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

Forskellen mellem maksimer og principper

Styring af kommunens forvaltninger, styringen af IT (IT-governance) og effektiv styring af kommunens forretnings- og IT-arkitektur kan understøttes ved at etablere principper der kan bruges i situationer, hvor beslutningstagere og IT-arkitekter skal træffe beslutninger der kan have betydning for kommunens IT-indkøb og forretningsdesign.

Der er fundamentale forskelle mellem en maksime og et princip. En maksime er en slags overordnet sætning der skal lede beslutningstagerne i en retning der understøtter at den bedst mulige beslutning træffes. Et princip består af består en overskrift, indhold med baggrund samt de tilfælde, hvor det giver god mening at fravige princippet. Et godt princip er SMART-evauleret, hvilket vil sige at der tages højde for:

  1. Det er specifikt.
  2. Det er målbart.
  3. Det er opnåeligt (achiveable).
  4. Det er relevant.
  5. Det er tidsafmålt.

Eksempel

Københavns Kommune som eksempel, hvor følgende er defineret som principper:

  • Dialogen er en kerneopgave.
  • Tidlig dialog.
  • Tydelig dialog.
  • Engagerede dialog.
  • Mangfoldig dialog.

Københavns Kommune har ikke udviklet principper, men de har udviklet en række maksimer. Bemærk de omtalte principper er til at finde i PDF-filen. De omtalte principper er som sådan ikke IT-principper, men omhandler kommunikation, hvilket dog bør sætte rammerne for IT-løsninger der understøtter dette.

Problemet ved anvendelse af den fremgangsmåde er at det bliver svært at måle om beslutningstagerne og de udførende i Københavns Kommune har gjort levet op til maksimerne, og det kræver en del fortolkning af kommunens digitaliseringskonsulenter og IT-arkitekter for at kunne udvælge de IT-løsninger der understøtter principperne. Dermed er principperne hverken gode eller nyttige, men på trods af dette, så kan principperne i deres nuværende form sætte nogle rammer.

Konklusion

Principper og maksimer kan anvendes til at sætte rammerne for beslutninger for udvikling af kommunens forvaltninger og udvælgelse af IT-løsninger, dog kræver det at de enkelte kommuner arbejder aktivt med at formulere SMARTE-principper, hvis kommunerne forventes at få mere ud af principperne end løse rammer, hvor alle mulige beslutninger kan træffes og ingen kan hænges op på om principperne overholdes og om de har en effekt.