fachzeitschrift fÜr die itsm˜community …...itsm 34 | 11 • 2015 19 ist (in scrum ist das die...

SM

CHANCEN AGILER IT> DE-SCALE YOUR ORGANIZATION>

IT-MANAGEMENT AUS DEM GLEICHGEWICHT> PRINCE2 AGILETM>

DISRUPTIVE IT SERVICE MANAGEMENT> TURBO IM PROJEKTMANAGEMENT

NR. 34 | NOVEMBER 2015 | EINZELPREIS 14 €

itFACHZEITSCHRIFT FÜR DIE ITSM-COMMUNITY

Agilitätim IT Service Management

NR. 34

ISSN

186

1-92

58

WW

W.IT

SMF.D

E

ServiceSServiceSManagementMManagementM

17itSM 34 | 11 • 2015

De-scale your Organization

1 MAnAgeMenT SuMMAry

Die Etablierung der IT als verlässlicher Partner und Dienstleister des Business ist lange Zeit mit der Ein-führung von IT Service Management Frameworks unter dem Stichwort „Best-Practice“ vorangetrie-ben worden. Bei allen vorzeigbaren Erfolgen dieser Bemühungen sind Kunden und Anwender immer noch unzufrieden und stellen immer höhere Anfor-derungen in kürzeren Zyklen. Prozesse haben sich zu verzwickten Abläufen entwickelt und sind für die aktuell geforderte Flexibilität nicht geeignet. Service Level Vereinbarungen werden nicht immer erfüllt und müssen mehr leisten als nur zur Rechtfertigung oder Absicherung zu dienen. Nicht zuletzt ist die Zufrie-denheit der IT-Mitarbeiter stark gesunken und unter-stützt damit nicht die Erwartungen und Forderungen an und von modernen Mitarbeitern.

Anhand von ausgewählten agilen Prinzipien wird in diesem Beitrag aufgezeigt, wie IT Service Manage-ment nachhaltig vereinfacht und neu ausgerichtet werden kann. Es wird gezeigt, wie „Empirische Pro-zesssteuerung“ statt „Best Practice“ stockende oder nicht zufriedenstellende Projekte zur Etablierung von IT Service Management wiederbeleben kann. In Anlehnung an das Rollenkonzept von Scrum werden Ideen für eine neue Service Organisation präsentiert. Abschließend wird das leichtgewichtige ITSM-Fra-mework FitSM vorgestellt, welches eine interessante Basis für ein agiles IT Service Management bietet.

2 AkTueLLe herAuSforderungen iM iT Service MAnAgeMenT

IT-Organisationen haben auf der Basis von Best Practice-Ansätzen wie ITIL® viel Arbeit zur Etablierung von IT Service Management geleistet. Die umfangrei-chen Frameworks lassen sich jedoch in der Praxis nicht immer leicht vermitteln oder implementieren. Integrierte Qualitätsmanagement-Prozesse dieser Frameworks liefern zwar umfangreiches Wissen über kontinuierliche Verbesserung, das jedoch vielfach wenn überhaupt „erst zum Schluss“ umgesetzt wird. Weiterhin bieten die ITSM-Frameworks zahlreiche praxiserprobte Lösungen, verleiten aber häufig und schnell in den IT-Organisationen zu einem „blinden“ Kopieren. Das wiederum stellt den Erfolg mancher Organisationsprojekte in Frage.

Eine Kundenanfrage (siehe folgende Seite) aus dem Mai 2015 zeigt das Dilemma. Das Unternehmen (welt-weit agierender Pharmakonzern) hat ein mächtiges Tool für IT Service Management im Einsatz, zahlrei-che spezialisierte Partner eingebunden, Vereinbarun-gen bzw. Verträge nach Lehrbuch, durchoptimierte Prozesse und sogar regelmäßige Messungen der Servicequalität.

Trotzdem sind die Kunden unzufrieden und zeigen der IT eindeutig, dass etwas geändert werden muss. Diese Unzufriedenheit bezieht sich dabei nicht direkt auf greif- und messbare Dinge wie Verletzung von Service Level Vereinbarungen oder zu hohen Kos-ten. Die Kunden bzw. Anwender bemängeln unter anderem:


TexT DIerK Söllner*

* erleben Sie Dierk Söllner auf dem Jahreskongress am 01.12.2015 mit dem Vortrag „De-ScAle yOUr OrGAnIZATIOn“

itSM 34 | 11 • 201518

• Unzureichende Orientierung an den Wünschen des Kunden/der Anwender

• Prozessumsetzung im Tool und im täglichen Leben nicht verständlich

• Kein Service-Commitment durch die Mitarbeiter• Komplexität der Service-Bestandteile• Herausforderung beim Monitoring der Prozesse

3 eMpiriSche prozeSSSTeuerung STATT beST prAcTice

Die aufgeführten Herausforderungen zeigen deut-lich, dass Best Practice Ansätze aktuell nicht immer eine Lösung anbieten. Sie müssen für den erfolgrei-chen Einsatz in der Praxis hinterfragt, ergänzt oder modifi ziert werden. Die Lebenszyklusphase CSI aus dem ITIL®-Framework könnte dazu eine Basis bilden, wird jedoch in der Praxis selten oder nur rudimentär angewendet und keinesfalls in die Unternehmens-kultur eingebettet.

Agile Methoden setzen demgegenüber häufi g auf das Prinzip der „Empirischen Prozessteuerung“ [Suther-land/Schwaber 2013]. Dabei wird Wissen aus Erfah-rung gewonnen und Entscheidungen werden auf Basis des Bekannten getroffen. Der Ansatz, Erfahrun-gen anderer Unternehmen in die eigene IT-Organisa-tion zu kopieren, wird gegen das schrittweise Lernen und eigenes Verbessern getauscht. Vorschläge und Anregungen aus anderen Frameworks können über-nommen werden. Wichtig ist jedoch, dass das über-schaubar bleibt und die eigenen Erfahrungen sowie Lernzyklen ergänzen muss.

Jede Implementierung von empirischer Prozesssteu-erung ruht auf drei Säulen (siehe Abbildung 1), näm-lich Transparenz, Überprüfung und Anpassung.

3.1 TrAnSpArenz

Die Forderung nach Transparenz verlangt mehr Sicht-barkeit der wesentlichen Aspekte eines Prozesses für diejenigen, die für das Ergebnis verantwortlich sind. Benötigt wird unter anderem eine gemeinsame Prozesssprache aller Prozessteilnehmer. Sowohl die Leistungserbringer als auch die Leistungsempfänger müssen ein gemeinsames Verständnis haben, wann die Leistung (hier der IT Service) wirklich erbracht


KUnDenAnFRAGe ZUM IT SeRVIce MAnAGeMenT

Dear Mr. Söllner,Thank you for your prompt reply. We have HPSM and I am responsible for Service Delivery for about 40 services – offshored and with 3 several „players“ involved in the delivery:

• infrastructure (hosting, databases, networks)• application delivery (specifi c for different services)• vendor (usually only doing bug-fi xing, but also involved in problem management)• consultants

We have SLA between us and customers, OLA with infrastructure and SLA with vendors. Typical KPI are measured daily however do not allow to „tune“ the process appropriately. I have the need to optimize the processes, and to bring transparency to Business – that is complaining for „too many interactions with support“ (whereby this is not demonstrated by the logs) and dislikes the offshoring. Objective is to please the business – removing ineffi ciencies – and being more effi cient in the monitoring of the processes.

Abb. 1: empirische Prozesssteuerung

19itSM 34 | 11 • 2015

ist (in Scrum ist das die „Definition of Done“). Die-ses gemeinsame Verständnis wird kontinuierlich wei-terentwickelt und bei der Lieferung des IT Services zur Abnahme durch den Kunden angewendet. Aus ITIL® lassen sich dazu die Service Acceptance Crite-rias heranziehen. Wichtig ist, dass diese Transparenz gemeinsam zwischen IT Service produzierenden und akzeptierenden Personen geschaffen wird und konti-nuierlich herzustellen ist.

3.2 ÜberprÜfung

Die Überprüfung fokussiert darauf, dass ständig mit Blick auf das vereinbarte Ziel die einzelnen Artefakte und der Fortschritt zu überprüfen sind. Diese Über-prüfung sollte durch die Leistungserbringer selbst und gewissenhaft erfolgen und die Arbeit nicht zu sehr behindern. Kernaussage ist dabei, dass die Überprüfung mit Blick auf die Zielerreichung erfol-gen muss. Das reduziert die Inhalte der Überprüfung auf das Wesentliche. Kennzahlen oder Berichte ori-entieren sich am gemeinsamen Ziel (Serviceverein-barungen) und nicht an technischen Möglichkeiten des Reporting oder der „Selbstbeweihräucherung der IT(-Manager)“.

3.3 AnpASSung

Sobald festgestellt wird, dass akzeptable Grenzwerte überschritten werden und beispielsweise IT Services nicht vereinbarungsgemäß erbracht werden können oder Prozesse ungenügende Ergebnisse liefern, muss der Prozess oder der Prozessinput angepasst wer-den. Diese Anpassung muss schnellstmöglich erfol-gen. Wichtig ist aus meiner Sicht, dass neben der klassischen Störungsbeseitigung und -bearbeitung (Incident, Problem und Change Management) sofort an einer Prozessänderung gearbeitet wird, d.h. dass sofort die kontinuierliche Verbesserung der Leis-tungserbringung gestartet wird.

3.4 eMpiriSche prozeSSTeuerung iM iT Service MAnAgeMenT

Die Empirische Prozesssteuerung wird in der Pra-xis des agilen Projektmanagements an konkreten Ereignissen und Terminen festgemacht. Im IT Service Management sind daher regelmäßige Termine ein-zurichten (siehe Kapitel „Die neue Service Organisa-tion“), an denen diese Aktivitäten durchzuführen sind. Der Erfolg hängt dabei von der Berücksichtigung aller drei Säulen ab, d.h. festgestellte Prozessfehler sind transparent zu dokumentieren und zu beseitigen.

4 ÜberTrAgung AgiLer prinzipien Auf dAS iT Service MAnAgeMenT

Mit der Formulierung des Agilen Manifests [http://agilemanifesto.org/iso/de] haben sich die Vertreter der führenden Methoden zur agilen Produktentwick-lung (bspw. Sutherland/Schwaber für Scrum, Beck/Jeffries/Fowler für Extreme Programming und Cock-burn für Crystal Clear) im Jahre 2001 auf eine gemein-same Basis für ihre Ansätze geeinigt. Das Agile Mani-fest dient allen Methoden als anerkannte, kollektive Grundlage und vereint damit teilweise inhaltlich unterschiedliche Frameworks. Neben den Kernaus-sagen sind 12 Prinzipien formuliert, die wichtige Eck-pfeiler im agilen Projektmanagement bilden und an dieser Stelle auszugsweise auf das IT Service Manage-ment übertragen und angewendet werden.

4.1 kundenzufriedenheiT durch konTinuierLiche Lieferung

Das Agile Manifest formuliert unter anderem das Prinzip „Unsere höchste Priorität ist es, den Kun-den durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ und stellt damit die Kundenzufriedenheit in den Vordergrund. Diese soll durch kontinuierliche Lieferung wertvol-ler Software erreicht werden. Überträgt man dieses Prinzip auf das IT Service Management, lassen sich folgende Forderungen ableiten. Das Service Team (siehe Kapitel 5) muss bestimmen können, was es liefern kann. Die kontinuierliche Lieferung wertvoller IT Services kann nur zur vollen Kundenzufriedenheit gelingen, wenn die Leistungserbringer bei der Fest-legung der Leistungsinhalte beteiligt sind und kon-kret bei erreichbaren Zielen mitwirken. Gleiches gilt für die Einbeziehung der Anwender, die stärker ihre konkreten Forderungen einbringen können müssen und intensiver an der Bewertung des Nutzens der erbrachten IT Services zu beteiligen sind.

Die Service-Inhalte sollten kontinuierlich mit Ausrich-tung an den Wünschen der Anwender weiterentwi-ckelt werden. Das bedeutet, dass konkrete Leistungen zwischen Erbringer und Abnehmer des IT Services zu vereinbaren sind sowie auf einem erreichbaren und geforderten Niveau starten.

4.2 MoTivierTe individuen

Ein weiteres Prinzip des Agilen Manifests lau-tet: „Errichte Projekte rund um motivierte Indivi-duen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“ Damit wird unter anderem die


itSM 34 | 11 • 201520

Mitarbeiterführung stärker auf den Menschen ausge-richtet und ein neues Verständnis von Zusammenar-beit etabliert. Im IT Service Management sollten die „Projekte“ als Service Team (siehe folgendes Kapitel) deklariert werden. Das heißt, dass die Erbringung der Services durch ein Team erfolgt, welches Unterstüt-zung und Vertrauen bekommt. Die IT-Organisation (Top-Management) setzt einen notwendigen Rahmen innerhalb dessen das Team frei arbeiten kann. Die jeweilige Führungskraft für das Service Team konkre-tisiert den Rahmen. Der Service Coach übernimmt in diesem Zusammenhang eine wichtige Aufgabe, denn er beseitigt die Hindernisse für das Team.

4.3 funkTionierende SofTwAre

Im Agilen Manifest wird gefordert: „Funktionierende Software ist das wichtigste Fortschrittsmaß“. Damit wird unterstrichen, dass das Ergebnis der Arbeit der IT den Anforderungen der Anwender entsprechen muss. Alle Tätigkeiten im IT Service Management müssen sich allein an funktionierenden IT Services ausrichten. Mit einer konsequenten Umsetzung die-ses Prinzips wird der Nutzen für die Anwender erhöht, da diese mehr als bisher Service-Inhalte bestimmen und Nutzen bzw. Business Value betont wird. Das Ser-vice-Team steht für die Einhaltung der Service-Level und sichert das als Team (Commitment) zu.

4.4 einfAchheiT

Im Agilen Manifest fi ndet sich auch das Prinzip: „Ein-fachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.“, welches mein per-sönliches Lieblingsprinzip ist. In agilen Projekten wird dabei Wert darauf gelegt, durch iteratives Vorgehen und permanenter Priorisierung der Anforderungen nur das aktuell Wichtigste umzusetzen (YAGNI-Prin-zip: You ain’t gonna need it.).

Im IT Service Management heißt das unter ande-rem, dass nicht alles technisch Mögliche umgesetzt werden muss. In einem intensiven Dialog zwischen Kunde, Anwender und Service-Team werden konkrete Service-Inhalte schrittweise entwickelt. Die berühmte „Goldkante an der Gardine“ fällt bei einem geringen bzw. nicht nachweisbaren Nutzen in diesen Gesprä-chen regelmäßig hinten runter.

4.5 verbeSSerung iM TeAM

Die kontinuierliche Verbesserung wird im Agilen Manifest folgendermaßen formuliert: „In regelmäßi-gen Abständen refl ektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend

an.“ Damit erhält das Service Team die Aufgabe direkt zugewiesen und muss sie regelmäßig durchführen. Der Rhythmus in agilen Projekten orientiert sich dabei an der Sprintlänge und liegt zwischen 2 und 4 Wochen.

Einfache Retrospektiven können im Service Team in regelmäßigen Abständen (monatlich) durchgeführt werden und sorgen unter anderem für kleine (aber wirkungsvolle) Veränderungen zur Steigerung der Prozesseffi zienz und -effektivität. Das CSI Register wird in diesem Fall permanent mit Leben gefüllt und die Arbeit damit an die Service Teams übertragen.

5 die neue Service orgAniSATion

Die Organisation des IT Service Managements benö-tigt mit Blick auf die aktuellen Herausforderungen ebenfalls eine Veränderung. Um beispielsweise das Commitment der Mitarbeiter zur Service Orientie-rung optimaler umzusetzen und den Kundenfokus über die gesamte Kette der Leistungserbringung zu stärken ist die Bildung von Service Teams notwendig. Diese Service Teams werden analog zu den Ansätzen aus dem agilen Projektmanagement mit drei Rollen besetzt. Diese drei Rollen sind teilweise schon in den vorhandenen Frameworks zum ITSM beschrieben, teilweise müssen sie neu geschaffen werden.


Abb. 2: Das Service Team: die Rollen Service owner, Service coach und Service Team, die zusammen an der

erbringung des Services arbeiten.

21itSM 34 | 11 • 2015

5.1 der Service owner

In einer neuen IT-Organisation mit dem klaren Fokus auf Serviceorientierung hat der Service Owner die umfassende Verantwortung für den Service und sorgt dafür, dass das Service Team das Richtige tut. Er ist die Schnittstelle zwischen Business und IT und erfüllt die Anforderungen der Fachbereiche durch entspre-chende IT Services. Im Idealfall hat er eine unterneh-merische Verantwortung für seinen Service. Eine hie-rarchische Weisungsbefugnis gegenüber dem Service Team würde den agilen Prinzipien widersprechen. Der Service Owner steuert die Aufgaben über eine Prio-risierung in das Team ein, die selbstorganisiert die Aufgaben übernehmen. Im generischen Rollenmo-dell von FitSM ist der Service Owner als eine zentrale Rolle beschrieben, der an den Gesamtverantwortli-chen des Service Management Systems berichtet. Der Service Owner

• hat umfassende Verantwortung (Accountable) für einen oder mehrere Services des Service Portfolios und des Service Katalogs

• agiert als zentrale Anlaufstelle (prozessübergrei-fend) für alles, was seinen Service betrifft und wird über alle wichtigen Ereignisse diesbezüglich informiert

• handelt als „Experte“ für seinen Service, sowohl in technischer als auch in nicht-technischer Hinsicht

• verwaltet und pflegt die Dokumentation seines Services, u.a. auch die Beschreibung und die Akzeptanzkriterien

• berichtet an den Eigner des Service Management Systems (SMS Owner)

Er formuliert die Anforderungen aus Sicht des Kun-den und betreut den IT Service als Produktmana-ger und hat ggfs. unternehmerische Aufgaben. Diese Rolle sorgt für die Orientierung an wertvollen Ser-vice-Inhalten und die Erfüllung der Kundenanforde-rungen. Der Inhaber betreut seinen Service aktiv und übernimmt mehr Verantwortung sowie persönliches Commitment (siehe obenstehende Textbox) für die-sen Service.

Er nimmt Veränderungen an Services ab und gibt diese im Rahmen einer schnellen Entscheidungsfin-dung frei zum Betrieb (in Zusammenarbeit mit dem CAB). Bei einer adäquaten Besetzung dieser Rolle (fachliche Führungskraft mit Durchsetzungsmöglich-keiten) kann eine schnellere Umsetzung der Anforde-rungen gewährleistet werden.

5.2 dAS Service TeAM

Das Service Team ist selbstorganisierend und mit allen Kompetenzen (Wissen/Erfahrung) ausgestattet, die es zur Serviceerbringung benötigt. Alle Tätigkeiten müssen durch das Service Team durchgeführt oder bei ausgelagerten IT Services bewertet und beauf-tragt werden können.

Um das Commitment des Service Teams zu unter-stützen wirkt es bei der Gestaltung von SLAs mit und bestimmt somit maßgeblich, was in diesen SLA ver-einbart wird. Je nach IT Service besteht das Service Team aus folgenden Mitgliedern:

• Service Level Manager• Provider Manager• Administratoren• Second/Third Level Support• Prozessberater• Technischer Berater• Entwickler• …

5.3 der Service coAch

Der Service Coach ist eine Rolle, die in klassischen IT Service Management Frameworks nicht vorgese-hen ist. Die bekannten Frameworks fokussieren auf traditionelle Managementprinzipien und setzen ent-sprechende Mechanismen wie Planung und Vorgabe, Prozess- und Aufgabenbeschreibungen sowie Füh-rungs- und Kontrollinstanzen ein. Der Service Coach unterstützt die Organisation und sein Service Team ohne hierarchische Macht und Befugnisse auf dem Weg zu einer serviceorientierten IT. Auf der Basis der agilen Werte und Prinzipien entwickelt er das Service


PeRSönlIcHeS coMMITMenT

Commitment ist die Selbstverpflichtung zur Erledigung einer Aufgabe oder Mission, um Verlässlichkeit und Motivation zu erhöhen. Jeder, der in seiner täglichen Arbeit diese Verantwortung übernimmt, muss sich bei der Erfüllung der damit verbundenen Pflichten verschreiben.

itSM 34 | 11 • 201522

Team im IT Service Management weiter und steigert schrittweise die Reifegrade der Prozesse und die Leis-tungsbereitschaft sowie -fähigkeit des Service Teams.

Er hilft dem Service Owner und dem Service Team insbesondere durch die konsequente Umsetzung einer kontinuierlichen Verbesserung bei der Erfül-lung der Aufgaben und in der Prozessgestaltung. Ein guter Service Coach sieht sich als Servant Leader für die Organisation und entwickelt die Vertrauens- und Kommunikationskultur weiter.

5.4 dAS Service-boArd

Um die Zusammenarbeit des Service Teams zu orga-nisieren und Erfahrungen mit der Anwendung von agilen Methoden zu sammeln, empfi ehlt sich die Nut-zung eines Kanban-Boards. Dieses Board ist als zent-raler Ort zu sehen, der das Service-Team zusammen-bringt und alle relevanten Aktivitäten rund um den betreuten IT Service darstellt. Meine persönlichen Erfahrungen und praktischen Erfolge mit einer täg-lichen Abstimmung anhand eines Boards unterstrei-chen die Notwendigkeit, dieses Service Board analog und für alle sichtbar zu führen.

Das Service Board schafft Transparenz über die Tätig-keiten des gesamten Service Teams. Dabei kann der bestehende Prozess des Teams sehr schnell und fl exibel abgebildet werden. In den Spalten werden bspw. verschiedene Status dargestellt. UND Sinnvoll sind einfache Regelungen im Team, die neben dem Service-Board platziert werden. In den Zeilen können die ITSM-Prozesse geführt werden oder alle betreu-ten Services aufgelistet sein. Sinnvoll sind einfache Regelungen der Zusammenarbeit im Team, die neben dem Service-Board sichtbar platziert werden.

Die Ausrichtung einer Organisation an agilen Prin-zipien führt wie schon beschrieben zu einer Verän-derung der Arbeitsweise und Unternehmenskultur. Sichtbares Beispiel hierfür ist die Einführung des Pull-Prinzips. Arbeiten werden nicht mehr den ein-zelnen Personen zugeteilt (Push), sondern vom Ser-vice Team bzw. den Mitgliedern gezogen (Pull). Die Arbeitseinteilung erfolgt also selbstorganisiert. Dazu ist eine permanente Vorbereitung und Steuerung der Arbeit durch den Service Owner notwendig.

Die fünf zentralen Kanban-Praktiken bieten an die-ser Stelle über das Service Board eine akzeptierte Grundlage zur Optimierung bestehender IT-Prozesse. Die schnelle und individuelle Umsetzung bietet IT-Managern und Führungskräften Quick-Wins bei der Prozessoptimierung.

6 fiTSM ALS ALTernATive zu iTiL®?

Zu Beginn des Artikels wurde die Frage in den Raum gestellt, ob Best-Practice-Ansätze wie ITIL® noch aus-reichend für die Lösung der aktuellen Herausforde-rungen sind. Das nach eigenem Anspruch leichtge-wichtige IT Service Management Framework FitSM hat als Zielsetzung die Beschreibung eines klaren, prag-matischen und erreichbaren Standards für effek-tives IT Service Management. Mit dem Fokus auf 14 Prozesse, die sehr nahe an der ISO20.000 entstan-den sind, formuliert es eine Grundlage, die übersicht-lich und greifbar ist. Eine IT-Organisation kann FitSM daher sehr gut als praxisnahe Baseline nutzen, die zunächst einfacher zu erreichen ist und dann schritt-weise ausgebaut und weiterentwickelt wird. Dies kann anhand der empirischen Prozesssteuerung erfolgen.

Daneben formuliert FitSM im Unterschied zu ITIL® übergreifende und prozessbezogene Anforderungen an ein IT Service Management, die es der nutzen-den IT-Organisation sehr leicht machen, die konti-nuierliche Verbesserung anhand von Reifegradstufen selbstbestimmt vorzunehmen1). Diese Anforderungen können vom Service Coach genutzt werden, um die eigene Organisation im Sinne der empirischen Pro-zesssteuerung schrittweise zu entwickeln.

FitSM fordert beispielsweise „Ein Service Katalog muss gepfl egt werden.“ und formuliert die Reifegrade mit folgenden Beschreibungen:

1) Weitere Information im Blogbeitrag „FitSM - Konkur-renz oder ergänzung zu ITIl®?“ unter www.dsoellner.de/blog/35-fi tsm-konkurrenz-oder-ergaenzung-zu-itil


