Digitalisering ved hjælp af RPA

Odense Kommune (Boye, 2017a) og Københavns Kommune (Boye, 2017b) har påbegyndt egentlige IT-projekter der tager deres udgangspunkt i digitalisering af forretningsprocesser. Software robotterne anvendes til at understøtte at IT-systemer integreres og forretningsprocesserne vil hænge sammen.

Det er en fryd at kunne læse, at kommunerne efterhånden er nået så langt med at digital-understøttelse af forretningsprocesser, at forretningsprocesserne også kan automatiseres.

Der findes dog også visse udfordringer ved at anvende software robotter til at integrere via grafiske brugergrænseflader mellem IT-systemer. Hvad vil der sker, hvis en grafisk brugergrænseflade udskiftes eller opdateres? Vil integrationen ændre sig automatisk eller vil den fejle? Dermed sagt det er fint og flot af Odense Kommune at kunne udvikle og implementere de nye integrationer inden for blot 7 uger, men der findes tilsvarende en række udfordringer der kræver en stram styring af IT i kommunerne der vælger RPA, måske endda strammere end det som kendetegner integrationer via webservices og API’er i en service-orienteret arkitektur. Og overholder RPA-integrationerne også de grundlæggende arkitektur tanker i MOX, som er Kommunernes Landsforenings de facto standard for integrationer?

IT-styring

For at kommunerne på sigt vil få succes med RPA, så kræver det, at kommunerne aktivt arbejder med Application Portfolio Management som efterhånden er en moden disciplin blandt organisationer der har arbejdet med service-orienteret arkitektur. Forskellen mellem det niveau der skal anvendes i RPA-sammenhænge og SOA-sammenhænge er, at ændringer i grafiske brugergrænseflader, som RPA anvender, sker oftere. RPA-integrationer (eller bløde integrationer) kan derfor have sine fordele ved at være nemmere at udvikle, men grundlaget for at anvende dem effektivt på længere sigt er lige så komplicerede som med SOA. RPA-integrationer virker samtidigt som om de ikke har sfordelene ved at anvende relativt stabile API’er og kontrakt mellem dataudvekslinger.

Konklusioner

RPA fremgangsmåden til integrationer kan vise sig på kortsigt at være et ”quick-fix”, men på sigt vil man også opleve at selve driften integrationerne der udvikles vil være svære og ofte mere tidskrævende end ved valget af en service-orienteret arkitektur (webservices og API’er). Ændringer, tid og projekterne vil med tiden vise at det vil være omkostningstungt at udvikle med RPA frem for med webservices og API’er. På visse områder minder anvendelsen af RPA om den samme hype som der var med SOA og med databaseintegrationer, hvortil kommunerne snart vil støde på udfordringer.

Kilder

Boye, M. (2017a). Odense implementerede software robotter på syv uger. URL https://www.version2.dk/artikel/odense-implementerede-software-robotter-paa-syv-uger-lim-vi-har-ledt-efter-1075145

Boye, M. (2017b). Robothær løfter tonsvis af idiot opgaver i Københavns Kommune. https://www.version2.dk/artikel/robothaer-loefter-tonsvis-idiot-opgaver-koebenhavns-kommune-1073401

Grunddata

Kommunerne råder over en række grunddata om sin organisation og oplysninger om kommunens geografiske data, og ligeledes har kommunerne ofte brug for at anvende egne grunddata til at understøtte effektivisering af intern administration såvel som mulighederne for at give borgerservice.

Data kommunerne råder over

De fleste kommuner råder over en række vigtige grunddata der alle viser sig yderst relevante for de fleste andre typer organisationer både i den offentlige sektor såvel som virksomheder i den private sektor, især i forhold til at skabe sig adgang til nye informationer

Kommunerne indberetter en række interessante og ikke mindst relevante data som kan bruges ikke alene af kommunen selv, men af en række forskellige interessenter, hvilket også gælder beslutningstagere i den offentlige sektor.

Oplysningerne som kan vise sig relevante for kommunerne i forvejen råder over via forskellige løsninger, og som kommunerne med fordel kan genanvende:

  1. Geodata om kommunernes geografiske struktur.
  2. Kommunernes organisatoriske strukturer.
  3. Kommunernes projektporteføljer.

De ovenstående datakilder kan bruges i forhold til at give beslutningstagerne i kommunerne en indsigt i, hvordan kommunerne er strukturerede m.v.

Data kommunerne henter

For at kommunerne kan gennemføre sagsbehandling, så kræver det at kommunerne har adgang til en række forskellige datakilder.

Eksempler på datakilder er som følgende:

  1. Personddata (CPR).
  2. Virksomhedsdata (CVR).
  3. BBR-data.

De ovenstående datakilder har ofte været behæftet med en afgift at anvende for den enkelte kommune, hvilket betyder at kommunen ofte har haft nogle omkostninger der er relateret til intellektuelle rettigheder for at sikre at kommunernes forvaltningers forretningsprocesser understøttede en effektiv borgerbetjening.

Bedre udnyttelse af datakilder

Der findes flere forskellige typer initiativer der skal sættes i gang med henblik på få etableret teknologierne (d.v.s. teknologistakken) og sikret at de enkelte integrationsplatforme i de enkelte kommuner bliver forvaltet hensigtsmæssigt.

Teknologier

Kommunerne kan få en bedre udnyttelse af de data, som den enkelte kommune råder over, og samtidigt få en bedre anvendelse af de fælles offentlige registrer, så bør kommunerne i så høj en grad det er muligt sikre at de forskellige IT-løsninger der anvendes i kommunerne kan trække de relevante data fra de relevante platforme. Det vil sige at kommunerne også selv bør gå i gang med at identificere mulighederne med at etablere den digitale infrastruktur som vil gøre det muligt for de enkelte kommune at kunne tilslutte nye IT-løsninger og nedbryde tekniske siloer, som gør at forretningsprocesser ellers ville være håndbårne processer.

Kommunerne må derfor hver især arbejde med en omstilling til, at interne integrationsplatforme kan etableres eller tilsvarende fælles kommunal infrastruktur etableres fx ved anvendelsen af VeRA (integrationsplatform) eller en anden teknologistak, som vil kunne understøtte en nem og effektiv model til integration af data mellem grunddata kilder og applikationer der bruger dem.

Etablering af integrationsplatformen

Den enkelte kommune kan ikke forvente, at den nødvendige digitale infrastruktur kommer på plads af sig selv. Den enkelte kommune må derfor etablere et egentligt projekt, hvor en projektleder får til hensigt at få etableret platformen. En digitaliseringskonsulent eller IT-arkitekt kan agere som teknisk projektleder som bør arbejde med at få afdækket de datakilder, som den enkelte kommune anvender, og hvordan der kan integreres op imod den.

Forvaltning af integrationsplatformen

Efter integrationsplatformen er blevet implementeret og platformen er driftsmodnet, så vil det være nødvendigt for den enkelte kommune, at sikre at de individuelle integrationsplatforme bliver styret til de enkelte kommunernes behov. De enkelte kommuner har hver deres behov i forhold til anvendelse af integrationerne, da de ofte har meget forskellige typer organisationer, og de har meget forskellige ambitionsniveauer på bestyrelsesniveauet såvel som i direktionen og i mellemledelsen, men fælles for alle kommunerne er at integrationsplatformen skal være driftsstabil og integrationsplatformen skal være sikker samt integrationsplatformen skal være nem at udvikle til.

De enkelte kommuner vil antageligvis have forskellige måder at tilgå opgaven med at styre deres respektive integrationsplatforme.

Forvaltning af grunddata

De enkelte kommuners integrationsplatforme skal styres, hvis den enkelte kommune skal opnå en fornuftig drift og afkast af investeringen. Integrationsplatformene er kun en måde at understøtte implementeringen af delingen af data fra de grunddata systemerne, og derfor kræver det at den enkelte kommune også får etableret en dataejer rolle, som står for at grunddata bliver anvendt på bedst mulig måde, og at datakvaliteten løftes. Dataejer rollen skal kunne koordinere på tværs af den enkelte kommunes forvaltning.

Konklusion

