Dine systemer fungerer. De taler bare ikke med hinanden
Hvert værktøj, du har købt, løser sit problem godt. Problemet er mellemrummet mellem dem, som ingen har solgt til nogen, og som endte hos en person med to faner åbne.
- Fakturering
- Webshop
- Regneark
Én registrering
Det får du
Forbindelser mellem de værktøjer, du allerede bruger
Hver oplysning skrives én gang og spreder sig, uden at nogen af værktøjerne skiftes ud.
En fastlagt hovedkilde
For hver type oplysning er det besluttet og dokumenteret, hvilket system der bestemmer.
Log over alt, der passerer
Hvad der kom ind, hvad der gik ud, hvad der fejlede, og hvad der blev forsøgt igen.
Sådan forløber det
Fastlægge sandhedskilden
Før vi forbinder noget som helst, beslutter vi, hvor hver type oplysning skal ændres, for at ændringen gælder.
Forbinde systemerne
Via hændelser, når det er muligt, og via periodisk synkronisering, når der ikke er hændelser.
Genbehandle og varsle
Når en tjeneste fejler, gemmer integrationen det, der ikke blev leveret, prøver igen og varsler en person, hvis den giver op.
Det, vi ikke lover
- Vi udskifter ikke de værktøjer, du allerede bruger. At skifte CRM er et meget større projekt.
- Uden API er vejen mindre elegant: planlagte eksporter, filer eller direkte læsning af databasen. Det siger vi fra starten.
- Vi forbinder ikke systemer, før det er besluttet, hvad der er hovedkilden til hver oplysning.
Flere detaljer
Hvorfor det sker for alle
Ingen vælger at have isolerede systemer. Det sker ved ophobning. Man køber faktureringen, fordi det var påkrævet, CRM-systemet, fordi salgsteamet voksede, webshoppen, fordi muligheden opstod, og e-mailværktøjet, fordi marketingchefen allerede kendte det. Hver beslutning var rimelig i sig selv.
Det, der aldrig fik en ejer, var mellemrummet mellem dem. Og da det mellemrum skulle udfyldes af nogen, blev det udfyldt af mennesker, i hånden, uden at nogen nogensinde besluttede, at det skulle være sådan.
Det spørgsmål, vi stiller først
Før vi forbinder noget som helst: hvad er sandhedskilden for hver type oplysning?
Hvis en kunde skifter adresse, hvor skal ændringen så foretages for at gælde? Hvis svaret er »det kommer an på« eller »alle steder«, kan integrationen endnu ikke bygges, fordi der ikke er nogen måde at løse konflikter på. At beslutte det er kedeligt, giver diskussion og er forskellen mellem en integration, der holder, og en, der bruger sit liv på at skabe dubletter.
Sådan forbinder vi
Via hændelser, når det er muligt. Når der sker noget i et system, giver det besked, og oplysningerne går videre med det samme. Det er hurtigere og bruger mindre.
Via periodisk synkronisering, når der ikke er hændelser. Hvert femte minut, hver time, én gang om dagen. Man vælger efter den reelle hast, ikke efter det, der ser bedst ud.
Med genbehandling, altid. Tjenester går ned, forbindelser falder ud, et svar tager for lang tid. Alt, hvad vi sætter op, regner med det og prøver igen, med stigende ventetid, og varsler en person, når det giver op.
Det mest almindelige tilfælde: hjemmesiden, der ikke taler med resten
Det eksempel, der dukker oftest op, er også det dyreste i tabte muligheder. Nogen udfylder en formular på hjemmesiden. Det, der burde ske, er: registrering oprettet, øjeblikkelig besked til den, der svarer, opfølgning planlagt og måling.
Det, der plejer at ske, er, at der lander en e-mail i en fælles indbakke. Hvis den rette person ikke ser den, ved ingen andre, at den har eksisteret. Derfor behandler vi hjemmesider og leads som det, der i praksis er et spørgsmål om integration.
Det, vi altid bliver spurgt om
Og hvis et af værktøjerne ikke har en API?
Det sker, især med ældre software. I de tilfælde er der næsten altid en vej: planlagte eksporter, filer i en delt mappe, direkte læsning af databasen. Det er mindre elegant, og det siger vi fra starten, men det løser opgaven.
Hvad sker der, når et af systemerne er nede?
Integrationen gemmer det, den ikke kunne levere, og prøver igen. Det, vi aldrig gør, er at lade oplysninger gå tabt i stilhed: hvis det efter flere forsøg ikke går igennem, får nogen besked, med loggen over det, der ikke blev leveret.
Tvinger det os til at skifte CRM?
Nej. Princippet på dette område er netop det modsatte: at beholde de værktøjer, I allerede betaler for og allerede kan bruge, og løse mellemrummet mellem dem. At skifte CRM er et meget større projekt, og det er sjældent løsningen på data, der ikke cirkulerer.
Fortæl os, hvad der bremser din drift.
Beskriv problemet med dine egne ord. Du behøver ikke at vide, hvad der skal bygges.
- Vi læser henvendelsen.
- Vi svarer inden for en time, pr. e-mail eller telefon, på engelsk eller portugisisk.
- Hvis det giver mening, aftaler vi en samtale.