“Make or Buy” Reloaded – A Business View on Cloud Computing

I remember 14 years ago – my early IT days, I was at IBM. We built CRM solutions based on the newly released Siebel 7 Web platform. These were solutions suddenly available anytime, anywhere, and easily on demand for new businesses.

10 years later the same buzz was called ‘Software as a Service’ or ‘private Cloud’. I was glad it finally got a name.  In the meantime there has been a lot of progress on virtualization, automation & the ‘Internet anywhere’. The cloud will soon reach it’s plateau of productivity. Also – after first ‘cloudiness’ – we have now a precise and common understanding what the cloud actually is (with all it’s various flavors: Private, Hybrid, Public, SaaS, IaaS and so on). We start to get an understanding on how to manage it and what the cloud means to us.  No doubt, the cloud will change the way IT will deliver its services: Increasingly, we will source these services out of the cloud, just think about the simple example ‘Google Mail for corporations’. But I will not bore you with that, there has been written a lot about this topic – after all, certain things have become a no-brainer, isn’t it? Looking at the cloud scene, I think one issue is that the cloud discussion is very much driven by an ‘inside-out’ view (the view of the cloud providers and IT-departments). But what does the cloud actually mean from a pure company perspective? What does it matter for them? Putting the security & compliance arguments aside for the moment, my hypothesis is that for the business, cost & time to market is at the end the driver to go for the cloud. Secondly, I think companies should be careful with the core processes, which differentiate them in the market – in this area standardization can completely kill their business.

So I hope I can open some new perspectives in my blog and hope you spend your valuable time reading them.

Cloud: the Inside-out view

Recently I was lucky to be part of two solution implementations, both in the ITSM tool area and with very similar scope, but one of them the traditional way and the other one with a SaaS/PaaS Cloud solution. Both I took care end-to-end, from evaluation, to design, until making sure that it is run as a Service. The perfect case for comparison, here is what I experienced:

  • The first difference was that in the cloud project, the whole operation part was gone. The solution was developed & run completely on a remote web platform, delivering out-of-the box 95% of the functionality we needed.  No thinking needed on how to host the platform. Also, traditional Service Design warranty aspects like capacity & availability have become obsolete, they were delivered by the cloud solution already on a very high level (with actually no ability to influence it).
  • What was the same? Both, cloud and traditional solution needed a proper governance & project around it, including requirements engineering, build and test.
  • However, in the cloud project, we were very much driven by the standard, that was delivered by the solution out-of the box. This of course had an influence on how we defined requirements

So out of practice I can only agree what has been written about the cloud. From an IT department view many things have become really easy and from a motivational point of view I had the feeling to focus myself on the more ’interesting’ stuff. The example I showed above is rather typical for PaaS  (Plafform as a Service) environment, offering a high degree of flexibility for the solution that is actually built on it. Today, a lot of the business is around SaaS (Software as a Service), the solutions delivered to the business are  ‘take it or leave it’ – this is a different flavor of cloud: standardized, industrialized solutions with not much customization possible. The perfect example is the e-mail service. Just to show you again the differences between the delivery models, there are 3 ways to deliver eMail Service:

  • The ‘traditional’ way: Completely run the e-mail service on your own in own premises
  • Classic outsourcing: An outsourcing provider runs the service for you
  • Cloud sourcing: You just use e.g. Google Mail and pay a monthly fee, including everything

So what are the consequences of the cloud from an inside-out perspective? IT departments will ‘shrink’ very much, there will be a general shift of Service Operation – and partly Service Transition staff – from the IT departments to the cloud providers (as they have to run everything in the future). The role of the IT department will be very much focused on Cloud Brokerage – sourcing the right IT Services from the cloud and making sure the Governance around it. Having the right Target Operating Model for that is key. The blogs of my colleagues Martin Andenmatten and Ben Martin give a very good insight into that.

Cloud: the outside-in view

Let’s now change the perspective and take a pure coprorate view. Simply speaking, the role of IT is to support business processes by delivering IT services that suit their needs. Beyond that, IT is (and should be) a black box for the business. So what’s the difference for the business having an in-sourced vs a cloud-sourced service? Well, nothing, at least from a quality point of view. With an insourced IT Service you can practically deliver towards the business the same service as in the cloud-based service (and the same time to market if you put enough money in it). For the business it’s actually not transparent where the IT Service comes from. Just think about the e-mail example. However, the big differentiator is cost. In most cases, the equivalent cloud service is much cheaper. So purely outside-in speaking the argument is cost.

I recently came across an impressive graph, which showed me that even in the vertical markets (industries) you can get a cloud solution for almost everything:

Vertical Cloud Solutions. (c) forbes.com 2014

Vertical Cloud Solutions. (c) forbes.com 2014

And above graph even does not show the horizontal solutions, which cover industry independent areas like HR, Finance and collaboration (That one would be probably twice as big).

So going back to the cost argument and looking at above graph– one logical conclusion would be that all IT Services go into the cloud. Maybe – but there is one additional thing to consider: The problem of standardization. For all processes, which look very similar across all companies and which do not play a differentiator (typically the support processes), going to standard is fine, going to cloud is perfect. You can gain a lot of efficiency there and align to Best Practice. However, for core processes, actually making up your business model, you shouldn’t do this, you need to make the difference. There might be an underlying IaaS or PaaS, but I never would use a standard Software as a Service (SaaS). This also reveals the double role of IT: On the one hand the traditional CIO-role, which is transforming to the Cloud Service Broker, on the other hand the emerging Chief Digital Officer, which acts as an enabler for the business. Both together will be the IT dream team of the future. I used the well-known ‘make or buy’ matrix and added these two roles (red) to illustrate this:

'Make or Buy' and the future double role of IT

‘Make or Buy’ and the future double role of IT

Wandel von der IT-Abteilung zum Service Broker

Aus MSM Studie: Studie Cloud Computing 2.0 – der Schweizermarkt bis 2016

Aus MSM Studie: Studie Cloud Computing 2.0 – der Schweizermarkt bis 2016

Die aktuellen Trendzahlen des MSM Research zur Entwicklung des IT Marktes bestätigen, was die Spatzen schon lange vom Dach pfeifen. Cloud Computing ist nicht mehr aufzuhalten und verdrängt nicht bloss die traditionelle interne IT sondern auch das klassische Full-Outsourcing. Der Paradigmawechsel im ICT-Betrieb wird zur Tatsache.

Wie war die Welt noch in Ordnung, als vor Jahren die interne IT noch ihren festen Bestandteil eines aufstrebenden Unternehmens war.

Traditionelle IT - da war alles noch im Griff

Traditionelle IT – da war alles noch im Griff

