with Proactive Knowledge Management

lapclassΔιαχείριση

6 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

144 εμφανίσεις

Session 803:

Augmenting Knowledge
-
Centered Support
with Proactive Knowledge Management

Augmenting Knowledge
-
Centered Support with
Proactive Knowledge Management

Copyright © 2011 HDI
-

All Rights Reserved.

2


Rick Joslin

HDI

Executive Director,
Certification & Training

The History of KCS

Proprietor: Consortium for Service Innovation


Non
-
profit alliance of customer service organizations
focused on innovative ideas through collective thinking
and experience


Board of Directors have included support executives from
Cisco, HP, Microsoft, Novell, and Oracle.


KCS principles have evolved from work that began in 1992


Originated with a simple premise: to capture, structure,
and reuse knowledge


Evangelizer: HDI


CSI partnered with HDI in 2003

the world's largest
membership association for the service and support industry


Made knowledge management
best practices
available through
certification and training

Copyright © 2011 HDI
-

All Rights Reserved.

3

Knowledge
-
Centered Support (KCS
SM
) Practices

Copyright © 2011 HDI
-

All Rights Reserved.

4

Knowledge

Articles

Capture

Structure

Reuse

Improve

Solve

Leadership &
Communications

Performance

Assessment

Process
Integration

Content

Health

Evolve

KCS is a service mark of the Consortium for Service Innovation

Knowledge Management

Copyright © 2011 HDI
-

All Rights Reserved.

5

Your
Knowledge
Base

Incident
Management

Request
Fulfillment

Event
Management

Problem
Management

Release and
Deployment
Management

Reactive

Proactive

Reactive Knowledge Management


Promotes capturing an article at the time it is
created and making the article available for
reuse


An article is created in response to a problem
already occurring

and being reported

to the support

center.


Copyright © 2011 HDI
-

All Rights Reserved.

6

Integrating Knowledge into Incident Management

Copyright © 2011 HDI
-

All Rights Reserved.

7

Create Incident

Search KB

Solution Found?

Solution Correct?

USE IT

Close Incident

Research or

Escalate

FLAG IT / FIX IT

ADD IT

Yes

Yes

No

No

Solve It

Release & Deployment Management


Building knowledge prior to its need


Useful when a depth of knowledge is needed


Forecast potential questions and problems before
they occur and build a knowledge base of
answers and resolutions in advance

Think “IT Service Continuity Management”


Invest now, just in case


Minimize impact if it occurs


An insurance policy

Copyright © 2011 HDI
-

All Rights Reserved.

8

Leverage Your KCS Practices

Building new knowledge
articles using:


Content Standard


Style Guide


Knowledge Templates


Quality Criteria


Knowledge Monitoring


KCS Competency Model


Use Reactive Knowledge
Management processes to
enhance knowledge articles
built through Proactive
Knowledge Management

Copyright © 2011 HDI
-

All Rights Reserved.

9

Remember the Audience

Copyright © 2011 HDI
-

All Rights Reserved.

10

How does it differ?

Proactive

Just in Case

IT Context

Developers, Knowledge
Engineers, SMEs,

Tech Writers

Validated

Published

Reactive

Just in Time

Customer Context

Support Center Analysts,

Level 2 and Level 3
Support Technicians

Experience

Real time

Copyright © 2011 HDI
-

All Rights Reserved.

11

Reactive & Proactive Knowledge Management

Copyright © 2011 HDI
-

All Rights Reserved.

12

Quality


High Quality


Reusable


Manageable


Low cost of ownership


Immediately Accessible


Flexible



Release & Deployment Management

Design


Forecast and research

Develop


Test the accuracy of the solutions

validation


Enlist a knowledge engineer

Deliver


Knowledge base is ready to be coordinated
with the release of a new product or service

Copyright © 2011 HDI
-

All Rights Reserved.

13

Error Messages

Capture in the development process

Copyright © 2011 HDI
-

All Rights Reserved.

14

Help Files and Manuals

Copyright © 2011 HDI
-

All Rights Reserved.

15

Forecast Common Problems

Consider all of the possible problems which can
occur which result in a
call

