Dissertation for PhD Degree in Information Systems: Facilitating Technology Adaptation in a Small Company with Limited Resources

by David Barth, written in 1995

KW

Kennedy-Western University

Park Center Pointe

1459 Tyrell Lane

Boise, Idaho 83706

208/375-4542

800/635-2900

Fax: 208/375-5402

EXECUTIVE INDEPENDENT STUDY

FINAL PROJECT PROPOSAL
SECTION TWO

NAME: David V. Barth
Student I.D.# N11147

ADDRESS:

CITY: Lakewood

STATE: Colorado

POSTAL CODE: 80226-3047

COUNTRY: USA

TELEPHONE:

DEGREE: PhD

TITLE OF PROJECT: Facilitating Technology Adaptation in a Small Company with Limited Resources.

STATEMENT OF THE PROBLEM: A small company's increased business requires that it transition from a manual invoicing system to one that is automated. The issue is how to accomplish this with limited financial and personnel resources.

IMPORTANCE AND SIGNIFICANCE OF THE PROBLEM:

My topic is significant for many small companies who operate on manual systems, as did the one in this study, and who do not appreciate the benefits of a suitable computer system nor know the challenges of installing such a system.

SOURCE MATERIAL:

1. Fortune Magazine
2. Byte
3. Datamation
4. Compute
5. PC World
6. PC Today
7. PC Computing
8. Home PC
9. Information Week

My Final Project Proposal is hereby submitted.

__________________________________________

Student's Signature

__________________________________________

Date: June 1995

Chapter 1

INTRODUCTION

Statement of the Problem

Many small businesses barely survive because their overhead costs require a major portion of their gross income. In some cases, especially for start-up companies, the overhead costs may exceed the gross income during the early part of the company's existence. To survive, small companies have to carefully manage their expenses, keeping them as low as practicable while maintaining a sufficient level of customer service.

Solving the problem of expense reduction is usually an ongoing challenge for a company manager. He must think in terms of how to keep costs low without causing the company harm. The employee morale, including that of his own as well as his family's, must be maintained while, at the same time, the level of customer satisfaction must be kept at a sufficiently high level to maintain loyalty. Company creditors must be kept happy by paying them on time.

So, to keep a small company running smoothly, the manager must walk a tightrope, maintaining a balance between the level of customer support and the cost of running the operation.

This is not easy for most small business managers. The successful approach often requires innovative solutions and attention to detail. Often, business managers lack the required knowledge to implement modern solutions to solve their business problems, and they can neither afford to pay consultants to provide the necessary expertise, nor take the time to learn about them. Sometimes they do not know of the existence of a solution that is readily available.

Of all the hurdles that businesses must overcome, this study addresses the possibility of enhancing a company's information systems. Every business must maintain information systems. Examples include information used to satisfy customer's needs; data to support federal, state, and local tax requirements; bookkeeping records to track company performance; payroll information; accounts payable and receivable accounting; marketing information; competitive data; and inventory tracking.

The media used for information storage may vary between systems depending on their size, their importance to the operation of the company, how frequent the information is accessed, and the level of the manager's expertise. The two primary types of data storage for the small business are paper and the computer. Prior to 1981, before the advent of a reasonably priced computer, most small businesses had to rely solely upon paper-based systems such as accounting ledger sheets to maintain their information systems.

Larger companies have benefited from a wider spectrum of data storage media including large (mainframe) computers, mini-computers, networked computers, time-shared computer services, microfiche, microfilm, and various specialized equipment such as proof machines and tabulating equipment. These companies have also used manual paper systems and have embraced the small computer revolution as well.

Options for the small business are more limited than for larger, established organizations, and therein lies the problem of introducing automated information systems. Initially, a small business may start out with all of its data on paper or in the head of the manager. After operations have begun, that information is usually placed in a formal system to meet various needs, for example, payroll. At some time after the company has been established, automated data processing may be an attractive option to replace the manual information systems. It should be noted that not all information systems should be converted to a computer. Depending on the usefulness of information and the way it is used, it may properly and efficiently reside in the head of the manager or on paper in accounting ledgers. It doesn't make much sense to place the names and addresses of a handful of suppliers into a computer if that information can be more easily kept on a slip of paper. In the same way, if a company has but one or two employees, the payroll data may be most conveniently kept on a ledger than in a computer.

However, it is important for small businesses to be able to transition from manual, paper-based systems to a computer when the advantages of automating are compelling.

Concept of the Study
This study was conceived to investigate the possibility of empowering the employees of a small business to automate a manual system. The assumption is that there are many small businesses that could benefit by automating a manual system, and their employees are the most knowledgeable and best qualified persons to evaluate and implement a computer system to replace the manual system they have been using.

The benefits of converting a manual system could include fewer person-hours required to run the system, more complete information, more accurate data, and faster processing of required reports. The positive aspects of allowing company employees to implement the system themselves could be increased self-satisfaction derived from having control over the selection and implementation of the system, a sense of ownership in the system which could translate into a more proactive approach to solving its problems, higher morale as a result of having more input to the operations of the company, and money saved that ordinarily would have to be spent on consultants or the hiring of information system experts.

Better information could be provided by an automated system. An example is information provided by a manual pay system compared to that shown by an automated payroll system. A manual payroll system might provide some hand-written information regarding deductions from a pay check, but an automated system could give the employee a neater accounting of pay history including an accurate breakdown of all deductions, year-to-date totals, and, possibly, even a track of vacation and sick days used and available.

An example of cost reduction for the company would be increased efficiency found in running a system on a computer as opposed to doing it manually. The payroll system can serve as an example. If a manual payroll requires two hours per pay period of the manager's time, and an automated system cuts the time in half, a time savings results, freeing the manager to address other concerns.

This study was designed to choose one manual system in one example company to determine if the assumptions above are correct and find out if the process would be simple and straight-forward enough that it might be replicated by other small businesses.

Importance of the Study
By using the procedures developed herein as a guide, it should be possible for many small companies with limited financial resources and little computer hardware or software expertise, to achieve similar success in automating manual systems. For small businesses that continue to use manual systems which could be converted to a more efficient computer system, the results of this study may be a way to improve their operation by helping them become more profitable and achieve improved customer service.

The positive affect on a company's operation includes a reduction in manpower required to operate the application that is converted. This can translate to a reduction in overall expense to the company. If the result of automation is fewer man hours required to run the converted application, that relieves manpower for use in other areas that may benefit from extra help.

If the automated system provides more timely, more accurate, or better information for customers, then it can be a positive advance for the company's level of customer service.

This study provided some outside assistance to the subject company to prime its employees to undertake the project, but the approach was intended to be straight-forward and simplistic so that the results could be duplicated by other companies with a minimal effort. The intent was to develop a cookbook approach to computer system implementation.

Scope of the Study
The scope of this study considers the following areas, discussed in detail in chapter three, "Method."

1. The selection of a subject company that is appropriate for the study was made. Although this project involves only one company, it is hoped that the results will indicate some degree of applicability to many other small businesses.


2. The study of the company's existing manual information systems was made to be determine which one was a candidate for automating. If none had been found, a different company would have to have been selected for the study.


3. The selection of computer hardware to support the conversion and implementation was made prior to the selection of software because hardware is more generic than software. While software functionality and capability may be highly variable from product to product, hardware must adhere to rigid standards, and there are only two primary types: IBM (and IBM compatibles) and Apple. Although hardware selection was an important element for this company, businesses that already have a computer available will not require this step.


4. The selection of software to automate the application followed hardware selection. To keep the study as simple as possible, it addressed only off-the-shelf software, to be installed as written, and not modified or customized in any way. Although the way the application was implemented might be modified, the actual software itself could not because this study addresses how a small company can improve its information systems in an inexpensive way, and changing programs or writing new ones can be very costly.


5. After a candidate application software package had been identified, it was tested to determine if it operated in such a way to accomplish the company's needs for the application. The selection of software and the subsequent testing continued until a suitable package was found.
   
   Had no suitable computer package been found, a different application would have had to be identified for conversion, or another company would have to be selected for the study.


6. The selected software was then implemented under the direction of company employees. If this had been unsuccessful, the study would have had to be terminated with the results documented.


7. The impact of the new software on the company was reported, from positive and negative viewpoints.


8. The possible transference of the results of the study to other companies was addressed. Since the objective of the study was to determine if a small company could move from a manual system to a computer system, with resulting enhancements in performance and reductions in cost, the impact of the results on other small organizations was considered.


9. Finally, suggestions were made regarding possible future studies that would supplant this one by gathering data about the information system situation in other small companies.

Hardware Trends
The following discussions of hardware and software trends provide general background for the study.

Since the advent of Apple Computer's first production personal computer in the late 1970s, desk top computers have become less expensive and more powerful. The first IBM personal computer, introduced in 1981, had a CPU that operated at a clock speed of 4.7 MHZ (4.7 million hertz, or cycles per second). It cost $5,000. Today, computers running the CPU at 100 MHZ cost under $2,000.

The clock speed is the "ticks" or cycles that the CPU uses to perform whole or parts of instructions, measured in millions of cycles (hertz) per second. Simple instructions require only a few clock cycles. The higher the frequency at which the CPU operates, the more instructions that can be executed in a given period of time. However, there is a physical limit to the frequency that a CPU chip will operate in the current technology, just as there is a physical limit to the rpms that an automobile engine will turn. A racing engine might run at ten or twelve thousand RPM, but forget about fifty thousand.

Whether the CPU limit is 500 MHZ or 1 GHz (one gigahertz, or a billion cycles per second), technology will probably take a different approach to increasing computer processing speed. This approach will probably involve an increase in "parallelism," the method of using two or more logic circuits to execute two or more instructions simultaneously (Coffee, 1994). If it sounds complicated to imagine a program running, wherein two instructions are being done at the same time by the CPU, it is. The logic of the computer must somehow look ahead in the program and determine what instructions can be done at the same time, then set them up so when it comes time to execute them, they are ready. The Intel Pentium chip does this on a small scale, but the future will bring great advances in this area.

Theoretically, if enough CPUs were ganged together, say, one CPU for each instruction in the program, and the instructions of a program were set up, ready for the CPU to execute them, a program could run in just a few clock cycles, or in a 100 MHZ computer, it would be finished in only five or ten millionths of a second. This is only an illustrative example. The attempt to bring many processors together to perform faster processing was done long ago, in the mid-1970s when the University of Illinois, under a government contract, connected 64 Burroughs computers together to run in parallel, ostensibly, to run programs that were to compute one of the most complex applications: weather modeling.

The PC owes its existence to one technological advance: Large Scale Integration (LSI), which is the ability to mass produce small silicon chips, ranging in size from that of a fingernail to those larger than an Oreo cookie, containing thousands or millions of transistors. The first commercially produced chips were designed to take the place of thousands of transistors that constitute the CPU in a computer. (See "Hardware Historical Perspectives" in Chapter 2).

The CPU is the section of the computer that consists of many transistors, and reducing the logic components to a small size facilitated the development of the first PCS. The magnitude of this compression could be illustrated by imagining thousands of separate transistors, each the size of the eraser on the end of a pencil, distributed across two hundred circuit boards fitted into slots in a computer cabinet. The whole CPU assembly might require twenty or thirty cubic feet of space. In addition, each board had to be connected to others by many wires. This is the configuration that 1960s vintage mainframe computers used, and each computer was nearly hand-built, and the manufacture of boards was largely done by hand on production lines staffed by assemblers. The construction of just one mainframe computer might require many weeks. The resulting cost of such a computer was in the millions of dollars.

Not only has the CPU circuitry been compressed into chip form, other logic circuits in the computer have also been redesigned into chips, so that most transistors in current PCS reside inside either the CPU or some other chip. These non-CPU chips are usually smaller than the CPU. Chips will be found on the main board, as the CPU is, on controller boards that plug into the main board, and on various hardware components themselves, such as hard disk drives, floppy drives, CD ROM (compact disk, read only memory) drives, and other components.

The original chip design used metal connectors protruding that looked like legs, giving them the look of short centipedes. The metal "legs" fit into small sockets mounted on the board by pressing the chip down into the socket. The advantage of this approach was that the chips could be easily pulled out and replaced. This advantage was particularly important in the days when even non-CPU chips were expensive, sometimes costing hundreds of dollars, and their reliability was not what it is today.

In the mid 1980s, the chip mounting technology changed to "surface mounting." The surface mount chips are flatter, usually square, and their legs are small wires that come out all four edges of the chip. The chip is mounted flat on the board with the wires soldered to the appropriate junctions on the circuit board. Surface mounting technology lends itself to automation, and most boards are mass produced on robotic assembly lines.

As a result of mass production feeding an ever growing market, instead of a production run of a few thousand circuit boards in the early 1980s, now, many boards have runs of several million. The impact of these large runs is that, although the first board to come off the assembly line may cost many millions of dollars, the average board price for the entire run puts the price in the tens of dollars, effectively making the board disposable.

No longer do computer technicians repair a circuit board at the component or chip level. They go only to the board level, simply throwing away a board that tests bad, even if it is a main board. It is less expensive to replace a board than spend money on parts and labor to try to repair it. In addition, the new board will have a new warranty and all new parts, a situation that one would not have with a repaired board.

The future of the personal computer has been discussed by computer experts for years. When IBM designed the first PC, it only allowed for one million bytes (characters) of addressable memory. This was done for marketing reasons. IBM's marketing philosophy in mainframe computers extended to their PC. More powerful and more expensive lines were planned, but clone makers jumped into the market, developing "work-arounds" for the deficiencies of the PC, increasing the allowable memory to 64 MB or more. The first PC had standard memory of 64 KB, expandable up to 640 KB of user memory, and, with control memory, the total was 1 MB.

PC memory, as with most computer memory in mainframe and minicomputers, loses the data stored when the power is cut off. Computer memory exists only by virtue of the power supplied to it. Technology is attempting to find a way for data to be retained in a memory chip when the power is cut off. This advance will cause a giant leap in computer operating speed, because it will open the door to replacing the relatively slow hard drive with much faster memory. Imagine removing the mechanical hard drive that contains spinning disks, and replacing it with a block of memory that has no moving parts and operates hundreds of times faster than the hard drive.

The first PC didn't have a hard drive for storing data. Data was stored only on floppy drives. The "extended technology" XT was simply a PC with a hard drive added to it. Early hard drives could hold only 5 MB and they cost more than $1,000. Large modern hard drives have a capacity exceeding two GB (gigabytes, two billion characters), and the cost is around fifty cents per megabyte, or around $500 per GB.

The trend in main board size is to continue combining and shrinking components so that main boards are becoming smaller. In addition, add-on boards that plug into the main board are shrinking, too, and some add-on boards are being built with multiple functions such as combining hard drive, floppy drive, and CD ROM drive electronics on one add-on controller board.

This down-sizing has paved the way for the lap top computer. Lap top computers are the future. They will not be able to compete with desk top PCS until they can do several additional things:

1. Lap tops need a fold-out, full-size keyboard. Keys can get smaller and more densely arranged on a keyboard, but fingers cannot get smaller to accommodate them. Lap tops usually have a plug so that a full-size keyboard may be attached, but that is a poor solution. The need is for a big keyboard that folds up.


2. Lap tops need to have at least eight slots available to plug in various add-on cards, just like desk tops have. The PCMCIA card (the latest model is called "CardBus") technology uses credit card-sized add-on boards, but these have not been well developed yet, and there aren't enough types available (Seymour, 1994). This technology is improving, however. Examples of add-on cards that are available for desk top PCS that should be available for lap tops are sound cards, CD ROM cards, fax/modem cards, video cards, drive controller cards, etc.


3. The monitor situation with lap tops has always been a problem. The most expensive lap tops costing more than $4,000 have good color monitors. A standard monitor can be plugged into most laptops, but, like plugging in a full-size keyboard, that is a poor solution. The best solution would be a folding monitor that could present a large viewing area.


4. Lap tops need to have commonality of peripherals so that a hard drive, floppy drive, or CD ROM drive can be purchased from any computer store and slipped into the unit, much as is done with desk top computers today.

As for the desk top PC, monitor technology is moving toward flat screens, similar to those used in lap tops. Cost is holding them back, but some day, the heavy, power-hungry, bulky monitor will be replaced by a thin, lightweight, large monitor that looks like a picture and can sit on the desk or hang on the wall.

The physical size of the desk top computer will shrink, too. Originally, diskette drives used eight-inch diskettes. Then came the 5 1/4 inch diskette drives, and the current standard is the 3.5 inch diskette drive. Consumers seem to do funny things at times, but there is always logic behind their actions. For example, the two-inch diskette drive was introduced several years ago, but it never became popular. The reason is that it is so much like the 3.5 inch drive, only a bit smaller. The change from the 5 1/4 inch drive to the 3.5, was much more significant. The 5 1/4 diskette is flexible and easily damaged. The improvement in the 3.5 inch diskette is that it is encased in a hard plastic case and is small enough to slip into a shirt or pants pocket without worry of damaging it. The advent of the 2 inch floppy was no great improvement over the 3.5 inch model because it was simply smaller, without any other great advances. So, the 2 inch drive has not become common.

Multimedia computers are now the rage. They are the same as any other PC except that they have a CD ROM drive, a sound card, and a pair of external speakers. PCS have an internal speaker built in to the case, but it is small and does not provide high-quality sound.

The CD ROM drive came about as an off-shoot of the music compact disks where the data was stored in very high density, in digital form, on disks that are not easily damaged.

Computer manufacturers began building CD ROM drives that could use the CD technology. Instead of storing music on the disks, computer manufacturers digitally store data such as encyclopedias, text from books, educational information accompanied by video pictures and speech and music, some of which are animated, and groups of programs that, otherwise, would require storage on dozens of diskettes. Many CD ROM drives will play audio compact disks, and the latest models are compatible with the photographic compact disk technology that Kodak has developed.

The future will bring more compact, faster CD ROM drives and the ability to write and delete, just as can be done with diskettes. Eventually, CD ROM disks will replace diskettes. They will come in the current size and a smaller size, both compatible with the same drive unit, and they will have read and write capability.

The advantage of CD ROM is its great capacity. CD ROM disks currently hold around 650 MB of data compared to a maximum of 1.2 MB for 5 1/4 inch floppy and 1.44 MB on a 3.5 inch diskette. Future technology will provide at least one smaller size of CD ROM, and higher density storage is probably coming soon.

As for a major philosophical design change, that is probably not likely within the next ten years. When IBM came out with the original PC, it planned to bring out newer technology computers to follow it, if their marketing strategy in the mainframe world is any guide. However, there is always a conflict between new hardware architecture and the software that has been running on the old architecture machines. For IBM, that was never a consideration. IBM was big enough to simply change the hardware and let the software houses convert their old software to fit the new computer. When the clone makers entered the market in the mid-1980s, a power shift occurred. IBM was no longer the dominant force in the PC industry. Software to run on the open architecture IBM computer was easy to write because IBM had made the internal logic operation public so that a plentiful supply of software would become available for IBM computers, making them more desirable. This ploy backfired when the IBM compatible manufacturers jumped into the market.

There are many small companies and few larger ones, like Compaq and Packard Bell, manufacturing IBM compatibles. However, no one manufacturer has the power to introduce a new architecture that would require the software makers to redo their programs to run on it.

The hardware makers have simply taken the old 1981 PC technology and produced faster, higher capacity computers, using work-arounds to address architectural shortcomings like the above-mentioned 1 MB limit. There are newer technology computers, called workstations, that use RISC (reduced instruction set) technology, made by Sun, Hewlett Packard, IBM, and others, that won't run PC software. These computers are much more powerful than any PC in use today, but they cost five to ten times as much, and the fact that they won't run popular software has left the public uninterested in them. These workstations are in use by companies and computer centers that need a lot of computer power for a network of computers. They are sometimes used as terminals for mainframe computers. So, RISC workstations have a place, but for now, it isn't with the general public because it desires computers that will run the many thousands of software programs on the market. (Coffee, 1994).

