Product-Process-Resource (PPR)-modellen: één bron van waarheid voor productie

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-11

Een PPR-model koppelt product, proces en resource in één structuur. Lees wat het bevat, hoe een kennisgraaf helpt en hoe productiemanagers er zelf een kunnen opbouwen.

Automatically translated with AI from the original post. Read the English original

Een PPR-model koppelt het product dat je bouwt, de processtappen die nodig zijn om het te bouwen en de resources die het werk kunnen uitvoeren, in één samenhangende structuur. Dit artikel is bedoeld voor productiemanagers die het zat zijn dat het ERP-systeem, de planningsspreadsheet en de simulatie telkens andere getallen tonen. Je leest wat een PPR-model bevat, waarom één bron van waarheid belangrijk is, hoe een kennisgraaf past en hoe je stap voor stap een eerste versie bouwt.

Belangrijkste punten

• Een PPR-model koppelt het product dat gebouwd wordt, het proces dat nodig is om het te bouwen en de resources die het werk kunnen uitvoeren, zodat de drie nooit los van elkaar worden beschreven.
• Fabrieken bewaren cyclustijden en routings vaak in meerdere systemen en spreadsheets, waardoor één wijziging op veel plekken moet worden doorgevoerd en er fouten insluipen.
• Een kennisgraaf slaat deze verbanden op als relaties, zodat je kunt vragen welke resources welke stap voor welk product kunnen uitvoeren.
• Vaardigheden en capaciteiten ontkoppelen een proces van een vaste machine, omdat het model beschrijft wat een stap vereist en wat een resource biedt.
• Begin klein met één productfamilie, hergebruik de gegevens die je ERP-systeem al bevat en wijs voor elk gegevensveld een eigenaar aan.

Wat is een PPR-model?

PPR staat voor product, proces en resource. Een referentiepaper over capaciteiten en vaardigheden in de productie beschrijft het PPR-concept als de drie belangrijkste aspecten van productiesystemen engineering. Producten zijn de in- en uitvoer van productie. Processen zetten inputs om in outputs. Resources voeren die processen uit. Zie het referentiemodelpaper over capaciteiten en vaardigheden.

De product-proces-resource-structuur bindt ze samen. Simpel gezegd beantwoordt ze drie onderling verbonden vragen:

• Product. Wat maken we? Varianten, onderdelen en de productiestuklijst.
• Proces. Hoe wordt het gemaakt? Stappen, hun volgorde, tijden en regels.
• Resource. Wat voert het werk uit? Machines, gereedschap en medewerkers, met hun agenda's en beperkingen.

De waarde zit in de verbanden. Een lijst met producten, een lijst met stappen en een lijst met machines zijn drie lijsten. Een PPR-model vertelt welke stap bij welk product hoort en welke machines en medewerkers die kunnen uitvoeren.

Waarom hebben fabrieken één bron van waarheid nodig?

De meeste fabrieken hebben deze informatie al, maar op verschillende plekken: routings in het ERP-systeem, tijden in een planningsspreadsheet, machinelijsten bij onderhoud, parameters in een simulatiemodel. Elke kopie loopt langzaam uit de pas met de andere.

Een artikel van Ferrer en collega's over assemblageautomatisering beschrijft het onderliggende probleem. PPR-modellering wordt als veelbelovend gezien omdat het de ontwikkeltijd en engineeringkosten kan verlagen en een efficiënt ontwerp en een efficiënte herconfiguratie van productiemiddelen mogelijk maakt. Het obstakel is de ineffectieve koppeling van PPR-gegevens, waardoor het systeemontwerp afhankelijk blijft van de kennis en ervaring van individuele engineers. Zie de samenvatting van het artikel. Het artikel kijkt naar assemblageautomatisering, maar het punt geldt ook voor elke fabriek waar product-, proces- en resourcegegevens los van elkaar worden bewaard.

Signalen dat je fabriek veel versies van de waarheid heeft:

• Een cyclustijd verandert, maar de planning, de offerte en de simulatie gebruiken nog de oude waarde.
• Planners houden een eigen spreadsheet bij, omdat ze het systeem niet vertrouwen.
• Niemand kan snel zeggen welke producten worden getroffen als een machine uitvalt.
• Een nieuwe productvariant heeft weken aan gegevensinvoer nodig voordat die gepland kan worden.

Wat hoort er in het model?

Een eerste bruikbare versie vraagt minder dan je misschien denkt. Begin per onderdeel met de velden die de planning echt gebruikt.

Product

1. Product- en variant-id's
2. Stuklijst voor productie (wat er van wat wordt gemaakt)
3. Kwaliteits- of testeisen die de route beïnvloeden

Proces

1. Bewerkingen en hun volgorde, inclusief alternatieven
2. Tijden per stuk en insteltijden
3. Benodigde vaardigheden of gereedschappen per bewerking

Resource

1. Machines, werkplekken, gereedschap en mensen
2. Agenda's, diensten en geplande stilstand
3. Capaciteit, vaardigheden en kwalificaties

Voeg dan de koppelingen toe: elke bewerking verwijst naar de producten waartoe ze behoort en naar de resources die haar kunnen uitvoeren. Het referentieartikel legt uit waarom dit helpt. Een capability of vaardigheid beschrijft de functie die een proces nodig heeft, en een resource levert die functie, dus "de anders starre koppeling tussen processen en resources wordt ontkoppeld". In de praktijk beschrijf je wat een stap vereist en wat elke resource biedt, en leg je niet één machine vast in de routing.

Hoe verschilt dit van een stuklijst en een routing?

