Tuesday, March 27, 2007

BPM Summit Day 1 - Observations

Pffff. How would you feel after a day at a congres about "Wordprocessing". Envision a congres hall, filled with 20 vendors. Each trying to talk to you, and show you their great product...
"In our app, you can type text and print it"
"Well, in ours you can type it and see it WSYIWYG!"
"Well, we work on all platforms"

Ok, now I know: BPM-Suites can model processes, execute them, measure them, and sometimes simulate them. Sure....
The key question: what's the differentiatior????

I remember Lean, where a lot of attention of going to the customer and the customer journey: what to do to fullfill your need.
My prediction: in the BPM market, it's going to be about understanding of the customer's business context, your professional services and training capabilities and your turn-around time to deliver real solutions, based on your track record.....
And for customer's it won't be easy to surf this vendor space.

Of course I can help :-)

BPM Summit Day 1 - Part 3

I went to a presentation by Janelle Hill (quite strong presenter, I must say), about new roles in the BPM area. She talked about the new "Process Excellence Center" or PEC, and the typical roles involved with BPM: process owner, process analyst, process consultant, process architect, PEC manager.
I must confess I am a bit hesitant. Everytime a new technology or thoughleadership reaches us, we are talking about new competence units. I remember the BI cc, the Java cc, the Client/Server cc, the Process Modelling cc. Sure, as a first step, some network of expertise is needed, but let's face it: do we have a "Money management center of excellence"? No, we have integral management, where finance is a part of the responsibility of a manager. Process management should be the same, with, sure, a backoffice or consultancy organization to support this manager.
What did trigger me was the notion of the expectations of IT and the attitude towards risk of management. When you have a situation where management is low risk, and sees IT as utility, coming from the IT side, pushing BPM will be very difficult. And trust me, I have been there... Working for an insurance company, with basically no appetite for innovation (unless it was pushed down from management), being an BPM evangalist was not easy....

I was quite happy being at the next presentation, by Singularity. Well, ok, this guy was just reading out-loud (yep) the full presentation (including the jokes, ouch!). But it did make a good point accross: case management is a fundamentally different add-on to BPM.
This is something I have been noticing as well: when modelling processes, you will come into business situations that will seriously challenge your modelling skills and also will exceed currect "production workflow" capabilities of BPM-suites.
The singularity guy showed a pyramid - with in the base typical "hygiene" processes: able to model at design time, limited complexity, limited collaboration. In the higher area's you get to processes that can be classified as...
- Many possibly events that need to be handled, with unpredictable occurence and sequence
- Intelligence at RUN time, a case handler that will decide that certain steps are needed in addition, or certain tasks will not be...
In one word "Judgemental processes". Examples include a doctor's visit, certain insurance claimes, pre-sales, exceptions, etc. Highly unpredictable and context-sensitive.
In my experience when you hit these types of processes and trying to BPMN them, you end up with a milion exceptions....
The key concepts in those types of processes:
- Process fragments, little pieces of process that can be added to a process instance
- Business rules, that will govern which fragments can be added in what conditions
- Events that will trigger changing the case processes and approach
- Case state that will determine where we are, and if we are finished
Definitly a new BPM area!

A quite good presentation was done by Nuon, one of the leading utilities companies in The Netherlands. Finally a solid BPM and SOA real-life projects, with some honest lessons and CSF's.
Their need was to reach as state where they were able to change processes in a matter of days/week instead of the typical 18! months. The market (customers, compliance, take-overs and mergers) was requiring this. They created a flexible SOA infrastructure with a BPM engine on top, and stepwise refined it. A bottom-up approach, quickly spreading the word and adding processes step by step.
A quite good prep-action was to define a reference architecture with layers and principles, around among others the service governance, the change control, etc. Some policies included:
- Stateless services
- A provider of contentservices (data, functionality connected to a business process) will not deliver the SOA/BPM infrastructure and vice versa (to prevent vendor lockin)
Well, they have processes running! Even changing them (cycle time: less than a month!). And with bottom-line success, including a nice decreasing days sales outstanding (DSO).

