Business Processes and Logical Process Modeling – An Overview

Published in TDAN.com April 2000

To design an application to provide optimum benefits, the architect, designer and programmers must thoroughly understand the data and processes needed. An excellent way to gain this understanding
and prepare to implement software is to carefully and completely model business processes and the relevant data.

Business processes represent the flow of data through a series of tasks that are designed to result in specific business outcomes. This article reviews the concepts of business processes and
logical process modeling. It is a useful place to start understanding the concepts of business processes and the benefits of modeling processes as well as data.

What Is a Business Process?

A process is a coordinated set of activities designed to produce a specific outcome. There are processes for saving a file, constructing a building, and cooking a meal. In fact, there is a process
for almost everything we do. A business process is a type of process designed to achieve a particular business objective.

Business processes consist of many components, including:

• The data needed to accomplish the desired business objective
• Individual work tasks that manipulate, review, or act upon the data in some way
• Decisions that affect the data in the process or the manner in which the process is conducted
• The movement of data between tasks in the process
• Individuals and groups which perform tasks

Processes can be manual or automated, fully documented or simply knowledge in the minds of one or more people. They can be simple or complex. They can be formal, requiring exact adherence to all
details; or flexible, provided the desired outcome is achieved.

Logical Process Modeling

Logical Process Modeling is the representation of a business process, detailing all the activities in the process from gathering the initial data to reaching the desired outcome. These are the
kinds of activities described in a logical process model:

• Gathering the data to be acted upon
• Controlling access to the data during the process execution
• Determining which work task in the process should be accomplished next
• Delivering the appropriate subset of the data to the corresponding work task
• Assuring that all necessary data exists and all required actions have been performed at each task
• Providing a mechanism to indicate acceptance of the results of the process, such as, electronic “signatures”

All business processes are made up of these actions. The most complex of processes can be broken down into these concepts. The complexity comes in the manner in which the process activities are
connected together. Some activities may occur in sequential order, while some may be performed in parallel. There may be circular paths in the process (a re-work loop, for example). It is likely
there will be some combination of these.

The movement of data and the decisions made determining the paths the data follow during the process comprise the process model. The contains only business activities, uses business terminology
(not software acronyms, technical jargon, etc.…), completely describes the activities of the business area being modeled, and is independent of any individual or position working in the
organization. Like its sibling, Logical Data Modeling, Logical Process Modeling does not include redundant activities, technology dependent activities, physical limitations or requirements or
current systems limitations or requirements. The process model is a representation of the business view of the set of activities under analysis.

Heretofore, many applications and systems were built without a logical process model or a rigorous examination of the processes needed to accomplish the business goals. This resulted in
applications that did not meet the needs of the users and / or were difficult to maintain and enhance.

Problems with an unmodeled system include the following:

• Not knowing who is in possession of the data at any point in time
• Lack of control over access to the data at any point in the process
• Inability to determine quickly where in the process the data resides and how long it has been there
• Difficulties in making adjustments to a specific execution of a business process
• Inconsistent process execution

Logical Process Modeling Primer

Modeling methods can be grouped into Logical and Physical types. Using a combination of these methodologies can produce the most complete model, and no single method is sufficient to adequately
define your processes.

Logical Process Modeling

Logical process modeling methods provide a description of the logical flow of data through a business process. They do not necessarily provide details about how decisions are made or how tasks are
chosen during the process execution. They may be either manual or electronic, or a combination of methods. Some of the logical modeling formats are:

• Written process descriptions
• Flow charts
• Data flow diagrams
• Function hierarchies
• Real-time models or state machines
• Functional dependency diagrams

A function is a high-level activity of an organization; a process is an activity of a business area; a sequential process is the lowest-level activity. Therefore:

Each business activity in a logical process model is included in a decomposition diagram, given a meaningful name and described in detail with text. As in Logical Data Modeling, naming conventions
are quite important in process modeling. Names for processes begin with a verb and should be as unique as possible while retaining meaning to the business users. Nouns used in the activity name
should be defined and used consistently. In a decomposition diagram, each level completely describes the level above it and should be understandable to all appropriate business users.

Physical Process Modeling

Physical modeling methods specify the topology (connectivity), data, roles, and rules of a business process. This model describes items such as:

• Work tasks to be completed during the process
• The order in which the tasks should be executed
• Data needed to start the process execution
• Data required to start and finish each work task
• Rules needed to determine routing through the process
• Exception handling techniques
• At least one defined business outcome
• Roles and permissions of each process participant

The physical model may not closely resemble the logical model, but they produce the same outcomes.

Data-Driven Approach to Process Definition

This approach, most commonly used in relational and object-oriented analysis efforts, analyzes the life cycle of each major data entity type. The approach defines a process for each phase or change
the data undergoes, the method by which the data is created, the reasons for the change and the event that causes the data to achieve its terminal state. This method assures that all data actions
are accounted for and that there are meaningful associations between the data and its processes. However, in a data-driven method, the logical data model must be completed before the process
modeling and analysis can begin.

Major points of interest in constructing a Logical Process Model are:

• The purpose of the process. Writing the purpose and referring to it frequently enables the analyst to recognize a step in the process that does not make sense in the context of the process.
• Who will participate in the process. The participants may be people, groups of people, or electronic applications.
• The order in which the steps of the process are done.
• The data you expect to be included in the process. There is an initial set of expected data, plus you should know what data you expect to be modified or added during the process. Part of this
  step is deciding which subset of the data is appropriate at each task in the process.
• Decisions that will be made during the execution of the process. These include decisions about which path the process should take, and whether all the required data is present at any given
  point in the process.
• The rules you will use to define the various parts of the process. Also, note any naming conventions that are important for the business.
• The disposition of the data at the end of the process. That is, will the data be retained or deleted? If you plan to store the data, where and in what form will the data be kept? Do future
  process-related reports need to access the data?

There may be other elements in the business processes that need to be included in the model. The more complete the model, the easier it will be to implement the software, and the more successful
the processes will be in producing the desired output.

Process definition also helps you know when a process should be broken into smaller, sequential processes. If the definition of a process is ambiguous or lengthy, it is usually a candidate for
decomposing into sequential processes. All functions are decomposed to processes, and all processes are ultimately decomposed into sequential processes.

Constructing the Process Model Diagrams

Once the functions, processes and sequential processes have been identified and defined, the analyst uses process modeling software to construct a set of diagrams to graphically represent the
business processes under scrutiny.

In drawing the diagrams, consider including the following items:

• The starting point of the process. There could be more than one starting point, depending on the purpose and the operation of the process. If a process contains more than one starting point,
  include all of them.
• All tasks to be performed during the execution of the process.
• The order in which the tasks should be accomplished, including any tasks that may be performed in parallel.
• All decision points, both those having to do with choosing a path through the process and those that determine whether or not the process should continue.
• Any points at which the process path may split or merge.
• The completion point of the process. As a process may have multiple starting points, it can also have multiple completion points.

You should also develop a means of identifying the data you expect at each point in the process. Be mindful of areas in the process where more than one task may be performed simultaneously. In
these areas, you may need to show data being shared among participants, or different subsets of the data being made available to each participant.

Finally, include the ending point(s) of the process. This indicates that the process has been completed and that all the data generated by the process can be identified.

Reviewing the Model

As in Logical Data Modeling, plan to spend a significant portion of modeling time reviewing the model. Validate your assumptions by reviewing them with the people who are involved in executing the
process to be certain your assumptions are correct and complete.

Verify all data requirements to ensure that all the data needed has been identified, while using what data is needed at each step in the process. It is a good practice to perform this verification
at each sequential process defined.

A good check of the accuracy of any model is to simulate it by walking through the process manually. This allows the analyst to locate any points in the processes that are not valid before system
construction.

Once the process has been successfully simulated, review the results with the people who understand the expected results from each function and process. This verification step allows the process
experts to understand the model you have created and point out any potential problems with the model before beginning the deployment of the model.

Summary

Like Logical Data Modeling, Logical Process Modeling is one of the primary techniques for analyzing and managing the information needed to achieve business goals. It is important that analysts
understand the concepts of process modeling, the methods used in process discovery and definition, and perfect the analytical skills for relating and explaining the data and processes used by a
business area. Properly performed, logical process modeling can greatly assist the system architects and developers in their efforts, producing functional and scalable applications.