Embed Size (px)
Citation preview
Service Management Project: POWER USERS TUTORIAL
CERN, 31 March 2011Pablo Martínez, Patricia Méndez, Mats Moller for the (IT and GS) Service Management team
31.03.2011 Page 2
Few words before starting…
On the 15th of February a new (and single) Service Desk at CERN with standard processes for all service providers has entered in production
GOAL OF THE PROJECT: Creation of a single Service Desk at CERN with standard processes for all service providers
User friendly approach for submitters and experts managing the tickets
Continual Service Improvement
HOW IS THIS DONE? Implementation of best practice (ITIL V3) applied to CERN needs
All services from IT and GS departments in Service Catalogue (FI and HR soon to follow)
Available for incident management and request fulfillment (2 processes for the moment)
SCOPE OF THIS TUTORIAL Services from 2 departments are now involved, BUT we already want to involve the experiments and the TE/EN
departments through special super-user representatives: POWER USERS
The following slides include the concepts you need to know before becoming a POWER USER
Even if you finally do not become a POWER USER, you will gain familiarity with the tool
31.03.2011 Page 3
GETTING DIRECTLY IN COLD WATER…
Specialized set of persons (per experiment or department) with the following rights:
1. They will be able to open tickets to any service at any support level and with any priority
2. They will be able to phone the service desk to request escalation of any existing ticket to a more expert support unit (or to change the support unit if needed)
Their judgment will he crucial to define escalation procedures for any ticket submitted from their experiment/department
3. They will have the rights to look at all non-confidential tickets in the system
Possibility to sort by experiment name already available in production
It is up to your experiment /department to decide whether you want to define such groups of persons after this tutorial
… who will be power users?
31.03.2011 Page 4
Service Management Project in numbers
Some Statistics
Number of incidents handled by the service since the 15th Feb: 10209 Number of NO SPAM incidents and not transformed in request: 6659 Number of NO SPAM IT incidents and not transformed in request: 4684 (70%)
Through email feeds: ~70% Through the phone: ~25% Through the portal: ~3% Through GGUS: ~1%
Number of requests handled by the service since the 15th Feb: 4474 Number of NO SPAM request: 3626 Number of NO SPAM IT incidents and not transformed in request: 2556 (70%)
Through email feeds: ~50% Through the phone: ~27% Through the tool: ~17% Through the portal: ~4%
31.03.2011 Page 5
Topics covered by this tutorial
The elements of the project The Catalogue The tool: Service-NOW (SNOW) The portal The Service Desk Rights and roles
The processes Incident Management Request Fulfillment
Important concepts you will need Knowledge DB, OWH, confidentiality, watch list Sharing tickets
Portal details covered by Pablo
Implementing POWER USERS
31.03.2011 Page 6
The Elements
• The Catalogue• The tool: Service-now (SNOW)• The portal• The entry point: Service Desk• Right and roles
31.03.2011 Page 7
Service catalogue
All technical services, activities and functions currently in production Section and Group leaders in charge of the Services and functions Support groups behind to provide 2nd, 3rd and (eventually) OWH support
What is inside?
Services
Functional Elements (per department,
group, sections)
Level of importance included
31.03.2011 Page 8
Elements available to the user
THE TOOL: 5 available instances of Service-NOW (SNOW) in production, training, testing sandbox and development
SNOW is a commercial product widely used in commercial and non-commercial organizations (CERN evaluated 42 products)
Most of the features we provide are out-of-the-box New requirements might have limitations
Self-service Portal Continuously including new improvements Users can access from the portal in a user friendly (and customizable) way:
Their active tickets Catalogue elements (FE, SE) submission of new tickets through specific Record Producers Knowledge articles
Service Desk Placed in B55 and opened from 7:30 to 18:30 with a service counter
Entry points: Phone (77777) Self-service portal Email: Still supported. However consider this is not the preferred procedure to follow)
31.03.2011 Page 9
Reaching the tool and the portal
THE PORTAL THE TOOL: SNOWhttp://cern.service-now.com/service-portal https://cern.service-now.com/navpage.com
Portal reachable from www.cern.ch
31.03.2011 Page 10
Rights and Roles
Following ITIL procedures, rights into SNOW are defined based on ROLES The support units role: “ITIL”
Any person included in a line of support has this role This is the role that POWER USERS will have
ITIL rights from the tool
Read access to all non-confidential tickets
Possibility to escalate the assigned ticket to other support units
Reassignment of tickets to other support units independently of the Service Desk
Creation of tickets from the tool
ITIL rights from the portal (more details given by Pablo)
Direct access to the tool for: Your own tickets Your own SE/FE for editing
purposes Publication of all keywords associated to
all SE/FE
31.03.2011 Page 11
The Processes• Incident Management• Request Fulfillment
31.03.2011 Page 12
The Processes: INCIDENT MANAGEMENT
ITIL terminology: “An incident is an unplanned interruption to an IT service or reduction in the quality of an IT
service” How to submit an incident:
From the portal (same for request fulfillments) We encourage this approach (next slide)
From the tool (same for request fulfillments) Available if you have the power user roles
Phoning the Service Desk (same for request fulfillments) Through email feeds (for IT services) (“equivalent” for request fulfillments)
Maintenance of the email feeds based on service responsible demands Through GGUS (for Grid related services) (“equivalent” for request fulfillments)
Important for the Grid community
It is worth to mention now (applicable also to request fulfillments): SNOW is not intended to substitute the ticketing systems you use to have (applicable to
GGUS and email-feeds) SNOW is a TICKETING SYSTEM, not a COMMON work place
Do not look for a savannah approach in SNOW
31.03.2011 Page 13
Submitting an incident from the portal
AVAILABILITY: ANY USER WITH A CERN ACCOUNT
Insert the topic of your search “a la google”Pablo will give all details about the portal
31.03.2011 Page 14
Advantages of the portal: The Record Producers (RP)
They will pop up after your search in the portal under the category: “tickets”
Available also from the FE and SE links
The title of the RP might be more intuitive than the FE/SE names
Direct and correct assignment of tickets to support units
Increase the performance of supporters Specific questions created by the FE
managers are included All info needed by the supporters
will be passed in just one step PENDING:
Add new persons to follow the ticket (the so called watch list)
Under development (already available for some few RPs)
Not all FE/SE contain RPs
31.03.2011 Page 15
Submitting a ticket from the tool
Availability restricted to support unit members and opened to power users
MANDATORY
MANDATORY
As a supporter or caller; be sure you include your comments here
23
456
1
1. The SE can be chosen by the submitter. Otherwise the highest impact relation will be chosen2. As a power user you can define to whom the ticket should arrive first3. Impact will automatically define the priority of the ticket 4. Priority defined based on the impact5. Watch list (persons to be notified and can interact with the ticket. Specific slide dedicated to these persons6. Confidentiality: If chosen ticket will be visible for: caller, assignment group, watch list members and approvers (RF)
31.03.2011 Page 16
What is happening behind the caller?
In default ticket will be assigned to the 1st level of support: Service Desk From the portal:
Specific Record producers can have pre-assigned the ticket to another support unit inside the chosen FE
From the tool: The assignment group can be chosen (POWER USERS RIGHTS), although the
default value is the Service Desk From an email feed
The support unit behind has been declared by the FE manager (slide 20) Service Desk can pass the ticket to the 2nd level of support
Who is behind depends on the FE managers If needed, the ticket is assigned to 3rd level from the 2nd level
Containing the experts of the service Out-of-Working-Hours tickets special procedures explained in slide 25
31.03.2011 Page 17
Steps of a submitted incident
1. NEW Ticket creation. Default state for new incidents
2. ASSIGNED Ticket assigned to a FE and a support unit (all members notified via email)
3. IN PROGRESS Somebody of the support unit has taken the ticket on his hands
4. WAITING FOR 3rd PARTY A new person is involved for the resolution of the ticket
5. WAITING FOR USER A answer from the caller is needed and he will be notified via email
6. WAITING FOR PARENT In the case the ticket is a child of an already existing ticket (from another user)
7. WAITING FOR CHANGE Incidents cannot be resolved immediately due to specific constrains
8. RESOLVED Specific and MANDATORY codes define the different close reasons (restored, workaround,
spam…)9. CLOSED
All resolved tickets not reopened by the caller are automatically close after 3 days At this point the ticket cannot be reopened again
31.03.2011 Page 18
Access to the tickets
Once a new ticket is submitted, caller will receive an email notification
It includes a link to the portal corresponding to this incident
Available for certain roles only (ITIL, including power users) access to the tool is also available
E-mail notification
PORTAL
Access to the tool
31.03.2011 Page 19
Integration with GGUS
GGUS and SNOW
1. Tickets assigned to the FE: „CERN Grid 2nd Line Support“ (specific 2nd line support email behind)
2. Ticket dispatched to the corresponding FEs containing the responsible support units behind
Status of the integration
In production for the FE below (integration with the IT-GT services still pending)
Synch between GGUS and SNOW in place
MESSAGE: SNOW DOES NOT REPLACE GGUS. If this is your ticketing system for GRID related issues, KEEP IT.
Previous setup:1. Ticket assigned to ROC_CERN
(user)2. System at CERN creates a
Remedy Ticket3. CERN Helpdesk assigns it to
the corresponding PRMS
31.03.2011 Page 20
Mail feeds
For all those support lines maintaining inbound emails
a. Mailing lists mapped to a specific Functional Element
b. Emails sent to these lists will create INCIDENTS with the following assignments:
a. During working hours the 1st receiver is the Service Desk
a. Unless the FE Manager has declared a direct route to 3rd level
b. Outside-Working-Hours (if defined), it will go to the OWH support group (slide 25)
Support lines no longer maintaining inbound mails
Return email will be sent to the user with a link to the SNOW portal
Emails sent to the Service Desk: Same procedure as in inbound emails
If the caller is a services address (for instance, monitoring/control systems) reporting to an email feed
Creation of WHITE LISTS including well known services emails that will be treated as “users”
MESSAGE: While using email feeds we cannot avoid the “ping-pong” emails to the caller
Email is a free text. Support lines might need to come back to the caller to collect further information
It concerns all those [email protected] lists you might use
31.03.2011 Page 21
The Processes: REQUEST FULFILMENT
Most of the important topic associated to incidents (submission, visualization of tickets, etc) can be applied to requests
ITIL terminology: “A request from a user for information, or advice, or for a standard change or for access to an IT
service” How to submit a request:
From the portal (same as incidents) From the tool (same as incidents) Phoning the Service Desk (same as incidents) Through email feeds
In default email feeds will create an incident Based on the judgment of the support line behind, this incident might be transformed in a
request At that moment the incident will be closed (caller will be notified) and the evolution of the
ticket will be followed from the request Through GGUS (for Grid related services)
Similar approach to that described for email feeds
31.03.2011 Page 22
Requests categories
1. Information Similar workflow as for incidents
2. Support and Consultancy It has to go to 2nd level for fulfillment verification before being resolved
3. Project Same as for Support and consultancy
4. Access The 2nd line of support will dispatch the request to a 3rd person for approval purposes. This
3rd person will have to fulfill the request before resolving the ticket5. Services & Products
Same approach as for access, this time including technical, financial and functional approvals
6. Configuration & Enhancements Same approach as for Services & Products
All these categories can be assigned directly to the support lines of the FEs BUT the category information (always passing through the Service Desk)
31.03.2011 Page 23
Example managing an Access request
1
2
3
1. The request has been taken by somebody on the 2nd line support 2. He has added somebody for approval purposes and sent the ticket for waiting for approvals3. The approver will receive a notification for approval purposes4. Once approved, the ticket will come back to the assignment group for fulfillment5. At that point ticket can be put in resolved status
31.03.2011 Page 24
Important topics for POWER USERS
• Out-of-working-hours• Knowledge DB• Confidentiality• Watch lists• Sharing the tickets
31.03.2011 Page 25
Some important concepts you need to know (1)
Out-of-Working-Hours
If this group is declared, incidents will be directly assigned to this group after 17:30
If tickets still in assigned status the day after at 8:30, resubmitted to 2nd line support
We want to avoid huge amount of non urgent issues arriving after working hours
Confidentiality
Confidential categories per FE declared by some FE managers
Any ticket assigned to that category will be treated as confidential, this means:
Only the caller, the supporter, the watch list and the approver (for RF) will be able to see the ticket
On caller demand, ticket can be considered confidential at submission time
Not possible through email feeds, GGUS or the portal (in this case we can do it)
31.03.2011 Page 26
Some important concepts you need to know (2)
Knowledge DB
It contains knowledge and information useful to resolve incidents/requests
Available from the portal and (currently) visible for any user
Levels of access to the knowledge DB under discussion
Specific approval procedures put in placed
Any support unit person can submit an article for the Knowledge DB
Approvals from the FE manager and specific boards will be followed before publishing the article
In production on Monday
All FAQ’s imported to SNOW
Already accessible from the portal
Available KB grouped by FEsImportant information will be available for callers and supporters
31.03.2011 Page 27
Some important concepts you need to know (3)
WATCH LISTS
List of persons following the evolution of the tickets
They can submit comments to the ticket (answering the notification email for example)
The CANNOT change the incident or the request status
Email feeds are blacklisted
Availability through:
Email feeds (any person added in .cc will be added to the watch list)
Any person added through the notification emails in the middle of the ticket life will be also added
Tool already seen in previous slides
Portal Inclusion of the watch list through the Record Producers ongoing
GGUS .cc field in GGUS not (yet) exported to the watch list of SNOW (following it with experts)
31.03.2011 Page 28
Sharing the tickets
From the portal Submitted tickets can be seen exclusively by the caller
From the tool Specific roles can see all submitted tickets Otherwise, callers can also see their specific tickets through the tool In both cases, the ticket can be currently exported as pdf and at this
point sent to any other person If you are a supporter, you can export the ticket of any person
We are considering the following approach At creation time, caller can decide the level of visibility of their tickets From confidential to public If public, then the ticket will be visible for any user also from the portal
Service Management Project: POWER USERS TUTORIAL
CERN, 31 March 2011Pablo Martínez, Patricia Méndez, Mats Moller for the (IT and GS) Service Management team
31.03.2011 Page 30
CERN Service Portal
PRESENTATION
Topics:
Overview of the Portal Catalogue navigation
Reporting incidents
My Profile
ITIL Role specifics
31.03.2011 Page 31
CERN Service Portal: Overview
What is the Service Portal for?
Goals: End-user friendly interface Service Catalogue navigation with ease
Search Hierarchical tree
Mechanism to report incidents and requests Other features
My Profile List of Contacts News
31.03.2011 Page 32
CERN Service Portal: Overview
Navigating the Service Catalogue: Search
• Search: Key element
Search for services/issues Catalogue items Tickets (RP) KB Articles
Available in Home page Banner CERN Users site
31.03.2011 Page 33
CERN Service Portal: Overview
Navigating the Service Catalogue: Search
• Search Results page
New algorithm (points, filters…) Search in titles and
keywords
Results page Google-like (use of “”) Differentiate elements type
Use icons Left side filters
Highlighted results Configurable layout
31.03.2011 Page 34
CERN Service Portal: Overview
Navigating the Service Catalogue: Navigation Pages
• To navigate the Catalogue
• Two pages for Service Elements1. Catalogue Structure (SA/CS/SE)
Searchable tree2. Service Elements by name
Indexed by name
• Two pages for Functional Elements Same structure than SE
• All Tickets List of all tickets by SE/FE
31.03.2011 Page 35
CERN Service Portal: Overview
Navigating the Service Catalogue: Detail Pages
• Description of the element
• Detail pages for Service Elements
Description Location Phone numbers …
Functional Elements Service Areas KB Articles …
31.03.2011 Page 36
CERN Service Portal: Overview
Reporting incidents: Using Record Producers
• With Record Producers
RP is a specific form to automatically generate a ticket Issues related questions Creating a SNOW incident/req.
Accessible from One ‘general’ under the Search Associated SE/FE Search
31.03.2011 Page 37
CERN Service Portal: Overview
Other: My Profile
• Personal information Last incidents (10)
Visualize incidents Get a printable version (PDF)
Last requests Personal information
Name, email, etc. Preferences
Portal configuration Search layout Main page blocks Icons …
31.03.2011 Page 38
CERN Service Portal: ITIL Role
Special features: ITIL Role
• Service Portal designed for end-users Few ITIL Role features
• ITIL Role special functions Service Element / Functional Element
See keywords SA / CS / SE / FE
‘Edit’ button (link to SNOW) My Profile
Link to see the SNOW profile Link to see the Group Members
31.03.2011 Page 39
Implementation of the Power Users
31.03.2011 Page 40
How they will be involved in the project
These persons will be grouped in certain FEs (already declared) in the catalogue
Computing Support for ATLAS, Computing Support CMS, Computing Support LHCb, Computing Support ALICE, Computing Support TE, Computing Support EN, Computing Support BE
The lines of support of these FEs will be populated with the final list of power users
These people will have the ITIL role that will provides them with the roles mentioned in the 3rd slide:
1. They will be able to open tickets to any service at any support level and with any priority2. They will be able to phone the service desk to request escalation of any existing ticket to a more
expert support unit (or to change the support unit if needed)3. They will have the rights to look at all submitted tickets in the system
The FE will not be visible from the portal for any user (hidden FE)
They will not be chosen as FE and support unit
We avoid the possibility of any assignment of tickets to these FEs
31.03.2011 Page 41
Extra information
Where to find extra documentation, tutorial material, presentations, etc https://services.web.cern.ch/
Our email list: [email protected]
Our specific FE in SNOW: IT Service Management Support
FE for SNOW developers service-now
