Drivs fram genom ett innovationsprojekt för ekonomiskt bistånd
Arbetsmetoden som beskrivs här tillämpas i ett innovationsprojekt för automatiserad ärendeberedning och beslutsstöd vid ekonomiskt bistånd. Det är det andra projektet som följer det nya arbetssätt som först testades inom dokumenthantering — och syftar bland annat till att verifiera om metoden håller även för verksamhetsnära, myndighetsutövande utveckling.
Projektet kombinerar tre innovationsdagar där verksamhet och utvecklingsteam tillsammans verifierar problembild, MVP och öppna frågor, med en efterföljande tvåveckors utvecklingssprint. AI används som aktivt verktyg genom hela processen. Sidan dokumenterar arbetsformen steg för steg — som en levande instruktion.
Varför behövs ett nytt arbetssätt?
Rakel 2.0 är det andra projektet som tillämpar det nya arbetssättet — efter den första sprinten om dokumenthantering. Målet är att verifiera om metoden håller även för ett verksamhetsnära, myndighetsutövande område där regelverk, dataintegrationer och konsekvenser för enskilda spelar en helt annan roll än i en mer teknikdriven kontext.
Sundsvalls kommun har historiskt arbetat med traditionell agil utveckling inspirerad av stora ramverk som SAFe, utan att ha valt ett specifikt ramverk. Utvecklingsteamen har delats upp utefter kompetensområde — backend och frontend — med flera lager av roller mellan verksamheten och utvecklarna: projektledare, verksamhetsutvecklare, lösningsarkitekter och teamledare.
Verksamheten, som är ovan vid teknisk utveckling, har ofta svårt att formulera krav tidigt i processen. Kravbilden förändras löpande, vilket skapar osynk som leder till förseningar, budgetöverskridanden och resultat som inte möter verksamhetens faktiska behov.
- Projekt drar ut på tiden och håller inte budget
- Uppdelning i backend- och frontend-team skapar beroenden och väntetider
- Flera lager mellan verksamhet och utvecklare försvårar kommunikation
- Verksamheten har svårt att uttrycka krav tidigt — kravbilden ändras löpande
- Resultaten uppfyller inte verksamhetens faktiska behov
- Tvärfunktionella team som kan lösa hela uppgiften
- Direktkontakt mellan verksamhet och utvecklare — inga mellanlager
- Snabbare leveranscykler och kortare feedbackloopar
- Prototypdriven utveckling som validerar hypoteser tidigt
- AI som verktyg för att accelerera utvecklingsprocessen
Beslutsstöd med automatiserad ärendeberedning
Rakel 2.0 är inte ett system som fattar beslut automatiskt. Lösningen är ett beslutsstöd som preppar ärendet åt handläggaren — hämtar data, bygger normberäkning och lyfter flaggor utifrån regelverket. Handläggaren fattar beslutet; lösningen verkställer åtgärden efter bekräftelse.
- Hämtar data från verksamhetssystem och SSBTEK och bygger automatiskt en normberäkning.
- Lyfter flaggor till handläggaren utifrån regelverket — t.ex. inkomstavvikelser, utgifter över gränsvärden, personer som inte stämmer.
- Handläggaren granskar, justerar vid behov och fattar beslutet.
- Efter handläggarens bekräftelse utför lösningen åtgärden (beslut, utbetalning, kommunikation) mot verksamhetssystemet.
- Det enda stället lösningen styr är vägvalet: om ärendet inte uppfyller kriterierna för återansökan ruttas det till hantering som ny ansökan.
Projektets faser
Projektet är uppbyggt i fyra faser: en förberedande fas där innovationsdagarna ingår, själva tvåveckors-sprinten, en utvärderingsfas och slutligen fortsatt utveckling under hösten.
Förberedelser innan sprinten
Fas 0 omfattar både det tekniska förarbetet och innovationsdagarna. Fem moment skapar förutsättningarna för att teamet ska vara produktivt från dag ett av sprinten:
Prototyp och förarbete
Ett förslag på ansökningsformulär är framtaget (ej färdigt). Verksamheten har förberett sina önskemål kring frågor och logik i formuläret. Det finns en BPMN-process för flödet och en integration mot SSBTEK på plats. Det tekniska underlaget är på en nivå där sprinten kan ta vid och förfina mot färdig funktion.
Innovationsdagarna (5–7 maj 2026)
Tre dagar då verksamhet och utvecklingsteam tillsammans verifierade problembilden, tog fram MVP-lista och preciserade öppna frågor. Resultatet är direkta indata till sprinten — leverabler, beslut, MVP-krav och konkretiserade frågeställningar. Verksamheten höll i stora delar av dialogen och drev agendan.
Arkitektur- och teknikdialog
Övergripande dialog kring lösningsarkitektur och tekniska förutsättningar utifrån prototypen. Teamet alignar kring teknikstack, miljöer och övergripande designbeslut så att alla är redo att börja direkt.
Egen deploykedja till testbädd
Teamet säkerställs full access att själva deploya ändringar direkt till en dedikerad testbädd (sundsvall.dev). Inga beroenden till andra team, som exempelvis IT-produktion, för att löpande kunna leverera och verifiera förändringar under sprintens gång. Autonomi i hela kedjan är en förutsättning för sprintens tempo.
Bedöm verksamhetens involvering
Graden av verksamhetsinvolvering under sprinten måste bedömas utifrån vad som ska byggas — Rakel 2.0 är en verksamhetsnära funktion som kräver särskild domänkunskap, så nära dagligt samarbete med verksamhetsspecialister behövs. Stödet till verksamhetens förberedelse varierar dessutom med mognad och bör vara en explicit bedömning i Fas 0 — denna verksamhet klarade sig långt på eget bevåg efter inledande vägledning.
Standup — sprintens dagliga nav
Varje dag genomförs en standup som fungerar som teamets gemensamma synkpunkt. Standupens syfte är tvådelat: att röja hinder för utvecklingen och att synka frågor och funderingar inom teamet och med verksamheten.
Genomgång av gårdagens utveckling
Teamet går igenom vad som gjorts sedan förra standupet — vad är klart, vad pågår, och var står vi i förhållande till sprintens mål?
Demo av ny funktionalitet
Om ny funktion har levererats körs en kort demo så att hela teamet ser framstegen och kan ge direkt feedback.
Frågor, hinder & synk
Öppen dialog där teammedlemmar lyfter blockeringar, frågor till verksamheten eller tekniska funderingar som behöver lösas för att arbetet ska flyta vidare.
Bärande principer för sprinten
Dessa principer vägleder teamets arbete genom hela sprinten.
Noll avstånd
Alla mellanlager mellan verksamhet och utveckling elimineras. Direkt dialog, direkt feedback.
Snabba leveranser
Korta cykler, dagliga leveranser och snabba feedbackloopar som fångar förändrade behov.
Tvärfunktionellt
Ett team som täcker alla kompetenser. Inga beroenden till andra team, ingen väntan.
AI-accelererat
AI används som verktyg i utvecklingen för att öka tempo och frigöra utvecklarnas kreativa kraft.
Hypotesdriven
Prototypen validerar en hypotes innan resurser investeras. Vi testar innan vi bygger klart.
Löpande anpassning
Processen utvecklas under sprinten. Vi lär oss och justerar dagligen.
Vad innebär det att delta i en innovationssprint?
Att delta i en innovationssprint är inte som vanligt projektarbete. Tempot är högre, avstånden kortare och förväntningarna annorlunda. Den här guiden beskriver det mindset och de beteenden som krävs av varje deltagare — oavsett roll — för att sprinten ska lyckas.
Mycket av det som beskrivs här kan kännas självklart. Men erfarenheten visar att det är just i gapet mellan att veta vad som krävs och att faktiskt agera därefter som de flesta sprintar fallerar. Läs med öppet sinne — inte för att lära dig nya saker, utan för att kalibrera ditt förhållningssätt.
En sprint lyckas inte för att teamet har rätt kompetens — den lyckas för att teamet har rätt inställning.
Ta ägarskap — inte instruktioner
Du är inte här för att utföra uppgifter. Du är här för att lösa ett problem.
I en sprint finns det ingen produktägare som talar om exakt vad du ska bygga. Det finns inget kravdokument som beskriver varje detalj. Istället finns det ett problem som behöver lösas, och du är en del av det team som ska lösa det.
Det innebär att du behöver förstå varför vi bygger det vi bygger — inte bara vad. Om du ser att något inte stämmer, att en lösning inte fungerar, eller att vi är på väg åt fel håll — då är det ditt ansvar att säga ifrån. Inte någon annans.
- Du ställer frågor när något är oklart — direkt, inte efter mötet
- Du föreslår alternativ om du ser en bättre väg
- Du tar initiativ att lösa problem utan att vänta på instruktioner
- Du hjälper teammedlemmar som fastnat, även om det inte är ditt ansvarsområde
- Väntar på att bli tilldelad arbete istället för att ta det
- Ser problem men säger inget — "det är inte mitt bord"
- Följer instruktioner blint trots att resultatet uppenbart blir fel
- Skjuter frågor framför sig — "jag tar det imorgon"
Kommunicera direkt och ofta
Kort avstånd kräver frekvent dialog. Tystnad är det största hindret.
En av sprintens viktigaste egenskaper är att avstånden mellan alla deltagare är minimala. Det finns inga mellanlager som filtrerar eller fördröjer information. Det betyder att du har direkt tillgång till alla — verksamheten, utvecklarna, alla i teamet.
Men kort avstånd är bara värdefullt om det faktiskt används. Om du sitter tyst med en fråga, om du inte delar framsteg eller om du undviker att ge direkt feedback — då förlorar vi sprintens viktigaste fördel.
Feedback ska ges direkt — inte sparas till nästa möte
I en sprint med dagliga leveranser hinner saker bli fel snabbt om feedback inte kommer i tid. Om du ser något som inte stämmer — i en demo, i en lösning, i ett beslut — säg det direkt. Att vara rak är inte oartigt. Att vänta tills det är för sent att ändra — det är problemet.
Det gäller alla riktningar: utvecklare mot verksamhet, verksamhet mot utvecklare, och kollegor sinsemellan. Sprinten lever på ärlig, omedelbar kommunikation.
Håll tempot — varje dag räknas
Tio arbetsdagar är inte mycket. Det som inte händer idag, händer kanske aldrig.
En tvåveckorssprint har ingen buffert. Det finns ingen "nästa sprint" att skjuta saker till. Det som inte görs idag minskar direkt vad vi kan åstadkomma totalt. Det betyder inte att du ska stressa — det betyder att du ska vara fokuserad och medveten om att din tid har direkt påverkan på resultatet.
Praktiskt innebär det: kom förberedd till standup. Lyft hinder direkt istället för att försöka lösa dem ensam i timmar. Fatta snabba beslut med tillräckligt bra information istället för att vänta på perfekt information som aldrig kommer.
Det perfekta är det godas fiende. Vi bygger för att lära — inte för att leverera en slutprodukt.
Omfamna förändring — det är meningen
Det vi bygger idag kommer att ändras imorgon. Och det är precis rätt.
I traditionellt projektarbete ses ändringar som ett problem — ett tecken på dålig planering eller otydliga krav. I en sprint är ändringar ett bevis på att processen fungerar. Vi bygger, vi testar, vi lär oss, och vi justerar. Det är själva poängen.
Det kräver att du släpper tanken på att "din del" ska vara perfekt och färdig. Var beredd på att det du byggt kan kastas om, att prioriteringar ändras och att lösningen utvecklas i en riktning du inte förutsåg. Det handlar inte om att ditt arbete var dåligt — det handlar om att vi vet mer nu än vi visste igår.
- "Vi lärde oss att det inte fungerade — bra, nu vet vi mer"
- "Verksamheten vill ha det annorlunda — då bygger vi om"
- "Jag hade fel om det här — tack för feedbacken"
- "Men vi bestämde ju redan att det skulle vara så här"
- "Det kan vi inte ändra nu — jag har redan byggt klart det"
- "Det borde verksamheten ha sagt från början"
Teamet framför individen
Din viktigaste uppgift är inte att vara bra på ditt — det är att göra teamet bättre.
I en innovationssprint arbetar alla tätt tillsammans. Det innebär att om du är klar med din uppgift men en kollega sitter fast, så är din nästa uppgift att hjälpa den kollegan. Det spelar ingen roll att det inte är "ditt område". Sprintens framgång mäts i vad teamet levererar — inte vad du personligen åstadkom.
Det innebär också att du behöver vara transparent med var du står. Att erkänna att du fastnat är inte en svaghet — det är att ge teamet möjlighet att lösa problemet snabbare. Att dölja problem för att "lösa det själv" är den dyraste misstaget i en sprint.
Alla roller är jämlika under sprinten
Under sprinten finns inga hierarkier. En verksamhetsspecialists observation väger lika tungt som en senior utvecklares tekniska bedömning. Den som har rätt information i stunden har mest att bidra med — oavsett titel. Det förhållningssättet kräver att alla lyssnar aktivt och respekterar varandras perspektiv.
Ha mod att vara obekväm
Tillväxt sker utanför komfortzonen — det gäller både produkten och dig.
En sprint pressar gränser. Du kommer att arbeta med människor du inte brukar samarbeta med. Du kommer att fatta beslut med ofullständig information. Du kommer att visa halvfärdigt arbete. Du kommer att få feedback som utmanar dina antaganden.
Allt detta är obekvämt. Men det är i det obehagliga som de verkliga genombrotten sker — både för produkten och för dig som deltagare. De sprint som producerar bäst resultat är de där deltagarna vågade vara osäkra, ställa dumma frågor och prova saker som kanske inte fungerade.
Den som aldrig visar halvfärdigt arbete lär sig aldrig om det var rätt väg. Våga visa, våga fråga, våga ändra dig.
Sex principer — ett mindset
Allt kokar ner till en enda sak: du är här för att bidra till att teamet löser ett verkligt problem på kortast möjliga tid. Det kräver ägarskap, rakhet, tempo, flexibilitet, laganda och mod.
Ägarskap
Förstå varför, inte bara vad. Ta ansvar för helheten.
Kommunikation
Prata direkt, ge feedback omedelbart, dölj ingenting.
Tempo
Varje dag räknas. Agera nu med tillräckligt bra information.
Förändring
Ändringar är bevis på framsteg. Omfamna dem.
Laganda
Teamets resultat är ditt resultat. Hjälp andra först.
Mod
Visa halvfärdigt. Ställ frågor. Våga ha fel.
Så rör sig ärendet genom lösningen
Schemat visar det tänkta flödet på hög nivå med datamängder per steg: inläsning → styrande vägval → datahämtning (verksamhetssystem, CareManagement, SSBTEK) → normberäkning → beslutsstöd och flaggor → beslut, utbetalning och kommunikation → effektuering → statusuppdatering. Återskrivning till verksamhetssystemet sker initialt via RPA, med processmotor/API som mål.
Funktioner i Rakel 2.0
Nedan listas funktionerna grupperade i tio områden i samma ordning som ärendet behandlas — från ansökningsformulär till effektuering. Varje funktion har ett unikt ID med prefix för sitt område (FORM, IN, DATA, SSB, NORM, UTG, FLAG, BES, EFF, GUI). Funktionerna är konsoliderade från MVP-kraven, SSBTEK- och Rakel-regelverket samt processkartan från innovationsdagarna.
Funktionerna delas in i tre hinkar
Eftersom verksamhetssystemets IFO-delar inte är konfigurerade när sprinten genomförs (se Insikt 01) prioriterar vi funktionerna i tre hinkar utifrån vad som kan byggas och verifieras nu.
Kan byggas och verifieras med befintlig API-åtkomst. Här ligger sprintens primära leveranser.
Kan byggas men inte verifieras mot riktig data — verksamhetssystemet saknar testdata. Byggs mot API-specifikation med mockad data.
Kräver data eller integrationer som ännu inte finns. Tas inte upp i denna sprint.
-
FORM-01
Formulär för nyansökan
-
FORM-02
Formulär för återansökan
-
FORM-03
Formulär för tilläggsansökan
-
IN-01
Skapa händelse/aktualisering när ansökan inkommit
-
IN-02
Hämta ansökan och bilagor från e-tjänsten
-
IN-03
Sök befintligt ärende
-
IN-04a
Styrande vägval — öppet ärende?Finns inget öppet ärende i systemet ruttas ansökan till hantering som ny ansökan.
-
IN-04b
Styrande vägval — huvudpersonÄr sökande och medsökande korrekt registrerade i systemet? Om nej, hantera som ny ansökan.
-
IN-04c
Sekretessmarkering — hård stoppHanteras ej automatiskt. Se Ö-01.
-
IN-05
Arkivera ansökan och bilagorSlå ihop bilagor till samlad fil. Se Ö-02 för när detta sker.
-
IN-06
Processflöden per ansökningstypNy / åter / tillägg — varje flöde täcker hela kedjan inläsning → beslut → arkivering.
-
IN-07
Löpande statusuppdateringBåde lösning och handläggare uppdateras — t.ex. när mer information inväntas.
-
DATA-01
Initial läsning från verksamhetssystemetPersonnummer, normberäkning (inkomster, utgifter, gemensamma hushållskostnader, personer/omfattning, norm), sekretessmarkering, senaste besluten med perioder.
-
DATA-02
Läsning från CareManagement: pågående återansökanMed perioder.
-
DATA-03
Läsning från verksamhetssystemet: verkställighetInsats/aktualitet med perioder, personer och handläggare.
-
DATA-04
Läsning från SSBTEK: inkomsterCSN, FK m.fl. samt ekonomiska beslut från Arbetsförmedlingen.
-
DATA-05
Läsning från CareManagement: inkomster + utgifterFrån ansökan.
-
DATA-06
Återskrivning till CareManagement: ny normberäkning
-
DATA-07
Återskrivning till verksamhetssystemetBevakningar/notiser, journal, dokument, beslut, utbetalning (vid normalkonto) — sker initialt via RPA, processmotor som mål.
-
SSB-01
Läs ut samtliga inkomsterFörmån, alla delförmåner och beloppstyper.
-
SSB-02
Whitelist med godkända förmånerAllt utanför listan flaggas (visar förmån + delförmån + beloppstyp).
-
SSB-03
Definiera ansöknings-, kontroll- och jämförelseperiod
-
SSB-04
Överför inkomster i kontrollperiodenTill normberäkningen.
-
SSB-05
Överför inkomster i jämförelseperiodenSom ej redan överförts.
-
SSB-06
Undantag — inkomster som varken överförs eller flaggas
-
SSB-07
Undantag — inkomster som alltid flaggasTrots att de hanterats. Se Ö-03.
-
SSB-08
Generell jämförelsemotorSummera per förmån, jämför kontroll- mot jämförelseperiod på nettobelopp, flagga vid avvikelse över tröskel. Täcker via konfiguration: dagersättning, PM/PM-Prel, bostadsbidrag, PLV, barnbidrag, underhållsstöd, studiestöd, a-kassa, studiehjälp. Se Ö-04, Ö-05, Ö-10.
-
SSB-09
Specialfall aktivitetsstöd/etableringsersättningKontrollera uttagna dagar mot icke-röda dagar; flagga vid avvikelse eller om period inte kan läsas. Se Ö-11, Ö-12.
-
SSB-10
Specialfall föräldrapenningKontrollera uttagna dagar + glapp mellan perioder; flagga vid glapp eller saknad föregående månad.
-
SSB-11
Specialfall studiehjälpExtratillägg (855 kr) ska ej tas med; hantera uppehållsmånader. Se Ö-06.
-
SSB-12
Jämför SSBTEK-inkomster mot normberäkningenSå inget dubbelförs.
-
SSB-13
Skapa nya inkomstslag för jämförelseAnnan inkomst, PLV, underhållsstöd, lön.
-
NORM-01
Skapa normberäkning från ansökanStart-/slutdatum, kopiera angivna inkomster och utgifter.
-
NORM-02
Hantera ofullständig vs. fullständig dataVid ofullständig: justera utifrån tillgängligt, flagga, schemalägg automatiskt nytt försök. Vid fullständig: justera utifrån all information och flagga eventuella avvikelser.
-
NORM-03
StoppfunktionHandläggare kan "ta" ansökan så lösningen inte skriver över manuellt arbete.
-
UTG-01
Generell utgiftsmotorAnvänd ansökt summa, jämför mot schablon + föregående månads godkända, flagga vid för stor differens, justera ev. godkänd summa. Täcker: boendekostnad, el, hemförsäkring, a-kassa/fackavgift, arbetsresor, sjukresor/färdtjänst, internet (egna gränsvärden per typ).
-
UTG-02
Specialfall medicin & läkarvårdMot schablon/gränsvärde utan föregående-jämförelse.
-
UTG-03
Övrigt biståndGodkänn alltid 0 kr och flagga.
-
UTG-04
Implementera gränsvärdesmatrisenDe sju fallen: inom/över gränsvärde × historik finns/saknas × stor ökning, per utgiftstyp. Se Ö-07.
-
FLAG-01
Flagga utifrån ansökningsfrågorÄndrad boendesituation, utbetalningssätt, nya tillgångar, vistelse i kommunen m.fl.
-
FLAG-02
Flagga om månadsbeslut redan finnsFör perioden.
-
FLAG-03
Flagga avvikelse i personerMellan ansökan och normberäkning/mall.
-
FLAG-04
Flagga barn som inte bor heltid"Dubbelkolla inkomster". Se Ö-05.
-
FLAG-05
Visa ärenden markerade som återkravLäs och visa i gränssnittet.
-
FLAG-06
Spegla bevakningar och notiserRen spegling utan logik — t.ex. tillfälligt uppehållstillstånd, barn som tar studenten.
-
BES-01
BeslutsförslagVisar förslag till beslut och utbetalningskonton. Standard beslutstyp 12:1, frastext och beslutsorsak från föregående beslut. Ändringsbart via rullistor. Vid bekräftelse fattar lösningen beslutet.
-
BES-02
UtbetalningSpeglar tidigare betalningsmottagare med konton och fördelningar, ändringsbart via rullista, kontering. Återskrivning till verksamhetssystemet gäller vid normalkonto. Se Ö-08, Ö-09, Ö-13.
-
BES-03
KommunikationStandardmeddelandefunktion + dagens datum, ändringsbart (t.ex. digital brevlåda/papper). Vid bekräftelse utför lösningen aktiviteten.
-
BES-04
Meddelanden ska kunna arkiverasMellan handläggare och klient.
-
EFF-01
Läs om utbetalning är effektueradI verksamhetssystemet — inkl. datum och dokument som ska visas på Mina sidor.
-
EFF-02
Polling-loopUpprepa kontroll tills utbetalning är effektuerad. Se Ö-14.
-
EFF-03
Uppdatera ärendestatus i CareManagementNär effektuering bekräftats.
-
GUI-01
SSBTEK-knapp för manuell dubbelkollSpeglar befintlig mikrotjänst.
-
GUI-02
Handläggare kan ändra i normberäkningenÄndringar skrivs tillbaka till verksamhetssystemet.
-
GUI-03
Dokumentvisning på Mina sidorTaggning av dokument skrivs till administrationsverktyg och verksamhetssystem; dokumenten hämtas tillbaka för visning.
Öppna frågor — 14 uppgifter
Frågor som identifierades under innovationsdagarna och som behöver besvaras innan respektive funktion kan byggas färdig. Presenteras som uppgifter att lösa, inte som osäkerheter.
-
Ö-01
Skilj på ruttning till ny ansökan och hård stopp vid sekretessBerör IN-04.
-
Ö-02
När ska bilagor slås ihop till samlad fil?Vid inskickning eller arkivering. Berör IN-05.
-
Ö-03
Hantera elstöd och skatteåterbäringSka de alltid flaggas eftersom de inte ser överförda ut? Berör SSB-07.
-
Ö-04
Procentsatser och riktning för jämförelsetrösklarPer inkomsttyp. Blockerar SSB-08.
-
Ö-05
Barn som bor deltid — halva inkomsterDefiniera hur lösningen ska känna till detta. Berör SSB-08 och FLAG-04.
-
Ö-06
Studiestöd via uppehållsregelverk eller manuell flagga?Berör SSB-11.
-
Ö-07
Hantera "avdrag soc" på bostadsbidrag och PLVHur ska detta flaggas? Berör UTG-04 och SSB-08.
-
Ö-08
Utbetalning — styrning på datum, uppdelning, OCR-fakturorBerör BES-02.
-
Ö-09
Förval av betalningsmottagare i verksamhetssystemetBekräfta om det går. Berör BES-02.
-
Ö-10
Preliminär kontra definitiv skattAvstämning med Försäkringskassan krävs. Berör SSB-08.
-
Ö-11
Kvittning och utmätning på dagersättningarBerör SSB-09.
-
Ö-12
Karensavdrag och rehabersättning på sjukpenningBerör SSB-09.
-
Ö-13
Utbetalning till annat än normalkontoBerör BES-02 och DATA-07.
-
Ö-14
Pollingintervall och timeout för effektuerad utbetalningBerör EFF-02.
Lärdomar från innovationsdagarna
Rakel 2.0 är det andra projektet att tillämpa det nya arbetssättet. Under innovationsdagarna 5–7 maj 2026 framkom två centrala insikter som styr hur sprinten genomförs och hur arbetssättet behöver justeras framåt.
Verksamhetssystemets IFO-delar är ännu inte konfigurerade och saknar all data när sprinten genomförs. Det skulle kunna tala för att skjuta upp sprinten tills datan finns på plats — men vi väljer ändå att köra. Skälet är att verksamhetens nyckelkompetens — en och samma person som både är lösningsförvaltare och processexpert — går på föräldraledighet efter sommaren. Den domänkunskapen är inte ersättningsbar och vi vill ta tillvara den medan den finns tillgänglig.
Strategin blir därför att bygga mot API-specifikation med mockad data så långt det går nu, och verifiera mot riktig data när systemet är konfigurerat. Eftersom återskrivningen till verksamhetssystemet dessutom initialt sker via RPA — med processmotor/API som mål — får integrationen två olika "verifieringspunkter": en mot RPA-flödet och en mot framtida API.
Den uppenbara risken är att vi bygger något som inte håller mot verkligheten. För att hantera det isolerar vi integrationerna så att mocken enkelt kan bytas mot riktig data, och dokumenterar tydligt vad som är verifierat kontra byggt-mot-spec.
Bygg mot spec, isolera integrationerna så mock enkelt kan bytas mot riktig data, och dokumentera tydligt vad som är verifierat kontra byggt-mot-spec. Planera in verifieringsfönster i Fas 3 när verksamhetssystemet är konfigurerat.
Innovationsdagarnas plan var att verksamheten skulle hålla i förmiddagen dag 1 och att utvecklingsteamet sedan tog över. Det som faktiskt hände var att verksamheten höll i hela dag 1 — och drev både dialogen och agendan långt in på dag 2. Det blev formatets största framgångsfaktor: när verksamheten själv äger problembilden och leder genomgången skapas en helt annan precision i kraven än när tekniken översätter åt dem.
Insikten är samtidigt att stödet till verksamhetens förberedelse varierar med mognad. Denna verksamhet klarade sig långt på eget bevåg efter en inledande vägledning. En annan verksamhet hade behövt betydligt mer hjälp för att nå samma utgångsläge. Det betyder att vi inte kan ha en standardmall för förberedelsestöd — det måste vara en explicit bedömning i Fas 0 av varje sprint.
Praktiskt betyder det att rollen processledning av innovationsdagarna behöver ha utrymme att också vara tyst när verksamheten driver — och samtidigt kunna gå in och stötta mer aktivt när det behövs. En obalanserad förberedelse syns direkt: lägre engagemang, otydligare problembild, sämre MVP-lista.
Inkludera bedömning av förberedelsestöd till verksamheten som ett uttalat moment i Fas 0-processen för kommande sprintar. Avsätt en initial dialog där processledningen bedömer verksamhetens mognad och kalibrerar stödet därefter.
Sprintens dag-för-dag-logg
Sprintens dag-för-dag-logg fylls i löpande från och med v.25 (15 juni 2026). Här kommer anteckningar från standup, möten, beslut och faktisk utveckling i koden att dokumenteras dag för dag — som en levande logg och framtida referens.
Så uppdateras sidan: Efter varje standup lämnar processledningen anteckningar som kompletteras med commit-historik från sprintens kodrepon. Sidan växer löpande under sprintens gång.
Vad sprinten ska leverera
Sammanfattningen av Rakel 2.0-sprinten skrivs i efterhand när tvåveckors-sprinten (v.25–26) är avslutad. Här kommer hypotes, faktisk leverans, slutdemo och utfall mot verksamhetens kriterier att dokumenteras.
Hypotesen som testas: Att ett tvärfunktionellt team utan mellanlager — parad med AI som aktiv medarbetare och med stark verksamhetsförankring genom innovationsdagarna — på två veckor kan leverera en första, sammanhängande version av beslutsstöd och automatiserad ärendeberedning för ekonomiskt bistånd. Givet att verksamhetssystemet ännu inte är konfigurerat bygger vi mot API-spec med mockad data (se Insikt 01); verifiering mot riktig data sker i Fas 3.
Sprinten är kommande
Innovationsdagarna 5–7 maj 2026 är genomförda. Tvåveckors-sprinten v.25–26 (15–26 juni 2026) är kommande. Den här fliken fylls i löpande från sprintstart och slutdemo planeras till slutet av v.26.
Retrospektivet skrivs efter sprinten
Retrospektivet för Rakel 2.0-sprinten skrivs i efterhand när tvåveckors-sprinten (v.25–26) är avslutad. Här kommer teamets lärdomar att samlas: vad som bar sprinten, vad som måste finnas på plats nästa gång, och vad som kan välta formatet.
Retrospektivet från innovationsdagarna 5–7 maj är dokumenterat separat i projektets interna underlag — det är inkorporerat i hur Fas 0 och Insikt 02 är formulerade på denna sida.