Take-aways from BPM-Forum session

Recently I visited a session of the Dutch BPM-Forum (http://www.bpm-forum.org/), where a dutch Insurance company talked about the implementation of a BPM tool (in this case http://www.cordys.com/) for a claims handling process.

Some key take-aways:

1. In the experience of the insurance company, in the end, the tools were NOT the issue. Most time was spent on understanding processes.
In my view, this is essential. Many vendors claim that their tools can do magic. Well, sure, but you still need a lot of work trying to understand and correctly model the processes. Business analysis is a key skill that you need in a BPM project, so be carefull with BPM projects run as an IT powerplay.

2. They understood that the processes they were trying to model, where too difficult to define in a sequential flow model. There were too many exceptions and possible events with unpredictable timing. They decide to take a Case management approach.


A great pictore from vd Aalst (professor on BPM at Technical University of Eindhoven, The Netherlands) that was used:


Also see: http://is.tm.tue.nl/staff/wvdaalst/workflowcourse/slides

My lesson: start with processes, and be very aware of the complexity. Don't use a modelling tool to understand the processes (because it will make you see reality through the limitations of the tool), but first seek to understand more freely. Then make the call if this is sequential/decision stuff or more complex event-based/collaboration based stuff, and pick the right tool for modelling and execution for that.

3. Essential for the business case, was the ability to use existing functionality. They found ways to abstract and use services provided by the legacy system. This allows them to use current investments, while opening the possibility (through the abstraction) to stepwise replace legacy with new technology, as long as it delivers the same service.

4. A good strategy was the focus on external partners. Part of the strategy, from the start, was the ability to integrate (from a process and BPM-suite) perspective with events and processes from and to other players in the service chain.

5. They kept Content solution and Process solution separate (but did integrate it).

In my opinion important. Currently some businesses invest heavily in ECM solutions and take a document-centric approach to process, implementing process in the ECM tool. In my view, documents are a temporary solution for information exchange. So, base your proces engine on proces, and let it integrate with information providers, including unstructured/ECM suppliers.

Functional or process oriented? Or is there a 3rd way?

Now, with the increased attention to BPM and processes, many companies are asking themselves: should we organize through function or process?
Some choose to stay in functional units, but increase the collaboration and create end-to-end governance and measurements (with often much politics).
Some turn the company sidewise, and create a more process driven organisation.

Of course, most of us understand the thoughts behind this.

Functional:
Pro's
- Focus on competency
- Easy to bind people - sharing the same work/chain unit
- Focus on scale efficiencies
- Relatively easy to measure
- Relatively easy to understand

Cons:
- Loose of focus on the complete chain
- Chance that units strive for suboptimal choices, that effect overall process effectivenes, efficiency and responsiveness (agility)
- Difficult to implement new or changed processes
- Pointing to each other when issues, no clear process coordinator

Process:

Pro's
- Focus on end-to-end responsibility
- Grows understanding of the full chain
- Outside in thinking , customer focus easier to keep
- Easier changes to processes
- Reduced or no interdepartmental hand-overs

Con's
- Chance of fragmented knowledge and skills
- Could become complex, depending on complexity
- Loss of checks and balances
- Simular functions are done in other proces organizations, leading to loss of benefits of scale

In my opinion, there is a third way, that combines best of both worlds.

Service Oriented - with process management.
STOP! If you now are thinking about webservices, ESB's, WDSL, BPEL and other stuff - reset please. I am talking about business services.
Think of SOA as another way of structuring. Instead of focus on FUNCTION (we do X), Process (we undertake X, then Y, ... then Z), think of a structure of loosely coupled units that provide a certain function, in the context of one or more processes.

Think business lego. Easy units that we can quickly reorganize into new value chains.

A critical succesfactor for this is the ability for each unit to partner. To quickly understand it's role in the whole, and adapt internally, if needed, to supply the correct service. Call it "Chain Service Intelligence". This is not a skill that is easy to develop! It should be deeply embedded in the people, the attitudes and culture of the organization.

Another succesfactor is the question: where do we put operational process management?
In a functional organization, this was always the issue: it was implicitely put in the functional units themselves (I am responsible for part Y in the chain....), but no-one felt responsible for the whole chain (Well, I handed over on time, so it's not my issues...).
So, how do we build and maintain chains of services?

I believe we can create flexible businesses with small "service units". But that we also need a central service, responsible for end-to-end processes. A unit, that has 2 responsibilities:
- Operational: managing/coordinating concrete execution of processes. E.g. a "case manager" that monitors the execution of proces XYZ for customer ABC. Customer focus and delivery focus.
- Tactical: staying focused on delivering process outcomes within set goals and boundaries, and where needed, improve processes (possible, supported by a Process Center of Excellence) - both from a internal stakeholder perspective (investors, employees) and customer (service, satisfaction). Basically, this department owns the "Change process" (which is a normal process, part of the process portfolio).

Lean and BPM - growing attention. But where are the Academics?

I just saw two articles on the use of Lean in the context of Business Process Management (published through BPM institute, ah, at least one BPM group that is surviving ;-)).
See:
http://www.bpmenterprise.com/content/c070618a.asp
http://www.bpmenterprise.com/content/c070625a.asp

And I am glad that we see this trend developing. In my opinion, Lean is a great process improvement framework, that we can apply in the area of BPM.
The big change from the BPR times is this: When BPR was big, basically the only process improvement groundrules we had, were, well, take a blank paper, and start all over.
But... where we used to have the "magical" step, going from current state process to future state, we now have a growing set of best practices and frameworks that make the process improvement step more based on sound research and practical experiences at other companies (such as Toyota).
Type BPM and Lean in Google and there are more and more hits.
The same on BPM and Six Sigma.
Great!

The only thing I am waiting for/hoping for is more activity in the field of academics - research on process concepts in the services industry... We need sound research and a better conceptual framework for service processes. While great work has been done on operations research and management, in the area of logistics and manufacturing, the "logistics" in services are not well understood. We know there is things as "cycletime" "Work in progress inventory" "flow"
"resource scheduling". But we need a better framework of theorie and optimization methods.

Anyone that has a perspective on this - reactions welcome!

(Dutch market): Lean survey

A request to my readers in The Netherlands.

In the Netherlands, there is a growing interest in Lean (a process improvement framework, based on the Toyota Production System).
A collegue of mine is researching the use of Lean in the dutch market. He is working for a unit that helps clients improve on Operational Excellence.
He is looking for people that are working for businesses (so, preferably not implementing consultants) that have been involved in Lean, that are located in The Netherlands and that are willing to spend 2 (well, 5 is more likely) minutes to fill in an online survey.
What's in it for you:
- Receive the results (and gain more information on the use of Lean)
- A chance to win a good book on Lean (for your next Lean project ;-))

