Multi-Tier ERP Implementations

Big companies feel comfortable with implementing Tier 1 ERP systems whilst most small companies, though envying the companies that can spend tens or hundreds of millions of dollars on such systems are pragmatic enough to realize that Tier 3s are a more realistic fit for them.

In the middle come Tier 2 systems for mid-size companies and also sometimes for independent operating units within large conglomerates. This blog, however, explores the fact that things are not always so clear-cut, and that it is possible for large groups to productively and efficiently use systems from more than one tier.

To some extent, this is happening already, with some large organizations using, for example, SAP ECC (a Tier 1) and SAP Business One (a Tier 3), and some medium size ones using systems like Sage Enterprise Management (a Tier 2) and Sage 200 (a Tier 3) operating in parallel.

They often initially believe that the smaller system is just a scaled-back version of the larger one and that, in consequence, operating the two side by side is straightforward, but this article, when looking at running different systems together, doesn't assume that they come from the same stable because even when they are they can be of completely different architecture and have very little in common anyway.

The article also looks at the pros and cons of both the single system approach and the multi-tier approach because, as is usual with ERP, few things are clear cut. But first the advantages of using just one system throughout the group.

Cost is frequently given as a justification for standardizing one system. Looking first at implementation costs, it would appear axiomatic that buying extra licenses for a Tier 1 system would be cheaper than buying separate Tier 2 and/or Tier 3 systems but with, for example, SAP moving to price based on the number of transactions processed, companies would be wise to check.

It should, though, be possible to reduce training costs, especially when doing a phased roll-out where some of the team involved in the implementation at Company 1 can help with that at Company 2, etc. Likewise, all companies can share experiences and ways of getting around system limitations (all systems have limitations). This sharing of experience will also lead to a faster overall implementation; meaning that expensive consultants are around for less time.

A final thought on the advantages of the single system approach is that some organizations, at the end of the implementation phase, retain at least some of their core team to form an internal support and consultancy group to provide front-line assistance when users run into difficulties and also to evaluate and, if appropriate, to roll out new releases and updates along with associated training, thus reducing lifetime costs whilst extracting maximum benefit from the chosen system.

Turning to possible disadvantages; cost advantages are not always easy to predict. The problem is that many systems are priced on the number of concurrent users (i.e. the maximum number of people who can be logged onto the system at any one time) either on the system in total or onto a particular module.

But a small company within a large group may not need all of the functionality that a large system offers so they might find themselves paying, for example, for users to be able to access the MRP module just to generate a replenishment report based upon ROP (reorder point) requirements. Or perhaps for the ability to apply complex sales order discount structures when they are not needed.

The reality is that simplifying a complex system is very difficult to do because it's usually not just a question of not using all of the available functionality. Different ways of working have to be developed and tested (imagine working out how to get the best out of a Ferrari without taking it out of first gear).

Yes, it is possible, but it takes expertise. And it adds time, cost, and risk to the project. What usually happens is that the smaller companies end up with systems that are unsuited to their needs and, when asked about them, words such as clunky, complex, laborious, and frustrating come into the conversation. Frequently they end up using just the bits of the system they are forced to and fill in the gaps with spreadsheet-based manual systems.

Because the 'one system' approach is not always the best solution, some companies look at a multi-tier approach but that too has its pros and cons. One big challenge for some organizations is that it is harder to manage and coordinate multiple implementations than it is just one.

At every stage from requirements specification through to implementation, the different teams will likely be advancing at different speeds. With Tier 1 systems typically taking three or more years to implement (potentially twice that if rolling out across a large group) and Tier 3s taking less than one, the smaller companies within the group could be ready to go live before the big ones have even made a selection decision.

In reality, from a pure time perspective, if the smaller companies' implementations have to be held back, they will probably be no worse off than if they had had to wait for a Tier 1. But getting a new system is probably something that they will be looking forward to (if not, then the organization has problems that ERP is unlikely to cure) so telling them that they will have to wait for it until the larger companies are ready to progress is likely to frustrate them.

Although the total running costs of multi-tier versus the one system approach can be hard to calculate, clearly the cost of selecting two (or more) systems will be more than one. It won't be twice as much because not everything has to be done twice (requirements specifications, for example) but systems have to be researched, reviewed, and assessed.

This is a manageable problem and one possible solution is to allow different companies to progress at different rates (although within an overall planned strategy), and that leads to the next consideration.

The organization will likely want to consolidate financial information at the Group level. For that, they can use a specialist accounting system or the financial modules of Tier 1 or Tier 2 solutions but either way, it will be necessary to have routines that can transfer data cleanly and reliably from the operating unit systems.

It also means a standard Chart of Accounts structure so it will be necessary to ensure that all systems can support that. The good news is that communication between the systems does not have to be at an individual transaction level and there are many systems out there that have been specifically designed to do the job.

One consideration, though, is that if some companies go live before others, there will need to be interim links developed to legacy systems and then this work will have to be re-done for the definitive system.

Additionally, operating different systems makes it more difficult for both the implementation teams and, following go-live, end-users to share experiences and it also makes it harder to introduce common procedures and ways of working; even though it can be argued that this is usually more a function of differences in operating unit size rather than ERP system.

However, on a more positive note; there are certainly advantages and one is that systems designed for smaller companies tend to be a better fit for smaller companies. They are less likely to have redundant functionality and will be a lot quicker to implement (3-6 years can be a long time for a small company and it can be argued that if a small company can wait even 3 years for a new system, it probably doesn't need one).

Add the fact that Tier 3 consultants are usually cheaper than Tier 2s, who are cheaper than Tier 1s, and the fact that these consultants will not be employed on scaling back what to a small company might be a monster, and clearly, implementation costs can be much lower.

It always helps that the smaller companies will feel more ownership of the chosen solution if they were part of choosing it. In the early days of a Tier 1 solution, some may feel that having a Tier 1 on their resume will help when they look for a new job, but pretty soon reality will kick in and they will realize that using a system that was chosen for them and not by them, and a system that is not optimized for their needs, is a high price to pay daily.

Turning this around, of course, the larger companies will also feel shackled if any lack of resources in the smaller companies limits their choice of system, how it is implemented, and, indeed, when it is implemented. And if they are told, “We would like to buy Megacorp's ERP but the smaller companies simply couldn't cope with it”, they will feel equally aggrieved.

So, in summary; when looking at the choice between single-system and multi-tier ERPs, the decision, although not always clear-cut, is likely to depend on the relative size of the companies within the group. If they are of comparable size, a single system solution is usually best but, if of differing sizes, multi-tier has to be considered.

Likewise, if standardization of procedures and ways of working is required, this is easier when only one system is used. However, the more the companies in the group differ, the more that multi-tier makes sense.

The good news is that increasingly nowadays, companies have a choice.