Adam Kapon, IT Leiter bei Mocca Sukero, und Max Admin, Projektleiter für das CMDB Projekt, sitzen nun schon einige Stunden zusammen. Sie wollen eine Methode zum “Top Down Analysieren” ihres IT Verbundes erarbeiten. Was recht geschwollen klingt, hat einen einfachen Grund: Eine Notfalldokumentation für die wichtigsten Systeme und Services des Unternehmens ist zu erstellen. Aber wie? Da gibt es schon ein wenig Denkarbeit zu leisten, wie sich schnell zeigt …

Notwendig wurde das Erarbeiten einer eigenen Methode erst durch ein kleines Scheitern. Im CMDB-Pilotprojekt haben zwar alle Beteiligten festgestellt, dass das Zusammentragen und Speichern von Detaildaten zu allen IT-Geräten gut und einfach möglich ist. Aber mit jedem Detail, um das sie die i-doit Datenbank angereichert hatten, entfernte sich auch eines der wichtigsten Ziele. Die Doku soll im Notfall schnell helfen. Man braucht also einen Gesamtüberblick, ein “Big Picture”. Oder in Fachsprache: Der IT Verbund muss dokumentiert sein. Details verstellen hier schnell den Blick und schlimmer noch: wenn sich alle Projektbeteiligten mit den Details beschäftigen, sind auch alle Energien im Projekt gebunden und das Ziel wird nie erreicht.

Was braucht man im Notfall?

Eine Dokumentation für den Notfall, so erkennen die beiden Diskussionspartner, besteht in erster Linie aus einem Überblick wie die Dinge zusammenhängen und welche Services und Systeme mindestens zur Verfügung stehen müssen. Erst später kommen dann Details, so ist man sich einig, die natürlich auch wichtig werden. Sie sehen das Ziel so: Die wichtigsten Geschäftsprozesse müssen weiterlaufen. Beispielsweise soll kein Kunde weggeschickt werden, weil keine Rechnung gedruckt werden kann. Da sind Provisorien und Notlösungen durchaus erlaubt. Zuerst die Pflicht, dann die Kür.

Doch diesen Gesamtüberblick hat derzeit niemand. Oder wie Adam Kapon es ausdrückt: “Natürlich hat ihn “jemand”. Nämlich Alle. Alle aktuellen und ehemaligen Mitarbeiter der IT Abteilung, alle jemals beschäftigten externen Dienstleister, ja teilweise die Kollegen in den Fachabteilungen. Sie und wir alle zusammen haben Fragmente in unseren Köpfen, in den persönlichen Aufzeichnungen und in den vielen Tabellen und Dokumenten, die angefertigt wurden. Möglicherweise sind diese sogar aktuell, wir wissen es nicht und wir können die Aktualität auch nicht abfragen. Im Extremfall kommen wir alle zusammen und lösen gemeinsam alle Probleme? Wie schön! Dieser weihrauchgetränkte Traum der wundersamen IT-Heilung wird wohl nicht wahr werden. Wir müssen der Realität ins Auge sehen. Wenn das Wissen über Zusammenhänge nur bei jemand Einzelnen liegt, der womöglich nicht verfügbar ist, müssen Andere diese Informationen durch aufwändiges Nachvollziehen erarbeiten. Im Notfall kostet das wertvolle Zeit.”

Welches Szenario malen wir uns aus?

Daher denken sich die beiden einmal in die andere Richtung und stellen stellen sich ein Worst-Case-Szenario vor:

Es ist niemand ihrer Kollegen erreichbar, einzig ein IT-kundiger Dienstleister hat die Aufgabe übernommen, einen Notbetrieb anhand der verfügbaren Dokumentation, die ihm von einem Prokuristen zur Verfügung gestellt wurde, aufzubauen. Den Betrieb führt der Dienstleister so lange weiter, bis das Betriebsteam zumindest in Teilen wieder verfügbar ist. Dann wird geordnet übergeben.

Auch das ein Extrem. Aber immerhin realistischer als das IT-Wunder. Es entspricht in gewisser Weise auch der täglichen Praxis: Schließlich ist nicht jeder in ihrem Team ein Vollprofi in allen Belangen. Wenn Anton Portas, der neue Admin, alleine Dienst hat, entspricht das nahezu diesem Szenario. Im Laufe der Zeit haben sich die Administratoren immer mehr zu Spezialisten entwickelt. Immer weniger Generalisten gibt es, schon aufgrund der enormen Bandbreite an technischen Funktionen, die es zu beherrschen gilt.

Eine schrittweise Anleitung für das korrekte Rücksichern der Kundendatenbank gibt also dem neuen Kollegen und selbst alten Hasen wie dem Netzwerk-Admin Sicherheit. Und darum geht’s: In einer extrem angespannten Situation mit Sicherheit zu einem definierten Ergebnis zu kommen. Im Sinne ihres Arbeitgebers: Das Geschäft läuft weiter. Das ist der Job.

Was ist nun zu tun?

Sie sehen die Aufgaben nun ein wenig klarer: Eine Dokumentation zu erstellen, die dem Anspruch gerecht wird von einem “fachkundigen Experten” gelesen und umgesetzt werden zu können, auch wenn er nicht direkt mit dem Tagesbetrieb zu tun hat. Und dafür muss eine standardisierte Methode her um ihre Systeme und IT Services zu analysieren. Diese soll immer gleich angewandt werden. Erst dann kommen vergleichbare Ergebnisse heraus.

Zuletzt hatten Max und Adam definiert, dass sie mit der Analyse des CRM Systems beginnen werden. Schritt für Schritt erarbeiten sie nun ihre Sicht auf die Dinge. Vorerst auf dem Papier.

Zwei Bilder vom Gleichen sind nicht das Selbe!

Adam Kapon zeichnet seine Sicht auf das CRM-System auf. Sein Bild sieht wie folgt aus:

Dokumentieren des CRM Systems 02

Sein Wissen über technische Zusammenhänge ist so ähnlich wie die seiner Abteilungsleiter-KollegInnen. Passt ja auch, denkt sich Max. Adam ist ja schließlich IT-Leiter. Adam denkt und spricht in Geschäftsprozessen. Aus Prozess-Sicht ist das CRM-Service, ebenso wie das ERP-Service, Telefonie und e-Mail jeweils ein Kästchen, oder eben ein Service, das einwandfrei funktionieren muss, sonst leidet der Prozess. Viel tiefer geht Adam auch gedanklich nicht in die Modellierung.

Er begründet das so: “Ich nehme an, dass dieser Detailgrad für den Anfang ausreicht. Wenn wir ein Gesamtverzeichnis aller IT-Services haben, ist das bereits die halbe Miete. Im Sinne unserer Annahme, dass im Notfall externe Dienstleister einspringen werden, müssen wir nur einen oder mehrere Dienstleister finden, die weitere Details erheben, um ihre Aufgabe wahrnehmen zu können. Dann notieren wir noch zu jedem Service die erhobenen Details, die Zuständigkeiten und interne Verantwortung. Das wird für den Notfall genügen.

Eine Beziehung der Geschäftsprozesse zu den Services ist zusätzlich Gold wert. Wie siehst du das, Max? Was benötigen wir noch?”.

“Ich glaube wir müssen noch Einiges besprechen” meint Max kopfschüttelnd. “Willst du die Dokumentation unseres IT-Verbundes tatsächlich outsourcen? Sollte das nicht eine unserer Kernkompetenzen sein?”. Sein Bild sieht in der Tat ganz anders aus:

Dokumentieren des CRM Systems 03

