POLO00325269
POL00325269
GP. Baler
RDB. Cooper
MID. Robert
HIM. Nowlan
15. Haw
M,Pescod
PT. Jeonings
RS
Pa
TA
o}
K Baines Esq
Post Office Counters Limited
20-23 Greville Street
London EC1N 8SS
AEF. Ru
Moc
6
SLAUGHTER AND MAY
* LDE and CDE Box No.I 1
wshwrorts ALR. Newhouse Furey 1D. Rice
PM. Olney MA, Whelton
stacey MO. Bennett
Underhill RD. de Cale
SP. Hal
WJ, Sibree
RC: Stern
Nicholson
1 Trees
EG.L. Wylde
A Beare
1D. Boyce
MEM, Hatred
1 Hodgson
S. Grandson
CR, Smith
Decument
Your reference
lin reply please quote
POL00325269
POL00325269
ers and ALA. Maggiar are Avocats& ta Cour B'Appel de Paris
N.von Bismarck AG. Ryde
LM, Carstensen JAD. Markt ;
NJ. Swycher SD, Warma:bul:suriva
PLWH. Brien DA, Wittmann
IM. Fenn TS, Boxe
ANN. Hyman Sy. Luder
AC. Johnson Al. MeClean
EF, Keeble wentyinan
KR. Dawe GN-Eaborn
SR Galbraith CG, Eales
NDF. Gray HE, Grit
MS, Hutchinson STM. Lee
SRB. Powel
number CA992700193
JRT/FMO
Writers direct line
28th September, 1999
Dear Mr Baines
LONDON
Documents relating to the Second Supplemental Agreement
At Jeff Triggs’ request, I enclose:-
The following original documents:-
(a)
(b)
(c)
(d)
(e)
Second Supplemental Agreement dated 24th September, 1999;
Side Agreement dated 24th September, 1999;
Rectification Timetable as referred to in the Second Supplemental
Agreement;
Annex to Second Supplemental Agreement dated 24th September, 1999;
Emergency Change Control Note 562 to the Codified Agreement dated
24th September, 1999.
I will forward the originals of the Fujitsu letter and Japanese legal opinion when
we
receive these from Masons.
Two copies of the “Bible of Documents relating to the Second Supplemental
Agreement to the Codified Agreement”.
Panis BRUSSELS SINGAPORE HONG KONG
/Contd.
NEW YORK
POL00325269
POL00325269
SLAUGHTER AND MAY
K Baines Esq 2 28th September, 1999
Please do not hesitate to contact me if there are any problems.
Yours sincerely
THIS SECOND SUPPLEMENTAL AGREEMENT, being Change Control Note
(CCN) No, 560 is made the 24th day of September, 1999
BETWEEN:
qa)
(2)
POST OFFICE COUNTERS LTD., whose registered office is at Gavrelle House,
2-14 Bunhill Row, London EC1Y 8HQ; and
ICL PATHWAY LIMITED, whose registered office is at 26 Finsbury Square,
London EC2A 1DS (the “Contractor”).
WHEREAS:
(A)
(B)
(c)
(D)
(E)
This Second Supplemental Agreement is supplemental to the Codified
Agreement between the parties dated 28th July, 1999 (the “Codified
Agreement”) and constitutes CCN No. 560 of that Codified Agreement.
The Contractor and POCL have been carrying out the Operational Trial and the
other Acceptance Procedures in accordance with the Codified Agreement.
By a Supplemental Agreement dated 20th August, 1999 (the “First
Supplemental Agreement”) the parties agreed that CSR Acceptance had not
been achieved at the end of the CSR Operational Trial Review Period.
By the First Supplemental Agreement the parties agreed, inter alia, a *
programme of work with a view to achieving Acceptance and Release —
Authorisation by 24th September, 1999, and also agreed that only certain
elements of the Core System Release were required to be re-submitted for
testing in the Second CSR Acceptance Test and that only certain faults could be
raised as Acceptance Incidents in relation to the Second CSR Acceptance Test.
As at the date of this Second Supplemental Agreement the following
Acceptance Incidents (in addition to those categorised as category (c) faults)
remain outstanding:-
(i) Category (b) Faults which are Substantive New Faults reported to the
Contractor after 3rd September, 1999 in respect of which no timetable
for resolution has been agreed
Those Acceptance Incidents described in Part A of Schedule 1; and
Gi) Faults not falling within recital (E)(i) above
Those Acceptance Incidents described in Part B of Schedule 1.
POL00325269
POL00325269
POL00325269
POL00325269
It is Agreed as follows
1.
11
1.2
1.3
1.4
Interpretation
Words and expressions defined in the Codified Agreement or the First
Supplemental Agreement shall bear the same meanings when used in this
Agreement.
In this Agreement the expression “POCL” shall bear the meaning ascribed
thereto in the Codified Agreement.
Unless the context otherwise requires references in this Agreement to clauses,
Recitals and Schedules are to clauses of, and Recitals and Schedules to, this
Agreement.
In this Agreement, unless the context otherwise requires:-
“Accounting Integrity Control Release” means the software release to
implement the functionality described in the TIP Control CCD .
“Accounting Integrity Control Release Date” means the date on which the
Accounting Integrity Control Release shall have been:-
(i) developed in accordance with the TIP Control CCD;
Gi) demonstrated by appropriate testing to have met the specification set
out in the TIP Control CCD; :
(iii) observed in operation,] during a live observation period comprising two
cash account weeks, in all Outlets to which Rollout shall have taken
place as at the beginning of such observation period; and
(iv) fully deployed in all Outlets to which Rollout shall have taken place at
such date.
“Cash Account Discrepancies” has the meaning ascribed thereto in Clause 7.1.
“Liabilities” means losses, costs, claims, charges, demands, expenses and
liabilities.
“Rectification Plan” has the meaning ascribed to it in Clause 3.1.
“Rectification Timetable” means the document so described and initialled by
the parties or their legal advisers for the purposes of identification.
“TIP Control CCD” means the CCD entitled “Logical Design for EPOSS/TIP
Reconciliation Controls”.
2.1
2.2
3.1
3.2
3.3
3.4
POL00325269
POL00325269
“TIP Integrity Checking Period” means the period from the date of this
Agreement until the expiry of a period of four consecutive weeks after the
Accounting Integrity Control Release Date in which the TIP Integrity Checking
Process shall have identified no Cash Account Discrepancies not also identified
by the Accounting Integrity Control Release.
“TIP Integrity Checking Process” means the process to be performed by POCL
pursuant to clause 7.1.
“TIP Interface” means the systems interface described in paragraph 3.4.1 of
Schedule GO1 to the Codified Agreement and defined in the CCD entitled
“Pathway to TIP Application Interface Specification”.
CSR Acceptance
The parties agree that CSR Acceptance shall be deemed to have been achieved
as at the date of this Agreement.
POCL acknowledges that the Release Authorisation Board has, in reliance on
the terms of this Agreement, authorised national rollout of the Core System
with effect from execution of this Agreement by both parties hereto.
Remedy of Outstanding Faults
The Contractor undertakes to use its reasonable endeavours to resolve each of
the outstanding Acceptance Incidents referred to in Part B of Schedule‘l in
accordance with the rectification plans listed Schedule 2 (“Rectification Plans”)
and the Rectification Timetable. POCL shall use its reasonable endeavours to
comply with the obligations imposed on it in the Rectification Plans. In the
event of any conflict between Schedule 2 and the Rectification Timetable the
provisions of Schedule 2 shall prevail.
For the avoidance of doubt, notwithstanding that the express provisions of
Schedule 2 may purport to impose absolute obligations on the parties, the
parties’ obligations in respect thereof shall be limited to using their respective
reasonable endeavours to perform them.
If any of the outstanding Acceptance Incidents referred to in Part B of Schedule
1 shall not have been remedied by the use of such reasonable endeavours by
the due date contained within the Rectification Timetable the Contractor shall
continue to use reasonable endeavours to resolve such Incident at its own
expense as soon as practicable thereafter and, where applicable, POCL shall
continue to use its reasonable endeavours to co-operate in such resolution in a
manner consistent with the co-operation required of it under the Rectification
Plans.
The provisions of clause 3.4 of the First Supplemental Agreement shall apply in
relation to Acceptance Incidents referred to in Part A of Schedule 1.
3.5
3.6
4.1
4.2
POL00325269
POL00325269
All work carried out by the Contractor, its agents and its sub-contractors in
remedying any of the Acceptance Incidents referred to in Part A of Schedule 1
shall be at the sole risk and expense of the Contractor.
The Contractor shall co-operate and join with POCL in providing such
information and explanation to the Post Office’s auditors as such auditors may
reasonably require in order to satisfy themselves that the audit reports of the
Post Office and POCL should not be qualified or contain a fundamental
uncertainty paragraph as a result of the circumstances giving rise to Acceptance
Incident 376.
First Supplemental Agreement
Clauses 5, 6 and 7 of the First Supplemental Agreement shall be superseded by
this Agreement and shall cease to apply with effect from the date hereof. The
remaining provisions thereof shall continue in effect insofar as they remain
applicable.
For the avoidance of doubt, clause 4.6 of the First Supplemental Agreement
shall continue to apply.
Variation of Roll Out Programme
The Roll Out Programme in Annex 1 to Schedule A12 to the Codified
Agreement shall be replaced in its entirety by the Roll Out Programme set out in
Schedule 3 to this Agreement. .
6.
6.1
6.1.1
6.1.2
6.1.3
6.2
Suspension of Rollout
If:-
any of the criteria in parts A to C of Schedule 4 shall not have been met by 24
November, 1999; or
the Accounting Integrity Control Release Date shall not have occurred by
14 January, 2000; or
any of the criteria set out in part D of Schedule 4 shall not have been met by 14
January, 2000
POCL shall be entitled by notice to the Contractor to postpone the resumption
of Rollout from 24 January, 2000 until such later date as shall be agreed
pursuant to clause 6.2 below.
If POCL gives notice pursuant to clause 6.1 above the parties shall meet as soon
as reasonably practicable thereafter with a view to agreeing and documenting:-
6.2.1
6.2.2
7.1
7.2
7.3
7.4
75
8.1
POL00325269
POL00325269
a plan and timetable for re-testing and demonstrating the satisfaction of each of
the criteria set out in Parts A to D (inclusive) of Schedule 4 not then satisfied;
and
a revised Roll Out Programme to take effect once the satisfaction of all such
criteria shall have been demonstrated and the Accounting Integrity Control
Release Date shall have occurred.
TIP Integrity Checking Process
POCL agrees that during the TIP Integrity Checking Period it shall, on a weekly
basis, carry out a process of creating a cash account from individual transaction
data received by it across the TIP Interface, comparing such cash account with
the electronic cash account received by it from the Contractor across the TIP
Interface, reporting to the Contractor any discrepancies between such accounts
(“Cash Account Discrepancies”) and providing to the Contractor such
co-operation as shall be necessary in order to enable the Contractor to
investigate such Cash Account Discrepancies.
In consideration for POCL performing the TIP Integrity Checking Process the
Contractor shall pay to POCL a charge calculated as follows:-
@ a fixed charge of £228,000; plus
(ii) a charge of £229 for each discrepancy reported to the Contractor.
The charge referred to in Clause 7.2(i) shall be due on the date of this :
Agreement and shall be paid, together with VAT thereon, within 23 days of
receipt by the Contractor of an invoice therefor.
The charge referred to in clause 7.2(ii) shall be invoiced and paid, together
with VAT thereon, on a monthly basis, each invoice to be paid within 30 days of
receipt thereof by the Contractor.
POCL shall be entitled to set off any amount owing to it under this clause 7
against any charges payable by it to the Contractor under the Codified
Agreement.
Indemnity
The Contractor shall indemnify and keep indemnified POCL on demand (on an
after tax basis) against all Liabilities (other than any costs and expenses
incurred in applying the TIP Integrity Checking Process) which POCL may
suffer or incur as a result of any matter or circumstance arising prior to the
Accounting Integrity Control Release Date which it would not have suffered or
incurred had the Accounting Integrity Control Release Date occurred on the
date hereof.
POL00325269
POL00325269
8.2 The Contractor shall not be liable under clause 8.1 above in respect of any
Liability suffered or incurred by POCL to the extent that such Liability would
not have been suffered or incurred but for a failure by POCL to apply the TIP
Integrity Checking Process in accordance with POCL’s procedures therefor.
8.3 In the event of any matter or circumstance arising in respect of which the
Contractor may be liable under clause 8.1 above, POCL shall promptly notify
the Contractor of such matter and shall permit the Contractor, at the
Contractor's expense, for a period of four weeks from notification of such
matter to investigate and seek to resolve the matter and/or mitigate the
Liability in question. POCL shall provide to the Contractor, at the Contractor’s
expense, such co-operation as the Contractor shall reasonably request to enable
the Contractor to take such action.
8.4 The provisions of clause 810 of the Codified Agreement shall apply to any
liability of the Contractor under this Agreement. For the avoidance of doubt
any liability incurred by the Contractor under this Agreement shall be included
within the aggregate liability of the Contractor under the Codified Agreement
for the purposes of Clause 810.2.3 of the Codified Agreement.
9. First Roll Out Payment
If by 13 November, 1999 Roll Out shall have occurred to a number of Outlets being
less than 1,800 but not less than 1,600 then the First Progress Payment of £90 million
under paragraph 1 of Schedule A12 to the Codified Agreement shall be reduced to
£80 million (before any deduction pursuant to paragraph 7.2 of the said .
Schedule A12) and shall become due on the later of 1st November, 1999 and the date
upon which Roll Out shall have occurred in 1,600 Outlets. If so, the second Progress
Payment shall be payable as currently scheduled in paragraph 1 of Schedule A12 but
shall be increased to £100 million (before any deduction pursuant to paragraph 7.2 of
Schedule Al2). The figures of £80 million and £100 million referred to in this clause
equate to gross figures of £106.67 million and £133.33 million before retention of 25
per cent. from each figure in accordance with the said paragraph 1 of Schedule A12.
10. Further Delays
For the purposes of Clause 606.2.1 of the Codified Agreement any delay in Rollout of
the Core System caused by the default of POCL shall be disregarded to the extent that
the aggregate duration of all such delays does not exceed 42 days.
11. Further Obligations
The Codified Agreement (including as appropriate its schedules) shall be amended so
as to impose upon the Contractor those additional ongoing obligations described in
Schedule 5 and such other obligations (if any) required by the Rectification Plans and
any documents referred to therein which the Parties agree should be treated as
ongoing obligations (such agreement not to be unreasonably withheld).
12.
12.1
12.2
12.3
12.4
12.5
POL00325269
POL00325269
Miscellaneous
The provisions of clause 603 of the Codified Agreement shall apply, mutatis
mutandis, to any notice to be given by POCL under this Agreement.
No delay or omission by POCL in exercising any right, power or remedy under
this Agreement shall:-
qi) affect that right, power or remedy; or
(ii) operate as a waiver of it.
The single or partial exercise of any right, power or remedy under this
Agreement shall not preclude any other or further exercise of it or the exercise
of any other right, power or remedy.
The rights, powers and remedies provided in this Agreement are cumulative
and not exclusive of any rights, powers and remedies provided by law.
Any payment to be made by the Contractor under clause 8.1 of this Agreement
shall be made without deduction or set off on any account whatsoever.
The provisions of this Agreement shall be deemed to be incorporated as
appropriate as amendments to the Codified Agreement.
Except to the extent expressly amended by this Agreement the provisions of the
Codified Agreement and its schedules shall continue unamended and in full
force and effect.
IN WITNESS WHEREOF this Second Supplemental Agreement has been
executed on behalf of the parties as follows:-
POL00325269
POL00325269
SCHEDULE 1
Outstanding Category (a) and (b) Faults
PartA
Substantive New Faults Reported after 3rd September, 1999
[None]
POL00325269
POL00325269
Part B
Acceptance Incidents with Rectification Plans
Acceptance Incidents 211, 218, 298, 314, 342, 369,
372, 376, 378, 390, 391, 408 and 412
each as described in the corresponding Acceptance Incident Forms contained in the
Annex to this Agreement
1a
1.2
1.3
1.4
2.1
2.2
2.3
3.1
POL00325269
POL00325269
SCHEDULE 2
Rectification Plans
For Remedy of Outstanding Acceptance Incidents
Documents referred to in the text of this Schedule and the timetable are annexed to
this Agreement. That Annex has been initialled for the purposes of identification.
AIN 211
The Contractor shall apply each of the fixes detailed in the Acceptance Incident
Analysis Form for AIN 211 (“Form 211”) by the date specified-for such fix in
Form 211.
Where no date is specified in Form 211 for the application of a fix, the
Contractor confirms that that fix has been successfully applied for all Outlets to
which Rollout has occurred as of the date of this Agreement.
The Contractor shall monitor the effectiveness of the action taken by it to
resolve the incident.
When the monitoring referred to in paragraph 1.3 demonstrates over a period
of four consecutive weeks that resolution of AIN 211 has been achieved, then
POCL will close AIN 211.
AIN 218
Each of the Contractor and POCL shall complete the steps and achieve the
objectives applicable to it (the “218 Obligations”) detailed in section 3 and the
Contractor shall meet the critical success factors (the “Criteria”) detailed in the
table headed “Critical Success Factors” in Document CR/ACD/218 (Version 0.5)
(dated 23rd September, 1999).
Each of the Contractor and POCL shall fulfil each of the 218 Obligations
applicable to it and the Contractor shall ensure that all the Criteria are met by
31st December, 1999.
When the 218 Obligations and all the Criteria shall have been satisfied, then
POCL will close AIN 218.
AIN 298
Each of the Contractor and POCL shall complete the steps and achieve the
objectives applicable to it (the “298 Obligations”) detailed in section 5 of
Document CR/ACD/298 (Version 0.8) (dated 23rd September, 1999)
(“CR/ACD/298”) and where that section identifies one party as fulfilling an
action, the other party shall assist the aforementioned party to reach a
successful conclusion.
3.2
3.3
3.4
3.5
3.6
3.7
4.1
4.2
4.3
4.4
POL00325269
POL00325269
11
Each of the Contractor and POCL shall complete each of the 298 Obligations
applicable to it by the dates and to the standards set out in section 5 of
CR/ACD/298.
Without prejudice to the generality of the above paragraphs 3.1 and 3.2, the
criteria to be met in respect of AIN 298 by 24 November, 1999 are as set out
in Part A of Schedule 4 of this Agreement.
The Contractor shall, until closure of AIN 298, record and report to POCL such
data as shall be necessary to enable POCL to calculate the number of Units
being recorded as defined in paragraph 3 of Part A of Schedule 4 to this
Agreement.
For the avoidance of doubt, it is agreed that the Contractor shall be permitted
to continue the good business practice of carrying out planned reboots outside
working hours, such planned reboots not to exceed an average of one per
Counter Position per month.
Without prejudice to the generality of the above paragraphs 3.1 and 3.2, as
described in paragraph 5.5.2 of CR/ACD/298, the Contractor shall produce and
deliver to POCL by 30" October, 1999 the document referred to in that
paragraph for review and agreement by 24 November, 1999 and the
Contractor shall implement the provisions of that revised document by 24%
November, 1999.
When the criteria in paragraph 3.3 and the obligations in paragraph 3.6 shall
have been satisfied, POCL will close AIN 298.
AIN 314
The Contractor shall produce and deliver to POCL a document entitled “ICL
Pathway Generalised API for OPS/TMS” (the “API Document”).
The Contractor shall produce the API Document in accordance with sections 2
(“Scope”), 3 (“Document Standards”) and 4 (“Content of ICL Pathway
Generalised API for OPS/TMS”) of Document CR/SPE/007 (Version 0.3) (dated
7th September, 1999) (“CR/SPE/007”).
The Contractor and POCL shall review the version of the API Document referred
to in sub-paragraph 4.4(A) as described in section 3 of CR/SPE/007.
The Contractor shall produce and deliver the API Document to POCL:
(A) as a version for review without the “Appendix” (as defined in paragraph
5(A) of CR/SPE/007) before 1st December, 1999;
4.5
5.1
5.2
5.3
6.1
6.2
6.3
6.4
POL00325269
POL00325269
12
(B) as a revised version without the Appendix incorporating the changes
arising from the review referred to in the above sub-paragraph 4.4(A)
and paragraph 4.3 as a CCN before 28th December, 1999; and
(c) with the Appendix before 1st February, 2000 as a CCN.
POCL will close AIN 314 on approval of the CCN referred to in sub-paragraph
4.4(C).
AIN 342
Until 1st October, 1999 the Contractor shall monitor the operation of the
procedures detailed in the Acceptance Incident Analysis Form for AIN 342
(“Form 342”) under the heading “New Procedures”.
The Contractor shall ensure that the daily automatic and email reports
described in Form 342 under the headings “Program Changes Required” and
“New Procedures” (under sub-heading “b. Central Processing Delays”,
paragraph 2) are produced.
When the monitoring detailed in paragraph 5.1, or such other monitoring as
the parties may agree, demonstrates that AIN 342 has been resolved and the
requirements of paragraph 5.2 are being fulfilled, POCL will close AIN 342.
AIN 369
Each of the Contractor and POCL shall complete the steps and achieve the
objectives applicable to it (the “369 Obligations”) detailed in the table (in two
parts) extracted from Document BA/ACC/020 (version 0.4) (dated 20th
September) (“BA/ACC/020”) and where that table identifies one party as
fulfilling an action, the other party shall assist the aforementioned party to
reach a successful conclusion.
Each of the Contractor and POCL shall complete each of the 369 Obligations
applicable to it by 31st December, 1999.
When the 369 Obligations shall have been satisfied by the Contractor and
POCL, POCL will close AIN 369.
On the completion of the Contractor’s 369 Obligations where the Contractor
has taken the lead on actions to be fulfilled (as referred to in BA/ACC/020),
POCL shall confirm to the Contractor in writing that such obligations have been
completed. However, this confirmation shall not affect any other of the
Contractor’s obligations to ensure that AIN 369 is ultimately resolved, in
accordance with BA/ACC/020.
71
7.2
7.3
7.4
75
8.1
8.2
POL00325269
POL00325269
13
AIN 372
The Contractor shall complete the steps detailed in Document CR/ACD/372
(Version 0.4) (dated 16th September, 1999) (“CR/ACD/372”) in paragraph
5.2:
(A) at sub-paragraph 6 (headed “.dll checking”) by the time at which the
step detailed in paragraph 7.4 below is completed; and
(B) at sub-paragraph 3 by the later of the completion of the steps detailed in
sub-paragraphs 7.2(A) and 7.2(B) below plus one week.
The Contractor shall complete the steps detailed in CR/ACD/372 in paragraph
5.2 at sub-paragraph 7, in the case of:
(A) running the software distribution of the “Riposte Peripheral Server
(Update Number 20)” by 16th December, 1999, although the Contractor
shall aim to ensure distribution by 30th September, 1999; and
(B) running the software distribution of the “Consolidated EPOSS/Counter
Applications Upgrade” by 16th December, 1999, although the
Contractor shall aim to ensure distribution by 15th October, 1999.
The Contractor shall supply the appropriate supporting documentation as
described in paragraph 5.2 of CR/ACD/372 by 1st November, 1999.
The Contractor shall review the software distribution undertaken in pursuance
of the above sub-paragraphs 7.2(A) and (B) in accordance with paragraph 5.2.1
of CR/ACD/372 by 16th March, 2000, or if earlier, three months from the date
on which the steps detailed in paragraph 7.2 above are both completed.
When the obligations referred to in sub-paragraphs 5.2(3) and 5.2(6) of
CR/ACD/372, the software distributions referred to in the above paragraph 7.2,
the supply of the supporting documentation referred to in paragraph 7.3 above;
and the review of the software distribution referred to in paragraph 7.4 above
shall have been completed, POCL will close AIN 372.
AIN 376
Each of the Contractor and POCL shall complete the steps and achieve the
objectives applicable to it (the “376 Obligations”) set out in Document
CR/ACD/376 (Version 0.9) (dated 23rd September, 1999) (“CR/ACD/376”)
and where that document identifies one party as fulfilling an action, the other
party shall assist the aforementioned party to reach a successful conclusion.
Each of the Contractor and POCL shall complete each of the 376 Obligations
applicable to it by the dates and to the standards set out in CR/ACD/376.
8.3
91
9.2
9.3
9.4
10.
10.1
10.2
10.3
10.4
POL00325269
POL00325269
14
When the TIP Integrity Checking Period ends, POCL will close AIN 376.
AIN 378
In accordance with the details set out in the Acceptance Incident Analysis Form
for AIN 378 (“Form 378”) and in Document CR/ACD/378 (Version 0.3) (dated
16th September, 1999), the Contractor confirms that it has analysed the
incidents in Form 378.
The Contractor shall apply a “Diagnostic”, which shall be effective by 1st
October, 1999, which shall:
(A) detect and prevent null Cash Account IDs, if necessary by forcing the
Outlet to re-run the cash account process; and
(B) log diagnostic messages to facilitate further analysis.
After a sufficient level of data has been acquired from the Diagnostic, the
Contractor shall promptly determine the cause of TIP 916 and shall promptly
apply an appropriate fix and monitor its application until the fix is successful
for a continuous period of two weeks.
When the fix referred to in paragraph 9.3 shall have been successful for a
continuous period of two weeks, POCL will close AIN 378.
AIN 390
As described in the Acceptance Incident Analysis Form for AIN 390 the
Contractor shall introduce a facility whereby, subject to paragraph 10.2 below,
following a crash of the APS at a counter and when undertaking session
recovery or disaster recovery (for those transactions where a system receipt has
been produced), the user shall still have the option of reserving a gap of
transactions and delaying recovery to a more convenient time.
The facility detailed in the above paragraph 10.1 is subject to the qualification
that in the event of a second crash occurring before the initial recovery is
completed, the procedure shall be that the clerk shall undertake recovery of all
those deferred transactions and then any other transactions that may have
occurred as a result of the second crash.
The facility detailed in the above paragraph 10.1 shall be applied by the
Contractor to all Outlets to which Roll-Out has occurred as at that date of
application by 30th November, 1999 and the Contractor shall then monitor the
facility.
When the monitoring referred to in paragraph 10.3 shall have demonstrated
over a continuous period of two weeks that resolution of AIN 390 has been
achieved, then POCL will close AIN 390.
11.
11.2
12.2
12.3
13.
13.1
13.2
13.3
POL00325269
POL00325269
15
AIN 391
The Contractor shall complete the steps (the “391 Obligations”) detailed in
paragraphs 5.1.2 and 5.2 of Document CR/ACD/391 (Version 1.0) (dated 13th
September, 1999) (“CR/ACD/391”) and POCL shall comply with its obligations
under paragraph 5.2 of CR/ACD/391.
The Contractor shall complete the 391 Obligations in accordance with the
timetable and standards set out in paragraphs 5.1.2 and 5.2 of CR/ACD/391.
When the obligations (with the exception of the obligations relating to
timetable) detailed in paragraphs 11.1 and 11.2 shall have been completed,
POCL will close the incident.
AIN 408
Each of the Contractor and POCL shall complete the outstanding steps
applicable to it (the “408 Obligations”) set out in the table in paragraph 5.4 of
Document CR/ACD/408 (Version 1.5) (dated 23rd September, 1999)
(“CR/ACD/408”).
Each of the Contractor and POCL shall complete to a satisfactory standard the
408 Obligations applicable to it in accordance with the timetable set out in the
table in paragraph 5.4 of CR/ACD/408.
When the obligations (with the exception of the obligations relating to”
timetable) detailed in paragraphs 12.1 and 12.2 shall have been completed,
POCL will close the AIN 408.
AIN 412
Each of the Contractor and POCL shall complete the steps and objectives
applicable to it (the “412 Obligations”), and all intermediate actions required to
achieve those steps, set out in the table at Section 6 of Document CR/ACD/412
(Version 0.2) (dated 10th September, 1999) (“CR/ACD/412”) and (with the
exception of item 1 in that table) as described in more detail in section 5 of
CR/ACD/412.
Each of the Contractor and POCL shall complete to a satisfactory standard the
412 Obligations applicable to it (and all intermediate steps and objectives) in
accordance with the timetable set out at Section 6 of CR/ACD/412.
When the obligations (with the exception of the Obligations relating to
timetable) detailed in paragraphs 13.1 and 13.2 shall have been completed,
POCL will close incident 412.
16
SCHEDULE 3
Revised Roll Out Programme
Roll Out Programme
PartA
Week Commencing Number of Outlets (inc.
live trial)
Already rolled out 299
23/08/99 24
30/08/99 1
06/09/99 47
13/09/99 80
20/09/99 158
27/09/99 178
04/10/99 203
11/10/99 203
18/10/99 203
25/10/99 203
01/11/99 203
08/11/99 ic]
15/11/99 0
22/11/99 i}
29/11/99 ie}
06/12/99 i?)
13/12/99 i?)
20/12/99 i?)
27/12/99 ie)
03/01/00 i?)
10/01/00 ie)
17/01/00 0
24/01/00 120
31/01/00 180
07/02/00 250
14/02/00 306
21/02/00 306
28/02/00 306
06/03/00 306
13/03/00 306
20/03/00 306
27/03/00 306
03/04/00 306
10/04/00 306
17/04/00 244
24/04/00 244
01/05/00 244
08/05/00 306
15/05/00 306
22/05/00 306
29/05/00 244
05/06/00 306
POL00325269
POL00325269
17
Week Commencing
Number of Outlets (inc.
live trial)
12/06/00 306
19/06/00 306
26/06/00 306
03/07/00 306
10/07/00 306
17/07/00 306
24/07/00 306
31/07/00 306
07/08/00 306
14/08/00 306
21/08/00 306
28/08/00 244
04/09/00 306
22/09/00 306
18/09/00 306
25/09/00 306
02/10/00 306
09/10/00 306
16/10/00 306
23/10/00 306
30/10/00 306
06/11/00 306
13/11/00 306
20/11/00 306
27/11/00 306
04/12/00 306
11/12/00 ie}
18/12/00 0
25/12/00 0
01/01/01 i?)
08/01/01 306
15/01/01 306
22/01/01 306
29/01/01 306
05/02/01 306
12/02/01 290
19/02/01 275
26/02/01 265
05/03/01 237
Sub total 17,797
POL00325269
POL00325269
POL00325269
POL00325269
18
Part B
Outlets to be Rolled Out under
Operational Business Change
Week Commencing Number of Outlets (inc.
live trial)
12/03/01 165
19/03/01 120
26/03/01 100
02/04/01 85
09/04/01 63
16/04/01 50
23/04/01 30
30/04/01 22
07/05/01 20
14/05/01 18
21/05/01 16
28/05/01 15
04/06/01 14
11/06/01 12
Sub total 730
National Roll Out Total I 18,527 ”
POL00325269
POL00325269
19
SCHEDULE 4
Acceptance Incident Rectification Criteria
PartA
System Stability (A.I. 298)
1. The criterion shall be measured in relation to the Counter Positions in those
Outlets to which Rollout shall have occurred by 1st October, 1999, provided
that that is not less than 750 Outlets. If that shall be less than 750 Outlets then
the criterion shall be measured in relation to the Counter Positions in those
Outlets in respect of which Rollout shall have occurred at the end of the week
in which Rollout shall have occurred in relation to 750 Outlets. For this
purpose a “week” is a week commencing on a date specified in the first column
of the Rollout Programme and the number of Outlets shall include the live trial
Outlets.
2. The criterion to be met by 24th November, 1999 shall be that during the period
from 18th October, 1999 until 14th November, 1999 the total number of Units
reported to the Help Desk in relation to the relevant Outlets shall not exceed
the aggregate number of Counter Positions in those Outlets multiplied by the
eter fi cet Alec .
For this jon a Me shall be measured as follows:-
@)
Gi
(iii)
(iv)
(vy)
each Help Desk authorised reboot shall count as one Unit;
each Help Desk authorised office snapshot print preview shall count as
one Unit;
each work-around authorised by the Help Desk to remove a “no entry”
sign which denies a legitimate function shall count as half a Unit;
each work-around authorised by the Help Desk to remove the necessity
to carry out a reboot or office snapshot print preview where the time
taken to carry out such work-around (as demonstrated by the Contractor
in the test environment normally used to validate test scripts) is less
than 4 minutes shall count as half a Unit.
each work-around authorised by the Help Desk to remove the necessity
to carry out a reboot or office snapshot print preview where the time
taken to carry out such work-around (as demonstrated by the Contractor
in the test environment normally used to validate test scripts) is 4
minutes or longer shall count as one Unit; and
POL00325269
POL00325269
20
Part B
TIP Interface Accounting Integrity (A.I. 376)
The criteria to be met by 24th November, 1999 shall be as follows:-
@
Gi)
iii)
(iv)
wv)
during the period from 3rd October, 1999 until 14th November, 1999
the percentage of Cash Accounts received by POCL across the TIP
Interface containing Cash Account Discrepancies shall not exceed 0.6
per cent of all such Cash Accounts;
during the period from 3rd October, 1999 until 14th November, 1999,
no Cash Account Discrepancy shall arise as a result of a cause previously
reported to POCL as having been remedied;
all new causes of Cash Account Discrepancies identified after the date of
this Agreement shall have been properly analysed by the Contractor and
suitable rectification plans therefor submitted to POCL in reasonable
detail within ten days of the Contractor becoming aware of such Cash
Account Discrepancy;
The Contractor shall have satisfied POCL (POCL acting reasonably) that
the Accounting Integrity Control Release would, had it been deployed at
the relevant time, have identified all Cash Account Discrepanciés
reported prior to 24th November, 1999 which shall have arisen as a
result of any new cause identified after the date of this Agreement; and
those elements of the Rectification Plan for Acceptance Incident 376
required to have been carried out by 24th November, 1999 shall have
been duly carried out.
POL00325269
POL00325269
21
Part C
Helpdesk Performance (A.1. 408)
The criteria to be met by 24th November, 1999 are as follows:-
(a) Service Targets
That each of the following service targets, measured on a weekly basis, shall be
met in at least four of the six weeks which fall between 4th October, 1999 and 14th
November, 1999 (but so that not all such service targets have to be met in the same
four weeks):-
i) that part of the service target referred to in paragraph 4.3.2.1 of
Schedule G10 to the Codified Agreement as refers to the answering of at
least 80% of all calls to the Help Desk within 20 seconds;
(ii) the service target contained in paragraph 4.3.2.3 of the said Schedule
G10;
(iii) the service target contained in paragraph 4.3.2.4 of the said Schedule
G10;
(iv) the service targets contained in paragraph 4.3.2.5 of the said Schedule
G10; and
(v) the service targets contained in paragraph 4 of Schedule 5.
@)
(ii)
(iii)
POL00325269
POL00325269
22
Part D
TIP Interface
The criteria to be met by 14th January, 2000 are as follows:-
during the period from 3rd October, 1999 until 14th January, 2000 the
percentage of Cash Accounts received by POCL across the TIP Interface
containing Cash Account Discrepancies shall not exceed 0.6 per cent. of all such
Cash Accounts;
during the period from 3rd October, 1999 until 14th January, 2000 no Cash
Account Discrepancy shall arise as a result of a cause previously reported to
POCL as having been remedied; and
all new causes of Cash Account Discrepancies identified after the date of this
Agreement shall have been properly analysed by the Contractor and suitable
rectification plans therefor submitted to POCL in reasonable detail within ten
days of the Contractor becoming aware of such Cash Account Discrepancy.
POL00325269
POL00325269
23
SCHEDULE 5
Additional Obligations
1. System Stability
A new paragraph 4.6 shall be added to Schedule G10 to the Codified
Agreement as follows:-
“4.6
4.6.1
4.6.2
4.6.3
Reboot Incidents
The Contractor shall use all reasonable endeavours to ensure that the
number of Reboot Incidents reported to the Help Desk does not exceed
the equivalent of one Reboot Incident per automated Counter Position
in any period of four months.
For the purposes of paragraph 4.6.1 above “Reboot Incident” shall
mean Help Desk authorised reboots, Help Desk authorised office
snapshot print previews and any work-arounds authorised by the Help
Desk to remove the necessity to carry out a reboot or office snapshot
print preview where the time taken to carry out such work-around (as
demonstrated by the Contractor in the test environment normally used
to validate test scripts) is four minutes or longer.”
For the avoidance of doubt, it is agreed that the Contractor shall be
permitted to continue the good business practice of carrying out planned
reboots outside working hours, such planned reboots not to exceed one
per count position per month.
2. Training
A new obligation shall be imposed upon the Contractor as follows:-
“The Contractor shall:-
@)
in relation to those Outlets to which Rollout is scheduled to take
place in or after January, 2000 run 370 half day training events
for 4,400 office managers (or such lesser number as POCL may
require) in accordance with the specification contained in the
document IM/PRO/172, version 0.2 - specification of pre-entry
event;
(ii) with effect from the date of this Agreement deploy the processes
and procedures set out in the document IM/PRD/066, version
0.2 - Monitoring of Trainer Quality;
POL00325269
POL00325269
24
(iii) with effect from 27th October, 1999, implement the new P.S.A.
process defined in the document entitled Pathway Performance
Standard Assessment Proposal, Low Level Plan.
3. Monitoring of Non-Polled Outlets
A new obligation shall be imposed on the Contractor to operate, with effect
from the date of closure of Acceptance Incident 342, the new reporting process
described in CP2078, which will produce an automatic report of Outlets in respect of
which there is no End of Day marker in the central journal file and shall ensure that
such report is e-mailed daily to the Business Support Unit and logged with the Help
Desk for immediate investigation.
4. Help Desk Service Targets
New paragraphs 4.3.2.7, 4.3.2.8 and 4.3.2.9 shall be added to Schedule G10 to
the Codified Agreement as follows:-
“4.3.2.7 100% of calls made to the Help Desk seeking advice and/or
guidance relating to cash accounts shall be answered and
satisfactorily dealt with, as and when first received, by personnel
skilled in providing such advice and/or guidance.
4.3.2.8 No call will be made to the Help Desk from any Outlet seeking
the same advice or guidance in relation to a cash account as
another call from the same Outlet in the same accountirig period.
4.3.2.9 Approved call scripts shall be correctly followed by Help Desk
staff in 95% of all calls, as measured by reviews of call records
carried out from time to time by POCL.”
POL00325269
POL00325269
25
Signed by
for and on behalf of
POST OFFICE
COUNTERS LTD. in the
presence of:
Signed by
for and on behalf of
ICL PATHWAY LIMITED
To the Codified Agreement dated 28" July, 1999
Issue Date: 24' September, 1999
POCL Authority:
ICL Pathway Authority:
POL00325269
POL00325269
POL00325269
POL00325269
1) A new paragraph 3.6 shall be added to Schedule G1 to the Codified Agreement as
follows:
3.6 Data Errors
3.6.1.1 Subject to sub paragraph 3.6.3 below, if the Contractor discovers any error occurring
in transaction records or cash account stream records other than the errors described
in sub paragraph 3.6.1.2 below (“Data Errors”) prior to the relevant record being
transmitted by the Contractor to POCL over the TIP Interface, the Contractor shall
not transmit the relevant record but shall retain it and promptly issue to POCL a
manual error report complying with sub-paragraph 3.6.2 below (a “Manual Error
Report’).
3.6.1.2 The following errors shall not be Data Errors:-
3.6.1.2.1 errors which are caused by invalid data input by Users in Outlets and are
not detected by the process introduced by the Accounting Integrity Control
Release;
3.6.1.2.2 errors caused by Reference Data (correctly applied by Pathway) which
preclude transactions from being correctly taken into account in the
subsequent cash account;
3.6.1.2.3 Cash accounts which are incomplete by reason of erroneous Reference
Data provided by POCL.
3.6.2 Each Manual Error Report shall include a full specification of the relevant record
following correction of the Data Error (the “Repaired Data”), in a format suitable for
POCL to key into a POCL Data input facility.
Electronic Submission of Repaired Data
3.6.3 If in any cash account week the number of Data Errors exceeds 50 the provisions of
paragraph 3.6.1.1 above shall not apply in respect of Data Errors occurring in that
cash account week (except to the extent that Manual Error Reports shall already have
3.6.4
3.6.5
3.6.6
POL00325269
POL00325269
been submitted to POCL). In that event the Contractor shall, unless otherwise agreed
by POCL:
a) withhold the relevant record;
b) correct the relevant Data Error; and
c) submit the relevant record containing the Repaired Data for electronic
transmission over the Data Interface.
Where a Data Error shall not have been discovered prior to transmission of the
relevant transaction record but is subsequently discovered by the application of a
weekly checking process (such Data Error being hereafter referred to as a “Weekly
Data Error”) the provisions of paragraph 3.6.3 above shall not apply to such Weekly
Data Error. Instead such Weekly Data Error shall (subject to paragraph 3.6.6 below)
be dealt with by the issue of a Manual Error Report as specified in paragraph 3.6.1.1
above notwithstanding that the total number of Data Errors in the relevant week may
have exceeded 50.
If the number of Weekly Data Errors exceeds twenty in any week the Contractor
shall, in consultation with POCL, review the process introduced by the Accounting
Integrity Control Release with a view to enhancing such process in order to detect the
relevant Data Errors prior to transmission of the relevant data and to identify and
correct root causes of such Data Errors.
If the number of Weekly Data Errors exceeds fifty in any week POCL shall be entitled
to require the Repaired Data relating to such Weekly Data Errors to be dealt with in
accordance with sub paragraphs (b) and (c) of paragraph 3.6.3 and not paragraph
3.6.4.
The Contractor undertakes that it will apply on a daily basis those checks required by
the TIP Control CCD to be so carried out and that all Data Errors discovered thereby
will then be dealt with in accordance with sub-paragraph 3.6.1.1 or 3.6.3 as
appropriate.
The Contractor undertakes that the delay between the occurrence of a Data Error (or
in the case of a Weekly Data Error, its detection) and the notification of the Repaired
POL00325269
POL00325269
Data to POCL (either by manual error report or electronically pursuant to paragraph
3.6.3 above) shall not exceed five working days.
3.6.9 Where the Contractor is required to make an assumption in order to correct a Data
Error and/or present Repaired Data, the Contractor shall make such assumption and
promptly inform POCL of the assumption made.
3.6.10 The Contractor shall pay to POCL 30 days after the end of each month a sum to
compensate POCL for its costs in dealing with Manual Error Reports equal to £150
per Data Error discovered after transmission of the relevant data and £100 per other
Data Error occurring in the cash account weeks ending during that month.
Other Discrepancies
3.6.11 The Contractor shall, following discovery of any discrepancy of the nature described
in paragraph 3.6.1.2.2 or 3.6.1.2.3 above, promptly issue a report to POCL containing
a brief description of the discrepancy and shall co-operate with POCL to investigate
and resolve such discrepancy.
2) This CCN 562 also modifies Acceptance Resolution Plan 376 (Reference
CR/ACD/376 Version 0.9 Dated 234 September 1999); paragraph 5.3.3. thereof shall
be amended as appropriate to be consistent with the provisions of Clause 1 of this
CCN 562 to the intent that the procedures and obligations set out in Clause 1 of this
CCN562 shall take precedence over, and replace, the procedures and obligations set
out in numbered paragraphs 1 to 5 (inclusive) of the said paragraph 5.3.3.
POL00325269
POL00325269
POL00325269
POL00325269
‘Acceplance Resolution Tnetable ;
[September
Textto_ITe [Task Name Start I Fish apace Sap aCaET pO eS ROpSTOSTINpOT TE TAT POTpS Ta ana Se poe OPT
7) [Management Milestones on Overall Plan Yo Sep 98) 24 Jan "00 per RERATR TARE ak AOR
Final Workshop Sepa] 7 Sep WH Ir
‘Joint Decision on implementation 20/8 and 2778 VO Sep 5] 10 Se5 I
~Aaree Key Corivachal Amends and Milestones Te Sep Wa] TE Sep WS I
I Sep Ie
Fi Sep) ms
hei ceTRAB rraating °
i) RecepanciAB - 4 "
‘Gonfirm rol out pian and volumes for year 2000 (Reset Pian) TINT om
‘Joint Delivery Reviews Wien id I I I 1 I
Full Review of Prograrnme Pian (incl Acceptance, CSR* and Roll Oui) Bde ws] dee [a
Perform AIS76 Live monitoring (pre re-start of NRO) Tyan Wo] Ta Jane Le
‘Start NRO Training Wien 86] 7 Jan bo © i101
NRO Re-Commences Blane] 2 jan WO Is
Aug WI _26 Feb vO
I 31Aug 99] OT NOV 9) I
SAG) STAB) pangs
‘Apply Fixes 13 Sep Wa] Bi Sep 9) Pee
I Rectification Plan agreed Sep] Sep v8 [ona I
‘Assumed Date Of ast Fix DOA] OT OWS] ss
i ~ Monitor Fixes (Minimum 4 Weeks) ~ Bow] soa ane
I ~ Approve Closure of this incident ‘Oi Rov 86] OF Nov We nn
‘Ais42 TiP Data file Delivery WA) CaF)
‘Submit Acceptance incident Form Shug 99] STARE saz t I I
Rectification Pian Agreed DoSep I C8 Sew fou: I I
wat ‘Monitor fixes & Actions TWSep w] 01 Oa 3 I
Monitor fixes and actions complete Oa ws] — OT OAT 4
‘Approve Closure of this incident WOa wo] —OZOA I ues
~~ a90)) A380 Recovery of APS Transactions ‘Di Sep ¥8I 1S Dec W)
32I [Siri Recon edo Fan - TS] SST] a aan
Recification Pian Agreed TOS WTO Sep [203 i
implement APS Recovery Sofware Change BONev] SO NNW [os
‘Wonitor APS Recovery Software Change Bi Bec wa] Taba
78 Bec I 15 Bec wo I
IG Sep 95] Ta Fab wo]
OF Sep 99) TOS) mat pr.
I pec A Pin 010000 Miestone rs Roled Up Tosh TTT Rotes Up Pog ess NN Project Summary PRAMNERT Roles Up Spit
Date 24 Sep 99 NNN 55) Py eeieo Up icsone © Exemal Tests — EERE] soit
Paget
POL00325269
POL00325269
‘Acceptance Resoliton Timetable
i ] [September I Sztobar November ‘Bacemiber [January I February
tento Ie [Task Name stst__I Finish -vopOe node of ola TOPSTODTT parts pa iper perhardpar pr apaoipao hiro paoiprorpropacapreaparty
Present Resolution Plan to POCUPWY working group 73 Sep 5] 13 Sep W5 was
incremental Fixes ~ Gi Sep V9] Ta an
i implement al incremental fxes for incidents identiied Ge Sep Wa] 14 Sep WO 703}
area ‘Approve clearance of al incremental fixes from field evidence WE Eep W5] 200 WH ax
37633)" Report on status of TIP interface integrity 20Sep 99/20 5¢p 90 33
area Review reporting of exceptions Oi Sep B] Ta Tan 8 ares
I a7636) Report Status On Exceptions To 24/11 Checkpoint Ber Bs] — Za Nov i i
aiea7] fal input faciity - ‘1 Oct 98] 30 Dec ws gprs oneeneerr RRR NS A
POEL Bovelop and Test manual input hare] [EERE 2
Toit Test of 50s aneadion ons : ar A
Manual input acity ive Wee ws] 5 sfusra
interim Reconciliation Sw wy
i Sep WWW Sep Bh oss
I Additional Reconciliation (Accounting Integrity Controls) Sep Ws) FAT
ares) Gacumant Logical Design EPOSSIAGcounting Reconciliation Convrols ee Pe
t6 8? Review Logical Design 03 Sep Gi] GT Sep ves?
3783 POCL io identi fare scenarios — Wa] Sew aso
arose) Response to failure scenarios and add to Logical Design VF Sep Wa] 18 Sep 95] sede
T i ‘Agreement to EPOSSIAccounting Reconciliation Controls ce) mI
7686) ‘Document & Agree Procedures to forward Reconciliation Reports to POCL Sep] 7 Sep WH) Tl 27450
wrest ‘Agree Rectification Plan for Accounting integrity Controls Fi Sep Wa] Fi Sep 1 hres
rs) Testing Swaiegy Issued Tap Ws] OF OATH
issue and Review HLTP's BOT) BSA
Development and Link Test 4 Sep 96) — 24 0a99]
Confirm overall release contents of this Upgrade Hoa] Woa ws
Confirm Scripting Approach TTOaw] BOA
Sysiem Testing (integration and Gycie 1) BOA] Ta No
‘System Testing (Gycies 2 and 3) ov wo] Gabe
Evaluation of Test Reports Tibee ws] Be ws
OFF Testing Boar w] oT ee I
‘Software Distribution oe Bi Bec Go] 27 Bec Ws)
Data Centre Upgrade Toe we] Dew
Corimit Accounting intagily Controls Boe we] Ti bee ws
~ Monitor Accounting Intagrity Controls (pre NRO re-start) ‘i Jan'00] 13 Jan'00
Monitor Controls (@ weeks Observation) Wien 06] Ta Few sere
isa OBC ee
t
Projet Ai Plan 010909 Task GRRE sone 4 Rolled Up Task = IEE Rolled up Progress AMEN Project Summary FEE Rolled Up Split
Sate 2459-09 Progress sme S150) Pr ies Up ttesine © Sena Toss ED sot
Page?
POL00325269
POL00325269
‘Acceptance Resolution Timetable
Date. 24 Sep 99
Progress mm Sy
PY Rood Uo Milcstone ©
tonr0 {te Task name sit_I _ Finish
wear) Dacument OBC procedures Di Sep 95) OF Sep WS
OCI Report on OBC procedures review Sep I WW Sep [ovens
‘Test of procedures TSH) TOS] MN sree
‘ares Succ TO Se WS] 2OSep WH
issue Procedures WSep 8] 30 Sep
ares Review Points WSep V8) Dec
a6] Review period prior to Acceptance Checkpoint (6 weeks) Oa] TT Now
I 37682 ‘Approve Closure of this incident TF] Ta Feb OO vase
me ‘AiS7@ Data integrity on Cash Account ‘B1Sep 99] OF Jan vO
a8 Discussion on Design Level Review (TIP incidents) i Sep 98] 17 Sep W
3762) Investigate root cause of additional incidents Bi Sep 85) 21 Sep
if Update Acceptance incident Form Fi Sep SI Fi Sep
I Develop and Appiy diagnostic fix OF Oetw] OF OAL WSI
Goliect Diagnostics BOAT) TOA
3786 Develop and Implement required fix (estimate) GF Nov'86 I GO Nov 95
we Wonitor fix baw HOw
are8] I ‘Modify stock rollover button to add information panel & eliminate multiple clicks ‘Gi Sep 9a] 06 Sep 29)
area) Distribute modification for stock ral over button Sep I GWEN
wen) ‘Approve Closure of this incident (subject to ciagnostic remedial action) Oi jan 06] Oh an WO
aes) 1869 OBCS Failures Gi Sep V9] Ga Fan 0
3a Ropar on Scanner lab tests Oi Sep G5] OF Sep os
3682 “Agree Rectification plan TaSep we] Oz Sep
POGL to obtain agreement irom DSS to provide reject covers DESep w]e Sep)
POCL obiain reject covers Sep Ws] 24 Sep 35
Data Analysis of impounded OBCS compared with ESNS (Trend Analysis) G2 Sep 98] 30Sep 00
Giuster Data Analysis Sep GG] BA Sep
POCL investigale results of Cluster analysis D6 Sep 05] BU Sep
Develop Action pla ig Lab Sep G07 Sep ¥o
Deploy Roving LabiVaiidation tests of rejects at outets TOSep Wa] 25 Sep 09)
Undertake Root Cause analysis to confirm no system issues CSc] TaSep w
Confirm resolution actions and root cause analysis with DSS Te Sep I 16 Sep 08
Prepare Monitoring and Evaluation Pian Sep 0] 2a Sep 3 wel I I
‘Broduce Paper on approach to be deployed in the Pilot WSep Gs] Bw Sep ‘ud
"Pilot scheme ative offices sep I BOR swoas i
Further tests following ‘Plot scheme TOA] TENET HH EXCISED os
Study to enify potential areas of improvement opportunity 5 OctwOI — BE Nav shes
inject A Plan or0000 Took ee o Roles oT TTT Roles Up Pog ess EE Peet Sunmay PAI Rove Up Spt
External Tasks
sm :
Page
POL00325269
POL00325269
‘Acceplance Resolvson Tnetable
I [_Sepiember_—[~—Oetober_I —"Wavemmbor I Deceribor_[_“anuary_[ February
texto Ie [Task Name stat__I Fintan op oapecofroopormapToopar ig ioharTOpSAOGTT Tpart srr por pa aja zporpT apap orf ropuorp woiprazh woe oapsTy
369.17] ‘Confirm process for communicating revisions to procedures (ICL Pathway) 20 Sep] 01 Oct W9 Game i.
saa I Genfirm process for ensuring that changes to system designiprocedures are reflected in wai I 20Sep¥8] 01 0x8 mm}:
sez] Confirm process for communicating revisions to procedures (POCL) OF Ow] i itz:
er) ‘Obsenalions during the Pilot wore EERE 2
‘Gbservations during the further tests folowing the ‘Plot Tio ESE
‘Confirm process for communicating revisions to procedures (for User Guides) ORT Bh fas
‘Analyse barcodes of books which are impounded during the Pilot BOT L4ehas
‘raiyse barcodes of books impounded during further teas Tolowing the ot neat poem
‘Analyse the printing/paper of books which are impounded during the ‘Pilot ~~ ore we
‘Analyse the printingipaper of books impounded during tests following ‘Pilot Tea wo] TaNov we
Reword paragraph(s) in Training workbooks relating to non bar-coded books WSep a] 24 Sep WO)
ised procedures confirmed fornew ofices daring ining events Hie) Wee we
Confirm communication of the revised procedures for new Horizon offices ‘20 Sep G3] —_20Sep 99]
‘Monitor and Evaluate Rejected books BOA ws] 37 Dec's)
‘Approve Closure of this incident Bian G5] Gian
~a7a) I AIS7? Live service upgrades [Saag Wa] Fa dan'o0
aay Daily checks for Corupt executables Di Sep W] 22095]
Prepare Recilication Pian a
Provide ATE Technical details a an
1 ‘Rgree Format of Software Distibution Tee] 16 Sep [ov
] ‘ares Rectification Plan Sept] iT Sep ws [ous
Run Software Distibution (Incl Riposte 20 upgrade, POCL to review) V7 Sep'W] 3050p WH
Run Sofware Distibution (Counters)POCL to review Oa ws] TO
989% of upgrades to be Included in reporting I Beaea] aoa oe
Review above Software Distribution WOaw] BOAT
‘Supporting documentation for live service upgrades Diner Ge] Oi Nov wo
POCL review of Software Distibulion processes GsNov G5] Tan
we) Planning involvement in CSR* I Oi Revo] OT Nar wa
aaa) w “Approve Closure ofthis incident Wan Go] 44 Jan 0
at) Abs System Stability Ti Sep we] RNa ww
2984) Fix Stability Issues ~ OF Sep 98] 24Nov 9
wari] POGL & PWY to agree achievement levels for each deficiency TiS] 2256975) mare ao. 13
om impo ee Bs Tap a] Te noe
‘Gngoing Analysis (Monitor, Analyse and Categorise incidents) Te Sep Bs] anew als
Track, identify and eliminate fauls Te Sep Wi] anor WH node
Evaluate Wi Sep WB Nav ws) " j
Project Al Plan 010089 Task GER ieseone Py Rolled Up Task = ENTER) Roles Up Progress ANNE Project Summary ARBRE Rotled Up Split
Date 24 Sep 99 Progress Ame SU nary Ge aoties Up mitestone Extemal Tasks Spit
Page a
POL00325269
POL00325269
‘Accepiance Resoivton Tnetable
[September I Oclober I —Wovember__ December [Jann [Febaaay——T
Texto I re [Task Name start___I _Finisn _ Poop oepaoof roepocep hooper iioherTopSTopTT per ian spar par paraliartzporiapTAspao poo 7oipaoTp voiprazh ace TeazETy
298.153 Monitor Double F1 fix 22 Sep ®] 29 Sep] "pees
wae ‘Monitor fix to Riposte Peripheral Server T2OAB] 306] oonisa
‘Monitor fix for elimination of printer contention Weep ws] WOAw
Monitor fix to alleviate buiten locking (EPOSS receipt aller APS receipi) Sep Wi) BW Sep wi]
Monitor revised system busy (based on Riposte Desktop processor time) Spe] SOA
Monitor fix to printing 2 final copies of cash account DSSep WI] TOOTS
— Monitor fix to Riposte message archiving procedure Diep wI WOR
‘Monitor fix to APS recovery routines: BSep W9I 24 Oct Go]
‘Monitor fix to Stock Unit checking Beep Ws] MOT
‘Monitor fix io query logged-on user message ee Oi Sep Bs] 50 ep 5
Monitor fix to Memory leakage from Printer Monitor Oi Sop G5] — BU Se0
~~ Brinter Failure with GIRO wansactions printing Bi Sep 8] 300A sos.se2
Monitor fix to APS problem CB Sep WS] HOA
‘Asse5s against success criteria in Part A Schedule 4 Ta Rov 95] 2a Now WH [ 2senes
“Assess agalnat 1 unit por counter por months TiNov Wa] 2a ov I Janse
‘Testing Policy DocumentiResolution Report Ti Sep Va) Nov 98
wea) Produce a Testing Policy document on minimising the risk in future releases OF Sep WS] OOS ep)
I ae Review and Agree Testing Policy Document Vise a] 7 Sep HH
wea Incorporate agreed testing approach into Pathway Testing Strategy TOA ws Te OATS
[e767 "Revisions to the testing & integration approach for CSR®™ ~~ WOW] 24Nov w)
ae x Produce Document WOaw] 300TH) Hasse I
BBE Review and Agree 2aNov Wo] BA Nov 9B) [nse
iinplement provisions Finer G6] Be Naw [rnses
Produce draft of Recification Pian ae er
‘Agree Reciification Pian RSepWI Sep [sear
Review Points WSepWI BNO I
‘Approve Closure of this incident Nov 8] 2a Rov WH Joes
Handover ongoing monitoring and review to Service Management TaNev I 24 Nov 95) I [2032
38) I Al2t@ Managers Training Course ‘Aug ¥8] 28 Feb 06)
Bei ‘Agree Resolution Pian Gr Sep %] 25775) pam lo. I I
Pre-Eniry Event ~ ~ TiAag Vs] ONO]
Tez ‘Agree spec of Pre-Assessment event Ce) ain22
wea) Develop Pre-Assessment course Sep I 22 Sep 98 em asegs
Development Activities Zep] TOA naz
TEL Pathway Ory Run woawI wore nas
POGL Bry Run OF Oat] — OF Oa
I Project: ai Pian 010908 Task REY icstone 4 Roles Up Task — NEE Roied Up Progress AMMEN Project Summary GMMR Fotied Up Spit
I bate 2e Sep 99 Progress RENNIN, Sumary PY ies Up tiesione exena Tasks ERMA spe
Page 5
POL00325269
POL00325269
Tcetnoe Ratan Tinea ]
T [September ‘Oeiober November I —Decsrnber ——[ ——anuary I —Febraary
‘ext10_I 10 [Task Name stan I _rinisn _ Toe Ooaa/of ooo fe ToRSTOp A par fis POT pO aera opOrpTA ap Roof vipa Topaz woop waapa
627] “Rmendmenis Made WOR w] 1200 [oar
Ha] Event Sign Of Woarwe] Woaw Jana
wea] Define and Agree Processes Bseqw) Woaw REET I
7830) Event Ready Tier Ye ov
I Raise CONGAS (Change RNM) ra aes
Submit CON Ben etdias
‘Approve CGN - . — Hep ia18s4
Monitoring Trainer Quality - Sep
Send Proposal to POGL 5 Sep
Fagan Review Sep
~ Develop and Sign off Document 8 Sep
Wontor Walser Delivery Bese I
Review of PSA ep 99
Drak Proposal to ICL Pathway ae
POCLICL Pathway Approval Process Sepa
“Approval of Review of PSA Process by POCL enw [ss
New PSA implemented HoaveI 7 Oa wo ‘°
Review, Design, Agree, inplomant PSA Falure Process Fi Sep] 20a] oe ee
I -aiass)}- Review of MTC Process (Amond, Agrea, inplomend Siete] URNS CREE vss
ea OCI Post instalation Suppor Sep] Oi Nov we viesr
ant Post Training Consolidation Tap eat Fane :
Tesi HSUG Process on Training Mode (Reviaw, Amend, Agree, Implement) TS Sep W] BOTH I beset
218582) ~ Training Workbook Exercises (Review, Amand, Agree , implement) 16 Sep 9] 5 Now 85 ; 218.902
ca Review Changes to User Training (Review, Amend, Agree, plement Tew] —HOTH arains
Promote Use of Training Mode OF Sep] OF Jan 8 siasee
Fae) Canfiem Success Criteria ~ Bee) Sew) BE asdeor
210 6a) iow and Agree Specie Performance Measures Sep 95] WORT
wees — ai oarwa Fr Oat9
I aeoe ‘Check and Assess Performance Woawe BOAT I
216065) Check Documentalion for Consistency TONov 96] Z2Nor we
3B 606 Performance Review Meeting Wee G8) 13 Dec we
“Breer Performance Review Report TO Jan G0] TO Jan 60) I I
a Meniior Ro-Out Bi lan 06] 20 Fed OS
Hiss) X] ——~Mieeing of all bigatons (Complete oer elements of valning solution) HOR ws] HORT I La
roma Pian o%o000 Task en ° er er
Dale 24 Sep 92 Progress emmmememment Sunray PRN Roles Up tiesione exeraiTais sou
Page 6
POL00325269
POL00325269
TecelnceRefouaonTineaie
[Sepiember ——T ‘Detober [November [December I January Lfetway I
Textto_ITe I Task Name Start Finish Pv08proepevo6fr voeporoep 0opa/ of /iof a iopsriopir part isn pan iporiipaiahiari2poni2prnzpaoipoorp7oipaoipvoipraapancapreapeoa
216.610) X Approve Closure of this incident based on CSF's ‘26 Feb 00} 26 Feb 00) ] 7
‘a4 Physical Security Beep Taw
i I Produce Acceptance Incident Analysis - Status report OFSep eS] OSH] sty \
Fires Recticaton Plan OTS) OT] an I
Produce revised sie plan both sites Tap Wa] SEH TH coma
instal new palsads fence al Boots mem
"Agree improvements to vehicle access baseline controls ~
59) Extend card 3cb8ss convas to Back gale al Wigan ee) a
install extra camera between data centre and perimeter at Wigan [AF Sep 98] 30 Sep Wa aa .
‘Decide on Tare exclusion Zona at Wigan ard nouly POGL kewl WHT Fl I
Taplement thar exausion Zoe at Wigan WOAH Oe
- ~ Add New exclusion zone to Red Care 8 Oct'99) 31 Dec 99) ERE ts
Update Wigan Tocal procedures Macchia
Produce and iplementinoclorsTelatig Wo ala respons Woe wal TORT
“dé Natin tigger to Palisade to Red Care Sap] BOR ae
POCL inspection of Wigan and Boot Sean Wo] Toa sovte
‘Approve Closure of this incident 11 Jan 00] 11 Jan 00) ee
ia) ~} ~ Aist4 Technical Document for Procurement Wha] oF
POEL to review and convient on new proposals rr pe
PWY to amend and reissue proposals a 01 Sep 99)
‘ere Reciicaton plan oe)
Reviow VO. of CSISPEIOO7 (Spec or document) Beep
“Produce revised version of CS/SPEIOO7 (epac of document) OF Sep 3]
3. ai T Produce CS/SPE/007 Generalised API for OPS/TPS- 24 Nov 99]
Ha x Formal Review with POCL and re-issue 23 Dec 99] 47
Produce Anpendies or)
Review revised AP! document with Appendix ‘1 Jan 0) I 3149
issue fovised API document with Appendix as CON a) aso
‘eprove Cisse of bis cidont Fee vast I
‘Aida HH CaI/SLA falls Shag Wa] Bao a I
Submit Resouion Plan Tew] ae] aor
Taree overall Reciicaton Plan and checkpoints Bia w) Tee I
blah Cash Account process document v2.1 Bie THM) pans
‘Seip Workshop (hare new Serpi5) Bip e) BS! \
Further Script Workshop (POCLPathway Review) TW Sep 3] — Ta Sep 9] a [ans I
Projeit:A Pan 010000 Task RR iesione ry Rolled Up Task ETE oes Up Progress ANNE Project Summary AAMT Rolled Up Spit
ate 24 Sep 99 Progress eT rN oles Up Miestone © Exteel Tasks EERE) spit
Page?
POL00325269
POL00325269
“Acceplance Resoliion Timetable
[September
texto [10 [Task ame cron I _rvun _ [SRSDeRpra SeapS nT ASU oe OPSORTTpo TSP BST po SET ET pe coe
4085] X Training of 6 off HSH siaifin the use of new sorpis 70 Sep'@5I 15 Sep 99 ves T
WaT] XI Training af furor 14 off HSH alain the use of new scrple Sep] SO Sep amar I I
wey x 2nd Line Refresher Course Sd Ln oe I
waa x Tat Line Refresher Courses Di Sepa] Sep WH oss
watt] x Exper Domain Operational (imploment new seripls) Sep] Sew Pest
wate Resourcing Model workshop Sep] CH Sew Boone
‘Workshop to review resoutcing modal and processes for SLA Measurements Woaw] BOTT [oon
Proposal io measure perfomance of Laval ash account ai hang wav (SLA) OT Sep] 10 Sep a oe
POCL counter proposal and review wep wl TTS ws rr
1st Audit of Gash Account Service Levels WOaw] TOIT Jae
Monitor against Acceplance Resolution Plan (prior t Accaplance Checkpoint) TOA] a Nov we east
Workshop on U3 Cash Account SLA Capture ~ 14 Sep Wo] 14 Sep [aes
Timplement (3 Cash Account SLA Oa a] BGA I woe20
Undertake compliance Audit of HSH scipis Woaws] Ta Sw Boone
Gross Reference to Equivalent Service Contract Schedule (Matix Mapping Call CalegorsatI 19 Sep'%9I — 50 Sep 00] EENTGY crn
way x Wesling to discuss Logiaice and motes for Gash Account Service Levels WSep wo] Fi Sew H foes I
‘iaa2sI I Wrkshop to describe processes for Sonice Level Measurement Boaw] —FoAw Bane I
was "Train and introduce Additonal HSH slat Tsp] TaN a I
Publishing of Weekly SLA Measurement Beep Ww) iho
Review Performance againat SLA Shove] Toho we
W826] XI ~~ Approve Closure ofthis incident Ti nov Ba Nav
“z) I Al4fa Provision of ad hoc repor in accordance with schedule CATEv10r reqt 814 D6 Bap 9] OT Nov We
waz] I Produce Recilicalion Plan Di Sep BS] TO Sep w
wea) Report on the history of Ad-hoc reporting Sep] TI Sep
Review Escalation procedure in Ad Hoc reporting process sep we] TIE TI
I Rareed improvernenis to the Ad-Hoc Request process Ta Sep 35] SOS
~- Guana bilge iota Mia
1 Produce and Agree "Bala Structure” definiion document Sep 0] —Ze0aw
I “azal I fase on reporing cycle associated with srvice level calculations Sep We] T3Sep we
Tia] I Produce and Agree "Service Level Reporting Gyele document TO Sep 5] 280A]
pany x) ‘Approve Closure of this incident GiNov G8] — OF Nov 96
w Non/Low Severity Incidents WO Sep 98] HOt
1 “Raree satus of disputed items Weep] oT oa]
32) Finalise Plan for 39 off Cow seventy incidents Gcdad Mielke
Project Ai Pian 010999 Task CREE Miesione ¢ Roled Up Task — TTY Rolled Up Progress NRE Project Summary FRAME Rolied Up Spit
Date: 24 Sep 99 Progress: Mme I Summary GG aolied Up Milestone External Tasks RENE) «spur .
Page 8
POL00325269
POL00325269
THIS SIDE AGREEMENT, being Change Control Note (CCN) No 561 is made the 24th day
of September, 1999
BETWEEN:
1)
POST OFFICE COUNTERS LTD. whose registered office is at Gavrelle House, 2-14
Bunhill Row, London EC1Y 8HQ; and
2) ICL PATHWAY LIMITED whose registered office is at 26 Finsbury Square, London
EC2A 1SL (the “Contractor”)
WHEREAS:
a) The parties have today entered into a Second Supplemental Agreement (the “Second
Supplemental Agreement”) to the Codified Agreement (the “Codified Agreement”)
between the parties dated 28% July, 1999.
b) The parties entered into a Supplemental Agreement dated 20% August, 1999, to the
Codified Agreement (the “First Supplemental Agreement”).
c) This Side Agreement (the “Side Agreement”) constitutes CCN No 561 to the Codified
Agreement.
d) Through the execution of this Side Agreement the parties wish to agree to co-operate
with each other with a view to optimising their available Rollout resources and
minimising the occurrence of fluctuations in workloads.
It is Agreed as follows:
1
11
1.2
2.
INTERPRETATION
Words and expressions defined in the Second Supplemental Agreement, the First
Supplemental Agreement or the Codified Agreement shall bear the same meanings
when used in this Agreement.
In this Agreement the expression “POCL” shall bear the meaning ascribed thereto in
the Codified Agreement.
Unless the context otherwise requires references in this Agreement to clauses and
recitals are to clauses and recitals to this Agreement.
COOPERATION
Each of the Contractor and POCL agrees to co-operate with the other:
a) to optimise utilisation of the Contractor’s and POCL’s available Rollout
resources; and
b) to minimise the occurrence of fluctuation in POCL’s and the Contractor's
workloads during Rollout.
3.
POL00325269
POL00325269
PARTICULAR OBLIGATIONS
Without prejudice to the generality of the obligations contained in the above Clause 2:
4.
a)
b)
d)
POCL will implement a policy change with effect from 1st October 1999, so that
each subpostmaster will be given specific dates for training and implementation
and will only be allowed to refuse those specific dates in exceptional
circumstances. Following the implementation of such policy change the
Contractor shall produce a Rollout plan which is evenly balanced between days
of the week in which Rollout is scheduled to take place.
POCL will undertake in-office data migration of up to 315 Outlets per five day
working week (the “Number”). The Number shall be proportionately less in
weeks including public holidays. POCL will use its reasonable endeavours to
undertake in-office data migration in more than the Number of Outlets to the
extent necessary to accommodate variations from the Roll Out Programme due
to variations from anticipated dropout rates.
POCL and the Contractor shall work together to agree Rollout plans for each of
the four implementation programme areas (each being an “ Area”), so as to
minimise week-on-week variation in workload (after making appropriate
adjustments for public holidays and increases and decreases of work in each
Area so as to achieve in aggregate the weekly requirements of the Roll Out
Programme), to the extent that this is practicable given other constraints (which
without limitation shall include the geographical distribution of Outlets and any
other constraints) (for each Area, the “Area Implementation Programme”).
The Contractor and POCL shall agree procedures such that POCL is given by the
Contractor as much advance notice as is practicable of numbers of Outlets
dropping out of each Area Implementation Programme on completion of
training so as to enable POCL to undertake short-term re-balancing of resources
between Area Implementation Programmes.
DEVELOPMENT OF PROCESSES AND REVIEW
The Contractor and POCL shall work together to develop processes to support the
obligations detailed in Clauses 2 and 3 above, and will review these processes jointly by
‘1st November 1999.
5.
5.1
5.2
MISCELLANEOUS
The provisions of clause 603 of the Codified Agreement shall apply, mutatis mutandis,
to any notice to be given under this Agreement.
No delay or omission in exercising any right, power or remedy under this Agreement
shall:
i)
it)
affect that right, power or remedy; or
operate as a waiver of it.
5.3
POL00325269
POL00325269
The single or partial exercise of any right, power or remedy under this Agreement
shall not prelude any other or further exercise of it or the exercise of any other right,
power or remedy.
The rights, powers and remedies provided in this Agreement are cumulative and are
not exclusive of any rights, powers and remedies provided by law.
The provision of this Agreement shall be deemed to be incorporated as appropriate
amendments to the Codified Agreement.
Except to the extent expressly amended by this Agreement, the provisions of the
Codified Agreement and its schedules shall continue unamended and in full force and
effect.
IN WITNESS WHEREOF THIS Side Agreement has been executed on behalf of the parties as
follows:
Signed by: H i
for and on behalf of: I i
POST OFFICE COUNTERS LTD., in
the presence of:
Signed b
for and on bel
ICL PATHWAY LIMITED, in
the presel
alf o!
PART 1
AIN 211
AIN 218
AIN 298
AIN 314
AIN 342
AIN 369
AIN 372
AIN 376
AIN 378
AIN 390
AIN 391
AIN 408
AIN 412
PART 2
AIN 211
AIN 218
AIN 298
AIN 314
AIN 342
AIN 369
AIN 372
AIN 376
AIN 378
AIN 390
AIN 391
AIN 408
AIN 412
analysis
document
document
document
analysis
table from
document
document
document
analysis
document
analysis
document
document
document
ANNEX
dated 20/09/99
CR/ACD/218 version 0.5 dated 23/09/99
CR/ACD/298 version 0.8 dated 23/09/99
CR/SPE/007 version 0.3 dated 07/09/99
dated 16/09/99
BA/ACC/020 version 0.4 dated 20/09/99
CR/ACD/372 version 0.4 dated 16/09/99
CR/ACD/376 version 0.9 dated 23/09/99
PI/DES/002 version 0.7 dated 20/9/99
dated 16/09/99
CR/ACD/378 version 0.3 dated 16/09/99
dated 16/09/99
CR/ACD/391 version 1.0 dated 13/09/99
CR/ACD/408 version 1.5 dated 23/09/99
CR/ACD/412 version 0.2 dated 10/09/99
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
POL00325269
POL00325269
Acceptance Incident Form Acceptance Incident Number (1)
211
Acceptance Test Name (2) Source (3) Date Observed (4)
EPOSS BSM 04/05/99
Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
Calum Craig
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
Criterion not met__> High
Substantive fault <Medium >
Other Low I
Pending
None
Description of Incident (10)
4 new occurrences of the receipts and
payments mismatch problem:
Week 20:
RED 99081810546
[RED 99081810547
Week 21:
HSH 9908240194,
HSH 9908240195
Receipts and payments do not equal on the cash account. The receipts total is different 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.
Signatures (11)
Witness / Reviewer Horizon Acceptance
Test Manager
Pathway AIM
Date: Date:
Date: Date:
DSS Acceptance Manager
POCL Business Assurance
Entered in Acceptance Database
Date:
Version 1.0
lofl
24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
218
Acceptance Test Name (2) Source (3) Date Observed (4)
Impl. A - User Training Rollout 19/05/99
Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
Graham Katon
Incident Type (7) Criterion Reference (8) (if riterion not met) Incident Severity (9)
Criterion not mer > =P! High
Substantive fault Medium >
Other Low
Pending
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.
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:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
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
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
I Griterion not met_> 536-01 High
Substantive fault Medium
Other ow >
Pending
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 on
31st May and the 28th June. However, as such problems should be reported directly to the HSH, it is likely that this
Inumber 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)
Witness / Reviewer Horizon Acceptance Pathway AIM
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
314
Acceptance Test Name (2) Source (3) Date Observed (4)
POCL Infrastructure Review 15/06/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Bob Booth
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
{Criterion not met > 469-01, 469-02, 470-01, 470-02, 869-05 High
Substantive fault Medium >
Other Low
Pending
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.
At 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
a 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 External 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 meet the criteria as being clearly defined technical documentation.
Providing third party documentation as with 'Riposte 32 API Specification’ indicates that the documentation is not
Imaintained by Pathway and therefore does 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.
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:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
342
‘Acceptance Test Name (2) Source (3) Date Observed (4)
TIP Interface BSM 02/06/99
'Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
Martin Box
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
Criterion not met 831-01 High
Substantive fault Medium >
Other Low
Pending
None
Description of Incident (10)
New description: A number of individual operational incidents have been raised by TIP concerning (a) the delivery
of transactions files and cash accounts to TIP after Day D, (b) Transaction files and / or Client summary files not
being received at all on the expected dates and (c) files not being delivered by 03:00. The continued occurrence of
such incidents suggests that there is a system management fault that will cause a breach of the SLA for Data file
delivery, in particular that 100% of all transaction records are to be delivered by 03:00 on Day D. (Schedule G10
paragraph 3.1) A consistent failure to meet this would constitute a high severity fault and an occasional failure would
constitute a medium severity fault.
The gateway of accepted files has not been cleared down. This could cause a potential files overload and the gateway
would not be able to handle the volumes. Currently, the analysis if the gateway is unnecessarily cluttered, causing
delays in the production of statistical results. POCL do not know if this is a procedural problem or whether there is a
fault in the systems management of the gateway. A TIP incident number 784 was originally raised on 11 May 1999
and the original Acceptance Incident was raised with Pathway at the time but was withdrawn in order to amalgamate
the TIP incidents into aggregate ones. This particular one stands on its own and is being re-raised.
Severity: POCL - medium
PWY - admit it is a problem but question why SLA's are not being used for this. The second part to the AI is
old number AI 363. They were lumped together as the outcome of the Gateway not being cleared would result in
non delivery of files.
Rectification: Richard Brunskill to provide details of rectification plans.
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:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
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
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
IGriterion not met_> 836-01 High
Substantive fault Medium
Other Low
Pending
None >
Description of Incident (10)
The bar code scanner reliability is questionable in relation to OBCS transactions where there has been a high
number of rejections of pension and allowance books.
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:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
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
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
a 476-04, 476-05, 537-01 ;
Criterion not met__> High
Substantive fault Medium >
Other Low
Pending
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:
b) 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 errors caused by corruptions to .dil 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
- appearance of a No Entry sign on the desktop preventing continuation (Pathway problem reference PC0027743)
IAn 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.
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:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
376
‘Acceptance Test Name (2) Source (3) Date Observed (4)
TIP Interface BSM 19/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Martin Box.
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
IGriterion not met_> 831-01 High
Substantive fault Medium >
Other Low
Pending
None
Description of Incident (10)
New Description: AIS contravention/ Data integrity - derived cash account not equal to the electronic cash
account. 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 received 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 account with
the electronic cash account sent by Pathway. Not all instances of similar occurrences have been logged by TIP as 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 each 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 respect 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.
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:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
378
Acceptance Test Name (2) Source (3) Date Observed (4)
TIP Interface BSM 19/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Martin Box
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
831-01 High
Substantive fault Medium
Other Low
Pending
None >
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 - due 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 details of dates for
download to outlets so TIP can monitor the rectification.
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:
Version 1.0 lofi 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
“Acceptance Incident Form Acceptance Incident Number (1)
390
Acceptance Test Name (2) Source (3) Date Observed (4)
APS Review 09/07/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Bob Cragg
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (0)
—— 549-02, PS-32 ;
(Criterion not met__> PS High
Substantive fault Medium >
Other Low
Pending
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. Due 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.
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:
lofl 24 September 1999
Version 1.0
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form 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 (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
Ke ‘terion not me 698-01, 698-02, 698-03, PS-22, PS-39, PS-40, PS-41 High
Substantive fault Medium
Other Low
Pending
None
Description of Incident (10)
The physical security controls in force at the two main Pathway data centres at Bootle and Wigan are deficient ina
number of areas, when measured against best practice, relevant standards (BS7799, as required by 698.03 and PS41,
IDITSS 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 turn the response to
Requirement 698.02.
‘The data centres are a critical element 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
intrusion - at various points tensioning wires are missing, the fence is not secured to the ground, locks are missing or
‘in a poor state, the fence is just fixed to the uprights purely by twisted wire, etc. Although the inner moat is covered
by an IR alarm and CCTV, this is little mitigation against a quick denial of service attack; as above, POCL have
been denied permission to view the CCTV coverage.
Wigan
1. The overall site is largely "public", with few controls on pedestrian access, indeed the area near to back gate was
in use by youths, unnoticed by the site security presence, during a recent visit. Although some legacy CCTV is in
place, this is monitored by a single member of staff who also acts as receptionist, undertakes tours of inspection etc,
which given the lack of any movement detection or site alarm is unlikely to provide reliable detection of intruders.
[One CCTV camera has been "missing" since the time of our initial visits, and we understand that ICL Pathway have
declined to pay for a CCTV upgrade. The outer site fence is again a delimiter rather than a security barrier. Asa
result, there is in effect public access right up to most of the building, or to within 5m of the Data Centre (although
the inner nrotection to the Data Centre has naw heen hroneht 1m to a more accentable standard)
Version 1.0 lof2 24 September 1999
Second Supplemental Agreement Annex to Schedule 2
assets (including services")
BS7799 s5
Relevant referenced documents for Physical Security include:
- Pathway Security Management Procedures - s5 (eg 5.1.1 "security of the perimeter is consistent wit the value of the
DITSS s13 (specific advice on vehicle parking distances etc).
Note also the new Data Protection Act imposes a duty on Information Security.
the inner protection to the Data Centre has now been brought up to a more acceptable standard).
Note that Pathway’s own Security Management Procedures [s5.1.1] refers to "defined perimeters. ... with consistent
level of security” and states that the security measures shall ensure that:
a) the security of the perimeter is consistent with the value of the assets (including services) under protection
Ib) the security perimeter is clearly defined.
POL00325269
POL00325269
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:
Version 1.0
2 of 2
24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
408
‘Acceptance Test Name (2) Source (3) Date Observed (4)
Service Levels BSM 23/07/99
Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
David McLaughlin
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
Criterion not met High
Substantive fault > Medium >
Other Low
Pending
None
Description of Incident (10)
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 1 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
IAll of these failures will have an impact on the network and customers.
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:
Version 1.0 lofl 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
412
‘Acceptance Test Name (2) Source (3) Date Observed (4)
Help Desk BSM 01/09/99
Witness/Reviewer who observed Incident (Owner) (5) Authority (6)
Jerome Brice
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
Criterion not met_—> High
Substantive fault Medium
Other Low
None I
Description of Incident (10)
Pathway produce a Service Review Book reporting performance against service levels on a monthly basis. In the July
1999 Service Review Book, Pathway reported that during the previous month they had passed all the service levels
relating to transaction services for AP, EPOSS and OBCS (these all relate to transaction times).
On the 22nd July 1999 Adele Kilcoyne requested an ad-hoc report from Pathway to be provided by 3 August. Pathway
acknowledged receipt of the request on 29 July.
The purpose of this request was:
- to confirm the overall level of service for the purposes of live trial evaluation (the review book does
not report actual levels of service if the SLA is met)
to verify that Pathway are calculating these SLAs in accordance with the contract schedules.
Pathway are contracted to provide this information within three working days of the request (Schedule CA15v10r
Requirement 914).
When this information had not been received on the 13 August Adele left a message on Richard Brunskill’s mobile
phone, no reply was received. As information had still not been received on 27 August, Adele made a further request.
‘In response to this request Adele received a phone call from Nicole Meredith of Pathway on the 27 August who
reported that they were now looking into this and would produce the information as soon as possible, and that the
person who is dealing would be back the following week.
The reason given for the delay was that the information was not available until now.
[As of today, 1 September, this information has still not been supplied.
‘The reason given for the delay is a major cause of concern for the following reasons:
- if the data was not available it would not have been possible to report that they had passed the service levels - this
calls into question the veracity of their service reporting.
- the computation of these service levels requires transaction counting (for the purposes of weighting fall-back
transactions and the calculation of remedies). Without this information we do not have assurance on how transactions
are being counted in the live environment for Service Levels. We know from a meeting between Liz Blackburn and
(Graham Wingrove and Dave Fletcher of Pathway (9 July 1999) that the system cannot currently count as defined for
steady state charging purposes as defined in Schedule A12.
- Pathway have not provided assurance that data will be available to timescales in the future. Adele Kilcoyne raised
Pathway’s refusal to provide three such previous requests at the 21 July Service Review Forum. She asked for
clarification of the agreement to provide information in this manner and also asked why no reason had been given for
not be able to supply this data. Richard Brunskill stated that from this point forward all ad hoc requests would be sent
via him and that a documented procedures was to be agreed (these comments are as minuted). Clearly Pathway’s
statement an 27 Anonst snogests that thev are insufficiently resonrced and are not canable of meetino the reanired
Version 1.0 lof2 24 September 1999
Second Supplemental Agreement Annex to Schedule 2
timescales for delivery.
statement on 27 August suggests that they are insufficiently resourced and are not capable of meeting the required
POL00325269
POL00325269
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:
Version 1.0
2 of 2
24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
‘Acceptance Incident Analysis Form To be completed by the ICL Pathway Acceptance Manager:
: to be given to the Horizon Acceptance Incident Manager
‘Acceptance Incident Number (1) [Analysis Sequence Number (2)
211
Acceptance Test Name (3)
EPOSS
y (5)
Analysed Incident Severity (4) "0" ] High / Medium / Low (4)
ius : : Medium
Analysis of Acceptance Incident (6)
Four calls have been formally added to this incident, and are addressed below.
In addition we have been informed of a further 7 incidents in week 22, detailed analysis of which has been sent
separately to Calum Craig and to TIP. In summary 6 of these resulted from a fault introduced by an attempted fix in
another area, which resulted in the system not preventing the user from swiping a book while at an inappropriate menu.
This bad fix has already been reversed out and a good fix made.
‘The 7th incident was caused by the reversal of Parcel Traffic and Non-Accounting Data transactions within a single
Existing Reversals session. This should not be done, and EPOSS needs amendment to prevent transactions with
different original transaction modes being reversed in the same session. This is being fixed under PinICL 29148. A
fix is in test and is expected on the counters no later than 22nd September.
IWe have also been informed of 5 incidents in week 23. These were caused by transactions in incorrect modes, as for
the 6 above.
[RED 99081810546, HSH 9908160116, PinICL 28627 was caused by a user navigating to the reversals screen while
having a remittance on the stack and then settling it, causing the transaction to be settled with the incorrect mode.
Solution is to disable the reversals button. Fix in test and is expected on the counters no later than 17th September.
RED 99081810547, HSH 9908160118, PinICL 28628/28547 was caused by an error which allowed the stock unit roll
process to be executed twice. This is in fact another aspect of TIP Incident 910, part of AI376. The multiple instances
of stock unit roll not only caused the inability to harvest cash account records but also put the counter into the wrong
ICAP and added the bought forward value for the start of CAP21 into the line 1085 value in the CAP 20 cash account.
The fix was delivered to outlets starting on 14th September.
HSH 9908240194/5 are similar: During APS recovery a situation occurred in which an APS transaction was recorded
against the Default stock unit, causing the cash account to be out of balance. Fix will shortly be passed to OTT, and is
expected in live by 24th September.
(Number of continuation pages
Clearance Action (7)
Pathway to deliver fixes and monitoring to continue for four weeks after last fix.
[Number of continuation pages _ i
Acceptance Incident Status (Qpen/
{ Retest/Recommended for KPR (8))
[Agreed Resolution Plan.
{I propose the Clearance Action ICL Pathway Test
and Incident Status described [Manager
above P. John Pope i :
20-Sep-99]
Version 1.0 lof2 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
‘TL accept / reject the Clearance Horizon Acceptance Date:
Action and Incident Status 'Test Manager —
described above
Horizon Acceptance Incident Manager Date:
DSS Acceptance Manager POCL Business Assurance
Date: Date:
Version 1.0 2 of 2
24 September 1999
ICL Pathway
Resolution Plan
Acceptance Incident 218
POL00325269
POL00325269
Ref: CR/ACD/218
0.5
23/9/99
Document Title:
Document Type:
Abstract:
Status:
Distribution:
Author:
Comments to:
Comments by:
Resolution Plan for Acceptance Incident 218
Resolution Plan
This document contains ICL Pathway’s plan to Close
Acceptance Incident 218
Issued
Expert:
Peter Copping
ICL Pathway:
Library
POCL:
Steve Grayston
John Meagher
Min Burdett
Jeff Austin
W M Foley
Pathway list
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page I of 7
ICL Pathway
POL00325269
POL00325269
Resolution Plan Ref: CR/ACD/218
. Version: 0.5
Acceptance Incident 218 Date: 23/9/99
Q Document control
0.1 Document history
Version
0.1
0.2
0.3
0.4
0.5
Date
20/8/99
16/9/99
22/9/99
22/9/99
23/9/99
Reason
Initial draft for comments
Agreed Resolution Plan
Amended following POCL feedback
To include critical success factors
Further updates arising from drafting of Schedule 2 Part A of
the second supplementary agreement
0.2 Approval authorities
Name
JH Bennett
JCC Dicks
W M Foley
Position Signature Date
Managing Director
Customer Requirements
Director
Business Development
Director
0.3 Associated documents
Reference
Vers Title Source
0.4 Abbreviations
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page 2 of 7
POL00325269
POL00325269
ICL Pathway Resolution Plan Ref: CR/ACD/218
Version: 0.5
Acceptance Incident 218 Date: 23/9/99
0.5 Table of content
1 PURPOSE
2 SUMMARY
3
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 7
POL00325269
POL00325269
ICL Pathway Resolution Plan Ref: CR/ACD/218
Version: 0.5
Acceptance Incident 218 Date: 23/9/99
1 Purpose
This document sets out ICL Pathway’s proposals that Acceptance Incident 218,
currently a medium severity incident, has an agreed resolution plan and that its
achievement will allow Acceptance Incident 218 to be Closed.
2 Summary
The Acceptance Incident was raised stating that "the majority of offices were
experiencing considerable ongoing difficulty in performing the completion of office
cash accounts.
Since then, there have been a number of developments in different areas to support the
closure plan for AI218. These areas are detailed below and all activities are included
in the overall resolution plan and activities are on schedule. A set of success criteria
have been drawn up and were passed to ICL Pathway on 26 August 1999.
The closure report reflects the application of the appropriate set of success criteria and
cross refers to the relevant measurement, analysis and 'agreement to close' activities to
be included in version 0.3 of the Rectification Plan.
3 Detailed activities
These have been in the areas described below. Where applicable the dates associated
with these activities are contained within the Timetable, Part B of Schedule 2 of the
second Supplementary Agreement (“the timetable” ).
Application software: changes have been made, principally in the area of stock unit
balancing and cash account to both software and surrounding processes to make the
task of office balancing easier to understand and complete. These changes were
implemented for LT2 and have proved successful in live use.
Training: changes have been made to the managers’ training event to spend more
time on the areas of error handling, printer use and principally stock unit balancing
and cash account. Again, these changes have proven successful in live events.
Help Desk: The Horizon Systems Helpdesk (HSH) has now been strengthened by the
addition of a cash account domain on Wednesdays and Thursdays. This is to ensure a
more advanced level of support for offices that are encountering cash account
problems.
Further to the activities above, a workshop took place on 13th August which
identified seven specific areas for potential improvement in association with AI218.
Commercial consequences of the actions below are agreed in an exchange of letters
between Bruce McNiven of POCL and Liam Foley of ICL Pathway(ref B.McNiven
letter of 3rd Sept. and Liam Foley's letter of 8th Sept.).
These areas are as follows:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 7
POL00325269
POL00325269
ICL Pathway Resolution Plan Ref: CR/ACD/218
Version: 0.5
Acceptance Incident 218 Date: 23/9/99
e Pre-Entry Event
ICL Pathway has offered to develop and run 370 half day events for a maximum of
4,400 office managers. This is a new event and the dates for the development of this
event are covered in detail within the timetable. Specification of the event is defined
in doc. IM/PRO/172, version 0.2 - Specification of pre-entry event. This specification
has been agreed with POCL through joint working groups.
© Post Installation Care
References were made in the success criteria for AI218 to the importance of an agreed
resolution plan for AI408. It has been jointly agreed that the Resolution Plan for
AI408 is sufficient to cover any residual concerns about post installation care and
consequent references to training.
e Post Installation Competency Strategy
The joint workshop on 13 August accepted that not all users within the large
population will ‘absorb’ Horizon. This may eventually call for closure of the outlet,
replacement of the sub-postmaster or training of additional staff. It has been agreed
between POCL and ICL Pathway that other steps taken within this resolution plan
should minimise the risk of this and that any residual fallout will be handled by
POCL. POCL have agreed to review and strengthen the relevant process. This is
reflected in the timetable.
e Monitoring Of Training Delivery
ICL Pathway has produced a document IM/PRD/066, version 0.2 - Monitoring of
Trainer Quality to detail the processes and procedures that are adopted by
Knowledgepool to ensure a high quality of training delivery. This document has been
reviewed by POCL and comments made which have been reflected in the latest issue
of the document.
e User Competency
POCL asserted that the Performance Standard Assessment (PSA) was proving too
subjective with potentially too much trainer assistance thus allowing trainees to pass
the PSA who would subsequently prove to be unable to handle Horizon in the live
environment. ICL Pathway and POCL have worked closely together to review the
PSA and to arrive at an agreed test to administer on the training courses. The actions
to achieve this are reflected in the timetable.
e Post Training Consolidation
It is recognised by POCL and ICL Pathway that insufficient use is being made of
training mode in the live environment. The parties have worked together to formulate
ideas for promotion of training mode in the live offices. Work on this subject is on-
going and the activities are reflected in the timetable.
e Agreed Training Course Changes
The changes raised by Trevor Rollason of POCL as a result of dry runs of the training
courses have been implemented and all courses are now signed off.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 7
ICL Pathway
Acceptance Incident 218
Resolution Plan
POL00325269
POL00325269
Ref: CR/ACD/218
Version: 0.5
Date: 23/9/99
All of the above areas of activity are reflected in the timetable and all activities
scheduled to be completed have been. All other activities are on schedule.
ACCEPTANCE INCIDENT - 218
CRITICAL SUCCESS FACTORS
The Following table defines the critical success factors (CSFs) which should be
applied to each of the activities to enable the resolution of Acceptance Incident 218. In
essence the CSFs are consistent with those defined for the evaluation of the LT2
Horizon system release.
Measure
Target
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.
Two time periods defined:
peak: Wed 12.00 noon - Thurs 12.00
noon
off-peak: the rest of the week
ICL Pathway to provide details of
calls received at HSH from additional
offices, breaking out calls by
categories, date, FAD code and
associated pinICL number
On average NBSC should not receive
more than 1.2 calls per week from
outlets when performing their first two
balances.
Te?
Overall the-ain-iste.achi
The number of offices unable to
complete the cash account balance
process and produce a cash account
balance.
As with current practice, cash account
balances with explicit reasons for a
discrepancy are still considered to be
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 6 of 7
ICL Pathway
Acceptance Incident 218
Resolution Plan
POL00325269
POL00325269
Ref: CR/ACD/218
Version: 0.5
Date: 23/9/99
valid.
Time taken to produce a stock unit
balance, the office balance and finally
produce a cash account.
It is assumed that the time taken for
balancing excludes any instances
where business related discrepancies
occur, e.g lost vouchers etc.
Ina typical sub-post office the overall
process for producing stock unit
balances, an office balance and the cash
account should be completed within
2.5 hours. In an ECCO office the
process should be completed within
4 Shours.
User generated error reported by TP,
in both CLASS and PIVOT.
Pre Horizon baseline level for same
outlets.
Level of success of Users against the
Performance Standard Assessment
(PSA).
At least 95% success rate.
All support material must mirror the
system e.g. training materials, guides,
operating manuals and Training
Mode.
There should be no inconsistencies (as
reported to the NBSC).
[Mitigation - Where inconsistencies are
identified there should be an agreed
resolution plan.]
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 7 of 7
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Pathway Plan wae: 231909
Document Title: Acceptance Incident 298 — Resolution Plan
Document Type: Acceptance Resolution Plan
Abstract: This document contains ICL Pathway’s updated resolution plan
for Acceptance Incident 298.
Status: Draft
Distribution: Expert:
Peter Copping
ICL Pathwa
Terry Austin
David Hollingsworth
Library
POCL:
John Meagher
Min Burdett
Jeff Austin
Author: JCC Dicks & D.C.Hollingsworth
Comments to: Pathway list
Comments by:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page I of 29
ICL
Pathway
POL00325269
POL00325269
Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Plan Date: 23/9/99
QO Document control
0.1 Document history
Version
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
Date
20/8/99
24/8/99
2/9/99
9/9/99
10/9/99
16/9/99
22/9/99
23/9/99
Reason
Initial draft for comments
Version for the Expert and workshop 26/8
Redrafted as a resolution plan
Material added on longer term incidence rates and defect
prevention for future releases; distributed as a draft at
Acceptance Workshop 9/9/99
Statistics updated to CAP 24; amendments to show statistics
by counter volumes as a result of Acceptance Workshop
9/9/99
Summary & outline forward projections added to Section
5.2.4; additional material incorporated into Section 5.5,
following review with POCL
Section 5.4.4 updated to reflect agreement on monitoring
process during Oct/Nov.
[DN: Partial results for CAP26 have been included in this
draft and should be disregarded. ]
Further updates arising from drafting of Schedule 2 Part A of
the second supplementary agreement
0.2 Approval authorities
Name Position Signature Date
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
T P Austin Development Director
0.3 Associated documents
Reference Vers Title
0.4 Abbreviations
Source
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Page 2 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
0.5 Table of content
1 PURPOSE...
2 SUMMARY...
3. CRITERIA..
4 POCL POSITION...
5 PATHWAY POSITION .....
5.1 PATHWAY WORK PROGRAMME
3.1.1 Short- Medium Term Activities
5.1.2 Medium-Long Term Activities.
5.2 STATISTICS FOR THE PERIOD SINCE 29 JULY
5.2.1 High level analysis. saeeestehbeseeneeontes .
5.2.2 System Load Events & “Unauthorised” Reboots ...
5.2.3 System Incident Metric:
5.2.4 Summary Position (CAP 25) & Future Projectio:
5.3. DETAILED INCIDENT ANALYSIS, CATEGORISATION & RESOLUTION.
5.3.1 Button No Entry Signs.
5.3.2 Suspense Account Prin
5.3.3 Virtual Memory Problem:
5.3.4 Printer Hanging......
5.3.5 Freezing during /afier log-on.
5.3.6 FI Twice during log-on
5.3.7 System Busy Message...
5.3.8 Query Logged-on Users Message
5.3.9 Miscellaneous Freezing / Usage...
5.3.10 Counter Printer problems .
5.3.11 APS Problems
5.3.12 OBCS Problems.
5.3.13 Counter Printer Bu:
5.4 RESOLUTION OF INCIDENT METRICS
5.4.1, Contractual Requirements...
5.4.2. Comparison against Industry Norm:
5.4.3. Acceptance Position...
5.4.4. Resolution Proposal
5.5 IMPROVED DEFECT REMOVAL FOR FUTURE RELEAS!
5.5.1 PINICL Analysis ..
5.5.2 Implications for CSR+ ..
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 29
POL00325269
POL00325269
Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Pathway Plan Version: 0.8
Date: 23/9/99
Purpose
This paper seeks agreed ways forward to resolve the system instability issues.
Summary
Pathway presents for review the relevant statistics for the period since 29 July, with
particular reference to System Load Events; the progress to date at a detailed level;
and the approach to future measurement, which it is proposed will involve POCL.
Criteria
The Criterion cited is 536/1.
“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”.
POCL position
Based upon the minutes of the Acceptance Board Meeting of 18 August 1999, POCL
contended that:
“the proposed rectification plan does not provide an understanding of how the
problems will be resolved by the proposed fixes. It is also unclear when fixes will be
implemented” .
“POCL would need to see the outturn of [the fixes] as this was the only way to
confirm the impact of the changes” .
“evidence from ringarounds suggested the problem could be 50% higher than
reported at the help desk and that there was no clear evidence from Pathway to
confirm or deny this”.
At the Acceptance Workshop on 6" September POCL introduced a proposed metric
of 1 system “lock-up” or “crash” (requiring reboot) per counter PC per annum. This
is based upon the achievement of a 95% reduction in stability incidents reported
against week 19 and is said to be broadly in line with system stability statistics from
ECCO and ALPS.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
5 Pathway position
5.1 Pathway work programme
5.1.1 Short- Medium Term Activities
The ICL Pathway programme of work to stabilise the current level of system
comprises root cause analysis and resolution of system incidents:
e detailed examination of Horizon System Help Desk call records
e direct telephone contact with post offices to more fully understand the detailed
nature of the problem as seen by the users
e reconstruction and analysis of problems within Pathway test systems
¢ testing and automated distribution of fixes as described in the Acceptance Incident
Analysis of 17 August
The details of this work programme are provided in Section 5.3, which gives an
analysis of the various system stability faults by category, along with details of fixes
applied and associated incidents levels pre- and post-fix.
5.1.2 Medium-Long Term Activities
In parallel with this short term activity, a thorough review of the detected faults is
underway to ascertain their nature and to identify what changes may be appropriate to
the ongoing Pathway development and testing approach. Section 5.5 of this document
provides details of the analysis already undertaken in this respect, the initial
conclusions and suggestions for improved defect removal for future releases.
5.2 Statistics for the period since 29 July
5.2.1 High level analysis
The principal measure of systems instability has been the calls made to the Horizon
Systems Help Desk by outlet staff reporting a problem with the functioning of the
system at the outlet.
For a proportion of such calls the incident is resolved by a system unit reboot (a Help
Desk “authorised reboot”). In other cases the Help Desk staff may recommend an
avoidance action that provides a simple workaround to the problem without rebooting
the system unit. In certain cases the Help Desk may also receive a call from an outlet
advising that outlet staff have locally initiated a reboot; such calls are recorded by the
Help Desk and normally provide some additional information relating to the
circumstances of the incident.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
5.2.2 System Load Events & “Unauthorised” Reboots
POCL expressed concern over the potential occurrence at outlets of locally initiated
system unit reboots that had not been reported to the Help Desk. ICL Pathway
subsequently mounted an exercise to extract this information by extracting and
analysing the Windows NT System Event Logs at each outlet. This provides precise
statistics for all System Load Events (SLEs) whatever their cause. By correlating
these load events with reboot instructions issued at the Help Desk it has been possible
to produces metrics for both authorised (via HSH) reboots and unauthorised (via local
office action) reboots. This analysis is continuing on a day by day basis.
Such unauthorised reboots may occur for a variety of reasons, including:
1. in response to a perceived systems malfunction of some kind, where the clerk
does not contact the Help Desk and initiates such action of his own volition
Rv
in response to an environmental incident such as a power cut or through
disconnection of the power supply
we
through failure to leave the machines switched on during periods of
unattended operation (e.g. overnight or weekends) with corresponding reboots
when operation restarts, e.g. on a Monday morning
Since the circumstances relating to such incidents are unknown, the incidents cannot
be directly attributed as systems stability incidents and must be excluded from the
detailed analysis in the following section. Both POCL and ICL Pathway are working
to reduce the incidence of such reboots to the core unavoidable events (category 2)
through improved user education and discipline.
5.2.3 System Incident Metrics
The high level analysis of system instability incidents thus includes three categories:
e Authorised reboots (correlated with Help Desk instructions)
e Unauthorised reboots
e Total Help Desk system incidents (including authorised reboots and other calls
closed via avoidance actions)
Summary totals for the Cash Account Periods 19-26 are shown in the following charts
(Note that the total for CAP 26 is provisional and the final figure may be subject to
minor variation once all incidents from the 22" September have been fully analysed.)
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 7 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
600 (PP _Reconciled Totals
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
HSH System Incident Calls gy HSH Authorised Reboots
(Unauthorised Reboots
Note that (i) CAP23 included a Bank Holiday and a planned (authorised) reboot of all
counters, by request to outlets; (ii) “ unauthorised” reboots have increased in CAP24
and CAP 25 due to the installation of new outlets showing up in the total. (This trend
is expected to continue.)
A more detailed scheme of incident analysis was instigated by Pathway from CAP23,
to facilitate focused incident analysis and resolution. This places emphasis on that
class of incidents which requires a system reboot. From week 24 an individual
reconciliation of incidents totals between Pathway and POCL has been occurring with
inclusion of a category for “ disputed” items which involve an HSH call but not a
reboot. For week 23 a retrospective adjustment has been added to the weekly total to
support comparison between the two weeks. However, direct comparison with earlier
weeks is not valid since the totals were not reconciled in this way.
The following chart shows the same data, with the planned reboot data removed
(31/8/99), CAP 23 adjusted for the bank holiday in terms of incident rate per day, and
the numbers for each week adjusted for the volume of counters installed. This shows
the incidence of the same measurements expressed as a rate of occurrence per counter
per week.
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
I HSH System incident Calls g HSH Authorised Reboots 4 Unauthorised Reboots
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 8 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
From the above analysis it can be seen that there is a reducing trend, particularly
towards the end of the current period. The chart following shows the incidence of
HSH calls per counter per week relating to systems incidents. The level of HSH
(authorised) reboots is now at the level of approximately 0.5 per month per counter,
below the first Pathway target (1.0) and the proposed threshold for classification as
medium severity.
The increase in incidents in CAP 23 is attributable to the introduction of the “System
Busy” indicator and a one-off fault introduced into OBCS which both resulted in a
significant number of new calls.
The following chart shows the HSH system incident calls separated into those
requiring a system reboot and those dealt with by advice or other action.
03
0.25
02
0 Pe : J a
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
HSH Authorised Reboots jg HSH Advice or Other Action
A number of analysed HSH calls have not been resolved between ICL Pathway and
POCL and are listed as disputed incidents. Such calls include simple workarounds to
known (predictable and stable) operational problems, and a few other incident types,
such as handling of printer jams and related printing conditions, which have not been
accepted by ICL Pathway as indicative of a system stability problem. The following
chart includes the above totals with disputed items shown as a separate category.
The principal incident in the disputed category is that of button locking (see section
5.3.1). Section 5.4.4 makes it clear that for the period of monitoring, those button
locking incidents that result in reboots or authorised workarounds will be counted.
HSH calls other than those, which result in reboots or workarounds due to button
locking, will not be monitored after CAP26.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 9 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
0.3
02
0.15
04
0.05
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
HSH Authorised Reboots gj HSH Advice or Other Action Disputed Items
5.2.4 Summary Position (CAP 25) & Future Projections
The incident types have been grouped into 13 categories and a detailed analysis is
provided in section 5.3.
Problems Eliminated
The following incident types have been eliminated with no noted recurrences:
e Back office printer hanging on final cash account production (Section 5.3.4)
e The “one-off’ OBCS problem (Section 5.3.12)
¢ Querying logged-on users problem (Section 5.3.8)
e Improvements in performance of the suspense account print (Section 5.3.2)
Problems Significantly Improved
The following incident types have seen significant improvement but have not been
totally eliminated
e Button locking problems (Section 5.3.1) have been reduced to a small number of
incidents, which can be avoided by workaround.
e Virtual memory and other error messages (Section 5.2.3)
e APS application problems - associated with printing and recovery (Section 5.3.11)
Key Outstanding Problems
The following problem areas have seen only minor improvements and are the
principal subjects of current analysis and fixes:
e Freezes during / after log-on and occasionally in other circumstances (Sections
5.3.5, 5.3.6 & 5.3.9)
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 10 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref. CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
e Counter printing issues (Sections 5.3.10 & 5.3.13)
e System Busy incidents (Section 5.3.7), although these are being re-categorised
into the underlying problems
The history of the main types of incident is shown in the chart below, shown on the
same scale as individual incident rates in section 5.3 (incidents occurring per counter
per annum). This indicates the history of when significant systems problems have
been experienced and eliminated.
16
14 g Others
12 System Busy
10 Application Problems
8 Button Lockung
6 Freezing
4 Back Office Printing
2 E a Counter printing
i}
go gh gh GP gh GP gh
This chart shows that the three significant incident categories as of CAPS 24-26 are
counter printing, system freeze conditions and system busy. (It is also apparent that
various AP problems in CAPs 19-23 were related to counter printer incidents, giving
rise to an understatement of such printer conditions during these weeks.)
Future Incident Rates
These are based upon an assessment of the current known problem areas with fixes
either in preparation or distribution, plus an expectation of smaller “ second phase”
improvements in the longer term to tackle residual incident types in significant
categories.
The main short term fixes assessed include:
1. The “Double F1” fix to relieve system freezes during log-on (week 25) plus
diagnostic to provide more details of other freeze conditions (should reduce 40-
50% of freeze conditions)
N
The fix to the Riposte Peripheral Server and related incidents involving 2" page
GIRO reports
Elimination of print contention by locking “Previous” during print format
operations
we
(2 & 3 should eliminate up to 50% of counter printing incidents and are expected in
CAP 26/27)
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 11 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref. CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
4. Alleviation of button locking problems when an EPOSS receipt is printed after an
APS receipt (should avoid workarounds for a substantial subset of incidents) —
issued in CAP 25
5. A revised version of System Busy based upon Riposte Desktop processor time
rather than total system time (this should eliminate some instances where system
busy is active because of background tasks rather than mainstream counter
operations) — issued in CAP 25
The future projections are separated into near term values for CAP 26 and 27, based
upon extrapolation of the HSH authorised reboot levels, and a set of medium term
values based upon system incident rates. All projections were made during CAP 25
based upon the actual field data obtained up to and including CAP 24. The
(provisional) actual figures for CAP 25 are also shown.
Near Term Projections
Projected Reboot Incidence
CAP CAP CAP CAP CAP CAP CAP CAP
24 25 26 27 28 29 30 31
Medium Term Projections
A similar chart for systems incident rate and an extrapolation for actual HSH call
volumes are shown below.
Projected Incident Rate (Per Counter Per Annum)
s
BOE
CAP CAP CAP CAP CAP CAP CAP CAP.
24 25 26 27 28 29 30 31 32 33 34
The single most significant drop is associated with counter printing fixes expected for
issue during CAP 26/7 and showing in the projection for CAP 28.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 12 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
Taking account of the projected increase in counter population this leads to the
following outline profile of incidents at the HSH.
Projected Incident Volumes (Per Week)
350,
300
250
200
150
100
50
CAP CAP CAP CAP CAP CAP CAP CAP CAP CAP CAP
24 25 26 27 28 29 30 31 32 33 34
The projected incident rate remains essentially stable over the near term with
reductions matched by increased counter volume; during October and November there
is a steady increase as the rate of counter build up exceeds incident reduction rate.
5.3 Detailed Incident Analysis, Categorisation & Resolution
To facilitate analysis and resolution, system incidents have been filtered into
individual categories, each typically associated with one particular problem area of
system operation. To provide confidence in the improving stability of the system,
incidents are recorded as daily totals within each category, to allow correlation against
the dates at which particular fixes were issued to resolve specific problems. This
analysis includes all system stability incidents whether resolved by a system reboot or
by procedural workaround.
As detailed investigation of incidents proceeds, certain faults may be grouped together
into a new category. Initially 12 categories were identified. At week CAP24 a number
of system busy incidents (category 7) have been categorised differently as the detail of
the fault has been understood. Certain incidents previously recorded under “ system
busy” have been identified as hang during/after log-on (category 5) and a specific
problem associated with the counter printer during busy conditions has been created
(category 13).
From version 0.5 of this document, the incident count has been based against the
number of counters installed and quoted as average incidents per counter per annum.
5.3.1 Button No Entry Signs
From time to time under normal system operation Horizon buttons are “locked” to
prevent user entry to the particular function at that point in the menu navigation. Such
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 13 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
locked buttons are represented to the user by a “no entry” sign across the button.
Examples of legitimate usage of locked functions include:
e prevention of more than one user selecting cash account functions or producing
certain types of daily printed report
e prevention of logout or entry to training mode when a suspended session exists
At LT2 substantial changes were made to button locking particularly to prevent access
to conflicting functions during cash account and printing functions. The logic
associated with button locking is complex and typically requires combinatorial
analysis of multiple conditions.
Fixes were issued to correct the majority of incidents recorded within this category, by
correcting the complex logic associated with button locking. A minor residual usage
problem has been identified, which results in button locking if the printer goes offline
immediately following a SU balance report. This problem has a simple workaround
and does not require a reboot.
The history of button locking incidents is shown below.
Button No Entry Signs
45
4 WP.5138 & 5298 - 15/8—
35
WP 5406-24}
4 : 3 o_m___om_ {2a
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
Note that reported incidents tend to be higher on cash account days because of a
higher incidence of legitimate button locking associated with cash account and office
printing functions. A number of disputed items (incidents which do not require
reboot) are excluded from week 23/24. With these included the average incident rate
is running at approximately 1 — 1.5 per counter p.a.
5.3.2 Suspense Account Print
The suspense account was taking an excessive time to print under certain
circumstances, giving the appearance of a system hang. A fix to improve the
performance was issued in two parts. The history of such incidents is provided below.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 14 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
Suspense A/C Print Hang
0.35
0.3
WP 5296 = oq
at
0.25
02
0.15
04
0.05
5.3.3 Virtual Memory Problems
Two problems have been observed which result in progressive memory leakage. (In
these circumstances application routines are obtaining virtual memory from Windows
but not freeing it correctly after use, leading to eventual virtual memory exhaustion.)
The reported symptoms include very slow system operation, virtual memory messages
being displayed and, occasionally a Windows shutdown and reboot. The principal
problem was memory leakage associated with the Print Monitor routine, which
resulted in a substantial loss of virtual memory during print operations. This was fixed
in WP 5408. A further residual, but relatively minor, problem associated with the cash
account reprint function has been diagnosed. A fix (lower priority) will be issued for
this in the future.
Virtual Memory Incidents (including Slow M/C & Dr
Watson)
14
1.2
1
0s :
06 —— ¥ a
04 a a -
* f=
5.3.4 Printer Hanging
Several problems were detected which result in back office printer hang-ups under
various specific circumstances. A fix for one class of problem, associated with
memory leakage, has already been distributed as part of WP 5408. This has reduced
the average incidence of such hang-ups. A second problem associated with printing
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 15 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
the 2 final copies of the cash account was identified, using results obtained from a
diagnostic fix distributed to the live estate. The fix to the cash account print routine
was issued on the 7" September. There have been no occurrences during the following
two weeks (CAPs 24 & 25)
Cash AIC Print Hang
o Lio
CAPI9 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
The residual count shown under CAP 24 relates to incidents from Thursday 2"
September.
5.3.5 Freezing during /after log-on
A number of incidents were observed in which the system froze after user log-on to
Riposte. On detailed investigation these were all connected with the Riposte (35 day)
message archiving procedure. After log-on various Riposte checks are called to trace
message sequences for integrity and (potential) recovery requirements. It was found
that certain of these routines were attempting to check message sequences which lay
beyond the message archiving window, resulting in system lock-up when the
messages could not be accessed. Three fixes were issued covering APS recovery
routines and Stock Unit checking.
Freezing during/after Log-on
18
wef _ rar
14
1.2
0.8
0.6
04
02
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
bas
An occasional occurrence of freezing during log-in (prior to entering Riposte) has also
been detected and this residual error is under investigation. Some instances of System
Busy incidents have been discovered to relate to freezing after log-in, which accounts
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 16 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
for the significantly higher incident rate in CAP 24. Note that the “ Double F1”
problem (immediately following section) is also related and has had a significant
effect on incidents during week 25.
5.3.6 F1 Twice during log-on
This was a specific condition associated with incorrect handling of double keystroke
“PI” during log-on (to navigate directly to “ Serve Customer” ) which could result in
a system hang. A fix was issued for this (WP5406), which left a residual problem with
certain OBCS book operations. A re-implemented fix was issued to cure this - see
Section 5.3.12. A second fix to eliminate a small residual occurrence of the
“FI” condition is under test at the time of writing and will be issued to the live estate
during week commencing 13" September.
Freeze following F1 twice during Log-on
0.14
0.12
04
0.08
0.06
0.04
0.02
oO ss) be Bes :
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
5.3.7 System Busy Message
This was introduced following discussion (via CR & Pathway CP2134) to provide
visible indication to the user when the system is busy, particularly during longer,
complex operations such as processing the cash account. This was distributed in WP
5407. The introduction of this message has itself resulted in a number of Help Desk
calls, which have also been tracked and analysed. An improved version of the busy
monitor routine was distributed (week commencing 6" September); this monitors only
resource usage associated with the Riposte desktop and invoked applications. (The
original utility monitored the total processor usage and could display the hourglass
when background routines such as NT or Tivoli functions were consuming resource.)
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 17 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution \ Ref: cRACD 298
ersion: 0.
Pathway Plan Dave. 23/9/99
System Busy Message (exc printer/log-on)
3
25 WP 5446-2678
2 {
15
1
05
0 fis]
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
A minor problem has been detected with the operation of the Busy Monitor, in that
after a few seconds it can partially obliterate a system message displayed on the
screen if there is a printer problem when printing a Giro transaction. (This can occur
when EPOSS is cycling awaiting the user response before continuing.) The touch
panel is not disabled under these circumstances and the Help Desk will advise users to
complete the response to the printer prompt, thereby allowing normal operation to
continue without reboot. A “fix” to provide reworking of the Giro printer dialogue
will be issued in due course. From CAP 24 specific problems associated with printer
busy and log-on freezes have been separated into their own categories.
Note that it the clerk may legitimately return from a screen to a previous, having set
off a print or transaction log query, and then undertake a second or third intensive
transaction. A number of occurrences of the system busy condition are believed to
result from such clerk initiated sequences. A block on the “previous” button is being
investigated to preclude such behaviour.
5.3.8 Query Logged-on Users Message
This was a specific problem that occurred during various operations when a user
incorrectly received a message querying details of logged-on users. This was fixed in
WP 5406, which has eliminated the problem.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 18 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref oes
ersion: 0.
Pathway Plan Date: 23/9/99
Query Logged on Users Message
07
06 a =
05
0.4 a
03
02 —
O41
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
5.3.9 Miscellaneous Freezing / Usage
There have been a few occurrences of miscellaneous screen freezing during usage,
mostly within Stock Unit declaration and balancing operations. A few reported
occurrences were associated with virtual memory problems and are resolved with the
fix identified in section 5.3.3. Several occurrences resulted from attempts to access
message sequences beyond the 35-day archiving period and other occurrences are
associated with multiple button pressing.
Miscellaneous freezing not in other categories
25
0 as : iS
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
Diagnosis continues on these and appropriate fixes will be issued in due course.
5.3.10 Counter Printer problems
Two specific problems have been identified with counter printer operations. One was
associated with the failure to print a second APS receipt, resulting in a subsequent
system hang; this was fixed as part of WP 5406.
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page 19 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
Counter Printer Problems exc. System busy
4
35 -
3 [WP 5406 - 247
25 E
2 -
15
1
05 a
0 oS
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
A second problem, associated with incorrect handling of printer failure conditions
within the Giro transaction printing routine, has been identified and work is
progressing on detailed diagnosis and resolution.
5.3.11 APS Problems
A number of APS application problems associated with receipt issue were identified
(including the second receipt problem identified above).
In certain circumstances a failure in the APS receipting routines could leave buttons
locked and a transaction on the stack. This was also fixed as part of WP 5406. A
further fix was issued as part of the system freezing work (WP 5208) to specifically
identify to the user the presence of APS recovery operations since this could give the
appearance of a system freeze.
APS issues
25
2
15 .
1 -
0.6 I
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
As can be seen, the overwhelming majority of APS related problems have now been
eliminated.
5.3.12 OBCS Problems
The “Double F1” fix (see section 5.3.6) which resulted in problems with jumping
screens during OBCS transactions (rather than normal screen navigation) introduced a
further problem. This showed up on Help Desk call analysis as a significant problem
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 20 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref! CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
following the “Double F1” fix. The majority of the problems were addressed by
WP5490; a fix relating to one further circumstance was included in WP 5405.
OBCS problems
3.5
25 =
2
15 a a —
1
05
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
There have been no further recurrences of the problem.
5.3.13 Counter Printer Busy Problems
One particular class of problem shown up from the “system busy” indicator relates to
a continuing counter printer busy condition returned to the application These have
now been classified as a particular incident type in their own right (from CAP 24).
Counter Printer Busy
0.3
0.25
0.2
0.15 a
O41
0.05
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
A fix for the Riposte Peripheral Server is currently under test and is expected to be
issued to the live estate during CAP 26.
5.4 Resolution of Incident Metrics
Pathway notes the POCL proposed metric of 1 system “lock-up” or “crash”
(requiring reboot) per counter PC per annum.
The Pathway position is that this is an unrealistic and unwarranted requirement to be
placed on the Pathway Solution.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 21 of 29
POL00325269
POL00325269
ICL Pathway Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Plan Version: 0.8
Date: 23/9/99
5.4.1. Contractual Requirements
There is no contracted Service Level which Pathway is required to meet relating to
lost time associated with OPS system stability incidents. (Lost time at the counter may
contribute to an increase in the volume of fall-back transactions which may fall within
the service reporting requirements of individual services - EPOSS, APS and OBCS.)
5.4.2. Comparison against Industry Norms
The POCL proposed level is unrealistically high when compared against normal
operational usage of complex distributed systems based upon Windows NT. Typical
industry norms of I event per month are reported. It is noted by both parties that a
periodic planned “preventative” reboot, outside prime usage time, may be a sensible
measure to help reduce the incidence of unplanned reboots.
5.4.3. Acceptance Position
AI 298 was raised against Requirement 536, on the basis of Live Trial usage
experience.
The planned acceptance testing associated with this Requirement was fully completed
with no outstanding issues. This comprised a combination of detailed technical test
and a review of the technical specifications of the relevant equipment.
ICL Pathway has accepted that there have been some incidents at outlets, which have
affected certain aspects of system operation. As detailed within Sections 5.2 and 5.3
there has already been a significant reduction in such incidents from the earlier levels
in June and July when this AI was raised. Pathway set an internal target of one
(authorised) reboot per month per counter and proposes that achievement of this level
reduces the incident to a medium severity. The levels of lost time associated with the
current incident rate fall well within this yardstick.
5.4.4. Resolution Proposal
POCL has indicated a desire to associate this incident with a further metric which
would represent an “acceptable” level of operation with respect to the occurrence of
system incidents prior to the full outlet rollout.
ICL Pathway will use all reasonable endeavours to reduce the incidence of
interruptions to normal counter operations resulting from the use of the OPS platform
and the Riposte desktop functions. Pathway has set a longer term (6 months) internal
target of 1 Help Desk authorised reboot incident per counter per 4 months measured
over the actual population of rolled out counters. Workarounds taking longer than
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 22 of 29
POL00325269
POL00325269
ICL Pathway Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Plan Version: 0.8
Date: 23/9/99
four minutes will counts as reboots. This represents a fourfold improvement beyond
the initial target.
Monitoring during Oct/Nov
The success criteria in relation to this AI to be evaluated in November in relation to
the continuation of national roll-out in January 2000 should have the following
characteristics:
e The number of outlets installed within the live estate at 1 October, providing this
number is at least 750, or if less than 750, the number at the end of the week
during which 750 outlets is achieved.
e Incidents to be quantified in “units” where:
e Help Desk authorised re-boots and Office Snapshot Print Previews to count as
one unit;
e Other workarounds to remove invalid no-entry signs to count as half a unit;
e New workarounds to remove the need for re-boots (such workarounds to take
less than 10% of the combined reboot and recovery time) to count as a half
unit (those exceeding 10% to count as one unit).
e The rate of occurrence measured over the 4-week period to mid-November 1999
(CAP 31-34) should average no more than one unit per counter position per 3
months.
In addition, ICL Pathway will be entitled to continue the good business practice of
planned reboots outside working hours not to exceed one per month per counter
position.
Ongoing improvement and longer term
It is important to recognise that ICL Pathway is strongly motivated to reduce such
incidents as they directly affect its own costs through staffing levels required at the
Help Desk. The Pathway Help Desk model and projected staffing levels are consistent
with this approach. For ICL Pathway this equates to a requirement to deal with up to
700 such calls per week as the outlet population increases over the next six months
(and the incident rate falls). Clearly Pathway will be strongly motivated to seek any
further possible reductions in incidents to reduce the corresponding call rate applied to
a full estate.
For POCL the achievement of the ongoing target of 1 reboot per 4 months would
result in a predicted loss of service of the order of 6.25 minutes per counter per month.
For a typical outlet operational period of 42 hours per week this equates to a loss of
service of < 0.06% per counter. In reality lost customer service time is likely to be
significantly less than this since the above calculation:
(i) makes no allowance for the possibility of directing customers to other counters
during an incident
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 23 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
(ii) makes no allowance for that proportion of incidents which occur during back
office processing and have no direct impact on customer service.
The incident analysis which has been jointly undertaken to date and the improved
level of understanding of system usage within the live outlets both suggest that the
target will be met within the projected 6 months. The most recent rate of authorised
reboot incidents is approaching half the initial target level, leaving a further required
halving to reach the final target. Pathway has undertaken analysis of several
outstanding incidents and diagnosed the detail of the problem. Software fixes will be
progressively released following regression testing which will see a further reduction
on the current incident rates towards the target. Hence the progression towards the
target is already substantially underpinned by known, diagnosed problems which are
awaiting fix issue.
5.5 Improved Defect Removal for Future Releases
The level of testing conducted on the Pathway solution has by any standard been
exceptionally high (over 100 dedicated testers, a staggering array of test
environments, at a cost of 10s of £Millions). The large, complex and distributed
nature of the system demands a sophisticated multi-layered approach to testing and
integration. The strategy was developed and agreed in conjunction with the sponsor
organisations at the outset, and was independently assessed during the treasury review
as being ‘leading edge’. It has been maintained in the light of experience of Release 1,
and is currently again under review in respect of Release 2 (CSR). Of particular
importance here is the experience of the Live Trial period, and the lessons that may be
learned to further improve the Defect Removal rate for future releases, and so reduce
the number of incidents encountered in the Live Estate.
5.5.1 PINICL Analysis
A review is underway of all the PinICL fixes applied across the whole of the Counter
systems for the Live Trial Period. This period was split into 3, known as LT1, LT2,
and CSR. Initial findings, measuring up to 31/08/99, indicate that a total of 133
PinICLs were involved. Of these, 2 were data related (including 1 on POCL Reference
Data), 1 was build related, and 2 were purely administrational to introduce the
decommissioning of BPS, leaving 128 software faults to be considered in all. (It may
be of interest to note here that about 30 of these were for BPS, although this does not
have a material bearing on the analysis.)
Of these 128 faults, just 50 were actually raised from activity in the Live Trial. The
other 78 were all in fact raised during the course of testing. (Most of these were found
long before the Live Trial in Pathway’s System Test and Integration Test stages or in
the MOT/E2E test stages immediately before the Live Trial. These were the subjects
of agreed deferral via the KPR process, to allow for their controlled introduction
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 24 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref. CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
during the course of the Live Trial, to avoid destabilisation. A small number were
raised after the KPR, as a result of Pathway’s ongoing regression testing)
The records for these PinICLs have been analysed to determine the nature of the
defects concerned. As a result they have been categorised accordingly, to help assess
how best the Development Lifecycle, and in particular the testing and integration
approach, may be revised to best detect such defects earlier, and so better protect the
Live service. A large number of low level classifications were used, which can be
summarised into the following high level categories:
1, Usability/Robustness:
MMI, Menus, Button locking, No-Entry signs, Double key stokes, Cosmetics,
Enforcement of correct practice, Operational usability, Correct error handling, etc.
2. Stability/Performance:
Screen freezes, Printer hangs, Memory leaks, Blue screens, NT messages,
Archiving anomalies, Function performance.
3. Application Logic:
Plain software bugs.
Initial findings indicate that the 128 fixes applied to during the Live Trial (78 faults
found in Testing and 50 faults found in Live) can be categorised as follows:
Category Testing Faults Live Faults
Usability/Robustness 38 38
Stability/Performance 14 5
Application Logic 26 7
(To set these figures in context, overall testing has trapped several thousand defects,
commensurate with the great size and complexity of this system.)
The following conclusions can be drawn:
e The overall approach has been extremely successful in reducing the exposure of
the Live Estate to a very small residue of defects remaining in the system (which
the industry recognises can never be entirely eliminated, although there is
always room to improve).
e The incidence of defects discovered is demonstrably reducing over time,
indicating a steady improvement in overall system stability.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 25 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
e There is clear evidence that the majority of defects in the Usability/Robustness
category have been trapped during testing, despite this being a notoriously
difficult and expensive problem domain to address exhaustively through testing.
e Nonetheless, the majority of defects escaping capture during test are in the
category Usability/Robustness, suggesting that there really is no substitute for
genuine Live exposure to flush out these types of defect (as per generally
accepted industry wisdom). It also suggests that this is the main area to target for
future improvement, offering more scope. Further to this, the report from the
EPOSS Defensive Test exercise was encouraging. It indicates that such short
focussed test activities, concentrating on particular aspects of system usage, can
have considerable success in removing defects both of the Usability/Robustness
and Stability/Performance categories.
(The EPOSS Defensive Test exercise was an additional test initiative introduced
by Pathway to satisfy test objectives relating to Usability/Robustness, which it
was recognised had not been fully met by the Model Office exercise and the
EPOSS Usability Trial.)
e Testing has eradicated all but a very few remaining Stability/Performance
defects, albeit that these can impart a disproportionate effect on the Live Estate,
further suggesting the importance of a Live Trial or equivalent period, where the
impact on the business can be limited and controlled. The fact that a significant
number of such defects were still being discovered in these late testing stages
indicates that there is potential for improvement here also. It suggests that a
more detailed analysis of the precise circumstances of these defects should be
conducted to determine any common factors and to assess whether any benefit is
to be had from specific testing actions earlier in the lifecycle.
e Testing has eradicated all but a very few remaining Application Logic defects.
Little scope for improvement in this area, other than the perpetual goal of earlier
discovery.
A further observation arising from the analysis would be that many of the PinICLs
arising in the Live Trial system had in fact been the subjects of earlier PinICLs raised
during the course of Testing. This is a common phenomenon. Typically it comes
about because for certain classes of defect (particularly where it is related to timing, or
multiple streams of activity in combination) the symptoms revealing the defect can
not easily be reproduced until the underlying defect is properly understood. Because it
cannot be reproduced the underlying defect can not be properly diagnosed. The faults
are then often put down to some flaw in the test environment, or the wrong code
versions being used, and the PinICL is closed ‘unable to reproduce’. There is no easy
remedy.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 26 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
5.5.2 Implications for CSR+
A full review of the testing conducted for Release 2 (CSR) has already been
conducted and a proposal document has been drafted “ Revisions to the Testing &
Integration Approach for Pathway Release CSR+”. Based on the findings above ICL
Pathway and POCL will jointly consider the following proposals, and as agreed
include them within a definitive version of that document. This review will take
place by 30/10/99 and the definitive version of that document will be published by
24/11/99 and brought into effect from this date
a) Analyse the precise circumstances of the defects in the Stability/Performance
category. Identify any common factors.
b) Analyse the precise circumstances of the defects in the Usability/Robustness
category. Identify any common factors.
c) From (a) and (b) above, establish any potential test points for existing testing
stages, and, as reasonably necessary, extend their respective objectives/review-
checklists accordingly. (Include Unit Test, System Test, and Conformance Test.)
d) As reasonably necessary, extend Code Review checklists to cover the specifics
from (a) & (b) above, with particular emphasis on the handling of exception
conditions.
e) Adopt the principles of the EPOSS Defensive Test exercise for wider application,
and in particular to mount earlier exercises specifically targeting those attributes
identified in (a) and (b) above. It is important that such test activities include the
involvement of design-aware ‘experts’ having intimate knowledge of system
areas subject to test and capable of targeting potential areas of weakness.
Involvement of Users should also be considered to address usability related
aspects.
f) Work with POCL in determining appropriate and agreeable alternative(s) to the
Live Trial for future releases, to allow each new product to be exposed to
substantial Live use, but with limited business impact, for an appropriate period
of time prior to general (national) release.
It should be noted that CSR+ has already benefited from the revisions included in the
Testing Strategy and will, in due course, from the additions listed above. A lifecycle-
wide review was also conducted earlier in the year, which resulted in a major
reorganisation of the Systems and Programmes Directorates into the new
Development Directorate. Amongst the initiatives introduced at that time were many
which addressed lessons learned from earlier releases to improve the Design and
Development stages for CSR+ and beyond. Of particular relevance here are:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 27 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution bia oe fs
ersion: F
Pathway Plan Date: 23/9/99
a) The formation of Delivery Units, focussing on particular Business and
Infrastructure areas, made up of mixed discipline teams combining Design,
Development, Unit Test, and System Test, and so promoting higher product
quality levels and greater lifecycle awareness. As each Delivery Unit spans all the
platforms supporting the end to end business applications within their respective
areas, this will also help to address the risks previously associated with cross-
paradigm boundaries.
b) The formation of the Technical Design Authority, providing central support to
the Delivery Units, with particular responsibility to oversee the end to end design
and ensure the overall technical integrity of the solution as a whole. One activity
currently under way is the systematic retrospective reviews of the end to end
Designs across the whole solution for CSR+. It should be noted here that these
reviews are not restricted to targeted reviews of the changes at CSR+ but also
encompass those areas of CSR+ inherited from CSR. (For example, it is planned
to review the EPOSS, TPS and RDMC/RDDS systems on an end to end basis,
not just the minor changes made in these areas at CSR+.) Pathway will also
consider seeking the involvement in these reviews of other expert areas within
ICL, external to Pathway, to bring an independent view for certain critical areas.
c) General improvements in the areas of Design Review, Code review, Module Test
Review and Link Test Review.
d) Strengthening of Product Acceptance Test (on entry to Pathway) for 3“ Party
developments.
e) Closer working relationship between the Delivery Units and the Technical
Integration area to promote rapid environment stabilisation.
Pathway already has in train a set of initiatives to improve the defensive measures
deployed within the system in key risk areas. Much has already been done to
introduce interlocks within the counter applications to preserve and protect the serial
dependencies inherent in the VB runtime environment. This in large measure has
eliminated the specific “double entry’ and parallel process ‘hanging’ issues underlying
many of the Usability/Robustness and Stability/Performance problems. The future
strategic goal here is the gradual introduction of more generic defensive measures,
including a full cross-phase locking mechanism.
Following on from the recent investigations into residual memory problems under
certain complex scenarios, Pathway has decided to deploy the BUSY.EXE toolset
more widely in testing for CSR+, using it in a pre-emptive fashion rather than purely
as a debug tool.
ICL Pathway believes that introducing further changes to the Design and
Development stages (other than ensuring that good practice is maintained) would
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 28 of 29
POL00325269
POL00325269
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
Pathway Plan Date: 23/9/99
result in only a marginal reduction of the defects in question. The majority of the
CSR+ functionality has now entered Link Test or System Test, so it would be sensible
at this stage to focus in these and later stages of the lifecycle.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 29 of 29
ICL Pathway
DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref:
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
COMMERCIAL IN CONFIDENCE
POL00325269
POL00325269
CR/SPE/007
Version: 0.3
Date: 7/09/99
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Contributors:
Reviewed By:
Comments By:
Comments To:
Distribution:
Development Of Manual Describing Use Of OPS, TMS and
EPOSS APIs Within ICL Pathway
Specification
N/A
This document describes the content and development timescale for
the production of the “ICL Pathway Generalised API for
OPS/TMS”
Draft
Tony Hayward
Tony Hayward
Janet Dore
John Dicks
David Hollingsworth
Dick Long
Document Author
ICL Pathway Library
John Dicks
Dick Long
Janet Dore
POCL
© 1999 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 1 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7/09/99
0.0 Document Control
0.1 Document History
Version No. I Date Reason for Issue Associated
: CP/PinICL No./
Acceptance
: : Incident
0.1 23/8/99 Draft — for peer review AI314
0.2 1/9/99 Revisions in response to comments I AI 314
received from POCL 31/8/99
0.3 7/9/99 Revisions agreed at Acceptance Workshop I AI 314
held on 2/9/99 also review comments from
J Folkes 7/9/99
0.2 Approval Authorities
Name Position __I Signature Date
John Dicks Director — Customer
Requirements
Terry Austin Director -
Development
0.3 Associated Documents
Reference Version Date Title Source
Release 17 On-Line Standards: I ICL Pathway
Processes — Document I On-Line
Management Standards
TD/ARC/029 0.2 11/5/99 I TMS Architecture I ICL Pathway
Specification
TD/ARC/030 0.2 21/5/99 I OPS Architecture I ICL Pathway
Specification
SD/STD/001 2.0 3/8/99 Horizon OPS Style Guide ICL Pathway
SD/DES/005 6.0 6/7/99 Horizon OPS Reports and I ICL Pathway
Receipts
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 2 of 12
Last Printed: 23/09/99
ICL Pathway
POL00325269
POL00325269
DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7/09/99
0.4 Abbreviations/Definitions
Abbreviation Definition
AI Acceptance Incident
API Application Program Interface
EPOS Electronic Point Of Sale
EPOSS EPOS Service
NDA Non Disclosure Agreement
OPS Office Platform Service
PPD Processes and Procedures Document
TMS Transaction Management Service
0.5 Changes in this Version
Version Changes
0.1 None — this is the initial draft
0.2 Revisions incorporating comments received from POCL 31/8/99. This
includes new sections on Agent Interfaces and System Management
0.3 Document commits to the Pathway specific APIs being defined as required
for the development process; a list to be given of those APIs the use of
which are ‘prohibited’ within the Pathway environment, the addition of an
appendix containing technical details of Systems Management and Key
Management that would be subject to an NDA, and a new section on
Standards. Changes following review comments from J Folkes 7/9/99.
0.6 Changes Expected
Changes
None
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 3 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE, Date: 7109/99
0.7 Table of Contents
1
2
3
4 Content of ICL Pathway Generalised API for OPS/TMS ........cecseesesteeeeeneeteeees 7
4.1 Introduction
4.2 Context......
4.4.3 Stock Unit Management
444 Reporting.
4.4.5 Balancing
4.5 Application Functions
4.5.1 Architecture.
4.5.2 Peripheral Server Interfaces...
4.5.3 Retail Broker Interfaces ....
4.5.4 Desktop Interfaces
4.5.5 Riposte Functions
4.5.5.1 Messaging...
4.5.5.2 Persistent Objects
4.5.5.3 Parsing Functions
4.6 Agent Interfaces
4.6.1 Bulk Agent
4.6.2 Interactive Agents
4.6.3 Enquiry Agents
4.7 Other Functions
4.7.1 Administration
4.7.2 Security
4.7.3. Availability.
4.7.4 Usability
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 4 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: Ti09/99
4.7.5 Performance
4.7.6 Resilience
4.8 Standards
4.8.1 Naming Standards
4.9 Systems Management
4.9.1 POCL Reference Data.
4.9.2 Event Reporting
4.9.3 Software Packaging.
5 Development Timetable
(A) Appendix - Systems Management and Key Management
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 5 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7/09/99
1 Introduction
This defines the content and production plan for the document:
“ICL Pathway Generalised API for OPS/TMS”
This document is for internal Pathway use by application developers.
It is also to be supplied under the Contract (in compliance with Requirements R469,
R470 and R869(part)) to POCL for the purpose of enabling POCL to procure
applications to run on the Service Infrastructure (i.e. interfacing with OPS and TMS).
As such it will be provided to Third Parties.
The OPS Architecture Specification describes the architecture for counter applications
operating within the OPS/TMS framework, and describes the interaction of counter
applications with OPS and TMS. The document expands on the architecture set out in
the OPS Architecture Specification.
2 Scope
The document is intended for application developers within ICL Pathway or Third
Parties. The purpose of the document is to enable developers to understand the
architecture employed and the facilities available within the ICL Pathway solution,
utilising OPS, TMS and EPOSS. The document is intended to provide developers
with sufficient details to plan the development of new applications operating in this
environment. The developers may be ICL Pathway staff, POCL staff or Third Parties.
The document will contain definitions of those Pathway specific APIs essential to
utilising OPS, TMS and EPOSS.
In the context of the Contract, it is available to POCL to enable the procurement
process. Any supplier of Riposte based applications must obtain a development
licence from Escher, who would supply the reference manuals for the Escher specific
APIs:
Escher Group Ltd.
101 Main Street
Cambridge
Massachusetts
USA
3 Document Standards
ICL Pathway shall produce the document in accordance with the ICL Pathway On-
Line Standards for document production. In essence, the document shall conform to a
standard template, be written in Microsoft Word and shall be subject to a document
review cycle, with comments and responses being formally recorded.
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE, Page: 6 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7/09/99
A draft of the document shall be produced and reviewed within ICL Pathway
according to the ICL Pathway Document Review Process. A baseline version
incorporating changes from the review will be submitted to POCL.
A formal review of the comments received at the end of the review period, assumed to
be 2 weeks, will be conducted with representatives of POCL. The review meeting
will agree the method of resolution of all comments raised.
A revised version of the document incorporating agreed changes will be baselined and
introduced into the Core Documentation Set under CCN.
4 Content of ICL Pathway Generalised API for OPS/TMS
This shall be as follows.
4.1 Introduction
This section describes who the document is intended to be read by, and the
conventions used.
4.2 Context
This identifies the relationship of this document to the OPS Architecture
Specification, which describes the Retail Broker, Peripheral Broker and Riposte
OCXs used in application development and how applications should be developed. It
identifies also the relationship to the TMS Architecture Specification that defines the
way Riposte facilities are used across the TMS domain. The relationship to the
Access Control Policy and OPS Style Guide is also defined.
4.3. Scope
The document provides a description of the context in which the APIs are used for the
application developer. These are expressed in terms of the business functions
supported by EPOSS, the application functionality supported by OPS/TMS, and other
application interfaces that need to be supported in the OPS/TMS environment.
The document will define APIs that have been created or modified by Pathway. It will
list any relevant Escher supplied APIs and will list Riposte APIs that are excluded
from the Pathway implementation.
4.4 Business Functions
4.4.1 EPOS
This section describes the concept of the ‘Sale’ of a product, its relationship to POCL
Reference Data and the data structures involved.
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 7 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY,
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7109/99
4.4.2 Settlement
This section defines the concepts used in the settlement of a customer session, the
impact of session transfer and how settlement data is sent to clients.
4.4.3, Stock Unit Management
This section identifies the concepts involved in the use of Stock Units, defines the
difference between shared and individual stock units and describes the data structures
involved.
4.4.4 Reporting
This section will describe the reporting functions that are available to the application
developer.
It will identify how a Cash Account is constructed using Reference Data and will
describe the data structures involved. It will cover the way receipts are produced and
cross refer to the document Horizon OPS Reports and Receipts.
4.4.5 Balancing
This section covers the way a Stock Unit balance is achieved and its relationship to
the office level Cash Account.
4.5 Application Functions
4.5.1 Architecture
This section will cross refer to the appropriate sections in the OPS Architecture
Specification.
4.5.2 Peripheral Server Interfaces
This describes the interface provided to support the use of input and output devices.
4.5.3 Retail Broker Interfaces
This describes the interfaces needed to add the sale of a product as a transaction to the
stack (list of transactions in the current session) presented to the clerk, to cancel
transactions and deal with any additional processing required at the point when a
session is settled.
4.5.4 Desktop Interfaces
This chapter describes how the desktop interface is controlled by the use of standard
OCXs and identifies those available for use by the application developer and those
controlled by the system.
4.5.5 Riposte Functions
This chapter describes the interfaces needed to handle messages and persistent
objects.
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 8 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7/09/99
4.5.5.1 Messaging
The section on messaging describes how messages are created and retrieved. It deals
also with the concept of markers, checkpoints and message ports. How to create and
wait for the response from queries is also covered as is how to start, end and undo a
transaction.
4.5.5.2 Persistent Objects
The section on persistent objects (such as reference data) covers the use of local
databases as well as the location of existing objects and the creation of new ones.
4.5.5.3 Parsing Functions
This section describes the concept of attribute grammar and how attribute grammar
and messages are parsed.
4.6 Agent Interfaces
4.6.1 Bulk Agent
The interfaces used by both bulk inbound and bulk outbound data transfer agents are
described.
4.6.2 Interactive Agents
The interfaces used by both interactive inbound and outbound agents are described.
4.6.3 Enquiry Agents
The interfaces used by enquiry agents are described.
4.7 Other Functions
4.7.1. Administration
This section describes the system supplied administration and configuration functions.
4.7.2 Security
The security functions that are available to the application developer are covered,
including an outline of functions and facilities available for cryptographic key
management.
The Appendix gives details of key management within the Pathway implementation.
4.7.3 Availability
This section covers the concept of SLAs. It describes the impact of End Of Day
processing and of disconnected counters on availability of the service to the clerk.
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 9 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7109/99
4.7.4 Usability
This section identifies how the interface to the clerk should be implemented and
describes the scope of MMI rules identified in the Horizon OPS Style Guide.
4.7.5 Performance
This section identifies the main issues to be considered to minimise the impact of new
applications on the existing OPS application services.
4.7.6 Resilience
This section describes the resilience provided by Riposte and the additional
functionality that applications have to provide to deal with the impact of hardware,
communications and software faults.
4.8 Standards
4.8.1 Naming Standards
This section defines the naming standards to be used for application components,
messages, and persistent objects, events and attributes.
4.9 Systems Management
This section covers the basic elements of systems management that need to be
considered in the procurement context of a new application. Further information on
those aspects of systems management that developers will require is contained in the
Appendix. This will be subject to Non Disclosure Agreement.
4.9.1 POCL Reference Data
This section describes how POCL Reference Data is accessed, the temporal nature of
such reference data and the process used to maintain such data.
4.9.2 Event Reporting
This section describes the application interfaces to be used for event reporting,
including the reporting of exception conditions.
4.9.3 Software Packaging
This section describes how software comprising new applications is to be handed over
to ICL Pathway for system integration testing, and the documentation needed to
support such handovers. This section gives an overview of the systems and integration
process and subsequent processes leading to implementation of the new application.
5 Development Timetable
The baselined version of this document, without the Appendix, is to be available by
the end of November 1999.
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 10 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7/09/99
The Appendix is to be available by end January 2000.
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 11 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
ICL Pathway DEVELOPMENT OF MANUAL DESCRIBING USE OF Ref: CR/SPE/007
OPS, TMS AND EPOSS APIS WITHIN ICL PATHWAY
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 7/09/99
(A)Appendix - Systems Management and Key
Management
This Appendix is subject to Non Disclosure Agreement
Systems Management
This document expands on the Systems Management information outlined in section
4.9.
In particular, this section defines how software comprising new applications is to be
handed over to ICL Pathway for system integration testing, also the documentation
needed to support such handovers. For instance, such documentation must include
program specifications and must list all the exception conditions catered for, together
with resource requirements.
The section defines the way that EXEs, OCXs and DLLs are packaged for distribution
and support purposes.
Key Management
Where a new application may employ encryption, Pathway anticipates that discussions
with the Supplier of the new application will be initiated at the earliest appropriate
stage. This section gives details of the functions for key management in the Pathway
environment including the distribution of keys to post offices.
© 1999 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 12 of 12
Last Printed: 23/09/99
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident AnalysisForm ‘Fo be completed by the ICL Pathway Acceptance Manager:
: AS : flo be given to the Horizon Acceptance Incident Manager
Acceptance Incident Number (1) Analysis Sequence Number (2)
342
Acceptance Test Name (3)
TIP Interface
“Analysed Incident Severity (4) High / Medium / Low (4) Authority (5)
See Medium
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.
Iwithdrawal. Since then an ad-hoc database analysis has been 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 a 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 (e.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. TVIFS/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. TDAION/005).
Clearance Action (7)
‘This is essentially the same as that proposed for AI371, relating to HAPS SLA.
Version 1.0 1 of3 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
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
ithe times of transmission and receipt acknowledgement.
Progam 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
I- FAD code
I- 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 set out in the “New Procedures” section below.
INew 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 due 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. This is an existing Web Page, which is accessible to POCL Service Management, and lists various problem
issues. This will enable 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
nf files and tho times af trancmiscion and rereint acknowlodeoment
Version 1.0 2 of 3 24 September 1999
Second Supplemental Agreement Annex to Schedule 2
of files and 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 reason, 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, and an extended period of monitoring to 1/10/99 is
proposed during which the specific actions within the Clearance Actions will be checked for completion.
This Clearance Action has been agreed by POCL and this Analysis form documents that agreement in accordance
Iwith the action agreed at the Acceptance Workshop on 25/8/99.
POL00325269
POL00325269
above
Acceptance Incident Status (Open! [Agreed Resolution Plan
Analysed Retest/Recommended for KPR (8))
Sig natures: — : ee
I propose the Clearance Action __IP- John Pope ICL Pathway Test
and Incident Status described Manager — é
16-Sep-99]
T accept / reject the Clearance
Action and Incident Status
described above
Horizon Acceptance
Horizon Acceptance Incident Manager Date:
‘DSS Acceptance Manager I poc. Business Assurance
Date: Date:
Version 1.0 3 of 3 24 September 1999
POL00325269
POL00325269
Table extracted from BA/ACC/020 Version 0.4 dated 20/9/1999
OBCS failures testing approach and rectification plan
The proposed rectification plan has two elements:
¢ further actions required to enable the completion of comprehensive analysis on each potential or perceived cause of the
problem;
* proposed solutions, which when implemented, should deliver a reduction in the level of manual inputs.
Page lof 6
POL00325269
POL00325269
Further analysis required
Topic area Sub topic Proposed action Lead Outputs Proposed
target date
System, Approach for Production of paper POCL (with I Agreement of paper 28 September
Procedures and further tests, outlining the approach to I input from
Order Books analyses and be deployed in the ‘pilot’ I ICL Pathway
observations and further testing, and DSS)
analyses and observations
planned to commence w/c
27 September
System issues Hardware and Pilot scheme at ‘live’ POCL Paper recording the results I 8 October
software offices, on receipt, issue, of the pilot, including
encashment and initial feedback and
redirection transactions changes required to the
process prior to further
testing
System issues Hardware and Further tests following POCL Paper recording the final 12 November
software ‘pilot’ scheme, on receipt, results, including
issue, encashment and proposed way forward
redirection transactions (dependant on the
outcome of the tests)
System issues Human Computer I Study to identify potential I POCL (with I Change requests 26 November
Interface areas of input as submitted, as appropriate
confusion/improvement — I required
opportunities. from ICL
Page 2of 6
POL00325269
POL00325269
Pathway /
Dss)
Training Communication of I Confirmation of the ICL Pathway I Paper outlining the 1 October
materials/ delivery I revised procedures I process for communicating process, focusing on the
(ICL Pathway) (1) revisions to procedures initial training i.e. the
during the lifetime of a training performed by ICL
release. To include revision Pathway (ICL Training
to training material and Services) personnel*.
communication to trainers.
Training Configuration Confirmation of the ICL Pathway I Paper outlining the 1 October
materials/ delivery I management process for ensuring that process*.
changes to system design
/ procedures are reflected
in draft/final versions of
the training workbook (i.e.
during the development of
the workbook for a
particular release).
Training Communication of I Confirmation of the POCL Paper outlining the 1 October
materials/ delivery I revised procedures I process for communicating process, focusing on the
(POCL) (ii) revisions to procedures on-going training i.e. the
during the lifetime of a training performed by
release. To include revision POCL personnel*.
to training material and
communication to trainers.
Procedures Correct application I Observations during the POCL Report outlining the initial I 8 October
of procedures ‘pilot’ commencing w/c 27 findings, including
Page 3of 6
POL00325269
POL00325269
September proposed way forward
(dependant on the
outcome of the
observations)
Procedures Correct application I Observations during the POCL Paper recording the final I 12 November
of procedures further tests following the results, including
‘pilot’. proposed way forward
(dependant on the
outcome of the
observations)
Procedures Communication of I Confirmation of the POCL Paper outlining the process I 1 October
revised procedures I process for communicating for communication both
revisions to procedures urgent and non-urgent
during the lifetime of a changes to the User Guide
release. To include the *
communication of urgent
information.
Order books Analysis of Analyse barcodes of books I POCL (using I Report on the initial 8 October
barcodes which are impounded independent I findings on the quality of
during the pilot ‘tester’) barcodes from books
commencing w/c 27 impounded in the live
September. environment, including
proposed way forward
(dependant on the
outcome of the analysis)
Order books Analysis of Analyse barcodes of books I POCL (using I Final report on the quality I 12 November
barcodes which are impounded independent _I of barcodes from books
Page 4of 6
POL00325269
POL00325269
during the further tests ‘tester’) impounded in the live
following the ‘pilot’. environment, including
proposed way forward
(dependant on the
outcome of the analysis)
Order books Analysis of Analyse the ICL Pathway I Report on the initial 8 October
printing/ paper printing / paper of books (PIRA) findings on the quality of
which are impounded the printing/ paper of
during the pilot books impounded in the
commencing w/c 27 live environment,
September including proposed way
forward (dependant on the
outcome of the analysis)
Order books Analysis of Analyse the ICL Pathway I Final report on the quality I 12 November
printing/ paper printing/ paper of books (PIRA) of printing/ paper from
which are impounded books impounded in the
during the tests following live environment,
the pilot including proposed way
forward (dependant on the
outcome of the analysis)
Proposed solutions
Topic area Sub topic Proposed action Lead Outputs Proposed
target date
Training, Training Reword paragraph(s) ICL Pathway I Draft of the changes, for 24 September
materials/delivery I workbook relating to non barcoded review
revisions books. Emphasise that
Page Sof 6
POL00325269
POL00325269
books should only be
scanned once, where an
impound message is
displayed. Emphasise
correct procedure for
‘system failure’ i.e. to use
this option only when the
barcode reader is faulty
and when the failure has
been reported to the
HSHD.
Training
materials/ delivery
Communication of
revised procedures
Confirmation of the
communication of the
revised procedure for new
Horizon offices during
training events
ICL Pathway
Copy of the trainers’
‘addendum’ documenting
the amendment
20 September
Procedures
Communication of
revised procedures
Confirmation of the
communication of the
revised procedure for new
Horizon offices
POCL
Copy of the
communication issued to
new Horizon offices
20 September
Page 6of 6
POL00325269
POL00325269
ICL Pathway Acceptance Proposal Ref: CR/ACD/372
. Version: 0.4
Acceptance Incident 372 Date: 16/9/99
Document Title: Acceptance Proposal for Acceptance Incident 372
Document Type: Acceptance Proposal
Abstract: This document contains the agreed Closure Plan in respect of
Acceptance Incident 372.
Status: Issued
Distribution: Expert:
Peter Copping
ICL Pathway:
Library
POCL:
Bob Booth/Jeremy Folkes
John Meagher
Min Burdett
Jeff Austin
Author: DC Hollingsworth/ J C C Dicks
Comments to: ICL Pathway list
Comments by:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 1 of 8
ICL Pathway
Acceptance Proposal Ref:
. Version:
Acceptance Incident 372 Date:
POL00325269
POL00325269
CR/ACD/372
0.4
16/9/99
0 Document control
0.1 Document history
Version Date
0.1 23/8/99
0.2 24/8/99
0.3 8/9/99
0.4 16/9/99
Reason
Initial draft for comments
Version for Expert and Workshop 25/8/99
Version documenting the agreed Clearance Plan Plan.
Further version following Acceptance workshop action
documenting the agreed Clearance Plan Plan.
0.2 Approval authorities
Name
JH Bennett
JCC Dicks
TP Austin
Position Signature
Managing Director
Customer Requirements
Director
Development Director
0.3 Associated documents
Reference Vers Title
0.4 Abbreviations
ATE Automated Targeting Engine
Date
Source
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 2 of 8
POL00325269
POL00325269
ICL Pathway Acceptance Proposal Ref: CR/ACD/372
Version: 0.4
Acceptance Incident 372 Date: 16/9/99
0.5 Table of content
1. PURPOSE
2. SUMMARY.
4. POCL POSITIO!
5. ICL PATHWAY POSITION
5.1 EVIDENCE TO ENABLE THE PLAN TO BE AGREED.......0--0+0
5.1.1 Report of the upgrade exercise and technical briefin,
5.1.2 Analysis of the Incident.
5.2 CLEARANCE PLAN
5.2.1 Clearance plan summary.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 8
POL00325269
POL00325269
ICL Pathway Acceptance Proposal Ref: CR/ACD/372
. Version: 0.4
Acceptance Incident 372 Date: 16/9/99
1. Purpose
This document sets out the ICL Pathway proposal to the Expert with respect to
Acceptance Incident 372.
2. Summary
ICL Pathway accepts that there were some system management incidents during the
CSR LT1 to LT2 system upgrade activity during the Live Trial period. Although the
scale of problems was relatively modest for the number of outlets involved (299), the
problems encountered, if left uncorrected, would cause difficulties in rolling out future
software upgrades to a much larger live estate. Thus ICL Pathway accepted a Medium
severity assessment.
Since the Acceptance Incident was raised the three important issues, that were the root
cause of the incidents, have all been fixed and details have been provided to POCL.
Ongoing monitoring and reporting of the systems management operations are already
in place, with details provided routinely to POCL via the ICL Pathway web site.
Specific technical questions relating to the performance and scalability of the software
distribution product and its method of operation have been answered in a detailed
technical presentation.
Specific further commitments have been given concerning the nature of CP2116 and
the content of a “substantial software download”.
Other lessons learned from the upgrade exercise will be incorporated in the planning
of the next software upgrade, expected to be CSR to CSR+ during 2000. POCL will
be invited to participate in that exercise (as they were in the LT1 to LT2 exercise), but
ICL Pathway cannot currently provide a date for this exercise since it has not yet
completed the planning stage. On the basis of the measures already in place, ICL
Pathway assesses the incident severity as “Low”.
3. Criteria
The Criterion under test is 37/1.
4. POCL position
Based upon the minutes of the Acceptance Board Meeting of 18 August 1999, POCL
contended that:
“there is lack of evidence on resolution to enable the current plan to be agreed”.
“the plan does not contain clear dates and deliverables”.
POCL have also expressed the desire to see a “dress rehearsal” of the next major
upgrade exercise using the (to be) developed scripts applied to a “small test estate”.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 8
POL00325269
POL00325269
ICL Pathway Acceptance Proposal Ref; CR/ACD/372
. Version: 0.4
Acceptance Incident 372 Date: 16/9/99
5. ICL Pathway position
5.1 Evidence to enable the plan to be agreed
5.1.1 Report of the upgrade exercise and technical briefing
ICL Pathway has already provided a very full and detailed report on the CSR LT1 to
LT2 upgrade exercise. This report includes:
e the full history of the weekend exercise
* astatement of problem areas encountered
e the decisions taken to overcome various problem as they arose
e references to ongoing operating procedures that will be improved
* recommended improvements, that will be incorporated into future system
upgrade exercises
POCL has reviewed the report and raised further questions, to which ICL Pathway has
also responded. ICL Pathway has also held a detailed technical briefing session for
POCL with the ICL Pathway senior systems designer covering the overall system
management procedures and products used.
5.1.2 Analysis of the Incident
ICL Pathway has accepted that some aspects of the LT1 to LT2 upgrade identified
problems in the systems management process. Three specific issues were identified:
1. The procedure for delivering one element of Reference Data (“Type D”
Reference Data) was not properly established, resulting in this Reference Data
being missing from some outlets and delaying the upgrade programme whilst
in-flight rectification was undertaken
2. The procedure for dealing with “Error Type 221” reports from the Tivoli
system management software was incorrectly specified, resulting in operations
staff following an unnecessary, but safe, procedure to manually control the
software upgrade on a site by site basis, rather than controlling the distribution
automatically using the Automated Targeting Engine. This resulted in a
somewhat extended time to complete the upgrade compared with the planned
time.
3. A specific technical fault was identified within the Automated Targeting
Engine, causing long error messages from an outlet being incorrectly handled.
In addition potential improvements were noted to several operational activities during
the LT1 to LT2 upgrade exercise and these will be fed into the planning activity for
the next software upgrade, although this has not yet reached a formally planned state.
5.2 Clearance plan
The agreed Clearance Plan is based upon:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 8
POL00325269
POL00325269
ICL Pathway Acceptance Proposal Ref: CR/ACD/372
Version: 0.4
Acceptance Incident 372 Date: 16/9/99
1. Actions to correct the three specific faults identified above.
These actions have all been completed and details made available to POCL.
2. The provision of additional technical details to POCL in response to comments
on the LT1 to LT2 upgrade report, specifically on the use of the Tivoli
software and the capabilities of the ATE.
This has been completed in the form of a detailed presentation to POCL staff
by the ICL Pathway senior designer responsible for systems management.
3. The provision of ongoing monitoring of the software distribution process,
using the ATE, with regular statistics provided on the ICL Pathway web site of
software distribution to the live estate (software details, start date, 95%, 99%
and 100% complete dates).
This action has been completed with the exception of adding details on the
99% completion date. ICL Pathway offers to provide this within one month.
In addition if POCL wish to view the use of the ATE in this situation ICL
Pathway has offered to provide this. Systems management capability is an
ongoing agenda item at the monthly Service Review Forum meetings where
any questions or issues arising from this ongoing monitoring / reporting can
be raised for discussion and resolution.
4. The provision for joint input by POCL and ICL Pathway into the next upgrade
plan (expected to be CSR to CSR+ during the first half of year 2000), allowing
POCL to have assurance that any concerns arising from the last upgrade
exercise have been addressed within the plans for the next.
This undertaking has been provided. The dates and details for this exercise
are beyond the current planning window but planning is expected to start
towards the end of this year or early next year. (Note that each upgrade
situation is individually planned according to the volume of software to be
distributed, the size of the live estate, the hours of operation of the outlets
involved, etc.)
5. Although ICL Pathway believes the above actions are comprehensive, should
POCL have residual concerns as to the capability of the systems management
service to cope with a substantial upgrade activity, ICL Pathway has also
proposed that CSR+ will initially be distributed to an agreed subset of live
offices prior to full roll-out. This offers the opportunity to review software
distribution capability in a live trial environment prior to commitment to the
entire live estate. At the time of writing, this particular exercise lies beyond
the current planning window (and hence cannot be assigned a specific date)
but would form part of the agreed CSR+ introduction plan.
6. dll file checking.
ICL Pathway has developed a Systems Management task that checks the
structure of .dll files in prescribed system directories for content integrity.
This task can be executed on a one shot basis at a particular outlet, or can be
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 8
POL00325269
POL00325269
ICL Pathway Acceptance Proposal Ref: CR/ACD/372
. Version: 0.4
Acceptance Incident 372 Date: 16/9/99
consolidated with other systems maintenance activities in the regular overnight
script (this also reloads the Riposte desktop, for example).
CP 2116 is being implemented to provide this regular overnight capability.
ICL Pathway will continue to run the .dll contents check on potentially
affected files within the overnight activities until an agreed closure criterion is
achieved. This will be either:
e diagnosis and fix of the underlying corruption problem, or:
¢ asubstantial software download has occurred followed by a clear period
of 3 months running with no detected .dll file corruptions.
Pathway confirms that .exe and .ocx files are also checked per CP 2116.
7. ATE (Automated Targeting Engine) functioning
The incident that occurred during the LT2 upgrade has been tested and fixed
(incorrect handling of long error messages). The fault was recorded and
cleared through the OSD fault notification process (PinICL is used for
Pathway related incidents). Further details have been supplied by OSD on the
nature of the fault and the resolution undertaken:
Messages in the Tivoli Log that exceed 512 bytes caused an error in ATE due
to a string size allocated not being long enough. The change required was to
terminate the log messages to a maximum of 512 bytes. Testing was
performed by simulating a Tivoli log with a message greater then 512 bytes
and was implemented with a new release of ATE.
As noted previously the ATE is in regular usage. ICL Pathway continues to
demonstrate its usage during normal operational management of the live
estate. Consistent with this usage, ICL Pathway will consolidate distributions
representative of the LT2 distribution during the next three months live
operation. (Representative in this sense is taken to include elements of both
Riposte and the Pathway counter applications.)
These distributions will be:
I. Riposte Peripheral Server (update #20). The characteristics of this
upgrade are that it involves complex interaction between parts of ICL
Pathway, and is defined by three Release Notes with detailed
interdependencies.
2. Consolidated EPOSS/Counter Applications Upgrade. This is
distinguished by its relative size, several Mbs.
Appropriate supporting documentation will be supplied, including
interdependencies, activity logs and statements of how any exceptions were
handled.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 7 of 8
POL00325269
POL00325269
CR/ACD/372
0.4
16/9/99
ICL Pathway Acceptance Proposal
Acceptance Incident 372
5.2.1 Clearance plan summary
All important Clearance plan activities have been completed.
Ongoing monitoring of software distribution activities is already provided (with a
further minor extension planned) and an appropriate review forum identified for
resolution of any matters arising.
The principle of POCL involvement in the planning of such software upgrade
exercises is already established and will continue into future exercises such as the
CSR+ upgrade. This can include further assurance of software distribution capability
within a live trial context.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 8 of 8
ICL
Pathway
POL00325269
POL00325269
Acceptance Resolution Plan Ref: CR/ACD/376
. Version: 0.9
Acceptance Incident 376 Date: 23/9/99
Document Title:
Document Type:
Abstract:
Status:
Distribution:
Author:
Comments to:
Comments by:
Acceptance Resolution Plan for Acceptance Incident 376
Acceptance Resolution Plan
This document contains ICL Pathway’s Resolution Plan in
respect of Acceptance Incident 376.
Issued
Expert:
Peter Copping
ICL Pathway:
P John Pope
Library
POCL:
Calum Craig
John Meagher
Min Burdett
Jeff Austin
JCC Dicks
Pathway list
23/9/99
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page I of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Ref: CR/ACD/376
Pathway Acceptance Incident 376 vee 23/919
QO Document control
0.1 Document history
Version Date Reason
0.1 20/8/98 Initial draft for comments
0.2 24/8/99 Version for Expert and workshop 26/8
0.3 4/9/99 Version for Expert and workshop 6/9
0.4 10/9/99 Version includes an addendum resolving actions from 9/9
workshop. For Expert and workshop 13/9 as Resolution Plan.
0.5 16/9/99 Version documenting final agreed Resolution Plan.
0.6 16/9/99 Further version minor changes, observation period described
0.7 22/9/99 To include agreed closure criteria
0.8 22/9/99 Updates agreed during drafting of Schedule 2 Part A of the
second supplementary agreement
0.9 23/9/99 Further updates arising from drafting of Schedule 2 Part A of
the second supplementary agreement
0.2 Approval authorities
Name Position Signature
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
0.3 Associated documents
Reference
CS/PRD/065 0.3
Vers Title
TIP Incident Status Report
0.7 Logical Design for EPOSS/TIP Reconciliation
Controls
Ceasing of Non-Core Products at Outlets
ey
Process For Removing Products From Outlets At
CSR
Date
Source
Pathway
Pathway
Pathway
Pathway
© 1999 ICL Pathway
Ltd COMMERCIAL IN CONFIDENCE
Page 2 of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Ref. CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
0.4 Abbreviations
AIS Application Interface Specification
CSR Core System Release
CSR+ Core System Release — Plus (the release after CSR)
EPOS Electronic Point of Sale
EPOSS _ EPOS Service
TIP Transaction Information Processing
TMS Transaction Management Service
TPS TIP Processing System — the Pathway host layer for the TIP stream
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Ref: CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
0.5 Table of content
1 PURPOSE,
2 SUMMARY
3. CRITERIA...
4 POCL POSITION.
5 PATHWAY POSITION...
5.1 BACKGROUND.
5.2. MATURITY OF PLAN
5.3. DELIVERY OF ADDITION
5.3.1 Ongoing Analysi:
5.3.2. Development Of Additional Recon
5.4. CORE TO NON-CORE (AI410)
5.4.1 The position at CSR...
6 CLOSURE CRITERIA
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Ref: CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
1 Purpose
This document sets out ICL Pathway’s proposal that Acceptance Incident 376,
currently categorised as Medium by Pathway and High by POCL, should be
recategorised by POCL as Medium, and that the Resolution Plan is satisfactory and
should be agreed.
2 Summary
Pathway contends that there are Clearance Actions that address the three remaining
issues defined by POCL.
The issue relates to not passing records to TIP because of harvester exceptions caused
by missing functions in counter code. ICL Pathway has taken measures to both stop
known occurrences and to ensure that any unforeseen occurrences are reported both to
TIP and to ICL Pathway development.
The occurrence of a functionally unrelated incident considered under this Acceptance
Incident, the omission of records from the counter cash account, concerned only
voucher products. This omission is in process of elimination. In addition procedures
have been tightened to minimise the risk of product withdrawals causing operational
difficulties at the counter.
Furthermore, additional reconciliation features that confirm the integrity of data
passing to TIP have been proposed.
3 = Criteria
Criterion 831/1 is cited: “The Contractor shall support interface from TMS and
Outlets to Transaction Information Processing (TIP).
4 POCL position
Based upon the minutes of the Acceptance Board Meeting of 18 August 1999, POCL
contended that:
“the plan is still immature” .
“the proposal not to deliver the additional controls until March 2000 is not
acceptable” .
“the latest analysis performed on Incident 410 ... has revealed further unresolved
deficiencies and the workaround for these is not agreed” .
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Ref: CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
5 Pathway position
5.1 Background
During the Live Trial, and since, incidents have occurred that, in POCL’s view,
constitute a potential threat to the integrity of their accounts. These are tracked in
A1376, TIP Acceptance Incident Status, and associated Root Cause Analysis.
5.2 Maturity of plan
The elements of the resolution plan are defined as activities within the integrated
Acceptance Resolution Plan (currently version 0.9, 16/9/99).
The Pathway proposal in this area has now been expanded into the High Level Design
document Logical Design for EPOSS/TIP Reconciliation Controls. The joint working
group has reviewed this in detail. This document provides a description of how
Pathway will provide additional reconciliation between the Cash Account produced in
the outlet and the transactions sent to TIP. It contains detailed proposals for
enhancements to counter processing, harvesting and the TPS Host.
5.3 Delivery of additional controls
Clearance action:
The document Logical Design for EPOSS/TIP Reconciliation Controls, Version
0.7, 20/9/99 has been agreed and the enhancements will be in service by 31/12/99.
5.3.1 Ongoing Analysis And Review Of Incidents
ICL Pathway will continue to analyse new incidents and will issue periodic updates of
the TIP Incident Status Report. This report will be reviewed jointly fortnightly or as
required.
ICL Pathway’s objective is to eliminate the root causes of such incidents as are
described in Section 2 above, while providing a clear method of communicating rare
error corrections.
5.3.2 Development Of Additional Reconciliation Controls
Additional controls through the introduction of reconciliation will be developed as
described in the document Logical Design for EPOSS/TIP Reconciliation Controls.
POCL's requirement to have continued visibility of the functionality of the solution
will be met by re-issues of the above-mentioned document. Should low level design
affect any area within the high level design, then the Logical Design document will be
updated and re-issued to POCL.
Pathway is currently providing Harvester exception reporting and will continue to do
so until the additional Reconciliation Controls have entered service.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Refi CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
POCL is concerned regarding assurance of testing plans and testing activities. ICL
Pathway will issue the High Level Test Plans (HLTPs) to POCL for the additional
reconciliation controls and will also issue the corresponding Test Reports, both for
comment. POCL will provide such comments in a single batch for each of the HLTPs
and Test Reports within two weeks of their provision to POCL. In addition, POCL,
may witness testing. The testing strategy to be adopted for this Plan will be
documented and provided te POCL.
5.3.3 Additional Reconciliation Procedures
POCL has observed that joint procedures for dealing with reconciliation incidents
need to be developed. ICL Pathway recognises the need for such procedures and will
work jointly with POCL to develop them. It is agreed that these procedures will
embrace the following five points:
1. POCL will accept manual error corrections of either transaction record errors
or cash account stream record errors up to an aggregate level of 50 per week
2. Above this level Pathway will fix errors and (re)submit the data electronically
to the TIP interface, unless agreed otherwise by POCL.
3. Manual error reports are to include a full specification of the repaired
transaction data, such that the data would pass the integrity checks if
resubmitted. Where it is necessary to make a judgement about a repair, such
judgement will be declared explicitly by Pathway. Data is to be presented in a
suitable format for POCL to key into a POCL data input facility.
4. The delay between the occurrence of an error (or where applicable its later
detection) and the notification of the correction to POCL (either manually in
accordance with (1) above or electronically in accordance with (2) above) shall
not exceed five working days.
5. Pathway is to pay POCL liquidated damages of £100 per transaction error
correction submitted manually.
The Contractor shall test the procedure described in sub paragraph (2) above prior to
the implementation of the additional reconciliation controls and POCL shall assist and
witness the attainment of the outcome.
The above procedures shall be introduced at the same time as the additional
reconciliation controls referred to in paragraph 5.3.2 above
5.4 Core to non-core (AI410)
Clearance action:
The document, Ceasing of Non-Core Products at Outlets, is agreed and ICL Pathway
will implement the defined functions for CSR+.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 7 of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Ref CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
5.4.1 The position at CSR
Refinement to product management procedures at CSR:
AI 410, although related to AI 376 through the generality of reconciliation of the Cash
Account and the TIP stream, is in fact the reverse condition: a record that was not
incorporated in the Cash Account was received by TIP.
This condition was caused by ceasing a product at an outlet by changing it from a
Core product (transacted at all outlets) to Non-core (transacted at only a subset). This
resulted in “end dating” the Item Reference Data at an outlet that had not received
replacement non-core reference data but had transacted the product earlier in the
week. EPOSS did not include transactions in the Cash Account that had occurred
immediately before the product was end-dated at the outlet.
It had been agreed, for CSR, that Operational Business Change procedures would
screen out cases of Item Reference Data being end-dated, the outlet would not be able
to perform housekeeping functions such as remitting out remaining inventory in any
case. The agreed process for removal from sale is by use of changes to the Menu
Hierarchy.
Unfortunately neither POCL nor Pathway staff involved had realised that changing a
product from Core to Non core would result in just such a cessation. Procedure
documentation has now been amended to make this case explicit.
ICL Pathway is introducing a change to ensure that all transactions for end-dated
products appear in the cash account. This will provide full accounting integrity.
The parties shall carry out the procedures described in the document Process For
Removing Products From Outlets At CSR, Version 0.3. These procedures will be
revisited if experience so indicates.
Introduction of an enhanced proposal for item transaction modes at CSR+:
A feature, Item Transaction Mode, is scheduled for introduction at CSR+ and will
provide a comprehensive means of controlling the classes of transaction that can be
applied to products. However, in the course of considering these issues it was further
realised that no provision at CSR+ in interfaces and designs had been made for the
particular case of end-dating Non-core products in individual outlets.
This issue, ceasing Non-core products at individual outlets at CSR+, has been
addressed in the document Ceasing of Non-Core Products at Outlets, which was
published on 24/8/99, and which POCL has confirmed is acceptable.
6 Closure Criteria
The closure criteria agreed between the parties are:
1. That there will be an Observation Period of six weeks starting 1" October 1999.
2. During the Observation Period there will be no reoccurrence of previously fixed
faults
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 8 of 9
POL00325269
POL00325269
ICL Acceptance Resolution Plan Ref: CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
3. During the Observation Period not more that 0.6% of Cash Accounts sent to TIP
will be found by TIP not to reconcile to the Cash Account derived by TIP from the
transaction stream due to Pathway processing error.
4. During the Observation Period Pathway will analyse all new incidents within 10
working days, and report these analyses to TIP using the established TIP Incident
Status format. The 10 days starts from the time TIP log the incident on the
Pathway helpdesk. The analysis is to include an expected fix implementation
date. For incidents that cannot be reproduced the result of analysis may be to
implement diagnostic code.
5. There will be a period of parallel running of the Pathway and TIP reconciliation
process during which the Pathway solution must find at least all those
reconciliation failures correctly reported by TIP.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 9 of 9
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
Pathway Reconciliation Controls Version: S09 99
Document Title: Logical Design for EPOSS/TIP Reconciliation Controls
Document Type: Design Specification
Abstract: This document describes the processes which will be put in
place to reconcile that the EPOSS transactions processed at the
Counter are passed through to POCL TIP; and that they are
accounted for in the weekly cash account statements prepared at
the Outlets and in the Cash Account details passed through to
POCL TIP
Status: Draft
Distribution: Alan Ward Peter Wiles
Dick Long Ann Cooper
John Dicks Lorraine Holt
John Pope Roger Donato
Chris Humphries David Jones
Gareth Jenkins Stephen Doyle
Steve Warwick Janet Dore
Phil Hemingway Stefan Robson
Rex Dixon Dennis Sandor
Richard Brunskill Dave Cooke
Duncan MacDonald Peter Chandler
Nikki O’ Sullivan
Library Calum Craig
Author: Roger Donato / Steve Warwick / Phil Hemingway
Comments to: Steve Warwick
Comments by: 23 September 1999
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page I of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP y Ref: PDESi002
aliati ersion: 0.
Pathway Reconciliation Controls Date: 20/09/99
Q Document Control
0.1 Document History
Version Date Reason
0.1 - First Draft in WORD 95 format (with lost section numbers)
0.2 - First Draft WORD 97 format as presented to POCL 03/09/99
0.3 10/09/99 Application of feedback from version 0.2
Absolute values change to Actuals in Daily Cash Account
Control Totals
Inclusion of brought forward totals in Reconciliation
Addition of transaction errors detected by Counters
0.4 14/09/99 Same as version 0.3
0.5 16/09/99 Scope Section added
Handling of failure scenarios added
Specification of Changes to Counters in the Detailed Design
Corrections / Changes arising from V0.3 feedback
Data item Transaction Date removed from report of Host
Detected Transaction Control Errors
CA Table *” XX” for error totals
0.6 17/09/99 Data Flow diagrams added
0.7 20/09/99 Comments added following review by TDA and
Acceptance Workshop at Gavrelle House on 17/09/99
0.2 Associated/ Documents
Reference Ver Date Title Source
sion
1 TIAFS/001 5.7 05/07/99 Pathway to TIP AIS POCL
PCSTIPIS
2 TD/DES/118 0.1 16/09/99 EOD Harvest Trailer Generation HLD Pathway
COMMERCIAL IN CONFIDENCE Page 2 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP \ Ref.: RUDESIO02
an ersion: 0.
Pathway Reconciliation Controls Date: 20/09/99
0.3 Abbreviations
CA Cash Account
CAP Cash Account Period
EPOSS Electronic Point of Sale System
OPS Outlet Processing System
POCL Post Office Counters Limited
TIP Transaction Information Processing
TPS Transaction Processing Service
0.4 Standard Terms
CA Table Number The number of the table as it appears on the Cash
Account: e.g. table 00 contains Receipts, table 10
contains Payments
Trading Date Trading Date is the period of time between consecutive
public end of day markers in message store. Normal
end of day is Outlet closing time (as specified in
Reference Data) plus half an hour or 19:00 hours
whichever is the earlier. Where an outlet has end of day
at 19:00 then a Trading Date of 07/12/99 covers the
period of time between 19:00 hours 06/12/99 to 19:00
hours 07/12/99. It should be noted that where an
outlet has differing closing times on consecutive days,
the ‘Trading Day’ may represent more or less than a
24-hour period.
0.5 Changes Forecast
Report Layouts to be modified in line with Low Level Design.
Other corrections and comments as necessary.
0.6 Approval authorities
To be defined
COMMERCIAL IN CONFIDENCE Page 3 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
sage Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
0.7. Table of content
1 SCOPE.
2 INTRODUCTION...........0008
3. Daily Transaction Control Total:
3.2 Daily Cash Account Control Totals...
3.3 Weekly Cash Account Control Totals ...
3.4 Weekly Cash Account Control Total Reconciliation...
4 DETAILED DESIGN PROPOSAL............
4A Changes to Message Store ...
4.1.1 Daily Transaction Control Totals
4.1.2 Daily Cash Account Control Totals...
4.13 Transaction Errors Detected by Counters.
4.4 Weekly Cash Account Control Totals ...
4.1.5 Cash Account Reconciliation Errors.......
4.2 Changes to Counters.
42.1 End of Day Architecture...
42.2 Normal End of Day Processing
4.2.3 Cash Account Processing ....
424 End of Day Processing Following Cash Account......
4.3 Changes to the Oracle Database...
43.1 Daily Transaction Totals...
43.2 Cash Account Total Lines
43.3 Stock Detail Total Lines
43.4 Exception Messages.
43.5 Control Exceptions
4.4 Changes to TPS Agent..
44.1 Daily Processing
4.4.2 Processing of Cash Account Dat
45 Changes to TPS Host.
4.5.1 Daily Processing...
45.2 Processing of CAP Stream Control Totals.
4.53 Processing of Office Stock Holding Control Totals
4.6 Exception Reports...
4.6.1 Host Detected Transaction Control Errors.
4.6.2 Message Store Errors...
4.6.3 Host Detected Cash Account Control Errors
4.6.4 Counter Detected Reconciliation Errors...
COMMERCIAL IN CONFIDENCE Page 4 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP \ Ref. RUDE 00
an ersion: 0.
Pathway Reconciliation Controls Date: 20/09/99
5 DATA FLOW DIAGRAMG...........::ssesessssersseescsssesseccetseseaserescsssesstenenseneansatonsesecene 23
5.1 Daily Processing ..
5.2 Cash Account Processing...
6 REPORT LAYOUTS .......ccccssccesseesesceseeesessesesensenseeseeeeseensesseaeeeesesersueeseeseenaaeaaes 27
6.1 Host Detected Transaction Control Errors...
6.2 Message Store Errors.
63 Host Detected Cash Account Control Errors...
64 Counter Detected Reconciliation Errors
6. FAILURE SCENARIOS........cccccccccsescsseseenseescesseessesssenseeseeseesaseeceueetesouseeeseunnseces 33
COMMERCIAL IN CONFIDENCE Page 5 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP v Ref: PUDES002
ili: if ‘ersion: .
Pathway Reconciliation Controls ‘ion Ooo
1 Scope
This document describes the processes to be introduced to the POCL Infrastructure
products to reconcile the transaction details and cash account details passed to POCL
TIP against the details captured at the counters.
The level of detail given is adequate to enable POCL to ascertain that the solution will
deliver the business requirement, which is to report all incidents in which either
transactions recorded at the counter are not both sent to TIP and brought to account in
the outlet Cash Account, or that the outlet cash account is not correctly transmitted to
TIP.
This document is the principle vehicle for communicating the reconciliation design to
POCL and will be re-issued as necessary.
2 Introduction
This document describes the processes that will be put in place to ensure that:
¢ The accounting transaction data recorded by the EPOSS system on the OPS can be
reconciled with the accounting transaction data returned to the POCL TIP system
across the TIP interface
@ The accounting transaction data written each day at the OPS can be reconciled
with the Cash Account data written at the OPS when the Cash Account is
produced
¢ The Outlet Stock Holdings generated at the end of a Cash Account Period at the
OPS can be reconciled with the Outlet Stock Holdings transferred to TIP across
the TIP Interface
¢ The Cash Account Line records generated at the OPS can be reconciled with the
Cash Account Line records returned to TIP across the TIP Interface
The processes to be put in place will be delivered through the implementation of new
software functionality at both the OPS and TPS Host systems. Where a new OPS
function is delivered to generate control totals, the function will be designed to
calculate the totals by a means different to that used in the current OPS functionality
which generates balancing and Cash Account data. This approach is being taken to
ensure that if the same total is calculated by two separate logical processes then there
can be a high level of assurance in the integrity of the data.
3 Overview
The reconciliation processes will be split into two separate sets of activity, Daily
reconciliation tasks and Weekly (or more accurately at the end of each CAP)
reconciliation tasks.
COMMERCIAL IN CONFIDENCE Page 6 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
wp ge Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
The daily tasks will ensure that the base transaction data recorded at the counter
matches the base transaction data transferred to TIP for that day. At the same time,
the transactions will be used to generate control totals for the Cash Account tables to
which the transaction will report at the end of the CAP.
At the end of the CAP, the daily control totals generated for each Cash Account table
will be accumulated and the resulting value calculated for the Payments and Receipt
tables will be compared with the Cash Account line records generated by the Cash
Account production process. If there is a discrepancy in this comparison then the
system will validate each of the accumulated daily control totals with the
corresponding Cash Account line records to identify the table which does not
reconcile and record an error message in the Riposte message store.
The existing functions in the system which create the outlet stock holding records and
the Cash Account Line records will also be amended to accumulate a control total for
each set of records which will be written into the message store at the end of each set.
These control total records will be harvested and inserted into the TPS Host database.
The TPS Host system will compare the Stock Holding records (‘STX’ records) and
the Cash Account Line records (‘CAC’ records) output to the TIP Cash Account sub-
file with the control totals received from the OPS system. In the event that the TPS
harvester fails to locate either the Stock Holding records (“STX’ records) or the Cash
Account Line records (‘CAC’ records) or the control totals calculated by the TPS
Host system differ from the control totals received from the OPS, then a reconciliation
error report will be produced.
3.1 Daily Transaction Control Totals
At the end of each logical day (Trading Day) an End of Day process runs to insert a
marker into the Riposte Message store. This marker records the precise point in the
message store (for each node in the group) at which the End Of Day process ran. The
marker is used by the TPS Harvester process to delineate the transactions which will
be extracted from the message store and sent, via the TPS Host System, to the POCL
TIP system across the TIP Interface.
The End of Day process will be extended to include an additional set of functions to:
@ Calculate control totals of all accounting transactions recorded since the last End
of Day marker. The control total will be made up of just those transactions which
get passed through to TIP: (thus “transfers” and “remittance settlements” will
not be included since they are not passed to TIP. The full list of transaction types
not passed to TIP are listed in section 4.2.1). The control total will include the
following fields/attributes:
1. Trading Date (Date of current EOD Marker)
Total number of transactions
Total of absolute value of transaction ‘Quantity’ field
eB YON
Total of absolute value of transaction ‘SaleValue’ field
COMMERCIAL IN CONFIDENCE Page 7 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
A Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
The control totals written by the OPS system will be harvested by the TPS Harvester
(or another specific Harvester process) and will be inserted into a new table within the
TPS Host Database. When the TPS Host system creates the TIP sub-file for an outlet
a new process will be added that independently calculates the control totals from the
records being generated in the sub-file and then compares them with the control totals
harvested from the OPS. If there is a discrepancy between the TPS and OPS
generated control totals, the following information will be written to an Exception
Report:
1. Outlet FAD code
2. The values calculated by the OPS
3. The values calculated by the TPS Host
3.2 Daily Cash Account Control Totals
At the same time that accounting transactions are read for the creation of the daily
transaction control totals (see 3.1 above), a further new function within the End of
Day process will cause the value of the transaction to be accumulated in an
appropriate control total(s) to facilitate reconciliation of the Cash Account at the end
of the Cash Account Period. This process will determine, for each transaction
processed, which Cash Account period is appropriate to the transaction (there may be
transactions for more than one CAP on any given day) and to which Cash Account
Table(s) control total the transaction is relevant. The determination of which Cash
Account Table control total is relevant will be based on the ‘Transaction Mode’ and
“Product Number’ contained in the transaction message that will then be used to
access the appropriate Cash Account Mapping reference data to determine the table
number to which the transaction relates. The control total record will include:
1. CAP Number
2. CA Table Number
3. Total number of transactions
4. Total of signed value of transaction ‘Qty’ or ‘SaleValue’ field (only one of these
attributes is present in each CA Line message).
Use of the Transaction Mode, Product Number and Cash Account Mapping data to
determine the appropriate CA Table control total will ensure that the total is derived
by a separate logical process from that used during the production of the Cash
Account itself. Cash Account production relies on the use of product ‘Primary
Mappings’ and ‘Secondary Mappings’ to aggregate transactions at the stock unit and
office levels before the Cash Account mappings are used to generate the final Cash
Account values.
COMMERCIAL IN CONFIDENCE Page 8 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
wpe Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
If any transactions are found which are not possible to map to a CA Table, their
details are added together and included in a Control Total for CA Table Number
“XX”. These are exceptions. The corresponding error transactions will be flagged in
message store from where they will be harvested as Counter detected errors.
Harvested errors will be written to an Exception Report for action via the normal RED
processes. The report will contain:
1. Outlet FAD code
2. The unique message number of the failed transaction
The Mode in which the transaction took place
w
The stock unit in which the transaction took place
The product number of the failed transaction
The Sale Value of the failed transaction
aan
The reason that the transaction failed to be mapped
3.3. Weekly Cash Account Control Totals
At the time that the Cash Account ‘Trial Report’ is produced the OPS system creates a
set of ‘Cash Account Line’ records (which reflect the line by line content of the hard-
copy print of the Cash Account).
For each set of records produced, an additional message will be written which
contains control totals. The control totals will include the following fields:
1. CAP Number
2. Total absolute number of transactions
3. Total of absolute value of transaction ‘Qty’ or ‘SaleValue’ field (only one of
these is present in each message, separate totals will be maintained for ‘Qty’
and ‘SaleValue’)
At the time that the Office is ‘rolled over’ in to the next CAP, the ‘Final Cash
Account Report’ is produced and the OPS system creates a set of ‘Office Stock
Holding’ records (which reflect the accumulation of the stock unit holdings at the end
of the CAP).
For each set of records produced, an additional message will be written which
contains control totals. The control totals will include the following fields:
1. CAP Number
2. Total absolute number of transactions
3. Total absolute value of transaction ‘Quantity’ field
4. Total of absolute value of transaction ‘“SaleValue’ field
COMMERCIAL IN CONFIDENCE Page 9 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
ann Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
The Stock Holding and Cash Account Line Control Total records will be harvested at
the same time as the Stock Holding and Cash Account transactions are harvested and
will be written to a new table in the TPS Host System database. When the TPS Host
system creates the TIP Cash Account sub-file for an outlet a new process will be
added that independently calculates the control totals from the records being generated
in the sub-file and then compares them with the control totals harvested from the OPS.
If there is a discrepancy between the TPS and OPS generated control totals, the
following information will be written to an Exception Report:
1. Outlet FAD code
2. CAP Number
2. The values calculated by the OPS
3. The values calculated by the TPS Host
3.4 Weekly Cash Account Control Total Reconciliation
The end of day procedure which follows the Cash Account Period Rollover will
retrieve the Daily Cash Account Reconciliation Control Totals (see 3.2 above) for the
current Office CAP (including any that took place on the day of the CAP rollover).
These totals will be accumulated to derive a single total for each Cash Account Table
and totals of appropriate tables (such as the Remittance tables and the balance brought
forward for the Receipts table) will be added to the Stock, Payments and Receipt table
control totals. The values generated for the control total of each of the tables will then
be compared with the values generated for the lines recorded for the table during the
production of the Cash Account. Any difference will be identified in a message
written to the message store.
Any error messages will be subsequently harvested and inserted into a new table in
the TPS Host Database. Errors will be output to an error report.
NOTES
1. The reconciliation process will work for normal and extended cash
accounts. Extended CAPs are the same as a normal CAP except that CAP
Number increases by more than 1 and the period covered is more than 7
days
2. The reconciliation process will be unaffected by days when the Outlet is
not trading because processing is covered by resilience already built into
the end of day process.
4 Detailed Design Proposal
4.1 Changes to Message Store
The following new messages will be written by the Counters to support the
Reconciliation process:
COMMERCIAL IN CONFIDENCE Page 10 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref.: PI/DES/002
senes Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
Daily Transaction Control Totals
Daily Cash Account Control Totals
Transaction Errors Detected by Counters
Weekly Cash Account and Stock Holding Control Totals
© © @
Cash Account Reconciliation Errors
4.1.1 Daily Transaction Control Totals
This message will be written by the normal end of day procedure and will contain
control totals that will be harvested and used in the TPS Host to check that the
transactions passed through to TIP reconcile against the totals generated at the outlet.
The message will contain the following attributes:
<Groupld:/ffiff> FAD Code
<Id:nn> Node
<Num:mmmmmmmm> Message number
<Date:dd-mmm-ccyy> Date of message
<Time:hh:mm:ss> Time of message
<Expiry:nnn> Retention period in days
<EPOSSTransaction: Group attribute for EPOSS Transactions
<TranType:DailyTxnCT> Transaction Type for Daily Control
Totals
<TradingDate:dd-mmm-ccyy> Date of EOD Marker
<MessageCount:nnnnnnnn> Number of transaction messages
<QtyCount:mannnnnn> Total of absolute value of Transaction
Quantity field
<ValueCount:nnnnnnnn.nn> Total of absolute value of Transaction
“SaleValue’ field
>
4.1.2 Daily Cash Account Control Totals
This message will be written by the normal end of day procedure and will contain
control totals for each Cash Account Table. The totals will be added together at the
end of the Cash Account Period and used to reconcile against the details on the Cash
Account. The message will contain the following attributes:
<Groupld:ffffff> FAD Code
<Id:nn> Node
<Num:mmmmmmmm> Message number
<Date:dd-mmm-ccyy> Date of message
<Time:hh:mm:ss> Time of message
COMMERCIAL IN CONFIDENCE Page 11 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
Pathway Reconciliation Controls Version: 5S o9i00
<Expiry:nnn> Retention period in days
<EPOSSTransaction: Group attribute for EPOSS Transactions
<TranType:DailyCACT > Transaction Type for Daily Cash
Account Control Totals
<CAP:ce> Cash Account Period
<CATable:t> Cash Account Table No
<MessageCount:nnnnnnnn> Number of transaction messages
<QtyCount:nnnnnnnn> Total of absolute value of Transaction
Quantity field
<ValueCount:nnnnnnan.nn> Total of absolute value of Transaction
“SaleValue’ field
Note: 1. Where a product reports to both a quantity and a value table on the cash
account the quantity and value in the transaction record will be accumulated
separately into the respective Cash Account Table.
2. Although the above structure contains both quantity and value counts the
majority of Cash Account Tables have only one or the other value (the
exception being Table 12). On Quantity-only tables the control total for
value will be zero. On Value-only tables the control total for quantity will
be zero.
CATable “XX” will be a special table set up to hold control totals for exception
transactions that do no map against a valid CA Table entry.
4.1.3 Transaction Errors Detected by Counters
This message will be output where the counter is unable to analyse the transaction in
message store. A new message is output containing the following attributes:
<Groupld:ffffff> FAD Code
<Id:nn> Node
<Num:mmmmmmmm> Message number
<Date:dd-mmm-ccyy> Date of message
<Time:hh:mm:ss> Time of message
<Expiry:nnn> Retention period in days
<EPOSSTransaction: Group attribute for EPOSS Transactions
<TranType:DailyCAErr > Transaction Type for Daily Cash
Account Control Total Errors
<Txnld: Transaction in error — formatted as
Groupld / Id / Num
COMMERCIAL IN CONFIDENCE Page 12 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP y Refi: RUDE?
ane ersion: 0.
Pathway Reconciliation Controls Date 20/09/99
<Group:ffiff> Group Id (FAD Code)
<Id:nn> Node Id
<Num:mmmmmmmm> Message Number
>
<Reason:ttitt> Reason for rejection (e.g. <Reason:No
CA Mapping> )
>
4.1.4 Weekly Cash Account Control Totals
This message will be written when the Cash Account is produced and will contain
control totals that will be harvested and used in the TPS Host to check that the cash
account details and stock details passed through to TIP reconcile against the totals
generated at the outlet. The message will contain the following attributes:
<Groupld:ffffff> FAD Code
<Id:nn> Node
<Num:mmmmmmmm> Message number
<Date:dd-mmm-ccyy> Date of message
<Time:hh:mm:ss> Time of message
<Expiry:mnn> Retention period in days
<EPOSSTransaction: Group attribute for EPOSS Transactions
<TranType: Weekly#CT > Transaction Type for Weekly Cash
Account (tt=CA)/Stock Holding (tt=SH)
Control Totals
<CAP:cce> Cash Account Period
<MessageCount:mnannnnnn> Number of CA Line/Stock Holding
messages
<QtyCount:mnnnannn> Total of absolute value of Transaction
Quantity field
<ValueCount:nnnnnnnn.nn> Total of absolute value of Transaction
“SaleValue’ field
4.1.5 Cash Account Reconciliation Errors
COMMERCIAL IN CONFIDENCE Page 13 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref.: PI/DES/002
spas Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
This message is output where the end of day procedure following the Cash Account
finds that the sum of the Daily Cash Account Control Totals (see section 4.1.2)
captured during the Cash Account Period does not agree with the totals on the Cash
Account. A message will be written where there is an error in the totals for a CA table.
The message will contain the following attributes:
<Groupld:ffff> FAD Code
<Id:nn> Node
<Num:mmmmmmmm> Message number
<Date:dd-mmm-ecyy> Date of message
<Time:hh:mm:ss> Time of message
<Expiry:nnn> Retention period in days
<EPOSSTransaction: Group attribute for EPOSS Transactions
<TranType: WeeklyCAErr > Transaction Type for Weekly Cash
Account Errors
<CAP:cc> Cash Account Period
<CATable:tt> Cash Account Table No
<CAQtyTot:nnnnnn> Total of signed values of the Quantity
field accumulated from the Cash
Account Line records
<CAValueTot:nnnnnn.nn> Total of signed values of the Sale Value
field accumulated from the Cash
Account Line records
<ControlQtyTot:nninnn> Total of signed values of the Quantity
field accumulated from the Daily Cash
Account Control Total records
<ControlValueTot:nnnnnn.nn> Total of signed values of the Sale Value
field accumulated from the Daily Cash
Account Control Total records
CATab “XX” will be a special table set up to hold control totals for exception.
transactions that do no map against a valid CA Table entry. If a message is written for
<CATable:XX>, <CAQtyTot:> and <CAValueTot:> will be null, but
<ControlQtyTot:> and <ControlValueTot:> will contain values.
4.2 Changes to Counters
4.2.1 End of Day Architecture
COMMERCIAL IN CONFIDENCE Page 14 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref.: PI/DES/002
ae Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
In order to ensure that the record set on which the Daily Control Totals are calculated
is fixed at a point in time, the processes for calculating the totals will need to run
AFTER the EOD Marker has been inserted into the message store (since this
delineates the messages for the day). The calculation of the totals will therefore be
carried out within the EOD process using the architecture developed for CSR+ for the
creation and management of “Harvest Trailers’ (see Ref. 2). This will result in the
Control Total messages being written after the EOD Marker but before the EOD
Harvest Trailer message. The resilience of the process remains unchanged since the
EOD process itself will continue to ensure that if the process is interrupted for any
reason, then the generation of the Control Totals and the Harvest Trailer will be
carried out when the system is re-started.
4.2.2 Normal End of Day Processing
The end of day procedure will be extended to scan message store to calculate control
totals and write messages for:
¢ Daily Transaction Control Totals (see section 4.1.1), making sure that absolute
values and quantities are used. These totals will be subsequently harvested and
used by TPS Host to reconcile against the number transactions passed through to
TIP. Some transactions are not passed through to TIP so these will not be
included in the control totals: the following transactions will not be included:
- Transfers
- Transfer settlements
- Remittance settlements
- Non accounting data settlements
- Parcel traffic settlements
The identification of the products to be excluded in this way will be controlled by
the use of a piece of reference data (persistent object) in the message store.
¢@ Daily Cash Account Control Totals (see section 4.1.2), making sure that signed
values and quantities are used. These totals will subsequently be used by the
counter software to reconcile the Cash Account. Totals will be written for the
following CA Tables
- 00 Receipts (Values)
- 10 Payments (Values)
- 07 Discrepancies (Values)
- 20 Cash Stock and Vouchers in Hand (Table 5) (Values)
- 30 Receipts (Quantities)
- 40 Payments (Quantities)
- 50 Stock in Hand Breakdown (Table 5b) and Suspense Account Tables
(Values)
- 60 Remittances from other Offices (Values)
COMMERCIAL IN CONFIDENCE Page 15 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref. PI/DES/002
wpe ge Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
- 61 Receipt of stock from SSO (Values)
- 70 Stock Returns to SSO (Values)
- 80 Remittances to other Offices (Values)
- 90 Girobank Transaction Breakdown (Table 10f) and Parcel Traffic
(Table 12) (Values and Quantities)
- 91 Number of Transactions (Table 10g) (Quantities)
A new message will be written to message store (before the EOD Harvest Trailer) for
any transaction that is found to be in error (see section 4.1.3).
Totals for error transactions are added together and included in a special Daily Cash
Account Control total for CA Table “XX”.
4.2.3 Cash Account Processing
When the Cash Account “Trial Report’ is produced the processing will be extended to
calculate control totals and write a message for:
¢@ Weekly Cash Account Control Total (see section 4.1.4), making sure that signed
values and quantities are used. This total will be subsequently harvested and used
by TPS Host to reconcile against the number of cash account lines passed through
to TIP.
When the Cash Account *Roll-Over’ is executed the processing will be extended to
calculate control totals for the outlet stock holdings and write a message for:
@ Weekly Outlet Stock Holding Control Total (see section 4.1.4), making sure that
signed values and quantities are used. This total will be subsequently harvested
and used by TPS Host to reconcile against the number of stock holding records
passed through to TIP.
4.2.4 End of Day Processing Following Cash Account
The end of day procedure will be extended as described in Section 3.4 to retrieve the
Daily Cash Account Reconciliation Control Totals (see section 4.1.2). The total for
each table on each day will be accumulated to give a single total for each table for the
Cash Account Period. The system will then perform the following additional
calculations:
1. The totals of Table 5(b), 2 and 2(a) will be added to the control total for Table
5;
2. The total of Table 3 will be deducted from the control total for Table 5;
The Table 5 Control Total from 1&2 above will be added to the Control Total
of the Payments Table (Table 10);
4. The Control Total of the Discrepancy Table (Table 07) will be added to the
Control Total of the Payments Table (Table 10);
5. The Control Total for Tables 6 and 6(a) will be added to the Control Total of
the Receipts Table (Table 00);
we
COMMERCIAL IN CONFIDENCE Page 16 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
ae Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
6. The Balance Brought Forward value for the Current CAP will be added to the
control total of the Receipts Table (Table 00);
7. The Control Total of Tables 8 and 9 will be added to the Control Total of the
Payments Table (Table 10).
These values will then be compared against each Cash Account Table total
accumulated from the Cash Account line records written during the production of the
Cash Account.
An error messsage will be written (see 4.1.5) when the total for any table does not
match the Control Total against which it is being compared.
4.3 Changes to the Oracle Database
The following tables will be added to the database which is populated by the
Harvester and processed by TPS Host:
@ Daily Transaction Totals
Cash Account Total Lines
+
@ Stock Detail Total Lines
¢@ Exception Transaction
+
Control Exceptions
4.3.1 Daily Transaction Totals
This is a table of control totals which will be populated nightly by the harvester from
the Transaction Stream Control Total message. It will contain the following data
items:
@ FAD Code
@ Trading Date
¢ Total Number of Transactions
¢ Total of absolute value of transaction “Quantity” field
¢ Total of absolute value of transaction “Sale Value” field
4.3.2 Cash Account Total Lines
This is a table of control totals which will be populated by the harvester from the
weekly CA Stream Control Total message. It will contain the following data items:
FAD Code
CAP Number
Total Number of lines
Total of absolute value of transaction “ Qty” field
oo ¢ © © +
Total of absolute value of transaction “Sale Value” field
COMMERCIAL IN CONFIDENCE Page 17 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref.: PI/DES/002
wp ge Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
4.3.3 Stock Detail Total Lines
This is a table of control totals which will be populated by the harvester from the
weekly Office Stock Holding Control Total message. It will contain the following
data items:
@ FAD Code
@ CAP Number
@ Total Number of messages
¢ Total of absolute value of transaction “Quantity” field
+
Total of absolute value of transaction “Sale Value” field
4.3.4 Exception Messages
This table will be used to hold details of messages where exception conditions have
been detected by the Counters and/or the Harvester. For example:
¢ End of Day process may not be able to map a particular transaction into one of
the CA tables (see section 4.1.3)
¢ The Harvester is unable to convert a particular data item because the content in
Message Store is not compatible with its definition in the Oracle database
The table will contain the following data items:
@ FAD Code
¢ Transaction Date
¢ Transaction Time
¢ Transaction Identifier
¢ Reason for rejection
4.3.5 Control Exceptions
This table will be used to hold details where the Cash Account Totals calculated by
the Counters do not correspond to the Control Totals captured by the Counters from
the transactions processed during the Cash Account Period. It will contain the
following data items:
FAD Code
CAP Number
CA Table Number
Accumulated signed total of ‘Qty’ values from Cash Account Line Records
Accumulated signed total of “Sale Value’ values from Cash Account Line Records
Accumulated signed total of ‘Qty’ values from Daily Cash Account Control Totals
oo ¢ © © © ©
Accumulated signed total of “Sale Value’ values from Daily Cash Account
Control Totals
COMMERCIAL IN CONFIDENCE Page 18 of 39
ICL
Pathway Reconciliation Controls
POL00325269
POL00325269
Logical Design for EPOSS/TIP Ref.: PI/DES/002
Version: 0.7
Date: 20/09/99
4.4
4.4.1
4.4.2
4.5
4.5.1
CA Table Number “XX” will be a special table set up to hold control totals for
exception transactions that do no map against a valid CA Table entry: Cash Account
attribute entries will be null, but Control Total entries will contain values.
Changes to TPS Agent
The Harvester will populate the new tables in the Oracle database: there may be
several entries for each FAD code.
Daily Processing
For each outlet that is harvested TPS Agent will process the Transaction Stream
Control Totals from message store and will populate the Daily Transactions Totals
table in the Oracle database.
Any transaction which it cannot harvest (because of invalid data) will be written to the
Exception Messages table (see section 4.3.4).
Any Transaction Error detected by the counter (see section 4.1.3) will also be written
to the Exception Messages table (see section 4.3.4).
Processing of Cash Account Data
For each outlet that is harvested TPS Agent will:
@ process Weekly Cash Account Stream Control Total(s) from message store to
populate the Cash Account Total Lines table in the Oracle database
process Office Stock Holding Control Total(s) from message store to populate the
Stock Detail Total Lines table in the Oracle database
Any line which it cannot harvest (because of invalid data) will be written to the
Exception Messages table (see section 4.3.4).
Any reconciliation error detected by the Counters (see 3.4 above) will be written to
the Control Exceptions table.
Changes to TPS Host
Daily Processing
For each outlet, TPS Host will
«@ Add up number of EPOSS transactions which have been harvested
¢@ Add up absolute value of transaction quantity field in the harvested transactions
@ Add up absolute value of transaction sale value field in the harvested transactions
o
Compare calculated totals against the control totals in the Daily Transaction Totals
total
COMMERCIAL IN CONFIDENCE Page 19 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
wp ge Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
¢ Output an exception report for those outlets which don’t balance containing both
sets of totals for each outlet (see 4.6.1 below)
Output an exception report of exception transactions reported by the Harvester
(see 4.6.2 below)
NOTES:
1. For control purposes a reversal will be treated in the same way as the transaction
being reversed. E.g. if the original transaction was for quantity 6 at a sales value of
£1.20, then the combination of the reversed and reversal transactions would
increment the number of transactions by 2, transaction quantity by 12, and sales
value by £2.40.
2. “Event” transactions will be ignored from the totals
4.5.2 Processing of CAP Stream Control Totals
For each outlet, TPS Host will
¢@ Add up number cash account lines which have been harvested
@ Add up absolute value of cash account line
¢@ Compare calculated totals against Weekly CAP Stream Control Totals
+
Output an exception report for those outlets which the Host detects as not
balancing (see 4.6.3 below)
¢@ Output an exception report for those outlets which Counter has reported as not
balancing (see 4.6.4 below)
¢ Output an exception report of exception cash account lines reported by the
Harvester (see 4.6.2)
4.5.3 Processing of Office Stock Holding Control Totals
For each outlet, TPS Host will
¢@ Add up number of stock detail lines
¢@ Add up absolute quantity of stock detail lines
¢@ Add up absolute value of stock detail lines
@ Compare calculated totals against Weekly Office Stock Holding Control Totals
°
Output an exception report for those outlets which the Host detects as not
balancing (see 4.6.3 below)
¢ Output an exception report of exception stock detail lines reported by the
Harvester (see 4.6.2)
4.6 Exception Reports
The following reports will be produced by the TPS Host:
¢ Host Detected Transaction Control Errors
COMMERCIAL IN CONFIDENCE Page 20 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref. PI/DES/002
ae Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
Harvester Detected Errors
@ Host Detected Cash Account Control Errors
# Counter Detected Reconciliation Errors
All these reports will be routed to the Business Support Unit within ICL Pathway who
will investigate each error. Any lost / missing transactions will be communicated to
POCL.
4.6.1 Host Detected Transaction Control Errors
This report is produced daily showing details for any outlet where the control totals
for the transactions output by the Host to POCL TIP do not match the Daily
Transaction Totals calculated by the Counters. The following data is reported for each
exception:
@ FAD Code
@ Trading Date
¢@ Control Totals calculated by Host
@ Control Totals calculated by Counter
An “END OF REPORT” message will appear at end of the report even if there are no
errors reported.
4.6.2 Message Store Errors
This report is produced to list exception conditions detected by the Harvester and/or
Counter when failing to process one of the messages in message store. The following
data is reported for each exception:
@ FAD Code
@ Trading Date
¢ Transaction Time
Content of message
@ Reason for Rejection
An “END OF REPORT” message will appear at end of the report even if there are no
errors reported.
4.6.3 Host Detected Cash Account Control Errors
This report is produced daily showing details for any outlet where the Control totals
for the number of entries on the Cash Account output by the Host to POCL TIP do not
match the Control Totals calculated by the Counters.
The following data is reported for each exception:
@ FAD Code
COMMERCIAL IN CONFIDENCE Page 21 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
wpe ge Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
@ Trading Date
@ Cash Account Period
¢@ Absolute Control Totals for Cash Account Lines calculated by Host
¢@ Absolute Control Totals for Cash Account Lines calculated by Counter
@ Absolute Control Totals for Stock Detail Lines calculated by Host
¢@ Absolute Control Totals for Stock Detail Lines calculated by Counter
An “END OF REPORT” message will appear at end of the report even if there are no
errors reported.
4.6.4 Counter Detected Reconciliation Errors
This report is produced daily showing details for any outlet where the accumulated
Daily Transaction Control totals for the cash account period do not match the totals on
the Cash Account produced by the Counters.
The following data is reported for each exception:
FAD Code
Trading Date
Cash Account Period
Cash Account Table Number
Cash Account Details calculated by Counter
oo ¢ © © © @
Control Totals for Cash Account calculated by Counter
CA Table Number “XX” will be used to report control totals for exception
transactions that do no map against a valid CA Table entry.
An “END OF REPORT” message will appear at end of the report even if there are no
errors reported.
COMMERCIAL IN CONFIDENCE Page 22 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
anid Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
5 Data Flow Diagrams
5.1 Daily Processing
The following diagram illustrates the data flow of the daily reconciliation processing:
@ Counter End of Day will process the transactions in Message Store and generate
additional messages for Daily Transaction Control Totals and Daily Cash Account
Control Totals
@ A message will also be written to Message Store for any transaction which cannot
be mapped into one of the cash account tables in the Daily Cash Account Control
Totals
@ The Daily Transaction Control Totals will be harvested and passed through to TPS
Host where they will be compared against the transactions output to TIP. Any
discrepancy will be reported as Host Detected Transaction Control Errors
¢ Any transactions which cannot be extracted by the Harvester will be posted to an
error table in the host database. This will also contain Counter Detected
Transaction Errors. This table will be processed by the host and they be reported
as Message Store errors.
COMMERCIAL IN CONFIDENCE Page 23 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
a Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
ouTter.
POST OFFICE
Transactions
4 1PS Daly Prosessg as
TPs
ia [10% AT TEORTOTAL
aunt ransac ‘Counter En of Day reads message si”
lnmessege store hd generates new total message
‘Transaction oy
‘Day Tsisaction
Cantal Totals
Dally Gash Account
Com Tela Counter Detected
‘Teansactions / Transaction bros
TH]MESBAGESTORE .
Daly Transaction — a
Transactions Conte Totals ouefGe petected
Fransscion Errors
42 [HARVEST
FPS Agent Rawwests WanisaconI
and new totals message to Ort
Satabace
Harvester Detete
‘Transaction Coiinter Detected
aly Transactions” ——_Transtin Eors
Conta Tota
(Ti2/ORACLE-DATABASE (T13I ORACLE-DB-TOTAL
J aiy tansacton aver Detected I
Transaction ont Tatas I
J Counter Detected
12 IHOST_PROG ‘Transaction Errors:
facts asactons tom Oracle
produces fue for TIP. At sa
Jcompares tla sent to TIP against Totals Mess
I
2 eee I
‘TBS Host produces exception ep)
I feos tected by Haresior I
I I
“Transaction
Message Store
Eros
- "Hast Detected Transact ~ -
Gontrol Eros
Poor ® ‘esu™
TiP.sysTeM BUSINNES SUPPORT
unt
COMMERCIAL IN CONFIDENCE Page 24 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP v Ref.: RUDE S002
ae ersion: 0.
Pathway Reconciliation Controls Date: 20/09/99
5.2 Cash Account Processing
The following diagram illustrates the data flow at the time of Cash Account Period
rollover
¢@ The Counters will generate additional control messages representing the Cash
Account Lines and Stock Details
¢ Counter End of Day will compare the Cash Account against the accumulated
totals for the Daily Cash Account Control Totals. Any reconciliation errors are
reported to Message Store
¢ Counter Detected Reconciliation Errors will be harvested and passed through to
the TPS Host where they will reported
¢@ The Control Messages for the Cash Account Lines and Stock Details will be
harvested and passed through to TPS Host where they will be compared against
the Cash Account Details output to TIP. Any discrepancy will be reported as Host
Detected Cash Account Control Errors
@ Any Cash Account Line or Stock Details Line which cannot be extracted by the
Harvester will also posted to an error table in the host database. This table will be
processed by the host and they be reported as Message Store errors.
COMMERCIAL IN CONFIDENCE Page 25 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Ref: PIDES/002
wipe Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
/ 1 Dat
a Reconstr
/ /
Sotines
Seal wet he
etc coca
(CAC noe "cachet
6] SRACIE-DRCKCUNES
Courte Det
caclnes I ST Loe
COMMERCIAL IN CONFIDENCE Page 26 of 39
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PYDES/002
Pathway Version: 0.6
Date: 17/09/99
POL00325269
POL00325269
6.1
REPORT LAYOUTS
Host Detected Transaction Control Errors
0 ° 0 ° 0 0 ° ° ° 1 1 1 1
1 2 3 4 5 6 7 8 9 0) 1 2 3
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
TPS RECONCILIATION REPORTS RUN DATE / TIME: dd/mm/yyyy hh:mm:ss PAGE NO: 22229
PROGRAM: NNNN
Host Detected Transaction Control Errors
outlet Trading Date Number Absolute Quantity Absolute value
28000 dd/mm/yyyy TPS Total Brsvcrstsrsrsred 22000000006 202200000
Counter Total xx: xX x KKK
200000 dd/mm/yyyy TPS Total xx as 3K
Counter Total HK 2000000000 OOOOH
*** END OF REPORT *#*
Notes
The report details lines will be in the following sort sequence:-
Ascending Outlet / Trading date / Transaction Date
COMMERCIAL IN CONFIDENCE Page 27 of 39
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Pathway
Version: 0.
6
Date: 17/09/99
POL00325269
POL00325269
6.2 Message Store Errors
0 o 0
1 2 3
12345678901234567890123456789012345678901
outlet Trading Transaction
Date Date
xxxxxx dd/mmi/yyyy dd/mm/yyyy
xxxxxx dd/mm/yyyy dd/mm/yyyy
*** END OF REPORT ***
Notes
0
4
Transaction
Time
hhimm: ss
0 0
5 6
TPS RECONCILIATION REPORTS
0 0 0 1 1 1 1
7 8 9 ° 1 2 3
RUN DATE / TIME: dd/mm/yyyy hh:mm:ss PAGE NO: 22229
PROGRAM: NNNN
Message Store Errors
Reject
Reason
RRUAKKKKAKAKAKAREN
RRXKAXRKKAKAKAAKEK
Message
ANKNAAAARRAAA KAKA KARA AKI
mH
RH MKRKKAKKAAAAAKN,
XMRNKKK NAKA MAAN AANA EKKO IH I
MXMNXAAAAAAA AA AK KAKA IKKE KR IK,
RXXNAKAKAAAKA KUMAR ARR KEAA AK KEKE AK RXR ERR RMR EKER
RXKKKANAAA AHN AM AKAIKE AN KAI RII I I
HSE II OCI III I II
XXKRNRAKAMAK AM AMAKKEKKARNARKMKRERARA RAK KAR RAMA KKK KERR,
RXKRKKA AKAMA MKKKKRAKARAK KAKA EM RRK KARE RRNA HHA KKK REI
3456789012345 678901234567890123456789012345678901234567890123456789012345 6789012345678 9012
COMMERCIAL IN CONFIDENCE
Page 28 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref. PI/DES/002
Version: 0.6
Pathway Date: 17/09/99
The report details lines will be in the following sort sequence:-
Ascending Outlet / Trading date / Transaction Date / Transaction Time
COMMERCIAL IN CONFIDENCE Page 29 of 39
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Version: 0.6
Pathway Date: 17/09/99
POL00325269
POL00325269
6.3 Host Detected Cash Account Control Errors
0) 0 0 0 0 0 0 0 Q 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
CONCILIATION REPORTS RUN DATE / TIME: dd/mm/yyyy hh:mm:ss PAGE NO: 22229
PROGRAM: NNNN
Host Detected Cash Account Control Errors
outlet Trading Date CAP Number Number Absolute Quantity Absolute Value
HER dd/mm/yyyy xx CAC Lines ~ TPS Total RRRXRXRX RXKKKERNXK
CAC Lines - Counter Total HRRXKERX RXXKAXKARK
STX Lines ~ TPS Total RXXHRXEX XXKXRXHRNE XXKKEKERK
STX Lines - Counter Total KRKRKERX AMKRXRHREX RRKKKERKRH
dd/mmn/yyyy xx CAC Lines - TPS Total XRXRRER RXAXRRRKKK
CAC Lines - Counter Total XE % RRMKKKRRKK
STX Lines - TPS Total KXRRXREN MXKAXKKXRE RRRKKXRXXX
STX Lines - Counter Total KRRKKERK RRXKXRRRAK XXXKRRERKX
*** END OF REPORT ***
COMMERCIAL IN CONFIDENCE Page 30 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Version: 0.6
Pathway Date: 17/09/99
Notes
The report details lines will be in the following sort sequence:-
Ascending Outlet / Trading date / Transaction Date
COMMERCIAL IN CONFIDENCE Page 31 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PUDES/002
Pathway Version: 0.6
Date: 17/09/99
6.4 Counter Detected Reconciliation Errors
oO i) oO oO oO 0 oO oO ) 1 1 1 1
1 2 3 4 s 6 7 8 9 i) 1 2 3
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
TPS RECONCILIATION REPORTS RUN DATE / TIME: dd/mm/yyyy hh:mm:ss PAGE NO: 22229
PROGRAM: NNNN
Counter Detected Reconciliation Errors
outlet ng Date CAP Number CAP Table Number Signed Value Total
RMX dd/mm/yyyy xx xX Cash Account
Control
XRKEXK dd/mm/yyyy xx KX Cash Account RXXXXERY
Control HXXR
*+* END OF REPORT ***
Notes
The report details lines will be in the following sort sequence:-
Ascending Outlet / Trading date / Transaction Date
COMMERCIAL IN CONFIDENCE Page 32 of 39
ICL
Pathway
Logical Design for EPOSS/TIP Reconciliation Controls
Version: 0.6
Date: 17/09/99
Ref: PI/DES/002
POL00325269
POL00325269
6. Failure Scenarios
This section describes how the Reconciliation Process will function under various failure scenarios.
Failure Condition
Scenario when failure occurs prior to
Initiation of Process
Scenario when failure occurs during the
Execution of Process
Scenario when failure occurs for protracted
period
1. End of Day—
Non gateway
node failure
Note that the most
common scenario for
this is the Postmaster
turning off the power
to an unused counter
Pc.
End of Day will run in the nodes which are
running:
Private end of day markers will be
written for each live node
¢ No public end of day markers are written
@ No Daily Transaction Control Totals
written
# No Daily Cash Account Control Totals
written
# No CA Reconciliation is carried out if it
is a Cash Account day
¢ No transactions are harvested
¢ No transaction details are output to TIP.
If the node is restored before midnight (local
time) EOD will run as normal for that day. It
may be that such “late EODs” will not be
harvested until the next day since the EODs
may miss the 20:30 TPS harvester cut-off
time. (See also 4 — Wan failures)
If node is restored after midnight EOD will
run on the day it is restored at the normal
Ifa non gateway node fails whilst EOD is
running then EOD fails to complete and
¢ No private end of day markers will be
written for node that dies
* No public end of day markers are written
¢@ No Daily Transaction Control Totals
written
# No Daily Cash Account Control Totals
written
# NoCA Reconciliation is carried out if it
is a Cash Account day
¢ No transactions are harvested
¢ No transaction details are output to TIP.
If the node is restored before midnight (local
time) EOD will run as normal for that day. It
may be that such “late EODs” will not be
harvested until the next day since the EODs
may miss the 20:30 TPS harvester cut-off
time. (See also 4 — Wan failures)
If node is restored after midnight EOD will
run on the day it is restored at the normal
Whilst node is down:
¢ No private end of day markers will be
written for dead node
No public end of day markers are written
¢@ No Daily Transaction Control Totals
written
@ No Daily Cash Account Control Totals
written
# NoCA Reconciliation is carried out
¢ No transactions are harvested
# No transaction details are output to TIP.
Note that if a node is down when EOD is
attempted on the gateway no further attempt
to write EOD will be made until “tomorrow’s
EOD time”
When the node is restored a private EOD
marker will be inserted at the normal EOD.
time.
System recovers when all nodes restored as
described below
COMMERCIAL IN CONFIDENCE
Page 33 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Pathway Version: 0.6
Date: 17/09/99
time for EOD time for EOD
3. End of Day — End of Day will not run if gateway server is I Ifnode goes down then end of day will fail: I As above
eae node down: @ No public end of day markers are written I System recovers when all nodes restored:
# No public end of day markers are written
¢# No Daily Transaction Control Totals
written
# No Daily Cash Account Control Totals
written
¢# NoCA Reconciliation is carried out if it
is a Cash Account day
No transactions are harvested
¢ No transaction details are output to TIP.
If the node is restored before midnight (local
time) EOD will run as normal (see above)
¢ No Daily Transaction Control Totals
written
@ No Daily Cash Account Control Totals
written
¢# NoCA Reconciliation is carried out if it
is a Cash Account day
No transactions are harvested
¢ No transaction details are output to TIP.
If the node is restored before midnight (local
time) EOD will run as normal (see above)
+
Public end of day markers will be
inserted at appropriate places
Daily Transaction Control Totals written
for each end day that node was down
CA Reconciliation is carried out if it is a
Cash Account day
Daily Cash Account Control Totals
written for each end day that node was
down
All missing days will be harvested
Daily Transaction Control Totals will be
checked by TPS Host
Transaction files will be passed onto TIP.
(AIL“ missing” Transactions will be
harvested with the “correct” Trading date)
w
End of Day -
LAN failure
Same as for failure in non-gateway node (see
1 above)
Same as for failure in non-gateway node (see
I above)
Same as for failure in non-gateway node (see
1 above)
4. End of Day—
WAN failure
This condition is not
detected at the
counter. It is only
visible at the data
Centre
End of Day will run if WAN is down:
¢ Public end of day markers will be
inserted at appropriate places
¢ Daily Transaction Control Totals written
¢@ Daily Cash Account Control Totals
written
Reconciliation checks will be carried out
End of Day will continue to run if WAN goes
down:
¢ Public end of day markers will be
inserted at appropriate places
Daily Transaction Control Totals written
@ Daily Cash Account Control Totals
written
During period of WAN failure:
+
Public end of day markers will be
inserted at appropriate places
Daily Transaction Control Totals written
Daily Cash Account Control Totals
written
Reconciliation checks will be carried out
COMMERCIAL IN CONFIDENCE
Page 34 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Pathway Version: 0.6
Date: 17/09/99
if CA day * Reconciliation checks will be carried out if CA day
¢ No transactions are harvested ifCA day ¢ No transactions are harvested
4 No transaction details are output to TIP, I * No transactions are harvested + No transaction details are output to TIP.
When WAN recovers: ¢ No transaction details are output to TIP. When WAN recovers:
4 Allmissing days will be harvested When WAN recovers: ¢ All missing days will be harvested
Daily Transaction Control Totals will be I * /!! missing days will be harvested © Daily Transaction Control Totals will be
checked by TPS Host # Daily Transaction Control Totals will be checked by TPS Host
4 Transaction files will be passed onto TIP checked by TPS Host + Transaction files will be passed onto TIP
Transaction files will be passed onto TIP
5. End of Day — NA Node rebuilding for a non gateway node will I N/A
Node rebuilding have no effect on end of day and details will
following failure be harvested to TIP in the normal way
Node rebuilding of gateway node will delay
end of day processing until rebuilding is
complete. Then end of day will run and
harvesting will run as normal.
6. EndofDay- I N/A Messages are not physically committed until I N/A
Application
failure
EOD has completed successfully. le. When
the last message has been written to the
message store.
Service will automatically restart when the
system is re-booted or the overnight reload of
desktop takes place
7. Cash Account
Production and
Rollover — Non-
gateway node
failure
Cash Account Production can proceed on
gateway node so long as:
¢ All stock units have been rolled over
@ User says OK to proceed when warned
Failure of a non-gateway node during the
production of the cash account will cause
Cash Account to fail.
However production of the Cash Account can
be restarted on the gateway node: (or this
During period of node failure:
Outlet can roll over and process as
normal (see column 1)
¢@ Cash Account can be produced
COMMERCIAL IN CONFIDENCE
Page 35 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref. PI/DES/002
Pathway Version: 0.6
Date: 17/09/99
that all nodes are not available node when back on line). @ Weekly Cash Account Control Totals
But subsequent end of day will not run. Thus: I But subsequent end of day will not run. Thus: ean be written
Outlet will roll over and process as ¢ Outlet will roll over and process as * No cash account details will be harvested
normal normal ¢@ No cash account details will be output to
Cash Account will be produced Cash Account will be produced TIP.
# Weekly Cash Account Control Totals I # Weekly Cash Account Control Totals I When non-gateway node is restored the
, : system recovers when next EOD is run:
written written
# Noccash account details will be harvested I # No cash account details will be harvested I * Al! missing cash account details and
totals will be harvested
+ Noah account details will be output to I + Noah account details will be output to # Stock Holding and Cash Account Line
: Control Totals will be checked by TPS
Host
Cash account details will be output to
TIP.
¢ CA Reconciliation is carried out if it is a
Cash Account day
8. Cash Account I N/A CA production can proceed on any other As for 7 above
Production and
Rollover —
gateway node
failure
node.
As for 7 above.
Production and
9. Cash Account As for (7) above
Production and
Rollover - LAN
failure
10. Cash Account During period of WAN failure: Same as column I During period of WAN failure:
COMMERCIAL IN CONFIDENCE
Page 36 of 39
ICL
Pathway
Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Version: 0.6
Date: 17/09/99
POL00325269
POL00325269
Rollover - WAN
failure
Outlet will roll over and process as
normal
Cash Account will be produced
Weekly Cash Account Control Totals
written
No cash account details will be harvested
No cash account details will be output to
TIP.
When WAN recovers:
¢ Outlet will roll over and process as
normal
# Cash Account will be produced
# Weekly Cash Account Control Totals
written
¢@ Weekly cash account reconciliation will
be carried out at outlet
# No cash account details will be harvested
¢ No cash account details will be output to
TIP.
4 All missing cash account details and
totals will be harvested When WAN recovers:
Stock Holding and Cash Account Line 4 All missing cash account details and
Control Totals will be checked by TPS totals will be harvested
Host Stock Holding and Cash Account Line
¢ Cash account details will be output to Control Totals will be checked by TPS
TIP. Host
¢ Cash account details will be output to
TIP.
ii. Cash Account I N/A Node rebuilding for a non gateway node will_I N/A
Production and have no effect on CAP rollover and details
Rollover - Node will be harvested to TIP in the normal way
ee ue Node rebuilding of gateway node will delay
8 CAP rollover until rebuilding is complete.
13. Cash Account I N/A IF these do not complete successfully, then I N/A
Production and
Rollover ~
Application
they can be re-invoked
Since harvesting is based on “ trailer
messages” written at the end of the process,
COMMERCIAL IN CONFIDENCE
Page 37 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Pathway Version: 0.6
Date: 17/09/99
failure then the harvester should only pick up the
successfully completed Rollovers and cash
Account reports
There are checks to prevent 2 Rollovers
being done for the same week and 2 cash
Accounts to be produced.
13. Agent &
Harvester
processing —
application
failure
Harvesters consider the following types of
failure :-
Riposte failures. If these failures are
“expected” failures such as Riposte has died,
then the agent will die leaving another
instance of the agent to tidy up The chunk
may well be marked as “Failed” (thus
requiring manual intervention by CFM before
recovery), since if Riposte has died it is likely
that other instances of the agent would have
the same problem
Oracle failures. If these failures are
“expected” failures such as Oracle having
died then the agent will die leaving another
instance of the agent to tidy up The chunk
may well be marked as “ Failed” (thus
requiring manual intervention by CFM before
recovery), since if Oracle has died it is likely
that other instances of the agent would have
the same problem
Unexpected Oracle failures. These are
assumed to be data failures, and so a message
is logged to the Oracle database and reported
by the Host (see 5.2)
A
14, Agent &
Harvester
COMMERCIAL IN CONFIDENCE
Page 38 of 39
POL00325269
POL00325269
ICL Logical Design for EPOSS/TIP Reconciliation Controls Refi PI/DES/002
Pathway Version: 0.6
Date: 17/09/99
processing ~
normal interface
failure
15. File transfer —
application
failure
To be supplied
To be supplied
To be supplied
COMMERCIAL IN CONFIDENCE
Page 39 of 39
Second Supplemental Agreement Annex to Schedule 2
POL00325269
POL00325269
Acceptance Incident Analysis Form
To be completed by the ICL Pathway Acceptance Manager:
to be given to the Horizon Acceptance Incident Manager
Acceptance Incident Number (1)
378
Analysis Sequence Number (2)
‘Acceptance Test Name (3)
TIP Interface
‘Analysed Incident Severity (4)
High / Medium / Low (4)
Medium
Authority (5)
Analysis of Acceptance Incident (6)
Fix applied 9-10/8
Incidents since notified to TIP 908 are earlier repeats.
Please see document CR/ACD/378 v0.3
robust against such occurrences.
Incident TIP 916, which has similar symptoms but a different root cause is being diagnosed and the system made
Number of continuation pages
Clearance Action (7)
AI.
Pathway will continue analysis of TIP incident 916, with a view to fix as soon as possible.
The initial fix for TIP 916 will be implemented, after which Pathway seeks this AI to be recategorised as Low. When
the final fix has been implemented and monitored as successful for two weeks, Pathway will seek the closure of the
[Number of continuation pages
I Acceptance Incident Status (Open
" [Agreed Resolution Plan
Analysed Retest/Recommended for KPR (8))
I Signatures:
I propose the Clearance Action
and Incident Status described
above P. John Pope
16-Sep-99]
T accept / reject the Clearance
Action and Incident Status
described above
Date:
Date:
IHorizon Acceptance Incident Manager
DSS Acceptance Manager
POCL Business Assurance i
Date:
Version 1.0
loft
24 September 1999
ICL Pathway
Acceptance Deposition
Acceptance Incident 378
POL00325269
POL00325269
Ref: CR/ACD/378
Version: 0.3
Date: 16/9/99
Document Title:
Document Type:
Abstract:
Status:
Distribution:
Author:
Comments to:
Comments by:
Acceptance Resolution Plan for Acceptance Incident 378
Acceptance Resolution Plan
This document contains ICL Pathway’s Resolution Plan in
respect of Acceptance Incident 378.
Issued
Expert:
Peter Copping
ICL Pathway:
Terry Austin
Library
POCL:
John Meagher
Min Burdett
Jeff Austin
Calum Craig
P John Pope
Pathway list
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 1 of 5
POL00325269
POL00325269
ICL Pathway Acceptance Deposition Ref: CR/ACD/378
. Version: 0.3
Acceptance Incident 378 Date: 16/9/99
0 Document control
0.1. Document history
Version Date Reason
0.1 20/8/99 Initial draft for comments
0.2 25/8/99 Version for the Expert and workshop 26/8
0.3 16/9/99 Updated.
0.2 Approval authorities
Name Position Signature Date
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
0.3. Associated documents
Reference Vers Title Source
AI378 TIP Incident Status Report Pathway
0.4 Abbreviations
TMS
TIP
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 2 of 5
POL00325269
POL00325269
ICL Pathway Acceptance Deposition Ref: CR/ACD/378
. Version: 0.3
Acceptance Incident 378 Date: 16/9/99
0.5 Table of content
1 PURPOSE
2 SUMMARY
3. CRITERIA
4 POCL POSITION
5 PATHWAY POSITION
5.1 FURTHER ANALYSIS FROM PATHWAY
5.2 RESOLUTION
5.3. CLEARANCE ACTION
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 5
POL00325269
POL00325269
ICL Pathway Acceptance Deposition Ref: ~CR/ACD/378
Version: 0.3
Acceptance Incident 378 Date: 16/9/99
1 Purpose
This document contains ICL Pathway’s Resolution Plan in respect of Acceptance
Incident 378.
2 Summary
ICL Pathway distributed the fix to the original incident, of which there were five
occurrences, on 9-10 August. ICL Pathway is preparing an extension to this fix to
cover a similar incident.
3 Criteria
The Criterion under test is 831/1.
“The Contractor shall support interfaces from TMS and Outlets to Transaction
Information Processing TIP”.
4 POCL position
Based upon the minutes of the Acceptance Board Meeting of 18 August 1999, POCL,
contended that:
“rectification activity had not been successful and further analysis was awaited from
Pathway”.
5 ‘Pathway position
5.1 Further analysis from Pathway
The original incident that gave rise to AI 378 was diagnosed and a fix was distributed
to the counters on 9-10 August. There had been two occurrences.
A further three incidents were reported all relating to the period before 10 August.
A further incident with similar symptoms, but a different root cause (TIP 916) has
been reported and is being diagnosed and the system made robust against such
occurrences.
5.2 Resolution
ICL Pathway will continue to monitor for such incidents and fix them. The incidents
are tracked at the detailed level in 4/378 TIP Incident Status Report.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 5
POL00325269
POL00325269
ICL Pathway Acceptance Deposition Ref: CR/ACD/378
I Version: 0.3
Acceptance Incident 378 Date: 16/9/99
5.3. Clearance action
The clearance plan is to monitor the live system for any re-occurrence of such
incidents. The fix implemented on 9-10 August has been in monitored as successful
for over a month.
The fix for TIP 916 is in preparation and will be monitored for a period of two weeks
after implementation.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 5
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
70 be completed by the ICL Pathway Acceptance Mander
__Ito be given to the Horizon Acceptance Incident Manager
Acceptance Incident Analysis Form —
Acceptance Incident Number (1) Analysis Sequence Number (2)
390
Acceptance Test Name (3)
APS
Analysed Incident Severity (4) High / Medium / Low (4) ‘Authority (5)
e : oe oS Medium
Analysis of Acceptance Incident (6)
IPOCL 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 transactions. 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 each data item being entered from the
receipt.
‘Number of continuation pages _
Clearance Action (7)
Additional response 17/08/99.
In addition to the CSR+ facilities described above, the following change will be introduced into APS by the end of
INovember 1999.
Following a crash, and when undertaking Session recovery or Disaster recovery (i. for those transactions where a
system receipt has been produced), the user will still have the option of reserving a gap of transactions and
delaying recovery to a more convenient time. However should a second crash occur, the clerk will be forced to
undertake recovery of all those deferred transactions and then any other transactions that may have occurred as a
result of the second crash.
‘The recovery of transactions produced during fall back for which manual receipts are produced are not affected by
these changes.
IAdditional response 31/08/99.
This introduction of the above change to APS by the end of November 1999 has been agreed by POCL and this
Analysis Form documents that agreement in accordance with the action agreed at the Acceptance Workshop on
25/8/99.
Additional response 16/9/99
‘This AI has been recategorised as Medium with an agreed Resolution Plan.
Version 1.0 lof2 24 September 1999
POL00325269
POL00325269
Second Supplemental Agreement Annex to Schedule 2
Agreed Resolution Plan
ees
I propose the Clearance Action
and Incident Status described
31/08/99 & 16/9/99
labove
‘I accept / reject the Clearance
Version 1.0 2of2 24 September 1999
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref. CR/ACD/391
. Version: 1.0
Acceptance Incident 391 Date: 13/9/99
Document Title: Acceptance Resolution Plan for Acceptance Incident 391
Document Type: Acceptance Resolution Plan
Abstract: This document contains the agreed Resolution Plan in respect
of Acceptance Incident 391.
Status: Issued
Distribution: Expert:
Peter Copping
ICL Pathway:
Library
POCL:
Bob Booth/Jeremy Folkes
John Meagher
Min Burdett
Jeff Austin
Author: D J Jones / J C C Dicks
Comments to: ICL Pathway list
Comments by:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page I of 6
ICL Pathway
POL00325269
POL00325269
Acceptance Resolution Plan Ref: CR/ACD/391
I Version: 1.0
Acceptance Incident 391 Date: 13/9/99
0 Document control
0.1 Document history
Version
0.1
0.2
0.3
0.4
1.0
Date
20/8/99
24/8/99
25/8/99
10/9/99
13/9/99
Reason
Initial draft
Draft Version for the expert and workshop 25/8
Version for the Expert and workshop 25/8
Version documenting the agreed Resolution Plan
Plan agreed at 13/9/99 Workshop
0.2 Approval authorities
Name
JH Bennett
JCC Dicks
M Bennett
Position Signature Date
Managing Director
Customer Requirements
Director
Quality and Risk Management
Director
0.3 Associated documents
Reference
Vers Title Source
0.4 Abbreviations
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page 2 of 6
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/391
Version: 1.0
Acceptance Incident 391 Date: 13/9/99
0.5 Table of content
1. PURPOSE
2. SUMMARY
3. CRITERIA...
4. POCL POSITION..
5. ICL PATHWAY POSITION
5.1 EVIDENCE TO ENABLE THE PLAN TO BE AGREED
5.1.1 Analysis of the Incident
5.1.2 Resolution Plan.........
5.2 RESOLUTION PLAN SUMMARY..
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 6
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/391
Version: 1.0
Acceptance Incident 391 Date: 13/9/99
1. Purpose
This document sets out the ICL Pathway Resolution Plan with respect to Acceptance
Incident 391.
2. Summary
This plan contains the actions agreed with Jeremy Folkes and Bob Booth (POCL) that
now constitute a satisfactory Resolution Plan for the issues raised under Acceptance
Incident 391.
3. Criteria
The Criteria under test are PS-22, PS-39, PS-40, PS-41, 698-03, 698-02, and 698-01.
[DN: PS39 is a repetition of 698-01; PS40 is a repetition of 698-02; PS41 is a
repetition of 698-03; PS22 is modified in the Codified Agreement to remove certain
references to DSS.]
4. POCL position
Several meetings have been held with POCL representatives and POCL have now
agreed that the actions in place to address the issues raised under AI 391 are
acceptable.
5. ICL Pathway position
5.1 Evidence to enable the plan to be agreed
5.1.1 Analysis of the Incident
POCL and ICL Pathway agreed that the specific areas of concern were as follows:
BOOTLE
1. The Data Centre fence is in a totally unsatisfactory state (acknowledged by
A&L)
2. 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.
3. Vehicle access is still possible to within 2 metres of the Data Centre. 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
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 6
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/391
Version: 1.0
Acceptance Incident 391 Date: 13/9/99
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.
WIGAN
4. Access via a back gate was not restricted or covered by CCTV.
5. Expected CCTV improvement has not been implemented.
6. Site security is totally dependent on a single security guard / receptionist /
CCTV operator with no defined backup.
5.1.2 Resolution Plan
BOOTLE
1 Since the last POCL visit repairs to the data centre fence have been carried out.
Missing or broken tension wires and fixings, attaching the fencing to the concrete
posts and hooks to secure the fence to the ground have been replaced and the
locks on the emergency access gates are now secure.
2 The perimeter fence upgrade, installed to date and in progress will
substantially improve the security at the site. The likely A&L timetable for
completion of the third phase of the perimeter fence upgrade is deemed
unacceptable by Pathway. Therefore Pathway will install a new palisade fence, by
the end of November 1999, at 5 metres from the data centre that will be to the
same standard as the one installed outside the data centre at Wigan.
3 Changes will be made to the Alliance and Leicester Quality System security
procedures, specifically relating to visitors arriving in a vehicle. The content of
the changes have been agreed with POCL (J Folkes & B Booth) and A&L (B
Jones). The necessary entries in the A&L Quality System documentation will be
completed by 31/10/99.
WIGAN
4 Pathway will extend the A & L card access system, in line with corporate
standards, to the pedestrian access gate adjacent to the canal by the end of
November 1999.
5 a) An additional external camera covering the area between the data centre and
the perimeter will be installed by 30 September.
b) Pathway is currently considering options for adding a further exclusion zone
approximately 30 metres from the data centre. These options include motion
detection, a further palisade fence or a microwave fence. Pathway will make the
decision as to its preferred option by the end of September, for implementation by
the end of December 1999. POCL will be informed by Pathway as to which
option has been chosen. The local procedures will be updated to take into
account changes related to the new exclusion zone and Pathway will also add this
onto the RED CARE system when installed.
6 a) Pathway will produce instructions related to the Wigan Security Guards
response to alarms on their pager, for inclusion in the A&L standing instructions.
A&L have confirmed that they will incorporate these instructions in their
procedures by 31/10/99.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page S of 6
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/391
Version: 1.0
Acceptance Incident 391 Date: 13/9/99
b) Pathway is adding the RED CARE monitoring system to the alarm trigger
mechanism on the palisade fence, by 30/09/99.
5.2 Resolution Plan summary
All Resolution Plan activities are now agreed with POCL and have been scheduled or
completed.
Pathway will provide site plans to POCL, by 30/09/99, for both Bootle and Wigan,
marked up to show where the additional security controls are/will be situated.
Ongoing monitoring of the plan will be carried out jointly and a POCL visit is
proposed to take place when all actions are complete (in late December or at the latest,
early in January 2000).
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 6
POL00325269
POL00325269
ICL Pathway Resolution Plan for AI408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Document Title: Resolution Plan for AI408- Horizon System Helpdesk
Document Type: Report
Release: CSR
Abstract: This document provides additional information and explanation
concerning the resolution of A1408.
Document Status: —_ Definitive
Author & Dept: Dave Cooke - ICL Pathway Customer Requirements
Peter Burden - ICL Pathway Customer Service
Paul Westfield — ICL Pathway Customer Service
Reviewed By: John Dicks - Director Customer Requirements
Stephen Muchow - Director Customer Service
Kevin Dowling - Service Director, Operational Services Division
Distribution: ICL Pathway POCL
ICL Reviewers John Meagher
Tony Oppenheim Keith Baines
ICL Pathway Library
© 1999 ICL Pathway Limited Company-in-Confidence Page: I of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
0.5
© 1999 ICL Pathway Limited Company-in-Confidence Page: 2 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for AI408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Document Control
0.5 Document History
Version No. I Date — Reason for Issue —
1.0 26/08/99 First issue
Ll 08/09/99 Updated following workshops and
reviews with POCL
1.2 16/09/99 Updated following an SLA workshop with
POCL
1.3 17/09/99 Updated following Acceptance Meeting
14 21/09/99 Updated Rectification Plan
1.5 23/09/99 Updated rectification Plan following a
conversation between Adele Henderson
and Paul Westfield.
0.5 Approval Authorities
Name Position Signature Date —
Stephen Muchow Director, I Customer
Service
John Dicks Director, I Customer
Requirements
0.5 Associated Documents
Reference — Version I Date Title - ‘ISource
1) CS/SMM/AI408 I 1.0 17/08/99 I HSH — Scripting, SLA I ICL Pathway
Recovery and Resource
Plan
2) 1.0 24/08/99 I Al408 — HSH Service I POCL
Level Failure
0.5
© 1999 ICL Pathway Limited Company-in-Confidence Page: 3 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Abbreviations/ Definitions
Abbreviation Definition
FTE Full Time Equivalent
HSH Horizon System Helpdesk
SLA Service Level Agreement
0.5 Changes in this Version
Version Changes
1.1 Primarily changes following the Acceptance Workshop on 26 August and
the Call Volume/HSH Model Workshop on 8 September. Revision to
document title.
1.2 Changes following the Acceptance Workshop on 14 September to agree
with POCL the Cash Account calls to be removed from the L1 and L2 SLA
calculations and confirm that these SLAs were met during the month of
August. Primarily Section 5.2.2 and 5.2.4.2 and a new 5.3. The old 5.3 is
now 5.4
17/09/99 — Additional final paragraph in section 5.2.4.2
1.3 Changes to section 5.3 and 5.4
14 Changes to section 5.2.4.2, 5.3 and 5.4
1.5 Changes to section 5.1 and 5.4
© 1999 ICL Pathway Limited Company-in-Confidence Page: 4 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for AI408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
0.6 Table of Contents
4. INTRODUCTION ......csesecssseescessssecessseeeeessnteesssneessanteesssnutecessseesseueeteaueeneaneesanenee 6
2 SCOPE.
3 POCL POSITION...
4 ICL PATHWAY POSITION ........ccsccsesseessessessessesnssnsssssstsnesssesessesessesseensenesecaseaneses 7
5 CLARIFICATIONS AND PROGRESS .........ccssssessssesseseseesseeessseseseesseneenseeeenseneecee 8
5.1 HSH Scripting Plan
5.1 Future activitie:
5.2
5.2.1
5.2.2
5.23 HSH Staffing review.....
5.2.4 Conclusions
5.3 Monitoring Period
5.4 SLA Rectification Plan....
6 APPENDIX A —- PROBLEM TYPE AGAINST SERVICE LEVEL... 17
1
© 1999 ICL Pathway Limited Company-in-Confidence Page: 5 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for A1408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Introduction
This document has been produced following the POCL / ICL Pathway Acceptance
Board Meeting of 18/08/99 and addresses the comments made in the minutes of that
meeting with respect to Acceptance Incident 408 and the statements made in the
POCL paper 4/408 — HSH Service Level Failure ~ 24/08/99.
This document provides additional information and explanation to that contained in
HSH Scripting, SLA Recovery and Resource Plan - CS/SMM/AI408 - 17/08/99 issued
to POCL as input to the Acceptance Board.
This document has been updated in the light of the Acceptance Workshop of 26/08/99
and the Call Volume/HSH Model Workshop on 8 September.
This document has been updated in light of the Acceptance Workshop on 14
September.
2 Scope
The scope of this paper comprises the content of AI408, the contents of the above
paper CS/SMM/AI408, the topics contained in the draft minutes from the above
Acceptance Board meeting and the paper 4/408 — HSH Service Level Failure.
The topics can be summarised as: -
e Plan for production and implementation of additional HSH Cash Account scripts
e HSH Resource Plan, comprising call volume projections and HSH staffing
projections
e HSH SLA Rectification Plan
3 POCL position
Based upon the minutes of the Acceptance Board meeting of 18 August 1999, POCL
contended that:
"Production of scripts is not complete"
"Tt does not take account of activities such as the need to train staff"
"Some items have already missed dates"
"Call volume projections and staffing projections contain assumptions that POCL
cannot agree based on experience to date"
On 24/08/1999 POCL also provided the paper A/-408 - HSH Service level Failure.
This supplemented the above points as follows:
e POCL’s experience to date is that some scripts have resulted in inappropriate
advice resulting in further calls to HSH and the National Business Support Centre.
© 1999 ICL Pathway Limited Company-in-Confidence Page: 6 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
e POCL requires an explanation of how the call volume projections are produced
and the logic that supports this process.
e POCL requires that the SLA rectification plan is produced and agreed.
4 ICL Pathway position
Taking the three main topics within this AI, ICL Pathway's position can be
summarised as: -
e HSH scripting plan - The plan described in section 2 of ref. (1) remains the basis
for addressing this aspect of the Al. The Acceptance Board may not have been
aware that actions designated for the 17" and 18th August were completed on
time. Subsequent actions within ICL Pathway and POCL have been completed in
a timely and co-operative manner from all parties involved. The revised HSH
Cash Account script document was re submitted to POCL as Cash Account
Process - ICL/PW/DSP/PRO/023 - version 2.1 - 24/08/1999.
(At the Acceptance Workshop of 26/08/99, POCL advised that there were further
comments on the scripts and a joint POCL/Pathway workshop aimed at finalising
the scripts was planned for (and was held on) 02/09/99)
e HSH Resource Plan - Call Volume prediction
ICL Pathway wish to ensure that POCL has confidence in the modelling tools and
management processes that are used to manage the Horizon System Helpdesk in
terms of staffing levels. The development of the HSH resource model draws upon
a decade of market leading experience of ICL providing Help Desk Services to a
diverse range of Clients.
Some of the key assumptions were introduced in ref. (1) and to supplement this
ICL Pathway proposed that a workshop be held with POCL to address POCL’s
concerns. A set of objectives for this event was proposed in section 5.2. This
event was held 7-8/9.
The HSH has experienced a substantial increase in calls on Wednesday / Thursday
associated with outlets having difficulties in completing the Cash Account
process. This increase in business related calls was not predicted and it is ICL
Pathway's intention to establish a cash account domain of skilled staff with the
appropriate business knowledge dedicated to handling this increase.
ICL Pathway does not consider it appropriate for these complex business related
calls to be handled within the SLA constraints of the Level 1 / Level 2 call
definitions. These calls have distorted the SLA performance.
e SLA Rectification Plan
The actions and target dates that will contribute to an improvement in the HSH
SLAs are set out in section 5.3.
© 1999 ICL Pathway Limited Company-in-Confidence Page: 7 of 20
Last Printed: 23/09/99 19:40
ICL Pathway
Resolution Plan for A1408- Horizon System Helpdesk
Company-in-Confidence
POL00325269
POL00325269
Ref.: CR/ACD/408
Version: 1.5
Date: 23/09/1999
5 Clarifications and Progress
5.1 HSH Scripting Plan
The script production plan described in ref. (1) and shown below has now been
successfully achieved with all actions completed on time.
No. I Description Target I Owner Achieved
date
1 Produce additional elements of Cash} 17/08/99 I P. Curley v
Account Process document in draft form for
POCL comment
2. Review and issue additional scripts to} 17/08/99 I P. Curley v
POCL
3. POCL review and comment on new scripts 19/08/99 I POCL v
4. Collate and respond to comments 20/08/99 I P. Curley v
5. Review and respond to POCL comments on I 17/08/99 I P. Curley v
version 2.0 draft of document
6. Review comments with HSH 19/08/99 I P. Curley v
7. Incorporate accepted comments into I 23/08/99 I P. Curley Vv
document from new scripts and comments
against draft Ver 2.0
8. Issue Document as V2.1 definitive 24/08/99 I P. Curley Vv 3.9.99
(status to be confirmed with POCL)
5.1.1
© 1999 ICL Pathway Limited ‘Company-in-Confidence Page: 8 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for A1408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Future activities
Following agreement of the new scripts, and in conjunction with the establishment of
the cash account domain, these scripts came into operation from 08/09/99.
It was agreed that a joint ICL Pathway / POCL review be held on 14/09/99. The
objectives of the review held on 14/09/99 being:
« Review scripts in light of operational use.
e Review, agree and include any additional scripts
e To identify any learning opportunities
Such reviews will continue in line with the recommendation in
ICL/PW/DSP/PRO/023
5.2 HSH Resource Plan
5.2.1 Background
The development of the model to support the resource requirements of the HSH was
based on ICL's previous experience in providing a wide range of Help Desk services
covering both systems and infrastructure call types. This was supplemented by a set
of assumptions covering the particular call types that ICL Pathway believed would be
generated by POCL's outlets.
ICL Pathway successfully applied the call volume and HSH resource model during
the period of Release 1a through to Release 1c. During this period there was good
achievement against SLA targets.
During the period of LT1 it became clear that the actual call patterns diverged from
those predicted by the models. In particular there were significant differences in call
volumes following the introduction of the first Wednesday cash account.
Following the second and subsequent cash accounts the continuing high level of calls
on Wednesday / Thursday, which had not been predicted by the model, required that
remedial action should be taken.
The resources of the HSH were supplemented by expert assistance from POCL and
Peritas (now termed KnowledgePool) who were able to successfully handle the
complex business related aspects of these Cash Account calls. This had a beneficial
impact on the call response times for the remaining calls being handled by HSH staff.
5.2.2
© 1999 ICL Pathway Limited Company-in-Confidence Page: 9 of 20
Last Printed: 23/09/99 19:40
ICL Pathway
POL00325269
POL00325269
Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Company-in-Confidence
Version: 1.5
Date: 23/09/1999
Service Level Analysis
Level 1 and Level 2 call resolution SLAs (excluding cash account calls as agreed with
POCL on 14 September) met their targets in August — see tables below.
Service Level Number August Target
Calls Resolved: of calls
Level 1 I <=5 minutes 190 96% 95%
>S minutes & 9 100% 100%
<= 10 minutes
Level 2 I <= 30 minutes 144 97% 95%
> 30 minutes & 4 100% 100%
<= 45 minutes
Total 347
5.2.2.1 Level 1 & Level 2 Calls Analysis — August 1999
The table below shows the number of service calls that were included within the L1
and L2 SLAs and those which needed to be re-categorised as agreed with POCL on 14
September. Cash Account printing calls remained in L2 as they involved an
operational known error. The sub categories can be seen in appendix A.
Total L1 & L2 Recorded in the Data Warehouse
455
Calls to be re-categorised out of L1 & L2:
Complaints
12
Cash Account (see section 5.2.2.2)
96
Calls to remain within L1 & L2:
Implementation
Advice & Guidance
Printing within Cash Account
Total
5.2.2.2 Cash Account Calls Analysis
The tables below show the breakdown of those Cash Account calls that were removed
from the L1 and L2 SLA calculations.
© 1999 ICL Pathway Limited
Company-in-Confidence
Page: 10 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Category Number of calls %
Cash Account Reports 22 23
Declarations 22 23
CAP Roll Over 19 20
Suspense Account 16 17
Stock Unit Balance 10 10
Discrepancies 7 7
Total 96
The table below shows the number of calls falling into resolved time periods.
Calls Resolved: Number of calls %
<= 5 minutes 48 50
>S5 minutes & 22 23
<= 10 minutes
> 10 minutes 26 27
Total 96 100
5.2.3 HSH Staffing review
At the 08/09/99 workshop on the Call Volume/HSH model ICL Pathway shared with
POCL the most up-to-date HSH resource plans for the remainder of 1999. These
separately identified the staffing for cash account calls. The predicted staffing level, in
terms of Full Time Equivalents, is set out below.
Model prediction (FTEs) Oct Nov Dec
HSH staff (excl. cash a/c) 26 35 35
Cash a/e staff 6 8 8
Total staff 32 43 43
© 1999 ICL Pathway Limited Company-in-Confidence Page: 11 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
The planned staffing of HSH is as set out below.
Oct Nov Dec
Fully operational HSH 34 39 43
analysts
KnowledgePoo! staff for 10 8 4
cash account domain
5.2.4 Conclusions
5.2.4.1 HSH staffing levels
From its analysis ICL Pathway believes that the HSH is sufficiently resourced now to
meet the call volumes for Level 1 and Level 2 call types. Further resource is needed to
augment performance on cash account days.
5.2.4.2 Cash Account Domain
ICL Pathway has therefore established a domain of specialist staff with the business
skills to handle Cash Account related calls. The solution for service levels for Cash
Account calls was discussed at the workshop on 7/8 September and further
suggestions were tabled at the workshop on 14 September.
The scripts now employed have been agreed with POCL and are to be reviewed
regularly to ensure they remain as effective as possible. Since the navigation of the
scripts is dependant upon information provided by the postmaster and may involve
returning to the counter terminal to provide further tasks as instructed, the time
elapsed will vary (e.g. closeness to telephone, frequency of external interruptions,
ete.). It was agreed at the acceptance meeting that benchmarking of Cash Account
scripts would add little value in determining the service performance and that a
qualitative approach would adopted as follows:
1. 100% availability of helpdesk staff skilled in providing the appropriate advice and
guidance. That is, no postmaster will be told that they would be rung back on
initially logging a call at the HSH.
2. No repeat call(s) from the same postmaster for the same incident in the same
accounting period.
On 21 September it was further agreed that
3. POCL will attend the HSH to audit that the approved call scripts have been
followed conscientiously and that consistent advice has been given. The
performance measure is 95% conformance.
© 1999 ICL Pathway Limited Company-in-Confidence Page: 12 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for A1408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Pathway suggests that Customer satisfaction with the Help Desk service should be
determined quarterly as described in requirement 914. Pathway will be pleased to
assist POCL in devising and conducting the satisfaction survey.
POCL may assure themselves that Cash Account service calls have been correctly
coded by the HSH through their existing Internet access to Powerhelp. The problem
type ID, described in Appendix A, may be used to construct searches as required.
Should POCL wish to further understand Pathway’s processes for service level
measurement then Pathway would be willing to provide a two-day workshop on the
subject.
5.2.4.3 HSH Resource Planning workshop
In order to ensure that POCL share ICL Pathway’s confidence in the robustness and
flexibility of the tools and processes used in HSH Resource planning, ICL Pathway
has held a workshop with POCL to cover this topic in more detail.
The objectives of the event being: -
e To enable POCL to gain understanding and have confidence in the overall
philosophy of the call volume model and it’s relationship to the resource planning
model.
e To discuss and explain the factors and logic that apply to the modelling of call
types and call profiles
e To explain the iterative management processes that are supported by the model
e To review the impact of Cash Account related calls on service levels
5.3
© 1999 ICL Pathway Limited Company-in-Confidence Page: 13 of 20
Last Printed: 23/09/99 19:40
ICL Pathway
POL00325269
POL00325269
Resolution Plan for A1408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Monitoring Period
A workshop was held on 14" September to audit the service performance of Level 1
and Level 2 calls and Cash Account calls. It was agreed that the service levels were
met.
Weekly monitoring of the service levels shown below will commence on the 4"
October for a six-week period, ending 14" November. Over the six-week period each
individual service level must be met, as a minimum, for 4 weeks. Reporting on the
achievement will be weekly and in the form of the following table.
Service Level Target Week Commencing
04/10 I 11/10 I 18/10 I 25/10 I O1/11 I 08/11
Level I I =5 minutes 95%
= 10 minutes 100%
Level 2 = 30 minutes 95%
= 45 minutes 100%
Calls answered within 20 80%
seconds
Cash Ring backs 0%
Account
calls
Repeat Calls 0%
Call scripts 5%
compliance
5.4
© 1999 ICL Pathway Limited Company-in-Confidence Page: 14 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref. CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
SLA Rectification Plan
This section summarises the activities that comprise the SLA Rectification Plan.
HSH Scripts
1. New scripts agreed with POCL (31/08/99) v 3.9.99
2. Implement new scripts (wef 08/09/99) ¥ 8.9.99
3. Initial ICL Pathway / POCL review of the implementation of ¥ 14.9.99
scripts in accordance with ICL/PW/DSP/PRO/023
Call Volume/ HSH model
4. Hold workshop with POCL (on 07-08/09/99) ¥ 7/8.9.99
HSH Staffing
5. Train and introduce 2 additional HSH staff v 31.8.99
TOTAL operational staff = 21 (by 31/08/99)
6. Train and introduce additional HSH staff On-going
in light of monthly updates to Call Volume/HSH Model
7. Review of staffing model at the end of October. Date agreed for 26.10.99
18/10/99
Call handling process
8. Complete refresher courses on call handling process a line) by Y 31.8.99
31/08/99
9. Start refresher courses on call handling process (1* line) by v 1.9.99
01/09/99
10. Complete refresher courses on call handling process (1* line) 30.9.99
Cash Account Domain
lL. Specialist staff identified and re-deployed by 06/09/99 ¥ 6.9.99
12. Cash Account domain operational (wef 08/09/99) ¥ 8.9.99
13. Train 6 HSH staff in use of cash account scripts v¥ 15.9.99
14. Train further 14 HSH staff in use of cash account scripts 30.9.99
SLA achievement
15. I Hold workshop with POCL (on 14/09/99) v 14.9.99
© 1999 ICL Pathway Limited Company-in-Confidence Page: 15 of 20
Last Printed: 23/09/99 19:40
ICL Pathway Resolution Plan for A1408- Horizon System Helpdesk Ref.:
Version: 1.5
Company-in-Confidence Date:
POL00325269
POL00325269
CR/ACD/408
23/09/1999
16. Publish proposed service measurement for Cash Account calls by v 16.9.99
16/09/99
17. Publication of the weekly SLA measurement, as described in On-going
section 5.3, will be on following Wednesday
18. Appendix A to cross-reference the equivalent service contract 30.9.99
schedule
19. Meeting to discuss the logistics and metrics for measuring the Cash I ¥ 21.9.99
Account service levels. First audit agreed for 13/10/99. (see section
5.2.4.2)
20. Pathway to hold a two-day workshop to describe its processes for 27.10.99
service level measurement. Workshop date agreed for 19/09/99
Closure of Acceptance Incident
21. Given that the monitoring period is successful, the Acceptance 21.11.99
Incident will be closed on 21“ November 1999
© 1999 ICL Pathway Limited Company-in-Confidence Page: 16 of 20
Last Printed: 23/09/99 19:40
ICL Pathway Resoluuun Plan for AI408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.2
Company-in-Confidence Date: 17/09/1999
6 Appendix A — Problem Type against Service Level
Closed Calls August 1999
Call Description Problem Type ILevel Problem Description No. Calls
ADVICE & GUIDANCE ADO! N/A BES OPERATION ENQUIRY 1
ADVICE & GUIDANCE AD02 N/A BES FALLBACK ENQUIRY i]
ADVICE & GUIDANCE ADO03 Level 1/2 I EPOSS OPERATION ENQUIRY 354
ADVICE & GUIDANCE ADO4 Level I EPOSS FALLBACK ENQUIRY 6
ADVICE & GUIDANCE ADO0S5 Level I APS OPERATION ENQUIRY 1
ADVICE & GUIDANCE ADO6 Level I APS FALLBACK ENQUIRY 6
ADVICE & GUIDANCE ADO7 Level I OBCS OPERATION ENQUIRY 10
ADVICE & GUIDANCE ADO09 Level I OPERATING ENVIRONMENT ENQUIRY 26
ADVICE & GUIDANCE ADI0O Level 2 OPERATING ENVIRONMENT CONSUMABLE 1
ADVICE & GUIDANCE ADI1 Level 2 DOCUMENTATION ISSUE 1
ADVICE & GUIDANCE ADI2 Level 2 SYSTEM ACCESS ENQUIRIES 33
ADVICE & GUIDANCE ADI3 Level 2 CUSTOMER COMPLAINT 2
ADVICE & GUIDANCE ADI14 Level 2 GENERAL ENQUIRY 3
OTHER CCcol Level 3 POST OFFICE - EMERGENCY CLOSURE (SHORT TERM 1
CLOSURE)
OTHER CCO03 Level 3 POST OFFICE -REOPENED 1
© 1999 ICL Pathway Limited Company-in-Confidence Page: 17 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.2
Company-in-Confidence Date: 17/09/1999
OTHER CC22 Level 3 POST OFFICE - PLANNED CLOSURE 1
OPERATIONS FEOL Level 3 FILE TRANSFER FAILURE, 2
OPERATIONS FE04 Level 3 INTERFACE OPERATION FAILURE 1
SOFTWARE FEOS Level 3 SOFTWARE ERROR DETECTED 45
INETWORK. FE06 Level 3 CLIENT SYSTEM - NETWORK PROBLEM 3
SECURITY FEO7 Level 3 CLIENT SYSTEM - SECURITY BREACH 1
OPERATIONS FEO9 Level 3 EPOSS OPERATION ERROR 23
OPERATIONS FE10 Level 3 APS OPERATION ERROR 2
OPERATIONS FEI Level 3 OBCS OPERATION ERROR 3
HARDWARE HCO1 Level 3 CENTRAL SYSTEM - PROCESSOR FAULT - UNUSABLE 5)
HARDWARE HCO02 Level 3 CENTRAL SYSTEM - PROCESSOR FAULT - USEABLE 1
HARDWARE HCO04 Level 3 CENTRAL SYSTEM - TERMINAL FAILURE
OTHER HC09 Level 3 CENTRAL SYSTEM - ENVIRONMENTAL FAILURE - 2
POWER
HARDWARE HDO1 Level 3 PERIPHERAL FAILURE - PROCESSOR 19
HARDWARE HDO4 Level 3 PERIPHERAL FAILURE - BAR CODE READER 4
HARDWARE HDO7 Level 3 PERIPHERAL FAILURE - COUNTER PRINTER 14
HARDWARE HDO8 Level 3 PERIPHERAL FAILURE - BACK OFFICE PRINTER 14
HARDWARE HDO9 Level 3 PERIPHERAL FAILURE - KEYBOARD. 2
HARDWARE HD10 Level 3 PERIPHERAL FAILURE - MONITOR TOUCH ELEMENT 3
HARDWARE HD11 Level 3 PERIPHERAL FAILURE - MONITOR Il
© 1999 ICL Pathway Limited Company-in-Confidence Page: 18 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.2
Company-in-Confidence Date: 17/09/1999
OTHER HD12 Level 3 ENVIRONMENT FAILURE - CABLING 4
OTHER HDI3 Level 3 OFFICE ENVIRONMENT FAILURE - POWER 43
HARDWARE HD14 Level 3 EQUIPMENT DAMAGED OR DESTROYED 2
IMPLEMENTATION IMO1 Level 3 PLANNED ACTIVITY RESCHEDULE 1
IMPLEMENTATION IM03 Level 3 SITE PREPARATION ISSUE 2
IMPLEMENTATION IM07 Level 2 OTHER 2
NETWORK NDOI Level 3 UNABLE TO CONTACT HQ 5
INETWORK NDO2 Level 3 NETWORK FAILURE - ISDN (WAN) 9
NETWORK ND03 Level 3 POST OFFICE - LINK FAILURE 7
NETWORK NDOS Level 3 POST OFFICE - CONFIGURATION FAILURE 1
OPERATIONS, OC02 Level 3 POST OFFICE - DATA DOWNLOAD FAILURE 1
OPERATIONS ObD02 Level 3 EPOSS - OPERATION FAILURE W1
OPERATIONS OD03 Level 3 APS - OPERATION FAILURE 2
OPERATIONS OD04 Level 3 OBCS - OPERATION FAILURE 4
OPERATIONS OD06 Level 3 ACCESS AND USER ADMINISTRATION FAILURE 10
OPERATIONS OD07 Level 3 OPERATING ENVIRONMENT FAILURE 2
OPERATIONS OD08 Level 3 SYSTEM ENVIRONMENT FAILURE 1
OPERATIONS ORO3 Level 3 CUSTOMER PAYMENT ISSUE 1
RECONCILIATION REOL Level 3 EPOSS 3
RECONCILIATION RE02 Level 3 APS 1
RECONCILIATION REO4 Level 3 OBCS 3
© 1999 ICL Pathway Limited Company-in-Confidence Page: 19 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
POL00325269
POL00325269
ICL Pathway Resolutiwu Plan for Al408- Horizon System Helpdesk Ref. CR/ACD/408
Version: 1.2
Company-in-Confidence Date: 17/09/1999
OPERATIONS SC03 Level 3 CENTRAL SYSTEM - OPERATING SYSTEM - PROCESS 1
FAILURE
SOFTWARE Sco4 Level 3 CENTRAL SYSTEM - OPERATING SYSTEM - ERROR 1
MESSAGE
SOFTWARE SC05 Level 3 CENTRAL SYSTEM - OPERATING SYSTEM CRASH 1
SOFTWARE Sc12 Level 3 CENTRAL SY - APPLICATION ERROR MESSAGE, 1
OPERATIONS SCI3 Level 3 CENTRAL SYSTEM - APPLICATION - UNABLE TO 1
PROCESS FILES
SOFTWARE SDO1 Level 3 SYSTEM MESSAGE DISPLAYED ON SCREEN 38
SOFTWARE SD02 Level 3 SOFTWARE ERROR 755
SOFTWARE SD03 Level 3 SYSTEM OPERATION HAS CHANGED UNEXPECTEDLY 29
SOFTWARE sb04 Level 3 EXPECTED CHANGE HAS NOT WORKED 1
SOFTWARE SDOS Level 3 OTHER 2
OTHER X105 Level 3 OTHER 175
SECURITY ZS02 Level 3 PMMC CARD OR PIN NUMBER LOST 3
SECURITY ZS03 Level 3 ONE SHOT PASSWORD REQUIRED 8
Total 1846
Total Level I calls = 413
Total Level 2 calls = 42
Total = 455 (agreeing with the figure in 5.2.2.1)
© 1999 ICL Pathway Limited Company-in-Confidence Page: 20 of 20
Last Printed: 23/09/99 19:40
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
. Version: 0.2
Acceptance Incident 412 Date: 10/09/99
Document Title: Acceptance Resolution Plan for Acceptance Incident 412
Document Type: Resolution Plan
Abstract: This document contains ICL Pathway’s Resolution Plan in respect of
Acceptance Incident 412.
Document Status: —_ Issued
Author & Dept: Dave Cooke - ICL Pathway Customer Requirements
Reviewed By: John Dicks - Director Customer Requirements
Stephen Muchow - Director Customer Service
Distribution: ICL Pathway POCL Expert
ICL Reviewers John Meagher Peter Copping
Tony Oppenheim Keith Baines
ICL Pathway Library
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 1 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref. CR/ACD/412
. Version: 0.2
Acceptance Incident 412 Date: 10/09/99
0 Document control
0.1 Document history
Version Date Reason
0.1 08/09/99 First Issue
0.2 10/09/99 Revised as Resolution Plan following Acceptance Workshop
of 09/09/99
0.2 Approval authorities
Name Position Signature Date
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
S Muchow Customer Services Director
0.3 Associated documents
Reference Date Vers Title Source
1. CS/PRO/031_ 21/10/97 1.0 MIS Report Production and ICL
Scheduling Pathway
2. CS/PRO/030 21/10/97 1.0 MIS Report dispatch procedure ICL
Pathway
0.4 Abbreviations
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 2 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
0.5 Table of content
1 PURPOSE
1.1 Scope
2 SUMMARY
3. CRITERIA.
4 POCL POSITION
5 PATHWAY POSITION...
5.1 AD-HOC REPORTING...
5.1.1 Ad-Hoc Request - History (Action Point 1)
3.1.2 Ad-Hoc Request - Request Definition (Action Point 2)..
5.1.3 Ad-Hoc Request - Process Improvement (supporting Action Point 1).
5.2 SERVICE REVIEW BOOK .
5.2.1 Benchmark Transaction time summaries
5.2.2 OBCS transaction times.
5.2.3 Fallback transactions.
5.3. TRANSACTION VOLUMES
5.3.1 Service Level Reporting Cycle (Action Point 3,
6 RESOLUTION PLAN.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
11
Purpose
This document is provided to resolve the questions and concerns expressed in AI 412
and to propose the basis of its Resolution. This AI relates to ICL Pathway’s
responsiveness in dealing with requests for ad-hoc reports, the method of calculation
used in the July Service Review Book and the ability of ICL Pathway to generate
counts of transaction volumes associated with SLA calculations.
The structure of this document follows these three areas of concern.
In addition the response to a particular ad-hoc report request referenced in the Al is
also addressed by this document.
Scope
The scope of this response comprises the original AI412, the supplementary POCL
paper AI412 - Service Performance Reporting and the minutes of the Acceptance
workshop of 09/09/99.
Summary
e Ad-Hoc Reporting - ICL Pathway accepts that the response to the particular ad-
hoc request referred to in this Al was delayed, but that the overall process is
operating correctly.
e July Service Review Book - The Transaction Time service level calculations are
based on the previously agreed mean benchmark transaction time. At this time no
adjustments were made for fallback transactions since the values for the various
catagories of fallback transaction time are still in the process of being agreed with
POCL.
e Transaction volume counting - ICL Pathway is able to count the various classes of
transactions and the overall transaction volumes are published via the ICL
Pathway Customer Services Web page.
Criteria
No criterion is mentioned in the AI.
POCL position
POCL's position is represented in the AI text as:
e ICL Pathway has not responded to an ad-hoc request issued on 22/07/99
associated with the July Service Review Book
© ICL Pathway has refused to respond to three previous ad-hoc requests
e ICL Pathway is unable to count transaction volumes
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
e "if this data was not available it would not have been possible to report that they
had passed the service levels - this calls into question the veracity of their service
reporting.”
The actions arising from Acceptance Workshop (5) are:
1. POCL/ICL Pathway to meet to review particular examples (of ad-hoc reporting)
that are of concern to POCL
2. ICL Pathway to consider whether it would be appropriate to provide a targeted
teach-in to appropriate POCL experts to enable them to focus their ad-hoc requests
around Pathway data structures
3. ICL Pathway to provide further information on (the SLA reporting cycle) for
POCL to review.
5 Pathway position
The response to this Al is split into three areas to address the various concerns and
questions raised by POCL. In addition a Resolution Plan is provided in section 6 to
address outstanding activities.
5.1 Ad-Hoc Reporting
ICL Pathway accepts that there has been some delay in dealing with the ad-hoc
request of 22/7/99. POCL has since provided evidence that it was actually submitted
on 23/7/99 by email, but the intended ICL Pathway recipient did not receive it.
Section 2 of this AI response provides the response to this request.
The AI also states that ICL Pathway has refused to provide responses to three previous
ad-hoc requests. This is not the case and ICL Pathway believes that POCL were
advised why it was not possible to respond to these requests.
The three requests are believed to be:
Date Ad-Hoc Request Description Reason
25/06/99 I Information of every call to HSH since The volume of information that
start of NR2 to present this would have generated
would be considerable and in a
form that would make any
subsequent analysis difficult.
The planned introduction of
on-line access to Powerhelp for
POCL was believed to be a
more appropriate way of
meeting this request.
06/07/99 I Incidents raised at HSH relating to non- It was explained to POCL that
application or desktop specific messages the Horizon system does record
e.g. “out of virtual memory", "virtual failures of this type.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
Date Ad-Hoc Request Description Reason
memory loss".
Such information is now
available by inspection of the
call closure text via Powerhelp.
06/07/99 I Incidents raised at HSH relating to It was explained to POCL that
"lockups" and "screen freezes". the Horizon system does record
failures of this type.
Such information is now
available by inspection of the
call closure text via Powerhelp.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref; CR/ACD/412
. Version: 0.2
Acceptance Incident 412 Date: 10/09/99
Ad-Hoc Request - History (Action Point 1)
The ad-hoc request process (CS/PRO/031 - MIS Report Production and Scheduling)
has been in operation for some considerable time, and the procedure for submission
was discussed and revised at the July Service Review forum. Many ad-hoc requests
have been and continue to be issued and ICL Pathway believes the responses provided
are to POCL's satisfaction. The following table summarises recent requests and ICL
Pathway's achievement against POCL's required response date.
Requested I Date of Date Request Date Outcome
By RequestI required delivered /
by response
Jayne 21/05/99} 21/05/99) Freeze incidents 21/05/99] Completed, results supplied
Widdowson
Jayne 01/06/99} 01/06/99] Calls to HSH by 2 outlets 02/06/99] Completed, results supplied
Widdowson
Jayne 01/06/99} 04/06/99) OBCS transactions 03/06/99} Completed, results supplied
Widdowson
Jayne 10/06/99] 10/06/99] OBCS transactions 14/06/99] Completed, results supplied
Widdowson
Phil TurnockI 25/06/99) ASAP} All HSH calls since 25/06/99] Face to face discussion
commencement of LT between R. Brunskill, PW and
Phil Turnock, POCL .
See 5.1 above.
Jayne 06/07/99} 06/07/99} HSH calls - virtual 06/07/99] Telephone discussion between
Widdowson memory, R Brunskill, PW & David
McLaughlin.
See 5.1 above
Jayne 06/07/99} 06/07/99] HSH calls — screen 06/07/99] Telephone discussion between
Widdowson freezes R Brunskill, PW & David
McLaughlin.
See 5.1 above.
Adele 23/07/99} 02/08/99) Txn times / service for 29/07/99} Receipt response delivered.
Kilcoyne EPOSS, OBCS, APS No trace of original request
showing performance & since. Administrative error.
calculation of SLA’
08/09/99} 08/09/99 Top 10 txns for all June 99 09/08/99} Completed, results supplied
- Aug 99 for OBCS, after further clarification of
EPOSS,APS by Product what was required, this was
Description. contrary to what was requested
via the ad-hoc form.
Analysis of the above shows that responses were provided to POCL for eight out of
the nine requests, of which seven were within three days or the POCL required date.
The exceptions were the request of 10/06/99 whose response was delivered after four
calendar days, but three POCL Core Working Days, and the request of 23/07/99,
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 7 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
which was not received by ICL Pathway. The subsequent escalation activities were
not sufficient to recognise and resolve this.
Complete responses were provided to five requests and POCL were advised that three
requests could not be answered directly (see 5.1).
ICL Pathway will normally provide ad hoc reports in accordance with R914 within
three POCL Core Working Days where the information required is readily available in
the form sought. Where such information is not readily available, as in these cases,
ICL Pathway will agree with POCL the most appropriate way of addressing the
particular request.
5.1.2 Ad-Hoc Request - Request Definition (Action Point 2)
Analysis of Ad-Hoc Requests shows that it would be mutually beneficial if the style of
the request was structured in a form that more readily reflected the data sets available
to ICL Pathway and from which the response will be generated.
In order to assist in this process, ICL Pathway will provide a document to POCL by 31
October 1999, highlighting the structure of the data captured in the Data Warehouse,
the Riposte Message Store and other Databases (local to ICL Pathway Customer
Services / MSU).
This document is intended to assist POCL in identifying whether or not an intended
request for information, via the Ad-hoc query process can be readily met. (This does
obviously not prevent POCL submitting a request without reference to this document).
It is proposed that a joint workshop be held, prior to 31 October 199, between ICL
Pathway and POCL to discuss the POCL MIS requirements in detail. (This workshop
was originally scheduled for the end of August 1999 but was deferred by joint
agreement between R Brunskill and Jayne Widdowson (POCL BSM) due to
Acceptance activities.
5.1.3. Ad-Hoc Request - Process Improvement (supporting Action Point 1)
In order to improve the handling of Ad-hoc queries it is proposed that the following
changes are introduced to the receipt and delivery procedures for Ad-Hoc requests.
e ICL Pathway will arrange for an ‘Ad-hoc Query’ mailbox to be set up within MS
exchange. All members of the ICL Pathway CS / MSU will have access to this
mailbox.
e The ‘Out of Office’ return message will be utilised to advise POCL that a query
has been received into the mailbox (Wording to be agreed with POCL)
e The mailbox will be accessed on an hourly basis by ICL Pathway CS / MSU staff
who will, upon receipt of a new request, send an e-mail confirmation that the
request has been logged by one of the MSU team and will advise the following:
e The expected completion date of the query, or
e Ifthe query cannot be completed, the Ad-hoc request will be returned with full
details as to why we cannot supply the information
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 8 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
5.2
5.2.1
e The Ad-hoc query will then be logged into the Ad-hoc query database
e All replies to the originator will be electronic, using the fields within the Ad-hoc
query report.
e In order to complete this procedure correctly, the Ad-hoc query request will be
amended to include a field for the originator’s e-mail address.
e Ad-hoc query process document ref: CS/PRO/030, v1.0 21/10/97 “MIS Report
Despatch Procedure’ will be re-issued to describe this new procedure.
e Interim Arrangements - Until the MS mailbox is operational, Ad-hoc requests
should be sent, by e-mail, to both:
Kashmir.Purewal GRO. and Richard.Brunskill!
Service Review Book
The particular request mentioned in the AI, dated 23/07/99, requests:
"Transaction Services and transaction times for EPOSS, OBCS and APS for July
showing the underlying data / calculations used to show they passed these SLAs".
The calculation of transaction time service levels for OBCS, APS and EPOSS is
specified in Schedules H08, E08 and FO8 respectively. These in turn refer to the
Benchmark Counter Transaction Times documents CR/PRP/011, CR/PRP/013 and
CR/PRP/014 all at version 1 and agreed with POCL as Contract Controlled
Documents.
These documents state that, with the exception of OBCS foreign transactions, all other
transactions times are to be based on the set of benchmark figures contained in each
document and not based on actual transaction time measurement. In all cases the
weighted mean transaction time of these benchmark figures is within the target
transaction time (see 2.1) and accordingly the Service Review Book for July and
previous months will show this as achieved using a green entry against the various
Transaction Services.
Benchmark Transaction time summaries
The following is reproduced from the summaries of the above transaction time
documents.
Service Mean Benchmark Mean Maximum
transaction time transaction time
OBCS 26.02 secs 27.01 secs
APS 18.80 secs 20.27 secs
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 9 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
I Version: 0.2
Acceptance Incident 412 Date: 10/09/99
EPOSS 22.90 secs 23.13 secs
5.2.2 OBCS transaction times
In the case of OBCS foreign transactions, comprising 6% of the total OBCS
transactions, the variable element is the ISDN communications time. The measured
benchmark figure for this is 5.4 seconds.
The actual mean time for the last three months, and the corresponding actual mean
transaction times are: -
Month ISDN time Actual Mean Target Mean
Transaction time Transaction time
June 5.39 26.02 27.01
July 5.66 26.03 27.01
August 4.71 25.98 27.01
5.2.3 Fallback transactions
The service level calculations for all of the transaction types described in the Service
Level Schedules also have to be adjusted by the number of transactions conducted in
various forms of fallback. This will take place when the individual fallback
transaction time figures have been agreed with POCL and this activity is being
managed by Jan Ambrose (ICL Pathway) and Pavittar Sandhu (POCL). A proposal
from ICL Pathway was made on 3/8/99 and final comments are awaited from POCL.
When these figures are agreed and the relevant Contract Schedules updated, the SLA
calculations will then take account of any adjustments required for fallback.
At present, however, transaction volumes are not required in order to calculate the
transaction time SLAs because the values of the fallback transaction times have not
yet been agreed.
5.3 Transaction Volumes
POCL has expressed concerns over the ability of ICL Pathway to calculate transaction
volumes, particularly in the context of transaction time SLA calculations. The above
explanation covers why transaction volumes are not currently required.
The particular meeting referred to in the AI (9/7/99 - Liz Blackburn, Graham
Wingrove et al.) was not concerned with overall transaction counting, but with
particular aspects of EPOSS transaction aggregation.
Transaction volumes for APS, OBCS and EPOSS are provided as part of the vital
statistics information available on the ICL Pathway Customer Services Web page.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 10 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
These overall totals are broken down into the transaction types required by the Service
Level Contract Schedules and will be used in future SLA calculations, subject to
agreement of the fallback times. Once this is in place POCL may request a detailed
breakdown of the transaction volumes that underpin entries in the Service Review
Book.
5.3.1 Service Level Reporting Cycle (Action Point 3)
In response to a request from POCL, ICL Pathway will provide a document by 31
October 1999 describing the data collection and SLA reporting cycle. It is intended
that the scope of this document will cover:
e What data is collected from the counters / helpdesks etc, and where it resides
e How this data is used in the calculation of SLA performance measures — the
interaction between Contract Administrator and the application of the formulas to
calculate SLA achievement.
e How this data is reported within the Service Level Agreement Monitor (SLAM)
and the outputs delivered to POCL.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 11 of 12
POL00325269
POL00325269
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
. Version: 0.2
Acceptance Incident 412 Date: 10/09/99
Resolution Plan
No. Action Target Responsibility
completion date
1 Complete agreement to Fallback I End September I Jan Ambrose (ICL Pathway) /
Transaction times Pavittar Sandhu (POCL)
2. Review and agree improvements I End September I Richard Brunskill (ICL
to Ad-Hoc Request process Pathway) / Dave McLaughlin
(POCL)
3. Joint MIS workshop to agree Prior to end Richard Brunskill and Jayne
POCL requirements October Widdowson (POCL)
4. Provide " data structure By 31/10/99 Richard Brunskill
definition" document
5. Provide "Service Level Reporting I By 31/10/99 Richard Brunskill / Peter
Cycle" document Robinson (ICL Pathway)
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 12 of 12