Volume 1, Article 13
             March 1999
 
 
 
 
OPINION

A GENERAL, YET USEFUL THEORY OF INFORMATION SYSTEMS

Steven Alter
McLaren School of Business
University of San Francisco
San Francisco, CA 94117, USA
alter@usfca.edu
 
 
 

ABSTRACT

This paper proposes a general, yet useful theory of information systems. It is a response to repeated lamentations and debates about whether it is possible to find a set of core concepts for the IS field. Business and IT professionals can apply this theory for understanding and analyzing information systems. Academic researchers can apply it for gaining a deeper appreciation of past research and for developing future research projects. This theory tries to be equally applicable to all information systems, and not just to a particular type of application such as TPS, MIS, DSS, EIS, GSS, or ERP. It also tries to be equally applicable to information systems of today, of 20 years ago, and of the near term future.

Keywords: information system, work system, roles of information systems, impact of information systems, information technology, system theory, systems analysis, project management, plumbing vs. content in information systems
 
 

I. INTRODUCTION
Almost every ICIS and AIS meeting seems to have at least one panel discussion or debate about whether information systems is actually a field of study and if so, what might be its core. IFIP Working Group 8.1 devoted an entire 1995 conference to the topic "Information System Concepts: Toward a Consolidation of Views," [Falkenberg et al, 1995] but rather little consolidation seemed to occur. The call for contributions to the December, 1998 IFIP 8.2 and 8.6 conference in Helsinki (just prior to the Helsinki ICIS) noted that "practical as well as theoretical conceptual frameworks aimed at integrating diverse aspects of IS/IT change effects are rare. The field is very fragmented. Therefore, the advancement of integrated practical views and theories of a holistic nature are needed." It asked "how can we make theory practical and practice generalisable?" [Larsen, T. J. et al, 1998]

This paper is directed toward to the academic IS community and tries to address the IFIP challenge directly. It proposes a general, yet useful theory of information systems. Business and IT professionals can apply this theory for understanding and analyzing information systems. Academic researchers can apply it for gaining a deeper appreciation of past research and for developing future research projects. This theory tries to be equally applicable to all information systems, and not just to a particular type of application such as TPS, MIS, DSS, EIS, GSS, or ERP. It also tries to be equally applicable to information systems of today, of 20 years ago, and of the near term future.

Undergraduate and MBA students have applied various versions of the underlying ideas for over five years. Much of this material is presented in different pedagogical form and in more detail in an information system textbook [Alter, 1999]. The same ideas are being explained in yet another form in a currently unnamed professional book that provides guidelines for business professionals trying to make sense of systems in their organizations.

Churchman, Mumford, Checkland, Markus, and many others have discussed aspects of this topic [Churchman, 1979], [Mumford & Weir, 1979], [Checkland & Scholes, 1990], [Markus, 1984], and their ideas surely influenced parts of this paper in one way or another. Despite this, the most direct source for the ideas presented here is my informal, trial-and-error effort over the course of many years to develop a systems analysis technique business professionals can use for understanding the systems they encounter and for thinking about the claims of software vendors and IT staff members. If the proposed theory turns out to be useful, it is will be important for some future version of this paper to indicate where others have expressed similar and contrasting ideas even though a meaningful set of contrasts would require a lot of explaining.

This paper starts by identifying criteria for a useful theory of information systems. It then presents a highly condensed summary of the theory in the form of 14 main points. Next it presents additional definitions, distinctions, and implications related to each of the 14 points. The paper ends by asking the reader to validate the theory’s usefulness by seeing whether it provides useful insights when applied to familiar systems or empirical research studies.

Readers should approach this paper skeptically and should ask themselves whether the ideas presented here could be expressed more effectively, whether they ignore essential issues, and, alas, whether they are off the mark altogether. This paper is only about proposing a general, but useful theory, and avoids longstanding debates about reference disciplines for the IS field and academic jurisdiction over different parts of the field.
 
 

II. CRITERIA FOR EVALUATING THE THEORY

A panel chaired by Michael Myers at the 1998 IFIP WG 8.1 addressed issues about IS theories and frameworks in several ways. The panel topic was "Practical and Theoretical Frameworks: Valuable Aids or Seductive Traps" [Myers et al, 1998]. Each participant spoke from a different, pre-assigned viewpoint. Dan Robey argued that "simple theories and simple frameworks can be dangerous guides to practice, and complex theories will probably be ignored or misunderstood. A useful theory strikes a balance between being simple and complex." Chris Sauer argued that "theory is actually of little value to practitioners" for two reasons. "First, social phenomena are not readily theorized" [because they differ from more predictable natural phenomena] and second, in the world of IS things change "so rapidly that even if we had good theories they would be outdated before completion." Geoff Walsham noted that "theoretical frameworks such as actor-network theory or structuration theory can be valuable sensitizing devices for the researcher or practitioner, but they clearly do not provide simple prescriptive guides to action, and there remains a challenge for academics to make the conceptual ideas and insights in these theories more accessible to thoughtful practitioners."

In effect, the panel was debating whether it is currently possible to produce a rigorous but understandable theory of information systems. Instead of joining that discussion, this paper tries to present a proof by example. It does this by proposing a theory that tries to be understandable, comprehensive, and useful while also providing a basis for in-depth analysis.
 

Understandable

The theory should be expressed in terms of words most business and IT professionals understand. For example, the theory might use the words user and participant, but not the word actor. Similarly, it might use technology and infrastructure, but not instantiation, structuration, and metamodel (despite the usefulness of such terms in communicating with specialists and researchers).
 

Comprehensive

The theory should say something meaningful about almost any information system, regardless of what type of information system is being analyzed and regardless of whether the organization is large or small. For example, although the theory might be applied to an information system that supports decision making, decision making per se should not be the central focus of the theory because many information systems are primarily about enforcing rules for processing data (e.g., transaction processing systems) or about conveniently storing and disseminating information (e.g., intranets). Similarly, the central issue should not be human-computer interaction if the theory is to cover information systems in which human-computer interaction is relatively unimportant compared to other factors, such as whether information system usage is a mandatory part of the work. Likewise, cybernetic feedback concepts should not be a central focus if the theory is to cover information systems that provide managers general information about the external business environment (which they cannot control) or that serve a knowledge management function by directing business professionals to the right people or documents.
 

Useful

The theory should help business and IT professionals observe and interpret the implementation and operation of specific information systems in organizations. It should provide practical help in activities such as:


IV. DEFINITIONS, DISTINCTIONS, AND IMPLICATIONS

This section extends each of the 14 points in the condensed summary of the theory. It defines many terms in more detail, identifies useful distinctions that may not be obvious, and identifies a number of implications and questions that the theory raises.
 

1. DEFINITION OF WORK SYSTEM

A work system is a system in which human participants and/or machines perform a business process using information, technology, and other resources to produce products (and/or services) for internal or external customers. Work systems may exist and produce their outputs over extended time spans or may be created as temporary systems (projects) designed to produce a particular output and then dissolve.

Most work systems can be subdivided into a set of smaller work systems. For example, one might consider an entire value chain as a work system, or might consider individual steps of a value chain as separate work systems. The choice of how to define the work system under consideration depends on the problem and the analyst.

The term work system is a fundamental concept for the theory presented here. The theory implicitly claims that the operation and significance of an information system is best understood in terms of the work system(s) it serves. As far as I am aware, the term work system is rare in the organization and information system literature. I coined this term in my own work and later found it mentioned in a number of places such as a 1998 advertising brochure for the American Society for Training and Development (ASTD). While writing this paper I accidentally encountered this term in a review of the book New Rules for a New Economy [Herzenberg et al, 1998], but that book uses the term in a much more general sense, as one of three concepts for describing the economy. (Its other two terms are business organization and career path.) The AltaVista, Excite, and Infoseek search engines on the Internet find between 4,000 to 7,000 web pages when asked to search for "work system," but most of these are for unrelated topics such as "back-to-work systems."
 

Relationship to General Systems Concepts

The concept of work system reflects many of the ideas of general systems theory. For example, according to Churchman’s book about the systems approach, a system is "a set of parts coordinated to accomplish a set of goals." … There are five basic considerations to keep in mind "when thinking about the meaning of a system:

1. the total system objectives, and more specifically, the performance measures of the whole system.

2. the system’s environment; the fixed constraints;

3. the resources of the system;

4. the components of the system, their activities, goals and measures of performance;

5. the management of the system." [Churchman, 1979, p. 29]
 

Among many other points about systems, Churchman notes that "a system is always embedded in a larger system." [Churchman, p. 76] In addition, the environment surrounding the system is "outside of the system’s control, but … also determines part of how the system performs." [Churchman, p. 36]. At various points Churchman states or implies that the definition of any particular system is not preordained and that the person analyzing the system needs to define it.
 

Viewer and Problem Dependence

The definition of a particular system is both viewer-dependent and problem-dependent because different observers thinking about more-or-less the same system might be concerned about different issues, might define it differently, and might interpret its purpose quite differently. The definition of a work system for purposes of any particular analysis depends on the issues addressed by the analysis. For example, a software vendor may call a product offering "the system," and an IS professional may call an established information system "the system," but this does not imply that either is the best view of "the system" for purposes of analyzing any particular problem or issue.

When a group of people analyze a system together, the definition of the problem and the related definition of the system’s scope should be viewed as the result of negotiations rather than as a fact of nature. The greater the difference between the vantage points and motives of different stakeholders, the greater the disagreement about the desired definition of the problem and the system.
 

Architecture and Performance

A work system’s architecture is its components and how they operate together. Architecture can be described at many different levels of detail for different purposes. It encompasses much more than documentation expressed by a flow chart or data flow diagram. For example, the system’s human participants (with all their individual differences and personal inconsistencies) should be viewed as part of the system’s architecture. An important practical shortcoming of computerized systems is that many computer-related aspects of architecture must be defined in excruciating detail in order to create and maintain the computer programs.

A work system’s performance is how well it operates. Primary determinants of work system performance include internal architecture and external factors such as the infrastructure it relies on and the external context within which it operates.

Work system performance can be divided into internal and external performance. Internal performance is how well the system operates internally whereas external performance is how well the system achieves its purpose. This distinction is sometimes summarized as the difference between efficiency and effectiveness. Internal performance is typically measured in terms such as productivity, cycle time, consistency (of the work that is done), and rate of output. External performance is gauged based on the extent to which the system’s product meets the needs and expectations of the system’s customers, who should therefore evaluate external performance based on their perceptions of the system’s product. Relevant measures of external performance include cost, quality, reliability, responsiveness, and conformance to standards as viewed by the customer.
 

Risk

In a formal, mathematical sense, risk refers to calculated probabilities of various outcomes. When applied in a non-mathematical sense for thinking about a system, risk is a good catch-all for things that can go drastically wrong and thereby cause total system failure or significant degradation. Thus, a change in system architecture or a response involving external infrastructure or context may be aimed at improving performance in general or may be aimed at reducing or eliminating specific risks the system faces.
 

Multiple, Often Contradictory Goals

A goal is a desired performance level. A goal must be stated in terms of a measure of performance in order to be specific enough to determine whether it has been achieved. Goals typically have less impact if performance in terms of those goals is not measured or if feedback about performance is delayed.

Work systems often have multiple goals and some of these goals may be mutually contradictory; for example, instant response for customers, low personnel expenses, and reasonable working conditions for work system participants. Goals may be inconsistent even for an individual system component. For example, consistency and productivity goals of a business process may be inconsistent with other goals related to rate of output, cycle time, and flexibility. Furthermore, goals for the entire work system or for any component may change precipitously depending on the pressures felt by the manager or observer or whoever is defining the goals regardless of what may have been agreed and recorded in the past.
 

Tradeoffs

It is usually impossible to simultaneously optimize all aspects of performance for all components of a work system. This statement is obvious when there are fundamental conflicts between the goals of different parts of a work system, but is also typically true because different subsystems have different operational characteristics. Instead of trying to optimize every aspect of an entire work system, it is usually necessary to suboptimize certain subsystems. This means that the architecture of certain subsystems must be designed in a way that limits the performance of those subsystems in order to increase the performance of other subsystems or the work system as a whole.
 

Problem Displacement

Due to the interdependence of work system components, changes in one subsystem may solve a local problem within one subsystem by shifting the problem to another subsystem without significantly improving overall system performance. This phenomenon can be called problem displacement. For example, when the development phase of an information system project is behind schedule, the resulting shortcuts may simply mean that the problem is displaced to the implementation phase. Similarly, sloppy work in one business process step may result in extra inspection and rework in a subsequent step. Problem displacement may optimize one subsystem while sacrificing the performance of another, but shifting a problem usually does not improve the performance of the system as a whole.
 

Organizations vs. Work Systems

Organizations typically contain multiple work systems and operate through them. An entire organization might be viewed as a work system, but for understanding information systems it is usually more effective to focus on particular work systems within an organization. How people are organized is certainly important in relation to a work system, but highlighting the term organization often leads to an emphasis on hierarchy, reporting relationships, and management rather than on how work is done, how well it is done, and how the results might be improved.

Participants in any particular work system may also participate in other work systems that demand their time, attention, and allegiance. This may be important in understanding resistance or lack of interest in changes in particular work systems or information systems. In many cases a work system participant’s lack of interest may stem from the amount of personal energy and attention already allocated to other work systems that seem more important.
 

2. ELEMENTS OF A WORK SYSTEM

Understanding a work system requires at least cursory understanding of six elements: the business process, participants, information, technology, products, and customers. The first four are inside the work system, whereas the products and/or services it produces and the customers who receive and use those products are outside the work system but essential for understanding the work system’s purpose and significance. This approach for summarizing a work system has been called the work-centered analysis (WCA) framework. [Alter, 1999].
 

Customer

The customer is whoever receives and uses the product of the work system. This may be an external customer, a customer for the organization’s product, or it may be an internal customer inside the organization. The customers of many work systems are participants in a downstream process in a value chain. A work system’s customer should evaluate the performance of its product.

Although a work system's customer is not usually a participant in that work system, the advent of interactive computing and more recently the Web have facilitated a trend toward making the customer a work system participant and an interactive user of an information system. Examples include ATMs and order entry systems that are directly accessible to external customers.

Customers should be distinguished from non-participant stakeholders. These individuals are neither customers nor participants, but still care about or are affected by a work system or its product. There are many reasons for being a stakeholder. Some involve internal operations, such as when the efficiency or inefficiency of a work system could ripple into other areas of the organization, could affect resource allocations, or could affect the organization’s external reputation. Other reasons involve internal politics, such as when a work system’s success or failure would reflect on an individual’s managerial judgement or that of a personal ally or rival.

In a typical situation, the manager is not the customer. The customer receives and uses whatever the work system produces. The manager manages the work system. This distinction is important because work system participants and people analyzing a work system often tend to view the manager as the customer and try to please the manager instead of pleasing the real customer.
 

Product

A work system’s purpose is to produce a product for the customer. This product is a combination of physical things, information, and service. It is possible to improve a work system’s product by enhancing or recombining the product components.

The product is what the work system produces, but is not the work system’s goal. A work system’s goals are the desired performance levels for each of the elements. Thus, one of the work system’s goals might be to generate a product that attains a desired cost and quality level as perceived by the customer. Other goals might be directed inward, such as business process goals for productivity and cycle time and its participant-related goals for employee skills, retention, and personal growth.
 

Business Process

This is the set of work steps that are performed within the work system. Some business processes are highly structured, such as those in highly automated factories. Other business processes are semi-structured or unstructured, such as management decision making. When the business process is totally unstructured it is unlikely that a formal information system will help in any consistent or predictable way. Increasing or decreasing the amount of structure in a business process may improve or degrade performance, depending on the situation and the performance variables that are being considered.

One might ask whether a work system is just another word for a business process. In the theory presented here, a business process is an element of a work system. One reason for treating the business process as a part of a work system (rather than as the unit of analysis) is that the business process may be performed in a way that deviates significantly from the idealized business process that might be described by a manager or in a procedure manual. Furthermore, different human participants with different skill levels, interests, and motivation may perform what is ostensibly the same business process in quite different ways. The extent and reasons for adherence or non-adherence to ostensibly structured business process actually is an interesting topic for information system research, especially as information systems are increasingly used to structure business processes. Although the term business process is essential for understanding the operation and significance of a work system, these issues illustrate why it is too limited to be the unit of analysis.
 

Participants

The participants are people who perform the work steps in the business process. The same business process might be performed with different degrees of success depending on participants’ skills, training, and interests. People with the title manager may or may not be work system participants. They are work system participants if they do some of the value-added work of the work system. They are not participants if they manage people who do the value added work.

A work system participant who uses information supplied by an information system may be a participant in the information system or may simply use information produced by an information system. For example, a manager receiving information from an MIS is a user of the information system and a participant in the work system of management. A manager developing a marketing analysis using a spreadsheet is a user of the spreadsheet and a participant in the system of creating the marketing analysis. A sales person entering sales call data into a centralized sales call tracking system is often a user only in the limited sense of using the information system’s data entry capabilities to supply data for the information users at headquarters.

The distinction between user and participant is important for understanding why information systems may or may not seem important to potential users. In some cases, their primary job function is as part of an information system. In other cases, their primary job functions involve participation in many different work systems, only one of which uses the information system in question. In these cases, issues related to the information system may be much less significant to the user because the user’s attention is spread across other work systems that may have higher priority. For example, a sales person entering sales call data into a tracking system is much more concerned with doing sales work. In situations such as these, aspects of the work system other than the quality of the information system or its human-computer interface are often primary determinants of whether an information system is used effectively.
 

Information

This is the information used by the work system participants to perform their work. Some of the information may be computerized, but other important information may never be captured on a computer. The information used in a work system is often a combination of hard (codified) and soft (intuitive or subjective) data. Better information may improve work system performance or may have no effect at all. Better information is more likely to improve work system performance if use of the information is part of a structured business process.

Since the information that is used or created within the work system is a part of the work system’s operation, the distinction between information and data is tangential when thinking about a work system. For example, in the many cases when an information system overlaps with a work system and structures, controls, or automates a major part of its business process, the corresponding information in the information system must be information in the work system (rather than just "data"). In other cases, an information system does not overlap with a work system but provides data that might or might not seem relevant to some of the work done by some of the work system participants. This is where the idea of data vs. information applies. An example is a transaction processing system in which the work system and information system overlap substantially. The information system produces information for this work system, but the same information may only be data when viewed in relation to a separate management work system that may or may not be able to use transaction information.
 

Technology

Technology is the hardware, software, and other tools used by the participants when doing their work. Information technology can perform six types of operations: capturing, transmitting, storing, retrieving, manipulating, and displaying information. The technology in a work system typically includes information technology, but it can also include other technologies that are tools in physical work.

The analysis of a work system sometimes requires distinguishing between the technology within the work system and the technical infrastructure that serves the work system. (See the following discussion of infrastructure.)
 

3. ENVIRONMENT OF A WORK SYSTEM

Understanding a work system usually requires an understanding of its environment, including the external infrastructure that it relies upon in order to operate and the managerial, organizational, regulatory, and competitive context that affect its operation.
 

Infrastructure