A last presentation by Global 360. Some concepts:
- Transformational applications versus tactical applications
- If your process needs more than 2 systems to work, forget the agility....
- Process intelligence (including BAM) will likely to be a separate domain, with it's own technology (BAM, simulation, workforce planning)

A last gem by Janelle Hill:
- In our age of information overload, process provides a context for information! More about this later, based on a great presentation on day 2 about collaborative BPM trends...

BPM Summit Day 1 - Part 2

BPM Summit – Day 1 Part 2

I went to the SAP presentation. I must say that I was disappointed – it was more a high level product overview and sales talk. Hm.
It was interesting to see that SAP has transformed itself from a pure ERP player, to a middleware supplier (they stated that they were #3 in the market) and active SOA/BPM standards pursuing company. Question stays if customers actually want that. Nuon for instance stated explicitly: our BPM and SOA layer provider will not be our “content” provider, and vice versa, to limit vendor lock-in. But with an installed based of 38.000 clients and about 12 million users (wow!), some will accept both ERP and BPM/SOA infrastructure from one vendor, I guess…
SAP is of course also busy with their industry templates. Nice to hear that they had a set (in R/3) and decided to simplify them! A lesson that a lot of template providers (to be) will probably still have to learn (and their customers…)

Loose gems from different sessions:
-Oracle: SOA will fail if you do not approach it with a BPM perspective.
- Global360: BPM is a success if you talk to an end-user and they only talk about their application (preferably: their “transformational application”) using only business terms and not mention any tools such as BPM. Aka “Our loan application”, “Our customer portal”.
- Let go of the word “Maintenance”. When approaching applications with BPM, let’s talk about iterations.
- BPM as technology will only deliver process effectiveness, not delivery efficiency. You will need to analyse processes and improve them yourself (using methods such as Lean-Six Sigma, Simulation and Process Automation).
- When starting with a process, a number of starting points exist: bottom-up (what is done/needs to be done), top-down(what goals, what measures).
- You might want to implement processes as-is with a BPM Suite, to be able to start gathering information, and then improve.
- Key question on BPM maturity: are you using BPM technology in AN application (Point Solution), or did you create a BPM Platform to be used by all process aware projects?
- A lot of companies (Oracle) are starting to offer “industry process templates”. Gartner predicts that these templates will become valuable assets. But not all agree.. The key question is: will this add value? Some say: we are not interested in the BPM-S Supplier X Order-To-Invoice process, we want to know how say Procter & Gamble is doing it. The closest companies to get to that kind of information will be process modeling companies and the larger system integrators… And not so much the smaller BPM-S suppliers…

Following later - an interesting presentation about Casemanagement, which in my view is a NEW addition to the BPM field (although some companies have been understanding this already for a while, among others pallas athena, singularity and metastorm).

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!

Sunday, March 25, 2007

Will be @ Gartner's BPM Summit in London

Oops, have not been blogging for a while. Busy with a large BPM design for a migration factory. And for my own migration :-) : moving to a new town. Dust is settling now, so time to blog more about BPM (lot's of new insights...).
Well, I am in London, and while be joining the BPM summit of Gartner. Will try to blog each day on the highlights. Looking forward hearing the newest insights on BPM. The program is loaded with potential interesting presentations!

Friday, March 02, 2007

BAM and visibility - driving 50 Mph without a steeringwheel?

Recently I say two interesting articles, dealing with "management" as a separate proces-area.
http://bpmbusiness.typepad.com/business_of_bpm/2007/01/bpm_and_six_sig_1.html, who writes about control and BAM (and confuses the two)
http://www.bptrends.com/publicationfiles/advisor20070227.pdf, a good article about management as a process, in relation to BPM.

I am working currently on an interesting project, which needs to quickly build a administration factory, that is able to handle a large volume of transactions (which are partly client facing, partly technical, involving a large number of stakeholders, including the unavoidable indian offshore backoffice). My client has already done good work on the key processes, however I quickly discovered that we needed to distinguish between a number of proces area's, with different levels of control.
The first level was the operational level: the exact process to handle a transaction. Most focus seem to go here, typically (and also for this client).
However, two more levels were needed:
A level, which is above the transaction layer, which I call the "logistical process layer". It's the whole operational planning and coordination of the large volume of transactions. Here, business rules and approaches such as Lean, TOC and operations research come in. At this level we design the factory, making sure it will be able to support the transaction amounts.
A third layer is what I call "governance". Here we talk about planning and steering on a higher level. Maybe you could call it planning & control, or simply management: making sure the goals of the factory are reached.

Back to management. I find it interesting, that a lot of attention in the BPM area is currently going to BAM - Business Activity Monitoring. And most people are enchanted - wow, we can provide management with almost real-time information at their fingertips.

My observation:
If your car is running at 50 Mph, the oil level is fine, the lights are on, the motor temperature is on, the airconditioning-temperature in the car is 20 degrees celcius, the time is 10.25, engine RPM is 100, and you see a tree approaching fast, a steer and a break would be nice....

In short: BAM without a Control mechanism does not add value
(well, ok, at least you'll know you will crash)

Or: don't measure if you can't steer
(So, I agree with Gartner that visibility is a great thing as a result from BPM, but it's not the full answer to business BPM needs...)

It links back to a lot of lessons people learned from Business Intelligence projects. Sure, in the beginning management will be thrilled, and will ask for various KPI's. Even so for BAM.
But quickly, you will find they are no longer looking at all the numbers. Why? Because KPI's that are not in their control are simply not relevant. KPI's that are in their control, and (ok, this might be simplifying things) are linked to some personal commitment (such as bonus, prestige, pain-such as be fired) will get the most attention.
Actually, KPI's that are not in their control will make them feel awkward (compare it to the feeling you get when confronted with global warming, hunger in africa, forrest destruction in brazil - it's all in the news (KPI's), but what (little) can I do about it??)

So, when designing a BPM environment, advices:
- Do design a management proces as well (plan do check act)
- Determine what controls the manager has (and which are linked to his/her(!) areas of interest)
- Define the KPI's (and frequency/events - alerts)
- Make sure that the controls are in some way known/modelled as well "if KPI X is below Y, then ....."

Hm. Controls. E.g. the "Act" when the "Check" did not satisfy the manager. What type of controls can you think of?

Here we get back to classic management theory:
- Operational management decisions:
- Set a different priority for a certain task/set of tasks "staff, please fix Client A NOW!"
- Re-assign work "Jim, please take over this task, and Mary, take Jack's job"
- Shout "Why didn't you do this already??" or ask "Could you please handle this now?"
- Quickly add resources "Get some temp workers right away"
- Create adhoc fixed to the process, probably specific to a certain transaction "forget check A for now!"
- Adhoc reward people (with money, fun, interesting challenges, etc)
- Coach, coach, coach
- Tactical management decisions:
- Send people to training
- Replace people, increase staff or decrease
- Analyse waste (Lean), including Defects (why, how often, how to prevent?)
- More structural changes/optimizations to the process - tune logistics and business rules
- Automate certain steps/innovate certain parts of the process
- Reward people more structurally (and grow them)
- Fire the manager :-)

A BPM system (or a manual BPM framework) will help here. A BPM system can support quick tuning of process (steps, assignment rules, flow business rules)

- Sure, a maximum optimized operational process is needed...
- However, if the management proces is ad-hoc, chaotic and immature, I bet fire fighting will drive out any good operational process
- And let's not forget, these managers are expensive, so let's make their process as efficient as possible as well :-)

So, are you designing operational processes with control in mind?
Motto: if the manager wants BPM, then his process will be BPM-ed too!