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.
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.
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.
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.
No comments:
Post a Comment