0

Wie ich IT-Services definiere (und welche 4 Grundsätze mir dabei helfen)

Du weißt inzwischen was IT und Fisch miteinander gemeinsam haben. Du hast gelesen, was geschäftsfokussierte IT-Dienste sind, warum ich dieses Konzept so schätze und  welche fünf Vorteile Du und Deine Kunden dadurch haben. Wir haben dabei auch über den Servicekatalog und das interessante Thema Verrechnung gesprochen.

Die Frage, die Du Dir vielleicht schon stellst: Wie soll das in der Praxis funktionieren. Heute möchte ich Dir zeigen, wie ich in meinen Projekten Services definiere. Die Basis sind natürlich die bereits besprochenen Ideen und theoretischen Grundlagen.

Du möchtest den Artikel als Podcast hören? Klicke hier!

 

 

Alles andere erreichst Du durch fleißiges Arbeiten und wenn Du Dich an folgende vier Grundsätze hältst:

Der Servicebaum

Bevor ich Dir die vier Grundsätze im Detail erläutere, möchte ich mit Dir über den Servicebaum sprechen. Der Servicebaum ist die Grundlage für viele Einsatzmöglichkeiten bzw. Nutzen des Konzeptes. Im Prinzip ist es ein umgekehrter Baum, dessen Wurzel oben ist. Die Wurzel ist der geschäftsfokussierte IT-Dienst, also die Verbindung der IT zum Geschäftsprozess. Die Zweige und Äste sind dann die Applikationen, Systeme und die IT-Infrastruktur. Je weiter nach unten Du kommst, umso technischer wird es und umso wohler fühlen sich die meisten IT-Mitarbeiter.

Im Prinzip arbeite ich schon seit vielen Jahren nach dieser Methode. Ausgehend von den Geschäftsprozessen eines Unternehmens, baue ich den Servicebaum auf, indem ich die Abhängigkeiten dokumentiere. Auch hier ist die Wiederholung der Schlüssel zur Geschwindigkeit und dem Erfolg. Ich habe in vielen Projekten die Erfahrung gemacht, dass sich die Mitarbeiter damit schwer tun. Während gemeinsam die Modellierung von Diensten gut voran ging, kam es immer wieder zum Stillstand, wenn ich nicht vor Ort war. Meistens lag es daran, dass die Projektmitarbeiter schnell wieder aus der Infrastruktur heraus versuchten, die Dienste zu definieren. Dazu aber gleich mehr.

OBASHI als Hilfsmittel

Ich bin dann vor zirka zwei Jahren durch Zufall auf die Methode OBASHI gestoßen. Beim Surfen im Internet. Das, was ich auf der Webseite sah, fand ich sofort interessant. Ich habe mir dann gleich das APMG-Buch dazu bestellt, welches ich auf einem Flug von Dresden nach Frankfurt und zurück gleich durchgelesen hatte. Es war verblüffend – in großen Teilen fand ich dort das beschrieben, wie ich seit Jahren arbeite. Aber was ist jetzt OBASHI. 

OBASHI ist eine Methode, die bei zwei Aufgaben hilft:

1. Abhängigkeiten zwischen Menschen, Prozessen und der IT zu dokumentieren
2. Den Fluss der Daten durch die IT zu dokumentieren und zu bewerten

Das Wort OBASHI selbst ist ein Akronym. Jeder Buchstabe steht für eine Schicht in dem Modell:

 

Wenn ich das in einem Satz ausdrücken soll, dann lautet der so:

Was hat sich für mich durch diese „Entdeckung“ verändert? Warum erzähle ich Dir das? Ich hatte endlich etwas gefunden, was ich meinen Kunden mit auf den Weg geben konnte, damit sie selbständig ihre Services von oben nach unten modellieren können. Der Aufbau des Servicebaums lässt sich anhand der sechs Buchstaben des Akronyms jederzeit nachvollziehen. Damit ist die Struktur eines jeden Service gleich. Es zieht Transparenz und Nachvollziehbarkeit ein.

Das Akronym OBASHI lässt sich einfach merken und wenn Du dich dran hältst, dann liegt der Teufel nur noch im Detail. Damit sind wir auch schon beim ersten der vier Grundsätze: Beginne mit der Modellierung beim Prozess und baue den Servicebaum von oben nach unten auf.

Wenn Du neugierig bist, wie OBASHI genau funktioniert, dann ist der kostenfreie OBASHI-eMail-Kurs genau das Richtige für Dich!

Beginne beim Prozess

Aus meiner Sicht ist das der wichtigste Rat, den ich Dir geben kann. Beginne soweit wie möglich oben im Servicebaum mit der Modellierung. In vielen Projekten stehe ich am Anfang vor der Befürchtung, dass erstmal ein komplettes Inventar der IT benötigt wird, um den Servicebaum zu modellieren und damit den Service zu definieren. Diese Vorstellung würde mir genauso viel Angst machen, wie meinen Kunden. Das kannst Du sicher nachvollziehen.

Ich kenne keine verlässlichen Zahlen, aber genau aufgrund dieses Vorgehens scheitert ein großer Teil der CMDB Projekte. Denkst Du, dass es jemals möglich sein wird, ein vollständiges Inventar zu haben? Ich glaube nicht. Meinst Du, dass das wichtig ist? Darüber können wir jetzt streiten. Für mich ist immer nur das wichtig, was auch einen Beitrag zum Kerngeschäft des Unternehmens liefert.

Damit Du nicht den Aufwand betreiben darfst, alles zu erfassen, beginne einfach von oben. Starte mit dem Geschäftsprozess. Danach werden die Abhängigkeiten entsprechend des OBASHI-Schichtenmodells dokumentiert. Als Beispiel nehmen wir mal den Prozess Angebot erstellen:

Um ein Angebot zu erstellen, wird die Software SAS-AX und BPM benötigt. Diese benötigen wiederrum zwei verschiedene Datenbanken. SAS-AX und die zugehörige Datenbank DB-SAS laufen auf dem Betriebssystem Windows Server 2008, welches auf den zwei entsprechenden virtuellen Servern installiert ist. BPM und die DB-AX laufen auf Windows Server 2008 R2 auf zwei entsprechenden virtuellen Maschinen. Die virtuelle Serverumgebung wird von insgesamt drei Servern bereitgestellt, die das Servernetzwerk und das Storage angebunden sind.

Von oben kommend, gehst Du jede einzelne Schicht durch und baust automatisch mit der Zeit Dein Inventar auf. Mit jedem neuen Service dokumentierst Du einen weiteren Teil des IT-Equipments. Der Trick liegt dabei in der Tatsache, dass Du Dich auf einen Prozess konzentrierst und nur das dokumentierst, was Du dafür benötigst.

Beginne mit dem Wichtigsten

Das führt mich zu meinem zweiten Grundsatz: beginne mit dem wichtigsten Prozess. Wenn wir etwas Neues beginnen, sind wir häufig genötigt, schnell den Nutzen nachzuweisen. Was aber noch viel wichtiger für Dich ist: Wenn Du schnell Erfolge erzielst, dann bist Du viel motivierter einen steinigen Weg konsequent zu gehen – in diesem Fall Deine Prozesswelt als Services abzubilden.

Daher beginne mit dem wichtigsten Unternehmensprozess. Der hat den meisten Wert für Dein Unternehmen. Das bedeutet, dass jede Störung, jeder schlecht geplante Change oder jeder Sicherheitsvorfall potentiell hohen finanziellen Schaden oder Reputationsverlust bedeutet. Wenn Du aufgrund des entstanden Servicebaums eine Störung schneller beseitigen oder unbekannte Abhängigkeiten aufdecken kannst, dann ist das der schnelle Erfolg, von dem ich gerade sprach. Aber auch wenn Du damit vernünftige SLAs verhandeln kannst, hast Du viel gewonnen. Mit vernünftig meine ich das gleiche Verständnis über die erwartete Verfügbarkeit, Entstörung usw. Dazu empfehle ich Dir die Folge 6 meines Podcasts, dort bin ich detailliert auf die 5 Vorteile geschäftsfokussierter IT-Dienste eingegangen.

