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 | Permalink | Comments (1)

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)