Een stuklijst somt de onderdelen van een product op. Een routing somt de bewerkingen en de werkcenters op. Beide horen bij de basisgegevens voor productie en beide zijn nodig. Maar elk beschrijft maar één kant. De stuklijst zegt niet hoe de onderdelen aan elkaar worden verbonden, en de routing noemt vaak een vast werkcenter, waardoor andere machines die het werk ook zouden kunnen doen onzichtbaar blijven.

Een PPR-model gebruikt beide als input en voegt toe wat ontbreekt: de koppelingen met de resources en hun beperkingen. Zo kunnen planning, simulatie en rapportage met dezelfde gegevens werken. Het ondersteunt ook een dynamischere en adaptievere manier van werken. Als een machine uitvalt of er een nieuwe variant binnenkomt, kun je zoeken naar een andere resource die de vereiste vaardigheid levert, in plaats van tal van routings met de hand aan te passen.

Hoe helpt een kennisgraaf?

Een graaf is een manier om gegevens op te slaan als dingen en de relaties daartussen. In een PPR-graaf zijn producten, stappen en resources de knooppunten, en zijn ‘wordt gemaakt door’, ‘vereist’ en ‘kan worden uitgevoerd op’ de relaties.

Het voordeel zie je wanneer je vragen stelt die de drie delen met elkaar verbinden:

• Welke resources kunnen stap 30 van productfamilie A uitvoeren?
• Welke producten verliezen hun enige gekwalificeerde operator als één persoon afwezig is?
• Welke stappen delen dezelfde knelpuntmachine?
• Wat verandert er als er een nieuwe machine wordt toegevoegd?

In een reeks afzonderlijke tabellen heeft elke vraag een nieuw rapport nodig. In een kennisgraaf volg je gewoon de koppelingen. Het is ook makkelijker uit te breiden: een nieuw soort relatie, zoals een gereedschapseis, vraagt geen herontwerp.

Voorbeeld: één wijziging, veel bewerkingen

Dit voorbeeld gebruikt aangenomen getallen.

Een fabriek maakt 40 producten. De cyclustijd van één boorstap op machine M3 verandert. Deze stap komt voor in de routings van 6 producten. De tijd wordt op 4 plekken opgeslagen: in het ERP-systeem, een planningsspreadsheet, het MES en een simulatiemodel.

Zonder gedeeld model. De planner doet 6 × 4 = 24 wijzigingen. Stel dat elke handmatige wijziging een kans van 2 procent heeft op een fout of op vergeten. De kans dat alle 24 goed zijn, is 0,98 tot de macht 24, wat ongeveer 0,62 is. De kans op minstens één fout is dus ongeveer 1 − 0,62 = 38 procent.

Met één bron. De tijd wordt één keer opgeslagen, op de koppeling tussen de stap en de machine, en alle producten en tools lezen die waarde. Eén wijziging, en de kans op een fout is de 2 procent van die ene wijziging.

De getallen zijn verzonnen, maar de logica is algemeen: hoe meer kopieën, hoe meer plekken met een verkeerde waarde. Eén enkele bron van waarheid voorkomt fouten niet, maar vermindert het aantal plekken waar ze kunnen ontstaan.

Hoe bouw je er zo een, stap voor stap?

1. Kies één productfamilie en één gebied, bijvoorbeeld de knelpuntlijn. Modelleer niet eerst de hele fabriek.
2. Verzamel de bestaande data. Haal routings, stuklijsten, tijden en resourcelijsten uit het ERP-systeem en andere bronnen.
3. Zoek de conflicten. Vergelijk dezelfde waarde op verschillende plekken. Bepaal welke juist is en wie er eigenaar van is.
4. Modelleer de koppelingen. Verbind elke stap met de producten en met de resources en vaardigheden die hem kunnen uitvoeren.
5. Toets het op de werkvloer. Laat het model zien aan voorlieden en planners. Vraag: is dit hoe het werk echt verloopt?
6. Koppel de afnemers aan. Planning, simulatie en rapportage moeten het model lezen, niet hun eigen kopieën.
7. Houd het actueel. Wijs per veld een dataeigenaar aan en stel een regel voor wijzigingen op.

Veelgemaakte fouten

• Alles eerst willen modelleren. Begin met één familie en breid de scope daarna uit.
• De ERP-fouten overnemen. Een model op basis van foute tijden is een keurig georganiseerd fout model. Controleer kernwaarden bij de machine.
• Geen dataeigenaar. Als niemand eigenaar is van een veld, loopt het weer uit de pas.
• Machines hard coderen in routings. Beschrijf de eis, en laat het model de resources zoeken die erbij passen.
• Een model bouwen dat niemand gebruikt. Als planning en simulatie nog hun eigen kopieën gebruiken, heb je er alleen een kopie bij gemaakt.
• Mensen en vaardigheden vergeten. Operators en hun kwalificaties vormen vaak de echte beperking.

Hoe software kan helpen

Een PPR-model kan worden gebouwd met een graph-database, een dataplatform of een speciaal tool. iFAKT's Polaris Designer is een module van iFAKT Polaris die een product-proces-resource-kennisgraaf bouwt als single source of truth voor producten, processtappen en resources. Wanneer je tools vergelijkt, vraag dan waar de data vandaan komt, hoe conflicten tussen bronnen zichtbaar worden en hoe andere tools, zoals planning en simulatie, het model lezen.

Volgende stap

Kies één productfamilie en schrijf de producten, de stappen en de resources op één blad, met de koppelingen ertussen. Vergelijk de tijden in je ERP-systeem met die bij de machine, en je hebt de eerste versie van een PPR-model en een lijst met data die gecorrigeerd moet worden.