• Blog
  • De-scale your Organization

De-scale your Organization

Anhand von ausgewählten agilen Prinzipien wird in diesem Blog aufgezeigt, wie IT Service Management nachhaltig vereinfacht und neu ausgerichtet werden kann. Dieser Beitrag ist im itSM-Magazin des itSMF Deutschland e.V. im Heft 34 (November 2015) erschienen. Das gesamte Heft "Agilität im IT Service Management" kann im itSMF-Shop erworben werden. pdfArtikel aus ITSM1.77 MB

Es wird gezeigt, wie "Empirische Prozesssteuerung" 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 vorgestellt. Abschließend wird das leichtgewichtige ITSM-Framework FitSM vorgestellt, welches eine interessante und erreichbare Basis für ein agiles IT Service Management bietet.

Aktuelle Herausforderungen im IT Service Management

Die Etablierung der IT als verlässlicher Partner und Dienstleister des Business ist lange Zeit mit der Einführung von IT Service Management Frameworks unter dem Stichwort "Best-Practice" vorangetrieben worden. Bei allen vorzeigbaren Erfolgen dieser Bemühungen sind Kunden und Anwender immer noch unzufrieden und stellen immer höhere Anforderungen 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 Zufriedenheit der IT-Mitarbeiter stark gesunken und unterstützt damit nicht die Erwartungen und Forderungen an und von modernen Mitarbeitern.

IT-Organisationen haben auf der Basis von Best Practice-Ansätzen wie ITIL® viel Arbeit zur Etablierung von IT Service Management geleistet. Die umfangreichen 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 Textbox 1) aus dem Mai 2015 zeigt das Dilemma. Das Unternehmen (weltweit agierender Pharmakonzern) hat ein mächtiges Tool für IT Service Management im Einsatz, zahlreiche spezialisierte Partner eingebunden, Vereinbarungen bzw. Verträge nach Lehrbuch, durchoptimierte Prozesse und sogar regelmäßige Messungen der Servicequalität.

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 (specific for different services)
- vendor (usually only doing bug-fixing, 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 optimise 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 inefficiencies - and being more efficient in the monitoring of the processes.

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 Kosten. Die Kunden bzw. Anwender bemängeln unter anderem:

  • 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

Empirische Prozesssteuerung statt Best Practice

Die aufgeführten Herausforderungen zeigen deutlich, dass Best Practice Ansätze aktuell nicht immer eine Lösung anbieten. Sie müssen für den erfolgreichen Einsatz in der Praxis hinterfragt, ergänzt oder modifiziert 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 Unternehmenskultur eingebettet.

Agile Methoden setzen demgegenüber häufig auf das Prinzip der „Empirischen Prozessteuerung“. Dabei wird Wissen aus Erfahrung gewonnen und Entscheidungen werden auf Basis des Bekannten getroffen. Der Ansatz, Erfahrungen anderer Unternehmen in die eigene IT-Organisation zu kopieren, wird gegen das schrittweise Lernen und eigenes Verbessern getauscht. Vorschläge und Anregungen aus anderen Frameworks können übernommen werden. Wichtig ist jedoch, dass das überschaubar bleibt und die eigenen Erfahrungen und Lernzyklen nur ergänzt.

Jede Implementierung von empirischer Prozesssteuerung ruht auf drei Säulen, nämlich Transparenz, Überprüfung und Anpassung.descale empirie

Transparenz

Die Forderung nach Transparenz verlangt mehr Sichtbarkeit 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 ist (im Scrum ist das die „Definition of Done“). Dieses gemeinsame Verständnis wird kontinuierlich weiterentwickelt und bei der Lieferung des IT Services zur Abnahme durch den Kunden angewendet. Aus ITIL® lassen sich dazu die Service Acceptance Criterias heranziehen. Wichtig ist, dass diese Transparenz gemeinsam zwischen IT Service produzierenden und akzeptierenden Personen geschaffen wird und kontinuierlich herzustellen ist.

Ü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 Überprü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 erfolgen muss. Das reduziert die Inhalte der Überprüfung auf das Wesentliche. Kennzahlen oder Berichte orientieren sich am gemeinsamen Ziel (Servicevereinbarungen) und nicht an technischen Möglichkeiten des Reporting oder der „Selbstbeweihräucherung der IT(-Manager)“.

Anpassung

Sobald festgestellt wird, dass akzeptable Grenzwerte überschritten werden und beispielsweise IT Services nicht vereinbarungsgemäß geliefert werden können oder Prozesse ungenügende Ergebnisse liefern, muss der Prozess oder der Prozessinput angepasst werden. Diese Anpassung muss schnellstmöglich erfolgen. 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 Leistungserbringung gestartet wird.

Empirische Prozessteuerung im IT Service Management

Die Empirische Prozesssteuerung wird in der Praxis des agilen Projektmanagements an konkreten Ereignissen und Terminen festgemacht. Im IT Service Management sind daher regelmäßige Termine einzurichten (siehe Kapitel „Die neue Service Organisation“), 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.

Ü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 Produktentwicklung (bspw. Sutherland/Schwaber für Scrum, Beck/Jeffries/Fowler für Extreme Programming und Cockburn für Crystal Clear) im Jahre 2001 auf eine gemeinsame Basis für ihre Ansätze geeinigt. Das Agile Manifest dient allen Methoden als anerkannte, kollektive Grundlage und vereint damit teilweise inhaltlich unterschiedliche Frameworks. Neben den Kernaussagen sind 12 Prinzipien formuliert, die wichtige Eckpfeiler im agilen Projektmanagement bilden und an dieser Stelle auszugsweise auf das IT Service Management übertragen und angewendet werden.

Kundenzufriedenheit durch kontinuierliche Lieferung

Das Agile Manifest formuliert unter anderem das Prinzip „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ und stellt damit die Kundenzufriedenheit in den Vordergrund. Diese soll durch kontinuierliche Lieferung wertvoller 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 Festlegung der Leistungsinhalte beteiligt sind und konkret 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 Ausrichtung an den Wünschen der Anwender weiterentwickelt werden. Das bedeutet, dass konkrete Leistungen zwischen Erbringer und Abnehmer des IT Services zu vereinbaren sind sowie auf einem erreichbaren und geforderten Niveau starten.

Motivierte Individuen

Ein weiteres Prinzip des Agilen Manifests lautet: „Errichte Projekte rund um motivierte Individuen. 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 Mitarbeiterführung stärker auf den Menschen ausgerichtet und ein neues Verständnis von Zusammenarbeit 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ützung 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 konkretisiert den Rahmen. Der Service Coach übernimmt in diesem Zusammenhang eine wichtige Aufgabe, denn er beseitigt die Hindernisse für das Team.

Funktionierende Software

Im Agilen Manifest wird gefordert: „Funktionierende Software ist das wichtigste Fortschrittsmaß“. Damit wird unterstrichen, dass das Ergebnis der Arbeit in der IT funktionieren muss, d.h. 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 dieses 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 Service-Team steht für die Einhaltung der Service-Level und sichert das als Team (Commitment) zu.

Einfachheit

Im Agilen Manifest findet sich auch das Prinzip: „Einfachheit - die Kunst, die Menge nicht getaner Arbeit zu maximieren - ist essenziell.“, welches mein persö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-Prinzip: You ain’t gonna need it.).

Im IT Service Management heißt das unter anderem, 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.

Verbesserung im Team

Die kontinuierliche Verbesserung wird im Agilen Manifest folgendermaßen formuliert: „In regelmäßigen Abständen reflektiert 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 Prozesseffizienz und –effektivität. Das CSI Register wird in diesem Fall permanent mit Leben gefüllt und die Arbeit damit an die Service Teams übertragen.

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 Orientierung 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.
Die Abbildung zeigt die Rollen Service Owner, Service Coach und Service Team, die zusammen an der Erbringung des Services arbeiten.Descale Service Team

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 entsprechende IT Services. Im Idealfall hat er eine unternehmerische Verantwortung für seinen Service. Eine hierarchische Weisungsbefugnis gegenüber dem Service Team würde den agilen Prinzipien widersprechen. Der Service Owner steuert die Aufgaben über eine Priorisierung in das Team ein, die selbstorganisiert die Aufgaben übernehmen.

Im generischen Rollenmodell von FitSM ist der Service Owner als eine zentrale Rolle beschrieben, der an den Gesamtverantwortlichen 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übergreifend) 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 Kunden und betreut den IT Service als Produktmanager und hat ggfs. unternehmerische Aufgaben. Diese Rolle sorgt für die Orientierung an wertvollen Service-Inhalten und die Erfüllung der Kundenanforderungen. Der Inhaber betreut seinen Service aktiv und übernimmt mehr Verantwortung sowie persönliches Commitment für diesen Service.

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

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 beauftragt werden können.

Um das Commitment des Service Teams zu unterstützen wirkt es bei der Gestaltung von SLAs mit und bestimmt somit maßgeblich, was im SLA vereinbart 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
  • ...

Der Service Coach

Der Service Coach ist eine Rolle, die in klassischen IT Service Management Frameworks nicht vorgesehen ist. Die bekannten Frameworks fokussieren auf traditionelle Managementprinzipien und setzen entsprechende Mechanismen wie Planung und Vorgabe, Prozess- und Aufgabenbeschreibungen sowie Führungs- 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 Team im IT Service Management weiter und steigert schrittweise die Reifegrade der Prozesse und die Leistungsbereitschaft 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üllung 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.

Das Service-Board

