Eines unserer Hauptprinzipien ist die ganzheitliche Sicht auf Geschäftsmodelle und -Prozesse. OBASHI-Darstellungen helfen, das Zusammenspiel von Geschäfts- und IT Prozessen, die Datenflüsse bis hin zur Hardware-Ausstattung zu visualisieren.

Das Akronym OBASHI steht für die Dokumentation von hierarchisch definierten Regeln:

• Owner: Wer ist der alleinige Eigner eines definierten Geschäftsprozesses?
• Business: Um welchen Geschäftsprozess geht es?
• Application: Welche Software-Anwendung bildet diesen Geschäftsprozess ab?
• System: In welchem Betriebs-System läuft die Anwendung?
• Hardware: Mit welcher Hardware (Blech) wird dieses System betrieben?
• Infrastructure: Wie ist diese Hardware in die vorhandene Infrastruktur eingebunden?

Wenn ein Unternehmen also konsequent sein Geschäftsmodell über die sechs Ebenen des OBASHI-Modells abbildet, entsteht Transparenz über die fachlichen und IT-technischen Verantwortlichkeiten und Abhängigkeiten. Es besteht Klarheit über die besonders geschäftskritischen Prozesse, sowie fachliche Leistungs-Schnitte. Daraus kann man zum Beispiel gesonderte Regressions-Testfälle ableiten, die mit jeder Software-Lieferung erneut und vollumfänglich getestet werden. Somit wird sichergestellt, dass das Unternehmen vorab die Kritikalität von jedem Change bewerten kann.

Der Aufwand bei der Einführung von OBASHI besteht zunächst in der eindeutigen Definition der Zuständigkeiten. Wer übernimmt für welchen Geschäfts-Prozess die alleinige Verantwortung? Wie grenzen sich Zuständigkeiten sowohl fachlich als auch technisch voneinander ab? Wie werden fachliche Leitungsschnitte definiert (siehe nachstehendes Beispiel) und auch im Applikations-Schnitt der IT-Systeme umgesetzt?

Quelle: eigene Darstellung

Zunächst wird also fachlich dargestellt, wie ein Unternehmen mit welchen Prozessen arbeitet. Danach werden die IT-Anwendungen dargestellt, die die Geschäftsprozesse unterstützen. Welche IT-Assets sind dazu notwendig und wie müssen Hardware, Software und Infrastruktur aufeinander abgestimmt werden? Welche Risikopotenziale für das Geschäftsmodell ergeben sich aus dem IT-Betrieb und wie geschäftskritisch ist ein System-Fehler?

OBASHI, Quelle: The ITSM Review

Als wir vor über 15 Jahren mit einem vereinfachten OBASHI-Ansatz in einem Konzern angefangen haben, war unser erster Schritt, End-to-End-Geschäftsprozesse zu definieren. Anschließend haben wir die gesamte Applikationslandschaft von über 650 Systemen den Geschäftsprozessen zugeordnet. Im ersten Schritt wurden somit Abhängigkeiten und vor allem Redundanzen sichtbar, die u.a. zu einem neuen IT-Architekturbild führten. Der deutlich schwerere Schritt war dann die Ableitung von IT-Service-Katalogen und SLA’s (Service Level Agreements – vertragliche Leistungsregelung zwischen Auftraggeber und Dienstleister für wiederkehrende Dienstleistungen) und die Aufnahme der Hardware/Infrastruktur. Den in Verbindung mit OBASHI immer wieder erwähnten Datenfluss zwischen Prozessen und Systemen sind wir erst in einem späteren Monitoring-Projekt angegangen.

Quelle: eigenes Bild

Wenn auch Sie sich mit OBASHI beschäftigt haben, schildern Sie uns gerne Ihre Eindrücke und Erfahrungen!

Christoph Lefkes