Integration von Cloud Service-Elementen in meinen Service Katalog: einfach ‘find’ and ‘replace’?

Es gibt kaum eine Unternehmens-Informatik, in welcher IT Service Management nicht in irgendeiner Weise vorhanden ist.

Basis bilden meist die Service Operation – Prozesse (Incident Management, Problem Management, Service Request Management, Event Management), welche mehr oder weniger ausgeprägt etabliert sind und gelebt werden.

Jedoch wird bei der vorgängigen Phase wie Service Design und Service Strategie das Kundefeld lichter, die implementierten Prozesse weniger.

Warum überhaupt ein Service Katalog?

Gerade letzte Woche war ich bei einem grösseren Kunden, bei welcher einen Kostentransparenz sprich ein Service Katalog mit Preisen auch heute (noch) kein Thema ist. Ebenso kompliziert und intransparent hat er mir seine jährlichen Budgetrunden mit dem Business beschrieben. Ein einfacher Service Katalog mit den entsprechenden Service Level Agreements könnte hier Abhilfe schaffen.

Diese Erfahrung konnte ich auch bei einem innerschweizerischen Unternehmen machen. Innert 4 Monaten hatten wir die 40-50 Hauptservices definiert. Der Finanzchef der IT Abteilung kam mir freudestrahlend entgegen – endlich konnte er mit seinen Geschäftskunden diskutieren über Absatz und Umsatz – Ziele pro Service, ein Novum für diese. Auch im Hinblick auf die anstehende Budgetrunde und Kostenübernahme – Diskussion fürs neue Jahr kam diese neue Basis wie gerufen.

Zugegeben, der in der schnelle geformte Servicekatalog war bei weitem nicht perfekt, jedoch genug detailliert, damit in die nächste Jahres-Budget-Runde einzusteigen. Die Toleranz war mit rund +/- 15% Unschärfe völlig akzeptable für den Kunden.

Einerseits existierten ja bereits Fragmente von technischen Services – was ergänzt werde musste ist meisten die Business Sicht. In mehreren Workshops wurden die Businessziele / Business Services identifiziert und eine Grundlage für eine Service Architektur gelegt.

Neue Service Elemente wie beispielsweise „Office 365“ oder „Cloud Storages“?

Was passiert jedoch, wenn sich nun aus der Sourcing Strategie plötzlich neue Technologien (beispielsweise „Office 365“ oder „Cloud Storage“) einbringen?

Farbspitzen

Die Auswirkung auf die Betriebsorganisation kann mittel bis gross sein, falls sollte Komponenten extern beschafft werden. Plötzlich wird aus einem Change auf Service Komponenten ein mittleres Organisationsprojekt. In diesem Fall sollte mit allen Involvierten vorgängig das Gespräch gesucht werden. Nicht, dass sich nun Kernaufgaben wie z.B. Operation wegfallen, nein, der gesamte Wechsel von einem Service Provider zu einem Service Integrator wird in den Fokus der Aufgaben rücken. Wie gehen wir dabei vor?

    • Review der Vision, Strategie und der Ziele
    • Review der «As-Is» Situation
    • Definition der «To Be» Modellkomponenten
    • Definition des «To Be» Betriebs – Modell
    • Transformation «As-Is» nach «To Be»

Solche Strategie Entscheide sollten begleitet werden im Sinne, dass die Auswirkungen auf die Organisation frühzeitig untersucht werden. Unserer Erfahrung nach empfehlen wir hier Betriebsmodell Varianten auszuarbeiten, welche sodann gewichtet werden…und schlussendlich sollte hinter solch einem Vorhaben ein Business Case stehen.

Betriebskonzept, Varianten – Business Case

Wenn alle Beteiligten involviert werden, können diese neuen Perspektiven für die Mitarbeiter durchaus sinnvoll, nachvollziehbar und gleichzeitig herausfordernd sein. Somit kann nicht zuletzt den Einzelnen ein interessanter, im ursprünglichen Aufgabengebiet erweiterter Job angeboten werden.

Differences in Service Management System between internally managed private Cloud and externally managed private Cloud

In one of my last blogs, I was reflecting on “Private Cloud and the impact to the existing IT Service Management System”. This view took in consideration design, transition and operation of an internally managed private Cloud.

There might be reasons to review the internally managed private Cloud model:

  • Building a private Cloud environment with out-of-the box Cloud products might by cumbersome, especially all the necessary integration, automation and orchestration effort is far too high, complex and costly,
  • Shortcomings in expertise, experiences, skillsets for Cloud architecture, engineering and integration design and build,
  • Shortcomings in expertise, experiences, skillsets for efficient and effective Cloud operation management,
  • Building an running a complete new set of technology is just not in line with strategy on core competencies,
  • Sourcing opportunities/alternatives are in line with company compliance and risk profile.

So what is the impact to the Service Management Model by moving to an externally managed private Cloud?

First and foremost, the management would need to understand the value of a defined sourcing strategy supporting the definition and the sustainability of the business case for an outsourced private Cloud from strategy over design, transition to Cloud Service operation. Besides the decision on the horizontal life cycle span of sourcing, the other sourcing dimension to be considered is vertical range of ownership for the Cloud Service’s value chain.

Sourcing ranges

Furthermore, the Cloud Service portfolio would need to be modified catering for the impact of the outsourced service elements. Same for the Financial Management: the definition and implementation of a pay-per use cost model between two separated legal entities would need to be supported.

Secondly, all the processes and functions supporting Service Design would need to be adapted for the support of an outsourced model. Sometimes hard to swallow for the teams in Service Design is the fact, that they have to revisit their traditional “selecting products (Cloud tech stack) approach” scope and responsibility. Now they are being asked to define service specifications based on business requirements and to process those specifications as part of a proper Service provider selection exercise. In order to do so, processes like service level, capacity, availability and continuity and security and, last but not least, supplier management processes and the respective process outcomes are becoming paramount.

On a capability level in Service Design, the shift to be supported is from technical skillsets to service and supplier management covering business consultancy, architecture and security as well as compliance and integration capabilities.

Thirdly, Service Transition and its processes are becoming a new  challange since the Cloud Service is being setup under the responsibility of an external partner. All the integration layers between in-house and provider (data bus, identity & access, processes, roles, boards) would need to be established as designed and contracted during that phase. This requires tight and stringent governance over the transition project.

Finally, the internal IT organization is not struggling anymore with definition and implementation effort for automated processes in service operation. The Cloud service provider will have all the operation processes being automated and integrated with customer’s portal, sign-on, dashboard and reporting functions. Capabilities and skillsets remaining in-house in service operations are to manage the provider regarding service performance, demand and change management, service reporting and accounting as well as continual service improvement.

For the moment there’s only one thing left to say. Even when a company sticks to an internally managed Cloud Service model, by integrating public cloud offerings with private Cloud Services (hybrid model), all the listed aspects above will have to be taken into account as well.

