We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

Is workflow still the core of every BPM implementation?

Vote 0 Votes
From Adam Deane's Business Process and Workflow blog, where, in reviewing the quotes of the week, Adam quotes, "The 'w' word today is also blasphemous in the analyst space because it is so much 'yesterday's news'.  But I argue that workflow is the core functionaliry of everyone's BPM implementation."  Do you agree?

10 Replies

| Add a Reply
  • Partially....

    Process (more precisely, business-process) is explicitly-defined coordination of activities to create a particular result. Those activities are carried out by different functional roles. (Functional roles should not be mixed with organisational roles, because an organisational role may cover a few functional roles.) For each functional role there is a view (or projection) of the business-process – a pool (like a BPMN pool; of course without any swimlines) which contains the explicit coordination of activities for that role. For some roles such coordination may be trivial, for others may more complex, but often it looks like an ordinary workflow.

    So, for an architect, a business-process instance is a set of pool-process instances which coordinate together their execution; for many participants – almost an old good workflow.

    Also, http://improving-bpm-systems.blogspot.com/2010/04/comparison-of-technologies-for-bpm-bpms.html

    Thanks,
    AS

  • Sure, especially if by "workflow" you mean the general concept of the flow of work, whether it is the guiding an individual worker to the right set of activities in the right order, routing work from person to person, or controlling the mix of work done by people and work done by systems.

    The problem with technological terms is that general sounding terms are often applied to much more specific technologies. In the case of "workflow", it was tied to a specific kind of workflow system -- collections of features and typical use cases -- which got a lot of press in the 90's. People then assume that the term is limited to that collection of features, so then if you have systems that still fundamentally deal with the "flow of work", but also provide good business modeling capabilities, reports, monitoring, system-to-system interactions, etc, people naturally feel the need to find a new term for it.

    This isn't unique to technology. Not to get morbid, but the term "undertaker" long ago implied no more than someone who undertakes some task. People involved in running funerals adopted the term as a euphemism for their career and it soon meant only that. Of course that meant they needed to find a new euphemism.

    And, of course, I don't mean to imply that business process creation is a subject that is so touchy that it requires euphemisms :-).

  • Simply put YES!!!

    The workflow word seems to be yesterdays news because people want to make BPM seem like it's something completely new...And it isnt...

    workFlow, BPM, ACM, APG are all essentially tackling the same business problem, and as such, all handle the process of "getting something done". The only real difference is their implementation on how to takle the same business problem...

    Business had issues with workflow becuase it was too rigid. This lead to the "BPM" term and wave of implementation, a little more flexible and encompasing more processes...But the same problems arise, BPM is too rigid, hence we are seeing ACM and APG being discussed more and more, and rightly so.....

    If workflow is yesterdays news, then surely traditional BPMS is well on the way to being yesterdays news too.

  • For me the workflow is a synonym to the process orchestration, i.e. execution of activities under a single control authority (think about a BPMN pool). But the true power of a modern BPMS and the differentiator towards pure workflow is it's ability to coordinate a network of processes executed asycnhronously and communicating via data, messages and signals.

    So yes - workflow is the core functionality yet it's only a half of the core functionality, process choreography being the other half. You can't do serious cross-functional process improvements without the second half.

    Yet I agree with Chris Adam's thought that process notations, business rules, BAM functionality etc. cost nothing without a robust and powerful workflow+choreography engine which is therefore the core component of a BPM software offering.

  • 'Yesterday', we set out to fix business challenges by looking at what seemed to be the immediate concern - workflow. As we started to adderess it, we began to notice its nuances, variants, contextual differences, challenges, tech shortcomings, and so on.

    And so each time we have drilled down on to the next bigger challenge and the next biggest concern; sometimes addressing it through a different concept or a new paradigm or a different technology.

    The point is we are witnessing an evolution of sorts - and make no mistake about it, for it is also an evolution of our own perspective of the challenges, where our immediate concerns lie and the opportunities and limitations posed by available technology.

    My point - yesterday or today, old or new technology, dated or path-breaking paradigms, we have the same goal: getting business to deliver.

  • This thread needs a dissenting viewpoint. :P

    In my experience, "workflow" describes the coordination of human-oriented tasks. A "business process" is simply a series of activities that produces some business-relevant result and could describe a workflow, the coordination of non-human (system-oriented) tasks, or a combination of the two. So, no, workflow is not at the core of EVERY BPM implementation.

    Case in point: many BPMSes these days are used as service orchestration engines. In this SOA context, a business process involves the coordinated execution of a series of computational tasks (services), with no human involvement -- and, therefore, no workflow. Notationally, the participants are computing resources rather than humans.

  • How about a TLA equation to "clarify" my viewpoint ;)

    BPM - WF + DM = ACM

    Jacob Ukelson - CTO ActionBase


  • There are 3 dominant paradigms in modern BPM:

    1. Workflow (BPMS), which yes is about flow, implemented via concurrent flowcharts - in this approach, as in the BPMN notation, the driver is sequence flow (of Activities) and/or message flow

    2. Case Management (ACM), which is about data, documents and rules, implemented via shared repositories - in this approach, the driver is knowledge worker judgement, constrained by policies implemented as business rules

    3. Human Interaction Management, which is about goals and knowledge, implemented via dynamic, cross-boundary Plans - in this approach, the drivers are effective teams, structured communication, use of knowledge, time management and dynamic planning.

    HTH
    All the best
    Keith

  • While there are arguments for both sides you have to look at it as simply as possible.

    The work needs to be defined and understood before how it flows across an organisation can be defined and understood. Without getting hung up on definitions of 'Workflow' (come on kids, can we move past the vendor acronyms and jostling for position with answers ?) I believe that work needs to be fluid within a certain set of boundaries.

    Picture a river. The water is contained within a set path and the boundaries are the river banks, it can be a rapid river or slow and meandering but how it's how the water moves within those banks that we could and should compare it with how we define and deliver BPM and Workflow.

    If we dropped a lot of the systemic approaches and points of view to how we look on our business models we might find we a lot more common ground.

  • Workflow started as the predefined path of documents with some logical flow branches in between. It basically was about replacing the inhouse office mail cart.

    As process became more about work organisation all these different governance approaches appeared, from Agile, via Outside-In to my own favorite Adaptive. To gain the full benefits, businesses will want to use ONE system and it will have to encompass workflow, case managment (a.k.a. dynamic), social, and obviously mobile.

    Social and Mobile challenge current governance approaches and make them - in my mind - obsolete or unusable. Both are encompassed in the ADAPTIVE paradigm, as is GOAL-Orientation that is not included anywhere else, except in Keith Harrison-Broninski concept of HIM.

    SO NO, workflow is no longer at the core of every BPM implementation, but each process might at some stage also have workflow elements mixed with the others. So it is impossible to use different systems for the different functionality.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT