Our answer is BPM software technology. In explaining this answer we’ll start by defining the idea of “first-class functionality” in a given software product. Then we’ll look at the big three first-class functions in BPM software technology: work, process and, in the next section, automation artefact manufacturing.
What Is A First-Class Function Of Software Technology? Why Does This Matter?
When given functionality is a first-class citizen of a software system, that “first-classness” implies that users of a technology can use that functionality directly. And some reference to the functionality will likely show up as a feature listed on the product’s website.
The idea of “first-class” arose first in the world of software programming to describe an attribute of coded software functions. But the term is now used more generally in IT discourse to describe higher level functions as well. A good example is the first statement in the Business Rules Manifesto, by the Business Rules Group, to wit “Rules are a first-class citizen of the requirements world”.
If functionality is not first-class, then that implies that extra work is required to achieve that functionality, if it is even possible.
With this definition of first-class functionality, let’s examine BPM software technology.
Work As First-Class Function Of BPM Software Technology
Why is BPM software the technology for automating work?
Uniquely in BPM “concepts of work are first-class citizens” of BPM technology.
What does this idea mean, that “concepts of work are first-class citizens”?
In the case of BPM, business managers or business analysts or even business users can directly manipulate the concepts of work in the software. (The most important ideas of work which are first-class citizens of BPM are the concepts of “task” or “activity”, and “workflow” etc.) BPM software product users will use concepts of work through the BPM automation artefact life-cycle, especially during modeling and during actual business usage.
First-class status for work in BPM software technology is realized by support for a business process notation or language. BPMN (“Business Process Model And Notation”) is the most common process specification language, taking over from the more limiting “BPEL”. There are many other business process specification languages.
See Paper I, Section 4 for a discussion concerning how the idea of work as first-class citizen of BPM software technology is realized.
Repetition As First-Class Function Of BPM Technology
Work is not the only first-class citizen of BPM software technology; in addition to the idea of work, the concept of “repeated work pattern” is also a first-class citizen of BPM software. And the name we give to repeated work patterns is “business process”.
What does it mean for BPM software product functionality to say that “process” or “repetition” is a first-class citizen of that software?
Process first-classness means that BPM software is built with the expectation that individual artefacts will be used over and over again. And that implies modeling and tooling support for process patterns. For example, at the level of process pattern, BPM software will natively support task loops. Or at the management and monitoring level, there will be support for managing multiple concurrent process instances and for higher-level management work such as comparing instances to baselines.
BPM software product users will use concepts of work through the automation artefact life-cycle, especially during modeling and during actual business usage.
BPM And The Economics Of Repetition
But how important is support for repeated work patterns?
If we want to understand the application of BPM software to the work of organization, it’s important to understand what kind of work needs to be done, in other words, what kind of work our BPM software technology needs to support.
So what kinds of work are there to automate?
Work can be project- or process-oriented. Work can be highly standardized or structured -- or not. In each case, we might consider that different categories of software are applicable. For example, project management software may be appropriate for a large one-time, non-repeating project, but overkill for small projects.
On this basis we might conclude that BPM software may be applicable sometimes, but only for those special business cases where work is repetitive.
This conclusion would be incorrect though. Repetitive work is not a special case.
The idea that repetitive work is a special case, ignores economic pressure on organizational structure. In fact, repetitive work is and has to be the dominant pattern in any business.
Nobel Prize-winning economist Ronald Coase1 is noted for his 1937 insight that defined the tendency for organizations to evolve to a certain size. The tendency to a given size was based on the costs of organizing the business of the organization (specifically transaction costs of contracting out versus direct management). The result, which is also nicely intuitive, is that organizations tend to specialization. Specialization has always been characteristic of organization, but with global trade we can see specialization increasing more and more.
Almost by definition then, organizations are built around the idea of people working together doing the same thing over and over again. Except in the short term, repetition is necessarily part of all business models. (And even mass customization and case management still fall under the umbrella of specialized, repetitive work – it just depends on the level of analysis one is using.)
So not only are concepts of work first-class citizens of BPM software technology, but BPM software technology also includes first-class support for the most important pattern of organizational work, which is repetitive work, or process work.
Paper Road Map
There are four papers in the Series: Explore BPM Technology As Revolutionary Enabler:
- This first Paper, “Why BPM Is Unique & Important”, introduces the exciting topic of BPM software technology and why BPM so relevant to business today. Work, process and modeling are revealed as built-in to BPM software, enabling rapid construction of new business capabilities. Published in five parts.
- The second Paper, “Minimum Viable Definition Of BPM”, introduces the whole BPM ecosystem but then zeros in on the Minimum Viable Definition. Promotion and adoption of BPM software technology is facilitated when the unique value of core BPM is clear. Published in one part.
- The third Paper, “Challenges Of Being A BPM Pioneer”, highlights technical keys to success for a BPM programme. BPM software technology is not mature, and “results may vary”. However, there are ways of narrowing the “cone of outcomes” for your BPM programme.
- The fourth Paper, “Adoption Process & BPM Institutionalization”, covers how BPM software technology adoption can accelerate beyond the current technology grid-lock, a process which is less about technology and more about community.