What do you want your new ERP system to do for you?

When looking at new ERP systems, companies in the mid-market (Tier 2) especially have many choices but all companies, regardless of tier, have first to decide what they want their system to do for them. ERP systems are designed to cope with as many different scenarios as is economically viable to widen their appeal and maximize their potential market.

That means that they will have functionality, and indeed complete modules, that not every prospective customer will need or want. Not all companies, for example, will want to use the payroll module or the HR module, not all will need project accounting, and not even all manufacturing companies will need MRP.

So, even before writing a requirements specification or ITT (Invitation to Tender), they will need to decide on a high-level specification of what business areas and business problems the new system are to address. That means a review of what the company is currently doing and what it should be doing, both now and in the foreseeable future.

Some companies approach this by documenting the status quo, or 'as is', and using that as a template. However, this only works when they are perfectly satisfied with their existing system and are only changing it for technical reasons, such as it becoming unsupportable.

But, for the majority, moving to a new system is a rare opportunity to review what they are doing, how they are doing it, and why they are doing it. To quote Peter Drucker: “There is no greater waste than doing more efficiently that which should not be done at all”.

There are two phases in system planning. There is this first phase that we are discussing, and there is a second phase where the initial overall system design has to be reviewed in light of the functionality offered by the chosen system and may then have to be adjusted or amended.

This article doesn’t aim to duplicate the points made in the previously mentioned article about writing requirements or ITTs, but it does want to discuss at a higher level some things that need to be considered.

Blue moons and red herrings

When companies think about what their biggest and most serious problems are, it is entirely natural for them to think of the problems that have occurred most recently or which have caused the biggest problem. It is difficult to be truly objective. The problem that caused a real headache yesterday might not occur again for months, if at all, but the pain that was felt today is not something that they want to feel again.

For that reason, they will want the new system to provide a means of avoiding or at least alleviating that problem in the future. But a system shouldn't be built around exceptions; the things that happen once in a blue moon. No system can be designed to cope with the unexpected, so exceptions should be dealt with exceptionally.

A well-implemented system facilitates this by handling routine things routinely to free up people's time to manage exceptions when they do occur. Turning our attention to red herrings, where do these come from? Many people have elements of their jobs that they do not like and would happily relinquish.

When gathering requirements, some people will see opportunities for the bits of their jobs that they don't like to be taken away and either automated or stripped out and given to someone else. They will exaggerate problems that do exist and invent others that do not.

An advantage of having a team approach to requirements specification is that these falsities stand a much better chance of being identified for what they are.

Reinventing the wheel

When setting off to select a new system, there is always the temptation to use the present system as a template and just look for a system that just plugs perceived gaps. This can be dangerous; as it can't be assumed that any new system does all that the old system did, even if it comes from the same supplier.

Different systems have different design teams and these teams will have differing views on what is required in a system. There is also the common danger that a lot of money may have been spent on bespoke modifications for your old system, and what has become thought of as being a standard system is not standard at all.

Throw in resistance to change and a company can easily end up with a new system that is no better than the old one. It might have a new user interface and nicer screens, and it might not crash as often as the old one did, but it will not have moved forward.

A new system means and needs change. To the people who say, “I want everything to be different but nothing to change”, the response must be: “If you always do what you’ve always done, you’ll always get what you’ve always had”. But companies will find that help is at hand from their contacts and trading partners.

Many of these will be willing to host visits from customers and suppliers to discuss their systems and the way they work; recognizing that it is in their own best interests to have more efficient suppliers and more successful customers. That can expose a company contemplating ERP to new ways of doing things and new ways of thinking about problems, and frequently has the added benefit of strengthening relationships with those partners.

Companies need to remember not to look for a system that fits what they are doing now but to look for one that fits where they want the company to be tomorrow.

Too much bespoke

This problem can be related to the previous one in that they both try to limit change; be that change in the way the company works or change in the way that individuals work. It can also be caused by people conscientiously striving for the best system possible but, in the words of Confucius, “The best is the enemy of the good”.

Here’s an interesting fact: a major ERP company has said that, typically, three years into the live running of a package ERP system, less than 30% of the bespoke software written for it is still in use. Frequently it never gets used at all. But the writing of that bespoke added unnecessary cost to the project and probably delayed it.

Too much delay and too much cost and sometimes senior management will either pull the plug on the project or take a decision to go live without the specified modifications being completed. Companies then either go live with a system that has unplanned holes in it or, sometimes, senior management gets so bored or frustrated with the project that the system doesn't go live at all.

Bespoke software has a continuing cost over the years that it will be in use (hopefully at least ten). There is the initial cost of writing it, there is the cost of modifying it every time the system authors issue a new release of the package. Potentially, there is the cost of not being able to move to a new release at all because the cost of re-writing modifications is prohibitive.

Packaged software is written to be flexible but bespoke software generally is not, so companies can find themselves with a system that is stuck in a time warp whilst the company and the core package move ahead.

Because it was there

Additional problems can occur when companies move towards creating a shortlist and, in doing so, start to look at the functionality being offered by competing systems. As has already been noted, ERP systems are designed to satisfy as many requirements as possible and, for that reason, will have functionality that not all user companies want or need.

Because of the modular structure of these systems, much-unwanted functionality can be filtered out by simply not buying that module. So individual companies can decide not to buy, for example, the payroll module, the CRM module, or a whole range of modules such as those providing manufacturing functionality.

Sticking with manufacturing: some systems, particularly Tier 2s and Tier 3s, deliver integrated functionality that can't always be broken out and simply needs to be ignored and not used. So companies may have systems that have, say, MRP functionality even though they don't need MRP, or finite capacity scheduling when all they need is infinite capacity scheduling.

Likewise, the finance department may find that they have project accounting functionality but no projects to account for, and the sales department may find that they have extensive discounting options that they don't need.

Moving to a more detailed level: finance may find that they can have more elements in their General Ledger account structure than they need, manufacturing may find that they can have many more levels in their bill of material structures than they need, inventory may find that they can hold safety stocks against everything when they don't need to, and quality may find that they can hold limitless analytical data against every purchasing and manufacturing batch.

The danger is that companies can feel that, if functionality is available, they should be using it. They can be encouraged to do so by their implementation partners and system integrators, simply because more functionality to turn on means more consultancy days for them.

Sometimes the key to a successful ERP implementation is knowing what functionality not to turn on.