Modeling the Business Process
Modeling the business process is an essential part of any software development process. It enables the analyst to capture the broad outline and procedures that govern what it is a business does. This model provides an overview of where the proposed software system being considered fits into the organizational structure and daily activities. It can also provide the justification for building the system by capturing the current manual and automated procedures that are to be rolled up into a new system, and the associated cost benefit.
As an early model of business activity, it enables the analyst to capture the significant events, inputs, resources and outputs associated with business process. By connecting later design elements (such as Use Cases) back to the business process model through implementation links, it is possible to build up a fully traceable model from the broad process outlines to the functional requirements and eventually to the software artefacts actually being constructed.
As the Business Process Model typically has a broader and more inclusive range than just the software system being considered, it also enables the analyst to clearly map what is in the scope of the proposed system and what is to be implemented in other ways (eg. a manual process).
Process Modeling Notation
A business process model typically defines the following elements:
| · | The goal or reason for the process |
| · | Specific inputs |
| · | Specific outputs |
| · | Resources consumed |
| · | Activities that are performed in some order, and |
| · | Events that drive the process. |
The business process:
| · | Can affect more than one organizational unit |
| · | Can have a horizontal organizational impact |
| · | Creates value of some kind for the customer; customers can be internal or external. |
The Business Process
A business process is a collection of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how the work is done within an organization, in contrast to a product's focus on what. A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs: a structure for action. The notation used to depict a business process is illustrated below.
The process notation implies a flow of activities from left to right. Typically an event element is placed to the left of the process and the output to the right. To specifically notate the internal activities, UML activity elements can be placed inside the process element.
Inputs, Resources and Information
Business processes use information to tailor or complete their activities. Information, unlike resources, is not consumed in the process; rather it is used as part of the transformation process. Information can come from external sources, from customers, from internal organizational units and could even be the product of other processes. A resource is an input to a business process and, unlike information, is typically consumed during the processing. For example, as each daily train service is run and actuals recorded, the service resource is 'used up' as far as the process of recording actual train times is concerned.
The notation to illustrate information and resources is shown below.
A supply link indicates that the information or object linked to the process is not used up in the processing phase. For example, order templates can be used over and over to provide new orders of a certain style; the templates are not altered or exhausted as part of this activity.
An input link indicates that the attached object or resource is consumed in the processing procedure. As an example, as customer orders are processed they are completed and signed off, and typically are used only once per unique resource (order).
Events
An event is the receipt of some object, a time or date reached, a notification or some other trigger that initiates the business process. The event might be consumed and transformed (for example a customer order) or simply act as a catalyst (for example, nightly batch job).
Outputs
A business process typically produces one or more outputs of value to the business, either for internal use or to satisfy external requirements. An output might be a physical object (such as a report or invoice), a transformation of raw resources into a new arrangement (a daily schedule or roster) or an overall business result such as completing a customer order.
An output of one business process might feed into another process, either as a requested item or a trigger to initiate new activities.
An output link indicates that the business process produces some object (either physical or logical) that is of value to the organization, either as an externally visible item or as an internal product (possibly feeding another process).
Goals
A business process has some well defined goal. This is the reason the organization does this work, and should be defined in terms of the benefits this process has for the organization as a whole and in satisfying the business requirements.
A goal link indicates the attached object to the business process describes the goal of the process. A goal is the business justification for performing the activity.
Putting it together
The diagram below illustrates how the various model elements can be grouped together to produce a coherent picture of a named business process. Included are the inputs, outputs, events, goals and other resources which are of significance.
Traceability
Traceability defines the way a given business process is to be implemented in the proposed system. In an implementation diagram, use cases, packages and other model artefacts can be linked back to the business process with <<implementation>> links to signify the dependent relationship. The example below illustrates how a Business Process is implemented by a Use Case and a package. As the model develops and functional software components are built and linked to Use Cases, the business justification for each element can be derived from this model.
Note that this model also implies what is NOT being delivered. The Business Process typically includes a wide range of manual and automated procedures. This model illustrates exactly what functionality (Use Cases) are to be built to service a particular business process; any missing functionality must come from other (manual or automated) systems and procedures.
An Example
The example below is an example of the kind of model that can be built up to represent a business process. In this model, the goal of the business process is to take customer orders and to ship those orders out. A user starts the process with an inquiry, which leads to the involvement of the Book Catalogue, Shopping Cart, On-line pages and warehouse inventory. The output of significance to the business is a customer order.
The second half of the process model is to respond to a customer order and ship the required items. The second process involves the warehouse inventory, shipping company and completes when an order is delivered to the customer.
See Also