Monday February 28, 2005
Individual Program Leaders for Sun Global Resolution Troubleshooting occasionally tie-up with Program Leaders in other companies. Recently two colleagues of mine were invited to the offices of Cisco in San Francisco to talk about the challenges of instituting this in their company. Sadly I wasn't there (I had planned to attend and something else got in the way), and I heard from my colleagues that the Cisco Program Leaders were particularly interested in the process improvement feedback loop we're using in Sun. One day I hope to meet you, until then, this is a drawing of the basic operation of one of the feedback loops we use.
In the call flow there are people who are generating work for other people. In this model I'm calling the people who are generating work “Escalation Generators” and the handlers of that work “Escalation handlers” Bear in mind that escalation handlers can also be escalation generators if they then pass work to others. Every day we get a dump out of the case management system of all the transfer of work movements between one group of people and another. A Process Caoch (either a Program Leader of a Process Facilitator) is associated with a group of engineers. This can be the staff the Program Leader has they themselves trained – it provides continuity following the training course.
A batch program associates all the work from the generators with their respective process coach, and creates a personalised html form for the coach, making it easy for the coach to visit the work of their coaching group.
The coach visits the html form, takes a look at the quality of the documentation and finds coachable moments, both “well done”, or “could do better”.
There are two stages to the coaching – the first stage is getting the end users to recognise when they should use a part of KT's process, we call this the “triggers for use” and once we see individuals using a process to document the work we are looking for “Good use of Process”. Program Leaders should be able to recognise Good Use of Process when they see it – if not KT have a definition you can recycle.
Feedback or consequences are provided to the individuals one to one, either by email, a phone call or in person.
Typical emails that we send are:
|
Poor quality from the escalation generator It is perfectly reasonable to ask the escalation generator for a problem statement and specification on this escalation if it would assist you in the resolution of the problem. The escalating engineer has been trained, and should provide you with a specification. Ensure you have cycled this escalation through "Received Incomplete"at some point in it's life to alert Management to the lower than expected quality of the documentation. |
|---|
|
A specification from the escalation generator when it was not necessary Thank you for providing the problem statement and specification on the above escalation. The provision of a clear description of the problem in a standard format is very helpful in the speedy understanding of a customer problem, and overall will result in a shorter time to resolution, more chance of a first time fix and more satisfied customers. Please note that there are certain escalation types that do not mandate an SGR specification. For all cases where you know the cause of the problem;
you do not need to also provide a specification. It's fine to do so, but it is not necessary. For further details see .... (url for further details) |
|
A good specification from the escalation generator Thank you for providing the problem statement and specification on the above escalation. The provision of a clear description of the problem in a standard format is very helpful in the speedy understanding of a customer problem, and overall will result in a shorter time to resolution, more chance of a first time fix and more satisfied customers. |
|
A specification that had coachable moments. Hand crafted by process experts every time. |
Once the reports are completed by the coaches they are archived (in a mail archive as it happens).
We can the do data mining and compare the performance of cases where good quality documentation wes provided compared with not such good quality documentation.
Posted by Rick Santina on March 09, 2005 at 08:16 AM GMT #
Posted by Steve White on March 14, 2005 at 08:20 PM GMT #
Posted by dsaf on January 22, 2006 at 03:28 PM GMT #
Posted by 赵军 on March 24, 2006 at 04:08 AM GMT #
Posted by 姨太太眼 on March 30, 2006 at 01:47 PM BST #
Posted by 虚拟主机 on June 23, 2006 at 02:28 AM BST #
Posted by sd on June 30, 2006 at 02:01 AM BST #
Posted by rewrew on July 10, 2006 at 02:04 AM BST #
Posted by erwe on July 16, 2006 at 08:59 AM BST #
Posted by ewr on August 02, 2006 at 08:27 AM BST #
Posted by wrwerew on August 08, 2006 at 07:20 AM BST #
Posted by wr2 on August 21, 2006 at 09:38 AM BST #
Posted by rwerwer on September 29, 2006 at 09:00 AM BST #
Posted by fdasfdsa on October 13, 2006 at 03:22 AM BST #
Posted by fdadsfdas on October 16, 2006 at 05:43 AM BST #