Der SW-Ingenieur und der Projektleiter waren die Helden, welche mühseligen Arbeitsabläufe in Programme gossen und die Abwicklung der Geschäftstransaktionen automatisierte. Der Betrieb war akzeptabel und die Abhängigkeit der IT hielt sich noch in Grenzen.

Aber die Welt hat sich gedreht. Mobilität, BYOD, BigData und eben auch IT aus der Steckdose sind heute Realität. Wie eine finstere Bedrohung werden die neuen Trends innerhalb der IT-Organisationen wahrgenommen und nach allen möglichen Abwehrargumenten gesucht, um das Unvermeintliche möglichst lange abzuhalten.

Unkontrollierte IT

Unkontrollierte IT

10 Cloud-Mythen gemäss Gartner
Gartner hat in einem aktuellen Beitrag die 10 grössten Märchen rund um Cloud Computing aufgelistet: http://www.gartner.com/newsroom/id/2889217

  • Mythos 1: Mit Cloud kann man immer Geld sparen
  • Mythos 2: Um gut zu sein, muss man in der Cloud sein
  • Mythos 3: Cloud soll für alles verwendet werden
  • Mythos 4: “Der CEO will es” ist eine Cloud-Strategie
  • Mythos 5: Wir brauchen EINE Cloud-Strategie oder Anbieter
  • Mythos 6: Cloud ist weniger sicher als Vorort-Installierte Systeme
  • Mythos 7: Cloud ist nicht für business-kritische Anwendungen
  • Mythos 8: Cloud ist nichts anderes als ein Datacenter
  • Mythos 9: Durch die Migration in die Cloud werden automatisch alle Cloud-Charakteristiken vererbt
  • Mythos 10: Virtualisierung ist gleichzusetzen wie Private Cloud

Das Verständnis, was Cloud Computing wirklich ist, ist grösstenteils noch unterentwickelt. Cloud ist längst keine technische Raffinesse mehr – es ist eine neue Computer-Revolution, wie künftig IT-Services bereitgestellt werden. Das Thema darf nicht mehr den technischen System-Administratoren alleine überlassen werden. Es ist die Pflicht des IT-Managements, sich mit der Thematik ernsthaft auseinander zu setzen und die Chancen und Risiken für das Unternehmen verantwortungsvoll aufzuarbeiten. Lesen Sie dazu auch unseren Beitrag “Gute Gründe für einen sicheren Weg in die Cloud“.

Und sie dreht sich doch…
Die Realität ist nicht aufzuhalten. Das Business will von den neuen Technologien profitieren und holt sich den Service halt selber. Schatten-IT’s sind die Folge, welche oft nicht einer zentralen Kontrolle unterstellt sind und damit ein unkontrolliertes Risiko für das gesamte Unternehmen darstellen.

Das damit das operationelle Risiko von Unternehmen zunimmt, entgeht auch nicht den offiziellen Regulatoren. Immer stärker werden nun Unternehmen verpflichtet, die Einhaltung der Richtlinien, insbesondere auch der rechtmässigen Abwicklung von Geschäftstransaktionen, der Datensicherheit- und Datenschutz-Bestimmungen zu prüfen und entsprechende Kontrollen einzurichten. Dadurch muss das interne Kontrollsystem (IKS) erweitert und auf die Überwachung der ordnungsmässigen Zusammenarbeit der externen Provider ausgerichtet werden.

Der künftige Service-Broker
Das künftige Rollenbild innerhalb der IT-Organisation wird sich verändern. Teilweise sogar dramatisch. Es ist ein schleichender, aber nicht aufzuhaltender Prozess. Die technischen Ingenieure werden nach und nach aus den Unternehmen verschwinden, da ihre Leistungen nun von externen Partnern erbracht werden. Infrastrukturen kann man intern nicht mehr konkurrenzfähig bereitstellen.

IT under Control

IT under Control

Wenn Unternehmen mehr und mehr Teile ihrer IT extern auslagern, sei es in die Cloud oder zu einem Sourcing-Provider, muss es jemanden geben, welcher die Schnittstelle zwischen den beiden Parteien wahrnimmt. Es braucht eine kompetente Stelle, welche die mehr und mehr extern betriebenen Service-Bestandteile zu einem ganzheitlichen Service orchestriert und die Qualität, Sicherheit, Compliance und Performance auf der gesamten Supply-Chain sicherstellt.

Erfolgreiches Sourcing oder Cloud-Computing startet nicht mit der Technologie. Vielmehr startet es mit einem klaren Blick auf das Service Management als oberste Management-Disziplin einer intern verbleibenden IT-Organisation.

Es braucht zwei “Eltern”-Teile, um ein Cloud-Computing-“Kind” “grosszuziehen”:

  • Service LifeCycle Management und dessen Prozesse (siehe ITIL®), beginnend mit der Service Strategy und dem bereits erwähnten Service Portfolio Management Prozess sowie den übergreifenden Lebenszyklus-Phasen Service Design, Transition, Operation und kontinuierliche Verbesserung.
  • Sourcing LifeCycle Management und seinen Aktivitäten-Stufen beginnend mit einer Sourcing-Strategie, Lieferantenauswahl, Transition, Operation und Vertrags-Management  (siehe auch OPBOK – Outsourcing Professional Body of Knowledge)

Diese beiden Disziplinen müssen miteinander “verheiratet” werden. Dies liegt in der Verantwortung des CIOs. Cloud Computing ohne diese beiden Rahmenbedingungen ist wie Finanzmanagement ohne Buchhaltung.

Und dies muss die Vision der verbleibenden IT-Organisation sein. Die Zukunft findet nicht nur in der Wolke statt – sie findet genauso in den Unternehmen statt, welche die Klaviatur des Service Brokerage beherrschen. IT-Organisationen sind gut beraten, sich auf dieses Szenario vorzubereiten. Und externe Cloud- oder Service Provider müssen sich auf reife Kunden einstellen, welche ihnen genauer auf die Finger schauen.

Einen wunderbaren Artikel dazu habe ich im Blog von Information Age gefunden: Out of service: when yesterday’s IT service management meets today’s world. Es wird höchste Zeit, sich dem Thema Service Management und Customer Experience ernsthafter auseinander zu setzen.


Service Design Package – die unbefleckte Perle von ITIL®

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

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

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

SDP als zentrales Lieferobjekt in der Service Entwicklung

SDP als zentrales Lieferobjekt in der Service Entwicklung

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

SDP - der Rote Faden durch den Service LifeCycle

SDP – der Rote Faden durch den Service LifeCycle

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

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

SDP Operation Dokumente

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

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

    SDP Projekt Dokumente

    SDP Projekt Dokumente

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

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

Service Design Organiation

