Når man begynder at arbejde med integrationer så støder man på flere forskellige begreber som alle holder et løfte om at kunne integrere en platform med andre systemer på. I denne artikel vil jeg forsøge at tegne et billede af disse begreber, således du som læser får mulighed for at navigere i disse begreber og vurdere om de integrationer du ønsker også kan lade sig gøre. Hvis du er i tvivl kan du altid kontakte os, for en hjælpende hånd. Samtidig vil denne artikel også give eksempler på hvilke overvejelser man skal gøre sig når man begynder at bygge integrationer.
Indholdsfortegnelse
Introduktion
Design af integrationer
Hvad er webhooks?
Hvad er et API?
Noget om kompleksitet
Introduktion
Når du står i en situation, hvor du skal vurdere på om det er den ene eller anden teknologi du skal bruge til at integrere med, så har du allerede gjort dig nogle tanker omkring hvad det er du vil opnå. Her er det en god ide at få dette defineret og beskrevet, således du altid har dette at holde op imod den teknologi du møder senere hen. Dette er vigtigt fordi, når man sidder og overvejer hvilken værdi man vil tilføje sin organisation, så tænker man på virksomheden, på hvordan integrationer kan understøtte virksomhedens strategi og hvordan man vil kunne vokse som virksomhed ved disse integrationer. Vi ser alt for ofte det “modsatte”, nemlig hvor man starter fra et teknisk punkt og kigger på hvad man kan med de systemer man har og med de tekniske kapaciteter (læs: medarbejdere) som er tilgængelige.
Dette er en farlig situation, man er allerede begrænset af alt fra teknologi, systemer og medarbejdere. Dette er en situation, hvor man allerede er ved at give køb på de mange muligheder som er tilgængelige. I stedet for at definere hvad man vil have og har behov for, så er man begrænset til “hvad kan jeg få?”. Det betyder at man ikke er i kontrol, men lader systemer, teknologier og andre personer styre, hvad der kan lade sig gøre.
Nogle gange hører vi at “vores regnskabssystem kan ikke give os de data” – vores svar er altid noget i retning af: “så skift det ud!”. Det er naturligvis nemmere sagt end gjort og det er også en vild provokation og noget som vi har fået mange rullende øjne ud af. Det er godt at blive provokeret på denne måde. Når vi kommer med sådan en provokerende udtalelse, så er det fordi vi netop antager at man har lavet et seriøst arbejde omkring hvordan man vil understøtte virksomhedens strategi ved hjælpe af IT og integrationerne. Vi antager altid at en integrationsopgave bunder i en vigtig værdiskabelse for virksomheden og noget som er en del af strategien og som noget, der navigeres mod. Dette er vigtigt! Ellers ville behovet jo aldrig være opstået. Hvis det er regnskabssystemet eller CRM (eller andre systemer) som står i vejen for virksomhedens ambitioner i fremtiden, jamen så er det eneste naturlige at lave en plan for at udskifte dem med andre som tilgodeser virksomhedens strategi. Vi ved at det ikke sker fra den ene dag, til den anden, men tag konsekvensen og start arbejdet med at skifte det ud.
Design af integrationer
Tilbage er så at begynde at designe, hvordan data flyder rundt mellem systemer, hvilket system ejer data og er der nogle systemer som bestemmer over andre. Dette arbejde er nemmest at lave på en stor whiteboard tavle og det er typisk noget som tager noget tid. Nogle af de emner man bør overveje er:
- Hvilket system ejer noget givet data (fx. hvilket system ejer kundedata, er det CRM eller regnskabssystemet)?
- Skal data synkroniseres i een retning eller i to retninger (fx. fra regnskabssystem til CRM eller også den anden vej)?
- Hvilket system “vinder”, hvis der sker to opdateringer oven i hinanden?
Flytter man data eller hændelser (eller begge dele)?
Det er her det begynder at blive en smule teknisk. Når man når til dette punkt, så skal man afgøre om man flytter data rundt, eller om man sender hændelserne også. Det kan måske lyde som to sider af samme sag, så lad mig give et eksempel:
Hvis man flytter ren data fra et regnskabssystem til et CRM system, så vil det svare til at man eksporterer en masse data fra regnskabssystemet og indsætter det ind i CRM systemet. Det betyder at CRM systemet ikke ved _hvorfor_ det får data, og i nogle systemer forbigår dette en masse rutiner som skal tjekke data.
At flytte ren data er typisk ikke det vi ønsker, hvis vi er ved at lave integrationer mellem systemer som skal samarbejde. At flytte ren data er rigtig godt når man skal flytte data ud i et datawarehouse for at lave rapportering (fx. Microsoft Power BI analyser) på data.
Hvis man får en hændelse (en besked) fra et system, så svarer det til at man “bare” får en notifikation om at data er ændret: “Jeg har oprettet en ny kunde” – kunne være en hændelse som fx. CRM systemet sender til regnskabssystemet. I dette tilfælde ved vi _hvorfor_ vi skal integrere (fordi der er kommet en _ny_ kunde i systemet). Så ved vi at når vi skal have det ind i regnskabssystemet, så skal der laves forskellige tjeks på alt fra CVR nummer til momszoner osv. Disse forretningsregler er vigtige for at vi kan lave meningsfyldte integrationer. Disse hændelser kommer typisk i to varianter: med data eller uden data. Hvis de er uden data betyder det at de notificerer om at “en ny kunde er oprettet, det nye id er 17” og så må regnskabssystemet ellers gå tilbage og hente data for den nye kunde og integrere data. Hvis det er med data, så kommer data med notifikationen: “en ny kunde er oprettet, og her er der data”. I det sidste scenarie har vi nu data og kan indsætte det i fx. regnskabssystemet, her har vi sparet en arbejdsgang med at hente data fra kildesystemet.
Hvad er Webhooks?
I forbindelse med integrationer støder vi på begrebet “webhooks”. For mange lyder beskrivelserne vi støder på, umiddelbart til at dette vil løse alle problemer med integrationer og at det er nemt at gå til og lave integrationer. Det er en smule mere nuanceret.
Webhooks er en måde hvorpå et system kan udsende “notifikationer” (som beskrevet tidligere) til en modtager. En webhook oprettes inde i et system, fx. inde i e-conomic regnskabssystemet og så kan den notificere andre systemer om en hændelse. Dette er en meget anvendt måde at integrere på fra et system til et andet, stort set alle systemer tilbyder en webhook, det er meget populært. Det man lige skal huske på er at en Webhook kun er en-vejs, det vil sige at det kun er en notifikation en system kan sende til andre. Et eksempel på dette kan være at e-conomic regnskabssystemet (eller andre) sender en notifikation når der er bogført en faktura. Det vil sige, at når den regnskabsansvarlige laver og bogfører en faktura i regnskabssystemet, så udsender regnskabssystemet en notifikation til et andet system (grunden til at jeg ikke skriver et bestemt system her, er fordi det kan være et CRM, men det kan også være noget der er designet og udviklet netop til denne integration – det er det mest almindelige). Hvert system har sin egen måde at sende webhooks på, nogle har data med og andre har ikke data med. Som et eksempel her, så sender e-conomic regnskabssystemet (i skrivende stund) kun et fakturanummer med ud, når en faktura bliver bogført. Så må en integration efterfølgende bede om det data, der er brug for for at gennemføre integrationen. Det kan godt virke lidt omstændigt, først får man information om en hændelse, så skal man hente data for så at flytte data til et andet system. Som med alt muligt andet, så er der en mening med galskaben og der er både fordele og ulemper ved at modtage hændelser med/uden data.
Fordelen ved webhooks er at det er nemt at agere på en hændelse i et system, det vil sige at man kan holde sine systemer opdaterede i noget der ligner “live” (realtid). Alternativet er meget værre – hvis man ALTID vil have fx. sit regnskabssystem opdateret med data fra CRM eller fra Webshop, så er man nødt til at spørge fx. hvert minut. Det vil ca. se sådan her ud (man kalder det polling):
“Har du noget nyt data?”, “Har du noget nyt data?”, “Har du noget nyt data?”
Det er ikke optimalt og det tager mange ressurcer at konstant spørge efter data. Derfor vil man mange gange hellere gøre det på den anden måde, modtage en webhook og så selv have noget kode som kan hente data og integrere det. Webhooks er en måde at få leveret data “ud af et system på”.
Ulempen ved Webhooks er at de er en-vejs, det vil sige at man kan ikke spørge en webhook om noget (fx. om data) her skal systemet kunne udstille sine data gennem et API (mere om det senere) og man kan så spørge efter data. En anden ulempe er tilliden til at man har fået alt data. Hvad hvis man mister en webhook – så har man et hul i data. Hvad hvis det system som modtager webhook ikke kan klare belastningen (vores systemer kan klare det hele, de kører på Microsoft Azure – bare rolig). Her skal man nok have en backup plan, i tilfælde af at det sker – måske et tjek engang i døgnet.
Hvad er et API?
Populært sagt kan man sige at et API er en grænseflade for programmører/systemer til at kommunikere med et system. Normalt ved vi godt at det er mennesker som sidder og bruger brugergrænsefladen på et system til at indtaste data, sende fakturaer og træffe beslutninger. Et API er for programmører/systemer hvad brugergrænsefladen er for mennesker. Det er her man mange gange kan udføre de samme handlinger som et menneske kan udføre via brugergrænsefladen: Oprette faktura, oprette kunde, skifte leveringsadresse og meget andet. Det er et API vi bruger til at indsætte data i et system med og spørge om fx. en kunde allerede eksisterer i CRM systemet.
At bruge et API er en lidt “tungere” opgave og her skal der som ofte en programmør til at lave en integration (hos Median har vi allerede lavet en lang række integrationer som kan genbruges til din virksomhed – så starter vi ikke helt forfra). Et API kommer mange gange under flere forskellige navne, nogle gange ser man også forkortelserne HTTP og REST og det er alt sammen noget som forklarer en programmør hvordan man skal snakke sammen med det API.
Fordi et API giver lov til at indsætte data i et system er det ofte beskyttet med en eller form for sikkerhed for ikke at alle bare kan sende data ind til dit regnskabssystem.
Fordelen ved at bruge et API er at man har bedre adgang til data, både at læse og skrive data til systemet. Det betyder at man kan lave nogle ret omfattende integrationer som indeholder meget forretningslogik. Det er her man virkelig kan skabe værdi for virksomhederne.
Ulempen ved at bruge et API er at man skal bruge en programmør (ved ikke om det er en ulempe) ellers skal man købe standardløsninger som dem vi tilbyder her hos Median. Ulempen er også at man ikke får besked omkring hændelser, man kan læse og skrive data, men man ved ikke noget omkring hændelser i systemet. Det betyder at man må reagere på webhooks og så kalde et API eller man må lave noget med faste intervaller, fx. en gang i døgnet.
Noget om kompleksistet
Når data skal integreres mellem to systemer er det ret enkelt og man kan modtage en webhook og så indsætte data via et API i et andet system. Men hvad nu hvis der er mere end to systemer?
Hvis vi leger med at øge kompleksiteten en smule og opstiller et scenarie, hvor en kunde ringer ind til vores regnskabsafdeling og siger til dem at han er flyttet til en ny adresse. Det er en ret normal ting, og noget som sker hele tiden. Men hvad med vores systemer? Medarbejderen i regnskabsafdelingen ændrer adressen i regnskabssystemet, så bliver fakturaer sendt til den rigtige adresse. Så langt så godt. Hvad med vores CRM system – der står stadig den gamle adresse, så når vores kørende sælger lige er i området og svinger ind til et kort møde, har han så den rigtige adresse? Når kunden så bestiller en kasse tennisbolde (eller noget andet) fra vores webshop, så vil vi også gerne kunne sende dem til den rigtige adresse.
Betyder ovenstående scenarie så at medarbejderen i regnskabsafdelingen skal ind i alle systemer og rette i adressen – ja – hvis ikke vi har integreret systemerne (ikke alle medarbejdere i regnskabsafdelingen ved hvor mange systemer der findes på tværs af virksomheden).
Kompleksiteten stiger voldsomt, hvis ikke vi har en eller anden form for dokumentation af alle de integrationer vi opbygger. Hvis ikke denne dokumentation findes og vi erstatter et CRM med et nyt CRM, så har en en masse, komplekse problemer. En lang del af disse problemer kan løses af RPA og små robotter – og det er et rigtigt godt sted at starte. Uanset om der er en programmør i spil eller om det er med RPA (som ofte også laves af en programmør) så er dokumentation et must. Uden dokumentation stifter man så meget teknisk gæld at man på et tidspunkt er nødt til at smide håndklædet i ringen og starte helt forfra med systemer og integrationer.
Trackbacks/Pingbacks