Horizon Error Root Cause Project
Final Report
Completed by Joyce Daggett
Horizon Error Root Cause and Reduction
Manager
34 October 2000
Contents
POL00334154
Id
lo
»
»
®
>
moa
Management Summary
Background
The Approach
Findings
Solutions/ Recommendations
Conclusion
Summary of Solutions and Recommendations
Background
Project Terms of Reference
Scope
Specific Objectives
Deliverables
Responsibilities
The Approach
Team Purpose
The September 99 Root Cause forum
The Root Cause User Workshop
The Solution Workshop
Findings and Recommendations
Forms and Supporting Documentation
Observation Study - Benchmarking
Product Design
TP Internal Processes
Conformance
Service Improvement Process
Training
Business Targets and KPI's
Measurement of the Project’s Success
Impact of other initiatives
ECCO+
Learning Points for ERA Project
Project Costs
Appendix List
Outline responsibilities of members of cross functional team for Error
Root Cause and Reduction
Top 10 Errors by volume for May 2000
Root Cause Maps, outputs of the User Group Workshop
Steering group activity plan
Transaction Processing Error Root Cause Impact Calendar
11
11
12
12
13
14
15
15
16
17
18
19
19
20
BaR
38
POL00334154
POL00334154
1.0 Management Summary
1.1 Background
The project was sponsored by Alan Barrie, PON Operations Director, on
behalf of the NRO Board. It was established to investigate the increase in
error levels when offices migrated to the Horizon automated platform. The
impact in TP was the need to recruit extra staff to deal with these errors. A
Business Case produced by the Automation Directorate showed a cost of
£500k for the extra staff against the significant risk of not settling accurately
with Clients. The key deliverables of the project were to find the root cause,
identify solutions to reduce the levels back to pre migration levels or below
and either implement where practical and or identify ongoing processes to
minimise this effect.
1,2 The Approach
The project duration was three months, lead by a dedicated senior manager.
The approach was through a virtual team, of an empowered Steering Group
(roles and responsibilities detailed in Appendix A), and a workshop
involving First Line users. The project drew from and built on the work done
by the Data Integrity Project, one of the National Roll Out preparation
projects.
The Steering Group starting point was to take the top ten categories of error
from the Transaction Accuracy Measurement Database, which is held and
analysed in Transaction Processing. An explanation of this process is at
Section 4.2.
The Steering group commissioned the Root Cause Workshop, agreeing the
purpose and proposing the membership. The workshop took the “whats”
and looked at the groups of products within the categories and asked the
question why,
1.3 Findings
The root causes for the largest category ranged from;
¢ balancing procedures not clear
¢ reversal process too difficult
¢ not sure what screen they are in so do not input the figure
¢ not being aware until much later that they have done it incorrectly
¢ icon layout different between screens in serve and IN Rem
¢ tired at the end of the day
There is no one root cause to explain why postmasters make an error.
Having performed root cause analysis on all the categories the causes could
be clustered under eight groups; System Related, Training, Human Computer
3
POL00334154
Interface, Process/Procedures and Conformance, Communication, Business
Change, Management Information and Helpline.
An analysis of errors being made by office type was undertaken and shows
that the relative error rates have not changed significantly in any one office
type, they have increased across the board.
1.4 Solutions/Recommendations
The solutions were generated and prioritised by the Steering Group and eight
clear solutions were recommended. They are summarised at Section 5.
In addition a number of simple solutions have been implemented.
e Aseries of work aids covering - The most frequently asked questions on
the Helpdesk along with their answers, The top ten errors and how to
avoid them, Handy Hints and Tips - have been produced and are being
passed through the process for feeding into Counter News.
¢ Comments have been fed into the team who produce Horizon Balancing
guide for future improvements.
¢ Comments fed to Steve Gibbs to assist on his work outlining the principles
of how to operate out of hours stock units.
The Steering Group will come together once more in November to measure
the success to date and identify how any outstanding actions can be reported
through to the NRO Board to ensure that they are updated and cleared. A
matrix at Appendix E describes how potential initiatives have an impact on
the reduction in errors.
1.5 Conclusion
In conclusion the activities and initiatives described in recommendations/
solutions will reduce the errors to below the manual baseline once roll out is
complete, provided, and this is key, the solutions are effectively deployed.
The latest trends are showing an improvement in the level of increase of
errors when outlets first migrate and for the first time we are seeing a
shortening in the length of the learning curve. The conclusion that can be
drawn on this is the impact of the preparation projects done before National
Roll Out.
This piece of work did not look at the fundamental issues of why we get any
errors at all. This is within the scope of the ERA programme with it’s design
principles to simplify transaction, remove the Cash Account and maintain a
single stream of data. This piece of work has not been able to evaluate the
impact of the CSR+ upgrade.
POL00334154
The board are asked to sponsor;
¢ £10,000 to commission Research Services to undertake the Observation
Study. This will take account of the findings within the HEB study and
looks specifically at how good and bad outlets are using the User and
Balancing Guides. These guides detail what the standard procedures
should be.
¢ £6,500 for CM2 resource for three months to prepare the small business
cases and co-ordinate the activities.
1.6 Summary of Solutions and Recommendations
POL00334154
Ref I Cluster Root Cause Solution Potential Impact on Errors
No Heading
5.1 _ I Process/ Forms and Supporting, Short To medium term - resource to look at all forms This has the potential to reduce the incremental errors by 10% or
procedure/ I Documentation not aligned I and align to system and link into the work being carried I £30k in costs.
conformance I with Horizon screen out by the Service Delivery Planning Team. Resource is required to prepare a simple business case, to target
formats Long term - pass to ERA to migration stages build in. the rogue forms and identify production and distribution costs
3.2 I Process/ No standard way to do Observation Study, building on the work done by John _ I The study would cost £10k. Resource would be needed to
procedure/ I things, no process to share I Evans, conducted by Research Services. To look at how _I evaluate the findings and produce a business case to deploy the
conformance I best practice. the User Guides and Balancing guides which detail the recommendations. If cost effective, a further 10% reduction in
processes are being used in good and bad offices. errors is realistic.
5.3 I Process Complex and different Product Design in TP needs to take account of impact on I Short Term - none
procedure/ I procedures for products __I potential errors when assessing options for new Medium Term - no significant increases in errors as a result of
conformance products, Solution is accepted and is to be deployed. new products.
Long Term ERA to pick up and design errors out
54 Process/ Not being told early that Transaction Accuracy Measure will explain the cause of I The work of the TAM is assessing impact on errors and it should
procedure/ I error has been made and the error, the timing is still constrained to when the not be double counted here.
conformance I information not always error has been resolved.
easy to understand
55 I Process/ No policy on conformance I The Business Develop a policy backed up by aharder __I This measure is dependant on the previous solutions being in
procedure/ approach to non conformance place and builds on the TAM improvement activity.
conformance
5.6 I System Tcons in different places or _I Service Improvement Process to be defined and Proper impact assessment on Service Improvements will identify
Related different naming regimes _I deployed. TP already engaged with BSM reduction in errors along with the cost of the change
5.7 Training, Dissatisfaction with Transaction Processing and Business Service The cost benefit of this approach will need to be evaluated. Part of
Training, Management work jointly to identify problem offices & _ I the joint work will be to identify and prioritise target outlets and
to ask the residual HFSO’s in the territories to give assess the impact on a small number of outlets. TAM will play an
refresher training. This approach has been agreed integral part in informing decision making.
within TP/BSM.
5.8 Business Conflicting / missing KPI I The introduction of the Transaction Accuracy Measure _ I Transaction Accuracy Measure has it’s own business case to.
Change Targets e.g. Increase Sales, I onto the scorecard will allow a balance to be made deliver benefits.
reduce waiting times both
at the detriment to back
office procedures where
against the other KPI's
POL00334154
errors occur.
2.0 Background
In September 1999 during Live Trial and as part of the Data Integrity
Preparation Projects, a team was set up to undertake a Root Cause Analysis
Workshop with the aim of establishing the cause of errors being generated by
the live trial offices. This group of people looked at the nine main error areas
and identified some solutions to them. They were looking for short term
solutions that could be implemented before National roll out. Unfortunately
no measures were put in place to monitor the effectiveness of these solutions,
and due to major business reorganisation (SCS) people have moved on.
Therefore there was no body of people left to take this initial piece of work
forward .
At week one of the new financial year as the roll out of Horizon continued,
Post Office Network (Transaction Processing) became increasingly concerned
at the volume of errors being generated by automated outlets, given the
impact on clients, customers, costs and the integrity of business data. The
error baseline of 0.63 errors per office continued to rise to an unacceptable
level (see Table 1.). A business case was produced with the help of the
Automation Directorate for £0.5k to cover the anticipated extra costs of
dealing with the increased errors and extra staff are being employed.
Table 1. Horizon errors generated in a sample 4 week period, as Roll Out
gathers pace.
Week 01 Week 02 Week 03 Week 04
27% Mar 00 I 03"4 Apr 00 I 10 Apr 00 I 17 Apr 00
Number of 4692 6927 6369 7285
Horizon Errors
Number of 4401 4719 5044 5370
Horizon Offices
Errors per Horizon I 1.07 1.47 1.26 1.36
Office
Transaction Processing needed to bring in extra staff to clear the increased
volume of errors. Twenty four of these extra staff were in post at April, and
based on trend data, the forecast at that point in time was for an additional
requirement of up to 40 staff by September 2000. The length of the learning
curve was also giving cause for concern and was at this time not expected to
return to baseline until 20 weeks after conversion.
It was therefore decided to undertake a short term project to look at initiatives
that could be implemented to reduce the level of errors being generated and
the length of the learning curve.
POL00334154
The project was sponsored by Alan Barrie, Operations Director, on behalf of
Don Grey, Horizon National Roll Out Project Manager.
3.0 Project Terms of Reference
3.1 Scope
¢ To analyse impact of previously identified solutions from the Data
Integrity Project that were implemented by Conformance and Retail
Network Project.
¢ To analyse current NRO error data and identify trends, issues and
problem areas for further root cause analysis.
¢ The cross functional team will take the output of the above analysis
and:
1. take error data through the root cause process to
establish potential solutions
2. review the impact of previous solutions and identify
any areas where additional activity /action is required
3. develop solutions and action plans for implementation
4. to consider root cause/solutions/ actions for those
offices already migrated as well as those planned for
future.
¢ To produce action plans detailing all activities required through the
life of the error root cause and reduction Terms Of Reference.
3.2 Specific Objectives
¢ To implement solutions which reduce the error levels to or below the
pre-Horizon baseline.
¢ To implement solutions which shorten the length of the learning
curve.
3.3 Deliverables
1 Analysis to understand trend of error levels and the products or
problems which are causing 80% of the errors.
2 Workshop analysis to determine potential root causes and
amendment of previous solutions.
3 Identification of potential solutions and decision of which solutions
to implement - by end of Aug 2000.
POL00334154
4 Identification of future process to maintain error level - by end of
Sept 2000.
3.4 Responsibilities
Sponsor:
Project Manager:
Research Services:
BSM - Incidents/problem
management:
TP Ops front line:
Horizon implementation:
HORN:
Member for the Operating
Process team:
Lead for Workshop:
4.0 The Approach
Alan Barrie on behalf of NRO Project Board
Joyce Daggett
Kjetil Fuglestad
Phil Turnock
Julie Dart, Problem Management
Chris Clarke, Horizon Liaison Manager
Janice Rowell
Peter Pycock, Keith Jones
Jim Watkin
Joyce Daggett, TP Project Manager
Lynn Kelly, Head of Development
Representatives for the cross functional team were nominated by their
respective line and the first meeting was called for the 8'* June 2000. At this
meeting each individual was asked to sign up to their roles and
responsibilities within the forum (see Appendix A) and the team purpose was
agreed.
A presentation to the NRO board was undertaken on the 26" June 2000. We
asked them for:-
-Support when implementing solutions.
-Continued support for the cross functional team.
-Removal of barriers.
4.1 Team Purpose
¢ To take error data through the root cause process to establish potential
solutions.
10
POL00334154
POL00334154
¢ To review the impact of previous solutions and identify any areas where
additional activity /action is required.
¢ Develop solutions and action plans for implementation.
¢ To consider root cause solutions/actions for offices already migrated as
well as those planned for the future.
¢ To implement solutions that reduce the error levels to or below the pre-
Horizon baseline.
¢ To implement solutions that shorten the length of the learning curve.
The steering group decision was to hold two workshops, one to be a root
cause forum involving the users and the second to be a solution generating
workshop consisting in the main of the steering group.
The steering group were asked to nominate users for the root cause analysis
forum, it was agreed that the workshop should include two Branch managers
and two sub postmasters one from each of the two HORN areas represented,
one Horizon Field support, one Franchise manager and one rural RNM.
4.2 The September 99 Root Cause Forum
The outputs of the September 99 error root cause forum were examined.
Solutions had been implemented however because no measurement process
had been developed and other contributory factors had impacted on errors it
was now impossible to be clear on the success of any solutions. The error
areas which were examined in September with the exception of one, were all
still relevant and appeared again in May’s error stats. The Root Cause user
group would focus on the May error statistics.
Explanation - Each time an error notice is investigated to resolution, what
caused the error is recorded on to a database now called Transaction
Accuracy Measure. For example, the largest category of error (52%) across
CLASS and PIVOT is where either the Cash Account or supporting document
has a figure missing or it is different to it’s matching entry. The top ten
categories cover 80% of all errors. Effectively the database describes what the
postmaster did to create the error.
4.3 The Root Cause User Workshop
The workshop was held on the 23"4 June 2000 the purpose was defined as:-
11
“Using the statistics, data and information provided on the top ten
errors, by volume, examine each error type and using root cause
analysis tools. Drill down to establish the fundamental base of the
problem. Document findings for the Root Cause Solution
Workshop.”
Using root cause analysis tools the User Workshop delved into the reasons
behind each error type (see Appendix B for the error types and volumes that
were looked at by the workshop).
Root Cause Maps were generated from the analysis (see Appendix C) and
these maps were then used to pull together areas of cause under each of the
following headings :- System, Process/Procedures and Guidelines, Training,
Human Computer Interface, Horizon Field Support, Communication,
Horizon Balancing Guide, Information and forms design, Business Change,
Helpline. All of the information was then used by the Steering Group Solution
Workshop to develop an activity plan.
4.4 The Solution Workshop
The solution workshop was held in Chesterfield on the 6'* July 2000. The
causes for each of the error types was sifted and prioritised. Solutions were
identified and the activity necessary to deliver them was mapped out on to an
activity plan with assigned owners and target dates (see Appendix D for the
latest version of the plan). The activity plan was monitored by two further
Steering Group meetings on the 25" July and the 29th August.
5.0 Solutions and Recommendations
5.1 Forms and Supporting Documentation
User feed back suggests that we have in use a high percentage of forms that
do not align to the Horizon system. In some cases examples were given
where a form gives information that needs to be keyed into the system in an
opposite order to the screen used to capture the data, thus creating a high risk
that the information will not be keyed correctly by the office. It was never part
of Horizon’s scope to look at forms and supporting document design and we
believe that this is a gap.
It is recommended that Post Office Network dedicate project resource to
look at all forms and accounting supporting documentation, with a view to
beginning to bring the forms in line with our automated system. It is also
recommended that user input is gained at the design stage and at the testing
stage to ensure that they are user friendly. This could be done ahead of ERA
on the forms which cause the biggest problems. Some work would need to
12
POL00334154
POL00334154
be done to identify these. Two examples we were given in the User
Workshop were the DPI schedules and the Remittance advice notes.
Short to medium term -(3 months CM) resource to prepare a simple
business case and to do cost benefit analysis i.e. which forms are causing
highest amount of errors and what would be the production and
distribution costs. This could then be linked into the work already started
by the service delivery planning team.
Long term pass into the ERA project for building into the design. We need
to design out errors.
5.2 Observation Study -Benchmarking
There is no process in place to identify and share best practice across the
network. Outlets that have adapted quickly to the automated environment
and are operating with low error rates are not able to share their learning,
work practices and methodology. It is thought that an observation study
carried out in a sample of offices may significantly improve our
understanding of why and how Horizon errors are made and enable the
territories to spread best practice across the network. Unfortunately the time-
scales of this project have not allowed such a study to be carried out.
It is recommended that an observation study (building on the work done by
John Evans on human error) be conducted by Research Services to look at
how the various user and balancing guides are being used in good and bad
offices. What practices do the good offices use which helps them to avoid
errors?
It is estimated that carrying out a study in twelve outlets (6 good and 6 poor
offices) would cost around £10,000 and take between 4 to 6 weeks to
conduct. This would provide the input for a business case to deploy the
recommendations in the territories. If cost effective a further 10% reduction
in errors is feasible.
5.3 Product Design
The way that we design products and their back end accounting processes can
lead to errors. There are products that are more error prone than others and
there are products that generate errors which are complex and more difficult
to clear. For example using the automated payments line for the personal
banking product makes any Personal Banking errors difficult to identify and
hence they take longer to clear. Whilst the Transaction Processing average
error clearance rate is judged to be 6.2 errors per hour it is thought that on the
Automated Products team the clearance rate is approximately 1.2 errors per
hour.
POL00334154
There appears to be no statistical based method for calculating expected
errors on proposed new products. The method currently in use is to ask
Transaction Processing team leaders. In our view these people may not have
the wider view necessary and some tie up with errors produced needs to be
written in to the New Product Accounting Model. It is highly likely no
account of the increased error levels being experienced across TP is being
taken into account at the product development stage.
It is noted that Product Feasibility’s are still being written for the manual
environment, and that the operational business change process is not clear
regarding timescales for the individual steps and tiers within it. Only overall
lead times are available and appear to be variably understood. Problems
being encountered include products being launched or amended without
adhering to the Operational Business Change Process thus making it
impossible for the offices to sell the products correctly. They then invariably
use the complex process of selling from the suspense account and this causes
errors.
It is recommended that Transaction processing re - examine the methods
currently in use in their development team to calculate expected error
volumes on new or changed products. The aim should be to implement a
clear documented process which is realistic, takes account of the automated.
platform and can be applied across generic product types. This has been
passed to Transaction Processing and work has already commenced on it.
5.4 TP Internal Processes
It would appear that Transaction Processing no longer proactively seek to
prevent or drive down errors. This is in part due to:-
a) The business reorganisation under SCS has meant that Transaction
Processing’s role has changed to that of a deployment unit. Transaction
Processing is not a shaper of policy or business initiatives. Therefore
Transaction Processing no longer play an active role in sub postmaster
road shows or federation conferences etc. Where in the past much good
work on error reduction was done through partnerships with the
territories we now need to understand the role of the operating process
in error reduction. We believe that this should be taken forward as a
joint action between Transaction Processing and Transaction Accuracy
Measure Improvement Group (via the Operating Process Team).
b) The large increase in error volumes being experienced since roll out
has required Transaction Processing to fully concentrate on the
application of it’s resource to error clearance and maintenance of data
integrity.
14
There are pockets of proactivity taking place in Transaction Processing where
teams have derived their own help sheets and have started a telephone
campaign on some offices, for instance the Powerkeys, Parcels and
Promotions team try to ring ten offenders of manual completion of table 12
per week. Such activity exists in isolated pockets, there is no co-ordinated
approach.
It is recommended that PON begin work to proactively reduce errors
through a program of support and education. That a forum be established
to continue and build on the work commenced as part of this project. The
forum to have representatives from the Operating Process, the Territories,
National Business Support Centre, Transaction Processing, the forum to
develop a co-ordinated approach to error reduction/process improvement
and feed into the next phase of Transaction Accuracy Measure, via
Transaction Accuracy Measure Improvement Group. The activity will also
need to be linked with the problem office process in National Business
Support Centre, and the Service Improvement Process.
5.5 Conformance
confermance.Through analysis and investigation during the project it was
identified that the majority of the errors could be assigned to user non-
conformance, attributable to lack of processes & procedures during the ‘stock
unit & cash account’ events, e.g. individuals completing cash account using
their own processes which can often lead to key data being missed, thus
creating errors (non accounting data).
Though to date there has been numerous piecemeal attempts to address this
problem, with the development of documents and guides to assist in the
balancing process and to aid error prevention. Much of this is wasted work
as some offices simply disregard them, or don’t have time to read and digest
the contents.
The business needs to develop a policy backed up by a harder approach to
non- conformance. The group strongly recommend that a ‘task force’ is
established to co-ordinate and define Post Office Network's preferred
process & procedure for completing both ‘stock unit & cash account
balances’ in a sequential/logical form, ensuring all data (without exception)
is captured using the Horizon system. The agreed process should then be
15
POL00334154
POL00334154
incorporated into ‘counter operations manuals’ and ‘training briefs’ with a
clear directive of being mandatory, with procedural audit and the retail line
ensuring conformance is maintained during site visits. The group would
need to take feeds from the observation study and would need to link into
the Transaction Accuracy Measure Improvements Group.
The benefits of a standard defined process will provide an eventual ‘win’
solution by driving down cost and ensuring conformance - “The Horizon
system has been designed in a systematic way, therefore it is vital that the
users operate it using a standard systematic approach.”
5.6 Service Improvement Process
During the course of the project we uncovered various pockets of activity
taking place, one of which is the Service Improvement Process. We discovered
that a number of Service Improvements were logged but there was no clear
process to follow on how these would be evaluated, sifted and progressed
through to conclusion.
It is recommended that the Service Improvement Process be fully defined,
documented, deployed and embedded throughout the Business. This
would enable all areas and individuals to be clear on their responsibilities
within that process. It is also recommended that Transaction Processing are
involved in the impact assessment of Service Improvements in order to
ensure delivery of maximum business benefits through the reduction of
errors. Dialogue has already commenced with Transaction Processing,
Business Service Management and the Operating Process.
It is recommended that a Service Improvement be registered with input
from the Transaction Processing error clearance team to make the Personal
Banking icons more user friendly. That icons be grouped by product i.e.
one icon for Co-op that is selected to get to a screen with all Co-op icons. At
the moment, the screen used for banking products shows icons for multi-
products, making it easier for the individual to press the Co-op icon when
they should have selected Lloyds. Note With the roll out of CSR+ this
Service Improvement has now been made.
It is further recommended that Service Improvement number 7 is pursued
via the owner of the Service Development Plan (Nick Beal). This will
reduce some Pension and Allowance errors, although further work would
need to be done to establish the volume, It is not thought to be high.
It is recommended that Human Computer Interface issues currently logged
as Service Improvements be pursued with urgency as, although impossible
to quantify, these are likely to have a positive impact on error reduction.
16
POL00334154
5.7 Training
There is a high degree of dissatisfaction with the training given on Horizon.
Users were critical of the 1.5 days dedicated training. Comments such as “it
wasn’t long enough,” “too much to take ina short time,” “not tailored to
needs as some individuals were conversant with technology some have never
touched a computer” were given.
The field support process was criticised for lack of support in all transactions
(not all transactions were covered on the day the HFSO was present) and for
telling people the wrong way to do things i.e. the suspense account. The
training did not test peoples understanding or confidence in using the system,
hence we have a number of postmasters who are not at all confident using
horizon and this in itself leads to errors in areas such as reversals, creating
stock units, balancing and accounting for out of hours transactions to name
but a few. Feed back has been given to the National Training Team, and the
lessons learned from this must be taken forward into the ERA project.
Work needs to be undertaken to identify the offices still encountering
problems 12 weeks after conversion (high error rates, high volume of calls to
NBSC) and that HFSO’s be sent into these offices to undertake refresher
training tailored to individual needs (see also recommendations in Section
5.4). Assuming that 500 offices would need a two day refresher training
course, then Travel and Subsistence costs are estimated to be £77.5k. This is
based on an allowance of £80 for travel, £70 for a night’s accommodation and
£5 incidental allowance per office visit.
National Business Support Centre already identify problem offices by
number of calls made to the help line, however concern has been raised that
these offices may not be the offices with high error rates in actual fact they
could be the reverse, offices who ring the help line to make sure that they are
doing things correctly and avoiding errors.
It is recommended that the National Business Support Centre and
Transaction Processing jointly commence work to identify problem offices
for further refresher training. This joint approach to identify areas of
concern could flag up the area and type of support needed i.e. whether the
issue is one of more training required or bad practice being used.
Transaction Accuracy Measure will play an integral part in the decisions
and profiling of problem offices. This approach would also give us the
wider business view to enable us to tackle the costs of problem offices
being borne by Post Office Network. If the training is successful then
savings should be feasible in both Transaction Processing and National
Business Support Centre and this should be a measurement of the works
success. Transaction Processing are signed up to do this but resource is
needed to research which are the genuine problem offices ( could be picked
up by the resource at 5.1 if authorised) and what savings could be realised if
17
the training were to be successful. This work also needs to link to the
System Improvement process.
5.8 Business Targets and KPI's
Users were keen to point out that the business has conflicting targets. They
pointed out the difficulties of operating a new automated system whilst
trying not to make errors, serve customers to keep waiting time down and
grow sales. Table 2 shows the impact on our KPI's. You will note that the
worst hit area is the error rates, although waiting is impacted short term, this
returns within target by the end of a three month period whilst the impact on
the error rates continues to be an issue.
Table 2. Impact of Horizon on Business KPI’s
Short Term Medium Term
0-3 mths 3 -12mths
Waiting Time Very negative impact _I No significant impact
Staff/Agents attitude No significant impact_I Not known
Customer Satisfaction
No significant impact
No significant impact
Transactional Knowledge
No significant impact
No significant impact
Error Rates
Very negative impact
Very negative impact
POL00334154
It is recommended that those responsible for setting business targets bear
this conflict in mind when either establishing any new and/or monitoring
current targets. The impact of any new and/or additional targets into the
network should bear careful consideration and be fully risk assessed for
any potential increase in errors and consequent impact on costs.
The introduction of the Transaction Accuracy Measure onto the scorecard
will allow a balance to be made against any other key performance
indicators.
6.0 Measurement of the Project’s Success
It is strongly recommended that the impact of the initiatives arising from the
Root Cause Project is measured on a quarterly basis. To enable this
measurement to be carried out an impact calendar has been produced
(Appendix E). This calendar links initiatives and anticipated impacts, which
can be tested by analysing data from the current QPA data base and the
forthcoming Transactional Accuracy Measures Database (TAM). It should be
noted that there will be a 2-3 month lag in results, due to the necessity of
18
POL00334154
using cleared errors in the analysis. The key aim of the analysis is to discover
which initiatives have been successful and have not.
The analysis will measure the impact separately on offices that have been live
with Horizon for some time and newly automated offices. The analysis will
also attempt to distinguish between a general learning curve effect and more
rapid improvement in error rates caused by specific initiatives.
¢ The likely cost of setting up a measurement process is £3k.
¢ We have been quoted ongoing analysis costs of £2.5k per quarter, however
Transaction Processing believe that once the process is established the
monitoring could be carried out in house.
6.1 Impacts of other Initiatives
It should be noted that the project was conducted against a shifting platform
of continuing Roll Out and that other initiatives due to take place shortly will
or should have a positive impact on error levels (see Appendix E).
CSR+ Should impact positively on the error types HP201 Incorrect/nil entry
PIVOT and HC201 Incorrect icon selected CLASS, although it should be borne
in mind that initially errors may increase.
The system solution sponsored by Transaction Processing (Change Control
Notice CCN 631a) to move the Table 12 prompt should impact positively on
HP201 Incorrect/ nil entry entered.
Through the introduction of TAM throughout the network, consistent
reporting of errors has been established and this will help focus the retail line
on their poorest performing outlets.
7.0 ECCO+
A report was commissioned some time ago (the Darren Boscoe Report) to
undertake analysis of errors in ECCO+ offices. Appendix C of that report
provides a list of potential sources of error in ECCO+. The majority of these
causes and sources of error have been carried over into the Horizon
environment.
It could be argued that as ECCO+ was situated in our larger offices, the high
volume of transactions completed by these offices would increase the
likelihood of errors. However, although Branch Offices (most ECCO+ offices
were Branch Offices) produced slightly more errors per office, the errors per
19
transaction is much lower than for other office types. This indicates that the
rate was not increased by ECCO+ compared to a manual operation.
The relative error rates have not changed significantly since the introduction
of Horizon (see Table 3.).
Table 3. Proportion of errors vs proportion of volume
% of errors °% of errors % of volume I % of
(pre Horizon) I (post of Network
Horizon) transactions
Branch Offices I 7 6 20 3
MSPO/ FPO 10 10 10 5
SPSO 83 84 70 92
8.0 Learning Points For ERA Project
e Launch conformance with the technology
¢ Ensure that changes to procedures etc.. are done in tandem with system
changes
e Less complexity especially around any transaction reversal or balancing
processes.
¢ Get rid of supporting paperwork where possible. Redesign paper work
where it is key ensuring that it mirrors the system and is user friendly and
as idiot proof as possible. This is necessary through the migration states.
e Improve Human computer interface - icon clarity etc. Design out as much
opportunity for Human error as possible.
¢ Train, train and train again. Ensure training meets needs of all individuals,
test understanding.
e Make the Operational Business Change process more flexible and
responsive to business needs such as quick product launch.
9.0 Project Costs
Cost
1x T/B9 12,000
0.5 x PO 4,700
20
POL00334154
Post Office Consulting
4,500
T&S
500
Total Cost
21,700
NB.
T &S includes all travel by project manager and any other travel to workshops claimed against the project by
steering/user group members.
21
POL00334154
Appendix A - Outline responsibilities of members of cross
functional team for error root cause and reduction
Horizon Implementation - Janice Rowell
\V Able to take actions back to pathway re: software content/design.
\) Able to take actions to change HFSO procedures/ training.
\) Assess actions to change training programme for implementation and take
forward to area of responsibility.
\ Conversely able to explain Pathway software releases, HFSO
accountabilities and postmaster training content.
\ Able to nominate “experts” for input to Root Cause workshops.
BSM - Phil Turnock
\ Able to take actions to:
e Amend Helpdesk scripts
¢ Change tier 1 and tier 2 procedures
¢ Influence Pathway Helpdesk scripts and procedures
\ Able to explain:
¢ Helpdesk, tier 1, tier 2 and Pathway procedures
\ Able to nominate front line staff to take part in Root Cause workshop
\ Able to provide any required data to the steering group.
Territory - Peter Pycock and Keith Jones
\) Able to take actions to:
¢ Provide steering group with anecdotal evidence/ feedback
¢ Change RNM procedures/ training (if short term and not out of line
of Retail Line Review)
¢ Change comms with outlets
¢ Change RNM visit content
¢ Identify cost/benefit of solutions
\ Able to explain:
¢ Data available, RNM role, visit content, comms with Outlets
\ Able to nominate front line staff to take part in Root Cause Workshop
22
POL00334154
POL00334154
Research Services - Kjetil Fuglestad
\) Able to take actions to:
e Analyse data and produce trends and recommendations
¢ To measure effectiveness of solutions
¢ Advise on statistical verocity of any solutions
Operating Process Team - Jim Watkin
Vv Main focus on identifying channels for solutions beyond the project.
\ Able to take actions to:
¢ Pass solutions to Sub Process Owners, ERA project, Product Design
Principles, Transaction Accounting Measure (TAM)
¢ Take a judgement of whether short term conformance can take
forward.
\ Able to explain Operating Process Strategy and links to initiatives
impacting on.
Project Manager - Joyce Daggett
\) Able to take and lead actions to:
¢ Review impact of previous solutions and identify any areas where
additional activity/action is required.
¢ Take error data through Root Cause process
¢ Develop solutions and action plan for implementation for migrated
offices and those planned for future.
¢ To provide the Head of Transaction Processing with updates and
benefit monitoring reports for NRO project board.
¢ Gain collective sign up from NRO.
Transaction Processing - Julie Dart & Chris Clarke
V Able to take actions to:
¢ Collect data
e Assess cost/benefit of solution
¢ Change procedures within Transaction Processing
\ Able to explain:
¢ Type of errors, implications of errors, input to Root Cause
Workshop.
23
POL00334154
Appendix B - Top 10 Errors by volume for May 2000
CATEGORY ‘VOLUME I PERCENTAGE
IHP201 - Incorrect/Nil Entry Entered - PIVOT 12057 41%
Where Postmaster has failed to enter or has
lentered an incorrect transaction into the
Horizon system.
Includes errors formerly known as omitted
figures / incorrect entry
1H1C201 - Incorrect Icon Selected - CLASS 4109 14%
Where Postmaster has selected the wrong
product.
This results in compensating errors on two or
Imore cash account lines.
[Formerly known as wrong line entry.
IH1C202 - Incorrect/ Nil Value Entered - CLASS 3370 11%
Where Postmaster has failed to enter or has
entered an incorrect value transaction into the
Horizon system including incorrect reversal
transactions
Includes errors formerly known as omitted
figures / incorrect entry
IH1P206 - Manual Amendment 1022 3%
Where Postmaster has made a manual
lamendment that requires corrective action in
Transaction Processing but which does not
lappear as a Class or Pivot error
IHP203 - Incorrect Icon Selected - PIVOT 620 2%
Where Postmaster has selected the wrong
product
This results in compensating errors on two or
more cash account lines
24
[Formerly known as wrong line entry
CATEGORY
VOLUME
PERCENTAGE
IHP209 - Correct Icon not Available
Where Postmaster has been instructed to
follow an authorised temporary procedure i.e.
told to use an alternative icon for a limited
period due to the fact that the correct icon is
not available on Horizon
le.g. Missing icons for new value Home Care
stamps due to a failure in the OBC process
467
2%
1H1C210 - Delayed Cash Account
Where errors are produced due to the receipt
lof a cash account which contains transactions
relating to later weeks
e.g. A week 18 account received which
contains transaction data for weeks 18,19 and
20
[Known as a ‘back to front’ three week account
440
1.5%
IHC76 - Incorrect Date on BCV
Where Postmaster has entered the wrong date
lon the BCV which is then processed to a
different cash account week from that where
the transaction took place
418
1.5%
IHIN202 - Incorrect/ Nil Entry Entered - PIVOT
Negative Sales
Where Postmaster has failed to enter or has
entered an incorrect transaction into the
Horizon system.
Includes errors formerly known as omitted
figures / incorrect entry
282
1%
25
POL00334154
CATEGORY
VOLUME
PERCENTAGE
1H1C206 - Incorrect Balancing Procedures -
[Automated Payments Team
Where the Outlet / stock unit has balanced and
rolled into the next cash account period too
early or too late resulting in compensating
errors when compared to APACHI
information
262
1%
IHCO07 - No Signature
Where the Final version cash account is
received in Transaction Processing without
being signed by the Postmaster.
The cash account is returned to the outlet for
signing.
259
1%
Total number of errors for May
26
29692
POL00334154
Appendix C - Root Cause Maps, outputs of the User Group
Workshop
a1aeIeAY JON UoD] 199109
qunoady yseo pakeiag
mreerel = aes
porte ee jdsteetoset aoe
Yes i maven eee,
/ ‘not followed wrong line easy to get w ron,
oineonnat
Seas
I rie
apa
— ation wid tore
onl cenel mS process fam $08 chagee
received by all communicetod to Inception of a new] yet fuk
ee iterate Monet op Poe
ecneeer
: Ovantn wd
sa nba
rages crt Cae et once
Troe eet Tis ott fesse
Pcl teay Business Change: robust alinfo Business to make
offices sel which, ws
ae te wens
products rox ‘end
respi)
Baacbant
semamtaen
Gee
=a
‘inks right is only a contingency)
aero
che (coningercy
len) happen
Treiiae
{allgspenssion
atthe igh pon
"A balance perio
torcapya
bance pei 2)
screen which
‘Single stock unt
cate Not clear eroush
‘Wout nate
omnes 9! is eS
27
POL00334154
sainpasoid Bursuejeg }9a1109u,
———
=>
‘SSV19 PayDajas Uo! JaU09UI
=
Fas pol dong
am orth bara) surer balances
Tole by H#50 =e thou vee oul APToo no
Confusion wih thatyou con eat our sock. (Got in Bat
cutothoonpate oft before the ages Leave stock unt wet) but
or any ie ‘coc turer recorded by soc
saint balance to CA “unit in the
fatowing wok
“We eects Fas Pot bs
commute clear enough for
Pas fo unrstandTrow to
complete frher balance fo ers
Tot sides of bis nous are
recorded the sue w eck
Communication on crest seo
cutot hous slockprocedvres
lear enough no emphasis
ford
=
swoctee I I Mevwartoert et enough wee
‘SreroawinI—I
setanae)
Darthave
ot outco
Meow I coated et
eh
‘he nforston ae
5 te optus on
swrbciy (og Lanter FeeI I corr antheI I watson shud
‘romofa POS ard pope soyd I fam Pareabee] I berosng
rerraepa
imesere .
rvtrovtore I __Iog.nore.crm I__I tanaataaonw I__I Netenugh ret
ed to mch ‘conse onrs spare
ssriy =
mm
\
\ Logos don't People serving Arrow s used to) ‘eon use rot
\ rao e ispeed dteesset II coneorte
Ler Le w enough ‘system,
\ Barclays
wa Nata
ba ong Foton pares} I “teabe
ecarsgcons I_I Stade ot cnbuny dye II rogue or Rateut
are les I tou ane tomecstes, I I ‘changen'o
e bd training times
28
POL00334154
POL00334154
Ez. leon coming “eons + Get complacent
“eons are not Soon, wetting differentiated by and dont always
clear below icon is ‘one etter, eg INL bok at the:
‘mall RCLS, INL POLS pictures
5
Q
I
3
s “eons and stockI "ERED
2 Scene system, e9 £20 >
> £10, £10 >£20
Qa
Tv
<
)
3
- When the
stickers are +“ Only one word ey)
peeled off the differentiates the paseo llel
schedules are forms under the wrong
difficult to identity I icon
ae “pe promye
eed Severo
vse Beazer] [ompesea) [axa
Stes] foto oor / “Us00 by HSFOs: wore ths best praction
Fa Sent [7] Mnwcoe 7] sere I—] uote ane
i a ‘wat
FI
ES Sereauie I [race ueneI [conipucntscomI I imlctn I I wottanironed
[tenon Lr OY i FE cere hoor ‘esks how mary I—{ that hes ture
A semen I I reavant’I I Wiacsmcasceny I “eccseam I Irampatst rou
A ae lees
z hes Elec casiganit
3 r99s (depencs an M—I Horizon has mero) this natch
Ea re) I sosmaee sister
3 Beipeleoaed sex ea orn
coy 2
g -
cane .
ecrtenceaI_I Spine
eee mee] [a
causeg back strovmeacmee II oncom unn,_I Hopino on t=
Us0 of oftorant as process}
a taasen E
‘you are tying [Not clone w hich Lappe Low lover of
Tenia ore II ate a0) yatta
[I "Steer same rg pet
rio! Src
29
—
eae Com batten,
Talon srpiesion ss
ssionepsok
= wares
sropanotcan I _Noponet>
Dai rparisaI__ I Sn palepr ir I__I Mists srg face outa
manual report [I I thers is nothing to! I tf I] balance snapshot)
‘ti ransacion Toned youn cae eal dng “otmandnory
‘te
z Taga ar Tranrgrat
go orb en Not sure of ts.
cromancaed noire I) ehanes,
ogee SS
Fy pect sre = eof conpits
Hi sometesean Pavone netegnpetwel I verry cases
s ‘be produced I not understood ‘enough on ‘confusion
g whut cuting of "I ‘rang
i ‘re prvons dy
2} \ \ eeauers_I aseed Terma he
&) \ I were cs tet gen
a "sub
SereervenI Cheques aro Gotoicon
bison I_I seadand gm I_I etaquen do
vila, eee,
Wopatyot Used oprnthaI I -Prasurectaef I toot wentan Tregysemle I_I tts go ough
tamectremeI —I ‘toten(nan’ II Sreenme II capt srenty] I rurmdende I_I 9 tay sunt
Vet cash "ernie gore auch ‘bor used snob ass pats
el
wanna e uct] [rmeanytopereI I tsa
neace evetem = —7 II of best practice
theeerseteI —]_ unsteteg I
‘ood ra seseaprance I_I (comhstned
peescuer!
Late in process Lengthy Easier to amend
and complicated procedure to go manually on hard bribe
to do ‘through Horizon copy of CA vy
=
= /
5
é
Es
/ Once roled over
4 Gy to new CA week,
z something in can't go back to
3 erin) ‘change
Q
3
3
$
a
\ Net
Nothing to stop communicated Subsequenty
»\I someone entering ‘that itis wrong to don't realise this
manual manualy amend is wrong and
amendments initial follow up causes problems
and training
30
POL00334154
Appendix D - Steering group activity plan (version 7 @ 11/09/00)
No. Activity and date raised Owner I Target I Status Outcome
date
1. _Incorrect/Nil Entry PIVOT
1A I 6 July
Check knowledge base system within Amanda 25/7/00 Cc No significant mention of tables, just that they are mandatory.
NSBC is accurate in terms of tables 10g and I Booth Queries regarding how to navigate the system to complete them
12, Feed back findings to steering group. are forwarded to the Horizon helpdesk.
Report on most frequently asked questions I Amanda 25/7/00 Cc Report passed to Joyce Daggett and Chris Clarke for further
and answers given by the helpdesk Booth action (see below).
25% July IP
Take the helpdesk frequently asked Q&As I Joyce 18/8/00 Work completed in TP and amendments comments fed back to
document and format into an output that Daggett & Amanda Booth as owner of the information. Ready to publish
can be passed down via the retail line. Chris once Amanda gets back to Joyce.
Clarke
29th August
Phil to chase with the frequently asked Q
and A’s doc with Amanda - this doc needs
to be ina user friendly format.
25th July
Are the offices calling the helpdesk on this I Phil 11/8/00 I C Information passed to Kjetil for analysis.
query the ones making these errors? Turnock
Get a list of offices who have rang the
helpdesk in April, May and June regarding
non-accounting data (or general balancing
queries), with call dates.
KF - yet to do.
Analysis of the above data and pass to Kjetil 18/8/00 Who should be highlighting problem offices - TP with helpline
Joyce Daggett for circulation to the Steering I Fuglestad connections? (i.e. high errors but not calling helpline). - for
Group. consideration in project? JD
29k August Joyce
Handy hints and how to avoid top errors Daggett/
Chris Clarke
docs sent for inclusion in Counter News
31
POL00334154
No. Activity and date raised Owner I Target I Status Outcome
date
1B, I &*Iuly
Management information on errors, ie early I Joyce 25/7/00 I IP Met with PPP 24/7 to establish if any local team initiatives are in
1c warning report is not being deployed. Daggett place. Currently, they ring up the top 10 worse offending offices
Consider feasibility of using Cash Account I Julie Dart weekly - this takes four hours of a PO's time. They have
check guide via RNM’s. previously put out information in Counter News, and this may
TP error process is too lengthy. Look at be worth doing again to cover interim between now and the
getting information on errors sooner, Mark Burley solution due in November (see 1G). TP Internal
particularly for this error and in advance of Solution Development Team looking at these areas. Due to
CSR+. Link into TP, PIT, and error report back 24/9
resolution teams.
1E I July
HBG is generic - Feed comments from Joyce 25/7/00 Cc Comments given - will update group of any feedback.
workshop to Kevin Thompson Daggett Cc Kevin has asked for a copy of the Root Cause Maps.
1G I @Iuly
System prompts needed to remind PMRs to I Jim Watkin I 25/7/00 Cc Currently, a prompt to enter DPI information is given by the
enter PIVOT information on table 12 and system, but this is given at the beginning of the balance routine.
10g. Talk to Mark Burley to establish what If this warning is ignored and over ridden, then DPI cannot be
has been done and when it will be entered without creating a new stock unit on which to input the
implemented. data (this stock unit would then need to be deleted in the
following week).
There are plans to introduce an enhancement to the system
which will move the prompt to a stage in the process when the
last stock unit in use is due to be balanced. (This does not apply
to dormant stock units which can be rolled over as at present).
The system will not, however, force the user to include this
information (i.e. the prompt can still be ignored) as it is possible
for an office to have nil traffic and it is deemed unnecessary to
Needs to be captured under ERA at point of force nil entries.
‘ion. Need to identify any other No definite date has been set but, this enhancement is intended
ways in which we can feed the lessons Joyce Project to follow shortly after CSR+ - maybe October/November 2000.
learnt into ERA Daggett end
Recommendation in final report
32
POL00334154
No. Activity and date raised Owner I Target I Status Outcome
date
250 July
The balancing problem could be solved by _ I Joyce 25/8/00 I IP Consideration of options.
conformance - a systematic procedure for I Daggett Recommendation for final report.
balancing for all offices to follow would be I Phil
the ultimate solution. Turnock
Jim Watkin
29% August
JW- Balancing checklist has gone out to Jim Watkin I 20/9/00 IP A balancing guide is being trialled to help achieve a standard
offices. balancing process. Jim will feedback conclusions from the trial.
Suspense Account Errors feedback passed I Joyce c
to Janice Rowell for comment/distribution. I Daggett
CC - Can any info from Jeff Widdowson’s Chris IP
suspense account workshops be fed into Clarke
this project?
POCL cheques held in suspense account - is } Chris Clarke I 7/9/00 IP Chris to talk to Jeff and Marion by 24/9
there a better way of doing this/can we Joyce
change it? To talk to Marion Dale. Daggett
2. _ Incorrect Icon Selected CLASS (Including 7. Delayed Cash Account)
33
POL00334154
2C
6 July
Supporting paperwork not user friendly.
No emphasis on the part you need to refer
to. Investigate supporting paperwork -
who designs it and do they align it to the
automated process? Who would
incorporate in future development and
would they consult users at the design
stage?
Joyce
Daggett
25/8/00
P
Incorporate findings in final report
Activity and date raised
Owner
Target
date
Status
Outcome
2D,
2E,
7C
6 July
Abbreviations used too much in relation to
Horizon. Icon use is not consistent on the
system. There are no clear prompts on the
system to remind you which week you are
in.
Feed back improvement opportunities to
BSM via SIP process.
Phil
Turnock
25/7/00
Fed to SIP.
Joint initiative with TP and NBSC to sift the SIP’s impact test
and drive forward.
Error costing analysis completed to input to joint meeting on
SIP’s.
Phil Turnock, Ben Gildersleve and Tom Basquille to meet to
decide how to progress.
Ben and Joyce to meet 25/8
29h August
Phil/Ben/Tom mtg not now necessary.
JD- meeting with Mark Burley (which SIP
to push, concentrate on top 3)
Joyce
Daggett
1/9/00
P
SIP no. 7 and 12 will be pushed by this project via Nick Beal.
3.
Incorrect Value Entered CLASS
34
POL00334154
3E
ing targets in the network cause Joyce 25/8/00 € Discussed action with Kjetil - Incorporate findings in final
errors, ie Q of S, mystery shopper, error free I Daggett, report
account. Establish what the targets are and I Kjetil It is a fact that we have got conflicting targets, however the
how they contradict/impact, and feed in to I Fuglestad customer still must come first in a transaction. Even if a PM is
the final report. leaving something until later, it should still reduce as part of the
learning curve. See follow up action below.
25th July
Kjetil to prepare a paragraph with a grid of I Kjetil 25/8/00 Cc Kjetil to update on progress
impacts on office performance against Fuglestad Grid of impacts to be incorporated in final report.
Business KPIs of Horizon Roll Out for final
report.
No. Activity and date raised Owner I Target I Status Outcome
date
3F I 6 July
Reversals process is difficult. Feed back Janice 25/8/00 Cc Service Improvement logged to make reversal screen a different
the comments to HFSO’s and training, Rowell colour.
(Steve Grayson) knowledge pool to ensure
comments are taken into account in future
developments. Request Steve to report
back what he has taken forward and added
into HFSO best practice guide and user
comments on Roll Out being too quick and
not flexible.
Low level activities:
1) Contacted Steve Grayson and awaiting reply
2) Comments sent to Field Support managers
to cascade at team meetings
Joyce looking at Service Improvements with Ben Gildersleve.
35
POL00334154
No. Activity and date raised Owner I Target I Status Outcome
date
4. _ Manual Amendments
4A, I July
4p, I Lickof high level understanding of Joyce 25/7/00 I IP Meeting set up to talk to Document Preparation team leader to
7 I Horizon system. Don’t realise this is Daggett examine feasibility of doing phone calls (will continue to do so
4C_ I wrong and causes problems. Once rolled anda TP unless someone tells them) - fallback would be Counter News
over, can’t go back into the system to team article. May be possible to target to 20 worst offenders weekly.
change. Look into reinforcing leader
communication on manual amendment TP Internal Solution Development Group looking at manual
problems, eg personal phone call, Counter amendments. Due to report back 25/9.
News etc. Scope size of problem.
25% July JD spoken to Data Prep team leader who has enough resource to
Look at options for a solution. Feed via Joyce 10/8 IP do 20 phone calls per week. JD now to pursue production of a
QPA to areas with lots of manual Daggett script. Postal Officer working on script - to be reviewed end of
amendments? and Chris Sept.
Clarke
6 July
Prompts on system to do a snapshot Janice 25/7/00 Cc Written report back to next steering group meeting.
balance - re-enforce at training and in the I Rowell
training guide.
General training problem in Northern Janice 10/8/00 Cc Northern Ireland offices not being trained any differently.
Ireland? Scottish Trainers? Are we Rowell Looking at stats nothing to verify that the problem is different
teaching the Scottish method in NI and rem process/ procedure.
therefore creating errors? Report back on Letter sent to Steve Grayson, recommending different training
email to Joyce Daggett. for Northern Ireland, where products differ or are NI specific/
29 August
Look at top error types in Northern Ireland I Chris Clarke I 25/9 IP Chris to ask PIT Team to pull off some stats for NI offices, for
- is there a pattern? Joyce analysing.
Daggett
36
POL00334154
Activity and date raised
Owner
Target
date
Status
Outcome
Incorrect Icon Selected PIVOT
6 July
Complacency in offices - don’t look at
pictures on icons.
Look at how we progress information on
best practice i.e. tidy office versus untidy
office and error free versus high error
levels.
Low level activities:
1. Set up meeting with Kjetil to establish how
to get best use out of stats
2. Look at feasibility of office observation visits
- good/bad/why/best practice.
Joyce
Daggett,
Kjetil
Fuglestad
37
Discussed with Kjetil and agreed a way forward. See follow up
action below.
Stats show that high error offices in manual environment only
explains 20% of the post Horizon high errors
POL00334154
25th July
Provide some analysis around balancing,
process of good and bad offices, including
some that were low error in the manual
environment and are now high in the
automated, and some that were high error
manually and are now low. Also to
include some Northern Ireland offices. A
range of size and mix of business etc. to be
taken into account. An observation sheet
will then be put together. We may need to
test it out before we go live with it. We
need Steering Group input on the best way
to do this study and who could support us
doing it, ie. HORN support RNMs, HFSO.
etc.
Kjetil Fuglestad to update Joyce Daggett.
Kjetil
Fuglestad,
Joyce
Daggett
10/8/000
P
Trained data gatherers (ie branch office staff that can be loaned
for specific projects). Need to understand size of project.
Need updates from Kjetil to determine what needs to go into the
final report.
38
POL00334154
No. Activity and date raised Owner I Target I Status Outcome
date
5C I otJuly
Parcel paperwork confusing. Once sticker I Jim Watkin I 25/7/00 Cc The problem with identically coloured DPI schedules is
removed one word differentiates forms currently being assessed, but current thoughts are that the
easy to enter under wrong icon. whole parcel acceptance procedure in the Network needs
Raise issue on parcel forms with Mark revamping, In the light of this, it is unlikely that the forms will
Burley. Will this be covered by CCN631? be re-issued in alternate colours as previously.
Likely to be completely new forms
25' July
Joyce to feed back all workshop comments __I Joyce 25/8/00 NS
to suppliers and Parcel Account Managers. I Daggett
6. Correct Icon Not Available
6D I étIuly
Don’t know who to contact if they don’t Phil 25/7/00 I C E-mail sent regarding having a Counter News article on this
have icon. Communication to offices on I Turnock problem.
what to do when icon not available. Flag,
up to Nicola Wood.
8. _ Incorrect Balancing Procedures
8A, 6 July
Offices not doing further balance after out I Joyce 25/7/00 I IP Fed comments to Steve Gibbs, nothing back as yet. Have fed
8B, of hours transactions, eg lottery, APT, bill Daggett into some work Graham Simmons is doing on out of hours for
8C_ I payments, BT. Effect of this is not the HFSO’s. Passed him information from teams and input to
communicated clearly enough for people to
understand. Correct procedure to follow
for the use of out of hours stock is not clear
enough.
Feed comments into Steve Gibbs for the
work he is doing on this issue.
the brief.
Draft OOH procedure received from Steve Gibb for comment on
9/8. To be re-done to show ‘how’ it should be done.
Awaiting outcome of report after comments fed back.
Out of hours process also covered in the two documents
produced for Counter News.
39
POL00334154
No. Activity and date raised Owner I Target I Status Outcome
date
Measurement Linked Activities
M1 I 25 July Joyce
Understand the increase in the manual Daggett & I 14/8/00 Cc A number of factors are increasing the manual baseline,
error baseline Chris including HEMEL, PDP/PIP. The manual baseline appears to
Clarke have changed and may never get back to 0.63. *?*
29th August
Consider recommending splitting Chris Clarke Cc
Automated Payments off from Personal Joyce
Banking Daggett
M2 I 25 July
To document the measurement process. Kjetil € Kjetil to update - complete
Fuglestad
MB I 25% July
Document an impact calendar, recording I Joyce 14/8/00 I C Impact calendar produced. JD to distribute.
ALL activities - for use in measurement Daggett &
Chris
Clarke
General Communication Linked Activities
C1 I 25" July Joyce First draft being circulated for comment and amendment 9/8.
Produce a communication on the top errors I Daggett & I 20/8/00 IP
and how to avoid them Chris Draft now complete and ready to send to Communication Team
Clarke for deployment.
C2 25' July
Speak to Mark Kelly regarding the Joyce 28/8/00 € Mark advised use of current communication vehicles. Counter
possibility of any wider communication Daggett News suggested. All communication must be passed by BSM.
What about a communication in Counter News informing of the
whole project?
40
POL00334154
POL00334154
Appendix E - Transaction Processing Error Root Cause
Impact Calendar
¢ Project ends 31/8
¢ Bearing in mind TP backlog it will probably be 12 weeks before we see any
results i.e. 30" November.
e What other influences are there between 30/6 and 30/11 which will/could
impact results
e Errors cleared by QPA category which we targeted in May 00.
Error Type CSR+ I Mark I OPTIP I OPTIP I Root
Burley I Stage I Stage I Cause
1 2 Project
HP201 Incorrect/nil
entry PIVOT a a a
HC201 Incorrect icon
selected CLASS a
HC 202 Incorrect
nil/value entered
CLASS
HP206 Manual
amendment
HP203 Incorrect icon
selected PIVOT
HP209/HC217 Correct
icon not available
HC 210 Delayed cash (NB. this category
needs to be monitored _
accounts through roll out - could
lead us into trouble)
HC76 Incorrect date on
BCV 8 ]
HN202 Incorrect/nil
entry entered PIVOT
negative sales
HC206 Incorrect
balancing procedures
automated payments possible
HC707 no signature
(not a Horizon error)
41