Skip to main content

Procedure: T&T Incident Management

Contents​

SectionPage
A. Purpose & Benefits3
B. Scope3
C. Roles & Responsibilities3
Customer3
1st level of Support4
2nd and 3rd levels of support: Subject Matter Experts and Product Owners / Vendors4
D. Procedure5
D.1 Incidents Reported by Users5
Submission7
Registration7
Analysis8
Resolution10
Testing/confirmation11
Documenting Solution & Closure11
E. Definitions11
F. Performance Indicators11
G. Document Owner12
H. Document Management12
Contact Person12
Review Cycle12
Document history12
I. Approval12
J. References12
K. Appendix13
K.1 T&T Incidents Management Procedure Diagram13

A. Purpose & Benefits​

The purpose of this procedure is to describe the standard phases and controls of the JTI IT Incident Management for Track & Trace (T&T) related Incidents (Incidents raised under JTI-TAT business application).

The main goals addressed by this procedure are to:

  1. Ensure consistent management of Incidents throughout JTI IT Business Technology Services (BTS), IT Global Delivery Center (GDC) and T&T Business Support team (Business counterpart for T&T incidents resolution)
  2. Define standard phases and associated controls of JTI T&T Incidents Management
  3. Define roles and responsibilities of involved groups in each of the phases

B. Scope​

This procedure applies to all JTI IT incidents raised under JTI-TAT business application.

C. Roles & Responsibilities​

The following ARCI matrix highlights main roles (or IT Function) and responsibilities (Tasks) defined by the present document:

#TaskCustomer / Power User1st level of Support (IT support)1st level of Support (Business Support)2nd level of Support (Subject Matter Expert - SME)3rd level of Support (Product Owners / Vendors)
1Search My Knowledge for appropriate Knowledge Base Article and apply if availableAR
2Report incident if solution is not availableARR
3Register incident in ITSPRARRR
4Perform initial analysisCARCC
5Search for solution including articles in the IT Knowledge BaseIARR
6Resolve Business related incidentsIIARIC
7Escalate to IT Resolution Group if were not able to find an appropriate solutionIAR
8Resolve incident and provide solution to Assignment memberIIARC
9Confirm with customer IT related incidents resolutionCAR
10Confirm with customer Business related incidents resolutionCAR
11Create / update IT Service Portal (ITSP) knowledge article if necessaryARR
12Close the incidentIARR

ARCI meaning:

  • Responsible: Person who works to complete the task
  • Accountable: Person to whom “R” is reporting and who is the authority to sign-off on task completion
  • Consulted: Person who provides information and/or expertise necessary to complete the task (two-way communication)
  • Informed: Person who needs to be notified of the task outcome but does not need to be consulted (one-way communication)

Customer​

Any T&T application user, who creates an Incident in the IT Service Portal.

  • Reports T&T services disruption
  • Customer is responsible to confirm applicability of the solution offered

1st level of Support​

1st level Support organization:

  • T&T IT Support team
  • T&T Business Support team (for details see paragraph 10 of section D below)

Responsibilities:

  • Performs preliminary analysis of an Incident
  • Initially assesses and periodically re-assess prioritization of an Incident
  • Applies a standard solution(s) and operational scripts documented in the T&T IT Support Knowledge Base, performs advanced troubleshooting
  • Ensures end-to-end and timely resolution of the Incident (Incident ownership)
  • Escalates the incident to the 2nd level of Support / Global Supply Chain Compliance Projects team (GSC CP), when applicable
  • Ensures follow-up on resolution activities with all teams and experts involved
  • Manages communication between all Support levels
  • Keeps incidents up-to-date with latest communication or investigation results
  • Keeps Customer up-to-date with investigation status or results
  • Provides assistance to a Customer while testing a solution proposed
  • Updates the IT Knowledge Base with known solutions on a regular basis and keep them up-to-date
  • Verifies the solution with Customer and confirms incident closure

2nd and 3rd levels of support: Subject Matter Experts and Product Owners / Vendors​

This role is assigned to the support IT team(s) in charge of the service on which incident was raised:

  • IT GDC
  • IT BTS
  • GSC CP
  • Vendors Support organizations:
    • Fracture Code
    • Inexto
    • Osapiens
    • Sierra
    • WorldLine
    • Dentsu
    • DeLaRue
  • Global IT functions:
    • NCC (Networks and Communications Center)
    • GDC
    • Global Service Desk (GSD)
    • ICS (Identity and Collaboration Solutions)

Responsibilities:

  • Investigate on the incident escalated by the 1st level of Support based on information provided
  • Find respective solution or workaround and apply it (2nd and 3rd level support)
  • Search for root cause
  • Ensure that identified root causes are captured as defects and fixed during the development cycles

If the issue which can affect T&T end user is detected by any of the T&T team members, issue is to be reported via ITSP Incident raising by this T&T team member.

D. Procedure​

D.1 Incidents Reported by Users​

Incidents Reported by Users are managed as described per T&T Incident Management Procedure Diagram below and in the attachment in section “K”.

T&T Incident Management Procedure Diagram — text conversion​

The diagram is a swimlane process flow involving the following lanes:

  • Customer / end-user
  • Customer / Power User
  • IT support (1st level)
  • Business Support (1st level)
  • 2nd level support
  • 3rd level support / Vendors
  • IT functions (NCC, DCO, etc.)
  • GSC CP

Main flow and decision points captured from the diagram:

  1. Customer / Power User

    • Issue appears
    • Find issue resolution with available knowledge and KBA
    • Decision: Is issue solved?
      • Yes: Issue is resolved
      • No: Incident is raised in the ITSP

  2. IT support (1st level)

    • Issue identified
    • Incident is raised in the ITSP
    • Assess the priority
    • Decision: Is Business Support to be involved for consultation or full resolution?
      • No: Find resolution using operational scripts
      • Yes: Request support from Business Support
    • Decision: Is incident resolved?
      • Yes: Request confirmation from Power User to close incident
      • No: Request support from IT BTS SME
    • Decision: Is closure confirmed?
      • Yes: Incident is closed in the ITSP
      • No: Continue follow-up / analysis

  3. Business Support (1st level)

    • Issue identified
    • Find resolution or consulting
    • Decision: Is consultation provided?
    • Decision: Is the provided consultation sufficient?
      • Yes: Continue toward closure confirmation
      • No: Request support from GSC CP
    • Decision: Is incident resolved?
      • Yes: Request confirmation from customer to close incident
      • No: Continue support / escalation
    • Incident is closed in the ITSP when closure is confirmed

  4. 2nd level support

    • Investigate (by IT)
    • Decision: Is the solution found?
    • Decision: Is IT functions support or consultation required?
    • Decision: Is Vendor Support required?

  5. 3rd level support / Vendors

    • Provide support and consultations
    • Decision: Is incident resolved?

  6. IT functions (NCC, DCO, etc.)

    • Provide support and consultations
    • Decision: Is incident resolved?

  7. GSC CP

    • Providing support and consultations

Submission​

  1. Incident can be submitted by:
  • Customer — when there is no known solution available
  • IT / Business Support teams or 2nd level Support SME — when issue is detected by the appropriate team
  • GSD — when T&T Incident is raised via phone call or e-mail to GSD

Registration​

  1. Once Incident is raised and is assigned to T&T IT Support team, the member of this team must assign the Incident to themselves. The T&T IT Support team member to whom the Incident was assigned (Assignment Member) shall put himself as an Incident Owner.

  2. When information provided by Incident Initiator is not sufficient to perform the analysis, prioritization or investigation, the Incident Owner or Assignment Member gathers additional information from the Incident Initiator. Any communication is logged by the Incident Owner or Assignment Member into the IT Service Portal.

  3. Incident Owner or Assignment Member checks the incident for the following:

  • If the reported incident duplicates an earlier registered incident, then the newly created incident is linked to the earlier registered (parent) incident in the status “waiting for -> problem / major incident resolution”. Once parent Incident is resolved User is notified automatically. Incident investigation and escalation is logged within a parent incident
  • If the request is in fact a Change that should go through the T&T Ideation form (refer to GSC CP Demand Management Process), the Incident Owner advises the User to submit the Idea via T&T Ideation form. The Incident Owner then closes the Incident with respective solution and solution code
  • If the request is a Service Request that should go through the IT Service Request process (refer to 10.018 IT Service Request Management Procedure) then the Incident Owner advises the User to submit an IT Service Request via the IT Service Portal or opens IT service Request on behalf of User. Incident Owner then closes the Incident with respective solution and solution code
  • If there is an available Knowledge Base (KB) which can solve the Incident, Incident Owner links this KB to the Incident

Analysis​

  1. Incident Owner or Assignment Member performs the initial Prioritization of the Incident by defining the Incident’s urgency and impact.

This includes finished goods warehouses located at the factories.

RatingImpactUrgency
150% of operations at the market are blocked and market affected is one of the markets summing up 80% of total T&T sales volume and no applicable workaround available. Critical products involved and no replacement available. Out of Stock (OOS) situation occurredUrgent shipment (<24hrs) driven by contractual obligations, risk of write-off (e.g.: expected price change), or lack of successful Arrival message. JTI customer fails to send Arrival messages and problem is on JTI side
2Warehouse operations are fully blocked, but <50% of operations at the market and no applicable workaround and / or replacement product available. Risk of OOS is foreseenJTI fails to execute shipment in full compliance with local T&T legislation. JTI fails to execute arrival in full compliance with local T&T legislation at JTI warehouse and the further shipment is not urgent (>24hrs)
3Operations at warehouse are not fully blocked, applicable workaround and / or replacement product availableJTI fails to execute other types of operation in full compliance with local T&T legislation: arrival - return from customer, aggregation / disaggregation messages, deactivation, trans-loading. T&T operations and/or applications are not directly affected, but somehow involved
RatingImpactUrgency
1>25% of total factory production capacity and minimum 4 lines are blockedJTI fails to report production data to local T&T governmental systems. Factory cannot start production due to unavailability / inaccessibility of some T&T services. No temporary solution exists; e.g.: case packer rejects all bundles, FCReader does not work, etc.
2<25% of total factory production capacity is blockedFactory foresees problem to start / run production due to unavailability / inaccessibility of some T&T services in the next 72hrs. Temporary solution exists and applied, but requires significant extra efforts (overtime, extra human resources, increased rejects, extra costs, etc.); e.g.: case packer reading speed reduced, FCReader reject rate increased
3Some production lines, or certain process affected, but production is still runningTemporary solution exists and applied by factory; e.g.: request to check codes availability for WO, update label template. T&T operations and/or applications are not directly affected, but somehow involved
  1. When Impact and Urgency is assessed, Incident Priority is defined with the below matrix:
Impact \ Urgency3 - Normal2 - Important1 - Critical
1 - High321
2 - Medium432
3 - Low543

  1. In case there is a business necessity, GSC CP Director has the right to request increase final priority rating by 1 point (e.g.: from P2 to P1) for any Incident, by providing the T&T support team with reasons to increase impact/urgency. This additional information must be recorded in the incident to support this priority increase.

  2. If several Incidents are evaluated with the same rating and there is no capacity to handle them simultaneously (e.g.: two P1 incidents at a time), following rules to be applied:

  • If Incidents are raised by markets (distribution), then GSC CP Business Support Manager (or GSC CP Director) to decide which Incident to be resolved first
  • If Incidents are raised by factories (production), then an appropriate GSC CP Implementation Manager (or GSC CP Director) to decide which Incident to be resolved first
  • If Incidents are raised by market and factory, then GSC CP Business Support Manager and an appropriate GSC CP Implementation Manager should come to an agreement (or GSC CP Director) which Incident to be resolved first
Role / ResponsibilityScope
GSC CP DirectorAll markets and factories
GSC CP Business Support ManagerAll markets
GSC CP Implementation ManagerFactories of: Russia, Kazakhstan, Uzbekistan, Ukraine, Belarus, Turkey, Taiwan, Indonesia, Korea, Philippines, Egypt, Brasil
GSC CP Implementation ManagerFactories of: Romania, Poland, Serbia, Germany, Greece, Spain, Andorra, United States, Canada, Switzerland, Egypt

  1. For incidents reported by T&T Customer (Power User - PU) but not related to T&T ownership can be transferred to GSD. In this case the incident is reassigned by the Incident Owner to the GSD Team. At this point, the new Incident Owner (GSD) takes full responsibility for the subsequent incident processing.

  2. After Priority is assessed Incident Owner or Assignment Member checks if the Incident has to be assigned to the T&T Business Support team.

10.1 Business Support team assignment scope​

Business Support team to be assigned to the Incident, if the Incident topic lies within the following scope:

10.1.1. Process description and process flow diagram development

10.1.2. Support to factories and markets in developing reports customized to their specific business requirements

10.1.3. Business process related problem analysis, root cause identification and solution development

10.1.4. Support of business changes (systems, legislations, etc.) implementation to the T&T markets and factories

10.1.5. T&T Master data maintenance

10.1.6. T&T related trainings for PU

10.2 Business Support team watch list involvement​

Business Support team to be involved and added to Watch list of the Incident if following criteria are met:

10.2.1. It is the 3rd time in the recent 4 weeks when market / factory opens Incident on the same issue / topic

10.2.2. Problem occurred because of T&T user not following correct process

10.2.3. PU raised Incident although problem can be resolved by KB and KB has been shared with PU

10.2.4. Incident has been assigned with Priority 1 or Priority 2

Resolution​

  1. Incident Owner or Assignment Member shall amend Incident Priority if Incident Impact or Urgency changes. The priority of the incident can’t be decreased except it was set by mistake. If Priority of the Incident was set higher than actual by mistake, it shall be decreased to reflect the real severity of the Incident. Respective comment must be included in the work notes of the incident.

  2. If Incident is classified with Priority 1, it shall be managed in line with 10.007 Major Incident Management Procedure. To raise the priority of the incident to P1, assignment member must fill in P1 template and ask GSD (call to GSD + re-assigning of the ticket to GSD) to raise the priority to P1.

  3. Assignment Member / Incident Owner has to track time passed after Incident was classified with Priority 1.

If Priority 1 Incident is not resolved within 4 hours for distribution related incidents or within 6 hours for production related incidents, Incident Owner / Assignment Member initiates T&T Crisis Management procedure.

  1. Incident Owner or Assignment Member investigates the incident. If solution cannot be found, then (s)he records the current results of investigation and requests support either from IT BTS TT / GDC-Track & Trace Delivery Center (GDC-TTDC) Subject Matter Expert (if Incident is assigned to T&T IT Support), or from GSC CP Subject Matter Expert (if Incident is assigned to T&T Business Support) by assigning the incident in IT Service Portal to the relevant ITSP group. If support from IT infrastructure related teams is required, Incident to be assigned to the relevant ITSP group. Resolution of security incidents is owned by Security Operations Center and are managed as per details in 10.008A Security Incident Management.

  2. New Assignment Group investigates the issue, escalated by the Incident Owner and completes the Incident back to the Incident Owner with the solution for the incident as a note. In case any clarification is required or another IT team should be involved, the current Assignment Group reassigns the Incident back to the Incident Owner with corresponding comments.

  3. If resolution of the reported issue requires implementation of a change for bug fixing and there is no workaround, the Incident Owner applies to Customer with a suggestion to open demand.

16.1. If Customer confirms readiness to open a demand and participate in User Acceptance Test (UAT), Incident shall be closed with solution code “Passed - Passed to Demand, Change or Service request”

16.2. If Customer refuses to open a demand and participate in UAT thereafter, Incident shall be closed with solution code “Unable - not able to solve or in conflict with Standard or Policy”

  1. If the resolution of the reported issue can only be performed with a new release of an IT system involved, Incident is marked as waiting for release and kept in open state. The Vendor/Development Team is informed about the issue. Such incidents will be resolved as soon as the new release is implemented. Long lasting Incidents can be closed with “Unable to Solve” solution code (no workaround is available) and the Customer shall be informed that unfortunately there is no solution for this issue for the time being. However, if there is a risk that similar Incidents will occur again proactive/reactive Problem ticket to be opened to continue investigation, find and eliminate root cause. The customer who reported the incident must be added to the customer watch list.

  2. If the resolution of the reported issue will be performed with Disaster Recovery Process (DRP) invocation, incident is marked as “DRP activation” and kept in open state. Such incidents will be resolved by initiating an existing disaster recovery procedure.

  3. Once the solution is found, the Incident Owner or Assignment Member provides it to the User by the most appropriate communication channel (ITSP, email or phone), explaining the cause of the issue and steps to be done to resolve it. The solution must be logged into “Solution” field of the incident. The Incident Owner or Assignment Member provides User with all necessary consultancy and assistance, when necessary.

Testing/confirmation​

  1. If solution is applied in testing instances firstly, Incident Owner or Assignment Member assists User with testing, providing necessary consultancy and making sure, that all necessary customizing and configuration relevant for testing are in place.

  2. As soon as required solution is delivered in production instance, User is expected to confirm to the Incident Owner that the solution resolves the reported issue. The following rules apply to User confirmation:

  • If the User replies that the incident is not resolved as expected, the Incident Owner proceeds with further analysis of the incident
  • Incident is treated as successfully resolved and confirmed for closure when the User confirmed resolution or when user did not get back to Incident Owner within 10 business days with any meaningful reply. Then the customer has 14 days to re-open the incident in case of necessity

Documenting Solution & Closure​

  1. Once solution is provided, the Incident Owner decides wherever it should be documented in the Knowledge Base and marks an incident as potential knowledge if necessary. Such marked incidents are followed up with after incident closure as per 10.044 Knowledge Base Management Procedure.

  2. Once closure confirmation from User is obtained, incident is resolved. When closing the incident, the Incident Owner ensures that the solution is clearly stated in the incident and the reference of the Knowledge Base Article — if one was used to resolve the incident — is specified.

  3. When multiple instances of the same incident occur or when the root cause of an incident could not be identified and Incident Owner believes it is necessary to investigate, Incident Owner registers a new Problem in ITSP to eliminate the root cause of the incident as per 10.081 Problem Management Procedure.

E. Definitions​

The following definitions apply:

  • Category (Incident)
  • Subcategory (Incident)
  • Incident
  • Security Incident
  • IT Service
  • SAP Subcategory (Incident)
  • Resolution Group
  • Support Level

Refer to Glossary of IT Terms for definitions.

Refer to IT P&P Portal Glossary for any further definitions.

F. Performance Indicators​

In order to measure proper implementation of this document and its effectiveness in serving the management goals defined above, the performance indicators will be measured and reported to GSC CP, IT T&T BTS and IT T&T Delivery Center Management.

Definition and technical design of the performance indicators and regular report are determined in the T&T Support Model.

G. Document Owner​

This document is owned by GDC T&T Delivery Center Director.

Any exception to this document must be duly justified and documented by the requestor and authorized by the Document Owner.

H. Document Management​

Contact Person​

Questions and feedback regarding this document should be submitted to the above listed Document Owner or his designated delegate.

Review Cycle​

The Document Owner will review (and update, where required) this document every four years or whenever changes in business environment demand such a review.

Document history​

VersionDate of issueEffective datePurpose of change
1.1July 31, 2023August 01, 2023New document

I. Approval​

RolePosition TitleSign-Off
WriterT&T Service Delivery ManagerOctober 21, 2022
WriterGSC CP Business Support ManagerOctober 21, 2022
ReviewerGDC T&T Delivery Center DirectorJuly 19, 2023
ReviewerBTS T&T Service DirectorAugust 02, 2023
ReviewerGSD Tower Manager, Business Solutions (T&T)June 14, 2023
ReviewerIncident & Problem Management Processes OwnerJune 08, 2023
ReviewerIT Business Continuity Manager
ReviewerGSC Compliance Projects DirectorOctober 24, 2022
ApproverBTS Track & Trace Program DirectorAugust 18, 2023

J. References​

  1. 10.008A Security Incidents
  2. 10.008B SAP Incident Categorization Guidelines
  3. 10.008C Security Incident Report
  4. 10.008D Security Incident Prioritization
  5. 10.007 Major Incidents and Crisis Management Procedure
  6. 10.018 IT Service Request Management Procedure
  7. 10.019 Operations Change Management Procedure
  8. 10.017 Change Management Procedure
  9. 10.044 Knowledge Base Management Procedure
  10. 10.081 Problem Management Procedure
  11. T&T Support Model

K. Appendix​

K.1 T&T Incidents Management Procedure Diagram​

The appendix references the file:

T&T Support Process.pdf