Max Admin hat nicht locker gelassen. Bei seiner letzten Session mit IT Leiter Kapon, haben sie gemeinsam versucht das CRM-System, “Top Down” zu analysieren. Soll heißen: Nicht die technischen Details in den Vordergrund zu rücken, sondern eben mal von oben drauf zu blicken und sich nur die wichtigsten Eigenschaften, Funktionen und Services anzusehen. Ein Thema das offen blieb: ob und wie sie mit den Geschäftsprozessen von Mocca Sukero umgehen sollen. Mit dieser Frage im Bauch hat Max weiter recherchiert. Er konnte nicht glauben, dass er alles selbst erfinden muss. Und siehe da: Er stieß auf eine Methode, die sich mit dem Schnittpunkt von IT und Business auseinandersetzt: OBASHI.

“Schon wieder etwas Japanisches?” fragt Adam Kapon. Max lächelt: “No Sir! Very british”.

OBASHI bedeutet: O – Ownership, B – Business Process, A = Application, S = System, H = Hardware, I = Infrastructure. Es ist ein 6-Ebenen Modell, um Zusammenhänge in der IT zu analysieren und zu dokumentieren. Also ziemlich genau das, was wir benötigen, um unseren bestehenden IT-Verbund standardisiert zu dokumentieren. Und das Beste dabei ist: Wir müssen es nicht erfinden! Das Rad ist schon da und anscheinend recht rund!”.

“Gefunden habe ich die Methode im deutschsprachigen BLOG von Robert Sieber. Er ist IT-Berater aus Dresden. Wenn es um IT-Service-Management geht sind seine Artikel top: Pragmatisch, praktisch, gut. In seinem BLOG und Podcast habe ich bereits viel Input für unser Vorhaben gefunden. Meine Frau wundert sich schon, dass ich Tag und Nacht Kopfhörer trage. Die OBASHI Methode erscheint mir vor allem in Hinblick auf das Thema Notfallplan gut geeignet.”

Doch Adam Kapon ist nicht so leicht zu begeistern: “Alle sechs Ebenen willst du in einer CMDB abbilden? Geht das überhaupt? Es kommt mir ein wenig schräg vor, ein Verzeichnis von Geschäftsprozessen in unserem Dokumentationswerkzeug zu führen. Ja, das “Big Picture”, so fühle ich instinktiv, verlangt danach. Eine IT, die nicht unser Geschäft unterstützt, hat ja keinen Sinn. Natürlich ist es logisch und wünschenswert, diesen Zusammenhang irgendwie kenntlich zu machen. Aber muss das in der IT-Dokumentation passieren? Ist das nicht bereits Architekturmanagement? Oder Geschäftsprozessmanagement? Bist du da nicht auf dem Holzweg? Überfordern wir da nicht unsere Kolleginnen und Kollegen? Kann denn i-doit das überhaupt?”.

“Ich bin mitten in einem OBASHI-Kurs, der übrigens kostenfrei angeboten wird, so Max. “Bald werde ich eine Antwort darauf haben. Es geht eigentlich noch gar nicht um das Befüllen der CMDB. Zuerst geht es mal darum, die Zusammenhänge zu erkennen und ‘auf Papier’ zu bringen. Erst wenn das geschafft ist, reden wir über Tools. Doch lass’ mich dir bitte erklären, warum mir diese Analysemethode so gut gefällt: Denn: wir können anscheinend mehrere Fliegen mit einer Klappe erschlagen:

  • “Eine deiner Anforderungen an die CMDB ist es, die Verantwortlichkeiten zu klären und zu dokumentieren. Das wird bei OBASHI insofern berücksichtigt, als das Thema ‚Ownership‘ ganz oben steht. Zuletzt, als wir uns mit dem Beispiel CRM beschäftigten, sind wir ja schon drauf gekommen, dass das CRM-System eigentlich nicht der IT “gehört”, sondern dem Vertriebsleiter Philipp Prezo. Das mag vielleicht stimmen. Ich schätze jedoch, es ist ihm ziemlich egal. Viel wichtiger ist wahrscheinlich: Die Geschäftsprozesse, die ohne CRM-System nicht funktionieren würden, “gehören” dem Vertriebsleiter. Also alles, was mit Verkauf zu tun hat. Er ist für das Funktionieren der Prozesse verantwortlich. Zu ihm müssen wir auch gehen, wenn es größere Umbauten oder Ausfälle in diesen IT-Systemen gibt.

