Vad är ett verksamhetsnära system?

I nästan varje verksamhet finns det ett flöde som ingen har hittat ett bra system för. Offerter som rör sig via e-post och ett kalkylark för att CRM:et inte hanterar de undantag som egentligen är standard i er bransch. Kvalitetskontroller som dokumenteras 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. Orderhantering som sker utanför affärssystemet för att en affärsregel som formats under tio år inte ryms i standardkonfigurationen.

De här lösningarna lever kvar för att de fyller ett behov. Problemet är att de är bräckliga — kunskapen om hur de fungerar sitter hos en eller två personer, de integrerar inte med resten av systemmiljön och de är svåra att ändra när verksamheten förändras.

Verksamhetsnära systemEtt system byggt specifikt för en organisations processer och affärslogik — i stället för att organisationen anpassar sina processer efter ett standardsystem. Det är ägt av er, kan förändras i er takt och integrerar med er befintliga systemmiljö. är ett system som speglar hur er verksamhet faktiskt fungerar, med era regler, era undantag och er logik inbyggd. Det kan vara ett orderhanteringssystem för en specifik branschprocess, ett kvalitetssystem för en tillverkningslinje, ett uppföljningsverktyg för ett flöde som är unikt för er affär, eller något helt annat. Det gemensamma är att det är byggt utifrån er process — inte en process ni anpassat er efter.

Standardsystem är ofta bra. De täcker vanliga processer väl, är underhållna av leverantören och har en etablerad användargrupp. Problemet uppstår när er process avviker tillräckligt mycket för att kompromisserna ska börja kosta — i tid, i manuella steg, i personberoende eller i möjligheter ni inte kan ta.

Det finns tre mönster som återkommer hos de verksamheter vi pratar med när frågan om egenutvecklat system dyker upp.

Det första är processspecificitet: er process har regler, undantag och flöden 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. Det är inte att ni gör det fel — det är att processen är specifik för er verksamhet och er affär.

Det andra är kostnaden för "nästan rätt". Kringlösningarna syns sällan som en rad i budgeten. De syns i controller-funktionens tid, i onboarding-perioden för nya medarbetare, i de frågor som går till den enda personen som kan systemet tillräckligt bra för att hantera undantagen. Den kostnaden är verklig även om den är osynlig.

Det tredje är förändringstakten. Om er verksamhet förändras snabbare än en leverantörs releaseplan, eller om ni behöver styra exakt vad som ändras och när, är ett standardsystem en broms. Att vänta på en patch eller en roadmap-feature för att kunna leverera till era kunder är en kostnad som sällan räknas in i kalkylerna för systemvalet.

Det som avgör om ett verksamhetsnära system levererar värde på lång sikt har sällan med tekniken att göra. Tekniken för att bygga och drifta ett modernt system i Azure är välbeprövad. Det som avgör är hur väl systemet speglar er verksamhets logik — och hur den logiken underhålls och ägs över tid.

Det praktiska innebär att processen behöver vara förstått 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? De frågorna är svårare att ändra i efterhand än tekniska val, och de avgör om systemet fungerar i driften snarare än bara i en demo.

Integration är en del av det — ett system som inte pratar med er befintliga systemmiljö skapar ett nytt informationssilot snarare än att lösa ett. Och förvaltning är en annan: systemet ni bygger idag ska fungera om tre år, fem år, tio år. Det kräver ett planerat ägarskap, inte ett ad-hoc-beroende av den person som råkade bygga det.

Artiklarna nedan täcker de delar 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. Frågan om äga eller hyra. Integrationens roll. Förvaltning och långsiktigt ägarskap.

Gaia börjar med att förstå processen — inte med att presentera en teknisk lösning. Vi behöver veta var flödet börjar och slutar, vilka regler och undantag som styr det, var personberoendena sitter och hur systemet behöver hänga ihop med resten av er IT-miljö. Det arbetet avgör om ett egenutvecklat system är rätt väg överhuvudtaget, och i så fall vad som ska byggas.

Tekniken vi bygger med är Microsofts: Azure, .NET, React och Power Platform. Men det är förståelsen av er verksamhet som bestämmer vad vi sätter ihop av det.