Abb. 3: Das Service Board zur Steuerung der Arbeit des Service Teams und zur Schaffung von Transparenz.

23itSM 34 | 11 • 2015


• Ad-hoc: Der Service Provider kann seine Angebote an die Kunden kommunizieren. Die Beschreibungen sind eher technisch geprägt als dass sie den Nutzen für den Kunden aufzeigen.

• Repeatable: Es existiert eine Liste von Angebo-ten an Kunden, die grob in logische (im Sinne von Nutzen) Bereiche aufgeteilt ist. Die Verant-wortung für die Pfl ege ist auf einer informellen Basis geregelt.

• Defi ned: Es existiert ein Servicekatalog, der ein-deutig verschiedene Angebote für Kunden bein-haltet. Diese Angebote zeigen den Nutzen für den Kunden auf. Die Pfl ege ist eindeutig geregelt.

Das agile Prinzip „Kundenzufriedenheit durch konti-nuierliche Lieferung“ kann im Dialog zwischen Kunde, Anwender und Service Team umgesetzt werden. Ein Service Katalog muss nicht sofort als Hochglanzbro-schüre mit modernem Webportal geschaffen werden, wenn das zu erreichende Ziel gemeinsam formuliert und festgelegt ist sowie der Weg durch das Service Team beschritten und den Service Coach begleitet wird.

