Are You Using an Older Version of Salesforce.com’s Service?

The answer is – it isn’t possible.  “No one’s ever on an old version of Salesforce.com because Salesforce.com is multitenant, that is everybody shares the same servers, so when those servers are upgraded, everybody’s upgraded.”

So naturally, when a perplexed customer asked me whether “Navatar runs on an older version of Salesforce,” I became very curious about what could have prompted that question.

When the customer revealed that a consulting firm had advised him about Navatar being on an older version, the mystery began to unfold.  Basically, consultants and systems integrators make money customizing software. Some of them don’t like Navatar’s pre-built software for financial firms (built on the Salesforce platform) since it reduces the hours they can bill to a customer. To steer the customer away from off-the-shelf products, they feed false information so they can make money re-inventing the wheel.

This happens often, since the cloud, still in its infancy, is a bit like the wild west. Fortune hunters, such as consultants fixated on their billable hours or software salespeople obsessed with their commissions, sometimes discover easy money by planting fear or simply distorting facts. … when that happens, it is the customer who often loses.

The customer loses because they walk away with the impression that reinventing the wheel is a better and easier option. They end up spending a phenomenal amount of time engaged in system implementation, instead of their core business – in addition to paying thousands of dollars for consulting and support services that are redundant or available for free in the cloud world (see my InformationWeek post: How to Reduce IT Services Costs in the Cloud).  But their frustration really peaks when, even after all the spending and distraction, they never get a system that meets their needs. They are then left with two difficult options:

a) changing course – switching to a pre-built product, which requires writing off the time/money spent on system implementation (it also requires someone willing to acknowledge their mistake, which is probably a bigger challenge)

b) continuing the reinvention process – assuming, somehow, that they are close to the finish line and finding a different consultant with the hope they can somehow salvage their investment (which inevitably requires throwing more good money after bad).

How to avoid getting into this situation? Read on.

So, should I reinvent the wheel?

Even though there will always be con-artists, having choices isn’t a bad thing. Customers need to be aware of some simple facts that can lead to an informed decision, when they choose between buy versus build, a standard IT industry concept. Build refers to buying some generic software or platform and then using it to build the functionality you need – you also then need to continue maintaining and supporting whatever you build. Companies usually go the build route when they believe their business processes are so unique that they cannot fit any packaged product – some large companies also choose to build since they are heavily invested in their IT organizations that like building systems. A company will buy commercial off-the-shelf (COTS) software, instead of building, if they believe 75-80% of their needs can be met by it (read more about buy vs. build in this article). So, both buy and build are valid options, suited to different types of scenarios.

The cloud offers options between buy and build.  For instance, Salesforce provides a top notch cloud (and CRM) platform, which is sold directly by them as well as by other resellers and OEM partners, through AppExchange and other channels. You can find so many products on AppExchange that can provide you what you need – if not, you can also try to build it yourself using the Salesforce platform (or other cloud platforms). Not every product can be replicated using the build process, but given time and money, quite a few of them can.

When it comes to build, there are plenty of available statistics around the value provided by software development projects. According to Standish Group (Chaos Report), 68% of all software development projects are unsuccessful. Mercer Consulting’s Firoz Dosani claims 80% of technology projects actually cost more than they return. In the cloud, the build success percentages may be better – but so are the number of buy options available to you.

The statistics notwithstanding, if you choose to build in a cloud environment, you have to be ready to spend (at a minimum) the next 6-12 months working with consultants (or IT staff) – and then hope your investment will pay off. All this time you will be spending your time thinking about what your system should be doing, how it should be modified, how to generate reports, etc – and if you do get a system that does what you want, you will also need to figure out how to support and maintain it.

That said, if reinventing the wheel still seems tempting, it’s most probably due to one (or more) of these reasons below:

1.   You believe your business processes are very unique – you’re convinced, after careful analysis, that other businesses similar to yours operate in a very different way and no off-the-shelf product comes close to matching the way you do business.

2.   You have to deal with complex integrations – you have to integrate the new system to several of your internal systems, before it can provide any value.

3.   You are an IT person who loves to build – you are not scared of writing software or you find building to be a fun activity or you believe doing it yourself will make your job secure.

4.   You have assumed that building is very straightforward – you have been told that building is simply a matter of a few mouse-clicks, while enjoying a couple of beers – or a consultant has convinced you that building can save you a lot of money.

5.   You’re worried about the viability of the COTS provider – you like the off-the-shelf product but are concerned about the risks of the provider going out of business.

6.   Someone with credibility has badmouthed the buy option – this is exactly what happened in the example above.

If your reason is #1 or #2, you may not have much choice but to build – the best option then may be to hire a good consulting firm who can provide proper guidance. But remember – good consultants don’t reinvent wheels. Stay away from the type that I described in the example above and hire a firm that has credibility in your industry.

If your reason is #3, you may have made your decision already. Assuming that your job will remain secure in case the build project doesn’t deliver as expected, at least you’ll have fun doing what you love.

If your reason is #4, you will do yourself a huge favor by assessing the total cost of ownership (TCO) of what you are about to do, to understand what it would really take to build and maintain the system. You will need to understand the time and money involved in requirement gathering, building, modifying, training, supporting etc, over a period of time (there are several simple TCO models available). It won’t take you more than 30 minutes to understand the TCO, if you can spare that time.

If your reason is #5, you have to understand that in the cloud world you’re not really buying software – you’re only paying for a year’s usage, so your real risk isn’t that of losing your investment; the only risk is the additional cost of migrating to another system, which is usually lower than that of reinventing the wheel. Generally speaking, if the provider has been around for more than 3 years and has more than 100 customers, you should be on solid ground.

If your reason is #6, you can test the credibility of whoever advises you against buying, by asking them to put their assertions in an email. If you never see that email, you will know that they are not acting in your interest.

It’s really about TCO

When it comes to choosing a cloud-based product, there are a number of factors to be considered (which I will cover in a later post). At a minimum, the product fit and the total cost of ownership (TCO) are important. Most customers are able to assess whether a product fits their needs – it’s their inability to estimate TCO upfront is what steers them away from their core business, into the messy world of systems integration. It shouldn’t be that way.  As Robert X. Cringely observes:

“Unless you are operating a software company, software should not be central to the way you view your business. It’s just a means to an end. And to be classed as truly successful, the means should be quietly efficient and as close to invisible as you can get.” 

Alok Misra