People who work in IT service management (ITSM) spend a lot of time thinking about and perfecting their processes. And that’s a good thing. But when we focus on processes to the exclusion of everything else, we lose out. In this blog I’m going to explain why you need to think about the things you do in terms of value streams, rather than just as processes.
There’s a lot of confusion about the difference between value streams and processes. It’s not surprising we sometimes find the distinction confusing, because both value streams and processes describe how activities work together to achieve something. So, what is the distinction? Here are the definitions from ITIL 4 to start the discussion.
|Value Stream: A series of steps an organisation undertakes to create and deliver products and services to consumers.
Process: A set of interrelated or interacting activities that transform inputs into outputs.
Every value stream starts with demand or opportunity and ends with value being created for one or more stakeholders. For example, the demand might be that an IT organization is asked to create a new service to help sales teams understand their customers. The end point – the value that gets created – would be the increase in sales arising from the sales teams’ improved understanding of their customers.
Every process produces well-defined outputs. For example, an IT organization may have a process for authorizing changes. This takes an RfC (request for change) as an input, and the output is formal authorization for the change to be implemented. But this might not directly result in value for a stakeholder; this RfC process only creates value when it’s part of a bigger value stream.To get big improvements while minimizing risk, you need to improve the value stream, not just individual processes, says @StuartRance. #ITIL Click To Tweet
A typical value stream includes many different processes, and all of them need to work together seamlessly to maximise value creation. It’s very easy to imagine that if you optimize individual processes you’ll get improvement. In practice, optimizing individual processes may lead to the opposite of what you intended, as your improved process may have a negative impact on others in your organization in ways you didn’t consider or expect. Similarly, if you always have an eye to the bigger picture, you’ll be able to identify what it is that really needs to be improved and how to do it in ways that help everyone.
To get big improvements while minimizing risk, you need to improve the value stream, not just individual processes.
Here are a couple of examples.
This example is based on something that actually happened at a large financial organization in Europe. There’d been lots of complaints about how change management was slowing down the organization’s ability to deploy new software, and how this was affecting the agility of the whole company. So, the IT organization decided to review how they managed changes.
This is what I usually see in these circumstances. The IT change manager and the people they work with consider ways that they could optimize their process to reduce the overhead.
BUT this organization did something different. They understood that it’s much better to consider a whole value stream instead of just focusing on a single process. They appointed one senior IT manager to review and improve the entire value stream for creating new functionality to support the business. The value stream started when the customer identified a requirement for new IT functionality and ended when the new functionality was being successfully used by the users.
What this meant was that the senior IT manager didn’t just look at processes. Their remit was to look at people, process, technology, and suppliers (what we would now call the four dimensions of service management) to optimize the end-to-end value stream and ensure it delivered value.@StuartRance explains why you need to think about the things you do in terms of value streams, rather than just as processes. #ITSM Click To Tweet
The result was a really impressive transformation of change management. Under the old system, software developers manually submitted an RfC when they were ready to deploy the software. There was then a delay while the change was evaluated and approved. If the change was rejected at this stage, there was yet more delay as it went back for rework.
The new system focused on optimizing the value stream. One aspect of this involved the use of new tools that automatically submitted an RfC as soon as all the information required was available. Nobody had to put this information together to create the RfC, it was all created naturally as part of earlier stages in the value stream. As a result, RfCs were submitted early enough for the person assigned to evaluate them to provide timely suggestions that could easily be incorporated into the development and testing phase. Consequently, changes were very rarely rejected because the people involved had already collaborated to iron out potential difficulties and produce products and services that were much better able to meet the customer’s needs.
Obviously, there were lots of other improvements made to the value stream as part of the transformation, but I hope I’ve written enough to demonstrate that improving an entire value stream is much better than improving a single process. We can’t afford to think only about a single team’s outputs. We also need to think about how the things we all do work together to create value.
In this example the manager who redesigned the value stream was not responsible for doing the work; they didn’t take ownership of the software development team, or the change management team.
So, what did they do that resulted in an impressive transformation? They collaborated with all the interested stakeholders to ensure that everyone engaged, that everyone’s needs were met, and that everyone contributed to end-to-end value creation. They authorized the replacement of some of the tools and ensured that all tools were integrated to reduce manual work. They optimized processes that needed improvement, and ensured people had the skills and resources needed to collaborate well. This way of working may be less straightforward than optimizing a process. But it has two great benefits. People are less likely to resist the changes that are made when they’ve been intimately involved in making them and therefore better understand the need for them; and it delivers excellent results.
This example was at a healthcare institution, in the UK. Management complained that it was taking far too long for an employee joining the company to have everything they needed to be able to do their work efficiently.
This organization had a good process for service request management. If someone needed a new phone, or laptop, or PC, or an email account they could typically get everything sorted in just a few days, although there might be a longer delay if some parts weren’t available.
What was missing was an understanding of the end to end value stream; in this case what exactly needed to happen between an employee joining the company, and that employee becoming a productive member of staff. When they analyzed the value stream, they found that many different parts of the organization needed to be involved, not just IT. The new staff member needed:
Once the whole value stream had been analyzed it was easy to see where the bottlenecks were, and what needed doing to sort them out. Devices could be ordered as soon as the start date was known, without waiting for the employee to actually start. Training could be scheduled for their first day. Accounts could be created in advance and activated as soon as training had been delivered. By making a few simple changes the average, and maximum, time needed to onboard new staff was massively reduced, and new staff were able to get on with the work much faster.
Processes can be very helpful but optimizing a process may not make any difference to your customers. If you want to do a great job of helping your customers then look at the value streams you’re part of, and ask yourself what you can do to optimize those.
If you’re familiar with the ITIL guiding principles you may have noticed how they contributed to the success of the organizations in my two examples. (If you’re not familiar with them, you might want to take a look at The 7 Guiding Principles of ITIL 4: Practical Advice to Help You Make Decisions)
Both of the examples in this blog followed these principles to help optimize two very different value streams:
I’m sure these organizations could have used the other guiding principles too: Start where you are, Keep it simple and practical, and Progress iteratively with feedback, could all contribute to helping optimize a value stream.
And finally, if you haven’t thought about what you do in terms of value streams before, then you have a great opportunity to improve in ways that’ll make a real difference to your customers.