Introduction
Business process modelling (BPM) is a fundamental component of key business initiatives. For example.
- Process improvement and optimisation
- Operational resilience
- Operational risk
- Regulatory compliance
- Business process automation
It is important that an enterprise can keep its business process modelling initiatives complete, consistent, relevant, and up to date. This requires a governance regime for business process models.
The purpose of this blog post is to describe how an enterprise-wide business process modelling initiative, using IBM Blueworks Live (BWL), can be governed.
The blog post describes tested ideas for the setup and management of business process modelling in BWL.
Executive Sponsorship
High level executive sponsorship is essential for a successful BPM initiative. Process owners must clearly understand what is required from them and why their role is important. The executive sponsor(s) should make the purpose of the initiative and the role of process owners very clear. This emphasis should be reinforced regularly.
Some enterprises have used an executive video to introduce the value of BPM and the role of process owners.
Ownership & Accountability
Every business process within the enterprise needs a process owner. The role of the process owner should be clearly defined within the enterprise.
For example, the role could be defined thus.
The process owner is responsible for managing and overseeing the objectives and performance of a process through Key Performance Indicators. The process owner has the authority to make required changes related to achieving process objectives.
The process owner must have the authority and accountability to fulfil this role.
Processes will be defined at different levels. It is important that process ownership and accountability is defined at all levels. A Level One process definition will be owned by a very senior (often C level) executive. The deeper level models that combine to make up the Level One process may be owned by lower levels of management.
Process Model Community
The community of users for business process models should be clearly identified. Are they process improvement teams, an operational resilience team, process participants, all of the above?
Understanding the users of the models can influence the types of information and the level of detail to be included.
A RACI or RASCI+ model can be useful. This defines who is:
- Responsible – The process participants.
- Accountable – The business owner.
- Supportive – Providers of resources to the responsible role.
- Consulted – Subject matter experts on the process.
- Informed – Roles that need to understand process progress.
- + Plus – Roles that use process models for operational or regulatory requirements.
Understanding the users for process models will help to define the appropriate level of detail to be captured and to whom the models should be made available.
User Groups
Once you understand the user needs; create Blueworks Live User Groups for each community that you have identified. You can then use these groups to setup Access to your spaces. Do not provide access via an individual user’s id/email address in each space.
Doing this provides an easy mechanism to control access. Users can be added or removed from groups. Access will change without the administrator having to check each space.
For information about how to setup and use User Groups go to the relevant entry in the Blueworks Live Help.
Business Process Modelling Lifecycle
The enterprise must define a lifecycle for business process models. This will involve the creation of models, their publication and any changes that need to be made. Each lifecycle event needs to be governed.
When a process model is created, it must adhere to standards set by the enterprise. Adherence to these standards should be validated before the process model is made available to its users.
A formal process should be defined to take a process model from definition, through creation, validation and publication.
Blueworks Live provides a default lifecycle. The Blueprint (Process Model) editor is responsible for creating a snapshot version of the Blueprint that can be published. Typically, thisblueprint will be approved by another editor or contributor using a Blueworks Live Process Application.
If approved, an Editor will click the publish icon on the Blueprint snapshot to make it available to viewers and to mark it as the “live” version of the Blueprint. Editors are then free to work on future versions of the Blueprint with the knowledge that the published version is the one that will be seen by viewers.
Any communication between the reviewer and the creator/editor can be managed using comments in the Blueprint and via Blueworks Live's collaboration tools.
This procedure is simple and well supported by the product.
Figure 1: Default Blueworks Live Process Blueprint Lifecycle
Changes to a Blueprint can also be managed using this lifecycle model. Only the currently published model is available to viewers. Editors can work on a new snapshot. Once reviewed and approved this snapshot can become the published version.
In regulated enterprises there is a need for an additional lifecycle stage that allows for regular process model reviews. This is discussed below.
Business Process Modelling Standards for the Enterprise
IBM Blueworks Live uses the Business Process Model and Notation 2.0 (BPMN 2.0) standard for process modelling. It also enables the use of the American Productivity and Quality Center’s (APQC) Process Classification Framework (PCF).
Process Framework
An enterprise can use the relevant APQC PCF, or they can define their own framework. The framework will define process levels and the processes that fit into each level. The enterprise should clearly define what process levels are to be used and what they describe.
Figure 2: An example of a Process Level Definition
In Blueworks Live the Process Framework is represented in two ways:
Space Hierarchy
The Space hierarchy into which process Blueprints are placed. Typically, there will be a space for each Level 1 process with subspaces for each level 2 process. Level 3 and 4 process will be present in the level 2 space. Level 5 detail is held within a Level 4 process blueprint and attached/linked documentation. Sometimes L3 processes define spaces for L4.
Figure 3: Sample Space Hierarchy
Navigation View
A Framework Navigation view. These can be built using the Discovery Map capability of Blueworks Live. The view can be used to drill down from L1 to L4 models with links to the detailed Process Blueprints. Important properties of the constituent L1-4 processes (for example KPIs) can be shown on the Blueworks Live Analyse view.
Figure 4: Sample Framework Navigation view showing L2-3
Defining Modelling Standards
By defining a set of standards for process Modelling the enterprise can create consistent models that will have at least a minimal level of accuracy and completeness.
Standards could cover:
- What information must, should, can be documented
- The use of BPMN elements – Milestones, Swimlanes, Activities, Events, Gateways and Flows
- Convention for Activity labelling – for example strict adherence to a verb/noun combination (“Create Order” or “Validate Payment”). It can be helpful to provide a list of useful (and bad) activity verbs
- Convention on Gateway labelling – for example verb(/noun) with question mark (“Validated?” Or “Order Valid?”)
- Requirements for descriptive documentation in models
- Requirements for essential meta-data fields – a MSCW model is useful. E.g.” Participant” Must be completed, “Supplier” Should be completed etc
- Diagramming conventions. For example, “Happy path start, and end events should appear in the same swimlane”
- Definition of the accepted use of Policy artefacts in BWL
- Terms to be used for tagging
Please note this list is not exhaustive. Please visit the IBM Blueworks Live Community Blog Post – A Quality Assurance Checklist for Blueworks Live for more details on this topic.
Quality Assurance
Procedures should be in place for the completion of a Quality Assurance (QA) review before a Blueprint can be published.
Some enterprises use a self-assessment mechanism for their BWL Blueprints.
A self-assessment checklist should check for:
- Completeness
- Adherence to Standards
- Correctness
Where processes are subject to regulation, QA should be performed by a third party. This could be another member of the modelling team or a team with a QA role.
The blog post mentioned above has some ideas for creating a checklist.
QA can be built into the Blueworks Live lifecycle model. It can be managed using a BWL Process Application.
Change Management
Process models will change over time. Change management should be built into the Blueprint lifecycle.
Changes can be made to a snapshot of the model. The currently published version will not be affected by any changes. Once changes have been reviewed and approved the changed snapshot can be published, replacing the existing published snapshot.
Reviews and approvals can be managed using Blueworks Live Process Applications.
Review Cycles
In regulated industries it is important to regularly review process models. Blueworks Live does not currently have an automated review capability. The following are some potential mechanisms to implement reviews in Blueworks Live.
- Add an indication of when the next review should occur to the Blueprint. This could be a custom property or a tag. Reports with this information can be created from the BWL user interface via a “Space Export”, from the “where used” icon in the BWL Glossary, or by using the BWL Artefact Reporting API (Application Programming Interface).
- Use the “Published Date” or “Last Modified Date” fields from either the “Items” tag of a Space Export or from the BWL API. This date can be used to compute the time since publication or modification. Any Blueprint over a certain “age” can be scheduled for review.
The default Blueworks Live lifecycle should be modified in order to accommodate change management and periodic reviews. An example is shown below.
Figure 5: Example of Blueworks Live artifact lifecycle with change management and periodic reviews
Conclusion
Enterprises that implement good governance for Blueworks Live get better outcomes from their Business Process Modelling initiatives. This blog post describes some good practices for BWL governance.