redesign of managerial tasks: a requisite for successful ......a requisite for successful decision...

Managerial Tasks Redesign

Redesign ofManagerial Tasks:A Requisite forSuccessful DecisionSupport Systems*.

By: Michael J. Ginzberg

AbstractDeveloping and installing a computerobased systemin an organization can have major impacts on thetasks performed by participants in that organiza-tion. In recent years, an increasing share of systemsdevelopment effort has been directed towardsystems to support managerial decision making.These systems require a far greater degree ofindividual change than did earlier, clerical replace-ment systems. Successful implementation oftenrequires changes in the users" views of their jobs.The demands that these systems place on the imple-mentation process cause many standard develop-ment approaches to be inadequate. This articlesuggests some alternative approaches and pointsout the need for new tools.

Keywords: Decision support systems, level-of-adoption,managerial task change, system design,system evaluation, user training

Categories: 2.4. 3,36

"This research was supported in part by a grant from theFacult~ Research Fund of the Graduate School ofBusiness. Columbia Universi~.

IntroductionIt has long been recognized that the devel-opment and installation of computer-basedsystems can have major impacts on an organi-zation; these activities lead to changes whichaffect the members of that organization and alterthe jobs they perform. As early as 1960, we finddetailed accounts of the processes of systemdevelopment and installation, and of systemimpacts on various segments of the organizationand on the individuals employed in thesesegments [18]. These early reports, and themajority of all studies to date on the impact ofcomputer-based systems, focused primarily onthe impacts of the computer on clericalpersonnel and on the tasks performed by theseemployees. About 1970, however, the focus ofstudies of computer-based system impactbegan to shift, examining how these systemsaffected managerial personnel and the tasksthey perform [21, 22].

There is ample reason for this shift in the focus ofresearch on system impacts. Early computer-based systems in organizations were orientedprimarily toward the automation of paperworkflow; they dealt with the processing of routinetransactions and the preparation of historicalreports. The personnel most directly involvedwith these operations were clerical employees;managers were primarily concerned with theoutputs of these processes. It is understandablethat the focus in early research efforts was onsuch variables as

¯ changes in skill requirements for clericaljobs,

¯ routinization of clerical work,¯ intrinsic interest of clerical tasks, ando reduction in the number of clerical jobs

[3, 5].These are the areas that experienced the impactof early efforts to use the computer in businessorganizations.

In the past five to ten years, however, anincreasing share of the effort in developingcomputer-based ,systems has been directedtoward systems which support managerialdecision-making processes. These are systemswhich are not a part of the organization’s routinepaper flow, but which can provide a managerwith the information needed to make decisions.Unlike historical reporting or routinetransaction

MIS Ouarterly / March 1978 39


processing systems, these decision-orientedsystems have a tremendous potential to impactthe way managers do their jobs, and minimalimpact on clerical tas.ks and procedures.

It is my intention in this article to support theposition that a system designed to support andimprove managerial decision-making must,almost by definition, be built around a "model"of the manager’s role; this role is to be differentfrom the one in use prior to the development ofthat system. If such a system is to be usedsuccessfully, a change in the manager’s view ofhis task must take place, This type of change isoften not a simple one, and may require majorshifts in both the way certain tasks are accomp-lished and even the definitions of these tasks.Further, accepting this view implies that thestrategies needed for implementing this type ofsystem differ from those which were appropriateto systems developed in the past.

Information Technology andOrganization ChangeAll attempts to develop computer-based systemsimply some degree of change for some membersof the user organization. The hypothesisexplored here is that the degree of change, atleast at the individual level, required for success-ful implementation of a managerial decisionsupport system (DSS) is considerably greaterthan that required for successful implementationof other types of computer-based informationsystems (e.g., clerical replacement systems).

Clerical replacement systems essentiallydemand changes in procedures --how thingsare done. These systems take an existing tasksuch as preparation of payroll or entering ofsales orders, and change the means by whichthat task is accomplished. The purpose of such asystem is not to provide the organization with thecapacity to perform a new function; rather, it is toenable the organization to perform an existingfunction more efficiently.

Three recent studies provide evidence thatDSS’s, unlike clerical replacement systems.require a change that goes beyond how thingsare done and extends to what things are done.Alter [1], in a survey of 56 DSS’s, notes that in

most of the cases he studied, a key issuesurrounding system development was changingthe user’s view of his job. Nash [20] suggests thatuse of a DSS led to "expansion" of the decisionprocesses of users in a major bank. Loughranand Cocks [16] argue that the installation of acomputer-based planning system changed the"nature of work" for managerial and staffemployees of an airline. In essence, each ofthese authors suggests that successful imple-mentation of a DSS requires change in thedefinition of the user’s task -- a partialreformulation of his role.

A view of organization designTo understand why these two types of systemsrequire fundamentally different types ofchange, we need to consider the relationshipbetween managerial technology, such ascomputer-based systems, and other aspects ofthe organization. Harold Leavitt [15] provides asimple but useful conceptualization of anorganization. In his view, an organization iscomposed of four inter-connected components:(1) the organization’s task or tasks, (2) technology it employs in performing this task,(3) the people who comprise the organization,and (4) its structure. For the organization function effectively, there must be a balanceamong these four components. In this view,then, the role of organization design is to selecttasks, technologies, people, and structureswhich are mutually complementary and enablethe organization to operate efficiently andeffectively.

According to this view, organizations areessentially homeostatic entities. An organizationin which the various components are in balancewill attempt to remain in balance, and will oftenresist efforts to alter any of these four compo-nents. If, however, one of these components ischanged, for example a new task is imposed onthe organization by changes in the externalenvironment, the balance that exists in theorganization may be upset, and forces willdevelop to restore that balance. Equilibrium canbe restored either by effectively thwarting theoriginal change -- not accepting the newlyassigned task, failing to use the newly intro-duced technology -- or by making compen-

40 MIS Quarterly / March 1978


sating changes in one or more of the otherorganizational components.

Clerical replacement systems are generally builtin response to changes in other components ofthe organization. As an organization grows, sodoes the amount of information it must process.At some point, existing systems are no longercapable of efficiently processing the requiredvolumes of data. In essence, the environmentimposes new tasks on the organization, and thiscreates an imbalance among the organizationalcomponents. Developing a new computer-basedsystem is one approach which can be taken tocorrect this imbalance. Galbraith [6] suggestsother approaches dealing with structure whichcould be taken. This system might lead tofurther changes in people, task, or structure; but,inducing subsequent changes is not usually amajor aim of this type of system. Clericalreplacement systems are basically attempts tostabilize the organization, to restore equili-brium, to enable the organization to continuefunctioning efficiently.

Technology, however, need not always be theelement that responds to changes. It can,instead, be used as the vehicle through whichchange is introduced to the organization.OSS’s are often built because someone believesthere could be a better, more effective, way ofdoing things. These systems are not developedin response to changes that have occurred inother organizational components, but areintroduced into relatively stable organizations.Two recent studies [1, 8] have found that DSS’sare frequently introduced to the organization byan external source, typically the person whowants to sell the system to the organization,and the more innovative the system, the morelikely this is to be true. Clearly, these are notcases of organizations searching for solutionsto pressing problems. In fact, some of theorganizations surveyed in each of these studiescharacterized these systems as "R & D efforts."

How is the introduction of a DSS into a stableorganization likely to impact the organization’sfunctioning? When a change is made to itsmanagerial technology, a previously stableorganization may become unstable. To regainstability, further changes to task, structure, orpeople probably will be necessary. Variousstudies have shown that in effective organio

zations, structure tends to be determined by thegeneral nature of the organization’s task [4, 14,24]. Thus, we would not expect structural changeas the immediate response to a change in tech-nology. We might, however, observe changestaking place in the people and task atthe micro orindividual level subsystems.

I contend that DSS’s often are developed andimplemented precisely in order to induce changein people through learning and in the specifictasks they perform. Mintzberg [19] suggeststhat managers make decisions in a very intuitive,non-explicit fashion. This is so partially becausewe understand little about managerial work andhave been unable to Supply managers with anacceptable technology to make their approachmore explicit.

A part of the development of any interesting DSSis the structuring of some portion of managers’decision making environments [10]. Thisstructuring may take the form of (1) specifyingthe data to be considered, (2) prescribing thetype of analysis to be conducted, (3) formalizingrules for choosing among alternatives, etc. Thespecific form is not important. It is important,however, to recognize that in each case we areasking managers to change the way they view apart of their decision environment, leading themto replace their intuitive approach with a moreexplicit, formalized approach. Doing thisrequires that they change their view of at leastsome of the tasks which constitute their role.

In summary, 1 have suggested that clericalreplacement systems are often developed inresponse to changes in other components of theorganization. The goal in developing thesesystems is to reestablish equilibrium among theorganizational components. On the other hand,decision support systems are frequently imple-mented by organizations already at equilibrium,with the goal of inducing change in the task orpeople subsystems of the organization. Thedifference between the goals of these two typesof systems is analogous to that between "singleloop learning" and "double loop learning" [2]. Inthe former case we are attempting to maintainthe existing organization; in the latter, we arequestioning it. Many people would disagree withthis characterization of the role of DSS’s; itdoes run counter to the implicit assumptions ofmost prevailing models of the system design

MIS Quarterly / March 1978 41


process. We will return to this issue in a latersection of this article.

A model of requisite change

At the beginning of this article we drew a distinc-tion between two types of systems -- clericalreplacement systems which have the solepurpose of automating a part of the organi-zation’s paper flow, and decision supportsystems which are designed solely to supportmanagerial decision making. In fact, theserepresent opposite extremes on a continuum ofsystem purposes, although we can find manysystems which serve both purposes to someextent. It is useful, nonetheless, to talk aboutthese two archetypal systems, since theyrepresent qualitatively different situationsrequiring fundamentally different types oforganizational change.

Huysmans [11] has articulated a view of theadoption of management science projects whichclosely parallels the view of the system relatedchanges discussed above. In his view, there arethree distinct "levels of adoption" (LOA) whichmay be appropriate for system implementationefforts. Each succeeding level implies a greaterdegree of individual change than does the levelbefore it. Keen [12] argues that in order torepresent the full range of adoption possibilities,a fourth level must be included which implieseven more change than Huysmans’ level 3. Thefour levels are:

1. Management Action: Use of a system with-out extensive involvement or under-standing; at this level, the user treats thesystem as a "black box" which gives himneeded information or provides him with asolution.

2. Management Change: Use of a system withan elementary understanding by the user ofwhat the system does; at this level, the usertreats the system as a tool which he canapply to help find the answers to specificquestions.

3. Recurring Use o! the Management ScienceApproach: Use of a system with an appre-ciation for the usefulness of an analyticapproach to problem solving; at this level,the user attempts to apply the analyticframework provided by the system to a

variety of problems which confront him inthe course of performing his job.

4.Task Redefinition: Use of the system as acatalyst for change in the definition of theuser’s role; at this level, the user activelyattempts to change his view of his job, anduses the system to help redefine the tasks itwas designed to support.

Huysmans suggests that any system develop-ment project might aim for any one of theselevels of adoption. It is necessary, however, torecognize explicitly which level is to be achieved,so that appropriate strategies might beemployed. I suggest, however, that since eachLOA describes a different degree of individualchange, each level will be appropriate for sometypes of systems and inappropriate for others.

We should note that the appropriate LOA doesnot depend on the specific tool being employed,but rather on the use that is to be made of thattool Optimization models, for example, couldbe used to generate solutions which were thenimplemented without further question. Thiswould be level 1 adoption. On the other hand,the same model could be used to test multipleformulations of a problem with variousparameter settings to find an acceptablesolution, and this would be level 2 adoption. Wecan also find examples where adoption at level 3or 4 would be necessary. It is the intended use ofthe system which determines the appropriateLOA.

Consider first level 1, "management action."Adoption at this level means simply acceptingthe systenl output as correct and taking whateveractions are implied by this output. This is thelevel of adoption appropriate for many clericalreplacement systems. For example, a newpayroll system, once debugged, should beexpected to calculate the proper amount ofcompensation, and an individual should be paidthat sum. We would neither want nor expect thesystem user to attempt to "optimize" theamounts paid to individuals as in a level 2adoption, nor to employ the pay calculatingalgorithms to solve other business problems asin a level 3 adoption. For a simple clericalreplacement system, level 1 adoption is all that isneeded.



At the other extreme we have level 4 "taskredefinition." A DSS for portfolio managers in abank trust department provides a good exampleof adoption at this level. Prior to development ofthis system, portfolio managers had a "stockoriented" view of their job -- Le., they wouldconsider one stock at a time, and determinewhich portfolios to buy or sell for that stock.Finance theory suggests that a more appropriateview is one that looks at a portfolio of stocks as anentity, and the department’s managementbelieved that performance might improve ifportfolio managers were to switch from a stockoriented to a portfolio oriented view. To effectthis change, a DSS which pro~’ided multiple waysto view and analyze portfolios was developedand implemented. It should be clear that for thissystem to be truly successful, the portfoliomanagers would have to change their approachto decision making. They could not effectivelyuse the structure provided by the system withoutmaking this change in task definition.

We have identified the appropriate LOA’s for twoarchetypal systems w pure clerical replacemen~tsystems and innovative DSS’s. Many systems fallbetween these extremes, having some of thecharacteristics of each type of system. The levelsof change appropriate to these systems also fallbetween the extremes discussed above."Management change," level 2, entails using thesystem as a problem solving tool within somewell defined area. Many data retrieval systemsrequire adoption at this level. The system cannotbe used without some understanding of whatdata it contains and how they relate to theproblem area, thus level 1 adoption is insuffi-cient. But, successful use" does not requireeither extending the use of the system to otherproblem areas or redefining one’s approach tothe focal problem area, making levels 3 and 4,respectively, unnecessary.

Level 3, "recurring use of the managementscier~ce approach," differs from level 4 more indegree than in kind, and might best be termed"task extension." Adopting at this level requiresthat the analytic framework or structure providedby the system be applied to a variety of decisionproblems. This is the appropriate LOA for DSS’swhich provide analytic tools that do not differSubstantially from the user’s existing conceptualframework. We should note that adoption at thislevel may eventually lead to level 4 adoption, as

the application of the system leads to greaterunderstanding of the decision environment andrecognition that alternative approaches mightbe appropriate.

We Can summarize this discussion of LOA in theform of an hypothesis:

H: The level of individual changerequired for successful implemen-tation of a computer-based systemdiffers across system types. Pureclerical replacement systemsrequire adoption only at level 1,"management action." Decisionsupport systems require adoptionat least at level 3, and frequently atlevel 4, if full benefit is to beobtained. Systems failing betweenthese two extremes require adop-tion at an intermediate level.

Further, I would argue that attempting to adopt ata level higher than that appropriate to the systemis a waste of effort. The system is not designed tosupport a higher level of change, and attempts toattain this higher level are likely to beunsuccessful.

