In this issue of Industry Insider, Craig Errey, our guest columnist from PTG Global, discusses how to avoid spending too much time and money on enterprise software implementations.


The conventional approach to implementing major enterprise software is to create a set of high-level business requirements and then go to market to select a technology and/or vendor. This is not necessarily the best approach.

Invariably, one or more of the following happens:

• Potential customers are wowed by the size of the vendor's customer base - the majority are never wrong, right? If it works for all these organisations, how can we go wrong?
• Vendors then offer a cheap entry price into the world of ERP / CRM and make various claims about the superiority of their software and the impact on your business,
• The executive, although somewhat jaded by the IT department's continued troubles in delivering technology that works, engages the vendor thinking it will be different this time,
• The vendor starts work and swarms of 'consultants', still quite wet behind the ears, are poking around in your business, saying you need to change this and change that,
• You have regular meetings with the vendor where you argue, negotiate and then resign yourself to the sacrifices you need to make because their software 'doesn't work that way', You also need to change your processes to suit, otherwise they say 'Sure we can do that, but it's a change request', and 'ka-ching ka-ching' goes the cash register,
• You review and sign-off large lists of 'change requests', thinking that there's something funny with the pricing in relation to the original quote given way back during the tender process,
• Years after the project was supposed to finish, the same consultants are now getting married and having kids, all toasting you for making it possible.

While a combination of all of the preceding represents an extreme case, it can be reflective of the common experience of companies that implement large scale enterprise applications.

Importantly, I haven't even mentioned the problems with the user interface. The reality is that the success of a given technology is not dependant so much on issues of technical elegance as it is on user acceptance. That is, when staff have to figure out how to relate the different business processes in an ERP system to the way they're used to doing things.

Faced with a need to 'learn' new screens that bear little or no resemblance to the applications they've used before, they invariably have a better idea for what to use -- spreadsheets and access databases (also known as corporate chewing gum). Think of the implications -- your ERP / CRM integration strategy has just been defeated by a basic spreadsheet.

