“What's in a name? That which we call a rose
By any other name would smell as sweet.”
William Shakespeare, Romeo and Juliet, Act II, Scene I
What's in a name? Not so much? What is important is what we mean and understand by the thing that is named. Shared understanding is everything; without understanding, there is no effective communication. If we begin with unknown differences in the way we visualize and name basic concepts, there is no way we can converge on common understandings and develop sophisticated models of how the world works. Without understanding, we can't even have rational conversations about our different views.
While the nature of an object is more important than what we call it, language can be a powerful force for understanding, as well as for misunderstanding. When it comes to gaining a shared understanding in BPM and related areas, we are too often 'separated by a common language'.
In the general discourse around business processes and their modeling, management, and improvement, we have a problem with language. When we start conversations about business process theory and practice with fundamental differences in the conceptualization of the idea of 'process', it's not going to end well.
The problem is that we can have very different ideas about what a process is, and these differences can exist in every language. It's much more fundamental than whether we say inkqubo, فرآيند, processus, quy trình, proceso, proces, inshila, próiseas, اجراء عمل, prozess, mchakato, prosess, processo, inqubo, prosessi, प्रक्रिया, or process.
The process problem
I hear processes called all sorts of things: business process, capability, process area, value chain, process group, business service, component, value stream, machine, service, responsibility, procedure—and there are, no doubt, many more. Now, I can hear lots of readers saying “No! Such-and-such is not a process.” But that's the problem; we all think we are correct, and anyone who disagrees with us is misguided. Don't you agree!?
In some cases, it's not as hard-edged as that, and the various terms are suggested as being 'sort of the same'. That doesn't help. If a component or capability or machine is much the same as a process, then why do we need more than one term? Choose whichever term you prefer, but let's document an architecture, not a thesaurus.
Differences in the definition of basic concepts in and around BPM are not just of pedantic or pedagogic interest. They cause a lot of wasted time and create confusion, which handicaps development. To illustrate this point, there have been several long discussions about 'process' vs. 'capabilities' in various LinkedIn discussion groups. One that I followed for a while continued for over 12 months and, last time I looked, had gone through the 300 comments mark—and it's mainly people talking at cross purposes because of different definitions of the fundamentals. A new LinkedIn discussion about the meaning of 'value chain' is showing all the signs of another long and circular run.
Does it help to call 'processes' at the different levels of a hierarchy by different names? Does a process that is reused throughout an organization need to be called something other than a process? Adjectives are useful. Couldn't it be a level 1 process and a common process? Do we solve the problem of not knowing what a process is by inventing an additional name we don't understand?
It's often more than just having different names for processes; we start from different fundamental assumptions about what the term should describe. Starting from different perceptions, we inevitably end up in different places, and we waste a lot of time arguing about the relative benefits of unreal differences.
Where it all begins
Having thought about this for a long time, and participated enthusiastically in many of the pointless arguments caused by an unnoticed lack of agreement at the most basic level, I have finally discovered that the reason for the dissonance is quite simple—perhaps embarrassingly so.
You might think of a process as a set of related activities, with definite triggers and results, which transforms inputs into outputs. Essentially, this is visualized as a set of boxes and arrows in a process model. I call this the minimalist view.
Alternatively, you might think of a process as everything described above, plus all that is needed to execute and manage the process—that is, all of the resources, systems and people. I call this the holistic view.
When you start with the minimalist view, you fairly soon decide that there is something missing, namely all of the resources, systems, and people required to execute and manage the process—that is, all the additional elements included in the holistic view. If a process is just a series of activities, you need to find something else that will do the rest of what is required. Hence, we create new concepts like capabilities, components, machines, etc. When you start with the holistic view, there is nothing missing.
When some folks start with the holistic view and some with the minimalist view, it's not surprising we have disagreements. I'm not saying either is definitively correct; the world could operate with either. However, the problem is we are trying to operate with both, and without being conscious that we are doing so.
Modeling the problem?
Might it be that the problem is, I won't say caused, but exacerbated by having a heavy emphasis on process modeling, particularly modeling of an uncomplicated nature that focuses on just capturing activity sequences? Our view of what comprises a process might easily be shaped, or at least influenced, by the visualizations of them with which we are familiar. 'Process' might naturally be conflated with 'process model'. If you start by seeing processes represented only as boxes and arrows that is likely to nurture the minimalist view where you perceive a process as a type of documentation. If your experience is that processes are represented by a modeling database rich in information about activities, people, systems, data, performance, and other interrelationships, it will be hard to take anything other than the holistic view, and the idea of 'process' becomes much more than documentation—it becomes a proactive management tool.
A corollary of this would be that your position on the holistic-minimalist scale might be influenced by the modeling tools you use. Although it doesn't have to be like this, a modeling tool that is essentially a drawing package is likely to be used to draw minimalist process representations, and a more sophisticated repository-based tool lends itself to a more complex view of a process. Of course, we can't blame the tool. At most, this can be just one element of what forms our personal 'process view'.
Our exposure to visualizations of process must have a strong effect on our perceptions of process. While it can't be the whole story—and there is nothing inevitable about the various experience pathways—modeling processes must inevitably influence the modeling of our process view.
Does this matter?
So, does all this matter? Is there a problem, an impact that should worry us? Yes, I think there is.
It's not the issue of which word you use to describe a 'process'. While I find 'process' a perfectly good word that does not need to be reinvented or supported by other nouns, there should not be a problem in using other words (assuming shared understanding and consistent use) except in communicating with people, perhaps outside your organization, who use a different language. I recently worked in an organization where 'holistic processes' are called 'machines', and I came to find that term quite compelling in that environment.
If you want to test the extent of the problem and its possible impacts, listen to the conversations around you about 'process' and note the various terms used. Then ask a selection of colleagues to write down their personal understanding of what each of those terms mean. Test those written responses against what you hear people say, and get the respondents together to discuss the differences.
The problem is that poor definition of terms, inconsistent usage, unnecessary complexity, and general fuzziness about the nature of a business process, leads to pointless arguments, confusion, and the significant opportunity cost of not working to a shared 'theory of process' that is integrated, coherent, scalable, and fractal.
I think the holistic definition of a process is the most effective approach. It simplifies the process view and removes the need for the additional complexity to compensate for the minimalist perspective. It allows for a much richer discussion about how organizations create, accumulate, and deliver value to their customers and other stakeholders.
What can we do?
While it would be good to imagine that throughout the 'world of process' we might come to some common agreement about the nature of a process, that's not going to happen. The practical target we can set is that in each organization we take steps to be as clear as possible in the language used—not just in what we say, but also in how we think about processes.
The general strategy must be to use clean language with a minimum vocabulary that is understood and utilized by all. Here are five ProcessTalk practices that can achieve those objectives.
- Clean it up. The language of process must be well defined with clear meanings for each word in the vocabulary without fuzzy edges and unresolved overlaps. Seek out and remove any confusion in the way process issues are discussed.
- Keep it short. The process vocabulary should be as brief as possible and as long as it needs to be. Synonyms, real or imagined, are not required. A single term like process (or widget, or whatever you prefer) can, with appropriate adjectives, be used to describe every hierarchical level and every variation.
- Write it down. Document the process vocabulary; create the glossary of terms, and describe in as much detail as is useful about how each term is used.
- Share it. Actively ensure that everyone understands the language of process. Make it available, explain it, talk about it—bring it to life so that it will be used.
- Speak up. Insist that the correct language is used and, when it isn't, speak up and ask for clarification. Create the habit of using the right language in the correct context.
Business process management (or, better, process-based management) is a management philosophy that requires us to think differently about organizations and how they operate. The cross-functional, or end-to-end, approach is very different for most organizations, their teams, and people.
Clean language used consistently won't solve every problem in that transformation, but it removes the distractions of unnecessary confusion, improves clarity in thinking and reasoning, and makes it easier to explain the important concepts.
Postscript
I asked a French colleague, Clement Hurpin, to review this article and I thank him for his insights. As an aside, Clement mentioned a personal perspective that I thought was compelling, and I share it with you:
I can relate to this paper in a strange way. I lived in Quebec, where people speak a different French than mine. Some words were the same but used for different things. For example, a 'camisole' in Quebec is a sleeveless T-shirt, but in France is a straitjacket! As French citizens living in Quebec, we were advised not to assume that we spoke the same language – 'you might use the same words, but they have different meanings.'
It seems we are not alone!
The Macquarie Dictionary (the best reference for Australian English usage) says that 'camisole' is 'a woman's simple top with narrow shoulder straps, now usually worn as an undergarment.' Prenez garde, Clément!
Roger Tregear
Latest posts by Roger Tregear (see all)
- Practical Process: Process Improvement Is Not Enough - June 6, 2022
- Practical Process: What Should a Process Owner Know? - January 3, 2022
- Practical Process: Why is Process Work Different? - September 7, 2021
- Practical Process: A New As Is–Making Process Improvement Real - May 31, 2021
- Practical Process: Speaking to the Board–A Fab Way to Communicate with Strategic and Effective Executive Decision-Makers - April 5, 2021
A process system and a management system, needs a common business vocabulary in all the company, to drive the Strategy voice. But each task name and each process name must be with the envision direct line from company strategy.
Roger, I was about to comment on Process Precept #1 when you posted this gem. As you say, ‘Shared understanding is everything; without understanding, there is no effective communication.’
13 years ago, Bill Gurley from Benchmark Capital called BPM the next killer app, “BPM will not just change the software industry – it will change industry in general. Just like Deming.”
Your paper describes why this has not happened – there is ‘no effective communication’ of process.
We can argue about words for ever, but to quote Ivan Turgenev a “drawing shows me at one glance what might be spread over ten pages in a book.” Write 10 pages about a rose and people will still interpret the words, but with one picture everyone sees the same thing.
Pretty much everything we currently use to describe what happens in an organization is conceptual. Even the drawings we use – flow charts – are largely abstract.
Think of process as blood supply. We can show how it interacts with the body’s organs but if we can’t picture the blood flow in the context of a human body our understanding is diminished.
So too with business. Process needs to be pictured in the context of the organization it supports.
In a former life (we sold Process Manufacturing ERP) our PR firm couldn’t envisage what happens in a manufacturing business so we drew a picture of the main end-to-end processes – sales, manufacture and purchase – flowing through a typical factory/office layout and interacting.
We subsequently discovered that our sales prospects were also in the dark about how their own business hung together so we used that diagram in all our sales activities. It was very effective.
Recently we searched the Web long and hard for something similar but could find no generic images that convey how a manufacturing business works from end-to-end. Do such exist or do people really not know how processes operate in the real world?
The problem for process today is that it lacks a formally defined environment with which to interact and thereby present itself, both in terms of the organization in which it operates and the resources that it utilizes – the buildings, offices, desks, machines, trucks, etc. that define the real world in which process takes place. Not forgetting the people and spatial attributes – the things the IOT requires.
With this we can show the C-suite their organization and its processes in a form that they can relate to – the real world. We can now achieve the transformation that Bill Gurley predicted in March 2003.
As Einstein said, “If I can’t picture it, I can’t understand it.”
Thanks for your support, John.
I agree that visualization is a massively powerful tool. Not a panacea though, as I expect you’ll agree. Two people looking at a picture can easily have very different opinions about what they are seeing. Proof of that is in every art gallery. Visualization helps us see the big picture, perhaps an abstraction without the noisy details, but we still need to talk about it. In the phrase “shared understanding” perhaps the hardest part is the sharing.
Agree. There are multiple sources to have some “process” terms defined in different ways. Sources may include having a team with people from different nationalities, coming from different industries, and even if they come from the same industry, they come from different companies. In some cases, when a company is new and it’s still in the process of defining its common terminology, a term in one area can be described very different in other area.
Roger,
I’ll see your William Shakespeare and raise you an Abraham Lincoln.
“How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn’t make it a leg”
A timely article for me. By way of introduction I’m currently employed as a business analyst in a U.K. based financial services organisation. Apologies for the length of the reply but I believe you’re the closest to “solving” the practical dilemma I’m facing that I’ve read thus far. I too have waded through the Linkedin discussion( for those interested it’s here)
https://www.linkedin.com/groups/1175137/1175137-5796714327490707456)
only to be bewildered by the multiplicity of views, but also intrigued by some entrenched positions.
External influences to my current organisation have prompted discussion around “capabilities” and there’s been further conversations regarding how these link / relate to “processes”. It’s not the first time the company has dabbled in this space, but new concepts are being mooted and kicked around.
I am relatively new to the architecture discipline and am either blessed or cursed by carrying no baggage whatever regarding “processes” or “capabilities”. I have heard and read persuasive arguments from proponents of both terms. I’m a pragmatist. I want a tool that works for what I’m doing (helping to articulate an enterprise architecture).
Starting from virtually no knowledge, I’ve have therefore been on a journey of discovery (an interesting one). My starting point was a well written and consumable article titled “The Business Capability Map: The “Rosetta Stone” of Business / IT Alignment” Authored by William Ulrich and Michael Rosen. At the time I commenced my journey, said article was available freely on the net (as an example of Cutter Consortium’s work) it has subsequently been placed behind a pay wall (fair enough given its quality / utility). However, that article had the following words within it (I hope Messrs Ulrich and Rosen don’t object to the redacted quote being used here) :
“Capabilities map to, but are not the same as, an LOB, business unit, business process, or value stream……………………………. A capability does not decompose into a process; a process does not decompose into a capability.”
That’s about as black and white as it gets. In the authors’ expressed view, there certainly is / was a difference between what is referred to as a “capability” and a “process”( in their article). Without the authors having reference to your definitions of holistic / minimalist “process” it is impossible to determine if the authors would agree with you that they are the same thing.
To a degree it does appear that at least Michael Rosen has been persuaded of the holistic view, well according to Alec Sharp he has:
https://www.bptrends.com/publicationfiles/10-01-2013-COL-Practitioner's%20Perspective-Peace%20Accord%20Reached-Alec%20Sharp.pdf
There’s further support for the view you present provided by Max Tay (an effective contributor to the Linkedin discussion)
http://blog.maxconsilium.com/2013/10/business-process-architectural-view-vs.html
Who made a point analogous to yours in “ that” thread but was swept away somewhat in the ongoing discussion. It’s very much a case of he who defines the terms wins the argument. If you fit a definition of “process” to be equal to “capability” then the terms are indeed interchangeable. Whether it’s sensible to do so or not is a different question.
However, out in the real world there are still business architects talking about “capability” and “process” as mutually exclusive. This is problematic personally (stopping progress), but I wonder whether it indicates a possible drawback of the approach you have suggested?
Firstly and most importantly (and still not settled beyond doubt) . Is the intent of the word “capability” as described by its proponents (primarily in the Business / Enterprise Architecture community) equal to your suggested definition of holistic processes? If it is, then great! However, you appear to have already made that assumption (or are sufficiently convinced they are)? With due respect, you’re just one more bloke on the internet espousing a view (facetiousness is my downfall and I apologise for it). How do the non- cognoscenti determine the veracity of the position you are promoting? Otherwise we’re in Lincoln territory? Is it sufficiently rigorous to insist that “process” covers everything an organisation does or could want to do (note with more time I’d word this more tightly)? If I wanted to be mischievous when playing semantics consider the following. I have the “capability” to love my children. Try and convince me that is a process. If it isn’t a process and is something else then using process for both would seem odd would it not (In the time available I couldn’t think of a killer business example something like “inspire customers” might work).
Secondly, whilst conceding that understanding is more important than words, standard definitions are adopted for a reason. Among them is promotion of common understanding within disciplines and potentially across them. Without such common language, the process of translation / interpretation becomes ever more awkward. Where would we be if a French “metre” was different to an English “metre” (we should never have given up the yard!)?
I’m neither wedded to BPM or anything else for that matter . As a pragmatist I believe your five points are useful and possibly the only way to proceed given that the dream of common language let alone understanding appears beyond us. Within an organisation they will provide sufficient commonality of understanding to move forward regardless of the terminology used. However, I would caution that even agreement within a single workplace may be problematic and time consuming. More widely though for us new to the discipline it would be of great help if there was at least some agreement of some common terms. As it is, a given definition is almost only as good as the last person you spoke to…… perhaps it really is? When confronted with BIZBOK, BABOK, Glossaries etc. it’s disconcerting to have to basically pay scant regard to them.
Finally thanks for taking the time to publish this. It has allowed me to think around some of the tail chasing I have been doing and put it in perspective. I cannot succeed without terms defining what we’re currently doing. There’s more work to be done!
Spencer
Thank you for your thoughtful response and for the research you have done to bring together some key references.
Firstly, let me happily acknowledge by JABOTI status (Just Another Bloke On The Internet). While I’m sure the world would be a better place if everyone else just agreed with me, I can see that the world does not have that capability and I don’t know by what process it would be developed!
This capability vs process question worried me for a long time until I realized it wasn’t a question that I had to answer. I’m perfectly happy for capability modelling to happen amongst consenting adults, and the breakthrough for me was to realize that I didn’t have to participate – I could just get on with managing processes (holistically defined).
However, I appreciate that this is not a universally applicable solution and that you have to deal with the dreaded “external influences”. So let me outline my response the question “what about our capabilities?”
Essentially, my answer is “what’s the problem you are trying to solve?” If you accept the premise that the only way any organization can create, accumulate and deliver value to customers and other external stakeholders is via cross-functional business processes, and this is the essence of process-based management (I have discussed this in many places, for example, see my BPTrends columns here, here, and here), then the primary focus needs to be on processes. In any case, it always seems to me that what most people mean by “capability” is the ability to execute a process. If we define process in the holistic way, what is missing that requires the addition of the concept of capabilities? What’s the problem that is solved by the addition of capabilities? This JABOTI doesn’t see one.
In developing theories of organizational development and management, we should be seeking to bring simplicity, not increase complexity; we should be trying to make things easier for managers, not harder.
I don’t feel the need to prove the ‘primacy of process’ by disproving theories of capability. They are not the same—if they are the same, we don’t need one of them. There seems a lot of support for the idea that one does not ‘turn into’ the other. So as separate concepts they can co-exist. I just don’t see the need for the capability view. If you pursue both the capability view and the process view (holistically defined and properly named) you might discover soon enough that the need for the capability view disappears. Then the primacy of process is proven, or at least demonstrated.
I take your point about human emotion (love for children in your example) being difficult to explain as a process. I agree. We are a long way from being able to model, indeed even describe well, any human emotion. In thinking about organizational performance, do we need to? You said you couldn’t easily see a “killer business example” but “inspire customers” might be one. I think we could define a process called Inspire Customers. I don’t mean to say there is no emotion in management, but I don’t see it being reduced to a process or a capability. There is a similar issue in process description. In many processes there comes a point where the activity is essentially Be Clever and we are relying on years of experience and expertise to synthesize many variables and make a judgement call. We can’t easily, or usefully, model what happens in the head of such experts either.
Thank you for engaging in this discussion.
Roger
Sure, we must progress to common-agreed concepts, terms and definitions. BPM and EA are still as alchemy, while, ideally, they should be as applied science.
At present, I consider some various definitions of the same concept as different viewpoints – see http://improving-bpm-systems.blogspot.ch/2015/10/concepts-crisis-in-it-and-sister-domains.html
Thanks,
AS