AUTHOR ARCHIVES: Ian Mapp

Why is it that, in a time of unprecedented innovation in phone technology, all field service mobile apps are the same? Ian Mapp, Director at Wyser Stewart throws down the gauntlet to app developers...

Not precisely the same, of course. But, essentially they all try to solve the challenges faced by mobile engineers/technicians in the same way. If you look at the websites of companies that supply such applications – and there are plenty to choose from, too many to list here – you will find the descriptions almost interchangeable.

They all claim to increase productivity by replacing the reliance on paper-based forms, reliably integrating with office-based systems, eliminating errors and speeding up processes; improving cashflow by removing delays in producing the final invoice and reducing customer disputes. Sure, there are differences in details and variations in the technology platforms that are supported, but they are almost identical in capabilities. Plus, delivering indistinguishable experiences for the user.

 

It seems that the biggest innovation right now is who supplies the device – the company or the worker! To BYOD, or not to BYOD. It’s 2014. Is that best we can do? Really?

Smartphones are becoming ubiquitous, with market penetration in the UK this year estimated somewhere between 70-80%. And each of them has amazing computing capability, and a bunch of ‘smart’ features that make them very powerful devices. The biggest challenge when rolling out mobile applications is often user resistance to changing their working practices, but we don’t exploit those capabilities or make it very attractive when all we offer our engineers is a replacement for filling out forms.

“Okay, if you’re so clever, what do you suggest?” I hear you ask. And it’s a fair question.

The design for today’s apps mostly started out as automated equivalents of paper systems, as has been mentioned. And that is true of most administrative software products. Take a manual procedure, tweak it a bit and write the resulting re-engineered process into code. Bingo! A faster version of what worked before, more reliable, more consistent and leading to more work being done.

But, what if we started from a clean sheet and made smartphone capabilities intrinsic to the design of a new model for mobile workers? What might that look like? Now, I am by no means a software developer so some of this may not be practical, but I am an enthusiastic smartphone user and this does not seem at all far-fetched. Here are some ideas for a (better) day in the life for an engineer, using M/App (our imaginary mobile app - sorry, couldn’t resist it!)

 

It’s 07:45, and Sam’s phone chimes. Sam has been checking the news headlines and is already logged into the phone – possibly using a fingerprint for security validation. M/App knows, from a calendar entry, that Sam is scheduled for a shift starting at 08:00 and offers a simple prompt, “Ready to start your shift Sam?” with Yes/No/Snooze options for a response. No logging in to an application, no menu choices to be made, just a single button press (or voice input).

The software interrogates Sam’s scheduled jobs and checks for any delays on the journey to the first one. There are none, and at 08:02 M/App gently reminds Sam that he needs to start his daily vehicle check, in order to set off in time for his first appointment. The checklist is on-screen as soon as the phone detects movement outside to the van. The vehicle check requires input from Sam, but once that is finished, the app is expecting that travel will begin to the site and will not require any further response if it detects movement at speed – indicating driving – on a reasonable route to the first destination.

The phone detects that Sam is out of the vehicle, and based on GPS signals, prompts for confirmation that Sam has arrived on-site. He may only have parked nearby and needs some time before he truly arrives, or he may have unrelated tasks to perform – like returning a call to a manager – and so a positive acknowledgement is required.

Depending on the quality of the data about the machine to be serviced, it may be possible to use the latest in-building positioning technologies to determine when Sam is ready to begin work. Irrespective of that detail, M/App will always default to a prompt about the next expected step in the process.

 

For example, asking “Are you ready to start work on the xyz machine?” with Yes/No/Snooze options is simpler than asking for a ‘Start Time’ to be input in HH:MM format. And streamlining the data input demands will also encourage Sam to record what he is doing in real-time, further improving the flow of data back to the office and the decisions to be made about new priority jobs, and dynamically rescheduling for overruns and delays.

The workflow will progress through the necessary actions to complete the job, using any sensors or features of the device than can provide knowledge that enable the app to intelligently determine what is happening and what should happen next – clock, camera, touch screen, accelerometers, GPS and Wi-Fi for positioning, other installed apps or OS facilities.

I am not suggesting that everything will flow simply from step to step without variation – that would not be realistic – but in many industries and job types there is a definite pattern to the individual activities and M/App suggests the ‘line of least resistance’ for the engineer to follow. That’s what we call best-practice, isn’t it?

M/App is always active in the background, trying to ensure that the schedule can be met. For example, Sam starts a task with a ‘standard’ time of 60 minutes. After 30 minutes, the app checks for travel delays and detects a problem, with a hold-up of 20 minutes and a late arrival predicted. The app prompts Sam for an estimated completion time, he confirms 30 minutes, and informs the central system of the upcoming problem. That allows the scheduling system to determine the best course of action. A decision is made and the change to his schedule is communicated to Sam’s device while he continues to work, meaning that he can immediately move on to the right next job – avoiding the traffic hold-up. That improves the productivity of his shift, and means more satisfied customers at the end of the day.

The application is “nudging” Sam to carry out the tasks and jobs in the order that the centralised scheduling system has determined to be optimal, by requiring the lowest level of effort to follow that plan. However, Sam may be able to override that, and carry out work in a different sequence – one of his own choosing. But, it will mean more inputs, choices and manual navigation by him to achieve those overrides.

[quote]How can we use the power of a smartphone to unobtrusively assist our engineers in their daily work, enabling them to focus on delivering service to our customers?’

The underlying design principle of M/App is not ‘how can we get our engineers to fill out the head-office mandated forms better?’, but ‘how can we use the power of a smartphone to unobtrusively assist our engineers in their daily work, enabling them to focus on delivering service to our customers?’. It’s a simple change in approach, but that switch somehow changes everything.

 

So, come on application developers, the market is ripe for some innovation. Over to you.