Integrating Agile and ITSM

Every week a new production release and often changing requirements and priorities – this is daily life in agile environments. How does this project delivery approach (usually: SCRUM) fit into existing IT Service Management processes (usually: ITIL)? How do we manage for example the increasing trade-off between flexibility and stability? How do we make sure operational service-requirements are reflected in an early phase of an agile project? How do ITSM-roles and SCRUM-roles chime together? Can ITIL and Agile coexist? YES, definitely!

Before we proceed on that, just to make sure that things don’t get mixed up:

  • This blog is not about using agile project delivery methods to drive ITSM initiatives forward (I call this CSI 2.0: An very promising, but completely different topic)
  • I hope it’s also not one of these wishy-washy “let’s go agile ITSM” blogs, which promote that we now should forget all the processes and become ‘cool agile’. In my opintion, there is on the ITSM-side a lack of understanding, that SCRUM is an extremely structured approach, but within these boundaries promotes the principle of self-organization. Often, only the second part is perceived and ‘becoming agile’ acts as a bad excuse for the chaos. A very good observation on this you can read in this blog.
  • So this is rather about how to integrate a specific Project Management approach with ITIL. Especially if agile project methodology is used for existing products or services (being already in operation), a tight integration into your Service Management processes is key.

Developing the Model

Step 1: Understanding the two Domains and their Goals

ITIL and SCRUM do not contradict each other. There is no incompatibility. SCRUM is a specific way to deliver projects, it’s an iterative, adaptive and incremental approach to project management. You can use it for any kind of project, even outside IT, and has become by far the most popular agile methods. ITIL is about best practice IT Service Management. It’s a holistic collection of ideas and processes on how to define, design, transition, run and finally continuously improve services (-> that’s the service lifecylce). ITIL takes the operational point of view into consideration, acknowledging that value to the customer is delivered during service operation and therefore operational requirements must be reflected in an early phase of Service Design. ITIL is agnostic on what PM methodology is used. So ITIL and SCRUM are rather complementary. Similar if you would look at ITIL and Prince. The challenge is how the two interact.

Step 2: Understand how the two Domains fit together on high Level

ITIL and SCRUM fit perfectly on high level. From ITIL perspective, SCRUM starts with Service Design and ends with the delivery of a product or service (well, actually it starts over and over again). I made below graph to illustrate this:

Scrum & ITIL: A perfect fit on high level

Scrum & ITIL: A perfect fit on high level

So, let’s quickly walk through the SCRUM process and you will immediately understand what this buzz is all about:

  1. Service Design: Starting from the approved business case, requirements are gathered in form of user stories & prioritized. The result is the prioritized product backlog.
  2. Service Transition: This is handled through timeboxed sprints (typically between 1-6 weeks each sprint). Each sprint starts with a sprint planning meeting, in which user stories are included for the next sprint (-> sprint backlog, a subset of the product backlog). Daily standup meetings help to track progress and to eliminate impedimends. The sprint ends on the one hand with the sprint review meeting, in which the new/changed service or product is formally accepted. On the other hand, there is the Sprint Retrospect Meeting, which results in the lessons learned for the next sprint.

Step 3: Tackling the Challenges

Don’t forget Operations

One issue with purely SCRUM-driven projects is that they don’t care about Service Operation and focus very much on the utility (functional requirements) of a new product or service. Solutions are thrown over the fence and especially warranty-aspects of a new service (capacity, availability, security and continuity) are not taken into consideration and at the end of the chain the service doesn’t deliver it’s value. DevOps provides some ideas on how to solve this, but I still don’t get the point how DevOps works in practice (…). One of the big contributions of ITIL is that these operational aspects are already reflected in an early stage of the Service Design phase. Applied to SCRUM, this would mean that already during creation of User Stories and the Product Backlog these requirements are gathered. During the sprint, teams taking care of these aspects (e.g. infrastructure) need to be part of the Scrum Team.

Including warranty requirements in the product and sprint backlog planning

Including warranty requirements in the product and sprint backlog planning

Change Management & Release Planning

From an operational perspective, Change Management acts as a protector of the productive environment, identifying risks of each change and preventing negative impact. More broadly , you can put every change on a Configuration Item under Change Control (e.g. product backlog, which is created in Service Design). The tricky question is to which extend. On the one hand it will give you more stability; on the other hand you add more administration and loose flexibility. So it’s a trade-off. Change Control is also a big topic in SCRUM, for example each sprint end with a sprint review meeting, in which the product owner reviews and approves the sprint. Or in Service Design, the product owner acts as a gatekeeper for each user story (change control over requirements). So putting this picture together, there are many instances of change control:

How much change control do you need? Balancing flexibility & stability through delegation models and achieving a controlled service environment

How much change control do you need? Balancing flexibility & stability through delegation models and achieving a controlled service environment

To achieve the right balance between flexibility and stability it is key a) to decide, what you want to put under change control and b) moreover to apply the right delegation models. For example:

  • Change control over the Product Backlog is delegated to the Product Owner. However, Service Operation teams should be involved as well to ensure operational warranty requirements are included as well in the user stories;
  • Change Control over the sprint results is delegated to the Product Owner and in case the sprint shall be included in a future release, the regular operational CAB acts as an approver too;
  • Change Control over the Sprint Backlog is delegated to the Product Owner, Scrum Team and Scrum Master and the regular Release Planning Team.

Test Automation

Using agile project methodologies means frequent releases. Testing can become a real pain. This concerns less the testing of new functionality, but rather the regression testing (checking if existing functionality has been affected by new release, repetitive). Automating regression tests is key. Test factory teams need to be involved early and based on the product backlog develop test cases need to be developed and automated.

Step 4: Integrating SCRUM- and ITIL-Roles

Scrum knows only three key roles: The Product Owner (‘voice of the customer’), Scrum Master (the facilitator) and the Scrum Team (the developers). ITIL knows many roles, but Service Owner, Change Manager, CAB seem to be very relevant to me in this context.

  • ITIL Service Owner and SCRUM Product Owner: If we talk about existing services, it makes sense that the two roles are incorporated in the same person. Both roles act as a voice of the customer and know the requirements side. On the software side, this is often represented by the Application Owner.
  • Change Management: Scrum Master and Product Owner need to be part of the CAB if it comes to the release of a sprint. The Product Owner acts as CAB approver from a sprint backlog point of view.
  • CSI Manager and Scrum Master: Continuos learning is an integral concept in Scrum: In sprint retrospective meetings, process improvements are identified. In the daily scrum meetings, impediments which hinder success are eliminated. This is all happening under Scrum Master responsibility. Structural improvements out of the Scrum process should be considered from overall organizational developement perspective and become part of the CSI register, therefore the Scrum Masters and the CSI Manager should liase on a regular base.

