Business-Specific Field Service Mobility Application

Objective

Our Field Services client specialises in Mechanical Services. The National Service Manager (NSM) was looking for a Field Service Mobility solution. There was an App option which was part of the Service module in their ERP, but it didn’t meet their process needs. He had found alternative options, but they all required use of the accompanying Field Service Management software for back-office processes. The NSM wanted a standalone Field Service Mobility App, which covered process requirements; was easy for the service techs to use; and could integrate to their ERP.

The NSM engaged us to build both the Field Service Mobility App and the integration to/from their ERP.

Solution Delivery

• The National Service Manager (NSM) knew what he wanted to achieve with the App, but was the first to admit that he wasn’t the right person to write a formal requirements document. In the absence of a suitable candidate in the business, he asked us to write it, using  our prior knowledge of and experience working in Field Service businesses.
• We sat down with the NSM and first discussed the functional options he thought he wanted in the App. We then mapped out the current Back Office business processes (with him) and included both ERP and external actions.
• After those initial information gathering sessions, we investigated the ERP integration requirements. We specifically looked at where we needed data from the ERP and when we had to send data back.
• The Integration Requirements, App functions and Back Office processes gave us enough information to put together a proposed group of screens for the App.
• It was really important for the NSM that the App itself was intuitive for the techs to use. He wanted the screens to guide the tech through the process of capturing the right information for the service job, but not to be too restrictive. We had to find a delicate balance, but we came up with a screen navigation structure that he was happy with.
• The NSM added a few requirements later in the process, where he wanted to capture information on the App that his ERP Service module couldn’t incorporate. Our proposed structure had included a SQL back-end database to store key data and manage the integrity of the data sync and ERP integration. This was important Middleware, which could control the processes and provide a secure layer between the App and the ERP. It also meant that it was a simple addition for us to allow for the storage of the additional information in this database.
• Once we had documented all the elements of the App design, the back-office business process change and the ERP integration, with the NSM in agreement, we could commence the build.
• Once the build was complete, we picked a small group of service techs to be our BETA testers. These techs worked with the NSM and us to “road test” the App. The techs came up with some very useful suggestions that we could incorporate into the Stage 2 work.

Achievements

• Our most exciting achievement? Service techs didn’t need extensive training on the app. Our intuitive workflow worked! Each tech was given a one-page “Function Cheat Sheet” as a reference guide. It had some reminder notes on how to log in and find key functions. The NSM also gave them a high-level overview of the new processes at their Weekly Toolbox Meetings. This information was enough for them to download the app and start processing.
• Surprisingly, it was the back office staff who struggled the most with the technology change. Even though the staff had been trained on the changes to their ERP and external processes, they found it hard to stop using the old processes.
• We also had some interesting challenges keeping the scope manageable and cost effective. Despite their prior scope sign-off, some people in the business wanted to “ADD IN ALL THE FEATURES NOW”. They had an expectation that the product had to be fully-realised for Stage 1. While Stage 1 contained all the key functionality needed to make the app usable, any “nice to haves” were not included. This was primarily due to the time, cost and effort required for the additional items. The requested functionality seemed small or easy to build to a non-technical person. These conversations were difficult, as perception and reality of cost can differ, but they were important to have.
• The Field Service App usage continues to increase, with over 100 service technicians currently using it. This has helped to ensure that the ratio of Back Office staff supporting service technicians has remained low, despite the business growth.

If you’d like to learn more about this project, click here to contact us.