Verksamhetsnära system
Sluta anpassa er verksamhet efter programvaran
Varje verksamhet har processer som inget standardsystem täcker helt, och kompromisserna kostar arbetstid och manuella steg varje dag. Ett eget verksamhetssystem är ett systemprojekt som börjar med en förstudie och fortsätter genom bygge och produktionssättning till förvaltning i många år.
Er kärnprocess förtjänar bättre än en workaround
Orderhantering, tillverkningsplanering, avvikelserapportering och avtal är flöden som verksamheten står och faller med, men systemstödet har sällan hängt med. Det som borde vara en sammanhållen process ligger utspritt över flera system, med manuella steg och egna kalkylblad däremellan.
Så länge samma personer är kvar fungerar det, men det växer inte med verksamheten, och kunskapen om hur allt hänger ihop sitter ofta hos en eller två av dem.
System byggda för hur ni faktiskt jobbar
Ett sådant uppdrag är ett systemprojekt som ska bära verksamheten i många år. Returpacks affärssystem byggde vi från grunden för drygt 15 år sedan, och i dag går över 1,6 miljarder enheter om året genom det. Med LFV:s flygplaneringssystem har vi arbetat i 25 år, och för Ottobock byggde vi en B2B-handel med kundunikt lager och prissättning.
Varje projekt börjar i flödet, med processen som den faktiskt ser ut i dag, så att ni ser vad systemet ska göra och vad det kostar innan byggfasen börjar. Sedan går bygget hela vägen till produktion, med arkitektur, säkerhet och integration mot de system ni redan har.
Ett system byggt för er process håller så länge någon äger logiken, och därför planerar vi för förvaltningen redan från start.
Varför egenutvecklat
Fem skäl att sluta kompromissa
Standarden gör er till alla andra
Ett standardsystem är byggt för en typisk verksamhet, och det som skiljer er från konkurrenterna är ofta precis det systemet tvingar er att kompromissa bort. Med ett eget system får det försprånget finnas kvar i hur ni arbetar.
"Nästan rätt" har ett pris ni betalar varje dag
Ett system som passar till 80 % låter billigt, men de sista 20 procenten betalar ni för varje dag i dubbelinmatning och Excel-ark vid sidan om. Räkna ihop det över tre år, så vänder kalkylen ofta.
Ni äger systemet i stället för en licens
Med ett standardsystem hyr ni funktionalitet och väntar på någon annans roadmap. Ett eget system äger ni, så det är era prioriteringar som styr vad som byggs härnäst och när.
Bygget har blivit billigare, men inte ägandet
Det som länge talat mot egenutvecklat, att det var dyrt och tog tid, gäller inte längre på samma sätt, för AI-assisterad utveckling har gjort själva bygget billigare. Ägandet har däremot inte blivit billigare. Systemet ska förvaltas, säkras och vidareutvecklas i tio år, och det som avgör om det håller är fortfarande att ni vet vad som ska byggas.
Systemet följer er när ni förändras
En standardprodukt får nya versioner när leverantören bestämmer det. Ett system byggt för er ändras i stället när er verksamhet gör det, i den takt ni själva väljer.
Hur vi arbetar
Så går ett systemprojekt till
Förstudie med fast pris
Projektet börjar med Systemskissen, där ni och era användare går igenom flödet på djupet: vem gör vad, i vilken ordning och med vilka beroenden. Under förstudien klickar användarna sig igenom en prototyp av kärnflödet, så att missförstånd syns innan ni investerat tungt. Förstudien har fast pris och slutar i en kalkyl och ett fast pris för fas 1 av bygget.
Azure · .NET · Power Platform · GitHub Copilot
Bygge i faser, hela vägen till produktion
Bygget delas i faser med en beslutspunkt mellan varje, och innan systemet går i produktion kör en testgrupp ur er verksamhet det skarpt. Där ingår också det som affärskritiska system kräver för att ni ska kunna lita på dem när det gäller, som felhantering, loggning, prestandaoptimering och automatiserade tester.
Azure App Services · CI/CD · DevOps · Automatiserad testning
Integration med er verklighet
Ett nytt system som inte pratar med ert affärssystem, er dataplattform eller era befintliga flöden skapar bara ett problem till. Därför planeras integrationen från första dagen, med API:er mot era system och dataflöden som synkar automatiskt. Arkitekturen utgår från de system ni redan har, så att det nya passar in och håller på lång sikt.
API-design · Azure Integration Services · Azure Functions · REST/GraphQL
Vi stannar kvar
Verksamheten förändras, och systemet behöver hänga med i många år efter driftsättningen. Därför förvaltar och vidareutvecklar vi det vi bygger, med samma team som redan arbetat i er kod och med era användare, så att ni slipper förklara historien varje gång något ska ändras. Returpacks affärssystem har vi förvaltat på det sättet i drygt 15 år, och med LFV:s flygplaneringssystem har vi hållit på i 25.
Förvaltningsavtal · DevOps · Kontinuerlig vidareutveckling
Insikter
Fördjupning om verksamhetsnära system
Fyra artiklar om frågorna som avgör om ett eget system är rätt väg och vad som krävs för att det ska hålla.
Vad är ett verksamhetsnära system?
Vad begreppet täcker, när det är rätt väg och vad som avgör om det håller.
Läs artikeln → 02 · BeslutetÄga eller hyra — när ska man bygga eget?
Vad kalkylen faktiskt innehåller och hur break-even-punkten har förändrats.
Läs artikeln → 03 · IntegrationIntegration i ett verksamhetsnära system
Hur ett eget system ansluter till resten av er IT-miljö, och vad som händer när ingen har planerat för det.
Läs artikeln → 04 · FörvaltningFörvaltning — vad håller ett system vid liv?
Ägarskap och dokumentation avgör systemets livslängd mer än tekniken gör.
Läs artikeln →Guide · 5 frågor
Är ett eget system rätt för er?
Svara på fem frågor, så får ni en ärlig fingervisning om ett eget system är rätt väg för er och åt vilket håll kalkylen pekar.
FAQ
Vanliga frågor
Vad är ett verksamhetsnära system?
Ett verksamhetsnära system är ett verksamhetssystem byggt för hur just er organisation arbetar, i stället för att ni anpassar processerna efter ett standardsystem. Systemet följer då flödet som det faktiskt ser ut, med färre manuella steg och bättre kontroll. Gaia bygger dem i Azure, .NET, React och Power Platform och förvaltar dem ofta i många år efteråt, som Returpacks affärssystem och LFV:s flygplaneringssystem.
Hur lång tid tar ett systemprojekt?
Det beror på hur stor processen är. Projektet börjar med Systemskissen, en förstudie till fast pris där ni går igenom flödet på djupet och era användare testar en klickbar prototyp. Den slutar i en prioriterad kravlista och ett fast pris för fas 1. Bygget delas sedan i faser med beslutspunkter emellan, och enskilda moduler kan vara i produktion efter 4–8 veckor. Därefter följer förvaltning, som för de flesta system pågår i många år.
Skiljer sig detta från att köpa ett standardsystem?
Ja. Ett standardsystem kräver att ni anpassar processerna efter programvaran, och det som inte passar hamnar i manuella kringlösningar och i väntan på leverantörens roadmap. Ett verksamhetsnära system byggs för hur ni arbetar och kan ändras när verksamheten ändras. Räknar man in anpassning, licenser och integration är kostnaden jämförbar med ett standardsystem.
Ingångserbjudande
Systemskissen — förstudien in i ert systemprojekt
Innan ni beställer ett bygge bör ni ha sett det. Systemskissen är förstudien, med en genomgång av processen och en klickbar prototyp som era användare fått säga sitt om. Förstudien har fast pris och slutar i ett fast pris för fas 1 av bygget, och sedan bestämmer ni om ni vill gå vidare.
Börja med processen som skaver mest
Berätta hur processen fungerar i dag, så säger vi om Systemskissen är rätt första steg.