Part 1 - Requirements and Configuration.doc

Requirements and Analysis Document

University of North TexasComputer Services Problem Management

Part 1 - Requirements and Configuration

Prepared By:

Christopher Strauss

19 February, 1998

Table of Contents

TABLE OF CONTENTS....................................................................................................................... 2

PURPOSE............................................................................................................................................... 3

PROJECT OBJECTIVES...................................................................................................................... 4

WORKFLOW REQUIREMENTS........................................................................................................5

WORKFLOW PROCESS............................................................................................................................ 5PROBLEM ASSIGNMENT AND OWNERSHIP...............................................................................................5

Ticket Entry and Initial Assignment..................................................................................................5Reassignment of Tickets.................................................................................................................... 6Reopening of Tickets......................................................................................................................... 6

PROBLEM CATEGORIZATION.................................................................................................................. 7Categorization Hierarchy................................................................................................................. 7Categories........................................................................................................................................ 7Types................................................................................................................................................ 8Skills Needed (Referral Points)......................................................................................................... 9

STATE TRANSITIONS/LIFE-CYCLE........................................................................................................ 13State Definitions............................................................................................................................. 13Summary of State Transitions/Workflow..........................................................................................13New State Transitions..................................................................................................................... 14Assigned State Transitions.............................................................................................................. 14Work In Progress State Transitions.................................................................................................15Reassign State Transitions.............................................................................................................. 15Pending State Transition................................................................................................................. 15Escalated State Transitions............................................................................................................. 16Resolved State Transitions.............................................................................................................. 17Closed State Transitions................................................................................................................. 17Reopen State Transitions................................................................................................................ 18

ESCALATION POLICIES......................................................................................................................... 19Impact............................................................................................................................................ 19Priority (drives escalation)............................................................................................................. 19

SYSTEM CONFIGURATION............................................................................................................. 20

SYSTEM SERVER CONFIGURATION........................................................................................................20SYSTEM SCHEMA CONFIGURATION.......................................................................................................21SCHEMA DESCRIPTIONS....................................................................................................................... 22

Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES

Purpose

The Purpose of this document is to present a draft Requirements Analysis for the University of North Texas computer support problem resolution system. This project falls under the oversight of the Distributed Computer Support Management Team (DCSMT), which directed the selection of the Remedy product for enterprise-wide implementation. The project leader has formed an implementation team of technical support staff, and an implementation steering committee from central and distributed support area managers. Subject to change as appropriate, the various working group representatives are:

Implementation Team MembersGroup NameImplementation Project LeaderCollege of Arts and Sciences Computing

Timothy Christian

Remedy System Administrator Christopher StraussSystem Server Administrator John BoothAdaptec Interface integration Jim CurryManageWise integration Allen BradleySpectrum integration Blair CopelandDatabase integration to Directory Services Bill BuntainMacintosh client evaluation Ty YoungX11R5 with Motif client evaluation Marc St.-GilWeb client evaluation Mark Wilcox

Steering Committee MembersGroup NameImplementation Project Program Manager and College of Arts and Sciences Computing

Timothy Christian, Chair

Remedy System Administrator and Computing Center Helpdesk

Christopher Strauss

College of Education Computing Paul HonsCollege of Business Administration Computing Jan BrothersComputing Center Academic Computing Philip BaczewskiComputing Center Data Communications Mike ManerHealth Science Center Tom Newell (possible)Library Network Administration Robert PiercePhysical Plant Computing Cindie HarrisSchool of Community Service Computing Rich AndersonSchool of Visual Arts Computing Craig Berry

This document summarizes the business rules and proposed workflow required to support the problem management design requirements of a UNT Computing Services internal problem resolution system to be developed using Remedy’s Action Request System. By definition, UNT Computing Services are comprised of one central computing center and over a dozen individual distributed support organizations, and for planning purposes include all UNT and HSC staff who support some aspect of computer use.

With the intent of deploying as capable an application as possible in a short time frame, the implementation team will modify the Help Desk 2.0 template provided by Remedy to suit our own operations. The set of schemas comprising the template is extensive, interdependent, and highly automated. The advantage to using them is that Remedy Corporation has already invested a great deal of effort in developing them, and they are consequently feature-rich in ways that have proven valuable to many other organizations. There are no less than 24 schemas, 201 filters, 364 active links, 24 menus, and 5 escalations already defined. The templates are already well documented in both printed and help-text form, with notes to facilitate adaptation to our needs. It would take several people already well-versed in Remedy development to build a comparable system from scratch.

DCSMT Call Tracking Project 3


Project Objectives

UNT Computing Services will use the Remedy Action Request System to develop and implement a problem processing and tracking system to support problem resolution for UNT affiliated customers, known as “requesters” in the terminology Remedy uses (faculty, staff, and students). The users of the system will be internal UNT Computing Services representatives.

At this time, we will employ a shared, multi-use Windows NT server (Corsair) for system development and a dedicated, fault-tolerant Windows NT server (Remedy) for production purposes. Design and deployment of the Problem Management system for UNT Computing Services will take place in phases. The implementation plan calls for the deployment of a “pilot” system to be utilized by a selected group number of departments who are represented on the steering committee. A full-scale deployment to all computer support areas will take place later. Additional components including web access and integration with network management tools will follow.

The specific requirements for development, as presented by UNT Computing Services, are as follows:

Import client data on a daily or weekly basis to an underlying data store. Auto-fill client information into new case tickets when available. Provide a user-friendly interface with Windows, Macintosh, Web, and X-Window clients that speeds data

entry, particularly of initial contacts. Facilitate rapid entry of customer contacts/problems as “cases” into the system. Data elements will include general customer information and detailed customer problems. Correlation to UNT machines by decal number will be supported. Categorize problems by type, root cause, location received, and method received. Provide knowledge base assistance to UNT Computing Services employees for problem categorization,

resolution, to include referral recommendations. Notify staff when they receive new assignments, transfers and escalations via system tools, e-mail, or pager. Must be able to track all calls received from opening to resolution and closure. Must flag duplicate problems from the same customer within a given time period. Must flag duplicate problems from different customers within a given time period. Must automatically escalate calls when parameters are exceeded. Confirm to users via e-mail or other means (FAX?; phone?) when a representative has opened and/or closed a

call, depending upon the client’s preference. Support root cause analysis of problems. Must identify individual customers and the amount of effort spent resolving their problems. Support pre-defined and ad-hoc reporting. Must support the building of a knowledge base from selected resolved issues.

Cases may come into the Problem Management system in one of the following ways:

Telephone Call (i.e. the problem is entered by a UNT Computing Services representative in the central helpdesk or one of the distributed areas).

Walk-in (i.e. the problem is entered by a UNT Computing Services representative in the central helpdesk or one of the distributed areas).

E-Mail (e-mail to the central [email protected] queue, or the Remedy arsystem mailbox, or to one of the distributed areas that is then forwarded to the helpdesk or arsystem mail queue).

AR Web case ticket entry made directly by the requestor.

As indicated earlier, the implementation will take place in phases. UNT Computing Services intends to include World Wide Web deployment, knowledgebase integration, and other applications during later phases. This phase of the project (problem management) will focus on basic call tracking and routing/notification.



Workflow Requirements

Workflow process.

The diagram below describes elements of the problem management process.

The following sections describe the important elements of the process:

Assignment and Ownership Problem Categorization State Transitions/Life-Cycle Escalation Policies

Problem Assignment and Ownership.

An important aspect of the problem resolution process is the subject of ‘problem ownership’ and the process of assignment or reassignment that might be required in order to resolve the problem. One or more individuals or departments may own problem tickets during the course of their life cycle. Hence, each ticket includes a field for ‘Assigned Individual’, ‘Assigned Department’ and possibly ‘Retain Ownership’ (the latter is a field that the Barnhill consultant added that we might want to consider using as well for controlling case closure). The following paragraphs describe the basic process of problem resolution in terms of ticket ownership.

Type and Source of Tickets

As currently defined in our implementation, cases or tickets will fall into one of three (3) Types, and will come from one of six (6) sources.

TypesProblem (the default) Question Request

SourcesPhone (the default) Requester telephones the computer support staffRequester Requester fills out Remedy form themselves – probably in the case of one computer

support staff member reporting a problem to another support area or personWalk-In Requester walks in to helpdesk, lab, etc.EMail Request sent to system or operator via e-mailWeb Requester filled out an AR Web formNMP Network Monitoring Process initiates ticket

Ticket Entry and Initial Assignment.



Problem tickets entered by UNT Computing Services representatives in response to receipt of a problem are opened for submission in the “New” state by default. The first thing the representative must do is locate the client’s information as expeditiously as possible. If the representative can resolve the call immediately (from memory or look-up from a knowledge base of previous problems) the call is submitted in the “Closed” state, with the required problem categorization and resolution information provided.

If the representative cannot resolve the problem, he or she must categorize the problem prior to submission. The categorization process should also result in a proposed set of first-level and second-level referral points. The representative may assign the call manually to an individual or department responsible for the particular problem type. Alternatively, the system will automatically assign the ticket to an individual or department (if the ‘Assigned-to’ field is left blank… unless we set the system to not allow that) designated as responsible for the specific problem type utilizing the auto-assignment capability provided by the system. Helpdesk staffers recommend a single button labeled something like "Assign to Recommended First-Level Support" that will implement the default referral with one mouse click. Upon submission, the ticket will be set to “Assigned” and the individual or department will be notified. Thereafter, the problem may change ownership through reassignment as described below under “Call Reassignment”. Call reassignment is the same regardless of how the ticket was entered.

When an individual receives notification of a problem assignment, the status is changed to “Work in Progress” if work is to begin immediately. Tickets not acknowledged in a certain time period (see Escalation requirements) are escalated to the assigned individual’s supervisor/manager for reassignment or expediting.

Reassignment of Tickets

A new or in progress ticket is assigned to an individual or department for resolution by the receiving representative either manually or by utilizing the auto-assignment capability. If the ticket cannot be resolved by the assigned individual and reassignment is required, an individual may request reassignment.

Reassignment is selected by changing the status to “Reassign” which causes the assignment of the ticket to change to the individual’s supervisor/manager. The supervisor/manager, once notified, can elect to reassign the ticket to another individual or department. This will also hold true if initial assignment of the ticket will go to any individual or department other than the submitting individual’s. NOTE: How do WE want to do this at UNT – can a helpdesk staffer assign a case to a user, or only to a group for group member pickup or manager assignment.

A reported problem may go through any of the above procedures multiple times before finally being resolved.

Reopening of Tickets

A ticket for a case that has not been resolved (in the opinion of either the requester or one of the computer support staff) will be set to a status of Reopen and reassigned to the responsible agency for follow-up. The "Reopen" status allows tracking the work history of calls that were closed without being resolved, or problems that recurred immediately, as opposed to a case left open indefinitely.



Problem Categorization

Problem categorization must support the various departments utilizing the system. This requirement will be met with a hierarchical menu that supports rapid navigation and one-click selection of problem category, type and item affected. This menu will select a descriptor representing all three fields in order to speed data entry.

Given the problem categorization and knowledge base requirements discussed, it was determined that the internal tools available in Remedy may be adequate to meet the initial knowledge base and look-up solution requirements. The implementation will therefore consist of modifications to the data sets to meet this requirement. The steering committee may consider third-party knowledgebase products after the base system has been fully deployed.

Categorization Hierarchy

Cases will be identified as being related to one “Category,” one “Type,” and one “Item Affected.” The case categorization process will also result in an assignment of one to two levels of “Skill Needed” to each case. These will correlate to the campus computer support organizations, drawn from the previous call queues used in Clientele and the list of distributed support areas. Draft tables for Category, Type, and Skill Needed appear below. The listing of current Items Affected, sorted on Category and Type, is a 28 page MS Access database report titled Case Category Detail for Remedy Action Request System, available separately and on the web.

Categories

CategoryAcad MainframeAdmin MainframeDepartmentalInternet / IntranetMacintoshMS-DOSNetwareNetwork DeviceNT ServerUNIX DesktopUNIX ServerWindows 3.xWindows 95Windows NT



Types (Standard Computing Items)

Type (Computing Items)Admin AppsApplicationBOOTP DNS DHCP MXCampus NetworkCommunicationsConnectivityData EntryData Jack / WiringDatabaseDesktop PublishingDialup InternetDialup Remote ControlDriver / ProtocolElectronic MailFile SystemGeneral ComputingGraphicsHardwareInformationInstructional SupportInternet ApplicationMulti MediaNetworkOperating SystemOtherPrintingProgrammingRemote AccessReportsServer / ServiceSpreadsheetStatistics / MathSuite / WorksTech SupportTrainingTutorialsUNT ApplicationsUSENET NEWS (nntp:)UserID / AccountUtilitiesWebWord ProcessingwwWeb (http://; HTML)



Types (Departmental Entries)

TypeArts and SciencesAuxiliary UnitBusinessCommunity ServiceComputing CenterDistributed AreaEducationGeneral Access LabsHealth Science CenterHousingHuman ResourcesLibrariesLibrary SchoolMicro MaintenanceMusicPhysical PlantPolicePurchasingStudent AffairsStudent Service CenterTAMSUnionVisual Arts

Types (Supplementary Menus)

TypeCannot Log InFaculty / StaffStudentsSystem ErrorUsage Question



Types (Computing Center Departmental Sub-Entries)

TypeAcademic ComputingAcademic MainframeAdmin ApplicationsAdmin MainframeAdministrative NetworkAdmissions DataCOM-PLETEComputer OperationsComputing Center AACWIS Web SupportDatabase SupportDataCommDesktop OSDocumentationFiscal DataGeneral DataHelpdeskIBM OSInstructional TechMessagingNetWare NOSNetwork ManagementPayroll Personnel DataProduction ServicesSecurityStatistical ResearchStudent Records DataStudent Services DataUNIXVoice Response



Skills Needed (Referral Points)

Org Skill DescriptionCentral ABN Support Administrative Network SupportCentral Academic Computing Academic Computing and GALCentral Academic Mainframe Academic Mainframe User ServicesCentral ACS GAL Academic Computing Services GALCentral Admin Computing Administrative ComputingCentral Admin Mainframe Administrative MainframeCentral Admissions Data Admissions Data Systems TeamCentral Applications ApplicationsCentral CC Security CC SecurityCentral COM-PLETE COM-PLETECentral Computer Operations Mainframe Computer OperationsCentral Computing Center Computing Center AdministrationCentral CWIS Web Support CWIS and Central Web SupportCentral Data Entry Data EntryCentral Database Support Database/Central Programming Support

TeamCentral DataComm Data CommunicationsCentral Desktop OS Desktop Operating Systems SupportCentral Documentation Documentation ServicesCentral Fiscal Data Fiscal Data Systems TeamCentral General Data General Data Systems TeamCentral Helpdesk Computing Center Support ServicesCentral IBM OS IBM OS Software SupportCentral Instructional Technology Instructional Technology Development GroupCentral Mainframe Print Mainframe Print OperationsCentral Messaging Electronic MessagingCentral Network Management Network Management and User SupportCentral Network OS Network Operating Systems (NetWare)Central NMS Network and Microcomputer ServicesCentral Payroll Personnel Data Payroll Personnel Data Systems TeamCentral Production Services Production Services and Data EntryCentral Remedy Remedy Support Database AdministrationCentral Statistical Research Research and Statistical Support ServicesCentral Student Records Data Student Records Data Systems TeamCentral Student Services Data Student Services Data Systems TeamCentral UNIX Systems UNIX Systems SupportCentral Video Conferencing Video Conferencing and CommunicationsCentral Voice Response Voice Response Applications TeamDistributed APPLICABLE DU Distributed Support Unit of DepartmentDistributed CASCSS Arts & Sciences SupportDistributed CASCSS-Desktop Arts & Sciences Desktop/Applications SupportDistributed CASCSS-GAL Arts & Sciences General Access Lab SupportDistributed CASCSS-GroupWise Arts & Sciences GroupWise SupportDistributed CASCSS-Network Arts & Sciences Network SupportDistributed CASCSS-SysAdmin Arts & Sciences File Server SupportDistributed CASCSS-Web Arts & Sciences Web Server SupportDistributed COBA Classroom Business Classroom Support



Distributed COBA CSS Business HelpDistributed COBA Programming Business Programming SupportDistributed COBA Technical Business Technical SupportDistributed COEGAL COE Lab SupportDistributed COEL1 COE Level 1 SupportDistributed COEL2 COE Level 2 SupportDistributed Computer Advantage Computer Advantage Training GroupDistributed Housing Housing CSSDistributed HSCCSS Health Science CenterDistributed INSTRUCTOR Primary support is from the class instructorDistributed Libraries Libraries LAN/PC ManagementDistributed Library GAL Library General Access LabsDistributed Micro Maintenance Micro MaintenanceDistributed Music CSS Music CSSDistributed Physical Plant CSS Physical Plant CSSDistributed Police PoliceDistributed Purchasing / Printing Purchasing / PrintingDistributed SCS CSS School of Community Service CSSDistributed SLIS Classroom SLIS Classroom SupportDistributed SLIS CSS SLIS General Computer SupportDistributed SLIS GAL SLIS General Access LabDistributed SOVA CSS Visual Arts Computer SupportDistributed SOVA Lab Visual Arts Lab SupportDistributed Student Affairs Student Affairs CSSDistributed Student Service Center Student Service Center CSSDistributed TAMS Admin TAMS Administration SupportDistributed TAMS Lab TAMS Lab SupportDistributed Union Union AdministrationUniversity Budget Budget OfficeUniversity Bursar Bursar's OfficeUniversity Claims Accounting Claims AccountingUniversity Financial Aid Financial AidUniversity GALC General Access Lab CommitteeUniversity GALMAC General Access Lab Managers CommitteeUniversity Human Resources Human ResourcesUniversity ID Card ID Card OfficeUniversity Property Property ControlUniversity Registrar RegistrarUniversity TeleComm TeleCommunications OfficeUniversity Telephone Telephone RepairUniversity UNKNOWN This product needs a second level of supportUniversity Unsupported Unsupported



State Transitions/Life-Cycle

State Definitions

The following table summarizes the various states of a ticket in the problem management process:

State DefinitionNew Default state. Calls are submitted in this state ONLY by Requesters.Assigned Call is assigned to an individual or department but not being worked.Work In Progress Call is being worked.Reassign Call is assigned to the individual’s manager pending reassignment.Pending Awaiting action from an external party.Escalated Call has not been acknowledged within a specific time or the time allotted for

closure has elapsed and requires management’s attention.Resolved Call resolved. No further work required.Closed Call resolution confirmed by user or elapsed time.Reopen Call not adequately resolved and awaiting the assignment process.

Summary of State Transitions/Workflow

All the Possible state transitions are defined by the following table:

State (To)(From) New Assigned WIP Reassign Pending Escalated Resolved Closed ReopenNew Y Y N Y Y Y N NAssigned N Y Y Y Y Y N NWIP N N Y Y Y Y N NReassign N Y Y Y Y Y N NPending N N Y Y Y Y N NEscalated N Y Y Y Y Y N NResolved N Y Y Y Y N Y YClosed N N N N N N N YReopen N Y Y N Y Y Y Y



New State Transitions

Assigned State Transitions



Work In Progress State Transitions

Reassign State Transitions

Pending State Transition



Escalated State Transitions



Resolved State Transitions

Closed State Transitions



Reopen State Transitions



Escalation Policies

Escalation policies will monitor the amount of time each submitted/modified entry remains in a particular status. The schema “HD:EscalateTime” will be created to allow generation of a flexible, soft-coded, policy system that specifies the status and the greatest amount of time any entry may remain in that status before notifications are sent to the assignee, assignee’s supervisor, and department manager respectively. Functionality will also be provided on the main entry schema to allow the immediate escalation of problems.

NOTE: Impact and Priority are separate processes, not linked properties, at least as I understand it. A support technician must assign priority based upon impact. We may WANT to link them with a filter according to our own rationale. If so, what priority do we assign to what impact, keeping in mind the requester hotlist flag.

Impact

Setting Priority

Notes

Campuswide System Down Urgent20+ People out of service UrgentMachine has Virus HighCannot use machine HighCannot use network HighCannot use critical app HighCannot use non-critical app Mediu

mNeeds new software installed Mediu

mNeeds new hardware installed Mediu

mCustomer modified machine/sw

Low

Unsupported hardware/software

Low

Personal hardware/software Low

Priority (drives escalation)

Priority Setting

Requester on Hotlist Time to Escalation (default settings)

Urgent Yes 2 hoursHigh Yes 4 hoursMedium Yes 1 dayLow Yes 2 dayUrgent No 4 hoursHigh No 8 hours (1 day)Medium No 2 daysLow No 4 days



System Configuration

System Server ConfigurationThe underlying server components and services support the UNT Remedy Action Request system are depicted below.



System Schema Configuration

The underlying data table (schema) and workflow relationships are depicted below.



Schema DescriptionsThe problem management "Help Desk" application will consist of the following basic schemas/data objects (Note: the design phase may identify additional schemas/data objects to enable particular functionality if necessary):

Schema Name(s) DescriptonHD-Helpdesk Main application schema which holds information about the problem and

it’s resolution.HD:PeopleInformation Information about UNT affiliated clients.HD:User Schema to hold computer support staff members (consultants) who may be

assigned particular problems. Referenced for auto-assign.HD:Group Schema to hold notification group informationHD:CaseCategory Schema to associate categories, root causes and reason codes.HD:Solutions Schema to associate category codes with resolutions.

HD:EscalateTime Schema to identify escalation policies.HD:Reporting Schema to select “canned” reports or ad-hoc reporting.HD:Reporting-ReportFields Schema to identify which fields from the SR:Problems schema will be

available for ad-hoc reporting purposes from the SR:Reporting schema.SR:Messages (Barnhill add) Schema to special messages to be displayed to the consultant.HD:DepartmentConfig (add?)

Schema to associate department, college, etc. in menus

HD:Equipment (add) Schema to hold computer information for customers (not provided by Remedy’s Help Desk 2.0 template)

The main schema is the Helpdesk Schema. All problems are entered into the database via screens (views) of this schema. The submitter can pull in the Client Information by looking up the client details using either the ‘UNT ID Number’ or ‘Last Name’ fields. Once the client’s information is pulled in, the problem will be categorized by selecting the category, type and item affected.

Detailed listings of the fields and functions of the various schema are described in Part 2 of this document.


Part 1 - Requirements and Configuration.doc

Documents

Transcript of Part 1 - Requirements and Configuration.doc