What do we purchase?

Or why you should consider a bespoke application from Quru instead of that packaged application

Roland Whitehead, Quru CEO

Many businesses, for one reason or another, get to the point where they need to implement new business management systems. Whilst their needs and reasons will vary, they all share a common question: "what do we purchase?".

For many years now, the answer to that question has been an off-the-shelf or "packaged" application and services to install and tailor it. Be it an ERP or CRM based application, the services are likely to exceed the cost of the licenses. What is less obvious at the time of purchase are the hidden costs to the business of the acquisition. As a result, many business suffer very badly from their answer to that initial question - some never recover.

To illustrate this, consider the typical approach to the decision, installation and implementation process.

The decision

Initially the business will do a simple analysis of the sort of application that they need; this is where they decide if they are to be product based (ERP), customer based (CRM) or just financials based. Armed with that decision they may write an initial specification to determine their needs and will go out to the market to see what is available.

In most cases, the business will be flooded by implementers of one system or another. Many will have the same product and will compete on the service. They will offer product at various levels from the "instant install" to the fully featured, all consuming system. They will talk about the implementation time needed and give some warning that the business will have to do a lot of work to make this system work. Typically, the system chosen will have gone through some competitive selection where price will dominate.

Having secured a signed contract the supplier will bring in hardware to run the new system and will install the base application. This will take next to no time and will be completely painless. This is where the services kick in. An analyst will start to map what the business does; interviewing people from all parts of the business, they will attempt to describe exactly how the business works. Frequently this piece of work is eye-opening to the business' managers and can be the most valuable piece of the whole exercise.

The problem surfaces

The analysts will hand over a polished report to the implementers who will read it, cover it with highlight pen or sticky notes and start to work out exaclty how they can make the freshly installed package work something like the processes described in the report. Many hours will be spent achieving the easily achievable and the business will follow with pleasure. Gradually it will become clear that some (or in unlucky cases many) processes in place just can't be replicated in the system; all to frequently it is more than just a few. The implementers will scratch their heads and will do their best to get as close as possible but the end users assigned to test it will just say that it won't work. Sooner or later these issues will be escalated to the project sponsors:

"I'm afraid that we can't get the system to work the way you want as it currently is." says the supplier.

"Well this is an important process so what would it take to make it work?" sensibly asks the business.

"Oh, X thousands of pounds and Y months of time. It would be much better to change the process."

"That much? But that's 25% of the whole project budget more!".

"Exactly," says the supplier, "that is why we recommend that you change the process".

So the business sets out to change their tried and tested processes to meet the way that the new system works, the implementers tick their boxes and the trainers move in.

Repercussions

So now the trainers don't just have to train the users on how to use the new application within their existing processes, they have to teach new processes. The users don't understand why this has to be - those old processes have evolved over many years and are known to work and to work well. Potentially the new process has been rapidly put together to meet the implementation schedule (after all, the business sensibly put a delivery bonus into the purchase contract, didn't they?) and it may not be quite right. So when the trainer has left and the old system declared to be "legacy" (it wasn't possible to import all that old data into the new system because it just didn't fit - but that's a subject for another article) the end users are left struggling, productivity takes a nose dive and the real cost to the business kicks in - it now takes twice as many people to do the same job as it did before.

The alternate approach

• The important parts of the implementation process, the analysis of the business and the training, will remain the same. It is unlikely that there will be much difference in cost or approach. The savings made by not training new process will cover the extra costs of developing the training from scratch.
• If an application can be developed for the same cost (or less!) as the combined license and implementation costs for the packaged application then the business will be saving.
• There will be less productive time lost as the down time whilst the users learn new processes won't be necessary.
• There will be no opportunity costs as the business will continue to use its existing processes to fulfil orders and its own client will remain happy and continue to use the business.
• There should be fewer systems to maintain as a bespoke application can more easily import data from the old system removing the requirement for legacy data servers.

Going forward, the pain that the business would have suffered will be removed.

The CIO magazine published a very detailed analysis of the approach taken by the three major international fine art auction companies, Sotheby's, Christies and Bonhams (Read it here). Whilst the three business have very similar numbers of employees and locations and broadly similar numbers of sales and transactions, they all took a different approach. Sotheby's elected to install the ERP package SAP, Christies the CRM package Seibel and Bonhams used the core team at Quru to build a bespoke solution. With project budgets of $40million and £26million respectively, Sotheby's and Christies still rely on legacy systems, extra helper applications and high numbers of support staff. Bonhams, on the other hand, has a fully integrated system that includes print and web publication and 10 years of legacy data and went live for a total budget of just £1.5million.

It's a question of scale

So the big question is that of determining when the cost of licensing and implementing a packaged application is big enough to pay for a bespoke application. For many, this will be much lower than they thought. For others, it will be disappointingly high. From experience, we have found that if a business is looking up at implement a small business financials application such as Sage or Great Plains, then there just isn't the scope for a bespoke application - there probably isn't even the budget for a proper business analysis phase and the whole thing will be driven by the business' FD or CFO. But if the business is looking at a proper ERP or CRM package or an enterprise financials package then it is highly likely that the bespoke application will turn out cheaper.

More information

If you would like to discuss this further then please contact us through the contacts page or call us on +44 20 7836 0731.