2.14.2  Enterprise Incident Management Standards

2.14.2.1  (03-17-2010)
Introduction

  1. This IRM establishes uniform Enterprise Incident Management (EIM) standards as it relates to providing support to the MITS customers, while utilizing the Enterprise Incident Management Tools, Information Technology Asset Management System Incident Management (ITAMS IM ) also known as ITAMS Service Center (ITAMS SC), OS GetServices, FindIT and Password Management. The MITS support process is defined as the organized approach to documenting both the process and the results in support of our customers on a single database. IRS management at each site is responsible for ensuring compliance within these standards meet Master Service Level Agreements.

  2. The workflow tool for all MITS Service Providers is the ITAMS IM module, for reporting and tracking all MITS incidents and service requests (i.e., system software, application software, telecommunications, or hardware) and any related documentation problems. EIM Standards IRM documents the methodology for incident reporting, tracking, and service requests.

  3. The ITAMS IM module contains the workflow tool for the Employee Resource Center (ERC) in Agency Wide Support Services (AWSS) and its related service providers. This IRM only covers providers serviced by the MITS Enterprise Service Desk (ESD) and addresses shared processes between the two as applicable. The ITAMS system also includes the Asset Center Module. The standards and policies for that system can be found in IRM 2.14.1.

  4. The ESD and ERC also share use of a common toll free number via an ACD and a common customer portal using OS GetServices http://getservices.web.irs.gov .

  5. The ITAMS IM module also serves as the ESD tool, which provides the agency with a centralized database for MITS Incident Management, Problem Management, Knowledge Management, and Asset Management. Detailed instructions for the ITAMS IM Module can be found in the ITAMS IM User Reference Guide http://esm1.enterprise.irs.gov . All MITS service requests and Incidents will be reported to the ESD based on enterprise procedures and/or via the MITS OS GetServices web site http://getservices.web.irs.gov or e-mail and/or via calls as procedures dictate. The customer experiencing a problem with any MITS resource is responsible for timely reporting of said problem to the ESD i.e. web site, e-mail, toll free number, etc.

  6. The ESD is the single point of contact for MITS requests and Services. The ESD is responsible for monitoring, tracking and escalating all Priority 1 and 2 incidents. The Service Operations Specialists (SOSs) will monitor P1 and P2 tickets to ensure progress and updates are being made towards resolution of the incident. A Service Restoration Team (SRT) conference call will be initiated by the SOSs with the responsible Service Providers if progress is not being made on resolution or if multiple service providers are needed to resolve the P1 or P2 incident. Each Service Provider manager is responsible for monitoring, tracking and escalating Priority 3-5 incidents or service requests.

  7. The ESD's responsibility is the initial triage and resolution of incidents. If the ESD is unable to resolve, then the incident will be assigned to the appropriate Service Provider for resolution. To ensure quality customer service, the ESD should never refer a customer to another MITS Service Provider; instead the Enterprise Incident Management Standards IRM process should be followed to route customer requests to the appropriate service organization using Probe and Response or established procedures. The ESD is responsible for monitoring incident process on behalf of the customer through resolution and through the escalation process.

  8. All enterprise Service Providers are responsible for timely updates on all assigned incidents with relevant update notes and for validating ITAMS codes including but not limited to resolution code, project code, cause code, program name, key word, incident stop date/time and priority. These codes are determined in conformance with the standard coding values based on the specifics of each incident. The online Probe and Response guide contains the knowledge base for standard incident coding, incident assignment, Level I triage and resolution solutions for frequently reported problems. Service Providers (Level 2) personnel should ensure that an ITAMS incident is opened if an incident or service request is received directly from the customer. This can be accomplished by ensuring the customer has contacted the ESD and received an incident ticket or by utilizing the http://getservices.web.irs.gov site and opening the incident ticket on behalf of the customer and providing enough information to instruct the assignment of the incident to the proper Service Provider. The Service Provider opening the incident shall use the Probe and Response Guide knowledge base to determine and assign to the appropriate Service Provider.

  9. Any organization/Project office or modernization project that requires incident management support from the ESD is required to submit the information outlined in the Request for MITS Service Desk Support Project Package located on http://eues.web.irs.gov/ESD/ESD-MAIN.aspx . This document defines the ESD requirements, which must be provided to EUES before routing calls to the ESD for new projects/requests for service.

  10. Listed below are the various methods in which a MITS customer may use to contact the ESD. All MITS customers reporting a mission critical, work stoppage or a potential work stoppage, will be required to report the incident via phone. All mission critical & potentially mission critical incidents will require a follow-up phone call to the ESD Escalation Queue when utilizing e-mail. Mission critical and potentially mission critical incidents cannot be reported via OS GetServices. Should a customer open a mission critical incident using OS GetServices, the incident will be closed and a new one opened by the ESD as this will impact the systemic and manual escalation alert process as defined in Section 2.14.2.7. The various methods for contacting the ESD are listed below:

    • PHONE
      1-866-743-5748 (18667HELP4U)
      Select Option 2 - Information Technology Support Desk
      Listen to the prompts to reach the appropriate Enterprise Service Desk Specialist

    • TTY
      1–866–435–7486

    • E-MAIL
      External E-mail: MITS.EUES.enterprise.service.desk@irs.gov
      Internal E-mail: *MITS-EUES Enterprise Service Desk
      A follow-up phone call to ESD will be required when reporting mission critical Priority 1 or potentially mission critical Priority 2 incidents when using this method to report an incident.

    • Web Ticketing
      http://getservices.web.irs.gov
      Mission critical work stoppage or potential work stoppage incidents cannot be reported using this method.

  11. Enterprise Service Desk Service Level Agreements are listed below:

    • ESD will answer the Escalation Queue Calls (Work Stoppage/Potential Work Stoppage) within 2 minutes.

    • ESD will answer all other calls within 2 minutes.

    • ESD will respond to a VMS by contacting the customer within 4 business hours.

    • ESD will respond to e-mail requests or incident/requests submitted via OS GetServices by contacting the customer for triage, resolution/additional information, or reassigning to a more appropriate Service Provider within 2 hours of receipt of the incident.

    • ESD will perform 100% callback on all contacts. Customers will identify their preferred contact method, either e-mail or phone. The resolution closure e-mail generated by ITAMS will satisfy this requirement for those choosing e-mail. For customers choosing phone, ESD will work callback lists to ensure the customer is satisfied with the service.

    • ESD Percent Resolved at First Contact is set at 85% (calculation available in MITS Reports Data Dictionary).

    • Level 1 and Level 2 Resolved on Time is set to meeting MSLA Commitments of 85%.

    • ESD Call Abandon Rate is set to 8%.

      Note:

      MITS enterprise measures relating to abandon rate, resolved on time, queue time and first call resolved are established by the MITS Strategic Planning Office and distributed via management. Targets may change on a FY basis.

2.14.2.2  (03-17-2010)
Security

  1. Security is vital within the IRS.

2.14.2.2.1  (03-17-2010)
ITAMS ServiceCenter Security

  1. Checks and balances ensure security procedures are followed before any data is entered or updated in ITAMS. This section explains security checks that occur once the data is cleared for entry into ITAMS. The ITAMS system is a consolidated database used by IRS personnel throughout the country.

  2. ITAMS ServiceCenter (SC) supports all IRS and Treasury requirements for personal accountability. ServiceCenter users must authenticate themselves to the application prior to accessing their accounts and exercising the rights and privileges associated with the combination of capability words in their Operator Record and the Security Profile to which they are assigned. All users must enter a valid user id and password to establish their individual identity to the application.

  3. Audit and personal accountability: Once in the application, all individual user actions required by IRS can be audited and recorded. This audit information is recorded partially on a UNIX log file and partially on the application (Oracle database) and is accessible by only a few system and database administrators. Actions that will be recorded include:

    • User application log in time

    • User application log off time

    • File opening/access

    • Password creation

    • Password change

    • Password deletion

    • Record creation

    • Record modification

    • Record deletion

2.14.2.2.1.1  (03-17-2010)
Enterprise Service Desk Security Procedures

  1. Incident entries should include all of the information available to allow successful and speedy diagnosis and resolution of the incident. However certain cases should have limits placed on the kind and/or amount of Sensitive but Unclassified (SBU) information in order to avoid security problems.
    The following is not permissible within an ITAMS incident:

    • Entry of passwords, since this is a primary security violation by itself.

    • Entry of taxpayer identifiable information, such as Social Security Numbers (SSNs) or taxpayer location, is not permitted since this is likely to result in enabling a UNAX violation and may violate privacy standards.

    • Entry of employee or taxpayer information that is subject to the Privacy Act. This includes home telephone numbers and addresses. While this might be necessary for supporting users in flexiplace situations, the availability of this information to every service desk user is inappropriate. For certain instances, e.g. Criminal Investigations Special Agent 1811s, this information must be very closely held.

      Note:

      Workstation and Network Printer IP Addresses are permissible.

    Where these types of information are determined to be needed for resolution of an incident, then the ITAMS incident should be edited to avoid the SBU disclosure. The SBU information should be handled in an appropriate manner, including secure e-mail, courier transmissions, or suitable paraphrasing of the SBU material.

    • Where only a few accounts are involved, taxpayer information such as name, address, SSNs, taxpayer information number (TIN), and/or document locator number (DLN) can be relayed to the Service Provider by phone.

    • In cases where a large number of accounts are involved, or when it is otherwise infeasible or undesirable to delete taxpayer name and addresses, all documentation that contains sensitive information will be stamped "Official Use Only" , placed in a secure envelope, sealed and routed to the Service Provider. The envelope should be marked with the incident number and labeled "To Be Opened By Addressee Only" .

    • Documents containing taxpayer identifying information must never be included in a fax transmission unless the information is sanitized (blacked out).

    • Home phone numbers must never be included in an incident. Enterprise Service Desk (ESD) Specialists will use the Alternate Phone number field within the Customer Directory to post alternative customer numbers. The alternate phone number is accessible to ESD Specialists and Service Providers by placing the cursor within the Reported By field and selecting "Find" or F8. This step will display a Customer Directory Record containing the alternate phone number.

    • In the event an incident is opened with sensitive data; the Service Provider should contact the ESD. The ESD will utilize the Data Cleanup within ITAMS to remove the sensitive date. Should this utility be unavailable a Priority 1 incident will be opened requesting the data be removed from the incident. The designated Escalation group will utilize the Data Utility Cleanup to remove the SBU data. These incidents will NOT follow the Incident ALERT and escalation process for a Priority 1 defined later in the IRM.

      Where the material concerns problems related to any of the following, special procedures may be needed, including not opening an incident:

    • Entries indicative of an active Cyber security incident unless instructions are provided in the Probe and Response

    • Entries containing Classified information (e.g. vulnerabilities) concerning an IRS system or network.

    • SBU material should always be handled in full conformance with IRM 10.8.1, Information Technology Security Policy and Guidance.

2.14.2.2.2  (03-17-2010)
ITAMS ServiceCenter Access Instructions

  1. All new user requests, to access ITAMS ServiceCenter (SC) or ITAMS Asset Center (AC) must submit an OL5081 for the appropriate ITAMS application via the Online 5081 process located at the web portal: https://ol5081.enterprise.irs.gov. ITAMS SC supports the Incident Management module and Application Program Registry (APR) module. The ITAMS AC supports the Asset Management (inventory).

2.14.2.2.2.1  (03-17-2010)
General Rules

  1. The NORMAL PROCEDURE is to submit an OL5081, below are specific requirements that must be included with the OL5081 process:
    Access to ITAMS SC. The OL5081 Special Instructions field must state only ONE of the following authorized profiles:

    • Read Only: allows user to research and view incidents.

    • SP Level 2: allows user to update and close incidents. (Typical user profile - Assignment group name required on the OL5081)

    • ESD Level 1: allows user to open Calls and subsequently open, update, and close incidents. Must be authorized by the ESD Manager as these users should be part of the ESD staff. Also indicate appropriate Level 1 domain access for the EUES, EOPS, and ERC.

    • SAT Level 1: allows user to open ONLY SAT Incidents during SAT Testing. This profile is restricted to Product Assurance personnel.

    • Territory Admin, Problem Admin and ESD Admin functionality is defined in the ESD Problem Administrators guide posted on http://mitsreports.web.irs.gov/pr.asp.

  2. CONTRACTORS will follow the same OL5081 request process as indicated for normal procedure. However, when an OL5081 is received from a contractor the OL5081 SA will access the Personal Background Investigation Process (PBIP) database to ensure the contractor has been added to the database, the contract # matches what is on the OL5081, and there are approval dates in the Interim Access Approval field or Final Access Approval field in the PBIP database. If none of the above is met then the OL5081 request is denied until criteria stated is met.

  3. ESD Specialists will: notate in the "Special Instructions" field the specific Call Center ID that relates to the geographic desk the Specialist is assigned and the Service Provider directory information. Note: if the employee has an ITAMS login account but is new to the ESD position the ESD ID must be updated by the local problem administrator in ESD or by using the OL5081 profile modification process below.

  4. Change requests (i.e. full name, login name) or profile modifications should be submitted via the OL5081 system by using the MODIFY PROFILE and the details of the request should be entered in the Special Instructions field.

  5. All new user requests for access to ITAMS AC must submit an OL5081 for the appropriate ITAMS application for the respective area with the corresponding SPIF Code via the Online 5081 process located at the web portal at: https://ol5081.enterprise.irs.gov . The OL5081 will first need to be approved by the Local Area SPIF Coordinator, once approved the ITAMS Administrators will process the request. The OL5081 Special Instructions must also state the user’s authorized profile. OL5081 must be submitted with the corresponding SPIF code/location.

  6. ERC-SERVICECENTER application supports the Employee Resource Call (ERC) Center and its Service Providers. ITAMS ServiceCenter is the ticketing system for all AWSS operation support. These include requests for facilities management service, personnel service, and other non-MITS support service.

    • The OL5081 Special Instructions field must state only ONE of the following authorized profiles: Please indicate in your OL5081 Special Instructions one of the following Profile Types you will be authorized to use to support the ERC ticketing system and also include the name of your associated Assignment Group.

    • ERC Profile Types:

      ERC Level 1: This permission level is for all employees at the ERC Call Center and other users who take calls and create service tickets.

      ERC Level 2: This permission level is for field users who resolve and close service tickets created by the ERC.

2.14.2.2.2.2  (03-17-2010)
The Operator Profile

  1. ITAMS enforces security through the establishment and use of the Operator Profile. Each ITAMS user must have an Operator Profile established and maintained by the ITAMS Security Administrator (SA) (located in the EOPS organization) before they can access ITAMS. As a user, it is important to know what the profile contains in order to understand your system access rights. Only the ITAMS Security Administrator or Problem Administrator (with restricted capability) can make changes to your Operator Profile. The profiles contain user capabilities, which define what rights a user has, and provide for security.

  2. For each user the ITAMS Security Administrator creates an account and password based on the user’s SEID. The Operator Profile provides access, defines the user's Asset Security Level, and records their Enterprise Service Desk ID. Fields within the Operator Profile that contain information pertaining directly to the user include their name, location, division, and function. Users may also be assigned to Security Groups that will give them access to certain files.

  3. The Operator Profile also assigns the user's Authority Level and outlines their capabilities through the use of capabilities that the ITAMS Security Administrator enters for the user profile. When a user accesses an ITAMS function, the system looks at the user profile to determine what functions and type of information that user can access. The Operator Profile is:

    • Set up by the ITAMS Security Administrator.

    • Validated against the user's login by the system. Validation is performed for all users

    • Determines which records and fields a user can access

    • Determines which functions and data a user can access

2.14.2.2.2.3  (03-17-2010)
User Login Security Features

  1. ITAMS user Login security features will automatically " Lock" and in some cases "Expire." The following describes the Login security features / rules regarding the retention of your ITAMS login account:

    • Rule # 1: Each user login account will maintain the "Last Login" date that you logged into the ITAMS application. When your "Last Login" date exceeds 45 days from the current date, your login account will be "Locked" . If you attempt to login and your login account has been "Locked" , you will receive the message "Login account locked - call local Enterprise Service Desk to request account be unlocked" . This means that each user must periodically login to the ITAMS application within 45 days of their last login session to maintain access authorization.

    • Rule # 2: When your "Last Login" date exceeds 90 days from the current date, your login account will be " Expired" . If you attempt to login and your login account has been "Expired" , you will receive the message "Login account has expired - an OL5081 must be submitted to reinstate access" . This means that if you fail to login to the ITAMS application for 90 days, you will be considered an inactive user and your account will be expired and you will need to submit an OL5081 request to reinstate your ITAMS access.

2.14.2.2.2.4  (03-17-2010)
User IDs

  1. All user IDs must adhere to the standard login format to access any ITAMS platform via Solaris or NIS+. The standard login for ITAMS Service Center and Asset Center is an employee’s SEID.

    • ERC user login id is also equal to their SEID

2.14.2.2.2.5  (03-17-2010)
Password Management for ITAMS ServiceCenter

  1. Passwords are required for every new and existing account. Password creation is based on the Federal Information Publication Standard 112 (FIPS 112) and the Department of Defense (DOD) Password Management Guideline Manual, ISC-STD-002-85. The Application administrator will ensure that all accounts have passwords by confirming that the password required parameter is set in the default login file. The following practices apply to Password Security:

    • The Application administrator is responsible for creating user accounts and initial passwords. The user is responsible for creating his/her password in accordance with the prescribed guidelines. If the user forgets his/her password the user will contact ESD to unlock/reset password, if the password has been compromised the Security Office should be notified and the SA will reset the password account.

    • Passwords will be forced to be changed every 45 days.

    • A warning is not given but the user will be automatically prompted to change their password after 45 days.

    • Password shall be a minimum of (8) characters but no more than (14) and must have at least (3) alpha characters and either (1) numeric or special character. Password is case sensitive and upper and lower case is accepted.

    • The new password shall not be the same as the last 24 passwords.

    • Passwords shall not be the same as the User ID.

  2. Accounts are automatically locked after three (3) unsuccessful logon attempts. After each failed login attempt a message will display with the following: NOTE: Invalid password entered. Make sure your CAPS LOCK key is turned off, remember passwords are case sensitive. Your account will be locked after 3 failed attempts..

2.14.2.2.2.6  (03-17-2010)
Service Provider Assignment Groups

  1. ITAMS SC Assignment Groups identify the individuals who resolve incidents assigned by the ESD. Any assignment group changes or additions required by ESD Problem Administrator must be tracked and requested via an ITAMS SC change request incidents assigned to the ESD Problem Management Administrator Assignment Group.

  2. The ESD Problem Administrators are responsible for creating ITAMS Assignment Groups as required for new IT Service Providers. When creating new Assignment Groups, standard naming conventions will be used following the appropriate organization chart that will align Service Providers with the services being provided. This same policy applies to the creation of Escalation Alert groups. The ESD Problem Administrators will also be responsible for maintaining the manager field, the Alert stage escalations, and the auto-assignments; and ensure any added or removed groups are reflected on the Disaster Recovery website.

  3. Prior to any new Assignment Group being implemented into production, the PCAM organization must review and approve the request. No assignment groups will be created as project or system specific, as there are fields within the ITAMS incidents to accommodate the need for this type of segregation. It is the responsibility of the Service Providers to submit Probe and Response which would document specific project and system names that would enable them to create an In-Box to separate their incidents.

  4. The Territory Problem Administrators are responsible for ensuring that a Service Provider Directory record exists for each operator in the assignment group; that all assignment groups and operators are current; and identify "alert" assignment groups.

    1. Assignment groups must be established and maintained in concurrence with the standard naming convention (org-area-territory etc.). At a minimum it must match the organization structure relating to the group Modifications/Additions/Deletion of Assignment Groups Names will be communicated to ITAMS users via an Information Alert.

    2. The ESD Specialist will assign an incident to the appropriate Service Provider group based on the scenario provided in the Probe & Response. This includes, but is not limited to using any information within the customer directory, problem description, etc. to determine the correct Service Provider for a particular incident.

    3. If a Service Provider is not designated or problem is not in Probe and Response, auto assign will be manually invoked

    4. If auto assign is not successful in producing a Service Provider the ESD Specialist will assign to the local territory for triage. The first group listed for Desktop or Telecom will be used based on the problem description.

    5. If auto assign is invoked and a valid Service Provider Group is not entered, the ESD Specialist will contact a member of the QASC Team for assistance in incident assignment.

2.14.2.3  (03-17-2010)
Service Management

  1. The ITAMS Service Management process will be used to track all incoming calls and is an Enterprise Service Desk (ESD) tool used in conjunction with incident management. Uniphi Connect software will be used to allow ESD Specialists to transfer calls between the ESD and designated Upper Level Service Desks, identify the number of callers in the queue and messages in the queue. Messages will be presented to ESD Specialists as they become available. Calls will be routed to the next available agent for a more equitable work distribution.

  2. If the ESD Specialist can perform first contact resolution, which includes call triage, status update, passwords etc. the call incident will be closed. If the incident cannot be resolved by the ESD Specialist on initial contact, then an incident will be created from the call incident and assigned to the appropriate Service Provider.

2.14.2.3.1  (03-17-2010)
Call Incident

  1. A standardized set of front end questions have been incorporated into the Probe and Response (P&R) guide to be used for each call. The following collected and documented from each caller contacting the ESD when reporting an incident:

    1. Ensure all customer information is validated (i.e. phone #, location, site id, organization code, department, etc), especially Org code (Use F8 in the Org Code field to view high level org).

    2. Document all error messages in problem description and verify barcode/machine.

    3. Identify scope and impact (when the caller is a MITS Service Provider and provides specific priority or routing information, create incident as instructed, document caller and route as requested).

      Note:

      Scope and impact in conjunction with the P&R will be used to properly set the priority code, unless specified by a MITS manager.

      "Is the problem affecting other employees in your area?"

      "If so, how many users and/or terminals?"

    4. "When did the problem occur (i.e. date, time)?"

    5. "What system are you accessing?"

    6. "What location are you calling from?"

      The ESD will ensure the current location of the customer is documented (remote users are often at alternative sites).

      1. "How can you be contacted, is there an Alternative Phone number to reach you?"

      2. "When are you available?"

    7. If problem is being reported by an external helpdesk (i.e. IBM Web Hosting, IRS.GOV (AFFINA), E-HELP, HR Connect, etc.) request a cross-reference incident number from the external helpdesk and enter the external helpdesk incident number into the ITAMS Problem Description.

  2. The Customer Directory will be used when opening a call incident and will be maintained by ESD as a source of information related to customers. Required entries are:

    • Last Name, First Name

    • SEID

    • Phone (office)

    • Problem Site ID

    • Organization Department number will be used

    • Building Code

    • Territory Code

  3. The ESD will verify all information and enter a current validation date on the Customer Directory.

2.14.2.3.1.1  (03-17-2010)
Customer Directory

  1. The Customer Directory is used in conjunction with The Corporate Authoritative Directory Service (CADS) as a resource for the most current customer information. The CADS interfaces with and receives data from various corporate databases such as the HR Connect, Asset Center, Employee Connection, and e-mail directories.

  2. A customer refers to all IRS employees and contractors. Customer information is added to the database by accessing the Customer Directory screen. The customer directory is populated through the personnel data system Corporate Authoritative Directory Service (CADS) and/or manual entry.

  3. The Customer Directory is a shared data source for the MITS and AWSS Employee Resource Center customers. The ITAMS SC incident data will still be online and/or archived for 3+ years.

  4. The ability to identify where a customer is located will assist in tracking where a problem existed and what type of problem the customer experienced. This type of information will be used for Balanced Measures Reporting. Results of this reporting will allow organizations the ability to focus on improving the quality of their service and trend analysis for process improvements.

  5. The Customer Directory must be used to fill customer information for all call incidents. If a customer is temporarily re-located from their normal post of duty, the Alt Phone field (Alternate Phone) must be used to contact the customer as well as updating the building code on the incident.

  6. The Customer Directory has the ability to add a manual record for a customer if the operator has the proper permissions . Since the directory is created and updated by authoritative directory data sources in the IRS, this option should not be used on a regular basis.

  7. The Customer Directory contains records with information (name, phone, e-mail, etc.) from the Corporate Authoritative Directory Service (CADS) and for individuals who call the ESD and who are not in CADS. These records can be created and edited by the ESD. The ESD or an administrator can add a new customer record to the system only if a caller is new and the systemic updates to add their record have not been completed.

  8. The CADS Organization/Department Number is used to identify a customer Business Operating Division (BOD) within the IRS, for example MITS, Criminal Investigation, Small Business Self Employed (SBSE), Wage and Investment (W&I), etc. The CADS Standard Employee Identification number (SEID) identifies every IRS employee without using a Social Security Number.

  9. When opening an incident and there is a duplicate customer contact entry, one of which is from a manual source (SEID field will have CD#####), the ESD Specialist should select the CADS record for updates and population on incident.

    • The ESD Specialist will verify the contact file data and update the validation date in the Customer Directory each time the customer contacts the ESD. The last date that the customer record was validated will be displayed on the Call screen.

  10. The Customer Directory record contains a field designating access to the Active Directory Domain (DS indicator). This field is used to authenticate users to the OS GetServices web site for requests. In the event the indicator is not set and the customer can not use OS GetServices the P&R for this scenario should be used to resolve the incident.

2.14.2.3.1.2  (03-17-2010)
Open/Close Call Incident

  1. The Open/Close option is used for ESD incident resolution.

  2. If the ESD receives a misdirected call from a customer requesting support from an external Service Desk or support from an Upper-Level Enterprise Service Desk (ULHD); i.e. HR Connect, the ESD Specialist will open/close a call incident and transfer the customer to the appropriate servicing area or provide instructions as documented in the P&R. In the case of an external Service Desk (Treasury, Affina, IBM Web Hosting, AT&T, etc.) the ESD will transfer the call via Uniphi Connect using outbound call procedures. If the ULHD is not available when the call comes in an incident needs to be created and assigned appropriately.

2.14.2.3.1.3  (03-17-2010)
Transfer to the Upper Level Help Desk (ULHD)

  1. The process for a transfer between EUES and an ULHD is listed below:

    1. The ESD Specialist will obtain and validate the required customer contact information.

    2. Complete the incident and assign accordingly using the P&R guide.

    3. Provide the customer with the incident number and transfer call.

      Note:

      If an Upper Level Service Desks does not utilize ITAMS, the ESD will communicate the incident to the appropriate Upper Level Service Desk via phone call and/or e-mail. Lists of the Upper Level Help Desk numbers for the ESD are located in the Uniphi phonebook or P&R guide.

2.14.2.3.1.4  (03-17-2010)
Transfer to the Employee Resource Center

  1. The process for a transfer to the Employee Resource Center (ERC) is listed below:

    1. The ESD will collect and document all contact information and a brief description of the incident. If the issue is related to the ERC or any of their providers, the incident will be transferred to ERC. The customer will not be burdened to provide the basic information again to ERC. The customer will be advised that the incident is being transferred to ERC for service; the customer will be given the incident number and information on how to select the correct prompt for any status issues.

    2. If the ESD has a incident input from the OS GetServices Portal, they will evaluate the request and perform a desk transfer of the incident to the ERC.

    3. The ESD is required to update the incident with all appropriate information.

2.14.2.3.1.5  (03-17-2010)
Required Fields for a Call Incident

  1. Below are the fields that need to be populated in a Call Ticket:

    Required Field Description
    Call Center ID Is populated based on the source where the initial incident was recorded. The valid defaults will be equivalent to a call center ID of the Specialist opening the incident as documented in the Operator Profile record, or the OS GetServices web selection (i.e. WEBFIX, WEBGET, WEBMOV, WEBPWM, and WEBPWMSS). The ESD and Service Providers should never use the OS GetServices web site to close incidents.
    • Note - Web incidents from OS Get Services, Tivoli Auto Gen incidents, and failed LAN self service resets attempts, do not generate call incidents only incidents.

    • The ESD managers must ensure their employee call center id in the operator profile in ITAMS SC is accurate when requesting access or modifications to ITAMS.

    Help Desk ID This field will default to the ESD Specialist Desk at OPEN and will be updated to reflect the Service Provider's domain/associated enterprise service desk if the incident is reassigned. Currently the values are:
    • EUES- All MITS supported Service Providers with the exceptions below.

    • EOPS - All employees assigned to the Enterprise Operations Organization.

    • ERC - ERC supported Service Providers.

    Method Reported The ESD Specialist at the ESD will be required to enter the means in which the customer reported an incident by selecting one of the options available from the Method Reported pull down menu. Note: Telephone should be used for any TTY calls received.
    Incident Start The ESD Specialist will be required to enter the date/time the incident originated into the Incident Start field. If the incident is reported via e-mail, the date/time of the e-mail should be used as the incident start time. Using the fill key, the current date/time will populate. The ESD Specialist will have the option to type in the date/time if modifications are required.
    Notify By E-mail will be the default used for every customer. The ESD Specialist will be required to verify whether or not the user has an e-mail address in the customer directory before selecting this option. If the customer has an e-mail address and prefers to be notified by e-mail when the incident is resolved, they will receive an e-mail message informing them the incident has been resolved.

    Note:

    A BLANK entry in the e-mail field of the Customer Directory indicates the customer doesn't have an e-mail address and should be left BLANK. The value is updated on the CADS imports with e-mail information.


    If the customer does not have an e-mail address or prefers to be contacted via phone when the incident is resolved, the ESD Specialist will select phone from the pull down menu. If phone is entered into the Notify By field, the customer will be placed on a Call Back List once the associated incident is resolved. When placed on a Call Back List, the ESD will contact the customer by phone when the incident has been resolved.
    Contact Information Customer contact information will be auto-populated from the customer directory. If additional customer location information is secured from the customer this will be recorded in the incident description field and updated in the specific incident as appropriate. If the information is regarding the customer's permanent location information the CONTACT LOCATION of the customer record can be updated. Note this is not a permanent update. Changing the customer directory record will only be by-passed for a maximum of 30 days to allow the systematic updates to pass to ITAMS SC via the CADS load. ESD should use the P&R to advise the customer of the proper update for directory information.
    Incident Description The incident description will define the incident, the scope and impact of the incident, error codes and/or messages. The ESD Specialist will determine the scope and impact of the incident, recording the responses to the mandatory front-end questions in Section 2.14.2.3.1 and using the P&R guide.
    Category and Sub-Category Categories and subcategories classify incidents. Categories are used to identify the overall type of incident, to whom to direct the incident, the severity, and priority of the incident. Subcategories are used to define the incident more accurately with the use of categories. These subcategories are dynamically linked to certain categories. The P&R guide must be used to provide the mandatory incident coding information. The web incident process has pre-determined category and sub category and cause code selections associated with the customer request. These incidents need careful review of the incident description to ensure the customer made the correct selections. Any time a category or sub category is changed the P&R guide should be scanned and the auto-assignment function must be manually invoked to ensure proper routing.
    Priority Priority Definitions have been defined to allow for standard service levels across all the enterprise and committed to in the MITS Master Service Level Agreement (MSLA) . Each incident will be given a priority code according to the severity of the incident being reported. Exhibit 2.14.2-2 defines the available priority codes and definitions that will be used for tracking and escalating MITS incidents in ITAMS.

    Each priority defines the criteria and timeframes for incident assignment, update and target resolution time. If the specified timeframes for Priority 1 or 2 incidents are not met then the incident will go through a series of Alert Stages. (See Alert Stages Table Exhibit 2.14.2-4). It is the responsibility of the Primary Assignment Group/Service Provider to ensure an incident is assigned, updated and resolved within the timeframe defined. Priority 1 & 2 incidents cannot be downgraded. The capability to alter P3-P5 incidents can be accomplished by contacting ESD or by a MITS Manager with an approved OL5081 for priority code change. See Section 2.14.2.3.2.5 for procedures to request priority change capability prior to submitting an OL5081.
    • Priority 1 & 2 - The ESD is responsible for monitoring, tracking and escalating Priority 1 & 2 incidents. Automatic ALERTS are active for all Priority 1 and 2 incidents.

    • Priority 3, 4, and 5 - Each Service Provider management is responsible for monitoring, tracking and escalating Priority 3, 4, and 5 incidents. Automatic ALERTS will not be activated for these priorities and a manual process of monitoring, tracking and escalating will be required.

    .
    Service Request Priorities R1 through R5 are used by Enterprise Operations (EOPS) Service Providers, as applicable. The EOPS Incident Management Support Unit or designee will be responsible for monitoring and tracking all service request priority incidents R1 through R5. ITAMS automatic ALERTS for service request incidents are not activated and a manual process of tracking and escalating will be required for each provider.

    Note:

    Exhibit 2.14.2.-3 displays all the priority codes and definitions for all Service Requests.

    Project Field The project field is utilized to further define the incident by an IRS project. Projects listed on the ITAMS Project Table are derived from the IRS As-Built Architecture (ABA). ESD and Service providers are required to search for the most appropriate project for each incident. Note: Projects are associated by Category, ensuring the correct category of an incident will assist in defining the correct project. This field should be set upon initial triage of the incident and is required at closing of the incident.
    Devices Impacted Devices impacted field must be completed with the number of terminals or communication devices impacted. Upon resolution of the incident, the Service Provider will be required to verify that the number of terminals input to this field is accurate. This field should be set upon initial triage of the incident and is required at closing of the incident.
    Customers Impacted Customers impacted field must be completed with the number of customers impacted by the incident or request.
    Asset Identifier A MITS standard is to include on Tier 1 and Tier 2 hardware incidents barcode information in the incident. The Serial Number, Device ID and Machine Name will be populated into the remaining asset identifier fields if the information is available on the asset record. Service Providers must enter/validate and update the asset identifier if a hardware incident reported is for equipment other than the computer assigned to the customer:
    • For computer hardware incidents the customer will be asked to verify and/or provide the Machine Name/Barcode as displayed on the device. The Serial Number, Device ID and Barcode will be populated into the remaining asset identifier fields if the information is available on the asset record if the machine name is valid.

    • If for any reason the customer cannot provide the Machine Name/Barcode the ESD will complete the incident for dispatch to the local desktop support without this information.

    • For printer hardware incidents the Barcode of the device should be secured from the customer.

    • SW Incidents will include Barcode/Machine Names to utilize remote control in triage and incident resolution


    Asset Identifiers include:
    • Barcode

    • Serial Number

    • Device ID

    • Machine Name

    Program Name Program Name field links to the program name table where the primary and secondary programmers are identified. The Service Provider group and the associated primary programmer will be auto-populated when a valid program name is entered into the field. All other users have the option of entering a valid program name into this field to view the primary and secondary programmers. All Service Providers can auto-populate the programmer information by entering a valid program name, selecting Options, then selecting AUTO PROGRAMMER ASSIGN.
    COTS Product The Commercial Off The Shelf (COTS) field is used to identify a specific COTS product a customer is requesting or requires troubleshooting. These entries are validated from the asset management standards list.
    Keyword Keyword is used to define a type of incident that cannot be categorized under an Asset ID, Program Name or COTS Product. For example, a incident such as password reset should be input as "PSWD" in the Key Word field. The Key Word for the incidents generated via OS GetServices web site will include the first line entered by the customer on the incident and the description will include the customer selection during the request process. If a standard Keyword entry is found in the P&R it must be populated in the incident.
    Service Delivery Model (SDM) The SDM is required for all EUES personnel upon closure of an incident. This is a result of a setting in the operator record.

    Note:

    2.14.2.3.2.5 displays meanings for Resolution SDM codes

2.14.2.3.1.6  (03-17-2010)
Call Incident Status

  1. The status of a call incident is used to determine the life cycle stages of a call incident. They are listed below:

    • Open Linked: Call incidents that have resulted in the creation and assignment of an incident for a Level 2 Service Provider.

    • Open Call Back:Call incidents in which the incident originally opened has been closed and the customer either has no e-mail address or requested a phone call contact when incident is closed

    • Open Idle: Call incidents that are not associated or linked to an incident. ESD Specialist will review these incidents on a daily basis for their respected areas and close them appropriately.

    • Closed: Call incident closed by an ESD Specialist performing Level I triage or closed when a corresponding incident is closed by a Service Provider

2.14.2.3.1.7  (03-17-2010)
Check Incident Status

  1. When a customer contacts the ESD to check on the status of an incident, the ESD Specialist will research the Incident for the customer and provide assistance. In addition, the ESD Specialist will open/close a call Incident with the resolution code of "CHECK STATUS" to indicate why the customer called in. ESD Specialists should refer to the P&R guide for further guidance.

2.14.2.3.2  (03-17-2010)
ITAMS Incident Management

  1. Incidents tracked within the ITAMS IM module started from a call received must follow the basic life cycle process listed below:

    1. ESD Specialist opens a call incident (the first step to the incident management process).

    2. ESD asks the 7 Front End Questions.

    3. ESD refers to P&R guide.

    4. ESD resolves issue and closes incident. If ESD is unable to resolve then 5 through 12 of the following steps are completed.

    5. ESD creates an incident and assigns it to an Assignment group. Systemic Assignment Group Notifications are issued (as required).

    6. Level 2 assigns to a Technical Service Provider (complete assignee field).

    7. Level 2 ensures all actions are documented in Incident Detail/Description field.

    8. Level 2 ensures standard incident coding.

    9. Level 2 resolves or performs incident triage/assignment.

    10. For P1/P2 incidents, a Service Restoration Team (SRT) call may be necessary if progress is not made in incident resolution or more than one level 2/3 Service Provider is needed to resolve the incident.

    11. Level 2 receives customer concurrence to close incident or places incident in resolve status if unable to obtain customer concurrence.

  2. Incidents tracked within the ITAMS IM module started from a web request or e-mail received must follow the basic life cycle process listed below:

    1. Review incident in appropriate queue (ex. Web queue, EUES queue, or Service Provider queue).

    2. Validate all the information coincides with the ITAMS Probe and Response 7 Front-End Questions.

    3. Contact customer if additional information is needed to route/resolve the issue.

    4. Search Probe and Response for resolution or assignment group.

    5. Validate standard incident coding is correct (update as appropriate).

    6. Resolve. If unable to resolve perform ticket triage/assignment.

    7. Assignment to Technical Service Provider (complete assignee field).

    8. Ensure all actions are documented in update.

    9. Systemic Assignment Group Notification (as required).

    10. Updates/Resolutions.

    11. Close.

2.14.2.3.2.1  (03-17-2010)
Creating an Incident

  1. Creating an Incident:

    • If the ESD Specialist is unable to perform first call resolution, the Specialist will create an incident from the call incident. The incident incident will be assigned a unique system generated number.

    • All Tivoli incidents generated systemically when pre-defined thresholds are met will generate an incident ticket with pre-defined systemic field defaults. Call incidents will NOT be generated for Tivoli Auto Gen incidents.

    • All incidents generated from the OS GetServices web site will create incidents populated required fields based on the customer selection. Call incidents will NOT be generated for web-initiated requests. Call incident are generated to track all Password Management self-service events that are successfully completed by the customer.

    • All requests entered via OS GetServices (MY TECHNOLOGY) will be assigned to the ESD for Level I Triage with the following exceptions:

    1. HW COMM Devices (defaults to Local Telecom).

    2. HW DESKTOP (defaults to Local Desktop).

    3. All OS GetServices Get IT Requests (except for software) defaults to Local Integration Equipment Group.

    4. OS GetServices Get-IT software requests route to ESD.

    5. ISRP hardware requests default to local SA group.

    Note:

    At anytime if an auto assign record is not present or there is a duplicate, the incident will default to the ESD.

2.14.2.3.2.1.1  (03-17-2010)
Production vs. Non-Production Incidents

  1. The Prod Non-Prod field is used to identify whether the incident being reported is Production Related or Non-Production Related.

    • All incidents opened on the ITAMS ServiceCenter (SC) Production Database, regardless of what is entered into the PROD-NONPROD field, will be monitored/tracked/escalated according to priority assigned to the incident.

      Production incidents will be included in the Measures Reports.

      Incidents opened with any other entry in the Prod/Non Prod field other than PRODUCTION will be excluded from the Measures Report.

    ITAMS PROD-NONPROD TABLE

    PROD_NONPROD Description
    CADE Cade Mock Cycle Incidents
    DEV Development
    DITE Development & Integration Environment
    DR Defective Reporting
    DSRT Deployment Site Readiness Test
    FIT FIT Testing
    INFO INFO Note Indicated Added for CBO Replaces CCJS
    ORT Operational Readiness Testing
    PHB Production - HUB Testing
    PILO PILOT - A phase that is used to test SYS readiness
    PMY Production - Mid Year Processing
    PRD Production
    PSIT Project System Integration Test
    PSU Production - Start Up Conversion
    RSIT Release System Integration Test
    SATM SYS Acceptability TST Modernization
    SIT System Integration Testing
    SLA Service Level Agreement
    SMC Compatibility Testing
    TSE TCC SAT/FIT System
    TST Test Tickets

2.14.2.3.2.2  (03-17-2010)
MAC-PLAN Tickets (Project Planning Tickets)

  1. The ITAMS SC module is used to track project level work for EUES and can be used by any MITS Service Provider. The procedure is located at http://mitsreports.web.irs.gov/pr.asp in the file named Training Guide rv5 MACPLAN.doc. MAC-PLAN is a special sub category used to track work and is not included in the target resolution measures in MITS. This process creates a hierarchal reporting process for any services being performed not specifically associated to a committed timeframe in any service level commitment document (ex. MSLA, SLA etc.). As an example: Hardware refreshment efforts, local pro-active initiatives etc.

2.14.2.3.2.3  (03-17-2010)
Initial Customer Contact Process

  1. Once the incident has been assigned to the Service Provider Group, the Service Provider will be required to contact the customer within 2 hours of receipt of the incident and adhere to the following guidelines:

    1. Complete the Initial Contact field: The Initial Contact field identifies when the Service Provider contacted a customer after receipt of an incident. This is a date/time field and can be filled automatically with current date and time by selecting the ellipsis button within the field. Initial contact should be accomplished within 2 hours of receipt of the incident.

      Note:

      A minimum of 3 attempts should be made to contact the customer.

      • First attempt via the phone number or alternate phone number as recorded in the customer record.

      • Second attempt by e-mail if e-mail address is available and there are no incidents with e-mail, otherwise another attempt by phone.

      • The final attempt would be a contact to the customer's manager of record as identified in ITAMS customer record or Discovery Directory.

    2. If the Service Provider has made a minimum of 3 attempts to contact the customer over the course of 3 days without success then the Service Provider will document all attempts to contact the customer via updates on the incident.

      If the incident is a Priority 3, 4 or 5 and the customer has not responded then close the incident with resolution code “NO CUST RESPNSE” (No Customer Response). If the incident was resolved then the appropriate resolution code specific to the incident resolution will be used.

    3. A minimum of 1 attempt per day for a 3 day period is required before an incident will be closed with the resolution of "NO CUST RESPNSE. "

    4. ESD and Service Providers will follow their specific standards for managing the incident inventory as long as the procedures conform to the IRM standards for customer contact and closure.

2.14.2.3.2.4  (03-17-2010)
Incident Status

  1. The status of an incident is used to determine the life cycle stages of an incident. They are listed below:

    Incident Status Description
    Open Initial status of an incident when opened by the ESD or a new incident from OS GetServices.
    Open/Approval Requested Incident is awaiting managerial approval. Opened through OS GetServices.
    Assigned Incident has been assigned to a Service Provider assignee (name assigned to a member of the assignment group).
    Customer Appt Customer initiated request for service at a specific date and time outside the target resolution. Note: Estimated resolution time is required and a confirmation e-mail is sent to the assigned technician and the customer that confirms the customer's request to schedule service outside the MSLA standards. MITS Service Providers should not use this option to schedule their workload; only customers needing this convenience should request it.
    Resolved Service Provider has resolved the issue but has not yet obtained customer concurrence.
    Closed Service Provider has resolved issue or provided service and customer is satisfied.
    Pending Customer Service Provider has attempted to contact the customer, but the customer is not available. Example: on leave, in a meeting, etc. Service Provider has resolved the incident, but is awaiting action from the customer or waiting for concurrence on a resolved issued.
    Pending Funding Service Provider has escalated to management and the Area Director or appropriate executive has denied the necessary funding to provide the product or service.
    Pending Vendor Service Provider has determined vendor service is required and is awaiting technician or part.
    Pending Testing Service Provider is awaiting testing results.
    Pending Other Service Provider has determined a delay has been encountered in incident resolution, or is a cross referenced incident, but not due to Pending Vendor, Pending Customer or Pending Funding.
    Reopened Used when a incident is reopened, the incident status must be changed to Reopened. This status can only be used within 30 days of the original incident being resolved and it can not be a P1 or P2, or have been closed with the resolution code of No Cust Response.
    Reassigned When a incident is reassigned from one Service Provider to another the incident status must be changed to Reassigned. The incident description must also contain the details regarding the reassignment.
    Work In Progress Service Provider has reviewed the incident and is working the incident with the customer.

2.14.2.3.2.5  (03-17-2010)
Subsequent Updates

  1. All actions taken by the Service Provider up until incident resolution will be documented in the update actions field. Updates must be entered according to the time frames defined by the priority the incident was assigned.

  2. The following list includes some of the instances when an incident is updated:

    • Priority is changed.

    • Actions taken to triage/resolve incident.

    • Incident is placed in pending status.

    • Category is changed.

    • Cross referencing incidents.

    • Re-open of incidents.

    • Current status is provided.

    • Incidents are shared.

    • Incidents are transferred to another Service Provider.

    • Incident reassigned to the ESD if the Service Provider does not know to which Service Provide to reassign incident.

    • Incident are deferred by entering an Estimated Resolution Date/Time and a valid update to indicate actions being taken to correct the incident. Note: Alert Stage/Deadline e-mails will continue, phone call to managers will be deferred (P1/P2 incidents).

    • Incidents are assigned.

    • Incidents are reassigned.

    • Customers are contacted.

    • Any field change.

    Priority Changes: Designated personnel will have the following authority:

    1. Only ESD Specialists are authorized to change the priority of an incident as appropriate. Priority changes for P3-P5 can be changed by ESD Specialists or by local management personnel. Local management must have approval from ESD Senior Management and approval via the OL5081 application. Personnel requiring the capability to change a P3-P5 priority code will be required to follow the process listed below:

      Secure approval from an ESD Senior Manager by opening the OS GetServices portal http://getservices.web.irs.gov and selecting "My Technology" then " Get New Hardware/Printers" request.

      Select Other in the Product field and enter the appropriate ESD Senior Management as the approver under the approved by section.

      Once the incident request has been approved and is completed, the requestor will be notified via e-mail and the incident can be closed.

      The requester will need to initiate a request through the OL5081 system and will enter the approved incident number in the special instruction field as well as notating that they are requesting priority change capability.

      Once the OL5081 has been approved and submitted, ITAMS Security will add a Capability Word to the authorized personnels profile to allow for the changing of P3-P5 priority codes.

    2. Priority codes are set during the initial reporting of a incident and are based on scope and impact of the incident. The priority code assigned to the incident will determine the target resolution time for the Service Provider to perform incident resolution. During the life cycle of the incident if the Service Provider determines the priority should be changed, they are required to:

      Contact the customer to notify them of the change in scope and impact and advise them of the new target delivery.

      Update the incident identifying justification for the change in priority.

      Contact the ESD to make the priority code change or local management point of contact with the capability to alter priority.

    3. Prior to the change of priority the authorized/designated personnel will confirm the coordination was made and change the priority.

    4. Priority 3 - 5 can be changed by the ESD or authorized field personnel.

    5. The ESD, in conformance within standard escalation procedures, can only create Priority 1 or Priority 2 incidents. P3-P5 incidents cannot be upgraded to a P1 or P2. P3-P5 incidents that require an upgrade to a P1 or P2 will be managed as follows:

      The P3-P5 incident will be closed and cross-referenced to the new priority incident.

      A new P1 or P2 incident will be opened.

      The Service Provider will need to update the incident with the scope and impact.

      Note:

      See 2.14.2.7.1.4 for downgrading restriction of priority 1 and 2 incidents.

  3. Change Category: Service Providers should change the category if they determine the category assigned by the ESD Specialist is incorrect or if they determine through incident resolution that the category should be changed. Any time a category or sub category is changed the auto-assignment function must be manually invoked after referencing the P&R guide for additional guidance on triage / assignment and/or resolution.

  4. Customer Appointment: Estimated resolution is required when using this status code. The required date and time is the appointment. This will generate a customer notification confirming the appointment scheduled with the customer. EUES personnel are required to enter the SDM of ITS appointment (this is essential in ensuring the incident is flagged as on time for MITS measures). The following procedures apply:

    Note:

    Customer Appointment APPLIES ONLY to EUES Desktop Support personnel but can be used by any Service Provider.

    1. Customer Appointments are used to accommodate a customer's need to have a scheduled time for a MITS service. The customer must request the appointment. Using this feature in ITAMS SC will allow for proper reporting of service within customer commitment.

    2. Customer requests a scheduled appointment for a break/fix or EUES service.

    3. Change status to "Cust Appt."

    4. Enter the agreed upon appointment date and time in the Estimated Resolution field on the "update" tab.

    5. Enter the details about the appointment (date/time/location) in the incident update.

    6. When you save the update, e-mail will go to the customer (and to the service provider assignee on the incident) confirming the appointment.

    7. If the appointment time changes for whatever reason, repeat steps 1-5. A new confirmation e-mail is sent to the Service Provider assigned the incident and the customer.

    8. When the incident is corrected or the service delivered and you are ready to close the incident, update "ITS-APPOINTMENT" in the RESOLUTION SDM.

  5. Resolution Service Delivery Model (SDM): The End User and Equipment and Services organization has implemented a number of Service Delivery Options to support the Service Delivery Model for providing service. In the ITAMS SC application the EUES employees performing service are required to enter the Resolution Service Delivery Model used to perform service. This information is selected from a field on the resolution tab of an incident labeled Resolution SDM. The values are:

    SDM Values Description
    Onsite Used when service is provided from onsite support staff for the customer in person.
    Dispatch Used when Service Provider staff is dispatched to a location without permanent on site support, but within a 25-mile radius of on-site support. (The original intent of the SDM was to not dispatch technicians further than 25 miles from on-site support. Other SDM's would be utilized to provide that service.)
    Drop Ship Used when a product is sent to a customer for a self service solution. May also be used in combination with Contractor. If the customer cannot perform required tasks, equipment could be drop shipped and a contractor would do the actual installation, etc.
    Scheduled Visit Used when service is rendered during a scheduled customer visitation to a POD without onsite or dispatch support.
    ITS Appointment This option is used when a customer requests an appointment for service that is convenient for them. Please note to use this resolution you should have had the incident in a Cust Appt status with the estimated resolution time of the requested appointment.
    Contractor Used when the Service Provider is an outside contractor (only for sites designated as Contractor). Contract services may be utilized by projects, etc. that are not part of the SDM Model.
    RFD Internal Used by the Service Provider when a customer visits a Rapid Fix and Delivery site at an IRS location for service.
    Remote Used when the Service Provider is able to resolve any customer incident or provide service using a remote access tool (e.g. Tivoli) or can resolve via verbal instruction to the customer.

  6. Managing Duplicate Incidents/Calls: ESD Specialists will be responsible for managing the following process for duplicate incidents:

    1. Duplicate Incidents: ITAMS SC is designed to check for duplicate incidents searching the Asset ID fields and the Program Name field. If an exact entry is entered into either one of these fields, ITAMS will search the database for incidents that already exist with the same entry in one of these fields. If an exact match is found, the following message will be displayed, "Potentially Related Incidents by Asset. " The ESD Specialist should select the incidents on the QBE list to determine whether the incident being reported is a duplicate incident. If the incident is a duplicate the ESD Specialist should select the link option to the current incident. If the incident being reported is not a duplicate incident the ESD Specialist should select the back option and then select Create Problem and continue with the open process.

    2. Cross Reference Duplicate Incidents: If multiple incidents exist for the same incident, the incident assigned to or opened by the Service Provider will be categorized as the master incident by placing M in the X-Ref field of the incident. The Incident Start Time contained within the master incident will reflect the time of the first incident opened by the customer or the Service Provider reporting the incident.

      Duplicate incident will be associated to the master incident by using the Associate to Problem option from the duplicate incident and updating the incident with the following; placing an X in the X-Ref field, placing the incident in pending other status, entering the master incident number into the update description field, enter the Cause Code of UNKNOWN and the Resolution Code of CROSSREF.

      The Assignment Group for all Cross-Referenced incidents associated to a Priority 1 incident should be changed manually to reflect the Assignment Group who is working the incident.

      Updates and resolution will be entered into the master incident by the Service Provider. Once the master incident is closed by the Service Provider, the Specialist will close the duplicate/cross reference incidents by entering the incident resolution description provided by the Service Provider in the master incident and entering the master incident Incident Stop time into the cross reference incident. If there are cross referenced call incidents associated to the master incident they will close systemically.

      The customer of the cross-reference and master incident will be notified via e-mail or a Call Back when incidents are closed.

      All master incidents that are coded as a Priority 1 will be associated to an Incident Alert with a category of INFO-ALERT.

    3. Cross Reference Duplicate/Multiple Calls: When multiple/duplicate calls on a single incident are received, the call incidents will be associated to the master incident by using the Associate to Incident feature after the call incident has been completed. The master incident will contain the Incident Alert information, updates and resolution entered by the Service Provider. The Incident Start Time contained within the master incident will reflect the time of the first incident opened by the customer or the Service Provider reporting the incident. The customer will be notified via e-mail or a Call Back when the master incident is closed. If a call incident is associated with a master incident, the call incident will close systemically when the master incident is closed.

  7. Re-Open Process: Customers have 3 options to reopen a closed incident if the closed incident meets the reopen criteria:

    1. The Customer can have an ESD Specialist reopen a closed incident.

    2. Customers have the ability to reopen incidents using a reopen link provided in the customer’s Closed Incident Notification e-mail, only if the incident was not closed with "No Customer Response" in the resolution field.

    3. Customers can reopen an incident by visiting the OS GetServices website → My Request Status tab to view all closed incidents under the "My Request History " link. Only closed incidents eligible for the reopen process will allow the customer to select the option to reopen the incident.

    The ESD Specialist will update the incident with the reason the incident was reopened. The incident will go from Closed status to Open status and changed to Reopened status when the incident is saved.

    • The initial Cause Code, Resolution Code, and Incident Resolution description will remain in the incident and will be changed by the Assignee if necessary.

    • The Re-open process will be used to take an incident out of closed status up to 30 days after the customer is informed of the resolution.

    • If a re-opened incident is determined to be a new incident the assignee will update/close the re-opened incident and request the customer to call the ESD and report the new trouble or use the http://GetService.web.irs.gov site to report the incident.

      Note:

      If appropriate the MITS Service Provider should open the incident on OS GetServices on behalf of the customer.

    • If an incident is opened and determined that it should have been a re-open of another incident, close the incident and re-open the original incident.

2.14.2.3.2.6  (03-17-2010)
Resolution/Close Process

  1. Once a incident has been resolved the incident will be updated with a detailed resolution description. Customer concurrence should be obtained before the incident is closed by the Service Provider.

  2. The update resolution must include confirmation and concurrence received from the customer on proposed resolution. If the service is performed remotely or while the customer is away from their work area, the Service Provider is required to confirm with the customer the incident is resolved before closing the incident. This includes verifying with the customer that any instructions provided were successful in resolving the incident. The incident stop time on the history tab of the incident must be updated with the date and time the Service Provider completed the resolution (not the time required to gain customer concurrence). Note: If root cause of incident not determined, a Root Cause Analysis record (RCA) may need to be opened. See 2.14.2.7.2 for RCA process.

    1. If the Service Provider has made a minimum of 2 attempts during a 2 business day period to contact the customer and/or manager without success then the Service Provider will:

      Document all attempts to contact the customer and/or manager via updates on the incident.

      Place the incident in Pending Customer status.

      Contact the customer's manager on the second attempt on the second day.

    2. If customer confirmation cannot be received, the incident will be updated indicating the incident was put in Resolved status with the appropriate resolution code specific to the incident resolution.. The resolution code will reflect the action taken by the Service Provider. The resolution code of NO CUST RESPONSE must not be used to close a incident that was resolved. The incident stop time populated on the history field will be pre-populated to the time the Service Provider resolved the incident which will not be the actual time the incident is closed; ensuring measures are calculated on service while allowing the incident to stay open for 2 days to gain customer concurrence.

    3. When an incident is placed in Resolved status the customer will receive a systemically generated e-mail. The "RESOLVED Incident Notification " e-mail link will route the customer to OS GetServices – My Request Status, enabling customers to (a) concur with the resolution and close the incident, or (b) re-open the incident. Customers will also be able to take action to close or re-open incidents pending their concurrence, by going directly to OS GetServices → My Request Status.
      A 10-day reminder e-mail will be sent to the customer if the resolved incident is still pending their response. If no action is taken by the customer after 30-days have elapsed, the resolved incident will systemically close.
      The "RESOLVE" button will only be visible and available for "FixIT" incidents (P3 and P4) and incidents where the "Reported For" customer has a valid e-mail address.
      The "RESOLVE" button will not be visible and available for P1/P2 incidents and requests for products and services "GetIT" (P5). However, if a " FixIT" incident is downgraded to a P5, then the incident would still be eligible for this process.

      Note:

      For those incidents where the " RESOLVE" button is not an option, Service Providers are still required to secure customer concurrence.

    4. If the customer's incident is found not to be resolved as initially recorded the incident stop time should be updated to reflect the final resolution time.

  3. Incident Stop Times: The actual time that the incident was resolved should be recorded in the Incident Stop field. This is a date/time field and can be filled automatically with current date and time by selecting the ellipsis button within the field during the close routine.

    • During the resolution process the incident stop time can be entered under the History Tab at any time to record when service was rendered.

    • Priority 1 or 2 incident incidents not resolved according to priority definitions will be escalated through the Alerts process.

  4. Customer Follow-Up: Keeping the customer informed about the status of incident resolution efforts is a vital aspect of providing quality service. MITS has established a 100% customer call back process. Every MITS customer will be contacted by either e-mail or phone.

    • E-mail: Each customer who requested to be notified via e-mail when their incident is resolved will receive an e-mail notification of the incident resolution. If the incident was not resolved to their satisfaction, the customer can contact the ESD and request their incident be reopened. The ESD Specialist will reopen the customer's incident and assign it accordingly.

    • Phone Call Back: An Open Call Back List is generated for customers who have requested to be notified via telephone when the Service Provider has closed their incident. The customer will be contacted by the ESD to inform them of the incident resolution and ensure the customer was satisfied with the service. If the customer is satisfied with the service provided, the ESD Specialist will close the call incident. If the customer is not satisfied with the service provided, the ESD Specialist will reopen the incident and assign to the appropriate Service Provider for incident resolution.

    • The ESD Specialist should monitor the Call Back List at least once per shift for those incidents that require a call back to the customer. If an ESD Specialist attempts to make contact with a customer, but is unable to speak with them, the ESD Specialist will leave a voice mail that will include:

      ITAMS incident number.

      Message indicating the incident has been closed and if their incident was not resolved to their satisfaction, they may contact the ESD to request the incident be re-opened.

2.14.2.4  (03-17-2010)
Incident Management

  1. The Enterprise Service Desk (ESD) Specialists will have 4 separate queues to be managed by each Specialist and reviewed by each ESD manager.

2.14.2.4.1  (03-17-2010)
Incident Management Queue

  1. Open-Callback: An Open-Callback List is generated in ITAMS for customers who do not have a valid e-mail address or have requested to be notified via telephone when the Service Provider has closed their incident. The ESD monitors the Open-Callback List for those incidents that require a call back to the customer to confirm customer concurrence with the resolution of their incident. The ESD is responsible for 100% of the callbacks to users to verify that the incident was corrected and to let them know that the incident was closed.

  2. ITAMS WEB QUEUE: The ITAMS Web Queue is built from all incidents reported by customers from the OS GetServices web page (http://GetServices.web.irs.gov) . This queue is accessed via the ITAMS Incident Management module. A "Web Queue" button is available to all ESD Specialists allowing access to the next available incident from the web queue; this allows the quick bypass of locked records being accessed by someone else in the ESD. Web Queue incidents only include "Open" status incidents assigned to "EUES-ENTERPRISE-SERVICE-DESK" . These incidents are sorted by priority, with a P3 being the highest and at the top of the queue. Incidents are additionally sorted by time and date.

    Note:

    Certain selections from OS GetServices are directly routed to the Service Provider.

  3. ITAMS EUES Queue: The EUES SD Queue is built from all ITAMS incidents that are assigned to the ESD for the ESD Specialists to work. This queue is accessed via the ITAMS Incident Management module. A"EUES SD Queue" button is available to all ESD Specialists allowing access to the next available incident from this queue; this allows the quick bypass of locked records being accessed by someone else in the ESD. The incidents are in a status other than "Open" or "Resolved " (includes incidents reassigned to the ESD from the Web Queue, reassigned from Service Providers or updated with an estimated resolution date for further action by ESD). These incidents are sorted by priority, with a P3 being the highest and at the top of the queue. Incidents are additionally sorted by time and date. Updated incidents will not appear in queue for two hours after they are updated or after their estimated resolution date & time has expired, which ever is later.

    Note:

    Neither the EUES queue button nor the Web queue button will display incidents awaiting approval or categorized as an INFO Alert.

  4. E-Mail Queue: The *MITS-EUES Enterprise Service Desk e-mails are managed by ESD. Customers and Service Providers can e-mail incidents and requests Info Alerts or Scheduled outages to this e-mail address. The ESD has up to two hours to create and assign an incident ticket from an e-mail received from a customer. If the customer is reporting a P1/P2 incident using e-mail, a follow-up phone call to the Escalation Queue is mandatory.

2.14.2.4.2  (03-17-2010)
Probe and Response

  1. An automated knowledge database called the Probe and Response Guide (P&R) was developed for use within the ITAMS Incident Management Application. The ITAMS P&R guide provides information to the ESD Specialists and Service Providers for enhanced incident triage, First Contact Resolution, timely incident assignment, standard incident coding and resolution solutions. Several fields (Category, Subcategory, Key Word, and Project) can be automatically populated into the incident.

  2. It is mandatory for the ESD Specialists to use the P&R guide during initial triage of a reported incident and prior to assigning to a Service Provider group. The P&R guide is also available to Service Providers for use in determining the standard incident codes or enterprise standard of incident resolution for a particular incident type. Service Providers can view the information, but cannot automatically populate into the incident. A copy of the P&R User Guide can be found on http://mitsreports.web.irs.gov/pr.asp .The web site is updated monthly by the ESD analyst staff with the P&R database.

  3. The P&R online guide contains topics relating to customer facing products and services included but not limited to:

    • Field Desktop services and products

    • Field Telecom services and products

    • Tech Services and products

    • Enterprise Systems Management services and products

    • Incident Management

    • Tivoli

    • Enterprise Networks services and products

    • Modernization Projects

    • Enterprise Operations (EOPS) services and products

    • Integrated Document Solution Enterprise processes (Campus Most Efficient Organization (MEO)

    • Application triage and resolution

    • Enterprise Service Desk Services

  4. Probe and Response Additions/Modifications/Deletions : Probe and Response Knowledge Owners will be responsible for maintaining their knowledge by direct access to the knowledge management (P&R) database or by submitting requested changes via a standard template resulting in an ITAMS incident.

  5. Template-ITAMS Incident: Knowledge Owners will be required to complete a template documenting their requested changes.

  6. Each Web or Word template submitted will be reviewed, approved for submission and entered by the EUES ESD QASC Section. Personnel within this section are available to provide guidance on the completion of these templates. The QASC e-mail address is as follows: &MITS ACIO EUES ESD ANALYSTS .

  7. WEB TEMPLATE - The Web Template will be used for 10 or less ITAMS P&R additions/modifications/deletions. Each request will generate 1 incident ticket to the ESD. Once the form has been completed by the Service Provider, they will select the " Submit" button from the template, which will send the template to the ESD group e-mail box requesting an incident ticket be opened. The ESD will follow standard procedures for opening and assigning the incident and providing the customer with the incident number. The Incident Description of the P&R change request incident will include a link to the P&R Web Template.

  8. WORD TEMPLATE - The Word Template will be used for 11 or more ITAMS P&R additions/modifications/deletions. Once the knowledge owner has completed the template(s) they will save the template file with their project name and date, open an OS GetServices web incident and attach the template(s) or send an e-mail to the *MITS-EUES Enterprise Service Desk group e-mail box with the template(s) attached. The ESD will follow standard procedures by opening and assigning the incident and providing the customer with the incident number. The Incident Description of the P&R will reference the attached word template and include any special instructions documented by the knowledge owner.

  9. The Probe and Response Web and Word templates, Training Guide and other related material is available via the following URL: http://eues.web.irs.gov/ESD/ESD-MAIN.aspx.

  10. The ITAMS incident created from the template will be coded as category "Customer Request" , subcategory "MAC PLAN" and coded as a Priority 5. The incident will be assigned to the Quality Assurance and System Control (QASC) for review and validation of compliance for coding standards and incorporation of standard ESD triage practice. QASC will contact the submitter/author if further review/analysis is required and facilitate the update to the system.

  11. Changes involving enterprise systems, application or software must be approved by the organization with the technical responsibility for the product. The submitter/author is required to gain concurrence of the technical, process and/or procedure owner before assigning a P&R entry to a Service Provider group.

  12. If an enterprise standard is being developed by an organization for use by the field territories, the initiator of the request must obtain concurrence for incident assignments to groups and or organizations other than their own and document the information in the incident. Concurrence documented via an ITAMS incident applies to both template submission and direct authoring access.

  13. Changes involving any aspect of reporting or needing a review for policy compliance will be shared for approval with the EUES Planning Coordination and Asset Management (PCAM), Policy & Measures team before implementing.

2.14.2.4.3  (03-17-2010)
Reassign

  1. The reassign process will be used to route incidents to the appropriate Service Provider (EUES, Enterprise Operations, etc.) for the following reasons:

    • Incident was assigned to a group in error.

    • After performing triage, the Service Provider determines the incident should be assigned to another Service Provider.

    • A Service Provider has completed their service and another provider needs to perform services for the customer.

  2. Reassignment Responsibilities:

    1. ESD Specialist's Responsibilities:

      If a Service Provider reassigns an incident back to the ESD, the ESD Specialist is responsible for reassignment of that incident to the appropriate group utilizing the Probe and Response (P&R) Guide as a resource.

      Reassigning the incident to the responsible primary Service Provider allows for alert notifications to be sent for Priority 1 incidents.

    2. Service Provider's Responsibilities:

      Service Providers will have the capability of reassigning incidents back to the ESD or to another Service Provider as detailed in the P&R database. The Service Providers must use the P&R guide to find the proper Service Provider before assigning back to ESD. All research attempts should be documented in the incident.

      If a Service Provider is reassigning a incident they will have the capability to assign directly to another Service Provider. They must use the P&R to identify the group and if the appropriate Service Provider isn't found, the incident must be assigned back to the ESD for appropriate assignment.

      The Service Provider reassigning the incident must change the incident status to "Reassigned " and document the reason for the reassignment.

      The Service Provider Group who received the incident will be required to assign the incident to an individual assignee or to another group within the time defined by the priority of the incident along with contacting the customer. The status of the incident will be updated to "Assigned " when the incident is name assigned to a Service Provider.

      If a Priority 1 incident is not assigned within the priority definition time frames, Alerts will be issued to the designated personnel. See 2.14.2.7.1.11 Alert Notifications/Escalation.

      An update to the incident is required to identify why the incident was reassigned and provide a contact point.

2.14.2.4.4  (03-17-2010)
Share Assigning

  1. The share process will be used when an incident needs to be worked concurrently by multiple Service Providers or for information sharing. Incidents can be shared among Service Provider groups. Alerts will be generated to the owner of the incident for Priority 1 incidents and not the share assignment group. Some examples include:

    • Incidents that require two Service Providers to perform incident resolution simultaneously.

    • The assigning Service Provider can designate themselves in the Share Assignment field to monitor the status of the incident after reassignment.


    The primary assignment group is responsible for incident resolution, customer concurrence, and close out of the incident.

2.14.2.5  (03-17-2010)
Incident Quality Review

  1. This section provides procedures for enterprise level and site reviews as requested, as well as front-line manager evaluative employee reviews of the Enterprise Service Desk (ESD).

  2. The Quality Review process provides a method to monitor, measure, and improve the quality of MITS products and Services as outlined in the Master Service Level agreement and recorded via the ITAMS Incident management process and procedures. Quality Review data is used to provide quality statistics, and to identify trends, problem areas, training needs, and opportunities for process improvement.

  3. The Quality Assurance and System Control (QASC) group in the ESD serves as embedded quality for MITS. QASC supports the Enterprise commitment and capability among all individuals to continually improve customer service, employee satisfaction, and standard recording of business results. ESD or designee (QASC) is responsible for the 100% review of all Priority 1 incidents generated in the enterprise to ensure all process and procedures were followed and incident data is accurate including reviewing all required fields for proper information. The review results will be shared with the organizations and Service Providers involved with the incident. ESD managers are required to review at least 2 incidents per month for each employee.

  4. Additional detailed process information on P1/P2 incident management can be found at the following URL: http://eues.web.irs.gov/ESD/IncidentMgmtP1P2.aspx.

  5. The Quality process is based on several components:

    The Planning, Coordination, and Asset Management - Policy and Measures (PCAM P&M) group in EUES interprets the strategic plan goals and sets or improves the calculations of the quality measures, to ensure they can be reported from the bottom to the top of the organization and support the MSLA agreements. This includes providing a calculation process that is fair and which enables managers and employees to act in a meaningful way upon the results.

2.14.2.5.1  (03-17-2010)
Quality Review Roles and Responsibilities

  1. The ESD Specialists/Level 1 and/or Service Provider/Level 2 will be required to validate the following fields at a minimum at resolution:

    • Priority

    • Category

    • Sub-Category

    • Project Code

    • Number of devices impacted

    • Number of customers impacted

    • Cause Code

    • Resolution Code

    • Valid resolution description detailing corrective action

    • Incident Start Time

    • Incident Stop Time

    • Incident Title (optional)

    • Resolution SDM (EUES only)

  2. Each Service Provider function should have a plan for ensuring data quality of the Service Providers in their organization.

2.14.2.5.2  (03-17-2010)
Mandatory P1 / P2 Incident Managerial Review

  1. Per a September 11, 2009 memo signed by Deputy Chief Information Officer, Operations, all P1 / P2 incidents will be reviewed by group managers (or their designee) for quality assurance purposes. Information regarding this effort can be found at http://eues.web.irs.gov/ESD/Service%20Provider%20Ticket%20Data%20Quality%20Review.aspx

2.14.2.5.3  (03-17-2010)
Customer Feedback

  1. Reports of customer feedback are information sharing and non-evaluative reviews and reports reflecting information from our Misroute reports, Service Desk and Service Provider incident “issues” and Customer Survey analysis. ESD will be looking for systemic or operational “opportunities” that will create a “value added” or a very big “bang for the buck.” What will be most productive is to investigate instances that are symptomatic of a serious deficiency which if correct, would eliminate multiple incident errors and enhance the incident management system. Since the data is from multiple sources they are only indicators of quality. The Top Ten format is used to report Lessons Learned. Top Ten reports are included in the Bi-Monthly report to management, for discussion in group meetings for internal ESD items and lesson learned report shared with Service Provider management.

  2. The ESD QASC staff will be responsible for facilitating any reply, escalation, action or issues with the customer and/or the Service Provider.

  3. Customers who have concerns/issues/questions with the ESD services, tools, policy and procedures or MITS services and products supported by the ESD should submit their feedback to the following mailbox: "*MITS-EUES ESD Analysts Feedback."

  4. When reporting incidents in regards to the mis-assigned incidents, the standard Lessons Learned format is to be used and then forwarded to the above mailbox. The Standard Lessons Learned Format is located on the following URL: http://mitsreports.web.irs.gov/pr.asp titled "ESD Incident Review Feedback Procedures."

2.14.2.5.4  (03-17-2010)
Quality Review Reports

  1. These reports are generated from the ESD Quality Reviews and Measures group (QASC):

    • DAILY: Priority 1 & Info Alert - ALL EUES Manager Information Sharing E-mail (upon request)

      Note:

      Review results will be shared with all impacted Service Providers.

    • EUES QUARTERLY OPERATIONAL REVIEW:
      This report provides Enterprise performance on MSLA objectives as well as present the organizational health for Customer Satisfaction and Employee Satisfaction measures.

    • ESD SERVICE DESK OPERATIONAL REVIEW:
      This report provides ESD Senior Management and Service Desk manager with quarterly performance results on MSLA issues and provides an overall picture of the performance of the ESD.

    • Lesson Learned:
      Prepared for all misrouted incident forms submitted by the Service Providers to improve incident management. The incidents reported are researched and review for compliance with the IRM process and procedures and feedback sent to through management to effected providers. This report will also be prepared from review incidents based on the QASC sampling strategy for P2, P3, P4 and P5. Lessons Learned Feedback Reports prepared by ESD customers should be forwarded to the mailbox: *MITS-EUES ESD Analysts Feedback."MITS-EUES ESD ANALYSTS FEEDBACK " Distribution List.

    • Enterprise MITS Reporting:
      The Planning Coordination and Asset Management - Policy and Measures group (PCAM P&M) submits Incident and Asset Management reports and data for the ACIO Dashboard on a monthly basis. Data for the ACIO Dashboard is either posted by PCAM P&M on behalf of EUES or submitted to the Customer Relationship and Service Delivery (CRSD) and to PCAM for review and subsequent posting to the dashboard. Incident Management data includes such metrics as first contact resolution, percent on-time by priority, average resolution time, and percent of web incidents. Asset Management data includes metrics on obsolescent assets. Metrics are designed to reflect MITS results for delivering products and services in compliance with the IRS Strategic Plan. This group also maintains the MITS reports sites, designs and generates a myriad of Incident and Asset Management reports based on the stated needs of business units, and facilitates the sharing data used by the Business Performance Measures System (BPMS).

2.14.2.6  (03-17-2010)
Customer Facing Communications

  1. One or more of the following means of communication will be used to notify customers and/or managers of scheduled and/or unscheduled outages, critical incidents, incident escalation, etc:

    • Info Alert

    • Enterprise E-mail

    • VMS

    • Phone Call

    • Enterprise Advisory

    • IFRAME

    • ACD Broadcast Messages

2.14.2.6.1  (03-17-2010)
ITAMS Alert Notification Website

  1. Information Technology ITAMS Alerts: An Information Technology (IT) Alert is notification prepared by either IT Service Providers or the Enterprise Service Desk (ESD), documenting scheduled/unscheduled outages that impact IT Services. In addition to the Scheduled and Unscheduled outage alerts, general information is also prepared by the IT Service Providers, that may or may not impact access to IT Services, i.e.; power outages, these alerts are viewable to all customers via the following Web Site: http://mitsreports.web.irs.gov/outage.asp.

  2. Information included in an Information Technology ITAMS Alert includes, but are not limited to the following examples:

    • MITS Scheduled Outage

    • MITS Unscheduled Outage

    • MITS General Information Sharing

    • MITS End of Day (EOD) Processing

  3. Enterprise Customer Advisories: IT related incidents where scope and impact are Nationwide are also sent by the designated Advisory Points of Contact of the Enterprise Advisory Team (*MITS Information Services) to impacted IRS Employees and the ESD. The ESD will open an Information Alert (P3) with the received information but will not send out another Information Alert. Procedures are located at the following URL: http://mits.web.irs.gov/M_ProceduresGuidelinesStandards/ProcsGuidesStands_Advisory.htm .

  4. Information included in a customer advisory included but are not limited to the following examples:

    • Weather - National disasters

    • Power Outages with the Computing Centers

    • Scheduled hardware and software enterprise updates

    • Customer Facing Incident Management Tool

    • Viruses

  5. OS Get Services Information Window (IFrame): OS GetServices web site contains a window that is used to disseminate notification for nationwide critical incident outages. This information window area within the web page is referred to as the IFRAME and can be used by ESD and ERC.

  6. The IFRAME content message will reflect the MITS/ERC Toll Free Number ACD front end messages customers hear during major outages or when there are large numbers of calls being received on the same issue. The IFrame points to a small web application that looks up current enterprise " messages" and presents them to the customer.

  7. Content Management Process: The high-level process for creating, approving and publishing content for the IFrame is as follows:

    • An event requiring enterprise customer communication occurs.

    • An ERC or ESD management team member drafts a message with the required data elements.

    • Message is approved by other ERC/ESD management team members.

    • Approved message is forwarded to the ESD ACD team (the same team responsible for adding/removing ACD front-end messages regarding enterprise events).

    • ESD ACD team performs a final QA on the message (spelling and grammar), accesses the ServiceCenter interface for creating/managing content, and creates a new entry.

    • An item expires when the content expiration date/time is exceeded.

    • Access to the ServiceCenter interface is controlled by the ServiceCenter "iframe" capability word. After initial deployment, a user will be granted this capability by completing an OL5081 ITAMS ServiceCenter account modification request. ServiceCenter SysAdmins will contact ESD QASC to obtain approval before assigning the capability word.

2.14.2.7  (03-17-2010)
Incident Escalation/Notification

  1. Incident Escalation/Notification process follows.

2.14.2.7.1  (03-17-2010)
Priority 1 and Priority 2 Incident Escalation

  1. One core function of the ESD is to monitor, track and escalate all Priority 1 and Priority 2 incidents in the MITS environment until resolved. In addition to the 100% post review of P1 incidents and sampling of P2 for post review, the ESD is responsible for the following:

2.14.2.7.1.1  (03-17-2010)
Priority 1

  1. Severe Mission Critical Work Stoppage or ANY issue relating to safety or health (fire, electrical shock etc.). Impact on vital IRS Customer Commitments of National or area-wide scope. Affecting MULTIPLE internal or external customers and impacting service to taxpayers. Immediate action required.

  2. The following checklist will be used by the ESD to monitor, track and escalate Priority 1 incidents:

    • Incident must be assigned to an assignee or an assignment group within 30 minutes.

    • Incident must be updated within 1 hour from open time - Alert Stage 1.

    • Incident must be updated within 2 hours from open time - Alert Stage 2.

    • Incident must be updated within 3 hours from open time - Alert Stage 3.

    • Incident should be resolved within 4 hours from open time - Deadline Alert.

    If not resolved in 4 hours - monitor incident in 30 minutes intervals for updates and closure. Unless an Estimated Time of Resolution is input in this field, escalation will continue.

    Incidents not assigned/updated within 30 minutes will be updated as follows:

    • Alert stage 1 - 30 minutes from open time

    • Alert stage 2 - 1 hour from open time

    • Alert stage 3 - 1.5 hours from open time

    • DEADLINE - 4 hours from open time


    Two types of customers will report Priority 1 incidents:

    • MITS Service Provider - Scope and impact will be defined on initial call or when the Service Provider completes the Standard Unscheduled Outage template which will be attached to the Priority 1 incident.

    • Customer - Scope and impact will be defined once the incident has been assigned and triaged by the Service Provider. The Service Provider will complete the Standard Unscheduled Outage template which will be attached to the Priority 1 incident.

    Note:

    Some Priority 1 incidents are generated automatically for the modernized environment when a pre-defined threshold has been exceeded. The P1 escalation process will be followed for these incidents unless stated differently in P&R for the given issue.

  3. The ESD will designate an ESD Specialist to receive the initial report of a Priority 1 outage via the ACD escalation gate. The ESD Specialist will be considered the Total Contact Owner (TCO) of the Priority 1 incident. The TCO will be responsible for updating the “History” tab within the incident with his/her name along with their manager. The designated TCO and his/her manager will be responsible through incident resolution for:

    • Tracking

    • Monitoring

    • Escalating through closure

    • Performing customer notification

  4. TCO will initiate the Incident Management Escalation process following the Management Escalation Path documented in ITAMS for all P1 incidents that are not:

    • Assigned to an individual/group timely.

    • Updated timely (includes the Service Provider identifying Scope and Impact for P1 Outage).

    • Resolved within the Target Resolution Time.

    • Escalation will continue through the Director Level, if there are no actions taken as a result of escalation.

  5. The TCO Specialist who received the initial call will perform the following actions and document within the ITAMS incident for each Priority 1 incident:

    • Check for Scheduled Maintenance/outage related tickets (to avoid the opening of duplicate incidents), check for active Root Cause Analysis (RCA) records for Known Errors/Workaround Available, Resolution Identified/Pending Change, etc.

    • Attach Priority 1 Confirmation document to ITAMS incident.

    • Issue Level 1 broadcast message.

    • Notify manager so they can determine if incident meets Crisis Event criteria. If so, manager will follow internal ESD procedures for Crisis Event notification.

    • Courtesy call to manager of the assignment/Service Provider group.

    • Complete TCO fields in ITAMS.

    • Open Incident Alert once scope and impact identified.

    • Check with ESD manager to verify if a front-end message needs to be issued for outage.

    • Create Incident Alert e-mail once scope and impact identified.

    • Acknowledge Incident Alert in ITAMS.

    • Associate the Incident Alert to the Priority 1 master incident.

    • Issue Incident Alert e-mail template.

    • Issue Executive Level VMS.

    • Associate & cross-reference calls and incidents to master incident.

    • Monitor incident.

    • Initiate ticket escalation as necessary.

    • Send ticket closeout e-mail template when incident is closed.

    • Follow TCO transfer procedures as necessary.

  6. EOPS SOS will convene a Service Restoration Team (SRT) for P1 incidents when the following rules apply:

    • No progress/update on P1 incident for 30 minutes or more

    • Incident is "bouncing" around to various service providers

    • Multiple service providers are required to isolate the nature of the outage

    • Multiple service providers are required to resolve the outage

    • Multiple service providers are required to determine customer/other workload impacts of the outage (or impacts of potential workarounds, fixes, etc.)

    • Executive-level management approval is needed to implement a workaround or permanent resolution.

      A SRT may be requested by contacting or e-mailing the Service Operations Specialists:

      Common Lines:  304-264-7090 or 901-546-3020

      E-mail:  &MITS ACIOEOPS-ECC-SDM

    SRT notes will be completed for each SRT call and forwarded to the SRT Team Members. The notes will also be attached to the P1 incident and posted to the EOPS SRT SharePoint.

  7. Technical Service Providers and manager have the authority to request the prioritization of a P1 incident, but will be required to define the scope and impact. The ESD Specialist will document the formal request including collecting all contact information of the requestor and all pertinent information.

  8. Service Providers have the authority to direct incident assignment to an Assignment Group. The Probe and Response will be used by the ESD, if the Service Provider does not define incident assignment when reporting the incident.

  9. The Service Provider may close a P1 incident only when the customer concurs that service is restored. The Service Provider must verify that service is restored, contact the customer for concurrence, and enter the incident stop-time in the incident.

  10. If service has been restored, but the root cause was not identified the manager of the Service Provider area may contact the ESD to open an ITAMS R1 ticket (Request for Services) for a Root Cause Analysis (RCA), referencing the P1 incident. See 2.14.2.7.2 for more information on the RCA process.

    1. The RCA will remain open until a Resolution has been identified and implemented.

    2. If service has been restored but the Service Provider recommends a monitoring period, he or she will enter the incident stop time and the anticipated monitoring period as the estimated resolution time. The Service Provider will determine when monitoring is no longer required and close the incident. If the same incident recurs during or after the monitoring period, the Service Provider will open a new incident with a reference in the existing (or new) RCA, as appropriate.

    3. If the incident needs to remain open for any other reason, such as completing required documentation, the incident stop time will be used until the Service Provider closes the incident.

  11. Enterprise Incident Management Standards Escalation Path : Monitoring/Escalation within EUES; Customer call backs for status or lack of timely updates for high impact incidents:

    • First Level - ESD Specialist responsibility::

      Sends Notify to Service Provider & contacts Service Provider manager.

      No response/updates from Service Provider, escalate to ESD manager on duty.

    • Second Level - ESD Manager:

      Contact made to Service Provider manager.

      No Response, escalate to ESD East/West Senior manager

    • Third Level - ESD Senior Management:

      Contact made to EUES Territory manager or EOPS Section Chief by ESD East/West senior manager

    • Fourth Level - ESD Program Manager:

      Notify Customer Relationship Management (POC's listed on
      http://eues.web.irs.gov/home/CRMEscalation.aspx).

      Contact Area Director or EOPS Branch Chief, Peer EUES SM.

    • Fifth Level - EUES Director or EOPS Director

2.14.2.7.1.2  (03-17-2010)
Priority 2

  1. Potential Work Stoppage - Could have a direct impact on the service to taxpayers or if scope is multi-user and there is no work-around. Incident could lead to severe mission critical work stoppage if actions are not taken to resolve incident.

  2. The following checklist will be used by the ESD to monitor, track and escalate Priority 2 incidents:

    • Incident must be assigned to an assignee or an assignment group within 1 hour.

    • Incident must be updated within 2 hours - Alert Stage 1.

    • Incident must be updated within 4 hours - Alert Stage 2.

    • Incident must be updated within 6 hours - Alert Stage 3.

    • Incident should be resolved in 8 hours - Deadline Alert.

      If not resolved in 8 hours - monitor incident in 30 minutes intervals for updates or closure, unless an estimated time of resolution has been input in the incident by the Service Provider.

      Two types of customers will report Priority 2 incidents:

      • MITS Service Provider – Scope and impact will be defined on initial call.

      • Customer – Scope and impact will be defined once the incident has been assigned and triaged by the Service Provider.

        Note:

        Priority 2 incidents are generated automatically for the modernized environment when a pre-defined threshold has been exceeded. The P2 escalation process will be followed for these incidents unless stated differently in P&R for the given issue.

  3. The ESD will designate an ESD Specialist to receive the initial report of a Priority 2 outage via the ACD escalation gate. The ESD Specialist will be considered the Total Contact Owner (TCO) of the Priority 2 incident. The TCO will be responsible for updating the "History" tab within the incident with his/her name along with their manager. The designated TCO and his/her ESD manager will be responsible through incident resolution for:

    • Tracking

    • Monitoring

    • Escalating through closure

    • Performing customer notification

  4. TCO will initiate the Incident Management Escalation process following the Management Escalation Path documented in ITAMS for all P2 incidents that are not:

    • Assigned to an individual/group timely

    • Updated timely

    • Resolved within the Target Resolution Time

    Escalation will continue through the Director Level, if there are no actions taken as a result of escalation.

  5. The TCO Specialist who received the initial call will perform the following actions and document within the ITAMS incident for each Priority 2 incident:

    • Check for Scheduled Maintenance/outage related tickets (to avoid the opening of duplicate incidents), check for active Root Cause Analysis (RCA) records for Known Errors/Workaround Available, Resolution Identified/Pending Change, etc.

    • Issue Level 1 broadcast message

    • Courtesy call to manager of assignment group

    • Complete TCO fields in ITAMS

    • Associate & cross-reference calls and incidents to master incident

    • Monitor ticket through resolution

    • Initiate ticket escalation as necessary

    • Follow TCO transfer procedures as necessary

    • In the event that there is no Estimated Resolution Date or the Estimated Resolution Date has expired the assigned TCO/ESD manager will continue escalation until the end of their shift at which time the incident will be assigned to a new ESD Specialist to TCO.

      Note:

      All incidents needing TCO monitoring must be reviewed and addressed from creation through resolution.

  6. EOPS SOS will initiate a Service Restoration Team (SRT) for P2 Incidents upon review of potential customer impact, systemic nature of outage, etc. See section 2.14.2.7.1.1 for more information on the SRT process.

  7. Service Providers and managers have the authority to request the prioritization of a P2 incident, but will be required to define the scope and impact. The ESD Specialist will document the formal request including collecting all contact information from the requestor and all pertinent information.

  8. Service Providers have the authority to direct incident assignment to an Assignment Group. The P&R will be used by the ESD if the Service Provider does not define incident assignment when reporting the incident.

  9. The Service Provider may close a P2 incident only when the customer concurs that service is restored. The Service Provider must verify that service is restored, contact the customer for concurrence, and enter the incident stop-time in the incident.

  10. If service has been restored, but the root cause was not identified the manager of the Service Provider area may contact the ESD to open an ITAMS R2 ticket (Request for Services) for a Root Cause Analysis (RCA), referencing the P2 incident. See 7.14.2.7.2 for more information on the RCA process.

    1. The RCA will remain open until a Resolution has been identified and implemented.

    2. If service has been restored but the Service Provider recommends a monitoring period, he or she will enter the incident stop time and the anticipated monitoring period as the estimated resolution time. The Service Provider will determine when monitoring is no longer required and close the incident. If the same incident recurs during or after the monitoring period, the Service Provider will open a new incident with a reference in the existing (or new) RCA, as appropriate.

    3. If the incident needs to remain open for any other reason, such as completing required documentation, the incident stop time will be used until the Service Provider closes the incident.

2.14.2.7.1.3  (03-17-2010)
Requesting a Priority 3, 4, or 5 Incident be Upgraded to Priority 1 or 2

  1. In the event that a Priority 3, 4 or 5 incident needs to be upgraded to a Priority 1 or 2, the ESD will close the P3, P4 or P5 incident and open a new P1 or P2 incident.

    • ESD will confirm there is no Scheduled Outage or an existing P1 or P2 incident opened for the outage being reported. If there are no other high priority incident incidents opened or no scheduled outage, the ESD will close the lower priority incident(s) and open a P1 or a P2 incident.

      The P3, P4 or P5 will be closed and coded as follows:

      Cause Code: CUST ERR

      Resolution Code: Not Resolved

      Incident Resolution: Your incident has been closed. This incident is being tracked as a Nationwide Outage. Your new Incident Number is #######.

      The P3, P4 or P5 incident number will be cross-referenced and associated to the P1 or P2 incident.

    • The ESD will contact the customer and inform them of the new incident number.

    • The ESD will open a P1 and attach the Priority 1 Confirmation Template (Unscheduled Outage) or P2 (no template) incident in ITAMS and assign to the appropriate Service Provider.

      The Incident Start Time on the high priority incident will reflect the time of when the scope and impact was determined to be a nationwide impact.

      If the incident is not name assigned or the Priority 1 Confirmation Template (Unscheduled Outage) is not completed within 30 minutes, the ESD will begin the Incident Management Escalation process.

2.14.2.7.1.4  (03-17-2010)
Downgrading Restriction of Priority 1 and 2 Incidents

  1. P1 and P2 incidents will not be downgraded. Below are options a Service Provider may use in place of a downgrade:

    1. Leave the Priority 1/2 incident open and record the actual time the incident was resolved in the Incident Stop Field. This is a date/time field and can be filled automatically with current date and time by selecting the ellipsis button within the field during the incident closing process. During the resolution process, the incident stop time can be entered under the history tab at any time to record when the service was rendered. Priority 1/ 2 outage time is measured from the incident start and stop time, not the open and close time fields in ITAMS.

    2. Close the Priority 1/2 incident and open a lower priority incident. If the Service Provider is requesting to leave the incident open for monitoring, the priority incident should be closed and a new incident can be opened with a priority code to reflect the current impact of the outage.


More Internal Revenue Manual