Administrator Guide                               Version: 3.1Dec 08Doc ID: CDAG: 3.1:122008: 01
Legal Notices and Disclaimer              © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVED              No part of th...
Table of Contents       Legal Notices and Disclaimer.........................................................................
Table of Tables       Table 1-1: Acronyms and Conventions....................................................................
1.          About this Guide1.1      Intended Audience       The coDesk 3.1 Administrator guide is intended for applicatio...
About this Guide                                            determined width and indentation from                         ...
2.           About coDesk2.1      What is coDesk       coDesk is an enterprise class, web based, workflow enabled, service...
About coDesk                     iii.       Agent’s dashboard: For one who delivers service to the end user.              ...
About coDesk            3.   Easy to use for both customers and staff.            4.   Strong support for automating ITIL®...
About coDesk                20. Provision to set user specific personalized home pages.                21. Provision for e...
About coDesk            2.   Record, qualify, route, assign, categorize, prioritize, escalate, close and monitor          ...
About coDesk                6.   Ticker messages are displayed in the home page of the users to intimate the              ...
3.           Architecture       coDesk is an ITIL® centric service desk product to suit the business needs of the growing ...
Architecture                iii.   Change Management                iv.    Configuration Management        coDesk also off...
Architecture       coDesk uses several parameters like end user ticket rating, SLA breached etc to build       reports bas...
Architecture        Access control and permissions are role based and the user can navigate and perform        operations ...
4.           Terms Used in coDesk 3.1       coDesk is a web based Service Desk software application built on ITIL® standar...
Terms Used in coDesk 3.1        Approval Team        Approval Team includes group of users whose consent is required befor...
Terms Used in coDesk 3.1       Change Calendar       The various activities of the change manager, approval team, and impl...
Terms Used in coDesk 3.1        Service Rule according to the parameters provided. If an exact match is not found in the  ...
Terms Used in coDesk 3.1       Each and every asset is associated with a hierarchy label. Hierarchy label is used to      ...
Terms Used in coDesk 3.1        Vendors can be mapped to the service. Hence, if any ticket is logged to a service the     ...
Terms Used in coDesk 3.1       Problem Outcome       Problem outcomes are the end results obtained after resolving the pro...
Terms Used in coDesk 3.1        Region and Location refers to the Region and the Location of the user logging a ticket.   ...
Terms Used in coDesk 3.1       Response time refers to the time taken by the agent to accept / reject / assign the ticket ...
Terms Used in coDesk 3.1        Service Code        Service Codes are pre fill codes defined in the application. The servi...
Terms Used in coDesk 3.1       For each service in coDesk, there should be one Service Provider. One Service Provider     ...
Terms Used in coDesk 3.1        State Flow        State flow refers to the next possible states that can be assigned to a ...
Terms Used in coDesk 3.1       Vendors       Vendors are organizations who are involved along with the agents while resolv...
5.          Incident Management in coDesk                                                       3.1       According to ITI...
Incident Management in coDesk 3.1                14. Support for Root Cause Analysis                15. Ability to record ...
Incident Management in coDesk 3.1       Incident ticket can be logged by the end user or the agent on behalf of other user...
Incident Management in coDesk 3.1        satisfying all the three conditions of Team, Team Role and Shift are evaluated an...
Incident Management in coDesk 3.1       Knowledgebase is a database repository which contains articles published by differ...
Incident Management in coDesk 3.1        assigned the SLA Start state. The SLA Start state can be assigned in any of the f...
Incident Management in coDesk 3.1       If the ticket is re opened at 5.30 P.M and if the service is configured to include...
Incident Management in coDesk 3.1        action exceeds the configured SLA time then the SLA is said to be breached for th...
Incident Management in coDesk 3.1       the mailbox settings. The configured mailbox can then be associated with the prefi...
6.         Problem Management in coDesk                                                     3.1       According to ITIL® b...
Problem Management in coDesk 3.1                13. Monitoring Problem and Known Error through their life cycle.          ...
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Co desk 3.1 administrator guide
Upcoming SlideShare
Loading in …5
×

Co desk 3.1 administrator guide

1,267
-1

Published on

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,267
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Co desk 3.1 administrator guide

  1. 1. Administrator Guide Version: 3.1Dec 08Doc ID: CDAG: 3.1:122008: 01
  2. 2. Legal Notices and Disclaimer © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVED No part of this document can be reproduced, or transmitted, or stored in any form or by any means without the prior written approval of the copyright owners. Due care and diligence has been taken in preparing this document. Network Solutions Private Limited, its subsidiaries, distributors, dealers, re-sellers, or licensors shall not be held responsible for any mistake that may have inadvertently crept in In no event shall Network Solutions Private Limited, its subsidiaries, distributors, dealers, re-sellers, or licensors shall be liable for any direct, consequential or incidental damages in connection with or arising from the use of this document or the product accompanying it ITIL® is a Registered Trade Mark of the UK Office of Government Commerce. All other trademarks and copyrights as referred in this document are the property of their respective ownersContact Information Network Solutions Private Limited - An IBM company th 32, Grape Garden, 6 block th 17 H Main Road, Koramangala Bangalore - 560 095 Tel:+91-80-2550 8365 / 2553 5228 Fax: +91-80-2552 0949 / 2552 3379 E-Mail: softwaresupport@netsol.co.in Website: http://www.netsol.co.in
  3. 3. Table of Contents Legal Notices and Disclaimer.......................................................................................... 2 1. About this Guide ....................................................................................................... 7 1.1 Intended Audience .......................................................................................... 7 1.2 Acronyms and Conventions .......................................................................... 7 1.3 Contents of this Guide.................................................................................... 8 2. About coDesk............................................................................................................ 9 2.1 What is coDesk................................................................................................ 9 2.2 What’s New in coDesk 3.1 .............................................................................. 9 2.3 Features of coDesk 3.1 ................................................................................. 10 2.4 Benefits of coDesk 3.1.................................................................................. 12 3. Architecture............................................................................................................. 15 4. Terms Used in coDesk 3.1 ..................................................................................... 19 5. Incident Management in coDesk 3.1..................................................................... 33 6. Problem Management in coDesk 3.1 .................................................................... 43 7. Change Management in coDesk 3.1 ..................................................................... 47 8. Configuration Management in coDesk 3.1 ........................................................... 53 9. Dashboard view in coDesk 3.1 .............................................................................. 59 10. Knowledgebase ...................................................................................................... 61 11. Index......................................................................................................................... 65 © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 3 of 65
  4. 4. Table of Tables Table 1-1: Acronyms and Conventions............................................................................................. 8 Table 1-2: Contents of the guide....................................................................................................... 8 © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 5 of 65
  5. 5. 1. About this Guide1.1 Intended Audience The coDesk 3.1 Administrator guide is intended for application administrators who would configure and create workflows for service support in coDesk 3.1. This guide provides a concise description about the product and the various terms involved in them.1.2 Acronyms and Conventions Activity / Detail Usage in the guide Chapters All chapters of the guide start on an odd page. References to screens, dialog boxes, References are in bold text. controls and other objects. Instructions All instructions are numbered. If there are sub instructions they are numbered in lower roman numerals. Note text All admonishments such as caution, note appear within a two sided bordered table. Image / screen numbering Screens in the guide are numbered in a sequence. The first number indicating the chapter number and the second number indicating the screen order in that chapter. The screen numbering is followed by the figure title. Tables Tables in the guide have a pre- © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 7 of 65
  6. 6. About this Guide determined width and indentation from the left margin. Tables are numbered in a sequence. The first numbers indicate the chapter number followed by the order of the table in that chapter. The number is followed by the table title in bold. Reference to the application name In this document, “coDesk” refers to and version the coDesk application version 3.1. Table 1-1: Acronyms and Conventions1.3 Contents of this Guide Chapter Description Chapter 1 A brief introduction about the intent of About this guide the guide, acronyms used in the guide and its contents. Chapter 2 Speaks about the features and About coDesk 3.1 benefits of coDesk Chapter 3 Brief introduction about the various Architecture components of coDesk 3.1 Chapter 4 Introduces the various terms involved Terms used in coDesk 3.1 in coDesk 3.1 for better understanding the product Chapter 5 Explains the overview of incident Incident Management management in coDesk. 3.1 Chapter 6 Briefs about the overview of problem Problem Management management in coDesk 3.1 Chapter 7 Briefs about the overview of Change Change Management management in coDesk 3.1 Chapter 8 Briefs about the overview of Configuration Management Configuration management in coDesk 3.1 Chapter 9 Briefs about the overview of Knowledgebase Knowledgebase in coDesk 3.1 Table 1-2: Contents of the guidePage 8 of 65 coDesk 3.1 Administrator Guide
  7. 7. 2. About coDesk2.1 What is coDesk coDesk is an enterprise class, web based, workflow enabled, service desk application that automates ITIL® best practices for Service Support. coDesk is designed for external and internal service support for a variety of domains like IT help desk, service request automation, issue management, etc. It provides configurable and flexible workflow and routing capabilities that allows service delivery automation and enables quick resolution of customer support issues2.2 What’s New in coDesk 3.1 coDesk offers enhanced support for ITIL® best practices for Service Support. New features and capabilities include - 1. The database for coDesk can be deployed on IBM DB 2® V 9.5 Database and Microsoft® SQL Server® 2005 Database. 2. The coDesk is enhanced to display the reports based on dashboard views. The data in the dashboard view are displayed in Pictorial, Graphical and Tabular formats. There are five pre-defined dashboards based on the type of users in coDesk. i. Helpdesk Administrator’s dashboard: For one who manages the helpdesk function and keeps track of the loads, tool availability and performance. ii. Service Administrator’s dashboard: For one who manages services and is responsible for service delivery and its performance. © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 9 of 65
  8. 8. About coDesk iii. Agent’s dashboard: For one who delivers service to the end user. iv. End User’s dashboard: For one who receives the service from the service desk. v. Executive dashboard: For stakeholders who are interested in the services offered by the service desk and can make informed decisions based on the performance of the service. 3. Users can be removed from different dependent objects. 4. Enhanced SNAPPiMON Integration i. Provision to map time zone with the SNAPPiMON Instance. ii. Provision to utilize the asset attributes for ticket logging. iii. Provision to define ticket workflow on occasions of SNAPPiMON Open and Close events. iv. Provision to customize the ticket description with ability to map SNAPPiMON specific fields. 5. Provision to view audit summary of Configuration masters to know the actions performed on the masters. 6. Change Request is enhanced with the allocation feature. While allocating the ticket, permissions to modify the ticket parameters like More Fields, Attachments and Queries can be provided. Based on the permissions provided the agent can view the modify ticket details. 7. Super Administrator can now view user audit report. Information like Login/Logout date/time, User Authentication, User details(login name, organization, department, workgroup, designation, role, region, location and time zone) and Log details(Invalid/Successful login date/time) of each valid user in coDesk. 8. The Change password and Forgot password are available as a part of Email template. Any changes in the user details or the user information will be notified to the user through email. The Change password and Forgot password templates can be customized.2.3 Features of coDesk 3.1 1. Multi-touch suite that automates the complete support and service life-cycle-call logging, qualifying, assigning, categorizing, prioritizing, routing, escalating, tracking, closing, reporting and monitoring. 2. Completely web-based service support system that manages tickets from submission to closure.Page 10 of 65 coDesk 3.1 Administrator Guide
  9. 9. About coDesk 3. Easy to use for both customers and staff. 4. Strong support for automating ITIL® best practices for Service Support including Incident Management, Problem Management, Change Management and Configuration Management. 5. Scalable and Flexible engine - allows coDesk to suit various needs – Case Management, Issue Management, Service Desk, Helpdesk, Customer Care, Change Management, Bug Tracking etc. 6. coDesk provides Web & Email based call logging. Tickets can be routed based on multiple attributes of the ticket. These attributes include Category, Classification, Severity, Impact, Location, Time of the Day, Day of the week, etc. Intelligent call router that auto-routes and assigns a ticket to the right resource based on Team, Team role, Agents and Shifts etc, thus resulting in faster resolution. 7. Strong and Flexible E-mail and SMS notifications triggered at every stage of the process. 8. Built-in Knowledgebase allows customer self-service and hence lower call loads and enables dynamic growth of organizational knowledge. 9. Multiple pre-defined reports generate reports for specific functions like list of closed tickets, engineer performance, status summary of different tickets, re- opened tickets etc. 10. Supports multiple instances of coDesk on a single system. 11. Integrated support for Incident, Problem, Change and Configuration Management, and Service Level Management for Support Processes. 12. Scalable, High Performance solution and Web based User Interface. 13. Supports Windows 2003 Server OS and MS-SQL Server® 2005 database / IBM DB 2® database and IBM DB 2® on Linux. 14. Supports multiple Time Zones. Users can be associated with a timezone and view all data in the timezone they belong to. Users can also change their timezone as part of their profile updates. 15. Asset service has the option to define permissions for provider and receiver groups for viewing assets. Show and Hide permissions can be set for all the assets mapped to the service. 16. Users can view the email call logging mode details in the Audit page. Call logging mode in the audit page will display the email id of ticket logger who is not configured in coDesk and the mapped coDesk end user name. 17. User Definition has the Advanced Search option to search for users by adding multiple conditions. 18. Assets and Users can be exported in CSV format. 19. Online help is provided across all the modules.coDesk 3.1 Administrator Guide Page 11 of 65
  10. 10. About coDesk 20. Provision to set user specific personalized home pages. 21. Provision for end users to rate the call directly from the Incident Closure mail. 22. Supports multiple instances of SNAPPiMON to integrate into coDesk. Event template has been introduced to capture event patterns from SNAPPiMON. Multiple Event Templates can be mapped to a coDesk service. 23. Work Queues has the New and Transferred tabs that display the tickets in queue and the transferred tickets with the total number of entries. 24. Transfer Analysis report in Problem and Incident services. This report tracks every action in the cycle of ticket transfer and calculates the percentage of successful transfers, average transfer per ticket, and the Maximum transfers on any ticket. 25. Paging control to support MS SQL 2000, MS SQL Server® 2005 and IBM DB 2®. 26. Provision to save the queries per user per report under Analytics. The saved queries will generate reports based on current dates. 27. The Turn Around Time report in Change Requests include ‘Scheduled Variance’ column. 28. Users can customize columns in the list views provided permissions are defined for them in the User Template. 29. Provision to enable or disable the Request Types globally. 30. Ticket Number can be generated even before the ticket is submitted. Once the ticket logging is cancelled, the ticket is considered as ‘abandoned’. 31. Agents can view the number of ‘Tickets in Queue’ and the ‘Active Tickets’ (pending) at the time of Transfer Action. 32. Two filters under Pending Tickets, namely Transferred in, Allocated out and the respective icons to view the tickets that are transferred or allocated to agents. 33. Additional Notes can be added even after closing the call. 34. Provision to modify and delete the assets through bulk operations. 35. Multiple searches can be done by choosing filters across all pages.2.4 Benefits of coDesk 3.1 Centrally manage all issues & requests with comprehensive tracking 1. coDesk is a multi-touch suite that automates the complete support and service life-cycle. You can centrally track and manage multi-channel requests - phone (Verbal), email, Enterprise Management System (EMS) as well as web forms.Page 12 of 65 coDesk 3.1 Administrator Guide
  11. 11. About coDesk 2. Record, qualify, route, assign, categorize, prioritize, escalate, close and monitor issues and requests throughout the service life cycle. Improve your call flow and operations 1. Track adherence to service level agreements (SLA). Manage by exception. 2. Organize Agents into teams and track performance by agent or by teams. Supports multiple teams at multiple locations. 3. Provides multiple tenancy support for service providers. 4. Manage the change requests with logging, approval, delivery and re- record process. 5. Implement your Service Provider Group’s specific workday calendar (Service Window). 6. Enable quick qualification of tickets to determine the organizations obligation to provide support or service. 7. Send customizable email alerts and notifications, including mass emails. 8. Log issues / requests through emails. Improve First Time Resolution 1. Track ticket escalation, re-assignment, transfers and also re-occurrence and hence address critical issues. 2. Track staff performance and hence identify re-training needs. 3. Records all issues/problems in a centralized database to create a searchable, sort able, historical archive from which support staff and developers can identify patterns and recurring problems to facilitate rapid resolutions. 4. Serves as a resource for known problems and their resolutions, allowing system administrators/support staff to be proactive in identifying and addressing potential problems. Empower staff and users with Self-service 1. Built-in knowledgebase provides anytime / anywhere access to organizational knowledge. 2. Provides the Agents and customers the ability to search knowledgebase for finding solutions – without contacting the support center. 3. This results in lower call load, increased productivity and lower operational costs. 4. Create a self-learning organization. 5. Bulletin Board is introduced in coDesk to post and reply messages based on permissions.coDesk 3.1 Administrator Guide Page 13 of 65
  12. 12. About coDesk 6. Ticker messages are displayed in the home page of the users to intimate the users with status of various elements. Provide customer service 24/7 1. Empower customers with the ability to submit and track their own issues. 2. Keep customers informed with email status notifications regarding the status. 3. Analyze customer feedback on service response and resolution. Efficiently manage resources 1. Permits support staff managers to coordinate, assign and delegate problem solving among their staff based upon workload and expertise. 2. Managers can divide and assign the workload based upon the skill and knowledge levels of their support personnel.Page 14 of 65 coDesk 3.1 Administrator Guide
  13. 13. 3. Architecture coDesk is an ITIL® centric service desk product to suit the business needs of the growing IT infrastructure. The various components and features of coDesk are shown in the figure below. Figure 3-1: coDesk Summary coDesk provides support for the following process i. Incident Management ii. Problem Management © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 15 of 65
  14. 14. Architecture iii. Change Management iv. Configuration Management coDesk also offers flexible routing and effective permissions and access control. It provides well organized knowledgebase which maintains the articles published by different users. Integrated Configuration Management Database CMDB provides effective and efficient asset management. coDesk offers effective reporting and analysis, notifications are intimated to users while performing every activity and SLA; escalations are enabled to offer quick resolution of customer tickets. The logical view of coDesk components is displayed as shown below Figure 3-2: coDesk Logical components Web Portal Web Portal is used for user management and application configuration. Several actions and activities can be performed using the web portal Analytics and Dashboards coDesk is used for effective analysis of the efficiency of the Agents in resolving the ticket. It offers several reports to quickly and correctly interpret the ticket management process.Page 16 of 65 coDesk 3.1 Administrator Guide
  15. 15. Architecture coDesk uses several parameters like end user ticket rating, SLA breached etc to build reports based on them. Dashboards provide a pictorial, graphical and tabular representation of data in coDesk to analyze the reports easily. Notifications and Alerts coDesk offers effective and efficient email alerts and notifications triggered at every stage of the call flow process. coDesk can be configured to provide alerts before SLA breaches Status change etc. These notifications and alerts provide information to the end users who logged the ticket and the other configured users. Escalation notifications can be sent to superiors so that the superiors will act on the ticket and the ticket can be resolved to the entire satisfaction of the customers. Incident Management, Problem Management and Change Management Incident Management, Problem Management and Change Management are various processes that can be carried out by coDesk. coDesk is completely ITIL® centric and all these functions are carried out based on best practices and recommendations of ITIL®. User Management User management in coDesk is easy to configure and use. The users can be created / deleted / modified. Users can be made inactive if they are not needed. Users can belong to roles that correspond to either agent or end user role types. Service Provider is independent of the organizations and can accommodate users of several organizations to belong to a common Service Provider. Knowledge Base The Knowledge Base is a data store repository that is used to store and share FAQs, workarounds, troubleshooting tips and articles. Commonly encountered issues can be documented in knowledge base. The agent and the customer can refer the knowledgebase to solve the issues. Many new technologies can be documented and stored in knowledgebase and thus it offers a self help facility. Bulletin Board Bulletin board messages can be posted and replies can be given to those messages based on permissions. This enhances the communication between different users of the application. Ticker Messages Ticker messages appear in the home page of the users and are based on permission centric. These messages provide warning alerts and information about the various issues. SLA Engine Service Level Agreements are the maximum time limits within which the ticket must be responded or resolved. The SLA engine tracks and escalates Response and Resolution SLAs. Access Control and PermissioncoDesk 3.1 Administrator Guide Page 17 of 65
  16. 16. Architecture Access control and permissions are role based and the user can navigate and perform operations in the application based on permissions. Integrated CMDB Configuration Management Database (CMDB) is integrated with IBM/Netsol Asset Manager to offer better service. Process Manager Process Manager interacts with each of the components and maintains a flow between the processes.Page 18 of 65 coDesk 3.1 Administrator Guide
  17. 17. 4. Terms Used in coDesk 3.1 coDesk is a web based Service Desk software application built on ITIL® standards, hence most of the terminology used and applicable are ITIL® centric. However the user needs to be familiar with some of the key concepts associated with the product before using the application. The purpose of this section is to familiarize users with coDesk specific concepts and terminology. Accept Action When a ticket is logged by the end user, the ticket is placed in the work queue of the agent. The agent working on the ticket needs to perform an Accept action to work on the ticket. Actions Actions are pre defined and it is essential to map the actions to the status. Acknowledge Resolution Acknowledge resolution an activity if configured for a service allows the agent to manually specify the Resolution time. The resolution time specified manually during acknowledge resolution activity or the time at which the resolve action is performed can be taken as the actual resolution time depending on the agent’s decision. The agent can override the resolution time any number of times before the ticket is closed using resolution acknowledge activity. The time provided during acknowledge resolution must be greater than the ticket logged time. Acknowledge Response Acknowledge Response activity if configured for a service, will allow the agent to manually specify the response time for the ticket. In such circumstances, performing accept action will only transfer the ownership of the ticket. Hence it is necessary to perform acknowledge response activity before resolving the ticket. The time manually specified during acknowledge response must be greater than the ticket logged time. The acknowledge response activity can be performed any number of times and the response time can be modified before closing the ticket. © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 19 of 65
  18. 18. Terms Used in coDesk 3.1 Approval Team Approval Team includes group of users whose consent is required before starting the implementation process for a change. However the change manager can override the approval of the members of approval team if required. Users of the approval team can belong to any organization. Many approval teams can be configured and the change manager can select the needed approval team for the ticket. There are two types of approval team namely Change Advisory Board and Change Advisory Board Emergency Committee. Under normal situations, the CAB members can approve / disapprove the RFC. Under emergencies, CAB E/C can be involved for the approval process. The change request has to be approved before it is implemented. Assets Configuration Management provides a logical model of infrastructure or service by identifying, controlling, maintaining, verifying and reporting assets in existence including their version, constituent components and relationship. Assets include all components that build the infrastructure of the organization. Auto Closure Time After a ticket is resolved, the ticket has to be closed. The end user or the agent can close the ticket. If the ticket is not closed by the agent or the end user the ticket gets closed automatically after the interval defined by auto closure time. Bulletin Board Bulletin Board messages can be posted and replies can be provided by users based on permissions defined in the user template. Create, modify delete, reply, modify reply and delete reply can be performed by users based on permissions. This enhances the communication between the users of the application. Call Modes Call Modes refer to the various call modes by which the end user can log a ticket. Some of the call modes are Web Form, Phone, SMS, email etc. The application currently supports web based, email and SMS based call logging. Category Category, sub category and classification are used to identify a ticket. There can be many sub categories under a category. But classification is independent of category and sub category. Category, sub category and classification are used in Service Rule to uniquely route the ticket to the associated agent. Change Artifacts Change Artifacts are the type of attachments that can be added by agents while working on the Change Request tickets. The agent while adding activity notes on a change request ticket can add attachments of the configured artifacts type to support service notes.Page 20 of 65 coDesk 3.1 Administrator Guide
  19. 19. Terms Used in coDesk 3.1 Change Calendar The various activities of the change manager, approval team, and implementation team can be scheduled and reminders and notifications can be sent to the configured users at the configured time using change calendar option. Change Origin Change Origin refers to the activity which initiated the change. Change origin and change reason are provided by the end user at the time of logging the ticket. Change Outcome Change Outcome is the result obtained after implementing the approved change. The Change manager after performing the approved change will provide change outcome before closing the ticket. All the possible change outcomes must be defined before using the application. Change Override Reason Change Request ticket must be approved before implementation. If the decision made by the approval team is not satisfactory then the change manager can himself approve or disapprove the change request. The decision made by the change manager is final if he has permission to override. During such situations, the change manager has to specify the reason for overriding approval team’s decision. Change Reason Change reason is provided by the end user while logging a change request ticket. For example, if there is a network failure, then change reason would be “not able to connect to network”. Change origin would be “network failure” and the effect of Non implementation would be “All users in the network will not be able to connect to network” and finally after resolving the ticket, the change outcome would be “Network working properly” Change Reminder The change calendar will schedule the various activities for change manager, approval team and implementation team. The start time and the end time for the activity must be provided and the change calendar can be designed to provide reminder before starting the activity and before ending the activity. This helps to complete the process in time. According to the planned start and end dates the implementation team and the change manager can act and implement the change. Closure When a ticket is closed, the agent closing the ticket needs to provide closure comments. This helps the agent to keep track of the various activities carried out while closing the ticket. You can define the closure codes that are used while closing the ticket. Default Operational Rule The user logs a ticket for a service, providing details like category, sub category, classification, impact, urgency, region and location. The ticket looks for the best matchcoDesk 3.1 Administrator Guide Page 21 of 65
  20. 20. Terms Used in coDesk 3.1 Service Rule according to the parameters provided. If an exact match is not found in the Service Rule, it looks for the routing precedence configured for the service. If no match is found according to the routing precedence defined the ticket will follow the default Operational Rule. Denied Service Name The user of a service receiving organization can be denied to log tickets for a particular service. This can be configured in Configurations > Permissions > Service Receiver Template. If Open action is not allowed for a particular user, for a specific service, then that user can log tickets for that particular service. Department coDesk uses department to configure the department of the users in various organizations. Each user in coDesk is associated with a department in an organization. Designation Every user in an organization is associated with a designation. coDesk defines the designations of the users using this option. Domain When a user is authenticated by Active Directory mode, domain passwords need to be provided to check the credentials. An Active Directory authenticated coDesk user will provide the user name and the Active Directory password while logging in to the application Emergency Change Emergency Change is of great significance and its implementation at the earliest is necessary to restore the proper functioning of the various activities in an Organization. Emergency change requires the approval of Change Advisory Board (CAB) Emergency Change (E/C) before implementing the change. The change cannot be implemented without receiving the approval. Escalation Escalation is the process of passing information through email to the superiors or experts if a ticket is not resolved within the specified time duration. Escalation Level There can be many escalation levels. The application can send escalation alerts to different people at different escalation time intervals. Force Own Force own depends on the permissions provided for the agents in the provider template. The agent will be able to force own the ticket by searching the ticket from the title bar in the home page. Hierarchy LabelsPage 22 of 65 coDesk 3.1 Administrator Guide
  21. 21. Terms Used in coDesk 3.1 Each and every asset is associated with a hierarchy label. Hierarchy label is used to identify the position of the asset in an organization. Four levels of hierarchy labels can be provided for each asset. Holiday Window Holiday window is used to define Holiday dates and the business hours of the organization during the holidays. You can configure Holiday windows in different timezones. Identification Codes Identification codes are used to identify a problem. Identification code is selected by the user at the time of logging a problem ticket. Implementation Team Implementation Team is group of change managers who will implement the change request approved by the members of the approval team. After implementing the change the members of the implementation team will provide work order notes to intimate the ticket owner about the change. Known Error Database (KEDB) Known Error Database is the database containing temporary work around and permanent solutions of some possible known errors. Known Errors Problem management deals with finding the underlying cause for multiple incidents. When the root cause for the problem is identified, temporary work around and solution are developed, problem becomes a known error Major Change Major change is a classification of RFC which is of more importance and approval from the members of the approval team is required. Major change requires approval from the members of Change Advisory Board (CAB) before implementing the change. Major Incident There can be many secondary incident tickets that are related to a primary incident ticket. Finding a solution to the primary incident will in turn provide solution to the secondary incidents. The primary incident is called the major incident and the other incidents that are related to this primary incident are called minor incidents. Closing the major incident will close all the related minor incidents Manager Managers are associated with the users in the application. Each user can have several managers associated for different functions. Map VendorcoDesk 3.1 Administrator Guide Page 23 of 65
  22. 22. Terms Used in coDesk 3.1 Vendors can be mapped to the service. Hence, if any ticket is logged to a service the ticket can be assigned to the vendor of the mapped service only. Minor Change Minor change is of very little importance and hence any change manager of the Service Provider can approve the minor change. Minor Incident Minor incidents are secondary incidents which have a common root cause. There may be many tickets which have the same root cause. All the tickets can be resolved by resolving an incident ticket. The tickets that are related and resolved by solving the primary ticket are called minor incidents. Navigation Template Navigational templates are used to grant navigation permission to the user roles that have been configured in the application. Based on the permissions granted, the user will be able to perform the actions using the application. The administrator can decide on the module headings and subheadings that should appear on the application screen for different roles. It is also possible to provide user specific navigation permission using this option. Non Implementation The end user while logging a change request ticket can provide the effect of not implementing the change. The agent working on the ticket can understand the significance of the change. All the possible effects of non implementing the change request tickets need to be defined before logging change request tickets. Open Action When a ticket is logged, the default action for the ticket is Open. Open action is not available for the user. Organization coDesk stores the organizations of users. The organizational details like the Contact person, telephone number, email address and fax number help to uniquely identify the organization of the user using the application. Proactive Problem Proactive problem management is the process of identifying and solving problems and known errors before incidents occur. The problem is foreseen and is resolved even before its actual occurrence. Problem Codes Each problem is associated with a root cause, temporary work around and a permanent solution. A problem code is provided for each root cause, temporary work around and permanent solution. You can then associate these problem codes to Known errors and store them in Known Error Database (KEDB).Page 24 of 65 coDesk 3.1 Administrator Guide
  23. 23. Terms Used in coDesk 3.1 Problem Outcome Problem outcomes are the end results obtained after resolving the problem tickets. The agent while resolving the problem ticket needs to specify the outcome of the ticket. All the possible outcomes must be predefined to enable the agent to use them while resolving a problem ticket. Projects Projects are used in Asset Management for mapping the assets. Provider Template Provider template provides permissions for the actions, activities and views for the users associated with a specific service from a particular service provider. The first service provider template created for any service is the default template. User specific actions, views and activities can also be defined and the users can be associated with the templates. Ticket proxy logging view can be defined for provider templates. The tabs and the fields to be displayed while logging a ticket can be configured using this option. Asset Service Action Mapping can be defined for asset service provider template. Queries When a problem or a change request ticket is logged by the user, the user can provide clear picture of the situation by answering the queries. Queries can be defined separately for problem and change request service types by the administrator. The end user can select queries and provide answers for them while logging a ticket. The answers provided by the end users help the agent in resolving the ticket. Rating After a ticket is resolved by the agent, the customer can rate the ticket according to the satisfaction of the service received for the ticket. The rating determines the efficiency of the agent working on the ticket. Reactive Problem Reactive Problem refers to the process of solving problems in response to one or more incidents. By default the problem tickets logged are reactive in nature. Receiver Template Actions, activities and views can be defined for the service receiver. The first receiver template created for a service is the default template. Users can be associated to non default templates and user specific actions, activities and views can be defined. Ticket logging view can be defined for receiver templates. The tabs and the fields to be displayed while logging a ticket can be configured using this option. Recurring Escalation Escalation can be defined to repeat after specific time duration. The time interval for the escalation alert message to repeat is called recurring time. Recurring frequency is the number of times the escalation alert messages need to be sent. Region and LocationcoDesk 3.1 Administrator Guide Page 25 of 65
  24. 24. Terms Used in coDesk 3.1 Region and Location refers to the Region and the Location of the user logging a ticket. The Region and Location must be associated with the Service Rule for resolving the ticket. Time zones must be associated with the region and location. All the locations under a region will have same timezone. Reject Action If the agent working on the ticket considers the ticket to be inappropriate, then the agent can perform reject action before working on the ticket. Accept, reject and assign are the three actions that an agent can perform before working on the ticket. Reject Reason The agent working on the ticket can reject the ticket from the work queue. While rejecting the ticket the agent needs to specify the reject reason. All the possible reject reasons must be configured ReOpen Reason The ticket can be reopened by the agent who was working on the ticket or by the end user who logged the ticket. When the ticket is reopened, it is necessary to specify the reason for reopening the ticket. Reopen Action The agent or the end user who logged the ticket can re-open the ticket. While performing a reopen action it is necessary to specify the reason for reopening the ticket. Resolution After the ticket is resolved, the agent must provide the resolution code. The resolution code helps the agent to keep track of the resolution outcomes for the ticket. You can define the resolution codes before using the application. Resolution Time Resolution time refers to the time elapsed between the SLA start state and the SLA end state discarding the time duration for which the ticket was placed in SLA Hold state. By default the SLA start state is Opened and the SLA end state is the time at which the resolve action is performed on the ticket. If the resolution time taken by a ticket exceeds the time specified in the SLA, then the SLA for the resolution time is breached. Resolution time refers to the time elapsed between the SLA start state and the time when a resolve action is performed on the ticket discarding the time duration for which the ticket is put in SLA hold state. Resolve Action Agent will need to resolve the ticket after diagnosing the issue and provide a solution. Once the Resolve action is performed on the ticket, the ticket can be either closed or reopened only. Response TimePage 26 of 65 coDesk 3.1 Administrator Guide
  25. 25. Terms Used in coDesk 3.1 Response time refers to the time taken by the agent to accept / reject / assign the ticket from the time the ticket is logged. The above actions must be undertaken before the response time configured in the SLA elapses. If the response time exceeds the configured Response SLA time, then the SLA for the response time is breached. Request Types Request Types are configured for incident tickets. There are four predefined request types. The user can change the label names to suit their needs. Request types appear in the ticket logging page based on permissions configured in Ticket Logging view of the receiver template. Role Types There are two different role types in coDesk. They are agent and the End user. The agent is a person who is working on the ticket (Service Provider). The end user is a person who is logging a ticket (Service Receiver). You can configure users of any of these two role types. Each user in coDesk is associated with a First name, Last name, User name, Password, Organization, Department, Work Group and Role. The contact details of the users like Contact address, Phone number, Region, Location and Search code is also provided. Root Cause While resolving an incident ticket, the agent needs to specify the root cause associated with the ticket. All the possible root causes for various incidents must be pre configured before using the application. Self Registration Users can register themselves in the application using self registration. All the self registered users will be part of end user role type. The self registered users can be associated to different services. Service Each service is associated to a service type, service group, Service Provider and Service Receiver. All the configurations selected for the Service Group are available for the service. You can select the Category, Sub category and Classification associated with the service. You can also select the Impact, Urgency and Priority associated with the service. You can select the Actions, Status codes and the SLA for the service. The incident service can also be configured for Acknowledge response and Acknowledge resolution activities. You also need to define the Default Operation Rule and the additional fields for the service. Service provider Template and Service Receiver Template must be configured for a service.coDesk 3.1 Administrator Guide Page 27 of 65
  26. 26. Terms Used in coDesk 3.1 Service Code Service Codes are pre fill codes defined in the application. The service codes can be configured in the application to which the services and mailboxes are associated. These codes can be selected while logging the tickets for the incident, problem and change request service. That will automatically populate the other fields required to log the ticket. The codes can also be mapped to the mailboxes for email call logging of the incident tickets. These codes are provided in the Subject box while logging an incident ticket through email. In addition, if the message is not provided while logging the ticket, then the default message is sent in the email that is configured in the code. Service Rule A service can have any number of Service Rules. Each Service Rule is identified by a unique combination of Category, Sub category, Classification, Region, Location, Priority and Operational Rule. When a ticket is logged for a service, a Service Rule corresponding to the ticket logged is searched and the corresponding Operational Rule is selected. Depending on the Operational Rule, Service Window and the Routing Rule are selected and the ticket is routed to the agent. Service Group Service Group is a collection of related services. The categories, classification related to the service group, impact, urgency and priority related to the service group, the status codes related to the service group and the additional codes like root cause reason, closure and re-open reason can be configured. The fields selected for a service group can only be used by services which are a part of the service group. Service Level Agreement (SLA) / Operational Level Agreement (OLA) Service Level Agreement (SLA) defines the response time, resolution time and SLA breach time for Incident tickets. OLA defines the response time, resolution time and SLA breach for Problem tickets. SLA Response Reminder The Administrator can configure the application to provide a reminder before the SLA for the response time for a specific Service Rule breaches. For example if the value is provided as 1hrs, and the response time for the ticket according to the Service Rule is 4 P.M then a reminder message is sent to the agent working on the ticket by 3 PM Service Notes type Service Notes are provided by the agents working on the ticket while performing various actions and activities on the ticket. This helps to keep track of the various actions and activities that are performed to resolve the ticket. All the possible service notes types must be defined before using the application. Service Providers Service Providers are the group of users who may belong to any organization, department and role. Service Provider is group of users who provide a particular service.Page 28 of 65 coDesk 3.1 Administrator Guide
  27. 27. Terms Used in coDesk 3.1 For each service in coDesk, there should be one Service Provider. One Service Provider can provide multiple services. Service Receivers Service Receivers are group of users who seek service. The Service Receivers can belong to any organization, department, work group and role. For each service there should be one Service Receiver associated with the service. The Service Receivers can log tickets to the service and the ticket can be serviced by the users of the Service Provider associated with the service. A service receiver can be part of multiple services. Service Window Service Window refers to the business hours of the organization. You can define different working hours for each day of the week in a service window. A graphical representation of the different working hours for day of the week is displayed. You can associate a timezone with the service window when you need to create service windows for agents who work in different timezones. Service Window Group Service Window Group is a combination of Service Window and Holiday Window for a particular time period. You can group service windows based on timezones. Shift Shift refers to the working hours of the users in an organization. The users can work for any number of days. The operational start time and end time can be configured separately for all days of the week. The user can be associated with a shift while building a team. SLA End State The agent needs to perform a resolve action, before closing the ticket. The resolve action can be mapped to any state. When the agent performs the resolve action, the ticket is automatically assigned the corresponding mapped state and the SLA clock stops. The agent cannot assign any state to end the SLA. The agents need to perform a resolve action to end the SLA. SLA Hold State When a ticket is assigned SLA hold state, the SLA clock stops and the SLA clock resumes after the ticket is assigned a non hold state. SLA Start State When a ticket is assigned the SLA Start State, the SLA clock starts ticking. The SLA Start State can be different for each service. Standard Change Standard Change is a pre approved change request. It is a basic change and hence by default the standard change is approved.coDesk 3.1 Administrator Guide Page 29 of 65
  28. 28. Terms Used in coDesk 3.1 State Flow State flow refers to the next possible states that can be assigned to a ticket. It defines the flow of the ticket. For example, if Begin state is Accepted, the possible next states for the ticket can be defined. So when the agent assigns accepted state for a ticket then according to the end states defined in the state flow the agent can select the other states. Team Team refers to a group of people involved in providing service. A SERVICE PROVIDER can have any number of teams. You can select and set the hierarchy of the team roles before configuring team members for a team. You can build a team by selecting the configured team roles and shifts and associate it to users. Team Role Team roles are created to build a hierarchy in the team. All the team roles must be defined before associating them with the corresponding teams. Team roles play an important role while performing certain actions like assign. The agent can assign the ticket to other agents who are peers are agents lower in the hierarchy. While performing Search by Team the agent will be able to view the tickets of the agents who are peers or lower in the hierarchy. Ticket Status The agent working on the ticket can put the ticket to any ticket status. The default status of the ticket when it is logged is opened. The other status that can be assigned to a ticket before it can be closed must be defined using this option. Ticker Messages Ticker messages appear in the home page of the application based on the permissions defined in the user template. Different icons can be associated to different ticker types. Transfer Reason A ticket can be transferred from one agent to another agent within the same Service Provider. When an agent transfers the ticket, the agent needs to specify the reason for transferring the ticket. The agent to whom the ticket is transferred can either accept the ticket or reject the ticket. If the ticket is accepted, the ownership of the ticket is modified and if the agent rejects the transferred ticket, then the owner is not altered. User Template User templates define the permissions for ticker and the bulletin board messages for the users. Urgency and Impact Urgency and Impact are provided by the end users while logging a ticket. These features help in determining the priority of the ticket. Urgency refers to the necessity of the service and the impact refers to the effect of the problem. Based on Urgency and Impact a priority matrix is constructed for resolving the ticket.Page 30 of 65 coDesk 3.1 Administrator Guide
  29. 29. Terms Used in coDesk 3.1 Vendors Vendors are organizations who are involved along with the agents while resolving the ticket. The contact details of the vendor are configured in coDesk using this option. Vendor Escalation Each vendor is associated to particular service. The ticket is routed to a vendor depending on the service for which it is associated. Vendor SLA is defined for each vendor. It specifies the time duration within which the issue has to be resolved by the vendor. The resolution time and the escalation time for each service and each vendor corresponding to the service are defined. The escalation time and the resolution time vary with the priority of the ticket. If the ticket is in the vendor assigned state for duration more than the resolution time given by the vendor SLA then an email is sent to the vendor. When the ticket is put in the vendor assigned state, the normal SLA will continue to be executed while the vendor SLA will also start. The regular escalations can be sent along with the vendor escalations only if regular escalation option is selected while configuring the vendor escalations. Work Group Each organization is associated with many departments. Each department can be further classified in to workgroups. Users can be associated to organizations, departments and workgroups.coDesk 3.1 Administrator Guide Page 31 of 65
  30. 30. 5. Incident Management in coDesk 3.1 According to ITIL® Service Support best practices, an incident is an event which is not a part of standard operation and which causes or may cause interruption thereby affecting the normal productivity in an organization. The significant role of incident management is to restore normal operation of the service as quickly as possible with no or least impact on the productivity of the organization. coDesk is completely ITIL® centric and offers flexible and efficient automation for incident management. coDesk helps the incident management team to undertake the following tasks. 1. Provide flexible support for incident classification and categorization. 2. Helps restore services as quickly as possible with minimal disruption to users. 3. Manage and track incidents through their life cycle 4. Provide support for Operational activities 5. Automatic and flexible routing of an incident 6. Support for Response and Resolution SLA with escalations and notifications 7. Ability to allocate, transfer tickets to higher skilled experts. 8. Support for searching Knowledgebase to review solutions and workarounds to known issues, problems, errors, etc. 9. Ability to link and track minor incidents with a major incident. 10. Support to relate Incident with Known Error, Problems, Change Requests, Assets (Desktops, Routers, etc). 11. Ability to relate to one or more assets or configuration items with an incident. 12. Multiple actions possible – Accept, Own, Transfer, Allocate, Resolve, Close, Reopen, etc 13. Ability for end user to rate tickets and provide feedback © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 33 of 65
  31. 31. Incident Management in coDesk 3.1 14. Support for Root Cause Analysis 15. Ability to record investigation, outcome and diagnosis with each incident. 16. Support for notifications and emails during entire incident life cycle. 17. Ability to correspond with end user and help desk teams. 18. Real time dashboards for Agents and Managers. 19. Out of the box historical reports for analysis of Incident Management Process. Ability to choose and pick the columns that need to be displayed in the reports. 20. Flexibility of adding additional/custom text fields to record custom/additional information with each incident. 21. Detailed audit history is available for every incident or ticket. The history keeps track of all changes, transfers and actions taken on the incident from creation to closure. This provides visibility to end user on the handling of the ticket. The overall incident management in coDesk can be depicted by the figure below. Figure 5-1: Incident Management Overview The different ways by which the user can log incident tickets are provided in the left side of the above diagram. 1. Incident tickets can be logged by accessing the web site or via email (SMTP) 2. Incident tickets can also be logged while generating Tivoli Event Console Events. coDesk and Tivoli Event Console (TEC) are integrated and hence an event generated in TEC will log a ticket in coDesk. Incident tickets can be logged for SNAPPiMON events. SNAPPiMON and coDesk can be integrated and any alarm generated in SNAPPiMON can be raised as a ticket in coDesk.Page 34 of 65 coDesk 3.1 Administrator Guide
  32. 32. Incident Management in coDesk 3.1 Incident ticket can be logged by the end user or the agent on behalf of other users (Proxy incident). While logging the ticket, the user provides details like the service name, category, sub category, classification, region, location, urgency, impact and description for the ticket. The user can also provide attachments to support the ticket. Self – Calls logged by end users Proxy – Calls logged by agents on behalf of end users Offline – Calls logged by agents after working on the calls. The agent can directly visit the customer place and resolve the call and then later on the agent can log an offline call. Offline calls can be logged only for incidents. Routing Service Rules are defined for several combinations of region, location, category, sub category, classification, and priority for a service. A service can have many Service Rules and when a ticket is logged to a particular service the ticket looks for the best matched Service Rule and follows the corresponding operational rule. From the operational rule the ticket looks for the service window and selects the routing rule corresponding to the service window. If there is no service window (the ticket is logged during non working hours) and the Route option in Service Rule is not selected then the ticket takes the routing rule corresponding to the next available service window. If a ticket is logged after the expiry of the service window group, then the ticket is routed to the service administrator for the corresponding service. According to the routing rule selected the ticket is routed either to a team /agent / shift/ team role / team role. If there is a match in the Service Rule but the service window is not found and the Route option in the Service Rule is checked, then the ticket is routed to service administrator. The ticket takes the SLA, Response Escalation Rule, and Resolution Escalation Rule configured for the administrator. If no exact match in the Service Rule is found, then the ticket looks for the Routing precedence defined for the service. According to the routing precedence defined if any match in the Service Rule is found, then the application takes the corresponding Service Rule. If none of the Service Rule matches with the ticket, even after considering the routing precedence, then the ticket takes the default operational rule for the service. From the default operational rule, the ticket looks for the service window and selects the routing rule corresponding to the service window. If no match in the service window is found, the ticket takes the routing rule associated with the next available service window. According to the routing rule selected, the ticket is routed to team/agent / shift / team role. If a ticket is logged after the expiry of the service window group, then the ticket is routed to the service administrator for the corresponding service. Generic Routing Generic Routing in coDesk is used to route the ticket to the agents based on Team, Team Role and Shift. For example if the Team is selected as Software and the Team Role is selected as Engineer and the Shift is selected as Morning, then all the agentscoDesk 3.1 Administrator Guide Page 35 of 65
  33. 33. Incident Management in coDesk 3.1 satisfying all the three conditions of Team, Team Role and Shift are evaluated and the ticket is routed to all the agents satisfying the conditions. Specific Routing Specific Routing in coDesk is used to route the ticket to the agents based on any one of the following i. Team ii. Team Role iii. Agent iv. Shift When Team option is selected, the ticket is routed to all the agents of the selected team. When Team Role is selected, select the Team and the Team role and the ticket is routed to all the agents of the selected team roles in the team. When the agent option is selected, select the Team, the team role and the agent (s). The ticket is now routed to the agent (s) configured. When Shift is selected, select the Team and the Shift the ticket is routed to all the agents of the team and the shift selected. Call Flow The agent working on the ticket can perform several operations on the ticket. The ticket is available in the work queue according to the routing and the agent needs to accept the ticket. The time elapsed between the ticket log and the ticket acceptance / rejection is called the response time. The response time can also be manually specified by the agent working on the ticket if the service associated with the ticket is configured for acknowledge response activity. After the ticket is accepted, the agent becomes the owner of the ticket. The owner can perform several actions like correspond with other agents or the end user, allocate the ticket to other agents, transfer the ticket, assign to vendors, mark the ticket as major / minor incident, relate the ticket to major incident, relate the ticket to assets, relate to knowledgebase, raise problem or raise RFC and relate to known error. After performing various activities on the ticket the ticket has to be resolved. Notifications are provided to the user each time whenever there is a change in the status or activity. This helps the end user who logged the ticket to keep track of various activities that are performed to resolve a ticket. Notifications are sent as Email in HTML or text format and through SMS. Agent can mark an incident ticket as major incident while working on the ticket or logging a proxy ticket. A major incident ticket can be related to several minor incident tickets. Resolving a major incident ticket will prompt the agent to resolve the related minor incidents. The agent working on the ticket can either resolve the minor incidents along with the major incidents or can unrelate the minor incidents and resolve them separately. Agents can look into the Known Error Database (KEDB) and the knowledgebase for easy and quick resolution of the ticket. KEDB is a data repository which stores all the known errors along with the root cause, temporary workarounds and permanent solutions.Page 36 of 65 coDesk 3.1 Administrator Guide
  34. 34. Incident Management in coDesk 3.1 Knowledgebase is a database repository which contains articles published by different users. The agents and users based on the permission provided can go through them and be aware of the latest technologies and improve their knowledge in problem solving. This helps to resolve the tickets in a faster rate. Incident Management in coDesk supports many teams for a service depending on their shift and team role. Strong Audit capabilities are included to track of the incident tickets at any point of time. Allocation details, details of attachments added to support the ticket, Ticket rule summary, service notes, vendor details; related assets, related problems and RFCs can be viewed to clearly understand the issue. A service of incident type can be related to a service of problem or change request. Whenever an incident ticket is logged, the particular incident ticket can be related to problem tickets or change request tickets or assets related to the service. This relation helps to easily identify the root cause of the problem and resolve the issue at the earliest. Reports in coDesk are enhanced greatly to include web based reports, real time dashboards. Service Level Agreement Service Level Agreement (SLA) is set of rules and norms that are agreed by the service providing organization to offer quality service. There are normally two types of SLAs defined for a Service Rule – Response SLA and Resolution SLA. Whenever a user logs a ticket, the response SLA automatically starts ticking. The response SLA ends at the moment the ticket is accepted / rejected / assigned and is moved out from the work queue. If the service is configured for acknowledge response activity, accepting the call is only the transfer of ownership for the call and the agent needs to manually provide the response time by performing the acknowledge response activity. The response time can be manually provided any number of times before closing the ticket and the time must be greater than the ticket logged time. When a ticket is assigned, the assigned agent cannot accept or reject the ticket and can perform other operations on the ticket. For example, if a user logs a ticket at 9 A.M and the response SLA for the ticket is defined as 2 Hrs, then the agent should accept or reject or assign the ticket within 11 A.M. If the ticket is accepted / rejected / assigned and is taken away from the work queue before 11 A.M then the ticket has met the response SLA. If the ticket is still available in the work queue after 11 A.M then the response SLA is breached. The user can configure SLA Start State and the Auto Closure Time for a service. SLA start state refers to the state at which the Resolution SLA starts ticking. When a ticket is put to SLA hold state, the SLA clock stops ticking but will resume again if the state is changed to non hold status. By default, when a ticket is logged, the Resolution SLA will start automatically if SLA start state is mapped to the Open action. The Resolution SLA will start when the ticket iscoDesk 3.1 Administrator Guide Page 37 of 65
  35. 35. Incident Management in coDesk 3.1 assigned the SLA Start state. The SLA Start state can be assigned in any of the following ways. 1. Changing the ticket status to SLA start state by using Service Notes 2. Changing the ticket status using Change Status action. 3. By performing an action that would change the status. 4. By performing transfer or allocation action. For example if resolution SLA start state is Accepted and Accept action is related to Accepted status then the Resolution SLA for the ticket starts immediately when Accept action is performed on the ticket. Whenever a ticket is assigned SLA Hold status the SLA calculation will stop temporarily, but will continue again once the ticket status is changed to non hold status. The ticket status can be changed by 1. Changing the ticket status to SLA start state by using Service Notes 2. Changing the ticket status using Change Status action. The change status action will display only the statuses that are not mapped to the default actions for a service. Whenever a resolve action is performed on the ticket, the Resolution SLA stops. Resolve action can be mapped to any status and the associated status becomes the SLA end state for that service. The mapped end state is not available in change status option or Service Notes option. The agent cannot assign that status to the ticket at any point of time. When the agent performs Resolve action on a ticket, the ticket is assigned the corresponding mapped status automatically and the SLA stops immediately. Auto closure time is the time defined for each service for which the ticket is resolved and is not reopened or closed. After the completion of the defined auto closure time, the ticket gets closed automatically. When a ticket is reopened the SLA resolution time continues ticking and is not started fresh. The agent can perform all operations and activities similar to a new ticket. For example, SLA Start Time – 2 P.M SLA Resolution Time - 4 hrs Auto Closure Time – 2 hrs The agent has resolved the ticket within 3 hrs i.e., by 5 P.M. The ticket will be closed automatically by 7 P.M if the user who logged the ticket /agent who worked on the ticket does not reopen the ticket. Reopen and Close actions are based on the permissions defined for the agents and the end users in the provider and the receiver templates. The SLA configuration for a service provides option to include / exclude the time interval between the resolved state and the reopened state to be a part of the SLA while configuring the Service.Page 38 of 65 coDesk 3.1 Administrator Guide
  36. 36. Incident Management in coDesk 3.1 If the ticket is re opened at 5.30 P.M and if the service is configured to include the time between the resolved state and the reopened state to be the part of SLA then the agent is left with only 30 mins to complete the ticket without breaching the SLA. But if the service is not configured to include the time interval between the resolved state and the reopened state to be the part of SLA then the agent is left out with 1 Hr to complete the ticket without breaching the SLA. SLA Resolution time is the time taken to resolve the ticket irrespective of the number of times the ticket is reopened discarding the time interval for which the ticket is put in hold state and the time for which the ticket was in resolved state and reopened again based on the configurations made for the service. Incident tickets need to be reopened before it is closed. Closed incident tickets cannot be reopened. Acknowledge Response The ticket is routed to the work queue depending on the routing rule. The agent can perform an accept action to work on the ticket. The actual response time at this instant is the time at which accept / reject /assign action is performed on the ticket. If Acknowledge Response activity is configured for a service, the time at which the accept action is performed on a ticket is just the transfer of ownership from the work queue. The agent needs to manually provide the response time for the ticket. The response time must be greater then the ticket logged time. The response time can be specified any number of times and the time provided during the latest acknowledge response activity is considered as the actual response time. The actual response time should be less than or equal to the estimated response time. Otherwise the response SLA for the ticket is said to be breached. Acknowledge Resolution Acknowledge Resolution if configured for a service, allows the agent to manually specify the resolution time for the tickets associated with the service. The actual resolution time depends on the time taken to perform the resolve action or the time specified during the acknowledge resolution activity. Acknowledge resolution can be performed any number of times and the application allows the agent either to retain the previous resolution time or override that with the newly provided resolution time. The estimated resolution time must be greater than or equal to the actual resolution time. Otherwise the resolution SLA for the ticket is said to be breached. SLA Escalation Service Level Agreements (SLA) is configured to assure quality and quick service to the end users. Response SLA is the time within which the ticket must be accepted or rejected or assigned and moved away from the work queue or the time specified during Acknowledge Response activity depending on the service configuration. Resolution SLA is the time within which the ticket must be resolved. If the time taken to perform thiscoDesk 3.1 Administrator Guide Page 39 of 65
  37. 37. Incident Management in coDesk 3.1 action exceeds the configured SLA time then the SLA is said to be breached for this ticket. The resolution time can be manually provided by the agent while performing Acknowledge Resolve activity depending on the service configuration. The ticket can be escalated to the configured person as per the configured time which corresponds to the SLA time. Many levels of escalations can be defined and notifications and alert messages can be sent to different people at different duration. If the configured escalation time duration is 12 hrs and the other configured escalation time duration is 6 hrs then, after the response SLA is started, the application waits for the least configured time duration (6 hrs in this case) and checks if the ticket is not yet responded. If the ticket is still available in the work queue and exceeds the response escalation time configured for the ticket, then the ticket is escalated to the users configured for the escalation. Similarly if the ticket is not resolved within the resolution escalation configured, then the ticket is escalated to the configured users. Escalation levels are independent of the order in which they are configured. The escalations levels are considered in ascending order of escalation time. The second level escalation happens after the next least configured time duration from the time the SLA is started (In this example it is 12 hours after the response SLA is started.) Note Escalation time interval is calculated from the instant the SLA is started. The minimum configured escalation time is taken as the first level of escalation. For example if the configured escalation levels are 10 Hrs and 6 Hrs, then the first escalation happens 6 Hrs after the SLA is started and the second escalation happens 10 Hrs after the SLA is started. The 10 Hrs also includes the first configured 6 Hrs. If first escalation happens at 8 A.M in the morning, then the second escalation happens at 12 noon. Escalation Notifications can be provided for any number of times according to the recurring frequency. If the recurring frequency is 4 and the recurring time interval is 5 hrs, then escalation will happen after 5 hrs since the last escalation time. In a similar manner escalation will repeat once in 5 hrs for 4 times. According to the recurring time and recurring frequency the ticket can be escalated to higher personnel. The recurring escalation time is calculated after the last level of escalation and is sent to the configured users at that level. Escalation can also be continued irrespective of the frequency till the ticket is closed. Email Call Logging coDesk enables end users and also the users who are not part of coDesk to log tickets through email. When a user who is not part of coDesk logs a ticket, the user will be mapped to a coDesk user. Email call logging facilitates ticket logging for incident tickets only. Tickets logged through email follow the same call life cycle as the tickets logged through other call modes. For email call logging, mailboxes and prefill codes have to be configured. The email id for the mailbox, username and password can be configured inPage 40 of 65 coDesk 3.1 Administrator Guide
  38. 38. Incident Management in coDesk 3.1 the mailbox settings. The configured mailbox can then be associated with the prefill codes. TEC Integration coDesk provides bidirectional integration with Tivoli Event Console (TEC). coDesk is integrated with TEC by connecting TEC to coDesk database server through the CTA (coDesk-TEC Adapter) tool. TEC Severity, TEC Template, and TEC Classes need to be configured in coDesk for logging a ticket when an event is generated in TEC. TEC Severity name should be same as in TEC. SNAPPiMON Integration coDesk provides bidirectional integration with SNAPPiMON 3.7. Multiple SNAPPiMON SP4 instances can be integrated into coDesk. Each SNAPPiMON instance is configured by its instance name, IP address, and port number. SNAPPiMON events need to be configured in coDesk to log a ticket when an event is generated in SNAPPiMON. coDesk is pre configured with certain common events fired in SNAPPiMON. The user can also define new SNAPPiMON events in coDesk. However, the events’ names should be same as in SNAPPiMON. The SNAPPiMON events need to be mapped to coDesk incident service for logging a ticket. Asset Manager Integration Asset Manager 3.5 SP2 can be integrated with coDesk to maintain and keep track of the assets available in an organization. Both Asset Manager and coDesk must share the same database for integration. Asset Manager is integrated with coDesk by its server IP address, port number, protocol type and instance name. Permissions Permission in coDesk is template based. The templates define the permitted actions, activities and views for end users and agents. Separate templates are defined for Service Provider and Service Receiver. Agents and end users will be mapped to multiple templates for different services. There will be one default template for agent and end user per service.coDesk 3.1 Administrator Guide Page 41 of 65
  39. 39. 6. Problem Management in coDesk 3.1 According to ITIL® best practices, Problem Management investigates the underlying cause of incidents and aims to prevent the incidents of the same time from occurring again. Problem management assists the incident management in finding the underlying solution for the event. When the root cause of the event is found the problem becomes a Known Error. Each known error is associated with an error statement, temporary work around and permanent solution. Effective problem management prevents similar incidents from occurring again. Problem management automation in coDesk provides the following capabilities:- 1. Log, track, transfer and manage problems. 2. Identify errors within the IT infrastructure. 3. Find root causes and initiate corrective action. 4. Reduce number & severity of incidents by proactively identifying improvements to IT infrastructure. 5. Support for problem logging, categorization. 6. Support for recording problem analysis, investigations. 7. Support for root cause analysis including multiple workarounds, solutions, etc. 8. Support for multiple problem teams. 9. Support for Operational Level Agreements for Problem Resolution. 10. Support for multiple actions on Problems including Accept, Reject, Own, Transfer, Transfer Accept, Transfer Reject, Analyze, Resolve, Close, Reopen, etc. 11. Strong support for Error Control including Error detection and identification. 12. Support for recording error assessment, error resolution, etc. © Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVEDcoDesk 3.1 Administrator Guide Page 43 of 65
  40. 40. Problem Management in coDesk 3.1 13. Monitoring Problem and Known Error through their life cycle. 14. Multiple reports provide excellent analysis capabilities. 15. Ability to associate problem record with change requests. 16. Ability to associate incidents with problems. 17. Ability to relate problem or known error with one or more Configuration Items or Assets. 18. Multiple actions possible – Accept, Own, Transfer, Allocate, Resolve, Close, Reopen, Assign etc. 19. Detailed audit history provided for each problem and known error across its entire life cycle. The overview of the problem management is as shown below. Figure 6-1: Problem Management – Overview A problem ticket can be logged in any of the following three ways 1. Problem ticket can be logged directly by the user using the application. Web based ticket logging can be made by providing the required features and descriptions for making the ticket. 2. Problem tickets can be raised from an incident to find the root cause of the event. Hence problem ticket can be raised based on the need to close one or more incidents of the same nature (reactive problem management). Problems tickets can also be raised from change requests. 3. A problem can be proactively identified by analyzing either the incident trends or by other proactive analysis and the solution for the problem can be found. Proactive problem identification is the process of identifying the problem which might occur in feature and finding the root cause, temporary work around and permanent solution. Thus a problem can be solved even before its occurrence. 4. Proxy Problem tickets can be logged by the agent on behalf of other users.Page 44 of 65 coDesk 3.1 Administrator Guide

×