Vad är ett verksamhetsnära system?

Ett verksamhetsnära system är ett verksamhetssystem som byggs för en organisations egna processer och affärslogik, i stället för att organisationen anpassar sig efter ett standardsystem. Verksamheten äger systemet och kan ändra det i den takt den behöver, och det hänger ihop med de system som redan finns, till exempel affärs- och ekonomisystemet.

Behovet brukar börja med ett flöde som ingen har hittat ett bra system för, och sådana finns i nästan varje verksamhet. Offerterna går kanske via e-post och ett kalkylark, eftersom CRM:et inte hanterar de undantag som egentligen är standard i er bransch. På andra ställen dokumenteras kvalitetskontroller i en separat fil, för att det egentliga systemet kräver tio klick per rad och ändå inte sparar exakt det ni behöver. Eller så sköts orderhanteringen utanför affärssystemet, eftersom en affärsregel som formats under tio år inte ryms i standardkonfigurationen.

Sådana lösningar lever kvar för att de fyller ett behov, men de är bräckliga. Kunskapen om hur de fungerar sitter ofta hos en eller två personer, och eftersom de inte hänger ihop med resten av systemmiljön blir de svåra att ändra när verksamheten förändras.

Verksamhetsnära systemEtt system som byggs för en organisations egna processer och affärslogik, så att verksamheten slipper anpassa sig efter ett standardsystem. Ni äger det, kan ändra det i er egen takt och koppla det till systemen ni redan har. speglar alltså hur verksamheten faktiskt fungerar, med de regler och undantag som gäller just hos er inbyggda. I praktiken kan det vara ett orderhanteringssystem för en specifik branschprocess, ett kvalitetssystem för en tillverkningslinje eller ett uppföljningssystem för ett flöde som är unikt för er affär. Gemensamt för dem är att systemet byggs utifrån processen som den ser ut i dag.

Standardsystem är ofta bra, och de täcker vanliga processer väl. Leverantören underhåller dem och det finns en etablerad användargrupp. Det blir ett problem först när er process avviker så mycket att kompromisserna börjar kosta, oftast i form av manuella steg och beroende av enskilda personer.

När frågan om ett egenutvecklat system dyker upp hos de verksamheter vi pratar med, återkommer tre mönster. Det första är att processen har regler och undantag som inget standardsystem stöder bra. Ni kan konfigurera systemet på olika sätt och ändå hamna i lägen som kräver kringlösningar, och det beror inte på att ni gör fel utan på att processen hör till just er affär.

Det andra är kostnaden för "nästan rätt". Kringlösningarna syns sällan som en rad i budgeten, men de tar tid för controllerfunktionen och gör att nya medarbetare behöver längre tid för att komma in i jobbet. Dessutom går frågorna om undantagen till den enda person som kan systemet tillräckligt bra, och den tiden räknas sällan in någonstans.

Det tredje är förändringstakten. Om verksamheten förändras snabbare än leverantörens releaseplan, eller om ni behöver styra exakt vad som ändras och när, blir standardsystemet en broms. Varje gång ni väntar på en uppdatering från leverantören för att kunna leverera något till era kunder kostar det, och den kostnaden kommer sällan med i kalkylen när systemet väljs.

Om ett verksamhetsnära system gör nytta på lång sikt avgörs sällan av tekniken, eftersom tekniken för att bygga och driva ett modernt system i Azure är väl beprövad. Det som avgör är hur väl systemet speglar logiken i verksamheten, och hur den logiken underhålls och ägs över tid.

I praktiken betyder det att processen behöver vara utredd, tillsammans med dem som arbetar i den, innan koden skrivs. Vilka regler styr flödet? Var finns undantagen? Vem fattar beslut om vad? Hur ser gränsytan mot era andra system ut? Svaren på de frågorna är svårare att ändra i efterhand än tekniska val, och de avgör om systemet fungerar i driften och inte bara i en demo.

Integrationen hör också dit, för ett system som inte pratar med den befintliga systemmiljön skapar en ny informationssilo i stället för att ta bort en. Sedan är det förvaltningen. Systemet ni bygger i dag ska fungera om tio år, och det kräver ett planerat ägarskap i stället för ett beroende av den person som råkade bygga det.

Artiklarna nedan går igenom det som avgör om ett verksamhetsnära system är rätt väg för er och vad som krävs för att det ska hålla. De tar upp frågan om att äga eller hyra och hur integrationen mot andra system fungerar, och sist hur förvaltning och ägarskap ordnas på lång sikt.

Arbetet börjar i ert flöde, långt innan någon pratar om teknik. Tillsammans går vi igenom var flödet börjar och slutar, vilka regler och undantag som styr det och var personberoendena sitter. Sedan reder vi ut hur systemet behöver hänga ihop med resten av IT-miljön.

Själva bygget gör vi med Microsofts teknik, som Azure, .NET, React och Power Platform, men vad som sätts ihop av den bestäms av hur er process ser ut. Därför är Systemskissen första steget. Efter tre till fyra veckor vet ni om ett egenutvecklat system är rätt väg över huvud taget, och i så fall vad som ska byggas.