In recent posts I have been considering what sort of software is required to properly and securely support human collaborative work - and giving examples of situations in which current tools and techniques fall down.  Here's one with which we are all familiar, yet which is in fact completely inappropriate in any real sense: the use of email to conduct a "business interaction": a conversation, dialogue, discussion, negotiation or any other set of inter-related work communications.

Email must be far and away the most common of all Internet business tools, more so even than the Web.  Not every company offers a transactional Web site, or uses such sites to do its own business.  But they all provide their employees with email and expect them to use it.  It is surprising, then, that when you actually start to think about it, that email turns out to be incredibly ill-suited to business use.

For a start, email is dreadfully insecure.  Some companies provide their employees with secure messaging services, but many more don't.  In general, emails are plain text communications that can be read by any intermediary as they travel across the Internet.  Further, you don't even know who is reading the email once it gets to its destination - it could be the person you address it to, or it could be their PA, or someone else who they have asked to check their email while they are out of the office.  It could also be an IT staff member with privileged access to the email system, or any superuser charged with maintaining it.

Email has in fact many technical security problems with falsified headers, corrupted attachments, and so on.  But let's put the insecurity of email aside, since it is such a huge and obvious problem - and look at some of its more subtle and interesting problems - ones that are business-related rather than technical.

First, there is tone.  In the early days of the Internet, its users recognized that email brought with it problems of emotional content.  Basically, when you write something you do so with an attitude - which may be anything from humorous to gently reprimanding to insistent to deferential.  The trouble is, the person reading it doesn't always interpret your message in the same way you meant it.  It is very easy to mistake the emotional content of an email, which is why early Internet users developed a concept of "netiquette" - a set of practices that enabled parties to a discussion to make their intent clear in terms both of logical and of emotional content.  These days, however, the use of email has spread and netiquette has vanished.  I've seen many an email discussion that would have been cordial if carried out in person deterioriate as the people concerned misread the tone of messages from each other.  And this can have serious business impact.

Second, there is involvement.  The people engaged in an email interaction tend to change as the conversation progresses.  Often people are CCed by one respondent but not by another - sometimes deliberately, other times just because a party presses "Reply" instead of "Reply All" by accident.  This gives rise to all sorts of thorny problems, not just of politics and wounded feelings, but very practical things such as people expecting someone to know (and act on) something that they were in fact never informed of.

Third, there is sequencing.  People tend to work through their inboxes in date order - oldest first.  So how many times have you replied to an email, promising certain actions, then realized there was a later email (perhaps not even from the same person) which renders your response inappropriate or even unnecessary?  To avoid this problem, I try to consciously force myself not to reply to anyone at all until I've read all my emails, which is a tiring and unnatural way to work.  Effectively, you end up reading everything twice, since once you've worked through your inbox once you have to start all over again - and hope that another email doesn't arrive while you're doing so!

Fourth, there is filing.  How do you file your emails?  Myself, I try to put them in folders, organized logically, but often the subject matter of the folders.overlaps.  Do you put a message from a consultancy client about a technical issue under "consultancy" or under "technical"?  Do you keep each client's email in a separate folder or organize it by "type" in some way?  Not only do such filing strategies rarely work as you would like, but they are also incredibly laborious.  It takes ages to set up and maintain the rules that assign messages to folders, and even then you end up doing some by hand as most email systems file incoming but not outgoing email.  One solution is just to leave everything in a default inbox and rely on search tools, but then what do you search on?  Every email has different keywords.  We're into the rarefied domain of what is called "latent semantic analysis" - and all we need is to store our interactions with people in a sensible way!

Fifth, there is the biggest problem of all.

Email is so easy to use that it's easy to overlook how for many people it is more of a problem than a convenience.  In a corporate environment, it is not unusual to receive hundreds of  emails per day, which both reduces productivity and increases stress. As they say, for some people email gets in the way of their work - and for the rest, email is their work.

Why do we all get so many emails, more than we can reasonably be expected to deal with? Because we never get the chance to specify exactly the messages we are willing to receive.

For example, many people routinely "CC the whole world" as a means of dealing with an issue that crops up - partly since it is easier than working out who exactly needs to know about the issue, and partly to cover their own backs. And the impact of this very common practice is enormous. Faced with an inbox full of such blanket postings, you are nevertheless forced to read each one carefully, since you can never be sure that the one message you skim, or skip entirely, is the one that raises a business problem for which you will later be held responsible. Far from increasing co-operation amongst colleagues, unrestrained messaging not only reduces productivity but also fosters a culture in which people are encouraged to offload issues onto others - rather than a culture in which people are motivated to personally ensure solutions

Similarly, when someone has a question that needs answering, the general assumption in a modern workplace is that one can just fire off an email to get the information required. No matter that the recipient(s) may already be drowning in work, or may not be the best people to ask anyway - simply by receiving an email, they each take on the responsibility to respond, even if it is only with a suggestion that someone else would be better placed to help out.

TAKE AWAY

