Prozesse dokumentieren? Gähn … muss das sein?

Wir kennen niemanden, der mit Freude und Energie ein Projekt beginnt, in dem es um „Dokumentation“ geht. Und trotzdem sind die Erfassung und Diskussion des IST-Zustandes der Prozesse, Schnittstellen und Verantwortlichkeiten wichtige Meilensteine für jedes Digitalisierungsprojekt. Warum Prozessorientierung der Schlüssel zum Erfolg der eigenen Digitalstrategie ist, erläutern Dr. Kai Krings (CEO, Intellior AG) und Christian Sennewald (Leiter Digitale Transformation, SHD).

In einer Artikelserie hat unser Partner Intellior AG sieben Erfolgsfaktoren für eine nachhaltige Prozessorientierung herausgearbeitet:

1. Attraktives Zukunfts- und Zielbild
2. Klarer Kunden- und Stakeholderfokus
3. Anwenderorientierte Prozessgestaltung und -dokumentation
4. Transparente Rollen und Verantwortlichkeiten
5. Verwendbare Daten, Informationen und tiefes Wissen
6. Wirkungsvolle Führung und Prozessorganisation
7. Aussagekräftige Prozessmessung und -steuerung

Im folgenden Fachartikel stellt Christian Sennewald, Leiter Digitale Transformation den Erfolgsfaktor Nr. 3 vor.

In den Diskussionen mit unseren Kunden bemerken wir, dass Prozessorientierung oft lediglich als „Orientierung an einem definierten Geschäftsprozess“ verstanden wird. Wir sehen aber weitere Potentiale: Prozessorientierung sollte immer den Zielen „Wirtschaftlichkeit“ und „Kundenorientierung“ folgen.  Was heißt das konkret? Die Unternehmensprozesse liefern stabil, regelkonform und wirtschaftlich gesteuert genau die Leistungen, von denen interne und vor allem externe Kunden begeistert sind. Dafür ist eine definierte und abgestimmte Prozessdokumentation ein wesentliches Mittel zum Zweck. Lebendig und wirksam werden die Prozesse aber erst, wenn alle Beteiligten Verantwortung für Durchführung und Steuerung übernehmen. Dazu braucht es abgestimmte und in der Organisation verankerte Rollen für Prozessverantwortliche, die mit den Linienverantwortlichkeiten abgestimmt sind. Und klare Ziele und Prioritäten für Prozesse, für alle greifbar und sichtbar in einer Prozesslandkarte. Abgestimmte, einfache Konventionen und eine anforderungsgerechte und mit wachsenden Anforderungen erweiterbare BPM Software beschleunigen die weitere Umsetzung. Ein Rollenkonzept mit Verbindung zu den Planstellen und Organisationseinheiten, verknüpfte Dokumente und zu nutzende IT-Systeme/Transaktionen helfen allen Beteiligten die Prozesse und Verantwortlichkeiten zu leben. Auf dieser Basis können Prozesse wirksam bis in eine gelebte Umsetzung und vor allem bis hin zur kontinuierlichen Verbesserung definiert werden.

Wenn wir auf das Ziel­bild Ihres „Pro­zess-Pro­jek­tes“ schau­en, geht es häu­fig um ein ge­mein­sa­mes Pro­zess­ver­ständ­nis für eine an­ste­hen­de IT-Un­ter­stüt­zung. Dabei ist es sehr ent­schei­dend, ob es sich bei dem Ziel­sys­tem um eine Stan­dard­soft­ware (z.B. ERP, CRM oder PLM) han­delt, oder der Pro­zess unternehmens­spe­zi­fisch um­ge­setzt wird, z.B. über eine Work­flow-En­gi­ne.

Zielsystem: Standardsoftware

In der Regel strebt das Unternehmen eine Har­mo­ni­sie­rung von Pro­zess­va­ri­an­ten an, um den Aufwand zu reduzieren. Häu­fig geschieht das mit Hilfe von Re­fe­renz­pro­zess­mo­del­len, die in Hin­blick auf die ei­ge­nen An­for­de­run­gen über­prüft wer­den. Dabei kann die „Flug­hö­he“ sehr un­ter­schied­lich sein: von sehr fei­nen Ein­zel­auf­ga­ben und Trans­ak­tio­nen nah an der Sys­tem­nut­zung bis hin zu durch­gän­gi­gen Pro­zes­sen. Diese bilden dann auch Auf­ga­ben und Ent­schei­dun­gen ab­, die eben­falls er­for­der­lich sind, aber nicht oder nur teil­wei­se sys­tem­un­ter­stützt lau­fen.

Zielsystem: Individueller Prozess

Bei unternehmensindividuellen Prozessen hängt es von der Ziel­platt­form ab, wie die Pro­zes­se mo­del­liert wer­den müs­sen:

• Variante 1: ein­fa­che, eher fach­li­chen BPMN-Pro­zes­se, die im Ziel­sys­tem bis zum lauf­fä­hi­gen eWork­flow inkl. Ober­flä­che und For­mu­la­ren an­ge­rei­chert wer­den
• Variante 2: No­code oder Low­code Lö­sun­gen, bei denen be­reits beim Mo­del­lie­ren der lauf­fä­hi­ge Pro­zess ent­steht (wie z.B. auch bei un­se­rer Lö­sung IBM Business Workflow Automation oder Intellior BPM|Flow)
• Variante 3: voll­stän­di­ge BPMN Mo­del­lie­rung

Fälle 1 und 3 be­nö­ti­gen zwin­gend IT-Spe­zia­lis­ten, die den Pro­zess fe­der­füh­rend mit dem Fach­be­reich im je­wei­li­gen Ziel­sys­tem tech­nisch um­set­zen. Dabei soll­te aber in jedem Fall der fach­li­che Pro­zess mög­lichst ein­fach mo­del­liert und leicht ver­stan­den wer­den kön­nen.

Hier­zu kön­nen Me­tho­den zur An­wen­dung kom­men, die die fach­li­che Pro­zess­be­schrei­bung von der tech­ni­schen Be­schrei­bung und damit der IT spe­zi­fi­schen Lö­sung tren­nen. Bei­spiel­haft sei das Ar­bei­ten mit „black Pools“ oder „col­lap­sed Sub Pro­ces­ses“ ge­nannt, die eine tech­ni­sche Um­set­zung in einem SCIL-Lay­er (Ser­vice Contract Im­ple­men­ta­ti­on Layer) dar­stel­len und so z.B. auch un­ter­schied­li­che Im­ple­men­tie­rungs­va­ri­an­ten je Stand­ort ab­bil­den kön­nen. Die­ser An­satz einer Pro­cess Dri­ven Ar­chi­tec­tu­re (PDA) ver­spricht eine ef­fi­zi­en­te und ef­fek­ti­ve Soft­ware­ent­wick­lung, ver­langt al­ler­dings auch die kon­se­quen­te Um­set­zung der me­tho­di­schen An­for­de­run­gen und die Nut­zung der BPMN No­ta­ti­on. Fol­gen­de An­for­de­run­gen sol­len er­füllt wer­den:

1. Konsistente und einheitliche Darstellung von Pro­zes­sen über alle be­nö­tig­ten Ebe­nen
2. Ein­fach zu lesen und zu ver­ste­hen für die Kern­ziel­grup­pen​​​
   - Pro­zess­an­wen­der/Pro­zess­team (als Lese-/Ver­ständ­nis­hil­fe für die Pro­zess­durch­füh­rung)
   - Pro­zess­mo­del­lie­rer und Pro­zess­ma­nage­ment­be­ra­ter (für die Mo­del­lie­rung und IT-Um­set­zung)
   - Pro­zes­s­eig­ner und Pro­zess­ma­na­ger (für die Frei­ga­be, Un­ter­stüt­zung und Steue­rung)
3. Ein­fa­cher und schnel­ler Auf­bau von Mo­del­lie­rungs­fä­hig­kei­ten zum Auf­bau des Pro­zess­mo­dells

Diese An­for­de­run­gen wer­den am bes­ten durch eine stark re­du­zier­tes Sym­bol­pa­let­te auf Basis des BPMN 2.0 Standards der OMG (ISO/IEC 19510:2013) er­füllt. Sie wird heute be­reits im Rah­men von Aus­bil­dung oder Stu­di­um ver­mit­telt und von allen re­le­van­ten Sys­te­men mit Stan­dard­schnitt­stel­len un­ter­stützt.

Im Rah­men von Pro­zess­work­shops er­ar­bei­ten wir die not­wen­di­gen Grund­la­gen an einem Flip­chart mit Pos­t-Its – das ist dann unsere sicht­ba­re Kon­ven­ti­on. Ist das Hand­werks­zeug und damit die re­du­zier­te Sym­bol­pa­let­te ver­stan­den und ein­ge­übt, eig­nen sich für die Work­shops nicht nur Pos­t-Its. Auch wie­der­ver­wend­ba­re Shapes fin­den in den krea­ti­ven Run­den po­si­ti­ven An­klang. Der große Vor­teil liegt hier auf der Ro­bust­heit und Be­schrift­bar­keit. Sehr oft wer­den die ein­zel­nen Tasks in einer le­ben­di­gen Work­sh­op­si­tua­ti­on von Swim­la­ne zu Swim­la­ne ver­scho­ben und der Tas­kna­me für die Bil­dung eines ge­mein­sa­men Ver­ständ­nis­ses mehr als nur zwei­mal ver­än­dert – und das ist gut so. Als Bei­spiel für wie­der­ver­wend­ba­re Shapes emp­feh­len wir den Mo­dera­ti­ons­kof­fer von Pro­Board, er­hält­lich unter www.​proboard.​de.

IST-Prozesse verbessern

Für den klassischen Weg „Ist-Pro­zes­se ver­bes­sern“ nehmen wir Abläufe über Interviews oder Work­shops mit den Be­tei­lig­ten auf und visualisieren diese. Dann identifizieren wir gemeinsam und systematisch die Schwach­stel­len und bewerten sie mit ihrem Op­ti­mie­rungs­po­ten­zi­al. Die ver­bes­ser­ten Soll-Pro­zes­se wer­den er­ar­bei­tet und mit Um­set­zungs­maß­nah­men do­ku­men­tiert.

Sollten ent­spre­chen­de Informationen über die IST-Prozesse bereits vorliegen, er­setzt die Va­ri­an­te fak­ten­ba­sier­te Ist-Pro­zes­s­er­he­bung über Pro­cess-Mi­ning die Pro­zes­s­er­he­bung. Dann startet unsere Zusammenarbeit mit der Dis­kus­si­on und Ver­bes­se­rung der ziel­kon­for­men Va­ri­an­ten in einem Work­shop.

Die In­ter­view­me­tho­de ist für Pro­zes­s­er­he­bun­gen pro­ble­ma­tisch, weil die Wahr­neh­mung, Sicht­wei­se und In­ter­pre­ta­ti­on des In­ter­view­ers zu un­nö­ti­gen Schlei­fen oder einer ver­meint­lich ge­teil­ten Sicht­wei­se füh­ren kann. In gut mo­de­rier­ten Work­shops fin­den per­ma­nent be­griff­li­che und fach­li­che Klä­run­gen statt, die dann auch meist zu einer ge­teil­ten Sicht­wei­se und einem glei­chen Pro­zess­ver­ständ­nis füh­ren. Ge­ne­rell schau­en Me­tho­den der Is­ter­he­bung auf „Un­zu­läng­lich­kei­ten“ und iden­ti­fi­zie­ren Feh­ler, Pro­ble­me oder Ri­si­ken, auch wenn von Ver­bes­se­rungs­po­ten­zia­len ge­spro­chen wird. Damit gibt es bei den Be­tei­lig­ten immer „Schul­di­ge“ und nicht sel­ten wird ver­tei­digt, warum etwas not­wen­dig war oder noch ist. Hier kann eine klare Kom­mu­ni­ka­ti­on über ver­än­der­te Ziele und Rah­men­be­din­gun­gen „lin­dern“. Der Lö­sungs­fo­kus rückt dennoch in den Hintergrund.

Ziel­fo­kus­sier­te Soll­pro­zess-Work­shops 

Bei stark ver­än­der­ten und an­spruchs­vol­len Zie­len sowie einem vor­han­de­nen Pro­zess­ver­ständ­nis kann ein Soll-Pro­zess di­rekt in einem Work­shop krea­tiv ent­wi­ckelt wer­den. Vom Pro­zess­ende be­gin­nend wird im Work­shop ge­fragt, was wel­che Rolle in der vor­her­ge­hen­den Ak­ti­vi­tät lie­fern muss, damit der Nach­fol­ger gut ar­bei­ten kann. Auf diese Weise wer­den Ist-Rou­ti­nen re­flek­tiert und nicht ein­fach fort­ge­schrie­ben. Damit wird mehr über die ziel­kon­for­me Lö­sung und we­ni­ger über Pro­ble­me ge­spro­chen.

Idea­ler­wei­se wurde die Pro­zess­land­schaft TOP-Down ent­wi­ckelt. Wenn dabei sys­te­ma­tisch ge­ar­bei­tet wurde, soll­ten die Ver­ant­wort­lich­kei­ten für Pro­zes­se und die je­weils vor- und nach­ge­la­ger­ten Schritte mit ihren Zuständigkeiten ge­klärt sein. Wenn nicht, kann eine Me­tho­de aus dem Be­reich Lean Six Sigma für Klar­heit sor­gen. Das „SIPOC“ Mo­dell. In die­sem Mo­dell wer­den die In­for­ma­tio­nen nach fol­gen­dem Mus­ter zu­sam­men­ge­tra­gen:

S … Sup­p­lier > I … Input > P … Pro­cess > O … Out­put > C … Cust­o­m­er

