Task: Sketch a Business Process Diagram |
|
 |
Describe the business as a process sketch using a subset of Business Process Modeling Notation (BPMN). This process activity can either be internal to the business (company, organization) or between businesses. |
|
Purpose
This task provides a simple mechanism to capture complex business processes in order to gain a shared understanding of
the business.
Business Process Diagrams are sketched to capture "As-is" business process
and needed improvement, and may be the start of further detailed analysis, including, defining solution
requirements, use cases, and storyboards or part of some further Business Architecture objectives, for instance,
employment of further Business Process Management techniques, including process simulation (for instance with WebSphere
Business Modeler).
|
Relationships
Roles | Main:
| Additional:
| Assisting:
|
Inputs | Mandatory:
| Optional:
| External:
|
Outputs |
|
Main Description
As part of a business improvement it is often necessary to understand the participants, the roles and activities that
provides a result of value to the business, its customers and stakeholders.
By capturing the business in an easily understood notation, allows all stakeholders to participate in discussions,
recommendations and solution definition, to meet some specified business need, objective or goal. The business
requirements, major participants, the desired results and the reason for the change is often described in a vision
document (see Artifact:Business Vision) and is used to drive improvements in the software development.
If a vision document does not exist then there must be some documented business requirement (defect, enhancement,
e-mail, customer request) which is used to provide the scope of the Business Process Diagram, participants and
expected result
The typical improving principle associated with each objective (business requirement) is:
More information can be found at Introduction to Business Objectives and Practices
|
Steps
Create To-Be Business Process Diagram
80% of projects are updates to existing systems, in creating a new to-be business process diagram we may actually
create a new sketch, and populating it with the contents of an existing diagram, and using this as the starting
point.
|
For each new participant create a Lane
In the chosen Business Process Diagram (simple or B2B) draw a Lane that represents the role of each new participant (Actor, business
worker, etc) necessary to complete a business Result.
Existing Use Case Actors are a good source for identifying participants.
|
Add a Start Event
There are many ways that business process can be started (instantiated) - Business Process Modeling Notation defines
six ways of triggering a Start Event.
It is recommended to minimise the number of start of events for a business process as it may make it difficult to
understand, usually there is one participant who is the main role in triggering the process.If there is no clearly
identified starting participant, attach the start event to the Pool.
If an exisiting Business Process Diagram is used as a starting point, examine whether the start
event is still valid. Modify as necessary.
|
Describe the process flow as tasks and decisions
For each of the business requirements, describe the flow of Message and Data Object necessary to achieve the Process Result. The flow consists of Tasks, Decisions, Join, Fork and Sub-Process.
Tasks are activities recognised by the business and should not include software application details. The correct level
of abstraction should be maintained. Details can be add either by referencing existing Use-Cases, Storyboard and
Solution requirements, or creating new ones.
|
Optimize the process flow, by referencing sub-process tasks
After several Business Process Diagrams have been sketched there is a duplication of some part of
the process. To increase reuse, reduce maintance, improve communication and ensure consistent development of the
process, it is necessary to create re-usuable Sub-Process Business Process Diagram that optimize the process and to replace those tasks in
the main process with a Sub-Process Task. |
Add End Events
As the name implies, the End Event indicates where a process will end and represents the expect results from
the business process and often maps to features, problems described in the business vision.
Each Process Result in the sketch will have an end event. To aid clarity, it might be necessary
to have multiple end events of the same result, in the sketch, rather than trying to draw connections to a
single end event.
|
Add Use-Cases and Storyboard references
As the Business Process Diagram represents an abstract of the process it is necessary to
provide more detail to the solution, this can be accomplished by adding new or existing Use-Cases, Storyboard and
solution requirements to tasks in the process.
See the Storyboard and Use-Case guidelines for more information.
|
Add references to any supporting material
Once the draft Business Process Diagram is complete, add references (links) to any other exisiting
supporting material (web sites, documents) both within and external to the project to provide a better understanding
of the problem, and desired solution. |
Evaluate Your Results
You should check the sketch at this stage to verify that the work is headed in the right direction and has the desired Result. Review early drafts with other Business Analysts and key stakeholders, recording
their comments and applying their feedback, where appropriate, to the sketch. |
|
Properties
Multiple Occurrences |  |
Event Driven |  |
Ongoing |  |
Optional |  |
Planned |  |
Repeatable |  |
Key Considerations
Begin with your existing, classified as "As-Is", Business Process Diagrams, to identify those imrpovement sketches, classified
as "To-Be", that reflect the new solution and the changes necessary by the current project.
These "To-Be" become known as "As-Is" when used in future business solutions.
As a general guidance, Business Process Diagrams should not be used to document all the activities of a
business, but rather those that need improvement,
|
More Information
Guidelines |
|
Supporting Materials |
|
Tool Mentors |
|
|