top of page
Search
Andy Higgins

BPM: Prescriptive or Descriptive?


Is Business Process Modelling prescriptive or descriptive? I vote "prescriptive." But let's take a minute to define the terms.

Prescriptive is the normative "should." The processes MUST run this way, and exceptions are "failures" for which other, error-handling processes are invoked.

Descriptive is less constraining. Yes, the processes should run this way, but we recognize they don't always, and that's ok.

Architectural standards are generally silent on this question. But there are many fallouts if a prescriptive approach to modelling is not used.

  • There is noise in the metrics

Measures are important for transformational targets as well as continuous improvement. If your process design is only descriptive, there's no way to count on the measures that are taken for how the "processes" are performing. Take a simple measure of sales-by-channel per period of time. If the call center can also place an order for a customer who's having trouble with your web site, is that sale credited to the web channel, or to the customer call center channel?

  • Controls (financial, regulatory, health and safety, academic or programmer peer review...) may be by-passed

When processes are prescriptive then trip wires and fail-safes can be built in. These controls force segregation of duties, for instance, in financial entries, or lock-out / tag-out processes for maintenance in a production environment, or permitting activities for confined space entry or waste discharge. Limiting process execution, making processes un-executable without their corresponding controls, is a powerful mechanism that is lost in the descriptive view.

  • Requirements elicitation and definition is greatly magnified and expanded

A picture is worth a thousand words. (So why am I blogging?) If you simply make your pictures dispositive - they disposition any question of how things ought to be - you eliminate a ton of redundant work in eliciting and articulating requirements. Not that classic requirements management disciplines can be thrown out when undertaking a major government acquisition, but one of the major differences in package implementations I've seen in the DoD vs commercial industry is the over-reliance on RM instead of prescriptive process models. I have successfully implemented a half-dozen commercial packages without ever using requirements management (save for the exception cases around the edges, the RICE objects that needed programming). It's not only possible, but even desirable, to state your requirements in the form of prescriptive, dispositive process models that don't need further debate on the specific, detailed words in "Shall..." statements and so-called "SMART" requirements.

  • Business rule elicitation and definition is required without prescriptive models

Same / same as with requirements elicitation, business rules can be stated or depicted. You may have policy guidance - internal agency policy, or externally-imposed regulations - from which B/Rs are directly derived. In such cases the process models can link directly to the relevant LRPs (laws, regulations, policies). There's no need to restate them in B/R documentation. And documenting B/Rs that describe the WHEN conditions that arise after activities are executed is just redundant. If there are two flows out of a process activity (or a flow to a decision diamond, which then has two possible outcomes), then the diagram is simply and affirmatively interpreted as "saying" that "when this occurs do x, when that occurs do y, and there's nothing else that can occur." Why re-state the same thing in a business rule?

  • Quality measures and controls are abandoned

Performance metrics as transformational and continuous improvement targets were noted above, but in a steady-state operation there is also the key element of alerts and alarms when trends emerge. SPC / SQC disciplines provide these mechanisms. In a manufacturing environment it's understood that you do "processes" in a certain, fixed, mandatory way (recipes in chemical manufacturing, assemblies in discrete manufacturing, etc.) Why isn't it the same for business processes? Knowing that you're not paying invoices on time, that there's a trend downward in discounts taken (or a trend upward in discounts not taken) is a valuable insight into the operation of the A/P process. You need to specify the process model as prescriptive in order for accounting personnel to be held accountable for taking discounts.

  • Encoding the business processes - COTS configuration, iBPMS setups, workflows - is not immediately enabled

This is the flip side of the Requirements Management argument. With only considering the flows as descriptive you lose the ability to make configuration settings in software to directly support the processes. Among many failures in that program, for the USAF's $1B Expeditionary Combat System fiasco, the contactor's plan for configuring the software relied on the statements of requirements. The plan for testing relied on the process definitions. There was a severe mismatch when the requirements were clearly fulfilled but the "processes" just couldn't support the business!

  • Automated management and process optimization - the power of BPM tools - is not enabled

Beyond the COTS configuration, BPM tools have matured to the point where they monitor and manage process execution. Dynamic case management can intelligently re-route customer inquiries or problems as workload and capacity become available, or as exceptional circumstances arise. But even though these tools often offer Business Rule Engines (see above) in addition to process flow modelling tools, and BRs are encoded for triggering and executing process steps, they still rely on the underlying definition of processes that are optimized. If there's descriptive "float" in the process execution, optimization is neither possible nor desirable, since attempts at optimizing are just as likely to lead to thrashing and sub-optimization.

When combined with the other IT disciplines for COTS implementation and automated business process management, and/or when combined with the need to enforce controls in the operation of the business, the payoff for a prescriptive view is fairly self-evident. Don't get caught in the architecture trap of documentation for its own sake. Make your BPR and your architecture prescriptive, and get your money's worth out of it.

56 views0 comments

Recent Posts

See All

Mr. Cooper, She Hurt Us All

The following opinion piece appeared in the Washington Post today; highlights are mine: Opinion by Christian Cooper July 14, 2020 at 1:09...

bottom of page