Advice on the Use of a MICROCOMPUTER System
COMPUTERS
Ever hear of a “computer disaster”? Computer disasters are stories about people whose lives were ruined by a computer. A store owner, for example, may have had a successful business until the day a computer salesman walked through the door. Now, his computer system is inoperative, his records are fouled up, and the salesman’s telephone is disconnected.
Unfortunately, anyone who invests in a computer system runs the risk of creating a computer disaster. While the risk can be minimized, it will never disappear.
This is the fourth and final article in this series on microcomputers. In FIRE ENGINEERING’S October issue, we introduced you to microcomputer hardware. In November, we explained the various software available and their capabilities. In December, we offered hints on purchasing microcomputer software. This month, we’ll help you to disaster-proof your computer purchasing and use by dispelling some old myths. We’ll provide practical advice for each stage of microcomputer use and describe a computer-driven management system that can yield critical information for an agency’s decision makers.
COMPUTER PROBLEMS OR PEOPLE PROBLEMS?
Many people feel that computer technology is dangerous. Have you ever heard someone say, “Try to do something with a computer and you’re bound to cause problems”? Interestingly enough, there is some truth to that saying.
Microcomputers are tools, and like any tool, they have the power to focus and direct energy and work. Let’s use a fire service analogy: You respond to a kitchen fire in a one-story wood frame dwelling. The building is filled with dense smoke, little visible flame. The incident commander has ordered your company to ventilate the structure. You choose an axe to accomplish this task. Depending on how you use the axe, there could be favorable or disasterous results: The fire could be vented safely through the roof or through a horizontal opening, such as a window or door; OR the fire could be pulled into uninvolved parts of the structure, or with a delay plus incorrect venting, a backdraft could result, causing firefighter injuries.
The axe, as a tool, has the potential to contribute to the work effort or to significantly harm it. The type of axe is far less critical than the competence and training of the person using the axe.
Similarly, the microcomputer, as a powerful management tool, can be used to solve problems or to create them. The competence and training of the manager using a microcomputer is the critical factor. Let’s examine some factors that can contribute to computer disasters.
DISASTER FACTORS
There are three factors that aid the likelihood of a computer disaster: high initial investment, customized system development, and, as we have seen, poor management.
Of the three factors, two, high initial investment and customized development, are minimized by recent advancements in technology. Poor management, however, is as much a problem as ever. Let’s look at each factor.
Investment
In the 1970s, all computer systems were expensive. Small businesses that wanted to computerize had to invest a lot of money. There was no choice. Frequently, new computer systems worked well and netted businesses a good return on their investments. Sometimes, however, the computer didn’t function as expected. Large investments in expensive computer systems caused financial hardships for many small businesses.
Today, as we enter the mid-1980s, there’s a choice. While there are still expensive computer systems, there are also a variety of powerful computer systems that are comparatively inexpensive. A small business can obtain a powerful computer system for less than $4,000. You can now try computerization without risking a pile of money. Smaller initial investments have lowered the risk for first-time computer buyers.
Continued on page 40
Continued from page 38
Customized development
Customized system development is another factor that can increase the risk of computer disaster. The buyer gives a vendor money to create hardware and/or software that have never been produced before. It’s risky business and frequently unnecessary.
Today, standardized hardware and pre-packaged software are inexpensive, easy to use, and available right off the shelf at your local computer store. Another benefit is flexibility. If you don’t like the way your “off-the-shelf” software performs, you can reformat it, and your changes will take hours, not weeks.
Management
Unfortunately, poor management is a risk factor that is not easily cured. There’s an old computer saying, “Computers will speed anything you do. If you manage well, a computer will help you manage well much faster. If you manage poorly, a computer will help you manage poorly much faster.” Many computer disasters cannot be blamed on new technology but rather on poor management. Let’s look at a list of the essential elements of good management during each stage of microcomputer procurement and use.
STAGES
OF MICROCOMPUTER USE
The purchasing stage
The essential elements of good purchasing include:
- Know your needs.
- Select appropriate software.
- Select required hardware.
The “IT’S HERE!” stage
Many fire departments get stuck in this stage for a year or more. The microcomputer is ordered. It arrives and gets taken out of the box. One or more people run a couple of simple programs, but the computer is never used for anything important.
Sometimes agencies get stuck in this stage because someone has decided that if a firefighter did “something wrong,” the computer system might be ruined. More frequently, however, managers simply don’t know what to do next. Here are some suggestions:
- Prioritize the list of applications you used to purchase the computer.
- Choose one application that is both useful and relatively easy to implement on the computer.
- Find someone in the agency who is interested in that application and has the time and inclination to learn the software package necessary to put the application on the computer.
- Take your time. Don’t try to start another application until your first application is running well. Maintain all paper records and don’t stop manual data processing procedures until the computerized version is fully debugged.
- Once you have developed one application, try a second application using the same software package. Remember, implement applications one at a time. Do one, debug it, try another.
The “Does this thing do anything else?” stage
Approximately 80% of those people who use a microcomputer use it with just one application package. Maybe it’s word processing or data base management or a spread sheet, but the tendency is to minimize the usefulness of microcomputers by sticking to just one piece of software. To move through this stage:
- Choose an application from
- your priority list that requires a second software package.
- Seek another volunteer to implement that software package.
- Train people to enter data from paper records into the computer.
- Offer opportunities for data entry people to learn to design software applications. Experts on one software package should train experts on other software packages.
The “Everyone wants something on the computer” stage
As soon as the computer proves itself as a useful management tool, everyone will want to have some type of application program running on the computer. The trick is to control the use of the computer without frustrating the enthusiasm of potential users.
- Allow people to participate in the planning and prioritization process. Ask them how they think a microcomputer may help them to save time or do their job better. How might an application in one division of the agency benefit someone in another division?
- Offer frequent, voluntary training sessions for both data entry and application design.
- Allow people free time on the computer. Games are especially useful for getting people comfortable with the computer and encouraging interest.
The “Let’s budget for more microcomputers” stage
Remember, two microcomputers may not be twice as useful as one. Consider the following:
- Do you need another micro? Is the present micro being used more than eight hours a day? Is it really necessary to have data entered in computers from each substation, or could it be done more efficiently and accurately from one central location?
- Make sure you have a master plan for computer procurement and use. A committee should be assigned to continuously assess microcomputer needs and to update a microcomputer master plan.
- Don’t mix operating systems. Remember, if you buy a second or third microcomputer, unless there is a compelling application requir-
- ing new software, don’t purchase new computers that utilize incompatible operating systems.
GETTING DOWN TO BUSINESS
Now that we know how to buy and use a microcomputer, let’s examine an area where a microcomputer can really earn its keep—decision support.
By knowing what you do and how you do it, you can design a management system that will provide critical information to agency decision makers. Let’s look at the design of a management system and several pitfalls which result from poor management.
A management system can be divided into two elements, formal and informal. Formal management elements consist of an organization’s written mission statement, plans, policies, procedures, goals, objectives, etc. Informal elements are an organization’s real life products and services.
To determine if a fire or an emergency management service (EMS) agency is being managed effectively, formal elements are studied first. If the organization, at least on paper, has a good idea of why it exists, where it’s going and how it’s going to get there, that’s a good start. The quality of the entire management system cannot be judged, however, until the formal elements are compared to the informal elements. In other words, is the quality of the formal (written) elements matched by actual operations? A microcomputer is most valuable when it is used to measure the quality of real-life operations.
Feedback
Most fire departments keep records. If Engine 22 responds to a grass fire, a record is made of the event. Similarly, EMS incidents, inspections, training, etc., are all documented by written record.
Unfortunately, records of many fire departments simply record a collection of individual events. Useful feedback on the effectiveness of an entire operational area cannot be gained until the data from individual records is processed into useful information. Let’s use fire incidents as an example.
A fire department responds to 2,000 fire incidents annually. Records for each run are stored in a file cabinet and used for investigations and to support insurance claims. Were these records to be entered into a computer using data base software, much more useful feedback information could be generated. As we have seen, a computer, with its electronic selecting, sorting, counting, and reporting capabilities, can process the data from individual records into useful management information, such as:
- Total dollar loss.
- Dollar loss by census tract.
- Dollar loss by ignition source.
- Out-of-service times by unit.
- Overall response time average.
- Average response time by unit.
- Etc.
This type of information will help a fire manager determine the effectiveness of both formal and informal organizational elements. Feedback information may be used to enhance formal elements by identifying ineffective policies and procedures. Similarly, goals and objectives may be changed to make them more realistic or more relevant to the organization’s stated purpose.
Feedback information may also be used to enhance informal elements. Feedback may reveal that policies and procedures are not being observed by operational personnel. For example, feedback information may indicate that serious head injuries are being taken to the nearest hospital rather than to specialized trauma centers identified in EMS protocols. Feedback information thus allows these types of deficiencies to be detected and corrected.
THE PITFALLS
Of the top five management pitfalls that contribute to computer failures, two don’t involve a computer at all. Let’s examine each.
No. 1, poor mission statement
This is a common fire service deficiency. Many fire and EMS agencies simply don’t have a clearly defined purpose. Even those managers who have developed a good mission statement frequently don’t share it with operational personnel.
A mission statement is a simple one or two sentence statement articulating the reasons for an organization’s existence. For example, “The Kingston Fire Department exists to protect the lives and property of the citizens of Kingston by providing fire protection and prehospital emergency medical services.”
Do you think a mission statement is unimportant? In the 1970s, many fire departments adopted pre-hospital EMS. Some departments had successful EMS operations, some did not. Invariably, the difference between success and failure was due to management’s insistence that EMS was a legitimate function of the department. Failure occurred when arguments about the appropriateness of EMS in the fire department were allowed to continue year after year.
A good mission statement, known by all employees, keeps everyone working together toward a common purpose. If there is disagreement about the purpose of an organization, a computerized feedback system will be almost useless. The information the feedback system produces will direct managers to the symptoms of poor operations rather than pinpointing the actual cause.
No. 2, poor goals and objectives
Frequently, an agency’s goals and objectives are not written in measurable terms. For example, “The Fire Prevention Division will lower fire incidents through increased fire prevention activity.” How can a manager, let alone a computer, determine if that goal is being accomplished?
Management System
FORMAL ELEMENTS INFORMAL ELEMENTS
Do “lower fire incidents” mean fewer fires, lower dollar loss overall, or lower median loss per fire? Does “increased fire prevention activity” mean more inspections, more public education programs, or more school drills? If you can’t measure a goal or an objective, your computer can’t measure your success.
A better example might read, “Over the next 18 months, the Fire Prevention Division will reduce the number of malicious fires by 30% through the establishment of a juvenile fire setters program.” Now the computer can measure your success and help you pinpoint problem areas.
Now let’s move onto some computer related pitfalls.
No. 3, too much info
Not everything needs to be on a computer. A manager with a pile of computer printouts on his desk may be suffering from “data pollution.” Remember, the goal is to support management decision making. Everything does not need to be put into the computer. Prioritize your applications and keep your computer-generated reports simple and relevant.
No. 4, info to the wrong people
Sometimes the chief of an agency will insist that all computer-generated reports go to his office without anyone else seeing them.
Information must be shared so that decision making can be delegated. If one individual attempts to make all the decisions in an organization, the organization will never be better than the talents of that one individual. Information needs to be distributed to the lowest management level capable of effecting the necessary changes.
It’s also a good policy to share information with line personnel. Remember, they are your primary source of data. The data that your computer processes is the same operational data that your line personnel collect. Make them feel a part of your management system by sharing information.
No. 5, too close supervision
Fire and EMS managers can use new information resources inappropriately. For example, a computer printout shows that ambulance A-14 was out of service 20 minutes after transporting a patient to the hospital. On the same shift, the ambulance was out of service for 22 minutes after a second emergency transportation.
A manager may be tempted to call the ambulance crew into his office, wave the computer printout in their faces, and demand an explanation. But, regardless of the data, it may be wrong to conclude that time is being wasted at the hospital.
Instead of instant confrontation, use the computer to do a little research. Does the crew in question have a longer average out of service time than other crews? Did the responses in question involve cardiopulmonary resuscitation (CPR) or possibly a contagious disease? Are there any other factors that could account for a delay?
Quick, punitive use of feedback data will generally result in “linelevel sabotage” of data collection. “Okay, if he wants his computer to show a quick in-service time, we’ll make it show a quick in-service time.” If employees perceive that they must manipulate data to make it look good, the whole feedback system becomes useless.
Computers are useful tools, but they can never be better than the managers who use them.
