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
Nio 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.
Bockarna speglar vad som faktiskt levererats i koden under sprinten (per 24 juni) — avläst direkt ur commit-historiken i de fyra repona. Varje avbockad funktion visar en kort motivering.
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✓ Levererat · nyansökan med formulärrevideringar + process
-
FORM-02
Formulär för återansökan✓ Levererat · återansökningsformulär byggt + granskat
-
FORM-03
Formulär för tilläggsansökan✓ Levererat · tilläggsansökan med normrutor + process
-
FORM-04
Skyddade personuppgifter — varning och spärrVarning på startsidan ("ska inte använda denna e-tjänst") och spärr mot att personer med skyddade personuppgifter ansöker. Komplement till IN-04c. Se Ö-01.✓ Levererat · spärr + ingen läcka av skyddad identitet
-
FORM-05
Startsida med viktig informationInformationssida innan ansökan: krav/rättigheter med länk till sundsvall.se, hur ansökan fungerar (BankID för sökande och medsökande), stickprovskontroll, korrekta uppgifter, meddelandefunktion och kontaktlänk.
-
FORM-06
Civilstånd med BankID-signeringCivilståndsval i tre alternativ (ensamstående, gift/registrerad partner, sambo). Eventuell medsökande signerar med BankID i detta steg.⚠ Byggt — civilstånd + BankID-signering (mock)
-
FORM-07
Personuppgifter och notisinställningarVisa civilstånd samt personnummer och adress för sökande och ev. medsökande. Notisfråga "Hur vill du få notiser om din ansökan?" överst med val e-post/SMS (välj minst ett) och därefter kontaktfält, med info om att ändrade uppgifter slår igenom på Mina sidor.✓ Levererat · personuppgifter + notiskanal per person
-
FORM-08
Barnuppgifter med boendegradFråga om barn under 21 år som bor helt eller delvis i hemmet, med informationstext om vilka barn som ska anges. Per barn anges hur mycket barnet bor i hemmet under ansökningsmånaden, inkl. alternativet "Annat (ange antal dagar)" med dagfält 1–31.⚠ Byggt — barn/boendegrad, verifieras
-
FORM-09
Boende — villkorad logik och boendeformFråga om boendesituationen förändrats/kommer förändras under ansökningsmånaden. Vid oförändrat: ett sammanslaget fält för antal vuxna och barn i bostaden. Vid förändring: "Välj ny boendeform" ur fast lista. Rubriken "Boende" tas bort.⚠ Byggt — boendeform + villkorad logik, verifieras
-
FORM-10
Steg "Ansökan" med normvalDöp om steget "Ekonomi" till "Ansökan" och flytta ansökningsperioden hit. Normfråga "Vilken norm ansöker du bistånd för?" med val riksnorm eller annan norm.⚠ Byggt — steg Ansökan + normval, verifieras
-
FORM-11
Kostnadsposter att ansöka omEj obligatoriska kostnadsposter med infotext och beloppsfält (hyra, el, hemförsäkring, internet, a-kassa, fackavgift, resor, sjukresor/färdtjänst, läkarvård, medicin) samt "Övrigt bistånd" via rullista med fritext.✓ Levererat · kostnadsväljare med beloppsfält
-
FORM-12
Inkomster sedan senaste ansökanFråga med dynamisk text (du/ni) om inkomster/insättningar sedan senaste ansökan, med info om vilka inkomster som inte behöver redovisas, och omdöpta inkomsttyper i rullista.⚠ Byggt — inkomster sedan senaste ansökan, verifieras
-
FORM-13
Väntande ersättningarFråga om ansökt och väntar på beslut om ny ersättning från annan myndighet/organisation, med exempelinfo samt fält för vilken ersättning och namn på den som sökt.
-
FORM-14
TillgångarFråga om tillgångar som inte informerats om tidigare, med exempelinfo. Vid "Ja" väljs tillgångstyp inkl. "Annat", och dokumentkrav visas automatiskt.⚠ Byggt — tillgångstyper, verifieras
-
FORM-15
Planering på heltid"Vilken planering har [namn]?" per sökande/medsökande med info om heltidskrav. Omdöpta alternativ (sjukskriven, SFI-studerande, annan planering) och villkorade infotexter; sjukskriven utlöser dokumentkrav.✓ Levererat · planering per sökande/medsökande
-
FORM-16
Utbetalning"Hur vill ni ha eventuellt bistånd utbetalt?" (delas lika). Per sökande/medsökande: samma utbetalningssätt/konto som föregående ansökan, annars nytt utbetalningssätt, med fritext vid "Annat".⚠ Byggt — utbetalningssätt i sammanställning, verifieras
-
FORM-17
Vistelse och försäkranVistelseintyg om att bo i och huvudsakligen befinna sig i Sundsvall under perioden, uppdaterad försäkranstext (bidragsbrott, myndighetskontroll, återbetalning) och avslutande informationsruta om meddelandefunktionen.✓ Levererat · vistelseintyg + försäkran + signering
-
FORM-18
Dynamisk bifogat-/dokumentkravsmotorBilagor styrs av gjorda val: krävs underlag visas "Du behöver bifoga följande" med punktlista automatiskt, annars fråga om bilagor behövs (nej förifyllt). Dokumentkrav per boendeform, tillgångstyp, vid sjukskrivning, akut tandvård och vid nytt bankkonto för utbetalning (underlag som visar bankens namn, kontoinnehavare och kontonummer — personspecifik text per sökande/medsökande). Tillåtna format: docx, doc, jpeg, jpg, pdf, png.⚠ Byggt — bilage-/dokumentkravsmotor, verifieras
-
IN-01
Skapa händelse/aktualisering när ansökan inkommit✓ Levererat · create-actualisation skapar aktualisering
-
IN-02
Hämta ansökan och bilagor från e-tjänsten✓ Levererat · hämtar ansökan + bilagor, samlad PDF
-
IN-03
Sök befintligt ärende✓ Levererat · gemensam ingång slår upp befintligt ärende
-
IN-04a
Styrande vägval — öppet ärende?Finns inget öppet ärende i systemet ruttas ansökan till hantering som ny ansökan.✓ Levererat · gemensam ingång ruttar till rätt flöde
-
IN-04b
Styrande vägval — huvudpersonÄr sökande och medsökande korrekt registrerade i systemet? Om nej, hantera som ny ansökan.⚠ Byggt — kontroll av huvudperson, verifieras
-
IN-04c
Sekretessmarkering — hård stoppHanteras ej automatiskt. Se Ö-01.✓ Levererat · hård stopp vid sekretess, ingen statusläcka
-
IN-05
Arkivera ansökan och bilagorSlå ihop bilagor till samlad fil. Se Ö-02 för när detta sker.✓ Levererat · bilagor slås ihop till samlad fil
-
IN-06
Processflöden per ansökningstypNy / åter / tillägg — varje flöde täcker hela kedjan inläsning → beslut → arkivering.⚠ Byggt — återansökansflödet klart; ny/tillägg delvis
-
IN-07
Löpande statusuppdateringBåde lösning och handläggare uppdateras — t.ex. när mer information inväntas.✓ Levererat · notiser + status, läs-kvitton
-
DATA-01
Initial läsning från verksamhetssystemetPersonnummer, normberäkning (inkomster, utgifter, gemensamma hushållskostnader, personer/omfattning, norm), sekretessmarkering, senaste besluten med perioder.⚠ Byggt mot spec — FC-läsning, verifieras mot riktig data
-
DATA-02
Läsning från CareManagement: pågående återansökanMed perioder.✓ Levererat · läser pågående återansökan
-
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.⚠ Byggt mot spec — SSBTEK/FK-inkomster, verifieras
-
DATA-05
Läsning från CareManagement: inkomster + utgifterFrån ansökan.✓ Levererat · läser inkomster + utgifter från ansökan
-
DATA-06
Återskrivning till CareManagement: ny normberäkning✓ Levererat · skriver ny normberäkning till CareManagement
-
DATA-07
Återskrivning till verksamhetssystemetBevakningar/notiser, journal, dokument, beslut, utbetalning (vid normalkonto) — sker initialt via RPA, processmotor som mål.✓ Levererat · arkivering av dokument till vald Lifecare-aktualisering
-
SSB-01
Läs ut samtliga inkomsterFörmån, alla delförmåner och beloppstyper.⚠ Byggt mot spec — verifieras mot riktig SSBTEK-data
-
SSB-02
Whitelist med godkända förmånerAllt utanför listan flaggas (visar förmån + delförmån + beloppstyp).⚠ Byggt mot spec — DMN-klassificering, verifieras
-
SSB-03
Definiera ansöknings-, kontroll- och jämförelseperiod⚠ Byggt mot spec — perioddefinition, verifieras
-
SSB-04
Överför inkomster i kontrollperiodenTill normberäkningen.⚠ Byggt mot spec — överför kontrollperiod, verifieras
-
SSB-05
Överför inkomster i jämförelseperiodenSom ej redan överförts.⚠ Byggt mot spec — överför jämförelseperiod, verifieras
-
SSB-06
Undantag — inkomster som varken överförs eller flaggas⚠ Byggt mot spec — undantagsregler, verifieras
-
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.⚠ Byggt — jämförelsemotor; trösklar väntar på Ö-04
-
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.⚠ Byggt mot spec — jämför mot normberäkning, verifieras
-
SSB-13
Skapa nya inkomstslag för jämförelseAnnan inkomst, PLV, underhållsstöd, lön.⚠ Byggt mot spec — nya inkomstslag, verifieras
-
NORM-01
Skapa normberäkning från ansökanStart-/slutdatum, kopiera angivna inkomster och utgifter.✓ Levererat · normberäkning skapas från ansökan
-
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.✓ Levererat · fullständighetskoll + automatiskt nytt försök
-
NORM-03
StoppfunktionHandläggare kan "ta" ansökan så lösningen inte skriver över manuellt arbete.✓ Levererat · skrivskydd så manuellt arbete inte skrivs över
-
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).⚠ Byggt — utgiftsmotor (skälighet + tak), verifieras
-
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.⚠ Byggt — utgiftsregelträd per typ (skälighetstabell), verifieras
-
FLAG-01
Flagga utifrån ansökningsfrågorÄndrad boendesituation, utbetalningssätt, nya tillgångar, vistelse i kommunen m.fl.⚠ Byggt — delta-flaggning från ansökan, verifieras
-
FLAG-02
Flagga om månadsbeslut redan finnsFör perioden.⚠ Byggt — guard som fryser återansökan vid nyligt beslut, verifieras
-
FLAG-03
Flagga avvikelse i personerMellan ansökan och normberäkning/mall.⚠ Byggt — flaggar avvikelse i personer, verifieras
-
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.✓ Levererat · speglar bevakningar/notiser (Från Lifecare)
-
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.✓ Levererat · beslutsförslag med fraser + alternativ
-
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.⚠ Byggt — utbetalningsflik; kontering väntar Ö-08/09/13
-
BES-03
KommunikationStandardmeddelandefunktion + dagens datum, ändringsbart (t.ex. digital brevlåda/papper). Vid bekräftelse utför lösningen aktiviteten.✓ Levererat · meddelande-/beslutskommunikation
-
BES-04
Meddelanden ska kunna arkiverasMellan handläggare och klient.✓ Levererat · meddelandehistorik kan arkiveras
-
EFF-01
Läs om utbetalning är effektueradI verksamhetssystemet — inkl. datum och dokument som ska visas på Mina sidor.⚠ Byggt mot spec — läser utbetalning i Lifecare, verifieras
-
EFF-02
Polling-loopUpprepa kontroll tills utbetalning är effektuerad. Se Ö-14.⚠ Byggt — polling; intervall/timeout väntar på Ö-14
-
EFF-03
Uppdatera ärendestatus i CareManagementNär effektuering bekräftats.✓ Levererat · uppdaterar ärendestatus + avsluta ärende
-
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.✓ Levererat · handläggare redigerar normberäkningen inline
-
GUI-03
Dokumentvisning på Mina sidorTaggning av dokument skrivs till administrationsverktyg och verksamhetssystem; dokumenten hämtas tillbaka för visning.⚠ Byggt — Dokument-flik; Mina sidor-visning väntar Ö-15
Öppna frågor — 15 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.
-
Ö-15
Hur ska beslut meddelas och visas för klienten?Ska handläggaren manuellt ladda upp beslut och infodokument i meddelandeflödet, eller kan det ske automatiskt? Berör BES-03 och GUI-03.
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.
Standup
Verksamhetsexperten hade gått igenom formulärutkastet för återansökan och identifierat 24 feedbackpunkter. Hur kostnader och planering bäst ska fyllas i är fortsatt oklart — möte med UX bokades under dagen för att ta tag i det. Ändringar genomfördes i CareManagement.
Levererat i kod
api-service-caremanagement
- Integration mot Lifecare FamilyCare klar: lösningen kan nu läsa ärendehistorik och skriva tillbaka beslut och normberäkning
- Hela SSBTEK-inkomstpipelinen på plats: hämtar inkomster, tillämpar kontroll- och jämförelseperiod, flaggar förändringar över 12%
- FK-inkomster (Försäkringskassan) tillagda — täcker nu huvuddelen av EB-inkomster
- Gemensam ingång klar: bedömer om en ansökan ska bli ny-, åter- eller tilläggsansökan
web-app-drakel
- Kodkvalitetsinfrastruktur på plats: testramverk, ESLint, Prettier, CI-flöden och automatiska kontroller
- Alla beroenden uppgraderade — teknisk skuld betald dag 1
web-app-business-center
- Första version av ansökningsformuläret för ekonomiskt bistånd påbörjat
- Kopplingen mot CareManagement via Dokploy-miljön på plats
Standup
Formulärändringarna för återansökan visades och godkändes av verksamheten — särskilt sektionerna för inkomster, tillgångar och utgifter, framtagna med stöd av UX. Diskuterat: stoppfunktion för ärenden där sökande eller medsökande har skyddade personuppgifter (IN-04c) och en funktion som slår ihop uppladdade bilagor till en samlad fil för arkivering (IN-05). Planerat för dagen: handläggargränssnittet (Draken) och processlogiken i processmotorn påbörjas.
Levererat i kod
api-service-caremanagement
- Inkomstpipelinen kopplad hela vägen: SSBTEK-inkomster sätts ihop till en normberäkning som skrivs till Lifecare, med varningar för ohanterade inkomster och förändringar över 12%
- Beslutsstödet syns på ärendet: normberäkningens varningar skrivs som en rekommendation till handläggaren (markeras "kräver granskning" eller "ok")
- Bilagor slås ihop till en samlad PDF när en ansökan skapas — hanterar PDF, bilder och Word (.doc/.docx), med platshållarsida så sammanslagningen aldrig krockar (kopplar till IN-05)
- Meddelandefunktionen stödjer nu filbilagor
- Skyddade personuppgifter: har sökande eller medsökande skyddad identitet erbjuds ingen ansökan — personen hänvisas till handläggare, och statusen läcker inte ut via API:t (kopplar till FORM-04 / IN-04c)
- Formulärschemat exponeras via API per ansökningstyp (ny/åter/tillägg) så frontend kan bygga formuläret utan hårdkodning
- Notisinställningar per person: sökande och medsökande kan få egna notiser, med kontaktuppgifter från Mina sidor (kopplar till FORM-07)
- Återansökan förifyller bara hushållets barn — aldrig medsökande (verksamhetsfeedback)
- Integritet: personnummer tas bort från API:ts ytterkant — parter identifieras med partyId och slås upp internt endast mot Lifecare/SSBTEK
api-service-operaton
- Byggde processmotorns normberäkningssteg: anropar CareManagement och returnerar beräknings-id och varningar så processen kan rutta ärendet till handläggargranskning
- Lade till processteg för aktualisering/arkivering och utbetalning (tills vidare som stubbar tills systemstöden finns på plats)
- Förtydligade en bärande princip i koden: processmotorn utför inga utbetalningar själv — utbetalningarna sköts av en RPA-process i Lifecare som återkopplar till lösningen. Motorn läser bara av om utbetalningen är effektuerad och väntar tills den är klar
web-app-business-center
- Byggde ut återansökningsformuläret enligt verksamhetens feedback: sammanslagna steg, separat planering för sökande och medsökande, uppdaterade boendeformer (kopplar FORM-09, FORM-15)
- Sparar kontakt- och notisinställningar per person, sökande och medsökande (kopplar FORM-07)
- Bilagor: begränsning till tillåtna filtyper och tydligare hjälptexter om vad som ska bifogas (kopplar FORM-18)
- Validering av medsökandes personnummer och koppling mot det nya endpointet för att skapa ärende
- Löpande text-, informations- och stiljusteringar i formuläret
web-app-business-center
- Medborgarens ekonomiskt bistånd-ärenden visas nu på ärendesidan på Mina sidor
- Meddelanden i ärendet stödjer bilagor (ladda upp och ner)
- Översatte (i18n) kvarvarande texter i EB-flödet
web-app-drakel
- Påbörjade handläggargränssnittet (Draken): kvalitets- och testinfrastruktur på plats och beroenden uppdaterade
- Ny "Meddelanden"-flik i handläggarens ärendevy med filbilagor, omdesignad för att matcha Mina sidor
- Säkerhetshärdning: rate-limiting på inloggnings-/SAML-endpoints och borttagen kommandoinjektionsrisk i kodgenereringen (CodeQL-fynd åtgärdade)
- Diverse gränssnittsfixar (bl.a. fullbreddsfält i ärendevyn)
Standup
Sedan sist har handläggargränssnittet (Draken) byggts vidare — förhandsgranskning av bifogade filer i meddelanden är på plats — och BPMN-processen för återansökningar har påbörjats. Sammanställningar för bilagor visades, både bilagor från ansökan och bilagor som kommit via meddelanden, och UX ombads titta på den nya designen för meddelandevyn. Planerat för dagen: fortsatt logikutveckling i BPMN-processen samt att vy och logik för normberäkning påbörjas.
Levererat i kod
api-service-caremanagement
- Ärenden får nu ett läsbart ärendenummer i formatet EB-ÅÅMM#### med månadsvis löpnummer, härlett från verksamhetens namespace
- Ekonomiskt bistånd-processen startar automatiskt vid en inkommen återansökan, och sökandeparterna sparas på ärendet
- Normberäkningen delades upp i två steg: förbered (räknas fram utan att skrivas till Lifecare, kan göras om) och verkställ (skrivs först efter handläggarens beslut) — håller principen beslutsstöd ≠ automatiskt beslut tydlig
- Utkast till normberäkning kan redigeras med skydd mot oavsiktlig överskrivning
- Inkomstvarningar blev kvitterbara objekt, och normberäkningens fullständighet jämförs mot föregående månad
- Ny payment-status-endpoint som läser av utbetalningen i Lifecare (kopplar till RPA-återkopplingen)
- create-actualisation-endpoint som skapar aktualiseringen i Lifecare
- Bilagor taggas och klientens konversation slås automatiskt ihop till en PDF; bilder normaliseras till A4 vid sammanslagning (kopplar till IN-05)
api-service-operaton
- SSBTEK-regelverket flyttades ut ur CareManagement och in i processmotorn som en DMN-driven, in-process-evaluator som klassificerar inkomster
- Ny runtime-endpoint för beslutsutvärdering
- create-actualisation- och check-payment-status-stegen anropar nu CareManagement på riktigt (inte längre stubbar) — processen läser av Lifecare-utbetalningen
- Normberäknings-workern delades i förbered (loop) + verkställ (efter beslut), och rapporterar fullständighet
web-app-business-center
- Meddelanden i ärendet visas som chattbubblor med trådning, och man kan svara på och citera ett specifikt meddelande
- Nytt färgschema-val (ljust/mörkt/följ systemet) i användarmenyn
- Mjukare bubbelfärger och bättre kontrast i mörkt läge; trådar visas äldst först
web-app-business-center
- Sparar partsuppgifter när ärendet skapas, sätter rätt ärenderubrik och förbättrad validering av personnummer
- Formuläret scrollar till toppen vid sidbyte, plus löpande formulär- och stiljusteringar
web-app-drakel
- Handläggarens meddelandevy (Draken): trådad konversation med svar, chattbubblor som skiljer egna meddelanden från sökandens, datumavdelare och svenska relativa tidsstämplar
- Ärenden kan hämtas och ruttas via ärendenummer
- Bättre kontrast på bilagor, höjd takhöjd på konversationslistan samt kod- och lintstädning
web-app-drakel
- Anteckningar (notes) på ärendet, ärendedetaljer och uppdaterad ärendetabell
- Ny bilagor-flik för bilagor som kommit via meddelanden, med räknare, samt förhandsgranskning av bilagor och PDF
Standup
Måndagens standup efter midsommarhelgen summerade torsdagens arbete (sista dagen före helgen): normberäkningsfliken är klar med tillhörande backendlogik, meddelandevyns gränssnitt förbättrades, och flikar för beslut/godkännande av ärende respektive utbetalningar är på plats. Arbetet med att minska teknisk skuld fortsätter löpande. Planerat för dagen: sätta en plan för vecka 2 — större funktioner och penseldrag prioriteras tidigt i veckan, finslipning och detaljer senare.
Levererat i kod
api-service-caremanagement
- Beslut-fliken fick sitt API: beslut kan nu sparas med belopp, beslutsmeddelande, beslutsdatum och period i en spårbar rad. Tillåtna beslutsalternativ per ärendetyp exponeras (BIFALL/DELAVSLAG med belopp, AVSLAG/AVVISNING utan), och senaste rekommenderade beslut/belopp visas på EB-vyn — beslutsstöd, inte beslut: handläggaren beslutar
- Normberäkningen formades om för att spegla Lifecare FamilyCare-kontraktet fullt ut: Familj, Inkomster, Utgifter, Levnadskostnader i övrigt och Gemensamma kostnader
- Tresektionsmodell för normberäkningsutkastet (personer · inkomster · utgifter) där processens värde hålls åtskilt från handläggarens, med mjuk borttagning som överlever den dagliga SSBTEK-uppdateringen
- Per-sektion-kvittering: handläggaren kan godkänna varje sektion (beräkning · utbetalning · beslut) var för sig, med vem/när-stämpel
- Inkomstvarningar kan återöppnas till OPEN
- Bilagor: den sammanslagna klient-PDF:en taggas med konversationsursprung och den samlade bilagelistan kan filtreras på ursprung och avsändarroll
web-app-drakel
- Ny Beslut-flik i handläggarvyn, kopplad mot CareManagements besluts-API: alternativen styr listan, rekommendationen förifyller beslut/belopp/period/datum (0 kr vid avslag) och Spara skapar beslutet
- Ny Utbetalning-flik som läser av om Lifecare-utbetalningen för ansökningsmånaden är effektuerad — visar Utbetald (med datum) / Inte utbetald ännu / Status ej tillgänglig (kopplar till RPA-återkopplingen)
- Första versionen av normberäkningsvyn, plus varningsvisning, varningsplacering och partsuppgifter på ärendet
web-app-drakel
- Designjustering av meddelandevyn: vänsterställda meddelanden i full bredd, bilagor som kompakta chips och en mjukare bubbelfärg
Standup
Tisdagens standup gick igenom gårdagens (måndag 22 juni) utveckling. Teamet gick igenom vilka funktioner som under innovationsdagarna definierades som MVP, och vad som därmed ska prioriteras resten av veckan. Kvar att leverera för MVP: hantering av dokument i lösningen, arkivering av meddelanden och hantering av nyansökningar.
Levererat i kod
api-service-caremanagement
- Journalanteckningar (ärendejournal) fick fullt CRUD med skrivskyddslås på ärendet, och Typ-katalogen för anteckningar backas nu av den centrala metadata-lookupen
- Ny metadata-endpoint för EB-typer som matar både Mina sidor och Lifecare med etiketter, grupper och medborgar-flagga (citizenReportable) — komplett handläggar-uppsättning av typer plus handläggar-only Lifecare-typer, med grupper som stabila koder (HOUSING/WORK_AND_STUDIES/HEALTH/OTHER)
- Återansökan: DMN-styrd delta-flaggning som markerar förändringar i hushållsstorlek och boende sedan förra ansökan
- Bevakningar: datumbundna bevakningsobjekt med CRUD
- Regelverksvarningar för utgifter exponeras (skälighetsprövning + tak)
- Ansökt belopp kan anges när en normutgift skapas
- Teknisk skuld: EB/Lifecare-API:t normaliserat till engelsk namngivning, databasmigrering städad, och medborgarens inkomst/kostnads-kontrakt återställt för att laga Mina sidor
web-app-drakel
- Normberäkningen lyftes rejält: typ-dropdowns hämtas nu från metadata-katalogen, utgiftskolumnerna döptes till Förslag/Godkänt, effektivt belopp kan redigeras direkt, ansökt belopp anges på ny utgiftsrad, datumväljare på inkomstrader och bevarad scrollposition vid radborttagning
- Ny flik Journalanteckningar med modal för ny anteckning
- Ny Bevakningar-sektion i sidofältet
- Beslut/godkännande: sektionsvisa kvitteringar och avsluta ärende, samt lås av en sektions innehåll när den godkänts — handläggaren godkänner, det är beslutsstöd och inte automatiserat beslut
- Regelverksvarningar för utgifter visas i vyn, svenska rolletiketter med sökanden först, och bredare ärendevy (1400px)
web-app-business-center
- Medborgarens ansökan: koder för egendom/fordon/norm linjerades med caremanagements kontrakt
Standup
Onsdagens standup gick igenom gårdagens (tisdag 23 juni) utveckling — dagen gick bra. En omprioritering gjordes: arbetet med nyansökningar pausas och teamet gick i stället över till att bygga en notifieringsfunktion för meddelanden på ärenden som handläggaren är ansvarig för. Planerat för dagen: fortsatt prioriterad utveckling enligt den nya planen. Claes och Ebba tar en dialog med Sigrid direkt efter mötet.
Levererat i kod
api-service-caremanagement
- RPA-brygga: ny rpa-modul som lägger UiPath-köobjekt för de delar av Lifecare som saknar API (bevakningar, journal, dokument, beslut, utbetalning). CareManagement styr inte Lifecare direkt — en robot utför GUI-flödet utanför processen, idempotent och avstängd som standard. Beslutsstöd ≠ automatiserat beslut: robotjobbet triggas av processen/handläggaren, och en köhickup rullar aldrig tillbaka en redan committad Lifecare-skrivning
- Händelselogg: per-ärende vem/vad/när-logg över både läsningar och skrivningar, med läsbara beskrivningar, källa och aktör (X-Sent-By), filtrerbar — loggen överlever att ärendet tas bort
- Arkivering av meddelandehistorik (MVP): en konversation arkiveras först när sökanden skickat minst ett meddelande; handläggarens bilagor finns redan i Lifecare och dubbleras inte (markeras "finns i Lifecare"), och en periodrad (första–sista meddelandedatum) läggs till
- Oläst-räknare och läskvitton för meddelanden, åtskilt från händelseloggen och exkluderat från åtkomstloggen så att pollning inte flödar den
- Per-ärende badge-räknare för anteckningar, händelser, bevakningar och aktiva varningar
- Ärendeuppgifter: sökandens ansökningssammanställning bifogas som {ärendenummer}.pdf (ett CASE_DATA-original per ärende) vid EB-skapande; handläggare sätts på ärendet från sökandens Lifecare-uppgift
api-service-operaton
- Processmotorns fetch-lifecare-supplements-worker är inte längre en stub — den triggar via CareManagements nya RPA-endpoint en robot som hämtar de Lifecare-bara tilläggen (bevakningar/notiser, journal, dokument) som SSBTEK inte bär och skriver tillbaka dem på ärendet
- Workers taggas med X-Sent-By=operaton och normberäkningens prepare/commit pekar om mot CareManagements omdöpta /calculation-väg
web-app-drakel
- Ny Händelselogg-flik som flyttades till höger sidofält som kompakta kort, filtrerbar på källa; aktören stämplas via X-Sent-By
- Ärendeflikarna grupperade i två nivåer, med flik- och sidofältsdata som lazy-laddas vid behov och sidofältsräknare via ologgade count-endpoints
- Ny Dokument-flik; bilagor kan förhandsgranskas innan de skickas, och sökande/medsökande visas högst upp på ärendet
- "Från Lifecare"-ursprungschip på bevakningar; normberäkning kräver ansökt belopp på manuell utgiftsrad och en godkänd (låst) sektion förblir läsbar
web-app-business-center
- Medborgarens ansökan: sammanställningen konsolideras i de fem wizard-grupperna plus underskrift, och förhandsvisningen renderas från samma serializer som PDF:en (identiska frågor, svar och hjälptexter), med varje inkomst/tillgång/planeringspost som egen sektion med formulärets fältetiketter
- Ansökningssammanställningen (ärendeuppgifter) bifogas som PDF vid inskick — i formulärordning med numrerade grupper och X-Sent-By mot caremanagement
Standup
Torsdagens standup gick igenom gårdagens (onsdag 24 juni) utveckling. Sedan sist: frastexter samt besluts-, rubrik- och dokumentmallar på plats, förbättringar i normberäkningen, ihopslagning av menyer på ärendet, samt sparande och visning av den rådata (frågor och svar) som ärendet skapades med. Arbetet med nyansökan och tilläggsansökan har påbörjats. Planerat för dagen: fortsatt logik för tilläggsansökan, mindre förbättringar löpande, och en eventuell koppling mot Metan för att läsa ut sökandens barn och visa dem i nyansökan.
Levererat i kod
api-service-caremanagement
- Normberäkning kan nu skapas direkt från en nyansökan
- Automatisk tilldelning av handläggare via DMN-regel (Decision_defaultAssignee)
- Oföränderlig, återrenderbar snapshot av medborgarens ansökningsformulär — rådatan (frågor och svar) som ärendet skapades med sparas och kan visas igen
- Ansökt belopp på normutgift kan redigeras, och utkastsektionerna håller stabil radordning
- Notis vid inkommande meddelande även när ärendet ännu saknar handläggare
- Ärendet stämplas med tidpunkten för den senaste dagliga körningen
api-service-operaton
- Nytt processteg (worker) som skapar normberäkningen för nyansökansprocessen
web-app-drakel
- Mallar: mallstyrd dokumenteditor (ny Templating-tjänst), redigering i WYSIWYG-editor och dokumenttext som renderas som sanerad HTML i listan
- Beslut: beslutsmeddelande-editor med frasmallar, frastexter för bifall och en samlad "Alla"-kategori, enkelval i frastext-comboboxar
- Normberäkning: ansökt belopp redigerbart på utgiftsrader, inline-sparande (on-blur) med utkastrad för nya rader som håller sin plats via serverposition, och inkomstdatum skickas som date-time
- Flikar och menyer: "Meddelanden och bilagor" lyft till toppnivåflik och uppdelad i separata Meddelanden- och Bilagor-flikar, fliklayout per ansökningstyp (ny/tillägg/åter), och flikar förblir klickbara när en sektion godkänts
- Ansökningssnapshot renderas som ärendets sammanställning, med tydligare sammanställningstitlar för bilagor
- Notiser: handläggarens notiser listas i översikten, som kan filtreras på okvitterade notiser
- Omgenererade API-kontrakt mot caremanagement samt diverse mindre fixar
web-app-business-center
- Oföränderlig formulär-snapshot som speglar den bifogade PDF:en
- Justeringar i tilläggsformuläret och fix av personnummeranrop för sambo
Standup
Fredagens standup — sprintens sista dag — gick igenom gårdagens (torsdag 25 juni) utveckling: ändringar i nyansöknings- och tilläggsformuläret, inläsning av barn till sökande från Citizen, och vidareutvecklat regelverk för utgifter. Planerat för dagen: finslipning av gränssnittet, backend för jobbstimulans och eventuellt regelverk för ansökan. Sprinten avslutas med retrospektiv 10:00–11:30.
Levererat i kod
api-service-caremanagement
- Regelverk för utgifter (verksamhetens skälighetstabell): varje EB-utgiftstyp får nu sitt eget modellerbara regelträd (hyra, hemförsäkring, … övrigt bistånd) där godkänt belopp styrs av föregående månads godkända belopp och gränsvärdet styr varningstexten — ersätter den tidigare felkopplade regeln så att taken faktiskt slår till. Sökandens ålder, antal barn och hushållsstorlek matas in i bedömningen — beslutsstöd, inte beslut
- Återansökan-guard: när en sökande (eller medsökande) nyligen haft ett EB-ärende avslutat (konfigurerbart fönster, default 30 dagar, satt med jurist) rekommenderas återansökan, och en ny ansökan fryses som "kräver manuell granskning" (ingen process/aktualisering startas) tills handläggaren öppnar den — då körs den som en vanlig återansökan
- Auto-start av nyansökan-processen för nya EB-ärenden — nu startar alla tre intagstyperna (nyansökan, återansökan, tillägg) sina processer automatiskt
- Lifecare-aktualiseringar: lista en persons aktualiseringar (personnummer-säker modell, pnr borttaget) och arkivera ett uppladdat dokument (t.ex. en tilläggsansökan) till en vald aktualisering
- Ärendelistan: sorterbart och sökbart sökandenamn; EB-statusar exponeras med svenska visningsnamn och livscykelordning, inmatade i den redigerbara metadata-katalogen
- Handläggarredigerat ansökt belopp på systemgenererade utgiftsrader bevaras över den dagliga uppdateringen
api-service-operaton
- Uppstädning: död update-errand-parameter-worker borttagen
web-app-business-center
- Nyansökningsformuläret reviderat (gäller bara nyansökan; återansökan/tillägg oförändrade): tolkfråga och boendesituation flyttade/omformulerade, "Vad avser ansökan?" och norm blev flerval, obligatorisk försörjnings-fritext, jobbsökande lägger automatiskt till planerad aktivitet + jobbansökningsrad, och egen referensdokumentlista för bilagor per sökande/medsökande
- Tilläggsformuläret: norm visas som utgiftsboxar med specifikation per norm, 80-teckens gräns + räknare på kostnadsspecifikationen, och hjälptexten "Sök endast" visas bara på nyansökan
- Barn till sökande: hämtar vårdnadsbarn från Citizen (custodychildren) för både sökande och medsökande, slås ihop med Lifecare-förifyllningen och dedupas i samma barnförslag (best-effort så en utebliven träff aldrig blockerar formuläret); åtkomstscope begärs bara för vårdnadsbarn
web-app-drakel
- Översikten körs nu helt server-side (RSQL-filter, sortering, paginering med rader per sida) med fyra vyer i sidofältet — Alla / Nya / Öppna / Avslutade — och en filterpanel med status/prioritet (flerval), borttagbara chips och olästa meddelanden. Ny Sökande-kolumn med serversortering och fritextsök på ärendenummer + sökandenamn; "Senaste aktivitet" visas i Idag/Igår-format
- Beslut: "Besluta och utbetala" renderar beslut-PDF:en, sparar den som DECISION-bilaga och skickar beslutet till valda kanaler (Mina sidor, digital brevlåda, brev) — varje kanal oberoende, misslyckade kanaler rapporteras; PDF:en visas i egen subflik och sparat beslutsmeddelande läses tillbaka i editorn med fullföljdshänvisning. Åtgärden visas bara på återansökan och när ärendet inte är avslutat
- Aktualisering: ansöknings-PDF:en kan arkiveras till en vald Lifecare-aktualisering, med aktualiserings-id i pluklistan
- Mallstyrda journalanteckningar i WYSIWYG-editorn; läsbarare form-snapshot (sektionskort, tvåkolumns fält); bredare beslutsfält med belopp-summaruta
Sprintens sista dag — ingen standup. Nedan dagens kodleverans inför slutdemo och retrospektiv.
Levererat i kod
api-service-caremanagement
- Ny läs-igenom-tjänst som serverar sökandens Lifecare-historik direkt till Draken: normberäkningar (full nedbrytning — header-summor samt inkomst-, utgifts-, särskild-utgift- och hushållsmedlemsrader), beslut (header + personer) och dokument (metadata + PDF-strömning); partyId slås upp till personnummer via citizen-tjänsten, med 24-månadersfönster som default
- Svensk lokalisering genomgående: notistyper/-undertyper, nya-meddelande-notiser, händelseloggens beskrivningar och EB-varningar fick svenska visningsnamn (plus enum-visningsnamn)
- Robusthet i EB-ansökningsinläsningen: tolererar skalärvärde där modellen väntar en lista (med tydligt parse-fel), accepterar 'request'-delen utan JSON-content-type, och errand-created-lyssnaren gör omförsök på MariaDB 11:s snapshot-isolation-race
web-app-business-center
- Fick medborgaransökans inskick att gå igenom mot caremanagement — byggde om multipart-anropet så 'request'-delen skickas som ren JSON i dokumenterat format, X-Sent-By i rätt format och normType som lista
- Barn till sökande återaktiverat via en scope:ad token (CitizenRelationAccess) som bara skickas på custodychildren-anropet, så barnförslagen ger data igen (best-effort — en utebliven träff blockerar aldrig inskicket)
web-app-drakel
- Finslipning av handläggargränssnittet: Alert-baserade varningar/status, godkänd-markering på flikar med grön alert, datumväljare i normberäkning och layoutjusteringar
- Delad och klickbar PDF-förhandsgranskning som fungerar även vid låst sektion, "Visa pdf" bredvid titeln och robustare normberäknings-PDF
- Översikten persisterar nu filter och sortering i en zustand-store (med hydration-guard)
Vad sprinten levererade
Tvåveckors-sprinten v.25–26 (15–26 juni 2026) är genomförd och avslutades med en slutdemo den 26 juni. Den följde på innovationsdagarna 5–7 maj och var det andra projektet som testade kommunens nya arbetssätt — den här gången i ett verksamhetsnära, myndighetsutövande område.
Hypotesen som testades: Att ett tvärfunktionellt team utan mellanlager — parat 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 byggdes lösningen mot API-spec med mockad data (se Insikt 01); verifiering mot riktig data sker i Fas 3.
9 arbetsdagar · 4 repon · 342 commits
Under nio arbetsdagar (två veckor minus midsommarafton) gjordes 342 commits över fyra kodrepon — web-app-drakel (144), api-service-caremanagement (109), web-app-business-center (70) och api-service-operaton (19). Av 85 funktioner i den konsoliderade listan är 28 levererade och verifierbara, 30 byggda mot spec (väntar på riktig data) och 27 ej påbörjade eller blockerade.
Vad teamet tar med sig
Retrospektivet hölls efter sprintens slut. Det är sammanställt i tre delar: vad som bar sprinten, vad som behöver finnas på plats nästa gång, och de lärdomar vi tar med oss. (Retron från innovationsdagarna 5–7 maj är dokumenterad separat och inkorporerad i hur Fas 0 och Insikt 02 är formulerade.)
- Högt i tak och öppen dialog — inga dumma frågor, alla vågade dela tankar och idéer
- Tvärfunktionellt team i samma rum (närhetsprincipen), med stort beslutsmandat hos verksamheten
- Snabb återkoppling från verksamheten och snabba API-justeringar vid behov
- Högt tempo och starkt driv — alla med och drog åt samma håll
- Förberedda miljöer och fullt fokus: heltid på uppgiften, innovationsdagarna gav fart från start
- AI till allt — "hade inte gått utan"; många commits och funktioner på kort tid
- Två veckor gav utrymme att tänka och återkomma — utan att bli för stressigt
- Riktigt verksamhetssystem och API:er att integrera mot (Lifecare, SSBTEK, RPA) — mindre mockat
- Tillgång till alla ingående delar redan innan start: API:er, systemet och en arkitekt nära
- En helhetskarta över flödet och hur tjänsten hänger ihop med andra system, innan sprinten
- Grund för hur verksamheten arbetar idag, grundmallar (dokument/journaler) och styrande designprinciper
- En yta/whiteboard för att snabbt fånga idéer och frågor i högt tempo
- Bättre koordination av parallella AI-sessioner (delade trådar krockade ibland)
- Andningsutrymme för reflektion mitt i, och samma resurser hela vägen genom projektet
Lärdomar vi tar med oss
- Rätt personer på rätt plats är avgörande — arbetssättet är kraftfullt men passar inte alla personer eller situationer.
- AI som hävstång: AI + nära verksamhet + fokuserad utveckling åstadkommer förvånansvärt mycket. Automatisera återkommande moment (egna "skills") och låt AI jobba direkt mot frontend.
- Skriv ner i tempot: i 200 % fart tappas frågor och beslut om de inte fångas direkt.
- Verksamheten visar, inte bara förklarar — det minskar kommunikationsmissarna mellan verksamhet och utvecklare.
- Allt går inte att förbereda — en del måste få växa fram under tiden, och intensiva veckor kräver inplanerad återhämtning.