Der findes en række udfordringer i kommunerne med at få skabt den sande værdi ved at registrere data om borgerne, virksomhederne, NGO’erne og brugerne af kommunernes ressourcer. Udfordringerne omhandler bl.a. at kommunerne gør brug af datakilder der kun øger omkostningerne for kommunernes drift, og kommunerne kan kun realisere den fulde værdi ved at skifte til de relevante datakilder, og at hver kommune implementere noget der minder om en lokal integrationsplatform der kan bruges til at trække data fra de relevante datakilder, behandle data og integrere de forbrugere af data der er tilgængelige.

Den enkelte kommune kan ikke komme uden om behovet for styring af den enkelte integrationsplatform, og den enkelte kommune kan ej heller komme uden om at få etableret ansvarlige for opretholdelse af datakvaliteten i kommunernes datakilder.

Udfordringer ved borgervendte selvbetjeningsløsninger

Borgere, virksomheder og NGO’er har alle et behov for at kunne kommunikere med de kommuner, hvor de har til huse, og det har ligeledes vist sig for de fleste organisationer i den offentlige sektor, at der er en positiv business case ved at understøtte digital kommunikation med borgere, virksomheder og NGO’er. Trods den gode business case og indsatser over flere omgang så findes der stadig et kæmpe udviklingspotentiale i de kommunale selvbetjeningsløsninger, og der findes stadig en del udfordringer med at anvende dem.

Kommunerne bør derfor arbejde med at sat indkøb og udvikling af selvbetjeningsløsninger ind i den rette proces, og kommunerne bør ligeledes arbejde med at få inkluderet omkostninger til design, tests og vedligeholdelse af selvbetjeningsløsningerne.

Dårligt design

Kommunerne har både en række udfordringer og en række mulige løsninger på at få rettet op på de trends der findes i øjeblikket for kommunale IT-løsninger.

Udfordringer

Nedenstående er typiske tegn på at der vil opstå udfordringer med selvbetjeningsløsningerne:

  • Borgerne bliver ikke involveret.
  • Brugerne i kommunen bliver kun delvist involveret.

Mulig løsning

Kommunerne skal involvere borgere i forskellige aldersgrupper og i forskellige samfundslag. Dermed sagt skal kommunen begynde at få skabt kontakt til de potentielle brugere af selvbetjeningsløsningen. Det betyder at digitaliseringskonsulenten eller IT-arkitekten skal have identificeret den eller de målgrupper der skal bruge løsningen, og en repræsentativ gruppe skal inviteres ind til workshops, om hvordan selvbetjeningens forventes anvendt, og hvad der skal til for at få selvbetjeningsløsningen til at være brugervenlig.

De administrative medarbejdere skal ligeledes på workshops med henblik på at få styr på den kontekst som selvbetjeningsløsningen skal anvendes i, og hvordan brugergrænsefladen skal være designet med henblik på at imødekomme sagsbehandlingen.

Brugerne skal involveres til at få “optegnet” et bud på en grafisk brugergrænseflade. Brugergrænsefladen skal leverandøren i hænde, så selvbetjeningsløsningernes brugergrænseflader bliver udviklet rigtigt første gang.

Kommunerne skal følge op på brugen af selvbetjeningsløsningerne, og jævnligt holde brugergrænsefladerne opdateret. Sidst men ikke mindst så bør kommunerne aktivt involvere de mennesker, som i kommunen vil stå for at holde selvbetjeningsløsningen og det samlede system opdateret, da de skal kunne indgå i opsætningen.

IT-sikkerhed

De borgervendte selvbetjeningsløsninger kan udgøre både en effektiviseringsfaktor og en IT-sikkerhedsmæssig risiko, hvis de designes forkert, eller værre endnu bruges forkert. IT-sikkerhed er et emne som bliver mere og mere relevant for kommunerne, og udfordringerne med at gøre løsningerne anvendelige og samtidigt sikre.

Udfordringer

Nedenstående er typiske tegn på at der vil opstå udfordringer med selvbetjeningsløsningerne:

  • Data fra kommunens “borgervendte” zone på netværket skal i kontakt med administrative systemer på den sikre zone. Åbning af netværkszonen kan give adgang til uønskede mennesker adgang til data.
  • Data kan vise sig at være korrupte, hvilket kan påvirke stabiliteten af administrative systemer.
  • Ustabile administrative systemer kan lede til ustabile forretningsprocesser.

Mulig løsning

