Choosing a Field Service Management System

As published in Service Management, an article by Steve Burrows on the business considerations in selecting a Field Service Management Solution.

Making the right choice of field service management system

Deciding which computer system to buy for the organisation is the stuff of nightmares. Between the complexity of modern business processes and operations, the conflicting requirements of users and the grandiose claims made by some software suppliers, selecting a system is a very difficult and hazardous undertaking which often leads to disappointment and wasted capital expenditure.

The above statement is true for almost all strategic/enterprise computer systems – ERP, CRM, etc, even though the business processes and modus operandi surrounding the use of such systems are well understood and relatively standardised. Selecting a field service management (FSM) system is much more difficult.

FSM is not well established, there are few conventions about how it should best be done, and the diverse needs of field service providers mean that there are more variables to take account of than when selecting most other breeds of enterprise software.

As a consequence FSM systems vary considerably in their capabilities – some are better suited to one type of service operation, others to a different operating model. This article attempts to highlight the most relevant factors to be considered when selecting a system.

Scheduled versus reactive:

Service operations normally fall into two categories – pre-planned and reactive. If you schedule visits in advance, then you are in the former category. If you service business-critical equipment and need to get to the customer as soon as you can, then you are reactive, although you may also use scheduled visits for preventative maintenance.

Different systems on the market are stronger or weaker at scheduled versus ad-hoc appointments, and some, designed primarily for the B2C service market, cannot efficiently support a reactive service model. Will the system allow you to operate both scheduled and reactive service effectively?

SLA or reasonable efforts:

If you run an SLA-driven service operation you will be perpetually juggling the conflicts of engineer availability versus deadlines. You will require a system that allows you to attach SLA response terms to each customer and/or item of equipment depending on which carries the SLA (possibly different SLAs for multiple items of equipment on the same site).

You will expect that the service system will automatically highlight all jobs that are nearing their SLA response time, and will escalate endangered jobs to a supervisor in real-time. Many systems cannot achieve this.

If you are only required to respond under terms of ‘reasonable efforts’ then you will have a broader choice of systems – but one day you might want to provide SLA terms to a demanding customer. Will the system allow you to operate complex multi-level SLAs for some customers/equipment, whilst other customers or equipment (possibly on the same site as equipment under SLA) have no SLAs? Will it allow you to prioritise between customers on different levels of contract?

Contract or time and materials:

Some service operations operate on the basis of chargeable calls, others expect to have service contracts in place with their customers. A small proportion are rental operators, who own the equipment they are servicing, and include all service costs within the rental charges.

Will the system allow you to specify whether a customer or item of equipment is covered by contract or chargeable? Does it provide reporting which allows you to determine the profits on chargeable calls, and the costs of contact calls? Can you measure the profitability of a contract over the past year? Does the system identify unprofitable contracts prior to their renewal? Does it automatically produce contract renewal documentation?

Does it support different contract durations and billing frequencies? For chargeable calls does the system inform the engineer of the price of the parts he is fitting, so that he can consult the customer before using an expensive part?

Billing:

The subject of billing is possibly the most varied and complex within FSM systems. If you have chargeable (pay as you go) key account customers will the system allow you to provide special terms? Discounted labour and parts charges?

Will it allow split charging – call-out charges, time charges, parts charges? Free time in the call-out charge? The permutations are endless, and the majority of FSM system suppliers fail to recognise that in many cases the billing engine in their systems inhibits the flexibility of commercial model available to the service organisation – resulting in manually corrected invoices.

Warranty:

Warranty terms vary and many items of capital equipment have complex warranties. Will the system support split warranties (for example three year parts warranty, one year labour warranty)? Or warranties for specific components (three years for the machine, but one year for the power supply)?

And how does it cope with these, does it support serialised parts so that you know whether a component has been replaced, and whether the replacement is still under warranty or not? Can you report on which items have been replaced under warranty so that you can make a counter claim to the OEM? Does the mobile element of the system tell the engineer which replaced parts must be returned to base for warranty claims and which may be discarded?

