BPMblog.ch

Der Aus­druck stammt von einem Kun­den, der ihn, als ich ein­mal mit ihm über Gründe für den Ein­satz von BPM-Software sprach, spon­tan prägte.

Wiki­pe­dia sagt zu Middleware:

Midd­le­ware (deutsch etwa „Zwi­schen­an­wen­dung“) bezeich­net in der Infor­ma­tik anwen­dungs­neu­trale Pro­gramme, die so zwi­schen Anwen­dun­gen ver­mit­teln, dass die Kom­ple­xi­tät die­ser Appli­ka­tio­nen und ihrer Infra­struk­tur ver­bor­gen wird. Man kann Midd­le­ware auch als eine Ver­tei­lungs­platt­form, d. h. als ein Pro­to­koll (oder Pro­to­koll­bün­del) auf einer höhe­ren Schicht als der der gewöhn­li­chen Rech­ner­kom­mu­ni­ka­tion auf­fas­sen. Im Gegen­satz zu niveau­tie­fe­ren Netz­werk­diens­ten, wel­che die ein­fa­che Kom­mu­ni­ka­tion zwi­schen Rech­nern hand­ha­ben, unter­stützt Midd­le­ware die Kom­mu­ni­ka­tion zwi­schen Pro­zes­sen.

In vie­len Fir­men ist das nach wie vor die Auf­gabe des Mit­ar­bei­ters. Der Mit­ar­bei­ter weiss — und muss wis­sen — was er zu tun hat, wenn die Bestel­lung eines neuen Kun­den ein­trifft. Er geht in die CRM-Lösung und erfasst dort den neuen Kon­takt (womög­lich muss er dazu die voll­stän­di­gen Daten erst im Inter­net oder tele­fo­nisch abklä­ren). Anschlies­send öffnet er die ERP-Applikation und erfasst dort die­sel­ben Daten noch ein­mal. Die Bestel­lung scannt er und ver­schlag­wor­tet sie anschlies­send in der DMS-Lösung. Er send­et­wo­mög­lich ein Mail an den zustän­di­gen Ver­triebs­mit­ar­bei­ter um even­tu­elle Fra­gen betref­fend der Kon­di­tio­nen zu klä­ren und legt dann die Bestel­lung in sei­nen Post­ein­gang. Erhält er womög­lich Stun­den oder Tage spä­ter die ent­spre­chende Rück­mel­dung vom Ver­trieb, dann sucht er wie­der nach der Bestel­lung und erfasst die ent­spre­chen­den Punkte in der ERP nach.

In ein­fach struk­tu­rier­ten Umge­bun­gen und bei zwei oder drei Mit­ar­bei­tern ist dies bestimmt ein prag­ma­ti­scher Ansatz. In grös­se­ren Fir­men kann das aber schnell zu Pro­ble­men füh­ren. Dies hat unter ande­rem die fol­gen­den Gründe:

• Das Know­How hängt an ein­zel­nen Mit­ar­bei­tern — fal­len sie aus (Urlaub, Krank­heit, Kün­di­gung) fällt damit auch Pro­zess­know­how weg. Die­ses muss ent­we­der redun­dant gehal­ten wer­den (indem eine Auf­gabe immer von 2 Per­so­nen besetzt wird) oder aber es bedingt im Bedarfs­fall (und Krank­hei­ten kom­men manch­mal zur unpas­sends­ten Zeit) ein­fach versuchen…
• Die Schu­lung von neuen Mit­ar­bei­tern wird kom­ple­xer weil sie eben diese Midd­le­ware — Akti­vi­tä­ten ler­nen und umset­zen müssen.
• Dinge blei­ben lie­gen. Nie­mand hat einen genauen Über­blick ob alle Akti­vi­tä­ten schon gemacht wur­den. So kann schon ein­mal eine grös­sere Bestel­lung so lange im Post­korb gam­meln bis der Kunde rekla­miert oder gleich wo anders bestellt, weil er nicht war­ten kann.

BPM-Software, wel­che den Aspekt der Pro­zess­aus­füh­rung mit-unterstützt geht hier einen ande­ren Weg. Ziel ist es den Mit­ar­bei­ter bei der Bewäl­ti­gung sei­ner Auf­ga­ben zu unter­stüt­zen. (Nicht wie oft unter­stellt ihn zu ersetzen.)

Sol­che Soft­ware­pro­dukte — und davon gibt es inzwi­schen ver­schie­dene auf dem Markt — gehen im All­ge­mei­nen davon aus, dass sie dem User eine Ober­flä­che (ob HTML, Fat Cli­ent, Web 2.0 oder For­mu­lare) zur Ver­fü­gung stel­len in denen er durch seine Auf­ga­ben gelei­tet wird. Dabei wer­den ihm zum Bedarfs­zeit­punkt alle Daten aus den ver­schie­de­nen Umsys­te­men (CRM, ERP, DMS usw.) zur Ver­fü­gung gestellt und seine Ein­ga­ben wer­den wie­derum in die ent­spre­chen­den Sys­teme über­nom­men. Der Tech­no­lo­gien sind hier viele — taug­li­che und weni­ger taugliche.

Die Vor­teile die­ses Ansat­zes ent­spre­chen den Nach­tei­len des vor­ge­nann­ten. Was zusätz­lich hinzu kommt ist, dass der Mit­ar­bei­ter in den für die ein­zel­nen Pro­zess­schritte gestal­te­ten Ein­ga­be­mas­ken nur die Fel­der zur Ver­fü­gung gestellt bekommt, die er auch braucht. Es kann dabei fest­ge­legt wer­den, wel­che Fel­der nur der Anzeige die­nen, wel­che aus­ge­füllt wer­den müs­sen und wel­che es bei Bedarf kön­nen. Zusätz­lich kön­nen ent­spre­chende Fel­der vali­diert wer­den. Damit kann ein gros­ser Bei­trag zur Daten­qua­li­tät geleis­tet wer­den. Wer kann schon sicher sein, dass er in einer Ein­ga­be­maske mit hun­dert­fünf­zig Fel­dern über 6 Rei­ter ver­teilt nicht irgend­wel­che Daten ein­zu­ge­ben oder anzu­pas­sen ver­gisst? Wer kann sicher sein, dass jeder Mit­ar­bei­ter die Feld­be­schrif­tung „Kun­den­ka­te­go­rie“ gleich ver­steht und nicht einer „A“, ein ande­rer „Indus­trie­kunde“ und der dritte „Neu­kunde“ eingibt?

Zwei­fel­los kann viel davon auch in beste­hen­den Sys­te­men ent­wi­ckelt wer­den. Viele ERP-Systeme bei­spiels­weise, bie­ten heute die Mög­lich­keit an, indi­vi­du­elle Mas­ken für unter­schied­li­che Mit­ar­bei­ter bereit­zu­hal­ten und damit ist natür­lich auch die Mög­lich­keit gege­ben, dass man ver­schie­dene Mas­ken für ver­schie­dene Akti­vi­tä­ten anlegt. Das ist im Nor­mal­fall eine Frage von Kos­ten und Zeitaufwand.

Wo aber eigent­lich alle Nicht-BPM-Engines schei­tern ist dort, wo Pro­zesse meh­rere Sys­teme tan­gie­ren. Natür­lich ist es mög­lich in der ERP auf das CRM zuzu­grei­fen. Doch das wol­len Sie ja nicht immer, wenn Sie es aber wol­len, dann soll es die für den betref­fen­den Schritt rele­van­ten Daten anzei­gen­und Ein­ga­ben auch gleich dort­hin übertragen…

Wer das in Pro­duk­ten wie ERP, CRM, DMS, SRM etc. aus­pro­gram­mie­ren lässt wird ent­spre­chende Kos­ten auf sich zukom­men sehen. Gute BPM-Enginges sind hier anders. Es ist die Grund­lage ihres Daseins, dass sie fle­xi­bel sind, schnell anpass­bar und hoch-integrativ.