<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">

The Leonardo Blog

All Posts

Thoughts on the Conflicted Use of Process Language


A Process By Any Other Name....

“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 the conflicted use of process 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 us saying 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 people 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!?

It’s often more than just having different names for processes; we start from different fundamental assumptions about what the term should describe.

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

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, that 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.16_Minimalist_View_Holistic_View.png

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.

New Call-to-action

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

New Call-to-action


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!

Related Posts

Leonardo at the Red Hat Forum in Sydney

Leonardo will be exhibiting and presenting at the Red Hat Forum in Sydney at the Hyatt Regency.  Our presentation topic will be 'Using Processes-as-Microservices to Drive Better Customer Experiences' which presents an approach that combines digitised processes, business rules, and microservices that collectively deliver improved customer experiences through event-driven digital “micro-moments” – those brief interactions with your customers that can sometime be neglected. At our booth we will be talking about  end-to-end process improvement - from business architecture and modelling to process automation, integration and platform - implemented for our clients using an agile, scalable delivery model. We will also being showing our demo of process-centric applications on a digital platform - using best of breed technologies from Red Hat and Entando.  Come enter the draw to automate your own processes using a Amazon Echo Spot.   

Leonardo partners with Trisotech for greater client success

Leonardo announced today that they have formed a partnership with Trisotech - a leading provider of highly visual and interactive software tools that help organizations innovate, transform and improve their operations. According to Adam Mutton, Managing Director of Delivery for Leonardo, “Trisotech enables Leonardo Consulting to foster an innovative, collaborative approach for the subject matter experts at its clients. Trisotech’s Digital Enterprise Suite is a modelling environment that helps Leonardo design, model and execute its customers’ business processes & business rules. Organisations globally are demanding digital and mobile enablement to streamline and automate their processes to improve the customer experience and drive revenue. Trisotech’s modelling platform delivers BPMN, CMMN and DMN which are crucial artefacts to drive consistency that connects business strategy to automation, integration and implementation for Leonardo’s clients.” “Trisotech is very excited to be partnering with Leonardo,” says Trisotech Chief Sales Officer, George Barlow. “Leonardo is an acknowledged thought-leader in process management practice, and has an experienced team delivering technical outcomes for their clients – from strategy to execution. “Leonardo serves a wide spectrum of customers in the public and private sectors in Australia and around the world by delivering a range of products and services in the consulting, delivery and development arenas. “Combining Leonardo’s expertise in assisting customers to improve organizational performance by documenting, analyzing, improving and managing business processes with our Trisotech Digital Enterprise Suite will provide Leonardo clients additional benefits. These include powerful and comprehensive new ways to visualize, innovate, transform and improve through tools like our Discovery Accelerator, Business Process Modeling, Case Management Modeling, Decision Management Modeling, and exciting data visualization via the Insight Analyzer – all powered by Trisotech’s revolutionary Digital Enterprise Graph.” About Trisotech Trisotech is a global leader in digital enterprise transformation solutions, offering innovative and easy-to-use software tools that allow customers to visualize, innovate, transform and improve their digital enterprise processes and business decisions. Trisotech customers use The Digital Enterprise Suiteto provide new and revolutionary ways for their knowledge workers to collaborate and succeed in an increasingly global, connected and competitive world. Trisotech products are providing digital transformation help to communications, agriculture, manufacturing, financial, healthcare, insurance, energy, distribution, government, and many other types of organizations. Trisotech is a privately held company. Website: http://www.trisotech.com

Leonardo partners with University of Melbourne’s Apromore

Leonardo and the University of Melbourne’s Apromore team today announced a partnership whereby Leonardo will be assisting the Apromore team in developing the platform strategy and implementing it through an agile methodology, and by providing industry-strength development power to improve the platform. According to Leonardo Managing Director of Deliver Adam Mutton, “Apromore’s unique selling point is that its process mining capabilities are ahead of the curve, given that they are directly informed by many years of academic research, combined with numerous applications in the field. We have substantial experience in supporting open-source initiatives and are confident we can transfer this experience to the Apromore Initiative”. Apromore is an open-source business process analytics platform combining state-of-the-art process mining capabilities with functionality for managing process model collections. Apromore’s wide range of advanced process mining features range from automated discovery through to variants mining and predictive process monitoring. “We are thrilled to be partnering with Leonardo,” says Apromore team leader Professor Marcello La Rosa, from The University of Melbourne. “Leonardo Consulting is an acknowledged thought-leader in process analysis and improvement, and has an experienced team delivering technical outcomes for their clients – from strategy to execution. This partnership will help the technology become more robust and ready for large-scale adoption.”