how should business professionals analyze information systems for

How should business professionals analyze information systems for themselves?

Steven Alter

University of San [email protected]

This paper was submitted to the 1995 MIS

Quarterly special issue on MIS education, but

was not accepted.

1

How should business professionals analyze information systems

for themselves?

ABSTRACT:

Introductory courses in information systems for business majors are often unpopular and frustrating to teach, partially because they cover an excess of vocabulary and technical details but miss what the audience really wants (or should want). Business professionals should want an integrated approach they can internalize and use effectively for analyzing and designing systems from a personal, business-oriented viewpoint. The purpose of their analysis should be to gain insight about a system and to collaborate effectively with the IS staff, vendors, and colleagues, rather than to do the work of IS professionals creating and documenting a rigorous hardware and software specification.

This paper discusses an attempt to develop a systems analysis method for business professionals. The WCA (work centered analysis) method starts with a framework for creating a system snapshot based on six elements: 1) the business process, 2) the products and/or services the business process generates, 3) the internal or external customers of the business process, and the 4) participants, 5) information, and 6) technology involved in the business process. The WCA method organizes a business professional’s analysis and (re)design of a system by using this framework from five distinct perspectives: 1) architecture, 2) performance, 3) infrastructure, 4) context, and 5) risks. This method implies that the natural unit of analysis for business professionals is the business process, not the information system. Implications for teaching and research are discussed.

keywords: systems analysis, business process, IS evaluation, IS design, information requirements determination, IS development methods and tools, IS educationISRL categories: AH05, DD0402, E101, FB03, FB04, FC, IA01

The current difficulties with introductory IS courses stem from many causes, one of which is the lack of genuinely helpful concepts and frameworks typical business professionals can use to analyze and design systems for themselves. Their analysis and design efforts should be directed toward gaining insight about the systems they have and the systems they really want, rather than toward creating rigorous technical specifications. Gaining insight should help them develop or acquire their own systems in simple situations and should aid communication with their business colleagues and the IS staff and vendors who do the technical work of building and maintaining the systems.

The lack of genuinely useful core concepts is just as evident in detail-laden basic textbooks as in overly abstract research papers. The excuse that it takes a long time for emerging fields to become coherent doesn’t help us deal with our current problems in business schools. Too many students don’t see the point of

3

much of what we teach and many of our colleagues in other fields no longer see mystery in the computers they use every day.

This paper describes an applied research project aimed at developing a method typical business professionals could use to analyze and design information systems from their own personal viewpoint. This method was developed over several years through numerous iterations of presentations and write-ups used by MBA and EMBA students to understand real systems in their businesses. The method is based on business ideas such as TQM, process re-engineering, and empowerment. Its central concern is not information technology, not information, not the user, not the user organization, and certainly not management. Rather, it is the work being performed, in other words, the business process the information system supports. After describing the search for basic ideas about information systems, the paper summarizes the method that was developed along with direct and indirect feedback about its effectiveness in analyzing real world systems. The final sections discuss implications for teaching and research.

SEARCHING FOR THE BASIC IDEAS

Based on a combination of academic and business experience I have had a long term concern about difficulties students in introductory IS courses have in writing papers about real world systems. Although it is easy to find fault with the students, it is also possible that their omissions and confusions indicate something is missing from what is being taught. An opportunity to give a series of guest lectures provided a unique way to work on this issue. Visiting universities and several research institutions, I delivered 22 iterations of a talk whose true goal dawned on me about half way through the effort:

Assume that I have one hour to give a presentation to a small group of business professionals who will soon attend a meeting about a particular system in their business. Like many business professionals they understand their own business context, have some understanding of technology through the use of spreadsheets, word processors, or other computer applications, but may have never received explicit training about systems. I need to give a one-hour presentation that will probably help them. Unfortunately, I have to live with three unreasonable ground rules:

1) I cannot know what job or business background the people have. They may be system users, programmers, top managers, or anyone else who cares about the system. They may be working for a grocery store, an airline, a computer company, or any other type of firm.

2) I cannot know what type of system they will be discussing. It may be a telephone voice mail system, a customer billing system, or an information system for managers.

3) I cannot know the agenda of their meeting. They may be reviewing an existing system, evaluating a proposal from a software vendor, or designing a new system.

Is there anything I could say that would probably be useful even with these unreasonable ground rules? If so, I would have found basic

4

ideas business professionals can understand and internalize to gain insight about their systems. These ideas would be the basis for the introductory course, and they would help in seeing where our field is going.

When I believed the ideas were reasonably coherent after 22 iterations of the talk during 1992-93, I produced and distributed several iterations of a 30-35 page write-up to MBA and executive MBA students during 1993-94. They used it while writing papers about systems in their businesses and later provided written feedback about their personal reactions to the usefulness of the approach.

This research on the basic IS ideas was done using an industrial research model rather than an academic research model. The goal was not to create a trail of experimental data that could be analyzed carefully, but rather to develop a useful method as rapidly as possible. The method has now stabilized enough that it can be tested in a traditional experimental approach such as the one used by Boland (1978) in his study of alternatives for generating system design ideas.

The result of the research to date is a method business professionals can use to gain a quick initial understanding of specific systems in their business environment. The “work centered analysis” (WCA) method uses a six-element framework for creating a one-page system snapshot, and then goes into more depth by looking at the current and proposed system from five perspectives. The WCA method is designed to help business professionals gain insight about a system. It does not attempt to be a rigorous requirements analysis or system methodology, and must be supplemented by other techniques during a system development process. Although designed for use by business professionals, it is also potentially valuable for IS professionals as a way to communicate more effectively with users and managers. For example, its use might help avoid some of the problems Davidson (1993) observed in JAD sessions that miss a true dialogue because they are run by the IS staff to obtain the information the IS staff needs.

The next two sections summarize the latest version of the WCA method and present some of the ideas and observations that led to its current form. The final section of the paper discusses implications related to the introductory IS course and other aspects of the IS field.

THE WCA METHOD: USING A FRAMEWORK TO LOOK AT WORK FROM MULTIPLE PERSPECTIVES

The WCA method consists of a framework for summarizing a system and general guidelines for an analysis and design process using the framework from five perspectives. It is summarized here, was presented to the MBA and EMBA students in a more detailed write-up, and has been explained in additional layers of depth elsewhere (publication by author, 199X). The WCA method is based on the idea that business professionals can and should analyze business systems by focusing on the work done by the system. Work is the application of human and physical resources such as people, equipment, time, effort, and money to produce outputs used by internal or external customers. Work occurs only if

5

product and/or service outputs are generated for use by internal or external customers.

Framework for thinking about systems in business

Figure 1 shows a general framework for thinking about systems in business by focusing on the work being done. Although initially developed to help understand applications of information technology, this framework can be used to think about any business process or information system. Consistent with the need to emphasize business issues such as process improvement, customer focus, empowerment, and alignment, the framework consists of six linked elements: the internal or external customers of the business process, the products (and/or services) generated by the business process, the steps in the business process, the participants in the business process, the information the business process uses or creates, and the technology the business process uses.

The box surrounding business process, participants, information, and information technology indicates that those four elements are the system performing the work. If processing information plays any role in performing the work, which is almost always the case, part of the system is an information system. The work system’s output is the product, which is used by its customers. Including the product and customer in the picture even though they are not part of the system reflects the TQM notion that the customer is the ultimate judge of quality.

All of the links in the framework are two-way, implying that all the elements should be in balance. For example, the participants should fit the business process and the product should fit the expectations of the customers. Any imbalance in the system usually implies a need for change. The two-way links also imply that a change in any area may result in changes in any of the other areas. For example, availability of more powerful technology could affect every other element of the framework. By making more information accessible, the new technology could permit business process changes which in turn affect the skills required of participants and the quality of the product received by the customer.

6

Figure 1: Framework for thinking about systems in business.This framework consisting of six linked elements can be used for thinking about any system in business. This book emphasizes ways it can be used for analyzing business processes and the information systems that support them.

• impacts of other business processes? • organizational policies, practices, plans

products

customers

participants

technology

business process

information

Except for the arrow connecting customer and product, all the arrows in the diagram are attached to the business process. This implies that the business process is the central focus for summarizing a system. If the customer is unhappy with the product, the business process should change. If the participants cannot perform as required, either they must change through training, motivation, or replacement or the business process must change.

There is no link between technology and participants because the framework was designed primarily for thinking about business processes in which information technology is the main technology being considered. Even though certain forms of information technology may affect participants directly in some ways (such as by requiring computer related skills or by giving them eyestrain), the main impacts on participants typically result from the nature of the business process rather than the technology per se. In situations involving other types of technologies, such as x-rays or potentially harmful chemicals, a direct link between technology and participants might be added to the framework.

7

Figure 2 is an example of a system snapshot based on the framework. This particular example summarizes Wal-Mart’s inventory replenishment system based on brief descriptions in magazine articles. The major steps in the business process include identifying items sold to consumers, providing receipts to consumers, analyzing sales data, and reordering inventory. The basic approach is to collect sales data during customer checkout and transmit the data to buyers and suppliers daily. The product of the business process includes receipts for shoppers and availability of inventory and sales data, resulting in low inventory levels without reducing service and coordination with suppliers. The customers of the process include shoppers (who receive receipts for their purchases) and suppliers (who receive replenishment orders). Any such diagram is a simplification of reality providing only a brief snapshot and leaving out many features essential for understanding the situation. But it is useful because it identifies six elements a business professional can start learning about in just a few minutes. Business professionals unable to do this don’t understand the system well enough to start an analysis. In addition, the framework encourages thinking about the system using TQM focal points including the customer, the product, the business process, and the participants. Too often, business professionals mislead themselves by focusing on technology and information rather than what matters most to them, the business process and what it produces. Finally, the summary can be used to start a dialogue since others in the firm might draw the summary differently. By highlighting disagreements the effort to produce an agreed upon version of Figure 2 would be a useful starting point when collaborating with others to analyze or design a system.

8

Figure 2: Snapshot of Wal-Mart’s inventory systemThe framework is used here to summarize Wal-Mart’s system for tracking and reordering inventory. If a summary of this type is successful it provides a feeling for the things a business professional should think about even though it leaves out most of the details in the system.

• receipts for shoppers • availability of current inventory and sales data, permitting: - low inventory levels without reduced service - coordination with suppliers

• detailed listing of each shopper's purchases • price, inventory level, and daily sales for each product

• checkout clerks • employees who control and order inventory

• bar code scanners • computers • telecommunications equipment

