• Analysts have a lucrative business in providing feature comparisons, advising vendors which new functions the market would be most interested in, and helping organizations select from the bewildering array of products on offer;
• Consultants have built a niche helping organizations choose, implement, and maintain these beasts - what a French consulting company with whom I once worked referred to disparagingly as "pousse-bouton" work;
• Enterprise architects charged with business process implementation are able to divest themselves of responsibility by laying it on the shoulders of software product vendors and their promises;
• Software product vendors have found a new market, often for a mixed bag of legacy or bought-in products that they can assemble, revamp, and re-purpose as a BPMS suite.

Nevertheless, it can't last forever.  The major vendors in IT are already owning up to the imminent death of the BPMS implicitly, not only by incorporating BPM functionality into monolithic middleware suites (Oracle, SAP, IBM, etc) but even into the operating system itself (Microsoft).  As I pointed out in my last post, published research from IBM shows how to implement business processes without a BPMS at all.  And here is what David Frankel of SAP has to say about using Model-Driven Architecture (MDA) for business process implementation on bptrends.com this month:

Model-Driven Service Orchestration

Often times, developers trying to get a handle on MDA approach it with the thought that they have
to use it to generate the components of their applications, or at least to generate fat skeletons of
the components, to which programmers add some finishing code. Then they run straight into the
last mile struggles with legacy back end systems that hold so much of the data in non-normalized
form.

Some of the most successful approaches that I’ve seen take a different route to nailing down the
last mile with MDA. They use service-oriented architecture (SOA) to present existing application
functionality as a set of service components whose interfaces are highly normalized via
consistent use of service interface languages such as Web Services Description Language
(WSDL). They use modeling to define specific orchestrations of the services. They walk the last
mile by compiling or executing the orchestration models.

In sum, this approach deals with the last mile problem that non-normalized back end systems
pose, by using SOA to provide a normalized intermediate tier that model compilers and model
execution engines can target in a consistent fashion.

In other words, Frankel is saying that you can use MDA to execute mechanistic business processes via SOA.  Draw your business process models, using whatever notation you like as long as it can generate code - UML is fine, for instance.   Then connect your code to services via WSDL.  That's it.  You can use a BPMS if you wish.  But you don't need to.

TAKE AWAY

Some people are attached to BPMS tools because of the wide range of features they typically offer - for messaging, reporting, configuration, and so on. However, tempting as such goodies may be, their use is not in any way related to increased business success.

In fact, there is a strong argument that adoption of multi-functional workplace tools has exactly the opposite effect.  A wide range of features and options often does little but distract people and muddy the waters.  Being bombarded by information from every side and in every form imaginable is a primary cause of stress - when you add multiple forms of messaging to multiple forms of reporting you get what I call "network overload", which is even worse than information overload.  On top of this many organizations are now using sophisticated workplace tools to transfer system administration responsibilities that properly belong to the IT department - authentication and authorization, for example - to end-users who are neither adequately qualified nor adequately resourced to handle such tasks.

What I see is that the net effect of introducing ever more highly powerful applications into the workplace has simply been to obscure individuals' true business goals and responsibilities.  How many people feel that they are running to stand still these days?  Or even just trying to keep their feet on the ground in the face of a tidal wave of information from all sides - and the demands for response generated by such information?

What the IT industry should be delivering is agile tools - agile in the sense of just-good-enough.  On this basis, the rise of programming techniques based on Model-Driven Architecture will, for many organizations, make a BPMS unnecessary.

For a start, an MDA approach is far closer to the original Third Wave ideal for BPM than the current generation of BPMS tools, since mainstream MDA tools such as Eclipse EMF are based on a simple, general, robust underpinning - unlike any current BPMS products!  It could be argued that the OMG MetaObject Facility that underpins EMF is the closest we currently have to the sort of generic framework envisaged by Smith and Fingar in their seminal 2003 book.

More importantly, MDA makes it possible to define your business goals, then implement processes to support them as quickly and simply as possible - and go round the loop again each time the goals change, as they do continually.  So why do you need anything else?  KISS, as they say.

Happy Easter.

Posted by keithhb in Business Process Management • Management • Office Applications • Security • Service-Orientated Architecture | Permalink | Comments (8)

... well, just about everything.

Some of you will atready know that HumanEdj went on general release yesterday.  The press release is here and you can listen to a podcast with Elizabeth Book about it here.

This release follows months of beta testing, in a programme that included over a hundred organizations of all sizes, types, sectors, and geographical locations.  I knew from my consulting experience that the software met a need in all sectors, so the variety in the programme was not really a surprise. What was a pleasant surprise was:

• The level of response, since the only invitations to join the beta programme were mentions on this blog
• How many major incumbent software vendors were on the programme.

