PLM-selectie en -implementatie: veelgemaakte fouten

Wat zijn de meestgemaakte PLM-fouten?

Publicaties van Aras, Arena en de Dassault-partner TECHNIA, allemaal bronnen van leveranciers, noemen overlappende lijsten: onduidelijke eisen, ontbrekende steun van het management, slecht verandermanagement, zwakke integratieplanning, vuile data en te weinig training. Geen van hen noemt een faalpercentage, en het register noemt er geen. Het register groepeert de fouten hieronder per projectfase, en de afsluitende tabel koppelt elke fout aan een vroeg signaal en een oplossing.

Fouten tijdens de selectie

Selectiefouten zijn het goedkoopst te herstellen, omdat er nog niets is geconfigureerd. Ze bepalen ook elke latere fase, omdat eisen, shortlist en contract op dezelfde aannames rusten.

• Featurechecklists zonder scenario's. Een checklist beloont de langste lijst met vinkjes. Aras waarschuwt dat functies soms worden overschat en dat best practice van de leverancier niet altijd bij de processen van de koper past. Gescripte scenario's toetsen de pasvorm wel.
• Geen benoemde data-eigenaar. Onderdeelnummering, stuklijststructuur en vrijgaveregels hebben één verantwoordelijke nodig voordat een leverancier ze configureert.
• Demo's met data van de leverancier. Een gepolijste demonstratie toont het datamodel van de leverancier. Voorbeelddata van de eigen producten van de koper leggen hiaten vroeg bloot.
• Vergelijken op prijs alleen. TECHNIA merkt op dat beslissingen op basis van verkooppraatjes, populariteit of prijs een systeem kunnen opleveren dat niet bij de workflows past. Vergelijk de kosten over de volledige looptijd, zoals in wat PLM-software kost.
• Eisen opgesteld door een kleine groep. Aras beschrijft software die wordt opgelegd aan gebruikers die er niet bij betrokken waren, wat weerstand uitlokt. Workshops met engineering, productie, kwaliteit en inkoop verbreden de input.

Fouten tijdens de implementatie

Implementatiefouten verschijnen vaak als vertraging en herwerk. De meeste zijn terug te voeren op een beslissing uit de selectie die niemand heeft herzien.

• Big-bang-scope. Arena noemt te snel implementeren een van de adoptiefouten en stelt fasen voor die beginnen met de kern: stuklijst-, wijzigings- en documentbeheer.
• Migratie die laat wordt opgepakt. Profileren en opschonen kosten doorlooptijd, en Arena merkt op dat slechte invoer slechte resultaten geeft.
• Te veel maatwerk. Elke uitbreiding verhoogt de kosten van elke latere upgrade.
• Integratieplanning tot het eind uitgesteld. Arena en TECHNIA beschrijven allebei datasilo's wanneer koppelingen met ERP, CAD en andere systemen laat worden gepland.
• Geen sponsor in het management. Aras wijst op leidinggevenden die een snelle oplossing verwachten en hun geduld verliezen.
• Onduidelijke doelen. TECHNIA noemt onrealistische verwachtingen dat het systeem alles zelf oplost. Specifieke, tijdgebonden doelen die aan benoemde pijnpunten zijn gekoppeld, geven het team in elke fase iets om te toetsen.

Fouten na de livegang

Een release die technisch werkt, kan het dagelijks werk toch onveranderd laten. De signalen zijn te zien in het gedrag van engineers, inkopers en kwaliteitsmedewerkers in de maanden na de start.

• Aangehouden spreadsheets. Arena noemt oude gewoonten als fout. Teams blijven spreadsheets en papier gebruiken zolang de oude routes niet zijn gesloten.
• Training die stopt bij de livegang. Rolgebaseerde training voor interne gebruikers en externe partners gaat na elke release door.
• Geen governance. Zonder wijzigingscommissie en datastewards raken onderdeelrecords uit de pas en is de migratie-inspanning verspild.
• Geen meting. TECHNIA stelt voor indicatoren te volgen zoals ontwikkeltijd en productkwaliteit. Volg daarnaast gebruik en datakwaliteit.

Hoe voorkom je deze fouten?

Gebruik de tabel als reviewchecklist bij elke fasepoort, waarbij de projectsponsor, de data-eigenaar en de key users elk hun eigen rijen goedkeuren. Een fout die tijdens de selectie wordt ontdekt, kost een herschreven eis. Dezelfde fout na de livegang kost herwerk in geconfigureerde processen en gemigreerde data.

Veelgestelde vragen

Bronnen

• Aras: Why do PLM selection projects fail?
• Arena: Top 10 PLM adoption mistakes to avoid
• TECHNIA: Barriers to PLM implementation

Geschreven door Nathalie Paniuta. Gecontroleerd op 4 november 2026 door de redactie van PLM Vendors. Regelgevingsdata en leveranciersgegevens veranderen; raadpleeg de bronnen voor de actuele stand. Correcties met bron: info@plmvendors.com.