7 Steps to Rapid more Successful Implementations
The template approach to CMMS implementations is designed to provide a successful format to CMMS implementing, as well as a "jump start" to projects via the use of pre-defined, flexible practices and standards. These standards are able to be applied to any implementation and include the important points required to ensure the integrity of the maintenance delivery function.
By utilizing a template approach there is an ability to take firm control over the project from the very outset. Listed below are the 7 steps are that form part of the template approach. Each of the steps mentioned here are very broad and generally require a series of different management tools in order to achieve the ultimate goal. That is a rapid and successful project in full control of the client organization
This is Part Three of a three-part article that is based on the book, CMMS: A Timesaving Implementation Process by Daryl Mather.
Part One discussed the strategic importance of Maintenance Management.
Part Two covered the relationship between CMMS and ERP.
1. Define the ROI attainable, and therefore the budget
CMMS provides benefits in a variety of areas. These include availability, increase in planning and scheduling efficiencies, increased use of standardized information, advanced inventory management and a greater volume of information available for reliability and efficiency analysis of the delivery of the maintenance function.
It does need to be added that while maintenance history information has little to no effect on the determination of maintenance strategy development, it does have a very large effect on the application of processes of failure elimination or root cause failure analysis.
There are obviously many areas from which an accurate savings could then be calculated given some variables beforehand. Once the saving has been calculated we can then look at defining exactly what our budget may be able to be set at. A saving of $100,000 allows us a spending limit of $1,000,000 if we are intent on a 10% ROI for example. A very normal way of managing this step is to ask the vendors to provide an ROI figure, often in dollar terms, or percentage of saving, and often in a manner that is not linked to the actual purchase of a CMMS system.
As with all of the steps included in the template approach, part of the focus is to allow clients, or potential clients, some level of control over the entire process. This needs to begin with expectations of pricing and return on investment targets. Thus beginning the exercise of control from very early in the project.
2. Define the tactical goals of the implementation
The tactical goals are those that we also want to achieve apart from the ROI. However in order to better focus the overall implementation efforts there is a need to tie these with the overall ROI. It is important to note that finishing on time and on budget are not tactical implementation goals. They are givens. We do not at any time set out to fail in this crucial area.
For example, if one of the ROI goals is to achieve a 10% reduction in inventory levels. (Warehouse materials for maintenance in this case) Then we would be advised to address this requirement in the tactical goals. This may be expressed as increases in inventory rotations and of the service level of maintenance stock. These two indicators provide a good guide to creating processes for the efficiency and effectiveness areas of warehouse management.
Some other typical tactical goals of the implementation may include:
* increases in the estimations accuracy index
* increases in maintenance preparedness
* increases in planned and scheduled work
* better communications between the warehousing and maintenance departments
* better internal client focus from the human resources department to the maintenance department
* overall reduction in information management systems
3. Define the operating environment of the business
The operating environment of the business forms the base of the requirements statement we will need to define through this process. During this step we need to be defining what the physical and corporate environment factors are that affect our selection of system. Although somewhat tedious and, mos assume, straight forward. This is a pivotal part of our process.
Operating context definitions may include, but are definitely not restricted to:
* How many sites are we going to implement the system in ?
* What systems exist today that will need to stay in place? (Therefore what are the interfacing / integrating requirements?)
* What is the IT platform of our corporation?
1. (This point reveals something else in CMMS implementation that is of critical importance. Do not allow the implementation to become hijacked or derailed by interference from IT departments. As always we need to attempt to focus our attention on the overall benefits we will gain in the arenas of maintenance management, reliability of our physical assets and optimization of the use of our human assets.)
* How do our people work? (Rostering or shift arrangements, local or remote sites etc)
* What are our equipment classification types? (Many or few?)
* What are the current and future requirements for reliability focussed functions such as condition monitoring?
This area is obviously a large one and one that needs to be treated seriously as it forms the base, along with our ROI and cost statements, of our overall efforts.
4. Define the steps required to achieve the tactical goals
The diagram on this page illustrates a 6 step progression required to create implement proceed along the path to the realization of the tactical goals that have been created. In this particular case the goal would be the achievement of a planned state of maintenance management. (Steps to the Planned State of Maintenance Management) However all of these steps, not including the 5th step, are essential elements for the creation of any business process involving modern day CMMS systems. This is especially true for the areas of maintenance and engineering.
For example in the 5th step in a process of inventory optimization the equivalent step may be the creation of spares management policies.
This part of the process is, without doubt the most laborious and difficult area of any implementation template. This includes a vast number of areas all covered under the one heading. It is also the area where there exists the majority of waste in the implementation process. Many of the arguments are repeated time and time again in each project.
This paper includes a brief overview of what the terms of Business Rules and Work Processes; however a detailed approach to the steps required would need to cover all of these steps in this model. And as always, there are a number of common themes and principals that can be applied in each of the steps.
Business rules refers to a series of standards within the organization with regards to how we are going to manage maintenance in a generic and homogeneous manner.
Some example areas would include:
* Definitions of technical change management qualification procedures
* Rules on the prioritization of work, and how this is to be applied to the efficient management and programming of resources
* What are the maintenance indicators that will be applied
* How do we classify maintenance and work type.
There are a range of business rules associated with the implementation process. However as a general guide we need to be looking at those things that will be able to guide maintenance efforts in a generic sense over the entire operation. And these need to be created to suit the corporate goals of the organization.
Work processes refer to all the processes within the maintenance organization. These may include:
* Maintenance Planning and Scheduling
* Backlog management ? Technical Change Management
* Shutdown planning and execution systems
* Inventory management and dispatching systems
Some of the expected outcomes of this phase should be the development of role descriptions and role interactions, as well as the Work Order Life Cycle.
From here we are able to determine what are the business rule and process requirements of our system, as well as what are all of the roles those who need to interact with the system, and at what point their intervention is required. For those systems with complex authorization functions this step should also provide the basis for easily determining the authorities required by each role.
This step can be used, in its complete form, for redefinition of the maintenance hierarchy if this is deemed appropriate.
5. Define the Training Matrix and plan for Delivery.
As a consequence of the previous steps we should have arrived at a point whereby we have our roles of people who need to interact with the system defined, and via the Work Order Life Cycle we should also have determined when and what the interaction both with the system and in the process needs to be.
From here we are able to determine the training matrix for the implementation process. This is something that needs to be considered very carefully as it all too often leads to either the success or failure of the implementation effort. A crucial part of the training matrix is the development and deployment of training focussing on the processes we have defined in the previous step. This is without a doubt one of the key elements of CMMS failure.
Once the system is bought the training tends to focus on the functionality of the system, the recommendations of consultants and the half serious attempt to adapt existing processes to the new system. I have seen many times, and I am sure that I am not the only person, many processes created after an implementation. Thus often we are trying to adapt the organization to the requirements of the system instead of the other way around.
6. Define the management team and their required interactions and the Project Plan
There are basic rules to an implementation project; however most of these circle around the themes of involvement and empowerment of the implementation team. Depending on the size and scope of the project the design and interrelations of the team required will change markedly.
It needs to be accepted that the elimination of the software vendor's consultancy services is not an aim of the template process. However there is a need for greater industry wide understanding of how to manage these type of efforts. Therefore potential clients can be empowered with greater control throughout the entire exercise. At this point in time we should have the requirements document pinpoint accurate including: (among other points)
* Interfaces / Integration points with other systems
* Migratory data should be recognised and a plan created for the management of this
* Processes have been re-defined to ensure the implementation of best practice CMMS management processes. And the functionality requirements will have fallen out of this. (Graded in the typical "Critical / Important / Nice to have" style of rating)
* Training requirements have been defined and have been planned out in terms of which role require what training is required for what roles.
* Key implementation information regarding size of project, team members identified and other critical information.
So at this point we are able to both create the requirements document and draft a general implementation plan for the rapid and successful project, executed under the control of the client organization.
7. Constant reviews and measurement against project objectives and timeframes
This stage is better stated as "Planning for Success" the project does not end until the benefits are realized and the "new" maintenance focus is both implemented and embedded within the corporate culture.
For this reason there needs to be the usual raft of project controls during the project to mark critical stages and points of control. But there also needs to be the planning of post project points of control. In these control points we can realize self-audits of the system, of the project, of the amount of change that has occurred and perhaps future possibilities for dramatic change.
Conclusion
With the advances today in technology it has become obvious that there is a need for maintenance management theory and practice to catch up with the advances made in business management theory and practice generally. With a focus on the everyday processes that we use to implement and control reliability initiatives we will really begin to realize great leaps in company performance and cost effectiveness of maintenance; as well as realizing the vast array of benefits available from an implementation of reliability growth initiatives and applications of new technologies.
The current state of CMMS technology is at a very advanced level, in a lot of cases far more so than our ability to apply it. This tool has very strong and provable results, yet there are a great number of projects involving CMMS systems that end in failure and in cost and time overruns. The proliferation of vendors in this market, instead of driving costs down, has been driving them up. When this fact is combined with the common occurrence of CMMS "failures" it becomes obvious that the market should be buyer driven. Vendors need to be challenged and compared rigorously over pricing, after sales service and contractual guarantees. (Possibly even to the shared risk model recently adopted by some)
By using a template approach we are able to realize immediate benefits to the implementation process as well as to the delivery of the maintenance function. We may even be able to create the changes required without the purchase of a new CMMS by better utilizing what we have today.
SOURCE:
http://www.technologyevaluation.com/research/articles/cmms-templates-for-effective-implementations-part-three-7-steps-to-rapid-more-successful-implementations-16920/
The template approach to CMMS implementations is designed to provide a successful format to CMMS implementing, as well as a "jump start" to projects via the use of pre-defined, flexible practices and standards. These standards are able to be applied to any implementation and include the important points required to ensure the integrity of the maintenance delivery function.
By utilizing a template approach there is an ability to take firm control over the project from the very outset. Listed below are the 7 steps are that form part of the template approach. Each of the steps mentioned here are very broad and generally require a series of different management tools in order to achieve the ultimate goal. That is a rapid and successful project in full control of the client organization
This is Part Three of a three-part article that is based on the book, CMMS: A Timesaving Implementation Process by Daryl Mather.
Part One discussed the strategic importance of Maintenance Management.
Part Two covered the relationship between CMMS and ERP.
1. Define the ROI attainable, and therefore the budget
CMMS provides benefits in a variety of areas. These include availability, increase in planning and scheduling efficiencies, increased use of standardized information, advanced inventory management and a greater volume of information available for reliability and efficiency analysis of the delivery of the maintenance function.
It does need to be added that while maintenance history information has little to no effect on the determination of maintenance strategy development, it does have a very large effect on the application of processes of failure elimination or root cause failure analysis.
There are obviously many areas from which an accurate savings could then be calculated given some variables beforehand. Once the saving has been calculated we can then look at defining exactly what our budget may be able to be set at. A saving of $100,000 allows us a spending limit of $1,000,000 if we are intent on a 10% ROI for example. A very normal way of managing this step is to ask the vendors to provide an ROI figure, often in dollar terms, or percentage of saving, and often in a manner that is not linked to the actual purchase of a CMMS system.
As with all of the steps included in the template approach, part of the focus is to allow clients, or potential clients, some level of control over the entire process. This needs to begin with expectations of pricing and return on investment targets. Thus beginning the exercise of control from very early in the project.
2. Define the tactical goals of the implementation
The tactical goals are those that we also want to achieve apart from the ROI. However in order to better focus the overall implementation efforts there is a need to tie these with the overall ROI. It is important to note that finishing on time and on budget are not tactical implementation goals. They are givens. We do not at any time set out to fail in this crucial area.
For example, if one of the ROI goals is to achieve a 10% reduction in inventory levels. (Warehouse materials for maintenance in this case) Then we would be advised to address this requirement in the tactical goals. This may be expressed as increases in inventory rotations and of the service level of maintenance stock. These two indicators provide a good guide to creating processes for the efficiency and effectiveness areas of warehouse management.
Some other typical tactical goals of the implementation may include:
* increases in the estimations accuracy index
* increases in maintenance preparedness
* increases in planned and scheduled work
* better communications between the warehousing and maintenance departments
* better internal client focus from the human resources department to the maintenance department
* overall reduction in information management systems
3. Define the operating environment of the business
The operating environment of the business forms the base of the requirements statement we will need to define through this process. During this step we need to be defining what the physical and corporate environment factors are that affect our selection of system. Although somewhat tedious and, mos assume, straight forward. This is a pivotal part of our process.
Operating context definitions may include, but are definitely not restricted to:
* How many sites are we going to implement the system in ?
* What systems exist today that will need to stay in place? (Therefore what are the interfacing / integrating requirements?)
* What is the IT platform of our corporation?
1. (This point reveals something else in CMMS implementation that is of critical importance. Do not allow the implementation to become hijacked or derailed by interference from IT departments. As always we need to attempt to focus our attention on the overall benefits we will gain in the arenas of maintenance management, reliability of our physical assets and optimization of the use of our human assets.)
* How do our people work? (Rostering or shift arrangements, local or remote sites etc)
* What are our equipment classification types? (Many or few?)
* What are the current and future requirements for reliability focussed functions such as condition monitoring?
This area is obviously a large one and one that needs to be treated seriously as it forms the base, along with our ROI and cost statements, of our overall efforts.
4. Define the steps required to achieve the tactical goals
The diagram on this page illustrates a 6 step progression required to create implement proceed along the path to the realization of the tactical goals that have been created. In this particular case the goal would be the achievement of a planned state of maintenance management. (Steps to the Planned State of Maintenance Management) However all of these steps, not including the 5th step, are essential elements for the creation of any business process involving modern day CMMS systems. This is especially true for the areas of maintenance and engineering.
For example in the 5th step in a process of inventory optimization the equivalent step may be the creation of spares management policies.
This part of the process is, without doubt the most laborious and difficult area of any implementation template. This includes a vast number of areas all covered under the one heading. It is also the area where there exists the majority of waste in the implementation process. Many of the arguments are repeated time and time again in each project.
This paper includes a brief overview of what the terms of Business Rules and Work Processes; however a detailed approach to the steps required would need to cover all of these steps in this model. And as always, there are a number of common themes and principals that can be applied in each of the steps.
Business rules refers to a series of standards within the organization with regards to how we are going to manage maintenance in a generic and homogeneous manner.
Some example areas would include:
* Definitions of technical change management qualification procedures
* Rules on the prioritization of work, and how this is to be applied to the efficient management and programming of resources
* What are the maintenance indicators that will be applied
* How do we classify maintenance and work type.
There are a range of business rules associated with the implementation process. However as a general guide we need to be looking at those things that will be able to guide maintenance efforts in a generic sense over the entire operation. And these need to be created to suit the corporate goals of the organization.
Work processes refer to all the processes within the maintenance organization. These may include:
* Maintenance Planning and Scheduling
* Backlog management ? Technical Change Management
* Shutdown planning and execution systems
* Inventory management and dispatching systems
Some of the expected outcomes of this phase should be the development of role descriptions and role interactions, as well as the Work Order Life Cycle.
From here we are able to determine what are the business rule and process requirements of our system, as well as what are all of the roles those who need to interact with the system, and at what point their intervention is required. For those systems with complex authorization functions this step should also provide the basis for easily determining the authorities required by each role.
This step can be used, in its complete form, for redefinition of the maintenance hierarchy if this is deemed appropriate.
5. Define the Training Matrix and plan for Delivery.
As a consequence of the previous steps we should have arrived at a point whereby we have our roles of people who need to interact with the system defined, and via the Work Order Life Cycle we should also have determined when and what the interaction both with the system and in the process needs to be.
From here we are able to determine the training matrix for the implementation process. This is something that needs to be considered very carefully as it all too often leads to either the success or failure of the implementation effort. A crucial part of the training matrix is the development and deployment of training focussing on the processes we have defined in the previous step. This is without a doubt one of the key elements of CMMS failure.
Once the system is bought the training tends to focus on the functionality of the system, the recommendations of consultants and the half serious attempt to adapt existing processes to the new system. I have seen many times, and I am sure that I am not the only person, many processes created after an implementation. Thus often we are trying to adapt the organization to the requirements of the system instead of the other way around.
6. Define the management team and their required interactions and the Project Plan
There are basic rules to an implementation project; however most of these circle around the themes of involvement and empowerment of the implementation team. Depending on the size and scope of the project the design and interrelations of the team required will change markedly.
It needs to be accepted that the elimination of the software vendor's consultancy services is not an aim of the template process. However there is a need for greater industry wide understanding of how to manage these type of efforts. Therefore potential clients can be empowered with greater control throughout the entire exercise. At this point in time we should have the requirements document pinpoint accurate including: (among other points)
* Interfaces / Integration points with other systems
* Migratory data should be recognised and a plan created for the management of this
* Processes have been re-defined to ensure the implementation of best practice CMMS management processes. And the functionality requirements will have fallen out of this. (Graded in the typical "Critical / Important / Nice to have" style of rating)
* Training requirements have been defined and have been planned out in terms of which role require what training is required for what roles.
* Key implementation information regarding size of project, team members identified and other critical information.
So at this point we are able to both create the requirements document and draft a general implementation plan for the rapid and successful project, executed under the control of the client organization.
7. Constant reviews and measurement against project objectives and timeframes
This stage is better stated as "Planning for Success" the project does not end until the benefits are realized and the "new" maintenance focus is both implemented and embedded within the corporate culture.
For this reason there needs to be the usual raft of project controls during the project to mark critical stages and points of control. But there also needs to be the planning of post project points of control. In these control points we can realize self-audits of the system, of the project, of the amount of change that has occurred and perhaps future possibilities for dramatic change.
Conclusion
With the advances today in technology it has become obvious that there is a need for maintenance management theory and practice to catch up with the advances made in business management theory and practice generally. With a focus on the everyday processes that we use to implement and control reliability initiatives we will really begin to realize great leaps in company performance and cost effectiveness of maintenance; as well as realizing the vast array of benefits available from an implementation of reliability growth initiatives and applications of new technologies.
The current state of CMMS technology is at a very advanced level, in a lot of cases far more so than our ability to apply it. This tool has very strong and provable results, yet there are a great number of projects involving CMMS systems that end in failure and in cost and time overruns. The proliferation of vendors in this market, instead of driving costs down, has been driving them up. When this fact is combined with the common occurrence of CMMS "failures" it becomes obvious that the market should be buyer driven. Vendors need to be challenged and compared rigorously over pricing, after sales service and contractual guarantees. (Possibly even to the shared risk model recently adopted by some)
By using a template approach we are able to realize immediate benefits to the implementation process as well as to the delivery of the maintenance function. We may even be able to create the changes required without the purchase of a new CMMS by better utilizing what we have today.
SOURCE:
http://www.technologyevaluation.com/research/articles/cmms-templates-for-effective-implementations-part-three-7-steps-to-rapid-more-successful-implementations-16920/
No comments:
Post a Comment