Gartner BPB Summit London, Day 1 - Part 1

BPM Summit Day 1 – Part 1
Also see: http://www.gartner.com/2_events/conferences/bpm2.jsp
I had a somewhat slow start at Gartner’s BPM Summit. Although presentations were okay, I actually did not hear that much new. My lesson: although Gartner is an important player in the research area, the summit does not hit that much in depth real life lessons.

A summary of presentations.

Bill Rosser kicked off an introduction around BPM as a discipline. Nice to see someone actually trying to define what is meant by discipline (in his terms: an area of study/ expertise/ knowledge, a set of principles/methods, and a set of rules of conduct to comply with).
A returning item in this and later presentations was the trigger to get started with BPM and related technology: 1. Improvements (e.g. cost, customer value, time to market), 2. Agility and 3. innovations. In the eyes of Gartner, although process improvement is a good goal, it’s a bit limited compared to the potential of BPM. But a necessary step in the adoption of BPM.
Starting with BPM could be done top-down and bottom-up, the latter being the most frequent encountered, according to Gartner. Bottom-up has it’s risks, mainly in loosing focus and early termination. It’s main CSF’s are good champions and good results, that are marketable towards sr. management.
Another repeating subject was the need for business to realize that functional orientation and corresponding business area maximization will most likely lead to overall sub-optimalization. Key is maximalization over the whole valuechain (starting with your own company off course…), and a combination of functional and process orientation. So process orientation as a complement to traditional functional management.

Nice to see that Bill talked a bit about the change management and the area’s of interventions (as I wrote about earlier: BPM is a set of interventions, in my eyes). Areas included organization, technology, culture, to build trust, rewards, ownership and the right attitude, through for instance education and methodology standards. He warned that these interventions could take 2 – 3 years to yield result and that you need to time these interventions right: if going too fast, you might not get the results (ouch, a valuable lesson for me, who typically is too much ahead…).
He also warned about the discipline: while it is important to approach process management as a discipline, one should be careful not to create a “harnas” with too much discipline demands. Don’t focus too much on standards, tools etc. Overdoing it could harm progress. In my perspective most companies I meet still are quite under-disciplined (read: adhoc), but the US-situation might be different.
And a last lesson: while running your BPM efforts, communicate communicate communicate. Have process visibility as key focus.

During the opening keynote we heard there were about 450 delegates. Not bad for a European BPM Summit! A summary was given on Gartner’s6 best practices/key elements for BPM: Alignment, Culture & Leadership, Methodology, People Skills & Roles, Governance and BPM Technology.
A quite good presentation was given by Mark Raskino. While stressing the fact that we are in a 3rd wave, and that BPM is a must-do, he also warned that BPM is a hype currently, and that expectations are inflated. The real valuable lessons will need to be learned the hard way: by doing, partly failing and recovering. A path I am very willing to take, and am taking every day. The key lesson: again, this is not the silver bullet, the “plug & play” solutions that will magically solve issues, like CRM, ERP etc promised before.
He talked about the mindset of managers, and what would convince these people to go BPM. Quite simply: cash flow, market position (not to be bought, but to take over yourself), your stockprice, your competitive edge (something that might be good now, but is deteriorating quickly, and management’s knowledge of the pain (and fat) in processes. His key remark: Process maturity (read: your ability to continuously improve) is a sustainable competitive advantage.
An analysis of the market developments showed that this advantage is quite needed: globalization (in terms of offshore resources, capital, markets and conditions for execution of processes) and regulations/compliance (which will grow due to the ease of internet).
His premises: the question is not if you will do BPM, but how well you will do it….
And he predicted that business process may well start to be recognized as intangible assets that will start to appear on companies balancesheets (now, how’s that for “management!”).
He stated a solid wishlist for managers in 2015, and striking was that BPM was a requirement in most of them. Research showed that CEO’s were seeing this too, and that even CIO’s (although a bit hidden in research) were responding with changing investment patterns.

Some concluding remarks:
- Essential in BPM is to create a number of process abstraction layers (which I recognize in my projects).
- A nice metafore on the changing IT landscape: from Stonehenge (legacy) to Lego city.
- Business intelligence will become a critical element in BPM: Without clear measurements, discussions on which process to improve and why will stay highly political and not objective.
- BPM Suites are currently highly oversold, and under-delivering (a finding which agrees with results from the CIO research)
- IT should NOT be the BPM leader, but the enabler.

And a last theme, that came back later: IT’s is slowly becoming a more planned (IT portfolio) area, but for BPM that’s killing: you don’t want to put in a process-change request at IT, and wait for X months. You want it within days! It made me aware that something like IT portfolio control, which seems like a nice idea, is actually not something business is glad about…. Chances are that when introducing BPM, we need two processes for change: the quick one, for BPM (maybe even with business doing it themselves) and the slower one (custom code maintenance, etc). Mark warned that to keep good time to market for process changes, the number of people/layers involved in a change should be minimized (otherwise too much noise, time, cost). And I agree – agility on the deliveryside could do wonders here!