Cloud Academy
  1. Home
  2. Training Library
  3. Further resources

The SVC podcast

Developed with
QA

Contents

keyboard_tab
ITIL®4 Foundation Certificate in IT Service Management
2
The SVS podcast
PREVIEW20m 19s
play-arrow
Start course
Overview
DifficultyBeginner
Duration1h 32m
Students1
Ratings
5/5
star star star star star

Description

N/A

Transcript

- [Dave] Hey everyone, and welcome back to another episode of QA's Vital Four Podcast. I'm Dave, and once again I'm joined by Martin Waters and Paul Wigzel. Today, we're gonna be talking about the service value chain, which is kind of 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 to listen 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's it about? And, what does it do?

 

- [Paul] Excellent there, 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 kind of area that has replaced the life cycle. If you're new to ITIL, this is the area of activity, where we're doing the work for words 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 to 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 are, if you like, about six key activities within the service value chain. Now plan, I'm gonna start with plan, because plan is quite an interesting area, because when you're thinking about planning, very often people will think about planning, oh, 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 at a tactical, and even down to the operational level. So what does it actually mean? So, there's no point in saying, "We wanna shoot for the moon." Because actually, do we wanna shoot for the moon? Or should we start off by seeing 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 the 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 services 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, 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 sort of things we need to be thinking about as part of a plan. So when we are talking about planning, or we'll be 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 the 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, or continually, if you prefer.

 

- [Dave] And actually, something you touched on there, that it can happen at the macro level, or the micro level.

 

- [Paul] Absolutely.

 

- [Dave] Is really reflective of the whole nature of ITIL, you know, in previous and in other podcasts, we've talked about, just how the whole of ITIL 4 can be applied to the user, to the individual, and also to the organization, and to the consumer. So, I think that, you know, just this one activity really almost demonstrated that perfectly.

 

- [Paul] Absolutely right.

 

- [Dave] But what about yourself, Martin? What are your thoughts?

 

- [Martin] Well, taking what Paul sort out with the plan activity, then take on the other activity areas of the service value chain, is the improve activity area. And just like the plan activity, this really touches all the other activities that go. And in fact, in another podcast, we talked about the four dimensions of service management as well, 'cause those are gonna need to be continually improved. So the improve area of the service value chain has actually got a very wide scope again. And therefore, think of this improve area of activity is very much gonna be almost a lot of gaining feedback, often through engage, the actual stakeholders, who either consume the service, or will be targeted 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 used in the likes of the method, that ITIL 4 promotes. The continual improvement method, with its some steps to it. And also, the use of tracking of improvement through the likes of continual improvement registers. So we've got this constant say of control of the improvement effort that we do. 'Cause every improvement we do is gonna consume resources across the value chain activities. And also, its gonna be meaningful, in terms of that whole focus of the service value chain, to ultra produce products and services, that are obviously gonna give the right co-creative value to the end consumers.

 

- [Dave] In terms of this one in particular, improve, do you think there's a specific reason why we've got continually improve 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've reiterated it twice?

 

- [Martin] It's really the scope really, 'cause 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, kind of high level systemic view of how we are almost like a best-in-class service provision organization. We need continually improve in 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 a value chain entity around improve, yeah, it's just shining that light even more intensively on that we can't rest on our laurels. We need to have, you know, almost, again, constantly going on within any successful services provision organization, this focus around improving the activity. Unlike plan, as Paul just talked about, it touches all the other value chain activities. There's no start, middle, and end to it. Again, in terms of the value chain, and the whole nature of this value chain is quite dynamic in its nature anyway. It's not meant to be fixed and rigid. And that's why it's at those two levels really that in it's all for overemphasizing the need for improvement to occur.

 

- [Dave] You mentioned that some of the ways that the improve activity might take place, will be through that other activity you just mentioned, engage. Did you wanna tell us a bit more about that, Paul? How that kind of relationship might work out.

 

- [Paul] Yeah, sure. Definitely, let's talk about engage, 'cause 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. Engage is, we're constantly engaging. So you might be engaging again, and you mentioned it earlier when you were talking at a macro level and a 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, it's an all encompassing, all en-capturing activity, to get good understanding of the stakeholders. And we use that word absolutely straight. Stakeholders, people with a vested interest. So we are engaging, and we should be engaging all of the time. There's an old communication mantra that says, "We are communicating all of the time." And in ITIL 4, we are talking out we should be engaging all of the time, 'cause 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 are 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 that as part of the service value chain, it's not we do this, and we do this, and we do this, and we do this. The six activities are absolutely core, and are happening all of 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 contracts, "or they're renewing their subscription, "or they're trying to buy additional products, "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 a tactical level. And we're engaging at an operational level.

 

- [Dave] In terms of, maybe a nice way to put it is actually to think, as you've mentioned, so we're looking to improve, so we engage with the third party, or the customer, or whoever it is, and we get 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 off the mark?

 

- Yeah, that's very correct. There's a very natural link between the engage activity that Paul just talked about and the design and transition service value chain activity area. And it's in that design and transition value chain activity area that we'll take yeah, lots of inputs from the end consumers via engage. Understand their various, kind of stakeholder needs, often around new chain services. And you know, capture their initial requirements, but also in that design and transition value chain area, we'll actually then start to literally come up with a service solution, that is gonna be in accordance with their needs, in accordance with their expectations. Think about the usual triumvirate of the quality needs that they're after, but there's always the cost to consider, and risks incumbent in terms of doing any new or chain service. And design and transition looks at that and analyzes that, and comes up with a solution around that. And often, we'll then play that back through engage, back to the stakeholders to check, is this looking like an appropriate solution? And assume we get the right validation of that, well then we start to properly interrelate as design and transition with a lot of the other very related service value chain activities of obtain and build into deliver and support. But it's true that Zion transition will ultimately go live, so the practice of change control is a fundamental idea and aspect of design and transition activity. And with the practices like knowledge management and other practices that are gonna be fundamental to bringing new services succesfully live to the end consumers.

 

- [Dave] But before we move on in 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 kind of lingo we of hear everyday. 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.

 

- Yeah.

 

- 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. Or it's that constant focus on with the end consumers in mind. Assume we get the right solution validated, then as part of design and 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 they'll alternately lead into fully go live to the end target users and consumers. And design transition in that activity area, 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.

 

- [Paul] And I'll just add in, of course, that 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 will be to bring the people with us as well.

 

- [Dave] Of course, thinking about those four dimensions again. And if you've not listened to it yet, we recommend having a listen to our podcast on the four dimensions if you are not sure what we are 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.

 

- [Paul] 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 better descriptions, it says, "The purpose of obtain and 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 engage has got involved. So then engage has got involved to understand exactly what the specifications are, and has worked with design and transition to actually deliver the agreed specification. So design and transition do the work to deliver the agreed specification that engages, as if you're 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 gonna go into buy stuff from cloud? Does that mean we're going to go into working in partnership? Does that mean we're gonna write it ourselves? Design it ourselves? Build it ourselves? Does that mean that we've got the skills required to do that? So we needed 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 components are there, whether we can support them. And so I'm not trying to jump ahead, but that takes us into delivery and support, but whether they are supportable, whether they are supported, whether we've got the right contracts in place, 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.

 

- [Dave] I think you've segued it perfectly actually into deliver and support, maybe we should just continue on with that. What are your thoughts, Martin?

 

- [Martin] In deliver and support, as when all of these value chains, there's so much interrelated aspects going on. But once we finally see the service, the products, the activity we're doing as part of deliver and support, is obviously to ensure that they're actually delivered to the levels that the end customers, the end consumers expect. So, the principle of there'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. 'Cause there's always gonna be a need to even just field questions from end consumers of the service. But, you know, fundamentally, it's not just that. It could be, obviously, the service could go wrong, the service has to have various requests facilitated around it. We see through this deliver and support activity area of the service value chain, obviously, with agree, or the requirements in terms of support levels, will be agreed as past level design and transition. But now here we are, literally living and breathing it every day, and often through the likes, the practices like service desk is a practice, and instant and problem management, request management as practices. We're actually now actively engaged, through engage, but with end consumers, ensuring that the service is delivered exactly in accordance with its specified service levels. And then obviously through that, almost when working with improve, going back via engage to see is the feedback good? Is that service support wrapper working as part of dormant support? And obviously, adjusting that as required in line of the active use of the service.

 

- [Dave] That's really insightful. I was just kind of wondering, you know, these six activities, they seem, you know, like 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-created value? Is it always the case that all six activities will happen? Or, you know, can you foresee an example where maybe four would be used? Or--

 

- [Paul] 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 gonna wanna plan. You're always gonna wanna engage. Because if you don't engage, you're not gonna know whether you're gonna be anywhere close to delivering. You can't obtain and build, what's not been designed and transitioned.

 

- [Dave] You always wanna improve.

 

- [Paul] You always want to improve. And whatever you're going to obtain and build, ultimately has to be looked after. And in every way, you're gonna 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.

 

- [Martin] I agree, Paul. I think all the six value chain activities are fundamental to service and product success. I suppose the only thing that perhaps has to be said, in the idea the service value chain, and we talk about the actual practices being utilized across those six areas of interrelated activity. Obviously some practices, groups, or resources will be more relevant to certain value chain activities over other value chain activities.

 

- [Dave] True, yeah.

 

- [Martin] Like service desk is fundamentally gonna map to a lot of engage, deliver and support, and probably primarily improve the areas. But it could also get involved in obtain and build, and design and transition aspects as well. So, 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 gonna be crucial to that.

 

- [Dave] So, it is key that, you know, people who are looking to do an ITIL 4 course, I mean, are familiar, understand these core six activities, and really understand how the service value chain sits within the service value system. So with that in mind, perhaps you could talk about an example. I see maybe you're hoping--

 

- [Paul] Oh no, I'm just gonna jump in. I'm totally agreeing with what you're saying, but I'm just gonna say, let's not fall into the trap of saying, "Well we've got these six elements "of the service value chain. "Well therefore, we're gonna need a big team to do this."

 

- [Dave] Oh yeah.

 

- [Paul] Because in truth, one person, two people, three people could do this quite comfortably.

 

- [Dave] It sounds like my job.

 

- [Dave] Bear in mind that we're almost... I mean I kind of, I liken these areas to like hats. You know, while I'm doing a piece of engage so I've got my engage 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. Or I can put my improvement hat on. It's quite difficult to wear more than one hat at any point in time. But you know what I'm saying is--

 

- [Martin] You're good at swapping hats.

 

- [Dave] You can keep swapping hats. Yeah, 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 it 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 consumers. Engaging with the customers. They are going to be involved with the design and transition because ultimately they are gonna be receiving information from users. They're gonna be receiving instances and problems, potentially. So we'd like them to be involved in the design transition. They're definitely gonna be involved in the obtain build, because obviously if they're gonna be looking after it we will 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 gonna be looking after it on the day-to-day basis. And who better to ask about whether the customers or 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, yeah, the service desk was probably the cleanest, or the easiest of that, but you could pick any of the practices.

 

- [Martin] Agreed.

 

- [Dave] And they'd map across.

 

- [Martin] They would, yeah.

 

- [Dave] Fantastic, yeah, it's... I think it's just one of the most powerful parts of ITIL 4, and I've said that, in fact, the entire framework, if that's the best way to think of ITIL is a framework. The entire of ITIL 4 seems really, really powerful, but specifically, the service value chains speaks to me, because even while I'm not in IT myself, I can find this as useful. I can apply this to anything really.

 

- [Paul] Yeah, you could build a house for this.

 

- [Dave] Build a house, could do whatever you like. Well, I think we're gonna 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.

About the Author

Martin is a professionally qualified and experienced IT Professional with over 25 years experience in the IT industry. He has held a number of senior roles and has experience of large scale IT Service Management implementation programmes both in public and private sectors. He has over 15 years experience working for QA as both a Senior principal lecturer/consultant and as Head of Service Management Product Development. Martin has delivered training to a wide variety of audiences, both UK and internationally, to consistently high levels of customer satisfaction.

His main role at QA is acting as a Head of Service Management Product Development to enable QA to deliver high quality, interactive training in the following areas:

  • Delivering a wide range of public ITIL, SIAM and BRM courses
  • Delivering onsite ITIL and SIAM courses
  • Developing high quality QA authored Service Management courses and courseware across all delivery mechanisms including classroom, e-learning and virtual
  • Working with Industry partners to develop new curricula and courses – Recent examples include ITIL Practitioner and the BCS EXIN SIAM Foundation qualifications