POL00043691
POL00043691
‘Acceptance Incident Number (1)
211
Source @)
Acceptance Test Name @) Date Observed (4)
BSM 05/04/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Incident Type (7) -
Substantive fault
Other
Medium
Low
None
Description of Incident (10)
Receipts and payments do not equal on the cash account. The receipts total is differnt from the payments total
when printing off the cash account. This was originally thought to be a migration problem only however the fault
has now been replicated on a cash account following the migration week.
Witness / Reviewer Horizon Acceptance Pathway AIM
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
From Tohu Dicks
12/08/99 10:04 P:\O01public\Acceptance Incidents\wednesday 11 aug list.zip
Name Modified Size Ratio Packed Path
410-08-11.xls 11/08/99 14:46 24,064 73% 6,395
408-08-11.xls 11/08/99 18:10 23,040 75% 5,799
395-08-11.xIs 11/08/99 15:19 28,160 75% 7,020
394-08-11.xIs 11/08/99 14:53 21,504 76% 5,198
391-08-11.xls 11/08/99 15:14 34,816 71% 9,943
390-08-11.xIs° 11/08/99 15:13 22,528 75% 5,716
378-08-11.xls 11/08/99 14:38 20,992 76% 5,134
+376-08-09.xls 09/08/99 19:12 25,600 73% 6,854-
372-08-11.xls 11/08/99 14:58 25,088 73% 6,779
371-08-11.xIs 11/08/99 18:40 23,552 74% 6,097
© 369-08-11.xls 11/08/99 15:28 27,648 76% 6,717
3F368-08-11.xIs 11/08/99 15:02 22,016 76% 5,314
361-08-11.xls 11/08/99 18:38 27,136. 76% 6,627
342-08-11.xls 11/08/99 14:09 29,184 72% 8,077
314-08-11.xIs 11/08/99 15:59 24,064 76% 5,746
314-08-11.doc 11/08/99 16:31 27,136 81% 5,185 ‘
301-08-11.xls 11/08/99 15:24 24,064 74% 6,294
300-08-11.xls 11/08/9915:22 23,040 75% 5,696
*298-08-11.xls 11/08/99 16:48 27,648 72% 7,619
+ 298-08-11.doc 11/08/99 18:19 24,576 85% 3,587
#218-08-11.xls 11/08/99 20:16 21,504 77% 5,027
*218-08-11.doc 11/08/99 20:10 29,696 80% 6,069
211-08-11.xls 11/08/99 14:33 20,992 77% 4,886
23 file(s) 578,048 75% 141,779
13 AUG RRS- <0,
POL00043691
POL00043691
Acceptance Incident Number (1)
211
Analysis Sequence Number (2)
Acceptance Test Name (3)
High / Medium / Low (4)
None.
Authority 6)
POCL
introduced, via several CRs, into LT2.
Number of continuation pages
This incident, which we believe is related incident 315, has been fixed as part of the changes to the balancing process
Clearance Action (7)
POCL to close
=IResolved
I propose the Clearance Action
land Incident Status described
above
I accept / reject the Clearance
Action and Incident Status
described above
POL00043691
POL00043691
{ - - y
Acceptance Incident Number (1)
Swan seit 218
Acceptance Test Name (2) Source (3) Date Observed (4)
Implementation A - User Training/Doc Trial 19/05/99
Witness/Reviewer who observed Incident (Owner) (5) . Authority (6)
Graham Katon POCL
ott nt Severity. (9)ix'
High
Substantive fault Medium
Other . Low
None
Description of Incident (10) :
The Managers Training Course is not acceptable due to deficiencies in the accounting modules. In the live
environment the training given did not equip the users to perform the completion of office cash accounts. This is a
basis POCL function that is central to running and accounting for the POCL network.
Witness / Review cr Pathway i
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance .
Entered in Acceptance Database Date:
POL00043691
POL00043691
uhyny Acceprance Manger
inde Incident Afanoger
Acceptance Incident Number (1)
Analysis Sequence Number (2)
218
Acceptance Test Name (3)
Implementation A - User Training/Doc
Analysed: Incident Severity.(4) * High / Medium / Low (4) Authority (5)
Sit eh ON a None POCL
Analysis of Acceptance Incident (6)
Please sec accompanying text of letter to Bruce Mcniven
Clearance Action (7)
Bruce McNiven of 10 August has been responded to.
Pathway asks POCL to Close this incident.
IAll actions have now been completed satisfactorily and the review of the Acceptance Incident under cober of letter from
11 propose the Clearance Action
and Incident Status described
above CC Dicks BE 11th August
accept / reject the Clearance Horizon-Acceptance ss: Date:
Action and Incident Status rest Manger ey ae
ldescribed above etneracaas
Date:
DSS-Acceptance Manager. «
Date:
Date:
POL00043691
POL00043691
7
?
Mail - Received Mail
avila.smithi.__
Coombs MJB fe10152 9
john.meagher ({~---"~%
ruth.holleran!
bruce.mcniven}
john.dicks!
mike (u) coombs? ~~
Review of Acceptance Incident 218 - Training
10/08/1999 18:24
Dicks
Acceptance
Sender.....
Recipient...
Subject
Sent.
Attachments...
Reply Requested.
Folder.
In Reply To.
Read......
Reply Sent
Reply Requested by.
Delivered.
11/08/1999 08:39
10/08/1999 18:27
Priority. Normal
Sensitivity None
Status... Read
Importance Normal
Conversion Prohibited: No
Apologies, but I incorrectly sent this mail to you initially as I meant to
‘Save as Draft‘ and instead hit sent!
Please find attached, the final version of both documents which have been
updated since I initially sent it to you.
Sorry for any confusion.
Avila
(See attached file: Dicks 1008.doc) (See attached file: Acceptance
Incident 218.doc) .
POL00043691
POL00043691
John Dicks
Director, Customer Enquiries
_ ICL Pathway Limited
Forest Road
Feltham
Middlesex TW13 7EJ 10‘ August 1999
Dear John
Re: Review of Acceptance Incident 218 - Training
An analysis of the evaluation against the business impacts identified in the
Acceptance Incident is attached.
Although many of the criteria have been met, it is regarded as significant that the
training and go-live process relies on the deployment of POCL:'HFSO resource. On
the basis of this evaluation, we are not prepared to reduce the severity rating from
‘high’. :
POCLs view is that without this resource there would have to be a complete revision -
of the training approach in order to ensure helpdesks were not rendered ineffective
by the high level of calls following the first and, to some extent, subsequent balances.
POCLs view is that HFSO resource was not deployed as an extension of training.
The cost impact and diversion of resource which this requires must be addressed by
ICL Pathway. “
It is also POCLs view that the related adequacy of HSH support must be integrated
with this Acceptance Incident and removed as an additional source of concern.
The training improvements identified as part of the qualitative research by Post
Office Business Consultancy must also be addressed as part of a rectification plan.
Yours sincerely
Bruce McNiven
Director
Horizon Programme
cc. Mike Coombs, Chris French, Ruth Holleran, John Meagher
POL00043691
POL00043691
we
Horizon Incident Number 218 - Evaluation
1.
Criterion : 534/1
“Pathway’s Training solution shall take account of users experience in terms of automated products and platforms (ECCO+,
APT, ALPs) and their differing abilities to learn”.
2.
BUSINESS IMPACT
SUMMARY OF SUCCESS CRITERIA
MEASURE.
EVALUATION
1.
The Office Managers ability to
undertake daily balancing and
produce a cash account is adversely
impacted resulting in a failure to
support accurate POCL accounting.
This is a high severity impact on
POCL’s ability to perform its normal
business functions.
™ Reduction in the number of offices unable to
complete the cash account balance process
and produce a cash account balance (relative
to the sample).
™ Continuing or better level of success in the
pass rate of the Performance Standard
Assessment (PSA) test.
™ Performance Standard Assessment (PSA) to
reflect live operation and standard practices;
Horizon users complete PSA again on day 10.
™ Data from BSM telephone survey for balance
related to the 4‘ August contained the
following; 22 offices produced an account, 1
office had a two week cash account. This
criteria is therefore met.
™ Criteria met.
™@ Criteria met.
. The consequential effect is that the
amount of time taken to produce the
cash accounts is excessive in relation
to the time taken on the previous
(manual) system and significantly in
excess of POCLs expectations for the
service.
™ Reduction in time taken to produce a stock
unit balance , the office balance and finally
produce a cash account (relative to the
sample.
™ Balancing statistics for the 4" August Cash
Account indicate an overall reduction in time
taken to complete balances in both sub offices
and ECCO offices. Even at the reduced level,
concerns remain about overall balancing times.
POL00043691
POL00043691
BUSINESS IMPACT
SUMMARY OF SUCCESS CRITERIA
‘MEASURE
EVALUATION
3. The consequences are also that the
number of cash account related
incidents reported to POCL NBSC is
considerably greater than expected.
(About a third of the calls coming to
NBSC Help Desk indicate a lack of
understanding of the cash accounting
and balancing process). HSH are
responsible for resolving these service
incidents but are unable to cope with
the content and volume of calls which
are therefore having to be dealt with
by NBSC. As the Manger’s training
course is deficient, NBSC and
presumably HSH staff who receive
this training course, are also
inadequately trained.
™ Reduction in demand on support - Measured
through a reduction in the number of calls (at
the peak time on Wednesday evening and
Thursday morning) for advice and guidance
to support stock unit balancing, office
balancing and production of the cash account
received at the HSH and/or at the NBSC.
™ Reduction in the length of calls from the
. additional 25 offices.
™ The overall number of calls in weeks 1, 2 and3
by the LT2 offices showed a reduction on the
LT1 mirror offices for the equivalent three
weeks. .
The average number of calls made by offices
during the non-peak days also showed a
reduction.
However, it should be noted there is a significant
increase in.the 2% week cash account for both
LT1 and LT2 offices when there is no support at
these outlets, suggesting that some of the outlet
managers still do not have the confidence or
ability to complete the process unsupported.
™ The evidence to analyse this criteria is limited
and was regarded as indicative only. The broad
conclusion is that the evidence is insufficient to
make a substantive judgement regarding first
cash accounts but there is overall evidence to
suggest a reduction in call times for 2"4 cash
accounts. However, it again has to be noted that
the length of calls for both LT1 and LT2 offices
was significantly higher on 24 cash accounts
than the 1st cash account suggesting the critical ’
requirement for training to be
supported/ delivered by HSH. It also
underlines the necessity of the HFSO support to
balancing in week 1.
I
POL00043691
POL00043691
BUSINESS IMPACT
SUMMARY OF SUCCESS CRITERIA
MEASURE
EVALUATION
4. The practical effect of the incident is
also causing the HFSO’s to devote a
disproportionate amount of time to
. support the outlets on cash accounts.
The number of HFSOs that would be
required to support National Roll-Out
would be significantly greater than
currently envisaged (initial indications
" are that two to three times as many
HFSOs as planned would be required.
This compounds the major impact on
POCLs resources.
™ No specific success criteria was identified to
address this business impact. Overall, POCL
would wish to reduce the cost of extended
training support at outlets through HFSOs.
™ POCL are now planning for 100% support of
first cash accounts and recognise that significant
additional support may be required for second
and subsequent balances at some offices. This is
a cost and resource drain on POCL. It is also a
change to the original HFSO role which was to
support the KPI delivery for POCL and to
accelerate the learning curve at outlets. POCL
concerns on this impact remain.
wo
. There is also an impact on TP who are
having to process a significant
increase in errors on Class and Pivot
(up to 3 times as many weekly errors).
This is having a significant impact on
resources in TP during the live trial.
These errors will also raise liability
issues between the POCL and
subpostmasters, and POCL and client
organisations.
™ Reduction in both the number of incidents
where Receipts do not equal Payments and
. Incidents where balance B/F does not equal
balance due to PO on previous Cash Account.
™ Reduction in the number of errors reported
by TP - both CLASS and PIVOT errors
(relative to the sample).
™ Overall, the incidents of receipts not equal to
payments have reduced and the residual causes
are under investigation or have been resolved.
Criteria met.
™ The level of CLASS errors between 26th May and
21s‘ July has reduced. Without full information,
the indications are that PIVOT errors have also
reduced.
POL00043691
POL00043691
3. Qualitative Measures
3.1 Although the small sample size of 18 responses limits the validity of the findings, some significant improvements were found in
comparison to Live Trial 1 (a sample of 102). Overall, attitudes towards Horizon are better at the LT2 offices compared to the
LT1 experience. The key outstanding issues to ‘emerge from research were as follows:
& The course is still considered to be too short and intensive. ICL have proposed a pre-training course but details are
awaited. . .
@ The need to further stream the training groups. This issue has not been addressed by Pathway beyond the streaming
required by POCL for ECCO+ staff. Pathway’s response is to do this wherever possible. There are impacts on the
number of training places. .
® Variation in trainer quality. Discussions taking place between POCL and ICL Pathway to look at how there can be a
greater quality assurance for trainer ability and consistency of delivering the course specification.
™ There are significant problems with technical and software faults in the training sessions. POCL regard these are
significant issues which will require rectification.
HADATA\WORD\Horizon\ Acceptance Incident 218.doc
POL00043691
POL00043691
ra '
ef
Bruce McNiven
POCL
20-23 Greville Streer
London
ECIN 8SS
11 August 1999 4
Dear Bruce
Thank you for you letter of 10 August.
Pathway is convinced that it has done everything that it can to
improve the training and prepare users for Horizon, and that the
essence of the remaining issues that you are seeking to address
relate to POCL’s own management of change. This was made
clear to Bruce McNiven in correspondence from John Bennett
(KP/99Jul339 dated 7" July 99) and a second letter to Bruce
McNiven (dated 25" June £99). .
Pathway has consistently maintained that user confidence in the
system will be achieved only through managing the change in
POCL business processes such that POCL’s target standard
approach is adopted across the Post Office network. Until this
achieved by POCL, it, will be necessary for POCL to substitute
additional support in one-form or another. Increased use of the
revised training, which is now a very suitable vehicle, is one such
form. Another is the gradual dissemination of the target business
process through POCL’s own support, however provided, to the
balancing business process. ‘
For these reasons, Pathway believes the Acceptance Incident 218,
which formally relates to training, should now be closed.
Pathway does not accept that any further revisions to the training
courses, other than routine minor improvements already
identified, are required, or indeed are now desirable in light of the
commitments made by both parties to revised courses and
collateral.
POL00043691
POL00043691
-2-
Pathway has made every effort to make changes to the training to
POCL’s satisfaction throughout live trial, such thar every course
has been significantly changed. Furthermore, an additional 24
outlets were installed in July, at POCL’s request, to form a basis on
which the effectiveness of the training improvements could be —
and indeed have been - demonstrated.- At every stage POCL has
had complete approval authority for the changes being made and
has registered its satisfaction with the results of these changes.
The narrative below details the extensive steps taken by Pathway,
with POCL approval, to address the concerns expressed in AI 218.
Counter Manager & Counter Assistant courses revised
In response to feedback received from POCL and formally through
CR R0052b, ICL Pathway has made a large number of detailed
changes to both the Counter Manager and Counter Assistant
training courses. Crucially, the Counter Manager (CM) course
was much modified to improve coverage and an emphasis placed
on the balancing business process and related issues. The CM
course now devotes much of Day 2 (Workbook 10) to this process
and considerable time is spent explaining the process and checking
the understanding of the delegates.
Both the CM and CA courses have been observed and positively
received by POCL and approved to go forward to National
Rollout including routine minor improyements (Trevor Rollason’s
Email to Andy Barkham of 10/8/99) which Pathway are only too _
pleased to incorporate.
ICL Pathway believes that the improved CM training better
prepares Outlet managers for the task of balancing when they
return to the outlet. This improved training, coupled with
~ changes to the way that Horizon now handles the balancing
process, makes achieving a balance much easier than during Live
Trial and the comparative success of the extra 24-outlets bears this
out. :
HESO course revised
POCL requested several changes to the HFSO training progranime
in their CR ROOGO. This CR requested changes to the content of
the course, the introduction of a new 4-day MiMAN course and a
new 1-day MiECCO course. These new courses provide more
opportunities to practice the migration processes and to work with
different error detection/correction scenarios ~ all of which add
value to the migration process.
Additionally, ICL Pathway retrained HFSOs during Live Trial to
provide more training on balancing and related topics.
POL00043691
POL00043691
é. '
Since Live Trial, ICL Pathway has developed a new three-day
course for HFSOs that runs after the POCL induction training and
before the 4-5 day HFSO course. This extended course
(previously it was a two-day event) provides in-depth coverage of
balancing; the cash account; reversals; use of the suspense account
and error detection and correction.
This new course has been very well received by POCL observers
(Ann Cocker and Graham Young) and POCL HFSOs alike, who
were pleased that their comments from Live Trial were taken
onboard.
HESO role positioning
The HFSO role has always been pivotal to the success of the
programme. In addition to performing migration (a vital function
which sets the scene for the first balance) the HFSO also provides
help and support to the Outlet Manager at what can be a Stressful
and trying time. At the point of installation the Outlet Manager
comes face to face with the Horizon system.for the first time since
training and will, naturally, be anxious, even apprehensive. It is
important that the HFSO helps the Outlet Manager to complete
the migration process effectively and in accordance with the
defined processes.
Extra trainers for balancing support
On a weekly basis since Live Trial, ICL Pathway has been
providing additional balancing support through the use of ICL TS
trainers. ICL Pathway has borne this cost in recognition of the
need to enhance support levels at the HSH and NBSC.
Extra Transition Executives (TEs)
The Transition Executive role exists primarily to provide expert
help and support to the HFSOs. Since Live Trial, an extra TE has
been added to each IP region bringing the total of TEs to eight -
thus doubling the initial size of this team.
HSH 8 NBSC training
ICL Pathway has trained HSH and NBSC staff in the revised
processes and systems embodied in LT2. This training was.
targeted at those topics most frequently calling for helpdesk
assistance.
CRs/Balancing process changes
A number of changes to the Horizon system and the. way that it
deals with balancing were implemented in LT2. These changes
sought to make balancing easier and to remove unnecessary steps
from balancing processes and procedures.
POL00043691
“4.
QRGs and workbooks
The Quick Reference Guides and Training Workbooks have been
revised to reflect the new courses and also best practice. These
QRGs and Workbooks have been signed-off by POCL for use in
NRO.
Yours sincerely
©" John Dicks ‘
Director, Customer Requirements
Copies: Chris French, Ruth Holleran, John Meagher
Mike Coombs
POL00043691
POL00043691
POL00043691
"] Acceptance Incident Number (1)
3 . 298
‘Acceptance Test Name (2) Source (3) Date Observed (4)
POCL Infrastructure BSM 01/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Jeremy Folkes
Tneident Type (7) lerioniReference (8), E
Substantive fault Medium
Other Low
None
Description of Incident (10) :
Evidence from the Live Trial shows that the counter system is subject to "lockups" and “screen freezes", where the
system halts in mid-processing giving the user no opportunity to take any corrective action. This is either exhibited
iby the system hanging or presenting a blank blue screen. The user is forced to ring the HSH and is advised to reboot]
the system. The immediate effect of this problem is in terms of the reliability of the Service Infrastructure’s input
devices. However, once the underlying reasons for the problem are identified, this could change the perception.At
least 25 such occurrences have been identified on the LTSC log between the start of the Core Observation Period
jon 31st May and the 28th June. However, as such problems should be reported directly to the HSH, it is likely that
{this number represents only a small proportion of the total in which case, this problem would be widespread.
Consequently, POCL’s initial assessment is that this incident is likely to be more than low severity.
“Signatures (11) .°
1 efit
Witness / Reviewer Horizon Acceptance
Test Manager
Pathway
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance .
Entered in Acceptance Database Date:
POL00043691
POL00043691
‘\feibe'conipteted I
Feat eal
be given
Acceptance Incident Number (1) Analysis Sequence Number (2)
298
Acceptance Test Name (3)
POCL Infrastructure
Analysed Incident. Severl High/ Medium 7 Low (4) Authority (5)
Analysis of Acceptance Incident (6)
System faults reported to the Horizon System Helpdesk on Wednesday/Thursdays for the past 12 weeks have been
analysed. The reason for only reporting on Wed/Thurs figures is that these have been monitored over an extended period
lof time, and do represent the “worst case" figures. Figures for each day are now monitored (as from the end of July).
'The HSH calls analysed are provided on the Worksheet "HSH Call Analysis".
These figures continue to be monitored but clearly show that the number of "lockouts" and frozen screens has fallen to the
lowest figure for the past 12 weeks since the introduction of LT2.
This will continue to be monitored, but should be reduced to Low severity om the basis of the progress shown.
Clearance Action (7) .
Pathway will continue to investigate the root cause of residual occurrences and a further formal ‘review undertaken on
completion of the fist three months of roll-out.
On the basis of further information provided by POCL (the telephone survey) on 6 August and Pathway’s selective re-
survey conducted 9-10 August, Pathway has carried out further analysis and testing and has identified no fault conditions
fas at the 11/8/99. See separate document.
On the basis of the significant progress to date Pathway expects this Al to be recategorised by both POCL and Pathway as
Low, by Wednesday 11/8.
Pathway points out that even ifall offices were to reboot their counters prior to balancing every week the impact level
would be that specified for a Medium severity incident. The time taken to reboot a gateway counter is typically no more
AMPH Of Agtinuation pages
Acceptance Incident Status (Open! Resolved
Analysed RetesURecommended for KPR (8) '
igiaturess
I propose the Clearance Action
and Incident Status described
above John Dicks
Taccept/ reject the Clearance I
Action and Incident Status
described above
1th August 1999
Date:
IHoriz
- }POCE Busi
aero eras
DSS Acceptance Manage
POL00043691
POL00043691
,
feootn
Criteria
Criteria Descripti
536 - 01
Peripheral and input devices supplied as part of the elements of the Service Infrastructure on which OPS is
provided shall be reliable, robust and easy to use
Page 3
System Faults Identified from HSH call log: LT1 & LT2 - Analysis of Wedneesday & Thursday HSH Calls received
Call analysis taken using Wednesday and Thursday calls from each week as received by HSH,
With effect trom Friday 23.07.99. the call analysis at this level will be completed daily and reported weekly (Friday to Thursday calls)x,
LT2 sites shown as shaded
Y
Types of Fault
203 19220 2627 02/03 09/10 167 23724
May I May I May I June I June I June I June {30/01 July]0708 July}.
Lock Out: Clerks reports that they are unable to
[continue ta operate the system
Frozen Sercen: Clerks reports that they are
unable to continue to operate system
Blue Sereen: Screen goes blue preventing the clerk
from continuing to operate the system YJ 1 2 6 3 3 0 2 5
Blank screen: Screen goes blank preventing the cler . ;
from continuing to operate the system i} 0 0 oO 0 1 0 - 2 1
Totals
~Lu-] 4] 2 7 45 7 33 7 27 7 13 7 30] 21
Eevewal Renal
Numbers of Live Outlets
T 198 I 241 I 289 I 299 I 299 I 299 I 299 [ 299 I~“299
Faults per Live Outlet
[006 [006 [005] 016] O12] 01 I 005] O11 I 0.08
SF i
[0.09 I 0.06 I 0.02
POL00043691
POL00043691
POL00043691
POL00043691
Reboots without calling the HSHD
It is undoubtedly the case that outlets are rebooting their counters without calling the
HSH.
Using the POCL telephone survey data supplied by POCL on 6/8 its was possible to re-
survey more closely the outlets not calling the HSHD before rebooting and by inspection
of the associated message stores seek to understand the reasons why outlet staff are
habitually rebooting.
Pathway will also in the immediate future and on a random basis contact outlets that are
rebooting so that a real fault unknown to us at present is not overlooked.
The question posed by POCL was not sufficiently specific to discriminate between
several classes of problem. Pathway CS has asked-POCL to make the questions used on
the survey more specific and would ask that the comment reason field is completed if at
all possible.
Why are outlets rebooting?
In general, rebooting is seen — incorrectly - as a “cure for all ills” and understandably
outlet staff will not always be ready to expend. time reporting to the HSHD a course of
action they have already embarked upon.
The reboots that are recorded and that are not associated with a call to the HSHD do
include cases where the system unit is being tured on after having-been tuned off
overnight or in error during the day. Although instructions are clear not to tum off
system units, it is clearly the case that staff do tum them off, as was evidenced by the
- difficulties Pathway had in upgrading counters to LT2.
Where a user has made a mistake, he may choose to reboot instead of Undo-ing an
uncommitted transaction or Reversing a committed one. In the latter case a reversal
would/will still be required, but it is possible that this may not be understood. It is not
possible for Pathway to distinguish this case from the message store record.
A user may get into a thought “loop” whereby he cannot see how to return to a desired
state and reboots to wipe the slate clean and have another try. There are several instances
of the user having been coached through such a thought loop by the HSHD. -Again, itis
not possible for Pathway to distinguish this case from the message store récord.
In some offices we believe the keyboard is being used as an auxiliary work surface with
books and manuals being placed on it. It is possible that if'a key or key is permanently
pressed the counter will exhibit symptoms of being frozen, although it should be possible
to unfreeze it after a short delay. Similarly it is not possible for Pathway to distinguish
this case from the message store record.
POL00043691
POL00043691
It is possible that printers being replenished with paper are not responding to resume the
printing for some seconds, although they will in fact resume when the user retries form
the screen button.
Pathway’s search for faults
Pathway, nevertheless accepts there are probably significant residual faults in the system
that could present themselves as a “freeze” and is working hard to find them. At the time
of preparing this report none has been found. Consideration is being given to increasing
the swap file size, although testing has eliminated this as a specific cause.
Jecd
11/8
POL00043691
POL00043691
; Agee tance-Incident: Ormynaee, ‘Acceptance Incident Number (1)
wash é 300
“Acceptance Test Name (2) Source (3) Date Observed (4)
POCL Infrastructure BSM 01/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Jeremy Folkes
Incident Type (7)
536-01 High
Substantive fault Medium
Other Low
None
Description of Incident (10)
Evidence from the Live Trial indicates that should the printer fail during operation, the’ system may lock up rather
than handling the error normally. This has been observed even when the printer has only run out of paper.The
immediate effect of this problem is in terms of the reliability of the Service Infrastructure’s peripheral and input
devices. However, once the underlying reasons for the problem are identified, this could change the
perception.Several occurrences have been identified on the LTSC log between the start of the Core Observation
Period on 31st May and the 28th June. As such problems should be reported directly to the HSH, it is likely that this
represents only a small fraction of the total, in which case this problem would be widespread. Consequently,
POCL’s initial assessment is that this incident is likely to be more than low severity.
Signatures (11):
Witness / Reviewer Horizon Acceptance Pathway AIM
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
Acceptance Incident Number (1) [Analysis Sequence Number (2)
300
Acceptance Test Name (3)
POCL Infrastructure
High / Medium / Low (4) ‘Authority (3)
: A None
Analysis of Acceptance Incident (6) . a
Most of the wording on this incident is generic wording pasted into a number of incidents.
Pathway are not aware of any incidents where physical printer failure (paper out, paper jam etc) has caused the system to
lock.
‘The procedures for dealing with routine printer failures are covered in the counter procedures documentation The topic
was also covered at the Horizon Pathway Delivery Mecting held at Gavrelle House on 3rd August. The minutes to that
meeting include a Pathway report on printer best practices.
[Number/of continuation pages
Clearance Action (7)
We request that POCL close this Al by Wednesday 11/8 unless they can indicate particular incidents not covered by
IAI298.
POCL has agreed to consider this.
I propose the Clearance Action '
and Incident Status described ee Bie J
above : P. John Pope Beier 11th August 1999
I accept / reject the Clearance sascha Date:
Action and Incident Status ~ irestivtanajer restive ze Ve
described above eae eae ee :
of cp n i : Date:
SSIPO E Business Assarancet
Date:
POL00043691
POL00043691
Criteria
Criteria Descriptions
536-01
provided shall be reliable, robust and easy to use
Peripheral and input devices supplied as part of the elements of the Service Infrastructure on which OPS is
POL00043691
POL00043691
’ »
ae wy
‘Acceptance Incident Number (1)
301
“Acceptance Test Name (2) a Source@) Date Observed (4)
POCL Infrastructure * BSM 01/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Jeremy Folkes
Substantive fault
Other
Description of Incident (10)
Evidence from the Live Trail indicates that if'a process fails due to a printer failure, the accounting data within the
office may suffer a loss of integrity. The principal effect isa loss of accounting data integrity. Other effects include:
considerable extra work by the counter (and potentially support staff) to resolve problem; loss of confidence in the
lsystem;- undermining of evidential quality of system outputs.Several occurrences have been identified on the LTSC
. flog between the start of the Core Observation Period on 31st May and the 28th June. As such problems should be
reported directly to the HSH, it is likely that this represents only a small fraction of the total, in which case this
problem would be widespread. Consequently, POCL’s initial assessment is that this incident is likely to be more
than low severity. .
Horizon Acceptance
: Pathway I ‘AIM
. ‘Test Manager . i.
Date: Date: Date:
Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date: ~
POL00043691
POL00043691
Acceptance Incide, ‘be completed by the ICL: Pathway Acceptance Manag
* Iteibe given to the Horizon Acceptance Incident Manager’
Acceptance Incident Number (1) Analysis Sequence Number (2)
301
Acceptance Test Name (3)
POCL Infrastructure
High / Medium / Low (4) Authority (5)
None
I. Analysed Incident-Severit
Analysis of Acceptance Incident (6) .
We are not aware of any process failures (associated with printer failure or otherwise) that would result in a loss of the
integrity of the accounting data within an outlet.
As this Incident was raised prior to the implementation of LT2 in the outlets, and as much.of it is generic wording common
to a number of Incidents, we suggest that this incident should be closed and, if it should prove necessary, a new incident
citing specific instances of failure of the LT2 software should be raised.
By
Number of continuation pages "425
Clearance Action (7)
Pathway expects POCL to close this incident by Wednesday 11/8.
POCL has agreed to consider closing this incident by 11/8 as it is already covered by AI 211.
Resolved
PS RB:
Date: 11th August 1999
land Incident Status described
above P. John Pope
I accept / reject the Clearance
Action and Incident Status
described above
Date:
Horizon Acceptance Incident Mariager-
DSS Acceptance Manager-~\:
POL00043691
POL00043691
Criteria
iteria Descrip
472-04
The imegrity and security of data held within OPS shall not be compromised by any Incident nor when OPS is re-
established following any Incident.
1820 - 03
EPOSS shall ensure that, following an Incident, or if operationally desirable for any other reason
(a) the user can return to a complete and recent position .
\(b) no corruption of secured data has occurred
(c) a full recovery can be effected swiftly and in an auditable manner
1820 - 07
IEPOSS shall ensure that in the event of a failure of any part of the Service Infrastructure, Recovery can be
performed to a known position and with the minimum of disruption to the User. Data re-entry shall be minimal
where previously committed Transactions have to be re-entered ‘ :
820 - 08 :
EPOSS shall warn the User where there is the possibility that data are corrupt
828 - 01 :
The confidentiality, integrity, validity and completeness of data shall be maintained throughout all storage,
processes and transmissions, including during periods of Service Failure and recovery from Service Failure.
PS - 43
The confidentiality, integrity, validity and completeness of data shall be maintained throughout all storage,
processes and transmissions, including during periods of Service Failure and recovery from Service Failure.
[R828]
891-11
Outlet accounting information shall reconcile, taking account of Stock and cash brought forward, carried forward,
Transaction data and local suspense items (as defined in the EPOSS requirements). This shall also be sustained in
fall-back and during Recovery after any Service Failure.
Page 3
POL00043691
POL00043691
we
ete
+I Acceptance Incident Number (1)
314
Source (3) Date Observed (4)
POCL Infrastructure Review 15/06/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Bob Booth
Substantive fault Medium
Other Low
None
Description of Incident (10)
The above criteria refer to the requirement for Pathway to supply detailed technical documentation which will allow]
POCL to procure applications from a third party supplier.
IAt the time the POCL Infrastructure Acceptance Specification was being agreed it was recognised that the technical
documentation to support it did not exist. Therefore POCL agreed that Pathway could provide the documentation at
fa later date. Furthermore it was understood that Pathway were allowed to put forward their proposal as to how this
criteria would be met in the future.
[The main document cited was the ICL Pathway Extemal Applications Procurement Policy’ which detailed an
approach as to how they would work with a third party supplier. However this document still does not meet the
criteria as they stand today.
Furthermore the other cited references, ‘Counter Hardware Design Specification’, ‘OPS Architecture Document’ and !
'TMS Architecture Document’ do not mect the criteria as being clearly defined technical documentation.
Providing third party documentation as with ‘Riposte 32 API Specification’ indicates that the documentation is not
maintained by Pathway and therefore docs not fully meet the criteria.
In summary the documentation provided is not sufficiently detailed to allow POCL to procure applications from a
third party supplier.
Horizon Acceptance [Pathway AIM
‘Test Manager
Witness / Reviewer
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
leled by ELCU Railway Acceptance Managers:
a ance Incident MesageN SMO
bes
toibe given tothe Hort
‘Acceptance Incident Number (1) [Analysis Sequence Number (2)
314
Acceptance Test Name (3)
POCL Infrastructure
Analysed Incident-Severity-(4)°.. -INone/Low Authority (5)
Analysis of Acceptance Incident (6) =
Please see attached document.
Clearance Action (7)
POCL to review revised analysis and recategorise this incident.
POL00043691
POL00043691
ae
+6
Signatures
Setter
I propose the Clearance Action
and Incident Status described
above
J CC Dicks
Date: 11/8/99
T accept / reject the Clearance
Action and Incident Status
described above
Date:
POL00043691
POL00043691
4. Criteria
[e Descriptions
1469 - O01
The technical documentation concerning OPS and the elements of the Service Infrastructure used to provide OPS
shall be suitable to allow POCL to procure applications which utilise OPS or hardware which interfaces with OPS.
These procurements shall not necessarily be from Pathway.
469 - 02
Pathway shall provide technical documentation concerning OPS and the elements of the Service Infrastructure
used to provide OPS.
470 - 01
Pathway shall provide technical documentation conceming TMS and the elements of the Service Infrastructure
lused to provide TMS.
470 - 02
IThe technical documentation concerning TMS and the elements of the Service Infrastructure used to provide TMS
shall be suitable to allow POCL to procure applications which utilise TMS. These procurements shall not
necessarily be from Pathway
1869 - 05
IThe CONTRACTOR shall maintain detailed technical documentation of the interfaces from TMS to PAS, CMS,
OPS and all attachable elements of the Service Infrastructure.
AL 314 additional analysis
This additional analysis is in response to comments on Pathway document “ICL Pathway
Extemal Applications Procurement Policy”, Version 0.1, 25/5/99, (CR/POL/004), which
were received 6/8/99.
Criteria within scope
Criterion 869/5, though touching on similar aspects to Criteria 469/1-2 and 470/1-2, does
not relate to the provision of technical documentation for application procurement
support, (it relates to boundary performance assessment). It is included within th scope
of this analysis on the basis of an agreement that it is a proper subset of Criteria 469/1
and 470/2
Provision of technical documentation
The specific technical documentation to be provided was defined in the associated
Solutions 469 and 470 and has, in fact, been substantially provided. Moreover, additional
material has also been provided as is shown in the POCL Infrastructure Acceptance Pack,
see POCL Infrastructure Acceptance Pack — Segment 5, 28/5/99.
Under 469/2 Pathway undertook to provide:
OPS Architecture Document
OPS API Document
Counter Hardware Specification Document
Under 470/1 Pathway undertook to provide:
~ TMS Architecture Document
TMS API Document
TMS Hardware Specification
All of these documents, except the last listed, have already been provided. Nevertheless,
the contents of the last mentioned is provided within the Asset Register under the
Codified Agreement.
Two of these documents are substantially sourced from a supplier. Pathway affirms that
it will maintain these as versions of ES/IFS/003, ES/IFS/004.
Therefore Criteria 469/2, 470/1 and 869/5 cannot be considered under this Acceptance
Incident.
Pathway role in relation to application procurement
The burden of the comments provided on 6/8 is that POCL does not see a role for ICL
Pathway to participate in the early stages of the introduction of a particular application.
POL00043691
POL00043691
POL00043691
POL00043691
This is, POCL believes, because it would constrain competition and give Pathway an
unfair advantage if Pathway subsequently was asked to bid as a supplier in the
procurement itself.
Altention is drawn to Clause 211 of the Codified Agreement. Probably the most
important applications to be introduced will be the subject of Clause 211. Under this
provision, POCL has,committed to work with ICL Pathway to revive and continue the
discussions with a view to developing a business strategy for the introduction of Network
Banking and Modern Government applications. The comments provided appear to
indicate that this provision has not been acknowledged by POCL in this context.
There is also the “normal” case of POCL procuring an application from Pathway via
normal Change Control.
To the extent that Clause 211 does not apply, either because the applications under
consideration are not those envisaged by Clause 211, or because the joint work does not
come to a successful conclusion, then ICL Pathway believes that Requirements - and
Solutions - 469 and 470 are intended to apply. -
In preparing CR/POL/004, Version 0.1, ICL Pathway was addressing the need to ensure
that ICL Pathway is able to accommodate the preparation, deployment and operation of
an application on the ICL Pathway Service platform and that technical and operational
integrity is not compromised by a third party application. The areas to be covered, be
they hardware or software oriented, are:
Programme Management, Business Requirements, Systems Design, Application Design,
Implementation, Application Test & Integration, Systems Integration, Systems Test, .
Type Approval, Business Acceptance, Manufacture, Distribution, Installation,
Maintenance, Service Reporting, Invoicing.
Whether these activities are addressed with Pathway early or late in an application’s
business cycle is the fundamental point at issue. ICL Pathway had proceeded on the
assumption that delays and nugatory work would be less if issues were addressed as early
as possible.. However, if POCL believes that addressing such issues early would confer
an unfair advantage on ICL Pathway then ICL Pathway is content to leave such
considerations to be addressed at a time and in such manner as may be determined by
POCL.
Regardless of the point in time during the procurement cycle that ICL Pathway is notified
of a procurement, ICL Pathway has a legitimate right to guaranteed participation and.
authority in certain of these activities if its Service commitments are not to be .
compromised. In other activities Pathway may or may not be involved, and in some
others Pathway will not want to participate.
Accordingly Pathway will revise CR/POL/004 to this effect.
POL00043691
POL00043691
Suitability and sufficiency of technical documentation
Pathway contends that the documents provided are suitable for use by a reasonably
competent IT services provider in relation to designing and implementing an application
utilising the Services in question.
Therefore Criteria 469/1 and 470/2 cannot be considered under this Acceptance Incident.
In addition to the formal conformance with the Criteria, there is also the practical point as
to whether these documents are sufficient for procuring applications that make use of
Services other than OPS and TMS, scope which is outside of the contracted Requirement.
Pathway’s contention here is that the needs of a third party supplier cannot be known
except with reference to nature of the particular application.
This can be illustrated through consideration of a hypothetical application that is exactly
the same as APS. The service provider would also require a good deal of technical and
other information that is application specific: AP Client Specifications, Token
Technology Specifications, HAPS Interface Specification, business rules in relation to
EPOSS, and any interfaces it may need outside of TMS and APS. ICL Pathway cannot
meet certain of these needs because it is not the owner of such information, and could
possibly meet others, particularly in relation to Services other than OPS and TMS.
In the cases of other hypothetical applications it is possible that Pathway could be the
information authority. For example the third party application might need specific
information about the way in which Service Level and Remedy information is collected
within the Pathway system because it may be agreed that the application will rely on
Pathway Invoicing and SLAM systems. In fact the service provider might require more
than documentary information, for example test data.
Accordingly ICL Pathway will revise CR/POL/004 such that Pathway will not be
responsible to the procurement authority for the Programme Management activity but
will be guaranteed participation in the Programme Management activity (at a point in
time determined by POCL) and will provide suitable representation at Programme
meetings. The Programme Management activity will be defined to contain the definition
of additional documentation or services to be provided by Pathway.
Jecd
10/8
POL00043691
POL00043691
Acceptance Incident Number (1)
342
Acceptance Test Name (2) Source (3) Date Observed (4)
TIP Interface Trial 02/06/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Martin Box
Substantive fault Medium
Other Low
None
Description of Incident (10)
Incidents have been raised by TIP re. the late delivery of transactions files and cash accounts imo TIP, i.e. after Day
ID. These constitute 30+ transaction files from various Organisational Units and 2 cash account files. The main
concem here is that it is POCL/TIP who are doing the chasing and not Pathway. We would have expected Pathway
ito be more proactive in the late file delivery area. Late delivery means that various POCL back end processes
cannot be completed to agreed timescales. POCL/TIP/Transaction Processing needs to understand why this situation
was allowed to happen. POCL/TIP needs to be presented with the processes, procedures and any software fixes that
fare to be put in place to eradicate this problem.
Incidents have been raised by TIP in respect of Transaction Files and Client Transmission Summary files not being
received at all on the expected dates. This is significant as the daily time slot for the TIP operation was missed and
the files in question had to be processed when received. This meant that TIP had to play "catch up" and also meant
that certain deadlines within the back end operation had to be extended to accommodate Pathway’s failure to
deliver. POCL/TIP/Transaction Processing/Settlement needs to understand why this situation was allowed to
happen. POCL/TIP needs to be presented with the processes, procedures and any software fixes that are to be put in
place to eradicate this problem.
An incident has been raised by TIP in relation to all files for a day not being delivered until after the agreed
processing time, i.e. placed on the server by Pathway at 03:44. This is significant as the daily time slot for the TIP
operation was missed and that days files had to be processed the following evening. This meant that TIP had to play
catch up" and also meant that certain deadlines within the back end operation had to be extended to accommodate
/Pathway’s failure. POCL/TIP/Transaction Processing/Settlement needs to understand why this situation was allowed
ito happen. POCL/TIP needs to be presented with the processes, procedures and any software fixes that are to be put
in place to eradicate this problem.
c
Witness / Reviewer Horizon Acceptance Pathway AIM
‘Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager
POCL Business Assurance
Entered in Acceptance Database
Date:
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
342
Acceptance Test Name (3)
TIP Interface
Tigh / Medium / Low (4) ‘Authority (5)
© Low
Analysis of Acceptance Incident (6)
IAll incidents identified by TIP relating to file and/or transaction delivery were reviewed at Chesterfield (29/7/99); a further,
incident (TIP889 — 3/8) is under investigation. Incidents fall into two categories, plus a further question relating to FTMS.
gateway file housekeeping.
1, Delayed transaction delivery from outlets.
Transactions are not harvested from Outlets in the following circumstances:
1, One or more Counter PCs cannot be synchronised with the Gateway PC at the post office. This may be because they
have a fault, or because they have been switched off.
2. Ata single counter post office, there is a fault with the mirror disk
3. Failure of the Gateway PC
4. Failure to communicate via the ISDN line
These ‘conditions are characterised by there not being an End of Day marker in the central journal file for the Outlet
concerned (“non-polled post office”).
The facility to monitor and report on non-polled outlets was part of the BES harvesting suite, removed following DSS
withdrawal. Since then an ad-hoc database analysis has becn in place to identify such outlets and a new ongoing reporting
system is in the process of introduction (CP2078) to produce an automatic report which is emailed daily to the Business
Support Unit who log an incident with the HSH for immediate investigation.
2. Files delivered late from the TPS.Hosts to TIP
This can happen if fault has occurred during the processing cycle such that the delays incurred mean that the production
and transmission of the files for TIP in not in line with the SLAs.
‘The majority of incidents reported under this category have occurred during failover testing between Wigan and Bootle
sites, which represent exceptional circumstances and are not representative of normal systems operation.
3. File Housekeeping on FTMS gateway servers
‘The housekeeping in the FTMS servers has been corrected (PINICL 27537) to ensure that files for each Service (c.g. TIP)
are only held for the period set out,in the corresponding AIS. This is documented in "Pathway to Post Office Technical
Specification" ref. TIMFS/008 section 6.2.3. Details of the parameters for the file retention period are given in the internal
design document "FTMS Configurations for Pathway TPS and POCL TIP Links at Release 2" (ref. TD/ON/005).
Number of continuation pages
Clearance Action (7)
This is essentially the same as that proposed for AI371, relating to HAPS SLA.
Procedures Required
Procedures are required to cover the following.
1. An incident to be raised with the Horizon System Helpdesk at the earliest appropriate time when an Outlet is not polled,
2. Pathway to produce daily (internal) reports monitoring the transmission of the TIP files, the numbers of files and the
umes of transmission and receipt acknowledgement.
POL00043691
POL00043691
athway to produce daily (internal) reports monitoring the transmission of the TIP files. the numbers of files and the
times of transmission and receipt acknowledgement.
Ce Changes Required
1, An automatic report to be produced overnight to detect instances of non-polled post offices, and an email report
automatically sent to the Business Support Unit (BSU). This daily report will list:
I- Date of report .
- FAD code ‘
}- Date since the Outlet was last polled
This will be implemented during CSR as an urgent development.
[Note = This facility has been developed and is expected to be Released shortly.)
{The BSU will follow the new procedure sct out in the “New Procedures” section below.
New Procedures
a. Non-Polled Outlets
1. The BSU have implemented a new procedure whereby they report incidents of non-polled post offices to the HSH. This
is currently done on receipt of a manually produced report of non-polled post offices. This report is duc to be produced
automatically (see item 2 in “Program Changes Required”.
Status: This procedure has been implemented. It is possible to email’a copy of this manually produced report to a central
POCL Service Management function as an interim measure before the procedure set out in item 2 below is available.
2. Customer Services require a procedure whereby they update the “On-Line Problem Management Database” Web Page.
Web Page, which is accessible to POCL Service Management, and lists various problem issues. This
will cnable the TIP team to enquire on non-polled post offices.
Status: This procedure has been agreed and will be implemented when the automatically produced non-polled report is
available (see item 2 Program Changes Required).
b. Central Processing Delays
1, A draft copy of the Interim Transaction Information Processing System ICL Pathway Operating Level dated 15/03/99)
has been sent to POCL for review. In discussions, TIP have indicated that they do not require advance warning of potential
delays in TIP files being sent to TIP. There are contractual remedies if Pathway fail to meet the SLA timescales.
Status: The Operating Level Agreement is in draft form and Pathway is waiting on POCL for comments. The draft OLA
does not include provision for Pathway Operations to inform TIP Operations of likely delays in the transmission of TIP
(files. :
2. Pathway OSD have implemented a new procedure whereby they produce a daily Operations Service Management
Report. .
Status: This is for internal Service Management only, but does show the transmission of the TIP files, the numbers of files
land the times of transmission and receipt acknowledgement.
Pathway believes that the actions put in place provide adequate assurance that appropriate procedures exist for dealing
with potential service delivery problems on an ongoing basis. If SLAs are not met, for any Teason, remedies will apply as
per G10. Schedule. Specific ongoing monitoring of non-polled outlets can be continued via the mechanism described
above, if desired by TIP. .
On this basis Pathway believes the incident is, in effect, resolved, but are prepared to accept ongoing monitoring for an
agreed period under a severity categorisation of “low".
POCL committed to review this Al on 12/8/99.
Number of continuation pages .
Acceptance Incident Status (Open! Resolved
Analyseu RelesURecomumended Tor KER)
Signatures: -
POL00043691
POL00043691
1 propose the Clearance Action
and Incident Status described
above
D.Hollingsworth for John [Fey
Pope
Date:1 1/8/99
Taccept// reject the Clearance
Action and Incident Status
described above
wane
ABCEs
Date:
Date:
POL00043691
POL00043691
pita Weare] Acceptance Incident Number (1)
a ENA oer eee 4 : 361
Acceptance Test Name (2) Source (3) Date Observed (4)
TIP Interface BSM ~ 30/06/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Martin Box
Substantive fault Medium
Other Low
Pending,
one
Description of Incident (10)
New Description: Incidents have been raised by TIP in respect of duplicate records / files sent across the interface
from Pathway to TIP. TIP correctly rejects the files in these instances. It is concerning. that the Pathway solution
allows duplicate transaction records to be generated. Pathway are aware that duplicate records contravene the AIS
protocol. Other incidents relate to the fallback / contingency arrangements within the Pathway domain where
duplicate files were generated. This has caused numerous hours of investigation by TIP and would become
unmanageable at National Rollout levels.
Severity: POCL - medium - many hours to investigate each problem. POCL to monitor when fix is in place.
PWY - accept the problem exists. Don't really argue with the medium rating.
_IRectification: Steve Warwick to provide rectification of this issue. A fix for this is in the Pathway domain. Steve
ito provide details as to dates for download to the outlets.
Horizon Acceptance Pathway
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
fad REICH Pahony Acceptance Mating
ers
Hest ENON
Acceptance Incident: nt Analysis, Form: :
‘1 5 iB tb be given'to the’ Monson Acceptance: ncident ‘Mandates
Acceptance Incident Number (1) Analysis Sequence Number (2)
361
Acceptance Test Name (3)
TIP Interface
Analysed ‘Incident'Severity (4)... High / Medium / Low (4) ‘Authority (5)
“ ‘ & 5 Low
Analysis of Acceptance Incident (6)
This incident now excludes duplicate AP sequence numbers, which are now covered by 395.
The remaining incidents are already closed within Horizon except for the one conceming multiple identical events, where
the issue is not that the software has crroncously created duplicate records for a single event, but that there are multiple
separate events producing identical records - an example was caused by thousands of log on attempts duc to a permanently
depressed enter key giving rise to events so close together as to have identical time stamps.
4
Pathway have now agreed to enhance the system to filter out such identical events to avoid TIP erroncously categorizing
them as duplicates and consequently rejecting files.
Niimber‘of-continuation pages =<:
Clearance Action (7)
Pathway argue that the residual issue was not in fact a fault, and so the incident should be CLOSED.
Pathway would in any case argue that the impact of the residual issue were it to be deemed a fault would be Low.
The agreed system enhancement has been tested within Pathway and was delivered to live on 3rd August. We are not
* Jaware of any further incidents.
Resolved
I propose the Clearance Action
land Incident Status described
above P. John Pope
Taccept / reject the Clearance
Action and Incident Status
described above
11th August 1999.
Date:
ager». Date:
Date: Date:
POL00043691
POL00043691
—
Acceptance Incident:Analys Breit.
Acceptance Taeident Number (1) Analysis Sequence Number (2) a
361 1
‘Acceptance Test Namie (3)
TIP Interface
High/ Medium / Low (4) Authority (5)
None
rectified,
Incident 9905110226 was software error, now fixed. 9905210206 was duplicate events when issuing order books, now
fixed. 9905280170 was sofiware error now fixed. 9906220033 (APS sequence nos.) was a software error now fixed.
9906280140 was software error now fixed. 9906280141 & 9906290187 were errors associated with a one off situation of
switching Bootle/Wigan (in this case also in conjunction with a problem within TIP conceming the treatment of previously I
received files).
The underlying root cause PINICLs have all been closed with fixes applied 25086 (OBCS - LT1), 25348 (duplicate cash
a/c lines - LT2), 27012/26835/26752 (all duplicates relating to Duplicate APS sequence nos - LT2). The sole exception is
26928 (which relates to the occurrence and treatment of potentially repeating / duplicate events) which required resolution
with TIP over how they wished repeated events to be treated. TIP have indicated they want these screened out (this
confirmation was required since repeated events can legitimately occur) and a fix to introduce this screening has ben
produced, tested and the release note is currently in preparation.
Number'of:continuationipag
Clearance Action (7) Closure
7 I propose the Clearance Action
land Incident Status described
above
T accept / reject the Clearance
[Action and Incident Status
described above
Date:
Horizon Accept in
POL00043691
POL00043691
a *
7 "a
Acceptance Incident Number (1)
f 368
Acceptance Test Name (2) Source (3) Date Observed (4)
Security BSM 20/07/99
Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
Jeremy Folkes
Incident Type (7)
Dyce
Leica PS-22, 698-03, High
Substantive fault Medium
Other ; Low
None
Description of Incident (10) .
‘The computer room at Lytham St Annes, supporting the ICL Outsourcing Tivoli operation, is not physically secure.
In particular, the air conditioning arrangements for the room arc based on leaving the window open, and even when
closed, the window offers inadequate security for the nature of the contents.
Note: We understand that steps are now being taken to rectify this defect, with the installation of security mesh over
ithe window, however we are told that this work will not be completed until after the end of the Core Observation
Period.
I: Signatures 11)",
Witness / Reviewer Horizon Acceptance Pathway
Test Manager
Date: : Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
red in Acceptance Data Date:
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
Acceptance Test Name (3)
Security
"Auialyseddneldent Se “High fedium/ Low (4) I- Authority (5)
“Analysis of “Acceptance Incident (6)
The analysis is contained in the incident description on page 1. The area of concem is the external windows i inJ Block in
the quadrangle area on the Lytham site. The requirement is to have security grills fitted to the external windows.
Numibervof-continwationpapeskcaN i esM aac
Clearance Action (7)
It has been confirmed by Martine Bowes of the Lytham Estate Services Group that the grills are expected to be delivered
land fitted by 12/8/99. Pathway will notify POCL when the work is complete and will Close the incident.
I propose the Clearance Action Date: 11/8/99
* Jand Incident Status described ; .
above Dave Jones
T accept / reject the Clearance
Action and Incident Status
described above
Date:
ROCESS
POL00043691
POL00043691
a «
he @
Acceptance Incident Number (1)
foe e ‘ 3 369
Acceptance Test Name (2) Source (3) Date Observed (4)
POCL Infrastructure: BSM 20/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
David McLaughlin
ident ‘ype @ eriom\Relerts (8). 3 jneldent
536-01
High
Substantive fault Medium
Other Low
None
Description of Incident (10)
The scanner reliability is questionable in relation to OBCS transactions where there has been a high number of
rejections of pension and allowance books.
Witness / Reviewer Horizon Acceptance Pathway AIM
‘Test Manager
Date: Date: Date:
Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
a oth
ae:
Acceptance Incident Number (1) Analysis Sequence Number (2)
369
‘Acceptance Test Name (3)
POCL Infrastructure
High / Medium / Low (4) Authority (5)
None
Analysis of Acceptance Incident (6) -
A problem with scanning OBCS bar codes was first notified in November 1998 by HSH following an.increase in calls
from PMs regarding impounded order books. The books concemed had a new type of printed bar code and so the problem
\was initially attributed to the new method of printing adopted by BA.
Although problems were originally believed to be confined to one print run in November and calls relating to problem did
cease by mid-December, calls re-emerged in late December. Further tests in carly January revealed that the problem could
be caused by a change to the paper. 5
In mid-January, PIRA examined the paper supplics and concluded that the relative humidity levels of paper were 7% when
the acceptable industry level is 5.3%. In addition, it was found that the necessary ink-hardening agent was not present in
the paper. Arrangements were made for the immediate replacement of the hardening agent and for new supplies of paper
to be tested.
In early February, a temporary procedure was introduced by POCL that involved treating the order book as a non bar-
coded book. This procedure is still in place. Tests undertaken by Welch Allyn on behalf of ICL Pathway in mid-February
concluded that the problems resulted from the poor print quality of the bar codes.
In March, BA received new supplies of paper. However, in mid-April, it was confirmed that these provided little
improvement in paper quality. Further paper was ordered from another supplier. In late-May it was advised that more
positive results had been obtained using this paper.
In early June, BA provided the view that the ESNS scanner used by ALPS had greater tolerance than Horizon scanner. In
late June, BA provided evidence that some bar codes could be read with the ESNS scanner but not with the Horizon
scanner. However, it was confirmed that the Horizon scanner did accord with the agreed specification and those problems
did not occur before November 1998.
Tests of bar codes continuc to be undertaken by both BA and Pathway. Pathway is currently awaiting confirmation from
POCL that the tests carried out carlier this year by BA were compliant to ‘Code 3 of 9” standard bar codes and that their
tests have included the original paper and ink combination. Currently, ICL Pathway is beginning tests on a batch of 90
barcodes received from BA via POCL. The majority is being tested at BRAOI using both the ESNS and OBCS scanner,
but two have been forwarded to Welch Allyn (vid the Implementation team at KIDO1) for verification/ validation of the
bar codes compliance with the agreed standard.
Number. of:continuation'pages::
Clearance Action (7)
At present ICL Pathway does not believe that sufficient evidence has been provided that the bar cole scanner is operating
lout of specification and request that this Incident is closed.
ICL
con
Pa way and POCL are continuing to investigate DSS's concerns, and ongoing management of these issues will
¢ via our respective Service Managment groups.
POL00043691
POL00043691
I propose the Clearance Action Date: 29/7/99
and Incident Status described
above D.Cooke
T accept / reject the Clearance
Action and Incident Status
described above
Date:
Date:
eae
Date: Date:
Horizon-Acceptance In
DSS Acceptance Mai 1a
POL00043691
POL00043691
4 oA
RS 4 4 So
eo Incident Analysis
Acceptance Incident Number (1) Analysis Sequence Number (2)
369
Acceptance Test Name (3)
POCL Infrastructure.
Analysed Incident Severity (4)° High / Medium / Low (4) Authority (5)
sf wae Ake None
Analysis of Acceptance Incident (6)
We have carried out the test on 90 books reffered to in the previous analysis, and found the scanner tq be reliable.
IA brief report is attached
bees] 2
Clearance Action (7)
POCL to reconsider severity in'the light of the satisfactory Pathway report by 11/8.
Signatures:
1} propose the Clearance Action 11th August 1999
and Incident Status described
above P. John Pope
1 accept / reject the Clearance oi ‘Aecep Date:
Action and Incident Status
described above
eepiance Incident Manager... - Date:
Date:
POL00043691
POL00043691
ICL Pathway Ref: OTT/TST2/0062
+ ie A f Version: 0.1
Testing of alternative scanners with new foils. Author: KSAU
Date: 08/12/99
Title : Testing of both Pathway scanner and ALPS scanner against a batch of new OBCS foils.
Release Note : NIA PinICL / ChangeProposal : N/A
Pre Fix Test Completed Date : N/A Tested By: N/A
Post Fix Test Completed Date: 30/7/99 Tested BY: KSAU
Result of Testing : Scanning new foils : PASS Tested By: KSAU
Use of ALPS scanners : FAIL
Problem description .
Apparently, there have been problems scanning some of the newer OBCS foils. POCL believe that the scanners used on the ALPS
counters are more tolerant. It is therefore necessary to carry out some comparative testing using both types of scanner against a
batch of new foils,
Test script *
: ( .
Origtacr Se wt
1. Connect ALP. 9)
The cable supplie nal power supply.
This is totally di ud anda
piggyback plug to} counter is used
for the Touch Sere
Although the cable ling around the
cable and plug me: s, it was possible
to ‘modify’ a Path
Unfortunately, altk ” . yee . ose proximity to
a bar code, no data
Tt was not therefon
nv
Scan new foils using old and new Pathway scanners.
The terms old and new do not refer to different types of scanners, only different aged ones.
One off Serial No. M-50, with S/W rev level 5.1. 1=*=D=].2, and one off Serial No. N-15 with S/W rev. level
5.1.1=*=F=1,2,
Using the M-50 Pathway scanner, each of the 90 supplicd foils a MINIMUM of five times, this, resulted in 450+ successful
scans, no fails, .
‘The above operation was then repeated using scanner N-15, again 450+ successful scans with no fails.
3. Test scanners on mutilated foils.
Five of the new foils were damaged in various ways; folding, screwing up, rolling into a tube, soaking in coffee and soft
di
Itwas necessary to flatten out the worst of the creases in some of the foils but all could be read without significant difficulty.
scammer report COMMERCIAL IN CONFIDENCE Page I of 2
©1997 ICL Pathway Ltd
POL00043691
POL00043691
«out
“cL Pathway _ Ref OTT/TST2/0063
Testing of alternative scanners with new foils. V anon: Ke Au
Author: KSA
Date: 08/12/99
Conclusion
Based on the testing carried out, there is no evidence to suggest that the existing scanners cannot read the new types of OBCS foil
either when they are brand new and shiny or after they have been subjected to various degrees of abuse.
scanner report COMMERCIAL IN CONFIDENCE Page 2 of 2
“© 1997 ICL. Pathway Lid .
POL00043691
POL00043691
ICL Pathway
Testing of alternative scanners with new foils. KSAU
-
08/12/99 @
Title: Reliability test of Pathway scanner against a batch of new OBCS foils.
Release Note : N/A PinICL / ChangeProposal : N/A
Pre Fix Test Completed Date : N/A Tested By: N/A
Post Fix Test Completed Date: 30/7/99 Tested By: KSAU
Result of Testing : Scanning new foils : PASS Tested By: KSAU
Summary
Pathway have tested both old and new scanners on a batch of new OBCS foils. Even after degradation of
the foils by coffee, cola and physical abuse the scanners read all foils successfully. We conclude that the
Pathway scanner is therefore at least as reliable as the APS scanner.
Background t
1. Scan new foil
The terms old aj (ever keer by PI eP ¢ ve Se wt .
One off Serial N evel
5.1.1=*5F=1.2, °
Using the M-501 450+ successful
scans, no fails.
The above operat
2. Test scanners
. Five of the new fi
drink.
Wg un a cuuc, sUaKing In coffee and soft
It was necessary to flatten out the worst of the creases in some of the foils but all could be read without significant difficulty.
Conclusion
Based on the testing carried out, there is no evidence to suggest that the existing scanners cannot read the new types of OBCS foil
cither when they are brand new and shiny or after they have been subjected to various degrees of abuse.
scanner report = pip COMMERCIAL IN CONFIDENCE Page 1 of 1
41997 ICL. Pathway Lad
POL00043691
POL00043691
tach
Nga Ge
‘Acceptance Incident Number (1)
: ; : 371
“Acceptance Test Name (2) ‘ Source (3) Date Observed (4)
APS . BSM 13/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
_Bob ces
1891-02, 891-09, "$90: 02, 890-01 a
High
Substantive fault Medium
Other Low
None
Description of Incident (10)
Late transactionsTransactionis have been identified in the HAPS system as being more jan 9 days old. NB
investigations into the cause have been ongoing for some time. There appear to be a number of short falls in
‘exception reporting. It was not reported that transactions were not being retrieved from an outlet for over a week.It
was not reported that the system was processing transactioris outside the service levels in schedule E08.It was not
identified that an outlet had hardware problems outside maintenance agreements.
26/06/99 For 23/06 transactions were harvested that were older than day D. (OSG: 126 HSH: E-9906240223)
This shows that ICL Pathway are delivering transactions that are more than 10 days old. This contravenes SLA
Schedule E08.
Same for 02/07/99 OSG: 131 HSH: £-9907050027
Same for 13/07/99 OSG: 136 HSH: E-9907140067
Pathway”
Horizon Acceptance
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database . Date:
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
371
Acceptance Test Name (3)
High / Medium / Low (4) Authority (5)
Low
alysed'Incident Severit;
Analysis of Acceptance Incident (6)
ICL Pathway acknowledge that there have been a number of situations where an Outlets transactions have not been sent to
HAPS for greater then 9 days, and that the reporting of these occurences has not been satisfactory.
Of the incidents quoted :-
OSG 126 - This was caused by a Hardware failure resolved on 1/7, which resulted in End of Day not being set.
OSG - 131 - This was caused by intermittent comms failure resolved on 2/7 which resulted in End of Day not being
receicvd.
OSG - 136 - This was caused by a combination of the LT2 upgrade causing late HAPS harvesting and two outlets
experiencing network problems. Information provided to POCL on these issues and this was closed on 29/7/99.
In all of the above the HAPS harvesting operation and transmission operated correctly. Outlet transactions were missing,
from these transmissions due cither to End of Day markers not being set or not being received in the Data Centre.
Conceming the reporting of these incidents, ICL Customer Services will shortly have access to a daily report advising,
those outlets whose End of Day marker has not been received, and therefore whose transactions will not be forwarded to
HAPS. This infornation will be discussed with POCL.
In the interim, the End of Day status is being determined by manual analysis of the message store and this is proving
satisfactory.
NUinber’ ae ‘continuation’ pages
Clearance Action (7)
ICL Pathway propose this incident is closed based on the satisafctory interim procedures, and the planned introduction of a
daily report.
ISce report dated 6/8/99 updating incident, describing new procedures including production of daily report.
As agreed and actioned at the Acceptance review 10/8 Pathway has provided reports for the last five working days. POCL.
fare actioned to correlate their reports with these and to Close this incident.
POL00043691
POL00043691
raed
CON ea
Sane
‘
a z
I propose the Clearance Action D. Cooke Ter Path Date: 29/7/99
land Incident Status described [update by Tony Hayward anaes jJupdated on 6/08/99
above . (pp D Cooke)
T accept / reject the Clearance .
Rosner cai
Action and Incident Status : Festivtinas Trees a
es
aan NSA eANE
Susingss Assurance,
SONYA ase T Nd RWC Sal
updated on 11/8/99.
Date:
POL00043691
POL00043691
Guat
an ae
=] Acceptance Incident Number (1) e@
372
Acceptance Test Name (2) Source (3) Date Observed (4)
POCL Infrastructure . BSM 20/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Rod Stocker
: eNO
High
Substantive fault , Medium
Other Low
None
Description of Incident (10)
The contractor shall carry out system management of all the Services in a consistent and coherent manner to ensure
the following: *
Ib) changes to the Services can be made speedily and accurately.
Upgrade of 299 offices was planned to be done on 10th/1 1th July such that all offices were able to offer an LT2
service at start of business on Monday 12 July. Success criteria were identified (see Pathway Report dated 16/7/99
version 2). Release contents for LT2 were identified in Pathway Report CS/REP/043 version 1.0 dated 9/7/99).
Not all 299 offices were successfully upgraded to LT2 by 0900 hours Monday 12 July. by 1030 hours 288 had been
upgraded leaving 11 offices still operating LT1. The follwing incidents are demonstrations of the failure to meet the
criteria.
IA number of crrors caused by corruptions to .dll files:
- outlets unable to declare stamps, stock and cash (Pathway problem reference PC0027742)
+ receipts not equal to payment errors (FAD codes: 390329, 8523, 13523, 166328)
IApproximatley 35 outlets made calls to the HSH with the following problem
I- appearance of a No Entry sign on the desktop preventing continuation (Pathway problem reference PC0027743)
[An LT2 change was to the font size for the cash account. TP report that 8 offices (FAD 252329, 205329, 407329,
258523, 188504, 156523, 166328, 461329) produced cash accounts with the old font size.
Witness / Reviewer Horizon Acceptance Pathway AIM >
Test Manager .
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
=
* Ipreventing continuation (Pathway problem reference PC0027743).
_ I This problem is entirely unconnected with the software distribution process and is not a systems management issue. A fix
lecepiane
rizon'Aeceplance Incident Manag
Acceptance Incident Number (1) Analysis Sequence Number (2)
“372
‘Acceptance Test Name (3)
POCL Infrastructure
Analysed Incident-Sevérity: (4) wh High / Medium / Low (4) Authority (5)
ve ty ea? None :
‘Analysis of Acceptance Incident (6)
For cach of the individual points made in the Al, the Pathway analysis is provided following (in italic font)
1. A number of errors were caused by corruptions to .dll files: -
This was not an error of the software distribution process itself; but a problem during the transfer of the distributed files to
the Windows NT operational directory, and was apparent on 3 counters. The underlying cause of this remains under -
investigation; to date the characteristics have not been reproducible. From a systems management perspective the
consequences were correctly handled — the counters were successfully regressed and recommitted.
2. Approximately 35 outlets made calls to the HSH with the problem of appearance of a No Entry sign on the desktop
10 this has been implemented in WP 5138; this will be distributed to the live estate in the immediate future,
3. An LT2 change was to the font size for the cash account. TP report that 8 offices (FAD 252329, 205329, 407329,
258523, 188504, 156523, 166328, 461329) produced cash accounts with the old font size.
Pathway is not aware of any reported incidents relating to the font size used in cash account printing following the LT! to
ILT2 upgrade.
IThe upgrade was achieved in line with the general requirements of R537 in terms of both speed and accuracy, with the
vast majority of outlets updated within the Pathway target timescale of Monday moming, and all within the critical
timescale of the following Wednesday to support operation of the revised cash account procedures (with the exception of
lone part-time office which does not open on Wednesdays).
‘The LT! to LT2 upgrade report and supplementary information has been supplied to POCL covering the incidents
described and others. POCL observations on this report have been received and comments on thse observations are
provided in a separate response document.
Clearance Action (7)
Reh OL SPA RVPLANALE his incident based on the upgrade reports provided and that all outlets are now running on
LT2,
IComments on the observations supplied by POCL on 7/8 are in preparation at this time (9/8). Ongoing monitoring as
requested in the observations will be provided. POCL already has access to the Systems Management Montoring reports
published on the Pathway website, This provides details of sofiware distribution actions (fixes etc.) covering the start date
for distribution, 95% complete and 100% complete. Any issues arising from such monitoring should be raised by POCL at
the Service Review Forum,
Subject to POCL.
"Thursday 12/8,
sment of the comments supplied, Pathway anticipates that this A! will be Closed or recategorised by
-
POL00043691
POL00043691
Resolved
Signatures: 6:
I propose the Clearance Action
and Incident Status described
above
{1th August 1999
I accept / reject the Clearance
(Action and Incident Status
described above
) Date:
POL00043691
POL00043691
&] Acceptance Incident Number (1)
376
Source (3) Date Observed (4)
TIP Interface BSM 19/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6) .
Martin Box
Byer Rion Rot et incident’ Ex ;
High
Substantive fault Medium
Other. Low
None
Description of Incident (10)
New Description: AIS contraventior/ Data integrity - derived cash account not equal to'the electronic cash
laccount.Incidents (TIP 821, 822, 846, 855, 856, 857, 858, 859, 864, 965, 866, 868, 869, 870, 873, 874) have been
raised by TIP in respect of all transactions that constitute a cash account have not been recived by TIP or when *
electronic cash accounts received where transactions that have been conducted and received by TIP are missing
from the respective cash account lines. These issues have come to light when comparing a TIP derived cash accountI
with the electronic cash account sent by Pathway. Not all instances of similar occurrences have been logged by TIP
las the physical resource to check each occurrence of a difference within the derived versus the electronic is not
available, It was expected that this facility would by now be comparing like with like. This is very significant.
Missing transactions and missing cash account line entries cause reconciliation failures within POCL back end
systems and error resolution is invoked, The cash account produced by the Organisational Unit in these instances
must be in doubt and is not a fair reflection of the business undertaken at cach Organisational Unit. A
subpostmaster may be asked to bring to account an error, but the error was produced via system failure rather than
human failure. Many hours of investigation at both the front end and back end have taken place to help resolve
these problems. The benefits assigned to POCL back end system in réspect of an automated cash account are being
questioned.
Severity: POCL - high - would effect POCL's ability to produce an accurate cash account.
PWY - accept the problem exists. Would argue about the severity - would it genuinly effect the accounting,
integrity as it currently exists?
Rectification: Steve Warwick to provide rectification of this issue. PWY understand the problem and are currently
working on the fix. Steve Warwick to provide details.
Signat es(1) .
Wit ness 7 Rev ‘iewer Horizon Acceptance
- Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager _ POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
Acceptance:
D Pathway Accep
aE
Seotancédneldent
aes r
Acceptance Incident Number (1) Analysis Sequence Number (2)
376
Acceptance Test Name (3)
TIP Interface
fanny High / Medium / Low (4) Authority (5)
Low
Analysis of Acceptance Incident (6)
Pathway has analysed all occurrences where the (TIP) derived cash account docs not equal the actual cash account (up to
TIP 883). There is no suggestion or indication that there is a fault in the calculation or reporting of the Cash Account; the
incidents relate to an occasional missing transaction when reporting to TIP. This had a rate of occurrence of c. 1% of
outlets per week based on an analysis of the reported TIP incidents. It is agreed this would have been unsustainably high
when considered against a target population of 20,000 outlets.
‘The agent modification referred to in previous anlyses has been operational since 3/8 and is operating successfully.
An updated summary of TIP incidents was supplied 11/8 as actioned. As noted the root problem has been diagnosed in all
Inon “serve customer” transactions leaving onc further problem under diagnosis relating to occasional scales transactions,
which are all in serve customer mode and are corrected by the agent modification noted above.
In addition Pathway has established routine monitoring for all harvesting exceptions and should any occur will notify them
to TIP in advance and has agreed a suitable procedure with TIP, thereby substantially reducing the TIP effort in handling
any exceptions.
POCL has removed the aspect concerning the reference data change from core to non core from this Al and re-raised it as
AI 410 (TIP Incident 866). In this case there is no fault within the Pathway system. Pathway has proposed an approach to
POCL to avoid this problem through the use of product types within RD.
Clearance Action (7)
Rum fbelureenstitutazauspingyansaction attributes was introduced 3/8. Pathway confirms that at the time of completing
this analysis no further missing transactions have been noted to date by Pathway internal monitoring.
Subject to satisfactory processing by TIP of the cash account for weck 19 in line with the reduced incident rate proposed
by Pathway, and with the above procedures in place to notify any exceptions, Pathway assess the severity of the incident
las “low”.
Ongoing monitoring for the next three months should progressively reduce occurrence to a maximum of 0.1% at which
point the incident be closed.
I propose the Clearance Action
and Incident Status described I
above John Pope ¢[11th August 1999
Vaccept / reject the Clearance : poe Heese. I Date:
Action and Incident Status Tests Manageres BENE:
described above Ragiuery bans Z
Horizon-Acceptancé Irie fanager Date:
POL00043691
POL00043691
—
Tene
Tanager:
POL00043691
POL00043691
eae
th oye
‘Acceptance Incident Number (1)
z . 378
Acceptance Test Name ( ro Source (3) Date Observed (4)
TIP Interface BSM 19/07/99
Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
Martin Box
Substantive fault
Other
Description of Incident (10)
New Description: Incidents (TIP 806, 867) have been raised in respect of a cash account sub file containing only
stock holding records and not a cash account record as expected, This held up the processing of the cash account
within POCL's back end systems, This was correctly rejected by TIP.
Severity: POCL - medium - duc to time taken to investigate each problem and knock on impact on POCL back end
systems. .
PWY - accept the problem exists. Dispute medium rating.
Rectification: Steve Warwick to provide rectification of this issue. A fix exists - Steve to provide détails of dates
for download to outlets so TIP can monitor the rectification.
Signatures qi we ee
Witness /Reviewer Horizon Acceptance] Pathway [AIM
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Date:
POL00043691
POL00043691
iuhway Acceplance Manager. -.~
Eanes ae
éeptance Ineldent Manager
Acceptance Incident Number (1) Analysis Sequence Number (2)
. 378
Acceptance Test Name (3)
‘TIP Interface
Analysed Incident Severity (4) > High / Medium / Low (4) ‘Authority (5)
pose None/Low
“Analysis of Acceptance Incident (6)
Fix applied 9-10/8
Number’of continuation: pages: sic:
Clearance Action (7)
IPOCL to monitor for Cash Accounts prepraed 11-12/8 and close (or recategorise).
I propose the Clearance Action
land Incident Status described
above P. John Pope
Taccept/ reject the Clearance
Action and Incident Status
described above
Horizon Acceptange Incident Manager’ I
11th August 1999
Date:
I DSS‘Aceeptance Mariager. -
Date:
POL00043691
POL00043691
Cave
ye
Acceptance Incident Number (1)
‘ 390
Acceptance Test Name (2) Source (3) Date Observed (4)
IAPS Review 09/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Bob Cragg
Incident Type (7): Cri rign'Reference (8) (if criterion 'nét met) *. : aci S
Substantive fault Medium
Other Low
None
Description of Incident (10) ,
Recovery facilities are inadequate for the recovery of transactions. They fail criterion 32, 549/2This area of
functionality is weak and requires the operator to declare the reversal as a lost transaction and then at a later point
reverse the recovered transaction. This procedure is difficult to operate and does not provide full audit trail for
reversed transactions, When declaring the transactions that have been missed the range is referred to as the "gap". It
has come to light that the NR2 system only supports one gap. Duc to the business need to continue trading by
delaying the recovery , it is possible that additional failures will create further "gaps" . Since the system does not
support this there is a shortfall in process / procedures.
}- Signatiires (11):
Witness / Reviewer Horizon Acceptance Pathway AIM
‘Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
390
Acceptance Test Namie (3)
High / Medium / Low (4)
Low
Authority (5)
Analysis of Acceptance Incident (6)
POCL will be aware that ICL Pathway are changing the recovery processes of APS for CSR+. This includes providing
support for recovery of reversals. At CSR+ APS will automatically write recovery transactions for all AP transcations. In
the event of a Session failure these recovery transactions will be used to automatically recover their original AP
transaction.
In the event of a Disaster recovery at CSR +, the concept of gaps is removed. In this situation the message store is being
reinstated from a remote node and the recovery transactions are not available. APS simply-asks the clerk for details of any
receipts which he has which have a date/time more recent than the latest known APS transaction message. If the clerk
chooses not to recover all receipts in this category then the clerk must retain these receipts for later processing. The data
entry process will also use check digits on cach data item being entered from the receipt.
Numberof-continuation;papestes sera
Clearance Action (7)
None.
FOURS NOI a
INI f.conti
I propose the Clearance Action
and Incident Status described
above D.Cooke SES Soin
1 accept 1 reject the Clearance Hor iggrAces places ‘ Date:
[Action and Incident Status ‘estiManaperetyye crise
REE
Serer
BOGLBusinesstAssi
BURG Me eee
POL00043691
POL00043691
oo
Acceptance Incident Number (1)
391
Acceptance Test Name (2) Source (3) Date Observed (4)
Security BSM 22/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Jeremy Folkes
Incident Type I Criterion Reference’ (8) (if ig c
PS-22, PS-39, PS-40, PS-41, 698-03, 698-02, 698-01 High
Substantive fault Medium
Other Low
None
Description of Incident (10)
The physical security controls in force at the two main Pathway data centres at Bootle and Wigan are deficient in a
number of areas, when measured against best practice, relevant standards (BS7799, as required by 698.03 and PS41,
DITSS as required by PS22) and Pathway’s own Security Management Procedures (RS/PRO/028 1.0 10.5.99),
which form part of Pathway’s Security Policy (RS/POL/002 4.0 30.4.99), which is in tum the response to
Requirement 698.02.
The data centres are a critical clement of the Pathway service provided to POCL, and should be protected to an
adequate standard to control the risks and liabilities of both Pathway and POCL (as per 698.01 and PS39).
Recent inspections of the Data Centres show that the quoted criteria are not met. Detailed comments have been
passed to ICL Pathway on a number of occasions, including following the last site visit on the 22nd July. However,
these include:
Bootle
1. The Data Centre is located within 2m of a car park used by staff from a number of other organisations over which
ICL Pathway have no control, and to which visitors cars have largely unrestricted access. The DITSS recommends
a 25m vehicle exclusion zone. There are no physical restrictions on pedestrian access up to within 2m of the Data
Centre, with the outer site fence claimed purely to be a delimiter and not intended as a physical control. CCTV
coverage of the car park close to the Data Centre does not appear good, and POCL have been denied permission to
view the CCTV coverage. Pathway’s previous stated mitigations to the proximity of the car park, based on CCTV
tracking, control of visitors cars, etc do not appear to be effective.
2. The fence protecting the Data Centre itself is in such a poor state as to offer only a low level of protection against
Witness /Reviewer I Horii
Pathway
‘Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
"
-
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
391
Acceptance Test Name (3)
Security
High / Medium / Low (4) Authority (5)
Low
rity @)
Analysed'Incident S
Analysis of Acceptance Incident (6)
BOOTLE
The points raised at 1 & 2 are well understood by Pathway and were fully covered in the Bootle Data Centre Threat
Assessment document (RS/REP/007). A copy of Version 1 was provided to Horizon together with other documents on
23/2/99. (Document now at version 2.0 dated 11/5/99). These items have been discussed at length between Pathway and
Horizon in the past. It should be noted in addition that the levels of threat analysed in this document also related to the
Benefit Payment workload.
At the 22/7/99 visit, only one clement of the control procedures described in carlicr discussion and agreements was not
demonstrable. This being, access to the CCTV monitoring. Pathway was unable on the day to arrange access to the CCTV.
monitoring facility because the officers with appropriate authority were not available. (Action point 1).
(Continued on a further page)
“JONE
Nuinber of continuation’ pages
Clearance Action (7)
1, Pathway will arrange for a further visit to Bootle to be scheduled on or before 10th August 1999 for nominated Pathway
land Horizon staff (if required) to view the CCTV coverage. I ACTION B Procter by 30/7/99
12. A meeting is being arranged for week commencing 2nd August with Graham Hooper (A & L Corporate Sccurity) and
Colin Jones (A & L Property Services Manager). The actual date will: be confirmed by 30th July 1999 ACTIONB.
Procter
= II propose the “Clearance Action Date: 29/07/99
land Incident Status described
above
T accept / reject the Clearance
Action and Incident Status
described above
Dave Jones -
Date:
DSS Acceptance Manager
Date:
POL00043691
POL00043691
Coa
‘Analysis of Acceptance Incident #391 (6) (Continued from previous page)
Specific points raised in the Acceptance Incident together with the associated Threat Assessment and
Recommendations references
1. Car park Proximity & Pedestrian access - Covered in RS/REP/007 Section 3 No. 2,4 &7
Fence delimiter - Covered in RS/REP/007 Section 3 No. 2,4 &7
Previous mitigation statement - Covered in RS/REP/007 Section 3 No. 1
2 Fence around Data Centre
+ Following previous visits and Horizon recommendations, improvements were made to the fence;
E.G. Ducting made more secure, gate bolts protected by metal plates, “V" shaped barbed wire
installed on top of the fence.
- It is accepted that some problems remain with the upkeep. The issues quoted were raised with A &
L Group Property Services Manager (North) and further specific action requested to improve matters
on 27/7/99.
- An urgent meeting has also been requested with A&L Corporate Security Manager to confirm that
the necessary actions have been carried out or have been planned. (Action point 2)
Quick denial of service attack - Covered in RS/REP/007 Section 3 No. 1, 2,4 &7
5
WIGAN
The points raised are well understood by Pathway and have been discussed at length between Pathway and
Horizon in the past.
'The recommendations made on previous visits required the erection of a new palisade fence to protect the Data
Centre exterior wall and modifications to the security guard procedures. Both of these have been completed and
this has been acknowledged by Horizon. The details were confirmed in the Girobank letter dated 15/2/99, copied
to Ian Stevenson on 23/2/99. The palisade fence was erected in accordance with Pathway specification.
The only outstanding action on these works is to provide Horizon with a copy of an updated Wigan site plan
recording the location of the palisade fence. Pathway will provide a copy when it is available from A & L.
‘Specific points raised in the Acceptance Incident:
1 Pedestrian access - The site perimeter fence is intended to act only as a boundary marker.
Accordingly, and in response to agreed requirements, Pathway/A &L have clearly defined and
installed a robust security perimeter for the Data Centre building.
CCTV monitoring - There is intruder detection on the new palisade fence. During the day the
CCTV is centred on the palisade fence, at night the CCTV is centred on the perimeter fence but if the
palisade Sabrephonic guard wire is triggered the CCTV will revert back to the palisade fence area.
Standing instructions exist for the response to any alarm on the site.
Missing camera/CCTV upgrade - As stated above a CCTV camera covers the palisade fence and
the perimeter fence and is specific for the area under surveillance.
DOCUMENT REFERENCES
{The AI quotes Pathway’s Security Management Procedures. Pathway considers that the
security on the sites is commensurate with threats to the services.
The security within the inner fence area described in RS/REP/007 for Bootle, which is also covered in
the A & L letter of 15/12/98, is further evidence of appropriate provision. (c.g. Moat, motion detection,
ICCTY, active infrared beam, building construction — concrete floors, double glazed and shatterproof
film lined windows).
It should also be noted that should denial of access or availability of service arise for whatever
reason, the ultimate mitigation is the invocation of the site failover,
With regards to the provisions of BS7799 s5 and DITSS s13, these are adequately covered in the notes
above and were also dealt with in carlier correspondence (in particular the letter to Ian Stevenson from.
Barry Procter dated 8/2/99.)
POL00043691
POL00043691
Analysis of Acceptance Incident #391 (6) — Update following mectings on Sth & 6th August
[Actions and points of note discussed and agreed between POCL ( Bob Booth) and Pathway :
BOOTLE
1, Repairs to the fence, highlighted under Bootle item 2 in the initial Incident description, are to be
carried out by A & L by the end of August.
2. Pathway have asked OSD to specifically include a report on security aspects at the monthly Service
Review Forum rather than cover them on an exception basis. Any actions arising will be included in
the minutes for the meeting, which will be available for viewing if required.
3. Pathway will provide POCL with dates for Phases 2 & 3 of the perimeter fence upgrade. Phase one is
complete.
14. Bob Booth is to visit the site in carly September with Barry Procter.
INOTE. The CCTV facilities had recently been upgraded to give automatic camera movement to any area where a
sensor has been triggered.
(As previously indicated, directly as a result of the Threat Analysis and regular Pathway reviews,
factions were placed by Pathway on A & L to improve the security at the site. ‘
WIGAN
1. Pathway will discuss the installation of a card access protection on the pedestrian access
gate (adjacent to the canal), with Alliance & Leicester.
2. Pathway will establish that Security Guards respond to alarms to their pager within a ‘reasonable’
time period and, if they are unable to respond what back-up arrangements exist.
3. Pathway to provide more details on the planned new CCTV camera installation.
GENERAL
Pathway will discuss with A & L the inclusion of disaster recovery invocation [and resultant single site operation)
las one of the events which triggers the state of alert change to RED. In such an event, the vehicle exclusion zone
jin Bootle would need to extend to 25 metres, or additional site security staff
would be needed in Wigan.
POL00043691
POL00043691
- ST’
Acceptance Incident Number (1)
; 394
Source (3) Date Observed (4)
APS BSM 23/06/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
ident, Sevérity:(9);
_ Criterion not met High
Gbstantive fault >. Medium
Other Low
None
Description of Incident (10)
A number of instances hasve been recorded by TP where re-prints of the Cash Account report show differences
from the original report which cannot be explained by additional transactions.
Witness / Reviewer Horizon Acceptance Pathway AIM
-) Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
Soy?
& “>
Acceptance Incident Number (1) Analysis Sequence Number (2)
394
‘Acceptance Test Name (3)
APS
Analysed Incident!Severi High / Medium / Low (4) Authority (5)
eee ¥ None
Analysis of Acceptance Incident (6)
These incidents are all duplicates of E-9905250160 (PINICL 26066 - now closed). The original problem was caused by
postmasters failing to complete one c/a report before starting the next; completing the report (via the complete button)
required to reset variables prior to priniting the next report.. To avoid problems of this type a modification to the Report
Broker (\WP_4931) was introduced at LT2 to support the printing of consecutive reports without the need to select
“complete” and re-enter the report screen. There have been no notified re-occurrences of problems of this type.
Niimber of continuation pages.
Clearance Action (7)
Cleared as described above.
POCL to close if no occurrences have been reported.
Tosi
ation'pages «. “Si
“Resolved
I propose the Clearance Action
land Incident Status described
above
I accept / reject the Clearance
Action and Incident Status
described above
Horizon‘Acceptanceiiei
DSS Acc
Date:
POL00043691
POL00043691
‘Acceptance Incident Number (1)
Calum Craig
Reserves 395
Acceptance Test Name (2) Source (3) Date Observed (4)
APS BSM 23/06/99
Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
(GriterlomReterence (8)
Criterion not met
Other
High
None
Description of Incident (10)
and 27012 refer.
continue to be reported by both TP and TIP.
‘TP have detected a number of incidents over the Live Trial period where duplicate AP transaction reference I
numbers have been issued and where unmatched AP transaction reversals have appeared. PinICLs 26752, 26835
It was anticipated that this problem would be cleared with the introduction of the LT2 software, however instances
Witness / Reviewer
Entered in Acceptance Database
Horizon Acceptance Pathway AIM
‘Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Date:
POL00043691
POL00043691
—
ee
Tobe completed by the ICl Pathway Accepiance Mei
given to,the Horlzon Acceptance Incident Manag
Acceptance Incident Analysis!Form: .
Acceptance Incident Number (1) Analysis Sequence Number (2)
395
Acceptance Test Name (3)
APS
Analysed Incident Severity (4): High / Medium / Low (4) Authority (5)
hart i Medium
Analysis of Acceptance Incident (6)
This analysis is copied from Al 361, which discusses the PinICLs cited:
This incident concems duplicates, There are a number of causes which have been rectified.
Incident 9905110226 was software error, now fixed. 9905210206 was duplicate events when issuing order books, now
fixed. 9905280170 was software error now fixed. 9906220033 (APS sequence nos.) was a software error now fixed.
9906280140 was software error now fixed. 9906280141 & 9906290187 were errors associated with a one off situation of
switching Bootle/Wigan (ini this case also in conjunction with a problem within TIP conceming the treatment of previously
received files),
The underlying root cause PINICLs have all been closed with fixes applied 25086 (OBCS - LT1), 25348 (duplicate cash
a/c lines - LT2), 27012/26835/26752 (all duplicates relating to Duplicate APS sequence nos - LT2). The sole exception
jis 26928 (which relates to the occurrence and treatment of potentially repeating / duplicate events) which required
resolution with TIP over how they wished repeated events to be treated. TIP have indicated they want these screened out
(this confirmation was required since repeated events can legitimately occur) and a fix to introduce this screening has ben
produced, tested and the release note is currently in preparation.
There is a software fix to filter out duplicates. Fix waiting to be applied.
Note that sometimes duplicate "events" are caused by users holding down the key too long.
Duplicate records for EPOSS_Events and Book_Events will not be written
to the TIP output files.
Number: of continuation pages>.
Clearance Action (7)
POCL to close after further monitoring, or supply specific references to further incidents.
Number ‘of contindation pag
Signatures:
I propose the Clearance Action
and Incident Status described
above P. John Pope 4th August 1999
T accept / reject the Clearance Date:
Action and Incident Status
described above
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
395
Acceptance Test Name (3)
High / Medium / Low (4) Authority (5)
None/Low
“Analysis of Acceptance Incident (6) :
IAll instances of APS duplicate records and unmatched reversals have arisen from the same APS recovery situations.
(Incidents up to and including TIP 876 & 881) There was a fault in the LT! software which resulted in the allocation of a
duplicate sequence number in certain circumstances even if the clerk had followed correct recovery procedures, This was
fixed was fixed at LT2.
Since LT2 there have been a small number of occurrences of a related incident which has arisen through failure at the
outlet to follow correct procedures during recovery. In these situations APS has been forced into crash recovery
(apparently by clerks not logging out and/or powering off PCs) and during the recovery:the incorrect APS sequence
number has been entered. (See below.)
On the basis that the root error has been eliminated and the incident rate consequentially reduced Pathway rate this incident}
las low severity. -
In addition we are adding a validation check to APS recovery to prevent a clerk entering as the last transaction a number
ower than the last transaction known to the system. This will further reduce the occurrence of duplicate transaction
numbers. This fix will be released soon, probably during August.
Number‘ of-contintiation:
Clearance Action (7)
IPOCL to close or recategorise after further monitoring, noting that AI 390 provides an enhancement path.
Resolved
land Incident Status described
above
‘ T accept / reject the Clearance
[Action and Incident Status
described above
Horiz
/DSS Acceptance Manager
POL00043691
POL00043691
cy F
© KP
P. cic Acceptance Incident Number (1) -
Bevaewec se "408
‘Acceptance Test Name (2) ‘Source (3) Date Observed (4)
Service Levels BSM 23/0799
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
David McLaughlin
Tnedent Tne)
Criterion not met High
Other Low
None
Description of Incident (10) 5
Failure of the Horizon System helpdesk to support the network. there were six service level failures in the last
reporting period and are listed below.
Calls answered within 40s
Calls abondoned through ring off
Level I calls resolved within 5 mins
Level I calls resolved within 10 mins
Level 2 calls resolved within 30 mins
Level 2 calls resolved within 45 mins
All of these failures will have an impact on the network and customers.
en AE ee
Witness / Reviewer Horizon Acceptance Pathway
- Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
408
‘Acceptance Test Name (3)
Service Levels
Tigh / Medium / Low (4) ‘Authority 6)
d-IncidentSeverity
: the None/Low
‘Analysis of Acceptance Incident (6)
The roll out of LT] and impact of the Wednesday CA activity has affected the SLA's identified. The influx of “expert
domain" staff on to the HSH initially meant that average call duration rose substantially as all callers were trapped on the
front line.This initially impacted all the named SLA targets. The expert domain was relocated to second line and we have
introduced call scripts into HSH.
The HSH has also introduced new staff in preparation for roll out. We identified that the new staff were not operating the
call management procedures properly (ie call suspend) and call times were not being managed. New staff have been
retrained the issuc has now been removed.
Call coding has been analysed an we have identified many calls classified as L1 (5 & 10. minutes) that arc clearly L2 (30 -
45 min target). After manually reviewing and recoding these calls to L2 the SLA performance track has improved
considerably. . Changes to the coding structure on HSH are being progressed.
Nuinber.of continuation ‘pages **.
Clearance Action (7)
The SLA targets are subject to the monthly Horizon Service Performance review process and POCL will be presented with
the re-worked figures as described above,
Given this situation I have given this incident a LOW severity.
Letter confirming actions to date, SLA perfomance track and planned activites was sent to David McLaughlin 11/08/99 as
actioned. I have confirmed David has recieved the letter, awaiting confrimation its is acceptable. Paul 11/08/99
POCL to Close or recategorise as Low.
Analysed
I propose the Clearance Action
and Incident Status described
above
1 accept / reject the Clearance
Action and Incident Status
described above
Hi éceptance'Incident Ma
: pra
11/08/99}
DSS.Ace¢piance Manager."
POL00043691
POL00043691
—
op
‘Acceptance Incident Number (1)
410
‘Acceptance Test Name (2) Source (3) Date Observed (4)
TIP Interface 15-Jul-99
Witness/Reviewer who observed Incident (Owner) (5) _ Authority (6)
Mark Burley
Substantive fault Medium
Other Low
Pending
None
electronic cash account at the
TIP reference 866
HSH reference E9907150220
Description of Incident (10)
week end.
TIP have detected an instance where transactions received in the daily transaction file are not represented on the
The transactions missing from the cash account are associated with a product changing from core to non-core.
aes PRR
Witness / Review er Horizon Acceptance Pathway AIM
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
red in Acceptance Database Date:
POL00043691
POL00043691
Acceptance Incident Number (1) Analysis Sequence Number (2)
410
Acceptance Test Name (3)
TIP Interface
Thigh / Medium / Low (4) ‘Authority (5)
None/Low
Analysis of Acceptance Incident (6)
This incident was caused by POCL effectively ceasing a product at an outlet by changing it from core to noncore. The
effect of this was to end date the current reference data for the product at all outlets, but to provide replacement reference
data only to the sub-set of offices which were to handle the noncore product. At the end of the week any office which had.
{transacted the product while it was core and was not designated to transact the product locally would fail to include such
{transactions on its cash account.
It is well understood (and provided for in agreed procedures) that products must not be ceased - i.e. the item reference data
must not be end-dated. — Because of this the OBC procedures provide for the change of a product from noncore to core,
but do NOT provide for the change of a product from core to noncore.
IAt the Chesterfield Review of TIP Incidents on 29/7 POCL and Pathway agreed that this eventuality was not a Pathway
fault and was classed as a "Category 2" operational incident. It is still Pathways view that this is no-fault, but we have
taken the actions set out below to make explicit the prohibition on changing core items to non-core already implied by the
prohibition on deleting items, and will as we already do for core item deletions, police attemted reference data changes to
ensure that future errors by POCL are prevented.
Number: of continuation pagesa..
Clearance Action (7)
We have suggested to POCL a method of working which would enable them to achieve the same business objective
without doing an illegal reference data change: remove the core product using the agreed procedures (in which the product
ref data is not end dated), and introduce a new noncore product at the required outlets.
A new version (version 2.1) of the Reference Data Change Catalogue has been produced. The changes between versions
2.0 and 2.1 have been agreed with POCL (Andy Corbett, BSM OSG and Ijaz Bhatti, Automation Process Manager). .
The changes are:
IA statement that the change “core product becomes non core” is not available at CSR [section 6.5.5].
The amendment of “changing non-core product availability” to show that removal of outlets is not available at CSR
[section 6.5.2].
These changes are to remove the issue that arises when an outlet can no longer sell a product (which cither used to be core,
lor was non-core and the availability has reduced) but has transacted it before the cash account has been produced, or still
= _ Iholds stock for the product (where applicable).
OSG BSM will reject any requests from the Business which are identified as removing the availability of a product from
outlets, in line with the RDCC, before it reaches ICL Pathway.
ICL Pathway will impact changes from POCL against the RDCC, and any new requests to end the availability of a product
at outlets (unless part of a permanent outlet closure) w ill be rejectd, as is already done for attempts to delete core items.
Pathway expects that this AJ will recategorised by POCL as Closed.
Hf POCL cannot agree to close this incident by 12/8 then Pathway asks that it should be recategorised as Low on the
grounds that POCL has confirmed that this class of change is now explicitly excluded from agreed Business Change
proced
POL00043691
POL00043691
“ic!
yor,
d .
grounds that POCL has confirmed that
procedures,
If POCL cannot agree to close this incident by 12/8 then Pathway asks that it should be recategorised as Low on the
this class of change is now explicitly excluded from agreed Busincss Change
land Incident Status described
above : P.
John Pope
Date:11th August 1999
Taccept/ reject the Clearance
Action and Incident Status
described above
M:
2a
eee Se GS
RoR
PAZ
Date:
POL00043691
POL00043691
ae
If POCL cannot agree to close this incident by 12/8 then Pathway asks that it should be recategorised as Low on the’
grounds that POCL has confirmed that this class of change is now explicitly excluded from agreed Business Change
procedures.
BOGEN =
ae
Date:11th August 1999
and Incident Status described
labove IP. John Pope
I accept / reject the Clearance
Action and Incident Status
described above
Date:
Date:
Date:
fone
Even TAS