Systemudvikling og integrationer: hvornår bør virksomheden bygge noget selv?

Start med én arbejdsgang

Vælg en opgave, som både forekommer ofte og har et tydeligt slutpunkt. Beskriv hvem der gør hvad, hvilke oplysninger der bruges, og hvor informationen kommer fra. Notér også ventetid og manuelle kontroller. En formular på websitet er kun starten, hvis en medarbejder stadig skal kopiere det hele videre, før nogen kan svare kunden.

Tæl forekomsten i en repræsentativ periode. Mål hvor lang tid de forskellige trin tager, og notér hvilke fejl der kræver ekstra arbejde. Regn ikke al tid som en mulig besparelse; nogle vurderinger skal stadig foretages af et menneske.

Tag undtagelserne med: en eksisterende kunde sender en ny forespørgsel, et felt mangler, eller en ordre ændres efter registrering. Disse situationer afgør ofte, hvor enkel løsningen reelt kan blive.

Vælg mellem konfigurering, integration og udvikling

Undersøg først, om de systemer, I allerede betaler for, kan løse opgaven. Vurder derefter, om en færdig kobling eller en afgrænset integration er tilstrækkelig. Egen systemudvikling er mest interessant, når en vigtig arbejdsgang ikke dækkes på en fornuftig måde af alternativerne.

Bed om en demonstration af den samme opgave i hvert alternativ. En funktionsliste kan skjule forskellen mellem, at noget er muligt, og at medarbejderne faktisk kan få det gjort uden omveje. Vurder også, hvordan løsningen kan ændres, og hvem der skal holde den kørende.

Eksempel: fra kontaktformular til CRM

Forestil dig en virksomhed, der modtager tilbudsforespørgsler via websitet. En integration kan overføre nødvendige oplysninger til CRM, oprette en salgsopgave og varsle det rigtige team. Dette er et illustrerende løsningsforslag, ikke en beskrivelse af en bestemt kundeleverance.

Start med at fastlægge, hvilket system der ejer hvilke data. Kontaktoplysningerne kan komme fra formularen, mens kundestatus skal vedligeholdes i CRM. En ny indsendelse bør ikke overskrive sælgerens vurdering, medmindre det er en bevidst regel.

Skellet mellem kontakt og forespørgsel er vigtigt. Den samme person kan sende to reelle henvendelser om forskellige behov. En løsning, der fjerner alt med samme e-mailadresse som duplikat, kan derfor miste information.

Bestil, hvad der skal ske, når noget fejler

En integration skal kunne håndtere, at et modtagersystem ikke svarer, at adgange udløber, eller at en besked bliver sendt flere gange. Aftal, hvilke fejl der skal prøves igen, hvor de vises, og hvem der varsles. En e-mail, der bare siger «fejl», giver et dårligt grundlag for opfølgning.

AWS beskriver idempotens som et princip, der lader en gentaget forespørgsel få samme effekt som én behandling. For et CRM-flow kan et unikt indsendelses-ID bruges til at undgå, at et nyt leveringsforsøg opretter den samme salgsopgave flere gange.

Stripe er et konkret eksempel på en leverandør, der dokumenterer både duplikerede webhook-hændelser og at hændelser ikke garanteres leveret i rækkefølge. Pointen ved indkøb er at bede udvikleren kontrollere den faktiske dokumentation for hvert system, I skal koble til.

Lav en lille første leverance med tydelig test

Afgræns den første version til ét flow, der giver værdi i sig selv. I kan for eksempel overføre forespørgsler og oprette opgaver, før I bygger automatisk tilbudsproduktion. Det gør det lettere at kontrollere datakvaliteten og få feedback fra dem, der skal bruge systemet.

Test med aftalte testdata, og dokumentér det forventede resultat. En vellykket normalindsendelse er kun ét scenarie. Kontrollér også gentaget levering, manglende information, midlertidig fejl og en eksisterende kontakt med et nyt behov.

Før I øger brugen, bør nogen kunne finde en konkret test frem fra start til slut. Brug en reference, der kan spores mellem systemerne, og undgå at gemme flere personoplysninger i logs, end I har brug for for at forstå fejlen.

• Normal flow opretter de rigtige oplysninger hos den rigtige modtager.
• Gentagen levering af samme hændelse giver ikke en ekstra opgave.
• En fejl bliver synlig og får en navngiven ansvarlig.
• En ny forespørgsel fra en eksisterende kontakt bliver bevaret.
• Adgange og dokumentation kan overdrages til virksomheden.

Afklar, hvem der ejer løsningen bagefter

Et projekt er ikke færdigplanlagt, før drift og ændringer har en ejer. Afklar, hvor løsningen kører, hvem der betaler for nødvendige tjenester, hvem der kan ændre adgange, og hvordan I får hjælp, hvis data holder op med at flyde.

Bed også om en enkel oversigt over systemer, koblinger og forudsætninger. Når et CRM skifter et feltnavn, eller en leverandør ændrer en grænseflade, bør det være muligt at finde ud af, hvad der kan blive påvirket. God dokumentation gør videreudvikling lettere at bestille og reducerer afhængigheden af én person.