Lösningsval kanal
Ä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 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.
Exempel 2
Förvaltningen har inget systemstöd alls.
Ärenden kommer in via blanketter via post eller e-post till en funktionsbrevlåda.
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
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.
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.
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.
Fördelar
Kan ge grundläggande automatisering och även automatiserat beslutsfattande om möjlighet finns.
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.
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.