• shoppers • suppliers

• impacts of other business processes? • organizational policies, practices, plans

products

customers

participants

technology

business process

information

major steps: • identify items sold • provide receipts • analyze sales data • reorder inventory

basic approach: • collect sales data during customer checkout • transmit data to buyers and suppliers daily

Five perspectives for thinking about a system

The WCA method uses the framework to look at work from the multiple perspectives necessary for understanding any existing or proposed system in business. As summarized in Table 1, the perspectives include architecture, performance, infrastructure, context, and risks.

1) The architecture perspective looks at how the current or proposed system operates mechanically by summarizing its components, the way the

9

components are linked, and the way the components operate together. The term architecture applies equally to processes, information, technology, and organizations. For example, information architecture is a statement of how information is organized within a system, whereas organizational architecture is a statement of how the people and departments are organized. Architecture is dealt with in two ways. First, as is often done using data flow diagrams, flow charts, or other diagramming methods, it can be documented using diagrams showing sets of linked components. In addition, it can be described conceptually using ideas such as degree of structure, degree of integration, range of involvement, reliance on computers, attention to planning and control within the process, and provision for recovery from errors and malfunctions.

Table 1: Issues raised by five perspectives for understanding an existing or proposed system in businessFive perspectives each raise a set of questions that should be considered when analyzing a system from a business professional’s perspective.

perspective key issuesArchitecture • What are the components of the system that produces the work and

uses the work product?• How are the components linked?• How do the components operate together?

Performance • How well do the components operate individually?• How well does the system operate? (How well is the work performed?)• How well should the system operate?

Infrastructure • What technical and human infrastructure does the work rely upon?• In what ways does infrastructure present opportunities or obstacles?

Context • What are the impacts of the organizational and technical context?• In what ways does the context present opportunities or obstacles?

Risks • What foreseeable things can prevent the work from happening, can make the work inefficient, or can cause defects in the work product ?• What are the likely responses to these problems?

2) The performance perspective uses business terms to describe how well the system or its components operate. For example, product performance can be measured in terms of price, quality, responsiveness, reliability, and conformance to standards or regulations, whereas process performance can be measured in terms of capacity, consistency, productivity, cycle time, flexibility, and security. One of the TQM movement’s main tenets is that many businesses need better process measurement to guide process improvement.

3) The infrastructure perspective describes the resources the system depends upon and shares with other systems. Infrastructure is typically not under control of the systems it serves, yet plays an essential role in those systems. For information systems, the technical infrastructure typically includes computer networks, telephone systems, and software for building and operating these systems. The human infrastructure for these systems is the support staff that keeps them operating effectively. Examining infrastructure often reveals

10

constraints limiting the changes that can occur, but may also reveal untapped opportunities to use available resources.

4) The context perspective describes the organizational and technical realm within which the current or proposed system operates, including non-participating stakeholders, competitive and regulatory issues external to the firm, resources outside of the system, and implementation issues related to the organization’s policies, practices, and culture. The context may create incentives and even urgency for change, but may also create obstacles.

5) The risks perspective looks at foreseeable events whose occurrence could cause system degradation or failure. General categories of risks can be identified for each of the elements of the framework. For example, risks related to information include data errors, data fraud, and data theft. Since every business system has some risks any effort to build or change a system should include identifying foreseeable risks and deciding on either countermeasures or acceptance of the risks.

An analysis and design process

Figure 3 illustrates the steps in the systems analysis process and shows how the framework and perspectives are used. The steps are as follows:

11

Figure 3: Steps in systems analysis for business professionalsSystems analysis iterates between defining system scope, describing the system, and proposing improvements. The description and improvement stages each use the same five perspectives: architecture, performance, infrastructure, context, and risks. The final step is selecting among alternatives based on tradeoffs, constraints, uncertainties, decision criteria, and implementation issues.

• i mpacts of other busi ness processes?

• organi zati onal pol i ci es, practi ces, pl ans

determine scope and purpose of the analysis

describe the current situation

design potential improvements

select among alternatives





• tradeoffs • constraints • uncertainties • decision criteria • implementation





• architecture • performance • infrastructure • context • risks

• architecture • performance • infrastructure • context • risks

1) Determine the scope and purpose of the analysis: Decide what problem is being solved. The scope of the problem is defined primarily by the scope of the business processes included in the analysis.

2) Describe the current situation: Describe the existing system from five perspectives: how it operates, how well it operates, what infrastructure it relies

12

upon, what context it operates in, and what risks affect it. Look at each element of the framework within all five perspectives.

3) Design potential improvements: Suggest ways of changing one or more elements to improve the system’s performance. Describe potential changes in architecture and estimate how they will be reflected in the other perspectives, namely, performance, infrastructure, context, and risks . Because the six elements in the framework are linked, architectural changes in any element usually call for corresponding changes elsewhere.

4) Select among alternatives: Use the understanding developed through the first three steps to decide what to do. Make the decision considering issues such as tradeoffs, constraints, uncertainties, decision criteria, and feasibility of implementation in the organization.

Figure 3 shows that each systems analysis step can be performed using the six-element framework. Applying a single framework from many perspectives helps keep the analysis coherent and helps avoid excessive attention to tangential issues. It also shows that the process is iterative, consistent with the way people typically identify a problem they want to think about and then redefine the problem after gathering information that helps them understand it. Note that the steps in Figure 3 seem to apply to a single system or business process. If the situation being analyzed contains several major subsystems, the steps can be used to examine each subsystem separately, and then to examine the overall system.

Even though it might seem obvious that systems analysis and design should involve something like the steps in Figure 3, two important objections should be considered. First, it is reasonable to ask whether studying the current situation before proposing potential improvements could be counterproductive in some cases. Starting by analyzing the current situation carefully might encourage taking certain things for granted, thereby making it less likely that radical, new ideas will emerge. If the goal is radical change, starting with general objectives and a blank sheet of paper might be more appropriate even though detailed system design and implementation will require careful attention to the current system.

An additional objection might be that the process described in Figure 3 is too cumbersome and involves too many steps. Specifically, it seems to ask the business professional to look at the same six elements eleven different times, once for the purpose and scope, five times each to look at the current system and potential improvements from the five perspectives. Inclusion of all these considerations does not mean that business professionals need to produce overlapping documentation eleven different times. The issues raised are inescapable and ought to be considered, regardless of how they are combined or reported in a written document or oral presentation.

Ideally, any business professional should be able to use the WCA method for thinking about business processes and the information systems that support them. Its purpose is to provide an organized approach for thinking about systems, but it is definitely not either a cookbook anyone can follow mindlessly or a strait jacket that forces adherence to a procedure. The WCA method contains many ideas that can be applied when thinking about any system in business. If some ideas do not resonate for a particular situation, they should be skipped. If some important ideas involve organizational or political issues too difficult to discuss with certain individuals, so be it. At least the business

13

professional doing the analysis will have been more likely to consider these points by following an organized approach.

Unlike analysis and design methods for system builders, this method makes no attempt to create a rigorous specification of a desired system. Instead, it is designed to help business professionals think about different facets of a system so that their interactions with other business professionals and with system builders will be more effective. The guidelines presented here are not meant as a dogmatic statement of exactly how systems must be analyzed. Rather, they are guidelines for encouraging coverage of issues business people understand and care about.

Although designed to be very general, the WCA method has important limitations. Like any framework or general problem solving approach, it is not a formula or cookbook. Using it effectively requires judgment. It applies most directly to business processes containing identifiable steps occurring over time and producing a recognizable output, and is not as effective when applied to broad, amorphous activities such as “management” or “communication.” For example, while it can help in thinking about a telephone system or even about how a computer operates internally, it is more useful in thinking about a sales, finance, or production process that occurs over time. The limitation in regard to amorphous activities also raises a caution flag, however, since information systems directed at poorly defined activities are often ineffective due to lack of user understanding about how to gain benefits from using them.

SOURCES OF IDEAS

The WCA method was developed through many iterations starting with ideas from the general business environment and academic literature and evolving based on pitfalls observed in student papers and on direct feedback from students.

Initial ideas from business and academic sources

The initial presentation that evolved into the WCA method was a loose combination of ideas from general systems theory, problem solving models, sociotechnical systems analysis, TQM, and business process re-engineering.

• General systems theory provided an initial vocabulary for thinking about systems, such as subsystem, environment, input, output, division of labor. It raised issues about what really was the system, leading to the conclusion that the business process was the most useful unit of analysis. But it seemed too general and not prescriptive enough in relation to information systems to provide the direction typical business professionals require in analyzing information systems.• General problem solving models such as Simon’s led to the inclusion of the problem solving process in Figure 3 (scope, description, design, selection) rather than just a set of concepts for describing systems. But these models were again too general to be the primary basis of a method for analyzing information systems.• Work design and sociotechnical systems analysis encouraged considering both the technical system (techniques for doing work) and the social system (people and relationships between people). But these ideas

14

seemed to provide too little guidance about describing and evaluating system elements. (For references see Hirschheim and Klein, 1994.) • Total quality management provided ideas such as focusing separately on products and processes, recognizing that customers evaluate the outputs of a process, and recognizing the need for performance measurement and genuine involvement by process participants. These ideas had the most direct effect on the WCA method as it evolved. • Business process re-engineering reinforced the need to focus on the process and showed the desirability of starting the analysis from the premise that anything can change, including the organization and the work that is done. But its insistence on radical change made it inappropriate as a general approach for analyzing information systems. • The system development life cycle provided a rigorous process including identifying what specific information is used by specific business processes. But system life cycle models seemed more involved with controlling projects and creating documentation rather than with helping business professionals think about information systems.

Pitfalls revealed in papers by MBA and EMBA students

The WCA method evolved further based on what I identified as confusions and omissions in papers written by evening MBA and EMBA students about systems in their businesses. The current form of the WCA method was developed to help alleviate some of the pitfalls these students encountered. Common pitfalls are listed in Table 3 along with earlier modifications of the WCA method to reduce the likelihood the same problems would arise again in using later versions.

Table 3: Pitfalls encountered in attempts to use earlier versions of the frameworkThe common pitfalls listed here led to superficial systems analysis when evening MBA students used earlier versions of the WCA method, which was then modified to help avoid these pitfalls.

pitfall example related feature in the framework or perspectives

difficulty distinguishing between software and business processes

talking about desktop publishing software as though it were the entire document production process

The framework distinguishes between the business process and the technology.

failure to distinguish between the customer’s view of the product and the internal view of the process

