Meist liegt es an organisatorischen Faktoren und nicht an der Technik, wenn IT-Projekte scheitern. Wie sieht ein intelligentes Prozessmanagement aus? Von Dr. Rainer Feldbrügge
Organisationen mögen keine Veränderungen, aber gerade in IT-Projekten steckt viel Veränderungsdruck. Das liegt schon an den hohen Erwartungen, die damit verknüpft sind: Aufgaben sollen (teilweise) automatisch erledigt werden; Entscheidungen sollen regelbasiert erfolgen; Vorgänge sollen zuverlässig weitergeleitet und dokumentiert werden. Und schließlich wird erwartet, dass Informationen da landen, wo sie gebraucht werden.
Jede dieser Erwartungen bedeutet Veränderung: Automatisierung erfordert, dass die Komplexität von Vorgängen reduziert wird. Regelbasierte Entscheidungsfindung funktioniert nur mit eindeutigen Vorgaben. Zuverlässige Weiterleitungen brauchen einheitliche Abläufe und Zuständigkeiten. Wenn Informationen dahin kommen, wo sie gebraucht werden, verschwindet Herrschaftswissen – Hierarchien werden abgebaut. Klar, dass bei solchen Veränderungen manchen Leuten angst und bange wird und Widerstand vorprogrammiert ist. Wie kann man also ein IT-Projekt vorausschauend um diese Klippen steuern?
Erster Schritt: Die Widerstände verstehen
Organisatorischer Widerstand gegen Veränderungen der betrieblichen Informationstechnologie hat nichts mit bösem Willen oder technischer Rückständigkeit zu tun. Die Mitarbeiter kennen ihre Abläufe in allen Facetten, sie haben bisher für jedes Problem eine Lösung gefunden und sie wissen, welche Herausforderungen sich im Detail verstecken können. Die Zukunft aber kennen sie nur aus wolkigen Beschreibungen der IT-Lösung, häufig aus der Feder eines Marketing- oder Technikexperten. Oft genug weichen die IT-Projektleiter aus, wenn sie mit Fragen konfrontiert werden und verweisen auf später. Das gibt den Mitarbeitern nicht die Sicherheit, dass für ihre Aufgabenstellungen gute Lösungen gefunden werden – sie bleiben in Alarmstellung, bis etwas schiefgeht. Und irgendwas geht immer schief.
Die Sprengkraft liegt in der emotionalen Ladung, die die Veränderungen mit sich bringen. So sind komplexe Aufgaben und Entscheidungen für ihre „Inhaber“ mit besonderem Status verbunden. Sie werden gereizt reagieren, wenn man mit einer scheinbar einfachen Matrix kommt. Aber genau diese Handhabung von Komplexität ist häufig erforderlich, denn die Helden der Arbeit werden seltener und teurer.
Zweiter Schritt: Veränderungsprozess sichtbar machen
Was hilft, ist ein frühzeitiger realistischer Blick in die Zukunft. Und hier kommt das Werkzeug „Organisationsentwicklung“ ins Spiel – also ein geplanter, gelenkter und systematischer Prozess, der Veränderungen in Unternehmen begleitet. Wer die Werkzeuge der Organisationsentwicklung nutzt, macht Veränderungsprozesse sichtbar und ruft die Beteiligten zur Mitarbeit auf. Der Vorteil: Die Mitarbeiter erkennen, wie ihre Arbeit zukünftig laufen wird, welche Rolle ihnen dabei zukommt (und welche Rolle nicht mehr). Sie können ihre Bedenken und ihre Befürchtungen äußern, womit die notwendigen Themen auf dem Tisch sind. Eine Extrarunde Diskussion in dieser Phase verhindert eine spätere Bauchlandung.
Dritter Schritt: Ein Prozessmodell nutzen
Doch wie sollen die Fachabteilungen wissen, wie es später sein wird, wenn es die Lösung noch gar nicht gibt? Hier braucht man ein Prozessmodell, das alle Aufgaben, Zuständigkeiten, Systeme und automatischen Schritte übersichtlich gliedert. So erkennen alle, wie ihre Prozesse heute laufen und wie es in Zukunft sein wird. Wenn das Modell einerseits einfach verständlich und andererseits eindeutig ist, unterstützt es die organisatorische Klärung vor der technischen Lösung. Mit dem Prozess-Modellierungsstandard BPMN 2.0 (Business Process Model and Notation) gibt es dafür ein gutes Instrument. Dabei handelt es sich um einen branchenübergreifenden Industriestandard zur eindeutigen Beschreibung von Prozessen, wie er von den meisten Herstellern von Unternehmens-Software verwendet wird. Experten können damit Prozesse verständlich beschreiben und IT-Entwickler nutzen dasselbe Modell für die technische Konzeption.
Das Modell hilft, die organisatorischen Diskussionen im Vorfeld zu moderieren, Szenarien zu vergleichen und zusammen mit dem IT-Anbieter die beste Option und auch die Kosten für die Zukunft zu definieren. So sind Entscheidungen eindeutig – da bleibt kein Raum mehr für Interpretationen und die spätere Neuauflage alter Diskussionen. Und die IT-Dienstleister arbeiten auf der Basis eines eindeutigen Auftrags: Ihr Pflichtenheft leitet sich direkt aus dem vereinbarten Prozessmodell ab.
Aber fast immer ändern sich die Anforderungen an eine Lösung während des Projektes. Zudem wird gefordert, dass sich die erarbeitete IT-Lösung auch nach deren Implementierung flexibel an Veränderungen anpassen lässt. Wie geht man damit um? Hier hilft die agile Software-Entwicklung, die immer auf Prozessmodellen basiert. Ändert sich ein Faktor in der Projektumwelt, kann man im Modell durchspielen, welche Auswirkungen das auf das Projekt hat und wie man darauf reagieren kann. Das Pflichtenheft ist ein lebendiger Prozess und kein totes Vertragswerk im Schrank.
IT-Projekte zielen ins Herz des Unternehmens. Wer sein IT-Projekt mit einem Prozessmodell begleitet, ist im Vorteil: Interne Widerstände werden frühzeitig erkannt und die Entwicklung des Unternehmens bleibt im Fluss.
