CA Unicenter Service Desk Change Policy

CA Unicenter Service Desk Change Policy Outline of Change Processes, Roles, and Terms for CA Unicenter Service Desk John Cowsert

2 Table of Contents Description of CA Unicenter Service Desk... 3 Roles and Responsibilities... 3 Administrative Department... 3 Application Administrator... 3 Help Desk Steering Team... 3 HDST Responsibilities... 3 HDST Current Membership... 3 HDST Meetings... 4 Prioritization Procedures... 4 Important Definitions... 4 Customization... 4 Modification... 4 What parts of CA Unicenter Service Desk can be modified?... 5 Request for Change Process for CA Unicenter Service Desk... 5 Glossary of Terms... 6 Access Types... 6 Active... 6 Activity Log... 6 Affected End User... 7 Announcements... 7 Assignee... 7 Attachments... 7 Contact Types... 7 Database Schema... 7 Event... 8 Form Groups... 8 Group... 8 Knowledge Documents... 8 Logging Agent/Reported By... 8 Mail Transfer Agents (MTA)... 8 Option Manager... 8 Organization... 9 Partitions... 9 Priority... 9 Profile Browser... 9 Properties... 10 Request/Incident/Problem Area... 10 Scoreboard... 10 Service Types... 10 Status... 11 CA Unicenter Service Desk Views... 11

3 Description of CA Unicenter Service Desk CA Unicenter Service Desk (CA USD) is the ticketing tool purchased by the University of Illinois to track requests and incidents for the University campuses and administration. The application contains information about all University users from the Banner ERP and is used by multiple University help desks. Roles and Responsibilities Administrative Department Administrative Information Technology Services (AITS) performs administrative duties for the CA Unicenter Service Desk tool. Changes made to the tool are controlled via the AITS COE Application Support group and are maintained according to the AITS published change management policies. Application Administrator The Application Administrator is the person in charge of implementing changes to the CA Unicenter Service Desk environment and holds an advisory, non voting role on the Help Desk Steering Team. A member of AITS Application Support staff has been charged with this duty. Help Desk Steering Team The Help Desk Steering Committee (HDST) is the governing body of the CA Unicenter Service Desk tool. The HDST is comprised of representatives from Administrative Information Technology Services (AITS), Campus Information Technologies and Educational Services (CITES) Office of Business and Financial Services (OBFS), Human Resources (HR), University of Illinois at Springfield (UIS), Decision Support and UIC College of Pharmacy Technology Support and Office of Student Support Services [OSSS]). HDST is the central group to review CA USD tool issues and requests for changes and it ensures that changes to the tool are reviewed and prioritized. The HDST is not directly responsible for implementation of changes to the CA USD tool, however team members are encouraged to participate in subcommittees to explore functions or projects related to the CA USD tool. HDST Responsibilities To provide an arena to discuss and review tool issues and changes. To review operational reports for the CA USD tool. To develop strategies for enhancements to the CA USD tool. To gather and disseminate information and events to other represented departments. To vote on and provide sign off for enhancements to the CA USD tool. HDST Current Membership CITES Kathy Lyons

4 AITS Mike Lyon and Peggy Ball Decision Support Lisa Courtney HR Amy Glenn and Nancy Neild UIS Stephen Rohrer OBFS Ryan Hall UIC Pharmacy Phil Reiter OSSS Barb Roche AITS Application Administrator (Advisor) John Cowsert HDST Meetings The HDST meets the third Friday of every month to discuss CA USD tool issues and enhancements. Agendas are set three days in advance of meetings. Prioritization Procedures Important Definitions Customization A customization in CA Unicenter is defined as an external change to the CA USD tool that is not part of the installed software. Most customizations require external developer/vendor work and may even require additional funds to purchase vendor support to support customizations. HDST and AITS plan to minimize baseline customizations in order to maintain support status with the vendor and reduce potential problems with future software upgrades and patching. Example of a Customization The ability to send tickets directly to the CA USD tool is considered a customization. CA USD is not designed to accept emails from multiple email addresses so a customization needed to be created and supported with University funds. Modification A modification in CA Unicenter is defined as an internal change to an integral part of CA USD. These changes either affect all groups utilizing the CA USD tool, or just an individual user group, which would impact a smaller set of users. Dependent on the modification, the HDST will review and prioritize the enhancement based on the agreement of the representative user groups. Example of a Modification The ability to send a note to the end user upon closure of a ticket is a global modification, meaning that this ability cannot be turned off or on for some user groups, but instead would affect all user groups in the CA USD tool.

5 The ability to create a new Group or a Service Type is considered a local modification as the groups are tailored to the correct analysts and Service Types are created to be conditional for an organization. What parts of CA Unicenter Service Desk can be modified? If a modification can be modified at a local level this means the modification will only affect a small group of users in the tool rather than all users of the CA USD tool. If a modification can only be modified at a global level it means that the modification will affect all users of the tool. The following components of CA USD can be modified on a local or global level (see Glossary of Terms): Parts of CA Unicenter Service Desk Modifiable at Local Level Modifiable at Global Level GUI Web Forms Login Page Mail Transfer Agents Notifications Service Types (Escalations) Contact Types Profile Browser Attachments Data Partitions Ticket Status Access Types Database Schema Groups and Group Priority Memberships Request/Incident Areas and Option Manager options their Properties Announcements Scoreboards Knowledge Documents Request for Change Process for CA Unicenter Service Desk Requests for changes to the CA USD tool are submitted to the AITS Service Desk via phone or email. The AITS Service Desk will communicate the request with AITS Application Support. If the change is not a local modification then the change must be reviewed by the HDST. Requests are reviewed for business need, affect on campus groups, and affect on future upgrades to CA USD. HDST will then submit a work request to AITS. AITS will then allocate the necessary resources. Local Global Customization Reviewed by HDST Reviewed by HDST Modification Reviewed by AITS Reviewed by HDST

6 Glossary of Terms Below is a brief overview of terms associated with CA USD. While not exhaustive, additional information is available via the tool s online help. Right clicking any page in CA USD will open content related information about CA USD. Access Types Access Types are the security types that are granted to accounts and when coupled with Contact Types, determine access to partitions, form groups, and authentication. Access Types must be granted correctly to make sure that the account can only view data related to an individual or the group in which they work. There are 6 types of Access Types: 1. Administrator This Access Type goes across all partitions, has its own form group, and has access to the entire application options and configurations. 2. Campus Administrator This Access Type stays within its own partition to see only partition tickets and has the ability to grant access to other analysts, create new groups and control group membership. 3. Knowledgebase Manager This Access Type stays within its own partition to see only partition tickets and has the ability to grant access to other analysts, and is able to create, publish, and update Knowledge Documents. 4. Analysts This Access Types stays within its own partition, and has the ability to create Employees and Students. Analysts can see Request/Incident Areas available to Employees, Students, and Internal only Request/Incident Areas. 5. Employees This Access Type can only look at tickets where they are the Affected End User. Employees only see Request/Incident Areas available for Employees and Students. 6. Students This Access Type can only look at tickets where they are the Affected End User. Students only see Request/Incident Areas available for Students only. Students are the most restricted Access Type. Active The Active designation denotes what state a ticket is in. An Active ticket means the ticket is open and available for changes and updates. An Inactive ticket means the ticket is closed and must be reopened to affect proper changes. Activity Log This is the list of activities that have been logged for a request, incident, or change order.

7 Affected End User The name of the person affected by the Request/Incident. Announcements Announcements are messages and notes that are added to the web GUI for contacts to see. They can be created as internal or external (end user facing) and can be limited to certain organizations within the application. Simple HTML coding rules apply. Assignee The name of the person assigned to the Request/Incident. Attachments Found on the Attachment tab on a ticket, attachments can be added by end users, analysts, or via email. A set of acceptable types of attachments is known in the system and all types of pictures and text types are allowed including all Microsoft Office and Adobe product file types. Contact Types Contact Types are the type of contact that a record is. These must be designated together with Access Types to be affective as part of security. Analysts Analysts are defined as those contact records that work in a help/service desk and create, update, and close tickets. Employee Employees are able to see the End User web view where they can see their old tickets, current tickets, and create new ones. Student Students are able to see the End User web view where they can see their old tickets, current tickets, and create new ones. Database Schema The Database Schema is the known tables and views in the database and the definition of the fields and code that comprise the tables and views. This is an area of the tool that should be modified with great caution and only the System Administrator should have access to changes to the schema. Making changes to the underlying database is not recommended by the vendor. Changes should be conducted according to the Modification Documentation provided as some changes cannot be backed out and changed once implemented as well as use of vendor tools means changes are flagged as known changes for future upgrades to ignore.

8 Event Part of a Service Type that fires based on conditional statements. Form Groups Form groups are groups of forms that define the windows that are displayed. Forms are changed by the System Administrator to modify views of the web application. Group The group that is responsible for a Request/Incident. Any individual contact assigned to the group can handle the task once it is assigned to the group. Group membership is granted to Analysts contact types only. Knowledge Documents Also known as Solutions, these documents hold information that explain how to solve different problems based on information gathered during ticket research or known issues. The Knowledge Documents are created in HTML and information added to them will work with direct code input. Simple HTML rules apply. Logging Agent/Reported By The name of the person who created the Request. Mail Transfer Agents (MTA) Mail Transfer Agents are the applications that parse and forward email to the CA USD email application. Email must be sent to CA USD in a specific format in order to create and route tickets appropriately. MTAs are administered by AITS and can be modified for local groups. Option Manager The Option Manger is a set of options available only to the System Administrator. There are 133 posted options with CA USD. All are global in nature and a restart of services to edit, activate or inactivate. Option examples for the following areas of change include: Archival and Purge Audit Log CA Workflow Change Order Manager Email LDAP Notifications Request Manager Security

9 Web Services Organization The company, division, or department where contacts work. Partitions Data partitions are subsets of the database with restricted access to data records, based on their content. You restrict that access by defining a set of constraints for each data partition. Data Partitions are then controlled by the Access Type granted to a contact record. Priority Priorities are used by incidents and requests to escalate tickets to the required level based on the severity of the issue. There are 4 Priorities in CA USD. 1 Outage, 2 High, 3 Normal, 4 Low. If a ticket is given a priority higher than the 3 Normal, the Service Types for that priority begin and the older lower Service Types are cancelled. 1 Outage This is a global priority. A Global Priority means that the priority itself has a Service Type attached to it. Thus, all groups must utilize the same priority Service Type and conditional statements about the ticket are used to control who gets what notification and when the notification is sent. The Service Types look at the Organization assigned to the Groups to determine what events are to occur. Groups using this priority are CITES and AITS. 2 High This is also a global priority used by multiple groups. Groups using this priority are CITES, UIS, and AITS. 3 Normal This is not a global priority. This is the default priority that does not have a Service Type associated with it. The Service Types are set via the Request/Incident Areas instead. All groups use this priority as a default. 4 Low This is a global priority, but the settings are set to a standard 24/48 hour standard. Meaning that a ticket will notify the assignee that the ticket remains open at 24 and 48 hours since the ticket opening with no further reminders. Profile Browser The Profile Browser provides a centralized area to view detailed information about the contacts and organizations that make up your enterprise. One way to display the Profile Browser is to click Profile Browser on an issue, request or change order detail window. You can also select Profile Browser from the View menu on the Service Desk tab. The Profile Browser is divided into three panes:

10 The left pane shows the menu for contact and organization information, environment, and history (this is described below). The right pane displays the windows for different types of contact history depending on your latest selection. The bottom pane shows the Scratchpad area, allowing you to add additional information to the record being profiled. Properties Properties are utilized at ticket creation to gather additional information pertaining to a problem. Properties are created on the Request/Incident Areas and are controlled there as well. They can be enforced/required or passive. When a ticket is created, these popup questions are found on the Properties tab of a ticket and should be filled out by the user or the analyst. While there are no limits to the number of properties a ticket may have, it is recommended that less is more. End Users can see properties on any end user assessable Request/Incident Area via the end user web interface. They are viewable as soon as the Request/Incident Area is selected. If required a red box outlines the empty textbox and waits to be filled. Request/Incident/Problem Area This is also known as the category of a Request or Incident. The Request/Incident/Problem Areas control, partition views, launching of surveys, service type designation, default groups, auto assignment, properties, etc. Request/Incident/Problem Areas control how tickets are routed and what actions occur to tickets until they are closed. Scoreboard The scoreboard is a set of queries available to a contact that show up on the left hand side tree of their GUI. Since the scoreboard is a performance reducing task, queries must be controlled to allow for best performance of the application. Service Types Shows the level of support service received by the contact affected by the record. Service types are automatically attached to requests/incidents based on the Service Type defined for its Request/Incident Area. (The system administrator defines Service Types and Request/Incident Areas through the web interface.) If different Service Types have been defined for other values on the issue (priority and contact, for example) the Service Type used is the one with the best (lowest) ranking. For example, if an issue is opened and the From contact has a 12 hour resolution Service Type, which is ranked as 2, while the priority code has a 4 hour resolution Service Type, which is ranked as 1, the Service Type for the issue will be 4 hour resolution.

11 In order for Service Types to work, good practice is to grant groups correct organizations as they are used for conditional purposes. Status A status is the marked condition of a ticket based on the processes of the ticket or events that occur to the ticket. Examples include: Open, Acknowledged, Reopen, Closed, Work In Progress, Resolved, Hold, etc. CA Unicenter Service Desk Views There are 3 CA USD views. Administrator View Is the same as the Analyst view with the addition of the Administration tab. The Administration tab contains information on: o Archival and Purge o Attachments Library and Repository Configuration o Events and Macros o Knowledge o Notifications o Options Manager o Security o Service Desk Settings o Web Services Policy Analyst View The Analyst view is the default view of CA USD that allows service desk staff to view, create, update, and search for tickets and search the knowledgebase. End User View The End User view is the view as seen by employees and students. It s a simple view that only allows a user to view tickets where they are the affected end user.