5 typiske integrationsfejl

Integrationsopgaver kan være intimiderende for både os som leverandør og vores kunder. Vi udviser altid stor respekt overfor integrationsopgaver, da de ofte viser sig mere komplicerede end først antaget.

Vi har mange tusinde timers erfaring med både store og små integrationsopgaver. Igennem de mange opgaver har vi lært en masse om, hvad der fungerer, og hvad der ikke fungerer.

Nedenfor har vi opsummeret de 5 typiske faldgruber, når dit website eller shop skal integreres:

  1. Integrationsopgaven bliver alene behandlet som en udvikleropgave

  2. Forretningen bliver fanget mellem forskellige leverandører

  3. Data i test-miljøet er anderledes end i produktionsmiljøet

  4. Estimat og tidsplan er optimistisk

  5. Overvågning bliver en eftertanke


integration1 - Integrationsopgaven bliver alene behandlet som en udvikleropgave

Den klassiske integrationsopgave er at udstille en forretnings produkter på en webshop og give kunderne muligheden for at bestille produkterne. Produkterne kommer fra et ERP system og skal vises på websitet. På overfladen en simpel opgave, men ofte oplever vi, at opgaven ikke kan løses uden forretningsmæssig viden - og i nogle tilfælde skal der tages forretningsmæssige beslutninger.

Et eksempel kan fx være følgende data fra et ERP system:

Product name: 22 mm nøgle

Product description 1: Denne 22 mm nøgle bliver brugt til at skrue hvad som helst fra hinanden

Product description 2: Når noget er i stykker, så brug denne nøgle til at samle det

Ovenstående data skal "oversættes" til websitet, hvor følgende felter findes:

Product title

Short description

Long description

Er short description så description 1 eller description 2? Det er faktisk umuligt at vide, uden at have kendskab til forretningen. Hvis udvikleren gætter forkert, så bliver det rapporteret som en fejl senere i udviklingsprocessen. Og jo senere i udviklingsprocessen fejlen bliver opdaget, jo dyrere er det at rette.

Nu er dette et meget banalt eksempel, der næppe har de store konsekvenser eller er specielt svært at lave om. Men vi oplever talrige eksempler på felter, der kan misforstås eller mangler. De data, som forretningen kender fra deres verden, kan se helt anderledes ud, når dataene bliver hentet fra et ERP system.

I disse tilfælde bliver det en større detektivopgave. Og det er en opgave, der kræver samarbejder mellem udvikleren og de forretningsansvarlige. Og ofte faktisk én part mere.

integrationssamarbejde2 - Forretningen bliver fanget mellem forskellige leverandører

Koordinering af ressourcer fra flere forskellige organisationer kræver sit, og vi oplever udfordringer, når både viden og leverancer skal koordineres.

Leverandøren af ERP systemet sidder ofte inde med viden, som enten er helt nødvendig, eller i det mindste gør udviklingen for os integratorer lettere. Hvis der ikke er et godt samarbejde mellem ERP leverandør, forretningen og os som udviklere, så bliver resultatet tilfældigt. Og oplevelsen hos virksomheden er, at der hele tiden er småfejl, og at budgettet skrider.

Vi oplever typisk, at vi som udviklere af websitet er afhængige af, at en ERP leverandør laver en tilretning eller leverer et dataudtræk. Det er ikke altid det er muligt, at leverandøren har tid til at leverer deres del af arbejdet, således at det passer ind i tidsplanen for websitet.

integrationstest3 - Data i test-miljøet er anderledes end i produktionsmiljøet

Det er god skik at arbejde op imod et test-miljø under udviklingen af et integrationssetup. Her er det en fordel ikke at skulle bekymre sig om at ødelægge eller eksponere rigtige data, men det kan være en ulempe at arbejde med testdata. Det helt ekstreme test-eksempel kunne se sådan ud:

Product name: test

Product description 1: test

Product description 2: test 

Den udvikler og tester, der skal arbejde med sådanne data, har svært ved at verificere at data overføres korrekt.

Et andet problem med testdata er, at man kan risikere at arbejde på en delmængde af det totale datasæt. Det kan fx give sig udslag i, at performance-problemer først viser sig sent i udviklingsforløbet, eller at nogle produkter simpelthen ikke importeres korrekt.

Det er sådan med software, at det ikke er bedre, end den test, der har været. Og hvis import-koden testes op imod et sæt af data, der ikke er repræsentativt for det endelig datasæt, så stiger risikoen for fejl.

integrationsestimat4 - Estimat og tidsplan er for optimistisk

Typisk er estimatet for selve arbejdet med at skrive kode egentlig realistisk, mens opgaverne med at samarbejde omkring at forstå data og koordinere mellem forretningen og forskellige leverandører er undervurderet.

Estimatet baserer sig ofte på en antagelse om, at datakvaliteten er god, og at kunden og/eller tredjepart overholder deres tidsplan med at leverer disse data. I praksis er der dog ofte et eller andet, der skrider, og så spreder forsinkelsen sig som ringe i vandet.

Bliver et felt i produkttabellen ikke udstillet gennem API'et? Eller understøtter ERP-systemet og websitet ikke samme variant/format? Det er eksempler på ting, vi først finder ud af, når vi har haft fingrene helt nede i detaljen. Hvis ikke både tidsplanen og estimatet tager højde for at vi lærer undervejs, så bliver integrationsprocessen en dårlig oplevelse.

integrationsovervågning5 - Overvågningen bliver en eftertanke

En import af produkter mellem et ERP system og webshop kører typisk en eller flere gange i døgnet. I de fleste tilfælde er det en automatiseret proces - uden at nogle mennesker er inde over. Så hvad sker der, når der sker fejl?

Typisk er koden skrevet, så den er relativt robust over for de typiske fejl, såsom netværksproblemer og manglende data. Men den hyppigste fejl er, at udviklerne og virksomheden ikke aftaler, hvem der er ansvarlig for at overvåge systemet - særligt de første 3 måneder efter projektet af afsluttet. Udvikleren er videre til det næste projekt, og kunden har vænnet sig til, at det hele bare virker. Hvis ERP systemet så bliver opdateret eller en anden systemmæssig opdatering har en uheldig sideeffekt, går det ud over integrationen.

Samarbejdet er afgørende

Jo mere alle involverede i processen er opmærksomme på de farer, der er beskrevet her, jo bedre integrationsprojekt kommer der ud af det. Det er nødvendigt med en kollaborativ process, da alle parter skal bidrage med deres viden, før projektet bliver en success. Vælg derfor dine partnere med omhu og vær sikker på, de har erfaring med typen af integration.

Hvis ikke du er tilmeldt nyhedsbrevet, så gør det nu, så får du besked når opfølgningen til denne artikel bliver publiceret. Her giver vi 5 tips til et bedre integrationsprojekt.