In einem aktuellen Projekt modelliere ich mit dem Kunden gerade einen Teil seiner IT-Umgebung. Nachdem wir die ersten drei Services definiert hatten, war es offensichtlich, dass es an einer Stelle einen Single-Point-of-failure gab. Diesen hatte bisher noch niemand identifiziert. Entsprechend strukturierte Servicebäume sorgen für Transparenz.

Wenn Du mit dem wichtigsten Prozess beginnst, erscheint Dir das vielleicht als ebenso schwierig und kompliziert, wie das Aufstellen eines vollständigen IT-Inventars. Das ist richtig. Deswegen gilt es den Prozess in sinnvolle Teilprozesse zu zerlegen und mit diesen zu beginnen. Erinnere Dich bitte an mein Beispiel: „Angebot erstellen“ – das ist ein Teil des Vertriebsprozesses. Dieser umfasst noch viele andere Teilprozesse bzw. Services. Zum Beispiel: Auftragsbestätigung erstellen, Preisanfrage, Lieferschein erstellen usw.

Du darfst dabei darauf achten, die richtige Flughöhe zu finden. Die Aussagekraft eines Service wird geschmälert, wenn er zu viele oder zu wenige IT-Assets enthält. Wobei zu viel schlimmer ist als zu wenig. Zu wenig bedeute vor allem eine zu große Anzahl von Services und damit Unübersichtlichkeit.

Kleine Schritte – sofort Nutzen

Wenn Du Deinen wichtigsten Prozess zerlegst, dann beachte bitte meinen dritten Grundsatz: Gehe iterativ vor – wähle kleine Ziele und schaffe schnell Nutzen. In meinem Beispiel vom Vertriebsprozess nimmst Du Dir jeden einzelnen Teilprozess als einzelnen Service vor. Erst wenn Du mit Angebot erstellen fertig bist, kommt die Preisanfrage dran. Das ist für Dich wichtig. Kleine Aufgaben sind schnell fertig und bringen so nach kurzer Zeit einen Nutzen.

Ich erlebe es immer wieder das Gefühl etwas fertig zu haben, ist toll. Es motiviert mich weiterzumachen. Das kennst Du bestimmt auch. Endlich fertig und nicht die ewig langen Projekte, bei denen erst nach Monaten oder Jahren die Ernte eingefahren werden kann. Da ich sehr viel auch mit agilen Artefakten und Methoden arbeite, bin ich da glaub ich auch etwas geprägt. Bei Kanban gibt es den Spruch: „Stop starting, start finishing“ und da ist viel dran.

Dazu vielleicht mal in einem späteren Podcast mehr. Ein einzelner Service und dann der nächste, hat für Dich einen weiteren entscheidenden Vorteil: Du lernst jedes Mal dazu. Du kannst die Methode, wie Du Deine Services modellierst verfeinern, verändern oder ganz umstellen. Das ist mein vierter Grundsatz: Verfeinere Deine Modellierungsidee mit jedem Service und trau Dich etwas wegzuwerfen.

Ständige Verbesserung

Am Anfang steht trotz des Hilfsmittels OBASHI die Frage, wie möchtest Du Deine Services modellieren. Du solltest Dich in einigen Punkten nicht zu sehr auf die Methode versteifen, sondern gucken, was Du brauchst. Bei mir ist es beispielsweise so, dass ich häufig die Schicht System, also das Betriebssystem weglasse. Es bringt mir nur dann einen Wert, wenn ich neben der Servicemodellierung auch gleichzeitig eine detaillierte Datenflussanalyse ermöglichen möchte. Dann darfst Du Dir auch überlegen, wie Redundanz, Virtualisierung und viele andere Dinge dargestellt werden sollen. Die Frage der Abstraktion stellt sich ebenso in fast jedem Projekt. Das heißt, möchtest Du jeden einzelnen Switch im Servicebaum sehen, oder reicht eine Netzwerkwolke.

Ich starte die Arbeit immer mit einer Mischung aus den Anforderungen der Kunden und dem Gefühl, basierend auf meiner Erfahrung, was gut für den Kunden ist. Das sind Annahmen. Diese Annahmen darfst Du verifizieren. Spätesten nach dem dritten Service merkst Du, ob die Annahmen ergänzt oder verändert werden müssen. Das ist gut! Damit entwickelst Du nämlich genau die Art der Modellierung, die für Dich passend ist. Und bitte wundere Dich nicht, wenn Du die ersten drei Services dann nochmal modellieren musst. Das kommt gar nicht so selten vor.

Genau aus diesem Grund zeichne ich die Strukturen zuerst auf dem Flipchart oder Whiteboard, bevor ich sie in Software giese. Da bin ich viel schneller mit Änderungen und wegwerfen. Das kann ich Dir als Tipp mitgeben. Das hat für Dich auch noch einen zweiten Vorteil – auf den komm ich gleich zu sprechen.

Vorher möchte ich die vier Grundsätze zusammenfassen. Wenn Du geschäftsfokussierte IT-Dienste modellieren möchtest, dann empfehle ich Dir:

1. Beginne mit der Modellierung beim Prozess und baue den Servicebaum von oben nach unten auf
2. Starte mit dem wichtigsten Prozess.
3. Gehe iterativ vor – wähle kleine Ziele und schaffe schnell Nutzen
4. Verfeinere Deine Modellierungsidee mit jedem Service und trau Dich etwas wegzuwerfen.

Ich hoffe, die helfen Dir genauso wie mir.

Nutze das Flipchart!

Zum Abschluss möchte ich noch auf ein Problem eingehen: Welche Prozess hat mein Unternehmen überhaupt? Damit bin ich immer wieder im Vorfeld von Projekten konfrontiert. Eines ist klar, geschäftsfokussierte IT-Dienste definierst Du nicht ohne mit den Prozessverantwortlich oder Nutzern gesprochen zu haben. Selbst wenn Dein Unternehmen eine aktuelle Prozessdokumentation hat, wirst Du viel kommunizieren dürfen.

Genau da liegt der zweite Vorteil des Flipcharts. Visualisierung ist ein ganz mächtiges Werkzeug. Viel Wissen versteckt sich in den Köpfen der Menschen. Wenn Du beginnst die Abhängigkeiten zwischen Menschen, Prozessen und IT aufzumalen, werden das Deine Gesprächspartner verarbeiten und Dir immer mehr Informationen geben. Das Dümmste was Du jetzt machen kannst, ist diesen Denkprozess mit den Worten „Warte mal, das muss ich erstmal ins Programm eingeben“ zu unterbrechen. Am Flipchart oder Whiteboard bist Du sehr schnell mit aufschreiben, zeichnen, durchstreichen, hinzufügen und auch wegwerfen. Das ist genau das richtige Werkzeug für diesen Prozessschritt.

Wie kannst Du bei fehlender oder unzureichender Dokumentation ermitteln, welche Prozess und Prozessschritte es gibt. Ich nutze dazu Techniken aus der Disziplin der Business Analyse. Das BABoK ist der Business Analyse Body of Knowledge – also das Standardwerk, in dem die Business Analyse, der Prozess und die Methoden beschrieben sind. Dort findet sich auch eine Definition: „Business Analyse ist die Summe der Aufgaben und Methoden, die eingesetzt werden, um zwischen unterschiedlichen Stakeholdern zu vermitteln mit dem Ziel, die Strukturen, Grundsätze und Abläufe eines Unternehmens zu verstehen …“

Das sind ganz verschiedene Techniken wie Brainstormig, Dokumentenanalyse, Interviews, Shadowing oder Structured WalkThrough. Je nachdem, welche Ausgangssituation vorliegt, kannst Du die verschiedenen Techniken anwenden. Die am 15. April erscheinende dritte Version des BABoK kennt 46 verschiedene Techniken.

Für die Definition von geschäftsfokussierten IT-Diensten sind die Fähigkeiten eines Business-Analysten von großer Bedeutung. Deswegen freue ich mich besonders, dass ich in der nächsten Folge mit Ingrid und Peter Gerstbach über Business Analyse spreche. Du darfst Dich auf ein spannendes und heiteres Interview freuen.

Wenn Du Fragen zur Definition und Modellierung geschäftsfokussierter IT-Dienste hast, denn schreibe mir eine eMail an robert@different-thinking.de