I just read an interesting post by Irwin Lazar speculating about why Google purchased DocVerse. His take is that they want to use the DocVerse technology to get Google Wave into Office Documents.

I am not sure that is the reason they did it, but to me it sounds like a brilliant idea. Here at ActionBase we have been long time advocates of active documents (ActionDocs) that are not just passive objects in a process – but actually drive the process forward (for example have the checklist drive the process it describes) – and then have the process feedback into the document (e.g. checklist) on how a specific instance of the process is actually progressing.

If Google uses DocVerse to do this with Office and Wave – I think they will have made real progress in making Google Wave a real alternative to process oriented email in business, effectively making it an Adaptive Case Management system (and under the covers have Google be the  cloud based process warehouse and an alternative to SharePoint).

I was reading an article in the Economist (Data, data everywhere) about the growing abudance of digital data, and the problems caused by the need (desire?) to analyze all that data and extract usable information. That got me thinking about why the capture of the data in digital format (the data existed before, just no one was capturing it – sort of as the same issue as with the email filter problem) is causing so much angst. Then it hit me – the capture of this data is missing something- the context of the process involved in creating the data. The data captured after the fact is a jumble of direct information, symptoms and side-effects caused by the process of interest. So looking just at the data is the equivalent of doing forensic analysis of the aftermath of an unknown process – and trying to piece together the process (this is very hard to do, and what makes CSI such a compelling show to watch). If there was someone watching the actual events as they unfold (or the actual “murder” process) they could just say – this mess was caused by A shooting B and then running away – and understanding the resulting data (e.g. blood splats on the wall, shell casings on the floor) would be much simpler (and CSI would be a very boring show).

Of course, we can’t track the process for many kinds of data (e.g. a star exploding in astrophysics, or customer buying patterns in a physical store) – so we have no choice but looking at after the fact data and doing forensic analysis. But for any process that you can directly watch and provide the eyewitness view – the amount of data analysis needed goes down drastically, since the context is known.

Bottom line,  if we know the context – understanding the process becomes much easier, in many cases almost trivial. Not having an actual birds eye view of the existing process one of the key issues in trying to model actual business processes in any organization (especially since most interesting business processes involve human participants). Modeling a business process is similar to forensic analysis – finding the participants, interviewing them, looking for clues and artifacts, creating tentative models, simulation.  Hard, interesting work. Maybe we could create a show “Business Process Investigation”…

This is where adaptive case management (ACM)  tools can be invaluable – since they can start managing a process without a-priori modeling. But how do you get people to start using an ACM tool – since they would need change the way they do the process first – not something they would embrace. This is where doing ACM in existing email and document environments can really make a difference – users can remain in their regular environment – with the underlying process system-of-record proving the “eye-witness”  birds eye view of what actually takes place. Then if is there is still the need to model the process – it becomes much, much easier.

When we talk about managing unstructured, ad-hoc process (or using the adaptive case management terminology – knowledge process), one thing we always discuss is the notion of a best practice – which is a framework which describes a general outline of the work to be done (what needs to be done, not how to do it). In many cases we have seen these best practices boil down to a checklist (or a series of checklists).

Turns out that the lowly checklist is a very valuable tool for managing complex, unstructured ad-hoc processes in many domains. I was reading an excellent article on the benefits of checklists in unstructured processes from an old article in “The New Yorker“ by Atul Gawande, that was referred by Jon Udell’s blog post on “Atul Gawande on why heroes use checklists“.

Last week seemed to be the kickoff of a new area of process management – Adaptive Case Management. Yay – finally third party validation of ActionBase’s sweet spot. Interesting presentations by both Forrester (though they also use the term dynamic case management) and the WfMC (the slides and recording are available from their site – look for the link on their homepage). When I listened to the webinar – it seemed like they were giving the same pitch about unstructured, ad-hoc, emergent human processes that we give about HPM (and I write about in this blog) – so maybe the process management world is finally moving  in our direction…

A Business Process Management Suite (BPMS) is a great tool for creating software for the management of routine business processes. One question that arises quite frequently is what processes should be selected for a BPM initiative. I think some of the uncertainty is caused by the fact that you can look at almost anything done in business from a process perspective – and so could be a candidate for a BPM initiative. I have even seen forum question about whether BPM is the next generation of general purpose application development tools (just for the record – it isn’t).

Well, I don’t know the answer to what processes should be selected for a BPM initiative, but I can give some guidance into types of processes that should NOT be considered. Here is a checklist of some of the questions that can be used to rule out a process from being considered for a BPM initiative:

1. Does the process have a lot of ad-hoc, unpredictable activity associated with it (i.e does it change each time it is executed)?
2. Are there a lot of exceptions associated with process?
3. Is the process a people process that is heavily dependent on the skill and knowledge of the participants –do they need to be in charge of the flow? Is negotiation and discussion between participants a major part of the process?
4. Does the process require investigation and research?
5. Is the process generating and gathering (for the most part) unstructured data and content (i.e. documents)?
6. Does the process flow change based on the accumulated documents and content?

If you answered yes to one or more of these questions – you probably should look to a different process for your BPM initiative – the process you choose would lend itself better to Human Process Management (also starting to be called Adaptive Case Management by the WfMC, or Dynamic Case Management by Forrester).

I found an updated blog post (the original is from 2 years ago – just shows that the more things change, the more they remain the same) from David Allen of “Getting Things Done” called “The Problem is not Information Overload“. He makes a similar point as Clay Shirky, though using different terminology. His main point isn’t the fact that there is a lot of information available – but rather the fact that not all emails are equally important and the feeling of being overwhelmed is caused by “One simple reason: each one of those e-mails might mean something. “. The stress is caused by the need to determine which are actually important.

He is right about that – but that isn’t the whole problem. Another, related, problem is that business emails often are part of a long running unstructured human process and have a context to them – e.g. previous emails, documents – which need to be pieced together in to a coherent picture of the current state of the process. That is the second reason that people feel overwhelmed by email. As I wrote in my eariler post, business class email can help with the first issue – essentially defining a class of email (what we call ActionMail here at ActionBase) that really is important.

We address the second issue by making sure that all the emails and documents relevant to a specific process are linked together (Google Wave does something very similar) into a single process (or conversation ala Google). That is very different than just maintaining the request-response sequence of the email (which some email systems support) since the linkage is based on relevance as determined by the participants, rather then just request-response (which is only one factor in determining relevance). Doing it this way makes sure that all the information that the participants in the process think is relevant is linked together and shared by all – removing the second cause of the feelings of email overload.

I saw an interesting presentation on Why and How the Enterprise should Harness the Power of Google Wave in 2010  and interesting post on BPMRedux quoting Gartner that “about a fifth of business users are predicted to use social networking services rather than email as their primary vehicle for interpersonal communications” which means that in four 80% of business users will continue to use email as their primary vehicle of interpersonal communications. So it would seem Google Wave adoption for bs users is a long way off…

I actually think that Gartner is right – most business users will continue to use email as their primary business collaboration vehicle, but I predict email will be a very different animal  in just a few years. I think Google hit it right on the head when they started positioning Wave as the next generation of email – they understand the power of email as the entrenched business collaboration vehicle. They will leverage Gmail to get into the enterprise, and then morph email via Google Wave.

Google Wave for Gmail and ActionBase for Outlook are a natural progression of email for business users.

I watched an interesting lecture by Clay Shirky on information overload (Its not Information Overload, its Filter Failure), and quite a few of his points have meshed with what we have found at ActionBase. One of his points is that information overload has been with us for a long time – as a term it has been around for around 20 years, and for hundreds of years there has been more information free available then a person could manage. What has changed is the social based filtering systems that help alleviate the problem of information overload no longer work.

Using his argument – much of email overload is a social system design problem – there effectively no cost to sending an email (as opposed to the cost of say, printing a memo and sending it) so there is very little thought at the source about whether to  send an email or not. Especially, which has an economic incentive to pepper people with useless email (though there are technical solution helping with that). But what about the rest of  you email, the ones that aren’t spam, but aren’t critically important?

ActionBase helps alleviate the email overload issue by creating a different class of email called “ActionMail”.  Even though it is as easy to do as regular email (and you use the same tools), it actully has social mechanisms that helps with filtering at the source – ActionMail remains in the senders inbox until the process is complete, and the resulting email conversations are tracked. Those two additional features utilize normal human social systems to ensure that ActionMails aren’t just more spam, but indicate that the source (the initiator of the ActionMail) has done some filtering and has decided that this email is actualy somethingof import that shouldn’t be ignored.

By dividing everyday email into two classes (regular email and ActionMail) with similar but slightly different social paradigms, ActionBase ensures that your ActionBox is short and to the point, containing business email that really requires your attention, alleviating the problem of email overload.

That in a nutshell what Human Process Management is – a way to solve the issues with human processes that are done today  using regular email and documents (issues such as information overload, followup,  tracking, visibility), while allowing users to remain in their familiar email and document environment.

