Skräddarsydda system: när det lönar sig att bygga eget och när standard räcker

Vad betyder skräddarsytt egentligen?

Spannet är stort. I ena änden finns ett helt eget verksamhetssystem som ersätter flera standardprodukter. I andra änden ett litet verktyg som gör en enda sak väl, till exempel räknar fram en offert enligt era regler. Det mesta som mindre företag behöver ligger närmare den andra änden.

Ett skräddarsytt system har nästan alltid tre delar. Ett gränssnitt där människor arbetar, alltså formulär, listor och knappar. En databas, det vill säga platsen där informationen sparas på ett ordnat sätt. Och regler: vem får göra vad, i vilken ordning saker händer och vad som räknas som klart. Det är reglerna som gör systemet till ert.

En vanlig fråga till mig som konsult för verksamhetssystem är just den här: skräddarsytt system eller standardsystem? Det ärliga svaret är oftast en blandning. Standardsystemen sköter det allmänna, och något litet och eget fyller luckan mellan dem.

När standardsystemet vinner

Bokföring, lön, e-post, dokumentlagring och vanlig kundhantering är lösta problem. Fortnox, Visma, Microsoft 365 och HubSpot används av väldigt många företag och uppdateras utan att ni behöver göra något. Att bygga eget där är nästan alltid ett dyrt sätt att få något sämre.

Standard vinner också när ert arbetssätt är mindre unikt än det känns. Många speciella behov visar sig vara en inställning eller ett tillägg. Ett eget system ska fylla en lucka, inte ersätta något som fungerar.

Standardsystem, low-code eller eget

Det finns ett mellanläge. Low-code betyder verktyg där man bygger appar och databaser genom att klicka ihop dem i stället för att skriva kod, till exempel Airtable eller Microsoft Power Apps. Det passar när flödet är tydligt och användarna interna. Jag har skrivit mer om det på sidan om Airtable, Zapier och n8n och i texten om att bygga interna verktyg i Airtable.

Ett grovt sätt att välja: standardsystem när behovet är vanligt, low-code när behovet är ert men enkelt, och ett eget byggt system när reglerna är komplicerade, när kunder eller partner ska logga in, eller när low-code-verktyget börjar kräva fler undantag än det sparar.

Vad som driver kostnaden över tid

Bygget är sällan den största kostnaden. Förvaltning: någon måste rätta fel, uppdatera och ändra när verksamheten ändras. Säkerhet: inloggning och behörigheter blir ert ansvar på ett annat sätt än i en köpt tjänst. Ägarskap av koden: se till att avtalet säger att ni äger koden och har tillgång till den. Dokumentation: en kort beskrivning av vad systemet gör och hur det återställs är värd mer än den kostar. Beroende: om bara en person eller en leverantör förstår systemet har ni köpt en risk tillsammans med verktyget.

Inget av det här är skäl att avstå, men skäl att räkna med det från början. Vill du först se hur era system hänger ihop kan verktyget för systemlandskap hjälpa.

Ett exempel från mitt eget arbete

I redigeringsverktyget jag har byggt för mitt eget innehåll fanns en lättmissad risk. Två personer kunde öppna samma post, göra varsin ändring och spara med några sekunders mellanrum. Båda fick beskedet att det var sparat, men den senare sparningen skrev tyst över den första. En ändring försvann utan att någon märkte det.

Jag ändrade det så att varje sparning talar om vilken version den utgick från. Om någon annan hunnit spara en nyare version under tiden stoppas den gamla sparningen som en konflikt i stället för att skriva över. Personen får då läsa in den senaste versionen och göra om sin ändring medvetet.

Lärdomen gäller alla skräddarsydda system. Det räcker inte att de fungerar när allt går som planerat. Det är det som händer vid sidan av den raka vägen som avgör om man kan lita på dem.