Berichten

volkerrail-icon

Infrabedrijf VolkerRail wordt een bouwend ICT-bedrijf

TechniaTranscat en VolkerRail werken reeds jaren samen om de informatie van hun producten te managen en te zorgen dat de juiste informatie beschikbaar is voor de organisatie.
In de afgelopen jaren heeft TechniaTranscat veel meerwaarde gebracht aan VolkerRail op vlak van informatiemanagement. Over de ontwikkelingen, de manier van werken en de samenwerking kunt u meer lezen in dit artikel.

Bronvermelding: LINK magazine juni 2016. linkmagazine

Enovia 3DExperience 2016X up and running!

Voor het VIPE project (Vanderlande Integrated PLM Experience) heeft TechniaTranscat de OTAP straat ge-upgrade van versie 2014x naar 2016x. Hiermee wordt het project verrijkt met bijvoorbeeld standaard ‘Single Sign On’ functionaliteit met behulp van 3DPassport van Dassault Systèmes. Met 3DPassport worden vanaf 2016x alle (toegangs)rechten geregeld.

voor artikel 2016x

Wat is een OTAP straat?

Tijdens de start van het VIPE project zijn meerdere omgevingen opgezet in wat een OTAP straat wordt genoemd. Dit staat voor Ontwikkel, Test, Acceptatie en Productie. Door meerdere omgevingen op te zetten kunnen gecontroleerd wijzigingen worden doorgevoerd waarbij het testen van de  functionaliteit een cruciaal onderdeel vormt.
Een OTAP straat opzetten kost tijd en vergt onderhoud, maar TechniaTranscat is van mening dat dit voor ieder project de moeite waard is, omdat het dure fouten in productie voorkomt. Eigenlijk hetzelfde als bij productontwikkeling.

Nieuw in Enovia 2016 X

Wat is er nog meer nieuw in 2016X ? Te veel om in een kort nieuwsbericht te laten zien, maar in ieder geval: Volledig vernieuwde user interface waarbij ook navigatiestructuren zijn aangepakt. Hierdoor zijn er nog minder mouse clicks nodig voor dezelfde handelingen dan in 2014x én is het nog overzichtelijker voor de gebruiker. Tevens zorgt dit er voor dat Enovia op mobiele apparaten betere performance laat zien. Daarnaast is er veel gesleuteld aan het business analytics gedeelte. Het is makkelijker geworden om een dashboard te maken voor het rapporteren van (productontwikkeling) performance. Ook in het CAD stuk zijn veel verbeteringen aangebracht; zo is SolidWorks nog beter geïntegreerd waardoor op sommige vlakken 40% performance winst is behaald. Als laatste willen we nog even het 3DSearch stuk aanhalen waar met behulp van de 6WTags de gebruiker vele malen sneller uitkomt bij productinformatie. Dit is een onontbeerlijk stuk gereedschap voor PLM implementaties.

Voortgang VIPE

Het Vipe project wordt gefaseerd aangepakt. Hierbij worden alle afzonderlijke fases voorbereid, gebouwd, getest en geaccepteerd. Op dit moment zijn de eerste twee fases (opzetten wereldwijde infrastructuur en de opleveren eerste functionaliteit) geaccepteerd en staan klaar voor productie. Voor de zomervakantie moet de volgende fase zijn geaccepteerd en de daaropvolgende in testfase staan. Uitrol vindt plaats in voorjaar 2017.

Neem contact op met Maarten Van den Nieuwenhuijzen voor meer informatie over Enovia 2016X.

infostrait-maarten-van-den-nieuwenhuijzen

 

 

configuration management

Configuratie Management

Ik ben IJsbrand Schipperus, PLM consultant bij TechniaTranscat. Al sinds het begin van mijn carriere speelt het beheren van data een rol. In het begin, in de rol van tekenaar / constructeur, speelde het vooral als gebruiker. Later ben ik me er echt in gaan verdiepen en er blijkt altijd nog weer een onderwerp te zijn dat erg interessant is, maar dat nog wat uitleg behoeft. Zo ook dit onderwerp.

