Automotive ERP: What Suppliers Actually Need

What does a supplier need from an automotive ERP?

A supplier needs an ERP that follows a part from raw material to the customer's dock, reacts to the customer's changing delivery schedule, and produces the quality records an auditor will ask for. Everything else is secondary.

That sounds obvious, but the vendor pages that rank for automotive ERP mostly describe OEM-scale platforms. A tier-2 plant stamping brackets for three tier-1 customers has a different problem. Its customers change release quantities weekly, ask for a shipping notice before the truck leaves, and expect a recall to be scoped in hours.

The quality side is set by the sector's own rules. IATF 16949 is the quality management standard that automotive customers expect their suppliers to be certified to. The AIAG describes the Production Part Approval Process (PPAP), the documentation pack a supplier submits before a part goes into production.

How does automotive ERP software differ from general manufacturing ERP?

The difference is mostly in four places: traceability, customer schedules, quality records and shipping documents. A general manufacturing system can cover them, but usually through configuration or custom code that someone then has to own.

The list below sets out what to look for, and what usually goes wrong, in each area, plus change control, which cuts across all four.

• Traceability. You need the finished part linked to its raw material batch, machine and shift. Common failure: the batch is recorded at goods receipt but lost at the first rework step.
• Customer schedules. You need weekly release changes applied to production plans. Common failure: releases are keyed in by hand from a customer portal.
• Quality records. You need inspection results and corrective actions tied to part numbers. Common failure: the records live in a separate quality tool or in spreadsheets.
• Shipping documents. You need the advance shipping notice and labels in the customer's format. Common failure: a custom script that nobody wants to touch.
• Change control. You need engineering revisions tracked against open orders. Common failure: an old revision is still on the shop-floor routing.

Standards bodies such as Odette publish the messaging and logistics standards that many European customers expect. Check which ones each of your customers actually requires before you shortlist anything.

A note on sources: the guidance in this section and the PPAP and IATF points draw on the AIAG and IATF material linked above, not on an automotive project of ours. Our own hands-on evidence is the case below, which is why we are explicit about how it fits.

Where do supplier ERP projects go wrong?

In our experience, projects stall more often on scope and undocumented history than on missing features. The system gets blamed for problems that were really about nobody knowing how the business had been wired into it.

Customisations nobody can explain

Over ten years, a plant adds a label printout, a custom costing rule, a special rule for one customer's returnable packaging. The engineer who wrote each one moves on. After a few years nobody will change that code, because nobody can say what depends on it.

The spreadsheet that becomes the real system

Once changing the ERP feels risky, people build around it. Planning moves to a spreadsheet, quotes to another.

The ERP still holds the official numbers, but the working numbers are somewhere else and owned by whoever built the file. That is the risk you should worry about, because an audit or a recall will ask the spreadsheet questions the ERP cannot answer.

What does an ERP we left in place look like?

We saw exactly this pattern on an Apache OFBiz modernisation. To be clear about the fit: this was a wholesale distributor, not an automotive supplier. The failure mode is the same one described above, which is why we use it here.

OFBiz case: the problems

The company ran a nine-year-old Apache OFBiz 17.12 instance with 340 custom extensions. The two engineers who built them had left and nothing was documented.

Every report became a developer ticket with a three-week queue, so the business built 41 Excel exports maintained by 11 people. Quotes took 2.5 days because pricing lived half in OFBiz and half in a spreadsheet. They were scoping a move to a tier-one ERP, mainly because nobody could explain the current one.

OFBiz case: the fix

A five-day diagnostic found the customisations were sound and the PostgreSQL schema underneath was clean. The trouble was access. Over eight weeks we documented all 340 extensions and put a read-only API over the existing data. We did not migrate, and the instance is still on 17.12.

Quote turnaround went from 2.5 days to 3 hours. Report tickets to developers fell from roughly 14 a month to 2. We retired 29 of the 41 spreadsheets and left 12 alone on purpose, because they were genuine ad-hoc analysis where Excel is the right tool.

Should you replace your ERP or build around it?

Replace it when the underlying data model or the vendor's support is the problem. Build around it when the database is sound and the real trouble is that nobody understands the code or can reach the data.

You can tell which case you are in with a short diagnostic. Look at the schema: is it clean and queryable? Look at the custom code: is it sound but undocumented, or genuinely broken? In the OFBiz case the answers were "clean" and "sound but undocumented", which made a replacement the expensive way to buy documentation.

There is a cost to building around. You keep the old platform's version, its licence or support position, and its upgrade debt.

In that engagement the version upgrade was scoped and recommended but kept out of the work, since doing an upgrade and a new interface together makes any breakage impossible to trace. The Apache OFBiz project publishes its own release notes, which are the place to check support status for your version.

What should you do before you evaluate automotive ERP vendors?

Write down how an order, a quality record and a shipment actually move through your plant today. Do it before any vendor demo, because a demo answers the questions the vendor chose to show.

1. Start with one real customer. Take a single part number and follow it: the release arrives, the work order is created, material is issued, inspection is recorded, the shipping notice goes out. Note every place where someone retypes data or opens a spreadsheet.
2. List the customisations in your current system, if you have one. For each, write who uses it and what breaks if it goes. Where the answer is "we don't know," that is your first piece of work, whichever ERP you end up on.
3. Check the database itself. A read-only copy and an afternoon with someone who knows SQL will tell you whether the data is in good shape. PostgreSQL's documentation covers read-only roles and query limits if you want to set that up safely.

Can Viithiisys help with the replace-or-build decision?

Yes. Our enterprise software work covers both the build-around and the replace case, and the choice between them comes out of the diagnostic. We have been doing this since 2007 from Mohali, with a Canadian office in Markham, Ontario, and more than 500 projects shipped for clients in six countries.

If the finding is that your system is sound but opaque, system modernisation is the work that follows. If the finding is that the data model has to change, we say so, and scope that as a separate project.

Start with one part number

Pick the part number that gives your planners the most trouble. Trace it from the customer's release to the shipping notice and mark every handoff that happens in a spreadsheet or someone's head.

If you would like a second pair of eyes on that trace, book a workflow audit. We look at how the work moves, check what your ERP database holds, and tell you whether you need a new system or just a way to see inside the one you have.

On the OFBiz engagement, the client found out they did not need a new ERP; they needed 340 undocumented extensions explained.