The only thing the hardware manufacturers have been able to do is to continue increasing the power of the PC. It is possible its power will eventually supersede that of the RISC workstations. Prices continue to plummet as the cost of compute power halves every eighteen months (Spears, 1995).

Software Trends
With the future of IBM compatible technology expected to remain unchanged for the foreseeable future, the software houses are continuing to turn out software for PCS. There are changes in the overall "look and feel," however.

When Microsoft introduced Windows to compete with the graphical user interface (GUI) that Apple had pioneered, many computers were too slow or lacked sufficient capacity to run it well. Many computer programs designed to operate with Windows ran slowly. Users who wanted a speedy program often chose standard "DOS" programs that ran with the DOS operating system instead of with Windows. (See "Software Historical Perspectives" in Chapter 2).

This situation was simply that software development had gotten ahead of computer power, and it helped spur the demand for more powerful computers. Most users like Windows because it provides a standardized way that programs interface to the user. The "look and feel" that Windows programs provide, enables users to more quickly use Windows programs because they work in a similar way to other programs that run under Windows.

Before the development of Windows, all programs ran under DOS, and most were "text-based" in that they interfaced with the computer user through statements or questions printed on the screen. With Windows, however, programs communicate with small "windows" that pop onto the screen to guide the user when it is necessary to obtain some input. The use of these small "windows" is where Windows got its name.

Windows and the programs that run with it use graphics instead of lines of text. The colorful graphics are often little pictures of functions that can be accomplished by the user, and other pictures like slide switches for adjusting mouse sensitivity, for example, radio buttons that resemble push buttons on a car radio, and other graphical devices that help the user understand the application better.

Some software houses have elected to develop their software for DOS, and in doing so, provide some graphical pictures and little windows in the DOS environment. The trend is for DOS programs to be written for Windows because more users are running other applications in Windows. Some software is available in two versions: one for DOS and one for Windows.

Another trend is larger programs and more of them within an application. For example, Novell WordPerfect 6.1 for Windows requires 32 MB to be available on a user's hard drive before it can be installed. With DOS and Windows requiring close to 30 MB, the need for larger hard drives is obvious. No longer can a user that has DOS and Windows get by with a 40 MB hard drive if he wants to run many software programs. His hard drive will simply run out of space. This is causing an increase in demand for larger hard drives, and prices for them are currently less than fifty cents per MB, and likely to fall as more of them reach the market.

Software prices are dropping as competition heats up between software providers. There are a limited number of types of business applications, but more come on the market each year.

Larger software packages are now coming out on a single CD ROM disk instead of several 3.5 inch floppy diskettes. This makes it much easier to load large programs because one CD ROM disk may be loaded instead of having to load and unload many floppies.

Commercial Software houses are beginning to compete with each other by offering lower prices for "competitive versions" and "upgrade" versions. Often the same program is used for both the competitive version and the upgrade version. The way this marketing approach works is that a person who uses an older version of the new product or is using some other vendor's software, can purchase the upgrade version for a lower price than the buyer who isn't using an old version of the same product or a competitor's software.

With the introduction of computer viruses in the mid-1980s, software houses changed their approach to packaging. Now, all software comes out of the factory shrink-wrapped to attempt to foil persons who might be tempted to introduce an infected diskette into a commercial software package.

Software that is provided on CD ROM drives is not susceptible to tampering because it is read-only, and cannot be written upon. It isn't possible to add a virus to a CD ROM disk. However, it is possible to create a new CD ROM disk, copying the programs from the original disk along with the virus, but the effort and cost to accomplish that task would seem to reduce the probability of someone attempting it.

Software viruses are still a worry for the computer user. The vulnerability increases when the user downloads software from a bulletin board or loads a floppy diskette that is not an original, but a copy of an original diskette. In these circumstances, it is possible that someone may have infected the program with a virus that can cause the machine to act strangely, or, at worst, render it inoperable until a technician eradicates the virus.

Most shareware vendors, bulletin board operators, and commercial software houses run virus checks on all software before allowing it to be distributed. Windows and Norton Utilities now come with a virus check program that alerts the user if a virus is found. There are also companies that specialize in virus protection and removal.

The trend toward larger software packages is driving the power of computers. As software developers add more functions to their packages, users are forced to upgrade or acquire a more powerful computer.

Games are some of the fastest growing software packages. They have gone from text-based, monochrome software to those featuring color, sound, full-motion graphics with 360 degree viewing capability. This trend continues as new games are coming out with three-dimensional graphics displayed through a head-mounted viewing device.

Eventually, virtual reality will provide the capability for a user to simulate a realistic impression of a far away or imaginary locale by software that requires a very powerful computer.

Definition of Terms
The following terms have been defined to attempt to reduce obfuscation common in technical discussions, particularly those in information systems. An effort was made to present all computer-specific terms used in this study as well as some that might be useful to the reader.

To keep the flow of the text smooth, the traditional masculine form is used throughout, but it is intended to pertain to both sexes.

Adapter Card. An auxiliary logic board that plugs into the main board of a computer. Also referred to as "Add-on Board" (Sachs, 1984). (See Main Board).

Application. A specific information system, be it manual or computerized, that performs a function. Examples of business applications are Invoicing, Accounts Payable, Accounts Receivable, General Ledger, Fixed Assets, and Inventory.

Assembly Language. Also known as "Assemblers." A language used by a computer programmer to create instructions for a computer to operate. Assembly languages are manufacturer-specific and cannot be used on another manufacturer's computer. Assemblers are a higher level language than machine language because they use mnemonic symbols (ADD A, 9) instead of binary codes (1011100000001001). Also, one assembler statement may generate many machine language statements.

Assembler languages have been superseded by higher level, more productive languages such as compilers which allow the programmer to write fewer instructions. Although used little at the present, the advantage that assemblers have over compilers is that programmers can use them to eliminate non-essential instructions that compilers sometimes generate, speeding up the operation of a computer for critical applications such as those used in airline reservation systems where thousands of transactions are processed each second.

In the hierarchy of languages, assemblers fit between machine languages and compilers (Claus & Schwill, 1992). (See Machine Language and Compiler).

AT. A computer designation that represents "advanced technology." (See XT and PC).

Byte. The storage space required in a computer to hold one character of information. For example, "A," "1," "%," "$," and "q" each require one byte of storage. (See KB, MB, GB).

CPU. Central Processing Unit: the "brain" of the computer that controls all operations. Until the development of the first large scale integrated circuits, called "chips," consisting of thousands of transistors, the central processing unit consisted of individual components (Claus & Schwill 1992).

Until 1958, these components were vacuum tubes (Forkner & McLeod, 1973). Between 1958 and 1975, thousands of individual transistors were assembled on many plastic boards, sometimes numbering in the hundreds, to make up the CPU. This architecture was very expensive to produce, requiring a large computer unit with a lot of wiring between the boards, prohibiting most individuals from owning a computer.

In the mid-1970s, engineers developed a way of putting thousands of transistors into a "chip" slightly smaller than a package of Lifesavers. Advances in technology have resulted in the Pentium CPU chip containing ten million transistors.

CD ROM. This is an acronym for "compact disk, read-only memory." It is the computer version or the music variety of compact disks except that data is stored on the disk which has a capacity of 650 MB. CD ROM disks require a CD ROM drive. Many new CD ROM disks are being introduced because this technology is the core of "multi-media" computers. (See Multi-media).

Clone. (See Compatible).

Commercial Software. This software consists of one or more computer programs that are copyrighted and sold through retail outlets instead of being distributed free of charge as are shareware programs. Unlike shareware, commercial software cannot legally be copied and redistributed by anyone except the manufacturer and its licensees. Some commercial software is copy-protected to thwart unauthorized distribution of the product.

Stringent laws protect the copyrights of commercial software houses just as they protect authors of works written in other media such as books (Stagner, 1988). (See Giftware, Public Domain Software, and Shareware).

Compatible. A computer that operates like a computer built by an original manufacturer (e.g. IBM or Apple). That means it will operate like the original computer and will run the same software. For example, there are IBM compatibles and Apple compatibles. The term "compatible" generally refers to IBM compatibles.

In the early to mid-1980s when true IBM Personal Computers were in short supply, IBM compatibles came on the market to satisfy the demand (Dodge, 1994).

Packard Bell and Compaq are companies who manufacture name-brand computers that are compatible with IBM personal computers. Many foreign manufacturers, particularly in Asia, build generic IBM compatibles that may not even have a name plate on them.

In the mainframe computer environment, Amdahl manufactures compatibles for large scale IBM computers. This term can also apply to computer peripherals that are compatible with an original manufacturer's equipment such as printers and disk drives (Claus & Schwill, 1992).

Compiler. A high-level computer language used by programmers to write computer programs. Compilers are generally platform independent in that they can usually be run on computers of a variety of manufacturers. Examples are Cobol, Fortran, C++, Basic, Pascal, and newer, highly developed compilers called Fourth Generation Languages (4GL).

Each compiler statement generates many machine language instructions. In the hierarchy of languages, compilers rank at the top of the list, above assemblers and machine language. Compilers allow the programmer to write fewer instructions because they are able to generate the necessary machine language instructions from one compiler instruction (Claus & Schwill, 1992). (See Machine Language and Assembler Language).

Context Sensitive. This usually applies to help information or documentation that is specific to the location in the program where additional information was requested. For example, if a person is entering a date into a field in an input screen and wishes to know what the format of the date should be, if the program can provide context sensitive information, a request for additional help can show the format in which the date should be entered.

Cybernetics. The broad meaning refers to the study of systems: organic and man-made. In data processing circles it means the study of computers (Claus & Schwill, 1992).

Database. A group of files that may have some common fields between them for reference purposes. For example, a customer file may have links to an inventory file so that each customer record is not required to hold repetitive inventory information such as the description of the item.

To go a bit farther, a customer record may have inventory part numbers that refer to parts in the inventory file. If a person desires to list the customers and a complete description of the inventory ordered during the past month, he may simply instruct the Database to print the customer information, then take each part number on the customer's record and print the associated inventory descriptions. In this way, duplication of information is reduced because each customer record does not need to carry a duplicate of the full description of each inventory item ordered, only the part numbers.

A Database program usually provides a variety of ways of selecting and sorting records to be displayed or printed (Claus & Schwill, 1992).

Disk Drive. (See Floppy Drive and Hard Drive).

Floppy Drive. A mechanical device that reads and writes information to a removable floppy diskette by spinning it next to sensitive read/write heads that transfer information between the computer and the diskette. Two drive sizes are common: 5 1/4 inches and 3.5 inches. Maximum capacity varies according to the type of drive, with capacities at 1.2 MB for 5 1/4 inch drives and 1.44 MB for 3.5 inch drives. Drives are usually capable of reading and writing diskettes with a lower capacity, but not those with a capacity higher than the capacity at which the drive is rated (Connell, 1987).

Freeware. (See Shareware).

GB. This is the abbreviation for gigabyte, or billion bytes. (See KB, MB, and BYTE).

Giftware. Giftware is the term for free sample demonstration software that has one or more features removed compared to the full-featured commercial version. Duplication and distribution are authorized. Giftware is usually accompanied by an offer to purchase the complete commercial software package (Stagner, 1988).

Graphical User Interface. Abbreviated "GUI" (pronounced "gooey"), it is a means of showing program options on a computer terminal screen as pictures (icons) that may be selected using a pointing devices such as a mouse. (See Icon).

GUI. (See Graphical User Interface).

Hard Drive. A mechanical device that is sealed, typically containing one or more non-removable disks inside. Similar in concept to a floppy drive, a hard drive uses read/write heads to transfer information between the computer and the drive. Hard drive capacities vary with the number of internal disks (sometimes called "platters"), the density at which data is written on them, and whether both sides of the disks are used. Current capacities vary from 40 MB to more than 4 GB (gigabytes or billion bytes) (Glass, 1991). (See Byte, KB, MB, and GB).

Hardware. This is the computer "machinery" that runs the software programs. It includes the computer and any peripherals connected to it such as a printer (Claus & Schwill, 1992). (See Software and Peripherals).

IBM Compatible. (See Compatible).

IS. This is the common abbreviation for "Information Systems," which often refers to the department in a large company charged with managing and supporting its computer and information assets.

Icon. A picture that represents a program function used to select the activity by clicking a pointer such as that provided by a mouse or track ball. Icons are usually associated with graphical user interfaces (GUI) that attempt to make a program easier to use by presenting options with the use of pictures (Glass, 1991). (See Graphical User Interface).

IDE. This is the abbreviation for "integrated drive electronics." It is the most common technology for hard drives and provides much of the control circuitry to be mounted on the hard drive itself instead of having all of it mounted on the controller board as it was in older technology. (See Hard Drive).

Information System. This is a generic noun referring to any system, manual or computerized, that is used to process an application or provide information. "Information system" is sometimes used interchangeably with "application" and "software." (See Application and Software) (Claus & Schwill, 1992).

KB. This is the abbreviation for kilobyte, or thousand bytes. (See MB, GB, and Byte).

LAN. (See Local Area Network).

Local Area Network (LAN). A physical connection between two or more computers located near each other, one of which acts a server or host (a "master" personal computer that is more powerful and possesses enough memory and disk storage capacity to meet the needs of the network). The server contains the files used by all of the computers on the LAN so that each computer won't be updating independent files that will have to be merged later to create a master file. A LAN is applicable where several users need to operate a single software system at the same time, using different computers. LAN hardware consists of an adapter card that fits into each computer, the wire that connects all of the adapter cards, and the software to operate it. (See Server).

Machine Language. A language written in binary code, used directly by a computer to execute instructions such as "move" and "add." Consisting of strings of ones and zeros, these instructions are the lowest level instruction type because the computer executes them directly.

Higher level languages, assemblers and compilers, allow for greater programmer productivity because the assembler or compiler generates many machine language instructions for each instruction written by the programmer. For example, the single compiler statement written by a programmer, "Write Record to Disk," might result in the compiler generating ten or more machine language statements to accomplish the task of writing a record. A compiler statement is written using more meaningful codes such as "ADD" or "MOVE."

Machine languages are manufacturer-specific and cannot be used by another manufacturer's computer (Claus & Schwill, 1992). (See Assembler Language and Compiler).

Main Board. The primary circuit board in a computer into which adapter boards plug. The main board is often called "mother board." It usually contains the primary computer logic, control circuits, CPU, and memory. (See CPU and Adapter Card).

Mainframe Computer. The largest, most powerful type of computer. Originally created in the 1940s, as miniaturization improved, it was joined by the minicomputer in the late 1960s and the personal computer in the late 1970s. (See Personal Computer and Minicomputer).

MB. This is the abbreviation for Megabyte, or million bytes. A byte represents one character (Connell, 1987). (See KB, GB, and Byte).

Memory. Typically, temporary storage in a computer. Random access storage (RAM) loses its data when the power is removed. It is the fastest means of storing and retrieving information, and program instructions may be executed from memory (Claus & Schwill, 1992).

Microcomputer. (See Personal Computer).

Minicomputer. Smaller and, in general, less powerful than a mainframe computer, it became feasible as a result of efforts in computer component miniaturization during the late 1960s. In the hierarchy of computer size, minicomputers are between mainframes and personal computers. (See Mainframe and Personal Computer).

Mother Board. (See Main Board).

Multi-media. Typically, a computer that has a CD ROM drive, a sound card, and speakers. The CD ROM titles that fall into the category of multi-media often display pictures, sound, or moving picture clips with or without sound. The term "multi-media" refers to the ability of a computer to show motion pictures, still photographs, and sound, as well as text. (See CD ROM).

NCR forms. "No Carbon Required" multi-part forms that are designed to cause an image formed by pressure on the front form to be duplicated through subsequent forms.

Network. (See LAN).

PC. A computer designation that represents "personal computer." It is a generic term as well as the model of the first IBM computer introduced in 1981 (Connell, 1987). (See AT, XT, and Personal Computer).

Peripherals. Strictly speaking, any computer component used as an input device or output device, including keyboard, monitor, hard drive, floppy drives, pointing device (mouse, track ball, joy stick, light pen), printer, CD ROM drive, speakers, and scanner, to name most of the popular peripherals (Claus & Schwill, 1992).

Personal Computer. Personal computers became feasible in the mid 1970s, when technology was advanced to the stage that the "brain" of the computer, the central processing unit (CPU), consisting of thousands of transistors, could be combined into a single unit. The unit became known as a CPU "chip," and current models are about the size of an Oreo cookie. This giant step in miniaturization allowed for the computer's logic assembly to be sized to fit on a plastic sheet or "board" slightly larger than a foot square.

This advance meant that a low-powered computer, built around this small main board (also called "mother" board), could fit into a small cabinet that could sit on a desk. The CPU chip, model number 8086 (and subsequently, the 8088), was developed by a small organization that became Intel, the world's largest CPU chip manufacturer. This development, alone, made the personal computer possible. As had been done with the CPU, other logic circuits were converted to chips (Claus & Schwill, 1992). (See CPU and Main Board).

Pixel. Modified abbreviation for "picture element." A pixel is a dot on a computer monitor screen. The definition that a screen can provide is determined, in part, by the density of the dots. Current technology provides the highest definition of .26 mm. The average monitor has .28 mm between dots (Claus & Schwill, 1992).

Program. A group of computer language instructions that accomplish one or more tasks. Programs vary in size from a few instructions to many thousands. Programs may be grouped together to form a system, although the following terms are often used interchangeably: program, system, package, and application. These terms may be preceded by the word "software" (Claus & Schwill, 1992). (See Application and System).

Public Domain Software. The author of this software has released the copyright for it. Copying and distributing it are allowed. Any costs involved are to cover the copying, shipping, and handling, not the software itself (Stagner, 1988). (See Shareware, Commercial Software, and Giftware).

RAM. Acronym for "random access memory" that is the primary memory in a computer. Typically, it loses its storage ability when power is removed (the computer is turned off). Computer programs are executed from RAM (Claus & Schwill, 1992). (See Memory).

Server. A "master" computer that forms the central part of a Local Area Network (LAN). Because the files used by the other computers on the LAN reside on the server, it must possess enough speed and capacity to send, receive, and process data between it and the other computers on the LAN. (See LAN).

Servomotor. The main component of an analog computer. Properly "ganged" together, servomotors can do the two basic arithmetic functions of a digital computer: addition and subtraction. (In both analog and digital computers, multiplication is simply a function of many additions and division is accomplished through many subtractions.)

Analog computers are now used only in very specific applications requiring their specialized capabilities. They have lost desirability as general purpose computers because, unlike digital computers, they are less accurate, require periodic alignment, are prone to mechanical failure, are bulky and heavy, and require much more energy to operate, given the same assignment.

Shareware. "Free" programs, usually written by individuals or small groups who request a voluntary payment if the user decides to use the software. Sometimes incorrectly called "Freeware," shareware exists because of the monetary support provided by users to developers.

Some shareware programs are a sample of the full-function commercial software package that may be purchased from the shareware vendor. Less than fully-functional shareware is sometimes irreverently referred to as "crippleware." Most shareware is fully functional. The authors encourage duplication of the software and rely on the honesty of the user to forward payment, which typically ranges from $10 to $50, if he elects to use the product.

Shareware provides the user a chance to try out programs for a small fee of a few dollars to cover copying and distribution costs (Stagner, 1988). (See Commercial Software, Public Domain Software, and Giftware).

Software. A generic term that is applies to computer programs, systems, packages, and applications. The word "software" often precedes these terms. These terms are often used interchangeably to refer to the computer instructions that enable the computer to accomplish tasks (Claus & Schwill, 1992). (See Shareware, Public Domain Software, Giftware, Commercial Software, Program, System, and Application).

Transistor. Developed in the late 1950s, the transistor replaced the vacuum tube in digital computers and became the primary basic unit in computers, heralding the second generation in cybernetics (Forkner & McLeod, 1973). Originally, transistors were mounted singly on computer boards, but technology eventually enabled them to be grouped together in a single block of silicon, forming a large scale integrated (LSI) unit or "chip" (Bentley, 1984). (See Personal Computer and CPU).