Det giver mening i de fleste tilfælde for kommunerne at gøre transporten af data fra selvbetjeningsløsningen til de administrative systemer asynkrone. Ydermere skal filer der flyttes fra selvbetjeningsløsningerne ind på den sikre netværkszone scannes, og inficerede filer skal kasseres. Filer der kommer i kendte formater kan ydermere omskrives, så eventuelt indlejrede makroer bliver fjernet. Anvende asynkrone integrationer, hvor data flyttes fra en beskedkø i kommunens DMZ til den sikre zone. Sidst men ikke mindst, så skal dataforbindelserne mellem selvbetjeningsløsningerne fra usikre til sikre zoner være krypterede, så mulige indtrængere på kommunernes de-militarized zoner, ikke kan “lytte” med til kommunikationen, og få adgang til de data der sendes.

Integration til administrative systemer

Kommunerne har behov for at kunne anvende data sikkert, stabilt og effektivt. Data fra selvbetjeningsløsningerne kan derfor med fordel få udviklet integrationer mellem de borgervendte selvbetjeningsløsninger og de administrative systemer (såvel som fagsystemer) der kan anvende data til at gøre forretningsprocesserne mere sammenhængende og mere effektive.

Udfordringer

Der findes forskellige udfordringer der kan have indflydelse på om system-til-system integrationerne vil bidrage med den størst mulige værdi:

  • Etablering af system-til-system integrationer til selvbetjeningsløsninger kan hurtigt vise sig uoverskuelige, hvis mange systemer anvender dem.
  • System-til-system integrationer kan vise sig uoverskuelige at vedligeholde, hvis de ikke findes på en central integrationsplatform.
  • System-til-system integrationer kan vise sig svære at anvende effektivt mellem systemer, hvis de kun er synkrone.

Herudover kan der opstå udfordringer med system-til-system integrationer, når selvbetjeningsløsningerne og de administrative systemer opdateres eller sidenhen opgraderes. Dermed sagt så bliver det nødvendigt for kommunerne at tage mere ejerskab over løsningerne og planlægningen af indkøb og opdateringen. Kommunerne bør også forvente flere omkostninger ved indkøb af IT-løsninger.

Mulig løsning

For at selvbetjeningsløsninger kan skabe den størst mulige værdi for kommunen så skal de data der kommer fra selvbetjeningsløsningen kunne flyttes over i administrative systemer automatisk. Dette kræver at der udvikles integrationer mellem selvbetjeningsløsningerne og de administrative systemer.

Integrationerne må forventes at blive mere og mere efterspurgte, og det gør samtidigt at, hvis der opstår en fejl på en af integrationerne til selvbetjeningsløsningen, så vil det kræve flere ressourcer at få rettet op på fejlen. Den ekstra tid og de ekstra ressourcer vil gøre det mere omkostningsfuldt for kommunen at få sine forretningsprocesser til at fungere korrekt.

Integrationerne kan i visse tilfælde kunne genbruges, hvis de er centraliseret på en integrationsplatform, hvor det vil være muligt at anvende en række integrationsmønstre, men også at få sikret overvågning, service level agreements m.v.

Konklusion

Kommunerne skal arbejde på at få styr på forretningsarkitekturen og applikationsarkitekturen for deres selvbetjeningsløsningerne. Kommunerne må indregne omkostningerne til bedre design, bedre sikkerhed og integrationer mellem selvbetjeningsløsningerne og de administrative systemer.

Kommunerne skal stille krav til, at selvbetjeningsløsningerne der indkøbes overholder god skik for IT-sikkerhed herunder:

  1. Kryptering af forbindelse.
  2. Kryptering af indhold på selvbetjeningsløsningen.
  3. Skanning af filer fra usikker til sikre zone.
  4. Asynkrone integrationer, så data ikke kommer direkte ind på den sikre zoner.

Kommunerne skal, når de udarbejder business cases for indkøb af selvbetjeningsløsninger og administrative systemer, at systemernes sikkerhedsmodeller skal opdateres over tid, og dette kan kræve, at IT-løsningerne skal udvikles og implementeres. Ændring i sikkerhedsmodellerne kan ligeledes betyde, at integrationerne mellem systemerne begynder ændre adfærd.