.svg)
Varför rip-and-replace ERP-modernisering inte fungerar
Historiskt sett förlitade sig ERP-uppgraderingar ofta på ett big-bang- eller rip-and-ersätt-tillvägagångssätt, där hela organisationen övergick från det äldre systemet till det nya i en enda cutover. I tillverkningen skapar detta för mycket volatilitet.
Äldre ERP innehåller vanligtvis årtionden av anpassad kod, odokumenterade lösningar, och affärslogik som aldrig formellt spelades in. Att försöka kartlägga all den komplexiteten i ett nytt system på en gång skapar en stor marginal för fel. Om ett kritiskt produktionsflöde misslyckas dag ett är effekten omedelbar. Linjer stannar, beställningar missar leveransfönster och leverantörs- och kundrelationer tar träffen.
Problemet förvärras av hur djupt tillverkande ERP ansluter till omgivande system. Det integreras vanligtvis med MES, WMS, PLM, CRM, finansverktyg och upphandlingsplattformar. En fullständig nedskärning innebär att var och en av dessa anslutningar måste fungera korrekt från dag ett. I en komplex miljö är det sällan realistiskt.
En stegvis migrationsstrategi tar itu med detta genom att bryta processen i mindre, mer inneslutna övergångar snarare än ett drag med höga insatser.
Hur man formulerar en stegvis ERP-migreringsstrategi
En stegvis migreringsstrategi bryter ERP-moderniseringen i mindre, mer hanterbara vågor. Istället för att ersätta hela ERP-stacken på en gång, migrerar företag utvalda funktioner över tid.
Detta är särskilt användbart vid tillverkning eftersom inte alla processer bär samma nivå av operativ risk. Vissa funktioner kan moderniseras tidigare med mindre påverkan, medan mer känsliga processer kan flyttas senare, när arkitekturen och integrationsvägarna har bevisats.
Två metoder utgör grunden för de flesta fasade ERP-migreringar inom tillverkningen: strangler fig-mönstret och parallellkörningsstrategier.
1. Strangler Fig-mönstret för äldre ERP-ersättning
Strangler fikonmönstret är en stegvis moderniseringsmetod där specifika delar av ett äldre system gradvis ersätts av nya appar eller tjänster tills det gamla systemet kan dras tillbaka.
Tillämpat på ERP-migrering fungerar mönstret genom att bygga den nya miljön runt kanterna på den äldre plattformen. Specifika moduler dirigeras till det nya systemet en i taget, medan det äldre ERP-systemet fortsätter att hantera allt annat. En tillverkare kan börja med att migrera upphandling och leverantörshantering. Den nya upphandlingsmodulen går live, inköpsdata flyter genom den och motsvarande äldre modulen är inaktiverad. Ekonomi, personal och lagerhantering fortsätter att köras på det gamla systemet. Under efterföljande faser migrerar fler moduler tills den äldre plattformen kan avvecklas.
Den viktigaste fördelen är riskisolering. Om ett datamappningsproblem påverkar upphandlingsmodulen förblir den innesluten där snarare än att störa ekonomi eller produktionsschemaläggning samtidigt.
2. Parallellkörningsstrategier för datavalidering
Även vid migrering av en enda modul måste företag verifiera att det nya systemet producerar korrekta utdata innan den äldre versionen stängs av. Parallellkörningsstrategier möjliggör detta.
En parallellkörning innebär att både den äldre modulen och dess ersättning används samtidigt under en definierad testperiod. Samma transaktioner behandlas i båda miljöerna och utgångarna jämförs. För en finansiell modul kan det innebära att du matar in fakturadata i båda systemen och avstämmer de resulterande huvudböckerna i slutet av varje dag. Om siffrorna överensstämmer konsekvent över hela konjunkturcykeln har det nya systemet visat sig tillräckligt med noggrannhet för att ta över. Om avvikelser uppstår undersöker och korrigerar det tekniska teamet datamappningen utan att påverka live-poster, som förblir säkra i det äldre systemet.
Det är viktigt att definiera tydliga, mätbara framgångskriterier innan man startar en parallellkörning. Utan dem blir det svårt att avgöra när det nya systemet verkligen är klart.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
