Prototyp Kundhändelsetypskatalog

[johantjader]

Mina ärenden har lagt ut en första enkel prototyp på en s.k. kundhändelsetypskatalog på dataportalen. Kundhändelsetypskatalogen tror vi är är förutsättningsskapande för att t.ex.

• ärendeåterkoppling producenter emellan ska bli mer likartad då producenter får insyn i hur andra utformat sin ärendeåterkoppling, detta bör på sikt leda till att upplevelsen av s.k. "mydighetska" minskar,
• det ska bli överskådligt för en konsument vilken ärendeåterkoppling som finns tillgänglig och ha förutsättningar för att kunna ta beslut huruvida relevant information finns för att realisera vissa tjänster
• få förståelse för vilken typ av ärendeåterkoppling som finns, men också saknas, för att tillgodose behov av ärendeåterkoppling inom t.ex. en viss livssituation
• för en konsument att förstå hur kundhändelsetyper förhåller sig till varandra i ett prpducentärende och hur ärendeåterkopplingen är utformad

Realiserandet av katalogen som en teknisk komponent är inget som ligger i planerna i närtid. Men vi har valt att ta fram en enkel prototyp för att kunna ha något mer konkret att diskutera utifrån för att bättre förstå behov och krav på en ev. framtida lösning.

Prototypen finns tillgänglig via Mina ärenden på dataportal eller via denna länk.

Vi tar gärna emot synpunkter, tankar och ideér i tråden nedan.

För den som vill veta mer så beskrivs tankarna bakom kundhändelsetypskatalogen närmare nedan.

---

Varför en kundhändelsetypskatalog?

En konsument-tjänst kommer med hjälp av standardiserade tjänster inom Mina ärenden kunna hämta kundhändelser ifrån en eller flera producenter. Det finns vissa urvalsmöjligheter i dessa hämtningar, men i slutändan kommer konsument-tjänsten ändå att ha en lista med kundhändelser av olika typer.

Om konsument-tjänsten erbjuder en mer sofistikerad vy över kundhändelserna än bara en kronologisk lista så behöver kundhändelserna grupperas och sorteras in i de producentärenden som de tillhör. Dessutom kan det vara så att vissa kundhändelser 'saknas', dvs konsument-tjänsten hade förväntat sig att få dem, men de dök inte upp i listan av kundhändelser som hämtades. Hur vet konsument-tjänsten att vissa kundhändelser 'saknas'?

Låt oss ta ett enkelt exempel, återigen med Pias Tacotruck och vår fiktiva företagstjänst.

Företagstjänsten har tidigare kommit fram till att Pia behöver genomgå fyra producentärenden (exakt hur det har gått till och hur den informationen är lagrad har inte med kundhändelsetypskatalogen att göra utan beskrivs på andra ställen):

• Anmäla verklig huvudman hos Bolagsverket
• Registrera sig som arbetsgivare hos Skatteverket
• Registrera varumärke hos Patent och registreringsverket
• Anmäla fettavskiljare hos Stockholms stad.

Företagstjänsten har nu hämtat följande lista med kundhändelser ifrån några producenter (och sedan lagt ihop svaren ifrån respektive konsument till en och samma lista). Notera att alla dessa värden är påhittade för exemplets skull. I verkligheten kan kundhändelser av dessa typer ha andra id:n, andra kundhändelsetyper och andra rubriker.

Id	Tidpunkt	Producent	Kundhändelsetyp	Rubrik
1	2022-06-20 15:12:32	Skatteverket	SKV.ARBETSGIVARE.ANSOKAN	Ansökan mottagen för arbetsgivarregistrering
2	2022-06-21 09:32:12	Patent och registreringsverket	PRV.VARUMARKE.ANSOKAN	Ansökan mottagen för varumärkesregistering
3	2022-06-21 14:12:49	Stockholms stad	KOMMUN.FETTAVSKILJARE.ANSOKAN	Ansökan mottagen för fettavskiljare
4	2022-07-01 09:03:05	Skatteverket	SKV.ARBETSGIVARE.HANDLAGGNING	Handläggning påbörjad för arbetsgivarreigstrering
5	2022-07-04 11:32:54	Stockholms stad	KOMMUN.FETTAVSKILJARE.HANDLAGGNING	Handläggning påbörjad för fettavskiljare
6	2022-07-04 13:21:15	Skatteverket	SKV.ARBETSGIVARE.BESLUT	Beslut fattat för arbetsgivarregistrering
7	2022-07-04 14:12:35	Patent och registreringsverket	PRV.VARUMARKE.KOMPLETTERING	Komplettera din ansökan för varumärke

Om detta var all information som företagstjänsten kände till så hade den iofs kunnat placera in dessa kundhändelser i respektive producentärende, men den hade inte kunnat förstå om producentärendena är klara eller om det är kundhändelser som borde ha hänt men ännu inte gjort det.

För att få en fullödig bild av hur det går för Pia med sina producentärenden behöver företagstjänsten också förstå hur respektive producentärende borde gå till och vilka kundhändelser som borde komma. Alltså behöver den förstå för respektive typ av producentärende, vilka typer av kundhändelser som kommer då och i vilken ordning. Dessutom behöver den förstå vilken kundhändelsetyp som indikerar att respektive producentärende är klart (åtminstone såsom producenten ser det).

Vilken information finns i katalogen?

Kundhändelsetypskatalogen innehåller information om följande entiteter:

• Kundhändelsetyper
• Producentärendetyper.

För varje producentärendetyp (Arbetsgivarregistrering, varumärkesregistrering, fettavskiljare, verklig huvudman i exemplet ovan) innehåller kundhändelsetypskatalogen information om:

• Namn på producentärendetypen
• Producentärendetypens identifierare (den text som står i mitten-fältet av kundhändelsetypsnamnet i tabellen ovan, alltså ARBETSGIVARE, VARUMARKE etc)
• Flödet av kundhändelsetyper som skapas när en kund genomgår en instans av producentärendet. I flödesbeskrivningen ingår:
  • Startpunkt
  • Vilka kundhändelsetyper en kund kan passera och i vilken ordning
  • Vilken/vilka kundhändelsetyp som indikerar att producenten anser att flödet är klart och producentärendet därmed är avslutat
    (kundhändelser av dessa kundhändelsetyper har värdet true på attributet producentarendetKlart)
  • Vilka kundhändelsetyper som indikerar att kunden behöver göra någonting för att flödet skall fortskrida
    (kundhändelser av dessa kundhändelsetyper har värdet true på attributet producentarendetKraverKundatgard)

Flödet kan illustreras i ett flödesschema som skulle kunna se ut så här:

Exemplet ovan visar hur producentärendetypen för momsdeklaration skulle kunna se ut hos Skatteverket. Observera att det är endast ett exempel. Den riktiga processen kan absolut se annorlunda ut med andra kundhändelsetyper och ett annat flöde.

Producentärenden av denna typ börjar i pricken längst upp i diagrammet. Varje ruta beskriver kundhändelser som skickas när producentärendet fortlöper. Pilarna representerar möjliga ordningar mellan kundhändelsetyperna. Pricken med ram längst ned visar att när sista kundhändelsetypen kommit (i detta exempel Moms betalad) så anser producenten (i exemplet Skatteverket) att producentärendet är avslutat. Kunden kan mycket väl ha en annan uppfattning och vilja fortsätta handläggningen via ett överklagande eller liknande. Överklagandet kan tänkas ingå i samma producentärende och i så fall bör flödet illustrera det. I detta exempel hanteras istället ett eventuellt överklagande i en annan producentärendetyp.

För varje kundhändelsetyp som finns i kundhändelsetypskatalogen SKALL följande information finnas lagrad:

• Namn
• Identifierare (kundhändelsetyp med de 3 fälten för Aktör, Producentärendetyp och Steg)
• Relationer till övriga kundhändelsetyper via flödesdiagrammen för respektive producentärendetyp.
• Vilken behörighet som krävs för att få ta del av kundhändelser av denna typ
• URL/Pekare till producentens API där man kan hämta kundhändelser av denna typ

Dessutom KAN följande information finnas lagrad

• Rubrik
• Beskrivning
• URL/Pekare till producentens dokumentation över kundhändelser av denna typ

Skapa förståelse för information och flöden i kundhändeltypskatalogen

Med hjälp av informationen som finns i kundhändelsetypskatalogen kan en konsumenttjänst skapa förståelse för listan av kundhändelser som den har fått ifrån producenterna. Tabellen ovan med kundhändelser kan placeras in i respektive producentärende och konsumenttjänsten kan också förstå vilka kundhändelser som ännu inte kommit för respektive producentärende. På så sätt kan konsumenttjänsten avgöra status i respektive producentärende, se vilka som är färdiga och vilka som ännu ej påbörjats.

Med informationen om kundhändelser som faktiskt inträffat (instanserna i tabellen ovan) och vilka som borde komma i respektive producentärende (kundhändelsetyper i respektive producentärendetyp i från kundhändelsetypskatalogen) kan en konsumenttjänst skapa användargränssnitt som liknar vårt exempel i företagstjänsten:

I exemplet ser vi 4 instanser av producentärenden som kunden (Pia) behöver genomgå. Detta är de 4 producentärenden som beskrevs längst upp i detta dokument:

• Anmäl verklig huvudman (BV)
  Eftersom listan av kundhändelser som hämtats inte innehåller någon kundhändelse ifrån denna producentärendetyp vet konsumenttjänsten att detta producentärende ännu ej är påbörjat.
• Registrera dig som arbetsgivare (SKV)
  Ifrån kundhändelsetypskatalogen förstår konsumenttjänsten att denna producentärendetyp har tre steg med tre kundhändelser. Alla dessa finns det instanser ifrån i listan av kundhändelser och därmed kan alla visas som genomförda
• Registrera varumärke (PRV)
  Ifrån kundhändelsetypskatalogen kan konsumenttjänsten förstå att det finns ett alternativflöde där komplettering krävs (liknande moms-exemplet ovan). Det finns en kundhändelse av rätt typ för komplettering och denna har en kundhändelsekategori som indikerar att bollen ligger hos kunden. Konsumenttjänsten kan därför välja att visa alternativflödet och dessutom med en ikon indikera att bollen ligger hos kunden.
• Anmäl fettavskiljare (Sthlm stad)
  I kundhändelsetypskatalogen ser konsumenttjänsten att det finns tre kundhändelser som skall komma för att producentärendet skall anses vara klart. Dock finns bara två av dessa representerade i listan av kundhändelser som faktiskt kommit och därför kan konsumenttjänsten visa att de två första är genomförda, men inte den sista

Flera producenter med samma typer (kommuner eller regioner)

Kundhändelser som kommer ifrån myndigheter är (i det här sammanhanget) enkla eftersom myndigheten har 'monopol' på sitt verksamhetsområde och därför finns det endast en producent (myndigheten) som producerar kundhändelser i de producentärendetyper som myndigheten ansvarar för.

Men i fallet kommuner och regioner blir det lite mer komplicerat. Här finns flera producenter som har ansvar för samma verksamhetsområde. Det är till exempel flera kommuner som hanterar samhällsbyggnadsprocessen och därför skapar kundhändelser för till exempel hantering av bygglov. Dessutom finns ett självstyre som gör att kommunerna eller regionerna har rätt att organisera sin verksamhet såsom de själva finner bäst. Förutsättningarna för att bygga IT-stöd varierar också kraftigt mellan olika kommuner och regioner. Detta kan leda till att samma producentärendetyp (t ex hantera bygglov) har olika grad av digitalisering hos olika producenter.

Det är därför inte sannolikt att dessa producentärendetyper kommer att han en och samma bild över vilka kundhändelser som uppstår i dem hos olika producenter (samma producentärendetyp hos olika kommuner eller olika regioner). Kundhändelsetypskatalogen behöver alltså kunna hantera denna situation.

Vi tror dock att det finns ett värde för kommuner och regioner att samordna sig så att åtminstone vissa delar av deras producentärendetyper har samma kundhändelser. Vissa delar kommer att sammanfalla, medans vissa kommer att se olika ut. Arbetet att standardisera och samordna kommer att leda till en harmonisering mellan kommuner eller mellan regioner i hur definitionerna av kundhändelser ser ut, även om det inte kommer att vara en 100-procentig överensstämmelse.

Bilden ovan illustrerar situationen för en specifik producentärendetyp. Vi tänker oss ett hypotetiskt exempel där det finns två producenter (t ex två kommuner) som hanterar samma prducentärendetyp. Flödesschemat i mitten av bilden och till höger i bilden visar de två kommunernas definition. Vi kan här se att båda kommunerna har samma kundhändelsetyper för typ 1 och 3, medan 2, 4 och 5 skiljer sig åt.

Kundhändelsetypskatalogen behöver hålla reda på denna information och förstå hur producentärendetypen är implementerad hos de två producenterna. Kundhändelsetypskatalogen kommer att innehålla en sammanlagd bild (den vänstra i bilden) ur vilken den kan göra urval eller utsnitt för respektive producent.

