Service Management Project: POWER USERS TUTORIAL CERN, 31 March 2011 Pablo Martínez, Patricia Méndez, Mats Moller for the (IT and GS) Service Management team

Page 2 Few words before starting… On the 15 th 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

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?

Page 4 Service Management Project in numbers Some Statistics  Number of incidents handled by the service since the 15 th Feb:  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 feeds: ~70%  Through the phone: ~25%  Through the portal: ~3%  Through GGUS: ~1%  Number of requests handled by the service since the 15 th Feb: 4474  Number of NO SPAM request: 3626  Number of NO SPAM IT incidents and not transformed in request: 2556 (70%)  Through feeds: ~50%  Through the phone: ~27%  Through the tool: ~17%  Through the portal: ~4%

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

Page 6 The Elements The Catalogue The tool: Service-now (SNOW) The portal The entry point: Service Desk Right and roles

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 2 nd, 3 rd and (eventually) OWH support What is inside? Services Functional Elements (per department, group, sections) Level of importance included

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  Still supported. However consider this is not the preferred procedure to follow)

Page 9 Reaching the tool and the portal THE PORTALTHE TOOL: SNOW Portal reachable from

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

Page 11 The Processes Incident Management Request Fulfillment

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 feeds (for IT services) (“equivalent” for request fulfillments)  Maintenance of the 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 -feeds)  SNOW is a TICKETING SYSTEM, not a COMMON work place  Do not look for a savannah approach in SNOW

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

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

Page 15 Submitting a ticket from the tool Availability restricted to support unit members and opened to power users MANDATORY As a supporter or caller; be sure you include your comments here The SE can be chosen by the submitter. Otherwise the highest impact relation will be chosen 2.As a power user you can define to whom the ticket should arrive first 3.Impact will automatically define the priority of the ticket 4.Priority defined based on the impact 5.Watch list (persons to be notified and can interact with the ticket. Specific slide dedicated to these persons 6.Confidentiality: If chosen ticket will be visible for: caller, assignment group, watch list members and approvers (RF)

Page 16 What is happening behind the caller?  In default ticket will be assigned to the 1 st 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 feed  The support unit behind has been declared by the FE manager (slide 20)  Service Desk can pass the ticket to the 2 nd level of support  Who is behind depends on the FE managers  If needed, the ticket is assigned to 3 rd level from the 2 nd level  Containing the experts of the service  Out-of-Working-Hours tickets  special procedures explained in slide 25

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 ) 3.IN PROGRESS  Somebody of the support unit has taken the ticket on his hands 4.WAITING FOR 3 rd 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 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

Page 18 Access to the tickets  Once a new ticket is submitted, caller will receive an 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 notification PORTAL Access to the tool

Page 19 Integration with GGUS Previous setup: 1.Ticket assigned to ROC_CERN (user) 2.System at CERN creates a Remedy Ticket 3.CERN Helpdesk assigns it to the corresponding PRMS

Page 20 Mail feeds It concerns all those lists you might use

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 feeds  In default 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 feeds

Page 22 Requests categories 1.Information  Similar workflow as for incidents 2.Support and Consultancy  It has to go to 2 nd level for fulfillment verification before being resolved 3.Project  Same as for Support and consultancy 4.Access  The 2 nd line of support will dispatch the request to a 3 rd person for approval purposes. This 3 rd person will have to fulfill the request before resolving the ticket 5.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)

Page 23 Example managing an Access request The request has been taken by somebody on the 2 nd line support 2.He has added somebody for approval purposes and sent the ticket for waiting for approvals 3.The approver will receive a notification for approval purposes 4.Once approved, the ticket will come back to the assignment group for fulfillment 5.At that point ticket can be put in resolved status

Page 24 Important topics for POWER USERS Out-of-working-hours Knowledge DB Confidentiality Watch lists Sharing the tickets

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 2 nd 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 feeds, GGUS or the portal (in this case we can do it)

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 FEs Important information will be available for callers and supporters

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 for example)  The CANNOT change the incident or the request status  feeds are blacklisted  Availability through:  feeds (any person added in.cc will be added to the watch list)  Any person added through the notification s 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)

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 2011 Pablo Martínez, Patricia Méndez, Mats Moller for the (IT and GS) Service Management team

Page 30 CERN Service Portal PRESENTATION Topics:  Overview of the Portal  Catalogue navigation  Reporting incidents  My Profile  ITIL Role specifics

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

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

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

Page 34 CERN Service Portal: Overview Navigating the Service Catalogue: Navigation Pages To navigate the Catalogue Two pages for Service Elements 1.Catalogue Structure (SA/CS/SE)  Searchable tree 2.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

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  …

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

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, , etc.  Preferences  Portal configuration  Search layout  Main page blocks  Icons  …

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

Page 39 Implementation of the Power Users

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 3 rd slide: 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) 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

Page 41 Extra information  Where to find extra documentation, tutorial material, presentations, etc   Our list:   Our specific FE in SNOW:  IT Service Management Support  FE for SNOW developers  service-now