Business process modeling is an important component of business analysis, and enables organizations to understand the processes that manage the flow of data and information.
To enable an information system 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 model business processes and the relevant data carefully and completely.
Just as many organizations have not grasped fully the need to model their data , many organizations do not model their processes logically, and even fewer refine the models to include both data and process. Good enterprise data / information management practices indicate that organizations that model their data and processes logically and use those models to develop an understanding of the business requirements achieve more success with their information systems and knowledge management.
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 that 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.
Basics of 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 (Figure 1):
Figure 1: Activities described in a logical process model
All business processes consist 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. 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 that determine the paths the data follow during the process comprise the process model. The logical process model contains only business activities, it uses business terminology (not software acronyms, technical jargon, etc.…), and it 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 or systems limitations or technical 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. The lack of a process model resulted in applications that did not meet the needs of the users and / or were difficult to maintain and enhance.
Problems with an un-modeled 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.
- Lack of effective training in the proper processes using the relevant data.
Logical Process Modeling Primer
Modeling methods can be grouped into logical and physical types. Using a combination of these formats can produce the most complete model, and no single method is sufficient to define an organization’s processes adequately.
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. The designs may be either manual or electronic, or a combination of methods and may use a variety of tools to complete the model’s components. Some of the logical modeling formats and components 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 (or task) is the lowest-level activity. Therefore:
Functions consist of Processes. Functions are identified, usually, at the planning stage of development, and can be decomposed into other functions or into processes. Some examples of Functions would include: Human Resource Management, Marketing, and Claims Processing.
Processes consist of Sequential Processes. Processes are activities that have a beginning and an end; they transform data and are more detailed than functions. They can be decomposed into other processes or into Sequential Processes. Some examples of Processes would be: Make Payment, Produce Statement of Account, and Verify Employment.
Sequential Processes (Tasks). Sequential processes are specific tasks performed by the business area, and, like a process, transform data. They cannot be decomposed further. Examples of Sequential Processes (also known as Tasks) are: Record Customer Information, Validate Social Security Number, and Calculate Amount Due.
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 and should be designed after the logical process model has been completed and approved. 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 process model may not closely resemble the logical process model, but they produce the same outcomes. The processes are modeled using process model conventions; they are not modeled with the diagrams used in logical data modeling (Entity-Relationship diagrams).
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 and an associated data dictionary or business glossary 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: Order in a process model is essential, and is one of the main ways a process model differs from a data model.
- 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 business https://www.ewsolutions.com/fundamental-principles-of-business-rules/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 there is a 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 that is under development, 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 (tasks). 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/tasks.
Constructing the Process Model Diagrams
Once the functions, processes, and sequential processes/tasks have been identified and defined, the analyst uses process modeling software to construct a set of diagrams to represent graphically 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 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.
A business analyst should also develop a means of identifying the data that is expected at each point in the process. It is important to identify areas in the process where more than one task may be performed simultaneously, to show data which is shared among participants, or different subsets of the data being made available to each participant.
Finally, it is essential to 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 Business Process 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.
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.