Understanding, modeling and managing a business capability effectively requires a balanced view of six basic questions (following Zachman). Table 1 enumerates the six questions.
If your business does nothing but manufacture or produce physical widgets (nevermind 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.
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.
These are not strengths of many process-oriented practices.
For all the non-widget-centric business activity in the world – which includes just about all every conceivable form of white-collar work – these needs become paramount. And make no mistake, the future lies with automation that white-collar work.
What would I do to correct the shortcomings of your approach? Our answer is to become more why-centric, as opposed to narrowly how-centric. That shift has the following essential features.
Understanding business strategy as something distinct from business processes. 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
1Refer 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 EngineerTM,” Business Rules Journal, Vol. 14, No. 11 (Nov. 2013), URL: http://www.BRCommunity.com/a2013/b727.html
Speak Your Mind