Sundsvalls kommun · DigIT & IAF

Förankringssprint: Draken för alkohol och tobak

Tisdag 25 – torsdag 27 augusti 2026
Tre dagar. Verksamheten deltar i fyra block, DigIT arbetar hela dagarna.
Syfte

Vi landar processen, vi bygger inte systemet

Efter tre dagar ska processen vara överenskommen med verksamheten och lösningsmönstren dokumenterade. Det utgör bottenplattan för den två veckor långa utvecklingssprinten som följer.

Det här ska finnas på torsdag eftermiddag

  • En processmodell som verksamheten står bakom: faser, hur ärenden hänger ihop med tillstånd och serveringsställen, och vad som händer efter beslut
  • Elva lösningsmönster dokumenterade och avstämda — de listas i sin helhet under rubriken Bottenplattan längre ned
  • Backlog och avgränsning för utvecklingssprinten
  • Ett fastställt läge för varje integration: byggs, ersätts av testdata under sprinten, eller skjuts till senare

Det här kommer inte finnas

  • Ett färdigt system att börja handlägga i
  • Färdiga integrationer mot syna.se, Kivra eller P-360
  • Slutgiltig design på skärmarna
  • Beslut- och uppföljningsfaserna byggda i AI-draken
  • Svar på samtliga frågor — en del kommer att parkeras med ansvarig och datum

Förväntansbilden fastställs vid sprintens start. Båda listorna ovan gås igenom i inledningen av block 1, så att samtliga deltagare har samma bild av vad veckan resulterar i.

Överblick

Så ligger tiderna

DagVerksamhetenDigITInnehåll
Tisdag 25/8 08:30–12:00 08:30–16:30 Processmodellen
Onsdag 26/8 08:30–12:00 08:30–16:30 Ansökan från start till beslut
Torsdag 27/8 08:30–12:00
14:30–16:30
08:30–16:30 Anmälan, tillsyn, åtgärd och förnyelse, därefter avslut och retrospektiv

Varje dag inleds med standup. Under eftermiddagarna omsätter DigIT förmiddagens beslut till konfiguration och lösningsmönster, och varje förmiddag inleds med att verksamheten verifierar resultatet.

Om tidsanvändningen. Verksamhetens tid är sprintens knappaste resurs. Ett block avslutas när innehållet är genomarbetat, även om det inträffar före utsatt sluttid — den frigjorda tiden går till DigIT:s arbete. Under eftermiddagarna deltar verksamheten inte i arbetet, men ska vara nåbar för frågor som uppstår.

Dagordning

Sju block över tre dagar

Rosa markering betyder att verksamheten deltar, blå att DigIT arbetar internt. Delarna inom ett block har ingen klockslagsindelning. Varje block avslutas med en prioritering som anger vad som måste bli klart och vad som kan kortas.

Tisdag 25 augusti

Processmodellen — grunden allt annat vilar på
Med verksamheten

Block 1 · Processmodellen

08:30–12:00

Blocket resulterar i en processmodell som verksamheten står bakom: hur ett ärende rör sig genom faserna, hur ärenden hänger ihop med tillstånd och serveringsställen, och vad som händer efter att beslutet är fattat. Genomgången utgår från de fiktiva exempelärenden som finns i AI-draken.

  1. Ramar och förväntan

    Upplägget för veckan, hur blocken hänger ihop, och vad sprinten resulterar i respektive inte resulterar i. Roller och dokumentatör presenteras.

  2. Hur ärenden, tillstånd och serveringsställen hänger ihop

    Relationerna mellan organisation, serveringsställe, tillstånd och ärende fastställs. Detta styr både tillsynsprocessen och kundbilden.

    • Ett ärende per serveringsställe men samma organisationsnummer — vad är objektet och vad är ärendet?
    • Vad sker när en organisation har flera serveringsställen och ett av dem byter ägare?
    • Ska tillsynsärendet knytas till tillståndet eller till serveringsstället?
    • Vilka ärenden ska kopplas automatiskt: tillsyn, åtgärd, överklagan, ändring?
  3. Ärendets faser

    Faserna registrerat, granska, utreda, beslut och uppföljning prövas mot samtliga fyra ärendetyper. Avvikelser dokumenteras per ärendetyp.

    • Håller faserna för ansökan, anmälan, tillsyn och förnyelse?
    • Vad triggar övergången mellan faserna, och vad ska ske automatiskt vid varje övergång?
    • När ska snabbExit användas, och vad får inte kringgås med den?
    • Vilka statusar behöver handläggaren se i ärendelistan för att prioritera sitt arbete?
  4. Vad som händer efter beslutet

    Ett beviljat ärende övergår i ett tillstånd som ska förvaltas över tid. Här fastställs vad som skapas, vad kundbilden ska innehålla och vad som ska bevakas löpande.

    • Vad skapas när ett bifall registreras, och vad ska ske automatiskt?
    • Vad ska kundbilden visa, och vem konsumerar den — handläggare, inspektör eller näringsidkaren?
    • Hur representeras ett aktivt tillstånd, och vad kan förändra det över tid?
    • Vad ska ske automatiskt när tillståndet finns på plats: tillsyn, bevakning, påminnelser?
  5. Avstämning inför eftermiddagen

    Beslutsloggen läses upp och bekräftas punkt för punkt. Det som verksamheten ska möta vid onsdagens standup fastställs.

Prioritering: del 2 och 3 ska bli klara i blocket. Del 4 kan reduceras till en översiktlig genomgång och fördjupas i block 3.
Utfall: processmodellen definierad och dokumenterad, avstämd mot tillståndsstrukturen i arkitekturdokumentet
DigIT internt

Block 2 · Omsättning till lösningsmönster

13:00–16:30

Processmodellen dokumenteras som mönster och konfigureras i test där det är möjligt. Onsdagens genomgång av granska- och utredningsfasen i AI-draken förbereds.

Support Management saknar idag processmotor. En del av sprintens uppdrag är att förbereda för Operaton som processmotor i Support Management, och att fastställa vilka delar av processmodellen som motorn ska äga.

  • Vilka delar av processmodellen ska ligga i Operaton och vilka i Draken?
  • Vilka relationer mellan ärenden måste byggas, och vilka finns redan som mönster?
  • Vad krävs för att kunna köra Operaton i test- och produktionsmiljön?
  • Katla eller OpenE per e-tjänst — teknisk fråga som hanteras utanför verksamhetsblocken
Utfall: processmodellen dokumenterad som mönster, förberedelse för Operaton påbörjad, onsdagens ingång fastställd

Onsdag 26 augusti

Ansökan hela vägen igenom
Med verksamheten

Block 3 · Ansökan från start till beslut

08:30–12:00

Ansökan är den mest kompletta processen och den enda där prototypen är byggd en bra bit. Blocket består därför i huvudsak av verifiering: handläggarna kör verkliga ärenden i AI-draken och beskriver var handläggningen skulle avvika.

  1. Verifiering av tisdagens beslut

    Det som konfigurerats sedan föregående dag visas. Verksamheten bekräftar eller korrigerar innan vi går vidare.

  2. Registrera och granska
    • Räcker den förenklade bolagsdatan, och framgår styrelseengagemang tillräckligt tydligt?
    • Hur avgör en handläggare idag om någon är person med betydande inflytande, och hur kan systemet stödja det?
    • Vilka bilagekontroller är rutin och vilka kräver bedömning?
    • Vilka mallar behövs för att begära komplettering, och vem ska kunna ändra dem?
    • Hur uppmärksammas handläggaren på kopplade eller tidigare ärenden?
  3. Utreda: lämplighetsprövning och remisser

    Blockets tyngdpunkt och den mest omfattande delen av handläggningen. Delen genomförs i tre avsnitt: remisser, personlig och ekonomisk lämplighet, samt den sammanvägda bedömningen.

    • Stämmer remissinstanserna och mallarna med hur ärenden faktiskt skrivs idag?
    • Hur följs det upp att ett yttrande kommit in, och vad sker när det dröjer?
    • Kommunikationen med myndigheterna sker idag via post, e-post och säker e-post. Vad ska systemet stödja och vad förblir manuellt?
    • Vad i den ekonomiska bedömningen kan hämtas automatiskt, och vad kräver handläggarens omdöme?
    • Automatiskt meddelande vid övergång till utredning — vad ska det innehålla och vilken handläggningstid anges?
  4. Automatisering i granskning och utredning

    Här identifieras var AI och processmotorn kan avlasta handläggningen. Delen resulterar i en till två konkreta kandidater som utforskas vidare, medan övriga förslag placeras i backlog.

    • Vilka bilagor granskas rutinmässigt på ett sätt som AI skulle kunna förbereda?
    • Vilka kontroller i granskafasen är regelstyrda och kan därmed automatiseras i processmotorn?
    • Var i utredningen skulle ett AI-genererat underlag spara mest tid, och var är det olämpligt?
    • Vilket ansvar och vilken kontroll ska handläggaren alltid behålla?
  5. Beslut och uppföljning

    Faserna är inte byggda. Delen avgränsas till vad systemet ska visa och vad som ska ske automatiskt; delegationsordningen som sådan är given.

    • Vad avgör om beslutet fattas på delegation eller av individutskottet?
    • Hur hänger P-360-ärendenumret ihop med Draken-ärendet, och när skapas det?
    • Hur registreras och följs en överklagan?
    • Vad återstår i ärendet efter att beslutet är expedierat?