Vacuum Tube. Vacuum tubes were predecessors to transistors in digital computers. They look like large light bulbs and can achieve the two states required by digital computer logic circuits: "on" and "off."

Computers built using vacuum tubes required a large room, had thousands of them, required massive air conditioners to keep the components cool, and needed constant attention to replace them when they burned out (Forkner & McLeod 1973). (See Transistor and CPU).

Virus. Instructions deliberately inserted into a program to make the computer act strangely or disable it altogether.

XT. A computer designation that represents "extended technology." The XT was introduced in 1985 and is now obsolete. (See AT and PC).

Chapter 2

REVIEW OF RELATED LITERATURE

Introduction
The literature survey concentrated on approaches to implement a computer system and associated software. The writings of primary interest related to smaller companies and the potential problems they face. Additional topics that gained attention included involvement of users in implementation efforts and the relationship between project success and their taking ownership in the system.

After it was determined that there was a manual system in the company that could be converted to a computer system, the hardware and software aspects were considered. Historical perspectives that have made computing power available to small businesses were researched to add background to the study. A logical extension of the historical look was reviewing prognostications of near-term advances, important in order to make a good decision on the type of hardware and software to acquire.

Attention was paid to sources of computer definitions to provide documentation of some of the common technical terms related to the study. Although technical terms are used in this text, an attempt has been made to make the meaning of the ideas understood in the context of the discussion. The inclusion of a broad scope of technical definitions is provided as an aid to readers who might benefit from a ready reference of terms related to the subject of the study.

Personnel Considerations
In an article in PC Week entitled, "Don't Underestimate the PC Kitchen Cabinet," the author says the general attitude of information systems (IS) managers is changing in regard to users of personal computers. In the early days of small computers, corporate users of PCs were nearly ignored by their information system departments. The current trend is to invite them to join the software selection team (Seymour, 1992).

Seymour recommends that the software selection group resemble the "kitchen cabinet" of friends and advisors whom President Jackson brought together informally in 1829 to work on problems and discuss ideas. He says users are the most knowledgeable about the software they need to do their jobs. They can provide a means of building consensus within the company. Instead of the selection process taking place wholly within the IS department, by bringing in users, the process is opened to the mainstream of the company, providing a more open forum and resulting in a better choice of software.

By bringing users into the process, they become engaged in the purchase, testing, implementation, and support of the system. They receive a sense of importance and they become the eyes and ears of management as well as its voice for the merits of it (Seymour, 1992).

In his book, Office Automation: The Productivity Challenge, Chorafas (1982) has a section addressing "The Cultural Perspective." He contends that with sufficient attention to the personnel factor, a conversion from a manual to an automated system does not have to be traumatic and that reducing resistance by the user staff is very critical if the software is to be accepted by the establishment. The truth of this assertion is paramount for this study.

Richard Sharland (1991) writes that users should be involved during all aspects of requirements definition. Their association with the development of the framework of the new system will provide the company with specific needs to be met by the new system. Another objective is that the users will begin to take ownership of the system as it is designed and built.

A key observation that Shamlin makes is the importance of user involvement in the selection, acquisition, testing, and implementation process. She says that if they are involved, workers begin to take ownership of the software early and help insure its success. Her view on user involvement agrees with Chorafas' (1982) view which supports the need for user involvement in bringing a new software package to a small company.

A contrasting viewpoint presented in "Management evaluation of software packages" (1985) (no author listed) is that users need not take part in the selection, evaluation, or development of software packages. Instead, users should be trained to accept and use the new package. This book observes that, initially, some employees will accept the new software and some will not. It asserts that one of the primary objectives of the training is to answer employee concerns regarding the new package so they will accept it.

This view is of interest because it highlights the difference between information system facilities in large companies to those in small companies. In the era prior to the advent of small, inexpensive computers, mainframe computers were the common means of accomplishing automation within a company. Typically, users were not involved in all aspects of designing, implementing, or testing a software package. Instead, that was the role of the information systems department. If any users did not readily accept the new package following its implementation, and training was not successful in changing their attitude, then they were either made to work with the new package, or they were transferred to another area within the company, they were terminated.

A major assertion of this study is that due to limited manpower and financial resources, a small company must involve the users from the beginning of a project through the final implementation to try to guarantee success. This is in contrast to the approach proposed in "Management Evaluation of Software Packages," discussed above. Such a philosophy may work in large organizations where employees are plentiful and easily replaced, but not in a small organization where knowledge of an area in the company is critical to its operation and trained employees are not easily replaced.

In Connell and Shafer's "The Professional User's Guide to Acquiring Software" (1987), the viewpoint is from that of a medium to large organization that writes its own software. This approach is interesting because, if read and believed by the manager of a small company, there would seem to be no possibility of obtaining a personal computer package without a great expense. It describes software for personal computers in the same context as that written and maintained for mainframe computers: that an in-house staff of information technology professionals is necessary. To make matters appear even less tenable for the small business, Connell and Shafer assert that the skills of each professional should include expertise in the following areas:

1. Advanced networking


2. Sophisticated hardware communications


3. Knowledge about personal computers manufactured by many companies


4. Background in operating system administration of many companies


5. Knowledge of consulting


6. The ability to quickly learn new computer languages

In defense of this view, it was developed before the flood of excellent and inexpensive software packages. A small company should not need personnel who have the above qualifications to implement a successful software package.

For example, advanced networking expertise is needed only if a company desires to install a local area network (LAN) that connects one or more personal computers to a server (a "master" personal computer that is more powerful and possesses enough memory and disk storage capacity to meet the needs of the network). And even if a small company does desire to set up a network of two or three computers, modern, easy-to-use LAN software for small installations is available. In most cases a user can be educated to administer the LAN simply by reading the instruction book that is provided with the kit. Difficult problems must be referred to an expert, but, again, for simple installations, problems rarely arise.

Knowledge of "sophisticated hardware communications" might be necessary in an organization that has a mainframe computer, but for a small company, even if it uses a small LAN, such knowledge is not necessary. For companies that choose to set up a LAN, a source of expert assistance should be identified so that a consultant can be called to handle difficult problems if they do arise.

Knowledge about computers manufactured by many companies isn't necessary. Knowing enough about the selected hardware to get a software package up and running should be sufficient. This basic knowledge is available from many sources including local colleges, adult education centers, and many computer stores. Most cities have one or more training companies dedicated exclusively to teaching the basics of computers.

If a company develops a relationship with a computer store, that store may provide answers that eliminate the need to hire an expert consultant. By the same token, expertise in operating many different computers is not needed. If the purchaser of software needs to know enough to get started, that information is usually provided with the general information about the hardware.

If consulting expertise is applicable in any organization that does not do consulting itself, it is for larger companies that want members of the information systems staff to interact with users as though they were consulting. Generally speaking, knowledge of consulting is not necessary except where that line of work is the purpose of the company.

The ability to learn new languages quickly probably only applies to consultants. For the purposes of this study, a small business will have no need to know any languages. Employees of a software house or a larger company that has the resources to write its packages in-house, will want to hire people who are literate in the languages the company uses to develop its software, but the need to be able to learn other languages quickly is rarely necessary except, once again, in a firm that specializes in software consultation.

Breslin (1986), in his book "Selecting and Installing Software Packages," states that when a company decides to convert to a new software package it must involve users to "minimize disruption and foster a proprietary attitude" toward the new software. He says that the benefits of the new package must be communicated to all employees to reassure them in areas of concern that they may have, including the possibility of having to work longer hours, the fear of the unknown, and job security issues.

Breslin contends that one of the reasons for the lack of user acceptance of a new package is inadequate user training. With the proper education and involvement, he says users will even embrace a deficient package. If users fail to fully accept a new package, it will likely fail. When users take ownership for a new package, their relationship to it changes from "their" package to "our" package. He says training plays an important role in user acceptance.

The training strategy Breslin suggests has four elements.

1. The company should assign responsibility for training. The most inexpensive approach is to "train the trainer." This trained person or group of persons can train other employees within the company.


2. The training syllabus should include the entire system, not just those areas that the users need to know, to provide an understanding of the relationship of the package to the various areas within the organization.


3. The training should sell the system to the users by discussing why it is needed and what benefits it will provide to the company.


4. Breslin's final element is the ongoing reevaluation of the training process to ensure that it is accomplishing the desired objectives.

In essence, the installation of a new package should be a positive experience for everyone involved with it, including the users. This premise of Breslin's is a key element in this study for the success of a new package brought into a small organization.

In summary, five authors, Seymour, Chorafas, Sharland, Shamlin, and Breslin recognize the importance of user involvement when introducing a new package to a company. The work entitled "Management Evaluation of Software Packages" and Connell and Shafer do not emphasize the importance of user involvement. In this study, the value and success of user involvement is tested.

Selection of Hardware
The approach of selecting hardware before selecting software, is supported by Mick (1984) who says that it is a myth that a computer purchaser should select the software first, then choose the hardware platform on which to run it. His contention is based on the idea that the things the computer will be used for will expand during its life, so the buyer doesn't have a firm idea of exactly what he will be doing with the computer.

He says the primary deciding factor should be that the chosen computer is flexible. In regard to hardware selection, price, performance, and the availability of software to run on the hardware are important factors. Although he doesn't name a computer type, Mick's comment about price, performance, and software availability supports the selection of an IBM-type computer instead of one manufactured by Apple.

In Cloning Around: A Guide to PC Compatibles, Stagner (1988) states that the success of the IBM PC product family as a whole has resulted in two important factors: 1) IBM compatibles have become the de facto standard, and, 2) this has resulted in an abundance of IBM PC-compatible software.

Apple Computer has incorporated IBM compatibility into its computer architecture, but the price/performance of a generic IBM compatible has made it the computer of choice for a small business of the type this study addresses. This isn't to say that an Apple Computer wouldn't be an acceptable choice for small company computing. If a company already had an Apple computer and were comfortable with the operation of it, it would be a viable alternative if suitable software could be found. The best approach in such a situation would probably be to investigate Apple-compatible software packages. If none were found that met the company's requirements, then the acquisition of an IBM compatible could be made to select a package.

An IBM compatible is a commonly available computer that can run most readily obtainable software packages. Sullivan (1991) points out that seventy-five percent of the personal computers in use are IBM or IBM-compatibles.

A cursory look at the software sold by computer shops, shareware providers, software speciality shops, office supply chain stores, and other sources shows that most of the programs are written for IBM-compatible computers.

However, if a company already has an Apple computer, software for most applications is usually available, although not in the quantity and diversity of titles compatible with IBM equipment. Sullivan says the decision regarding whether to buy an Apple or an IBM compatible computer is based on the preferences of the user.

Stagner (1988) addresses the possibility of purchasing a computer by mail order. He says that a person considering such an acquisition method should know how long the vendor has been in business, if the vendor can ship within forty-eight hours, and if it has an 800 phone number for technical support. Stagner suggests that the purchaser not buy unassembled components, but get the computer already assembled and tested. The problem with mail order computers is that if hardware problems occur, it is usually necessary to return the computer or parts of it to the vendor for replacement. Even the fastest turnaround may take two days, and a small company often cannot afford to have its computer down for that length of time.

Based on these comments, for this study, an IBM compatible was the computer of choice, purchased from a local vendor who could provide immediate support in case it were needed.

Selection of Software
Mick (1984) states there are four ways to obtain software: Buy a full software package, buy a function-specific module, write the system using a high-level development tool, or write the program from scratch using a traditional programming language.

Beizer comments on the write versus buy decision saying that the virtue of purchased software is that it tends to be better in most respects compared to software written in-house. He doesn't consider the cost aspect of writing software. Because writing a software package is beyond the capability of most small companies, this study focuses on purchased programs.

In an article entitled, "Selecting Software," Hollander (1992), says time, cost and availability are the major considerations to be made when deciding whether to buy or write software. He points out that more companies are choosing to purchase software instead of write it in-house because of the high costs and long lead time required to bring up home-grown systems.

Hollander contends that most companies do not know how to purchase software, and purchasing the wrong package can be costly and result in a lowering of employee morale. His solution is to put together a software selection team, then take time to define the system requirements.

Hollander's approach appears to have merit, although he doesn't specify whom should make up the selection team. Other authors have emphasized the importance of placing users of the new system on the selection team because they are the most knowledgeable in the operation of the existing system.

In his chapter "Buying Software," in Working Smart, Mick (1984) compares purchasing hardware and buying software:

Buying software is more difficult and frustrating than buying hardware. Software products are less well described than hardware products and tend to be more complex, making evaluation and comparison extremely difficult (P. 130).

Balzer provides another viewpoint in the difference between software and its relationship to hardware, contending that hardware capabilities have improved greatly during the past decade, but software productivity has lagged, resulting in much less relative improvement than hardware has experienced. Software development is an activity that is labor-intensive and not formalized (Balzer, 1989).

The selection of a software package begins, according to Carolyn Shamlin (1989) in her book, The Other Side of Software, with three tasks: 1) the needs assessment, 2) goals based upon those needs, and 3) objectives that achieve the goals. Her attitude toward software is that it should be as simple as possible, not grandiose, and meet the following criteria:

1. Have well-defined benefits.


2. Perform a function that is already well-organized and understood.

When buying software, Mick suggests the following guidelines: buying software for long-term use (with sufficient capabilities to serve the needs of the purchaser now and in the foreseeable future), making sure that good documentation is included with the purchase, insuring the software house is reliable, talking to other users, and trying the software prior to purchase.

Addressing Mick's first suggestion, for the purpose of this study, purchasing software with long-term use as a primary consideration isn't critical because outgrowing the software is not an immediate factor in a small company whose plan is to automate a manual system and not go beyond that objective for the near future. In addition, purchasing a complicated system could hinder implementation as observed by several authors: Shamlin, Mick, and Sullivan, discussed in the section entitled "Pitfalls in System Development."

Mick's second comment is that good documentation is important. However, for the purposes of this study, the selected program should be easy enough to use that extensive studying of a manual is not necessary. Furthermore, software writers often include documentation internal to the application program so that it may be consulted while the application is running. Even more advanced internal documentation methodologies include "context-sensitive" documentation in which a request for help results in documentation that is specific to the function currently being performed by the user.

Another disagreement with one of Mick's assertions is that the software house must be reliable. The reliability of the software house is not so important as the reliability of the software itself. Since many software houses go out of business, are purchased by another company, or drop product lines, it would be difficult to guarantee continued support for the product over a period of more than a few years, if that long. It is important to consider what situation the company would be in if the software house were unable to provide support. Could the company's application continue to function? This answer is difficult to answer. The approach to software selection should be to test the program enough to show that it is basically sound and will provide the same functionality as the manual system being replaced.

Mick's third point reviewed here is the suggestion that other users of the application be consulted regarding their problems and solutions. Discussions with other users is sometimes possible, especially with more popular software systems. Although some small businesses may be reluctant to discuss their software for fear of divulging competitive secrets, an attempt at finding out what works and what doesn't is important when selecting a package. Sometimes a software vendor may have a list of customers who can be contacted to discuss their experience with the software. A list of customers provided by the software vendor should be viewed with reservation because it may represent only satisfied customers and not a cross section.

The suggestion Mick makes for measuring and selecting software is for the purchaser to try it out. That activity is most important because not only does it provide verification of capabilities of the software, but it gives the employee who will ultimately use it the chance to determine how well it will replace the manual system.

Nixon's (1990) review of the development of farm-related software from a company called Farmplan is an interesting study in problems faced by uninitiated farmers when they convert from manual to computer systems to help them run their businesses.

Nixon notes that there is a wide gulf between the farmer and the software writer. The farmer has a general feel for his information needs but has no idea of how software should be written to meet them. The software writer knows how to provide an information system but does not have a good understanding of the farmer's problems.

Previous to Farmplan's software, farmers in the UK who could afford it, purchased time on mainframe computers and used computer service bureaus. The drawbacks to this approach were that the farmers had to entrust their data to an outside company and that these methods are expensive.

The advent of the personal computer enabled farmers to employ spreadsheets to track critical data. Some farm-specific programs became available in the 1980s, but they were too sophisticated and complex for the average farmer to successfully use.

Nixon describes how Farmplan was formed to solve these problems through the following approaches:

1. Provide software training to farmers to build their confidence in the programs.


2. Set up an advice hotline to address bookkeeping and accounting problems presented by farmers.


3. Periodically update the software to keep it timely and improve it.


4. Provide a hardware problem-solving service.

The Farmplan software was successful because of the provision of these concepts.

Nixon says the general characteristics of successful software are that it is menu-driven, and has data entry and report sections, input error checking, utility routines, and online help information.

These attributes can be easily verified during program testing. Nixon explains that the four criteria for program evaluation are its ease of data entry, the usefulness of its output, the effectiveness of error handling routines, and the quality of the documentation.

These items present a good guide for evaluation. The average user who tests a system should compare its functionality with that of the manual system with which he is familiar and draw conclusions from his experience running the program without specifically addressing each of these points.

In his section on evaluating computer software, Sachs (1984) says that choosing software is more difficult than selecting hardware because of the variety of software packages available and the multiplicity of features in each of them. His selection criteria are in question format:

1. Will the package solve the problem?


2. Will the program fit the current operational habits of the organization?


3. Is the program compatible with the hardware?


4. Is it compatible with the computer's operating system?


5. Does it have the capability to pass data to other programs?


6. Is the software house reputable?


7. Is it easy to use?


8. Is it reliable?


9. Is it flexible?


10. Is the user manual sufficient?


11. Is there manufacturer support for the package?


12. Is there a toll-free support number provided?


13. Is training available?


14. Is it part of a family of software?

Concerns one, two, seven, and nine ("will the package solve the problem?," "will the program fit the current operational habits of the organization?," "is it easy to use?," and "is it flexible?") can be identified by the user when testing begins. Either the program will work the way the user understands and considers acceptable; or it will do the job, but in a different way that may or may not be acceptable to the user; or it will not provide the desired functionality. Depending on the user's attitude toward the package, it may be accepted or rejected.

"Flexibility" is a vague term that doesn't have much significance in a discussion of software unless it addresses specific issues. Examples include the ability of the software to print to a dot matrix printer as well as a laser printer and, the ability to use pre-printed forms, the capability to use blank paper. Flexibility should be determined during the testing phase as program capabilities are investigated.

The third and fourth questions ("is the program compatible with the hardware?" and "is it compatible with the computer's operating system?") can be investigated prior to purchase by reading the program description which should provide a list of minimum system requirements. If the hardware lacks the necessary capabilities, either the software package should be rejected or the hardware upgraded to provide the needed power. Some software vendors, notably Software Etc., provide a money-back warranty on their software. A purchaser may return software purchased at Software Etc. within thirty days if unsatisfied for any reason.

If the software is loaded onto the system and fails to run, even after checking to determine that the correct procedures have been followed, if the user has had no problems testing other packages, perhaps it is a poor package in the first place or it is so complex that it requires expert knowledge that is absent in most small businesses. In any case, software that acts poorly during installation or start-up probably should be discarded unless there are other internal company reasons that it is needed (such as it interfaces with a currently-used package that runs well).

The sixth question ("does it have the capability to pass data to other programs?") probably isn't a concern because nearly all software packages lack this capability unless they are part of a group of applications from the same software house. There may be exceptions, but they are very rare. Data stored by package "X" is almost never capable of being fed directly to package "Y" of a different software manufacturer. For example, the accounts receivable information from an invoicing package called "Invoice-It" can't be fed directly to Medlin's accounting package. However, the invoicing data in Peachtree's invoicing system may be fed directly into Peachtree's accounting package because they have been designed to do that, and when a change is made to the data configuration in the invoicing program, the same change is made to the accounting package to insure compatibility.

Compatibility between the software systems of competing software houses is nearly non-existent. It would be like trying to fit a windshield made for a Ford into a Chevrolet. The designs are different, and they probably always will be. If a user wants inter-system compatibility, then an integrated system such as Peachtree should be selected, but that raises the problem of complexity.

