Michael Liehmann, Consultant des Organisations- und Strategieberaters ICG, kennt die Tücken im Projektgeschäft. Nach seiner IT-Karriere bei Organisationen und Unternehmen wie dem Bundeskanzleramt, Heidelberger Druckmaschinen und Siemens ist er 2010 auf die Beraterseite gewechselt. Die international aufgestellte Integrated Consulting Group (ICG) sieht sich mit Experten wie dem 41-jährigen Wiener als ein erfahrenes Beratungsunternehmen mit echtem IT-Expertenwissen. »Bei vielen IT-Projekten sind es immer wieder die gleichen Ursachen, die zu Problemen führen«, weiß er. »Meist wird nicht genügend auf die notwendigen Veränderungen am Arbeitsplatz oder Mitarbeiterfähigkeiten geachtet. Ein Paradefehler ist, wenn die Auswirkungen von IT-Projekten auf die Geschäftsprozesse unterschätzt werden.« Ein typisches Beispiel sei etwa eine Mitarbeiterin in einer Buchhaltungsabteilung, die ohne ausreichende Schulung von heute auf morgen mit einem neuen SAP-Programm umgehen muss. »Widerstand ist in so einen Fall fast schon vorprogrammiert. Diese Situation ist weniger ein Thema für die Technik, sondern ein Führungsthema«, so der Experte. Doch auch bei genügend Schulung der betroffenen Anwender können sich Widerstände gegen ein neues System, ein neues IT-Werkzeug oder neue Prozesse bilden. Dies zu lösen ist ebenso eine Aufgabe für die Unternehmensführung, ein Thema der gesamten Organisation.
Liehmann zeigt ein anderes Beispiel auf: eine Tischlerei, in der ein neues Textverarbeitungssystem eingeführt wird. Abgesehen von den Skills, die nun alle für dessen Anwendung benötigen, wird die neue Lösung vermutlich auch Auswirkungen auf die Vertriebsmitarbeiter im Außendienst haben. Welche Möglichkeiten, deren Workflow in die Lösung zu integrieren, gibt es? Welche elektronischen Postfächer machen in der Organisation des Handwerksbetriebes Sinn? Sollte nicht auch gleich das Ablagesystem des Unternehmens verändert werden? Es geht hier nicht nur um den simplen Einsatz eines neuen IT-Werkzeugs, wie man es vielleicht anfangs vermutet hätte, sondern vielmehr um die Veränderung von Geschäftsprozessen.
Man möchte meinen, dass gerade in der IT-Branche das Wissen um Change Management und der Impact auf Geschäftsprozesse durch IT-Veränderungen ein abgelutschtes Thema ist. Doch fallen in Projekten gerade bei Budgetnot jene Maßnahmen dem Sparstift zum Opfer, die über die technische Implementierung hinaus die Menschen sozial begleiten sollen. Intern besetzte Projektbegleiter haben wiederum ein Glaubwürdigkeitsproblem, meint Liehmann. »Wenn Sie beim gleichen Anbieter eine Unfallversicherung und eine Rechtsschutzversicherung kaufen, können Sie davon ausgehen, dass die beiden Abteilungen einander nicht besonders auf die Nerven gehen werden.« Ein zugeschalteter neutraler Dritter könne besser ein Vertrauensverhältnis zu allen Mitarbeiterebenen aufbauen, versichert der ICG-Berater.
Nicht ausführen, sondern vorschlagen
Traditionell werden in IT-Projekten in den Unternehmen vorhandene Strukturen technisch unterstützt. Ein größerer Nutzen entstünde dagegen auf neuen Wegen, die mit der IT beschritten werden können. Für Liehmann ist ein aktuell laufendes Projekt der ICG im öffentlichen Bereich ein gutes Beispiel dazu. Sachbearbeitern werden beim Anlegen von Datensätzen über Formulare gleichzeitig weitere Anhänge, Anforderungen und Verknüpfungen aus dem passenden Themenfeld vorgeschlagen. Erst das proaktive Agieren des Systems unterstützt die eigentliche Kernkompetenzen der Behörde: die Wissensarbeit in spezialisierten Themenfeldern.
Der Berater ist aus diesem Grund auch kein Fan der klassisch-monolithischen Vorgangsweise bei Projektausschreibungen in der IT. Deren Pfad sah ja bisher stets ähnlich aus: Ein Auftraggeber erstellt ein mehrseitiges Heft mit den Anforderungen, der Anbieter schlüsselt die Leistungen detailliert in einem zehnmal stärkeren Katalog auf. Am Ende des Tages streiten sich die Beteiligten dann aber um Formulierungen und Paragraphen. Auch hier gibt es bereits einen sinnvolleren Zugang – etwa das bereits in der Softwareentwicklung populäre Scrum-Modell. Dabei wird das Pflichtenheft durch eine zu Beginn formulierte Vision ersetzt. Detaillierte Ziele werden anhand von User-Storys beschrieben, in der Projektumsetzung nähert man sich einander dann von beiden Seiten – Entwickler ebenso wie Auftraggeber. »Mit der Detailfuchserei, wie sie bislang bei Projekten vorgeherrscht hat, ist keiner glücklich geworden. Unser Ansatz eines häppchenweisen Zugangs, der inkrementellen Umsetzung, lässt mehr Spielraum für vielleicht neue Erkenntnisse und Wege zu. Klarerweise passt dies nicht überall. Wenn Sie ein Kraftwerk bauen, müssen Sie bereits zu Beginn alle Details kennen, wie es aussehen wird«, schmunzelt Liehmann. Aus der gemeinsamen Erfahrung mit Kollegen, Kunden und vielen Unternehmen weiß der Berater aber, dass der modellhafte Scrum-Zugang in viele andere Bereiche passt. Der Einsatz eines Beraters als Moderator in solchen Umsetzungen liegt dann auf der Hand: »Wir können Input geben und wir helfen bei der Kommunikation unter den Technikern auf sozialer Ebene.«