Short answers first: the decisions that are critical to ERP acquisition and implementation project success should be made at the earliest possible moment in the acquisition and planning process.
What are these critical decisions?
- What are we trying to implement?
First, some very common and very wrong answers:
- Software
- An ERP system
- A particular brand of ERP system
- A subset of a particular brand of ERP system configured in a particular way
- Any other name for the overall task that isn’t centered around the concept of running our particular business as we best see fit to run it.
The natural tendency to answer this question in terms of software is the original sin of business system implementations, and the root cause of a vast amount of failure, struggle and misery.
Nobody (at least nobody who isn’t in the software business to some extent) buys software just to buy software. They buy software to accomplish some particular purpose, and that purpose is what they’re implementing when they implement the software that they buy. The purpose of any planned ERP system is not an airy abstraction (á la “implement ERP” or such); it is a dense bundle of specifics about how the company does business and wishes to do business over the life of the new system. This dense bundle of specifics includes the company’s current operations but it also extends (or should) into the company’s future. Many things will happen during the life of the new system, and not all of them are confined to the way the company operates today. The company’s strategic plan will either be realized or not during the life of the new system. If that plan succeeds and the company’s strategic goals are met, the new system won’t be the only reason why. But if the new system is unable to support the company’s long term goals, that alone is all that is needed to defeat them: that alone is sufficient to defeat all the strategic planning the company could ever do.
The failure to frame the entire acquisition and implementation process in concrete, detailed business language that describes exactly what is to be accomplished – both in terms of present operations and future goals – is the first step toward failure.
So, the question “what are we trying to implement” leads to a couple of others:
|
- What are the risks involved, where do they lie and how will we manage them?
- How do we retain control of the implementation process?
- How is control usually lost?
- When is it lost?
- How do we avoid confusing knowledge with resources?
What does this even mean? In a nutshell, we often rightly perceive that we lack the knowledge needed to perform some task; in ERP projects, there will usually be many such tasks (often including management of the project itself). In every such case there is an implicit choice between learning the expertise required and renting it, but we can’t make this choice until we know we have it. All too often in ERP projects, missing knowledge is assumed to mean missing resources: we see ourselves compelled to rent people simply because we lack their expertise, ignoring alternative avenues of knowledge transfer. When we make this mistake, we often end up renting people who do (or at least charge for) far more than we actually need from them. Worse, we often turn over control of our project to the outside management of the people we rent (because how can we manage them if we don’t know what they’re doing?) This is compounded by three facts:
- Inevitably, some expertise must be rented in any ERP implementation project; meaning that we are already receptive to renting expertise and the people we rent it from are always willing to rent us more.
- Next, we do appreciate the very real costs and burdens (especially those of time and opportunity cost) of allocating and training our own people; we are reluctant to incur these costs and burdens because of
- the problems caused by making our own people available for what seems like optional work, and
- the apparently fleeting benefit of acquiring the missing expertise ourselves;
- and we don’t properly understand either the extent to which we’re renting more billable hours than we need or the full cost of renting expertise in the first place (especially in non-value added time purchased and the overall impact on the project in terms of risk and control).
Finally, we don’t know where or how to acquire the knowledge that we lack; often we don’t even know how to describe the knowledge that we lack.
- Who is going to do this work?
- What resources are required?
- What resources are we able to commit?
- What resources will we have to acquire?
- What absolute constraints in terms of budget and schedule are we going to impose on the effort?
