Business-Process-Management (BPM) in die Praxis umzusetzen, gehört zu den größeren Herausforderungen für eine IT-Abteilung. Zehn Empfehlungen helfen, Projekte zu stemmen und das System zukunftssicher zu gestalten.
1. Barrieren überwinden
Prozess-Management setzt voraus, dass sich die fachliche und die technische Seite, zwei Bereiche mit unterschiedlicher Sprache, nicht nur verständigen, sondern im Klaren sind, dass sie Partner in einem Implementierungsprojekt mit weit reichenden Folgen für ihr Unternehmen sind. Das Team sollte alle Mittel nutzen, die Kommunikation zwischen den Abteilungen anzustoßen und lebendig zu halten, um genug gemeinsames Wissen zu gewinnen. Ein externer Partner kann in der Planungsphase eines Projekts helfen, vorausgesetzt er bringt nachweislich gute Kommunikations- und Organisationsfähigkeiten mit (siehe auch: Die wichtigsten Fragen zum Business-Process-Management)
2. Die Fundamente bestimmen die Haltbarkeit
Ein Business-Process-Management-System (BPMS) besteht aus vielen Einzelkomponenten, die höchst unterschiedliche Aufgaben erfüllen, gleichwohl aber reibungslos zusammenarbeiten müssen. Das wird nur gelingen, wenn die IT-technische Entwicklung auf einem klaren Framework, einem funktionalen Konzept aufsetzt, das flexibel und erweiterungsfähig ist. Das Framework umfasst eine Prozess-Engine, die Aufgabenverwaltung auf dem Benutzer-Interface, eine Service-Registry für alle Zugangsinformationen und gegebenenfalls auch die Service-Infrastruktur der Basisdienste. Die Nagelprobe für die Qualität dieses Fundaments ist jeder Änderungswunsch. Von einem guten Konzept darf das Projekt-Management nicht mehr abweichen.
3. Offen sein für Neues
BPM-Umgebungen erleben durch neue oder angepasste Prozesse häufige Änderungen. Folglich sollte ein solches System darauf angelegt sein, den Aufwand für solche Änderungen klein zu halten und dadurch die Prozesstreue zu verbessern. Das setzt wiederum voraus, vorab denkbare Change-Szenarien zu analysieren, Erweiterungen einzuplanen und die Ergebnisse solcher Überlegungen in den Prozess der Entwicklung eines Frameworks einfließen zu lassen.
4. Klare Zuständigkeiten und Abläufe definieren
IT-Prozesse orchestrieren bestehende Basisfunktionen. Diese müssen klar strukturiert und definiert sein. Prozesse können Schwächen der Servicemodellierung an der Basis nicht ausgleichen. Vielmehr machen sich Probleme in diesem Bereich bei späteren Veränderungen der Prozesse bemerkbar und führen zu ineffektivem Prozess-Management. Das kann gegebenenfalls das Gesamtziel eines BPM-Systems gefährden.
5. Prozesse sollen von Dauer sein
BPM-Systeme haben eine überdurchschnittliche Lebensdauer. Insbesondere die aus bewährten Fachverfahren entwickelten Prozessdefinitionen überleben die üblichen Turnaround-Zyklen der IT. Daher müssen sie portabel angelegt werden, um die ihnen zugrunde liegende technische Infrastruktur einschließlich der Prozess-Engine mit möglichst geringem Aufwand austauschen zu können. Entsprechend ist für die Prozesse alles irrelevant, was nur kurzzeitige Bedeutung hat. Vielmehr sind diese so zu modellieren, dass sie universellen, grundsätzlichen Charakter haben und einen künftigen Bedarf abdecken.
6. Standards für die Evolution
Austauschbarkeit lässt sich konsequent nur realisieren, wenn IT-Verantwortliche sich, auch wenn es Mehraufwand bedeutet, an international anerkannte Standards halten. Nicht gemeint sind damit firmenspezifische Spezifikationen. Die wichtigsten unabhängigen Standards im Prozess-Management sind: XML und BPEL zur Beschreibung von Business-Prozessen in einer allgemein gültigen Notation, WSDL zur Beschreibung von SOA-Funktionen und deren Ort, XSD für die Beschreibung von Datenschemas, WS-Security als Architektur für SOA-Sicherheit, SOAP zur Beschreibung von SOA-Anfragen und Antworten sowie Xpath als Query-Sprache für XML-Datenmodelle (siehe auch: Standards erleichtern BPM-Projekte).
7. Open Source gegen proprietäre Fallen
In allen IT-Lösungen, auch in herstellerspezifischen quelloffenen Systemen, lauern Fallen, deren Ergebnis eine Abhängigkeit von einem Anbieter wäre. Das kann den evolutionären Wandel der Infrastruktur sehr aufwändig machen kann. Vergleichen lässt sich das Problem mit den Unterschieden zwischen Unix-Derivaten, die trotz vieler Standards einen Wechsel zwischen Herstellern erschweren. Open-Source-basierende Lösungen haben den Vorteil, dass sich solche Punkte von erfahrenen BPM-Praktikern identifizieren lassen.
8. Eindeutig definieren und beschreiben
Die Basisdienste müssen klar definiert sein. Die Anwendungs-Programmier-Schnittstellen (APIs) sind sauber zu dokumentieren. Unterschiedliche Datenmodellierungen, etwa in Folge divergierender Beschreibungen einer Entität - beispielsweise eines Kunden - in verschiedenen Fachabteilungen, gilt es zu verhindern, weil sie aufwändige Transformationen notwendig machen. Starke Bindungen, in denen ein Dienst einen anderen voraussetzt, sind nicht immer auszuschließen, sollten aber auf ein Minimum reduziert werden. Technologieübergänge werden durch die Integration von Legacy-Systemen und Ähnlichem zwangsläufig auftreten. Bei SOA-inhärenter Technik, etwa in Form von Schema-Transformationen, sind sie zu vermeiden.
9. Von der Pilotinstallation bis zum Post-Deployment planen
Bei der Einführung eines so stark mit den Fachabteilungen verzahnten Systems ist von Anfang an mit vielen Korrekturen und Änderungen zu rechnen. Die Qualitätssicherung der Prozessdefinitionen ist in der Regel langwieriger als bei üblichen Softwarekomponenten und muss realistisch geplant werden. Änderungen lassen sich durch eine gut geplante Pilotphase reduzieren. Um Änderungen effizient zu verarbeiten, ist es notwendig, vorab spezielle Tools zum Fehler- und Change-Management zu implementieren.
10. An morgen denken
Prozess- und Software-Updates sind bei Prozess-Management-Systemen aufwändiger als bei anderen Unternehmensanwendungen. Denn bestehende Prozessinstanzen lassen sich oft nur mit größerem Aufwand auf eine neue Prozessversion migrieren. Unabhängig von der verwendeten technischen Infrastruktur muss das Design dem System auf jeder Ebene eine Zukunft von zehn Jahren und mehr eröffnen. Dazu sollte man mögliche Perspektiven für die Entwicklung des Anwenderunternehmens, seines gesellschaftlichen Umfelds (zum Beispiel in der Gesetzgebung) sowie des technischen Fortschritts in der Informations- und Kommunikationstechnik in Betracht ziehen.