Selecting and Implementing a Client-Server Based Integrated Materials (ERP) System
Edward M. Lundeen, CPIM, C.P.M.
Edward M. Lundeen, CPIM, C.P.M., Project Manager, Phelps Dodge Mining Company, Phoenix, AZ 85004, 602-234-8596 or 505-537-4381 email@example.com
84th Annual International Conference Proceedings - 1999
Abstract. While many materials professionals use automated materials systems on a daily basis to perform their work, few will likely have the opportunity to select and implement such a system. The following is written and targeted towards those practitioners who may be considering or are involved in such a selection and implementation process.
Opportunities. The potential to error in a major system selection and implementation is high while the likelihood of an error free selection and implementation is less likely. The opportunity, therefore, is to minimize decision and application risk by gaining advance knowledge of such processes and events. Gaining additional knowledge is no guarantee of success but it does reduce the risk of failure.
Objectives. To educate and inform any party who may be interested in either replacing an existing legacy system or in implementing a greenfield project.
Overview. We were happy with our Purchasing, Stores and Inventory system. It was not susceptible to a year 2000 (Y2K) defect and was functionally robust, offering many features that were practical and usable. The fact is, we were so happy with what we had that we failed to consider what was available in the marketplace and hadn't stayed abreast of the changes that were transforming the information technology industry. We were asked by a senior manager to attend a product demonstration and were surprised to see the new technology that was available that would allow us to manage our business more intelligently... it only required time and money to move forward (and lots of both).
The problem statement we were attempting to solve was:
- How can we fundamentally change the manner in which we manage our business?
- How can we more effectively:
- Reduce cycle times,
- Reduce and/or eliminating paperwork,
- Streamline our processes (work effort, paperwork and approvals),
- Empower employees involved in the process,
- Reduce, minimize or eliminate selected inventories,
- Increase "wrench time" or effective work related activities,
- Decentralize processing, data and storage,
- Provide information at the point of need, and
- Provide materials at the point of use.
Process. The steps we employed in our selection and implementation process (herein referred to as "the project"), while not without error, resulted in a successful project and final product. The steps, identified in outline form, will be detailed in the subsequent passages, as follows:
- Process mapping
- Business process re-engineering (BPR)
- Development of requirements document
- Request for proposal/Bid
- Software selection
- Develop project plan
Process mapping typically involves schematically identifying the steps, activities and interrelationships associated with performing a specific task (this is usually done by drawing or "mapping" the steps on paper or via a PC based program). For example, drawing a map of the steps that a requisition takes from recognition of need until the requisition has been satisfied, either by a purchase order or, possibly, by cancellation of the requirement. This process, while time consuming and somewhat monotonous, serves as the basis for all that follows. It is important that all of the "current states" or processes that may be modified, replaced or affected by the new software be mapped during this phase of the project.
Business process re-engineering involves taking the processes that were mapped in the previous step and looking for methods to streamline, minimize, enhance and/or modify the processes into the desired future state. This might be labeled as what we would like the world to look like if we could design (or redesign) it today.
The requirements document is the listing of features, elements and functional specifications that will be required of the software in order to support our future or desired state with the new system we intend to purchase. This assumes a perfect world exists which, while not realistic, provides a starting point for our comparison and analysis of software packages (gap analysis).
The request for proposal (RFP) process is believed to be straightforward for this audience and will not be detailed here.
Software selection is one of the more difficult pieces of this process and the results (from an effectiveness or correctness standpoint) may not be known for some time after the selection. The best analogy for selecting a software package isn't much different than selecting a spouse. This will be a partner for an extended period (possibly the balance of your career) and may have significant ramifications as to your organization's future earnings, expenses and profitability. The software selection process typically compares the RFP and the requirements document as it relates to identifying and assessing gaps relative to what your needs are versus the supplier's product offering. Theoretically, the supplier whose product offering has the fewest gaps (in the analysis) tends to be considered the best"fit". Practically speaking, all requirements are likely not equal in value or necessity, thus a weighted approach may be more apropos to give credence to those elements that have greater perceived importance than others do. The software selection process likely will/should involve extended product demonstration events (sales demos and customer driven or directed demonstrations) as well as customer visits to installed sites and conversations with current customers of the product(s) under consideration. Additional time spent in this area should be viewed as a major investment in the decision process, not as "non-productive" time. Finally, don't allow yourself to be rushed into a decision based on sweetened offers from the software providers as is frequently their practice. Note: typically the closer to the end of a calendar quarter and/or fiscal year for the software supplier, the better the commercial inducements that will be offered to motivate your decision.
The project plan may have been developed on a preliminary or macro level prior to initiating the process mapping activity, however, until a software selection is made it will be very difficult to finalize and detail your project plan. The plan is best developed in concert with the resource(s) that will be providing your integration and/or professional services activities. This plan serves as the business road map detailing critical events, milestones, dates and budgetary elements relative to the overall project.
A key consideration is whether separate project facilities will be established where all primary project activities will take place. Critical to this decision are issues such as having an isolated network environment where the software can be loaded and tested while employing client data. A segregated environment may be needed to: conduct data development related work; test point releases, patches and upgrades prior to implementation; train employees; and, run process simulations to validate the software relative to your intended BPR effort. You may discover there are inherent deficiencies between how you expect the software to work and how it actually works thus requiring process workarounds.
The data component of this project is probably one of the 2 most critical elements (after software selection). Mapping and converting data fields from your old system(s) to the new system are relatively straightforward. Defining new naming conventions and developing appropriate parent-child hierarchies and "scrubbing" the data to appropriately fit into these fields is time consuming and critical to the end product. In fact, we didn't get it right the first time and have had to revisit some of these issues more than once. Developing a data strategy and then rigidly adhering to it during the data building and scrubbing process is paramount to a successful project. The data strategy should be thoroughly discussed, defined and agreed to with the integrator and/or professional services provider prior to the initiation of any work relative to this aspect of the project.
While not necessarily a mandatory step (but an extremely valuable one), running a business simulation by employing the software, converted data and business processes prior to initiating end user training has monumental value. This step allows an opportunity to validate your business processes relative to the software logic to determine if there are any processes that are unsupported by the software and to identify if process workarounds are required. The process workarounds can be identified, detailed and tested during this simulation. Finally, the simulation may result in identifying deficiencies or defects in the software that were previously unknown.
While all process steps in the project implementation are important, training is the second most critical element, after data. The ability to effectively and efficiently move into a production environment is dependent upon the end user's ability to successfully navigate and employ the system. We discovered training to be the critical link in this process. Our experience (given the specific system we purchased) required 3.5 days per person, on average, to learn the basic tenants of the system. Given the number of personnel that required training and the number of available classroom seats that were available on any given day, we started training roughly 6 months prior to our first implementation. This was problematic as those employees who attended the earliest classes required refresher training prior to implementation. Knowing what we learned through this process, we would have been well served to have created an "electronic playground" for those who attended classes early where they could have continued to hone their skills in an environment that wouldn't affect the ongoing development work (i.e. create a "test" instance and database for practice). Also, we learned that employing a "train-the-trainer" approach (using your own employees to train) was a cost effective approach that netted better results than employing contract trainers.
The actual implementation process was one bound by working extreme hours to provide end user (internal customer) support as they labored their way through the learning curve of the new system. We discovered that having sufficient resources to cover all of the respective work entities (i.e. purchasing, stores, accounting, shops/crafts, management, etc.) was a challenge. Fortunately, by the time the actual implementation took place, the core team that started the project was intimately familiar with the application and rarely discovered new or previously unknown problems. Subsequent roll-outs of the product to additional sites took on somewhat of a repetitive flavor, however, our implementation team became much more proficient at the required activities.
Post implementation activities are centered around several events, such as:
- Resolving software problems and deficiencies
- Resolving process issues with internal customers
- Planning for future releases and upgrades
- Providing operational support for internal customers
- Conducting a post completion analysis
- Developing internal user groups
- Refining the business processes developed during the BPR phase
Points for consideration. During the various phases of a project such as this you will discover a significant number of opportunities to make decisions critical to how your project will develop or be finalized. Following are some issues for consideration:
- Does your software supplier have a documented and proven implementation methodology?
- How many other customers have already implemented this product?
- What is the expected implementation time required from software selection to go-live?
- Who will provide implementation/integration services? Will it be the software supplier or a third party integrator? Are there qualified professional services groups available to provide the level of support needed? Is the product widely enough known that third party integrators are available without having to pay for their learning curve?
- How many application program interfaces (APIs) are going to be involved? What will it cost to integrate these APIs? What will be the implication on future software upgrades and/or releases? Note: APIs should be identified during the process mapping phase.
- Will we stay with baseline software or do we plan on customizing the application (be aware of serious implications for future releases)?
- How will we manage the training component? What will it cost to train our end users? Will we employ a generic approach to training or will we use a company and/or industry specific style? Do we have sufficient facilities to conduct training? Have we calculated how many training man-days will be required to complete necessary training prior to go-live (suggest "backing into" the requirements to determine start dates, number of seats and facilities required)? How will we maintain learned skills for those first taught if they will not be immediately applying their skills (playground concept)?
- Are we buying software that doesn't currently exist (vaporware)? Are we buying software that is unproven and/or untested wherein we become a beta partner for potential bleeding edge technology? Are we willing to be a beta partner? Are we willing to invest potentially significant sums of money that may not directly contribute to our implementation efforts?
- What are the pros and cons of being a beta partner?
Pros - possibility of influencing software design and direction, learning experience in advance of general population, advance copy of release/product, potential favorable relationship with supplier
Cons - investment of money that may not result in any direct benefits, potential unfavorable relationship with software supplier as you may be perceived as an antagonist, unknowns as to whether failures are software related, process related, infrastructure related or knowledge related (don't understand how the software should work)
- How much historical data should we convert to the new system? What is the cost-benefit of converting all of this data versus some versus none?
- Do we have sufficient information services staff to support our new system?
- Is our IS infrastructure sufficient to meet the need of the system? Do we have sufficient servers, PCs, network bandwidth, network connections, network able components, etc.?
- Has your software supplier provided you with a supported configuration document? Have you checked with any other customers to determine if the supported configuration is valid and realistic? What type of performance metrics (i.e. response time and data storage requirements) are other customers experiencing. Is the application scaleable?
- Does the product have archiving capabilities to offload old records to minimize data storage requirements?
- Has the software supplier provided you with a year 2000 (Y2K) certification and have you personally verified that the product is Y2K compliant?
- Have you checked the references of your professional services provider? Is the professional services organization capable of providing the maximum number of consultants you may require? Are they willing to allow your organization to select and deselect consultants from their resource base?
The list of questions can (and would) go on ad nauseam if space permitted, however, the foregoing is merely an example of the types of opportunities you will have for consideration.
Conclusion. The undertaking of the selection and implementation of a new or replacement materials system may best be described as a process more than a project. There are obvious and logical steps that can be followed (as described herein), however, following the steps does not guarantee success any more than deviating from the steps guarantees failure, it doesn't.
The most critical elements for success in this venture are:
- Select a business partner you are willing to work with for the long haul.
- Select a product that meets the majority of your needs and requirements in order to avoid product customization and regression from your process needs.
- Develop a project plan that is realistic and workable. Allow buffer time for unknowns and don't be afraid to make realistic adjustments to the schedule. Conversely, the schedule can't be a moving target. Be realistic and practical.
- Ensure you have developed a budget that doesn't cut corners. You will be amazed at how quickly you will spend project money and at how many unknown and unanticipated items will creep into the budget.
- Professional services alone can make or break your budget. Find a qualified and worthy professional services and/or integrator partner for the project.
- If the supplier can't demonstrate the functionality of the software assume they may never deliver it. Only be willing to buy (and pay for) that which you can see and personally demonstrate.
- Select a qualified and committed core team to work on your project. Identify and recruit the best resources your corporation has to offer.
- Constantly think outside the box.
- Have fun on the project.
- Reward exceptional behavior.