Phase two: Best practice methodologies for system implementation
Now that the best EAM/ CMMS application for your business has been selected, the deployment phase begins. But an EAM system is not a plug-and-play application. Will you miss out on some real operational savings? Will the data be clean enough to provide value in a production environment? Will processes be tailored to match the new system, or will they be optimized to improve business? Is the vendor knowledgeable about your specific industry or regulatory requirements?
Bringing a software application live is very different from implementing a business solution. A successful implementation depends on a precise, cohesive flow of multiple discrete activities such as configuration, training, and integration. This article discusses best practice methodologies that will help get the most out of an EAM/CMMS implementation.
The project team
Ideally, the team who selected the system will take the leading role in its implementation. This team includes skilled representatives from each department that will be affected by the new system. They gained invaluable knowledge during the process of evaluating the current state of the business, identifying needs, assessing alternatives, and selecting the preferred solution. To hit the ground running, this is not the time to pull these experts onto other priorities.
Instead, start with this team and lean on vendor or consultant resources for support. Fortify the team with additional in-house personnel who are capable of facilitating the implementation. An eagerness to learn and deep knowledge of specific business functions will help ensure this project is a success.
Make it clear that it is an honor to be selected for an implementation, not a penalty. The project team will be recognized as experts by the time the implementation is complete, not only by their peers but by management (read “job security”). They will have amassed a wealth of knowledge about not only the application but the new business processes and data behind the product. Just make sure the team is not overly burdened by their usual job responsibilities while they concentrate on improving the business.
Once the project team is selected, the implementation kicks off with a major project planning event. During this event, roles and responsibilities, activities and tasks, and milestones and constraints are charted within the preferred implementation timeline. Rather than starting from scratch, the vendor or implementation consultant can provide a template project plan that demonstrates the typical sequence of events and interrelationships between activities. The template also helps to ensure key steps are not overlooked. During the planning session, the baseline template will be tailored to the company’s specific circumstances.
The planning event involves a high level scoping of all implementation requirements. Key performance indicator (KPI) metrics are defined at the onset of the project and used to guide the intended project outcome. Time is allotted to assess gaps and define new business processes. System interfaces, data conversions, and custom extensions are considered, as well as system and hardware configuration. A preliminary plan for employee communications and training is developed, as are functional and system testing. Each of these components is then factored into the implementation project plan. This is a critical step; many project failures and delays can be traced back to poor upfront planning.
Reconciliations are performed to unveil the gaps between the current and future state, and to adapt business processes and the software configuration accordingly. Even the most configurable software applications can have gaps between supported and desired work processes. If automation is not possible, you may need to modify a process or incorporate an extension to the system. An experienced consultant with industry expertise can help arrive at such decisions quickly and avoid pitfalls that might otherwise need to be revisited later in the implementation.
As a starting point, the vendor or consultant should be able to provide a template business model. This model should incorporate best practice processes, benchmarked from the industry, which can be tailored in a workshop setting based on the software’s capabilities and the company’s unique business requirements. The model provides a launch point, as opposed to a clean slate. It expedites the reconciliation of software and process gaps, and minimizes the risk of carrying legacy system inefficiencies into the new environment.
During the hands-on reconciliation workshops, the optimal software configuration is defined and documented, the preferred business processes are validated within the new system, and legacy data quality issues are pinpointed.
Configuration decisions from the reconciliation workshops feed directly into the technical implementation activity. To a great extent, these activities can occur in parallel with oversight from the project manager. The functions are distinct and there are few overlapping constraints, but a high degree of communication is essential to keep the project on course.
Baseline configuration. The configuration defined and documented as a result of the gap reconciliation workshops now comes to life in a baseline system configuration. This configured system will be used to test conversions, other data preparation, system interfaces, custom extensions, KPI metrics, and reports. The baseline configuration also will be used as the basis for system testing.
Data preparation. Depending on the scope and quality of data in the legacy system, you may decide to convert large data files such as equipment records, historical work orders, inventory, and purchase orders. Do not be afraid to archive historical records that have outlived their usefulness; it will speed up the conversion process. Another beneficial tactic is to segment static (rarely changing) data from dynamic data, and load it in advance in order to shorten the process of migration at go-live.
Minor data gaps or errors should be cleansed in the old system prior to conversion. Major data cleansing may be required due to differences in validation or data structures in the new system. Any remaining data files can be manually populated in the new system. Tools are available to automate large-scale cleanup, mapping, and migration processes in order to enable real-time conversions with minimal downtime at go-live. Have the database administrator ensure the new environment data is stable and properly tuned.
Metrics and reports. Reports are among the most overlooked aspects of a project. It is easy to want everything to look the same as it did in the old system, but that would defeat the purpose of the new system and put the project budget and timeline at risk. Odds are a lot of paper is being generated that is not necessary or not effective. The vendor or consultant can help define and prioritize reporting requirements, select a report writing tool, and develop the reports.
The goal in the new system is to ensure management views and reports reflect the KPIs defined early in the project. The multitude of reports generated in the old system must be analyzed for current need. Where possible, the system’s canned reports should be used, but where information gaps appear, custom reports and views can be developed.
If multiple plants run similar reports, a new standard should be defined. With proper planning, the overall number of reports could decrease as much as 60 percent in the new system. Without proper planning, you could end up scrambling to provide management information.
Application integration. Interfaces must be built to enable data sharing between the EAM/CMMS and ERP or other third party systems. The process review, reconciliation, and configuration materials developed previously can be combined into a process integration model. This model will help decide whether the vendor-supplied integration points or automated integration tools should be used, or a custom integration developed.
Where the touch points occur can have a significant impact on the cost, complexity, and reliability of the interface. This can be considered the high blood pressure of the implementation. Without effective monitoring and management, it can easily become the silent killer of a project. The vendor or consultant can provide guidance in interface strategy and design.
Custom extensions. It is highly preferable to avoid customizations. However, an application extension may be required if baseline functionality or workarounds do not satisfy business requirements. During custom extension design and coding, it is important to provide the maximum benefit without compromising baseline integrity or the ability to apply future upgrades.
Once all technical activity is completed, it is time to test, verify, and validate the new system in a controlled test environment. Integrated system testing verifies all software and hardware is functioning properly throughout the enterprise. This includes all workstations, network and printer connections, and interface compatibility.
User acceptance testing validates the functional use of new system processes and data, including the business rules, software configuration, and interfaces. Test plans and scripts can be developed from the new system process flows, and each process scenario should be tested in excruciating detail.
The third major test is sometimes overlooked and yet critical to optimizing system performance. Load testing simulates a large number of concurrent system users so that performance tuning can occur before go-live. Automated tools can simplify load testing.
The project team is now well-versed in the new system, and as go-live nears it is time to introduce the end users to their new system. Training should occur shortly before go-live and only after a thoroughly tested, solid training environment with real data is available. Users need to learn how to perform specific procedures in the new system—not just how to use the tool.
Power users and key roles such as planners and schedulers do not have a large turnover and training is likely to occur only once. Lean on the vendor or consultant for these lessons. Develop internal trainers for system overviews and general functions like work requests and material requests required by a larger plant population. Computer-based or Web-based tools are gaining in popularity for infrequent users and refresher training.
The vendor or consultant should have industry-specific, role-based baseline training materials that can be adapted to your specific requirements. The test scripts and process scenarios developed previously can be leveraged to expedite training material customization.
A vendor or consultant can provide training classes for you, or can train your trainers. Alternately, members of the project team may be willing and able to conduct the training sessions. Do not ask them too early in the project; they will warm up to the idea as their knowledge base strengthens.
Start-up and roll-out
The project team’s work comes to fruition during start-up and roll-out. With all hands on deck, the production system comes alive and users officially transition to the new system.
A production walk-through conducted the day before go-live serves as a final check for log-ins, system access, and printer connectivity. A cradle-to-grave scenario performed at the workstations of key users eliminates the “gotchas” that can occur when plant environment factors differ from the development environment.
The full project team should be on hand for the first several days to help smooth over any issues, and a smaller team available for another week or so. A process for logging, prioritizing, and responding to help desk issues will help gain the trust of the end users.
The project team does not disband once the system goes live. They should work as a team to discuss lessons learned, and progress to the next phase of system optimization and continuous improvement.
From start to finish, throughout the implementation, it is vitally important that the project work not be hidden from view. Implementing a system in near-isolation generates fear and insecurity rather than respect. Instead, ongoing employee communications will generate excitement and help the future users of the system feel involved and assume ownership.
A steady stream of information should be supplied via signs, newsletters, or letters from executives. Benefits to employees and the company as a whole should be promoted. Feedback and suggestions should be encouraged. Each important milestone should be recognized and celebrated. A successful go-live is a great excuse to pat everyone on the back with a party. What a great way to begin an important new era within the company.
Future article in this series will discuss project optimization. The previous article was “Managing an EAM/CMMS Project—Phase one: An unbiased team approach to system selection.”
The processes that are part of the EAM/CMMS project implementation.