More Reports in from #BPM2012: Process Cloud
Keith Swenson had a great writeup of a session entitled “Managing & Tracing the Traversals of Process Clouds with Templates, Agendas and Artifacts”:
The concept “Open Process Clouds” has nothing to do with cloud computing, but rather parts of a process that can not be presented by a traditional process. They use a little cloud symbol in the process definition to denote the ambiguous, unpredictable behavior of what people do there. This is precisely what we have been talking about in ACM as an unpredictable process, but his terminology is a little different.
“many critical business processes lack a predefined process model, but depend upon the experience and expertise of case managers who work with large amounts of unstructured data to make decisions.”
This is a really interesting notation for capturing this idea as you can see from the diagram Keith captured:
Incidentally, when we’ve modeled this sort of thing in BPM suites, we’ve used a particular activity template to represent these “clouds” where we know the inputs, expected outputs, and potential boundary events but we either don’t know, don’t care, or can’t know the internals. For example, a meeting’s details don’t need to be modeled, but we can set an expectation of sending as inputs financial statements, attendees, agenda; and as outputs, meeting minutes, decisions, to-dos, commitments, etc.
Like Keith, I find the terminology to be straightforward to understand (Agenda, Templates).
Keith relates to this through an ACM lens, and I through a BPM lens, so we probably have some different takeaways but I’m glad he shared his notes as I think it is a really clear explanation of the concept. Keith summarizes:
I like this paper because it puts very good words around the issues that the ACM people have been talking about: important business activities can not be modeled and supported with a BPM approach. Instead of a process, they use a very simple concept of an “agenda” which can be modified by the case manager at any time. The focus needs to be more on artifacts, and less on task/process. This is clearly the right idea for knowledge worker cases.
I don’t share Keith’s view that this isn’t supported by BPM (in the diagram above, it sure looks like Volker Gruhn was presenting a BPM framework around a “process cloud”, and we’ve certainly represented similar processes with activities that could be best explained by Agenda and Outcome, we just didn’t use the cool cloud depiction). But intelligent human beings can disagree on things like this. The main point is that these words may be helpful in explaining the concept of how to frame a meeting or ambiguous activity in terms of its inputs and outputs and how it fits within a larger process context.
(In fact, I’ve made this point in previous blog posts and comment threads, that you want to model the inputs and outputs in BPM because BPM is what gives you the tools to manage for aggregate outcomes and correlations (macro), whereas providing a better “generate healing plan” process cloud implementation is more about an individual outcome (micro).)