ERP is commonly perceived as a computer system. Not so. It’s a people system made possible by the computer software and hardware.
Good people can make a bad system work; bad people can’t make a good system work
Often the problem lies not with the ERP concept. But in the demand for quick fixes and rapid cures to underlying structural problems. Putting yourself on the same side as the customer is one of the best ways to avoid the massive rework caused by the customer deciding that the product you just spent 12 months on is not the right product after all. One of the most important areas in enhancing the value added to clients is designing the presentation of information so that it can be readily assimilated and internalized as knowledge. All of the work that goes into development is not adding value until the software is in the hands of the customer.
The truth is, no organization plans to fail – rather, they fail to plan…
Many ERP implementations proceed without sufficient knowledge of the possibilities or potential in the new systems. This relegates the design process to a discussion of repeating the current design (the only thing the client knows) or implementing a process that the consultants happen to know (limited to what the consultants have experienced).
There are literally thousands of decisions that must be made on these projects. The project team must be empowered to make most of them. That is one reason organizations must put their best people on these teams. Achieving early wins and optimizing user buy-in can pave the way for controlling both political and fiscal costs down the road and increase the chances of delivery project on time and on budget. In making design decisions, the entire process should be considered, not just the individual steps, in isolation. As in many things, the business process is only as good as its weakest subprocess. Most of the attention should be focused on the process bottlenecks.
To integrate business processes, there is a tendency to employ a bottom-up technical integration, stitching together application components that were never intended to work together at the business level. The “Train the Trainer” Pitfall: It is not realistic to assume someone can be trained several weeks before the go-live and expect him/her to deliver quality training.
The starting step for business-driven implementation is the creation of business process maps. Ironically, customizations don’t add value by default. By default they subtract value, at least in the short run through costs associated with analysis, design, and development. In general, the more comprehensive the system, the more complex configuration will be.
Implementations must shift from “design and build” unique products to “buy and integrate” standard products. Unsuccessful companies start their ERP implementation effort with automation, bypassing the critical steps of understanding and simplifying their processes. These companies believe that automation alone will improve performance and lead to productivity gains. Automating complex or nonvalue-added processes, however, will not increase productivity or provide measurable improvements in performance.
Implementing the ERP system and realizing the promised benefits are two different ball games. Implementation can be a success, but if the operational phase is not planned and organized properly with the support of all the people involved, then the promised benefits will not materialize. To ensure rapid and smooth implementation, team members must be capable of dedicating 60 to 100 percent of their time to the ERP project. Lower committed times of 20 to 30 percent, or less, do not work well because of the high learning curves required for ERP implementations. Improvements in the use of the ERP system are an outcome of improvements in the process.
Knowledge transfer is the greatest value an implementation partner can provide to a customer.