People who've been involved in deploying an ERP system often describe the process as complicated, lengthy, or painful. They know through experience that enterprise business software can be expensive to implement, challenging to learn, and difficult to fit to the unique needs of the business. With these types of experiences and descriptions, you might question, "Why do it?" It becomes clear that in order to embark on a project of this magnitude, a company must first carefully assess the business needs and goals that drive the project. Management must set, document, and agree upon these business goals before you select a structured, thorough methodology for business analysis and for implementation. Then, you can proceed through the steps of the methodology, always considering the business goals as project decisions are made. These big-picture goals, combined with a structured, thorough methodology, are your keys to successful deployment of an ERP suite.

Figure 1 will give you an idea of the phases in deploying an ERP suite.

Figure 1: This is the path to successful ERP suite deployment. (Click images to enlarge.)

Enterprise Resource Planning

By its all-encompassing nature, an ERP implementation affects business processes across the entire organization. A good ERP suite is designed to help your business identify, plan, manage, and control enterprise resources such as money, inventory, equipment, physical facilities, and people.

Whether it be in the order-to-cash process, the procure-to-pay process, supply chain planning, logistics execution, or financial/management reporting, it is obvious that no process is an island and no department works in isolation.
Consider the order-to-cash business process. This process involves everything from the original receipt of the customer order through credit checking, manufacturing, inventory, order fulfillment, and eventually receipt of money from the customer. So then, one of the challenges of an ERP deployment is that even a single business process will impact multiple departments within the organization. In addition, with the ever-increasing reach of Web commerce, many of the business processes addressed in the ERP deployment go outside the four walls of the organization.

Therefore, it is critical to consider the effects on all departments and business partners when setting a business goal. Every decision becomes a cost-vs.-benefit analysis. Often, you will find that the results of a decision may increase costs or efforts in one area and greatly decrease costs or increase benefits in several other areas. The big picture must be considered in all cases. This is not an easy task; it may involve several areas, and each area must talk with the others.

Overview of the Process

Once you have set and documented the initial business goals, begin a Fit Analysis. (See Sidebar 1 for a Fit Analysis methodology.) In this important initial step, you will analyze the business and assess the fit of the ERP suite to the business needs and goals. Because the business processes aren't performed in isolation, these discussions shouldn't happen in isolation. Involve all affected areas at the same time. It may come as a surprise, but when people from several areas are brought together to discuss a current business process, there will be lengthy discussions and possibly some disagreement, but almost everyone in the room will learn something. Additionally, if the tone is set properly for open discussion, the result may be a series of better ideas and process improvements (and some of these may have nothing to do with the ERP suite).

Another important result of this process will be to identify the gaps between current business processes and the ERP suite's standard functionality. This is where it is critical to have a project team and a decision-making structure already in place. Put simply, when a gap is identified, there are three choices: modify the process, modify the system, or modify both the process and the system. It is critical during these discussions to always document the alternatives considered and the reasons an idea was chosen or dismissed as this documentation will help you remember the details should you have the same discussion 30 or 60 days later. Figure 2 diagrams the steps involved in a Fit Analysis.

Figure 2: Fit Analysis is like putting together puzzle pieces.

When assessing the fit of an ERP suite to your company, the elements of the system and the company must be reviewed from the following three perspectives:

Master Files

• Does the database contain files and fields to hold data equivalent to the existing systems?
• Is the database structured appropriately to support data and transactions equivalent to the existing systems?

Functional Areas

• What functions are performed by each department?
• Do these functions exist in the new system?

Critical Business Processes

• What are the critical processes used to run the business?
• Does the system contain functions to support these critical processes?
• What is the fit of the system transactions to the critical processes?

There can be great overlap in each of these assessments, but reviewing the business and the system from multiple perspectives yields a more complete fit analysis and begins to highlight the gaps that procedural or system modifications must close.

The Fit Analysis process will yield several tangible results. The major result will be definition of the project's scope. The project scope is critical because you must develop a realistic estimate of time and effort required for the project. The scope will also define all of your critical business processes and document their flow through the organization. This knowledge is a great benefit to your organization, along with the inter-department knowledge gained from the business analysis discussions. Finally, the Fit Analysis provides the basis for the initial project plan, which will place the question of how to do this project into a structured context.

Once you've completed the Fit Analysis and created an initial project plan, it's time to begin the implementation process. Before getting into specifics of the implementation process, here are some helpful hints:

