ERP-byte: skilj anslutna dataflöden åt stegvis
Vid ett ERP-byte behöver anslutna applikationer tydliga överlämningspunkter. Ett avgränsat flöde gör ansvar och återgång möjliga att kontrollera.
Skilj de enskilda dataflödena åt innan du byter deras mål vid ett ERP-byte. En applikation som känner till det gamla ERP-systemets interna fält överallt är svårare att flytta riktat. En tydlig överlämningspunkt kan begränsa det beroendet.
Välj en avgränsad väg
I ett fiktivt företag skapar en portal order i det gamla ERP-systemet och får senare deras status. Just denna väg väljs som första migreringssteg. Andra anslutningar förblir i sitt avtalade läge. Kartlägg även återkopplingar och fördröjd bearbetning; en redan skickad order kan efter bytet fortfarande ge ett svar från det gamla systemet.
Microsoft beskriver stegvis ersättning via en förmedlare i Strangler Fig-mönstret. Det är ett arkitekturbeslut som kräver en insats. Det passar särskilt när den gamla och nya vägen kan finnas parallellt under en tid.
Håll verksamhetsbetydelsen stabil vid överlämningen
I exemplet överlämnar portalen en begäran om att skapa en order med sin egen åtgärdsidentifierare. En adapter översätter den till formatet för det avsedda ERP-systemet. ERP-systemets interna orderidentifierare kopplas till portalåtgärden.
Fas | Nya portalbegäranden | Order som redan skapats i gamla ERP |
|---|---|---|
Före bytet | Till gamla ERP | Koppla status via den gamla vägen |
Efter bytet | Till nya ERP | Fortsätt koppla återkopplingar via den gamla vägen |
Den gamla vägen avslutas | Till nya ERP | Klargör återstående fall slutgiltigt i förväg |
Tabellen är vår egen exempelfördelning. Två ERP-system får inte oberoende utföra samma begäran som en ny order. En teknisk parallelljämförelse behöver en separat säkrad väg utan dubbel effekt i produktion.
Kontrollera översättning och datakoppling
Ett Anti-Corruption Layer översätter mellan olika systemmodeller. Det kan ligga inuti en applikation. För vårt exempel måste artikel- och kundidentifierare samt betydelsen av mängder passa det nya ERP-systemet. Samma fältnamn är inget tillräckligt bevis för det.
Kontrollera en ny order och ett försenat statusmeddelande för en gammal order före bytet. Undersök om båda hamnar vid rätt portalåtgärd. Överföringen av befintliga data måste ta hänsyn till samma kopplingar.
Planera återgången med hänsyn till konsekvenserna för data
Ange när nya begäranden åter får använda den gamla vägen. Hantera separat de order som redan skapats i det nya ERP-systemet. Att växla tillbaka förmedlaren överför eller raderar dem inte automatiskt. Kontrollera också vem som övervakar och underhåller förmedlaren; den får inte obemärkt bli en flaskhals.
Den gamla anslutningen tas bort först när öppna återkopplingar och återstående beroenden har klargjorts. Dess slut beror därmed på de berörda åtgärderna och inte bara på datumet för den första lyckade nya begäran.
Källor
Läs vidare
Alla artiklar
API:er & integration med ASES
ERP, CRM och webbutik smidigt sammankopplade