Business process governance is a catalyst for continuous process improvement and the collaboration between business and IT on corporate goals. Business process governance is essential to ensuring strong business and IT alignment by creating a framework that ensures the use of standard methods and tools to  drive consistent and scalable delivery.

Business process governance contributes to corporate governance. Corporate governance is a framework for determining corporate direction and performance, how the corporation uses its resources, and what accountability exists for the stewardship of those resources.

Business process governance is a framework that ensures that the corporation’s direction is realized at an operating level and is reflected through operating  performance. The BPM layer interacts with IT, business, and SOA layers, and it requires a governance framework that accounts for those interactions. Given the complexity of these interactions, business process governance is an evolutionary process.

IT governance is a framework for establishing mechanisms and policies to  ensure that the corporation’s direction is supported and sustained by technology.

SOA governance is a specialization of IT governance that places key decisions  within the context of the lifecycle of service components and services.

What constitutes a business process governance model? A business process governance model:

• Determines a joint vision
• Establishes policies, guidelines, standards, and frameworks
• Promotes enterprise-level  performance  metrics
• Specifies chains of responsibility, authority, and communication to empower  people
• Establishes measurement, policy, and control mechanisms to empower people to carry out their roles and responsibilities
•  Puts in place organizational structures for governing the lifecycle of processes
•  Establishes procedures for using and sharing process knowledge to reduce  process efforts
• Specifies BPM funding models
• Governs and measures the business value of processes
• Establishes a clear communication channel to enhance collaboration  between business and IT

The first critical step toward a process decomposition framework is building out a common taxonomy for BPM projects.

Multiple, parallel BPM efforts can create confusion and duplication of effort in the absence of a common business process taxonomy or vocabulary. A  project or program requires awareness of the need to define the common taxonomy for efforts (for example, what defines a customer? Is it a client, a  prospect, or any involved party?) and follows the conventions and rules accordingly. In mature industries, there are likely to be associations that already  perform these functions (either as their mission or in a de-facto manner), so they  are the best places to start, as they save time and reduce arguments within an  organization. However, the beginning taxonomy should not be static. Like BPM  projects, taxonomy and the meaning of certain terms should evolve as the organization’s BPM maturity evolves.

Establish a predefined process hierarchy and decomposition. Development time  lines, and how well process requirements are fulfilled, are impacted by the level  of detail to which processes are defined, captured, and for which BPM solutions  are designed and developed (for example, level 2 versus level 6). It is essential  to predefine a process hierarchy and the decomposition levels that are the  framework and reference structure for the BPM projects and program.

A solid starting point for this hierarchy is APQC’s various process decomposition  frameworks built by industry. Many industry associations might provide good starting places as well. Also, like the common taxonomy, there is abundant room to evolve the process hierarchy and decomposition as the organization evolves  in its BPM maturity.

Be careful not to equate an IT-focused capability map, component business model, or value net with a process hierarchy. Equating these items adversely impacts the BPM project in the following ways:

• It gives the participants the impression that the BPM effort is another IT project for new IT tools.
• It sets back the business or process architecture component of the BPM journey, as over several months project participants realize that after processes are defined, you need to string together many elements of a value  net to deliver any process. Processes do not equal capabilities, and they need to be organized appropriately to deliver enterprise value.

Deploy a rigorous model management approach. The process-centric approach to BPM projects requires model management discipline for the maintenance, versioning, and collaboration of process models across the enterprise. It is best  to realize and plan for this contingency at the beginning of the BPM journey, and  anticipate the need going forward. These practices tie in tightly with the process  hierarchy and decomposition, as it becomes the index for organizing the models that need the maintenance, versioning, and collaboration management guidelines this step delivers.

Process ownership is a crucial factor in successful BPM solution deployment, adoption, and sustainability. A process-based ownership model is process-oriented (meaning that it is focused on all steps from a customer’s request to fulfilling that request) and this model works cross line of business (LOB). A process-based ownership model:

• Solves customer and enterprise pain points across business processes and  aligns with strategic goals.
• Manages the process through process ownership within an organization and horizontal alignment.
• Creates accountability and empowerment to enable process performance and results.
• Creates reusable enterprise-level processes.
• White space is minimized as functions are aligned to support specific  processes.
• Over time, the business becomes governed and measured by the process.

Through the process-based ownership model, you achieve visibility into the process contribution to the enterprise strategy, and you achieve the goals at an  executive level. This executive visibility ensures that the end-to-end processes  perform well. Clearly established ownership allows resolution of conflicting goals  among processes through governed collaboration across departments.

The common pitfalls are those actions and compromises that organizations  often make that reduce the authority and accountability of the process owner. Strong process ownership is crucial. The process owner can never be a temporary one. For the same reason, assigning a technical leader or a junior  leader to the role instead of business representative is inviting additional risk  into your BPM journey.

IBM advocates a rapid prototyping (agile) methodology for BPM development efforts. In doing so, how an organization attacks its projects and programs often  becomes more important than what it attacks, because the overall goal is to  focus on value. In doing so, the technique of time boxing  the efforts to focus on  value delivered over short time bursts is critical. This situation also builds  up a transformation cadence that many organizations lack when they attempt to  transform their processes, their development techniques, their delivery models,  and even their business models. This cadence, tied into the strategic plan and roadmap, and executive sponsorship and the focus on value (not technology solutions), is critical to the BPM transformation journey, the success of the projects, and the return on the BPM investment.

The BPM Center of Excellence establishes standard performance metrics as a  baseline for all BPM-approved projects to ensure that projects are tracked throughout their lifecycle against the proposed business case. The metrics are integrated into a common reporting process.

Continuous monitoring of the projects throughout their lifecycle is important. It ensures that the BPM projects  deliver the expected business value.