Sprinten inleddes med ett tekniskt uppstartsmöte tillsammans med utvecklarna. Målet är en produktionsklar applikation om två veckor, uppdelat på två delmål: vecka 39 ska ett ansökningsärende och ett anmälningsärende kunna registreras i Katla och drivas hela vägen till beslut, vecka 40 handlar om assets, tillsyn och presentation. Minimimålet för vecka 39 är att kunna fatta ett bifallsbeslut och få ett asset-id — skalet räcker, innehållet i asseten kan landa senare.

Mötet gick igenom labelstrukturen, hur tillsyn kopplas till objekt, överklagandeflödet, förhållandet mellan processmotorn och PHASES i Support Management, samt migrering och assets som generell tjänst.

Beslut på mötet

• Labelstrukturen är spikad med tre ändringar: Okategoriserat flyttas till dokumentationsroten och blir generiskt, tillsyn delas i inre och yttre som egna ärendetyper, och tillsynsområdestaggarna utgår till förmån för assetreferenser.
• Tillsyn utförs på ett serverings- eller försäljningsställe, inte på ett enskilt tillstånd. Ett ställe kan ha flera tillstånd och en tillsyn ska kunna omfatta flera samtidigt.
• Överklagan blir en egen rot med en i princip manuell process. Beslut återöppnas aldrig — i stället skapas ett nytt ärende som pekar på det överklagade. Processkalet läggs till nu, men flödet ligger inte i dessa två veckor.
• PHASES i Support Management används inte här. Bedömningen är att fasmodellen inte tillför något utöver visualisering och att två spår ger redundant data som fronten måste hantera.
• Arbetsordning: först ett tomt ärende hela vägen genom processkalet, därefter påfyllnad av data per fas. Fronten bygger knappar för manuella steg.
• Kundbilden är avgränsad från sprinten. Eget möte på onsdag.

Arbetet i Jira

Dagen gav 20 nya ärenden på sprintbrädet, de flesta skapade direkt ur uppstartsmötet. Tyngdpunkten ligger på revisionshantering i PartyAssets, manuell stegning av processen och de luckor som lyftes kring scheman och kategorier.

Färdigställt

Till granskning

Pågående

Nytt att göra

Nytt i backloggen

Merparten av dagens nya ärenden kommer direkt ur uppstartsmötet. Sex av dem är deluppgifter under DRAKEN-4926 PartyAssets: Revisionshantering, alltså versioneringen och historiken som diskuterades.

Deluppgifter under revisionshanteringen

Frågor som kräver svar

Övrigt som lyftes

• Assets är en generell tjänst som även används för parkeringstillstånd, färdtjänst och livsmedelsanläggningar från Ecos. Olika datastrukturer talar för gemensam tabell med extra parametrar i JSON.
• Versionering av assets. En uppdatering bör skapa en ny version och låta den gamla ligga kvar. Historik är inte formellt kravställt men bedöms som indirekt krav — en krögare kan ändra serveringsansvarig via Mina sidor dagen före en anmäld tillsyn.
• Migrering av cirka 130–150 tillstånd skulle kunna göras genom en egen ärendetyp utan processtöd, med ett inmatningsgränssnitt likt det som byggts för mark och exploatering. Migrering får inte trigga utskick till kund.
• Statusrapportering. Processmotorn rapporterar status och felmeddelanden till ett processinfo-objekt i Support Management, vilket löser dagens problem att man inte ser vad ett ärende väntar på.

Dagen inleddes med laget runt. Andra halvan av mötet ägnades åt en dialog med verksamheten om hur yttre tillsyn går till i praktiken idag, och vad som krävs för att kunna göra den i Draken ute på plats.

Laget runt

• PartyAssets och tillstånden. Arbete med att kunna justera ett befintligt tillstånd, exempelvis byta serveringsansvarig, och spåra ändringarna som historik så att man ser att ett serveringsställe bytt serveringsansvarig flera gånger. Kräver omfattande ändringar i tjänsten.
• Support Management. Både manuell och automatisk start av processen. Ett ärende ska kunna skapas manuellt i gränssnittet — nytt ärende, välj typ — och processen ska antingen starta automatiskt eller först när handläggaren trycker på starta handläggning. Båda varianterna ska fungera. Det gäller starten, inte stegningen genom faserna.
• Katlan. Registrering fungerar i stort sett. Justeringar gjorda kring kategorisering och labels.
• Processläget i handläggningsdraken. En större funktion är på väg in: att kunna ta sig igenom alla steg som Support Management presenterar i processen, visa varje label som är definierad per steg, visa visuellt var ärendet befinner sig och integrera loggen. Förslag att även visa processteget per ärende i tabellvyn — det finns inte i skissen och behöver lyftas separat.
• Utökad verksamhetsbeskrivning från Bolagsverket presenteras nu visuellt. Ett ärende är upplagt för att koppla PBI:er, sätta upp roller och kunna markera och skicka in dem.
• Tillståndets innehåll. Datastrukturen för vad ett tillstånd ska bestå av arbetas igenom. En uppdaterad lista skickas till verksamheten under dagen för godkännande.
• UX. Idé om att använda stilguiden och låta AI ta fram en bruttolista inför UX-granskningen, eftersom UX-resursen är hårt belastad.

Så går yttre tillsyn till idag

• Handläggarna skriver ut protokollet och fyller i det för hand på plats, tillsammans med utskrifter av tillstånd och serveringsansvariga. Efteråt skannas protokollet in i AlkT och eventuella anmärkningar registreras.
• Det mesta bockas av som utan anmärkning. Text skrivs bara när det finns anmärkningar, och då upp till ungefär en A4-sida.
• Ute skrivs bara stödord — längre text skrivs färdigt efter hemkomst. Samtidigt är det just efterarbetet man vill komma ifrån, eftersom besöken blandas ihop när man hunnit med flera ställen.
• Bilder går att ta med men kräver omvägar idag, och fungerar inte bra.

Vad som behövs för fältläget

• Färdiga fraser att bocka i — en tes att testa, inte ett beslut. Tesen är att handläggaren bockar i färdiga meningar per protokollpunkt, med graderingar och möjlighet att ändra texten efteråt, ungefär som tillsynsappen i AlkT fungerade. Korta meningar krävs om det ska fungera på telefon. Nästa steg är att pröva den: Linn har arbetat med formuleringarna och kan bidra med underlag, och tesen får stå eller falla mot ett verkligt tillsynstillfälle.
• Enheten är en öppen fråga. Kommunen har inte stöd för programvara på paddor, bara telefoner, och paddorna saknar VPN och når därför inte interna applikationer. En laptop är opraktisk inne på trånga nattklubbar. Vikbara tvåiett-datorer ska undersökas, och telefon kan fungera om texten hålls kort.
• Ljudinspelning av tillsynen avfärdades. Hög musik på plats, och olämpligt att gäster och tillståndshavare hörs i inspelningen.

Arbetet i Jira

Utdraget från tisdagen visar rörelsen på brädet: ett ärende färdigställt, ett flyttat till granskning, två pågående och tre nya i backloggen. Två av de nya kommer direkt ur avstämningen.

Färdigställt

Till granskning

Pågående

Nytt i backloggen

Nya frågor från dagen

Laget runt följdes av en genomgång med verksamheten av den Excel som skickades ut dagen innan. Två frågor landade i beslut: hur tillfälliga tillstånd ska hanteras, och vad som behöver finnas med om matservering.

Laget runt

• Tillstånd och historik i PartyAssets. Revisionshanteringen byggs så att man kan gå tillbaka och se exakt vad som gällde vid ett givet datum, exempelvis hur ofta serveringsansvarig bytts. En knäckfråga är att ett tillstånd som skapas med tio bilagor inte ska bli tio revisioner — allt ska höra till första revisionen. Lösning finns. Nästa steg är integrationen i processmotorn: när beslut är fattat hämtas beslutet från Support Management och används mot PartyAssets för att skapa tillståndet.
• Support Management. De tio delarna som byggts var för sig syrs nu ihop till en heltäckande lösning. Andreas flaggar samtidigt för att kodbygget börjar ta lång tid, upp till 30 minuter. Orsaken är inte känd och han ska kolla vad det beror på.
• PBI. Rollkoden är uppladdad, så PBI kan sättas på ärendet via gränssnittet. Verksamhetsbeskrivningen i ärendet ska granskas.
• Frontend. Backloggen är uppsatt enligt sprintmålet och uppdateras löpande. Fokus ligger på registreringsformulären, där fälten justeras efter veckans diskussioner. Målet är att ha dem i stort sett klara den här veckan.
• Tillståndets innehåll. Ett förslag är framtaget i kombination med Folkhälsomyndighetens dokumentation, uttalat som en tes att arbeta vidare från.
• UX. En AI-baserad granskningsuppsättning byggs: skärmbilder från registreringsformulären ger en bruttolista till Sigrid, som sedan lämnar riktlinjer för vad som ska ändras. Bedömningen är att något liknande behövs i varje sprint, annars räcker inte UX-resursen till.

Beslut

• Tillfälliga tillstånd läggs parallellt med det stadigvarande. Det stadigvarande ligger kvar och löper tills det återkallas eller återlämnas. Ett tillfälligt tillstånd läggs ovanpå som ett eget tillstånd med tidsbestämd period och löper ut av sig självt — ingen behöver ändra det stadigvarande. Flera tillfälliga kan överlappa. Verksamheten ställde sig bakom upplägget, som också gör det tydligare för kunden vad som är det vanliga tillståndet och vad som är tillfälligt.
• Mat behöver inte finnas på tillståndet. Matkravet är borta i lagen och tillståndsbeviset har aldrig innehållit uppgifter om mat — det som fanns i den gamla databasen hörde till utredningen. Frågan behålls däremot i utredningen, eftersom verksamhetens karaktär påverkar bedömningen: en kvarterskrog med sittande gäster kräver annat än en nattklubb utan matservering, exempelvis i fråga om ordningsvakter och tillsynsfrekvens. Den nya e-tjänsten frågar redan om matservering och begär dryckesmeny i stället för matmeny. En enkel, icke tvingande flagga för matservering läggs ändå på tillståndet för att ta höjd, eftersom ingen ännu vet hur viktig uppgiften blir.
• Två dryckeskategorier läggs till både på tillståndet och på beslutet: andra jästa alkoholdrycker samt alkoholdrycksliknande preparat, exempelvis alkoholglass och alkoholpulver. Kryddning av spritdrycker finns sedan tidigare under anmälningar.

Arbetet i Jira

Utdraget från onsdagen visar ett färdigställt ärende, fyra till granskning, sex pågående och två nya i backloggen. Byggtiderna har fått ett eget ärende.

Färdigställt

Till granskning

Pågående

Nytt i backloggen

Öppet efter dagen

• Dialogen med Folkhälsomyndigheten om API för restaurangnummer är inte påbörjad, tas under dagen.
• Verksamheten fortsätter granska listan över tillståndets innehåll. Bygget utgår från den strukturen tills vidare, och ändringar flaggas i chatten eller på korta avstämningar.
• Andreas kollar vad de kraftigt ökade byggtiderna beror på.

Laget runt följdes av en genomgång med verksamheten av hur ett tillstånd avslutas, som underlag för vilka ärendetyper som behövs. Dagen avslutades med en avstämning av läget mot sprintmålet.

Laget runt