The operation of most work systems relies on infrastructure. Infrastructure is defined as the shared human and technical resources that the work system relies on in order to operate even though these resources exist and are managed outside of the work system. By this definition, technology inside the work system is not part of infrastructure.

Infrastructure typically includes human infrastructure, such as support and training staff, information infrastructure such as shared databases, and technical infrastructure such as telecommunications networks and programming technology. The fact that infrastructure is essential complicates the analysis of a work system by creating the temptation to expand the system’s scope to include the infrastructure. This approach may seem necessary for completeness, but makes the analysis longer and more complex. Also notice that one work system’s infrastructure is another work system’s product.

In general, technical infrastructure is a technology-based system that is shared among many work systems and is owned and managed by a centralized authority in charge of infrastructure. This authority could be an outsourcing contractor. This distinction between technology inside the work system versus the shared infrastructure it relies on is imprecise. The distinction is useful, however, because it encourages people to identify the technology that is clearly within the work system and because it helps in identifying essential resources that are or are not within the control of the managers of the system.
 

Context

A work system’s context is the organizational, competitive, technical, and regulatory realm within which the work system operates. These environmental factors affect the system’s performance even though the system does not rely on them directly in order to operate.

A work system’s context may create incentives and even urgency for change, but may also create obstacles. Intangible aspects of the context include the organization’s culture, the current organizational and competitive climate, and the goals and opinions of various stakeholders. The relevant context may also include explicit rules and requirements such as government regulations, industry standards, and organizational policies.
 

4. FIT BETWEEN ELEMENTS OF A WORK SYSTEM

The smooth and painless operation of a work system depends on the alignment and mutual balance between the various elements of the system plus adequate support from the external environment. The elements of the work system are well aligned if the espoused goals and measures of performance in all parts of the system are consistent and mutually reinforcing. They are well balanced if the relative concentration of resources in different parts of the system is appropriate and if no part of the system has excessive or inadequate resources compared to other parts of the system.

Misalignments and imbalances cause pain by impeding the work system’s operation, by degrading its product, and by diverting energy and effort into complaints and disputes. Misalignments and imbalances result from a wide range of factors such as poor coordination, displacement of problems to other parts of the work system, or excessive concentration of resources in some parts of the system while the resources in other parts of the system are inadequate.

A change in any particular element of a work system (except possibly the customer) usually requires a corresponding change in other elements in order to maintain balance. For example, better information or technology may have no effect on work system performance if nothing is being done about limiting factors elsewhere, such as with the business process or participants.

It is easy to say that the elements of a work system should be aligned and balanced, but the fact that work systems contain disparate elements often lead to imbalances and misalignments that require management attention. These problems include architectural imbalances within the work system, inconsistent goals within the work system, and conflicts related to the context and infrastructure.
 

Architectural Imbalances within the Work System

Looking at selected pairs of elements of a work system reveals a number of areas of potential imbalance that may be inherent in a work system’s architecture:

Product vs. customer: The product may disappoint the customer in a variety of ways. It may cost too much to learn, operate, and maintain; it may contain the wrong features; it may not be reliable enough.

Business process vs. product: The business process may be insufficient for producing the desired product or the business process may consume excessive resources relative to the value of the product it produces.

Participant vs. business process: The business process may be inappropriate for participants for reasons such as being too abstract, requiring too much knowledge, being too repetitive and boring, making minimal use of skills, etc. Inconsistency between the business process and the participants’ incentives, skills, and interests are especially important when a new information system changes characteristics of work, such as the degree of structure, the degree of autonomy, and the degree of abstractness.

Information vs. business process: The available information may be insufficient for the business process or the business process may not take advantage of the available information.

Technology vs. business process: The available technology may be insufficient or may be excessively expensive relative to the requirements of the business process. Conversely, the business process may not take advantage of the available technology. A common technology vs. business process mismatch occurs with the use of application software packages because the software may be designed for a similar process in a different type of business and may not contain the right vocabulary or processing logic.

Technology vs. participants: A mismatch between the technology and the participants can occur for a variety of reasons ranging from lack of training and familiarity through fundamental mismatches related to a lack of dexterity or visual acuity. Another aspect of a mismatch between technology and participants might involve negative impacts on the participants. Except when technology creates direct health and safety hazards, it is quite possible that the impact of technology characteristics on users tends to be less significant than the impact of business process characteristics on the users.
 

Inconsistent Goals within the Work System

Work systems are often subject to internally conflicting goals. Some of these conflicts stem from differing viewpoints of customers, participants, and work system managers. For example, product performance (cost, quality, responsiveness, reliability, and product conformance) perceived by the work system’s customers is different from internal business process performance (rate of output, consistency, productivity, cycle time, etc.) that work system managers care about but that work system customers may not notice at all. Likewise, evaluating work system participants based on the number of units they complete each day could undermine business process goals related to consistency and product goals related to quality.

Other conflicting goals apply to individual elements of a work system. For example, the customer’s goal for product cost (as perceived by the customer) may be inconsistent with the customer’s goal for product quality. Similarly, requiring too much consistency makes a business process inflexible, whereas too much flexibility makes a business process inconsistent. When looking at information, excessive requirements for information security may make information inaccessible; conversely, making information more accessible often makes it less secure.
 

Conflicts Related to the Context and Infrastructure

Work system participants often have responsibilities in other work systems that demand some of their attention and energy. Since any individual’s attention and energy is finite, responsibilities in multiple work systems can create an unbalanced situation in which an individual must juggle conflicting demands on personal attention and effort.

In addition, information systems serving as infrastructure for many work systems may face conflicting requirements from these diverse systems. For example, a manufacturing group’s productivity might depend on freezing schedules several weeks at a time, whereas a sales group’s sales productivity might improve if it could suggest schedule changes at any time. This example shows why an enterprise-wide information system could become entangled in conflicting goals as its content is being negotiated. Goal conflicts may also occur in relation to technical capabilities of computers or networks, such as when departments share infrastructure costs even though one department might require a much higher level of network availability.
 

5. DEFINITION OF AN INFORMATION SYSTEM AS A WORK SYSTEM

An information system is a particular type of work system. It is a work system that processes information by performing various combinations of six types of operations: capturing, transmitting, storing, retrieving, manipulating, and displaying information. For example, an information system cannot move or produce physical objects even though it may support or automate aspects of a work system that moves or produces physical objects. Similarly, an information system cannot think, learn, interpret information, create ideas, or make decisions unless it contains computer programs that express these tasks in terms of the six basic information processing operations. (Someone needs to know how to write the programs.)

An information system exists to produce information or to support or automate the work performed by other work systems. An information system may be a subsystem of a work system, but may also exist external to work systems that use the information it produces.

Since an information system is a work system, any ideas, generalizations, and systems analysis methods that apply to work systems should also apply to information systems. For example, just as most work systems can be subdivided into a set of smaller work systems, many information systems can be subdivided into a set of smaller information systems. Consider a retailer’s information system for keeping track of orders and payments. For some purposes, the parts of the information system devoted to entering orders and receiving payments might be considered a separate information system from the parts devoted to entering data about customers and products; similarly, the management reporting system might be treated as a separate information system. As with systems in general, the choice of how to define the information system under consideration depends on the problem and the analyst.

An important question in defining an information system is whether or not to include users (and all their variability) inside the system. Based on the concepts of viewer- and problem-dependence mentioned earlier, this question should be decided on a case by case basis depending on the problem that is being analyzed. In a typical case, clerks whose job is processing information in a predictable fashion would usually be included within an information system. In a contrasting case, managers who use information provided by an MIS would be outside of the information system, but would use the information while participating in a work system related to management.

An aside: In addition to being a part of proposed theory, defining an information system as a work system may help in interpreting results from IS research and practitioner observations and generalizations. My personal, untested belief is that many results attributed to information system characteristics or changes would be described more accurately as results related to issues in the work system. Whether or not this belief would hold up across much of the empirical and experimental IS literature, it is certainly a pertinent question for my Ph.D. research on decision support systems. At the time I did the work I thought it was about DSS, and people who saw the resulting book [Alter, 1980] and articles seemed to agree. In retrospect it has become clear that the phenomena I observed in the many cases I studied were more related to the work system rather than to the DSS per se. (I admit this freely because the statute of limitations for rescinding my degree has surely passed.)
 

6. ROLES OF INFORMATION SYSTEMS IN WORK SYSTEMS THEY SERVE

An information system exists in order to serve one or more work systems. This is why the significance and operation of an information system in an organization are often better understood by examining the work system(s) the information system serves rather than by examining the information system itself or the organization in which it operates.

Contrary to the common assumption that a typical information system’s purpose is to provide information to work system participants, information systems may serve work systems in a variety of roles. Table 1 summarizes the possibilities using two variables, whether the information system serves one or many work systems and the degree of structure imposed by the information system’s role. In relation to a single work system, an information system may provide information, may structure the work, or may automate some of the work. In relation to a group of related work systems, an information may support information sharing, may coordinate the work, and may integrate the work. Table 2 provides examples related to each role.


 
Table 1. Roles an Information System Can Play in Work Systems

Supporting an individual work system		 PROVIDE INFORMATION

Provide information that 
supports work done in an individual work system

 STRUCTURE WORK

Structure work done in an individual work system

 AUTOMATE WORK

Automate some of the work done in an individual work system
Supporting multiple work systems INFORMATION SHARING

Support information sharing across multiple work systems

 COORDINATE WORK

Coordinate work done in multiple systems

 INTEGRATE WORK

Integrate work done in multiple systems
Imposing minimal amount of structure
--------------------
Voluntary usage
<<=================>>		 Imposing large amount of structure
--------------------
Mandatory usage

 
 
 
Table 2. Examples of Different Roles Information Systems Can Play in Work Systems
Supporting an individual work system PROVIDE INFORMATION

Managers use an MIS to track progress and identify issues

Individual uses a DSS to analyze an issue

 STRUCTURE WORK

Insurance sales people fill out forms in sales process.

Interactive IS identifies errors and suggests corrective action.

Expert system structures work of a novice.

 AUTOMATE WORK

Information system controls equipment in a factory.

Mathematical model performs calculation that determines a decision.
Supporting multiple work systems INFORMATION SHARING

Intranet provides access to company info.

Groupware supports document access.

Videoconferencing supports information sharing

 COORDINATE WORK

Planning system balances workload.

Information system updates factory schedule for new sales.

 INTEGRATE WORK

ERP system provides common database and consistent naming.

CAD system detects inconsistencies across modules from different designers
Imposing minimal amount of structure
--------------------
Voluntary usage
<<================>>		 Imposing large amount of structure
--------------------
Mandatory usage

 
From Voluntary  to Mandatory, from Less Structure to More Structure
Tables 1 and 2 show that the degree to which information system usage is mandatory typically increases as the information system imposes more structure on the work. The wide range of possibilities in these Tables implies that generalizations based on information systems serving one type of role may not be valid for information systems serving other types of roles. This is important for IS research because interpretations of research results sometimes seem to assume that that an information system or the information it provides is used voluntarily. This assumption is sometimes made even though many other current applications of information systems are primarily about structuring, controlling, automating, or integrating work systems where usage is not at all voluntary.

When information system usage is voluntary, the business process is usually unstructured or semi-structured and the information system supports some aspects of the process. This pattern is common in using MIS, EIS, marketing information systems, and other information systems that track progress and provide background information. Information systems such as these may help in identifying issues and in deciding what to do, but the information systems themselves do very little to structure a decision process. Similarly, using a model-based decision support system as an analysis tool is also voluntary. The model helps by providing information in a usable form, but the analyst still needs to decide how to tailor the model, what to recommend, and how to sell the recommendation.

When the information system structures or controls major aspects of the work, the business process is typically semi-structured or highly structured. For example, this is the pattern when insurance sales people fill out certain forms in order to sell insurance. Without the information system they might have much greater freedom in their sales process. With it, the sales process is constrained to some extent because of consistency requirements imposed by related to management control. An example involving slightly more structure occurs when an interactive information system identifies likely problems and errors that have just occurred in a business process, possibly suggests corrective action, and possibly prevents the business process from continuing until the problems or errors are resolved. It also happens when an information system sets short-term goals or priorities, such as identifying which item in the work-in-process has highest priority in terms of meeting a schedule.

An information system can automate a major aspect of a business process only if that work is totally structured. This happens when an information system directly controls equipment, such as when an autopilot controls the flight of an airplane or when an information system tells an automated production process which options to install for a particular work order. It also happens when a mathematical model performs a calculation that largely determines a complex but highly structured decision such as the equity trading decisions determined by program trading models. In many of these situations, speed is of the essence and people couldn’t perform the calculations fast enough even if they wanted to.

The progression from voluntary to mandatory usage and from imposing little structure to imposing a great deal of structure on the work raises different types of issues for information systems. The significance of aesthetics and personal preferences is often important in determining the manner and extent of voluntary information system usage, such as when a manager uses an EIS. Aesthetics and personal preferences are much less important in determining the whether someone checking in passengers at an airport will use an airline reservation system. On the other hand, the consequences of information system bugs or poor fit between the information system and the work system become more serious as the information system imposes more structure. A poorly designed or buggy information system can make a structured work system inefficient or prevent it from operating at all.

Given the divergence between the different roles, it is important to identify and discuss assumptions by work system participants and their managers about an information system’s role in a work system. Failure to do this may cause implementation problems if one group believes information system usage is voluntary while another believes consistent information system usage is a mandatory part of the work system’s structure. Similarly, research findings related to information systems whose use is voluntary may have little bearing on information systems whose use is mandatory. For example, the usage-related impacts of commonly studied variables such as perceived usefulness and perceived ease of use [Gefen & Keil, 1998] might be quite different if the work system called for mandatory versus voluntary usage patterns.
 

7. DEGREE OF INTEGRATION BETWEEN AN INFORMATION SYSTEM AND
    A WORK SYSTEM IT SERVES

Information systems and the work systems they serve may or may not be truly separate entities. The increasing power of computers, networks, and software has made it far easier to reduce or eliminate the traditional separation between work systems (where work is done in real time) and information systems (which provide after-the-fact information to managers). The result is a trend toward incorporating information systems into value added work. Finance, manufacturing, and sales work systems that once might have been completely manual cannot operate effectively today without real time information systems that support and/or control them.

There is a broad range of possibilities for functional integration between an information system and a work system it serves. A minimal degree of functional integration occurs when the two systems are separate entities. In this case, the information system provides information used in the work system but does not play an active role in the work system. With a higher degree of integration, the information system becomes a tool or active component of the work system. With the highest degree of integration, the information system and work system are virtually indistinguishable. Table 3 shows examples that demonstrate the possibilities.

The degree of functional integration is a major factor in the impact of operational shortcomings and bugs in the information system. With a minimal degree of integration, the main issue from a work system viewpoint is whether the information is adequate rather than whether the information system has shortcomings. As the degree of integration increases, information system shortcomings become a more serious annoyance. If the information system is an integral part of the work system, its problems can prevent the work system from operating at all.

Differing degrees of functional integration also elicit different types of management concerns. Minimal levels of functional integration may increase the likelihood that work system participants will misinterpret the information provided by the information system. The fact that the information system plays no active role in the work system may also signal an opportunity to improve work system performance by creating a higher degree of integration. If the information system provides tools and information that are somewhat tangential to the main demands on the work system participants, the time and effort they must devote to other responsibilities will probably limit the information system’s impact. If the information system is an integral part of the work system or is virtually indistinguishable from it, the information system itself may become a constraint that unduly restricts work system flexibility.

Table 3. Examples Showing Different Possible Degrees of Integration between
an Information System and a Work System It Serves
  Information system dedicated to a single work system Information system serving as infrastructure shared among many work systems
Information system virtually indistinguishable from work system Online brokerage system

Accounts payable system

System for processing loan applications

 (N/A, by definition of infrastructure)
Information system is integral part of work system CAD system in a small engineering or architectural firm

Automated dispatching in an automated factory

Embedded system in a car or other machine

 National airline reservation system used by local travel agent.

National inventory system used by people in many different locations and business roles to determine inventory availability.
Information system is interactive tool used at the discretion of work system participants Model used by mortgage broker to calculate monthly payments.

Online medical database used by doctor to find drug interactions.

 Commercial marketing database with analysis tools.

Corporate intranet providing access to corporate policies, announcements, etc.
Information system is external source of information for work system Database of lab results in a 10-doctor clinic.

Customized market analysis system for a local business.

 National manufacturer’s product and price list.

Commercial marketing data presented as preformatted reports
 
Dedicated Information Systems versus Shared Infrastructure

When an information system is dedicated to serving a particular work system, it is comparatively likely that the information system will be modified to satisfy changing needs in the work system. To the contrary, information systems serving as shared infrastructure for many different work systems may tend to take on a life of their own. They are typically managed separately and may not be as responsive to the changing needs of particular work systems.

There are many important examples in which a large, enterprise-wide information system is the shared infrastructure that serves many disjointed work systems. Consider an airline reservation information system. Although it might be viewed and managed as a single information system, it can provide the infrastructure for a wide range of work systems. Such work systems might include updating flight information and prices, deciding which flight to take, making reservations, printing tickets, monitoring the ticket market, and making yield management decisions (how many seats to offer in different price categories on specific flights). Similarly, an ERP system can provide capabilities serving a variety of work systems while also serving as shared infrastructure facilitating information integration across a firm.

When a massive information system serves as shared infrastructure, managers making decisions about it may find no way to avoid sacrificing the performance of some work systems in order to improve the performance of others. This suboptimization of the operation of particular work systems raises real, but sometimes poorly articulated issues about which work systems should be served best and which should be sacrificed in favor of larger organizational goals. There are probably many cases when work system participants do not understand the rationale for information system decisions that affect them and believe that negative impacts occurred by accident or due to inattention or bad decision making.
 

8. CONTENT vs. PLUMBING IN INFORMATION SYSTEMS

Viewed conceptually rather than mechanically, information systems consist of two layers: content and plumbing. An information system’s content is the expression of its role in the work system and is described in terms related to the business process and the business world. Content includes the information the information system provides for the business process and the way the information system structures, controls, or automates parts of the business process. A detailed discussion of content might include the definition of data items in a database, the business rules built into transaction processing software, the specific information a manager receives on a weekly report, the sender’s name and the text of an email message, and the image on a videoconferencing screen.

The degree to which an information system’s content is customized for a particular business situation is an important factor in how easily the information system can be implemented and used in a work system. For example, assume that content could focus on any of the following four possibilities: providing general business information, providing general purpose analysis tools, providing specific information needed to perform a well-defined business process, or providing analysis tools tailored to a well-defined business process. An information system whose content focuses on a well-defined business process with well-defined information is typically easier to implement and use effectively than an information system with a more general purpose.

The plumbing layer exists to make content-related operations possible. It includes the aspects of the information system that deliver the content but are hidden or might be hidden from work system participants so that they can focus their attention on their work within the business process. Typical information system users have no interest in the plumbing layer and want to avoid learning about its intricacies. Just as in a building, they want the plumbing to work well and at reasonable expense, but do not care about the technical choices that determine whether the plumbing works well and at what cost. For example, a web page’s user cares about the information it provides, but doesn’t care about TCP/IP, Java, and other aspects of the plumbing that communicates with the server, retrieves the data defining the web page and displays the page. Similarly, a user’s database query starts at the content level (such as "Which three regions had the best performance?") and is converted by a machine or person into SQL or some other form that can be handled by the plumbing layer. The plumbing finds the data wherever it happens to be, combines or filters it, and displays it.

