FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Changes in v1.2
Changed the word ‘ticket’ to a correct defined term where unclear
Updated the CBIF selection criteria to include BIF explicitly tagged Peaks
Added references to using the BIFApproved and BIFRejected Collections
Applied emphasis that defect Peaks can only be closed when the fix is released to live
Updated Appendix A to add steps to challenge “Re-target” and force to PTF
Inserted Appendix B to add anomaly checks for TfSNow
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 testsystem but if it 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 Peakto 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
HDR-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. Updated Actions, removing ones completed
NOAPona
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 bef
delve into the detail
3. Added screenshots and diagrams to aid understanding
Page I 1
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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 (Customer visible)” field in TFSNow
Added criteria currently being used to derive content for CBIF and HDR
10. Added Appendix A to show some data validation checks that certain teams are advised to
build in to and expand upon within their own local processes
41. Added Appendix B to show draft criteria for not acting on defects — the potential policy we will
write to remove any subjectivity from decisions to close defect Peaks or nof@pen Peaks from
Jiras . y
12. Updated Actions
Page I 2
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Contents
New term
Investigation Peaks becoming Defect Peaks..
New fields in Peak...
New field values in Peak.
New field values in Peak..........-.:0004
Renewed importance for Peak fields.
TfSNow Incident needed for things POL should know.
New field values in TfSNow..
Renewed importance TfSNow fields....
BIF...
CBIF...
PTF.....
HDR.
Introduction & Overview.
The Goal.....
Purpose & Scope.
The Streams...
Terminology — Overview...
Stream 1 — Incident & Problem (lifiks to Peak, Key Meetings & Live Defect ManagementI
Managing Incidents...
Managing Problems...
Actions...
System Changes.
One-Time Actions.
New Ways of Working
Stream 2 — Use of Peak (3LS, 4LS & Release).
Peak...
Release.....
Actions.......
System Changes.
Time Actions...
Page I 3
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
New Ways of Working......
Stream 3 — Live Defect Management...
Live Defect Management — Live Defect Definition........
Live Defect Management — Goals.
Live Defect Management — Key Fields in Peal
Live Defect Management — Reporting..
Actions...
System Changes.
One-Time Actions...........0+
New Ways of Working......
Stream 4 -BIF, CBIF, PTF and HDR........
BIF..
CBIF...
CBIF Submission Extract Criteria
PTF...
HDR.
HDR Submission Extract Criteria.
KB — Info only....
Release Mgt tab — for BIF, CBIF and PTF...
CBIF / HDR Diagram...
Actions.......
System Change:
One-Time Actions...
New Ways of Working...
Appendix A — Peak data anomaly checks.
Appendix B — TfSNow data anomaly checks
Appendix C — draft criteria for closing defect Peaks with NO action.
Page I 4
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
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)
(Fujitsu Restricted - 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.
Page I5
Version & Last updated: See file name
Document owner: Steve Browell
FU,
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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.
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)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 POkto 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:to a TfSNow 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) — isa 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 TfSNow 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 well as the
differences between Investigation Peaks and Defect Peaks:
Page I6
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232729
1J00232729
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Incident — Peak — Defect
Potential Defect Investigation Peak Confirmed Defect
Investigation! Fujitsu Internal
Bonded, updates I
replies I
+ Updates auto replicate "I
+ Updates donot show I I
+ The Defect Peak willbe
managed internally
‘through BIF,CBIF, PTF and
the soic
tonite ore + Updates to the Defect
eines soe Peak are NOT linked toa
TiSNow Incident so are
Live Dee
{call yp
Investigation Peaks becoming Defect Peaks
internal only
« 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 TfSNow
and Peak (and via bonding to POL ServiceNow)
« When the investigation work has concludedion an Investigation Peak and a Live Defect has
been confirmed then one of the following actions need to be taken — most likely by
Development
co If the Investigation Peak has been raised internally and is not linked to a TfSNow
Incident then its Call Type just needs changing to “#" - Defect Identified
o If the Investigation Peak.is linked to a TfSNow Incident then the Investigation Peak
must be cloned to create anew 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
closéd 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 it
is resolved and released to live
numbers
+ POLrely on ServiceNow
Page I7
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Peak Inciden
II REFEReNces I _PRopucTs EVIDENCE Pact et
[Call Reference IPC0294913
[Release Targeted At - HNG-X 21.52
[Cail Type = Live Incidents ~
Defect identified :
coeet A--Administrative use
impact C= Cloned call
- Enhancement Request
- Document Review/Design Walkthrough
ate aA 2: DC Testing Incidents/Defects
ALL C0294913 oper I ~ Intemal Development Incidents/Defects
Details entered ar rimark
Sunmary:1Nc3092244 [RESETS T ays VAI BAL/HES
all Type:t roblem Management
call Priority:0 I 0 Operational (SSC)
frorge’ Release:!G") P — Product Incidents/Defects
+4 R— Release Notice Forum
Date:01-Jun-2021 22) 5 _ sytem Testing Incidents/Defects
fnczDENT Hanacenen * Technical query
lbate/Time Raised: 3IU— Security Testing Incidents/Defects
Priority: D V— Vulnerability
contact Name: POA SI W - Reference Data Service
Contact Phone: - System Management Testing Incidents/Defects
JOriginator: %0000@) Y -- Live (Non-RefData) Data Updates ~
pee Fefereheer INCSOIZZE
5
roduct Serial No:
Product Site:
Service: WA I Platform: NA I Server: NA
New fields in Peak
Some new fields have been added to Peak that must be used from this time:
o 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)
o 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 latenin the document)
o 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)
o Release Mgt tab — Initial and Completed dates and text box - We need to know the stage
we arevat 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:
o Call 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
Page I 8
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
New field values in Peak
Some new values have been added to existing fields that must be used to improve Peak reporting
and tracking:
o Call 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:
DETAILS I REFERENCES PRODUCTS. IMPACT
[Call Reference [PC0295241
[Release [Reported In -- HNG-X Rel. Ind.
iCall Type O -- Operational (SSC)
oeitack Defect Identified
‘A--Administrative use
[impact C ~ Cloned call
E - Enhancement Request
all w_1 F -- Document Review/Design Walkthrough aS
10 G — GDC Testing Incidents/Defects
JicaLt_Pco295242 oper I — Intemal Development Incidents/Defects
Details entered are} K -- Primark
Ijsummary:testing II - Live Incidents
I ar as . M-~ Problem Management
all Priority: - ,
IFrarget Release:twa-I © ~ Operational (SSC)
lroured to:epsc . uj P~ Product Incidents/Defects
lioate:16.Jun.2023 201 R ~ Release Notice Forum F
I[seare of Response]]I S~ System Testing Incident/Defects
litesting dev MO T—Technical query
lI[End of Response] I U~ Security Testing Incidents/Defects
liResponse code to caI V-- Vulnerability llem Identified(38)
Date: 16-Jun-2021 10) W -- Reference Data Service
IIThe Call record hasI X -- System Management Testing Incidents/Defects fps
Ijoste:16-2un-2024 10IY -- Live (Non-RefData) Data Updates Bd
[Start of Response]
test 1
II[end of Response]
\IResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
lidate: 16-Jun-2021 10:51:08 User: John Simpkins
IPevelopnent Cost updated? new cost is 2 (Mant Days)
o 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 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”
IAdd Incident to Collection
Fault that
present on the Live system th
o Collections of “HDR-Fin” or “HDR-Exp” for HDR Defects
Page I 9
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
IAdd Incident to Collection
I HOR-Exp — Horizon Defect Review - SPM Experience [Public]
_~ II Add to Collection I
7
izon Defect Review - SPM Experience [Public]
HOR-Exp ~
Hl ‘on Defect Review - Financial impact [Public]
o Target Release - the values of “Requested For” and “Released at” will cease to be used
o 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 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”
[Add Incident to Collection
##LiveAflectingDefect — Fault that is present on the Live system that is inconsisten... [Pu to Collection I
o 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
IAdd Incident to Collection
[ HOR-Exp ~ Horizon Defect Review - SPM Experience [Public] __
_~I[ Add to Collection I
7
jorizon Defect Review - SPM Experience [Public]
izon Defect Review - Financial Impact [Public]
* 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:
o Call 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 file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Peak In:
I DETAILS. I REFERENCES I PRODUCTS EVIDENCE i IMPACT
[Call Reference [PC0295241
[Release Reported In -- HNG-X Rel. Ind
[Call Type O -- Operational (SSC) v
Keane #—Defect Identified
A-- Administrative use
impact C~ Cloned call
E — Enhancement Request
rad F - Document Review/Design Walkthrough
ate: 16-Jun-2021 10) G -- GDC Testing Incidents/Defects
‘ALL PC@295241 oper I -- Internal Development Incidents/Defects
L-- Live Incidents
M-- Problem Management
Operational (SSC)
Product Incidents/Defects
R -- Release Notice Forum
S — System Testing Incidents/Defects
testing dev MD T Technical query
[End of Response] I U ~ Security Testing Incidents/Defects
Response code to cal V ~ Vulnerability lem Identified(38)
Jate: 16-Jun-2021 10I W -- Reference Data Service
the Call record hasI X ~ System Management Testing Incidents/Defects as
Date: 16-Jun-2021 10I Y ~- Live (Non-RefData) Data Updates =
Development Cost updated? Hew Cost I= 2"(Man Days)
[Start of Response]
test 1
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
ate: 16-Jun-2021 10:51:08 User: John Simokins
Date: 16-Jun-2021 10)
o Summary - must be written so,as tobe 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)
o Impact — tab and free formfield to articulate impact, status and next steps so it is easy to
understand foranyone This will be maintained for HDR Peaks weekly. For other Peaks it can
be as needed
e Business impact: [as used currently, mention how many branches are affected if
helpful]
e Status update: [description of current status — succinct]
«Next action: [next action to be taken and expected date for next update]
o Priority which must be validated at all times so it is accurately shown as this will affect
reporting and decision making
o Assigned Team — must show which team is currently responsible for taking the next action
or ensuring action is taken
o Product Group and Product - We need to know the part of the system that the Live Defect
relates to for reporting and quality purposes
o 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 file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e« “41 General — in Procedure” — caused by not following defined procedure
o 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:
e “63 -- Final -- Programme approved - No fix required” — for Peaks rejected at CBIF
« “66 -- Final -- Enhancement Request” — for Peaks tagged with the
##LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects but enhancement requests
e “68 -- Final -- Administrative Response” — for Peaks tagged with the
##LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects
e “95 -- Final — Advice after Investigation” — for Peaks tagged withithe
##LiveAffectingDefect Collection that were subsequently qualified as not being Live
Defects
e “100 -- Final -- Route call to TfS” - for Peaks tagged,with the ##LiveAffectingDefect
Collection that were subsequently qualified as not being Live Defects within Peak
e “120 -- Final -- Cloned to create Defect Peak" for Peaks that WERE Investigation
Peaks and have been cloned to create a defect Peak.
e The value “30 -- Pending -- TL confirmed” will cease to be used
o Target Release - the values of “Requested For” and “Released at” will cease to be used
TfSNow Incident needed for things POL, should knot
e 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 Incidentis 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
w field values inelfSNow
¢ Configuration Item of —- HDR-Fin, HDR-Exp and LiveAffectingDefect for Incidents and
Problems
o)LiveAffectingDefect must be set when the TfSNow Incident meets the criteria for a
Live Defect at the earliest possible opportunity
ot “HDR-Fin” or “HDR-Exp” for HDR Defects
to200f1235 >
QQ SNe a HAssettog = Seriatmumber = Company
search Search
HOR EXP POA (ematy)
ce BOA (empty)
Renewed importance TfSNow fields
e¢ State - will allow reporting on Potential Defects and Confirmed Defects
Page I 12
Version & Last updated See file n
Document owner Steve Bre
BIF
PTF
HDR
FU,
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
State Work in Progress v
o Acknowledged — Fujitsu is aware of the Incident but is not yet working on it
o 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 bysany
reader. Peak uses a dedicated field for this and uses the following format»
o Business impact: [description of the business impact, succinct]
o Status update: [description of current status — succinct]
o 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 reviewSeparate minutes
Peaks to be taken to CBIF will’be identifiable from criteria based on data fields on a Peak
Submissions to CBIF will uSé.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)
It is 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 it is 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 n
Document owner Steve Bro
FUJ00232729
1J00232729
FUJ00232729
FUJ00232729
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...
31° July 2021
...and to have completed all improvement including any early challenges and snags by
31% August 2021
Purpose & Scope
co 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 forsome, it is 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
POA needs 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
co Our interactions needs to be system and process driven not people and experience — and
that will create a clear audit trail foo.
o We need to limit the dependency on meeting-specific reports or embedded tables in minutes
to show progress on important matters.
o 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 andvable to make decisions for us or with us
o 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
o We.néed to agree the functions of the various platforms and meetings to ensure it all joins up
(this document is a start)
o If PObjis tracking it - or applying governance to it — then so should we — and our process
should bein advance of theirs so we have no surprises
o 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
o We need to protect our internal systems from a need for routine disclosure — so we can work
our way
o 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
o For this to succeed we need considerable cross functional support coupled with manager and
team member engagement
°
°
The Streams
e Stream 1 - Incident & Problem (links to Peak, Key Meetings & Live Defect Management)
Page I 14
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
co 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
e Stream 2 - Use of Peak (3LS, 4LS & Release)
o Focusses on the Peak Incident management features and their links to Live Defect
Management and Release Management
e Stream 3 - Live Defect Management
o Defines an improved way to capture Live Defect information and report on it both
internally and to POL
« Stream 4 -BIF, CBIF, PTF and HDR
co 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 entriesjare 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
o All Incidents 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,
lems
co AllProblems 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.
o 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 TfSNow 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.
oo
Page I 15
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Release Notes must state all Peaks that are being closed when the Release goes live. This
must be included in the related Change ticket
o There must be a report showing the Peaks and any associated POL HDR Defect references
so that POL are able to keep their tracking in sync
o Release dates must be held in Peak so that Peaks can be tracked to deployment
co ALive Defect is defined as an issue that:
e ls present on a LIVE system
« Is, or appears to be, inconsistent with the agreed design or service specification
e Is, therefore, a fault that is likely to need fixing
e The Horizon Defects Review (HDR) scope will be those Live Defects thatialso 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)
Note: Only one HDR-* Collection neéds to be set and if both could apply then HDR-Fin should
be chosen
IAdd Incident to Collection
HDR-Exp — Horizon Defect Review - SPM prperenes [Public] _ a II Add to Collection I
HOR-Exp Horizon Defect Review - SPM Experience [Public]
HOR-Fin ~ Horizon Defect Review - Financial Impact [Public]
e 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)
o 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 isto be added to the TfSNow Incident so that it is 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.
e Note: If the Incident has been escalated to a Problem in TfSNow then updates on the
investigation work will be provided within the weekly status update report which
shows confirmed Live Defect
o 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.
o Non-HDR Defects will be managed internally 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.
ct Management
o All Live Defects must be rigorously managed until resolved.
Page I 16
Version & Last updated: See file ni
Document owner Steve Bre
BIF
HDR
FU,
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
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.
All confirmed 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 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.
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.
It is 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.
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 17
Version & Last updated: See file n
Document owner Steve Bre
FUJ00232729
1J00232729
FU,
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. Incidents must be raised in TfSNow
by Fujitsu or in ServiceNow 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 onithe 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 internal instructions)
Incidents raised as Fujitsu internal 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]
Page I 18
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232729
1J00232729
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o 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
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
o We need to use the designated open and close categories to better monitor Incident
categories
* Open category — TfSNow has Configuration Items that should be used
*® Closure code — TfSNow has these and they should be used
co 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-Advice & Guidance
Avoidance Action Supplied POA-Fujitsu Operational
Administrative Response POA-Administration
‘Advice and guidance given POA-Advice & Guidance,
No fault in product Tong Fault,Found/No Action
Duplicate Call Cancelled
Solicited Known Error POA-Advice.& Guidance
Insufficient evidence Unidentified Root Cause
Fix Released to Call Logger POA-Peak Fault Found
User error POA-User Error
Unspecified Insufficient evidence I Unidentified Root Cause
Call withdrawn by user Cancelled
Fixedvat/Future Release POA-Peak Fault Found
Enhancement Request POA-POL domain
Suspected hardware fault Unidentified Root Cause
o 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
o 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
e 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
o Fujitsu will set an Incident to Suspended in TfSNow until POL close their original Incident
Page I 19
1 & Last updated: See file n:
ent owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Note: Resolved in TfSNow 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 it is truly Resolved
then they will request POL to close it.
When POL close an Incident it notifies MAC and MAC can then close the TTSNow
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.”
o 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
o ALive Defect is defined as an issue that:
Is present on a LIVE system
ls, 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
“LiveAffectingDefect” Cl added in TfSNow
The State field values must be used.
State Work in Progress ‘
= Acknowledged — Fujitsu is aware of the Incident but is not yet working on it
= Workln 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
o 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 20
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= Configuration items Search Name
1 to200f1,235 >
F Ail>Name>=HoR
QS Name a Sssettag —-Seriatnumber = Company = Managed by
Search Search Search Search Search
@ = HOR-ExP POA (empty
@ REN BOA fomety
e 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)
e 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-* Ci needs to be set and if both could apply then HDR-Fin should be chosen
o When the HDR* Cl is applied to an Incident, Fujitsu MACG.will also email the Fujitsu Duty
Manager email alias and a POL designated,alias to provide an email early warning that a
new HDR Incident has been raised
o Incidents carrying a HDR* Cl will have the POL Problem references added to the Incident to
enable cross-checking
o Incidents carrying a HDR* Cl will still be.classified as potential or confirmed Live Defects
using the classifications mentioned above
o Peaks that are cloned that have a ServiceNow reference cannot be closed by EDSC until the
cloned Peak that was created isjalso 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
o 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
o Recurring Incidents and Incidents with follow up actions require a Problem record to be
created. The Incidents are linked to the Problem
o 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
o Weneed management reports for Incidents to see trends. This needs to be part of the
monthly SMR and/or internal Service Operations meetings:
e® Open, Active and Closed Incidents
e Live Defect Incidents — potential and confirmed
e HDR Defects — potential and confirmed
« For each, show views based on:
= Open category & Close codes
= Cl associations
« — Internal response times by type/priority
Page I 21
Version & Last updated See file n
Document owner Steve Bre
°
FUJ00232729
FUJ00232729
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, TfSNow
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.
If a 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):
°
°
°
°°
°
°
o
v
Configuration Items
Search Name
1 to 200f1.235 >
All> Name >= HOR
4 Name a S Asset tag = company = Managed by
Search Search earch Search Search
@ ioR-exP POA (emnpty)
@ HORAN POA (empty)
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
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
Problem reporting should have HDR tagged Problems
Incidents where the resolution is a fix to address a Live Defect may be both a Peak anda
Problem (the former for management, the latter for joint process validation)
Page I 22
See file n:
Steve Bre
Version & Last updated:
Document owner
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Actions
System Changes
ys ,
2 § foompleted
n °
One-Time Actions
Page I 23
Version & Last updated: See file narr
Document owner Steve Browell
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
SR Sam Eee Ber 0
FUJ00232729
FUJ00232729
* Fixdn Py Fujitsu-hs firrned_that the-Incident
g ii
fixcit likely-tinked-to-a-Ch: ticket
eo I leted 21.07.2024 ken-to SMC -too-Fujitsu MAC. it
feomp! “OF P Fj
die/MAC-t We need ly-the-Cl-and State field value-checks-to-existi
42. Si pply SI isting-
° Renae anteiag erate cee
b. Major Incident procedures — SVM/SDM/PRO/0001
¢. Incident procedures- SVM/SDM/PRO/0018
d. Problem procedures - SVM/SDM/PRO/0025
e Duty Managerhandbook SVMISDMIMAN/2378
f. Awaiting Steve Ba approval
Page I 24
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
to-flow-throughTISN: d-
ig
t e
iginal Peak should -then-be-closed-as-it- has-b perseded-[ leted
17. Sandie — we need MAC to ensure that any Peak that is closed that has been cloned and for
which continued TfSNow updates are still needed (e.g. it is bonded to POL),is sent back to
Peak for the Peak to be reopened. Otherwise the TfSNow incident will stagnate as no Peak
updates will be received and manual chasing will be needed to get progress updates on the
cloned Peak
FOPrPRP TH
19. Steve Br - Investigate how Post Office Cloud systems and processes will affect these
processes and ways of working
New Ways of Working
a. Outcome -New.HDR report has been produced and will be checked weekly by
Fujitsu MAC, This will be added to the Friday Peak/TfS report
2. Sandie —- Werneed to regularly check
e 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
teference 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
e the current status and the next action on an Incident is clearly stated so any reader is
in no doubt that the Incident is under full control — challenging and coaching where
needed
e the Summary field is well worded and understandable by most readers
e the relevant open and close categories are being used when handling Incidents —
applying additional caution with bonded Incidents to use the mutually agreed settings
e 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)
Page I 25
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 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
3. 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
Outcome - New HDR report has been produced and will be checked weekly by
Fujitsu MAC. This will be added to the Friday Peak/TfS report]
5. Sandie—Close Incidents when investigation Reak is closed anda defect Redk Refi
a. Outcome — Part of new MAC process
6
7.
Page I 26
1 & Last updated: See file ni
ent owner Steve Bre
FUJ00232729
FUJ00232729
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)
o Team -—Adam Woodley, Tariq Arain, Matt Swain, Tomi Okelola — plus John Simpkins & Mark
Wright
Peak
co 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
o 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
o If any 3LS, 4LS or Architect creates a Peak in the course of their normal duties that matches
the definition of Live Defect:
e Is present on a LIVE system
¢ Is, or appears to be, inconsistent with the agreed design or service specification
e 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.
IAdd Incident to Collection
II Add to Collection
co Ifa Peak has had the ##LiveAffectingDefect Collection added, and it also has at least 1 of
the following attributes (Horizon Defect,Review)»
e 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)
e 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
IAdd Incident to Collection
I HOR-Exp -- Horizon Defect Review - SPM Experience [Public]
II Add to Collection I
=
jorizon Defect Review - SPM Experience [Public]
Horizon Defect Review - Financial Impact [Public]
HDR-Exp -
HOR.
co 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 TfSNow. The original Peak should be closed citing that it has been
superseded by a Peak linked to TfSNow
o When the investigation into an issue defined in a Peak originating from TfSNow is concluded,
the ‘investigation’ Peak can be closed
e 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 27
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
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)
e 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
co The interface between TfSNow and Peak (OTI) 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
o The Summary field needs to be written so as to be understandable to most readers as it will
be used in internal management and external POL reports
o New fields are being introduced to help Live Defect Management tracking andwreporting and
these will need to be completed by various parties as the Peak progresses.
e See section Live Defect Management — Key Fields in Peak
o 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 hot clone Peaks but instead they
obfuscate the original so it can be widely shared and updated whilst
maintaining any links to TfSNow.dncidents. Peaks cloned prior to this date
that remain open will have broken the auto links to any TfSNow 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 fromthe 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: if a Peak has been assigned to a Baseline then cloning should be done
with caution and include consultation with the Baseline owner in advance
« ‘When the [Clone] button is clicked, the following menu is displayed:
Page I 28
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
te aa
« The user selects from the list (Defect is the default option), and clicks confirm. The
reason is captured in the clone Peak:
Date:11-Aug-2021 09:00:38 User: John Simpkins
CALL PC0250898. opened
Details entered are:-
iSummary:test mb problem
call Type:#
call Priority:D
Harget Release:HNG-X 12.11
Routed to:EDSC - John Simpkins
Date:11-Aug-2021 09:00:38 User: John Simpkins
Clone Reason: Create 3 Defect Peak
JDate:14-Dec-2015 15:52:55 User: Customer Call_
CALL PC0244669 opened
Details entered are:-
isummary:test mb problem
e — If the Defect reason is selected, the clone will be created with Call Type ‘#'’.
o Peaks raised in Test or Dev that also relate to the Live environment will not have Call Type
“L.
* 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
o 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
o 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
o 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 29
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Rules on use of Call Type need restating so we ensure greater consistency
co 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
e The report created by Fujitsu MAC is useful but does not appear to cause action to
be taken
co 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
co ‘Private’ Peak updates can be added to the Progress field. They stay in Peak and are,not
replicated across the OT
o Updates added the Response field are replicated across the OT]
o The References field is manually maintained so can miss Incidentor KBA references. SMC
may add KBA into reference text instead of into the References. field which limits query-
ability
co Peaks closures:
e 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)
e 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
“#". If the Peak is not linked toa 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”
e All other Peaks are closed,based on team/process specific rules — as per current
processes
o Peaks closed as usef/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
e “40 General — User” - caused by an action performed by the user which was
Outside expected use
e “41 General — in Procedure” — caused by not following defined procedure
co 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
co 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
o 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-Advice & Guidance
Page I 30
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
‘Avoidance Action Supplied POA-Fujitsu Operational
‘Administrative Response POA-Administration
‘Advice and guidance given POA-Advice & Guidance
No fault in product POA-No Fault Found/No Action
Taken
Duplicate Call Cancelled
Solicited Known Error POA-Advice & Guidance
Insufficient evidence Unidentified Root Cause
Fix Released to Call Logger POA-Peak Fault Found
User error POA-User Error
Unspecified Insufficient evidence I Unidentified Root Cause
Call withdrawn by user Cancelled
Fixed at Future Release POA-Peak Fault Found
Enhancement Request POA-POL domain
Suspected hardware fault Unidentified Root Cause
o 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
o To ensure we avoid updates, being, overtly associated with an individual the updates should
be system driven — not separate emails or meeting comments
o 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
o Deferred Peaks should be recognisable against the release they were deferred from and the
release to which'they are subsequently targeted
o Only Peaks can be deferred — POA Jira’s or other things stored outside of Peak CANNOT be
deferred,
o 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
[Add Incident to Collection
e 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
e Target Release Type changed to “Proposed for” for subsequent update via BIF/PTF
Page I 31
Version & Last updated: See file ni
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 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
[Add Incident to Collection
HOR-Exp -- Horizon Defect Review - SPM Experience [Public] ree v II Add to Collection I
or
1p ~- Horizon Defect Review - SPM Experience [Public]
Horizon Defect Review - Financial Impact [Public]
o Release Notes must list all Peaks that are fixed and being deployed. The extract/report must
also show the POLPRB- reference for HDR Defectsand 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):
(Cal ReferenceISummary Pan nee ene
PCO29S314_ LST20.94: Proper messages ha to dispaly instead of Agent eveut in DCM. LREC.DCM
PC029S403 LST: 20.94: Too may D records in LREC fie
PC0295711 PBS Plot INC8349716 : Amex tax not sete as expected when reconcing DRS? reports
PC0295725 PBS: INC83S4763 (IFSNow) :INCO388718 Lloyds £300 withlraval [MCSUK-16376]
POL Problem Refi Problem Ref
PREATE LRBC_C4D jo
o Release Notes will not list:
e 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
Live Defects but are just a tracking mechanism for the Test team)
o 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 fixis deployed and they are asked to close the Peak :
© The action of deploying the Release should notify SSC so that any related I
correctly actioned
o “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
co Ifa Peak has been assigned to a Baseline then cloning should be done with caution and
include consultation with the Baseline owner in advance
o 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
o Hotfixes are a mini release and will use the new 3-node release numbering xx.yy.zz 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
o Release Management will maintain the Target Release date table:
Page I 32
Version & Last updated: See file ni
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e All past 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)
e 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
e The Target Release screen should be used to make universal changes to Peaks
when release information changes
¢ Hotfix releases must also be included in the date table
* 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
Actions
System Changes
ages has to dspaly stead of Agu events inDCM_LREC.DCM. CREATE LREC.C4D jo
PC029S403 19T:20.94: Too mmy D records n LREC fe
PCO20S711 PBS Piot INC8349716 : Amex bos pot sete expeced when resonclng DRS? reports
.C029S725__ PBS: INC83S4763 (TFSNow) :INCO388718 Loyds £300 withdrawal [MCSUK-16376]
Gose
. I to-be-i istentwith-th d-desi is ificati
g
Page I 33
1 & Last updated: See file n:
vent owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
dat tomatically_flow- back to TISNow-The original Peak should belclosed citi
defined k-originating-from_TISNow i Juded=thei tigation’ Reak. be
11. Adam/Steve Ba/Sandie — 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
12. 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
13. Adam/Tariq - Manager reports will need to be created to enable spot checks on Peak data
entry quality and to encourage new habits — fields filled in, fields read well, clones created for
correct situations
Page I 34
Version & Last updated See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
a.
20. John - Conduct feasibility work to check how Peak extracts can be created — branded,
obfuscated, redacted, exclude Progress updates etc — for potential future sharing,
commitments
20. Adam — Notify the SSC team and create a process so that 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 Peaksmust 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. We need to agree,
implement and document a frequency for doing this. Is.weekly,enough? If updates are
demanded more frequently then MAC will be chasing so it.will become apparent quite quickly
if higher frequency updates are needed. 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
24+. Adam d f Incidents taised_wh Peak is determined by t
22. Adam — we need SSC to understand that MAC may reopen Peaks by assigning them back to
the Peak resolver groups to ensure that any Peak that is closed that has been cloned and for
which continued TfSNow updates are still needed (e.g. it is bonded to POL) is kept open to
ensure updates continue tobe provided. Otherwise the TfSNow incident will stagnate as no
Peak updatesiwill be received and manual chasing will be needed to get progress updates on
the cloned Peak
27. Steve Br - Investigate how Post Office Cloud systems and processes will affect these
processes and ways of working
Page I 35
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
« MS mentioned Jira — is this what we are now expected to use? Or is it Peak?
« MW mentioned the new cloud systems will use Jira not Peak
« TAmentioned 4LS do not have access to the POL JIRA system unless in the P2C
team. What are the FJ views and processes around POL JIRA?
New Ways of Working
3d-to-ch to-whatis-described-in-this-d "
2. Adam/Tariq/Sandie — regular checks should be made to ensure 3LS, 4LS or Architects who
create Peaks in the course of their normal duties that relate to the Live system where POL
should be notified are contacting Fujitsu MAC to raise an Incident and determine how to
ensure the Peak is correctly associated
lone-has-bs ted-for-the-defect Reak
5. Sandie/Adam/SMC - The Summary field needs improving to make,more sense to more
readers as it will be used in internal management reports.and external POL reports
6. Adam/Tariq—Call Type “#’ is f firmed _Live Defects only-and-needs-to-be-used by-th
teams
7. Adam/Tariq - Peaks that relate to the Live system should have their Call Type set to “L” until.
they are confirmed or qualified out
8. Adam/Tariq—Current d-stat + bein thé Peak and-noti ‘ i
9:
40:
with TfSNow Incidents closeéd,for the same reasons to send a monthly report to POL to
recommend,enhancements that could avoid the occurrence of the issue
14. 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
{Cal ReteenfSurmary RAPS IOUACIASS Por Probien Raft Prbem Red
95314 LST20.94 Proper messages bso dopa tetead of get events nDCM_LREC DCM CREATE. LREC CD jo
LST: 20.4 Too ny D records LREC fe
PCO2SS7I1 PBS Plot: INC8349716: Amex tum not seed as expected when reconcne DRS2 eps
1960295725 PBS: INCE3SI763(TFSNow) -INCO3KS718 Lyd £300 witha [MCSUK-16376]
Page I 36
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
18. Matt S — Release Management must ensure TfSNow Change tickets show all Peaks being.
fixed along with their applicable POL and/or Fujitsu Problem references
20. 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
21. PMs/QFP - Deferred Peaks will need to be updated. The party obtaining agreement to defer
will need to ensure:
othe ##LiveAffectingDefect Collection is set
othe “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)
Page I 37
& Last updated See file name
Steve Browell
FUJ00232729
FUJ00232729
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
°
°
All Live 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
A Live Defect is defined as an issue that:
e Is present on a LIVE system
e ls, or appears to be, inconsistent with the agreed design or service specification
e Is, therefore, a fault that is likely to need fixing
e 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)
= ¥ [Add 1 Colecton I
ed
jorizon Defect Review - SPM Experience [Public]
jorizon Defect Review - Financial Impact [Public]
e There may be a workaround, but the underlying issue still meets the criteria above
e An Incident may be undefinvestigation that is not confirmed to meet the criteria
above but has,attributes that meet the criteria above (a potential Live Defect/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
e Live (Non-HDR) Defects
« Non-Live Defects (test/dev etc) — 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
°
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
o Live Defects must be recorded as Peaks and managed using the Peak system
e 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
Page I 38
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o 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
o 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
o We need to know the status of all Live Defects and whether there are any issues needing
attention
o We need to be able to review trends and attributes of Live Defects to identify patterns — 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
o Live Defects must be clearly titled so that they can be understood by the majority of readers
o 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
o All Live Defects must have a clear next action stated that can be tracked
o All Live Defects must be owned by a team at all times whosemmanager will ensure the right
actions are being taken (this can be a different team throughout the lifetime of the Live
Defect)
o 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
o When a HDR Defect is being investigated there willbe a TfSNow Incident open and bonded.
POL will track status by referring to their ServiceNow Incident. All progress on the
investigation is to be added to the TfSNow Incident so that it is visible to POL in their
corresponding ServiceNow Incident:
e It is POL’s responsibility to keep their Problem record up to date if they have opened
one
o If Fujitsu completes its investigation and confirms there is no HDR Defect then the
investigation Peak and Incidentwill be closed with no further actions required. The Peak will
be closed with Response Category, “95 -- Final — Advice after Investigation” [or “66 — Final —
Enhancement Requeést’] 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
o When a HDR)Defect is.confirmed as a Fujitsu owned Live Defect, then a new defect Peak
will be created thatisummarises 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
thenreplicate to the TfSNow Incident. The investigation Peak will be closed along with the
TfSNow 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
o Live Defects that are not classified as HDR Defects are managed internally by Fujitsu using
Peak. Reports will be available for POL to show overall progress but it is not intended that
every non-HDR Defect will be discussed
co 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
o 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:
e the ##LiveAffectingDefect Collection is set
Page I 39
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
I{ Add to Collection I
e the “Deferral Agreed” Collection is set
e The Call Type is 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
EE
Peak Inciden
DETAILS PRODUCTS o
[Call Reference
[Release [Targeted At -- HNG-X 21.52
[Call Type L- Live Incidents. ¥.
#~ Defect Identified
comet ‘A-- Administrative use
[Impact C-- Cloned call
Is E — Enhancement Request
Document Review/Design Walkthrough
jun-2021. 22) G ~ GDC Testing Incidents/Defects
258073. opal I~ lotomal Development incidents Diélocks
jetails entered areI K— Primark
y:INC6082246, REY aR I VET 8s
all Type:
fey:
roblem Management
~ Operational (SSC)
Product incidents/Defects
jelease Notice Forum
ystem Testing Incidents/Defects
schnical query
loate/Time Raised: 3IU~ Securty Testing Incidents/Defects
Priority: D V— Vulnerability
Poa I W~ Reference Data Service
I X= System Management Testing Incidents/Defects
or 100000] Y ~ Live (Non-RefData) Data Updates x
riginator’s referenCer NCOIZERE
Product Serial No:
Product Site:
e Target Release Type changed to “Proposed for” for subsequent update via BIF/PTF
e 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
IAdd Incident to Collection
HDR-Exp —- Horizon Defect Review - SPM Experience [Public] ¥]I Add to Collection I
oy ToT
HDR-Exp — Horizon Defect Review - SPM Experience [Public] *
HOR
jorizon Defect Review - Financial Impact [Public]
Page I 40
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Weneed 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
o 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
o 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
o Reports are needed for management to show the overall status, trends, and patterns related
to all current Live Defects and historical Live Defects
o 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”
co 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 toyHDR so that
the meeting has the information in advance
o 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
o 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
o “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
© Weneed a method to track when a fix was ready and then the delay was related to waiting
for a slot to deploy as it is the date the fix could have been applied that is key — not the date
it wes applied
BIFApproved is a date when we knew what to do. Although this does not inc! ide an
estimate of the time to fix it, itis a point where we could have started the work and
hence a fix could have been deployed nearer to that time that the release date
eventually used
+ We need to message this correctly to POL and POA management
« We need to challenge ourselves ‘on our processes and the batching of items for a
release — why do we not do more releases, why do we not put more in a release
+ We need to ensure that POL and POA management are involved in the defect
decision making so we agree periodically t it waiting is ok rather than action
* Demand Planning may need to include an explicit defect fix work item so it can be
prioritised along with the other project work — or not — but by explicit decision making
o 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
Page I 41
Version & Last updated: See file n
Document owner Steve Bre
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
I Response Category - 97 ~- Final -- Unspecified insufficient evidence
I Response Category — 98 -- Final - User error
Response Category - 100 — ~ Final -- Route call to Ts
I Response Category - 120 - -Final — Cloned to create Defect Peak
Response Category — 200 - Final — Call witharawn by user
Live Defect Management — Key Fields in Peak
The following are the key fields needed for Live Defect Management:
°
°
FUJ00232729
FUJ00232729
Call 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 othenCall 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:
I DETAILS II REFERENCEs II PRODUCTS _EVIDENCE I
[Gall Reference [PC0295241
[Release [Reported In -- HNG-X Rel. Ind.
[Call Type © - Operational (SSC)
eves Defect Identified
‘A Administrative use
[impact C ~ Cloned call
E ~ Enhancement Request
F -- Document Review/Design Walkthrough
ate: 16-Jun-2021 10 G ~ GDC Testing Incidents /Defects
ALL_PC8295241 oper I ~-Intemal Development Incidents/Defects
tails entered are} K — Primark
Summary:testing I -- Live Incidents
M—~ Problem Management
© ~ Operational (SSC)
P — Product Incidents/Defects
sey eee ede: Release Notice Forum
fstane oF Response]IS~ System Testing Incidents/Defects
esting dev ' I T= Technical query
[End of Response} lu ~ Security Testing Incidents/Defects
ate: 16-Jun-2021 10 W -- Reference Data Service
The Call record has) X-—- System Management Testing Incidents/Defects ps
ate: 16-Jun-2021 10I Y - Live (Non-RefData) Data Updates +
evelopment Cost updated? Hew Cost Is 2 (Man Daysy
[Start of Response]
itest 1
[End of Response]
jate: 16-Jun-2021 10:51:08 User: John Simpkins
sponse code to caI V~ Vulnerability lem Identified(38)
Response code to call type L as Category 40 -- 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
Page I 42
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e Business impact: [as used currently, mention how many branches are affected if
helpful]
« Status update: [description of current status — succinct]
e Next action: [next action to be taken and expected date for next update]
o 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 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”
Incident to Collection
ffectingDefect — Fault that
present on the Li
o Priority —- which must be validated at all times so it is accurately shown as this will affect
reporting and decision making
o Collections of “HDR-Fin” or “HDR-Exp” for HDR Defects
Note: Only one HDR-* Collection needs to be set and if both couldyapply then HDR-Fin should be
chosen
[Add Incident to Collection
I HOR-Exp -- Horizon Defect Review - SPM Experience [Public] _
o 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:
eH EE
o Fujitsu Problem reference — using the prefix “FJUPRB-" so it is obvious and also searchable
e Fujitsu Problem Reference is a Reference field and the following screenshots shows
how to add the field:
Page I 43
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Fea are Magee Syste FO
o Workaround - to state “Yes/No” state if a workaround has been implemented, If the field is
blank or contains “No” then no workaround has been identified. If it is “Yes” then an accepted
workaround is in place
e Workaround is a Reference field and the following 2 screenshots show how to add
the field and set its value:
veak Incident Sanagetent System - PCUzYS241
[calinfsvece
(Calera
[Gases
Peak Incident Management System - PCO
pena. vereencts ipebiery rpm pact coupcros rargeremese (_paeet or
[Retiree Tape [eres aioe
(Cat reference 20059
[Gatefereace
(Callatersace <=
(Raaieteias Tope
2 I haa eeioent I
Expected Fema) [==
‘ein ipl eferencen these mvt bcs separ and be of he Sa
o Release Mgt tab - Initial and Completed dates and text box - We need to know the e 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
o Assigned Team — must show which team is currently responsible for taking the next action
or ensuring action is taken
o Product Group and Product - We need to know the part of the system that the Live Defect
relates to for reporting and quality purposes
co 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
Page I 44
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Response Category -— specific values have been identified to enable clarity and to spot
exclusions:
e “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
o Target Release — the values of “Requested For” and “Released at” will cease to be used
o Management governance and checking is needed to ensure this is how the system is being
used — correcting at least weekly
o Areminder 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
= The Response Category is changed.
= The ##LiveAffectingDefect Collections added
* The HDR-Fin or HDR-Exp Collections are added
e Pop-up wording:
= Is this a Live Defect? — ifso, add the ##LiveAffectingDefect Collection
= Is the Call Type correct (Live Incident or Defect Identified if applicable)?
= Does/could this affect branch operations? — if so, add the HDR-Fin or HDR-
Exp Collection
= Is there a Workaround? = if so, add the Workaround References field and
set it to Yes
= Does your lastupdate 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 Mafagement Reporting
e 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,
Page I 45
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
HDR_User, HDR_Date, BIF_User, BIF_Date, TFSBonded (1/0), Assignee, Time to
Target (Days)
Actions
System Changes
ef 6 2 eH Pw PR ED
John —E: F#SNow, iceNow— ContactN: ‘bt the-defined rts
Joni
i? leted 26.07.2021}
Teor} OF +
t to-“Fault that i
o Events triggering presentation of the pop-up:
Page I 46
Version & Last updated: See file ni
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Pop-up
The Peak Routing is changed
The Call Type is changed
The Response Category is changed
The ##LiveAffectingDefect Collection is added
The HDR-Fin or HDR-Exp Collections are added
wording:
Is this a Live Defect? — if so, add the ##LiveAffectingDefect Collection
Is the Call Type correct (Live Incident or Defect Identified if applicable)?
Does/could this affect branch operations? — if so, add the HDR-Fin or
HDR-Exp Collection
Is there a Workaround? — if so, add the Workaround References field
and set it to Yes
Does your last update read well to users not involved in the Peak
progress?
Have you added a helpful Impact update?
Is the Priority correct?
Are the Product & Product Group fields correct?
Is the Status (Response Category),correct?,
this i id jally-the-defi FL
2
a ifthe Peak d-te th ig Assigned Team thi ign it
i Is presentona-LiVE-system
iis, tolbe-i istent. with the-agreed-d
Page I 47
Version & Last updated: See file n
Document owner Steve Bro
Page I 48
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
t thi has-3 e d-this field will be shared.
i. Root Cause values need explaining and adding to the Application Support
Strategy document
4
6
7
8
13
14
15
16
21
24
26
31
32
33
34
37
38
39
40
41
Architecture
Design - Platform Design
Design - High Level Design
Design - System Outline
Development - Build Scripts
Development - Code
Development - Low Level Design
Development - Reference Data
Requirements
Cfg Mgt - Config Data Error
Integration - Build
Test - Test interpretation
Test - Script
Test - Data
Test - Environment
General - Network Change
General - Hardware Fault
General - User Knowledge
General - User
General - in Procedure
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 42 Gen - Outside Program Control
e 43 General - Operational Change
e 96 Gen - Investigation On-Going
e 97 General - 3rd Party issue
e 99 General - Unknown
10. Steve Br/Steve Ba/Tariq/Adam/Graham — when the final listof 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
11.
16.
17. Steve Br - Agree a process for, CBIF Proposal creation
St i ty Peak h-as-tagenico-rel
20. i ging 3° party 9g
24+. Steve-Bi ge-a-briefing-call-with-all-rel tROA gers-to-explain-this-st
22. 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
DE/VP 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
##LiveAffectingDefect tagged Peaks)
2. Steve Br/Adam - 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
3. Adam/Tariq—Ch: the t te-a-defect Reak-with Call Type "#" that. will-b
et i) i ‘yp!
Page I 49
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
a. Outcome - see Appendix A
Page I 50
Version & Lz
Document o1
FUJ00232729
FUJ00232729
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
o Team -— Steve Bansal, Sandie Bothick, Adam Woodley, Tariq Arain, Matt Swain, Tomi
Okelola, James Guy — plus cascade to all 3LS, 4LS, and Architects
BIF
o BIF is a Fujitsu internal meeting
o When a Developer is ready for BIF to consider their proposal then they must
e Set BIF Action flag on the relevant Peak
¢ If the Peak:
= Is present on a LIVE system
= 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
* — If the cause and required action to remedy are:
* — Still being investigated — then,Set the Call Type to "L"
e Are confirmed — set the Call Type to “#” and also update:
o Root Cause field is up to date
Peak In:
{ petans II REFERENCES PRODUCTS EVIDENCE IMPACT
[Call Reference [PCo295241
[Release JReported In —- HNG-X Rel. Ind.
[cat O--Operatoral S50) =
contac ‘A= Administrative
[Impact C~ Cloned call fg
tee E~ Emancoment Regist =
BS F Document Review’Design Walkthrough sc eeeE
SA IG ~ GDC Tesing nade Defects
a ‘oe eral Developmen incigentDeecis
5 entered are) K ~ Primark i
[Summary:testing II — Live Incidents I
i
I
all Type: M-— Problem Management
‘ell Priority:D ° es
Prarget Release:t-
touted EOtEDSE
wed S0zE0SC =_ 41 R Release Notice Forum
Rstact of necporsey]S-~ System Testing Incdents/Defects I
testing dev n> I T~ Technical query
[end of Response] I Secutty Testing IncidentsDetects I
Response cove t0 cal V~Vuinerablity hen adenti¢iea(s8)
[Dste:46-3un-2621 16] W ~ Reference Data Service F
[the Cali record hasIX-- Systom Management Testing
te: 16-Jun-2024 ion RefData) Data Upd
Joevelopoent Cost “coEE TEP (a Os
[stare of Response]
test 1
[End of Response)
IRecponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Joate: 46-Jun-2024 10:51:08 User: John Sinokins
© ~ Operational (SSC)
Product Incidents/Defects
= 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
co All Peaks with the BIF Action flag set will be reviewed at BIF
Page I 51
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e This will include all defects Peaks with the ##LiveAffectingDefect tag
e — It will also include other Peaks that may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
oO. 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
oO. BIF must consider the proposal (as it does currently) and also validate the following data
values for defect Peaks:
e = If the Peak:
= — Is present on a LIVE system
= — 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
[Add Incident to Collection,
= If the cause and required action to remedy.are:
e — Still being investigated — then set the Call Type to "L"
* Are confirmed — set the Call Type to “#” and also update:
o Root Cause field is up to date
Peak In
I. REFERENCES I PRODUCTS EVIDENCE IMPACT
[PC0295241
[Reported In - HNG-X Rel. Ind
‘0 — Operational (SSC) y.
‘A-- Administrative use
© ~-Cloned call
Senay. E ~ Enhancement Request
F --Document Review/Design Walkthrough
ste:16-Jun-2021 10 G ~ GDC Testing Incidents/Defects
“ALL PC@295241. oper I ~ Internal Development incidents/Defects
,e entered Primark
Isunmary: testing Incidents
Katt Typest roblem Management
mL briotiny Operational (SSC)
forget Release HN p — Product Incidents/Defects
Ieoee sé a cear ie R ~ Release Notice Forum
start of nesponse}] S~ System Testing Incidents/Defects
Technical query
testing dev "0
[End of Response] I U ~ Security Testing Incidents/Defects
IResponse code to cal V— Vulnerability jem Ident ified(38)
aa 10 W.-- Reference Data Service
fhe Call record hasI X~ System Management Testing Incidents/Defects his
jate: 16-Jun-2021 10) Y ~-Live (Non-RefData) Data Updates =
evelopment Cost updtear WaW COSE IS 2” (HOW Days)
(Start of Response]
test 1
[End of Response]
iesponse code to call type I as Category 40 -- Pending -- Incident Under Investigation
ate:16-Jun-2021 10:51:08 User:John Simokins
= 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
Page I 52
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= 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:
e Affects, or has the potential to affect, branch financial outcomes, add
the HDR-Fin Collection
e 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
e 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 couldiapply then HDR-
Fin should be chosen
IAdd Incident to Collection
[ HOR-Exp ~ Horizon Defect Review - SPM Experionce [Pubic] I Addto Colecton
HOR-Exp -- Horizon Defect Review - SPM Experience [Public]
HOR-Fin ~ Horizon Defect Review - Financial Impact [Public]
= 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
* Thesfix can be done in more than one way and POL would need to
guide Fujitsuon choosing the preferred option.
* The fix may change the functionality of the system and consequently
POL will be required to provide appropriate communication, and
potentially training, to the subpostmasters.
* The fix may need to be done in conjunction with changes performed
by some of POL's other suppliers and POL will need to manage and
synchronise that activity.
* — 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.
* 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).
* 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 53
Version & Last updated: See file ni
Document owner Steve Bre
Page I 54
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e The new BIF date fields (Initial and Completed) willneed tobe completed during, or
after, the BIF meeting (not before or it will affect status reporting)
= Initial date - will hold the date of the firstBIF 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
e If the Peak is approved at BIF then the BIFApproved Collection must be added (also
for BIFRejected)
[Add incident to Collection
[EiPApproved Approved fo fx by the Business Inpact Forum [Team] SJ] Add to Colecion.
e 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
e If the 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
CBIF isa joint meeting with POL
CBIF wilhcontinue to exist and it will be merged with the
HDR 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
data items so it is system driven. See CBIF Submission
Extract Criteria below for the system value that will
determine CBIF applicability
vi
Document owner Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o 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
e 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:
« 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 outcometof CBIF discussions should be added to the CBIF text box on the
Release Mgt tab. Aiconcise note is all that is needed. No need for separate in CBIF
minutes,
e Ifthe Peak needs to go back to the Developer then it should be assigned to the
Developer team
@” ‘if the. Peak can proceed as discussed then the PTF Action flag will be set
« If the Peak is to be discussed next time (as POL wish to seek wider feedback within
their own organisation) then the PTF Action flag will not be set and this will cause the
Peak to reappear on the weekly report
e 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”
co 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
co There is no definition of CBIF in the contract — it says BIF — this needs to be addressed
CBIF Submission Extract Criteria
co Asat the 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.
Page I 55
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o Filter on these values first:
e Must have the ##LiveAffectingDefect tag (relates to the Live system and does, or
might, need a fix)
« Must be Call Type "#" (a fix is needed)
e Must have a Planned Out Date in the future or blank (it has not been deployed)
e Must have the BIF Approved Collection set or have a BIF Completed Date in the
past (it has been technically qualified)
e Must not have the PTF action set (it has gone past CBIF)
e Must not have PTF dates (it has gone past CBIF)
e Must not be Targeted At as this means it has gone through PTF already
e Must not have a HDR Collection (or it has been to HDR anyway)
« 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
I 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 TIS
I Response Category — 120 -- Final -- Cloned to create Defect Peak
Response Category — 200 -- Final -- Call withdrawn by user
co Then, in turn, check these filters to build the 3 lists:
e — List.1 — high priority Live Defects:
™), Must be Priority A or B (highest impact defects)
e List 2 — Live Defects that originated from a POL ServiceNow bonded Incident:
= Must have a POL SNOW Reference
e 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)
PTF
o PTF is a Fujitsu internal meeting
o All Peaks with the PTF Action flag set will be reviewed at BIF
e This will include all defect Peaks with the ##LiveAffectingDefect tag
e It will also include other Peaks that may relate to other topics such as environments
or Peaks that the Developers wish to discuss at the forum
o. Ifa Peak needs to be re-presented at PTF then it will have the PTF Action flag set again
Page I 56
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o 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:
e« 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 ifthe Peak is iteratively presented for review and it will
allow reporting on whatwas 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
HDR
co There is anupdated 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
o Overview of the process:
‘© Fujitsu takes new items as Incidents to HDR not KBAs or Peaks
e 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
e Fujitsu embeds any relevant KBA or Peak content into the Incident it shares
e Fujitsu tags its Incidents and Peaks with the applicable HDR-* Cl or Collection tags
e 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
e If a 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
Page I 57
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
« Updates on potential Live Defects is provided via bonded Incident updates
« Updates on confirmed Live Defects is provided by defect Peak weekly reports
e 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)
e As this is an early warning 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
o Summary
e Potential HDR Defects will be reported automatically to POL via the service
management toolset replication driven by Fujitsu updates to the TfSNow Incident
e 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
e 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
e 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
o 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 tothe relevant POL third party
o POLwill probably convert the ServiceNow Incident to a ServiceNow Problem — but that is
their choice
o If Fujitsu completes its investigation and confirms there.is no HDR Defect then the
investigation Peak and Incident will beclosed 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
o For the purposes of Live Defect Management, Fujitsu will use Peak references not TfSNow
Problem references
co Fujitsu will provide its view of Status =from its systems — and manage any difference of
opinion with POL
o Fujitsu will provide weekly updates prior to the meeting
e Potential HDR Defects — no action required as the updates will already be in POL
SeryiceNow
« 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.
* CBlFynew.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
o 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
o 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
o 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
Page I 58
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
o The HDR minutes need an overhaul for Fujitsu. This is the Fujitsu specific meeting and yet it
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/TfSNow Incident
or defect Peak)
e They need to show Fujitsu’s latest update
e Asummary view at the top is needed - New, Open, Closed, by Severity, by area
affected, and trend
o 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 withyany
additional comments made during the meeting being added to the Incident.or defect Peak
co There is no definition of HDR in the contract — this needs to be addressed
HDR Submission Extract Criteria
o Asat the date of this document, the criteria to be used to determiné\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.
o Aspreadsheet format has been used to date so.the previous week's submission should be
used as the basis for the new report
o Filter on these values first:
« Must have the ##LiveAffectingDefect Collection (relates to the Live system and
does, or might, need a fix)
e Must have the either the HDR-Fin or HDR-Exp Collection (Collections contains HDR)
e Must have a Planned Out'Date inthe future or blank (it has 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
I Response Category — 94 -- Final - Advice and guidance given
" Response Category — 95 -- Final -- Advice after Investigation
I 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 TIS
Response Category — 120 -- Final -- Cloned to create Defect Peak
Response Category — 200 -- Final -- Call withdrawn by user
o List 1 — Deferred Live Defect Peaks
e Must also have the Collection “Deferral Agreed”
Page I 59
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e 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
e Extract the list showing:
= Category (HDR-Fin = Impact, HDR-Exp = Experience)
* Sort on 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
o Next Lists - non-Deferred Peaks
e Must NOT have the Collection “Deferral Agreed”
e List 2 — Project Live Defects.
= If clearly from a Project that is under 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:
e Category (HDR-Fin = Impact, HDR-Exp = Experience)
o Sort on this field
e POL Reference (N/A at this time)
* Fujitsu Reference (the Peak Call reference for Call Type #,
othenwise the TfSNow/ServiceNow Incident reference)
o Sort on this field too
se Summary
e Confirmed Defect (Call Type is # = Yes, otherwise No)
« Workaround
e 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 TfSNow/ServiceNow Incident update” as
this is where the latest status should be recorded
Page I 60
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
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 TfSNow
= 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:
e Category (HDR-Fin = Impact, HDR-Exp = Experience)
o Sort on this field
e POL Reference (this should be known unless the entry is new)
« Fujitsu Reference (the Peak Call reference for CalhType #,
otherwise the TfSNow/ServiceNow Incident or Problem reference)
o Sort on this field too
e Summary
« Confirmed Defect (Call Type is # = Yes, otherwise No)
« Workaround
« Business Impact (See Incident, latest)Problem record update, or
Business Impact field)
Bewrena I = I
KB — Info only
o The Fujitsu KB is an information repository used for Support purposes
o 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)
o KBAs do not need to be shared with POL as the tracking needs to be on the Peak and
Incident raised to progress them
o If the awareness or involvement of POL is applicable then there will be a TfSNow bonded
Incident and this willcontain all relevant parts of any KBA so that the Incident that POL see
is a suitable complete reference
o 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 61
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
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
Hioka S
“The fhe may change the functionality of the system and consequently POL wil be required to provide sation, and rating. to the
“The fx may need tobe done nt conjuncton wi changes performed by some of POL's other suppliers and POL wal need to manage and synchyonte that acy, I
“The fix may need to be done concurrenty wth a separate future planned change. due to the hwo fixes besng logically re
The foc may relate to active discussions between Fujisu and POL on a speci and topic and hence shoud be
Fujitsu does not beteve a xis a sensible option and seeks POL's agreement to record the cumstances ina KB only
Fest cout progress
iiese PIF progress
ib
bs
ct RH update
Page I 62
Version & Last updated: See file name
Document owner: Steve Browell
CBIF / HDR Diagram
If it isa Live Defect then
add the
LiveAffectingDefect Cl
If it is a HDR Incident
then add relevant Cl
Updates auto replicate
POL rely on ServiceNow
Page I 63
POA Improvements — Streams 1-4
FUJ00232729
FUJ00232729
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Incident — Peak — Defect — HDR — CBIF
Potential Defect
Investigation Peak
Confirmed Defect
~ POL Incident
[ServiceNow]
Bonded
Fujitsu Incident
(TfSNow]
If POL not
needed
ification
Fujitsu Internal
Version & Last updated
Document owner
Fujitsu Internal
Fujitsu Reports
HDR/CBIF, or
Continuous Improvement I
Live Defect Peak
Internal Live
Defect Peak
[Call Type changed
to “#"]
CBIF Peak
Deferred Live Peak
See file name
Steve Browell
All should be Call Type “#”
All should have the Collection
HitLiveAffectingDefect
If HDR then relevant Collection should be
added
Updates do not auto replicate
Updates are system driven by reports:
1. Live Defects with the HDR Collection -
for the HDR meeting
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
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Actions
System Changes
Fujitsu-d t-beli fix ible-optis d- seeks POL: tt
One-Time Actions
o =BIF
4. Tariq/Matt S — identify any documents that refer to BIF that need to be updated (e.g.
Work Instructions)
5. Steve Br- = look at amending the BIF references i in the contract documents
o 6CBIF
PF PF PRS
James/Steve Br — identify the POL obligations to provide references for rejected
proposals and ensure they are appropriately stored in Peak and on KBAs
Steve Br — look at amending the BIF references in the contract documents
@
Wt
Page I 64
Version & Last updated: See file name
Document owner Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
‘eB
o PTF
1 Mats she RTF Chale knewe1e-pay special attention te Peake witt-¢ HOR
Collection and these that have been to CBIF
3
4.
o HDR
1.
2.
3.
4.
5.
6. Steve Br — look at how HDR should be referenced. in the contract documents
New Ways of Working
o «BIF
.
* Mats thatthe BIF chair i they-must:
* “Ensure. t Priority i tly set
= Create any BIF minutes by using Peak queries that extract the fields required
o 6CBIF
e James -— 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 65
Version & Last updated: See file name
Document owner: Steve Browell
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
= The new CBIF date fields (Initial and Completed) will need to be completed
during, or after, the CBIF 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
e 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
= If the Peak can proceed as discussed then the PTF Action flag.will be set
= If the Peak is to be discussed next time (as POL wish to.seek wider feedback
within their own organisation) then the PTF Action flag will not be set 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 “63 -- Final -- Programme approved - No fix required”
o HDR
« Steve Br/Steve’Ba/Adam/Sandie — the meeting needs to be fed with a report shared
in advance for confirmed Live Defects and CBIF updates (potential Live Defects are
updated through the service management toolsets)
e Steve Ba/Adam/Sandie - Incidents in either Peak or TfSNow need to be robustly
managed and management will need to check and coach the teams
« Steve Ba/Adam/Sandie -— Incidents tagged with “HDR*” need to be intercepted early
and an alert sent to an agreed distribution list in both Fujitsu and POL
Page I 66
Version & Last updated See file n
Document owner Steve Bre
FU,
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 the ##LiveAffectingDefect Collection added.
Data Consistency & Accuracy
1.
2.
3.
[ALL] If the ##LiveAffectingDefect Collection is set, is it correct?
[ALL] If the ##LiveAffectingDefect is set then is progress to an outcome going as quickly as it
could?
[Defect Manager] Check for Peaks that have both HDR-* Collections and decide on the most
appropriate and remove the unnecessary one
[ALL] Peaks that have the following No Fault Found Response Category outcome should be
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 TfS
Response Category — 120 -- Final -- Cloned to create Defect Peak
Response Category — 200 -- Final — Call withdrawn by user
Note:The Response Category must be changed if this is not a No Fault Found outcome
[ALL] 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
[Release Management] All Peaks with Planned Out Live (Date Out Live field on Peak screens)
in the past should be Closed. The ‘fix’ has been deployed. If they are Status F then the Call
Logger or Call Logger Team manager should ensure these are closed
[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
co 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
[All] 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
Page I 67
Version & Last updated: See file n
Document owner Steve Bro
FUJ00232729
1J00232729
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Note: The Response Category must be changed if this is not a confirmed Live Defect
e [All] 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
e [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"”
« 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
e [All] Peaks with the ##LiveAffectingDefect Collection should be Call Type L or#. Where they
are not, the Call Type should be challenged and changed
e This can exclude Peaks where the Planned Out Live (Date Out Live fieldon Peak
screens) is in the past and the ‘fix’ has been deployed
e 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
e [All] Peaks need to accurately state the Product and Product Group as this will be used to
identify the system components to which Live Defects arevassociated
e [SSC] Peaks containing the HDR Collection that:
e Are not Call Type "#"
« Do not the Planned Out Live (Date Out Live field‘on Peak screens) in the past as the
‘fix’ has been deployed
e Are not closed as they had a No-Fault Found Response Category
e And were not Deferred
must have a TfSNow and a ServiceNow Incidentreference as they are under active
investigation and affect a POL branch so/POL must be aware through the service management
toolsets
e [SSC] Peaks containing the HDR Collection that are Call Type "#" may have a TfSNow 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
e [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
e [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
e 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
e [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 ‘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
Page I 68
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
e [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
e [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
e [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
e [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
e [Release Management] If a Peak has been to BIF it needs to have the BIFApproved or
BlFRejected collection added. If not then it should have the BIF Action flag set as it is. to be re-
presented
e [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 69
Version & Last updated See file n
Document owner Steve Bre
FUJ00232729
FUJ00232729
POA Improvements — Streams 1-4
Improved Ways of Working & Actions Required
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY (POA ONLY)
Appendix 8 - TSNow data anomaly checks
To ensure the data in TfSNow 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 TfSNow Incidents that have had the ##LiveAffectingDefect or any HDR-*
Configuration Items added.
Data Consistency & Accuracy
e [Defect Manager] Check TfSNow Incidents ...
Page I 70
updated See file name
Steve Browell
FUJ00232729
FUJ00232729
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 initial draft to build upon.
A fix for a Live Defect will NOT be progressed if at least THREE of the following conditions apply:
* The frequency of occurrence of the Live Defect is rare - less than TWICE perannum,
* The impact of the Live defect is minor — it does NOT affect branch operations:or Fujitsu
service delivery
« 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 time to remedy the Live Defect would have noticeable implications on other delivery
work — it would be an unwanted distraction of resources
* The Live Defect is in a part of the system that will be decommissioned before any fix could
be developed and deployed
* 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 seé.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 71
Version & Last updated See file n
Document owner Steve Bre