Utvecklingssprint – upplägg och läge, Draken AoT

Läget efter sprinten

Avstämning 5 oktober

Sprinten nådde ungefär till och med mål 2 för vecka 40. Det som inte blev klart rullar in i den här veckan som första prioritet.

Vecka 39

Registrering och handläggning

Registrera ett ansökningsärende och ett anmälningsärende i Katla Klart
Ärenden ska kunna handläggas – granska, utreda och besluta Delvis
- Utredningssteget återstår i sin helhet och är den tyngsta kvarvarande delen.
- Kommunikation med kunden via Mina sidor Delvis
- Skal för asset Klart

Vecka 40

Assets, tillsyn och presentation

Komplett asset för tillstånds- och anmälningsprocessen Delvis
- Data skickas in, men hanteringen är inte fullständig. Att välja mellan befintligt och nytt serveringsställe på en adress hanteras inte, och processen som skapar nytt vid behov är inte på plats.
Starta och handlägga tillsynsärende och åtgärdsärende Pågår
- Backend-arbetet pågår parallellt. Målet är att bli klar med den delen den här veckan.
Visa asset i Handläggningsdraken, sökbart Återstår
Visa asset på Mina sidor Återstår

Beslutsflödet är felsökt. Beslutsfattande och roller gicks igenom i fredags, och flödet ska nu kunna rulla igenom hela vägen. Det är förutsättningen för att verksamheten ska kunna börja testa.

Restlista och prioritet

Prio 1 blockerar handläggning. Prio 2 måste finnas men blockerar inte. Prio 3 ligger efter innevarande vecka.

Prio 1 – blockerar handläggning

Prio 1

Utredning

Hela utredningssteget återstår. Sektionerna är remisser och yttranden, personlig lämplighet, ekonomisk lämplighet, kunskapsprov, lokal och serveringsställe, sammanvägd bedömning samt förslag till beslut.

Börja med remissprocessen – den är helt främmande för Draken idag och är den tyngsta delen. Byggs enligt skissen som en första version.
Därefter förslag till beslut. Övriga sektioner kan vara fritext eller platshållare i första versionen, så att steget går att ta sig igenom.
Kunskapsprov och personlig lämplighet kopplas till PBI-sektionen: peka ut en person, markera OK eller inte OK, lägg till anteckning.
Lokal och serveringsställe väntar på koppling till lokalinspektion och brandsäkerhet. Oklart om det ska vara ett dokument eller en kontroll av uppgifter från ärendet.
Mallar behövs i templating för remiss, ordningsfråga och vandelsprövning.

Prio 1

Serveringsställe

Hantering av serveringsställen, inklusive att skapa nya när det behövs.

Handläggaren väljer i beslutssteget om tillståndet gäller ett befintligt serveringsställe på adressen eller ett nytt. Listan visar vilka som är aktiva och vilka som är lediga.
Processen skapar restaurangnumret vid bifall, om det inte redan finns ett på adressen.
Det bör framgå på beslutet att ett serveringsställe tilldelas, så att det inte sker osynligt i bakgrunden.
LicensedBusiness kan behöva justeringar, exempelvis för att kunna spara.

Prio 2 – måste finnas, men blockerar inte handläggning

Prio 2

Tillsyn och åtgärd

Processen bedöms enkel – lite ska ske automatiskt. Dokumentationen av stegen pågår och kompletteras med vad som sker i gränssnittet och vad processen ska hantera. Åtgärd följer samma spår som tillsyn, som parallella processer i processmotorn. Målet är att backend-delen blir klar den här veckan.

Prio 2

Förändring av asset

Inte påbörjad. Gäller ändring av ett redan utfärdat tillstånd: e-postadress, vilka drycker tillståndet omfattar, serveringsställets adress och serveringsansvarig.

Stödet finns till stor del – PATCH mot PartyAssets med versionshantering ger historik över hur tillståndet såg ut tidigare.
Det som återstår är att sy ihop det i processen, så att ett godkänt ändringsbeslut faktiskt leder till uppdateringen.
Ändring av serveringsansvarig ska kunna göras fritt, så länge det finns historik över vilka som haft rollen.

Prio 2.1

Migrering

Den historiska databasen. Inte påbörjad och garanterat omfattande. Levereras inte den här veckan, men förutsättningarna ska vara klarlagda. Arbetet kan inledas när tillsyn och åtgärd är avklarade.

Tobaksdatan ligger i en annan databas som inte är åtkomlig med nuvarande behörigheter. Ärende är inlagt för åtkomst till både databasen och filytan där handlingarna ligger.
Oklart om tobaks- och alkoholtillstånd ligger på samma filyta. Ett alternativ är att migrera alkohol först.
Det finns ingen separat testdatabas, så provdata kan köras in i test utan särskild hantering.

Prio 3 – inte den här veckan

Prio 3

Folkhälsomyndigheten

Integration mot deras API. De svarar inte på kontaktförsöken och jagas vidare. Tills vidare hanteras återrapporteringen för hand.

Prio 3

Överklagan

Processen spikas internt först och presenteras därefter för verksamheten som ett besked om hur den kommer att fungera, inte som en förankring. Möte kallas när processen är klar.

Prio 3

Mina sidor

Visa ärenden och assets för kunden. Kräver att namespace för AoT släpps igenom i konfigurationen, vilket kan vara en snabb åtgärd. Men det finns inget att visa förrän prio 1 och 2 är på plats.

Prio 3

Kundbild

Med ett party-id går det att hämta ärenden och lista serveringsställen, men vad som faktiskt ska visas är inte utrett. Förutsätter dessutom serveringsställehanteringen och utredningen.

Plan för veckorna som återstår

Fyra veckor kvar. Två i nuvarande arbetsform, därefter en svans för fix, justeringar och städning.

Vecka 41

Denna vecka

Bli klar med det som skulle varit klart under sprinten – utredning och serveringsställe först.
Backend för tillsyn och åtgärd.
Förutsättningarna för migreringen klarlagda.
Testomgång med verksamheten på onsdag.

Vecka 42

Fortsatt utveckling

Förändring av asset syds ihop i processen.
Migreringen påbörjas när tillsyn och åtgärd är avklarade.
Veckomålen bryts ned i början av veckan, med en bedömning av vad som flyttas till svansen.

Vecka 43–44

Svans

Fix, justeringar och städarbete.
Det som inte rymts i de två föregående veckorna.

Testomgång med verksamheten på onsdag. Testmiljön rensas och 3–5 ärenden av olika typer läggs upp, så att de kan gå igenom handläggningen från början till slut. Det behöver inte vara färdigt – kända brister listas i förväg så att de vet vad som inte ska testas. Poängen är att få in dem tidigt, eftersom synpunkter och ändringar är oundvikliga och bättre kommer nu än sent.

Beslut som styr arbetet

Förändringsärenden

Alla förändringar kommer in via Mina sidor. Det gäller ändringar på ett redan utfärdat tillstånd, till exempel serveringstider. Det krävs få uppgifter – det är inget fullständigt ansökningsformulär.
En förändring blir ett ärende med de nya uppgifterna. Vid beslut skapas en ny version av asseten i stället för att den befintliga skrivs över, så att historiken finns kvar.
Samma sak ska gå att skapa från Draken, så att handläggaren kan göra det manuellt. Den vägen byggs först – då går flödet att testa innan Mina sidor-delen finns.
Utredningsfliken startas alltid. Handläggaren avgör hur tung utredningen blir: ibland en full remissprocess, ibland bara en kontroll.

Mallar och dokument

Mallarna genereras som PDF. Dokumentet skapas från mallen och fylls med uppgifter från ärendet via platshållare – mallen hämtas inte för att redigeras.
Ingen redigering av PDF:en i gränssnittet. Fritext i mallen skulle spräcka formatet. Sidhuvud och sidfot sätts automatiskt, och det är innehållssektionen som styrs från ärendet.
Remissen skickas inte av systemet. Den skapar en PDF-bilaga som läggs på ärendet. Innehållet har känsliga personuppgifter och får inte gå via vanlig e-post – polis och Skatteverket har olika tjänster för säker post, och SDK finns inte i kommunen än. Handläggaren laddar ner, skickar via sin egen kanal och laddar upp svaret som bilaga.
Bilagor ska ha en typ, exempelvis "remiss polis", och det ska framgå om de är inkomna eller skickade. Då kan remiss och svar paras ihop i överblicken.

Avgränsat tills vidare

Registreringsformuläret uppdateras inte nu. Uppgifterna som kommer in är inte helt korrekta, men de är inte avgörande för handläggningen.
Fakturering ligger utanför.

Arkitektur: integrationen mot processmotorn skalar inte

En teknisk fråga utan synlig effekt för användaren, men som behöver tas höjd för innan fler verksamheter kommer in.

Idag finns en egen integration från Support Management till pw-alkt, som håller ett tiotal processer. Lösningen byggdes så eftersom RabbitMQ inte var klart när lösningen designades.
Det fungerar bra för en handfull processmotorer, men antalet integrationer växer linjärt med antalet processer. Smärtgränsen går redan vid två – då bör frågan tas upp.
Riktningen är att lyfta in RabbitMQ i Support Management och publicera meddelanden, så att processmotorerna lyssnar i stället för att var och en kräver en egen integration.
Konsekvensen av dagens lösning är att Support Management blir specifik för AoT i stället för generisk över namespaces.
Planeras att hanteras under 2027.

Beroenden och öppna punkter

Fråga	Ligger hos	Status
Åtkomst till databasen med tobaksdata och till filytan med handlingar	Systemägare, ärende inlagt	Blockerar migrering
Skisser för mallar: remiss, ordningsfråga och vandelsprövning	Teamet	Efterfrågat
Skisser för förändringsärenden på Mina sidor	Möte bokas	Planerat
Svar från Folkhälsomyndigheten om API-integration	FHM	Inget svar
Koppling till lokalinspektion och brandsäkerhet	Ej utrett	Öppen
Namespace för AoT i konfigurationen för Mina sidor	Teamet	Snabb åtgärd
Redigerbar PDF för extern mottagare som ska fylla i remissvar	Ej avgjort	Öppen
Hur generisk processen i pw-alkt ska vara för andra verksamheter	Ej avgjort	Öppen

Arbetsform

Arbetet fortsätter som under sprinten, med standups, genomgångar och demo tillsammans med dem som varit med hittills.
Verksamheten kommer in och testar handläggning på onsdag, och därefter löpande.
Veckomålen bryts ned för de kommande två veckorna, med en bedömning av vad som flyttas till svansen.
Arbetet styrs av restlistan och prioriteringen. Det kan bli aktuellt att ta en prio 3 i backend tidigare, för att frontend ska kunna komma vidare.

Risker

Risk	Konsekvens	Hantering
Utredningssteget är stort och frontendtungt	Den enskilt största kvarvarande delen, och den blockerar handläggning.	Bygg remissprocessen först, låt övriga sektioner vara platshållare i första versionen.
Migreringen är inte påbörjad och åtkomsten saknas	Störst osäkerhet i hela leveransen. Blir den försenad påverkas driftsättningen.	Jaga åtkomstärendet. Klarlägg förutsättningarna den här veckan även om arbetet inte hinner starta.
Verksamheten kommer in sent i testningen	Synpunkter och ändringar landar för sent för att hinna hanteras.	Testomgång på onsdag, med kända brister listade i förväg.
Mer flyttas till svansen än vad som ryms	Två veckor avsatta för fix och städning fylls av kvarvarande utveckling.	Bryt ned veckomålen och bedöm löpande vad som faktiskt hinns med.
Integrationen mot processmotorn skalar inte	Varje ny verksamhet kräver en egen integration, och Support Management förblir AoT-specifikt.	Ta upp frågan om RabbitMQ innan nästa verksamhet ansluts. Hanteras under 2027.