This document intends to give a brief overview of Business Process Management (BPM) and Business Process Management Suite (BPMS). This document is more geared towards the Business Analyst (BA) roles and responsibilities within a BPMS implementation. This document will help the BAs in understanding basic concepts and will help them in a typical BPMS implementation.
1.1 What is BPM
Business Process Management is a series of steps (activities/procedures), taken by an organization in order to achieve its goals, involving one or more actors (human or system), guided by a set of rules (business policies), resulting in a predictable outcome.
BPM is also a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization’s activities and processes. (Gartner 2005)
A business process is a set of linked activities that create value by transforming an input into a more valuable output. Both input and output can be artifacts and/or information and the transformation can be performed by human actors, machines, or both.
A business process can be decomposed into several sub-processes, which have their own attributes, but also contribute to achieving the goal of the super-process. The analysis of business processes typically includes the mapping of processes and sub-processes down to activity level.
Activities are parts of the business process that do not include any decision making and thus are not worth decomposing (although decomposition would be possible), such as “Answer the phone”, and “produce an invoice”. Business process modeling is used to capture, document and reengineer business processes.\
A business process:
1. Has a Goal
2. Has specific inputs
3. Has specific outputs
4. Uses resources
5. Has a number of activities that are performed in some order
6. May affect more than one organizational unit. Horizontal organizational impact
7. Creates value of some kind for the customer. The customer may be internal or external.
1.2 What is BPMS
Many vendors have created application suites which enable organizations to better manage their business processes. These technologies typically involve tools to visually design and model business processes; simulate and test business processes; automate, control and measure business processes; and provide feedback and reporting on process performance. Some vendors have combined these functions into business process management suites that provide a complete integrated BPM platform, commonly referred to as a BPMS.
Many organizations have a large number of legacy systems. In order to manage the end-to-end work involved in business processes, a BPMS must be able to integrate with legacy systems across the organization in order to control work, get information or measure performance. A variety of new technologies have emerged to simplify integration efforts and the technology industry appears to be standardizing on a specific set of open technologies, commonly referred to as Web Services. A common framework for how these technologies are deployed is also being adopted, most often referred to as a Service Oriented Architecture (SOA). By leveraging web services in a service oriented architecture construct, organizations can build and manage end-to-end business processes across organizational silos and their legacy systems. Many modern BPM technology solutions include the capability to interface to legacy systems through these standard interfaces, providing the tools to automate and orchestrate work across the entire organization.
1.2.1 BPMS Capability Summary
; Provides mechanisms to
o Create visibility into business processes
o Enable continuous optimization
o Prioritize, based on a data-driven approach, optimization opportunities
o Persist the outcomes of Six Sigma Control
; Provides visibility to:
o Process Simulation and Execution
o Key Performance Metrics of the process e.g.
o Financial throughput, Worker Productivity, Process SLA
o Current state/status of a work item
o Queues and Audit Trails
o Process SLA
o Workers of the queue (s) and their workload
; Capability to route work
o Automatic / Dynamic
o To roles within a queue (e.g. team lead vs. member, new home loan specialist vs. 2nd mortgage specialist)
o Based upon reporting relationships (manager, manager’s manager etc.)
o Based upon a time lapse (e.g. 1 week after completion of previous task)
> Capabilities for managers to manage workload
o View work items in Queues
o Ability to route (for load balancing and out of office scenarios) , reassign, collaborate, or suspend work items
o Ability to change priority or due date
1.3 When to use BPMS
Below are mentioned some of scenarios in which it is recommended to go in for a BPMS implementation
> Process Automation Requirements (Workflow)
o Workflow involving a combination of human-to-human, human-to-system, or system-to-system tasks
o Human interaction involves roles and hierarchies
o Work routing is controlled by business rules and/or by process managers
o Work execution needs human and systems integration/interaction
o Process spans roles, organizations, and systems
> Process Management Requirements
o Ability to get process visibility (e.g. where is loan number 123 stuck? Or who is the bottleneck?)
o Ability to manage workload and staff utilization
o Ability to manage tasks and priorities to meet SLA’s
o Ability to react to operational issues e.g. fraud detection
o Ability to deploy multiple versions to meet requirements (regulatory)
; Process Optimization Requirements
o Ability to analyze process performance and identify opportunities
o Historical vs. Simulated (did I do as I thought I would?)
o Historical vs. Historical (Are there any anomalies/trends?)
o Ability to ‘model’ process changes and assess impacts
o Historical vs. v2 Simulation (What-if scenarios)
o What if Analysis (What needs to change to ensure customer SLAs during the up-coming loan sale?)
; Process Modeling ; Analysis Requirements
o Ability to build a process picture
o Ability to capture cost and time metrics in the process
o Ability to simulate multiple scenarios and understand cost ; time impacts
1.4.1 Process Life Cycle
Similar to a software project implementation, every process implementation also has a life cycle. This could be termed as Process Life Cycle or the phases involved in implementing a process.
The following figure shows the various phases involved within a process implementation
Below are mentioned some high level activities performed in the phases
Define and Discover
; Define business problem/goals
; Document current state (measure current performance)
; Analyze current state and look for opportunities
Model and Simulate
; Model current process model
; Identify process management metrics
; Evaluate baseline performance
; Model alternative scenarios and analyze against metrics
; Refine opportunity set
Deploy, Execute and Monitor
; Execute future state
; Measure process and business metrics
; Manage thresholds and exceptions
; Adjust operations to meet objectives/SLAs
Optimize and Analyze
; Analyze historical data for patterns
; Review against previous assumptions
; Build ‘what-if’ scenarios
; Refine metrics/SLAs
; Refine operations/processes
1.4.2 Roles within a BPMS implementation
A typical BPMS implementation involves many people and varied roles. Some of the roles and their typical activities are outlined below
1. Process Modeler (Business Analyst) – Typical responsibilities include
a. Gather and document requirements
b. Process modeling
c. Process simulation and optimization
d. User interface requirements and design
e. Test case preparation
2. BPMS Architect
a. Business Process Design
b. Interface design
c. Review business model
d. Facilitate code review from BPM CTA team
3. BPMS Developer
a. Design and develop BPMS code
b. Design and develop external system interfaces
c. Unit testing
d. Support Integration Testing
e. Support transition
4. Application Developer
a. Develop non BPMS components of the process implementation (if any)
b. Unit test developed components
a. Design and Develop test plans and test scripts
b. System and Integration testing
6. BPM CoE (Center of Excellence) team (if applicable)
a. Provide technical assistance (if needed) to the development team
b. Conduct Design and Code reviews
c. Provide BPM platform support
d. Code migration and implementation
7. Process Analyst
a. Process monitoring and analysis
b. Conduct periodic meeting on process performance with sub process owner and process owners
c. Train users
d. Suggest process improvements
8. Process Owner
2.1.1 Business Process Definition
Business Process Definition (BPD) is the term for process model within Teamworks. Modeling a process in TeamWorks Authoring Environment is creating a Business Process Definition (BPD). When a process is executed at run time, the TeamWorks engine runs an instance of the BPD. A BPD is a reusable model of a business process, defining what is common to all run-time instances of the Process definition.
Following are some of the things that make up the BPD
; Pools and Lanes – According to the BPMN specifications, a Pool typically represents an organization. Pools contain Lanes, which typically represent departments within that organization. Lanes are containers for the activities and events that take place during run time. By placing Activities in lanes one specifies who does what.
; Activities – An Activity represents a logical unit of work that can be executed at run time by a human or a system.
; Sequence line or flow – Sequence Lines are used to manage the sequence of activities and events that take place at run time. Sequence lines can also hold conditions that determine rules for how a process proceeds when it reaches a Switch, Split, or Join.
; Gateways – TeamWorks Gateways include Simple and Conditional Splits and Joins, and Decisions. Gateways control the divergence and convergence of Sequence Lines, determining branching, forking, merging, and joining of the paths that a run-time process can take.
; Tracking – Tracking Events are used to indicate a point in a process at which we need to track the run-time data for reporting purposes.
Some best practices around developing a BPD
; Process flow – The process flow should always be top to bottom and left to right. Sequence lines should not cross each other as much as possible.
; Readability – Ensure that the process model has good readability. Some tips and tricks include
o Use multiple end events; this will help in reducing crossing over of sequence lines.
o Use multiple system lanes; this will help in better readability
o If the process is complex and has many activities try combining activities into sub processes.
; Documentation – Appropriate documentation is required for all processes and activities. It is advisable to leverage organization specified templates for such documentation.
; Process Documentation within TeamWorks – TeamWorks provides for documentation fields for processes and various components of the process.
a. Define and identify Process Key Performance Indicators (KPIs)
b. Responsible for the process (Business Owner)
c. Communicate with stakeholders
d. Liaison between IT and business
e. Promotes success of the business process automation
f. Suggest process improvements
9. Sub Process Owner
a. Defines and identifies sub process Key Performance Indicators (KPIs)
b. Responsible for the sub process SLAs
c. Communicates any changes up to the process owner for review and implementation
10. Process users
a. User Acceptance Testing
b. Participate in process
c. Provide feedback on process improvements
It could be quite possible in some implementations, roles overlap and a single individual could perform multiple roles.
2 BPMS implementation tasks
2.1 Process Modeling
Process modeling is a huge concept in itself. However this section will provide a short synopsis of the same in short in perspective of this document. We would like to define Process Modeling as the exercise that will result in a business process definition that needs to be implemented. This section will outline the various aspects that one needs to keep in perspective to design the final process model.