I was reading an article on model based development in the February Communications of the ACM (Software Model Checking Takes Off by Steven P. Miller, Michael W. Whalen and Darren D. Cofer). Model based development (MBD) is the use of  domain-specific, graphical   modeling   languages   that can  be  executed  and  analyzed  before a actual  application is  built.  This allows developers to create a model of the application, execute it on their desktops, analyze  it  with  automated  tools,  and  use it  to  automatically  generate  code  and test cases.

Now if you take that definition with business as the domain, and BPMN as the modeling language – you pretty much get what many people think of as a BPMS (or at least what a BPMS should be). Now if you look at the state of what is feasible based on the technical literature vs. what most BPM vendors claim for their tools using standard modeling techniques (e.g. automatically convert from model to running code with no need to program, complete round trip between executable and model, the ability to model, simulate and execute even the most complex business process) you have to come to one of the following conclusions:

1. The state of the art in Business Process Modeling is far beyond the state of the art in modeling of every other domain.
2. Business processes are trivial compared to what needs to be modeled in any other domain
3. BPM suites are useful frameworks and tools to help with the modeling of business processes, and they also provide a framework of support for developers to translate the model to an executable language – but don’t expect them to truly bridge the gap between a model and the application that implements the process  - unless you have really simple process.

I don’t believe 1 is true – I haven’t seen any technical breakthroughs in the literature that are specific to business as a modeling domain. With respect to 2, I know business processes are quite complex – and they are used to manage complex, dynamic systems. I also know that the broader, more complex and more dynamic the domain– the less possibility there is to model the system as a whole. You can model parts of the system – but not the whole end-to-end system.

I am starting to see a lot of BPM vendors jump on the unstructured, ad-hoc business process bandwagon. That is good, since it validates the value of being able to manage these processes, but since there is no standard terminology to discuss this issue, it is difficult to understand who does exactly what. Hopefully WfMC’s work on Adaptive Case Management will help with the appropriate definitions and descriptions.

I think the key lies in whether the existence of a predefined process model is a cardinal requirement. BPM requires a process model as a starting point for process definition. Without a model – you can implement a process – but it isn’t BPM. Various flavors of BPM extend the notion of what can be expressed in the model (e.g. dynamic BPM allows models to be extended by rules), but they all require a model as a first step. For most BPM suites the more rigorous the model the better – since it allows the model to be executable.

Now to define the simplest basic requirement for handling unstructured processes –enabling processes with emergent models – i.e. the participants are building up the models as they execute process instances (perhaps with some loosely defined guideline or best practice as a starting point). I will claim the ability to do that is at odds with the basic definition of BPM, since it precludes a model based approach.

Let’s say you want to use a BPMS for an emergent process. So first you need to either:

1. Build a trivial generic model, but then engine wouldn’t be able to do much and it wouldn’t be much help to the participants. Anyway, trivial examples aren’t of much interest in a real world business environment.
2. Build an outline of a process, but allowing every step to be optional and have an associated exception point – again as an executable model it wouldn’t be worth much.
3. Build a detailed model (including rules) capturing as many variations on the process that make sense. Of course this makes the modeling process VERY complex but I think most BPM suites would claim this is the way to go. In any case it still won’t work for emergent processes.

Let’s assume we go with option 3 above – the process is modeled as best as possible, including all the known variations.  But since it is modeling an emergent process, by definition we won’t have modeled all possible paths for the process and the participants will need to change the process during execution. The ways they have for doing that are:

1. The participants change the general model (either the model or the rules) – this is very dangerous, and the more rigorous and complex the model the greater the chance to screw up something big time. It also doesn’t make sense since this really might be a one-off execution.
2. The participants have their own “local” copy of the process and they modify that. Still would be a lot of work for the participants, but there would also be all kinds of issues of multiple models existing for the “same” process – how to reconcile the changes, how do you store and access variants on a given model etc.
3. The participants do things “outside” the existing  model.
   1. It is outside the model, but under the control of the BPM engine.  This requires a whole set of new capabilities for the engine. The engine will need to be something much different than a standard BPM (BPEL or BPMN) execution engine. The engine will need to become something VERY different (I would think encompass something much closer to a collaboration tool) – and then of course figure out how to reconcile that back into the original process. It opens a whole can of worms from an execution perspective – and it certainly isn’t anything like BPM today.
   2. It is outside the model, and not under the control of the BPM. If this happens all the time then the model is not worth much, and neither is the engine.  So why start with the model at all?

So a key aspect in using BPM for managing a process is the ability to model the process (and manage that model) in a cost effective way. Unstructured, ad-hoc human processes can’t be modeled (or at least in any cost effective way) so current BPM tools can’t really handle them. Managing human processes requires a different, complementary set of technologies – and a different mindset.