No, it’s not about processes start and end event, it’s about what should be named as process and what shouldn’t.

A few quotes showing the range of opinions -

Paul Harmon comments the “Process and Capabilities” discussion at LinkedIn BPTrends group:

One of the major differences in the field is between people who use “process” to refer to a diagram, or even more narrowly to the pattern of activities and flows, and those who use “process” to refer to everything that is involved in producing specified outputs. I am definitely in the latter camp… for me, the idea of separating “recourses” or “people” or “managers” from “process” is simply to take a very narrow view of process… The “capabilities” the Army cites are small processes - activities if you would - that get assembled into larger processes when necessity requires. One capability is landing by rubber raft. Another is hiking 10 miles very quickly, etc. Once a specific hostage situation arises a process (project?) is assembled of many discrete activities and executed.

As we can see, Paul tend to name “process” literally everything - activities and combinations of activities of any scale, and makes no difference between processes and projects.

Howard Smith writes in the article published at BPTrends.com:

Trying to box process in and equate it with step-by-step systems is a fiction which denies all modern thinking about process in theory and practice. “Adaptive case management” is just one type of process, a name for the process inside. Open the “adaptive case management” box and what you’ll find is a process.

Association of BPM Professionals sees it differently (the quote from BPM CBOK, Chapter 6, section 6.2.2):

… we find that a great many companies define process and process management as the work that happens within a given business unit. ABPMP officially disagrees with this definition… “Process” as defined by ABPMP is cross‐organizational and takes in all work of any type needed to build and deliver a product or service. Here process can be broken into subprocesses and the subprocesses performed by business units…

What is common and what is the difference?

• Common is the focus on the end results and performance. (Geary Rummler called what he was doing “performance consulting”, not “process consulting”.)
• It’s also common agreement that the work performed should be considered at all levels - at the top end-to-end process level, at the workflow level, at the individual workplace level.

The disagreement is two-fold:

• ABPMP reserves the term “process” for the top level of the process hierarchy and uses terms “subprocess”, “workflow”, “activity”, “task” for lower levels. The alternative viewpoint is to call “process” all activities from top to the atomic tasks.
• Paul and Howard do not make difference between processes, projects and cases, they all are just different forms of the process work. The CBOK, by contrast, clearly distinguishes processes and projects.

But does it really matter? It’s just the definitions game after all - I’m sure that both camps use the same methods in the field.

I believe it does: words aren’t just letters or sounds, it’s also magic that programs people’s behavior. How do you call the boat, so it will flow. From this perspective it’s a bad idea to call any activity a process.

When people are said that everything is a process, they tend to lose the goal (the value for the consumer) and the end-to-end process out of sight. It’s much easier and comfortable to imitate process management activities at the lower levels - without crossing the department boundaries, without questioning the existing balance of power… in a way like this:

But sorry - “no harm, no value”. So I agree with ABPMP’s position: you can’t pretend to practice BPM if you don’t reach the end-to-end processes.

I also believe it’s counter-productive to put the equal sign between projects and processes. OK, there is no difference whether the goal will be reached by a project or process. Yet the methods, tools and practices used to manage projects and processes differ quite significantly, so how would we elaborate these methods and how would we adopt these practices if it’s “all the same thing”?

You don’t need BPM if you should hold the Olympics in Sochi. Those who prepared it perfectly mostly thought in project terms, not in terms of processes - I know it for sure!

Pure process methods and tools probably won’t be sufficient for a law firm, too. It’d be just fine for the insurance company yet the legal case can be defined as process at the topmost level only.

What is more reasonable in cases like these - pretending that these are all kind of processes or saying that there is process methodology capable of doing this and that but it won’t sufficient so you need to have e.g. case management tools? I believe the second approach would be more pragmatic and better help reaching the goals.

Whenever we need to name all range of work performed to reach the organization’s goal including projects, processes and cases of any scale then let’s better use the term “collaborative work”.

In the following series of articles I’ll share my thoughts about similarities and differences between projects, processes, cases (and also document-oriented workflow, incidents, tasks), what tools are there to manage them and how the unified environment able to deal with all forms of collaborative work may look like. In fact they are already published at BPM.com so impatient readers may read them right now. Others are welcome to read them here twice a week.

Similar articles:

• What Is a BPMN Process (And What Is Not)
• How the Division of Labor Lowers Productivity