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

Can BPMN work for the knowledge worker?

Vote 0 Votes
We have considered this question from a different angle, but I think this is important. As Keith Swenson says in this blog, "BPMN is not a good language for describing a plan for a knowledge worker, because it requires a skill beyond their profession." So do you think BPMN is a good language for the knowledge worker?

12 Replies

| Add a Reply
  • BPMN seems to ensure that development sits in IT so to put in simple language "NO"!

  • Are Knowledge-workers looking for a language?

    Do they need a language for structured tasks?

    Are fixed sequences of Tasks a Knowledge-worker priority?

    "Knowledge"-work suggests information and expertise. It is less about control flows and more about decision support; less pre-defined and more adaptive.

  • I think "Knowledge Workers" would rather skip BPMN and go directly to a template guiding them through the steps to building solutions. Essentially they need to 1) create a checklist of items associated with the workflow, 2) create the workflow (Activity 1, Activity 2, etc), 3) add basic rules per activity (who does what by some deadline, attachments), and 4) set notifications. The user designing the solution never sees BPMN. This functionality/templates currently exist. They are quite cool.

  • If BPMN can be pared down to a subset that is relevant to the knowledge worker, yes. That's the approach taken by several enterprises that I've worked with.

  • First, chuck the term "knowledge worker." That appellation's a misnomer that's been around since the late 90's KM panacea du jour at the time and is a load of cr^p. Virtually every user I've ever known likes that menu-driven, turnkey interface that holds their hand the whole way.

    Second, the last two letters in that acronym stand for "modeling notation." BPMN being one way to model a process. I liken it to the UML, giving us more than one vantage point into a process or workflow. That function would be more associated with an analyst or architect, not a user or "knowledge worker."

  • With a little help, yes. BPMN can help knowledge workers to understand the gap, the goal and the change needed. However, if merely a BPMN model can do the ' implementation or migration trick' I doubt it.

  • People seem to be agreeing that BPMN is used to support "design time" activity by system designers and system architects. They are the only one "modeling" the work.

    Patrick: I am interested in what term you would use to replace "Knowledge worker". The origin of the term is really Peter Drucker's 1959 book on how some jobs require thought and expertise -- not simply manual labor. These jobs are fundamentally not-automatable. Perhaps you were thinking of a different definition of "knowledge worker"?

    I recently ran across a Gartner quote where they estimated that 25 percent of jobs in 2010 were 'non-routine'. By 2015 they expect 40 percent of an organization’s work will be ‘non-routine’. Non-routine skills are those we cannot automate.

    You have heard the phrase "change is the only thing you can count on". When considering the suitability of any kind of expression language, what is important is to consider how it supports unanticipated change.

    Not just change by the original developers. I have seen hundreds of programmers demonstrate that they can instantly change their programs in any way necessary. Such a demonstration depends on a tremendous amount of knowledge on the internal structures of the system -- something a programmer is likely to know, but not someone whose primary job is not programming.

    With knowledge work, change is not an exceptional activity. Changing the plan is precisely what a planner does. It is what a manger does. Languages like BPMN have been designed for precise and accurate automation of processes. It was not designed specifically to make it easy to change, nor was it designed to be transparent so that anyone can make a change safely and easily without any need to invest time studying the process in detail. These design points need consideration.

  • Who needs BPMN anyway?

    I agree with the fact that the work of a knowledge worker is not modelling processes, it is making decisions, treating patients, developing a training, solving problems etc.

    And probably their work can be modeled in BPMN style (at least afterwards), but what is the use of that?

    Sometimes it seems the whole world wants to model processes. Ever met a customer that was proud of you because you modeled your processes? No, they were happy because you helped them.

    And I am a great fan of engaging the real workers in executing, managing and improving the process, but I believe less and less that BPMN models in fancy tools in the cloud will help with that.

    I think English, Russian, Chinese and Spanish are better language for the knowledge workers.

  • It turns out process designers are knowledge workers too :) So BPMN is perfectly well suited to knowledge workers who are in the business of improving process.

    For those in the business of executing their own processes, BPMN may or may not be a good fit for them - but usually when this question is raised people are talking about Keith's favorite subset of processes - the unpredictable stuff. In which case, modeling won't be the best activity to engage in (regardless of the notation).

    As to Emiel's comment - modeling is a means to an end. Yes, I have had customers happy when we modeled their process in fancy tools - because in some cases they had difficulty articulating and understanding their own processes. We gave them the tools and understanding and insight to see into the processes that were actually happening (one customer referred to these as invisible factories... )

    However, in that case the "end" was to shed light on what's going on. In other cases the "end" is to improve the process, to achieve a result for customers, to achieve a financial or technical result - and modeling is just a step in the journey.


Add a Reply

Monthly Archives