Software house reputability, as raised by question six, is a moot concern because, as observed above, the continuous turnover and shake out in the software industry indicates that stability is not an attribute to be expected. If a package performs well and the user learns to understand and use it, that is more important than the viability of the software house. In the early phase of software testing and implementation there may be times when the software house would be consulted, but the company should realize that the software house may cease to exist at any time in the future and take that possibility into account when selecting a package. This is a negative point for very complex packages that might require a significant degree of assistance from the software house.

The reliability issue presented by question eight is difficult because unreliability in a program may show up immediately or later on. The term "software reliability" can have many meanings, but the primary concern is how the software treats the integrity of the data and if it operates in a consistent manner. For example, if a program tends to "lock up" the computer, making it necessary to restart the computer, it is unreliable. If data is somehow lost or corrupted, the program may be unreliable. These problems may not be the fault of the program. It may be incompatible with the hardware, there may be power surges that cause the computer to fail, there may be a hardware component that is operating intermittently, or the operator may be operating the system improperly (such as turning off the computer in the middle of a data entry session). If this software is set aside and a different package fails in the same manner, then the hardware or the operator may be suspect. However, if the new package works fine, then the failing package that was set aside may be the culprit and probably should be rejected.

A serious situation exists if the reliability problems occur infrequently. In such a case, it is more difficult to pin down the source of the problem. To prove reliability of a package, Sullivan (1991) suggests that the manual system should be run along with the new software for six months before stopping the manual one. Unfortunately, it is usually unreasonable for most small companies to run two systems in parallel for that length of time because they lack the manpower.

Question ten ("is the user manual sufficient?") also applies to on-line documentation because software houses are providing fewer manuals and more computer-based help information. This reduces the cost of printing manuals which, in general, are expensive to produce and keep updated compared to documentation that resides in the software itself. This question should be answered during the user testing phase.

In some cases, software is written to be so self-evident that reference to a manual or an on-line help facility is almost never necessary. The user will probably need to refer to some sort of printed instructions to get the program installed and to start it. From that point, most of the information should be on the screen or accessible from it. The usual help screen trigger in programs written for IBM-compatibles is the F1 (function one) key on the keyboard.

The chairman of IBM, Louis Gerstner, contends that the computer industry is very "unfriendly" from the viewpoint of easy-to-use software and hardware. He says, "This is an ego-driven industry that is in love with its own technology," a surprising statement coming from the top man at IBM ("IBM's chief," 1995). Competitive pressures are forcing software houses to improve their software so that it can be implemented, maintained, and run more easily by lay users.

In his chapter entitled "User Friendly - Buzzword or Breakthrough?," Glass (1991) says, "software engineers have begin to ‘think user'." He cites Xerox's Palo Alto Research Center (PARC) that developed the graphical user interface (GUI), first used in the Apple Macintosh and later in Microsoft's "Windows" program written for IBM and IBM-compatible computers. "Graphical user interface" is a big name for little pictures (icons) displayed on the screen. To start a program or a function, the user merely positions the mouse so that the pointer on the screen is touching the appropriate picture, then presses a button on the mouse. This replaces the earlier need to type a text command to start a function.

