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.
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:
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
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.
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.
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.
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.
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).
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.
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.