Although Fortune recently used the term plumbing as a category that includes Microsoft’s Windows, Cisco Systems’ networking products, and Marimba’s application distribution products [Warner, 1999], the distinction between plumbing and content is certainly not standard in the information systems literature. It is useful, however, because it creates an understandable image and avoids some of the confusions that occur when talking about "computer systems" and "technical systems." For example, even though a telephone switching network can be viewed as a complex computer system, many people do not associate computers with telephones. In contrast, it is easy to think of the wires and the routing as the plumbing whereas the voice conversation or email message being conveyed is the content. Similarly, it is sometimes confusing to call part of a system a "technical system" because the content of many information systems involves sophisticated technical knowledge. This is certainly the case for an information system used in designing airplanes, creating economic forecasts, or mapping the human genome.
 

Impact of Content vs. Plumbing on Work System Participants

Work system participants need to understand an information system’s content in order to do their work effectively. This content may take the form of providing information that work system participants use voluntarily, but it can also take other forms, such as structuring or controlling the work system, automating important aspects of the work system, or integrating the work system with other work systems. In effect, content is any aspect of the information system that the work system participants would normally talk about when they are not specifically talking about how to operate a computer.

Even with the advances built into current technology, too much of the effort of work system participants is still devoted to understanding and dealing with the plumbing. Smooth and painless operation and use of information systems is more likely when work system participants can devote their attention to content rather than plumbing. It is likely that both personal productivity and job satisfaction of most information system users are inversely related to the amount of attention they must devote to information system plumbing. Similarly, business professionals are more able to manage systems in which the plumbing can be hidden effectively, whereas IT professionals are needed to the extent the plumbing cannot be hidden.

Much of what passes for information system training (and information system education) is about plumbing but not about content. Since work system participants must focus on content in order to do their work effectively, it is ironic that most information system documentation either focuses on plumbing completely or emphasizes the most plumbing-like aspects of content, such as database definitions and transaction definitions. It seems likely (but is certainly open to verification) that only a small part of the documentation of most information systems focuses on the way the information system affects or changes the way work system participants do their work and produce desired results.
 

Role of Content vs. Plumbing in the Progress of Software

Much of the progress that has occurred in software is related to the increasing separation between content and plumbing so that information system users can focus on content while letting someone else focus on plumbing. By progressing in this direction, each successive generation of computer languages has allowed programmers to do more of their work in clarifying the details of content rather than the details of plumbing.

Part of the distinction between the plumbing layer and the content layer involves the meanings attached to groups of bits. In the plumbing layer, groupings of bits are captured, transmitted, stored, retrieved, manipulated, and displayed without reference to what they mean to the users. In the content layer, groupings of bits are defined in terms of concepts related to the user’s business world. An automated translation process converts content-related tasks (such as retrieving specific items of information or transmitting email messages) into plumbing-related tasks defined in terms of groupings of bits. These processing techniques and groupings of bits are designed to make the internal operation of the information system more efficient. They may have little or no obvious correspondence to the groupings of bits that constitute information users can understand.
 

9. IMPACT OF AN INFORMATION SYSTEM

An information system’s impact can be divided into two parts. First, an information system’s features and capabilities may have a direct impact on a work system’s architecture and performance. The impact on architecture involves the role it plays in the work system; the impact on work system performance involves both the role it plays and how well it plays that role. Second, its features and capabilities may have an impact on the work system’s long term flexibility and adaptability. This secondary impact is determined primarily by the quality and adaptability of both information system content and its plumbing.
 

Direct Impact on Work System Architecture and Performance

The idea of an information system’s impact on a work system sometimes seems illogical because an information system may be a subsystem of a work system that it serves and therefore may be part of the business process architecture within the work system. It is easy to talk about the impact of a penicillin shot or of going on a diet, but one typically doesn’t speak of the impact of a foundation on a building even though the building would collapse without its foundation. On the other hand, the characteristics of the foundation do affect the building’s structural integrity. In a similar way, the discussion of an information system’s impact on a work system is usually about the impact of establishing new features and capabilities rather than about whether or not the information system exists.

An information system’s direct impact occurs in the way its features and capabilities provide information for a work system or play an active role in the business process architecture within the work system. The earlier section on information system roles noted that an information system can structure a work system, can control it, and automate important aspects of the work, and can integrate it with other work systems. These roles are all related to the work system’s business process. In a more general sense, an information system can affect any of the following aspects of business process architecture: degree of structure; range of involvement; level of integration; complexity; degree of reliance on machines; attention to planning, execution, and control; and treatment of exceptions, errors, and malfunctions. [Alter, 1999]

Impacts on work system performance involve many factors because different performance variables apply to each of the six elements of a work system. For example, customer satisfaction is related to a combination of product function and product performance variables perceived by the work system’s customers, such as cost, quality, responsiveness, reliability, and product conformance. These variables are directly or indirectly related to internal business process performance variables such as rate of output, consistency, productivity, and cycle time. In turn, these variables are affected by performance variables related to participants, information, and technology. With so many performance variables interacting, it is often difficult to link any particular improvement in work system performance to a specific group of information system features or capabilities.

This general line of reasoning also applies to discussions about the competitive and organizational impact of IT. These discussions tend to skip important steps. A realistic starting point is the impact of IT on the efficiency and effectiveness of critical work systems whose operational success affects the organization’s success. IT often contributes significantly to work system efficiency and effectiveness, but it is unclear why one would want to assume or argue that just one work system component (IT) determines the organization’s success. In most of the cases when an information system improvement has a major impact, those improvements are accompanied by other, equally essential improvements elsewhere in the work system.
 

Limits to the Potential Impact of an Information System

The impact of an information system is limited by the role it plays in work systems it serves. An information system that addresses one part of the business process within a work system may have little effect on the work system’s performance if the limiting factors are related to the other parts of the process.

This type of limit is especially important to consider when an upgrade in information system plumbing is being considered. Changing the plumbing tends to have a direct impact on work system performance only if the current plumbing is a limiting factor for the work system. If plumbing is not the limiting factor, changing the plumbing probably won’t affect work system performance directly (whether or not it affects other variables such as the long-term maintainability of the information system or the job satisfaction of the IT staff).
 

Possibility of Negative Impacts

A change in any of the roles of information systems or architectural characteristics of a business process can potentially improve or degrade work system performance or may have no impact whatsoever. An information system change has no performance impact if it does no harm but also fails to address the factors that actually limit the particular work system’s performance. A change that degrades performance may make a business process more difficult to perform, may necessitate an awkward workaround, may make it difficult to change the work system in the future, and may even cause the work system to fail.

An example of a workaround is the way order entry clerks sometimes fill in a phony shipping address on an order because the information system will not let them take the order without a shipping address. This feature may have seemed obvious in some situations, but when lead times are very long it may not make sense to require filling in the address if the purchaser does not know where the shipment should arrive months in the future. The workaround permits entry of the order, but merely transforms a problem for the order entry work system into a subsequent problem for the delivery work system. Similar problems sometimes occur when compromises between conflicting needs in ERP implementations force particular work systems to relinquish existing information systems that had been customized to address their specific situations especially well. In one particular case, a major electronics manufacturer was forced to abandon its longstanding practice of using negative quantities on customer orders as a way to cancel charges for product options that particular customer might not want. The work system for entering orders had to adopt awkward, time-consuming workarounds because the ERP system would not recognize negative quantities on an order.
 

Enabler or Inhibitor of Change

A change in the information system serving a work system may support a desired change in the work system, but inflexibility or other problems with the information system’s content or plumbing may inhibit or even prohibit desired changes in the work system. The billing information system for a major telephone company is an example of an information system that prevented important work system improvements. The company had developed new services but could not offer them to customers because it was unable to incorporate those services into its decades old billing system. At a more global level, the Y2K problem has inhibited information system and work system improvements by diverting resources and attention toward avoiding information system failures and away from using information systems to enable new work system improvements.

In both the billing and Y2K examples the core of the problem concerns plumbing, namely, the way that information systems happened to have been programmed independent of the content the information systems were attempting to deliver. Even the most current plumbing (the latest operating systems, middleware, programming languages, etc.) still requires a great deal of attention by IT specialists when new information systems are built from scratch. As with the billing and Y2K examples, the complexities of dealing with older plumbing add cost and complexity to conversions from old to new information systems. The ironic result is that information systems that were supposed to enable change often turn out to inhibit or prevent it.
 

10. DEFINITION OF A PROJECT AS A WORK SYSTEM

A project is a time-limited work system designed to produce a particular product and then go out of existence. It is a work system because it involves human participants and/or machines performing a business process using information, technology, and other resources to produce products and/or services for internal or external customers.

The fact that a project is a work system means that generalizations about work systems also apply to projects.
 

11. PHASES OF A PROJECT THAT CREATES OR SIGNIFICANTLY CHANGES
A WORK SYSTEM

Projects that create or significantly change a work system (which may be an information system) typically go through four idealized phases unless they are terminated before completion. The four phases are initiation, development, implementation, and operation and maintenance [Alter, 1999]. These idealized phases serve as a least common denominator crossing different types of work system projects whose internal business processes may vary greatly.
 

Initiation

The initiation phase is the process of clarifying the reasons for changing the work system, identifying the people and processes that will be affected, describing in general terms what the changes will entail, and allocating the time and other resources necessary to accomplish the change. Key issues in this phase include attaining agreement on the purpose and goals of the proposed change and making sure that the likely benefits far exceed the likely costs in terms of time and resources.
 

Development

The development phase is the process of defining, creating, or obtaining the tools, documentation, procedures, facilities, and any other physical and information resources that are needed before the change can be implemented successfully in the organization. Key issues in this phase revolve around creating or obtaining all required resources in a cost-effective manner and, if necessary, demonstrating tools and procedures actually meet the requirements. Completion of this phase means that the tools seem to function properly. Whether the work system will absorb or reject the desired changes is determined by the next phase.
 

Implementation

The implementation phase is the process of making the desired changes operational in the organization. This includes planning for the roll out, training work system participants, and converting from the old way of doing things to the new way. Organizational implementation frequently raises issues about how to convert to a different business process with minimum pain and how to deal with political questions and changes in power relationships.
 

Operation and Maintenance

This final phase involves keeping the work system operating effectively by monitoring its performance and making minor changes that do not require a major project. This phase continues until major changes are required. At that time a new iteration of the four phases starts. Management allocates resources to initiate a project. The initiation phase ends with specific ideas about what should change, the new development phase begins, and so on.
 

Relative Weighting of Phases in Different Types of Projects

The four phases of a work system project were described in a general manner without mentioning information systems, hardware, or software. The same phases apply whether or not the changes in the work system are related to an information system that serves it. When an information system is involved, the same phases apply regardless of whether the information system is built from scratch using a structured life cycle, is based on application software purchased from a software vendor, or is developed using a sequence of prototypes.

Although the same phases apply, their relative weighting differs across different types of projects. Consider the difference between three types of projects: 1) a project that creates or changes a work system without involving information systems, 2) a project that creates or changes an information system, and 3) a project that creates or changes software. The work system project (1) is mostly or entirely about changing content and has little to do with plumbing. Its development phase is often shorter and simpler than its implementation phase because the development of tools and materials that don’t involve computers often takes less time and effort than implementing a work system change. The information system project (2) may involve major changes in both content and plumbing. Consequently, both its development and implementation phases may consume substantial amount of time and energy. The software project (3) is primarily about plumbing because software is plumbing. The product of a software project is software that runs on a computer rather than an information system whose operation supports a work system in an organization. The goal of the exercise is creating software that operates according to the specifications determined at the beginning of the project. Whether or not the software is actually used or integrated into a specific work system in an organization is virtually an afterthought in terms of the software project per se. Over-all, the relative balance between development and implementation is a proxy for the relative balance of plumbing changes vs. content changes in a project.

A careful look at typical information systems texts, programming texts, and systems analysis and design texts would probably show some degree of confusion about whether the life cycle models that are presented are really about software or information systems or work systems. At minimum, much of the literature on building software emphasizes the development phase. An example is a CACM article on Microsoft’s release cycle for its software products [Cusomano & Selby, 1997]. The article explains a well-defined software cycle that combines tight central control of fundamental architectural issues with small group autonomy over some of the features in each module. Another CACM article [Hersleb et al, 1997] describes the Software Engineering Institute’s capability maturity model and its claim that highly structured methods including extensive recordkeeping tend to produce higher quality software. In both cases, a lot is said about building and maintaining software but little is said about the implementation of information systems or work systems that use the software. (This is an observation about the focus of the articles and definitely not a complaint about their content.)
 

What Is Implementation?

The definition of implementation is the central question here. In the four phases of a work system project, implementation is about converting from the old information system and work system to the modified information system and work system. The literature about software projects often implies a different meaning for the term implementation. This meaning involves satisfying a set of functional requirements for software. In the four phases described above, implementation ends when the new systems are operational in the organization. The alternative view is that implementation ends when the software operates correctly on the computer. This difference in terminology would be of little consequence except that similar confusions frequently muddle project-related discussions between business professionals and IT professionals. To say the least, the fact that implementation may have totally different meanings to people participating the same project is likely to cause confusion.
 

Involvement of Business Professionals in All Four Phases

Business professionals should be involved in all the major phases of an information system project (unless the project is purely about plumbing). They should control content, either directly or indirectly, because they have the best understanding of how the work system should operate. Their participation is also needed because it usually gives the project additional credibility that removes obstacles during implementation.

In the initiation phase, they should help define the desired work system changes and the way new information system capabilities should enable the work system changes. Involvement in this phase is especially important because problems in implementation may be much worse when there is little debate about the definition of the system and definition of the problem early in the project. In the development phase business professionals should make sure that the content-related details of the information system are consistent with the goals of the desired work system. During the implementation phase they should make sure that the implementation in the organization is planned appropriately and that implementation issues and problems are identified and resolved quickly. During the operation and maintenance phase they should make sure that the operation and performance of the work system and information system are both monitored and that the performance information is used for further improvements.
 

12. IMPACT OF THE BALANCE OF CONTENT AND PLUMBING IN A PROJECT

The incidence of disappointing outcomes and outright failures is probably much higher for projects involving information systems than for work system projects in which information systems are a minor factor. For this reason, information system projects receive a great deal of attention.

Information system projects often have greater conceptual and managerial complexity than work system projects that do not involve information system changes. Figure 2 summarizes part of the reason by claiming that the relative balance of content and plumbing in an information system project affects the project’s degree of difficulty and should affect its organizational structure. For projects of any particular size, the Figure says that projects involving significant change in both content and plumbing are more difficult than those in which the changes mostly involve just content or just plumbing. This is one of the reasons why ERP projects and major new application projects are often difficult.


Figure 2. Difficulty of a Project Based on the Relative Weighting
of Content Changes and Plumbing Changes

A key factor in the difficulty of many information system projects is the extreme thoroughness and precision required to define hardware and software configurations and to write and test computer programs. A high degree of care is needed because computer systems cannot identify and work around logical errors as programs are being executed. In contrast, people can work from partial specifications, can recognize when they going beyond what they understand, and can ask questions. (Recognizing the importance of human abilities to work around rules that don’t quite fit, unions have often used "work-to-rule" as a tactic in labor negotiations. With this tactic, they do their jobs "by meticulously observing every one of the rules and regulations and performing only the duties stated in their job descriptions. The result, fully intended in this case, is that work grinds to a halt, or at least to a snail’s pace." [Scott, 1998])

The necessary thoroughness and precision about information system details extends to both the content and the plumbing. The content-related details include definitions of the data, the rules built into transactions, and design of management reports. These details require attention from work system participants as well as IT experts, who must apply the same care to plumbing-related choices involving internal design, programming techniques, and hardware installation.

Unfortunately, the difficulties don’t stop there. Information system projects that change information system plumbing substantially require the involvement of programmers and other technical specialists, and this leads to difficult issues about how the work should be organized, who should manage it, and who should evaluate whether the project is a success. To clarify some of these issues it is possible to look at an information system project using the six elements for summarizing a work system. (The following paragraphs are about the six elements of the project, and not the six elements of the work system that is being changed.)
 

Customers

The main customers of an information system project are the managers and participants in the work system that is being improved. IT staff members are secondary customers because they need to maintain and upgrade the hardware and software in the future. Conflicts between these groups are common because their criteria for success are often different. Work system managers and participants are most concerned with how well the work system operates and how its operation affects personal work conditions, ambitions, and interests. These central concerns far outweigh tangential concerns such as forgiving the mismatch of an information system that was designed before business conditions or other external factors changed. Information system builders usually do their best to create information systems that improve work system performance, but their viewpoint is strongly influenced by the way they are evaluated. Much like contractors constructing a physical building, they want a clear agreement about what they are trying to produce in a particular time frame and at a particular price, and they want to be judged on whether they meet their commitments. These agreements usually do not include contingency clauses about what should happen if the planned functionality is no longer on the mark due to changes in the business situation. Furthermore, even putting together a clear functional specification is a difficult task for large projects.
 

Products

The differing views of the work system participants and the IT staff may even extend to what they view as the product of the effort. To a work system participant, the most important product of an information system project is not the information system, but rather, timely and painless transition to a better business process and better working conditions within a work system. In contrast, given the IT staff’s responsibilities, members of the IT staff tend to view the product as information system capabilities that satisfy certain specifications and can be maintained conveniently in the future.
 

Business Process

Information systems can be built or modified using a variety of business processes depending on the relative importance of different goals. For example, a structured life cycle approach with carefully defined deliverables might be used if project control is especially important; a prototype might help in identifying new ways to improve a work system’s operation; and a commercial software package might be used if the organization lacks the time, skills, or desire to build an information system from scratch. An improvisatory approach [Orlikowski & Hofman, 1997] may be effective when most of the changes involve content rather than plumbing and when the content is not hard-wired in the plumbing.

Regardless of which system building approach is used, each of the phases may reveal conflicts and confusions. The initiation phase and early parts of the development phase may contain power struggles about who should define the information system requirements. At minimum, it may turn out that "the requirements" are nothing more than a temporary compromise that allows the project to continue even though important project participants are unaware of or dissatisfied with what will be produced. Regardless of what was originally agreed in the initiation phase, the development and implementation phases may uncover unanticipated problems and shortcomings in the original design. In some cases the requirements will be changed. In others, the details will be changed without explaining that the information system no longer satisfies the original requirements. In yet other cases, the business issues facing the work system participants may change even as the information system is being built.
 

Participants

Anyone who has been a highly specialized expert or who has worked with specialized experts such as programmers, doctors, and lawyers, recognizes some of the frustrations that often occur when experts try to collaborate with non-experts. Those viewing themselves as experts are often frustrated with their inability to explain simple issues to non-experts, while the non-experts are frustrated with the expert’s combination of jargon and arrogance. Expert vs. non-expert issues in information system projects sometimes have extra edginess when a plumbing expert tries to suggest work system changes (i.e., content changes) to a plumbing non-expert who has participated in the work system for years. And beyond expertise or non-expertise, people who do technical work for a living often have a comparatively high tolerance for sitting in a room and discussing concepts and details for hours on end. People in other types of work may view this as torture.

Another facet of the human issues in these projects involves management and ownership. Managers representing the work system that is being improved usually have the deepest understanding of the work system, but they usually cannot supervise or evaluate the work of the technical specialists. Frequently they don’t understand plumbing issues, don’t understand processes related to plumbing, such as design and testing, and don’t know how to manage people who specialize in IT plumbing. On the other side, managers representing the technical specialties can supervise and evaluate the technical work but sometimes pay too much attention to technical issues and too little to practical considerations and the frequently changing needs of the work system. They may not have deep knowledge of the content and typically do not have the responsibility to make the content operate effectively over time in the organization.
 

Information

Typical information about a project includes the goals, schedules, and details of the work. A special problem with information system projects is the enormous amount of detailed information about both the content and the plumbing. No one could understand everything about an information system that contains thousands of pages of computer programs and specifications, despite which many of these systems are built successfully. The enormous amount of project information does take a toll however, especially on work system participants and managers who are asked to examine lengthy information system descriptions or documentation.
 

Technology

Rapid changes and improvements in technology raise many questions in information system projects. Some are about the technology that will be used in the information system, such as whether that technology will become obsolete (which is guaranteed, at least eventually) and whether it is a cost-effective choice (which may be difficult to evaluate). Other questions are about the technology used in the project itself. Programmers often want to use the latest technology, but as with technologies in any work system, better programming technologies have a significant impact mainly when they are an integral part of a work system that exploits their features.

Taken together, the issues under these six headings show that information system projects often occur in a climate of technical complexity, difficult supervision, and overt or covert conflict about what the requirements are and how to evaluate success. Pure software projects are simpler in some ways because they aim at creating software rather than implementing it and maintaining its value for an organization facing external change.
 

13. WORK SYSTEM SUCCESS

The success of a work system depends on the relative strength of forces supporting the system versus forces and obstacles opposing the system. The forces favoring or opposing the change project may exist within the work system and/or outside the work system. Typical forces within the work system include appropriate or inappropriate information system features, adequate or inadequate technology, and favorable or unfavorable views by work system participants. Forces outside the work system include adequacy of external infrastructure, business pressures, favorable or unfavorable views and ambitions of external stakeholders, and regulations and standards that may or may not favor the changes.

Since some of the forces are inside the system and other come from outside, even perfect analysis of a system’s internal operation does not insure its success. An information system’s operation may satisfy its negotiated requirements only to be undermined or rendered inadequate by changes in the environment that surrounds it. Furthermore, since the supporting and opposing forces often stem from multiple, contradictory goals of various subsystems and of stakeholders outside of the system, it is virtually impossible to design work systems or information systems that are simultaneously optimal on all legitimate criteria.
 

14. INHERITANCE OF GENERALIZATIONS, TRUISMS, AND SUCCESS FACTORS

The fact that both information systems and substantial projects are work systems implies that generalizations, truisms, and success factors related to work systems in general should also apply to information systems and to projects. Furthermore, Figure 3 illustrates that statements about information systems in general should also apply to particular types of information systems, just as statements about projects in general should apply to particular types of projects.


Figure 3. Inheritance of Generalizations, Truisms, and Success Factors Related to
Work Systems, Information Systems, and Projects

The inheritance relationships represented in Figure 3 could be useful in many ways. First, they could help in codifying and interpreting what is known about system success. The information system literature contains numerous discussions of success factors and lessons learned. The sources range from personal experience to carefully researched field studies and surveys. The conclusions from research frequently include obligatory caveats about the limited sample size or special nature of the type of information system that was studied. These caveats often lead to suggestions that more research is needed to extend the findings to other types of information systems. Figure 3 points in a different direction. Attention to which phenomena are related to which level in the diagram might add to the clarity of the results and might lead to the conclusion that additional research may not be needed to replicate the results for different types of systems.

To demonstrate how inheritance of success factors might be presented in practice, Tables 4 through 8 identify what I believe are typical success factors for each of the five categories in Figure 3. Table 4 lists typical success factors related to work systems in general. Table 5 and Table 7 list additional success factors related to information systems in general and projects in general. They do not repeat the work system success factors "inherited" from Table 4. Similarly, Table 6 and Table 8 list success factors related to specific types of information systems and to information system projects but do not repeat the success factors from Table 5 and Table 7 that should be inherited. The specific success factors in all five of these tables are presented as phrases related to the six elements of a work system and plus the infrastructure and context from the surrounding environment.


 
 
Table 4: Success Factors for Work Systems in General
Context · Consistency with Culture 
· Cooperative decisions about work methods
· Low level of turmoil and distraction
Infrastructure · Adequate technical infrastructure for the work system
· Adequate human infrastructure for the work system
Customer and Product · Product design consistent with customer needs
· Adequate product performance
Business process · Fit of business process with other elements
· Adequate resources for business process
· Effective operational management
Participants · Appropriate skills and understanding
· Interest in doing this type of work
· Motivation to do this work in this setting
· Ability to work together to resolve conflicts
Information · Adequate information quality
· Adequate information accessibility
· Adequate information presentation
· Adequate information security
Technology · Ease of use (regardless of whether the technology is IT)
· Adequate technology performance (having enough "horsepower" of 
   whatever type is called for)
· Maintainability
· Compatibility with technology in related systems

 
 
 
Table 5: Success Factors for Information Systems in General
(but not for All Work Systems)
Context · Extensive experience with information systems
· Positive beliefs about information systems
Infrastructure · Adequate support by the IT staff
· Adequate training on content
· Adequate training on plumbing
Customer and Product · (same as in Table 4)
Business process · Comfortable fit with the work system being served
Participants · Familiarity with using computers
·Confidence computers will not be used for de-skilling, job elimination, 
   etc.
Information · Information appropriately tailored to the situation
Technology · Adequate internal design
· Adequate compatibility with technology in related systems
· Adequate documentation
· Adequate performance of technology (adequate speed of computers; 
   response time, etc.)

 
 
 
Table 6: Success factors for Particular Types of Information Systems
(but not for All Information Systems)
Context · Power to enforce usage patterns (pertinent to information systems 
   whose use is mandatory or whose effectiveness requires critical mass) 
Infrastructure · Training and support on complex analysis tasks (for information system
   involving complex content and sophisticated data analysis) 
Customer and Product · Customization of software to match the business process (important 
   when the business process is highly structured) 
Business process · Attainment of critical mass in usage (important for email and other 
   information systems that require critical mass; not important for 
   information systems used individually)
· Fit to decision style (usefulness of collaborative decision tools depends 
   on whether decision making is collaborative)
· Error detection (especially important if the information system 
   automates a process or controls it in real time)
Participants · Fluency in typing (important for information systems requiring a lot of 
   typing by users)
· Mathematical sophistication (important for data mining, certain DSS...) 
Information · Adequate parameter estimates (important for model based DSS)
Technology · (Same as Table 5)

 
 
 
Table 7: Success Factors for Work System Projects in General
Context · Management commitment 
· Management willingness to allocate necessary resources
· Consensus on the need for the project
· Consensus on project governance
· Informed agreement on the requirements
· Culture of cooperation on projects
· Legal or competitive necessity
Infrastructure · Adequate technical infrastructure for the project
· Adequate human infrastructure for the project 
Customer and product · Limited scope of change (The product of the project is change; The 
   greater the intended change, the lower the probability of success.)
· Realistic expectations
· Customer involvement in designing and accepting the project’s product
Business process · Use of a business process tailored to the project
· Experience with the type of business process used for the project
· Appropriate project management
· Attention to implementation in the organization
Participants · Involvement of project participants in all four phases of the project
· Commitment to project success
· Experience doing this type of project
· Confidence by project participants that the project can be done with the 
   human and technical resources that are available
· Incentives that favor timely completion of the project
· Availability of subject matter experts (SMEs) who provide necessary 
   knowledge about the situation
Information · Shared understanding of the project’s goals, rationale, schedule, and 
   resources
· Schedules and deliverables designed to further the work (not delay it) 
   and to help in identifying problems and slippages 
· Expert knowledge about the context and content of the work system 
   being improved or created
Technology · Experience with whatever type of technology is being used for the 
   project
· Adequate technology for performing the project

 
 
Table 8: Success Factors for Information System Projects
(but not Work System Projects in General)
Context · Positive beliefs about information systems
· Inclusion of the overall information system effort the organization’s plan 
   (thereby legitimizing the project)
Infrastructure · Adequate information system architecture, networks
· Adequate IT support staff
Customer and product · (Same as Table 7)
Business process · Careful testing of software and technical configurations
· Frozen requirements during programming and testing (unless the 
   project involves use of a prototype)
Participants · Comfortable relationship between IT staff and work system participants 
   and their management
· Involvement in detailed analysis of information system content
Information · Adequately clear requirements for content and for plumbing
· Adequate external specification
· Adequate internal specification
Technology · Adequate attention to internal design and technical robustness

 
My general belief is that the most important success factors occur at the level of work systems in general and information systems in general rather than at the level of particular types of information systems. Also, notice that Table 6 (success factors for particular types of information systems) focuses on verifiable operational characteristics such as whether or not usage is mandatory and whether critical mass is important. It does not focus on traditional system types (TPS vs. MIS vs. DSS, etc.) because there is little agreement about the characteristics that reliably link any particular system to one category or another.