Service Design Organiation

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

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

  • Design Coordination Prozess

    Design Coordination Prozess

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

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

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

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

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

SDP - die umbeflekte Perle im ITSM

SDP – die umbeflekte Perle im ITSM

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



DevOps, Agile Development, Continuous Delivery und ITIL: Was gibt es für Zusammenhänge und wie man sie nutzen kann

Die traditionelle IT, viele ihrer Methoden, Strukturen und Vorgehensweisen sind nicht mehr zeitgemäss. Die von Kunden und Business gewünschten IT Capabilities, wie Time-to-Market, Innovation und Agilität bei gleichzeitigem Kosten-, Qualitäts- und Compliance-Management sind so nicht machbar. Silomentalität, Prozess-Bürokratie, Technologie- statt Kundenfokussierung werden abgelöst durch neue Servicemodelle (Cloud), Agile Projektmanagement-Methoden, neue Zusammenarbeitsmodelle zwischen Development und Operation und durch die durchgängige Automatisierung von Prozessen.

Welche neuen Konzepte und Strukturen gibt es, wie hängen sie zusammen und welche Rolle spielt “good old” ITIL?


Der Fokus von DevOps ist Time-to-Market, d.h. schnell, und in schnellen Verbesserungszyklen Produkte und Service für Kunden bereitzustellen zu können, ohne Abstriche an Produkt – oder Servicequalitätsmerkmalen wie Sicherheit und Verfügbarkeit. Aus ITIL Sicht spannen sich DevOps Konzepte über die Service Lifecycles Service Design, Service Transition , Service Operation und Continual Service Improvement. DevOps Konzepte gehen eher von taktischen Service- und Produktanforderungen aus, d.h. es gibt ein existierendes Service Portfolio mit etablierten Services und Produkten, die ständig erweitert und verbessert werden. Die Entwicklung neuer Services und Servicestrategien sind nicht Bestandteil dieses Konzeptes, d.h., die ITIl Service Strategie Prozesse sind komplementär.


Agile Development

Agile Development Konzepte gibt es schon länger, Scrum ist ein Beispiel dafür. Mein Kollege Alex Lichtenberger hat in seinem Blog “Integrating Agile and ITSM” auf den Zusammenhang von Agilen Projektmethoden und ITSM hingewiesen. Agiles Development ist auch ein wesentliches Grundelement für DevOps.


Continuous Delivery, Integration & Deployment

Andere Grundelemente für DevOps Konzepte sind Continuous Delivery mit Continuous Integration und Deployment Praktiken.

Continuous Delivery ist eine Methode der Softwareentwicklung, die Softwarequalität sicherstellt und liefert unter den Bedingungen von Schnelligkeit und hoher Release-Kadenz.  Dazu notwendig sind standardisierte automatisierte Build und Test Prozesse mit Hilfe von Continuous Integration Praktiken und standardisierte und basierend auf automatisierten Release –und Deployment Prozessen der Continuous Deployment Praktiken.


ITIL, Agility, DevOps und Continuous Delivery

Struktur in der Arbeitsteilung und Genauigkeit in der Definition sind Voraussetzungen für Geschwindigkeit, hohe Frequenz und Qualität. Diese Voraussetzungen werden geschaffen mit Prozessen. Agilität und DevOps sind keine Chaosveranstaltungen, sondern basieren auf automatisierten Prozessen. Automatisieren kann man nur, was man vorher definiert hat. Automatisierte Prozesse sind des Gegenteil von Prozessbürokratie, es fehlt die menschliche “Entschleunigung”. Automatisierte Prozesse ist IT Intelligenz gegossen in ausführbaren Maschinen-Code. ITIL bietet den exzellenten Fundus, um IT Intelligenz aufzunehmen und strukturiert zu definieren. Ausgeführt werden Prozesse von geeigneten Tools, die Softwaredesign, Entwicklung, Test, Release –und Deployment unterstützen.


ITIL ist war und ist Bestandteil der traditionellen IT. In der neuen IT Welt bildet es als einen Ausgangspunkt für Automatisierung weiterhin eine entscheidende Grundlage für Time-to-Market, Innovation und Agilität.

Die Suche nach klarer Identität im IT Service Management

Identität ist die Gesamtheit der eine Entität, einen Gegenstand oder ein Objekt kennzeichnenden und als Individuum von allen anderen unterscheidenden Eigentümlichkeiten. Analog wird der Begriff auch zur Charakterisierung von Personen verwandt. Psychologisch und soziologisch steht dabei im Vordergrund, welche Merkmale im Selbstverständnis von Individuen oder Gruppen als wesentlich erachtet werden.”

Quelle: wikipedia.de

Soweit das die Definition, was wir unter Identitiät verstehen sollten. Irgend etwas sollte uns als Individuum von allen anderen unterscheiden. Also wären wir einzigartig in unserer Identitität. Als Menschen gelingt uns das auch meistens – aber wie sieht es mit uns in der beruflichen Rolle, insbesondere in der Rolle eines IT Service Managers aus? Ich verfolge diesbezüglich seit Jahren bis heute immer wieder Presseartikel und Jobbörsen und diskutiere mit Consulting-Kunden und Academy-Teilnehmern über deren Profile. Leider wird dabei immer wieder klar, wie weit der strukturierte Ansatz von ITIL(R) vom tatsächlichen Leben entfernt scheint. Die heile Welt der ITIL(R) Rollen und Verantwortlichkeiten, die Klarheit der Zuständigkeiten und insbesondere die Definition, was ein Service Manager eben NICHT ist, scheint in der Welt da draussen noch nicht angekommen zu sein.

In einer aktuellen Stellenanzeige eines Mittelständlers finde ich zum Beispiel folgendes:

Gesucht: Mitarbeiter für den Service Desk

Beschreibung der Aufgaben:

  • Bearbeitung von Kundenanrufen und Störungen im Rahmen des Incident Managements
  • Verwaltung von Benutzerrechten und Zutrittsberechtigungen
  • Durchführen von Benutzer-Schulungen zu IT-Themen
  • Unterstützung bei der Systemadministration (Server/Clients/Software/Datenbanken)
  • Beschaffung von Informatikmitteln
  • Durchführung IMAC (install-move-add-change) von Endgeräten………