Max hat sich warm geredet …

  • “Eine weitere Anforderung, die ich von dir gehört habe: Du willst einen Servicekatalog. Zuerst dachte ich, dass das so ziemlich das Letzte ist, das wir umsetzen werden und gar nichts mit dem CMDB-Projekt zu tun hat. Seit ich OBASHI kenne denke ich anders: Alleine die drei Ebenen O, B und A zu kennen und dokumentiert zu haben, ist ja quasi schon der größte Teil des Servicekatalogs. Falls ich das alles richtig verstanden habe”, fügt er noch schnell hinzu. Ganz geheuer sind dem langjährigen IT-Administrator die neuen Erkenntnisse nicht.

    “Wenn wir dann auch noch die Infrastruktur bzw. Services dokumentieren,” setzt er fort, “ist das wahrscheinlich ein echter Mehrwert für uns als IT Abteilung. Wir können darstellen, wie die Services zusammenhängen, was wir leisten, wie wir es leisten und wissen zum ersten Mal wofür wir es eigentlich tun. Höchstwahrscheinlich stoßen wir auf eine Menge Optimierungspotenzial.”

Nun lächelt Kapon: “OK. Das gefällt mir. Dokumentation nicht als Selbstzweck zu sehen, sondern um die Darstellbarkeit unserer Realität in der IT Abteilung zu ermöglichen. Wenn wir diese Informationen, die wir dabei gewinnen, verwenden, um Innovationen voranzutreiben und dabei auch noch den Betrieb optimieren, machen wir einen Superjob. Wir verdichten Daten zu nutzbaren Informationen und generieren daraus Wissen, das Innovation ermöglicht. Nur so weiter, bitte!”

 

  • “Da sind wir beim dritten Punkt. Beim Optimieren unserer IT. Zum Beispiel: Welche Betriebssysteme haben wir denn eigentlich im Haus? Wir wissen es derzeit nicht genau. Ein gutes Dutzend werden es schon sein. Das Problem dabei: Die Vielfalt ist vielleicht für uns Admins persönlich spannend. Öfter mal was Neues. Aber klug ist sie nicht. Sie macht uns angreifbar. Keiner kennt auch nur ein Betriebssystem so gut, dass wir es wirklich gehärtet und damit sicher, nach Stand der Technik, betreiben können. Denk’ nur mal, was das für unseren Online-Shop, unser Internetangebot oder die Kassensysteme bedeutet: Wir wissen nicht mal, was wir haben, geschweige denn, wie es sicher wird. Diese Vielfalt müssen wir reduzieren, also zuerst analysieren, dann dokumentieren und bei passender Gelegenheit auf einen neuen Standard heben.”

“Guter Punkt” nickt Kapon. “So wie du es schilderst, macht mir das auch ein wenig Sorge. Wir werden tatsächlich mehr in Standards denken müssen und uns dort weiterbilden. Das alles riecht immer mehr nach Architekturmanagement”.

  • “Und schließlich ist da noch das Thema mit dem wir noch nicht weitergekommen sind: Der vom Geschäftsführer eingeforderte Notfallplan. Derzeit ist er ja, wie du weißt, verteilt in unseren Köpfen. Ich denke OBASHI wird uns helfen, hier rascher vorwärts zu kommen.”

“Das klingt alles recht durchdacht.” setzt Kapon fort. “Du hast hier anscheinend eine wirklich brauchbare Analysemethode gefunden. Aber wie willst du nun weiter machen? Was bedeutet das für unser CMDB-Projekt? Willst du nun ein paar Monate analysieren, oder können wir bald einmal Erfolge zeigen?

“Zuerst mal werde ich den OBASHI Kurs fertig machen” erklärt Max. Das geht sicher schneller, als sich eine Methode selbst zusammen zu zimmern. Alles Gelernte werde ich versuchen sofort anzuwenden. Robert stellt Vorlagen zur Verfügung, die für den Anfang sicher ausreichend sind. Mal sehen, wie weit wir kommen. 

Max zählt auf: “Für unser CMDB-Projekt bedeutet das:

a) Entweder wir dokumentieren die Zusammenhänge auf Papier, oder
b) erstellen digitale Dokumente, oder
c) führen ein zweites Dokumentationssystem im Haus ein, oder
d) verwenden i-doit.”

Kapon winkt ab: “Ein Dokumentationstool aufzubauen und aktuell zu halten wird schlimm genug. Und das Drama mit den veralteten Dateien sehe ich mir nicht mehr länger an. Punkt für dich. Probieren wir es aus”.

“Ich hoffe schon in den nächsten Wochen unsere wichtigsten Applikationen und Services mit OBASHI dokumentiert zu haben”, setzt Max nach. Dann übertrage ich diese Informationen in i-doit. Ich schlage vor: Dann reden wir wieder ausführlich?”.
Kapon nickt. Er muss wohl auf einen vorzeigbaren Quick Win noch ein wenig warten. Aber im Vergleich zum Start des Pilotprojekts ist bereits viel geschehen auf das er stolz ist. Das Bewusstsein ist geschaffen. Zumindest in Teilen seiner IT-Abteilung. Jetzt muss er sich überlegen, wie er dieses neue Service-Bewusstsein auch in die anderen Köpfe bringt. Er merkt aber auch, dass das Projekt immer größer wird. Alles, was in den letzten Jahren nicht, oder unzulänglich angepackt wurde: Hier liegt es.

Auch er muss sich gut überlegen, wie und wohin er das CMDB-Projekt steuert.

Share This