The Service Value Chain 

And what you can see is that we've got three elements there that are not activities. But even though they're not activities, they're actually pretty central to the idea of the service value chain. Because the service value chain's job, quite simply, is to get from demand on one side to value to the consumer, the user, the customer on the other side, the co-creation of that value via products and services. So even though they're not actual activities, then-- they're still vitally important. Because they're absolutely what the service value chain is all about. Now, through the service value chain, you can see a whole host of different activities. We've got engage in there. We've got plan. We've got to improve. We've got design and transition, obtain and build, and deliver and support. Now, there's no one set route through there. There are different routes depending on what it is you're trying to achieve. So, don't look at that and think there's only going to be one route. And the key thing when we look at all of the practices a little bit later on-- what the practices do is they interact in each of these value chain activities. So, what I'm going to do is give you a couple of examples talking through some of the practices that might actually be involved to give you an idea of how this works.

 

So firstly, let's take a simple case. And that might be a hardware failure. So, a hardware failure takes place-- that's where the demand comes from in a hardware failure. Effectively, the customer at the other end needs support. So, what's going to happen first is we will go into engage. Now, with a hardware failure, engage is almost certainly going to be the service desk practice that gets involved, somebody doing that.

 

But it could be the incident management. If you've got automated reporting when hardware fails, then it could be incident management that gets involved and engaged straight away. So, you're into engage. What will happen then? Well, it might well be after you've done that, then-- it's a hardware failure. We've got hardware spares in in-store.

 

So, we might go straight to deliver and support. And within deliver and support, what might well happen there is that you've got incident management finding the cause of the hardware failure, looking at it, and, OK, we've worked out that it's a hardware failure. We need to do something about it. Configuration management tells us what type of hardware we need. Could well be then that we go to look at IT asset management.

 

Yes, we've got one of those in stock. And then change controls as well-- OK, what you're doing is a like-for-like replacement. So, this is a standard change. So, what you see as you progress through from the different value chain activities-- and you've got the practices supporting underneath. What would happen then is you would probably finish off this one with a trip back to engage and engage, and the service desk going back to the user and saying, right, OK, we've fixed that. You're able to work again. And being able to work again means that we've finally got the value back to the user. So, you can see what we've done there is a very, very limited trip through this service value chain. Now, what you might get in another case is let's say you wanted a new service, Ok, something a little bit more complex-- a new service.

 

Your demand here is let's say the customer were in a retail environment-- one that I know and love-- were in a retail environment. And the demand there comes from, OK, we wants a new online shopping service that we can put together. So there, we go into engage. And engage there might well be relationship management, getting involved to find it out exactly what it is the customer needs and the sponsor needs.

 

From engage, it might well go into plan. What will happen in plan? Well, that's where things like portfolio management will get involved. Architecture management will get involved. Project management, finance management, risk management. And they'll put together, perhaps, a plan, a business case for a new service. That might well then go back to engage in relationship management to go back and talk to the sponsor, talk to the customer. Is this what you want, guys? Yes, it is. It's been approved.

 

So, it goes back in to plan in the value chain. And plan then might well make sure that we've got the plan. It's been approved. And that then goes off to design and transition. Design and transition might well, at that point, have things like capacity management, availability management, business analysis. There's a whole host of things that can be going on in there making sure that the design and transition. From design and transition, what might happen then?

 

Ok, we could go off to -- we could go off to obtain build if we're doing this internally or externally, and so on, and so on, and so on. So, as you can see what we do for each activity and each demand is we use the value chain to trip through and find out to how to get from actually having at the far end there, making sure that we've got what the demand that the customer wants, the opportunity that they need to fulfill right the way back down to the other end here, where we're looking at delivering the value. And you decide what the root is through the value chain and which of the practices actually support the different elements of that value chain.

 

What I'm going to tell you, it's not an exhaustive list of everything that the plan does but just to give you an idea. Now, planning can happen pretty much all the way through, which is why it stretches right the way from end to end. So, planning and decision making so that there might well be obviously planning activities and decision making going maybe into design I'd say as something that they would do. What else are they going to do? A lot of the policies, and a lot of the architecture decisions, a lot of the plans, OK, will come from this particular arena, from the planning arena.

 

