Best Prac­tices RPA

Das The­ma Ro­bo­tic Pro­cess Au­to­ma­ti­on (RPA) kommt im Un­ter­neh­mens­all­tag an. Auf dem Scheer Di­gi­tal World Con­gress 2018 be­rich­te­ten An­wen­der über ih­re Er­fah­run­gen und Best Prac­tices.

Computerwoche - - Inhalt - Von Man­fred Brem­mer, Se­ni­or Edi­tor IoT & Mo­bi­le

Im­mer mehr Un­ter­neh­men set­zen auf Ro­bo­tic Pro­cess Au­to­ma­ti­on (RPA). Scheer-Ma­na­ger Ul­rich Storck hat sie­ben Tipps, wie Sie Ih­re RPA-Vor­ha­ben er­folg­reich auf­set­zen kön­nen.

Be­trach­tet man den Gart­ner Hy­pecy­cle für Emer­ging Tech­no­lo­gies, er­reich­te das The­ma RPA (bei Gart­ner Smart Ro­bots ge­nannt) 2017 sei­nen Hö­he­punkt. Doch was pas­sier­te nach dem Hy­pe? Ver­schwin­det das The­ma wie­der von der Agen­da oder schafft es den Über­gang in die pro­duk­ti­ve Pha­se? Was für Er­fah­run­gen und Les­sons lear­ned gibt es be­reits? Mit die­sen Fra­gen be­fass­te sich Ul­rich Storck, Head of Pro­duct De­ve­lop­ment bei der Scheer GmbH, in ei­nem Vor­trag auf dem Scheer Di­gi­tal World Con­gress 2018 in Frank­furt am Main.

Storck ver­wies auf ei­ne Stu­die der In­for­ma­ti­on Ser­vices Group (ISG), für die knapp 250 Un­ter­neh­men aus Deutsch­land, Ös­ter­reich und der Schweiz zum The­ma RPA be­fragt wur­den. Der Er­he­bung zu­fol­ge be­fin­det sich mehr als die Hälf­te der be­frag­ten Be­trie­be der­zeit in ei­ner frü­hen pro­duk­ti­ven Pha­se mit Pi­lo­ten oder we­ni­gen Ein­zel­pro­jek­ten. Stra­te­gisch kommt die Au­to­ma­ti­sie­rungs­tech­nik aber meis­tens noch nicht zum Ein­satz. Sechs von zehn Un­ter­neh­men er­war­ten je­doch, in spä­tes­tens zwei Jah­ren min­des­tens zehn RPA-Pro­zes­se auf­ge­setzt zu ha­ben. Von die­sen Ear­ly Ad­op­ters will über die Hälf­te bis da­hin so­gar mehr als 25 Ge­schäfts­pro­zes­se an Soft­ware­ro­bo­ter über­ge­ben ha­ben. Wie Storck wei­ter aus­führt, stellt sich bei den An­wen­dern aber auch ei­ne ge­wis­se Er­nüch­te­rung ein – ge­bo­ren aus der Er­kennt­nis, dass RPA nicht die ei­er­le­gen­de Woll­milch­sau ist, son­dern nur ein Mit­tel von vie­len.

RPA: We­der He­xen­werk noch Selbst­läu­fer

Über be­reits um­ge­setz­te RPA-Pro­jek­te be­rich­te­te Di­mitar To­do­rov, Head of IT Ap­p­li­ca­ti­ons and In­te­gra­ti­on Ser­vices bei der Ener­gie­ver­sor­gung Nie­der­ös­ter­reich (EVN). Das Un­ter­neh­men mit knapp 7000 Mit­ar­bei­tern be­fin­det sich beim Ein­satz von Soft­ware­ro­bo­tern ge­ra­de in ei­nem Pro­of of Con­cept, hat aber über die letz­ten Mo­na­te schon sechs bis sie­ben An­wen­dungs­fäl­le rea­li­siert.

Das bis­he­ri­ge Er­geb­nis fällt laut To­do­rov weit­ge­hend po­si­tiv aus: Der Re­turn on In­vest (RoI) wer­de mit RPA „um Fak­to­ren bes­ser“, kon­sta­tiert der IT-Ver­ant­wort­li­che, auch die Ti­me to Mar­ket wer­de kür­zer. Au­ßer­dem sei die Um­set­zung kein He­xen­werk, wenn für ei­ne gra­fi­sche Schnitt­stel­le ent­wi­ckelt wer­de. Al­ler­dings, so To­do­rov, ist RPA nicht un­be­dingt ein Selbst­läu-

fer. So er­fül­le sich der Traum von Wie­der­ver­wen­dung nur sel­ten. Wich­tig sei es, die An­wen­dungs­fäl­le sorg­fäl­tig zu prü­fen. In ei­nem au­to­ma­ti­sier­ten Pro­zess Da­ten von A nach B zu schau­feln, ist laut To­do­rov der Ide­al­fall. Der IT-Ma­na­ger emp­fiehlt au­ßer­dem, bei ei­nem RPA-Pro­jekt al­le Sta­ke­hol­der recht­zei­tig ein­zu­be­zie­hen. Da­zu zäh­le auch der Be­triebs­rat. In sei­nem Un­ter­neh­men ha­be die­ser das Pro­jekt ak­tiv un­ter­stützt, da RPA da­zu bei­ge­tra­gen ha­be, Mit­ar­bei­ter von mo­no­to­nen und da­mit frus­trie­ren­den Tä­tig­kei­ten zu be­frei­en.