The underlying problem with email is that people are rarely clear about who they are working with, and on what, or who is the best person to approach in a given situation. There is no clear visibility of shared and individual goals and responsibilities, so people deal with things in a variety of unpredictable ways.  For instance, they may spread the net as wide as possible, and include anyone that could possibly have a tangential interest - with the result that everyone's workload increases, general efficiency drops, and stress levels rise.

The only way forward is to provide a simple means for people to declare what exactly they are interested in, and what exactly they are responsible for - i.e., software tools that facilitate a more intelligent form of human collaboration.  Email does not provide this, and is never going to provide this.  It is a low-level protocol that should underpin more business-oriented tools for human collaboration.

And once we get such tools, perhaps we'll be able to get more work done, with less stress - and still get home in time to see the kids.

Posted by keithhb in Business Process Management • Internet • Knowledge Management • Management • Office Applications • Security | Permalink | Comments (4)

In recent posts I have been looking at the issues, particularly of security, facing people who try to put support in place for human collaboration that crosses organizational boundaries.  In particular, though it is now widely accepted that a process-based approach is essential for structuring and managing work, existing workflow and BPM tools fall down when it comes to cross-organizational work activities.  And the underlying problem is that no one organization "owns" the process.

Standard process support tools assume that somewhere, there is a server hosting each "process instance".  In other words, the process itself is like a program, with which the human process participants interact, and which does a certain amount of work on its own to support them (typically carrying out automatable activities such as database updates or Web service invocation).  But when you have multiple organizations involved, each with their own systems, and more importantly, each with their own management responsibilities, where is this program going to "live"?

In some cases, one party to the process has enough leverage to lay claim to being the host - consider a large manufacturer, for instance, who may insist that smaller suppliers hook into its own systems if they want the business.  The manufacturer may not truly own the process, but they can force everyone else to act as though they do.  In other cases, however, no one party has such power, and all parties must work together in some more equable way.

This is the domain of what is called "choreography" - the definition of an overarching "public process", to which all parties sign up, and which includes a description of the interactions between parties but no detail of how the supporting back end activities will be carried out by each party.  However, choreography is very limited in scope at present.  Part of the problem is that current choreography techniques possess neither a standardized graphical notation that would permit the parties to visualize a process nor a standardized means of arriving at agreement on a process definition (though I have proposed the techniques of Human Interaction Management to fill both these gaps).  But this is by no means the whole problem.