What they're also going to do, they're going to make sure that we've got some shared understanding, that the various stakeholders have got shared understanding.

 

So, if this is starting to sound a little bit like project management, then when we look at the general management practices a little bit later, although it's not part of the foundation syllabus, you'll see that project management is in there. They're going to make sure that people are aware in planning of current status, that different stakeholders are aware of the current status of any planning activity and plans that are moving forward. It's really important as well, I think, from the perspective of plan that they are planning and that they are holistic in their planning to make sure that in the planning we cover all four dimensions of IT service management, not just the technology parts of it but the people, the third parties, the processes, the value streams, and so on. That's particularly important to remember that part of the planning is to make sure that you are holistic.

 

So, you think about that, then change might be part of planning but organizational change, IT change, they're all in there. So please, please, please remember in the planning to be holistic. And the final thing is that one of the things that planning absolutely needs to do, if we remember when we talked about PESTLE earlier in the course, is understanding those constraints. That's massively important for the planning activity. If they don't understand the constraints, then the plans are wrong. The plans are wrong, the execution is wrong. The value isn't achieved. And what do we end up with? Unhappy customers, unhappy users.

 

Its role is to ensure continual improvement of products, services, and practices, and indeed, all of the other service value chain activities themselves. So, improve-- it's really, really important for improve that absolutely and totally relies on data and input from lots of other areas performance information, in particular, from deliver and support is going to be an enormous input. Without the data, improve is actually dead in the water. So, data is massively important, and particularly, from deliver and support. What was the famous Sherlock Holmes quote? "Data, data, data, I cannot make bricks without clay." So that's a massively important part of improve. What else are we looking at as part of it? Well, one of the other things that improve is going to do is there's going to be a lot of feedback and that feedback primarily to the stakeholders is going to go out to the engage activity. So, through relationship management, perhaps through service level management, maybe even through the service desk, the engage activity is going to happen.

 

What else are we looking at with improvements? The improvement initiatives themselves-- so the actual improvements, they're likely to go out to or almost certainly going to go out to plan. So again, if we're looking at improve, improve is almost-- we think of a really, really good meal that we've had. Improve is the sauce that you can pour all over the meal and really makes the meal come alive. So, improvement needs to touch absolutely every practice in your organization, every service, every product. But they need that data. I can't stress enough just how important the data is to improve. It can't operate without it. It can't have it. It's got no baseline if it's got no data, so that's a really important part of what we do with improve. And of course, the continual improvement practice is likely to own this most of the way through in your organization using the continual improvement model that we've looked at earlier in the course.

 

Very important element, Engage. Without engage, we have no source of demand. So, I think the first thing for us to understand, OK, is that demand loves engage. OK. Demand loves engage. Demand needs engage. Now, what we need to remember with the engagement, about how we pick up the demand, how we pick up the opportunities. Whether that demand is a service desk call or the demand for a new service, so the opportunity for a new service, it needs some sort of engagement.

 

One of the things we've got to understand, is that that is always going to be two-way engagement. And two-way engagement from the service provider to the consumer, from a service provider to a supplier. So, they're going to be engaged-- it's not just engagement necessarily with customers and consumers. It can be engagement with suppliers as well, because it's two stakeholders working together. It's two way, and it needs to be at the strategic, at the tactical, and at the operational level. So that, again, is massively important, that if you don't get-- for example, if you only get engagement at the operation and tactical levels, then the strategic level just doesn't work. If there's no relationship at the strategic level. Once something gets engaged there, people have got no idea what's going on. Similarly, if you've got no engagement at other levels, it becomes particularly difficult.

 

So, it might well be, for example, if we've got a new service or an improved service, then we might well be using relationship management. Or we could be using business analysis as two of the practices that we use for new chain services. We could, as well, be using service-level management as a practice in here to help us to do that. But remember, I did say that it was two-way. So, feedback on services is going to be a two-way activity. What's new about a service is going to go one way, whether that's actually provided the value coming back the other. Again, you can see an absolute role in there for the service desk. You can see a role in there for service-level management, for release management, and so on. What else are they going to do?

 

Well, let's have a little bit-- always particularly important that we can manage expectations. And again, what we'll find is that engage is going to manage expectations through release management, through service-level management, and in particular on a day-to-day operational basis through the service desk. And finally, in terms of engage-- important that it's going to provide knowledge. So, the engagement providing knowledge that the customers can use and turn it into wisdom. Data gets turned into information, information gets turned into knowledge, knowledge gets turned into wisdom.

 

And it does pretty much what it says there. It's all about designing and transitioning into the live environment, into the production environment, the products and services that meet the expectation of the customer. And they've got to meet their expectation, the old eternal triangle, of time, cost, and quality. So, that's an important part of what design does. [Video description begins] He draws a triangle on the screen. The three corners of the triangle are labelled as: TIME, COST, and QUAL. [Video description ends] Now, it's important that the third design in transition in particular, two major, major sources of imports. Source number one is going to be, as we mentioned earlier-- source number one is going to be plan. And what it's going to get from there are portfolio decisions.

 

But a lot of what it gets from there are the constraints that are going to be-- that it's got to design within. So, what sorts of availability does a new service need-- availability does it need? What sorts of capacity does a new service or products need? What kind of performance does the customer expect for a new service or products? What about security aspects of a new service or product? And also, how about the support of the new service or products? Without the constraints, without the guidance, without knowing what those expectations are in these areas, then unfortunately, design and transition are simply guessing. And the chances are that if they're just guessing, forget that.

 

And it's all about making sure that the service components, the services or whatever, are available when and where they are needed. So that can be hardware. oops. That can be software. That can be documentation. They're available when and where they are needed. Now, if the elements of the value chain is called obtain and build. So, of course, any of those could be bought or could be built. It doesn't make any difference.

 

Where are they going to get most of their-- they're almost going to be in a tight loop with our friends in design and transition. So, what's going to happen is design is going to pass through to obtain and build. Obtain and build is going to go back to design and transition to do the transition bits of that. So, they're going to end up particularly in Agile environments in a loop. And, of course, engage will be in there as we go back to the customer. So, even in the Agile world, we can see that this particular value chain is probably going to be one that's a well-trodden path and one that people working in this type of environment are going to be used to, not dissimilar to a kind of Scrum environments where you do a bit of backlog planning, a bit of backlog grooming.

 

I've always liked that-- backlog grooming. I'm just grooming the dog or the rabbit or whatever else. So, you're doing a little bit of that. So that's our planning activity. You're then designing, you're building, you're transitioning, and you're getting feedback, the engage from the customer. So, you can see that we could use this in a very, very Agile way, the whole of the service value chain with obtain and build sat there in the middle. So, it doesn't matter to obtain and build, whether you're cutting your own code or whether you're going out to a third party to cut the code for you or you're buying the software indirectly. It still fits into this service value chain.

 

This is the end game. This is where we really, really, really want to see lots of those happy customers, happy consumers, happy users, and of course, the service provider-- and the service providers are happy with the service that they're providing as well. So, the key to this is delivering and supporting. And it's making sure that you hit that spec. Okay. That specification is so, so important ahead that's supported and delivered in line with customer/user needs.

 

That then, creates value for everybody right the way through -- the right the way through the ecosystem. Now, if you ask most users what their major concerns are about IT services, they're going to say to you if it fails, fix it and fix it quickly. And if you change it, change it and get it right. After that, most of them, Yeah, OK-- yeah, hopefully, that it goes as well what they need it to do. So, it's all about that deliver and support.

 

So, as you can imagine that some of the key practices that are going to be involved here are incident management, change control, problem management, and of course, our good friends in the service desk-- all four of them key, key practices in helping to deliver good service management.

 

Practices are sets of organizational resources designed for performing work or accomplishing an objective. The practices are defined against the four dimensions of service management.

 

So, a practice may include people, processes, technology, skills, objectives, suppliers. They could all be part of a practice. So, practice could be as simple as two people sat at a monitor with a capacity management tool just watching the throughput in a database. Or a practice could be as complex as a global follow the sun service desk. The SVS includes three different types of practices. General management practices are ones that have been adapted for service management from general business management practices.

 

The service management practices are the traditional ITIL service management ones that you-- the people will know and-- know and love and ask specifically about service management. And, finally, there are three technical management practices, which as the name suggests, are to do with the technology that helps to deliver service management and services.

 

You'll notice we've got two different coloring schemes here. The ones that are greyed out are ones that are not part of the ITIL 4 Foundation syllabus, so you've no need to worry about things like architecture management, organizational change management, project management, business analysis, software development, and management.

 

They're all key parts of what ITIL does, but we've got to limit what we can actually deliver as part of the Foundation syllabus.

 

Goal number one is making you more effective, better at what you do. Goal number two, the one related to -- where the one related to efficiency, to money, to using resources wisely-- nearly said wildly there, which might be the same. The final one is making sure that the services that you provide are still what the organization needs-- so that continual alignment between the services you offer and changing business needs.

 

And that's one that's often overlooked in continual improvement where people do usually take the effectiveness, doing things better, or the efficiency, looking after the money route. Continual improvement needs to be embedded into every fiber of your organization, and it's absolutely everybody's responsibility.

 

So, it's very, very important for continual improvement as a practice to make sure that it's gotten methods of capturing all potential improvements, and they won't come just from just in the management part of the organization. They could come absolutely from any one of the stakeholders in service management. One of the big roles that continual improvement has also got is ensuring that it helps to develop improvement-related methods and techniques.

 

Now, what you certainly won't see is having the same method that covers the whole of the organization but certainly, having principles around improvement. You've got to capture the ideas. You've got to make sure that you prioritize the improvements.

 

You've got to make sure that each improvement can be properly planned and justified and so on. But you can develop different related methods for doing that. What you will find is organizations generally capture all of the ideas for an improvement in a continual improvement register.

 

They're all there. It doesn't mean that they're all going to happen. It just means that you can see, and you've got visibility. And what was that guiding principle?

 

Promote visibility-- you've got visibility of all of the potential improvements in the organization so that you can see them together. Somebody somewhere has got to make a decision. If I've got a bag of money to invest, then I need to invest that bag of money in whichever service or whichever service management practice needs it.

 

So, I might have one person asking for extra people, another person asking for training, another person asking for new technology. What I've got to do is make sure that I can understand which improvement is going to give me the most value for my organization. So, I will record all of those improvements in that continual improvement register.

 

First, encouraging continual improvement across the organization. What you need is that passion for continual improvement and the ownership of continual improvement. I see so many continual improvement initiatives that fall by the wayside because they've got no ownership, they've got nobody monitoring them, they've got nobody taking the initiatives forward, and so all the good ideas simply fall on stony ground and don't germinate into anything that's useful for the organization and can add value.

 

Securing time and budget for continual improvement and that needs some of that ownership across the organization and encouraging, as we said in the previous point. But securing time and budget is very, very important. Again, a lot of continual improvement initiatives will tend to fail because people don't ring fence the time to make the continual improvement.

 

And they try to do it as an end of desk activity oh, we'll just slip in when we've got time. It just doesn't happen if you do it like that. Identifying and logging the improvement opportunities. Promoting visibility is massively important and seeing all the improvement opportunities together quite often you'll find that you'll look through the improvement opportunities have come from different places and you actually get, oh, yeah, actually that's the same improvement opportunity, but worded slightly differently like different parts of the organization.

 

I remember doing some work for an organization in the UK that runs ambulances and what they said was go around the organization and see what the improvement opportunities are. We went around the organization. We looked the improvement opportunities and what we found that a completely different parts of the organization they actually identified the same improvement opportunity.

 

Now the beauty of that is you can put that op you put that improvement opportunity into place provided there is a business case for it and so on. And actually what you've done is made a number of stakeholders a lot happier with the service and the outcome of the service. Assessing and prioritizing in improvement opportunities. We all love a quick win, and may well be some of your improvement opportunities that fall into that category. But you've got to look at improvement opportunities against the budget you've got, against the time it's going to take to realize them, against what it's actually going to cost to implement them.

 

Making sure you've got a business case for any improvement action. This is a massively important area and we'll rely on other service management practices and other ITIL practices, in particular something like service portfolio and portfolio management, which we don't actually cover in this course. But certainly when we're making those business cases for improvement, quite often people will express the business case for improvement in different ways that person A says, oh, this will benefit the organization by seven bananas, person B says this will benefit the organization by 14 oranges, person C says this is worth two walnuts.

 

And you kind of think, well, how do I compare walnuts, with bananas, and oranges? And what happens if somebody brings cherries along? What do we do, make a fruit salad? No. So you've got to have the ability to be able to compare. So having that standard way of making a business case for improvement actions makes lots and lots of sense. Helping to plan and implement the improvements. What C continual improvement people are not going to do necessarily is roll the sleeves up and get themselves dirty, but certainly the planning, the implementing, making sure the resources are available is a key part of the role of continual improvement.

 

Measuring and evaluating any improvement results is also massively important. Yet we had the hypothesis that said if we do improvement x, then we're going to generate result y, did we actually do that? We made a business case for this improvement that said we would save XYZ, did we save XYZ over that particular period of time? So making sure you can measure and evaluate improvement results now that has an added bonus.

 

What that added bonus is that when it comes to making future business cases, you can see how accurate you were in your original hypothesis, so you can add more trust quite often in the business cases. So measuring and evaluating results doesn't just prove that actually it works, it can help continual improvement improve itself.

 

And the final one on the list there is coordinating improvement activities across the entire organization. And improvement, almost certainly because of the holistic nature of service management improvement's going to involve an awful lot of different people. It's going to involve a lot of different stakeholders. It's probably going to involve third parties, changes to processes, changes to procedures. It's going to involve changes to information, changes to technology. That all needs coordinating, that's the holistic nature of service management. Failure to coordinate is planning to fail.

 

You remember back to when we talked about the value chain, the service value chain, and we talked about how each of the individual practices will contribute to the different value chain activities to a greater or lesser extent. Well, this is the way that it looks for continual improvement. Now, I think the obvious one is the value chain activity there is the second one down improve where continual improvements structures and those structures that you build, that limited number of structures, to allow you to do continual improvement.

 

Then continual improvement make sure those resources are in place, the activities, to enable improvement at all levels strategic, tactical, and operational within the organization and within the service value system. I think it's probably true to say, as well, that continual improvement is going to be joined at the hip to planning and that they're going to work very, very closely together.

 

Not only continual can continual improvement be applied the planning activities, the methods, and the techniques to make sure that they're relevant to the organization's current objectives, but it is a lot of the planning activity that takes place within continual improvement that's going to be passed over into the planned phase of the value chain.

 

Looking at the rest of the value chain there and continual improvements interface with those particular areas now for certain continual improvement is going to need information from every one of those value chain activities. They can all improve. Continual improvement is about everybody in the organization improving.

 

So engage, design, transition, obtain, build, deliver, support each of those value chain activities will be subject to continual improvement. And the continual improvement practice is applied to all of them. Now, what you might find is that, typically, you will find continual improvement will work more on, perhaps, deliver and support as an area stuff that's live, services that are live.

 

That's, typically, where continual improvement will work. And they might make improvements, but they tend only to be smaller improvements. Because if you've got your design, and your transition, and you build correct, then all you going to be doing at that stage is making small incremental improvements. So it might be that you make a 100 improvements there, and the value of each improvement is just one.

 

Now, it almost certainly, there'll be less scope for improvement in engage, or in design, or in transition. let's say, for example, in design, you might only find and make one improvement in design, but that's got a value because it's so fundamental to what you're doing. It's got a value of 100. So the net value of 100 one unit improvements to deliver and support was 100.

 

The net value of one 100 unit improvement to design is 100. So, as you can see, it's just as important in an organization that continual improvement works on all of those value chain activities and all of the other practices.

 

Next practice we're going to take a look at is information security, and its role is to protect the information needed by the organization to conduct its business. It's about managing risks to the confidentiality, integrity, and availability of information. Confidentiality is to do with the physical security of data, so it's password protection, encryption, whatever else it might be. Integrity is to do with being able to trust the data. So if you think about your bank account, your checking account, and the different ways that can be updated, you can go to an ATM machine. You can do telephone banking. You can do internet banking. You could bank on your mobile, on your cell phone. There are a whole host different ways. And you've got to be able to trust that all of that data is being updated it's been updated faithfully.

 

And then finally, availability of information this is actually one that a lot of people don't consider as part of security and information security. You ring up to any organization that you've got anything to do with insurance or banking so on and they're always going to ask you some security questions. So they ask you security questions. They've got to do that for regulation. What's your secret word? What's your mother's maiden name? What's your inside leg measurement? All of those different things that they'll ask you but they got to have the answers available in front of them to be able to say, yes, you are who you say you are. And if they've not got that information available and then you can't password check and so on. Then that's going to mean that they're in breach of regulations if they can't do that.

 

So confidentiality, integrity, and availability of information are massively important to information security, as is monitoring authentication and non-repudiation. So authentication, I ring up my service desk. I've forgotten my password. Who are you? I'm the CEO of the organization. Oh, OK, then I'll just change your password. Well, I can't. I've got to prove I'm the CEO of the organization first. I'm not just going to give you access to the CEO's private accounts. And their non-repudiation what's making sure that somebody can't deny that they took a particular action so making sure things are logged and stored and that we've got a history of what's happened from a security perspective when people logged in, when people logged out.

 

And it's important as part of information security that you take the needs of the business, and you transfer them into and make sure that you've got the architecture, the training, the people, the procedures, the processes that are going to make this work. So a lot of this will feed into the design phase of services from an information security perspective. The people working in this area need to be information and security specialists first. Service management people technology people probably going to be second. And they've got to have a balance as well between prevention, detection, and correction in information security, making sure prevention, ensuring that incidents don't actually occur.

 

Now if you look at most organizations, you will have some sort of password protocol that will be in place. You've got to change your password. You've got to change your password every six weeks. You can't use a password that you've used in the last 15. You can't have two letters and two numbers together that are together in the alphabet. I'll follow on after each of the three of the characters have got to be special characters, and one of them got to be Klingon. They're trying to prevent incidents may be over the top then maybe not the Klingon bit. So the prevention, ensuring that security incidents don't occur, the detection, making sure that if we do get an issue that we can rapidly detect incidents that can not be prevented. We see almost weekly in the news now, we see major corporations that have suffered data breaches and hacking attacks.

 

And how quickly and reliably can you actually detect them? Some organizations, it's weeks before they actually detect something, and they'll turn round and say, oh, the last 47 million people to do business with us need to change their passwords. What? How has it taken you that long to actually notice this? So you need not only prevention but to invest funds and effort resources into detection. And of course, when things go wrong, where the bulk of the funding goes now at the moment strangely is into correction recovering from incidents after they are detected.

 

Actually, to be honest, you need to maintain that balance so that a lot of your funding doesn't need to go into correction, recovering from incidents after they are detected. You learn your lessons and make sure that you don't suffer the same information security issues more than once. A key message for information security though, is to design in information security into your services, whether you're building them intuitively or not, making sure that security is there from day one.

 

It is massively difficult to retrofit security to something that hasn't been designed for it. You can imagine you've got a brand new house a brand new home. You've got rarely sleek hardwood mahogany doors. And suddenly, you realize there are no locks on them, so you've got to get somebody to come along and drill big holes to put locks into your beautiful mahogany doors that you thought look so, so good. They weren't designed to have big holes drilled through them. They don't look so good now and what you paid for them. yeah, retrofitting security doesn't always work, doesn't always look good design it in.

 

Its role is to establish and nurture the links between the organization and its various stakeholders at the strategic and tactical levels. And it should apply to all relevant parties. So that can be from a stakeholder perspective, it can be sponsors. It can be the customer. It can be the suppliers to the organization. It can be any of these people. Each of those stakeholders' needs and drivers are understood, and products and services are prioritized appropriately.

 

I said before that it was massively important thinking about utility, the functionality of a service, the warranty, its fitness for use. It's massively important to understand how each of those elements created value for the consumers, for the customers, for the users, for the sponsors. And each of those has got a different view of what value is. Relationship management got an important role in understanding the strategic and tactical value of services we deliver, and making sure that particular relationship is nurtured.

 

It's also got other roles, as well. It's going to make sure that conflicting stakeholder requirements are mediated appropriately. You might have multiple parts of the organization wanting to use, for example, collaboration services. And it might be that you've got a rollout that you've planned that's going to be an iterative rollout, one particular area at a time, and all of the customers feel that hey, we should be first. We're the most important.

 

So helping to mediate that is an important part of the relationship management role. Any stakeholder complaints and escalations are going to be handled well through probably an empathetic yet formal process, so making sure you've got somebody at the top of that tree, one before your C levels and your senior execs, who could be escalated to to make sure that those complaints and escalations are handled in any sort of way that will make the customer and the consumer happy.

 

And finally, what we're probably going to look at is making sure that relationship management contributes to every element of the service value chain. But it's particularly important that it contributes in the engage part of the value chain. What we're going to look at now is how relationship management interfaces at strategic, tactical, and operational levels, and helps to maintain that relationship.

 

On one side of the organization, I've got the consumer. On the other side, I've got the service provider. And the service provider and the consumer what happens in the organization is they need to have a relationship.

 

[Video description begins] He writes CON and SP on the adjacent sides of the triangle. He then draws two horizontal lines crossing the triangle. The triangle is now divided into three horizontal sections. [Video description ends]

 

They need to engage the service provider and the consumer and the customer. Now that's going to happen at a strategic, a tactical, and an operational level.

 

[Video description begins] He writes ST, TA, and OP on the three horizontal sections. [Video description ends]

 

And we've got to make sure that relationship works now. Within service management, we've got three practices that are going to help us to do that. Two that we see later on, one that we've already seen.

 

We know the role of our people in relationship management is somewhere in there. And so what we've got is relationship management, and what it's doing is looking at the relationship in a strategic and tactical sense.

 

[Video description begins] He writes RM inside the top-left section of the triangle, and draws two way arrow. [Video description ends]

 

What you're going to see a little bit later as well, is that we're going to have service-level managements who

 

[Video description begins] He writes SLM inside the middle section of the triangle, and draws two way arrow. [Video description ends]

 

were looking at the relationship from a tactical and operational perspective.

 

And then a little bit later still, what you're going to see is you're going to see the service desk.

 

[Video description begins] He writes SDESK inside the bottom section of the triangle, and draws two way arrow. [Video description ends]

 

And the service desk is looking after that relationship between the consumer, the customer, and the service provider from a purely operational perspective. Maybe just getting up into tactical a little. Now, what we've got is full coverage there. Now what's very, very, very important in any organization is that we've talked about how important perspective is. a perspective of the service from the customer, the consumer, the sponsor's perspective, the chances are that the sponsors of the service is sat somewhere up here.

 

[Video description begins] He draws an icon outside the top-right side of the triangle. [Video description ends]

 

The chances are the consumers of the service, they're all sat somewhere down there.

 

[Video description begins] He draws an icon inside the bottom-right side of the triangle. [Video description ends]

 

And they've got very, very different views of the way that the service works, and is that service are those products giving value? So we've got to understand that value at all levels. And that's what these different practices are actually helping to do.

 

[Video description begins] He highlights the three sections of the triangle. [Video description ends]

 

Now two things I think here that are very, very, very important.

 

Number one, you need ownership of these people here. They've actually got to talk to each other at some point. They can't live in silos.

 

[Video description begins] He highlights RM, SLM, and S DESK inside the triangle. [Video description ends]

 

Otherwise, it's almost like dealing with three different organizations. So there absolutely has to be communication between these guys about perspective of service.

 

[Video description begins] He draws two way arrow between RM, SLM, and S DESK. [Video description ends]

 

And these guys up here, what we've got is it might be the sponsor thinks a service sucks. It could be that down here that the operational people think that the service is absolutely magic. It's great. So we need to understand that. And from a communication perspective, the best communications happened at peer level.

 

[Video description begins] He draws two way arrow inside the three sections of the triangle. [Video description ends]

 

The service desk, you've got the best handle on the users. Service level management, probably best at the tactical level. Relationship management, up at this strategic level. Why? Because the people on either side of this divide have got the same frame of reference for what they're talking about.

 

I'll leave you with this though that in any organization, the most dangerous conversations where people can totally misunderstand is if this conversation starts taking place between the strategic service provider and the operational consumer or user. Or the other way there they're the really, really dangerous conversations. Not because people are trying to be clever or trying to pull rank in the organization, but actually they've got very, very different frames of reference for what good service looks like.

 

So the next one of our general management practices is supplier management. And its job is to ensure that the organization's suppliers and their performance are managed appropriately to support the provision of seamless quality products and services. A lot of it is about value for money and getting value for money from the suppliers.

 

Supplier management creates a single point of visibility and control, and we'll see why that's important in the next slide. And supplier or sourcing strategy defines the organization's plan for how it will leverage contribution of suppliers in achievement of the overall service management strategy.

 

So how much outsource in an organization does, how much it uses suppliers, where it uses suppliers, what types of suppliers it uses, will define a lot of your service management strategy. And it's led to organizations using techniques such as CYAM, service integration, and management and creating a CYAM layer in an organization to allow them to manage multiple suppliers in a value chain.

 

Supplier planning makes sure that any new or changed services. Then the suppliers know exactly what their role is, making sure that we understand what the supplier will contribute. Happens so much doesn't it where a new supplier, a change to a service, and all of a sudden, something the supplier used to do or didn't used to do kind of gets all confused. So supplier planning is important. Evaluation of suppliers and contracts so in the stage before you engage suppliers, making sure, looking at suppliers, and continuing to look at suppliers and health check them through the life cycle of a contract and whether they're actually hitting that contract. Supply categorization is an important role. Suppliers are categorized as in there are many different categorizations of suppliers.

 

And the ISIL uses just talks about strategic, tactical, and commodity suppliers fairly obvious where that where the actually sits. And what you tend to find and the reason why a single point of contact for supplier management is so important is the strategic suppliers are very often managed by individuals whose sole role is supplier management. They're experts in their field. But once you get down into the lower categories of suppliers, tactical and indeed, commodity, it's not really worth engaging a full-time supplier management on those on those organizations. And what tends to happen is that the specialist supplier manages that single points of contact in the organization almost acts as consultants to other people in the organization who will manage suppliers as an end of desk activity.

 

It might well be that the primary role is within a DevOps toolchain or is within change management. But as a secondary role, they manage a particular supplier. So the supplier management specialists act as consultants, making sure that we're consistent in the organization in the way that we actually manage our suppliers missed one out there drop back to supplier and contract negotiation. Supply and contract negotiation requires specialists, particularly with certain contractual language. Now they're not the people who are the absolute specialists in the contractual language.

 

You'll have illegals within the organization who will do that, but they're certainly going to need to know the basics of contract law to help them to negotiate the correct kind of contract. Anybody who's ever got caught up in best endeavors and reasonable endeavors will know exactly what I mean. Supply and contract management itself, making sure that the contract is being managed, that all the deliverables from the suppliers are being adhered to, whether that be reporting or other such knowledge being passed, making sure that the communication's happening, and now leads into the performance on the warranty management.

 

Performance management hopefully, everything goes very, very well, and we don't have to engage service credits be they positive or negative to the organizations that we're using as third-party suppliers. But I think certainly, from a warranty management viewpoint, if we do need to go back and claim some money from an organization, a third party under warranty because they've not met performance, the supplier management practice is where that happens. And finally, contract renewal, if we're lucky, contract termination if that particular organization either isn't providing value or you no longer need their goods or services. They're all the specialist areas that supplier management practice will be involved in.