FUITSU
FUJ00233141
FUJ00233141
POA LIVE DEFECT MANAGEMENT PROCEDURES
FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Document Title:
POA LIVE DEFECT MANAGEMENT PROCEDURES
Document Reference: SVM/SDM/PRO/4313
CP/CWO Reference: None
Abstract:
Document Status:
Author & Dept:
Description of the procedures and systems to be used on the Post
Office Account for Live Defect Management
APPROVED
Steve Browell
External Distribution: None
Information
Classification:
See section 0.9
pana Authorities:
Steve Bansal Senior Service Delivery See Dimensions for record
Manager
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 1.0
UNCONTROLLED WHEN PRINTED OR _Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS
PageNo: 1 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. e
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN €&
CONFIDENCE)
0
Document Control
0.1 Table of Contents
0 DOCUMENT CONTROL 2
0.1 Table of Contents 2
0.2 Document History 3
0.3 Review Details... 3
0.4 Associated Documents (Internal & External) 3
0.5 Abbreviations 4
0.6 Glossary... 4
0.7 Changes Expected 5
0.8
0.9
1
14
1.2
1.3
2 LIVE DEFECT MANAGEMENT
21 Principles ..
2.2 Tagging
2.3 Live Defer
2.4 Managing the Defe x
2.5 Reporting . 0
2.6 Data checkii 0
27 0
24 0
27.2 PTF — Fujitsu internal. 2
2.7.3 HDR (including CBIF) — joint Fujitsu and POL meeting. 3
2.7.4 CBIF (part of HDR) — joint Fujitsu and POL meeting. 4
B APPENDIX — CHECKLISTS FOR TFSNOW & PEAK STACK OWNERG...........23
C APPENDIX —- NO FAULT FOUND RESPONSE CATEGORIES IN PEAK...........24
E APPENDIX - DEPLOYING FIXES VIA RELEASE MANAGEMENT.............00008 26
F APPENDIX - DEPLOYING FIXES OUTSIDE OF RELEASE MANAGEMENT...28
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version 1.0
UNCONTROLLED WHEN PRINTED OR —_ Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 2of29
FUJ00233141
FUJ00233141
POA LIVE DEFECT MANAGEMENT PROCEDURES -
FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
FUJITSU
0.2 Document History
Only integer versions are authorised for development.
Version No.
Summary of Changes and Reason for Issue
Associated Change
CWO, CP, CCN or
PEAK Reference
0.1 03-OCT-2023 Initial draft N/A
02 04-OCT-2023 I Updates following initial SME reviews. Ready for wider review I N/A
1.0 17-Oct-2023 Approval version N/A
0.3 Review Details
Review Comments by:
Review Comments to:
Steven Browell + POA Document Management
Mandatory Review
Role
Name
Defect & Service Process Manager
Matthew Hatch
POA SDM
Sandie Bothick
SSC Manager
‘Adam Woodley
SSC Team Leader
John Simpkins
Senior Service Delivery Manager
Steve Bansal
Release Management and Operational Change Manager
Tomi Okelola
Test Manager
Joan Duhaney
POA UK Application Delivery Lead
Tariq Arain
Optional Review
Role Name
LST Test Manager Mark Ascott
Head of Post Office Account Business Operations Graham Allen
Applications Architect Steven Porter
Operations Manager Jerry Acton
Business Requirements and Acceptance Manager - POA I Steve Evans
(* ) = Reviewers that returned comments
Issued for Information — Please restrict this
distribution list to a minimum
Position/Role Name
0.4 Associated Documents (Internal & External)
© Copyright Fujitsu 2023
FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 3 of 29
FUITSU
POA LIVE DEFECT MANAGEMENT PROCEDURES
FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
FUJ00233141
FUJ00233141
References should normally refer to the latest approved version in Dimensions; only refer to a
specific version if necessary.
Reference Version Date Title Source
PGM/DCM/TEM/0001 I See note I See note above POA Generic Document Template Dimensions
(DO NOT REMOVE) above
PGM/DCM/ION/0001 POA Document Reviewers/Approvers I Dimensions
(DO NOT REMOVE) Role Matrix
SVM/SDM/PRO/4317 I Latest See Dimensions POL Horizon Defects Review Terms Dimensions
of Reference
SVM/SDM/PRO/0875 I Latest See Dimensions Application Support Strategy Dimensions
SVM/SDM/PRO/0018 I Latest See Dimensions POA Operations Incident Dimensions
Management Procedure
SVM/SDM/PRO/0001 I Latest See Dimensions POA Operations Major Incident Dimensions
Procedure
SVM/SDM/PRO/4695 I Latest See Dimensions Post Office Account Defect Dimensions
Management Reporting
CS/MAN/011 Latest See Dimensions Peak User Guide Dimensions
SVM/SDM/PRO/1520 I Latest See Dimensions Release Management Strategy Dimensions
0.5 Abbrevia
tions
Abbreviation Definition
BIF Business Impact Forum
CBIF Customer Business Impact Forum
DEV DEVelopers
HDR Horizon Defect Review
HKERF Former Horizon Known Error Review Forum
KB Knowledge Base
KBA Knowledge Base Article
KEL Known Error Log (previous name for KB)
LDM Live Defect Management
MAC Major Account Controllers
Mss Managed Systems Support
NFF No Fault Found
PMO Programme Management Office
POA Post Office Account
POL Post Office Limited
PTF Peak Targeting Forum
RMF Release Management Forum
SDLC Software Delivery LifeCycle
SMC Systems Management Centre
0.6 Glossary
© Copyright Fujitsu 2023
FUJITSU RESTRICTED (COMMERCIAL IN Ref:
CONFIDENCE) Version:
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS. Page No:
SVM/SDM/PRO/4313
1.0
17-Oct-2023
FUJ00233141
FUJ00233141
oe POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Term Definition
Alphabetical order please
Bonded An Incident is “bonded” to enable synchronisation between Fujitsu TfSNow and POL
ServiceNow
Peak The Incident Management System used by POA 3” and 4" line support teams and
other capability units involved in HNGX releases. It interfaces with the TfSNow call
management system.
Stack/Resolver Group A container within a service management toolset containing a collection of items
belonging to a designated owner and group e.g. items for a Windows Server support
team could be in the WindowsServer stack/resolver group owned by the leader of the
Windows Server team
TfSNow Triole for ServiceNOW - Service Management Toolset (Incident Change Problem)
0.7 Changes Expected
Under regular continuous improvement review
0.8 Accuracy
Fujitsu Services endeavours to ensure that the information contained in this document is correct but, while every
effort is made to ensure the accuracy of such information, it accepts no liability for any loss (however caused)
sustained as a result of any error or omission in the same.
0.9 Information Classification
The author has assessed the information in this document for risk of disclosure and has assigned an information
classification of FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE).
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 5 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
1 Background & Introduction
This document pulls together the many working processes from many teams to present a consolidated
view of the POA end-to-end process of Live Defect Management (LDM).
It describes how the systems should be used and how various teams need to interact to ensure an
effective end-to-end process is followed, tracked and reported on.
LDM uses the POA Peak system. Live Defects must be recorded as Peaks.
The processes described in this document align to the 2021 definition of a Defect as agreed with Post
Office Limited (POL).
1.1. Ownership
The LDM process is owned by the POA Defect & Service Process Manager.
1.2 Scope
LDM relates to the Live system. LDM does not cover the management of test defects raised during the
Software Delivery LifeCycle (SDLC) as these are managed under their own test defect management
processes. If a defect is found during the SDLC that relates to the Live system (as defined below) then
that defect will be treated as a Live Defect and will be managed following the LDM process described in
this document.
1.3 Definitions of Live Defect and HDR Defect
Fujitsu uses 2 definitions of a Defect to allow it to track entries in its systems: a Live Defect; and a HDR
Defect. These definitions were agreed with POL to ensure consistency in reporting and language and
POL then included these in its “POL Horizon Defects Review Terms of Reference” document. “Bugs.
Errors and Defects” are collectively referred to as Defects.
Both defined Defect types are made visible by using tags in the Fujitsu TfSNow and Peak systems.
A Live Defect is defined as an issue that:
+ Is present on a LIVE system
+ — Is within Fujitsu's scope of obligations
+ — Is, or appears to be, inconsistent with the agreed design or service specification
+ — Is, therefore, a fault that is likely to need fixing
A HDR Defect is defined as a Live Defect that also has at least 1 of the following attributes (HDR
Defects):
+ Affects, or has the potential to affect, branch financial outcomes
+ Affects, or has the potential to affect, the way a postmaster is required to use the system (User
Interface, Report, Function)
+ Affects, or has the potential to affect, the experience of a Post Office customer or client
HDR Defects are classed as either “Financial” impacting (which POL call “Impact” and Fujitsu call
“Financial”) or “Experience” impacting (which we both call “Experience”).
Throughout this document, there are additional terms and phrases that apply. The key ones are:
« HDR Forum — a weekly meeting with POL to review HDR Defects. POL need to know the HDR
Defects and their status. It is understood that POL share this with postmasters. This is a very
important meeting that sees Fujitsu and POL aligned on the HDR Defects.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 6 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e Investigation Peak/Potential Live Defect (Peak) — is an Incident that is being investigated
where the cause and required action are not yet confirmed. A linked TfSNow Incident may well
exist — and MUST exist if POL need to be aware.
e Defect Peak — is a new Peak that is not linked to a TfSNow Incident (but is created from the
Investigation Peak/Potential Live Defect Peak so it carries all the required historical data) and
that describes a confirmed Live Defect where the cause and required action to fix are known. The
investigation has concluded.
e Knowledge Base (KB)/Knowledge Base Article (KBA) — The Knowledge Base is an
information repository used for support purposes. Knowledge Base Articles are descriptions of
aspects of the system that have been recorded to help support staff. The term Known Error Log
(KEL) is no longer used. Live Defects are NOT managed using the Knowledge Base but there
may be KBAs that describe aspects of Live Defects.
2 Live Defect Management
2.1 Principles
When an Incident is raised it can become a Live Defect. The management of Incidents is therefore a
critical initial step in the LDM process.
e Live Defect Management is owned by the POA Defect & Service Process Manager.
e Live Defects must be recorded as Peaks and managed using the Peak system.
e Fujitsu uses Peak references for Live Defects, not TfSNow Problem references.
e Live Service is always the priority so Live Defects take priority over Project work — including
during the investigation stage. Conflict is to be escalated and handled by management.
e POA must know how many Live Defects and HDR Defects there are at any point in time.
« POA must be able to differentiate between Live Defects that are still being investigated and are
not confirmed, and Live Defects that have been confirmed and require action to resolve.
e POA needs to know the status of all Live Defects and whether there are any issues needing
attention.
e — If.an Incident relates to the Live environment, then it is treated as a Live Defect until proven
otherwise.
e When raised in Peak, it has the LiveAffectingDefect tag added for easier identification and
tracking.
e The required fields and tags within Peak must be kept up to date to enable tracking of status and
reporting of progress (see Appendix A — Key Fields in Peak).
The status of all Live Defects must be always known and must be reported to POL.
e All POA support teams must ensure progress is being made on items in their stacks.
« POA must always seek to identify a workaround for confirmed Live Defects - and update Peak.
e Every confirmed Live Defect must be targeted at a numbered release as early as possible so it is
clear when the fix will be deployed (refer to Appendix E — Deploying Fixes via Release
Management):
o Some fixes need to be deployed outside of the release process and via operational
change (refer to Appendix F — Deploying Fixes outside of Release Management).
e Releases without dates must be escalated to POA management and POL until a date is
assigned. This can be mitigated with pre-agreed maintenance release schedules.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 7 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES.
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e If POL postpones a scheduled maintenance release, then this is a POL decision and the release
deployment date will be updated.
e If POL cancels a scheduled maintenance release, then this is a POL decision and any confirmed
Live Defects within that proposed release become temporarily accepted defects by POL.
2.2 Tagging
An Incident is defined in the HNG-X contract as “any perceived abnormal or undesirable occurrence
relating to the Services”. Incident Management procedures are defined in “SVM/SDM/PRO/0018 - POA.
Operations Incident Management Procedure”, “SVM/SDM/PRO/001 — POA Operations Major Incident
Procedure” and “SVM/SDM/PRO/0875 - Application Support Strategy”.
Any party may raise an Incident:
+ If the Incident meets the criteria of a Live Defect, then it must be progressed to Peak and be
assigned the ##LiveAffecting Defect tag.
+ If the Incident meets the criteria of a HDR Defect, then it must be progressed to Peak and be
additionally assigned the HDR-Fin or HDR-Exp tag.
The key fields within the Incident then allow the tracking of the progress of the Live Defect to its
resolution (or qualification out) and enable all reporting. Refer to Appendix A — Key Fields in Peak.
2.3 Live Defect stages
As a Live Defect progresses through the process and its fields in Peak are amended as required, the Live
Defect will pass through these stages:
IDX32>EbEbIDID Ie
“TYSNow Incident No actionneeded «Defect Peak -Solutionroview «Target at / *Code/build = Packagefixes—-Confirm it works -DeploytoLive
“investigation Peak -Raise Change -Solutionbeing -«andapproval ©—ProposeFora_—_solution
siniiate Fix identified sTaketoceirif Release
needed
1. INVESTIGATING - A Live Defect will start out as a potential Live Defect until sufficient
investigation has taken place.
2. SOLUTIONING - If a fault is confirmed then this will progress to be a confirmed Live Defect (if it
is not a fault then the potential Live Defect will be closed).
3. PROPOSED FOR - Once a solution is identified for a confirmed Live Defect it will need to go
through the POA processes before the fix is assigned to an appropriate release. It will initially be
proposed for inclusion in a future release.
4. TARGETED AT - Once the release is confirmed, the Peak will be Targeted At that release.
Releases are then managed through to deployment to Live.
5. ACCEPTED DEFECT - Accepted Defect is a Defect that has been discussed by Fujitsu and POL
and it has been jointly agreed that no further actions will be performed i.e. accepted as not being
fixed.
2.4 Managing the Defect
The following is a guide to managing Live Defects:
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 8 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Incident — Peak — Defect — HDR — CBIF
Potential Defect Investigation Peak Confirmed Defect
{investigation}
investigation Fujitsu Internal Fujitsu Internal
jitsu Reports
HOR/CBIF or
Continuous improvement
+ itis Live Defect then Bonded
add the
LiveatectingDefect Cl Pa + Allshould be Call Type “#*
+ ifitisa HOR Incident > + Allshould have the Collection
then add relevant Cl ‘ttLvedectingDetect
+ Updates auto replicate + THOR then relevant Collection should be
+ POL rely on ServiceNow added
POL notification
needed I
+ Updates do not auto replicate
*+ Updates are system driven by reports
1. Uve Defects with the HOR Collection —
forthe HOR meeting
CCBIF qualifying Peaks for the HOR
meeting
Live Defects excluding the HOR
Collection - reported (T3C) under
Continuous Improvement
Deferred Defect Peaks ~ for
= information and tracking
« All Live Defects must have a clear next action stated that can be tracked.
e All Live Defects must be always owned by a team whose manager will ensure actions are being
taken (this can be a different team throughout the lifetime of the Live Defect).
e Live Defects that are not classified as HDR Defects are managed internally by Fujitsu using
Peak. Reports will be available for POL to show overall progress.
« When a HDR Defect is being investigated there will be a TfSNow Incident open and bonded.
POL will track status by referring to their ServiceNow Incident. All progress on the investigation is
to be added to the TfSNow Incident so that it is visible to POL in their corresponding ServiceNow
Incident. It is POL's responsibility to keep its own internal HDR Defect records up to date.
e If Fujitsu completes its investigation and confirms there is no HDR Defect, then the investigation
Peak and Incident will be closed with no further actions required. It will then be excluded from
Live Defect counts in the future. The HDR-* Collection should remain, so it is known that it was
considered within the HDR Forum.
e When a HDR Defect is confirmed as a Fujitsu owned Live Defect, then a new defect Peak will be
created that summarises the fault and the required fix and carries all the required key field data
items. The defect Peak reference will be added to the investigation Peak which will then replicate
to the TfSNow Incident. The investigation Peak will be closed along with the TfSNow Incident.
Fujitsu will then manage the progress of the Live Defect in Peak and will provide status update
reports from Peak that will be shared with POL for POL to use as part of the weekly HDR Forum.
e Peaks that have been tested successfully and are still to be deployed must not be closed and
must be routed to the Peak stack RM-x and assigned to “Release to Live” so it is clear that the
Live Defect is still present in the system but that its fix has been tested and is awaiting release.
e Several Response Category field values are considered No Fault Found. See Appendix C — No
Fault Found Response Categories in Peak and “SVM/SDM/PRO/0875 - Application Support
Strategy’.
e If adecision is made that progressing a Live Defect is not the best option (for example the
feature is being migrated and any fix would serve little purpose) then we should act as follows:
o If there is a Live Defect then Fujitsu should assume an obligation to fix it.
o If Fujitsu does not believe a fix is the best option, then it must get permission not to
create and deploy a fix.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 9 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
o Such permission can be from POL (ideally and especially if it is a Live Defect that would
in any way affect how POL uses the solution) or from POA Delivery Executive (DE)
(where the only impacted entity is Fujitsu).
o The Response Category on the Live Defect Peak must be changed to “Accepted Live
Defect” (so it is treated as a no action Peak).
o “Accepted Live Defects” will appear on all POA and POL Live Defect reports.
2.5 Reporting
Fujitsu provides a variety of reports to different audiences:
+ All HDR Defects to POL — at the POL chaired weekly HDR Forum meeting.
+ All Live Defects to POL fortnightly.
+ All Live Defects (comprising all HDR Defects) — for the monthly POA Business Review.
+ All Live Defects to the POA stack owners and POA management teams monthly.
Refer to SVM/SDM/PRO/4695 — Horizon Defect Management Reporting for additional details on how the
reports mentioned are created.
2.6 Data checking
The tagging of Live Defect and HDR Defect Peaks relies on many manual actions which can be
susceptible to human error or interpretation. To mitigate this, there are a series of overlapping and inter-
connecting processes performed by separate people and teams that significantly reduce the potential for
omission or mistakes to go uncorrected. This provides high reliability to the LDM tagging and resulting
processes.
« Peak owners are required to keep the Peaks updated and the key fields up to date.
e Checks are made by stack owners as part of their Incident Management actions (see Appendix B
— Checklists for TfSNow & Peak Stack owners).
e The chairs of key meetings such as the Business Impact Forum (BIF) and the Peak Targeting
Forum (PTF) check field values.
e The Major Account Controller (MAC) team perform periodic checks following a local work
instruction to ensure the Peak key fields are being constantly checked for data inconsistencies,
challenging the Peak owners to make required corrections (e.g. a fix has been deployed ina
release in the past, but the Live Defect Peak has not yet been closed).
e The regular reporting extracts also serve to ensure the key fields and tagging is regularly
checked. Any inconsistencies are challenged and updated.
Combining the extensive level of awareness within the support teams with the many additional
overlapping processes means that the identification of Live Defects and HDR Defects is highly reliable.
2.7 Key Meetings
The key meetings that support the LDM process are summarised below. The outcome of BIF/CBIF/PTF
meetings is held in concise notes in the relevant text boxes on the RELEASE MGT tab in Peak. This
enables easy refer backs without the need to source external content.
2.7.1 BIF - Fujitsu internal
e BIF is a Fujitsu internal meeting that is held every weekday (if required) to ensure prompt
discussion on Peaks ready for group review.
e When a Peak is ready for BIF to consider, the BIF Action flag must be set on the relevant Peak,
so itis identifiable.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 10 0f 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e All Peaks with the BIF Action flag set will be reviewed at BIF:
co This will include all defects Peaks with the ##LiveAffectingDefect tag.
o It will also include other Peaks that may relate to other topics such as environments or
Peaks that the Developers wish to discuss at the forum.
e As Peaks are assigned the BIF Action, the support specialist will be presented with a prompt to
ensure they confirm the key data items are correctly set within the Peak. This will ensure that the
BIF meeting can focus on the solution for the Peak and not whether certain key fields on the
Peak are correct:
BIF Checlc list: PCO250902
‘Please confirm this Peak checklist as much as possible
tohhelp streamline the BIF process.
LLiveAfiecting Peak © FE
[HDR - Experience
[Defect Call Type #
‘Workaround available
Product Correct
Priority Corect
“Impact Complete
e Atthe BIF meeting itself, more Key Fields will be checked to ensure the accuracy of the Peak
system. For example, BIF will:
o Ensure Call Type is correct.
o Ensure Workaround field is up to date.
o Ensure Product Group field is up to date.
o Ensure Product field is up to date.
o Ensure Priority field is up to date.
o Ensure Impact field is up to date.
e If a Peak had previously been rejected - as more information was required - then it will have the
BIF Action flag set again when the Developer is ready to re-present their proposal
= The BIF Chair must check if there are conditions that would mean the Peak needs POL input and
hence must go to CBIF. The questions are on the RELEASE MGT tab under the BIF section (see
screenshot below as well as text extract):
‘IF Guations
win a separate nae planes
e The fix can be done in more than one way and POL would need to guide Fujitsu on
choosing the preferred option.
«The fix may change the functionality of the system and consequently POL will be
required to provide appropriate communication, and potentially training, to the
subpostmasters.
«The fix may need to be done in conjunction with changes performed by some of POL's
other suppliers and POL will need to manage and synchronise that activity.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 11 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
«The fix may need to be done concurrently with a separate future planned change, due to
the two fixes being logically related, and POL would need to confirm their willingness to
accept any potential delays in deploying the fix.
e The fix may relate to active discussions between Fujitsu and POL on a specific and
separate topic and hence should be discussed within that context (Fujitsu management
discretion).
e Fujitsu does not believe a fix is a sensible option and seeks POL's agreement to record
the circumstances in a KBA only.
© The BIF chair must record, in Peak on the RELEASE MGT tab, what decisions are made:
eo
itera Detagsore1 1
eee
1 Pejeteanee: Pam fect
ainmmONETTH ‘cpm 5O.0NT)
co The BIF date fields (Initial and Completed) will be completed during, or after, the BIF
meeting (not before or it will affect status reporting):
= Initial date - will hold the date of the first BIF meeting that the Peak was
presented at — this value should not change.
= Completed date - will hold the last BIF meeting the Peak was discussed at — this
value will change if the Peak is iteratively presented for review, and it will allow
reporting on what was reviewed at the last BIF meeting.
o The outcome of BIF discussions should be added to the BIF text box on the RELEASE
MGT tab. A concise note is all that is needed.
co If the Peak is approved or rejected at BIF, then the BIFApproved Collection must be
added (also for BIFRejected).
[Add Incident to Collection
[EiFApproved - Approved for fx by the Business Impact Forum [Team] T)] Add to Collection
o If the Peak is to go to CBIF this will be determined by the field values and the BIF chair
should not set the PTF Action flag.
co If the Peak does not need to go to CBIF then the PTF Action flag will be set if the Peak is
approved.
2.7.2. PTF — Fujitsu internal
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR _Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 12 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e PTF is a Fujitsu internal meeting that is held every weekday (if required) to ensure prompt
discussion on Peaks ready for group review. It is typically held at the same time as the BIF for
process efficiency.
e All Peaks with the PTF Action flag set will be reviewed at BIF:
o This will include all defect Peaks with the ##LiveAffectingDefect tag.
o It will also include other Peaks that may relate to other topics such as environments or
Peaks that the Developers wish to discuss at the forum.
e Ifa Peak needs to be re-presented at PTF then it will have the PTF Action flag set again.
e PTF must consider the proposal (as it does currently) and additionally be mindful that any that
carry a HDR Collection or that have been presented at CBIF must get additional scrutiny — and
potentially prioritisation — as progress will be reported to POL weekly.
* The PTF chair must record, in Peak on the RELEASE MGT tab, what decisions are made:
Py apeen — Destine vee
Pek Teng Fn
ela ape Fes
—— Tiere es Ru Nmpeed Fu ide
Ka Rece Sema on pop Dnens
a DaR COLI Copied am DONATI
or
o The PTF date fields (Initial and Completed) will need to be completed during, or after, the
PTF meeting (not before or it will affect status reporting):
= Initial date - will hold the date of the first PTF meeting the Peak was presented at
—this value should not change.
= Completed date - will hold the last PTF meeting the Peak was discussed at — this
value will change if the Peak is iteratively presented for review, and it will allow
reporting on what was reviewed at the last PTF meeting.
o The outcome of PTF discussions should be added to the PTF text box on the RELEASE
MGT tab. A concise note is all that is needed.
e The ideal outcome from PTF is that the Peak (whether a Live Defect or not) is Targeted At a
numbered release.
2.7.3. HDR (including CBIF) — joint Fujitsu and POL meeting
«The HDR Forum (formerly Horizon Known Error Review Forum (HKERF)). This is a critical
meeting where POL and Fujitsu review the progress of all open HDR Defects. It is a joint weekly
forum chaired by POL. A Terms of Reference is owned by Post Office and is also stored in
Dimensions as SVM/SDM/PRO/4317.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 13 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
2.7.4
Potential HDR Defects will be reported automatically to POL via the service management toolset
replication driven by Fujitsu updates to the TfSNow Incident. An Incident raised and bonded to
describe the potential fault condition being investigated.
Actual HDR Defects (including any deferred) will be shared with POL weekly by an extract report
from Peak that will be sent to POL in advance of the meeting showing the latest update.
If Fujitsu completes its investigation and confirms there is no HDR Defect, then the investigation
Peak and Incident will be closed with no further actions required. POL will be notified of the
reason on the HDR Report and at the weekly HDR Form meeting.
Fujitsu will provide its view of status — from its systems — and manage any difference of opinion
with POL.
The agreed target dataset for reporting a HDR Defect is as follows (as at the date of this report):
: aeact I = a
Trnpact Index 13552 Tas Ede
‘HORIZON
Document Oxmer:Fujites
Date of Issue: 2022-02-16 132
[POL Problem Reference
Fujitsu Reference
[Date frst logged at HDR (Gime F9)
Fujitsu Tale
POL Title
[Description
[Branch Financial pact or Experience Fujitsu HDR Fin HDR-Exp)
[Branch impact described
(Defext Coniemed (or sul under saveruiganca)
How found
[Wen found
[When dates back wo (when could w ave wanted happening)
[Branches afected
[Frequency of occurence
FRooteause
It deected monitored
{Workaround
[Workaround description
INewtacton
[Target Release Number
[Target Release date (latest evimate)
The Impact tab in Peak will automatically show this layout if a HDR-* Collection is added. The
content can also be readily extracted to HTML format for sharing or inserting into POL reports.
Fujitsu will provide weekly updates to POL at least one working day prior to the HDR Forum
meeting.
CBIF proposals are also discussed with POL at this forum.
CBIF (part of HDR) — joint Fujitsu and POL meeting
CBIF is a joint meeting with POL and is combined with the HDR Forum meeting.
o Items to be discussed at CBIF must have a “CBIF Proposal” that has been created in
advance using the agreed template (see below) and approval process, so it is clear that
this is what the decision needs to be made on (not additional dialogue during a meeting).
“CBIF Proposal” should be attached to the Peak and also be sent with the HDR weekly
report so that the meeting has the information in advance.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 14 of 29
oO
FUJITSU
POA LIVE DEFECT MANAGEMENT PROCEDURES
FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
FUJ00233141
FUJ00233141
Customer Business Impact Forum (CBIF) Proposal
Sipe ISS PaaS
<aiame> agra
“<<oescription ~ probably derived from the Peak but nt requiring
Pealo>
reader to have access tothe
<<Probably Derived from the impact fel inthe Peak >>
<<A8Cetc or just show one>>
-ccwvhat do Fults believe isthe best option >>
“<cwhat are the implications/considerations POL needs to understand when making its decision>>
e Peaks to be discussed at CBIF are determined by Peak data items so it is system driven. Fujitsu
may invite SMEs to the CBIF part of the HDR meeting if it would help with any explanations to
POL.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 15 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e The CBIF representative must record, in Peak on the RELEASE MGT tab, what decisions are
made:
sas atti ae Sains Devt 3ac731 86
ie apes FoF
Pa Tag in TF
LSS etter seared
al Sago Fos 2)
—_ Tir eave ar en Fe amped Fe eh
ra DORE) pina Da DONT)
par i
ome i
o The CBIF date fields (Initial and Completed) will need to be completed.
= Initial date - will hold the date of the first CBIF meeting the Peak was presented
at — this value should not change.
= Completed date - will hold the last CBIF meeting the Peak was discussed at —
this value will change if the Peak is iteratively presented for review, and it will
allow reporting on what was reviewed at the last CBIF meeting.
o The outcome of CBIF discussions should be added to the CBIF text box on the
RELEASE MGT tab. A concise note is all that is needed.
co If the Peak needs to go back to the Developer, then it should be assigned to the
Developer team.
o If the Peak can proceed as discussed at CBIF, then the PTF Action flag will be set.
co If the Peak is to be discussed next time (as POL wish to seek wider feedback within their
own organisation) then the PTF Action flag will not be set as this will cause the Peak to
reappear on the weekly PTF report.
o CBIF rejections must get a POL reference which must be added to the Peak and to any
applicable KBAs so it is a matter of record that this was a POL decision. The Peak is
then closed with Response Category “63 -- Final -- Programme approved - No fix
required”.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 16 of 29
FUJ00233141
FUJ00233141
POA LIVE DEFECT MANAGEMENT PROCEDURES -
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
A Appendix — Key Fields in Peak
There are many fields in Peak that help support users to determine status and record information. Many
of those are mandatory or system generated. These remain important and are described in “CS/MAN/011
— Peak User Guide”.
The fields identified below are important to the LDM process and will need to be completed at various
stages of the progress of the Live Defect. The screenshots and description may change over time so this
appendix should be seen as illustrative rather than a definitive and maintained reference.
To help remind Peak users of the importance of Live Defect and HDR Defect Peak updates, a banner
appears on the Peak login screen:
\Defect Management Changes
nave been some changes tothe Defect Management process to enable more accurate reporting. lense consider the following when reviewing a potential defect Peake
+ Bisa Live Defect Ifo add the WLiveAtetingDefert Colleton
the Cal (Change to L— Live Incident or #— Defect Identified as applicable
luct Group Sele core:t? Multipe products can beaded if required
4 the Status Response Catego (Does it select the cusent activity a the defect process
+ Where ponible eure your progress updates are understandable to noe-echical user
pei
The following are the key fields needed for Live Defect Management:
+ Call Type — must be set to “#” Defect Identified when a Live Defect is confirmed. Prior to this,
Live Defects should be Call Type “L” Live Incident but can have other Call Types provided
they carry the ##LiveAffectingDefect Collection. The Collection descriptive text is “Fault that
is present on the Live system that is inconsistent with the agreed design and/or service
specification” .
Peak In
a aay
{ Detans . 5 PRODUCTS. EVIDENCE T
Reference [PC0295241
[Release [Reported In -- HNG-X Rel. Ind.
‘all ‘O -- Operational (SSC) v
‘ontact =
‘A--Administrative use —___———
C-- Cloned call fpg/not yet defined/TBA] St
E ~ Enhancement Request
F —- Document Review/Design Walkthrough
ment
ISunmary: testing
‘all Type:L
call Priority:0
jTarget Release: HNG-
JRouted to: E0SC
M— Problem Management
O ~ Operational (SSC)
P ~ Product Incidents/Defects
=U) R= Release Notice Forum
pari pn ees 8 ~ System Testing Incidents/Defects
esting dev 1D I T ~ Technical query
[End of Response] IU— Security Testing Incidents/Defects
Response code to caI V— Vulnerability
hen rdentified(38)
evelopment Cost upda
[Start of Response]
est 1
[End of Response]
jespons:
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 17 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e Summary — must be written to be understandable by most readers. This will need more thought
when Peaks are raised.
e Impact — tab will display in one of 2 formats: a shorter form for non HDR Peaks; and a longer
more complete form to meet the HDR reporting dataset requirements. For other Peaks it should
ideally also be updated but this is not mandatory.
o Shorter form:
Tape inaerNew Tagitte aknown Daten
PDessaprion [* short non-technical description of the Problee]
[Branch uapact described
How found
[When found EE
[hens dates bck to (when could have wared
D
happenin
[Branches afered
Frequency of occurence
[Roceeause
ik detected monitored
Workaround [2
[Workaround decrpton Wa
Fx equied
Kans opie
o Longer, HDR dataset form:
‘act - cs lag
Tepes ier Taste
‘DEFECT REVIEW FORUM: DEFECT SUNRIARY
Document Chae Furs Control -Conmercal-n-Confience
Docunert Owner Fave
‘Dat of eae
+ ie ged OR TE)
Tie
——
enc Facil gan a epics aa HOR Fa RES)
=
es Cnt ra ami)
Fics nad
Ties oad
Then dates Bako (When coud Wave aed 7
[Branches atiectes
reqoency of occurrence
FRosccamne
nit detected monitored
[Tiger Release Nomber
[Tze Release date (atv mat)
co Byclicking on the Export icon on the top right, a sharable version of the Impact content is
presented in HTML format and can be easily saved.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 18 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
+ Collection ##LiveAffectingDefect (formerly ##LiveAffectingSoftwareF ault). This Collection must
be set when the Peak meets the criteria for a Live Defect at the earliest possible opportunity.
It is likely that Call Type “L” will frequently carry this ##tag but it will not always be the case
so needs selectively applying. The Collection descriptive text is “Fault that is present on the
Live system that is inconsistent with the agreed design and/or service specification”.
e Collections of “HDR-Fin” or “HDR-Exp” for HDR Defects.
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin should be chosen
[Ada Incident to Collection
[ HDR-Exp — Horizon Defect Review - SPM Experience [Public] y) I Add to Collection
So wo
HDR-Exp ~- Horizon Defect Review - SPM Experience [Public]
HDR-Fin ~ Horizon Defect Review - Financial Impact [Public]
* Collections — when a Collection is added or removed, the history is held on the RELEASE MGT
tab in the Release Management Forum (RMF) area as shown below:
Release Management Forum (RMF)
@3/11/2021 Added to Collection ##LivesffectingDefect by John Simpkins.
03/11/2021 Collection ##LiveaffectingDefect removed by John Simpkins.
3/11/2021 Added to Collection HOR-Exp by John Simpkins.
(3/11/2021 Collection HOR-Exp removed by John Simpkins.
93/11/2021 Added to Collection HOR-Fin by John Simpkins.
03/11/2021 Collection HOR-Fin removed by John Simpkins.I
e Priority —must be constantly validated so it is accurate as this will affect reporting and decision
making.
e POL Problem reference — using the prefix “POLPRB-" so it is obvious and also searchable.
o POL Problem Reference is a Reference field and the following screenshots shows how
to add the field:
‘Peak Incident Management Spsems -PC029S241
HEHE
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 19 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e Fujitsu Problem reference — using the prefix “FJPRB-" so it is obvious and also searchable.
o Fujitsu Problem Reference is a Reference field and the following screenshots shows how
to add the field:
Peak tncident Management System - PC029S241
=a
ror Prous a
e Workaround - to state “Yes/No” state if a workaround has been implemented. If the field is
blank or contains “No”, then no workaround has been identified. If it is “Yes”, then an accepted
workaround is in place.
o Workaround is a Reference field, and the following 2 screenshots show how to add the
field and set its value:
Yeak Incident Management System - 200295241
(ieee [Caner aie
—— eo
Pallcernce Poneman
al reaence OTT
[Eeirence Vaio)
atone]
Fagan Fema] =>)
Peak Incident Management System - PCOZ
vereERcS
[Caren ia
al efarace coxounso
—— pemeno0
al vfarece ecconino
[Add Reference Type Valet)
(Add Rictovence(s) I
Ves vT
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 20 of 29
FUJ00233141
FUJ00233141
POA LIVE DEFECT MANAGEMENT PROCEDURES
FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
FUITSU
e External Dependency - to allow key dependencies to be captured as these typically cause
extended delays e.g. with POL turnaround (perhaps when related to their EUC provider), or with
Fujitsu sub-contracted parties such as Worldline.
o External Dependency is a Reference field and the following screenshot shows how to
add the field and set its value:
[aa Reference Tipe
[Reference Value)
‘remal Dependency
Add Referoncate)
Expected FomailayI Fujtsu son POA
ingenco
Po.
POL EUC Proser
POL Network Prove
Vendor
Ota
e Internal Dependency — to allow key dependencies to be captured as these typically cause
extended delays e.g. dependent on another release.
co Internal Dependency is a Reference field, and the following screenshot shows how to
add the field and set its value:
[ai Reference Tipe
‘Dasral Dependency
[Reference Value)
Ad Retorencets)
Expected Fomail@)Irytss_von POA
ingenco
POL
POL EUC Proviser
OL Neto Prove
Vendor
Other
RELEASE MGT tab - Initial and Completed dates and text box - We need to know the stage
we are at in the fixing process, the date it initially entered the stage, and when the stage was
completed and the notes from the meetings at which it was discussed.
Assigned Team — must show which team is currently responsible for taking the next action or
ensuring action is taken.
Product Group and Product - We need to know the part of the system that the Live Defect
relates to for reporting and quality purposes.
Root Cause - we need to know what type of fix was needed, which when matched to the part of
the system affected, gives us further quality data.
Response Category — specific values have been identified to enable clarity and to spot
exclusions:
o “63 -- Final -- Programme approved - No fix required” — for Peaks rejected at CBIF.
o “66 -- Final -- Enhancement Request” — for Peaks tagged with the HDR Collection that
were subsequently qualified as not being HDR Defects but enhancement requests.
“95 -- Final — Advice after Investigation” — for Peaks tagged with the HDR Collection that
were subsequently qualified as not being HDR Defects.
co The value “30 -- Pending -- TL confirmed” will cease to be used.
A more complete list of No Fault Found Response Categories can be found in Appendix C -
No Fault Found Response Category values in Peak.
e Areminder will pop up on certain changes of Peak status to remind support staff to consider the
key fields:
o Events triggering presentation of the pop-up:
© Copyright Fujitsu 2023
The Peak Routing is changed.
FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 21 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
= The Call Type is changed.
= The Response Category is changed.
= The ##LiveAffectingDefect Collection is added.
= The HDR-Fin or HDR-Exp Collections are added.
co Pop-up wording:
= Is this a Live Defect? — if so, add the ##LiveAffectingDefect Collection.
= — Is the Call Type correct? — Live Incident or Defect Identified (if applicable)
= Does/could this affect branch operations? — if so, add the HDR-Fin or HDR-
Exp Collection.
= Is there a Workaround? - if so, add the Workaround References field and set it
to Yes.
= Does your last update read well to users not involved in the Peak progress?
= Have you added a helpful Impact update?
= — Is the Priority correct?
= Are the Product & Product Group field values correct?
* Is the Status (Response Category) correct?
e Cloning Peaks
co There are important occasions when it is necessary to clone Peaks. This should be done
following the process explained in Appendix D — Cloning Peaks.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 22 of 29
FUJITSU
POA LIVE DEFECT MANAGEMENT PROCEDURES
FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
FUJ00233141
FUJ00233141
B- Appendix — Checklists for TfSNow & Peak Stack
owners
This checklist is maintained separate to this document and is subject to change. The version below is for
illustrative purposes only.
A checklist exists to help owners of TfSNow Resolver Groups and Peak stacks to keep the Incidents and
Peaks in a manner consistent with the Live Defect Management processes.
For Peak:
For TfSNow:
There’s a Peak in my stack.
eth Peak tan tothe correct pen (oto ick si on POA
tin ptanlUve Detec wht neds dogo progres oDaect
\dortadorto quay as MOT ve Dec?
trees tot creda then oes HR ny bonded to
tion!
2 ichareHOR- calecon ist tang ested ih rity
‘eau of Pty ele?
es eft Weed, and has been arated PF when wl wok
Irth espana Canepa coeet?
When rl at updated andi that an acceptabl mesa?
Doth atest upates ead wll andmate sense? aot change ther and
)nexpcd oath et actin?
Peat the fon esanse Citgo th
ended Cogs necery
‘orn geod
‘bere tg cloned Mae ret uated
Peaks acer closed wth any othe lowing Response Categories we
20 lc other yr
There’s an Incident in my TfSNow Assignment Group,
‘Should this be in my Asignment Group? ot, then route 0 the
Fgh Asgnment Group
lathe Incident signed to the comec parton (tof sick til on
POA) not, then easignit
1. tthe Summary field a lear desertion that others wll
understand?
Ifthe incidents not bonded 0 POL ServceNou, does it have the
right Open category?
‘sit potential Live Detect? 0, athe LinedectingDafect C1
fits potential Live Defect, what needs ding to progresit toa
confirmed defect orto qualify as NOT a ive Defect?
Should POL be aware? if30, the incident will eet be logged by
[MAC with the require specifi Categories scan be bonded to
POL Serves Now t0 POL can be kept upsated th progress
1 ts or could tbe, branch impacting is, ensure MAC ae asked
to 2dd the HOR-Fin or HOR Exo Ch
\fithass HOR cist bein
of Prioty eld value?
Withasa HOR Cis recent entry the “Additional comments
(Customer visibly fied up to date ad wel worded so tht POL
\sthe State fld corres st?
‘2 workaround avaible eis wil show in the Peak appesble
sete Workaround Reference wile et 0 Yee)? 30, make sre
‘tthe “Aston comments (Customer ble) elderly
states this ~ especialy if this Incidents bonded t POL Serviceton
Has anthing charged tat would mean the tied FecingDefet
CorHR.* is are no longer correct and should be removed? ifs,
remove them
2g litinked 08 TSNow Change?
When waits updated ands that on aecepabeinespan?
tae the Ince to nave al record avaable?
How longi tsnc the nent was ised ~ aris that acceptable
co does steven ned doing?
Dotelaesupdtes rae vel and make sense? Wo, change
‘hem and eoaehthe eestor
Ifthe Inder bonded POL SesceNou, does the atest update
tothe “Adio! comments (Customer be ld eke ear
{0 POL what de stats? toda update tat es
Isieder who peas expected take the next atin?
Iryouare wating tor someon eterna ta your team 0 ake aeion
catenge ther ork progress,
Is the nent Suspended a further usu actions needed
$0, ander 10 working days have lapsed the cident ol be
one
Ire inient being closed, ensure thas the right sre code
ted has the corect nian dataset eed fos pe cal work
inatractoneI
Ioterasterral
Incidents recent sed shouldbe checked: they were led
with no action required by Fujitsu, does the Incident ear state
tha? if they were close following action taken by Fujitsu, does the
Incident cleat state that?
© Copyright Fujitsu 2023
FUJITSU RESTRICTED (COMMERCIAL IN Ref:
CONFIDENCE)
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS.
Version: 1.0
Page No: 23 of 29
17-Oct-2023
SVM/SDM/PRO/4313
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
C Appendix — No Fault Found Response Categories
in Peak
Peaks with the following Response Categories are deemed to be No Fault Found as no action was
required to remedy the issue raised. In some cases, this is because the fault is within an area of the
system that is managed using TfSNow and hence Peak is not the source of the Live Defect information.
In other cases, this is because the fault is already being investigated under another Peak.
Response Category — 68 -- Final - Administrative Response
Response Category — 95 — Final -- Advice after Investigation
Response Category — 94 Final -- Advice and guidance given
Response Category ~ 70 -- Final -- Avoidance Action Supplied
Response Category — 200 - Final -- Call withdrawn by user
Response Category — 120 — Final -- Cloned to create Defect Peak
Response Category — 72 -— Final -- Duplicate Call
Response Category — 58 -- Final -- Documentation Fix Available to Call Logger
Response Category — 66 -- Final - Enhancement Request
Response Category — 96 -- Final -- Insufficient evidence
Response Category — 62 -- Final — No fault in product
Response Category — 63 -- Final -- Programme Approved — No Fix Required
Response Category — 64 -- Final - Published Known Error
Response Category — 100 — Final -- Route call to TfS
Response Category — 97 -- Final -- Unspecified insufficient evidence
Response Category - 98 — Final ~ User error
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. PageNo: 24 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
D Appendix — Cloning Peaks
Cloning processes and rules need to be applied consistently:
e Cloning carries forward all Collections, References and Key Fields and it must show cloned from
and cloned to support chain of events tracking.
e Cloning should be for specific purposes and the reason will appear as a prompt when cloning is
initiated:
o Assignment to GDC (so we can redact/obfuscate)
Note: Since April 2020 UK Bridge do not clone Peaks but instead they obfuscate the
original so it can be widely shared and updated whilst maintaining any links to TfSNow
Incidents.
co Splitting into multiple threads linked to a single origin (e.g. Data Centre & Counter,
phased fix — urgent perhaps by script/refdata and follow-on for code).
o Disassociating from the TfSNow incident (e.g. documentation, follow-on to an initial
response to an Incident).
o Creating the defect Peak to progress the Live Defect to resolution.
o Creating Test Only Peaks where the test in a particular environment can't mirror the
entirety of the issue described e.g. 3rd party connections are not available. This is rare.
Testing is then done on the clone in that environment. The master defect Peak is still
open as it may be used for the full testing in LST. The Test Only Peak will be closed once
testing is completed successfully.
Note: if a Peak has been assigned to a Baseline, then cloning should be done with
caution and include consultation with the Baseline owner in advance
« When the [Clone] button is clicked, the following menu is displayed:
Select Clone Reason
(Create a Defect Peak
‘Spit into multiple streams
Disassociate from TisNow ticket
Test rig reasons
Other
Enter new clone Summary:
Clone test 2 - Testing Peak development
e The user selects from the list (“Create a Defect Peak” is the default option), amends the
Summary to give the clone a different and helpful title, and clicks confirm. The reason is captured
in the clone Peak:
Date:11-Aug-2021 09:00:38 User: John Simpkins.
CALL Pco25e898 opened
lbetails entered are:-
\Summary:test mb problem
icall Type:
call Priority:D
Target Release:HNG-x 12.11
Routed to:EDSC - John Simpkins
Date:41-Aug-2021 09:00:38 User:John Simy
Clone Reason: Create a Defect Peak
Date:14-Dec-2015 15:52:55 User:_Customer Call_
ICALL pco2aaces opened
Details entered are:~
jSumary:test mb problem
e If the Defect reason is selected, the clone will be created with Call Type ‘#'.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 25 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
E Appendix — Deploying Fixes via Release
Management
Live Defects, once assigned to a release at BIF/PTF, then follow the POA Release Management
processes. The Release Management Strategy is defined in SVM/SDM/PRO/1520. The following also
needs consideration:
e Release Notes must list all Peaks that are fixed and being deployed. The extract/report must also
show the POLPRB- reference for HDR Defects and the Fujitsu Problem references if they have
been tagged to be tracked by the Problem manager(s). This is achieved by clicking the button to
the right of the listed Peaks in the Release Note which creates an Excel spreadsheet that can
attached to the TfSNow Change ticket (format like below):
(Cat Rates my [POL Problem RefFyjin Problem Ref
7C0205314-LST20.96: Proper messages hs to dspaly atead of Aen eveus in DCM_LREC-DCM_CREATE LREC C&D)
C029S403 LST: 2094: Too many D records in LREC fle
FC020S7I1_ PBS Pot INC8349716 Amex bs not etd s expected when reconcine DRS? reports
C0295725 PBS: INC8354763 (TFSNow) :INCO386718 Lbyds £300 withraval [MCSUK-16376]
« Release Notes will not list:
othe Peaks that are being deferred (as they are not fixed yet).
o anyclone Peaks raised by Test for Test Only actions (as these are not additional Live
Defects but are just a tracking mechanism for the Test team).
e The action of deploying the release should set the applicable Peak Status to “F” and alert the
originator that the fix is deployed and ready for them to confirm and close the Peak.
e If arelease has gone Live, then any urgent new Live Defect Peaks must NOT be Targeted At
already deployed releases. A new hotfix release reference should be generated.
e If ahotfix is needed, Release Management will create the hotfix release in Peak with its own set
of dates, so that it can be properly tracked.
e Release Management will maintain the Target Release date table:
co Allpast releases must state the actual release date for deployment (if phased, this
should be the Pilot release date when at least 1 live branch saw new code installed).
o All future releases must show the latest anticipated release date for deployment —
irrespective of who will be leading the deployment.
co The release date should be the first time that the deployment was made to any live
environment (this is currently always Model Office). The date will therefore show the first
time the fix was deployed to a live counter/branch even though a phased rollout may
mean other counters/branches did not receive the fix until a later agreed date.
co The Target Release screen should be used to make universal changes to Peaks when
release information changes — especially the Planned Dates for the whole release. The
dates can be changed and then the “Reset Date” button is used to apply the new date to
all Peaks Targeted At the updated release (see below):
Peak Incident Management System
am
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 1.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 26 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Peak Incident Manageme
Sasa Release PNG 1S >
Sear smite
co These date changes then propagate to the RELEASE MGT tab for each Peak and
update the dates shown below enabling the progress of each Peak to be tracked:
Planned Dates (DD/MMUYYYY) ‘Actual Dates (DDMMYYYY)
Out Development I
Out iteration ]
toto LST
Ow LST 1
‘10 Production I ae I
o Hotfix releases must also be included in the date table.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version! 1.0
UNCONTROLLED WHEN PRINTED OR: Date: 17-Oct-2023
STORED OUTSIDE DIMENSIONS. Page No: 27 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
F Appendix — Deploying Fixes outside of Release
Management
If a Peak is being fixed outside of a release — e.g. by operational change by us, or by operational change
to relate to a Worldline deployment then we must update the Peak to Response Category ‘69 — Final —
Network/Operational change complete’.
e If the Peak is Call Type “# -- Defect Identified” then the Peak will check for the existence of the
following References:
= TfSNow with a value starting ‘CHG’.
= Operational Change Date.
e If both are not found, display the following error message:
ss¢2.fs.fujitsu.com says
For a live defect you must add a reference for the "TISNow’ Change and
the ‘Operation Change Date’ before selecting this Final response.
e The support user is expected to add the TfSNow change reference and the expected deployment
date to the Peak.
e If the Peak is not already Targeted At a release, setting this Response Category will now set it as
Targeted At and set the Target Release Type to ‘TFSNOW CHG’.
e If no release record exists, one is created, and the Planned & Actual dates completed. If a
release record already exists, it is updated with the Operational Change Date.
e The Impact page (for non-HDR Defect Peaks) has been updated for the Target Release date
(estimate) to be the Operational Change Date for a TFSNOW CHG release. It did not make
sense for HDR defects (as these do not have the Operational Change Date field).
« An FAQ has been added to Peak too: https://ssc.fs.fujitsu.com/Peak/PeakFAQ jsp#Q73 .
geen ror when aling a eponse cle
For live defect Peak (Call pe ~ Defect Leni), if this into be closed ctside a relate using an Operational Change you mut ensre hat the following References ae aided tthe Peak:
sonal Change References:
+ TESNow The Change reference (arts with CHG)
1 Operational Change Date - The dae tut he change was applied production DDAMEYYYY)
Withou these references in place when you ty to ad» Final Reon 69 . Neto Operational change compete you wil get the flloming ect
f
e Both of the TFSNow and Operational Change Date fields are added to the extract spreadsheet
for your and MAC reference.
What this means:
e If Peaks are to go live outside of a release, we must use the ‘69 — Final — Network/Operational
change complete’ Response Category and complete the 2 new fields when warned they are
needed.
e If the TFSNow and Operational Change Dates are set, and maintained, by the support user then
it will see the normal reporting fields auto updated.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIALIN Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS. PageNo: 28 of 29
FUJ00233141
FUJ00233141
oO POA LIVE DEFECT MANAGEMENT PROCEDURES. .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e That should mean that they will not be caught by the MAC WI so as people start to use it, the
chasers from MAC will diminish.
e Reviews and reports on Peaks is consistent with those being deployed under a release.
« When a Peak that is ##LiveAffectingDefect is being assigned to another person, there is a
prompt that appears:
ssc.fs.fujitsu.com says
I cere tis r-assgnmentis made please conf that as manyof the
1 Impact Tab fields as you can complete have been updated. This will help
] us ensure the impact Tab contains an ever improving level of content
Y accuracy.
Cancel
If they click “Ok” then the re-assignment continues as normal. If they click “Cancel” then the re-
assignment is stopped whilst they go make further changes.
e Deferred Peaks (that do not relate to test environment findings) become Live Defects. When a
Peak is deferred, the Fujitsu party obtaining the agreement must ensure the
##LiveAffectingDefect Collection is set where applicable and any applicable HDR-Fin or HDR-
EXP Collection.
© Copyright Fujitsu 2023 FUJITSU RESTRICTED (COMMERCIAL IN _ Ref: SVM/SDM/PRO/4313
CONFIDENCE) Version: 4.0
UNCONTROLLED WHEN PRINTED OR —_ Date 17-Oct-2023
STORED OUTSIDE DIMENSIONS PageNo: 29 of 29