A Test of theLevel-of-AdoptionHypothesis

An empirical test of the level-of-adoptionhypothesis was performed as part of a study ofsystem implementation [8]. Data about theconduct of the development process andperceptions of project outcomes were collectedfrom users and designers inv~)lved in twenty-ninesystem development projects.1 These 29 projectstook place in eleven organizations representingnine different industries. The sample includedprojects displaying a wide range of character-istics: some were close to pure clerical replace-ment systems, while others representedinnovative decision support systems.

Background information was collected for eachsystem. This information included:

¯ Capabilities provided by the system,¯ types of system users -- clerical or

managerial,¯ types of change attributable to the system,



¯ mode of interaction with the system, and¯ sophistication of models and techniques

included.

Nine questions were asked about these systemcharacteristics. Certain responses for eachquestion were considered to be more typical ofDSS’s than of clerical replacement systems. Theprojects in the sample had ~cores ranging from1-8 on a scale with values ranging from 0-9. Priorto analyzing any of the data on the implementa-tion process or project outcomes, the projectswere divided into groups on the basis of theirscores on this scale. The break points betweengroups were fixed so that system characteristicswere relatively homogeneous within groups anddiffered between groups. Three groups wereformed, scores of 1-3, 4-5, and 6-8. There are 8projects in the least, complex group most likeclerical replacement systems, 10 projects in themiddle group, and 11 projects in the mostcomplex group most like decision supportsystems.

Table 1 summarizes the characteristics of thesystems in the three groups. The systems in theleast complex group are primarily historicalreporting systems serving clerical users. Most ofthese systems automated functions which werepreviously done manually; none of them incor-porated sophisticated models or mathematicaltechniques. Typical examples of systems in thisgroup are a hospital out-patient billing systemand a system to calculate sales commissions fora major office equipment supplier.

Systems in the middle group differ from those inthe least complex group in a number of ways.They tend to be multi-functional, more directlyaimed at managerial users, and frequentlyinclude simple projective models° One systemtypical of this group is a data retrieval systemused by a television station to file, analyze, andfollow up on consumer complaints. Another typeof system included in this group is representedby a beef inventory tracking and forecastingprogram used by a large supermarket chain.

1The difference between user and designer responses tothe questions asked ere discussed elsewhere [8, 9], andwill not be dealt with here, I will confine the discussion toan analysis of the users’ responses to these questions.

The systems in the high complexity group, thosemost like DSS’s, are aimed exclusively atmanagerial users, supporting decision makingrather than clerical operations. Many of thesesystems serve multiple functions, and in anumber of cases they touch on the activities ofmultiple areas of the organization. All of thesesystems include sophisticated models ormathematical techniques, and in most cases theywere designed to provide their users withgeneralized support for their tasks. Examples ofsystems in this group include the portfoliomanagement system described earlier, and asystem to support inventory planning, alloca-tion, and distribution for an office equipmentmanufacturer.

In summary, the three groups of systems doappear to be qualitatively different, and span therange from clerical replacement to decisionsupport. According to our hypothesis, forsystems in the low complexity group, adoptiOn atlevel 1 would seem adequate. Systems in themiddle group fit the definition of systems wherelevel 2 adoption is most appropriate -- Le.,systems which should serve as problem solvingtools in a fairly restricted area. Finally, the highcomplexity group is composed of DSS-likesystems, and adoption at level 3 or 4 should benecessary.

Measuring level of adoptionFour items in the research questionnaire wereused to measure the level of adoption achievedby each of the users. These items were:Level 1: The project provided me with the

answers I needed.Level 2: The system provided me with the tech-

niques to solve my problem.Level 3: I tend to rely more on analytic aids in

my work now that this system has beeninstalled.

Level 4: The decisions I make have changed as aresult of having this system.

Users were asked to indicate how well each ofthese statements described their projects. If astatement was reported as being characteristicof the project, it was assumed that adoption atthat level had occurred~

As we shall see when we turn to the results,some users reported achieving levels of adoption



Characteristics

Table 1.

OPERATES ON-LINE

Summary of System Characteristics

