Product Data Backbone

Een Product Data Backbone bundelt gegevens en documenten uit alle afdelingen en systemen in één centrale database. Een overkoepelend PLM-systeem moet daarom alle IT-systemen (ERP, CAD en PDM/PLM) die relevant zijn voor de productlevenscyclus in het bedrijf integreren en een centrale informatiebasis creëren. Hiermee is het fundament gelegd voor ononderbroken digitale informatieverwerking. In het PLM-systeem vloeien productgegevens en documenten in digitale vorm samen en worden ze vervolgens aan elkaar gekoppeld. Het resultaat is een helder inzicht in de totale levenscyclus van een product. Directe en functionele relaties worden zichtbaar en helpen wijzigingsconflicten te voorkomen. De Product Data Backbone vormt zo de ruggengraat voor alle digitale informatie die relevant is voor een product. Zonder deze ruggengraat is een naadloze digitalisering van productontwikkeling en -beheer in technische bedrijven niet mogelijk.

5.1 Digitaal platformInformatiebron voor de gehele productlevenscyclus

De Product Data Backbone verzorgt de verschillende afdelingen en bedrijfslocaties van een onderneming permanent en naadloos met informatie uit de productlevenscyclus. Daarbij is het essentieel dat alle gegevens die relevant zijn voor productontwikkeling en productmanagement digitaal met elkaar worden verbonden en dat hun onderlinge relaties zichtbaar worden gemaakt. Alleen zo kunnen processen digitaal worden aangestuurd. Productontwikkelaars kunnen bijvoorbeeld geïnformeerd worden over een mislukte test van een constructie die door hen is ontworpen, terwijl technische redacteurs door wijzigingen aan een component kunnen worden aangestuurd om de bijbehorende documentatie aan te passen.

Betrokkenen hoeven niet meer alle documenten op verschillende locaties bij elkaar te sprokkelen, maar worden via de relationele informatie in de Product Data Backbone automatisch van complete en actuele informatie voorzien.



Met PDM/PLM-software voor Product Lifecycle Management kan een bedrijf een Product Data Backbone opbouwen. Daarin vormen CAD-systemen (bijv. AutoCAD, Autodesk Inventor, Creo, Solid Edge en Solidworks) en een productdatamanagementsysteem (PDM-systeem) samen met een technisch documentmanagementsysteem (DMStec) een digitaal end-to-end platform dat samenwerking over de grenzen van het bedrijf heen ondersteunt en dat als PDM/PLM-systeem in het hele bedrijf kan worden gebruikt.

5.2 Productontwikkeling en productmanagementOp weg naar digital product engineering

De levenscyclus van een product begint met zijn ontwikkeling, ongeacht of het om pompen, motoren, componenten voor speciale machines of een complete grote technische installatie gaat. Technisch bedrijven zijn een belangrijk deel van hun tijd bezig om succesvol gebleken basiscomponenten van een product uit te breiden en aan te passen aan de specifieke eisen van klanten. Zij moeten hiervoor relevante documenten die eerder door anderen zijn opgesteld eenvoudig kunnen raadplegen. Om productontwikkelprocessen te versoepelen dient onder andere de samenwerking tussen de disciplines mechanica, elektrotechniek, elektronica en softwareontwikkeling te worden verbeterd. Hiervoor is een end-to-end inzicht vereist in de relaties tussen alle informatie die er rondom het product en in aangrenzende administratieve disciplines wordt gegenereerd. Dit is de eerste stap op weg naar digital product engineering.



In technische bedrijven worden de vele documenten die tijdens de levenscyclus van een product ontstaan meestal apart beheerd. Zo zijn de CAD-gegevens van productontwikkeling opgeslagen in PDM-systemen, maar worden productie- en logistieke data met eigen documentbeheerfuncties van de ERP/CRM-software beheerd. De communicatie met klanten verloopt weer via CRM-applicaties, terwijl sommige delen van de documentenstroom met klassieke DMS-systemen worden beheerst. Hierdoor is er geen sprake van een doorlopend proces, waardoor er regelmatig conflicten en storingen ontstaan. Het is dan zinvol om alle informatie en documenten over een product aan elkaar te koppelen. Dit kan het best met een centrale Product Data Backbone.

Serviceverlening wordt steeds meer onderdeel van het product zelf. Hoe meer maatwerk een fabrikant biedt, hoe belangrijker het is dat hij alle informatie en documenten over zijn producten direct bij de hand heeft. Tegenwoordig wordt er in dit kader over digitaal productbeheer en digitale informatietweelingen gesproken. PDM/PLM- en DMStec-oplossingen voegen alle informatie samen en structureren en visualiseren deze met technische structuren, bijvoorbeeld een machinestructuur met zijn ingebouwde modules en componenten. Wanneer een motor meervoudig in een machine of in meerdere machines voorkomt, dan zijn de gegevens over het vermogen van de motor aan alle motoren in de machines gekoppeld.

