« Live from Delphi - User Centered Design for Process Redesign | Main | SOA, BPO and business rules »

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go. Last one was Derek Miers on "Achieving Enterprise Agility". Derek started out by pointing out that many definitions of process are based on manufacturing - orchestration - and not enough on collaboration - choreography - important as knowledge workers tend to need choreography not orchestration.

BPM is primarily a business philosophy, not about technology. How do people work on their processes and meet their objectives. Clearly there is technology that supports this but the business approach is key. Lots of reasons for doing this including customer-centricity, compliance, innovation, IT reuse, agility, risk management and so on.

Multiple interpretations of process - purpose of an organization (that orchestrates functions through practices) or a set of procedures lumped together. Implementation normally mixes practices and procedures. Processes might be one or the other or a mixture. Clearly those that focus on procedures, which tend to be more established and higher-volume, are where decisioning comes in. They tend to focus on repeatability and speed and be back-office focused. Practices tend to be more knowledge-centric and flexible and suitable for processes being done by knowledge workers.

People often show a 75-80% production, 15-18% collaboration, 2-4% ad-hoc and 1-2% exceptions. Even very repeatable, high volume processes still have some collaborative exceptions. Contract negotiations might be completely ad-hoc. He made the valid point that even if much of your process is production then much of your cost could be in the ad-hoc, collaborative stuff.

• Think Big - have an overall plan and have a decent project methodology
• Start Small - try something that can be completed in 60-90 days tops
• Iterate - keep getting better

Derek also encouraged folks not to over model or put too much in a repository before implementing - his preferred approach is to build some high level models from various perspectives and then implement and iterate. He also discouraged too much focus on input/output modeling as this can perpetuate processes to manage the information flow where a more radical approach might be to solve the business problem with less or different data. Lastly he suggested that folks "start again" when they being to iterate, using the initial models to help with understanding rather than trying to build on them.

Derek went on to discuss the Business Process Maturity Model and how it might be applied by organizations to help understand what kind of solution/approach is appropriate. This approach, based on the CMM levels, is described over on the Teraquest website. Derek clearly feels this is a useful approach while I remain cynical - I think we need to see more mature process-centric organizations before we can really establish a model for them. Interesting stuff though and the authors have clearly done lots of high-quality work on it so check it out.

There was one point he made with which I am going to disagree - he said that when things go wrong companies differentiate themselves. While this is true, one would hope it is a minority of instances that go wrong. Thus if they go right most of the time then it is how they go right that differentiates companies. Amazon is not differentiated by how it handles problems but by how reliable its core process is.

Technorati Tags: BPM, BPMS, business agility, business process management

Posted by jtaylor in Business Agility • Business Process Management • Business Rules |Digg This|Add to del.icio.us

Trackback Pings

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