This document provides guidance on selecting, purchasing, and implementing a computerized maintenance management system (CMMS) or computer-aided facilities management (CAFM) software solution. It outlines the importance of thorough planning, including defining requirements and goals, identifying stakeholders, and creating an implementation plan. The document also describes different types of software options and factors to consider when evaluating vendors. The goal is to help readers navigate this process to prevent costly mistakes and ensure the system's success.

1. SystemQuest Ltd
Helping You Understand Maintenance
Management Software
By: Chris Lee
A Simple Guide to Selecting, Purchasing and
Implementing a CMMS or CAFM Software Solution

2. 1
Index.
Page
Introduction……………………………………………………………………... 2
Planning Stage………………………………………………………………….. 2
Why?..................................................................................... 2
From the top down…………………………………………………………… 3
From the bottom up…………………………………………………………. 3
Who?.................................................................................... 3
What?................................................................................... 4
System Requirements Gathering……………………………............ 4
Vendor Suitability…………………………………………………………….. 5
What are the Software Choices?.......................................... 5
Out of the Box Solutions…………………………………………………… 6
Hybrid Solutions……………………………………………………………….. 6
High end Software Solutions…………………………………………….. 6
Implementation Plan Part 1 – Selection to Purchase………… 7
Implementation Plan Part 2 – Installation to Go Live………… 8
5 Tips for a Simple System Implementation……………………… 11
Glossary of Acronyms……………………………………………………….. 11
Summary…………………………………………………………………………... 12

3. 2
Helping you to Understand Maintenance Management Software
Introduction: - I hope for those that take the time to read this document that you will gain some
knowledge and insight into the process that surrounds the; selection, purchase and implementation
of a computerised maintenance system. Hopefully my knowledge and experience gained over the
years (23 years in engineering and 15 years in maintenance software sales, training and consultancy)
will provide you with a simple and unbiased view – helping you to plan and structure the project
whilst preventing costly mistakes.
Here are just a few of the hard facts of a typical system in a small to medium sized business that I
have encountered:
• In 80% of the systems only 20% of the functionality is used
• A lot of systems have been purchased from comfort rather specification/requirements
• Most Implementations are not planned they happen
• Data is entered randomly rather than in a structured format
In recent years I have worked with many companies and individuals embarking on
purchasing/installing a Computerised Maintenance Management System (CMMS) or a Computer
Aided Facilities Management system (CAFM) for the first time - maybe on this occasion you have
been given that responsibility of selection and Implementation?
For the uninitiated it can seem like a daunting task, with plenty of pitfalls just waiting to catch you
out. The process does not have to be turned into a “rocket science” to achieve success but there is
one thing that cannot be emphasised enough…..planning and preparation is key!
It has been said many times that “if a project is to go wrong, it will be at the planning stage”!
Planning stage – It starts with 3 simple questions; Why, Who & What?
Why: - Let’s start by asking “why are we having a system” and what are the main drivers relative to
the business. For example is it; compliance, control of costs and charges, performance monitoring,
satisfying customer audits, quality control, labour management, stock control etc. Most systems
need drivers from within the business for success, without those drivers the system stands a chance
of never reaching its full potential or even worse….failure! Some drivers will ultimately identify the
maintenance system as being business critical to the organisation, rather than the desire of an
individual to be more efficient in their day to day role (nothing wrong with that idea!).

4. 3
From The top down: -The influence for the purchase and implementation of the system can also
have a bearing on the WHY and what precedes it. System needs driven by requirements identified by
the top tier of management in a company, will invariably carry more interest/emphasis, along with in
most cases a more generous budget for procurement of a total solution i.e. purchase of software,
hardware, external training and consultancy, internal resource availability etc. It is an unfortunate
fact that within some of these larger group wide projects that the maintenance managers/engineers
at the sharp end can easily get overlooked and will at times not get there ideal or preferred solution!
From the bottom up: - This for me is the most common scenario that I encounter, the engineering
supervisor/manager/group engineer/facilities manager identifies the need for a system or
replacement system. Sometimes it’s for the same reasons as previously outlined or it could be that
they feel that there must be a better way to search, plan and report on activity, harnessing the
power of a computer.
Their problem now is that they have to get the buy in and support from senior management (and the
rest of the business). Without the full support and commitment of all parties, they face an inevitable
uphill battle of limited funds, compromising/limiting the choice of products available to select,
unlikely to have money for external help (consultancy) and product training, with a lack of
resources/dedicated time made available to support the project. It’s a situation that I have seen in
countless organisations and it is only the desire, grit and determination of the system champion –
sometimes balancing the day job with trying to implement the system at the start/end of the day or
any spare time, that will see it succeed. Unfortunately the system is never likely to reach anywhere
near the full potential and the company will be unlikely to reap the same financial benefits or
efficiencies of a system that has the endorsement and support from above.
On the positive side, it is likely to be your choice of system, under your control and ultimately up to
you what you put in and get out of it!
Who: - At the planning stage it is a major consideration, who will “champion” the project, taking the
lead, even inputting the data manually. What is their current role and experience within the
business, what spare capacity (time) do they have. It is important to understand that a good system
champion needs to have an all-round understanding of the business. Just because that person is a
good engineer, it does not make them an automatic choice for the role of planning and structuring
the data in a system (system implementor) - nor should the idea of bringing in a bright young
student for the summer to build a system with little engineering, plant or site knowledge….as when
they have gone they will likely to be the only person who understood the structure they created.
It goes without saying that you are required to give any champion/implementer sufficient dedicate
and uninterrupted time on the system to ensure the best chance of success. Outside of the
implementation, consideration also needs to be given to the roles of those who will run the system
on a day to day basis and of course to the end users…the work requesters and engineers who will
require limited access to the system. Skill sets, acceptance to change (no one likes change) are again
to be considered along with potential introductory sessions and a training program for all users.

5. 4
What: - The Why quite often drives the What in as much as it looks at the drivers within the
business and that has a bearing on what you are likely to want out the system in terms of the 3 key
elements Searching, Planning and Reporting. It may be compliance, relating to proof of carrying out
work or having taken/recorded certain readings/conditions, able to demonstrate a regular
maintenance regime exists, management/KPI reports, costs, charges, fault analysis, downtime,
response time etc. This all forms part of the System Requirements.
It is essential during the planning process to build up a clear definition of these before progressing
beyond this stage of the project. The requirements ultimately determine what data is entered and in
what format, enabling you to be able to readily supply the information required at the press of a
button. System requirements also highlight other areas for consideration, for example, IT
requirements; deployment, licencing, underlying database etc. The systems features and
functionality is also a consideration; automation of processes, artificial intelligence within the
system, notifications, alarms etc.
I have formulated a generic requirements template that I will happily share with you. It will take you
through a series of questions where you can identify what is essential in a product, desirable or not
required at all. It will also ask some basic IT requirement questions amongst others.
System Requirements Gathering: - This ultimately depend on the scale of the project, for the
smaller project, the requirement may be driven solely by you and can be kept simple to suit the
needs of your department - considering the roles of the individual users, access to the system, duties
and responsibilities etc.
It is still advisable to consult the other stakeholders in the business to get there view on any
immediate or future requirements. Make sure that you consult with the IT department, to ensure
that they have no objections/questions on the suitability of the software that they may need to
install on their network/hardware. It may be that the software is to be hosted off-site by the vendor
and therefore will raise the question of access to applications outside of the business. The make-up
and openness of the database may also be a consideration and something that they are best placed
to offer advice on. If relevant, the production department needs to be consulted for work
requisitioning and for the planning of machine outages relating to planned preventative
maintenance.
On the larger implementations driven from above, a project team is sometimes formed made up of
member from each department from within the business (production, engineering, purchasing,
estates, IT etc.) It is sometimes difficult in the larger groups to make progress quickly as it’s harder to
get agreement from the different stakeholders, trying to get everyone to focus on the bigger picture
rather than their own specific area of interest. The group does however become an essential part of
the project when you start to consider the need for integration (sharing data) between systems e.g.
a maintenance system providing data to accounts/purchasing systems. A BMS system providing
failure notifications to the maintenance system. The maintenance system providing information to
other systems e.g. production planning, human resources, CAD (or vice versa).

6. 5
Whether, you use my templates, write your own or just document all that is decided, it will form the
basis of what you require as a business from a potential software solution. The next potential hurdle
for some people is the budget for the project and securing the necessary funds, as that can decide
what packages will be available for you to consider!
Vendor suitability: - I see on posts on web site such as LinkedIn people asking what packages do
people recommend. I tend to send them an answer getting them to focus on what we have
described previously (requirements). You have to be careful not to get confused or influenced by
some people’s answers on these forums, as they may well represent a vendor and will obviously be
trying to promote that product. Others with the best of intentions will tell you openly how
wonderful certain packages are when their business is poles apart from yours, they may well have;
more resources available than you, a bigger budget to spend on purchasing the software,
implementation support, training etc. In short their requirements could be totally different to yours!
More importantly for me, I would be interested to know from them how the company reacts to
requests for change to the product, support issues and other areas of communication (pre and post
sales experience) – as that forms a very important part of selecting the right solution provider to
move forward with.
As you can see taking the advice from others can sometimes be misleading. Instead focus on your
requirements and formulate a vendor questionnaire to assess a potential supplier’s suitability to
provide a complete solution.
Again, I have created my own vendor questionnaire which falls in line with the questions that I have
asked in my requirements gathering template. With this questionnaire it is almost always
customised to reflect your exact requirements and will allow you to evaluate one company’s
answers against another. I am happy to share what I have created with anyone interested to follow
this process.
What are the software choices and understanding the differences?
With well over 200 software (CMMS &, CAFM) solutions worldwide to choose from it is easy to be
blinded by the choices that are on offer. to help you understand the differences between CMMS
and CAFM solutions.
Quite simply, CMMS is normally considered for asset intensive businesses i.e. like manufacturing
plants/industrial sites and CAFM for the more location/facilities based maintenance.
Both CMMS & CAFM software carry very similar functionality and in a lot of cases the core features
and principles of operation are the same. In some CAFM systems you will have an option to add
facilities oriented module’s for; space management, facilities booking, CAD interface etc. Where as
in some CMMS software you may find additional modules for things such as: asset tracking,
condition monitoring, OEE, stock control etc. Some software vendors will deliberately write
applications to cross the boundaries and try and capture business from both sectors.

7. 6
With such a wide choice of software (CMMS & CAFM) on offer it goes without saying that you will
encounter a large variance in the purchase price. There can be any number of reasons for this - here
are just a few:
• How much flexibility you will find in the software – i.e. level of customisation that can be
provided
• How scalable the product is relative to your business and the number of users in this country
or across the globe
• How much automation is contained within the system functions (notifications, alarms,
artificial intelligence, job escalation, reporting tools etc.)
• The operating platform that it runs on – cost of development/support
• What’s included with the original licence (functions, features, number of users etc.)
• Brand name, product maturity and perceived market value
• Levels of integration that can be achieved
Out of the box solutions: - A category of software that is supplied on a self- install CD/DVD,
downloaded online or hosted by the vendor. It may require very little configuration to initially get
the system installed and more often than not the system is implemented and data entry is by the
companies own staff, manually entering it over a period of time. This can provide an ideal solution
for people with low requirements, smaller budgets and minimal resources to manage it on a day to
day basis. These systems can be limited in flexibility and customisation and therefore be sure that
the solution will do all that you require, as additional features/modules etc. may not be an option to
have added later. Some well-known systems that fall into this category are; FrontLine and Pirana.
Hybrid systems: - Systems that have an all-round appeal, can be virtually used straight out of the
box, may require some help in installation and configuration. The systems have the added advantage
to be able to configure/control; screens, forms and fields, with dashboard controls and report
customisation also an attractive option. Ideal for people with more defined requirements will
require a slightly larger budget to get the full benefits from this type of systems (in terms of
customisation and configuration, that is quite often better to use the skills of the vendor). Some
well-known systems that fall into this category are; Agility and Tabs FM.
The high end software solutions: - These are systems for business with very defined requirements,
where integrations to other in-house business solutions are a strong possibility. These packages are
sold on a consultative basis and specialist help is normally required at all stages of the process. The
overall purchase and implementation cost can be high, with time and dedicated resource a must.
Software from this category is usually purchased and driven from above. Some well-known systems
that fall into this category are; FSI Concept and Maximo along with the likes of SAP.

8. 7
The Implementation Plan
With the requirements documented in one format or another you now need to consider formulating
an implementation plan. This can be quite basic but it is essential to outline the various steps and
stages of the process, people responsibilities, timescales, actions etc. It is also wise to consider a
phased approach, setting achievable and realistic timescales for each step of the project. Set regular
review meetings to ensure that you stay on target.
Part 1 - Selection to Purchase An example of a simple plan: -
1). Outline of system and business requirements.
Considering the points raised in the” Why, Who and What” sections. i.e. the purpose of the system,
scale of the project, available resources, roles of the individuals, timescale to purchase, implement,
train and roll out, integration to other system, budget etc.
2). Formulate a list of potential vendors.
From attending shows, research on the web, adverts and articles in trade magazines and from
recommendations from people from your business sector. Formulate a list of potential vendors.
3). Send out specification and assessment document to vendors.
Either using my template or one that you have created yourself, send out the questionnaire to the
selected software vendors.
4). Evaluate returned questionnaires.
Having sent out the questionnaire, evaluate the ones returned in-line with your requirements
document. From my past experience and for some unexplainable reason you have to be prepared
for some companies not to bother returning the completed form, even though the software may
well be suitable for inclusion in the next phase of the selection process? Your completed
requirements document is the benchmark to compare the systems suitability and to get some idea
of costs. Also ensure that these potential vendors are likely to provide a solution within your
budgetary constraints.
5) Shortlist potential suppliers.
Create a shortlist of potential suppliers/vendors, at least 3 and no more than 5. Arrange for on-site
demonstrations to be carried out and involve all interested parties from within the business. Try and
control the group and not let the people be romanced by the possibilities, bear in mind that the
salesperson doing the demo will try to impress with the “whistles and bells” features. Keep a grip on
the demo, control it by limiting time and sticking to requesting a demonstration that covers the key
functionality outlined in your requirements document.

9. 8
6) Formal quotations.
Invite the shortlisted companies to submit formal quotations in-line with your requirements. Ensure
that the quotes are “like for like” where possible.
7) Reference site visits.
Organise with the potential vendors, visits to a site/s where there is a synergy between the
businesses. Whilst there, ask questions regarding how they use their system and compare that with
your own requirements, check what they think of the sales and support that they have received, ask
for a demonstration of how they use the system and the key reports that they generate.
It is sometimes better to attend the site/s unescorted by the potential vendor, as it easier to ask
sensitive questions about the product and service and to get an honest answer without feeling
pressured.
If visits are not possible due to time and distance constraints, please ensure that you at least make
contact with reference customers over the phone or by email and ask the questions.
8) Final selection and purchase.
Considering all of the information received, coupled with the vendor demonstrations and views
expressed by the reference sites (visits/telephone conversations)….it is time to make an informed
and educated selection and purchase.
Part 2 – Installation to Go-Live - An example of a simple plan.
9) Installation/configuration.
Depending on which product is selected and whether the system is to be installed as a stand-alone,
networked or hosted system, could affect this process and who has to be involved. In most cases
there will be some involvement from your own in-house or out-sourced IT department. It the case of
the out of the box software some packages installed locally will be done via a CD/DVD following a
self- install wizard built into the software, other packages may require the vendor to attend site and
to install and configure the system. Configuration could include the basic system settings along with
creating users/user groups/security and user profiles etc.
10) Product/Implementation training.
Again depending on which product you select, could affect the need for this level of training. In the
out of the box and hybrid systems that I described earlier, it can still be very much down to your own
system champion to be heavily involved in the implementation. Sometimes, manually inputting the
data or at the least, collating the necessary info into spreadsheets before it is validated and
imported into your system. Either way it is good for that person to undergo some form of training on

10. 9
the process and rationale behind building the system and structuring the data thus providing the
necessary management reports identified in the requirements gathering process.
11) Data entry process.
There are two main methods manual and electronic (import from spreadsheet or existing database).
Manual method: - In the out of the box and hybrid system it is not uncommon for individuals to be
given the task of manual data entry. It is important that they have a clear definition and
understanding of what they are doing and why (Implementation training in line with requirements).
I have in the past created flow diagrams for training purposes that will act as an aide memoir as to
the process and order of data entry. This improves the speed and efficiency during the process by
limiting the amount of jumping backwards and forward between the records as you enter data. I also
find that this acts as a good discussion document when carrying out end-user training. Before the
process starts it is important to gather as much information together as possible e.g. asset listing
with details, supplier listing, contractor/contract information, PPM task list with relevant details,
documents and drawing to be attached, parts listing, personnel details etc. The more information
you have upfront the more efficient you can be in this process. Below are a couple of examples of
flow diagrams identifying the order of configuration and data entry when setting up the system
manually.
Examples of flow diagrams
outlining data entry order for the
Agility and Pirana systems.

11. 10
Electronic method: - This is an option for most of the packages from the bottom of the range
through to the top. Out of the box and hybrid applications also teach manual data entry, where as
some of the larger packages encourage the import of data as the preferred method, getting people
to collate data in spreadsheet format so that it can be readily manipulated prior to being Imported
by the vendor (sometimes the utility is built into the software). As part of the services that some
vendors offer they will go through the spreadsheet and validate it, checking the quality and integrity
of the data before importing. Be aware that this service normally carries a charge.
On the positive side:
• It can be a quick way to kick start the project, especially if you already have data from a
previous system to transfer/import or have data in spreadsheet format.
• Manipulation and corrections are sometimes easier done outside the package.
• Validation can be done using the expertise of the vendor.
On the negative side:
• If you don’t have any data then you still have to input it onto a spreadsheet.
• If a company offers the import service but not the data validation then you could find the
quality and integrity an issue later.
• Sceptical about the companies that only promote this method of data entry as I feel that at
times they are conditioning people to be more reliant on their services and away from
having the depth of knowledge that comes with manual entry method.
• Additional cost for the service.
12) End-user training: - It is debatable as to whether the end-user training should come before the
pilot system is proven, as any changes could affect the training previously given to the end users? It
is however necessary to at least train those people who will be part of the pilot or test area. They
will require the necessary training to be able to operate the software and carry out the duties for
their role (previously identified in the requirements gathering process). In my experience I have
always tried to limit what I show, allotting a profile that shuts down/securing areas of the software
that are of no concern and keeping these session small in numbers and short in time. I normally
provide simple picture book training guides for their method of operation. I have also found it better
in some cases to do two shorter sessions than one long session that will turn people off.
Where I am able to spread the software training over the two short sessions, I have used the first
session as an overview and introductory session (navigating the system) and then the second for
giving instruction on how to use the software.
13) Running a pilot: - Although not essential I do prefer this myself, introducing the software into a
defined area of the business testing both the soundness of the implementation and getting the
feedback from the operators/end-users. Being able to carry out some fine tuning before releasing it
to the rest of the business.

12. 11
14) Go Live: - On successful completion of the pilot system, you are now in a position to release the
system to the masses. For some people who have manually built the system, it may be that you have
only populated the data to cover the pilot area. You are now in a position to continue to build the
system following the proven format/structure. For others it could mean a roll out around the
business training the end-users as you go!
15) On-going Reviews and system development/improvement: - It is highly unlikely that your
system will be perfect or complete at the point of “go-live” – so it is important to set and conduct
on-going system reviews, include representatives from the end-users and in certain instances the
vendor. Within these meetings you can discuss and plan any changes to the system or schedule the
next phase of development. These meetings are vital to ensure that you get the buy in from
everyone and that the system will go on to reach its full potential.
5 tips for a simple system Implementation: -
• Don’t try and fill all the boxes on the screen – only put in what you want out!
• Keep assets as large as possible – you can always add the sub-assets later.
• Keep the tasks generic - rather than asset specific.
• Follow the correct order for data entry – make sure you have all the data collated before
starting.
• Adopt a phased approach to the implementation – set achievable milestones.
Glossary of common acronyms used throughout this industry: -
• ASP: Application Service Provider (Re: Hosted systems)
• BOM: Bill of Materials
• CAFM: Computer Aided Facility Management
• CBM: Condition Based Monitoring
• CMMS: Computerised Maintenance Management Software/Systems
• CM: Condition Monitoring
• CRM: Customer Relationship Management
• EAM: Enterprise Asset Management
• ERP: Enterprise Resource Planning
• FMS: Facility Management Software/System (Same as CAFM)
• FMEA: Failure Mode Effect Analysis
• FMECA: Failure Mode Effect and Criticality Analysis
• ISP: Internet Service Provider
• KPI: Key Performance Indicator
• MDT: Mean Down Time
• MTBF: Mean Time Between Failures
• MTTR: Mean Time To Repair
• MWT: Mean Wait Time

13. 12
• MMS: Maintenance Management System (manual system)
• NDT: Non Destructive Testing
• OTB: Operate To Breakdown
• OEE: Overall Equipment Effectiveness
• PM: Planned Maintenance
• PPM: Preventative Planned Maintenance
• PdM: Predictive Maintenance
• PO: Purchase Order
• RCM: Reliability Centered Maintenance
• RCFA: Root Cause Failure Analysis
• SaaS: Software as a Service (Hosted Systems)
• TCO: Total Cost of Ownership
• TPM: Total Productive Maintenance
• WO, W/O: Work Order
• WR: Work Request
In Summary: - I have tried to give you a simple but comprehensive overview of the process.
There are major benefits gained from creating an Implementation plan in that people
involved have a clear definition of what is required (internal staff and vendor). Everyone
understands what their role is in the project and what they are required to deliver according
to timescale. Following the plan and getting the system data structure right from the start,
reduces the chances of having to make major and costly changes to the data later on.
Having a clear plan will also help to promote the buy-in from the users within the business
and will subsequently increase the chances of the systems success.
Produced by:
Chris Lee
Director
SystemQuest Ltd
www.systemquest.co.uk