• Beslut till tillstånd. Kedjan mellan processtjänsten och PartyAssets implementeras. När ett beslut fattats i Support Management väcks processen, som kontrollerar om beslutet är bifall och i så fall skapar tillståndet i PartyAssets — tjänsten som äger tillståndet. Vid avslag skapas inget tillstånd, men processen går ändå vidare till nästa steg.
• Övervakning via Slack. Om processmotorn fastnar eller kastar ett fel skrivs det till en Slack-kanal, så teamet får signal om att något behöver åtgärdas manuellt. I början får man räkna med fler incidenter, för sådant ingen tagit höjd för.
• Relationer mellan ärende och tillstånd. Tjänsten för relationer mellan ärenden används nu även för relationen mellan ärendet och tillståndet, via Relations-API:t.
• Byggtiderna. Utredningen pågår och det finns ett par spår som löser problemet.
• Utredningssteget i klienten. Skalet finns så att man kan stega förbi steget, men sektionerna i lämplighetsprövningen saknas. Arbetet börjar med remisser och yttranden, som är den största sektionen, och fortsätter med personlig lämplighet, ekonomisk lämplighet, kunskapskrav, lokal och serveringsställe, samt den sammanvägda bedömningen som krävs för att gå vidare till beslut och uppföljning.
• Registreringsformulären. Arbete både med inskickning av ärenden och med motsvarande del i handläggargränssnittet, så att fälten visas rätt. Ett kvarstående fel är att schemat inte gör vissa fält obligatoriska trots att de borde vara det — exporten från OpenE blev inte komplett. Rättningen slår igenom både i Draken och i registreringsformuläret.
• Draft i Katlan. En sökande ska kunna spara en påbörjad ansökan och fortsätta senare, när alla uppgifter inte finns till hands. Funktionen ska utvecklas.

Hur ett tillstånd avslutas

Status och prioritering

Verksamheten frågade om arbetet ligger i fas. Bedömningen är ja, och fronten går framåt. Utredningsfasen är samtidigt omfattande, och teamet flaggar i tid om den riskerar att dra ut.

• Prioritering för vecka 39: ta sig igenom alla faser med tomt skal, hellre än att färdigställa utredningsdelen. Verksamhetens input kommer ändå att ändra fälten — dagens utredningsmall är AI-genererad och behöver kompletteras.
• Målbilden ligger fast: registrera ett tillståndsärende, driva det till beslut och skapa skalet till en asset, även med tomma steg.
• Förslag: testa hela kedjan med automatiska steg, exempelvis ett folkölsärende som går igenom alla steg av sig självt och landar direkt i uppföljning. Då syns eventuella luckor utan att någon klickar sig igenom gränssnittet manuellt.
• Demo på måndag i en förlängd avstämning. Sikte på att verksamheten börjar testa registrering under nästa vecka.

Arbetet i Jira

Utdraget torsdag kl. 15:57 omfattar 40 ärenden. Nitton är färdigställda, däribland hela raden av arbetssteg i Support Management och pw-alkt som byggts sedan den tekniska sprinten, samt revisionshanteringen i PartyAssets.

Färdigställt

Till granskning

Pågående

Att göra

Nytt i backloggen

Följer med sedan tidigare

Sista dagen i vecka 39. Laget runt visade att kedjan hänger ihop, och därefter diskuterades två frågor som kommit upp under veckan: om ett ärende ska kunna avbrytas, och hur helt automatiska ärenden ska synas för verksamheten.

Laget runt

• Vecka 39 är i praktiken i mål. Ärenden kan registreras i Katlan, hanteras i gränssnittet och avslutas, och ett ärende kan stegas igenom processmotorn hela vägen. Bedömningen är att sprintmålet är uppfyllt, med reservationen att det inte är bekräftat ännu.
• Nästa steg är tillsynsdelarna, som är omfattande. Förberedelserna är påbörjade.
• Registreringsformuläret. Två sidor av samma sak: att få in ett ärende i processen, och att få in all information som behövs på ärendet. Under dagen syddes delarna ihop så att formuläret blir hyfsat komplett och ett sådant ärende kan tas genom processen.
• Folköl som semi-automatiskt flöde. Processen skapar beslutet automatiskt, agerar på det, skapar tillstånd för försäljning eller servering av folköl, och ärendet landar i uppföljning. Runt omkring pågår mycket småfix i PartyAssets: vilken information som ska följa med från ärendet ned till tillståndet, och i vilken form den sparas.
• Support Management. Två större ändringar är inne och en funktion provades på morgonen. Parallellt körs avvikelse- och LCM-spåren in löpande. Planen är att samla allt i en gemensam branch och ta en release under veckan.
• Attribut som dyker upp längs vägen. Nya attribut upptäcks efter hand, och en ny API-version per enskilt tillägg ger mycket overhead. Slutsatsen är att samla ihop dem och ta dem i ett svep.
• Demon på måndag körs mot testmiljön snarare än lokalt, så att verksamheten kan klicka runt själva. Testmiljön uppdateras kontinuerligt.

Ska man kunna avbryta ett ärende?

Frågan kom upp eftersom det redan går att pausa ett ärende. Att avbryta innebär tekniskt att processen dödas — ärendet kan inte återupptas, utan ett nytt måste skapas.

• Verksamheten vill inte fatta avslagsbeslut för sådant som aldrig var menat som en ansökan. Vanligaste fallet är att en sökande skickar in en ny ansökan i stället för en komplettering, så att två ligger parallellt. Då vill man kunna plocka bort den felaktiga och notera "enligt överenskommelse" som spår, i stället för att lägga administrativ tid på ett beslut.
• Sökanden ska inte kunna avbryta själv under ärendets gång — dels för att en avgift uppstått, dels för att någon annars kan dra tillbaka sin ansökan när det står klart att den inte kommer beviljas. Det är handläggaren som tar bort.
• Före påbörjad handläggning kan kunden eventuellt avbryta via Mina sidor. Därefter sker det via dialog med handläggaren.
• Motsvarigheten finns redan i MEX och parkeringstillstånd som en snabb exit, som avslutar ärendet utan att leda till beslut.

Automatiska ärenden och notifieringar

• Märkning av maskinhandlagda ärenden. Ärenden bör märkas som manuella eller automatiska, och handläggaren blir sannolikt ett tjänstekonto snarare än en person.
• Varför ärendet stannar i uppföljning. Dels för att faktureringen inte finns på plats ännu, dels för att verksamheten vill se att anmälan kommit in. Kom det in fyra folkölsanmälningar över helgen vill de veta det, så att de snabbt kan besöka stället och gå igenom egenkontrollprogrammet.
• Notifiering till Mina sidor vid fasövergång ingick inte i vecka 39. Att skicka meddelanden fungerar redan; det som saknas är den automatiska notifieringen när exempelvis utredning startar. Här behövs finlir — inget pling för varje fas i en folkölsprocess som tar millisekunder, men väl vid en ansökan om stadigvarande serveringstillstånd när ansökan bedömts komplett och handläggningen påbörjas.

Arbetet i Jira

Utdraget togs måndag morgon och visar rörelsen sedan torsdagen: sju ärenden färdigställda och tre pågående. Schemaspåret är stängt — både korrigeringarna och de obligatoriska fälten — liksom SM-A12, det sista arbetssteget i Support Management.

Färdigställt

Pågående

Första dagen i vecka 40. Avstämning följd av demo mot testmiljön, där ett ärende följdes från registrering i Katlan till avslut i handläggargränssnittet.

Namnändringar att skapa lappar på

Att rätta i e-tjänstens schema

• Fel version av schemat ligger inne. Formuläret visade frågor om mat, som är borttagna i den nya e-tjänsten. Filen hette "ny" men verkar ändå vara en äldre variant — stäms av med Marc.
• Tre år ska vara fem år. En fråga anger senaste tre åren, men föreskrifterna är ändrade till fem.
• Bilagekrav för föreningar saknas. Är sökanden en förening ska stadgar och konstituerande styrelseprotokoll krävas, annars är ansökan inte komplett. Kopplingen mellan ärendetyp och obligatoriska bilagor styrs av schemat.

Demon

Genomgången följde ett ärende från registrering till avslut. Registreringsformuläret fungerar: inloggning, val av organisation ur personens bolagsengagemang, tillägg av övriga parter, ifyllnad, bilagor med kategori och inskick. Den som inte är firmatecknare kan ansöka men måste ladda upp fullmakt.

I handläggargränssnittet syns ärendet under Nya ärenden, med grundinformation, ärendeuppgifter, förenklad bolagsdata från Bolagsverket och möjlighet att markera en person som PBI. Därefter granskning, inledd utredning, beslut och uppföljning, med processteget synligt överst och flikarna som låses upp allteftersom.

Synpunkter från verksamheten

• Sökfunktion i bolagslistan. Vissa personer har 400 eller fler bolagsengagemang. Listan behöver kunna filtreras. Datan ska kollas upp först.
• Bilagornas typ syns inte i handläggargränssnittet, bara filnamnet. Kategorin eller etiketten måste följa med, eftersom granskningen går ut på att kontrollera att rätt dokument skickats in.
• Lagrum behövs i utredningen, och det är andra lagrum än i beslutet. I utredningen hänvisas exempelvis till 8:22 vid catering och lättdrycker, medan beslutet grundas på 8:2. Kräver en egen sektion.
• Beslut måste kunna sparas som utkast. Idag låses beslutet när det sparas, vilket inte fungerar om handläggaren behöver lämna datorn. Sparat ska inte betyda skickat.
• Tillståndsbeviset genereras som PDF i beslutsdelen utifrån den exempelfil som skickats. Verksamheten skickar in ett verkligt tillståndsbevis så att mallen kan byggas mot hur det ser ut idag. Beslut och bevis ska bli tillgängliga direkt på Mina sidor.
• Automatiskt meddelande när utredning startar är inte implementerat. Det är vid den tidpunkten servicetiden börjar räknas.

Arbetet i Jira

Utdraget kl. 16:05 visar 26 ärenden i rörelse: tretton färdigställda, ett till granskning, åtta pågående, ett att göra och tre nya i backloggen. Flera av dem svarar direkt mot det som kom upp i demon.

Färdigställt

Till granskning

Pågående

Att göra

Nytt i backloggen

Beslut och veckans inriktning

• Snabb exit ska gå att göra oavsett var i processen ärendet står. Ärendet avslutas då utan att följa processen vidare. Ligger som PR tillsammans med buggfixar.
• Knappen att återuppta eller inleda utredning på ett avslutat ärende ska bort. Däremot väcktes tanken att kunna starta en tillsyn direkt från ett anmälningsärende.
• Veckans mål: fixa buggarna från fredagen, påbörja tillsynsprocessen, och gå igenom vilka ärendetyper som faktiskt ska finnas — en Excel tas fram som verksamheten får bekräfta eller dementera.
• Verksamheten får testmiljön under veckan för att klicka runt själva. Innan dess återstår arbete med texter och språk, som idag är handläggardrivet.
• UX-granskningen med Sigrid har en risk: ändringar slår mot befintliga produktionsappar, särskilt avvikelse som byggts enligt det nya. Det behöver samlas i en leveransplan innan något ändras.

Avstämningen handlade om tillståndsbeviset — hur det genereras och vad som ska stå på det — och mynnade ut i att verksamheten fick åtkomst till registreringsformulären för att granska frågorna.

Laget runt

• Tillståndsbevis skapas automatiskt. Mallarna byggs i templating-tjänsten och integrationen mot processmotorn är inlagd, så beviset genereras när beslutet fattas — för både tobak och alkohol, försäljning som servering.
• Restaurangnummer. Fix i tjänsten så att den fungerar som flödet kräver.
• Ny version av attributen är släppt, med buggfixar som behövs för processmotorns signalhantering.
• Byggtiderna. En optimering är hittad som kortar byggtiden med 57 procent. Arbetet fortsätter, men det var den stora vinsten.
• Funktionsbrevlådorna för alkohol och tobak är på väg ut.
• Utkast och bilagekategorier. I registreringsformuläret går det nu att spara ett utkast och fortsätta senare, och att ange kategori per bilaga vid inskick. Kategorin speglas ännu inte i Draken, det återstår att bygga.
• Kundbilden finns i en mycket basal form: man kan gå in på en organisation och se vilka tillstånd den har.
• Nästa steg är serveringsställen — adressen ska matcha mot ett serverings- eller försäljningsställe och fyllas i Draken därifrån.

Beslut

• Tillståndsbeviset får ingen underskrift. Uppfattningen är att myndighetsdokument inte behöver undertecknas på det sättet, även om det formella läget är osäkert — mycket få dokument kräver signering. Skulle det krävas vore e-signering rätt väg; att skriva ut, skriva under och skanna in tar bort hela digitaliseringen. Beviset anger i stället vem som är beslutsfattare och vem det är utfärdat av. Tesen är att det räcker, och den behöver bekräftas.
• E-postadressen på beviset behålls, telefonnumret tas bort i stället. Förslaget var att ta bort mejladressen för att inte uppmuntra mejl, men verksamheten tar hellre emot mejl än samtal. Avgörande är att mejl till funktionsbrevlådan kommer in i Draken som ärenden, så ingen behöver gräva i en mejllåda.
• Felaktiga frågor rättas i vårt eget registreringsformulär, inte i e-tjänsten. Avstämningen med Marc bekräftade att vi har den senaste versionen, men den innehåller ändå frågor som inte borde vara med. I stället för att vänta på rättningar i e-tjänsten rättar vi i Katlan.

Testrunda för verksamheten

Verksamheten fick åtkomst till registreringsformulären under förmiddagen och loggar in som testpersonen Karin Andersson, som har företag i testmiljön.

• Dela upp arbetet — hälften tittar på tobak, hälften på alkohol.
• Fokus är frågorna: är det rätt frågor, vilka ska bort, och är någon felaktigt formulerad?
• Kommentarer samlas på en enkel sida i Teams-kanalen, så att dokumentationen börjar byggas.
• Uppföljning onsdag klockan tio. Frågorna behöver vara genomgångna senast då, eftersom nästa runda fokuserar på handläggningsgränssnittet.

Öppet

• Registreringsformuläret är en lång scroll. Idén är att dela upp det i hopfällbara kapitel, ungefär som utredningsfliken — företagsinformation, tillståndsinformation och så vidare. Tekniskt kan det innebära flera json-scheman, särskilt om mobilanvändning ska ske i flera steg, medan desktop kan visa dem sammanställda.
• Mobilanvändningen är okänd. Ingen i verksamheten vet hur stor andel som använder e-tjänsten via mobil, och inga klagomål har nått dem, vilket tolkas som att det fungerar hyfsat. Det finns sannolikt data att hämta.

Arbetet i Jira

Utdraget kl. 15:58 visar 23 ärenden i rörelse: tre färdigställda, fem till granskning, åtta pågående, tre att göra, tre i backloggen och ett som avförts.

Färdigställt

Till granskning

Pågående

Att göra

Backlog

Avfört

Efter laget runt ägnades mötet åt cateringtillstånd — ett område som till stor del var nytt för utvecklingssidan — och åt när ett restaurangnummer ska skapas.

Laget runt

• Tillståndsbeviset. Mallarna i templating är i praktiken klara: beviset skapas direkt när beslutet fattas och ser ut som dagens bevis, minus underskriften. En idé kom upp — förhandsvisning av beviset i beslutssteget, så att handläggaren ser hur beviset blir innan hen klickar bifall.
• Serveringsställen. Arbetet med att hämta ut vilka serveringsställen som finns på en adress eller organisation fortsätter.
• Flikarna mappas mot processens steg, så att innehållet renderas utifrån vilken fas ärendet står i. Innehållet per steg är inte färdigt, men man ska kunna ta sig igenom den automatiserade folkölsprocessen och ett stadigvarande ärende. Målet är att ha det på plats före demon.
• Funktionsbrevlådorna är konfigurerade i Support Management och testade — mejl kommer in som de ska. En knapp för att svara eller skicka meddelande fungerade inte och återstår.
• Byggtidsfixen är släppt och kapar mycket av byggtiden.
• Buggfixarna från fredagen är i stort sett ute, en återstår. Tempot är högt och granskningskön växer.
• Testrundan på registreringsformuläret gav en lugnare känsla — det viktigaste är att rätt uppgifter kommer in, och den biten är avbetad. En motsvarande runda för handläggningsgränssnittet behövs men bedöms inte hinnas med den här veckan.
• Dokumentation av tillsynsprocessen och åtgärdsärenden pågår: vad som händer i respektive steg, kompletterat med vad som sker i gränssnittet och vad processen ska hantera.
• Bilagor per ärendetyp ska dokumenteras. Vissa krävs alltid, andra är villkorade — fullmakt krävs exempelvis bara om sökanden inte är firmatecknare. Någon färdig sammanställning finns inte idag, så den tas fram nu tillsammans med verksamheten.

Catering