A more significant issue is that choreography is about defining programs.  A process created using the techniques of, for instance, the W3C choreography language WS-CDL, is essentially a quite basic set of control flow structures (each party's role being defined like a procedural program), that interact at key points in precisely defined ways.  This is never going to capture the reality of human collaborative work, is it!  People work in flexible, innovative, adaptive ways that are totally unsuited to such descriptive techniques.  In particular, a large part of what people do when they work together is to discuss, periodically, what they are going to do from now on - in other words, they redefine the process itself on a regular basis.  This goes entirely contrary to the principles of process choreography - at least as currently supported by the IT industry.  At present, those tools that exist for choreography require you to go through an old-fashioned "design, code, test, deploy" cycle in order to implement something, and then expect you to leave it well alone for as long as possible.

The reality of how poorly the IT industry is doing in this respect is illustrated by problems facing those parts of the public sector responsible for maintaining law and order.  A typical case may well involve police forces, social services, legal bodies, educational institutions, mental healthcare, hospital services, and more.  How are the people in all these organizations supposed to collaborate using "programmatic" tools?  Apart from the rigidity of the processes that can be defined in such tools, which is no use at all in such a situation, each person works under quite specific constraints regarding, for instance, data protection.  There are complex rules regarding what information can be shared and with whom - rules which if broken have serious consequences.

Further, the people who work in such fields are chosen for their ability to judge a situation and develop an appropriate response on the fly.  They are not expected to work from a procedure manual, and would be failing if they did so.  Being expected to comply with rules is not the same as being expected to work to rule!

TAKE AWAY

So what is the solution?  Clearly we need process support tools that are not only more adaptive, but that also allow the process instance to be spread across multiple machines.  Further, such tools must provide facilities for the people involved to define precisely what information they wish to share with others, who will receive it, when they will receive it, and under what conditions.

This latter facility can only be implemented by appreciating that keeping information confidential is not the same as concealing ownership of information.  A social worker may not be able to make the contents of a case file available to the police, but they would not wish to hide the fact that they have such a case file.  A process definition needs to support the definition of information, and sharing of that definition, without necessarily making the information itself available to all parties.

I will be discussing these ideas again in future blog entries.  And if you are interested in an implementation of these principles for support of collaborative processes, free enterprise-grade software will be available soon (and you are welcome to sign up for pre-release trial if you wish).

In the meantime, anyone responsible for managing cross-organizational work processes should at least be aware of these issues.  Anyone who has tried to use current workflow/BPM tools to support cross-organizational human work activities will tell you that it is a very painful, expensive, and unrewarding experience.

Posted by keithhb in Business Process Management • Management • Security | Permalink | Comments (0)

This time I will try and illustrate the proposed approach - process-based tools that are hosted on clients rather than on centralized servers - by means of an example.  And as so often happens, the perfect example dropped into my lap only recently.

Have you ever been driven into a perfect storm of rage by customer "service" from a supplier?  I try to take the long view and stay calm in most situations, but got pretty close to the edge when trying to sort out my personal broadband service during the last few days.  Over a year ago, I signed up for what was, at the time, in the UK, a fast business-grade connection, from the supplier I have used for well over a decade now.  The 12 month lock-in on the contract is now over - and since the company is currently offering a price of about half what I agreed to pay originally, I tried to contact them to sort the matter out.  This is where matters went horribly wrong, the only silver lining (to my raised blood pressure) being that the story is usefully instructive for our purposes here.

As background, the company concerned was one of the first UK ISPs.  In its early days, 1992 onwards, it was a very friendly, knowledgeable outfit with a technically-literate customer base.  The company managed its growth well, and grew rapidly, to the point where at one stage 2% of UK phone calls were to its dial-up service.  Then, after 6 years, they were bought out.  And everything changed.  In particular, the customer service effectively vanished overnight.

Before takeover, even at the height of their popularity, you used to ring their office building in suburban London, and speak to a permanent employee.  It was not unusual to speak to the same person on multiple occasions, and the person you spoke to would be the one that dealt with your case.  Now, if you email them or use their Web site to submit a support request, you are lucky if you get an automated acknowledgement, and even that won't be for a while.  If you dare to ring, on the other hand, you get forwarded from one person to another in a never-ending chain - 6 is not unusual, often not even being transferred, but having to hang up and redial - and at each stage, you must repeat your name, confirm your identity via a sequence of questions, then explain your situation all over again.  At the end of going through this sequence 3 times, all I got each time was a promise of a callback.  And none of these callbacks ever materialized.

What is the root cause of this appalling behaviour?

If we compare the current situation to the early days of this company, and make an analogy with computer systems, at the start a customer like me had what we can think of as a "channel" to the supplier (like a persistent open socket, if you are technically minded).  I could ring them, and know who I was contacting - even where the person was located. This was long before the days of calls being recorded, but the person I spoke to would take responsibility for sorting the matter out, would ring me back once they had done so, and - crucially - if I then got further problems, I could ring the person concerned on their direct line.  I never had to re-explain anything, and always knew exactly how to contact them if necessary.

Effectively, customer and supplier built and shared a "process context" - a mini-workspace, in which lived certain data and activities.  Data included my account details and any problems or issues I was facing, along with any relevant information provided by the supplier.  Activities included efforts on my side to supply additional information or carry out tests, and on their side to sort things out in various ways.

All this was accomplished informally, of course.  They may have used some kind of CRM system, but if so, I was never aware of it in any way.  What I was aware of, to my delight as a satisfied customer, was that we knew each other - "knew" in the very specific sense of understanding that we were engaged in a collaboration, and of what that collaboration consisted.  We were participants in a shared process, participants who had signed up to be involved, had agreed on the nature of the process in question, and each did their bit to ensure the process was carried out successfully.

TAKE AWAY

The functionality required to provide effective customer support is very different from CRM.  Some CRM systems may include the ability to document specific issues raised by a customer, and the actions taken on both sides, but such systems offer no ongoing means to manage that process.  And current Business Process Management or workflow products do not provide sufficient flexibility to support the full range of issues raised by customers, which are generally a highly individual concoction of requirements and problems.

The problem with CRM, BPM, et al is that they assume both customer and supplier will fit naturally into the limited range of functions offered by a pre-configured server system.  And this is so far from business reality that it is almost laughable.  In fact, the true nature of customer service is more like this:

1. Customer (or sometimes supplier) opens a negotiation - on a number of topics, which may or may not be related.
2. Supplier and customer exchange information, and agree next actions to be carried out - all this being highly customized to the case in question.
3. Step 2 is repeated until both parties are satisfied.

What sort of software is required to support this behaviour?  Software that lets both parties define multi-party contracts, replete with custom data items and activities, and each keep a copy of that contract on their own system (since both parties will naturally want a record of the agreement).  Further, the software objects embodying this contract must act not only as a "system of record" but also support active engagement in the collaborative process thus defined - as well as the continual re-negotiation of this process.

It is easy to see that current Web technology does not work anything at all like this - saving or printing a page from a supplier's support Web site, for example, offers nothing like the functionality described above.  What is required is a "rich client" capable of defining, depicting, enacting and revising such collaborative contracts - a client that all parties to a process use to support the work involved.  My own efforts to provide free software of this form are surely only the start of a new wave in technology for customer service.  And for many other fields too.

In the next instalments of this series, I will look at further applications and examples of this approach to collaborative work support.  Stay tuned if you want to see what is round the corner.

And I have changed my broadband supplier, by the way.

Posted by keithhb in Business Process Management • Internet • Management | Permalink | Comments (0)