Becsült olvasási idő: 6 perc

A termék életciklus-menedzsment (PLM) rendszerek bevezetése és migrációja az egyik legösszetettebb feladat, amivel egy mérnöki szervezet szembesülhet. Tapasztalatunk szerint az ilyen projektek kudarcáért szinte soha nem azok a tényezők a felelősek, amelyekre egy hagyományos projektterv felkészül. Az iparágban ugyanis makacs tévhitek övezik a bevezetési és migrációs folyamatokat, amelyek elkerülhetetlenül túllépett költségvetésekhez, csúszásokhoz és működési nehézségekhez vezetnek.

A tiszta adat illúziója és a tulajdonosi vákuum

Minden szervezet szilárdan meg van győződve arról, hogy az adatai „nagyrészt tiszták”. A valóságban azonban egy átfogó PLM-adatfelmérés szinte mindig sokkoló képet fest: a darabjegyzékek (BOM-ok) 20–40%-a tartalmaz strukturális hibákat vagy hiányzó alkatrészeket, a cikkszámok duplikálódnak a termékcsaládok és üzletágak között, az elárvult dokumentumoknak nincs érvényes kapcsolatuk, a revíziók nem egyeznek a vault fájlokkal, a lejárati és életciklus-állapotokat pedig soha senki nem tartotta karban. Ennek a mélyebb gyökere a tulajdonosi vákuum: a mérnökség IT-problémának tekinti a helyzetet, az IT viszont mérnöki döntésnek véli, miközben az adathiány növekszik, a migráció pedig elakad. Ha a régi technológiát változatlan formában migráljuk, az azonnal felemészti az újonnan bevezetett PLM-befektetés értékét.

Mit teszünk mi? Alapos mérnöki felmérés előzi meg az ajánlatadást, amely nem csupán a műszaki és informatikai tényezőkre tér ki, hanem a bevezetés üzleti értékére és megtérülésére is.

Amikor a migráció álcázott transzformációvá válik

A hatókör (scope) bővülése ritkán véletlen – szinte mindig a „csak még egy követelmény” csapdájából fakad. A migrációs projektek gyakran abba buknak bele, hogy az „A rendszerből B-be visszük az adatokat” alapcél csendben átalakul a BOM-hierarchia újrastrukturálásává, új besorolási sémák bevezetésévé, a felvásárolt cégek cikkszámainak harmonizálásává vagy éppen egy évtizedes dokumentumkezelési adósság eltakarításává. Bár ezek valós üzleti igények, soha nem a migráció keretein belül kellene megoldani őket. Ha a migrációt használják a szervezeti transzformáció álcájaként, a programok könnyedén 2-3-szorosára duzzasztják a költségeket és az időkeretet.

Mit teszünk mi? A felmérés során élesen különválasztjuk az egyes követelményeket, és az azok megvalósításához szükséges feladatokat, felelősöket. A bevezetés során folyamatosan agilisen adjuk hozzá a rendszerhez a követelményekben foglalt funkciókat.

Kanonikus modell hiánya és a CAD-migráció rejtett csapdái

Ha a csapat nem határoz meg előre egy kanonikus modellt, a folyamat végén csupán átörökíti az inkompatibilitásokat a jövőbe. A forrás- és a céladatmodellek ritkán illeszkednek egymáshoz: a relációs adatbázis-struktúrák és az objektum-központú PLM-architektúrák alapvető szemléletbeli eltérései miatt az attribútumok, a kapcsolatok és az érvényességi logikák nem képezhetők le 1:1 arányban. Ezt tetézi a vegyes CAD-környezet (ahol az NX, a SolidWorks és a CATIA gyakran egyszerre van jelen), ahol a fájlok hivatkozásai csendben sérülhetnek, és a hiba csak akkor derül ki, amikor egy mérnök határidős munkája során nem tud megnyitni egy összeállítást. A CAD-fájlok ugyanis nem csupán egyszerű csatolmányok, hanem verzióérzékeny mérnöki műtárgyak, amelyek saját munkafolyamatot, eszközkészletet és validációs protokollt igényelnek.

Mit teszünk mi? A tapasztalatunk révén tanácsot tudunk adni a megfelelő adatstruktúrára és szükség esetén automatizálni tudjuk az adatok átalakítását, átstruktúrálását.

Hamis magabiztosság és a technikai szemlélet tévútja

A legsúlyosabb iparági hiba annak a hitnek a táplálása, hogy egyetlen sikeres tesztbetöltés elegendő validáció. A valóságban a reprezentatív mintáknak a rendszer legbonyolultabb, legzavarosabb BOM-jait kell lefedniük, és end-to-end folyamatvizsgálatot, integrációs tesztelést, valamint tényleges mérnökök által végzett felhasználói tesztelést kell megkövetelniük. Ha ez hiányzik, a hibák a go-live után jelentkeznek, a mérnökök pedig elveszítik a bizalmukat, és árnyékrendszereket kezdenek használni a megosztott mappákban.

Mit teszünk mi? Széleskörű automatizált tesztekkel valós körülményeket tesztelünk, így valóban megbízhatóan működő rendszert adunk át.

A legnagyobb hiba mind közül mégis az, ha a migrációt tisztán informatikai projektként kezeljük. Egy alkatrészszám sokkal több, mint egy egyszerű karakterlánc: magában foglalja a revíziós vonalat, a jóváhagyott beszállítókat, a megfelelőségi bizonyítékokat és a mérnöki szándékot is. Ha ezeket a kontextusokat figyelmen kívül hagyjuk, egy olyan technikai adattemetőt hozunk létre, amely működési szempontból teljesen hatástalan. A sikeres PLM-migráció nem a technológiáról, hanem a gondos tervezésről, a határozott irányításról és a helyes üzleti folyamatok kialakításáról szól. Ebben tudunk mi, a graphIT Kft.-nél segíteni.