And an extra request, if you fill it in, please remark on the last survey page, that you found the page through this blog...

Thanks!

The original request (Dutch):
"Lean is ‘hot’. Steeds meer bedrijven en sectoren adopteren het Lean gedachtegoed in hun streven naar efficiëntie en productiviteitsverbetering. Niet alleen binnen productie en logistiek, maar bijvoorbeeld ook in de energiesector, zorg en financiële wereld worden de principes van Lean veelvuldig toegepast.

Capgemini is een onderzoek gestart om de toepassing van het Lean gedachtegoed en de doelstellingen die organisaties hiermee nastreven in kaart te brengen binnen de diverse branches en bedrijfsfuncties in Nederland.
De resultaten zullen u de mogelijkheid bieden uw positie in te schatten. Met andere woorden, het zal antwoord geven op vragen als: wordt Lean veelvuldig toegepast binnen mijn branche? Welke tools worden daarbij gebruikt en met welke doelstelling? En zou het gedachtegoed van Lean wellicht ook voor mijn bedrijf effectief kunnen zijn?

Wij vragen twee minuten van uw tijd om antwoord te geven op zes korte vragen. Ook als u nog niet eerder bekend bent met ‘Lean’ kunt u de vragen beantwoorden. Uiteraard ontvangt u na afloop van het onderzoek de resultaten. Tevens maakt u door het invullen van de vragenlijst kans op het boek ‘Lean Transformation’ van B. Henderson en J. Larco.

Open de onderstaande link om direct de vragenlijst te openen:
www.operationalexcellence.nu "

BPM is about change - and change is about people

As a consumer, I am often amazed about the inside-out thinking of companies (not the customer is focus, but the company - and the customer has to live with it, or leave.... and most time they will...). And in addition, to the many many basically terrible processes that companies have, leading to awfull customer service, mainly caused by unawareness and lack of ownership.

The basis truth is: customers come and stay if service is good. And let's define the basis to service: it's that simple (well...) chain of all the little steps-actions-thoughts-decisions and ownership that people in your business take when trying to make a customer happy. It's the people!

As a short example: I am spending 4 months now to get rid of my Internet connection (that I cannot use even at this stage). Am struggling to order new furniture, where the company forgot to send me the requested proposol ("because person X was transfered and forgot to hand over"). So today, when I went to a shop for new contactlenzes, and everything just went fine (they even had the right data on me), I was even a bit amazed (and satisfied!). These people simply cared and had their processes in order.

As BPM specialists, I think we sometimes forget this, and focus on process too much. If we magically analyse the proces, identify gaps, issues, find the causes and remove them, processes will flow again. Sure, this is part of the needed intervention, but it's not enough: in the end, it's the people, and the chain of their actions, thoughts and ownership....

Coincidences do not exist I think. Currently I am doing two projects that are forcing me to see this fact and deal with it. And to be honest - I like it. My BPM attitude and efforts are suddenly growing to something I could call, well, group therapy.

For instance - I am currently working with an insurance company, that is struggling with a key area in their change operations: how to deal with changes, linking to their processes and IT solution. The key area I focus on currently is requirements.
I have the luxury that I can interview many people, based on a structured interview template, that covers process, concepts, stakeholders, issues and possible solutions. It's a great way to see through a group, see many viewpoints and perspectives, and identify patterns, shared images of issues, but also explicit or hidden differences in point of views (and even disputes).

First of all, I started realizing that this set of interviews is already a process intervention - by asking certain questions, people started thinking about things and became aware of their own actions and the consequences it had. They started seeing the chain (or at least part of it)!
But a key realization: for many people, playing a part in a customer chain, is like the group of blind men touching the elefant... they all assume they understand, but never see the full picture.

The next step (which I find somewhat scary) is that I will feed back the findings of all interviews to the group as a total (in a workshop), checking with them the correctness of my findings (and note - correctness is not reality - it's perception of the group). Maybe the elefant becomes more visible. I will also let them prioritize as group the biggest issues, and let them brainstorm on possible solutions + prioritize. Again an intervention (and almost group therapy) to make them realize the current state of how things are going and make them understand that THEY are in the lead to create a good, outside in, process, but more important that this process can only work if they care about it....

Maybe we should not talk about BPM, but about MPATEY - "My Process Actions That Elevate YOU (the customer). Eg.... empathy for the customer :-)
Are you focused on the people? If not, then realize: blueprint thinking on process is a nice and safe way to understand and to design, but it's only part of the solution...

Collaborative and Mobile solutions from MagicMonday Amsterdam

A bit off topic, but in a way linked to new ways of interaction during business processes and knowledge work...

I attended a great event yesterday in Amsterdam: Mobile Monday (http://www.mobilemonday.nl/, Dutch).

Two things came up, that showed interesting innovations for businesses, in the area of B2C (or better C2B!) and G2P (Group to Person, sorry my invention :-)).

1. Backchannel (G2P)
A new concept for me, very new generation internet type. The concept is simple: a presenter is giving a speech, supported by visual material (such as a Powerpoint presentation). At the same time, a large screen shows comments by the group listening to the presenter. This could vary from questions, doubts, observations, new insights to (realtime) results of research (is this person telling the truth).
What's nice about it:
- It made the whole group feel much more involved.
- Easier and faster to interact with rest of audience (react to eachothers comments)
- It made boring parts of the presentation much more fun :-)
- The comments are kept (on a website) and can be reviewed later by presenter and participants (would be nice if there was a playback with timed backchannel, a type of voice over :-))

Where I have my doubts:
- Well, I am not a part of the new internet generation, that can MSN, listen to music, watch tv and do homework at the same time. The constant stream of comments distracted me from the speaker
- It would be nice to filter out questions to the speaker and keep them on the screen, till addressed. Now it was still a blur of all kinds of comments, which kept going...