Prioritering: del 3 ska bli klar i blocket. Del 5 kan kortas, eftersom det mesta styrs av delegationsordning och diarieföring snarare än av verksamhetens val.
Utfall: granska- och utredningsfasen verifierade mot verkliga ärenden, automatiseringskandidater utpekade, gapen listade och prioriterade
DigIT internt

Block 4 · Ansökningsflödet och förberedelse av torsdagen

13:00–16:30

Remiss-, mall- och meddelandemönstren dokumenteras. Ärendetyperna för anmälan, tillsyn och förnyelse förbereds som tomma ärendetyper i AI-draken inför torsdagens block. De utpekade automatiseringskandidaterna bedöms tekniskt: vad som kan byggas som prototyp under sprinten och vad som hör hemma i utvecklingssprinten.

Utfall: tre mönster dokumenterade, prototypen förberedd för torsdagen, automatiseringskandidaterna tekniskt bedömda

Torsdag 27 augusti

De återstående processerna, därefter avslut
Med verksamheten

Block 5 · Anmälan, tillsyn, åtgärd och förnyelse

08:30–12:00

Fyra processer i ett block. De behandlas som varianter av processmodellen från tisdagen, inte som fyra separata genomgångar. Tillsyn och förnyelse är de processer där processmotorn har störst potential, eftersom båda är tidsstyrda och återkommande.

  1. Anmälan som variant av ansökan

    Anmälan har tunnare utredning och i regel inga remisser. Delen fastställer skillnaderna mot ansökan.

    • Folköl, e-cigaretter och nikotinprodukter — samma ärendetyp eller tre olika?
    • Vad kontrolleras i ett egenkontrollprogram, och vad av det kan automatiseras?
    • Vilka steg i ansökningsprocessen ska utgå helt?
  2. Tillsyn: inre och yttre spår

    Blockets tyngdpunkt. Tillsyn är återkommande och objektsbunden, har minst systemstöd idag och ställer flest krav på processmodellen. Delen avgränsas till behov; teknikval för fältstöd hanteras i block 6.

    • Vad triggar ett tillsynsärende — årshjul, tips, kontrollköp eller handläggarens bedömning?
    • Inre tillsyn: vilka uppgifter hämtas in, hur ofta, och vad kan processmotorn bevaka automatiskt?
    • Yttre tillsyn: vad ska inspektören kunna göra på plats, och vad räcker det att kunna se?
    • Vad sker vid bristande täckning ute i fält?
    • Kapaciteten begränsar antalet tillsyner per år — ska systemet stödja planering mot ett tak?
    • Kan protokoll och underlag förberedas automatiskt inför ett tillsynsbesök?
  3. Åtgärdsärende

    Handläggaren skapar ärendet åt näringsidkaren, som rapporterar progress men inte kan avsluta det själv.

    • Hur kopplas åtgärdsärendet till tillsynsärendet, och när kan tillsynen stängas?
    • Vad ser kunden på Mina sidor, och vad sker när en deadline passeras?
    • Hur dokumenteras bedömningen att en åtgärd är godkänd?
  4. Förnyelse, årshjul och restaurangrapport

    Underlaget innehåller en motsägelse som ska avgöras i delen: stadigvarande serveringstillstånd gäller tills vidare och förnyas inte, medan tobakstillstånd kan vara tidsbegränsade. Den återkommande skyldigheten för alkohol är restaurangrapporten senast 1 mars, som inte förekommer i processbeskrivningarna.

    • Är förnyelseprocessen i praktiken en tobaksfråga?
    • Ska restaurangrapporten hanteras som ärendetyp, och hur bevakas den?
    • Vilken förnyelseegenskap sätts per tillstånd, och vad styr den?
    • Vem påminns, när, via vilken kanal — och vad kan processmotorn driva utan handläggarinsats?
