POL00090428
POL00090428
Annex To Second Supplement Agreement
Dated 24 September 1999
POL00090428
POL00090428
THIS SECOND SUPPLEMENTAL AGREEMENT, being Change Control Note
(CCN) No. 560 is made the 24th day of September, 1999
BETWEEN:
q)
(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
(ii) Faults not falling within recital (E) (i) above
Those Acceptance Incidents described in Part B of Schedule 1.
POL00090428
POL00090428
It is Agreed as follows
1s
pes
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:-
(69) developed in accordance with the TIP Control CCD;
(ii) demonstrated by appropriate testing to have met the specification set
out in the TIP Control CCD;
(iii) I 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”.
Ball
2.2
3.1
3.2
3.3
3.4
POL00090428
POL00090428
“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.
POL00090428
POL00090428
35 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.
3.6 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.
4. First Supplemental Agreement
4.1 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.
4.2 For the avoidance of doubt, clause 4.6 of the First Supplemental Agreement
shall continue to apply.
5. 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. Suspension of Rollout
6.1 If:-
6.1.1 any of the criteria in parts A to C of Schedule 4 shall not have been met by 24
November, 1999; or
6.1.2 the Accounting Integrity Control Release Date shall not have occurred by
14 January, 2000; or
6.1.3 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.
6.2 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
72
7.4
7.5
8.1
POL00090428
POL00090428
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:-
qi) 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.
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.
POL00090428
POL00090428
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.6
12.7
POL00090428
POL00090428
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:-
@ 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:-
SCHEDULE 1
Outstanding Category (a) and (b) Faults
PartA
Substantive New Faults Reported after 3rd September, 1999
[None]
POL00090428
POL00090428
POL00090428
POL00090428
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
id
1.2
1.3
1.4
2.1
2.2
2.3
3.1
POL00090428
POL00090428
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.
aw
3.3
3.4
3.5
3.6
3.7
4.1
4.2
4.3
4.4
POL00090428
POL00090428
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
POL00090428
POL00090428
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
(Cc) 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.
We
7.3
7.4
7.5
8.1
8.2
POL00090428
POL00090428
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
$.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
9.2
9.3
9.4
10.
TOL
10.2
10.4
POL00090428
POL00090428
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.
12.2
12.3
13.
13.2
13.3
POL00090428
POL00090428
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 nt
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 ie}
15/11/99 i?)
22/11/99 ie}
29/11/99 )
06/12/99 0
13/12/99 o
20/12/99 ie}
27/12/99 ie)
03/01/00 i?)
10/01/00 i?)
17/01/00 )
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
POL00090428
POL00090428
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 ie}
25/12/00 oO
01/01/01 (‘)
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
POL00090428
POL00090428
POL00090428
POL00090428
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 Re)
04/06/01 14
11/06/01 12
Sub total 730
National Roll Out Total I 18,527 ”
2.
POL00090428
POL00090428
1)
SCHEDULE 4
Acceptance Incident Rectification Criteria
PartA
System Stability (A.I. 298)
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.
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
raction @/13.2.00..
GRO- ' GRO I GRO 7
3.
For this pur oséa Unit shall be measured as follows:-
(i) each Help Desk authorised reboot shall count as one Unit;
(ii) each Help Desk authorised office snapshot print preview shall count as
one Unit;
(iii) I 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;
(iv) I 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.
(v) 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
POL00090428
POL00090428
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)
(vy)
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.
POL00090428
POL00090428
21
Part C
Helpdesk Performance (A.I. 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)
POL00090428
POL00090428
22
Part D
TIP Interface
Accounting Integrity (A.1.376)
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.
POL00090428
POL00090428
23
SCHEDULE 5
Additional Obligations
a. System Stability
A new paragraph 4.6 shall be added to Schedule G10 to the Codified
Agreement as follows:-
“4.6
Reboot Incidents
4.6.1 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.
4.6.2 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.”
4.6.3 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;
POL00090428
POL00090428
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 accounting 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.”
POL00090428
POL00090428
Signed by
for and on behalf of
POST OFFICE
COUNTERS LTD. in the
presence
Signed by A. CMR CTEL
for and on behalf of
ICL PATHWAY LIMITED
POL00090428
POL00090428
THIS SIDE AGREEMENT, being Change Control Note (CCN) No 561 is made the 24* day
of September, 1999
BETWEEN:
1) I 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.
Itis Agreed as follows:
1. INTERPRETATION
1.1 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.
1.2 In this Agreement the expression “POCL” shall bear the meaning ascribed thereto in
the Codified Agreement.
1.3 Unless the context otherwise requires references in this Agreement to clauses and
recitals are to clauses and recitals to this Agreement.
2. 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.
5.
POL00090428
POL00090428
PARTICULAR OBLIGATIONS
Without prejudice to the generality of the obligations contained in the above Clause 2:
4.
a)
b)
i)
qd)
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)
ii)
affect that right, power or remedy; or
operate as a waiver of it.
POL00090428
POL00090428
tas)
or
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.
5.4 The rights, powers and remedies provided in this Agreement are cumulative and are
not exclusive of any rights, powers and remedies provided by law.
5.5 The provision of this Agreement shall be deemed to be incorporated as appropriate
amendments to the Codified Agreement.
5.6 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: a
Signed by:
for and on behalf of:
POST OFFICE COUNTERS LTD., in
the presence of:
Signed by: &. Chere precy
for and on behalf of: ; :
ICL PATHWAY LIMITED, in i
the presenc i
‘GRO
POL00090428
POL00090428
Recfestin Tonatibl
ON ae (a
POL00090428
POL00090428
_ Acceptance Resolution Timetable
[September I October I November I December I January I _Fabruary I
texto [re [Task name Start finish __[57OsporGesoo sooo ooT ooo toe TOPSTOpTT apart fsra BT Tparspeafs oor 2pTA TpwOTh oosf io pUoTp voip romh ab TpATA
7] JManagement Milestones on Overall Pan To Sep W524 Jan W (gy ecnaemerericea SRELA =
- Final Workshop ir sep a] 7 Sanwa -
“Joint Decision on implementation 2079 and 2779 Tew] TOS w I
I ‘Agree Key Contractual Amendments and Milestones: 16 Sep 09} 16 Sep 0) 1 ry
Overall Incident Measuring/Monitoring Report Process Agreed V7 Sep 99! 17 Sep 2 [2
Review of impact on Programme Plan Sep 90) a Sep wo ms
Provisional AccoptancelRAB moeing Hiww] asew i"
Acceptance/RAB - 24 Sep 99/24 Sep 0) 4 "
‘Confirm rolt out plan and volumes for year 2000 (Reset Plan) — ‘Oi Nov'99] OT Nov 99) > on
Joint Delivery Reviews 17 Sep 99] 08 Dec ¥9) 1 1 1 1 1 1 I
28] I Full Review of Programme Pan (nd Accaplance, CSR and Rol Ou) How] Ow 1
3] I — Perform AIST Live monitoring (pre re-start of NRO) Ta yan 9] Te Jano I»
Swan NRO Training oe om
I RRO Re-Commences an 6 1
TAccoptance incidents Whig Wi] ae FD Wo
iv) 1" AiaTT Receipts and Payments not equal Er ee
im ‘Submit Acceptance incident Form me ee I
I Apply Fixes 24 Sep 99] a 21 ‘
1 Recifeaton Pian agre Cre low
‘Assumed Date Of asi Fix TORTS ws
ane Monitor Fes (Minimum 4 Weeks) TOA
2117] x] Approve Closure of this incident Gi Nov 3]
‘Ais42 TIP Data file Delivery oe
Submit Acceptance Incident Form ‘31 Aug 99]
Rectification Plan Agreed 09 Sep ¥9I
Monitor fires & Actions HOA
Monitor fixes and aeions completo Tow
Approve Closure of this incident 02 Oct 99)
‘i380 Recovery of APS Transactions at sep a] as oa
‘Submit Acceptance Incident Form ~ 01 Sep 99] 06 Sep 90) Hl 2
Rectification Plan Agreed 10 Sep 99] iH 1 03
Implement APS Recovery Sofware Change SOT wi [904
Monitor APS Recovery Software Change baw) WOW soos
AlaT6 Cash Account not equal to electronic (Accounting Integrity Controls) oF Sep va] Ta FeO WO
I Prepare Resolution pian ~ —— os] TOS] ;
ees eae Task GE iesione ry Roles Up Tk TITTY Rotes Up Popes NNN Project Summary PAI ates Up Spit i
One 2459-08 Proress eT Py occ up ttestne © Enteral Tass so
Paget I 1
POL00090428
POL00090428
‘Acveplance Resolution Timetable
T [September [October overnber December [January February
I Text10 Trade ik Name Stan Finish Se
3762, , Present Resolution Plan to POCLIPWY working group 13 Sep G3] 13 Sep aia
area) 7 Incremental Fixes 1 Sep V8] ¥4 Jan 00
wen] iinplement al incremental fixes for indents identified a Gs wa] See sre
west] “Approve clearance ofal incremental fires Wom field wvidenc Bipwl DEH] asd
eH Report on siatus of TIP interface integrity ~ Fre) at
a6 a Tt Review reporting of exceptions OT Sep 94] 14 Jan 05] Sasi
we35 I] Repori Status On Exceptions To 24711 Checkpoint Bev Wo] 2 Nov I I feds
s7637/ IManual input facity 10a 99I 30 Dee vo eee erent
semi] POCL Develop and Test manual input faciity ~ Oi Gat Ga] 29Nov I EXUMGSUEE
363% ~ Joint Test of 60+ transaction errors - - DNav Ga] 21 Dee I an I
EU TAE ‘Manual Input facility tive ~ 30e¢ 9] 30 Dec WI =a, 376373
~ interim Reconeliation G6 Sep 93] 00 Sep 7 ow
POCL decision PWY's iniorim Daa Inlogry Chocks are adequate ‘65 Sep Wo] 00 Sep 0 Bana
Raditional ReconcliationAccounting Integrity Controls) Ta Feb 88
“Document Logical Design EPOSS/Accounting Reconcliation Contwois wep] ones
Review Logical Design 05 Sep Wo] — 07 Sep es
POCL to identify failure scenarios a ~W9 Sep 38] ~ 09 Sep %9] 78.83
Response io falure scenarios and add to Logical Design ~ 19 Sep 96] 15 Sep 9 asl
‘Agreement to EPOSS/Accounting Reconciliation Controls “G8 Sep 09] 20Sep 0]
Document & Agree Procedures to forward Reconciliation Reports to POCL 13 Sep V8] 17 Sep GO Tl ods
Agree Rectification Plan for Accounting Integrity Contols. 21 Sep 99] 21 Sep 09] L767
Testing Stralegy lssued 13 Sep 06] 08 Oar90
issue and Review HLTP's ~ ~ weave] “BOAT
I Development and Link Test ~Tisep] Boar
Confirm overall release contents of this Upgrade Boaw] —290c199}
Confirm Seripling Approach Va wo] — 28 0er95I
‘System Testing (Integration and Cycle 1) 22. Oct 08 14 Nov 99]
‘System Testing (Cycles 2 and 3) 1S Nov 98 I 02 Bec 88]
Evaluation of Test Reports
OTT Testing
‘Software Distribution
Data Centre Upgrade
‘Commit Accounting integrity Controls
295) 22 Dec
bec Ws] U7 Dee v5
230806] 27 Bee Wo
woe ws] Des
2e Dec I” 31 Dec we
(OF dan'0o] 13 Jan 00)
Va Jan 00] V4 Feb 00]
01 Sep 99] 30 Sep 08]
mena
Project AI Pian 010909
ate 24 Sep 99
Tea TE
Progress a!
Miesione rs
Summary
Rotied Up Task
Rolled Up Milestone ©>
EEE ono —
External Tasks
Poet Sy TTT
Roles Up Spit
Page?
POL00090428
POL00090428
‘cceplance Resoldton Tetable
[September [October [_ November I December] Tinwary __I__ February I
Textt0 Ie jan Name I stant Finish n0epovdepevoahravoeporoap Tcopar ih tohianTOpsniopin part ifs ipan apart iparrajiwapartap7n2pao if worhi7/oipaoipvorprozh aroap voaparcy
weet) I ‘Document OBC procedures IB: Sena] —Or Seo) areas
we POCL Report on OBG procedures review a le cial dake mses
wee) Testol procedures OF Sep 99) TOS] sane
T ‘Agree success criteria - 10 Sep 94] 20 Sep WI HE 5 ;
Tasue Procedures Sep V6] 30 Sep WH [ordee
Review Points Sep 0] 22000 9 I I I
Review period prior to Acceptance Checkpoint (6 weeks) 10a G9] Nov
“6827 ‘Approve Closure of this incident Fa Feb 80] Ta Feb 00 aay
“a ‘AUST Data Integrity on Gash Account Gi Sep Va] Ga Jan 0
Discussion on Design Level Review (TIP incidents) I Sep 88] T7 Sep
Tnvestigate root cause of additional incidents Fi Sep 06] 2 Sep
Update Acceptance Incident Form I Ri Sepa] Fi Sep
Develop and Apply diagnostic fix ar Gata] oF et]
are I Gael Diagnoses WOa vo] TOW
ae) Develop and implement required fix (estimate) ‘30 Nov 99]
a om)
v8 I ‘Modify stock rollover button to add information panel & eliminate multiple clicks ~~ I 01 Sep 99] 08 Sep 99)
3789) Distribute modification for stock roll over button 08 Sep 99] 08 Sep 99
went ‘Approve Closure of this incident (subject to diagnostic remedial action) 04 Jan 00) 04 Jan 00] er
“sis I Aide OBS Fatores Gi Sap Wi] OF WH
3607 ‘Report on Scanner lab tests - Oi Sep G0] 01 Sep Wo]
Agree Rectification pian 02 Sep 99] 02 Sep 99]
POCL to oblan agreement rom DSS to provide reject covers Bia T) Tee
POCL obtain reject covers: i ‘24 Sep ¥9I
Daa Analysis of pounded OBCS compared with ESNS (Trend Analysis) ToS
‘Cluster Data Analysis 2 124 Sep 99 I
i POCL investigate resulls of Cluster analysis Sep
Develop Action plan for Roving Lab 07 Sep 99 I
Deploy Roving LabiValdaton wats of rejects at outels Bene
Undertake Root Cause analysis to confirm no system issues Tape
Conf rescaion scons and rook cause analysis witi OSS Wap wa] Sew
Prepare Monitoring and Evaluation Plan scala 7 Sep vo) Ba Sep ws]
Produce Paper on approach to be deployed in the ‘Pilot’ ~ ~~ I 20 Sep 90] ~ 28 Sep 05
"Pilot scheme ative" ofices wOaw
36917) Further tests following ‘Pilot scheme ~ Ta Nov @
369 18) ‘Study to identify potential areas of improvement opportunity ~ “FE Nov 0
Reoctaal a Task TE este rs Se ere
Bate 2 Sep 9 Progress ewe FY Fotos vp iesione O Esienal Tass sot
im Pane
POL00090428
POL00090428
‘Accepance Resoluton Timetable
[September -—~“Getaber I —Wovarmbar_[ ~~ Dacamnbar [anny [ February
Texto I re [Task Name stan __I Finish _ PSrGapaapaowavooporoeprroapar of wnoferOpar opi pat fis par ipor iparzhavraparapTn pao oor I avip voiprosh weep oapsTaI
36919 ‘Confirm process for communicating revisions to procedures (ICL Pathway) 30 Sep 5] OF Oct we Is ~
sea Confirm process for ensuring that changes to system designiprocedures are reflected in vai I 20Sep vo] GT Oat das
wea Confirm process for communicating revisions to procedures (POCL) ar sep 8a] OF Oar
32923] I Observations during te Pot WO SepW] 080A
seem ‘Observations during the further tests following the Pilot WOaw] TE nov 5]
3695 Confirm process for communicating revisions to procedures (for User Guides) “2 Sep Wi] GOA W)
36926) ‘Analyse barcodes of books which are impounded during the ‘Pilot 01 Oct 9] ~ 01 Oct'¥0
“sea I arava barcodes of books impounded during Trher tests folowing the Pit WOR
30928) 7 ‘Analyse the printingipaper of book: pouni Pilot
368) 3 ~ I) Analyse the printingipaper of books Impounded during tests lollowing Pilot
aa) ‘Reword paragraphs) in Training workbooks relating to non bar-coded books Sep I Ba Sep WO
36532] I Ravised procedures confined for naw offices during waning evenis : Dsew] DSH wI
sea35} Confirm communication of the revised procedures for new Horizon offices - Sep W3I 2080p %I
‘Monitor and Evaluate Rejected books - — BOava] 31 DeewI
~ Approve Closure of this incident - a ‘G4 Jan'00] 04 Jan 09]
“ata I Als72 Live service upgrades ~ eC OS)
r Dally checks for Corrupt executables ot Sep wa] Bz aT
wa? Prepare Reciiication Plan ~ I ar Sep 90] 8 Sep 9
723] Provide ATE Technical details ~~ [31 Aug 9] 31 Aug 99)
aaa} “Agree Format of Software Distribution TW Sep Wa] Te Sep 0
west ‘Rares Recification Plan ~ I I Sep 98] TT Sep
‘726 Run Software Distribution (inci Riposte 20 upgrade, POCL to review) 17 Sep'08] 30Sep 0
a7 ‘Run Sofware Distribution (Counters)POCL to review “Gr oaw] SOA
wae} I 99% of upgrades to be included in reporting Rave] Oa
weal I Review above Software Distibution WOaw] FOV]
“w29] x] ‘Supporting documentation for live service upgrades ~~ I Of Nova] 07 Nov 89]
37210] X] POC review of Sofware Dstibuton processes I 03 Nov 98] 14 Jan 89 eit
[any Planning involvementin CSR Or Wow 98 [sn
[omapx ‘Approve Closure of this incident I 14 Jan 00 [14 Jan 00} 72.13
a ‘Aiza8 System Stability 01 Sep V8] 24Now W]
POCL & PWY to agree achievement lavels for each ~ Tse) 5% er ine
Implement known fixes Oi Sep Wa] Wa Sep WH
Gagaing Analysis (Monitor, Analyse and Catogorso incidents), - 16 Sep a] Bi Nov Wo
t Track, deny and wiinate Touts ~ wwsep-vo] 20NT
i ~~ Evaluate a a 01 Sep 08] 24 Nov 9
re Task GEE tesore rs Se ee er
I bate 24 Sep-90 Progress me S317 FY cctesupnticsione © Enteral Tasks Spit
+
te
Page «
POL00090428
POL00090428
‘Monitor ix to Stock Unit checking
‘Monitor fix to query logged-on user message
‘Monitor fix to Memory leakage from Printer Monitor
Pant
jure with GIRO Wansactions printing
‘Monitor fix to APS problem — oo
‘Assess against success criteria in Part A Schedule 4
2 Sep volo
OF Sep 98
Hi Sep 95]
OF Sep 98
(08 Sep 99
‘Bi Nov 95] 24
pe 76) X
‘Assess against 1 unit per counter per 3 months
re)
aaa] Testing Policy Document Resolution Report ‘Oi Sep 9
20021] ~~ Produce a Testing Policy document on minim
may > Review and Agree Testing Policy Document
mR Incorporate agreed testing approach into Pathway Testing Strategy
oo "Revisions to the testing & Integration approach for CORY
Baan] x Produce Document
wea] x Review and Agro 2iNov 99
wees] X Traplement provisions
Produce draft of Recifcation Plan
Crs)
‘Agree Rectification Plan
Sep %
Review Points
Base v8
‘Approve Closure of this incident
Handover ongoing monitoring and review to Service Management
‘i218 Managers Training Course
‘Agree Resolution Plan
~ Bihiov
Bi Now 88
WAug v9)
Pre-Entry Event
‘gree spec of Pre-Assessment event
‘Acceptance Resolution Tunetable
[September ‘Oelaber Woversbar I ecembar I January I —Fabroary
Teatro _Ite Task Name Finisn _ E7O5prGepsOof aves ooo Ticapar ight of erTOpSTOpir par afisapa7 part iparigha12poraern spo cosh roipadip voipriazh aoapvaapata
Monitor Double F1 fix 29 Sep
‘Monitor fix to Riposte Peripheral Server ~ WORT —
‘Monitor fix for elimination of printer contention WOR
Monitor fix to alleviate button locking (EPOSS receipt after APS receipt) WSep
7 Monitor revised system busy (based on Riposte Desklop processor ime) “woaw
‘Monitor fix to printing 2 final copies of cash account aSep 9] 100K 98)
T ‘Monitor fix to Riposte message archiving procedure Beep ve] Oaw
‘Monitor fix to APS recovery routine - Sep W]
prema
q
I [2300
I [ 2ts602
ea
[ 2025
Hesear
ii I
[st
[2x2
218.4 i
21822
avaas
Develop Pre-Assessment course
Development Acivives cr
TEL Pathway Dry Run 025
POCL Ory Run - i
Project Ai Pian 010909 ‘Task ERE iesione. of Rolled Up Task EN) Rolled Up Progress MN Project Summary AME Foved Up Spit
Date 24 Sep 9 Progress cE Sunmcy FY ois upmicsione © Stents TY sot
Pages
POL00090428
POL00090428
_ “Acceplance Resolvion Timetable
- [September I —— October I —Wovamber December [January [Febraary [J ‘
tenro_Ire [Task Name sian ___I _ Finan _ Richioepescof sopra roopang vos TOpSTOpIT par fis pi ypsr para iaporaprn pop aoip7opuoipmoipradhaoapapen
zea} I “Amendments Made 12 Oct Wo] 120299] Tar
76m) Event Sign Of Woawe Boa Hsin
rr) Define and Agree Processes Sew] BOA nami I.
F836] ] Event Ready a ar Sa] OT ov Ba ”
3837 Raise CCNS¢3 (Change RNM) Tih G6] Sag
Tes} ‘Submit CON aR Sep 5] 2 Sep
eM Approve CON — - aa Sep Ha] BE Sep WH] ede
384] I” ‘Monitoring Trainer Quality Hsp OT I
reat] ‘Send Proposal to POL Gi Sep Ga] OF Sep wo na
morn Fagan Review ~ Ga Sep 5] 08 Sep siaaa
Davelop and Sign of Document 7) Et}
‘onitor Trainer Delivery Oa sits
Review of PSA [R858 TCT) gp
Draft Proposal to ICL Pathway ~ a Bp 95] TO Sep FH] ier
POCUICL Pathway Approval Process — Sep 95
‘Approval of Review of PSA Process by POCL Sep ies
‘New PSA implemented Boas] BT Oaw “ __
Review, Design, Agree, implement PSA Failure Process Fi Sep wo] 2500
71856] Review of MTC Process (Amend, Agree, Implement) I 5 Sep] Oe Naw aH
ares] POCL Post installation Support Se
21838] POCL Post installation Competency a = OS Nov 29) II
wes] Post Training Consolidation a ~ G1 Sep 99] OF Jan]
esa) SUG Process on Training Mode (Review, Amend, Agree, implement) eo)
218562] I Training Workbook Exercises (Review, Amend, Agree , implement) . 16Sep 9] nov wa
ves Review Changes to User Training (Review, Amend, Agree, Implement) OF Sep 33]
21838] “Promote Use a Training Wode nC aissos
nee) Measurement of Pian Effectiveness Pa Sep Ba] BE Feb :
veer — 13 Sep wo] iF Sep 5 BB ides
21ate2I I ~~ Develop, Review and Agree Specie Peformance Weasures Weep wa] Hoa —
T implement Toa] TORT 1
‘Check and Assess Performance Oat wo] 30a wo
t Check Documentation for Consistency TORov 90) — 22 Nov 99
Perfomance Review Mesting abe wa] 3 ee we Danie
Performance Review Report ian 0o] Wan wo (a
Monitor RoI-Out jan v0] 70 Feb vO .
I Weatng ofa abigations (Compete other elements of vaining solution) sow va) aOR] ee il
Project Al Plan 010090 Task ME ese ry Roled Up Task II Roles Up Progress ENR Project Summary AMM Fie Up Sput -
Oate 24 Se0°99 Progress mE Suy PY woiec up ttiesione Enteral Tasks Spit
Page 6
POL00090428
POL00090428
“Acceplance Resohiton Timetable
I L. September] ‘Oclober Wovember [December] Tanwary____[___ February I
texto {te [Task Name sit __I Finish voapO Ce TOee of fe TOpSTOpT pat fier Bar par apart t2paap7A puoi aoifi7oipwoipvoipraahaoepinapate
718610 “Approve Closure ofthis incident based on CSF Za Feb Wo] —20Fed WD i T 7
‘Al391 Physical Security a eT
sry Produce Accoplance Incident Analysis - Status report ee eo I
‘gree Recifcation Pian Sp] ayy I
Produce revised site plan - both sites 7 Sep W5] —30Sep 9 nek i
Install new palisade fence at Boole WZNiv Bo] 30Now 08 mm.
“Roree improvements lo vehicle access baseline controls Ga Sep 5] 05 Sop I
‘Amend vehicle access base line conirols “WT Sep G8] 31 Oct 98) a one
Erlend card access controls to back gate al Wigan is Nov Go] BO Nov wo rms
install exta camora betwoen dala contre and perimeter at Wigan oS 17 Sep Wi] 30 Sep Esa
Decide on furor exclusion zone at Wigan and notify POCL 20 Sep Wo] 90 Sep I Ib I
Implement further exclusion zone at Wigan 18 Oct' 9/31 Dec 99) I .
“Rad New exclusion zone to Red Care ~WeOaw] 31 Dee wo] [See
Update Wigan local procedures BW Sep a] — 280A I
Produce and implement insiniclons relating to alarm response at Wigan ~ ‘Oa v] 36a] /
“Rad Alarm Wigger to Palisade to Red Care 17 Sep Wi] —30Sep 9 a 7 I
POCL Inspection of Wigan and Bootie (04 Jan'00I 10 Jan 00) I Sadi
“Approve Closure of tis incident em) ae
a4 ‘Ribi4 Technical Document for Procurement viFeD wo
POCL to review and comment on new proposals — Be) aa
PWY to amend and reissue proposals ~ 0 Sep Bo] OF Sep 99] ag
FTE) ‘gree Recilication plan “G2 Sep Wa] WH Sep vo sys
Review V0.2 of CS/SPEI007 (Spee for document) ee
Produce revised version of CS/SPENOOT (apes of docuront) ar Sep 9a) BT SI fous
Produce CS/SPEI007 Generalised APlforOPSAPS——SCSCS~S~S~S H8ep 0
Formal Review with POCL and redssue — Ir bee 86] 2a bec wo] aed
Produce Appendices Oi Gee Wo] 2a Dee I I
Review revised API document with Appendix Chien 06] ST Jan WO I as,
issue revised API document with Appendix as CCN Oi Feb wo] OT Feo WO aso
na Approve Closure of this incident ‘01 Feb 00] on
408) ‘Al408 HSH Call SLA failure ‘31 Aug 99] 24 Nov 99]
wer Submit Resolution Plan ~ “Oi Sep Wa] BE Sep ws
408 2I ‘Agree overall Rectification Pian and checkpoints i ‘22 Sep G8) 22 Sep W
Publish Cash Account process document v2.1 WB Sep I GH Sep WH
‘Script Workshop (Agree new scripts) G2 Sep 3] 05 Sep ¥0
Further Script Workshop (POCL/Pathway Review) Sep Wi]
eee Task GREE tes.000 + Se ee en
Cate 24 Sep 90 Progress EN S00) PY ies up ttiosine © External Tasks spat
Page?
POL00090428
POL00090428
‘Acceptance Resoluton Timetable
OCI counter proposal and review
~~ W Sep WI 13 Sep 09
wae
Tst Audit of Cash Account Service Levels
WOa we] ITO ws)
eT)
Monitor against Acceptance Resolution Pian (prior to Acceptance Checkpoint)
WOaw] a Nov wo
‘Workshop on L3 Cash Account SLA Capture:
Ta Sep 9] 14 Sep 99
40820), Implement L3 Cash Account SLA wow
40822 Undertake compliance Audit of HSH scripts 13090]
eB Cross Reference to Equivalent Service Contract Schedule (Matrix Mapping Call CategorisatI 13 Sep 99)
“woaza] x ‘Weting to discuss Logistics and metiics for Cash Account Service Levels, 20 Sep
wa28] x! Workshop to describe processes for Service Level Measurement
rok) Train and Introduce Additional HSH staff
wary x Publishing of Weekly SLA Measurement
ry Review Performance against SLA
wee] x ‘Approve Closure of this incident
a ‘Al412 Provision of ad hoc report in accordance with schedule CA15v10r reqt 914
wa2 Produce Rectification Pian
az3} Report on the history of Ad-hoc reporting
aay Review Escalation procedure in Ad -Hoc reporting process
was ‘Agreed improvements to the Ad-Hoc Request proc
‘Advise POCL how to supply requirements for ad hoc reports
Produce and Agree “Data Structure™ definition document
‘Ravise on reporting cycle associated with service level calculations
Produce and Agree “Service Level Reporting Cycle" document
‘Approve Closure of this incident
[September [October [ —Wovernber I Dacember [January [February I
textio_Ire [Task Name start Fintan _ [Zep oepevoof os ooabTiooparigh woh TopSTOpT ipa isn ipa por iparahan2boraprmapsioipaoifio\paipisipradhanaprogpay
4088) Training of 6 off HSH staffin the use of new scripts T0Sep Ga] 15 Sep 05) mr
wary x Training of farther 14 off HSH staffin the use of now scripts W Sep Wo] 30Sep WO aay \
waa ‘nd Line Refresher Course Shaw] TAT] I gone
was] 1st Line Refresher Cours Di Sep Wi] BO Sep 95] ae
wary x Exper Domain Operational (Implement new scripts) Sep Wa] OB Sep ¥5] Joon
we Resourcing Model workshop ‘GF Sep Wa] OB Sep ¥5] ents
waa] x ‘Workshop to review resourcing model and processes for SLA Measurements, OA] WOAW
way x Proposal to measure performance of Level 3 cash account call handling service (SLA) et)
% NoniLow Severity incidents
m Agree status of disputed items
I 33] [Finalise Pian for 39 off Low seventy incidents
as . a oS — [ee A
Projet Al Pan 010000 Tex EEE ese ° Roles Up Task — AER Rates Un Progress Project Summary Fated Up Spit
Date 24 Sep 99 Progress EE Sino FY ies Up iesione O Exemal Tasks RERARRE) sou
Page
POL00090428
POL00090428
EMERGENCY CCN 562
To the Codified Agreement dated 28 July, 1999
Issue Date: 24' September, 1999
POCL Authority:
ICL Pathway Authority: I G RO ;
POL00090428
POL00090428
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.7
POL00090428
POL00090428
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
3.6.9
3.6.10
POL00090428
POL00090428
Data to POCL (either by manual error report or electronically pursuant to paragraph
3.6.3 above) shall not exceed five working days.
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.
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.
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.
POL00090428
POL00090428
so GRO
PART I
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 analysis dated 20/09/99
AIN 218 document CR/ACD/218 version 0.5 dated 23/09/99
AIN 298 document CR/ACD/298 version 0.8 dated 23/09/99
AIN 314 document CR/SPE/007 version 0.3 dated 07/09/99
AIN 342 analysis dated 16/09/99
AIN 369 table from BA/ACC/020 version 0.4 dated 20/09/99
AIN 372 document CR/ACD/372 version 0.4 dated 16/09/99
AIN 376 document CR/ACD/376 version 0.9 dated 23/09/99
document PI/DES/002 version 0.7 dated 20/9/99
AIN 378 analysis dated 16/09/99
document CR/ACD/378 version 0.3 dated 16/09/99
AIN 390 analysis dated 16/09/99
AIN 391 document CR/ACD/391 version 1.0 dated 13/09/99
AIN 408 document CR/ACD/408 version 1.5 dated 23/09/99
AIN 412 document CR/ACD/412 version 0.2 dated 10/09/99
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
“Acceptance Incident Form Acceptance Incident Number (1)
211
‘Acceptance Test Name (2) Source (3) Date Observed (4)
IEPOSS 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)
Substantive fault Medium >
Other Low
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 Pathway AIM
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Entered in Acceptance Database Date:
Version 1.0
lof 24 Sept
tember 1999
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident “umber (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 criterion not met) Incident Severity (9)
~ High
Substantive fault
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 lof1 24 September 1999
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1) 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)
Substantive fault Medium
Other owd
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
by 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
number represents only a small proportion of the total in which case, this problem would be widespread.
(Consequently. POCL’s initial assessment is that this incident is likely to be more than low severity.
Signatures (11)
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
POL00090428
POL00090428
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)
469-01, 469-02, 470-01, 470-02, 869-05 High
Substantive fault
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.
IAt the time the POCL Infrastructure Acceptance Specification was being agreed it was recognised that the technical
documentation to support it did not exist. Therefore POCL agreed that Pathway could provide the documentation at
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
maintained 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
POL00090428
POL00090428
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 BSE! High
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
lof 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
jand 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 Al 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 lof1 24 September 1999
POL00090428
POL00090428
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
lWitness/Reviewer who observed Incident (Owner) (5) Authority (6)
David McLaughlin
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
36-01 .
Substantive fault
Medium
Other Low
Pending
one
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
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance fcident 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) (ifcriterion not met) Incident Severity (9)
1476-04, 476-05, 537-01 .
Substantive fault
Other
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:
1b) changes to the Services can be made speedily and accurately.
Upgrade of 299 offices was planned to be done on 10th/11th 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
lupgraded leaving 11 offices still operating LT1. The follwing incidents are demonstrations of the failure to meet the
criteria.
A 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)
Approximatley 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)
An LT2 change was to the font size for the cash account. TP report that 8 offices (FAD 252329, 205329, 407329,
258523, 188504, 156523, 166328, 461329) produced cash accounts with the old font size.
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 lof
24 September 1999
POL00090428
POL00090428
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)
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
ithe 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
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form 2 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)
31-01 .
i High
Substantive fault Medium
Other Low
Pending
one
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
Iwithin 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 lof 1
24 September 1999
POL00090428
POL00090428
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 (9)
549-02, PS-32 High
Substantive fault
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:
Version 1.0 lofl 24 September 1999
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
eat , 391
Acceptance Test Name (2) Source (3) Date Observed (4)
Security BSM 22/07/99
I Witness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
Jeremy Folkes
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
698-01, 698-02, 698-03, PS-22, PS-39, PS-40, PS-41 High
Substantive fault Medium
Other ow
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 in a
number of areas, when measured against best practice, relevant standards (BS7799, as required by 698.03 and PS41,
DITSS as required by PS22) and Pathway’s own Security Management Procedures (RS/PRO/028 1.0 10.5.99),
which form part of Pathway’s Security Policy (RS/POL/002 4.0 30.4.99), which is in tum the response to
Requirement 698.02.
‘The data centres are a critical 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 fora 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 mn ta a more accentable standard)
Version 1.0 1 of 2 24 September 1999
Second Supplemental Agreement Annex to Schedule 2
the inner protection to the Data Centre has now been brought up to a more acceptable standard).
level of security” and states that the security measures shall ensure that:
lb) the security perimeter is clearly defined.
Relevant referenced documents for Physical Security include:
assets (including services")
- BS7799 s5
- DITSS s13 (specific advice on vehicle parking distances etc).
Note also the new Data Protection Act imposes a duty on Information Security.
Note that Pathway’s own Security Management Procedures [s5.1.1] refers to "defined perimeters... with consistent
a) the security of the perimeter is consistent with the value of the assets (including services) under protection
- Pathway Security Management Procedures - s5 (eg 5.1.1 "security of the perimeter is consistent wit the value of the
POL00090428
POL00090428
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
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Form Acceptance Incident Number (1)
ss 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
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 I calls resolved within 5 mins
Level 1 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
POL00090428
POL00090428
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
lWitness/Reviewer who observed Incident (Owner) (5) ‘Authority (6)
Jerome Brice
Incident Type (7) Criterion Reference (8) (if criterion not met) Incident Severity (9)
Substantive fault Medium
Other Low
None
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).
IWhen 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.
IAs 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
fare 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 on 77 Anonst snecests that thev are insufficiently resourced and are not canable of meetino the reanired
Version 1.0 1 of 2 24 September 1999
ie
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
POL00090428
POL00090428
Signatures (11)
Witness / Reviewer Horizon Acceptance Pathway AIM
Test Manager
Date: Date: Date: Date:
DSS Acceptance Manager POCL Business Assurance
Date:
Entered in Acceptance Database
Version 1.0
2 of 2
24 September 1999
POL00090428
POL00090428
way Acceprance Manager:
re Fre ICL Path
ube cor Pete oon "deceptance Incident Manager
Elio be gia 10
‘Acceptance Incident Number (1)
Acceptance Test Name (3)
Analysis of Acceptance Incident (6) :
Four calls have
ave been formally added to this incident, and are ——= daress
s of which has been sent
duced by an attempted fix in
te men
In addition we hav
cantian: euee, whielh: eeniinedl to TIP. In summary 6 of thes ed froma fault intro ‘
This bad fix has already teen the ae not preventing the wiping 2 book while at an inappropria
The 7th incident id versed out and a good fix m= 41
Existing pevensiesesston, I by the reversal of Peel Toate Fe, nion-Accounting Da
different original saaaesares ‘This should not be done, and EE" OSS reeds amendment 10 prevent
is in.fest andifs expec fed modes being reversed in the same agsion. THIS 1S peing fixed un
pected on the counters no later than 22 ===———2.4 september
—wser
ta transactions within a single
transactions with
der PinICL 29148. A
1 modes. as fo
We have also been inform 5 incidents in week 23. THR
so been informed of $ hi
d of 5 incidents in week one _
een whilt
the 6 above
RED 99081810546
546, HSH 9908160116, PinICL 28627 wa caused bY? MET navigating to the reversals <r
the transaction tO be settled with the incorrect mode.
Jater than 17th September
having
ng a remitt
nittance on the stack and then settling it, causiz>
“ ig ib -_——
ed on the counters no
Solution is to dis
lution is to disable the reversals button. Fix in test and ==
RED 99081810547, one
process to be pot 9908160118, PinlCL 28628/285 ——==R7 SET
cuted twice. This is in fact another aspec® Linen
of stock unit roll not onl ed the inability to harve: p21 into
aly sas = he line
AP and added the bov tors e for the star -
ught forward value for of C
e fix was delivered 1
d to outlets starting on 14th September —
expect
allowed the stock unit
76, The multiple inst:
fhe wre
ged by an error which
910, part of AIS
e counter into ¢
ds but also put the
085 value in the CAP 29 cash acce
ction was Tec
to OTT.
which an APS transa\
ill shortly be passe!
arion occurred in
Fix w
HSH 990824¢ .
8240194 5
against the mie are similar: During APS recovery a Si #——_
stock unit, causing the cash omaat oh=SS-— out of balance.
expected in live by 24th September.
Number of continuation pages See
Clearance Action (7)
eeks after last fix.
Pathway to deli
eliv
liver fixes and monitoring to continue for fou —_
— “i Resolution Plan.
I propose the Clearance Action
eal Incident Status described
ove
P. John Pope
Version 1.0
Second Supplemental Agreement Annex to Schedule 2
POL00090428
POL00090428
I accept / reject the Clearance Date:
Action and Incident Status
described above
Date:
Date: Date:
Version 1.0
24 September 1999
ICL Pathway
Resolution Plan
Acceptance Incident 218
POL00090428
POL00090428
CRACD/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
Resolution Plan
Acceptance Incident 218
Ref:
Version:
Date:
POL00090428
POL00090428
CR/ACD/218
0.5
23/9/99
0 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
ICC Dicks
W M Foley
Position Signature
Managing Director
Customer Requirements
Director
Business Development
Director
0.3 Associated documents
Reference
Vers Title
0.4 Abbreviations
Date
Source
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 2 of 7
POL00090428
POL00090428
ICL Pathway Resolution Plan Ref: CR/ACD.2!8
Version: 0.5
Acceptance Incident 218 Date: 23/9/99
0.5 Table of content
3. DETAILED ACTIVITIES
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 7
POL00090428
POL00090428
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 are:
lescribed 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 Liz Foley's letter of 8th Sept.).
These areas are as follows:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 7
POL00090428
POL00090428
ICL Pathway Resolution Plan Ref! CRACD218
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 AIJ408. 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.
¢ 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.
¢ 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.
¢ 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.
¢ 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.
« 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
POL00090428
POL00090428
ICL Pathway Resolution Plan Ref: CR/ACD/218
Version: 0.5
Acceptance Incident 218 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 - On average NBSC should not receive
Measured through a reduction in the more than 1.2 calls per week from
number of calls (at peak time on outlets when performing their first two
ing and Thursday I balances.
advice and guidance to I
support stock unit balancing, office
balancing and production of the cash
account received at the HSH and/or at I
the NBSC.
Two time periods defined:
peak: Wed 12.00 noon - Thurs 12.00
noon
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
Redustish inthe length ofcalls from
pediionah offices i —
The number of 0 s unable to
complete the cash account balance
I 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
Resolution Plan
Acceptance Incident 218
POL00090428
POL00090428
Ref. CRACD/218
Version: 0.5
Date: 23/999
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.5hours.
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).
I [Mitigation - Where inconsistencies are
I identified there should be an agreed
I resolution plan.]
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 7
of7
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution _ Refi CRACD/298
Pathway Plan ee Bhcops
Document Title: Acceptance Incident 298 — Resolution Plan
Document Type: Acceptance Resolution Pian
Abstract: This document contains ICL Pathway’s updated resolution plan
for Acceptance Incident 298.
Status: Draft
Distribution: Expert:
Peter Copping
ICL Pathway:
Terry Austin
David Hollingsworth
Library
POCL:
John Meaghe:
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 Acceptance Incident 298 — Resolution
Pathway Plan
Ref:
Version:
Date:
POL00090428
POL00090428
CRACD/298
Os
23/9/99
QO Document control
0.1 Document history
Version Date Reason
0.1 20/8/99 Initial draft for comments
0.2 Version for the Expert and workshop 26/8
0.3 Redrafted as a resolution plan
0.4 Material added on longer term incidence rates and defect
prevention for future releases; distributed as a draft at
Acceptance Workshop 9/9/99
0.5 10/9/99 Statistics updated to CAP 24: amendments to show statistics
by counter volumes as a result of Acceptance Workshop
9/9/99
0.6 16/9/99 Summary & outline forward projections added to Section
5.2.4; additional material incorporated into Section 5.5.
following review with POCL
0.7 22/9/99 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 egarded ]
0.8 23/9/99 Further updates ari from drafting of Schedule 2 Part A of
the second supplementary
0.2 Approval authorities
reement
Name Position Signature
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
T P Austin Development Director
0.3 Associated documents
Reference Vers Title
0.4 Abbreviations
Date
Source
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Page 2 of 29
ICL Acceptance Incident 298 — Resolution
Pathway
Plan
Ref:
Version:
Date:
POL00090428
POL00090428
CR/ACD/298
0.8
23/9/99
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 3 of 29
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Pa Pla Version: 0.8
thway in Date: 23/9/99
0.5 Table of content
1 PURPOSE...
2 SUMMARY...
3 CRITERIA.....
4 POCL POSITION
‘stem Load Events & “Unauthor
Incident Metrt ne 7
Position (CAP & Future Pr tions... ” - 0
LED INCIDENT ANALYSIS. CATEGORISATION & RESOLUTION. eosnsesausivecinvey 13
5 PATHWAY POSITION . 6
5.1 PATHWAY WORK PROGRAMME .... 6
5.1.1 Short- Medium Term Activities . 6
5 1.2 Medium-Long Term Activities... _ a:]
5.2 STATISTICS FOR THE PERIOD SINCE. 29 JULY .. veel
1 High level analysis 6
Reboots
5 Freezing during /after log-on
6 FI Twice during log-on
7 System Busy Message...
3.8 Query Logged-on Us
-ellaneous Freezi
3.
3.
5.3.4 Printer Hanging...
3
3
ems
3.3.12 OBCS Problems .
5.3.13 Counter Printer Busy Pre oblems
5.4 RESOLUTION OF INCIDENT METRICS .
3. 4.1. Contractual Requirements ..
Comparison against Industry Norms
5.4.3. Acceptance Position
5.4.4. Resolution Proposal.
IMPROVED DEFECT REMOVAL FOR FUTURE RELEAS ASES
T PINICL ANALSIS coeessoes
5.5.2 Implications for CSR=
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 29
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref: CR ACD/298
Version: 0.8
Pathway Plan Date: 23/999
1 Purpose
This paper seeks agreed ways forward to resolve the system instability issues.
2 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.
3 Criteria
The Criterion cited is 536/1.
astr
Infra:
eral and input devices supplied as part of the elements of the Service
ture on which OPS is provided shall be reliable. robust and easy to use”.
4 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
ICL
POL00090428
POL00090428
Acceptance Incident 298 — Resolution Ref: CR ACD 298
Pathway Plan Veqinw: 02)
Date: 23.9/99
5
5.1
Pathway position
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
© 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
analysi
this work programme are provided in Section 5.3. which gives an
of the variou: ility faults by c: ry. along with details of fixes
applied and associated incidents levels pre- and post-fix.
5.1.2 Medium-Long Term Activities
5.2
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 tions for improved defect removal for future releases.
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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref: CRACD 298
Version: 0.8
Pathway Plan Gate 259/09
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
i)
in response to an environmental incident such as a power cut or through
disconnection of the power supply
through failure to leave the machines switched on during periods of
unattended operation (e.g. overnight or weekends) with corresponding reboots
when operation rest: 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:
« Authorised reboots (correlated with Help Desk instructions)
e Unauthorised reboots
¢ 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution __ Refi CR'ACD 298
Pathway Plan V srsion: ae so
(> Reconciled Totals
5
I
I
I
I
I
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
CHSH System Incident Calis 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.
I
“Reconciled Totals - I
CAPI9 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
HSH System Incident Calls gy HSH Authorised Reboots ( Unauthorised Reboots
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 8 of 29
ICL
POL00090428
POL00090428
Acceptance Incident 298 — Resolution Ref: CR/ACD 298
Pathway Plan Sesion: 1
Date: 239/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.
CAP19 CAP20 CAP21 CAP22
(HSH Authorised Reboot:
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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution ‘ Ref: oe aia
ersion:
Pathway Plan Dates 23/9199
CAPig CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
(HSH Authorised Reboots gj HSH Advice or Other Action G Disputed tems —
5.2.4 Summary Position (CAP 25) & Future Projections
d
The incident types have been grouped into 13 categories and a detailed anal
provided in section 3.3
Problems Eliminated
The following incident types have been eliminated with no noted recurrences:
¢ Back office printer han:
g on final cash account production (Section 5
e The “one-off” OBCS problem (Section 5.3.12)
d-on users problem (Section 5.3.8)
¢ Improvements in performance of the suspense account print (Section 5.3.2)
Problems Significantly Improved
The following incident types have seen s
totally eliminated
nificant improvement but have not been
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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Refi CRACD 298
Version: 0.8
Pathway Plan Dams. 23/9199
© Counter printing issues (Sections 5
e System Busy incidents (Sectior
into the underlying problems
7). although these are being re-categorised
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.
go
System Busy
Application Problems
Button Lockung
Freezing
m Back Office Printing
a Counter printing
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 p
nter 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)
i)
The fix to the Riposte Peripheral Server and related incidents involving 2" page
GIRO reports
3. Elimination of print contention by locking “Previous” during print format
operations
(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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution \ Refi CRACD 298
Jersion: 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
un
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
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)
P CAP 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution 7 Ref ACD 208
ersion: 0.
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
a ane re a
250 FsI A I E
200 I
150 LH EL
100 e MH
50 Fa Ie
0 H Bi
CAP CAP CAP CAP CAP CAP CAP CAP CAP CAP CAP
24 25 26 27 28 29 30 31 32 33 34
The projected ir rate r ins 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
id resolution, system incidents have been filtered into
ach 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 rormal 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref: CR ACD/298
Version: 0.8
Pathway Plan ate: B39
locked buttons are represented to the user by a “no entry” sign across the button.
Examples of legitimate usage of locked functions include:
¢ prevention of more than one user selecting cash account functions or producing
certain types of daily printed report
* 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
—_ Fa
CAPi9 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
I
I
i}
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
ICL
Pathway
Acceptance Incident 298
Plan
POL00090428
POL00090428
— Resolution Ref: CRACD/298
Version: 0.8
Date: 23/9/99
Suspense AJC Print Hang
0.35 ;
025 I I
ye — _
5.3.3 Virtual Memory Problems
Two problems have been observed which result in progr
these circumstances application routines are obtaining v
ssive memory leakage. (In
rtual memory from Windows
but not freeing it correctly after use, leading to eventual virtual memory exhaustion.)
The reported symptoms include very slow
em 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 fir
in WP 5408. A further residual. but relativ
netion has been
this in the fur
ely minor. problem associated with the cas
iagnosed. A fix (lower priority) will be issued for
Virtual Memory Incidents (including Slow M/C & Dr
Watson)
0.2
WP 5408-199
Ries ee
v
CAP19 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Refi CR/ACD 298
Version: 0.8
Pathway Plan Deter ‘aaa
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
ia fecal
CAP21 CAP22 CAP23 CAF24 CAP25 CAP26
The residual count shown under CAP 24 relates to inc
September.
nts from Thursday 2"
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)
mess iving 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
02
CAP! CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP26
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
POL00090428
POL00090428
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
“F1” 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
°
@
°
3°
td
°
i)
g
°
°
8
CAPI9 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
3407. 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref. CR'ACD/298
Pathway Plan Version: 0.8
Date: 239.99
System Busy Message (exc printer/log-on)
CAPI9 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. havi
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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref. CR'ACD/298
Version: 0.8
Pathway Plan Dee: Zs
Query Logged on Users Message
CAPI9 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
{ we 5135-248 I
oe a 7}
CAPig 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref. CRACD 298
Version: 0.8
Pathway Plan Date: 23/9/99
Counter Printer Problems exc. System busy
CAPi2 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 receip
(including the second receipt problem identified above).
ue were identified
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
oa
CAP1¢ 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution __ Refi CR/ACD/298
Pathway Plan ¥ sal 08 0
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
CAPi9 CAP20 CAP21 CAP22 CAP23 CAP24 CAP25 CAP25
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
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 I 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 Solvr‘on.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 21 of 29
POL00090428
POL00090428
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
experience.
Requirement 536, on t
s of Live Trial usage
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
POL00090428
POL00090428
ICL Pathway Acceptance Incident 298 — Resolution Ref: CR’ACD.298
Plan Version: 0.8
Date: 23/999
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 Al to be evaluated in November in relation to
the continuation of national roll-out in January 2000 should have the following
characteristics:
© 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:
© 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:
¢ 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 2 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 I 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution CRACD 298
Pathway Plan ene
(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
POL00090428
POL00090428
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 locki
g, 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.
w
. 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 i)
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:
«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).
¢ 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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref: CRVACD/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
POL00090428
POL00090428
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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref: CR/ACD/298
Version: 0.8
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
POL00090428
POL00090428
ICL Acceptance Incident 298 — Resolution Ref. CR/ACD/298
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
POL00090428
POL00090428
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
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Contributors:
Reviewed By:
Comments By:
Comments To:
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
Distribution: 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
POL00090428
POL00090428
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
N aA Sie il See i, a
0.1 23/8/99 I Draft—forpeerreview ‘AI314
0.2 1/9/99 Revisions in response to comments I AI314
received from POCL 31/8/99
03 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 Signature i 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
POL00090428
POL00090428
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.4 Abbreviations/Definitions
Acceptance
Incident
Application Program Interface
Electronic Point Of Sale
EPOS Service
Non Disclosure Agreement
Office Platform Service
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: 19/99.
POL00090428
POL00090428
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.7 Table of Contents
1
2
3
4 Content of ICL Pathway Generalised API for OPS/TMS....
4.1 Introduction...
4.4.2 Settlement
4.4.3 Stock Unit Management ....
4.4.4 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
45:4 Desktop Interfaces quncsccysne a eammanamecerue
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
461 Bub Agtibsccncnnnnaoe
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
POL00090428
POL00090428
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.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.
D 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
POL00090428
POL00090428
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
POL00090428
POL00090428
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
POL00090428
POL00090428
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.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
POL00090428
POL00090428
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
POL00090428
POL00090428
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
POL00090428
POL00090428
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
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
POL00090428
POL00090428
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
(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
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
Acceptance Incident Number (1) Analysis Sequence Number (2)
342
Acceptance Test Name (3)
TIP Interface
High / Medium / Low (4) Authority (5)
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
withdrawal. 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
IThe 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. TI/IFS/008 section 6.2.3. Details of the parameters for the file retention period are
given in the internal design document "FTMS Configurations for Pathway TPS and POCL TIP Links at Release 2"
(ref. TD/ION/005).
Clearance Action (7)
‘This is essentially the same as that proposed for AI371, relating to HAPS SLA.
Version 1.0 1 of 3 24 September 1999
POL00090428
POL00090428
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
the 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:
- 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.]
IThe BSU will follow the new procedure set out in the “New Procedures” section below.
New Procedures
a. Non-Polled Outlets
1. The BSU have implemented a new procedure whereby they report incidents of non-polled post offices to the HSH.
This is currently done on receipt of a manually produced report of non-polled post offices. This report is 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
ISLA timescales.
Status: The Operating Level Agreement is in draft form and Pathway is waiting on POCL for comments. The draft
OLA does not include provision for Pathway Operations to inform TIP Operations of likely delays in the
transmission of TIP files
2. Pathway OSD have implemented a new procedure whereby they-produce a daily Operations Service Management
Report.
Status: This is for internal Service Management only, but does show the transmission of the TIP files, the numbers
of filoc and the times af rrancmicsian and receint acknawledeoment
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
[with the action agreed at the Acceptance Workshop on 25/8/99.
POL00090428
POL00090428
Agreed Resolution Plan
and Incident Status described
above
I propose the Clearance Action _IP- John Pope
T accept / reject the Clearance
Action and Incident Status
described above
16-Sep-99
Date:
POCL Business Assurance
Date:
Version 1.0
3 of 3
24 September 1999
POL00090428
POL00090428
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
POL00090428
POL00090428
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 I 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 required
opportunities. from ICL
Page 2of 6
POL00090428
POL00090428
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) (I) 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 30f 6
POL00090428
POL00090428
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 dof 6
POL00090428
POL00090428
during the further tests
following the ‘pilot’.
‘tester’)
impounded in the live
environment, including
proposed way forward
(dependant on the
outcome of the analysis)
Order books
Analysis of
printing/ paper
Analyse the
printing/ paper of books
which are impounded
during the pilot
commencing, w/c 27
September
ICL Pathway
(PIRA)
Report on the initial
findings on the quality of
the printing/ paper of
books impounded in the
live environment,
including proposed way
forward (dependant on the
outcome of the analysis)
8 October
Order books
Analysis of
Analyse the
ICL Pathway
Final report on the quality
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
POL00090428
POL00090428
books should only be
scanned once, where an
impound message is
displayed. Emphasise
correct procedure for
‘system failure’ ie. 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 Septembe:
Page 60f 6
POL00090428
POL00090428
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: D C 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:
POL00090428
POL00090428
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
T P 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
POL00090428
POL00090428
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
3. CRITERIA..
4. POCL POSITION
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
5.1.2 Analysis of the Inciden
5.2 CLEARANCE PLAN
5.21 Clearance plan summary ccns-cssremmsinonscncaaicenscniie aN en Te 8
wn
Aan
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 8
POL00090428
POL00090428
ICL Pathwa Acceptance Proposal Ref: CR/ACD/372
y vi 04
ersi .
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 LT] 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 537/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
POL00090428
POL00090428
ICL Pathway Acceptance Proposal Ref: CR/ACD/372
. Version: 0.4
Acceptance Incident 372 Date: 16/9/99
5.2
ICL Pathway position
Evidence to enable the plan to be agreed
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
e 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
e 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.
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:
f, 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.
Clearance plan
The agreed Clearance Plan is based upon:
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 8
POL00090428
POL00090428
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
POL00090428
POL00090428
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.
vA 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:
A 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
POL00090428
POL00090428
ICL Pathway Acceptance Proposal Ref: CR/ACD/372
. Version: 0.4
Acceptance Incident 372 Date: 16/9/99
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
POL00090428
POL00090428
ICL Acceptance Resolution Plan Ref: CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
Document Title: Acceptance Resolution Plan for Acceptance Incident 376
Document Type: Acceptance Resolution Plan
Abstract: This document contains ICL Pathway’s Resolution Plan in
respect of Acceptance Incident 376.
Status: Issued
Distribution: Expert:
Peter Copping
ICL Pathway:
P John Pope
Library
POCL:
Calum Craig
John Meagher
Min Burdett
Jeff Austin
Author: JCC Dicks
Comments to: Pathway list
Comments by: 23/9/99
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page I of 9
POL00090428
POL00090428
ICL Acceptance Resolution Plan Ref: CR/ACD/376
Pathway . Version: 0.9
Acceptance Incident 376 Date: 23/9/99
0 Document control
0.1 Document history
Version Date Reason
0.1 20/8/98 Initial draft for comments
02, 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 Date
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
0.3 Associated documents
Reference Vers Title Source
TIP Incident Status Report Pathway
0.7 Logical Design for EPOSS/TIP Reconciliation Pathway
Controls
Ceasing of Non-Core Products at Outlets Pathway
CS/PRD/065 0.3. Process For Removing Products From Outlets At Pathway
CSR
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 2 of 9
POL00090428
POL00090428
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
POL00090428
POL00090428
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 ves
5.3. DELIVERY OF ADDITIONAL CONTROLS
5.3.1 Ongoing Analysis And Review Of In
5.3.2 Development Of Additional Reconciliation Controls
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
POL00090428
POL00090428
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
POL00090428
POL00090428
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
AI376, 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
POL00090428
POL00090428
IGE. Acceptance Resolution Plan Ref: CRVACD/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 to 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
wv
Above this level Pathway will fix errors and (re)submit the data electronically
to the TIP interface. unless agreed otherwise by POCL.
we
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.
ae 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
POL00090428
POL00090428
ICL Acceptance Resolution Plan Venn, SRACPSTC
ersion: 0:
Pathway 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
POL00090428
POL00090428
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
Pathway Reconciliation Controls a 9168
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
a gl Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
0 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 TI/IFS/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
POL00090428
POL00090428
ICL. Logical Design for EPOSS/TIP Vv Ref.: BUpeson
aliati ersion: 0.
Pathway Reconciliation Controls Date: 20/0909
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
0.5
0.6
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.
Changes Forecast
Report Layouts to be modified in line with Low Level Design.
Other corrections and comments as necessary.
Approval authorities
To be defined
COMMERCIAL IN CONFIDENCE Page 3 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
sii aps Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
0.7 Table of content
1 SCOPE.....
2 INTRODUCTION
3 OVERVIEW...
3.1 Daily Transaction Control Totals.
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...
4.1 Changes to Message Store...
4.11 Daily Transaction Control Totals .
4.1.2 Daily Cash Account Control Totals
4.1.3 Transaction Errors Detected by Counters...
4.14 Weekly Cash Account Control Totals .
4.1.5 Cash Account Reconciliation Errors...
4.2 Changes to Counters..
4.2.1 End of Day Architecture...
4.2.2 Normal End of Day Processin;
423 Cash Account Processing ....
4.24 End of Day Processing Following Cash Account...
4.3 Changes to the Oracle Database 17
43.1 Daily Transaction Total:
432 Cash Account Total Lines
4.3.3 Stock Detail Total Line:
43.4 Exception Messages............
4.3.5 Control Exceptions .........ss00
44 Changes to TPS Agen
441 Daily Processing.....
442 Processing of Cash Account Data.
4.5 Changes to TPS Host.
Daily Processing...
Processing of CAP Stream Control Totals
Processing of Office Stock Holding Control Totals...
4.6 Exception Reports...
6.1 Host Detected Transaction Control Errors.
2 Message Store Errors....... oss
3 Host Detected Cash Account Control Errors
4 Counter Detected Reconciliation Errors...
COMMERCIAL IN CONFIDENCE Page 4 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP PU/DES/002
Pathway Reconciliation Controls 20/09/99
5 DATA FLOW DIAGRAMS
5.1 Daily Processing ...
5.2 Cash Account Processing...
6 REPORT LAYOUTS
6.1 Host Detected Transaction Control Errors..
6.2 Message Store Errors..
6.3 Host Detected Cash Account Control Errors...
6.4 Counter Detected Reconciliation Errors
6. FAILURE SCENARIOS
COMMERCIAL IN CONFIDENCE
Page 5 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref.: PI/DES/002
tit06t, Version: 0.7
Pathway Reconciliation Controls Date. 20/09/99
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref. PI/DES/002
sina 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 contro] 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)
2. Total number of transactions
3. Total of absolute value of transaction ‘Quantity’ field
4. Total of absolute value of transaction *SaleValue’ field
COMMERCIAL IN CONFIDENCE Page 7 of 39
ICL
POL00090428
POL00090428
Logical Design for EPOSS/TIP Ref.: PI/DES/002
Pathway Reconciliation Controls Version: 0.7
Date: 20/09/99
ic fy 4
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
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
eee 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
we
The Mode in which the transaction took place
4. The stock unit in which the transaction took place
5. The product number of the failed transaction
6. The Sale Value of the failed transaction
7. 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
POL00090428
POL00090428
IGE, Logical Design for EPOSS/TIP. Ref.: PI/DES/002
aicces 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
CAP Number
N
N
The values calculated by the OPS
The values calculated by the TPS Host
uw
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 I 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
ICL
POL00090428
POL00090428
Logical Design for EPOSS/TIP Ref. PI/DES/002
Pathway Reconciliation Controls Version: 0.7
Date: 20/09/99
4.1.1
4.1.2
Daily Transaction Control Totals
Daily Cash Account Control Totals
Transaction Errors Detected by Counters
Weekly Cash Account and Stock Holding Control Totals
of © © +
Cash Account Reconciliation Errors
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:fiffff> 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:nnnnnnnn> Total of absolute value of Transaction
Quantity field
<ValueCount:nnnnnnnn.nn> Total of absolute value of Transaction
“SaleValue’ field
>
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:mmmmmmmim> Message number
<Date:dd-mmm-ceyy> Date of message
<Time:hh:mm:ss> Time of message
COMMERCIAL IN CONFIDENCE Page 11 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP __Ref.: PI/DES/002
Pathway Reconciliation Controls ais ine
<Expiry:nnn> Retention period in days
<EPOSSTransaction: Group attribute for EPOSS Transactions
<TranType:DailyCACT > Transaction Type for Daily Cash
Account Control Totals
<CAP:cc> Cash Account Period
<CATable:tt> Cash Account Table No
<MessageCount:nnnnnnnn> Number of transaction messages
<QtyCount:nnnnnnnn> Total of absolute value of Transaction
Quantity field
<ValueCount:nnmnnnnn.nn> Total of absolute value of Transaction
‘SaleValue’ field
S
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:(fffff>
<Id:nn>
<Num:mmmmmmmm>
<Date:dd-mmm-cey>
<Time:hh:mm:ss>
<Expiry:nnn>
FAD Code
Node
Message number
Date of message
Time of message
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
GrouplId /Id/Num
COMMERCIAL IN CONFIDENCE Page 12 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP. Ref: PI/DES/002
Pathway Reconciliation Controls tm 5
Date: 20/09/99
<Group:ffffff>
<Id:nn>
Group Id (FAD Code)
Node Id
<Num:mimmmmmmm> Message Number
&
<Reason:(ttttt>
>
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:
FAD Code
Node
<Groupld:fffff>
<Id:nn>
<Num:mmmmmmmm>
<Date:dd-mmm-ccyy>
<Time:hh:mm:ss>
<Expiry:nnn>
<EPOSSTransaction:
<TranType: WeeklywCT >
<CAP:cce>
<MessageCount:nnnnnnnn>
<QtyCount:nnninnnn>
<ValueCount:ninnnnnn.nn>
4.1.5 Cash Account Reconciliation Errors
Message number
Date of message
Time of message
Retention period in days
Group attribute for EPOSS Transactions
Transaction Type for Weekly Cash
Account (tt=CA)/Stock Holding (tt=SH)
Control Totals
Cash Account Period
Number of CA Line/Stock Holding
messages
Total of absolute value of Transaction
Quantity field
Total of absolute value of Transaction
*SaleValue’ field
COMMERCIAL IN CONFIDENCE
Page 13 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref. PI/DES/002
eras 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: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: WeeklyCAEnrr > Transaction Type for Weekly Cash
Account Errors
<CAP:ce> Cash Account Period
<CATable:1t> 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:nmnnnn> Total of signed values of the Quantity
field accumulated from the Daily Cash
Account Control Total records
<ControlValueTot:nmnnnn.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 <Contro! ValueTot:> will contain values.
4.2 Changes to Counters
4.2.1 End of Day Architecture
COMMERCIAL IN CONFIDENCE Page 14 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
rina 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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref: PI/DES/002
Pathway Reconciliation Controls eee pues
- 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)
Anew 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
N
The total of Table 3 will be deducted from the control total for Table 5;
be
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):
wu
The Control Total for Tables 6 and 6(a) will be added to the Control Total of
the Receipts Table (Table 00):
COMMERCIAL IN CONFIDENCE Page 16 of 39
POL00090428
POL00090428
PI/DES/002
0.7
20/09/99
ICL Logical Design for EPOSS/TIP
Pathway Reconciliation Controls
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
+
Total of absolute value of transaction “Sale Value” field
COMMERCIAL IN CONFIDENCE Page 17 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref.: PI/DES/002
Pry 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
@ Accumulated signed total of ‘Sale Value’ values from Daily Cash Account
Control Totals
COMMERCIAL IN CONFIDENCE Page 18 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP \ Ref.: PUpEson®
iliati ersion: 0.
Pathway Reconciliation Controls Dates 20/0/09
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.
4.4 Changes to TPS Agent
The Harvester will populate the new tables in the Oracle database: there may be
several entries for each FAD code.
4.4.1 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).
4.4.2 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.
4.5 Changes to TPS Host
4.5.1 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
¢@ Compare calculated totals against the control totals in the Daily Transaction Totals
total
COMMERCIAL IN CONFIDENCE Page 19 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref. PI/DES/002
eaices 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
ICL
Pathway Reconciliation Controls Merion 07
POL00090428
POL00090428
PI/DES/002
Logical Design for EPOSS/TIP
Date: 20/09/99
4.6.1
4.6.2
4.6.3
¢ 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.
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.
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.
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP ai
Pathway Reconciliation Controls 20/09/09
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
¢@ 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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP PIDES/002
Pathway Reconciliation Controls oF 99.00
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP aeie
ersion: 0.
Pathway Reconciliation Controls Date. 20/09/99
ouner
POST OFFICE
Transactions
4 TPS Daly Processing Oe
TPs
19 LOS TRANS i ECO TOTAL
‘Counter reeardsvansai ‘Counter End of Day reads massage st
in message store tnd generates ne otal messape
y 7 Daly Cash Account _”
ston O20 TOS
Transactions
Transactions Counter Detected
SFransacion Erore
and new totals message te Ore
Satabase
Harvester Detete
eee ~ cointer Detected
Daly Transactions Transaction Eros
Cental Tots
Tid ORACLEDATABASE TiS ORACLEDE.TOTAL Pi aE See
Harvester Detected
Day Transaction ves
Transaction Centro! Totals =
Counter Detectes
Transaction Eos
2 HOST PROG
TPS Host earacis ransacions Vor rade
Database and produces fe for TIP. A same tne
Compares lola sent te TIP agansi Tolais Mess iS TERRORS
"TPS Host produces exception repor
of erors detected by Harvester
Control Erors: -
COMMERCIAL IN CONFIDENCE
Page 24 of 39
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP \ Ref.: ae
rane ersion: 0.
Pathway Reconciliation Controls ate; 20N0SES
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Ref.: PI/DES/002
atone Version: 0.7
Pathway Reconciliation Controls Date: 20/09/99
tes
(cal
cept
esaaae Store ee
COMMERCIAL IN CONFIDENCE Page 26 of 39
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref PI/DES/002
Pathway Version: 0.6
Date 17/09/99
POL00090428
POL00090428
6.1
REPORT LAYOUTS
Host Detected Transaction Control Errors
0 0 ty) ° 0 0 ° 0 ° 1 a 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
290K dd/mm/yyyy TPS Total Pooesonsd HAHA 22K
Counter Total HOOK posmescssad 22K
23000 da/inm/yyyy TPS Total 20000000 3900000000 23000000
Counter Total 300090000 2000000000 3300000000
*#* 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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PI/DES/002
Pathway Version: 0.6
Date: 17/09/99
6.2 Message Store Errors
0 0 i) 0 i) i) i} 0 0 1 1 1 1
1 2 3 4 5 6 kf 8 9 0 1 2 3
1234567890123456789012345
Trading Transact ion
ont tet
Date bate
da/mm/yyyy —da/mn/yyyy
dd/mm/yyyy — dd/mm/y:
*** END OF REPORT ***
Notes
‘TPS RECONCILIATION REPORTS
Transact ion
Time
hh:mm:ss
hh:mm:ss
RUN DATE / TIME: dd/mm/yyyy hh:mm:ss PAGE NO: 22229
PROGRAM: NNNN
Message Store Errors
Message
Reason
HRRRARAAMAMAKAKARKARAAA KA MH KAA AKAK AKERS,
ERAXRRKKR EEE
RXXKES
RRKKKAMAAARAKARAKKAR AAA MAHA KARA K AKER
KKKKAAKMMAKKARARAA AAA MAAK KAA ARA RARE,
RRKAXARAKAAAAKARARARARK ARKH AK KK ARERR
ROKK KMAMMAAKKAAKAN AKAMA AKA AREA ARARAAARAK
XKKAI I KKK KAMA AAAI I
HX ARKKAKAKK AK AA KAR KAAAAARARAAAR
AAXKAXKRKKARN
RXKAXARAAKAKKKARARARARARARAN
RAK:
x
3
67890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
COMMERCIAL IN CONFIDENCE
Page 28 of 39
POL00090428
POL00090428
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
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Reconciliation Controls Ref: PYDES/002
Pathway Version: 0.6
Date: 17/09/99
6.3 Host Detected Cash Account Control Errors
0 0 0 0 0 0 0 0 0 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3
1234567890123456789012345678901
789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
TPS RECONCILIATION 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
de/mm/ yyy xx CAC Lines - TPS Total MHMRRXXKX
CAC Lines - Counter Total
STX Lines - TPS
‘otal REXKKRRE
STX Lines - Counter Total
CAC Lines - TPS Total
XXKAAK RRXKXKEX
dd /mn/yyyy
CAC Lines - Counter Total XXXAKXKX
STX Lines - TPS Total AURENKX
STX Lines - Counter Total XXX
*** END OF REPC
HUMKXKRRKK
ARKXXXAKK HRKXXKXXXK
KERRKK MRRKXRRXRK
KARKRXKRKK
RXXXXXXXXX
RRKRKKKKRK HAKKXXKARK
HRKRAXRKK XXXXXXXXXK
COMMERCIAL IN CONFIDENCE
Page 30 of 39
ICL Logical Design for EPOSS/TIP Reconciliation Controls
Pathway
POL00090428
POL00090428
Ref: PI/DES/002
Version: 0.6
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
Ref: PI/DES/002
POL00090428
POL00090428
ICL Logical Design for EPOSS/TIP Reconciliation Controls R
Pathway Version: 0.6
Date: 17/09/99
6.4 Counter Detected Reconciliation Errors
i) 0 0 0 i) C i} 0 0 1 1 1 i
1 3 4 5 6 7 8 9 0 1 2 3
123456789012345678901
TPS RECONCILIATION REPORTS RUN DATE
Counter Detected Reconciliat
Number
Outlet Trading bate CAP Number CAP Table
id /mmin/ XX Cash Account
Control
RRXKAK dd/mm/yyyy RX RX Cash Account HRKKEKRK
Control HH:
*** END OF REPORT ***
Notes
The report details lines will be in the following sort sequence:-
saction Date
Ascending Outlet / Trading date / Tr
3456789012345 6789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
TIME: dd/mm/yyyy hh:mm:ss PAGE NO: 22229
PROGRAM: NNNN
on Errors
Signed Value Total
RRKRRKKK
HRRKXXRRRK
COMMERCIAL IN CONFIDENCE
Page 32 of 39
ICL
Pathway
Logical Design for EPOSS/TIP Reconciliation Controls
POL00090428
POL00090428
Ref: PI/DES/002
Version: 0.6
Date: 17/09/99
6.
This section describes how the Reconciliation Process will function under various failure s
Failure Scenarios
scenarios.
Failure Condition
PT. End of Day
Non
node
ailure
Note that the most
common scenario for
this is the Postmaster
2 off the power
to an unused counter
PC.
Scenario when failure occurs prior to
Initiation of Process
End of Day will run in the nodes which are
runnii
¢@ Private end of day markers will be
written for cach live 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 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
Scenario when failure occurs during the
Execution of Process
leway node fails whilst EOD is
D fails to complete and
Ifa non-g
running then E
¢ 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
Scenario when failure occurs for protracted
period
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
ICL
Pathway
Logical Design for EPOSS/TIP Reconciliation Controls Ref:
Version: 0.6
Date: 17/09/99
PV/DES/002
POL00090428
POL00090428
End of Day —
Gateway node
failure
End of Day -
LAN failure
I time for B
Same as
»D
time for EOD
End of Day will not run if gateway server is
down:
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)
If node goes down then end of day will fail:
+
+
+
+
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 (see above)
“As above
System recovers when all nodes restored:
+
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.
(All “ missing” Transactions will be
harvested with the “correct” Trading date)
for failure in non
1 above)
Same as for failure in non-gateway node (see
I above)
Same as for failure in non-gateway node (see
1 above)
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 gi
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
ICL
Pathway
Logical Design for EPOSS/TIP Reconciliation Controls
Ref:
Version:
PI/DES/002
0.6
17/09/99
POL00090428
POL00090428
~ifCAday
¢ No transactions are harvested
# No transaction details are output to TIP.
When WAN recovers:
# All missing days will be harvested
¢ Daily Transaction Control Totals will be
checked by TPS Host
¢ Transaction files will be passed onto TIP
¢ Reconciliation checks will be carried out
if CA day
# No transactions are harvested
¢@ No transaction details are output to TIP.
When WAN recovers:
# All missing days will be harvested
Daily Transaction Control Totals will be
checked by TPS Host
¢ Transaction files will be passed onto TIP
if CA day
¢ No transactions are harvested
# No transaction details are output to TIP.
When WAN recovers:
# All missing days will be harvested
# Daily Transaction Control Totals will be
checked by TPS Host
¢ Transaction files will be passed onto TIP
3. End of Day —
Node rebuilding
following failure
N/A
Node rebuilding for a non gateway node will
have no effect on end of day and details will
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.
N/A
6. End of Day —
Application
failure
Production and
Rollover ~ Non-
gateway node
‘ailure
N/A
Messages are not physically committed until
EOD has completed successfully. I.e. 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
Cash Account Production can proceed on’
gateway node so long as:
# All stock units have been rolled over
ed when warned
@ User says OK to pro
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
N/A
“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
ICL
Pathway
Logical Design for EPOSS/TIP Reconciliation Controls Ref:
Version: 0.6
Date: 17/09/99
PI/DES/002
POL00090428
POL00090428
that all nodes are not available
But subsequent end of day will not run, Thus:
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
node when back on line).
But subsequent end of day will not run. Thus:
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
¢# Weekly Cash Account Control Totals
can be written
¢ No cash account details will be harvested
# No cash account details will be output to
TIP.
When non-gateway node is restored the
system recovers when next EOD is run:
¢ All missing cash account details and
totals will be harvested
* Stock Holding and Cash Account Line
B.C
Production and
Rollover ~
gateway node
failure
d si Control Totals will be checked by TPS
Host
@ Cash account details will be output to
TIP.
# CA Reconciliation is carried out if itis a
Cash Account day
sh Account I N/A CA production can proceed on any other As for 7 above
node.
As for 7 above.
9. Cash Account
Production and
Rollover - LAN
failure
As for (7) above
10. Cash Account
Production and
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:
Version: 0.6
Date: 17/09/99
PI/DES/002
POL00090428
POL00090428
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:
¢ All missing cash account details and
totals will be harvested
# Stock Holding and Cash Account Line
Control Totals will be checked by TPS
Host
@ Cash account details will be output to
TIP,
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.
When WAN recovers:
¢ All missing cash account details and
totals will be harvested
¢ Stock Holding and Cash Account Line
Control Totals will be checked by TPS
Host
# Cash account details will be output to
TIP.
11. Cash Account
Production and
Rollover - Node
rebuilding
following failure
N/A
Node rebuilding for a non gateway node will
have no effect on CAP rollover and details
will be harvested to TIP in the normal way
Node rebuilding of gateway node will delay
CAP rollover until rebuilding is complete.
N/A
I 12. Cash Account
Production and
Rollover —
Application
If these do not complete successfully, then
they can be re-invoked
Since harvesting is based on “trailer
messages” written at the end of the proces:
N/A
COMMERCIAL IN CONFIDENCE
Page 37 of 39
POL00090428
POL00090428
ICL, Logical Design for EPOSS/TIP Reconciliation Controls Ref:
Pathway Version: 0.6
Date: 17/09/99
[failure 4 a - ~ I then the harvester should only pick up the On
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.
7 Harvesters consider the following types of I N/A
Harvester failure :-
es Riposte failures. If these failures are
application “ 7. f "
failure 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)
P14. Agent & -
Harvester
COMMERCIAL IN CONFIDENCE Page 38 of 39
ICL
Pathway
Logical Design for EPOSS/TIP Reconciliation Controls
PI/DES/002
0.6
17/09/99
POL00090428
POL00090428
processing —
normal interface
failure
application
failure
“File transfer————
‘Tobe supplied
To be supplied
To be supplied
COMMERCIAL IN CONFIDENCE
Page 39 of 39
Second Supplemental Agreement Annex to Schedule 2
POL00090428
POL00090428
‘Acceptance Incident Number (1)
378
Analysis Sequence Number (2)
Acceptance Test Name (3)
TIP Interface
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.
High / Medium / Low (4)
Medium
‘Authority (5)
Incident TIP 916, which has similar symptoms but a different root cause is being diagnosed and the system made
INumber of continuation pages
Clearance Action (7)
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
AI.
Agreed Resolution Plan
I propose the Clearance Action
and Incident Status described
above
16-Sep-99]
T accept / reject the Clearance
Action and Incident Status
described above
[Horizon Acceptance cident Mai
soap e
Date:
DSS Acceptance Manager
I POCL Business Assurance
Date:
Version 1.0
lofl
24 September 1999
ICL Pathway
Acceptance Deposition
Acceptance Incident 378
POL00090428
POL00090428
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
ICL Pathway Acceptance Deposition
Acceptance Incident 378
Ref:
Version:
Date:
POL00090428
POL00090428
CR/ACD/378
0.3
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
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
0.3 Associated documents
Reference Vers Title
AI378 TIP Incident Status Report
0.4 Abbreviations
TMS
ap
Date
Source
Pathway
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Page 2 of 5
POL00090428
POL00090428
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 ACTIOD
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 5
POL00090428
POL00090428
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
POL00090428
POL00090428
ICL Pathway Acceptance Deposition Ref: CR/ACD/378
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
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
‘Acceptance Incident Number (1) Analysis Sequence Number (2)
390
‘Acceptance Test Name (3)
High / Medium / Low (4) Authority (5)
Medium
POCL will be aware that ICL Pathway are changing the recovery processes of APS for CSR+. This includes
providing support for recovery of reversals. At CSR+ APS will automatically write recovery transactions for all
IAP 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.
INumbér 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 2 crash, and when undertaking Session recovery or Disaster recovery (i.e. 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.
Additional 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.
IAdditional response 16/9/99
This AI has been recategorised as Medium with an agreed Resolution Plan.
[Number of continuation pages
Version 1.0 1 of2 24 September 1999
POL00090428
POL00090428
Second Supplemental Agreement Annex to Schedule 2
[Agreed Resolution Plan
I propose the Clearance Action y Date: 11/8/99 & 17/08/99 &I
and Incident Status described 31/08/99 & 16/9/99
above tia
T accept / reject the Clearance
Action and Incident Status
described above
Version 1.0 2 of 2 24 September 1999
ICL Pathway
Acceptance Resolution Plan
Acceptance Incident 391
POL00090428
POL00090428
Ref: CR/ACD/391
Version: 1.0
Date: 13/9/99
Document Title:
Document Type:
Abstract:
Status:
Distribution:
Author:
Comments to:
Comments by:
Acceptance Resolution Plan for Acceptance Incident 391
Acceptance Resolution Plan
This document contains the agreed Resolution Plan in respect
of Acceptance Incident 391.
Issued
Expert:
Peter Copping
ICL Pathway:
Library
POCL:
Bob Booth/Jeremy Folkes
John Meagher
Min Burdett
Jeff Austin
D J Jones / J C C Dicks
ICL Pathway list
€ 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page I of 6
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan v Ref: CRACD ISO}
ersion: 1.
Acceptance Incident 391 Date: 13/9/99
0 Document control
0.1 Document history
Version Date Reason
0.1 20/8/99 Initial draft
0.2 24/8/99 Draft Version for the expert and workshop 25/8
0.3 25/8/99 Version for the Expert and workshop 25/8
0.4 10/9/99 Version documenting the agreed Resolution Plan
1.0 13/9/99 Plan agreed at 13/9/99 Workshop
0.2 Approval authorities
Name Position Signature Date
JH Bennett Managing Director
JCC Dicks Customer Requirements
Director
M Bennett 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
POL00090428
POL00090428
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........sssssssssssessssssssesssssesensccssscssssecesseesssse 4
5.1.1 Analysis of the Incident 4
5.1.2 Resolution Plan J
5.2 RESOLUTION PLAN SUMMARY. -6
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 6
POL00090428
POL00090428
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.
a 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
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan y Ref: PRA S}
ersion: 1,
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 5 of 6
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan Vv. Ref: }CR/ACD/391
ersion: 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
ICL Pathway
POL00090428
POL00090428
Resolution Plan for A1408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Reviewed By:
Resolution Plan for AI408- Horizon System Helpdesk
Report
CSR
This document provides additional information and explanation
concerning the resolution of AI408.
Definitive
Dave Cooke - ICL Pathway Customer Requirements
Peter Burden - ICL Pathway Customer Service
Paul Westfield — ICL Pathway Customer Service
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
ICL Pathway
Resolution Plan for A1408- Horizon System Helpdesk
Company-in-Confidence
POL00090428
POL00090428
Ref.: CR/ACD/408
Version: 1.5
Date: 23/09/1999
0.5
© 1999 ICL Pathway Limited Company-in-Confidence
Page: 2 of 20
Last Printed: 23/09/99 19:40
POL00090428
POL00090428
ICL Pathway Resolution Plan for A1408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
Document Control
0.5 Document History
om IssvemaMeet aE
26/08/99 First issue
il 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
1.4 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
(2 Position Signature
Stephen Muchow Director, I Customer
Service
John Dicks Director, Customer
Requirements
0.5 Associated Documents
Reference Version I Date Title Source
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 AIl408 - 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
POL00090428
POL00090428
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
HSH Horizon System Helpdesk
SLA Service Level Agreement
0.5 Changes in this Version
Primarily changes following the Acceptance Workshop on 26 August and
the Call Volume/HSH Model Workshop on 8 September. Revision to
document title.
L2. 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
Ls 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
POL00090428
POL00090428
ICL Pathway Resolution Plan for Al408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
0.6 Table of Contents
4 INTRODUCTION ......ccssssesssessssseesssessseesseessncessuseessseessueessusessueeneessueessueessneeeesneeese 6
Fe 6
3 POCL POSITION
4 ICL PATHWAY POSITION
5 CLARIFICATIONS AND PROGRESS sscccssssssssinvesssssssssssscnssassvasennstescesceesesiesisia 8
5.1 HSH Scripting Plan...
5.1.1 Future activities ..
5.2 HSH Resource Plan
9
52.1 Background. 9
5.2.2 Service Level An 0
523 HSH Staffing review 1
5.2.4 Conclusions 12
53 Monitoring Perio
5.4 SLA Rectification Plan.
6 APPENDIX A- PROBLEM TYPE AGAINST SERVICE LEVEL.......scssssse 17
1
© 1999 ICL Pathway Limited Company-in-Confidence Page: 5 of 20
Last Printed: 23/09/99 19:40
POL00090428
POL00090428
ICL Pathway Resolution Plan for Al408- 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"
"It 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 AJ-408 - HSH Service level Failure.
This supplemented the above points as follows:
© 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
POL00090428
POL00090428
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 AI. 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
POL00090428
POL00090428
ICL Pathway Resolution Plan for A1408- Horizon System Helpdesk Ref.: CR/ACD/408
Version: 1.5
Company-in-Confidence 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
if Produce additional elements of CashI 17/08/99 I P. Curley Wi
Account Process document in draft form for
POCL comment
2. Review and issue additional scripts to} 17/08/99 I P. Curley 4
POCL I
As POCL review and comment on new scripts 19/08/99 I POCL Sf
4. Collate and respond to comments 20/08/99 I P. Curley Sf
5. Review and respond to POCL comments on I 17/08/99 I P. Curley of
version 2.0 draft of document
6. Review comments with HSH 19/08/99 I P. Curley Y
Te Incorporate accepted comments into I 23/08/99 I P. Curley ef
document from new scripts and comments
against draft Ver 2.0
8. Issue Document as V2.1 definitive 24/08/99 I P. Curley v¥ 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
POL00090428
POL00090428
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:
e 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 LT] 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
POL00090428
POL00090428
ICL Pathway 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 I August Target
Calls Resolved: otcalls
Level 1 I <=5 minutes 190 96% 95%
>5 minutes & S 100% 100%
<= 10 minutes
Level 2 I <= 30 minutes 144 97% 95%
> 30 minutes & 4 100% 100%
<= 45 minutes
I 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
Cash Account (see section 5.2.2.2)
96
Calls to remain within L1 & L2:
Implementation
i)
Advice & Guidance
292
Printing within Cash Account
a
rvs)
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
POL00090428
POL00090428
ICL Pathway Resolution Plan for AI408- 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 vA
Total 96
The table below shows the number of calls falling into resolved time periods.
{ Calls Resolved: Number of calls %
<= 5 minutes 48 50
>5 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/c 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
POL00090428
POL00090428
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
KnowledgePool 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,
etc.). 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. he
performance measure is 95% conformance.
© 1999 ICL Pathway Limited Company-in-Confidence : 12 of 20
Last Printed: 23/09/99 19:40
POL00090428
POL00090428
ICL Pathway Resolution Plan for AI408- 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: -
¢ 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
¢ To explain the iterative management processes that are supported by the model
© 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:
09/99 19:40
POL00090428
POL00090428
ICL Pathway Resolution Plan for AI408- Horizon System Helpdesk Ref.: CR/ACD/408
Company-in-Confidence
Version: 1.5
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 1 = 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 95%
compliance
5.4
© 1999 ICL Pathway Limited
‘Company-in-Confidence
Page: 14 of 20
Last Printed: 23/09/99 19:40
POL00090428
POL00090428
ICL Pathway Resolution Plan for A1408- 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 Y¥ 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) Y 718.9.99
HSH Staffing
a Train and introduce 2 additional HSH staff Y 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 (2™ line) by Y 31.8.99
31/08/99
9. Start refresher courses on call handling process (1* line) by ¥ 1.9.99
01/09/99
10. Complete refresher courses on call handling process (1* line) 30.9.99
Cash Account Domain
11. Specialist staff identified and re-deployed by 06/09/99 Y 6.9.99
12. Cash Account domain operational (wef 08/09/99) Y 8.9.99
134 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. Hold workshop with POCL (on 14/09/99) Y 149.99
© 1999 ICL Pathway Limited Company-in-Confidence Page: 15 of 20
Last Printed: 23/09/99 19:40
POL00090428
POL00090428
ICL Pathway Resolution Plan for A1408- Horizon System Helpdesk Ref. CR/ACD/408
Version: 1.5
Company-in-Confidence Date: 23/09/1999
16. Publish proposed service measurement for Cash Account calls by Y 16.9.99
16/09/99
Ly. Publication of the weekly SLA measurement, as described in On-going
section 5.3, will be on following Wednesday
18. I 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 V 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 Resoluuyn Plan for Al408- 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 1
ADVICE & GUIDANCE AD03 Level 1/2 EPOSS OPERATION ENQUIRY 354
ADVICE & GUIDANCE AD04 Level I EPOSS FALLBACK ENQUIRY 6
ADVICE & GUIDANCE ADOS Level I APS OPERATION ENQUIRY 1
ADVICE & GUIDANCE AD06 Level I APS FALLBACK ENQUIRY 6
ADVICE & GUIDANCE ADO07 Level 1 OBCS OPERATION ENQUIRY 10
ADVICE & GUIDANCE ADO09 Level I OPERATING ENVIRONMENT ENQUIRY 26
ADVICE & GUIDANCE ADIO Level 2 OPERATING ENVIRONMENT CONSUMABLE 1
ADVICE & GUIDANCE ADII Level 2 DOCUMENTATION ISSUE 1
ADVICE & GUIDANCE AD12 Level 2 SYSTEM ACCESS ENQUIRIES 33
ADVICE & GUIDANCE ADI3 Level 2 CUSTOMER COMPLAINT 2
ADVICE & GUIDANCE ADI4 Level 2 GENERAL ENQUIRY 3
OTHER CCOl Level 3 POST OFFICE - EMERGENCY CLOSURE (SHORT TERM 1
CLOSURE)
OTHER CC03 Level 3 POST OFFICE -REOPENED 1
© 1999 ICL Pathway Limited Company-in-Confidence Page: 17 of 20
Last Printed: 23/09/99 19:40
POL00090428
POL00090428
ICL Pathway Resolutivn 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 FEO! Level 3 PILE TRANSFER FAILURE 2
OPERATIONS FEO4 Level 3 INTERFACE OPERATION FAILURE I
SOFTWARE PROS Level 3 SOFTWARE ERROR DETECTED 45
NETWORK I FEO6 Level 3 CLIENT SYSTEM - NETWORK PROBLEM 3
SECURITY FEO7 Level 3 CLIENT SYSTEM - SECURITY BREACH 1
OPERATIONS FE09 Level 3 EPOSS OPERATION ERROR 23
OPERATIONS FEIO 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 HC02 Level 3 CENTRAL SYSTEM - PROCESSOR FAULT - USEABLE 1
HARDWARE HC04 Level 3 CENTRAL SYSTEM - TERMINAL FAILURE
OTHER HC09 Level 3 SYSTEM - ENVIRONMENTAL FAILURE - 2
POWER
HARDWARE HDO1 Level 3 PERIPHERAL FAILURE - PROCESSOR 19
HARDWARE HD04 Level 3 PERIPHERAL FAILURE - BAR CODE READER 4
HARDWARE HDO7 Level 3 PERIPHERAL FAILURE - COUNTER PRINTER 14
HARDWARE HDO08 Level 3 PERIPHERAL FAILURE - BACK OFFICE PRINTER 4
HARDWARE HD09 Level 3 PERIPHERAL FAILURE - KEYBOARD 2
HARDWARE HDI0 Level 3 PERIPHERAL FAILURE - MONITOR TOUCH ELEMENT 3
HARDWARE HDI Level 3 PERIPHERAL FAILURE - MONITOR "1
© 1999 ICL Pathway Limited
Company-in-Confidence
Page: 18 of 20
Last Printed: 23/09/99 19:40
POL00090428
POL00090428
POL00090428
POL00090428
ICL Pathway Resolutiva Plan for Al408- Horizon System Helpdesk Ref. CR/ACD/408
Version: 1.2
Company-in-Confidence Date: 17/09/1999
OTHER HDI2 Level 3 ENVIRONMENT FAILURE - CABLING 4
OTHER HDI3 Level 3 OFFICE ENVIRONMENT FAILURE - POWER B
HARDWARE HDI4 Level 3 EQUIPMENT DAMAGED OR DESTROYED 2
IMPLEMENTATION IMOl Level 3 PLANNED ACTIVITY RESCHEDULE I
IMPLEMENTATION 1M03 Level 3 SITE PREPARATION ISSUE 2
IMPLEMENTATION 1M07 Level 2 OTHER - 2
NETWORK NDO1 Level 3 UNABLE TO CONTACT HQ 5
NETWORK - NDO02 Level 3 NETWORK FAILURE - ISDN (WAN) 9
NETWORK ~~ I NDO3 Level 3 POST OFFICE - LINK F E 7
NETWORK NDOS Level 3 POST OFFICE - CONFIGURATION FAILURE 1
OPERATIONS OC02 Level 3 POST OFFICE - DATA DOWNLOAD FAILURE 1
OPERATIONS OD02 Level 3 EPOSS - OPERATION FAILURE Til
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 ODO8 Level 3 SYSTEM ENVIRONMENT FAILURE 1
OPERATIONS OR03 Level 3 CUSTOMER PAYMENT ISSUE 1
RECONCILIATION REOI Level 3 EPOSS 3
RECONCILIATION REO2 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
POL00090428
POL00090428
TCL Pathway Resolution Plan for ALM08- Horizon System Helpdesk Ref: CR/ACD/408
Company-in-Confidence Date: 17a 999
OPERATIONS, SC03 Level 3 CENTRAL SYSTEM - OPERATING SYSTEM - PROCESS 1
FAILURE
SOFTWARE SC04 Level 3 CENTRAL SYSTEM - OPERATING SYSTEM - ERROR 1
MESSAGE
SOFTWARE SC0S Level 3 CENTRAL SYSTEM - OPERATING SYSTEM CRASH 1
SOFTWARE SC12 Level 3 CENTRAL SYSTEM - APPLICATION ERROR MESSAGE 1
OPERATIONS Sci3 Level 3 CENTRAL SYSTEM - APPLICATION - UNABLE TO 1
PROCE: ILES
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. SD04 Level 3 EXPECTED CHANGE HAS NOT WORKED 1
SOFTWARE SD0S Level 3 OTHER 2
OTHER X105 Level 3 OTHER 175
URITY ZS02 Level 3 PMMC CARD OR PIN NUMBER LOST 3
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
POL00090428
POL00090428
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 I of 12
POL00090428
POL00090428
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
POL00090428
POL00090428
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 aed
1.1 SCOPE
2 SUMMARY
3. CRITERIA...
4 POCL POSITION.
5 PATHWAY POSITION...
5.1 AD-HOC REPORTING..........0+
5.1.1 Ad-Hoc Request - History (Action Point 1) ..
5.1.2 Ad-Hoc Request - Request Definition (Action Poin
5.1.3 Ad-Hoc Request - Process Improvement (supporting Action Point 1) .
5.2 SERVICE REVIEW BOOK memnanenere
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
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
Version: 0.2
Acceptance Incident 412 Date: 10/09/99
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.
1.1 Scope
The scope of this response comprises the original AI412, the supplementary POCL
paper A/4]2 - Service Performance Reporting and the minutes of the Acceptance
workshop of 09/09/99.
2 Summary
e Ad-Hoc Reporting - ICL Pathway accepts that the response to the particular ad-
hoc request referred to in this AI 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.
3 Criteria
No criterion is mentioned in the AI.
4 POCL position
POCL's position is represented in the AI text as:
* ICL Pathway has not responded to an ad-hoc request issued on 22/07/99
associated with the July Service Review Book
e 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
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan 7 Ref. ol
ersion: 0.
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
POL00090428
POL00090428
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
POL00090428
POL00090428
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 Turnock} 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
Lisa 08/09/99} 08/09/99} Top 10 txns for all June 99 09/08/99} Completed, results supplied
Browsden - Aug 99 for OBCS, after further clarification of
0171 400 EPOSS,APS by Product what was required, this was
8609 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
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan Ref: CRVACD/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.
¢ 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)
¢ 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
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
. Version: 0.2
Acceptance Incident 412 Date: 10/09/99
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 Inorder 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@
5.2 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 F08 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.
5.2.1. 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
POL00090428
POL00090428
ICL Pathway Acceptance Resolution Plan Ref: CR/ACD/412
. 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
POL00090428
POL00090428
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:
© 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