Google wave received a lot of attention for its incorporation of real-time in email – which makes a lot of sense for  conversations and discussions among friends. Intuitively, it seemed a lot less valuable from an enterprise perspective. I was trying to figure out why when I came upon this paper by Erik Brynjolfsson from MIT. He was looking at the productivity of knowledge workers that used a database and email for thier work. Lots of interesting data in the paper but for me the bottom line is: “On average, workers using more asynchronous email and database tools handle substantially more projects simultaneously. In contrast, traditional synchronous communication modes such as phone calls correlate with less multitasking“. His research shows that multitasking is the key to knowledge worker productivity.

Bottom line, tools that make email a more effective multi-tasking tool for processes can have a big effect on knowledge worker productivity.

There is cute video on youtube showing an unstructured process in email (and how Lotus Connections could have been used to make things easier). Of course, ActionBase could have made things just as easy, but using Outlook and Sharepoint rather than Lotus. So if you use MS Outlook and Office instead of Lotus – just change the reference in the video from Lotus Connection to ActionBase – and voila! you have a cute video on using ActionBase for managing unstructured processes in email

I hadan interesting conversation with Gareth Herschel from Gartner about using ActionBase to link different CRM constituencies like a customer service call center and the sales force. They both have CRM systems to help manage their processes – but the systems (even if the are modules of the same vendor) are very different. The problem is that connecting these different constituencies can bring lots of benefit to the organization – but doing in a traditional way can be very expensive (e.g. providing the service center with access to an opportunity management system). For example, a customer calls in about service, but during the conversation a sales opportunity arises – in most case this is entered in the CRM system – but there is no way to get it out other then sophisticated techniques like text analysis and data mining.  McKinsey discussed the same issue a few years back “Most companies also lack a systematic way to pass leads and service requests from one channel or product group to another, leaving it up to dutiful employees to bridge those gaps by making an exceptional effort, such as that of the bank teller who jots down leads on pieces of paper and hands them to the private-banking team.”

That is where ActionBase comes in – enabling lightweight integration between the different groups. The first step is  enabling the service rep to send a quick ActionMail to a sales center email address with a link to the customer information (it could be as easy as sending it to sales@abc,com). The ActionMail would be forwarded to an appropriate sales rep who could follow up on the lead and (hopefully) make the sale. These leads would be managed, tracked and reported through ActionBase’s reporting mechanism and system of records. Voila a simple, cost effective way for your service center to  track the leads and revenue generated by their service reps.

In many ways this exemplifies the ease of using a human process management system to bridge between two structured processes (and to handle exceptions). Over time this could be modeled and made into a structured process – but rather than waiting – you can start iteratively designing your process immediately at very little cost, using tools people are familiar with.

BPMS are very good managing structured processes. But what happends once there is an exception? usually the BPMS sends out an email to the person in charge. But how do you track this ad hoc process to its completion?

Today I’d like to discuss how HPMS can be of help in these situtations

A:  An HPMS should support  both loose integration via email, and tight integration via web services.

Loose email Based Integration

Most BPMS and structured process engines (e.g. CRM) already have a mechanism to invoked an external human process via email. An HPMS should be able to intercept these emails (e.g. via a designated inbox) and use it in order to invoke an HPMS. The human process can then be monitored and managed via the HPMS. Once the invoked human process is complete an email response is sent back to system that initiated the human process. This mechanism requires no programming and should work for any structured process.

Web Services Integration

A tighter way to integrate and HPMS with a BPMS is via BPEL (Business Process Execution Language), which is a standard way to express business process behavior for web services. Most BPM systems support BPEL as an execution language. 

The easiest way to invoke (or kick-off) an HPMS process from BPEL is as a web service. An HPMS process can be invoked by the BPEL flow to handle long running human centric tasks as part of a business process, or as a mechanism for handling application (or service) faults in the flow. I am including a more technical overview in the next couple paragraphs for those interested.

An application fault happens when a service invoked by a BPEL flow is unable to complete its task. This can happen for a variety of reasons, but one common reason is that the content associated with the service invocation is inappropriate or wrong. The BPEL service then returns an error with one of the messages defined in the service WSDL (Web Services Definition Langauge). It is up to the BPEL flow to decide what to do with that. One way to handle these faults is by invoking an appropriate HPMS service for the long running process used to handle the exception. When invoking the service the BPEL should provide the fault message provided by the service that failed, and the input information that generated the fault. The BPEL flow will need to wait for a (timed) response from the HPMS service. The BPEL flow can then resume its normal flow with the new content obtained, or rethrow a fault for a catastrophic failure (or time-out).

An HPMS can also be invoked as a standard web service for handling long running human processes from BPEL. The BPEL flow can invoke the HPMS service as it would any web service. The invocation should(at a minimum) provide the HPMS services with a way to find the intended recipient (e.g. email address) that will handle the process and a priority, a start date, and a planned end date.

Here is why i think anyone who takes the time to write a meeting minutes document is practically wasting his/her time.
In general we take the time to put things in writing as a way of documenting the decisions, action items and agreements made in a meeting. The problem everyone faces is that two seconds and even before the digital ink dried on your meeting minutes paper things start to change.
Responsibilities, due dates, the nature of action items etc… that is the dynamic nature of people as they work together.
Writing a meeting minutes document is like taking a photo of a specific point in space-time and thinking that this is what is still going on right now…

As things change, people seldomly revisit the document and edit these changes, so the document becomes obsolete, a fossil of a meeting that once took place somewhere in time.

What we really need is a way of extracting these logical entities (decisions, action items etc) from the document and be able to work on them in a collaborative nature like email.
Think of a mechanism that allows you to define action items in a document, and when you are done, these action items are magically transferred to the relevant people and as they work on them, any response, change or collaborative information gathered is documented on the same action item.
Furthermore, the next time you open the document, the changes made in ‘real life’ are propagated back to the document so your ‘photo’ is actually a ‘video’ or a real time snap shot of the ever changing reality – these are actionable documents we call ActionDocs.

So we have established the idea that email clients are not cut out for managing day to day work.

Working with several people and managing action items can not be done through email. We need a new breed of email clients that are action item oriented. this type of email system will arrange information that is otherwise scattered across email messages and collate them into one single entity – the action item.

Imagine sending a request to three different people to hand out their report. With regular email you are bound to end up with minimum 3 emails and 3 attachments… and when you take into account, questions, clarification, scheduling and status updates you get a pile of email.

A task oriented email client will behave like a wiki document in the sense that once you send it out, any response, question or comment made by recipients or yourself, will all happen on the same email entry… all the relevant information under a single line item – THIS IS COLLABORATIVE EMAIL.

In ActionBase we call this email – ActionMail.

ActionMail is the next generation of work email which is task oriented rather than message oriented.

Email is SO 1.0 – and this is why we all suffer from email overload…

Let’s face, it – we abuse email into doing things it was never meant to do and this is why we face  over flooded mailboxes with no clear view on the things that matter the most.

Today’s email clients were designed for yesterday’s email. Originally, email was merely a communication medium. Today, we engage in a variety of complex behaviors using email, such as project management, collaboration, meeting scheduling, to-do tracking, etc.

There have been no thrilling innovations in email. GMail, Outlook 2007 both offer enhanced searching capabilities but the problem remains… and this is the reason why:

email clients think about “messages” – our minds think about “context”.

Context is the logical meaning which spans and transcends a specific email message or conversation thread. if i emailed someone requesting that they do something, the request or action item is the context, and this logical issue can span several email correspondence threads sometimes even across email accounts.

The next generation of mailing will have an ability to find the logical context and transform email clients to becoming context oriented and not message oriented.