03810 ITSM in Zeiten von Agilität
|
Störungszeiten reduzieren, Änderungen planen und koordiniert durchführen oder externe Dienstleister zielgerecht einbinden, das für sich genommen sind bereits fordernde Aufgaben, insbesondere in IT-Abteilungen mittlerer und kleiner Unternehmen sowie in der öffentlichen Verwaltung. Themen wie die agile Transition oder der Aufbau von DevOps halten auch hier Einzug und sorgen für zusätzliche Verwirrung. Das betriebliche Umfeld ist dabei häufig geprägt von widersprüchlichen Wünschen seitens der (internen) Kunden sowie besonderen Anforderungen an die Schnelligkeit und die Sicherheit. Der Beitrag liefert mit dem Bezug auf FitSM einen möglichen Lösungsansatz, um den Herausforderungen zu begegnen. von: |
1 Einführung
Warum ITSM?
Geschäftsprozesse in Unternehmen hängen in zunehmendem Maße von einer funktionierenden Informationstechnik ab. Die IT-Abteilungen großer Unternehmen haben dies längst erkannt und bemühen sich, ihre Abläufe an bewährten Prozessen auszurichten und sich im Rahmen von IT Service Management (ITSM) weitgehend zu organisieren. Der Bedarf, beispielsweise Störungszeiten zu reduzieren, Änderungen zu planen und koordiniert durchzuführen oder externe Dienstleister zielgerecht einzubinden, wächst auch in IT-Abteilungen mittlerer und kleiner Unternehmen sowie in der öffentlichen Verwaltung. Diese stehen – genau wie die IT großer Organisationen – vor der Herausforderung, die IT mehr mit Blick auf die Anforderungen der „internen Kunden” zu organisieren und neben dem technischen Sachverstand des eigenen Personals eine verlässliche Organisation und ein geändertes Qualitätsbewusstsein aufzubauen. Auch die aktuellen Veränderungen von Organisationen im Rahmen von agilen Transitionen oder dem Aufbau von DevOps-Teams unterstreichen die Notwendigkeit von ITSM. Die „Betriebsaufgaben” müssen weiterhin strukturiert und organisiert erbracht werden. In diesem Zusammenhang findet also „ITSM in Entwicklungsteams” statt. Erfahrung im IT Service Management kann wertvolles Wissen für die Gestaltung der Teamarbeit einbringen.
Geschäftsprozesse in Unternehmen hängen in zunehmendem Maße von einer funktionierenden Informationstechnik ab. Die IT-Abteilungen großer Unternehmen haben dies längst erkannt und bemühen sich, ihre Abläufe an bewährten Prozessen auszurichten und sich im Rahmen von IT Service Management (ITSM) weitgehend zu organisieren. Der Bedarf, beispielsweise Störungszeiten zu reduzieren, Änderungen zu planen und koordiniert durchzuführen oder externe Dienstleister zielgerecht einzubinden, wächst auch in IT-Abteilungen mittlerer und kleiner Unternehmen sowie in der öffentlichen Verwaltung. Diese stehen – genau wie die IT großer Organisationen – vor der Herausforderung, die IT mehr mit Blick auf die Anforderungen der „internen Kunden” zu organisieren und neben dem technischen Sachverstand des eigenen Personals eine verlässliche Organisation und ein geändertes Qualitätsbewusstsein aufzubauen. Auch die aktuellen Veränderungen von Organisationen im Rahmen von agilen Transitionen oder dem Aufbau von DevOps-Teams unterstreichen die Notwendigkeit von ITSM. Die „Betriebsaufgaben” müssen weiterhin strukturiert und organisiert erbracht werden. In diesem Zusammenhang findet also „ITSM in Entwicklungsteams” statt. Erfahrung im IT Service Management kann wertvolles Wissen für die Gestaltung der Teamarbeit einbringen.
Das ITSM muss sich daher zwei unterschiedlichen Herausforderungen stellen:
| • | Widersprüchliche Anforderungen an die IT seitens eigener Geschäftsprozesse oder auch seitens Kunden (vor allem in Lieferketten) sowie |
| • | Schnelligkeit (d. h. Unterstützung der Agilität) und Sicherheit (d. h. Einhaltung der Governance) gewährleisten. |
Dieser Beitrag liefert mit dem Bezug auf FitSM einen möglichen Lösungsansatz.
1.1 Herausforderung Governance
Informationssicherheit, Datenschutz
IT-Governance war in den letzten Jahren stark geprägt von Informationssicherheit. Die DSGVO schreibt die Umsetzung technischer und organisatorischer Maßnahmen vor, Hersteller prüfen ihre Lieferketten auf Vorgaben der Informationssicherheit und des ITSM, Versicherungen machen Vorgaben für ihre Unternehmenskunden, und Banken beginnen, diesen Aspekt in die Kreditvergabe einfließen zu lassen.
IT-Governance war in den letzten Jahren stark geprägt von Informationssicherheit. Die DSGVO schreibt die Umsetzung technischer und organisatorischer Maßnahmen vor, Hersteller prüfen ihre Lieferketten auf Vorgaben der Informationssicherheit und des ITSM, Versicherungen machen Vorgaben für ihre Unternehmenskunden, und Banken beginnen, diesen Aspekt in die Kreditvergabe einfließen zu lassen.
Drei Rahmenwerke
Zur Ermittlung und Aufrechterhaltung eines adäquaten Sicherheitsniveaus kommen in Deutschland vorrangig drei Rahmenwerke zum Einsatz: ISO/IEC 27001 [1], IT-Grundschutz (BSI) und ISIS12 (IT-Sicherheitscluster). Alle diese Rahmenwerke kommen für sich zu dem Schluss, dass ein angemessenes Sicherheitsniveau ohne ITSM-Prozesse nicht machbar ist.
Zur Ermittlung und Aufrechterhaltung eines adäquaten Sicherheitsniveaus kommen in Deutschland vorrangig drei Rahmenwerke zum Einsatz: ISO/IEC 27001 [1], IT-Grundschutz (BSI) und ISIS12 (IT-Sicherheitscluster). Alle diese Rahmenwerke kommen für sich zu dem Schluss, dass ein angemessenes Sicherheitsniveau ohne ITSM-Prozesse nicht machbar ist.
ISO 27001
Die ISO/IEC 27001 fordert im Annex A die Umsetzung des Maßnahmenziels: „Es ist sichergestellt, dass Informationssicherheit ein fester Bestandteil über den gesamten Lebenszyklus von Informationssystemen ist.” (Maßnahmenziel A.14.1). Für den ganzen Komplex A.14 Anschaffung, Entwicklung und Instandhalten von Systemen wird die Umsetzung von 13 Einzelmaßnahmen gefordert. Darüber hinaus sagt die Maßnahme A.12.1.2: „Änderungen [...] an den informationsverarbeitenden Einrichtungen und an den Systemen werden gesteuert.”. Ohne ein koordiniertes Change Management, das bei Genehmigung, Erstellung, Test und Implementierung von Changes auch die Aspekte der Informationssicherheit berücksichtigt, lässt sich dies kaum umsetzen.
Die ISO/IEC 27001 fordert im Annex A die Umsetzung des Maßnahmenziels: „Es ist sichergestellt, dass Informationssicherheit ein fester Bestandteil über den gesamten Lebenszyklus von Informationssystemen ist.” (Maßnahmenziel A.14.1). Für den ganzen Komplex A.14 Anschaffung, Entwicklung und Instandhalten von Systemen wird die Umsetzung von 13 Einzelmaßnahmen gefordert. Darüber hinaus sagt die Maßnahme A.12.1.2: „Änderungen [...] an den informationsverarbeitenden Einrichtungen und an den Systemen werden gesteuert.”. Ohne ein koordiniertes Change Management, das bei Genehmigung, Erstellung, Test und Implementierung von Changes auch die Aspekte der Informationssicherheit berücksichtigt, lässt sich dies kaum umsetzen.
Auch die Anforderungen an eine konsistente und wirksame Herangehensweise für die Handhabung von Security-Incidents (Maßnahmenziel A.16.1) benötigen den korrespondierenden ITSM-Prozess Incident Management. Weitere Abhängigkeiten sind in der Anforderung Informationssicherheitsaspekte beim Business Continuity Management (Annex A17), bei der Kapazitätssteuerung (Maßnahme A.12.1.2) sowie der Verwaltung der Werte (Annex A.8) zu finden.
Ein Service Level Management wird nicht explizit gefordert, allerdings lässt sich die Anforderung zum Verstehen der Erfordernisse und Erwartungen interessierter Parteien ab einer bestimmten Komplexität nicht mehr sinnvoll ohne ein Service Level Management umsetzen.
IT-Grundschutz
Das BSI hat für das eigene Rahmenwerk IT-Grundschutz bereits vor Jahren eine Ausarbeitung zu den Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und IT Service Management veröffentlicht [2]. Dabei wurden Abhängigkeiten des IT-Grundschutzes von folgenden ITSM-Prozessen identifiziert: Configuration Management, Incident Management, Problem Management, Change Management, Service Level Management, Availability Management, Capacity Management und Continuity Management.
Das BSI hat für das eigene Rahmenwerk IT-Grundschutz bereits vor Jahren eine Ausarbeitung zu den Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und IT Service Management veröffentlicht [2]. Dabei wurden Abhängigkeiten des IT-Grundschutzes von folgenden ITSM-Prozessen identifiziert: Configuration Management, Incident Management, Problem Management, Change Management, Service Level Management, Availability Management, Capacity Management und Continuity Management.
ISIS12
Diese offensichtlichen, aber in der Praxis gerne ignorierten Abhängigkeiten haben den IT-Sicherheitscluster bei der Erstellung des Rahmenwerks ISIS12 dazu veranlasst, ITSM-Prozesse explizit zu verankern. Einer der zwölf für ISIS12 notwendigen Schritte (Schritt 5) fordert die Einführung eines Wartungsprozesses, eines Änderungsprozesses und eines Störungsbeseitigungsprozesses. Ohne die Umsetzung der genannten Prozesse ist eine Zertifizierung nach ISIS12 nicht möglich. Schaut man sich die Prozessbeschreibungen an, wird schnell klar, dass es sich bei den genannten Prozessen um folgende ITSM-Prozesse dreht: Availability Management, Capacity Management, Change Management und Incident Management. Zusätzlich wird in Schritt 4 die Erstellung einer CMDB gefordert.
Diese offensichtlichen, aber in der Praxis gerne ignorierten Abhängigkeiten haben den IT-Sicherheitscluster bei der Erstellung des Rahmenwerks ISIS12 dazu veranlasst, ITSM-Prozesse explizit zu verankern. Einer der zwölf für ISIS12 notwendigen Schritte (Schritt 5) fordert die Einführung eines Wartungsprozesses, eines Änderungsprozesses und eines Störungsbeseitigungsprozesses. Ohne die Umsetzung der genannten Prozesse ist eine Zertifizierung nach ISIS12 nicht möglich. Schaut man sich die Prozessbeschreibungen an, wird schnell klar, dass es sich bei den genannten Prozessen um folgende ITSM-Prozesse dreht: Availability Management, Capacity Management, Change Management und Incident Management. Zusätzlich wird in Schritt 4 die Erstellung einer CMDB gefordert.
In Schritt 6 Kritische Anwendungen identifizieren werden Fachverantwortliche für Anwendungen/Services/Geschäftsprozesse benannt, die anschließend ihre Anforderungen an Vertraulichkeit, Verfügbarkeit und Integrität formulieren sowie den maximal tolerierbaren Datenverlust und die maximal tolerierbare Ausfallzeit definieren. Diese Angaben sind jährlich einer Revision zu unterziehen. Ein vorhandener Service Level Management Prozess kann diese Forderungen umsetzen.
Einheitliche Forderungen der Informationssicherheit
Somit lässt sich festhalten, dass die relevanten Rahmenwerke zur Umsetzung eines adäquaten Sicherheitsniveaus einheitlich die Implementierung folgender ITSM-Prozesse voraussetzen:
Somit lässt sich festhalten, dass die relevanten Rahmenwerke zur Umsetzung eines adäquaten Sicherheitsniveaus einheitlich die Implementierung folgender ITSM-Prozesse voraussetzen:
| • | Configuration Management |
| • | Incident Management |
| • | Change Management |
| • | Availability Management |
| • | Capacity Management |
Zusätzlich bietet sich ab einer gewissen Komplexität die Implementierung eines Service Level Managements an. Das BSI rät darüber hinaus noch zum Problem Management Prozess.
Dass der ITSM-Prozess Information Security Management hier nicht erwähnt wird, liegt daran, dass die Rahmenwerke diesen Prozess bereits auf einem signifikant höheren Niveau umsetzen.
1.2 Herausforderungen in Zeiten von Agilität
Anpassungsfähiger und flexibler werden
Die Herausforderungen für Organisationen in Zeiten von Agilität sind anders als beim Thema Governance. Während es bei Governance wie oben beschrieben klare Vorgaben in Form von Gesetzen, umfangreichen Dokumenten bzw. überprüfbaren Normen gibt, ist die Notwendigkeit für Unternehmen, sich insbesondere in der IT-Organisation aufzustellen, wenig konkret. Es werden daher im Rahmen von Change-Projekten (Agile Transitions- oder Transformationsprojekte) vielfältige Aktivitäten unternommen, um Organisationen neu aufzustellen. Ziel ist, damit die notwendige Anpassungsfähigkeit in Zeiten von disruptiven Markt- und Technologieveränderungen zu gewährleisten.
Die Herausforderungen für Organisationen in Zeiten von Agilität sind anders als beim Thema Governance. Während es bei Governance wie oben beschrieben klare Vorgaben in Form von Gesetzen, umfangreichen Dokumenten bzw. überprüfbaren Normen gibt, ist die Notwendigkeit für Unternehmen, sich insbesondere in der IT-Organisation aufzustellen, wenig konkret. Es werden daher im Rahmen von Change-Projekten (Agile Transitions- oder Transformationsprojekte) vielfältige Aktivitäten unternommen, um Organisationen neu aufzustellen. Ziel ist, damit die notwendige Anpassungsfähigkeit in Zeiten von disruptiven Markt- und Technologieveränderungen zu gewährleisten.
ITSM-Aufgaben werden dabei in größeren Unternehmen verstärkt dezentralisiert. Das ist die Folge einer häufig genannten Zielsetzung: Aktuelle Herausforderungen können besser durch dezentrale Entscheidungsfindung statt zentraler Vorgabe und Kontrolle bewältigt werden. Befähigung und Ermächtigung in kleineren, selbstorganisierten sowie selbstverantwortlichen Einheiten führt zur notwendigen Reaktionsfähigkeit. [3]
Agiles Manifest und ITSM
Eine Dezentralisierung der Verantwortung wird dabei von FitSM unterstützt (vgl. Abschnitt 2.2). Anhand des agilen Manifests [4] und seiner vier Kernsätze soll das erläutert werden:
Eine Dezentralisierung der Verantwortung wird dabei von FitSM unterstützt (vgl. Abschnitt 2.2). Anhand des agilen Manifests [4] und seiner vier Kernsätze soll das erläutert werden:
| Kernsatz 1 | |
| • | Mensch im Mittelpunkt:Wir schätzen Individuen und Interaktionen mehr als Prozesse und Werkzeuge.ITSM-Prozesse haben häufig den Charakter einer zentralen Vorgabe. FitSM stellt die Formulierung von Anforderungen für die einzelnen Prozesse in den Vordergrund. Reifegrade helfen bei der Selbsteinschätzung der verantwortlichen und umsetzenden Einheiten. Diese können auf der Basis des General Requirements GR3 den Scope bestimmen, der explizit eine Einschränkung auf Services zulässt. FitSM bietet darüber hinaus ein generisches Rollenkonzept, das die Adaption auch in kleineren Einheiten ermöglicht. |
| Kernsatz 2 | |
| • | Wertschöpfung:Wir schätzen funktionierende Software mehr als umfassende Dokumentation.Die von FitSM formulierten Reifegrade für die Anforderungen setzen in der Regel auf der höchsten Stufe eine Dokumentation des Prozesses sowie seiner Ergebnisse voraus. Auf der Basis einer Service Management Richtlinie, die vom Management zu erstellen ist, kann von der Erreichung dieser Stufe abgesehen werden. FitSM überträgt dem Top-Management eine grundlegende Verantwortung durch aktives Engagement und sichtbare Führung. |
| Kernsatz 3 | |
| • | Kundenzufriedenheit:Wir schätzen Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.Im Prozess Customer Relationship Management fordert FitSM unter anderem, dass die Kunden der Services identifiziert sein müssen, Service Reviews unter Einbeziehung der Kunden durchgeführt werden müssen, eine konsistente Behandlung von Kundenbeschwerden gewährleistet sein muss und Kundenzufriedenheit gesteuert sowie gestaltet werden muss. Damit werden für die Kundenorientierung und vor allem -zufriedenheit wichtige Aspekte formuliert, deren Umsetzung in den dezentralen Einheiten erfolgen kann. |
| Kernsatz 4 | |
| • | Reaktionsfähigkeit:Wir schätzen Reagieren auf Veränderung mehr als das Befolgen eines Plans.FitSM ist ein Qualitätsmanagementsystem für IT Service Provider. Wie bei allen QM-Systemen wird dem Top-Management eine zentrale Verantwortung zugewiesen, die sich unter anderem in Planung, Einführung, Betrieb, Überwachung, Überprüfung und Verbesserung eines Service Management Systems (SMS) zeigt. Über dieses SMS und die aktive Umsetzung der dazugehörigen Service Management Richtlinie kann zentral der Rahmen gesetzt und bei Bedarf unterstützt werden. |
Diese Aspekte zeigen, dass FitSM das Thema IT Service Management pragmatisch, nachvollziehbar und verständlich für die Praxis löst. Damit ist die Basis für eine einfache Verbreitung und Anwendung auch im Rahmen von dezentralen und selbstorganisierten Organisationsformen möglich.
DevOps und ITSM
Entwicklungsteams und -projekte übernehmen im Rahmen der Veränderungen mittlerweile operative Betriebsaufgaben. Das kann beispielsweise zu häufigerer und schnellerer Lieferung von Changes führen oder die Störungsbeseitigung bzw. Ursachensuche in die jeweiligen Teams verlagern (DevOps).
Entwicklungsteams und -projekte übernehmen im Rahmen der Veränderungen mittlerweile operative Betriebsaufgaben. Das kann beispielsweise zu häufigerer und schnellerer Lieferung von Changes führen oder die Störungsbeseitigung bzw. Ursachensuche in die jeweiligen Teams verlagern (DevOps).
DevOps-Teams sind (oder werden) für einen großen Teil der Prozessaufgaben von ITSM selbst verantwortlich. Das bedeutet beispielsweise:
| • | Aktive Unterstützung bei der Verhandlung von Service Level Agreements im Prozess Service Level Management. Der zentrale Prozess muss die DevOps-Teams bei Vertragsgestaltungen und vor allem -inhalten einbeziehen, um die Selbstorganisation der Teams zu gewährleisten (Pull- statt Push-Prinzip). |
| • | Durchführung von Changes im Prozess Change Management. In reifen DevOps-Organisationen wird die Entscheidung über Changes in den beteiligten Einheiten getroffen [5]. Bestehen noch stärkere Abhängigkeiten zwischen den DevOps-Teams und Service, ist ein zentraler Prozess (u. a. zur Sicherstellung der Governance) notwendig. Dieser verliert jedoch mehr und mehr an Bedeutung. |
| • | Die Störungsbehandlung/-beseitigung im Incident Management erfolgt wieder stärker im DevOps-Team. Auch das zeichnet erfolgreiche DevOps-Organisationen aus. Der zentrale Prozess übernimmt Aufgaben wie Single Point of Contact (SPoC), Erreichbarkeit und Anwenderkommunikation sowie Prozessüberwachung. Die Verantwortung für Störungsbearbeitung in den Teams wird dazu führen, dass diese Teams von Beginn an mehr Qualität liefern. |
| • | Auch das Problem Management findet in den DevOps-Teams statt, da diese an einer nachhaltigen Qualitätssteigerung interessiert und intrinsisch motiviert sind, auch die Ursachen zu finden und zu beseitigen. |
2 Sinnvoll organisieren
Häufig stehen IT-Organisationen vor der Problematik, dass die für größere Organisationen entwickelten Rahmenwerke, wie ITIL und ISO/IEC 20000, für ihre Belange zu mächtig und komplex sind oder zu hohe Anforderungen stellen. Das gilt selbstverständlich in noch größerem Maße für die agilen Teams, die im Rahmen einer Ausrichtung an DevOps im Prinzip die Umsetzung dieser Rahmenwerke in kleineren, autonomen Teams bewerkstelligen müssen.
Keep it simple
Bei dieser Problematik setzt FitSM an. Die wichtigsten Bestandteile etablierter Rahmenwerke wurden herausgearbeitet und unter dem Grundsatz Keep it simple auf das Notwendigste beschränkt und zusammengeführt. Die Ausrichtung ist dabei an einer praxisnahen Umsetzung orientiert.
Bei dieser Problematik setzt FitSM an. Die wichtigsten Bestandteile etablierter Rahmenwerke wurden herausgearbeitet und unter dem Grundsatz Keep it simple auf das Notwendigste beschränkt und zusammengeführt. Die Ausrichtung ist dabei an einer praxisnahen Umsetzung orientiert.
Im Folgenden wird zunächst der traditionelle Ansatz für IT Service Management erläutert, bei dem umfangreiche Ansätze vereinfacht werden. Danach wird der entgegengesetzte Weg beschrieben, der von FitSM präferiert und unterstützt wird.
2.1 Traditioneller Ansatz: Umfassendes Rahmenwerk, Vereinfachung bei Implementierung
„Hat FitSM eine Daseinsberechtigung? Die darin verwendeten Inhalte gibt es doch bereits in anderen Rahmenwerken.”
FitSM bedient sich in erster Linie an Inhalten aus ITIL, der ISO/IEC 20000 und COBIT und kombiniert die drei Ansätze miteinander. Das machen Seniorberater und Compliance-Beauftragte in großen Unternehmen schon seit Jahren. Diese Personen haben sich in alle genannten Rahmenwerke (mehrere tausend Seiten) eingearbeitet und jahrelange Praxiserfahrung bei der Implementierung gesammelt. Nur so ist es ihnen möglich, aus den umfangreichen Rahmenwerken das zu extrahieren, was für eine bestimmte Organisation tatsächlich relevant ist.
Traditioneller Ansatz
Wie können der IT-Leiter eines kleinen oder mittelständischen Unternehmens oder der Scrum Master bzw. agile Coach eines DevOps-Teams mit dieser Herausforderung umgehen? Möchten sie sich an den genannten Frameworks ausrichten, würde das bedeuten,
Wie können der IT-Leiter eines kleinen oder mittelständischen Unternehmens oder der Scrum Master bzw. agile Coach eines DevOps-Teams mit dieser Herausforderung umgehen? Möchten sie sich an den genannten Frameworks ausrichten, würde das bedeuten,
| 1. | sich in die ITIL-Bücher einarbeiten, |
| 2. | die für das eigene Unternehmen bzw. eigene Team relevanten Aspekte zu extrahieren, |
| 3. | diese dann so zu vereinfachen, dass das Unternehmen bzw. das Team handlungsfähig bleiben, d. h. nur die notwendigen Aspekte übernehmen und |
| 4. | dann das Ganze schrittweise zu implementieren. |
Ein Großteil der IT-Leiter mittelständischer Unternehmen dürfte intern nicht die dazu notwendigen Ressourcen aufbringen können. Gleiches gilt für die Scrum Master und agilen Coaches im DevOps-Umfeld.
Hier kommt FitSM ins Spiel. Die ersten drei Schritte wurden hier für die drei genannten Rahmenwerke bereits durchgeführt. Die Anforderungen sind praxisnah formuliert, um die Implementierung zu unterstützen. Trotzdem handelt es sich noch immer um ein generisches Rahmenwerk und muss durch die eigene Organisation mit Leben gefüllt werden.
FitSM ermöglicht den bisher genannten Verantwortlichen (IT-Leiter, Scrum Master, agile Coaches), die Vorteile dreier etablierter Rahmenwerke zu nutzen, auch wenn sie nicht die Ressourcen aufbringen können, diese auf die eigene Organisation herunterzubrechen. Dabei unterstützt es sowohl Governance-Aspekte als auch agile Ansätze.
2.2 FitSM – ein leichtgewichtiger Ansatz
Die traditionellen Rahmenwerke haben über die Jahre immer mehr Details aufgenommen, um sich immer mehr zu komplettieren. Dies ist vor allem für weltumspannende Konzerne wichtig. Die Erfahrung zeigt, dass bei der Anpassung auf ein mittelständisches Unternehmen immer wieder die gleichen Aspekte herausfallen, um ein Zuviel an Verwaltung zu vermeiden.
Die Initiatoren von FitSM standen bei der Entwicklung selbst vor der Frage: Was braucht eine mittelständische Organisation bzw. kleine Einheit wie ein DevOps-Team, und was wäre zu viel? Beteiligte aus vielen verschiedenen Ländern haben ihre Erfahrungen eingebracht. Herausgekommen ist ein minimalistischer Ansatz. So benötigt ein mittelständisches Unternehmen in der Regel kein extrem umfassendes Supplier Management für die IT. Trotzdem ist es wichtig, die Lieferanten, die abgeschlossenen Verträge und vor allem die Ansprechpartner des Kunden zu kennen. Vor allem wenn derjenige, der das normalerweise macht, gerade in Kreta am Strand liegt.
Minimalistischer Ansatz
Statt selbst umfangreiche Rahmenwerke aufwendig herunter zu brechen, wird mit FitSM ein absolutes Minimum an Organisation implementiert. Aus ITIL kommen jahrzehntelange Erfahrungswerte bei der Definition der ITSM-Prozesse. Die ISO/IEC 20000 bringt ein Managementsystem mit, das unter anderem den Rahmen für eine stetige Verbesserung legt und damit wie geschaffen für agile Teams ist. Außerdem werden Verantwortlichkeiten auf der obersten Managementebene festgelegt und dem Top-Management damit die Gelegenheit gegeben, den Rahmen für IT Service Management genau passend zur Organisation zu schaffen. Aus COBIT wurde ein Reifegradmodell adaptiert, das sich auch in einigen anderen Standards wiederfindet. Dieses Reifegradmodell ermöglicht agilen Teams die schrittweise Übernahme ehemals zentraler Aufgaben.
Statt selbst umfangreiche Rahmenwerke aufwendig herunter zu brechen, wird mit FitSM ein absolutes Minimum an Organisation implementiert. Aus ITIL kommen jahrzehntelange Erfahrungswerte bei der Definition der ITSM-Prozesse. Die ISO/IEC 20000 bringt ein Managementsystem mit, das unter anderem den Rahmen für eine stetige Verbesserung legt und damit wie geschaffen für agile Teams ist. Außerdem werden Verantwortlichkeiten auf der obersten Managementebene festgelegt und dem Top-Management damit die Gelegenheit gegeben, den Rahmen für IT Service Management genau passend zur Organisation zu schaffen. Aus COBIT wurde ein Reifegradmodell adaptiert, das sich auch in einigen anderen Standards wiederfindet. Dieses Reifegradmodell ermöglicht agilen Teams die schrittweise Übernahme ehemals zentraler Aufgaben.
Einfach und verständlich
Beim Zusammenführen der Reduktionen aus den drei Rahmenwerken wurde nicht nur darauf geachtet, dass alles nahtlos ineinandergreift. Darüber hinaus wurde ein handlungsfähiger Ansatz gewählt. FitSM zielt darauf ab, auch für Praktiker (d. h. nicht ITSM-Experten) möglichst verständlich zu sein. Es unterstützt durch einfache Formulierungen die praxisorientierte Integration in die tägliche Arbeit. Dieses Ineinandergreifen ist in Abbildung 1 dargestellt.
Beim Zusammenführen der Reduktionen aus den drei Rahmenwerken wurde nicht nur darauf geachtet, dass alles nahtlos ineinandergreift. Darüber hinaus wurde ein handlungsfähiger Ansatz gewählt. FitSM zielt darauf ab, auch für Praktiker (d. h. nicht ITSM-Experten) möglichst verständlich zu sein. Es unterstützt durch einfache Formulierungen die praxisorientierte Integration in die tägliche Arbeit. Dieses Ineinandergreifen ist in Abbildung 1 dargestellt.
In einer Welt, in der Geschäftsprozesse immer mehr von IT Services abhängen und die Verflechtung zwischen den IT Services zunimmt, kommt keine IT-Organisation mehr um ITSM herum. FitSM vereint die Aspekte, die beispielsweise eine moderne IT-Abteilung eines mittelständischen Unternehmens berücksichtigen muss, auf einem absolut minimalen Niveau. Dieser Ansatz gilt auch für agile Teams in DevOps-Organisationen.
Dadurch wird ermöglicht, im ersten Schritt einen leichtgewichtigen Ansatz zu wählen, dessen Implementierung die Erfahrung der Beteiligten im Umgang mit ITSM und den damit zusammenhängenden Prozessen stärkt.
Ausbauen, wo nötig
Zeigt sich nun, dass die beschriebenen Aspekte des Managementsystems nicht ausreichen, z. B. weil die Organisation bereits eine ISO-9001-Zertifizierung hat und die Managementsysteme kombiniert werden sollen, dann lohnt es sich, die ISO/IEC 20000 zu Rate zu ziehen und FitSM damit zu ergänzen. Das geht relativ unproblematisch, da man mit FitSM ja bereits einen Kern der ISO/IEC 20000 implementiert hat.
Zeigt sich nun, dass die beschriebenen Aspekte des Managementsystems nicht ausreichen, z. B. weil die Organisation bereits eine ISO-9001-Zertifizierung hat und die Managementsysteme kombiniert werden sollen, dann lohnt es sich, die ISO/IEC 20000 zu Rate zu ziehen und FitSM damit zu ergänzen. Das geht relativ unproblematisch, da man mit FitSM ja bereits einen Kern der ISO/IEC 20000 implementiert hat.
Best Practices ergänzen FitSM
Möglicherweise gibt es Prozesse, die einen umfangreicheren Ansatz benötigen, als FitSM dies vorsieht. Dies kann z. B. aus Anforderungen eines wichtigen Kunden oder auch einer Konzernmutter resultieren. In diesem Fall kann ITIL weiterhelfen. Die an ITIL und ISO/IEC 20000 angelehnten Prozesse ermöglichen eine nahtlose Erweiterung der beschriebenen Prozesse mit den weiterführenden Best Practices aus ITIL. Die dort erwähnten Begrifflichkeiten und Rollen kennt man bereits weitestgehend aus FitSM. In DevOps-Organisationen kann dieser Weg ebenfalls genutzt werden, da die bekannten Skalierungsansätze wie SAFe oder LeSS die Aufgaben für den Betrieb (d. h. IT Service Management) nicht adäquat beschreiben.
Möglicherweise gibt es Prozesse, die einen umfangreicheren Ansatz benötigen, als FitSM dies vorsieht. Dies kann z. B. aus Anforderungen eines wichtigen Kunden oder auch einer Konzernmutter resultieren. In diesem Fall kann ITIL weiterhelfen. Die an ITIL und ISO/IEC 20000 angelehnten Prozesse ermöglichen eine nahtlose Erweiterung der beschriebenen Prozesse mit den weiterführenden Best Practices aus ITIL. Die dort erwähnten Begrifflichkeiten und Rollen kennt man bereits weitestgehend aus FitSM. In DevOps-Organisationen kann dieser Weg ebenfalls genutzt werden, da die bekannten Skalierungsansätze wie SAFe oder LeSS die Aufgaben für den Betrieb (d. h. IT Service Management) nicht adäquat beschreiben.
Möchte oder muss das Management aus Gründen der Compliance bspw. ein unternehmensweites Steuerungs- und Kontrollsystem einführen, könnte es notwendig werden, die entsprechenden COBIT-Bestandteile in FitSM zu erweitern. Diese Orientierung an Reifegraden macht die Nutzung in agilen Teams ebenfalls möglich und sinnvoll.
2.3 Herausforderungen für ITSM in der Praxis?
Betrachtet man die geschilderten Aspekte, so stehen die IT-Leiter und agilen Coaches für ihre jeweiligen Themen vor folgenden Herausforderungen:
Zu ambitioniert
Die Literatur suggeriert immense Verbesserungspotenziale bei umfassender Implementierung. IT-Organisationen vertragen jedoch nur ein gewisses Maß an Veränderung innerhalb eines begrenzten Zeitraumes. In DevOps-Teams kann dem durch die schrittweise Nutzung entgegengewirkt werden, was den agilen Ansätzen (u. a. kurze Feedbackzyklen) immanent ist. Trotzdem sollte diese Gefahr aufgrund eines zu hohen Erwartungsdrucks von außen nicht vernachlässigt werden.
Die Literatur suggeriert immense Verbesserungspotenziale bei umfassender Implementierung. IT-Organisationen vertragen jedoch nur ein gewisses Maß an Veränderung innerhalb eines begrenzten Zeitraumes. In DevOps-Teams kann dem durch die schrittweise Nutzung entgegengewirkt werden, was den agilen Ansätzen (u. a. kurze Feedbackzyklen) immanent ist. Trotzdem sollte diese Gefahr aufgrund eines zu hohen Erwartungsdrucks von außen nicht vernachlässigt werden.
Zu projektartig
Die Anpassung von Abläufen wird häufig in Form eines Projekts durchgeführt. Dabei wird angenommen, dass ein Zielzustand schnell erreicht und gehalten werden kann. Agilität und nachhaltige, iterative Verbesserungen kommen dabei zu kurz. Dort wird eher auf nachhaltige Teamzusammensetzung und -entwicklung gesetzt.
Die Anpassung von Abläufen wird häufig in Form eines Projekts durchgeführt. Dabei wird angenommen, dass ein Zielzustand schnell erreicht und gehalten werden kann. Agilität und nachhaltige, iterative Verbesserungen kommen dabei zu kurz. Dort wird eher auf nachhaltige Teamzusammensetzung und -entwicklung gesetzt.
Beteiligte werden nicht abgeholt
Den Beteiligten werden Aktivitäten vorgesetzt, anstatt sie zu beteiligen. Sie sehen einen Mehraufwand und nicht den Nutzen. Insbesondere wenn Entwickler in DevOps-Teams Betriebsaufgaben übernehmen sollen, stoßen Scrum Master und agile Coaches auf dieses Problem.
Den Beteiligten werden Aktivitäten vorgesetzt, anstatt sie zu beteiligen. Sie sehen einen Mehraufwand und nicht den Nutzen. Insbesondere wenn Entwickler in DevOps-Teams Betriebsaufgaben übernehmen sollen, stoßen Scrum Master und agile Coaches auf dieses Problem.
Mangelnde Prozessverantwortung
Gibt es keinen Prozessverantwortlichen oder nimmt dieser seine Aufgaben nicht wahr, fehlt dem Prozess die Optimierung und die Anpassung an Veränderungen. Der gelebte Prozess entfernt sich nach Gutdünken der Beteiligten vom geplanten Prozess.
Gibt es keinen Prozessverantwortlichen oder nimmt dieser seine Aufgaben nicht wahr, fehlt dem Prozess die Optimierung und die Anpassung an Veränderungen. Der gelebte Prozess entfernt sich nach Gutdünken der Beteiligten vom geplanten Prozess.
Mangelnde Transparenz
Personen, die Aktivitäten ausführen, wissen nicht, was mit ihren Ergebnissen passiert, insbesondere, warum Kollegen bestimmte Informationen benötigen. Wer den Sinn einer Information nicht nachvollziehen kann, sieht auch keinen Grund dafür, dies zu dokumentieren. Agile Ansätze fokussieren auf Transparenz.
Personen, die Aktivitäten ausführen, wissen nicht, was mit ihren Ergebnissen passiert, insbesondere, warum Kollegen bestimmte Informationen benötigen. Wer den Sinn einer Information nicht nachvollziehen kann, sieht auch keinen Grund dafür, dies zu dokumentieren. Agile Ansätze fokussieren auf Transparenz.
Kein oder zu hoher Fokus auf KPIs
Ohne Messwerte lässt sich der Erfolg einer Maßnahme nur bedingt bewerten. Wird die Leistung der Prozessbeteiligten blind an die Erreichung von Messwerten gekoppelt, richten die Personen ihre Arbeit an den Messwerten aus. Dies korreliert nicht immer mit den Organisationszielen.
Ohne Messwerte lässt sich der Erfolg einer Maßnahme nur bedingt bewerten. Wird die Leistung der Prozessbeteiligten blind an die Erreichung von Messwerten gekoppelt, richten die Personen ihre Arbeit an den Messwerten aus. Dies korreliert nicht immer mit den Organisationszielen.
Übernahme von Tool-Vorlagen
Aus den Prozessmodellen werden Tools häufig 1:1 übernommen. Die Anpassung von ITSM-Werkzeugen ist zwar aufwendig, aber notwendig. Eine unreflektierte Übernahme von Prozess-Templates aus den Tools bringt kaum den gewünschten Mehrwert.
Aus den Prozessmodellen werden Tools häufig 1:1 übernommen. Die Anpassung von ITSM-Werkzeugen ist zwar aufwendig, aber notwendig. Eine unreflektierte Übernahme von Prozess-Templates aus den Tools bringt kaum den gewünschten Mehrwert.
Die Entscheidung, ein einfaches Rahmenwerk als Kern zu nutzen, löst nicht die aufgezeigten Probleme, aber es sorgt für eine höhere Verständlichkeit, gerade bei denen, die nicht direkt an der Planung beteiligt sind. Dies erhöht die Transparenz, vereinfacht die Definition von KPIs sowie die Erkennung von Verbesserungspotenzialen. Eine klare Vorstellung des Prozessmodells unterstützt zudem Auswahl und Implementierung von ITSM-Tools.
3 Aufbau von FitSM
FitSM als Rahmenwerk setzt sich aus einzelnen Standards zusammen. Wie in Abbildung 2 dargestellt, sind es im Kern vier Dokumente, die durch Anwendungshilfen ergänzt werden.
FitSM-0
FitSM-0 gibt einen kurzen Überblick über das Gesamtkonstrukt FitSM. Es definiert alle in FitSM verwendeten Fachbegriffe auf einfache Weise. Somit wird ein einheitliches Verständnis der verwendeten Begriffe erzeugt. Die Nutzung dieses Dokuments in der Praxis als Glossar hat sich bewährt. Es wurden bei den Begriffsbeschreibungen die Definitionen aus den bestehenden Rahmenwerken ITIL und ISO/IEC 20000 berücksichtigt, um Widersprüche zu vermeiden.
FitSM-0 gibt einen kurzen Überblick über das Gesamtkonstrukt FitSM. Es definiert alle in FitSM verwendeten Fachbegriffe auf einfache Weise. Somit wird ein einheitliches Verständnis der verwendeten Begriffe erzeugt. Die Nutzung dieses Dokuments in der Praxis als Glossar hat sich bewährt. Es wurden bei den Begriffsbeschreibungen die Definitionen aus den bestehenden Rahmenwerken ITIL und ISO/IEC 20000 berücksichtigt, um Widersprüche zu vermeiden.
FitSM-1
FitSM-1 enthält Anforderungen an ein funktionierendes IT Service Managementsystem. Das Dokument gliedert sich in einen Teil mit allgemeinen Anforderungen und einen Teil mit prozessspezifischen Anforderungen.
FitSM-1 enthält Anforderungen an ein funktionierendes IT Service Managementsystem. Das Dokument gliedert sich in einen Teil mit allgemeinen Anforderungen und einen Teil mit prozessspezifischen Anforderungen.
Diese Anforderungen sind in zwei Bereiche unterteilt. Der erste Teil enthält 17 allgemeine Anforderungen (General Requirements, GR) mit einer Relevanz für das gesamte Managementsystem. Der zweite Teil ist prozessspezifisch aufgebaut und enthält die insgesamt 66 Anforderungen an die jeweiligen Prozesse (Process Requirements, PR). Zusammengehörige Prozesse wurden in Prozessgruppen gegliedert. Zwischen den Prozessen der Prozessgruppen gibt es erhöhte Abhängigkeiten. Sie sind meist nicht unabhängig voneinander implementierbar.
FitSM-2
FitSM-2 empfiehlt verschiedene Grundsätze und Aktivitäten, die dabei helfen, die Anforderungen aus FitSM-1 umzusetzen. Es handelt sich dabei nicht um zwingend zu erfüllende Vorgaben, sondern um Handlungsempfehlungen, die die Einhaltung der Vorgaben erleichtern. Um die Zuordnung von Handlungsempfehlungen zu Anforderungen zu vereinfachen, enthält FitSM-2 die gleiche Gliederung wie FitSM-1.
FitSM-2 empfiehlt verschiedene Grundsätze und Aktivitäten, die dabei helfen, die Anforderungen aus FitSM-1 umzusetzen. Es handelt sich dabei nicht um zwingend zu erfüllende Vorgaben, sondern um Handlungsempfehlungen, die die Einhaltung der Vorgaben erleichtern. Um die Zuordnung von Handlungsempfehlungen zu Anforderungen zu vereinfachen, enthält FitSM-2 die gleiche Gliederung wie FitSM-1.
FitSM-3
FitSM-3 beschreibt ein Rollenmodell, das auf den Anforderungen von FitSM-1 aufbaut. Es werden Verantwortlichkeiten und Aufgaben einzelner Rollen definiert und Empfehlungen für mögliche Zuweisungen von Rollen zu Personen ausgesprochen. Das dargestellte Rollenkonzept hat keinen verpflichtenden Charakter. Es ist vielmehr als Vorschlag anzusehen.
FitSM-3 beschreibt ein Rollenmodell, das auf den Anforderungen von FitSM-1 aufbaut. Es werden Verantwortlichkeiten und Aufgaben einzelner Rollen definiert und Empfehlungen für mögliche Zuweisungen von Rollen zu Personen ausgesprochen. Das dargestellte Rollenkonzept hat keinen verpflichtenden Charakter. Es ist vielmehr als Vorschlag anzusehen.
Der Kern von FitSM mit den inhaltlichen Festlegungen und Beschreibungen wird durch nachfolgende praxisorientierte Ergänzungen komplettiert:
FitSM-4
FitSM-4 stellt Vorlagen und Beispiele für verschiedene Dokumente zur Verfügung, sodass diese nicht in jeder Organisation neu entwickelt werden müssen. Hier sind beispielsweise Vorlagen zur Prozessdefinition oder ein Service Level Agreement zu finden. Die Vorlagen werden stetig erweitert und in weitere Sprachen übersetzt.
FitSM-4 stellt Vorlagen und Beispiele für verschiedene Dokumente zur Verfügung, sodass diese nicht in jeder Organisation neu entwickelt werden müssen. Hier sind beispielsweise Vorlagen zur Prozessdefinition oder ein Service Level Agreement zu finden. Die Vorlagen werden stetig erweitert und in weitere Sprachen übersetzt.
FitSM-5
FitSM-5 enthält Leitfäden zur Unterstützung bei der Einführung des IT Service Managements und einiger Prozesse.
FitSM-5 enthält Leitfäden zur Unterstützung bei der Einführung des IT Service Managements und einiger Prozesse.
FitSM-6
FitSM-6 liefert ein Assessment-Tool, das der Bewertung des IT Service Management Reifegrads der eigenen Organisation dient. Es unterstützt dabei, festzustellen, in welchen Bereichen die gesteckten Ziele erreicht wurden und wo ein weiterer Ausbau der organisationseigenen Fähigkeiten sinnvoll wäre.
FitSM-6 liefert ein Assessment-Tool, das der Bewertung des IT Service Management Reifegrads der eigenen Organisation dient. Es unterstützt dabei, festzustellen, in welchen Bereichen die gesteckten Ziele erreicht wurden und wo ein weiterer Ausbau der organisationseigenen Fähigkeiten sinnvoll wäre.
Während Fragen zur Bestimmung eines Reifegrads häufig sehr komplex und schwer zu beantworten sind, wurde hier Wert auf einfache und präzise Fragestellungen gelegt. Um Interpretationsspielräume bei der Beantwortung der Fragen zu vermeiden, gibt es bereits vorformulierte Antworten.
4 Praktische Vorgehensweise
Typische Fragen
Auch bei der Nutzung von FitSM stellen sich die typischen Fragen:
Auch bei der Nutzung von FitSM stellen sich die typischen Fragen:
| • | Wo sind wir aktuell? – Ist identifizieren |
| • | Was ist unser Ziel? – Soll identifizieren |
| • | Wie gehen wir vor? – Rahmen festlegen |
| • | In welcher Reihenfolge setzen wir welche Prozesse um? –Prozessreihenfolge |
| • | Wie identifizieren wir Aufgabendetails und setzen diese um? – Aufgaben sichten |
| • | Gibt es bereits allgemeine Erfahrungswerte, die die Abarbeitung der Aufgaben erleichtern? – Vorlagen und Ratgeber |
| • | Wurde das Ziel erreicht? – Zielerreichungsgrad prüfen |
„Ist” identifizieren
Mit dem Assessment-Tool aus FitSM-6 lässt sich mit relativ geringem Aufwand feststellen, was bereits vorhanden ist und auf welchem Reifegrad sich die vorhandenen Prozesse bzw. Aktivitäten befinden. Auch wenn das Assessment-Tool die Möglichkeit bietet, den Fokus einzuschränken, also nur eine Teilgruppe der Prozesse zu betrachten, bietet es sich an dieser Stelle an, alle Fragen zu allen Prozessen zu beantworten. Damit ist sichergestellt, dass keine relevanten Aspekte vergessen werden, nur weil man selbst nicht an sie gedacht hat. Für agile oder DevOps-Teams ist dieser Einstieg pragmatisch und nachvollziehbar. Die Aufgaben aus ITSM sind greifbar beschrieben und können im Rahmen der Retrospektive oder eines Workshops auch mit Entwicklern bearbeitet werden.
Mit dem Assessment-Tool aus FitSM-6 lässt sich mit relativ geringem Aufwand feststellen, was bereits vorhanden ist und auf welchem Reifegrad sich die vorhandenen Prozesse bzw. Aktivitäten befinden. Auch wenn das Assessment-Tool die Möglichkeit bietet, den Fokus einzuschränken, also nur eine Teilgruppe der Prozesse zu betrachten, bietet es sich an dieser Stelle an, alle Fragen zu allen Prozessen zu beantworten. Damit ist sichergestellt, dass keine relevanten Aspekte vergessen werden, nur weil man selbst nicht an sie gedacht hat. Für agile oder DevOps-Teams ist dieser Einstieg pragmatisch und nachvollziehbar. Die Aufgaben aus ITSM sind greifbar beschrieben und können im Rahmen der Retrospektive oder eines Workshops auch mit Entwicklern bearbeitet werden.
„Soll” identifizieren
Bei der Zieldefinition stellt sich die Frage, welche Prozesse auf welchem Reifegrad betrieben werden sollen. Dabei ist es nicht nur legitim, sondern häufig auch sinnvoll, von dem hehren Ziel abzuweichen, alle Prozesse auf den höchsten Reifegrad heben zu wollen. Anforderungen aus Geschäftsprozessen oder auch gesetzliche Vorgaben bedingen häufig einen hohen Reifegrad einzelner Prozesse. Beschreiben Prozesse einzelne Tätigkeiten, die in der eigenen Organisation nur selten vorkommen und bei falscher Ausführung kaum negative Konsequenzen haben, hätte ein hoher Reifegrad möglicherweise ein zu hohes Verwaltungsniveau zur Folge. Dem Verwaltungsaufwand würde kein Nutzen in entsprechender Höhe gegenüberstehen.
Bei der Zieldefinition stellt sich die Frage, welche Prozesse auf welchem Reifegrad betrieben werden sollen. Dabei ist es nicht nur legitim, sondern häufig auch sinnvoll, von dem hehren Ziel abzuweichen, alle Prozesse auf den höchsten Reifegrad heben zu wollen. Anforderungen aus Geschäftsprozessen oder auch gesetzliche Vorgaben bedingen häufig einen hohen Reifegrad einzelner Prozesse. Beschreiben Prozesse einzelne Tätigkeiten, die in der eigenen Organisation nur selten vorkommen und bei falscher Ausführung kaum negative Konsequenzen haben, hätte ein hoher Reifegrad möglicherweise ein zu hohes Verwaltungsniveau zur Folge. Dem Verwaltungsaufwand würde kein Nutzen in entsprechender Höhe gegenüberstehen.
Die identifizierten Ziele können im Assessment-Tool erfasst werden. Dies hat den Vorteil, dass mit dem Werkzeug jederzeit das Delta zwischen Ist und Soll visualisiert werden kann. Gerade für die Dezentralisierung in den Produktteams (agil oder DevOps) ist die Möglichkeit der Reduzierung des Umfangs sehr hilfreich. Die Teams können die nicht benötigten Anforderungen und Prozesse „ausblenden”. Für die notwendigen Aufgaben kann auch ein niedrigerer Reifegrad ausreichend sein.
Rahmen festlegen
Die allgemeinen Anforderungen aus FitSM-1 legen einen Rahmen fest, ohne den sich die Prozesse selbst nur bedingt implementieren lassen. Es wird einer Person bzw. dem DevOps-Team die Verantwortung zur Etablierung des IT Service Managements übertragen. Diese Person/das jeweilige Team verantwortet letztendlich auch die Zielerreichung. Hier wird deutlich, dass sich große Teile dieses und des vorherigen Schrittes überlappen.
Die allgemeinen Anforderungen aus FitSM-1 legen einen Rahmen fest, ohne den sich die Prozesse selbst nur bedingt implementieren lassen. Es wird einer Person bzw. dem DevOps-Team die Verantwortung zur Etablierung des IT Service Managements übertragen. Diese Person/das jeweilige Team verantwortet letztendlich auch die Zielerreichung. Hier wird deutlich, dass sich große Teile dieses und des vorherigen Schrittes überlappen.
Art und Umfang der Dokumentation müssen festgelegt werden. Gibt es in der eigenen Organisation bereits Vorgaben und Werkzeuge zur Dokumentation von Prozessen?
Gerade IT-Dienstleistungsunternehmen stellt die Festlegung des Anwendungsbereiches vor Herausforderungen. Betrachten wir in unserem Projekt die Leistungserbringung an einen internen oder externen Kunden? Steht also im Fokus, dass der Kollege im Nachbarbüro arbeiten kann, oder der Endkunde?
Rollen zuweisen
FitSM kennt Rollen für das gesamte Managementsystem, für Services sowie für Prozesse. Die Kunst liegt häufig darin, die Rollen sinnvoll zu kombinieren. Gerade in kleinen Organisationen fallen viele Rollen auf einzelne Personen. Das ist völlig legitim. Die Erfahrung zeigt, dass ohne klare Rollen- und somit auch Aufgabenzuweisung auf lange Sicht die Qualitätssicherung und Weiterentwicklung nicht funktioniert und das IS Service Management einschläft.
FitSM kennt Rollen für das gesamte Managementsystem, für Services sowie für Prozesse. Die Kunst liegt häufig darin, die Rollen sinnvoll zu kombinieren. Gerade in kleinen Organisationen fallen viele Rollen auf einzelne Personen. Das ist völlig legitim. Die Erfahrung zeigt, dass ohne klare Rollen- und somit auch Aufgabenzuweisung auf lange Sicht die Qualitätssicherung und Weiterentwicklung nicht funktioniert und das IS Service Management einschläft.
Nutzt man FitSM in DevOps-Teams, kann man das generische Konzept einfach adaptieren und die Rollen abgleichen. Ein Product Owner kann sich bspw. seine erweiterten Aufgaben aus dem Service Owner nehmen.
Prozessreihenfolge
Alle Aufgaben parallel anzugehen, überfordert in der Regel die Organisation, vor allem die operative Basis, die die Durchführung der Tätigkeiten in den Prozessen übernimmt. Allerdings ist es auch nicht möglich, die Implementierung der Prozesse rein sequenziell anzugehen, gerade wenn einzelne Prozesse auf andere funktionierende Prozesse angewiesen sind. Um dem zu begegnen, wurden in FitSM Prozessgruppen gebildet, die Prozesse mit einem hohen Grad an Abhängigkeiten bündeln.
Alle Aufgaben parallel anzugehen, überfordert in der Regel die Organisation, vor allem die operative Basis, die die Durchführung der Tätigkeiten in den Prozessen übernimmt. Allerdings ist es auch nicht möglich, die Implementierung der Prozesse rein sequenziell anzugehen, gerade wenn einzelne Prozesse auf andere funktionierende Prozesse angewiesen sind. Um dem zu begegnen, wurden in FitSM Prozessgruppen gebildet, die Prozesse mit einem hohen Grad an Abhängigkeiten bündeln.
Bei der Erstellung einer Reihenfolge spielen zwei Fragen eine elementare Rolle:
| • | Wo lassen sich Quick Wins erzielen? |
| • | Welche Prozesse bieten Potenzial zur Entlastung der operativ beteiligten Personen? |
Kritischer Erfolgsfaktor
Ein kritischer Erfolgsfaktor des gesamten Projekts ist die Akzeptanz des IT Service Managements bei denjenigen, die die Aktivitäten ausführen. Halten sich diese nicht an die definierten Prozesse, lässt sich kein funktionierendes IT Service Management umsetzen. Die Beteiligten müssen den Nutzen selbst erkennen. Dies lässt sich am besten erreichen, wenn sich der Nutzen schnell zeigt, indem bspw. ein Missstand behoben wird, der aktuell bei allen Beteiligten negativ auffällt (Quick Wins).
Ein kritischer Erfolgsfaktor des gesamten Projekts ist die Akzeptanz des IT Service Managements bei denjenigen, die die Aktivitäten ausführen. Halten sich diese nicht an die definierten Prozesse, lässt sich kein funktionierendes IT Service Management umsetzen. Die Beteiligten müssen den Nutzen selbst erkennen. Dies lässt sich am besten erreichen, wenn sich der Nutzen schnell zeigt, indem bspw. ein Missstand behoben wird, der aktuell bei allen Beteiligten negativ auffällt (Quick Wins).
IT Service Management bringt häufig ein Mehr an Dokumentation mit sich, das im Alltag bewältigt werden muss. Allerdings besteht auch ein großes Automatisierungspotenzial, z. B., indem Anforderungen der Anwender über ein Werkzeug im Intranet aufgenommen und als Ticket direkt in einen automatisierten Workflow gebracht werden. Gerade ITSM-Systeme, die dies recht einfach unterstützen, hatten in den letzten Jahren auf dem Markt großen Erfolg.
Aufgaben sichten
Die Prozesse in ihrer zu implementierenden Reihenfolge sind festgelegt und einer oder mehrere Verantwortliche für die Implementierung wurden zugewiesen. Nun stellt sich für jeden Prozess die Frage, welche Einzelaufgaben erledigt werden müssen. Hier kann FitSM-2 unterstützen. Darin sind für alle Prozesse Aufgaben zu finden, welche einmalig bei der Implementierung anfallen, und Aufgaben, die Teil des stetig durchzuführenden Prozesses werden sollten. Konkretisiert werden diese Aufgaben durch die Anforderungen an die Prozesse aus FitSM-1.
Die Prozesse in ihrer zu implementierenden Reihenfolge sind festgelegt und einer oder mehrere Verantwortliche für die Implementierung wurden zugewiesen. Nun stellt sich für jeden Prozess die Frage, welche Einzelaufgaben erledigt werden müssen. Hier kann FitSM-2 unterstützen. Darin sind für alle Prozesse Aufgaben zu finden, welche einmalig bei der Implementierung anfallen, und Aufgaben, die Teil des stetig durchzuführenden Prozesses werden sollten. Konkretisiert werden diese Aufgaben durch die Anforderungen an die Prozesse aus FitSM-1.
Vorlagen und Ratgeber nutzen (FitSM-4+5)
Bei der Umsetzung treten bestimmte Fragestellungen in vielen Organisationen immer wieder auf. Um nur eine davon zu nennen: Was wird bei uns konkret ein Service? Unterstützung für derartige Fragestellungen bietet FitSM-5. In Form von Leitfäden wird aufgezeigt, wie derartige Fragestellungen gelöst werden können. Diese Leitfäden haben sich in der Praxis für agile/DevOps-Teams als sehr hilfreich herausgestellt, da sie eingängig und prägnant das jeweilige Thema beschreiben.
Bei der Umsetzung treten bestimmte Fragestellungen in vielen Organisationen immer wieder auf. Um nur eine davon zu nennen: Was wird bei uns konkret ein Service? Unterstützung für derartige Fragestellungen bietet FitSM-5. In Form von Leitfäden wird aufgezeigt, wie derartige Fragestellungen gelöst werden können. Diese Leitfäden haben sich in der Praxis für agile/DevOps-Teams als sehr hilfreich herausgestellt, da sie eingängig und prägnant das jeweilige Thema beschreiben.
Außerdem unterstützt FitSM-4 die praktische Umsetzung, indem Vorlagen z. B. für einen IT-Servicekatalog oder auch SLAs zur Verfügung gestellt werden.
Zielerreichungsgrad prüfen
Zur Identifikation des Zielerreichungsgrads lässt sich mit dem Assessment-Tool aus FitSM-6 jederzeit der aktuelle Reifegrad bestimmen. Genau wie bei der ursprünglichen Identifikation des Ist-Zustandes werden die Fragen zum Reifegrad beantwortet. Die Differenz zwischen Soll- und Ist-Zustand lässt sich im Assessment-Tool ablesen und sollte sich im Laufe des Projekts stetig verringern.
Zur Identifikation des Zielerreichungsgrads lässt sich mit dem Assessment-Tool aus FitSM-6 jederzeit der aktuelle Reifegrad bestimmen. Genau wie bei der ursprünglichen Identifikation des Ist-Zustandes werden die Fragen zum Reifegrad beantwortet. Die Differenz zwischen Soll- und Ist-Zustand lässt sich im Assessment-Tool ablesen und sollte sich im Laufe des Projekts stetig verringern.
Bei agiler Vorgehensweise können die Ergebnisse im Rahmen der Retrospektiven schrittweise behandelt werden.
5 Stetige Verbesserung
Die kontinuierliche Verbesserung kann als Zielsetzung eine Steigerung der Qualität, aber auch eine gleichbleibende Qualität mit geringerem Aufwand verfolgen.
PDCA-Zyklus
FitSM legt mit den allgemeinen Anforderungen und vor allem mit dem Fokus auf dem PDCA-Zyklus die Basis für eine kontinuierliche Verbesserung. Je höher der Reifegrad, desto koordinierter laufen die Prozesse. Der Anteil an Improvisation sinkt. Allerdings nehmen mit steigendem Reifegrad auch die Verwaltung und Dokumentation zu. Neben den Prozessen ist auch die Qualität des Managementsystems zu betrachten. Für jeden Managementaspekt ist die Frage zu beantworten, ob er berücksichtigt werden soll, und wenn ja, bis zu welchem Reifegrad er ausgebaut wird.
FitSM legt mit den allgemeinen Anforderungen und vor allem mit dem Fokus auf dem PDCA-Zyklus die Basis für eine kontinuierliche Verbesserung. Je höher der Reifegrad, desto koordinierter laufen die Prozesse. Der Anteil an Improvisation sinkt. Allerdings nehmen mit steigendem Reifegrad auch die Verwaltung und Dokumentation zu. Neben den Prozessen ist auch die Qualität des Managementsystems zu betrachten. Für jeden Managementaspekt ist die Frage zu beantworten, ob er berücksichtigt werden soll, und wenn ja, bis zu welchem Reifegrad er ausgebaut wird.
Scrum und ITSM
Der PDCA-Zyklus ist inhaltlich eine besondere Brücke zwischen Agilität (Scrum) und ITSM (FitSM). Die konkrete Formulierung in den allgemeinen Anforderungen macht die Nutzung in agilen Teams eingängig.
Der PDCA-Zyklus ist inhaltlich eine besondere Brücke zwischen Agilität (Scrum) und ITSM (FitSM). Die konkrete Formulierung in den allgemeinen Anforderungen macht die Nutzung in agilen Teams eingängig.
Quellen
1
ISO/IEC 27001:2013 – Information technology – Security techniques – Information security management systems – Requirements; International Organization for Standardization (ISO); deutsche Fassung: DIN EN ISO/IEC 27001:2017 – Informationstechnik – Sicherheitsverfahren – Informationssicherheitsmanagementsysteme – Anforderungen (ISO/IEC 27001:2013 einschließlich Cor 1:2014 und Cor 2:2015)
2
Bundesamt für Sicherheit in der Informationstechnik, Referat I 1.4 IT-Sicherheitsmanagement und IT-Grundschutz, ITIL und Informationssicherheit
3
Weiterführende Gedanken: www.devopsde.de/blog/33-de-scale-your-organization.html