Implementation

Kundhändelsetypkatalogen kommer att implementeras på central nivå, men informationen i den kommer att ägas av respektive producent.

Bilden ovan visar en skiss över vilka funktioner/komponenter som behövs i en kundhändelsetypskatalog. Vi skall gå igenom dem var för sig.

API
Den centrala delen av kundhändelsetypskatalogen är ett API som kan svara på frågor om informationen som är lagrad i kundhändelsetypskatalogen. API:et behöver innehålla endpoints för (åtminstone) följande frågor

• Lista vilka producentärendetyper som en specifik producent stödjer
• Beskriva flödet av kundhändelsetyper i en specifik producentärendetyp, både hur den ser ut generellt (över flera producenter) men även specifikt för en producent
• Beskriva detaljer av en eller flera specifika kundhändelsetyper

API:et kommer att vara ett REST-baserat API som levererar information i JSON-format. Informationen i kundhändelsetypskatalogen är på typnivå och inte instansnivå, vilket borde betyda att informationen är öppen. Därför behövs inte alltför hårda säkerhetskontroller för att komma åt informationen. Exakta detaljer får vi återkomma till.

Lagring
Informationen i kundhändelsetypskatalogen lagras i systemet, förmodligen i en databas av något slag. Viss information (se nedan i diskussionen om synkning med producenter) kommer också att finnas hos producenterna själva.

GUI för att uppdatera data
När producenter ansluter nya producentärendetyper eller när de ändrar i befintliga kommer informationen i kundhändelsetypskatalogen behöva ändras. I sin enklaste form kan detta göras via ett GUI där representanter ifrån producenterna kan editera informationen som finns lagrad i kundhändelsetypskatalogen. Det är dock viktigt att man i detta fall kommer ihåg att ändra även här (utöver att ändra i sin lokala verksamhet) och detta riskerar att glömmas bort.

Det finns dessutom ett antal andra liknande initiativ där producenter behöver hålla information om sina processer uppdaterade så det vore önskvärt med någon sorts samordning så att producenterna inte behöver hålla flera informationsmängder uppdaterade. Ett sådant exempel som identifierats är uppgiftskrav.se. Det finns mycket att vinna på att samordna uppdateringar av uppgiftskrav.se och kundhändelsetypskatalogen.

Åtkomst till detta GUI kräver en specifik behörighet per producent. Vem som helst skall inte få ändra på informationen och man skall inte heller få ändra informationen för någon annan producent än den man representerar.

GUI för att titta på data
Informationen som finns lagrad i kundhändelsetypskatalogen är inte bara intressant för system att ta del av. Även människor är intresserade av att förstå hur olika producenter har definierat sin verksamhet och vilka kundhändelser som uppstår vid vilka tillfällen. Därför behövs ett GUI som exponerar denna information.

Åtkomst till detta GUI bör vara relativt öppen. Informationen är inte känslig eftersom den endast är på typnivå.

Synkning med producenter
Vissa producenter kommer att vilja ha en egen lokal variant på en kundhändelsetypskatalog, dvs ett tekniskt system som håller reda på metadata om sina kundhändelsetyper och producentärendetyper. De behöver detta för sina egna behov. Detta gäller till exempel Skatteverket och Värmdö kommun. I dessa fall behöver inte informationen i den centrala kundhändelsetypskatalogen uppdateras manuellt utan istället kan man bygga en synkningslogik som hämtar data ifrån de lokala katalogerna via något API hos dem och sedan synkar den informationen med datat som finns lagrad centralt. En sådan synkning kan sedan köras regelbundet, t ex varje natt.

Man skulle kunna tänka sig en lösning där kundhändelsetypskatalogen inte lagrar den lokala information utan hämtar den vid behov ifrån aktuella producenter. Bedömningen är dock att detta blir komplicerat då man skulle behöva hålla reda på vilken del av informationen som finns lokalt i kundhändelsetypskatalogen och vilken som finns ute hos någon producent och i så fall vilken producent. Det blir enklare att se en helhet av informationen om allting finns på samma ställe, i kundhändelsetypskatalogen. Nackdelen med att göra så här är att vi behöver en mer komplex synkningslogik, men komplexiteten i detta fall är samlad endast hos synkningslogiken och sprider sig inte över hela kundhändelsetypskatalogen.