FUJ00232753
FUJ00232753
.
FUJITSU
shaping tomorrow with you
Live Defect Management on POA
An At-A-Glance guide
1 © 2021 FUJITSU
Document control (hidden slide)
Document Title: Live Defect Management At-A-Glance Guide
Document Reference: Peeeeibecdailiin
Abstract: An overview of the Live Defect Management process on the Post Office Account
DRAFT
Author & Dept Steve Browell
ij External Distribution: fiers}
Information vi . :
Classification: Fujitsu Restricted — Internal Use Only (see slide footers)
FUJ00232753
FUJ00232753
(ee)
FUJITSU
Fujitsu Restricte This slide is hidden and will not be displayed when your presentation is running
© 2021 FUJITSU
FUJ00232753
FUJ00232753
Abbreviations & Glossary (hidden slide) FUJITSU
= 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
= HDR Defect — Live Defects that affect, or have the potential to affect, branch operations (financial, experience, or end customer)
a Horizon Defect Review (HDR) — a weekly meeting with POL to review HDR Defects. POL need to know the HDR Defects and their status. They share this with postmasters. This is a very
important meeting that sees Fujitsu and POL aligned on the HDR Defects
a 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
a 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) — is a TfSNow Incident that describes the confirmed Live Defect that will be progressed by a Resolver Group that does not use Peak (e.g. Networks, Security, Unix)
= Potential Live Defect (Peak) — is a Live Defect that we are still looking into. There will likely be an investigation Peak open and probably a TfSNow Investigation Incident too. The Peak Call Type
should be “L”
LJ 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”
Ld 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”
a OTI — is the interface between Peak and TfSNow that allows Incidents to be transferred between the systems and updates to Incidents to replicate
= KBA - Knowledge Base Article. The term KEL is no longer to be used
This slide is hidden and will not be displayed when your presentation is running © 2021 FUJITSU
FUJ00232753
FUJ00232753
LDMoaP FUJITSU
= We work at pace to investigate and reach a confirmed outcome. Assigned Team owners to oversee. Some Assigned Teams do not have a clear owner
= Live service trumps Project work - for investigation and qualification - we land that message and we factor capacity accordingly. Teams escalate to management if there is conflict
m We always seek to identify a workaround - and we update the Peak Workaround reference to say Yes/No
™ ~~ Wealways look at rapid deployment options for HDR-*, Priority A/B (with implications & dependencies clearly stated). This MUST be considered at BIF and PTF
m Everything gets targeted to a numbered release fast - even if the release has no date
= We need maintenance windows and then we gear up to push through everything we can. And if we need more we ask POL. And if they say no, then the delay is on them.
= If all releases are numbered and sequenced then we can propose dates and ask for more slots from POL. If RM don't have a date then they need to go to whatever POL or POA forum is
applicable to get one
= We need a cadence of maintenance windows that are sensible and relevant to the rig availability and current resource availability. POL need to acknowledge that we need regular maintenance
windows irrespective of projects hogging rigs. If we are delaying fixes because of resources, rig availability or anything else then this has to be escalated so POL can decide to accept or
commission changes
= We need to revisit the option for maintenance releases to go to LST only - for pace
= HNG-A removed counter maintenance releases so CBA fixes sit waiting to match a functional release date
= LST implications for sequencing of testing releases need thought
= State the Assigned Teams and state and owner - and let them change it if it is incorrect
Investiga
&
Confirme
Live Integration
Defect
Defect Qualify
* TFSNow Incident +No action needed + Defect Peak + Solution review and + Target toa Release +Code/build solution + Package fixes * Confirm it works + Deploy to Live
-Investigation Peak + Raise Change + Solution being approval
+ Initiate Fix identified + Take to CBIF if
needed
4 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Background FUJITSU
POA has operated a Live Defect Management and Incident Management process
throughout the whole term of the contract
This slide deck takes all of the previous methods and augments them with some new fields
and field values that support an improved end to end process for Incidents and Defects
The new processes also align to the agreed 2021 definitions of a Live Defect and a branch
impacting defect which have been defined with POL
The effective management of Incidents and Defects requires the consistent use of systems
by all specialist support staff and also, regrettably, relies on many manual processes
The information in this slide deck is meant as a quick guide for all specialist support staff
(MAC, 3LS, 4LS & Architects) using either Peak or TfSNow
Specific communications have been held at team level and a Live Defect Management
guide document will shortly be released to Dimensions as a fuller description
Fujitsu Restricted ~ internal Use Only) 5 © 2021 FUJITSU
FUJ00232753
FUJ00232753
It all starts with an Incident being logged FUJITSU
@ 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 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
@ Incidents can relate to many aspects of the HNG-X solution but if they relate to
the Live system then they have the potential to be Live Defects
@ This may not be apparent at the outset so the situation will need to be under
constant review
@ If at any point the Incident is deemed to be a Live Defect, then the following slides
become relevant
Fujitsu Restricted — internal Use Only) 6 © 2021 FUJITSU
FUJ00232753
FUJ00232753
What is a Live Defect? FUJITSU
@ Live Defect
I] Is present ona LIVE system To ensure that Live Defects are easily
identifiable, support staff should do the
® Is within Fujitsu’s scope of obligations following:
& Is, or appears to be, inconsistent with the TFSNow — add the Lived ffectingDefect CI
agreed design or service specification Coan cad the MAL veAffectingDefect
@ Is, therefore, a fault that may need fixing
@ There may be a workaround, but the
underlying issue still meets the criteria
above
Fujitsu Restricted — internal Use Only) 7 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Live Defect progression... FUJITSU
@ A Live Defect will start out as a Potential Live Defect until sufficient
investigation has taken place
& Assuming that there is a fault, this will progress to be a Confirmed Live
Defect (if it is not a fault then the Live Defect will be closed)
& A Confirmed Live Defect will need to go through the POA processes
before the fix is eventually deployed to Live
& The flow below shows the progression path for a Live Defect
Potential Investiga Confirme
Live & Live Integration
Defect Qualify Defect
* TFSNow Incident +No action needed + Defect Peak + Solution review and + Target toa Release +Code/build solution + Package fixes * Confirm it works + Deploy to Live
-Investigation Peak + Raise Change + Solution being approval
+ Initiate Fix identified + Take to CBIF if
needed
Fujtsu Restricted ~ internal Use Only) 8 © 2021 FUJITSU
FUJ00232753
FUJ00232753
What is a HDR Defect? FUJITSU
@ Live Defects that affect, or have the potential to affect, branch operations
are known as HDR Defects
@ HDR Defects can only apply to the Live system and are a specific
classification of a Live Defect
@ HDR Defects are shared with POL and progress on them is reported
weekly
@ HDR Defects are the highest priority of Live Defect and are communicated
to postmasters by POL as part of its new ways of working
™ Progress on HDR Defects is highly visible
Fujitsu Restricted — internal Use Only) 9 © 2021 FUJITSU
FUJ00232753
FUJ00232753
. . fo?)
How do you identify a HDR Defect? FUJITSU
@ 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 To ensure that HDR Defects are
“HDR-Fin” Collection) easily identifiable, support staff
should do the following:
= 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” TfSNow — add the relevant HDR-* Cl
7 Peak — add the relevant HDR-*
Collection) .
Collection
= Affects, or has the potential to affect, the experience of a Post Office
customer or client (add the “HDR-Exp” Collection)
@ 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)
Fujitsu Restricted ~ internal Use Only) 10 © 2021 FUJITSU
FUJ00232753
FUJ00232753
HDR Live Defect Tracking & Reporting FUJITSU
@ HDR - tracks the whole lifecycle of HDR Defects
j
Potential Investiga Confirme
Live & Live Integration
Defect Qualify Defect
* TfSNow Incident +No action needed + Defect Peak * Solution review and + Target toa Release +Code/build solution + Package fixes * Confirm it works + Deploy to Live
‘Investigation Peak + Raise Change * Solution being approval
«Initiate Fix identified + Take to CBIF if
needed
"1 © 2021 FUJITSU
FUJ00232753
FUJ00232753
What about non-HDR Defects FUJITSU
& All Live Defects will follow the lifecycle shown
@ If they are non-HDR Defects then these will not be reported to POL but will
be reported on and managed by Fujitsu
Potential Investiga Confirme
Live & Live Integration
Defect Qualify Defect
+ TfSNow Incident +No action needed + Defect Peak + Solution review and + Target toa Release +Code/build solution + Package fixes + Confirm it works + Deploy to Live
‘Investigation Peak + Raise Change * Solution being approval
«Initiate Fix identified + Take to CBIF if
needed
FUJ00232753
FUJ00232753
Understanding the status of a Live Defect FUJITSU
@ To be able to effectively track and report on Live Defects, numerous fields
must be completed and maintained
@ This will vary depending on whether the Live Defect is being managed
through TfSNow or Peak
Fujitsu Restricted — internal Use Only) 13 © 2021 FUJITSU
FUJ00232753
FUJ00232753
TfSNow FUJITSU
m™ We do not reference KBAs, Peaks or internal content in TfSNow bonded Incidents. The TfSNow Incident must contain all relevant content
and be a comprehensive self-contained reference to the status of an Incident. The only Peak reference that should be added is for defect Peaks (if
applicable)
m™ The Summary field needs to be well worded and understandable by most readers as it will be used in reports for management and POL and will
affect the description fed to POL and into our own Peak system
We should not using separate emails to share progress that is not embedded into the Incident updates
Less qualified individuals may read Incident content so it must be well worded and should use language that is understandable to most readers
Anyone should be able to quickly determine the current status and the next action on an Incident so as to be in no doubt that the Incident is under
full control. The most effective way to do this is to make updates in “Additional comments (Customer visible)” that convey this message and avoid
updates that lack context
Category/Sub-category must not be changed on bonded Incidents or it will break the replication link
We should use the relevant open and close categories when handling Incidents — applying additional caution with bonded Incidents to use the
mutually agreed settings
The LiveAffectingDefect Cl is needed for Live Defects
The HDR* Cls are needed for special category Incidents and this will be set by Fujitsu management — and will trigger a new Fujitsu MAC
alerting process
The State field is important as it is now used to report status
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.” Is to be added. After 10 days, these Incidents should be closed
inydodalsWVork Instructions or process documents updating ta4eflect these changes © 2021 FUJITSU
Incident — Peak — Defect
Updates auto replicate
Updates do not show
Fujitsu Investigation Peak
or KBA reference
numbers.
POL rely on ServiceNow
Potential Defect
POL Incident
[ServiceNow]
Fujitsu Incident
[TTSNow]
Investigation
Peak
Fujitsu Internal
Cloned
confirm
added t
replicate
Peak
Not lnk
to cloneI
Confirmed
Defect
Eujitsu Internal
Live Defect Peak
[Call Type “#"]
create Detect Peak once
Defect Peak reference
Investigation Peak which wil
no replication from Defect,
to TISNow or ServiceNow so no need
Ace confirmed. Change Call Type to “#”
Live Defect Peak
[Call Type “#”]
FUJ00232753
FUJ00232753
FUJITSU
The Defect Peak will be
managed internally
through BIF, CBIF, PTF
and the SDLC
Updates to the Defect
Peak are NOT linked to a
TfSNow Incident so are
internal only
(Fujitsu Restricted — Internal Use Only )
15
© 2021 FUJITSU
FUJ00232753
FUJ00232753
Peak FUJITSU
New fields in Peak
m 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 showing location of Reference fields)
@ 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 showing location of Peak Incident Mauagement System PEE
Reference fields) Se :
™@ Workaround - to state “Yes/No” state if an accepted
workaround has been implemented. If the field is blank ae ae sara pase <a
or contains “No” then no workaround has been identified saa
Eapusted Fomaaioh] voy]
(see screenshot for how to set the value) ee an
16 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Updated RELEASE MGT tab FUJITSU
@ Release Mgt tab — Initial and Completed dates and text box - We need to know the stage we are at in the
fixing process, the date it initially entered the stage and when the stage was completed and the notes from
the meetings at which it was discussed (see screenshot)
tert curs sta ou: eee Magee Fou Sct ea ck
aa BORRTTTS Ceapied Dam DDABETTTY)
17 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Peak — critical fields and their values FUJITSU
® Collection #LiveAffectingDefect. This Collection
must be set when the Peak meets the criteria for a Live R@=ssessscotecess
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 ; Peak In:
DETAILS) ERERENGES paomucrs EVIDENCE Apict
applying (caiReieeae remaster
[Ret
JI Aad to Collection I
= 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
jee Identified, 30)
“= Tneldant Under Investigation
® Collections of “HDR-Fin” or “HDR-Exp” for HDR
Defects
i Add to Coliection
18 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Peak — important fields FUJITSU
& 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
= Summary — must be written so as to be understandable by most readers. This will need more thought when Peaks are raised.
Management should amend this during weekly clean-ups (careful to preserve links where raised in another system)
@ Impact -—tab and free form field to articulate impact, status and next steps so it is easy to understand for anyone. This will be
maintained for HDR Peaks weekly. For other Peaks it can be as needed
® Business impact: [as used currently, mention how many branches are affected if helpful]
= Status update: [description of current status — succinct]
® Next action: [next action to be taken and expected date for next update}...
pact text
Business impact: Prev and Cancel buttons are incorrectly made available to the Postmaster during the End-Of
Session script. Resulted in a Bureau Pre Order transaction being duplicated upon next login, causing a branch
accounts discrepancy. The discrepancy was raised by the Postmaster to Post Office for investigation. Fujitsu
have put monitoring in place which is checked on a weekly basis, and reported to Post Office if any further
occurrences are identified. A single instance of the issue has been identified over the last year.
Status update: Fujitsu have put monitoring in place which is checked on a weekly basis. The Defect has been
qualified, and Targeted At R71.20
‘Next action: Awaiting R71.20 counter release.
Priority — which must be validated at all times so it is accurately shown as this will affect reporting and decision making
Assigned Team — must show which team is currently responsible for taking the next action or ensuring action is taken
Product Group and Product - We need to know the part of the system that the Live Defect relates to for reporting and quality
purposes
CFrajisu Rest 19 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Peak updates — Internal & External FUJITSU
m@ When adding Progress to a ‘bonded’ Peak, the
default response option is ‘- Progress Only’ and
this does NOT flow back to TfSNow ——_>
= NOTE — but it would be visible if we were asked to
provide a copy of the Peak as the PDF feature takes
ALL content
@ Ifyou select a Response Category then any text
you add at the same time WILL flow back to
TfSNow if the Peak is ‘bonded’ (eee ian See
@ No References are sent to TfSNow for ‘bonded’
Peak, so all Documents, Baselines, KBs, and Ret Coat ini di
Peak references can be added for Fujitsu only pomcoea e sama cecegeu
access Caan eee)
Fujitsu Restricted ~ internal Use Only”) 20 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Peak — Root Cause & Response Category FUJITSU
™ 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
will exclude the following Root Cause values from Live Defects so these need to be applied with caution:
41 ~ Pending -- Product Error Diagnosed
42 ~ Pending -- Documentation Error Diagnosed
™ Response Category — specific values have been identified to enable clarity and to spot exclusions. Although there are
many values for this field, the following have important meanings — mostly is qualifying Live Defects as not defects and
hence allowing their exclusion from reporting:
62 -- Final - No fault in product
63 — Final ~ Programme Approved - No Fix Required
66 -- Final -- Enhancement Request
68 -- Final - Administrative Response
94 -- Final — Advice and guidance given
95 -- Final ~ Advice after Investigation
96 -- Final - Insufficient evidence
97 — Final — Unspecified insufficient evidence
98 -- Final — User error
100 ~ Final — Route call to TFS
120 -- Final - Cloned to create Defect Peak
200 -- Final - Call withdrawn by user
Fujitsu Restricted — internal Use Only)
21 © 2021 FUJITSU
FUJ00232753
FUJ00232753
Peak Cloning FUJITSU
& Cloning
= when clones are created you will be asked for a reason and this will be captured in the cloned Peak. Selecting “Create
a Defect Peak” will auto set the Call Type on the clone to “#”
You will also be asked to update the Summary so the description is unique and appropriate
Clones now carry forward many more fields (such as Collections, Reference, Workaround, and Release Mgt meeting
fields)
Date:11-Aug-2021 09:00:38 User: John Simpkins
Select Clone Reason: CALL PC@25@898 opened
(Create a Defect Peak
ISplit into multiple streams
Disassociate from TfsNow ticket
Test rig reasons
Details entered are:-
Summary:test mb problem
iCall Type:#
‘all Priority:D
Target Release:HNG-X 12.11
Routed to:EDSC - John Simpkins __
[Clon } Date:11-Aug-2021 09:00:38 User: John Simpkins
ss = Clone Reason: Create a Defect Peak
ate :14-Dec-2015 15:52:55 User: Customer Call_
ALL PC@244669 opened
Details entered are:-
summary:test mb problem
Other
Enter new clone Summary
22 © 2021 FUJITSU
Peak — No Fault Found
FUJ00232753
FUJ00232753
(ee)
FUJITSU
These Peak field values mean No Fault Found and will cause Peaks to be excluded when
counts are done of defects and progress on investigations into defects (see
SVM/SDM/PRO/0875):
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 TS
Response Category — 120 -- Final -- Goned to create Defect Peak
Response Category — 200 -- Final -- Call withdrawn by user
TfSNow may well
then show a defect
assigned toa
different Resolver
Group — but it has
ceased to be
something to track in
Peak
CFrjtsu Restricted ~ Internal Use Only ) 23
© 2021 FUJITSU
FUJ00232753
FUJ00232753
HDR reporting — directly from Peak/TfSNow FUJITSU
'PCO291532 I INC5S41788 : Failed Recoveries (AP cient data > 4,000 characters) - FULL I Yes, Business impact: Clerk will be unable to transact certain AP products, eg. National
FX Express, Drop n Go Open Account, MoneyGram, Bureau Pre-Order. The issue has
potential to occur due to APADC scripting caused by excessive length of exported AP
ent data > 4,000 characters.
‘Status update: Testing has been completed successfully.
Next action: Awaiting deployment in release 71.10.
00284005 I INCT712618 - FAD: 159405 St Annes 1598052 Bureau Pre Order Yes Business impact: Prev and Cancel buttons are incorrectly made available to the
‘Transaction ~node 2 Postmaster during the End-Of-Session script. Resulted in @ Bureau Pre Order
transaction being duplicated upon next login, causing a branch accounts
discrepancy. The discrepancy was raised by the Postmaster to Post Office for
investigation. Fujitsu have put monitoring in place which is checked on a weekly
basis, and reported to Post Office if any further occurrences are identified. A single
instance of the issue has been identified over the last year.
‘Status update: Fujitsu have put monitoring in place which is checked on a weekly
basis. The Defect has been qualified, and Targeted At R7i.20
Next action: Awaiting R73.20 counter release.
POORSEISS I INCEDE7IOT Inactivity logout for End-OF-Session scripts ms Business impact: Inactivity timeout during the End-Of Session script for 8
‘transaction where payment was being made by a cash withdrawal in the basket,
Fesulted in the transaction auto-setting to cash as per Business Rule BRU-327, but
‘outstanding recovery data resulted in a duplicate transaction being written,
‘resulting n'a branch accounts discrepancy. Fujtsu have put monitoring in place
‘which is checked on a weekly basis, and reported to Post Office if any further
‘occurrences are identified, A single instance of the issue has been identified over
the last year
‘Status update: Fujitsu have put monitoring in place which is checked on a weekly
basis. The options to remediate this defect were discussed with POL 21/07/2021
_and Fujitsu will also be sharing @ summary paper to heip POL.
‘Next action: POL to decide on its preferred course of action.
PRB0087806 I Help Screen Freezing on the Counters in Branches No Weekly problem update for the 19/07 that will be provided to Lorna Owens (POL)
Update: 19/07/2021: Matthew Hatch: Awaiting an update from POL with refer
103 POLactions.
nce
24 © 2021 FUJITSU
A checklist guide for Peak stack owners (and
Should this be in my stack? if not, then route it to the right Assigned
Team
Is the Peak assigned to the correct person (not off sick, still on POA)? If
not, then reassign it
my
Checklist guide for Peak stack management
stacl
rt specialists updoting Peaks}
Have discussions taken place over email or in meetings that should be
added to the Peak to ensure a full record is available?
How long is it since the Peak was raised ~ and is that acceptable or does a
review need doing?
FUJ00232753
FUJ00232753
FUJITSU
2 site potential Live Defect? Ifs0, add the #iLivetfectingDefect 1D Dothe latest updates read well and make sense? if not, change them and
Collection coach the crestor
if it is a potential Live Defect, what needs doing to progress it to Defect Dts it clear who (specifically) Is expected to take the next action? If not,
Identified or to qualify it as NOT a Live Defect? make it lear and notify the person expected to act
J itis Uve Defect, it should be Call Type “I” or “#”~s0 changeit if 1D Hfyou are waiting for someone external to your team to take action —
needed challenge them to make progress
OH itis Call Type “# - Defect Identified”, is it bonded to POL’s SNOW — if so, 0 Peaks with the following Response Categories that have the
it needs tobe cloned and then closed (tis okifit is only bonded to sLiveaffectingDefect Collection shouldbe Call Type “#” asa fxis
Tistiow) needed. Change it f necessary
2 sit, or could itbe, branch impacting ~ if s0, ad the HOR-Fin or HOR-Exp
Colleton {1 = Pending ~ Product Err Diagnosed
fit has a HOR-* Collection ~ is it being treated as high priority ~ 42 ~ Pending ~ Documentation Eror Diagnosed
regacdless of Priority field value? 2 Peaks that ae Status *F* should have an accurate Root Cause added
ifithas @ HOR-* Collection isthe Impact field up to date and well before being closed, Make sure itis undated
worded s0 that POL will understand 2 Peaks recenty closed with any ofthe following Response Categories are
ts the Workaround Reference added with Yes selected where a suitable deemed to have been No Fault Found with no fix action needed. Is this
workaround isn place? correct? f not, have the Peaks re-opened and corrected
Has anything changed that would mean the ##LiveaffectngDefect or
HOR” Caechns een longer ore and shoul bereaved? 62 Fiat - No feu in product
. Programme Approved ~ No Fx Required
remove them Enhancement Request
fits Defect identified, when will tbe taken to BIF? Set the IF Action Administrative Response
ifitis Defect identified, and has been approved at BIF, when wilt be Advice and guidance given
taken to PT? Set the PTF Action Advice after Investigation
2 ifit is Defect Identified, and has been Targeted in PTF, when will work Insufficient evidence
S 4 g Unspecified insufficient evidence
startto create the required fix? User enor
Is the Response Category correct? 100 ~ Final Route call to TIS
Is the Product and Product Group correct? Goned to create Defect Peak
2 When was it last updated — and is that an acceptable timespan? withdrawn by user
Fujitsu Restricted — internal Use Only ) 25 © 2021 FUJITSU
There’s an Incident in my TfSNow Assignment Group.
Checklist guide for TfSNow Assignment Groups
Should this be in my Assignment Group? If not, then route it to the
right Assignment Group
isthe incident assigned to the correct person (not off sick, still on
POA)? If not, then reassign it
© Isthe Summary field a clear description that others will
understand?
Ifthe Incident is not bonded to POL ServiceNow, does it have the
right Open category?
\s ita potential Live Defect? if so, add the LiveaffectingDefect Cl
If itis a potential Live Defect, what needs doing to progress it to a
confirmed defect or to qualify it as NOT a Live Defect?
Should POL be aware? if so, the incident will need to be logged by
‘MAC with the required specific Categories so it can be bonded to
POL ServiceNow so POL can be kept updated with progress
tsi, or could it be, branch impacting ~ if so, ensure MAC are asked
to add the HOR-Fin or HOR-Exp Ci
© ifithas a HDR-* Cl —is it being treated as high priority ~ regardless
of Priority field value?
1 fithas a HDR-* Cl ~is a recent entry in the “Additional comments
{Customer visible)” field up to date and well worded so that POL
will understand it?
Is the State field correctly set?
1s a workaround available (this will show in the Peak — if applicable
~as the Workaround Reference will be set to Yes}? f so, make sure
that the “Additional comments (Customer visible)” field clearly
states this ~ especially f this Incident is bonded to POL ServiceNow
oa
‘When was it last updated ~ and is that an acceptable timespan?
Have discussions taken place over email or in meetings that should
be added to the Incident to ensure a full record is available?
How long is it since the incident was raised — and is that acceptable
or does a review need doing?
Do the latest updates read well and make sense? if not, change
them and coach the creator
Ifthe incident is bonded to POL ServiceNow, does the latest update
to the “Additional comments (Customer visible)" field make it clear
to POL what the status is? If not, add an update that does
Is it clear who (specifically is expected to take the next action? if
not, make it clear and notify the person expected to act
If you ate waiting for someone external to your team to take action
~ challenge them to make progress
Is the Incident Suspended as no further Fujitsu action is needed? If
so, and after 10 working days have elapsed, the incident should be
closed
If the incident is being closed, ensure it has the right Closure code
and has the correct minimum dataset added (as per local work
Instructions):
© Line of Summary
Root Cause
Resolution
Internal/External
Fujitsu SME
© POL Stakeholder
Incidents recently closed should be checked. if they were closed
with no action required by Fujitsu, does the Incident clearly state
that? If they were closed following action taken by Fujitsu, does the
Incident clearly state that?
Has anything changed that would mean the #i#tLiveAffectingDefect °
‘or HDR-* Collections are no longer correct and should be removed?
If So, remove them
1D Afitis.a confirmed defect, when will the resolution action be taken
e.g. it inked to a TFSNow Change?
FUJ00232753
FUJ00232753
FUJITSU
nal Use Only )
26
© 2021 FUJITSU
FUJ00232753
FUJ00232753
Re)
FUJITSU
shaping tomorrow with you