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.

I believe, and I think that a lot of people would agree, that one of the key benefits of embarking on a business process project in any organization is the opportunity to understand and model existing and to-be processes in an organization. As far as I can tell that is the pervasive form of business process management – creating a model and understanding of processes (and using simple tools like Visio, various process modeling tools, paper and pencil).

The problem is that no matter how serious a company becomes in their modeling efforts – they will be only able to scratch the surface of the actual processes that make the business run. Since most processes are ad-hoc, unstructured human process and trying to model those would be difficult, and expensive. As an aside, I would claim that these human processes are the ones that matter most, since they truly are the processes that differentiate the business.

But lets imagine you could – lets imagine you could create a repository that contains an up to the minute description of all your processes, including your human process. It would be a goldmine! Like with data warehousing and BI which can give you enormous insight into how your business is doing – a process warehouse gives you the information on how the business actually gets its work done. Just imagine – data BI can show you where things are going well (or poorly), but process BI can give the insight into why they are going well (or poorly).

Of course to make this work you would need to be able to capture your processes, and store them in some appropriate format. Also, just like with data warehousing and BI – you need a lot of relevant process data for it provide true value, you need a way to store the data, and you need a way to access it.

I think emerging human process management technologies like Google Wave, ActionBase and Adaptive  Case Management tools are starting to provide the answers on how to gather enough information on these business process to make the analysis of these processes interesting and valuable – and that is the key to making a process repository work. It needs to have enough data. There are ways to store process instances in standard databases.  There are ways to data mine and visualize processes. So again the key is getting enough interesting process data.

So the pieces that are needed for creating and benefiting from a process repository are falling into place. Now as most of the process community is waking up to the role of unstructured, ad-hoc, human processes in organization – I think that we will start seeing more and more emphasis on process repositories – as a side effect of human process management. But the truth is – the side effect may be turn out to be  the key value from an organizational perspective.

I came upon a new term the other day – Social BPM (Neil Ward-Dutton’s presentation on “When BPM and Collboration Collide“). At least it was new to me. It  is the use of collaborative processes for BPM modelling. To be honest, I just don’t get it. Not that it isn’t a good idea or isn’t needed - it is, but why is BPM modeling considered a special one-of-a-kind process? Isn’t it is just another example of an unstructured, ad-hoc, collaborative, human process that needs be managed?

As I wrote in a previous post on SAP ’s Gravity - the fact that SAP needed to build a special tool, not using their own process technology for this process, just shows the limitation of existing BPM suites when it comes to managing unstructured, ad-hoc, human processes. BPM suites aren’t built for managing collaborative, ad-hoc, human processes and neither are wikis  (but combining the two makes things interesting, see my previous post on Combining Wiki and email).

So you would think the process folks, instead of building a bespoke tool would be trying to understand why the modeling process itself can’t be handled by BPM, and then try and figure out what to do in a general way. It is not that the BPM modeling process is inherently different then most other ad-hoc, unstructured, human processes in an organization – so I believe the focus should be on solving the general problem of managing ad-hoc, unstructured, human processes.

I had an interesting call with Lynda Ting from Microsoft last week about connectivity between email and SharePoint. After our call Lynda blogged that “ActionBase adds (to Sharepoint) the ability to have follow–up, tracking and process management associated with email.” This is a unique and important value proposition for customers. We enable them to take email correspondence and make it traceable. We consolidate discussions or conversations and their related actions. We also have the ability to add micro- messaging (like IM message), keeping all of these collaboration channels in context.

The context of a discussion is in many cases more important than any of its atomic elements. When you trace a discussion’s back and forth messages and see the documents related to it as well as all subsequent process activities, you create a view of one big web of social activity that encompasses the whole flow of the conversation, its context and all participants. It allows you to really trace where things are and who is doing what. By collating the whole process thread (like in IM  or Google Wave) we simplify collaboration and the way people share and view the same information in same context and the same discussion history.

Funny how all things get connected. I met  a very large Fortune 100 company last week. They work intensively in Office and SharePoint. We discussed our ability  to connect the dots between emails, and sites within SharePoint, to enable follow through on activities from within Word and Excel sheets. One of the folks there said to me that they have been searching for a long time for something that can be “the glue between email and other office tools”, collaborative applications and  workspaces.

He was referring to activities and conversations that start in email. Then you decide to create a Sharepoint site to link those discussions with their related documentation and have the team site to track the  follow up. ActionBase’s capability to provide one view of the flow that connects all those elements together within one context or process was a key feature for them. Most importantly the ability for everyone to be synced without duplicating items, and providing a single version of the truth was very appealing.

Meetings are a big part of the way business gets done. Like email – meetings are something that everyone loves to hate, but everyone does. Meetings, by their very definition, are a group activity – they are used to kick-off group activities, synch the group and assign new tasks, and summarize interim and final results.