• Involve as many people as possible. People need to feel that they are being heard.
• Let the business goals be known. Dedicated employees will see the value in improving the big picture and may contribute good ideas during the process. New and better goals may even be created.
• Be honest about disrupting people's normal work. During the implementation process, much time will be required of key people. When the system is deployed, people will be uncomfortable and will be less efficient at their jobs for a period of time. Let them know this up front and listen to them as it is occurring (and try to help).
• Be firm about having the project team learn the standard functionality of the ERP software before deciding to change it. If the project team members don't know what the software can do, how can they make proper decisions that differ from the current process? Encourage system exploration (playing).
• Be flexible in considering whether to modify the business process or the software. Every business considers its process unique in one area or another. Often, there is the feeling that "we must continue to do it our way." The project team decision-makers must open their minds to the thought that there may be different ways to accomplish the same results.
• Keep a watchful eye on project scope. If you have set the tone properly for open discussion and new ideas, many ideas will develop. However, if every good idea is considered for initial implementation, the scope may get so large that implementation may never occur (this is bad).
• Test, test, test, and test again (and don't forget to test in volume).

The implementation process begins with initial configuration of the ERP suite. (See Sidebar 2 for more information about implementation methodology.) Generally, ERP systems have much flexibility across modules. Therefore, many decisions must be made and parameters must be set before the system can even be used. The results of the Fit Analysis provide your "best initial guess" as to how the system will be used, so this is a good starting point.

Once the initial configuration is done, the missing link to beginning to play with the system is data. Initially, manually insert some sample data that represents your business. This should include customers, suppliers, items, inventory, G/L accounts, etc. This will allow key project team members to begin the exploration process. This will also allow them to be trained in the standard functionality of each of the modules.

A common objection users raise during training is that they'd prefer to be trained after all the system function modifications have been completed. You must address this objection as soon as it is raised. As stated in the helpful hints above, be firm about having the users learn the standard functionality because it may help you provide an alternative to the current process. If they learn the system and play with it, and a software change is still required, then you have still gained because their experience and feedback has strengthened your decision and has provided the user with knowledge of the new system. Remind the project team members that user training on your final customized system will take place once the customizations and interfaces have been developed.

Once the base system training is completed, begin to further define the critical business processes. At this stage, you must get down to the full details of what is done, who does it, and how. Again, this is a process in which people from multiple departments must come together and communicate. The result is a blueprint of your critical processes combined with information about how these will be performed in the new system. One caution here is to stay focused on the critical business processes because if these don't function, the rest of the processes will not matter.

Following the full definition of the critical business processes, you can begin to develop the modifications and interfaces. The development process should include a formal document for functional specifications and testing requirements, along with areas for approval and additional documentation. This is where "scope creep" can occur very easily. Keep a watchful eye, stick to your goals, and document everything.

During development, other activities can occur, such as technical training of the IT staff, development of user procedures, redesign of forms and reports, etc. In the end, when all of these tasks are completed, it is time for system testing, approval, and some rework. For good measure, test more than you think you need to: Test variety, test unusual situations, test in volume. Following system approval, it's time for training users on your new system, establishing user procedures, and going live.

The keys for success in going live are face-to-face support, real-time validation of the results of each activity, daily review of issues and successes, assignment of responsibility for issue resolution, and good relationships between project team members and users in each department. Listen well. Show that you care. Try to help. Work together.

You can make it through this process. When you do, share the positive business results of the new ERP suite with everyone, but focus on the hard work and dedication of the people. Then reward them.

Bob Gleisner is a director of professional services for LANSA. In addition to managing a large international consulting division, Bob has written for industry publications and is a frequent speaker at the International LANSA User Conference. Bob has over 25 years of experience helping companies in a variety of industries perform successful ERP implementations. You may reach Bob at This email address is being protected from spambots. You need JavaScript enabled to view it..

Sidebar 1: Fit Analysis Methodology

This Fit Analysis Methodology has a few key guidelines that will greatly increase your probability of success:

1. Involve the proper functional personnel in analyzing each area. This will ensure accurate definition of current processes. No guessing allowed.
2. Document everything discussed, including questions to be answered, suggested resources for information, and recent changes to processes.
3. Obtain approval of all processes, forms, reports, and flows from functional managers, covering every area in the analysis.
4. Identify reporting requirements, future plans, organizational changes, etc. These should be planned for right at the start.

These are the steps in the Fit Analysis Methodology:

1. Identify the critical business processes.
2. Identify the critical forms and reports.
3. Document the business flow.
4. Analyze the critical business processes vs. the module functions. Create tables of specific transactions in a process, module functions to perform each transaction, specific forms and reports in a process, and module forms and reports to replace each form and report
5.  Identify critical master files. Make tables of key data elements and data element functions in the current system.
6. Identify potential modifications, including the modification description, the business purpose, the alternatives considered, and any other relevant information
7. Identify potential interfaces to/from other systems, including data, transactions, and the business purpose.
    

Sidebar 2: Implementation Methodology

This implementation methodology has a few key guidelines that will greatly increase your probability of success:

1. Configure the system based on knowledge from the Fit Analysis. This is your best initial guess as to how the system will be used.
2. Migrate master file data early and be prepared to perform several migrations based on knowledge gained when working with the system.
3. Get users trained on the base system and get them working with the system early. Even if some screens may be changed, they will still gain knowledge and become comfortable with the system, and they may learn things to improve their jobs or avoid modifications.
4. Use a Functional Specification document to define and approve every modification. This becomes your historical record of changes and important decisions.
5. If a modification may affect transactions or system flow, consult with an expert in the ERP suite to guide you through alternatives or an impact analysis.
6. When modifying or adding functions to the system, follow the standards of the ERP suite for naming, structure, and internal function documentation. Doing so will ensure consistency and ease of analysis and modification in the future.
7. Retrain users on the final customized system when modifications are completed and approved in order to ensure accurate system testing and approval. Build user procedures from this training.

These are the steps in the implementation methodology:

1. System Configuration
2. Data Migration
3. Base System User Training
4. Critical Business Process Detail Definition
5. Other Business Process Detail Definition
6. Technical Training
7. Modification and Interface Development
8. Final User Training on Customized System
9. Implementation