Successful MIS Implementation

Integrated Management Information Systems (MIS) have been around for over 40 years, having evolved from simple ledgers and stock control to complex ERP. Over that time they have become considerably more reliable and vastly more capable. They are now also considerably more expensive to buy and set up. The increase in computing power has led to a huge expansion in their functionality, data storage and speed of response. Sadly, the level of implementation success, when measured as being a positive impact on the bottom line, has not kept pace.

In the early days the groundbreakers were warned that implementing such systems was risky – nine out of every ten implementations failed. Forty years on it’s not a lot better. Now somewhere between 15% and 20% of companies implementing or re-implementing claim they have realised measurable improvement, or expect to in the near future. We wonder why the rest would invest that much money without demanding a return.

Understanding why the success rate remains so low has been the subject of numerous surveys over the years, many coming to the same conclusions. But despite the helpful analysis, little has really changed. In attempting to answer this MML has distilled the experience gained from over twenty years spent helping companies to overcome the difficulties they have faced post-implementation. The frustration for us and for our clients is that putting it right after the event not only adds cost, but extends the time scale before any real benefit is delivered.

We believe part of the problem is that although the software vendors have used the survey findings to refine their implementation methodologies, many of which are now almost identical, they still contain two fundamental gaps. Few if any focus any effort on:

• developing an understanding within the business, especially at the top level, of the fundamental principles and concepts that their system will use to drive the business;
• helping the company to develop a concrete, high-level description of how the business will work once the system is in, that uses its capability effectively.

Our implementation approach may therefore appear to be very similar to that proposed by most software vendors. The differences, however, are significant and are derived from practical experience of what works. By filling these two gaps it significantly reduces the risk of failure. It also cuts time-scale. We have used this approach very successfully to achieve problem-free cutover in six or seven months, with benefits beginning to flow almost immediately.

The sections below set out the main elements of the approach, which is based on the following precepts.

1. Systems are there to support the business, not vice versa.
2. For a business to be effective its processes must be designed to work effectively.
3. The Executive owns the specification of that design and is ultimately responsible for its effective operation.
4. The managers are responsible for the detailed design that delivers the specification and for the management of the resources needed to make the process work.
5. IT’s role is to provide and maintain the systems and infrastructure necessary to support the detailed processes.

Business Imperative

Purpose: Articulates the factors motivating the change. Needs to be critically and strategically important to the company rather than just “nice to have” if the project is to be driven to completion and achieve it’s objectives.

Business Process Design Spec

Purpose: Translates the Imperative into a formal, documented specification for the way the business will work once the change has been effected. Ideally should mirror the process for specifying a product and should contain:

• a one-page high level process flow diagram;
• a set of detailed policies;
• defined quantified objectives.

This then provides a framework for the development of the detailed process design.

Detailed Process Maps

Purpose: To provide a fully integrated set of drawings or maps that explain how the business processes will work. It needs to demonstrate how the process will meet the requirements set out in the process specification; define what system functionality will be required to support the new process, and the related configuration options, and provides the basis for the development of process test scripts and skeleton work instructions. Provides a mechanism for process change control.

Process Test and Validate

Purpose: To ensure that the processes that have been designed are complete, robust and will deliver the expected outcomes. Testing is used to select the most suitable option for the configuration, where several exist, and to refine the process model, especially in relation to the handling of exceptions.
Validation is used to challenge the process and prove that it is robust. It can also provide a useful training opportunity.

Cut Over

Purpose: To populate the new system with data. It provides an opportunity remove obsolete data from the database and to resolve outstanding queries, so that only clean, accurate data is loaded into the new system.

Project Sponsor

Role: Project champion who “owns” the project, understands it’s importance to the company in terms of the imperative and has the vision to recognise how the benefits can be delivered. Protects the project from both internal and external threats. Usually chairs the Steering Committee.
Position: Director or Senior Executive

Steering Committee

Role: Approves and “owns” the business process specification and cost justification. Monitors progress of the project against the plan, ensures that adequate resource is made available and that conflicts of priority, especially between the project and the demands of the business, are resolved. Approves final version of detailed process maps and is the authorising body for subsequent changes.
Composition: Functional Directors and Senior Executives plus Project Manager, usually meets monthly.

Project Team

Role: Prepares, “owns” and delivers the project plan and develops the detailed process design in line with the process specification and checks this for completeness. Presents final design for challenge testing and approval. Sets-up, tasks and monitors the task teams for process mapping, process testing and cutover. Also responsible for developing outline process instructions and training plans.
Composition: Full time Project Manager with full time and part time key functional users. Meets weekly.

Task Teams

Role: To complete the tasks set by the project team; to define the detailed process maps, prototype testing, validation testing of the processes, cut-over planning and cut-over.
Composition: One member of the Project Team plus selected functional representatives, depending on the task. The membership may change over time as most tasks have a much shorter time scale than the complete project. Often meet several times each week, but usually for only part of the day.

Users

Role: Mainly involved with process validation testing and loading data at cutover. Play an important part if asked to participate in challenge testing.
Composition: Anyone from the user community.