... 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)

This is the last in my current blog series on SOA.  In the series so far, I have tried to explain what is missing from current approaches to SOA, and from business modelling in general - and how filling this gap can lead to enormous efficiency improvement, particularly with regard to SOA adoption.

A cornerstone of my argument is that an organization cannot be properly understood by talking only about the services it provides, either internally or externally.  Rather, an organization can only be understood as a network of interacting objects.  Contrary to what you might expect, it is IT people who seem to be insisting on the simplistic service-based approach, and business people who naturally see the world as a system of "things" and relationships between them.

But what, you may ask, about Porter's famous "value chains", and the competitive advantage to be gained by optimizing them?  Are not these just what IT people call "services"?

Yes and no.  Value chains may look like services, but trying to model an organization on a service basis leads only to disaster.  To help explain why, I am going to hand over to Paul Harmon, and quote at some length from a recent one of his "Business Process Trends Advisor" mailshots, that of 30 January 2007 (you can subscribe to these very useful mailings at bptrends.com):

"Operational effectiveness", as Porter uses the term, means performing similar activities better than rivals perform them. In essence, this is the "best practices" approach we hear so much about. Every company looks about, determines what appears to be the best way of accomplishing a given task and then seeks to implement that process in their organization. Unfortunately, according to Porter, it isn't an effective strategy. The problem is that everyone else is also trying to implement the same best practices. Thus, everyone involved in this approach gets stuck on a treadmill, moving faster all the time, while barely managing to keep up with their competitors. Best practices don't give a company a competitive edge - they are too easy to copy. Everyone who has observed companies investing in software systems that don't improve productivity or price, but just maintain parity with one's competitors, understands this. Worse, this approach drives profits down because more and more money is consumed in the effort to copy the best practices of competitors. If every company is relying on the same processes then no individual company is in a position to offer customers something special for which they can charge a premium. Everyone is simply engaged in an increasingly desperate struggle to be the low cost producer, and everyone is trying to get there by copying each other's best practices while their margins continue to shrink. As Porter sums it up: "Few companies have competed successfully on the basis of operational effectiveness over an extended period, and staying ahead of rivals gets harder every day."

The alternative is to focus on evolving a unique strategic position and then tailoring the company's value chain to execute that unique strategy. "Strategic positioning", Porter explains, "means performing different activities from rivals' or performing similar activities in different ways." He goes on to say that: "While operational effectiveness is about achieving excellence in individual activities, or functions, strategy is about combining activities." Indeed, Porter goes on to say that those who take strategy seriously need to have lots of discipline because they have to reject all kinds of options to stay focused on their strategy.

Rounding out his argument, Porter concludes: "Competitive advantage grows out of the entire system of activities. The fit among activities substantially reduces cost or increases differentiation." He goes on to warn that: "Achieving fit is difficult because it requires the integration of decisions and actions across many independent subunits." Obviously, I'm just providing the barest summary of Porter's argument. In essence, however, it is a very strong argument for defining a goal and then shaping and integrating a value chain to assure that all the processes in the value chain work together to achieve the goal.

The importance of this approach, according to Porter, is derived from the fact that: "Positions built on systems of activities are far more sustainable than those built on individual activities." In other words, while rivals can usually see when you have improved a specific activity, and can duplicate it, they will have a much harder time figuring out exactly how you have integrated all your processes. They will have an even harder time duplicating the management discipline required to keep the integrated whole functioning smoothly.

In other words, an organization must be understood and improved as an entire system - not as a set of activity sequences.  What is required to gain such an understanding?

There are many well-established techniques available for modelling an organization, ranging from analytic techniques such as the Zachman Framework to management tools such as Balanced Scorecard.  However, none of these techniques provide what is truly needed in order to optimize the way an organization operates, i.e., a systemic view together with the tools to leverage it:

• An overall perspective that can be used to make strategic decisions (what Human Interaction Management calls Strategic Control)
• The ability to drill down from this overall perspective to the processes allocated to specific executives (what HIM calls Executive Control)
• A means of using a process as a basis for executing, monitoring, and facilitating the work itself (what HIM calls Management Control).

To provide all this, you need to apply 3 techniques in conjunction:

• Process Architecture, for which Martyn Ould's Riva method is the leading approach, in order to understand what your organization does, at the highest level
• Human Interaction Management, in order to:
  • Break down the work required to implement this into the 3 levels of control described above
  • Implement the adaptive, innovative work done by humans collaborating (what HIM calls human-driven)
• Business Process Management, in order to implement routinized, repetitive work (what HIM calls mechanistic), allocating as much of it as possible to machines rather than humans.

TAKE AWAY

SOA on its own, like BPM, is a technical advance, not a business advance.  And like all other technical advances, both are as likely to cost you money as save you money.

However, applied in the right way, SOA can make a huge improvement to the operation of an organization.  This is the right way:

1. First draw up a process architecture, to unite business goals with business processes.  This is a sine qua non - unless you start here, you will be building a house on sand. As discussed earlier in this blog series, goals are the true foundation of all business activities.
2. Next apply Human Interaction Management, to make best use of the humans in your organization, at all levels of the organization chart - not in order to downsize your people away, but rather in order to leverage the skills you have on board.  Only via HIM can you gain the dual advantages of structure (for efficiency) and agility (for responsiveness).
3. Use BPM/workflow to improve your performance of mechanistic work - but be aware that there are no magic bullets to remove real-world complexity!  The idea that BPM would make it possible for business people to change mechanistic processes on the fly is a complete myth.  The IT department are going to stay involved for the duration, and when you want a new version of a mechanistic process you will need to ask IT people to draw it up, IT people to ensure it complies with regulations, IT people to test it, and IT people to deploy it.  Agility is for human-driven processes only - it is the province of HIM, not of BPM/workflow.
4. Finally (and only at this point should SOA enter the picture), look at all the processes you have defined - both human-driven and mechanistic - and ask: which of these could make use of services?  Then build the services you need, not those that the IT department suggests may be quite handy.

By following this approach, you will end up not only with a true picture of your organization, but with a picture that you can use for immediate practical purposes.  The system thus defined will match your strategy, via process architecture.  It will match your organization chart, via HIM levels of control.  It will lead to true process-orientation, for both kinds of work (human-driven and mechanistic).  And it will allow you to optimize as much as possible, via the use of SOA.

There may be no magic bullets to remove complexity, but there are means to tame it.  The 21st century business environment is completely unforgiving.  You have 2 options.  Ride the fourth wave.  Or let it drown you.

To find out more about using Riva, HIM, BPM and SOA in conjunction, start here.

Posted by keithhb in | 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)