Den 10–14 augusti sätter vi oss tillsammans — processledare och utvecklare på samma ställe, hela veckan — och bygger stödet för avvikelsehanteringsprocesserna inom välfärdssektorn i Sundsvalls kommun: ett handläggarstöd, ett gränssnitt där medborgaren kan registrera och följa sina ärenden, samt ett administrationsgränssnitt för behörighetshantering. Fokuserat, AI-accelererat och utan distraktioner.
Vid veckans slut har vi implementerat en version av behörighetsstyrning och behörighetsadministration av avvikelsehanteringen så långt vi kan komma, samt påbörjat lösningen för att hantera datasäkerhetskraven. Resultatet blir något så komplett som möjligt att utgå från i de fokuserade utvecklingssprintar som sedan följer, där verksamhetens behov löses fullt ut.
Där avvikelserna tas emot, utreds, kategoriseras, åtgärdas och följs upp — verktyget som bär hela processen för handläggarna inom vård och omsorg.
Där medborgaren själv kan registrera en avvikelse och sedan följa sitt ärende — se status, ta del av återkoppling och känna sig trygg med att ärendet hanteras.
Där behörighetshanteringen administreras — vem som får se och göra vad i avvikelsehanteringen. Byggs med en ny integration mot AccessMapper.
Formulär och flöde för att registrera avvikelser finns redan i testmiljö — vår startpunkt.
Prototyp av handläggarstödet som verksamheten har godkänt — vår målbild för funktionaliteten.
Vi reder ut de tekniskt komplicerade delarna — som behörighetsstyrning och datasäkerhet — och bygger så långt vi hinner.
Fokuserade utvecklingssprintar tillsammans med verksamheten som löser behoven hela vägen. Start vecka 36–37, leverans vecka 43.
När något inte blir som det ska i vården och omsorgen — en missad insats, ett läkemedelsfel, en brist i rutinerna — ska det registreras, utredas och åtgärdas. Det är så verksamheten lär sig och kvaliteten höjs. Idag saknar handläggarna inom välfärdssektorn (vård- och omsorgsförvaltningen samt individ- och arbetsmarknadsförvaltningen) ett modernt, sammanhållet stöd för den processen — och medborgaren saknar ett enkelt sätt att registrera och följa sina ärenden. Det ska vi ändra på.
Registreringsdelen finns redan framme i testmiljö, och en AI-byggd demo-applikation har visat verksamheten hur handläggarstödet kan se ut och fungera — den är godkänd som målbild. Den här veckan reder vi ut ett antal tekniskt komplicerade delar — som till exempel behörighetsstyrning och datasäkerhet — som förberedelse inför de kommande utvecklingssprintarna.
Den befintliga registreringsdelen för avvikelser, driftsatt i testmiljö. Grunden vi bygger vidare från.
draken-test.sundsvall.se/registrering/avvikelse_iafPrototypen av handläggarstödet som verksamheten har ok:at — vår funktionella målbild för sprinten.
claude.ai/public/artifacts/37ba1245…Avvikelseprocessen för VOF & IAF, dokumenterad på Confluence. Verksamhetens karta över flödet.
confluence.sundsvall.se/spaces/OAEn vecka är kort. Därför gäller sju enkla principer — de är inte förhandlingsbara, de är förutsättningen för att vi ska ro det här i land.
Vi tar eget ansvar för att driva processen framåt utan att vänta på yttre instruktioner. Ser du något som behöver göras — gör det.
Prata direkt med varandra, alltid. Ge feedback omedelbart. Tystnad är det största hindret.
Varje timme räknas. Agera med tillräcklig information — inte nödvändigtvis perfekt komplett sådan.
Avvikelsehanteringen måste bli klar. Good-enough framför optimalt. Komplexitet är en kostnad vi inte har råd med denna vecka.
Ändringar är bevis på att processen fungerar — inte på dålig planering. Ny insikt slår gammal plan.
Är du klar men en kollega har fastnat? Hjälp kollegan. Vi levererar tillsammans eller inte alls.
Vi använder AI aktivt i kodning, modellering och dokumentation — hela tiden. Det är så vi hinner en månads arbete på en vecka.
Kärnteamet sitter tillsammans hela veckan och jobbar fokuserat med sprinten — inget annat (om vi inte blir klara tidigare förstås). Stödresurser cirkulerar gärna i närområdet och är i övrigt nåbara via Slack och/eller Teams.
Leder den tekniska sprinten och är ytterst ansvarig för arkitekturbeslut — om och när sådana behövs.
Bygger tjänster, API:er och integrationer som bär avvikelseflödet.
Bygger tjänster, API:er och integrationer som bär avvikelseflödet.
Bygger handläggarnas gränssnitt — från AI-demons målbild till riktig applikation.
Bygger handläggarnas gränssnitt — från AI-demons målbild till riktig applikation.
Expertis kring verksamhetsfrågorna och processerna. Med vid uppstart, standups och demos — i övrigt tillgänglig vid behov.
Leder de fokuserade utvecklingssprintar som tar vid efter den här veckan. Med under sprinten för att säkra kontinuitet och en smidig överlämning till nästa steg.
Nyttjas vid behov när extra händer eller ögon behövs.
Processledare och utvecklare sitter tillsammans på ett och samma ställe hela veckan (exakt plats meddelas). Grovplanen nedan är just en grovplan — vi anpassar löpande efter vad vi lär oss. Omfamna förändring, som sagt.
Uppstartsmöte 08:30–10:30 med hela teamet inklusive Edwin och Claes. Vi går igenom målbilden, behörighetshantering och andra tekniskt komplicerade frågor, går igenom AI-demon, och planerar vad vi börjar med. Sedan: full fart
Fullt fokus på behörighetshantering och behörighetsadministration. Backend bygger datamodell och API:er. Frontend börjar realisera behörighets-delen i administrationsgränssnittet och handläggarvyerna.
Fokus på en demo-bar helhet: labels och platser på plats (även om listorna inte är korrekta än), VOF uppsatt parallellt med IAF, fortsatt arbete med regelverk och behörighetsstyrning. Halvtidsdemo på eftermiddagen där vi visar hur långt vi kommit.
Genomgång av säkerhetskraven och påbörjad datasäkerhetslösning. Platser på avdelningsnivå, språkstöd och behörighetsstyrning byggs vidare.
Göra klart så långt det går och merga in bakom featureflaggor. Slutdemo på eftermiddagen, sedan retro och riktning inför verksamhetssprintarna. (Vad demon landade i står i sprintloggen.)
Uppstartsmöte — hela teamet inklusive expertstödet. Målbild, arkitekturskiss och arbetsfördelning.
Standup — kort avstämning med hela teamet, inklusive expertstödet. Vad gjorde vi, vad gör vi, vad blockerar?
Halvtidsdemo — vi visar körande funktionalitet, inte slides. Feedback direkt, in i backloggen eller in i koden.
Slutdemo & retrospektiv — vi demar resultatet, summerar lärdomarna och sätter riktningen inför verksamhetssprintarna.
Slack / Teams — stödresurser är nåbara hela veckan. Fastnar vi ropar vi direkt, vi väntar inte till nästa möte.
Här dokumenterar vi veckan medan den pågår — vad vi byggt, vad vi beslutat och vad vi lärt oss. Loggen fylls på löpande under sprinten.
Dagen inleddes med ett uppstartsmöte där scopet för sprinten diskuterades, AI-demo-applikationen visades samt diskussionerna runt hur behörighetsstyrningen ska fungera inleddes.
Jobbat med lösningen för behörighetshantering — diskussionstungt — utmaningar med datastruktur i Metakatalogen samt hur framtida omorganisationer ska hanteras, med mera.
Dessutom: testmiljö uppsatt, alla beroenden uppdaterade (ett par hundra säkerhetsvarningar åtgärdade) och stöd byggt i AccessMapper för att lagra behörigheter på personnivå utöver AD-grupper.
Avstämningen om organisationsträdet gav klarhet: källan används idag främst för fakturering och kontering, men vi kan ändå bygga på den — vi tar en lokal kopia och förhåller oss till det som finns. Grundproblemet är att platser inte finns mappade alls, så det löser vi på vår sida.
I applikationen sattes tre utredningsformulär upp (ärendeformulären var klara sedan tidigare). Registreringsflödet förbättrades med inloggning och behörighetskontroll, men ärenden får ännu inte rätt plats eftersom labels saknas — det behöver åtgärdas.
Vi släpper organisationsträds-stöket för stunden — fokus på att komma så långt att vi har något bra att visa på halvtidsdemon i eftermiddag.
Backend fortsätter med regelverk och behörighetsstyrning. Frontend sätter upp VOF parallellt med IAF (samma funktionalitet men åtskilda organisationsträd — den som är inloggad för VOF ska inte se IAF:s träd och tvärtom), och alla labels/platser (Backend) ska in även om listorna inte är korrekta än — det måste gå att lägga ärenden — och AccessMapper används likaså med den data som finns. Testanvändarna stäms av med Henrik.
Vi tröskade igenom en stor mängd säkerhetskrav och påbörjade ett arbete kring datasäkerheten som förmodligen blir ett eget projekt — det är generellt och gäller fler processer än avvikelsehanteringen (t.ex. ekonomiskt bistånd och det som ska göras via Mina sidor vid införandet av det nya välfärdssystemet).
Platser och labels: det går nu att välja plats på avdelningsnivå, och platsen föreslås utifrån rapportörens anställning. Riktiga avdelningar är inlagda, och tack vare config-skriptet kan samma uppsättning läggas in i testmiljön med en knapptryckning när det är dags.
Språkstöd finns nu i både applikationen och språk-JSON:en — svenska och engelska än så länge, och fler språk kan enkelt läggas till. Översättningarna är AI-genererade och behöver granskas av verksamheten. Benämningar som kommer från API:t (t.ex. rollen "Rapportör") översätts dock inte ännu.
Behörighetsstyrningen växte rejält: auktoriseringen visade sig bara täcka ärenderesurserna, så ytterligare 14 resurser fick skyddas — bland annat admin-resurserna som styr själva access-kontrollen. Nu är den nära klar. Riktig AD-koppling till AccessMapper hinns inte med i sprinten; behörigheter läggs i stället in lokalt i AccessMapper, med stödet som byggdes i måndags.
Standup på morgonen: fokus på att göra klart så långt det går inför slutdemon kl 14. Både access-kontrollen och ärendehanteringen ligger bakom featureflaggor (avstängda som standard), så det var säkert att merga in i main. Det minimerar merge-konflikter när fler delar av teamet går in i koden under kommande sprintar.
Behörighetsstyrningen gick inte att visa live. Koden är skriven och deployad, men vi hann inte omfatta alla behörigheter — och när demot riggades hittade vi en bugg: AccessMapper går mot AD, och för en användare utan riktiga AD-grupper kommer ingenting alls tillbaka i stället för det vi förväntar oss. Planen att sidesteppa det genom att lägga behörigheterna på personnivå i stället för på grupp fungerade inte heller hela vägen. Bra att den hittades nu — den hinner åtgärdas innan nästa sprint.
I stället blev det en teknisk genomgång av före och efter. Innan sprinten fanns en ärendefiltrering kopplad till den nya tjänsten AccessMapper: antingen fick du fram ett ärende eller så fick du det inte. Nu finns auktoriseringskontroll per resurs över hela API:et — 30–40 resurser — så att man t.ex. kan få läsa ärenderesursen men inte bilagorna, eller Communication-resursen men inte namespace-konfigurationen. Ovanpå det ligger rollbaserade attributrestriktioner: utifrån roll styrs exakt vad som släpps igenom i payloaden. Det sistnämnda visade sig matcha ett av säkerhetskraven som vi fick se först i efterhand. Allt är konfigurerbart (det blir mycket config) och täckt av automatiska tester — det är ingen hack-lösning. PR:en landade på ~7 500 rader, och motsvarande utökningar är gjorda i både AccessMapper och Support Management.
Rollstyrningen är förutsättningen för utredningsdelen, där flera handläggare med olika roller ska jobba på samma ärende samtidigt i var sin flik. Uppskattningsvis ~95 % är på plats; kvar är att koppla ihop delarna och testa hela kedjan med riktig data och riktiga testanvändare.
Rapporteringsgränssnittet demades live för dem som inte sett det tidigare: vyn där rapportören ser sina inskickade ärenden och kan följa status, och formuläret där man väljer missförhållande eller avvikelse (verksamhetens egna termer — tröskeln för att rapportera ska vara så låg som möjligt). Inloggad rapportör får sin plats föreslagen utifrån anställningen och kan verifiera eller söka fram en annan — inklusive avdelningsnivå, som är nytt för den här veckan. Obligatoriska fält valideras, mobilvyn är en stegvis wizard i stället för en lång scroll, och man kan välja att logga ut direkt vid inskick eftersom man ofta jobbar på delade mobiler. Språkstöd (svenska och engelska) finns nu på plats. Bilagor och bilder är inte specat av verksamheten, men går att bygga om behovet finns.
Handläggargränssnittet visades med ett nyss inkommet ärende: ärendeuppgifter, vem som rapporterat och eventuella andra parter, samt de nya utredningsformulären som växlar dynamiskt beroende på om det är ett missförhållande eller en avvikelse. Nytt är också fas-stödet — registrering, granskning, utredning — som hjälper handläggaren att se var i processen ärendet befinner sig och som på sikt ska styra vilka flikar som visas i respektive fas, så att man slipper hantera allt samtidigt. Åtgärderna, som utredningen ska mynna ut i och som en särskild roll ska besluta om, är påbörjade men inte införda ännu.
Säkerhetskraven gicks igenom på kravsidan: ~100 krav sammanställda ur regelverken och våra egna styrdokument. De gäller all K3-klassad information, inte bara avvikelsehanteringen, och en del är redan uppfyllda medan mycket handlar om rutiner, organisation och styrning. Vissa krav kräver andra delar av organisationen (kryptering i databasen, separerade nätsegment), annat fixar vi själva (t.ex. audit-logg). Slutsatsen: det här behöver bli ett eget, systematiskt arbete ganska snart — mycket ska rullas ut för VOF och IAF i och med Lifecare-införandet. Kristin söker initiativägare.
En viktig fråga lyftes av Peter Karlsson: uppföljningen av avvikelser är inte klarlagd. Det handlar inte om att räkna ärenden, utan om att se trender och om avvikelsehanteringen faktiskt leder till kvalitetsförbättringar — verksamhetens främsta skäl till att det här ska bli bättre än dagens verktyg. Se den öppna frågan nedan.
Veckan har till stor del gått åt till teknik under kulisserna — nya tekniker vi inte haft tidigare, byggda så att de kan återanvändas i andra processer framöver (alkohol och tobak är ett exempel). Retrospektivet efter demon blev ovanligt positivt; hela genomgången finns under Retrospektiv.
Efter sprinten: nästa vecka är ingen sprintvecka — de gråa veckorna används för återhämtning och för att beta av restlistan i lugnare takt, mindre formaliserat. Teamet fortsätter direkt på måndag medan allt fortfarande sitter i huvudet. Verksamhetssprintarna drar igång vecka 36–37, med leverans vecka 43 i sikte, och verksamheten deltar till stor del på distans eftersom de sitter utspridda. Behörighetsstyrningen är det viktigaste att ha på plats till dess — hela processen bygger på den, och fler processer kommer behöva den när vi skalar upp.
Efter slutdemon på fredagen höll teamet retro. Den blev ovanligt positiv — det brukar bli tyst när frågan om vad som gått bra ställs, men här var det tvärtom. Det mesta som kom upp handlar om själva arbetssättet snarare än om koden.
Att lösa problem direkt i stället för var och en på sin kammare. Det räcker med att sitta i olika rum för att man ska klura vidare själv i onödan — tröskeln behöver inte vara hög för att bli ett hinder. Extra viktigt nu när AI-stödet gör att stegen blir större: ett felaktigt steg blir dyrare, och avstämning fångar det tidigt.
Löpande review, någon att bolla lösningar med och möjlighet att dela upp arbetet. Värdet är störst i Support Management, som många andra system beror på och där ett misstag slår brett. För en fristående tjänst räcker det ofta med en — bemanningen får bedömas per sprint utifrån vad som faktiskt ska byggas.
Inga andra möten, inga andra projekt. En stor del av vinsten är just att slippa kontextväxla — den tiden går annars förlorad varje gång man byter projekt.
Någon som kan bryta en metadiskussion, ta beslutet och låta teamet köra vidare. Frågan om avdelningar i organisationsträdet kunde ha stötts och blötts i timmar — i stället blev det ett beslut om manuell hantering tills vidare, och arbetet gick framåt.
Avvikelsehantering har riggats för under en längre tid och många delar hade redan börjat avhandlas — design, insikten att AccessMapper behövdes över huvud taget, organisationsträdet och möten med verksamheten om vilka roller som finns. Utan det hade uppstartssträckan blivit lång.
Målbilden var enkel att förhålla sig till: få något som snurrar i testmiljön. Inte färdigt, men inte trasigt. Då är det bara att ta tag i det som står i vägen, utan att fråga om det ingår.
Formatet kördes för första gången, men vad en teknisk sprint innebär presenterades aldrig: hur länge den pågår, att vi sitter tillsammans, vilka mandat teamet har, vems roll är vad, vem man frågar om vad — och vad som gäller när sprinten är slut. Fem minuter på uppstartsmötet hade räckt. Det gick bra ändå för att alla tog för sig, men ramen ska finnas nästa gång (och någon får gärna säga åt folk att läsa sprintsidan).
Alternativet till klassisk förstudie: sätt verksamhet och utveckling i samma rum i stället för ett dokument som skrivs av en förstudieledare, skickas vidare i flera led och till slut hamnar hos utvecklare som får gissa vad som menas. Då går det att ställa de tekniska frågorna på ett verksamhetsmässigt sätt, förstå processen på riktigt och läsa mellan raderna direkt. Det är den delen som är nyckeln — och den ger dessutom underlaget som saknas när tid ska estimeras.
Idag estimeras utifrån ett Jira-kort utan egentlig information om vad som ska göras — och att lova fel ser dåligt ut oavsett orsak. Bättre: grov prognos först, förfina den efter förankringen, och stoppa tidigt om omfattningen växer. På sikt hellre en prenumerationsmodell — ett antal utvecklare på heltid mot det som ger mest värde — än att boxa in arbetet per beställare och avdelning.
Mycket sitter i huvudet på dem som varit med — hur delarna hänger ihop och varför. Att bemanna nästa sprint med ett helt nytt team fungerar inte; det behöver finnas överlappning.
Veckan var rolig just för att man fick jobba nonstop med en sak — men det går inte att köra i det tempot hela tiden utan att bränna ut folk. Modellen är sprint följt av en lugnare period, och längden får anpassas: ibland två veckor tekniskt i sträck, ibland en vecka i taget.
Hörnet har blivit sprintplatsen — då bör den också vara rätt riggad: samma skärmuppsättning på varje plats (helst en 34-tumsskärm med en kabel som också laddar, i stället för dockor som krånglar), vettiga stolar och bord, och en whiteboard. Ingen ska få en sämre plats för att den kom sent.
Tiden i sprinten rapporteras veckovis och formlöst till Claes — ett mejl räcker. Det är skönare än att splittra veckan på objekt- och aktivitetskoder som ändå inte mappar verkligheten, där ett arbete kan spänna över flera objekt. Även tiden mellan sprintarna räknas med, så att totalen för avvikelsehanteringen blir rättvisande.
En teknisk sprint är motiverad när det finns nya, tunga frågor att lösa mitt i en plattform som mycket annat beror på — som behörighetsstyrningen den här veckan. När det mest handlar om att återanvända mönster vi redan har räcker det med prepp veckan innan. Det är den bedömningen vi vill bli bättre på att göra i förväg.
Det här tog vi inte i mål under veckan. Punkterna betas av under de två veckorna fram till verksamhetssprintarna — det mesta är sådant som behöver funka tekniskt innan verksamheten kan bidra, och som annars bromsar uppstarten av nästa sprint.
Täppa till de edge-case som återstår, fixa AD-buggen från demot och testa hela kedjan skarpt med testanvändare. Högsta prioritet — allt annat bygger på den.
Grupper behöver beställas för alla typer av användare, inte bara ett par dummy-roller. Borde egentligen ha varit klart tidigt — utan dem går behörigheterna inte att testa på riktigt.
Läsa in var personalen faktiskt jobbar från Metakatalogen till en egen cache, t.ex. en gång per dygn — det är anställningen som styr behörigheten, och uppslagen måste gå fort. Mappningen avgör nivå: enhetschef ser från nivå fyra och neråt, verksamhetschef från nivå två och neråt.
Att flytta ärenden mellan olika grupper av användare och mellan stadier, olika beroende på ärendetyp. Löst teoretiskt, inte byggt.
Flera handläggare ska kunna jobba på och spara samma ärende samtidigt utan att skriva över varandra. Konfliktdetektering byggdes i somras men nyttjas inte ännu — behöver kopplas in och testas.
Utredningen ska resultera i planerade åtgärder som en särskild roll beslutar om. Påbörjat, inte infört — och det är åtgärderna uppföljningen till stor del ska bygga på.
VOF:s avdelningar är inlagda, men för IAF har vi inget underlag ännu. Verksamheten håller dem i Excel — vi behöver få listan.
Förvaltningarna omorganiserar ofta. Att slå ihop, byta namn på eller ta bort avdelningar ska gå att göra i ett gränssnitt — inte genom handskriven SQL.
Frågor som dykt upp under arbetet och som behöver ett svar. Varje fråga behöver en ägare som ansvarar för att driva den framåt — och det ansvaret ligger hos dem som leder det utvecklingsinitiativ som syftar till att etablera avvikelsehanteringen: de utser ägare för samtliga öppna frågor. Listan uppdateras löpande, även efter sprintveckan.
Hur implementerar vi en generell hantering av testdata för alla processer inom VOF/IAF?
ej utsedd ännuBehörighetsstyrningen går inte att testa skarpt utan användare som täcker varje roll — rapportör, handläggare och utredare, enhetschef, verksamhetschef och administratör — och de behöver rätt anställning och placering i organisationsträdet för att platser och behörigheter ska slå igenom. Just avsaknaden av en riktig användare med riktiga AD-grupper var det som stoppade demot på fredagen. Till en demo räcker en av varje roll, men under verksamhetssprintarna behövs de i både VOF och IAF, och även för externa utförare vars användare inte finns i organisationsträdet alls. Kvar att avgöra: vem tar fram dem, i vilka miljöer, och hur hålls de aktuella över tid? Hänger ihop med AD-grupperna på restlistan och med frågan om testdata.
ej utsedd ännuLösningar för att minimera access till produktionsdata. Genomgången av säkerhetskraven (tors–fre) visade att det här är större än avvikelsehanteringen: ~100 krav som gäller all K3-klassad information, där vissa kräver andra delar av organisationen (kryptering i databas, separerade nätsegment) och andra ligger hos oss (audit-logg, maskning). Behöver bli ett eget initiativ med ett systematiskt arbetssätt — Kristin söker initiativägare. Angeläget inför Lifecare-införandet.
ej utsedd ännuFrågan ställdes på demon och diskuterades vidare på retron: var det rätt att bygga avvikelsehanteringen i Draken, eller hade en dedikerad applikation varit smidigare — inte minst för att kunna spridas till andra kommuner? Att bygga från noll tar avsevärt mycket längre tid: Support Management bär fem års löst arbete kring transaktionshantering, concurrency, pessimistiska läslås, konfliktdetektering och testverktyg, och det är mönster värda att återanvända. Samtidigt ökar komplexiteten ju mer distribuerat allt blir — vi har idag ingen transaktionshantering över tjänstegränser, så en operation som fallerar i fjärde steget av fem saknar återställning (köer är en tänkbar väg). Ekonomiskt bistånd testar den andra varianten med Care Management, en avknoppning av Support Management, på grund av direktintegrationen mot Lifecare. Nästa steg: bryt ut mer av det återanvändbara i dept44-biblioteken och utvärdera Care Management-spåret innan nästa gång frågan ställs.
ej utsedd ännuLyft av Peter Karlsson på slutdemon: hur ska verksamheten följa upp avvikelser? Inte antal ärenden, utan trender och om hanteringen faktiskt leder till kvalitetsförbättringar — det är verksamhetens främsta skäl till att det här ska bli bättre än dagens verktyg. Verksamheten har varit diffus och förvaltningarna oense, och delarna är inte specade. Vår hållning: bygg enklare uppföljning systemnära och on demand i stället för nattliga uttag till Qlik — dels för att undvika att uttagen havererar när datamodellen ändras, dels för att K3-data inte utan vidare bör suga ut ur systemet omaskat. Utredarna som är vana vid Qlik får fortsatt göra det avancerade där. Tas upp med verksamheten inför nästa sprint — kan förlänga en sprint markant.
ej utsedd ännuDelvis utredd (tis 11/8): källan används idag främst för fakturering och kontering, men vi kan bygga på en lokal kopia av den. Platser saknas dock helt — ingen mappning finns — och hanteras därför på vår sida. Kvar att avgöra: ska den vara master, och hur fångar vi upp organisationsförändringar? En laddningstjänst som synkar organisationsdata till AccessMapper dygnsvis ligger på todo.
Efter slutdemon (fre 14/8): Masterdata och Metakatalogen är två skilda saker — Metakatalogen visar hur organisationen ser ut just nu, medan Masterdata är systemet för att genomföra verksamhetsförändringar med full historik (att två avdelningar slagits ihop går inte att utläsa ur en diff på trädet, men finns i Masterdata) och för att simulera en omorganisation innan den genomförs. Långsiktigt rätt lösning är därför att få in avdelningarna i källan i stället för att dekorera trädet på vår sida. Ett vidare spår: ett ”Masterdata 2.0” som även håller fysiska platser och anläggningsregister — där finns flera case än vårt, och det borde redas ut med Marcus Olsson och de som varit med i de tidigare platsdialogerna.
ej utsedd ännuHur ska tillfälliga behörigheter tidsbegränsas (giltig från–till, tas aldrig bort) och historiken bevaras så att det går att se vem som hade access till vad och när? Ligger ansvaret i AccessMapper eller separat?
ej utsedd ännuVikarier och timanställda kan vara anställda på både VOF och IAF och växla dag för dag — hur vet vi vart en avvikelse ska skickas? Möjliga källor: dagens schema från schemasystemet (styr redan bemanning och behörigheter, t.ex. medicinskåp) eller delade mobiler kopplade till boendet. Kortsiktigt kan rapportören få välja förvaltning själv. Utredningspunkt — löses inte denna vecka. Pelle kollar status på delade mobiler med Niklas Johansson.
ej utsedd ännuSvenska och engelska finns på plats med AI-genererade översättningar — verksamheten behöver granska benämningarna och avgöra vilka fler språk som ska stödjas. Benämningar från API:t (t.ex. rollen "Rapportör") översätts inte idag. Databasen är UTF-8 så t.ex. arabiska och kinesiska bör fungera i applikationen, men SMS på arabiska har tidigare stoppats hos operatören.
ej utsedd ännuSökningen är en rent teknisk fråga och ingen blocker — det går att handlägga och skapa ärenden ändå, och statistik kan i värsta fall tas fram genom att läsa ut alla ärenden och filtrera. Vi tror oss veta hur den ska lösas, men den är inte högprioriterad. Viktigt dock: formulärscheman behöver designas med sökbarhet i åtanke, och varje nyckel behöver en förklaring i verksamhetsspråk. Åtgärderna sparas så att de enkelt går att filtrera och sortera — det är grunden att bygga uppföljningen på (se frågan om uppföljning & analys).
ej utsedd ännuExterna utförare (privata bolag) finns inte i organisationsträdet och saknar schema. Ansvarig hos utföraren måste själv lägga in sina användare via leverantörsportalen — annars kan de inte logga in. Hur användarhanteringen ska fungera i praktiken är en egen fråga som hanteras efter sprinten.
ej utsedd ännu