S~/stem Complexity(I Low Medium High

NO 50% of YESSystems

USED BY CLERICALPERSONNEL YES YES NO

USED BY 75% ofMANAGEMENT Systems YES YES

SERVES MULTIPLE 50% of 50% ofFUNCTIONS NO Systems Systems

SERVES MULTIPLE 20% ofUSER AREAS NO NO Systems

INCLUDES PROJECTIVE 50% ofMODELS NO Systems YES

INCLUDES STATISTICSOR OPTIMIZATIONS Seldom Seldom Frequent

inappropriately high for the types of systemsinvolved. This raises questions regarding ourassumption about the mapping betweenresponses to these four items and the level ofadoption achieved. It does not, however, raise aserious problem for testing the LOA hypothesis.All it does is make it more difficult to show adifference between the impact of achieving theminimum required LOA and that of achievinghigher, and presumably unnecessary, LOA’s.

Measuring project successOne item in the questionnaire asked for anassessment of overall satisfaction with the’outcome of the system development effort. Thismeasure of overall satisfaction was adopted asthe measure of system success. If the userreported being satisfied with project outcomes,the project was deemed successful; if the userdid not report being satisfied, the project was

¯ classified as unsuccessful.

More than one user responded to the researchquestionnaire for a number of projects; and, intwo projects users were not in agreement on thequestion of project success. Since we are dealingwith change at the individual level, it is notappropriate to aggregate the responses of anumber of users for a project. Rather, we shouldbe concerned with the relationship between each

individual’s satisfaction with the project and thelevel of change which he achieved. Thus, inanalyzing the data, we consider each user as aseparate unit.

Results of the testFigure 1 presents the relationship between LOAand success for the users of the systems in eachgroup. Generally, these data support the hypo-thesized relationship between LOA and success.In all but one case in level 1 for the lowcomplexity systems, successful users reportachieving the minimum level of adoptionhypothesized to be necessary for successfulimplementation of that class of system -- i.e.,levels 1, 2, and 3 for low, medium, and highcomplexity systems, respectively. Fewer of thesuccessful users report having achieved adegree of change greater than the minimumrequired for systems in that group.

We have hypothesized that successful imple-mentation requires adoption at some minimumlevel, and that this level differs across systemtypes. We can test this hypothesis by looking atthe users’ responses, comparing those at theminimum required level to those at higher levels.That is, we can compare the tables on thediagonal of Figure 1 to those below the diagonal.Figure 2 shows this comparison separately for



Low(N=9)Achieved Level 1?

Yes NoSuccess" 7 1Failure* 1 0

Achieved Level 2?Yes No

Success 4 4Failure 1 0

Achieved Level 3?

Yes NoSuccess 4 4Failure 1 0

Achieved Level 4?Yes No

Success 4 4Failure 1 0

"Overall Rating of Project Success or Failure.

Figure 1.

System Complexity

Medium(N= 10) High(N=18~

Yes No Yes No7 0 10 02 1 2 6

Yes No Yes No7 0 10 03 0 4 4

Yes No Yes No4 3 10 03 0 0 8

Yes No Yes No4 3 6 42 1 0 8

Achieved Level of Adoption vs. Success

successful and unsuccessful, users. Forsuccessful users, we must reject the nullhypothesis that there is no difference betweenthe degree to which adoption was achieved at theminimum and at higher levels. For unsuccessfulusers, we cannot reject this null hypothesis.Thus, the data support the contention thatachieving the minimum LOA appropriate to thesystem, but not any higher level, is a necessarycondition for successful implementation.

The patterh of LOA achieved by unsuccessfulusers is interesting. In the low and mediumcomplexity groups, we find that all unsuccessfulusers report achieving at least the minimum LOAnecessary for that type of system, levels 1 and 2,respectively. Failures were more likely to reportadoption at levels above the minimum than weresuccesses. ~ In the most complex group,

=A possible explanation for the large number of low andmedium complexity system users reporting adoption atlevels 3 and 4, is that these users did not truly understandthe meaning of change at these levels. This degree ofchange may be beyond the realm of their experiences, andtheir responses to questions about this type of changemight be based on standards different from thoseemployed by users of more complex systems.

however, no unsuccessful user reports adoptionat level 3 or 4, the levels appropriate for thisgroup. Thus, while achieving the necessaryminimum LOA did not assure success forsystems requiring small degrees of change,failing to achieve the required LOA always led tofailure in systems requiring high degrees ofchange. It would seem that achieving theminimum LOA is a necessary, but not sufficientcondition for success. These data also addsupport to the contention that successful imple-mentation of a DSS requires a significant degreeof individual change m redefinition, Or at leastextension, of the individual’s view of his tasks.

Another portion of the data gathered relates tothe question of the degree of change needed forsuccessful implementation. Four items in theresearch questionnaire dealt with the "fit" of thesystem to the user organization, and two itemsconcerned the degree to which users hadadjusted to accommodate the demands of thenew system. These items were;

Fit Items:1. The system still doesn’t fit well with our

organization’s way of doing things.



Minimum RequiredLevel (Diagonal)

Higher Levels (Sumof Sub-Diagonal)

X2 with correction for continuity = 11.46

X2 (.999, 1) = 10.8

p <.001

Minimum RequiredLevel (Diagonal)


Xz with correction for continuity = .127

Xz (.20, 1) = .064

NS

Successful Users

Did notAchieved achieve

24 1

26 22

50 23

Unsuccessful Users

Did notAchieved achieve

12

25

48

73

12

9 17

17 29

Figure 2. Achieved LOA at Minimum vs. Higher Levels

2. I am still uncomfortable about using thesystem in my work.

3. We’ve changed too fast for this system tokeep up.

4. We feel confident in our ability to manageand use the system.

Adjustment Items:1. We would really find it hardtogo backtoour

old way of doing things.2. The system caused changes in who is

important around here and I haven’t learnedhow to deal with this yet.

We would expect these first four items to beimportant for successful implementation of anysystem. But, the last two should only be salientin those cases where a large amount of individualchange is demanded by the system -- in other

words, in the case of DSS’s. Comparingsuccesses with failures in each group of systems,we find that a number of the "fit" itemsdifferentiate successful from unsuccessful usersin each group. ~ However, only in the mostcomplex group are successes differentiated fromfailures on the basis of items relating to individualchange to accommodate the system, as opposedto the system accommodating the user’s needs.Again, the results support the notion that a muchgreater level of change is required for successfulimplementation of DSS’s than is needed for othertypes of systems. And, the content of these itemssuggests that significant changes had occurredin the way tasks were accomplished.

=The Mann-Whitney U Test was used to test the differencebetween successful and unsuccessful users. Itemsreferred to as differentiating successful from unsuccessfulusers were significantly different at the ,10 level or better,



Implications for SystemsDevelopmentThe data presented above support thehypothesis that systems vary in the degree ofindividual change they imply, and that DSS’srequire substantially greater change to besuccessful than do "conveotional" systems.Alter’s [1] survey of 56 DSS’s lends additionalsupport to this conclusion. He notes that in caseswhere DSS’s attempted to provide significantsupport for decision makers, "a new way ofsolving the problem had now been institu-tionalized" [1, p. 158]. Furthermore, in 29 of the56 systems he studied, the key change issue waseither (1) unfreezing the job image or the way approaching the problem, or (2)using thesystem as a vehicle for change. These are thetypes of changes one would expect to find ifadoption at level 3 or 4 is taking place.

If we accept the contention that implementing aDSS entails substantially greater individualchange than does implementing a conventionalsystem, we are led to the conclusion thatcommonly used approaches to system develop-ment are inadequate for DSS developmentefforts. The following will focus on theseinadequacies and on some potential remedies.

System designAll models of system design imply certainassumptions about change. Conventionaldesign practice is, in fact, a change minimizingapproach. The analyst(1) interviews users to .document their stated

needs,(2) examines the existing information flows

the area of concern, and(3) prescribes a new set of information flows

which efficiently meets the stated needs.The focus of this approach is not systemic, buton one application at a time. User involvement indesign is minimal. Conventional design searchesfor obvious "holes" in the existing informationprocessing system, and attempts to fill them; tothe greatest extent possible, however, itattempts to maintain the status quo. This is aplausibie model for designing clerical replace-ment systems, but it is bound to existing organi-

zational practices and cannot produce thechange necessary for.a successful DSS.’

Many people have noted that the conventionaldesign approach frequently does not work, andalternative approaches have been suggested.Schultz & Slevin ~21] propose a method termedBehavioral Model Building (BMB). BMB is oneof a number of "participative" desig’napproaches, where users take an active role inthe design process. The aim of user involve-ment in BMB is to assure that the resultingsystem "fits" the user.and his organ ization. Whilemore appropriate than conventional design forsome types of systems, this approach, too,attempts to minimize change, and is likely tobe inadequate for DSS design.

Lucas [17] describes the benefits to be gainedfrom a more general participative strategy.Among these are:(1) the user is more committed to change;(2) the user is more knowledgeable about the

system and its use; and(3) incorporating the user’s knowledge of the

problem will lead to a better solution.All of these benefits are likely, and heavy userinvolvement in design is an important steptoward assuring DSS success.

Participation alone, however, is not enough.Participative design is based on the implicitassumption that users and designers knowexactly what they are trying to achieve. It is oftenimpossible to specify at the outset just what thefinal system will look like in designing aninnovative DSS. That is, we are dealing with afundamental change in the way the organizationfunctions; while we may know in what directionwe want to move, no one is likely to have a clearpicture of exactly where we should end up.

Gerrity [7] suggests a design approach whichaddresses part of this problem, and Alter [1]identifies some design strategies which appearto be useful. Gerrity’s approach, Decision-Centered Design, differs from others in twomajor respects. First, it focuses on decisionsand decision processes rather than on infor-mation flows. Second, it explicitly incorporatesdevelopment of a normative model of thedecision process, an ideal, into the designprocess. System design, then, is a search for

’See Lucas [17. pp. 60-62] for a similar view.



ways to move from the existing situation towardthe ideal. The normative model does not haveto be an achievable state, nordoes it have toremain static throughout the developmentprocess. Its importance is twofold. It clearlystates to both user and designer that this systemwill imply considerable change, and providessome direction for that change.

Alter found three important strategies whichwere employed in developing the systems hestudied. These were (1) use of prototypes,(2) evolutionary design, and (3) design series of tools. Each of these provides a wayof moving from the current status toward anuncertain goal. Each involves moving towardthat go.al in a series of small steps. Once eachstep is taken, the ultimate goal becomes a littleclearer, and the next step that will lead closer toit can be taken. This iterative approach alsoallows the necessary changes in otherorganizational components such as tasks andpeople to begin. It is undoubtedly moreexpensive to build a system this way than itwould be to build the ultimate systemimmediately. But, since we are unlikelyto knowatthe outset what that ultimate system should looklike, it is certainly less expensive to build the rightsystem expensively than to build the wrongsystem cheaply.

In summary, the design of DSS’s is likely to bemore successful if the design process incor-porates these three characteristics:

¯ user participation -- to incorporate theirknowledge into the design and to bolstertheir commitment to change;

¯ normative system modeling -- to under-score the necessity for change and to givesome direction to it; and

¯ evolutionary or iteratlve design -- toenable attainment of an unclear and shiftinggoal, and to assure proper adjustment ofother organizational components.

User TrainingAdequate training is important to the success ofall systems. But, what was "adequate" for clericalreplacement or transaction processing systemsis not likely to be sufficient when we turn toDSS’s. We can identify two training strategies

which are qualitatively quite different. In the first,"operations training," users are taught whatoperations the system is designed to performand how to instruct it to perform theseoperations. This is the strategy commonly usedin clerical replacement system developmentefforts, and is appropriate for these systems.Clerical replacement systems are designed toperform certain operations which werepreviously performed manually or by anothersystem, and the user’s major problem is to learnhow to continue doing what he has been doing allalong.

When this strategy is applied to DSS develop-ment efforts, it quite frequently fails. Effectiveuse of a DSS implies more than a new systemperforming old operations; it often requires thatusers learn new repertoires of operations such astask extension and redefinition. This leads to anessentially different training strategy -- "taskcontext training." Training in this mode entailsnot only showing the user how to produce acertain output, but more critically, showing theuser how to use this output in the context of hisjob. Alter describes a successful application ofthis type of training using "workshops," whereusers brought their own problems and learnedthe system by using it with guidance ,to solvethese problems. This type of training cancontinue over the system’s life, as users developnew ways of using the system to solve problems,and share these experiences with theircolleagues. Such an evolutionary pattern ofsystem use is quite appropriate for DSS’s. As thesystem is used, more is learned about how tasksshould be accomplished. This brings aboutchanges in the usage pattern as the tasks that areaccomplished.

System Eval-uationConventional techniques also seem to beinadequate for the evaluation of DSS’s. Systemsdesigned to take over the performance ofexisting tasks can often be evaluated on the basisof the cost of task performance; a successfulsystem should reduce this overall cost. DSS’s0however, are designed to enable the per-formance of new tasks. This cost displacementmodel cannot be used to accomplish an evalua-tion of a system which aims to make the organi-zation more effective, as opposed to more



efficient, by enabling it to do things it could notdo previously.

The DSS evaluation problem is particularlythorny. It is often difficult to place a value on thepromised outcome of using the system, e.g.,better decision making. We normally cannoteven be sure that the DSS is the reason for theobserved change; other changes in theorganization’s environment may have occurred,and could account for any improvement inperformance. The way out of this dilemma seemsto be in recognizing that a prime objective of DSSdevelopment is learning, both individual andorganizational. We can evaluate a project’smerits by assessing the amounts and types oflearning we expect from it, and then asking howmuch we are willing to pay for that learning. If itexceeds the likely bill for the project, we canproceed; if not, we should drop the project. Afterthe system has been implemented, we mustassess whether the promised learning actuallydid occur. ~ Unfortunately, measurementtechniques in this area are not well developed,and further research is required.

Concluding Comment

The successful development of innovative

decision support systems requires that we

recognize the substantial change implications ofthese systems, and that we view them in the

broader context of organizational change.Traditional system development tools are not

always appropriate for the more dynamicdevelopment requirements of DSS’s, and new

tools must be found. In the area of system

design, a combination of existing techniquesappears to be quite useful. In user training,certain new approaches have been tried andfound to work. In system evaluation, theoutlines of a new approach are emerging, butmuch further work is necessary.

SKeen [13] presents some further thoughts on the problemof evaluating DSS’s.

References[1[ Alter, S.L. "A Study of Computer Aided Decision

making in Organizations." unpublished Ph.D.dissertation, M.I.T., 1975.

[2] Argyris, C. "Organizational Learning and Manage-ment Information Systems,"Accounting, Organi-zations and Society. Vol, 2, No. 2, 1977, pp. 113-123.

[3] Bureau of Labor Statistics. "Office Automation in theFederal Government." Monthly Labor Review, Vol. 83.No. 9, 1960, pp. 933-938.

[4] Chandler, A.D., Jr. Strategy and Structure, M.I.T.Press, Cambridge, 1962.

[5] Elizur, D. Adapting to Innovation: A facet analysis ofthe case of the computer, Jerusalem Academic Press,1970.

[6] Galbraith, Jay. Designing Complex Organizations,Addison-Wesley, Reading, Mass., 1973.

[7] Gerrity, T.P., Jr. "Design of Man-Machine DecisionSystems: An Application to Portfolio Management,"Sloan Management Review, Vol. 12, No. 2, 1971,pp. 59-75.

[8] Ginzberg, M.J. "A Process Approach to ManagementScience Implementation", unpublished Ph.D. disser-tation, M,I.T., 1975.

[9] Ginzberg, M.J. "A study of the ImplementationProcess". presented to Implementation I1: AnInternational Conference on the Implementation ofManagement Science in Social Organizations,University of Pittsburgh, 1976.

[10] Gorry, G.A. & Scott Morton, M.S. "A Fra~nework forManagement Information Systems," S/oan Manage-ment Review, Vol. 13. No. 1, 1971, pp. 55--70.

[11] Huysmans, J.H.B.M. "Operations Research Imple-mentation and the Practice of Management," in R.L.Schultz & D.P. Slevin (eds.), Implementing Opera-tions Research/ Management Science, AmericanElsevier, New York, 1975.

112] Keen, P.G.W. "A Clinical Aproach to the Implemen-tation fo OR/MS/MIS Projects," Working Paper#780-75, Alfred P. Sloan School of Management,M.I.T., 1975a.

~13] Keen, P.G.W. "Computer-Based Decision Aids: TheEvaluation Problem," Sloan Management Review,Vol. 16, No. 3, 1975 b, pp. 17-29.

[14] Lawrence, PR. & Lorsch, J.W. Organization andEnvironment, Irwin, Homewood, II1., 1969.

[15] Leavitt. H.J. Managerial Psychology, University ofChicago Press. 1964.

[16] Loughran, B.P. & Cocks, P.J. "Airline ProgrammePlanning in British Airways European Division,"Interfaces. Vol. 7, No. 2, 1977, pp. 21-36.

[ 17] Lucas, H.C., Jr. The Analysis, Design, and Implemen-tation of Information Systems, McGraw-Hill,New York. 1976.

[18] Mann, F.C. & Williams, L.K. "Observations on theDynamics of a Change to Electronic Data ProcessingEquipment," Administrative Science Quarterly, Vol. 5,1960, pp. 217-256.

[19] Mintzberg, H. "Managerial Work: Analysis fromObservation," Management Science, Vol. 18, No. 2,1971. pp. B97oB110.

[20] N~sh0 D.R. "Building EIS, a Utility for Decisions,"Data Base, Vol. 8, No. 3. 1977. pp. 43-45.



[21] Schultz, R.L. & Slevin, D.P. "A Program of Researchon Implementation," in R.L. Schultz & D.P. Slevin(eds.), Implementing Operations Research/Management Science, American Elsevier, New York,1975.

[221 S¢ot~ Morton, M.S. Management Decision Systems,

Division of Research, Graduate School of BusinessAdministration, Harvard University, Boston, 1971.

[23] Stewart, R. How Computers Affect Management,M.I.T. Press, Cambridge, Massachusetts, 1972.

[24] Thompson, J.D. Organiz, ations in Action, McGraw-Hill, New York, 1967.

Statistical Appendix

We are trying to show that successful implementation of any type of system requires adoption at someminimum level, and that this level differs across system types.

One way to test this is to look at the responses of successful users, comparing those at the minimumrequired level to those at higher levels. That is, we want to compare the tables on the diagonal of Figure 1to those below the diagonal. We can look at the tables below the diagonal (responses to levels ofadoption greater than the minimum required for that type of system) either as the sum of the sub-diagonal entries in each column, or as the sum of the within-column averages of the sub-diagonalentries. Both are shown.

Minimum Required

Level (Diagonal)


SUCCESSFUL USERS

YES(ACHIEVED)

24

26

50

Minimum Required Level

Higher Levels (Average)

with correction for continuity = 11.4626 (p<.001)

YES NO

24 1

14 11

38 12

with correction for continuity = 6.8816 (p <.005)(Fisher exact probability = .0009607)

NO(DID NOT ACHIEVE)

1 25

22 48

23 73

25

25

5O

Thus, we have to reject the hypothesis that there is no difference between the degree to which successesachieved adoption at the minimum level required for the particular type of system and at higher levels.



We can now perform a similar analysis for unsuccessful users.


Higher Levels (Sum)


Higher Levels (Average)

UNSUCCESSFUL USERS

YES

4

8

12

NO

8

9

17

with correction for continuity = .127 (p <~.8)(Fisher exact probability = .362647)

YES NO

4 8

3.5 8.5

7.5 16.5

12

17

29

12

12

24

This violates the expected cell size assumptions for the X2 test, but it should be obvious that there is not asignificant difference between the two rows; they are virtually identical.

Thus. w.e cannot reject the hypothesis of no difference between achieving the minimum required leveland achieving higher levels for the unsuccessful users.

About the AuthorMichael Glnzberg Is an Asslstant Professor In theAccountlng Dlvlslon of the Graduate School ofBuslness, Columbla Unlverslty. He holds an S.B.In Management and a Ph.D. In ManagementSclence/Management Informatlon Systems fromthe Massachusetts Instltute of Technology, andan M.B.A. In Economlc Analysls from lonaCollege. Professor Glnzberg’s research focuseson the organlzatlonal and behavloral Issueswhlch arlse durlng attempts to develop andImplement computer-based accountlng andInformatlon systems. He Is cun’ently conductlngresearch on the appllcatlon selection andevaluatlon processes.


redesign of managerial tasks: a requisite for successful ......a requisite for successful decision...

Documents