• Cateringtillstånd är ett eget stadigvarande tillstånd. Det måste sökas särskilt, men kan utredas tillsammans med en ansökan om stadigvarande serveringstillstånd. Tekniskt blir det två separata tillstånd, så att alla kombinationer kan hanteras — både stadigvarande och catering, eller bara catering.
• Varje cateringtillfälle måste anmälas. Tillståndshavaren anmäler var sällskapet ska vara och kommunen godkänner lokalen. Ny lokal kräver utredning och remiss till räddningstjänsten; kända lokaler och kommunens egna är redan godkända. Det gäller bara slutna sällskap, och en avgift tas ut — därför måste anmälan registreras.
• Anmälan automatiseras inte i första versionen. Systemet kan inte avgöra om lokalen är ny eller redan godkänd, och vid ny lokal hamnar ärendet i utredning med remisshantering. Den får vara manuell tills vidare, och automatisering utvärderas senare.
• Anmälan hör hemma på Mina sidor, inte i Katlan. Tillståndshavaren har redan sitt cateringtillstånd, så anmälan bör utgå från det befintliga tillståndet och kopplas till det som en relation, i stället för att börja som en ny ansökan.

Restaurangnummer

Verksamheten läste upp Folkhälsomyndighetens besked från 29 maj 2026: restaurangnummer ska fortsätta vara en uppgift i tillståndsbeviset, begreppet behålls även när andra verksamheter än restauranger får serveringstillstånd, numret tilldelas serveringsstället vid beslut om stadigvarande tillstånd och följer lokalen genom ägarbyten — och även cateringtillstånd ska tilldelas restaurangnummer.

• Cateringföretag utan lokal får numret knutet till företagets adress.
• Ett bolag får ett restaurangnummer oavsett hur många vagnar eller enheter det har, eftersom numret hör till tillståndshavaren.
• Numret skapas när beslut om bifall fattas, alltså när tillståndet tillverkas. Inte tidigare — annars riskerar man nummer på adresser där ärendet slutade med avslag.

Arbetet i Jira

Utdraget visar elva ärenden i rörelse: tre färdigställda, fyra till granskning och fyra pågående.

Färdigställt

Till granskning

Pågående

Vanlig avstämning med laget runt. Därefter togs frågan om vad som egentligen ska gå att ändra på ett redan utfärdat tillstånd — och slutsatsen att det inte finns dokumenterat någonstans.

Laget runt

• Decision-objektet har utökats med fler parameterstrukturer, så att fria nycklar och värden kan sparas. Släpps under dagen och blir API-version 16.3.
• Publiceringen strulade mycket. En central del hade gått sönder sedan en version uppdaterats och inte längre var kompatibel, vilket tog tid innan något kunde publiceras.
• Templating för tillståndsbevis och förhandsgranskning är ute, tillsammans med de buggfixar som flaggats — fel roll och fel status in på beslut. Även krocken med PDF-hanteringen ska vara löst.
• Adressen sparas nu på företaget när uppgifterna registreras i registreringsformuläret. Det fanns en lucka där som är åtgärdad.
• Restaurangnamnet hämtas från LicensedBusiness så att det visas. Inte påslaget överallt, men det finns en version där det syns.
• Processhanteringen gicks igenom tillsammans, så att fler än den som byggt den förstår vad som händer i den.
• Tillgänglighet och tillsynsprocessen samt tillägg och ändring av stadigvarande serveringstillstånd ligger kvar att göra.

Serveringsställen

• Adressen i formuläret används för uppslaget. Har sökanden angett att adressen är samma som företagets kan den användas för att söka fram serveringsstället — eller så söker man på adressen direkt och får se vilka restauranger som finns där och vilka som är aktiva.
• Att välja ett av dem är inte byggt än.
• Restaurangnumret skapas vid beslut, inte när ärendet startas — annars får man nummer på adresser där ärendet slutade med avslag.

Processloggen

Den förbättrade processloggen är deployad. Den visar både den tekniska informationen och en läsbar text för vad som faktiskt hänt — exempelvis att tillståndet skapades — med tekniska detaljer bakom ett klick. Nästa steg är att titta på hur den ska presenteras i gränssnittet: vilken fas ärendet befinner sig i, vad som händer i fasen och vad som är relevant för användaren. Ett förslag finns framtaget.

Processhanteringen gav en del strul när ett ärende sätts upp av en handläggare i Draken i stället för att komma in via Katlan. Mycket är åtgärdat, scopet växte och bröts ut i flera ärenden.

Ändringar på befintligt tillstånd

• Det finns ingen dokumentation över vad som får ändras på ett stadigvarande serveringstillstånd, ett tobakstillstånd och så vidare. Hittills har teamet gissat.
• Omfattningen av handläggning varierar helt med vad som ändras. Ett bolag som byter e-postadress är en enkel ändring; en större serveringsyta kräver betydligt mer handläggning.
• Ett arbetsmöte bokas samma dag kl. 11–12 för att dokumentera detta tillsammans med verksamheten. Underlaget behövs även för Mina sidor — det som företagen kan göra själva ska kunna göras direkt där.

Arbetsform och textändringar

• Textändringar samlas i ett eget avsnitt i anteckningarna och läggs i backloggen. Fokus ligger på funktionalitet nu, men ändringarna sparas och görs vid tillfälle. Fler kommer.
• Testrundan med verksamheten gav bra utfall. Mötet spelades in och protokollet bearbetades till ett underlag för ändringarna, uppdelat i överskådliga delar. Arbetsformen ska förfinas och användas framåt.
• Registreringsformulären bedöms genomgångna. Nu flyttas fokus till handläggningen, och när det känns tryggt bjuds verksamheten in för att klicka igenom och dokumentera tillsammans.
• Hela handläggningsgränssnittet hinns sannolikt inte med den här veckan — två dagar återstår. Minst en ärendetyp bör dock hinnas med, för att få en känsla för om processen är rätt uppsatt utifrån verksamhetens perspektiv.

Folkhälsomyndigheten

Kontaktförsöken fortsätter utan svar. Dokumentation för API:et är efterfrågad.

Sprintens sista dag. Efter laget runt visade verksamheten hur remisserna faktiskt hanteras i AlkT idag — en genomgång som ändrade bilden av vad som behöver byggas.

