"Dat kan ons pakket ook." Wie rondkijkt voor meer grip op engineeringdata, hoort die zin in elke demo. De PDM-leverancier heeft een module voor artikelen, het ERP-pakket zegt documenten te beheren, en ergens schuift een PLM-consultant aan die alles onder één paraplu wil hangen. Aan het einde van de week heb je drie offertes en minder overzicht dan ooit.
Tijd voor een nuchtere ontrafeling. In dit artikel lees je het verschil tussen PDM, PLM en ERP: wat elk systeem doet, waar ze elkaar raken en in welke volgorde een mkb-maakbedrijf ze echt nodig heeft. Alvast de spoiler: de eerste stap is meestal geen van de drie, maar het op orde brengen van je eigen CAD-data, met goede afspraken en desnoods niet meer dan een toolbox als Thundercad naast Inventor.
PDM: grip op bestanden en versies
Product Data Management beheert de bestanden waar engineering mee werkt: modellen, tekeningen, samenstellingen en alles wat daaraan hangt. De kernfuncties zijn check-out en check-in (geen twee mensen tegelijk in hetzelfde onderdeel), versiebeheer (elke stand blijft bewaard) en zoeken op eigenschappen in plaats van op mapnamen. Een goed PDM-systeem kent bovendien de verwijzingen tussen bestanden: het weet in welke samenstellingen een onderdeel wordt gebruikt vóór jij het wijzigt.
PDM praat in bestanden en revisies, en dat is tegelijk zijn kracht en zijn grens. Voor Inventor-teams is Autodesk Vault de bekendste invulling; of die stap voor jouw team al loont, hangt af van teamgrootte, projectdruk en foutkosten. Daar schreven we eerder een eerlijk beslismodel voor in Heb je Vault nodig? Een eerlijk antwoord voor mkb-teams.
PLM: het proces rond het product
Product Lifecycle Management kijkt breder dan bestanden: het volgt een product van eis tot uitfasering. Denk aan wijzigingsverzoeken met beoordeling en goedkeuring, aan eisenbeheer, aan de samenhang tussen mechanica, elektro en software, en aan documentatie die niets met CAD te maken heeft: handleidingen, certificaten, testrapporten. PLM beantwoordt vragen als "welke wijzigingen zitten er in de uitvoering die bij deze klant draait" en "wie heeft die wijziging wanneer goedgekeurd".
Dat klinkt aantrekkelijk, en voor bedrijven met veel wijzigingsdruk of zware documentatie-eisen is het dat ook. Maar PLM veronderstelt dat de lagen eronder staan: zonder betrouwbaar bestandsbeheer en zonder gevulde metadata automatiseer je een proces dat er nog niet is. In het mkb is "PLM" bovendien vaak gewoon een goed afgesproken werkwijze met de middelen die er al zijn.
ERP: artikelen, aantallen en planning
Enterprise Resource Planning zit aan de bedrijfskant: verkooporders, inkoop, voorraad, planning, nacalculatie. Een ERP-systeem denkt niet in bestanden maar in artikelen: een artikelnummer met een omschrijving, een prijs, een levertijd en een voorraadstand. Wat engineering ontwerpt, wordt voor ERP pas interessant zodra het een artikel is dat besteld, gemaakt of verkocht moet worden.
Daarmee is ERP voor de meeste maakbedrijven het oudste en meest vanzelfsprekende systeem van de drie: het draaide er vaak al voordat er überhaupt in 3D werd getekend. De vraag is dus zelden óf je ERP nodig hebt, maar hoe je engineeringdata er betrouwbaar in krijgt.
Waar de drie elkaar raken, en waar het botst
Op papier is de taakverdeling helder. In de praktijk schuurt het op drie plekken: de stuklijst, de artikelstamdata en het wijzigingsproces. De stuklijst ontstaat in CAD, maar productie en inkoop werken met de versie in ERP. Artikelen bestaan in beide werelden, elk met eigen velden. En een wijziging raakt alles tegelijk: bestand, artikel, voorraad en lopende orders.
| Vraag | Antwoord hoort in |
|---|---|
| Welke versie van dit model is actueel? | PDM |
| Wie keurde deze wijziging goed, en wanneer? | PLM (of PDM met workflows) |
| Hoeveel stuks liggen er op voorraad? | ERP |
| Wat is de levertijd van dit koopdeel? | ERP |
| Uit welke onderdelen bestaat dit product? | Alle drie, elk met een eigen doel |
Die laatste regel is de bron van het meeste gedoe. De ontwerpstuklijst in CAD, de beheerde stuklijst in PDM en de productiestuklijst in ERP zijn familie van elkaar, maar niet identiek. Zolang mensen ze handmatig overtypen, lopen ze uit elkaar, en elke overgetypte regel is een kans op een fout die pas in de werkplaats opvalt.
Waar je ook staat in dit verhaal: de dagelijkse overdracht tussen Inventor en ERP hoeft niet te wachten op een groot systeem. Thundercad zet stuklijsten in je eigen Excel-sjabloon en laat je artikelen uit het ERP rechtstreeks in Inventor raadplegen en plaatsen.
Probeer 30 dagen gratisDe volgorde die voor het mkb meestal klopt
Leveranciers redeneren vanuit hun eigen doos; jij kunt beter redeneren vanuit je grootste risico. Voor de meeste mkb-maakbedrijven ziet de gezonde volgorde er zo uit:
- Eerst je CAD-data op orde. Vaste templates, gevulde iProperties, een heldere naamconventie en modellen zonder rommel. Zonder deze basis maakt elk systeem de chaos alleen maar beter vindbaar. Hoe die basis doorwerkt tot in de werkplaats, lees je in Schone, betrouwbare data naar productie.
- Dan PDM. Zodra meerdere mensen dagelijks in dezelfde bestanden werken, wordt versiebeheer het knelpunt. PDM lost een acuut en meetbaar probleem op; daarom staat het vóór PLM in de rij.
- ERP bewust koppelen. ERP draait meestal al. De winst zit in de overdracht: eerst afspraken over artikelnummers en stuklijstoverdracht, daarna pas techniek om die afspraken te automatiseren.
- PLM pas bij aantoonbare procespijn. Veel wijzigingsdruk, traceerbaarheidseisen van klanten, meerdere disciplines die op elkaar wachten: dat zijn de signalen. Niet "de demo zag er goed uit".
De volgorde is geen wet, maar één regel geldt altijd: elk systeem versterkt wat je erin stopt. Wie rommel invoert, krijgt keurig geordende rommel terug.
Veelgestelde vragen
Is Autodesk Vault nu PDM of PLM?
Vault is in de kern PDM: bestandsbeheer, versies en vindbaarheid voor je Inventor-omgeving. Uitgebreidere edities schuiven met wijzigingsworkflows en levenscycli richting PLM-terrein, maar het zwaartepunt blijft het beheer van CAD-bestanden. Voor de meeste Inventor-teams is dat precies wat er nodig is.
Kan ons ERP-pakket de CAD-bestanden niet gewoon meebeheren?
Documenten opslaan kan bijna elk ERP-systeem, maar CAD-bestanden zijn geen losse documenten: een samenstelling verwijst naar tientallen onderdelen die elkaar nodig hebben. Zonder check-out, versiebeheer en kennis van die verwijzingen gaat dat vroeg of laat mis. Laat ERP doen waar het goed in is en geef engineering een eigen beheerlaag.
Wat kan ik doen zonder ook maar één nieuw systeem te kopen?
Meer dan je denkt: een naamconventie afspreken, iProperties structureel vullen en de stuklijstoverdracht naar ERP standaardiseren. Dat werk is nodig voor élk toekomstig systeem en betaalt zich vandaag al uit. De export- en artikeltools van Thundercad kun je daarvoor een maand gratis inzetten.