Complexity in Enterprise Applications vs.

Simplicity in
User Experience
Matthias Uflacker
1
, Daniela Busse
2

1
Hasso-Plattner-Institut fr Softwaresystemtechnik GmbH
Prof.-Dr.-Helmert-Str. 2-3
14482 Potsdam, Germany
matthias.uflacker@hpi.uni-potsdam.de

2
SAP Labs, LLC.,
3475 Deer Creek Rd
94304 Palo Alto, CA, USA
daniela.busse@sap.com
Abstract. Advanced business applications like enterprise resource planning
systems (ERP) are characterized by a high degree of complexity in data,
functionality, and processes. This paper examines some decisive causes of this
complexity and their implications for software configuration and user
interaction. A case study of SAP

s R/3

Sales & Distribution module

exemplifies complexity in order management systems, and documents its
impact on the user experience. We emphasize the need to shield users
appropriately from underlying system complexity to provide a convenient and
simple-to-use software tool. We discuss several approaches for how to address
this.
Keywords: Enterprise Applications, ERP Systems, Software Complexity, User
Experience, Design
1 Introduction
Increasingly complex business processes, growing customer needs, and demanding
software requirements have led to heightened complexity in enterprise application
development (EAD) [7]. To define our terms: we regard "complexity" as a measure of
the resources expended by a system while interacting with a piece of software to
perform a given task [2]. Kearney et al. add that if the interacting system is a
computer, then complexity is defined by the execution time and storage required to
perform the computation. If the interacting system is a programmer, then complexity
is defined by the difficulty of performing tasks such as coding, debugging, testing, or
modifying the software. [3]. We further extend this definition by stating that if the
interacting system is an end-user, then complexity is defined by the difficulty of
performing a desired business task using the system. In this case, we apply the term
front-end complexity to mean the underlying program, and back-end complexity
to mean the difficulty of use as perceived by the end-user. By categorizing complexity
in this way, we accentuate the filtering effect that a user interface can have on
complex system internals and implementation details. Revealing front-end complexity
acts as an interfering factor for information conveyed between end-user and system.
Thus, in order to maximize work performance, ease-of-use, and user satisfaction, the
amount of complexity perceived by the user must be minimized. Eliminating difficult
or obstructive interaction patterns on the user interface level is an important, yet
challenging task in the development of standard enterprise solutions, and is an
essential step towards simplicity in user experience, something we argue for in this
paper.
1.1 A Need for Simplicity
In todays most universal and significant enterprise application scenarios, the usability
of business software has become an important differentiator for success. However, the
massive amount of data and functionality required by modern enterprise systems
imposes multiple challenges on interaction designers. They need to create a user
interface that meets specific functional requirements but at the same time adheres to
key usability attributes such as those defined by Nielsen [5]: learnability, efficiency,
memorability, and satisfaction. In order to maintain productivity, the software has to
be simple to understand and easy to use after a reasonable amount of time spent
getting acquainted with the system. Consequently, simplicity in user experience and
diligent system interaction design are considered important key factors in the
development of usable and desirable enterprise applications [4].
1.2 Goal of This Paper
It is not the purpose of this paper to present either a quantitative or qualitative
approach to software complexity assessment. Different approaches for measuring
software complexity are discussed in related literature (e.g. [2], [3]). Rather, it is the
conflict between aspired simplicity in user experience and the inherent complexity of
enterprise applications that this paper addresses.
2 Complexity in Enterprise Applications
Just like other engineering disciplines, the development of software systems is bound
by rules, constraints, and obligations imposed by numerous factions. An ever-
evolving patchwork of requirements and constraints impacts the entire development
process and ultimately affects design decisions. These system requirements, both
functional and non-functional, present challenges to the development process and add
to system complexity. A rather nave approach would be to simply create a user
interface on top of a complex enterprise system; this merely provides a transparent
view on complex implementation details. Despite the fact that most of the time this
appears to be the fastest and cheapest solution, it will most likely result in unusable
and cumbersome software. From a programmers point of view, this approach might
still appear to make the most sense. But system internals and computer processes do
not reflect real-world practices and work habits of users. Users, who need to deal with
system complexity manifesting itself in the user interface, would be better served by
an enhanced user experience that considers user interaction in relation to their needs
and goals for specific business scenarios. User interface designers are challenged with
the task of discovering these key processes and goals, and can only do so successfully
by working in a user-centered manner.

To classify a system's actual and perceived complexity, we categorize complexity
along two dimensions: functional vs. non-functional, and back-end vs. front-end
(Fig.1). "Back-end complexity" evolves from the difficulty of providing a software
platform that fulfils the functional and non-functional requirements of the targeted
market. Within this dimension, we further distinguish between intra-component and
inter-component complexity, where a component constitutes any form of a software
modularization entity (e.g. a package, module, component, or a service). End-users
are confronted with "front-end complexity" when interacting with the system on the
user interface level. Front-end complexity is determined based on measures of user
interface quality such as usability, ease of use, and learnability [5]. It denotes the
difficulty and any inconvenient burden a user experiences while trying to accomplish
certain business tasks with the system. By reducing front-end complexity,
simplification can be achieved. Appropriate human-computer interaction design
focuses on effective support of user relevant workflows and can reduce the amount of
perceived complexity to shield the user from any back-end complexity that may be
lurking underneath.
2.1 Functional Complexity
The "functional" back-end complexity of enterprise software is determined by the
considerable size of the problem domain typically addressed by these types of
applications. It is particularly influenced by the heterogeneity of the targeted customer
landscape and the resulting diversity of supported functionality and business
processes. A global market further promotes functional complexity of enterprise
software back-ends, as it exposes a number of special cases, singular requirements,
and separate treatments for each distinct targeted customer group. This not only
increases the number of considered use cases and scenarios. It also implies a complex
mesh of country- and industry-specific laws and regulations that software has to
respect (e.g. tax, accounting, or reporting directives). In addition, business processes
steadily become more complex as the relevant and available business data grows. The
number of involved participants, the integration of multi-party processes, and the
elasticity of business models complicates their implementation even further.

In this unsteady and complex deployment scenario, it is extremely challenging to
provide a functional software back-end which can be utilized by customers and
companies of different sizes, organizational structures, and diverse industries.
Because of this need, the internal functional complexity of a software component is
inevitably amplified. Supporting a large amount of required functionality leads to
capable, but heavily loaded, software components with pronounced internal code
complexity (Fig.1 (a)). Moreover, the consolidation and automation of business
processes causes an increase of functional dependencies. Originally separated by
concerns, data and functionality from multiple components are gathered to aggregate
and extend system capability. Processes now span multiple business components,
depending on both internal and external resources. An increase in inter-component
complexity is the result (Fig.1 (c)).

Software functionality, which is relevant to user tasks, has to be provided on the
applications user interface. This implies input parameters and output values, which
are returned to the user. From here we can deduce an inherent dependency between
functional back-end and front-end complexity (Fig.1 (e)): the more user-relevant
functions are covered by an application, the more functionality and appending
input/output parameters have to be presented to the users.
2.2 Non-Functional Complexity
Due to the economic value and critical importance it has for its customers, business
software has to comply with severe quality requirements. Robustness, security,
performance, maintainability, and extensibility are fundamental non-functional
requirements for enterprise applications. The fulfilment of those requirements
depends on appropriate compliance within each component, which adds to the degree
of "intra-component" complexity (Fig.1 (b)) for the software. Moreover, each module
has to ensure its adaptability and customization abilities to satisfy diverse usage
scenarios. Furthermore, the software landscape at individual enterprises is rarely built
from scratch. Parts of legacy systems are very often either replaced by entirely new
implementations or redesigned as single layers of multi-tier architectures.
Fig. 1. System complexity and perceived complexity

Compatibility with existing and collaborating hardware and software resources is
critical and has to be protected throughout this process. Compatibility with an existing
code or database, heterogeneous legacy systems, or stipulated user interface
technologies are common scenarios. This landscape integration imposes non-
functional constraints on the development process and complicates technical
solutions. Different platforms, languages, and processes among software modules also
contribute to "inter-component" complexity (Fig.1 (d)), often demanding software
adapters and intricate workarounds. The resulting implications for non-functional
front-end complexity (Fig.1 (f)) are self-evident: inconsistencies in appearance and
illogical behavior of the user interface. Ergonomic flaws and a lack of standards
aggravate non-functional front-end complexity even further.

As a result of these comprehensive non-functional requirements in combination with
an exceptionally complex problem domain, standard enterprise solutions are
characterized by a considerable general complexity level, which requires careful
consideration during the design process.
3 Case Study: R/3 Sales & Distribution
Evaluating methods for the optimization of the user experience in enterprise
applications requires an understanding of the nature of their complexity. This chapter
exemplifies enterprise application complexity by analyzing sales order management
and order variations in the SAP

R/3

Sales & Distribution module (SD). We

investigate the origin and implementation of different customer requirements and
highlight reasons for the large number of supported business functions found in the
software.
3.1 R/3 Overview
R/3 is a client-server-based standard ERP system and was SAPs fully-fledged and
well-established integrated business solution for mid- to large-scale enterprises until
the release of its successor, mySAP ERP. Still very commonly in use, R/3 features a
holistic and integrated approach for a wide range of different business tasks. Its
extensive range of functionality is delivered by a set of collaborating, but basically
independent, modules, where each module is responsible for a delimited business
area. Besides the Sales & Distribution module, which has been chosen for closer
investigation here, widely used modules include Financial Accounting (FI), Materials
Management (MM), Controlling (CO), Production Planning (PP) and Human
Resources (HR). This holistic approach provides a high level of "business integrity"
by leveraging functionality and sharing information among modules. Business
integrity is composed of "data integrity" and "process integrity" [6]. Data integrity
constitutes the shared use of enterprise master data by multiple functions from
different modules. Process integrity originates from function calls and data transfer
between modules, allowing for a seamless and automated process flow across the
enterprise. Taking an order-to-cash scenario as an example, an integrated process
might affect functionality and data related to order management, material master,
transport and delivery, and financial accounting. Data and process integrity increases
back-end complexity by fostering inter-component dependencies (Fig.1 (c)) and
configuration overhead inside integrated modules (Fig.1 (b)). R/3 reaches a high level
of variability and flexibility by allowing customers to select only those modules
which are required in their specific business scenario, and to customize the software
to their needs. The system grows with the enterprise, as further modules and resources
can be installed and configured as needed. By offering standard programming
interfaces and a unified data model, non-functional inter-component complexity
(Fig.1 (d)) in R/3 is significantly reduced.

With the provision of highly configurable and interoperable business functionality,
R/3 tries to fully cover the problem domain of enterprise resource planning. However,
such a great degree of customizability and adaptability comes with its downsides. The
total cost of ownership and deployment time are considerably increased by high
implementation efforts, business configuration and customization complexity.
3.2 Sales & Distribution
Our case study is an example from the area of standard ERP order management, a
choice that is motivated by the high prevalence of this software, its level of expected
complexity, and identifiable usability issues therein. One of the noticeable attributes
of the SD module is the crucial impact of its deployment not only on inner-
organizational units but across enterprise boundaries as well. As we will show, a well-
configured order management system integrates into a multitude of wide-spanning
operational workflows. This includes the provision of a customer interface to external
clients, which they can use to communicate with the system (e.g. for order
placement). In this regard, SD is strongly differentiated from internally operating
modules such as HR. In order to satisfy customers and their various requirements, an
organization has to construct an interface that allows seamless communication and
information interchange with external partners. Often, multiple distribution channels
are necessary; reaching from customers placing orders directly to sales representatives
via phone or through electronic commerce transactions. Electronic order placement
can be further based on numerous standards and processes (EDI
1
, RosettaNet, etc.),
which a supplier should be able support if customers ask for it. SD facilitates this
flexible behavior, but does so with an increased demand for configuration and system
complexity.

The vast scope of SD can be further characterized by the differences and varying
needs of particular order entry scenarios, such as high-volume enterprise business-to-
business (B2B), retail (business-to-consumer, B2C), or fully automated order
scenarios. All of those do not only strongly differ in respect to order volume,
conditions, etc., but they also each require a different set of auxiliary functionality to

