The ROI of Problem Management
January 26, 2013
The dirty little secret is out…no one believes in Problem Management. Yes, we all want to follow best practices, but we seem to always fall short. The reasons are many, but we know it comes down to people, process and technology. That being said, we will take a look at some of the common pitfalls some have experienced and how you can mitigate some of the challenges and realize real “tangible” benefits as a result of implementing Problem Management for the service desk.
Jim: Good morning, good afternoon and welcome everyone to today's bright talk event. I appreciate everyone taking time out of their schedule to attend today's presentation on the ROI Problem Management that where will discuss really how to achieve tangible benefits through better process and analysis. My name is Jim Blayney, I'm the Director of Product Marketing here at FrontRange Solutions for the heat is on management product line. And I'll be co-presenting today with Diego Jimenez, one of our Senior Solutions Consultant of which I'm gonna let Diego give a brief introduction of himself.
Diego: Great. Thank you Jim and hello everyone. Just a brief background about myself, I started back in the early 90's as a front line support technician or not only is gonna help industry. Then moved to different positions that's tier to engineer, and then jumped into the consultant business in the mid-90s. I consulted on security and IT support, and then in the late 90s I joined the vendor side of things by joining a tool manufacturer. I'm an actual version 3 certified and have helped around 800 companies in their selection of tools. Jim?
Jim: Okay, thanks Diego, great. So today, in terms of the agenda, the goal of today's session is to ensure that you, the audience have a solid understanding of problem management to include what it is? What it's not? Understanding some key concepts and functions that make up the practice of problem management, and we'll also take a look at some of the common pitfalls associated with trying to implement problem management. And then lastly we'll take a look at and show you how that can actually translate into real tangible benefits in ROI. Also, we'll have a few minutes at the end of the presentation to take any questions that you have, so with that let's go ahead and get started.
So just to set the stage before we actually get into the presentation, we'd like to take a quick poll with the audience to really help better understand where everyone stands with problem management. And what I'm going to do is just go ahead and open this up, and that you can take a quick look there at the questions. And take a look at that and just really, have you implemented problem management within your environment? Very simple yes or no question and we'll see what the results are there.
Okay. So Diego it's look like the majority of our audience here is sitting at about 80% have already implemented some form of a problem management, the 20% have not. So that kind of gives us a good understanding and really a baseline to really have this conversation around problem management and realizing some of the keys and benefits in ROI.
All right, so we're gonna go ahead and close that. And we're gonna get on to the next slide here. Okay, so let's begin the session really by first getting some definitions around problem management, and really from a definition standpoint. We can take to look at how ITIL defines problem, and problem is an unknown or really an underlying cause of one or more incidents. And I think that's pretty straight forward, but the goal of here really is to reduce the number and the severity of incidents in problems on the business itself. And then from a process standpoint, you really involved identifying and resolving problems before those incidences occur, very simple definition.
All right, so as a marker really of adoption and it's kind of interesting based on the poll that we just took about, 80% of the audience had already said that they've already adopted some form of problem management. But if we take to look at the latest HDI report, we can see that of those surveyed, in the latest report from HDI the 2012 survey. About 43% of those responded said that they were actually following some form of ITIL based Problem Management. And then actually looks like the adoption percentage seems to be historically trending about the same you know 46 to 43%, and as we can see based on the actual survey results themselves, problem management still sits in about third position below incident and the change.
All right, so know upon intended here, but really what is the problem? So let's take to look at some of the misperceptions around problem management. What some of the issues are that either to tour us, or stop us really from falling through with the implementing problem management. So problem management is a misunderstood process and really I think the reasons are pretty varied. And a lot of it comes down to either a lack of ITIL or process maturity, even a lack of definition if you will around what problem management really is, or confusing it with incident management, or even blending it into the incident management workflow. And of course you know, when it really comes down to the nuts and bolts here. Sometimes, it really comes down to just a lack of resources, and some would argue that problem management can be the most valuable process within ITIL framework, and really because it comes down to being the cornerstone to help drive a cost down, improve efficiency, and really ultimately improve customer satisfaction. So, next I think it probably makes sense to take a deeper look at what some of the key concepts and functions are around problem management that's we kind of uncover if you will, some of the key benefits. So with that, I'm gonna go ahead and let Diego take it from here, and he is gonna kinda to walk you through some of the key concepts around problem management, Diego?
Diego: Great. Thank you Jim, so let's go ahead and talk about the key concepts here. So there is a recommendations here made by the Gartner, and it really comes down to people, process, and technology. So when we talk about people you know, trying to implement end-user surveys or customer sat, combined with operation metrics will give you insights into how the desk is performing. If you talk about process are be able to formalize the process on how issues as discovered or uncovered within the environment. And then technology, by way of tools and technology of course, put in some diligence around what and how those tools are combined within the help to get the consistent data and at the end, it's all about getting consistent data.
So I do understand that there's a lot of you ahead of the game and have already implemented problem management, but for everyone's benefit on this webinar and that could take a few minutes to talk about the instant, and problem process, and how they are prescribed to be handled. So on this slide, the goal of the benefits of doing is in proper incident management. It pulls down to be able to resolve disruptions as soon as possible, even if it means rap in assistance, or patching things up, or even improvising at the last minute. Key benefits are to be able to reduce the time to resolution, improve on an industry standard called, a first call resolution or FCR for short. Also, the quick resolution expected by the customer and users can be accomplished by optimization based on impact to the business. Don't expect to get it right the first time around though there will always be room for improvements as stated by service improvement process. So now, if you look at the revolving arrow stair, let's go ahead and take it from the top. So having a proper policy or procedures for registering incidents is quite important. As well as having a formal incident way of capturing those incidents, could be a manual process, could be an electronic form, but it's gonna be something that captures that information. And the type of information that you're looking to captured obviously it's categorize those incidents properly via a category, a priority, and impact, and urgency of that particular incident. Then be able to have those new incidents match to related incidents is key there and once you had that be able to have a escalation procedures to be able to facilitate efficiency and resolution in a timely manner. And now obviously the leverage of knowledge base to be able to resolve existent incidents efficiently it's key in this process.
Now, if we go into problem management so a little bit of a change here. So the basic goal is to eliminate the actual disruptions. This could be handled in a reacted matter, and typically to date most of the companies will do it this way. I would say about 80% of companies still work reactively within problem management. The use of some sort of analysis to predict what could be a potential disruption it's always preferred. Now the obvious benefits here are reduction in the incidents, increased speed in which new incidents are resolved, the availability of services that would maximize that, and would stop the fire fight in most companies deal on a day-to-day basis.
So now with problem management, if you look at the revolving arrow sphere, gonna be able to see that you have the five problems of process, policies in place, be able to relate the incidents to problems, be able to identify known errors, have incident data, analyzed and to detect patterns within those incidents coming in, to detect that the recurring types of incidents. Then have resources required to resolution with proper skills to be able to determine what cause of those particular problems and then problems could be eliminated through resolution of root cause. Now that brings us to what the root cause analysis is. So you know, this is just a method of problem-solving that tries to identify the main cause of false, that cause operating events. Root cause analysis or in short RCAs are typically reactive, and it's just a reactive method for identifying issues. The analysis performed after an event could be improved with RCAs but could be also employed as a proactive method to forecast to avoid a causes of events before they even occur. You can see here also that other problem analysis techniques such as the Kepner Tregoe, or the Lean Sigma, or even the use of 5 why's, the 5 why's method, why? Why? Why? Why? As well of the six serving men method could be employed to be able to detect anything in the reactive phase.
So now if we go ahead and talk about the activities of problem management, you can see the problem management interfaces with many areas of IT, Service Desk, and the incident management process are some of those areas. So we have error control, and with error control we cover the process that involves having none errors until they are eliminated by successfully implementing change under the control of a change management process. The objective of error control is to be able to be aware of errors, to monitor those errors, and to eliminate those errors when feasible and it's cost-efficient.
Proactive prevention of those problems is the activity in which you identify the resolving problems before they occurred, and this is the proactive side of things. Use the example of identifying a problem as a sort for rollout on one of your systems going wrong and then prevent the problem occurring in another system by stopping the rollout. So this is something that you can prevent when you do release, a proper release management.
Now some of the major problem reviews are following the resolutions of every major problem. Problem management should complete a major problem review to establish things such as, what was done right? What went wrong? What could be done better next time? Or even how to prevent the problems from recurring?
So now, how do I know I have a problem? And you know, this is a very key because a lot of people still don't get it so, how do you know if you have a problem? After the creation of an incident, you can't match the incident to the problem, knowledge article, or an existing error you could have a potential problem. Or after analyzing the details of an incident and you realize this is an ongoing type of problem, or service desk is not matching the new incidents to an existent problem, knowledge article, or existent error appropriately. You may have a new problem or if after completing that infrastructure analysis, you realize it is a potential for things to break down, then you have the cause for a new problem.
Under the problem activities, we talked about problem control, and as we saw earlier some of the problem activities include that, this is what you do to be able to track and monitor a problem via identification and recording one of it. A proper classification you see that, and then the point in which you entered a full investigation and diagnostic space. After this, be able to resolve and close the problem, and then contrary to incident management, a problem records don't have to be close as soon as possible. So this is a misconception that you will have to have as a lace against problems, you can have a problem open as long as the incidence are close as soon as possible, then you are following the standard.
Under error control activities as I stated earlier, it covers the process involved all of successful correction of non-errors. So the objective is to change IT components to remove non-errors affecting IT infrastructure and enhance preventing any repetition of incidents. I know many IT departments are concerned with error controlled and it really goes and spends both the life of development systems. So error control that works close with change management as well.
And finally out for this kind of activity on the overview of common concepts and functions, we have some outputs. So the results of proper problem management according to ITIL it's an output in the form of request for a change or the RC in short. Also providing feedback regarding the different areas as far as if testing is being done properly, or if there needs to be a change in procedures, or if training is required to change behavior, or if a documentation to improve a knowledge needs to happen, or if you need to have proper training for customers, service personnel. And make sure management helps with ensuring that the problem output can be resolved in better procedures.
So if we go and talk about the ITIL based Problem Management those output items we just talked about most important can you identified high impact recurring events that are causing your organization a lot or in terms of time and money, and that's what problem management will do for the organization. So now what I like to do is talk a little bit about of a problem management and talks it about common pitfalls that could prevent from having a successful problem management procedure. But before I do that, what I'd like to do is, we're gonna have a new poll, so I'm gonna turn it back to Jim in quick, Jim?
Jim: Okay, all right. Thanks Diego. Yeah, so let's open up another poll here quickly. And what we're gonna asks here, really is around some of the key reasons IT departments may find it the difficulty implementing problem management. IT department, service desks, and really kind of, what does it really come down to in terms of your perception, the audience's perception. And really kind of what are some of the things that really impede them from implementing problem management. So we're just take a few seconds here and get a quick Snapshot on what people think here.
All right, this is getting to be pretty interesting in terms of response, in terms of response, so we are actually seeing an interesting split so far with about 40% saying that it's really comes down to people and the majority if not the rest of everyone else responding, saying that it's a people process technology of combination of all three, all of the above but pretty interesting split so far.
Diego: Yes, it is indeed Jim, and that bulls down to the perceived of the notion that you know problem management is really gonna fix everything. So let's go ahead and talk about that, the common pitfalls that we have with problem management. I know this is of I sort type of our slide, but there's a lot of a pitfalls and I tried to put everything into one slide. And you know, we can go on to that for a long time on this one, but let me just highlight some of those common pitfalls that you might encounter when you do problem management: So the first one is lack of proper skills and training. So now, as I stated before, education is about changing behavior. So if we look at learning retention rate studies shown that people you know, when they hear a lecture, they will only retain about 5% of what was explained. And turn, if change that to maybe a discussion group, that will increase to about 50% retention rate. So not just they are doing any type of training but really a concentrate in training that can be retained and improve the skills of the people in the organization, it's something that's never happens so it's one of the pitfalls there.
Then we have the next one which is no adoption. No adoption top to bottom, you know without adoption you can't have great process. So you could design a great procedure but if nobody will uses it, it will be a struggle and at the end is gonna be dropped. So you gotta get the leadership involvement in problem management like we have said before, maybe creating the problem management board. How those are executives get involved, maybe once a week to know what's really going on as far as you know proactive problem management.
Then the next one is no measurement to show improvement. So we talked about our KPIs, KPIs is Key Performance Indicators and most companies don't have that set and these are really to show what type of improvement has been obtained. A Senior Management is to be able to get involved in the process of looking at those values and what's been done to be able to take on the ownership of problem management.
The next one is incident bouncing, and we see that every time. Someone else's problem, right? So when we talk about incident management this is what's happening but you know, problem management it's someone else doing that then I'm not gonna bother. This is really a organizational wide type of a process, not just one individual process. So if there's a quality of service improvement, no way of telling if the loop has been closed. So if nobody understands what problem management is all about, then there's no objectives which is the next bullet point here, no objectives if you don't have specific targets.
Now, constraint by framework imposed, and I know about, you know most of the companies today they are using many tools such as ITILs to be able to run and create process. Well, many times organizations make it too difficult to use external process and techniques from that adapted framework. I could argue that you know, just being a 100% ITIL it doesn't mean that you're gonna be right, there is other process out there that can help you absolutely be proactive as well.
Then we go into a not problem, a reactive problem not under control. And this is key here because a lot of organizations try to start doing that proactive type of analysis. And the truth here is that we found that if you don't have reactive problem management under control you're never gonna be able to go into the proactive analysis side of things. That's because the reactive will always pull you back into the fire fighting mode. And then no problem methodology, not enough why's or we talking about the different ways that you can create different methodologies to be able to get to the root cause of what's going on.
All right, so let's go ahead and talk about some of the key benefits on problem management. And we have improved problem solving skills and resolution. So when we talk about improved skills and resolution, it really comes down to building process to try to get a deeper understanding of all the moving ports. Well that means falling systems, you know tools, applications, or even people, or process for that matter that we saw in the poll before. And as a result become more proactive in mitigating those issues in the future. Another key benefit we talked about improved first call resolution, if you're able to increase that percentage of close incidence on first contact you're moving forwards and be more efficient as a Service Desk. So what's gonna happen here as an improvement, you gotta be able to implement management, a problem management in the best practice to increase the level of knowledge and your knowledge base which of course can leverage by the Service Desk and the self-service tools.
Next, other benefit that we have under problem management, it's improved IT service quality. So if you not detecting that, that you're not doing proper problem management because nothing could be more important than improving the overall services being provided to the business. High quality and reliable services translate to high customer satisfaction and morale of the IT team. And we see that you know, basically, if you don't have a way to check on that via surveys, there is not gonna be a way that measure that quality and service improvement. Also reducing the incident volume to equity impact to Service Desk in a positive matter, because that you know, you try to remove the noise and allowing the Service Desk to focus on more important type of issues.
Lastly, nothing more can be saves regarding the ability to not only resolves issues permanently, but really to really ensure the stay close to not recurring. So in a sense, it really translates into shipping away the issues until you can see the root cause and to permanently fix the issues so that you can no longer impact the business in a negative way. So now, let me give now the floor back to Jim so you can tell us what the ROI and problem management so, Jim?
Jim: All right. Thanks Diego that was great. Hopefully you know, kind of going through those common pitfalls and then kinda translating those to key benefits. You can see how were kind of starting to build the story around, you know how valuable problem management can be you know for you and for the business. So let's take a look at how we can kinda bring all these together and it take everything that we've just kinda learn so far, put it into practice in order to kind of realize this tangible benefits.
So in order to start understanding the benefit, we do need to kind of think and step back, kind at look at where we are, and kind of where we're going. And in saying that, there are a number of key metrics that you wanna keep track of, you know within your system to measure on an ongoing basis. And these are just a few of the recommended problem management reports now that are out there, that will help you to get a clear picture of the overall health of your system. And you know, just a few of these, as in the first one here, number of incidents related to problems. It's important to really start rolling up all the known or related incidents so that you can kind of maintain an audit, really a historical audit of all the customers impacted by you know recurring problems or underlying problems. So then you can actually notify them and then notify them when that actual problem is closed or resolved. Another benefit obviously, not only to just understand you know who is affected but really even narrow that down even further not only from the end-user perspective but also from the service that's been impacted. And there is a number of cost calculation that's you can do there as well.
Number two just kind of pulled out here, a number of workarounds or temporary solutions provided. Is important that you know, the solution, this really kind of tells you that there's still work to be done here. Obviously you've got a temporary workaround in place, but maybe you need to do a little bit more of root cause analysis, due diligence to really kind of uncover what the underlying cause of that reoccuring problem is, so it kind of leads you in the direction that yes there's more work to be done and hopefully you know you can resource that accordingly.
Another one here kind of that jumps out of me is the number of RFC or Request for Changes that are in the system, really that have been issued to help provide the clear picture of the progression of how you're moving through the problem management last like a process, and really getting into a lower or reduced number of recurring problems. So hopefully you're kind of evolving if you will going from reactive to proactive problem management and actually taking steps, the next step if you will and actually fixing or resolving that issue through a change.
All right, so now let's go ahead and take a quick look at some areas that we see for potential savings and how they can actually be realized. And first we want to talk about recurring incidents and avoidance, and how this can really be realized by building a team and this could be a dedicated team, an ad hoc team, really to start looking at those recurring issues and trends over time. And get a deeper understanding and analysis of those issues, and as a result then team can make the recommendations to fix the root cause and hopefully put a stop to really the reoccurring system solve and and of course that's gonna you know, really come down to resources and of course everyone is trying to do more with less and that could be one person, that could be many people, that's why I say it could be a dedicated team or an ad hoc team depending on you know the services that are actually impacted.
We can then take a look at the incident handling and time reduction here of incident handling. And this really comes down to people process and technology where you really need to look at the integrated process to see some workflow to help automate some of the call handling, and reporting, and resolution task for that matter. So you know it does come down to people and process but there's a technology component here, that if you can automate some of these, and again automated you know based upon best practices obviously then you really gonna start seeing some potential savings here. You know everyone wants to focus on tools but it really again comes down to people and process are just as important.
Outbound calls avoidance. You should see a distinct reduction in the number of outbound calls as a result of the first call resolution as Diego it pointed out. This is critically important because you know, the last time that you have the service does actually making those outbound calls and you know either updating status, communicating with customers, the more time and money you're gonna save in the end, and of course it does kind of come down again to people, process, and technology.
Let's see. One other thing here around a first call resolution and improvement here is also that you know I mentioned taking time away from the Service Desk. One thing that you want to be able to do obviously is leverage the Service Desk, and leverage your expertise. And again, coming back to the people part of it, finding those teams that can help you actually start unlocking and uncovering and doing the due diligence around root cause, this actually place it a critical part on that as well.
Savings are based upon business interruptions and avoidance. This is the big ticket item, no one wants to talk about or no one wants to see you know outages in the system. And it trully can be realized by reducing the number of interruptions and outages. And so, doing the proper due diligence and root cause maintains the high-level performance, really you know, not only for the Service Desk but obviously for the business and to meet their business need and requirements as well. So critically important, and this is the big ticket item in terms of cost, and we're gonna talk about that in just a moment.
All right, so, now that we kind of looked at really kind of what the savings potentials are and how they realize we want to talk about some of the baseline metrics. And again, these are your typical kind of resourcing metrics that you'll wanna have in hand as you start to kind of look at calculating hard costs if you will around ROI and problem management. So you may or may not have some of these actual numbers and if not you can obviously, you can find industry averages either on online resources and/or you can make some assumptions on your part. And these are just some example numbers here but of course some of the salary costs here are gonna be driven you know, based on your service staff, and the areas that you live in, all of that combined. So one of the key elements that we need to know really comes down to FTE and really the labor cost here, the low to great on what that cost is, and whatever this number is you'll need to be able to translate that number into a salary or dollars per minute. And the reason for that is, most if not all the calculations are gonna be done by a time savings and that actually translates into minutes and dollars, and so you have to do those calculations as well. We'll also need to know the total incident volume and number of outages and again, this can be approximations in the beginning to kind of help you with the ballpark ROI number, until you actually have those actual. And then you'll also need to look at you know outages it's the company experiencing those outages, are they small? Are they medium? Are they large? And really to try to associate and understand how long those outages are in terms of duration and that will actually help really in terms of the calculations that they will see in just a few minutes on how they actually get at ROI number.
All right, so let's go ahead and take a look at some of the key areas for savings and really how you can begin to calculate ROI. So when we look at metrics, what we need, the metrics that we need in order to really calculate the reoccurring incident avoidances. You can see that we either need to know or make some assumption as to what the percentages of these outages were related to some of the recurring problems. And again, going back to the reporting, really kind of helping you know unlock some of those numbers. The reporting is gonna be very important here to establish a baseline from where you start. Again, it's important to have those numbers but and again, in the beginning obviously you can have, you know, you can make your assumptions and really try to derive actual and really actual to your business over time. So from that point, you can determine you know what the total number of incidents avoided really come down to in some, this particular case, the percent of business outages related to recurring problems. From a reporting standpoint we're already seeing that's at 25%, and then the total number of system outages is about 19, and then we can actually drill that down and look at what the actual average number of requests where, as a result of that problem or outage. And then drive that down even further and look at the actual reduction in terms of a percentage, and then we get a hard number here that we can then actually calculate so, 234 level one incidents avoided translate to you know a little over $2,000 in annual savings. So you know, it may not seem like a lot, but again these are kind of fair or I would say average or conservative estimates in terms of managing your problem management processes. And I would guess to say that you know once you've actually implemented these problem management best practices that you will probably see a higher percentage in terms of rate of return.
All right, so when we look at the reducing you know incident handling time or really trying to understand the time it takes to track down those known problems, identify them, and then you know again linked those related incidents because that's an important. And when we look at the time spent handling incidents on problems, you can see that we're looking for a few key items here first again, at the top here starting at the starting point here. Total number of incidents in the system again on an annual basis and then we look at what the percentage of those are related to known problems, their time spent in this particular case identifying a solution. And then we get that roll up of total time spent again, these numbers can be estimates but when then you start looking at expectations in terms of reduction or percentage you can see how the translates to overall time savings. Again going back to the FTE salary rate in minutes, and doing a calculation here on time spent per incident and incident avoidance which translates in this particular case to a cost savings of over, just over $3,000. And again, you know these are just estimates and you know your numbers are going to be completely different. But again it does give you some idea if we're actually reducing the number of those time spent on handling those calls, handling those incidents, you can start seeing with the actual true return on investment is.
Okay, so in terms of outbound call avoidance, this really comes down to understanding the total number of service incidence you know in the system. Again, kind of, at the starting point and when you look at the incident volume related to active incidents, you know again back to the reporting which is so, so important here. That you know, your estimate is or your lists from a reporting standpoint comes back and tells you that at least 25% of those are due to act of incidents or related to act of incidents which translates to about 15,000 as a hard number. And then you look at the total percentage in terms of reduction that you would expect. You can then start saying, okay, well that actually translates to about a hard number, about 850 total with a total annual savings of about $8,500. So again, kind of you know working your way down here in terms of the packing order, you can see how we actually derive from the pop level number, total incident volume, again going back to your reporting. And then understanding how many of those are actually related to reoccurring incidents to get down to a bottom line number here of $8,500.
Now historical analysis, in this particular case we are talking about business service interruption and avoiding those obviously these are key to the business, this is the big ticket item. This requires a lot of work you know, a lot of diligence, process. I mean this really comes down to all of three components to your people, process, and technology to try to get to this point. But the historical analysis over time would tell you that you know, you have a number of outages every year. And again hopefully you're capturing that within the Service Desk and the reporting that we talked about, and then making those assumptions again around whether or not these were in scale large, medium, and small. And giving them some duration whether they were 30 minutes in duration, 45, 30, whatever the case may be. And then you know, calculating that to an overall down time. And again making some assumptions in terms of what that actual duration is, and what the cost is, this actually will translate to literally about $25,000 and then again, you know looking at the roll up of the three previous ROI calculations that we're doing. I mean the roll up here, you can see within one annual year that this actually translates to a little over $50,000 in savings.
So you know, just to kind of take a look at in levels set that what we just talked about. You know we're talking about incident volume reduction here, where problem management is instrumental and reducing the number of incidents that in interrupt and interrupt the business. And that really translates it to have a little over $2,000 in savings, you know better fix time rates at the Service Desk and incident handling that translates to about $3,000, outbound call avoidance $8,500. You can see here that this is a pretty big number, and if you would add this up over a 3 year time period you know, calculating ROI over time you can see here that the you know the overall savings here could actually roll up to little under $100,000 within a year based upon the conservative as they met in terms of reduction, and percentage of reductions that we were really talking about previously. So again, very tangible ROI numbers here that you can actually pull together, and again a lot of it is derived from the reporting that you're hopefully doing, and also the best practices and kind of pulling all those things together to really kind of get down to a hard number. And I know that this is a very difficult thing to do at times, to pull in all this information, but again very important in terms of overall calculation and really driving benefits, tangible benefits from implementing problem management.
Now, that being said, in the end, in the end don't disregard customer satisfaction because there are some in tangible benefits here obviously. I think Diego spoke about them as well but you know, don't disregard customer satisfaction as a key driver around problem management and although it may be difficult to put a financial number, again customer sat, it can really play a significant role in the overall ROI and performance of the Service Desk. So all I can really say here is, if you have the ability to survey, I say survey, survey, survey to find out really understand you know what is happening to your customers and you know their business impact and bring that back in to the Service Desk to really start understanding not only the hard tangible cause but also the intangible benefit of customer satisfaction.
Okay, so in summary just a few key takeaways here, you know I think we've come into the end here. But few key takeaways here, it really comes down you know, as with most functional processes it comes down to people process and technology. I know a lot of you out there in terms of just who voted, really we're concerned about people, I agree with that, I agree. But all I can say is take the little steps to bring people into the process and utilize technology to support the entire problem management process. And take the necessary steps again, to measure, to identify, analyze, asses the ROI, and again not having hard numbers, you may not have all the numbers for the business but make some assumptions and you know find out, you know what the industry averages are that you can use to help implement and communicate ROI. And then obviously, you'll be successful in realizing true tangible benefits of ROI and a problem management in general.
So with that, I think Diego, I think we're actually coming to the end of the session here. And we're just gonna spend a few minutes here at the end so we'll answer a few questions that you may have. So we'll go ahead and take those questions now. And Diego I think there's a question here probably best suited for you and that is, what's the difference between reactive and proactive problem management?
Diego: Well, Jim yeah, we could definitely take another webinar just on that specific subject but let me just bullet down to a couple of bullet points. So I would say, you know on the reactive side the incident occurs and they are resolved. A problem management takes over and then they conduct an RCA. Okay, so when you see RCA it's more relevant to reactive mode. Problem management techniques such as you know, Tregoe, Fishbone, the things ones that we've mentioned are utilized. And the remediation activities track the activities to completion. When you talk about a proactive problem management, you're identifying trends and patterns and you're utilizing your data. So data quality is critical when you do a proactive management. On a reactive side, you close the problems very quick on the proactive side that remain open. So I would say the major differences are the, you know on the reactive investigation is usually just one root cause, on the proactive side you can have multiple causes. On the reactive investigation you can measure that in days, on the proactive investigation you can measure that in weeks, or even months. And then reactive goals could be just to eliminate that particular recurrence, on proactive goals are significantly reduce the recurrence of incidents, Jim?
Jim: Excellent. Okay, all right. Just another question here coming in, I'll answer this very quickly. You know where can I get the industry averages or some of the numbers that you're showing? That was actually pulled from the latest HDI report, I'm not sure if I mentioned that, I thought I did. But anyway, yeah if you have any questions regarding you know salaries, or averages things like that, that you know you may not be comfortable getting from the business, you can go ahead and use that report if you will for your actual reporting purposes so, and find that at HDI.
Let's see there's another question here, what are some of the key implementation criteria for problem management? And Diego, I'm gonna go ahead and let you answer that question.
Diego: Sure. So the key implementation criteria, I would say active senior management support. If you don't have their support there must what than even start problem management. You would get to have expected results clearly defined and understood by everyone. You gotta have a two stage cap of implementation, cord and then the others. So don't try to you know ball the ocean type of approach. A great performance system for everyone involved and the resolved oriented role models, you know sometimes it's important to understand the key is that, is not someone else's problem, it's everyone's problem. Information systems support use of new skills is important and have specific set of right skills performing the problem management role.
Jim: Okay. Okay, sorry to interrupt there. Yeah Diego, that was great. There is a number of questions in here that we're gonna have to get to, and unfortunately we're coming to the end of the session here, they're, let's kick this out and we're gonna finish the session. But I would like to thank everyone today for participating, for listening to the session and hopefully it's been beneficial. If you have any more questions you can obviously find us at FrontRange at www.frontrange.com for more information and as I mentioned we will try to get to your questions outside of this particular session, there was some great questions that we wanna get to. Again, we really appreciate the time today and look forward to speaking to you in the future and with that I would say thank you on behalf of Diego, and myself, and hope to talk to you soon. Thanks.