Vous êtes sur la page 1sur 12

 

ServiceNow  Best  Practice  Process    


Incident  Management  
Published:    March  2016  
 
   

 
 

Table  of  Contents  


Introduction  ..................................................................................................................................................................  3  
Incident  Management  using  ServiceNow  .....................................................................................................................  3  
Roles  and  Responsibilities  ............................................................................................................................................  3  
Incident  Manager  ......................................................................................................................................................  3  
Caller  .........................................................................................................................................................................  3  
Service  Desk  Analyst  (1  line)  ...................................................................................................................................  4  
st

Operational  Support  (2 /3 /4  line)  .......................................................................................................................  4  


nd rd th

Service  Desk  Manager  ...............................................................................................................................................  5  


Using  the  State  Model  ..................................................................................................................................................  5  
New  ...........................................................................................................................................................................  5  
In  Progress  ................................................................................................................................................................  6  
On  Hold  .....................................................................................................................................................................  6  
Resolved  ....................................................................................................................................................................  6  
Closed  .......................................................................................................................................................................  7  
Canceled  ...................................................................................................................................................................  7  
Establishing  Priority  ......................................................................................................................................................  7  
Incident  Categorization  ................................................................................................................................................  8  
Managing  Major  Incidents  ............................................................................................................................................  8  
Parent/Child  Incidents  ..................................................................................................................................................  9  
Incident  Templates  .......................................................................................................................................................  9  
Reports,  Homepages  and  Metrics  ................................................................................................................................  9  
Interoperability  with  other  processes  ........................................................................................................................  10  
Problem  Management  ............................................................................................................................................  10  
Change  Management  ..............................................................................................................................................  10  
Knowledge  Management  ........................................................................................................................................  11  
Configuration  Management  ....................................................................................................................................  11  
Service  Level  Management  .....................................................................................................................................  11  
Event  Management  .................................................................................................................................................  11  
 

 
 
 
 
 
 

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   2    
 

Introduction  
This  guide  is  created  to  explain  how  the  incident  management  process  is  designed  to  work  specifically  using  
ServiceNow.    It  should  be  used  by  engagement  managers,  technical  consultants  and  anyone  involved  in  
implementing  the  incident  management  application.    It  should  be  used  in  conjunction  with  technical  
implementation  guides  to  ensure  the  application  is  applied  consistently  to  all  customers.    This  should  also  ease  
customer  upgrade  paths  and  the  ability  to  expand  their  use  of  the  platform.  

Incident  Management  using  ServiceNow  


An  incident  is  defined  as  an  unplanned  interruption  or  a  reduction  in  the  quality  of  a  technical  service  or  a  failure  
of  a  configuration  item  (CI)  that  has  not  yet  impacted  a  technical  service.  Incidents  can  include  failures  or  
degradation  of  services  reported  by  users,  technical  staff,  third-­‐party  suppliers  and  partners,  or  automatically  from  
monitoring  tools.  
The  primary  goal  of  the  incident  management  process  is  to  restore  normal  service  operation  as  quickly  as  possible  
and  minimize  the  adverse  impact  of  incidents  on  business  operations,  ensuring  that  the  best  possible  levels  of  
service  quality  and  availability  are  maintained.  Normal  service  operation  is  defined  as  an  operational  state  where  
services  and  CIs  are  performing  within  agreed  service  and  operational  levels.    Incident  management  is  responsible  
for  managing  the  lifecycle  of  all  incidents.    A  temporary  workaround  to  restore  service  is  all  that  is  required  in  
many  cases  to  complete  the  process.  
ServiceNow  focuses  on  the  use  of  automation  and  information  to  speed  the  path  to  resolution.      

Roles  and  Responsibilities  

Incident  Manager  
Unlike  the  change  management  process  where  each  ticket  needs  to  be  reviewed  in  some  manner  by  the  managers  
of  the  process  incident  management  does  not  require  that.    The  Incident  Manager  is  concerned  primarily  with  
those  incidents  that  are  causing  a  higher  impact.    Typically  they  focus  on  managing  critical  incidents  and  the  health  
of  the  incident  management  process.  
Responsible  for:  
• Developing  and  maintaining  the  incident  management  process  and  procedures  
• Leadership  and  facilitation  of  the  incident  management  process  within  the  Technology  organization  
• Continual  improvement  of  the  process  
• Gathering  and  reporting  on  metrics  to  ensure  the  process  is  being  followed  and  is  effective  
• Managing  critical  incidents  

Caller  
The  Caller  is  the  individual  who  is  being  impacted  by  degradation  to  a  service  or  someone  who  has  discovered  an  
impact/potential  impact  to  a  service.    This  could  be  a  member  of  an  operational  support  team.    Alternatively  if  the  
issue  has  been  discovered  automatically  through  an  event  monitoring  system  then  the  Caller  may  be  captured  
against  that  system.  
 

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   3    
 

Responsible  for:  
• Bringing  incidents  to  the  attention  of  the  Service  Desk  
• Participating  in  the  implementation  of  a  solution  or  workaround  
• Confirming  successful  resolution  

Service  Desk  Analyst  (1st  line)  


The  Service  Desk  Analyst  is  considered  the  front  line  or  face  of  the  Technology  organization.    They  will  be  the  
people  the  rest  of  the  organization  interacts  with  most  commonly  and  this  will  typically  be  when  users  are  
experiencing  some  sort  of  technology  related  issue.    The  goal  of  the  SDA  is  to  deal  with  as  many  incidents  as  
possible  themselves  at  the  point  of  receiving  the  incident.    This  is  first  call  or  initial  contact  resolution.    Ideally  they  
want  to  solve  the  Callers  issue  immediately  without  having  to  involve  other  support  teams  and  without  the  Caller  
having  to  contact  them  a  second  time.  
Even  if  the  issue  cannot  be  dealt  with  by  the  SDA  many  organizations  will  still  keep  ownership  and  communication  
of  the  incident  with  the  SDA  even  though  others  may  be  providing  the  actual  resolution.  
Since  the  SDA  is  expected  to  resolve  incidents  themselves  they  need  a  very  broad  range  of  knowledge  across  all  
technical  services,  they  may  be  considered  a  ‘jack  of  all  trades,  master  of  none’.    This  means  they  need  access  to  
information  to  help  with  their  diagnosis,  as  they  are  likely  to  have  limited  knowledge  on  each  subject.    They  must  
at  least  try  to  determine  a  good  line  of  investigation  so  that  they  can  pass  the  incident  to  the  correct  Operational  
Support  team  for  further  diagnosis.  
Responsible  for:  
• Recording,  ownership,  monitoring,  tracking,  and  communication  about  incidents  
• Investigating  and  diagnosing  incidents  
• Providing  resolutions  and  workarounds  from  standard  operating  procedures  and  existing  known  errors  
• Escalating  incidents  to  operational  support  
• Communicating  with  the  caller  

Operational  Support  (2nd/3rd/4th  line)  


If  a  Service  Desk  Analyst  is  unable  to  resolve  an  incident  on  their  own  they  must  pass  responsibility  to  someone  
else  who  will  have  more  knowledge  and  experience.    Organizations  will  differ  in  how  they  structure  their  support  
nd
teams  however  a  common  approach  would  be  to  have  2  line  support  teams  within  the  Service  Desk  reporting  
structure  who  specialize  in  particular  services  and  would  be  considered  the  SMEs  for  these  services.    Escalating  to  
nd
2  line  would  still  keep  the  incident  within  the  Service  Desk.  
rd
3  line  support  is  typically  the  operational  team  responsible  for  the  service.    For  example  Database  Support,  
Network  Support,  Application  Development  etc.    These  are  the  teams  whose  main  focus  is  the  delivery  and  
maintenance  of  that  service.  
th
4  line  support  may  not  need  to  exist  in  many  organizations  but  this  could  be  where  the  service  is  supplied  by  an  
external  vendor  and  all  internal  support  teams  have  failed  to  resolve  the  issue.    The  incident  now  needs  to  be  
escalated  outside  of  the  organization.  
Essentially  the  higher  the  line  of  support  the  more  knowledge  and  experience  they  should  have  on  the  specific  
service  in  question,  the  less  general  knowledge  they  will  have  across  all  services.  
Responsible  for:  
• Investigating  and  diagnosing  incidents  escalated  from  the  Service  Desk  
• Developing  workarounds  

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   4    
 

• Resolving  and  recovery  of  assigned  incidents  


• Creating  incidents  after  detecting  a  service  failure  or  quality  degradation  or  a  situation  that  may  result  in  
one  

Service  Desk  Manager  


The  Service  Desk  Manager  is  a  key  stakeholder  in  the  incident  management  process.    It  is  their  team  who  will  
resolve  the  majority  of  incidents.  
Responsible  for:  
• Managing  resources  assigned  to  the  Service  Desk  
• Managing  Service  Desk  activities  
• Monitoring  and  reporting  on  Service  Desk  performance  
• Taking  overall  responsibility  for  incident  and  service  request  handling  by  the  Service  Desk  
• Making  improvements  to  the  Service  Desk  

Using  the  State  Model  


States  in  any  ServiceNow  application  serve  a  specific  purpose.    They  are  designed  to  make  it  clear  where  in  a  
process  a  particular  record  currently  resides  and  to  display  progress.    States  should  represent  a  unique  phase  in  a  
process  where  a  specific  set  of  related  activities  are  grouped  together  designed  to  achieve  a  particular  outcome  in  
order  to  move  to  the  next  phase  of  the  process.    For  example  in  Change  Management  the  Review  state  should  
contain  all  activities  required  to  review  the  success  or  failure  of  the  change  after  implementation.    It  would  not  be  
expected  that  review  activities  would  occur  during  other  states.    Out  of  the  box  Incident  Management  has  the  
following  state  model:  
• New  
• In  Progress  
• On  Hold  
• Resolved  
• Closed  
• Canceled  

New  
This  is  where  the  incident  ticket  is  opened  and  all  known  information  about  the  symptoms  experienced  is  
captured.    Any  services  that  have  experienced  an  impact  are  logged  as  a  Business  Service  CI.    The  incident  remains  
in  New  state  until  it  is  being  worked  on.    It  can  be  updated  with  additional  information  from  the  Caller  many  times  
not  just  when  it  is  first  raised.    Incidents  can  be  created  from  multiple  sources.      
• The  Service  Desk  Analyst  can  create  the  incident  directly  as  a  result  of  a  phone  call  or  email  from  a  user.  
• End  users  are  able  to  make  use  of  the  Self  Service  portal  where  they  can  directly  create  a  ticket.    This  
would  use  a  record  producer  to  generate  an  incident  record  rather  than  exposing  the  full  incident  form  to  
users  that  would  not  understand  most  of  it.      
• Incidents  can  be  automatically  generated  via  external  systems  such  as  event  monitoring.  
• Inbound  emails  can  generate  incident  records.  

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   5    
 

In  Progress  
The  incident  is  now  actively  being  worked  on.    This  is  quite  often  recognized  when  the  Assigned  to  field  has  been  
populated  with  an  individual  and  many  customers  will  want  to  automatically  update  the  state  field  when  this  has  
happened.    However  just  because  an  Assignee  has  been  named  does  not  mean  they  have  actually  begun  to  work  
on  it.    It  may  simply  be  assigned  to  their  list  of  work.    It  will  be  for  the  customer  to  determine  what  constitutes  
moving  to  In  Progress  and  this  could  be  manual.  
While  the  incident  is  in  progress  the  goal  is  to  conduct  diagnostic  steps  to  determine  the  cause  and  then  to  fix  the  
issue.    The  fix  could  either  be  a  temporary  workaround  or  a  permanent  solution  whichever  will  end  the  impact  
soonest.      
As  the  incident  is  being  diagnosed  it  may  be  reassigned  to  a  number  of  different  groups  as  certain  things  are  ruled  
out  or  in  and  the  cause  is  narrowed  down.    It  is  common  for  customers  to  want  to  track  the  number  of  times  an  
incident  ticket  is  reassigned  as  one  of  the  key  metrics  of  the  process.  

On  Hold  
The  On  Hold  state  is  used  to  highlight  when  work  has  begun  on  resolving  the  incident,  it  is  not  yet  resolved  but  it  is  
temporarily  not  being  worked  on  due  to  waiting  for  a  further  action  to  occur.    There  could  be  a  number  of  reasons  
for  this  but  commonly  they  are  things  such  as  the  Caller  needs  to  provide  further  information  or  the  solution  is  
identified  but  a  change  needs  to  be  implemented  to  achieve  this.    There  is  a  separate  on  hold  reason  field  to  
determine  why  the  incident  is  on  hold.    This  is  a  choice  list  so  that  customers  can  only  include  those  reasons  which  
they  determine  legitimate  for  pausing  an  incident  therefore  guiding  the  users  of  the  process  to  follow  it  correctly.  

 
The  Service  Level  Management  product  will  make  heavy  use  of  this  state  since  putting  something  on  hold  will  
typically  act  as  the  pause  condition  for  all  SLAs.    

Resolved  
Once  the  fix  has  been  applied  and  tested  by  the  Assignee  and  they  deem  that  it  has  been  successful  they  will  move  
the  incident  to  Resolved.    The  Caller  is  notified  of  this  and  it  is  during  this  state  that  they  are  expected  to  validate  
the  Assignees  belief  that  is  it  fixed.    If  they  agree  then  the  incident  can  be  closed  with  no  further  action.    If  they  
disagree  and  are  still  experiencing  an  impact  then  they  can  send  the  incident  back  to  In  Progress  state  with  their  
explanation  around  why.      
In  most  cases  customers  will  set  a  time  limit  on  when  the  Caller  can  disagree  with  a  Resolved  state  and  this  will  be  
around  5-­‐7  days.    Once  the  time  limit  is  reached  the  incident  will  automatically  move  to  Closed  and  the  Caller  
would  need  to  raise  a  brand  new  incident  if  symptoms  persisted.      
There  may  be  situations  where  it  was  not  possible  to  resolve  the  incident.    Maybe  the  symptoms  were  too  difficult  
to  reproduce  or  the  cost  of  fixing  the  issue  was  deemed  prohibitive.    In  these  cases  the  incident  would  still  be  
considered  resolved  but  with  a  close  code  of  Not  Solved.  
If  the  incident  has  followed  the  Major  Incident  Management  process  it  may  be  that  a  customer  would  also  want  to  
conduct  some  form  of  post  mortem  review  process.    This  should  take  place  during  the  Resolved  state.  

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   6    
 

Closed  
Once  the  incident  has  been  confirmed  as  resolved  and  any  necessary  close  out  work  has  been  completed  the  
incident  is  moved  to  Closed.    At  this  point  all  work  on  the  ticket  is  finished.    Should  any  follow  up  work  be  required  
this  will  be  via  a  problem,  change  or  other  associated  process.  

Canceled  
An  incident  should  only  be  set  to  Canceled  if  it  was  opened  by  mistake  and  an  incident  did  not  actually  exist.  

Establishing  Priority  
Incident  prioritization  typically  drives  the  timescales  associated  with  the  handling  of  the  incident  and  the  targeted  
time  to  resolution.  There  are  a  couple  of  methods  that  can  be  used  to  determine  priority.  
In  most  cases  priority  is  established  using  a  combination  of  impact  vs.  urgency,  where:  
Impact  is  the  effect  that  an  incident  has  on  business.    For  example  if  the  incident  only  impacts  a  single  employee  
the  impact  is  low  in  comparison  to  500,000  paying  customers  with  Twitter  accounts.  
Urgency  is  the  extent  to  which  the  incident's  resolution  can  bear  delay.      
Priority  is  generated  from  urgency  and  impact  according  to  the  following  table.  

  Urgency  High   Urgency  Medium   Urgency  Low  