1
EDI: Electronic Data Interchange
support both customers and suppliers. The former can be supported with guided
procedures and product recommendations (e.g. in an online shop scenario) or the
ability to demand the tracking of order status. The latter are dependant on a high level
of automation and visibility when they need to process large amounts of order
positions. Obviously, the large number of distinct ordering/selling scenarios can not
be treated in a uniform and pre-determined way by SD. Consider the span between
selling bolts and equipping a new medical facility, the differences among ordering a
customized bike, buying your favorite song online, and requesting a shipload of steel
plates on demand.
3.3 Customer Landscape and Targeted Markets
We have identified the heterogeneity of the customer landscape to be a major source
for system complexity in SD. The flexible and holistic approach of R/3 introduces a
considerable amount of functional complexity into the SD module, which
consequently needs to support a range of business cases (Fig.1 (a)). Markets served by
R/3 installations are to a large extent globally distributed and under the influence of
diverse conditions, laws, and regulations, which pushes the amount of required
functionality to the extreme. Covering this diversity of functional and non-functional
requirements with one standard solution is the challenge the product needs to meet.
Going back to the principle of modularization, R/3 addresses this challenge by
supporting businesses best practices in core modules and implementing specific and
isolated branch functionality in Industry Specific (IS) modules that operate on top.
Sales orders in the Oil & Gas sector, for example, certainly require different handling
and functionality from orders in Telecommunications. Still, SD is able to attend to
both domains. Altogether, 28 top-level industry sectors are covered by R/3 (Fig. 2),
further subdivided into more fine-grained branches (e.g. Food and Beverage as
sub-categories of Consumer Products). This differentiation broadly classifies
customers based on experience, best practices, and special requirements in their
specific business areas, speeding up system installation and customization. Yet,
business diversities, like the size and structure of the organization, markets, produced
goods, or services require special consideration and precise configuration.
Fig. 2 Top-level industry branches targeted by R/3. Customers are classified into finer-grained
sub branches, denoting industry specific needs and requirements.
3.4 Distribution Channels and Order Variants
How customer orders are handled not only depends on the industry sector. It is also
influenced by client characteristics, ordered products or services, and the degree of
process integration. For each order scenario in a sales organization, the system
provides an order variant (order type) which is specifically configured to initialize and
control the ordering process according to the requirements of that organizational unit.
The most common scenarios include orders for items that are delivered directly from
stock (sales-from-stock), produced specifically for that order (make-to-order), or
configured specifically to the customers own desire (configure-to-order).

Another important factor determining the ordering process is the customer who is
placing the order. Whether the order is domestic, international, or placed internally by
another company division will affect price, tax, and delivery calculations. Diverse
information from customer master data is used to determine pricing conditions,
discounts, credit worthiness, etc., based on process configuration (automation) and
order scenario specification. Resulting from the diversity of the customer landscape,
the SD module also has to cope with an equally complex diversity in materials that
can be ordered and managed. This leads to an extremely bloated set of parameters
being attached to any given order and to specific order items. An order can be divided
into header data, order data, and a list of items ordered. While data in the header and
order fields is relatively limited to information such as the ordering party and payment
and delivery details, the parameters available to each ordered item are much more
diverse than the minimal set that consists only of material ID and order quantity. We
identified more than 70 parameters related to order items in the Sales & Distribution
module. Each of these parameters had the right to exist, as it was required in at least
one specific order scenario or used by a number of customers, albeit a limited one.
Most of the parameters are only useful for certain industries and product types (e.g.
dangerous goods profiles or batch numbers). Others are relevant only if the order
management process is integrated and configured to automatically connect to business
functions such as booking and account determination (e.g. account assignments) or
supply chain management (e.g. available-to-promise quantities).
3.5 Process Automation
The full power of SD systems is ultimately leveraged by the automatic execution and
concatenation of activity-related business functionality and processes. A well-
integrated and customized order management system significantly supports the sales
process by automatically performing required calculations and connected processes.
Based on system configuration, operations that are typically automated and executed
on demand include product availability checks, price determination, transport and
delivery agreements, and accounting processes (Fig. 3). With this increase in process
integrity and automation, the level of functional interdependency between system
modules is boosted, contributing to system complexity (Fig.1 (c)). Taking automated
product availability checks as an example, multiple sources have to be consulted
before the system can return a result. Those sources may include material master,
storage and warehouse information, production plans, or procurement orders. The
pronounced sales process support and automation capability of SD alleviates
workflow efforts and decreases the amount of required functionality that has to be
accessible to the user. This can significantly reduce the perceived front-end
complexity of the system (Fig.1 (e)). Thus, process automation contributes to the
simplicity and economical utility of the software, and to the productivity of its users.
Nevertheless, the impact of automation on non-functional component complexity
(Fig.1 (b)) is extensive. Resources and business expertise are necessary to perform the
required configuration and maintenance work in any involved modules.
4 Dealing with Complexity: Towards Simplicity in User
Experience
As shown, R/3s Sales & Distribution module targets a variety of customers and
business tasks and provides an extensive set of functions in order to be applicable to a
wide range of scenarios. The resulting complexity is addressed by the software in
several ways. The modular structure of the architecture separates functional business
logic and allows customers to leave out unneeded components to reduce the scope of
installation. Providing a standard interface and nomenclature for business objects
simplifies the extensibility and adaptability of the back-end. Highly integrated
processes remove workload from end-users and improve efficiency, which is further
supported by a consistent look and feel on the user interface.

Yet, potentials for reducing front-end complexity are not fully tapped by R/3, which is
particularly outstanding among standard SD installations. R/3's standard user interface
(SAPGUI) neither adapts to the user's skill, nor does it offer any guiding step-by-step
procedures. Recognizable user interface patterns and consistent layout schemata are
lacking. The end-user is therefore not able to customize and adapt the user interface
according to specific needs, for example hiding unneeded fields or adjusting the
workflow. Grievances like these are typical results of a "technologydriven, inside-
out" design process (UI last). Instead, enterprise software development should build
on a "design-driven outside-in" approach to yield simple and usable tools. Simplicity
System Configuration
Fig. 3. Common scenarios for process automation in SD sales order management
can be seen here as the result of a continuous process of evaluation and selection [8].
In other words, decisions on how to simplify have to be made in steady conversation
with all involved stakeholders, including end-users.

We now will briefly discuss some prevailing approaches for how to deal with system
complexity and increase simplicity in the user experience.
4.1 Simplicity through User-Centered Interaction Design
We stress the importance of integrating and optimizing user-centered design methods
in the area of large-scale enterprise software development processes, as these help to
find and orient appropriate design decisions towards simplicity, productivity, and
ease-of-use. Addressing software complexity is always a process of finding
compromises and trade-offs between contradicting requirements. To create the perfect
application with minimal investment in time and budget is not possible, as there will
always be differences between what is desired and what can be realized under the
given constraints. To find the right balance and optimal solution for customers and
end-users requires a good understanding of how the software is going to be used later
on. Therefore, design decisions must not be solely based on functional requirements
identified through domain expertise, but need to embrace end-user knowledge and a
thorough task analysis. Several methods and patterns are known in user interaction
design to help address software complexity and information overload, such as
progressive disclosure (information hiding) or guided activities. User involvement is
not only important when deciding on what methods to apply, but it is also essential
when asking how those methods should best be applied. For example, progressive
disclosure as a method to reduce information displayed on the screen and to show this
information only when requested helps inexperienced users to work with an
application but reduces the efficiency of expert users by increasing the amount of
interaction (e.g. mouse clicks) required to acquire certain information.
4.2 Simplicity through Narrowing the Scope Focus
A reduced level of complexity in enterprise applications can be achieved by focusing
on a restricted customer landscape. "Focusing" is the explicit reduction of scope by
targeting a well-defined but smaller market. This may lead to concentration on the
requirements of one single industry branch or companies in specific countries or of a
specific size. Obviously, the total number of business processes and special
requirements that have to be considered by the software will reduce significantly,
ultimately reducing complexity and leading to product simplification. Deviating from
the principle of supporting a maximum number of business scenarios and different
customer requirements is a design decision with significant impact. Knowing what
requirements are to be supported and what functionality can be discarded is necessary.
This requires research and identification of the demands that are specific and essential
for the focused market. End-user research is therefore an important and required
practice to appropriately address the targeted market and to provide a solution that is
generally applicable and useful in its defined domain.
4.3 Simplicity through Business Configuration
The customer implementation of a flexible and wide-spanning software product such
as R/3 is a complex procedure. The system needs to be configured according to the
specific needs and business demands of the client. From this point of view, business
experts and the IT department on customer sites are end-users of the system, who
wish for simplicity and ease-of-configuration. This process can be substantially
supported by applying best practices and domain knowledge about specific business
and industry sectors. A reduction in customization time and efforts is achieved when
the system is preconfigured according to high-level characteristics of the customer
organization. By offering such services to customers, vendors can significantly reduce
the hurdle that is raised by purchase and implementation costs.

A next step in reducing configuration overhead is to introduce a higher-level and
more accessible customization procedure based on a set of questions regarding
enterprise specifics and business parameters. Such a business configuration approach
simplifies system customization by reducing the traditional implementation workload,
where the specification of configuration tables and system parameters on a very
technical level is common practice. Knowing which questions to ask and in which
context a fine-grained configuration is still feasible and reasonable, requires careful
consideration and a deep understanding of the customer landscape.
4.4 Simplicity through Process Integration and Continuity
The capability of a software product to integrate seamlessly into an existing work
environment contributes to a coherent user experience, as the need to convert media
formats and to switch between multiple tasks and applications diminishes. Process
continuity, that is the holistic support of a complex work process using one integrated
software system without interruption in workflow, reduces the amount of
comprehension the user needs to have about multiple systems plus their relations and
process dependencies. Just like good design is invisible, a well integrated tool to
support user tasks does so without drawing much recognition and observance [1]. It is
simply there to help. The more a utilized software system is isolated and dispersed on
the path to fulfill a certain business task, the more it is likely to stand in the way and
hinder the workflow of the user.

A good example for process continuity and integration is how employee time
management and recording functionality has been merged with standard organizers
and popular desktop calendar applications used throughout an organization. Another
one is the processing of ERP data in arbitrary spreadsheet tools to allow for
convenient report creation and data input. Not enforcing inapplicable work patterns,
but supporting the user in a confined environment is a key to more simplicity and
acceptance through usability. Certainly, a thorough contextual understanding of end-
user tasks and workflows is a prerequisite to achieving this.
4.5 Simplicity through End-User Training
Distinguishable from the approaches presented previously, end-user training is
instituted after or shortly before the system is deployed at customer site. Instead of
arranging for an intuitive and easy-to-use product during its design process, product
training is often a reaction to front-end complexity, major changes in personal
workflows, and steep learning curves. Yet, it is an effective way to simplify the users
acquaintance with a new complex product and to increase productivity. However,
end-user training is costly and only reasonable for central software products that are
used frequently and continuously.
5 Conclusion
In this paper, we gave an overview of the factors that make the design and
development of enterprise systems increasingly complex, such as the vast, often
multi-national user populations they target, and the extensive, particular needs of the
individual industry verticals that the software is supposed to serve. We introduced a
classification of this complexity along two dimensions: front-end vs. back-end
complexity, and functional vs. non-functional requirements. These dimensions of
complexity were illustrated with examples from the SAP R/3 Sales & Distribution
software and its requirements. Finally, ways of dealing with enterprise system
complexity were highlighted, such as user-centered design approaches and specific
interaction paradigms (to deal with front-end complexity), as well as customizability
vs. advance scoping of applications to deal with back-end (but finally also impacting
front-end) complexity.

The more these enterprise applications open themselves to markets of information
workers who are used to the user experience of easy-to-use consumer software and
the web, the brighter the spotlight can be on how we can best hide the systems
complexities for the benefit of the user. This can be achieved by applying user-
centered design and thorough domain expertise, but also by addressing topics such as
end-user customization, with business models that rest on IT-based customization
receiving higher (and more usability-focused) support on-site. The idea of "laser-
focus" applications that are built specifically for very targeted parts of a domain or
industry vertical is another approach. Many questions on how to best address this
challenge still remain unanswered, and further work will build on this initial overview
in order to tackle enterprise system complexity with an eye towards user experience
simplicity.
Acknowledgements
This work has been supported by various interview partners and ERP professionals.
The authors would especially like to thank Marei Dornick, Bettina Laugwitz, and
Andreas Zorell from SAP

AG for sharing their insights and valuable expertise on
enterprise systems and R/3 products.
References
1. Anderson, R.I., Conversations with Clement Mok and Jakob Nielsen, and with Bill Buxton
and Clifford Nass. interactions 7, 1 (Jan. 2000), 46-80
2. Basili, V.R., Qualitative software complexity models: A summary. Tutorial on Models and
Methods for Software Management and Engineering. IEEE Computer Society Press (1980)
3. Kearney, J.P., Sedlmeyer, R.L., Thompson, W.B., Gray, M.A., Adler, M.A., Software
complexity measurement. Communications of the ACM (1986), Vol. 29, Iss. 11
4. Nielsen, J., Designing Web Usability. The Practice of Simplicity. New Riders Publishing,
Indiana (1999)
5. Nielsen, J., Usability Engineering, Academic Press, Boston (1993)
6. Patig, S., SAP

R/3

am Beispiel erklrt. Peter Lang GmbH, Europischer Verlag der

Wissenschaften, Frankfurt a.M. (2003)
7. Zetie, C., Barnett, L., Why Enterprise Application Development Is So Hard And How It
Must Get Easier, Forrester Research Trends (August 2004). http://www.forrester.com
8. Zetie, C., The Power Of Simplicity In Application Development, Forrester Research Trends
(December 2005). http://www.forrester.com