SDP - der Rote Faden durch den Service LifeCycle

Service Design Package – die unbefleckte Perle von ITIL®

Service Management wird in vielen Organisationen immer noch als eine primäre und teilweise sogar ausschliessliche Disziplin für den IT-Betrieb angesehen. Das Framework ITIL hat es nicht geschafft, sich als ganzheitlicher Leitfaden für CIOs zu etablieren – obwohl schon seit 2007 der Service-LifeCycle-Ansatz beginnend mit der Service Strategie und insbesondere auch dem Service Design als die wegweisende und bahnbrechende Betrachtung für Service Provider innerhalb der ITSM-Fangemeinde gilt. Es wird zwar allgemein anerkannt, dass die Service-Betrachtung bei der Bereitstellung von IT-Lösungen insgesamt einen Mehrwert für Kunden darstellt. Das Servicespezifische wird aber ausserhalb der ITSM-Gemeinde eher als verhaltensbezogenen Eigenschaft im Support und in der kundenfreundlichen Reaktion des Service Desk zugeschrieben. Weniger als geplantes und konzipiertes Ergebnis aus der Entwicklungsabteilung.

Das Projekt Management ist per Definition dafür zuständig, dass Anforderungen des Business ermittelt werden und IT-Lösungen in Entwicklungsabteilungen oder vermehrt auch bei externen Partnern realisiert werden. Service Management wird hier nicht als Leitfaden für das Design von IT-Services hinzugezogen. Irgendwann kommt es zur feierlichen Betriebsübergabe, und damit etwas stärkere Berührung mit ITSM, insbesondere mit dem Change Management. Das Release Management gilt vielfach als integrale Aufgabe der Entwicklungsabteilung. Einzig das „Go“ für die Produktion wird vom Betrieb eingeholt. In erster Linie um Kollisionen zu vermeiden – was aber genau geliefert wird und wie bleibt unter Kontrolle der Entwicklung. Die Gewaltentrennung wird oftmals arg strapaziert.

Gut ist, wenn der Betrieb rechtzeitig involviert wurde, damit die Betreibbarkeit nicht erst nach dem Go-Live-Datum festgestellt werden muss. Die fachlichen, respektive Utility-Anforderungen sind in aller Regel gut abgedeckt. Was die Warranty, respektive Nicht-funktionalen Anforderungen anbelangt, ist Gegenstand vom Betrieb, welcher nach der Pilotphase für die Erstellung der SLAs zuständig ist. Doch dann ist es oftmals viel zu spät. Der berühmte Graben zwischen Entwicklung und Betrieb lässt sich so nicht überwinden (Siehe unser Blogbeitrag: Change? oder Projekt? oder was?).

SDP als zentrales Lieferobjekt in der Service Entwicklung
SDP als zentrales Lieferobjekt in der Service Entwicklung

Service Design Package
Dabei sieht das Framework ITIL® eine Reihe von Ansatzpunkten vor, um die Bereiche Business, Entwicklung und Betrieb besser aufeinander abzustimmen. Insbesondere wird die Erstellung eines Service Design Packages, SDP empfohlen, was aber von den meisten mir bekannten Organisationen bis heute jedoch komplett missachtet wird. Dabei ist das SDP genau das Instrument, welches die verschiedenen Service LifeCycle Phasen mit einander verbindet und von der Entwicklung über die Transition bis hin zum Betrieb für die Sicherstellung der Qualität sorgen soll. Das Service Design Package ist sozusagen der rote Faden zwischen den Service Lebensphasen.

SDP - der Rote Faden durch den Service LifeCycle
SDP – der Rote Faden durch den Service LifeCycle

Gemäss ITIL® soll während der Phase Service Design der später einmal zu liefernde Service ganzheitlich definiert werden. Ganzheitlich heisst hier neben der eigentlichen Business-Lösung (Utility) auch alle notwendigen Anpassungen an die Service Management Prozesse, Betriebsfunktionen, Metriken und Messsysteme. Im Service Design Package werden all diese Informationen zusammengestellt:

  • Anforderungen
    o   Businessanforderungen gemäss ursprünglicher Vereinbarung und Dokumentation
    o   Einsatzbereich des Services, welcher definiert, wie und wo der Service genutzt werden kann
    o   Die Business- und Kundenkontakte sowie alle anderen Stakeholder des Services
  • Service Design Spezifikation
      Die funktionalen Anforderungen (Utility) des neuen oder geänderten Service einschliesslich der erwarteten Ergebnisse und gelieferten Resultate
    Service Level Anforderungen (SLRs) mit den gewünschten Warranty Angaben für den Service
    o   Service- und operative Management Anforderungen inklusive aller Angaben bezüglich Steuerung, Betrieb, Monitoring, Messung und Berichtswesen
    o   Service Design und Topologie für die darauf folgende Implementierung im Betrieb. Dazu gehören klare Servicedefinitionen, Servicemodelle und –Optionen, alle notwendigen Infrastrukturkomponenten (Netz, Server, Datenbanken, Storage etc.), Dokumentationen für Anwender, Business, Betrieb und Support sowie die Prozesse, Verfahren, etc.
  • Bewertung der organisatorischen Bereitschaft
    o   Finanzielle Beurteilung
    o   Technische Einschätzung
    o   Geschäftlicher Nutzen
    o   Ressourcenbewertung und organisatorische Bewertung
    o   Kompetenzen und Fähigkeiten der Service Organisation, der involvierten Lieferanten
    o   Situation der vorhandenen Verträge
  • Service Lebenszyklusplan
    o   Ein Serviceprogramm oder Plan mit allen Phasen des Lebenszyklus einschliesslich Phasenabstimmung für die Transition- und Operation-Phase
    o   Service Transitionplan mit allen Build-Richtlinien, Deployment-Vorgaben, Testplänen etc.
    o   Abnahmeplan für die Service Operation
    o   Service Abnahmekriterien für Business, Anwender und Betrieb
SDP Operation Dokumente
SDP Operation Dokumente

Der Anspruch an das Design von Services wird damit um einiges grösser – bringt aber auf der anderen Seite auch enorme Vorteile:

  • Die Qualität der Services wird verbessert
  • Verbessert und vereinfacht die Entscheidungsfindung
  • Erleichtert die Implementierung von neuen oder geänderten Services
  • Vereinfacht die Ausrichtung der Services auf das Business

    SDP Projekt Dokumente
    SDP Projekt Dokumente
  • Sorgt für wirkungsvollere Serviceleistungserbringung
  • Verbessert die IT Governance
  • Sorgt für ein effektives Service Management
  • Reduziert die Gesamtkosten der Services

Design Coordination
Man kann argumentieren, dass das Projekt für die Lieferung dieser Angaben zuständig ist und der Betrieb bei der Einführung mittels Checkliste alles ab punktiert. Nur ist dies oft reine Theorie. Der Projektleiter ist in seinem Dreieck von Zeit, Ressourcen und Qualität gefangen und muss oft eines der Eckpunkte zu Gunsten der anderen strapazieren. Was oft zurückbleibt ist das vermeintlich am ehesten Verzichtbare.

Service Design Organiation
Service Design Organiation

Gemäss den Best Practice Empfehlungen von ITIL® wäre hierzu ein zentraler Prozess vorgesehen, welcher diese Aspekte zentral koordiniert und sicherstellt: Design Coordination. Damit wird dieser Aspekt nicht den Fähigkeiten und Erfahrungen der einzelnen Projektleiter überlassen.

Man kann diesen Prozess auch als zentrale Qualitäts-Funktion innerhalb der Lösungsentwicklung einrichten. Das Mandat dieser Funktion wäre:

  • Design Coordination Prozess
    Design Coordination Prozess

    Single Point of Contact für alle Koordinationsbelange innerhalb des Service Designs

  • Sicherstellen, dass die Designs konsistent durchgeführt werden
  • Koordination aller Design-Aktivitäten in den Projekten und Changes
  • Steuern der Termine, Ressourcen und allfälligen Konflikte
  • Planung der Ressourcen und Capabilities
  • Erstellen der Service Design Packages basierend auf den Service-Charters und Change Requests

Mit so einer Organisation werden bereits im Design von neuen Lösungen die Voraussetzungen für ein erfolgreiches Deployment und anschliessenden Betrieb der Services geschaffen.

Agilität und ITSM
Heute schreit alles nach Agilität und Flexibilität in der Entwicklung und Bereitstellung von neuen Services. Die klassischen Wasserfall-Projekte haben ausgedient, sagt man. Die auf Abstimmung, Absicherung und Konsens getrimmten IT-Organisationen werden seitens Business als zu bürokratisch und zeitraubend angesehen. Agility, SCRUM und DevOps sind die Schlagwörter der Zeit, welche einiges an Dynamik versprechen. Nur nützen diese Methoden insgesamt wenig, wenn zwar im Sprint entwickelt wurde, aber im Rest der Wertschöpfungskette weiterhin Blockaden und Verschwendung stattfindet: Verzögerungen im Genehmigungsverfahren, zu späte Involvierung der Anwender und des Betriebs, Bedürfnisse nicht wirklich validiert, das Testing erst nach der Entwicklung involviert etc.)

Agilität und Service Management ergänzen sich gut, wenn die Philosophie in der ganzen Organisation angewendet wird. Meine Kollegen, Ben Martin und Alex Lichtenberger haben dies in einem ihrer letzten Blogs anschaulich dargelegt (DevOps, Agile Development, Continuous Delivery und ITIL: Was gibt es für Zusammenhänge und wie man sie nutzen kann, und What IT Service Management can learn from the Agile Manifesto (and vice versa)).

SDP - die umbeflekte Perle im ITSM
SDP – die umbeflekte Perle im ITSM

Gerade hier ist eine zentrale Funktion „Design Coordination“ von grossem Nutzen. Mit dieser Aufgabe betraut, stellt sie die Abstimmung mit dem Business sicher – koordiniert die Ressourcen und gilt als eigentlicher Taktgeber der Service Portfolio-Umsetzung. Das Service Design Package ist vielfach noch eine unbefleckte Perle in der IT Organisation, welche darauf wartet, entdeckt zu werden.


 

 

Kommentar verfassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert