Part 1 - Requirements and Configuration.doc

574 views
509 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
574
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Part 1 - Requirements and Configuration.doc

  1. 1. Requirements and Analysis Document University of North Texas Computer Services Problem Management Part 1 - Requirements and Configuration Prepared By: Christopher Strauss 19 February, 1998
  2. 2. Table of Contents TABLE OF CONTENTS...............................................................................................................................2 PURPOSE.......................................................................................................................................................3 PROJECT OBJECTIVES.............................................................................................................................4 WORKFLOW REQUIREMENTS...............................................................................................................5 WORKFLOW PROCESS .................................................................................................................................5 PROBLEM ASSIGNMENT AND OWNERSHIP .......................................................................................................5 Type and Source of Tickets......................................................................................................................5 Ticket Entry and Initial Assignment........................................................................................................5 Reassignment of Tickets...........................................................................................................................6 Reopening of Tickets................................................................................................................................6 PROBLEM CATEGORIZATION........................................................................................................................7 Categorization Hierarchy........................................................................................................................7 Categories................................................................................................................................................7 Types (Standard Computing Items).........................................................................................................8 Types (Departmental Entries)..................................................................................................................9 Types (Supplementary Menus).................................................................................................................9 Types (Computing Center Departmental Sub-Entries).........................................................................10 Skills Needed (Referral Points).............................................................................................................11 STATE TRANSITIONS/LIFE-CYCLE..............................................................................................................13 State Definitions.....................................................................................................................................13 Summary of State Transitions/Workflow...............................................................................................13 New State Transitions............................................................................................................................14 Assigned State Transitions.....................................................................................................................14 Work In Progress State Transitions.......................................................................................................15 Reassign State Transitions.....................................................................................................................15 Pending State Transition.......................................................................................................................16 Escalated State Transitions...................................................................................................................17 Resolved State Transitions.....................................................................................................................18 Closed State Transitions........................................................................................................................18 Reopen State Transitions.......................................................................................................................19 ESCALATION POLICIES..............................................................................................................................20 Impact.....................................................................................................................................................20 Priority (drives escalation)....................................................................................................................20 SYSTEM CONFIGURATION....................................................................................................................21 SYSTEM SERVER CONFIGURATION..............................................................................................................21 SYSTEM SCHEMA CONFIGURATION.............................................................................................................22 SCHEMA DESCRIPTIONS............................................................................................................................23
  3. 3. 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 Members Group Name Implementation Project Leader Timothy Christian College of Arts and Sciences Computing Remedy System Administrator Christopher Strauss System Server Administrator John Booth Adaptec Interface integration Jim Curry ManageWise integration Allen Bradley Spectrum integration Blair Copeland Database integration to Directory Services Bill Buntain Macintosh client evaluation Ty Young X11R5 with Motif client evaluation Marc St.-Gil Web client evaluation Mark Wilcox Steering Committee Members Group Name Implementation Project Program Manager and Timothy Christian, Chair College of Arts and Sciences Computing Remedy System Administrator and Computing Christopher Strauss Center Helpdesk College of Education Computing Paul Hons College of Business Administration Computing Jan Brothers Computing Center Academic Computing Philip Baczewski Computing Center Data Communications Mike Maner Health Science Center Tom Newell (possible) Library Network Administration Robert Pierce Physical Plant Computing Cindie Harris School of Community Service Computing Rich Anderson School 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
  4. 4. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES 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 helpdesk@unt.edu 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. DCSMT Call Tracking Project 4
  5. 5. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Workflow Requirements Workflow process. The diagram below describes elements of the problem management process. Case Data Assignment Notification Collection Resolution Closure 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. Types Problem (the default) Question Request Sources Phone (the default) Requester telephones the computer support staff Requester Requester fills out Remedy form themselves – probably in the case of one computer support staff member reporting a problem to another support area or person Walk-In Requester walks in to helpdesk, lab, etc. EMail Request sent to system or operator via e-mail Web Requester filled out an AR Web form NMP 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 DCSMT Call Tracking Project 5
  6. 6. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES 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. DCSMT Call Tracking Project 6
  7. 7. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES 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 Category Acad Mainframe Admin Mainframe Departmental Internet / Intranet Macintosh MS-DOS Netware Network Device NT Server UNIX Desktop UNIX Server Windows 3.x Windows 95 Windows NT DCSMT Call Tracking Project 7
  8. 8. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Types (Standard Computing Items) Type (Computing Items) Admin Apps Application BOOTP DNS DHCP MX Campus Network Communications Connectivity Data Entry Data Jack / Wiring Database Desktop Publishing Dialup Internet Dialup Remote Control Driver / Protocol Electronic Mail File System General Computing Graphics Hardware Information Instructional Support Internet Application Multi Media Network Operating System Other Printing Programming Remote Access Reports Server / Service Spreadsheet Statistics / Math Suite / Works Tech Support Training Tutorials UNT Applications USENET NEWS (nntp:) UserID / Account Utilities Web Word Processing wwWeb (http://; HTML) DCSMT Call Tracking Project 8
  9. 9. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Types (Departmental Entries) Type Arts and Sciences Auxiliary Unit Business Community Service Computing Center Distributed Area Education General Access Labs Health Science Center Housing Human Resources Libraries Library School Micro Maintenance Music Physical Plant Police Purchasing Student Affairs Student Service Center TAMS Union Visual Arts Types (Supplementary Menus) Type Cannot Log In Faculty / Staff Students System Error Usage Question DCSMT Call Tracking Project 9
  10. 10. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Types (Computing Center Departmental Sub-Entries) Type Academic Computing Academic Mainframe Admin Applications Admin Mainframe Administrative Network Admissions Data COM-PLETE Computer Operations Computing Center AA CWIS Web Support Database Support DataComm Desktop OS Documentation Fiscal Data General Data Helpdesk IBM OS Instructional Tech Messaging NetWare NOS Network Management Payroll Personnel Data Production Services Security Statistical Research Student Records Data Student Services Data UNIX Voice Response DCSMT Call Tracking Project 10
  11. 11. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Skills Needed (Referral Points) Org Skill Description Central ABN Support Administrative Network Support Central Academic Computing Academic Computing and GAL Central Academic Mainframe Academic Mainframe User Services Central ACS GAL Academic Computing Services GAL Central Admin Computing Administrative Computing Central Admin Mainframe Administrative Mainframe Central Admissions Data Admissions Data Systems Team Central Applications Applications Central CC Security CC Security Central COM-PLETE COM-PLETE Central Computer Operations Mainframe Computer Operations Central Computing Center Computing Center Administration Central CWIS Web Support CWIS and Central Web Support Central Data Entry Data Entry Central Database Support Database/Central Programming Support Central DataComm TeamCommunications Data Central Desktop OS Desktop Operating Systems Support Central Documentation Documentation Services Central Fiscal Data Fiscal Data Systems Team Central General Data General Data Systems Team Central Helpdesk Computing Center Support Services Central IBM OS IBM OS Software Support Central Instructional Technology Instructional Technology Development Group Central Mainframe Print Mainframe Print Operations Central Messaging Electronic Messaging Central Network Management Network Management and User Support Central Network OS Network Operating Systems (NetWare) Central NMS Network and Microcomputer Services Central Payroll Personnel Data Payroll Personnel Data Systems Team Central Production Services Production Services and Data Entry Central Remedy Remedy Support Database Administration Central Statistical Research Research and Statistical Support Services Central Student Records Data Student Records Data Systems Team Central Student Services Data Student Services Data Systems Team Central UNIX Systems UNIX Systems Support Central Video Conferencing Video Conferencing and Communications Central Voice Response Voice Response Applications Team Distributed APPLICABLE DU Distributed Support Unit of Department Distributed CASCSS Arts & Sciences Support Distributed CASCSS-Desktop Arts & Sciences Desktop/Applications Support Distributed CASCSS-GAL Arts & Sciences General Access Lab Support Distributed CASCSS-GroupWise Arts & Sciences GroupWise Support Distributed CASCSS-Network Arts & Sciences Network Support Distributed CASCSS-SysAdmin Arts & Sciences File Server Support Distributed CASCSS-Web Arts & Sciences Web Server Support Distributed COBA Classroom Business Classroom Support DCSMT Call Tracking Project 11
  12. 12. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Distributed COBA CSS Business Help Distributed COBA Programming Business Programming Support Distributed COBA Technical Business Technical Support Distributed COEGAL COE Lab Support Distributed COEL1 COE Level 1 Support Distributed COEL2 COE Level 2 Support Distributed Computer Advantage Computer Advantage Training Group Distributed Housing Housing CSS Distributed HSCCSS Health Science Center Distributed INSTRUCTOR Primary support is from the class instructor Distributed Libraries Libraries LAN/PC Management Distributed Library GAL Library General Access Labs Distributed Micro Maintenance Micro Maintenance Distributed Music CSS Music CSS Distributed Physical Plant CSS Physical Plant CSS Distributed Police Police Distributed Purchasing / Printing Purchasing / Printing Distributed SCS CSS School of Community Service CSS Distributed SLIS Classroom SLIS Classroom Support Distributed SLIS CSS SLIS General Computer Support Distributed SLIS GAL SLIS General Access Lab Distributed SOVA CSS Visual Arts Computer Support Distributed SOVA Lab Visual Arts Lab Support Distributed Student Affairs Student Affairs CSS Distributed Student Service Center Student Service Center CSS Distributed TAMS Admin TAMS Administration Support Distributed TAMS Lab TAMS Lab Support Distributed Union Union Administration University Budget Budget Office University Bursar Bursar's Office University Claims Accounting Claims Accounting University Financial Aid Financial Aid University GALC General Access Lab Committee University GALMAC General Access Lab Managers Committee University Human Resources Human Resources University ID Card ID Card Office University Property Property Control University Registrar Registrar University TeleComm TeleCommunications Office University Telephone Telephone Repair University UNKNOWN This product needs a second level of support University Unsupported Unsupported DCSMT Call Tracking Project 12
  13. 13. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES State Transitions/Life-Cycle State Definitions The following table summarizes the various states of a ticket in the problem management process: State Definition New 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 Reopen New Y Y N Y Y Y N N Assigned N Y Y Y Y Y N N WIP N N Y Y Y Y N N Reassign N Y Y Y Y Y N N Pending N N Y Y Y Y N N Escalated N Y Y Y Y Y N N Resolved N Y Y Y Y N Y Y Closed N N N N N N N Y Reopen N Y Y N Y Y Y Y DCSMT Call Tracking Project 13
  14. 14. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES New State Transitions Assigned Assigned WIP WIP Reassign Reassign New Pending Pending New Escalated Escalated Resolved Resolved Closed Closed Reopen Reopen Assigned State Transitions New New WIP WIP Reassign Reassign Assigned Assigned Pending Pending Escalated Escalated Resolved Resolved Closed Closed Reopen Reopen DCSMT Call Tracking Project 14
  15. 15. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Work In Progress State Transitions New New Assigned Assigned Reassign Reassign Pending Pending WIP WIP Escalated Escalated Resolved Resolved Closed Closed Reopen Reopen Reassign State Transitions DCSMT Call Tracking Project 15
  16. 16. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES New New Assigned Assigned WIP WIP Reassign Pending Pending Reassign Escalated Escalated Resolved Resolved Closed Closed Reopen Reopen Pending State Transition New New Assigned Assigned WIP WIP Pending Pending Reassign Reassign Escalated Escalated Resolved Resolved Closed Closed Reopen Reopen DCSMT Call Tracking Project 16
  17. 17. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Escalated State Transitions New New Assigned Assigned WIP WIP Escalated Reassign Reassign Escalated Pending Pending Resolved Resolved Closed Closed Reopen Reopen DCSMT Call Tracking Project 17
  18. 18. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Resolved State Transitions New New Assigned Assigned WIP WIP Resolved Reassign Reassign Resolved Pending Pending Escalated Escalated Closed Closed Reopen Reopen Closed State Transitions New New Assigned Assigned WIP WIP Reassign Reassign Closed Closed Pending Pending Escalated Escalated Resolved Resolved Reopen Reopen DCSMT Call Tracking Project 18
  19. 19. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Reopen State Transitions New New Assigned Assigned WIP WIP Reassign Reassign Reopen Reopen Pending Pending Escalated Escalated Resolved Resolved Closed Closed DCSMT Call Tracking Project 19
  20. 20. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES 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 Priorit Notes y Campuswide System Down Urgent 20+ People out of service Urgent Machine has Virus High Cannot use machine High Cannot use network High Cannot use critical app High Cannot use non-critical app Mediu m Needs new software installed Mediu m Needs new hardware installed Mediu m Customer modified Low machine/sw Unsupported Low hardware/software Personal hardware/software Low Priority (drives escalation) Priority Requester on Hotlist Time to Escalation (default settings) Setting Urgent Yes 2 hours High Yes 4 hours Medium Yes 1 day Low Yes 2 day Urgent No 4 hours High No 8 hours (1 day) Medium No 2 days Low No 4 days DCSMT Call Tracking Project 20
  21. 21. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES System Configuration System Server Configuration The underlying server components and services support the UNT Remedy Action Request system are depicted below. REMEDY ARCSERVE SQL SERVER REMEDY IMPORT TOOL BACKUP NT BACKUP EXPORT DATA IMPORT DATA BACKUP AT THREE DIFFERENT LEVELS FLASHBOARDS SERVER REMEDY AR ARMAIL REMEDY AR SERVER SERVER WEB SERVER MS SQL EXCHANGE INTERNET INFO PAGING SERVER SERVER SERVER (IIS) SOFTWARE WINDOWS NT SERVER4 MMS SUPERSERVER DUAL PENTIUM PRO 200 WITH INTERNAL BUILT-IN DLT TAPE BACKUP DRIVE MODEM DCSMT Call Tracking Project 21
  22. 22. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES System Schema Configuration The underlying data table (schema) and workflow relationships are depicted below. HD:HELPDESK HD:PEOPLE HRMIS (CASE or CALL INFORMATION DATABASE CUSTOMER CALL, WALK-IN, E-MAIL, TICKET) WEB-FORM, OR CUSTOMER SRS OTHER CONTACT CUSTOMER INFORMATION DATABASE INFORMATION EQUIPMENT MMS EQUIP PROBLEM INFORMATION DATABASE DETAILS HD:USER CATEGORIZE HD:CASE (HELPDESK) PROBLEM CATEGORY SEARCH FOR HD:SOLUTIONS SOLUTION ASSIGN CASE HD:WORK NOTIFICATION SCHEDULE HD:GROUP ROUTE / WORK IN PROGRESS PRIORITY HD:USER HD:ESCALATE TIME (CONSULTANTS) RESOLVE CASE KNOWLEDGE KNOWLEDGE BASE ENTRY BASE REVIEW DCSMT Call Tracking Project 22
  23. 23. Requirements and Analysis Document - Part 1 - UNT COMPUTING SERVICES Schema Descriptions The 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) Descripton HD-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 information HD: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 Schema to associate department, college, etc. in menus (add?) 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. DCSMT Call Tracking Project 23

×