Affärssystem: så kartlägger du behov och krav

Utgå från affärsmodell, mål och budget

Krav på ett affärssystem är bara relevanta om de speglar hur företaget tjänar pengar. Skatteverket kallar affärsidén för första steget mot att bli företagare och den grund företaget vilar på: vad du ska sälja, hur och till vem. Enligt samma källa beskriver affärsplanen affärsidén så att andra förstår verksamheten. Den brukar innehålla avsnitt om företagets idé, mål, kunder och affärsmodell, och kan användas för att sälja in idén till exempelvis investerare, leverantörer och banker.

Budgeten hör till samma underlag. Skatteverket lyfter att en budget gör att du märker om affärsplanen håller och kan planera verksamheten bättre. Översätt det till kravarbetet: vilka intäkter, marginaler och kostnader ska systemet stödja, och vilka investeringar i system, utbildning och införande ryms inom den ram ni faktiskt har?

Utgå från att systemet ska stödja styrning och tillväxt, inte bara dagliga rutiner. WH Group beskriver ett affärssystem som antingen en katalysator för tillväxt eller en bromskloss. Vid upphandling måste man därför utgå från verksamhetens mål och behov för att hitta ett system som skapar kraft framåt.

Praktiskt: varje krav ni skriver bör kopplas till ett mål i affärsplanen, en prioriterad process eller en budgetpost. Krav utan sådan koppling hör på en önskelista, inte i kravspecifikationen.

Sätt mandat, roller och intern förankring först

Genesis IT:s checklista inför affärssystembyte börjar med att utse en intern projektledare och ett projektteam. Ett affärssystem påverkar hela verksamheten och kräver därför tydlig intern ansvarsfördelning. Projektledaren ska driva arbetet framåt och samordna leverantör och interna resurser.

Checklistan har tre konkreta punkter: ta med personer från ekonomi, lager, försäljning och IT; säkerställ att projektledaren har mandat att fatta beslut; kommunicera projektets mål och tidsplan till hela organisationen. Mandatet avgör om ni kan prioritera bort krav, hålla tidsplaner och fatta beslut utan rundgång.

Genesis IT pekar också på ett vanligt misstag: att underskatta den interna arbetsinsatsen. Många företag tror att leverantören gör allt, men ett lyckat införande kräver stort internt engagemang. Planera tid och resurser under hela projektet, inte bara i uppstarten.

En bred projektgrupp ger två saker: den fångar behov från fler delar av verksamheten, och kraven som till slut drivs igenom har redan ägare i organisationen när systemet tas i bruk.

Kartlägg nuläget process för process

Genesis IT:s checklista är tydlig med ordningen: innan ni konfigurerar systemet måste ni förstå hur ni arbetar i dag och hur ni vill arbeta framöver. En tydlig kravbild är grunden för ett lyckat införande.

Checklistan anger tre steg i denna fas: dokumentera nuvarande arbetsflöden, identifiera flaskhalsar och förbättringspotential, och lista funktionella och tekniska krav. Kravlistan kommer sist och ska vila på en dokumenterad bild av verkligheten, inte på gissningar.

Arbeta process för process, inte avdelningsvis. Beskriv vad som utlöser processen, vilka steg den innehåller, vem som gör vad, vilka system och register som används, var information stannar av och var fel uppstår. Skilj sedan medvetet på tre lägen: så här arbetar vi i dag, så här skulle vi kunna arbeta med bättre stöd, och så här vill vi arbeta framöver.

Det sista läget ska styra kraven. Om ni bara dokumenterar nuläget riskerar ni att låsa fast dagens arbetssätt – inklusive omvägarna – i det nya systemet.

Fånga behov från alla som ska använda systemet

Genesis IT:s guide för små och medelstora företag föreslår att behovskartläggningen börjar med att identifiera de mest kritiska funktionerna. Den ger tre frågor: Vilka processer vill vi digitalisera eller förbättra? Vilka system använder vi i dag – och vad saknas? Vilka avdelningar ska använda affärssystemet?

Frågorna ska besvaras av verksamheten, inte bara av ledningen. Intervjuer eller workshops per roll och avdelning visar var arbetet faktiskt gör ont: var dubbelregistrering sker, var information saknas, var man tvingas till egna lösningar vid sidan av systemet.

Guiden pekar också på en återkommande fallgrop: att inte involvera användarna. Om medarbetarna inte är med i processen riskerar ni låg användning efter införandet. Behovsinsamlingen är därför både kravarbete och förankring.

Samla resultatet strukturerat – per process, per roll, per system – och håll isär konstaterade behov från lösningsförslag. Behovet är ofta ”vi behöver se lagersaldot i realtid”; lösningen kan se olika ut beroende på systemval.

Formulera och prioritera funktionella krav

Evidi beskriver ett affärssystem som en integrerad mjukvarulösning som hjälper företag att hantera och automatisera affärsprocesser inom ekonomi, lagerhantering, försäljning, inköp, logistik, analys och mycket mer. Det är en rimlig stomme för kravlistan: gå igenom varje område och formulera vad just er verksamhet behöver.

Bredden gör prioriteringen avgörande. Genesis IT:s guide varnar för att det utan tydlig behovsbild är lätt att välja ett system som gör för lite eller alldeles för mycket. WH Group konstaterar att ett affärssystem inte kan lösa alla utmaningar en verksamhet har. Kritiska behov måste därför skiljas från trevliga tillägg.

En enkel metod är att sortera kraven i ska-krav (utan dem fungerar inte verksamheten), bör-krav (viktiga men inte avgörande vid uppstart) och önskemål (kan vänta eller hanteras manuellt). Sätt en ägare och en motivering på varje krav, så att ni i leverantörsdialogen kan förklara varför något är kritiskt.

Formulera kraven så att de går att svara ja eller nej på och att svaret går att verifiera i en demonstration. Undvik sammanblandningar som ”användarvänligt gränssnitt för orderhantering” – dela upp det i ett funktionellt krav på orderhanteringen och ett separat krav på användbarhet.

Prioritering av krav: ska, bör, önske

Ställ krav bortom funktionslistan

Genesis IT:s guide för små och medelstora företag lyfter fyra områden vid sidan av funktionslistan: tänk skalbart från start, välj ett branschanpassat system, utvärdera användarvänlighet och säkerställ support och vidareutveckling. Skalbarhet handlar om att slippa byta plattform när verksamheten växer; branschanpassning om färdiga arbetsflöden och bättre användarupplevelse utan dyra anpassningar.

Om användarvänlighet skriver samma guide att systemet ska vara enkelt att använda – inte bara för IT-avdelningen utan för alla medarbetare. Guiden råder er att be om en demo och låta flera olika användare testa innan ni bestämmer er. Hög användbarhet beskrivs som en direkt investering i produktivitet.

Integrationer hör också hit. Guiden nämner betallösningar som Swish och Klarna, e-handelsplattformar och transportlösningar som nShift, och konstaterar att bra nativa integrationer sparar tid och minskar risken för fel.

WH Group listar fem grundläggande krav: uppföljningsmodell, systemets roadmap, API, IT-säkerhet och avvikelsehantering. Det innebär att systemet ska kunna vara en del av ett ekosystem i stället för en isolerad ö; att leverantören ska ha en framtidssäker roadmap och kunna svara på hur de arbetar med produktutveckling; samt att IT-säkerhet och säkerhet i molnet ska ha tydliga och dokumenterade rutiner. Fråga leverantören hur de hanterar detta.

Inventera data och förbered migrering tidigt

Genesis IT:s checklista kallar datamigrering en kritisk del av implementationen och varnar för att flytta felaktig eller ostrukturerad data, eftersom det kan skapa problem i det nya systemet. Stegen är att rensa kund-, artikel- och leverantörsregister, strukturera data enligt det nya systemets format och planera testmigrering före skarp drift.

Detta påverkar kravbilden. Hur era register ser ut i dag – vilka fält som är obligatoriska, hur artiklar numreras och grupperas, hur kunder och leverantörer kategoriseras – avgör vad som kan flyttas och vilka fält och strukturer ni behöver kräva i det nya systemet.

Inventera därför tidigt: vilka register finns, vem äger dem, vilka dubbletter och luckor finns, och vilken data behövs verkligen i det nya systemet? Historisk data som ingen längre använder kan ofta arkiveras i stället för att migreras.

Testmigrering i god tid gör att ni upptäcker formatproblem, dubbletter och tappade kopplingar innan de blir produktionsproblem. Räkna med att rensningsarbetet kräver tid från verksamheten, inte bara från IT.

