Service Now

New features for the CERN implementationNovember 2012

Agenda• Priority matrix (INC & REQ)• Catalogue Structure

– Service Owner role and position– SE/FE notification flags

• Service management Roles & Role assignment• Master-Detail ticket structure• Bulk operations• Feedback • Knowledge article expiration• Confidential ticket tracking• Reopened flag / color• Notifications • Time worked • SLA / OLA structure

Modified Incident priority matrixPriority          

  Impact

 

Service Down

or a critical adverse impact on provision of service to the Business

Service Degradedor a major adverse

impact on provision of service to the Business

Service Affectedor a minor adverse

impact on provision of service to the Business

<1%

Service Disruption1 User or a small

number of the population affected

 

High: The damage caused by the Incident increases rapidly. P1 P2 P3 P4

Urgency

Medium: The damage caused by the Incident increases considerably over time

P2 P3 P4 P5

 

Low: The damage caused by the Incident only marginally increases over time

P3 P4 P5 P6

Essential Important Necessary Useful Nice-to-Have

Incident priority matrix -Implementation details

– SE <-> FE relation sets the default Urgency (as before)– Urgency can now be changed by supporters– Impact values changed

• Down / Degraded / Affected / Disruption

Request priority matrix• Impact “easy” to understand and aligned

– Similar to incidenti.e The request has impact on the delivery of the service to the business.

• Old Urgency was “mis-used” to specify delivery– Create separate delivery info– New request state ‘waiting for delivery time’ and manage priorities

according to the delivery calendar – Reward good planning making a.s.a.p. default medium

 

 As soon as possible

Urgency =

Delivery Fixed

 Flexible

 

 OLD NEW

 As soon as possible Medium

Urgency Fixed High - Low - High

 Flexible

High - Low - High

High Waiting for delivery date High

Modified request priority matrixPriority          

  Impact

 

Critical for the provision of service

to the Business

Major impact on provision of

service to the Business

Minor impact on provision of

service to the Business

Small impact on provision of

service to the Business

 

Fixed/Flexible(not treated &

delivery imminent)

High P2 P3 P4 P5

Urgency Delivery

As soon as possible Medium P3 P4 P5 P6

 

Fixed/Flexible(waiting for calendar)

Low P4 P5 P6 P6

Request priority matrix -Implementation details

– New field delivery• Values: Fixed / Flexible / as

soon as possible• If Fixed:

– Due date mandatory

• If Flexible : – Start date / End date mandatory

– Future change• New ticket state “waiting for delivery date”

– stops the time counting– Automatically goes back to in progress when delivery date approaches

Request priority matrix -Implementation details (2)

– SE <-> FE relation sets the default Urgency (as before)– Urgency can now be changed by supporters (as before)– Impact values changed

• Down / Degraded / Affected / Disruption

Service Area

Customer Service

Service Owner

Service Element

Customer

User

3rd Line Support Group

2nd Line Support Group

Functional Service Manager

OWH Support Group

Functional ElementOLA

Contracts

A

OLA

OLA

OLA Template

1nd LineSERVICE DESK OLA

People

Service levels Service hours = Schedule

SLA(s)

Service levels Service hours = Schedule

Catalogue structure (August 2011)

4rd Line Support Group

Service Area

Customer Service

Service OwnerService Element

Customer

User

3rd Line Support Group

2nd Line Support Group

Functional Element Manager

OWH Support Group

Functional Element

OLA

Contracts

A

OLA

OLA

OLA Template

1nd LineSERVICE DESK OLA

People

Service levels Service hours = Schedule

SLA(s)

Service levels Service hours = Schedule

OLA

Catalogue structure (November 2012)

Catalogue structure - implementation details

Catalogue structure – notification flags

• Service Element notification flag set: – 100% SLA notifications to Service Owners

• Functional Element notification flag set: – 50%, 75% and 100% SLA notifications to supporters– 100% notifications to Functional Managers

Service Management Role definitions

Services

functions

User

Use

Service ManagerOn Duty

Assistance

Service Owner

Monitors

Service Desk

Service Desk Manager

SupportSupervises

Customer

Represented

Provides Support

SupportGroups

FunctionalService  Manager

Is reponsible

Roles & Role assignment

4rd Line Support Group

Functional Element Manager

OWH Support Group

1nd Line SERVICE DESK

Egroups

AIS-Roles

Service Owner

SNOW-ADMIN

3rd Line Support Group

2nd Line Support Group

People (Foundation)

SNOW FE’s & SE’s

Master-Detail / Parent-Child• Master-detail is NOT parent-child– Parent-child allows handling the parent and thus working

on the child at the same time

Master detail ticket relations• Master detail allows “organizing” autonomous tickets– No transmission of any data between tickets– Available for INC (will come soon for REQ)

Bulk operations

• Clicking on the Actions button the list of “allowed” actions for the selected tickets is displayed

• Non applicable actions to the selected tickets are not selectable

• Bulk operations accessible from the list of incidents– Request will come soon

• Operations follow the same rules as for individual tickets

Bulk operations in detailBulk operation Description

Resolve Resolution of tickets in bulk mode• Applicable to tickets allowing the immediate resolution• Close code (M), solution field (M), work notes and additional

comments common for all selected tickets (dialog form available)

Set back to assigned Release selected tickets back to the pool

Add work notes Addition of common work notes (supporter internal notes) for all selected tickets

Set waiting for parent Assignment of selected tickets to a selectable parent• Candidate list restricted to “allowed” parents

Un-highlight  reopened Un-highlight the red color of reopened tickets

(M) Mandatory

Bulk operations in detail• “set waiting for parent” dialog• Will display only available parents for all selected

tickets (Loops not allowed)

Feedback (update)• Callers & Supporter can give feedback on the process at any time in the lifecycle of the

ticket.– This is NOT for giving details on the issue but for complaints and compliments

• Feedback targeted to a specific Functional Element and assignment group that is or was involved in the ticket

• Functional Managers can also give feedback to other previous Functional Element and assignment group that were involved in the ticket

Feedback (update)• The “destination’ Functional manager is notified

and should take action on the feedback if required• The Service Management team surveys negative

feedback to see if there are problems to be solved

• About 430 published articles have expired or are about to expired (within next week) in the system– Revision limit is set in default to one year– Submitters and Functional Managers notified in advance– Can use the menu to find their articles– After that date articles will be labeled in the portal as

EXPIRED

Not convenient from the user points of view

Knowledge article expiration

• One-click procedure to extend easily the next review date ( for Functional managers & Submitters)

– Top menu, right click: “Extend Review date”– Extends the new review date in one year

Knowledge article expiration

https://cern.service-now.com/service-portal/article.do?n=KB0001656

Confidential ticket tracking• Allows to know where a confidential ticket is without being able to see the data• Used by Service Desk if they get questions from the caller• Available for all supporters so they can know who now has a ticket they were

invoked with• Put a work note in the ticket (that you can not see )

Reopened ticket flagging• Possibility to take the orange coloring away

– Some support groups were disturbed by the coloring– Reopen counter not affected– Can be done in “bulk mode”

Notification settings

• All “supporter” notifications can be switch on/off

Notification device's• Supporters can set additional email and SMS notification destinations for all or a subset of

messages.• Detailed information available on request

Old Time Worked - CERN implemented feature

• Time worked field :– Visible only when ticket “in progress”– When ticket changes state <> “in progress” and time worked

<> 0 a metric record is created• Confuses the supporters and is difficult to understand• Requires reporting to group metric records and get information

about the full ticket time

New Time worked - standard ServiceNow

• Field always visible• Allows use of start/stop timer (when ticket visible)• Allows to add / subtract time • Accumulated time visible in the ticket• Individual “contributions” tracked in a tab at the bottom

SLA – target resolution time• Incident SLA due shows the target resolution date/time• Based on: priority & schedule (defined by the Service Owners)• Calculated & updated when conditions change (screen refresh)• Coming soon for request Fulfillment

SLA structure (reminder)• For each Service we combine schedule & priorities• Reflected in the ticket and in SLA reporting

SLA structure (reminder)performance reports

• Service Owners should:– Adjust the schedules– Set the proper target resolution times (priority)– Decide if they receive notifications (SE- tick box)

• Functional managers should– Decide if the support teams start to receive

notifications (FE- tick box)

– Coach the support team performance– Decide if they need OLA’s for their teams

SLA – what we need from you

New “berlin” ServiceNow release

• Has been thoroughly tested in the last weeks• Many issues handled / back to

“OutOfTheBox”• Upgrade on Sunday 19 November• Should be ready on Monday morning• No impact expected for users / no change in

functionality– Opens possibilities for future improvements