6. August 2021

Von Dr. Mar­tin Böhn & Sabi­ne Kraus

Bes­ser, schnel­ler und fle­xi­bler mit Infor­ma­tio­nen arbei­ten kön­nen: Dies ver­spre­chen vie­le Sys­te­me bzw. Her­stel­ler. Gute Soft­ware soll ein wert­vol­les Werk­zeug sein. In vie­len Pro­jek­ten sind die Sys­te­me aber zusätz­li­che Hür­den. Vie­le Aus­wahl- und Ein­füh­rungs­pro­jek­te schei­tern, weil die Anwen­der nicht die erhoff­te Unter­stüt­zung erfah­ren, die Sys­te­me nicht inte­griert sind und weil die orga­ni­sa­to­ri­sche Ver­an­ke­rung fehlt. Kla­re Zie­le und ein struk­tu­rier­tes Vor­ge­hen hel­fen, die Mit­ar­bei­ter ein­zu­bin­den und aus unüber­sicht­li­chen Soft­ware­märk­ten die rich­ti­ge Lösung zu fin­den. Gera­de beim The­ma Digi­tal Work­place sind kla­re Stra­te­gien und struk­tu­rier­te Vor­ge­hens­wei­sen wich­tig.

Die Ent­täu­schung ist groß, wenn die mit viel Enthu­si­as­mus und gro­ßen Visio­nen gestar­te­ten Pro­jek­te ins Sto­cken gera­ten oder ganz ein­ge­stellt wer­den. Zumeist schei­tert es nicht an der inves­tier­ten Zeit. Vie­le Pro­jek­te lau­fen mona­te­lang – manch­mal jah­re­lang – und die jewei­li­gen Pro­jekt­ma­na­ger tra­gen ord­ner­wei­se Infor­ma­tio­nen zusam­men. Doch ohne Ziel und Struk­tur ver­lie­ren sich vie­le Pro­jek­te in den unklar defi­nier­ten Ein­satz­sze­na­ri­en und der unüber­sicht­li­chen Anbie­ter­land­schaft. Oft wer­den am Ende ent­we­der gar kei­ne Sys­te­me beschafft oder nur iso­lier­te Ein­satz­sze­na­ri­en umge­setzt. So ent­ste­hen Infor­ma­ti­ons­si­los und ein Fli­cken­tep­pich an Sys­te­men, was den Zugriff auf wich­ti­ge, aktu­el­le und voll­stän­di­ge Infor­ma­tio­nen wei­ter erschwert. Gera­de mit Blick auf den Digi­tal Work­place ist es nicht ent­schei­dend, mög­lichst vie­le Infor­ma­tio­nen zu erhal­ten und abzu­le­gen, son­dern die­se in einen inhalt­li­chen, ent­schei­dungs­be­zo­ge­nen Kon­text zu brin­gen.

Kla­re Zie­le: Visi­on und kon­kre­te Ein­satz­be­rei­che

Grund­la­ge für jedes Pro­jekt zur Aus­wahl und Imple­men­tie­rung eines IT-Sys­tems muss eine klar for­mu­lier­te und rea­lis­ti­sche Ziel­set­zung sein. Die Pro­jekt­be­tei­lig­ten und Ver­ant­wort­li­chen müs­sen erreich­ba­re Zie­le set­zen und die not­wen­di­gen Res­sour­cen bereit­stel­len. Nur durch eine Auf­nah­me der Gege­ben­hei­ten und Rah­men­be­din­gun­gen und der dar­auf basie­ren­den Erar­bei­tung eines Pro­jekt­plans kann sicher­ge­stellt wer­den, dass dem gesam­ten Pro­jekt­team bewusst ist, was erreicht wer­den soll und wel­che not­wen­di­gen Auf­ga­ben dafür defi­niert wer­den müs­sen.