Max konzentrierte sich beim Erstellen seines Bildes auf die technischen Zusammenhänge rund um das CRM-System. Was ihm zur Funktionsweise ad hoc einfiel zeichnete er sofort ein. Dort wo er unsicher ist, wird er noch beim jeweiligen Spezialisten nachfragen. Sein Ansatz ist: Wir machen das nicht nur für den Notfall, sondern einmal für alle weiteren Anwendungsfälle, die da noch kommen mögen. Hauptaugenmerk legte er auf die Abhängigkeit, die er mit Pfeilen ausdrückt: Das jeweils “obere” Element ist abhängig vom Funktionieren des oder der unteren. Und diese haben wiederum andere Abhängigkeiten.

Der schwer zu fassende Begriff “Service”.

Nicht nur die Service- oder Applikationsebene, auch technische Details kommen natürlich bereits vor: Die Namen der Server hat er im Kopf, daraus ergibt sich eine Art Gruppierung bzw. Unterscheidung der Funktionen. Bekannte Schnittstellen zeichnet er ebenfalls ein. Der Begriff “Service” passt dabei einige Male gut. Oft erkennt er jedoch eher die technische Ausprägung in Form eines “Systems”. Vielleicht löst sich das noch auf? Vielleicht ist die formale Unterscheidung ja auch komplett egal? Jedenfalls ein Punkt, der noch diskutiert werden muss.

Er identifiziert drei wesentliche Funktionen des CRM Systems:

  • Die Datenbank, die auf einem dedizierten Datenbankserver läuft. Dieser wird auch von anderen Applikationen als DB-Server genutzt. Dieses Bereitstellen der Datenbank oder des Datenbanksystems klingt bereits stark nach einem Service, der mehrere Applikationen bedient. Da sie ja in Services denken und modellieren wollen, zeichnet er einen Technischen Service CRM-DB.
Dokumentieren des CRM Systems 04
Dokumentieren des CRM Systems 05
  • Es existiert ein Webserver, der für die Präsentation der Webanwendung für die Anwender verantwortlich ist. Der Webserver ist exklusiv für die CRM-Anwendung als virtuelles System aufgebaut worden. Auch hier verwendet Max eine Service-Entsprechung, die er CRM-WEB (Service) nennt.
  • Ebenso exklusiv ist der virtuelle Application-Server der eigentlichen CRM Applikation gewidmet. Diesen Funktionsbereich bzw. den technischen Service nennt er CRM-APP. Alle Schnittstellen sind mit diesem Server verbunden und alle Kernfunktionen des Systems, automatische Scripts, etc. laufen auf diesem Server bzw. machen eben diesen Service aus. Hier wird es später sicher spannend ins Detail zu gehen und die Konfigurationen festzustellen, die das Funktionieren überhaupt erst ermöglichen.
Dokumentieren des CRM Systems 06
Dokumentieren des CRM Systems 07

Darüber zeichnet er einen Sammel-Begriff: CRM-core. Hier ist sich Max nicht sicher. Ist das ein Service? Er meint damit die Kernfunktionen des CRM-Systems, ohne die eigentlich kein CRM Betrieb als komplett wahr genommen werden würde. Weder auf den Web-, noch auf den Application Teil kann verzichtet werden, und ein Betrieb ohne Datenbank ist gänzlich undenkbar. Er versucht es damit, den CRM-core Teil ebenfalls als Technischen Service zu bezeichnen.

Auf der obersten Ebene muss es wohl so etwas wie einen “Sammelbegriff” geben. Hier zeichnet er einfach CRM ein. Vielleicht wird es später als CRM-Service benannt, vielleicht bekommt es ein spezielles Attribut wie “Application Service” oder “Business Service”, oder so ähnlich. Vorerst dient es als Container für alles andere, das darunter passiert oder passieren muss. Und es dient als Objekt in i-doit, so ist sich Max sicher, das andere Eigenschaften hat, als die darunter liegenden Objekte. Beispielsweise liegt die Verantwortung für den gesamten CRM-Service nämlich gar nicht in der IT, hier ist der Vertriebsleiter zuständig. Beim Datenbank-Service sieht das ganz anders aus: Betrieb, Bereitstellung, Service, Wartung, Reparatur, laufende Optimierung, Backup, Restore, Update und Verbesserung, das ist Aufgabe der IT.