I'm not saying that all enterprise software is destined to fail, or that you shouldn't (or can't) use it to run your business. Indeed, there are probably many successful cases. What I am stating is that success can be achieved with a far greater degree of certainty and a much smaller price. It all has to do with the way you engage a vendor and their technology. The traditional approach invariably leads to a greatly diminished return on investment.

Before I go any further in describing how to greatly reduce the risks associated with introducing packaged enterprise applications in any business, let's take a step back and absorb the lessons of history. Winston Churchill once said that those who didn't learn from history were doomed to repeat its mistakes.

Unfortunately, this has been the case with enterprise applications, and not just packages. The tidal wave of packaged software take-up, starting in the early '90s, was a knee-jerk reaction to failed custom system development projects. For example, in the banking sector, multi-hundred-million dollar system disasters are the stuff of legend. They caused the affected management of these organisations to lose their appetites for more of the same. The thinking then became "We would have to be better off with packages because a high degree of what we need already exists".

This really appealed to the systems integration community, for obvious reasons, and many of them experienced explosive periods of growth. However, retrofitting a major application actually amounts to a more complex exercise than developing one from scratch, as many organisations have discovered.

So, what was the lesson that needed to be learned? What was the factor common to both approaches that caused the grief? There was no blueprint or master road map that fully defined requirements and created a clear line of sight between strategy, application behaviour and application code. No matter whether it was custom or off-the-shelf software, the method of engagement caused the problem.

Now, let's return to the central topic: how to effectively engage a technology vendor to get it right the first time.

Don't engage a technology partner to help with your business
One of the biggest mistakes organisations make is to engage the technology vendor too early, on the premise that they will help them with their business processes. The technology vendor knows about technology, not about business -- after all, you wouldn't get them to run your next business strategy meeting -- so why are they relied on when it comes to the business processes that have to deliver on the strategy?

With such a heavy focus on the technology, the IT department begins to think that business is all about technology -- in fact, business is about people. That is, people doing business with other people to exchange value through products and services. Therefore, if you only engage a technology company, you immediately create a void on the people and business side of things. Successful organisational change comes about when people, business and technology are fully aligned.

When they're not aligned, staff who want to do a better job are forced to find workarounds for poor practices. But once the processes are embedded in the software, it becomes harder to get around the inefficiencies. Then two things happen -- people start performing at a lower level and/or they return to the old applications or use Excel and Access databases to compensate.

So why doesn't the business first engage a business management expert to assist them in ensuring their business processes are best practice before embedding them in software?

Pick a vendor that can match 'your' business model
Instead of compliying with the application's embedded business model, organisations must ask the fundamental question about their technology partner: 'What do they know about my business?' Even better, 'What does this technology vendor know about best practice, change management and other fundamentals of running a successful business? How do I know the embedded processes really work and are best for my staff and customers?'

While the vendor may be able to successfully run their own business -- selling software -- what do they really know about other people's businesses and people's performance? How can you know that the changes their application will invariably force will improve business or drive success? You could even ask if the technology vendor uses their own software to run their business.

Before you pick a vendor, you need to be absolutely clear on the business processes, user requirements and interface designs necessary to implement these processes. Technology vendors are not generally good at this aspect and leave it to last, or downplay its importance.

Cheapest is not best
The tough competitive landscape means that vendors need to cut their prices to 'get in', knowing full well they'll make up fees in the ongoing change requests and the fact they'll still be working on it years after they said they'd finish. For its part, business has also been known to twist vendor's arms on pricing. Something's got to give and it is invariably the quality of the end result.

Despite the promises of off-the-shelf software, there is always some customisation required as you find out that the software doesn't work the way you want it to. How did you end up in this situation? Mainly because the initial requirements were so vague and ambiguous that any of the vendors appeared to deliver on them -- so you picked them on price. But as we all know, the devil is in the detail. With inevitable customisation requirements, custom built software may be a better solution.

The critical success factor: The user interface is all people see!
With technologists in charge, the user interface is generally the last thing to be designed. Why is the user interface critical? Firstly, the user interface defines the application behaviour and implements the business processes. Second, to the user, it is the application: you don't take the executive down to the server room to stare at the hypnotic qualities of the flashing lights, or let them ogle in wonder over the coders' shoulders. The only thing they (and end users) can make sense of is the user interface.

I mentioned earlier the gap technology vendors have in getting the people and business side right -- well this is where it all goes pear-shaped. If your staff can't use the application, or it takes twice a long as before, then this is where your return on investment will evaporate. Staff will just go back to the old ways or use their spreadsheets instead. The alternative is to continue to engage your vendor and work though hundreds of iterations with the user interface as you try and get something that people understand and can use.

Don't assume customisations will work when the base program is updated
The vendors regularly update their fundamental codebase to introduce better and better technologies. Unfortunately, all that customisation that you had to get to make the application do something close to what you need is not compatible and needs to be done again. If you don't upgrade, the vendor simply 'desupports' the old version and you are stuck in a bind - pay more money to stay up to date with an application that will still not work the way you want it to. As I suggested earlier, sometimes custom software may be better.

Where to from here
There is no doubt that ERP / CRM and related applications usually have little trouble with the business rules, policies and procedures for your business, but it's the user interface that will make or break the success of the implementation in the workplace.

If you're in the middle of implementation, there are a few things you can do:

• Check the current progress against the initial estimates. If you are in the early stages, then consider putting the project on hold. A month to take a breath and consider your options is nothing in the context of a multi-year implementation schedule.
• Examine the business processes you're embedding. Are they best practice? Are they what your customers value? Consider engaging business management or change management consultants to work with you to get the best efficiencies from your processes.
• Where is the user interface up to? Can people actually use it quickly, easily and without training? If you haven't progressed too far, engage usability and user interface design consultants to spend time getting the interfaces right, and then control ongoing development against the interfaces.
• What are your implementation strategies? If you have committed to months and months of training across all staff, then variance in performance is bound to be a problem. Training is just not an effective strategy -- if you have to train people to use the interface, then the interface is not helping people do their job. The interface should guide and constrain people's activities so they deliver best practice in a consistent manner.

If you're contemplating ERP / CRM for your business, consider the following:

• Get your requirements fully specified up front. This means all business requirements, all user requirements, and all user interface designs. These three components will then influence your system architecture. Armed with this 'Blueprint', you can then go to market and seek a vendor that can build to the blueprint. You may find that custom software is a better option than off-the-shelf software with hundreds of customisations.
• During requirements, work with change management consultants to ensure the business processes are the most effective and efficient they can be, and match customer expectations.
• Create a performance management framework that will demonstrate the required return on investment. This becomes the testing framework to control activities and ensure things are being done to contribute directly to the success of the business.

biography
Psychologist Craig Errey is managing director of PTG Global, which builds and tests online interfaces for intuitiveness and usability.