Die­se Visi­on muss auf kon­kre­te Ein­satz­be­rei­che her­un­ter­ge­bro­chen wer­den, aus denen ein Pro­jekt­plan mit ent­spre­chen­den Mei­len­stei­nen abge­lei­tet wer­den kann. Die Anwen­dungs­be­rei­che unter­schei­den sich je nach Anwen­der­grup­pe und Soft­ware­seg­ment: bspw. Ver­trags­ma­nage­ment im Enter­pri­se Con­tent Manage­ment (ECM), Post­ein­gangs­be­ar­bei­tung im Input Manage­ment (IM), bes­se­re Bestands­kun­den­be­treu­ung im Cus­to­mer Rela­ti­onship Manage­ment (CRM), bes­se­res Asset Manage­ment im Enter­pri­se Resour­ce Plan­ning (ERP). Gemein­sam ist die Kon­kre­ti­sie­rung der fach­li­chen Zie­le (Was soll erreicht wer­den?) und Rah­men­be­din­gun­gen (bspw. Res­sour­cen, ande­re Sys­te­me, ver­trag­li­che Rah­men­be­din­gun­gen). Bei der Aus­ge­stal­tung ist dar­auf zu ach­ten, dass kon­kre­te Pilot­pro­jek­te defi­niert sind, aber auch mög­li­che Aus­bau­stu­fen berück­sich­tigt wer­den. Kla­re Zie­le und Ein­satz­sze­na­ri­en hel­fen das Leis­tungs­port­fo­lio der Anbie­ter ver­glei­chen zu kön­nen und den „roten Faden“ hin zur geeig­ne­ten Lösung nicht zu ver­lie­ren.

Aus­wahl des Pro­jekt­teams

Bei der Zusam­men­set­zung des Teams soll­ten die ver­schie­de­nen Anspruchs­grup­pen mit ein­be­zo­gen wer­den. Reprä­sen­ta­ti­ve Ver­tre­ter aus Fach­be­rei­chen und IT mit dem ent­spre­chen­den Wis­sen über Auf­ga­ben, Arbeits­wei­sen, Infra­struk­tur und Befind­lich­kei­ten der Anwen­der ermög­li­chen die genaue Erar­bei­tung der Anfor­de­run­gen. Durch die Ein­bin­dung der Rechts­ab­tei­lung und des Qua­li­täts­ma­nage­ments wer­den über­ge­ord­ne­te Zie­le und Rah­men­be­din­gun­gen berück­sich­tigt. Das Hin­zu­zie­hen eines Bera­ters kann die Anfor­de­rungs­ana­ly­se beschleu­ni­gen, ergän­zen und qua­li­ta­tiv absi­chern. Hier ist aller­dings auf Neu­tra­li­tät des Dienst­leis­ters zu ach­ten, damit auch wirk­lich die bes­te Lösung für das Unter­neh­men gesucht wird.

Auf­nah­me der Ein­satz­be­rei­che und Anfor­de­run­gen

Aus­ge­hend von klar defi­nier­ten Ein­satz­sze­na­ri­en kön­nen die ein­zel­nen Auf­ga­ben­stel­lun­gen und Pro­zes­se ana­ly­siert und die ent­spre­chen­den Kri­te­ri­en für die Unter­stüt­zung durch ein Sys­tem abge­lei­tet wer­den. Durch Ana­ly­se bestehen­der Unter­la­gen oder Befra­gun­gen der Mit­ar­bei­ter kön­nen genutz­te Best Prac­ti­ces, vor­han­de­ne Pro­ble­me und bereits iden­ti­fi­zier­te Wün­sche und Ver­bes­se­rungs­ideen berück­sich­tigt wer­den. Über ers­te Markt­re­cher­chen oder unab­hän­gi­ge Bera­tung ist es mög­lich, neue Anre­gun­gen zu erhal­ten und die­se eben­falls in die Anfor­de­run­gen ein­flie­ßen zu las­sen. Das Las­ten­heft wächst im Zuge des Pro­jekts und wird suk­zes­si­ve mit Hil­fe der gewon­nen Infor­ma­tio­nen ver­fei­nert.

Bei der Pro­zess­ana­ly­se muss man sich von bis­he­ri­gen Arbeits­wei­sen lösen. Nicht die ein­zel­nen heu­ti­gen Tätig­kei­ten, son­dern der Hin­ter­grund der Auf­ga­be muss betrach­tet wer­den. Dar­aus kön­nen neue Mög­lich­kei­ten der Vor­gangs­be­ar­bei­tung unter Nut­zung der Funk­tio­nen der (neu­en) Soft­ware erar­bei­tet wer­den. Es gilt, die Poten­zia­le zur Ver­ein­fa­chung und Auto­ma­ti­sie­rung zu erken­nen. Auch soll­te von ein­zel­nen Mit­ar­bei­tern durch Rol­len­kon­zep­te abs­tra­hiert wer­den, wel­che die Anfor­de­run­gen bestimm­ter Auf­ga­ben­be­rei­che bün­deln.

Zudem ist ein über­grei­fen­des Archi­tek­tur­kon­zept wich­tig, wel­ches das Zusam­men­spiel der ver­schie­de­nen Fach­sys­te­me defi­niert. Damit wird die Ver­bin­dung der unter­schied­li­chen Anwen­dun­gen nicht nur tech­nisch, son­dern auch orga­ni­sa­to­risch gere­gelt: Wel­ches Sys­tem hat über wel­che Daten und Funk­tio­nen die Hoheit? Wel­che Auf­ga­ben wer­den mit wel­chen Sys­te­men bear­bei­tet? Wann wer­den wel­che Infor­ma­tio­nen über­tra­gen? Wie kön­nen sich Pro­zes­se ansto­ßen? – Das sind eini­ge der rele­van­ten Fra­gen in die­sem Zusam­men­hang.

Als Ergeb­nis der Pha­se erhält man ein Las­ten­heft, wel­ches das Pro­jekt­ziel beschreibt, die Anfor­de­run­gen in einem struk­tu­rier­ten Kri­te­ri­en­ka­ta­log fest­schreibt und zukünf­ti­ge Arbeits­wei­sen durch Soll-Pro­zes­se defi­niert.

Schritt für Schritt zur rich­ti­gen Lösung: mehr­stu­fi­ge Eva­lua­ti­on

Ein­fach mal ein paar Anbie­ter ein­la­den und auf die­ser Basis ent­schei­den – das ist ein Glücks­spiel. Die Soft­ware­aus­wahl soll­te mehr­stu­fig erfol­gen, um dabei gezielt das am bes­ten geeig­ne­te Sys­tem (und Team) zu iden­ti­fi­zie­ren. Als ers­te Stu­fe wird eine Markt­ein­gren­zung auf das jewei­li­ge Soft­ware­seg­ment emp­foh­len (Long­list). Anhand defi­nier­ter K.-o.-Kriterien kann der Markt dabei in der Regel auf vier bis zehn Sys­te­me ein­ge­grenzt wer­den.

Die wei­te­re Bewer­tung kann als klas­si­sche Aus­schrei­bung mit schrift­li­cher Stel­lung­nah­me zu ent­spre­chen­den Unter­la­gen erfol­gen. Hier­zu wer­den meist ein Aus­schnitt des Las­ten­hefts und eine Kos­ten­schät­zung ver­wen­det. Die Anbie­ter erhal­ten so die Mög­lich­keit, zu den aus­ge­wähl­ten funk­tio­na­len und tech­ni­schen Kri­te­ri­en, ihrem Leis­tungs­an­ge­bot und Kon­di­tio­nen Stel­lung zu neh­men. Ergän­zend kön­nen bereits hier ers­te (ein­fa­che) Prä­sen­ta­tio­nen der Sys­te­me durch­ge­führt wer­den. Auf die­ser Basis erfolgt eine wei­te­re Bewer­tung und Ein­gren­zung. Die ver­blie­be­nen Anbie­ter (Short­list) sind grund­sätz­lich alle geeig­net, das Pro­jekt gemäß der Anfor­de­run­gen an die Lösung zu leis­ten.

