OBASHI

Die Erfassung und Modellierung von Services stellt Unternehmen regelmäßig vor eine Herausforderung. Das große Problem: Es gibt kein einheitliches Konzept! Jeder Mitarbeiter hat einen anderen Blick auf die Services und seine Komponenten. Häufig werden dann auch nur die Komponenten im Service aufgeführt, die aus Sicht des Mitarbeiters essenziell für diesen sind. Dementsprechend ist auch jeder Service anders aufgebaut.

Jeder Mitarbeiter hat seine eigene Art, diese zu beschreiben und auch inhaltlich zu gliedern. Dies resultiert oft in Verständnisproblemen der anderen “Leser”. Ziel muss es daher sein, einen Standard zu nutzen, mit dem eine Vielzahl von Services modelliert und für alle Beteiligten verständlich und transparent dargestellt werden können.

OBASHI als Lösung des Problems

Sie werden zunächst denken: “OBASHI? Ist das eine neue japanische Management-Methode”. Keine Bange. OBASHI könnte nicht britischer sein. Aber was hat es mit diesem Konzept auf sich? Und wie hilft Ihnen diese Methode, die Datenflüsse in Ihrem Unternehmen besser zu verstehen? 

OBASHI ist eine Methode für die Modellierung von Services. Genauer gesagt hilft Ihnen diese Methode, die Datenflüsse zwischen Geschäftsprozessen und der IT darzustellen. OBASHI ist hierzulande wenig bekannt, wird jedoch international über alle Branchen hinweg eingesetzt.

Bei dieser Methode werden Services in 6 Ebenen dargestellt. Durch dieses Vorgehen wird sichergestellt, dass sich Mitarbeiter aktiv mit den Services auseinandersetzen und die notwendigen Komponenten kennen. Auch werden Services durch die klare Strukturierung dieses Modells für alle Beteiligten verständlich.

Das OBASHI-Ebenenmodell

Jede Ebene in OBASHI adressiert einen Bereich im Servicebaum. Schnell wird klar, das hier nicht einfach nur Services modelliert werden, sondern diese Informationen auch im Alltag genutzt werden können. Wenn Beispielsweise ein Server ausfällt, ist sofort ersichtlich, welche Services davon betroffen sind. Die verantwortlichen Personen sind so schnell informiert. Die Priorisierung von Tasks und ggf. die Überbrückung der Services bis zur vollständigen Wiederherstellung des Servers ist leicht umzusetzen.  

Vor allem IT-Führungskräften fällt es oft schwer zu verdeutlichen, wie Wichtig die IT für das Unternehmen wirklich ist. Budgetkürzungen und stundenlange Meetings, um Ausgaben zu erklären oder diese zu verteidigen, sind in vielen Unternehmen ständiger Begleiter. Durch die Modellierung mit der OBASHI-Methode verfügen Sie über eine visualisierte Ansicht aller Geschäftsprozesse im Unternehmen. Sie haben jederzeit die Möglichkeit aufzuzeigen, wie das Unternehmen arbeitet und was dafür benötigt wird.

OBASHI-Regeln

Damit diese Methode funktioniert, müssen einige Regeln eingehalten werden.

  • Ein Element steht für genau eine beliebige (physische oder virtuelle) Ressource.
  • Ein Element kann nur in einer Ebene existieren und nicht über mehrere Ebenen vergrößert werden.
  • Jedes Element kann durch frei wählbare Attribute beschrieben werden.
  • Jedes Element kann zu jedem anderen Element in Beziehung stehen.
  • Jedes Element hat eine durch den OBASHI-Standard definierte Farbe. Farben, die nicht zum Standard gehören, müssen in einer Legende explizit erklärt werden.
  • Diese Beziehungen werden durch einen (oder mehrere) von sechs Typen definiert.
  • Diese Beziehungstypen sind:
    a) Connection (Verbindung)
    b) Dependency (Abhängigkeit)
    c) Spatial (räumliche Beziehung)
    d) Set (Gruppierung)
    e) Layer (Beziehung in der gleichen Ebene)
    f) Sequential (Datenfluss-Verbindung)
  • Die Beziehungstypen folgen bestimmten Regeln (Beziehungs-Regeln).
  • OBASHI erfüllt die Datenfluss-Regeln.
  • Jeder Datenfluss kann durch frei wählbare Charakteristika näher beschrieben werden.

Tatsächlich schreibt der OBASHI-Standard eine genau definierte Farbe für jeden Element-Typ vor (z.B. #abdebe für die Infrastruktur-Ebene und #d5b7e1 für die Ownership-Ebene). Diese Farben sind in jedem Diagramm zu verwenden. Alle Farben, die nicht dem Standard folgen, müssen in einer beigefügten Legende erläutert werden.

In dieser Aufstellung begegnen uns einige Dinge, die nicht sofort verständlich sind. Was ist eine räumliche Beziehung? Was hat es mit den Beziehungsregeln auf sich? Und was sind Datenfluss-Regeln? Im Folgenden klären wir diese Begriffe.

OBASHI Beziehungstypen

Wie bereits erwähnt, können Elemente auf verschiedene Weise miteinander verknüpft sein. Die einfache Verbindung und die Abhängigkeit sind hier noch einfach zu verstehen. Die Verbindung (Connection) ist die häufigste Art, wie ein Element mit einem anderem verknüpft sein kann. Das andere Element befindet sich dann eine Ebene höher oder eine Ebene darunter. Die Abhängigkeit (Dependency) hingegen kann auch über mehrere Ebenen hinweg bestehen. Schließlich ist die Rechnungsstellung (Ebene B) direkt abhängig vom Funktionieren des entsprechenden Servers (Ebene H) mit dem CRM-System.

Eine Beziehung vom Typ „Layer“ (Ebene) existiert, wenn zwei Elemente in der gleichen Ebene verknüpft sind. 
Eine Gruppe von Elementen (Set) wird genutzt, wenn mehrere Elemente logisch zusammen gehören. Das ist beispielsweise bei virtuellen Maschinen der Fall: physischer Server, Betriebssystem, VM-Software, Gast-System u. s. w. .

Eine Sequenz wird immer dann genutzt, wenn der Datenfluss vom Daten-Erzeuger zum Daten-Empfänger dargestellt werden soll.

Etwas komplizierter wird es, wenn von räumlichen Beziehungen die Rede ist. Dieser Beziehungstyp wird verwendet, um eine Zugehörigkeit eines Elements zu einem anderen zu beschreiben. Ist Element A ein Teil von Element B, handelt es sich um eine räumliche Beziehung. Dieser Beziehungstyp ist der wohl komplexeste in der OBASHI-Welt.

OBASHI-Beziehungen müssen geregelt werden

Wir kennen nun die Typen, mit denen Elemente innerhalb eines OBASHI-Diagramms verbunden werden können. Diese Verbindungen folgen jedoch einem Satz eindeutiger Regeln.

  • Die Elemente innerhalb einer Ebene stehen implizit in Beziehung zueinander.
  • Steht ein Element über oder unter einem anderen Element, existiert eine implizite Beziehung.
  • Verbunde Elemente haben eine explizite Beziehung zueinander.
  • Eine Abhängigkeit (Dependency) ist immer gerichtet (Die Rechnungsstellung ist vom CRM abhängig, das CRM jedoch nicht von der Rechnungsstellung).
  • Ein Element kann in einem oder mehreren Sets vorkommen.
  • Elemente können eine oder mehrere Instanzen in einer Ebene haben.
  • Datenflüsse beinhalten immer zwei oder mehr Elemente, die verbunden oder voneinander abhängig sind.
  • Ein Datenfluss kann (ein oder mehrere) Datenflüsse enthalten. Die Abbildung von Datenflusshierarchien ist somit möglich.
  • Ein Datenfluss kann mehrere Sets umfassen.
  • Beziehungen zwischen den Elementen sind dauerhaft.

Auch wenn diese Regeln auf den ersten Blick höchst kompliziert erscheinen, lösen sich die meisten Verständnisprobleme auf, sobald die ersten OBASHI-Diagramme einmal angefertigt wurden.

OBASHI und die Datenflussregeln

Nicht nur OBASHI folgt klaren Regeln. Auch Datenflüsse unterliegen bestimmten Gesetzen, die bei der Entwicklung von OBASHI-Diagrammen beachtet werden wollen.

  1. Ein Datenfluss kann nur existieren, wenn auch tatsächlich Daten geflossen sind.
  2. An einem Datenfluss sind immer mindestens zwei Elemente beteiligt.
  3. Ein Datenfluss kann weitere Datenflüsse beinhalten.
  4. Wird ein Datenfluss unterbrochen, muss das eine Folge haben.

Diese Punkte sind auf den ersten Blick selbstverständlich und scheinen banal. Tatsächlich bergen sie jedoch Potential. Wenn beispielsweise zwischen zwei Elementen ein Datenfluss definiert wurde, jedoch keinerlei Daten übertragen werden, existiert auch kein Datenfluss.

Und beachten Sie bitte vor allem Punkt 4.: Wenn ein Datenfluss unterbrochen wird, muss daraus eine spürbare Folge resultieren. Bleibt die Unterbrechung folgenlos, schalten Sie den Datenfluss direkt ab. Denn dann ist er für Ihr Unternehmen ohnehin belanglos.

Vorteile der OBASHI-Methode im Überblick

  • Pragmatische Methode zur standardisierten Dokumentation von IT-Services
  • Darstellung von Abhängigkeiten und Beziehungen
  • Unterstützt bei der Ermittlung der Tragweite von Ausfällen und Störungen
  • Visualisierungsmethode zur besseren Kommunikation mit Mitarbeitern und Führungskräften
  • Eindeutige Identifikation der Services die von der IT Abhängig sind
  • Verdeutlicht welche Personen und Abteilungen von den Services abhängig sind
Pattrick Bluhm - Mit-Autor des i-doit Blogs

Der Autor

Pattrick Bluhm ist zertifizierter IT-Projektmanager im Bereich ITSM, CMDB und IT-Dokumentation. Er konzipiert und plant Dokumentationsprojekte und führt sie mit i-doit für mittelständische Unternehmen in der DACH-Region um. Im Jahr 2020 veröffentlichte er sein erstes Buch mit dem Titel "IT-Dokumentation - Projekte erfolgreich umsetzen".