When I first started writing about Human Interaction Management (HIM), at the start of 2005, there was considerable resistance to the ideas from the software community.  Despite my efforts to explain that HIM is not competitive but complementary to all existing offerings, raising rather than diminishing the value of current software products, many people involved in the software market seem not to have believed this at all.  Rather, they saw the emergence of a "new breed of productivity software" as a threat.  This viewpoint has definitely changed - out of necessity.

We are currently reaching the peak of a hype curve - not only for existing middleware solutions (Business Process Management, Content Management, Business Rule Management, etc) but for the clutch of good-looking new tools known as Web 2.0 (wikis, blogs, AJAX, etc).  How much money are organizations actually making from adoption of any of this?  Very little, I would say.  And saying it, I often feel like the little boy in the story about the Emperor's new clothes - it can't be long before others start to say it too.

When the wave breaks, as it will soon, incumbents providing these products and services will either go under (i.e, watch consumers become disenchanted with the offerings into which so much money has been invested) or surf - by providing their user base with a step-change in how they extract value from such offerings.

Human nature being what it is, it will not be long before the people currently investing in new middleware start to ask how it differentiates them from their competitors - and those still in love with Web 2.0 start to reject reading blogs, editing wikis, and making customized charts in a browser as a waste of time.  To keep these customers, you must offer something more, something that speaks directly to their most immediate need - which is to succeed in whatever it is that they are currently trying to accomplish.

The business person's true needs are not for more information on a Web portal or more features in an ERP suite.  Rather, the business person needs to become more productive, both personally and on behalf of the employer on whose success they depend.  Hence the business person desperately needs a new type of software tools - tools that will help them achieve rather than just "do stuff".

TAKE AWAY

The coming change is actually an opportunity, not a threat, for a supplier of Web portals and ERP suites.  By providing goal-directed collaboration tools that are customized to integrate seamlessly with their existing offerings, such a supplier can show people how to leverage such offerings for direct and immediate advantage, thus increasing both adoption of these offerings and customer satisfaction.

This is why so many software vendors signed up to beta test HumanEdj.  It is a free goal-directed collaboration tool designed from the ground up to support such integration - it can be branded and extended via standard Eclipse plug-ins.  What software vendor wouldn't think it a good idea to offer something based on this to their customers, something that in helping them meet their own business goals incidentally brings them back to the vendor's own fold?

Posted by keithhb in Business Process Management • Internet • Knowledge Management • Management • Office Applications • Service-Orientated Architecture | Permalink | Comments (0)

I have been arguing that current approaches to SOA are fundamentally flawed.  The fundamental problem is that they all treat business activities as a set of tasks organized into a flowchart.  In reality, organizational life is both more complex and simpler than this.  It is more complex because: work of all kinds is more like a set of interacting objects than a flowchart.  It is simpler because: work of all kinds is more like a set of interacting objects than a flowchart.

This is not just me being a smart-alec (read wise-ass, if you're in the US).  Flowcharts may seem simple, but their poor match to reality makes them inappropriate as a foundation for business process implementation.  Even in routine, repetitive work (what Human Interaction Management calls "mechanistic"), to which flowcharts are most suited, there are always a plethora of exception cases - and Pareto's rule tells us that it is the 20% of exceptions that cause 80% of the costs.  And when it comes to adaptive, innovative, interactive human work (what Human Interaction Management calls "human-driven"), flowcharts do nothing but get in the way.

If SOA is to deliver on its promises, it needs to deal properly not only with the exception cases - the edge cases that inevitably fall out to human handling - but also with the human work that at present is the biggest obstacle to improving organizational efficiency.  Contrary to how it might seem, SOA is in fact an ideal technology tool for improving both of these areas.

In both edge cases and human-driven processes, the work consists of a business process in which participants play Roles, via which they each have access to specific documents and other forms of data.  Crucially, the definition of these Roles does not derive from a set of flowcharts, but on goals and responsibilities.  Each Role has various overall goals and responsibilities, which taken together must satisfy the goals and responsibilities of the process as a whole.  A participant creates documents/data while playing a Role - in each case with certain of those goals and responsibilities in mind.  Participants exchange documents/data via Interactions between their Roles - again, in each case with specific goals and responsibilities in mind.

This is a new way of looking at business processes, leads to new and exciting principles and patterns for process description, and offers all sorts of advantages to the business.  Not only does it scale down, to the lowest-level routine processes, but it scales up, to the highest-level strategy and tactics of the organization as a whole.  At both ends of the scale, services can be used to great advantage by partially or fully automating key parts of the business process. In the next post to this blog, I will conclude this series on SOA by considering how a goal-directed approach to business modelling can be used to tame the Minotaur: truly integrate organizational management with the IT backbone.

TAKE AWAY

The way forward for SOA is to adopt an approach to modelling business activities that:

• Has natural support for human-driven activity
• Starts by defining goals and responsibilities, not a set of tasks to be carried out
• At a high-level, is based on business objects rather than flowcharts
• Allows low-level flowchart-type processes to be integrated into a cohesive model of organizational operations.

One immediate benefit of such an approach is that ROI on SOA initiatives can be maximized.  Not only can services be developed to support a larger group of business processes - i.e., human-driven processes as well as mechanistic processes - but the support thus provided is integrated naturally into the work of the organization as a whole.

The only approach currently on offer to meet these needs is Human Interaction Management, aka HIM.  A recent report by Information Age, Riding the fourth wave, heralded the emergence of HIM as follows:

A new generation of people-centric collaborative information management tools is set to produce the first fundamental advances in personal productivity since the arrival of the spreadsheet.

Gartner are quoted as predicting that the market for HIM systems is "at least another 5 years away".  So, the question is this.  Are you going to wait, and try to catch up with the market in a few years?  Or would you prefer it that the market struggles to catch up with you?

Posted by keithhb in Business Process Management • Management • Office Applications • Service-Orientated Architecture | Permalink | Comments (0)

Or rather, how not to lose money.

Happy New Year.  Regular readers of this blog may be waiting for the next instalment of the current series on SOA.  In the first two instalments:

• Is your SOAP turning to SOUP?
• SOA and the invisible side-effects of refactoring

... I outlined some of the business issues facing organizations implementing SOA, such as managing change and assessing cost effectiveness. It has been generally accepted for some time that investment in IT is not, on its own, going to give your organization any strategic advantage.  To the contrary, it is quite possible that investment in SOA will simply bring you a bunch of new expenses.

After all, what does SOA really promise to the business?  New integration technologies are just what they say on the tin - new technologies for integration.  Why should spending new money on integration improve your organization's bottom line?

I am not recommending that anyone should abandon their SOA initiatives.  Rather, I am suggesting that such initiatives should be driven by business people, with business aims in mind.  SOA proponents all claim that "yes, this is exactly what we do already".  But the "business advantages" espoused by the technical people currently heading up SOA projects are not usually business-related at all.  They are technical advantages, whose effect will only be felt by the IT department (if at all).

So what sort of things can be considered "business advantages"?  Is there anything generic that we can usefully say?  And how does it relate to SOA?

Let's start by recognizing that an organization is made up of people, all of whom have their own issues.  So "business advantages" means different things to different people.  Here is a very generic breakdown of the sorts of people involved in running any organization, and at an extremely high level, their most pressing problems.

The board of directors are there to lead the organization as a whole.  What they do is mandate aims (strategies and initiatives to implement) and constraints (policies and regulations to adhere to).  So the generic problem that board members have is very simple: how can they ensure that these aims are achieved and these constraints are complied with?  This is effectively a demand for "commitment processing".  The board wish to specify to executives how the business should operate, then receive from these executives their commitment to do so, plus (as time goes on) statistics on how things are progressing.

Managers have slightly different problems.  They have to deal with one-off ventures, projects, and issues.  They may be responsible for how the organization handles routine cases and problems.  Their fundamental need is to make sure that all these kinds of work are done efficiently - which means imposing enough structure for it to be facilitated, monitored and measured.  Some of the work can be (semi-)automated via workflow/BPM, but only some.  For the rest, such flowchart-based tools are far too restrictive.  However, the current alternatives - messaging and document sharing, perhaps via Web 2.0 technologies - don't provide any structure at all.

And then there's everybody else. The average office worker.  This is not a meaningless concept, since most people (including, in fact, directors and managers) have a basic problem in common.  Peter Drucker pointed out back in 1966 that "The Effective Executive" is good not at carrying out tasks, but at using time.  But these days, none of us have enough time - we are overloaded.  There is information overload: the well-known struggle to keep up with everything you are expected to know in order to do your job.  Even worse, there is network overload: characterized by the deluge of messages cluttering up the email inbox of the corporate employee.  The BBC say that:

It’s not unusual for office workers to spend as much as two hours a day, every day, sorting and reading all the mail which pours into their in-boxes, let alone the time they have to spend responding to it.

We all suffer from too much communication, which gets in the way of true collaboration.  And it is collaboration that delivers true business value.

TAKE AWAY

What does the analysis above of generic business problems have to do with SOA? 

Simply that we need to start by recognizing core business problems if we are to deliver genuinely useful business solutions.  In fact, effective enterprise IT architecture can help deliver solutions to all the problems outlined above - but only if the services provided by such IT are based directly on business needs, rather than technology features.

Most ERP system functions are never used.  Most "business intelligence" data is ignored.  Most "single sources of truth" bear little relation to the information truly needed by executives.  And the enterprise systems that people do use end up, as often as not, wasting people's time rather than saving it, like CRM systems that make you first do the work and then write it up.

In the second post from last year referred to above, I proposed that the answer to such business problems lies in Human Interaction Management (HIM), a set of principles, patterns and techniques for structuring collaborative work.  HIM is aimed directly at solving such problems, and is now fully supported by free software tools.

In the next posts to this blog, I will show how HIM can be used to leverage SOA to gain true business advantage.  In particular, we will see that HIM offers a direct way to understand change to services, and to measure their cost-effectiveness.

Posted by keithhb in Business Process Management • Internet • Knowledge Management • Management • Office Applications • Service-Orientated Architecture | Permalink | Comments (1)

There is so much excitement at the moment over applications delivered via a Web browser - wikis, blogs, shared documents/workspaces, portals, Web-based messaging, and so on - that no-one seems to be asking how much any of this actually contributes to the quality of workplace software.

It's all very new, which is an attraction in itself.  And it appears easy to start using such applications, since their user interfaces are often simple.  But is this type of software application actually any better than we had before?

In fact, it's usually much worse.  We've got used to complaining about having too much functionality in applications such as Microsoft Office, so at the moment the Web 2.0 stuff is benefiting from a rebound effect - it's simplicity is tempting. But here are some reasons why such software is a poor substitute for old-fashioned desktop software:

• It is not sensible to try and provide the same level of user interface functionality in a browser application that you can in a desktop application.  Browser programming technology is too lightweight to support truly sophisticated client applications - Javascript, to take one example, is a simple interpreted scripting language that was never intended to be as robust or powerful as the Java language it mimicked.  Any attempt to provide enterprise-class user interfaces solely via such browser technologies will ultimately founder, due not only to problems of download time for huge applications, but also because it is building a house on sand.  Using Web 2.0 means accepting a simplistic user interface.
   
• Most organizations are drowning in complex middleware systems, each of which carries a very high total cost of ownership. No-one wants more such systems. Desktop applications tends to be lightweight - the barrier to adoption is low, whether for one person or for the entire organization, since there is no need to involve the IT department at all. Web 2.0 applications, however, are the opposite - to the user, it seems simple to get started, but most commercial companies do not want their wikis or documents hosted on Google. They want them on their own servers, accessed by server-side software that they have installed, which means engaging with the IT department to start yet another long and involved software adoption cycle.
  
  
• Browser applications intended to support collaboration, as many do, depend on all concerned having access to the same servers.  But collaborative human work processes typically involve people from more than one organization.  Hence all participants may not have access to the same servers, or to the necessary resources on those servers - and even if this could be provided, there are many situations in which no one organization has the right to "own the process".  Hence it is necessary for all concerned to work in peer-to-peer fashion, rather than via a centralized server bottleneck.
   
• Systems intended for use by all kinds of people in all kinds of situation must be very easy to use, doing most of the work for you invisibly - especially back-end integration such as data sharing between applications.  This is not at all true of "Web 2.0" applications - they all present a different user interface, all run on different servers, and do not interoperate in any consistent fashion.  However much office workers may complain about Microsoft Office, they have come to expect a single user interface, which intelligently manages data integration complexity on their behalf.
   
• Any Web-based application is available only when you are connected to the Internet.  But in many working situations no such connection is available - when you are in transit, for example.  A well-designed desktop application, however, can be used at any time, even on any device.  Put the program and your data files on a USB stick, for instance, and you can work wherever you are, using any computer to which you happen to have handy, whether or not an Internet connection is available.

The most successful new desktop software applications of recent years - Groove, Skype, Firefox, and Thunderbird, for example - have not been browser based.  And if they were built today, using currently popular AJAX technologies, they wouldn't work as well as they do - they wouldn't be as fast, as stable, as well-featured, or as easy to use.

So when you are next considering adoption of an end-user workplace application - or building one - ask yourself this question:

Will a browser platform provide the level of functionality that, over the 20 years since the emergence of windowed operating systems, people have come to expect?

And don't be surprised if the answer is a resounding No.

Posted by keithhb in Internet • Office Applications | Permalink | Comments (0)

What?  The Chair of the Workflow Management Coalition, and former CTO (and designer) of Staffware, saying workflow sucks?  Yes, it's true.

Jon is not exactly noted for reluctance to rock boats.  But this statement seems particularly challenging.  I'll look more closely at Jon's message, and the content of the white paper he recently published, in a moment.  But first, we need to step back a bit.

Consider my post last week, How to abuse your software investments, in which I asserted that the deluge of new Internet tools known as Web 2.0 is actually a disadvantage to most organizations.  People are spending more and more time using these sexy new programs and devices without having any way of measuring the contribution to business goals made by such use.  As a result, most organizations are wasting more staff time than ever before.  Hardly the spirit of "extreme competition" needed in the new and challenging 21st century business environment!

To take just one example of such time wasting, here is a quote from the BBC, to which Jon himself drew my attention:

It’s not unusual for office workers to spend as much as two hours a day, every day, sorting and reading all the mail which pours into their in-boxes, let alone the time they have to spend responding to it.

How much is this contributing to personal or organizational goals?  I've written about the problems of corporate email before.  But email is just one example of how human work is actually being hijacked by new workplace technology.  Blogs, wikis, mailing lists, forums, intranets, chat, Web search, .... how are you measuring the operational (dis)advantages resulting from use of such tools in the workplace?

Here is a picture of where most organizations are now:

The underlying problem (and here we are getting closer to Jon's message) is that traditional work management tools - such as workflow - are of no help at all here.  You might think of workflow et al as "Work 1.0" and current knowledge-focused, collaboration-intensive, and innovation-driven work practices as "Work 2.0".  Here is a picture of where organizations need to go:

The key element of this picture is the blob in the middle, Human Interaction Management System, or HIMS.  What is an HIMS?  And why do we need one in order to implement what Jon's white paper calls Knowledge-Intensive BPM, or KIBPM - to control fundamentally important business activities such as Project Management and Case Management?

Let's start with the definition of an HIMS.  Here it is, from "Human Interactions: The Heart and Soul of Business Process Management" (2005), the seminal source book on Human Interaction Management (HIM):

A process modeling and enactment system that provides native support for the six Role Activity Theory object types (Role, Entity, Activity, User, State and Interaction), uses a state-based approach to Activity enablement and validation, permits Interactions to be composed of multiple asynchronous channels, and supports management of process change by allowing any process component to be created and configured as a natural part of process execution—not just objects of the six fundamental types, but also the user interfaces by which they are presented (screens, for example) and the means by which they interact with other systems (Web service calls, for example).

This is a complex definition, of course - almost what you would expect to see in a software specification document.  This is deliberate and necessary.  A HIMS must be a very specific sort of beast, in order to support the 5 basic principles of HIM:

1. Connection visibility - to work with people, you need to know who they are, what they can do, and what their responsibilities are as opposed to yours.
   You need Role and User objects, both instances and types, each with its own properties and responsibilities.
   
2. Structured messaging - if people are to manage their interactions with others better, their communications must be structured and goal-directed.
   You need Interaction objects in which there are multiple asynchronous channels, each for a different purpose.
   
3. Support for mental work - organizations must learn to manage the time and mental effort their staff invest in researching, comparing, considering, deciding, and generally turning information into knowledge and ideas.
   You need Entity objects that can be created, versioned and shared within a process.
   
4. Supportive rather than prescriptive activity management - humans do not sequence their activities in the manner of a procedural computer program.  There is always structure to human work, sometimes less and sometime more, but it is not the same kind of structure that you get in a flowchart.
   You need State objects that can both enable and validate Activity objects, along with the Roles that contain them.
   
5. Processes change processes - human activities are concerned often with solving problems, or making something happen. Such activities routinely start in the same fashion - by establishing a way of proceeding. Before you can design your new widget, or develop your marketing plan, you need to work out how you are going to do so - which methodology to use, which tools are required, which people should be consulted, and so on. In other words, process definition is an intrinsic part of the process itself.  Further, this is not a one-time thing - it happens continually throughout the life of the process.
   You must be able to manipulate not only objects but also user interfaces and integration mechanisms via the process that contains them.

How could a conventional "task allocation and notification" system possibly provide all these vital features?  Just to take one example, I have never seen a workflow/BPM system in which it is practical for users to try and make significant change to a process from within the process itself.  This is why Jon Pyke says, of course with tongue in cheek, that workflow sucks.  We need a new form of software tool, in order to support the business practices that are at the heart of organizational efficiency in the 21st century.

TAKE AWAY

 If you want to compete in the 21st century, you need to leverage your human resources efficiently.  If you want to leverage your human resources efficiently, you need an HIMS - not a workflow/BPM system rebadged as an HIMS.

So ask any software vendor trying to sell you a "Human Interaction Management System" how their offering conforms to the definition above.

Don't let them sell you a pig in a poke.

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

Here are some typical programs that someone reading this blog might use during a regular working day, in no particular order:

• Email client, perhaps as part of a Groupware solution such as Notes, possibly pushed to a device such as a Blackberry
• Web browser, particularly for search
• Intranet portal offering a Business Intelligence dashboard
• Reports from a decision support system
• Workflow/BPM task manager for notifications and work allocation
• Back-end ERP system for data on finance, logistics, inventory, etc
• Operational front-end system for various forms of data entry and maintenance
• Document/content management system
• Spreadsheet
• Word processor
• Presentation designer
• Drawing tool
• Project planner
• Voice-over-IP (e.g., Skype)
• Shared document access (e.g., Writely)
• Sector-specific databases - of drugs in healthcare, license numbers in law enforcement, and so on
• Sector-specific tools - graphics editors in design, CAD/CAM tools in engineering, and so on
• etc etc etc

I could go on.  These days, many people would add peripheral tools such as blog editors to the list, for example.  But perhaps you take my point!  It's a long list, isn't it.

Peter Drucker wrote, as far back as 1966 (in "The Effective Executive"):

The effective person focuses on contribution.  He [sic] looks up from his work and outward towards goals.

The great majority of people tend to focus downwards.  They are occupied with efforts rather than with results.

In other words, effectiveness is not about tasks.  It is about time.  Decide at the start of each day what are the most important things you need to achieve, then allocate your time accordingly.

Do you do this?  Most people would like to, but in fact are simply drowning in a sea of software.  They spend much of their time using programs of various forms, without ever stopping to ask a simple question:

How much does use of this software, at this moment, contribute either to my personal goals or to the aims of my organization?

TAKE AWAY

We are in the midst of a massive change in human working behaviour.  Some people, and some organizations, may be capitalizing on it, but many more are not.  The world is polarizing into the "very smart", who understand how to leverage the change - and the rest of us, who are just struggling to keep heads above water.

So, do you want - and does your organization want - to be "very smart"?  If so, you need to tackle grass roots issues head-on.  In particular, you first need to find out what are your staff are actually doing each day.  Most organizations have no way of knowing this, let alone any way of measuring its effectiveness.

I will be talking more about this issue in future blog entries.  For now, you might like to refer to this article - What is going on in your Organization?

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

For a start, there are multiple means by which I communicate with each beta tester - typically a combination of telephone, Skype talk, Skype chat, and email.  So the individual communications end up scattered about in various different places: my head, scribbled notes, Skype, and Thunderbird.  I try to record all interactions in a single repository, but this always means first having the conversation then writing it up (or pasting it in).  So inevitably some pieces of each conversation get lost, or collated out of sync.  If we were collaborating using a Human Interaction Management System (HIMS), such as humanedj itself, none of this would be an issue.  The technology underpinning each communication would be irrelevant, since all would be conducted via a HIMS that automatically recorded events.

Then there is the nature of each conversation.  Most people want to talk about two separate things:

1. Their experience of using the software - its strengths, weaknesses, what they would like to see added, and what they would like to see removed.
2. What sort of relationship they can expect with my company Role Modellers if they adopt the software - issues of licensing, support, partnering, and integration.

In HIM terms, these are separate "Interactions" (goal-directed communication channels) in a single "Story" (collaborative work process).  Keeping them separate has all sorts of advantages.  In particular, one can then involve different people in each Interaction: techies for the software discussions, business people for the relationship discussions.

Finally, collaborations tend to evolve over time.  Just to give one example, several of the beta testers have now decided they would like to collaborate amongst each other.  There are several such sub-groups forming - some in particular sectors, some organized geographically, some for the purposes of producing written material such as articles, some to investigate particular ways of jointly testing the software itself.  A few of these collaborations are being conducted via humanedj, though not all.  It would certainly simplify matters if the creation, merger and splitting of Stories was managed using humanedj - since otherwise those involved have only an informal idea of what is going on.  Using humanedj to conduct the Stories would not only facilitate the work itself and allow it to be automatically recorded (as described above), but make it amenable to management control - others in the organizations concerned would have visibility of the work, and a means both of controlling and of supporting it.

TAKE AWAY

Do the examples above sound familiar to you?   A software trial program is a typical example of what HIM calls a "human-driven" process.  Perhaps some of the tasks may be automated, but the work is quintessentially about people and their interactions.  With such work, you cannot say at the start how things will turn out - indeed, a fundamental part of the work itself is to establish how things will turn out.

With the rise of what author Daniel Pink calls "Asia, Automation and Abundance", such work is becoming more important than ever, as the only true competitive differentiator left.  Further, the new Internet-based communication tools have left us all drowning in a sea of messages from others - what I call network overload - that can be neither handled by individuals nor controlled by organizations, let alone leveraged properly for advantage.

We all need to structure our communications better - as collaborations, in which the individual Interactions are understood, separated out, and supported by a new generation of software tools.  Ask your software vendors what they are doing about HIM - and if their answer is unhelpful, ask yourself whether you are working with the right software vendors.

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

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)

This is the third and final entry in a blog series on writing documents - why the word processor is not the best way to do it, and how to do it better. In the two previous entries, I have:

• Explained the benefits of a more structured approach - an approach in which content is separated cleanly from formatting


• Given an example of such an approach.

In this final post of the series, I will describe a free tool that makes taking this approach just as easy as (if not more than) word processing.

The tool in question, XMLMind XML Editor (XXE), is one of many - there are various lists online, one of the best being provided by the DocBook project's own Wiki. However, I use XXE for 3 reasons:

1. The Standard Edition is free, and this provides enough functionality to write and output DocBook documents


2. With a couple of clicks you can generate output in various forms - HTML for Web browsing, Acrobat (PDF) for download/printing, and various other forms for compatibility with (say) Microsoft Word


3. It is very easy to use, since the interface is "WYSIWYG" - What You See Is What You Get.

What does this last point mean? Simply that using XXE is like using a word processor. Behind the scenes you may be creating XML, but you wouldn't know it - as document author, you write formatted text and see the results on screen just as in any word processor. For example, you can break a document into sections and sub-sections, place text in bold and italic, enter quotations, and so on. There are DocBook features for most common word processing tasks: bibliographies, cross references, footnotes, glossaries, embedded graphics, indexes, tables, and so on. You can even add attributed comments for collaborative working.

There is an XXE tutorial that explains how to write documents using the program, and gives you tips and tricks to speed up your work. I found that 30 minutes invested in this tutorial was enough to get going.

What you won't find anywhere in the tutorial, or in XXE itself, is information on how to specify fonts for pieces of text, customize the layout of pages, change paragraph formatting, etc. This is because, as explained in the previous blog entries, the whole point of using a structured approach is to let you as document author concentrate on content - and forget about document design. Not only are most people who write documents neither interested in nor qualified to design the documents they write, but by far the best approach is to apply preset formats to all your documents - formats that:

• Have been created by professional designers


• Are standardized across your organization and/or for the purpose of the particular document in question


• Not only enable output of the document in different forms but also guarantee stylistic consistency between these forms.

TAKE AWAY

Many of us spend a large proportion of our time entering text into a computer, often to create text documents (as opposed to say, spreadsheets). Typically this is done using a word processor, for example Microsoft Word. This blog series has asked: why?

Even the advanced features of modern word processors can be reproduced using an approach based on simple XML - and there is no need as an author ever to see this XML. You can write a "structured document", in which content is cleanly separated from formatting, without ever seeing a single XML tag - using WYSIWTG tools that have the same kind of interface as a word processor. What's more, such tools are available for free.

And once you start working in this way, the advantages are many and varied. As mentioned in previous blog entries, you can store such written materials in a repository, that is searchable not only on text keywords but according to the internal structure of the documents it contains. You also gain the very useful ability to generate various different forms of output from a single document with little or no effort - both for printing and for Web browsing, for example, or using different fonts, colours and layout.

But perhaps the most useful advantage of all is the ability to standardize on document formatting - both across an organization and for particular types of document - then change these standards at any time, without having ever to touch the documents themselves. To give but one example, we use it for providing software user documentation - and gain not only the ability to generate output both as Eclipse online help and in printable form, but also to change the style of this documentation at any time. For us, using structured documents is a no-brainer - as I suspect it would be for most organizations, if they only took the time to think about it.

An aim of desktop computing must surely be to reduce the amount of effort people have to invest in order to get things done. To me, it seems that taking away the responsibility for messing about with typefaces, line spacing, page layout, and other issues of document design can only be a significant step in this direction. Why not try it?

Posted by keithhb in Office Applications | Permalink | Comments (0)

In the previous posting, I described the disadvantages of using a word processor to create documents, and outlined the advantages of using a more structured approach - an approach in which content is separated cleanly from formatting. In this post, I will give an example of such an approach, and in the next post, I will describe a free tool that makes it just as easy as word processing.

The approach in question is to use a well-established XML dialect called DocBook. Quoting the DocBook Web site:

[DocBook] began in 1991 as a joint project of HaL Computer Systems and O'Reilly. Its popularity grew, and eventually it spawned its own maintainance organization, the Davenport Group. In mid-1998, it became a Technical Committee (TC) of the Organization for the Advancement of Structured Information Standards (OASIS).

DocBook has become the leading way to write structured documents. You create a set of XML files to represent your report, article, book, or whatever - and use XML "stylesheets" to generate from these files a number of finished products. You might require, for example, both a PDF version for printing/download and an HTML version for display using a Web browser. The ability to select any stylesheet for generating output means that on different occasions you can generate each of these end products with different typefaces, layouts, and so on.

Are you put off by the mention of a techie language such as XML? Never fear, as a document author there is no need for you ever to touch the stuff. There are (free) tools available that allow you to write DocBook, and generate all sorts of useful output, without needing even to see the underlying XML code.

TAKE AWAY

Creating a document in which the content (for instance, XML DocBook files) is separated cleanly from the formatting (for instance, as stylesheets) means that you automatically gain various useful advantages. In particular, you can store written materials in a repository, searchable according to the internal structure of the documents it contains. You also gain the very useful ability to generate various different forms of output from a single document with little or no effort - both for printing and for Web browsing, for example, or using different fonts, colours and layout.

DocBook is actually very simple to use - the XML tags are intuitive, with names such as chapter, title, section and so on. However, most people prefer not to write XML by hand. So there are many tools available, some of the best ones being free, which make it as simple to write a DocBook document as a Microsoft Word document. In the next blog post, I will describe one such tool and explain how to use it. If you are starting to see the benefits of changing the way you (and your colleagues) write documents, stay tuned.

Posted by keithhb in Office Applications | Permalink | Comments (0)

Most of us use a word processor, daily - and for many of us, it comes second only to email as a business tool. But is a word processor actually the best way to create written documents?

It is quite extraordinary that in the 21st century the standard way of creating formatted text on computers is essentially unchanged from its roots in 15th century typography. Gutenberg would have had no real difficulty using Microsoft Word. Prior to computerized typesetting, if you wanted bold text in a book, magazine, or newspaper, your printer would achieve it by taking the characters concerned from a bold version of the font and placing them into the appropriate positions on the page. These days, you do it yourself using a word processor - but the principle is exactly the same. You now place characters in bold by choosing the appropriate menu option, or clicking on a toolbar button, but - just as in the old hot metal days - the formatting is attached directly to the text itself.

Why on earth are we still doing things this way? As Charles Goldfarb writes: "Many credit the start of the generic coding movement to a presentation made by William Tunnicliffe, chairman of the Graphic Communications Association (GCA) Composition Committee, during a meeting at the Canadian Government Printing Office in September 1967: his topic -- the separation of information content of documents from their format." The 40-year old "generic coding movement", of which Goldfarb was a founder member, eventually gave rise in 1980 to the standard markup language SGML, which in turn formed the underpinning of HTML and subsequently XML.

In HTML, for instance, one specifies that certain text is a heading by surrounding it with "tags" such as h1 (heading level 1) or h2 (heading level 2), one identifies a list using tags such as ul (bulleted list) or ol (numbered list), and so on. It is then up to the browser that displays the HTML to "render" headings and lists using appropriate fonts and layout. With HTML, the rendering choices are generally built in to the browser itself. With XML, however, there is more flexibility in document formatting - one can identify sections of text as being of any nature whatsoever, then define (by various alternative means) the way in which you would like text of each type to be displayed.

Such an approach to publishing has many advantages over simple typesetting:

• You can do structural searches on the document (rather than just keyword searches)


• It is possible to present the document in outline style


• A document can be formatted in different ways for different purposes


• Documents can be stored and analysed via knowledge management techniques rather than as a stream of bytes


• ... and so on.

It is very hard to explain from a logical standpoint why most people do not write text in this way. Most likely, the reasons are simply commercial - the success of leading word processor products, for example. Yet there are few if any features of document creation that would not be better achieved via separation of content from formatting. And these days there are well-designed, free tools available for the creation and subsequent formatting of structured documents, tools that do not require the user to possess the technical skills of a programmer.

TAKE AWAY

The success of SGML and its descendants is immediately visible to all of us in the increasing prominence of the World Wide Web in everyday life. Yet, for some reason, the vast majority of people still write documents using a word processor, in which text is only structured via an implicit association with the attached formatting - and this is completely unreliable. Few people are consistent in their use even of bold or italic, for example.

More to the point, many word processor documents are stored natively in a format that precludes the simple presentation of the text in alternative forms. Yet this is potentially extremely useful. For example, it would be very valuable if a single document could be displayed either as an article, a slide presentation, a set of Web pages, or a syndicated feed - something that is impossible to achieve via conventional word processing.

In the next postings to this blog I will show how anyone, no matter how technically uninclined, can use simple, free tools to create documents in which content is cleanly separated from formatting. I will also illustrate the immediate business benefit of doing so with examples drawn from daily life.

If you ever write documents (and who doesn't), stay tuned.

Posted by keithhb in Office Applications | Permalink | Comments (1)