Context can Simplify Your Process

  • August 22, 2011
  • Scott

John Reynolds wrote a post recently about Interdependent tasks, and the resulting complexity. John takes a simple example, the vacation approval process, and then points out what makes the difference between a cute model and a real implementation:

Sam can’t really (in good conscience) make a Decision about any Vacation Request in isolation.  Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests.  To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.

And further:

Examples like these are what makes implementing “real world” processes hard.  Processes seldom execute in a vacuum, and work done within one instance often influences other instances.  Participants often have to consider multiple Tasks together, rather than performing each task in isolation.

He’s right, of course.  This is why a demonstration of a BPM solution can look easy, but the actual implementation actually takes real work and thought.

John purposely held back from suggesting a clever BPMN modeling solution or other trick of the trade to give us something to think about. I’ll give you my thoughts on how to approach the problem.   But in a general sense, this falls back into a general process pattern:

  • a process model that does a decent job of representing one process “instance”.
  • another process that manages the set of all processes
  • yet another process that is the maintenance and improvement of the process definition and the management of process instances collectively.

What John is describing is a variation on the second level of process.  It already goes without saying that we need to manage a set of vacation requests collectively.  The extra wrinkle is that at a step in the approval process, the process should present context to the user, that likely includes:

  • All pending and approved vacation requests for other team members
  • Possibly other pending and approved vacation requests for people on other teams
  • Remaining vacation days for this person
  • Remaining days in the year in which to use those days
  • Time since last vacation

All of this information gives the Approver context in which to make the decision.  The individual process’ execution flow hasn’t gotten more complicated. But the implementation details of that Approve step got more interesting.  Luckily, the information above will be pretty easy to provide if your BPMS had reasonable tracking and introspection capabilities.  So if we simply invest some trust in our user, and supply them with the information they need to make a decision, we’ll get really good outcomes with minimum implementation headaches.

Sometimes the really interesting bits in a process implementation aren’t in the BPMN.  As John points out, we shouldn’t assume that every detail should be captured in a BPMN model.

Related Posts
  • July 16, 2018
  • Ariana

Driven 2018 is coming up quick and we wanted to share some of our most anticipated sessions with you. You can ...

  • July 15, 2018
  • Scott

From nearly the first year I began writing this blog on behalf of BP3, pundits and commentators have predicted...

  • July 9, 2018
  • Ariana

We are excited to announce Automation Anywhere will be sponsoring Driven 2018. Automation Anywhere will be...

  • Scott

    It’s a rare case when I must disagree with you.

    The vacation process is a perfect fit for the “Resource Planning” pattern, Vacation requests and vacation planning are two separate workflows. Planning is started periodically; it collects all queued requests and present them for the human to make decisions about each taking into account the workforce interdependancies. When decisions are made, appropriate messages are sent to request process instances that awaite them.

    You wrote: “…at a step in the approval process, the process should present context to the user, that likely includes: All pending and approved vacation requests for other team members…” – The point is that it’s not a step of the approval (request) process but a separate process.

    “we shouldn’t assume that every detail should be captured in a BPMN model.” – Generally speaking, yes. But for this particular case BPMN is an excellent fit.

    • Anatoly, certainly you could use the Resource Planning pattern, and it
      is a good technical fit.  However, it isn’t the only good way to solve
      the vacation planning problem – especially if the # of requests is small – because generally one person isn’t
      approving 100 people’s vacations – just a small team, and likely only seeing one or two requests in a given timeframe.  But at the same
      time, as they approve that small team, they need bigger picture
      context…  Perhaps I approach this particular problem with my own
      firm’s assumptions in mind because I approve vacations for my team, and
      it isn’t so big that I would need a centralized resource planning process yet 😉

      If the # of approvals is large, and likely to have lots of concurrent
      requests for someone to approve- or needs to go to centralized approval
      as well (HR for example)- then the Resource Planning pattern is a
      perfect fit – because it will scale to a large # of requests without
      process redesign, and it will be straightforward to present a UI that
      allows for multiple approve/deny responses in one execution. 

      Whether that step is in the “Vacation approval” process or in the
      “Resource Planning” pattern’s separate process, it will need to present
      context to the USER to make a good decision, and modeling the outcome of
      that decision is actually pretty simple.

      I don’t think we disagree on this as much as you probably thought at
      first-  I just didn’t spell out my assumptions as I read John’s original
      scenario, and took the approach of a small change to the implicit
      process rather than the more interesting conceptual change that Resource
      Planning pattern would offer.  I should definitely spell out the assumptions when talking about design trade-offs!