Analysis of the Information Technology (IT)
needed to meet the requirements of the
Fisheries Act 1996

Prepared by Ted Howard - Solution-Multipliers Ltd
26 November, 1996


This is a high level overview of the information needs.

There are many possible ways of viewing the information requirements of an organisation - this document provides one - based upon the outputs required.

This document looks at what is required out of the system, then looks back at what inputs are required to meet those output requirements.

Then it has a look at the actual flows of information involved - to get a feel for the size of the information flow, and the complexity of processing required.

It then looks at the major costs, in development and ongoing operation of these information systems.

Required Outputs

What are the required outputs.

1/ The Act requires that several registries be maintained:

Some are related directly to quota: Some Functionality is required by the Act. The Act requires that all of this be done on a user-pays basis, and be accounted for:
All of the above functionality must link to an accounting system which allows for open-item payment of single lines on an invoice (so that disputed items may be easily tracked). All of the above can be loosely grouped as "registry services".

2/ The Actís major purpose is the SUSTAINABLE UTILISATION of fisheries resources.

This requires setting of Total Allowable Catches (TACs).

Two major sources of information are used in modeling fisheries :-

Both are expensive to gather accurately, though the former is usually much cheaper than the latter. Best results are obtained if both are used - with tagging and sampling used where-ever CPUE statistics show cause for concern.

Gathering of CPUE statistics is primarily a research objective, with some limited secondary enforcement utility. The CPUE statistics gathered since the disbanding of the old Fisheries Statistics Unit, which was overseen by fisheries scientists, are, in many cases, virtually useless as the error rates are too high.

Sources of error are multiple:

One thing is clear from this, that if CPUE statistics are to be collected, then to be of any value, they must be checked by people competent to assess their meaning, that means a fisheries scientist with practical fishing experience. Something similar to the old Fisheries Statistics Unit (FSU) is required if the science of fisheries management is to progress. This does mean that ongoing costs of collection and management are higher than those for simply punching in information, but several areas are available for significant cost savings.

If Catch Effort Landing Returns (CELRs) can be submitted electronically, with some error checking at source, then significant savings can be made on repunching and error checking.

For small day boats, this information could in most cases be captured by the Licensed Fish Receiver (LFR) with no degradation in the CPUE information. Larger vessels may find it economic to enter and submit the information electronically themselves, rather than send in paper.

Many intermediate sized vessels would adopt this as a cost saving measure, if it came as part of thier own performance monitoring software. The economics of this would require that individuals pay the actual costs of processing their information, including that of correcting errors introduced by them, and not some averaged cost over the fleet.

Conclusion Significant savings are available if gathering of CPUE statistics is looked at with common sense - particularly in the area of smaller day boats (the majority of vessels, but landing only a tiny fraction of the total catch).

Gathering and processing of CPUE statistics is the most expensive part of the IT operation, and probably the most important. It deserves a high priority.


Analysis of CPUE information is dependent upon the model employed by the scientist.

Analysis requirements vary considerably, and can be completely separated from the definition and maintenance of the database, provided a standard is adopted (such as the ANSI SQL 89 Standard {American National Standards Institute - Structured Query Language - 1989 standard}).

The area of critical concern to both fishermen and scientists then becomes the definition of the data model which defines the database content. Several major issues are present:
Continuity - any change in the structure of the data can cause problems in the analysis which render earlier (or later) data useless (for a particular modelís analysis);
Cost of provision by the fisher - traded against the accuracy of information supplied;
Cost of processing of that information into the database;
Cost of database access to trusted providers of analytical services.

All of these factors need to weighed in the definition of the data model used.

The process of defining the data-model, or making any changes to the data model is the major driver of costs to the industry at present, and the industry has little or no direct involvement.

Any change to that model can render all existing data virtually useless, or invalidate existing models. Changes can mean many years of very high uncertainty until a new time series is constructed.

Conclusion - Industry must have a major role in any proposed changes to the CPUE data-model, or database design. It is arguable the most strategically important area, and the one currently gaining least attention.

3/ Enforcement.

Enforcement officers would require access to all of the databases for three purposes:
Look for indication of deliberate fraud (vessels performing outside of fleet norms, which may require further investigation);
To compare observed against reported activity;
To charge for reported breeches of quota rights (lesser offence).

The original model developed for enforcement - where breaches were to be detected by comparing CELRs with QMRs and LFRRs is seriously flawed. Only a complete idiot would forge any documents in the chain without ensuring that all were similarly incorrect.

Having any enforcement activity attached to CPUE data (CELRs) degrades the usefulness of the gathered statistics (for the reason above).

