Featured
Author - Joseph
J. Strub
- December 23, 2003
Introduction
Due to its complex integration issues and cross-departmental impact, implementing a large ERP software package is a formidable process. Good project planning, with its key events such as software installation, training, and data conversions, can guide a team to a successful and smooth "go live." Piloting the software is one of, if not the most, critical event in the project life cycle.
Piloting or conference room pilot (CRP) is the process by which you put the software through its paces in a pseudo production setting to verify that it can support the standard business practices and routines of the company. I find it amusing that, if you interchange the last two letters of CRP, this may be what you have to do if you don't do a complete and thorough pilot. However, if done well, the pilot will uncover issues before they become problems, instill confidence in the users that the software is ready for prime time, and make the "go live" uneventful and a cause for celebration.
This
article examines five key attributes or characteristics of a success pilot,
namely:
- Pilot Segmentation
- Prep Work
- Control of the
Pilot
- Restartability
- Vote of Confidence
For each attribute, this article discusses actions to complete and pitfalls to avoid. Hopefully, by paying careful attention to critical aspects of piloting, the project team can avoid disappointments further in the project life cycle.
Pilot Segmentation
You don't have to be an aeronautical engineer to know that you don't build an entire plane and then test it. You test individual components the engine, instruments, electrical systems, then assemble the plane, and test it as a complete integrated unit. Similarly, in ERP software, you have components or process such as order entry and accounts receivables; purchasing and vendor payments; and production orders and manufacturing. Proper pilot segmentation means that you test components individually and satisfy yourself that they meet the business requirements. As I tell my clients, when piloting the components, you can afford to be selfish and ensure that your particular area of the software works as intended.
Once all of the components are proven to work individually, only then can you pilot the software in an integrated manner. If your component piloting is thorough and at a sufficient level of detail, any issues discovered in the integrated pilot should be ones dealing with the formatting and passing of data from component to component. This makes problem resolution easier and more efficient.
Prep Work
Before the plane takes flight, a lot of prep work precedes the takeoff. Likewise, to pilot ERP software, particularly in the integrated pilot, preparation is required on several fronts. Since piloting the individual processes is more on-the-job training and parochial, I want to concentrate, here, on the integrated pilot.
First, the legacy data must be converted into the ERP data repository. Users find it easier to relate to examples, calculations, and results, if they are using data that they have seen and worked with before. Comments like "I know that this customer requires special credit terms" or "this product uses a custom routing through production" promote familiarity and develop better insights.
Secondly, all customizations must be unit tested, accepted tested, before they are available for integrated testing. This also includes reports. Just as with data, users find it easier to view results from the integrated pilot when viewed in a manner that they are used to working with. Also, what better way to shake down reports? Run them!
Finally, realistic scenarios, with predictable results, must be prepared ahead of time, and not on the fly, to ensure that all cases are included and tested. Many of these cases are extracted from the process pilots. I usually ask one of the process leaders, like order entry, to start the ball rolling by preparing test scenarios. A good rule of thumb is to start simple and gradually increase the complexity. For example, start simple; start with an order of an existing customer and for products that are in stock. Then, try this order for a new customer. Then, try a more complex order for an existing customer but for a product that is out-of-stock but you do have the raw materials to make more. Then, place an order for an out-of-stock product but the raw materials have to be purchased.
The scenarios prepared by the order entry lead are then passed to the other process leaders, who will augment scenarios with conditions of their own, and develop new scenarios specific to their area of interest. The general idea is to crawl before you start to walk and run. You will find the users will not be overwhelmed and, as you will read later on in his discussion, scripted scenarios come in handy. Prep work consists of having converted legacy data, having tested customizations and reports, and having prepared scripted scenarios.
Control of the Pilot
While a license may not be needed to pilot software, there needs to be a clearly defined point of control and a person in charge. This can be useful in the process pilots and is usually accomplished by process-specific business conditions and the team leaders. However, it becomes even more important and essential in the integrated pilot, where diverse interests must be combined into a single goal, namely proving that the software can support the business.
The control point is the script of predefined and predetermined scenarios, detailing a step-by-step process to be followed. The person in charge should be a non-team leader whose sole mission is to keep the project team on its stated course. Too often, the integrated pilot quickly digresses into dealing with exceptions instead of concentrating on the basic transactions of the business. Let's face it, the basics account for more than 90% of the activity of the business. Good, well thought out scenarios will ensure that the exceptions are covered after the standard, straightforward transactions are successful.
It may be helpful for control to set up a conference room with a single workstation attached to an overhead projector to conduct the integrated pilot. This will avoid other team leaders going off on tangents and ensure that everyone's attention is focused on the scenario or issue at hand. Also, do not be disappointed, if little progress is made on the first day. The integrated pilot is like the plane moving down the runway, building momentum until it lifts off.
Restartability
You would expect the process pilot to go through many iterations before the process team is comfortable and is satisfied that a particular process can satisfy the requirements of the business. No matter how thorough you may have planned the integrated pilot, it is likely that this pilot, too, will go through several iterations. Usually, the integrated pilot will get so off course that the only way to make headway is to reassemble the pilot environment. This means returning the data, files, and settings back to their original state. It also means to be able to do this routinely. This is what is meant by restartability.
Take a snapshot of the pilot environment, have it loaded into a separate region, and configure dedicated workstation for access. Consider yourself successful if, on the first day of the integrated pilot, you only get through a couple of the simple scenarios. Leverage this fact as to why the team leaders need to devote the necessary resources to this important event of the implementation.
Vote of Confidence
A
successful pilot will instill confidence in the user community. The familiarity
of using data and reports that they have seen before will serve to reinforce
their confidence. Consequently, the last task in the ERP software pilot is the
vote of confidence. I literally mean a show of hands. Ask the process team leaders
in a group setting if they are comfortable with "going live."This
gives them a vested interest in using the software in a production environment.
Obviously, this does not mean that there won't be any speed bumps in the road.
And bribes are not allowed. If the vote is not unanimous, it's back to the pilot
drawing board to resolve areas of concern and, within reason, to make everyone
comfortable with using the software to support the business.
Summary
The piloting of ERP software can be a difficult segment of the overall implementation. However, if properly planned, executed, and managed, this single event can deliver benefits or identify areas where additional work is required. As is for a plane in flight, it is better to make these decisions before you pass "the point of no return" and are forced to institute midcourse corrections.
About
the Author
Joseph
J. Strub has extensive experience as a manager and senior consultant
in planning and executing ERP projects for manufacturing and distribution systems
for large to medium-size companies in the retail, food & beverage, chemical,
and CPG process industries. Additionally, Mr. Strub was a consultant
and Information Systems Auditor with PricewaterhouseCoopers and an applications
development and support manager for a Fortune 100 company.
He
can be reached at JoeStrub@writecompanyplus.com.