5.3 Digitaal informatienetwerkAlleen als mechanica, elektronica en softwareontwikkeling ook met elkaar communiceren

Binnen de productiesector hebben de commerciële afdelingen hun processen vaak het verst end-to-end geautomatiseerd. Via hun ERP-systeem hebben ze centraal toegang tot alle informatie over mechanische onderdelen, elektronische componenten en software-elementen en kunnen ze deze op elk gewenst moment met elkaar in verbinding brengen.

Engineering kan deze relaties vaak niet leggen – ten minste daar waar nog niet met een PDM/PLM-systeem wordt gewerkt. Dit komt omdat alle informatie is opgeslagen in verschillende systemen, zoals MCAD en ECAD, en grotendeels door de ontwikkelaars zelf wordt beheerd. Als mechanische onderdelen, elektronische componenten en software-elementen niet met elkaar communiceren, ontstaan er geen digitale producten. Daarom is er een digitaal informatienetwerk nodig, waarin gegevens aan elkaar zijn gekoppeld.

Stel een ontwikkelaar van elektronische componenten besluit dat een printplaat vijf centimeter breder moet zijn. De ontwikkelaar van de behuizing moet hiervan dan automatisch in kennis worden gesteld. Engineeringafdelingen ontwerpen complexe constructies, maar ervaren zelden of nooit hoe de klant deze beoordeelt en of ze ook functioneren zoals gepland. Er wordt maar weinig feedback gegeven en als dit al gebeurt, bereikt deze maar zelden de engineers of productmanagers. Meestal lost de serviceafdeling storingen individueel en ad hoc op.



Zonder relaties geen feedback

Als iedereen alleen in zijn ‘eigen’ systeem werkt en daar dit soort wijzigingen doorvoert, bestaan er geen feedbackstromen naar engineering of productmanagement. Om nog maar te zwijgen van processen die storingen, onderdelen en reclamaties aan elkaar koppelen om klachten correct te kunnen evalueren. Zulke feedbackstromen zijn echter onontbeerlijk om fouten in constructies zo snel mogelijk te herstellen. Ontwerpers en engineers moeten weten dat een condensator regelmatig te heet wordt, omdat ze te weinig ruimte tussen componenten hebben ingepland. Ze moeten worden geïnformeerd, wanneer een onderdeel voortdurend defect raakt en wellicht helemaal opnieuw moet worden ontworpen.

Een ander gevolg is dat er voor een bepaald probleem meerdere oplossingen worden bedacht. Dit gebeurt vaak wanneer niet duidelijk is wie waarvoor verantwoordelijk is, bijvoorbeeld bij componenten die door hun functie aan verschillende afdelingen kunnen worden toegekend. Uiterlijk bij het voorbereiden van de productie moeten afdelingen om de tafel gaan zitten en besluiten welke oplossing uiteindelijk wordt gebruikt. Productieprocessen worden zo onnodig vertraagd. In het ergste geval wordt de fout helemaal niet ontdekt en wordt een component dubbel of verkeerd geproduceerd.
Steeds meer bedrijven beseffen hoe belangrijk het is om machineonderdelen van versienummers te voorzien, maar wat vaak nog ontbreekt is een verbinding met de versies van de machinesoftware. Debet hieraan is dat software tot voor kort nog een betrekkelijk kleine rol speelde bij de ontwikkeling van constructies. Door de digitalisering in technische bedrijven is dit sterk veranderd. Bij het opstellen van waardeproposities voor producten verschuift de focus meer en meer richting software. Nieuwe machines draaien op volledig nieuwe software die nauwelijks nog overeenkomsten vertoont met de software van modellen die tien jaar gelden werden geproduceerd. De fabrikant moet daarom precies weten welke machine wanneer met welke software is geleverd – anders wordt onderhoud erg lastig. Bovendien is het upgraden van oude software naar de nieuwste versie meestal niet mogelijk.

Een fabrikant moet weten welke componenten vaker defect raken dan andere. Hij moet snel kunnen bepalen hoe een component gerepareerd en vervangen wordt en welke preventieve maatregelen engineering en productmanagement toepassen om defecten te voorkomen. Wie over deze informatie beschikt en snel met de juiste afdeling communiceert, kan meteen adequate service verlenen en zich zo van zijn concurrenten onderscheiden. Essentieel hiervoor is de ontwikkeling van een onderhoudsmanagementstrategie op basis waarvan exact kan worden bepaald in welke machines van een klant een specifiek onderdeel zich bevindt, zodat dit overal kan worden vervangen nog voor de eerste problemen optreden. Op deze manier kunnen afspraken in servicelevelagreements probleemloos worden nagekomen en reclamaties tot een minimum worden beperkt.

