I have been doing an experiment lately. Whenever I talk to a group of people about Adaptive Case Management (or Human Process Management) with knowedge workers that are familiar with BPM  – I ask “How many people present use BPM or a system built on BPM for their everyday work?”. Everyone at these meetings is a knowledge worker and (some of them even develop BPM tools and systems) . Never has more than one person raised their hand. Then I ask who uses email and documents every day, and of course everyone raises their hand. If you ask them how many of them do structured, repeatable, routine work eveyday – then the usual answer is that is always a part of their job, but not what they are paid for.

I know this is kind of a stupid experiment, but it does point out (at least for me) the current state of tooling for most knowledge workers. They consider their work (at least the important part of it) as “Design by Doing” as Jim Sinur so nicely worded it in his blog. BPM as they understand it (and I’m sure that everyone understands it a bit differently – but I’ll guess the ability to model a process, most probably in BPMN, is part of what they think is involved in BPM) has nothing to do with their everday jobs.

Sure we could try and extend BPMS (the tool) to include the kind of work they do, perhaps even extend it enough to have it include email and document management systems (or is it that document management systems include BPMS, I get confused). But why should we? Most BPM systems have hooks that let the system invoke email (and so do document management systems) – but I would doubt most people would consider email as part of BPM. BPM and email are two separate systems which are sometime used in unison to solve a business problem – there is no need to pull them both under the same umbrella. I think the same is true of Wikis and other social technologies – they are useful tools – and there is no benefit pulling them under the BPM umbrella. So in the on going debate on ACM as part of BPM – I’m going to have to side with Keith and Max.

BPMS (the tool, not the approach) is for routine, predictable, structured work where people and documents may play a part – but are not central. ACM is for unpredictable, unstructured, ad-hoc work – where people and documents are central. The two are complementary, but not equivalent. To prove my point, I’ll go back to my old post - no one is building social BPMS tools using BPMS - not even the BPMS vendors.

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.

I read an interesting post by Howard Greenstein on “Google Wave’s Massive Potential for Business Users“. First off, I’m glad to see more and more people agreeing with the assesment that Google Wave is going to have a broad impact on business. Second, I thought I could use his taxonomies to show how ActionBase + SharePoint compares to Google Wave. His assessment of Google Wave’s benefit for business is based on it as a tool for facilitating project oriented communcations. We haven’t stressed that aspect of ActionBase lately, but that is one of the key usage paradigms in ActionBase. Many of our customers use Word (or an ActionMail QuickMeeting), and ActionMail to do complex project management. 

Howard uses Daniel Levi’s Group Dynamics for Teams to classify different types of project oriented group communication:

It is clear that ActionBase provides lots of benefits for the “Different Place” column allowing people to continue with their email paradigm but with an layer of management and control that didn’t exist before. What may surprise people is that we are also quite heavily used for Same Time, Same Place communication- leveraging Word as a way to capture meeting minutes and resulting required actions. In Office and Sharepoint 2010 MS will also provide the infrastructure for collaborative documents creating, which will make our tool even more powerful.Our integration with SharePoint also enables us to also provide complete support for the ”Same Time, Different Place” paradigm.

So if you use MS technology (Outlook, Office and Sharpoint) rather than Google (Wave and Docs), ActionBase+Sharepoint cansimply  give you the same functionality in your environment.

I am currently reading Thomas Davenport’s book “Thinking for a Living”. Though I had scanned sections of it before, this is the first time I am giving a thorough end-to-end reading. As I read it, I thought I would pick out the parts relevant for Human Process Management.  In chapter two he gives a classification of different types of knowledge intensive processes which I think does a good job of segmenting the standard tools available today for knowledge workers.

• Transaction Model – Here companies use either bespoke applications, with the rules embedded in the app (e.g. CRM), or use BPM to build the app
• Integration Model – that is where BPM is most valuable, and BPM focus today.
• Expert Model - Browsers, Document repositories and  personal productivity applications are the tools available.
• Collaboration Model – This is what Human Process Management addresses. These are the unstructured, ad-hoc processes that people do everyday in email and documents, where  the overall work product is dependent on groups of knowledge workers collaborating. The fact that email reigns king for knowledge worker collaboration and coordination is show in a different chart, with knowledge workers spending about 20% of their day in email (even though the data is about 5 years old, itstill holds).

SharePoint is a great tool for collaboration between people, or as Microsoft puts it “SharePoint is an enterprise information portal that can be configured to run Intranet, Extranet and Internet sites.  Microsoft Office SharePoint Server 2007 allows people, teams and expertise to connect and collaborate”.

The one piece that is missing from that description is the idea of business process – which I describe as the business context in which the documents exist and the collaboration takes place. Microsoft isn’t blind to this and in SharePoint 2010 is promoting “SharePoint Foundation 2010” which is a enhanced version of the current “Windows Workflow Foundation” to allow programmers to create workflows associated with a SharePoint site. Basing the process implementation on Windows Workflow Foundation has a number of problems from a technical perspective (requires programming, processes are limited to the boundaries of the SharePoint Site Collection and processes can’t be changed at runtime). This makes its OK for structured processes – but completely in appropriate for human processes – the ad-hoc, unstructured process that we manage here at ActionBase.

In my previous post I wrote that Microsoft’s approach to process surprised me since they own the business tools most associated with the execution of human processes – Outlook (email) and Office (Documents). SharePoint 2010 could have been the platform for the killer app for human process management – by linking unstructured processes and unstructured data, human collaboration and human processes.

Well here at ActionBase we decided to fill the void. By linking ActionBase and SharePoint, people can easily link together (within a SharePoint site) the documents and the processes related to those documents. “ActionBase for SharePoint” brings to SharePoint users and to the organization a whole set of advantages that radically increase the benefits and ROI of a SharePoint installation:

1. Documents stored in the site can be ActionDocs. That means that documents don’t need to be only passive – they can be used to initiate and track the processes related to them. The simplest way to think about this is “meeting minutes” – “ActionBase for SharePoint” allows the “meeting minutes” document to kick-off and monitor the processes and action items kicked-off at the meeting.
2. The activities of the group can now be managed. This doesn’t mean much if the site is a passive “read-only” portal, but that isn’t what SharePoint is about. It is about collaboration between people – and let’s face it, collaboration between people ALWAYS includes email. “ActionBase for SharePoint” links ActionMail and SharePoint – so the group can know the various activities taking place outside the site in email that provide the context for the site and its documents.
3. From an organizational standpoint, using “ActionBase for SharePoint” enables SharePoint to become the “system-of-record” not just of the documents – but of the context and activities that take place related to those documents. From a compliance standpoint this is huge. This means from a GRC perspective that Outlook + Office (the main GRC tools in most organizations) + SharePoint +ActionBase finally gives organizations a GRC tool that doesn’t require a new platform – or for people to change the way they usually do their work.

We truly believe that these advantages make “ActionBase for SharePoint” the killer extension to SharePoint.