Fach­abteilungen zum eigenen Entwickeln befähigen

Das Fach- und Prozesswissen des Hauses liegt bei Spezialisten in den Geschäfts­bereichen, und dort liegen auch die Automatisierungs­potenziale. Die IT kann sie nicht alle heben. Also sollen die Fachexperten selbst entwickeln dürfen, mit Werkzeugen, die wenig oder keinen Programmcode verlangen. Der Haken ist der Beruf: In einer Prüfungs­gesellschaft darf nicht jeder alles entwickeln und in Betrieb nehmen. Gesucht ist der Rahmen, der beides zugleich möglich macht — Befähigung in der Breite und Regelkonformität.

Die Regeln kommen aus dem Berufsstand, nicht aus der IT. Bevor wir über Werkzeuge gesprochen haben, haben wir die regulatorischen Grundlagen zusammengetragen: die bestehenden Bestimmungen des Hauses und die Anforderungen der einschlägigen Berufsgruppen. Erst daraus wurden die Regeln und Leitlinien für die entwickelnden Fachexperten abgeleitet. In einem Beruf mit Berufsaufsicht ist das die richtige Reihenfolge — umgekehrt entsteht ein Regelwerk, das der erste Prüfungsfall aushebelt.

Governance zweimal: organisatorisch und technisch. Regeln, die nur auf Papier stehen, werden umgangen. Deshalb erzwingt die System­umgebung dieselben Anforderungen, die das Regelwerk formuliert — über Rollen und Rechte, über getrennte Umgebungen und über Freigabeschritte in der Bereitstellungs­strecke. Die dreistufige Landschaft aus Entwicklung, Test und Betrieb war dabei nicht dazu da, den Fachexperten Arbeit zu machen, sondern ihnen abzunehmen: Was sie mit Werkzeugen ohne Programmcode entwickeln, wird automatisch in die richtige Stufe ausgerollt, mit den Prüfschritten davor, ohne dass sie die Umgebung verstehen müssen. An dieser Stelle entscheidet sich, ob Befähigung in einem regulierten Beruf überhaupt möglich ist.

Ein Kompetenz­zentrum, das weiterarbeitet, wenn das Projekt vorbei ist. Wir haben den Prozess des Zentrums definiert und dokumentiert, das Startpaket des Herstellers gegen die Anforderungen des Hauses geprüft und dort erweitert, wo es nicht passte, und einen Werkzeugkasten mit bewährten Vorgehensweisen für die ersten Anwendungs­fälle angelegt. Das ist der Unterschied zwischen einer Schulung und einer Struktur: Die Schulung endet, das Zentrum bleibt der Ort, an dem die nächste Fachabteilung anfängt.

Lernen an echten Fällen, nicht an Übungen. Im zweiten Schritt wurden erste Anwendungs­fälle gemeinsam mit den Fachanwendern umgesetzt. Das hatte zwei Zwecke: Die Beteiligten lernen im Tun, und die Konzepte aus dem ersten Schritt werden dabei überprüft. Was sich an einem echten Fall nicht bewährt, wird korrigiert, bevor es Vorschrift für alle wird.