1. Peter Schooff
  2. BPM Discussions
  3. Thursday, July 13 2017, 09:52 AM
  4.  Subscribe via email
As the two terms are often confused, what would you say is the difference between workflow and process?
Emiel Kelly Accepted Answer
Workflow is just part of a process; the work (and order, if there is) executed for a case (that's why I like to call it a caseflow). In a process picture, the workflow is most of the time the skeleton that is drawn (at least, if it is possible to draw which is sometimes not possible for processes where the workflow "arises" during executing)

But to make that work happen, you need much more enablers. Think about:

- People
- Supplies
- Tools
- Information (on different levels)
- A way of managing

To me, that is a process : "Everything you do and need to solve the problem of a customer". Workflow is just a little part to make that happen.

Unfortunately a workflow (blocks and arrows) is often seen as a process.
Sharing my adventures in Process World via Procesje.nl
Patrick Lujan Accepted Answer
Blog Writer
Workflow – “the automation of business procedures or ‘workflows’ during which documents, information or tasks are passed from one participant to another in a way that is governed by rules or procedures.” - WFMC, c.1998

What is BPM? - Nathaniel Palmer, c.2014

One is connecting the dots. The latter is a multi-disciplinary business practice of which connecting the dots is, 'yes,' the skeleton.

In a word - "maturity."
Peter Hilton Accepted Answer
There are two potentially reasonable answers to this question:

  • BPM and workflow are just the same thing.
  • BPM and workflow are not the same thing.

This is a disturbing state of affairs that previously led me to write a longer answer in this blog post: The difference between workflow and business process management.
  1. https://www.signavio.com/post/difference-between-workflow-and-bpm/
The question is not workflow vs BPM, but workflow vs Process
  1. Emiel Kelly
  2. 2 weeks ago
Ayuh, you're right.
  1. Patrick Lujan
  2. 2 weeks ago
Bogdan Nafornita Accepted Answer
The workflows of the '90s are the processes of the '00s are the smart business applications of the '10s are the autonomous business bots of the '20s.
Managing Founder, profluo.com
All true. I will add that workflow persists in each generation of technology, in the same way that debits and credits persist in ERP systems.
  1. John Morris
  2. 2 weeks ago
Processes are templates - if you tweak them they become "best practices" - they lay out recommended steps in a particular sequence and usually incorporate a number of branching decision boxes that allow engagement of one or several or all of the available options at each decision box. Some decision boxes only accommodate selection of one of the listed options (i.e in a healthcare process, is the patient a male or female?).

Few processes are end-to-end in terms of practical attainment of Case objectives, so most of what you see in your inventory of process maps should rightfully be described as 'process fragments'. Process fragments don't have objectives other than the objective of getting to the "last" step.

Your "process" run-time side at Cases becomes the result of users and machines threading together process fragments.

Most work environments have to worry about workflow and workload. Unless you have one person performing all of the steps making up a process template instance, you need ways and means of setting priorities for the performance of work (i.e. many users, performing work along many process template instances, at many Cases).

A Case hosts process template instances and records actions at steps - a Case is a patient, an insurance claim, a homicide investigation, a job shop operations order.

Users need an environment capable of loading up user InTrays with process template instance steps. The name of the environment is Case. Technically, it is a record in a relational database management system unless the organization for some bizarre reason prefers individual Windows files/folders.

Steps post as they become "current" along an instance. The reason a particular user sees a step is that the step (plan side) had a routing that matches the user's skill category (i.e. admin person, nurse, doctor ; claims adjuster versus admin ; detective, supervising investigator, medical examiner ; welder, pipefitter, electrician).

Users micro schedule steps at their InTrays (I prefer today to complete three small tasks, versus advancing one large task; tomorrow if I have no meetings, I might prefer to spend all of my time advancing the status of one large task).

Supervisors tend to level and balance workload across Cases/Users, overriding user micro scheduling actions (the customer needs this order by Friday).

The usual expectation is one person "takes" a step and completes that step. Except in e.g, hospitals where many steps span shifts making it necessary to effect "handoffs".

Some of the time supervisors assign steps to other users as part of balancing workload within and across Cases.

When a Case Manager closes a Case, the particular set of steps performed is the Case workflow. (who did what, when)

Most of the time you have a unique set of steps at a Case where most of the steps in a template instance have been performed, where some of the process template steps have been skipped, and where some of the steps were ad hoc insertions.

The performance times for steps performed at a Case can vary widely (i.e. a 1 hour step could take 1 hour or 5 hours or 3 days).
Small qualifier here

"The reason a particular user sees a step called "A" is that:

a) step "A" (plan side) had a routing that matches the user's skill category
b) all predecessor (as per process logic) steps to step "A" have been declared to be 'complete'.

  1. Karl Walter Keirstead
  2. 2 weeks ago
What happens if two or more users see step "A" is a question we often get.

Perfectly legitimate because we encode skill attributes to steps not named users.

The protocol is simple - the first user "takes" the step and "owns" it. The step now shows "busy" to the rest of the users who saw step "A" and the step may actually clear from their InTrays if they do a refresh.

The expectation is the user who "took": the step will perform it or put the step back in the pool of "current" steps.

In medicine, if the performer/owner of a step goes off shift without completing the step, and there is an emergency, we go to "Break Glass" - here, anyone wanting to take over the step, has to make voice contact with the step owner, clarify what was done/ not done and then only take over the task.

If the new user cannot make voice contact, they have to "Break Glass" and this appends a "protocol variation" in the Patient Case History and brings both the original user and the new user on the carpet the next day to explain why the original user did not "put back" the in-progress step to the pool of "current" steps.

You can see that errors in handoffs can have life-death consequence in healthcare and other domains i.e. I come in, see an empty syringe, did the original user administer the dose or not?.

The options are no dose or a double dose, either of which could be fatal.

  1. Karl Walter Keirstead
  2. 2 weeks ago
Tim Bryce Accepted Answer
In the systems hierarchy, the process is represented by the sub-system, which is decomposed into procedures (both administrative and automated) representing the workflow. Administrative procedures are sub-divided into operational steps (aka, tasks), and computer procedures are sub-divided into programs.
  1. http://www.phmainstreet.com/mba/ss090813.pdf
Workflow and process are both techniques to explicitly coordinate various activities. They can handle various related artefacts (events, rules, roles, etc.) but at different levels of maturity. See ref1.

  1. https://improving-bpm-systems.blogspot.ch/2010/04/comparison-of-technologies-for-bpm-bpms.html
Max J. Pucher Accepted Answer
Blog Writer
Quite amazed by the answers ... and the immense ambiguity in terminology used.

It is really quite simple:

1) A process is a component of a value stream (or stage) performed by a defined business capability and describes a desired outcome. It also describes roles and resources involved.

2) A workflow is one means to describe a rigid sequence of work activities. It can be used to enforce work needed for a process but does not ensure outcomes. It is also costly to manage and implement requiring standardised workflows to be feasible. For 80 % of processes any other form of ensuring process outcomes is more effective.
Indeed, it is quite simple . . . .

Work that does not advance the needle toward a Case objective is work that should not be performed (with the exception of work done to satisfy external rules and regulations and work that benefits all Cases).

Not sure "any other form of ensuring process outcomes" is the way to go, but I am content with "any other good form of ensuring process outcomes is more effective"

  1. Karl Walter Keirstead
  2. 2 weeks ago
I thought some processes (admin, corporate, staff) live outside value streams.
  1. Bogdan Nafornita
  2. 2 weeks ago
Yes, they do. All corporations have overheads. There are many things that need to get done that do not directly augment value streams
  1. Karl Walter Keirstead
  2. 2 weeks ago
John Morris Accepted Answer
For today's question on the difference between workflow and process, here are some definitions sourced from various easily found sources (SEARCH ontology workflow task process) . Notice we start with "work". . .

          0) Work is the deliberate expenditure of effort to change reality ( i.e. in support of an "outcome" ).
          1) A task is a unit of work.
          2) An atomic workflow is a single task.
          3) Workflows are multiple orchestrated tasks.
          4) Workflow software is software technology that virtualizes (for modeling and management) a workflow.

