Zusammenspiel zwischen Fachabteilungen und IT
Wozu noch ein Dialog?
Die Einführung von BPM im Unternehmen führt zu einem Paradigmenwechsel in der gesamten Kette von der Erfassung fachlicher Anforderungen, über Änderungsmanagement bis hin zur technischen Implementierung und Steuerung der Geschäftsprozesse. Dieser drückt sich vor allen Dingen in dem Ziel einer nahtlosen toolunterstützten Nachvollziehbarkeit der fachlichen Vorgaben und in der Möglichkeit, diese direkt als Prozessmodelle zur Ausführung in die IT zu bringen, aus. Die angestrebte Durchgängigkeit zwischen Business als Auftraggeber und IT als Auftragnehmer führt zu einer deutlichen Reduktion von Missverständnissen und Unschärfen zwischen den Abteilungen. Dabei entstehen Anforderungen auf sowohl IT- als auch fachlicher Seite, deren jeweilige Nichterfüllung den Erfolg der BPM-Einführung gefährden kann.
Wer treibt? Wer bestimmt die Rahmenbedingungen?
Aus Geschäftssicht liegt ein optimales Management der Geschäftsprozesse primär im Interesse und Verantwortungsbereich der Fachabteilungen. Dort befindet sich das Wissen über die Prozesse und dort laufen sie ab. Bedarf für BPM kann sowohl punktuell entstehen, um lokal Verbesserungen zu erreichen, als auch global im Rahmen eines unternehmensweiten Optimierungsansatzes. In beiden Fällen müssen die Prozesse durch die unterliegenden IT-Systeme möglichst gut unterstützt werden. Dazu ist die IT als Dienstleister im Unternehmen gefragt.
Im Rahmen des BPM-Lifecycles (Erfassung, Planung, Implementierung und Messen sowie kontinuierliche Verbesserung von Prozessen) ist das Änderungsmanagement, in das beide Abteilungen eng eingebunden sind, als Thema besonders hervorzuheben. Änderungen können durch die Fachabteilung angestoßen werden, um z. B. auf neue Marktbedingungen oder eine geänderte Unternehmensstrategie zu reagieren, aber auch durch die IT-Abteilung, weil beispielsweise neue Technologien zum Tragen kommen.
Unbestritten ist die Fachabteilung als Vertreter der Geschäftsziele und -prozesse die treibende Kraft für BPM. Allerdings werden die Geschäftsprozesse nicht im luftleeren Raum implementiert, sondern auf Basis einer bestehenden IT-Landschaft, IT-Strategie, Governance etc. Daraus ergeben sich Rückkopplungen, die zu einer Neubewertung von Business-Cases im Rahmen von BPM führen können. Durch IT-Best-Practices, die Nutzung verfügbarer Services und Funktionen und basierend auf einer etablierten und flexiblen IT-Praxis können sich Vorteile für die Fachabteilung ergeben.
Wer spielt mit?
BPM hat einen Querschnittscharakter und erzwingt damit eine sehr enge Zusammenarbeit verschiedenster organisatorischer Einheiten. Wichtige Voraussetzung dafür ist ein gegenseitiges Verständnis der jeweiligen Fachtermini. Fachabteilung und IT sprechen naturgemäß unterschiedliche Sprachen. Auf fachlicher Seite liegt der Fokus eher auf guter Verständlichkeit für die Mitarbeiter, formale Korrektheit spielt eine geringere Rolle. Je näher man der Implementierung der Prozesse kommt, desto detaillierter müssen diese beschrieben sein und umso höher sind auch die formalen Anforderungen bezüglich Korrektheit und Vollständigkeit. Da es prinzipiell nicht sinnvoll ist, beide Seiten zu einer gemeinsamen Sprache zu zwingen, muss also an der Schnittstelle zwischen den Abteilungen eine klare Definition der fachlichen Termini (Vokabular) vorliegen, um ein durchgängiges, korrektes Verständnis zu erreichen. Standardisierte Notationen wie BPMN sind hier zwar hilfreich, allerdings kein Allheilmittel. Es muss von Fall zu Fall genau geprüft werden, ob die Ausdrucksmöglichkeiten tatsächlich den Anforderungen und Fähigkeiten der jeweiligen Projektbeteiligten entsprechen. So kann zum Beispiel auch die Fachabteilung BPMN zur Beschreibung der Prozesse verwenden (evtl. mit eingeschränktem methodischem Scope), sie sollte aber nicht dazu gezwungen werden. Eine gemeinsame sprachliche Basis muss aber auf jeden Fall geschaffen werden, andernfalls ist eine abteilungsübergreifende Kommunikation kaum möglich. Dieses Vokabular muss zentral zur Verfügung stehen und sauber in den verschiedenen Beschreibungssprachen der einzelnen Beteiligten verwendet werden.
Der mit Abstand wichtigste Punkt für eine erfolgreiche Zusammenarbeit ist unbestritten eine gute Kommunikation zwischen allen Beteiligten. Weiterhin müssen aber sowohl Fach- als auch IT-Abteilung bereit sein, sich im Rahmen der BPM-Einführung bestimmten Veränderungen zu unterwerfen. Die Fachabteilung muss schon bei der fachlichen Spezifikation der Prozesse IT-nahe Konzepte wie Modularisierung, Wiederverwendbarkeit und Service-Orientierung berücksichtigen und sich im Klaren darüber sein, dass BPM durch die Neugestaltung der Prozesse auch zu starken Veränderungen in der Organisation und den Verantwortlichkeiten führen kann. Die IT wiederum muss ihre Rolle als Dienstleister begreifen und bereit sein, schon bestehende Systeme und Architekturen an die fachlichen Anforderungen anzupassen.
Essenziell für jede Art von BPM-Ansatz (Projekt oder unternehmensweite Strategie) ist, dass beide Abteilungen von Anfang an beteiligt sind und auf Basis gemeinsamer Konventionen zusammenarbeiten. Unabdingbar ist dabei eine klare Zuweisung der Verantwortlichkeiten und Rollen. Der Erfolg einer umfassenden BPM-Einführung hängt wesentlich von der Einbindung des oberen Managements ab. Ein Projektstart auf Ebene der Subprozesse oder Aufgabengruppen kann aufgrund der geringen Erfolgswahrscheinlichkeiten nur in einem Scheitern enden. Neben der klaren Ausrichtung der gesamten Organisation auf ein geschäftsmodellgesteuertes Unternehmen sind weitere Instanzen essenziell für den Erfolg.
Die Einrichtung eines BPM-Kompetenz-Centers hat sich dabei als probates Mittel erwiesen. Aufgaben dieses Kompetenz-Centers sind:
- alle potenziell involvierten organisatorischen Einheiten zu erfassen,
- die schon bestehenden methodischen Ansätze zu analysieren und zu harmonisieren
- übergreifende Konventionen zu schaffen mit besonderem Fokus auf dem Übergang vom fachlichen zum technischen Prozess,
- die entsprechenden Werkzeuge zur Unterstützung in den verschiedenen Phasen auszuwählen,
- Definition der verschiedenen Rollen (Process-Owner, Process-Expert, Process-Engineer, Architect, Process-Developer, …), wo sie angesiedelt sind und wie ihre Zusammenarbeit geregelt ist,
- Beschreibung des Änderungsmanagements (wer stößt Änderungen an, wer muss sie genehmigen, wie werden die Auswirkungen und möglichen Risiken vorher abgeschätzt) sowohl während des initialen Projektes als auch später im Rahmen einer kontinuierlichen Pflege und Weiterentwicklung der Prozesse.
Sehr hilfreich für die o. g. Vermittlungsfunktion zwischen Fachabteilung und IT erweist sich die Rolle des Process-Engineers, der als Mediator bzw. Übersetzer für beide Seiten dienen kann. Oft wird diese Rolle von einer weisungsberechtigten und fachlich bzw. technisch kompetenten Person entweder auf Fachbereichs- oder IT-Seite geplant. Bisherige Umsetzungen zeigen, dass diese Rolle im Bereich der Organisation angesiedelt ist. Von einer Einbindung der Rolle im Bereich des CIO wird aufgrund von Erfahrungen abgeraten; eine Umsetzung von BPM-Vorhaben droht dann zu technisch auszufallen. Der Aufbau separater BPO-/BPM-Bereiche in der Linie wird sich erst in den kommenden Jahren durchsetzen. Bei lokalen Verbesserungen werden stabsstellenähnliche Ressourcen zu Rate gezogen. Eine feste Rolle wird zukünftig sicherstellen, dass die beiden bisher getrennt agierenden Bereiche reibungslos, zielorientiert und effizient kooperieren können.
Was ist das Objekt des Dialogs?
Das im Projekt entstehende bzw. angepasste, bevorzugterweise hierarchische Prozessmodell (abgebildet auf verschiedenen Abstraktionsebenen – fachlich, logisch, technisch) dient verschiedenen Zwecken. Neben der grundsätzlichen Aufforderung an alle Beteiligten (Stakeholder) am Dialog teilzunehmen, wird gemeinsam ein grafisches Abbild der Unternehmung erzeugt. Auf Basis der im Vorfeld aufgenommenen Prozesse und Tätigkeiten können die SOLL-Prozesse erstellt werden. Mittels Simulationen unter Beteiligung der fachlichen und technischen Seite wird eine spätere Erreichung der Ziele und eine Risikoabschätzung im Rahmen des Change-Managements möglich. Weiterhin wird eine unternehmensweit verfügbare Prozessdokumentation aufgebaut, einsetzbar zur Schulung und im operativen Betrieb. Und nicht zuletzt nutzt man das durchgängige Prozessmodell auch zur Messung und Bewertung der laufenden Prozesse, um einschätzen zu können, inwieweit die ursprünglich anvisierten Ziele erreicht wurden und wo weiteres Verbesserungspotenzial vorhanden ist.
Autor(en) dieses Artikels
Plamen Kiradjiev, IBM Deutschland GmbHCo-Autor(en) dieses Artikels
Dr. Boris Petkoff, AccordSystems - Friedrich Vollmar, IBM Deutschland GmbH - Uwe Rödiger, Software AG - Alexander Gutendorf, SONOXO GmbH - Julia Wagner, Software AG - Jan Thielscher, EACG GmbH - Alexander Gutendorf, SONOXO GmbH - Dominik Blattner, CDI AG - Carlos Leez, SONOXO GmbHDownload
Unsere Leitfäden stehen Ihnen auch zum Download zur Verfügung. Um unseren Downloadbereich zu nutzen, registrieren Sie sich bitte.
Hier registrieren

