In the early phase of ERP project the processes are usually defined. Like the requirements, they can be done by two different main approaches. Either target organization is reshaped and procedures changed so that they will match the ERP package. Or ERP package is forged to match companies existing processes.

Sometimes the term business process re-engineering (BPR) is used by consultants to actually reference the first option, but dressing it up to sound fancy and desirable. What they really are after is simple and easy implementation. But the true meaning of the term implies doing the process definitions really from scratch! Neither based on the ERP product or existing practice, but genuinely anew, aiming to actually maximize the efficiency of processes from target companies viewpoint.

Best-practise vs model process

The ERP product is supposed to contain best-practice type template already, so the standard argument of the implementing ERP vendor is to simply stick to it. Even if it is not treated as such perfect model, it can still serve as the starting point for modelling. And should! In stead of "reinventing the wheel" it would be logical to have a working, documented and tested package as a starting point. That way the customer or the project team can assess what would be missing (or work wrong) if it was to be used. And then work out minimally intrusive (or the most cost efficient) way to change it to better match the critical requirements of customer. As the high level approach.

But things can get more complicated even on this principle level! Especially if the target organization works on several physical locations (sites) and/or in several businesses (or product types) which all have their own ways as starting point.

Multi-organizational modeling vs unifiqation

Even if project could construct a perfect but different design for units A and B individually, the big question is: should they still run the same processes? If so, then which unit will be sacrificed to run the inferior (from their perspective) process? Or should a compromised process be designed, not a perfect for either, but good enough for both?

If every site, letting alone each product group or family, is allowed to run its own process optimized for each, there will be lots of processes required. If there is a gap in standard template process of the product, which needs to be enhanced, this effort must be multiplied by number of process variants. If these different units require or share common objects (say same raw materials or customers) in a different way, there maybe issues setting up the related master data in such a way that it supports both (or all). The alternatives multiply the effort needed in: implementation, testing, setting up master data, training, support instructions, future development etc. 

From business perspective the alternatives can take a toll on expected benefits. Creating a common purchasing department to handle all sites gets harder, if each of them have totally different process, setup and even definitions. Sharing ideas and knowledge will face extra boundaries if each unit runs totally different processes. All developments need to be done to each alternative, instead of leveraging the common ground. And so on.

It is easy to understand that top management and CIO office usually want none of above. The would prefer standard package for everyone. Even if modifications are to be allowed, they should at least be global (common to all) and not local. 

Resistance to unification

So pressure is hard to unify processes to the maximum, creating optimal global solution, at the cost of running things less optimally locally. Perhaps even in much less optimal than in existing older system. If this looks to be the case (regardless if it actually is that bad) it may cause some local managers to resist the whole project and to even impede it. This is often referred to as change resistance, and it can happen with reason or without.

Resistance can be direct, or sometimes more subtle: perhaps key people are not allocated to project by plant managers, people are not attending the project meetings (due to "emergency meetings" summoned by managers), or managers keep bringing new requirements to project team continuously and in critical phases (delaying delivery of them on purpose). It is hard to tell when these happenings are just normal business going in parallel with project and when it is change resistance, the difference may be in the eye of the observer. In the eyes of the project manager it is change resistance if not mutiny. It is not necessarily just childish fear for new, but response to the assimilation effort by the new common process. One cannot help not thinking about the Borgs in the famous Star Trek series when the unification and assimilation are emphasized.

This kind of behavior requires top management attention: if local site managers have more authority than project management, then their mutiny pays (for them) but the project takes the damage as it gets stuck in implementation. The importance of involving top management to the ERP project makes sense considering above - it could take changing some positions to clear way to the project. And this is of course a gambit in its own, probably the alternative managers are not as experienced in local business as the original ones, so issues could surface elsewhere.

In single site projects the focus is more clearly between localization versus standard (vanilla) package, but it can still play similarly. If the top management wants the vanilla and locals the enhanced version then there is room for fights. Or the friction can happen between departments, as the new processes will switch tasks and workload between departments. Those who feel they lose on this deal, may start opposing the project. On all these occasions, in order to meet the company wide goals, certain local and individual units may resist and this resistance must be handled one way or another.

Company template

There are some ways to deal with these problems. Like said above, using ERP package standard processes as defaults is usually a good approach. Keeping bar high enough regarding modifications is another good idea, but it shouldn't be too high. Unification is the key for efficiency in the long term, but modularity in company template is a way to allow some level of localization. It means that there could be e.g. two different templates to run production so that there is some room for choices per unit. But optimally both of these "production modules" would be compatible with "sales module" so that not the whole template needs to be doubled for a single change. If there is then e.g. business reporting needed, it would probably require that double work is needed regarding production reporting, but still hopefully a single implementation for sales would be sufficient. This way a "company template" gets build that makes further rollouts easier and more flexible, but it would still be manageable and relatively efficient approach. Of course this kind of extra aspect to process planning makes the already difficult implementation effort even harder, but it is just one of the little details that separates poor and excellent ERP project management and implementation.