1. not for distribution IBM Systems Middleware © 2015 IBM Corporation IBM Control Desk Service Request, Incident and Knowledge Management – Workshop Functions of Service Desk, Fulfillment, Self Service Self Facilitated

2. not for distribution IBM Systems Middleware © 2015 IBM Corporation Why Use This Deck  Your company has recently purchased IBM Control Desk and wish to enable functions in the area of service request, incident, knowledge management.  Planning an implementation of service desk system is more than just an install of the software.  Service Desk, Self Service, Catalog, offerings, delivery of services, knowledge and incident management are the face of IT to the business.  Workshops are conducted to design and define the processes, use and configuration of the new tool set. Workshops are simply a single step in the overall methodology of software implementations.  Allowing stakeholders and users to come together to define business processes helps ensure adoption of the software. Ensure that you include all the stakeholders in the planned workshop  To ensure faster agreement of new process changes.  Establish project focus and momentum.  Confirm ownership and mission. 2

3. not for distribution IBM Systems Middleware © 2015 IBM Corporation How to Use This PowerPoint Deck  This deck is constructed to facilitate a workshop and to be used in a group setting. The slides should facilitate discussion and ensure design and configuration decisions. The collaborative workshop should take hours or days to ensure complete design.  The workshop should be more than just talking about current processes, it is improving and determining configurations for IBM Control Desk (ICD) capabilities. Do not recreate current tool capabilities into IBM Control Desk, this will produce failure before you start. Always assess and ask “why?” when appraising current processes. Be cognizant of what works and what doesn’t. Build on what works in your current processes, do not be afraid to reconstruct what does not work!  Draw diagrams, write on whiteboards or present diagrams/documents to help illustrate points or relay information among the attendees.  Always ask “WHY?” If the “why?” doesn’t come quickly, skip over and return to ask Why.  The slides are not designed to ask every question for each process, they are meant to focus the group on what configuration and processes are necessary for the implementation. 3

4. not for distribution IBM Systems Middleware © 2015 IBM Corporation Preparation for Workshop  Activities to complete before conducting workshop: Have leaders/organizers or all of the attendees read the following list of pre reads (details in note section below) Ensure the project team has completed the base data design or ensure the focus to also define the necessary base data during this workshop. oIf the base data design is complete it should be understood by attendees (details on Base Data in Project Configure link in notes section below)  Collect any current documentation or diagrams on current processes to reference during workshop.  Did you consider using the Process Content Packs, as a starting point? Process Content Packs - Informational  Identify a documenter for the workshop and provide them the Design Document. Ensure Design Document is updated as part of the workshop activities ! Design Document – Template In Design Document, record attendees of work shop. It will be referenced later, it always is. 4

5. not for distribution IBM Systems Middleware © 2015 IBM Corporation Define Project Objectives, Goal, and/or Mission  Describe and document the mission, goals – Where do you want to be? Understand your strategy for service desk, catalog and self service and how it fits into the wider operational & business context oDoes it align to the overall business goals? This is a critical step for all attendees, to ensure all in the organization are in agreement of the goal and objectives Ensure this mission is agreed to at the executive level This drives the overall project, approach, and timeline  Measure for success - How do you know you made it? This does not need to be endless metrics but you need to be able to measure the success, or steps. Examples: oDesk agents are able to create, work and manage tickets without extensive training oSelf Service provides solutions and knowledge for the user to search before creating a request for an item or support, thus allowing for ticket deflection oCatalog items display to end users based on services offered to enable requesting through the self service application, and data captured the first time for fulfillment. 5