Repair on-site or return to base: Many capital equipment service operators swap-out or remove complex components/sub-assemblies on site and return the failed unit to a workshop for re-work. If swapped-out the reworked component is usually returned to stock, if removed then it must be re-installed once repaired.

Many FSM systems don't have capabilities to support this, but a few have comprehensive workshop modules that will not only manage the field service element of component removal, but will also track it through the repair workshop and back into stock or re-installation on the customer's site.

Broken calls or one visit fix:

For many field service operations a service call means a one-visit fix – either by repair or through swap-out. If the spares inventory is small enough to carry in a van, along with a small stock of replacement units, then a service job is relatively simple.

For some operations life is more difficult – the engineer may not be able to fix first time, he may not have a spare part because he can only carry a few hundred spares in the van, and have to order a part. It may prove upon inspection that the repair is a two-man job, or it may be that the engineer cannot diagnose the fault and another engineer must visit.

Each of these is a nightmare for the field service manager because broken calls are very costly and a disappointment for the customer. How does the system support broken calls? Does it support multiple visits for one job? Does it provide the means to schedule the delivery of replacement parts in sync with the second visit of an engineer? Does it prefer to schedule the engineer who visited first, or suggest another engineer who must redo the diagnostic process?

Engineer skills:

In a simple world all engineers are multi-skilled – they can do any job on any product. Life gets more complicated when engineers are more specialised.

Does the system support engineer skillsets, allowing you to determine which engineers can support which products or job types? With a large field service team the scheduling activity can become a nightmare unless the system can suggest which engineers are most appropriate for a specific job.

Geographic features:

Do your engineers work within geographic boundaries? How do you govern the area covered by an engineer? What if there are jobs close to the boundaries of an engineer's area – will the system support you in despatching an engineer ‘over the border’ into another region because he already has a job close by?

How do you define an engineer's area? A collection of postcodes, a line drawn on a map? Are engineers allocated to service specific customers? Does the system provide tools to support call allocators in determining the proximity of jobs?

Can it interface to an automated job scheduling system? In managing engineers on the ground the biggest considerations are skills and proximity, does the system provide the geographic tools to assist you in reducing engineer travel time?

Mobile data:

The probability is that you will have many more engineers than office-bound users of your field service system, so if the engineers are equipped with a mobile data terminal as part of the system they will be the most numerous of the system users.

Does the system provide comprehensive mobile data facilities? Is it tied to the van, or can the engineer take it with him onto site? Does it give the engineer the information he needs to do the job? Access details for the customer? Details of the equipment and fault? Information about previous engineer visits? Inventory of the equipment on site? A parts catalogue/price list? Technical documentation?

Mobile data is about much more than just logging the time of arrival and departure, it should extend the full benefits of system access to the engineer. Also consider what happens when the engineer is out of mobile data reception – is he then unable to use the system, or will it ‘store and forward’, allowing him to use it on site and then update head-office when he regains a radio signal?

Van stock control:

An engineer without the right parts is a disabled engineer. Stock control of engineer vans is an essential discipline in most field service operations, but neglected by many FSM systems that focus on managing calls and engineers.

Does the system provide comprehensive van inventory control? Automatic replenishment of parts used? Management of parts ordered by an engineer? Does it support stock exchange between engineers? Does it allow an engineer to locate the nearest source of a part?

Management information:

An FSM system accumulates a wealth of valuable data about product performance, reliability and maintenance cost, common causes of failure, engineer performance, parts usage, etc.

Does the system include standard reports to allow you to analyse your performance, and the ability to customise those report easily? Will it allow you to create reports with an external reporting/business intelligence tool such as Business Objects or Excel?

Clearly there are a lot of features and variables to consider when selecting a system. Almost every field service organisation is different and there are no software packages that can tick all of the boxes for all organisations, so careful consideration is required to ensure that the system you select will meet your needs now and in the foreseeable future.



The questions above are some of my generic considerations in evaluating a field service system, however you may have other specialised requirements to help you meet the challenges of your business.

• < Prev
• Next >