Brandon - a 22 year old knowledge worker in a multi-billion dollar manufacturing company - is a master at his craft, which is best described as a computer jockey. He navigates the company's enterprise resource planning systems with ease, slinging data from field-to-field, finding answers to inquiries without the least hesitation, and simultaneously mentoring his peers on how to do this or that- by telephone, by e-mail, or by yelling over the cubicle wall. He doesn't seem bothered by long, complex sequences of navigation that frustrate even his most seasoned colleagues. He always seems to get his work done on time, and he never seems frustrated.

Once each month Brandon spends his lunch hour at the local Staples store buying office supplies. He moves through the store with characteristic ease, filling his shopping cart with exactly what is needed with respect to this mundane, but nonetheless important job function. When he returns to the office, he hands over the supplies to Karen, who is responsible for the stock room, then goes back to his desk. He opens an Excel spreadsheet, makes a few minor adjustments to numbers to reflect his noontime purchase, prints out the spreadsheet, and attaches it to an employee expense reimbursement form, along with the original receipt, then drops it off at his supervisor's desk. He then returns to his desk and resumes slinging data around his enterprise systems.

What is simultaneously peculiar and familiar about this scenario is that Brandon's enterprise system includes processes and functionality for replenishing office supplies. But he doesn't use them. Why? Because he learned long ago that using the enterprise system for this function is difficult, error-prone, and frustrating. In fact, the only time he ever got into serious trouble with his supervisor was over the internal supply orders. So now, with characteristic grace, he simply subverts the system to accomplish the business goal and, frankly, to maintain his sense of hassle-free pleasure on the job. To many - including his supervisor - Brandon is both an innovator and "a company man," for within the immediate corporate microcosm of such tasks, he meets the business goals.

The story is true, the problems not unusual, and the business consequences serious. Which problems? The difficulties that Brandon experienced with the enterprise system around internal supplies comprise one problem, but even more serious is that of subverting the system to accomplish the business goal. Both problems carry with them significant costs to the business. In the former case, the corporation has tried developing training programs, adding help systems, distributing special instruction notices, conducting after-hours coaching sessions, hiring "wandering trainers," and even commissioning system re-design work in attempts to alleviate the complexity, eliminate the confusion, and obliterate the errors. In the latter case, the company suffers from paying higher prices for supplies and generally losing control of its internal inventory and distribution systems. What the company has failed to realize is that Grudin's Law is at work:

Nevertheless, Brandon's subvert-the-system tactics are brilliant and insightful in a very specific way, which shall become clear shortly. First, he had the insight that attempting to use the enterprise system was not worth his time. As quick and bright as he is, the training programs, help system, and other attempts to fix the problem by filling a perceived skill gap did not solve his problem. Brandon realized that no matter how skilled he was on the system, he could not achieve the necessary efficiency or accuracy to meet the business need. The inherent complexity of the system was, in Brandon's implicit view, the problem.

Brandon's world of work is one of being competent (and therefore happy) all of the time - which means always being able to achieve the business goal. To him there are three fundamental aspects of competency: (1) the complexity of the work he must do in terms of business rules, policies, procedures, and decisions; (2) the complexity of the tools of the trade (in this case the enterprise systems); and (3) the skills, knowledge, and abilities that he possesses to conquer (1) and (2) and thus get his job done. In the case of his work requirements around internal supplies, Brandon realized that (1) is not a problem, for the business issues and decisions around when to order supplies are straightforward. He also understands that the tools are hopelessly complex, to the extent that no amount of making changes to (3) - his skill level - can fix the problem. That is, the complexity of the tools dictates that business performance cannot be satisfactorily achieved through any amount of human performance. His solution, therefore, is to eliminate (2), the complexity of the tools, by simply not using them and replacing them with a set that is manageable (i.e., going to Staples, then using his spreadsheet and the reimbursement system).