Um die Zusammenarbeit des Service Teams zu organisieren und Erfahrungen mit der Anwendung von agilen Methoden zu sammeln, empfiehlt sich die Nutzung eines Kanban-Boards. Dieses Board ist als zentraler Ort zu sehen, der das Service-Team zusammenbringt und alle relevanten Aktivitäten rund um den betreuten IT Service darstellt. Die vielen praktischen Erfolge mit einer täglichen Abstimmung anhand eines Boards unterstreichen die Notwendigkeit, dieses Service Board analog und für alle sichtbar zu führen.

descale  serviceboardDas Service Board schafft Transparenz über die Tätigkeiten des gesamten Service Teams. Dabei kann der bestehende Prozess des Teams sehr schnell und flexibel abgebildet werden. In den Spalten werden bspw. verschiedene Status geführt. In den Zeilen können die ITSM-Prozesse geführt werden oder alle betreuten Services aufgelistet sein. Sinnvoll ist einfache Regelung der Zusammenarbeit im Team, die neben dem Service-Board platziert wird. Die Ausrichtung einer Organisation an agilen Prinzipien führt wie schon beschrieben zu einer Veränderung der Arbeitsweise und Unternehmenskultur. Sichtbares Beispiel hierfür ist die Einführung des Pull-Prinzips. Arbeiten werden nicht mehr den einzelnen Personen zugeteilt (Push), sondern vom Service 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 dieser 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.

FitSM als Alternative zu ITIL®?

Zu Beginn des Artikels wurde die Frage in den Raum gestellt, ob Best-Practice-Ansätze wie ITIL® noch ausreichend für die Lösung der aktuellen Herausforderungen sind. Das nach eigenem Anspruch leichtgewichtige IT Service Management Framework FitSM hat als Zielsetzung die Beschreibung eines klaren, pragmatischen und erreichbaren Standards für effektives IT Service Management. Mit dem Fokus auf 14 Prozesse, die sehr nahe an der ISO20.000 entstanden sind, formuliert es eine Grundlage, die übersichtlich und greifbar ist. Eine IT-Organisation kann FitSM daher sehr gut als praxisnahe Baseline nutzen, die zunächst einfacher zu erreichen ist und dann schrittweise 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 nutzenden IT-Organisation sehr leicht machen, die kontinuierliche Verbesserung anhand von Reifegradstufen selbstbestimmt vorzunehmen[1]. Diese Anforderungen können vom Service Coach genutzt werden, um die eigene Organisation im Sinne der empirischen Prozesssteuerung schrittweise zu entwickeln.

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

  1. 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.
  2. Repeatable: Es existiert eine Liste von Angeboten an Kunden, die grob in logische (im Sinne von Nutzen) Bereiche aufgeteilt ist. Die Verantwortung für die Pflege ist auf einer informellen Basis geregelt.
  3. Defined: Es existiert ein Servicekatalog, der eindeutig verschiedene Angebote für Kunden beinhaltet. Diese Angebote zeigen den Nutzen für den Kunden auf. Die Pflege ist eindeutig geregelt.

Das agile Prinzip „Kundenzufriedenheit durch kontinuierliche Lieferung“ kann im Dialog zwischen Kunde, Anwender und Service Team umgesetzt werden. Ein Service Katalog muss nicht sofort als Hochglanzbroschüre mit modernem Webportal umgesetzt 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.

descale service katalogMit dieser im Framework geregelten Vorgabe kann zunächst ein eher technisch orientierter Servicekatalog erstellt werden, der später bei Bedarf mit Nutzenaussagen und eindeutiger Verantwortung ergänzt werden kann. Für den Reifegrad „Ad-hoc“ ist die Mitarbeit des Kunden nicht notwendig, für den Reifegrad „Defined“ ist er in der Pflicht, den Nutzen zu formulieren.

Ausblick

Die in diesem Artikel beschriebenen Gedanken sollen einen ersten Einstieg und Überblick über die Möglichkeiten geben, das IT Service Management agiler zu gestalten. Sie sind in der Praxis nicht immer leicht umzusetzen. Neben der Veränderung der Unternehmenskultur müssen Führungsprinzipien angepasst und letzten Endes die Organisation verändert werden. Agile Prinzipien wie die „Einfachheit“ dürfen jedoch beispielsweise 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 klarere Regeln als in der klassischen Organisationsform und vor allem mehr bzw. andere Führung: „Selbstorganisation braucht Führung!“

Die eingangs formulierten Schwierigkeiten im IT Service Management sollten 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ötigen Resten zu befreien (to descale [engl.]: entkalken, abschuppen).

Der Strategieexperte Matthias Kolbusa formuliert das treffend so:

„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 Lippenbekenntnisse, keine unnötige Komplexität. Dafür mehr Klarheit und Aufrichtigkeit im Miteinander und mehr Konsequenz im Handeln.“