For some pictures of the concept....
http://www.flickr.com/photos/marjolyn/530670411/ (backchannel on the right)
http://www.flickr.com/photos/64015000@N00/530485307/ (backchannel image)

For a list of comments during the presentation (partly dutch, partly english):
http://www.flickr.com/photos/64015000@N00/530485307/

2. Mobile concept: barcode scan by mobile phone camera
There was a presenter from http://www.op3.com/, who are working on a new way of C2B (Customer to Business) interaction: through barcodes.
Some example scenarios:
- You walk around in museum. Every object has a barcode close to it. Scan the barcode with the camera on your phone, and additional information will be displayed....
- You walk on the street. You see that a lamppost is broken. The lamppost contains a barcode. You scan the barcode, which automatically informs the local government to fix it
- You want to get a coffee in your company or make a copy of some paper. Coffeemachine/Copieer broke. You scan the barcode, and your mobile phone informs the vendor that repair is needed.
- You see a poster of a cool new band. Scan the barcode and your phone shows you more info and enables you to order the cd, download MP3's or order tickets for the next concert close to you...
- You are buying a trainticket. The trainticket contains a barcode. You scan it, and your phone immediatly informs you about the fastest trainroute and interesting (well for you personally) things to do in the place of destination.

This is just a short brainstorm, but I do see large potential. From a lean perspective (outside in) it's amazing how difficult it often is to fulfill your need as a "consumer" (yikes). It involves searching, going places, asking, uninterested personnel, waittime (so it takes 2 months to get this couch?) etc. Technology that we as buyers could use to quickly find our way to the right product would greatly improve our lives. Not to forget the advantage for the companies...

A key lesson on process analysis & (re)design

Together with a team, we recently completed the process analysis and redesign for a specific process area for large bank.

I wanted to share some of the experiences and a key lesson.

We took the following approach:
1. Understand current process (including visual model) , through workshops and document review
2. Deepen understanding, by finding process statistics
3. Design future state process, by using elements of Lean and common sense
Step 1 - requirements. Step 2. Activities. Step 3. Responsibilities. Step 4. KPI's
4. Analyse automation possibilities, and define use cases, non functionals and preliminary IT architecture (iterative)
5. Develop business case and different scenario's

We delivered the following, in a way a fairly complete business architecture
- A proces diagram (with annotations) current state
- A proces requirements document future state
- A proces design (logical level) future state, annotated, different levels of abstraction and use of swimlanes
- An organizational design (with FTE calculations)
- A use cases document and non-functionals document (together: software requirements)
- A preliminary IT architecture
- A cost/benefit analysis spreadsheet with different scenario's for implementation (including options such as BPO and offshoring the development of the proposed IT solutions).

All deliverables have cross-traceability (for instance a proces step links to a certain requirement, links to a certain use case and feature of the proposed IT solution). Handy for consistency checking..

Nice was the active application of Lean thoughts. For instance:
- An active focus on the customer requirements: what would a customer require in terms of proces, product and service? And what steps does a client need to take to go from need to solution- and are we able to help with these steps or simplify/reduce?
- A split of the basis flow (main proces, which can include detection of exceptions) and exception handling processen, to make sure that the main factory process continues.
- A clear split in plan-do-check-act cycle activities.
- Just In Time approach, with zero - to close to zero work-in-progress inventories
- The use of takt-time as a basis for "flow design" and calculation of effort.

Key Lesson - split requirements and design

When I was still on the techie-side of things, we had a rule "the sooner you start coding, the longer it's going to take", promoting the importance of clear requirements and a thought-through architecture. Well, I think the same is true with Future State business process modelling. In the beginning we brainstormed and modelled a bit on future state, only to realize that, together with our client, we needed to take a step back.

What we did, was the division of process abstractions in:
- A set of requirements
- A logical model (with no implementation decisions yet)
- A physical model (with implementation decisions, scenario's, such as BPO and IT)

This greatly improved and focused our effort. We were able to facilitate our client through process requirement sessions, where questions were asked such as:
- What are the goals?
- What should have been done, to consider a process instance to be done totally?
- What should be the result of the process execution? In what dimensions measured?
- What should be CSF's and KPI's?
- What stakeholders are involved? Why? In what responsibility/accountability and added value?
- What requirements will the main stakeholder, the CUSTOMER, have? (VOC).

The key strength was, that the customer started to see that certain requirements where not compatible and needed prioritization (sure, you want low cost, high quality, agility, speed, compliance all at the same time, but that's nirvana. What's most important?)
And that the procesmodelling effort for the future state was a simple exercise, using the requirements as a basis. The modelling refined some of the requirements (feedback learning), for which we used traceability and version control.

Note: in the logical procesmodel we identified different processes - from workfloor to management.

After the logical procesmodelling was done, the next step was to explore implementation choices in the steps of the process. Can we automate X, can we outsource Y? It lead to a number of scenario's and a proposed physical process design.

Although it sounds a bit top-down, through iterations we made sure that requirements, logical design and physical design were synced and improved where needed. The result - a happy client, with a sound plan for his business. Next step: getting it decided and live!

4 reasons to capture your events

A common reason that I hear from companies, for embarking on the BPM journey is process visibility. The so needed knowledge about what's happening in the company, to be able to assess status, progress and strategic alignment.
In my opinion, visibility starts with events, and to begin with: the external events: situations where you as a company are contacted by an external stakeholder (customer, supplier), which triggers a series of activities.
A good start (which any secretary can tell you) is to have some type of incoming event recording system. Why?

4 reasons:
1. To help customers trust you - it is so strong if you can tell the customer - "sure, we have received your order, change, complaint, at date XYZ". Events are integral information in your customer relations history.
2. As part of your record management system (compliance, auditing)
3. As major input for your KPI's & management information (how many order-requests have we received?)
4. As input for your inline simulation engine

The last option is a fairy new feature in BPM engines. It saves you enormous time if you don't have to dig up all kinds of events information, to be able to run simulations.
Inline simulation helps you to see what results would have been, based on your past actual history, if you change certain business rules or processes....

The good news is that you already probably have many event capturing systems. Unfortunately, the events are not seens as separate entities, but are translated and deeply burried in your ERP's, CRM's, Web logs, batch-audit & signal files, Document management systems, not to forget masses of emails and paper documents.

It would be good to see a new module in your enterprise architecture: your event capturing and recording system. Let's call it the Event-Friend :-)
A system that recognizes events, stores them and dispatches them based on business rules to people, BPM suites, ERP systems, SOA orchestration stacks, etc.
And in the future maybe even more intelligent - able to relate events (which one belong to another) and see patterns, trouble (new account opening, and directly a cancel?) or fraude...

An essential element in your future Event Driven Architecture.

Do you have process maturity at the right place first?

Today I was "babysitting", taking care of a 2.5 year girl. Wonderful. Outside, sunny, and running around together with this gorgeous bundle of joy, energy and learning. It's a wonder to see small children learn. I must say, evolution has given children the right tools to grow up:
- Great Curiousness
- Joy and Courage
- The will to repeat again and again and again, (and getting better all the time as a result)

It made me realize an important thing about abilities in a company. There is quite some talk about "Business process management maturity" models. As a sidenote: did you ever meet a CEO that stayed awake at night, worrying how to get higher in the maturity model? Right...

Anyway, children grow up and learn. And they have the right skills for this learning.
But if we want to help grow a company, and get better processes, where would you start?
I have seen many checklists to hunt down the right process. The biggest bang for you buck, the most visibility, the best etc. Frontoffice! No, backoffice! Uhm, supporting processes first. No, the most fat slow cost-intensive. Probably, they are all right a bit.

But maybe more important than which process to pick, is the question how to proceed. Think of any activity in your company that delivers change. So, not the base processes (sell, procure, invoice, etc), but processes that change these base processes. Not much companies realize they have many of these types of processes as well. Some of them:
- New product development
- New IT systems
- Responding to changes in legislation
- Updating your brand and communications
- Management wanting a new way of reporting
Etc...

Now think about your strength in these types of processes.
As a small example, I worked for a company selling insurance products. They were ok doing that. But developing new ones or changes? A nightmare. No visible process, more a large group of people spending most time influencing and disagreeing. Efficient? Right.
I don't think that in general, companies are strong in their change oriented processes.
Now, compare that to the little girl, and her great learning ability....

Maybe when we are starting change or improvement projects, we should spent more time growing our change/learn ability. See this as one of the strategic goals in your project. Maybe even assess it first, and become aware of common pittfalls in your company.

Your change ability is:
1. a CSF for any running project or change process
2. A competitive advantage in general (confirmed in research on High Performance Organisations)

So, if you want to grow process maturity, grow your maturity in your change abilities first (or too!)

A tale of "moments of truth". 7 rules for Customer Management.

Ok, deep sigh, I had a "MOT" with a big company in the Netherlands. My telco provider, to be precise. (For MOT: see http://apply-mag.com/mag/farming_moments_truth/)

And it made me, sadly, realize, that BPM is SO necessary.

Short recap:
- I moved to live together with my girlfriend
- Both of us have broadband ADSL connections, at the same provider
- For some strange reason, KPN/Hetnet have a "year subscription"rule, e.g. if not cancelled at last month, you are forced to stay another year (something that in my recollection only weird bookshops still try to do).... even if you have been subscribing for many years, as a happy paying customer....

Since I moved to a house which already had a ADSL connection, I called my provider to see if I could cancel my own. Two subscriptions on the same address would not work anyway.
What follows (and I will not go in all details) were the usual 15 calls, press 1 for, no we can't do this, sure we can, endless music and a growing frustration.

Some of the experiences made me realize that outside-in thinking, MOT's and event driven companies are a FAR future in many cases.

My lessons:
1. Sure, a call center is nice, but make sure that you have identified your common EVENTS
2. Make sure that for each event a protocol or process exists. It should not be too hard to think outside in, and collect most possible events that can occur with your customers. And decide how to deal with them....consistently.
3. Decide who you will assign the process coordinator role. And make sure it is NOT your customer. In this last MOT, I had call center agents, requesting me to call back in 2 days, because then a certain change would have been processed. Me.... with the typical re-explain story all over again, including the earlier discussions no,,,yes,,,but,,,,
4. Consider to assign "a problem owner". Someone that simply says "Sure, I understand your event, I understand our steps to fulfill your needs and comply with our standards, and I WILL TAKE CARE OF IT". My name is XXX, and you can always call me at ..... I will call you as soon as.... Make sure that your customer does not need to understand the internal working of your company, to get his or her problem solved.
5. Train your staff to record decisions and status. Ah, I see you have called us before. Sure, the status is now xxxxx, and no, you don't have to explain again or go into discussion again. Nice for your customer, even nicer for your internal coordination mechanismes.
6. Don't make your customer feel that when signing up to a service, all lights are on green, and when in a later stage all lights are on red. A sure thing to get them really distrustfull.
7. Treat a loyal customer good.

Amazing that when you talk to these companies, which I often do, they have fancy process management tools, BAM, SOA, etc. But the key thing they forget.... the people that buy their services...
Process maturity is not about technology, it is about understanding that every MOT (moment of truth) is created by many small actions by various people in your company. BPM can be used as an intervention to get these actions aligned. It asks for a culture of customer orientation, getting the job done,.... simply maturity.
Maturity. So... Grow up! (or be gone when your competitors understand this better....)

Sentence of today "culture eats process for lunch every day."

A short post...:
Great article...
http://www.bpminaction.com/blog/2007/04/success_with_bpm_a_cpr_approac.php

"culture eats process for lunch every day."

What a great way to understand in a split-second that all your BPM efforts, often IT driven, will face an important hurdle, that will make you realize that process-analysis and design should be driven by people and culture first, and then IT....

Spring is here - time to approve standards...

In a relatively short period of time, I have seen important approvals of standards, related to BPM... BPM is on the move.

1. BPDM seems to be approved
See: http://www.modeldriven.org/web/bpdm
Still unsure how BPDM and XPDL are related. Will need to research this. Comments welcome.

2. BPMM
The business process maturity model (with a foundation of CMMi)
Also see: http://www.omg.org/docs/bmi/07-03-04.pdf

Very handy as reasonably objective framework for measurement and improvement planning.

3. BPEL 2.0
The business process execution language, version 2.0
Also see: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
and... http://www.oasis-open.org/committees/download.php/23665/wsbpel-v2.0-OS.htm

I have not checked BPEL 2.0 yet, but do hope it has now capabilities for human workflow as well....Anyone knows?

Star Rating added

I've added a 5 star rating widget (http://spotback.com), which allows visitors to score individual articles. You're most welcome leaving a score, after reading an article! Your scores are an important KPI in my BPM-BAM dashboard ;-). Thanks!

Future Feature of BPM-Suites : Predictive BPM

I remember, when working for a large insurance company, that they were struggling with workforce planning. Basically, once a year, they looked at the average workload per employee, and based on that estimate and some predictions on future developments, they agreed on the workforce numbers for different teams in front- and backoffices.
What they forgot were seasonal influences. In insurances, a lot of work happens during the beginning of the year (renewal, new pension plans).
A typical result was the following: agreed workforce started in januari, and (since workload was much higher), a backlog of work started to grow. Managers unsatisfied, pressure on teamleaders and, in the end, the workforce. Around june, backlog was unacceptable, expensive external temps were hired, which caused an initial extra drop in productivity (more experienced workforce needed to guide temps) and in, say oktober, things started to be in control, leading to november estimations for the next-year workforce, where, well, you guessed it, memory was short, so about the same numbers were planned....
And customer service? Well, in this company, it was seen normal that pension overviews of the previous year were send in Q3/Q4 of the next year on average.....

Of course, workforce planning is sometimes difficult. It requires process maturity to measure, be realistic, and take out politics. It takes process maturity to evaluate plans and have the courage to adapt when needed.

A great thing would be, if BPM-Suites came with a feature, which I would "predictive BPM".
Take a typical moment in time, with a running BPM Engine. A great number of process instances exist, each with a certain state in their flow.
It would be great if you could ask your engine the following basic questions:
1) How much workforce effort is needed the coming say 10 weeks, to finish the current process instances, if these processes are to be finished in a certain (SLA) timeframe?
2) What is the estimated influx of new process instances for the coming period, based on a seasonal analysis of previous years?
3) What is the total required workforce (current process instances + new instances) to finish all work required to meet SLA's?

Sure, this is complex stuff.
A BPM-S would need (or a tool above the BAM/BPM Suite):
- Knowledge of workforce - all people, their productivity, their work-assignments
- Knowledge of procesflows - typical flows per process (% for each branch and sub-branch)
- Task duration and effort
- Process history - a log of all process start events in previous years, #per day, % per type per day

But what a great planning tool would be possible. I could even see business analysts help managers with what-if scenario's...
- What-if our competitor is delivering 10% faster throughput, how much more workforce or productivity increase would we need?
- What-if we are able to change seasonal influences with some incentive?

In manufacturing, this type of planning is already there. The services industry is behind.

But it's promising to see that "Predictive" and "BPM" already are delivering hits on google.
Because what's process management, if the only thing we can do with BAM is look in our back-mirrors?

EDA, Rules and BPM

Came across a great diagram (sorry, (c)), which explained a possible architecture that connects Event Driven Architecture, Rules and BPM.

The elements (in sequence):

1. A business event occurs, and is signaled from somewhere (say a CRM application)
2. It's given to a Event Processing Agent. This decouples the business event from a process event. Based on rules, it translates the business event to one or more process events.
3. Process events are given to the BPM layer which starts a process (or continues a waiting one)

I like this decoupling. It creates a clear component that has the responsibility to know what is needed in terms of processes. And manage it by a rule engine.

Suppose your customer reports being pregnant... (ok, it's my girlfriend :-))

Process events for the typical insurance company:
- Time to start up a advice on life insurance
- Time to trigger some gift to be sent
- Time to inform the health insurance dept. on coming claims and required reservations....

I do still wonder where to place the logic for knowing, based on a process event, if a new process needs to be started or a waiting one needs to continue. In my view, we need some type of component there as well... with knowledge about process events, rules and current process instances that are waiting or running. The CEP-unit.

Case management - real life example

Went to a Special Interest Group meeting in my company, around the Cordys BPM product.
A group of consultants had succesfully delivered a BPM solution for a large insurance company, around Claims handling.
While they were modelling and gathering requirements they found:
- It was impossible to model a coherent process front-to-back
- Many events could happen, at unpredictable times and sequences
- If trying to model this in production workflow style, the amount of exceptions was simply too much
- Not all tasks could be predicted based on context...

No need to go on - they found the case management situation.
They created quite a flexible solution, were:
- Certain parts of the process were modelled - "process fragments"
- When a "case" was started, users could decide which tasks (and process fragments) needed to be performed
- During execution of the case, new tasks/fragments (from a standard list + manually defined - single tasks) could be added or removed
- After execution of a task, users could decide (based on business rules) if the case was finished or not.

The interesting part: they build this with a tool that was more aimed at traditional BPM. By a clever combination of some custom code + BPM parts, they were able to create a good solution.

The session did make me think about what a process really is, and what approach to choose to model and automate. A warning there: if you start projects with the production workflow BPM mindset, you will try to fit in reality (if you have a hammer, all problems look like nails...).

What is a process?
I am still struggling with this. Maybe what I will present here is rubbish, but it's a first attempt.

A process is defined as:
- A set of possible events
- A data context (or state)
- A set of possible activities
- A set of rules that govern relations between these elements

The metamodel relations are:
- There are External Events (outside of "world") and Internal Events: change of state
- (Event + Certain context/state) link to a certain Rule, that triggers Activity.
- Activity results in Change in State. Change in State triggers Event.

Now, you could define certain heuristics to come up with your "BPM approach"...

1. If all Events are known, and Each (Event-State) triggers unique Activity, we have production workflow.
-> Deterministic

2. If Certain (Event, State) combinations have NO Rule or Multiple known at design time, but do require an action (from a person!).... Case management
-> Non deterministic

3. If not all States can be defined at design time... Case management

4. If not all events can be definid at design time... hm, exceptions in workflow, or case management.

Hm, maybe it's getting late. But I am trying to find some type of BPM metamodel, that allows us to analyse a business situation more fundamentally, instead of trying to start with a workflow.
Ideas welcome!

Gartner BPM Summit London - Day 2, Part 1

Ah, a great start of the day with a good presenter: Regina Casonato.
Her research shows (and I agree, from real-life experiences) that there are processes we are currently not able to automate (well) with the current generation of BPM tools: fluid, contextbased collaborative processes.

Small example on my side: ever tried to model collaborative BPM with BPMN and Swimlanes? Right....

So where all vendors talk about S2S and H2S integration (S=System, H=Human), she helped us understand the tricky domain of H2H BPM.

Some important terms that play a role:
-> Presence.
In my definition: your own availability, in terms of for WHO, and via WHICH Channel at WHAT TIME. Something that you manage (already). However, something that in the future, you will be able to manage much more detailed.
Now: I can decide where I will be, if I pick up the phone (general or caller ID), if I will respond to IM (availability, even for certain people), etc. In the future I might detail this more: between 9 - 11 Am, I am available for BPM activities X, Y, and Z, through channels IM and email. Oh, and BPM process A, B and C I will be available during working days. E.g. detailing my presence "rules" to context....

-> Context
More tricky. Whenever we are presented by say an email or a workflow item or a phone call, or whatever thing/person that delivers us information, we need to understand why, what, how, who, when, etc. Context is what we need to be able to do something usefull with provided information and with a activity/request.

(She made an interesting link to BPM and information overflow: a process can be seen as a piece of context - we are doing X for customer Y). When delivering an activity, the process (what needs to be done) + process data (which customer, what step of the process) serve as context to the person doing the activity. So more explicit processes can help us structure reality and fight overload (well a bit - she warned for context overload).

-> Collective Intelligence
Beautifull clear concept - all the mindpower you can have, that you need to really perform some activity in a process well (think decision, strategy, etc).

Now, let's get back to the Collaborative part. Suppose a process requires a collaboration as part of a certain activity. H2H. This could be: synchronous (all people required need to be available, aka a "meeting"), asynchronous (a conversation over time - discussion/forum/email correspondence) or hybrid. The concept of presence becomes important here: a group of people receives a task. Will I get it, will I be involved, am I needed - a mix of context, rules and my presence decisions. And depending on my channel choices, I might be included through face to face, phone, chat/instant messaging, email, etc.
The key question: how to involve the right people at the right time, and support them well?
Her point is that these types of H2H interactions are currently not well integrated in BPM tools, and that if we want to take on the Information Worker processes, we'll need to rethink. From the production workflow transaction based processes (do this, do that) to a mix of do this, do that, hmmm, think about this, collaborate on that...
A mix of technologies, think networking sites (who has knowledge about XYZ and is currently present), IM, email, VOIP, etc.

It's funny, in my current project we spend quite some time how to get certain stakeholders doing certain tasks at the right time (sometimes together), and what if they are not available...
It links to another concept she used:
-> Just-In-Time Intelligence.
Ah. The right task and the right time to the right persons with the right knowledge.

Collaborative Events happening in a process flow can of course:
- Be logged -> to capture the knowledge, so that simular tasks later can re-use this knowledge
- Be traced -> to support compliance

In her view the whole Web 2.0 collaborative technology and BPM could be linked and merged.
And of course, she reminded us: don't do collaborative BPM within your company walls, think larger - customers, suppliers, partners.... How to leverage your collective intelligence!

Interesting times ahead!

A sidenote:
The concept of an Context Engine versus a Process Engine made me realize we currently mix these things. We define BPM models in BPM Suites, where at design time we decide for each activity what the means are to finish this activity (that person, that SOA call). What if we split these concepts:
- A process engine knows only about an activity that needs to be done
- A context engine knows for each activity, based on presence, contextual knowledge, etc, how to get this activity executed...

SAAS powered BPM-modeling for the traveling consultants...

Yes, I know, I am behind! I should have been blogging day 2 and 3 of the BPM summit. And I will, hopefully over Easter. Ouch, times flies, and I am in the final stage of a interesting BPM design phase, which was taking a lot of my time.

Anyway, a short post on new thoughts about the new SAAS development (or BPM ASP).
The SAAS for BPM concept is quite simple: provide a good BPM modelling tool, over the web. The process repository is hosted somewhere safe, no tools or databases needed on your PC's.
Two vendors that I know of now are working on delivering it: Appian (Appian Anywhere) and Lombardi's Blueprint. Others will follow, I expect.

Now for consultants working a lot on the road, at different projects, with different PC setups, this could actually be a great tool. How many times we have had situations where we needed to model complex processmodels really quickly, while either working on our own laptop (not connectable to client network, no printing, no sharing) or working on PC's provided by client with of course no BPM modelling tools (well, apart from Powerpoint...). Ouch. And most of these companies take 2 weeks and endless signatures to fix either the laptops or have BPM software installed (if they even have it).

So I see a new trend: "White Label" BPM SAAS, where consultancies companies can create their own labeled BPM modelling tools (oh, and while we are at it, throw in some organisation and Business/Information architecture modelling as well!). A nice collaborative environment, where projects can be set-up within 5 minutes and go.... The result: less Powerpoint frustration, productivity and collaboration + great tools to facilitate the complex tasks of process analysis, decisions and design..... And not to forget: a view for the our clients (RSS?!) on deliverables and progress.

My wishlist:
- Browser based, no added stuff needed.
- BPMN
- Create models and model-hierarchies
- Multi-user
- Version control and tracking
- Assign ownership to different model-area's (who can do what)
- RSS feeds and other update alerts on process changes
- Ability to log and discuss process questions and issues + resolutions
- Tool to extract everything in XPDL/BPDM
- Ok, tool to extract complete proces repository as some type of Office document (for easy off-line review and delivery)
- Ability to "tap into" a certain model/design session and see the live changes occur (when working in groups) and do some time of direct messaging/discussion online.

I think I will start talking to my employer :-)

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!

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!

BAM and visibility - driving 50 Mph without a steeringwheel?

Recently I say two interesting articles, dealing with "management" as a separate proces-area.
See:
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)
And...
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)

Realize...
- 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!

Some of my favourite BPM Blogs

Here are my favourites. If I miss a good one, let me know!

http://improving-nao.blogspot.com/
http://www.column2.com/
http://www.brsilver.com/wordpress
http://www.ebizq.net/blogs/bpmblog/
http://kswenson.wordpress.com/
http://www.bpminaction.com/blog/
http://blog.lombardicto.com/
http://www.itredux.com/blog/
http://www.edmblog.com/
http://www.ebizq.net/blogs/it_directions/
http://blogs.ittoolbox.com/erp/bpms

Late at night - a small Godel, Escher, Bach thought on BPM

