Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Ärendehantering

Interna och externa ärenden kommer att hanteras i parallella lösningar men följer samma lösningsmönster.

De främsta skälen att separera extern och intern ärendehantering är:

  • Lägger vi allt i samma lösning (samma komponenter) får vi en komplex lösning med många integrationer och mycket kod vilket gör livscykelhanteringen av lösningen kostsam över tid

  • Av säkerhetsmässiga skäl är det klokt att separera intern och extern ärendehantering - en attack på vår lösning för extern ärendehantering ska inte kunna påverka vår interna dito.

Extern ärendehantering

Med extern ärendehantering menas ärenden som initieras av externa intressenter, som till exempel bygglovsärenden, miljökontorsärenden, parkeringstillståndsärenden mm mm. Ärenden kan inkomma från både fysiska och juridiska personer och i en framtid kan även ombud vara aktuellt för i första hand fysiska juridiska personer. Ombud realiseras med hjälp av den nationella lösningen för ‘Mina Ombud’ som tillhandahålls av Bolagsverket https://minaombud.se/ .

Exempel 1

Förvaltningen har ett system i vårt hindrande digitala arv där ärenden registreras.

Ärenden kommer in via blanketter via post eller e-post till en funktionsbrevlåda.

Gliffy
imageAttachmentIdatt1121681501
macroId0a96c8ff-9a93-4360-9d68-1ca0a7be538f
baseUrlhttps://sundsvall.atlassian.net/wiki
nameramverksval kanal
diagramAttachmentIdatt1121779822
containerId1121681494
timestamp1668755954930

Exempel 2

Förvaltningen har inget systemstöd alls.

Ärenden kommer in via blanketter via post eller e-post till en funktionsbrevlåda.

Gliffy
imageAttachmentIdatt1123385404
macroId6c2d31b9-0b8f-4fbf-85df-436a1bc334ac
baseUrlhttps://sundsvall.atlassian.net/wiki
nameramverksval kanal2
diagramAttachmentIdatt1123221563
containerId1121681494
timestamp1669095539964

Intern ärendehantering

Med intern ärendehantering menas ärenden som initieras av interna intressenter - främst supportärenden. En intern intressent är någon som verkar inom kommunkoncernen dvs även våra bolag. Detta gäller även för handläggaren som kan finnas inom kommunkoncernen.

Exempel

Gliffy
imageAttachmentIdatt1123647622
macroIdb7c27ee6-4c53-4e89-88fe-bbe75f3e1f90
baseUrlhttps://sundsvall.atlassian.net/wiki
nameinternCM
diagramAttachmentIdatt1123713165
containerId1121681494
timestamp1669095722407

Exempel på tillämpningar och möjliga angreppssätt för olika case

Förutsättningarna skiljer sig åt mellan olika verksamheter och här behöver en praktisk och kanske taktisk värdering göras i många avseenden:

  • Behov

  • Volymer

  • Antal medarbetare som arbetar i processen

  • Timing dvs när behöver ett nytt stöd finnas på plats

  • Struktur och kännedom om processen är den befintlig eller helt ny

  • Avvikelser i processen

  • Eventuella kommande ändringar t.ex. byte av system

  • Tekniska förutsättningar

  • Möjlighet att påverka processen - utmana vad som är måste och relevant idag inte vad man blivit upplärd

Case: A | Verksamhet som arbetar med blanketter och/eller ostrukturerad data, ofta i e-post. Kan även röra en helt ny process

Angreppssätt

  • Fokusera på att få insamling av information i processen strukturerad genom att introducera e-tjänst.

  • Erbjud verksamheten handläggargränssnitt i OeP för att få ett grundläggande stöd för ärendehantering.

  • Om möjligt få verksamheten att upphöra med funktionsbrevlådor både vad gäller inkommande ärenden men också som handläggningsstöd.

  • Stötta verksamheten med att förstå processen, kanske kan den förenklas genom att information inte behöver inhämtas då vi redan har den t.ex. användarnamn eller adresser.

  • Applicerbart både för interna och externa ärendeflöden.

Tip

Fördelar

  • Låg instegs kostnad.

  • Enkelt att komma igång.

  • Lätt att anpassa.

  • Inget behov av IT utveckling.

  • Möjlighet för handläggare att skapa ärenden för att ha alla ärenden i ett system t.ex. om ärenden fortsatt inkommer via blankett.

Note

Nackdelar

  • Graden av automatisering är begränsad till t.ex. uppslag och valideringar som går att göra i e-tjänsten.

  • Kan vara utmanade i processer eller verksamheter där blanketten är huvudalternativet idag.

  • Om verksamhetssystem finns så har snarare den manuella hanteringen blivit digital istället för som tidigare analog – ingen digitalisering utan mera s.k. “digitisering”

Case: B | Verksamhet med stabila processer och nyttjande av e-tjänster, men dåliga möjligheter till integration mot bakomliggande verksamhetssystem

Angreppssätt

  • Säkerställ att den befintliga e-tjänsten samlar in data strukturerat och har stöd för XML taggning

  • Värdera om RPA är en lösning helt eller delvis för att processa ärenden från e-tjänsten där verksamhetssystemen inte möjliggör integrationer. RPA lösningen är här att beakta som en s.k. “gap filler” dvs en lösning i väntan på att bättre förutsättningar finns på plats.

  • Stötta verksamheten med att föreslå förbättringar som möjliggörs med teknik samt guida verksamheten i hur en ny process där automatisering introduceras kan utformas och göras så rationell som möjligt.

Tip

Fördelar

  • Kan ge grundläggande automatisering och även automatiserat beslutsfattande om möjlighet finns.

Note

Nackdelar

  • Kräver bra nyttokalkyl då lösningen inte har en lång hållbarhet (beroende på verksamhetssystemets förmodade livslängd).

Case C | Verksamhet med stabil och etablerad process, ofta vana vid e-tjänster, som behöver bättre automatisering i sin handläggning

Angreppssätt

  • Arbeta noga igenom processerna för att säkerställa hur handläggning går till och ska gå till med ett modern IT stöd.

  • Säkerställ att API stöd finns i alla integrationer som ska vara i realtid men helst även övriga integrationer.

  • Identifiera ett första scope (MVP) som är möjligt att börja använda i någon omfattning för att sedan skala upp.

  • Anpassa e-tjänsten till att vara integrationsbaserad mot underliggande API infrastruktur.

Tip

Fördelar

  • Möjliggör hög grad av automatisering t.ex. kan samtliga ärenden som kommer in valideras automatiskt och ett antal grundkontroller kan göras t.ex. om det finns andra ärenden som kan behöva beaktas.

  • Möjliggör automatiserat beslutsfattande där det finns större tydlighet i vilken logik som tillämpats vid beslutet.

  • Ger verksamheten ett integrerat ärendehanteringssystem där statusar och flöden kan göras än mer synligt för handläggaren. T.ex. är det inget problem att ett ärende som är markerat som klart mot en medborgare kan fortsätta i kommunens handläggning t.ex. framställande busskort som ska distribueras efter att beslut kommunicerats. Det går också att ha händelser i ett avslutat ärende t.ex. att historik visar att vi påmint om att ett visst ärende löper ut och att man kan ansöka om ny period.

  • Ger möjligheter till rationellt nyttjande av övrig API infrastruktur t.ex. möjlighet till automatiserade utskick i olika kanaler, möjlighet att framställa debiterings/faktureringsunderlag.

Note

Nackdelar

  • Kräver ett grundligt arbete och stor inblandning från verksamheten för att få full effekt.

  • Inblandning av fler roller och kompetenser, kräver ofta IT projektledare och huvudprojektledare för att samarbeta och driva ett införande i verksamheten.


Tjänsteutveckling

Med tjänst avses här tjänster som konsumeras av våra intressenter digitalt, som t ex:

  • Se mina uppgifter (adress, kontaktuppgifter mm)

  • Hantera mina kontaktuppgifter

  • Se mina pågående ärenden

  • Uppdatera pågående ärende

  • Se mina fakturor

  • Sök artiklar för återbruk

  • med mycket mera

Införandet av en ny tjänst, eller när lösningen för en befintlig tjänst ska bytas, ska följa de principer som är specificerade i vår API strategi, och nedan principer ska vara särskilt vägledande:

  • Vi designar homogena lösningar baserat på de processer i vilka vi som kommun möter våra intressenter.
    En sådan process kan spänna över flera förvaltningar/bolag, men upplevs av intressenten som en homogen kontakt med kommunen.

  • Funktioner ska i så stor utsträckning som möjligt designas och byggas fullt ut återanvändbara för alla processer där samma behov dyker upp.

Detta innebär:

  • Vid införande av en ny tjänst, eller när en befintlig tjänst ska bytas, så ska “kundresan” beaktas

    • Är tjänsten helt fristående eller ingår den i ett större flöde alternativt naturligt hänger ihop med andra tjänster?

      • Ingår tjänsten i ett större flöde alternativt naturligt hänger ihop med andra tjänster ska lösningen designas därefter och byggas i de ramverk som bäst möjliggör detta

  • Vid införande av en ny tjänst ska den designas och byggas fullt ut återanvändbar (om det inte kan fastslås att tjänsten är så unik att andra användningsområden aldrig kommer uppstå) och därefter byggas i de ramverk som bäst möjliggör detta

Exemplifierat med “se mina pågående ärenden”:

  • Tjänsten ingår både i större flöden samt hänger naturligt ihop med andra tjänster

  • Tjänsten kommer att vara återanvändbar för många intressentgrupper

Detta innebär att tjänsten ska etableras som en komponent i vår målarkitektur (som bl a kommer vara en återanvändbar lösning för flera Mina Sidor -applikationer) och presentationsdelen ska byggas i webb-ramverket.