Elements of Job Competency	Description
Business Complexity	Business rules, policies, procedures, decision-making
Tool Complexity	Computer systems, analytic tools, devices, equipment
Human Skill, Knowledge, Ability	Skill, knowledge, and ability to know and act on the business rules and command the tool set to establish and achieve business goals.

The traditional means by which organizations attempt to achieve job competency is to increase the skill, knowledge, and abilities of the human being who has to do the work. Implicit in this approach is that business complexity and tool complexity are given, fixed, immutable realities. Brandon's approach, on the other hand, was to reduce the complexity of the tools while holding everything else fixed, as depicted below:

Elements of Job Competency	Organizational Approach to Achieving Competency	Brandon's Approach to Achieving Competency
Business Complexity	assume fixed	assume fixed
Tool Complexity	assume fixed	Decrease it to achieve competency
Human Skill, Knowledge, Ability	Try to increase it to overcome business- and tool complexity	assume fixed

As we said earlier, Brandon's approach is fundamentally brilliant and insightful - not subverting the system, but realizing that there is an alternative to training to achieve competency. The brilliance of this observation is astounding in a number of ways, not the least of which is the fact that competence is fundamentally about achieving business performance through human performance, but not necessarily through how much skill, knowledge, and ability the worker is filled with.

Too often organizations have ignored the human being almost entirely in the process of implementing so-called business-enabling computer systems, or they have focused on human performance while overlooking the business imperative. These two issues, we shall see, are really just opposite sides of the same coin, where the results are the same: tremendous cost to the business.

While these problems rear their heads in a variety of corporate circumstances where computer-mediated work in involved, nowhere is it more pronounced than in the enterprise systems world. These are the behemoth enterprise resource planning (ERP) systems (SAP, PeopleSoft, Oracle, Baan), and their extensions to business intelligence, customer relationship management, supply chain management, e-commerce and back office / front office integration. To get some perspective on the extent of the problem, consider that licensing and maintenance revenue for ERPs alone is growing at a fairly steady annual rate and is predicted to increase from today's $20.5 Billion to $33.5 Billion by 2002.

At the end of the day, someone has to implement and maintain ERP systems and someone has to operate them. In the latter case, workers such as Brandon are faced with an astoundingly complex environment. Current practices suggest that it requires months or years of training to become competent in any iteration of ERP software, and the number of functions and features - and therefore complexity - continues to increase with time. Further, the means through which the ERP is presented to the worker - the graphical user interface (GUI) - has outlived its usefulness as a viable means for organizations to leverage their ERP investments. Very simply, the advantages of ERP functions from engineering and business perspectives do not scale up to users[1], meaning that we have created an environment in which business performance is largely unachievable through human performance.

According to Juala Moran, ERP software alone cannot service the enterprise. A survey of 164 ERP user companies in 62 US fortune 500 companies published in 1999 by Deloitte Consulting reflects this. The survey found that "ERP enabled enterprises are now using a variety of bolt-ons and other complementary technologies" while attempting to attain business performance - and still failing in many important ways. ERP functionality may form the backbone of the business requirements, but to make them usable, functional, and maintainable - from business and human perspectives - they require more.

These "bolt-ons" take many forms, including components that have traditionally been called performance support, or EPSS (electronic performance support systems). Unfortunately, such additions are comprised of brief electronic training materials, cue cards, help systems, and other forms of context-sensitive assistance created to overcome the design deficiencies of the system. Brandon, for example, might encounter an icon on his ERP toolbar labeled "office supplies" when he attempts to muddle through the task sequence. When he clicks on the icon, the help file or training nugget opens and gives him a detailed step-by-step procedure to follow to accomplish the task error-free.

The problem with this so-called extrinsic support is that Brandon must not only perform the task, but he must read through the procedure, which doesn't stay synchronized with his ERP navigation - particularly when he makes a mistake. Such a "solution" is akin to the highway department "fixing" a 3-meter-deep fissure in a roadway by placing a sign immediately in front of it that says, "Don't drive into the fissure." There are many other problems with this approach, which will be addressed subsequently.

In current software industry terms, ERPs require enterprise application integration (EAI) products. "These sit above the traditional middleware that provides the messaging to allow applications to communicate, enabling them to interoperate. There is a growing requirement for real-time interapplication links, to mirror the business processes they support." However, with integration comes an incredible increase in complexity as the human being now has to master multiple systems to complete a simple task. Bob Tate, senior executive at US software house Vantive, recently referred to SAP as "the software that grows like a weed."

Another popular response to the problem is to introduce enterprise "portals" and related browser-based interfaces to the many systems that are integrated "on the back end." For some reason designers and vendors of these web-based solutions would have us believe that this approach solves the problem. True, it may alleviate the need to learn many different interfaces, and most people today have some familiarity with the point-and-click controls of a browser-based application, but Brandon's fundamental problem is not solved with the browser approach. First, those layers-upon-layers of menus inherent in the legacy applications are replaced with layers-upon-layers of hyperlinks. Second, if thousands of features supported in a conventional graphical interface (Windows variety) violate fundamental human factors, how is an improvement to support the same thousands of features in the more organizationally rigid, control-poor, and real-estate-restricted world of browsers?

ERPs are operated by people like Brandon with a personal computer (PC) client, and herein lies the rub: the PC as we know it is all wrong for this purpose. "Computers are complex, difficult to learn, difficult to use, difficult to maintain," says Donald A. Norman. Because the PC is designed to do more and more unrelated things - particularly in the context of ERP software, where the market perpetuates this trend - it is doomed to resist becoming a human-centered device that is simple, reliable, versatile, and pleasurable. The business model of the PC in context with the complex nature of the ERP runs contrary to the needs of the ERP user. This is why Brandon goes to Staples and uses his simple spreadsheets and reimbursement forms to get office supplies.

When more and more tasks must be supported by the same device, the ability to accommodate simplicity through physical design diminishes, and ultimately disappears. The number of tasks that must be performed by an ERP on a PC with the same keyboard, mouse, and interface type keeps increasing in an unbounded fashion. Thus complexity seems to increase without bound, which runs contrary to Brandon's nature and preferences. If you count the number of choices presented by the cascading menus of PeopleSoft, for example, you will find as many as 3000 (three thousand) combinations within a single drop-down menu.

Items (1) and (2) in the above list are in many ways responsible for organizational inability to achieve business performance through human performance; item (2) points to the tragedy of just how much money is wasted trying. If business performance cannot be achieved through human performance, then training programs and other extrinsic or external forms of "support" represent an enormous waste of money in terms of developing and deploying them, and often taking workers away from their jobs to engage them. Consulting help lines, help systems, reading manuals and bulletins, asking coworkers, and adding all sorts of external supports to systems and the like are additional contributors to the travesty.

In early 1999, the ERP education and training services market was valued at $1.15 billion and is projected to exceed $3 billion by 2002. In view of ERP industry statistics, we can interpret this to mean that today it costs about 5% of the cost of the software license to provide training and services for an ERP, and that this will increase to over 9% by 2002. Individual training engagements by so-called performance improvement consultants, for example, can cost between $50,000 and $200,000 each - just to overcome basic organizational productivity losses experienced when a new ERP is introduced. But the fundamental reason why the ERP training and support market is growing proportionally faster than the ERP market itself is because the infrastructure and basic designs confound business performance through human performance. It's like attending to a leak in a car tire by adding air when it gets low: the hole keeps getting larger, perpetuating the demand for more air more frequently.

Even the casual observer will ask, Why is the cost of training so high, and why is it always increasing? We see from Brandon's insight that the enterprise systems industry is hopelessly stuck in terms of enabling business performance through human performance. The human being's platform, the PC, is all wrong as a multi-purpose device. ERPs, like all software, belongs to an industry that perpetuates itself through planned obsolescence, then responds with new versions that have more and more features and complexity. In the consumer market, for example, MS Word 2.x had about 350 features; a few years later, MS Word 97 was released with over 1300 features. The situation is far worse with regard to enterprise software. So, of course, the cost of training and support is high and continuously increasing.

A fundamental design flaw in ERPs is their data centricity, which can be illustrated very simply by considering almost any routine system transaction. Whether it is Brandon generating a purchase order or an HR generalist changing an employee's marital status or pay grade, the process inevitably involves multiple steps of navigation through layers of menus or hyperlinks to get to a number of screens or panels that include relevant data fields. The human being performing the task must know which data are relevant to the business transaction from the system's perspective (i.e., its data model). Further, the person must remember or learn how to chain the relevant screens together through navigation to appropriately enter the data. Pure and simply, the worker is burdened with mapping the business process to the system's navigational- and data schema.

The irony is that sometime during the system design process a flow of work was established, perhaps through interviews with work experts. Once the system designer understood the process and business issues involved, he or she distilled from this a set of requirements, then created specifications for system features. These features manifest themselves in the completed and deployed system as collections of menu items, panels containing data, a data structure, a means to query the data and generate reports, and the like. What is typically missing from the result is that fundamental flow of work from whence the requirements came. Training (and related forms of support), therefore, is the exercise of the reconstructing for the worker the flow of work that was articulated by the expert in the first place but which now must be manually accomplished through navigation! Further, we find in many cases that such training conducted in advance of doing is ineffective, in many cases simply because the worker does not remember the details by the time the task is encountered on the job. In the end the worker is saddled with the cognitive burden of mapping the workflow onto the navigation scheme and data model.

Why wasn't the system simply designed to reflect or literally enable this workflow, so that the worker does not need to learn navigation but can simply learn the business? Because the designer is concerned with data and the data transaction view of business, not with how human beings see the business. Data is clearly important; in some cases, it is the most important corporate asset. But the designer's psychology is simply this: the system is the guarantor business qua data integrity, while the human being is the user of the system.

The very practice of referring to the human worker as the "user" - which this chapter has avoided thus far - perpetuates the problem of properly representing the human being in system design, development, and evaluation. The term probably came to pass with the transitional from data processing to so-called "end-user computing." Whether the computer systems in question were commercial products or in-house (custom) applications, there has been a trend toward placing them in the hands of people who do the work but are not software (engineering) experts. The primary motivation for this practice has been business process improvement, by way of removing intermediaries from business transactions. For example, at one time reams of figures written on paper by those who conduct the business were key-punched onto cards daily, then processed into the systems overnight by the system (data) experts. Later, end-user interfaces to the data repositories were developed with tools such as CICS so that data entry could be accomplished at the source (although it would be held in "batches" for later processing, when these new or modified data were merged into the corporate repositories).

The notion of real-time processing evolved, which enabled those who conducted the business to not only enter transaction data directly, but could see its representation in the system immediately. Functionality further evolved in the user interface toward representations of business process and information, so that expert intermediaries have all but vanished, leaving only software developers as experts. Thus the dichotomy remains between the non-software-expert system "user" and the software-expert "developer."

Somehow, the notion of a person expertly "using" a system confuses the notion of accomplishing business with understanding what the developer created. This phenomenon is related to a portion of the process Geoffrey Moore calls Crossing the Chasm, where early adopters enamoured with technology qua technology put up with inconveniences at the early stages of a product's introduction to the market because they see some overwhelming utility that far outweighs the tribulations of mastering the device. More to our point, the early adopters share much of the curiosity about the technology that motivates designers. How many people, for example, were in awe of VisiCalc in the 1970s, not necessarily because of what it saved them in time and effort, but because of what it could do functionally? In such cases, mastery (including understanding what it was doing and how it was designed) was an end-in-itself rather than a means to an end - and represented an intellectual kinship of sorts with Dan Brickland, VisiCalc's developer.

