My blog
has often addressed leading edge techniques for the integration of business processes
with an enterprise IT backbone. A particular focus has been "human-driven"
business processes - those in which people not only enter data and record decisions
in online forms, but where they also collaborate with each other and leverage
business intelligence to create and innovate business solutions.
In recent entries I have articulated a top-down business process management
methodology which addresses the most pressing needs of the modern enterprise
- to acquire the agility necessary for survival in a globalized, wired marketplace,
while simultaneously complying with statutory regulations and company policies,
all within a safely controlled management hierarchy. Here is the methodology
in outline:
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 often in this blog, 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.
-1-