Case Tools and The Productivity Paradox
This paper will explore the issue of the productivity paradox and the role of Case
Tools in the efficient use of computers. This paper will consist of three parts. The role of CASE tools, what the productivity paradox is, and how the two are related to each other.
First, the paper will explain briefly what CASE tools are, and then, what the role of CASE tools have in system analysis. We need a firm grasp of what subject we are talking about before we discuss anything.
CASE tools are defined as computer-aided software engineering. They are automated software tools. Anyone can use them. There are many forms and many types. In fact, the list of different types of CASE tools is enormous. The capabilities of CASE tools run the gambit from helping to create data flow diagrams to making Julienne fries. I am sure that the reference is that, or maybe not. It was very late at night when I checked. Anyway, with CASE tools, as with any hyped computer product, a company can do literally anything, faster, better, stronger.
Seriously, there are many different types of CASE tools. They can be summarized as follows:
Each type of CASE tool can possibly be used in any phase of a design project and thus, will be of interest to the system analyst. The software costs money, but can give a benefit in time and money saved. So, it is of particular interest to the analyst how efficient and how effective CASE tools are. The analyst needs to know what tools will be needed to achieve the project's goals.
We will concentrate on what CASE tools can do for systems analysis. The types of CASE tools we will discuss are the ones that develop information systems. Systems analysts use these tools to automate or support information system projects.
This is still a lot of different tools. Essentially, the system analyst can use all of them, to a greater or lesser degree. The use of each different type of CASE tool is dependent on the phase of the project. In the early stages of the project, the analyst uses diagramming tools to create a tangible and usually visual representation of the system. It provides a visual breakdown to the processes, and enables the analyst the ability to see the process.
The analyst uses the diagramming tools up through the analysis stage of the project. In fact, the diagramming tools are the most useful CASE tools that the system analyst can use in project design. The other CASE tools mostly automate routine tasks within a project. These are the lower ends of CASE tools, and we will simply say that these tools attempt to create efficiency in the routine tasks needed to complete a project.
The most important tools in system analysis is the diagramming and the analysis tools. The diagramming tools create a visual representation of the process, data flow, and control structures. The analysis tools check to see if the data diagrams and the visuals that the diagramming tools create make sense. Each type is very important to the design process, and we will discuss each type in detail.
CASE diagramming tools, as stated before, create a visual representation of a system. The most common technique is the data flow diagramming. CASE tools enable the analyst to see how the system works. The diagram forces the analyst to look at the business system in a different light, and to see the way information flows within it. Software such as Oracle's Designer/2000 and Cool-Gen were created to fulfill this purpose, and the analyst can use these to generate the data flows.
Now, you may ask yourself the obvious question. Data flow diagrams may be useful, but why do we need the software? We can make these diagrams with pen and paper, probably faster. An experienced analyst could probably do these data flows in their head, and just write them down. Why would the company need to spend the money to pay for this toy for the analyst to use?
That is a very good question, and we will attempt to answer it later in the paper when we discuss productivity and its relation to CASE tools.
CASE analysis tools are to diagramming tools what spell and grammar checkers are to word processors. These tools make sure that everything is in working order, and that the form looks right. These tools are an automated way to tell the user what obvious mistakes have been made. These tools are an important component to the process, yet generally unexciting. After all, a person does not try to impress people with how effective their spell checker is on their word processor. Yet, we all need the spell checker on the word processor.
But, let us go back to the question, why do we even need these programs anyway? And to answer that question, we must first discuss the phenomena know as the productivity paradox.
The productivity paradox, to put it simply, is the rather alarming trend that we see that, even though we have more computers, people do not seem that much more efficient. According to the statistics, productivity has not increased at all since the introduction of the personal computer in the workplace.
There are three basic theories about why this is so. The first is that computers do not make us more efficient. In fact, in some ways, they make us less efficient. This is the minority of thinkers. The belief is that the computer has merely automated inefficient processes, and that true change or increased efficiency cannot occur simply because computers exist. We must the processes if we are to be more efficient.
Others believe that the paradox is due to statistical error. There is no inefficiency. The measurements are simply wrong. We are measuring the wrong things. At first glance, this argument seems incredibly stupid. It seems to be saying that since the data says computers are not increasing efficiency, the data is wrong, because we know that computers are efficient. This line of reasoning seems to have its conclusion before the facts.
But the argument for this is compelling. The argument is that the benefits are intangible, and cannot be measured. These benefits, quite conveniently, also cannot be proven. The best example is the statement that computers provide better customer service. Customer satisfaction cannot truly directly be quantified. Or rather increased customer satisfaction cannot be quantified. How do we measure that? And how do we know that the measurement is accurate? We do not have alternate universes to play with to tell us what could have happened in the different situation. We are not likely to find out either. Companies are not going to voluntarily forego using computers in their business to see how annoyed their customers can get at the lower level of service, so that academics can see the effects of the lack of computers on customer satisfaction.
So, we are stuck with indirect evidence, and the faith in the mantra that computers do increase efficiency. We do not know for sure that they do in a scientific way. However, we can see evidence that perhaps we are more efficient.
Computers have raised our standards. We expect more from a business now. Not long ago, customers used to wait patiently in line while the clerk called in verification for a credit card. This process usually took about one to two minutes. Now, a customer will ask whether there is a problem if the credit card takes longer than 15 seconds to confirm.
There is not an incredible amount of tangible evidence in increased efficiency in the above example. However, it is obvious that the system is more efficient.
We can also see the higher standards in presentations. Not long ago, less than ten years, someone could give a speech in a business setting without visuals. The speaker simply had to speak, and start with a really annoying pointless joke.
Now, if the speaker is not using PowerPoint, or some sort of visual aid, the speaker is unprepared, and most likely, will not be able to get their point across. People in business love pictures, and want to see them.
The third and final school of thought on the productivity paradox is that there has not been enough time for computers to achieve their full potential. We simply have to wait some more time to achieve the wonders of technology. Then, we will see the true power of computers and all of the promises of sugarplums and gumdrops will be fulfilled. We just need to wait for the next advancement in computers to achieve explosive efficiency. It is just over the horizon. An interesting theory, but the typical businessman's response to this theory is so what, how can your program help me business? Why should the company buy these expensive computer programs? What benefit do they have?
Well, Ed Yourdon of Computer world had this to say.
"I wish that I could believe that structured analysis, -or, for that matter, information engineering, object-oriented techniques or any methodology - had the power to change our world. But one of the sad, sobering consequences of reaching middle age is the discovery that by and large, it's all BS."
What we see is the clash between hype and reality, and the resulting pessimism that results from disappointment. CASE tools do not live up to their hype. They will not solve the company's problems. The CASE tool will not instantly turn a troubled company into an industry leader. The CASE tool will not even make a decent cup of coffee. That is why companies buy a coffee maker.
So, what can a CASE tool do? It is, to put it simply, a tool. The CASE tool helps the worker become more efficient. The worker is more able with the tool, but the worker does not suddenly gain the ability to perform miracles. CASE tools do not confer divine powers. If you buy a tool set to work on your car, you don't expect the car to stop having problems. Yet, CEO expects this out of CASE tools, and also, out of computers in general.
The key is to know the reality of how much a CASE tool can help a company. And to look at the reality of the efficiency of CASE tools, we will look at a study by Wanda J. Orlikowski titled CASE Tools as Organizational Change: Investigating Incremental and Radical Changes in Systems Development for our answer to the question how efficient are CASE tools. Or perhaps, a better question, how to use CASE tools efficiently. After all, a wrench is a very useful tool, but not if you use it as a hammer.
The paper is an empirical study of tow organizations' experiences with the adoption and use of CASE tools over time. The study looks at CASE tools in terms of whether the CASE tool was used in a radical or incremental change. Essentially, it looks into the issues involving adopting CASE tools. In other words, the paper talks about the costs involved in the learning curve in CASE tools, and how that effects efficiency.
The conclusion the paper makes is that CASE tools adoption into an organization goes through various stages. The first is that the IS manager states that there is a problem that a particular CASE tool can help solve. The managers then acquire the CASE tools for the job. Then the manager, usually influenced by the organizational culture, will attempt to integrate the tools into the organization. This results in changing IS policies, practices, operations, and relations with customers. The new tools create an ungodly mess for a while.
Then, the members of the organization react to the problems that the changes cause. And either the company is changed because of the CASE tools, or it is not. The change in the organization depends on whether the CASE tool is part of a radical organization change or an incremental change. In fact, one could say the study was a study of stating the obvious.
But behind the obvious statement, and results from the study comes a very key point. Efficiency is derived from the processes, practices, and the culture of the firms, not the CASE tools themselves.
The one company in the study, SCC, saw no significant drop off in efficiency when a new CASE tool was introduced. And when the new CASE tool was fully integrated, the company saw an increase in efficiency.
The key point is that SCC knew how to use CASE tools within their organization. The company understood the role CASE tools played in their processes, and really, the new CASE tools were just minor upgrades to existing systems.
Whereas, in the case of the other company, PCC, CASE tools changed system development. The managers at PCC intended that these new systems change how they did business. So, the result was expected.
The company wanted to change the role of IS in the firm, and used the CASE tools as a method to implement that change. As a result, the efficiency of the system was temporarily compromised. For a while there, the company was much less efficient and productive under the new system than the old system.
So, what this tells us that, compared to other instances of radical change as supposed to incremental change, CASE tools had no significant independent impact on the productivity of the workers. The amount of disruption that occurred during the changes at both companies was about the same as the disruption a company would have during change of this type without CASE tools.
PCC had a large sweeping organization change. PCC suffered a large disruption, followed by a period of adjustment, and adaptation. SCC had small changes, and almost no disruption. These are the normal results for any type of disruption. So, CASE tools have no inherent effect on productivity. CASE tools, by themselves, do not increase productivity.
The productivity increase comes from the acceptance and adoption of the CASE tool within the organization. The employees have to want to use the CASE tools, and be willing to learn how to use the CASE tools. Also, the CASE tools have to fit the business culture to be effective. A CASE tool cannot be effective if it generates reports that are in a completely different format than what the company uses. Then, the CASE tool is reducing productivity because the company now has to spend time translating the report generated into a form that the company can understand. This process costs additional time and money.
What the case study shows is that CASE tools have to be integrated within the framework of the organization. The people have to be considered. The employees use the computers and the computer programs, and therefore, it is more important how the software fits the skills and abilities of the employees than how well the software does the job. A CASE tool that can do everything that a company needs is completely useless if the employees have no idea how to use it. The CASE tool must be a good fit within the organization. And thus the CASE tool can increase the productivity of the worker.
In conclusion, we can say that CASE tools can increase productivity. Workers do produce better worker. They do not necessarily produce it faster, or produce more units over time. They produce more polished and, for lack of a better word, more useful work.
CASE tools create neatness. A good system analyst can create a data flow diagram with pen and paper. After all, the most important part of a data flow diagram is the thought process. The CASE tool merely makes sure that the diagram is readable. Readability is important because the analyst wants to be able to show other people how the process works, and a nice neat printout gets the point across much better than some chicken scratching.
CASE tools are not inherently productive. They do not operate in a vacuum. One product does not fit all. Despite SAP's claims, there is not a set of software that can work for all businesses. Sometimes the lack of productivity we see is due to a bad fit. Organizational leaders believe the hype about a CASE tool, and adopt it within their organization without considering whether the CASE tool will actually work well within the framework of the organization. Human error causes the productivity paradox; not the computer programs themselves.
And so, we will say again that CASE tools are tools. They are not miracle drugs, the silver bullet, the be-all end all solution to anything. CASE tools can help make the company more productive as long as the company intelligently chooses which CASE tools to use.
Every company just needs to follow the simple adage, the right tool for the right job. If the company remembers this, CASE tools can help achieve competitive advantage and more productivity. But if not, the company is just throwing money away, and the only ones who profit in that situation are the software vendors.
Ahituv, Niv. Zviran, Moshe. Glezer, Chanan. Top Management Toolbox for Managing Corporate IT, Communications of the ACM, 42(4): 93-99, 1999 Apr.
Armbruster, Jeffrey L. Comparing CASE tools., Dr. Dobbs's Journal of Software Tools for Professional Programmer.
Brynjolfsson, Erik. Hilt, Lorin M. Beyond the Productivity Paradox, Communications of the ACM. 41(8): 49-55, 1998 Aug.
Chmura, Alan. Crockett, Henry D. Tools to Align Goals and Information Systems, IEEE Software, 12(3) : 108-109. 1995 May.
Crockett, Henry David. What's the Proper Role for CASE tools?, IEEE Software. 12 (2): 19, 1995 March.
Glass, Robert. An Open Letter to the CEO, Computerworld. 32(42):37.
Ilvari, Juhani. Why are CASE tools not used?, Communications of the ACM, 39(10): 94-103, 1996 Oct.
Orlikowski, Wanda J. CASE Tools as Organizational Change: Investigating Incremental and Radical Changes in Systems Development, Management Information Systems Quarterly, Vol 17, No. 3, September 1993.
Paul, Lauren Gibbons. CASE is a Moot Point if there is no Management Buy-In, PC Week, 12(21):18, 1995 May 29.
Triplett, Jack E. The Solow Productivity Paradox: What do Computers do to Productivity?, Canadian Journal of Economics, 32(2):309-334, 1999 April.
© Vicki L. Sauter. All rights Reserved.