Defining a BPM strategy is a SKILL!

I am working currently on an interesting BPM assignment where a company wants to transform into a lean-mean-insurance-machine. Aggressive business targets, the typical time to market, reduce cost per policy, increase agility and total visibility on all multichannel (web, fax, phone, postal)/multilabel processes. And the typical realization: gosh, we have applications dating back from the sixties and seventies, they are not up to par to this new business context - we need a business AND IT transformation... Risky stuff.

Interestingly, what I observe, is that this company (and many others) is struggling with the further detailization of the business targets, in terms of SMART and especially the translation towards a new process architecture (how do the new processes need to run to reach these targets), and the requirements towards the IT solutions.

Key observations:
- People from IT and business are a bit stuck in the current way of doing business
- New processes are not fully defined
- Requirements are not stable and not complete
- Real BPM knowledge is scarce

It triggered two thoughts:
1. To really be able to do a solid process transformation, that can support new business targets, you will need good BPM knowledge! It is a set of skills on its own! BPM is a practice.

2. What are these skills? What are products that a company need to really define and implement a new business situation, to reach the targets?

To start with the products:
- A detailization of the targets (SMART, more operational)
- A process architecture (based on analysis and redesign)
- A organization (or business component) architecture
- A managementmodel (what to measure, how to steer the operations)
- A channel model - what processes to lead through what channels (and how to influence your external stakeholders to comply)
- A logistical model - how to assign tasks in a lean and mean way to humans (workflow) and machines (STP), for instance using skill/competence based routing
- business rules model for proces flow

When you have this al stabilized, then it's time to start defining requirements for IT support...
- Process engine
- Desktop (inbox, data screens, document management, outputmanagement)
- Integration-architecture of components
- BAM

The skills? Well, maybe we are no longer speaking of a BPM consultant, but we need specializations. Skills that we look for:
- Management consulting
- Process analysis and design (possibly including simulation)
- Architecture design
- Performance management design (CSF's, KPI's)
- Requirements analysis and definition
- Business case development and validation
- Logistical knowledge (lean-six sigma)

And then I don't even what to talk about the people skills, change management skills and facilitation skills (because many decisions and changes need to be done...)

Maybe it's time to start working on a Body of Knowledge for BPM specialists. From process mentality, maturity, analysis & design to IT solutions requirements/design...

Traffic jams and agile thinking