Impact  High   Priority  1     Priority  2     Priority  3    

Impact  Medium   Priority  2     Priority  3     Priority  4    

Impact  Low   Priority  3     Priority  4     Priority  5    

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   7    
 

It  is  possible  to  automatically  establish  the  priority  of  the  incident  based  on  the  CI  that  is  identified  in  the  incident  
record.  With  this  technique,  the  business  criticality  value  of  the  CI  is  used  to  determine  the  priority  of  the  incident.  
This  ensures  a  more  accurate  and  consistent  prioritization  of  incidents,  as  the  determination  of  impact  and  
urgency  can  be  a  subjective  call.  

Incident  Categorization  
Incident  categorization  is  commonly  used  to  drive  assignment  in  the  incident  management  process  as  well  as  
establish  trends  (incident  types/frequencies)  for  use  in  problem  management,  supplier  management  and  other  
ITSM  activities.    
See  Categorize  incidents  in  ServiceNow  Docs  for  a  list  of  the  category  and  subcategory  values  available  in  the  base  
system  although  these  are  just  considered  examples  rather  than  best  practice  categories.  
See  Define  an  assignment  rule  for  incidents  in  ServiceNow  Docs  for  a  description  of  how  to  automate  assignment  
based  on  categorization.  
This  method  of  categorization  requires  the  creator  of  the  incident  to  manually  select  the  category  and  subcategory  
from  predefined  lists.  
It  is  possible  to  automatically  categorize  and  assign  the  incident  based  on  the  CI  that  is  identified  in  the  incident  
record.  With  this  technique,  the  incident  management  process  inherits  the  same  categorization  schema  as  CIs  
maintained  through  the  configuration  management  process  and  the  category  of  an  incident  is  automatically  
determined  once  the  affected  CI  is  identified  in  the  incident  record.  This  technique  ensures  more  accurate  and  
consistent  categorization  of  incidents  and  supports  a  CI-­‐centric  approach  to  IT  service  management.    

Managing  Major  Incidents  


A  sub-­‐process  within  incident  management  is  the  Major  Incident  Management  process.    The  specific  criteria  for  a  
major  incident  will  need  to  be  determined  by  the  customer  however  for  the  most  part  this  will  include  all  P1  
incidents  and  potentially  some  P2.    
Some  typical  major  incident  criteria  are:  
• The  ability  of  significant  numbers  of  customers  and/or  key  customers  to  use  services  or  systems  is  or  will  
be  affected  
• The  cost  to  customers  and/or  the  service  provider  is  or  will  be  substantial,  both  in  terms  of  direct  and  
indirect  costs  including  financial  penalties  for  any  SLAs  breached    
• The  reputation  of  the  Service  Provider  is  likely  to  be  damaged  
In  addition  to  these  factors  the  amount  of  effort  and/or  time  required  to  manage  and  resolve  the  incident  is  likely  
to  be  large  and  it  is  very  likely  that  agreed  service  levels  (target  resolution  times)  will  be  breached.  
This  process  is  directly  coordinated  by  the  Incident  Manager.    They  will  ensure  that  all  necessary  technical  
resources  have  been  engaged  and  are  dedicated  to  the  incident.    They  will  also  be  coordinating  the  
communications  around  the  incident.    This  will  be  to  key  internal  stakeholders  and  to  the  customers  who  are  
impacted.    It  is  important  for  customers  to  be  regularly  updated  even  just  to  be  told  that  there  has  been  no  further  
progress  than  to  be  left  in  the  dark  and  assume  no  one  is  trying  to  resolve  their  issue.    The  ServiceNow  Incident  
Alert  Management  plugin  enables  organizations  to  create  and  manage  communications  related  to  major  incidents  
or  business  issues.  This  allows  incident  alert  administrators  to  bring  together  all  involved  or  impacted  users  during  
these  events  and  establish  quick  and  easy  communication  within  this  group.    

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   8    
 