Samla kravbilden i en kravspecifikation som går att utvärdera

När processer, behov, funktionella krav och tekniska krav är dokumenterade ska de samlas i en kravspecifikation. Genesis IT:s checklista nämner att lista funktionella och tekniska krav som ett eget steg, och Exsitec har tagit fram en guide och en kravspecifikation för affärssystem i sitt material om inköp av affärssystem.

Specifikationen ska byggas så att offerter och demonstrationer kan jämföras rättvist. Varje krav ska ha ett unikt nummer, en tydlig formulering och en prioritering, och leverantörerna ska svara på samma kravlista i samma ordning. Då syns vilka krav som uppfylls direkt, vilka som kräver anpassning och vilka som inte stöds alls.

Ta med uppföljningskravet. WH Group skriver att affärssystemet måste kunna stödja den uppföljningsmodell ni vill ha, och att det är ett grundkrav: systemet ska kunna samla in, strukturera och analysera rätt information utifrån hur ni faktiskt styr verksamheten – till exempel på projekt, marknader, affärsområden eller rullande tolv månader – utan export till Excel eller egna lösningar vid sidan av. WH Group lyfter också avvikelsehantering som ett viktigt område, där målet är att flytta användaren från rutinmässig inmatning till avvikelser och kvalificerade uppgifter.

Komplettera med en modell för uppföljning under införandet: vem svarar för respektive kravområde, hur dokumenteras avvikelser och hur beslutas det när ett krav inte kan uppfyllas inom projektets ram. Genesis IT:s checklista tar upp att dokumentera och åtgärda eventuella avvikelser som en del av kvalitetssäkringen.

Testa och förankra kraven internt

Genesis IT:s checklista avsätter ett eget steg för tester och kvalitetssäkring: innan systemet går live bör ni testa alla viktiga funktioner – från orderflöden till rapporter – i en testmiljö, med realistiska scenarier från er verksamhet. Det minskar risken för driftstörningar och fel.

Låt flera användargrupper prova. Genesis IT:s guide om systemval råder er att låta flera olika användare testa i samband med demonstration innan ni bestämmer er. Samma logik gäller era egna tester: ekonomi, lager, försäljning och IT bör alla köra sina egna scenarier, inte bara se någon annans genomgång.

Koppla testet till kravlistan. Varje ska-krav bör gå att verifiera i testmiljön, och avvikelser ska dokumenteras och åtgärdas. Visar sig ett krav svårare att uppfylla än väntat är det bättre att upptäcka under test än efter driftstart.

Förankringen är minst lika viktig som testet. Genesis IT:s checklista tar upp att boka utbildningstillfällen för olika användargrupper, skapa manualer eller interna guider och kommunicera nyttan med systemet för att skapa engagemang. Exsitec beskriver risken med ett system som inte möter behoven: verksamhetsstöd hamnar utanför systemet i mappar och kalkylfiler, trots att man vill ha det i affärssystemet.

Gör kravkartläggningen till en återkommande avstamning

Behovs- och kravarbetet är inte något man gör en gång och lämnar. Folkhälsomyndighetens checklista för implementering med kvalitet beskrivs som ett verktyg för hela implementeringsprocessen – inte något man läser, besvarar och lämnar, utan något man återvänder till regelbundet. Checklistan inleds med fyra centrala frågor om behov, insats, kunskapsstöd och plats för implementering.

Enligt Folkhälsomyndigheten kan frågor som inte går att besvara, eller inte besvaras tillräckligt konkret, visa var det finns frågetecken eller svagheter som måste hanteras innan man går vidare. Myndigheten konstaterar också att arbetet ibland inte går i mål: svaren kan visa att verksamheten inte behöver den föreslagna insatsen, eller att verksamheten inte är redo – och att man då på goda grunder kan besluta att avbryta eller pausa arbetet.

Översatt till affärssystemprojekt blir det en enkel checklista att återkomma till: Håller affärsplanens och budgetens antaganden? Är den interna projektorganisationen bemannad och mandaterad? Har vi dokumenterat processerna som kraven vilar på? Är data redo? Finns tid och resurser för test och utbildning?

Svaren styr om ni ska gå vidare, justera inriktning eller skjuta upp. Poängen är att fatta beslutet med öppna ögon – hellre en pausad upphandling på goda grunder än ett införande som ingen i organisationen är redo för.