Schön – in einer mittelständischen Firma kann man sicher nicht dediziert am Service Desk sitzen und auf Anrufe warten – oder sollte man nicht doch? Wenn aber ein Servicedesk-Mitarbeiter mit dem Kleinbus und 12 PCs im Gepäck in die Filialen fährt, um PCs auszuliefern, dann fehlt er während dieser Zeit als Ansprechpartner für die Anwender. Wird hier bewusst in Kauf genommen, dass Kunden eben mal warten – oder hat der IT-Chef im Jobprofil stehen, dass er bei Bedarf im Service Desk aushilft? Sie lachen vielleicht – aber auch dies habe ich in der Praxis bereits gesehen. Und Mittelstand heisst hier nicht, dass nur 3 Leute in der IT arbeiten. Woran also liegt es, dass ein Server-Admin mit Telefonie-Kenntnissen die Anforderungen als Service Desk Mitarbeiter für manche besser erfüllt als ein ITIL(R) Foundation-geschulter, mit entsprechenden social skills und Prozessverständnis gesegneter Kommunikator?

Wenn wir uns die ITIL(R) Core-Bücher ansehen, finden wir an verschiedenen Stellen deutliche Hinweise zu Rollen im Service Management und deren Ausprägung bzw. benötigtem Skillset. Leider ist auf Anhieb keine gesamthafte Aufstellung der Rollen erkennbar. Es werden nur Fragmente erkannt oder verstanden – das BIG PICTURE eines Rolleninhabers im IT Service Management bleibt der Fantasie des HR-Managers überlassen – zumindest meistens. Und somit fällt man mit besten Voraussetzungen für eine Position unverschuldet bereits bei der ersten Runde durch das Raster, weil man eine vielleicht mit copy and paste auf die job description übernommene Fähigkeit nicht erfüllt – und der HR-Mitarbeiter dieses Zünglein an der Waage falsch interpretiert.

(C)  Eichborn-Verlag (Peter Gaymann - Gaymanns beste Hühner)

(C) Eichborn-Verlag (Peter Gaymann – Gaymanns beste Hühner)

Nach meiner Meinung gibt es hier sehr viel Potenzial, nicht nur methodisch die Durchdringung mit ITIL(R) voran zu treiben, sondern in den Köpfen der Entscheider auch mit klaren Aussagen zu Jobprofilen, Anforderungen und benötigten Fähigkeiten für Klarheit zu sorgen, welche Skillsets man sich für diese Aufgaben an Bord holen sollte. Ein Service Manager, der im mittleren Management der IT angesiedelt wird und zumindest einen ITIL(R) Intermediate Kurs erfolgreich absolviert hat, braucht einen Namen und eine offizielle Job Description (die natürlich ohne weiteres auf Unternehmensbedürfnisse adaptiert werden kann) mit möglichst dediziertem Fokus auf seine Rolle in der end-to-end Service-Erbringung. Ich würde mir in einer nächsten Version von ITIL(R) sehr wünschen, dass man die vielen privaten Anstrengungen in diese Richtung von offizieller Seite mit einem Rahmenwerk und Best Practice” zu einem gesamthaften Roles&Responsiblities-Ansatz ablöst. Denn auch die bisher veröffentlichten Stellenbeschreibungen für Beschäftigte im IT Service Management gemäss ITIL(R) weichen noch häufig voneinander ab.

Die Mitarbeiter verdienen ein rollenspezifisches Gesicht, denn dadurch verlieren sie ihre Alleinstellungsmerkmale und können sich mit eindeutigen Rollen identifizieren. Zudem wird ein Re-Employment wesentlich erleichtert.

Die Glenfis AG stellt Ihnen eine Übersicht über die wichtigsten Rollen und deren Anforderungen kostenlos zur Verfügung. Vielleicht finden diese Informationen zumindest auszugsweise auch in Ihrem Unternehmen den Weg zu den Personalentscheidern – und damit in die Stellenbeschreibungen des IT-Personals.

Hier der Link zu den Rollenbeschreibungen:





Frameworks & Standards Reality Check: Let’s ask Google Trends

In my last blog I wrote about ITSM & the Agile Manifesto, which was shortly after followed by a hype around creating an ITIL Manifesto. Coincidence? It doesn’t matter. Anyway, it’s now time to do something different, to do some solid statistical work.

So my simple question was: BPMN, ITIL, Prince2, CMMI, Six Sigma, Kanban, ISO20k (…) – What are people looking for? After having played around with Google Trends, I think this tool gives us a pretty good answer. Google Trends shows us the Google search volume for specific keywords (or topics) over the last 7 years. Don’t forget, first of all, this is ‘just’ data (and it’s BIG data), which reflects real crowd behavior.

Warning: Don't do any wrong correlations & conclusion out of the data in this blog

Warning: Don’t do any crazy correlations & conclusion out of the data in this blog

You therefore have to be careful when drawing any conclusions or doing casual analysis out of Google Trend data. Otherwise you might end up in the same situation as recently the Princeton University researchers, which made some predictions about Facebook (very funny, don’t miss this article). So basically you can read the following out of Google Trends:

  • Volume per keyword (relative to each other): This is a good indicator for overall search popularity, but not necessarily for the specific importance.
  • Trend over time: This is a very good and valid indicator. It shows the change in popularity over the last 7 years or any other shorter timespan.
  • Geography: By splitting results by country, this gives you an idea about regional differences in keyword popularity or trend
  • Keyword drilldown: Very interesting. It shows you what the people are really looking for (per keyword). E.g. ‘ITIL’ very much relates to ‘ITIL certification” or “ITIL v3”, but DevOps rather to ‘What is Devops?’

Setting the Scene: Keyword List Definition

I collected a list of known standards and frameworks, some you might also call methods or approaches. The thing they have in common is that they are all relevant for IT, but many of them not exclusively. They cover Project Management, ITSM, Governance and Process Management and other areas, some of them are industry specific. I decided also to include Standard like ISO 9000 as this is relevant in comparison to other QM-focused IT frameworks. Below chart shows the terms I was using (btw created with wordle.net):

Setting the Scene: An unrefined  List of Frameworks, Standards and Methods

Setting the Scene: An unrefined List of Frameworks, Standards and Methods

Let me know, if I missed any important standard, framework or method and I will add it.

Search Popularity Analysis: The ‘Big Five’

I compared all the keywords, some refined by topics or negative keywords. For example, the term Scrum also refers to sport (rugby). Additionally I discovered that something is wrong with ITIL: It’s an extremely popular search term in Indonesia, which made me curious. After consulting Google Translator I found out that ITIL means Clitoris in Indonesian Language (funny, isn’t it?), which explains the regional spike. Again, I was able to filter all that irrelevant data out. Looking at the ‘Top five’ (Snapshot as per now), we have the following picture:

Google Trends: The 'Big Five'

Google Trends: The ‘Big Five’

As you can see, ITIL is by far the top one, followed by Scrum, ISO 9000/9001, Six Sigma (all at the same level) and finally Kanban on Rank 5.

If we go further down the list, the ranking continues like this (exact order):

ASL, TIPA and GAPPS I had to remove completely, because they returned invalid results (multiple meanings with no possibility to refine).