and on to my summary version of process . . .

          5) Process is a generalization of workflow in the context of the sponsoring organization.
          6) Process software technology, such as BPM, is based around workflow but encompasses additional
          support and tooling for workflow repetition and instance management and organizational
          context (esp. integration and identity
) .

Reading multiple common definitions of workflow versus process does not leave one with clarity. Workflow is "old-fashioned" and out-of-date. Process is the new workflow. (Except some of us are even abandoning process for solutions!) Or something. This makes selling BPM software more difficult. Arbitrary, informal distinctions between what should be clear technical definitions don't help either technologists or business leaders.

Concerning our question, let's start somewhere else first and then work back. How about "BPM software helps you automate your work". So you can do things differently and better. I once wrote a blog post about how we are "work shy", meaning we don't use the term work very often. And yet that's what business is all about. Thus the definition of BPM (posted elsewhere on this website) as "the technology of the work of business".

It's useful to consider that work and workflow are at the core of BPM and process -- in the same way that debits and credits are at the core of accounting and ERP and ecommerce. You don't "abstract away" from debits and credits. Debits and credits are not "out-of-date". If we turn our gaze away from what is at the core of BPM and workflow, then the work itself becomes a black box and an invitation to magical thinking, etc. etc.

So is BPM software workflow or process software? Maybe it depends on who you're talking to. Here's a possible distinction between workflow and process:

          a) Workflow is orchestrated work tasks from the point of view of the worker.

          b) Process is orchestrated work tasks from the point of view of the manager.

This distinction is actually useful -- a business case for a process, including the construction of a BPM artefact, is interesting and useful to process-sponsoring executives. Later, when deployed, day-to-day tasks managed via workflow are interesting and useful to staff. In both cases the "orchestrated work tasks" are in support of the same outcome for which the workflow/process asset was built.
I like

a) Workflow is orchestrated work tasks from the point of view of the worker.
b) Process is orchestrated work tasks from the point of view of the manager.

We all know corporations encourage staff to make consistent use of “best practices” because consistent use gives better outcomes. Making processes available as templates accomplishes this, to an extent. [manager, plan side]

We all know that workers need to deviate from “best practices” now and again. When they complete a scope of work, the record of what they did, when, and how is the workflow. [worker, run-time side]
  1. Karl Walter Keirstead
  2. 2 weeks ago
@Karl - +1 a perspective focusing on "plan" and "use". All this terminology should be -- and can be -- very clear. Adoption of BPM is held up when terminology is not clear.
Now however your note has triggered a new question, which is "what about when we just had 'workflow'"? In other words, if one was using workflow software circa 1995, obviously that software technology was used both in "planning mode" -- and then in "run-time" or "using mode". And so now the clear distinction between workflow and process based on points of view (POV) isn't so clear any more. My answer is "not to worry". In 1995, we used words which applied in that day, but the distinction works perfectly well now based on the evolution of business discourse.
  1. John Morris
  2. 2 weeks ago
@John, glad to see that different viewpoints are used to describe work! This is the first step to the systems thinking.
  1. Dr Alexander Samarin
  2. 2 weeks ago
FYI, I have added the idea of "outcome" (mentioned elsewhere in this discussion by @Max, @Karl, @David) as a better business word than "changing reality" as the purpose of a workflow/process.
  1. John Morris
  2. 2 weeks ago
Sure, "filling an order", "settling a claim", or "discharging a patient" are, for me, outcomes.

It may be that these initiatives "change reality", just as any action changes an input to an output, but I find "outcomes" to be more easily understandable.

In medicine, the Case objective is to discharge the patient and "outcome" seems to qualify whether they relapsed within 6 months so the meaning of outcomes can vary.

Anyone working with English has these problems -

In what other languages do you have folks "Driving on parkways" and "Parking on driveways"? Or, freeways, where you pay money.

We still have problems at BPM.com with "goals" vs "objectives" - I use Russell Ackoff's 1970 definitions but across the Internet we see variations.

I can see this is becoming a Friday "rant" so I might as well again give a response to "When do Cases close?"

The stock response should be "Cases close when Case Managers close them" (not my invention - It probably derives from "It ain't over till the fat lady sings").

