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 Dell.

1. 1

2. BJ – KCS Workflow and Security Architecture
2

3. 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.
3

4. 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…
4

5. 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!
5

6. 6

7. 7

8. 8

9. 9

10. 10