Analyzing the Trends over Time

Looking at the big five, one surprise for me was ITIL: Many people say that there is a decrease in popularity. It’s not true. Over the last 3 years the trend is flat, preceeded by a peak at 2007 (obviously related to the publication of ITIL V3) and a decrease which stopped 3 years ago.

Another observation is the continuous and impressive increase of popularity of Scrum over the last 7 years. In the agile area, Scrum seems to continuously rule out other agile frameworks/methods like DSDM/Atern and XP. No surprise. However, if we look at ISO 9000/9001 and Six Sigma, there was a huge decrease of popularity since 2007. Going through the whole list, we see the following:

  • Winners: Scrum, DevOps (First appearance 2011, now Rank 9) and TOGAF (slightly)
  • Evergreens (flat curve): ITIL, Kanban, Prince2, PMBOK, BPMN, ISO20’000, ISO 27’000 and Cobit
  • Losers: Six Sigma, CMMI and ISO 9000 /9001, XP, DSDM/Atern
  • Newcomers (first appearance in the last few years and not yet dead): DevOps, IT4IT, Standard and Case. They might reach the plateau of producitivity one day or become obsolete

This is just observation. It’s up to you to make any conclusions.
As a side-note: Statistically, evergreens are actually still winners. An already infected community cannot be re-infected. This has an impact on search behaviour.

Geographical Differences

Doing a geographical analysis, I don’t see very much regional difference in popularity, with the following exceptions:

  • ISO 9000/9001: Although worldwide loss of popularity, it’s still unbroken popular in whole Latin America
  • SixSigma is rather popular in India, the US and some Asian Countries, but not in Europe
  • The UK (including the Scottish) & the Netherlands love Prince2
  • PMBOK is rather popular on the American Continent than in Europe or Asia

Again, I present here just the data. I leave it up to you to interpret it.

Keyword Drilldown

I picked a couple of frameworks & standards and looked into the related searches:

  • ITIL: It’s all about doing a certification or training. Top searches include ‘ITIL certification’, ‘ITIL foundation’, ‘ITIL training’, Prince2 goes into a similar direction
  • In contradiction to that, DevOps is rather about searches like ‘What is DevOps’ and ‘Reaction to DevOps’. DevOps is new and popular and people want to know more about it
  • Similar to that, searches on Cobit, Scrum, PMBOK, CMMI and other are very much related on the content of the respective framework

So this was just scratching on the surface. But I think there were some interesting observations. Try it yourself and do some research on Google Trends.

Gute Gründe für einen sicheren Weg in die Cloud

Computerleistung bei Bedarf zu erhalten, ohne dabei viel Verwaltungsaufwand zu betreiben, sind hervorragende Argumente für kostenbewusste Unternehmen. Mit dieser Virtualisierungstechnik bietet sich für Unternehmen nun eine Vielzahl von Implementierungsmöglichkeiten.

Mit Cloud Computing hat sich die Art und Weise wie Geschäftsprozesse umgesetzt, angewendet und gemanagt werden, wesentlich verändert. Die Veränderung kann mit dem Aufkommen des Personal-Computers verglichen werden, welcher die IT-Nutzung ebenfalls revolutioniert hat. Mit Cloud sind nun die wesentlichen Komponenten schneller und flexibler einsetzbar geworden. Einige der Treiber, welche die Aufmerksamkeit der Entscheidungsträger innerhalb der Unternehmen auf sich gezogen haben, sind:

  • Optimierte Ressourcennutzung: Die typischen Auslastungen von Serverrechnerleistungen liegt in Unternehmen durchschnittlich bei 15 bis 20 Prozent. Der Rest der vorhandenen und bezahlten Kapazität bleibt ungenutzt. Wenn nun ein Model zur Verfügung steht, bei dem Ressourcen nur bezahlt werden, wenn diese tatsächlich benötigt werden, dann ist damit ein fast perfektes Model zur Ressourcenoptimierung gefunden worden.
  • Kosteneinsparungen: Der Wechsel von eingekauften und gewarteten Rechnerleistungen hin zu gemieteten Cloud-Services hat einen Paradigma Wechsel von Investitionsausgaben (CAPEX) hin zu reinen Betriebsausgaben (OPEX) zur Folge. Es besteht ein Potential zur Einsparung von Gesamtkosten. Man denke nur an die Möglichkeiten von flexiblen Rechnerleistungen für Testzwecke ohne dabei erhebliche Investitionen tätigen zu müssen. Zudem wird durch die Verrechnung der effektiven Nutzungsleistungen der Kapazitätsbedarf transparent gemacht.
  • Erhöhte Reaktionsfähigkeit: Durch On-Demand (Bedarfsgestützt), agile, skalierbare und flexible Services, welche zudem noch in kürzester Zeit der Organisation bereitgestellt werden können, bieten Unternehmen Fähigkeiten, schnell auf veränderte Situationen und Spitzenzeiten reagieren zu können.
  • Schnellere Innovationszyklen: Durch die Verwendung von Cloud-Lösungen können Innovationen schneller abgewickelt werden, als wenn dies rein intern im Unternehmen durchgeführt würde. Oftmals ist ein Wechsel hin zu einer neuen Software-Version eine einfache Anpassung der URL-Adresse im Browser.
  • Reduzierte Implementationszeiten: Mit Cloud Computing können Rechnerleistungen und Datenspeicher nach effektivem Bedarf und quasi in Echtzeit zur Verfügung gestellt werden. Die Umsetzung intern dauert in der Regel Wochen und Monate und bindet sehr viel Investitionsbudget (CAPEX).
  • Zuverlässigkeit: Der Ausfall einer einzelnen Komponente in einem Cloud-basierten System hat eine kleinere Auswirkung auf die allgemeine Service Verfügbarkeit und reduziert damit das Risiko eines Totalausfalls. Gosse und kritische Systeme müssen intern oft mit sehr komplexen ausfallsicheren Mechanismen (High Availability Options) ausgestattet werden.

Je nach Anforderungen der Unternehmen genügen eines oder mehrere dieser Argumente, um Cloud-Computing als Alternative Lösung zu betrachten. Insbesondere wenn es um Kosteneinsparungen geht, ist das Modell des Pay-per-use, der nutzungsabhängigen Verrechnung bestechend. Aber jede Cloud Lösung hat nicht nur Vorteile, sondern auch Risiken zu betrachten. Die Unternehmen müssen die Chancen und Risiken abwägen, um entscheiden zu können, ob die Cloud eine valable Lösung ist.



