We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anne Stuart’s BPM in Action

Michael Dortch

BPM, Business Intelligence (BI), and Enterprise Applications, Continued: A Natural "Procession?"

Vote 0 Votes

I am now the happy recipient of several comments in response to and/or in the same "neighborhood" as some of my recent posts here. Those comments come from David Chassels, CEO of a company called Procession plc. Procession specializes in "task-oriented" applications that embody the principles of human interaction management and are intended to deliver the business benefits promised by BPM. A standards-based process engine provides integration of disparate processes, and process-controlled data transformation. This enables implementation of integrated processes without expensive, clumsy custom adapters. And by my lights, what else you get is the ability to build applications that don't just support business processes – which are driven largely by how and why people interact at work –but are based directly upon them.

Neat. But at least as neat, at least to me, are David's thoughts about where BPM fits and does not fit, and what works and does not work where BPM implementation is concerned. In response to my recent post on business process profiles, David said that he thought I was generally "on the right track." He then went on to say that a common mistake is to think that a modeling tool will answer all the questions and challenges related to capturing and documenting business processes. Such tools often "try and address too many audiences with different agendas – the business, the analyst, the systems architect, the programmer and IT support," David said. The result: a "broad overview, but for none the detail required to take [their specific issues and challenges] forward."

"I can only speak from application build in our [BPM-enabled application-building environment], and nothing beats the good old-fashioned…direct discussion with business to establish who does what at each step, what information do they need, what are they allowed to do (and not do) and what reports do they need to create. [A]s you suggest, word processing or even a writing implement will do the job [of capturing this information] quite adequately. Armed with this detail the application can be built in days with no coding or compiling. It is not rocket science as some would like to promote! But it only works because there are only two parties involved – the business person and the business analysts who builds in a dynamic environment with the business involved at every step. All too simple…but it works!"

If, as I've written here before, BPM needs to be human-centric, pervasive, and invisible to users, it's got to get woven into the fabric that makes up the applications and services people use to do work. I think David and Procession have a very powerful spin on this idea, an approach worth noting whether you're an IT decision-maker trying to make BPM work at your enterprise, or a vendor looking to compete…or partner. (Procession recently entered into a "collaborative business relationship" with Atlas GOSS, a provider of support services to global outsourcing service providers (OSPs).)

So how, if at all, are you integrating or planning to integrate into your enterprise's applications or services, whether your enterprise buys or sells such things? Do let me know, so we can continue this evolving, fascinating, and timely conversation. Meanwhile, I appreciate David publicly, for writing, for allowing me to quote from his comments, and for convincing me that even if I'm crazy regarding this stuff, at least I'm not alone.

(By the way, a new RFG Research Note summarizes and expands upon several of my recent blogs about BPM-related vendor evolution. Please check out the Note in the RFG section of the Analyst Corner of ebizQ. As always, your thoughts welcome.

1 Comment

| Leave a comment

Hi David

As the originator of Human Interaction Management (HIM), I really have to comment on this!

David Chassels and I correspond from time to time, he comments on my blog, and so on. So I know about the Procession toolset, and can safely say that, despite the frequent references to HIM in Procession collateral, their software does not in any way implement HIM or the emerging type of software application known as a Human Interaction Management System (HIMS). To the contrary, it is very similar to old-fashioned workflow.

A focus on tasks and their types is really the traditional approach to work management, isn't it - dating back to Adam Smith's "division of labour" that revolutionized industrial production. Via Scientific Management (Taylor) and then Quality Management (Deming), this perspective gave rise to workflow applications and subsequently the BPMS as we know them.

Interestingly, there is renewed interest in task management in the programming community, with Mik Kersten's Mylar framework in the vanguard. This is a natural continuation of Taylor and Deming, since programming is after all a manufacturing activity.

My view (as readers of my own ebizQ blog will know) is that what works for manufacturing and other such "mechanistic" activities does not necessarily work for all business activities. In other words, a task focus may be appropriate for mechanistic work, but the class of business processes that I call "human-driven" - innovative, adaptive, collaborative human work - is not helped but rather hindered by focusing on tasks.

We do not judge books by the number of words they contain, or the average length of each word - and authors do not base their efforts on such criteria. Neither should we try to measure and implement human-driven business processes by focusing on tasks. Rather we should start with goals, look at how these map to business objects, ask who has which responsibilities for these objects, and so on - the core precepts of the GOOD methodology that underpins HIM. Then we will start not only to leverage but to properly value and recompense the less tangible efforts that are in fact the key drivers of business success.

This set of ideas, known collectively as Human Interaction Management, flies in the face of a typical workflow/BPM focus on tasks. Acceptance of such an approach is the step change one must make if one seeks to optimize human work in the enterprise, and the route to such a step change does not lie with conventional workflow applications - however they are marketed.

All the best

Leave a comment

Business process management and optimization -- philosophies, policies, practices, and punditry.

Anne Stuart

I am the editor of ebizQ.

Recently Commented On

Monthly Archives