ENTERPRISE MODELING:MODELING BENEFITS

MODELING BENEFITS

Enterprise models are used as instruments for better understanding business structures and processes. Thus, the general benefit of enterprise modeling is in business administration and organizational processes. Focusing computer support in business, we can use enterprise models additionally to describe the organizational impacts of information technology. Consequently, the second major benefit of enterprise modeling is for developing information systems.

Benefits for Business Administration and Organizational Processes Corporate mission statements entail the production and utilization of material output and services by combining production factors. Multiple entities and devices are responsible for fulfilling these tasks. In accordance with corporate objectives, their close collaboration must be ensured. In order for human beings to be able to handle complex social structures such as enterprises, these structures must be broken down into manageable units. The rules required for this process are referred to as ‘‘organi- zation.’’

Structural or hierarchical organizations are characterized by time-independent (static) rules, such as by hierarchies or enterprise topologies. Here, relationships involving management, output, infor- mation, or communication technology between departments, just to name a few, are entered. Org charts are some of the simple models used to depict these relationships.

Process organizations, on the other hand, deal with time-dependent and logical (dynamic) behavior of the processes necessary to complete the corporate mission. Hierarchical and process organizations are closely correlated. Hierarchical organizations have been a key topic in business theory for years.

However, due to buzzwords such as business process reengineering (BPR), process organizations have moved into the spotlight in recent years.

Reasons for creating business process models include:

• Optimizing organizational changes, a byproduct of BPR

• Storing corporate knowledge, such as in reference models

• Utilizing process documentation for ISO-9000 and other certifications

• Calculating the cost of business processes

• Leveraging process information to implement and customize standard software solutions or workflow systems (see Section 2.2).

Within these categories, other goals can be established for the modeling methods. In business process improvement, we must therefore identify the components that need to be addressed. Some of the many issues that can be addressed by business process optimization are:

• Changing the process structure by introducing simultaneous tasks, avoiding cycles, and stream- lining the structure

• Changing organizational reporting structures and developing employee qualification by improv- ing processing in its entirety

• Reducing the amount of documentation, streamlining and accelerating document and data flow

• Discussing possible outsourcing measures (shifting from internal to external output creation)

• Implementing new production and IT resources to improve processing functions

In these examples, we are referring to numerous modeling aspects, such as process structures, hierarchical organizations, employee qualification, documents (data), and external or internal output as well as production and IT resources. Obviously, an enterprise model, particularly a business process model for the purpose of optimization, must be fairly complex. Moreover, it should address multiple aspects, for which numerous description methods are necessary. These various purposes determine the kind of modeling objects as well as the required granularity.

Benefits for Developing Information Systems

Information systems can be designed as custom applications or purchased as off-the-shelf standard solutions. After the initial popularity of custom applications, integrated standard solutions are now the norm. With the advent of new types of software, such as componentware (where software com- ponents for certain application cases are assembled to form entire applications), a blend between the two approaches has recently been making inroads.

The development of custom applications is generally expensive and is often plagued by uncer- tainties, such as the duration of the development cycle or the difficulty of assessing costs. Thus, the tendency to shift software development from individual development to an organizational form of industrial manufacturing—in ‘‘software factories’’—is not surprising.

In this context, multiple methods for supporting the software development process have been developed. They differ according to their focus on the various software development processes and their preferred approach regarding the issue at hand, such as data, event, or function orientation, respectively.

Due to the wide range of methods that differ only slightly from one another, this market is cluttered. In fact, the multitude of products and approaches has actually impeded the development of computer-aided tools based on these methods. We therefore recommend a methodology (study of methods) covering various development methods. The following are typical questions that leverage the framework capabilities of a methodology:

1. Are there really so many totally different ways of designing a computer-aided information system?

2. If not, how similar are these methods? If so, why are there so many different ways?

3. Is there an optimal way of developing an information system?

4. Where does the development process start and where does it end?

5. What does the finished product of the design process look like?

6. How many steps are necessary to obtain a development result?

7. Should only one particular kind of information system be used or are several methods required, each for a different system? According to which criteria should the methods be selected?

The purpose of these questions is to classify and evaluate the various modeling methods. After these issues are addressed, there is, however, a second group of reasons for dealing with information system design methodologies (ISDMs), resulting from the fact that usually several business partners are involved in complex development projects. Sometimes they use different development methods, or the results of their work might overlap. Only an architecture integrating the individual methods, confirming agreement or pointing out any overlap, can lead to mutual understanding.

The alternative to individual software development is to buy a standardized business administra- tion software solution. Such solutions include modules for accounting, purchasing, sales, production planning, and so on. Financial information systems are characterized by a markedly high degree of complexity. Many corporate and external business partners are involved in the implementation of information systems. This becomes apparent in light of seamlessly integrated data processing, where data is shared by multiple applications. Examples include comprehensive IS-oriented concepts im- plemented in enterprises, CIM in manufacturing companies, IS-supported merchandise management systems for retailers, and electronic banking in financial institutions.

Until the mid-1990s, the ratio between the effort of implementing financial packaged applications in organizations and their purchase price was frequently more than 5:1. This ratio is so high because off-the-shelf systems are more or less easy to install, yet users must also determine which goals (strategies) they wish to reach with the system, how the functionality of the system can achieve this, and how to customize, configure, and technically implement the package.

With hardware and software costs rapidly decreasing, that ratio became even worse. Small and medium-sized enterprises (SMEs) are not able to pay consultants millions of dollars for implemen- tation. Hence, architectures, methods, and tools have become increasingly popular because they can help reduce the cost of software implementation and at the same time increase user acceptance of standard software solutions.

Several modeling approaches are possible:

• Reduce the effort necessary for creating the target concept by leveraging ‘‘best-practice case’’ knowledge available in reference models.

• Create a requirements definition by leveraging modeling techniques to detail the description.

• Document the requirements definition of the standard software by means of semantic modeling methods, making the business logic more understandable.

• Use semantic models to automate reconciliation of the requirements definition of the target concept with the standard software as much as possible, cutting down on the need for specific IS skills.

• Leverage semantic models as a starting point for maximum automation of system and config- uration customizing.