There is a practical twist to this silly response - since most Cases are closed manually, it follows, does it not, that one cannot possibly know what the workflow was until then because we never know what the "last" step is prior to closing?

What we seem to have sorted out at this Question is that process building is a plan-side exercise.

We have Cases for hosting process template instances, users do what they like. subject to orchestration from background BPM and user skips/jumps/ad hoc insertions.

The "audit trail" that the Case Manager sees at the time the Case closes is the "workflow".

Given two identical Cases with exactly the same steps performed in exactly the same sequence, the fact that one Case closes at T40 whereas the other Case closes at T57 is due to "workload" management by the Case Manager and the performing resources at the Case.

I need to qualify "audit trail" - what we really should say is "Case history" because the only acceptable content here is "data, as it was, at the time it was collected, on the data collection forms that were in place at that time, with a date/timestamp and user signature".

Once in, no entry can be changed otherwise you no longer have a legitimate "history". Many "audit trails" are nothing more than "logs".

I need to get back to work. . . .
  1. Karl Walter Keirstead
  2. 2 weeks ago
A version:
Managers' view is a model or template (HOW the work to be done).
Workers' view is an instance (WHAT work I am doing now).
Workflow is a human-tasks-only view (historically).
Process as a set of activities is an external observer's (e.g. consultant) view.
Process as a coordination of any activities is an architect's view (WHY the work to be done as that).
Some managers are architects of their processes (fortunately).
  1. Dr Alexander Samarin
  2. 2 weeks ago
@Alexander . . . +1 for clarity..

Re your first item, would you be able to live with "HOW the work should be done" ?
  1. Karl Walter Keirstead
  2. 2 weeks ago
+1 @Alexander and @Karl. We are getting lots of specificity here.
  1. John Morris
  2. 2 weeks ago
Re: "outcomes", note that the root of all workflow and process is work -- which is defined as "purposeful expenditure of effort" (i.e. to distinguish that activity from "play" - although one could argue that outcomes are not excluded from play). "Purposeful" directly implies outcomes. I note that the word purposeful includes a probabilistic element (i.e. "intentions") which is not directly a meaning of the term outcome. One must qualify outcome as in "intended outcome" to add probability.
Which gets us to @Karl's mention of "goals" versus "objectives". We have discussed elsewhere on BPM.com the debate (some would call it fruitless) on the meaning of goals and objectives, which are deceptively synonymous with outcomes. A good explanation can be made if one subsumes these terms under system theory. Then we get a goal is "new system state" of a desired object, and separately an objective as the "output of a project or a process". Thus projects or processes produce outputs which enable a new "state of affairs" for the host entity, e.g., a corporation.
As I have shared previously, it is possible find references to the meaning of goals and objectives which match this definition of goals and objectives; it is also possible to find definitions in which the semantics are completely reversed. All of this sounds academic; to my mind though it is evidence of the state of the maturity in management discourse. There is a very high cost to the current lack of precision -- if you dig into the reported root causes of failed projects it's not too hard to find examples of costly confusion between goals, objectives, purpose, project, process, mission etc. etc.
  1. John Morris
  2. 2 weeks ago
+1 @Alexander for "Workflow is a human-tasks-only view (historically)." -- This is true, and even today market analysis call out BPM packages which are human-task-oriented. While there is certainly some practical truth to this categorization now, I see it as an artefact of history (also as suggested by @Alexander). We are now faced with the question of BPM where the actors may be physical or virtual robots. Any discussion of productivity and automation -- which is the purpose of BPM software technology -- must now or soon include the question of non-human actors. We already have "sort-of" robots as machines (e.g. a Linux server with some CRON tasks and an API). I suggest that some historical terminology can be misleading.
  1. John Morris
  2. 2 weeks ago
@Karl, I think we may follow the MoSCoW patterns:
"HOW the work must be done"
"HOW the work should be done"
"HOW the work could be done"
"HOW the work would be done"

@John... For sure, we don't want BPM packages that are only "human - task - oriented".

The good solutions accommodate any mix of work from 5% human to 95% machine/robot.

For this to be accommodated, you need a task oriented environment where users can get to InTrays and perform tasks that post.

