Since we recorded this podcast, AXELOS have changed change control to change enablement. So, if you ever hear us talking about change control, what we really mean is change enablement. We hope you enjoy this podcast. Hey everyone, and welcome back to another episode of QA's ITIL 4 podcast. I'm Dave, and once again, I'm joined by Martin Waters and Paul Wetzel. Today, we're going to be talking about the Service Value Chain, which is one of the central core components of the Service Value System. 

And we'd like to just go a little bit more in depth into it, because it's a bit more complex and maybe needs a bit more explanation. So, we hope that you'll enjoy having listened to what we're talking about today. And, in fact, if you're interested, don't forget to check out our animation that explains this concept as well. But to get straight into it, Paul, can you tell us a bit more about the SVC, or Service Value Chain, and what it is, what it's about, and what does it do?

Excellent. Thanks Dave. The Service Value Chain is difficult. There's no two ways about that. It's right at the core. So, don't be frightened by it, but it is at the core of service management. It sits as the central element of the ITIL Service Value system. If you've done old versions of ITIL, this is the area that has replaced the lifecycle. If you're new to ITIL, this is the area of activity where we're doing the work, for want of a better description. That's taking the demand that we have for our services or products and actually turning them into value, and it's broken down into six activities. It's broken down into the activities of plan, of improve, of engage, of design and transition, obtain and build, and deliver and support. So, that's plan, improve, engage, design and transition, obtain and build, deliver and support. So, those if you like, other six key activities within the Service Value Chain.

Now, plan. I'm going to start with plan, because plan is quite an interesting area. Because when you're thinking about planning, very often people think about planning from a strategic perspective, and that's great. Yes, of course, we need to plan from a strategic perspective, but we also need to plan that is tactical and even down to the operational level. So, what does it actually mean? So, there's no point in saying, we want to shoot for the moon, because actually, do we want to shoot for the moon? Or should we start off by saying, If we can get into orbit and once we've got into orbit, then we can move. So, what are the plans? Let's set ourselves some plans. 

So, we're talking about strategic, tactical, or operational plans. We're talking about decisions around the portfolio of what services or products are we going to deliver to the customer, and what value will they actually bring to the customer or the consumer of those service or products? So, we're talking about making decisions around the services. We're talking about rules, the policies that we have to adhere to. We're talking about the structure of the architectures. Whether we're going to think about partnering up, or whether we're actually going to try and do this ourselves, these are the things we need to be thinking about as part of plan. So, when we're talking about planning or when we're talking about plan as part of this Service Value Chain, it's coming at various levels. And when and if you get to see the diagram that talks about the Service Value Chain, you'll notice that plan overarches, all of the other areas, because planning is happening all of the time. It's not a one stop activity. It's happening continuously, continually if you prefer.

Actually, something you touched on there, that it can happen at the macro-level or the micro-level. Absolutely.  Is really reflective of the whole nature of ITIL. In previous and in other podcasts, we've talked about just how the whole ITIL 4 can be applied to the user, to the individual, and also to the organization, and to the consumer. So, I think that just this one activity really almost demonstrates that perfectly. Absolutely right. But what about yourself, Martin? What are your thoughts? Well, taking what Paul talks about with the plan activity, then taking on the other activity areas of the Service Value Chain is the improved activity area. Just like the plan activity, this really touches all the other activities that go on. And in fact, in another podcast, we talked about the four dimensions of service management as well, because those are going to need to be continually improved. 

So, the improved area of Service Value Chain has actually got very wide scope again. And therefore, think of this improved area of activity is very much going to be almost a lot of gaining feedback, often through engage the actual stakeholders who are either consuming the service or will be target consumers of it. Obviously, within that, looking for where we're performing well, where we're not performing well. And therefore, almost acting as like a stimulus across all the other value chain activities. And in fact, the four dimensions of service management to drive very value-focused continual improvement activity. Often, using the likes of the method, the ITIL 4 promotes the continual improvement method with its seven steps to it. And also, the use of tracking of improvement through the likes of continual improvement registers. So, we got this constancy of control of the improvement effort that we do. Because of improvement we do is going to consume resources across the value chain activities.

And also, it's going to be meaningful in terms of that whole focus of the Service Value Chain to produce products and services that are obviously going to give the right co-creative value to the end consumers. In terms of this one in particular, improve, do you think there's a specific reason why we've got continually improved as a general theme within the Service Value System, but also as a specific activity within the Service Value Chain? Or do you think it's just because it's so important that they have reiterated it twice? It's really the scope really, because you're right, it's the need to continually improve is an element, I should say, of the overall ITIL Service Value System. So, looking at it from a very high-level systemic view of how we be hopefully always like a best-in-class service provision organization. We need continue improvement ethos and their principles being driven all the way across the organization to all levels of management. 

But with the Service Value Chain, this is now specifically about the actual products and services that we're doing. And therefore, in the specifics of products and services, the re-emphasis of the value chain activity around improve. It's just shining that light even more intensively. On that, we can't rest on our laurels. We need to have almost again constantly going on within any successful services provision organization. This focus around improvement activity. Unlike plan, as Paul just talked about, it touches all the other value chain activities. It doesn't. There's no start, middle, and end to it, again in terms of the value chain. And the whole nature of Service Value Chain is quite dynamic in its nature. Anyway, it's not meant to be fixed and rigid. And that's why it's that those two levels really, but ITIL 4, emphasizing the need for improvement to occur. You mentioned that some of the ways that the improve activity might take place will be through that other activity that you just mentioned, engage. Do you want to tell us a bit more about that, Paul?

How that micro-level relationship might work out? Sure, definitely want to talk about engage, because engage is such a key element of this Service Value Chain. But when to engage? You could very quickly fall into the trap that you engage right at the start and then we deliver products and services to the consumer and they achieve value. Brilliant. Thank you very much indeed. Everyone leaves. But in essence, engage is ongoing. And engage is that we're constantly engaging. So, you might be engaging again. And you mentioned it earlier when you're talking about, Dave about talking at a macro-level and micro-level. We're engaging with consumers. We're engaging with the customers. We're engaging with the users all the way through our whole value chain. We're talking about working with suppliers, working with partners, working with the customers, working with the users, working with the actual service-providing team ourselves. 

We are all, and when we talk about engage is an all-encompassing, all in capturing activity to get good understanding of the stakeholders, and we use that word absolutely, stakeholders, people with a vested interest. So, we are engaging and we should be engaging all of the time. I mean, there's an old communication manager that says, "We are communicating all of the time." In ITIL 4, we're talking about, we should be engaging all the time, because we want to know exactly what it is that we're trying to deliver. We want to know what the demand is for those services. We want to know how the customers are feeling. We want to know how the providers are feeling. We want to understand whether they're able to deliver the additional changes that we want or the improvements that we want.

We're all about engaging and working alongside the teams that are delivering and supporting the teams that doing the obtain and build. We're all about working together. And this is the bit that I'm probably not expressing very well, but I'm trying to express it, as part of the service value chain is not, we do this, and we do this, and we do this, and we do this. There are the six activities are absolutely core and are happening all the time. We've mentioned plan and improve, but so is engaging. You're engaging at the start, but you're also engaging as we go through, and ultimately, you're engaging at the end. The only way you're going to know whether you've delivered that value that you've co-created is by actually engaging with the consumer and saying, "Are you happy with what we've delivered?" 

Or you might be able to just assess it by saying, they're buying more; they're renewing their contract, or they're renewing their subscription, or they're trying to buy additional product, or whatever it happens to be. So then, we've got that engage level. So, we're engaging at a strategic level, we're engaging at tactical level, and we're engaging at an operational level. In terms of, maybe a nice way to put it is actually think, as you mentioned, so we are looking to improve. So, we engage with the third-party or the customer, whatever it is, and we hear their feedback and what do we do?

Well, then we look to design potentially a new product or a better product or an improved product and transition that. Would that be correct Martin? Or am

I? That's that's very correct. There's a very natural link between the engaged activity that Paul just talked about and the design transition, so its value chain activity area. And it's in that design and transition value chain activity area that will take lots of inputs from the end consumers  who are engage, understand their various stakeholder needs often around new change services and capture their initial requirements. But also in that design transition value chain area, will actually then start to literally come up with a service solution that is going to be in accordance with their needs, in accordance with their expectations. Think about the usual trends of their quality needs that they're after, but there's always the other cost to consider and risks incumbent in terms of doing any new or change service. 

And design transition looks at that and analyzes that and comes up with a solution around that and often will the employ that back through engage, back to the stakeholders to check is this looking like an appropriate solution? I assume we get the right validation of that, will then be starting to probably interrelate as design transition with a lot of the other very related services  like training activities of obtain/build into delivering support. But it's true that design transition ultimately will go live. So, the practice of change control is a fundamental idea and aspect of design transition activity, and other practices like knowledge management and other practices that are going to be fundamental to bringing new services successfully live to the end consumers.

Before we move on this one, I think some clarification could probably be really useful for the listener. Obviously, the term design, I think everyone is familiar with this word, it's really fundamental to so much of the lingo we hear every day, but the word transition is a bit more obscure. To transition means to go from one place to another or maybe from one state to another state.

And the orientation, generally here, is obviously depending on the size and the nature of the service and the service changes that we're doing, always with that constant focus with the end consumers in mind. Assuming we get the right solution validated and as part of design transition, we will go often from a non-live into things like pilots, where there'll be some representative usage in a sampled way of the new service and ultimately into fully-go-live to the end target users and consumers. And design transition in that activity of the value chain will be very much controlling of, almost like those stages of hopefully how we manage successfully service change really, ultimately as part of change control practice.

And I was just adding, of course, the in ITIL 4, we also not just focus on the technology but we're also focusing on the organizational change as well. So, part of the transition would be to bring the people with us as well. And, of course, thinking about those four dimensions again. If you've not listened to it yet, we recommend having listened to our podcast on the four dimensions, if you are not sure what we're alluding to here. But maybe we can kind of further this along by talking a little bit maybe about obtain and build and how that might relate to, for instance, the design and transition. Absolutely, I'd like to do that too, I'd like to do that if that's okay. 

When we go straight to the core book for one of our best description, it says the purpose of obtain/build value chain activity is to ensure that the service components are available when and where they are needed and meets the agreed specifications. Well, you can't do that bit if you don't know what the specifications are, and that's where engagers got involved. So, engagers got involved to understand exactly what the specifications are and has worked with design and transition to actually deliver that agreed specification. So, design and transition do the work to deliver the agreed specification that engages, as if you are like triggered or started. And then, we've got the bit about make the service components available when and where needed. Well, in a real world, what does that mean? Does that mean that we're going to go into buy stuff from cloud?

Does that mean we're going to go into working in partnership? Does that mean we're going to write it ourselves, design it ourselves, build it ourselves? Does that mean that we've got the skills required to do that? So, we need to get additional training for our people. All of that element effectively would be delivered by obtain and build, having been identified within the design and transition from conversations that have happened through engage, making sure, of course, that we're aligning to the plan. So, obtain and build, fundamentally, is just about making those service components available. 

So, we're talking about whether those conveyance are there, whether we can support them, and so I'm not trying to jump ahead, but that takes us into deliver and support. But whether they are supportable, whether they are supported, whether we've got the right contracts in place and all of that stuff is happening as part of obtain and build. So, by the time the services or products, if you like, move from obtain and build into deliver and support, we've got the full understanding of exactly what's needed.

I think you've figured perfectly actually into delivering support, so we should just continue on with that.

What are your thoughts Martin?

In delivering support, as with all these value chain activities, there's so much interrelated aspects go on. But it's once we finally see the service, the products, the activity we're doing as part of delivering support is obviously to ensure that they are actually delivered to the levels that the end customers, the end consumers expect. So, the principle obvious, it's no good delivering the service, and then, obviously, it's actually being used by the end consumers but then we can't have the constancy of support activity around it. Because there's always going to need to even just field questions from end consumers of the service. But fundamentally it's not just that, it could be obviously the service could go wrong, the service has to have various requests facilitated around that. We see through this delivering support activity area of the service value chain, obviously, would agree or the requirements in terms of support levels will be agreed as part and parcel of design transition. 

But now, here we are literally living and breathing it every day and often through the likes of the practices like service desk as a practice and incident and problem management, request management is practices. We're actually now actively engaged through engage back with end consumers ensuring that the service is delivered exactly in accordance with this specified service levels. And then obviously through that, almost when working with improve, again we're engaged to see is the feedback good, is that service support rapport working as part of delivery support and obviously adjusting that as required in light of the active use of the service.

That's really insightful. I was just wondering, these six activities, they seem all really important, but would you say that all six would have to happen every time an organization is looking to turn some kind of demand into co-creative value? Is it always the case that all six activities will happen? Or can you foresee an example where, maybe, a four would be used. That's a really interesting question. I'm sitting here thinking that I'm struggling to, now it might be that I'm just wanting to try and fit it all but I'm struggling to come up with a situation where you wouldn't use all of them. You may not touch them all to the same level of degree, but you're always going to want to plan, you're always going to want to engage. 

Because if you don't engage, you're not going to know whether you're going to be anywhere close to delivering. You can't obtain and build what's not been designed and transitioned. You always want to improve and whatever you're going to obtain and build, ultimately has to be looked after. And the only way you're going to know whether that's delivering what the consumer wants is by going back and engaging with it. So, I don't know how you feel Martin, but I'm sitting here struggling. I can't come up with, I'm desperately trying to think of a real world example where you would only use some of them. I agree Paul, I think all the six value chain activities are fundamental to service and product success. Suppose the only thing that perhaps has to be said in the idea of the service value chain, and we talk about the actual practices being utilized across those six areas of interlaced activity. 

Obviously, some practices, groups of resources will be more relevant  to certain value chain activities  or the other value chain activities. Like service desk is fundamentally going to map to an awful lot of engage, delivering support, and probably, primarily, improve areas but it could also get involved in obtain and build and design transition aspects as well. But yes, individual practice areas may have more or less relevance in certain value chain activities but fundamentally for you to do a successful service, then yes, I would agree with Paul, all six value chain activities are going to be crucial to that. So, it is key that people who are looking to do an ITIL 4 course are familiar, understand these core six activities and really understand how the service value change sits within the service value system. So, with that in mind, perhaps we could talk about like an example, I see, maybe, you're hoping. 

Just going to jump in, I totally agree with what you're saying but I was just going to say, let's not fall into the trap of saying, well we've got these six elements of the service value chain or, therefore, we're going to need a big team to do this. Because in truth, one person, two people, three people could do this quite comfortably. Sounds like my job. Bear in mind that we're almost, I mean I like in these areas to like hats. When I'm doing a piece of engage, so I've got my engaged hat on, I can take my engage hat off and I can put my design and transition hat on or I can put my planning hat on and I can put my improvement hat on. It's quite difficult to wear more than one hat at any point in time. 

But what I'm saying is that you can keep swapping hats, it becomes a bit like that, the variety act where they kept swapping hats. So, don't think it needs a huge team but I think Martin actually mentioned earlier on, I think a really good example, which is something like the service desk. Because the service desk is going to be engaging with the users, engaging with the consumer, engaging with the customers. They are going to be involved with the design and transition because, ultimately, they're going to be receiving information from users, they're going to be receiving instance and problems potentially. So, we'd like them to be in involved in the design transition. They're definitely going to be involved in the obtain/build because obviously they're going to be looking after, we want them to be involved in the building, the creation of it, the obtaining of it, the piloting of it. 

And then the deliver and support, they're definitely going to be looking after it on a day-to-day basis, and who better to ask about whether the customers or the consumers are happy with that than the people who are actually engaging with them. And who better to help with the improvement than the people who are actually using it day on day. So, I think, actually, the service desk was probably the cleanest or the easiest of that. But you can pick any of the practices and map across. Fantastic. I think it's just one of the most powerful part of a vital force, so that, in fact, not the entire framework, if that's the best way to think how vital is the framework, the entire vital force seems really, really powerful but, specifically, the service value chain speaks to me because even while I'm not in IT myself, I can find, this is useful. I could apply this to do anything really. You could build a house with this. Build a house? You could do whatever you'd like. Well, I think we're going to wrap this one up there guys, but thank you, again, for coming through today and joining me, and I hope to chat with you again soon.