Die Vorteile und Risiken im Zusammenhang mit Cloud Lösungen variieren auf Basis folgender Faktoren:

  • Art des Cloud Service Models: Software as a Service (SaaS), Platform as a Service (PaaS) oder Infrastructure as a Service (IaaS) und damit verbundene Service-Modelle wie Security as a Service (SecaaS), Storage as a Service (StaaS) usw.. Jedes Cloud Service-Modell adressiert unterschiedliche Geschäftszwecke und entsprechend unterschiedliche Risiken
  • Robustheit des bestehenden IT-Betriebs innerhalb des Unternehmens: Die Unternehmen müssen sicherstellen, dass ihre aktuelle Governance, Risiko Management und Informations-Security Enabler gut definiert und durch den bestehenden IT-Betrieb gesteuert werden. Mit der Cloud können neue Bedrohungen und Schwachstellen identifiziert werden. Aber wenn das Unternehmen vorbereitet ist und der IT-Betrieb in der Lage ist, diese Probleme entsprechend zu bearbeiten, dann ist das Gesamtrisiko für das Unternehmen niedriger zu erwarten.
  • Aktuelle Höhe der Geschäftsrisikoakzeptanz: Die Höhe des Risikos, welche ein Unternehmen bereit ist zu akzeptieren variiert zwischen Unternehmen und Branchen.
  • Aggregierter Wert der Daten, welcher in die Cloud verschoben werden sollen: Unternehmen müssen den Wert der Daten ermitteln, welcher diese für Menschen mit krimineller Absicht haben könnten.
  • Interne Sicherheits-Klassifizierung der Daten, welche in die Cloud gestellt werden sollen: Auch der interne Wert und Schutzbedarf der Daten soll ermittelt werden, um die Daten im Eigentum des Unternehmens zu belassen und nicht der Öffentlichkeit preisgeben zu wollen.
  • Die Compliance Verpflichtungen von geteilten Daten innerhalb der Cloud identifizieren: Daten, welche den persönlichen Datenschutz betreffen, oder Informationen des Finanzberichtes sind Beispiele, welche durch Compliance-Anforderungen speziell geschützt sind.
  • Cloud Service Provider (CSP) Risiken: Unternehmen sind gut beraten, eine Due Diligence bei potentiellen Cloud Service Providern durchzuführen. Da heute noch keine allgemeine und konsistente Sicherheitsstandards im Cloud-Umfeld gibt (es ist zurzeit ein Standard „ISO 37500 Guidance on Outsourcing“ in der Entwicklung), hat jeder CSP seine eigenen Ansätze und trüben so die Sicht auf die Sicherheit. CSPs sollen Best Practice Ansätze wie COBIT oder ITIL anwenden und international anerkannten Standards folgen.




Das Schlüsselelement in der Cloud heisst Vertrauen

Die kritischen Barrieren für Cloud Services sind Sicherheits- und Datenschutzbedenken. Cloud-Anwender und –Kunden können in Service Level Agreements (SLAs) festhalten, dass der Cloud Service Provider gewisse Kontrollziele einhalten muss. Letztlich kommt es aber immer auf das Schlüsselelement des Vertrauens an, was ein Kernelement im Cloud Computing Geschäftsmodell ist. Wenn das Vertrauen fehlt, dann können noch so viele Kontrollen definiert werden – die Bedenken würden nicht gemildert.

Bei der Berücksichtigung von Cloud Lösungen ist es daher eminent wichtig, alle Beteiligten und die Standorte zu kennen. Die Beteiligten beschränken sich nicht bloss auf den CSP und seine Mitarbeiter. Auch jene, welche mit dem Cloud Service Provider in Kontakt stehen und Service-Leistungen (zum Beispiel Support) bereitstellen. Es ist wichtig sicherzustellen, dass alle vertrauenswürdig sind. So zum Beispiel dass niemand in betrügerischen Tätigkeiten involviert ist und dass die Beteiligten finanziell abgesichert und solvent sind. Eine gute Regel ist, CSPs auszuwählen, welche bereits grosse Erfahrungen und eine entsprechende Cloud-Historie aufweisen können und zudem noch über solide Geschäftsreferenzen verfügen und zur Verfügung stellen.

Es braucht neue Skills: beim Provider wie auch beim Kunden

Nicht nur beim Cloud Service Provider CSP sondern auch beim Unternehmen, welcher diese Cloud Services bezieht, sind spezifische Fähigkeiten und Kompetenzen notwendig. Um ein Unternehmen professionell und sicher mit Cloud Diensten zu versorgen, sind Kenntnisse in folgenden Bereichen notwendig:

  • Prinzipien des Cloud Computing
  • Implementierung und steuern der Cloud
  • Nutzung der Cloud
  • Security und Compliance
  • Der Business Case bei der Evaluation von Cloud Computing
  • Lieferanten und Vertrags-Management

Bei Unternehmen, welche vermehrt Cloud Services im Einsatz haben, werden in Zukunft folgende Rollen immer zentraler:

a)     Cloud Service Owner

Er ist verantwortlich für den gesamten Lebenszyklus des Cloud Services, von der Service Strategie, Design, Transition (in und out) sowie dem Betrieb und der kontinuierlichen Verbesserung:

  • Managing des Cloud Service Portfolios
  • Repräsentation des Cloud Services im gesamten Unternehmen (Single Point of Contact)
  • Definition der Cloud Service Levels, Metriken und Messverfahren
  • Unterstützung der Prozessverantwortlichen im Umgang mit der Cloud (Managen der Unternehmensarchitektur, Service Level Management, Lieferanten Management, Risiko Management, Information Security Management)
  • Ausrichten des Cloud Service Management Modells auf die Governance der Unternehmens IT

b)     Cloud Service Manager

Der Cloud Service Manager ist für die Bereitstellung der Cloud Services zum Business gemäss SLA verantwortlich:

  • Reporting der Cloud Service Qualitätsparameter gegenüber Cloud Service Owner
  • Verantwortlich für die Abnahme der Service Akzeptanzkriterien zwischen Service Transition und Service Operation
  • Unterstützung bei der Definition der Service Level Agreements
  • Management der Cloud Administrations Rollen
  • Überwachung der Betriebs- und Support-Prozessleistungen (insbesondere Incident Management und Request Fulfilment, Problem Management, IT Service Continuity Management, Information Security Management, Availability und Capacity Management)

Service Management ist imme rnoch die Paradedisziplin. Die Management Anforderungen verschieben sich jedoch vom reinen Betrieb hin zu mehr Strategie und Governance. Lesen Sie dazu auch unsere früheren Beitrage:



Where to start with a Sourcing Governance Frame Work ?

Simple answer: Get yourself familiar with knowledge that is available. Basically, to build the knowledge for sourcing, outsourcing and related governance models, you would have to focus on the available knowledge sources.


First and foremost, you need to get to know local/national, laws under which any sourcing strategy is being defined and executed. For instance, if your company is headquartered in Switzerland, the “Bundesgesetz über den Datenschutz” would be a good starting point along with the “Verordnung zum Bundesgesetz über den Datenschutz”.  This law and its amendments are talking about the data protection rights of individual and juristic persons. If you consider to move part of your business abroad from your headquarter country, you need to consider the different intellectual property protection and data privacy rights at the locations you want to outsource to. If staff is affected by transitioning to an outsourcing service provider, you need to get yourself familiar with labor-law issues. In Switzerland, Art. 333 of the Swiss Code of Obligations (SCO – liability in the event of transfer of employment relationships) kicks in.

Industry Regulations

Based on national laws, certain industries are bind to some more granular regulations. In Switzerland, Financial Institutes have to act according to the bank secrecy law “Bankgeheimnis”. This law is triggering additional regulations for banks in the case of outsourcing. The Swiss Financial Market Supervisory Authority (FINMA) has released the circular “Outsourcing Banken” which describes the conditions under which outsourcing has to be performed.


Any sourcing strategy definition and execution of a bank in Switzerland need to have controls in place to adhere to this paper.

International Standards

Over the centuries, industries and branches have developed standards and norms of operation. ISO/IEC 38500 is an international standard for corporate governance of information technology. It provides a framework for effective governance of IT to assist those at the highest level of organizations to understand and fulfill their legal, regulatory, and ethical obligations in respect of their organizations’ use of IT. Any sourcing governance should be based on this standard.  To execute a sourcing strategy, a new norm will support standards for the outsourcing process in information technology: ISO/DIS 37500 (Guidance on outsourcing) is being drafted and under review – to be officially released 2015.  This norm is referencing a number of other ISO Standards very well known in information technology:

  • ISO 31000, Risk management
  • ISO 21500, Guidance on project management
  • ISO 9001, Quality management system
  • ISO/IEC 20000 Information technology – Service management
  • ISO/IEC 27001 Information technology – Security techniques
  • ISO 19011, Guidelines for auditing management systems.


International Frame Works

Especially for information technology, a number of established “best practice” frame works support the definition and execution of sourcing strategies. COBIT 5.0 is certainly the most comprehensive and complete frame work covering governance and management of information technology – supporting any form of sourcing.  Besides of the generic COBIT 5.0 frame work, there is a number of dedicated sourcing documents being released by the organization (ISACA) responsible for COBIT, i.e:

Very well known in IT is ITIL v3©. This frame works helps service providers and customers to define process responsibilities, activities and interfaces in service operations. In addition, the service transition from customer to the external service provider is being supported by processes and process outcomes (i.e. service acceptance criteria, knowledge management). The frame work’s service design processes are the base for the definition and execution of service requirements and service quality parameters throughout the souring life-cycle.

Maturity Assessments

Part of the execution of a sourcing strategy should always be an assessment about the sourcing capabilities of an organization. There exists more generic assessment frame works in IT not necessarily dedicated to sourcing (i.e COBIT Process Assessment Model (PAM), TIPA or CMMI). A specialized sourcing assessment would be the eSourcing Capability Model. This a framework has been developed by ITSqc at Carnegie Mellon University in order to improve the relationship between IT Services providers and their customers. The eSCM is twofold: eSCM-CL for Clients and eSCM-SP for Service Providers. These two models are consistent, symmetrical and complementary for each side of the client-provider relationship and this is the strength and the uniqueness of this model.

Trainings and Certifications

International de facto standard for training and certifications related to outsourcing is the Sourcing Governance Foundation course. It provides basic knowledge of what the main concepts of Outsourcing and Sourcing Governance are and how they can be applied. Best practice shows that implementing and operating a Sourcing Governance Function will require staff awareness and understanding of the key principles and concepts of outsourcing and sourcing governance. In this course an interactive approach is used combining lecture, discussion and exercises.

APMG-International has created the Sourcing Governance Foundation certification in conjunction with International Association of Outsourcing Professionals® (IAOP®).

Undertaking the course and successfully passing the examination qualifies an individual for COS-FP (Certified Outsourcing Specialist™ – Foundation Principles) certification from the International Association of Outsourcing Professionals® (IAOP®).

In Switzerland, the University of St. Gallen has been released a program “Certificate of Advanced Studies (CAS) in Sourcing and Cloud Management” this year. Focus is the definition and execution of sourcing strategies.


In essence

There is a lot of knowledge available as a good starting point for any company considering souring as an option for its future business. This knowledge needs will be a fundamental part of the organizational capabilities for any successful sourcing.

What IT Service Management can learn from the Agile Manifesto (and vice versa)

Agile has become incredibly relevant, also for the IT Service Management industry. This is nothing new. But do we really understand what this means? ITSM and Agile do not contradict each other. From my point of view two things are relevant: First, using agile project delivery methods and agile principles to drive ITSM initiatives forward (in contrast of using traditional waterfall methods). I call this CSI 2.0, because it finally brought the ITIL CSI approach down to earth. There are already many impressive success stories around. On the other hand, agile ITSM is about having a concept of integrating your ITSM processes and practices with agile service design & transition (e.g. scrum, crystal, dsdm etc.). As a side-note, the second one is also something DevOps tries to address. Weiterlesen

Die Geschichte von Don Quijote und IT Service Management

Ich würde ja jeden verstehen, der sich bei diesem Titel fragt, was denn die wunderbare, aber auch etwas schräge Geschichte aus dem 17. Jahrhundert mit dem modernen IT Service Management zu tun haben könnte. Ich denke … mehr als auf den ersten Blick meinen…

Für all die Leser, die die Geschichte nicht mehr präsent haben, finden unter den Links (siehe Schluss) eine einfache Zusammenfassung. Ich beziehe mich ausschliesslich auf das bekanntere erste Buch von Miguel de Cervantes Saavedra.

Der gute Don Quijote hatte offenbar Zugang zu einem riesigen Fundus an skurrilen und nicht immer realen Rittergeschichten und hat diese Bücher geradezu verschlungen. Immer mehr wurde dadurch diese Ritter-Welt zur seiner eigenen vermeintlichen Wirklichkeit und somit zu seiner Realität. Er zog mehrfach aus und erlebte dabei viele Abenteuer. Für Aussenstehende war das Ganze allerdings ziemlich schräg, befremdlich und so wurde er aktiv und nachdrücklich bekämpft, was der arme Don schmerzlich erfahren musste (sein Kampf gegen Windmühlen).

Ich denke, diese ausserordentliche Geschichte kann als Metapher für unsere heutige Situation im IT Service Management Umfeld gesehen werden. Sollte das eine oder andere meiner Ausführungen zum Schmunzeln anregen, so ist dies durchaus gewollt. (Auch als Service-Arbeiter* kann eine Prise Humor Berge versetzen….). Ich fokussiere mich in meinen Interpretationen der Metaphern auf zwei Richtungen, die ich im kommenden Teil gerne erläutern möchte.

