« How to make money from IT | Main | The first fundamental advances in personal productivity since the arrival of the spreadsheet »

January 29, 2007
Are you goal-directed? Or task-trapped? This post continues a blog series on gaining genuine business advantage (rather than just technical advantage) from SOA. If you haven't been following the series so far, or would like to refresh your memory, see the last post on How to make money from IT before reading further.

In the last post, I argued that to gain business advantage from SOA, you need first to step back and consider what the fundamental needs of an organization truly are.  To get started on this, I gave a very generic breakdown of the sorts of people involved in running any organization, and at an extremely high level, their most pressing problems.  These problems fall into 3 broad categories, which can be summarized as follows:

1. Commitment Processing [board level] - how to get the organization to implement the desired aims and constraints, which means gaining commitments to these aims/constraints and then monitoring their progress
2. Process Improvement [managerial] - how to make business processes more efficient, which means imposing enough structure that their progress can be facilitated, monitored and measured
3. Personal Productivity [everyone] - how to make the best use of your working day, which means reducing information and network overload enough to leave time to get on with your work

In fact, all these problems are closely related.  What is the connection?

In each case, the problem has the same foundation - that people lack the means to base their work directly on goals.  They struggle since they are trying to structure work on a completely different basis - that of the tasks they imagine work to be comprised of.

Ask any business person - a manager, a salesperson, a designer, a specialist in some field, a business analyst, a consultant, or anything else - to describe a particular type of work carried out in a particular organization, and they will do exactly the same thing.  First they will break the work down into a set of tasks.  Then they will explain how the tasks join up:

• Which tasks come before others
• How some tasks are dependent on the outcomes of other tasks
• Under what conditions you might repeat certain tasks

In effect, they are describing a flowchart.  They might even draw you a flowchart of some kind, to illustrate what they mean.

This approach to understanding work is the achilles heel of the modern workplace.  In fact, only a very limited kind of work can be appropriately described as a set of tasks organized into a flowchart.  This specific kind of work is what Human Interaction Management (HIM) terms "mechanistic": manufacturing, certain kinds of testing, logistics, order processing, invoicing, settlement, payroll, and so on.  Such work is the proper domain of workflow and BPM.

Everything else done in an organization is what HIM terms "human-driven" work: research, design, marketing, sales, customer support, team leadership, managing organizational change, software development, and so on.  I expect that everyone reading this blog would agree that this second kind of work is at least as critical to business success as the first kind of work.

However, despite the evident importance of human-driven work, there is a general lack of understanding of what it really consists of.  Both forms of work - mechanistic and human-driven - can be organized into structured, controlled business processes; but only if you appreciate the difference between the two forms of work, and that each must be described in a different way.  In particular, only mechanistic work can be described as a set of tasks, arranged in sequence like a flowchart.  Human-driven work must have a different kind of description, one that is based directly on goals: organizational goals, goals that are shared in some other way, and individual goals.  Only by structuring human-driven work in terms of goals can you do such work better, and manage it better.

TAKE AWAY

The discussion above shows that the connection between the 3 generic business problems of commitment processing, process improvement and personal productivity - i.e., how to make work goal-directed - is the same as the fundamental building block from which to start describing human-driven processes - i.e., goals, whether organizational, shared in some other way, or individual.

This is not surprising when you consider that business problems belong to business people - not to machines.  Board level responsibilities, managerial responsibilities, and all other working responsibilities are entrusted to human beings, not to computers.  Hence, by and large the work processes that cause these problems are human-driven processes rather than mechanistic processes, and the way to solve the problems is to improve the way that such human-driven processes are carried out in your organization.

Once this is done, the door is opened to true process-enablement of the organization.  Not just process-enablement of mechanistic work (via workflow and BPM), but also process-enablement of human-driven work (which requires different tools entirely).  And then SOA becomes a natural and logical next step in business improvement, rather than yet another technical innovation that promises more than it delivers.

To see how SOA will come into its own via process-enablement of human-driven work, consider how - as is now widely accepted - BPM and SOA are essentially indivisible.  You need services to implement BPM, and you need BPM to make effective use of services.  However, if you have only enabled some of your business processes - the mechanistic processes - you are missing out on the opportunity to optimize the vital human-driven work of your organization.  Not only is this a waste, but it means that the problems perceived as most pressing by the organization - the business problems, not the technical problems - are not being addressed by SOA at all.

In future posts to this blog, I will explore in more depth the nature of human-driven processes, discuss how to start structuring and managing them better, and show in more detail how this can lead to gaining true business advantage from SOA.  In the meantime, you can find out more about these ideas via the Human Interaction Management Web site.

Posted by keithhb in Business Process Management • Management • Service-Orientated Architecture |Digg This|Add to del.icio.us

Comments

Posted by: Ramudu at May 3, 2007 03:47 PM

Post a comment

Name:

Email Address:

URL:
Remember Me? YesNo

Comments: (you may use HTML tags for style)

We ask that you type your code (displayed below) in the text box.This code is an image that cannot be read by a machine. It prevents automated programs from submitting comments.


Code: