BPM: Theory to Practice

Tim Huenemann

What vs. How, Part 3

user-pic
Vote 0 Votes

This is the final post in a series about the distinction between what the business does and how the business does it. The previous post introduced business architecture and specifically capability modeling to describe and document what the business does. It can be found at: http://www.ebizq.net/blogs/bpm_theory/2012/02/what-vs-how-part-2.php.

The How

Finally we get to the how! Following a general (and perhaps oversimplified) philosophy, we should always figure out the what first, as we do with business architecture, and then move on to the how. After all, an organization need to decide what it should be doing, and why, before it dives into how to do it. This is where processes come into play, and the whole BPM approach.

Capability Realization with Process
Each business capability or outcome can be considered to be realized with a process implementation, perhaps even multiple implementations. For example, a customer complaint response capability can be implemented with different processes depending on geography, company division, customer type, or other factor that has engendered differing implementations.

At this point we are talking about how things happen - how the work gets done. In this sense, the process implementation can be viewed in the lens of the old standard "people, process, and technology" triangle: a process takes people and technology (and other resources...) and puts it all together to realize a capability. As you make process improvements, redesign procedures, and even implement new technology to automate processes, you are changing the how.

The Reality of Implementation and Governance
While it's always possible to model capabilities vs. processes as a documentation or analytical exercise, or as an architectural modeling effort, few organizations formally separate capability management from process management (in this case meaning the operational management and governance). When an organization analyzes and changes capabilities and processes, they are often done at the same time, with the same decision-making and planning activities, and the same projects. To put it another way, you don't have line-of-business people govern and change capabilities without also governing and changing the processes.
This is a natural condition, and logical, really. Think back to the capability realization concept. In order to change operating capabilities, you need to create new process implementations that match the new capabilities. And conversely, if you make substantial changes to processes and reengineer part of your business, this will most likely redefine the capabilities that are implemented by those processes.

What to Do
Don't try to force operational business management to become experts on capability (what) vs. process (how). For your architects and process experts, however, it is important to clearly differentiate between business architecture and process management. Find an architectural, implementation, and governance approach that works for your organization. Usually an organization will have experience with process modeling or process management, and you can slowly introduce business architecture and capability modeling as a new part of architecture that fits with the process work already in place.


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

    Blogs

    ADVERTISEMENT