Field Force Automation with BMC Remedy
BMC’s Remedy platform may not be the first enterprise application that springs to mind when it comes to field service; however, many large field service organizations are using it for exactly that.
We recently sat down with Cecelia von Tiesenhausen-Hush, a business process analyst at Rockwell Collins, to talk about how Rockwell enables their field techs at airports around the globe using Remedy and Mobile Reach apps. We also included Nasrin Azari and Justin Boeckler in the conversation, the CEO and CTO at Mobile Reach, to lend their perspectives on field force automation best practices.
How are organizations using BMC Remedy as a platform for field service management?
Cece: We use Remedy at Rockwell Collins to keep terminal and ground operations running smoothly at airports around the world. Our field techs rely on data and information in Remedy to resolve incidents related to ticketing kiosks, information displays, printers, and many other types of hardware. When a traveler moves through an airport, they are interacting with things that Rockwell Collins manages. All of that is handled with our Remedy instance and apps from Mobile Reach.
Nasrin: When people think of Remedy, they think of IT service management, because Remedy is the leader in the ITSM market. But many organizations that make money selling services to customers also use Remedy for their field service organization, taking advantage of the similarity between ITSM and FSM disciplines. Ultimately, a service is being requested, managed, delivered, and resolved. This makes Remedy a natural platform for field service management. And, from the field perspective, mobility underpins both ITSM and FSM in a similar way. Organizations need to create well-defined processes for field personnel to manage incidents and/or work orders, track equipment, record time & expense, capture signatures from customers, etc. Mobile solutions that are task-focused and efficient and that meet the specific needs of each type of field worker, enhance the Remedy platform to support all types of field service organizations.
Justin: Most people don’t realize that Remedy is a platform and that you can build any application on it. At a high level, field service use cases are not that different from ITSM use cases. In both cases, you have work being performed away from the desk, and it is important to capture this work so the business can make informed decisions. Mobile Reach is being leveraged as the primary interface for the field workers, and Remedy is both the backend and the primary interface for the desktop workers. The biggest missing feature when it comes to Remedy and FSM is the need for automated dispatching, which can also be built using the Remedy workflow engine. Rockwell Collins built a Remedy application that calls into the Mobile Reach push notification service in order to send notifications about work order assignments to techs in the field, emulating dispatch capabilities.
How do you handle distribution of builds for mobile devices?
Cece: Our build was standard across the board. One of the things that worked very well was doing a gradual rollout when we were first training everyone globally to use the apps. Adoption and compliance were much higher that way.
Justin: We have established a best practice around this, and we develop our mobile platform to enable it. Knowing that large field service organizations are often complex, with technicians using any number of device types, we believe that apps should be built once and then be able to be deployed to any mobile operating system, whether it’s iOS, Android or Windows. This creates efficiency within the app configuration, increases supportability, and increases user adoption on the deployment.
How do you update the mobile apps, such as changing fields and menus?
Cece: Most of our changes are made on the Remedy side, and we push those out to the field through Mobile Reach’s deployment manager. We use the Mobile Reach AppStudio if we have major changes to make to the apps.
Nasrin: Because mobile solutions for field service organizations are a direct reflection of the mobile work processes that field technicians perform and because a field service environment is very dynamic, one of the most crucial components of a mobile solution for FSM is how easy it is to iterate the mobile apps themselves. Mobile field service apps should be designed to be modified in the future, multiple times, because change is inevitable. Mobile Reach provides a non-coding tool called AppStudio to allow our customers to rapidly make modifications to their mobile apps. Our primary goal for this tool is to make it easy to update existing mobile apps and roll out these changes to the field team.
Justin: All Mobile Reach deployments include AppStudio. This is a drag-and-drop app builder tool that our customers use to design, create, iterate on and deploy apps to their technicians. Any app is easily updated without the need for any coding or change requests to Mobile Reach. AppStudio allows users to configure and modify any aspect of their apps, including menus, fields, permissions, etc. We have a number of pre-built template applications that map to common field service use cases that allow for our customers to get into production more quickly. In addition, the integration we enable with backend systems allows for a lot of the tables and field nodes properties to be automatically imported into the tool, which further simplifies the app building process.
How do you handle mobile data security? Do you use VPN tunnels to connect to Remedy while offsite?
Justin: Mobile Reach has been deployed in a number of high-security environments. We take security seriously and have built high levels of security management into our platform. We protect data-at-rest by encrypting the device-side app cache with AES 256bit encryption. We protect data in transit by encrypting all communications with these same levels. We also protect the UI with in-app locking and password validation to ensure a device prompts the user to re-enter their password before allowing access. We’ve worked with our customers to implement many different user authentication methods, while leveraging various SSO configurations.
How do you manage assets and do barcode scanning via the mobile app? How about change approvals?
Justin: We have a full suite of barcode scanning templates that support a variety of use cases — receiving, inventory and audits, to name a few. We also can leverage scanning technologies like UHF RFID, NFC, camera scanning (1D/2D) and Bluetooth barcode readers. To make these technologies work seamlessly you have to build direct API level integrations and then have actions that can be leveraged in-app in order to process the data being received from the hardware. This gives our customers many different scanning options and provides scalability in case their needs change in the future. In regards to change approvals, we have a number of customers who run approval apps. While these apps are simple they can be very high value because in many organizations managers can be bottlenecks. The key to approval apps, as with most any UI, is keeping the interface simple. In approval applications, this is even more important because typically it’s very transactional where the user is popping in the app with the expectation that they want to ‘Approve’ or ‘Reject’ a request very quickly. Ensuring they have access to all the information they need so they can make their decision quickly and keep the approval chain flowing is key.
Cece: All of our equipment has company-specific barcodes. We use these directly in the app, whether a tech is using the scanning feature or entering it in manually. Most people use the scanning functionality because things are moving so fast in the field that its difficult to keep up if they don’t.
What’s the biggest challenge in designing a mobilized Remedy platform?
Cece: The biggest challenge we have is that the lack of complete standardization across work sites. Sometimes we have requirements that are site-specific, so we need to design something that works for that site but also doesn’t adversely affect the other sites. It’s a delicate balance between having something standard across the board while also customizing each site.
Nasrin: The biggest challenge in mobilizing Remedy, or any enterprise application for that matter, is to change your way of thinking about the solution design. Instead of thinking, “I want Remedy on a mobile device.” you need to look at the mobile users, what their job responsibilities are, and design a mobile solution that caters to those needs, which are likely quite different from the standard Remedy user’s. When you start looking at a mobile solution from the backend, with existing functionality and features at the forefront of thought, resulting mobile apps tend to feel cluttered, complex, and very difficult to use. Instead, mobile apps need to be viewed from the perspective of the mobile user and his/her responsibilities. The user experience on a mobile device needs to be straightforward, process-oriented, and as simple as possible.
Justin: There could be a lot of challenges to implementing a mobile Remedy app because building a robust integration could take time. At Mobile Reach we’ve already put the work into building a solid integration architecture that leverages Remedy as much as possible. So I would say the biggest challenge is taking a complicated process and trying to distill the complex scenario into one or more simplified use cases. This is a primary design goal our team has when working with customers.
What features of your mobile app are most useful for your service team?
Cece: Our technicians at Rockwell Collins really like to have all the information they need to handle an incident before they even get started on the job. We work at many of the largest airports in the world, and techs often need to walk a mile or more to get to the site of an incident. They don’t want to walk that mile, realize they forgot a part or a tool, and have to walk all the way back to get those things. They know what they need before they accept the ticket so they’re fully prepared to solve the issue the first time around.