Inhoudsopgave
Problematiek
De problematiek van data uitwisseling heeft verschillende oorzaken. De meest voorkomende zijn:
- Er is geen gespecificeerd proces en werkwijze bij een klant en/of leverancier voor het uitwisselen van informatie
- Er is geen gespecificeerd uitwisselingsformat of het is heel specifiek format per leverancier.
- De leverancier heeft geen of een andere PLM systeem als de klant.
- De leverancier heeft niet hetzelfde CAD pakket of dezelfde actuele versie als die van de klant.
- Het verzamelen van informatie is handwerk, tijdrovend en foutgevoelig.
- Er is geen controle of registratie van informatie die door de klant verzonden en door de leverancier is ontvangen.
- Bij wijzigingen is het niet mogelijk om alleen wijzigingen door te sturen.
- Wijzigingen kunnen niet apart verwerkt worden bij een leverancier of niet getraceerd worden.
Naast deze concrete problemen is er ook sprake van een toenemende complexiteit in de definitie van producten, zowel inhoudelijk als in beschrijvende gegevens. Gecombineerd met een continue bedrijfsdoel van hogere efficiency, effectiviteit en traceerbaarheid is het onder controle brengen van data uitwisseling niet meer alleen een streven maar een eis geworden.
Aanpak
Bij de aanpak van de problematiek van data uitwisseling willen wij ons niet direct op de problemen richten maar op een structule opzet van proces en werkwijze om de informatiestroom en acties onder controle te houden. Daarvoor hebben we eerst naar de de informatiestroom en de acties die leiden tot verschillende deel stadia van informatie. Daarna hebben we de functionele requirements opgesteld en aannames verzameld waaraan process en werkwijze moeten voldoen om kwaliteit te waarborgen. Vervolgens hebben we gekeken welke technische requirements en technische oplossingen mogelijk zijn voor delen van de het proces.
Informatiestromen
Bij data exchange is met name sprake van een informatiestroom. Deze informatiestroom kan en wordt op een aantal plekken beinvloed. De basis benadering voor de uitwisseling van informatie is hieronder informatie gegeven.
Uitgangspunt is dat een klant informatie toe moet leveren aan één of meerdere leveranciers. Deze klant kan in principe zelf ook leverancier zijn die informatie beschikbaar moet stellen aan zijn eigen leveranciers. De uitwisseling van informatie bestaat uit de volgende acties:
 |
De 'klant' maakt een export van alle gegevens die nodig zijn voor de leverancier. |
|---|---|
 |
Het door de klant gegenereerde data exchange pakket heeft in dit (ideale) geval een format wat direct door zijn leveranciers kan worden geimporteerd en gebruikt. |
 |
De leverancier importeert de geleverde gegevens in zijn/haar PLM systeem en brengt ze daarmee onder beheer. Aanname is altijd dat de ontvangen gegevens per definitie onder wijzigingsbeheer door de klant vallen (master data management) en daarmee bij en door de leverancier niet wijzigbaar zijn. Bij een aanlevering van gewijzigde gegevens door de klant zullen de wijzigingen onder configuratiebeheer geimporteerd worden. Bij een ideale inrichting zal de klant alleen gewijzigde informatie aanleveren om uitwisselingspakketten klein te houden. Dit kan dan wel alleen als er een cerftificering heeft plaatsgevonden bij de leverancier dat deze in staat is middels configuratiebeheer wijzigingen te kunnen traceren. |
In de praktijk zullen door een klant geexporteerde gegevens vaak niet direct voldoen aan voorwaarden om deze direct uit te kunnen wisselen. Redenen kunnen zijn dat het format heel specifiek is voor zijn/haar PLM pakket, dat gegevens verzameld moeten worden uit verschillende systemen of dat conversie nodig is naar een beter format. Dit kan ook voorkomen bij de leverancier, wat in een complex geval leidt tot onderstaande informatiestroom met verschillende acties.
|
De 'klant' maakt een export van alle gegevens die nodig zijn voor de leverancier. |
|---|---|
 |
De initiele export heeft een proprietair format, afhankelijk van het PLM systeem of de systemen die in gebruik zijn. |
 |
