WITNO7260100
WITNO7260100
Witness Name: Neville Brian Gallacher
Statement No: WITNO7260100
Date: 16 March 2023
POST OFFICE HORIZON IT INQUIRY
FIRST WITNESS STATEMENT OF NEVILLE BRIAN GALLACHER
I, NEVILLE BRIAN GALLACHER, will say as follows:-
INTRODUCTION
1. lama former employee of Fujitsu Services Limited (Fujitsu). I left Fujitsu in 2017
and I am currently retired.
2. This witness statement is made to assist the Post Office Horizon IT Inquiry (the
Inquiry) with the matters set out in the Rule 9 Request provided to me on 1
February 2023 (the “Request”), to the extent I have or had direct knowledge of
such matters. I was assisted in preparing this statement by Morrison Foerster, who
represent Fujitsu in the Inquiry.
Page 1 of 7
WITNO7260100
WITNO7260100
3. The topics set out in the Request concern events that occurred between 5 and 23
years ago. However, many of the topics in the Request relate to the work of the
Horizon System Helpdesk/Horizon Service Desk (HSH/HSD). I did not work
directly with the HSH/HSD and my knowledge of these topics is therefore limited.
4. I have set out my best recollection of events in this statement. While I have tried
my best to recall these events, due to the time that has passed, there are areas
where my recollection is unclear or limited.
BACKGROUND
5. I joined the civil service in June 1989 as an Administrative Assistant and
transferred to Virtual Machine Environment (VME) Operations in June 1990. I was
a computer operative responsible for printers, computer tapes, and some aspects
of IT mainframe support. In 1991 the Information Technology Service Agency
(ITSA) was formed and was the primary IT arm of the civil service. My role meant
that I was now part of ITSA. Sometime around 1993 I transferred to UNIX support
as a Customer Support Specialist, still within ITSA, providing support for various
Department of Social Security (DSS) UNIX servers. In August 1995 I became an
Executive Officer, still primarily focusing on supporting UNIX operating systems.
6. ITSA was outsourced to ICL in 1996. My job title changed to Technical Support
Specialist although it was still the same role. In January 1997 I moved to a more
general UNIX Support team for the DSS accounts to support a much larger
distributed estate. The DSS had a large number of UNIX servers/services
scattered around the country in DSS offices and, if there were issues with these
units, the Distributed System Support team would be contacted to resolve the
Page 2 of 7
WITNO7260100
WITNO7260100
problem. We were not a helpdesk — we were a step back from that, providing
specialist technical support. This would also involve monitoring software updates
to the various UNIX systems.
7. Imoved to the Management Support System team (the MSS) for the DSS accounts
in about 1999, and in 2000 I was brought on to the Pathway project. I remained a
Technical Specialist at various levels, working on the Post Office Account until I
left Fujitsu in 2017.
8. I have a BTEC Higher National Certification in Computing from the University of
Central Lancashire. In 1999, I achieved a Microsoft Certified Systems Engineer
certification, which allowed me to work with different operating systems (such as
Windows).
TECHNICAL SUPPORT
9. The Pathway project in our area consisted of MSS and the System Management
Group (SMG). MSS were responsible for support and SMG for development. I
started off working in support, and at some point (I cannot recall exactly when), I
moved to the development team.
10.My technical support role in the MSS involved supporting the Tivoli Management
Framework (TMF) system after it had been integrated into Horizon. TMF was a
system which allowed administrators to manage large numbers of remote locations
or devices. There were multiple administrator roles across different teams within
Fujitsu such as SECAUD (Security Auditor), SECMAN (Security Manager),
SMCTECH (SMC Technician), SMCTEAM (SMC Teamleader) SMCNT (SMC
Operating system), SMCDBA (Database Administrator). These roles were all
Page 3 of 7
WITNO7260100
WITNO7260100
defined and setup prior to my move to the project and were designed to restrict
access to required areas only and provide a full audit trail.
11.1 attended various courses on the TMF system as part of my initial training for this
role. I did not receive any training on using the Horizon counter application as it
wasn’t accessed by MSS/SMG. One of the main aspects of TMF was software
distribution to central servers and Post Office counters — software would be
received from the Release Management team and packaged and distributed to the
required platform via the Tivoli product.
12.The MSS was not responsible for the software that was being distributed or
installed on the counters. The software would come packaged to us as a bundled
unit from the Release Management team and we would deliver it to the counters
via TMF - we did not deal with its contents.
13.We also provided support to the Systems Management Centre (SMC), which was
responsible for monitoring the “distribution engines” (which pushed software out to
the counters) during the allocated distribution windows (usually between 8.30pm
and 6am, when the Post Offices were closed). The SMC would contact the MSS if
they spotted any issues preventing distribution and we would point them to the
technical solution. Any IT system can have glitches but in general, from the
perspective of the MSS, the system was operating as we expected.
14.We would also occasionally provide support to the SMC in relation to issues being
experienced on the counters and central servers but this was usually restricted to
advising them of the appropriate team to pass the call to. Calls by postmasters to
the HSH/HSD about these issues would not be passed to me.
Page 4 of 7
WITNO7260100
WITNO7260100
15.1 used the Peak system to log progress updates for problems that came to me
through the SMC. These Peaks were then either closed or updated and passed to
other teams. However, the Peaks I dealt with were never from postmasters — I only
ever dealt with Peaks that were passed to me by the SMC, although information
from a postmaster may sometimes have been added to the call by the SMC. These
Peaks may have originated from calls to the SMC by other management teams
further up the chain or by a postmaster to the HSH/HSD, which was passed to the
SMC. I never dealt with postmasters directly. I remember hearing about PowerHelp
and PinlCL systems but they were never something that I dealt with.
16. Occasionally I would write or contribute to a Known Error Log (KEL) to explain how
or why something technical was occurring, and these KELs were made available
to the support teams. These could also be attached to call records. The purpose
of a KEL was to provide a solution that could resolve the problem until such time
as a software solution could be released, as the software solution had to be
designed, developed and tested before it could be implemented. I would also
sometimes be involved in resolving incidents not relating to Tivoli, such as Oracle
errors and Disk space errors.
17.As part of the MSS support team I had access to certain aspects of the live system,
specifically the Windows NT Operating System, via the Tivoli toolset. This was
needed as the various management support systems need managing as well, i.e.
Disk space management, monitoring relay servers, database administration etc.
Access to the live system via Tivoli was tightly regulated and audited using unique
logins, passwords, and keycard access to the room where the MSS sat. Our
Page 5 of 7
WITNO7260100
WITNO7260100
access to systems was to the NT operating system only, not the applications. We
could not change any transactional data on the counter and did not have access
to transaction data. We also did not have access to the counter applications — only
the Windows NT operating system.
SMG DEVELOPMENT TEAM
18.At some point (I cannot remember exactly when) I transferred from working in the
support team to working in development for the System Management Group
(‘SMG’), who worked alongside the MSS. The development team focused on
integrating management suites, which is essentially a collection of software, and
looking at whether we could offer more tools to the SMC - this was a bit more
forward-looking than the work done by the support team. I solely worked in
development for the SMG and was not involved with the live support team. My role
in development involved creating some Tivoli tools to help other teams remotely
manage some aspects of the servers such as stop/start processes, retrieve log
files, check connectivity etc. through an audited Tivoli account.
HSH/HSD
19. The Inquiry has asked me to describe my experiences working on the HSH/HSD
and whether in my view the HSH/HSD provided adequate support to postmasters.
As I mentioned above, I did not work directly with the HSH/HSD. There may have
been times where I indirectly provided support to these teams
Page 6 of 7
WITNO7260100
WITNO7260100
through my work with the SMC or via the Peak system, but I cannot recall any
specific examples of this.
BUGS, ERRORS AND DEFECTS
20.In the Request, the Inquiry has asked me whether I was aware of any bugs,
errors or defects within the Horizon system.
21.Given the nature of my position I was aware of general issues within the Horizon
system, as these would be assigned to my team to resolve. I do not recall these
being unusual or alarming in comparison to other systems I had previously
worked with. In instances where my team were struggling to resolve an issue, we
could raise a trouble ticket with a team at Tivoli who would assist in providing
technical support, but we did not need to do this often. Whilst some items were
more complex than others, I do not recall being aware of issues that couldn't be,
or weren't, resolved.
Statement of Truth
Page 7 of 7