POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Changes in v1.2
1. Changed the word ‘ticket’ to a correct defined term where unclear
2. Updated the CBIF selection criteria to include BIF explicitly tagged Peaks and moved the
content to Appendix E as a set of work instructions
3. Added references to using the BIFApproved and BIFRejected Collections
4. Applied emphasis that defect Peaks can only be closed when the fix is released to live
5. Updated Appendix A to add steps to challenge “Re-target” and force to PTF
6. Inserted Appendix B to add anomaly checks for TISNow
7. Renumbered Appendix B to Appendix C and updated it to use Live Defect and correct some
grammar errors
8. Response Category value “30 -- Pending -- TL confirmed’ will cease to be used
9. Target Release — the values of "Requested For" and “Released at’ will cease to be used
10. Removed references to Simon Wilson as the team work for Steve Evans
11. Watermark changed to “POA INTERNAL”
12. Consolidated Peak document update list action into Live Defect Section (moved Root Cause
list to this action)
13. Improved wording to clarify that a Live Defect is one that is present on the LIVE system and
something likely to need a fix (it can also be present on a test system but ifit is not present on
the live system then it is not a Live Defect)
14. Added definition for KBA
15. Updated screenshots to be more specific on the screen item they applied to
16. Updated the descriptive text for the ##LiveAffectingDefect Collection in Peak
17. Removed Root Cause values as reasons to treat as No Fault Found as too inconsistent at
this time
18. Adding cloning instruction screenshots
19. Added new Response Category “120 -- Final -- Cloned to create Defect Peak” to be used
when cloning an investigation Peak to create a defect Peak
20. Clarified technique for Peaks declared as on “monitor”
21. Added reference to Release Peaks and Peaks that have been Baselined
22. Clarified that only one HDR-* Cl or Collection should be set and if both could apply then use
HOR-Fin
23. Clarified that when Release Management set the Planned Out Live date they use the date the
first time the fix was deployed to the live environment (irrespective of rollout schedules that
may decide on the rollout to the whole live environment)
24. Added recommendation that Peaks that are resolved but not ready to be closed as the
resolution action is to be ‘monitored’ can remain in a non-closed state but must have a
Forecast Date added to the Response so that this warns the support specialist and team
leader that the review date has arrived and the Peak should be reviewed for closure
25. Added statement that Release Management processes will apply to 3" party deployments
that are within the Fujitsu scope of responsibilities. For example, Ingenico fixes will be
deployed under releases and Peaks will be Targeted At, Proposed for, and Reported In
release numbers identified for Ingenico fixes — currently 90.xx
26. Corrected the incorrect references to RAM/RAB
27. Added new step that on a release, SSC will ensure relevant KBA updates are checked and
completed
28. Added new approach for progressing fixes through the release process faster — with
consideration for a hot-fix
29. Added a screenshot for the Release Management “Reset Dates” feature
30. Added screenshots to explain the difference between an intemal Fujitsu Progress update and
a replicated Response update
Page I 1
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
31. Enhanced the description of the HDR report generation process and moved to Appendix D as
a work instruction
32. Updated Actions, removing ones completed
Changes in v1.1
1. Split Streams 5-7 to a new document
2. Added What's New to provide a pseudo Executive Summary for new readers before they
delve into the detail
3. Added screenshots and diagrams to aid understanding
4, Removed requirement for Development (ManDays) to be entered on any Peak and also
removed Development (ManDays) as a criteria for submission to CBIF
5. Refined criteria to be reviewed at BIF to guide what is taken to CBIF
6. Added additional references for Response Category and Root Cause field values
7. Added additional clarification that deferred Peaks that still require investigation are assigned
Call Type “L” not “#”
8. Added guidelines for use of the “Additional comments (Gustomeh visible)" field in"TfSNow
9. Added criteria currently being used to derive content for CBIand HDR
10. Added Appendix A to show some data validation checks that certain teamsjare advised to
build in to and expand upon within their own loéal processes
11. Added Appendix B to show draft criteria forfot acting on defects'> the potential policy we will
write to remove any subjectivity from decisions to close defect Peaks or not open Peaks from
Jiras
12. Updated Actions
Page I 2
Version & Last updated: See file name
Document owner: Steve Browel
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Contents
What’s New? sss
New terms..uccussen
Investigation Peaks becoming Defect Peaks.
New fields in Peak...
New field values in Peak...
New field values in Peak......
Renewed importance for Peak fields...
TFSNow Incident needed for things POL should know..
New field values in TfSNow....
Renewed importance TfSNow fields.........
BUF oa.
CBIF ...
PTF a
HDR...
Introduction & Overview ...
The Goal. sossnssen
Purpose & Scope...
The Streams
Terminology — Overview.......
Stream 1 - Incident & Problem (links to Peak, Key Meetings & Live Defect Management)...
Managing Incidents.
Managing Problems
Action
‘System Changes...
New Ways of Working ..
Stream 2 — Use of Peak (3LS, 415 & Release).
‘System Changes.
New Ways of Working
Stream 3 - Live Defect Management ..
Page I3
ion & Last updated
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Live Defect Management - Live Defect Definition......
Live Defect Management - Goals...
Live Defect Management ~ Key Fields in Peak .....
Live Defect Management — Reporting...
Actions .osssn
System Changes
One-Time Actions.
New Ways of Working ..
Stream 4 —BIF, CBIF, PTF and HDR......
BIF...
CBIF ...
PTF...
HOR...
KB - Info only
Release Mgt tab — for BIF, CBIF and PTF
CBIF / HDR Diagram
Actions ..
‘System Changes
One-Time Actions.
New Ways of Working
Appendix A -Peak data anomaly checks.
Appendix C ~ draft criteria for closing defect Peaks with NO action
Appendix D - HDR Report Creation Work Instructions.....
Appendix E - CBIF Submission Extract Work Instructions.
Page I 4
Version & Last
fated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
What's New?
This document describes a number of changes to the Post Office Account ways of working to improve
the end-to-end process of Live Defect Management. It describes how the systems should be used
and how various teams will need to interact to ensure an effective end-to-end process is followed and
can be tracked and reported on. This section provides highlights but the entire document should be
read to gather awareness of all changes being implemented.
The 4 Streams were introduced in the June 2021 All Hands, with an update provided in the July 2021
All Hands update:
Streams 1-4
Stream 1 - Incident & Stream 3 - Live Defect
Problem Management
(TfSNow, ServiceNow) Cross-functional process
Horizon Defects Review (HDR)
Q
Stream 2 - Peak
(Incident, Defect)
Stream 4 - Key Meetings
(BIF, CBIF, HDR)
> Work OUR way
> System & Process Driven
> Management Reporting (Command & Control)
(Fajita Restcted = Internal Use Only ) 3
Our interactions needs to be system and process driven, not people and experience — and that will
create a clear audit trail too,
We need to limit the dependency on meeting-specific reports or embedded tables in minutes to show
progress on important matters
Page I5
Version & Last updated: See fle name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Transparency is key ~ to the fullest sensible extent, POL need to see everything — and they need to
be able to see it in their systems or from consistent reports from our systems. That way, POL are
informed and able to make decisions for us or with us.
New terms
‘Throughout this document, there are new terms and phrases that will need to be understood so we
increasingly use a common language. A diagram is provided below this list. The main ones are:
+ Live Defect — is a logged Incident that is present on the Live system that is within Fujitsu's
scope of obligations and is, or appears to be, inconsistent with the agreed design or service
specification. It is, therefore, a fault that is likely to need fixing
* HDR Defect — Live Defects that affect, or have the potential to affect, branch operations
(financial, experience, or end customer)
* Horizon Defect Review (HDR) - a weekly meeting with POL to review HDR Defects, POL
need to know the HDR Defects and their status. They share this with postmasters. This is a
very important meeting that sees Fujitsu and POL aligned on the HDR Defects
+ Investigation 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. The Peak Call Type should be “L" if this is a Live Defect
* Defect Peak — is a Peak that is not linked toa T'SNow Incident and that describes the
confirmed Live Defect that will be progressed through the SDLC (BIF, PTF, Dev, Test,
Release) to live deployment
+ Investigation Incident (TfSNow) — is an Incident that is being investigated where the cause
and required action are not yet confirmed. The Incident MUST be bonded if POL need to be
aware
+ Defect Incident (TfSNow) — is a TfSNow Incident that describes the confirmed Live Defect
that will be progressed by a Resolver Group that does not use Peak (e.g. Networks, Security,
Unix)
* Potential Live Defect (Peak) ~ is a Live Defect that we are still looking into. There will likely
be an investigation Peak open and probably a TISNow Investigation Incident too. The Peak
Call Type should be “L"
* Confirmed Live Defect (Peak) — is a Live Defect where the cause and required action to fix
are known, The investigation has concluded. A defect Peak will exist with Call Type “#”
+ Potential Live Defect (TfSNow) ~ is a Live Defect that we are still looking into that is logged
as a TfSNow Investigation Incident. The State will be “Acknowledged, Work in Progress, or
Researching”
* Confirmed Live Defect (TfSNow) — is a Live Defect where the cause and required action to
fix are known. The investigation has concluded. A TfSNow Defect Incident will exist with the
State field set to “Fix in Progress”
* _KBA-— Knowledge Base Article. The term KEL is no longer to be used
The diagram below shows the links between ServiceNow, TfSNow and Peak as welll as the
differences between Investigation Peaks and Defect Peaks:
Page I6
Version & Last updated: See file name
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Incident — Peak — Defect
Investigation Peak c Defect
Fujitsu Internal Fujitsu Internal
+ Updates auto reptete
phe (ante
ve vsttonI ame Pear OTe
(ate aera coy
Investigation Peaks becoming Defect Peaks
* Peaks can exist to investigate Incidents. These are known as Investigation Peaks
* Some Peaks are linked to TfSNow Incidents allowing for updates to flow between TISNow
and Peak (and via bonding to POL ServiceNow)
* When the investigation work has conluded on an Investigation Peak and a Live Defect has
been confirmed then one of the following actions need to be taken ~ most likely by
Development
© Ifthe Investigation Peak has been raised internally and is not linked to a TfSNow
Incident then its Call Type just needs changing to "# - Defect Identified
© If the Investigation Peak is linked to a TFSNow Incident then the Investigation Peak
must be cloned to create a new Defect Peak. The Defect Peak must be given the Call
Type “#” - Defect Identified. The Investigation Peak must have the Defect Peak
reference added to the last progress update. The Investigation Peak must then be
closed with an appropriate Response Category and Root Cause being added. This
Defect Peak reference will then flow back to the TFSNow Incident (via the
Investigation Peak progress update) and also to the POL ServiceNow Incident (if
applicable). The TfSNow Incident will then also be closed. Future tracking of progress
will then be done using Peak by monitoring the Defect Peak created until itis
resolved and released to live
Page I7
Version & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
= Tor Ted
Peak Inciden
DEALS
(GailRefeence JPCO299013
Release [iargeed At HNGX2132
[Call Type_ [L ~ Live Incidents ~
eee Aiiete e 7
lmpact CG at
= E—Estencement Reqest a
Bvar saLines
= Problem Management
(0 ~ Operational SSC)
I P— Product Incidents/Defecs
sR Release Notice Forum L
2 §~ System Testing IncdentsDefects
T= Technical query
X~ System Management Testing Incidents/Defects
'Y— Live (Non RefData) Data Updates 2
New fields in Peak
‘Some new fields have been added to Peak that must be used from this time:
© POL Problem reference — using the prefix "POLPRB-" so it is obvious and also searchable.
Most likely only required when the Peak is declared to be a HDR Defect (see screenshot later
in the document)
© Fujitsu Problem reference — using the prefix "FJPRB-" so it is obvious and also searchable
Most likely to be updated by the Fujitsu Problem Manager to ensure the link is clear (see
screenshot later in the document)
© Workaround — to state “Yes/No” state if an accepted workaround has been implemented. If
the field is blank or contains “No” then no workaround has been identified (see screenshot
later in the document)
© 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 (see screenshot later in
the document)
New field values in Peak
‘Some new values have been added to existing fields that must be used to improve Peak reporting
and tracking
© Gall Type — must be set to “#” Defect Identified when a Live Defect is confirmed. Prior to
Live Defects ought to be Call Type “L" Live Incident but can have other Call Types provided
they carry the ##LiveAffectingDefect Collection
New field values in Peak
‘Some new values have been added to existing fields that must be used to improve Peak reporting
and tracking:
Page I8
Version & Last updated: See fle name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
© Gall Type — must be set to “#" Defect Identified when a Live Defect is confirmed. Prior to this,
Live Defects ought to be Call Type “L’ Live Incident but can have other Call Types provided
they carry the ##LiveAffectingDefect Collection
Peak In
Feo
DETAILS
Reference 1295241
[Release [Reported In -- HNG-X Rel. Ind.
[Cait ‘0 — Operational (SSC 7
[Contact a
Am ative use ese]
[Impact C— Cloned call iginot yet defined’TBA] St
E ~ Enhancement Request —
F — Document Review/Design Walkthrough a
ste16-Jun-2021 10] G ~- GDC Testing Incidents/Defects
LL_PC0295241. oped I —Intemal Development Incidents/Defects
jails entered areI K — Primark
JSumary:testing I — Live Incidents
all Type: I N— Problem Management
ene aus-I O— Operational (SSC)
gph abe ogee P ~- Product Incidents/Defects
Bete 1é dan 2021 ie R ~ Release Notice Forum
[start of Response]
U-~ Security Testing Incidents/Defects
V Vulnerability Jen Identified(38)
w
a
velopment Cost updat
I[start of Response]
jest 1
I[end of Response]
iesponse code to call type L as Category 40
jun-2621 10:51:08 User: John Sinoki
Pending -- Incident Under Investigation
© Collection #LiveAtfectingDefect (formerly ##LiveAffectingSoftwareFault). This Collection
must be set when the Peak meets the criteria for a Live Defect at the earliest possible
‘opportunity. Itis 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”
[Aad Tncident to Collection
AL iveAfectingDefect ~ Fault thats present on the Live system thats inconssten [Pubic] [Addo Collection
© Collections of “HDR-Fin” or “HDR-Exp” for HDR Defects
[Rat naitent ta Coleco
[HORE<p— porzon Defect Review - SPM Enperioce [Pub] ©] Aidt Collection
=
HDR-Exp - Horton Dafect Raven - SPM Experience [Pubic]
HDR-Fin ~ Horizon Defect Reviw- Financial impact [Puble)
© Target Release - the values of “Requested For" and “Released at” will cease to be used
© Collection #LiveAffectingDefect (formerly ##LiveAffectingSoftwareFault). 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
Page I 9
Version & Last updated: See file name
Document owner: Steve Browel
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
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”
© 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
[Rd Tocident to Collection
[[HOR-Exp — Horizon Detect Review - SPM Experience Pubic] ~ [Ada Cotlecton
HDR-Exp ~ Hortzon Dafect Raven - SPM Experience [Puble) a
HDR-Fin ~ Hotizon Defect Review - Financial Impact [Puble)
+ Target Release — the values of “Requested For" and “Released at" will cease to be used
Renewed importance for Peak fields
A number of existing fields have become important and must be completed for all Peaks:
© Gall Type — must be set to “#” Defect Identified when a Live Defect is confirmed. Prior to this,
Live Defects ought to 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 a Live system that is inconsistent with the agreed design and/or service
specification”
Page I 10
Version & Last updated: See fle name
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Peak In
aaa
{peta ces I
[GaltReference _[PC0295241
[Reported In -- HNG-X Rel. Ind.
T ‘0 — Operational (SSC) v
igiot yet defined TBA] St
F ~- Document ReviewiDesign Walkthrough janis
G ~ GDC Testing Incidents/Defects
1 ~ intemal Development Incidents/Defects
T
jen Identified(38)
\s
un-2024 10,7 ~ Live (Non-RefData) Data Updates
velopment Cort UpuCRIE RATER
I[Start of Response]
any
fend of Response]
esponse’ cove to’call type L as Category 40 -- Pending -- Incident Under Investigation
46-Jun-2621 10:51:06 User: Joho Sinkins
© Summary ~ must be written so as to be understandable by most readers. This will need more
thought when Peaks are raised. Management should amend this during weekly clean-ups
(careful to preserve links where raised in another system)
© Impact — tab and free form field to articulate impact, status and next steps so it is easy to
understand for anyone. This will be maintained for HDR Peaks weekly. For other Peaks it can
be as needed
+ Business impact: [as used currently, mention how many branches are affected if
helpful]
+ Status update: [description of current status — succinct]
Next action; [next action to be taken and expected date for next update]
° Priority — which must be validated at all times so it is accurately shown as this will affect
reporting and decision making
© 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. Some Root Cause options will also lead
to Live Defects being qualified out and not reported on. We may exclude the following Root
Cause values from Live Defects so these need to be applied with caution:
+ "39 General — User Knowledge” ~ caused by lack of knowledge with the user
* "40 General — User” — caused by an action performed by the user which was
outside expected use
Page I 11
Version & Last updated: See fle name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
* ‘41 General — in Procedure” — caused by not following defined procedure
© Response Category ~ specific values have been identified to enable clarity and to spot
exclusions. Although there are many values for this field (which are explained in
SVM/SDM/PRO/0875), the following have important meanings — mostly is qualifying Live
Defects as not defects and hence allowing their exclusion from reporting:
+ °63 -- Final - Programme approved - No fix required” — for Peaks rejected at CBIF
+ °66 -- Final - Enhancement Request” ~ for Peaks tagged with the
#H#LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects but enhancement requests
+ °68 -- Final - Administrative Response” — for Peaks tagged with the
#LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects
‘* "95 -- Final — Advice after Investigation” — for Peaks tagged with the
#LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects
* "100 -- Final -- Route call to TFS" ~ for Peaks tagged with the ##LiveAffectingDefect
Collection that were subsequently qualified as not being Live Defects within Peak
* "120 -- Final -- Cloned to create Defect Peak” — for Peaks that WERE Investigation
Peaks and have been cloned to create a defect Peak
‘+ The value “30-- Pending - TL confirmed’ will cease to be used
© Target Release - the values of “Requested For" and “Released at" will cease to be used
TfSNow Incident needed for things POL should’ know
‘* Fujitsu must not raise and manage Incidents that POL should be aware of without having a
bonded TfSNow Incident raised
* Creating a Peak to investigate an Incident is not sufficient if the Incident is something POL
need to be aware of. In that scenario Fujitsu MAC need to be contacted to create a new and
bonded Incident in TfSNow. This will cause a new Peak to be raised into which the
investigation Peak contents must be moved and the investigation Peak closed. This ensures
a link exists from the new Peak back to the POL ServiceNow Incident
New field values in TfSNow.
* Configuration Item of — HDR-Fin, HDR-Exp and LiveAffectingDefect for Incidents and
Problems
© LiveAffectingDefect must be set when the TfSNow Incident meets the criteria for a
Live Defect at the earliest possible opportunity
© “HDR-Fin” or “HDR-Exp” for HDR Defects
= configeaton tome Seach I me =
1 wr0nas &
J Ne nane>=t0R
Q Shame a puting ESulleumbar Company
© mene eas ‘eax
Hen ros exe)
Renewed importance TfSNow fields
* State — will allow reporting on Potential Defects and Confirmed Defects
Page I 12
Version & Last
cument owner Steve Browe
See file name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
BIF
PTF
HDR
State Workin Progress v
© Acknowledged — Fujitsu is aware of the Incident but is not yet working on it
© Work In Progress/Researching — Fujitsu is investigating the issue described in the
Incident
o Fix In Progress — Fujitsu has confirmed that the Incident requires an action to fix it —
most likely linked to a Change ticket
© Suspend — action is complete by Fujitsu or is required from another entity
Additional comments (Customer visible) — this must provide a latest status view — at least
periodically and for POL bonded Incidents mainly — so it can be easily understood by any
reader. Peak uses a dedicated field for this and uses the following format:
© Business impact: [description of the business impact, succinct}
© Status update: [description of current status — succinct]
© Next action: [next action to be taken and expected date for next update]
BIF now needs to check certain fields have been updated as part of the review process. In
particular, it needs to set specific CBIF flags if POL involvement is needed
The forecast man days effort will no longer be a deciding factor for submission to CBIF
The date of the BIF meeting and the notes made at the meeting will be held in Peak
removing the need to create or review separate
Peaks to be taken to CBIF will be identifiable from criteria based on data fields on a Peak
Submissions to CBIF will use a new proposal form to ensure the meeting focusses on the
decision and not the articulation of the topic. The proposal will be stored as a file attachment
in the Peak
POL are expected to make a decision based on the proposal (as they would for a CWO)
The date of the CBIF meeting and the notes made at the meeting will be held in Peak
removing the need to create or review separate minutes
The date of the PTF meeting and the notes made at the meeting will be held in Peak
removing the need to create or review separate minutes
This is a critical meeting which sees POL and Fujitsu having mutual awareness of the main
Live Defects that could affect branch operations and the progress being made on them
‘The Horizon Defects Review (HDR) Forum is the new name for what was the Known Error
Review Forum (KERF)
Itis a joint Fujitsu and POL weekly forum to manage HDR Defects that meet the stated
definition
POL will maintain a list of all HDR Defects and their progress
Fujitsu will provide updates on the HDR Defects itis tracking using a weekly report that will
extract information from Peak for the applicable Defect Peaks. Hence the importance of the
Peak field values
Fujitsu will also provide updates on Peaks that were deferred from releases where they meet
the HDR Defect criteria as these are, by definition, Live Defects
Page I 13
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Page I 14
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Introduction & Overview
The Goal.
To implement the defined list of improvements in this document in substantive part by...
315 July 2021
.and to have completed all improvement including any early challenges and snags by
31%t August 2021
Purpose & Scope
© Byrunning a series of Streams of work we will systematically drive improvements across POA
© The Streams will likely overlap and may well change format as progress is made
© Although active participation in a Stream may be low for some, itis critical that there is a
‘common understanding or we will not achieve cross functional change
© Stream members may change over time
© Each Stream will have a set of actions to complete — initially derived from this document
© The team can add additional actions as needed
© POAneeds to urgently evolve to a cross functionally agreed set of ways of working so that it
can be explained to any interested party with ease
© Our interactions needs to be system and process driven not people and experience — and that
will create a clear audit trail too
© We need to limit the dependency on meeting-specific reports or embedded tables in minutes
to show progress on important matters
© Transparency is key — to the fullest sensible extent, POL need to see everything - and they
need to be able to see it in their systems or from consistent reports from our systems. That
way, POL are informed and able to make decisions for us or with us
© That means we need to be clearer and consistent about what we mean by Incidents,
Problems, service management toolsets, Peak, KB, Live Defects, Live Defect Management,
BIF, CBIF, HDR, Release Notes, agreed deferred Live Defects and probably more
© We need to agree the functions of the various platforms and meetings to ensure it all joins up
(this document is a start)
© If POLis tracking it — or applying governance to it - then so should we — and our process
should be in advance of theirs so we have no surprises
© We do not have all the tools and integrations we would like, so the goal is to make the best
possible use of what we have already
© We need to protect our internal systems from a need for routine disclosure — so we can work
our way
© We need to ensure any POL desires on our ways of working relate to contracted obligations
and suit how our systems and people work — unless we are commissioned to change any of
those — as this is more likely to be consistent and reliable
© For this to succeed we need considerable cross functional support coupled with manager and
team member engagement
The Streams
* Stream 1 — Incident & Problem (links to Peak, Key Meetings & Live Defect Management)
© Focusses on clarifying how Incidents & Problems should be managed and reported
on including their relationship to Live Defects and the integrations with POL's
ServiceNow and Fujitsu's Peak systems
Page I 15
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
* Stream 2 - Use of Peak (3LS, 4LS & Release)
© Focusses on the Peak Incident management features and their li
Management and Release Management
+ Stream 3 — Live Defect Management
© Defines an improved way to capture Live Defect information and report on it both
intemally and to POL
* Stream 4 — BIF, CBIF, PTF and HDR
0 Refines the ways these key meetings are managed and integrates them with the
revised ways of working on Incidents, Problems, Peak, Release and Live Defects
Each Stream documents the key elements that reinforce an existing way of working or state a new
way of working. This content will be embedded into existing account documents for it to be formalised
Each Stream will then contain references to any System Changes made (optional), the One-Time
Actions needed to move to the defined ways of working, and then the New Ways of Working that will
describe what is different from how things are done today.
Actions that have been completed are scored out. The One-Time Actions that are underway at the
moment are highlighted in green although some of the other actions may also be partly active too.
Terminology — Overview
We need to be clearer and consistent about what we mean by, and how we use, various tools and
processes within POA. The following entries are intended as an initial simple summary. They will be
expanded on as the workstreams progress and sub elements will also be reviewed too. They cover
Incidents, Problems, Peak, Release, Live Defects, Live Defect Management, BIF, CBIF, HDR and the
KB.
Incidents
© Allincidents which POL should be aware of must be created and managed in TfSNow and be
bonded so that they replicate to POL ServiceNow. Although actions and progress may
happen in other tools, systems and processes, the primary source of all relevant content
MUST be TFSNow.
Problems
© All Problems must be raised in TfSNow and be reviewed on an agreed schedule with POL. As
Problems cannot be bonded, additional work will be needed to manually share updates and
hold mutual reference numbers.
Peaks
© Peaks can be used for many purposes. Where Peaks relate to Incidents initiated from
‘TFSNow, the relevant Investigation Peak updates MUST be synchronised with TfSNow. Peaks
raised outside of an Incident MUST also be raised as TTSNow Incidents if they require the
awareness or involvement of POL.
© Peak is the only system used to record and manage Live Defects.
© Peaks do not need to be shared with POL. If the awareness or involvement of POL is
applicable then there will be a TfSNow bonded Incident and this will contain all relevant parts
of any Peak so that the Incident that POL see is a suitable complete reference. Progress
updates for POL on HDR Defects will take latest extracts from the Peak system and provide
the update in a report,
Release
© Release Notes must state all Peaks that are being closed when the Release goes live. This
must be included in the related Change ticket
Page I 16
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
‘© There must be a report showing the Peaks and any associated POL HDR Defect references
0 that POL are able to keep their tracking in sync.
© Release dates must be held in Peak so that Peaks can be tracked to deployment
Live Defects
© ALive 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 specific
‘+ Is, therefore, a fault that is likely to need fixing
* The Horizon Defects Review (HDR) scope will be those Live Defects that also have at
least 1 of the following attributes (HDR Defects):
* Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
"Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the "HDR-Exp’ Collection)
"Affects, or has the potential to affect, the experience of a Post Office
‘customer or client (add the “HDR-Exp” Collection)
n
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin should
be chosen
[ai incident to Coleco
[HOe-Esp— Horton Detect Review SPM Experience Publ I Redo Colecion
_ ana
HOR Exp ~ Horizon Defect Raview - SPM Experience [Pubic] A
HOR-Fin ~ Horizon Defect Review - Financial Impact Pubic]
+ There may be a workaround, but the underlying issue still meets the criteria above
* The HDR Defect may be under investigation and is not confirmed to meet the criteria
above but has attributes that meet the criteria above (a potential HDR Defect)
© When the HDR Defect is being investigated there will be a TfSNow Incident open and
bonded. POL may track status using their ServiceNow Incident reference or may create a
ServiceNow Problem record and manage it with that reference. All progress during
investigation is to be added to the TfSNow Incident so that itis visible to POL in their
corresponding Incident. It is POL’s responsibility to keep their Problem record up to date if
they have opened one.
‘* Note: If the Incident has been escalated to a Problem in TISNow then updates on the
investigation work will be provided within the weekly status update report which
shows confirmed Live Defect
© When a HDR Defect is confirmed then a specific defect Peak reference will be added to the
closing comments in the TfSNow Incident. Fujitsu will then manage the HDR Defect in Peak
and will provide status update reports ~ from Peak — to POL at their weekly HDR Forum.
© Non-HDR Defects will be managed intemally by Fujitsu using Peak. Reports will be available
for POL to show overall progress but it is not intended that every non-HDR Defect will be
discussed.
Live Defect Management
© AllLive Defects must be rigorously managed until resolved.
© The status of all Live Defects must be known at all times and they must be shared with POL:
the more branch impacting ones at POL's Horizon Defects Review Forum; and the rest by a
separate report. Fujitsu must assure POL that Live Defects are well managed and must keep
POL aware of progress.
Page I 17
Version & Last updated: See file name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
BIF
© Allconfirmed Live Defects must go through the Business Impact Forum (BIF) and must have
all the required meta data and tags added/checked.
© The dates of BIF meetings, the outcome, and the reasons for CBIF submission must be
recorded in the Peak
cBIF
© CBIF submissions will be based on criteria held in Peak.
© The criteria are shown later in this document and that criteria will be agreed with POL.
© CBIF will become part of the POL HDR weekly meeting
HOR
© The Horizon Defects Review (HDR) Forum is the new name for what was the Known Error
Review Forum (KERF).
© This is a critical meeting which sees POL and Fujitsu having mutual awareness of the main
Live Defects and the progress being made on them.
© Itis.a joint weekly forum to manage HDR Defects that meet the stated definition.
© POL will maintain a list of all HDR Defects and their progress. Fujitsu will provide updates to
the HDR Defects being tracked.
© There must be a POL Problem reference and a corresponding Fujitsu Incident, Peak or
Problem reference.
© The updates to the Fujitsu tracked Incidents, Peaks and Problems will be shared at the HDR
Forum.
KB
© The Fujitsu KB is an information repository used for support purposes.
© Any observed defects will be recorded as a Knowledge Base Article (KBA) but the progress to
investigate and address them will be done via Peak(s) and/or Incident(s).
© KBAs do not need to be shared with POL as the tracking needs to be on the Peak and/or
Incident.
© If the awareness or involvement of POL is applicable then there will be a TfSNow bonded
Incident and this will contain all relevant parts of any KBA so that the Incident that POL see is
a suitable complete reference.
Page I 18
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Stream 1 —Incident & Problem (links to Peak, Key Meetings & Live
Defect Management)
Team ~ Steve Bansal, Sandie Bothick & Matt Hatch
Managing Incidents
‘An Incident is defined in the HNG-X contract as “any perceived abnormal or undesirable
‘occurrence relating to the Services”
Incidents for the Live environment that POL need to be notified of and be aware of must be
logged in the Fujitsu service management toolsets, TfSNow, and bonded so it is visible in the
POL service management toolset, ServiceNow
Fujitsu must ensure TfSNow Incidents are raised and bonded where POL notification is,
required (e.g. when relevant KBAs are created, or faults are identified whilst doing other work
such as testing or problem determination)
Service Operations should only use TfSNow for communicating Incidents between Fujitsu and
POL
Incidents cannot be raised by email by POL or Fujitsu. Inci
Fujitsu or in ServioeNow by POL
The Summary field should be understandable by most readers as this feeds Peak and also
shows on reports
‘* For system monitoring this is set by SMC, bonded Incidents it comes from POL,
otherwise it's Fujitsu staff (MAC & Security) that choose its content
The Incident should be a complete and comprehensive self-contained reference to the status
of an Incident
Incident progress MUST be shown on the Incident in TfSNow and cannot be managed via
separate emails. Emails must be added to the Incident in TfSNow if relevant to demonstrating
progress or status
The Incident should appear to be integral — the fact that 3 and 4" line use a different toolset
should not be apparent
There should be no references visible to POL (going forward) to toolsets used by Fujitsu that
are not accessible to POL such as Peak or KBA for status information (as these are Fujitsu
internal) — a Peak reference is acceptable for a reference to a defect Peak that is being
progressed, References for Fujitsu use only must be maintained
Incidents must be updated to contain relevant updates from systems such as Peak (but not
private updates) and relevant parts of KBAs (not the intemal instructions)
Incidents raised as Fujitsu intemal that do not need to be notified to POL may contain internal
system references
Incident updates should contain meaningful and appropriately detailed technical content
Incident updates, and in particular updates summarising the current status, should be written
in plain English to be understandable to most readers
A clear statement of the latest status and the next action should be obvious within the
Incident. This needs to be the last, or very recent, update
‘+ The “Additional comments (Customer visible)" field must provide a latest status view
~ at least periodically and for POL bonded Incidents mainly — so it can be easily
understood by any reader. Peak uses a dedicated field for this and uses the following
format:
* Business impact: [description of the business impact, succinct]
= Status update: [description of current status — succinct]
Next action: [next action to be taken and expected date for next update]
For bonded Incidents we need to use the agreed set of categories, sub-categories and Cls so
that the replication interface retains the settings. The original setting will stand throughout the
ints must be raised in TISNow by
Page I 19
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
life of the Incident. You cannot change the Category/Sub-Category or it breaks the replication
link. You can change the Cl but it will be retained Fujitsu side but will not replicate
© We need to use the designated open and close categories to better monitor Incident
categories
* Open category ~ TYSNow has Configuration Items that should be used
‘* Closure code — TfSNow has these and they should be used
© The Peak closure codes must map to TfSNow Incident closure codes. As at the date of this
document the mappings are as follows:
Peak Closure Code Fujitsu
‘Advice afer Investigation POA Advice & Guidance
‘Avoidance Action Supplied POA Fujitsu Operational
‘Administrative Response POA-Administration
‘Advice and guidance given POA Advice & Guidance
No fault in product POR No aut Fovgenaay
Duplicate Call Cancelled
Solicited Known Error POA Advice & Guidance
Insufficient evidence Unidentified Root Cause
Fix Released to Call Logger POA Peak Faull Found
User error POAUser Error
Unspecified Insufficient evidence _I Unidentified Root Cause
Call withdrawn by user Cancelled
Fixed at Future Release POA Peak Faull Found
Enhancement Request POAPOL domain
‘Suspected hardware fault Unidentified Root Cause
© Incidents outside of the Fujitsu domain that are identified by Fujitsu are passed to POL
ITDSD. If there are no consequential implications for Fujitsu then the TfSNow Incident will be
set to Suspended to await feedback to help us advance our KB (perhaps for the agreed
Suspend period and then we close). If there are implications then we leave the Incident open
‘as we need to know the outcome
© Only the originating organisation can close an Incident
‘* Incidents we have marked as requiring a fix should be closed in TFSNow with the
defect Peak reference added as that is what will be tracked and managed to
conclusion
* For Incidents closed that relate to process or user issues then we should propose
system improvements — and this should be done in conjunction with an equivalent
process for Peaks closed with the same reasons
© Fujitsu will set an Incident to Suspended in TfSNow until POL close their original Incident
Page I 20
sion & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
‘+ Note: Resolved in TYSNow only means that the last assigned Resolver Group has completed
their action — but it may require other actions by other Resolver Groups. Therefore, Resolved is
not replicated to ServiceNow or POL will wrongly assume it is Resolved and will likely close
their Incident. When all possible actions are complete and MAC believe itis truly Resolved then
they will request POL to close it
+ When POL close an Incident it notifies MAC and MAC can then close the TfSNow
Incident
‘+ Incidents in a Suspended state are reviewed weekly between the MAC and POL
teams and it is included in the monthly SMR pack.
= Where the Incident is Suspended as no further action by Fujitsu is possible
then after 10 days the Incident will be closed. When the Incident is set to
Suspended the following text will be added as the final update “Please be
aware that the incident will automatically be closed after 10 days if no
response is received from you.”
© Fujitsu must tag Incidents that POL are tracking (mostly for HDR) so it is aware of Incidents
where POL have an interest so that it can review content and status frequently. Adding any
relevant POL references, such as the POL Problem reference, should be considered
© ALive 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
‘+ Incidents that meet the definition of a Live Defect must have the
Cl added in TfSNow
‘+ The State field values must be used
/eAffectingDefect”
State Workin Progress
"Acknowledged — Fujitsu is aware of the Incident but is not yet working on it
+ Work In Progress/Researching — Fujitsu is investigating the issue described
in the Incident
* Fix In Progress — Fujitsu has confirmed that the Incident requires an action to
fix it most likely linked to a Change ticket
+ Suspend — action is complete by Fujitsu or is required from another entity
+ An Incident that has the LiveAffectingDefect Cl and State of Acknowledged/Work In
Progress/Researching is a potential Live Defect. Suspend will also be classed as a
potential Live Defect too for simplicity
‘* An Incident that has the LiveAffectingDefect Cl and State of Fix In Progress is a
confirmed Live Defect
© The POL Horizon Defects Review scope will be those Live Defects that also have at least 1 of
the following attributes (HDR Defects):
Page I 21
Version & Last updated: See file name
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
= Configuration tems SearchI time v[wa
1 tor0t1235 >
company = Managedby
search search search
© sok ee Pos formy)
eon Pon ‘ome
+ Affects, or has the potential to affect, branch financial outcomes (add the “HDR-Fin”
(oD)
‘* Affects, or has the potential to affect, the way a postmaster is required to use the
system (User Interface, Report, Function) (add the “HDR-Exp” Cl)
+ Affects, or has the potential to affect, the experience of a Post Office customer or
client (add the “HDR-Exp” Cl)
Note: Only one HDR-* Cl needs to be set and if both could apply then HDR-Fin should be chosen
© When the HDR® Cl is applied to an Incident, Fujitsu MAC will also email the Fujitsu Duty
Manager email alias and a POL designated alias to provide an email early warning that a new
HOR Incident has been raised
© Incidents carrying a HDR® Cl will have the POL Problem references added to the Incident to
enable cross-checking
© Incidents carrying a HDR® Cl will still be classified as potential or confirmed Live Defects
using the classifications mentioned above
© Peaks that are cloned that have a ServiceNow reference cannot be closed by EDSC until the
cloned Peak that was created is also closed or has its Call Type changed to “#". The original
Peak must be kept open until the cloned Peak is closed and updates must be applied to the
original Peak so that the related TfSNow and ServiceNow Incidents continue to receive
updates. For Peaks cloned for GDC for GDPR obfuscation reasons this will only apply up to
April 2020 as from that date the original Peak was obfuscated and a clone was not created
Peaks that are closed that have a ServiceNow reference with the reason being that a cloned
Peak is now to be tracked will be sent back to Peak by MAC to reopen the Peak as this must
be maintained to ensure the continued automatic flow of updates to the originator
© Recurring Incidents and Incidents with follow up actions require a Problem record to be
created. The Incidents are linked to the Problem
© To ensure we avoid updates being overtly associated with an individual, meetings, updates,
and reports relating to Incidents must be system driven from the relevant toolset — not
separate emails or meeting comments
© We need management reports for Incidents to see trends. This needs to be part of the
monthly SMR and/or internal Service Operations meetings:
‘* Open, Active and Closed Incidents
‘+ Live Defect Incidents — potential and confirmed
* HDR Defects ~ potential and confirmed
‘* For each, show views based on:
"= Open category & Close codes
"= Classociations
= Internal response times by type/priority
Page I 22
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
"Branch Code - an Incident may relate to one FAD (Branch Code will be set to
the nnnnnn FAD by either Fujitsu or POL) but it may relate to many FADs
(Branch Code set to POA SMC by Fujitsu or MAC by POL)
© Service requests should not be accepted as Incidents, but whilst they are very few (those that
relate to investigations are now re-directed through other channels) this will be accepted and
reviewed periodically
Managing Problems
© Problems must be logged in the Fujitsu service management toolset, TTSNow
© Problems cannot be bonded, like Incidents, to cause mutual replication between the Fujitsu
and POL service management toolsets so each organisation needs to maintain its own
records independently
© POL need to provide their Problem reference for Fujitsu to record and link to its own Problem
& POL also may need to provide status updates back to Fujitsu — we need to escalate POL
inefficiencies at SMR as well as at the inter-company Problem Review Meeting
© Fujitsu internal Problems are managed entirely in TfSNow
© Ifa Problem is tracking a Live Defect then the Problem needs to hold the Peak reference as
that is where progress will be actively updated and reported
© Peaks related to Fujitsu Problems will need to have the Fujitsu Problem reference added so
the association is clear when checked from either system
© Note: Fujitsu use Problem tasks and manage the updates to those
© Major Incidents will lead to Problems being raised to close out on all findings
© Fujitsu MAC will notify Problem of underlying issues identified from Incidents —these tend to
relate to Unix, NT etc (TfSNow Resolver Groups) and no Peaks (Peak has its own processes)
© Problems also use the State field — Acknowledged, Work In Progress, Researching, Fix In
Progress, Suspend — to record and track status
© The Problem should have the applicable Configuration Item assigned (HDR Defects):
= Configuration tems Search ime
1 to200f1205 >
Assettag — SSerisiumber Company = Managed by
© HORE Pos comp)
ern Pon ‘ome)
* Affects, or has the potential to affect, branch financial outcomes (add the “HDR-Fin”
cl)
* Affects, or has the potential to affect, the way a postmaster is required to use the
system (User Interface, Report, Function) (add the “HDR-Exp” Cl)
‘+ Affects, or has the potential to affect, the experience of a Post Office customer or
alient (add the “HDR-Exp" Cl)
Note: Only one HOR-* Ci needs to be set and if both could apply then HDR-Fin should be chosen
© Problem reporting should have HDR tagged Problems
© Incidents where the resolution is a fix to address a Live Defect may be both a Peak and a
Problem (the former for management, the latter for joint process validation)
Page I 23
Version & Last updated: See file name
cument owner Steve Browe
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Actions
System Changes
* Added Cis for HDR-Exp, HDR-Fin, LiveAffectingDefect
New Ways of Working
1. Sandie - We need to regularly check
that any Incident that POL need to be notified of or be aware of has been logged in
TfSNow and bonded
that we do not reference KBAs, Peaks or include internal content in TfSNow bonded
Incidents and that the TfSNow Incident contain all relevant content and be a
comprehensive self-contained reference to the status of an Incident. The only Peak
reference that should be added is for defect Peaks (if applicable)
Incidents are being updated and that we are not using separate emails to share
progress that is not embedded into the Incident updates
Incident updates are well worded and use language that is understandable to most
readers — challenging and coaching where needed
the current status and the next action on an Incident is clearly stated so any reader is
inno doubt that the Incident is under full control — challenging and coaching where
needed
the Summary field is well worded and understandable by most readers
the relevant open and close categories are being used when handling Incidents —
applying additional caution with bonded Incidents to use the mutually agreed settings
the LiveAffectingDefect Cl is being set for Live Defects
the HDR* Cls are being set by Fujitsu management where applicable (and that the
POL Problem Reference is also added to the Incident)
when an Incident is placed into Suspend as no further Fujitsu action is applicable
then the text of "Please be aware that the incident will automatically be closed after
10 days if no response is received from you.” has added. After 10 days, these
Incidents should be closed
2. Sandie/Steve Ba — create a process/report to share Incidents and Peaks closed due to
process or user issues with POL monthly to encourage POL to consider system
enhancements that could avoid the occurrence of the issue
Page I 24
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Stream 2 — Use of Peak (3LS, 4LS & Release)
© Team - Adam Woodley, Tariq Arain, Matt Swain, Tomi Okelola ~ plus John Simpkins & Mark
Wright
Peak
© The use of Peak and the updates to Peaks must be consistent and documented. That takes
the onus off the people and it enables anomaly reporting and management oversight
© Ifthe awareness or involvement of POL is applicable then there will be a TISNow bonded
Incident and this will contain all relevant parts of any Peak so that the Incident that POL see is
a suitable complete reference
© any 3LS, 4LS or Architect creates a Peak in the course of their normal duties that matches
the definition of Live Defect:
«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
..then it must be given the ##LiveAffectingDefect Collection and an Incident must be raised
in TfSNow if one is not already open.
YASS to Collection
© Ifa Peak has had the ##LiveAffectingDefect Collection added, and it also has at least 1 of the
following attributes (Horizon Defect Review):
* Affects, or has the potential to affect, branch financial outcomes (add the *HDR-Fin”
Collection)
* Affects, or has the potential to affect, the way a postmaster is required to use the
system (User Interface, Report, Function) (add the “HDR-Exp” Collection)
‘+ Affects, or has the potential to affect, the experience of a Post Office customer or
client (add the “HDR-Exp” Collection)
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin should be
chosen
[Ad Incident to Collection
HOR.Exp - Horizon Defect Roview - SPM Experience [Public] YJ] Adie Collection
HDR Exp ~ Horzon Defect Review - SPM Experience [Pubic]
HOR-Fin ~ Horizon Defect Reviw - Financial impact [Pubic]
© Ifa Peak raised independent of TfSNow is subsequently qualified as being an Incident that
POL should be aware of, then Fujitsu MAC need to be contacted. Fujitsu MAC will create a
new TFSNow Incident which will be bonded and then assigned to 3LS. This will create a new
Peak, The content of the original Peak must be copied to the new Peak so that updates can
automatically flow back to TISNow. The original Peak should be closed citing that it has been
superseded by a Peak linked to TTSNow
‘© When the investigation into an issue defined in a Peak originating from TfSNow is concluded,
the ‘investigation’ Peak can be closed
‘* If the investigation Peak is an existing clone then the Peak can have its Call Type
changed to “#" (for GDC obfuscated Peaks this will apply to any cloned Peaks
created prior to April 2020)
Page I 25
Version & Last updated: See file name
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
+ The investigation Peak has not been cloned then it needs to be cloned to create a
defect Peak (for GDC obfuscated Peaks this will apply to any Peaks obfuscated since
April 2020)
+ The defect Peak reference should be added to the investigation Peak as part of its
closure activity. The defect Peak reference will then be mentioned in the TfSNow
Incident so that it replicates to POL ServiceNow
© The interface between TfSNow and Peak (OT!) must protect the internal system references to
Peaks or KBAs and updates should appear to all be generated in TfSNow ~ except for a
reference to a defect Peak that is shared for future tracking purposes
© The Summary field needs to be written so as to be understandable to most readers a:
be used in internal management and external POL reports
© New fields are being introduced to help Live Defect Management tracking and reporting and
these will need to be completed by various parties as the Peak progresses
* See section Live Defect Management — Key Fields in Peak
© Cloning processes and rules need to be applied consistently:
* Cloning carries forward all Collections, References and Key Fields and it must show
cloned from and cloned to support chain of events tracking
‘* Cloning should be for specific purposes and the reason will appear as a prompt when
cloning is initiated:
= 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 TISNow Incidents. Peaks cloned prior to this date
that remain open will have broken the auto links to any TSNow Incidents
= 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)
+ Disassociating from the TfSNow incident (e.g. documentation, follow-on to an
initial response to an Incident)
* Creating the defect Peak to progress the Live Defect to resolution
= Creating Test Only Peaks where the test in a particular environment can't
mirror the entirety of the issue described e.g. 3 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: ifa Peak has been assigned to @ 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
it will
Page I 26
Version & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
‘+ The user selects from the list (Defect is the default option) and clicks confirm. The
reason is captured in the clone Peak:
[Date:41-Aug-2021 09:00:38 User:John Simpkins
lcaut Pco2ses98 opened
[Details entered are:
lcaLL Pcazaaceo opened
loetsils entered are:-
ISumary:test mb problen
‘* Ifthe Defect reason is selected, the clone will be created with Calll Type “#"
Peaks raised in Test or Dev that also relate to the Live environment will not have Call Type
‘* Test will raise a new Peak within the release being tested for unexpected Live
Defects and then assign it to the Developers. It has a Call Type "P” by default
+ The Developers & Architects decide if it relates to Live and must set the relevant Live
Defect meta data as described above
Peaks that are cloned that have a ServiceNow reference cannot be closed by EDSC until the
cloned Peak that was created is also closed or has its Call Type changed to “#". The original
Peak must be kept open until the cloned Peak is closed and updates must be applied to the
original Peak by EDSC so that the related TfSNow and ServiceNow Incidents continue to.
receive updates. For Peaks cloned for GDC for GDPR obfuscation reasons this will only apply
up to April 2020 as from that date the original Peak was obfuscated and a clone was not
created
Peaks that have been held by EDSC due to having been cloned and having a ServiceNow
reference must be periodically reviewed to ensure updates from the cloned Peak are applied
Peaks that are closed that have a ServiceNow reference with the reason being that a cloned
Peak is now to be tracked will be sent back to Peak by MAC to reopen the Peak as this must
be maintained to ensure the continued automatic flow of updates to the originator
Page I 27
Version & Last updated: See file name
Document owner Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
‘© Rules on use of Call Type need restating so we ensure greater consistency
© All Peaks must be owned by a team whose manager will check that progress is being made
© We need regular management quality checks — use of fields, age of Peaks, progress being
made ~ and this needs to be summarised and reported upwards to ensure executive visibility
and confidence
‘+ The report created by Fujitsu MAC is useful but does not appear to cause action to be
taken
© The origin of a Peak ~ SPM, POL, SMC, Fujitsu — is identifiable by scraping the Contact
Name: field — but this cannot be done using standard Peak reporting and requires a custom
script to be run. This has been created to help the POA Defect Manager report on this content
1501
Just for info based upon this meeting, When adding progress to a ‘bonded’ Peak the default
response option is - Progress Only’ this does NOT flow back to Peak
tated
ent
aapeecmren 2 tee)
recat Devt te Sefer Dae
[eet oa][—e)
ested
Note the Text on the right-hand side of the progress entry box for further guidence.
ltyou select a response category then the text above the Progress changes to reflect this:
=
iposus:
apace 2 a)
(Sal I
ar cre teat
(eaweat) ee
No references will be sent across to TFSNow (or beyond) so all Documents. Baselines. KBs, Peak etc
can be added as references
© Updates added the Response field are replicated across the OTI
© The References field is manually maintained so can miss Incident or KBA references. SMC
may add KBA into reference text instead of into the References field which limits query-ability
© Peaks closures:
‘* Incident related Peaks are closed when the investigation phase has concluded and
no further action is needed, when further info required (as it passes back to TfSNow),
or when the next action needs to be assigned to another TfSNow Resolver Group
(the Peak is no longer needed)
Page I 28
Version & Last updated: See file name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
‘* Incident related Peaks are closed when the investigation phase has concluded and
we have a confirmed Live Defect. This would see a cloned Peak raised as Call Type
“#. Ifthe Peak is not linked to a TfSNow Incident bonded to POL then the Peak can
just be reassigned to Call Type “#”
‘+ Defect Peaks are closed when the Release they are targeted at is deployed ~
ideally by automating the process — this will probably be Peaks at Status °F”
‘+ Allother Peaks are closed based on team/process specific rules — as per current
processes
© Peaks closed as user/process error should be considered along with TfSNow Incidents closed
for the same reasons to provide a monthly report to POL to recommend enhancements that,
could avoid the occurrence of the issue. A likely source of these could be Peaks closed with
the following Root Cause values:
* °39 General — User Knowledge” — caused by lack of knowledge with the user
* "40 General - User" - caused by an action performed by the user which was.
outside expected use
* "41 General - in Procedure” — caused by not following defined procedure
© Peaks/Incidents closed as “66 — Final — Enhancement Request” should also be reported on
monthly to POL to recommend enhancements are submitted to Fujitsu. KBAs also needs to
be updated to show the outcome was that POL need to raise an enhancement request
© Peaks that are resolved but not ready to be closed as the resolution action is to be ‘monitored”
can remain in a non-closed state but must have a Forecast Date added to the Response so
that this wams the support specialist and team leader that the review date has arrived and the
Peak should be reviewed for closure
© The Peak closure codes must map to TfSNow Incident closure codes. As at the date of this
document the mappings are as follows:
Peak Closure Code Fujitsu
‘Advice after Investigation POA-Advioe & Guidance
‘Avoldance Action Supplied POA-Fujitsu Operational
‘Administrative Response POA-Administration
“Advice and guidance given POA-Advioe & Guidance
No taulllaprodict POA-No Faull Found/No Action
Taken
Duplicate Call Cancelled
Solicited Known Error POA Advice & Guidance
Insufficient evidence Unidentified Root Cause
Fix Released to Gall Logger POA Peak Faull Found
User error POA User Error
Unspecified Insufficient evidence _I Unidentified Root Cause
Call withdrawn by user Cancelled
Fixed at Future Release POA Peak Faull Found
Enhancement Request POA-POL domain
Page I 29
sion & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
I Sespectd hardware out I Unidentiia Root Cause I
An Incident may relate to one FAD but it may relate to many FADs — this is recorded in the
Business Impact text showing the number of branches affected
To ensure we avoid updates being overtly associated with an individual the updates should
be system driven — not separate emails or meeting comments
For the occasions where Fujitsu is required to share actual Peaks, it will need to define a
Peak extract process that will brand, classify and version control content. The process must
also redact/obfuscate to remove Pll and remove internal only Progress updates. This extract
process is not under consideration as at the date of this report
Release
© Deferred Peaks should be recognisable against the release they were deferred from and the
release to which they are subsequently targeted
Only Peaks can be deferred — POA Jira's or other things stored outside of Peak CANNOT be
deferred
Deferred Peaks are by definition Live Defects. When a Peak is deferred, the Fujitsu party
obtaining the agreement must ensure:
‘+ the ##LiveAffectingDefect Collection is set
‘+ the "Deferral Agreed” Collection set
The Call Type set to “#" if the Live Defect is confirmed and a fix can be progressed, or
the Call Type set to “L" if the Live Defect still needs further investigation
Target Release Type changed to "Proposed for" for subsequent update via BIF/PTF
If the deferred Peak has at least 1 of the following attributes (Horizon Defect Review):
"Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
= Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the "HDR-Exp” Collection)
‘Affects, or has the potential to affect, the experience of a Post Office
‘customer or client (add the “HDR-Exp” Collection)
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin
‘should be chosen
[Rad Tncdeat ve Calistion
[HOR xp rtorzon Detect Revion- SPM Exparanca Pubic] [Af Calecton
HOR-Exp ~ Horizon Defect Review - SPM Expacencs [Pub] A
HOR.Fin- Horzon Date! Reviaw- Franca impact Pub] oo
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 similar to below):
Page I 30
Version & Last updated: See file name
Document owner: Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
(Cau Rarely [POL Probe RedFigiu Pot Rd
Release Notes will not list
+ the Peaks that are being deferred (as they are not fixed yet)
‘* any clone Peaks raised by Test for Test Only actions (as these are not additional
Defects but are just a tracking mechanism for the Test team)
The action of deploying the Release should cause the relevant Peaks on the Release Note to
be closed. As a minimum it should ensure all are set to Status “F” and alert the originator that
the fix is deployed and they are asked to close the Peak
Commented [BS1]: RM will need to ensure SSC are overtly
‘Release Peaks” are administrative reference Peaks for Release Management. They do not edited
act as master Peaks so the defect Peaks must be kept updated independent of the Release $5C will need a process to take the required action
Peak settings and dates
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
Release Management processes will apply to 3" party deployments that are within the Fujitsu
scope of responsibilities. For example, Ingenico fixes will be deployed under releases and
Peaks will be Targeted At, Proposed for, and Reported In release numbers identified for
Ingenico fixes — currently 90.xx
Hotfixes are a mini release and will use the new 3-node release numbering xx.yy.2z where
the primary 2 nodes are the release that they relate to and the third node is the hotfix number.
Peaks that form part of a hotfix will be targeted at the 3 node Release
Release Management will maintain the Target Release date table:
+ 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)
* All future Releases must show the latest anticipated release date for deployment ~
irrespective of who will be leading the deployment
‘* The Release date should be the first time that the deployment was made to any live
environment (Model Office or agreed pilot rollout sites). The date will therefore show
the first time the fix was deployed to a live counter/branch eventhough a phased
rollout may mean other counters/branches did not receive the fix until a later agreed
date
‘+ The Target Release screen should be used to make universal changes to Peaks
when release information changes. The Plan Out Live date 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):
‘* Hotfix releases must also be included in the date table
Page I 31
Version & Last updated: See file name
Document owner: Steve Browe
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
+ Targeted Releases with no stated deployment date must be reported on and
validated to ensure progress — or the intentional lack of it - is defined by process and
cannot go unnoticed
+ We all know that the goal is to progress from logging a perceived fault to fixing it
(unless it isn't really a fault) as quickly as we can. The added objective here is to
ensure POA management and POL management are aware of the packages of work
we have and are fully engaged in determining priorities and dates. The only thing
stopping us making an immediate fix should be a POL supported decision to not take
immediate action. We should never determine what we fix or don't by ourselves
(unless Fujitsu is the only beneficiary of the fix). So, here are some actions I feel
move us closer to that goal:
Actions
System Changes
* Create a button alongside the listed Peaks on the Release Note that gather the content for
into an Excel sheet for easy upload into the TfSNow Change ticket, updated the cloning
process to ask for a reason and then record it in the new cloned Peak, updated the cloning
process to take more fields across to the clone
New Ways of Working
1. Managers will need to conduct spot checks on Peak data entry quality and encourage new
habits — fields filled in, fields read well, clones created for correct situations - See Appendix A
2. Adam/Steve Ba/Sandie — Peaks closed as uset/process error should be considered along
with TFSNow Incidents closed for the same reasons to send a monthly report to POL to
recommend enhancements that could avoid the occurrence of the issue
3. Adam/Steve Ba/Sandie — Peaks/Incidents closed as “66 — Final — Enhancement Request”
should also be reported on monthly to POL to recommend enhancements are submitted to
Fujitsu. KBAs also needs to be updated to show the outcome was that POL need to raise an
‘enhancement request
4, Matt S — Targeted Releases with no stated deployment date must be reported on and
validated to ensure progress — or the intentional lack of it - is defined by process and cannot
go unnoticed
> the ##fLiveAfectingDefect Collection is set
© the “Deferral Agreed” Collection set
© The Call Type set to “#" if the Live Defect is confirmed and a fix can be progressed, or
the Call Type set to “L” if the Live Defect still needs further investigation
© Target Release Type changed to “Proposed for" for subsequent update via BIFIPTF
o Ifthe deferred Peak has at least 1 of the following attributes (Horizon Defect Review):
* Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
* Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the "HDR-Exp” Collection)
"Affects, or has the potential to affect, the experience of a Post Office
customer or client (add the “HDR-Exp” Collection)
Page I 32
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Stream 3 — Live Defect Management
© Team - Adam Woodley & Tariq Arain ~ plus John Simpkins
Live Defect Management — Live Defect Definition
© AllLive Defects are managed in Peak only
© Some classifications of Live Defects are managed in a joint weekly Horizon Defect Review
Forum chaired by POL. These are known as HDR Defects
© ALive 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
+ The Horizon Defects Review (HDR) scope will be those Live Defects that also have at
least 1 of the following attributes (HDR Defects):
* Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
* Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the "“HDR-Exp" Collection)
"Affects, or has the potential to affect, the experience of a Post Office
customer or client (add the “HDR-Exp” Collection)
[Raid Toston ta Coleco
HOR-Bxp ~ Horizon Defect Review - SPM Experience [Publ [Ads Collection
Ep le)
* There may be a workaround, but the underlying issue still meets the criteria above
‘* An Incident may be under investigation that is not confirmed to meet the criteria
above but has attributes that meet the criteria above (a potential Live Defecv/HDR
Defect)
© Note 1: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin should be
chosen
© Note 2: Defects identified and managed throughout the Development and Test stages are not under this
Live Defect Management process as they do not relate to the Live system. Hence there are 3 types of
defect
+ Live HOR Defects
+ Live (Non-HDR) Defects
© Non-Live Defects (testdev eto) — not tracked by Live Defect Management
© Note 3: KBAs can be raised to describe Live Defects but the management of the Live Defect is done by
the Peak and this Live Defect Management process
Live Defect Management — Goals
A banner will appear on the Peak login screen to remind support staff of the changes that are
described below. This will most likely be removed when new habits are successfully formed and
the reminder is no longer needed:
Page I 33
Version & Last updated: See file name
Document owner: Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
[Detect Management Changes
ave ben some hangs tthe Defect Management oes 1 enable mee aca repeting Pease come the follower when reviews «poten defer Peak
1 Wte posible enure you open uptrend fo son tec wets
Peak Incident Management System - RMG Account
© Live Defect Management must have a designated owner on POA to manage and evolve the
processes and systems used
© Staff will need training and guidance on how POA wants Live Defects to be managed and
how the systems need to be kept up to date
© Live Defects must be recorded as Peaks and managed using the Peak system
* Fujitsu may have Problems open for Live Defects but the Problem record needs to
hold the relevant Peak reference as this will be where progress updates will be
derived
© We must know how many Live Defects there are at any point in time — and importantly, we
must know which ones are part of the HDR Defect tracking led by POL and we must store the
POL tracking reference on our defect Peak
© We need to 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
© We need to know the status of all Live Defects and whether there are any issues needing
attention
© We need to be able to review trends and attributes of Live Defects to identify pattems — for
‘example, we need new reports to show trends, volumes, efficient areas, inefficient areas,
process stalled, aging entries, mix by priority, targeted at, time by stage, defects by system
area
© Live Defects must be clearly titled so that they can be understood by the majority of readers
© Live Defect status must be clearly stated and be current and not require the reader to read
content and come to a summarised view themselves
© AllLive Defects must have a clear next action stated that can be tracked
© All Live Defects must be owned by a team at all times whose manager will ensure the right
actions are being taken (this can be a different team throughout the lifetime of the Live
Defect)
© Managers must ensure that Live Defects within their areas are reviewed regularly and action
taken to ensure processes are being followed — this may require manual reviews
© 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 itis visible to POL in their
corresponding ServiceNow Incident
+ Itis POL’s responsibility to keep their Problem record up to date if they have opened
one
© 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. The Peak will
be closed with Response Category “95 -- Final - Advice after Investigation” [or “66 - Final —
Page I 34
Version & Last updated: See file name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Enhancement Request’] which will see it excluded from Live Defect counts in the future. The
HDR-* Collection should remain so we know it was considered within the HDR Forum
© 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 meta
data tags. 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 TTSNow
Incident. Fujitsu will then manage 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
© Live Defects that are not classified as HDR Defects are managed intemally by Fujitsu using
Peak. Reports will be available for POL to show overall progress but it is not intended that
every non-HDR Defect will be discussed
© There are a number of new and updated fields that comprise the key meta data used to
manage defect Peaks. These fields must be kept up to date by Fujitsu staff and checked and
amended by team managers regularly
‘© Defect Peaks that are approved for deferral when a release is deployed are, by definition,
Live Defects. The party obtaining agreement to defer the Peak must ensure’
‘+ the ##LiveAffectingDefect Collection is set
‘Add to Collection I
‘+ the "Deferral Agreed” Collection is set
‘+ The Call Type is set to“#" if the Live Defect is confirmed and a fix can be progressed,
or the Calll Type set to “L” if the Live Defect still needs further investigation
Peak Inciden
DETAILS
F = Document Reviw!Design Walkthrough oe
"rz G ~ GDC Testing incident/Defects
I ~Internal Development Incidents Defects
kK Primark
= Problem Management
(0-~ Operational (SSC)
Product Incidents;Defects
UR Release Notice Forum b
'S~ System Testing Incidents/Defects
cal T ~ Technical query
{U-~Secutty Testing ncdents/Defects
\V— Valnecaity
W- Reference Data Service
X_System Management Testing Incdents/Defects
Y= Live (Non-RetData) Data Updates 5
roduct Site!
ricer WAI Platform NA I Serv
* Target Release Type changed to “Proposed for” for subsequent update via BIF/PTF
Page I 35
Version & Last updated: See fle name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
+ If the deferred Peak has at least 1 of the following attributes (Horizon Defect Review):
= Affects, or has the potential to affect, branch financial outcomes (add the
“HDR-Fin” Collection)
* Affects, or has the potential to affect, the way a postmaster is required to use
the system (User Interface, Report, Function) (add the "HDR-Exp" Collection)
= Affects, or has the potential to affect, the experience of a Post Office
customer or client (add the “HDR-Exp” Collection)
Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-Fin
should be chosen
[Rad Incident vo Callen
[HOR-Esp—rorzon Defeat Revs SPU Exprence Pubic] [Ade Catocton
HDR Exp ~ Harzon Defect Review - SPM Experience [Pubic] i
HDR-Fin ~ Horizon Defect Review - Financial impact [Pubic]
We need a documented process that reviews any Fujitsu internal Jiras and ensures they are
monitored and raised as Peaks when needed so they follow the processes. Jiras meeting the
criteria stated in Appendix C require no action as Appendix C is a POA policy
We need to hold dates when Releases went live and when future Releases are proposed for
so we have an outcome for any defect Peak
We need to provide a full list of ALL Live Defects closed in a Release with their associated
POL Problem references so that POL are also able to manage their HDR process
Reports are needed for management to show the overall status, trends, and patterns related
to all current Live Defects and historical Live Defects
CBIF rejections will get a POL reference that we will add to the Peak References field and
also to the KBA so we know this was a POL decision not to take further action. The Peak will
be closed with Response “63 -- Final -- Programme approved - No fix required”
CBIF submissions will be documented in a file that will be attached to Peak. The file will use
the File Type “CBIF Proposal so it can be readily identified. This will be sent to HDR so that
the meeting has the information in advance
The outcome of BIF/CBIF/PTF meetings will be held in concise notes in the relevant text
boxes on the Release Mgt tab. No need for separate minutes
Peaks that have been tested successfully and are still to be deployed must not be closed and
must be routed to 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
“Release Peaks" are administrative reference Peaks for Release Management. They do not
act as master Peaks so the defect Peaks must be kept updated independent of the Release
Peak settings and dates
{Commented [B52]: 58 todecide how thisistracked
Version & Last updated: See file name
ES
Page I 36
Document owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
© The following Response Category field values are considered No Fault Found:
Response Category — 62 — Final - No fault in product
Response Category — 63 ~- Final ~ Programme Approved — No Fix Required
Response Category ~ 66 -- Final — Enhancement Request
Response Category — 68 — Final — Administrative Response
Response Category ~ 94 -- Final — Advice and guidance given
Response Category — 95 ~ Final — Advice after Investigation
Response Category — 96 — Final — insufficient evidence
Response Category — 97 — Final — Unspecified insufficient evidence
Response Category — 98 — Final — User error
Response Category — 100 — Final — Route call to 11S
Response Category ~ 120 — Final ~ Cloned to create Defect Peak
Response Category ~ 200 ~ Final - Call withdrawn by user
© We should ensure that any Live Defect is promptly investigated until we confirm no fault is
found or that a fix is needed and change the status to Defect Identified. Anyone owning a
stack with Peaks classed as ##LiveAffectingDefect that is open and still being investigated
should ensure progress is made optimally
© If we have a Live Defect that is Defect Identified and it has either of the HDR-* Collections, or
is Priority A or B we should:
a. Explore every option we can to find a workaround — and implement it
b. Getit Targeted At a release as fast as possible (immediate BIF and PTF)
©. Geta strong proposed date for these Releases (so we have a go live date in
mind) ~ this may require more input from POL
d. Propose a hot-fix is considered and invite POA management and POL
management to decide if they want to or not (forget the constraints — this is a
management call)
e. Stack owners and Release Management must ensure this is done
© Ifwe have a Live Defect that is Defect Identified and is Priority C/D/Z we should
a. Getit Targeted At a maintenance release as fast as possible
b. Normal BIF and PTF scheduled meetings can continue
c. Demand more maintenance releases with confirmed dates
d. Stack owners and Release Management must ensure this is done
e. We should expect to put Live Defects that are Defect Identified into the next
month's maintenance release ‘at the latest’
© Take ALL numbered and dated Releases to Demand Planning so they can be prioritised
alongside other work by POA and by POL and POL know the implication of not allowing us to
progress them Commented [BS3]: Added and subject to review and.
action planning
Live Defect Management — Key Fields in Peak
The following are the key fields needed for Live Defect Management:
Page I 37
Version & Last updated: See file name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
© Gall Type — must be set to “#" Defect Identified when a Live Defect is confirmed. Prior to this,
Live Defects ought to 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
[GaiReemce__Jpco29s241
[Release [Reported In -- HNG-X Rel. Ind.
[Cait ‘0 — Operational (SSC) Y
[Contact
‘A-- Administrative use
C— Cloned call ginot yet defined TBA] St
E — Enhancement Request =
F Document Review/Design Walkthrough ee
Isumnery: testing
all Type:
fall Priority:D
[Terget Release:ts-I ©
fted to:€Osc
L— Live Incidents
m
stsey] S~ System Testing incidents/Defects
sting dev WD I T~ Technical query
[end of Response] IU~ Security Testing incidents/Defects
tesponse code to cal V~ Vulnerability jen Identified(38)
16-Jun-7021 10, W ~ Reference Data Service r
‘Call record hasIX_~ System Management Testing Incidents/Defects pis
#¢: 16-Jun-2021 10 Y -- Live (Non-RefData) Data Updates
velopment Cost updated? new cost Is
[stare of Response]
est 1
[End of Response]
Pending -- Incident Under Investigation
© Summary — must be written so as to be understandable by most readers. This will need more
thought when Peaks are raised. Management should amend this during weekly clean-ups
(careful to preserve links where raised in another system)
© Impact ~ tab and free form field to articulate impact, status and next steps so it is easy to
understand for anyone. This will be maintained for HDR Peaks weekly. For other Peaks it can
be as needed
‘* Business impact: [as used currently, mention how many branches are affected if
helpful]
‘* Status update: [description of current status — succinct]
+ Next action: [next action to be taken and expected date for next update]
© Collection #LiveAffectingDefect (formerly ##LiveAfectingSoftwareFault). 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”
Page I 38
Version & Last updated: See fle name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
[Ada Tncident to Collection:
éLiveAfectingDefect.
thats present on the Live system thats inconsisten__ [Publ
Ads to Collection I
© Priority — which must be validated at all times so it is accurately shown as this will affect,
reporting and decision mal
© Collections of "HDR-Fin" or “HDR -Exp” for HDR Defects
‘Note: Only one HOR-* Collection needs to be set and if both could apply then HDR-Fin should be
chosen
[Raid Tacident to Collection
[Hor-exp — Horizon Detect Review - SPM Experience [Puble] © [Addo Colecton I
HOR Sp ~ Hoon Defect Raver - SPM Exariance Pbte Fi
HORFin ~ Horizon Defect Review - Financial impact [Pub]
© POL Problem reference — using the prefix "POLPRB-" so it is obvious and also searchable
+ POL Problem Reference is a Reference field and the following screenshots shows
how to add the field:
eo ra Magra sem PCH
000
I
© Fujitsu Problem reference — using the prefix "FJPRB-" so it is obvious and also searchable
‘* Fujitsu Problem Reference is a Reference field and the following screenshots shows
how to add the field:
= = ee
_ = I
© 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. Ifit is “Yes” then an accepted
workaround is in place
‘+ Workaround is a Reference field and the following 2 screenshots show how to add
the field and set its value:
Page I 39
Version & Last updated: See fle name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
°
°
ean icicar Maigret Stem PCD
Peak Incident Management System - PCO
om oF
I fecan
aR ame a
Release Mat 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:
* "63 -- Final ~ Programme approved - No fix required” — for Peaks rejected at CBIF
+ °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
‘+ The value “30 -- Pending -- TL confirmed’ will cease to be used
Target Release — the values of “Requested For" and “Released at’ will cease to be used
Management govemance and checking is needed to ensure this is how the system is being
used ~ correcting at least weekly
‘reminder will pop up on certain changes of Peak status to remind support staff to consider
the key fields:
‘+ Events triggering presentation of the pop-up:
"The Peak Routing is changed
+ The Call Type is changed
Page I 40
Version & Last updated: See file name
Document owner: Steve Browel
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= The Response Category is changed
+ The ##LiveAffectingDefect Collection is added
= The HDR-Fin or HDR-Exp Collections are added
+ 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)?
* Doesicould 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 fields correct?
+ Is the Status (Response Category) correct?
Live Defect Management — Reporting
From 2 queries/datasets it should be possible to create views of potential Live Defects,
confirmed Live Defects, deferred Live Defects, and Peaks needing customer input
The 2 reports are:
1, Report to extract all ##LiveAffectingDefect tagged Peaks and show the columns as below
2. Report to extract all Open Peaks and show the columns as below
* The output fields for both queries are to be (at least):
Call Reference, Summary, Date Opened, Product, Product Group, Call Type, Priority,
Assigned Team, Status, Root Cause, Collections, References, TfSNow Incident, POL
SNOW Incident, Contact Name, Workaround, Business Impact, Target Release, Target
Release Type, Response Category, BIF Initial Date, BIF Completed Date, BIF Text, CBIF
Initial Date, CBIF Completed Date, CBIF Text, CBIF Proposal (exists or doesn't for now),
PTF Initial Date, PTF Completed Date, PTF Text, Development (Man Days), Cloned from,
Cloned to, Date Time Last Updated, Planned Out Live, Call Logger, Actioned Team, Date
Last Closed, Call Loggers Team, BIF_Ticked_Questions, HDR_User, HDR_Date,
BIF_User, BIF_Date, TFSBonded (1/0), Assignee, Time to Target (Days)
Actions
‘System Changes
Rename ##LiveAffectingSoftwareFault to ##LiveAffectingDefect and apply to all currently
tagged Peaks
Rename Call Type "L" to remove “/Defects" from label
New Workaround field with optional text values Yes/No
New Call Type value of "#" for Defect Identified
New HDR Collections of *HDR-Fin” and *HDR-Exp"
Updated Release Mgt tab to add BIF, CBIF and PTF fields above current list (to hold dates of
meetings and outcome summaries)
‘Amended default guidance text for the Impact text box
New Reference type of POL Problem Reference and enforce POLPRB- prefix
New File Type of *CBIF Proposal"
Removed "30 -- Pending -TL confirmed” Response Category
Page I 41
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
* Amended the descriptive text for ##Lived ffectingDefect to “Fault that is present on the Live
system that is inconsistent with the agreed design and/or service specification”
‘Added new Response Category “Cloned to create Defect Peak"
‘Added text box to ask user why they are cloning, writing the response into the start of the
clone
Added capability to setup email alerts if specific Collections are added or removed
* Added temporary reminder pop-up until the new fields and values become more embedded
values
One-Time Actions
Remove the values of “Requested For" and “Released at” from list of Target Release field
i. Root Cause values need explaining and adding to the Application Support
Strategy document
* 1 Architecture
* 6 Design - Platform Design
7 Design - High Level Design
* 8 Design - System Outline
* 13 Development - Build Scripts
* 14 Development - Code
* 15 Development - Low Level Design
* 16 Development - Reference Data
+ 21 Requirements
© 24 Cfg Mgt - Config Data Error
* 26 Integration - Build
+ 31 Test- Test interpretation
+ 82. Test- Script
* 33. Test-Data
+ 34 Test- Environment
+ 37 General - Network Change
* 38 General - Hardware Fault
* 39 General - User Knowledge
+ 40 General - User
+41 General - in Procedure
* 42 Gen- Outside Program Control
* 43 General - Operational Change
* 96 Gen- Investigation On-Going
* 97 General - 3rd Party issue
* 99 General - Unknown
‘system = no matter how trivial - for review
3. Steve Br/Steve Ba/Tariq/Adam/Graham — when the final list of Live Defects is visible,
identify policy statements and decision criteria that can be defined that sees defect Peaks
either closed or actioned where currently they seem to have stagnated
Page I 42
Version & Last updated:
cument owner Steve Browe
See file name
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
5._ Steve Br - Agree a process for CBIF Proposal creation
waiting for a slot to deploy as it is the date the fix could have been applied that is key ~ not
7. Steve Br — Investigate implications of Post Office Cloud on ways of working. Check how Live
Defects are being recorded in AWS JIRA and be sure it is aligned to this Live Defect
Management process or that an agreed alternative way of working is defined and agreed at
DENVP level
New Ways of Working
The identified fields necessary for Live Defect Management must be kept up to date.
1, Adam - Mandate weekly refreshes of Impact field for all HDR- tagged Peaks (and ideally all
#fLiveAffectingDefect tagged Peaks)
2. Steve BriAdam - Implement a management process to check the new fields and ensure they
are correctly used for the next few weeks until habits form — see Appendix A for checks
Page I 43
Version & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Stream 4—BIF, CBIF, PTF and HDR
© Team ~ Steve Bansal, Sandie Bothick, Adam Woodley, Tariq Arain, Matt Swain, Tomi
Okelola, James Guy — plus cascade to all 3LS, 4LS, and Architects
BIF
© BIF isa Fujitsu intemal meeting
© When a Developer is ready for BIF to consider their proposal then they must
* Set BIF Action flag on the relevant Peak
+ Ifthe Peak
= 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
* Add the ##LiveAffectingDefect Collection
= Ifthe cause and required action to remedy are:
‘* Still being investigated — then set the Call Type to "L”
* Are confirmed ~ set the Call Type to “#” and also update:
© Root Cause field is up to date
——_ Peak Im
TPewnsss
TNGX Ral ia
C Caredeat ara yeccomes TOS
F Docaer ReviewOegn Waktous es
Tr 307 1a G GDC Teng nce Doce
ALL PCODOSN4 ope bea Development ndertsDelecs
on reneitied 20)
yg as Cetegr 40 Pending <= tack der Ist geon
= Ensure Workaround field is up to date
= Ensure Product Group field is up to date
= Ensure Product field is up to date
"Ensure Priority field is up to date
+ Ensure Impact field is up to date
© All Peaks with the BIF Action flag set will be reviewed at BIF
Page I 44
Version & Last updated: See file name
Document owner: Steve Browel
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
‘* This will include all defects Peaks with the ##LiveAffectingDefect tag
‘+ Itwill also include other Peaks that may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
© Ifa 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
© BIF must consider the proposal (as it does currently) and also validate the following data
values for defect Peaks:
+ Ifthe Peak:
+ 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
= Ensure the ###LiveAffectingDefect Collection is set
"If the cause and required action to remedy are:
* Still being investigated ~ then set the Call Type to "L"
* Are confirmed — set the Calll Type to “#” and also update:
© Root Cause field is up to date
Peak In
DETAILS
[Pco29s2a1
[Reported In HNG-X Rel Ind
[0 — Operational (SSC) 7]
por eve a
fe Clned ct rake etnwTOATSI
E ~ Enhancement Request ——
F Dacian ReviwrDesgn Watough ==
{6 GDC Testing ndens/Detecs
I Intmal Development incidents Detects
ic rmarh
ie dnt
11 Proto Management
}0~ Operational S80)
Sine dee nb I T— Technical query
End of Response] IU~Secutly Testing IncidentsDefects
response code to cal V~ Vulnerability Jen Identified(28)
IW Reference Data Service
The nae] X-- System Management Testing IncdentsiDefects pis
ste: Y= Live (Non-ReData) Data Updates 5
Jpevelopment Cost updated? new con
['store of Responce)
et 2
[[End of Response]
response cove to call type Lae Category 40 -- Pending -~ Incident Under Investigation
f:46-Dun-2021 10:51:08 User! John Sinoking
Be ee
[
"Ensure Workaround field is up to date
= Ensure Product Group field is up to date
= Ensure Product field is up to date
= Ensure Priority field is up to date
Page I 45
Version & Last updated: See fle name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
= Ensure Impact field is up to date
* Check if the new HDR Collections of “HDR-Fin” or “HDR-Exp” should apply. If
it needs applying then the chair must alert Steve Bansal, Adam Woodley and
Sandie Bothick. If the issue in the Peak:
* Affects, or has the potential to affect, branch financial outcomes, add
the HDR-Fin Collection
+ Affects, or has the potential to affect, the way a postmaster is,
required to use the system (User Interface, Report, Function), add
the HDR-Exp Collection
* Affects, or has the potential to affect, the experience of a Post Office
customer or client, add the HDR-Exp Collection
‘Note: Only one HDR-* Collection needs to be set and if both could apply then HDR-
Fin should be chosen
[Ridinsane Coleco
[Fores —Honson Detect Reva SPU Expnce (Pubi] I [ade Cotas
HOR Exp ~ Horizon Defoe Revi - SPM Exosrinco [Publ
HOR Far Haraon Detect Review - Prac pec ube.
"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
(0 The fix can be done in more than one way and POL would need to
guide Fujitsu on choosing the preferred option.
(1 The fix may change the functionality of the system and consequently
POL will be required to provide appropriate communication, and
potentially training, to the subpost masters.
(1 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.
[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.
(0 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).
(0 Fujitsu does not believe a fix is a sensible option and seeks POL’s
agreement to record the circumstances in a KBA only.
"Note: The forecast Development (ManDays) will no longer be a deciding
factor for submission to CBIF
© The BIF chair must record, in Peak on the Release Mgt tab, what decisions are made:
Page I 46
Version & Last updated: See file name
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
+ The new BIF date fields (Initial and Completed) will need to 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 the Peak was first 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
‘+ 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. No need for separate BIF minutes
* Ifthe Peak is approved at BIF then the BIFApproved Collection must be added (also
for BIFRejected)
(adie Cotlesion 4
I Gare Satie Cabcion I
‘+ 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
‘+ Ifthe Peak does not need to go to CBIF then the PTF Action flag will be set
© The definition of BIF in the contract ASM schedule needs to be updated
Page I 47
Version & Last updated: See fe name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
© CBIF is a joint meeting with POL
© CBIF will continue to exist and it will be merged with the
HOR Forum _ =
© CBIF will evolve to being more system driven (more
explanation below)
© Items to be discussed at CBIF must have a “CBIF —_—_—_——
Proposal’ that has been created in advance using the
agreed template (see right) and approval process so it
is clear that this is what the decision needs to be made
‘on (not additional dialogue during a meeting)
© Peaks to be discussed at CBIF are determined by Peak enn
data items so it is system driven. See CBIF Submission
Extract Criteria below for the system value that will
determine CBIF applicability
© Peaks required to go to CBIF will be identifiable via
system query and report and will be shared in advance
with POL so that the meeting can focus on the decision
not the familiarisation
If we need to invite an SME to elaborate (only for exceptional submissions) then the
‘SME will be invited. If the submission text is well worded then SME attendance
should not be required — as is currently the case when CWOs are approved
© The CBIF representative must record, in Peak on the Release Mgt tab (but not in the
presence of POL), what decisions are made:
Page I 48
The new CBIF date fields (Initial and Completed) will need to 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 CBIF the Peak was first 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
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. No need for separate in CBIF
minutes
If the Peak needs to go back to the Developer then it should be assigned to the
Developer team
Version & Last See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
‘* If the Peak can proceed as discussed then the PTF Action flag will be set
‘* Ifthe 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 and this will cause the
Peak to reappear on the weekly report
* CBIF rejections must get a POL reference which we add to the Peak and also to the
KBA so we know this was a POL decision. The Peak is then closed with Response
Category “63 -- Final - Programme approved - No fix required”
© There will need to be a weekly report seen by management of what is to be presented at
CBIF, and what the status is of open CBIF items and POL decisions
© There is no definition of CBIF in the contract - it says BIF — this needs to be addressed
Refer to Appendix E for instructions on how to determine if there are any CBIF candidates to report to
POL.
PIF
© PTF isa Fujitsu internal meeting
© All Peaks with the PTF Action flag set will be reviewed at BIF
‘+ This will include all defect Peaks with the ##LiveAffectingDefect tag
+ Itwill also include other Peaks that may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
©. Ifa Peak needs to be re-presented at PTF then it will have the PTF Action flag set again
© 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:
+ The new 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 the Peak was first 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
‘+ 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. No need for separate in PTF
minutes
Page I 49
Version & Last updated: See file name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
HDR
© There is an updated Terms of Reference (currently v2.2) but it has yet to be presented for
sign off. CBIF will need adding at some stage once Fujitsu are ready with the internal CBIF
processes
© Overview of the process
* Fujitsu takes new items as Incidents to HDR not KBAs or Peaks
‘* Fujitsu must ask POL for their Problem reference so it can be added to the Fujitsu
Incident (and any related Peaks) so we have the POL reference
‘* Fujitsu embeds any relevant KBA or Peak content into the Incident it shares
‘+ Fujitsu tags its Incidents and Peaks with the applicable HDR-* Cl or Collection tags
‘+ Fujitsu does not reference its KBAs (and does not share them with POL in their native
form)
‘+ The only Peak reference is the defect Peak reference Fujitsu raises when the cause
is known and a fix is to be taken through the fixing process. Fujitsu will close the
investigation Peak and the linked Incident as the confirmed defect Peak reference will
be the one that will be managed from this point
‘+ Ifa KBA, or internal Peak, is created that identifies a condition that meets the
definition of HDR Defect then Fujitsu raises an Incident by contacting Fujitsu MAC
with the relevant KBA content in it and Fujitsu MAC bonds the Incident and alerts
POL
‘+ Updates on potential Live Defects is provided via bonded Incident updates
‘+ Updates on confirmed Live Defects is provided by defect Peak weekly reports
‘* The above ensure POL has visibility at all times either from their ServiceNow Incident
or by maintaining their ServiceNow Problem record (POL will need to transpose data
from the weekly Fujitsu reports into its Problem records)
* As this is an early warming forum too, we will also issue an email alert to the Fujitsu
Duty Manager distribution list and a POL distribution list to alert interested parties
© Summary
‘* Potential HDR Defects will be reported automatically to POL via the service
management toolset replication driven by Fujitsu updates to the TfSNow Incident
‘* 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
‘* New CBIF content will be shared with POL on a weekly report from Peak that will
include the proposal and will be sent to POL in advance of the meeting
‘+ Updates to CBIF content will be shared with POL weekly by a extract report from
Peak that will be sent to POL in advance of the meeting showing the latest update
© The Incident will be worked by Fujitsu if it is within the Fujitsu scope of obligations — otherwise
it will be passed to POL ITDSD to assign to the relevant POL third party
© POLwill probably convert the ServiceNow Incident to a ServiceNow Problem — but that is
their choice
© 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. The defect
Peak will be closed with Response Category “95 -- Final - Advice after Investigation” to say
the HDR Defect was not confirmed
© For the purposes of Live Defect Management, Fujitsu will use Peak references not TTSNow
Problem references
© Fujitsu will provide its view of status — from its systems — and manage any difference of
opinion with POL
© Fujitsu will provide weekly updates prior to the meeting
Page I 50
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Refer to Appent
* Potential HDR Defects — no action required as the updates will already be in POL
ServiceNow
* Confirmed and deferred HDR Defects — by sharing the latest update on the defect
Peak we are managing our side in the form of a report.
‘+ CBIF new Live Defects — for decision by sharing the pro-forma proposal in a report
and inviting a decision
© Note: Any reports will be checked and sent in advance of the HDR Forum so POL can add it to
their Problem record and ensure they are ready to provide a decision to the CBIF new Live
Defects
The HDR Forum needs to evolve away from a “talking shop” to one of quick facts that
demonstrate systematic control and confidence. Fujitsu should reduce the number of
attendees
IF POL need more information, the Fujitsu Incident, Peak or Problem owner is tasked to get it
and add it to our system — or we get the CBIF proposal updated for resubmission, The new
information must be added to the system
POL need to hold the Fujitsu Incident or defect Peak reference in their Problem record so
they know what to ask us for an update on — and what to apply our report updates to in their
system
The HDR minutes need an overhaul for Fujitsu. This is the Fujitsu specific meeting and yet i
lists numerous Live Defects that are not related to Fujitsu and the minutes are sprawling and
hard to follow. POL will be advised that:
+ They need to make it clear which HDR Defects are within Fujitsu's scope of
obligations
+ They need to show the Fujitsu Live Defect reference (ServiceNow/TISNow Incident or
defect Peak)
+ They need to show Fujitsu's latest update
‘+ Asummary view at the top is needed - New, Open, Closed, by Severity, by area
affected, and trend
Any ad-hoc calls should only be required when the next scheduled meeting is too far away.
Updates from Fujitsu must come from the Incident update or defect Peak report with any
additional comments made during the meeting being added to the Incident or defect Peak
There is no definition of HDR in the contract — this needs to be addressed
D for instructions on how to create the weekly HDR Report for POL.
B— Info only
The Fujitsu KB is an information repository used for support purposes
Any observed Live Defects will be recorded as a KBA but the progress to investigate and
address them will be done via Peak(s) and Incident(s)
KBAs do not need to be shared with POL as the tracking needs to be on the Peak and
Incident raised to progress them
If the awareness or involvement of POL is applicable then there will be a TfSNow bonded
Incident and this will contain all relevant parts of any KBA so that the Incident that POL see is
a suitable complete reference
If POL accept a Live Defect ~ namely decide that no action is required — then the KBA will be
updated accordingly and will have the POL applicable reference added so it is clear that it
was not fixed by POL decision. This is a contract responsibility on POL to record these and
issue Fujitsu with a notification
Page I 51
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Release Mgt tab — for BIF, CBIF and PTF
Page I 52
Version & Last updated: See file name
Document owner: Steve Browell
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
CBIF / HDR Diagram
Incident — Peak — Defect — HDR — CBIF
Potential Defect Investigation Peak Confirmed Defect
{iovestigation) Fujitsu Internal Fujitsu Internal
Fujitsu Reports
POL Incident HDR/CBIF, or
[ServiceNow]
Continuous Improvement
+ Ifit isa Live Defect then
add the
LiveAffectingDefect Cl
If itis a HOR Incident
then add relevant Ci
* Updates auto replicate
* POL rely on ServiceNow
All should be Call Type “#”
All should have the Collection
iiLiveAffectingDefect
IFHDR then relevant Collection should be
added
Updates do not auto replicate
Updates are system driven by reports:
[Call Type “U"] [Call Type changed 1. Live Defects with the HDR Collection ~
to "# for the HDR meeting
a 2. CBIF qualifying Peaks ~ for the HDR
meeting
3. Live Defects excluding the HDR
Collection ~ reported (TBC) under
Continuous Improvement
4, Deferred Defect Peaks — for
Information and tracking
Fujitsu Incident
[TFSI
If POL notification
needed
Page I 53
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Actions
System Changes
© CBIF reason criteria added to the Release Mgt tab
One-Time Actions
© HDR
3. Steve Br — look at how HDR should be referenced in the contract documents
Page I 54
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Appendix A— Peak data anomaly checks,
To ensure the data in Peak remains consistent with the intentions of the changes within this
document, managers will need to conduct manual checks. Those checks should cover at least the
following. Expanded checklists should be created within each team. The POA Defect Manager will
also need to do this at a cross-function level.
The checks relate to Peaks that have had, or probably should have, the ##LiveAffectingDefect
Collection added.
Data Consistency & Accuracy.
1.
[ALL POA Managers] Any manager or senior manager on POA should ensure they have a
process to review all of the areas under their control to determine that progress is appropriate —
whether related to TTSNow or Peak, Live Defects need active management and it cannot be left
to individuals, escalations and exception management
2. [ALL Team Managers] Does the ###LiveAffectingDefect Collection need setting on any Peaks in
your area
3. [ALL Team Managers] Does a HDR-* Collection need setting on any Peaks in your area
4, [ALL Team Managers] If the ##Lived ffectingDefect Collection is set, is it (still) correct?
5. [ALL Team Managers] If the ##LiveAffectingDefect is set then is progress to an outcome going
as quickly as it could?
6. [ALL Team Managers] All Peaks with a HDR-* Collection must have a well worded Impact
update
7. [ALL Team Managers] Any Peaks that have both HDR-* Collections set should retain the HDR-
Fin Collection as this is more important to POL and HDR-Exp. A Peak should only have one
HDR-* Collection
8. [ALL Team Managers] If a Workaround is in place for a Peak then the Workaround Reference
field must have the value “Yes”
9. [ALL Team Managers] Irrespective of any Peak settings, is progress being made as quickly as
possible?
10. [ALL Team Managers] Any delay in making progress on Peaks due to other priorities e.g
projects or changes must be raised to the next level of management as Live service should
always be the priority
11, [ALL Team Managers] Peaks that have the following No Fault Found Response Category
‘outcome should be checked to ensure this is the right Response Category and also Closed as a
conclusion has been reached with no ‘fix’ action required by Fujitsu:
Response Category — 62 ~- Final — No fault in product
Response Category — 63 — Final — Programme Approved — No Fix Required
Response Category — 66 -- Final — Enhancement Request
Response Category — 68 ~ Final — Administrative Response
Response Category — 94 — Final — Advice and guidance given
Response Category — 95 — Final — Advice after Investigation
Response Category — 96 ~ Final — insufficient evidence
Response Category — 97 — Final — Unspecified insufficient evidence
Response Category — 98 ~ Final — User error
Response Category ~ 100 ~ Final ~ Route call to T1S
Response Category — 120 — Final - Cloned to create Defect Peak
Page I 55
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
Commented [BS4]: Generate error checking reporting ~
filter by Assigned Team or Call Logger
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Response Category ~ 200 ~ Final — Call withdrawn by user
Note: The Response Category must be changed if this is not a No Fault Found outcome
12, [ALL Team Managers] Peaks closed as Administrative Response should be checked as this is
sometimes a default selection. If it is wrong e.g. as it was in fact a software fix that was
deployed, then the Peak will need to be re-opened and correctly updated before being closed
again
13, [All Team Managers] Peaks with the ##LiveAffectingDefect Collection should be Call Type L or
#, Where they are not, the Call Type should be challenged and changed
* This can exclude Peaks where the Planned Out Live (Date Out Live field on Peak
screens) is in the past and the ‘fix’ has been deployed
+ These Peaks can be closed if they have a No Fault Found Response Category as
this shows they were subsequently determined to require no action by Fujitsu
14. [All Team Managers] These Response Categories with the following field values should be Call
Type “#” as they explicitly state there is a Live Defect to ‘fix’
Response Category ~ 41 -~- Pending -- Product Error Diagnosed
Response Category — 42 — Pending -- Documentation Error Diagnosed
Note: The Response Category must be changed if this is not a confirmed Live Defect
16. [All Team Managers] Peaks where the Call Logger starts with "Deleted User” or is blank need
the Call Logger Team oversight as the referenced Call Logger has left the system and hence
the Peak may be orphaned
‘* This can exclude Peaks where the Planned Out Live (Date Out Live field on Peak
screens) is in the past and the ‘fix’ has been deployed
[All Team Managers] Peaks need to accurately state the Product and Product Group as this will
be used to identify the system components to which Live Defects are associated
[ALL Team Managers] Peaks that have been set to Status “F” (Final) should be deployed fixes
awaiting closure. If they are not deployed then the status should be changed to a “P” status. If
they are Status F then the Call Logger or Call Logger Team manager should ensure these are
closed
18. [ALL Team Managers] The Summary field should be as clear as it possible and all updates
added to show progress should be clearly understandable by any reader
19. [ALL Team Managers] The Root Cause on any Peak should be maintained and it should be
checked carefully when being changed from Status “F” to Status °C”
20. [ALL Team Managers] Any Peaks that have a confirmed cause and req
Call Type changed to “#”
[All Team Managers] Any Peaks that are Call Type “#" can be bonded to T'SNow Incidents but
NOT if the TfSNow Incident is also bonded to POL ServiceNow. Peaks that are Call Type “#”
must be cloned to break the automatic replication with POL ServiceNow bonded Incidents
22. [Release Management] The key fields on any Peaks presented at BIF, CBIF or PTF must be
checked and amended accordingly
[Release Management] Peaks with release set to “Re-target” should have the PTF Action
automatically set
[Release Management] Check that Peaks that have the CBIF flags set do not have the PTF
action set until CBIF has been updated (catch the accidental setting of PTF Action after BIF but
before CBIF decision provided)
[Release Management] All Peaks with Planned Out Live (Date Out Live field on Peak screens)
in the past should be Closed. The ‘ix’ has been deployed. If they are Status F then the Call
Logger or Call Logger Team manager should ensure these are closed
26. [Release Management] All Peaks where the Planned Out Live (Date Out Live field on Peak
screens) is blank or in the future should not be Closed as the ‘fix’ has not yet been deployed
© These Peaks can be closed if they have a No Fault Found Response Category as
this shows they were subsequently determined to require no action by Fujitsu
1
3
1
a fix must have the
8
23.
2
BS
25.
Page I 56
Version & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
27.
2
8
3
3
8
33.
34.
3
36.
37.
I
3
8
a.
[Release Management] All Peaks with Target Release Type of “Targeted At” are Release
Management responsibility to drive to deployment demanding action from other teams as
needed to ensure timely progress
[Release Management] When a Peak is discussed for the first time at a BIF, CBIF or PTF
meeting then the applicable Planned Date and Actual Date should be set to the same date. If
the Peak is re-presented at any of these meetings then the Actual Date should change to the
date they were reviewed. Suitable comments should be added to the relevant section and
updates should be appended to maintain a log
[Release Management] If a Peak is approved at BIF then it must have the "BIFApproved”
Collection added and the BIF Action removed
[Release Management] If a Peak is approved at BIF and does not need to go to CBIF then it
must have the PTF Action set and the BIF Action removed
[Release Management] If a Peak is rejected at BIF then it is expected that the Peak will be
closed with an appropriate update. The Peak must have the “BIFRejected” Collection added
and the BIF Action removed
[Release Management] If a Peak is not approved at BIF (and not rejected) then the BIF Action
should remain so the Peak is picked up at the next BIF meeting
[Release Management] If a Peak is targeted at PTF then the PTF Action should be removed
[Release Management] If a Peak is not targeted at PTF then the PTF Action should remain so
the Peak is picked up at the next PTF meeting
[Release Management] The BIF Action should only be removed if BIF approves or rejects a
Peak
[Release Management] The Root Cause on any Peak should be maintained and it should be
checked carefully when being targeted and prepared for release to live
[Business Development] Any Peaks with the Collection "Deferral Agreed” should be Call Type
"#" unless the defect needs further investigation in which case it is Call Type "L”
‘* Deferred Peaks must have the ##LiveAffectingDefect Collection added once the
release they relate to is deployed
‘+ This can exclude Peaks where the Planned Out Live (Date Out Live field on Peak
screens) is in the past and the ‘fix’ has been deployed
[ALL Dev Teams] When a Live Defect is confirmed, if the Peak is bonded to TISNow and POL
‘ServiceNow then it must be cloned. The clone reference is to be added to the original Peak and
the original Peak closed with the Response Category “Cloned to create defect Peak’. If the
Peak is not bonded to TfSNow and POL ServiceNow then it can just have the Call Type
changed to "#"
[ALL Dev Teams] When a Live Defect is confirmed and the Call Type is changed to “#" the BIFI
Action must be set as soon possible so that the Peak moves quickly towards being targeted
[SSC] Peaks containing the HDR Collection that:
‘+ Are not Calll Type "#"
* Do not the Planned Out Live (Date Out Live field on Peak screens) in the past as the
‘fix’ has been deployed
* Are not closed as they had a No Fault Found Response Category
* And were not Deferred
must have a T'SNow and a ServiceNow Incident reference as they are under active
investigation and affect a POL branch so POL must be aware through the service management
toolsets
[SSC] Peaks containing the HDR Collection that are Call Type "#" may have a TISNow and a
ServiceNow Incident reference but they should not be linked to TfSNow. If they are, they need
to be cloned as they are investigation Peaks. The investigation Peak needs to be closed with
the defect Peak reference added. These will also include defect Peaks that originated from an
Incident raised within Fujitsu which POL did not need to be made aware of
Process Consistency & Rigour
Page I 57
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
[Release Management] Peaks that are Defect Identified that are Priority A or B or have a HDR-*
Collection must get an urgent BIF/PTF review to be assigned a Release as well as a Release
Date. A hot-fix must also be proposed for POA/POL management decision
[Release Management] Peaks that are Call Type "# - Defect Identified” but have not yet been to
BIF (BIF action not yet set and BIFApproved not in Collection) then action is needed unless
they are scheduled for the next BIF meeting
* This can exclude Peaks where the Planned Out Live (Date Out Live field on Peak
screens) is in the past and the ‘fix’ has been deployed
+ This can exclude Peaks that are Targeted At as they may have been handled prior to
the new processes
+ These Peaks can be closed if they have a No Fault Found Response Category as
this shows they were subsequently determined to require no action by Fujitsu
[Release Management] Targeted At Peaks should be Call Type "#" as the Defect is identified,
This should have been caught at BIF and/or PTF
+ This can exclude Peaks where the Planned Out Live (Date Out Live field on Peak
screens) is in the past and the ‘ix’ has been deployed
+ These Peaks can be closed if they have a No Fault Found Response Category as
this shows they were subsequently determined to require no action by Fujitsu
[Release Management] Peaks that are identified as “Re-target” should have the PTF action set
to force the continued discussion so a next step is clear
[Release Management] Targeted At and Proposed For - where Planned Out Live (Date Out Live
field on Peak screens) is blank or in the future should be Open (O or P) and not Closed (F or
C). Although F is still technically open, the Call Logger may deem it acceptable to close it
prematurely — hence Status F should be avoided
[Release Management] Where release numbers are referenced in Target Releases, a date for
the release should be added and reasons why no date can be assigned should be challenged
[Release Management] We need to highlight where the Target Release is ‘Rel. Ind.’ or ‘Next
Counter Release’ — perhaps with POL so they share our enthusiasm to schedule and fix - and in
so doing we keep momentum
[Release Management] If a Peak has been to BIF it needs to have the BIFApproved or
BIFRejected collection added. If not then it should have the BIF Action flag set as it is to be re-
presented
[All] Managers/Team Leaders must check for Peaks that have been cloned to ensure the
reasons match the conditions agreed. If they do not, then appropriate action must be taken
(update the cloning rules, remove the clone, ensure the reason for cloning is captured on the
‘master Peak and that the purpose of the new clone is captured in the cloned Peak)
Page I 58
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
heckel ‘Commented [BS5]: Generate error checking reporting —
filter by Assigned Team or Cal Logger
To ensure the data in TfSNow remains consistent with the intentions of the changes within this, _— ee
document, managers will need to conduct manual checks. Those checks should cover at least the [Commented [BS6): Create per manager checklist )
following. Expanded checklists should be created within each team. The POA Defect Manager will
also need to do this at a cross-function level.
The checks relate to TISNow Incidents that have had the ##LiveAffectingDefect or any HDR-*
Configuration Items added.
Data Consistency & Accuracy.
* [Defect Manager] Check TfSNow Incidents ...
Page I 59
Version & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix C — draft criteria for closing defect Peaks with NO action
There will always be Live Defects that experience and judgement says are simply not worth fixing. To
ensure this is a matter of policy and not one of subjective decision making, criteria is needed that staff
can use to make decisions.
The following is an
ial draft to build upon.
A fix for a Live Defect will NOT be progressed if at least THREE of the following conditions apply:
(1 The frequency of occurrence of the Live Defect is rare — less than TWICE per annum
The impact of the Live Defect is minor — it does NOT affect branch operations or Fujitsu
service delivery
(1 The impact of the Live Defect only affects Fujitsu service delivery — and Fujitsu has
‘compensating controls in place and Fujitsu management has agreed to taking no action
The impact of the Live Defect is accepted by POL ~ and a KBA has been created by both
Fujitsu and POL clearly stating the decision and the decision maker
The Live Defect is in a part of the system that will be decommissioned before any fix could be
developed and deployed
(1 The Live Defect relates to Fujitsu internal documentation only and the remedy will not affect
the understanding or support of the system by Fujitsu
Live Defects recorded in Jira’s that meet the above criteria do not need to be raised as Peaks as
doing so would simply see the Peaks immediately closed. A Jira that describes a Live Defect that
would warrant a KBA must have a KBA written to help future support activities,
Page I 60
Version & Last updated: See file name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix D - HDR Report Creation Work Instructions
To create the weekly HDR Report which is shared with POL, follow these steps:
As at the date of this document, the criteria to be used to determine HDR reporting
candidates to share with POL will be determined by creating 3 lists using the following logic.
The resulting lists will then be merged and the HDR candidates identified.
© Aspreadsheet format has been used to date so the previous week's submission should be
used as the basis for the new report ~ removing all previous week highlighting and deleting
rows scored out as POL have been told these are being removed
© Filter on these values first
Must have the ##LiveAffectingDefect Collection (relates to the Live system and does,
or might, need a fix)
Must have the either the HDR-Fin or HDR-Exp Collection (Collections contains HDR)
Must have a Planned Out Date in the future or blank (ithas not been deployed)
Must not have the Response Category set to any of these values as these are No
Fault Found
Response Category ~ 62 ~ Final - No fault in product
Response Category ~ 63 — Final -- Programme Approved — No Fix Required
Response Category ~ 66 — Final ~ Enhancement Request
Response Category ~ 68 — Final - Administrative Response
Response Category ~ 94 — Final - Advice and guidance given
Response Category — 95 — Final — Advice after investigation
Response Category ~ 96 — Final - Insufficient evidence
Response Category - 97 — Final - Unspecified insufficient evidence
Response Category — 98 — Final — User error
Response Category — 100 — Final — Route call to TFS
Response Category — 120 — Final — Cloned to create Defect Peak
Response Category — 200 — Final — Call withdrawn by user
© List 1 — Deferred Live Defect Peaks
Page I 61
Must also have the Collection “Deferral Agreed”
These are unlikely to be discussed at HDR as they are previously approved and
understood but are provided to show the level of Fujitsu control
Extract the list showing:
"Category (HDR-Fin = Impact, HDR-Exp = Experience)
© Sorton this field
= POL Reference (N/A at this time)
* Fujitsu Reference (the Peak Call reference)
* Sort on this field too
= Summary
= Confirmed Defect (Call Type is # = Yes, otherwise No)
= Workaround
Version & Last updated: See file name
cument owner Steve Browe
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
+ Compare the previous HDR report to the new list and amend accordingly so the new
HDR report list matches what the system now shows
= Any that have been closed should be scored out and hi
lighted in yellow
"Any that are new should be added to the relevant Impact or Experience
section and highlighted in yellow
© Next Lists ~ non-Deferred Peaks
* Must NOT have the Colle:
‘+ List 2— Project Live Defects
"If clearly from a Project that is under a controlled rollout where the Fujitsu and
POL Project Managers are working together (e.g. PBS — identifiable by the
use of "PBS" or “PITPOS' { which is an Ingenico Jira reference}, or other
identifiable text)
+ Summary contains “PBS or contains “PITPOS"
= There may be none
+ These are unlikely to be discussed at HDR as they are part of the ongoing
Project Manager regular review calls
"Extract the list showing
© Category (HDR-Fin = Impact, HDR-Exp = Experience)
© Sorton this field
n “Deferral Agreed”
* POL Reference (N/A at this time)
‘* Fujitsu Reference (the Peak Call reference for Call Type #, otherwise
the TfSNow/ServiceNow Incident reference)
© Sort on this field too
+ Summary
* Confirmed Defect (Call Type is # = Yes, otherwise No)
© Workaround
Compare the previous HDR report to the new list and amend accordingly so
the new HDR report list matches what the system now shows
‘+ Any that have been closed should be scored out and highlighted in
yellow
* Any that are new should be added to the relevant Impact or
Experience section and highlighted in yellow
* List 3 -non-Project Live Defects (likely originating from an Incident during normal
service delivery)
= These require more comprehensive information as these will be discussed at
the HDR meeting
= Having reached this point there will be a small number of entries left
+ This needs cross-referencing to the previous week's submission to check if
anything is new or if anything has disappeared. This will need manual
checking for confidence
= Some may still be under investigation. They will have a Call Type of “Live
Incident” and will have TfSNow/ServiceNow Incident references. For these,
the Fujitsu Update should be “See TISNow/ServiceNow Incident update” as
this is where the latest status should be recorded
Page I 62
Version & Last updated: See fle name
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
= Some may relate to Fujitsu Problems. The Collections should contain
“FJPRB-". For these, the Fujitsu Update should be the latest entry in the
relevant Fujitsu Problem record in TISNow
"The remainder should have the Call Type “Defect Identified". For these, the
Fujitsu Update should be derived from the Business Impact field which will
need to be checked and improved if necessary
+ Extract the list showing
* Category (HDR-Fin = Impact, HDR-Exp = Experience)
© Sorton this field
* POL Reference (this should be known unless the entry is new)
‘+ Fujitsu Reference (the Peak Call reference for Call Type #, otherwise
the TfSNow/ServiceNow Incident or Problem reference)
© Sort on this field too
+ Summary
* Confirmed Defect (Call Type is # = Yes, otherwise No)
+ Workaround
‘* Business Impact (See Incident, latest Problem record update, or
Business Impact field)
je I
* Compare the previous HDR report to the new list and amend accordingly so the new
HDR report list matches what the system now shows
"Any that have been closed should be scored out and highlighted in yellow
= Any that are new should be added to the relevant Impact or Experience
section and highlighted in red
‘+ These then need scrutiny to ensure they look correctly tagged as
HDR and that the Impact is accurate. If they are HDR then the
required fields for the HDR report need to be checked with SMEs and
ALS chased for updates. These red entries are the ones reviewed by
the Fujitsu HDR meeting attendees prior to the HDR report being
submitted
+ When the report is ready to submit, the highlighting should be
changed to yellow
= Any existing entries that remain on the list should be checked for updates to
the Impact statement and, if progressing from Live Incident to Defect
Confirmed, to amend the reference from a TFSNow Incident to the Defect
Peak reference
‘+The far right column “Change from last week” should be used to say what has
changed so it is clear where to look and why
Page I 63
Version & Last updated: See file name
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL ~ INTERNAL USE ONLY (POA ONLY)
Appendix E - CBIF Submission Extract Work Instructions
To identify if there are any CBIF submission necessary to POL, follow these steps:
© Asatthe date of this document, the criteria to be used to determine CBIF candidates to share
with POL will be determined by creating 3 lists using the following logic. The resulting lists will
then be merged and the CBIF candidates identified. A CBIF Proposal will then be needed as.
this is what will be submitted to POL.
© Filter on these values first:
Must have the ##LiveAffectingDefect tag (relates to the Live system and does, or
might, need a fix)
Must be Calll Type "#" (a fix is needed)
Must have a Planned Out Date in the future or blank (it has not been deployed)
Must not be Targeted At as this means it has gone through PTF already
Must not have a HDR Collection (or it has been to HDR anyway)
Must not have the BIF action set (it needs further discussion at BIF)
Must not have the PTF action set (it has gone past CBIF)
Must not have PTF dates (it has gone past CBIF)
Must not have the Response Category set to any of these values as these are No
Fault Found:
Response Category ~ 62 — Final ~No fault in product
Response Category ~ 63 ~ Final ~ Programme Approved ~ No Fix Required
Response Category ~ 66 — Final ~ Enhancement Request,
Response Category - 68 — Final ~ Administrative Response
Response Category - 94 ~ Final-- Advice and guidance given
Response Category — 95 — Final — Advice after Investigation I
Response Category — 96 ~ Final — Insufficient evidence I
Response Category - 97 ~ Final ~- Unspecified insufficient evidence
Response Category ~ 98 ~ Final ~ User error
Response Category ~ 100 — Final ~ Route call to TIS
Response Category ~ 120 ~ Final ~ Cloned to create Defect Peak
Response Category ~ 200 ~ Final ~ Call withdrawn by user
© Then, in tum, check these filters to build the 3 lists:
* List 1 — high priority Live Defects:
"= Must be Priority A or B (highest impact defects)
‘* List 2 Live Defects that originated from a POL ServiceNow bonded Incident:
= Must have a POL SNOW Reference
* List 3 - Live Defects explicitly identified at BIF for taking to CBIF:
"Must have a CBIF Criteria checked marker ~ BIF_Ticked_Questions is not
blank (BIF selected it for CBIF)
Page I 64
Version & Last updated:
cument owner Steve Browe
See file name
FUJ00232748
FUJ00232748
FUJ00232748
FUJ00232748
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Page I 65