5.4 Digital threadDigital thread verbindt operations en engineering

Bedrijven die inzicht hebben in de samenhang tussen onderdelen en reclamaties kunnen garantieclaims voorkomen en de kwaliteit van producten verbeteren. Door een digitale informatiestroom worden operations en engineering met elkaar verbonden en kunnen artikelen en componenten worden geëvalueerd. Om relaties te kunnen leggen tussen onderdelen en reclamaties is een Product Data Backbone vereist. De relaties tussen klanten en onderdelen alleen zijn niet voldoende. Deze zijn alleen van nut voor de serviceafdeling die hiervoor het CRM-systeem kan raadplegen. Ook engineers moeten direct worden geïnformeerd als er over een bepaald onderdeel veelvuldig klachten worden ingediend, zodat zij hier in ontwikkel- en productiedocumenten meteen rekening mee kunnen houden. Zonder deze feedback wordt het onderdeel gewoon verder gebruikt. Voor de serviceafdeling betekent dit elke keer weer hetzelfde probleem oplossen.

Een PDM/PLM-software moet ook in staat zijn om een relatie tussen zelf ontworpen onderdelen en ingekochte onderdelen in het ERP-systeem te leggen, voor het geval de ingekochte onderdelen storingsgevoelig zijn en vaak vervangen moeten worden. Ontwerpers en engineers worden in hun werk nauwelijks met zulke kwaliteitsproblemen geconfronteerd, waardoor bedrijven een groot potentieel om kosten te besparen onbenut laten. Door zelf een passend onderdeel te ontwerpen of inkoop te adviseren een ander onderdeel aan te schaffen, is er veel winst te behalen. Het enige dat hiervoor nodig is, is een bidirectionele interface tussen het PDM/PLM-systeem en het ERP-systeem. Deze zorgt ervoor dat informatie over en weer wordt gestuurd en de juiste relaties worden gelegd.



Verder is het zinvol om een wijzigings- of verbeteringsproces in te richten om de onderhoudshistorie van een artikel op te kunnen vragen. Al deze processen samen vormen uiteindelijk de digitale informatiestroom in uw bedrijf. Deze digital thread verbindt engineeringdata met operationele gegevens. Wanneer deze stroom consequent wordt beheerst, zal het aantal onderhoudstaken aanzienlijk dalen. Er ontstaat een verschuiving van reactief naar proactief onderhoud. Dit leidt tot aantrekkelijkere servicelevelagreements die ook nog eens gemakkelijker nagekomen kunnen worden. En als het aantal storingen daalt, stijgt de productkwaliteit.

Met behulp van een Product Data Backbone vinden mechanica, elektronica en softwareontwikkeling een gemeenschappelijke taal. Door productrelevante gegevens en documenten aan elkaar te koppelen, ontstaat een digitaal informatienetwerk dat alle componenten met elkaar verbindt, ongeacht of het daarbij gaat om mechanische, elektronische of softwarecomponenten. Hierdoor wordt inzichtelijk welke component waar, wanneer en met welke versie is gemonteerd of hergebruikt. Bedrijven die hun informatie eenduidig hebben vastgelegd en verantwoordelijkheden duidelijk hebben geregeld, worden veel minder vaak met dubbele oplossingen geconfronteerd.

Door commerciële informatie uit het ERP-systeem in de Product Data Backbone op te nemen, krijgen enigneers al tijdens de ontwikkelfase toegang tot componenten die de voorkeur van het bedrijf hebben (op voorraad, voordeliger, snelle leverancier). PDM/PLM en ERP wisselen informatie uit en leggen relaties tussen componenten onderling en tussen componenten en projecten.

Eenduidige informatie tijdens het ontwikkelproces is essentieel voor een nauwe samenwerking tussen de verschillende afdelingen. Alle betrokkenen weten wat ze moeten doen. Ze kunnen zien welke componenten er al in een mechatronische structuur aanwezig zijn, wie deze heeft ontwikkeld en wat de gevolgen zijn wanneer er iets wordt veranderd. Hierdoor is er minder communicatie en afstemming vereist en wordt de samenwerking sterk vereenvoudigd. Constructies worden snel en foutloos geproduceerd en geleverd.



Door de groeiende digitalisering kunnen kleine en middelgrote bedrijven in de maakindustrie – met name technische bedrijven – in de toekomst niet meer om een digitaal informatienetwerk heen. Het is daarom zinvol om een PDM/PLM-systeem als Product Data Backbone te introduceren en zo de voorwaarden te scheppen voor digitale producten.