When your business relies on revenue from services delivered in the field, your technicians need to operate as efficiently and effectively as possible. In the heavily regulated oil and gas industry, market forces, high-value processes and customer demands make productivity and efficiency all the more critical.
Learn how Applus+ RTD, a field service leader in oil and gas, enables its field workforce to improve technician productivity, customer service and reporting accuracy, while supporting safety and compliance initiatives.
View this webinar to learn how Applus+ RTD:
— addresses dynamic field service mobility
— manages time and expenses related to complex work orders
— integrates mobility into their field service platform to maximize usability
— accelerates billing cycles
— architects, scopes and deploys mobile apps that enable high-value field processes
Presenters
Neal Ratner
Manager of Business Innovations
Applus+ RTD
Justin Boeckler
CTO
Mobile Reach
View Now
If you prefer, you can read the full webinar transcript below.
Mobile Reach: Well good morning or good afternoon depending on where in the world you are. We are glad you could join us for today’s webinar. Today we will hear from Applus+ RTD, a leader in the energy sector, and learn how they are transforming and improving service delivery across their mobile field workforce. I’d like to introduce our presenters for this morning. From Applus, we have Neal Ratner. Neal is manager of business innovation systems and is responsible for the ongoing effectiveness of Applus’ field technicians. Neal works with customers and field inspection teams to ultimately improve productivity through technology. And, among other areas, he owns the mobile inspection initiative for Applus+ RTD’s large field force. Over his career, Neal has accumulated more than 20 years of experience in IT infrastructure, 10 years in software development and eight years in data science. Thanks for joining us today, Neal.
Neal: Excellent, thanks for having me.
Mobile Reach: And from Mobile Reach, we have Justin Boeckler. Justin is Mobile Reach’s chief technology officer. In that role, he establishes and manages the strategic direction of product management and R&D, including the development and design of Mobile Reach’s current products and solutions, and of course future roadmap efforts as well. Justin will be running the demo portion of today’s webinar. Thanks for joining us today, Justin.
Justin: Yes, I appreciate it. Looking forward to it.
Mobile Reach: So without further adieu, Neal, take it away.
Neal: Thank you. Just for a little background information I will go ahead and introduce what we do as a company. Applus is a global brand and we’re one of several divisions across the globe. As a common underlying theme, we perform inspections. In North America, we focus mainly on the oil and gas industry, but we do have some divisions that also inspect for the aerospace industry and DOD as well So, we have a varying number of needs.
And with Mobile Reach, one of our first requirements for working in remote areas as we do, all the mobile apps have to have the capability to be offline. So, we have some pretty stringent requirements. When someone has to go out and perform a mission-critical inspection, whether it’s offline 5 percent of the time or 50 percent of the time, we have to plan for those types of things. We’re in all these different remote areas. In North America, we are around 1,300 to 1,400 employees right now. Back before the oil and gas industry kind of went down, we were up to around 2,500 to 3,000 employees. We do anticipate a turnaround, so probably in the next 3 to 5 years, we’ll be back around that 2 to 3,000 number again with just the field personnel and inspection folks just in North America alone.
Moving on, the next slide explains what it is we actually do. You can see our inspectors out in the field and get an idea of why we have these offline requirements and why it’s nice to start being able to standardize our business processes. Our field technicians could be on a platform or in a refinery. They could be in a ditch in a canyon in the hills out in the middle of nowhere.
We also invent different types of inspection equipment, and we have numerous different ways to perform inspections. What we do is actually called non-destructive testing (NDT), So, basically, we use different types of ultrasonic testing or even X-ray. So for instance when you go to the doctor and you have the nurse go behind the wall. We actually have to cordon off areas and let the Nuclear Regulatory Commission (NRC) know where our folks are at all times. Because in order to perform X-ray, with the resources you need, if somebody gets into an accident on the side of the road, a HAZMAT team is called out. So, we have to be extremely careful. We have everything from vehicle inspection logs to real-time monitoring of where our technicians are and even how fast they are driving. So, it’s a pretty comprehensive ecosystem as far as the ecosystem of mobile applications we have already built and that we have to build continuing on over the next few years.
So, just kind of jumping in here, let’s look at standardization as far as business improvement. People always talk about business improvements. And our focus at Applus wasn’t just, “OK, let’s just improve things, Let’s just jump in and make things mobile.” We knew upfront that just using a mobile app doesn’t necessarily make you a better field technician. We knew we had to standardize.
Here’s a little backstory. In 2007-2008 in North America, we only had about 50 technicians. As you saw previously, now we are up over 1,400. We have bought many companies and have grown quite a bit and across many regions. Throughout that time, we’ve fragmented our processes. We had many great companies who performed their work really well. And when we brought them into the fold, that’s great. But now we have individuals who are just doing their way of work. And we don’t want to lose that, obviously, because they were a great success, that’s why we brought them into the fold in the first place. At the same time, we only need to take the great parts of what they do and the great parts of what other companies do and find this new super path, essentially. So, as we’ve been buying companies over the last several years and we have a big issue with so many fragmented processes. Even within the business unit, we’ve found with individual customers, we got, “This is how we will bill this customer and this is how we bill for the customer, and this customer gets this invoice and this customers gets this spreadsheet and this email and so on and so forth.”
If any of you deal with the oil and gas folks, or any kind of service industry where you have bigger companies likes that, a lot of times in order to have a better a voice to the customer we want to work with their processes as much as possible. We had to keep all those things in mind. Migrating all of those groups to one similar mobile inspection process was a big deal for us and it was the only way for us to build the foundation for business intelligence. And by that I mean we can’t start improving until we have a baseline. Once we have this baseline, whether it’s good or bad, now we can start tracking and marking improvements.
Moving on, so for just our recent project objectives, we wanted to standardize our base inspection processes. We have approximately 50 different types of inspection processes for everything from pipelines to equipment, even construction facilities, things like that. So, we wanted just some of our base inspection processes. There are about eight inspection processes in North America that are the base or conventional NDT. We wanted to standardize those across our business units. We wanted to improve our voice to the customer. We wanted to reduce our invoicing time. We wanted to increase reporting accuracy and efficiency. And we also wanted to enable our workforce. We wanted to give our workforce this mobile ability to work everywhere and not have to worry about all of the paper forms and the paper trail. Sometimes when just filling out a form, we literally had technicians getting postage and mailing in reports because of the locale of certain areas. We really wanted to start speeding up that process.
One of the things we didn’t want to worry about was: “Well we’re Android now what happens when we move to iOS, or what happens if we have a Microsoft Surface or what if they are on a laptop?” We needed a cross-platform solution. Keeping all these things in mind, that’s one of the main reasons why we wanted to work with a company like Mobile Reach. We ended up choosing Mobile Reach because they facilitated that cross mobile platform ability for us quite nicely.
So, some of the benefits we were going to get from this initial project included creating work reports and invoicing. When a guy goes out in the field and he creates a ticket, in the past that was a paper trail. Now it’s a workflow performed with the mobile app. We wanted to integrate that app directly with our ERP system, so we didn’t have to have so much office overhead, as far as people just querying the ERP, creating work orders or work reports, then passing that out to the guys, then consuming that then back and forth and back forth. We saw a huge improvement there in just speeding that process up.
We also wanted to provide our supervisors and managers with more transparency. We have project managers but they had no idea of what costs were, overhead, overtime, or double time things like that. We have all these different types of concerns when we send these guys out to work and the managers had no idea of what these costs were. And now we are able to provide them that type of transparency because we have a better correlation of what’s going on right now. We wanted to know how many actual billable hours did you have and what’s your actual billable rate? And then better visibility into the actual process. Now that we have metadata in the background, now that we can see how long it takes how long to perform certain tasks, we know how long the process takes and we can more accurately estimate our projects going forward.
Then as far as time entry and expenses, one of the biggest drives behind this, outside of just the paper trail, was the state California. If any of you deal with labor in California, you’ll know it’s difficult at best. Us and many companies went through troubled times in the last couple of years trying to facilitate and meet the requirements of California and it’s extremely expensive. We were going through audits and the auditors are asking us, “OK you have a guy out in the field in the middle of nowhere who has no internet connection, he just put down for lunch 12-1. Was it really 12 to 1 or was it 12:05 to 12:07?” You know going back a year or two years, this is a very difficult thing that California is asking us to do. How do we trace this exact time measurement, this clock-in, and clock-out mentality, for someone who’s out in the field in a caustic environment?
So definitely one of the biggest hurdles that we had in the project, as you’ll see more in a minute, was getting consistency in reporting. Just getting the work time and everything into the system, and as we said before, improving data accuracy.
So looking at all these things we were at Stage 1, or reactive. And if any of you are going through this process, or have looked into the process, or are already in this process, I’m sure someone in the company or maybe yourself is a Six Sigma. There’s probably some type of business improvement manager that has put some type of maturity model together, and you should. What we’ve found though, after years of doing these types of things, is that while you can kind of define these into phases or stages of development and implementation, it never really follows that arrow exactly. While this is absolutely something good to document, you need to know what your goals are, and you also have to be flexible and be able to adapt to what’s going on.
In our software development environment, we use an Agile methodology. For those of you have worked with Agile methodology, it allows us to be a little more flexible and if we hit a roadblock, we can shift gears and make things happen regardless. So, don’t be afraid and don’t worry about, “Hey we think everyone in our company should move from Phase 1, or from reactive to managed or managed to automated.” You may have certain portions or groups that are all the way in dynamic, and then you still may have groups all the way back in reactive. We still have that right now. We have people in billing and invoicing all the way up to Stage 4. But we still have field service technicians who still have not been 100 percent migrated all the way to the mobile app yet for varying reasons. Maybe they are putting work time in but not all of their inspections or maybe their inspections haven’t been created yet on the mobile application. So again, don’t worry about trying to move everyone in the entire business over to each stage all at one time. It’s a great goal but it’s probably just not gonna happen that way and that’s OK.
So keeping that in mind, let’s move on and explain what we did. To start off with, this actual project had its inception about four years ago. It started with work reports which tied to our ERP, and our time entry tied to ADP. We had expense reporting tied to a couple of different systems, some ADP, some Concur, and some completely manually tracked.
Our conventional NDT forms that we talked about, again we had eight different types of inspections. But what we found when putting this plan into place was that while there were eight different types of inspections across our business units, we had misalignment. We found that eight different inspections turned into about 20 different forms. That was a problem, as you’ll see in a few minutes. And then there were HSE forms. For those of you don’t work in the oil and gas and manufacturing industries, HSE helps with safety. Anytime we go out anywhere, we do vehicle inspections and we keep mileage logs. We perform every kind of assessment. And not just for the day, but when we move to our different environment, we perform a job site safety assessment. Some call it technical safety assessment, some call it hazard safety assessment. There are varying different names. I’m sure if you’ve got folks out in the field, you probably have something like this.
At the end of the day though, we already had those forms and we wanted to try and move those in as well. It does not seem like a big chunk, but moving on to Version 2, as we moved into development, we started realizing that we needed to pull back a bit. This is a lot that we’re actually doing. We’re connecting into a lot of different systems and we’re doing a lot of different things. So, while health and safety forms are important, we already have the forms and we have entire groups dedicated and a good process around that, so we shelved that and saved that for a later phase. We can mobilize that at a later phase. Of all the different services, that was probably the most standardized so we decided to focus on the inspections, work orders, and time tracking.
So, we moved on to Version 3 with no more HSE forms. But you know what? We realized these NDT forms with eight different types of inspections required 20 different forms. Now we started to realize there was even more misalignment. And we needed to take a step back. It was delaying our development and causing problems. So we said you know what, let’s put this back to what we call our stakeholders, or our product owners. Let’s kick it back to the subject matter experts who know what’s going on with these forms and let’s task them with getting us eight different inspection forms. Let’s get away from the 20 different forms, give us 8 different forms that we can use globally and we’ll build them smarter so that all the different business units and everyone can use them.
Again remember, we had all of these different companies and everybody thought they did it the right way. And they did, but we have to find a way for everyone to do it the same way. And so that was something that was taking us too much time, and again, we wanted to at least get it on the ground and build what we call the minimum viable product. We wanted to get something into the field tech’s hands so they could start using it and we could start seeing our ROI.
So moving onto Version 4 there were no more NDT forms. Now its just work reports, time entry, and expenses. But that stuff with California kept coming up. And we also found out that ADP came to us and said, “You guys are on an old platform at ADP, we need to migrate you and that’s going to take several months.” Well since expenses were tied to ADP and payroll, those got pulled out. So what we went through was the actual living process of getting to a minimum viable product. What we started with was those five different parts, and we got down to just work reports. Let’s just get our invoicing done so our field technicians can at least bill for what they are doing, right then and there. We can sign the ticket on site and we can bill that day. Which is something we could never do before. Sometimes we’re billing the customer 20 or 30 days later because of lags getting into the office, verifying paperwork, things like that. So, we just focused on work reports. So that’s Version 4.
On Version 5, we started field testing. Out stakeholders came back to us and said we have these CMDP forms. We’ve got these forms done. We’ve standardized them. We think we are ready for those now. So we have field technicians out in the field working with the work reports, they brought back the NDT forms and said we can do these again. We said OK, great. We developed them, we made them exactly how they wanted. Here are your work reports and your NDT inspection forms. Now, this is great, we can do our actual inspection, perform the inspection, and invoice it, and provide the customer report all on the same day. This is something that no other company is doing right now, This is fantastic.
Except what we found is when we actually put this out into field testing, we found the capacity for our field technicians to do work didn’t actually improve. In certain areas, even in some of our smaller regions, we still have 60 to 70 to 80 technicians, some of the groups were 2, 3 or 400 technicians. So it’s not easy to just roll this out to five guys. So we had to go in and look at this and as we started field testing, we found that the inspection time was getting really long, even though they knew how to go through the form very quickly. And we didn’t change the form from theoretically. It was just the pure change of going from paper to a different device. Imagine just going from one paper form to another paper form. Some guys had been working with the same paper forms not just for a few months and not just for a few years. Some of these folks have been doing for this 10-15 and even 20 years, So how they work with these forms was so ingrained in their nature, it was still a big change for them.
Even though the mobile apps were exactly what they wanted and we gave them everything that the needed, they came back to us and said, “We know we asked for this, so let’s go back to just work reports.” We said, “OK let’s go back to just work reports.” OK, so we took out the inspection forms, but in that time, we also found that you know what, we finished our ADP integration, and we are able to add back in time entry and expenses. Which is really just a simple little thing. That was actually already on their invoicing and tickets before. So again, that was a small enhancement that we worked with them on and they were able to digest. So that was version six of the mobile apps, and that’s actually live out in our field right now with several hundred technicians. And right now we are in the middle of small field testing. We’ve moved to some smaller groups who have been working with mobile applications and things for several years.
And moving onto Version 7, we’ve started to bring back the NDT forms with a smaller group that was a little more adept at working with all of this different technology and weren’t so ingrained into the paper forms. So, kind of going through all of this, I realize I explained a lot and it took a few minutes. But I wanted everyone to kind of realize, if you haven’t started down the road with these things, don’t be afraid of adversity and don’t be afraid of failing. Don’t be afraid of listening to the feedback you get from the field and making changes, even if something’s done. Even if it’s exactly what they asked for, sometimes they come back and say, you know what, it’s just too much.
So, getting into this rapid configuration and deployment and talking about the Agile methodology, we were able to work with Mobile Reach and their AppStudio tool, which is the product that really helps build all this mobile information flow. And again, we have people, we invested, and we actually used App Studio in-house as well. But we’re a small group so we actually work with Mobile Reach and they helped us build these applications as well, so it’s a great work relationship for us. Because as an enterprise field support organization, we just can’t hire 20 or 30 programmers. We need outside help and we don’t want to work with just open-source tools out there. We want a company that understands the needs of the enterprise. For us, Mobile Reach allowed us to use fewer internal resources to meet the expanding mobile needs of the business.
Again, there’s minimum overhead for us internally to manage application security because we’re working with a mobile platform and not necessarily all of the servers, and all of the databases, and everything that has to happen. We just need to worry about what matters most to us, which is the forms, the inspections, the billing invoices, things like that. Now we can focus on release management and be making continuous improvements. In our planning phases now, we actually plan to roll-out to business units, and before we move on to another business unit before we do anything, we already have it built into our release management. We assume each business unit is going to have some micro updates. They are going to have small changes or things that need to be tweaked a little bit. So rather than just assuming, “Hey we built this once and everyone is going to love it,” we didn’t want to make that assumption because that’s a recipe for failure. What we found was let’s give them what we think they need, build that minimal viable product, gets some feedback and then enhance it. If we try and think of everything that these guys are going to want, we are never going to be able to release the mobile apps. So, if I can impart anything to you guys is our Agile approach. You can look this up, there’s a whole methodology. If you look at the project management folks, there’s an Agile methodology, there’s a whole SCRUM Alliance. And SCRUM is not just software development, it’s for business improvement practices as well. There are many different ways to approach it.
“Genchi Genbutsu” (see where the work happens) is something that Toyota actually implemented many years ago and you folks can look that up as well. And we implemented that a long time ago also. It’s so important for us, because, we’re sitting in the office in the middle of America. We have so many different technicians in so many different environments. We just can’t understand what they are going through from the office, or even just walking outside. We have to go where they are doing the work. We know to go out to those ditches, go out to those fields, go out to those refineries, and we need to go to those manufacturing facilities. We need to find out what they are doing and watch how they are using the mobile apps. Maybe they have poor sunlight. Maybe it’s really hot. Maybe out in California it’s 110 degrees and really bright out. And in Houston, where I am, it’s raining half the time. So these are things you need to consider in how you build your applications. Is the contrast good enough? Are the buttons big enough? Little simple things.
So kind of wrapping up that concept of MVP, if you look at this we had an idea, we built the idea, we deployed the idea with our MVP. We started getting feedback, we measured, and then took the data in, learned what we had to learn, then created a new idea and enhanced, and this was a circular process. So again, I don’t want you to think you’re going to have to spend millions and millions and millions of dollars on development. But you’re never going to be able to build one product and then never have to develop it again. Those are the types of products that we are replacing right now and it’s a struggle because things were built back in 2003, 2005, 2007 and then they were left alone for years. And now we have people coming to us saying, “Hey this doesn’t work anymore.” Well this was actually designed to work on Windows XP, which hasn’t been supported for over a decade, so I don’t know what else to tell you. These are the types things we run into all the time.
So just thinking about those things, don’t be afraid of breaking it down to that minimum viable product. Remember, we broke it down to just work reports. And with that in mind, Mobile Reach actually works very much in that same way. So through our relationship with Mobile Reach, these are actually some the products that we requested. And again, not making any promises here, we were pretty vocal and we made a good case for it. But these are some pretty big things we asked for that really didn’t exist outside of what we had seen from a mobile app perspective. We hadn’t seen any offline PDF generation tools that came directly from an app. We could use Adobe directly and just fill out a form but that was not very dynamic and we saw from our feedback that people weren’t working with that very well.
So from our mobile application are creating offline PDFs. And Mobile Reach designed this for us, so it was really fantastic. We came up with the data grid view, which is just a view that our folks wanted to have. We took the platform that we work with that already builds applications in kind of a WSIWYG way (what you see is what you get) and we are able to take that and automatically build that layout in the Mobile Reach platform. This really led to the rapid deployment of the mobile apps. So these guys really helped us by implementing some of these things and developing the capabilities of the platform around our needs. Again, I’m not making any promises, but we also felt it didn’t hurt to ask.
So, with that, I’ll turn it over to Justin and he’ll show you some of the apps that we deployed to our field engineers and techs.
Justin: Thanks, I appreciate it. Kind of along the same lines, we very much like to hear from our customers, and we build a lot of our feature set based on that feedback. That’s how we’ve gotten to this point and built our mobile platform. Instead of just going out and building what we think everyone needs, we find it better to listen to our customers and adapt to their needs.
So to start off, what I’m going to do, these aren’t the exact mobile applications that we deployed at Applus. But they are very similar. We have genericized it so they sort of represent what Applus has already deployed. I’m using this tool called Reflector and it can be finicky so I apologize if there are any lags or delays. The first mobile application I’m going to show is a field inspect application. The field inspect app is designed to take some of these paper inspections that Neal was mentioning and replicating them onto an iPad. But these same applications can be pushed to phones or to tablets, whether they are Android or iOs or Windows tablets.
And the idea is that they are going to collect information within the application, get it to a point where that data is collected. And then they are generating some of those capabilities we’ve built for them around generating a PDF offline and being able to represent that, take the data that was collected in the mobile app and push it into that pre-built template PDF. And then they’ll get sign off and delivery to their customer as proof that this work that was performed while we’re out in the field.
At a high level, the way our solution works, if I drop back to the main screen, you’ll notice this MR icon is represented there. Initially, when you launch the application you’ll be presented with a login screen that the user would enter their credentials. Based on their credentials, they would automatically getdeployed one or more applications. So l’ve already logged into the app and what you are seeing is a number of these icons and each represents a different workflow or different application that have been automatically activated within my MR client. And these are what got delivered.
For example, if I was logged into the Applus servers, I would get three different applications. I would get the work order app. I’d get the NDT application and the time tracking app. In our case, I’ve got a number of out-of-the-box applications that map to different processes from enterprise asset management down to field force or field service type activities. The one I’m going to be focusing on today is the field inspection application which is very similar to the NDT applications that we built with Applus. Really, we were able to take a lot of the design and worked with Neal and his team to take a lot of the feedback and very specific design requirements. Because they went out in the field and they worked with their customers and their employees and field techs to figure out what works and what will appear the best.
Then, from their perspective, they wanted a very finger-friendly type of mobile application that would be represented with a high contrast look and feel. And again their screens are a little more robust than this is showing as their app has a lot more inspections built out. But the idea is you come to this launch screen, then you would select the type of inspection. So we select the structural inspection which jumps you into that particular inspection. Here you have a choice of reviewing inspections you have done previously, as well as creating a new inspection. And, when you jump into this view, we took a lot of the icons and concepts that Applus and Neal’s team actually provided us to incorporate into the application.
Across the bottom, you’ll notice that there’s different buttons. Each of these buttons will change the view that’s currently been selected. So I can navigate through this application and go back to the start if I want to select a work order, select a customer, and some of this might be copied in directly from the work order, and then select then technician that I want to assign this to. The location might be filled out automatically by the GPS coordinates of the individual. I can put in some project notes, examination details, you know, what area am I going to actually inspect? And, all this data is coming out of their system. So they can define, even though the structure of this application is already set up, a lot of the data elements that are coming from the back-end system that we are uploading and pushing and pulling this data to and from.
Then once I get to the inspections, they might have multiple components and different types of inspections they perform under this one overall structural inspections. So they can jump into another layer or they might be taking pictures of hazards, or snapping a photo of an issue and attaching that in. I can then come in and fill out some additional details and perform a checklist, if needed, then go ahead and save this. Now the inspection was created in association to this overall structural inspection. And they get to a point where they have completed the inspection and they are ready to get sign off on the job.
So the technicians might sign for it and the customer might have a point of contact signature that needs to be collected. You might want to indicate what level or what type of individuals are actually signing off. Is there a field engineer or something of that nature? Then they are going to generate a report. They get an option to email this out to the customer, so I can answer yes to this or I can just view the inspection report. And you’ll notice all of this data is being pulled out of the mobile application and pushed into this PDF in addition to the signature as well as any of the related inspection details that were created during this inspection report. Then once they save this, all this data is immediately pushed back into their system where they can do data mining and get different analytics off it as well then pull the information and send it to bill their customer.
So that’s just one example of a mobile field inspection application. The biggest take away to all of this is that we have a mobile platform. We can take in those requirements and either you as a customer can leverage our AppStudio tool to build your own mobile applications or we can help you through that process. The product is very flexible. We have a number of our template applications that we can show, so if you are interested in seeing more definitely let us know. Would be happy to talk about your processes and walk you through some more demonstrations for applications that might match those. You can set up a demo for your field service team by clicking here.
Mobile Reach: Perfect, Justin, thank you that’s excellent. I appreciate the demo and I appreciate the excellent talk though on the on the Mobile Reach platform. And Neal thank you also for a great story behind all the lessons learned through deploying mobile apps to your field force. Just a reminder for everyone we do have time for questions. We have a few coming in so I’d like to go ahead and jump to those now, actually. We can certainly field more if you have them as we go.
So, this first one is actually for your Neal. Are your mobile apps using data from more than one platform and then how does that work from a UI perspective?
Neal: That’s actually a great question. We have several different databases and that was one of the biggest things we wanted to make sure in developing to begin with. We were working with an old version of Microsoft Dynamics for our ERP at the beginning. We are now in the middle of a three-year global migration to SAP. So we actually knew up front that we were going to have to change databases. And some business units would be on on Microsoft Dynamics and some would be on SAP. So our main focus was to build a platform that our users would never have to worry about what they were connecting to or how they are connecting and that it was completely seamless. So, if today we are working with one database and next year were working with a different database, they would never know the difference. We built it in a way dynamically and worked heavily with Mobile Reach to make sure we designed it that way so it could be flexible enough to switch databases on the back-end and not have to interrupt our normal workflow.
Mobile Reach: OK, so actually this next one is continuing in that same vain. The next one is about the PDF you are creating out in the field. The question is how are those PDFs you created out in the field saved? Is a copy captured somewhere in a company database?
Neal: So yeah, in fact, there’s a couple of different things going on with that. So, absolutely, we create them out in the field even if they are offline. When they get online, they are emailed or synchronized to our database. They can be emailed to your customer which often is a requirement. At the same time, they are automatically attached to the inspection record or the work report as well. Even so, we can also automate if we so choose. I always advise against emailing all of these notifications. Again, we have more than 1,000 technicians, and some of those technicians sometimes perform five or six types of inspections per day. That is a heavy inundation of a whole lot of emails to our customers. So rather than just try and barrage them with a bunch of emails, we just save it in the database. Also, we actually provide our customers with access to our inspections database and certain portions of the invoicing system so have better transparency and can be a better business partner.
Mobile Reach: Excellent. So, this next question is good to get perspective from both of you, Justin we’ll start with you. What’s the right number of technicians for piloting a field app?
Justin: Good question. I think it can depend on how the organization is setup because, as Neal mentioned, in their case they are a global organization and have different regions with different requirements. There’s probably not a right number. I would say you want to have your user-base equally represented. You just want all of the requirements sort of represented in that user base. So I wouldn’t pick five users all from one region. I would try to spread those across the entire organization.
Mobile Reach: OK, how about you Neal. How did you guys do it at Applus?
Neal: Yeah, I definitely agree with Justin. You know, again, you may be continually performing beta tests throughout. So, we basically implemented and used technologists or champions. In each of our regions, we identified champions to help us not only test the product for the region and with their specific needs but also who helped others. So, we implemented the train the trainer methodology. I will definitely say you need more than one tester. But at the same time, don’t feel that you need to get input from 50 people from one region. Keep it realistic and keep in mind the minimal viable product. You are always going to get feedback when it’s in production anyway. So make sure that it works. Make sure it meets the immediate requirements that you have and get it out there. And then start getting the feedback and start watching how they are using it. So, you know again, definitely more than one but don’t got overboard on getting too many people involved.
Mobile Reach: Excellent, that makes a lot of sense you guys, thank you for both of those perspectives. We are right at 45 minutes past the hour so let’s finish with one more question and this one’s for you Neal. How does you mobile deployment support your compliance initiatives?
Neal: Actually that’s a two-fold question. So, not only do we have our own internal compliance but we’re a publicly traded company. We have obvious reporting that we have to do not only internally but globally. So from our ERP standpoint and things like that, this is helping too solidify all of our internal reporting and compliance needs now because instead of tracking all of those things down in an Excel spreadsheet, everything is in a database now. And not only that but it’s tied right our ERP so it’s very nice in that respect.
The second part of that is that we are a third-party inspection company. By definition, what we do is actually a compliance component for our customers in oil and gas, and even aerospace. Think about all that goes into an airplane that has to be inspected, that has to be documented, that has to be audited. You have all of those different things and we are the third-party environment that provides all of that documentation and provides proof of that documentation. So, in our databases and in our systems, we have information and are often looking at equipment from over 100 years ago and we have to define safety factors on this. Is it safe for operation? All these different things, and these are mission critical components from our customers. So yes, compliance is in everything we do, certainly not only internal but external as well for our customers.
Mobile Reach: Great, thanks for that Neal. I apologize for not getting to every question this afternoon. We will certainly follow up with you on those directly. Thank for you both very much for your time today, Neal and Justin. We appreciate your spending this 45 minutes with us on the webinar today. And we wish all of the rest of you a very pleasant day. Thank you all.
Learn more about fully enabling your field techs via our comprehensive guide to mobile field service apps.