looking at quality as an internal business process issue rather than as a customer-related issue, or looking at the internal cost of a production without looking at the total life cycle price paid by the internal or external customer

The framework includes the customer, the product, and the business process. The perspectives provide terms for looking at each separately.

difficulty defining the difficulty deciding whether the The framework separates the

15

boundaries of the system,

system is the entire sales process or just the part of the sales process that involves determining customer requirements

product from the process, and puts a box around the four elements within the system.

over-emphasis on small architectural details

explaining the process of generating government mandated reports as many tiny steps instead of several steps each of which could be subdivided if necessary

The system summary includes separate entries for summarizing the major steps and for describing the basic approach.

difficulty discussing architecture conceptually

avoiding conceptual issues such as whether the overall process should be more (or less) structured, more (or less) integrated, and more (or less) flexible

The architecture perspective separates entries for identifying the steps from other entries for discussing the business process conceptually.

avoidance of topics related to measurement and evaluation

saying the information was adequate but not discussing the error rate, or saying a business process was fast but not specifying how long it actually took

A separate performance perspective is included to encourage consideration of these issues.

tendency to ignore infrastructure issues

talking about implementation issues without talking about the role of the support staff

A separate infrastructure perspective is included.

tendency to ignore political and technical context

suggestions about building a system using object-oriented programming without considering organizational issues and technical compatibility

A separate context perspective is included.

tendency to assume systems will work as planned

talking about computerized systems uncritically without ever mentioning the things that could go wrong

A separate risk perspective is included.

temptation to use the approach as a cookbook rather than a guide

writing out the framework in detail so many times that it becomes tedious (for example, once for scope, five times for description, and five times for proposing improvements).

Explanations of the framework always say it is not a cookbook or fill-in-the-blanks approach.

Written feedback from EMBA students

As the first of two major projects in the course, students in an Executive MBA class in the Spring of 1994 wrote individual papers responding to the following assignment: “Use the systems analysis guide and other ideas we cover in class to analyze an information system in your organization. Since the purpose of the course is to give you ideas for thinking about information systems, part of your grade will be based the degree to which the paper demonstrates your understanding of these ideas.”

After the papers were turned in and 10 were presented orally by volunteers who thought their situations would be especially interesting to other class members, the students filled out a feedback form asking for a 1 (not useful)

16

to 5 (very useful) rating of the framework, a 1 to 5 rating of the usefulness of the WCA method (in its previous form), and any additional comments or suggestions for improvements. To encourage everyone filled out the form thoughtfully, it was given as a homework assignment and counted as five percent of the grade. From the outset it was clear to the students that the ideas were being developed and that genuine feedback was desired. The comments were discussed openly in class, and ran the gamut from positive to negative.

Figure 4 shows there was much greater agreement about the value of the framework than about the value of the entire WCA method. Comments in Table 4 indicate that students who found the WCA method less valuable viewed it as cumbersome and somewhat redundant since it used the same framework repeatedly to look at different aspects of a situation. But other students found this quite valuable as an organized way to think about the systems they were analyzing. The version of the WCA method explained earlier is a revision of the version these students. The revision attempted to clarify some terminology (such as changing “description & evaluation” to “performance”) and to make the use of the five perspectives seem less cumbersome. The key issue in this regard is that anyone using any systems analysis method simply has to use judgment in deciding how much to say, write, or think about each topic.

Figure 4: Evaluation of the framework and WCA method by executive MBA studentsTwenty EMBA students provided these rankings along with comments on feedback forms after using a version of the WCA method to analyze an information system in their business.

evaluation of the framework

rating (5 = very useful)

02

468

1012

1 2 3 4 5

number of responses

evaluation of the FMP method

rating (5 = very useful)

0

2

4

6

8

10

1 2 3 4 5

number of responses

Table 4: Selected comments about the framework and WCA method by executive MBA students

17

These selected comments were chosen to identify the main benefits and issues seen by EMBA students who used the framework and WCA method to analyze an information system. The WCA method was subsequently revised to incorporate this feedback.

comments about the framework:

• I think the framework is very good for ensuring that you consider information systems in the context of your overall business process.• very useful for understanding and approaching systems analysis. Makes it very simple to overcome “writer’s block” when getting started. Excellent communication tool. I plan to use a variation of this to teach.......• The greatest value was in challenging my view and thought process.• The framework was extremely helpful for me to see how the process really works, why it works well, and what the components are.• I found the focus on the customer and business processes quite useful.• There is a learning curve involved in using the framework. Also from a facilitator’s point of view pre-work would need to be designed for a team who would use this.

comments about the WCA method (later revised to incorporate this feedback):

• I thought the high level groupings -- scope, architecture,... to be useful. I did, however, find that it got tedious going through the customers, products, processes... cycle for each of the categories. Perhaps this could be condensed somehow.• The highly structured analysis was very helpful. I unearthed some issues I hadn’t previously identified in spite of a rather thorough analysis.• The process is too cumbersome to use for systems you and others are somewhat familiar with. I think it has great value when you are analyzing a system that is new to you.• Following the system mechanically is not very good; also leads to a false sense of security. You feel you have covered everything since you’ve done the analysis from all 6 points of view.• I think it would be vastly more usable by the novice if it were set up like a work book with a series of questions posed at each step. As it is, I think a typical business person would become bogged down in terminology and layers of analysis unless they were looking at an extremely simple process.• Too much detail. The opposite way managers are trained to write in a business environment.• A very logical thought process. As a business person it tends to seem very detailed. .... Bottom line, the experience is very beneficial in helping me to communicate with the MIS department.

other comments and suggestions:

• For baseline analysis [the framework] can assist to “walk-thru” the components of enabling systems for business needs. The strategic impact of the business process and where integration with other processes (can and will occur) has not been addressed. Also missing is the facilities questions (physical capacity, location, etc.)• I found it hard to think about the customers as separate from the products. I also had difficulty separating the business process from the participants.• In the particular case studied I thought the model could use a feedback loop as

18

customers change to participants and then to customers again.

The concluding sections of the paper will look at issues related to the natural unit of analysis for business professionals and implications for future teaching and research.

WHAT IS THE NATURAL UNIT OF ANALYSIS FOR BUSINESS PROFESSIONALS?

The development of the WCA method started as a search for a way business professionals can analyze information systems effectively, but ended up with a framework (Figure 1) that doesn’t identify the information system explicitly. Instead, the business process appears explicitly and is highlighted in the center of the framework, whereas the information system appears implicitly as the part of the larger system that happens to use information and technology. Stated differently, the WCA method is based on the assumption that the business process, rather than the information system or the information technology, is the natural unit of analysis for business professionals.

The relationship between information technology, information systems, and business processes

To explore this issue, Figure 5 reveals a series of different levels for defining “the system” being considered in any particular situation. A business professional could think of the system as the information technology, as the information system that uses the technology, as the business process that contains or is supported by the information system, or as the firm that consists of multiple business processes.

• Information technology is the hardware and software used by information systems. • An information system is a particular type of business process, one that uses information technology to capture, transmit, store, retrieve, manipulate, and/or display information, thereby supporting one or more other business processes. Software products ranging from spreadsheet and word processing software to DBMS and EIS software are not information systems because they are not business processes in their own right. • A business process is a related group of steps or activities that use people, information, and other resources to create value in the form of products and/or services for internal or external customers. Business processes consist of steps related in time and place, have a beginning and end, and have inputs and outputs (Harrington, 1991, Davenport 1993). • A firm (or government organization) consists of a large number of interrelated business processes that work together to generate products and/or services for external customers in a business environment.

19

• The business environment includes the firm itself and everything else that affects its success, such as competitors, suppliers, customers, regulatory agencies, and demographic, social, and economic conditions.

Figure 5: Relationship between IT, IS, and business processes within the firm and the business environmentThe definition of the five terms imply the type of hierarchical layering illustrated here. The layering is sometimes misleading, however, because many information systems play a role in many different business processes,

information technology

business process

information system

firm

business environment

The WCA method assumes it is practical and effective for business professionals to view “the system” as a business process involving information and technology. Viewing the system as the entire firm is too broad for most decisions business professionals are involved in, except the rare decisions that

20

are truly strategic in nature. Viewing the system as an information system or as information technology forces business professionals to focus on peripheral topics and technical details others are better equipped to handle. Doing this also deemphasizes crucial issues in the business realm, such as the essential information, human relationships, and contextual factors not directly related to uses of information technology.

Figure 5 has a number of direct implications for teaching, research, and practice. If the natural unit of analysis for business professionals is truly the business process rather than the information system, one might wonder why introductory courses emphasize technology so much more than business processes. And while there is an obvious need for IS professionals to master documentation and specification techniques such as data flow diagrams and data dictionaries, one might wonder why they aren’t trained in a wide range of techniques for communicating and collaborating effectively with their customers using terms their customers find natural.

Figure 5 also raises questions about the way IS researchers and practitioners use slogans such as “competing on technology” (the theme of SIM’s 1992 conference) and the “productivity paradox.” as headlines rather than other possible slogans emphasizing business processes. According to Figure 5, competing on technology would mean using information technology in information systems that support business processes that permit a firm to compete more effectively in a business environment. In other words, the headline and independent variable, technology, is nested three or four layers away from the dependent variable, business success. Even when business professionals recognize fully that technology is an essential enabler, it is more direct for them to think of competing on business processes, an idea expressed in many forms such as competing on core competencies (Prahad and Hamel, 1990; Quinn, 1992), competing on time (Stalk, 1988; Keen., 1988), and mass customization (Pine, 1993). If Figure 5 could influence the productivity paradox discussion, the issue would probably shift to how and why technology was incorporated into business processes that generated success. The number of layers in Figure 5 makes it seem almost amazing that Brynjolfsson (1994) found a return on investment of 60% for a sample of service firms .

An IS professional’s viewpoint: “the system” as an information system

Although Figure 5 might describe a business professional’s viewpoint, an IS professional’s viewpoint puts the information system in the forefront, just as a clothier’s viewpoint would emphasize the clothes. For an IS professional, “the system” is the information system, and it adds value by supporting one or more business processes. The fact that many business processes may be involved adds a new level of complexity because the IS professional may have to optimize over the requirements of many different user business processes and key internal IS processes, such as development, maintenance, and IS staff hiring and education.

21

To help visualize this point, Figure 6 represents part of an IS professional’s view of the American Airlines SABRE system. It shows that SABRE includes capabilities related to business processes ranging from transaction processing activities such as updating schedules and fares and generating and distributing tickets through decision support functions such as helping travel agents find the best flight for the customer and performing yield management calculations to determine the number of discount seats offered by the airlines. Each of these functions can be viewed as a separate business process at least part of which is within SABRE’s scope.

Figure 6: IS professional’s view of an information system that supports many different business processesThe American Airlines SABRE system can be viewed as a single information system that supports or includes many different business processes. The parts of the boxes outside the oval represent parts of these business processes that might be considered outside SABRE’s scope.

The SABRE system

updating flight schedules and fares

determining the number of discount seats on each flight

comparing alternative flights for travel agent customers

booking flights

generating sales statistics

printing and distributing tickets

A business professional analyzing any of these processes would want to include the parts of SABRE directly involved and view the rest of SABRE as shared infrastructure or as an externality. But the IS professionals who run SABRE have to optimize the entire system to insure it supports the required functions in a cost-effective manner. From the IS professional’s viewpoint, the information system is “the system” and it may be much larger than any particular business process it supports.

What about IS infrastructure?

An important objection to the WCA method is that it does not adequately handle analysis of infrastructure systems such as voice and data networks because it emphasizes the role of information technology within individual business processes. One possible response is that business professionals do not really care about infrastructure. What they care about is the business processes

22

that currently use the infrastructure or could do so eventually. Perhaps they should concentrate on business processes and organizational feasibility while leaving the technical feasibility and cost-effectiveness tradeoffs to IS professionals.

Another possible response is that whether or not something is infrastructure is in the eye of the beholder. Systems considered applications one year or in one department may eventually be considered infrastructure another year or in another department. For example, airline reservation systems may have initially been viewed as isolated business processes supported by islands of technology. But eventually they became crucial infrastructure of the airlines. And these systems themselves rely on other elements of societal infrastructure such as electric power generation or network maintenance that public utilities providers view as business processes.

The conclusions from this entire discussion is that the information system is a better unit of analysis for the IS professional while the business process is more appropriate for the business professional.

IMPLICATIONS FOR TEACHING AND RESEARCH

Many ideas in this paper are consistent with the spirit of the paradigm shift occurring in the introductory IS course at both undergraduate and MBA levels. This is a shift away from emphasizing technical vocabulary and computer literacy and toward emphasizing business processes, human and ethical issues, competitiveness, and business infrastructure. Three related aspects of the paper raise issues for both teaching and research:

1) the arguable assertion that the IS field lacks concepts and methods business professionals can use effectively to gain insight by performing their own analysis 2) the description of the WCA method and how it evolved with the help of MBA and EMBA students3) the conclusion that the business process is a better unit of analysis for business professionals than the information system.

The paper’s implications for research and teaching can be organized under four headings: recognizing that business professionals analyze systems, recognizing that our buzzwords, slogans, and classifications no longer suffice, improving IS concepts, and abandoning the view of ourselves as computer people.

Recognizing that business professionals analyze systems

This paper is based on the assumption that business professionals need to analyze systems from their own business viewpoint rather than from a technical IS viewpoint. The immediate question about teaching is whether most existing introductory IS courses are truly directed at the topics and skills business

23

professionals care about and can internalize. In other words, are they truly designed to serve the customer? The research reported here does not deal with that question, but it does show that the WCA method or something like it can be taught in a classroom setting and can be applied successfully by business professionals.

Emphasizing systems analysis by business professionals along with the importance of business processes does not mean that existing introductory courses need to be thrown away, however. To the contrary, these ideas provide coherence and rationale for most of the material currently taught.

Many research issues stem from the assumption that business professionals need to analyze systems from their own distinct business viewpoint, plus the assertion that current IS concepts and methods are insufficient. Experiments could be designed that would test the WCA method and would compare it to other alternatives. Instead of the action research approach used to develop the WCA method, the future research could be done using a more standard experimental approach. The research would be performed by giving business professionals (or student proxies) instruction on any set of IS concepts and methods and then trying to identify differences in performing systems analysis tasks. Alternative experimental treatments might include an explanation of the WCA method or some variation on it, chapters of any introductory textbook, group discussion of a number of case studies, or a series of hands-on computer exercises.

The question about the proper unit of analysis for business professionals could be explored similarly. An interesting part of the question here is to delve more deeply into the way business professionals think about systems, such as through metaphors (Kendall and Kendall, 1993). The ideas in this paper also cast some light on past IS research, such as by raising questions about the face validity of empirical IS research that ignores the business process supported by the information system, or that does not involve a business process at all.

Identifying and improving the basic concepts in the field

From the outset this paper has raised questions about the basic ideas in the IS field. Knowing and sharing these ideas is important for teaching and research because the ideas form the foundation for sharing knowledge and experience. The basic ideas implied by the current form of the WCA method are shown in the labels and annotations in Figures 1 and 2. These terms include customer, product, business process, participant, information, technology, architecture, performance, infrastructure, context, and risk. A more detailed discussion of the WCA method would identify secondary ideas, such as common terms used to describe or evaluate individual elements of the framework from the various perspectives. For example, terms such as degree of structure, range of involvement, and level of integration can be used to discuss business process architecture.

The usefulness of this set of basic terms versus any other potential set of basic terms (such as system, subsystem, input, output, boundary, environment, feedback control, etc., from general systems theory) could be evaluated in various ways. For teaching, the issue might be whether the terms genuinely help students understand a wide range of real world situations. A high risk