A bit off topic, but definitely linked to agile thinking: I will be moving to a new apartment in a new town. One of the disadvantages of the new town is the traffic jams towards my current job. Having tried the typical morning mess a number of times, it started me to think about a key concept in agile thinking: work in short chunks.
Well, traveling from and to work is the same. My current commute is about 40 km. A relatively straight road, not too many exits. The changes for a obstruction, accident, road-work are not that high - I have to deal with less risk, basically. The new route that I will take is longer. More exits, more merges, more chances that people will create a mess. (Didn't Sartre once say - "Hell - that's other people".... well, find yourself in a traffic-jam, and you'll remember ;-)).
I realized that all these traffic jam thoughts and frustrations were an advocate for the typical agile principe: work in small chunks. If possible, create a short route to a good base-point. Balance between distance and an arrival-position that adds value. Not too short, because the value delivered will be too limited. Not too long, because a higher risk that traffic jams will occur...

IT process management vs BPM

Have been working very hard on a IT Process Assessment for a client.

My finding: IT proces = proces = comparable to elements from BPM (but done on the IT side).

I started to see that we can learn quite some things from the IT-side, about process frameworks and process maturity.

1. Frameworks

For various IT processes, pre-defined procesframeworks exist, that can help you to quickly implement IT related processes, based on the experience of many companies (aka best practices).

To name a few:

- RUP and CMMi for Software Engineering

- ASL for application management (IT side)

- BISL for functional application management (business side)

- ITIL for IT service management

I know that there business process frameworks as well. For instance SCOR: http://www.supply-chain.org/page.ww?section=SCOR+Model&name=SCOR+Model

Frankly, I have my doubts here. For the general processes (hygiene, aka sending invoices, transporting products, etc) I can understand the use of them. But let's face it - to keep competive edge, are you going to implement "best practices" proven by other companies? I think not - I would be working based on the NEXT practices...

As an extra thought: many BPM-Suite vendors also claim that the tools come with process frameworks ("buy our tool, and your insurance claims process is already provided as a template"). Hm, sorry, but can a BPM-Suite vendor tell me, as a business specialist, how my business is run best? I doubt it.

2. Proces maturity

The CMMI has a great set of so-called "Generic Practices". These practices are about process maturity - the extent that you perform these practices, tell you something about your process maturity. These generic practices are general available (on the CMMI Sei site).

To quote some (Copyright SEI:):

'A managed process is institutionalized by doing the following: [CL103.N106]

- Adhering to organizational policies

- Following established plans and process descriptions

- Providing adequate resources (including funding, people, and tools)

- Assigning responsibility and authority for performing the process

- Training the people performing and supporting the process

- Placing designated work products under appropriate levels of configuration management

- Identifying and involving relevant stakeholders

- Monitoring and controlling the performance of the process against the plans for performing the process and taking corrective actions

- Objectively evaluating the process, its work products, and its services for adherence to the process descriptions, standards, and procedures, and addressing noncompliance

- Reviewing the activities, status, and results of the process with higher level management, and taking corrective action'

Is this useful for business processes? Yes! It provides an excellent assessment and growth framework, that's generic and easy to understand. I wonder why we don't have this yet on the BPM side: a clear maturity framework, with key generic practices per maturity level.... Let me know if you know more about this!

Gosh... (and talk about FM, CRM and BPM)

Gosh, someone linked to me (almost gives me a feeling of "Someone read my blog, therefore I exist). But Wolf, thanks for the kind words!
See: http://www.schumacherpartners.net/documents/0670615C0DCDCEC441AECAF116A0A186DDFDB1C7.html#12Jan2007
Wolf triggered me to write about something that is surprising me, even to the point of irritation (must be my preference for clear concepts)...
A newsgroup item triggered it before (as an example):
http://tech.groups.yahoo.com/group/business-process-management/message/267


Let's do some history.

Many, many years ago, someone invented the term Financial Management. And if you talk to managers, they actually have quite a clear grasp of the concept: a school of thought, set of tools, processes, etc to keep control of your finance (aka, value, money, debts, etc). What type of tools? Well - budget, actuals, general ledger, bookkeeping, reporting, balance sheets, etc. What school of thought: well, that it is handy to keep control of finance (of value), to keep your business healthy.
Did anyone say "technology"? Well, sure, but I (happily) do not hear anyone saying: Our accounting system (GL, AP, AR) IS financial management. Maybe that it supports it (quite efficiently and correctly, hopefully).

Now, let go some years back (where things got confusing). Someone comes up with the term "Customer Relationship Management". Some research and some thinking gave me quickly the understanding that it refered to a school of thought, set of tools, processes etc to keep control of your customers. What school of thought? The one that said things like : it is handy to understand your customers, and know a lot about them. It's is good to support them through the lifecycle (or in human terms: the period that they are interested in doing (repeated) business with your. And tools and patterns appeared around front office, call centres, multi-channel services, etc. Did anyone say technology? Well yes, and there we lost it somehow - CRM suddenly became synonym with systems. CRM=Siebel. And the problem was: companies started thinking that implementing Siebel would give them CRM. Company happy, customer happy. Right.... I think the confusing wasted many investments, and it took us years to get back to the original school of thought: know thy customer (and implement thought, mentality, processes and (some) support technology).

Last but not least - BPM.
In many postings, and vendor presentations, I see the same thing happening: Our tool XYZ is BPM. We do BPM. By implementing our tool, you do BPM. BPM is an extension to workflow. BPM is system to system orchestration. BPM is SOA. BPM is BPEL.

NO!

Let's agree:
When we talk about BPM, we talking about stuff to get and keep control of our processes (like finance and customers important assets for a business).
And sure, technology can support our BPM efforts. And let's call this technology BPM Suites. Not more, not less....

Ok, I'm getting of my soapbox... ;-)