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

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

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!).

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.

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).

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.

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.

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.

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

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.

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.

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

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