HomeMy WebLinkAboutMunicipal Information System Preliminary Study 1981Town of Southold, New York
Municipal Information System
Preliminary Study
December 23, 1981
Department of State
State of New York
01.0 Summary
We recommend that the Town of Southold:
1. Consider the acquisition of a minicomputer for its
Business Office.
Adopt a procedure to encumber funds in conformity with
regulations of the New York State Department of Audit
and Control.
e
Settle on one of the three design strategies (which we
summarize in the report) before taking further action
to change the way information is handled.
02.0 Background
02.1 Introduction
At the request of Mr. William Pell III, Supervisor of
the Town of Southold, the Department of State undertook
to determine the feasibility of computerizing certain town
operations.
On June 3, 1981 a research team from the Department
of State made a visit to the Town to set the scope of the
study and to review local records and procedures.
The study was limited by the Town Supervisor to the
Town's business office and the tasks handled by the two
full time and one part time staff members assigned to that
office.
02.2 Scope
This report presents the findings and recommendations
resulting from a limited scope study of the Town of
Southold fiscal and personnel information system. The study
treats the Town's business office as an independent system
receiving inputs from and sending outputs to individuals
and agencies outside of its own jurisdiction. It treats
other town departments as external entities. Hence, the
internal operations of other departments are not
considered.
Appendix A explains how to interpret the data flow
diagrams used in the report. Appendix B describes
alternate approaches that can be used in computerizing town
operations. Appendix C is a guide to writing operations
manuals.
02.3 Design Considerations
This study makes use of structured systems design.
Structured design is a method for accomplishing the
objectives of this study in a manner that is understandable
to the end user, and also understandable to the computer
technician. This design methodology makes use of a unique
graphic technique for picturing information systems. Data
Flow Diagrams, a key element of this technique, are used in
this report. Appendix G (page 15,ff.) contains an
explanation of how to read these diagrams.
In most areas examined by the study team, it was found
that computerization would improve processing time,
increase accuracy, standardize procedures, and provide more
useable information for management control and decision-
making in general. Nevertheless, this report does not
specifically recommend computerization of any municipal
function. Rather, the report provides an orientation for
officials in Southold to use to decide whether the benefits
of computerization are worthwhile locally. Should local
officials decide to automate, they can then decide on the
order in which computerization will be implemented.
If Southold opts for computerization, local officials
will want to be sure that all of the steps have been taken
to assure success. There is a set of generally accepted
procedures to follow in implementing an information system.
This system life cycle is described in Appendix B (page 15,
ff.). A good view of where town government is in the life
cycle will help local town officials to stay in control of
the project.
3
03.0 General Observations
03.1 Context
The context diagram (Figure 1, page 6) represents the
information which the business office indicates it receives
or sends out. The diagram defines the information
environment in which the business office operates. (Staff
of the Southold business office is the primary source of
information for the study. The context diagram is not
necessarily representative of all of the town's financial
reporting obligations.)
The heaviest flow of information occurs between the
business office and the Supervisor. This is as expected
since the Town Supervisor, as chief fiscal officer of the
town, has direct supervisory authority over business
operations. Interaction with the Supervisor is largely for
the purposes of annual budget preparation, accounting
summation, payroll technical approval, and expenditure
approval. The Supervisor is the business office's conduit
to the Board.
Another heavy dataflow occurs between the business
office and town departments for payroll and purchase
vouchering purposes. The Police and Highway departments
send timesheet summaries only, indicating that some of the
payroll work is handled outside of the business office.
Similarly, the Highway Department sends bills for payment
along with purchase vouchers, indicating that some of the
traditional purchasing responsibilities of a business
office are lightened in Southold by the completion of some
tasks by the originating department.
4
FIGURE 1
TO~ OF SOUTHOLD, BUSINESS OFFICE
A~P
Interaction with ADP, Inc., a commercial data proces-
sing service bureau, is the next heaviest data flow. The
Town purchases payroll processing services from the firm.
Together with the exchange of information with ADP,
Inc., other dataflows are fairly transparent to the rest of
town government, impacting exclusively on the internal
operations and responsibilities of the business office.
All are ancillary to the payroll, purchase, accounting, and
budgeting subsystems. The Task-Level Diagram (Figure 2,
page 7) spells out more clearly the relationship between
the various subsystems and external agencies.
04.0 Task Analysis
04.1 Audit Purchases
The Town of Southold should acquire a software
purchasing system which will:
1. enable its bookkeeper to encumber funds at the instant
an obligation is identified;
integrate the purchase process with
process so that the immediate financial
town can be ascertained on demand;
the accounting
position of the
provide a means for the chief fiscal officer to certify
that funds are available in a given account for
requisitioned purchases;
4. generate seasonalized purchase histories.
6
FIGURE 2
TO?~l OF SOUTHOLD, BUSINESS OFFICE
~,~L.L ~
The Audit of Purchases function involves putting
purchase orders and vendor bills in order, and obtaining
expenditure approval, prior to payment. The Business
Office reports that it does not encumber Town funds. (Fund
encumbrance is the setting aside of funds to cover the
estimated cost of purchases.) The Office relies on
individual departments to maintain their own accounts and
expenditure control procedures.
In its Uniform System of Accounts for Towns,
Comptroller's Division of Municipal Affairs
following requirement:
the State
makes the
Each appropriation account [prescribed for towns]
shall show the amount appropriated, the amount encum-
bered but remaining unexpended, the amount expended and
the encumbered balance.
Before a purchase order is released an encumbrance must
be filed with the [town] accounting officer. The chief
fiscal officer [of the town] will enter the encumbrance
against the proper appropriation account and indicate
his approval on the copy of the encumbrance and return
it to the [originating] unit. In case a proposed
commitment exceeds the balance available, the encum-
brance cannot be entered and must be returned to the
unit without approval. [1981:5-6]
The purpose of this rule is to assure that liabilities
will not be created in excess of amounts contained in the
approved town budget.
Recurrent cost overruns in at least one department
(Police) point up the need to introduce an encumbrance
procedure. However, if encumbrance were to be justified
solely on the basis of cost overruns a more formal analysis
would have to be undertaken to rule out alternative sources
of this problem.
Implementing an encumbrance procedure requires changes
in local purchase authorization. At present, the Highway
Department undertakes purchases independently of the
Business Office, sending both a purchase order and bill for
payment to the Business Office after the fact. An
encumbrance procedure requires prior approval from the
Business Office before an order is sent out to a vendor.
And though encumbrance does not require central bid
solicitation or order placing, time could be saved if the
Business Office took care of these procedures at the time
funds were encumbered. (The alternative is to send
encumbrance notices back to the original department, thus
authorizing that department to make a purchase.
Centralization eliminates a step, as compared in Figure 3,
page 10).
The utilization of an inhouse computer would have a
limited impact on the audit procedure now in operation.
The flow of hard copy forms (purchase orders and bills
written on paper) cannot be stemmed through the use of a
computer. Nevertheless, transforming purchase orders and
bills into their magnetic counterpart on a computer can
make the process of matching orders with bills, sorting
them by vendor, and typing an audit warrant for Board
approval much more efficient. Information from these hard
copy forms can be entered into the computer through a video
display terminal at the time they are received by the
Business Office. From that point on, the hard copy
documents can be archived and would not be needed again in
9
FIGURE 3
TOI'~ OF SOUTHOLD, BUSINESS OFFICE
10
the course of normal business operations. The draw back is
that time required to enter data could be equal to the time
now required to sift through forms manually. (A time
study, as a part of a formal system project, is needed to
make this assertion conclusive.)
On the other hand, the number of additional functions
that are tied to this data can each serve to reduce the
cost of data entry as a percent of the total cost of
auditing purchases. Furthermore, there is reason to believe
that the laborious data entry operation would pay off in
terms of increased speed and accuracy in these additional
functions.
04.2 Account for Fiscal Activity
An integrated accounting system is needed which will
allow posting on a daily basis with trial balances and
financial reports drawn on demand.
Automated reporting would eliminate the expenditure of
staff time now necessary to draft and type the "Monthly
Report of the Supervisor." Furthermore, a good software
system would enable a trial balance to be taken at any
instant of demand, eliminating the rigors of closing out
books at the end of each month.
An accounting system which is integrated with purchase
auditing will enable approved expenditures to be posted to
ledgers without further consideration of the actual dollar
value or account assignment of purchases, since these would
have been established during the audit of purchases
process.
11
04.3 Executive Deposit and Withdrawal Orders
The automated printing of checks (withdrawal orders) to
vendors and personnel is a desirable--though not mandatory
--requirement for any system the town could install for its
business office.
Drafting checks can be a time consuming task. Payroll
checks, in particular, would require a significant amount
of staff time to prepare manually if the existing relation-
ship with the commercial service bureau were severed. One
manual system on the market, for example, requires that 18
entries be made onto payroll records for each check drawn.
Many of these require arithmetic calculated prior to entry.
A computer could process and output a payroll check
requiring 18 entries at a rate of 8 seconds per check.
The maintenance of a vendor list in computer memory
would also enable payments for purchases to be made with
considerable ease. The integration of check writing
procedures with accounting procedures would enable the
automatic delivery of checks for all outstanding payments
on demand. Just as accounts could be updated using
information entered at the time a purchase order is first
encountered, so this same information could be used to
generate payments without further manual work.
04.4 Reconcile Bank Accounts
The reconciliation of bank accounts is essentially a
manual operation, though the process would be eased by the
fact that an automated check writing system should be able
to produce a register of checks issued. It may be
desirable to acquire a system which allows a notation for
returned-cancelled checks. This would be desirable if a
report of all outstanding checks are required, for
example.
12
04.5 Report Monthly Fiscal Activity
This task is considered as part of section 04.2 Account
for Fiscal Activity.
04.6 Process Payroll
The acquisition of a computer solely as a replacement
for services now provided by a commercial service bureau
would not save money. We anticipate, however, that the
processing of payroll in conjunction with other business
office tasks would increase control over the payroll
function without increasing present cost. Staff time
required to operate an inhouse automated payroll system
would be essentially the same as that now required to
complete service bureau data entry forms. Accuracy, how-
ever, would be increased since business office staff would
be entering data directly into the computer system, rather
than completing a form which others enter into a computer.
An inhouse system would also be far more responsive to
changes (the addition or deletion of an employee, or change
in pay rate) that the present arrangement.
13
Appendix A
Data Flow Diagrams
The diagrams contained in study reports are worth a thousand
words. They picture the flow of information through an organiza-
tion in a way that is meaningful to both the end user of informa-
tion and the information systems engineer. They eliminate the
time involved in creating a mental picture of an information
system from a complicated narrative exposition.
Data Flow Diagrams are used to picture the movement of
information within a predefined system. The boundaries of such a
system are arbitrary, and can be altered to make a study more
manageable. For example, Data Flow Diagrams that are used in
preliminary studies often treat departments within a local
government as independent systems. But the diagrams that emerge
from more formal research may identify the entire local
government as a single system with subsystems, such as budgeting
and payroll functions, that cross-cut organized departments. Any
chunk of human organization may be defined as a system, so long
as the parts within it are related in some particular fashion. A
major job that the Data Flow Diagram does is to picture the
relationships within a predefined system.
The symbols used in Data Flow Diagrams are few and simple.
Rectangles represent organizational units outside the system
being examined. Arrows represent actual pieces of information.
Bubbles stand for actions taken on the information. Open-ended
boxes are data stores.
Outside agencies (represented by rectangles) can be sources
of information, or final destinations of reports produced within
the system. An arrow emerging from a rectangle shows a piece of
information flowing from that source. In Figure 1 A, below, a
complaint is flowing into the system from a citizen.
A i
Figure 1 A
Whenever information flows into a system, it triggers some
action. Complaints may first be logged in a book. A vendor's
bill might first be compared with purchase orders or shipping
invoices. A citizen's request for a license may cause a clerk to
first check records to see if a license has already; been issued.
These actions are represented in a Data Flow Diagram by a
"bubble." Figure 2 shows mail, delivered by the U.S. Postal
Service, being date-stamped before any other action is taken.
Figure 2 A
A-2
In most instances, the actions represented by each bubble in
a Data Flow Diagram transforms the data. Mail, in Figure 2 A, is
transformed into date-stamped mail. Date-stamped mail might then
go through successive transformations (sorting by addressee,
culling advertisement literature from the pile, adding an
internal mail code) before reaching its destinations. A mail
room, defined as a system, might be diagrammed as in Figure 3 A.
Figure 3 A
It is often necessary to file pieces of information. Or
information might have to be retrieved from a file. For example,
a written grievance might be received by a personnel department.
The department's procedure might call for a clerk to examine the
employee file to make sure the grievance is from a current
employee, and then to file the grievance for later action.
A-3
Figure 4 A
In Figure 4 A, open-ended boxes are used to represent an
employee file, a file of rejected grievances, and a file of bona
fide grievances. Any kind of physical file is represented by the
open-ended rectangle, whether an index-card file, pigeon holes in
a mail room, standard filing cabinet, a list of codes kept taped
to a desk top, or a file stored in computer memory.
Rectangles, arrows, bubbles, and open boxes are all there is
to Data Flow Diagrams. Any system can be described with them.
And to make matters even simpler, the diagrams are presented in a
way that first outlines the overall system before getting into
the details. The first chart in a Data Flow Diagram shows only
one bubble, representing the entire system. The next chart shows
the same system, but with more bubbles to represent the various
tasks carried on within the system. Successive charts take each
bubble and break it down into more bubbles to show increasing
detail. The method makes the description of an information sytem
so straight forward and easy to read that data processing pro-
fessionals have had to invent a high-sounding word to make it
seem complicated. The call it "step-wise refinement". But
really, its the old method of outlining things from the general
to the specific we all learned in high school.
A-4
Like any outline, Data Flow Diagrams use numbers to identify
the steps taken to refine the picture of the system. The number
in each bubble is not a sequence number. The action represented
by a bubble numbered "2" does not necessarily follow the action
represented by number "1". Instead, the numbers are references
to other pages in a multiple paged Data Flow Diagram. In Figure
4, bubble No. 8 represents a grievance review process. Not very
much is known about the internal working of the review process
from this diagram. But on a succeeding page in the Data Flow
can a
Diagram, the details be spelled out using "lower level"
diagram. Each bubble in such a lower level diagram would be
referenced using the number 8, as the example in Figure 5 below.
Figure 5 A
As the diagram grows, increasingly more detail is presented.
In Figure 5 A additional files have appeared. These files were
hidden inside bubble 8 in Figure 3 A.
Data Flow Diagrams are at the heart of a state-of-the-art
Structured Systems Design methodology. In advanced studies, Data
Flow Diagrams contain such finite detail that the systems
A-5
engineer can easily transform them into operations manuals,
designs for computer programs, or specifications for contract
bids. But the preliminary Data Flow Diagram has more limited
objectives. The preliminary diagram is used for an overview
ofthe system under study. Before extensive effort is put into
formal analysis, a preliminary view enables decision-makers to
choose which major sub-systems to include in an information
system design, and which to ignore or put off until later.
The power of the Data Flow Diagram lies in its simplicity.
With only four easily understood symbols (rectangle, arrow,
bubble, and open-ended box) any information system can be repre-
sented. End users find that Data Flow Diagrams speak their
language, since it is common to think of work as involving taking
something from the "in-basket", doing something to it, and
sending it out. Systems engineers find that the Data Flow
Diagrams speak their language too, since it describes a system in
the structured way required by computers. And all without
wasting a thousand words.
A 6
Appendix B
Information System Development
Design Approaches
Three approaches have dominated the history of information
system design: incremental, MIS, modular.
The incremental approach involves developing new procedures,
one at a time. Perhaps the executive officer makes a list of
tasks he wants worked on, or he simply indicates which task he
wants to begin with (waiting until that task is complete before
choosing the next one). Usually he begins by selecting financial
operations for implementation on a computer. That done, he moves
to other applications. For example, a local government might
hire an outside contractor to develop a payroll system. A year
later, another contractor might be hired to develop a tax ac-
counting system. Still later, other contractors might be hired
to build water billing, equipment inventory, and highway main-
tenance systems. With the incremental approach, each system is
designed separately and operates separately. Each uses different
forms, stores data in different ways, and uses different pro-
cedures to achieve different reporting objectives.
This approach has the lowest short term cost. The local
government can buy only what it needs to satisfy a single
pressing need. The data processing industry is even set up to
address such piecemeal needs. Limited software packages are on
the market that enable a data processing consumer to select one
package to keep track of water bills from one firm and a package
to process parking tickets from another. Packaged software is
cheaper to buy, since the ability of the manufacturer to sell the
same package again and again allows him to lower his costs.
B 1
But there are also problems engendered by the piecemeal
development of systems. Sometimes the same piece of information
is needed on more than one system. To get it there, clerks have
to complete separate forms with the same information and type
each one separately on the computer terminal. So instead of
reducing paper work, the computer increases it. Sometimes the
same information is needed in separate formats: last name first
on one and first name first on another, or a birthdate written
"6/8/32" on one and as "June 8, 1932" on another, or a five
character account number for one bill and a ten-character number
for another. So instead of simplifying work, the computer makes
it more complicated and more prone to error. Often, too, there
is no way to bring data from different systems together, as might
be needed for a fiscal report. This
of all. The computer, which is best
tical comparisons and at revealing
tionships, is unable to compare the
banks.
is the most ironic situation
at doing complicated statis-
financially important rela-
information in its own data
The result: short term savings but long term expenses.
The MIS approach was developed to overcome the problem of
information incompatibility inherent in the incremental approach.
The idea was to put all information that is ever needed together
in the same location. Such an integrated database becomes a pool
of information that can be used for different purposes and for
different kinds of processing. From the database can be pulled
the data needed for routine operations: to generate a payroll,
bill sewer renters, provide a list of outstanding police
warrants, etc. It can also be used to answer management
questions or provide routine reports to aid the decision-making
process: based on experience, how much revenue from all sources
can be expected each year for the next five years; over the past
year, which department has had the highest rate of absenteeism;
what impact will cracking down on scofflaws have on court
operations.
B 2
The ability to bring together all the information needed to
answer high level management questions is the cornerstone of the
MIS approach.
The drawback to the MIS approach is that in practice it
turns out to be very complex and costly to implement. A
long-term design group is required to consider every issue of
importance to the organization before the system can be con-
structed and implemented. And while such a system usually
contains every conceivable combination of data in summary
reports, there is no guarantee that management is really able to
use the information it provides. This can happen if decision-
makers do not know how to use the information, or if they prefer
their own optimistic guesswork to forecasting events based on
concrete data. The result is that the MIS becomes a high-priced
expressway that will take people where they don't want to go.
The waste is even deeper when the system is designed so that
additional information is collected during more routine opera-
tions for the sole purpose of supplying data for a report that is
never read. A job application form that includes a question
about marital status solely to provide information for a report
on the number of divorced people in the workforce is wasteful in
two ways. First, a local government has to pay for the system
design and implementation in order to produce a report that is
never read. Second, the consumer must continue to pay for the
time necessary to extract this unneeded information from applica-
tion forms, code it, and enter the data at a computer terminal.
A sophisticated MIS can require that thousands of such needless
tasks be performed routinely. The annual cost can be staggering.
New developments in system design technology over the past
few years have lead to a new approach. This structured approach
has rendered the workable objectives of both the incremental and
MIS approaches. It uses the step-by-step strategy of incremental
B 3
design, while guiding each step with a master plan. In the
structured design strategy, every major software piece is
designed for a particular, specialized application. The major
software pieces are called modules. One software module might be
developed to handle payroll, another to handle project manage-
ment, another capital budgeting, and so on. Each module is
developed separately and operates independently of any other. The
most important ones may be developed first, the less pressing
ones later. However, all program modules are written in such a
way that they can make use of a common set of files, the inte-
grated database, which are defined independently from program
modules. For example, an integrated database might contain a
single definition of birthdate. Individual program modules that
need to use birthdate, such as a software module that handles
retirement payments, can only use the definition contained in the
integrated database.
The structured design methodology puts greater constraints
on software modules, not allowing individual programs to go their
own. Yet it results in a more flexible system. An examination
of some advanced results of this methodology demonstrates this
point. Under the MIS approach, every conceivable report is
predetermined by system designers. The structured design
strategy also predetermines some reports, though only those which
users indicate are regularly needed. But in addition, users are
able to specify their own special purpose reports as needed. In
the most sophisticated (and highest priced) systems, users can
type an ordinary, English language sentence on a computer
terminal, and the terminal will provide the answer. It is a
technology which approaches Star Wars fantasy. A decision-maker
can ask, "If I give police employees a 12% pay raise and I give
everyone else a 7% pay raise, how much will the total personal
services expenditure be?" The computer will extract all the key
B 4
words from the sentence, look up their definitions in the
database, find the data it needs to calculate the answer, do the
arithmetic, and print out the answer. Enormous flexibility is
required to execute such a task. But the flexibility engendered
by the structured design strategy has implications for less
sophisticated systems as well. Just as special reports can be
generated, so new software modules can be added to the system
without the threats of inconsistency and duplication that are a
part of the incremental approach.
Because of their flexibility, systems designed using a
structured approach are long-lived when compared to the results
of other approaches. Investment in existing software is
protected and the cost of the system over its life are reduced.
However, unlike the incremental approach, start up costs are much
higher. First, there is the cost of a system study which must be
done to achieve the benefits of structured design. To this must
be added any costs associated with the delay in computerization
caused by the time needed to complete the study. There are
additional hardware costs. Even though integrated databases
eliminate duplication, the technology usually requires more
storage space than conventional files. Fourth, depending on the
sophistication required, the system may require the purchase of
some special software in addition to the software modules
required to handle such things as payroll, billing, risk
management, etc. Finally, the cost of software modules may be
higher than conventional software packages. This is largely
because there are fewer firms available who have adopted a
structured design methodology. Though many organizations who
have their own, in-house programming staff have adopted
structured methodology, fewer companies that sell packaged
software to the data processing consumer have made this change.
It is a case of the market place not having caught up to the
technology.
B 5
System Life Cycle
The life cycle of systems developed with the modular
approach is unique. As systems studies get under way, the entire
organization comes under the analyst's spy glass. Towards the
end, only a few tasks survive to become implemented systems.
A local official might identify payroll as a problem area.
With luck he will have successfully escaped the grasp of venders
who are too willing to sell systems with claims that they will
meet all needs. Instead, he may fall into the clutches of a
systems analyst using a modular design approach. Suddenly his
payroll problem will become many problems throughout the entire
organization as the analyst recommends a comprehensive view.
Often leading a team of data gatherers, the analyst sets out to
do a preliminary study. The preliminary work is aimed at an
overview of the entire organization. Though the initial
treatment may be uneven -- the existing payroll system given more
depth than the assessor's tasks, for example -- it should touch
on all major functional areas. Done well, the preliminary study
becomes the framework on which modular subsystems are hung.
Following the preliminary study, local officials decide
which tasks they want to reorganize or computerize and which will
remain unchanged for the time being. This review step narrows
the focus of future work and saves time and money which, using
the MIS approach, would be expended on systems designs which are
not needed. Modular design allows you to cut as you go.
B 6
After this review, analysis enters a formal study phase.
Here analysts delve more deeply into the remaining parts of the
system. The payroll system that originally sparked conern may
not receive formal study treatment as hotter issues -- revealed
by the preliminary study -- leap forward. In the formal study
analysts measure the exact volume and fluctuation of purchase
orders processed. They take estimates of staff time required to
complete hearing minutes. They measure the dimensions of the
workspace assigned to the typing pool. They check the frequency
of calls received by law enforcers. They collect every item
needed to document the existing system and to specify a new
system. The result is a report which pinpoints areas where
savings can be expected and where new costs can emerge. Formal
analysis weighs costs against benefits, and lays a groundwork for
the arduous task of system specification ahead.
But before plunging into system specification; the project
pauses again to allow futher narrowing. Management now culls
from the project those tasks which formal analysis has revealed
are too costly, unneeded, conunterproductive, or too low a
priority to be undertaken now.
The specification phase entails a detailed description of an
information system to replace or augment the current one. The
process can vary in depth. Specifications that are meant to guide
programmers to implement the system in code (using COBOL,
FORTRAN, or another computer language), require greater effort
than those meant to solict bids form vendors. But it is always a
painstaking process. An exact blueprint of what is required must
be drawn to leave no question in the mind of the recipient.
System specifications say, "Give me an inventory system just like
this." They have to be precise; sloppiness here would mean that
a considerable number of dollars could fly out the window to
implement a faulty system.
B 7
The final review before implementation is management's last
chance to say no. For those specifications that receive official
blessing, it is onward to implementation. Just as the specifi-
cation phase can vary, so can implementation. For a local
government with an inhouse data processing department,
implementation can mean assigning programmers to coding tasks.
Other municipalities without their own data processing staff may
solicit bids, select a vendor, and spend most of the remaining
time waiting for a vendor to deliver its product. Implementation
is complete when the system is installed and meets all
performance tests.
Figure 1 B (page 9 B) shows the life cycle graphically.
Letters A through T represent tasks such as tax billing, youth
counseling, or snow removal. Shaded areas represent systems
analysis activity. If an MIS approach were used, the entire
diagram would be shaded. Hence, unshaded areas represents the
savings in study effort resulting from the modular approach. The
incremental approach could be represented by a single column with
only the problem identification, specification and implementation
phases included. System development costs are the least for this
approach.
B 8
FIGURE lB
TASKS UNDERGOING SYSTEMS ANALYSIS
~fDEFGHI]KL ~ DPaRST
PROBLEM IDENTIFICATI(~
STUDY DEFINITION
PP. ELIMINARY STUDY
REVIEW
FORMAL STUDY
REVIEW
SPECIFICATION
P. EVIEW
IMPLEMENTATION
FOLLOW-UP
B9
Appendix C
Operations Manuals
An operations manual is the procedural roadmap of an
organization for its employees to use in carrying out day-to-day
work. It explains, often in minute detail, how the business of
local government is to be conducted. An operations manual
records current operations and, in so doing, creates a history of
procedures that have been tried and tested. Sections of manuals
that are replaced with better procedures show what has proven
unsuccessful. Those that remain unchanged are the procedures
which time and experience have shown to be good government
practices. This written history is an invaluable guide to
organizational development, helping managers to avoid the
reintroduction of procedures that have already proven faulty;
helping them provide a clear statement of what works.
Procedures which work best are those which impose standards
across the entire government organization. Consistent work
practices help direct all government activities toward a common
goal. Employees often forget the ultimate purpose towards which
their daily actions are directed. A receptionist, for example,
might forget that his role is to serve the public and adopt a
method which makes life easy for him, but difficult for the
citizen. The imposition of a standard method of operation
provides a substantive guide to behavior which is originally
created with high level policy in mind.
Operations manuals also facilitate the training of new
employees. The manual can be a clear "how-to" book that allows
the trainee to take note of what situations can occur, even when
these events are not at hand. Throughout the job experience, the
manual instructs employees in the performance of their duties,
even if tasks do not occur regularly. When it is time for a
C-1
local government to issue property tax bills again, the manual
refreshes the memory of clerks who have not thought of taxes for
nine months. And by providing a basis of instruction for those
who may have never performed a given task before, the manual
helps eliminate dependency on single experienced individuals to
carry out critical procedures.
A basis of control is also created through the use of a
manual. Procedures serve to delegate to subordinates the
authority to make decisions within the policies devised by
management. From this point of view, the manual is an extensive
articulation of local government policy, setting the boundaries
for decision-making at each level in the organizational
hierarchy.
Finally, written procedures force an examination and evalua-
tion of the system of operations itself. They help establish a
benchmark against which current and future needs can be compared.
Both management and employees are able to resolve questions about
how the job should be performed.
Manual Formats
Operations manuals should be set up in a format that best
serves the needs of those who use them. A poster on the wall may
be the best way to instruct a sanitation worker how to inspect a
garbage compactor. Photographs may be appropriate to show fire
inspectors what hazards to look for. But most procedures fall
into one of three formats.
The narrative procedure is in essence a long story that
tells what is to be done, who will do it, when it will be done,
and how it will be done. (This what-when-who-how formula occurs
in all procedure formats.) Narrative procedures are the hardest
C-2
to put together. They depend on good technical writing skills.
Smooth transition is required between the various steps.
Grammatical structure is a predominant concern.
Overpayment of Tax Bill
The Treasurer Clerk refunds taxpayers for overpayment of
tax bills by issuing a refund check. Direct cash payments
are not made. If a taxpayer insists on cash, he should be
informed that the municipality's check can be cashed at a
local bank.
The taxpayer must sign his name, and enter his address
and tax payer identification number on the blue refund card
(Form T-3).
The Treasurer Clerk then enters the amount of money
refunded to the taxpayer in the refund journal (Form T-91).
A refund check (Form T-92) is then drawn in the taxpayer's
name. The refund check should then be given to the tax-
payer. The blue refund card is forwarded to the Treasuer.
The playscript method uses sequence numbers, actors, action
verbs, and a straight chronological sequence of who does what in
the procedure. For example:
PROBLEM: Overpayment of tax bill
1. Treasurer Clerk
Pay all refunds by check. Do not make
direct cash payment. If taxpayer
insists on cash, inform him that the
municipality's check can be cashed at
the local bank.
2. Taxpayer
Sign name; enter address and tax payer
identification number on blue refund
card (Form T-3).
3. Treasurer Clerk
Enter refund payed on refund journal
(Form T-91) and draw a refund check
(Form T-92) in taxpayer's name. Give
refund check to taxpayer. Send blue
refund card to Treasurer.
C-3
The outline method may be more familiar to most people. The
reader is walked through the process, item by item, guided by
step references. References to various parts
are made easily because of the roman numerical,
identification of each step. An example of
follows.
of the procedure
letter, or number
an outline format
I. Overpayment of tax bill
A. Treasurer Clerk
1. Pay all refunds by check
a. Do not make direct cash payment
be
If taxpayer insists on cash, inform him that
the municipality's check can be cashed at the
local bank.
B. Taxpayer
1. Complete taxpayer portion of blue refund card
(Form T-3)
aJ
sign name
enter address
enter taxpayer identification
number
C. Treasurer Clerk
1. Enter refund payed on refund journal (Form T-91)
2. Draw a refund check (Form T-92) in taxpayers name
3. Give refund check to taxpayer
4. Send blue refund card to Treasurer
C-4
Recently, decision tables have appeared in operations
manuals. Decision tables represent combinations of events and
the actions that should be taken. In the example below, a Court
Clerk is instructed in what action to take. The first section of
the table (above the double lines) contains "IF clauses." The
lower section contains the "THEN clauses."
PARKING VIOLATION X
MOVING VIOLATION -
X
FIRST OFFENSE
MOVING VIOLATION - X X
SECOND OFFENSE
DRIVING W~IILE INTOXICATED X X
IMPOSE $15 FINE X
IMPOSE $50 FINE X
REQUIRE COURT APPEARANCE X X
ISSUE ARREST WARRANT X
An "X" represents an existing condition.
fourth column is read,
For example, the
IF the offense is a second time moving
violation
AND the vehicle operator was
charged with driving while intoxicated
THEN issue an arrest warrant.
C-5
Written procedures do not spell out the why of each step.
Because of this, they are more simplified and condensed. Written
procedures should specify clearly the action required by the
employee.
To write operational procedures, devise a logical outline.
This outline should be a rough draft of the sequence of steps
within the procedure. Use charts, graphs, and examples of
completed forms whenever it makes the procedure clearer and
simpler. Write short sentence of ten words or less.
Indexing is necessary for a useable operations manual.
Without an index, information in the manual would be difficult to
retrieve. Indexing will also avoid the common complaint that, "I
can never find what I want in the manual," and avoid the problem
of user disaffection.
Ail forms used in the information system should be
identified by a reference number. When a form is introduced in
the text of the operations manual, this number should be cited.
In the index to the manual, all forms should be listed by name
and number. Somewhere in the manual should be a section which
collects together facimiles of all forms, appropriately com-
pleted. Sometimes a form may appear several times completed in
different ways.
The manual should also explain the filing system used for
records, reports, forms, or any other paper used. Describe the
type of filing equipment used and the method of indexing. Give
examples if this will help the reader understand.
C-6
Procedures in the operations manual should be clear, direct,
and to the point. Use present tense verbs and other action words
in a straight forward style of writing that moves the reader
through the operations smoothly.
There should be a method of disseminating and updating the
procedures, and this should appear in the manual also. One
method is to bind the manual like a book and reprint the entire
manual every three to six months. Only critical changes are
distributed immediately, and these are circulated by memo.
An alternative method is to distribute the manual in a
loose-leaf notebook. With this method, new and revised
procedures are distributed on hole-punched sheets to be slipped
in or out of the body of the manual. Users update their own
copies of the manual by removing obsolete pages and inserting
updated pages.
The manual writer should keep track of the time involved in
executing a procedure. A reasonable estimate of operating time
can be included with the procedure.
Procedures should be carefully evaluated to make sure that
none are excessively rigid.
C-7