Naar aanleiding van een discussie in de LinkedIn PDM Platform groep wilde ik toch een en ander op een rijtje zetten rondom de voortdurende discussie de noodzaak en het kwaad van customization. Bedrijfsomgevingen groeien en processen, procedures en werkwijzen worden ingericht al naar gelang de behoeften van specifieke activiteiten. In de meeste gevallen leidt dit tot lokale oplossingen. Bij aanschaf van een (nieuw) PLM systeem komt vervolgens bijna altijd naar voren dat de werkwijzen van het systeem anders zijn dan die van het bedrijf.
Het is de leveranciers niet kwalijk te nemen dat niet alle bedrijfsomgevingen direct ondersteund kunnen worden. Het is ondoenlijk om alle werkwijzen in kaart te brengen en daarvoor functionaliteit te schrijven. De focus van leveranciers is, gezien hun eigen business model, de meest voorkomende werkwijzen te ondersteunen. Ik moet wel constateren dat veel software pakketten slecht te configureren zijn en dat customization vaak direct veel inzicht vereist in datamodel en specifieke APIs.
Daarnaast moet ik ook constateren dat bij de introductie van een PLM systeem de primaire houding is; 'Het beste systeem is het vorige systeem'. Wij allemaal als gebruikers zijn niet ingesteld op verandering. We kunnen door ervaring beter omgaan met een systeem waarvan we de fouten en eigenaardigheden kennen dan een nieuwe systeem waarvan de werkwijze nog niet eens duidelijk zijn. Er is dus altijd een schone taak weggelegd om gebruikers goed te begeleiden in dit veranderingsproces. Wat voorkomen moet worden is dat functionaliteit die in een oude omgeving als zeer nuttig wordt beschouwd wordt meegenomen. Er zal een zeer goede afweging plaats moeten vinden of de functionaliteit niet op een andere manier al beschikbaar is of dat werkwijze aangepast kunnen worden om beter aan te sluiten bij een nieuw bedrijfsproces. Let op; het gevaar is om het PLM systeem leidend te laten zijn in processen, procedures en werkwijzen. PLM als concept dekt een bedrijfsproces af en het PLM systeem dient dit te ondersteunen.
Customization is niet per se slecht en er is altijd een grijs gebied tussen customization en configuration. Een duidelijke scheidingslijn is meestal dat customization begint als het van effect gaan zijn op het basis model van het PLM systeem. Met name bij upgrades zal dan extra werk verzet moeten worden om de customization te controleren en afzonderlijk te updaten.
Customization of configuration kost geld; dit is niet te ontkennen. Bij de keuze om dit te doen kan en moet een kosten afweging gemaakt worden. Levert de tijds- en kostenbesparing door fout vermindering meer op dat de totale kosten voor definitie, ontwikkeling en onderhoud. Wat hierbij vaak als complicatie naar voren komt, is dat de wens voor aanpassing vanuit de gebruiker komt en de implementatie door een IT-afdeling gerealiseerd moet worden. Als binnen een bedrijf de verrekening van gebruik van in dit geval het PLM systeem niet duidelijk is zal, kan weliswaar een kosten-baten analyse gemaakt worden, maar is zullen de kosten van de IT afdeling omhoog gaan, terwijl de die voor de gebruiker niet veranderen.