So I hope this gave you some ideas on how to bring the two worlds together. Scrum is not just for developing new products in an isolated world. It has become mainstream for tackling Service Design & Transition for existing Services. Finally, we talk here also about two worlds, which historically do not talk to each other. One the one hand the developer guys, on the other hand the operation guys. This is why we needs an integrated & practical approach on how to bring them together and finally a mutual understanding how both worlds work.

Don’t see it as a threat, see it as an opportunity.

Agile ITSM ist keine Rechtfertigung für das Chaos

Flexibilität, Geschwindigkeit und Resultatorientierung – das sind die Verlockungen, mit denen agile Methoden für sich werben. In vielen IT Organisationen wird damit eine erholsame Lanze gebrochen, um gegen der formalisierten, mitunter durch langwierig andauernden Abstimmungsprozess blockierten Entscheidungsfindung entgegen zu treten. Zu lange haben die Standardisierungsbemühungen in der Technologie aber auch in den Prozessen die Kreativität der IT Spezialisten in arge Schranken versetzt.

IT Service Management auf Basis von ITIL hat vielerorts dazu beigetragen, dass der Pragmatismus durch eine eher durch Bürokratie geprägte IT abgelöst wurde. Nun schlägt das Pendel der Entwicklung zurück. Cloud Computing, Multi Vendor Service Modelle, BYOD bei Anwendern und innerhalb der IT sowie die grassierenden Sozialen Medien sind Trends, denen sich keine IT Organisation ernsthaft erwehren kann. Das Business will von den Entwicklungen profitieren.

ITIL als Leitfaden für Best Practices in IT Service Management hat auf diese aktuellen Entwicklungen keine passende Antwort. Es wird noch Jahre dauern, bis ein entsprechendes neues Release der ITIL-Bücher erwartet werden darf, welcher sich dieser Thematik angemessen annimmt.

Agil und Lean sind daher heute im Management gern gehörte Begriffe und werden wohlwollend unterstützt, weil damit Flexibilität und rasche Umsetzung erhofft wird. Bestehende Abläufe und Prozesse werden in Frage gestellt – was zählt ist letztlich nur das Resultat, dass rechtzeitig vorliegt.

Agiles Vorgehen setzt hohe Maturität voraus
Dabei setzen agiles Vorgehen selbst strikt einzuhaltende Prozesse voraus. Das zu lösende Problem muss klar definiert sein, die Zeiten gilt es strikte einzuhalten und Entscheide sind im Team zu fällen. Prozesse sind also nicht ausser Kraft zu setzen, sondern viel mehr auf Dynamik und mit kürzeren Durchlaufzeiten auszurichten. Dies setzt eine entsprechend hohe Maturität der IT Organisation voraus. Hohe Maturität heisst hier: ziel- und resultatorientiert sowie selbstregulierend durch klare Zuständigkeiten und Kompetenzen.

Bei niedriger Maturität droht institutionalisiertes Chaos
IT Organisationen mit niedriger Maturität haben oft starre, bürokratische Abläufe, welche oft schlecht bis gar nicht gesteuert werden. Fehlende Dokumentationen, unklare Zuständigkeiten und nicht abgestimmte Ziele zwischen den Teams prägen solche IT-Abteilungen. Das Umschwenken auf agile Methoden wird hier von der Führung gerne als Vorwand genommen, da die Umsetzung auf ITSM-Praktiken gescheitert ist. Agile Methodik ohne Prozesse und Führung zementiert das bestehende Chaos und fördert das einzelkämpferische Vorgehen und das vorherrschende Heldentum.

Prinzipien agiler Vorgehensmethodik

Prinzipien agiler Vorgehensmethodik

Agiles ITSM heisst Fokussierung
Agiles ITSM hat aber durchaus seine Berechtigung und bringt grosse Vorteile, wenn man diese zu nutzen weiss. Wesentlich beim agilen Vorgehen ist, dass man sich auf das Wesentliche Fokussieren kann. Das heisst, dass man Aufgaben priorisieren muss und dass die Teams lernen müssen, die Arbeiten innerhalb vorgegebener Zeit auch tatsächlich abzuschliessen.

Arbeiten abzuschliessen anstelle immer neuere zu starten ist der kritische Erfolgsfaktor in der agilen Vorgehensmethodik. Wenn ich oft in IT Organisationen Einblick erhalte, sehe ich viele Teams, welche mehr Arbeit haben, als dass diese je erledigen können. Dort fehlt eine klare Fokussierung auf das, was wirklich wichtig ist.

Teams welche keine klare Fokussierung haben, liefern in aller Regel auch eine schlechtere Qualität. Durch den Versuch, alles auf einmal zu tun, entwickeln sie ein eigenständiges Verständnis und Definition dafür, ob eine Arbeit abgeschlossen ist. Man erklärt etwas als erledigt um sich dem nächsten Thema widmen zu können. Das Risiko ist relativ gross, dass die Arbeit zum ungünstigsten Zeitpunkt wiederholt werden muss.

Wie können nun IT Service Management Teams agile Methoden anwenden und den Fokus auf das Wesentliche erhalten? Wichtig ist, dass man die Arbeiten und der Sinn der Aufgabenstellung richtig versteht. Was ist der Ursprung der Aufträge und wie sind diese in die IT Organisationen übertragen worden? Verstehen wir die Zusammenhänge und Abhängigkeiten? In dem den Teams der Umfang der Arbeiten reduziert wird, auf das sie sich fokussieren sollen, verändert sich in der Regel auch ihre Einstellung, die Bereitschaft zur Termineinhaltung und das Verständnis der Qualität.

Sicherstellung der Dynamik durch Business-Alignment
Pläne und Prioritäten ändern. Das ist eine Tatsache, die es in Projekten wie auch innerhalb ITSM zu akzeptieren gilt. Business Anforderungen können mitunter schnell ändern und müssen berücksichtigt werden. Agile ITSM Teams müssen lernen, in Iterationen zusammen mit dem Business zu arbeiten.

Anstelle einmal jährlich vom Business Projektaufträge zu erhalten und diesen koste es was es wolle umzusetzen, brauchen agile ITSM Teams viel häufigere Begegnungen mit dem Business. Allenfalls monatlich trifft man sich mit dem Business, schaut sich den Gesamtplan immer wieder an und richtet durch Re-Priorisierung die Aktivitäten der IT auf das aktuelle Geschäftsgeschehen aus. Man kann nun im Detail auf die nächste Iteration hin planen, da die Informationen auf den aktuellsten Geschäftsentwicklungen beruhen.

Nur schon die regelmässigen Meetings mit dem Business und die laufende Überprüfung der Prioritäten ist ein erster wichtiger Schritt in Richtung agiles ITSM.

SCRUM Overview

SCRUM Overview

ITSM Teams befähigen statt kontrollieren
Die besten Lösungen kommen oft von selbstorganisierten Teams. ITSM Organisationen mit hoher Maturität befähigen ihre Teams zur Erarbeitung von Lösungsansätzen anstelle der detaillierten Beauftragung, wo nur noch umgesetzt werden darf. Wenn die Teams keinen Raum für Flexibilität und Kreativität haben, werden auch keine guten Lösungen entstehen. Es braucht klare Grenzen der Organisation, welche eingehalten werden müssen. Innerhalb dieser Grenzen sollen agile Teams aber frei arbeiten können. Es braucht ein hohes Vertrauen des Managements dazu – das Ergebnis lässt in der Regel nicht auf sich warten.


 

Emerging new Roles, Job Titles, Trainings and Certifications in the Cloud Services Area

As outlined in my last blog (“Private Cloud and the impact to the existing IT Service Management System”), the impact of the cloud services to an existing IT Service Management System is quite significant. Besides of the completeness, maturity, level of detail and automation challenges for the IT processes, internal IT organizations need to look to the impact to their organizational capabilities in terms of skills, expertise and experiences needed to run the show successfully.

imagesCAXB8HT1

The new skills, expertise and experiences needed are based on:

  1. new technology, tech stack integration and process automation,
  2. new or increased risk profiles for security and compliance,
  3. increased service governance and customer relationship requirements.

Starting with customer relationship management: Internal IT organizations are moving their business facing roles like “Business Analysts” more and more towards “Business Consultancy”.

“Business Consultancy” is way above defining requirements based on business needs. It is to look to the potential added value of an IT service for the business. The role of a “Cloud Consultant” as a customer facing role is to:

  • coach business functions on the impact of cloud services to the value chain of business services and products
  • help the business to create and to understand business case scenarios for moving into the cloud
  • review the business processes and portfolios to come up with cloud service proposals based on market trends
  • outline cloud migration and transition concept
  • coach the business functions on security, compliance and risk matters from an IT point of view.

Positioning an internal IT organization as a (private) cloud provider or cloud broker function (hybrid cloud deployments) requires a much stronger focus on service Ownership and service portfolio management. The role of a “Cloud Service Owner” ensures governance over all cloud service lifecycle phases, proper cloud service portfolio management and IT efficiency.

Capture

Looking to the service design phase of a cloud service, cloud specifics like resource pooling, rapid elasticity, orchestration and end-to-end automation will shape the traditional IT Architect role towards “Cloud Solution Architect“. A traditional “Developer” role will become a “Cloud Developer“. Due to the increased risks profiles in the area of security and compliance, dedicated cloud security management skills are needed. Therefore, the role of a “Cloud Security Manager” is to be considered. For service transition and service operations, two emerging roles with dedicated cloud knowledge are underway: The “Cloud Administrator” role is focused on running the cloud tech- stack based on automated run-books. The skillsets will be spread across all technology components used in the cloud. On contrary to traditional IT, cloud tech skills are not dedicated to technology towers. They are more towards understanding and managing technology integration, automation and orchestration. Last but not least, the overall responsibility for running a cloud service in operations will be with the “Cloud Service Manager“. The main responsibility of that role is to ensure, that a cloud service is being delivered by meeting the agreements and quality parameters routinely.

The mentioned emerging roles are becoming industry standards. Already today, role descriptions and even training and certification schemes are available. Please have a look at http://www.cloudcredential.org/certifications/ for more information.

Service Management ist mehr als die Summe aller Prozesse

Immer wieder treffe ich bei Kunden ein ähnliches Phänomen an: man hat wohl seit Jahren bereits eine stattliche Anzahl von ITSM Prozessen implementiert, aber keine gemeinsamen Ziele entwickelt, was damit erreicht werden soll. Anstelle funktionaler Silos abzubauen, hat man zusätzliche Prozess-Silos eingerichtet ohne jegliche Orientierung und selten mit der notwendigen Abstimmung. Die Prozessownership wird über die verschiedenen Organisationsbereiche verteilt – aber eine gemeinsame Vision, was mit den Prozessen zu erreichen ist, fehlt.

Vor lauter Bäumen den Wald nicht sehen

Vor lauter Bäumen den Wald nicht sehen

Vor lauter Bäumen den Wald nicht sehen wollen
An den Führungsstrukturen und an den Prinzipien in solchen Organisationen hat sich trotz dieser Prozesse überhaupt nichts geändert. Die von den Prozess-Ownern ermittelten und selbst definierten KPIs interessieren das IT Management genau so wenig wie die Daten, welche durch die verschiedentlich involvierten Systeme produziert werden. Hauptsache der Auditor hat nichts zu meckern…

Irgendwie verbindet man mit Prozessen noch eine gewisse Ordnungsmässigkeit – aber als Steuerinstrument für die IT werden sie in den seltensten Fällen verstanden.

Service Management ist ein völlig neu ausgerichtetes IT-Geschäftsmodells
Wenn man seine Organisation nach Service Management ausrichten will, dann muss man bereit sein, sein bisheriges Geschäftsmodell zu hinterfragen. Ein paar Prozesse einrichten die sich mehr oder weniger nach ITIL ausrichten hat damit nichts, aber auch gar nichts zu tun.

Service Management sind nicht nur Prozesse. Es sind die Führungsstrukturen, Prinzipien, Ziele, Mitarbeiter, Technologien und Tools, Daten, Kommunikation und und und … Und diese müssen in der Summe komplett neu ausgerichtet werden. Es wird nicht behauptet, dass es einfach ist. Es ist schwierig und benötigt Manager mit entsprechenden Visionen. CIOs, welche diese Visionen nicht haben, werden die Ziele nicht erreichen. Was ich heute in den meisten Fällen der Service Management Implementationen sehe, ist leider halbe Lippenbekenntnis ohne jegliche Orientierung und demzufolge auch ohne jeglichen nachvollziehbaren und wirtschaftlichen Erfolg.

Die immer wieder aufkeimenden Polemiken zwischen, was ist nun ein Service oder IT-Service und was ist ein System oder IT-System helfen nicht wirklich weiter. Zumindest nicht diejenigen, welche vor dem Problem stehen, eine Lösung bereitzustellen. Grundsätzlich bin ich auch klar der Auffassung, dass die Tools den Prozessen zu folgen haben und nicht umgekehrt. Aber ich kann nicht nur esoterisch in der Wolke diskutieren ohne irgendeinmal die Füsse auf den Boden stellen zu können. Wer Taten statt Folien will, muss die Theorie in der Praxis beweisen können und wollen.

Ganzheitliches Denken heisst, nichts auszulassen

Service Management ERP System

Service Management ERP System

Wenn Service Management als Geschäftsmodell in der IT gewollt ist, braucht es auch ein Service Management System. Am einfachsten stellt man sich vor, dass es ein ERP System, ein Enterprise Resource Planning System braucht für die IT. Enterprise-Resource-Planning (ERP) bezeichnet die unternehmerische Aufgabe, die in einem Unternehmen vorhandenen Ressourcen (Kapital, Betriebsmittel oder Personal) möglichst effizient für den betrieblichen Ablauf einzusetzen und somit die Steuerung von Geschäftsprozessen zu optimieren (Gemäss Wikipedia).

Architekturkonzept TOGAF

Architekturkonzept TOGAF

Und so ein System zu bauen und zudem noch Kundenorientierung und Serviceorientierung zu integrieren, setzt das Vorhandensein einer serviceorientierten Architektur voraus. Das Haus, das gebaut werden soll, muss einen Architekten haben, der die verschiedenen Anforderungen mit den vorhandenen Ressourcen und Technologien abstimmt, damit die Funktion des Service Management Systems vollständig wahrgenommen werden kann.

Um Service Management wirkungsvoll umzusetzen, braucht es also einen Architekten, welcher das Geschäftsmodell der IT mit den Prozessen, Anwendungen, Datensystemen und Technologien aufeinander abstimmt und orchestriert, dass die Summe als Ganzes die Ziele der IT optimal erreicht. In einer solchen Umgebung gibt es kein Jekami-Konzept. Gerade wenn Organisationen etwas grösser sind und beispielsweise über hundert oder gar tausend IT Mitarbeiter in sich vereint, dann ist eine solche Rolle unverzichtbar.

Die Business-Architektur gemäss TOGAF beinhaltet in der IT das grundsätzliche Betriebsmodell mit allen Governance- und Management Prozessen. Hier spielen die ITIL Prozesse eine massgebliche Rolle. Die Service Management Prozesse sind die “Business Prozesse” der IT. Hier werden die Bedürfnisse der Kunden abgeholt, die Service Leistungen vereinbart und letztlich auch erbracht und garantiert. Hier findet die Orchestrierung der Services statt und stellt die Dynamik des Business sicher.

Aber dazu braucht es eben auch Hilfsmittel und Daten. Diese sind entsprechend den Bedürfnissen der Business-Architektur auszurichten.

Die Informations-System-Architektur beinhaltet alle Hilfsmittel, Applikationen und vor allem Daten, welche im Rahmen eines Konzepts aufeinander abgestimmt werden müssen. Hier spielen Die ITSM-Tools und System-Management Werkzeuge wie Reporting, Deployment, Monitoring oder auch Event-Konsolen eine zentrale Rolle. Insbesondere ein Daten- und Informations-Management Konzept sind hier unabdingbar und konsequent durchzusetzen. Das Reporting setzt letztlich hier auf den Daten auf, welche verlässlich sein müssen. Es ist wichtig zu wissen, wo die Daten sind, woher sie kommen und wer die verarbeiteten Daten benötigt. Wenn schon Redundanzen, dann bitte kontrolliert.

Aber irgendwo müssen die Tools und Daten auch technisch in Betrieb genommen werden. Dazu braucht es die Technologie-Architektur.

Die Technologie-Architektur beinhaltet alle Systemtechnischen Komponenten und Bewirtschaftungssysteme. Hier werden die Puzzles zusammengestellt und die Schnittstellen bedient. Hier geht es letztlich auch ab, was oben mal angedacht wurde. Dabei können Systeme und Platformen aus der Wolke, zugemietet oder in den eigenen Räumlichkeiten bereitgestellt werden. Was wie in welcher Ausprägung genutzt wird, hat letztlich Auswirkungen auf die Dimensionierung. Hier müssen die Zusammenhänge der Service Architektur und System Architektur gut verstanden werden, damit das Ganze mehr als die Summe der Einzelkomponenten wird.

Jede IT hat das Service Management System, das er verdient…

Jeder hat die IT, die er verdient

Jeder hat die IT, die er verdient

Wenn man nicht weiss, was man will, dann darf man sich nicht wundern, dass man erhält, was man nicht braucht. In Zeiten des knappen Geldes, wird der Druck nicht nachlassen, sich als CIO erklären zu müssen.

Die IT kann nicht glaubhaft als verlässlicher Provider gegenüber dem Business auftreten, wenn sie im eigenen Haus keine Ordnung hat. Hier kann der Tatbeweis erbracht werden, das Geschäftsmodell nicht nur zu verstehen, sondern selber zu beherrschen.

Prozesse sind gut und wichtig – aber bei weitem nicht der einzige Faktor, der Service Management zum Betriebsmodell einer IT macht. Ein Service Management Architekt kann hier die wichtigste Ansprechstelle sein, um agil reagieren zu können, wenn neue Anforderungen anstehen.


 

The SLA Cheat Sheet

SLA Cheating? Better not, unless you want to mess up the relationship with your customers in long-term. So, why this blog? First of all, because cheating in terms of achieving Service Level Agreement targets is widely common, especially in the IT-outsourcing business. This shows up in various ways, just to give you some examples: Weiterlesen

ITIL für KMUs: Die zentralen 4 plus eine Domäne des ITSM

ITIL® ist ein universelles Framework und mit seinen fünf Bänden mit mehr als 7 Kilo Gewicht ein schwer verdaulicher Klumpen an Best Practices, den es zu verdauen gilt. In dieser Form ist ITIL® völlig ungeeignet für kleinere und mittlere Organisationen! 28 Prozesse und 4 Funktionen – und dann noch all diese Rollen. Das kann und will man sich im Mittelstand nicht leisten.

Komplett ignorieren kann man die Disziplinen aber doch nicht. Zu gross sind die Herausforderungen der IT-Industrie, welche auch vor den kleineren IT-Organisationen nicht halt machen. Verlässliche IT-Leistungen, Sicherheit, Mobilität und Kostendruck sind nicht nur für grosse Organisationen eine Herkulesaufgabe – auch KMUs müssen hier eine gangbare Lösung finden.

Nur – wie packe ich es an. Wie weiss ich, was für mich als Mittelstand relevant ist und auf was ich verzichten kann? Dieser Frage ist letzte Woche auch das itSMF Deutschland mit dem Live-Event „ITSM im Mittelstand“ nach gegangen. Auch ich habe dort einen Beitrag geleistet und das Buch von Malcolm Fry, ITIL Lite vorgestellt und wie man damit ITSM auf den Mittelstand zuschneiden kann. Ein anderer Beitrag zeigte auf, welche drei Prozesse es nun sind, auf das sich die ganze Aufregung reduzieren lässt. Ich verzichte jetzt hier auf deren Aufzählung, weil es dann doch etwas zu banal war. Nur soviel: letztlich zeigte sich, dass man alle auch noch wichtigen Dinge dann einfach bei den drei Prozessen subsumiert hat (…).

Im Nachgang zu diesem Event habe ich versucht, die wesentlichen ITSM-Domänen einer jeden IT-Organisation – insbesondere der der KMUs auszuleuchten. Bevor ich jedoch auf diese 4 plus eine ITSM-Domäne eingehe, möchte ich die wesentlichen Unterschiede zwischen grossen und kleinen Organisationen hervorheben.

Was kennzeichnet KMUs gegenüber grossen Organisationen?
Kleinere Organisationen werden oft auf ihre beschränkten finanziellen und personellen Mittel reduziert. Das leuchtet ein und macht klar, dass nicht mit der gleichen Kelle angerührt werden kann. Trotzdem bleiben die Herausforderungen gleich gross.

Es gibt aber auch viele Vorteile, welche kleinere Organisationen gegenüber grösseren haben: Agilität und Flexibilität. Während grosse Organisationen geradezu darunter leiden, breitangelegte Abstimmungen bis zuhinterst in jeder Abteilung durchzuführen, werden in KMUs Entscheide recht pragmatisch und im Türrahmen mit dem CIO gefällt. Grosse Organisationen tendieren zu viel mehr Bürokratie und damit zu lähmenden Abläufen, während kleine Organisationen schlanke und direkte Wege kennen.

Grössere Organisationen sind schwierig zu führen. Man holt sich Berater und stützt sich mehrfach ab, um ja nicht belangt zu werden. Währenddessen kleinere Organisationen eher auf ihre Kunden und Kollegen in ähnlichem Umfeld hören und sich inspirieren lassen.

Kleine Organisationen sind wie ein Dorf – da kennt man sich und weiss, wer wofür zuständig ist. Grosse Organisationen sind wie Städte – sehr unpersönlich und immer wieder überraschend, wer auch noch seine Ideen einstreuen möchte.

Was ich bei vielen ITSM-Implementationsprojekten in grossen Organisationen auch immer wieder feststelle, ist eine regelrechte Fragmentierung der ITIL-Disziplinen. Während sich die eine Ecke der IT-Organisation um das Thema Infrastruktur-Management und Service Operation Prozesse kümmert, ist in einer ganz anderen Ecke ein Team an der Erarbeitung von Service Katalogen und Portfolio Management beschäftigt. Irgendwo anders werden vielleicht noch Financial Management und Reporting betrieben. Letztlich hat sich die Entwicklungsabteilung in Grossorganisationen immer noch nicht auf die Niederungen eines Service Management herunter gelassen. Vielleicht hilft hier eines Tages die DevOps-Strömung weiter.

Die Fragmente sind dann bei weitem nicht immer auf einander abgestimmt. Es kommt vielmehr sogar vor, dass Prozesse wie beispielsweise Change Management mehrfach implementiert und zudem mit unterschiedlichen Zuständigkeiten und Werkezeugen realisiert sind. Das Management nutzt zudem das Prozess Management nicht zur Steuerung der IT, weil ihr Führungssystem nicht auf Services und Prozesse ausgerichtet ist. Siehe hierzu unser Beitrag zum Controlled Service Environment.

Grosse Organisationen haben also nicht nur Vorteile. Es ist gerade für den Mittelstand wichtig, dass sie ihre Vorteile nutzen und durch mehr Agilität und Flexibilität besser auf die Anforderungen ihres Business reagieren. Das ist im Bereich ITSM besonders wichtig.

Die 4 plus eine ITSM-Domäne
Was von ITIL ist nun wichtig für meine Organisation – was kann ich weglassen? Diese Frage stellen sich nicht nur die kleinen Organisationen. Auch grosse Organisationen sind nicht in der Lage, alle Themen gleichzeitig zu starten. Es wäre auch vermessen, einzelne Service Management Disziplinen generell als mehr oder weniger Wichtig zu deklarieren. Grundsätzlich sind alle Themen wichtig – sonst wären sie nicht als Best Practice erfasst worden.

Eine IT-Organisation muss sich jedoch den Herausforderungen stellen und eine kundenfokussierte IT-Dienstleistung ordnungsgemäss erbringen. Ich habe die wesentlichen Themen in folgende 4 Domänen aufgeteilt:

Die Vier plus 1 Domäne in ITSM

Die Vier plus 1 Domäne in ITSM

  • Kunden-Domäne: hier spielen sich alle direkten Kontakte auf Business- und Benutzerebene statt
  • Sicherheits-Domäne: hier geht es um die Einhaltung Sicherheitsvorschriften und den Schutz der Daten und Services
  • Sourcing-Domäne: Bei dieser Domäne dreht sich alles um die Bereitstellung der Ressourcen, sei es intern oder extern oder gar aus der Cloud
  • Technologie-Domäne: Letztlich ist die IT immer auch noch Technik, welche immer mehr in der Kontrolle des Endanwenders liegt und gleichzeitig mit den internen Technologie-Architekturen vernetzt werden müssen

Die „plus eine“ Domäne kümmert sich um Change & Control und soll sich damit um die ordnungsmässige Abwicklung der Änderungen kümmern und die Nachvollziehbarkeit gewährleisten.

Alle 4 plus eine Domäne sind für KMUs wie auch für grosse Organisationen wichtig. Das Service Management System ist das Führungssystem, welche diese Domänen zusammenhält und damit die Basis für mehrwertgenerierende IT-Services bildet.

Ich stelle im Folgenden die vier Domänen etwas detaillierter vor.

1. Kunden-Domäne

Die Kunden-Domäne des ITSM

Die Kunden-Domäne des ITSM

Es gibt drei Ebenen, bei welchem der Kunde mit der IT-Organisation in Kontakt tritt. Der Benutzer auf der operationellen Ebene im Wesentlichen über den Service Desk. Der Business-Manager auf der taktischen Ebene über den Service Katalog und das SLA durch den Business Releationship Manager und den Service Level Manager. Und letztlich der Geschäftsführer über die strategische Ebene und dem Service Portfolio Management und der Service Strategie.

Insbesondere das Service Desk, das Incident Management und der Service Katalog sind zentrale Elemente, um der IT ein Gesicht und eine Sprache zu geben. Wenn diese Schnittstellen zum Kunden gut realisiert und damit als Visitenkarte der IT-Organisation etabliert ist, dann kann sich hinter dieser Facette noch sehr viel Chaos verbergen, ohne dass damit das Image der IT leidet. Umgekehrt kann noch so eine gut strukturierte IT-Organisation mit einem lausigen Kunden-Interface nie den Kunden zufriedenstellen.

Eine wichtige Disziplin und damit auch ein ITIL-Prozess ist das Reporting. Die finanzielle und kundenseitige Berichterstattung über eine Leistungsperiode inklusive der sich abzuzeichnenden Trends.

Weitere Optimierungen nach der Umsetzung des Service Desk und des Service Katalogs sind im Bereich Service Request Modelle und Automatisierung von Bestellabwicklungen anzustreben.

2. Sicherheits-Domäne

Die Sicherheits-Domäne des ITSM

Die Sicherheits-Domäne des ITSM

Sicherheit kann nicht genügend betont werden. Dies ist nicht mit einem Tool oder mit den restriktiven Verboten von bestimmten Technologien alleine zu lösen. Sicherheit kostet – aber keine Sicherheit kostet viel mehr. Ein CIO handelt schlichtweg fahrlässig, wenn er nicht die notwendigen Schutzmassnahmen einrichtet.

Ein klares Rollenkonzept und ein Identity und ein durchgesetzter Access Management Prozess, welcher den Zugriff auf vertrauliche Systeme und Daten regelt ist ein absolutes Minimum.

Privacy – der Schutz der Privatsphäre – aber auch Cybersecurity sind heute die zentralen Themen in der Geschäftswelt. Damit ist die heute grösste Gefahr von Angriffen auf Unternehmen, Personen und Assets gemeint, welche oft mit krimineller Absicht begangen wird. Auch KMUs brauchen heute hier ein minimal Verständnis dieser Gefahren und müssen sich hinsichtlich wirkungsvoller Abwehr rüsten.

Letztlich gehört in diese Domäne auch ein Business Continuity Management sowie ein darauf abgestütztes IT Service Continuity Konzept. Eine einfache, aber mit dem Business durchgeführte Impact Analyse zeigt recht eindrücklich, was ein zeitlicher Ausfall von IT-Services und der Verlust von Daten tatsächlich bedeuten. Der hochgerechnete Schaden lässt geeignete Recovery-Massnahmen gut begründen.

IT-Organisationen, welche an der Planung des Business Continuity Managements scheitern, planen das Scheitern des Unternehmens im Ernstfall.

3. Sourcing-Domäne

Die Sourcing-Domäne des ITSM

Die Sourcing-Domäne des ITSM

Alles aus einer Hand ist heute eher die Ausnahme als die Regel. Grosse wie auch kleine Organisationen tendieren heute mehr den je, IT-Leistungen extern zu beziehen.

Die Frage nach dem Sourcing stellt sich sowohl auf der Entwicklungs- wie auch auf der Servicebereitstellungs-Seite. Gerade heute, wo Infrastrukturen, Plattformen und ganze Software-Applikationen als Service aus der Wolke bezogen werden kann, stellt sich berechtigterweise die Frage: warum selber machen.

Dieser Trend wird anhalten. Die IT kann sich diesem Trend nicht entziehen. Der Kostendruck ist schlichtweg zu riesig und der Fachkräftemangel zu gross, als dass mit dem Angebot Schritt gehalten werden kann. Das Business bezieht sich heute solche Leistungen mit der Kreditkarte via Internet und kann innert kurzer Zeit die Services nutzen.

Die Kontrolle über die IT ist deswegen aber nicht weniger wichtig geworden für die Organisationen. Auch KMUs müssen hier die Schnittstelle zwischen Business und Service Provider wahrnehmen und als Service Broker sicherstellen, dass Vorgaben, Kontrollen eingehalten und die operative Abhängigkeit minimiert wird.

Vendor- oder Supplier Management sowie die Definition einer mit dem Business abgestimmten Sourcing- und Cloud Governance sind zentrale Themen, welche auch ein Mittelständer umsetzen muss, um nicht ein Heer von unkontrollierten Schatten-ITs wie einen Sack voller Flöhe hüten zu müssen.

4. Technologie-Domäne

Die Technologie-Domäne des ITSM

Die Technologie-Domäne des ITSM

Die Technologie ist die Paradedisziplin der IT-Organisationen. Aber immer mehr geht die Kontrolle auf die Endbenutzer über und läuft Gefahr, der IT-Organisation zu entgleiten. Vorbei sind die Zeiten, in welchen die interne IT die Herrschaft und das Wissen der Technologie gehortet hatte. Die neuen Generationen von Anwendern wachsen mit dem Internet und all seinen Möglichkeiten auf. BYOD, Social Media und Mobilität sind eine Voraussetzung, um überhaupt gute Leute in die Unternehmen zu locken. Eine IT-Organisation, welche sich hier unter noch so gut gemeinten Argumenten versucht zu verweigern, wird früher oder später von der Realität überrannt.

Man kann den Regen nicht am Fallen hindern.

Plus 1: Change Control Domäne

Die Change Control Domäne des ITSM

Die Change Control Domäne des ITSM

Als letzte und doch auch wichtige Domäne ist die Steuerung aller Veränderungen an IT-Services, Verträgen und Technologien. Die IT ist heute dermassen in die Abwicklung der Business-Prozesse integriert, sodass die regulatorischen Anforderungen eins zu eins in der IT umgesetzt werden muss. Änderungen an den Abläufen und Systemen müssen nachvollziehbar sein und der CIO ist rechenschaftspflichtig über sämtliche Bewegungen der IT-Assets, Daten und Systeme.

Das Change Management ist eine der ersten Hausaufgaben einer noch so kleinen IT-Organisation, welche möglichst früh umgesetzt werden muss. Jedes noch so gut gemeinte „hey – Joe, mach mal schnell“ ist Gift in den Augen der Auditoren und letztlich nicht zu verantworten.

Und zu guter Letzt : Ein paar Umsetzungstipps
Mit drei Prozessen wird man die Sorge um ITSM nicht los. Zu gross ist die Verantwortung der CIOs, als dass man sich hier aus der Affäre ziehen kann.

Wenn die Themen aber auch vielfältig sind, können sich Mittelständer bei der Umsetzung aber doch einiges an Papierübungen sparen, welche grosse Organisationen zwecks Abstimmung und Aufklärung sich antun müssen.

Zudem empfehle ich, als erstes Buch der ITIL-Bibliothek das CSI zu verinnerlichen. Nicht den grossen Wurf mit allen Prozessen und Disziplinen des ITSM versuchen, sondern wenige, dafür machbare Schritte anzugehen. Die Philosophie von ITIL ist die Transformation der IT in eine lernende Organisation zu vollziehen. Die Welt verändert sich eh – und das Business wird seine Ansprüche entsprechend laufend anpassen. Die IT-Organisation muss damit Schritt halten können.

Hier noch zwei Hinweise zur pragmatischen Umsetzung:

  • Definition von klaren Rollen und Verantwortlichkeiten anstelle seitenweise Ablaufdiagramme und Dokumentation: wenn die Zuständigkeiten klar sind, dann erübrigt sich das Hinschreiben und Zeichnen von Aktivitäten und Diagrammen
  • Dokumentation von Standardabläufen: Sowohl im Incident als auch im Request-Fulfillment Bereich gibt es immer wiederkehrende Abläufe, welche einmal dokumentiert helfen, schneller und einfacher abgewickelt zu werden. Hier eignen sich die Prozesse besonders. Es gibt aber immer auch Fälle, welche erstmalig und einmalig bleiben, welchen sich die IT-Spezialisten annehmen müssen. Siehe hierzu den Buch-Review Beitrag „Standard+Case“.

ITSM ist auch für den Mittelstand wichtig. Es empfiehlt sich, sich mit dem Framework vertieft auseinander zu setzen. Ein externer, erfahrenerer Berater kann hier helfen, den Weg durch den Dschungel zu finden und als Lotse in der Organisation dem CIO den Weg aufzeigen. Und mein Traum der industriellen IT-Revolution wird vielleicht einmal wahr.


 

Private Cloud and the impact to the existing IT Service Management System

There are quite a lot of companies hopping the “private cloud train” the last months. Reasons for considering private cloud deployments are:

  • Business data have to be “on premise”
  • Industrialization, automatization, standardization of internal IT
  • Re-use of investments already made (virtualization, server, storage)
  • Development of internal skill sets supporting the move to a modern IT provider.

Most of such companies are running their IT under the governance of an IT Service Management System based on ITILv3 ®.

Question is: Are there any changes to the definition and implementation of the IT service management processes needed supporting the private cloud deployments?

Answer is yes, indeed, there are a couple of things that need to be reviewed, prioritized, communicated and trained.

  1. Considering a new customer/business perspective

Customers focus will shift to strategic discussion with IT rather than being busy complaining about number and duration of incidents. Very soon, they will be interested by when an under what condition they can move their applications to the cloud. This will be a discussion along Service Portfolio, Demand and Financial Management processes, followed by the definition of service quality parameters along the Service Level Management process. If the management system in place is not very mature (process capability wise) for all strategic processes, there are investments needed to develop IT capabilities supporting business relationship management on truly strategic level.

Importance/Comlexity of ITIL lifecycle phases from customer point  ((Will Cloud Computing Change Standards in IT Service Management?  Marc Jansen, Computer Science Institute)

Importance/Comlexity of ITIL lifecycle phases from customer point
((Will Cloud Computing Change Standards in IT Service Management?
Marc Jansen, Computer Science Institute)

The Service Catalogue in place is just a collection of application names and prices? Well, catalogue management supporting a private cloud service means:

  • Description of the cloud functionalities
  • Options and descriptions of service quality parameters (i.e. capacity bands)
  • Pay-per-use conditions in form of consumption units and real-time reporting options
  • Instanciation of a good portion of the service catalogue as executable service request catalogue (self-service portal).

Service Level Management and all service quality processes (Availability, Capacity, Security, Continuity Management) are needed to frame the conditions under which the private cloud services are going to be delivered to the business. For a lot of IT organizations, private cloud initiatives will be the starting point of investing in the maturity of the Service Design processes. The service model is new, service definitions are new, customer/business requirements and expectations are fresh and unexploited.

The second customer perspective, a rather operational one, will be the ability to self- manage the service functionality and non-functionality wise. Self-service management means no traditional interaction with the IT organization neither with service requests nor with incidents tickets.

  1. IT Process and Operation automation

Having talked about Self-Service capabilities: What does it mean to process automation?

Importance/Complexity ITI lifecycle phases from cloud provider view  (Will Cloud Computing Change Standards in IT Service Management?  Marc Jansen, Computer Science Institute)

Importance/Complexity ITI lifecycle phases from cloud provider view
(Will Cloud Computing Change Standards in IT Service Management?
Marc Jansen, Computer Science Institute)

First of all: Before anyone can automate something, it has to be defined. Sounds simple but the reality of a private cloud program will unearth process bodies and zombies a big deal. An automated service catalogue with a self-service portal is just a starting point:

  • Financial management: counting service consumption units (so called “metering” and real-time charging has to be defined and implemented. Consumption units are capacity volumes. Elastic and rapid increase and decrease of consumption of capacity volumes requires the automation of Capacity management.
  • Self-service management means the execution of service request in real-time based on defined standard changes. An automated Request Fulfilment process will trigger process automation for Change, Deployment and Configuration management.
  • Availability of a service is certainly one of the critical service parameters to the business. This will stay the same for private cloud services. However, Availability Management in the cloud will be different: The reactive part of availability management will become marginal; the proactive one has to be defined and implemented in an automated way. By re-thinking the consequences, there will be serious impact to the processes supporting availability: Event Management.
  • Event Management will become THE backend process where a lot of the IT business logic will have to be deployed to. Automated self-run (resilience) and operation control capabilities are needed. Same for Release Management. Hopefully, well-defined and implemented Event, Release and Deployment Management processes will impact the Incident Management too: Assumed, cloud end-users will not be affected by incidents the same way like it is with traditional IT Services, a new definition of Incidents is required, especially the demarcation of Events and Incidents (when an Event becomes an Incident) will have to be reviewed. Fighting incidents itself will also be an automated process with a good portion of IT business intelligence. Which will lead to the question: What will be the role of the first level (Service Desk, IT Operation) and the second level (usually Technical Services in the future? For Service Desk and IT Operation, there will be a decrease in responsibility and workload for sure. For Technical Services functions there will be a workload shift from Incident Management to Problem Management. And for Problem Management, same as for Availability Management, there is a move from reactive to proactive management needed: Problem Management will be based on the analysis of events and trend of events and not so much on Incident Management information.
  • Access management capabilities needed for private cloud are being sourced by three requirements: Self-service just-in-time, security aspects and consumption metering. Access management will have to automate the implementation of the combination of the three requirements: Authentication, authorization and accounting.
  1. Service Broker Capabilities

Private Cloud Services have their limits: Capacity volumes – and respectively business demands – are limited by the finite hard-and software stack “at-premise”. Almost infinite capacity would only be available by adding public capacity offerings to private cloud services. This discussion with the business will start very soon.

The theoretical concept behind the capability of the internal IT to enrich their private offerings with public services from the market is called “Service Brokering”.

Cloud Service Broker Model

Cloud Service Broker Model

Of the three Service Brokering models (see Gartner):

  • Cloud Service Intermediation
  • Cloud Service  Aggregation and customization
  • Cloud Service Arbitrage

the “Cloud Service Intermediation” model is one applicable for internal IT organizations. This model provides added value support on top of one or more existing cloud services (private) to enhance some specific capability of ‘said’ cloud services, without actually providing any of the cloud services itself (public cloud offerings).

Intermediation service capabilities may include identity and access management, service level management and reporting, security management and incident reporting, or supervision on pricing and billing. Intermediation services providers often also provide pre-contract consultancy services such as guidance of the cloud customer through the cloud selection process.

By looking to the requirements of such a model to the existing IT Service Management System in place, this model certainly will have an impact to the maturity of Supplier Management (supplier selection, service quality requirements and price models), Service Level Management (managing underpinning contracts), Security Management (business data ready for public) and Service Continuity Management (no internet – no service, complete vendor failures, contract exists and data availability).

Re-shaping the existing Service Management Model for private Cloud

All the above mentioned process capabilities have to be in place for an internal IT organization in order to become a private cloud service provider and a service broker on top of it.

Many IT organizations are making use of the already existing Continual Service Improvement Process (CSI) and addressing the gaps as part of the process. Other organizations start a dedicated project (some of them are using agile methods) to defined and implement the needed capabilities. And still others develop and implement a dedicated, new IT Service Management System (Cloud Operating Model) in parallel to the existing , traditional IT model and make use of a Cloud Migration Concept to transition traditional services into the cloud.