ERP-bytte: skill tilknyttede dataflyter trinnvis
Ved et ERP-bytte trenger tilknyttede applikasjoner klare overleveringspunkter. En avgrenset dataflyt gjør ansvar og tilbakevei kontrollerbare.

Skill de enkelte dataflytene før du bytter målet deres ved et ERP-bytte. En applikasjon som kjenner det gamle ERP-systemets interne felt overalt, er vanskeligere å flytte målrettet. Et klart overleveringspunkt kan begrense denne avhengigheten.
Velg en avgrenset vei
I en oppdiktet virksomhet oppretter en portal ordrer i det gamle ERP-systemet og mottar senere statusen deres. Nettopp denne veien velges til første migreringstrinn. Andre forbindelser blir i sin avtalte tilstand. Kartlegg også tilbakemeldinger og forsinket behandling; en allerede sendt ordre kan etter byttet fortsatt gi et svar fra det gamle systemet.
Microsoft beskriver trinnvis utskifting via et mellomledd i Strangler Fig-mønsteret. Det er en arkitekturbeslutning som krever innsats. Den passer særlig når gammel og ny vei kan eksistere side om side en periode.
Hold forretningsbetydningen stabil ved overleveringen
I eksemplet overleverer portalen en forespørsel om ordreopprettelse med sin egen handlingsidentifikator. En adapter oversetter den til formatet til det tiltenkte ERP-systemet. Den interne ERP-ordreidentifikatoren knyttes til portalhandlingen.
Fase | Nye portalforespørsler | Ordrer som allerede er opprettet i gammelt ERP |
|---|---|---|
Før byttet | Til gammelt ERP | Knytt status gjennom gammel vei |
Etter byttet | Til nytt ERP | Fortsett å knytte tilbakemeldinger gjennom gammel vei |
Gammel vei avsluttes | Til nytt ERP | Avklar resterende tilfeller endelig på forhånd |
Tabellen er vår egen eksempelfordeling. To ERP-systemer må ikke uavhengig utføre samme forespørsel som en ny ordre. En teknisk parallellsammenligning trenger en separat sikret vei uten dobbel virkning i produksjon.
Kontroller oversettelse og datakobling
Et Anti-Corruption Layer oversetter mellom ulike systemmodeller. Det kan ligge inne i en applikasjon. I vårt eksempel må vare- og kundeidentifikatorer samt mengdenes betydning passe til det nye ERP-systemet. Samme feltnavn er ikke tilstrekkelig bevis for dette.
Kontroller en ny ordre og en forsinket statusmelding til en gammel ordre før byttet. Undersøk om begge havner ved riktig portalhandling. Overføring av eksisterende data må ta hensyn til de samme koblingene.
Planlegg tilbakeveien med tanke på konsekvensene for data
Fastsett når nye forespørsler kan bruke gammel vei igjen. Avklar separat ordrene som allerede er opprettet i det nye ERP-systemet. Å skifte mellomleddet tilbake overfører eller sletter dem ikke automatisk. Kontroller også hvem som overvåker og vedlikeholder mellomleddet; det må ikke ubemerket bli en flaskehals.
Den gamle forbindelsen fjernes først når åpne tilbakemeldinger og resterende avhengigheter er avklart. Avslutningen avhenger dermed av de berørte handlingene og ikke bare datoen for den første vellykkede nye forespørselen.
Kilder
Les videre
Alle artikler





API-er og integrasjon med ASES
ERP, CRM og nettbutikk ryddig koblet sammen

