|
It is a truism that in any complex activity, the critical, defining decisions should be made as early in the process as possible. In ERP implementation projects this principle is routinely undermined by the nearly universal practice of separating acquisition and implementation activities into separate projects, performed by separate teams operating under separate control.
It is a truism that in any complex activity, the critical, defining decisions should be made as early in the process as possible. In ERP implementation projects this principle is routinely undermined by the nearly universal practice of separating acquisition and implementation activities into separate projects, performed by separate teams operating under separate control. This causes any number of critical decisions that ought to occur in the earliest phases of acquisition planning to be deferred to the implementation phase, where they are then made by the wrong people for the wrong reasons, well out of the sight of those who have the most at stake in them. These stakeholders have, in fact, needlessly surrendered control of the project to outsiders in the usually unquestioned but always mistaken belief that technical proficiency and product knowledge trump their own needs and abilities in all matters relating to system implementation.
What must be turned over to outsiders is the technical process of system configuration – the actual work of making the product do what the user company needs from it. This is a lot, but it doesn’t include three things that should never be turned over to outsiders, but often are:
The working blueprint for what the user company needs the system to do.
The enforceable definition of project success as nothing less than the working, efficient configuration of the system according to that blueprint.
The day to day monitoring and control of the implementation itself.
These three things can’t be separated. Day to day control of the implementation is ceded to implementation vendors when they are given the task of deciding what the system will do (as opposed to how it will do it). When that happens, the implementation team has no choice but to take control: they’ve been given the task of defining the project, so define it they must. And day to day control slips away unnoticed when the implementation team is held to some standard of performance other than the configuration of the system according to the user company’s precise instructions.
This being the case, why is the job of defining what the system is to do ever passed to the implementers? Because of some common, overlapping misunderstandings.
It is often viewed as a technical, software-dominated task, either too complex for the user company to do for itself, or too product specific for anyone but a product expert to do.
The implementation vendor offers business analysis as a professional service; sometimes it seems attractive to outsource this work, especially if the user company believes the vendor can do as good a job as it could do itself.
Most commonly of all, the user company sometimes thinks that they’ve defined their requirements when in fact they haven’t.
All three of these notions are misconceptions. We’ll take them in order.
First, the description of what the user company needs the system to do is not a technical, software-dominated task: the task is rather one of describing the complex internals of one particular company’s business, in common business-oriented terms.
In many ways, a well implemented ERP system is a mirror of a company’s operations. In this mirror, a single business event – say, a shipment to a customer – is reflected back to different people in different ways. To an accountant looking at one aspect of the transaction, it becomes a $135.53 debit to the cost of sales; to accounts receivable, it becomes an open invoice to be tracked; to someone else it represents a sales commission earned; it is a warranty responsibility for a business unit fifty miles away; it is a line item on a dozen sales reports, and part of a summarized total on a dozen more; it is a fragment of consumed sales forecast, that later became a fragment of a master schedule, that still later became a demand against manufacturing that was fulfilled by a now-closed shop order.
|
