Systemutveckling och integrationer: när bör företaget bygga något eget?

Börja med ett arbetsflöde

Välj en uppgift som både förekommer ofta och har en tydlig slutpunkt. Beskriv vem som gör vad, vilka uppgifter som används och var informationen kommer ifrån. Notera också väntetid och manuella kontroller. Ett formulär på webbplatsen är bara starten om en anställd fortfarande måste kopiera allt vidare innan någon kan svara kunden.

Räkna förekomsten under en representativ period. Mät hur lång tid de olika stegen tar och notera vilka fel som kräver extra arbete. Räkna inte all tid som en möjlig besparing; vissa bedömningar måste fortfarande göras av en människa.

Ta med undantagen: en befintlig kund skickar en ny förfrågan, ett fält saknas eller en order ändras efter registrering. De här situationerna avgör ofta hur enkel lösningen faktiskt kan bli.

Välj mellan konfigurering, integration och utveckling

Undersök först om systemen ni redan betalar för kan lösa uppgiften. Bedöm därefter om en färdig koppling eller en avgränsad integration är tillräcklig. Egen systemutveckling är mest intressant när ett viktigt arbetsflöde inte täcks på ett rimligt sätt av alternativen.

Be om en demonstration av samma uppgift i varje alternativ. En funktionslista kan dölja skillnaden mellan att något är möjligt och att medarbetarna faktiskt kan få det gjort utan omvägar. Bedöm också hur lösningen kan ändras och vem som ska hålla den i gång.

Exempel: från kontaktformulär till CRM

Tänk dig ett företag som tar emot offertförfrågningar via webbplatsen. En integration kan överföra nödvändiga uppgifter till CRM, skapa en säljuppgift och avisera rätt team. Det här är ett illustrativt lösningsförslag, inte en beskrivning av en specifik kundleverans.

Börja med att bestämma vilket system som äger vilka data. Kontaktinformationen kan komma från formuläret, medan kundstatus ska underhållas i CRM. En ny inskickning bör inte skriva över säljarens bedömning utan att det finns en medveten regel för det.

Skillnaden mellan kontakt och förfrågan är viktig. Samma person kan skicka två verkliga förfrågningar om olika behov. En lösning som tar bort allt med samma e-postadress som duplikat kan därför förlora information.

Bestäm vad som ska hända när något går fel

En integration måste kunna hantera att ett mottagande system inte svarar, att behörigheter löper ut eller att ett meddelande skickas flera gånger. Kom överens om vilka fel som ska försöka igen, var de visas och vem som aviseringar går till. Ett e-postmeddelande som bara säger «fel» ger dåligt underlag för uppföljning.

AWS beskriver idempotens som en princip som gör att en upprepad förfrågan får samma effekt som en enda behandling. För ett CRM-flöde kan ett unikt inskicknings-ID användas för att undvika att ett nytt leveransförsök skapar samma säljuppgift flera gånger.

Stripe är ett konkret exempel på en leverantör som dokumenterar både duplicerade webhook-händelser och att händelser inte garanteras levereras i ordning. Poängen vid inköp är att be utvecklaren kontrollera den faktiska dokumentationen för varje system ni ska koppla till.

Gör en liten första leverans med tydligt test

Avgränsa den första versionen till ett flöde som ger värde i sig självt. Ni kan till exempel överföra förfrågningar och skapa uppgifter innan ni bygger automatisk offertproduktion. Det gör det lättare att kontrollera datakvaliteten och få återkoppling från dem som ska använda systemet.

Testa med avtalade testdata och dokumentera förväntat resultat. En lyckad normalinskickning är bara ett scenario. Kontrollera också upprepad leverans, saknad information, tillfälligt fel och en befintlig kontakt med ett nytt behov.

Innan ni ökar användningen bör någon kunna hitta tillbaka till ett konkret test från början till slut. Använd en referens som kan spåras mellan systemen och undvik att lagra mer personinformation i loggar än ni behöver för att förstå felet.

• Ett normalt flöde skapar rätt information hos rätt mottagare.
• Upprepad leverans av samma händelse skapar inte en extra uppgift.
• Ett fel blir synligt och har en namngiven ansvarig.
• En ny förfrågan från en befintlig kontakt bevaras.
• Behörigheter och dokumentation kan överlämnas till företaget.

Klargör vem som äger lösningen efteråt

Ett projekt är inte färdigplanerat förrän drift och ändringar har en ägare. Klargör var lösningen körs, vem som betalar för nödvändiga tjänster, vem som kan ändra behörigheter och hur ni får hjälp om data slutar flöda.

Be också om en enkel översikt över system, kopplingar och förutsättningar. När ett CRM byter ett fältnamn eller en leverantör ändrar ett gränssnitt bör det vara möjligt att ta reda på vad som kan påverkas. Bra dokumentation gör vidareutveckling lättare att beställa och minskar beroendet av en person.