BPM often overreaches. Understanding, modeling and managing a business capability effectively requires a balanced view of six basic questions, not just one, as given in the table below. I follow Zachman in these matters, so yes, the table is Zachmanesque.
Basic Business Question
Kind of Model
What inventory of things needs to be managed to support business activity?
structural model (e.g., concept model, data model)
How do transforms of things in business activity need to take place to add value?
Where does business activity occur?
Who collaborates with whom to undertake business activity?
interaction model (e.g., organizational chart, use case)
When does business activity take place?
temporal model (e.g., schedule, event model, milestone model)
Why are results of business activity deemed appropriate or not?
strategy model (e.g., Policy Charter, constraint model)
If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others. Your overall approach and architecture will reflect that. You will naturally gravitate toward BPM.
That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:
Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks. E-suite executives tend to be much more focused on the latter.
Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them. As a result your process models will be unnecessarily complex and your overall solutions un-agile.
You approach will fall woefully short in addressing the intellectual capital that underlies your processes. Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.
Fewer and fewer business problems these days fall into nothing-but-widgets category. Even for widget-centric businesses, at least three needs are increasingly urgent:
Ensuring the quality of meta-data.
Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
Retaining, teaching and repurposing intellectual capital.
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”
I agree with the premise that it’s important to take a balanced view of the above 6 facets.
Also a BPM perspective tends to be operational rather than strategic. So, in addition to the 3 important things listed, there’s a need to take an external, outside-in perspective – for whom is the capability required, how does it fit into their world, and what are the competition doing?
This is not to say that BPM is not a valuable practice in the right context, merely that it’s only part of the picture.
Ronald G. Ross
Agree 100% on all.
BPM and the Knowledge Economy: White-Collar Work — Ron Ross on Business Rules
[…] BPM and the Knowledge Economy: Nothing But Widgets? http://www.brsolutions.com/2015/11/16/bpm-and-the-knowledge-economy-nothing-but-widgets/ […]