Choosing Business Applications - The CEO View

Choosing and implementing a new business application can be risky, with many organisations making catastrophic, costly and very public mistakes. However there is plenty of proven experience on the best approaches, to draw on. Learn how to select and implement a new system and avoid risk.

Why the change

The first step in selecting and implementing a new application is to understand why this is being done. I have had over 20 years experience in selecting and implementing systems, and have found that the real driver for the change is not always fully understood.

Replacing a transactional system, such as payroll, finance, billing etc is costly and disruptive to the business. In many cases the reason given is that “we can’t get the right information out of the existing system”. This defies logic as the transactions are likely to be the same in the new and old systems, it is just that people can’t analyse them the way they want.

Improving the information access to an existing system may be a far more effective and less costly solution than replacing it.

Rule 1. Don’t replace a transactional system if information access is the main issue.

The right level of decision-making. Often the decision regarding a new system is left to those with operational involvement in the process. While it is important that these people be involved, they may only see the system from an operational view and potentially only in terms of the operations they know. For example a customer management system that manages customer billing is both a customer relationship system and a key financial system. The customer management staff will be focused on the system managing customer contacts well, but it may not manage debtors well. Similarly it may manage both of these transactions well, but be incapable of giving executive management the right level of knowledge about customer activity and trends.

Rule 2. Operational staff see transactions, executive management see business information and knowledge. Systems must address both.

In many cases the executive management is too busy to be involved in the detail so the selection process is delegated down to people who do not have the breadth of knowledge, or are incapable of making the judgements asked of them.

How to make a decision. The criteria for making a decision should be agreed before making contact with any of the vendors. Many people do their requirements gathering by talking to a number of product vendors and reading their marketing material. This approach is guaranteed to cloud and confuse your thinking on what is required for your business. In my experience the fastest way to introduce uncontrolled scope creep in the project is for the evaluation team to include facts from the vendors’ marketing material into their requirements list.

Rule 3. Determine how you will make a decision before engaging with the product suppliers.

In principle there are four criteria to consider in transitioning from the current to the target position:

Does the product functionally get you there?

Unless you have some truly unique requirements, most vendors’ products that you will shortlist will meet most or all of your documented functional requirements. The area that most people focus on, functional requirements is often the least informative for making a decision. (This is why a formal functional mapping tendering process is not a complete decision making approach).
Has the vendor the strength and capability to get you there?

Vendor strength, is often the most informative, but harder to judge. The strength and capability includes many things such as the quality and knowledge of their staff, availability of other people who know the product, local user groups, project management ability, site visits to other users and even a formal proof of concept. If done well a proof of concept can tell you as much about the vendor, their staff, their capabilities, as it tells you about the product.
Is the total price appropriate?
Does the product fit your environment, including integration to other systems?

Product fit is also vital to the success of the project. It may be the best system for processing particular business transactions, but if it doesn’t easily integrate with other business systems, or provide the right level of knowledge to the executive team then the project will not succeed in delivering to business expectation.

Implementation. The most consistent mistake made in implementation is to try to contract the responsibility for a successful implementation to the vendor or the vendor’s implementation partner. There are many instances where this approach has led to a very public disaster. It is far better for you to retain control of the project and engage those people you need to assist your staff including your project manager. This is not to say that you should not use the very valuable product knowledge and expertise from the vendor, just that you should retain control. The vendor’s staff may well know how to overcome a hurdle, but they are focussed on using only their product, not looking for the best way.

The vendor’s staff may very well implement exactly what you ask for, whether this is sensible or not. You need someone on the project who has the management backing to challenge existing business rules, otherwise you will end up with a new system that imitates the one it is replacing. Worse still you can end up bending the new system to meet old business rules and miss the opportunity to significantly improve business processes. It is imperative to the success of the project that the business processes are carefully looked at. I have been on many projects where, when challenged no one can recall the reason why something was done in a particular way. You will also find that the way staff “have always” performed processes may differ widely from your documented process.

Rule 4. Look carefully at business processes and remember the saying that the definition of insanity is repeating the same actions and expecting a different result.

The hidden costs. The four often overlooked or under funded implementation tasks are:

Project management

There is a rule of thumb from Project Management 101, which says that, unless in the region of 15% of the total services effort is committed to project management, you are not actually managing the project. While the vendor may provide good project management services, if you have accepted the earlier advice in this paper of not contracting the risk to the vendor, then the project manager should be your resource. It is more important that the project manager, you appoint, is an excellent project manager rather than a product expert.
Data migration

Depending on the nature of your business, the history and trend information you have in your current system may be one of the most valuable intangible assets you have. However this data may be in poor shape. There may be significant effort required to clean up this data and bring this valuable information across to the new system. The way to control the risk and variability of data migration is to conduct a formal data quality assessment of the current data, before starting.
Reporting

Again most vendors will point to their standard suite, their report writing tools and maybe make some provision for producing some additional reports. The rest is up to you. Costs can blow out here because your business users will want all their current reports repeated in the new system (whether they use them or not).
Testing

When implementing a package application the testing should make up around 20% of the total effort, if testing is to be done properly. Software customisation and development requires a greater testing component. There is more than one company that I know of that has gone out of business as a result of deploying a major business system that was not properly tested.

Many people look only at the cost of the package and the cost of the vendor resources. The vendor will want to make the total purchase price of software and services competitive, which is reasonable as the costs of the above four items are irrespective of the software chosen. However these four items could easily double the cost of the services required. Also, it is almost impossible in the proposal phase for the vendor to accurately assess real costs for reporting and data migration.

Conclusion

While there have been many catastrophes in selecting and implementing new business systems, there is a sufficient body of experience available to you to ensure you avoid the pitfalls. Follow the rules and learn from others’ mistakes.

For further information regarding the services offered by I Services Consulting, visit the CEO Online Advisor Network - click here

Bruce Drury can be contacted via the I Services website www.iservices.com.au, or by email bdrury@iservices.com.au. Bruce Drury is one of the founders and Managing Director of I Services Consulting. He has had over 20 years experience in delivering innovative technology solutions to business. He has worked as an employee and consultant to businesses large and small. He has worked with a number of the major systems integration companies and consulting companies. He is a qualified professional project manager. He jointly founded I Services 5 years ago to be able to provide business focussed and vendor independent business solutions.
First published: 18 October 2004.
Last updated: 8 March 2006.