Mit dieser im Framework geregelten Vorgabe kann zunächst ein eher technisch orientierter Serviceka-talog erstellt werden, der später bei Bedarf mit Nut-zenaussagen und eindeutiger Verantwortung ergänzt werden kann. Für den Reifegrad „Ad-hoc“ ist die Mitarbeit des Kunden nicht notwendig, für den Rei-fegrad „Defi ned“ ist er in der Pfl icht, den Nutzen zu formulieren.

7 AuSbLick

Die in diesem Artikel beschriebenen Gedanken sollen einen ersten Einstieg und Überblick über die Mög-lichkeiten geben, das IT Service Management agiler zu gestalten. Sie sind in der Praxis nicht immer leicht umzusetzen. Neben der Veränderung der Unterneh-menskultur müssen Führungsprinzipien angepasst und letzten Endes die Organisation verändert werden. Agile Prinzipien wie die „Einfachheit“ dürfen jedoch nicht als Entschuldigung für fehlende Ordnungsmä-ßigkeit herhalten, eine gewisse Grund-Governance muss erhalten bleiben.

Eine vielleicht noch größere Herausforderung sind die Mitarbeiter. Um agil zu arbeiten braucht es kla-rere Regeln als in der klassischen Organisationsform und vor allem mehr bzw. andere Führung: „Selbstor-ganisation braucht Führung!“ Die eingangs formulier-ten Schwierigkeiten im IT Service Management soll-ten Grund genug sein, darüber nachzudenken, alte Denkmuster zu hinterfragen und sich auch von alten Gewohnheiten zu trennen.

Mit Blick auf den Titel dieses Beitrages empfehle ich, die IT-Organisation einmal zu entkalken und die in der täglichen Praxis etablierten Abläufe von unnöti-gen Resten zu befreien (to descale [engl.]: entkalken, abschuppen). Der Strategieexperte Matthias Kolbusa (http://kolbusa.de/) formuliert das treffend so:

DIeRK SöllneR ist seit 1992 als Berater, Trainer und Coach in verschiedenen Posi-tionen bei IT-Dienstleistern und IT-Beratungsunternehmen aktiv gewesen. Seit 2011 unterstützt er mit dieser Erfahrung unter dem Motto „Dierk Söllner vereint erfolgreich Business und IT“ als selbständiger Berater in zahlreichen Projekten und Schulungen zum IT Service Management, zum agilen Projektmanagement und im Business Process Management.

[email protected]

WWW.DSoellneR.De

„was uns wirklich weiterbringt sind nicht Meetings, Planung und Kontrolle, sondern Mut, Geschwindigkeit und Konsequenz. In sich verändernden Märkten brauchen wir weniger „Geschwätz“, keine lippenbekennt-nisse, keine unnötige Komplexität. Dafür mehr Klarheit und Aufrichtigkeit im Miteinander und mehr Kon-sequenz im handeln.“

lITeRATUR / lInKS:[Sutherland/Schwaber 2013] www.scrumguides.org

fachzeitschrift fÜr die itsm˜community …...itsm 34 | 11 • 2015 19 ist (in scrum ist das die...

Documents