Supplier Quality PPAP Software: Six Weeks to Job One and Nobody Can Say Which Submissions Are Approved

Why part approval collapses in the last six weeks before launch

A programme manager asks a simple question in a launch review: of the 312 purchased part numbers on this build, how many have an approved part submission warrant at the current drawing revision, from the supplier plant that will actually make them. Nobody in the room can answer. The supplier quality team has a tracking spreadsheet, last updated by hand, which says 287 approved. Two engineers immediately say that number is wrong, because they know of parts that were approved before the last engineering change and have not been resubmitted.

What follows is three weeks of a supplier quality team emailing 60 suppliers asking for confirmation, chasing attachments, and finding that four packages were sent to an engineer who left, one was approved verbally on a call, and eleven were approved at a revision that no longer exists. Meanwhile the programme cannot slip, so a deviation gets granted for a handful of parts, and a deviation granted under launch pressure with no expiry date is how a temporary condition becomes a permanent one.

The underlying issue is that part approval is treated as a document exchange when it is actually a state machine. Each part number, at each revision, from each supplier plant, is in exactly one state: not requested, requested, submitted, under review, rejected with actions, approved, interim approved with an expiry, or invalidated by a change. Email cannot represent a state machine. Neither can a spreadsheet maintained by a person who is also doing three launches.

Problem 1: PPAP is not one requirement, it is a matrix

The AIAG production part approval process defines eighteen elements, from design records and process flow diagrams through the process failure mode and effects analysis, control plan, measurement systems analysis, dimensional results, material and performance test results, initial process studies, and the part submission warrant itself. It also defines submission levels, so what a supplier actually sends you differs by level, and level assignment depends on part risk, supplier history, and your own customer specific requirements flowed down from the people who buy from you.

Aerospace runs a related but distinct discipline, with advanced product quality planning under AS9145 and first article inspection under AS9102 with its own forms and its own rules about what triggers a new first article. Medical device manufacturers have no PPAP at all but run supplier validation with qualification protocols that occupy the same organisational space.

So the requirement is a matrix: commodity, risk class, customer requirement set, and standard, resolving to a required element list per part per submission. Spreadsheets flatten that matrix into one checklist that is wrong for most parts. Packaged quality suites configure it, up to the point where your customer specific requirements diverge from what the configuration model anticipated. A custom build treats the matrix as data, so adding a new customer requirement set is a row rather than a change request.

Problem 2: revision is the entire game and email has no concept of it

An approval is only meaningful against a specific part revision, a specific drawing revision, from a specific supplier manufacturing location, using specific tooling. Change any of those and the approval status is at best questionable and at worst void. Yet the events that change them arrive from everywhere: an engineering change order in PLM, a supplier moving production between their own plants, a tooling refurbishment, a sub tier supplier substitution the supplier did not think worth mentioning, a process change to improve their yield.

What a custom build must include is an approval record bound to the full identity of what was approved: part number, revision, drawing revision, supplier site, tooling identifier. When an engineering change is released in PLM, every affected approval is automatically flagged for review and a resubmission request generated at the correct level, which for a minor change might be a level one warrant only rather than a full package. That single automation removes the most common cause of the launch review scenario above, which is that nobody connected an engineering change in March to an approval granted in January.

Problem 3: deviations are granted under pressure and never expire

Every launch generates deviations. A part is needed, the submission is not complete, and a decision is made to proceed with a documented concession. That is legitimate engineering judgement. What is not legitimate, and what we find at most manufacturers, is that the deviation has no expiry, no quantity limit, no owner responsible for clearing it, and no visibility above the person who granted it.

The build should make every deviation a bounded object: a defined expiry date or a defined quantity, whichever comes first, an owner, a required closure action, and automatic escalation as the boundary approaches. Parts running on deviation should be visible on one screen to the supplier quality director, with age. Manufacturers who put this in place are usually startled by the count, which is the point.

Problem 4: the evidence arrives as PDFs that cannot be analysed

A submission package typically includes dimensional results as a table keyed to a ballooned drawing, capability studies for significant characteristics, measurement systems analysis results, and material certifications. All of it arrives as PDFs and scans. So the supplier quality engineer reads it, forms a judgement, and clicks approve. Nothing in the package is ever queryable again.

What a custom build does is capture the numbers, not just the file. Dimensional results and capability indices are entered by the supplier in the portal or extracted from the submitted documents with human confirmation, tied to characteristic identifiers from the ballooned drawing. This is a legitimate and narrow use of document extraction: read the tables, propose values against characteristics, have the engineer confirm. Once the numbers are in the system, the review itself gets faster, because out of tolerance and marginal capability values are flagged before the engineer opens the file rather than after they have read forty pages.

Where Siemens Opcenter Quality, ETQ, Ideagen and Plex actually stop

These are real quality management systems and we would not dismiss any of them. Siemens Opcenter Quality has genuine depth and fits naturally if you already run Teamcenter, because the PLM link is the hardest part of this problem and having it native is worth a great deal. ETQ Reliance is a strong, configurable quality platform with broad compliance coverage. Ideagen has real presence in aerospace quality. Plex is a solid choice if you are already running it as your manufacturing system, since the shop floor data is already there.

Where they strain is specific. Their supplier facing experience is usually the weakest surface, and PPAP is a supplier facing process: if a tooling shop with four employees cannot submit a package without training, they will email it to your engineer and you are back where you started. Customer specific requirement sets flowed down from your own customers tend to exceed what the configuration model was designed for, especially in automotive where each customer imposes its own variations. Element level data capture, as opposed to document storage, is often shallow, so you keep the PDF and lose the numbers. And licence models that charge per user make it uncomfortable to give every supplier contact an account, which pushes the process back to email.

Our honest position: if you run Teamcenter, evaluate Opcenter Quality seriously before commissioning anything. If your quality organisation has already standardised on ETQ or Ideagen for corrective action and audits, extending there may beat a new system on total cost even if the supplier experience is weaker. Build when the supplier submission experience, the customer requirement matrix, or the element level data are the parts that carry your value.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering submission requests by part, revision, supplier site and level, structured element checklists driven by a requirement matrix, review and approval with full history, and a live launch readiness view runs $70,000 to $150,000 and ships in 12 to 16 weeks. A full platform adding a supplier portal with guided submission, dimensional and capability data capture with document extraction, deviation control with expiry and escalation, PLM change driven resubmission, ERP part revision sync, and supplier scorecards including submission quality runs $180,000 to $420,000 phased over 6 to 12 months.

What drives cost up specifically here: the number of distinct customer requirement sets you must flow down, since automotive manufacturers serving three original equipment customers effectively run three rule books. PLM integration depth, which is straightforward with a modern system and painful with an older installation or with engineering data spread across two systems after an acquisition. Aerospace first article inspection support, which is a genuinely different data model from PPAP and not a variation on it. Supplier portal languages, because your tooling suppliers in Mexico, Turkey and China will not use an English only portal properly. And any requirement for electronic signature under regulated conditions.

Build versus buy, and when buying is the right call

Buy, or use a shared folder with strict discipline, if you buy a few dozen parts from a stable supplier base with infrequent engineering changes. The overhead of a system exceeds the cost of the problem. Buy a packaged quality suite if your organisation is already standardised on one for audits and corrective actions and your requirements are close to its model, because a second system creates a second place to look.

Build when two or more of these are true. You launch programmes with hundreds of purchased parts on a fixed date. You flow down more than one customer specific requirement set. You operate multiple receiving plants and the same part is approved for one and not another. Engineering changes are frequent enough that revision drift is your main source of invalid approvals. You need the numbers inside submissions, not just the documents, for capability analysis across a programme. Or your supplier base includes many small shops for whom a heavy enterprise portal is a genuine barrier.

The tipping point is launch cadence. A manufacturer launching one programme every three years can survive on discipline. A manufacturer with overlapping launches and continuous engineering change has a coordination problem that only a system can hold, because the state of 312 parts across 60 suppliers at 4 plants is not something a person can carry.

How to choose a developer for supplier quality software

Ask them to model the approval record before anything else. A developer who has done this work will bind approval to part revision, drawing revision, supplier manufacturing site, receiving plant and tooling, and will ask which of those changing should invalidate an approval automatically. A developer who models supplier and document has built a file repository and your launch review will go exactly the way it goes today.

Ask how a released engineering change becomes a resubmission request. If the answer requires someone to notice, the system has not solved your actual problem. The PLM connection is the hardest and most valuable part of the build and it should be discussed in the first meeting, not in phase two.

Ask what a four person tooling shop sees when they are asked to submit. If the answer involves training, account provisioning and a password policy, they will email a PDF to your engineer and the system will quietly fail at the edge where most of your risk lives.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else. At Digital Heroes the code is yours from the first commit. Part approval records are evidence in customer and regulatory audits, and that evidence should never depend on a licence renewal.