KCS Consortium Presentation: Success & Challenges with Dell's Global Knowledge Centered Support (KCS) Programs
•Download as PPT, PDF•
2 likes•1,185 views
This is a presentation delivered to the Consortium for Service Innovation during a workshop held in September of 2007 in Dallas, TX with ATG (now Oracle). It highlighted the early successes and challenges encountered by the early adopters in Application Support & Services while implementing Knowledge Centered Support (KCS) and the lessons learned and shared as adoption of KCS grew throughout other internal organizations at Dell. Download the PowerPoint file and you'll also get the slide notes I used during this presentation, which offers some additional explanation & background info on the main points of each slide.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (15)
Recently uploaded
Recently uploaded (20)
KCS Consortium Presentation: Success & Challenges with Dell's Global Knowledge Centered Support (KCS) Programs
- 1. Knowledge Centered Support Lessons Learned from Application Support 09/10/2007
- 2. Introductions • Bryan “BJ” Hoffpauir – SCADA / Factory Automation Application Manager & Knowledge System Architect 2 Information Technology
- 3. Management Perspectives • Performance Metrics Alignment – Management and IC’s must BOTH incorporate KM metrics for success • Create the Right Incentives – Don’t encourage bad behavior • Adapt Metrics as Rollout Progresses – Metrics you use in the beginning of rollout will need to be modified over time. • Set & Manage Expectations – KCS isn’t something you can “turn on” and expect success. 3 Information Technology
- 4. Training & Change Management • Planning for Success – Bring in stakeholders early to discuss how KCS will affect all user groups. • Technical Change Management – Identifying integration opportunities with relevant IT Systems • Process Change Management – Communication essential to preventing Fear, Uncertainty, and Doubt • Training & Coaching – Start with Basic Usage Training, but must evolve. Coaches must be trusted and have respect of knowledge workers. 4 Information Technology
- 5. Workflow & Security Architecture • Developed New Philosophy towards knowledge & KM • Workflow Design - should enable that articles are technically accurate, findable, and re-usable. • Security Planning – Develop a Flexible model that can change over time. Take into account natural tendencies to hoard and silo knowledge. 5 Information Technology
- 6. KCS Results • 14% Increase in customer satisfaction • 32% Increase first ticket close rate • 36% tickets deflected to web • 44% Increase in employee satisfaction • 52% Decreased handle time (SA) • 60% Decreased problem escalations • 66% Decreased new hire training time • 85% Reduced average response time 6 Information Technology
- 7. Dell Results – Cimplicity Incident Counts Cimplicity Sev 1 & 2 Incidents Time to Service Available 3:21:36 2:52:48 2:24:00 1:55:12 1:26:24 0:57:36 0:28:48 0:00:00 Q3 FY06 Q4 FY06 Q1 FY07 Q2 FY07 Q3 FY07 Cimplicity 2:00:19 1:28:45 1:28:36 1:01:32 0:46:41 Other Source 2:56:39 2:15:05 2:08:03 1:54:29 1:45:56 Overall 2:28:29 1:51:55 1:48:19 1:28:00 1:16:18 Cimplicity Other Source Overall 7 Information Technology
- 8. Dell Results – Cimplicity SA Metrics Cimplicity Sev 1 & 2 Incident Count 160 140 120 100 80 60 40 20 0 Q3 FY06 Q4 FY06 Q1 FY07 Q2 FY07 Q3 FY07 Other Source 81 59 57 40 44 Cimplicity 75 9 25 16 15 Cimplicity Other Source 8 Information Technology
- 9. Dell Results – Cimplicity GSC Metrics % Of Tickets Resolved by GSC Cimplicity Support 70.00% 60.00% 50.00% 40.00% 30.00% 20.00% 10.00% 0.00% Feb Mar April May June July Aug Sept Oct 9 Information Technology
- 10. Questions & Answers 10 Information Technology
Editor's Notes
- BJ – KCS Workflow and Security Architecture
- Alignment – For true success, need top-level buy-in from Directors. They must hold Sr. Managers accountable for driving the organizational behavior changes needed for KCS to succeed. Incentives – Focusing too much on daily KCS activity metrics (like views or re-use) can encourage gaming the system. IC’s need to know that they will be evaluated on these things, but the MOST important metrics at the end of the day are the Service Level Metrics. Time To Service Available, Time to WIP, etc… Adapt – We started initially measuring solution views, then progressed to usage & re-use. We’ve adapted to allow Remedy & KCS Combined Metrics Expectations – Especially true for Sr. Management. We’re talking about organizational process & behavior changes. These take a while to set in and individuals on teams will mature at different rates. Need to emphasize that we’re investing in a long-term strategy for success.
- Planning – Forming a Core Team with representatives from different segments allows discussion of challenges and sharing of concerns Technical Change Management – For us, analysts work through Remedy – had to integrate. Initial efforts weren’t all that great – we required a tune-up phase where we really had to work with end-user to find out the best way to integrate with the Way They Worked. Process Change Management – Many Employees fear change. Management must work diligently to communicate why the new KCS processes are being implemented. Many will fear job loss / downsizing. Some team members may not be suited for new role as Knowledge Steward – need to understand that not all support staff will want to change. Training & Coaching – We started with one-size fits all training. We’re adapting as that isn’t successful across all teams. Dev Teams have certain needs, Coaches need advanced training, etc…
- Philosophy – Initially we were consumers of knowledge. Dev gave us info and we used it and learned on our own. All participants have knowledge to contribute (and MUST contribute for true organizational growth) Should default to sharing knowledge Workflow – Initial design was great for producing initial versions. Making sure they were finable was a challenge. Had to use coaches to ingrain the process of continuously updating solutions as BP’s reported them differently. Searchability needed additional focus (partly due to challenges with initial Remedy Integration) Also, initially, we put the responsibility of ensuring technical accuracy across all analysts & shared with Dev Team. We’re moving to a model where we have one group accountable for knowledge in App Spaces – the application owners. We think this is essential to ensuring long-term accuracy. Adding responsibilities will get you started, but need something more robust for long term. Security – All groups want the same thing – access to other’s knowledge and to lock down their own. We’re used to economics of scarcity, but knowledge doesn’t have the same characteristics of physical goods – the more it’s shared, the more value it has. Some groups will want to really segment themselves out, avoid this if possible!