A Process is only as Simple as it is

Scott Francis
Next Post
Previous Post
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.
  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Complex Business Models (or Processes?) -- Topsy.com()

  • If we really want to change the world via managed processes, then we need to get as many processes managed as we possibly can…

    There are two parts to achieving this goal:
    – Tools that make managing simple processes simpler
    – Teaching people how to simplify their processes

    I worry when people insist that their processes are “really really” complex – and I worry even more when the tool vendors cater to this notion. “You want to build an unpredictable and infinitely customizable process?” – “Have we got the tool for you!”

  • sfrancis

    John –
    I agree with what you just said there. I think if done right, adding features and integrating them seamlessly with a BPM suite addresses the first point for non-simple processes: making managing those processes simpler (as compared to managing those processes with bespoke integration between many different process-supporting technologies).

    Of course, I think there's a great market for making simple processes “simpler” to manage (or make). ACM (and ActionBase itself) are really good examples of this.

    What I worry about is when people insist that BPM (or BPMN) unnecessarily makes processes complex – if the process is complex it isn't because of the tooling, its because of the process. (An exception to this is when there is a serious impedance matching problem between the tooling and the process, but I don't think that's typically the issue with BPM).

  • Scott,
    Glad we agree on most of the points;)

    The growing complexity of BPM suites is a benefit for IT staff – it is now easier to implement complex structured processes, but the downside is that BPM suites are now a developers tool – not a business tool. So I guess the questions are – Who are the intended users of BPMS technology? Who owns the processes that are created?

    It seems clear that many BPM suites are going down the road of middleware – becoming a platform enabling a sophisticated IT staff to create better business process solutions more quickly – which means that IT is in charge of managing, maintaining and evolving those process and making IT the defacto owner of the process.

    Though that wasn't the original promise of BPM suites (they were hoping to enable business people to build and own processes themselves), it does makes sense for the automation of complex structured enterprise processes – but opens the door for new lighterweight, good-enough tools for other processes (either not as complex, or not as automated).

    I am hoping that ACM will enable “good enough” process management for simpler, non-automated (i.e. human) processes-enabling business people to own, manage and modify those process themselves.

  • sfrancis

    Jacob-
    Great response, I really appreciate it, and I agree with your goals for ACM. Its a space that several technologies have tried to address, so far falling short of the right balance between capability and simplicity (in my humble opinion), to address the processes you describe.

    While I don't see traditional BPM suite deployments, properly managed, going the middleware route, if you hand software to middleware IT guys… guess what they'll do with it :) The risk you describe for BPM suites is real.

    It really requires different thought process and method for deployment to get the right collaboration between IT and Business to get processes deployed with BPM Suites. This is the same collaboration that should exist for ANY IT project, but BPM suites at least make it possible for them to communicate more clearly.

  • Pingback: BPM Quotes of the week « Adam Deane()

  • tom_shepherd

    Scott / Jacob,

    The concerning comment for me in this conversation is “I am hoping that ACM will enable 'good enough' process management for simpler, non-automated (i.e. human) processes-enabling business people to own, manage and modify those process themselves.”

    ACM isn't about dealing with simple processes, quite the opposite actually. I believe that ACM should enable support for the most complex processes, those which are often impractical to model / capture in a traditional BPM suite.

    When I say this, I'm not thinking theoretically, rather looking at this from a point of view of what is practical. There are business scenarios where it is simply infeasible to predict and therefore predefine, all the possible choices and outcomes of a given process. If you want to read an objective example of this, take a look at the comments section on the following post: http://www.tomshepherd.net/?p=118

    Scott, you raise a very good point on the separation and distinction of ACM from BPM by certain ACM advocates, which I'd like to explore a bit. From my experience, most BPMS vendors are not typically able to support Adaptive Case Management. Sure, many add case folders and task lists and some level of collaborative tasks (like your example of an “out” to sharepoint within Lombardi). In the end though, the structured process is the coordinating object. In ACM, the case itself can be (and typically is) the coordinating object, and lives on after the process has ended. Think of it as an inversion of the work item / process instance and the case folder.

    Back to the separation of ACM and BPM at a functional level, I don't believe that the two have to be separate and independent. My feeling is that you need structured process within the constructs of ACM to deal with the more structured case management problems, and to bring repeatability to some of the more routine aspects of knowledge work. After all, very few scenarios are truly 100% unstructured / non-repeatable.

    One of the other topics that I've raised recently is that Case Management solutions and a Case Management approach are not one and the same, much as there is a distinction between BPM and BPMS. Which is why I'll agree with you and say that most organizations will want the benefits brought by both ACM and BPMS, although time will tell whether we'll see it called BPM or something else (doesn't really matter to me).

  • sfrancis

    Tom –

    Agreed w/ your comments about Case Management (approach) and Case Management (software). Regarding the BPM/ACM separation, I think the tools need to adapt to allow either a structured process to drive more ad-hoc (case management oriented) subprocesses, or to allow ACM to drive more structured subprocesses (pieces of a more flexible whole). Clearly the best answer is for the tools to handle both well. This isn't too dis-similar to arguments between BPM and SOA – which one is the tail and which one is the dog, so to speak :) I'm not sure that it matters vis-a-vis ACM and BPMS – but ideally you want support for both.

    Tom, funny enough, coming back to this and reading my own earlier comment I found I need to offer clarification to the comment that “if a process is complex it isn't the tooling that makes it so” – of course, the caveat to that is that the “best-fit” tooling for a particular problem yield simpler solutions (don't add complexity, or abstract complexity in useful ways) than tooling that isn't a best-fit. So while BPMN doesn't “create” complexity, I think other approaches (JJ's resource based modeling, or ACM, or even rules) will offer best-fit for other situations. I think Jacob's point is that his own product line is geared toward allowing the business to own their own process definitions and execution (good enough for simpler processes). Because these processes won't be highly defined ahead of time, they'll look “simple” ahead of time, though the actual execution path, and the software to make that work, may actually be quite complex. I think clearly ActionBase fits case management use cases – but I leave it to Jacob and/or you to say whether it fits the definition of ACM (or even, more precisely, what the definition of ACM should be vs. Case Management)…