Once  the  major  incident  has  been  resolved  there  will  be  follow  up  steps  to  review  what  happened  and  where  
improvements  can  be  made  in  the  future.    Typically  lessons  learned  and  next  steps  are  produced.    It  is  common  for  
a  problem  record  to  be  generated  to  track  any  further  work  required  even  if  the  incident  itself  has  been  resolved.  

Parent/Child  Incidents  
Where  an  incident  is  causing  a  wide  impact  this  will  be  evident  with  a  number  of  records  being  raised  by  different  
Callers  for  the  same  issue.    Although  these  incidents  are  reporting  the  same  thing  and  might  be  considered  
duplicates  of  each  other  it  is  good  to  capture  each  instance  where  the  impact  has  been  experienced  so  that  the  
size  of  impact  can  be  more  easily  determined.    The  down  side  of  having  many  incidents  logged  with  the  same  issue  
is  that  they  will  all  need  to  be  updated  as  the  incident  is  diagnosed  and  resolved.    This  can  be  easily  handled  by  
designating  one  incident  as  the  parent  and  relating  all  other  incidents  to  this  parent  via  the  Child  Incidents  related  
list.    When  work  notes  or  comments  are  added  to  the  parent  these  will  automatically  copy  to  all  related  child  
incidents.    In  addition  when  the  parent  is  resolved  the  child  incidents  will  also  be  resolved  and  the  closure  
information  copied  over.  

Incident  Templates  
Incident  templates  may  be  also  be  established  to  handle  issues  that  are  seen  repeatedly  and  require  the  same  
steps  to  resolve  each  time.    The  Service  Desk  agent  can  raise  a  new  incident  from  a  template  when  they  are  
responding  to  a  call  or  email  from  a  user.    See  Templates  in  ServiceNow  Docs  for  a  description  of  how  to  use  the  
template  feature  of  ServiceNow  to  support  this  concept.  

Reports,  Homepages  and  Metrics  


There  are  numerous  reports  available  in  ServiceNow  that  can  be  used  to  generate  charts,  publish  to  a  URL,  or  
schedule  to  be  run  and  distributed  at  regular  intervals.    Users  can  also  create  custom  reports.  See  Create  and  
manage  reports  in  ServiceNow  Docs  for  more  details  on  this  capability.  

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   9    
 

In  addition  to  reports,  each  user  can  create  a  personal  homepage  and  add  gauges  containing  up-­‐to-­‐the-­‐minute  
information  about  the  current  status  of  records  that  exist  in  ServiceNow  tables.  See  Customize  homepages  in  
ServiceNow  Docs  for  details.  
Metrics  and  Performance  Analytics  can  be  used  to  understand  the  health  of  the  incident  management  process  and  
where  improvements  can  be  made.    
Some  useful  indicators:  
• Open  Incidents  –  Are  there  many  open  incidents  for  a  long  time  -­‐  more  than  90  days?    Are  more  assigned  
to  a  particular  group?  
• New  incidents  -­‐  Do  you  have  a  peak  on  Mondays  –  so  you  need  more  staff  on  that  day?    Any  other  
seasonal  variations?      
• Backlog  growth  -­‐  Are  you  keeping  pace?    What  factors  (category,  etc)  affect  it?  
• Resolved  incidents  –  What’s  the  resolution  time?    Which  group  is  resolving  the  most?  
These  type  of  metrics  can  be  used  in  conjunction  with  Performance  Analytics  to  get  an  easy  to  understand  view  of  
where  to  focus  improvement  efforts.  

Interoperability  with  other  processes  

