Skip to main content

FIW Description

Version: 1, effective date: 11-March-2023

Sviatoslav Meshcheriakov

Contents​

1 Introduction​

1.1 Document Objective​

The objective of this document is to describe the approach to optimize the update process for the factories and the vendors with Factory Implementation Window (FIW).

1.2 Background​

Current factory upgrades have a series of flaws: hard to get approval, the necessity of multiple factory stoppages for each of the systems, and so on. The goal is to optimize this process

1.3 Systems in the scope of the update​

  • TPM

  • Inexto Gate

  • GLA

1.4 Process in scope​

One factory update window for all of the systems with the schedule for all of the factories.

1.5 Systems to update out of Scope​

  • Systems located not on the factories side(CR,Vault,etc.)
  • SAP

1.6 Regulations in Scope​

The FIW process will not filter factories by any regulation, all factories will be in the process.

2 Factory Implementation Window Strategy​

The Factory Implementation Window process will be split into three phases to test and implement this strategy for all factories.

  • Phase 1 – Implement FIW for the pilot factory (GRP1 factory)

  • Phase 2 – Implement FIW for the next factories. (ROP1 and CSP2)

  • Phase 3 – Implement FIW for all leftover factories one by one

2.1 TimeLine​

  • TBD

2.2 Milestones​

Figure 1

3 Factory Implementation Window​

The factory implementation window is about to schedule a fixed update window for each factory, for example, each second Tuesday Andorra factory should be stopped for up to two hours, for GLA and TPM updates.

3.1 Prerequisites​

  • FIW should take place only within the working time of the JTI T&T Employees

  • FIW shouldn’t take place on Monday and Friday

  • In case the national holiday intersects with the update day, this case will be resolved individually according to JTI T&T Team availability

  • ITSP ticket should be created for each FIW update

  • The T&T Support team should be aware of all FIW updates.

  • In case updates take more than 2 hours tasks, should be split into multiple waves.

  • In case an update is not successful, restoration to the initial state should be done within the 2-hour window

3.2 Preparation​

To implement the new factory, the T&T team should approve the schedule of the FIW with the factory individually. Factory, on their side, took responsibility to be ready to stop the factory for the scheduled time and provide a contact person for the update time.

The T&T team took responsibility to send an updated plan to the factory upfront via ITSP and email with scheduled system updates and informing the factory in case there will be any changesto the scheduleв update.

3.3 Process Description​

  1. T&T team, for two weeks before the update window, send the factory update plan with a description of the updated systems and the type of update (Hot – without DB stoppage, Cold – with DB stoppage).

For example;

SystemUpdate TypeTime to updateStoppage neededChange Description
GLACold2 hYes1. Update to version 4.6.4 - 2. Configure Colos Software for the secondary server
TPMN/AN/AN/ANo need to update
GateHot20 minNot neededIncreased production speed

  1. According to provided information factory does preparations, including DB incremental backup in case of a cold update.

  2. In scheduling time factory updates

  3. After testing and confirmation of workability, the factory goes back to BAU.

  4. In case of problems that couldn’t be solved within the FIW time slot, all systems should be switched to a backup ALOHA server and solve the issue offline, without factory further stoppage.

3.4 Benefits​

  • Reduce time stoppage for the factories

  • Dramatically reduce time spending for approval of the update slot and factory stoppage

  • Determining the best downtime when the loss will be the least according to the production plans

  • Scheduling a fixed update window for the factory instead of having separate downtimes for each system

  • Reduce update time for the T&T team

  • With DevOps process updates could be automated

3.5 Potential Risks​

  • Updating all the systems at the same time makes it harder to diagnose the issues which could happen in the test phase.
    • To avoid this there will be a QA training update + with every subsequent update there will be more experience in the update process and diagnostic
  • In case of serious problems with the updated system, the probability of not getting into the allocated window increases, and because of this, the update will be delayed for a month.
    • Could be solved by changing the schedule and partial update

4 “Systems to update” Description​

Figure 2

5 FIW Workflow​

Figure 3

6 Roles​

Role NameDescriptionCurrent Assignee
FIW ManagerCoordinate preparations for FIW: contact with factories, collecting questioniere and so on. Not participate in update itself.Meshcheriakov, Sviatoslav
Factory clusterPerson who is in charge of schedule approvel for factories.Helmeseanu, Marius
GSCPerson who is in charge of update approvel from GSC side.-
FactoryPerson who is in charge of support of update on factory side: stop the production, check the production after update and so on.Individual per factory
GLA adminPerson who in charge of update of the GLA system: plan, update and making decision of rollback, if it needed.Kondratyev, Andrey
TPM adminPerson who in charge of update of the TPM system: plan, update and making decision of rollback, if it needed.Rodrigez, Joaquin
Inexto adminPerson who in charge of update of the Gate system: plan, update and making decision of rollback, if it needed.Evdokimov, Pavel

6.1 Revision History​

VersionEffective datePurpose of changeAuthor
111-March-2023Initial draftSviatoslav Meshcheriakov

ANY QUESTIONS?

ASK TEAM