Laget runt

• Ändrings- och tilläggsärendena tog gårdagen, tillsammans med mallarna. Underlag har kommit från verksamheten och det finns en väg framåt. Arbetet fortsätter primärt med pw-alkt och processmotorn.
• Ny ärendekategori och processmodell för catering lades in i samband med releasen av Support Management, tillsammans med det som kommer från LCM-spåret.
• De nya parametrarna på utredningen är påbörjade.
• Serveringsställen är i praktiken klara — det går att spara serveringsstället på ett beslut. En mindre detalj återstår att kontrollera.
• Ändringarna i registreringsformuläret börjar betas av utifrån dokumentet från testrundan.
• Remisserna fortsätter, med fokus på hur svaren taggas och sorteras i Support Management kopplat till de uppladdade filerna. Remissdelen ska vara färdig till demon.
• Pollingen mot processmotorn gav problem i den interna demon. En fråga har gått till utvecklingssidan om hur den kan optimeras, och en fix är uppsatt som åtminstone tar ett steg på vägen.

Bilagor och remissvar

Frågan ställdes om bilagefliken redan nu ska visa samhörigheten mellan remiss och svar. Första versionen hålls enkel: där visas bara att det finns bilagetyper som polisremiss, remiss till Tullverket och så vidare. Kopplingen mellan remiss och svar visas i remissblocken, där den blir tydlig. Mer metadata på bilagorna kan komma på sikt.

Så ser remissarbetet ut idag

• Handläggaren fyller i väldigt lite. Namn på bolaget och de personer som är aktuella — namn och organisationsnummer, eller namn och personnummer. Resten fyller Skatteverket i.
• Ägarbilden ska följa med in i mallen. I AlkT markeras vilka som är PBI på en av flikarna i ägarbilden, och de ska kopplas och följa med in i mallen. Det fungerar sällan i praktiken.
• Närstående bolag fylls i manuellt. De kan bli många, och uppgifterna skrivs av eller kopieras in för hand. Därefter PDF:as blanketten och mejlas till Skatteverket.
• Blanketterna växer. Utrymmen kopieras in för att få plats med fler bolag — rekordet är 28 sidor på en skatteverksremiss. En person kan vara aktiv i flera hundra bolag, så handläggaren gör ett urval.
• Svaret blir ofta större än remissen. Skatteverket svarar handskrivet eller datorskrivet, bifogar kopior på beslut om skattetillägg och skickar bilagor när allt inte får plats.

Slutsatser för bygget

• Mindre inmatning än väntat. Det handläggarna behöver kunna ändra är namn, bolag, organisations- eller personnummer, datum och vem som är handläggare. Övrigt kan förifyllas från ärendet.
• Format får inte ändras på två av remisserna. Skatteverkets remiss och polisens utdrag ur belastningsregistret är myndigheterna mycket noga med. Övriga remisser är egna, enkla blanketter där utseendet inte är lika känsligt.
• Ett fåtal fält på webbsidan är enklaste vägen — fälten skickas in i mallen som renderar PDF:en, på samma sätt som tillståndsbeviset. För formulär som varierar i storlek men inte i komplexitet kan JSON Schema rendera HTML i webbläsaren, som i sin tur skickas till templating för PDF.
• Ifyllbart PDF-formulär utreds som alternativ, eftersom det bevarar formalian i myndigheternas blanketter och ändå kan förifyllas programmatiskt.
• Varje mall behöver gås igenom — sex mallar har lämnats över, men det finns fler. Per remiss ska det avgöras vilken data som ska in och om handläggaren behöver en texteditor, enbart inmatningsfält eller ingenting alls.
• Metodiken är densamma oavsett teknisk lösning. En PDF skapas, läggs som bilaga på ärendet och visas i remisskortet — både det som skickas ut och svaret som kommer in. Till demon körs den lösning som finns idag.

Uppslagning av bolagsengagemang

• Alla personer slås inte upp automatiskt — det blir för många anrop. Handläggaren markerar vilka som är intressanta och de slås upp.
• Rollen i bolaget finns i förenklad bolagsdata, men varje person kräver en egen fråga. En bulkfråga vore önskvärd och tas upp med Bolagsverket.
• Ägarkedjor kan gå i flera led — moderbolag med dotterbolag som i sin tur har dotterbolag. Det är personerna som knyter ihop bilden; bolagsrelationer syns inte i dagens data.
• Verklig huvudman ska finnas i Bolagsverkets data. Att den faktiskt kommer med är inte verifierat.

Ändringar på befintligt tillstånd

Gårdagens möte med verksamheten gav ett bra underlag, och en första skiss är påbörjad. Fokus idag ligger på hur ändringarna presenteras UX-mässigt och hur de ska taggas datamässigt. Målet är en version 1.0 att visa på eftermiddagen, som nästa vecka kan arbetas vidare på. Det är en viktig del av leveransen — att tillståndshavaren själv ska kunna hantera ändringar via Mina sidor.

Demo och retrospektiv

På eftermiddagen hölls demo av sprintens resultat, följd av en retrospektiv.

Demo — registreringsformuläret

• Ordvalsändringarna från testrundan är införda. Medborgaren loggar in med BankID och väljer ärendetyp, varefter rätt formulär visas. Gårdsförsäljning demades.
• Företag hämtas från inloggningen — de bolag personen har engagemang i. Personer kan läggas till manuellt.
• Bilagor markeras i rött när de saknas, och kategorierna är åtta till tio stycken, härledda ur formuläret. Flera filer kan laddas upp per kategori.
• Två frågor togs upp: om det behövs en övrigt-kategori för sådant sökanden vill skicka med utöver listan, och om formuläret kan förenklas genom att bilagor som uppenbart inte behövs väljs bort.

