IT Directions

Human Interactions in the English countryside

July 15th, 2010

If you are interested in next-generation techniques for managing collaborative human work, you may like to know about a series of workshops on Human Interaction Management this Autumn.

I will be running them myself. Each workshop is limited to 8 people and the focus is on producing real-world, usable results. Attendees will come away with executable processes and organizational models based on their own business.

More details below.

Role Modellers Autumn 2010 Workshop Series - Human Interaction Management

“The first fundamental advance in personal productivity since the arrival of the spreadsheet” (Information Age, 2007) is here, and we can help you get started. According to Gartner, the “Fourth Wave” of Human Interaction Management techniques and tools won’t be mainstream until 2012 - so now is your chance to get ahead of competitors.

Located at Role Modellers’ offices in a picturesque English market town, this 2-day workshop is a hands-on introduction to next-generation process modelling and execution techniques that deal with human work at all organizational levels.

Working with examples from their own business, attendees will learn how to:

* Reduce knowledge worker costs by up to 75%;
* Deal efficiently and effectively with the 20% of “exceptional cases” that generate 80% of operating expenses (and potentially 80% of revenue);
* Build collaborative business applications in minutes;
* Implement true cross-boundary business processes;
* Define and execute organizational strategy.

Workshop Brochure: http://tinyurl.com/2ugrvh7

Posted in Business Process Management, Governance, Knowledge Management, Management, Productivity, Requirements | No Comments »

The operating system for the Internet

July 6th, 2010

Been a while since I posted. During 2009 and 2010 (exactly when Gartner predicted back in 2007 - well done, Janelle Hill), major organizations have started using HIM/GOOD as the basis for their strategy, and HumanEdj as a foundation component of next-generation Web platforms, and supporting these efforts has been rather time-consuming.

Having been through this process, I’ve come to understand that HIM/GOOD have 3 quite separate aspects:

1. Next generation productivity
Business Change Leaders need to introduce what Information Age called “The first fundamental advance in personal productivity since the arrival of the spreadsheet”. This is documented in my articles on The Future of Work and Goal-Oriented Organization Design.

2. Next generation software
Software Developers and Technical Business Analysts need better tools to build collaborative business applications. See my presentation to Javapolis (“A Software Framework for Human Interactions”) then try the demonstration HumanEdj Web application.

3. Next generation Internet
Technologists are building a massive infrastructure around Web services and federated trust. What is going to glue all this together? We need an operating system for the Web …

In order to use a computer, you install an operating system to provide and control access by people (user accounts) to things (local and network resources) and services (programs, typically).

It is the same with the next generation of the Internet. We need a more general means to provide and control access by people (trusted identities) to things (objects with an IP address or RFID tag) and services (Web services, typically). Just as with a computer, an operating system is required.

HIM/HumanEdj do exactly this - join up the Internet into something both usable and useful:

HIM - a process modelling approach based on objects of specific types (unlike other process modelling approaches, which are based on sequences of tasks).

HIM helps you understand the Roles, People, Interactions, Activities, Entities and Rules required to achieve objectives, so that you can choose the appropriate resources for a venture, project, programme, issue, bid, or any other piece of work. You can then adjust the resources as necessary while doing the work - a critical enabler for collaborative human activity.

HumanEdj - a process execution system that implements HIM processes as “Plans” that can cross boundaries of any kind (unlike other process execution systems, which are restricted to a specific domain).

People working together in a Plan can belong to different organizations and can use their own instances of HumanEdj with different servers and different user interfaces. You can even communicate with colleagues in a HumanEdj plan using a messaging service such as email. There is no need for a single organization to “own the process”, and no restriction to a specific device or platform. This is why email has become so widely used - you can communicate with people without having to use the same email server, or even know what email server they use.

HIM/HumanEdj make it possible to use the Internet efficiently and effectively.

They also make it possible to audit your usage. With the rise of regulatory controls in government/business, and the growing dangers of cyber-crime, it is becoming more and more important to keep a human-readable audit trail of your Internet activity (both for individuals and for organizations).

With HIM/HumanEdj, you get this for free. Every HumanEdj Plan is recorded automatically, both as a template for future work and as an audit trail. You always have a record of what you did, with whom, and the resources you used.

HIM/HumanEdj are the operating system for the next generation of the World Wide Web - they make it work, and they keep it safe.

Posted in Business Process Management, Governance, Human Interaction Management, Internet, Knowledge Management, Management, Operating Systems, Productivity, Service-Orientated Architecture | No Comments »

Forming a Business Change Team

March 11th, 2009

In my last post I began explaining the different high-level roles involved in the governance of business change, by focusing on Requirements Management - a role that deserves special attention since:

Requirements Management (as opposed to Requirements Gathering or Requirements Analysis) is widely misunderstood - or not understood at all;
Requirements are fundamental to any form of business change - get your requirements wrong and any related efforts are doomed to failure.

In future posts I will discuss the other high-level business change roles:

Stakeholder Management
Business Change Management
Benefits Management
Risk And Dependency Management
Marketing And Communications

First, however, some people have asked why all these roles are necessary. To see this, it is necessary to backtrack and ask a preceding question: what are the goals of a business change activity?

You might think that goals would be different in every case, but in fact the key aims of business change are always the same:

To ensure that work meets stakeholder needs - for which you need to identify stakeholders, both internal and external, and communicate with them effectively;
To deliver results into a business-as-usual environment - the key purpose of a dedicated business change role;
To maximise benefits from outcomes - i.e., work out in advance what your benefits will be, and then ensure that the consequent work realizes these benefits;
To minimize the costs associated with delivery - which means managing dependencies and risks.

A little thought shows that, to achieve these goals, the Roles above are all necessary. In some cases more than one Role may be played by the same person, but unless you start with an understanding of Roles and associated responsibilities, important activities will slip through the net and your work will not deliver the desired results.

TAKE AWAY

There are many different methods for handling business change. For example, many consulting firms base their practice on a proprietary approach to business change. However, none of these methods are grounded in a robust theory of human work (since the first such theory is Human Interaction Management, which only appeared recently).

In the end, all current mainstream approaches to business change are essentially a synthesis of carefully selected best practices. The problem with such approaches is that it becomes hard to join all the dots - to connect high-level strategy with middle-management practice with operational activities. Many business change activities appear to have succeeded but fail to deliver the expected results, since there are unforeseen breakdowns where the realities of human-driven process enactment do not live up to the expectation as depicted on colourful Web dashboards.

A key reason for this is Pareto’s rule: that the 20% of “exceptions” (which are really the rule, since they always occur) consume 80% of the costs. To properly handle such edge cases, you need processes that have flexibility designed in - processes that do not pretend real life is as simple and mechanistic as a flowchart.

In harsh economic times, when cost reduction and improved effectivess is more necessary than ever, we need to get business change right first time - which means acknowledging this real-world nature of human-driven work. We need a new approach to business change, an approach like the GOOD method associated with HIM (aspects of which I am describing here).

In future posts I will show the different areas of interest of each of the Roles above, and explain how to develop a governance structure for your business change project, venture or initiative that ensures they collaborate effectively.

Posted in Business Process Management, Governance, Management, Requirements | 2 Comments »

Business Change Made Easy

February 26th, 2009

My last post included a diagram showing the different high-level roles involved in the governance of a business change effort, and promised to explain more. In this post I will discuss a role that is pivotal to success, yet almost always misunderstood - Requirements Management.

Ask a range of people to define Requirements Management and you will get a range of answers. Some will say it concerns the management of a team of requirements analysts. Others will mention maintenance of a requirements repository. Many will talk vaguely about “engaging with the business”.

Only rarely will you hear anything about the true focus of requirements management, which is sustainability. Anyone can run workshops and document a resulting set of “business needs”. It is not even particularly hard to keep these documents reasonably up to date. What is far harder is to ensure that your requirements are key to controlling business change - that they guide all the work carried out through all the life of an initiative, project or venture.

Achieving this requirements nirvana has several aspects.

For a start, your requirements repository must contain the right sort of artefacts. The most beautifully constructed use cases and sequence diagrams in the world will not make up for there being no domain model (surprisingly often the case), process architecture, organizational structure, and so on. Here it is not one size fits all - although certain information is always necessary, the degree of detail and appropriate formats vary from situation to situation.

Then there are scope issues. What is the reach of your information and your interactions? Have you modelled enough or too much? How far do the tentacles of your requirements gathering and analysis stretch, and how should you deal with the boundaries? More subtleties that take skill and experience to handle.

A different but vitally important aspect is how the requirements are used. Here it is no good relying on informal interactions with colleagues. However good your inter-personal skills may be, everything can - and will - go to hell if you don’t have formal processes to manage the flow of intent (which includes the flow of information but covers rather more). Rely on goodwill and a single calendar clash, annual leave, change of position or accidental CC ommission may throw a small but fatal spanner into the works of a huge programme.

Further, like all forms of management, it is necessary not only to define goals and provide resources but to monitor the work carried out and adjust as necessary. Requirements can be wrong, for a start, or simply need enhancement based on the in-depth experience of those charged with implementing them. Further, requirements management is closely tied to other types of high-level management, as the diagram in my last post shows. These demands make the need for formal, well-understood processes (as opposed to informal human interactions) even more vital.

The processes in question are, as regular readers of this blog will be aware, not the kind that can be described using flowchart techniques - rather they are the iterative, interactive, innovative kind that typically cross organizational boundaries. To understand and describe such processes, you need the techniques of Human Interaction Management (HIM).

Orthogonal to all the concerns above are relationship issues - within the requirements team, with those who must implement the requirements, and with stakeholders both internal and external. The best artefacts and the best processes cannot achieve their purpose if the people involved are mis-aligned. Here again it is necessary to apply HIM principles - teams, communication, knowledge, time management and planning are all essential factors.

TAKE AWAY

In my last post I emphasized how transparency was the key factor in success of a business change initiative. Many people find it hard to achieve this - the culture they are working within may discourage it, for example. The way to solve such problems is not to make a general demand for “more open-ness” or any other form of deep organizational change, but to focus on intended outcomes - one by one.

This comes down to the aspects of requirements management discussed above. Make a public case for each aspect in turn, via a formal document, using language that is simple and neutral. Those above, around and below you - whatever their priorities or agendas - will find it hard to resist the simple logic of each small change to working practice.

Working softly softly in this way, you will eventually find you are where you need to be. Look after the pennies and the pounds will take care of themselves, as they say. Or used to, before the credit crunch

Stay tuned for more advice on business change made easy.

Posted in Management, Productivity, Requirements | 2 Comments »

Strategic and Executive Control

February 19th, 2009

In my last post, I described a framework that can be used to guide business change - the OMG’s Business Motivation Model (BMM) - and suggested that you also need other techniques in the early stages of an initiative, project or venture. In fact a tool such as BMM is only the start.

Any form of business change must take into account a number of varied factors, any of which can derail the effort if not dealt with properly:

Organizational structures both old and new
Dependence and impact on external supppliers
Perceptions both inside and outside the team
Timescales and associated resources
Risks and associated mitigations
People and associated interactions
etc.

To deal with all this harmoniously requires a clear understanding of governance. The methodology associated with Human Interaction Management distinguishes 2 forms of governance: how to set goals and stick to them (strategic control) and how to make the work fit into an organizational context (executive control).

Shown below are illustrations of the key governance roles:

… and of how these roles work both together and with lower-level roles for management control:

TAKE AWAY

In my experience, if there is a single key factor that distinguishes successful initiatives, projects or ventures, it is transparency. If everyone involved can see what is going on generally, they can understand their own part in it and make sure they are working effectively, safe in the knowledge that their work will be recognized. They can also help identify general issues as early as possible, and see why it is in their own interest to do so.

If, on the other hand, the waters are generally muddy, people go into back-covering mode. They work to rule, not only doing the minimum necessary but also spending valuable time proving that they have done so - time that would have been better spent making productive contributions. In extreme cases, in which there is little reason to believe that the work as a whole will succeed, people will devote most of their daily effort to saving their own reputations - much like a run on a bank that is suspected of failing.

In the next posts to this blog I will explain the pictures above, and show how the simple practices depicted help to ensure success both for the teams you work in, and for you personally.

Read the rest of this entry »

Posted in Management, Productivity, Requirements | No Comments »

Business Motivation Model

February 12th, 2009

First an apology. It has been over 3 weeks since my last post - and yesterday a commenter on that post wrote:

Great teaser, please, release the other posts of the new series ASAP

Thanks, Kerber, for the prod. As an excuse, I’ve been very busy recently putting into practice the ideas I promised to write about!

Let’s start with a technique that has been around for many years now but is not as well known as it should be - the Business Motivation Model. This is now an OMG specification (http://www.omg.org/spec/BMM/1.0), although it originally started life with the Business Rules Group, who were responsible for the key concepts.

The BMM fills a vital gap in the business analyst’s armoury. Indeed, it is a technique that, in conjunction with the right supporting framework (which I will be describing in the rest of this series) is capable of elevating business analysis above the low technical concerns in which it is currently mired. The BMM allows you to provide a formal basis for business change planning - not just IT system implementation but any form of initiative, project or venture. Indeed, a key benefit for IT people of using BMM is that it places the high-level focus directly on high-level business drivers, rather than on low-level technical concerns.

Surely, I hear you say, no modern development project would fail to take account of business issues - indeed, no modern development project would fail to put business issues firmly in the driving seat. Here I must interject a hollow laugh. Where projects have an IT element, most “high-level” documents purporting to address strategy, benefits, requirements, change planning, and so on are thinly disguised computer system proposals - the IT element hijacks and dominates everything else. This may be because IT is more familiar territory to the people who draw up these documents, or because business analyis techniques often come from an IT world and are thus IT-oriented. The end result, however, is that most projects that are IT-related become IT projects, and thus fail to deliver the full business benefits originally promised.

It is the responsibility of the business analysts who become involved at an early stage to remedy this situation - and doing so will have the pleasant side-effect of increasing their own credibility, since they will then become business change agents rather than factories for system architectures and program specifications. Most business analysts of today are in fact “systems analysts”, which is not a healthy situation either for the business or for their own careers.

How does the BMM help? It provides a metamodel with which you can capture the “ends” (vision, goals and objectives) of a proposed business change, together with the “means” to those ends - mission, strategies (with associated tactics), and policies (with associated rules) - and the “influencers” whose “assessments” drive, guide and control the work involved. Simple but powerful stuff. My own experience with BMM is that it provides just the right amount of rigour - enough to help understanding, but not too much to prevent flexible use in different circumstances.

You don’t need tools to use BMM. If you use the IBM Rational Suite, there is a RequisitePro template for BMM available from IBM. However, you can adopt the analysis techniques and document your findings using any word processor or spreadsheet.

TAKE AWAY

Despite the potential value offered by BMM to enterprises of all types and sizes, its take-up has been slow. Some people find it confusing - there are feedback loops around Influencers and Assessments, for example, and it can be hard to retrofit BMM to existing projects. The lack of good explanatory documentation does not help here - and in general, the OMG could do a lot more to encourage adoption of BMM.

There is also a deeper concern about incompleteness. In my own work, I use BMM as an element of the GOOD methodology (see http://human-interaction-management.info) to provide a route to action and integrate multiple change planning efforts. In future posts, I will say more about the other techniques that you need in order to put BMM to best use in the early stages of an initiative, project or venture.

Stay tuned, and I’ll try not to leave such a long gap before the next post

Tags: Business Motivation Model BMM OMG
Posted in Career, Management, Requirements | No Comments »

Derisking Software Development via Business Modelling

January 19th, 2009

As a consultant I often advise large-scale software development projects that have got themselves into trouble, or fear they are about to. The root causes are wide ranging, but more often than not, the problems arise from mistakes and/or omissions very early in the development lifecycle. This is such an old story that one has to wonder - why have people not yet learned that a stitch in time saves nine?

The answer, I believe, is that mainstream approaches to the software development lifecycle still lack mature techniques and accompanying tools in the early stages. For example, even when a project makes an effort to construct use cases they often turn out to add low value. This may partly be because use case design has been stripped of entity modeling aspects included in its original formulation, aspects designed by Ivar Jacobson to help ensure the viability of use cases. However, a deeper reason is that current techniques used early in the development lifecycle are incomplete. We need more than better use cases - we need more than use cases per se.

Despite dramatic improvements in the last few years in many aspects of software production, such as the emergence of agile practices (including practices associated with iteration such as test-first coding) and higher-level code generation techniques (ranging from programming tools such as “model-driven architecture” to systems for process and rule definition), there have been only minor improvements to the way in which people understand the business drivers that cause software to be constructed in the first place.

For example, consider Rational Unified Process (RUP), which thanks to adoption by IBM is one of the most widely used software development methodologies. Proponents of RUP claim that it is an almost universal technique, offering support for iterative approaches despite its traditional waterfall origins. RUP has given rise to an “open” descendant, Open Unified Process (OUP) which is also touted as being adaptable to pretty much any software project.

RUP and OUP place particular emphasis on the early stages of a project, with “Construction” being deferred until the third of four phases, and practitioners being encouraged to use structured disciplines for Business Modeling and Requirements Analysis. However, dig a little deeper and the picture starts to develop cracks.

In particular, the “Inception” phase of RUP is supposed to include development of a “business model”. What exactly is a business model? Well, who knows - certainly, there is little in RUP itself (or the accompanying IBM toolset) to explain the term.

The main clue is mention of “business” use cases, as opposed to “system” use cases. This is a useful distinction, but not a very clear one, and does not go anywhere near far enough. Where are the business objects of primary value identified, their lifecycles described, their stakeholders defined, and the interactions between these stakeholders captured? Where are the drivers for high-level system strategy, and the mechanisms for implementation of this strategy? How are domain security models to be understood and related to user experience models?

TAKE AWAY

Mistakes and omissions made early in a software development project are always the most expensive sort. Unfortunately, they are also by far the most common sort.

In this new series of blog articles, I will be suggesting ways that you can improve the early stages of the software development lifecycle, by reference to the business modelling techniques of Goal-Oriented Organization Design (GOOD). GOOD was created as a methodology to assist implementation of Human Interaction Management (HIM) techniques and tools - and a key driver for HIM itself was innovation in requirements analysis (see the HIM Web site for details).

If you are interested to learn how business motivation modelling, process architecture, organizational design, edge stories, user profiles and classic scenarios can help you capture and analyse requirements more effectively, then stay tuned to this blog.

Posted in Requirements | 2 Comments »

Implementing HIM

January 15th, 2009

I was asked to summarize some aspects of Human Interaction Management for a research report by a major consulting company. Readers of this blog may find my response useful, so here it is.

Added Value of HIM

Pareto’s law tells us that the 20% of “exceptional cases” account
for 80% of the costs - but it does not tell us why. To discover why,
and deal with it, one must appreciate that “exceptional cases” are not
exceptional at all. They are the norm, since they occur all the time - further, they are what truly test your business practices.

To deal with the “long tail” - i.e., to operate efficiently and
effectively in a globalized economy - one must abandon the hopeful
notion that business processes can be defined once then run thousands
of times with only minor change. One must create an operational
environment in which change is not only possible, but structured,
encouraged and aligned with strategic objectives.

This means taking a much richer view of “process” - a view in which people, communication channels, knowledge, time and plans are all managed along with the activities
that are more easily visible - across multiple domains that include not
only you and all your trading partners but also your customers.
Bottom-up empowerment is not enough. Top-down control is not enough.
You need an enterprise management framework that supports both, at the
same time, using the same approach.

Consider some typical human-driven processes:

A bid to build a new range of aircraft;

A joint venture to expand operations into a new region;

The acquisition of a former competitor;

Development of the new look for a product;

Creation of a marketing campaign;

Management of hundreds of software engineers;

Response to emergencies;

…

HIM improves the efficiency of such processes, by allowing
organizations to reduce or eliminate the estimated 28% of knowledge
worker time that is currently wasted due to poor control of human
interactions. However, the primary concern in such processes is to succeed,
from the perspective of the customers, vendors, and individuals taking
part. HIM goes further than cost and time reduction - HIM improves
knowledge worker effectiveness. By showing people the context
in which they are working, and the value they are expected to deliver,
HIM allows knowledge workers to use their skills and experience tomake informed choices about the actions they take and the resources they
use.

Potential Bottlenecks of Implementing HIM

To encourage success, you must empower people to work as
well as possible - to use the skills that they were originally hired
for. HIM, and the accompanying method GOOD, create organizations based
on negotiation and trust rather than on rules and control.

This does not mean abandoning hierarchical management!
Rather, the approach allows each level of management to do what it does
best:

The board can define strategies;
Executives can create routes forward that implement the strategies;
Managers can implement the routes.

However, senior people often feel it is dangerous to
empower people - that people may go off at tangents, or abuse the
system. This is the main obstacle to organizational transformation via
HIM.

To overcome this obstacle, it is necessary to explain how HIM is a
systems approach with feedback loops that actually make such
organizations more reliably focused on results. HIM and GOOD not only
make more dynamic organizations - they make organizations that perform
better, and act more safely.

Best Implementation Route for HIM

The initial step in adopting HIM is to hold workshops in which the organization discovers the processes that:

Cause most pain to it, its customers, and its staff
Offer most potential for transformation.

For this purpose, I find a combination of techniques useful.
These techniques are lightweight - a day or two is enough to discover
the areas that need immediate attention. Then GOOD can be used on
those areas to apply HIM.

Often, the output of a workshop is nothing more than a 1-page
diagram. Many people find it incredibly helpful just to have a simple
way of understanding what is going on - this alone can be enough to transform the way they work, and help them to deliver huge value to their organization.

TAKE AWAY

In the 20th century, competitive pressure led
to the transformation of routine work via Scientific Management,
Statistical Quality Control and Total Quality Management.

In the 21st century, competitive pressure will lead to the transformation of human-driven work via (I believe) HIM and GOOD.

It is a new age, in all sorts of ways, and organizations must make
radical changes if they wish to prosper. Fortunately, the changes are
straightforward, and benefit everyone involved. It is an exciting time.

For more information, see the HIM Web site.

Posted in Business Process Management, Knowledge Management, Management, Productivity | No Comments »

The Business Process Spectrum

December 7th, 2008

Explanation soon … watch this space!

Posted in Business Process Management | No Comments »

Keith’s adventures in BPMN - Conclusions and a look forward

October 20th, 2008

In my last post, I quoted an article on this site by Jon Pyke in which he looked forward to 2 new generations of BPM tools that provide support for knowledge work. The first of these generations integrates Case Management with process technology. The second goes further to support Human Interaction Management (HIM).
Jon is now the Chief Strategy Officer of Cordys, who along with other key BPM players are now bringing to market the first of these developments. What is involved in the second step? And why is it necessary?
As regards what is involved, I have tried to illustrate in this blog series some features of HIM that go beyond the capabilities of current process and case management technology, even offerings that appear to be at the leading edge. HIM notation directly addresses five aspects of management with which organizations are currently struggling:

Teams
Communication
Knowledge
Time
Planning

Further, the current inexorable trends towards outsourcing, partnering and sub-contracting as the fundamental means of doing business in a globalized economy mean that in each of the 5 aspects of management above it is critical to support decentralized, cross-boundary processes where there is not necessarily a single process “owner”.
To meet these requirements, a new paradigm for process description is required - one that is based not on state machines in which the process is a clockwork mechanism that moves from stage to stage, controlled centrally by a single engine, but on object models where a process is a set of objects in different domains, whose interaction and synchronization is controlled collaboratively by agents acting on behalf of each player. This new paradigm is what HIM notation, and the underpinning HIM semantics, provide.
As regards why this is necessary, one only needs to read a newspaper. The global economy is in meltdown, for which the deep reason is simply the advent of the Web, with the consequent rise of “Asia, Automation and Abundance”. Computing has brought a huge sea change to our world, a change to which we are too close to see the true scale. The only way to survive such change is to adapt, which means taking dramatic steps early on. For once, only the early adopters will survive! Those that wait until new ideas have been fully tested will be out of business before they get a chance to put them into practice for themselves.

Scientists are starting to realize that information processing may lie at the heart of many different aspects of nature (see, for example, Charles Seife’s “Decoding the Universe”). Similarly, mathematicians are starting to understand how the notion of computation explains many of the dramatic results of the last hundred years (see, for example, Gregory Chaitin’s “Metamaths - the Quest for Omega”).
In business, an equivalent conceptual breakthrough is taking place. Pareto’s law tells us that the 20% of “exceptional cases” account for 80% of the costs - but it does not tell us why. To discover why, and deal with it, one must appreciate that “exceptional cases” are not exceptional at all! They are the norm, since they occur all the time - further, they are what truly test your business practices.
To deal with the “long tail” - i.e., to operate efficiently and effectively in a globalized economy - one must abandon the hopeful notion that business processes can be defined once then run thousands of times with only minor change. One must create an operational environment in which change is not only possible, but structured, encouraged and aligned with strategic objectives.
This means taking a much richer view of “process” - a view in which people, communication channels, knowledge, time and plans are all managed along with the activities that are more easily visible - across multiple domains that include not only you and all your trading partners but also your customers. Bottom-up empowerment is not enough. Top-down control is not enough. You need an enterprise management framework that supports both, at the same time, using the same approach.
Change is never easy, especially when the luxury of taking your time is not available. However, as you can see by watching lynchpins of the financial world topple one by one, right now there really is little choice. Yes, you need to improve the 80% of processes that are mechanistic, using current mainstream BPM techniques, but this only brings you up to the level of your competitors. To stay ahead, and stay in the game, you need to improve the other 20% of processes that cannot be fully planned in advance - and do it at enterprise level.
Find out more about HIM here.