These 1: „Der von einer guten Idee getriebene und gegen alle Widrigkeiten kämpfende Ritter“
Hand auf’s Herz, ist das nicht für uns als „Service Arbeiter“ die ganz normale tägliche Herausforderung, die Idee des sinnvoll gemanagten Services mit den entsprechenden Prozessen den betroffenen Stakeholdern zu erklären? Dass das zum Kampf von unterschiedlichen Wahrnehmungen führen kann, dürfte für viele von uns nichts Neues sein. Ja ich würde sogar wagen zu behaupten, das ist schlicht Alltag.

Auf der einen Seite steht das Senior Management, welches insbesondere im KMU Bereich nach wie vor leidgeprüft aus vielen gescheiterten Prozessversuchen den Schluss zieht, dass die Service-/Prozess-Orientierung nicht wirklich nötig und viel zu aufwendig sei (unter dem Motto: „Niemand kann uns erläutern, was unter dem Strich raus schaut, also lassen wir es besser…. es ging ja bisher auch ohne“)

Auf der anderen Seite stehen die gegen Windmühlen kämpfenden „Service-Don Quijotes“, die ehrlich, differenziert und besonnen den Wert eines solchen Service- bzw. Prozess-Ansatzes versuchen zu adressieren. Solche besonnen Ritter des Service Managements verfolgen (im Gegensatz zur späteren These 2) einen strategisch und taktisch klugen und weit vorausblickenden Ansatz immer in der Absicht, das Management vom Benefit zu überzeugen („quick-wins“, „low-hanging-fruits“, „start-small-think-big“, etc.).

Ich bin heute mehr denn je überzeugt, dass mit verdaubaren, nachvollziehbaren und vor allem mit schrittweisem Vorgehen, dieser Konflikt signifikant entschärft werden kann. Denn es ist durchaus so, dass spürbarer UND messbarer Erfolg gesehen und honoriert wird, was zu Appetit auf mehr führt. Es soll nicht zum Kampf werden (wie bei Don Quijote), sondern ein Miteinander, wo schrittweise und nachhaltig vorgegangen wird.

These 2: „Der völlig verblendete, von zu viel Phantasie fehlgeleitete Ritter“
Ich habe das selber erfahren vor Jahren, als ich das erste Mal in Kontakt mit ITIL kam. Ich war fasziniert von den Ideen, von den guten Ansätzen und Werkzeugen, welche die akuten und latenten Probleme der damaligen IT-Organisation adressierten und dadurch viele Lösungsmöglichkeiten offerierten. Obwohl überall als „best practice“ (es war eben noch die V2) angepriesen, nahm ich das ganze als „die neue Realität“ an und war geradezu euphorisch. Ich zog aus und konnte nicht verstehen, dass meine Gegenübers sich oft kopfschüttelnd abwendeten, bzw. sogar aktiv das Vorgeschlagene oder von mir selbstständig Eingeleitete, bekämpften.

Hier sehe ich den Vergleich zu unserem naiven Don Quijote, er war so weltfremd, dass er keine Wahrnehmung hatte für die Realität. Er kämpfte gegen die vermeintlich Bösen, die im Ursprung gar nicht so waren (ich spreche mal nicht von den Windmühlen…;-)

Über die vielen Jahre im Service Management habe ich gelernt, dass wenn man als realitätsfremder, immer an der Grenze von Ignoranz funktionierender Service Management Verfechter (z.B. ITIL, ISO20000, etc.) auf die Leute zu geht, das Gegenüber zur negativen Reaktion zwingt. Service Management ist kein Selbstzweck (und war auch nie als das gedacht), sondern viel mehr als Hilfsmittel in unser IT-getriebenen Service-Gesellschaft deren Wertschöpfung zu steigern.

Wenn ich Bücher, Berichte, Beiträge oder Blogs lese von Fundamentalisten und Evangelisten so wird mir sehr schnell klar, zu welchem nachhaltigen Schaden das führen kann. Ich stelle mir vor, wenn ich Mitglied des Senior Management wäre und mir erklärt würde, dass es jetzt unumgänglich sei, ein Projekt mit zig Mann-Tagen zu lancieren um die 4Ps („People“, „Process“, „Products (technology)“ und „Partner“) neu auszurichten und man dabei sicherlich einen Haufen Geld sparen kann, dann verstehe ich die äusserst kritische Haltung. Am Ende solcher skurrilen Kompagnien wird dann leidlich versucht den Mehrwert für den Aufwand zu rechtfertigen. Ich erinnere daran, dass im KMU-Bereich eine interne Service Management Kampagne ein signifikantes Investment darstellen kann.

Besonnenheit, Miteinander und ein neuer Ansatz
Ich wünsche mir für unser Service Management Business mehr Besonnenheit (mit kluger Voraussicht und dem Auge für das Wesentliche). Ehrlich in einem Miteinander herausfinden, wo der Schuh drückt und dann mit Weitblick und verdaubaren Schritten für Organisation und Business an die Umsetzung gehen wird erfolgreicher sein, als Grabenkämpfe und Selbstverwirklichung.

Ein für das Service Management eher neuerer Ansatz (der als Erweiterung gesehen werden soll) bekommt immer mehr Anhänger. Getrieben von der Idee, dass es für Organisationen oft schwierig ist (insbesondere bei kleineren), eine Prozesslandschaft zu etablieren, die alle Eventualitäten abdeckt, soll das Case Management eine neue Herangehensweise bieten, um strukturiert bei fehlendem Prozess oder Prozessfragmenten die Service-Organisation und somit den Service-Konsument zu unterstützen.

Im Wesentlichen gibt es zwei Ansätze:

  1. Die Organisation hat noch keinen Prozess für das Issue, welches jetzt ansteht („buttom-up“)
  2. Die Organisation hat wohl einen eingeführten Prozess, der hilft hier aber nicht
    weiter, da dieser nicht zum Issue passt.

Im Gesundheits- oder Sozialwesen kennt man diesen Ansatz schon seit mehreren Jahren und hat hier sehr gute Erfahrungen gemacht.

Eine gute Möglichkeit, diesen Ansatz kennen zu lernen und zu diskutieren ist der IT Manager Kongress (siehe link). Hier wird die SwissICT-Themengruppe „Service Management in der Praxis“, welche sich seit ca. einem Jahr mit diesem Thema beschäftigt, einen Workshop durchführen.


Die Geschichte von Don Quijote

Workshop am IT Manager Kongress „Case Management in der Informatik“: