FUJ00119556
FUJ00119556
IN THE MATTER OF
THE POST OFFICE HORIZON IT INQUIRY
SUBMISSIONS ON BEHALF OF FUJITSU SERVICES LIMITED
IN RESPONSE TO A RULE 9 REQUEST DATED 29 APRIL 2022
These written submissions are made on behalf of Fujitsu Services Limited (“Fujitsu”) in
response to a request for information provided by the Post Office Horizon IT Inquiry
(the “Inquiry”) to Fujitsu on 29 April 2022 in accordance with Rule 9 of the Inquiry
Rules 2006, in addition to supplemental requests from the Inquiry by emails dated 24 June
2022, 14 July 2022 and 26 July 2022, (the “Requests”).
The Requests followed disclosure of the following documents by Fujitsu to the Inquiry, all
of which were created in the period 1 January 1995 to 31 December 2000 (the “Relevant
Period’):
a) Data from the PinICL archive;
b) Data from the Peak database; and
c) Data from the “Known Error Log” (“KEL”).
The Requests seek explanations in relation to (i) the classifications used in the PinICL and
KEL databases, what these represented and how they changed over time, (ii) specific
references in PinICLs to “migrations” as the cause of errors identified, (iii) the meaning
and usage of “CAP” numbers in PinICL records, and (iv) different departments within
Fujitsu’s Horizon support teams. These are addressed separately below.
BACKGROUND: PINICL AND PEAK SYSTEMS
4.
5.
PinICL was the customised incident logging and resolution tracking system adopted for
use by ICL Pathway Limited (“ICL Pathway”) to support the Horizon IT system during
the period 1996 to 2003, prior to the introduction of the Peak system in 2003. ICL Pathway
was the entity contracted to deliver the Horizon IT system during this period. Like the
PinICL system, Peak is an incident and release management system and work allocation
tool.
PinICL recorded (amongst other things) incidents:
a) identified by ICL Pathway in test systems;
b) identified by ICL Pathway during routine system monitoring;
FUJ00119556
FUJ00119556
c) raised by Post Office Counters Limited (as it then was), some of which may have
resulted from feedback received from sub-postmasters; and
d) resulting from certain calls made to the Horizon System Helpdesk by sub-
postmasters, which were deemed necessary for escalation through ICL Pathway’s
incident management process.
6. PinICL was also used to record information relating to the release of new software to the
Horizon IT system.
7. Each item logged on the PinICL system is referred to as a PinICL (collectively,
“PinICLs”).
8. In the Inquiry’s email dated 24 June 2022, it was noted that some of the data disclosed by
Fujitsu from the Peak database appeared to be duplicative of data contained in the PinICL
archive, which had already been disclosed. Fujitsu understands that, while PinICLs that
were still open when the Peak system was introduced in 2003 were migrated to the Peak
system, it appears that some of these records have also been maintained in the PinICL
archive. Fujitsu has identified approximately 13,442 documents disclosed to the Inquiry
which appear to have been maintained in both the PinICL archive and the live Peak
database. Details of these documents are set out in the “Schedule of PinICL and PEAK
Versions” (FSL 01/1).
9. Where records have been maintained in both the PinICL archive and Peak database, Fujitsu
suggests that the Inquiry refers to the version extracted from the Peak database. This is
because:
a) Peak is a live database, still currently in use, and will therefore capture any updates
to the equivalent PinICL record between the time the record was migrated and the
date on which the Peak database was extracted for the purposes of the Inquiry; and
b) records extracted from the Peak database also contain their attachments as family
member documents, where available. No such attachments are readily available in
relation to records held in the PinICL archive.
PINICL CLASSIFICATIONS
...Please can you provide an explanation of the following...The classifications that are used
in the PinICLs, such as the call type codings, category codings, priority definitions, defect
cause codings and target releases.
10. The classifications used historically in the PinICL database are set out in the following
documents, copies of which are enclosed with these submissions:
a) “PinICL Reference Data Guides” (FSL 01/2 and FSL 01/3);
b) “PinICL Training Manuals” (FSL 01/4 and FSL 01/5);
FUJ00119556
FUJ00119556
c) “PinICL Incident and Problem Management” process documents (FSL 01/6 to
FSL 01/8); and
d) an “End to End Support” process document (FSL 01/9).
11. Further detail is also provided in an earlier draft of the PinICL Reference Data Guide
entitled “PinICL User Guide” (FSL 01/10).
12. In order to assist the Inquiry’s reading of the documents and to demonstrate how the
classifications listed in the Requests changed over time, enclosed with these submissions
are the following:
a) Appendix A to these submissions is a table setting out extracts from relevant
sections of a number of the documents referred to above (see Table 1 of
Appendix A). This table should be read in conjunction with the contemporaneous
documents in full;
b) Table 2 of Appendix A is a summary of information drawn from the PinICL records
themselves as at 8 November 2002, which Fujitsu has prepared to supplement the
information in Table 1 of Appendix A; and
c) a“Schedule of PinICL Classifications” (FSL 01/11), further information in relation
to which is set out below.
Please provide a comprehensive record of what the following PinICL codes represented at
different points in time...
13. In addition to the information set out in Table 1 of Appendix A to these submissions, the
Requests seek a comprehensive record of the meaning of certain PinICL classifications
over time and the dates for which those meanings were valid. Fujitsu’s response for each
of the PinICL codes specified in the Requests is set out below.
«+-Call Type (AKA Type Coding)...
14. Fujitsu does not believe that a central history of Call Type definitions exists. This is because
(i) Fujitsu understands the table in PinICL which contained the Call Type definition was
over-written upon cach amendment to the definition, and (ii) the progress text recorded
against each PinICL (i.e. the user readable history) does not record the Call Type
description, simply the identifying letter.
15. For completeness, and to assist the Inquiry, a table of the single available archive for Call
Type definitions is set out in the “Call Type” tab of the Schedule of PinICL Classifications
(FSL O1/11).
...Response Category (AKA Category Coding)...
16. Similarly, Fujitsu understands that Response Category definitions were overwritten in the
relevant table in PinICL when they were amended. However, for this classification, the text
FUJ00119556
FUJ00119556
of each definition was re-produced in full in the PinICL progress text. In order to assist the
Inquiry, Fujitsu has parsed the progress text and identified instances when Response
Category definitions appeared to change.
. As noted in Section 15 of the PinICL Incident Management Process (FSL 01/8), Response
Categories vary according to Call Type. The “Response Category” tab of the Schedule of
PinICL Classifications (FSL 01/11) sets out, (i) the numerical value used for each of the
Response Categories, (ii) the text definition of those values, (iii) which Call Type each
definition was attributable to, and (iv) the first and last known dates these definitions appear
to have been used.
«+-Call Priority (AKA Priority Definitions)...
18.
As with the Call Type definitions, Fujitsu understands the table containing Call Priority
definitions was overwritten upon each amendment and the progress text recorded against
each PinICL included only the alphabetical identifier.
. However, the progress text does record the relevant “Target Date” each time a Call Priority
was entered. Fujitsu has therefore parsed the system calculated Target Date from the
progress text and, in order to assist the Inquiry in relation to the Requests, set out the raw
PinICL data relevant to Call Priorities (FSL 01/12). Fujitsu produced this data by, (i) taking
the first Target Date from the progress text of each PinICL, (ii) comparing this to the
timestamp that the relevant progress entry was created (Column D), and (iii) extracting the
difference in hours (Column H). Column H aims to illustrate the definition of the Call
Priorities attributable to each relevant PinICL. Fujitsu understands that PinICL did not
include non-working days in Target Date calculations.
...Defect Cause (AKA Root Cause Analysis).
20.
As with the classifications referred to above, Fujitsu understands that Defect Cause
definitions were overwritten in the relevant table in PinICL when the definitions were
amended. However, as with the Response Category, the text of each Defect Cause
definition was re-produced in full in the PinICL progress text. Fujitsu has therefore parsed
the progress text and identified instances when the Defect Cause definitions changed. The
“Defect Cause” tab of the Schedule of PinICL Classifications (FSL 01/11) sets out the
same information described in respect of the Response Category classification above,
namely (i) the numerical value used for each Defect Cause, (ii) the text definition of those
values, (iii) which Call Type each definition was attributable to, and (iv) the first and last
known dates these definitions appear to have been used.
Please confirm if it is possible to identify from the PinICL or Peak records which of the
sources listed in paragraph 5 of these submissions raised the incident.
21.
Fujitsu notes that the Requests relate to documents created prior to 31 December 2000,
which pre-date the introduction of the Peak system in 2003. These submissions therefore
concern the PinICL system only.
22.
FUJ00119556
FUJ00119556
When an incident was logged in the PinICL system, it would be allocated a Call Type. In
most cases, it would be possible to identify from the Call Type which team raised the
incident and, from that, which of the four sources referred to in paragraph 5 the PinICL
relates to. However, it may not be possible to do this for every PinICL if the incident was
raised by a team which did not have an allocated Call Type value.
Please confirm what “Target Release” indicates and what would cause it to change during
the course of a PinICL.
23.
24
When an incident was logged in the PinICL system, it was also allocated a Target Release
value. Table 1 of Appendix A to these submissions sets out extracts from relevant
documents regarding the Target Release classification, including the following extract
from the PinICL Reference Data Guide (FSL 01/2):
“For Live calls the Target Release field is initially set by a member of the SSC to the release
on which the incident occurred. For all other Call types it is set to the system default of
“Unknown”... As the project moves forward, old Target Release values become redundant
and new values are introduced.”
. Fujitsu understands that the Target Release value was updated throughout the life of a
PinICL if, for example:
a) a defect was identified, in which case the Target Release field was updated to refer
to the current proposed release that was to include the PinICL solution (see the
“PinICL MIS Reporting Requirement”, (FSL 01/13)); or
b) as stated above, old Target Release values became redundant as new releases were
rolled out (see, the PinICL Reference Data Guide, FSL 01/2 and FSL 01/3).
Please provide release dates for the Target Release codes set out in Table 2B of Appendix A.
25.
26.
Table 2B of Appendix A sets out the relevant description for the different Target Release
codes. However, Fujitsu does not hold a central record of historic releases and, accordingly,
the actual release dates of each Target Release listed (if the releases were in fact rolled out)
are not readily available. It may be possible to ascertain the actual release dates through a
manual review of Release PinICLs (as noted in the “Call Type” tab of the Schedule of
PinICL Classifications (FSL 01/11), Call Type R was largely attributable to Release
PinICLs). Fujitsu notes that undertaking such a review would likely take a significant
amount of time, but it would be content to do so, should this assist the Inquiry.
For the Inquiry’s information, the “Target Release” tab of the Schedule of PinICL
Classifications (FSL 01/11) contains information relating to (i) the number of PinICLs
attributable to each Target Release (PinICL Count Column), and (ii) the first and last
known dates the Target Releases are referred to (First and Last Date columns).
FUJ00119556
FUJ00119556
PINICL CONTENT
A number of PinICLs discuss “migrations” as the cause of errors identified. Please provide
information regarding when a migration would be carried out.
27. Fujitsu respectfully notes that it has not had reference to specific PinICLs of the type
described by the Inquiry in this aspect of the Requests and, as far as Fujitsu is aware, the
word “migration” did not have any one specific meaning during the Relevant Period.
However, Fujitsu understands that the use of “migration” in PinICLs could refer to the
following:
a) branches moving to the Horizon IT system from previous systems during the pilots
and national rollout of the Horizon IT system. An example of the data migration
that took place when some branches moved to the Horizon IT system is set out in
the document entitled “In Office Data Migration - CSR+” (FSL 01/14); or
b) the release of new or updated software, for example to add functionality to the
Horizon IT system or in response to incidents recorded in the PinICL system, as set
out in the “Pathway Release Policy” (FSL 01/15).
References in the PinICLs to “CAP”, meaning Cash Accounting Period, often have a
number associated with them, for example “CAP 25”. Please explain what these numbers
represent, whether they are universal and, if so, provide a calendar that translates the
numbers to relevant reporting periods.
28. Fujitsu understands that, during the Relevant Period, Post Office branches operated on a
weekly trading period (the “Cash Accounting Period” or “CAP”). The CAP numbers set
out in a number of PinICL records represent the relevant weekly trading period within the
financial year. As set out in the “Explanation of Local P.O Reconciliation and
Administration” (FSL 01/16), these numbers were used universally by all branches, and
their usage and calendar was set by Post Office Counters Limited. Fujitsu has enclosed
with these submissions contemporancous calendars of the CAP numbers used for the year
1999 (FSL 01/17 — 23).
29. Fujitsu notes that the “CAP” abbreviation was also used in reference to other terms during
the Relevant Period, such as “Corrective Action Plan” or the CAPs system that was being
developed by the Benefits Agency before they withdrew from the project.
BACKGROUND: KEL
30. The “Known Error Log” was a knowledge management tool used by both ICL Pathway
and Fujitsu to explain how to deal with, or work around, issues that arose in the Horizon
IT system. Each entry in the Known Error Log was referred to as a “KEL” (collectively,
“KELs”). The term “Known Error Log” or “KEL” was replaced in around July 2019 by
the term “Knowledge Base” or “KB”.
31. The content of the KEL database has changed over time, depending on the requirements of
the support units utilising it. For example, if certain systems or services ceased to be
FUJ00119556
FUJ00119556
provided or were otherwise removed from the solution, KELs relating to those systems or
services, which were then no longer relevant, may have been deleted to improve the
functionality of the database. Fujitsu understands that all recoverable KELs for the relevant
period have been provided to the Inquiry and, to the extent any KELs from this period have
not been provided, this is because they are no longer recoverable.
KEL CLASSIFICATIONS
..-Please can you provide an explanation of the following... The classifications that are
used in KELs such as type codings, status definitions and visibility definitions.
32.
33.
34.
36.
Unlike the PinICL database, which was only in place for a limited period of time, KELs
have been in place in various forms for over 20 years. By way of background, until around
July 2006, KELs were stored in a “flat-file” structure consisting of unformatted text files.
From around July 2006 onwards, these KELs were then imported to the KEL database,
which allowed for the KELs to be filtered and searched more easily. Given the passage of
time, there is limited instructive documentation available in relation to KELs prior to this
migration.
Guidance relating to the use of KELs is stored on a Fujitsu internal website for the Software
Support Centre (“SSC”). This website has been in place from at least October 2006. Copies
of the earliest identified “KEL User Guides” from the SSC website can be found at
FSL 01/24 and FSL 01/25. “Notes” and “help” pages from later iterations of the SSC
website also provide information relating to certain of the classifications listed. These
“notes” and “help” pages are enclosed at FSL 01/26 to FSL 01/66.
Pages from the SSC’s current website, providing guidance on how the SSC can create,
update and search the current KB database, are enclosed at FSL 01/67 to FSL 01/71.
. To assist the Inquiry with its review of these pages and to illustrate the development of the
classifications listed in the Requests over time, enclosed at Appendix B to these
submissions are tables setting out extracts from relevant sections of the “notes” and “help”
pages enclosed. As with Appendix A, Appendix B should be read in conjunction with the
contemporaneous documents in full. An index setting out the relevant dates for each of the
“notes” and “help” pages enclosed is also provided in Appendix C.
Given the extensive period that the KEL / KB database has been in place, Fujitsu has not
in the time available been able to identify contemporaneous documents relating to all of
the classifications listed in the Requests. Should Fujitsu identify any further documents
relevant to the Requests, Fujitsu will produce these to the Inquiry by way of supplemental
production.
FUJ00119556
FUJ00119556
ROLE OF SUPPORT TEAMS
Please explain the respective role of the various departments within Fujitsu’s Horizon
support teams.
37. The table at Appendix D to these submissions refers to contemporaneous documents which
contain explanations regarding the support teams identified by the Inquiry in the Requests,
including (i) relevant extracts from these documents setting out the respective role of each
team, (ii) whether each team constituted the first, second, third or fourth line of support,
and (iii) descriptions of how incidents moved between the various teams. Copies of the
relevant contemporaneous documents are also enclosed with these submissions.
13 SEPTEMBER 2022
INDEX OF EXHIBITS
pone Document Description Control No. URN
Schedule of PinICL and PEAK
1. FSL 01/1 Versions POINQ0125746F I FUJO0119551
FSL 01/2 PinICL Reference Data Guide FUJ00098256
2. (CM/MAN/00S - Version 1) _ I POINQ0104427F
FSL 01/3 PinICL Reference Data Guide FUJO0098258
3. (CM/MAN/005 - Version 2) POINQO104429F
FSL 01/4 PinICL Training Manual FUJ00098257
4. (CM/MAN/009 - Version 1)__ I POINQ0104428F
FSL 01/5 PinICL Training Manual FUJ00098259
.. (CM/MAN/009 - Version 2) POINQO104430F
FSL 01/6 PinICL Problem Management FUJ00098251
6. (PAPROOI4 - Version 1) POINQ0104422F
FSL 01/7 PinICL Problem Management FUJ00098252
7 (PA/PRO/014 - Version 2) POINQ0104423F
PinICL Incident Management
8. FSL 01/8 Process (PA/PRO/O14 — POINQO0104424F I FUJ00098253
Version 3)
; End to End Support Process,
9. I FSLOL/9 Operational Level Agreement I POINQ0086068F I FUJ00079897
(CS/FSP/006 - Version 2)
FSL 01/10 Draft PinICL User Guide FUJ00098255
10. (CM/MAN/005 - Version 0.1) POINQ0104426F
Schedule of PinICL
1. I FSLOI/11 Classifications POINQO125747F I FUJOO119552
PinICL data relevant to Call
12. I FSLO1/12 Priorities POINQO125748F I FUJOO119551
PinICL MIS Reporting
13. I FSLO1/13 Requirement POINQ0064668F I FUJ00058497
(CM/REQ/003 — Version 1)
In Office Data Migration — CSR+ FUJOOI18140
14. I FSLO1/14 (IM/STR/064 — Version 1) POINQ0124374F
Pathway Release Policy FUIOOIISI28
15. I FSLOI/15 (PA/STR/003 — Version 5) POINQ0124362F
Explanation of Local P.O.
16. I FSLOI/16 Reconciliation and Administration POINQ0085364F I FUJ00079193
(Version 1)
FUJ00119556
FUJ00119556
Exhibit
No. Document Description Control No. URN
17. I FSLOI/I7 Counter News POINQO0124365F I FUJ00118131
18. I FSLOI/18 1999 CAP “Rewon ~ Midlands POINQ0124366F I FUJOO118132
19. I FSLOI/19 hae hat Andis POINQ0124367F I FUJO0118133
20. I FSL01/20 I 1999 CAP Calendar — North East POINQO124368F I FUJO0118134
21. I FSL 01/21 1999 CAN Calendar Scotland & POINQ0124369F I FUJOO118135
22. I FSL01/22 I 1999 CAP Calendar— South East I pOINQO124370F I FUJO0118136
23. I FSL 01/23 ea calendar ee POINQ0124371F I FUJOO118137
24. I FSL01/24 (KELUssrGuide hin sevsion!) POINQ0104432F I FUJ00098261
25, I FSL 01/25 (KELUserGuide html sevsion 28) POINQO104433F I FUJ00098262
26, I FSL0126 I createnotes ep revisiont363) I POINQO1O4439F I FLJ00098268
27. I FSL0027 I createnotes ep revision!364) I POINQoLosasor I FUJ00098269
og I FSL01/28 (ereatensten bp revision! 365) I POINQoLo4441F I FUF00098270
29, I FSLOU29 I (ceatenotes ep revision 366) I POINQOLO44A2F I FUI00098271
30. I FSL01/30 (ereatenates bp sevsion 4o9) I POINQo104443F I FUs00098272
32. I FSL 01/32 (createnetes hp revision 792) I POINQO104445F FUJ00098274
35. I FSL 01/35 (createnates ep revision 991) POINQO104448F I FUJ00098277
FUJ00119556
FUJ00119556
Exhibit
Ne. Document Description Control No. URN
Creating New Knowledge Base
36. I FSL 01/36 articles POINQO0104449F I FUJ00098278
(createnotes.jsp_revision2279)
37, I FSL 01/37 SEP Vexion POINQO104450F I FUJ00098279
3g, I FSL 01/38 SET PLL Versione) POINQO104451F I FUJ00098280
39. I FSL 01/39 SRP Vexion Sy POINQO104452F I FUJO0098281
40. I FSL01/40 See Vesion gy POINQ0104453F I FUJ00098282
41. I FSL01/41 SOT PLL Venione) POINQO104454F I FUJ00098283
42, I FSL01/42 SPT PLL Vexiong) POINQO104455F I FUJ00098284
43, I FSL01/43 STP. Vexion 2) POINQ0104456F I FUJ00098285
44, I FSL 01/44 set oLIsh venion ye POINQ0104457F I FUJ00098286
45. I FSL 01/45 TEL PD Ite) Version 3) POINQO104458F I FUJ00098287
46. I FSL01/46 Seep ital Veron 3) POINQ0104459F I FUJ00098288
47. I FSL01/47 seep Liel Version a) POINQO104460F I FUJ00098289
4g. I FSL 01/48 CtHELPSeS31. Vesa I) POINQO104461F I FUJ00098290
49. I FSL01/49 iM PSeSsl Vesaa 3) POINQ0104462F I FUJ00098291
50, I FSL 01/50 a Seon Ns 1) POINQO104463F I FUI00098292
51, I FSLOU/SI cepa) Vesa) POINQOL04464F I FUJO0098293
52. I FSL 01/52 KEL Search Notes POINQ0104465F I FUJ00098294
(HELP1940M - Version 2)
FUJ00119556
FUJ00119556
Exhibit
No.
Document Description
Control No.
URN
FSL 01/53
Knowledge Base Search Notes
(HELP1940M - Version 3)
POINQO104466F
FUJ00098295
FSL 01/54
Creating New Knowledge Entries
(HELP3653J - Version 4)
POINQO104467F
FUJ00098296
FSL 01/55
Knowledge Base Search Notes
(HELP1940M - Version 4)
POINQ0104468F
FUJ00098297
FSL 01/56
Knowledge Base Search Notes
(HELP1940M - Version 5)
POINQO104469F
FUJ00098298
FSL 01/57
Creating New Knowledge Entries
(HELP3653J - Version 5)
POINQ0104470F
FUJ00098299
FSL 01/58
Creating New Knowledge Entries
(HELP3653J - Version 6)
POINQO104471F
FUJ00098300
FSL 01/59
Knowledge Base Search Notes
(HELP1940M - Version 6)
POINQO104472F
FUJ00098301
60.
FSL 01/60
Knowledge Base Entries: Use of
Product
(HELP4739N - Version 1)
POINQ0104473F
FUJ00098302
6l.
FSL 01/61
Knowledge Base Entries: Use of
Product
(HELP4739N - Version 2)
POINQ0104474F
FUJ00098303
62.
FSL 01/62
Knowledge Base Entries: Use of
Product
(HELP4739N - Version 3)
POINQ0104475F
FUJ00098304
63.
FSL 01/63
Support Knowledge: Use of
Product
(HELP4739N - Version 4)
POINQO104476F
FUJ00098305
64.
FSL 01/64
Support Knowledge: Use of
Product
(HELP4739N - Version 5)
POINQ0104477F
FUJ00098306
65.
FSL 01/65
Support Knowledge: Use of
Product
(HELP4739N - Version 6)
POINQO104425F
FUJ00098254
66.
FSL 01/66
Support Knowledge: Use of
Product
(HELP4739N - Version 7)
POINQO0104431F
FUJ00098260
67.
FSL 01/67
Support Knowledge: Types
(HELP117J)
POINQ0104434F
FUJ00098263
FUJ00119556
FUJ00119556
Exhibit
Ne. Document Description Control No. URN
68, I FSL 01/68 smoot EL PIOAOAD Notes I pomqoi0443sF I FU300098264
69. I FSLo1/69 I Support Knowledge: Lifecycle POINQ0104436F I FUJ00098265
70. I FSL 01/70 Creating NHELPO Entries POINQ0104437F I FUJ00098266
Support Knowledge: Use of
71. I FSLOW/71 Product POINQ0104438F I FUJ00098267
(HELP4739N)
Horizon Systems Helpdesk
72. I FSLO1/72 Processes and Procedures POINQOOS6S8IF I FUJ00080410
(CS/PRO/0048 — Version 1)
Horizon System Helpdesk Call
73. I FSLOW/73 Enquiry Matrix POINQ0086657F I FUJ00080486
(CS/FSP/0002 — Version 1)
CS Support Services Operations
74. I FSLO1/74 Manual POINQ0085987F I FUJ00079816
(CS/MAN/002 — Version 3)
Incident Management Process
75. I FSLOI/75 Definition POINQ0086036F I FUJ00079865
(CS/PRD/074 — Version 1)
OTI Test Plan
76. I FSL01/76 (ED/DOC/005 — Version 1) POINQO0124361F I FUJ00118127
EDSC Call Management
77. I FSLOV77 I Cepyprpyooo1— Version 1) __ I POINQ0124360F FUJOO118126
PinICL Administration Functions
78. I FSL 01/78 (CM/PRD/IO16 — Version 2) _ I POINQ0124372F FUJOO118138
CS Infrastructure Services
79. I FSLO1/79 Operations Manual POINQ0064674F I FUJ00058503
(CS/MAN/005 — Version 3)
Pathway Customer Service Audit
80. I FSL 01/80 POINQ0086854F I FUJ00080683
(IA/REP/025 — Version 1)
FUJ00119556
FUJ00119556
Exhibit
No Document Description Control No. URN
ICL Pathway Development
Directorate Incident/Defect
81. I FSLOI/81 Management POINQ0085994F I FUJ00079823
(DE/PRO/015 — Version 1)
FUJ00119556
FUJ00119556
APPENDIX A
CLASSIFICATION DEFINITIONS FOR THE PINICL DATABASE
1, CLASSIFICATIONS AS DEFINED IN CONTEMPORANEOUS DOCUMENTS ENCLOSED
FUJ00119556
FUJ00119556
Classification I PinICL Incident Management Process, I Draft PinICL User Guide, PinICL Reference Data Guide, PinICL Training Manual, PinICL Reference Data Guide,
30 January 1998, 15 February 2000 17 November 2000 5 February 2001 18 February 2002
{FSL.01/7}' [ESL 01/9] [ESL 01/1] [RSL 01/3)? {FSL.01/2]
‘Type Codings
[Section 7 of each document listed, unless otherwise stated]
A “Administrative use”™ “Administrative use™* - - .
[Seotions 13 and 15]
B 5 “BIT (Business Integration Testing)” = = BIC Bus. Ini.
Cc = “Cloned call” 7 z “Cloned calls — not used when logging new
calls”
D = “DIT (Direct Interface Testing” = = =
G zi =MIG (Migration Testing” : zi "BIC Rel Mig™
L “(Live) should only be used by SSC when the I “Live use error™ “The Call Type is used to determine the phase I - EDSC (SSC
call is raised on operational software on behalf of the product lifeeyele in which the incident
ofa user” [Section 3] was found. Eg. Call Type ‘Lis for Live Calls,
and may only be used by SSC!”
“Live use error” [Section 13]
M ‘Model Office raised by SIS*” [Section 13] “MOT (Model Office Test” = Z 7
N ‘Model Office raised by PDA™ [Section 13] _ I "MOR (Model Office Rehearsal)” = = =
P ‘Product error (error in product under test or I “Product error” 7 > “Any other team not covered by this list™
in test data)” [Section 3, see also Section 13]
R “Release Notice Forum” [Section 13] “Release Notice Forum” = “Release Management Forum™ “RelMngmntForum™
[Section 5.5.1]
3s : SST Gystem Testing” : - “Any System Test tean™
T “Technical query (don't know if error/usability I “Technical query” - - -
etc)” [Section 3, see also Section 13]
v = “PERF (Performance Testing” = = “BIC IntgryVor™
Y : 2K (Wear 2000 Testing” = = “SecurityPoliey
Z a “Problem Management™ “Problem Management calls™ “Problem Mg”
Section 5.5.1]
Category Codings (referred to as “Response Category” in the guidance)
[Section 8 of each document listed, unless otherwise stated]
‘Open “The Team Leader (or nominee) validates the I As described in the PinlCL Reference Data I "/NJew Call” ~ As described in the PinICL Reference Data
cell (see section 3.1), checking details and
priority level.
© If the call is valid, click on Respond and
select the TL Confirmed response
category. (This changes the call status
_from Open to Pending”
Guide dated 17 November 2000
[FSL 01/1]
Guide dated 17 November 2000
[FSL 01/1]
' For earlier classifications, see also the equivalent sections in versions one and two of the PinICL Problem Management Process documents dating from 1997 [FSL 01/5 and FSL 01/6, respectively
2 See also the equivalent sections in the PinICL Training Manual dated 19 February 2002 (FSL 01/4]
The type codings listed here in respect of the PinICL Incident Management Process dated 30 January 1998 [FSL 01/7] are said to be “
in respect of the Draft PinICL User Guide dated 15 February 2000 [FSL 01/9] refle
for those listed in the other documents set out in this Appendix A. This list is not exhaustive, For a more comprehensive
“The type codings listed her
SBTC: “Business & Technical Conformance; now known as PTU (Pathway Testing Unit)” (Section 0.4]
© The type codings listed here in respect of the PinICL Reference Data Guide dated 18 February 2002 [FSL 01/2] are said to be “the main types that we use creating a new call” [Section 7]. This list is not exhaustive
7 EDSC: Not defined but understood to refer to the “Eur
* SIS: Not det
ied but understood to refer to the “Strate;
yean Development and Support Center”,
Interface Service’
° PDA: Not defined but understood to refer to the “Programme Delivery Authority”
‘ype
see Section 7
“PinICL name for team now known as SSC.” [Section 0.4]
he list of possible call types”, albeit “most users will use one of call types P and T” {Section 13]
dings described as being “used in today's process” (see those definitions highlighted in bold text), in addition to equivalent type codings
FUJ00119556
FUJ00119556
Classification I PinICL Incident Management Process, I Draft PinICL User Guide, PinICL Reference Data Guide, PinICL Training Manual, PinICL Reference Data Guide,
30 January 1998 15 February 2000 17 November 2000 5 February 2001 18 February 2002
[FSL 017)" [FSL 01/9) [FSL 01/1] IFSL 01/3)? IFSL 012]
[Section 3]
Pending When you supply a Pending response, the call I “[W]ork in progres *[ Work in progress “A Pending call remains with the current team I As described in the PinICL Reference Data
remains with you unless you Route the call I “{I]t stays with the user unless routed I “...a Pending Response leaves the Call with I unless you use the Route button” (Section 6] Guide dated 17 November 2000
elsewhere.” [Section 15] explicit” the currently Assigned Team/Assignee” [FSL.01/I]
Final “If a call is transferred with Final status, the I “[F]ix released” “...a Final Response is routed back to the I “A Final call routes back automatically to the I As described in the PinICL Reference Data
‘appropriate process for testing or accepting I “(T]he call is routed back automatically tothe I originator by the system” call logger ~ you have completed your work on I Guide dated 17 November 2000
the response and closing the call needs to be I originator” the call and you expect the call logger to close I {FSL 01/1]
followed.” [Section 5] the call.” (Section 6]
“When you supply a Final response, the call “When a call is given a Response Category
‘automatically transfers to the originator (call with status Final, the call routes back
logger).” (Section 15] automatically 10 the call logger (or more
strictly to the Contact ~ this may have been
‘changed to reflect organisational changes)”
[Section 7]
Closed - - - - -
Response I See Section 15 for the response categories I See Section § for a “definiive Tint of all I = >
Categories I available for different call types within the I response categories” within the above statuses,
above statuses with those most frequently used highlighted in
bold and blue text
Priority Definitions”
[Section 6 of each document listed, unless otherwise stated]
A “Each call type has a set of priorities each with I As described in the PinICL Reference Data I “Description: Programme Stopped “Each call type has a set of priorities each with I As described in the PinICL Reference Data
4 target response time; this is the number of I Guide dated 17 November 2000 Days to Fix: I" 4 target response time; this is the number of I Guide dated 17 November 2000
working days within which a response is I (FSL 01/1} working days within which a response is I [FSL OWI]
expected... “Critical error which is stopping any progress I expected...
4 on that particular rig, it cannot be worked I A
Business stopped around and will cause the test windows not to I Programme stopped
J day” [Section 3.6] be met, It is only possible for there to be one I I day”
priority ‘A’ Cail on a rig at any time.”
“The progress of 'A” Priority and Fast Track Refers to the PinICL Reference Data Guide for
Calls: must be monitored hourly by the Team more detail [Section 5.4]
Leader and progress narrative added within
the required guidelines.” (Section 7]
B “Each call type has a set of priorities each with I As described in the PinICL Reference Data I “Description: Progress Stopped ‘As described in the PinICL Incident I As described in the PinICL Reference Data
@ target response time; this is the number of I Guide dated 17 November 2000 Days to Fix: 3” Management Process dated 30 January 1998 I Guide dated 17 November 2000
working days within which a response is I [FSLO1/1] (FSL 01/7] (FSL 01/1]
expected. “Highly significant error that is stopping any
B further progress either on the rig or with the I Refers to the PinICL Reference Data Guide for
Progress stopped seript being executed on the rig, e.g, the I more detail [Section 5.4]
3 days” [Section 3.6] overnight schedule cannot run due to data
c “Each call ype has a set of priorities each with I “Description: Progress Restricted “Description: Progress Restricted As described in the PinlCL Incident I As deseribed im the PinlCL Reference Data
«target response time; this is the number of I Days to Fix: 5" Days to Fix: 5” Management Process dated 30 January 1998 I Guide dated 17 November 2000
working days within which a response is [FSL 01/7) [FSL 01/1]
expected. “Error affecting how one aspect is working, I “An error which affects how one aspect is
c can be either a data problem where invalid I working. This can be either a data problem I Refers to the PinICL Reference Data Guide for
Progress restricted data is being written to the database, or a code I where invalid data is being written to the I more detail [Section 5.4]
5 days” [Section 3.6] error where the user is unable to use aI database or a code error where the user is
particular client.” unable to use a particular client.”
D “Each call ype has a set of priorities each with I As described in the PinICL Reference Data I “Description: Non-Urgent As described in the PinICL Incident I As described in the PinICL Reference Data
4 target response time; this is the number of
Guide dated 17 November 2000
[FSLO1/1]
Days 10 Fix: 10°
Management Process dated 30 January 1998
[FSL.017]
Guide dated 17 November 2000
[ESL 01/1]
"© See also Appendix B of the End to End Support Process, Operational Level Agreement dated 17 June 2003 [FSL 01/8) for information on the definition of call priorities.
FUJ00119556
FUJ00119556
Classification I PinICL Incident Management Process, I Draft PinICL User Guide, PinICL Reference Data Guide, PinICL Training Manual, PinICL Reference Data Guide,
30 January 1998 15 February 2000 17 November 2000 5 February 2001 18 February 2002
[FSL 017)" [FSL 01/9) [FSL 01/1] IFSL 01/3)? IFSL 012]
working days within which a response is
expected.
D
Non-Urgent
10 days” [Section 3.6]
“Insignificant_and usually cosmetic error,
either a documentation error or spelling error
on the system, which always has a work
around.”
Refers to the PinICL Reference Data Guide for
more detail [Section 5.4]
Defect Cause Codings (referred to as “Root Cause Analysis” in the guidance)
[Sections as stated]
‘See Table 2A
Below
“A root cause value is mandatory for all new
calls. The defect cause may change during the
life cycle of the call as investigation matures
«and a better view of the problem is identified.”
{Section 11]
“The system will enforce use of this field in two
When the Call iogger first
routes the Call to another person or team, the
system will insist on being supplied with a
value. At this point, the most frequently used
value will be “99 General — Unknown”. When
vou close a Call, the system will not accept “99
General ~ Unknown” as a valid value.”
[Section 11]
circumstances,
As described in the PinlCL Reference Data
Guide dated 17 November 2000
[FSL 01/1}
[Section 5.5.2]
“The Route Cause is specified on the same
popup as Call Effort. When the Call logger first
routes the Call to another person or team, the
system will insist on being supplied with a
value. At this point, the most frequently used
value will be “99 General ~ Unknown”. As the
call is analysed, the value should be refined:
“often the most appropriate person to do this is
the one who finds the reason for the Call. When
the Call is closed, the system will not accept
“99 General — Unknown” as a valid value.”
[Section 12]
Target Releases
[Section 3 of each document listed]
See Table 2B
Below
“Select Target Release from the pull down
‘menu - likely to be ‘Release 2.0”
“Target Release field should be used to identify
the register allocated: in some cases, this is
subdivided to indicate the release. Values are
CSR-CI2_2R, CSR-CI3, CSR-CI3_2, CSR-
C13_2R, CSR-CIR (Increments)
CSR-CI4 (CSR+)
3.0 (Beyond CSR)
RODB 2.5, RODB 2.5p, RODB 2.6 (Roll Out
Database)
NER (No Fix Required)
UNKNOWN
These releases comprise of the full Incident
Management System”
“For Live Calls, the Target Release field is
wet by a member of the SSC t0 the
release on which the incident occurred. For
all other Call types itis set to the system default
n”. The field may only be changed
by people with Local Administrative capability
(or greater). It is normally set to a value
agreed between the members of the OP!”
“For Live Calls, the Target Release field is
provisionally set by a member of the SSC to the
release on which the incident occurred. For all
other Call types it is set to the system default of
Unknown”. The field may only be changed
by people with Local Administrative capability
(or greater). It is normally set to a value
‘agreed between the members of the QFP! or
RMF" as appropriate
PTU: “Pathway Testing Unit” [Section 0.4]
" RMF: “Release Management Forum” (Section 0.4]
duality Filtering Process (a group containing representation from the Delivery Streams, B&TC and Customer Services)” [Section 0.4]
jusiness & Technical Conformance” (Section 0.4)
duality Filtering Process (a group containing representation from the Delivery Units, PTU and Customer Services)” [Section 0.4]
2. CLASSIFICATIONS AS DEFINED IN PINICL RECORDS AS AT
8 NOVEMBER 2002
A. Defect Cause Codings
Classification Description
1 Architecture - T.E.I
6 Design - Platform Design
7 Design - High Level Design
8 Design - System Outline
13 Development - Build Scripts
14 Development - Code
15 Development - Low Level Design
16 Development - Reference Data
21 Requirements
26 Integration - Build
31 Test - Test interpretation
32 Test - Script
33 Test - Data
38 General - Hardware Fault
39 General - User Knowledge
40 General - User
41 General - in Procedure
42 Gen - Outside Pathway Control
99 General - Unknown
FUJ00119556
FUJ00119556
B. Target Releases
Classification Description Classification Description
-1 Unknown 135 CSR-CBR
5 Future Unspecified 137 CSR-CI2_2R
9 PinICL 4.20 139 CSR-CI2R
10 R-Data 140 DDR - > 2
ul BI3_TRD 141 PDR - Unknown
12 BI3S30_TRD 142 3.0
15 AP-Client 143 PDR ->2
50 PIT Build _BI2 146 CSR-CI4
Sl PIT_Build_BI_2R 148 PDR - 2.1
52 PIT Build BI_2S20 150 PDR - NR2
53 PIT_Build_BI_2S20R 151 CSR
54 PIT Build BI 3 152 PDR - NR2/LT2
55 PIT Build BI 3R 154 PDR - NR2/LT1
56 PIT Build BI 3830 156 PDR - NR2/MOT
57 PIT Build BI_3S30R 159 PDR - RIc/LT1
58 PIT Build BI 3840 160 PDR - Ric
59 PIT Build BI_3S40R 167 CSR-CI3_4
60 PIT_Build_BI_3S50 169 CSR-CB_2
61 PIT_Build_BI_3S50R 170 IR - unknown
70 OCMS 1.0 172 IR - 3.0
72 OCMS_Full 173 IR->2
73 OCMS_Interim 176 IR - CSR+
74 OCMS 2 177 CSR-CI3
75 OCMS 0.1 178 IR -2.1
76 M1Clone 179 CSR-CI2
7 MRB 180 IR - NR2
78 MRA 181 IR - CSR
80 RODB 2.6 Plus 182 IR - NR2/LT2
84 RODB 2.6 184 R-NR2/LTI
86 RODB 2.5p 186 IR - NR2/MOT
88 RODB 2.5 189 IR - R1c/LTI
90 IGL 190 IR -Rle
101 Release 0.7 201 Release 0.8
108 M1Client 210 CI4MIR
0 ML 220 Cl4S10B
120 NFR - No Fix Reqd 230 CI4S10A
123 CSR-CI4L1 240 CI4S10R
125 CSR-CI4U1 241 CI4S10R-Provisional
127 CSR-CI4P3 242 CI4S10R-Authorised
128 CSR-CI4P2 245 CI4S10
129 CSR-CI4P1 259 CI4S06R
130 DTL - unknown 260 CI4S06
131 CSR-CI4RB 266 CI4S04R
132 CSR-CI4RA 267 Cl4S804
133 CSR-CI4R 269 CI4S03R
134 CSR-CI3_2R. 270 C14S03
FUJ00119556
FUJ00119556
Classification Description Classification Description
275 BLI 307 BI_3S30R-Authorised
276 BI_1R-Provisional 311 BI_3S40
277 BI_1R-Authorised 312 BL 3S40R-Provisional
280 BLIS12 313 BI_3S40R-Authorised
281 BI_IS11R-Provisional 317 BI_3S50
282 BI_1S11R-Authorised 318 BI_3SS50R-Provisional
283 BL_ISI1 319 BI_3S50R-Authorised
285 BI 2 401 Release 1.0
286 BI_2R-Provisional 410 Release la
287 BI_2R-Authorised 420 Release 1b
288 BI_2S20 424 RODB
289 BI_2S20R-Provisional 425 DPAG bid
290 CSR-CI2_2 430 Release Ic
291 BL_2S20R-Authorised 440 Release Id
295 BL3 450 Release le
296 BI_3R-Provisional 501 Release 2R
297 BL 3R-Authorised 510 Release 2.0
301 Release 0.9 520 Release 2+
305 BI_3S30 601 Release 3.0
306 BI_3S30R-Provisional
20
FUJ00119556
FUJ00119556
APPENDIX B
KEL / KB CLASSIFICATIONS.
1. TYPE CODINGS (KEL)
FUJ00119556
FUJ00119556
resolved yet."
are not resolved yet.”
Classification I Creating New KELs Creating New KELs Creating New KELs
(createnotes.jsp_revision1363) (createnotes.jsp_revision1840) (createnotes.jsp_revision1990)
16 October 2008 [FSL 01/12] 22 July 2015 [FSL 01/19} 27 November 2015 [FSL 01/20]
Information “This KEL is informative only and does I As described in the Creating New KELs I As described in the Creating New KELs
not describe a known fault.” page dated 16 October 2008 [FSL 01/12] I page dated 16 October 2008 [FSL 01/12]
Fault Fixed “The fault described on this KEL is “The symptoms described on this KEL _ I “The symptoms described on this KEL
believed to be fixed in the live system.” I are believed to be resolved in the live are believed to be resolved.”*
system.”
Unresolved “The fault described on this KEL is not I “The symptoms described on this KEL I As described in the Creating New KELs
page dated 22 July 2015 [FSL 01/19]
' Further versions of this document contain a similar definition, see also: createnotes.j
p_revision1366 [FSL 01/15]; createnotes.jsp_revision1409 [FSL 01/16]; createnotes.jsp_revision1440 [FSL 01/17]; createnotes.jsp_revision!792
d createnotes.jsp_revision1991 [FSL 01/21]
? Further versions of this document contain a similar definition, see also: createnotes.jsp_revision1364 [FSL 01/13]; createnotes.jsp_revision1365 [FSL 01/14];
createnotes.jsp_revision 1366 [FSL 01/15]; createnotes.jsp_revision1409 [FSL 01/16]; createnotes.jsp_revision1440 [FSL 01/17]; and createnotes.jsp_revision1792
createnotes,
[FSL 01/18
[FSL 01/18]
> Further versions of this document contain a similar definition, see also: createnotes.jsp_revision1991 [FSL 01/21]
4 Further versions of this document contain a similar definition, see also: as (2) above
5 A further version of this document contains a similar definition, see also: createnotes.jsp_revision1991 [FSL 01/21]
21
_revision!364 [FSL 01/13]; createnotes.jsp_revision!365 [FSL 01/14];
2. TYPE CODINGS (KB)
FUJ00119556
FUJ00119556
Classification Support Knowledge: Types Support Knowledge: Types Creating new Knowledge Base articles
(HELP117J - Version 1) (HELP117J - Version 4) (createnotes.jsp_revision2279)
15 July 2019 [FSL 01/23] 16 July 2019 [FSL 01/26] 23 July 2019 [FSL 01/22]
Fault (KBF) “A knowledge base entry which I“A knowledge base entry which I “The symptoms describe a known fault,
represents a fault in the system that
requires a root cause fix and has the
following qualities.
system is not conforming to
requirement.
e FJ Incident is with (or will be
with) the development group for
root cause fix.
© 3rd party issues also recorded
with fix time expectation.
¢ The KBF solution field may
describe a work round until fix
has been released
e The KBF is updated with fix
information (including effective
date) when fix is deployed.
Knowledge entry is _ then
deprecated.”
represents a fault in the system that
requires a root cause fix and has the
following qualities.
e System is not conforming to
requirement.
e FJ Incident is with (or will be
with) the a development group
for root cause fix.
© 3rd party issues may also be
recorded on a KBF (with fix time
expectation).
You can expect a KBF entry to be
subject to service review on a
regular basis until the fix is deployed
to live. Once the fix is deployed, the
KBF is updated with fix information
(including effective date) and then
deprecated.
It is important that the Peak field
contains the reference to the Fault
Peak being used for the development
root cause fix.
The KBF may also describe a work
round required until the fix has been
released.
There is expected to be an active
KBF entry for every unresolved fault
this should reference the ticket that the
correction is being persued on. Once the
incident has been resolved this KBF will
be deactivated”
22
FUJ00119556
FUJ00119556
which documents a work round.
© Contains troubleshooting
information: see these symptoms
take this action.
© The solution on this entry is
actionable (e.g.by a_ support
team, help desk or end user).
e Process definition is
action in this context, so SMC
entries are mainly KBI not KBA”
not an
Classification Support Knowledge: Types Support Knowledge: Types Creating new Knowledge Base articles
(HELP117J - Version 1) (HELP117J - Version 4) (createnotes.jsp_revision2279)
15 July 2019 [FSL 01/23] 16 July 2019 [FSL 01/26] 23 July 2019 [FSL 01/22]
which impacts the end user of the
service.”
Action (KBA) “A actionable knowledge base entry I “A actionable knowledge base entry I“The symptoms and the appropriate
which documents a
technical steps required to generate
an outcome.
© Symptoms: Contains a definition
of the conditions needed for the
action to be relevant i.e. see
these symptoms take this action.
© Solution: The solution on this
entry is actionable (e.g. by a
support team, help desk or end
user).
The existence of a KBA means that
there is no expectation that the
symptoms will even have a root
cause. fix.27
series of
action/workarround to implement”
Information (KBI)
“A knowledge base entry which
represents information only.
General A&G
© Expect most SMC raised entries
to be of this type
Symptom / Problem / Solution format
is not well suited to this kind of entry
but we'll continue to_maintain_this
“A knowledge base entry which
represents information only.
General advise and guidance.
Essentially, everything else.
Symptom / Problem / Solution format
is not well suited to this kind of entry
but we'll continue to maintain KBI
entries using these fields for
“This KB is informative only and will not
require any action to take place.”
© Further versions of this document contain a similar definition, see also: HELP117J - Version 2 [FSL 01/24]; HELP117J - Version 3 [FSL 01/25]; HELP117J -
Version 5 [FSL 01/27]; HELP117J - Version 6 [FSL 01/28]; and HELP117J - Version 7 [FSL 01/29]
7 Further versions of this document contain a similar definition, see also: HELP117J - Version 2 [FSL 01/24]; HELP117J - Version 3 [FSL 01/25]; HELP117) -
Version 5 [FSL 01/27]; HELP117J - Version 6 [FSL 01/28]; and HELP117J - Version 7 [FSL 01/29]
23
FUJ00119556
FUJ00119556
Classification
Support Knowledge: Types
(HELP117J - Version 1)
15 July 2019 [FSL 01/23]
Support Knowledge: Types
(HELP117J - Version 4)
16 July 2019 [FSL 01/26]
Creating new Knowledge Base articles
(createnotes.jsp_revision2279)
23 July 2019 [FSL 01/22]
way for compatibility. Expect this to
change later as we move to
Confluence.”
compatibility. Expect this to change
later as we move to Confluence.
Expect most SMC raised
(monitoring) entries to start as KBI.
I don't consider the simple "if you see
this event, ignore it” to be suitable as
a KBA, If it is found that a monitored
event leads to the generation of a
incident and some action is needed
by a later line of support, the entry
can be turned into a KBA at that
time.”*
* Further versions of this document contain a similar definition, see also: HELP117J - Version 2 [FSL 01/24]; HELP117J - Version 3 [FSL 01/25]; HELP117J -
Version 5 [FSL 01/27]; HELP117J - Version 6 [FSL 01/28]; and HELP117J - Version 7 [FSL 01/29]
24
3. STATUS DEFINITIONS
FUJ00119556
FUJ00119556
Unauthorised)”'°
Classification? I KEL User Guide Support Knowledge: Support Knowledge: Support Knowledge:
(KELUserGuide.htmI_ Lifecycle (HELP2148J - Lifecycle (HELP2148J - Lifecycle (HELP2148J -
revsion1) dated 11 October I Version 1) Version 2) Version 3)
2006 [FSL 01/10] 15 July 2019 [FSL 01/30] 16 July 2019 [FSL 01/31] 20 July 2020 [FSL 01/32]
Unauthorised I “Status ( Authorised or - - -
Authorised or
Active
“Status ( Authorised or
Unauthorised)"
“Entry is current and in
use’
As described in the Support
Knowledge: Lifecycle page
dated 15 July 2019
As described in the Support
Knowledge: Lifecycle page
dated 15 July 2019
Deprecated
“Information is no longer
current. Becomes a candidate
for deletion later. e.g.
e Fault has been fixed in
version x
e¢ Reference data induced
fault. When fixed
becomes a_ deprecated
entry (because no longer
current)
When deprecated, the person
updating is asked for a brief
reason which is logged into
the KBx history”®
° Although not referenced in the documents enclosed, it is understood that in circumstances where a new version of a KEL or KB is rejected, the classification
“Rejected” may be used
‘© A further version of this document contains a similar definition, see also: KELUserGuide.html_revsion!28 [FSL 01/11]
‘I A further version of this document contains a similar definition, see also: KELUserGuide.html_revsion128 [FSL 01/11]
!2 A further version of this document contains a similar definition, see also: HELP2148J - Version 3 [FSL 01/32]; and HELP2148J - Version 4 [FSL 01/33]
3 Deprecated is understood to be an automated internal status used when a version of a KEL is superseded and becomes no longer searchable by the Fujitsu
support, test and development teams. In this version of the HELP page, the term was attributed inadvertently to a description of the “Deactivated” status. This
was corrected in HELP2148J - Version 2 [FSL 01/31]
25
FUJ00119556
FUJ00119556
required. e.g. Facility / Server
has been removed from
service
When deleted, the person
updating is asked for_a brief
Knowledge: Lifecycle page
dated 15 July 2019
Classification"? I KEL User Guide Support Knowledge: Support Knowledge: Support Knowledge:
(KELUserGuide.html_revsi I Lifecycle (HELP2148J - Lifecycle (HELP2148J - Lifecycle (HELP2148J -
onl) dated 11 October 2006 I Version 1) Version 2) Version 3)
[FSL 01/10] 15 July 2019 [FSL 01/30] 16 July 2019 [FSL 01/31] 20 July 2020 [FSL 01/32]
Deactivated - - “Information is no longer I “Information is no longer
current. Becomes a candidate I current. Becomes a candidate
for deletion later. e.g. for deletion later. e.g.
© Fault has been fixed inI ¢ Fault has been fixed in
version x version x
e Reference data induced I ¢ Reference data induced
fault. When fixed becomes fault. When fixed becomes
a deactivated — entry a deactivated — entry
(because no longer (because no longer
current) current)
When deactivating, the I When deactivating, __ the
person updating is asked for a I person updating is asked for a
brief reason which is logged I brief reason which is logged
into the KBx history.” into the KBx history.
If the KB is SPM affecting it
cannot be deactivated without
authorisation from the
service
management team”'*
Deleted - “Information is no longer I As described in the Support I As described in the Support
Knowledge: Lifecycle page
dated 15 July 2019
'4 Although not referenced in the documents enclosed, it is understood that, where a new version of a KEL or KB is rejected, the classification “Rejected” could
be used
'S A further version of this document contains a similar definition, see also: HELP2148J - Version 4 [FSL 01/33]
26
FUJ00119556
FUJ00119556
peason which is logged into
the KBx history”'®
'© A further version of this document contains a similar definition, see also: HELP2148J - Version 3 [FSL 01/32]; and HELP2148J - Version 4 [FSL 01/33]
27
4, VISIBILITY
FUJ00119556
FUJ00119556
Classification KEL User Guide (KELUserGuide.html_revsion1) Creating New Knowledge Entries
dated 11 October 2006 [FSL 01/10] (HELP3653J - Version 2)
16 July 2019 [FSL 01/35]
H (High) — “Visibility ( High, Medium and Low )” -
No longer in use!”
M (Medium) — “Visibility (High, Medium and Low )”” -
No longer in use
L (Low) — “Visibility ( High, Medium and Low )”™ -
No longer in use
Eventing Only - “Used by the SMC to allow their searches to be targeted at
monitoring knowledge only.”!
General Usage
“The default for any knowledge entry raised by a resolver
group such as a 3LS team.”
7 See the Creating New KELs page (createnotes,jsp_revision1363) dated 16 October 2008 [FSL 01/12], which states “Once used to indicate how visible (or
critical) a problem was perceived to be. At the moment — unused”
'8 A further version of this document contains a similar definition, see also: KELUserGuide.html_revsion128 [FSL 01/11]
'® A further version of this document contains a similar definition, see also: KELUserGuide.html_revsion!28 [FSL 01/11]
°° A further version of this document contains a similar definition, see also: KELUserGuide.html_revsion128 [FSL 01/11]
*! Further versions of this document contain a similar definition, s
HELP3653J - Version 5 [FSL 01/43]; and HELP3653J - Version 6 [FSL 01/44]
» Further versions of this document contain a similar definition, see also: HELP3653J - Version 3 [FSL 01/37]; HELP3653J - Version 4 [FSL 01/40];
HELP3653J - Version 5 [FSL 01/43]; and HELP3653J - Version 6 [FSL 01/44]
28
also: HELP3653J - Version 3 [FSL 01/37]; HELP3653J - Version 4 [FSL 01/40];
APPENDIX C
FUJ00119556
FUJ00119556
INDEX OF “NOTES” AND “HELP” PAGES ENCLOSED
Exhibit No. Filename Approximate Date Created
FSL 01/10 KELUserGuide.html_revsion1.pdf 11/10/2006
FSLOI/I1 KELUserGuide.html_revsion128.pdf 18/01/2007
FSL 01/12 createnotes jsp_revision1363.pdf 16/10/2008
FSL 01/13 createnotes.jsp_revision1364.pdf 16/10/2008
FSL 01/14 createnotes.jsp_revision1365.pdf 16/10/2008
FSL 01/15 createnotes jsp_revision1366.pdf 16/10/2008
FSL 01/16 createnotes.jsp_revision1409.pdf 15/05/2009
FSL 01/17 createnotes.jsp_revision1440.pdf 01/06/2010
FSL 01/18 createnotes.jsp_revision1792.pdf 20/04/2015
FSL 01/19 createnotes.jsp_revision1840.pdf 22/07/2015
FSL 01/20 createnotes jsp_revision1990.pdf 27/11/2015
FSL 01/21 createnotes.jsp_revision1991.pdf 27/11/2015
FSL 01/22 createnotes.jsp_revision2279.pdf 23/07/2019
FSL 01/23 HELP117J - Version 1 pdf 15/07/2019
FSL 01/24 HELP117J - Version 2.pdf 16/07/2019
FSL 01/25 HELP117J - Version 3.pdf 16/07/2019
FSL 01/26 HELP117J - Version 4.pdf 16/07/2019
FSL 01/27 HELP117J - Version 5.pdf 16/07/2019
FSL 01/28 HELP117J - Version 6.pdf 20/07/2020
FSL 01/29 HELP117J - Version 7.pdf 12/07/2021
FUJ00119556
FUJ00119556
Exhibit No. Filename Approximate Date Created
FSL 01/30 HELP2148J - Version I.pdf 15/07/2019
FSL01/31 HELP2148J - Version 2.pdf 16/07/2019
FSL 01/32 HELP2148J - Version 3.pdf 20/07/2020
FSL 01/33 HELP2148J - Version 4.pdf 12/07/2021
FSL 01/34 HELP3653J - Version 1.pdf 15/07/2019
FSL 01/35 HELP3653J - Version 2.pdf 16/07/2019
FSL 01/36 HELP1940M - Version 1.pdf 18/08/2017
FSL 01/37 HELP3653J - Version 3.pdf 16/07/2019
FSL 01/38 HELP1940M - Version 2.pdf 13/08/2018
FSL 01/339 HELP1940M - Version 3.pdf 16/07/2019
FSL 01/40 HELP3653J - Version 4.pdf 16/07/2019
FSLO1/41 HELP1940M - Version 4.pdf 17/08/2020
FSL 01/42 HELP1940M - Version 5.pdf 25/01/2021
FSL 01/43 HELP3653J - Version 5.pdf 20/07/2020
FSL 01/44 HELP3653J - Version 6.pdf 12/07/2021
FSL 01/45 HELP1940M - Version 6.pdf 24/01/2022
FSL 01/46 HELP4739N - Version I .pdf 08/08/2019
FSL 01/47 HELP4739N - Version 2.pdf 08/08/2019
FSL 01/48 HELP4739N - Version 3.pdf 08/08/2019
FSL 01/49 HELP4739N - Version 4.pdf 08/08/2019
FSL 01/50 HELP4739N - Version 5.pdf 17/08/2020
FSLO1/51 HELP4739N - Version 6.pdf 22/02/2021
FSL 01/52 HELP4739N - Version 7.pdf 31/01/2022
30
FUJ00119556
FUJ00119556
APPENDIX D
Team
Department!
Line of
Support
Description (and source, where available)
HSH
Horizon System
Helpdesk
First
“provides Post Office Counters Ltd outlet staff with a single point of contact for
dealing with all problems relating to the Horizon system procedures and the
Horizon system installed in outlets, and also for OBCS fallback encashments.
Additionally it provides a single point of contact for technical interface queries
from POCL (HAPS) staff via the NBSC helpdesk. Any calls received which are
inappropriate to this helpdesk may be re-directed to the appropriate service
point.” (Horizon Systems Helpdesk Processes and Procedures, p.7, FSL 01/72).
“provides first level support for all technical issues. The Horizon System
Helpdesk staff will record details of the issue or request by ascertaining
information from the customer regarding the nature and impact of the problem,
the Horizon System Helpdesk operator will be able to resolve or diagnose the
problem during this initial telephone conversation. Should the operator fail to
resolve the problem at this time, he will route the incident onto a second line
support unit and inform the customer what to expect and when.” (Horizon
System Helpdesk Call Enquiry Matrix, p.5, FSL 01/73).
HIT
HSH Incident Team
First
The HSH Incident Team formed part of the HSH. However, Fujitsu has only
seen references to this team in documents post-dating the period relevant to this
Request.
SMC
System Management
Centre
Second
“On receipt of a call from the HSH, the SMC's first task is to determine whether
or not the service call is a software code problem.
If the service request call indicates a software problem which has been seen
before, and for which a workaround is already available, the SMC follows its
' A wide range of other teams were involved in the management of PinICLs and KELs, as demonstrated by ICL Pathway Development Directorate
Incident/Defect Management, (FSL 01/81).
31
FUJ00119556
FUJ00119556
Team
Department!
Line of
Support
Description (and source, where available)
own internal procedures to ensure that the workaround is passed to the
customer.
If the service request call indicates a software problem which has been seen
before, and for which a workaround is not available, the SMC links the current
call to the first call and does not pass the call to the SSC. This ensures that the
SSC does not receive duplicate calls for the same problem.
If the service call indicates a software problem that has not been seen before,
the SMC follows its own internal procedures to pass the call to the SSC,
providing information about the problem and Pathway’s exposure, that is, the
number of calls received and the potential number of counters that are affected.
They also provide details about the software version installed on the platform.
(CS Support Services Operations Manual, p.12, FSL 01/74)
SSC
System Support Centre
Third
“On receipt of an incident PinICL the SSC investigate the incident. If on
investigation the SSC determine that:
e The incident was incorrectly routed, it is passed backed to the SMC to
route to the appropriate support unit (Section 4.2.1.1).
e = The incident is a business incident, and not system related, it is routed
through to the MSU (Section 4.3.2.1).
e = The incident is a reference data incident it is routed through to the
Reference Data Team (Section 4.3.3.1).
e = The incident is a known error, it is passed backed to the SMC to deal
with (Section 4.2.1.1).
e = The incident is already known, i.e. it is a duplicate incident, the SSC
associate the duplicate PinICL to the original PinICL and close the
duplicate PinICL. Go to Section 4.3.1.3 for the SSC closure process.
32
FUJ00119556
FUJ00119556
Team
Department!
Line of
Support
Description (and source, where available)
If none of the above apply, the incident is either resolved by the SSC or routed
to 4th line support for resolution. However, a decision first has to be made as to
whether a business incident is associated with the incident being dealt with. If
so, the SSC will raise a new business incident with the HSH (Section 4.1.1).
The SSC raise a KEL for incidents that they have not come across before and
require further work and time before they are resolved. This is then used by the
SMC to stop duplicate incidents being sent through to the SSC.
If a workaround can be developed, it is added to the respective KEL to be used
as required. If the workaround requires agreement from [POL], a Problem is
raised to obtain the agreement.
If the incident cannot be resolved by the SSC, it is passed to 4th line support
(Section 4.4.1) for resolution. If the SSC can resolve the incident, the
appropriate actions are taken until the incident is ready for closure (Section
4.3.1.3).” (Incident Management Process Definition, p.22, FSL 01/75)
EDSC
European
Development &
Support Centre
Third
“EDSC are organisationally positioned within ICL Pathway and are
responsible for the provision of 3rd line software support.” (OTI Test Plan, p.3
FSL 01/ 76).
“EDSC identify area of problem and call is directed to appropriate 4th line”
(EDSC Call Management, p.5, FSL 01/77).
“... This has been replaced by SSC. For technical reasons, the team in PinICL is
still referred to by this abbreviation.” (PinICL Administration Functions, p.3,
FSL 01/78)
33
FUJ00119556
FUJ00119556
Team
Department!
Line of
Support
Description (and source, where available)
MSU
Management Support
Unit
Third
“The Management Support Unit supports the ICL Pathway operation in the
following areas:
e Management Information Systems
e Information technology equipment
e EPOSS and APS transaction reconciliation
e = Performance benchmarking”
(CS Infrastructure Services Operations Manual, p.8, FSL 01/79. See sections 4.1
to 4.4 for further information on each of the above areas)
MSU-Indt
Mgt
Management Support
Unit — Incident
Management
Third
For organisational purposes, “MSU Indt Mgt” was used in PinICL to route calls
relating to reconciliation incidents to certain individuals within the MSU
(classed as “incident management”). For more detail, see “EPOSS and APS
transaction reconciliation’, section 4.3, CS Infrastructure Services Operations
Manual, FSL 01/79.
Reconciliation incidents were also referred to as Business Incidents, and vice
versa, during the relevant period (see Pathway Customer Service Audit, FSL
01/80).
QFP
Quality Filtering
Process
Third
“QFP Representatives are identified for each of the Delivery Units.
QFP Administration maintains a list of these representatives.
QFP Administration assigns Incidents to the OF P Representatives for analysis.
The OFP Representatives are responsible for ensuring that either the Incident is
recommended for closure or a potential product defect is identified.
34
FUJ00119556
FUJ00119556
Team
Department!
Line of
Support
Description (and source, where available)
If the Incident has been incorrectly assigned it is returned with a
recommendation as to where it should go...”
“If the OFP Representative believes this Incident or this Incident plus others
reveals a design weakness then it can be escalated to the TDA as a Problem and
progressed in accordance with the ICL Pathway Development Directorate
Problem Management Process, PA/PRO/O16...”
“...The OF P Representative ensures that all solution components are identified
and can be progressed satisfactorily. If appropriate, a workaround solution may
be required for the current baseline as well as a longer-term solution or
consequential work may be required in another Delivery Unit, which has to be
worked on in parallel.
Copy (Clone) PinICLs should be used for this task with a separate PinICL
raised for each piece of work. The PinICL should be updated with a clear set of
instructions so that the relationships are clear. The procedure for raising clone
PinICLs is covered in the PinICL Reference Data Guide CM/MAN/005.
Discussion with CS ifa KEL entry is required or needs to be updated. The
Procedure for updating/creating KELs is contained in the PinICL Reference
Data Guide CM/MAN/005” (ICL Pathway Development Directorate
Incident/Defect Management, p.13 — 19, FSL 01/81).
35