The environment must not be closed - you need one of hard-wired devices or a generic data exchanger between your environment and local and remote system, applications, devices so that the environment is aware of what is going on outside of the environment and can, on it's own, facilitate processing or impede processing based on data values and rule operating on these values.

Tasks that do not need the attention of humans can be encoded to "system" - we can pretend that they post to the InTray of a non-human user called "system" and that "system" deals with them. Nothing I can see wrong with that.

If "system" has a problem i.e. the particular set of data item values at a branching decision box is incapable of firing any one of the listed options, the designers of the process painfully (hopefully sooner than later) discover that they should have included an option called "none of the above".

So, at the end of the day, there is no difference between a human task and a non-human task.

Each must be committed for activity downstream from that task to move forward.
Emiel Kelly Accepted Answer
I think readers are much less confused after reading all the answers. :p
Sharing my adventures in Process World via Procesje.nl
less than writers?
  1. Dr Alexander Samarin
  2. 2 weeks ago
Well, the writers are all over the place, so the readers probably are way more confused than they typically are at these BPM Questions/Responses/Comments.
  1. Karl Walter Keirstead
  2. 2 weeks ago
Kai Laamanen Accepted Answer
I would like to support John's view... Workflow point of view of the worker, Business Process is point of view of the manager. The wording "process" can of course refer any presentation including input - activity - output.

The phenomena behind the question is how to deal with the "granurilaty" of the activities and different "levels" process management. If we describe the activities in very detail, we loose the big picture. The purpose to describe the process is different for a worker and manager. The workers view is more action oriented... how the work is done (= best practice as Karl has pointed out). The manager view is more about how the work is organized... do have clear roles and effective job designs or meaningful performance metrics.

I have identified 5 "levels" such as
1. Business definition... position in value creating network
2. Process map...customer's buying logic vs. organization's earning logic
3. Business process...organizing the work for value creation for customer and improvement of operational excellence
4. Product and service process.. how specific product or service is realized to create value
5. Workflow... for learning, process improvement and information system development for better performance

Each level has it's own purpose or challenge to deal with. In big picture I see the three upper levels as "process management" (manger's responsibility). The two lower levels are for "process improvement" (expert's or worker's responsibility)

br. Kai
David Chassels Accepted Answer
Process represents the end to end sequence of tasks which create information for a desired outcome. Within that process there is the need to pass information to other users, incl machines, to complete the process. Workflow is that movement of data/information within a process and just one " component" alongside rules state UIs etc which make a modern day "platform" to build a process.

Indeed, one meaning of "the process" is the "final" end-to-end sequence, but that can be five process template instances threaded together as never before, with all kinds of skips, jumps, ad hoc insertions.

In practice, we might as well resign to each Case being absolutely unique.

Contrast this with a "totally" automated real "end-to-end" process where plan side is the same as run-time side where all outcomes are hard-wired (for good reason) - in an automated cement making process, if your slurry feed goes below a certain level, and the process is not throttled back, the kiln will burn out and you could end up having to re-brick long sections of a 400 foot long kiln.

I don't see how "workflow" is just "one 'component' alongside rules . . .

Workflow for me is the result of rules etc (i.e. the user tries to do something, the rules trip him/her up, the user has to remedy or work around).

See my long comments above relating to workflow and workload.
  1. Karl Walter Keirstead
  2. 2 weeks ago
Is a BPMs the same as a Case Management System?

I don't see how one can get customers to 'do BPM" if the software environment does not accommodate hosting of instances of process templates, accommodate user workflow (what they do/when), and accommodate supervisory workload leveling and balancing.

For many apps, if you don't have a way for external systems to auto-load data to Cases and if you don't have a way to message/get back responses to and from remote systems, you become a prisoner of your environment.
@Karl. You raise good point what is BPMs? BPM is the discipline in thinking to create the application. Call the resulting application what it does...BPMs is....what...? There is not much in business that is not a case and to adopt BPM you need to understand how the software delivers as you suggest. The tag Adaptive is what the resultant application needs to support..time to put BPMs to sleep.....it is meaningless to business.
  1. David Chassels
  2. 2 weeks ago
+1 @David, as usual, you give good suggestions and good advice!
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.