Integration? What's that and what do I do with it? What about my DMS?

[Aimsmith]

Bob:

Thanks very much for your post. AMEN to all you said. This industry is in a total state of denial about it's condition. No wonder they are on life support!

Randy

 

[Bob]

Alex,
I agree that the DMS world (and in general the auto business) is behind the times from a technology viewpoint, and would like to see them become more open in general.

If the DMS operators were to become completely open, it still would not obsolve themselves of the legal liability.

Their is risk all around, and I think if third party vendors want to "integrate" then they should work with the DMS providers. It simply makes their tools more valuable to the retailer, doesn't it.

I am not advocating for the DMS providers! I don't understand why the third party vendors don't get certified with the DMS provider. It only makes their solution more valuable, and proves to the retailer that both the DMS provider and third party vendor are working together!

Isn't the retailers mind put at ease if he/she knows the third party vendor has his/her back from an integration viewpoint!
Doesn't the retailer sleep better at night knowing he/she has one less headache?

Just my viewpoint!

 

[Alex Snyder (blog)]

Bob - thanks again for your viewpoint. Yes, we all understand that there is legal liability for the DMS providers. Yes, it would be great if every vendor became "certified". I assume they don't all do this because there is a significant monetary cost along with the programming time when it comes to becoming "certified". On top of that there are probably some political things going on behind the scenes...

If a DMS provider is trying to purchase a particular vendor, it might not be in the DMS provider's best interest to help that other company increase its value with "certification".

Whether it be legal, huge costs, or political the consumer (ours) and client (us) still loses in the end.

I'm sick of being the loser in this stupid game!

 

[David Book]

Once again, another good discussion. My two cents....

Integration - yikes. The word itself screams "difficult" "impossible" "time consuming" "unproductive." Sure, there are vendors and DMS providers that are working hard at being "nice" to each other but really, in nearly 100% of cases, it just doesn't work as designed. Like mentioned earlier, certification processes are a good concept but almost impossible to administer with the pace of change recently (going to get even faster). Pushing, pulling, feeding, it's all just a blur to most "normal folks" just trying to do their jobs.

Consider this: About a year ago none of our phones had fancy little touch screens - today tons do. I've already forgot how to use a once cool Querty Keyboard. About a year ago almost nobody had ever heard of a "net book" - today, it's one of the hottest PC products. I could go on and on.

The reality is, like it or not, in a very short amount of time, there will be very few dealers storing their data locally. Yeah, we've all heard this before... but how "real" was the idea of "cloud computing" only a few short months ago.

In the last few years (months really) GIANT corporations (banks included, they understand the possible litigation associated with their businesses too) have been moving large data-sets offsite (did you know that almost zero B of A's have local data storage anymore?) and the car biz' isn't too far behind. Behind, sure, but not too far. Don't take my word for it, I'm just an industry vendor guy. Take the WORLDS word for it. Data's moving upstairs and there isn't anything anyone can do about it, including Rey Rey, ADP or any of the other "big providers."

The key to our industries data integration problems lies in standards. Standards like the trusty ADF / XML lead. Standards like the RSS inventory that almost no web-providers provide - easily. Standards like EVERY other industry designs and supports in order to advance their industry. Airlines, Banks, Hospitals, everybody that survives has figured it out - except us. It's time our industry got serious about standardizing each and every kind of data we create, transmit, share and protect.

a) Develop a standard database schema
b) Dealers "own" their database and store it wherever they please.
c) Solutions providers create front-ends to manipulate the standard database. Parts, service, sales, FI, HR, the whole enchilada.
d) all transmissions are encrypted and customer data is not accessible by anyone without the customers electronic permission (just like banks, doctors, etc. )

It may sound like I'm minimizing the complexity surrounding such a big problem, I am. But, I'm also not naive enough to think that our industry is somehow going to remain both viable AND old-school. It just isn't going to work. Heck, "modern" in our stores is a PC emulator rigged up to act like UNIX. Come on.... are we serious?

For the folks that are concerned about "security" - consider this. Would you rather your data be offsite behind a standard protection mechanism, or, in the hands of Lucy upstairs, or John in FI or Jack in service, or me, Joe vendor? Seems obvious doesn't it.

Who's aboard, we have lots of work to do!
David.

 

[umer.autojini]

@david I 100% agree with you on principle of "Develop a standard database schema". There are many specs already for exchanging customer data(ADF/STAR), financial data (STAR), Warranty and others... but we are lacking a standard for inventory exchange. Lets all work towards getting a standard in place for vehicle inventory. That addresses...