Met deze blog wil ik u kennis laten maken met Configuratie Management. Ik wil u laten zien wat het is, hoe het werkt en vooral wat u er aan heeft. Ook komen zaken als valkuilen bij implementatie aan de orde.

Wat is het?

Configuratie Management is het beheren van Configuraties. Een Configuratie in deze context is een set data die hoort bij een bepaalde Levensfase van een product. Dit is het makkelijkste uit te leggen aan de hand van een voorbeeld.

Een veel gebruikte Configuratie is ‘As Required’. In deze Configuratie zitten alle documenten en gegevens die nodig zijn om te omschrijven hoe het product ‘er uit ziet’ zoals het gewenst is. In deze configuratie zitten bijvoorbeeld Requirement Specificatie documenten.

Een andere veel gebruikte Configuratie is ‘As Designed’. In deze configuratie zitten alle documenten die het product specificeren zoals het ontworpen is. Hier vind je vaak (3D) CAD data, electrische- en hydraulische schema’s en software terug.

Door het gebruik maken van Configuraties, ontstaat de wens om deze te beheren. Iemand zal het overzicht moeten hebben over alle Configuraties, alle medewerkers beperken zich immers tot één Configuratie. Degene die alle Configuraties beheerd, wordt de Product Owner genoemd. Elk Product of Artikel heeft een eigen Product Owner.

Hoe werkt het?

We zijn gewend steeds meer data te vergaren en op te slaan over onze producten. Zo is het tegenwoordig heel normaal dat we 3D CAD data opslaan om ook een beeld te hebben van het product en om deze te kunnen simuleren. Daarnaast bestaat nog de werktekening die er voor zorgt dat ons product gemaakt kan worden. De trend is om alle product data te gaan bundelen, hiervoor hebben we een PDM/PLM systeem nodig. Denk bijvoorbeeld aan software die bij een product hoort. Multidisciplinaire CAD data waar dus ook electrische- of hydraulische ontwerpen in zitten, maar ook de requirements, handleidingen, brochures en renderings van het product.

Hierdoor krijgen we Artikelen in PLM waar een verscheidenheid aan data aan hangt. Fijn dat het allemaal bij elkaar op één plek staat, maar moet het Artikel nu echt gereviseerd worden als we een nieuwe rendering toe willen voegen? Als we een spelfout uit de manual willen halen, en we maken een nieuwe revisie van het Artikel, moet dan alles weer gecontroleerd worden bij een vrijgave? Hoe zorgen we dat we precies dat stukje dat gewijzigd is wèl goed checken, en de rest gewoon laten zoals het is?

Door Configuraties te gaan gebruiken, deel je de product data op in logische blokken. Meestal is een afdeling verantwoordelijk voor een Configuratie. Zo is Verkoop of Marketing verantwoordelijk voor de Configuratie ‘As Required’ en Engineering voor de Configuratie ‘As Designed’. Elke Configuratie kent zijn eigen levenscyclus, een vrijgegeven Configuratie noemen we een Baseline.

Deze Baselines gebruiken we vervolgens als startpunt als we aan de slag willen met een Artikel. Een Product maken we door de laatste Baseline van een Configuratie te nemen en deze aan te vullen met alle goedgekeurde Changes.

Als we een goedgekeurde wijziging hebben, kunnen we deze direct doorvoeren. Ook als verderop in het proces nog gewerkt wordt aan een andere configuratie van het Artikel.
Doordat de configuraties onafhankelijk van elkaar zijn, kunnen ze ook onafhankelijk van elkaar gewijzigd worden. Natuurlijk kunnen wijzigingen ook invloed hebben op meerdere Configuraties.

Revisie / versie

Even een zijstapje naar het onderwerp Revisie / Versie. Als we kijken naar bovenstaande verhaal, dan is het verschil tussen een Revisie en een Versie heel simpel uit te leggen:

Een Revisie is een verandering in het Artikel / Product op basis van dezelfde Requirements.

Een Versie is een verandering in het Artikel / Product op basis van nieuwe Requirements.

