A Process is only as Simple as it is

  • April 7, 2010
  • Scott
  • 8 Comments

Jacob Ukelson of ActionBase once again writes an intriguing post on complex business processes, referencing a Clay Shirky article on the collapse of complex business models.

Ironically, while I share Jacob’s optimism about the future of products like ActionBase, I don’t agree with some of the points he makes in his post even though they are in support of a conclusion we both agree on.  First, in areas of agreement: whether you call it case management or ad-hoc processes or knowledge work – software products are increasingly going to target what Phil Gilbert used to call “the 98% of the business that isn’t in IT”.  Different vendors will tackle this differently.  A few interesting examples:

  • ActionBase lets users create a process (and amend it) on the fly using Word, Excel, and Sharepoint to drive that process.  Several other vendors have been pushing “case management” or “adaptive case management”, and it looks like ActionBase is adopting some of this terminology in their positioning as well.
  • Lombardi (now part of IBM) created Blueprint to foster more participation in building and understanding process models (and not strictly BPMN process model views). Simultaneously Lombardi released products to integrate ad-hoc subprocesses leveraging Sharepoint (a common example is collecting interview feedback via Sharepoint, but collecting the final decision on follow-up steps in a structured process).  Several other “community” and “social” sites have cropped up since:  Alignspace,  Blueworks, Signavio, to name a few – each with different target audience from formal process modeling to more informal networking and sharing.

However, part of Jacob’s post I don’t find myself agreeing with.  Jacob makes the argument that BPM-targeted products are becoming more complex – by adding rules, simulation, event processing (and by adding to the modeling notation itself).  I’ll agree that the BPMN notation has evolved to become more complicated – and that is a concern – but mitigated by the fact that you aren’t required to use the most complicated elements to get the job done.

As Jacob notes, supporting rules, simulation, and complex (or even simple) event processing is valuable, but I think he overstates how much complexity is added by including these elements in a BPM offering.  For one, processes often leverage rules and events regardless of whether these features are integrated into the BPM offering.  For another, transparently supporting events and the way they interact with your processes actually reduces complexity of the software solution being built.  If you have a simple process that doesn’t require events, you don’t pay a complexity penalty for those features existing – but if you need to deal with events interacting with your process, then having a well-integrated event model actually helps quite a bit.  Finally, simulation is almost a completely separate function – it doesn’t complicate execution or building the executable model, but it does give analysts a way to model behavior before they go live.

An interesting example.  One of the things you often want from a process is to be able to report on what’s happening within the process, or to do analysis on the aggregate data.  If data tracking capabilities aren’t baked into the process software you use, then you’ll have to build the data tracking capabilities (and likely, the reporting capabilities).  But if the data tracking capability is built seamlessly into your process software, then you’re more likely to track the data you need, and at less expense and complexity (as measured by lines of code written, or by just about any other measure you choose).

I guess my point, with regard to complexity is this: a given process is easier to describe and translate to execution today than it was before these features were added to BPM suites, not harder.  Of course, with increased efficiency for previously mundane but time consuming tasks, the difficulty of problems being tackles is growing – but that’s just the way the software business works – the goal posts are always moving. There is an opportunity for BPM solutions to differentiate by providing a better overall experience- making sure the various parts that Jacob describes work together as “one” product rather than feeling like they were bolted on with duct tape and bailing wire.  Some product teams have done a better job than others in this respect… in part leading to the conclusion that BPM is “too hard” or “too complicated” by some, while others think BPM is the best thing since sliced bread (and all points inbetween).  A fair amount of this variance in perspective can be traced to early experiences with specific BPM suites.

I think it is healthy for ACM (adaptive case management) advocates to hash out what ACM truly is in their own discussions and forums (as WfMC has separated it from bPM), but I think ultimately organizations are going to see ACM as a necessary component of their Business Process Management initiatives, rather than something separate from their process initiatives.  Jacob is right – many of the BPM software vendors won’t “get” the unstructured world of ACM, until it has a chance to mature and coalesce around what the key features and benefits are.

Related Posts
  • November 15, 2018
  • Joe
  • 0 Comments

Editor's Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...

  • November 8, 2018
  • Larry
  • 0 Comments

[Editor’s note: This guest post is the ninth in a series from Larry Taber, BP3’s Digital Strategy Officer ...

  • November 6, 2018
  • Joe
  • 0 Comments

Editor's note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...