Prioritering: del 2 och 3 ska bli klara i blocket, eftersom de har minst befintligt stöd. Del 4 kan begränsas till att avgöra motsägelsen i underlaget och lämna detaljerna till utvecklingssprinten.
Utfall: de tre återstående processerna definierade som varianter av processmodellen, med fältstöd och tidsstyrning avgjorda
DigIT internt

Block 6 · Färdigställande inför slutdemo

12:00–14:30

Mönsterlistan slutförs, konfiguration genomförs där det är möjligt och demonstrationen förbereds. Teknikvalet för fältstöd avgörs utifrån behovsbilden från block 5. Blocket omfattar färdigställande av befintligt arbete; ny funktionalitet påbörjas inte, eftersom utvecklarna har avsatt tid efter sprinten för det arbetet.

Utfall: mönsterlistan komplett, demonstrationen genomgången
Med verksamheten

Block 7 · Avslut och retrospektiv

14:30–16:30

Blocket avser bekräftelse av veckans arbete. Frågor som väcks och inte kan avgöras förs till parkeringslistan.

  1. Slutdemo mot mönsterlistan

    Mönstren gås igenom punkt för punkt och visas i test där det är möjligt. Verksamheten bekräftar eller korrigerar varje punkt.

  2. Vad utvecklingssprinten levererar

    Det ska tydligt framgå vad som ligger i sprinten, vad som kommer efter och vad som är parkerat tills vidare.

  3. Retrospektiv

    Tre rubriker: framgångsfaktorer, förbättringsområden och utfall. Lappar först, samtal sedan. Avsätt sista halvtimmen.

Utfall: bottenplattan godkänd, avgränsad backlog som verksamheten sett och accepterat, retrospektivet dokumenterat
Definition of done

Bottenplattan: elva lösningsmönster

Detta är sprintens leverans. Varje mönster ska vara dokumenterat och avstämt med verksamheten innan utvecklingssprinten inleds. Listan bockas av löpande under veckan.

Innan tisdag 08:30

Förberedelser

Sprinten förutsätter att det tekniska är på plats när verksamheten kommer in i rummet. Blockupplägget ger ingen marginal för felsökning under pågående pass.

AI-drakenAnsvarig: Edwin
MiljöAnsvariga: Edwin, Tobias
UnderlagAnsvariga: Edwin, Peter
Deltagare och rollerAnsvarig: Edwin
Frågor med svar innan, inte underAnsvariga: Tobias, Andreas

Rena DigIT-frågor som besvaras före sprinten, eftersom de annars tar tid från verksamhetsblocken.

Vilka som deltar

Deltagare

DigIT
  • Edwin MolinaProcessledare
  • Lars OscarssonProduktägare
  • Peter KarlssonIT-strateg
  • Andreas CarlssonUtvecklare
  • André SöderlundUtvecklare
  • Tobias NordinUtvecklare
  • Henrik SandströmUtvecklare
IAF
  • Annika BackströmStabschef
  • Urban EdlundHandläggare
  • Annika JanssonHandläggare
  • Sara FrisentorpHandläggare
  • Linn SaltsidisHandläggare
Förhållningssätt

Så arbetar vi under sprinten

Åtta förhållningssätt som gäller genom hela veckan.

Samma rum Verksamhet och utvecklare arbetar tillsammans fysiskt under verksamhetsblocken.
Förberett i förväg Miljö, prototyp och underlag är på plats innan sprinten inleds.
Konkret ingång Varje verksamhetsblock inleds med ett ärende eller en konfiguration att utgå från, inte med en tom tavla.
Behov före lösning Under verksamhetsblocken beskrivs behov och arbetssätt. Tekniska lösningsval görs i DigIT-blocken.
Bekräftade beslut Varje block avslutas med att beslutsloggen läses upp och bekräftas punkt för punkt.
Parkering med ansvar Frågor som inte kan avgöras parkeras med ansvarig person och datum.
Verksamhetens tid först Ett block avslutas när innehållet är genomarbetat. Frigjord tid går till DigIT-arbetet.
Nåbarhet på eftermiddagen Verksamheten deltar inte i eftermiddagsarbetet men är nåbar för frågor.