BPM often simply overreaches.  Understanding, modeling, and managing a business effectively requires a balanced view of six basic questions, not just one, as given in Table 1.  I follow Zachman in these matters so, yes, the table is Zachmanesque.

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.  C-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.


• Your 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 the nothing-but-widgets category.  Even for widget-centric businesses, at least three needs are increasingly urgent:

1. Ensuring the quality of meta-data.


2. Demonstrating compliance-based actual rules, rather than the artifacts and effects that IT systems produce.


3. Retaining, teaching, and repurposing intellectual capital.

These are not strengths of common BPM practices.

For all the non-widget-centric business activity in the world — which includes just about every conceivable form of white-collar work — these needs become paramount.  And make no mistake, the future lies with automation of that white-collar work.

What would I do to correct the shortcomings of BPM?  Our answer is to become more why-centric, as opposed to narrowly how-centric.  That shift has several essential features:

• Understanding business strategy as something distinct from business processes (and BPM).  Business goals and business risks should be drivers of business process design — not the other way around.  You need to be strategy-driven, not simply process-driven.


• Designing core metrics around business goals and business risks — the things that concern C-suite executives the most.


• Realizing that for white-collar work the 3-D world of widgets has vanished, and that tolerances and quality can be expressed only in terms of business rules.


• Treating business rules as a first-class citizen, externalized from process models.^[3]


• Identifying operational business decisions (based on encoded business rules) as a crucial focal point in re-engineering business processes.


• Including a Why Button as part of every business solution.^[4]  Pressing the Why Button leads immediately to the business rules that produced the results you see from any process.

For further information, please visit BRSolutions.com      

References

[1]  Refer to Refer to Business Rule Concepts:   Getting to the Point of Knowledge (4th ed), by Ronald G. Ross, 2013, Chapter 1 and Part 2.   http://www.brsolutions.com/b_concepts.php  

[2]  Refer to Building Business Solutions:   Business Analysis with Business Rules by Ronald G. Ross and Gladys S.W. Lam, 2nd ed. (Sept, 2015), an IIBA Sponsored Handbook, Chapter 4.   http://www.brsolutions.com/b_building_business_solutions.php  

[3]  Refer to the Business Rules Manifesto, now in almost 20 languages: http://www.businessrulesgroup.org/brmanifesto.htm  

[4]  Refer to Ronald G. Ross, "The Why Engineer™," Business Rules Journal, Vol. 14, No. 11 (Nov. 2013), URL:  http://www.BRCommunity.com/a2013/b727.html  

# # #