If your business is to achieve benefits from a new business system, executive management must define a framework for handling the project. A friend of mine, paraphrasing an old Gartner review on relational databases says "ERP is technology that can hurt you." Nothing is farther from the truth if it is managed well. Improving technology, including ERP systems, is required if a mid-size business expects to be competitive five years from today.
ERP implementers are now utilizing lessons learned from the time when many businesses were preparing for Y2K by implementing large all encompassing ERP packages. These lessons can now be framed into governance philosophy that considerably reduces the risk and the expense of ERP implementations. This is especially true for mid-sized businesses.
Successful implementers recognized early on that ERP implementations were more than an IT project, they were a business project. Yet, involving line of business managers, key performers and integrated teams only partially improved success rates. Successful businesses now consider a third aspect in ERP implementation to achieve another quantum of improvement. Change management, when balanced with IT management, and business management, aligns the project so it meets future objectives, rather than being obsolete when the future arrives. Balancing these three dimensions requires a rigorous governance model and defined CEO oversight.
Governance is a "framework for decision rights and accountability to encourage desirable behavior in the use of IT" states Peter Weill at MIT's Sloan School. All ERP implementations are large relative to the size of the business and they require many decisions. Therefore, it is likely your existing IT governance model is too unwieldy for an ERP project. A new governance model must be defined that evolves through three distinct stages of the ERP implementation.
ERP projects should be divided into three distinct phases:
- start up yielding business value and software and partner evaluation and selection
- configuration including procedure documentation, functional testing, process exception handling and integration testing
- deployment and go-live
Executive management is responsible for defining initial ERP project governance. A governance foundation is always the same; who has the authority to decide what, how is accountability assigned and what communication mechanism is in place to measure value so that the project is permitted to move forward. As the project moves forward, ERP project governance needs change as project members require that accountability be moved as the project comes into contact with workers deeper in the organization.
Start up governance addresses strategy and defines the scope of the project. Is ERP a strategy to cut costs, improve processes, expand or open new channels, or reduce risk related to obsolete software and hardware? The executive suite must communicate this to the project leader and business unit managers and preferably to every knowledge worker in the company; repeatedly. Project teams without a precisely defined purpose often exhibit a guessing behavior attempting to define what upper management expects. They often deliver more than is required, often nice to have functionality, but at a cost in both time and money.
Early and frequent communication uncovers misalignment. At one company an executive performance goal was to consolidate back office functions. This project was not communicated to the ERP project team due to "sensitivity." Four weeks before deployment only two of nine people familiar with the new ERP processes were still engaged in the consolidated department. The executive suite was responsible for this misalignment.
Governance is evidenced by executive behavior that re-iterates accountability and purpose, via downward communication. Start up governance grants authority to a project leader and the CEO communicates this to line of business leaders. Project quality ultimately is determined by this message. Integrated software requires interdepartmental cooperation. Start up governance is complete when financial analysis and selection authority is assigned. Typically the CFO demands ownership of the financial analysis. The project team is given unambiguous authority for managing selection. Selection authority and scope criteria must be defined before line of business employees are involved in the evaluation.
Configuration governance primarily involves project team communication. If the CEO challenges the project team with difficult questions interdepartmental or intrateam fiction may be exhibited in their behavior earlier in the project. Challenging questions might include what criteria determine when software can be modified? Are there processes that cannot be changed; what are the criteria? How do you measure improved processes? Can the project be bid as a fixed cost implementation? These challenges ultimately define project team authority and must be communicated throughout the organization.
Configuration governance also defines the working relationships between the project sub teams. Clearly defined departmental communication channels are essential. Expected time frames for resolving questions must be also defined. The project team defines expected time commitments. Line of business managers, if they are not on the project team, must be expected to operate without key performers for these periods of time. Early stage ERP deployment is often a question of how will process holders recognize and handle processing exceptions.
After all process teams prove that the functional units work as documented deployment governance starts. The CEO and the project leader start moving governance authority to business unit managers. These managers refine processes verify exception handling and prove to their satisfaction that the training plan has been successful. Deployment considerations were planned by the project team. This plan includes conversion acceptance, hourly implementation schedules, resource availability, go/no-go criteria, etc. Authority for implementing this plan remains with the project leader who is accountable for how deployment will be structured and who and has the authority for prioritizing and resolving issues. But the CEO must re-iterate to the line of business managers that they are accountable for a successful deployment not the project team. Deployment governance remains in place until the system is in stable production at which time the original IT governance model is adjusted to accommodate the new integrated environment.
Donovan O. Dean is President, Rx for ERP, which is a consultancy specializing in Enterprise Resource Planning startup. www.rxforerp.com
