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 firstname.lastname@example.org
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:
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 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:
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:
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)
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: