Share this webinar
An ITSM Program usually starts with the ‘Service Desk’ and ‘Incident Management’. While that’s a great start, the real benefits come when you move beyond your first process and introduce ITSM as the foundation for extraordinary service delivery.
You will learn:
- A brief history of Service Management and its underlying benefits
- The “down and dirty” of designing a process
- The importance on communication and obtaining “buy-in” for ITSM
- The concept of the ITSM program office
- Building and executing an ITSM roadmap
David: All right, Cecile, can you here me ok?
Cecile: I can, thanks.
David: Thanks. Hey, everyone, welcome to today’s webinar. My name is David Mainville and I am going to be leading you through this presentation and I also want to say that we are NAVVIA. So also for those of you who are new to our webinar series I am just going to give you a little bit of introduction as to who we are. NAVVIA is 100% ITSM focused company. We have been in business for 14 years and through that time we have been 100% focused on helping organizations of all shapes and sizes implement IT service management.
As a company we have two major offerings. We have a software that provides really a toolkit, service management program offices, make the most of their service management program as well as a whole suit of consulting services that can help organizations in any stage of their ITSM journey.
Welcome to Your First Process and…Beyond! The reason I came up with this topic for today’s webinar it became apparent to me from my trips to conferences, meeting with clients that folks are at various stages of their ITSM journey. I wanted to make something really important. It is a journey. ITSM is not installing a tool. ITSM is not one singular thing but it is really a journey and we have people on this call here today who are at every stage of their journey. And that is great. But I think it is also important to remind folks that when it comes to service management that is really about taking that holistic approach and it is really about looking at it as it is entirety. Not just in terms of incident management or doing some metrics or installing some tool but in its full entirety. That is why I really want to try and convey the message from today’s webinar.
So, why do people do IT service management? Well, first of all IT service management is born out of necessity. What do I mean by that? Well, there was reason, there were rationales for this framework. This set of best practices to be put together and it really started back in the day when IT was first introduced into organization.
It was important to make sure that the chaos, the problems, the incidents, the issues resulting from this implementation of technology to support the needs of the business, to make sure that chaos was taken out of it, if you know what I mean. And the results of IT service management are really to deliver superior service and improved business outcomes.
ITSM came really out of necessity. And, I mean, I was around back in then, in the early days of service management, my background is of a mainstream guy, and I remember back in the day we applied principles of service management then. And it is just as valid now and I am sure they are going to be just as valid in the future.
So, IT service management. What is it and what is it not? I do want to emphasize that IT service management is not a tool although many of you believe that a tool is the most important part of the service management program. And while processes are very important service management is not about the process itself. Process is a component. Nor is it a department or a group of people although people make a very important part of a service management program.
Mostly important, service management is not nice to have. Service management is critical to the operations of today’s modern data centers.
If you take a look at the economy as a whole IT represents a very significant span for many companies. Very, very significant span. And the purpose of service management if we really want to be honest about it is to make sure that IT is run correctly and serves the business because without a business there would be no IT. We would not have our jobs. It is important that we maximize the investment that our companies are making in IT service management into the IT systems that are supporting the needs of the business. So it is very critical to understand where IT service has its best application and that is making sure that IT us run correctly and serving the needs of the business.
If you have to ask me what I believe IT service management is I really believe it is a practice. And like anything that is important to do practice makes perfect. I go on and say that service management is a mindset. It is the way that we engage business. It is the way that we operate our systems. It is the way we support our users. Service management is in a project. It isn’t a one-time-thing. It is definitely not a lift and shift process from an existing tool into a new tool. It is a mindset that is completely focused on maximizing the value that IT brings to the business.
You know, IT service management isn’t new. I mentioned that when I started in this industry I started, I guess it was in the early ‘80s and service management was already a big part of the way that we manage our mainframe environments. We had incidents. We had changes. We had a reconfiguration management database. And we used those things to get value and I saw it every day. I saw the value that service management brought to the organizations that I worked for.
One case in point, one example, I remember using information in our incident management database to identify the group cause of a problem, which saved our company millions of dollars. Service management has its benefits if practiced. And service management isn’t new. We are sitting here at the crossroads of what it came before and at the crossroads of where service management will evolve to. And I am confident that service management will be applicable today into the future as it was from its humble beginning.
The roots of service management go way back. They go way back into the ‘70s. And when you think about it, service, if you take IT out of it, service goes back even further but the application of service management. And the IT space probably started in the 1970’s with something known as IBM’s integrated Systems Management Architecture. And that architecture was put to place to really address the needs of managing information technology in support of the business. So all the way back in the ‘70s people were already thinking about the importance of service management and its applicability to business.
In the ‘80s things evolved, we saw the beginnings of something called ITIL or something called the ITIL infrastructure. We also saw the evolution of a whole new suit of technology called Enterprise System Management (ESM).
Enterprise System Managements was a suit of tool very much focused on detecting issues on the infrastructure alerting us to those issues prior to them causing even more serious problems. And when you look at it, ESM was very much underpinning of what we were trying to do today with service management. I was beginning of automating of much what we were doing from a service management perspective.
In 1990’s we saw more and more of organizations that is getting on, so to speak, a bandwagon of process. Why? Because these organizations like IBM, Microsoft. MOF and others saw the importance of process in terms of improving liability and availability of the services of the software and the technology they provided. So we saw things in ‘90s such as IBM’s IT process model which was a great holistic view of all of the processes within IT, how they interact and how they support the needs of the business.
Microsoft came to the table with MOF, which was their management’s operation framework. Yes, much of it was built on the ITIL foundation but Microsoft also introduced their own spin on it in support of distributive technology. And the distributive technology was back in the ‘90s then very prevalent part of what we are trying to support in IT perspective. Microsoft very quickly realized that systems and techniques we apply to the mainframe world is a very much applicable to the distributive computing world.
We also saw the release of ISACA’s COBIT which stands for control objectives of IT which was a way for auditors to get a hand off of what was required by IT practitioner, what was needed to ensure that the system was running so that when they came in and audited the IT sector they were able to get back and be assured that the right processes, procedures, controls were in place.
We also saw a framework for eTOM which was very much focused on a specific industry that is a telecommunication industry but also tool much of what was there with IT process model, Microsoft MOF, very similar models but applied to a specific industry. I guess what we are seeing here is the evolution of IT management that not only stretches back into the ‘70s and beyond but it also spans multiple industries.
In the 2000’s we see a lot of from the service management perspective: ISO20000 was introduced and it was one of the first frameworks where organizations can help actually certified in service management practices. 0We saw the evolution of COBIT and COBIT 5 and mostly recently we saw the merge or the joint venture between Capita and the British government for the next generation of ITIL and the best practices that it supports. So the roots of service management go way back and I am convinced and I am sure that they are going to continue into the future because the domains have not gone any easier. In fact, there are so many moving parts in the IT organizations then ever before. We are dealing with a lot of different technology, a lot of different stakeholders. It is really important more than ever that we have a quick process and good technique place to make sure that we are delivering the best value of business.
Service management is timeless and it is technologically independent. I mentioned before that my first introduction to service management was back in the mainframe era and back then mainframes were introduced into the business sector more that it had been in the past. PCs didn’t exist. We did not have distributive computing. If you were to do computing it was going to be on a mainframe. And more and more were mainframes on how business process was executing. If we are going to start executing business processes on technology it is important that we keep those systems reliable and available. And that is really where the essence of service started.
You know, in the late ‘80s and ‘early 90s we started moving towards the distributive computing and we almost forgot what we have learned from the mainframe era. People started installing computers on their desks. Business units or business departments started putting systems app but without the support of the good service management processes and we saw a lot of chaos. Changes were going in the middle of the day, systems were going up and down and it actually resulted in the distributive computing environment being repatriated into what used to be a mainframe domain. Once they repatriated into that domain we started applying those best practices and distributing computing came under control. And a control not from the perspective, you know, like, ‘I want to be in charge of it.’ But control from the perspective of getting the best value. We are driving the efficiency and effectiveness of the system and we are doing what is right for the company. We continued on this evolution and we saw a large move towards outsourcing and some people would say, ‘Oh, you know, if I outsource I don’t have to worry about the process.’ Let vendors get worry about the process. You could not be further from the truth because as a company you are ultimately responsible for the services that are being delivered. And any company that I know that outsource there was still within the organization and there was still within central company that was responsible for that outsourcing relationship.
It soon became apparent that process was a key. It was important that the outsourcers had good processes but it was also important that it was a company that drew what those processes were because ultimately it was our service. You are responsible for it. It was meeting the needs of your business and process was a way that you brought your outsourcers under control.
We are moving into an era of cloud computing. A lot of organizations are bringing in applications. It could be IT service management tools that live in the cloud. It could be business applications like workday or salesport.com that live in the cloud and again there are some of us out there who would think, ‘Hey, there is no reason to have service management, ITSM programs if we have everything in the cloud.’ That is not the case as when something goes down and that SOR systems hosted on salesport.com or when that HR system hosted on workday goes down, well, ultimately, your users, the people in your company are going to be coming to you to know why. And good processes, the way you date your outsourcers, the SLs that you put around those outsourcers, the mechanisms to have incidents and events alerted back to the organization is all part of good service management practice. And it is very important even in the cloud computing environment to ensure those practices exist.
The future? Who knows what’s that going to hold but one thing I can tell you, that in the future system management and service management is going to just as applicable as it was back in the day of the mainframe, the distributive computers or the era of outsourcing your cloud computing.
Service management is timeless. Its technology is independent and as a company we know we have been doing this for 14 years and many of us in this company have been doing this for much longer. And we have seen these concepts of service management transcend all of the technologies. So it did not matter if you are running info man on a green screen off of a mainframe or you are running the early versions of remedy or some current tools that live in the cloud, service now or easy Vista or other tools that are up there. It doesn’t really matter. It is technology independent. It is really important to have these practices in place.
So, where do you start your journey? For many, the journey begins with process but I do want to pint out a process is only a piece as there are whole intervolving set of objectives and things you have to accomplish as part of the service management program but many of us, gratefully so, start with process.
When you start with process it’s critical. Critical that you engage your stakeholders. Again just looking at it from my experience and experience of our company service management programs that feel to engage stakeholders and what do I mean by stakeholders ? I mean people at all levels of the service company, people at the service desk, the technicians, folks at the IT department, the business users all the way up to senior executive management like the CEO in the SCO. All of those individuals have a stake if you will in a well functioning service management program and reliable and available systems. When you engage your stakeholders it is important to listen and if you don’t listen to the needs of your stakeholders and you don’t understand what their issues are and if you don’t know what their concerns are how are you supposed to design something that is going to be better? You really need to take those needs into consideration and make them part of any process design. I highly encourage anyone to take an opportunity to reach out and talk to folks.
What is working in the process? What is not working? What are you trying to achieve? What is your hot button? What are the things that you are looking for? Are you looking for timed market, are you looking for their availability, are you looking for turnaround times? These are the things that you need to understand before you design the process. These things inherently don’t just come out of the tool or out of an ITIL book. It comes from talking to people.
Once you understand the needs of individuals it is also important to develop a plan because without a plan any road will get you to anywhere. And it may not be the right road. It is important through this discussion, this assessment to survey your stakeholders that you understand the current state of service management in your organization. And this is not a one-time thing. This is something you can do over and over. You can irreversibly assess your program so you can feed back to management that in fact that you do have value to the business. So it is important to understand your current state and just as important is important to get some quick wins because people want to see results. So any time you are embarking on a process deign in a service management program it is important to look for the hot buttons and see if you can provide quick wins.
Sometimes depending on the maturity of your organization it might be as simple as holding a meeting like a cap, if you are not at that level of maturity. If you are more sophisticated there could be other quick wins. I have been involved as the co-founder of a NAVVIA company but also prior to that numerous assessments and I have always seen quick wins.
There is always something that you could address and that is showing that you are listening to your users and that you have been responsive.
Once you’ve got those quick wins in places it is important to do some enhancement of the process so bringing those processes is a higher degree of maturity. It is very, very critical. And also the tools and technology that supported, no plan can ignore that the processes are supported on technology. But no plan should ignore the fact that there are processes involved. And I know that a lot of folks will say, ‘you know what? We are going to install it out of the box.’ Or we are going to do lift and shift process to that tool. Well, ask yourself a question: why are you doing lift and shift in the first place? Is it because people are complaining on what you have. If they are complaining on what you have how do you then think that moving in to a new tool will make it any better? If your process for doing a service request is broken no tool is going to fix it then. It is going to take time to think and look where it is broken, to ask people about what is broken and then make sure that in the new technology solution, which may have a lot of advantages over the old tool, but I am not saying it won’t but you want to make sure that in the new technology solution you have accounted for the deficiencies in the processes in the first place, because I am going to tell you something: if you look ate the organizations that are most respected companies in the world you will see that a lot of that company’s processes is based in information technology. Those companies have extremely deep roots in doing IT right. So doing IT right means listening and supporting the needs of the business. Not doing a lift and shift process from one tool to another. It is all about the improvement and meeting the needs of the business. And you cannot forget that organizational change is a part of that because people are not going to readily adopt any change, whether it is for better or not. People are gong to be resistant to it. They are going to be a little dubious or skeptical of that new change. Some people just don’t want to hear anything about it and we are passively aggressive. We actually try to torpedo your program. So any good plan should include organizational component, which includes communication, talking to people. You can’t build or design processes sitting in your office. You have to go out and talk to people and engage people.
Your organizational change will help drive you into that future state. When you do sit down to design a process you should design to improve. There is no point in taking process as is and moving it on to a new tool. Well, maybe there are one or two examples. Maybe you have a perfect process that is running great and you want to save some money going to a new tool but that’s not the case that I’ve seen. That is not what I’ve seen in the countless, and when I say countless, in 30 years that I have been in the IT industry I have always been in it as a service provider perspective. I was a mainframe technician. I fixed hardware. I supported customers. I ran an organization that provided field support. I always saw it from a customer perspective and I’ll tell you something- there is always something that can be improved.
It is very important that when you sit down and do a process design you are looking for what it needs to be improved. And for a lot of people that is hard. It is hard to figure it out how to do it and there is a lot of it because you are disconnected to stakeholders. All the way from the CEO down to the users and by staying disconnected you are running the risk of not implementing the process of the way it is going actually bring a group a better improvement. One of the best companies I have ever worked work, a mainframe company, has some of the best service management processes and I access system through the teletype terminal. Yes, a terminal that had a keyboard and a roll of paper that printed out the answer. And I connected it through a 300-baud modem. You know acoustic coupler. I stuck a phone into an acoustic coupler then dialed in. The technology had nothing to do with the effectiveness of that company’s processes. Nothing at all. What made their processes work was basically the fact that it was a mindset. Everything in that organization was based on improving customers’ service so when you entered an incident you had to actually add to it what you actually fixed. People can learn from that.
When you enter the ticket you also have to close it with what was result so that people can measure the satisfaction. These things are taken incredibly seriously and we had meetings surrounding the process, governance as I like to call it or good management when people came in and said , ‘Hey, why haven’t you closed the ticket?’ How does this ticket have no good information in it? How come this change was not submitted correctly? It is aspects around the process that are just as important as the process activities.
So whenever you want to design a process design to improve.
You also have to find the right balance. Now, this diagram here is an actual process model of someone at service desk organization. I found it on the web and it was one of those IT analysts’ report. I think they might have been forced to write it down. But it was an actual representation of someone’s process. You know, there is a balance. I like to call it 80-20 because a process is as much about a communication as it is about documenting the steps. It will have no value if people don’t understand the processes. If you are spending too much time in the weeds and the complexity will your business users, will your IT users, will your end users understand what that process is or would they glaze over and ignore it?
You don’t like people to ignore the processes. Now I am not saying that our process can’t be detailed but what I am saying is how that process can fail, how you break it down into its activities, how you break it down into its task, how you drill down into procedures and all be done in such a way that really improves the ability to communicate the intention of that process to the people in the organization. Once they understand they are going to be more likely to adhere to it and adopt that process. But if they look at something and their eyes begin to glaze over you’ve lost them. And then you have lost the benefits of a service management. So it is really important to find that balance.
When you are designing a process it is extremely important to engage all of the stakeholders. And you know what? They all speak a different language. The language a CEO speaks, the language your CIO speaks is different from a language of a service desk agent, a technician, and a software specialist. They all speak their own language. And what drives the individuals is different.
Everybody should have service management communicated to them in a language that they understand. You know, with senior management, it is really about improving business value of IT. It really is about making things more efficient. It is about taking the cost of IT again, when you look at the economy as a whole one of the biggest spends of organizations is information technology so that is the money that is being spend. Yes, it is to support the business but it is also a cost. And anything you can do to reduce that cost would be welcomed to the senior executive to the company.
When you move into different parts of the organization the things change, the requirements change, and the needs of the individual change. Maybe when you are speaking to a technician it is important to communicate how that is going to reduce the number of averages therefore the number of times they call 3 in the morning. Or when you speak to a service desk agent you need to talk in terms- well, this knowledge base has improved your effectiveness in resolving the next issue. Or when you speak to someone in the software group you can talk about how this better integration between application development operation is going to make a more seamless production of new software to the organization.
Ultimately it all supports the needs of the business but again going into the CIO and talking about CIs and detailed elements of ITIL is probably going to get that person to glaze over. So you must engage your stakeholders in the language they understand.
You also need to keep your process documentations simple, concise and clear. I think it was Mark Twain who said, ‘I apologize for writing such a long letter. I didn’t have a time to write a short one. What does that mean? It takes work sometimes to make something clear and concise. It takes energy and effort. It is easy just to put a lot of words down on paper. It is harder to make something clear and concise. If something is clear and concise that effort that you put into doing that is going to be shared with everybody in your organization, so that is really critical. Keeping your process simple, clear and concise. And never start from scratch. I mean, those days are gone. There is enough best practice information in the industry today. You don’t have to sit down and draw a change management process from scratch and take it for somebody who has been in more companies that I even hope to remember. 90% of most people’s management processes is the same. You submit a change, you assess the change, you go to a cab and you review the change, you schedule the change, you implement the change, you go back if it doesn’t work, you go ahead if it does. You notify the user that the change is done and you close up the change management. It is same for almost everybody. Yes there are new answers, the agrees of approval, a path that takes the approval process. Yes, a little different for organization but most of it is the same so don’t reinvent the wheel. There is a lot of good stuff out there.
Also from my experience and again just to remind you for 14 years we have been helping organizations implement service managements and service management tools. One of the biggest things I’ve seen derailing a service management project or program is the translation of the process into a supporting tool so you went out and bought the latest service management service desk tool. You’ve got some consultants in, they came, they defined and documented your processes, took that information, through over a wall, gave it to a technical person to implement they looked at it and said. ‘ I don’t have the details I need here.’ And when they had implemented what were going to implement or implemented the tool out of the box. Either way that was not the process that was defined and the process that people thought was important for business so a capturing of automation requirements as you are doing the process design, simultaneously with doing the process design is so critical for the success of a project or a program. When you are building a process and gathering those requirements, remember to validate frequently back with your stakeholders to ensure that you’ve got those requirements straight. And don’t get drown in this culprit. Validating is not an excuse for getting more requirements. Validating is really ensuring that the validates you have are good ones.
People talk about using different methodologies today like agile. Agile is not an excuse for full requirements definition. Just you are doing something quickly it does not mean you are not doing it in a planned orderly fashion. And that is another thing as there are lots of folks who might think IT service management doesn’t apply in a fast pace world of cloud computing and agile element. Well, it applies more than ever because you still don’t want to introduce that code to affect your clients. You still have to put controls. You just adopt and align the processes to meet more agile and flexible development approach.
And always remember to educate and communicate. Do not assume that people understand the process. Don’t assume that they are going to read it if you sent it to them in an email. Don’t assume they are up to share point and pull it down and fully understand it. You need to spend some time communicating and educating people. One of the things we see when we do assessment is that most people are not aware of the process of documentation. Most of that process documentation was built in a vacuum which was distributed by the email and that was the end of that. Most people don’t know about it, don’t care about it and, really, don’t have any idea about it. And that means what processes are they following? Or what they think should be the right processes. So a very important process design to point out is to educate and communicate. I once heard this very senior manager in an organization to say, ‘We don’t need to train people on this process’ tool. They are smart people and they will figure it out. Ok, that is true but each of them is going to figure it out in their own way, through their own lens, through their own interpretation and that may not mean that everybody is doing the same thing.
Every so often when you are doing service management you have to stop, you have to pause, you have to sit and ask yourself: Are you getting value from the ITSM program? So what does that mean? Well, do you have less incidents? Are the incidents that you are getting being result quicker? Are changes introducing less disruption to the environment? Are service requests handled more efficiently, more effectively? I can’t believe it. I was in an organization, not that long ago, maybe 2 weeks ago, where it takes 12 weeks to get a copy of Microsoft project for a project manager who needed that copy of software to do that job. 12 weeks! I mean, I can go to the store and buy it the same day.
So why did it take 12 weeks for IT to get access to a copy of software and to provision it to a user? That is totally unacceptable. And these are the questions you should be asking yourself. Are people happy with the service they receive? Are implementations going smoothly? Changes being introduced accurately? Are you getting value from your service management program? And the only way of knowing that is by putting some governance around the program. How do you do that? Make sure that your process is defined. Make sure you identify the controls for those objectives. Mae sure that when you have management incident process there are 7 great key things that you want to have done.
Meetings to control the closure of incidents. You want to make escalation procedures are working, whatever those controls are you have to identify them and then assign accountability for those controls, require evidence that those controls are being bad and then measure and report on it. And if you do this and shine the light on service management, service management will get better. If you think the service management is tool implementing a process and the tool and forgetting about it you are not doing service management. You are implementing a tool and that will take you so far but it is not going to take you all the way. You have to actually close that loop by governing the process that you haven’t placed.
Again, going back to that example when I was entering tickets on a teletype machine, I kid you not. It was a process. It was sitting down with my technical senior stuff, sitting down with our specialists looking at every incident, analyzing it, looking at a root cause, closing the ticket, that is where value of service management came from. It didn’t come from a teletype, I tell you. It came from the process. And again, I have already touched this point but beyond educating somebody in one process or one tool you have to make education part of a service management program in its entirety. Why?
Because training fosters adoption. Training helps you communicate the ‘why’ of the process. I am sure that some of you, folks, there have kids -I would be surprised if you didn’t- what is the first thing your kid says to you when you ask him a question? They say ‘Why’. People are ‘why-ers’ as they want to know why. And training answers the question. Why do you want to change the management? Why do we do incident managements? Why do we have service request fulfillment? Why do we have the SLM? Training a scheme of fosters adoption so build a plan that addresses all your stakeholders. The CIO does not need to go and become an ITIL V3 expert but a little bit of IT awareness might be good in a language that resonates with the senior executive position. It is also good for people who have to work in the process like submit changes or respond incidents, really understand the process and the tool and how it affects their day-to-day job. So you need and education plan to address all your stakeholders that include rich curriculum courses.
And consider various training formats. If you are launching a new service management tool or program a lot of people would put a lot of training around that but then forget about that as people change in the company. People move jobs, new people come in, people leave. So that training still needs to be available for newcomers. So consider various training formats like CVT because that is going to help you keep the newcomers speed on the process.
The other thing that I found really well when you’re training folks in the service management program is to consider using a ‘go to’ people. Now, what do I mean by ‘go to’ people? We all have ‘go to’ people in our company. The people we go to when we need something done. Those are the people that everyone respect, the people that always seem to have the answer, that are willing to pitch in and get it done. When the go to people delivered the ITSM training people listened because they respect those individuals at first place. Just consider using those folks as part of your education program.
Tying it all together. You know, I threw a lot of concepts over the last few minutes. I talked about the service management back in the day of the mainframe. I talked about the entering tickets into a teletype computer. I talked about making processes as simple and easy and concise. I talked about the importance of engaging your stakeholders. I talked about a lot of things when it comes to service management, you know, the parallels of changing, of just lifting and shifting, a process of one tool to the other without looking personal improvement. But how do you tie all that up together? How do you make sure it happens? What controls or makes sure that ITSM is functioning properly within an organization? Well, I submit something that is called The ITSM Program Office. Sometimes it is called the service management office, the IT or ITIL company center. It doesn’t really matter on the name. What matters is the function. And I tell you, this function existed when I started back in 1980’s in many organizations but the ones that I respected for sure.
And I tell you something when I started in IT and I was a mainframe technician we knew what customers had their act together and which ones didn’t. You get the certain customer and you say, ‘They are always having problems and they are out of control.’ You go to another organization and you are almost intimidated oh how great they are. They have their act together and you can’t pull over their eyes because they have a service management program and they have a service management office. They might have not called it that way in those days. I think they called it system managements, enterprise system managements but these are the people who were the experts in the processes. The folks who gathered and produced the metrics through issue the reports and actually you know what? They did continue the service improvement or service improvement plans against those reports. They were the folks responsible for communications about upcoming changes about outages, about the whole dynamic of service management. They’ve got in helping any time a new solution had been built to ensure that service management was designed right into the solution.
Now, you think that is impossible? If you look back at IBM and the way IBM architects systems there is a block within the architectural building blocks that is called service management. A system or a solution should never be built without some understanding and how it is going to be monitored, managed and controlled. So, having some good design components. This is in some big bureaucracy, ok? This is the furthest from the truth. You don’t need armies of people to do this. As a matter of fact, it is more of a virtual type of organization, maybe a couple of dedicated resources but it is more of a virtual organization which brings in the process owners ITSM subject matter experts, people who know about enterprise system management tool, your architectural group. Operations blocks. Boy, I mean, they are the guys on the front lines of all the systems. They need to be involved in any service management program. App dev and Apt-get, I have seen a lot of stuff on the net lately, webinars, articles, a lot of chatters around the gap between Apt and ITSM.
There shouldn’t be a gap. They are part of the process. You know a change, that goes as far back as understanding the requirements of new application and bring them on all the way through validation and testing and rolling it out.
So, app dev needs to be part of that. The business. People who connect you into the needs of the business and executives who help you steer and break the tie, so to speak, and resolve issues in these various group but in the executive steering committee to make sure that the ITSM program or a service management program is aligned to the needs of the business. Again, it is not a big bureaucracy. It is done before and those companies that we respect most of all I bet you they’ve got one in place because they run their organization on process, process lives in IT and someone’s got to oversea the process. And that is the service management office.
So I get it. Hopefully you get it. But how do you do it? What are some of the practical ways, because, you know, this can be very abstract comment or concept, they should say. It is very abstract, you know, ‘Oh, I’ve tried to do this before. It is really hard to do or I don’t really know what to do to design a process so how do I engage my stakeholders. You need to know how to do it and I think there are 4 simple steps.
And those 4 simple steps are:
- Make sure you survey and understand the needs of the business.
- Make sure you design and document processes that are clear and precise and are widely distributed and communicated.
- Verify those processes that are being followed because like anything entropy will take a call and if you take your eye of the processes they will degrade so verifying being followed will verify those processes healthy.
- We talked about the IT as an expenditure in the economy. Well, doing system managements, service system managements is also expensive if you are going to implement a new tool and a new process and all that comes along with that you better get the most of it. So verify. People are doing it.
- And then finally learn. Train people, teach them about the process, and make sure they understand it. And these things are not one time. This is a cycle of continual improvement.
Survey. Design. Verify. And learn.
What I would like to do now is maybe show you an example of how we in this organization do this using our own technology because I think it really helps if you can see this lay out in a sort of a pragmatical, practical approach rather than some abstract concepts on supplies. So let me take a moment here. It will only take 7,8 minutes to actually walk you through of how this can be accomplished in an automated streamline fashion.
So what I am going to do is to log into what is called the NAVVIA tool kit. This is what we developed in our house and we use in our consulting engagement and more recently people are acquiring it as their service management program. So I logged in and we embodied everything that we learned. So everything that I learned in my 30 years in service management, everything we’ve learned for 14 years being a company, the methodologies, the techniques, the best practices we’ve tried to embed within technology so it is just simple to implement.
If I did go out and survey some individuals on the maturity of the processes I can quickly create a survey project. And that survey project can consist of an unlimited number of survey questionnaires, which can come in from free built intellectual property that we included in our tool. So you are asking people about their program and you are asking them in a consistent repeatable way. Very, very simple. And once you have these surveys, the ability to launch in these surveys out to an organization look at the results through a series of dashboards reports. So you have opted minute insight to what people think about processes, about COBAT control, about the most recent ITSM tool implementation and bring that back to the service management office as a way of setting some baselines and identifying areas to improve, running a batch of reports, distributing those reports to management.
How many of you have been asked by management, ‘Show me the RY. Show me the value of the service management programs.’ Well, maybe it is important to do that by yourselves without having to engage the army of consultants but to go out and measure the relative maturity of processes. The specific maturity of an individual process or dive deep into a process and understand where the gaps might be in a variety areas of process, people, technology and others. And then to produce those reports it is very easy to understand passion.
The other important part is designing processes and communicating them to your audience but you also don’t want to spend a lot of time doing that. If you are able to come along and built your own little work space to develop your processes and then in that work space not start from scratch but to start from a library of predefined processes templates. And then use that intellectual property that has been built over years as the starting point for your process. Not to be your process but to be the starting point of your process, then to be able to go in and easily make changes. If you click on the process easily make changes to the process, for example, you know what, verify the users’ information. That is really the responsibility of the incident coordinator.
Make changes to swindling diagrams, make changes to the word doc, offer them easy way to use interface and then have the documentation produced automatically. So have a word document that is created at the touch of the bottom that includes any change that you made in the process of documentation.
For example, I made the change to the first flow chart there is a change in my word doc. Without go and update various artifacts but also see that change in a mind map, a RACI chart and these artifacts were designed to make it simple for people to understand, to revise a clear concise document, a mind map that is all that a lot of people need to understand the key aspects of a process. What are the activities? What are the tasks? A RACI chart, a flow diagram and some deep dive reports that go even deeper. And then have all that information in a nice, simple, easy to use place.
Also you have to have a way to verify the processes once they’ve been implemented so I can go ahead and say, ‘You know that incident management process I created? Let me govern it.’ Let me put some controls over that process based on industry standards like ITIL and COBAT. Let me point to that demo process while sitting over here. And without any expert knowledge of a COBAT and ITSM I have created a series of tasks, provide evidence of a service task function, that are a map to a control, that are a map to a role in your company with the frequency and then let these systems send out tickets if you will that people need to respond to with evidences that the processes are being followed. This is all editable and you can control it but it is a great starting point to make sure that these 12 controls around incident management are scheduled as evidence collected and, you know what? When your auditors come in and see that you are doing measurements around your processes and you have well defined and documented processes and that you are verifying that the processes are being met. Boy, are you showing that you are under control? Most importantly, you probably are under control and you are beginning to drive the real value of the service management.
And then learn, educate, train. What we decided to do is build in the ability to provide everything from introduction to ITIL. ITIL in 10 minutes, ITIL foundations - a whole host of education in the format that everyone in the company can assume and by doing that you are setting a common language in your organization. A common language in which people will understand the difference in changing and release, that people understand the difference between the incident and a problem. People understand a true value of service management. And just by enrolling in courses which are live or taking the recorded courses they get that foundational information that is going to help service management make success.
Anyway, I just didn’t want to take too much time on this but I just wanted to say that there are techniques, there are some tools that can help you take this really abstract concept which is service management and really starts: how do I design a process, how I govern it once it is in its place, and take that information and really pull it together so that you have in your hands those simple things that you really need to do, to survey to see what’s working and what’s not working, design to make it better, verify to keep it healthy and learn to keep people well educated. With that in place I think you really can take our service management program from your first process to beyond.
Thank you for being part of this webinar today. Once again my name is David Mainville. If you have any questions you can follow up directly to me firstname.lastname@example.org. You could also direct message me on Twitter. My Handle is @Mainville. And also you can check on at navvia.com/library where we have a whole host of service management, education and articles, white papers and prerecorded webinars. If you are interested in other ITSM contact I do encourage you to go up to the library. So, once again thank you for being part of today’s webinar. Take care, Bye for now.