6. not for distribution IBM Systems Middleware © 2015 IBM Corporation High Level Discussion Topics  Are there shortcomings of processes or capabilities that should be discussed & what priority should they be addressed in this project? It may not be possible to tackle them all so priority is key Do not try and rebuild old tool in new tool, you will carry the shortcomings with you.  What data if any will need to be migrated from existing tools (assets, categorization, organization, cost centers, locations, owner or work groups)?  Are there any regulatory (SOXS), audit compliance or best practice (ISO19770, ISO2000, ITIL, COBIT) requirements that must be met? If yes, who is the stakeholders or interested parties, that can ensure compliance?  Does the project have in scope items or exclusions? Ensure they are documented and adhered to throughout workshop session.  What metrics, SLA, KPIs & reports are produced now, and what is required additionally going forward? How does the process perform against targets today? Do not recreate reports just to create them, validate they are needed as many reports exist in legacy systems that are unused or of no value with next or current processes.  How many expected users? How many self service users? Will there be 3rd party/external users? 6

7. not for distribution IBM Systems Middleware © 2015 IBM Corporation 7 END USER Self Service END USER Self Service Submit Service Request Service Desk Agent Works Service Request Search for Solutions Create Incident Service Desk Agent Works Service Request Search for Solutions Create Incident Incident Agent Works Incident Create Problem Incident Agent Works Incident Create Problem Problem Agent Works Problem Problem Agent Works Problem Create Catalog Request Work Order created to begin fulfillment process Ticket Resolved & Survey completed by End User Search Solutions Ticket Deflection achieved Ticket Process Flow

8. not for distribution IBM Systems Middleware © 2015 IBM Corporation Understanding Your Maturity and Processes  Where is the organization at in respect to maturity of processes? Are the processes consistent steps and flows that would allow for automation? oIf not consider manual and define automation as next steps Is there room in the project to improve the processes? Must you start “near” as is and grow Consider how these factors influence design and configurations oPeople (number of users ) oNumber and type of Processes oEffectiveness of the processes and the challenges they may have oInterconnectivity of teams and flows of work  Based on maturity determine if you can take a path of automation, or if you may start with the processes a bit more manual and automate them as use and understanding of the tool increases Review Job Aid: on manual or automated desk processesJob Aid: on manual or automated desk processes 8

9. not for distribution IBM Systems Middleware © 2015 IBM Corporation Next Few Slides are focused on Designing - Through Use Cases  Slides 10 – 17 are use case slides, created to help you through the design workshop if you do not have use cases documented or they are similar to these.  If your business already has use cases defined, use them as the basis for the workshop discussions independently or in conjunction with the ones provided. There are common use cases on the next few slides, and same as used in Project Start The questions in the gray boxes in the following slides are general questions that should be applied to all use cases. If you are bringing in use cases from your own organization, it is recommended to apply the questions in the box to them as well.  If the business only has a list of requirements and not use cases, it is suggested to utilize said list in conjunction with the use cases provided in the following slides. It is not recommended to base the design solely on a requirements list. This will cause the tool/process not to flow based on user tasks and cause user dissatisfaction.  Discuss the use cases in the following slides collaboratively, as the slides help with general use questions. The general questions apply to all of the use cases to help facilitate a good business discussion and define the design for configuration 9

10. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case One  What would users be enabled to do and not through the Self Service portion of ICD?  What business flow must a request follow?  What business flow must a fix (broken asset etc.) follow?  Are all end users the same? Should they have different permissions?  Would the end users be requesting a fulfillment request or an issue to be resolved?  What or how do you wish to display to user? oWhat services, knowledge items and support would you provide to attempt ticket deflection? 10 After logging into the ICD Self Service Center, an End User submits a service request Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

11. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case Two Will end user chat be supported? What hours is chat available? Who will be assigned to chat? All Service Desk Analysts or some subset? Are multiple chat topics necessary for the end user to select? If this is new capabilities for your business, ensure to consider staffing, and how this impacts the other ways to create a service request. 11 End user chats with Service Desk Analyst for an issue which creates a service request Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

12. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case Three Will creating of tickets through email be supported? Do they have different level of service provided through email vs. through chat/call/walk-up? What email address will you provide to ensure the user can create a ticket through email? (this must be set in the tool) 12 A Service Request is created through an email sent from an end user to the support software Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

13. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case Four What data must the agent collect? Is there any fields required? Is this a request for service or an issue to be resolved? Will you need several flows for different request types? Are there common ticket types that are created, which could allow for “templates”? How might you design self service to encourage user to try to find an answer first before calling? 13 Service Desk Agent creates a service request from a call received from an end user or by walk up Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

14. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case Five Is workflow /automation necessary? Are all tickets assigned to desk first? Can you move a request ticket directly to fulfillment team? What is the different urgency for different priority of tickets? What sources does the analyst use to find answers? Should a knowledge base be created and used? 14 Service Desk Agent works the ticket within IBM Control Desk, to resolve the users issue or fulfill the request Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

15. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case Six How or what is the notification process to the incident team? What teams or groups need to be enabled as incident analyst support? Is the same classification for Incident used as with Service Request? Are there agreements with other teams to assist in incident management processes? 15 Service Desk Agent creates an Incident from a Service Request and assigns it to the Analyst Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

16. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case Seven Is there active Problem Management today? If not, is this a phase one activity? Problem management is often part time work of desk agents and incident analysts, is it necessary to know when these resources may be working a problem versus other ticket types? Root cause analysis often spans days and resources, how detailed is this need for timelines and what the resources may be doing? 16 Incident Analyst creates a Problem record from an incident and assigns it to a Problem Analyst Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

17. not for distribution IBM Systems Middleware © 2015 IBM Corporation Use Case Eight Will you utilize the Knowledge Base as a means of ticket deflection? Today knowledge can be housed in many systems, how will users find the right information/solution? What sort of approval or flow might a new knowledge item (solution) need to take before exposed to users? Will knowledge items (solutions) be focused internally (agents) or self service first? 17 Knowledge Management is used to find the answer to an issue, by many roles (end user, agent, analyst…) Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management Are the same processes used by all groups, locations, and sites? Does the process formally exist today (documented)? Do they conform to industry best practices? If so, this is the foundation to start mapping to the current tool capabilities. Are the processes efficient? Are the hand offs to other groups and systems manual or automated? Can this be improved? How is the business organized for supporting teams be structured in the tool, centrally or de- centralized? What metrics, SLA, KPIs & reports are required going forward? Do not recreate reports just to create them, validate they are actually used and needed. Define and identify other processes that will interlock to “ticketing”, such as asset, change, or configuration management

18. not for distribution IBM Systems Middleware © 2015 IBM Corporation Workshop - Wrap Up  Ensure you have defined the data sets for the fields and data noted in the design document?  Have all use case flows been defined and no action items?  Are there any necessary fields to be added to the user interface? Be sure the documentation has recorded these fields. How to decide what is mandatory?  It is necessary to identify/discuss any required integrations for the implementation. The required integration(s) should be noted in the design document The overall design of the integration(s) should be a separate workshop, to allow the inclusion of the technical resources  Verify with workshop attendees if there are any open items?  Set date for validation of the design as it may take the documenter a few hours/days to ensure completeness before distribution.

19. not for distribution IBM Systems Middleware © 2015 IBM Corporation Design Validation 19  Once the design is complete and documentation is complete, ensure full organizational buy-in/sign off on configurations. Have a quick working session to share and explain the design and approach with any who may not have attended the workshop but will sign off on design.  Once configuration of the software has begun, engage with the users (all roles) to review early, often and always.  Design/configuration validation should occur in varying systems such as development and User Acceptance, or what ever the systems are called, which are pre-production.  Pre-production system(s) should be configured based on the design document to the exact letter. If configuration and tool capabilities conflict, the issue should be addressed straight away with the full team if possible or if necessary.

20. not for distribution IBM Systems Middleware © 2015 IBM Corporation Next Steps 20  Once validation is complete, configuration of the software should begin.  Training: Determine any training approach that may be needed for the overall project rollout.  Consider and define a rollout strategy, for go live.