|
|
|
08/22/2011 03:20 PM
|
|
|
Hi all,
Apologies in advance for the long post but I thought I would provide sufficient information so as to ensure the community understands my situation.
Lean has been instigated and gaining momentum in our manufacturing company for a number of years but now the focus is shifting from the shop floor to the support functions and how the principles apply there.
I work in the IT department where at present our work largely falls into three categories
1. provide support everyday hardware and software support (helpdesk environment). 2. enhance and integrate current systems (2-20days development) and 3. Design and/or implement large IT systems.
Traditionally we measure around Service Level Agreements (SLAs) for the help desk type work and 'delivery to schedule' for development activities. We don't measure it but our management is keen to ensure high utilisation of resources, thinking this will improve our productivity. I am keen to try and change the mindset and the analogy I like is that of a relay team 'focus on the baton, not on the runners'.
Has the community any advice on KPIs, as these definitely drive our behaviours? I like the idea of cycle time or of Value Time/Lead time ratios but every job we do is different and hence any improvement we see on a month by month basis may be down to natural variation in demand. Regarding the helpdesk calls I also like the systems approach of trying to focus the reduction of calls rather than answering them within a certain time as almost all of these calls are some sort of waste. Maybe we shouldn't even try to get KPIs at this stage?
Your help and advice is appreciated.
|
|
|
|
|
08/22/2011 08:01 PM
|
|
|
Conor,
I hope he doesn't mind, but to quote John Shook, there are 2 measurements that matter: Performance to Purpose and Performance to Plan. I'd also like to add that measurements are critical in defining and solving specific problems - but those should come and go as necessary.
Since being efficient or having fast cycle times is never an organization's purpose, I would start by defining the purpose of the IT department from your customers' perspectives. What do they value and how do you provide it? I really like where you are headed with reducing the need for helpdesk calls. As an IT customer, I value a system that works so well that I don't need any help. Fast turnaround is nice if I do have to call someone, but if everyone is only focused on reducing the cycle time, then nobody is trying to solve the root cause of why calls are necessary to begin with. Once you figure out what the true customer value is (or should be), then you can worry about how to measure its delivery.
And finally, don't measure things that you aren't willing or able to change. That's just waste with all sorts of behavioral / cultural ramifications.
Brent
|
|
|
|
|
08/23/2011 05:41 PM
|
|
|
Brent,
Where did you get this quote from John Shook and is there more information on this topic available? We are currently in a similar exercise in our company on what measures to define.
Regards,
Dirk.
|
|
|
|
|
08/26/2011 03:33 PM
|
|
|
Dirk,
I have never seen it documented or any more information about it, but it could exist somewhere that I'm not aware of. It was relayed to me by two LEI Faculty members who were in a workshop with John. It was his response to a question about "which metrics matter?"
I use it all the time in workshops and it works very well for getting people to think at a higher level about the process and what it really is supposed to accomplish (purpose). People get so buried in the details sometimes that they cannot see beyond process steps. Hopefully each process purpose somehow supports a higher level purpose of the organization - similar to strategy deployment. The plan part can be in-process quality, a daily production schedule, a project plan, or even the implementation of a corporate strategy. That all ties into whatever PDCA cadence / process we are using.
Regards,
Brent
|
|
|
|
|
08/26/2011 03:36 PM
|
|
|
Preview Message
Dirk,
I have never seen any documentation on this thinking. The story was relayed to me by some LEI Faculty members who were in a workshop with John several years ago. Someone taking the workshop asked what measurements matter and that was John's reply. I don't know anymore details, but have used it many times in my own workshops and it always works very well. Groups get stuck in only making incremental improvements to their current states and this helps them think bigger picture before diving back down into specific problems. I would be more than happy to chat with you about it or answer any questions.
Regards, Brent
|
|
|
|
|
08/26/2011 03:36 PM
|
|
|
I run an aircraft overhaul operation and IT really has an affect on our production (positive or negative). My recommendation is that IT performance be tied to overall productivity. For example, we watch log on times for our mechanics. We want to drive down log on times and eliminate delays on the production floor. May seem like a small contribution but when you add it all up, it makes a difference. So my advice is tie your performance in IT directly to the companies output. Of note, it may be that the IT department productivity may even be worse but overall contribution to total productivity may be improved.
|
|
|
|
|
08/26/2011 03:37 PM
|
|
|
Hello,
Great questions Connor and I agree with what you've said Brent. If I may emphasize a point which you touched on Brent, and that is, Quality.
I have found by being both a customer and supplier of IT that Quality is what people/users appreciate the most. Often, within IT, we are focussed on what we know best - IT - however those whom we support are not experts at what makes their computers work (or not work) and as such are expecting their computer to "just work" - which, in my opinion, is how users view Quailtiy of IT.
In creating IT metrics for previous employers I looked at measuring our service level to the SLA's. I have found that a number of companies view an SLA as something they have to agree to as opposed to something they strive for. Within IT we used OLA (Operational Level Agreements) which are internal agreements and helped us distinguish between external agreements - SLA's.
I also created pareto charts to capture which services had the most incidents and problems and focussed on the top ones to investigate why they had the most incidents and/or problems.
Thirdly we started to standardize our work within IT by using a common language - ITIL. This reduced considerable confusion within the IT department as well as put excellent focus on solving the problem as opposed to "band-aiding" a fix that would only cause another symptom to occur in the future. I would reference ITIL v3 as well as ISO/IEC 20000 for more information.
Kind Regards,
Douglas
|
|
|
|
|
08/30/2011 10:32 AM
|
|
|
Hello Connor,
there are several steps we have taken in our company to develop the service desk metrics
A/ the metrics we have defined specifically for service desk are
1/ Contact volume (contact = call, mail, ticket, i.e. anything that conveys the value (i.e. password reset) to the customer, be careful about "double counting", under certain circumstances in dependency how granular report you require, you do not want to measure a call and subsequently created ticket as 2 events)
2/ Average Call Resolution time (including hold time and after-call work time)
3/ First Time Fix (ratio of contact resolved during "first touch" (= not transfered outside of the pool) divided by total amount of contacts
4/ Contacts per Productive Hour (productive hour is an hour worked, education, illness, etc are naturally excluded. I found this metric very useful as it gives you interesting point of view at your pools/team's productivity. For instance - if you guys have "only" 2 contacts per productive hour, it is telling you -as a manager - that your guys are either not utilized or you have a wrong contact reporting in place and are losing money (of course, it depends on the definition of a contact)
B/ All of these metrics are by default
1/ collected on so called pool level, however, if your subactivities are significantly different, merging them into one bucket could "hide" data.
2/ analyzed through Shewart's process analysis (we have a limited amount of identifiable signals/exceptional variations compared to e.g. Nelson's rules)
As far as your approach to call reduction, I very much agree with the poka-yoke approach - as a matter of fact, a satisfied customer is a customer without an incident. We are trying to reduce "unnecessary contacts" through education of the customer and/or automation. Depending on your contract with the customer, applying such changes can be difficult as it usually bears additional cost with it. At the end when you prevent an incident, we find it essential to share a particular pool's results with other pools to share the best practice.
|
|
|
|
|
08/30/2011 04:13 PM
|
|
|
Jan, that is a very good list. I would add that resolution time and first-time resolution are very good balancing metrics: we do not want to hand off the contact, particularly if that is not a warm transfer: information and context is lost, and the customer feels the inconvenience of a second contact, plus wait time But, technical people will plug away at a problem for as long as you give them--they are generally curious by nature. You will find a balance between the two, and can adjust them together. (and understand that adjusting one will change the other)
I would also add contacts / customer. If you have data to segregate your customers by location, by function, etc. then looking at this metric across populations can help you to quickly focus on customer satisfaction trends beyond the individual call.
|
|
|
|
>
Community >
Forums
Send to a Friend
