BPM, BKM, and the Seven Ps: Processes

BPM in Action Blog

« Getting to a "CPR" Approach: Follow the "Seven Ps!" | Main | BPM: Too Fast for Textbooks? »

April 12, 2007

BPM, BKM, and the Seven Ps: Processes

Does it seem weirdly recursive to discuss the need for processes to manage processes? (Don't worry; it's a rhetorical question.)

My ebizQ blogging colleague, Keith Harrison-Broninski, is engaged in a friendly debate about processes engendered by a response to one of my recent entries here by David Chassels, head of Procession plc. I'll have more to say about this debate in the future. For now, however, I'll say this. The debate has inspired me to refine some of my thinking about the interactions linking people and processes.

I think I now think there are two classes of processes – task-driven and human-driven. I think I also now think that task-driven processes define and/or how tasks get done, often by IT systems and resources, while human-driven processes define and/or describe how people do things. Both are essential to successful business operations. However, they are very different from one another, and cannot likely be equally effectively addressed by any common set of processes or technologies. For example, it seems likely to me that it's easier to automate task-driven processes than human-driven processes. I'd bet that often, the most IT can hope to do to support human-driven processes is to capture information about them in ways that make it possible to document and build upon them.

So what's needed are processes designed to take all of this into account in ways that enable consistency, manageability, and rationalization with business goals and requirements – and how people do things. Because after all, BPM and BKM are, at their core, about how people do work, work that typically requires them to perform tasks that manipulate information. Clear so far? Good!

It often helps efforts intended to enable effective BPM and BKM to use each of the seven Ps to frame and prioritize enterprise-specific questions focused that particular P. Here are some examples of such questions for processes.

• Are all knowledge/process management processes sufficiently aligned with one another, and with those governing business and IT goals, operations, and services? If not, how can they be so aligned?
• Are processes governing IT solution assessment, deployment, and integration sufficiently informed by process/knowledge management efforts?
• Are processes that govern other initiatives, projects, and tasks designed to support and comply with knowledge/process management processes and goals? If not, how can they be so aligned?

These are just examples of starting points for discussions of process/knowledge management processes at your specific organization of choice. The most important bits are to start the conversation, and to use it and the results of it and related initiatives to expand and refine your portfolio of business/knowledge management processes.

There are six more Ps to go, and each has a significant processes-specific component. Keep these things in mind while addressing the other Ps, and getting to effective BPM and BKM just might be a little easier for you and your colleagues. Do let me know, please, either way…

Posted by mdortch in BPM • Business Knowledge Management | Digg This | Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/1688

Comments

Hi Michael

Thanks for this - the partition of processes that you describe is essentially the idea that I try to promote, with only slightly different terminology - the processes you term "task-driven", I term "mechanistic".

You write, "I'd bet that often, the most IT can hope to do to support human-driven processes is to capture information about them in ways that make it possible to document and build upon them." At present this may be true, but I am attempting to provide software support for human-driven processes via a new kind of process engine.

You ask a set of interesting questions about such processes. You may find this article of value: A New Approach To Quality.

--
All the best
Keith

Posted by: Keith Harrison-Broninski at April 12, 2007 04:22 AM

Michael:
I am interested to see this distinction coming to the fore, and I agree with you. I also think that you may be getting to the heart of why (as it was reported at the recent Gartner BPM Summit) 80% of the BPM implementation work is still happening at the first two steps on the 'BPM Maturity Model'. Maybe the 'hangup' is that we have BPA and BPM tools that do a great job with the task-driven processes, but are not such a good fit with human-driven processes.

I recently communicated with Keith [Harrison-Broninski] on a related topic. I had heard from some prominent Analysts that about 70% of the business process analysis work being done today is still being done with Visio. Keith agreed. Since Visio seems to be the tool of choice for capturing human-driven (and other) processes, everyone would be better off with a tool that (to paraphrase a Gartner analyst) lets people 'use Visio better.'

Posted by: mtalaba at April 18, 2007 03:57 PM

Of course system tasks and human interaction driven ones are different. That's OK but they must be seamlessly joined up and that means one technology otherwise more unnecessary complexity. All this requires is a custom "business object" to suit. The "human" one requires roles and performers assigned automatically as the process starts. Everybody knows what is expected i.e. their "goals" and empowered to just do their job however loose or prescribed as the process design dictates. Most system tasks are invisible just happen in the predetermined sequence and have different characteristics as a business task object. All this and putting the right information to the right person at the right time are all "organised" by a process engine.

A good BPM solution should be supplying "real time" information to allow a dynamic measurement of all people activities to continually optimise efficient achievement of goals or output. The step to allow users to build at run time a custom process within agreed parameters (to ensure content integrity) is now available. The next step as Keith has alluded to is the self-adjusting process that can recognise the need to change dynamically. It is all now possible which puts business knowledge as driver in this new breed of "Dynamic Applications" as now being described by Forrester Research Inc

Posted by: David Chassels at April 19, 2007 10:37 AM