Challenging accepted ERP wisdom

Workshop So you've been through an ERP implementation before and you know how it's all done? That’s good to hear, but if your experience was a few years ago, it might be worth taking a look at the way things have been changing. The truth is that anyone reviewing their ERP requirements today won't be doing themselves any favours if they approach the definition of requirements in the traditional manner, and there are two areas of accepted wisdom that need to be seriously challenged in relation to this.

The first is the assumption that your business is unique, and therefore that the game being played is to find a solution that can be morphed to the shape of your peculiar business processes.

Whether the processes concerned are existing ones that have grown up over time or funky new ways of doing things that might fall out of a creative re-engineering exercise doesn't matter. What does is the misconception that you can somehow gain business advantage by doing a lot of core process stuff differently to your peers in the same industry.

Experience over the years has demonstrated time and time again that this is the exception rather than the rule. In fact, there is generally more to be gained by standardising on industry best practice in so called 'non-differentiating' areas (which probably represents the bulk of your process-centric activity), rather than perpetuating poor legacy practices that can often be convoluted and inefficient as a result of historical factors that ceased to be relevant many years ago.

This sometimes means taking a hard line when working with people in the business on defining functional requirements, and not letting natural resistance to change, emotional or political attachment to existing ways of doing things or threats to personal security (eg through roles disappearing) get in the way of rationalising and streamlining processes. Of course this needs to be done as sensitively as possible to keep people on board, but if pandering to someone's illogical desires or hang-ups translates to two weeks of customisation work and an ongoing maintenance burden, you really need to stand firm.

In practical terms, the trick is to do a rough-cut requirements analysis to establish scope and emphasis, being honest about the functions and processes that are genuinely differentiating, but then take the time to review a few product offerings and sit through some demos before locking your requirements down. As you look at the way the latest packages work, there will be areas in which suppliers are consistently presenting something different to the way you do things, and this is probably an indicator of where you are out of line with best practice and should therefore adjust your process to the standard application, rather than vice versa.

Of course from time to time, you will encounter a difference in relation to something that really does provide an edge if you approach it differently to everyone else, in which case there might be a need for some tailoring, but you want to keep these areas to an absolute minimum.

For the avoidance of doubt, none of this means taking a totally prescriptive approach and having to be a slave to policies and workflows that have been rigidly defined by a supplier. Within a given process area, modern ERP packages offer a lot more flexibility than the systems of the 90s in terms of soft configuration options. Variations on a core theme can be implemented through software switches and rules to allow fine tuning to your environment. It's when you move outside of those parameters into code cutting territory that it starts to get expensive and potentially constraining over the longer term.

The second big area of accepted wisdom that needs to be challenged, particularly in a large enterprise group structure, is that it is best to standardise on a single package across the whole of the business. A lot of organisations have taken this blanket approach over the years and ended up stifling or constraining the activities of smaller operating companies, or placing an unnecessary burden on them from a cost and rigidity perspective.

This is especially true when there is a lot of diversity in business structures, models and operations at divisional level, which for the operating company can lead to a negative double whammy. Not only are they forced into accepting an inappropriately configured 'big iron' ERP solution, they are also asked to pay their share of initial licence and implementation costs, and ongoing maintenance and support, all at premium prices.

If this kind of situation exists within your organisation, then a switch to the so called 'two-tier' ERP model might be in order. This is characterised by the existence of a large-footprint central package, surrounded by lighter weight solutions that are cheaper, simpler and more flexible, and better suited to operating company requirements.

To quote a colleague in another analyst firm that has done a lot of work in this area, Ray Wang from Altimeter Group, "Smaller 'spoke' systems in a two-tier hub and spoke approach can offer lower costs and greater flexibility. There are typically no real savings from 'single instance' ERP deployments across a group structure". In line with this, Wang's data suggests the number of organisations considering the two-tier approach is increasing rapidly, with almost one in three larger enterprises interviewed heading in this direction.

If you turn this around, there is a warning here for organisations who currently have a mixed ERP environment to think twice before assuming that a group-wide consolidation exercise is the right thing to embark on. If a division's current systems are in need of replacement, a switch to a modern small-footprint alternative might be a better bet than absorbing them into the 'mother ship' environment.

Some of you out there might have experience that corroborates the above, but others are sure to take issue with our recommendations. Either way, it would be good to know what you think in the comment section below. ®