Ok, it's late, going to bed soon.
But I got triggered by a small sentence on
http://www.bpm.com/BriefingRO.asp?BriefingId=29
stating "the need for a tool to “manage the process of process management.”

Hm. Question to all BPM-people: how is the business process management of our business process management efforts....

If I read the sentence, it's almost like getting yourself out of a swamp, by pulling your own hair (that's an old fairytale reference :-)).

But seriously, is it possible to...
- Model your process management efforts
- Execute them
- Measure them
- Improve them
?

What KPI's can we define for process management efforts?
- Nr of models completed...
- Cycle time per model...
- Complexity of delivered models...
- Cost per model
- Nr of process issues identified. Nr of solved.
- Nr of process improvement ideas identified. Nr of implemented.
- Delivered business case
- Average business case per improvement idea

A big question is: can we define a model for, say proces modelling?
And interesting - if people feel awkward here, and doubt about the possibility to model the process modelling effort, well, how do you think your stakeholders feel if you come to model their process???? Right.

Good night.

Impressed ... new BPM technology and thinking

Today I watched the webinar, that you can access via http://www.lombardisoftware.com/press-release_2-12-07.php

Impressed...
- A nice but somewhat high level Forrester view on BPM

and then the new Blueprint solution of Lombardi...
- SAAS
- Collaborative process modeling
- Drawing done for you, by the tool, you can give activities in plain text
- Linking process issues and goals of the company - traceability of impact
- Roundtrip between the SAAS repository and your business location-based BPM engine, including BAM data

Hats off.

And a tip: quite nice other BPM related webinars available there!

Lean - Waste Part 2....

Another Lean Waste element is waiting time. Time where a customer request is waiting...
Let's go back to our insurance process, handling a request for a customer (a new insurance).

Do we have waiting time? You bet...
- A request waits in the mailbox to be picked up by the business and be distributed
- A request waits on an available employee to handle it
- A request waits because the company requested additional information from the customer (incomplete or incorrect)
- A request waits on availability and action of a internel employee, to provide internal information (a decision, a review)
- A request (or following subproduct) is waiting for an automated batch process that will process it further (typically during night, or weekend, or end of month).
- A request is waiting for a manual batch driven process ("once a day, in the morning, we empty the "send files" box, book the items and give it to our team).

Observations:
- If you walk around in the these types of companies, you can actually see these queues... Try to find large stacks of files or cases, on desks, bookshelves, cars, etc). In manufacturing terms, this is called Stock or Inventory (of work-in-progress).
- A lot of the more traditional data processing financial companies find this Inventory quite normal. Always been there, we always done it this way, "no inventory is red alert - people not busy enough...."

The true facts (and manufacturing consultants will find the following observations not that surprising):
- Each request that is waiting, is NOT adding value to the end-customer. The end-customer did not ask for waiting time, he or she asked for an insurance!
- Each request that is waiting, is costing the company money.
- Each request that would be processed faster, earlier, would lead to earlier cash flows.
- Earlier cash flows is greatly appreciated by your asset management department, and your shareholders

Essential reading for the BPM consultant...
The Goal - Goldratt
The Goldmine - Balle
And check out the Lean Institute.
Good reading, also for BPM-specialists, and also for services industries....

Lean Part 1 - On Lean's Waste Thinking in the financial industry

Lean is a nice framework to use to assess processes and redesign them...
One of the area's in which Lean shines, is the concept of waste: everything which is not supporting value in the process, towards customer and towards business.
If you apply this concept to typical data processing in financial service industry area's (such as insurance - claims, quotes, etc), you can see that some of the current industry practices can be done much more efficient...

Let's take an insurance company, and a request for a new insurance.

Let's start with a waste: Defects (e.g. a product has been produced partly or completely, but turns out to be defect, which means that the next step in the process can not continue and rework is needed).
Does this happen in our process? Yep...
- Supplied information by customer or agent is incorrect
- Supplied information by customer or agent is incomplete
- Customer request is being processed, but insurance company finds out that request is not within company policy
- Customer request is being processed, but insurance company finds out that request is not within company policy
- Customer request is being processed, but insurance company finds out that request is not within legal constraints
- Information stored or created by insurance company is incorrect
- Output created by insurance company is incorrect
- Output created by insurance company is correct, but not understandable by customer (Ouch! Know that one??)

Interesting enough - if you talk to the business of a company, these situations are very common. But then, if you ask them if these situations are TRACKED, the answer is usually no...
Ouch.... defects, but no clue on frequency, impact, cost, cause, structural fix/avoidance...
The second painpoint is the reaction to a situation. Typically an expensive employee (more experienced) will need to take a look, check, and correct. Expensive stuff. Again and again.

So, why not create the following business rules in every BPM process:
1. If a defect (situation above) is detected, the normal handler employee STOPs the process, records the event, and hands over the issue to a ERROR queue (with a seperate team), then continues on the next customer request. This keeps the normal FLOW going.
2. The error team analyses the situation, corrects the situation, if possible, or stops it. If corrected, the request is rerouted into the normal flow again
3. KPI's are defined on the error situations, measured and evaluated
4. Periodically, trend analysis and problem-cause analysis is done. Corrective actions are taken, to prevent or reduce situations from happening.

Process maturity starts with acknowledging wastes, including defects...

Alchemists and the search of the AS-IS to TO-BE

Having worked with BPR beginning of the 90's, I am glad that the industry has developed. One key issue that I experienced in the BPR area was the "Alchemist" movement (don't know how to give it a better name - people that through magic searched for a way to create gold). The alchemist were usually brought in when we as BPR team were done with the AS-IS modeling, and had also identified bottlenecks/process issues/etc. (In Hammer's time: the moment in the BPR project, where one should get a blank piece of paper and draw the TO-BE)
The alchemists would look at our models, look very intelligent, and draw the TO-BE. We would create a business case (again, magic...). We would simply start coding it in Client-Server :-). And the when change management time came along, it would work. The process. Well, sometimes.
And all the time, I had this nagging feeling... why this TO-BE process. Why not another.
Having some background in Operational Research/Econometrics, I would dream of applying some evidence-based/science supported framework, but people would laugh me away.
Well, time's they are a-changing.
As BPM specialists we should understand that magical TO-BE thinking is not enough.