Questions eleven, twelve, and thirteen ("is there manufacturer support for the package?," "is there a toll-free support number provided?," and "is training available?" are similar questions that have been addressed, above, in the discussion of software house viability. Manufacturer support is nice to have in the beginning. If there is none, then the software should be very easy to use and the user doing the testing should have no problems implementing and running the package.

However, if no vendor support exists and the user has difficulty running the package, one of two situations may exist: either the user has little ability to run an office computer, or the package is not written well enough to provide operational answers within itself. If the user has had success testing another package, then he is probably capable enough to test any but the most complex program, and, as observed above, complex packages should be avoided for an initial conversion unless specific circumstances mandate their use.

The existence of a toll-free support number usually isn't an important issue in itself. First, if heavy support is required, either the user is incapable of running office equipment or the package is complex and deficient in easily available documentation. If the user's ability is the problem, that becomes a personnel concern of the company. Modern software packages are being written to be run by nearly anyone who can turn on a computer and is willing to learn. However, if the software is complex and difficult to understand, it should be rejected. Small companies usually don't have the fiscal resources to hire experts to run their software.

As for a toll-free number, the software purchaser pays for user support in one way or another. A software house cannot afford to provide free support. That cost is usually passed on to buyers of their products as a higher purchase price for the software or an annual support charge. The existence of a toll-free phone number with no per-minute charge for calls usually means that the costs of such support have been paid for by some other means. Like most businesses, software houses must keep their prices competitive and, at the same time, derive enough income to keep themselves financially viable.

Training is normally only necessary for the most complex packages. If a complex package must be acquired, then the availability of training is a concern. For software packages that address only one common business functions such as inventory control, invoicing, accounts receivable, accounts payable, general ledger, fixed assets, tax accounting, or point of sale, to name a few, training shouldn't be needed for a user who is familiar with the operation of the manual system being replaced.

Sachs' fourteenth question, "is it part of a family of software?" is a decision the company must make regarding the type of package it wants to install. In most cases, especially for the first or second package installed by a company, the package should be "stand-alone" software that is designed to address only one reporting issue. Later on, after a company has developed extensive expertise running several stand-alone packages, a complicated, integrated family of software may be considered.

Converting to a full-featured system can be a challenge because the individual programs often require one or more of the other programs to be functioning. For example, if the company purchases a fully-integrated package that consists of invoicing, accounts receivable, accounts payable, and general ledger, bringing up the accounts receivable part of the system may require the general ledger part to be brought up at the same time because accounts receivable transactions will be sent to it to keep all of the modules in balance with each other. So, the company may have to bring up several applications within the group, simultaneously.

This is a larger project than that of converting one manual system to a computer, and it is outside the scope of this study. However, with experience, a company should be able to pull off conversion to an integrated reporting system.

Referring to a May 1984 article in "Harvard Business Review" written by F. W. McFarlan and entitled "Information Technology Changes the Way You Compete," Sharland (1991) has developed four categories of software applications.

1. "Strategic" applications are those that enable a company to compete better. He says these are custom packages, traditionally developed internally. Examples of applications that fall into this category are material requirements planning (MRP), sales forecasting, and applications written to interface with suppliers.


2. "High potential" applications are less specific to the company, but normally not available from an outside source, so they are written in-house. Sharland cites manpower planning and decision support as examples.


3. "Factory" applications support common business functions such as accounts receivable, accounts payable, inventory management, and invoicing. These are commonly available off-the-shelf from software houses.


4. "Support" applications are not critical to businesses, Sharland says, but improve performance. Examples he gives are payroll, word processing, and database systems.

Sharland indicates that, of the above types of application software, only factory and support applications are candidates for consideration of being obtained from outside the company. These two types of packages are the subject of this study because they are easily purchased. However, they must be thoroughly evaluated to determine if they meet minimum acceptance criteria.

Sharland's analysis continues by describing four methods of package evaluation that would apply to "factory" and "support" applications.

1. The picture comparison method uses pictures from sales brochures, advertisements, technical manuals, and other literature. The pictures are assembled on story boards to illustrate the features of the product.


2. A detailed evaluation is based on questions about candidate packages written on an evaluation sheet. Weights are placed on the response of each question, then the answers to the questions are collected and the weighted calculations for each package compared to the others to make a selection of the best one. Software suppliers can be evaluated using the same method, according to Sharland.


3. An implemented evaluation is used for low-cost packages whereby the package is acquired and tested to determine if it is acceptable by creating and evaluating a list of deficiencies. Sharland makes some key observations regarding this method. He says testing must be done by those who will ultimately use the system because they know what the required functions are, and many of these may not be written, but, instead, a part of user knowledge. Sharland observes that the primary difficulty with low-cost packages for common applications is that there is a large number from which to choose.


4. The last method is package led evaluation, used when user knowledge of the business area for which the package is developed is limited. This evaluation uses a list of as many requirements that the users can generate, although it will certainly be incomplete in the beginning and may have to be enhanced as more is learned about the needs of the business area. The abbreviated requirements list is used to identify potential packages. Advice from software suppliers can be requested and site visits can be made at other companies using the package or to the software house to see demonstrations of the product. If the package can be acquired, at least on a provisional basis, experiments can be made with it to see how it meets the requirements.

Since this study will focus on converting a manual application that the users know, and the application to be converted will solve a single business problem, Sharland's "implemented evaluation" will be the method of choice. His 1991 book, "Package Evaluation," sums up this procedure that best fits small companies. This approach calls for the organization to obtain a likely software package and allow the users to test it to develop a list of deficiencies. Based on tests of several packages, the best one is selected.

A comment regarding the picture comparison method is that it seems unlikely that such a process would result in the collection of sufficient information to enable a company to choose one without the additional use of one of the other evaluation methods.

Another writer says the trend in software information representation on the screen is away from text-based data that requires the user to respond to text displayed on the screen by entering text to instruct the program (Dickinson, 1992). His view is that text is being replaced by graphical user interface (GUI) displays of pull-down "windows," "buttons," "icons," and other presentation devices that enable the user to navigate though an application using the on-screen pointer provided by a mouse, for example. He states that the trend is away from DOS-based applications which usually use text toward Windows-based applications which conform to the graphical user interface methodology. His contention is that the GUI format provides easier use of a product.

Although his premise has general merit, the ease of use depends more on the way a package is written and not the method of display. There are many examples of GUI software that is not easy to use for the uninitiated, for example, the database program FoxPro. A graphic presentation on the screen looks nice, but it is no guarantee that the average employee will be able to run it successfully without specific, in-depth training.

Smith and Tweney (1992) have some suggestions for general operation of invoicing software. It should have the ability for the user to add customers on the fly, while creating an invoice, instead of requiring that the invoice function be closed and then the customer add function be entered.

In addition, they recommend a package have the ability to print a message on the invoice such as "We appreciate your business." The configuration set up of the software should have built-in printer drivers to allow for the use of various printers, including a Hewlett Packard laser printer which is a de facto standard in the industry for laser printers. Most laser printers will print if the information they receive is formatted for an HP laser.

Smith and Tweney also mention that many invoicing systems will print only on pre-printed forms, often only available from the software house. Their advice is to look for a system that will print on plain paper which is much cheaper than printed forms.

Finally, the writers advise looking for software that provides for various statistical reports. Since the information will reside in the database, it would be convenient if it could be shown in various ways.

From the literature, the best suggestions regarding software selection are to buy, not to write; choose a manual application to convert that is well-organized and understood and is a relatively simple concept as opposed to an integrated family of interdependent modules; determine the acceptability of a package based upon the results of user testing; look for a package that can update other files on the fly, such as a customer file; seek one that will print on various printers and can use plain paper; and one that provides a selection of useful reports.

Determination of Common Themes
The primary common themes presented by authors that apply to small companies considering converting a manual system to a computer system are two. First, the purchase of a software package, instead of having a custom system written, was a consideration. Second, involving the users in the entire software selection and implementation process was presented by several authors. A third theme that is discounted by this study is the need for training, discussed later.

Shamlin (1989), Sharland (1991), and Mick (1984) each assert that, for a small organization, there are advantages to purchasing software as opposed to having the software written in-house by one or more employee-programmers, or having it written by outside consultants. Shamlin points out that purchased software is likely to be much less expensive, be thoroughly tested, may have a broad range of features in order to meet the needs of a wide group of clientele, is already in use by other businesses who might be sources of information about the product, and may have an on-going product enhancement program.

For the objectives of this study, in a small business, if an inexpensive package can be found that achieves the necessary functionality provided by a manual system, then implementation of it may yield positive results in the form of better customer service, more timely reports, a savings in labor, and better overall operating efficiency.

As for involvement of users, several authors held this concept to be of great importance to the success of a computer system implementation, specifically, Seymour, Chorafas, Feynman, Sharland, Shamlin, and Breslin.

Although his situation was unusual, Feynman (1985) illustrates that the success of his project hinged on the involvement of the staff. In this case, it was solving the complex calculations supporting the development of the atomic bomb during the mid 1940s. After he took over the computer center at Los Alamos, New Mexico and arranged for the workers to be told top secret information about what they were doing, their problem solution rate soared.

Shamlin, Chorafas, Sharland, Seymour, and Breslin are in agreement with the concept of involving users from the beginning of a conversion project. Each of them note that the success of the project may depend on user involvement.

No author discredited the idea of involving the user, but Bentley (1984) recognizes that a new package results in human problems attributed to change. He suggests there are three primary effects to humans when they are faced with change, and for a project to be successful, they must be addressed.

1. Physical (relocating work areas)


2. Psychological (concerns regarding layoffs, over-time work, responsibilities)


3. Social (the framework of an individual's relationship with others)

Although Bentley's three effects may carry importance in a large organization, for the purposes of this study of a small company, such concerns would probably be solved in an ad-hoc, informal manner.

Nixon (1990) and the book entitled "Management Evaluation of Software Packages" (1985), consider that proper user training is the key to the successful implementation of software. These sources do not address the possibility of user involvement in a project. For the purposes of this study, training is not considered a paramount requirement for successful package implementation.

Although training is important in some situations, only minor familiarization with the use of a computer is necessary to get a simple package up and running. In fact, users of the manual system are usually knowledgeable of its functions and its relationship to other areas within the company. They will be the best qualified to evaluate a computer package to take its place. This is why the concept of user involvement is considered one of the most important themes provided by the authors studied here.

For the small company, where one or two people can make or break a conversion project, it seems to be very important that the staff be involved from the beginning. This study will investigate the value of involving the employees in the project from its inception.

Hardware Historical Perspectives
This is an overview of the evolution of computers to illustrate the technological changes that have resulted in an inexpensive computer that small businesses use to solve many of their data processing and reporting requirements.

During the 1940s computers were developed primarily for research purposes in universities. A few private companies, such as IBM, did research and development too, but computers were so expensive to build that very few private persons or small companies could afford to own a computer until the late 1960s.

The military was one of the largest customers for computers, especially during World War II. One major application for military computers was calculation of fire control solutions for radar directed guns (Feynman, 1985).

There are two basic types of computers: analog and digital. Analog computers became popular in the late 1930s, followed by the digital computer in the late 1940s. Analog computers are mechanical, most often using servo motors to do addition and subtraction to achieve the desired solution. A mechanical input to a servo motor shaft (for example, turning it by hand), that causes it to rotate two tenths of one rotation, results in an electrical output representing that much rotation. If a second servo shaft is rotated three tenths of one full rotation, and its output signal is sent to a third servo along with that of the first servo, the sum of these two inputs causes the third servo to rotate five tenths of a full rotation. The result may be mechanically displayed by an odometer-type mechanical readout. A negative number may be represented by reverse rotation. In the above example, if the value from the first servo represented a rotation of minus two tenths of a rotation, the sum of its output and that of the second servo would result in the third servo turning only one tenth of a full rotation. In this manner, addition and subtraction are accomplished, and multiplication and division are simply a string of additions and subtractions, respectively.

Analog computers have survived only in very specialized applications because they are not accurate, require a lot of maintenance and periodic realignment, are very bulky, and are relatively slow (Forkner & McLeod, 1973).

Although there were experimental mechanical digital computers using ganged electrical switches in the early Twentieth Century, they did little useful work. In the early 1940s IBM built punch card tabulating machines that were used to solve a single mathematical function at a time, such as multiplying numbers on two punch cards and creating a third card with the result. IBM machines like this were used to do calculations required to develop the first atomic bomb at Los Alamos, New Mexico (Feynman, 1985).

With funding provided by IBM, Harvard developed the Mark I computer, a step beyond the punch card tabulator technology, and considered the first real computer, even though it was based on existing electromechanical technology.

It was in 1946 that two University of Pennsylvania engineers, Mauchly and Eckert, built the first vacuum tube computer, ENIAC (Electrical Numerical Integrator And Computer), considered the first electronic computer (Bentley, 1984). It used 19,000 vacuum tubes (called "valves" by the British who invented them), weighed thirty tons, and was housed in a large room (Forkner & McLeod, 1973). Even though it was crude by today's standards, ENIAC was one thousand times faster than any calculating device before that time (Bentley, 1984).

Vacuum tubes in computers operated in one of two states: either "on" or "off," to represent "one" or "zero," respectively. Transistors in computer chips work the same way. Strings of ones and zeros are numbers in base two and can be mathematically manipulated to achieve great accuracy. Vacuum tube computers provided a vast improvement in accuracy over analog computers, but tubes were prone to burning out, much the same as a light bulb, requiring replacement. A 1940s vintage vacuum tube computer had much less power than a modern calculator and was much more bulky.

In 1949 The University of Cambridge developed a computer called EDSAC (Electrical Delay Storage Automatic Calculator). The University of Pennsylvania followed with EDVAC (Electrical Discrete Variable Automatic Computer). EDSAC and EDVAC were unique in that they were the first computers capable of storing instructions and data and to use modifiable instructions (Bentley, 1984).

The first generation of machines considered true computers began in 1951 with the first commercial computer installation, and extended through 1958, when Sperry Rand announced the first transistorized computer, heralding the second computer generation, lasting until 1964. The third generation, beginning in 1964, featured a leap in computer power made possible by miniaturized transistor circuits, thin film memories, and the introduction of high-level languages such as Algol, Fortran, and Cobol (Bentley, 1984).

The milestones of subsequent computer generations are blurred because advancements were less revolution and more evolution (Forkner & McLeod, 1973).

Until the introduction of the minicomputer in the late 1960s, computers were of the "mainframe" variety. Minicomputers provide slightly less power with an excellent price/performance ratio, compared to mainframes.

As miniaturization continued, by the late 1970s, small "personal" computers, in kit form, were available for hobbyists to build and program. In the late 1970s Apple Computer began production of a complete, ready-to-run, personal computer that became popular with businesses, schools, and individuals. For the first time, the non-technical person could purchase and use a computer.

The computer industry giant, IBM, decided to meet Apple's personal computer challenge head-on by introducing its own entry, the IBM PC, into the personal computer marketplace in 1981 (Stagner, 1988). To motivate software developers to create programs to run on its computer, IBM elected to present its offering with "open architecture," meaning that the internal design was available to anyone so that software development would be easier. As a result of open architecture, availability of software to run on IBM exceeded that available for Apple computers.

However, the open architecture philosophy backfired on IBM as other manufacturers began building computers based on the IBM architecture. They are called "IBM compatibles" because they are designed to use the same software as IBM computers (Dodge, 1994). The resulting competition caused IBM-type computer prices to plummet. As performance increased and prices dropped, sales skyrocketed.

Traditionally, computer power has increased each year, and the price per unit of compute power keeps falling. That tradition continues today. The first IBM PC, introduced in 1981, cost $5,000 (Stagner, 1988). It was configured with one megabyte (MB) of random access memory (RAM), two floppy drives, a monochrome monitor, and a printer. Its oscillator speed, a measure of how fast a computer can execute instructions, was 4.77 megacycles (MHz). It had no hard drive because there were none commercially available for the PC at that time.

By comparison, in 1995, $2,500 would purchase a computer with 8 MB RAM, two floppy drives, a color monitor, a printer, a 540 MB hard drive, and a clock speed of 90 MHz.

The adaptation of a hard drive to the PC resulted in the PCXT, introduced in 1984 (Stagner, 1988). "XT" is an acronym for "Extended Technology." In 1985 the PCAT came out. "AT" stands for "Advanced Technology," and this machine was a departure from the earlier IBM design in that the logic circuits had been reworked to improve performance. The first model of the AT is also commonly referred to as the 286 because it uses the Intel CPU chip with the designation "80286." Subsequent models of IBM and IBM compatible computers are still referred to as "AT," even Pentiums, because they adhere to the basic architecture pioneered by the 80286.

It is this computer evolution that ultimately enabled small businesses to purchase computers to take over many of their reporting and operational tasks.

Software Historical Perspectives
In this study "software" refers to application programs, as opposed to system software that constitutes operating systems such as DOS and Windows.

The early software for PCs was text-based. Programs displayed instructions and information on the screen in text format. Screens were all monochrome, so programs didn't need to provide color displays. As programs became more sophisticated, they began using graphical displays. These were an improvement over text-based displays because they could be more easily understood through the use of icons providing information that pure text could not.

From a software perspective, improvements have kept up with hardware advancements. In fact, to some extent, software has pushed hardware development because more advanced programs require faster computers with more storage capacity.

The first stored computer programs were written in machine language, represented by ones and zeros. Machine languages continued to be used into the late 1950s when assembler languages were developed to make computer programming more efficient. One statement in assembler language can generate several machine language statements, improving programmer productivity. The problem with assembler languages is that they are specific to a manufacturer's equipment, a problem that was resolved with the advent of compiler languages which can run on a variety of computers. Programming efficiency was again improved since one compiler statement can generate many machine language statements, the equivalent of many assembler statements (Forkner & McLeod, 1973).

Technology produced the color terminal, which enabled additional information to be made available to the user. For example, warning message might be shown in red letters to attract attention. In response to Apple's graphical user interface (GUI), Microsoft developed a GUI for IBM computers and called it "Windows." Early versions are not true operating systems, but a collection of graphics displays that allow the computer to launch programs. Windows programs are characterized by "pull-down windows" that are information boxes allowing complex selections and decisions to be easily made by the user. The easiest method of interfacing with Windows is by a pointing device, such as a mouse or track ball. By manipulating the cursor around the screen, the user can point to the selection that he wishes to activate.

Programs written for IBM and IBM compatible computers are of one of two types: DOS or Windows. A DOS program runs using the DOS operating system and does not need Windows. A Windows program requires Windows to be running before it can be started. A program that runs only with DOS will run faster than the same program that is written for Windows because Windows is an additional series of programs that must be run, requiring additional hardware resources.

Faster, more powerful computers have accommodated larger, more complex programs that older computers built a few years ago cannot run.

If a program is well written, it doesn't matter whether it runs under DOS or under Windows. It should be easy to use and provide the necessary information in a clear manner. For this study, an easy-to-use, highly functional software package was sought, regardless of whether it was DOS-based or required Windows.

Pitfalls in Conversion Projects
Shamlin (1989) observes that if the users aren't involved in the project, they won't take ownership of the system to insure its success. When an individual is invited to participate in testing and implementing a software product, he becomes an integral part of the process. When that person helps select and test the system, it is hoped that he will become a supporter of it and take a certain amount of pride and ownership in it. This ownership attitude motivates the user to try to overcome system deficiencies, causing him to find ways to work around problems that would frustrate and alienate someone who has not developed a sense of "ownership" of the project. If this attitude can be instilled in key users of the system, they will do all they can to insure that the system works.

Feynman's (1985) experience running the computer center at Los Alamos during World War II is probably the first recorded example of a computer room staff doing as little as possible until given "ownership" and a sense that they were an important part of the project.

Feynman took over the computer center after the first manager got sidetracked investigating the computer's capabilities instead of using it to solve the complex mathematical problems the scientists needed to build the first atomic bomb. The group of people running the computer had only solved three problems in nine months. Feynman describes the situation when he took over:

. . . although they had done only three problems in nine months, I had a very good group. The real trouble was that no one had ever told these fellows anything. The army had selected them from all over the country for a thing called Special Engineer Detachment - clever boys from high school who had engineering ability. They sent them up to Los Alamos. They put them in barracks. And they would tell them nothing. (p. 110).

The staff came to work each day, punched numbers into cards, and ran them through the IBM computers, but for what purpose, they didn't know. Feynman's approach was to have Oppenheimer get permission from the security people for Feynman to give the men a lecture on what the Los Alamos project was all about and the significance of the computations they were doing.

After the lecture, the men were very excited. They felt involved. Now they understood that they, too, were helping win the war and their work was of utmost importance to national security. Their efforts in the computer lab rose considerably, and they began to invent ways of doing the computations better. They began working three shifts, and they didn't need supervision. In fact, they invented some additional programs to supplement those that the scientists, like Feynman, had developed. During the next three months they solved nine problems, a productivity increase by a factor of nine!

Converting a manual system to a computer should only be done if the manual application operates well (Bentley, 1984). The basis for this assertion is that automating a poorly running system won't make it better. It may actually cause a degradation in performance. In a small-company environment, the solution would be to choose a different system to be converted or take the time to iron out the problems in the manual system before attempting to migrate it to a computer.

As mentioned previously, in the section entitled "Selection of Software," Shamlin states that only a manual system that is well understood should be converted to a computer.

Computers can be a boon to small businesses, but they have weaknesses that have to be considered (Bentley, 1984). Computers, small or large, are hardware devices that are susceptible to failure. Although it is uncommon, they are essentially electromechanical devices, and, as such, can cease operation for a variety of reasons including power surges, sharp jolts, over-heating, and component age.

Program failure is another hazard of computerized applications (Bentley, 1984). Not every program is perfect in every way. A section of code that has not been tested well and is infrequently used, may not exhibit a problem until some time after the program has been working. A small company that lacks computer experts who can immediately address and fix the offending code, must rely on support of the software house or a consultant to repair the problem.

Operator failure is another potential area of trouble, but it is usually corrected by using the proper operating procedure. However, human errors can do harm to a computer system if a file is accidently deleted or harmfully altered. In situations like this, a company must call in a software professional. Assuming the mistake was an honest accident, the blame really cannot be placed on the operator. A well-written computer program will have safe-guards to prevent accidental destruction by an inept user.

Other potential pitfalls described by Bentley include improper control procedures (e.g.: failing to back up files), program rigidity that prevents any program changes, system complexity, poor staff training, and output that is improper for the use intended such as a report that goes to the screen, but cannot be directed to a printer or a program that allows for printing to a dot matrix printer but not to a laser printer. Many of these potential problems can be identified during the investigation of the product before it is implemented simply by testing the features of the system as they will be used after installation.

Shamlin says it is a mistake to try to install a large, complex system that is grandiose because it will require much longer to install and increase the cost of the software (1989). Mick (1984) agrees, stating that it is difficult to make a very complex system successful in a reasonable period of time, compared to a more simple one. He says that a simple system is a better candidate for a company's first conversion than a complex one because it is more easily implemented, can be put in place in a shorter period of time, the users are provided earlier use of the software, and it is less costly than spending additional manpower trying to put in a system with a broader capability. Although a simpler system may have less functionality than a more complicated one, unless there are mandatory features that are lacking in the simpler system, it is usually the most economical choice.

Sullivan (1991) concurs with the concept of starting small when it comes to converting from a manual system. He contends that implementing a program that is too big for the business's current needs is a waste because unneeded information must be created and entered into the new system to set it up. He says that a company may eventually choose to migrate to a larger computer system, but that it is best for the company and its employees to become familiar with the computerization of the system first, then advance to a more complex system later, after a high comfort level has been achieved with the computer and the way information is processed by the new application.

Sullivan also states that if a computer system chosen to replace a manual operation is compatible with a more powerful system that could be installed in the future, the existing data files could be transferred directly to the new system. However, this advantage shouldn't be counted on because upgrading to a more capable package usually means that the data in the old package must be manually transferred from the old to the new. This is usually accomplished by printing the contents of the old system to paper, then entering that information into the new system in the format required by it. For the small business to avoid pitfalls, the authors cited agree that user involvement is important to the success of a new system and that simplicity is best for the first computer system that replaces a manual one. The study was begun with these concepts in mind.

Testing
Testing is an important aspect of choosing a software package. The testing process should thoroughly check all of the functions that the company considers necessary for its operation. Testing should also provide a good feel for the overall characteristics of the package.

Although the thought of testing software that has never been seen before may be a daunting prospect, testing a new package can be accomplished without having detailed knowledge of how it works (Beizer, 1984). Knowing the principles of the operation of the application is sufficient. A significant determination of the success of a package is how easy it is to begin using.

Beizer states that it is impossible to prove that a program is error-free or perfect. He says that a realistic goal of testing is to provide a "suitably convincing demonstration" that provides the user with a comfortable feeling for the operation of the software.

A user contemplating testing a program for the first time may find solace in the findings of Goodell (1989), that most commercial programs exhibit similar characteristics. This would lead a user who is about to test a package to expect similar operational characteristics from packages designed to process the same application. Goodell studied the functions of business programs and found that the great majority of them do similar things. The most predominate action of business programs was printing a report, followed by file maintenance, file build/load/copy, posting/updating, and sort. These were the functions most common in business software. He concludes that business applications tend to be consistent in the things they do, largely attributable to common business and accounting practices.

In an article in "Software Development," Gianturco (1994) describes several testing methods. Functional testing, also called "black box" testing, is a procedure used to create test cases based on the program's functionality as described by the program specifications. This testing method is not practical for verifying selected software packages in this study because it requires analysis of software specification which are not available in most packages.

Equivalence partitioning is another non-execution testing method in which program specifications are examined to determine valid inputs to each program subroutine. For the same reason that functional testing is not viable for this study, equivalence partitioning is not usable. It requires program specifications which are neither available nor easy to analyze by a package purchaser.The third non-executional testing method Gianturco discusses is Boundary Value Analysis. He characterizes it as usually augmenting equivalence partitioning. This method involves examining program specifications to determine valid and invalid input values. In reality, a user will most often determine the validity of input values by testing the program during execution.

Category-partition testing is the fourth non-execution testing method. It involves creating a list of items that can vary for each input to the program, including data types, length of input data, and size of the data. It is used to create test cases by choosing values based on classes of data. This method is more valuable to software designers than users.

Structural testing, also called "white box" testing, includes several ways to confirm program viability. It uses analysis of the program's structure (study of the program code) to design test cases. This is a different approach from functional (black box) testing which uses program specifications.

Another structural testing approach is mutation testing, an execution-based method which requires several variations of the program, referred to as "mutants," to compare their output for validation purposes.

Another testing method is called "Run-time assertions," wherein blocks of code are inserted into a program to test its operation during execution.

"Data flow analysis" develops test sets by examining how variable values are defined and used by the program. It is a non-execution test, and more valuable to the software house than the software purchaser.

"Multiple version testing" is an execution testing approach whereby several versions of the program are coded from the program specifications. The output produced by the majority of the program variants is considered to be the true output of the program.

Path testing, another execution-based testing method is probably the best approach to use by the user. The program is tested during execution by entering various input values to determine how it reacts. Examples of path testing include some methods (statement, branch, and condition coverage) that may or may not be suitable for a user to employ in a testing program. "Statement coverage" insures that every statement is executed at least once. "Branch coverage" insures that every program branch is executed at least once. These methods are more applicable to testing by the software developer than the user. "Condition coverage" is the execution and subsequent evaluation of each branch to determine if the input result is "true" or "false." Again, this is applicable to use by the software house. "Extended branch coverage," also called "multiple condition coverage," checks a truth table (a true/false matrix of results of entering various inputs) to test every variable. This is a very time-consuming testing method because of the great number of possible input variables to a program or program routine.

"Code reading" is a thorough, non-executional testing method used by programmers to check their code by reading each line to try to determine if the program is correct. A code walk-through is accomplished by one programmer who creates specifications from reading the code. These specifications are then compared to the original specifications to see if they match. Desk checks commonly employ three programmers analyzing the code to find logic faults (Gianturco 1994).

As noted above, the only testing method available to the small company is path testing, an execution-based testing method in which the user enters various types of data and observes the system's reaction to it.

Summary
Two major ideas regarding the introduction of a new computer system have come forth from the literature. First, if too much is attempted at any one time, it is possible to get bogged down in the myriad of details, causing the project to get strung out for a long time, or dropped completely due to indecision and frustration. Even large companies with many information system specialists can become overloaded working on a project that is too large, too radical, or is changed too much during the implementation. In selecting a more simple solution, desirable features may be given up, at least temporarily, but the objective is to get the basic system up and running. After that, the extra functions can be addressed. The second important observation the authors agree on is that, by involving the users at every stage of the process, they will accept the project and make it their own, insuring its success. The authors studied consider this one of the most important aspects of the process of putting in a new system because without user backing, it won't be as successful, and could fail completely, causing a negative impact on efficiency and productivity as the company has to back up to the original system or take some other recovery action. Chapter 3

METHOD

Selecting the Subject Company for the Study
The objective of the study is to determine if a small company that does not have much computer expertise can improve its information systems using its own resources. The conversion of a manual system to a computer-based system should be inexpensive and have a positive impact on the company, its employees, and its customers.

A subject company might already have some of its reporting work done by computer, but it should have at least one manual application that is a candidate for being automated. In addition, its management needs to be open-minded about allowing a study to be undertaken on its premises, and if a candidate manual system is identified, allow it to be converted to a computer.

The selection process was begun by talking with local small business owners to determine if they might be interested in allowing their company become the subject for this study. The owner of a small wholesale office supply company agreed to the study. He was planning to take his wife on a two-month vacation and, after becoming familiar with the approach to the study, allowed it to commence in his absence. His daughter would manage the operation while he was away, visiting the office each day for approximately one hour. She was agreeable to the concept of the study, would monitor its progress, and make any required decisions.

One stipulation the owner made before allowing this study to be undertaken was that there be no risk to his company or his employees. This was a fair requirement. It would be poor technique to enter a place of business and cause it harm or distress.

To begin the study an assessment had to be made of the information systems his organization, The Ross Company, was currently using. If there were no manual applications that were candidates for converting to a computer, his company would not fit the selection criteria, and another subject company would have had to be found.

The company meets the criteria of being small, grossing about $170,000 per year. A billing system that was implemented several years ago by a consultant is run on the owner's computer at his home. All other company information systems were manual, including the invoicing, general ledger, accounts payable, inventory, customer list, and pricing.

Since the owner of the company owns a computer, he is not averse to computers in general, but he lacks the confidence and knowledge to try to implement any new systems at the company by himself. Until asked if he would agree to free consulting, he was not interested in hiring a consultant to investigate the possibility of improving his company's systems.

He started the company in 1950 with a partner who is no longer a member of the organization. Recently, due to competitive pressure from the office supply chain stores, his company has been under severe economic pressure. It barely breaks even during the year, making the issue of operational efficiency important.

Prior to the study, he had two employees, a half-time typist and a shipping clerk. The half-time typist planned to retire in a few months, when she turned sixty-five. She would either have to be replaced, or the workload of the shipping clerk would have to be increased to cover the additional duties of typing invoices and shipping labels.

Neither prospect was encouraging because the wages paid by the company have not kept up with inflation. The half-time typist, who worked twenty years for the company, received $6.80 per hour, and it is expected that a replacement would have required $8.00 or more.

The shipping clerk, who is an eight-year veteran of the company, earns $7.25 per hour, and to place too much more work on him might be cause for him to seek another job. Replacing him would probably require the company to pay a higher wage to entice a new employee to take the position. The cost to the company of paying a higher wage is not only the wage itself but the additional state and federal payroll taxes.

With the confirmation that the company met the criteria of a small business that has several manual systems, the next step in the study was to determine if it had a manual system that could be converted to increase its efficiency.

Selecting a Manual Application to be Converted
The manual systems identified as potential conversion candidates included general ledger, accounts payable, inventory, invoicing, pricing, and customer list.

The general ledger, accounts payable, and inventory systems were manual, done by the owner at his home. Although they are candidates for conversion, since he does them himself, they don't have a direct impact on company operations. Therefore, they were rejected as potential applications to convert.

As for the pricing function, each quarter the company's major supplier sends it three price books, called "pricers." They are one and a half inches thick, contain the item number for each of the 25,000 items represented in the annual color catalog, a short description of the item, and four columns of pricing. The Ross Company pays the lowest printed price, shown in the fourth column. Ross's customers, retail office supply stores, pay the first column price which is typically between fifteen and twenty percent above Ross's cost. The end customer's cost at the retail stores is about fifty percent higher than what Ross's customers pay.

Converting the pricer to the computer is beyond the company's needs for the following reasons. First, it would have to be redone each quarter and would require each of its 900 pages to be scanned into a computer format. At this time, it is not a good candidate for conversion because it wouldn't achieve a great deal of efficiency. Also, the likelihood that a computer program could be found that would accommodate scanned pricer information is remote.

The same is true for the customer list. It is maintained on a Rolodex file. When an invoice is typed, the Rolodex is consulted for the customer's address. The address is also typed on a shipping label using the Rolodex as a source for the shipping address. Converting it, by itself, would not provide much advantage to the company.

Finally, the invoicing system was considered. After looking at all of the applications, this was the one that stood out as having the potential to do the most to reduce costs. If it could be converted to a suitable software system by the time the typist retired, the workload of the shipping clerk might not be increased too much so that he could do both the invoicing and his regular job, packing and shipping orders. It became clear that the customer file and the pricing information might be incorporated into a computer-based invoicing system, resulting in an overall improvement in the company's information systems.

Shamlin's (1989) criteria for selecting a manual application to be converted are twofold. First, the object of the conversion must have well defined benefits and, second, the manual system must be well organized and thoroughly understood by the user.

The benefits to be derived from converting the manual invoicing system were well defined, predicted to be a majority of the following items. Some of them raise questions which are addressed in a discussion of the manual system, in the following section.

• A neater invoice would be produced.


• After the most active inventory items have been entered into the computer, the invoice creation process would simply be a matter of selecting an item from the list in the computer, greatly accelerating the invoice preparation process.


• The use of the price book to find the price of each item ordered would no longer be necessary because the pricing information for every item would reside in the computer.


• If an invoice were lost or mutilated, it could simply be reprinted.


• Two different sizes of four-part invoice forms would no longer be needed. A cost savings would result from using white, single-part stock paper instead of the forms.


• The existing disparity in invoice numbers on the two different sizes of invoice forms would be eliminated by computer-generating the numbers.


• The Rolodex would no longer be needed to find a customer's name and address. The name and address would automatically be printed on the invoice, and it could be read from the invoice to type the shipping label.


• Sales and inventory status reports would be available at any time to show current status or the status for any given time period.

Shamlin's second requirement, that the user should understand the manual application, was satisfied. The invoice typist and the shipping clerk knew the system very well.

The owner's daughter assented to further study of the invoicing system, followed by implementation of an automated system if a suitable on could be found. The next step was an analysis of the manual invoicing system to determine how it worked and what the key requirements were for a software replacement.

Operation of the Manual Invoicing System
Operation of the manual system began with the placing of an order by a customer. Orders are usually placed by phone, but they may be faxed or arrive by mail. Both the half-time typist and the shipping clerk took orders during the morning when the calls were heaviest. After the typist left at noon, the shipping clerk took the orders during his work of packing orders and preparing them for shipment each afternoon.

Two phone lines are installed with a roll-over feature in the event the primary number is busy. This enables two calls to be handled simultaneously, allowing both the typist and the shipping clerk to take orders at the same time. In the afternoons orders were called in less frequently, so the shipping clerk was able to handle all of them himself.

The manual invoicing system was item number-driven. When a Ross employee took an order, each item number was written down on paper as the customer identified it. Most customers place orders by item numbers found in the catalog. In cases where a customer can't find an item in the catalog, the person taking the order looks for it either during the call or after the call, depending on the customer's preference. Once the item number was located, it was added to the customer's order sheet.

After an order was written, each item was located in the price book and the price per unit was written on the paper. If the number of units ordered was greater than one, then that number was multiplied by the unit cost to obtain the extended cost.

During the morning, the typist typed the order on half-page, NCR (no carbon required), four-part forms. These had pre-printed, consecutive invoice numbers. When the supply got low, they had to be reordered with the proper sequence numbers.

Each page of the four-part form was a different color to make identification easy. Since the typing was less clear on the back sheets, the customer received the front copy (the original), as a shipping list and invoice, packed with the order. Another copy was filed alphabetically by customer name, one became the working copy that went home with the owner so he could update the general ledger and accounts receivable books, and the fourth copy was an extra packing slip in the event of a drop-ship. If the order was not a drop-ship, the fourth copy was thrown away.

The half-page form was supplemented by a full-page invoice form for orders that had more items than would fit on the half-page form. The owner used the two types of forms because he wanted to cut costs. Since most orders would fit on the smaller form, and it was less expensive than the full-page form, there was a small savings.

It was rare for an order to require more than one full page, but when that occurred, two full-page invoice forms were used. A problem with using two sizes of invoice forms was that each size had a different invoice number sequence. This made it more difficult to find an invoice within a customer's file because two numbering systems were in use: one for short invoice forms and a different one for long invoice forms. If a customer's orders rarely required a large form because his orders were usually small, they were more easily located in the file than if his orders were a mix of large and small orders requiring large and small forms with two sets of invoice numbers.

To type the invoice, the customer's name and shipping address were found on the Rolodex file. A pencil was stuck between the cards to hold the place while the information was typed on the invoice. Additional heading information included the date and Ross' address which was actually typed on each invoice. The owner's philosophy was that the company's typed name and address looked neater than that of a stamp.

The body of the invoice was then typed, containing, from left to right, the item number, the number of units ordered. a description of the item, the suggested list price, the wholesale cost to the customer, and the extended wholesale cost.

During the typing process, errors that occurred were corrected using the correction tape mechanism built into the typewriter. However, the three back pages were smudged by the correction. They were usually corrected after typing was finished by penciling in the correct information. Since these pages were used internally, their appearance wasn't as important as the customer's copy which was the original that was corrected with the lift-off tape. However, there was a chance that the corrections would not be made correctly or would not be made at all. There were times when an error was discovered after the invoice form had been pulled out of the typewriter. In those instances, White Out was used to cover up the mistake before the information was re-typed.

Invoice forms often became ugly with painted-out errors, lift-off marks, and retyped areas. Sometimes the typist elected to simply retype the entire invoice, a waste of time. After being re-typed, the smudged invoice was thrown out. The problem was that a gap in the invoice numerical sequence resulted, preventing reconciliation of invoices by their numbers. The owner reconciled by matching items received from Ross's suppliers with items shipped to customers, researching disparities when the items ordered weren't shipped out or when items shipped were not shown as having been ordered by Ross.

When the typist left at noon, the shipping clerk did the order taking, invoice typing, and order shipment. The most time-consuming part of his job was, and still is, handling inventory and packing orders. Typing invoices was his next most time-consuming duty.

Before sealing a box, a shipping label has to be typed. A standard, glue-backed label is stamped with the Ross return address, then placed in the typewriter. The Rolodex customer file or the invoice was consulted for the shipping address of the customer.

The final part of the shipping procedure requires wetting the back of the label, placing it on the box, weighing the box, and writing the order information into the United Parcel Service (UPS) log.

Items ordered that are not be available for shipment the following day are written on a sheet of paper and placed in a back order tray. Most items are available from Ross' main supplier, but if the local warehouse is temporarily out of stock, they are ordered from one of the supplier's other warehouses, usually Salt Lake City, Los Angeles, or Dallas. Since these items require two or three days to arrive, all available items are shipped upon receipt, the following day, unless the customer specifies that he wants the shipment held until the entire order can be shipped to reduce his shipping costs. When the items arrive, the back order sheet serves as a reminder of the customer who ordered them.

Orders received during the day are ordered from Ross' primary supplier that afternoon if Ross doesn't have them in stock. They arrive the following morning in time for the shipping clerk to box them for shipping by the time the UPS truck arrives in the afternoon.

This completes the description of how the manual invoice system worked. Now the problem was to find a software package that could take its place. But first, a discussion of hardware selection is undertaken.

The Selection of Computer Hardware
Selecting the computer to run software that has not yet been selected may seem to be a futile task because, without knowing which software package is to be chosen, how can a computer to run it be identified? The response to this apparent dichotomy is that the scope of the software to be used is known. It is a single, relatively simple application instead of a group of interrelated accounting applications such as general ledger, accounts payable, accounts receivable, and inventory control bound together in an integrated package.

Furthermore, the invoicing function, by itself, is not a huge, complex application. It must do a few specific things that are currently accomplished manually, that is all. For example, it should allow order information to be typed in and then printed on an invoice. There may be some additional requirements when the actual selection is studied, but, for right now, a basic computer is all that is required. The software programs of an average invoicing package might require five to ten megabytes (MB) of hard drive storage and, perhaps, another five to ten MB for data storage.

A small businessman in search of a computer probably would not have a feel for these hardware requirements. However, in his search for hardware, he could ask computer vendors questions regarding the type of package he was thinking of installing and note the various answers. One certainly couldn't expect them all to be the same since sales people often have their own axe to grind in the form of commissions and the occasional need to move over-stocked merchandise. However, he should be able to get a general idea of the size and cost of the computer needed to run the type of software package he has in mind.

Even if a businessman purchases a computer that is too small, most likely, it could be expanded to meet the needs of a particular software package. The aim is to acquire a moderately-priced computer to run a moderate-size application. In the case of The Ross Company, an inexpensive computer costing $700 was obtained to run the invoicing system. Although the user, the full-time shipping clerk, was kept informed of the size of computer required and the plans for its purchase, he did not actually participate in the acquisition.

Purchasing too much computer for this project would be undesirable because excess capacity that will never be used is a waste. In addition, since prices on computers have continued to fall during the past ten years, there is reason to believe they will drop in the future. Computer capacity that is not purchased today, but purchased in the future, will cost less. That is the premise for purchasing a modest computer. Besides, two features that constitute its power, the memory and the hard drive, could be upgraded, if necessary, to accommodate an unexpectedly large invoicing package.

For the purposes of this study, only two major computer types were considered because they are proven business machines, not simply computers used in game playing. They are IBM and Apple. Apple's current mainstay in the market has excellent graphics capability and is easy to learn to use. A drawback with Apple computers is that, compared to IBM compatibles, they are more expensive. There are fewer outlets for them, and, as a result, fewer repair shops. There is less software available for Apple products, and modifying and upgrading them is not as easy as it is with IBM compatibles. Finally, the IBM compatible line is broader, with many more choices of computers, options, and peripherals.

Had The Ross Company already owned an Apple computer that could have been used for invoicing, then invoicing software for it would have been acquired and tested. Since there was no computer at the Company's site, the choice was an IBM compatible.

An option when considering modest cost computers is to buy new or used. Purchasing a used one is not a good idea for someone who is not familiar with computers for a couple of reasons. If the used computer is of older technology, it may be outdated, relatively low power, and less capable of being upgraded. Compatibility problems could result when trying to install software on an old computer. Older technology used monochrome monitors, but most software today can display pleasing colors. Older keyboards had fewer keys and no numeric keypad, and newer keyboards are incompatible with old technology computers, called "PC" (IBM's original 1981 model designation that stood for "personal computer") or "XT" (the mid-1980s improved design designation that represented "extended technology.")

A warranty is a good idea in the event the computer has teething problems following purchase, and used computers rarely carry more than a 90 day warranty on parts and labor. The warranty on new computers is often 90 days on parts and two years for labor, although warranties vary widely due to competition. It would be a comfort to have hardware support following purchase. No one in The Ross Company is familiar enough with computers to do any trouble shooting or repair, so a warranty would be valuable.

The newest technology computer of the IBM type is designated "AT," for "advanced technology." The chosen configuration included a color monitor, a mouse, a keyboard with a numeric key pad, and an extension cord with multiple electrical outlets and surge protection in case there are power fluctuations that could damage the computer.

The "AT" line constitutes a broad range of computers starting at 286 and going up to the Pentium P5 and P6 series. A computer sales person would be able to sort out the details for a businessman interested in buying one. However, it would be advisable to shop around and compare notes, just as when making an automobile purchase. For example, the purchaser would soon find that the 286 is obsolete. The 386 series is about to become obsolete, the 486 is current state-of-the art, and the Pentium is poised on the threshold to becoming the new de-facto standard. Ignoring the 286, prices for the 386 are very reasonable, yet the 386 is still a very capable machine, especially for running a relatively simple, stand-alone application such as invoicing.

To present some specifics about the computer obtained for The Ross Company, it is a generic IBM compatible (the name plate has the name of the computer store that assembled the components), has an Intel 80386SX central processing unit (CPU) chip on the main board (also called "mother board"), an oscillator speed of 33 MHZ, a 40 megabyte (MB) IDE (Integrated Drive Electronics) hard drive, a 1.44 MB floppy drive, and a 1.2 MB floppy drive.

The 80386SX CPU is the less powerful version of the 80386DX. Note that the "80" in the designation is usually dropped. The 80386SX central processing unit is a product of Intel Corporation, the world's largest manufacturer of CPUs. Even computers that do not use an Intel CPU are identified by the Intel designation because it presents a good measure of the power of a computer. (Intel elected to change the designation of the CPU that followed the 80486 from "80586" to "Pentium P5" so it could copyright the new name.)

When considering hard drives, the IDE type hard drive is a more modern drive than older drives manufactured a few years ago (RLL and MFM). The electronics have been miniaturized to an extent that much of the circuitry that used to be on the hard drive controller board is now mounted on the hard drive itself. This improves its performance because the drive no longer must communicate to the controller board for everything it does. Instead, many of its functions are managed by the electronics built right into it.

When considering the time lapse of sending a signal across a cable two feet long, having it decoded on the controller board, and then getting it sent back over the cable to the hard drive, it is apparent that there is a speed benefit if the hard drive has the control circuitry built right into it.

The access time of a hard drive is measured in milliseconds, and this particular computer came with a 17 millisecond hard drive. Currently, drives with a transfer rate of 12 milliseconds or less are available, but the extra cost for that speed isn't justified for this application.

A 40 MB hard drive was chosen because of its inexpensive price. A larger hard drive isn't necessary at this time because the DOS (disk operating system) requires less than ten megabytes, leaving plenty of room for the invoicing program.

The use of the Windows system is not contemplated at this time, but if it is needed, a larger hard drive will be acquired to accommodate it. Some computer software requires the Windows graphical user interface (GUI) and some requires only DOS. More modest, less expensive software requires only DOS to run, and it is anticipated that a modestly-priced package that has the necessary functionality will be available.

The computer has a fourteen inch (measured diagonally as with televisions) color VGA (video graphics adaptor) monitor with a 640 x 480 dot density. The pixels are .32 mm apart, providing a modestly-priced monitor that is readable. Monitors that are larger, have a greater dot density, and will display many more colors, even millions, are available, but the extra cost isn't justified for this application.

The electronics to run the floppy drives, the hard drive, the mouse, and the monitor reside on adapter boards that fit into the six slots on the main board. The video adapter board to control the monitor has a memory chip on it with a capacity of 256 kilobytes, enough to provide 16 colors and easy-to-read text on the screen. When the video adapter board is plugged into the main board, an opening in the back of the computer case exposes a plug to which the control cable from the monitor attaches. The computer has a parallel port for a printer, a serial port for a mouse, a game port to accommodate a joy stick for playing games, and an additional serial port for some other device, if needed.

Perusing computer magazines shows many mail-order companies that sell computers like this one, priced lower, but the support issue is important for The Ross Company. Local support is preferred because it would be difficult for Ross to operate if the computer had to be shipped somewhere for several days to be repaired.

The remaining component necessary to operate an invoicing application is a printer to print each invoice once the order has been entered. The selection of a printer is a different matter from selecting the computer. Printers are mechanical, and their compatibility is not a big concern because a ten-year old printer that attaches to the parallel port on an old-technology PC or XT computer will run on the newer technology AT computer.

The selected printer, a 9-pin dot matrix type, is nearly disposable because the cost of repair usually exceeds the cost to purchase a new one, especially if the print head requires replacement. The cost of a new print head, with the additional labor to install it, can exceed $200, the cost of a new dot matrix printer.

Printers come in several designs, depending on the type of print required (letters formed by dots or fully-formed characters like those produced by a typewriter), the speed at which it will print, and the width of the carriage (80 or 132 column). The most inexpensive printers are dot matrix types. There are nine-pin and twenty-four pin dot matrix printers, with the nine-pin units costing the least.

Nine-pin printers use a print head with a matrix of nine pins that are pushed through the head block by magnetic coils, striking the ribbon which leaves the imprint of the pins when the ribbon hits the paper. The configuration of the dots created by the pins forms the letters. The pins operate very fast so the head can move along the page as the pins move in and out, hammering the ribbon to make the images on the paper. A close look at the paper reveals the presence of the dots that form the letters.

The best paper to use in a dot matrix printer to print invoices is continuous form stock that is fed by pins fitting into holes on the edges of the paper. For an invoice, the use of a nine-pin dot matrix printer should be acceptable. A slow printer will be fine for The Ross Company because the invoices are not printed in high-volume.

Ink jet printers are more expensive. They don't use a ribbon. Instead, their print head uses tiny nozzles to spray ink on the page, eliminating the ribbon, but requiring ink refills. The print quality is better than that of dot matrix printers because the images are fully-formed characters.

Laser printers use the most advanced print technology, operating much like a copy machine. Cut paper is placed into the tray and the printer pulls the sheets into it, one at a time, transferring the image onto it by an electrostatic process. Laser printers are expensive, costing upward from $400. They do require the occasional addition of toner, usually by removing the old toner cartridge and replacing it with a new cartridge. A cartridge may be capable of printing more than 15,000 pages and the cost of a new toner cartridge can range from $40 to $200, depending on the printer and the number of copies that can be obtained from the cartridge. Some higher-priced cartridges contain some of the mechanical devices used to transport the paper through the printer.

For The Ross Company, a used nine-pin dot matrix printer is inexpensive, almost disposable, costs under $60, and should produce an acceptably readable invoice. If the need arises for a new printer in the future, that decision can be made later.

Acquisition of the Selected Software
There are several ways to acquire software just as there are several different types of software. Commercial software may be purchased from one of the large chain stores that carry computers, software, and other business equipment; from a store that specializes in software; and from mail order houses.

Shareware may be downloaded from a BBS (Bulletin Board System), purchased from a mall software shop, purchased by mail order from a shareware provider, bought from smaller computer shops, and obtained from individuals. Information about various software packages can be found by researching magazines, browsing software stores, and perusing direct mail brochures.

Commercial software is usually fully functional as purchased, unlike some shareware programs that are distributed as demonstration packages. Commercial programs normally cost more than shareware, partly because of marketing costs that shareware writers do not incur. Public domain software is free since its ownership has been given to everyone.

The approach used for this study was the acquisition of both commercial and shareware software. Each package was evaluated without regard to its source. Packages that did not meet the needs of the company were discarded.

The checks that need to be made at the time of purchase are two. The software must be specifically for invoicing. It should not be part of an integrated system consisting of several other applications that need to be installed simultaneously. This requirement helps keep the scope of the project narrowed to replacing the manual package, keeping the size of the effort reasonable.

The other check that should be made at purchase time is that the software is compatible with the company's computer, in the case of Ross, an IBM compatible. The software box usually indicates the minimum system requirements, specifying the such factors as the memory requirement, hard drive space, the DOS version, and monitor type.

Chapter 4

DATA ANALYSIS

Evaluation Criteria for the Selected Software Package

Selecting software requires a different approach from that used to select the hardware. First, to gather information on invoicing systems in use, some local companies were casually interviewed regarding their invoicing system. These systems ranged in complexity from a very simple type used to print a sales slip at the time of purchase to a full-blown integrated commercial software system by Peach Tree that consisted of all the major accounting functions, including invoicing. Because of its complexity, the Peach Tree user reported that it was difficult to learn.

These interviews confirmed the opinions of Mick (1984) and Shamlin (1989) that a simple system be chosen for the conversion of a manual, stand-alone system. The reasoning is that the first conversion should be basic in order to help insure the success of the project.

Shamlin (1989) provides a list of items that the selected software should meet. This list seems to represent the general requirements for The Ross Company. Each of Shamlin's items is followed by a comment about how it relates to Ross.

1. It should be easy to install.
   There are certainly excellent packages available that are difficult to install, but a package with this characteristic illustrates that it may not be written for a novice user or it has not been well designed. The package intended to replace a manual system, should be a simple package that emulates the manual system.


2. Getting it running should be easy.
   The comments observed above, in item 1, apply here. If it is difficult to get running, then it probably isn't a desirable package for Ross.


3. Menus should be available to guide the user.
   A package should be easy to use by a person unfamiliar with computers. This could be accomplished by making the program menu-driven so that the user could easily select functions. Menus eliminate the need to know specifically what keys to press to get into a function.


4. It should have a good data entry capability.
   The user should be able to operate the package without having to learn a lot of special key strokes or function keys. The necessity of a physical template taped to the keyboard to guide a user through a plethora of options is undesirable because it requires the user to divert his attention away from the screen. An example of a package that required the use of a template is WordPerfect, versions prior to 6.0. Version 6.0 dispensed with the obfuscating template, replacing it with on-screen options and pull-down menus, making it much easier to use.


5. The reports it generates should be sufficient.
   This is important, especially for packages that lack another means of retrieving data from the data files. Since a lot of information eventually resides in the files of a package, the ability to get to it is important. Not only should it be viewable on the screen, there should be a capability to print it. Useful information that might be provided by the reporting function of an invoicing system might include the following:


• A listing of the customers in the customer file.


• A listing of the items in the inventory file.


• A summary of items sold, by part number, for a user-specified period of time to analyze ordering history.


• Total sales, in dollars, for a user-selected period.


6. It should function like the manual system that it replaces.
   The program should emulate the manual system's invoice format that shows both the suggested retail price as well as the unit and extended item price the customer would have to pay Ross. This, then, would require three amount columns for each item shown on the invoice: Suggested Retail; Unit Cost; and Extended Unit Cost. The general format of the invoice should remain the same.
   
   The importance of this requirement is that some customers might not be pleased if the invoices began to appear different, and the learning curve for the Ross employees would be steep if the new system operated philosophically similar to the manual system.


7. It should have no weaknesses such as the requirement to use only special forms or a limited number of printers.
   Most weaknesses should be discovered during testing, including the need to purchase invoice forms from the software house. The question of printer limitations would not come up unless the company elected to change to a different printer and found that the package wouldn't support it.
   
   A severe problem should disqualify a package. The worst time to discover a failing is after the package is in use. Testing should be as thorough as possible, although it is nearly impossible to detect every possible negative aspect in a package. In cases where a severe fault is discovered later, the option to investigate a replacement package should be considered.


8. It should work smoothly and switch easily between functions.
   The package should be capable of updating the customer and inventory files "on the fly," during the invoicing function. This would make invoice creation a seamless operation.

Although other authors cited similar criteria, Shamlin's list seemed to be most closely applicable to small businesses, so it is covered in detail here.

Evaluating the Selected Application Software
Software evaluation is an important aspect of selecting a new software package. It must be proven that it meets the Company's needs as well as being acceptable to those users who will be assigned to operate the software.

For this study, the evaluation phase began with a review of the functionality of the original manual system that represented a benchmark against which to measure candidate software packages. Following the review of the manual system, a replacement software package was acquired and installed on the computer. A preliminary check was made to ensure that the package is compatible with the computer to make sure its disk and memory requirements did not exceed those of the computer. The Ross computer's disk capacity is 40 MB and the installed memory is one MB. If the software would operate with those limitations, then it was ready to be evaluated through user testing. If the software failed to operate smoothly or exhibited incompatible behavior, it was discarded, and the search for another package was begun.

User acceptance is the most critical part of the evaluation process because the user may disqualify the package at any time if it fails to satisfy his requirements.

Software evaluation is divided into two basic types: execution-based and non-execution techniques. The software house is responsible for non-execution program testing since the purchaser either does not receive the program source code and program specifications or does not posses the time and expertise to do it. The sole means of user verification, then, is execution testing. (Gianturco, 1994).

For the purposes of this study, path testing is the most suitable means of determining functionality of the selected program. The user tests the program by executing it and analyzing its performance based on how it processes input.

The first invoicing program was acquired and installed on the computer. Preliminary indications were that it provided fully-functional capabilities. The user began the evaluation by entering the invoicing mode and putting in a dummy invoice. The first problem that arose, since the customer file was empty, was that a customer had to be added for the test invoice to be created. To the regret of the user, the program's structure required the user to exit the invoice function altogether, enter the customer maintenance section of the application, and then enter the customer information.

After all the customer information had been added, the user had to exit the customer maintenance function and reenter the invoicing function. He had to locate the invoice he had been working on and then enter the customer name, which enabled the program to fill in the customer information.

The next step in the test was to create an invoice by entering the items ordered by the customer. For inventory items, the program operated in a like manner as it did for customer data. If an item was not on the program's inventory file, the user was required to exit the invoicing function, enter the inventory part of the program, and then enter the inventory items.

After the inventory items had been entered, the user had to return to the invoicing function and then begin entering the items. If an item was inadvertently left off of the inventory file, the user had to back out of the invoicing part and reiterate the process to get the item added to the inventory.

This was a time-consuming and inefficient process, but in defense of it, if a company had a list of inventory items that it could enter completely before using the program, then it would have been a satisfactory application. However, the user didn't want to enter all 25,000 items because it would be too large an effort, and not all 25,000 items would ever be ordered. The user decided that this package failed the evaluation because the interface between the invoicing and customer and inventory functions was not was not smooth.

The user needed a software package that allowed entry of customers and inventory items "on the fly." With this capability, the user could begin an invoice and temporarily go into the customer function to make an addition or change, then immediately switch back to the invoice with a minimum of keystrokes. The same capability was needed for inventory items. During the entry of items ordered by a customer, if an inventory item did not exist on the inventory file, then the user could instantly switch to the inventory file and add the missing item, then immediately switch back to the invoice, resulting in an efficient invoice entry process.

A week later, a second invoicing program was acquired through a local retail office supply store that was part of a nationwide chain. The cost of the package was $17. It was installed and the preliminary investigation began. Unfortunately, after the program was installed, it would not run, displaying a message indicating that the computer lacked sufficient memory.

This problem was with the software itself. Only the first 640 KB of the one MB memory is "executable," meaning that the extra memory is useful storage for an intelligently written program, but program instructions cannot be executed in the area above 640 KB. The computer was set up to use some additional operating features which are aids to operating the computer, but eat up some of the 640 KB of memory.

Although it would have been easy to cut out the few extra features to provide the full 640 KB of memory, it was decided that since the software utilized poor memory management, it was very likely to fall short in other areas. Besides, the company didn't want to have to give up additional features for the sake of an invoicing program. In the event a suitable invoicing package could not be found, it would be possible to return to this package to reevaluate it.

Modern, well-written programs are designed to manage computer memory so that they don't require the entire 640 KB. For example, WordPerfect version 6.1 requires 32 MB of disk space for installation, but to run, it requires less than 600 KB of memory. This is because the WordPerfect program manages the memory by loading in small parts of the word processing program, bringing in additional parts to overlay the first part, as needed. In this way, it is flexible enough to operate even if the available memory falls short of 640 KB.

The third program was purchased from another local retail software vendor that was part of a nationwide chain. The cost of this program was $32.00. The program passed the initial inspection and went into the testing phase. It soon became evident that this program had one insurmountable fault. It would not print a meaningful invoice on plain paper, requiring pre-printed forms that could be ordered from the software house. Although this might have been perceived by the software house as a clever marketing ploy that would bring in additional sales generated by forms purchases, the user was not impressed. He did not wish to be committed to purchasing pre-printed forms from a vendor whose life-expectancy was unknown, and for a cost that could escalate over a period of time.

Another factor that did not come to light at the time of the evaluation was whether forms could be purchased for laser printers as well as dot matrix printers. Also, the information that was provided by the software house did not indicate if the forms were multi-part or single sheet. In any case, the user rejected this package.

The user wanted to use white, stock paper and have the program print headings on each page. White, stock, continuous paper is inexpensive and readily available. Also, the program should be capable of printing multiple copies of each invoice to emulate the manual system that had used four parts.

The fourth program to be tested was shareware, obtained from a mail-order shareware vendor. Although shareware may not seem to be a likely source for a company's software system, historically, there have been some excellent shareware packages. Examples include Procomm, a superb communications package; PC-Write, an excellent, full-featured word processor; Wampum, an easy-to-use, menu-driven database program; and Medlin, a very capable accounting package.

Top-grade commercial software is often marketed as shareware, just to get the user interested in it. The price for the shareware diskette was a nominal $5 to cover duplication and shipping charges.

The shareware invoicing package is called "Invoice-It." This program was loaded onto the computer. Preliminary evaluation indicated it would run in the available memory. It is menu-driven with attractive screens. Browsing the menus showed that it can maintain the three major areas of an invoicing system: customer file, inventory file, and invoice file. In addition, it has a basic reporting module that provides some statistical reports. One example is a display of the total dollar amount that customers have ordered during a user-specified time period.

Evaluation proved that the program would allow the user to enter the invoicing function, then pop into the customer or inventory areas to add or change information, as necessary. In addition, the system was easy to use and provided clear menu selections, enabling the user to begin running it after only a few minutes of investigation.

Although this package was better than all of the previous programs tested, it wasn't perfect. It didn't allow for three amount fields. It only had room for unit cost and extended unit cost. There was not column for suggested retail price, a very useful item for customers to use to price the product for sale in their stores and to enable them to determine their gross profit margin: the difference between unit cost and the suggested retail price, assuming they planned to sell the item at the suggested retail price.

In the old manual system, the pre-printed four-part forms had three columns. However, the user, the shipping clerk, liked the package, and he wanted to make it work, if at all possible. He provided the idea of placing the suggested retail price in the item description line, to the far right, to look like this: LIST $XX.XX.

The user decided to use the word "List" on every item line because the invoicing program didn't have any means for allowing a user-defined heading. The plan was implemented and is a success. The line provides enough room for the item description as well as the list price. The shipping clerk began entering the list price whenever he added a line item, and he even positioned it so the word "list" would line up evenly in a column on the invoice, resulting in a neater look.

Another problem corrected by the user was that the quantity of each inventory had to be greater than zero or the item could not be ordered due to insufficient stock. Since inventory control was not intended to be used as part of the invoicing system, the user decided to enter all nines in the inventory quantity field. Each time an item was ordered, the inventory quantity was reduced by one. Eventually, the user will have to go into the inventory system and increase the quantity to all nines once again, but this will not be soon.

The user evaluation continued for another week, with no further problems. The used dot matrix printer had been installed so that invoices could be printed. Although it printed slowly, and did not provide letter-quality output due to the nine-pin print head, the user deemed the invoices satisfactory.

After two weeks of testing and loading inventory items and customers, the system was considered ready for live use, and the switch was made from manually typing invoices to entering them on the computer. The timing was opportune because the invoice typist retired two weeks after the system went live.

The user was sufficiently impressed with the package to order the commercial version of the software from the software house, Future Systems, for $39.00. Future Systems sent the latest version of the software and a guide booklet. The commercial version was the same as the shareware version with the exception that it was updated to include the latest refinements and new statistical reports. Also, the purchase provided free client support by the vendor, but toll-free calls to the Texas office were not provided.

After the cut over, the invoicing function was more time-consuming than typing would have been because, although many inventory items had been entered, nearly each order included several items that had not yet been entered and required the shipping clerk to add them during invoice creation. By the third week, the number of items that needed to be entered had dropped to one or two per invoice, and the invoicing process began to speed up.

With a total of 25,000 items that could be ordered, it was not practical to enter them all into the system. However, within a few weeks, all of the commonly ordered items had been entered on the computer, about 3,000.

The overall look of the invoices was much improved. Mistakes that had been manually corrected on the typewriter, were simply corrected on the computer and the invoice reprinted. With the manual system, the cost extension for each item was done using a calculator, and the invoices had to be double-checked because errors were not uncommon. The new system accomplished it automatically. Adding up the extended cost column was another potential source of errors, and, again, the computer eliminated mathematical anomalies.

After the automated system had been running four weeks, a new quarterly pricer was delivered. It contained a list of all 25,000 items, and the prices had changed for some of them. Fortunately, it is an easy task to check the items on the computer to those in the pricer because they are both in the same sequence: sorted by item number within manufacturer.

By bringing up the inventory file on the computer and opening the pricer to the same manufacturer, it is possible to simply go down the list in the pricer and look for items marked by an asterisk. An asterisk indicates that the item's price has changed. When an item with an asterisk is found, the corresponding item in the computer is adjusted by the user.

Three amounts have to be changed in the computer: the list price (in the description field), the cost to Ross (never printed on invoices and only printed on in-house reports), and the unit cost to the customer. The suggested list price and the cost to Ross are provided by the pricer. With a few exceptions, the cost to the customer is calculated at twenty percent over the cost to Ross.

So, every quarter, when a new pricer comes out, the computer inventory file has to be updated. This is much less of an effort than the requirement of the old, manual system, to look up the cost information for each item in each invoice. The correction to all inventory file prices can be accomplished over a period of several days.

Thirty days following the installation of the commercial version of the software, it crashed. A call to the vendor provided the answer to the problem. Each time the program was started, it had displayed a message suggesting that the program be registered. The user incorrectly assumed that this message could be ignored because registration was automatically accomplished through purchase of the software. What the message meant was that the user should go into the setup part of the program and enter the number printed on the software diskette. This is Future System's method of preventing a copy of the software from being illegally distributed. The number on the diskette was entered into the system and it returned to normal operation.

The system performed very well under the operation by the shipping clerk. He handles the invoicing system entirely by himself, takes orders over the phone and by fax, enters them into the computer, prints the invoices, and ships the orders.

As noted previously, the invoicing program provides the user the opportunity to select a number of copies to be printed. To emulate the old, manual system, the package was set up to print three copies of the invoice which are distributed as follows: one that is sent with the order shipment, one to the customer file, and one to be used for entering data into the accounts receivable system which is installed on the owner's home computer. The four-part forms used with the manual invoicing system provided a means to identify the distribution of each page. The white, original copy was sent to the customer with the shipment, the pink copy was filed in the customer file, and the yellow copy was used to enter the order information into the accounts receivable system. The canary copy was discarded except when an extra copy was needed for a drop shipment, in which case, it was sent with the order to the drop ship location.

Since the new system prints invoices on white paper, a means was needed to indicate the disposition of the file copy. The shipping clerk devised a solution. He ordered a rubber stamp, "FILE COPY." One of the three copies was stamped with "FILE COPY," and filed in the customer file. One copy was placed in the shipping container, and one was used to enter the accounts receivable information.

If a shipping copy is required for a drop-shipment, the program provides a shipping copy that omits all pricing information except for the list price quoted in the description field. This shipping copy can be requested just before the invoice is printed, or it can be printed after the three invoice copies have been printed.

With the old system, if a fifth copy was needed for any reason, or a replacement copy was needed to replace one that was lost or mutilated, an existing copy had to be copied on a copier. There were instances where the in-house copies were misplaced or lost. In such cases, there was not way to recover them. With the new system, extra copies may be printed any time they are needed.

The Impact of the New Invoicing Software on the Company
The Ross Company was able to operate with only one full-time employee instead of one full-time shipping clerk and a half-time typist. The cost of the computer and used laser printer, which ultimately replaced the dot matrix printer, was about $1000. Two-months of wage-savings, approximately six hundred dollars a month resulting from the retirement of the invoice typist, offset the cost of the computer system.

The use of plain paper in place of pre-printed four-part invoice forms resulted in an annual savings of approximately $150. Although there was an increase in electricity usage, it was not judged significant, especially considering that during the winter months, the elderly typist had used two electric heaters beneath her desk, which the shipping clerk did not need.

One change that saved time and money was the elimination of mathematical errors that sometimes occurred with the old system. The time required to produce an invoice was reduced. Approximately two minutes were required to look up the item cost in the pricer and then type it on the four-part form, using the old system. The new system requires about thirty seconds to key a line that has the item in the inventory file. Therefore, the estimated time savings for producing an invoice line with the new system is approximately one and a half minutes.

The time required to add an occasional inventory item onto the new system's inventory file is offset by the time savings provided by the automated calculation of the extended cost of an item and the addition of the unit cost and extended cost fields. The overall time required to key an invoice into the new system is one-third of that needed to type it in the old system. This time efficiency has allowed the shipping clerk to handle both the invoicing and the shipping functions by himself.

A non-monetary impact on the company is a much better-looking invoice. Customers have complemented the company on its clearer, more professional document.

Time Requirements for the Study
A discussion of the time required to accomplish the study is of interest because there should be some correlation to the time requirement for other small businesses to do a conversion of similar scope (See the chart in Appendix A).

The project began in early October with the search for a subject company. Of course, this part of the process is specific to only this study. The subject company was identified and an agreement in place by mid-December. The hardware selection process required the last two weeks of December, followed by hardware installation during the first week in January.

A software package was selected in mid-January. It was installed and tested shortly after acquisition, and this became a reiterative process as four packages are acquired, installed, and tested until the fourth one was deemed satisfactory by the user in late March. This process is shown by three, nearly parallel, lines on the chart in Appendix A, representing these concurrent activities.

Once the final package had been selected, the preliminary data had to be entered before going live. This consisted of the printer set-up procedure and entry of the company's primary customers. A few inventory items were already on the system because real items and prices had been used for test purposes. Additional items would be entered on the fly as invoices were created for customer orders. As mentioned earlier, it required several months until all of the commonly ordered items had been entered onto the Invoice-It database.

The entire length of the study required six months. For a similar conversion by another company, the project would be shorter by two months because the selection of a subject company would not be part of an actual conversion effort. The estimate for a small company to do a conversion like this one is four months, assuming it followed the approach described herein and converted a similar manual system.

Chapter 5

SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS

Uniqueness and Limitations of the Method

The method is unique in that instead of relying solely on literary sources, surveys, or a combination of both to prove or disprove the theory, a company was chosen to be the subject of the study. The theory that a small company could convert an application with little outside assistance was tested in a real-life situation.

This method does have a major limitation. What might be successful at one company may not work at another. In that respect, perhaps the selection of The Ross Company caused the outcome to be positive, and the selection of other companies might show negative results. If Ross is typical of small companies that are still using manual systems, then this approach could have wide applicability.

Another limitation of the method is that it addresses only one company instead of a group. It would be difficult to duplicate this particular study with several small companies. However, as described in the section on suggestions for further research, a two-part study beginning with a survey and following up with guidelines for converting a manual system.

Finally, this study method required intervention, evidenced by the presence of an observer who was doing the study. In quantum physics, the "uncertainty principle" states that the act of observing a system or event causes the results to change (Encyclopaedia Britannica, 1968). Although the study of human nature is far different from that of physics, the effect of the presence of an observer is a concern because it could change the outcome of a project such as the one undertaken in this study. The answer to this question shall have to await a future study that involves transference and the success of a company to convert an application by itself without the presence of an observer.

Conclusions Related to User Involvement
One common theme that was stated by several authors was the importance of involving employees who would actually work with the system after its installation. The authors agreed that without giving them knowledge about the project and letting them participate in it, users would not readily take ownership, and, instead, might allow the system to fail or run at a low level of effectiveness. This theme was tested by having the shipping clerk, the person who would actually be responsible for running the system after it was live, to install, select, and test the invoicing system.

The first invoicing program selected for testing was installed on the computer by the user after he read the accompanying instructions. Then, when he had a half hour or so available, he started the invoicing system. With his knowledge of the manual system, he noted potential problem areas and thought of ways around the problems. The first three systems chosen for analysis were not successful in meeting Ross' needs. The fourth wasn't perfect, but a modification to the way inventory is entered solved the problem. The shipping clerk suggested it and tested the idea on the computer to insure that it would work.

It could be argued that he elected to use the system out of self-defense because he didn't have time to type the invoices, but the situation during the first few weeks indicates that although he didn't like typing invoices, the new system required that he spend more time with it than he would have typing them. For the first few weeks, he had to learn the new system, and when he keyed an invoice into the computer, he had to put in everything, the same as he would have had to do typing on the typewriter.

The user recognized that he would only have to enter a customer's mailing and shipping addresses once. Thereafter when he needed to create an invoice for that customer, he needed only to press a few keys and it would pop up on the screen, ready for him to enter the items ordered.

The same was true for inventory items. He had to learn how to enter them, and then enter each one according to the way the system would work best. Entering an invoice item into the computer took much longer than it would have had he typed it because the entry required more fields to be keyed. These included item cost to Ross, the number of items in inventory, the manufacturer, and the supplier.

However, like the customer addresses, inventory items needed to be entered only once. After that, they were still there, ready to be pulled up the next time a customer placed an order for them.

To further substantiate the idea that the shipping clerk had taken ownership of the system, in his spare moments he would sit down at the computer and actually enter inventory items from the catalog that had not been ordered, but that he knew were ordered frequently. In this way, he was spending the time to enter them before they actually needed to be put in. The result is that he was accelerating the development and functionality of the system.

As had occurred in Feynman's (1985) experience in the Los Alamos computer lab during World War II, the shipping clerk required no supervision for running the computer system. Not only did he make sure data was entered accurately, he also decided to take responsibility for the hardware. He learned to adjust the dot matrix printer to provide the best clarity, and he replaced the ribbon whenever it became worn. When the excess toner hopper filled up in a the laser printer that replaced the dot matrix printer, he read the manual and found out how to open up the printer and empty it. The shipping clerk was able to integrate the invoicing function into his own schedule and soon was comfortable doing both jobs.

The conclusion is that by involving the user, he became the principal supporter of the new system and worked hard to insure its success. It would be incorrect to assume that this approach would work for every small business because too many variables are involved. Companies and the people and systems that are in them differ. The experience at Ross could be an indicator that it is possible to get employees in a small company to convert to automated systems.

Conclusions Related to Package Selection
Choosing a relatively simple, single-purpose system for converting a manual system was another common theme discussed by several authors. The basis for this philosophy is that for conversion from a manual system, the new system is probably not going to be the last, and trying to convert to a complex system is likely to bog down a first-time conversion effort, putting the project in jeopardy. The change from a manual system to an automated one is usually a difficult task for a small company that lacks extensive computer expertise. Also, because the change between the manual and automated systems will be dramatic, a company should have the opportunity to get used to the change and integrate its methodology into company operations before considering a complex package that might be much more difficult to install and run.

This study showed that by taking a conservative approach to upgrading one manual system to a stand-alone computer-based system, the user was able to successfully do the installation, testing, and eventual implementation of the selected software. This plan could be followed by more challenging conversions in the future, using knowledge learned by this first conversion as a basis.

Limitations of Program Capabilities
Although the selected invoicing program meets the basic requirements of emulating the functions of the manual system, a month following implementation, further capabilities were investigated. A labor-intensive operation still carried on in the company is the collection of copies of the invoices created by the new invoicing program followed by the entry of them into the accounts receivable system on the owner's home computer.

The owner runs the accounts receivable system from his home because that allows him to work on it during evenings and weekends. This operation requires the owner to collect a copy of each invoice, take the copies home, enter them into his accounts receivable system, print the statements, stuff the statements into window envelopes, and mail them.

The shipping clerk recognized that the invoicing system has a statement printing capability built in. However, tests of it showed that it was only capable of applying the exact amount of payment to one invoice. The Ross Company's customers send payments that cover one or more invoices, and the amount they send often does not exactly equal that of a number of invoices. The owner's accounts receivable system, a shareware package called Medlin, accommodates the receipt of any amount and carries the remainder until the next payment is received. It is suitable for The Ross Company's needs, but it doesn't interface with the Invoice-It invoicing system, hence, the need to enter invoice amounts manually. Medlin does not have an invoicing system built into it. It is an accounting package that is directed toward accounting functions such as accounts receivable, accounts payable, fixed assets, and general ledger.

The best situation for The Ross Company would be to have an invoicing system that interfaced directly to an accounts receivable system. Upon receipt of a check, entering the name of the company would bring up an option to enter the amount. The program would apply the amount of the check to the oldest invoice. If the invoice amount were larger than the check, the program could determine how the user would wish to apply uneven amounts: either partially to an invoice with a larger amount or disregard the invoice and check subsequent invoices. After applying amounts to invoice amounts smaller than the original and resultant residual amounts, any remaining balance from the original check would be held, to be added to the next check received. A report noting partially or wholly unpaid invoices would be created, along with statements to be sent to customers.

The illustration of the lack of interface to another system is presented here to show that an information system decision, in this case, the selection of a computer-based invoicing system to replace the manual system, did not meet all invoicing, payment, and billing needs. This is not an untenable situation, however. The positive aspect is that the implementation of the invoicing system was successful, and that was the desired outcome.

A new invoicing system with a built-in accounts receivable system or a satisfactory interface to an external accounts receivable system would solve the problem of having to manually reenter the invoice information into an accounts receivable system. This means that a new invoicing system that accommodates receivables eventually may be selected. The necessity to do this is not immediate. The invoicing system has reduced the company overhead. To further reduce the overhead by eliminating the need to manually enter invoice data into the accounts receivable system requires a different approach, one that is beyond the scope of this study. It is discussed herein to present the reality of information system challenges.

Suggestions for System Enhancement
At some time in the future, it is expected that the selected software may not be able to adapt to new requirements. This should be an anticipated part of system evolution, and it will require decisions. The options would include some of the following.

First, the selected software may be left as-is, for the near-term, with no further enhancements. This may be a good solution. The new software has achieved the desired results. Further improvements may not be possible without changing to a different software package.

Second, an entirely new software package could be selected with more functionality than the first. The knowledge acquired from the experience getting the first package going may result in changed or expanded system requirements. By selecting a new package based on these new parameters, the existing system could be replaced.

There are many other possibilities, but they would be expensive. For example, a consultant could be hired to write a system that would be acceptable. Or, the consultant could write an interface between the existing invoicing system and a new accounts payable system.

Although the implementation of the invoice system has been successful, the shipping clerk must still manually type shipping labels for each order. The shipping clerk suggested that automating this function could further reduce the time required to assemble an order for shipment.

Currently, the shipping clerk must pull a blank, two and one-half inch by three and one half inch, standard-form, glue-backed shipping label from a pad. The company's return address is placed on it using a rubber stamp. Then it is inserted into the typewriter. The shipping address is typed onto the label by referring to the shipping address on the invoice.

The implementation of an automated print facility for shipping labels should enable one label to be printed at a time. Since the existing laser printer won't accommodate forms the size of a single label, a multi-label form wouldn't provide for printing one form at a time, and changing paper in the laser printer would require extra time, a dedicated, inexpensive dot matrix printer would be the best choice for printing shipping labels.

The preferred label stock for printing in a dot matrix printer would be a one-up continuous form that could be torn off the printer after one was printed. The label would be large enough to allow printing of the Ross's return address followed by the customer's shipping address. Although printing the return address each time might be considered a waste, it would allow for the purchase of generic, inexpensive labels that would not require the return address to be pre-printed on them.

The invoicing program does have the option to print the customer's shipping address, but it is designed to use only one specific label size, one by three and one half inches. This small a label would not have room for a return address, even if the invoicing program could print it. However, a solution to the problem could be to use the rubber stamp on the box or on another label that could be applied above the customer's shipping address label.

Both printers could be connected to the computer's single parallel port through a print select switch. This switch could be a cause of inconvenience if it were left in the wrong position when printing. The result could be printing a label on the plain paper in the laser printer or printing an invoice on the continuous-form mailing labels loaded in the dot matrix printer. However, this problem would become rare with increased experience.

Another option would be to install a second parallel printer port in the computer and configure it as "LPT2." In this manner, the label print program could direct labels to LPT2 and the invoicing program could send invoices to the current printer port, LPT1.

The easiest approach to printing shipping labels seems to be to print them from the invoicing program and use a separate, pre-printed label or a rubber stamp for the return address. By using the large labels that are currently available, stamping them with the Ross return address as is currently done, and affixing the smaller, invoice-printed label across the "ship to" portion of it, might provide the easiest solution. This would eliminate the need to manually type each shipping label, but it wouldn't reduce the current workload in a significant way since the average number of shipping labels used each day is ten to fifteen. On the positive side, the automated labels would be consistent in their content with no typing errors or corrections, and they would look more professional. The current shipping labels sometimes give the impression that the shipments are coming out of a "ma and pa" operation (which they are).

The other areas that could be computerized are inventory control, general ledger, fixed assets, and accounts payable. They could streamline the financial tracking and reporting systems, especially if a large, integrated package were installed.

Transference of this Approach to Other Businesses
Because this study has shown that a small company can utilize its own personnel to bring up a new computer application to replace a manual system, the suggestion is that other small companies might be able to do the same. A future study could prove that supposition. (See "Recommendations For Further Research.")

The method used to transfer this information to other businesses is a problem for further research. However, by following some simple guidelines developed in this study, a small company should be able to analyze its current manual applications to determine if one is a candidate for conversion. If one is found, then the steps taken herein can be a general guide for accomplishing the project.

Applicability for other businesses is one thing. Actually transferring that knowledge is quite another. Some businesses would be able to accomplish such a project, but others would not. Although small businesses have a lot in common, each one has slightly different ways of operating, different philosophies, and these differences may make the use of a generic software package impossible. In cases like this, the company may have to resort to hiring a professional software developer to obtain a custom package suitable for its operations. Such an approach is outside the scope of this study.

The point made by this study is that for simple applications, transferability seems very likely, but the proof of that will have to wait for a future study. However, a scenario that might work is described below.

After a candidate company that might benefit from converting a manual application to a computer has been identified, an attempt to transfer the knowledge developed in this study could proceed.

The transference could take place using a cookbook approach, to be accomplished by the manager of the subject company or someone he assigns, as follows:

1. Write down the primary functions being accomplished in the company. First, review the duties of each employee, including those of the company manager, and create a list of each employee's major duties with a corresponding estimate of the average daily hours spent on each task. For example, the list might look like Table 1.
   
   
   • Table 1
   • Employee's Tasks List
   • EMPLOYEE
   • Manager - TASK: Payroll; AVERAGE HOURS PER DAY: 2
   • Manager - TASK: Reconcile Accounts Receivable and Accounts Payable; AVERAGE HOURS PER DAY: 2
   • Julie - TASK: Wait on Walk-In Customers; AVERAGE HOURS PER DAY: 1
   • Julie - TASK: Take Phone Orders; AVERAGE HOURS PER DAY: 2
   • Julie - TASK: Type Invoices; AVERAGE HOURS PER DAY: 3
   • Matt - TASK: Pick (pull items from Inventory), Pack, and Ship Orders; AVERAGE HOURS PER DAY: 5
   • Manager - TASK: Pay Bills; AVERAGE HOURS PER DAY: 1/2
   • Matt - TASK: Inventory Control; AVERAGE HOURS PER DAY: 1
2. Now reduce the list to the tasks that are most likely to be accomplished by a computer. Matt's picking, packing, and shipping task requires manual labor that couldn't be replicated by a computer using today's technology. The same is true for Julie's duty of waiting on customers and taking phone orders. These two items should be crossed off of the list because they could not be automated on a computer.


3. The remaining items can be prioritized by their potential for benefiting the company if they are converted to a computer. Those that would provide the most benefit go to the top of the list. Those that would benefit it the least go to the bottom of the list. One way to prioritize the remaining items is by using the average number of hours per day the employees spend doing each task. The activity that requires the most time each day could provide the most benefit if converted from a manual system to a computer. The prioritized list might look like Table 2.
   
   • Table 2
   • Employee's Tasks by Hours
   • EMPLOYEE: Julie - Task: Type Invoices; AVERAGE HOURS PER DAY: 3
   • EMPLOYEE: Manager - Task: Payroll; AVERAGE HOURS PER DAY: 2
   • EMPLOYEE: Manager - Task: Reconcile Accounts Receivable and Accounts Payable; AVERAGE HOURS PER DAY: 2
   • EMPLOYEE: Matt - Task: Inventory Control; AVERAGE HOURS PER DAY: 1
   • EMPLOYEE: Manager - Task: Pay Bills; AVERAGE HOURS PER DAY: 1/2
   
   Although there are other methods of determining which manual system could provide the most benefit if automated, the average number of hours per day was used in this example. The table shows that the invoicing function would provide the most benefit. Automating any of the other functions might be helpful, too, but converting them wouldn't have as much impact as automating the invoicing system, based on the number of hours required to do each task.


4. The next step would be for the manager to meet with the invoicing system user (Julie) and discuss the possibility of converting the system to a computer. Getting her support in such a project is a key item and could mean the difference between success and failure of the conversion effort. The manager could address the idea of converting by bringing up the possibility that it would help Julie do her work and provide the company with better information.
   Depending on the relationship between the manager and Julie, the conversation could be tailored to elicit ideas from Julie to get her involved in the decision-making process. This is the first step to her taking ownership for the computer project and, ultimately, the new invoicing system. The process of involving the user might be best accomplished by spreading it over a period of a few weeks with a couple of discussions with her each week.
   Several important aspects of the planned conversion should be addressed. Julie would need to be assured that her job was not in jeopardy; that her position was more important than ever. She would need to feel like a key member of the team.


5. Once Julie had emerged as a member of the team (even though the team may consist of only the manager and her), the details of the plan should be unfolded for her. The plan is basic: to find a representative package, install it on a computer, and test it to determine if it will meet the company's needs. It would be hoped that the user, Julie in this scenario, would take a major responsibility in the project, helping make the selection, doing the computer installation by following the instructions provided with the software, and then running the package by keying in representative data and analyzing the results and the performance of the package. Her job may have to be adjusted so that she has sufficient time to work on the project.
   
   The manager must keep himself informed of the progress and findings so that he may help guide the project. His input regarding the acceptability of a package is very important because he represents the philosophy of the company.
   
   This may be a reiterative process if the first package fails to live up to the expectations of the company. It may have to be removed from the system and another package selected and installed for testing. This circular process may continue until a satisfactory package is found or it is decided that no computer package will achieve the desired results and the manual system will have to be continued.

Future Conversion Considerations
When the decision is made to convert the computer-based package to another application package, the approach to converting depends on the design characteristics of the old and new programs.

Some applications, particularly fully-functional word processors, have a built-in conversion capability that allows the user to select the name of the package that originally created the file, and it is converted from the old format to the new.

If an invoicing program were discovered that could read the files created by the current Invoice-It invoicing program and convert the data to its own format, that would solve the problem of how to get the information from the old system to the new. It is unlikely that such a system exists for several reasons. There are many different invoicing programs and not any that have captured enough of the market that competitive pressure requires them to provide conversion utilities for competing systems. Unlike competing word processing systems that often have a need to pass text files between themselves, invoicing programs do not have this capability.

Another approach to converting data where the old and new packages lack any conversion ability or don't share common file formats is the method of programmatically extracting the data from the old system files and then feeding it into the new system's files. The problem with this approach is that it requires a deep knowledge of computers. Since the assumption of this study is that company employees have little computer knowledge, this method is eliminated as a viable solution. Of course, a consultant could be called upon to provide the necessary technical expertise to convert the data, but this would be expensive, and another assumption of this study is that the company's cash flow won't accommodate such an expenditure.

A fourth approach is the simplest, but the most time-consuming. The user prints the contents of the old system then keys the data into the new system. In the best scenario, the specific data requirements in both systems would be similar, if not identical, requiring little or no modification or addition to the data in the old system prior to entering it into the new system. In a less desirable framework, the data in the old system would have little compatibility to the data requirements of the new system. In a case such as this, the old data must be modified and often supplemented by additional data before being entered into the new system.

A worst-case scenario is where the data in the old system isn't easily printed. Such a system might provide a good screen presentation of the data, but it might not be capable of spitting out all of the data to the printer. In any case, the framework of this study didn't investigate the problem of converting from one computer system to another. This discussion was deemed valuable to provide insight into possible situations that might be presented during the system life cycle.

Recommendations for Further Research
One limitation of this study is that only one company was the subject. Further research could be aimed at a large population of small companies. By some method, perhaps interviews or questionnaires, a group of small companies could be investigated to determine those that might be candidates for implementation of a computer system.

The approach could begin by contacting small companies across a given geographic area, such as a state, group of states, or, perhaps the entire country. Or businesses of a certain type could be contacted. Mailing lists for businesses are available from list sellers shown in the Yellow Pages. The target companies could be reduced to a manageable size by culling those that were less likely to be in the target groupings. For example, the study could target dry cleaning establishments grossing less than $300,000 per year.

Using the final list, the selected companies could be sent a questionnaire that would attempt to determine if the company already had a computer. It could ask if the company had any manual systems that might be candidates for converting to an automated system. The development of the questionnaire would be a critical item in the study. Not only would it have to be designed to increase the likelihood of receiving a response, but it would have to ask the right questions so that valid conclusions could be drawn.

A generalized approach to computer solutions could be drawn up. Each group of companies that might be assisted by one of the generalized solutions could be mailed an info packet.

• First, they could receive a note thanking them for their participation in the survey and the results of the survey showing all the company groupings, with their own group highlighted. The statistical analysis probably shouldn't include specific company information such as name, address, or phone number for privacy reasons.


• Second, each respondent could receive a guide to the actions they might take to convert a manual information system. This information could be in a report format that would be a "free," unsolicited guide that the recipients could accept or reject.

The interest to the researcher would be the survey information provided by the companies. Of interest would be the percentage of types of companies that have computers and those that don't. It would be valuable to know the types of applications in use, the models of computers used, etc.

For example, information derived from the questionnaire could possibly answer some of these questions:

1. Does your company use a computer? _____________


2. How many computers are in use? ________________


3. What model computers are in use? (please be as specific as possible): __________________________________


4. CPU type: _____________________________________


5. Number of monitor displays is in use:


6. Number of Hard Disk Drives: ___________________


7. Please list the applications you run on your computers:


• general ledger ______________


• accounts payable ____________


• accounts receivable _________


• inventory ___________________


• fixed assets ________________


• invoicing ___________________


• Spreadsheet _________________


• Word Processing _____________


• Others: _____________________


8. Please list the applications you do manually:


• general ledger ______________


• accounts payable ____________


• accounts receivable _________


• inventory ___________________


• fixed assets ________________


• invoicing ___________________


• Spreadsheet _________________


• Word Processing _____________


• Others: _____________________


9. In what State is your company located? _________________


10. Comments: ______________________________________

Questions such as these could form an interesting group of statistics that could be manipulated in various ways to draw conclusions based on many factors such as geographic, computer type, computer applications, and manual applications, to name a few.

A subsequent study could arrange to send another survey to the original group of companies requesting information on whether or not the company attempted to convert a manual system and the results of that attempt.

Summary
It is hoped that this study will add to the body of knowledge in such a manner that companies, like The Ross Company, will be empowered to improve their operations, where feasible, through their own initiative, by moving away from manual systems to more efficient computer solutions.

The success of this study relied upon the involvement of this author. However, an attempt was made to guide the user toward implementing the computer system in a straight-forward, simplistic manner that could be followed by most persons with a minimal knowledge of computers.

One fact that stands in the way of many companies converting to a computer is that the owner or manager in charge often may lack the necessary experience to know where to begin. This situation will probably change as future generations who are now learning about computers in school and at home enter the work force. At the present, studies like this may be the catalysts to give the older generation managers the knowledge and confidence they need to get started.

This study was undertaken to determine if a manual system could be automated by the staff of a small company. It was determined that this is possible. To accomplish this objective, the user, the shipping clerk, was encouraged to become involved with the project from the beginning, as soon as the prospect of converting to an automated system was suggested. Although he was not computer literate, he managed to install and test various packages using the instructions supplied with each package. In addition, a single application was selected for conversion instead of an integrated group of packages.

When a package was obtained that he had difficulty loading onto the computer, it was discarded for the reason that if it required a high degree of technical computer expertise to install, then a lot of expertise would probably be required to run it. If the instructions were not clear, the package was discarded.

The shipping clerk's involvement reached a level where he was knowledgeable and interested enough in the success of the project to suggest a way that the operating procedure could be changed to make it work like the manual system.

Additional factors that will affect the outcome of a computer-related project are the differences between various small companies. These differences will determine, to some extent, the success or failure of a conversion effort. Some companies might achieve success and some might not.

Differences could include such things as management style, the attitude of the employees, the type of business the company is involved in, the financial strength of the company, the interest of the management to improve information systems, and management's attitude toward computers, to name a few. The study of these factors might be the subject of future studies.

REFERENCES

• Balzer, R. (1989). A fifteen-year perspective on automatic programming. In T. J. Biggerstaff & A. J. Perlis (Eds.), Software reusability, Volume II, Applications and experience, (pp. 289-311). New York: ACM Press.
• Beizer, B. (1984). Software system testing and quality assurance. New York: Van Nostrand Reinhold.
• Bentley, T. J. (1984). The computer: past, present, and future. London: Macmillan Press.
• Breslin, J. (1986). Selecting and installing software packages. Westport: Greenwood Press.
• Chorafas, D. N. (1982). Office automation: The productivity challenge. Englewood Cliffs: Prentice-Hall.
• Claus, V. & Schwill, A. (1992). Encyclopaedia of information technology. New York: Ellis Horwood.
• Coffee, P. (1994, October). Real-world trends now favor X86 development. PC Week, p. 36.
• Connell, J. L., & Shafer, L. (1987). The professional user's guide to acquiring software. New York: Van Nostrand Reinhold.
• Dickinson, J. (1992, November). Radical shifts afoot in software distribution. Computer Shopper, p. 62.
• Dodge, J. (1994, October). PowerPC, Mac OS, PreP: Where do IBM, Apple go from here? PC Week, p. 1.
• Feynman, R. P. (1985). Surely you're joking, Mr. Feynman!. New York: Norton.
• Forkner, I. & McLeod, R. (1973). Computerized business systems. New York: Wiley.
• Gianturco, M. D. (1994, August). Testing techniques for quality software. Software Development. p. 45.
• Glass, R. (1990). Software conflict: essays on the art and science of software engineering. Englewood Cliffs: Prentice-Hall.
• Goodell, M. (1989). What business programs do: Recurring functions in a sample of commercial applications. In T. J. Biggerstaff & A. J. Perlis (Eds.), Software reusability, Volume II, Applications and experience, (pp. 197-211). New York: ACM Press.
• Hollander, N. (1992, October). Selecting software. Software Magazine, p. 6. IBM's Chief: Stranger in a Strange Land. (1995, February 2). Rocky Mountain News. P. 17.
• Management evaluation of software packages. (1985). Port Jefferson: Chantico Publishing Company.
• Meyer, B. (1989). Reusability: The case for object-oriented design. In T. J. Biggerstaff & A. J. Perlis (Eds.), Software reusability, Volume II, Applications and experience, (pp. 1-33). New York: ACM Press.
• Mick, C. K. (1984). Working smart. New York: Macmillan.
• Nixon, J. (1990). Software for farmers in the United Kingdom. In W. Ehrenberger (Ed.), Approving software products, (p. 343). Amsterdam: Elsevier Science Publishers.
• Sachs, J. (1984). Your IBM pc made easy. Berkeley: McGraw-Hill.
• Seymour, J. (1992, March). Don't underestimate the pc kitchen cabinet. PC Week, p. 81.
• Seymour, J. (1994, November). Can CardBus save the bacon for PCMCIA? PC Week, p. 48.
• Shamlin, C. (1989). The other side of software (2nd ed.). New York: AMACOM.
• Sharland, R. (1991). Package evaluation. Aldershot: Avebury Technical.
• Smith, J. & Tweney, D. (1992, February). Accounting software 101. PC-Computing, p. 252.
• Spears, G. (1995, June). Big ideas for a little money. Kiplinger's personal finance magazine, P. 46.
• Stagner, W. (1988). Cloning around: A guide to pc compatibles. Chesterland: Weber Systems.
• Sullivan, N. (1991). Computer power for your small business. New York: AMACOM.
• "Uncertainty Principle." Encyclopaedia Britannica. 1968 ed.