Dokumentieren des CRM Systems 08

Wie ist das mit den Schnittstellen?

Max hat noch weitere Services bei seiner Schnellanalyse identifiziert, die zwar dazu gehören, aber nicht zu den Kernfunktionen gezählt werden können:

Dokumentieren des CRM Systems 09

Einerseits die Mail-Schnittstelle bzw. die Funktion des automatisierten Mailversands aus dem CRM-System. Diese wird vom CRM Application-Server ausgelöst. Für einen erfolgreichen Versand von e-Mails wird jedoch weit mehr benötigt: Ein Mail-Relay Service, offene Ports in der Firewall, ein eigener System-Account unter dem die Services laufen. Auf diese Funktion, so nimmt Max an, kann im Notfall verzichtet werden. Daher zeichnet er dieses Service auch getrennt von der Kernfunktion ein. Ein automatisiertes e-Mail kann nötigenfalls später nochmals gesandt werden. Er nennt diesen Service CRM-mailing (-Service).

Ebenso finden Datenabgleiche zwischen CRM und ERP Daten statt. Diese sind zwar für den laufenden Standardbetrieb wichtig, im Notfall kann darauf vorübergehend verzichtet werden. Er nennt den Service, der auch aus viel mehr besteht, als allgemein angenommen, CRM-ERP-Sync. Max weiß, dass hier ein externer Dienstleister mit der Programmierung der Schnittstelle beschäftigt wurde. Da muss es also auch Wartungsverträge oder zumindest Kontaktpersonen geben, die er in der CMDB dokumentieren will.

Dokumentieren des CRM Systems 10
Dokumentieren des CRM Systems 11

Komplettiert wird das Bild von den Abhängigkeiten von weiteren IT-Services.

  • Zum einen ist da natürlich das Server-Netzwerk  und die Core-Switches. Max nennt den technischen Service Core-LAN, er meint damit die Hochgeschwindigkeits-Netzwerkzone im Rechenzentrum. Ohne diesen Netzwerk-Service ist kein weiterer seiner bereits eingezeichneten CRM-Services lauffähig. Unsicher ist er sich noch, ob er die Abhängigkeit korrekt gezeichnet hat, vielleicht ist es einfacher, die Abhängigkeit weiter oben abzubilden. Er wird einfach mehrere Varianten ausprobieren, eine Relation ist schnell gezeichnet und auch schnell in i-doit abgebildet.
    • Ebenso modelliert er, obwohl nicht Aufgabe dieser Session, gleich ein wenig weiter, damit er es nicht vergisst: Ein Core-LAN ohne DNS-Service ist so gut wie undenkbar. Er kann sich gut erinnern, dass der Aufbau und vor allem der Betrieb dieses Services so manches Kopfzerbrechen gebracht hat.

Auch benötigt man eine verbindliche Zeitquelle, den NTP-Service, zur Synchronisation aller Systeme. Ohne, wird es in Zeiten von Schaltsekunden, Schaltjahren, Sommerzeit und Verzeichnisdiensten extrem mühsam.

An dieser Stelle möchte er auch gleich auf spezielle Services verweisen, die nichttechnischer Natur sind. Die Verwaltung der IP-Adressräume, das korrekte Routing, den Netzplan, all das verwaltet sein Kollege David Sendo. Er führt das ebenfalls als Service aus und nennt es schlicht IPAM-Service. Später wird er die Begrifflichkeit noch mit dem Zuständigen besprechen.

Dokumentieren des CRM Systems 12
Dokumentieren des CRM Systems 13

