Organizations improving performance and aligning or reengineering processes endeavor to define their core business processes. They often use ‘happy days’ use case scenarios, or they create workflow diagrams in Visio. A ‘happy-day path’ only considers flows that occur when no exceptions are encountered. So, someday the team needs to visit ‘unhappy’ branches. Converting the use case or work-flow into the formal needs of a business process model can be challenging. So I offer these simple guidelines.
Model-to-Execution: The Goal
The goal of moving a use case into a business process model is to prepare the way for model execution. Proponents of BPM believe business analysts should become process- oriented and build executable artifacts. The activities described here help this transition. As organizations become more mature in BPM, they will use process modeling standards such as business process modeling notation (BPMN).
Foundations to the Approach: Core Concepts
To envisage a practical approach to designing processes from a use case document, we should first define the main terms. First, a business process is an event activated flow of decision-coordinated activities, conducted by participants and acting on data, information and knowledge that achieve a goal. This definition arises from a compendium of the literature of BPM and business rules community. It concisely defines:
- The end state of the process design,
- The design choices,
- The role of business rules
- The translation from a use-case to a process design.
Next, I define the important terms:
- An event is a message, indicator, announcement or something similar that represents that an occurrence that has happened and has been registered
- A flow is a motion of data from activity to activity, there are two types of flows in a business process, a message and a transition,
- Data consists of structured information that is owned by a business process.
- A business decision is the outcome of business rules applied to process information
- An activity is a task that is performed by a process participant
- A participant is any resource that is involved in a business process, be it a human person, a group of people, a system or another process.
- The goal is the state, aim or object of which the process tends to or should achieve.
An effective BPM approach parses the semantic of the use case into core design components of the business process. To ‘parse’ our use case semantics, we form a map from the use case sentence into one or more of the process components defined above. Also, we wish to set apart the business rule from process activities. Use cases that expound on business rules are often implemented in systems in the software development life cycle. Here it is possible the decision will not be flexible.The challenge of the ‘happy-days’ use case is that it is not always obvious what should be an activity, participant, or decision.
Defining Participant, Activity and Flow
A use case is an ordered sequence of action descriptions. Action descriptions are complete sentences and should be in the form:
Subject … Verb… Direct Object … Prepositional phrase
To parse the sentence for the participant should be simple —the subject is the participant and the activity becomes the verb and perhaps part of the remaining phrase. In BPMN, the participant defines a swim lane and activities become rounded boxes. However, this is not always obvious from every action description, especially with business rules or decisions.
A flow, a solid arrow in BPMN, is a sequence from one activity to the next in the same swim lane. A message is a flow of data from one participant’s activity to another participant. BPMN shows the message as a dotted arrow.Watch out for the flow or message presented as all or a portion of the activity. For instance, consider these use case action description sentences:
1) Requisition Officer Selects the Order Type
2) Requisition Officer Requests a Quotation for Transport from Vendor
3)The Transport vendor reviews…
The Business Process Modeling Notation shows:
Finding the Decision, Separating the Decision from the Rule
Business rules should identify decisions in the use case. Rules discovered in use cases should be relegated to the business rules approach. Workflow diagrams that include business rules might display a sequence of data-exclusive diamonds converging on the decision. An example of a sequence of rules that approves a requisition is included below:
In use case action statements, we detect decisions or business rules activities by asking the following:
1. Does the action validate, verify or confirm information in a the process
2. Does the verb decide, direct or control the flow
3. Does the action compute values for use in a latter comparison, for instance does the action commute a value that defines a change in direction latter in the use case
4. Does the action divert the flow of the use case based on a previously decided proposition? These questions suggest sentences in the use case that might be business rules. As we have suggested, the business rule should not be a part of the process model, only the decision.
Steps to Execution
I have covered some of the steps that move a use case closer to a form that can be executed. I have not covered the critical steps of process engineering and data modeling.Data is critical to develop a process prototype. This is an activity that can be done in parallel with use case development.
Complete process models need orchestration and choreography. Engineering the solution requires an understanding of the work flow patterns for the choreography and orchestration for the problem domain.
To succeed you should understand the basic elements of the business process: the activity, participant, and decision. I have developed a simple approach to developing the process model from the use case on my Blog.