So how can Sharepoint (or any wiki) help manage meetings? Currently it is easy enough to use most wikis (or Sharepoint) to set up a shared workspace for all the participants in the meeting, and have all of the relevant documents stored in the shared workspace. That is very useful as the prelimninary step in a meeting, to make sure everyone can do their homework before the meeting. During the meeting discussions are had – and hopefully, decisions are made and tasks assigned. If it is a formal meeting, minutes are taken – if not there (hopefully) is someone that took notes and wrote down action items. The question is then what?? You can put those “action documents” in the shared workspace – but those documents are passive documents that just sit there. You can translate those into task lists  and todo lists - but that doesn’t really make it part of everyones normal workflow – they too just sit there. In Sharepoint you could program a workflow for the tasks – but that is too expensive, especially since you only know the first step of each todo or task. So what usally happens is that an email summary is sent, and in too many cases the action items and follow-up just slowly die. No wonder so many meetings have such ineffective outcomes.

That is where ActionBase’s human process management together with Sharepoint (or a wiki) can make things much more effective. By making the meeting minutes document (in Word or PDF)  or summary email an action document (or a quick meeting if you want to do it directly in Outlook). You can now link that document directly with the processes they initiated – and track them from the document itself, the shared workspace and Outlook. By making it part of the participants usual  flow in Outlook, and providing a group view in Sharepoint – meetings results are visible, they can be actively tracked and managed. The ability to link decisions with their outcome can have a huge beneficial effect on operational effiency.

OK. So the definition I am using for BPM - ”Business Process Management (BPM) is the understanding, visibility and control of business processes, enabling them to be managed as strategic assets” covers a lot of ground, so there needs to be some way to scope what is in, and what is out of BPM. I found a nice post on BPM futures on Renewing BPM for the coming decade where he states that BPM (as opposed to just workflow) is where a workflow product includes deeply integrated workbenches for process modelling, simulation and analysis it is indeed BPM. I think I more or less buy that – BPM must have the capability to model, simulate and analyze business processes.

So that means the ability to model a process end-to-end (i.e. what I would call defining the process as a structured process) has to be part of a BPM implementation. That means by definition BPM (as the term is used today), can’t be used for unstructured, ad-hoc, human processes – since those process can’t be modelled (I would actually argue that very few processes that includes humans as part of the process can actually be completly modeled). So does a “good-enough” BPMS need to ability model?

My answer is “yes, but..”. Modelling is important (especially for structured processes), but not critical – there are other ways to provide visibilityand control.Google Wave doesn’t allow for modelling  in the BPMN sense, but on the other hand – it does provide for a mechanism called “robots”. One way to look at robots is as a way to model the actors in a process – so rather than models the flow (which is the focus of BPMN), Google Wave models the actors – and the flow is emergent. So on that account Google Wave can be a good enough BPM but with a very different mindset. If you need the modelling capabilities you could put the appropriate robots in place, and then you could simulate the process with synthetic actors. Currently Google Wave has no ability for analysis.

At ActionBase we allow for a simple model of a “recommended” flow through “process best practices” – it allow for the recommendation of next steps, but doesn’t require the participants in the business process to follow the best practice, they can do anything they think is appropriate as a next step, though the steps are tracked and visible. Tracking takes the place of modeling in the management of unstructured, ad-hoc human process – both for ActionBase and Google Wave – providing both control (in a social sense, not  programmatically dictated control) and visibility. ActionBase does provide a graphical view of process as it was executed, and stores the execution information in a standard SQL database for access and analysis. We have started to look at technologies for deeper analysis of those emergent processes.

The one thing that bothers me most about Enterprise 2.0 is that in certain circles it has taken on some aspects of a religion, rather than a pragmatic approach to solving certain business problems. They preach that Enterprise 2.0 tools (especially Wikis) will replace email – and of course everyones life will be be better. This doesn’t make any sense to me (nor does it make sense to Andrew McAffee – the inventor of the term Enterprise 2.0. In his blog he mentions trying to replace email is a bad idea).

The reason it doesn’t make an sense is because email and wiki are such complementary technologies, especially with respect to bringing visbility to the ad-hoc, unstructured, human processes in organizations. Emails and Wiki fulfill different requirements  the spectrum of technical tools need to support human processes in organizations. In trying to find what others are thinking around wikis and email I came across the following diagram that tries to explain why Wikis are superior to email:

The reason that I think it is a good picture is that it shows one use case where Wikis shine (and email sucks) - the collaborative editing of documents. I also think it is a good diagram because it shows that the collaboration folks don’t think in terms of the human process that includes the collaboration (and on the other hand the process folks forget about the collaborative side of processes). The drawbacks of email in this scenarios are:

1. Attachments can lead to confusion (which is the most up to date version)
2. No collaborative editing of documents (or docuement versioning)
3. Project related Emails are scattered throughout the inbox
4. Doesn’t have a history and tracking mechanism

but email isn’t all bad, even for this scenario. Assuming this part of a larger business process (e.g. contract management, audit), today’s Wikis are missing functionality too:

1. Opening side channels of communications,
2. Bringing outside people into the collaboration
3. Notification
4. Enabling sequence of steps as part a process.

That is why I think the answer is a combining of the two technologies (as Google has done with Wave and we have done in ActionBase, especially in ActionBase for Sharepoint). The new type of email (ActionMail or Wave) solves email problems 1,3,4 (a single verison of each attachment, a single email line item per process, an inline history and tracking mechanism). For the collaborative editing aspects – Google Wave leverages Google Docs, while we leverage Microsoft’s solution.

By combining the two metaphors – email and wiki – we can provide a solution to real business problems,  that either solution on its own can’t.