Demo — handläggningsgränssnittet

• Serveringsställen på adressen visas i ärendet — både aktiva och tidigare, med restaurangnummer.
• Förenklad bolagsdata längst ned. Handläggaren markerar vilka som har betydande intresse, och de läggs till som kontaktpersoner på ärendet. Några buggar återstår där.
• Flikarna följer processens fas och visar vilket steg ärendet står i.
• Utredningsfliken har remissinstanser, datum och utskick. Remissen sparas som bilaga på ärendet och svaret laddas upp.
• Beslutsfliken har beslut, motivering och villkor, plus serveringsställesektionen där handläggaren väljer befintligt serveringsställe eller skapar ett nytt. Kopplingen till processmotorn vid beslut är inte byggd i bakgrunden än.
• Tillståndsbeviset går att förhandsgranska innan beslut, med röd text som visar att det inte är ett fattat beslut. Beviset kan skrivas ut som PDF.
• QR-kod på beviset leder till Mina sidor, i linje med att flytta självservicen dit — exempelvis anmälan av serveringsansvarig.
• Versionshantering av beviset. Vid namnbyte utfärdas ett nytt bevis som version två, och historiken går att följa bakåt.

Demo — beslutstyper

• Delvis avslag måste kunna hanteras. Man kan få avslag på sprit men bifall i övrigt, avslag på en del av serveringstiden, eller bifall med villkor som vakter eller bordsservering.
• Det måste framgå tydligt i beslutet vad som bifallits och vad som avslagits, eftersom avslaget ska kunna överklagas. Jämförelsen gjordes med färdtjänst, som har en egen beslutstyp för detta.
• Ett beslut, inte två — men med bifall och avslag separerade i dokumentet.

Demo — remisser

• Flödet följer en logik för att stega vidare, med olika mottagare, löpnummer och taggar så att varje remiss kan följas upp. Medelpads räddningstjänstförbund användes som exempel.
• Det ska gå att se vilka remisser som är besvarade och var svaret placerats.
• Texteditorn kommer att förändras när HTML-hanteringen görs om, men flödet är detsamma.
• Bilagor som ska följa med remissen — exempelvis ritningar till räddningstjänsten — är inte byggt än.

Demo — tillsyn och åtgärd

• Åtgärdsärendet skapas automatiskt när tillsynen avslutas, som en separat process kopplad till tillsynen.
• Anmäld och oanmäld tillsyn hanteras, och åtgärdsärendet visas för tillståndshavaren på Mina sidor.

Demo — Mina sidor

Det som visades är en AI-skiss, inte byggd funktionalitet. Skissen kommer att fungera som mall för utvecklingen.

• Tillstånd och avtal samlas under Beslut och dokument och ska rymma allt kunden fått av kommunen, inte bara serveringstillstånd.
• Ett tillstånd visar övergripande information med resten nedladdningsbart som PDF.
• Anmäl förändring är ett formulär grupperat utifrån kundens perspektiv — serveringsställe, företag, tider, spritsorter. Kryssar kunden i vad som ska ändras aktiveras bara relevanta frågor och bilagor.
• Kostnaden måste synas. Kunden behöver förstå att en ändring kostar pengar innan den skickas in, och att en anmälan inte är ett beslut utan något som granskas. Hjälptexter och ett kostnadsbesked efterfrågades.
• Ändringar hamnar som nytt ärende i Draken.

Utfall av utvecklingssprinten

• Vecka 39 nådde målet — att kunna skapa ett ärende hela vägen in i systemet.
• Vecka 40 hade som mål att handlägga hela vägen, visa tillståndet och visa det på Mina sidor. Flödet går att ta sig igenom, men delar är inte färdiga i bakgrunden.
• Förutsättningarna för självservice finns, och ett förslag presenterades för hur kunden själv ska kunna hantera ändringar.
• Tillsyn och åtgärd är osäkrast. Åtta punkter listades dagen innan som inte hunnits med.
• Två veckor till i samma arbetsform är planen, med nedbrytning av vad som ska vara klart och en ny demo i slutet av perioden.
• Registreringsdelen uppdateras parallellt med handläggningen.

Retrospektiv — det som fungerat

• Närheten till verksamheten. Frågor har kunnat ställas och besvaras samma dag i stället för att ta två till tre veckor, vilket är den normala ledtiden.
• Fel upptäcks snabbt och kan rättas snabbt. Man ser direkt om något blivit fel och hinner ändra.
• Verksamheten kom in tidigt och gav konkret feedback på skisserna, både på det som fungerade och det som inte höll.
• Att prata direkt är värdefullt. Att gå via en person som tolkar och återberättar leder till missförstånd och extra varv.

Retrospektiv — det som kan bli bättre

• Ännu närmare. Att sitta i samma rum hade gett mer än digitala avstämningar.
• Chatten har sina baksidor — svar kan dröja, det blir kontextbyten.
• Mer förarbete. Förståelsen för verksamhetens processer borde ha varit djupare innan sprinten. Detaljerna tar längre tid än estimerat, och det är i detaljerna arbetet avgörs.
• Dokumentera processen när den är klar, så att nya personer kan sätta sig in i den och felsöka.
• Inspelningarna är ett bra underlag för att fånga detaljer som annars faller bort.

Framåt

Konkret plan för nästa vecka tas fram på måndag. Frågor går via chatten, med telefon vid akuta ärenden. Ingen daglig avstämning, men demo igen om två veckor.

Arbetet i Jira

Två utdrag täcker dagen. Det första togs fredag morgon kl. 08:08 och visar torsdagens avslut: tio färdigställda ärenden. Det andra togs måndag 5 oktober kl. 10:44 och visar fredagens rörelse: tolv ärenden, ett färdigställt, sju till granskning och fyra pågående.

Färdigställt torsdag

Färdigställt fredag

Till granskning

Pågående