Case Study

Model Database

How a Database Strategy Solved Time, Money & Effort for Chevrolet Europe...

& virtually eliminated errors

Automotive Product Landscape

Presenting your product line on your website is no easy task in the automotive industry, which most outside of the industry don’t know. The combined complexity of the model specifications and options together with legal requirements make for a complicated puzzle.

There are a lot of legal requirements for specific data to be shown in specific ways (at least here in the EU). It seems something new comes along every year to challenge the way you can or can’t market your cars.

Multiple uses for the same data – each car’s technical specifications and prices (including detailed breakdown of all the taxes) must be shown in several areas of the website – configurator, trim level comparison, cross carline comparison, carline website pages, etc.

Chevrolet Europe’s Landscape in 2005

With all the countries moved to one platform and the Chevrolet brand officially launched in Europe it was now time for a redesign to move from the Daewoo look.

To be more efficient with our websites we started to use databases to make managing so much content across so many languages easier. We set up databases for images, dealers, and model data.

The databases were all integrated within our CMS platform making it a seamless working experience for our markets – a one stop digital shop.

Each country would add whatever technical and specifications data they wanted to the MDB in their local language  with an accompanying English translation.

Problem To Solve

With our second redesign in 2008 and an expanded range it became apparent that we had to come up with more efficiencies to run a better platform and reduce the workload. With the next redesign in 2008 we planned to make the MDB more powerful.

Step 1

What Exactly Was Going On?

The same specification appeared on multiple carlines on one website would often appear with a different naming nomenclature. And then would have different wording on the price lists.

Product managers had to enter in their new carline or model year update into the model database on the website platform and then they had to repeat the same procedure for the Equipment and Price lists with another agency in another tool. And a third time for the technical specifications in the categories

The equipment and price list had another layer of complexity and costs in that it started from a print first mentality with each country agency building out costly layers in InDesign and then making the PDF from there. Additionally, there was no governance on what information and how they should look. This made it difficult and expensive to keep an up-to-date price list (due to changing exchange rates) on the websites. Many countries simply had to take the price lists down because they couldn’t afford to keep updating them.

This was very labour intensive for the small teams in each country. There was then the issue of correcting wrong information and ensuring that it was done across all the channels.

The current set-up was not working for the product managers nor was it customer friendly.

Step 2

What To Do With The Mess?

  • We had a long-term vision to reduce workloads, rid additional agencies and use the MDB for more than just the website content.
  • To achieve this a multi-pronged approach had to be taken because ‘Rome wasn’t built in a day’

Priority 1

  • Clean up the databases. Create one English master of all carline specifications. Lock down the MDB so new carline data could only entered by the agency with confirmation and approval by the HQ.
  • This was a huge undertaking: we had to get the HQ product managers involved and have them agree on English master naming structure for each specification. They too were guilty of using different nomenclature.
  • Formed a working group that consisted of the stakeholders – central product managers, key local product managers, web agency and me. Specifications and functionality, wireframes, etc were shared with the group for feedback and input.
  • Cleaning the MDB took about six weeks. Removed all multiples and added all the missing specifications.

Priority 2

  • Share the finalised English master MDB with all the product managers across Europe.
  • Start the cleanup in all of the markets – translate new specifications and reset up each of the carlines.

Step 3

What Next?

With the MDB cleaned up we were able to use the data to populate many dynamic areas on the website – compare trim levels, configurator, model sections, etc. with the confidence that the data changes were made once in one location and XXX across the site.

Build the Equipment and Price Lists

We flipped the approach to creating E&P’s  and made them digital first, print second. By doing this the website and CMS because the central hub from which the product managers were working. This was their master content.

  • Set up a low-res PDF generator with the web platform.
  • Wireframe, art direction, build templates for the E&P – again involved the working group from the markets, HQ and agency.
  • The templates were set up for each carline and could be localised to include promotional offers, legal and disclaimers, pricing, taxes.
  • The specifications, options and prices were pulled into the template from the database. The markets could publish their E&P with a click of a button.
  • If they required a high res PDF for printing the agency would convert the file and prepare it for printing.
  • The launch of this template meant that all the countries who couldn’t have their E&Ps live due to constant price changes now could.

2009 Onwards

We applied the model database approach to accessories and accessory brochures, glossary of automotive terms, and an offers database.

The MDB went through three versions when it finally was used by the HQ product managers to set up all the new model year updates and new launches. This reduced the workload for the markets to a click to select what specifications they wanted to show along with their pricing.

The model database was used to create the technical specifications in the catalogues and to send data to the dealer websites.

Learnings / Summary

Company savings in the first year of a harmonised MDB and the digitised Pricelist was €600K.

You need to have the teams’ early buy in and to do this you need to make them an integral part of the process – not only do they get behind the project in an invested way, but they contribute a lot towards the development and success of the project, because  they are on the frontlines and know better than someone sitting in the HQ.

You have to be conscious that sometimes to gain efficiencies, improve consistency, reduce costs, you have to compromise on some flexibility. Total flexibility is what got us into trouble in the first place. A database will never be as flexible as a creative person building something in InDesign and putting content wherever and however he/she wants. But, the payoff in terms of resources and budgets sometimes outweighs a prettier layout.