Door middel van een conversie kan het propriétaire format omgezet worden naar een generiek format. De conversie bestaat uit twee hoofddelen; |
|
Het generieke format is in principe door verschillende partijen te gebruiken, maar kan gefilterde informatie voor een specifieke leverancier bevatten. Alle informatie is in ieder geval in een dusdanig format beschikbaar dat dit door elke leverancier kan worden gebruikt voor verder verwerking. |
|
Na een eventuele conversie van de leverancier in zijn/haar eigen propriétaire format kunnen de gegevens geimporteerd worden. |
Requirements en aannamen
Als gevolg van analyse van de informatiestroom en de verwachte acties kunnen we de volgende aannamen en functionele requirements opstellen.
Aannames
- De klant is te allen tijde verantwoordelijk voor de kwaliteit van zijn of haar data. Dit geldt ook voor de kwaliteit van geconverteerde gegevens.
- Native CAD gegevens kunnen worden uitgewisseld en worden gebruikt als de leverancier hiermee overweg kan.
- Bij aanlevering van gelijke (3D) informatie in meerdere formats moet met de klant overeen zijn gekomen welke informatie leidend is. De overige informatie is dan per definitie afgeleid en ter referentie. Als een leverancier deze gegevens in zijn eigen hoofdproces gebruikt is hij verantwoordelijk voor het veriifieren van de gegevens met de master data.
- Aan een leverancier aangeleverde informatie valt per definitie onder wijzigingsbeheer van de klant en zijn niet wijzigbaar (read-only) door de leverancier.
- Wijzigingen door een klant aangeleverd moeten onder configuratiebeheer worden verwerkt in het PLM systeem van de leverancier.
- Kwaliteitscontrole van de gegevens -met uitzondering van conversiestappen- valt buiten de verantwoordelijkheid van het data uitwisselingsproces. Eventuele fouten die bijvoorbeeld door een leverancier worden geconstateerd vallen onder het afspraken rondom het wijzigingsproces tussen klant en leverancier.
Requirements
- De klant moet zorg dragen dat geregistreerd wordt welke informatie met een leverancier is gecommuniceerd.
- De leverancier is verantwoordelijk om alle ontvangen gegevens als read-only te beschouwen waarbij wijzigingsbeheer door de klant wordt uitgevoerd.
- Wijziigngen door de leverancier uitgevoerd zijn mogen niet leiden tot een gewijzigd product tenzij overeengekomen met de klant als onderdeel van een wijzigingsaanvraag of met toestemming van de klant als deviation.
- Het generieke data uitwisselingspakket bevat alle productgegevens, stuklijsten en files van één specifiek (top)product.
- Het genereren van een data uitwisselingspakket moet plaats kunnen vinden als automatisch proces, gestuurd door opties die bepalen welke data types nodig zijn.
- Als een klant wijzigingpakketten aanlevert aan een leverancier moet aangegeven worden op welke eerder gestuurde gegevens deze gebaseerd zijn (baseline).
- Een klant certificeert haar leverancier of leverancier toont aan dat zij wijzigingen onder configuratiebeheer verwerkt en traceerbaar maakt.
- Het generieke data uitwisselings format
- bevat informatie in een consistente en eenduidige vorm;
- valt zelf onder wijzigingsbeheer tussen klant en leverancier;
- is eenvoudig uitbreidbaar;
- is beveiligd;
- maakt gebruik van (open) standaarden.
- Conversie door klant of leverancier valt onder verantwoordelijkheid van de respectievelijke partij. Deze partij draagt zelf zorg voor de garantie van kwaliteit van dit proces, ofwel door een eenmalige validatie van het proces ofwel door review van de resultaten.
Implementatie
Voor implementatie hebben we aparte specificaties opgesteld voor de volgende onderwerpen:
- Export en Conversie
- Generiek Data Exchange Format
- Conversie en Import
- Wijzigingsbeheer
- Configuratiebeheer
We gaan er hierbij uit dat een leverancier mogelijk geen beschikking heeft over een eigen PLM systeem of een systeem met beperkte mogelijkheden.