Dass die IT-ler dadurch Zeit für die Funktionalitäten haben, war keine leichte Umstellung. Für Heise ist das eine Aufwertung ihrer Arbeit. Das hat anfangs aber nicht jeder so gesehen. "Es mag daran liegen, dass der Mensch gern seinen Gewohnheiten treu bleibt", sagt der Infrastruktur-Chef. "Die Akzeptanz dieser neuen Rolle war nicht von heute auf morgen hergestellt."

IBM muss den Change genauestens dokumentieren

So äußerten einige Mitarbeiter Bedenken, den Skill für die Software zu verlieren und im Falle einer Panne nicht handeln zu können. Abhilfe schafft ein Change Management-Prozess. "IBM muss vereinbarungsgemäß jeden Schritt dokumentieren", erklärt Heise. "Und unsere Mitarbeiter haben jederzeit Zugriff auf diese Dokumentation und den aktuellen Status des Changes."

Dass die Veränderungen trotz anfänglicher Bedenken umgesetzt werden konnten, hängt mit der frühen Einbindung und dem Engagement der Gruppenleiter zusammen. "Wir wollten das, und das hat auf die Teams ausgestrahlt", ist Heise überzeugt. "Als Führungsperson darf man bei einem solchen Projekt nicht unsicher sein." Wichtig sei auch, dass die Mitarbeiter weiterhin die Verantwortung für die Qualität der Software tragen. Sie geben zwar das Doing ab, behalten aber den Hut auf.

Günther Heises Fazit nach knapp zehn Jahren: Die Kosten für diese Dienstleistung sind über den gesamten Zeitraum konstant geblieben, die Verfügbarkeit wurde eingehalten und bei der Bundesbank hat sich ein Release-Management etabliert. Ob die Qualität der Services eingehalten wird, überprüft die Bank an Punkten wie Termintreue, Zahl der Incidents und der Auswertung von Problem Records.