Loading...
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