Weiter oben in seiner Zeichnung hat er die Abhängigkeit des CRM-Core-Services von zwei weiteren technischen Services abgebildet:

  • Einerseits benötigen die Anwender Zugriff zum Webserver. Dazu gibt es das, was er vereinfacht User-LAN nennt. Auch das wird Max mit dem Netzwerkadmin noch klären, denn: Es gibt ja, so weiß er, nicht nur ein User-LAN sondern für jede der 15 Außenstellen ein eigenes.

    • Als Teilmenge dieses Services merkt sich Max den DHCP-Service vor. Er ist sich jedoch nicht sicher, ob sein Kollege ausschließlich Clients mit automatisch vergebenen IP-Adressen beschickt, oder auch Server und andere IP-Geräte. Demnach wird vielleicht noch die Abhängigkeit ähnlich dem DNS-Service gezeichnet.
  • Wenn die Anwender die Eingabemaske des CRM-Login-Screens sehen, können sie sich nun einloggen, allerdings nur, wenn es einen entsprechenden User im System gibt. Das CRM-System nutzt zur Userverwaltung und Authentifizierung das zentrale Directory, dass Max folglich als LDAP-Service bezeichnet. Auch bei diesem Service ist sich Max gewahr, dass es mehr als ein rein technisches Service ist. Die Organisation, Verwaltung, Sicherung und laufende Verbesserung ist zweifelsohne ein toller Service, der von der IT Abteilung bereitgestellt wird.
Dokumentieren des CRM Systems 14

Was für Max nun noch unklar ist: Sollen zukünftig auch die Geschäftsprozesse in die CMDB als eigenes Objekt aufgenommen werden? Ist es sinnvoll, sie mit dem jeweiligen Service zu verbinden? Wann braucht man das? Wer braucht das?

Conclusio

Max hat einiges an Definitionsarbeit vor sich. Wenn er alles in seinem Kopf herumträgt, wird das wohl sein sehr persönliches Projekt bleiben. Niemand kann seine Gedanken und Gespräche nachvollziehen, wenn er sie nicht nachvollziehbar dokumentiert. Er muss also eine Art Handbuch herausgeben, in dem er definiert wie und was dokumentiert werden soll.

Einige Punkte die er sich auf jeden Fall ansehen sollte:

  • Eine Definition, ob, wann und wie die identifizierten Services unterschieden werden. Hier gibt es kein Richtig oder Falsch. Man muss die Begriffe für die eigene unternehmensspezifische Sicht definieren.

Die Kandidaten sind:

    • Business Service
    • Application Service
    • Middleware/Database Service
    • Technischer Service
    • Infrastrukturservice
    • Nichttechnischer Service
  • Eine Definition wie die Elemente in der CMDB zu benennen sind.
  • Eine Abstimmung mit dem Netzwerk-Admin über die Netzwerk-Services, hier ist definitiv nicht Max’ Fachbereich.
  • Eine testweise Modellierung in i-doit, um herauszufinden, ob die Bilder in der Software auch abbildbar sind.

Sehen wir zu, wie er das gelöst bekommt …

 

Sie haben Fragen? Anregungen? Oder möchten Ihre Erfahrungen mit uns teilen? Wir freuen uns auf Ihr Feedback via E-Mail, Facebook oder Twitter. (Die Social Media Bar finden Sie auf der linken Seite dieses Beitrags).

Wer hier schreibt:
Peter Resch-Edermayr arbeitet seit nahezu 20 Jahren als Berater an der 
Ausgestaltung von IT-Prozessen. Seit 2014 ist er als Evangelist für i-doit tätig. Situationen aus seinen Projekten verarbeitet er hier zu BLOG-EpisodenDie handelnden Personen sind daher auch nicht ganz frei erfunden, ihre Namen schon. Er begrüßt es, wenn Sie sich mit ihm über Xing oder Twitter vernetzen und austauschen.

Share This