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...
2 comments:
Hi Roeland, What you put across in this small blog is precisely what most of the industry fails to understand. Well they are not to blame since most of the so called IT Research Companies fail to make the difference between BPM and BPMS, they use these terms loosely and interchangeably, which leads to further confusion.
The most dangerous element in the success of any BPM is a management who assumes itself knowledgeable about BPM.
A bottom up approach, IT to Business, to educate such players must never be practiced.
Unfortunately, this is the case often. At last, techies end up defining BPM directions.
What’s the other choice in situations like this?
Thanks
AB
Post a Comment