Over the next couple of blogs I want to cover some business process engineering topics that I have used with great success over many years. I this blog I want to focus on an approach in identifying and selecting business processes for automation.
Business Process Identification and Selection
The success of a business process engineering project often hinges on picking the right process(es) to automate. This requires the application of a practical, quantitative analysis of process candidates which can effectively distinguish those processes best suited to automation and prioritize them for business process engineering.
The ideal starting point for business process selection is, of course, a good list of candidate processes. This is known as “business process identification” in which, ideally, candidate business processes are revealed in a strategic analysis of the business.
Strategic analysis involves various forms of business motivation documents (business plans, strategy maps, etc.) used in conjunction with functional models to identify processes at the right level of granularity and establish their strategic value.
I am going to cover both a “strategic approach” and an alternative “tactical approach” for business process candidate identification, followed by a procedure to achieve effective process selection with or without strategic inputs.
The strategic approach focuses on business process identification and selection using a variety of tools and techniques. While the tactical
approach, on the other hand, assumes the business process candidates
have been selected by some other means and need only to be justified and prioritized for business process automation projects.
Strategic Approach
The strategic analysis approach uses business motivation models and business function models in order to achieve the right level of granularity and to identify functional and process overlap and duplication. If possible I like to use an enterprises existing business function model to assist with business process identification and decomposition. If the enterprise does not have one I tend to look for function models in their industry and if that fails I fall back on APQC process classification framework which is a cross-industry model.
Across these various functional models, they all share the same hierarchical
representation, which makes them fairly widely recognizable. But they do tend to differ in the number of levels and what the levels represent. Here is an example of the levels and what they represent.
- Level 0 – This level defines the top level business functions of the enterprise, which might include topics such as: Manage IT, Manage Financial Services, and Manage Customer Service, etc. Typically very little detail is required, other than high-level descriptions for the function performed by each child node defined in this level.
- Level 1 – This level decomposes the parent high-level business functions into groups defining similar processes performed by the high-level business function. For instance, Manage Enterprise Information, Manage IT Knowledge, and Develop and Maintain IT Solutions are all examples of children of the Manage IT from Level 0. Again, descriptive information defining the family of processes should be sufficient at this level for detailing nodes.
- Level 2 – This level defines individual core business processes within the parent business process group. It includes defining the roles and high-level functions performed by the process. Understand that it is not always necessary to have more than one child for each parent. At this level, the introduction of high-level use cases can be introduced to begin detailing the processes identified in this level. Otherwise, if a business process modeling approach will be used, then high-level business process models (or process maps) can be established at this level.
- Level 3 – This level breaks down a business process into corresponding Business Activities. Business Activities are the activities performed as part of a business process that may yet be broken down across several tasks. (Think transaction, rather than method here, where the transaction may be executed, as a unit, over several actors). Again, use case analysis is a great way to represent nodes in this level when taking a purely functional approach.
- Level 4 – This level breaks down Business Activities, into finer grained Business Tasks. Tasks are typically performed by a single actor (system or human), but may involve many steps. Again, use cases are a valid way to represent nodes of this level, although, at this level, they are more likely to also involve other descriptive documents and diagrams to supplement them.
- Level 5 – This level breaks down a business task, into finer grained steps. This is the lowest level of detail necessary for functional modeling. Typically detailed requirements are all that is necessary at the step level.
The strategic approach focuses only on the functional hierarchy from level 0 to level 2 (based on the example definitions above) The architect can use the descriptions above to align function and process descriptions and, if necessary, decompose to the next level until a set of core business processes has been identified. So for example – Once the Business Function(s) have been selected, the next step is to narrow down the focus to the Process Group(s), which have been categorized as a Level 1.
Once the Business Process Group(s) have been identified the next step is to decompose these into Core Business Process(es).
Functional decomposition is a technique for developing an understanding of business processes and their level of granularity in an enterprise. The focus for business process selection should be Core Business Processes (level 2), for example “Expense Reimbursement” is a core business process in the example above.
It is important to note that this is NOT an organizational chart. Simply mapping the activities that people perform in their organizational roles will not lead to an effective functional model since many functions and processes have variations occurring in other parts of the organization. This approach requires a top-down decomposition without regard for organizational boundaries in order to get a clear picture of the core processes that span the enterprise.
A true business process model (as opposed to technical orchestration) can now be recognized as representing a Core Business Process. These business process models, also known as process maps at this level, identify the primary Business Activities at the highest level of the business process flow. Further business and technical analysis, in later phases of the engineering process, continue this decomposition into the lower levels of the functional model.
Tactical Approach
In the absence of strategic business inputs, such as top-level functional models and business motivation, it is still possible to document process selection criteria and to evaluate candidates without the assessment of Value Alignment.
A tactical approach is often taken when getting started with BPM to raise visibility and to gain senior management commitment for future project work. In the early stages of a BPM program it is fairly straightforward to identify core business processes and “low-hanging fruit” for process improvement. In such cases we focus on existing processes that are causing the organization the most pain, e.g. high cost, inefficient, taking too long to complete, inconsistent, low satisfaction, etc.
Business processes identified in this way can now proceed as process candidates to be used in the next step of process selection.
Process Selection
A Business Process Selection Framework can be used to select which potential business process should be realized through automation. This framework should have a scoring mechanism to evaluate business process candidates. Candidate process scoring is not used to decide if new process or functionality should be created, rather it is simply used to decide if the business process should be realized as an automated process. If a process candidate fails selection for automation it does not reflect on the value of the business process, instead it merely indicates that the business process is not an appropriate candidate for employing BPM technologies. Now that a number of processes have been identified they can be prioritize based on a scoring mechanism.
A Business Process Selection Framework is used to evaluate the business value alignment (in the case of strategic analysis) along with various other benefits expected from automation. Inhibitors to automation are also considered and in some cases a process may be determined unsuitable: for example if a process is too complex (high risk), or is well optimized and doesn’t change, there may be no value in automating it. The following table describes some example benefit criteria that can be used for evaluation of business process candidates.
| Benefit Criteria | Description |
| Value Alignment | Weighs the alignment of the business process to the enterprise’s business and BPM goals |
| Process Category | Weighs the process based on how the process contributes to the business. Evaluation of this score tends to be focused on whether the process is a core, strategic, or supporting process |
| Executive Interest | Weighs executive interest and support |
| BPM Project | Weighs to what extent a project has been identified, justified, and scheduled for development |
| Business Impact | Weighs the impact automating the process would have on the bottom line of the business by either reducing costs or increasing revenue |
| Improvement Opportunity | Weighs the opportunity for improving the process once the process is managed and monitored |
| Response to Change | Weighs the likelihood that the process will require modifications to meet changing business needs |
The following table describes some example inhibitor criteria that can be used for evaluation of business process candidates.
| Inhibitor Criteria | Description |
| Lack of Structure | Weighs the lack of structure in the process. Sample categories are for evaluation of this score are ad-hoc, unstructured, structured |
| Complexity | Weighs the scope and complexity of the process. The process should be small enough in scope and simple enough in complexity to be appropriate for this effort |
| Organization | Weighs the extent of reorganization and/or changed organizational policies required for this process. The authority to make these changes must be taken into consideration |
| Resources Involved | Weighs to what extent are resources such as employees involved in the process |
| Integration Complexity | Weighs the complexity of integrating the applications necessary to support the process |
| Knowledge Gap | Weighs the availability of knowledge about this process. Example categories could be little, gaps, general, extensive. |
The framework should generate a numeric score (Decision Basis Score) that can be used to select and prioritize business processes for automation.
This example collection of benefits and inhibitors should be weighted
according to their importance in any given enterprise’s situation. More parameters can be added or removed as need and weightings can be adapted to suite any specific enterprise’s needs.
OK, that is it for this blog in my next blog I will cover business process design.
Good Luck, Now Go Architect Model that Process
An Enterprise Architect's Musings 