In addition to organizing existing knowledge, the inheritance relationships could be used to interpret the results of new empirical research. For example, the conclusions of the next paper published on DSS in finance organizations could identify the findings that seem to be about work systems in general, the findings about information systems in general, the findings about information systems in finance organizations or about DSS in particular, and so on. At minimum, this approach would help avoid the fallacy of concluding that very general phenomena are unique characteristics of particular types of systems.

The inheritance of generalizations about work systems could also motivate additional links between the disciplines of organizational behavior and information systems. For example, an attempt to identify generalizations at the top level might help in "importing" organizational behavior ideas that are significant for information systems even though they are typically observed and studied when information technology is unimportant or absent.
 
 

V. CONCLUSION

This paper  presents a general theory of information systems that could be useful to business and IT professionals and academic researchers and that could be equally applicable to all information systems of today, of 20 years ago, and of the near term future. The theory presented here started from an unusual premise, namely, that in order for a business professional to understand an information system it is necessary to understand the work system that the information system serves. The theory included a number of distinctions, such as work system vs. information system, work system vs. business process, content vs. plumbing, participant vs. user, different roles of information systems within work systems, and the inheritance of work system generalizations by information systems and projects (because they are work systems in their right).

Aside from its role in the proposed theory, the distinction between information systems and work systems is useful for business professionals, IT professionals, and researchers. Most business professionals probably care more about a work system than about an information system that serves it. Business professionals would therefore do well to analyze their own work system (at least superficially) before thinking about how to use or improve an information system and before looking at the features and benefits proposed by software vendors and IT professionals. In turn, software vendors and IT professionals would probably do well to understand more about a specific work system before suggesting an information system "solution" to problems in that system. When looking at the work system, they should focus on the system participants and the context in addition to the idealized business process and information requirements.

The distinction between work systems and information systems is also potentially useful in interpreting research related to the impact of changes or improvements in information systems. These changes often contribute to better (or worse) organizational results, but the impact of the information system per se is often difficult to separate from the impact of other changes in the work system.
 

Homework Exercises

It is easy to claim that this type of theory is potentially useful, but you might not believe the claim without an empirical demonstration. Although a careful experiment could take years, you can test the theory informally by trying to apply it to situations and ideas you are familiar with. Papers proposing a theory typically do not end with a set of homework exercises for the reader but I do believe that an interested reader should have a way to validate the ideas without designing an experiment and waiting two years for the results. Please consider doing any of the following exercises in any amount of depth to decide whether this paper provided useful ideas:

1. Identify a number of empirical research studies you are familiar with. Without reviewing them in  detail, try to decide whether each study is really about a work system, an information system, or software. After doing this, look at the published studies, focus on the hypotheses and research findings, and decide whether they are really about a work system, an information system, or software. Explain any discrepancies in what you find.

2. Identify a number of current information system terms that are at least partially about information system content such as data mining, OLAP, executive information system, knowledge management, groupware, intranet, electronic commerce, enterprise system, etc. (and not plumbing-related terms such as Java, Linux, TCP/IP, ADSL, etc.) Separately interpret each topic as a work system, an information system, and software. Look at several articles about any topic and decide whether these articles are looking at it as a work system, information, or software, or, alternatively, whether it isn’t clear which level the article is looking at.

3. Examine this theory (not just the limited examples and explanations in the paper) and identify parts of it that could be omitted without reducing its usefulness. Also identify things that it omits but that should be included.

4. Compare this theory of information systems with any other theory of information systems you are familiar with. Identify areas of overlap and non-overlap. Identify situations in which one theory would be more useful than the other.

Editor’s Note: This paper was received on February 26, 1999 and was published on March 26, 1999.
 
 

REFERENCES

Alter, S. (1980) Decision Support Systems: Current Practice and Continuing Challenges. Reading, MA: Addison-Wesley.

Alter, S. (1999) Information Systems: A Management Perspective. 3rd ed. Reading, MA: Addison-Wesley Longman.

Checkland, P. and J. Scholes (1990). Soft Systems Methodology in Action. Chichester, England: John Wiley and Sons.

Churchman, C. W. (1979) The Systems Approach (revised and updated) New York: Dell Publishing.

Cusomano, M.A. and R. W. Selby (1997) "How Microsoft Builds Software," Communications of the ACM 40(6), June 1997, pp. 53-61.

Davis, G. (1969) Computer Data Processing, 2nd ed., New York: McGraw-Hill, p. 195

Falkenberg, E. D., W. Hesse, and A. Olive, eds. (1995) Information System Concepts: toward a consolidation of views. Proceedings of the IFIP international working conference on information system concepts, Marburg, Germany, Mar. 28-30, 1995. London: Chapman & Hall.

Gefen, D. and M. Keil. (1998) "The Impact of Developer Responsiveness on Perceptions of Usefulness and Ease of Use: An Extension of the Technology Acceptance Model," The Data Base for Advances in Information Systems, 29(2), Spring 1998, pp. 35-49.

Hersleb, J., et al. (1997) "Software Quality and the Capability Maturity Model," Communications of the ACM, (40)6, June 1997, pp. 31-40.

Herzenberg, S. A., J. A. Alic, and H.Wial. (1998) New Rules for a New Economy: Employment and Opportunity in Postindustrial America, ILR Press: A Twentieth Century Fund Book

Larsen, T. J., L. Levine, and J. I. DeGross, eds. (1998) Information Systems: Current Issues and Future Changes. Proceedings of the IFIP WG 8.2 and 8.6 Joint Working Conference on Information Systems: Current Issues and Future Changes, Helsinki, Finland, Dec. 10-13, 1998.

Markus, M. L. (1984) . Systems in Organizations: Bugs & Features. Boston: Pitman.

Mumford, E and M. Weir (1979). Computer Systems in Work Design – the ETHICS Method. New York: Wiley.

Myers, M.D., D. Robey, C. Sauer, and G. Walsham (1998) "Practical and Theoretical Frameworks: Valuable Aids or Seductive Traps," pp. 303-305 in Larsen, T. J., L. Levine, and J. I. DeGross, op. cit.

Orlikowski, W. and J. D. Hofman (1997). "An Improvisational Model for Change Management: the Case of Groupware Technologies," Sloan Management Review, Winter 1997, pp. 11-21.

Scott, J. C. (1998) Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed, New Haven: Yale University Press, p. 310.

Warner, Melanie (1999) "The Beauty of Hype: a Cautionary Tale of Silicon Valley," Fortune, Mar. 1, 1999, p. 142.
 
 

ABOUT THE AUTHOR

Steven Alter is Professor of Information Systems at the University of San Francisco. He holds a B.S. in mathematics and Ph.D. in management science from MIT. He extended his 1975 Ph.D. thesis into one of the first books on decision support systems. After teaching at the University of Southern California he served for eight years as co-founder and Vice President of Consilium, a manufacturing software firm that went public in 1989 and was acquired by Applied Materials in 1998. His many roles at Consilium included starting departments for customer service, training, documentation, technical support, and product management. Upon returning to academia, he wrote the textbook Information Systems: A Management Perspective. The third edition of that text was published in October,1998. His articles have appeared in Harvard Business Review, Sloan Management Review, MIS Quarterly, Interfaces, Communications of the ACM, Futures, The Futurist, and many conference transactions.

Copyright ©1999, by the Association for Information Systems. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than the Association for Information Systems must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or fee. Request permission to publish from: AIS Administrative Office, P.O. Box 2712 Atlanta, GA, 30301-2712 Attn: Reprints or via e-mail from ais@gsu.edu
 
 






EDITOR
Paul Gray
Claremont Graduate University

            AIS SENIOR EDITORIAL BOARD

Henry C. Lucas, Jr.
Editor-in-Chief
New York University		 Paul Gray 
Editor, CAIS Claremont Graduate University		 Phillip Ein-Dor 
Editor, JAIS
Tel-Aviv University
Edward A. Stohr
Editor-at-Large
New York University		 Blake Ives 
Editor, Electronic Publications 
Louisiana State University		 Reagan Ramsower
Editor, ISWorld Net
Baylor University

            CAIS ADVISORY BOARD

Gordon Davis
University of Minnesota		 Richard Mason
Southern Methodist University 		 Jay Nunamaker 
University of Arizona
Henk Sol
Delft University		 Ralph Sprague
University of Hawaii		  

         CAIS EDITORIAL BOARD

Steve Alter
University of San Francisco		 Barbara Bashein
California State University		 Tung Bui
University of Hawaii		 Christer Carlsson 
Abo Academy, Finland
H. Michael Chung 
California State University		 Omar El Sawy 
University of Southern California		 Jane Fedorowicz
Bentley College		 Brent Gallupe
Queens University, Canada
Sy Goodman 
University of Arizona		 Chris Holland 
Manchester Business School, UK		 Jaak Jurison 
Fordham University		 George Kasper 
Virginia Commonwealth University
Jerry Luftman 
Stevens Institute of Technology		 Munir Mandviwalla 
Temple University		 M.Lynne Markus 
Claremont Graduate University		 Don McCubbrey
University of Denver
Michael Myers
University of Auckland, New Zealand		 Seev Neumann Tel Aviv University, Israel Hung Kook Park 
Sangmyung University, Korea		 Dan Power 
University of Northern Iowa
Maung Sein
Agder College, Norway		 Margaret Tan 
National University of Singapore,Singapore		 Robert E. Umbaugh
Carlisle Consulting Group		 Doug Vogel 
City University of Hong Kong, China
Hugh Watson 
University of Georgia		 Dick Welke
Georgia State University		 Rolf Wigand 
Syracuse University		  Phil Yetton 
University of New South Wales, Australia

             ADMINISTRATIVE PERSONNEL

Eph McLean 
AIS, Executive Director
Georgia State University		 Colleen Bauder
Subscriptions Manager
Georgia State University		 Reagan Ramsower
Publisher, CAIS
Baylor University