24

research project might look for differences between the basic terms currently used by typical business professionals and the basic terms used by IS professionals. This research might find little or no commonality in the basic terms used by anyone to refer to anything other than technology per se. A safer research project might involve training people on a particular set of basic terms and observing the impact on their subsequent work on system-related projects.

Recognizing that IS buzzwords, slogans, and classifications have a short half life

The idea of trying to identify basic concepts is also valuable for identifying terms that couldn’t be basic concepts because there is no agreement about their meaning or because their meaning changes every five years, such McLean et al (1993) show for the term end user computing. Terms such as artificial intelligence, supercomputer, decision support system, and office automation belong in this category, yet these terms are often featured as important ideas in introductory information system texts. These terms are important because they are used frequently, but students’ complaints about the excess of buzzwords, slogans, and time-varying classification schemes are perfectly justified because the featured terms often aren’t the basic concepts.

To show how the framework in Figure 1 makes it easier to see the problem, Table 6 identifies a number of common system categories each of which has connotations as a business process and as a technology. Reporting research in a way that adds to knowledge and communicates effectively when using these terms requires greater clarity about whether topic is the business process connotation, the technology connotation, or both (or neither).

Table 6: classification schemes viewed as a business process or as technologyBusiness process ideas and technology ideas are both associated with system categories. This causes confusion and ambiguity when the same technologies are used for different types of business processes.

topic connotation as a business process connotation as technologyexpert system

providing information to the person doing work so that it is performed the way an expert would do it

inference, if-then rules,frames, LISP, PROLOG

decision support system

decision process in which business professionals actually use computers interactively for an important task

computer program combining data analysis and modeling to help business professionals analyze a decision

executive information system

process during which executives use interactive computers to monitor recent business results and track the business environmental

interactive computer system making it easy for executives to find information theywant if it has been included

end user computing

business process in which users use computing directly to do their jobs

personal computer andspreadsheet used in an office or on an airplane

management information

management process in which managers use information to

standard summary reports generated periodically based on

25

system monitor recent business resultsand make decisions

data in a transaction processingsystem

group decision support system

process of using networked terminals to support a face to face multi-participant meeting

the networked terminals, other display equipment, and softwarefor note taking and voting

Abandoning the view of ourselves as computer people

Placing more emphasis on business processes and on systems analysis by business professionals is part of a major ongoing change. Many of us still view ourselves as computer people. Many of our colleagues in other areas of business agree with that image and believe we are dispensable precisely for that reason.

Everyone will be a computer person soon. Positioning ourselves as computer people is a losing strategy because the mystery is gone from computers. People drive cars without knowing about ignition systems just as they use computers and telecommunications without knowing much about the operation of computer chips. We still need to impart understanding of technology, but we need more clarity about the difference between transient details of today’s technology and the basic ideas that will still apply five years from now.

We also need to avoid acting as cheerleaders for computing and the computer industry. Technology is wonderful, but it is not our job to convince students it is a panacea or that they will have important skills when they can add a column of numbers using a spreadsheet.

Shifting the emphasis in the introductory IS course away technology details and toward business processes and systems analysis is one of the ways we can avoid being cast as computer people. More important, it is a way we can provide genuine value to the future business professionals who are our customers.

References

Boland, R. J., Jr. “The Process and Product of System Design,” Management Science, (24:9), May 1978, pp. 887-898.

Brynjolfsson, E. “The Productivity Paradox of Information Technology,” Communications of the ACM (36:12), December 1993, pp. 67-77.

Davenport, T. H. Process Improvement: Reengineering Work through Information Technology, Harvard Business School Press: Boston, MA, 1993.

Davidson, E. J. “An Exploratory Study of Joint Application Design (JAD) in Information Systems Delivery,” pp. 271-283 in Proceedings of the Fourteen International Conference on Information Systems, J. I. DeGross, R. P. Bostrom, and D. Robey (eds.) Orlando, Fl, 1993.

Harrington, H. J. Business Process Improvement. McGraw-Hill: New York, 1991.Hirschheim, R and Klein, H. K. “Realizing Emancipatory Principles in Information

Systems Development: The Case for ETHICS,” MIS Quarterly (18:1), March 1994, pp. 83-109.

26

Keen, P. G. W. Competing in Time: Using Telecommunications for Competitive Advantage. Ballinger Publishing Company: Cambridge, MA, 1988.

Kendall, J. E. and Kendall, K. E. “Metaphors and Methodologies: Living Beyond the Systems Machine,” MIS Quarterly (17:2) June 1993, pp. 149-171.

McLean, E. R., Kappelman, L. A., and Thompson, J. P. “Converging End-User and Corporate Computing,” Communications of the ACM (36:12), December 1993, pp. 79-92.

Pine, B. J., II. Mass Customization: The New Frontier in Business Competition. Harvard Business School Press: Boston, MA, 1993.

Prahad, C. K. and Hamel, G. “The Core Competence of the Corporation.” Harvard Business Review. May-June 1990, pp. 79-91.

Publication by author, in press. To be inserted after the refereeing process.Quinn, J. B. Intelligent Enterprise.. Free Press: New York, 1992.

Stalk, G., Jr. “Time - The Next Source of Competitive Advantage,” Harvard Business Review, July -August 1988, pp. 41-51.

27