to the support center.

Focus on the 80/20 rule.

What 20% of problems

generate 80% of your calls?

How can we identify these?





Copyright © 2011 HDI
-

All Rights Reserved.

16

Historical Records


Research the impact of
previous versions and
previous projects


Analyze incident records


Evaluate usage of
existing knowledge


Copyright © 2011 HDI
-

All Rights Reserved.

17

Quality Assurance Testing

BUGS


Known Problems


Known Errors


UI Issues


Confusing Tasks


Unexpected Results

Copyright © 2011 HDI
-

All Rights Reserved.

18

What Knowledge to Include?

Copyright © 2011 HDI
-

All Rights Reserved.

19

Define the Scope of Your Knowledge Base

Copyright © 2011 HDI
-

All Rights Reserved.

20

Sample Knowledge Engineering Workflow

Copyright © 2011 HDI
-

All Rights Reserved.

21


Submit
Articles


Validate
Article


Create Best
Resolution


Classify Problems


Edit for Audience


Proof Read


Publish the
Knowledge

Developer

SME

Tech Writer

Publisher

Proactive Problem Management


Enhancing knowledge
based on analysis


High reuse articles


High impact problems


Building knowledge
based on analysis


Diagnostics for problems with similar symptoms


Gaps identified in self
-
service usage

Copyright © 2011 HDI
-

All Rights Reserved.

22

High Reuse or High Impact

1.
Identify Root Cause


Change from Problem to Known Error


Update the Knowledge Base


Include steps to validate the cause

2.
Identify Best Workaround


Update the Knowledge Base

3.
Identify Permanent Fix


Submit Change Request


Update the Knowledge Base


Copyright © 2011 HDI
-

All Rights Reserved.

23

Engineer Diagnostics

Copyright © 2011 HDI
-

All Rights Reserved.

24

T h e s e r v e r d o e s n o t
h a v e a D N S e n t r y
C a n t h e s e r v e r b e
a c c e s s e d w i t h t h e n a m e
e n t e r e d c o r r e c t l y?
M i s s p e l l e d o r i n c o r r e c t
s e r v e r n a m e.
C a n o t h e r W W W
s i t e s b e a c c e s s e d?
I s t h e P C r u n n i n g t h e
b r o w s e r d i r e c t l y c o n n e c t e d t o
t h e I n t e r n e t?
C a n t h e W W W s i t e
e v e n t u a l l y b e a c c e s s e d
a f t e r s e v e r a l r e p e a t
a t t e m p t s?
T h e n e t w o r k o r t h e s e r v e r w a s t o o
b u s y, o r t h e W W W s e r v e r w a s d o w n
t e m p o r a r i l y.
I s t h e m o d e m c o n n e c t i o n
f u n c t i o n i n g p r o p e r l y?
D o e s t h e u s e r h a v e
p r o p e r f i r e w a l l
a u t h o r i z a t i o n?
D o e s t h e n e t w o r k u s e N I S
n a m e m a p p i n g i n s t e a d o f
D N S?
N o p r o p e r f i r e w a l l
a u t h o r i z a t i o n t o a c c e s s t h e
e x t e r n a l W W W s e r v e r.
B a d m o d e m
c o n n e c t i o n.
N o
C a n t h e W W W s e r v e r b e
a c c e s s e d a f t e r c h e c k i n g/
c o r r e c t i n g t h e T C P/I P
s o f t w a r e?
Y e s
I n c o r r e c t T C P/I P s o f t w a r e
c o n f i g u r a t i o n/i n s t a l l a t i o n.
U n k n o w n e r r o r. C o n t a c t n e x t l e v e l s u p p o r t. P o s s i b l e c a u s e s
i n c l u d e a n i n t e r m i t t e n t p r o b l e m o n t h e r e m o t e s e r v e r, a c o n f l i c t
b e t w e e n N e t s c a p e a n d a n o t h e r a p p l i c a t i o n o r t h e o p e r a t i n g s y s t e m
( s u c h a s t h e W i n d o w s N T 3.5 1 S h e l l U p d a t e A l p h a r e l e a s e, e t c.
N o D N S s u p p o r t. H o s t n a m e s
w i l l n o t f u n c t i o n i n N e t s c a p e
w i t h o u t D N S s u p p o r t.
T h e s e r v e r o r a n i n t e r v e n i n g
l i n k i s d o w n o r m a l f u n c t i o n i n g.
I s a l o c a l f i l e o r a
W W W s e r v e r b e i n g
a c c e s s e d?
I g n o r e t h e e r r o r. N e t s c a p e i s t r y i n g t o
a c c e s s a U R L a t t h e s a m e t i m e t h e l o c a l
f i l e i s b e i n g o p e n e d.
L o c a l
N o
N o
N o
Y e s
W W W
D i r e c t
M o d e m
N o
Y e s
Y e s
Y e s
Y e s
N o
N o
Y e s
Tips for Engineering Diagnostics

1.
Gather Data: Identify the possible end
results


Evaluate existing knowledge with common symptoms


Brainstorm possible causes to the problem.





A
Fishbone Diagram

is another name for the
Ishikawa
Diagram

or
Cause and Effect Diagram
.


Copyright © 2011 HDI
-

All Rights Reserved.

25

Tips for Engineering Diagnostics

2.
Ask questions that will eliminate several
possible causes / problems all at once.



Printers: Is this a network printer or a local
printer?


Connectivity: Are you in a company office, a
remote facility, home office, or other location
such as a hotel?


Benefits: Is the benefit relate to you or a family
member?

Copyright © 2011 HDI
-

All Rights Reserved.

26

Tips for Engineering Diagnostics

3.
Eliminate common causes / problems early


Printers: Is the printer out of paper?


Connectivity: Did the VPN connect successfully?


Benefits: Was the doctor in
-
network?

Copyright © 2011 HDI
-

All Rights Reserved.

27

Tips for Engineering Diagnostics

4.
Evaluate the likelihood of causes or
problems and prioritize the order of testing
for them


Printer is out of paper


Printer has a bad power supply


Printer is offline


Printer is not turned on


Printer is out of ink


Printer was not configured on the PC

Copyright © 2011 HDI
-

All Rights Reserved.

28

Tips for Engineering Diagnostics

5.
Consider the cost of the question.


Is the printer plugged in?


Is there paper in the printer?


Does the printer display an error message?


Is the power supply working properly?


Can you replace the printer to see if we can rule
out the server and network?


What is the status of the printer in your control
panel?

Copyright © 2011 HDI
-

All Rights Reserved.

29

Tips for Engineering Diagnostics

6.
Help the user answer the question.


Provide the steps the user needs to determine the
answer.


Add a test to validate the cause.


How to check the status of a printer using the
control panel


These could be steps in the knowledge document


Or a link to another knowledge document

Copyright © 2011 HDI
-

All Rights Reserved.

30

Tips for Engineering Diagnostics

7.
Never end a diagnostic with “I don’t know”.


Always provide guidance.


Usually this is a place in the diagnostic to advise
how to get assisted service or to escalate the
issue.

Copyright © 2011 HDI
-

All Rights Reserved.

31

It’s Time to Exercise


Break into small groups


Develop a diagnostic for the question

What fruit is it?


You may only ask questions that can be
answered by a
Yes

or a
No


The next slide will be your possible answers to
the customer’s question.


You will be given time to test your diagnostic


Copyright © 2011 HDI
-

All Rights Reserved.

32

The “Fruit” Tree


Red Apple


Pear


Banana


Strawberry


Orange


Grapefruit


Red Grapes

Copyright © 2011 HDI
-

All Rights Reserved.

33


Pineapple


Green Grapes


Yellow Apple


Cherries


Kiwi


Cantaloupe


Watermelon

Possible Solution

Copyright © 2011 HDI
-

All Rights Reserved.

34

Does it grow on a tree?

Maximum of 4 questions asked:

Never asked “Is it a <name the fruit>?

Thank you for attending this session.
Don’t forget to complete the
evaluation!

Session: 803

Rick Joslin

HDI

Executive Director, Certification & Training

(E) rjoslin@thinkhdi.com

(C) 412.841.9793