Almost all shop management software is encrypted using an estimating management standard (EMS), which was developed in the early 1990s. Since then, data privacy needs have changed and many are arguing for a switch to a more secure data encryption standard.
A new standard—business message specification (BMS)—has been developed, but the switch has yet to happen due to the massive amount of time and financial resources required.
As the vice president of industry relations for AudaExplore, Rick Tuuri has had a front-row seat to the EMS-BMS debate. Prior to joining AudaExplore, he also worked for I-CAR and has been involved with the organization since the late 1980s, when EMS was in its infancy.
Tuuri recently spoke with FenderBender to explain the differences between the two standards, the problems associated with EMS, and the obstacles standing in the way of implementing the BMS standard.
Why was EMS created and what did it allow shop owners to do?
The Collision Industry Electronic Commerce Association (CIECA) was formed around 20 years ago to deal with the problem of creating a standard output. At the time, all the systems had a proprietary output. For example, you would have to use an estimating system on one computer, and a shop management system on a different computer because they had conflicting protocol. If you needed to load your estimating data into your shop management system, it was very difficult because the proprietary output from one didn’t understand the proprietary input from the other. It was just really cumbersome for not only the repairers, but also the entire industry.
CIECA was formed around that problem. What the industry needed was a standard output so that no matter whose system you were using, you’d be able to export data and import data into other systems and their protocols would be understood.
It was a massive undertaking to come up with a universal language standard in terms of how these systems talked to each other. Imagine if you had an AT&T phone and someone else had a Verizon phone, but you couldn’t talk to each other because one would translate your language into its own standard protocol and the other phone wouldn’t understand it. That’s essentially the way the industry worked for years before the EMS standard was created.
What are the problems associated with the EMS standard now?
I think what people are looking for is a better solution. It’s not that EMS doesn’t work, but what it does is transmit all the data. In an estimate, for example, all the data is transmitted through the EMS standard. That means the owners’ name, all the contact information, the insurers’ name, the description of the car, body of the estimate, every line and dollar value.
The issue is that there’s not an option to share only part of that information. If I want to take the estimate and produce an electronic parts order, I don’t necessarily want to send the customers’ information to the dealership; I only want to send them the parts that are necessary for the order. The issue with EMS is that it sends everything.
It’s a data-control and privacy issue. Whenever you implement technology to speed things up, it creates a different level of potential problems. Now we’ve got electronic data flying all over the place and our eyes have been opened to the possible misuse of information.
How is the information being misused?
A shop owner came up to me at CIC and said that somebody had come into his shop and told him, “I know what your margins are, I know how many parts you should buy, and here’s how I think you should change your parts buying.” By and large, that’s not the case. But a lot of people’s fears are that someone is going to use the data in a manner that hasn’t been disclosed.
What kind of rights do software subscribers have in their terms of usage?
When anyone licenses Audatex software, we have a licensing agreement in place that states how we can and cannot use your data. In short, it says we will not use your customer data and shop information without your expressed permission.
We will use the estimate information in reports that can be delivered to insurers, OEMs, and repairers, but only in aggregated format, which means your shop is anonymous.
So we do have measures in place, but they’re not physical measures that actually prevent transmission of data that might not be desirable to send to a particular party.
There is some legislation in place: The Gramm-Leach-Bliley Act of 1999 says that when an insurance company does business with any vendor, that vendor has to have privacy protocol in place. But that legislation is fairly old, if not cumbersome.
What are the benefits of a BMS standard?
The first solution was EMS, and that created this electronic blob of all the information that goes to anybody. What BMS does is segment the data into client data, insurer data, and estimate data, and gives you the capability to easily transmit the pieces of information you want.
If I decide I only want to send parts numbers and prices to the dealership, I can do that for an order. If I decide I only want to send the estimate data to the rental car company, I can segment that data and tell the system to send this one piece of information, but not the rest.
Right now, we have handshakes and signed agreements in place that dictate how we’ll use the data. But what BMS does is not only dictate how the data will be used, but it will also make sure that’s the only data the intended party will get. So you wouldn’t get the data that you weren’t licensed to use. To me that’s the real benefit from BMS.
Why hasn’t the change to the BMS standard happened?
What are the challenges?
It’s a matter of programming time and priorities. BMS hasn’t really taken off in the industry because everybody seems to look at the other segments as the ones that ought to start it. What it means as an information provider is the same thing implementing EMS meant in the early 1990s: a lot of programming work for no monetization. We did scope it out, and it is part of our future plan, but it’s a matter of prioritization based on return on investment. When we look at BMS, it’s going to cost us a few million dollars, and we’re not going to make any money off of that.
Plus, the systems that are out there that need the input aren’t prepared to receive BMS. So there’s another nickel on the side of the scale that says even though everyone wants it, if we were to develop and implement the standard tomorrow, no one would be able to use it.
There comes a point in time where you just have to do it anyway, and we’re looking for that point in time, but it’s a matter of timing, money and capability. If it was a matter of taking 15 minutes and writing 10 lines of code, that would be one thing. But it’s not that simple; it’s reprogramming the entire output of an estimate. The CIECA EMS standard took us more than $1 million to develop, and BMS would be as big of an investment, if not more. If you had two or three different system providers that decided to split up the work so one would develop the BMS export capability and the other would develop the ability to import BMS data, that might be a winning solution.
We have a finite number of resources, a finite number of projects we can undertake, and we prioritize those based on need, capacity to use, and return on investment. Right now, the need for BMS is there, but the capacity to use is zero and the return on investment is zero. When you put that on a priority matrix, it doesn’t bode well for the standard coming out in the next few months.
