There have been many instances where I have seen organisations change their Computer Maintenance Management System (CMMS) or components thereof due to perceived under performance or poor value delivery of the system. On closer evaluation I find in many cases the failure to deliver value is due to a mismatch of Maintenance Work Management Process and supporting CMMS functionality and workflow.

A mismatch between the business process, system functionality and supported workflow may be as a result of implementing vanilla systems without consideration of tailoring functionality and workflow to the business process, or vice versa not adapting the business process to fit the information system workflow. In either case one of the two will need to change in order to generate the most effective solution.

The perfect CMMS

The reality is that there is no perfect CMMS (off the shelf at least) as each organisation will have its own unique requirements. These requirements, and often funding constraints, usually guide our decision in terms of the type of system that is procured and implemented, which may be a vanilla, best of breed, customised or bespoke. Extreme customisation of systems has its own challenges in the long run, beyond just the cost of customisation, that has a major impact of ongoing specialist support and painful upgrades or migration when system versions are no longer supported.

Systems support business requirements, not individual user requirements

If core business process steps and workflow are not supported, due to lack of analysis or availability of documented procedures, then development and delivery of the information system is slow and frequent rework and functional changes (often based on wish-lists rather than process requirement) are evident. This will ultimately lead to a frustrated user group and poor business process compliance.

Unfortunately, business processes are often not given enough attention when new systems are being implemented. In poor examples of CMMS implementation, the engineering requirements and expectation may even be ignored all together, with implementations being driven by Finance departments, leaving little room for influence by the Engineering department. This last example reflecting a general poor maturity level of such an organisation.

Generating value when implementing new systems

Good alignment relies on having a clear understanding of the business process requirement. The as-is process may be analysed for this, but in many cases, it is an opportunity to develop new processes or do a refresh the current process if there is one.

When designing or refreshing the process the following basic framework may offer some guidance on what a good approach looks like:

Stakeholder engagement and strategic intent

Business process design should not be done in isolation by the department or managers that appear to be affected by the process. Stakeholder engagement, Subject Matter Experts (SMEs) and influencers within the business’ involvement is a key success driver to design a process that will be adopted by operational teams.

Adding a wider Asset Management view to this also means gaining understanding of the internal and external drivers that are influencing our processes. These may be captured within the various strategies in our organisation or even external strategies for example the NSW Digital Government Strategy that has an influence on their direct stakeholders.

A more specific example of strategic requirement influencing the work management process: The organisation has a vision of having a risk view of the asset portfolio, which is based on criticality (consequence) and condition (probability). In terms of impacting on the Work Management Process, how do we execute condition assessments? What is the standard to do consistent condition assessments? How is the capturing of condition data supported to create a risk view of the asset portfolio?

From the above example there is a clear requirement in terms of process (execute and capture condition), standards (how condition assessments are rated) and information system support requirement (how we mange condition data).

Business process development

Based on the stakeholder engagement and workshops with team members the process is developed and documented. This will usually be made up of the process maps, supporting description of the detailed steps as well as a RACI indicating the process roles and responsibilities.

Organisational alignment

Once the roles and responsibilities are mapped, it may be that some organisational alignment is required to support the process, noting that there are many processes to be supported and that we don’t just align ourselves around a single process.

Information systems planning

With the business process requirements now well documented and understood, the options in terms of supporting those are considered. There are cases where the workflow may not be fully supported, in which case some tweaking to the business process may be required.

Implementation and change management

Assuming that a common ground has been found between business process and information system, the organisation is not ready for implementation and rollout. There are of course many other considerations and factors that need to be considered in such an implementation, but the point of this article is just to enforce the process and system alignment principle.

If good organisational change management practices are applied to the above approach it ensures that when the CMMS is implemented:

  • The business process requirements are well understood and documented,
  • It will complement core business requirements that add value,
  • There will be clearly defined user roles and responsibilities (aiding user rights, access, and security rules of the information system), and
  • It will promote buy-in from system users.

If your organisation is struggling to gain the expected value from its CMMS, contact us today to discuss a way forward, which may include:

Back to top