Voordelen

Een voordeel dat we al gezien hebben is dat het product in een duidelijke structuur wordt opgedeeld. Daarnaast zagen we dat we een afdeling of groep mensen verantwoordelijk kunnen maken voor precies dat deel waar ze ook echt verantwoordelijk voor zijn.

Er is echter nog een groot voordeel. Doordat de Configuraties hun eigen levenscyclus hebben, kunnen ze onafhankelijk van elkaar aangepast worden. Er kan dus tegelijkertijd aan alle Configuraties gewerkt worden. Zo kan Manufacturing de eerste versie of revisie van een product alvast produceren, terwijl er ondertussen hard gewerkt wordt aan de volgende revisie door Engineering en tegelijkertijd door Marketing de requirements worden bijgesteld voor een volgende versie van het product.

Doordat alle afdelingen tegelijkertijd hun eigen Configuratie kunnen bewerken, kan de Time-To-Market drastisch omlaag. Ook wijzigingen kunnen sneller doorgevoerd worden, hierdoor kunnen we sneller nieuwere versies van het product op de markt brengen.

Een laatste voordeel is nog het beheren van uitgeleverde Configuraties. Door een configuratie ‘As Delivered’ of zelfs ‘As Serviced’ te gaan gebruiken is bij te houden wat er precies aan de klant is uitgeleverd en zelfs wat er tijdens service beurten vervangen is. Zo kun je bij het maken van een nieuwe revisie van een onderdeel snel achterhalen waar deze aanwezig is als je deze wilt vervangen.

Change Management

Het invoeren van Configuraties levert wel een punt van aandacht op: Als er iets wijzigt in een configuratie waardoor de andere Configuraties niet meer aansluiten, moet er actie worden ondernomen, terwijl een wijziging die verder geen consequenties heeft geen onnodig werk mag opleveren. Als de requirements wijzigen en de ontwerpen dekken deze daardoor niet meer af, lever je later een product af dat niet voldoet aan de eisen.

Het is daarom van belang om Change Management goed op orde te hebben of te brengen bij het in gebruik nemen van Configuration Management. Er zal in de change een moment moeten zijn dat er gekeken wordt óf het een Configuratie overschrijdende wijziging is of niet. Vaak kan dit pas als de wijziging ook echt doorgevoerd is, omdat je dan pas weet hoe deze precies is geworden. Maar voor sommige wijzigingen is vooraf al duidelijk dat deze grotere impact gaat hebben, of willen we zelfs de productie van de vorige revisie / versie stop zetten om problemen te voorkomen.

Change Management is dus een wezenlijk onderdeel van Configuratie Management!

Valkuilen

Naast de eerder genoemde Change Management kent Configuratie Management nog andere valkuilen. Sterke punten van deze methode kunnen bij verkeerde implementatie drempels opwerpen die er voor zorgen dat de uitkomst niet positief, maar negatief is.

Zo is het van groot belang te zorgen dat de Configuraties aansluiten op het proces binnen uw bedrijf. Als deze niet aansluiten, kan niet de juiste groep mensen gevormd worden die voor de Configuratie verantwoordelijk is. Ook kunnen Configuraties te ruim genomen worden, waardoor er juist te veel mensen binnen een Configuratie moeten werken en er te veel mensen verantwoordelijk voor zijn. De kracht was juist te zorgen dat groepen mensen hun ‘eigen’ Configuratie kunnen gebruiken.

Ook zal er goed nagedacht moeten worden hoe de Configuraties zich verhouden ten opzichte van elkaar. Wie bepaald wat? Als de verkeerde gegevens in de verkeerde Configuratie beheerd worden, zijn er mensen voor verantwoordelijk, die dat in werkelijkheid niet zijn. Het is dus belangrijk om vóóraf vast te leggen welke gegevens binnen elke Configuratie beheerd dienen te worden. Is dit nog niet duidelijk, dan dient eerst het bedrijfsproces vastgelegd en indien nodig gewijzigd te worden.

Meer weten? Neem dan contact met ons op!

config mgmnt plaatje