Computerization is the implementation of a new hardware system and/or software application in a business organization. It is called first time computerization if the business does not have an existing data processing operation. In this case, the computer system replaces an existing manual system or implements a new business application. It is called upgrade computerization if the company already uses computers. This could involve the purchase of new computer hardware to replace existing hardware or to add a major new sub-system. It could also involve replacing an existing software system or adding a new software application to an in-place data processing operation. However, purchase of mere peripherals does not qualify as upgrade computerization.
Thirty years ago, only large companies could afford to computerize. The only computers available were mainframes that cost millions of dollars. Today, personal computers are the subject of TV advertising for home consumption and exist in countless homes and businesses. We are now in the information age. Even small business is finding that computers are necessary for survival.
What follows is a list of the computer applications used mostly by small business. The list is ordered in decreasing order of popularity.
- Accounts Payable
- General Ledger
- Financial Reporting
Small business is taking advantage of the price reduction in computer hardware. Personal computers known as PC's are very popular as are other types of microcomputers. Most personal computers allow only one person to use them at a time. These computers are classified as single user systems. Some microcomputers are multi-user systems. Single user systems can be joined together to form a multi-user network. However, this approach is more expensive than purchasing a multi-user computer directly.
Where microcomputers prove inadequate, small business turns to mini-computers. Almost all mini-computers are multi-user systems. Mini's are much more expensive than micro's, but they provide much more computing power.
In rare instances, small companies have turned to super-mini-computers. A super-mini is a network of interrelated mini-computers working together to produce extraordinary computer power. Many super-mini's also provide fault tolerant or non-stop processing. That is, should any component of the network fail, the remainder of the system would be able to compensate for it. Data processing would not be interrupted.
Mainframe computers are primarily used by small business for time-sharing. This is a mechanism whereby multiple users can purchase computer time and resources without having to invest in computer hardware. Usually, this begins inexpensively, but, as data processing activity increases, cost factors lead companies to consider purchasing their own computers.
Industry Organization
Once a company makes the decision to purchase a computer system, what happens next? Typically, what is the approach to such a purchase? In most cases, the buyer has a general idea of what is needed for the application. However, very little detail has been defined at that point. Where does the buyer go to get the type of sales help that he needs?
Very often, buyers go to their local computer store or to some advertised discount computer store. The sales people in these stores are not usually very knowledgeable. They "push" only the hardware that the store sells. This is also true within large computer companies. However, sales people who work for large manufacturers are usually better equipped to understand and deal with a buyer's problems. A computer store will sell the buyer a personal computer (or maybe several) and pre-packaged software that may or may not service the business. By dealing with a computer store, the buyer is normally responsible for hardware/software integration.
As an alternative to dealing with a retail outlet, a buyer can go to computer manufacturer sponsored OEM's, VAR's and VAD's. Traditionally, in technical industries, an OEM (Original Equipment Manufacturer) purchases many products at a discount and assembles these into a final single product to be sold in its new form. In the computer industry, an OEM deals directly with customers to provide turnkey systems. The customer buys the computer equipment from the OEM with all software necessary for required activities. Theoretically, an OEM provides custom software development while a VAR (Value Added Retailer) or VAD (Value Added Dealer) sells pre-packaged software. However, this distinction seems to have vanished. In any event, OEM's, VAR's and VAD's orient the small business customer toward the purchase of an integrated system. In this case, the seller is normally responsible for the hardware/software integration.
Another alternative is for the buyer to engage a knowledgeable computer consultant to assist in the decision making process for computerization. The consultant can also handle the details of implementation. In this instance, the consultant is not involved in the development of new software. The consultant helps to select from already existing hardware and software. Only where custom software development is deemed necessary does the consultant become involved in coordination of the development effort. This approach is highly desirable. Normally, the novice user cannot properly evaluate data processing merchandise with respect to quality or even fitness for use. In fact, there is an equivalence between a novice user computerizing without expert assistance and an individual defending himself in a major criminal trial without adequate legal representation. Although there is an additional expense involved in using an expert, this approach ultimately saves money. Using a consultant in this way represents an analgesic to the "headaches" caused by the details of computerization. The consultant normally assumes liability for actions in behalf of his client, thereby providing the buyer with additional recourse.
As a final alternative, the buyer contracts for custom software development. Usually, the company purchases standard computer hardware along with specialized software. However, in some instances, custom computer hardware must be developed. This approach should be avoided unless no other alternative exists. Where custom development proves absolutely necessary, the buyer should engage an independent expert throughout the entire development cycle to protect the buyer's business interests. This is true even where a vendor performs custom modification of standard "off-the-shelf" software.
Why Computerization Fails
Computerization is one of the most fearsome and potentially devastating activities in which a business can engage. Many small and medium sized companies do not survive it. At its very best, it is a nightmare that a sane individual wants to avoid. Except for trivial applications, computerization almost never runs smoothly. Most companies are unhappy with the results. Even when successful, scars remain.
Well, if it feels so bad, why do it? A business computerizes because it must have the information and control that only a computer can provide. As undesirable as it is, computerization is necessary.
Why does computerization fail? Often, many factors combine to make failure inevitable. In fact, most experts can accurately predict failure before the process has even begun.
Most vendors are honest and well intentioned. Most commercially available hardware is reliable and serviceable and meets performance specifications. Commercially available packaged software tends to perform better than custom developed software.
The software development cycle is so complex that many vendors inadvertently fail to perform and fail to meet contractual commitments. Occasionally, a vendor acts maliciously. However, a vendor's failure to perform is usually the result of vendor negligence. (There is no intention to apply a legal definition to the "negligence" concept. Simply, the vendor fails to take appropriate precautions. This practice is common among small companies.) Most often, there is a breakdown in communications between the vendor and the buyer. This breakdown often occurs upon initial contact.
In order to sell a "system", the vendor must somehow investigate fitness for use. In the case of a buyer purchasing hardware and software from a retail outlet, vendor involvement with fitness for use is minimal. Yet, even here, one finds numerous instances of customer dissatisfaction. To determine fitness for use, the vendor enters into the specification process. Here is the first vulnerable point. First, there is often a major difference between what a customer wants and what he says he wants. Often a vendor misunderstands what the customer says he needs. To deal with this problem, the customer should always require the submission of a document in which the vendor restates the customer's requirements in the vendor's own words. This document is called the Problem Specification.
Even when both parties understand what tasks the computer system must perform, how often does the following dispute arise? The customer claims that the computer software development has not been completed. It does not perform the way the customer expected. The vendor claims that the customer is constantly changing his mind about what has to be done. He adds new functions and frequently changes those already programmed. The vendor can no longer afford to continue development of the software. Communications between the parties break down, and all development activity ceases. This problem can be avoided by requiring the vendor to submit a document specifying how the software would operate from a user's point of view. This is called the Functional Specification. This document should include file layouts, screen layouts, report layouts and menus along with a description of how the system operates. This is not user documentation. However, the Functional Specification "casts" the computer system in "concrete". The Functional Specification must be part of the contract between the two parties. Once approved, changes therein amount to re-negotiation.
Problems With Multi-Vendor Acquisitions
"He did it! I'm not responsible!" says the first vendor.
"No, no! He's responsible!" claims the other.
We said earlier that a buyer should avoid multi-vendor acquisitions. Finger pointing done by vendors causes nothing but frustration for the user. Sometimes, one of them may be at fault. At other times, both may be at fault. Usually, the hardware vendor is much larger than the software vendor, and is in a position to exert pressure on the software vendor on the customer's behalf. However, hardware vendors often "sell" authorized software vendors on the features of their computer hardware and systems software. Suddenly, the software vendor finds that he cannot perform because the hardware lacks the require functionality.
One thing is certain. None of the parties are seeking legal problems. The customer wants his system to work, and the vendors want their customer to be satisfied.
The solution to the problem is simple. Contractually establish a single point of liability with the hardware vendor. From a technical viewpoint, he is in a better position to solve problems that may arise.
But, what if the hardware vendor refuses to accept systems responsibility? (If he recommended the software vendor, he may not be able to totally absolve himself.) Once again, under these circumstances, and independent expert should be employed. This may not prevent all potentially damaging occurrences, but it goes a long way toward achieving that goal.
Post Contract Procedure
The contract is signed. Development or implementation has begun.
A software development cycle (excluding user documentation) occurs in three phases:
Statistics have shown that the first phase (planning and analysis) takes one-third of the time, the second phase (coding) takes one-sixth of the time, and the third phase (testing) takes one-half of the time. This ratio is essential to a successful project. We see here very much emphasis on testing and very little emphasis on coding. When preparing schedules, most programmers, who have a good idea of how long it takes to code a program, rarely allow sufficient test time. Therefore, they produce "shoddy" software. "There's just a few more bugs, and then we're finished." It seems as if software remains ninety-percent complete forever.
In fact, it is impossible for a large software system to be completely "bug free". This may not necessarily prevent implementation. The operating system for one of the most popular mainframe computers was released with eleven-thousand known bugs. Nonetheless, removing this computer from the marketplace would have caused irreparable harm to customers. The key to success is functionality. The inability of the programmer to remove the "last" bug is unimportant if the user never encounters that bug. However, if insufficient test time is allotted during the development process, even this level of functionality will not be achieved.
Consequently, actual development time for software most often exceeds quoted development time by a large amount. If customers cannot accept this fact, most software development contracts result in preparation for litigation? How can this problem be avoided, or, at least, diminished?
The difficulty of estimating development time is greatly reduced by "breaking down" the entire project into small, separately solvable problems. The developer estimates the total project time as the sum of the times to complete each of the sub-tasks. In fact, the greater the number of sub-tasks (or project milestones), the higher the probability that the actual development time will be close to the estimated time. Each milestone must be able to be measured. For example, CODING - 90% COMPLETE is not a valid milestone. However, DELIVER CUSTOMER FILE INPUT ROUTINES is a measurable item. The keyword here is "control". If the time to complete a milestone slips, certain corrective action can be taken to insure that future milestones are completed on time. In the worst case, if the project end-dates cannot be met, the user is aware of it very early into the project. He can then make appropriate preparations. This is the way most large companies deal with their own in-house software development. Also, large companies usually employ "expert" project managers to control software development. While this does not insure that every project will be completed within an acceptable time frame, it does minimize schedule and cost overruns, and it does provide for a greater number of successfully completed projects.
Control is the name of the game. For each milestone, every effort must be made to insure on-time delivery, and the delivered sub-product must meet specifications. If this cannot be achieved for each sub-task, then the entire project will be unsuccessful.
Summary
We are now in the information age, and the time soon approaches when every individual and every business will use computers. Most children are now computer literate.
Each year, more and more companies computerize. Computerization is a very difficult process that almost never runs smoothly. Yet many difficulties can be reduced by customer awareness.
Whenever possible, standard "off the shelf" hardware and software should be used. Multi-vendor acquisitions should be avoided. When they cannot be avoided, a single point of system responsibility should be established. Custom development should be avoided. When it cannot be avoided, the buyer should engage an independent expert. (Use of an expert would help under any circumstance.) With custom software development, the buyer must insist upon the submission of problem and functional specifications. The buyer must also insist upon a delivery schedule of milestones consisting of as many project sub-tasks as can be devised. The entire project must be controlled.
Using these precautions, it is possible to minimize the problems associated with computerization, and to allow a business to reap the benefits of the information age.