There ARE frameworks, that have proven themselves, and we should know about them.
- Statistical process control
- Lean/TPS
- SixSigma
- Simulation
- TRIZ

Of course, the "makeable" business is an illusion. Even if we could design the "perfect" process, getting there is a whole new game. But it would not hurt trying to get a bit more logical and (services) science driven.

Page flow versus process flow

I started noticing that in a number of RFP's around BPM-suites a requirement start popping up, that can possibly create a lot of mess.

Requirement: "When a user is working on a workflow task, and finishes it through the task window, and the process engine determines that the following task in the same process instance is to be done by the same user, the presentation layer should automatically lock and open this task, without the user going back to the inbox".

Hm, it sounds like a logical and user-friendly requirement. But in already two technical projects, based on different BPM-technology, we have been trying to solve this and had difficult issues.
One of the key problems arising here, is the mix of two metaphores: the MVC design pattern for task based user interaction and the MVC design patters for workflow/process.

Because, suppose a BPM solution supports the stated requirement, well, then it won't take very long and then someone will happily say "he, but than we can use our BPM tool to model user interface flow, e.g. screen 1, screen 2, screen 3 or 4, including all business rules". Sounds nice. But don't go there....
Why?

1. Technical issue.
In a solid architecture, user interface and process engine are decoupled with clear interfaces. User interface can use the process engine API to...
- get inbox of tasks
- claim / open task
- park / pause task
- report task ready

Most BPM engines do not support an API call, where in one transaction, one can signal a task ready, let the process engine create the next task, and ask that task immediately if it's for the current user.... It means that if a user reports a task ready, and the user interface needs to know if the following task is for the same user, some type of polling needs to be done (because you do not want to have knowledge in the user interface about the process, aka ah, it was task 5 in process B, so than I know task 6 will be for this user again - this would give maintenance on too many places...)
Pooling would be tough - the user interface does not know: IS there a next task? When will it be there (the process engine might be busy)? When it's not there, does it mean there is no task in this process instance. Etc. etc. Difficult stuff.

2. Logical issues
What is a page? What is a task?
If you start mixing these things, projects could become very complex and you end up using technology for something it is not meant to be used for (as of yet...)

In my opinion is a task a logical unit of work, to be done by one user, in (preferably) one go.
It could require a user interface, consisting of multiple pages or windows. With complex business rules. But these are MVC task/presentation data business rules.

On content, process and relation...

In modern human interaction, there are basically three dimensions that influence the effectiveness of the coorporation between two (or more) people:
- Content (e.g. WHAT, the issue at hand, what do we want to reach together, solve, do, work on, etc)
- Process (e.g. HOW, in what way, through what steps, will we get to the objectives, and the required content, who will do what when why)
- Relation (e.g. WE - how do we relate, trust eachother, help eachother, like eachother)

Picture the following example situation:
Consultant is creating a beautifull BPM architecture (content).
Presents it to his key stakeholder.
Key stakeholder says "NO, I don't think this is a good BPM architecture...."
while thinking "because I don't trust you, and you don't seem to focus on my issues...."
Consulant says "Oh, I will try to improve the BPM architecture" while thinking
"Why is this architecture wrong, I worked soo hard, I dislike this person!"

I've been there.....
My lessons (learned the hard way):
- Be aware of these three dimensions (maybe there is even a fourth - spiritual, but that's an other story...)
- Realize that handling each dimension well requires different skills, and that skills of one dimension are often useless in the other dimensions (ever tried to create a projectplan (=process) to build your relation?)
- Keep the communication open - build the relationship for this, and when given feedback or decisions try to find out where it comes from (e.g. what dimension). Don't mix it up as the example person did (which was, of course, me....)

On serial thinking and case management

It's funny - how much people will start to think accoording to a tool metaphore, and forget reality. Dealing with business stakeholders, I typically walk through existing process documents (flows, diagrams, etc). During these sessions often we come to a certain proces, where a lot of steps are modelled, all done by the same user, modelled in a strict sequence, with a lot of business rules (e.g. research 1, if A, continue. research 2, if B, continue. etc.) Standard question: do you really do these in sequence?
Typically, the answer is... NO. A business person will do these in parallel, might skip a step, and will often have their own preference in which to handle first, and last. And usually, also the business rules are not done in sequence, but as a full-check.
E.g. the proces may look like:

Act1 -> CheckA -> Act2 -> CheckB -> Act3 -> Check C

And the business will do something like:
(In any order 1, 2, 3) -> (in any order A, B, C).

These leads to a number of observations:
1. Make sure that your model represents reality working
2. If something is not sequential, don't model it like that (even though it looks simpeler)
3. Wonder why sometimes users hate workflowmanagement solutions? Big chance they are forced to do things sequential, while reality or preference is different.
4. Try not to model all these rules in your process flow. Make it one decision case, and stick the rules in a rule engine....

Now, matters turn worse, if sequential oriented BPM modellers start trying to modelling processes, where the process is more a casemanagement business situation.
Casemanagement - difficult to define, but let's give it a try:
- Typical business process management solutions provide for production workflow - you can define a process template, and process instances will follow the process as defined in the template. There is always ONE point where the process instance is (except for maybe parallel tracks, but also there, there is always ONE point where the process-instance is, in that track).
- What if you have a situation, where the issue at hand (an order, a claim, etc), has a lot of different scenario's, which complicated timing dependencies and what-if's. For instance - a legal procedure, with many sidesteps, possible escalations and subprocedures. Trying to model that in a production workflow is seriously difficult - you end up with an almost unreadable diagram, with many many business rules, and not something elegant, agile and maintainable. Believe me, I've been there...
So.... what do we need? Technology that allows us to create unique process instances, where (in parallel) a user (or a system) can activate certain subprocess templates. A user interface that can help users with this (check out Flower, a dutch product).
And a modelling language that can support this. Ouch. We are talking state transititions, user selectable sub-templates, and still some way to know progress and termination. I would doubt BPMN is up to the task....

As observations:
- When you notice you are dealing with a complex business situation where production workflow modelling feels limited and create overly complex diagrams, you are probably on the wrong track...
- Don't try to squeeze a frog in a pan, don't try to squeeze a complex business situation in a too limited expression language such as BPMN.
- For now: create some kind of state diagram, an sub BPMN models + a lot of explaination :-)

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... ;-)