1. What data we must have in the DMS. (I'm frankly exhausted of figuring out what color is Silver2 or entries like dblue vs dkblue vs drkblue)
2. Layout of inventory feeds. Every provider has their own standard... why do I have to write a different import for HomeNet, VinSolution, DSI, CDM... or a export for ATC, CC, Vehix.

To get started... on #2... I have created this xsd... http://www.autojini.com/xml/xsdDocs/index.html (still needs tons of work)

I would also add that actually implementing the standard fully is the key. To date I have not found any CRM provider that fully supports the ADF standard. Mainly... ADF clearly supports Inline or Attachment based data... most providers take only inline data. There is a perfectly logical standard for processing errors in ADF but so far no one has actually implemented correct error handeling in ADF. i.e send the errors to the ADF data provider not the dealer.

 

[Cem Avsar]

Do not forget to clear (delete) all DMS VPN access. You will be surprise when you find out your previous employees still accessing your DMS via VPN. Remember REYREY does NOT care !

REYREY offers VPN access !

Get a security report from REYREY and good luck.

Happy selling.

(by the way I still use dial up connection, it works)

 

[countzerro]

The biggest problem with integration is that there are very few people who actually understand how it all works together. You must be able to tell your vendors exactly what your want. I have all of our systems working together thanks to some great IT people at vAuto, The Cardone Group, Autouplink and eBiz Autos. Where other vendors said they couldn't, we have found creative ways to make it all work together. Here is the list.
Six New Car Franchises
Two Used Car Lots
Four Separate Buildings
One DMS with one (YES,1!) F&I Log On
One (YES,1!) Vehicle Account
Three different Parts and Service Accounts(Does anyone else have these kinda problems)
Six New Car Websites
One Group /Used Car Site.... and the list goes on.
We have ADP as our DMS, Autouplink polls our inventory, and breaks it down into multiple feeds based on different filtering criteria. vAuto both pulls from and pushes to Autouplink. It also separates the used car inventories based on which lot, so we have one place to price our used cars.
We have four separate dedicated ePencil servers, with a web based Enterprise CRM solution courtesy of Cardone/Dealerpeak(big shout to Gus, Vincent and Laymon the best in the business). We also have 12 different vehicle accounts for our web sites. Believe it or not it all works together great. And when there are problems, 99.99% of the time somebody put in the wrong data.
Worst case scenario, I can always write an "English Statement", export to a csv file, convert the data to an Excel Spreadsheet and FTP it to my vendors.
It helps that we have General Managers and a Dealer Principle that understand the importance of the technology. Almost all of our Sales Managers have bought in, and one of our Used Car Managers who was as "old school" as they came is now a Dale Pollack fan and it shows. Our used car sales, grosses and turn rate are all way up, and we cut our used car inventory in almost half!!!
And yes we still have one (YES,1!) "old school" sales manager and we have been dragging him kicking and screaming the whole way! I think even he's actually starting to get it. Either that or he's just found something else to kick and scream about.
Matt Young
IT Manager /Crisis Avoidance Specialist
Jack Ingram Motors

 

[DEP]

Great Post!  When vendors tell you that your group is overprotective they might be referring to the fact that you actually take the time to run third party requests for integration through a legal team.  All too often I witness dealers and office staff who sign these types of contracts and agreements without even browsing over them. Many times, these contracts include clauses or disclaimers that release the third party vendor from liability for data loss, corruption, or theft caused by the integration hence the responsibility often falls solely on the dealership.
I do work in the industry for a third party company that does invest in secure integration with several DMS partners including the "Big Three" as you refer to them.  We view the certification process as an important aspect of our business that allows our clients to do business with us in confidence.  Unfortunately, it's not always the easiest or most popular stance to take.  If you think about it, many of your customers would probably be happy if you told them them that they can neglect costly procedures in their maintenance guide and still enjoy optimal performance from their new car. Much the same way a vendor might tell you to ignore your data providers cerification policy guidlines for protecting your system and data. The argument to keep using vendors that rely on hostile integration to access data is often based on a broken correlation: Nothing negative has occurred to this point, therefore nothing negative will ever occur.  My point is, it’s always easy to "drink the kool aid" and there will always be plenty of companies happy to serve it as long as decision makers are willing to drink.
In today’s market, clients often place focus and expectations on fast and easy.  As we've all witnessed in the credit card industry, fast and easy doesn't always mix well with private or sensitive information. In making credit cards faster and easier to use than ever, credit card companies and the vendors that process them have made it easier in many cases, for criminals to commit data theft and fraud.  Sometimes it might make sense to be careful what we wish for, at least before we consider unintended consequences. (Ask any individual who has gone through identity theft or a company that’s been through a class action lawsuit for failing to adequately protect sensitive data)
   Data security can be like auto insurance. Unfortunately, it's often just not that important until a problem occurs.  The saying, "An ounce of prevention is worth a pound of cure" seems relevant when talking about this issue. To anyone faced with decisions involving data security and integration, I recommend examining motivations and agendas of the companies using non-certified integrations to gain access to data just as you scrutinize the companies that implement and maintain the certification programs. 

 

[David Book]

@ DP

Your post is so spot-on and important. There are many many implications with "slinging information around" that almost nobody thinks about when they enter a agreement with a new vendor.

I think our industry is asking for trouble if we simplify (like I did in an earlier post) the integration issue. But, we cannot afford to ignore it. Seems to me that these yet-to-be-developed standards should start with a solid data protection and security plan.

Thanks for sharing from your perspective
David Book

 

[umer.autojini]

@Matt "Crisis Avoidance Specialist"