In der anschlie­ßen­den Detail­eva­lua­ti­on wird die am bes­ten geeig­ne­te Lösung iden­ti­fi­ziert. Neben einer Stel­lung­nah­me zum gesam­ten Las­ten­heft wer­den auch Refe­renz­pro­jek­te sowie genaue Kos­ten- und Zeit­schät­zun­gen hin­sicht­lich der Umset­zung erfor­der­lich. Zudem muss die Soft­ware mög­lichst nah an den spä­te­ren Anwen­dungs­sze­na­ri­en beur­teilt wer­den. Hier emp­fiehlt sich eine struk­tu­rier­te Sys­tem­prä­sen­ta­ti­on anhand eines Leit­fa­dens (Pro­zess-Dreh­buch), wel­che unter­schied­li­che Ein­satz­mög­lich­kei­ten im spä­te­ren Betrieb ver­deut­licht. Hier­bei wer­den sowohl die Hand­ha­bung und Leis­tungs­fä­hig­keit des Sys­tems als auch die Arbeits­wei­se des Anbie­ters (Her­stel­ler und Pro­jekt­part­ner) bewer­tet. Zusätz­lich kann eine Test­stel­lung als Pro­of-of-Con­cept durch­ge­führt wer­den, um bspw. die Über­nah­me von Daten aus bestehen­den Sys­te­men oder bestimm­te Aspek­te des Ein­rich­tungs­auf­wands zu prü­fen.

Ent­schei­dung und Ver­trags­ab­schluss

Auf Basis der nun vor­lie­gen­den Infor­ma­tio­nen ist in einem letz­ten Schritt des Eva­lua­ti­ons­pro­zes­ses eine kla­re Ent­schei­dungs­vor­la­ge zu erzeu­gen. Die Ver­ant­wort­li­chen in der Geschäfts­lei­tung müs­sen Vor­ge­hen und Ergeb­nis­se nach­voll­zie­hen kön­nen und kla­re Grün­de für eine Ent­schei­dungs­emp­feh­lung erken­nen. Mög­li­che Alter­na­ti­ven sind klar zu benen­nen und dabei die Hin­ter­grün­de für Preis­un­ter­schie­de oder eine unter­schied­li­che Abde­ckung ver­schie­de­ner Ein­satz­be­rei­che zu erklä­ren. So kann ver­hin­dert wer­den, dass „Äpfel mit Bir­nen“ ver­gli­chen wer­den.

Es ist wich­tig, alle Ver­hand­lungs­er­geb­nis­se und Ent­schei­dun­gen schrift­lich zu fixie­ren, damit bei allen Betei­lig­ten Klar­heit über Ver­trags­in­hal­te und Kon­di­tio­nen herrscht. Als mit­gel­ten­de Unter­la­gen soll­ten die Infor­ma­tio­nen aus dem Aus­wahl­ver­fah­ren auf­ge­nom­men wer­den. So ste­hen ver­bind­li­che Infor­ma­tio­nen zu Kos­ten, Ter­mi­nen und der Abde­ckung der Anfor­de­run­gen aus dem Las­ten­heft zur Ver­fü­gung. Es ist zu beach­ten, dass auch die inter­nen Res­sour­cen für die Umset­zung bereit­ge­stellt wer­den müs­sen.

Erfolgs­fak­to­ren für die Umset­zung

Wesent­li­cher Erfolgs­fak­tor für die Pro­jekt­um­set­zung ist, dass die Sys­tem­ein­füh­rung von Schu­lun­gen und unter­stüt­zen­den orga­ni­sa­to­ri­schen Maß­nah­men beglei­tet wird. Mit­ar­bei­ter müs­sen ler­nen, wie sie die Soft­ware rich­tig ein­set­zen kön­nen. In den beglei­ten­den Work­shops soll­ten neben der tech­ni­schen Bedie­nung auch die in der Soft­ware abge­bil­de­ten Struk­tu­ren und Pro­zes­se ver­mit­telt wer­den. Es emp­fiehlt sich daher, auf­ga­ben­be­zo­ge­ne Schu­lun­gen für die Mit­ar­bei­ter durch­zu­füh­ren, sodass die­se das ver­mit­tel­te Wis­sen gleich in ihren Arbeits­ab­läu­fen anwen­den kön­nen.

