My colleague @Ian Leu recently published the excellent article "Digital Product Value Stream Management Architecture Blueprint" here in this community. As a ServiceNow Enterprise Architect and certified ITIL®4 Strategic Leader, this gave me the idea to reflect a bit on the discipline of Value Stream Management from an IT Service Management (ITSM) perspective.
ServiceNow customers working in ITSM spend a lot of time thinking about and perfecting their processes. We are very supportive of this as well. Not least with the very sophisticated means of Process Optimization.
But if we focus exclusively on the processes and disregard everything else, then this could be a misguided path. In this article, I'll explain why it's important to think of ITSM operations in terms of value streams and not just processes.
What's the difference between a value stream and a process?
There is a lot of confusion about the difference between value streams and processes. The distinction is often difficult to make because both value streams and processes describe how activities work together to accomplish something. So, what is the difference? Here are the definitions from ITIL 4 to start the discussion.
Value Stream: A series of steps an organization undertakes to create and deliver products and services to consumers.
Process: A set of interrelated or interacting activities that transform inputs into outputs.
Each value stream begins with a demand or an opportunity and ends with the creation of value for one or more stakeholders. For example, the demand might be that an IT organisation is asked to develop a new service to help sales teams improve digital sales channels with support from artificial intelligence. The result, the value created, would be the resulting increase in sales.
Each process produces clearly defined outcomes. ITIL incident management is the practice of restoring services as quickly as possible after an incident. But this may not lead directly to value for a stakeholder; this incident process only creates value if it is part of a larger value stream.
A typical value stream includes many different processes that all need to work together seamlessly to maximize value. We know this very well in IT. The value stream view in IT operating models is not new. For example, IT4IT's Target Operation Model is based on a value chain with four authoritative value streams: strategy-to-portfolio, requirement-to-deploy, request-to-fulfill, and detect-to-correct.
It is very easy to imagine that improvements can be achieved by optimizing individual processes. In practice, optimizing individual processes can have the opposite effect of what you intended, because an improved process can have a negative impact on other processes in your organization that was not considered or expected. We have seen this time and again in the last 25 years when ITSM implementation projects have remained unsuccessful because the Incident process has already been improved for the third time, but the change process, for example, has not even been started. Only those who keep an eye on the big picture can recognize what really needs to be improved.
To achieve major improvements while minimizing risk, you need to improve the entire value stream, not just individual processes.
Example of a value stream for a changed service
This example is based on an episode that occurred at a large industrial company in Germany. There were many complaints that the introduction of Request Management only made the handling of requests more bureaucratic, but not better. So, the IT department decided to overhaul its request management.
In typical fashion, the request manager and the staff they work with sit down and figure out how to streamline their process to reduce overhead. However, this organization understood that it was much better to look at the entire value stream, rather than just focusing on that single process. It engaged an enterprise architect to review and improve the entire value stream for its requirements.
In many cases, the value stream began when employees were hired, or when they changed their position within the company because then there was a sudden need for new software, hardware, services, entitlements, etc. The value stream ended when the delivered good was successfully used by the users.
This meant that the enterprise architect was not only concerned with processes. His job was to consider people, processes, technologies and suppliers (what we would now call the four dimensions of service management) to optimize the entire value stream and ensure it delivered value.
The result was an impressive transformation of request management. Under the old system, requests were usually made by people who themselves needed something new or something changed. Often the need would have been foreseeable much earlier, and the request was made very late. Also, there was then a delay while the requirement was evaluated and approved because there was no context for it.
The new system focused on optimizing the value stream. The requirements were embedded in processes that the HR organization was responsible for. For example, a new office employee always needs an adequate IT workstation. As soon as all necessary information was collected, the order could be triggered. Requests were no longer delayed by additional approvals because this fact of need was out of the question in this context.
This example shows very strikingly that improving the entire value stream is much better than improving the individual process. It is not very helpful to always think about the results of a single team. It makes more sense to think about how things are done across the enterprise working together to create value.
The enterprise architect connected workflows from HR service delivery and from IT request fulfillment processes, which, by the way, worked very quickly and easily thanks to the implementation on their ServiceNow platform. The two value streams, Hire-to-Retire and Request-to-Fulfill, were connected, and the value was increased in both.
Conclusion
Processes can be very helpful but optimizing a process may not make a difference to customers. If you really want to help your customer, then look at the value streams and optimize them.
ITIL insiders will have noticed that many of the things I discuss here are in line with the ITIL Guiding Principles, which are:
- Focus on Value
- Start where you are
- Progress iteratively with feedback
- Collaborate and promote visibility
- Think and work holistically
- Keep it simple and practical
- Optimize and automate
Finally, if you've never thought about what you do in terms of value streams, you have a great opportunity to improve in a way that your customers feel a real difference.
How do I recognize and define Value Streams?
The value stream approach comes from Lean Management. Lean IT is also the ideal framework for identifying and optimizing value streams.
Lean management: 5 steps to optimize the value stream
The first step is to identify the value stream. As a rule, the focus is always on the customer: which products and services are purchased by the customer? What is the customer's view of quality, performance, and their costs? What is the customer willing to spend money on and what is the concrete added value? Where does this request start with the customer and where is the result, the service or the product handed over and how does the performance unfold as added value across the various stations of the organizational units involved.
This consideration must now take place independently of documented processes, tools, or functions in order to obtain the real, realistic and, above all, currently lived picture. In this way, the value streams can be identified in a first step. The focus is primarily on the value streams with the greatest benefit, potential in terms of feasibility for the customer and for the service provider.
The second step is to perform a so-called value stream mapping. This is now a central task, whereby the actual process is analyzed and recorded step by step. This is also where the dependencies and media discontinuities become apparent. Which situations require additional information and clarification? How is the data passed on, what remains where and, above all, what is waited for and why? Which tools are used where and when. It is possible to refer to existing documentation - but it is important that the real world is mapped. Once the entire picture has been established, then the current status of the "big picture" for the value stream can be represented well.
Often this "big picture" is missing in organizations because everyone in their function and process is trying to do the best for the customer. Only when the entire picture becomes transparent can it be quickly recognized where problems, delays and unnecessary clarifications impair and slow down the flow of the value stream. Now, based on a common view of the targeted value for the customer, the flow can be optimized, leaner and faster.
A Value Stream Mapping Workshop with all participants is an extremely enlightening experience. The joint wow effect and the resulting identification of the participants with the value stream and thus with the service or product for the customer is priceless. The people involved no longer see themselves merely as a function or part of a process, but recognize their contribution to the generation of added value and thus the meaningfulness of their work.
How can ITIL4 help to shape the value streams?
With the new version of ITIL, the focus has been deliberately placed on added value. Not processes, not practices, not services or products are in the foreground. It is the added value that is to be created for the company, the business or the end customer.
The Service Management System under ITIL4 is now based on a Service Value System and on the principle of Value Chain and Value Streams. There is only one Value Chain for the organization, but a multitude of Value Streams. ITIL4 has not specified or predefined these Value Streams. There is a good reason for this: the only correct and valid value stream in this form does not exist because it is different for every organization and every service. Just as there are different companies with different products and services.
The service value chain in ITIL 4 is essentially an operating model that lists the six key activities necessary to create value with a product or service – plan, engage, design and transition, obtain/build, deliver and support, and improve
Each value stream to be mapped affects several or even all of these activities. These value streams can contain a wide variety of processes that are explicitly tailored to the specific value flow for the service.
In ITIL4, 34 practices have been identified and described which can be used to implement the 6 activities in the value streams. In these practices, the necessary processes, skills, information, tools and interfaces to be considered at providers are to be addressed and defined. For each of these 34 practices, it has been defined to what extent the individual practice supports the 6 generic activities, and thus the service value chain as a whole.
