Overview Agile Service Management Value Chain

Agile Service Management Value Chain

«Agile» is the new must-have-attribute in all approaches, when it comes to moving into the digital future. Because “agile” promises the classic Gordian knot: better, faster and cheaper. Waterfall sounds old-fashioned and bureaucratic. Agile stands for open, creative, courageous and successful. New methodologies like DevOps, SAFe or the new kid on the block VeriSM are now the most sought-after management models in enterprises. COBIT, ITIL and classic project management methods have done their job, but they are far away from meeting the current challenges of the digital future. At least, these are the many responses from organizations that are struggling with the current management approaches to deal with the new reality.

So, it is not surprising that now even in the «Service Management » industry there are attempts to put a touch of agility into it. Because «agile» is the new «sex-sells», there are offered today new training courses, e.g. Certified Agile Service Manager from DevOps Institute.  Also we from Glenfis are an accredited partner of the DevOps Institute and  are offering CASM trainings. But what is sold here as a «Agile Service Manager» Training is indeed a Process design training, based on agile approaches like Scrum. The so called «Agile Service Manager» is the Scrum Master for ITSM Process design.

But Service Management is not process design in a first place. Service Management is all about planning, designing, implementing, delivering and supporting of Services with the purpose of delivering value to the business by realizing benefits, optimizing risks and optimizing resources. Of course, processes are important and needed. But does agile designed and implemented processes automatically lead to agile service management and service delivery? I have my doubts.

There are currently many evolving technologies in the areas of service development and service provision. Artificial Intelligence, Machine Learning, automation and Continuous Integration, Continuous Deployment (CI/CD) are key technologies that penetrate classic service management tasks. DevOps is currently the most common methodology to close the gap between developers and operators (link).  With Shift Left, all the requirements of the service operation should be tipped in the forefront of the requirements of the developers. So once realized in the solution, the developer may only press CI/CD-button and an automatic procedure is ensuring the integration, testing and implementation. Ultimately, there is no need for any additional operations – at least, that’s the vision. Not seldom developers speak a bit spitefully about DevOps is equal to NoOps. In fact, the idea is, that the combined Dev and Ops teams are building a new collaboration team which take full responsibility of building and delivering of Services: you build it, you own it, you support it.

Now – how does Service Management fits in this new world? Especially when you consider ITIL® V3 Edition 2011 with its 24 to 34 processes (depending how you are reading the books), there are no organization and service management experts who seriously want to consider their full implementation. In fact, the big number of processes have fragmented the area of service management, that the implemented processes often produced additional silos. And having these processes under control often results in bureaucracy. You cannot see the forest for the trees.

There are sure additional practices needed, which are not covered by DevOps today. For example, Services must be delivered, fulfilled and supported in the day to day operation. But how can this be done in an «agile» way?

How to adapt the Agile Manifesto to Service Management?

The «Manifesto for Agile Software Development» is seen as the 10 commandments in the software development Bible. In fact, there are only four recommendations, which needs to  be considred. These four recommendations are read like a vow and are often referenced.

Because the Manifesto has been defined within and for development teams, we should use the spirit and try to translate it in our service management view.

It could be like this: In our Agile Service Management work we have come to value:

  • Individuals and interactions over processes and tools: Interactions with our customer, users and partners are much more important than just using (to hide oneself behind) processes and tools
  • Working software over comprehensive documentation: Delivering stable and reliable services that create customer and user experience is much more value than producing comprehensive documentation.
  • Customer collaboration over contract negotiation: A happy customer is much more important than comply somehow negotiated Service Level Agreement (see also our blog: Service Level Agreements Fulfilled. Customer Unhappy)
  • Responding to change over following a plan: In our rapid changing world, we always respond to business requirements instead of insisting on previously defined and now outdated plans

These principles are not new to service management organizations. These are the basic ideas and values behind ITIL and Service Management and will hopefully be shared to all students by good training providers. But when it comes to the bottom um Service Management, people see only the fragmented processes. Each process has its purpose – but the big picture how to achieve the principles and the value often get lost.

So how can «agile» bring more value in the Service Management approach and is it still necessary? I like the blog post from Steve Denning where he discussed the question What Is Agile?. Agile is not only reserved for software development, but is a basic attitude on how to work. Agile behavior can therefore also be used in service management. If we want to be successful with agile and truly reap the benefits of what we expect to get from agility, then we need to embrace agile throughout the full value chain.

That’s why I like the concept of Value Chain which is in the heart of DevOps. Because speed and flexibility are key in today’s business and IT, we need to better understand the customer needs and applying service design thinking. We do not need to think in processes, but in value flows. We must understand the tasks to be done to deliver value from the beginning of the flow until to the end. We must understand and identify the main value chains in our service organization.

But Value Chains are not by default also agile. Important here is that there is a common and agreed mission about always focusing on delivering value to the business. This needs to be shared within the entire service management team. There is team spirit and culture of communication and passion needed with short feedback loops and everybody’s willingness to allow changes for the customer’s competitive advantage. Through chaining the practices within the value stream, the activities follow always a shared goal and mission with satisfying customer is highest priority. The seamless collaboration within each practice and the entire value stream must be reviewed at regular intervals and adjusted as needed. The goal here is to let the value stream flow as smoothly as possible without queuing.

Concept: Agile Service Management Value Chain

The following approach is a suggestion from my side, which I have not shared yet with other experts. I want to throw a stone into the water here to trigger the discussion. The model is far away to be finished. However, I have been inspired by the different methods, in particular by IT4ITTM from the Open Group where I have used basic thoughts and adapted my diagrams.

Overview Agile Service Management Value Chain
Overview Agile Service Management Value Chain

The Agile Service Management Value Chain consist in my view of the following three Value Streams:

  • Service Innovation: The main purpose and goal of this value stream is to achieve competitive advantage, business innovation, and improved operational effectiveness and efficiency by exploiting information technology developments. Service Innovation can be called the Value Stream where today the DevOps methodology is used.
  • Service Fulfillment: The main purpose and goal of this value stream is to ensure that services and service levels meet current and future needs by creating improved outcomes, increased confidence, trust in IT and effective use of resources.
  • Service Support: The main purpose and goal of this value stream is to achieve increased productivity and to minimize disruptions through quick resolution of incident; and to increase availability, to improve service levels, to reduce costs, and to improve customer convenience and satisfaction by reducing the number of operational problems.

The big advantage is to keep focus on the value streams instead of getting lost in the various processes which are confusing today service management organizations. The main purpose of the agile service management chain is to deliver value and outcome to the business and to ensure transparency in all their activities.

There are important supporting practices which are needed throughout the whole agile service management chain. I rather call them practices instead of processes, because they can be implemented less formal.

The following four practices are important supporting activities in the value chain:

  • Financial & Resource Management: Resources includes people, technology, information and financial assets. They are needed throughout all three value streams. Financial transparency is key in this practice.
  • Service Asset & Configuration Management: this is a key practice well known from ITIL, where the information and configuration assets need to be planned, controlled and provided in all three value streams.
  • Information Security & Data Protection: Information is the currency of the 21st century and must be protected from cyber-attacks. The security and data protection requirements must be considered in all practices within the three value streams.
  • Governance, risk and compliance: GRC are in the accountability of the governance board and management of every organization. This must be ensured within all three value streams

An important aspect here is also the concept of continual service improvement (CSI). This can be seen as the retrospective within each value stream and across all value streams or the entire value chain. But also the three ways from the DevOps movement shall be used to learn, understand and increase the flows, creating short feedback loops and a culture that fosters experimentation, taking risks and learning from failure. This is different from the pure lean approach, which is focussing only on waste. Understanding that repetition and practice is the prerequisite to mastery and that enables continuous improvement with the freedom of creativty and renewal. And here is where the mentioned certified agile service manager (CASM) may  be demanded. With his agile, Scrum approach to design and re-design practices and processes he should define them with just enough control and structure.

The Agile Service Management Value Chain is representing the operation model of a service organization and is not limited to an IT organization. So, it should be easy adaptable for any enterprise service organization as well. It is important that there is a clear accountability in the top management for the whole value chain.

The following value streams are now more detailed. Each single value stream should be assigned to an accountable manager with leadership and coaching skills to ensure seamless integration of each practice.

Service Innovation Value Stream

Service Innovation Value Stream
Service Innovation Value Stream

The Service Innovation Value Stream reflects main practices out of Service Strategy, Service Design and Service Transition. I have identified the following 4 main practices, which must be coordinated and integrated:

  1. Service Demand & Portfolio Management: In an agile way, new demands from Business and from Lifecycle-Support needs to be reviewed, evaluated, proposed and monitored. Every new or changed service is linked to a service blueprint (conceptional service)
  2. Requirement Management: For every agreed service proposal, the requirements need to be identified and analyzed. Besides the functional requirements, all the non-functional and operational requirements need to be identified. Here practices from Availability Management, Capacity Management, Risk & Compliance Management, Information Security Management and Business Continuity Management can be used. To each of the requirements, a test case must be specified.
  3. Development & Test: The solution can be either sourced, procured or coded inhouse. But the service must be developed based on the requirements and test need to prove the acceptance.
  4. Release, Integrate & Deployment Management: The practices from Release & Deployment Management can be used here. Integration will be a more and more important challenge for organization because multiple external services and suppliers need to be orchestrated and integrated. Infrastructure are often used directly in the integration scripts as a line of code.

How to get an agile Service Innovation Value Stream: The common vision and goal of this value stream is: to achieve competitive advantage, business innovation, and improved operational effectiveness and efficiency by exploiting information technology developments. Th focus needs to be always on business innovation. Agile team needs assembling a portfolio to meet the business needs from different sources and to deliver against the business demand by focusing on the business impact first. This will help to define the product backlog and to prioritize the user stories to be developed. To meet the continuous delivery goals, testing needs to be closely integrated into the development process, allowing a quickly and consistently deploy of service.

As already mentioned, this value stream is currently implemented in many organizations using DevOps methodology.

Service Fulfillment Value Stream

Service Fulfillment Value Stream
Service Fulfillment Value Stream

The Service Fulfillment Value Stream reflects the normal service delivery practices of today. But in future, this must be implemented in a much more interactive way. Users want to see in their portal the available services, their terms of use, the costs and the immediate availability after subscription. The service costs need to be made transparent and accurate.

This includes business services and service requests as well. I have identified the following 4 main practices, which must be coordinated and integrated:

  1. Service Portal & Catalogue Management: All new services from «Service Innovation Value Stream» and agreed external services from different providers (like cloud providers) must be consolidated and integrated in an internal service catalogue. Within the user portal, each user can see all services he can have access too. He will see all subscribed services, service reports and costs and can manage them.
  2. Service Agreement & Subscription: The user can request a service which may involve a workflow for getting financial and functional approvals. The service agreements and costs are transparent and with the subscription the agreement is done.
  3. Service Orchestration & Delivery: After successful subscription, the service mast be made available. If there are components to be deployed or delivered, automatic fulfillment procedures (standard changes) must be started. This can include external suppliers (for example a PaaS-environment for developers).
  4. Service Monitoring, Reporting & Chargeback: Service usage will be monitored and tracked. This can include different sources from integrated IT-Services in the hybrid environment. The service reporting practice needs to consolidate the usage and make reports available to the users.

How to get an agile Service Fulfillment Value Stream: The common vision and goal of this value stream is: to ensure that services and service levels meet current and future needs by creating improved outcomes, increased confidence, trust in IT and effective use of resources. In an agile world, we are living with dynamic changing service catalogue items and service delivery partners. We are moving to a world of more automated services and configured when ordered. The Service Portal needs to support the customer and user experience regarding timeliness, reliability and transparency. Fulfillment processes are based on automated workflows and needs only be managed by exceptions. Workflows are constantly optimized for consumption.

Service Support Value Stream

Service Support Value Stream
Service Support Value Stream

The Service Support Value Stream reflects the normal service support practices of today. Even if services are developed and delivered more stable, there will issues to be solved. A lot of new technology is coming in this field like chat bot and machine learning which enhance current supporting activities. These practices need to be implemented to increase the productivity and to minimize disruptions through quick and sustained resolution.

I have identified the following 4 main practices, which must be coordinated and integrated:

  1. Event Management: This practice is well known in ITIL and should support in detecting irregular system behavior. With the usage of AI functionality, failures should be prevented and solved, before a user get notice of the problem.
  2. Incident Management: This practice is sure still an important one in the future. Also, a service desk might be used besides of chat bots to get user issues registered and solved as quickly as possible. Ticket integration with involved suppliers should be automated and the progress needs to be tracked.
  3. Problem Management: Recurring problems must be analyzed and their errors identified. Existing error-databases from involved suppliers can be integrated to faster find the root causes.
  4. Change Management: Identified Errors need to be corrected using change management practices.

How to get an agile Service Support Value Stream: The common vision and goal of this value stream is: to achieve increased productivity and to minimize disruptions through quick resolution of incident; and to increase availability, to improve service levels, to reduce costs, and to improve customer convenience and satisfaction by reducing the number of operational problems. Within this value stream, the focus must be on predictive and automatic triage. Here, Artificial Intelligence and Machine Learning will be new technologies to help to prevent incidents and proactive resolutions. A close DevOps collaboration is needed to prioritize solving processes. The user must always have a sincere feeling that his issues are taken seriously and resolved to his satisfaction.

Conclusion to Agile Service Management

As mentioned, this is not a complete model of Agile Service Management. But what do you think: would it help to use the concept of Value Chain to better transform traditional Service Management organizations in a more agile and hopefully value delivering service management organization?


 

16 Kommentare zu «Agile Service Management Value Chain»

  1. Hallo Martin,

    allerorten hören wir vom agilen Service Management. Wie geht ITSM und agil zusammen. Gut, dass Du die Diskussion anstößt!

    Grundsätzlich gehe ich davon aus, dass agil erstmal eine Grundhaltung, Geisteshaltung und ein Standpunkt ist, der sich an den Handlungen und dem Verhalten jedes Einzelnen in der Organisation ablesen lässt. Und das zu erreichen dürfte der schwerste Teil der Aufgabe sein.

    Zweite Hypothese: Agilität bedeutet wendig – schnelles Reagieren auf sich ändernde Rahmenbedingungen. Nur wenn Wendigkeit einen Wert hat, hat es Bedarf nach Agilität.

    Nun ergeben sich für mich Fragen:

    1. Was hindert uns daran die Organisation mit den bestehenden Prozessen wendiger zu machen? Das “Mindset” zu entwickelt, dass es dafür braucht?

    2. Warum eine neue Wertschöpfungskette? Warum nicht mit IT4IT arbeiten und dieses ausgestalten? Ja, es ist größer als ITSM – und genau das finde ich daran gut.

    Zu Deiner Frage, ob ein Wertkettenmodell hilft. Sicher hilft das – allerdings finde ich es spannender im Unternehmen zu schauen, wie die Wertschöpfung stattfindet – inkl. IT. Also wie wird Geld verdient und welchen Beitrag leistet IT. Ansonsten besteht schon die Gefahr, dass das wieder eine Nabelschau wird, oder?

    Robert

  2. Martin, seit meinem ersten Kommentar schwirrt mein Kopf und ich kann nicht schlafen …

    Ist eine Wertschöpfungskette agil? Ne, oder? Es kommt doch darauf an, wie die Prozesse oder Practices gestaltet sind, oder?
    Warum ist DevOps so wendig (Du schreibst flexibel und schnell)? Weil die Menschen die richtige Einstellung haben – die DASA beschreibt das so: https://www.devopsagileskills.org/dasa-devops-principles/ – auch hier wieder das Mindest im Vordergrund. Und da ist der Value Chain Ansatz wie gesagt durchaus hilfreich.
    Weil die richtigen Werkzeuge verwendet werden.
    Was sind die Werkzeuge: Scrum, Kanban, Automatisierung, Qualitygates (Defininition of ready, Definition of Done, automatisierte Tests, …), Transparenz, Messen usw.
    Für mich heißt es, dass wir Ideen entwickeln dürfen, wie wir vorhandene Werkzeuge in den ITSM Prozessen einsetzen können, um wendiger zu werden und um den Kunden besser im Blick zu haben. Und wir dürfen auch neue Werkzeuge entwickeln. Da sollte unsere Energie reinfließen, oder?
    Der Agile Service Manager hat ja genau den Ansatz. Dort adaptiert das DevOps Institute (krampfhaft) Scrum auf das Prozess Management im ITSM. Warum nicht. Dierk Söllner nannte es mal adaptives Prozessmanagement. Warum nicht, wenn es hilft.

    Robert

    1. Danke Robert für Dein Feedback. Ja – Du hast recht. Ich habe Deine Anregung aufgenommen und den Blog angepasst mit dem Hinweis, was denn Agilität ausmacht. Für mich ist der Value Stream Ansatz dahingehend ein Vorteil, weil es übergreifend die Vision und das Ziel festlegt. Heute sind die vielen Prozesse oft sehr fragmentiert und mit jeweils individualisierten Zielen versehen, welche sich gegenseitig nicht immer unterstützen. Dabei geht das Übergeordnete oft unter.

  3. Hallo Martin,

    der Ansatz Valuestream ist in gut. Der erste Schritt ist die Ende-zu-Ende-Verantwortung zu verstehen. Der zweite und die nächsten Schritte sind dann wirklich “Agilität” in die einzelnen Prozesse zu bringen. Wie wir einzelne Prozesse “agil” gestalten, darüber würde ich gern diskutieren.
    Robert

  4. Hallo Martin,

    vielen Dank für Deinen Gedankenanstoß!

    Allerdings verstehe ich den Mehrwert Deines Vorschlags gegenüber IT4IT im Originalzustand nicht. IT4IT selbst verschließt sich durch sein Design ja nicht agiler Vorgehensweise. Im Gegenteil, es ist bewusst offen, und legt weder Agilität noch Wasserfall fest.

    Es mag einen Mehrwert geben, ein vereinfachtes IT4IT-Modell zu haben. Denn so lese ich Deinen Artikel primär:

    1) Vereinfache IT4IT etwas durch Zusammenlegen von S2P und R2D (gleichwohl dazwischen immer der Meilenstein und das Quality Gate “go/no-go” liegt) sowie durch Weglassen und Neuanordnung von Functional Components.

    2) Weise explizit in einigen Absätzen darauf hin, wie agile Methoden entlang der Value Chain Verwendung finden sollten.

    Nun steht aber, was 1) betrifft, IT4IT im Original einer Vereinfachung im Sinne einer Fokussierung auf die zunächst für meine Organisation/meinen Kontext notwendigen Value Streams und Functional Components überhaupt nicht entgegen. Pick & Choose geht auch mit dem Original. Die Einführung neuer Value Stream-Namen bringt dann eher Konfusion und verwässert den wichtigen IT4IT-Beitrag des eindeutigen Vokabulars.

    Und was 2) betrifft: Agilität wird weder durch IT4IT verhindert noch explizit vorgeschrieben. Also, wenn ich agil entlang der Wertschöpfungskette sein möchte, dann sollte ich das tun. Aber unter Anwendung von IT4IT. Meines Erachtens braucht man dafür kein neues Modell.

    Herzliche Grüße!
    Marc

    1. Hallo Marc,
      danke für Deinen Input. IT4IT ist kein Prozess-Modell sondern eine präskriptive Referenz-Architektur für Tool-Lieferanten. Du hast recht – das Modell IT4IT bietet eine Grundlage und hat für meine Überlegungen auch die Basis gelegt. Ich bin ein grosser Fan von IT4IT wie Du aus meinem Blog entnehmen kannst – ich bin sogar im IT4IT Forum beteiligt.
      IT4IT greift aber in der Diskussion um Agilität grundsätzlich etwas zu kurz und ist durch seine starre Vorgabe eher hinderlich, wenn es darum geht, selbstorganisierend im Team den Weg zum Ziel zu definieren.
      Ich wollte hier den Spagat aufzeigen und damit die Brücken schlagen. Ich sehe die Prozesse hier in meinem Modell eher als Praktiken und weniger stringent. Wichtig ist das übergeordnete Ziel, das in den Value Streams zu erreichen gilt.
      Und ja – Du hast recht bezüglich dem Naming. Ich kann hier nicht die Nomenklatur von IT4IT nehmen, weil ich damit die IT4IT Architektur missbrauchen und die Bedeutung der Begriffe verändern würde. Und im Bereich Service Management von ITIL oder anderen Frameworks haben wir nun mal nichts in dieser Richtung.
      Wichtig war mir vor allem auch, die Diskussion anzustossen. Und das scheint mir doch etwas gelungen zu sein.
      Danke nochmals für Deinen Input.
      Gruss
      –Martin

  5. Zahra Rahemtulla

    Marten – I really like this model because it takes the traditional ITIL model and really turns it around to a true Service model with flexibility, agility and the velocity that businesses require. It also does not take away from the intended and always true purpose of Service Management – delivering value to meet business outcomes by organizing accordingly.

    I have a question for you on roles – do you see the “traditional” role of the Process Owner going away in favour of the Service Owner taking on more accountability? Which service mgmt. roles would I ensure are part of an Agile Scrum team to represent services that the product owners are building.

    1. Hi Zahara,
      thank you for your feedbback. Indeed, the new agile and DevOps movement change the focus to the more holistic and end-to-end service and value stream view. This has been the long time critics to the often bureaucratic implementation of ITIL processes.
      And to your question concerning roles: yes, traditional process owner roles are going away or at least are secuondary. The mission and goals for the service owner (product owner) and value stream owner are primary and are accountable for the value to achieve. How the processes are used and defined is up to the teams. Important is, that necessary controls are identified and part of the service. But how it has to be done, should be defined by the teams. Service Management processes will be just practices which can be used within the value streams – but should be considered and managed isolated.

    1. Danke Helmut, dass man sich im Service Management anfangen musste, umzudenken, das hat sich schon lange abgezeichnet. Zuviel wurde falsch und schlecht umgesetzt. Nur – ob man nun etwas gelernt hat, muss sich noch zeigen.

  6. Hallo Robert,
    ich bin erst heute auf die Seite gestoßen und möchte auf Deine Frage “Was hindert uns daran die Organisation mit den bestehenden Prozessen wendiger zu machen? Das „Mindset“ zu entwickelt, dass es dafür braucht?” antworten.

    Natürlich brauchen wir eine Zielvorstellung, wie die Prozesse künftig gestaltet sein sollten bzw. welche Praktiken wir auf welche Weise nutzenbrigend (wertschöpfend) einsetzen können. Und brauchen eine passende Kultur und ein passendes Mindset der beteiligten Personen.

    Aber: Organisationen mit bestehenden Prozessen sind nicht reformierbar! Man kann sie nur zerschlagen. Es wird einem also nichts anderes übrig bleiben,die neuen Prozesse parallel neu aufzubauen. Die Menschen als Einzelpersonen kann man dabei mitnehmen – aber nicht als unveränderte Gruppen im Kollektiv. Dann sind die Beharrungswiderstände zu groß.

    Für mich gibt es drei auf einander aufbauende Orientirungen:
    * Prozess-Orientierung
    * Service-Orientierung
    * Agile Orientierung

    Der Vorteil der Prozess-Orientierung ist die Trennung in wertschöpfende (Kern-P) und nicht-wertschöpfende Prozesse (Unterstützungs- und Führungs-P). In einem Kernprozess kann jetzt jede Aktivität auf ihren Wertschöpfungsbeitrag untersucht und ggf verändert oder gestrichen werden. Bei den Unterstützungsprozessen kann die Notwendigkeit hintrfragt werden, um sie zu streichen. Bei vorhandener Notwendigkeit können sie auf das Minimum reduziert werden. Idealerweise werden sie aus der eigenen Organisation an einen Dienstleister ausgelagert. Die Dienstleister stehen dann in einem reinen Preiswettbewerb, wobei die Einhaltung der Prozessqualität überwacht werden muss (= preiswert statt nur billig)..

    Bei der Service-Orientierung ärgere ich mich darüber, dass ITIl bis heute kein Service-Qualitätsmodell hat. Ein Service ist und bleibt im Reifegrad 1 ein Leistungsbündel aus materiellen Gütern (Hardware), immateriellen Gütern (Software) und Dienstleistungen zur Unterstützung eines geschäftlichen Zwecks. Dass ITIl 4 jetzt auf Wertschöpfungsketten abzielt ist nach der Übermodellierung mit dem Lebenszyklus ein Fortschritt, aber Business IT-Alignment wurde schon mit ITIL 2 propagiert. Service-Orientierung ist für mich vor allem die Einführung einer Abstraktionsschicht zwischen einem äußeren Service (= Service-Nutzung) und einem inneren Service (= Service-Erbringung). Damit wird die Bereitstellung eines Service unabhängig von der Technologie der Service-Erbringung und damit flexibel. Die Fokussierung auf den Nutzen in der Beschreibung des äußeren Service sorgt nicht nur für das Business Alignment, was den Wertschöpfungsbeitragf erhöht, und die leichtere Austauschbarkeit von Service-Providern, was durch größeren Wettbewerb die Wirtschaftlichkeit verbessert. Es sorgt sondern auch dafür, dass Service-orientierte Prozesse (und nicht nur die Services) nicht mehr aktivitätsbasiert, sondern nutzenbasiert beschrieben werden. Im Zuge von ITIL 4 und ISO 20000 ist jetzt viel von Enterprise Service Management die Rede. Ich hoffe, dass endet nicht so wie beim Enterprise Architekturmanagement, welches als Gesamt-IT-Architektur management missverstanden wird. Nach meinem Verständnis ist Enterprise als Klammer zwischen Business und IT zu verstehen, weshalb es auch im Business ein Business Servicemanagement (und Business Architekturmanagement) geben sollte, wie in den ursprünglichen Konzepten einer Service Orientierten Architektur (SOA) vorgesehen.

    Während Prozess-Orientierung der Rationalisierung der Unterstützungsprozesse dient und Service-Orientierung die Optimierung der Kernprozesse verfolgt, bleibt es nun der Agilen Orientierung vorbehalten, die Führungsprozesse anzugehen. Neben der eingangs diskutierten Frage, wie bestehende Prozesse (gemeint sind hier die Kern- und Unterstützungsprozesse) verändert, d. h. agiler gestaltet werden können (natürlich nur, wenn Agilität hier auch einen Wertschöpfungsbeitrag liefert), sehe ich hier die zweite große Herausforderung. Zunächst einmal wird es weiter das Top-Management für die startegische Führung geben, während auf operativer Ebene sich die Teams selbst organisieren und vor allem durch die geforderte Wertschöpfung faktisch gesteuert werden. Was ist aber mit dem gesamten mittleren Management, also Personen die ihren Status, ihr Einkommen und ihre Karriere mit der Zuordnung einer Rolle innerhalb der Hierarchie verbinden. Gibt es die Hierarchie nicht mehr (Lean), ist auf ihr Selbstverständnis und ihre Selbstrechtfertigung in Frage gestellt. Vielleicht sind diese Personen ursprüngich nur als Folge der Bürokratisierung der Prozesse entstanden, jedenfalls sind sie heute ein Treiber für diese Bürokratisierung. Ich habe schon öfters Unternehmen darauf angesprochen, die stolz ihre Konzepte für agile Arbeitsweisen präsentiert haben. Wie in den dann notwendigen Transformationsprozess das mittlere Management einbezogen werden soll, konnte ich keinem der Konzepte entnehmen. Dieser Personenkreis kann aber die Transformation weitaus nachhaltiger behindern, als ein evtl. unzureichendes Mindset auf operativer Ebene.

  7. Hallo Volker,

    danke für Deinen umfangreichen Gedanken!

    Wenn ich das Wort “zerschlagen” richtig interpretiere, dann verzichten wir auf die Erfahrung und das Wissen der Mitarbeiter in den Prozessen und bauen auf grüner Wiese was Neues auf? Ich glaube, dass keiner Zeit hat, sich nebenbei noch mit einer komplett neuen Prozesswelt zu beschäftigen.

    Ich denke schon, dass es Prozess für Prozess eine Veränderung geben kann. Voraussetzung: KUNDENORIENTIERUNG. Wir müssen den Kunden in den Mittelpunkt unseres Handelns stellen. Wir müssen uns immer fragen, ob das was wir tun, dem Kunden hilft, seine Probleme und Jobs zu lösen. Dann kommt die Serviceorientierung, dann die Prozessorientierung. Haben wir da “alles richtig” gemacht, sind wir agil 😉 ODER?

    Robert

    1. Hallo zusammen,
      spannende Diskussion. Ich finde die Fokussierung auf den Kunden und was für das Unternehmen einen Mehrwert bringt, ist eines vom Wichtigsten überhaupt. Zentral ist auch das in der neuen ITIL Version hervorgehobene Co-Creation beim Mehrwert und Service. Hier müssen wir lernen, einen Schritt weiter zu gehen. Wir sollen uns nicht nach irgendetwas orientieren, was wir denken, das Richtige zu sein. Wir müssen es gemeinsam mit den Kunden tun. Gemeinsame Ownership für Services und den damit anvisierten Mehrwert – und damit auch gemeinsame Ownership der Risiken. So eine strategische Partnerschaft zwischen Business und Provider wird eine Herausforderung für die Zukunft – und die Anerkennung als strategischer Partner kann man sich nicht selbst auf die Fahne schreiben, die muss man sich verdienen – durch Tatbeweis und Vertrauen.

      Und auch eines der Grundprinzipien von ITIL4 ist: Start were you are. Der Begriff “Zerschlagen” ist daher wohl eher sinnbildlich gemeint. Man muss die Krusten aufbrechen, damit bin ich völlig einig. Aber man muss es mit den Leuten gemeinsam tun. Zerschlagen tönt auch nach Big Bang: alles weg und alles neu. Was ja nicht unbedingt nach agil aussieht. So ein Vorgehen birgt Widerstand und überzeugt die wenigsten Mitstreiter, welche man aber braucht, um Service-Fähigkeiten zu entwickeln.
      –Martin

Kommentar verfassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert