Analyzing Business Processes for an Enterprise System

Consider the question, "What are you doing now?" We can answer this question at

many levels of abstraction. We might say:

* "I'm living in Berkeley and taking courses at the University."

* "I'm studying Document Engineering."

* "I'm reading section 9.1."

All these answers may be true, but they may not be equally useful or informative to

the questioner. How we answer the question depends on how much context we share

with the person asking the question. What do they already know about us and what

we are doing? Did we last talk to them 10 minutes or 10 years ago? If we have a

common context, it makes sense to answer the question with a very specific answer.

If we don't, a general or more abstract answer is more appropriate.

This simple example illustrates a fundamental challenge when we analyze anything.

Some things have a conventional level of description, and some levels may seem more

intuitive or natural than others, but there are almost always alternatives to any

description.

Business processes can be described at many

levels of abstraction

Business processes are particularly subject to this description ambiguity. Often we

can't directly observe the processes we want to analyze. We can see them more easily when they deal with tangible or physical objects, but many business processes

involve intangible goods or only information about goods. Modeling business

processes is also difficult because the key involvement of people and organizations,

as opposed to mechanical or physical factors, can result in models that have idiosyncratic or unexpected characteristics.

We will attack the level of abstraction problem by systematically decomposing our

process descriptions into a three-level hierarchy. We will use business reference models as a guide because their hierarchical organization of processes has been designed

9.1 THE LEVELS OF

ABSTRACTION CHALLENGE

DOCUMENT ENGINEERING ANALYZING AND DESIGNING DOCUMENTS FOR BUSINESS INFORMATICS & WEB SERVICES277

to reinforce different levels of granularity. We will use metamodels for process

descriptions at each level that provide us with standard metadata for defining what

the processes mean and how they are carried out.

We analyze a business to create a common understanding of how it works and the

domain in which it operates. The level at which we start our analysis, and the

amount of detail in the resulting analysis, depends on where our emphasis lies on the

continuum from strategic initiatives to merely tactical projects.

We'll present a modeling approach in this chapter that starts with the most abstract

perspective and works its way down to progressively more granular models. Some

business organizational patterns are described using the B2C, B2B, and the other

acronyms we discussed in Section 4.1.2 that characterize business relationships by

their commerciography.

3

Even these extremely coarse patterns raise predictable

issues and challenges about producer-consumer relationships, legacy technology,

competition, governance, and regulations.

When we look inside a business, we might be tempted to rely on its organizational

model as an analogy to its process model. But from a business process perspective,

the functional business areas of any organization, such as manufacturing, engineering, marketing, sales, finance, and human resources, are purely logical entities that

exist to carry out a company's business model. There is no necessary relationship

between business process patterns, an enterprise's management structure, and the

support for carrying out the processes in facilities, technology, and systems.

9.2

ANALYZING BUSINESS ORGANIZATION

ANALYZING BUSINESS PROCESSES278

There are no necessary relationships between business

processes, management structure and facilities,

technology, and systems

This is a subtle but important point. The fact that an enterprise performs a purchasing process does not imply that it has a purchasing organization,