Gå til innholdet

ERP-bytte: skill tilknyttede dataflyter trinnvis

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

Tobias Krüger2 min lesetid
Oransje ERP-kontaktmodul med databasesymbol ved siden av en metallkontakt.

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

Skrevet av

  • Tobias KrügerRedaktør for systemintegrasjonTobias Krüger jobber hos ASES med samspillet mellom ulike programvaresystemer. I artiklene sine forklarer han hvordan ERP, CRM og nettbutikker kobles sammen, og hvordan man håndterer feil i datautvekslingen.

Følg ASES

Les videre

Alle artikler

API-er og integrasjon med ASES

ERP, CRM og nettbutikk ryddig koblet sammen