This series of penetrating discussions on the latest in enterprise mobility explores advancements in applications design and deployment technologies across the full spectrum of edge devices and operating environments.
Our next innovator interview focuses on how Source Refrigeration and HVAC has been extending the productivity of its workforce, much of it in the field, through the use of innovative mobile applications and services.
Listen to the podcast. Find it on iTunes. Get the mobile app for iOS or Android. Read a full transcript or download a copy.
We'll delve in to how Source Refrigeration has created a boundaryless enterprise and reaped the rewards of Agile processes and the ability to extend data and intelligence to where it’s needed most.
To learn how their successful mobile journey has unfolded, we welcome Hal Kolp, Vice President of Information Technology at Source Refrigeration and HVAC in Anaheim, California. The discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.
Here are some excerpts:
Gardner: It’s my understanding that you have something on the order of several hundred field-based service and installation experts serving the needs of 2,500 or more customers nationwide. Tell us a little bit about why mobility is essential for you and how this has created better efficiency and innovation for you?
Kolp: Source started to explore mobility back in 2006. I was tasked with a project to figure out if it made sense to take our service organization, which was driven by paper, and convert it to an electronic form of a service ticket.
 |
| Kolp |
At that time, the goals were pretty simple. They were to eliminate the paper in the field, shorten our billing cycle from 28 days to 3 days, and take all of the material, labor, and asset information and put it into the system as quickly as possible, so we could give our customers better information about the equipment, how they are performing, and total cost of ownership (TCO).
But over time, things change. In our service organization then, we had 275 guys. Today, we have 600. So we've grown substantially, and our data is quite a bit better. We also use mobility on the construction side of our business, where we're installing new refrigeration equipment or HVAC equipment into large supermarket chains around the country.
Our construction managers and foremen live their lives on their tablets. They know the status of their job, they know their cost, they're looking at labor, they're doing safety reports and daily turnover reports. Anyone in our office can see pictures from any job site. They can look at the current status of a job, and this is all done over the cellular network. The business has really evolved.
Gardner: It’s interesting that you had the foresight to get your systems of record into paperless mode and were ready to extend that information to the edge, but then also be able to accept data and information from the edge to then augment and improve on the systems of record. One benefits the other, or there is a symbiosis or virtuous adoption cycle. What have been some of the business benefits of doing it that way?
Kolp: There are simple benefits on the service side. First of all, the billing cycle changed dramatically, and that generated a huge amount of cash. It’s a one-time win, whatever you would bill between 3 days and 28 days. All of that revenue came in, and there was this huge influx of cash in the beginning. That actually paid for the entire project. Just the generation of that cash was enough to more than compensate for all the software development and all the devices. So that was a big win.
But then we streamlined billing. Instead of a biller looking at a piece of paper and entering a time ticket, it was done automatically. Instead of looking at a piece of paper, then doing an inventory transfer to put it on a job, that was eliminated. Technician’s comments never made it into our system or on paper. They just sent a photocopy of the document to the customer.
Today, within 30 seconds of the person completing a work order, it’s uploaded to the system. It’s been generated into PDF documents where necessary. All the purchase order and work order information has entered into the system automatically, and an acknowledgement of the work order is sent to our customer without any human intervention. It just happens, just part of our daily business.
That’s a huge win for the business. It also gives you data for things that you can start to measure yourself on. We have a whole series of key performance indicators (KPIs) and dashboards that are built to help our service managers and regional directors understand what’s going on their business.
Technician efficiency
Do we have customers where we're spending a lot of time in their store-servicing them? That means there is something wrong. Let’s see if we can solve our customer’s problems. We look at the efficiency of our technicians.
We look at the efficiency of drive times. That electronic data even led us into automatic dispatching systems. We have computers that look at the urgency of the call, the location of the call, and the skills necessary to do that service request. It automatically decides which technician to send and when to send them. It takes a work order and dispatches a specific technician on it.
Gardner: So you've become data-driven and then far more intelligent, responsive, and agile as a result. Tell me how you've been able to achieve that, but at the same time, not get bogged down in an application development cycle that can take a long time, or even find yourself in waterfall-type of affair, where the requirement shift rapidly, and by the time you finish a product, it’s obsolete.
How have you been able to change your application development for your mobile applications in a way that keeps up with these business requirements?
This
last year, we converted to the Kony platform, and all indications so
far are that that platform is going to be great for us.
Kolp: We've worked on three different mobile platforms. The claim in the beginning was to develop once and just update and move forward. That didn’t really work out so well on the first couple of platforms. The platforms became obsolete, and we essentially had to rewrite the application on to a new platform for which the claim was that it was going to survive.
This last year, we converted to the Kony platform, and all indications so far are that that platform is going to be great for us, because we've done a whole bunch of upgrades in the last 12 months on the platform. We're moving, and our application is migrating very quickly.
So things are very good on that side and in our development process. When we were building our new application initially, we were doing two builds a week. So every couple of days we do a little sprint up. We don’t really call them sprints, but essentially, it was a sprint to add functionality. We go into a quick testing cycle, and while we're testing, we have folks adding new functionality and fixing bugs. Then, we do another release.
At the current stage where we are in production really depends on the needs of the business. Last week, we had a new release and this week, we're having another release as we fix some small bugs or did enhancements to the products that came up during our initial rollout where we are making changes. It’s not that difficult to roll out a new version.
We send an alert. The text says that they have got a new version. They complete the work order that they're on, they perform an update, and they're back in business again. So it's pretty simple.
Field input
Gardner: So it's a very agile, iterative, easily adaptive type of development infrastructure. What about the input from those people in the field. Another aspect of agile development isn’t just the processes for the development itself, but being able to get more people involved with deciding features, functions, and not necessarily forcing the developers to read minds.
Has that crept into your process? Are you able to take either a business analyst or practitioner in the field and allow them to have the input that then creates better apps and better processes?
Kolp: In our latest generation application, we made tremendous changes in the user interface to make it easier for the technicians to do their job and for them to not have to think about anything. If they needed to do something, they knew what they had to do. It was kind of in their face, in other words. We use cues on screens by colors. It’s something that's required for them to do, it’s always red. If there is an input field that is optional, then it’s in blue. We have those kinds of cues.
We also built a little mini application, a web app, that's used by technicians for frequently asked questions (FAQs). If they have got some questions about how this application works, they can look at the FAQs. They can also submit a request for enhancements directly from the page. So we're getting requests from the field.
If they have a question about the application, we can take that question
and turn it into a new FAQ page, response, or new question that people
can click on and learn.
If they have a question about the application, we can take that question and turn it into a new FAQ page, response, or new question that people can click on and learn. We're trying to make the application to be more driven by the field and less by managers in the back office.
Gardner: Are there any metrics yet that would indicate an improvement in the use of the apps, based on this improved user interface and user experience. Is there any way to say the better we make it, the more they use it; the more they use it, the better the business results?
Kolp: We're in early stages of our rollout. In a couple of weeks we'll have about 200 of our 600 guys on the new application, and the guys noticed a few things. Number one, they believe the application is much more responsive to them. It’s just fast. Our application happens to be on iOS. Things happen quickly because of the processor and memory. So that’s really good for them.
The other thing they notice, is that if they're looking at assets and they need to find something in the asset, need to look up a part, or need to do anything, we've added search capability that just makes it brain-dead simple to find stuff that they need to look for. They can use their camera as a barcode scanner within our application. It’s easy to attach pictures.
What they find is that we've made it easier for them to add information and document their call. They have a much greater tendency to add information than they did before. For example, if they're in their work order notes, which for us is a summary, they can just talk. We use voice to text, and that will convert it. If they choose to type, they can type, but many of the guys really like the voice to text, because they have big fingers and typing on the screen is a little bit harder for them.
What's of interest?
Gardner: We are here at Kony World, Hal. Did anything jump out at you that’s particularly interesting? We've heard about solution ecosystems and vertical industries, Visualizer update, some cloud interactions for developers? Did anything really jump out at you that might be of interest for the coming year?
Kolp: I'm very interested in Visualizer 2.0. It appears to be a huge improvement over the original version. We use third-party development. In our case, we used somebody else’s front-end design tool for our project, but I really like the ability to be able to take our project and then use it with Visualizer 2.0, so that we can develop the screens and the flow that we want and hand it off to the developers. They can hook it up to the back end and go.
I just like having the ability to have that control, and now we've done the heavy lifting. For the most part, understanding your data, data flow or the flow of the application is usually where you spend quite a bit more time. For us to be able to do that ourselves is much better than writing on napkins or using PowerPoint or Visio to generate screens or some other application.
It’s nice because ultimately we will be able to go use Visualizer, push it into the application, take the application, push it back into Visualizer, make more changes, and go back and forth. I see that as a huge advantage. That’s one thing I took from the show.
When your business says that you can't mobilize some process, it's
probably not true. There's this resistance to change that's natural to
everyone.
Gardner: With this journey that you've been on since 2006, you’ve gone quite a way. Is there anything you could advise others who are perhaps just beginning in extending their enterprise to that mobile edge, finding the ways to engage with the people in the field that will get them to be adding information, taking more intelligence back from the apps into their work? What might you do with 20-20 hindsight and then relate that to people just starting?
Kolp: There are a couple of things that I’ll point out. There was a large reluctance for people to say that this would actually work. When your business says that you can't mobilize some process, it's probably not true. There's this resistance to change that's natural to everyone.
Our technicians today, who have been on mobile applications, hate to be on paper. They don't want to have anything to do with paper, because it's harder for them. They have more work to do. They have to collect the paper, shove the paper in an envelope, or hand it off to someone to do things. So they don’t like it.
The other thing you should consider is what happens when that device breaks? All devices will break at some point for some reason. Look at how those devices are going to get replaced. We operate in 20 states. You can't depend upon the home office to be able to rush out a replacement device for your suppliers in real time. We looked pretty hard at using all kinds of different methods to reduce the downtime for guys in the field.
You should look at that. That’s really important if the device is being used all day, every day for a field worker. That’s their primary communication method.
Simpler is better
The other thing I could say is, “simpler is better.” Don't make an application where you have to type-in a tremendous amount of data. Make data entry as easy as possible via taps or predefined fields.
Think about your entire process front to back and don't hesitate to change the way that you gather information today, as opposed to the way you want to in the future. Don't take a paper form and automate it, because that isn't the way your field worker thinks. You need to generate the new flow of information so that it fits on whatever size screen you want. It can't be a spreadsheet or it can’t be a bunch of checkboxes and stuff, because that doesn't necessarily suit the tool that you are using to drive the information gathering.
Spend a lot of time upfront designing screens and figuring out how the process should work. If you do that, you'll meet with very little pushback from the field once they get it and actually use it. I would communicate with the field regularly if you're developing and tell them what's going on, so that they are not blind-sided by something new.
The simpler you can make your application, the faster you can roll it out, and then just enhance, enhance, enhance.
I'd work closely with the field in designing the application. I'd also be involved with anybody that touches that data. In our case, it's service managers. We work with builders, inventory control, purchasing people, and timecards. All of those were pieces that our applications touch. So people from the business were involved, even people from finance, because we're making financial transactions in the enterprise resource planning (ERP) system.
So get all those people involved and make sure that they're in agreement with what you're doing. Make sure that you test thoroughly and that everybody signs off together at the end. The simpler you can make your application, the faster you can roll it out, and then just enhance, enhance, enhance.
Add a new feature if you're starting something new. If you're replacing an existing application, it's much harder to do that. You'll have to create all of the functionality because the business typically doesn't want to lose functionally.
Listen to the podcast. Find it on iTunes. Get the mobile app for iOS or Android. Read a full transcript or download a copy. Sponsor: Kony, Inc.
You may also be interested in:
- Kony Visualizer puts mobile apps design control in hands of those closest to the business
- Mobility moves from 'nice to have' to 'must have' for large US healthcare insurer
- Kony executive Burley Kawasaki on best tips for attaining speed in enterprise mobile apps delivery
- Kony gives enterprises the means to make mobile development a force multiplier for business productivity
- Panel tackles how to make mobile devices as secure as they are indispensable
- Five ways to make identity management work best across hybrid computing environments
- As the digital economy ramps up, expect a new identity management vision to leapfrog passwords
- Mobile enablement presents challenges, opportunities as enterprises retool apps for the future now
- Standards and APIs: How to best manage identity and security in the mobile era
