The CMMS in Industry
The CMMS industry is divided into various styles of system providers, all of which are defined within the book CMMS: A Timesaving Implementation Process. For the requirements of this position paper we will only be speaking about the two main types. Those are ERP (Enterprise Resource Planning) and EAM (Enterprise Asset Management) style systems.
Figure 1.
This is Part Two 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 Three will present a template for successful implementations of CMMS.
ERP Systems
The modern day ERP system is built on the needs of management of production planning and the optimization of resources to carry out these plans. Effectively they are the products of the MRP and MRP2 theories and methodologies. There has been an enormous expansion in the use and implementation of these systems due to various factors. Principally however the manufacturing sector, at a global level, is immense. Secondly there has been the trend towards financial management requirements as detailed above. ERP systems tend to be outstanding performers in these two areas in particular. However it needs to be understood that the management of maintenance is not, and never has been, a part of the MRP methodologies.
Thus the implementation of these systems is generally not done with the requirements of the maintenance function in mind. Some of these style systems have developed reasonably strong maintenance management functionality, but the overall focus is not on the management of resources and information in the manner required by maintenance professionals.
EAM Systems
EAM systems have descended from the needs of maintenance in capital intensive industries. When we commonly refer to as CMMS we are, more often than not, referring to the functionality that is encapsulated in the large EAM style systems. Today they are truly enterprise level systems and include the relevant sub systems for managing finances, materials, human resources and even sales in some systems.
The EAM system is unique in its model for management of materials for capital intensive industries, and maintenance functionality in general. This is further given credibility by recent moves of major ERP producers to develop and market EAM style systems.
The Market
The market has grown increasingly competitive in both these areas. In the beginnings of the industry it was very much a vendors market, however today it is more and more a market determined by the buyer. The options among the low, medium, and high-end systems are staggering.
Within the next few years those CMMS providers that do not comply with the basic requirements of maintenance, will find themselves on the declining end of the CMMS market, or even extinct. Maintenance can and should be more demanding regarding CMMS functionality and pricing, the ability to find a good deal among providers is greater than ever and is set to become increasingly so. Yet the great many of the buyers in today's sales are blissfully unaware of many of these factors and distinctions, leading even further towards the failure of systems and to their outright overpricing in many instances.
During the last two years in particular the sales of large end CMMS systems has dropped off significantly. There is a large amount of discontent and disillusionment over what benefits can be provided and how much needs to be invested to receive these benefits. There are a great number of CMMS disasters also. These include projects that do not deliver the promised benefits or the promised changes in the operations that clients were originally offered. Although this market is starting to pick up again, it remains an area of doubt and of overriding discontent.
Recent development in this area is the employment of web-based functionality to deliver the maintenance administration function. The implications in this area are immense, and will see the emergence of a whole new range of services that will be offered and that will lend themselves to outsourcing style arrangements. However current technology leaves a great deal to be desired in terms of delivering comparable functionality
Conventional views on software development and sales tell us that this will be not allow ASP's to be truly competitive in today's marketplace. However recent surveys by respected commentators in the area show major increases in the application and use of ASP systems — mainly in the small to medium range companies. This appears to be due mainly to the expense and complexity of major large-scale systems.
Therefore it can be seen that the advanced functionalities of the major large-scale systems may have reached the point of diminishing returns, whereby companies are deciding to buy systems with less functionality due to price considerations.
Reasons for Failure
Before we can begin to analyse the reason for failure of CMMS system implementations we first need to determine what a failure of a CMMS implementation is. Failures in this area can be many and varied, for example it can include:
* Cost overruns
* Time Overruns
* Lack of end user usage of the system
* Failure to achieve promised benefits
* Even failure to become part of the every day life of a corporation.
So the amount of ways in which we perceive a CMMS failure is great. Also great is the number of ways in which we are able to create the environment for this failure. There are a number of these but as a grouping we can generally say that there was a basic failure in the definition of requirements. This is a statement that is made often and understood little.
So what do we mean by the failure of the definition of requirements?
Among the single most common reasons for CMMS failure we have seen is the lack of content; or the lack of understanding of what are the requirements of the assets that we are charged with managing. (The content of the system) As such the implementation of a computerized system, even when one was already in place, will only allow us to manage a poor situation better.
Another part of the failure to define requirements is in the definition of the business processes and the rules of the business as they exist today, and how we want them to exist tomorrow. The implementation of an enterprise level system is a tumultuous event with far reaching consequences throughout an organization. Even at a department only level it can have far reaching consequences throughout the organization.
Therefore we can see the implementation process as a means of taking the quantum leap in maintenance management techniques. It is a time of firstly: definition, and secondly: the redefinition of the maintenance processes in use. Therefore as a part of this level of requirements definition we need to look at the business rules, processes and the physical scope of a CMMS implementation. This in terms of physical locations, number of final user, and so on.
The defining of requirements step is something that requires an excruciating level of detail in some areas. However the payback from this is large and permanent. Over the years I have seen clients becoming a lot more efficient in their definitions of what they require from CMMS. However it is still very much a case of "this is what we do today, give us a system that will do that!".
In these cases the benefits possible through process reengineering are lost from the outset and, frankly speaking, they become set up for a "dump and run style" implementation. (A particularly nasty but common practice.) In these cases it is all too common to find corporations trying desperately, after the event, to redefine their processes to match the functionality of the CMMS.
Other common failing of CMMS implementations: (All of which in one form or another are a part of the failure of requirements definition)
* Lack of executive support and "push"
* Even more dangerous, lack of middle management support.
* Lack of understanding of the benefits and implications of the implementation
* Poor change management. (Continuance of "fiefdoms" within the organization.)
* Lack of training in either the systems usage, or in the processes that we have, or have developed, to proceed in our maintenance mission.
* Poor follow up on processes and impact of the implementation
* Lack of cross department usage and or understanding (Lack of the internal client focus)
Another frequent occurrence is the lack of control over the implementation process by the client. This often is one of the causes of companies not attempting to implement all of the possible changes within a project. The perception that the organization is not ready, or that the change would be too great is a view of maintenance management from a generation ago. With the rates of change in the world around us everyday, how can we really believe that we need to isolate our organizations from this?
The template process is a means of avoiding these common traps and achieving success throughout the organization in the implementation of this essential management tool.
The Template Process
During the past 7 years I have been involved either directly or indirectly in a great number of CMMS system implementations. These have ranged from small 5 person workshops to gigantic multi country applications. In this process I have seen a great number of the common failures listed above, but also a great deal of waste in the process of implementation.
After a while it became evident that the same debates regarding various parts of the implementation process were held again and again. As were many of the hours and hours of work that went into developing standards and processes. It began to amaze me how frequently I had been involved in the recreation of maintenance management, only to arrive at exactly the same definitions and standards in almost every case.
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.
In reviewing sites after an implementation many of the standards and procedures used within the template approach have also been able to be applied in a manner that assists greatly in the optimization of any CMMS and in its better acceptance by maintenance professionals and others within the company.
By utilizing a template approach there is an ability to take firm control over the project from the very outset. From process design, to the functionality definitions, the training required, project size and scope as well as assignment of team members through to the post implementation impact analyses. Rather than being led by the consultancy firm through all of the steps required in a manner that is out of your control and is generally restricted by various contractual definitions and obligations.
'
SOURCE:
http://www.technologyevaluation.com/research/articles/cmms-templates-for-effective-implementations-part-two-the-cmms-industry-and-erp-16919/
The CMMS industry is divided into various styles of system providers, all of which are defined within the book CMMS: A Timesaving Implementation Process. For the requirements of this position paper we will only be speaking about the two main types. Those are ERP (Enterprise Resource Planning) and EAM (Enterprise Asset Management) style systems.
Figure 1.
This is Part Two 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 Three will present a template for successful implementations of CMMS.
ERP Systems
The modern day ERP system is built on the needs of management of production planning and the optimization of resources to carry out these plans. Effectively they are the products of the MRP and MRP2 theories and methodologies. There has been an enormous expansion in the use and implementation of these systems due to various factors. Principally however the manufacturing sector, at a global level, is immense. Secondly there has been the trend towards financial management requirements as detailed above. ERP systems tend to be outstanding performers in these two areas in particular. However it needs to be understood that the management of maintenance is not, and never has been, a part of the MRP methodologies.
Thus the implementation of these systems is generally not done with the requirements of the maintenance function in mind. Some of these style systems have developed reasonably strong maintenance management functionality, but the overall focus is not on the management of resources and information in the manner required by maintenance professionals.
EAM Systems
EAM systems have descended from the needs of maintenance in capital intensive industries. When we commonly refer to as CMMS we are, more often than not, referring to the functionality that is encapsulated in the large EAM style systems. Today they are truly enterprise level systems and include the relevant sub systems for managing finances, materials, human resources and even sales in some systems.
The EAM system is unique in its model for management of materials for capital intensive industries, and maintenance functionality in general. This is further given credibility by recent moves of major ERP producers to develop and market EAM style systems.
The Market
The market has grown increasingly competitive in both these areas. In the beginnings of the industry it was very much a vendors market, however today it is more and more a market determined by the buyer. The options among the low, medium, and high-end systems are staggering.
Within the next few years those CMMS providers that do not comply with the basic requirements of maintenance, will find themselves on the declining end of the CMMS market, or even extinct. Maintenance can and should be more demanding regarding CMMS functionality and pricing, the ability to find a good deal among providers is greater than ever and is set to become increasingly so. Yet the great many of the buyers in today's sales are blissfully unaware of many of these factors and distinctions, leading even further towards the failure of systems and to their outright overpricing in many instances.
During the last two years in particular the sales of large end CMMS systems has dropped off significantly. There is a large amount of discontent and disillusionment over what benefits can be provided and how much needs to be invested to receive these benefits. There are a great number of CMMS disasters also. These include projects that do not deliver the promised benefits or the promised changes in the operations that clients were originally offered. Although this market is starting to pick up again, it remains an area of doubt and of overriding discontent.
Recent development in this area is the employment of web-based functionality to deliver the maintenance administration function. The implications in this area are immense, and will see the emergence of a whole new range of services that will be offered and that will lend themselves to outsourcing style arrangements. However current technology leaves a great deal to be desired in terms of delivering comparable functionality
Conventional views on software development and sales tell us that this will be not allow ASP's to be truly competitive in today's marketplace. However recent surveys by respected commentators in the area show major increases in the application and use of ASP systems — mainly in the small to medium range companies. This appears to be due mainly to the expense and complexity of major large-scale systems.
Therefore it can be seen that the advanced functionalities of the major large-scale systems may have reached the point of diminishing returns, whereby companies are deciding to buy systems with less functionality due to price considerations.
Reasons for Failure
Before we can begin to analyse the reason for failure of CMMS system implementations we first need to determine what a failure of a CMMS implementation is. Failures in this area can be many and varied, for example it can include:
* Cost overruns
* Time Overruns
* Lack of end user usage of the system
* Failure to achieve promised benefits
* Even failure to become part of the every day life of a corporation.
So the amount of ways in which we perceive a CMMS failure is great. Also great is the number of ways in which we are able to create the environment for this failure. There are a number of these but as a grouping we can generally say that there was a basic failure in the definition of requirements. This is a statement that is made often and understood little.
So what do we mean by the failure of the definition of requirements?
Among the single most common reasons for CMMS failure we have seen is the lack of content; or the lack of understanding of what are the requirements of the assets that we are charged with managing. (The content of the system) As such the implementation of a computerized system, even when one was already in place, will only allow us to manage a poor situation better.
Another part of the failure to define requirements is in the definition of the business processes and the rules of the business as they exist today, and how we want them to exist tomorrow. The implementation of an enterprise level system is a tumultuous event with far reaching consequences throughout an organization. Even at a department only level it can have far reaching consequences throughout the organization.
Therefore we can see the implementation process as a means of taking the quantum leap in maintenance management techniques. It is a time of firstly: definition, and secondly: the redefinition of the maintenance processes in use. Therefore as a part of this level of requirements definition we need to look at the business rules, processes and the physical scope of a CMMS implementation. This in terms of physical locations, number of final user, and so on.
The defining of requirements step is something that requires an excruciating level of detail in some areas. However the payback from this is large and permanent. Over the years I have seen clients becoming a lot more efficient in their definitions of what they require from CMMS. However it is still very much a case of "this is what we do today, give us a system that will do that!".
In these cases the benefits possible through process reengineering are lost from the outset and, frankly speaking, they become set up for a "dump and run style" implementation. (A particularly nasty but common practice.) In these cases it is all too common to find corporations trying desperately, after the event, to redefine their processes to match the functionality of the CMMS.
Other common failing of CMMS implementations: (All of which in one form or another are a part of the failure of requirements definition)
* Lack of executive support and "push"
* Even more dangerous, lack of middle management support.
* Lack of understanding of the benefits and implications of the implementation
* Poor change management. (Continuance of "fiefdoms" within the organization.)
* Lack of training in either the systems usage, or in the processes that we have, or have developed, to proceed in our maintenance mission.
* Poor follow up on processes and impact of the implementation
* Lack of cross department usage and or understanding (Lack of the internal client focus)
Another frequent occurrence is the lack of control over the implementation process by the client. This often is one of the causes of companies not attempting to implement all of the possible changes within a project. The perception that the organization is not ready, or that the change would be too great is a view of maintenance management from a generation ago. With the rates of change in the world around us everyday, how can we really believe that we need to isolate our organizations from this?
The template process is a means of avoiding these common traps and achieving success throughout the organization in the implementation of this essential management tool.
The Template Process
During the past 7 years I have been involved either directly or indirectly in a great number of CMMS system implementations. These have ranged from small 5 person workshops to gigantic multi country applications. In this process I have seen a great number of the common failures listed above, but also a great deal of waste in the process of implementation.
After a while it became evident that the same debates regarding various parts of the implementation process were held again and again. As were many of the hours and hours of work that went into developing standards and processes. It began to amaze me how frequently I had been involved in the recreation of maintenance management, only to arrive at exactly the same definitions and standards in almost every case.
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.
In reviewing sites after an implementation many of the standards and procedures used within the template approach have also been able to be applied in a manner that assists greatly in the optimization of any CMMS and in its better acceptance by maintenance professionals and others within the company.
By utilizing a template approach there is an ability to take firm control over the project from the very outset. From process design, to the functionality definitions, the training required, project size and scope as well as assignment of team members through to the post implementation impact analyses. Rather than being led by the consultancy firm through all of the steps required in a manner that is out of your control and is generally restricted by various contractual definitions and obligations.
'
SOURCE:
http://www.technologyevaluation.com/research/articles/cmms-templates-for-effective-implementations-part-two-the-cmms-industry-and-erp-16919/
No comments:
Post a Comment