Zu­dem dürf­ten die IT-Ver­ant­wort­li­chen nicht ver­ges­sen, dass sie sich mit RPA ei­ne wei­te­re Tech­no­lo­gie ins Haus hol­ten – mit al­len Kon­se­quen­zen. Wer­de RPA erst ein­mal in der Brei­te ein­ge­setzt, han­de­le es sich um ein wei­te­res ge­schäfts­kri­ti­sches Sys­tem, bei des­sen Aus­fall gan­ze Pro­zess­ket­ten still­ste­hen könn­ten. Au­ßer­dem ha­be RPA li­zenz­tech­ni­sche Aus­wir­kun­gen auf Dritt­pro­duk­te et­wa von SAP.

Bei ei­nem re­la­tiv neu­en The­ma wie RPA ist fer­ner die Kom­pe­tenz des Tech­no­lo­gie­part­ners wich­tig. „Vie­le ken­nen das Po­ten­zi­al noch nicht“, er­klärt To­do­rov, auch das Wis­sen über die Vor- und Nach­tei­le der ver­schie­de­nen Lö­sun­gen am Markt rei­che oft nicht aus. Aus die­sem Grund sei ein Part­ner ge­fragt, der die Tech­nik be­herrscht und sich aus­kennt.

RPA als Self-Ser­vice

In­ter­es­sant ist die Art und Wei­se, wie der ös­ter­rei­chi­sche Ener­gie­ver­sor­ger die in­ter­ne Zu­stän­dig­keit ge­re­gelt hat: Die IT bie­tet den Fach­be­rei­chen RPA als ei­ne Art Self-Ser­vice an, al­ler­dings nur an­ge­lern­ten be­zie­hungs­wei­se ein­ge­wie­se­nen Mit­ar­bei­tern, da ge­wis­se Pro­gram­mier­kennt­nis­se er­for­der­lich sind. Hin­ter­grund war das In­ter­es­se der Fach­ab­tei­lun­gen, selbst Pro­zes­se aus­zu­wäh­len und dem Soft­ware­ro­bo­ter zu über­ge­ben, so EVN-Mann To­do­rov. Im Prin­zip sei das rich­tig ge­we­sen. Man müs­se aber be­den­ken, dass es sich bei RPA um Soft­ware­ent­wick­lung hand­le, und da­mit sei ei­ne Qua­li­täts­si­che­rung er­for­der­lich. An­de­rer­seits brau­che man für An­pas­sun­gen aber auch die Kennt­nis­se aus dem Fach­be­reich.

Die RPA-An­bie­ter wis­sen, dass sie sich mit ih­ren Pro­duk­ten an der Schnitt­stel­le zwi­schen IT und Ge­schäfts­be­rei­chen bewegen. Das gilt na­tür­lich auch für die Scheer GmbH. So bie­tet das Karls­ru­her Un­ter­neh­men mit sei­ner „Scheer Pro­cess Au­to­ma­ti­on Sui­te“(Scheer PAS), die ei­ne Lö­sung des RPA-Spe­zia­lis­ten Ui­path in­te­griert, be­reits ei­ne Low-Code-Platt­form für die mo­dell­ge­trie­be­ne Di­gi­ta­li­sie­rung und Au­to­ma­ti­sie­rung von mensch­li­chen Ar­beits­pro­zes­sen.

Das Au­gust-Wil­helm-Scheer-In­sti­tut (AWSI) wie­der­um ent­wi­ckelt ei­ne Me­tho­de, mit de­ren Hil­fe Ar­beits­pro­zes­se au­to­ma­ti­siert er­fasst und do­ku­men­tiert wer­den kön­nen. Mit Desk­top Ac­tivi­ty Mi­ning, das Tech­ni­ken aus dem Da­ta und Pro­cess Mi­ning nutzt, wür­den Vor­ar­bei­ten ent­fal­len, die bis­her für RPA not­wen­dig wa­ren. Im De­tail wer­den über ein im Hin­ter­grund lau­fen­des Auf­nah­me­pro­gramm die re­le­van­ten Pro­zess­ak­tio­nen der Mit­ar­bei­ter wie Text­ein­ga­ben, Maus­klicks oder Pro­gramm­auf­ru­fe iden­ti­fi­ziert und an­ony­mi­siert er­fasst. Aus die­sen wer­den dann mit Pro­cess-Mi­nin­gAl­go­rith­men Pro­zess­mo­del­le ge­ne­riert, um ei­ne um­fang­rei­che Darstel­lung des rea­len Ar­beits­pro­zes­ses zu er­hal­ten.

Laut AWSI setzt Desk­top Ac­tivi­ty Mi­ning im Ge­gen­satz zu klas­si­schen Pro­cess-Mi­ning-An­sät­zen, bei de­nen nur Trans­ak­ti­ons­da­ten aus IT-Sys­te­men zur Be­schrei­bung ei­nes Ge­schäfts­pro­zes­ses ge­nutzt wer­den, auf der di­rek­ten Ar­beits­ebe­ne der Mit­ar­bei­ter an. Es wer­den al­so auch sol­che Ak­tio­nen er­fasst, die trotz ih­rer Pro­zess­re­le­vanz bis­her nicht durch vor­han­de­ne IT-Sys­te­me do­ku­men­tiert wer­den kön­nen – bei­spiels­wei­se das Schrei­ben ei­ner E-Mail.

24

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.