In der Pro­zess­do­ku­men­ta­ti­on lie­fert das SIPOC Mo­dell auch eine sehr ein­fa­che und über­sicht­li­che Dar­stel­lung für Pro­zes­se auf der nächst­tie­fe­ren Ebene. Zum Beispiel wenn aus Grün­den der Un­ab­hän­gig­keit oder Steu­er­bar­keit ei­ge­ne Pro­zes­se er­for­der­lich sind. Der SIPOC ist auch ein Hilfs­mit­tel für die Dar­stel­lung, Ab­stim­mung, Ana­ly­se und Op­ti­mie­rung einer End-to-End Pro­zess­ket­te. Im ers­ten Schritt kön­nen so die Schnitt­stel­len (Start-/ End­er­eig­nis­se, In-/ Out­puts, Qua­li­tät oder Ser­vice­le­vel) ge­klärt und ver­ein­bart wer­den, ganz oft sind das be­reits Quick Wins für Ihr Pro­zess-Pro­jekt. Die Me­tho­de ist sehr fle­xi­bel und kann sogar für die de­tail­lier­te Ab­stim­mung zwi­schen un­ter­schied­li­chen Funk­tio­nen auf Tas­ke­be­ne ge­nutzt wer­den.

Hat man mit den oben be­schrie­be­nen Me­tho­den bzw. An­sät­zen einen Pro­zess er­fasst, geht es nun darum, die­sen in einem ge­eig­ne­ten Tool zu mo­del­lie­ren. Da geht nun in den meis­ten Pro­jek­ten schon die Fra­ge­rei los. Wohin und in wel­cher Form soll der Pro­zess ab­ge­legt wer­den. Da rei­chen die Vor­schlä­ge der Work­sh­opteil­neh­mer von

„Lasst uns das Bild des Whi­te­boards im In­tra­net oder File­sys­tem ab­le­gen“

bis hin zu

„Ich habe nach­her Zeit und über­füh­re es schnell in Visio und lege es dann im zen­tra­len Do­ku­men­ten Ma­nage­ment Sys­tem ab“

Letz­te­res wäre an­ge­sichts der Al­ter­na­ti­ve schon die bes­sere Wahl. Je­doch soll­te man bei der Too­laus­wahl für das Pro­zess­ma­nage­ment auf fol­gen­de Ei­gen­schaf­ten ach­ten:

• Nut­zung eines da­ten­bank­ge­stütz­ten Sys­tems, um die do­ku­men­tie­ren Ei­gen­schaf­ten aus­wer­ten zu kön­nen
• Ein­fa­che Tool­un­ter­stüt­zung in der Mo­del­lie­rungs­pha­se. Ta­bel­la­ri­sche Er­fas­sungs­mög­lich­keit des Pro­zes­ses. Das Mo­dell, d.h. die Gra­fik in BPMN Dar­stel­lung wird live „On the fly“ ge­ne­riert. Bei einer gra­fi­schen Mo­del­lie­rung sorgt ein Au­to­lay­ou­ter für ma­xi­ma­le Pro­duk­ti­vi­tät, eben­so wie aus­ge­wähl­te Pro­zess­ak­ti­vi­tä­ten per Mausklick in einen Sub­pro­zess über­führt wer­den kön­nen. Auch soll­te man dar­auf ach­ten, dass mit­gel­ten­de Do­ku­men­te, IT-Sys­te­me und Rol­len di­rekt aus den Stamm­da­ten aus­ge­wählt wer­den kön­nen.
• Die Er­fas­sung von un­ter­schied­li­chen Gel­tungs­be­rei­chen soll­te vor­han­den sein. Denn der On­Boar­ding-Pro­zess in der Fir­men­zen­tra­le in Deutsch­land wird wahr­schein­lich ein ganz an­de­rer sein, als das On­Boar­ding im Pro­jekt­bü­ro in Tai­wan.
• Eine au­to­ma­ti­sche und fle­xi­ble Lay­out- und Dar­stel­lungs­op­ti­on ist wich­tig. Heute hat kei­ner mehr Lust und Zeit, Pfei­le und Ver­bin­dun­gen ma­nu­ell zu zie­hen oder ein­zel­ne Shapes aus­zu­rich­ten. Zu­sätz­lich ist zum De­sign­zeit­punkt oft noch nicht klar unter wel­cher Per­spek­ti­ve das Pro­zess­mo­dell dar­ge­stellt wer­den soll: Stehen die Durch­füh­rungs­ver­ant­wor­tung oder die ge­nutz­ten IT-Sys­te­me im Fokus der Be­trach­tung?
  Ab­bil­dung 5 und 6 ver­an­schau­li­chen diese Si­tua­ti­on. Es han­delt sich um den glei­chen Pro­zess. Nur wurde zwi­schen bei­den Ab­bil­dun­gen zur Lauf­zeit die Dar­stel­lung mit einem Maus­klick über einen Au­to­lay­ou­ter ver­än­dert. Auch eine An­pas­sung zwi­schen Ho­ri­zon­tal- und Ver­ti­k­al­lay­out wird oft benötigt und ist per Maus­klick mög­lich. Oder die Einblendung der mit­gel­ten­den Do­ku­men­te neben den ei­gent­li­chen Pro­zess­schrit­ten – ein Klick genügt.