Gutes Chan­ge-Manage­ment ist ein wei­te­rer wich­ti­ger Fak­tor, um Mit­ar­bei­tern die Angst vor dem neu­en Sys­tem zu neh­men. Nur wer die Nut­zer früh­zei­tig für die Ände­run­gen in ihren all­täg­li­chen Arbeits­pro­zes­sen begeis­tern kann, kann sich auch ihre akti­ve Mit­ar­beit sichern. Sie soll­ten bereits im Rah­men der Ziel­de­fi­ni­ti­on infor­miert wer­den und der Aus­wahl­pro­zess soll­te mög­lichst trans­pa­rent gestal­tet sein. Das Pro­jekt­mar­ke­ting rund um die Ein­füh­rung soll­te neben einer Prä­sen­ta­ti­on und den auf­ga­ben­be­zo­ge­nen Schu­lun­gen auch aus­rei­chen­de Mög­lich­kei­ten für Rück­fra­gen umfas­sen.

Eine rea­lis­ti­sche Pla­nung bei der Ein­füh­rung ist zudem ein wesent­li­cher Erfolgs­fak­tor. Pro­jekt­res­sour­cen wer­den oft über­for­dert. Auch bei der Imple­men­tie­rung soll­te eine mehr­stu­fi­ge Vor­ge­hens­wei­se gewählt wer­den. Nach einer Basis­in­stal­la­ti­on und der Umset­zung der Pilot­pro­jek­te wer­den funk­tio­na­le Erwei­te­run­gen oder eine Aus­wei­tung des Anwen­der­krei­ses in den Fol­ge­pro­jek­ten durch­ge­führt. In den Pilot­pro­jek­ten ist auf kla­re Lösun­gen mit einem schnell fühl- und mess­ba­ren Nut­zen zu ach­ten, um die Betei­lig­ten von dem Sys­tem zu über­zeu­gen. Auch hier gilt „Think Big, start small“ – so kön­nen schnell nach­weis­ba­re Erfol­ge erzielt wer­den, die Geld-, Zeit- und Qua­li­täts­vor­tei­le brin­gen und die Mit­ar­bei­ter­ak­zep­tanz sichern.

Beson­der­hei­ten der Soft­ware­aus­wahl im Digi­tal Work­place

Der Weg zum Digi­tal Work­place beginnt mit einer umfas­sen­den Visi­on und Stra­te­gie, wel­che in ein­zel­ne Pro­jek­te her­un­ter­ge­bro­chen wer­den. Daher gibt es oft Abhän­gig­kei­ten zwi­schen den ein­zel­nen Sys­te­men zu beach­ten. Die ein­zel­nen Soft­ware­aus­wahl­pro­jek­te müs­sen in ein über­grei­fen­des Archi­tek­tur­kon­zept ein­ge­bun­den wer­den. Die­se Infor­ma­ti­ons- und Sys­tem­land­schaft wird sich suk­zes­si­ve ver­fei­nern, da die neu­en Sys­te­me zusätz­li­che Mög­lich­kei­ten bie­ten. Unter­neh­men soll­ten daher auch kla­re Zwi­schen­lö­sun­gen pla­nen.

Eine Beson­der­heit bei der Umset­zung des Digi­tal Work­place ist, dass „Soft­ware­aus­wahl“ die Beschaf­fung neu­er Sys­te­me bedeu­ten kann, aber nicht muss. All­ge­mein bezeich­net Soft­ware­aus­wahl die Zuord­nung von Werk­zeu­gen zu Anwen­dungs­fäl­len und Arbeits­wei­sen. Daher gibt es unter­schied­li­che Aus­prä­gun­gen:

• Ande­re Gestal­tung von bestehen­den Sys­te­men oder geziel­te Erwei­te­rung der Nut­zung bestehen­der Sys­te­me, bspw. auch von bestimm­ten Funk­ti­ons­mo­du­len (bspw. Work­flow)
• Erwei­te­rung bestehen­der Sys­te­me durch zusätz­li­che Modu­le oder Part­ner­pro­duk­te
• Ande­re Art der Kom­bi­na­ti­on und Ver­net­zung der Sys­te­me (Infor­ma­tio­nen, Pro­zes­se und Ober­flä­che)
• Kon­so­li­die­rung der Sys­te­me – ins­be­son­de­re, wenn sich his­to­risch ver­schie­de­ne Werk­zeu­ge ent­wi­ckelt haben, wenn die Fach­be­rei­che unab­hän­gig von­ein­an­der beschafft haben
• Aber natür­lich auch Aus­wahl neu­er Soft­ware (zur Ablö­sung alter Sys­te­me und / oder zur Abde­ckung neu­er Anwen­dungs­fäl­le

Das grund­sätz­li­che Vor­ge­hen unter­schei­det sich dabei kaum. Basis muss eine kla­re Ziel­de­fi­ni­ti­on sein, gefolgt von einer Anfor­de­rungs­ana­ly­se und Soll-Kon­zep­ti­on. Wer­den Sys­te­me kon­so­li­diert oder wird zunächst nach Lösun­gen in der vor­han­de­nen Soft­ware­land­schaft gesucht, wird ledig­lich die Pha­se „Markt­ein­gren­zung“ ange­passt. Die schritt­wei­se Eva­lua­ti­on der in Fra­ge kom­men­den Sys­te­me inkl. Abschät­zung der Kos­ten, Pro­jekt­lauf­zei­ten und Qua­li­tät der Kon­zep­te ist wie­der gut ver­gleich­bar.

Fazit: Soft­ware­aus­wahl durch­füh­ren – aber rich­tig!

Die Umset­zung des Digi­tal Work­place ist nicht tri­vi­al, da Tech­nik, Funk­tio­na­li­tät, Pro­zes­se und Unter­neh­mens­phi­lo­so­phie betrof­fen sind. Aber ent­spre­chen­de inein­an­der grei­fen­de Sys­te­me, Infor­ma­tio­nen und Pro­zes­se sind auch abso­lut erfor­der­lich in der moder­nen Geschäfts­welt. Es nützt nichts, den Kopf in den Sand zu ste­cken und abzu­war­ten, da die Pro­ble­me mit ver­schie­de­nen Infor­ma­ti­ons­la­gern (nach Abtei­lung, Sys­tem: Papier­ab­la­ge, Datei­ab­la­ge, Fach­an­wen­dung, E-Mail) und unzu­rei­chen­der Vorgangs­unterstützung immer stär­ker wer­den und bei der Infor­ma­ti­ons­re­cher­che und -wei­ter­lei­tung enorm viel Arbeits­zeit ver­schwen­det wird.

Um zu einer wirk­li­chen Ver­bes­se­rung im Umgang mit den betrieb­li­chen Infor­ma­tio­nen zu gelan­gen, müs­sen die Metho­den zur Ziel­de­fi­ni­ti­on, Spe­zi­fi­ka­ti­on der Anfor­de­run­gen und Bewer­tung der Anbie­ter kon­se­quent ein­ge­setzt wer­den. Rea­lis­mus und Mut zur Ver­än­de­rung sind dabei zwei wesent­li­che Merk­ma­le eines erfolg­rei­chen Pro­jekts. Ein gut struk­tu­rier­tes und gut doku­men­tier­tes Vor­ge­hen bei der Soft­ware­aus­wahl redu­ziert die mög­li­chen Risi­ken der Aus­wahl und ver­ein­facht gleich­zei­tig das Aus­schöp­fen der Vor­tei­le. Es ist kein leich­tes Unter­fan­gen, Soft­ware für den Digi­tal Work­place aus­zu­wäh­len. Aber es kann der Schritt in eine neue Welt der Nut­zung von Infor­ma­ti­on mit ein­fa­che­ren, fle­xi­ble­ren und bes­se­ren Pro­zes­sen sein.