We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

BPM: Theory to Practice

Tim Huenemann

What vs. How, Part 2

Vote 0 Votes

My last post presented the intersection of strategic planning, business architecture, and BPM, and the distinction of what the business does vs. how the business does it. It can be found at: http://www.ebizq.net/blogs/bpm_theory/2012/01/what-vs-how-part-1.php. This blog entry is #2 of a series.

The What
The previous post explained how strategic planning covers some Why (why a business wants to do something), some Where (where a business wants to go, implying a transition), and a touch of What (what a business does or wants to be able to do). It also discussed how this planning is not a good way to represent the What.
The What is addressed with business architecture. A common entry point into business architecture is capability modeling. By modeling the organization's capabilities, we create a picture of what the organization is capable of delivering.
Why do people care about the What? A comprehensive view of an organization's capabilities is useful for many purposes. Some examples:
1. Providing static documentation of what the organization does and the pieces involved ("Oh really? We do that?")
2. Finding gaps in business capabilities that need to be filled
3. Finding overlapping operations or investments that could be consolidated
4. Finding capabilities that can be outsourced or insourced
5. Analyzing the impact of a proposed change or new initiative

Capability Modeling
Capability modeling can take many forms. At a basic level, you are picking an area of the business (small scope or large scope) and documenting the capabilities of the business. A capability is something the organization can accomplish, likely for a customer, that provides a desired outcome, such as "electronic bill payment for customers" or "delivery of courier packages to residential areas." You can document current state or future state, depending on the goals and desired value of the modeling.
There are practically infinite combinations of outcomes, attributes, details, and relationships that can be part of a capability model. To explain how a capability is realized, the model can include details of/references to all the customers, staff, processes, technology, business partners, and resources involved in the capability.
Capabilities are often modeled in a hierarchy, similar to a process hierarchy.

Capability Modeling is Not...
Capability modeling documents the business capabilities, not the processes. At a high level, capabilities can appear identical to processes. But there can be multiple ways to design business processes to implement a capability. You can reference processes in a capability model, but designing and changing processes doesn't mean you are necessarily changing the capability. The more details you include in a capability model, the more the model may reflect a particular implementation (or two), but at a definitional level, a capability is definitely not a process.
Capability modeling is also not the same as functional decomposition. A common mistake is developing a capability hierarchy in a manner that actually leads to a functional decomposition along organizational/departmental lines, which strays from what capability modeling is all about. A functional decomposition can end up being a sort of hybrid of an org chart and process decomposition that isn't a good model for capabilities.

Back to the What
This just scratches the surface of capability modeling, let alone the whole topic of business architecture, but hopefully you have a taste for how to represent and analyze the What. In the next post, I will wrap things up with the How of BPM.

Leave a comment

This blog offers a true “practitioner’s perspective,” with issues and commentary based on real-world experience across many industries.

Tim Huenemann

Tim Huenemann is the senior principal for business architecture and process management at Trexin Consulting. He has more than 20 years of experience in process management and business-focused IT. In his consulting work, he helps organizations execute business strategy by implementing effective process management and IT solutions. He regularly translates BPM theory into practice, and practice, and more practice. Contact Tim at tim.huenemann[at]trexin.com.

Recently Commented On

Recent Webinars

    Monthly Archives