Problem  Management  
Problem  Management  is  the  ‘next  step’  process  for  incidents  that  require  further  investigation  for  the  root  cause.    
Problem  records  can  be  generated  directly  from  the  incident  record  and  will  copy  over  key  data.    Incidents  can  be  
put  into  On  Hold  state  with  a  reason  of  Awaiting  problem.    There  could  be  many  incidents  associated  with  a  single  
problem  and  the  higher  the  number  of  incidents  the  clearer  the  scale  of  impact  becomes.    It  may  be  that  when  the  
problem  was  first  encountered  the  number  of  associated  incidents  was  low  and  so  it  was  decided  not  to  pursue  a  
permanent  fix  however  as  the  number  increases  and  the  impact  widens  that  decision  may  be  reviewed.  
If  a  workaround  exists  for  the  problem  this  can  be  logged  into  the  problem  record  and  automatically  pushed  into  
all  associated  incident  records.  
Once  the  problem  has  been  fixed  all  associated  incidents  can  be  automatically  closed.  

Change  Management  
For  many  incidents  the  solution  will  require  work  on  a  service,  hardware  or  software.    Conducting  this  work  will  
require  a  change  record  to  be  raised.  

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   10    
 

Emergency  changes  typically  require  an  incident  record  to  be  related  to  prove  that  they  are  urgent  enough  to  
bypass  the  full  process  and  lead  times.  
In  some  cases  a  change  was  implemented  that  resulted  in  an  incident.    An  incident  record  can  be  created  from  the  
originating  change  record  to  show  the  cause  and  link  the  chain  of  events  together.  

Knowledge  Management  
Knowledge  is  a  vital  part  of  the  incident  process.    It  is  available  using  the  Contextual  Search  feature  embedded  into  
the  incident  record  and  record  producers  to  display  relevant  knowledge  articles  as  the  incident  is  being  created.    
Contextual  Search  will  use  text  entered  into  the  Short  description  fields  or  other  text  fields  to  search  for  close  
matches  in  the  knowledge  base  and  display  these  on  the  screen.      

 
This  is  designed  to  assist  either  the  Caller  with  information  that  may  help  them  to  resolve  their  own  incident  
without  having  to  log  it  at  all.    Or  it  can  help  the  Service  Desk  Analyst  to  find  information  that  may  resolve  the  
incident  without  having  to  escalate  to  an  SME.  

Configuration  Management  
The  configuration  management  system  underpins  all  incident  management  activities.  It  not  only  hosts  the  incident  
and  other  service  management  records,  but  contains  details  of  the  infrastructure  vital  to  efficient  call  handling.    

Service  Level  Management  


Service  Level  Management  is  used  to  define  agreed  timescales  around  the  handling  of  incidents.    These  may  be  
internal  agreements  between  support  teams,  contractual  obligations  from  vendors  or  to  customers  and  
expectations  set  with  internal  users.  
These  are  used  within  the  incident  record  in  the  Task  SLA  related  list  to  alert  resolution  teams  to  how  they  are  
doing  within  the  promised  timescales.  
Metrics  can  be  gathered  for  reporting  on  how  well  the  agreements  are  being  adhered  to  using  the  Reporting  and  
Performance  Analytics  functionality.    These  can  then  be  used  to  establish  where  improvements  need  to  be  made    
The  most  commonly  tracked  agreements  include:    
• Incident  response  times    
• Target  resolution  times    

Event  Management  
Automated  event  monitoring  tools  scan  infrastructure  to  check  for  certain  acceptable  conditions  that  are  
considered  healthy.    Once  these  conditions  are  no  longer  met  an  event  or  alert  can  be  created  to  draw  attention  to  
the  change  in  health  of  the  infrastructure.    Where  that  change  has  been  significant  enough  or  is  occurring  

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   11    
 

frequently  enough  that  criteria  would  then  be  considered  an  incident  where  support  resources  would  need  to  take  
action.    Incidents  can  be  automatically  created  based  on  certain  criteria  allowing  support  teams  to  react  quickly.    
Typically  these  alerts  can  be  set  to  catch  issues  before  they  create  a  much  larger  and  more  visible  impact  and  a  
major  incident  can  be  avoided.  

©  2016  ServiceNow,  Inc.  All  rights  reserved.    


ServiceNow  and  the  ServiceNow  logo  are  trademarks  of  ServiceNow,  Inc.  All  other  brand  and  product  names  are  trademarks  or  registered  trademarks  of  their  respective  holders.   12