Dmdc ccc-ticketing system requirements v7b

1,834 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,834
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dmdc ccc-ticketing system requirements v7b

  1. 1. DefenseManpowerDataCenter Consolidated ContactCenter - PSA _ CSR Ticketing System Business Requirements Document(BRD) Version 1.1 - Ken Fulmer Feb 21, 2013 INSPIRITEC CONFIDENTIAL MATERIAL
  2. 2. INSPIRITEC CONFIDENTIAL Document Version Control Version Date Change Description Author 1.0 2/15/13 Initial version Ken Fulmer 1.1 2/21/13 Updated with comments from 2/20/13 review Alecia Chrin TABLE OF CONTENTS 1 PROJECT OVERVIEW ............................................................................................................ 3 1.1 1.2 2 Business Areas Impacted ........................................................................................ 3 Business Assumptions ............................................................................................ 3 REQUIREMENTS .................................................................................................................... 5 2.1 Business Requirements ........................................................................................... 5 2.1.1 Ticket Information Requirements ................................................................................ 5 2.1.2 SSN Privacy approach ................................................................................................ 9 2.1.3 Application and Sub Application Areas ..................................................................... 10 2.1.4 Knowledge Base Requirements................................................................................ 11 2.1.5 Escalation Procedure Requirements ........................................................................ 11 2.1.6 Tracking and Monitoring ........................................................................................... 12 2.2 Interface Requirements .......................................................................................... 13 2.3 Report Requirements ............................................................................................. 13 2.3.1 Report 1 - The Daily Operations Report ................................................................... 13 2.3.2 Report 2 – AQL Report ............................................................................................. 14 2.3.3 Report 3 – Monthly Operations Summary ................................................................ 14 2.4 Non-Functional Requirements............................................................................... 15 Page 2 of 15 DMDC-CCC Business Requirements Document
  3. 3. INSPIRITEC CONFIDENTIAL 1 PROJECT OVERVIEW The primary purpose of this document is to set the scope and requirements for the Personnel Security Assurance (PSA) ticketing system, which will be leveraging the Computer Associates (CA) Service Desk Manager (CA-SDM) application. The system will be used to take phone calls and other contacts to get support for key PSA systems as described in the Consolidated Contact Center (CCC) Performance Work Statement (PWS). The CA Service Desk Manager was selected as it is integrated with other Defense Manpower Data Center (DMDC) call center components, and therefore is a logical tool to use for the CCC operation. There was a further decision to install the system on site at Ft.Knox, to enable a simplified network operation for a short term start up. The scope of the system is short term focused to get operational with the PSA calls by April 1, 2013, the go live date. The system will track the call status of all PSA calls that DMDC is responsible for, including the Joint Personnel Adjudication System (JPAS), Electronic Questionnaires for Investigations Processing (e-QIP), Defense Central Index of Investigations (DCII), and Secure Web Fingerprint Transmission (SWFT) systems. It will also handle all contact types (phone, email, etc.) as well three (3) escalation levels. The first escalation level is the Tier 1 contact center reps who have been trained in handling calls in a specific problem area; calls will be directed to the Tier 1 reps via a call routing capability in the phone switch to a queue. That queue will be responded to by the first available agent in that area. The second escalation level is the Tier 2 reps; these are more deeply trained specialists and trainers who also can spend more time with the caller or conduct research. The Tier 2 reps are part of the contact center staff. The third level of escalation is Tier 3. Escalation to Tier 3 takes place when a contact issue is needed to be sent to someone outside the direct control of the contact center. The call tracking system will keep track of the issue and age the issues for time outstanding, and track the issue until it is resolved. Reporting is also part of the scope of this requirement definition. There are several types of reports - for operational, AQL management, and internal performance management needs. Reports are mostly run on a schedule, but can also be ad-hoc. Scheduled and ad-hoc reports and queries are intended to remain small, so that they minimize the performance impact on the call center’s CA-SDM application. 1.1 Business Areas Impacted The ticketing system is for use by InspiriTec to be used in support of the DMDC consolidated contact center. 1.2 Business Assumptions This section documents any assumptions related to the project. Page 3 of 15 DMDC-CCC Business Requirements Document
  4. 4. INSPIRITEC CONFIDENTIAL Identifier Assumption Internal or External AS1 There are no electronic interfaces from the call tracking system to DMDC applications in scope at this time. DMDC and caller impact AS2 The startup date will constrain decisions to take a short term focus to get operational in a timely manner. External AS3 All calls/contacts will be closed in the ticketing system. Any Tier 3 agency or group will need to communicate ticket closure status back to the contact center. InspiriTec will track all calls and update status info until closure AS4 Infrastructure such as network and telephony is the responsibility of Ft. Knox and DMDC government organizations. Per project plan AS5 Responsibility for backups will be with the Fort Knox Data Center, this is agreed upon by Ft. Knox NEC. FortKnoxDataCenter AS6 Responsibility for patching the OS will be with the FortKnoxDataCenter. FortKnoxDataCenter AS7 Responsibility for patching Service Desk will be with HP / InspiriTec. Responsibility for patching SQL Server will be with the FortKnoxDataCenter. HP/InspiriTec Availability of Military Base Facilities and Infrastructure will be the responsibility of Ft.Knox and DMDC government organizations. DMDC, Ft. Knox NEC AS8 AS9 FortKnoxDataCenter Page 4 of 15 DMDC-CCC Business Requirements Document
  5. 5. INSPIRITEC CONFIDENTIAL 2 REQUIREMENTS This section presents requirements that must be fulfilled by the proposed solution. 2.1 Business Requirements The Service Desk ticketing system will allow the PSA contact center operation to capture, track and report on all functional and technical inquiries received by InspiriTec’s PSA agents. PSA agents will provide support for the following applications: DCII, JPAS, e-QIP and SWFT and provide response to related procedural and policy inquiries. The ticketing system should support relevant sub-tasks which may include: 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16) Assist users with application execution / installation Assist with completing user application Reactivate record within eQIP or JPAS Troubleshoot/resolve application issues Review site/application ticket call history (See reporting section) Clearly document customer issues in trouble ticket Answer FAQs Other technical support as needed Escalate issues as needed via a DMDC application such as Data Request System (DRS); See escalation procedures Explain policies and procedures applicable to the personnel security program Troubleshoot all client call problems within scope of the defined PSA applications. Update/create troubleshooting documents for common issues to provide to customers. Provide customers with troubleshooting documents Contribute towards DMDC Message Board- CCC will provide monthly suggested updates. This is not an electronic interface. Monitor email, fax, voicemail, and other customer communication methods. Provide and update recorded announcementsin the event of any system outage or production slowdown to avoid callers reaching an agent to get the same information. of any agency or location wide issue for customers calling the call center The following sections outline the minimum requirements of the current Personnel Security/Assurance Applications Information Management System (IMS). All fields are subject to change in the future as needed. 2.1.1 Ticket Information Requirements All Tickets will collect the basic information listed below. Page 5 of 15 DMDC-CCC Business Requirements Document
  6. 6. INSPIRITEC CONFIDENTIAL 2.1.1.1 Contact Profile Information Field Name Description Name Primary phone number (unique key) SMO code Format Full Name Used as primary lookup Security Management Office code CAGE code Email address Alt Phone number User ID User Key Work Default 10 digit plus 4 for ext 7 nd Allow 2 phone optional To Be Defined by User(optional) 7 Default 10+4 Default 12 characters alphanumeric a) Contact primary phone number (This will be the first field entered), and is the key between the contact info and the ticket info. b) User’s name will be captured and verified by the Customer Service Representative (CSR) to confirm the caller’s id along with at least one other item of verification from the contact profile to validate that the caller is who they say they are. c) User’s email address will be used if follow-up is required d) User’s alternate phone for call back, if other than the primary phone number. 2.1.1.2 Ticket Information Field Ticket Number Type Application Area Comments System generated with YY as a prefix Incident or Request Default to Incident List of Values – JPAS, eQIP, SWFT, DCII, General, SAR Length Default field length and structure Default CA-SDM Category Application Sub Area See Table below for values Source of Ticket Need By Date Caller Social Security Number (SSN) Affected Phone, Fax, Email, Paper Mail, Web, Other CA-SDM Sub Category for each category Drop Down List Customer requested completion date Default Use if required - will be displayed only to the rep assigned to the ticket 9 numeric – no dash or space Optional field – use if needed Default name field Page 6 of 15 DMDC-CCC Business Requirements Document
  7. 7. INSPIRITEC CONFIDENTIAL Field Subject Name Affected Subject SSN Affected Subject Date of Birth Affected Subject Phone # Affected Subject email Nominating Official Name Priority Problem Description Problem Summary Notes Status SAR Resolution Escalation Root Cause Related Ticket Number Ticket Date, time indicators Comments Length length Use if required - display only to the agent who is currently assigned the ticket 9 numeric Use only if required MM/DD/YYYY Use only if required 10+4 Use only if required Default Use only if required – optional text field to be used as needed on SAR and other tickets. Default for a name Default 1-5 Values to Be defined Open field text to describe the problem Default Default length Optional Summary of Problem Default length Area to describe ticket activity and changes to the ticket and who made the change and when Open, Closed, Tier 3, Under Review and Waiting Processed And Accept Accept or Rejected with reason codes of: i. Reject - Obsolete SAR form submitted ii. Reject - Incomplete SAR iii. Reject - No LOA submitted (JPAS primary account managers – Industry) iv. Reject -Nominating official not KMP in ISFD v. Reject - Military’ request (JPAS) vi. Reject - User’ (or ‘non-primary’ account manager) request (JPAS, DCII, SWFT) vii. Reject - Applicant not eligible for requested access viii. Reject - Applicant already possesses requested access Change in ticket assignment in terms of the person or group Table of Values – Hold for future table definition Optional field - with up to 5 values of ticket numbers Default values and length Default List of Values Ticket open – date/time, close date/time ; status change date/time, etc. Use standard values of CA-SDM Default List of Valid Values Alphanumeric, 50 characters Page 7 of 15 DMDC-CCC Business Requirements Document
  8. 8. INSPIRITEC CONFIDENTIAL All ticket fields are defaulted to the standard system values where possible, including links to the knowledge base and to the contact profile information. For AQL reporting purposes a ticket is open whether it is open to Tier 1 or Tier 2. 2.1.1.2.1 Handling of the Affected Subject Information Some tickets will not be about the caller but about an affected subject. An example is an industrial Facility Security Officers (FSO) calling about a person in their organization applying for a security clearance. In cases where it is appropriate to the ticket the agent will fill in the Affected Subject data values as needed. The SSN value is usually required for such situations, and as such the SSN follows the same Personally Identifiable Information (PII) rules of only being displayed to the agent who has the ticket assigned and is left blank in all other situations. 2.1.1.2.2 Default Values The normal Service Desk Management handling values are assumed to take the defaults. A partial list is included here for illustration Ticket number –Sequential number assigned by the system Date/time opened – System assigned based on system date and time Days/time elapsed – System calculated based on time open to time closed Date/time closed – Entered by system date at the time the ticket is in status = closed Related Ticket Number – Assigned by CSR for any reference – optional field with up to 5 values of ticket numbers. Page 8 of 15 DMDC-CCC Business Requirements Document
  9. 9. INSPIRITEC CONFIDENTIAL 2.1.2 SSN Privacy approach The Social Security Number (SSN) privacy solution for the PSA helpdesk will be similar to, and based on the solution used by the DMDC Support Office (DSO) call center solution. Not only will this approach provide an easier transition when DSO is brought into the CCC solution, but it will also provide consistent protection for PII data. This solution will only display the SSN to the CSR assigned to the ticket. When a PSA phone call goes to the CSR, the CSR/System will call up the CA SDM contact record using the caller's Primary Phone Number. The CSR will use the SSN to access JPAS through the application itself. Since CA-SDM assigns a 'ticket number' or 'case ID' to each caller event, the information about the CSR resolution will be stored by case ID or ticket number in the comments section. No PII data will be written into the text because the CSR resolution information is linked to the contact information by case ID/ticket number in the application. With this approach, there will always be a way to find out incident history for a given caller. The requirements for this approach are listed below: Each ticket will support only 1 affected user. If an FSO calls about multiple affected users, that will result in multiple tickets. The contact database will not be pre-populated with data. As incidents are received, the contact database will be populated over time with user information. Each incident will contain 2 custom fields: Caller SSN, and Affected Party SSN o Any values optionally entered in these fields will be displayed only to the person to whom the ticket is assigned o These fields will not appear on any reports o These fields will not be transferred to Tier 3 o The fields will be visible only to the CSR to whom the ticket is assigned o Tickets are assigned to an agent by name All ticket creation will begin in the Profile Browser. When the ticket is created, the Assignee field will be auto-populated with the creator name. The ticket will always have an Assignee who can view the SSN, if an SSN is entered. Typical process flow o FSO calls; CSR will ask for name, email, phone number, etc. If the FSO’s contact exists in the system, the appropriate fields will auto-populate o FSO will describe the inquiry for the affected party o If the inquiry requires storing the SSN, agent will ask for the SSN by phone, and enter it in the appropriate field All adjusting "activity" done to the ticket is inherently tracked. When a ticket is escalated to Tier 3 o Status is set to “Moved to Tier3” o Ticket stays assigned to a Tier 2 agent o Updates to the ticket are made by the Tier 2 agent o If there is an SSN related inquiry from Tier 3, the assigned Tier 2 agent will look up the Affected Party SSN field and relay the SSN over phone to the Tier 3 agent The SSN will not be encrypted in the database for the current phase Page 9 of 15 DMDC-CCC Business Requirements Document
  10. 10. INSPIRITEC CONFIDENTIAL 2.1.3 Application and Sub Application Areas Application Sub-Application JPAS Password Reset Account Setup Tech Question General/Other Record Reactivation eQIP Password Reset Golden Question reset Application Submission Tech Question SWFT Password Reset Account Setup General/Other Tech DCII Account Setup Password Reset Tech General/Other General Adjudicative/Clearance Inquiry Investigation Status General Personnel Inquiry Compelling Need Congressional Inquiry –Govt. SAR JPAS, SWFT DCII Page 10 of 15 DMDC-CCC Business Requirements Document
  11. 11. INSPIRITEC CONFIDENTIAL 2.1.4 Knowledge Base Requirements 1) There will be several thousand knowledge base articles in the ticketing system to support the information needed to respond to calls. Either the full text of the information, or a Uniform Resource Locator (URL) link to the information will be stored in the CA-SDM ticketing system 2. The information will have a header record that will contain the following fields: Title, Description, and Resolution information; and this will be used for search and retrieval. This information will be assigned by InspiriTec on each Knowledge Management (KM) article for loading into the KM database. 3. The KM articles will be in the Acrobat PDF format for inclusion into the KM database . 4. The template for loading the PDF articles is as follows: Category (e.g. JPAS) Title of Article Problem Summary This section will contain keywords FileName for the attachment 5. The underlying articles will contain both specific solutions for solving common problems, as well as entire online user guides, administrator guides, and other documents for use by the CSR, or Tier 2 reps in resolving problems. So, an attached PDF file may be as small as 1-3 pages, or it could be alarge document of 100+ pages. 2.1.5 Escalation Procedure Requirements While the ultimate goal is to create a one call resolution philosophy, processes have been developed to accommodate Tier 2 and Tier 3 escalations 2.1.5.1 Tier 2 Escalation Requirements The following types of calls are usually escalated to the Tier 2 reps: Customer complaints of service, either via phone or email Advanced troubleshooting If the Tier 1 CSR cannot resolve the issue within 5 minutes or whatever the sub-application guideline indicates, the call will be escalated to Tier 2. Any call that is beyond the skill level of knowledge of the Tier 1 CSR to resolve will also be escalated to the team leader for that application area. The phone call and ticket information will be saved, and the issue will be transferred to the team leader, who will act as the Tier 2. Since the CA-SDM ticket doesn’t have the capability to make the assessment if the ticket is beyond the skill level of the CSR, a manual assignment of the ticket by the Tier 1 CSR to Tier 2 will take place. At the time of the transfer, the status of the ticket will be set to “Open” and moved to Tier 2 for handling of the ticket. Information will otherwise remain unchanged until acted upon by the next agent in Tier 2.A status of Under Review and Waiting is assigned if the ticket requires special research to finalize the issue. For AQL reporting, the status will report which level of agent is handling the call, and for what period of time. Page 11 of 15 DMDC-CCC Business Requirements Document
  12. 12. INSPIRITEC CONFIDENTIAL At the completion of the Tier 2 escalation, if the issue is resolved, the disposition of the ticket will be noted as “Closed”, and the resolution will be added into the description field for the CSR to review. If the issue is not resolved, then it will be marked as needing follow-up, but will not be completed in real time. This will initiate the date and time of the status tracking. In the reporting section, any item that is not closed, and not escalated to Tier 3 will be aged, and a daily operations review will focus on any items that are open for more than one day, and a plan developed for each item to be resolved. If items age more than 2 business days, then the Call Center Manager will decide if those calls need to be elevated to Tier 3 for assistance. 2.1.5.2 Tier 3 Escalation Requirements o o o o o o 2.1.6 2.1.6.1 Any call or contact that cannot be resolved by the on-site call center would need to be transferred to specialists outside the call center, such as to DMDC, Defense Security Service (DSS), the sustainment team, or other contract firms for resolution. The ticket will be marked as escalated to the organization that it is being transferred to. The ticket date and time of the escalation will be recorded to the database, and the specific person or group assigned will be noted. A status code of “Moved to Tier 3” will be established and assigned to tickets escalated to Tier 3. This will leave the ticket still assigned to a Tier 2 agent on site, and that Tier 2 agent will have control of the ticket while any offsite follow-up at Tier 3 is taking place. A manual email follow-up to the DMDC program office, and to the receiving organization will be generated to confirm that this action has been taken, and the email will contain the ticket number and relevant information from the description. In the email, the Tier 2 agent will select text from the description field and cut and paste that into the email system for manual email forwarding. In addition, the agent may call the Tier 3 group to confirm receipt for the ticket handling. Also included will be instructions to send notice back to the On-Site Call Center so that the ticket can be tracked, and closed upon notice back of final disposition from the Tier 3 group. The Government lead will attempt to resolve the issue. If not able to do so, the issue will be forwarded to Program Manager for further assistance. All issues statuses will be logged in the Tier 2 Support Tracking Log. Tracking and Monitoring Tracking Access Types In CA-SDM, there are Access Types associated with the Contact Types. The standard Contact Types in CA-SDM are: Analyst Employee Group Guest For this implementation, we will create two(2) Access Types for the Analyst Contact Type: Page 12 of 15 DMDC-CCC Business Requirements Document
  13. 13. INSPIRITEC CONFIDENTIAL Analyst I Analyst II These two Access Types will allow CA-SDM to differentiate between Tier I and Tier 2 Analysts. All Tier 1 agents will have an Access Type of Analyst I, and all Tier 2 agents will have an Access Type of Analyst II in CA-SDM. One can find out if a given agent is part of the Tier 1 or the Tier 2 group by clicking on the agent’s name in the ticket; this will take the user to the agent’s contact info where the Access Type will reveal if the agent is a Tier 1 or Tier 2 agent. 2.1.6.2 Monitoring Ticket Escalation Level In order to monitor ticket escalation levels (identify if a given ticket is being worked on at the Tier 1 or the Tier 2 escalation level), the solution will be implemented with a checkbox to indicate that the ticket is being escalated to Tier 2. When the ticket is being moved to Tier 2, the Analyst would check the box and save the ticket. This would create an entry in the activity log when field is changed. One can see if a ticket is being worked by the Tier 1 or Tier 2 agents by inspecting if the checkbox is "checked". Further, by adding the auditing of the checkbox, one can also identify who escalated the ticket to Tier 2, and when the escalation took place. The Status field on the ticket can be used to verify if a ticket has been transferred to Tier 3. 2.2 Interface Requirements There are no electronic interfaces at this time. 2.3 2.3.1 Report Requirements Report 1 - The Daily Operations Report The Daily operations report will provide a list of all tickets for the past business day, by application type in the summary. The Daily Operations Report will show all tickets handled within 5 minutes and all calls exceeding 5 minutes, sorted by application type and by count. For all ticket open times exceeding 7 minutes a list of the ticket numbers will be displayed. For all tickets in a status of Open for more than 24 hours, and Not of the Category=SAR, those tickets will be listed by application area, by ticket number. For all tickets marked as type = SAR, and open more than 72 hours, the ticket will be listed by ticket number with the SAR type and sub-application identified. Page 13 of 15 DMDC-CCC Business Requirements Document
  14. 14. INSPIRITEC CONFIDENTIAL 2.3.2 Report 2 – AQL Report 2.3.3 Report 3 – Monthly Operations Summary The report will show a total of all tickets received, sorted by application area, and then by source of the contact (e.g. JPAS, by phone, by email, by fax, etc.). The report will show all tickets sorted by contact type, and then by application area. The report will show all tickets, sorted by type, and averages for daily call volume by application. The report will show the total number of Compelling Need (DoD CAF) tickets The report will show the total number of Personnel Inquiry Write-ups contacts The report will show a summary of SAR accepted and rejected with list of rejection reasons. If the ticket type = SAR, exclude from report If status = tier 3, exclude from the report Monthly Operations Summary Reporting Requirements Requirement The report will show a total of the following: Data Types Tickets Received Application Area Source of the Contact The report following: will show the Total Tickets in period Contact type Application Area The report will the show the following: Sub Applic within each Application area Source of contact Daily average of call volume total and by Application Area The report will show the following: The report will show the total number of General Personnel Inquiry tickets The report will show a summary of SAR accepted and rejected with list of rejection reasons sorted by Total of all General category tickets. ApplicationArea= Personnel Inquiry SAR accepted SAR rejected List of rejectioncode Data Structure Contacts received, sorted by application area, and then by source of the contact (JPAS, phone,email, fax, etc.) All contacts sorted by contact type and then by application area. The report will show all contacts, sorted by type, and averages for daily call volume by application. Contact received information for records that meet the Application area= General Personnel Inquiry requirement All SAR requests filtered by Accepted type and Rejected type. . Page 14 of 15 DMDC-CCC Business Requirements Document
  15. 15. INSPIRITEC CONFIDENTIAL frequency of occurrence counts 2.4 Non-Functional Requirements Non-Functional requirements include organizational changes, training, or documentation requirements such as user manuals. The non-functional requirements are listed below. ID Special Requirement Priority Requirement Type Source NFR1 Resource Training High Training development InspiriTec NFR2 Training the trainer High Training development DMDC NFR3 Training Materials Development- Create materials necessary to provide training remotely High Training development InspiriTec Page 15 of 15 DMDC-CCC Business Requirements Document

×