Conclusion If enforcement were to concentrate efforts on actual surveillance, and spot checks, combined with sophisticated vessel/catch profiling to indicate likely targets for detailed surveillance activities, the results would be far more productive than simply comparing report totals.

Constraints on Outputs

Everyone requires timely and accurate information.

Enforcement requires that information pass the legal tests for evidence.

Much of the information is commercially sensitive, and as such, strictly confidential.

Future development and contestability require that open standards be adopted and enforced - for both database design and information security. Industry accepts and endorses the Database Specifications and Standards developed by MFish.

Constraints on Design

Industry wishes to note that there is no requirement for the body that physically holds the databases to be the body which is responsible for the maintenance of those databases, or processing of the input to them.

It is entirely possible that the information going into the database could be collected and processed by a body other than the body owning and maintaining the hardware on which the database resides.

Conclusion The rules and constraints on the collection of information should be kept entirely separate from the rules and constraints on access to that information.

Size of Project

What sort of information flows are we talking about ?
How big are the numbers ?
What is the size of the problem we are dealing with ?
Most of these databases are very small by todayís standards.


There are some 2,500 holders of quota in the current system (2320 as at 11/11/96), with about 2,600 vessels.


There are 184 stocks currently in the Quota Management System (of 33 species groups).
This is likely to increase to some 140 species groups, or some 800 stocks.


Currently there are about 11,000 records on the holdings database. This may rise to some 40,000.
Currently some 3,000 documents are process for trading purposes.
Under ACE - this could change dramatically. As the act currently stands, there is likely to be little trading until after the end of year - as the risk to companies is too high. Should that change, and trading be possible electronically, it is likely that trade volumes would be likely to run at about 1,000 documents per month (with an average of about 5 stocks per document). This would give an annual database of some 12,000 ACE trade records, or 60,000 stock trades. With most of the transaction processing being handled electronically (via encrypted eMail attachment) this load is minimal. A single PC dedicated to this task could process over 200 transactions an hour - with confirmations (ie and average monthís transactions in 5 working hours).

ITQ & Securities will be paper based transactions.
ITQ trades are likely to be minimal - probably less than 500 documents per year.
Securities may be more common, say 1,000 documents per year. If these were to take 10 minutes each to process (a generous allowance), that amounts 250 person hours per year, or 5 hours per week (on average).

Monthly Balance reports.

Currently these generate one page per stock - and carry very little information which changes.

A re-design of this report to a spreadsheet style output would reduce this to one page per person in most cases (2 or three pages for the top dozen or so quota holders).

ACE ACE ACE ACE Catch Catch Catch Balance
Stock Open In Out Total Open Month Total Available
ABC1 1,000 2,000 500 2,500 850 1,250 2,100 400
XYZ7 2,000 1,000 0 3,000 1,612 1,014 2,626 374

This drops the requirement for paper to some 2,500 pages per month for monthly balances, and a similar requirement for invoices.

With a reasonable laser printer at 10ppm would take 250 minutes of just over 4 hours for each print run. With a mechanical folder & stuffer, the whole monthly balance run could be done by one person in one day. Another day to print and send invoices.

The entering of receipts, and processing of cheques should take no more than 1 minute per client - or 50 hours (at 50 per hour). Allowing a couple of days for processing any queries, that is 2 weeks per month for one person to handle monthly balance and invoicing.

All of the above functionality could be achieved by a PC, or a small network of PCs.

Conclusion The amount of processing for the ordinary accounting needs of the ministry is minimal, requiring at most two people, and at best one person part time.

With automated ACE trading, the registry functions of ITQ trading and Securities registration are minimal, requiring at most one person.

This leaves only the data processing - of QMRs, LFRRs, and CELRs.

QMRs and LFRRs can be largely automated, so that paper traffic is likely to be under 500 forms per month. Section 296 allows for electronic transmission of any form, by anyone provided both are approved.

Total Registry staff excluding CELRs - 3 - Manager/Registrar plus 2 operators.

This leaves the major area of IT cost and performance to be addressed as the CELRs, as their information is so vital to the continuity of the fisheries we all rely upon. My suggestion is a separate unit, probably closely allied with a scientific institution, to handle all of the CELR processing. This would consist of a Manager/Scientist and two or fouroperators.

With fishers paying the full cost of data entry - many will opt for electronic submission - by disk or eMail, to reduce their costs. This unit could well end up being simply two people, over a period of a year or two.


Use of Electronic transmission has the potential to dramatically reduce costs and increase performance of registry functions, and Catch Effort recording.

The size of these systems is small by todayís standards, and can easily be accomodated on Personal Computers - there is no need for expensive larger platforms.

The number of people needed is small, and could start with as many as 8, probably reducing to 5 over a period of 2 years - perhaps to as few as 3.