In the enterprise systems world, the designer is challenged with extremely complex engineering problems around software layers (data, middle, application, presentation), speed and distribution, capacity, security, and a host of constraints imposed by the organization's technological- and business infrastructures. In total context, the "user" is not really thought of as the person who accomplishes business, but instead the person who will successfully communicate with the application layer and, in turn, the middle layer and data layers of the designer's colossal engineering feat through the presentation layer - the skin - of the system. Think about it: beneath the "skin" lies an impressive, complex, breathtaking set of engineering structures that evoke the same awe we experience when we see physical engineered feats, such as skyscrapers, the space shuttle, or aircraft carriers. The "user" is perceived as privileged to do just that: use the magnificent achievement, but on the designer's terms, which is through the skin. Further, the amount of attention that the creator could possibly devote to the skin of the prodigious creation must stand in proportion to what is really important.

So the "user" is someone who is graced with the good fortune to make use of the massive machine - and who will, of course, put up with the task of deciphering the cause-and-effect between the skin and the machine. The designer's perspective is that every aspect of the machine was built to support the business. So "using" the system is assumed to mean conducting business - when it is, in fact, an exercise comprised largely of guessing what the system needs from the skin in order to function.

The user - system dichotomy has many more serious implications with respect to ensuring business performance through human performance. For example, the designer's perspective is from the inside (data) out, rather than from the outside (business) in. The very notion of the computer interface as the "skin" through which the human being interacts with the system begs the question, as the metaphor implies that the human must know in advance what the system is expecting. On the other hand, the system must know in advance what the human is expecting - if the human-computer interaction is to be successful. In the absence of cognition, the scenario is an infinite regression (e.g., the person needs to know what the system expects, which needs to know what the person expects, who needs to know what the system expects, and so on ad infinitum). Pathological, perhaps? No - in fact, it provides compelling proof of the impossibility of business performance through human performance in cases where the design basis of the interface is behaviorist versus cognitive - which is very often the case. Attempts are made to "correct" the problem by adding a cognitively-based wrapper of sorts, in the form of training modules, context-sensitive help, and so forth. On the other hand, if the interface is based in cognition, then the scenario remains hopeless because the system is data-centric, while the person is business-centric. Remedies lie in system models that are business-centered, goal-directed, and activity-based, where the human being is an integral part. Such attributes, we shall see, form the basis of performance centered design.

We will encounter these and more problems with the notion of "user" subsequently, in context with remedies. For now, and for the remainder of this book, we will dispense with the term "user" at all cost. If the goal is to ensure business performance through human performance, then the worker is a business performer. This term, introduced by Gloria Gery in the context of performance support systems and, similarly, discussed by Brenda Laurel, places the focus where it belongs: (1) on the business and/or its representation; (2) on an outside-in design process; and (3) places human action -the activity of conducting business - solely within the business representation.

To be sure, the above discussion does not ignore the fact that engineers have attempted to represent the human being in the software design and development processes. As early as 1970 companies such as IBM stressed a "user focus" that has evolved into formal usability practices, including evaluation laboratories and inspection methods. Human factors engineers are now integral to the software design and evaluation functions. The trend has generally evolved with customer-focus and Quality practices that are responsible for business success in other industries, most notably the Japanese auto industry through the 1980s and 90s. Today, usability is literally a business, particularly with the explosion of e-business. For such systems, the human factors are critical to success, because there are fewer and fewer knowledgeable human intermediaries between the buyer and the supplier. Consider, for example, the "one click order" that we find on successful e-business web sites.

In the literature we have frequently seen the defense of the human being in the age of the machine. Donald Norman, Brenda Laurel, Alan Cooper, Gloria Gery and others have since the late 80s championed the cause; their predecessors - Ted Nelson, Douglas Englebart, and others paved the way in the 60s and 70s. With the exception of Gloria Gery, each has approached the problem from a unique and important perspective that addresses necessary but not sufficient conditions for ensuring business performance through human performance. Performance Centered Design aims to address sufficient conditions, and expand on the work started by Gloria Gery. But we must first examine the flip side of the problem just discussed: the consequences of focusing on the human factors in the absence of business focus.