Field Functionality No. 1 — Track that truck stock inventory and don’t forget the reverse supply chain. An ERP usually does a good job tracking inventory levels, location, and inventory transactions, but it does not always do a very good job of tracking mobile truck inventory, and in a field service environment, that is where inventory is consumed.

Each technician vehicle is, in essence, a rolling warehouse. This means software must provide visibility of inventory on each truck so dispatchers or automated scheduling software can determine which technician has the inventory to perform an assigned service task. It needs to provide visibility of inventory consumed from the truck stock in order to bill the part to the customer, determine whether it is under warranty, drive replenishment processes, and create parts dispositions for parts that must be received back for repair, remanufacturing, refurbishment, and compliance.

It will also need to track when larger inventory items need to be loaded on a truck in a specific order to accommodate the order of service calls or if a repairable unit can be sent to a depot. In this instance, a return material authorization (RMA) should be created automatically and the defect routed to the right repair location. If a field replaceable unit is eligible for a core credit, this process needs to be initiated in the field and ERP alerts must be created to the credit against the OEM.

Finding the Right Functionality

Some major ERP providers do not provide this functionality — even some of the popular field service management software products don’t; therefore, it’s vital for service organizations to ask questions of their software providers to ensure the requirement for this functionality does not fall between cracks. An ERP system will usually remain the inventory system of record with field service software modifying inventory levels or usages, but the field service software should facilitate processes for inventory management and inventory accountability, like cycle counts, as well as initiating purchase demands on service order requirements for parts not in stock.

Field Functionality No. 2 — Track essential asset maintenance history. ERP products usually do a good job of establishing the original asset record derived from a manufacturing or sales order, but what if the asset record changes or the asset changes ownership or changes over time? These field service-related transactions normally don’t update the asset record in the ERP. Further, what if the product is sold through distribution?  

Once that serialized item has been installed, the ability to update the asset record with the essential service and maintenance history is often difficult to achieve with some solutions. FSM software must be capable of tracking the work performed, parts consumed, fault codes, changes in location, and other transactions that take place during the asset life cycle. Recording maintenance history is just one element of this requirement and a lot of other things can happen with an asset after the sale that are essential to service delivery.

For example, the location of the asset may change, with assets covered by a service contract moving within a facility or even transported from one facility or region to another. Alternatively, the way the customer is using the asset may change with implications on recommended service regimens. Service software has to be sensitive to these changes.  

Questions FSM Can Answer

Ownership of parts or subcomponents may change depending on the contract. If a part is removed, does it remain with the customer? Do they get it back after it has been refurbished? If so, do they get the same component back or just a replacement? When subcontractors perform work on an asset, field service software will authorize the work, capture work order completions and part returns, and be used to manage the subcontractor compensation process.   

FSM software should capture all of these changes and use the resulting data to facilitate the service life cycle while maintaining a current database for customers, assets, contracts, warranties, parts, and repairs without administrative overhead. 

Field Functionality No. 3 – Track contract management capability. An ERP instance may include functionality for things such as contract management, including a record of what the customer is entitled to in terms of pricing, replacement parts, service level agreements (SLAs), and more. But if a company is managing contracts in this way, and the field work order or ticketing system is outside the ERP, how do you get the entitlements to flow into the work order?

The answer is that you usually don’t, and you end up with a very manual and tedious service billing process. The goal should be to have the technician complete the work order and not have to worry about what pricing, parts, or SLA the customer is entitled to under contract. All of that should occur without intervention. If contract management and field service ticketing are handled in two separate systems, the required integration is daunting enough that it usually is not performed or not performed to the extent it should be.

Field Functionality No. 4 — Track those high-volume transactions, including point of sale and work order completion that are often performed outside of the ERP. Around the business world, most businesses will use third-party solutions for high-volume tasks, such as point of sale, but field service organizations process high-volume transactions as well, and it is essential these are recorded on a timely basis. The ability to quickly debrief a call and have it prepared for billing can reduce days sales outstanding and greatly improve time to cash.

A Truly Integrated Approach

All of these barriers to efficient delivery of service exist unless field service software streamlines the delivery process. It’s true that a systems integrator can make an ERP do pretty much anything with the proper amount of time or cost, but without an application to easily manage the process, it will be very difficult to make it easy to use for people in the field and administrators.

The sheer complexity of the application architecture cannot be configured out of a business process. If you have 20,000 break-fix service calls a week, this costs you in terms of time, dollars, and customer experience. A best-in-class FSM software application should complete these transactions automatically in the back-end ERP system as the technician completes work orders, consumes inventory, records equipment condition, and interacts with the customer.

Fielding the Right Solution

Most ERP applications are not a perfect fit for much of the field service process. That is why a service organization will usually extend that system of record with a best-of-breed software application. The technician just records their travel and labor time, parts used, parts needed, part returns, and quality information, and the system addresses pricing, if commitments were met, and the back-office database updates seamlessly. With developing trends such as assets-as-a-service, IoT, and augmented reality all beginning to take shape, these technologies will be supported in best-in-class service systems earlier in their life cycle. The underlying technology is just better suited to these highly configurable service platforms.

For more information on extending ERP software for field service management, read the white paper summary here: https://www.ifsworld.com/us/sitecore/media-library/assets/2018/12/04/whitepaper-get-more-from-sap-with-fsm/

Publication date: 03/22/19