Convergence of process model silos

Go look in a random, reasonably mature organisation, and it is likely that you will encounter a number of places where people think, discuss, record and analyse process.


Let's see where.....

First of all we see BPA centers, that model processes so the organisation can... be compliant, reach ISO certification, communicate to people (knowledge management). Often the procesmodels and instructions are published on some intranet.

Then we see enterprise architects, modeling processes (often from a higher view).

We see business analists, working in a change project, trying to find the As-is and To-be situation, and documenting them in requirements tool (parts of business or system use cases) or documents

We see BPM engines running, with procesmodels.

That's a lot of process models, with often a lot of overlap.

Duplication of data and of simular tooling is often the case.

Currently, we see that the tools in the various areas are not integrated. It means remodelling processes in the other tool. And we see that the tools are limited. A BPA tool can have great modelling capabilities, but can't link things to (abstract) services. Or the BPM-suite is great to model processes, but we can't publish them to do knowledge management.

The key question - will we end up with convergence?

There are signs.

- Some companies are using BPA (for instance ARIS) to also model requirements, next to as-is and to-be processes

- Some companies are using their extended BPM suite to also publish the processes to some intranet (for instance Pega systems)

- Some BPM companies are buying BPA tooling

- Some BPA vendors are extending their BPA offering with BPM-suite execution cabilities.

I long for an integrated tool (either one tool, or a clear, say XPDL type, integration - but beware round-trip...)... where I....

- Can model an enterprise (functions, processes, services, organisational units)

- Can model requirements (including business rules), and link them to all of these elements, as-is and to-be

- Can define processes in more detail

- Can execute and measure some of these processes

Human BPM/BPI-game and my key lessons

Recently I attended a good training on process modeling and analysis. One of the final parts was a group exercise where we simulated a process. A lot of fun - first we got the specs of a process, e.g. activities, flows, business rules and resources. And each of us was given a role in the process. Based on a computermodel we received "customer orders", and we performed the tasks, delivering the requested product, while the computer was measuring %on-time delivery and leadtime (+ variances + some other KPI's).
Then we had the opportunity to discuss the process, our observations on performance, and as a group suggest and implement improvements. Of course we used various techniques, we just learned in the training, such as elements from value added analysis, bottleneck removal, leveling, and other lean + common sense techniques. Then we performed the process again, with again KPI measurement. And one last round of improvement and simulation.
We did fine in the end - the process was definitely improved. And - both leadtime went down, resourcing went down, cost went down and predictability went up (less lead time variance).

My key lessons:
1. A lot of improvements is FREE
We often have the idea that improvement comes at a cost. Yes - for most improved processes that will probably be true. But the start process we were given was not so unrealistic. Yet, with surprising little improvement changes, we were able to improve on all major performance elements.
Wandering around various organizations, I have often been puzzled by the lack of view on processes and the great, yet unattemped potential for improvement...

2. Change management is hard....
Running the process went fine, but as a group coming to terms with the analysis, improvement ideas and selection/implementation - ough. A lot of discussion, confusing, different angles, lack of leadership.
It learned me the valuable lessons:
-Business Process Improvement (BPI) needs a mix of people from the floor and people with general process improvement skills
- BPI workshops need a strong facilitator
- BPI needs someone that takes decisions - e.g. management that understand the BPI ideas and is able to prioritize and select

In real live I see these things too. So much room for improvement. Coming up with good improvement ideas is often easy. But getting all the people aligned and agreeing- that's the hard part. In terms of evolution, I guess that's our next challenge. We are great survivors. But in the future collaboration will define our real survival. Not sure if we humans are equiped enough for this task...

(Dutch only) Al goede deelname Nederlands BPM onderzoek (nog lopend)

(Dutch only - concerns progress on a dutch research on application of BPM as discipline and BPM technology in dutch organizations)

Eerder heb ik geschreven over het onderzoek "Business Process Management in Nederland - 2008" dat de Hogeschool Utrecht ism Capgemini uitvoert.
Ik moet zeggen - we hebben nog een week te gaan, maar al 100 mensen hebben de enquete ingevuld op www.bpmsurvey.nl .
Het betekent dat we qua onderbouwing van resultaten redelijk stevig staan, ook gezien de spreiding van de deelnemers over de verschillende branches in Nederland. En ik denk dat de resultaten interessant worden en bruikbaar voor organisaties om te kijken waar BPM zich heen ontwikkelt en te zien wat andere organisaties doen met BPM en BPM technologie.

Reacties van de deelnemers waren voornamelijk positief. Eén quote:
"Het BPM survey werkte voor mij heel verhelderend. Aan de hand van de vragen zie ik de gaten op BPM gebied in onze organisatie. Ik ga mij binnen onze afdeling verder bekwamen in alle facetten van BPM om verbeteringen door te voeren en deze uit te dragen binnen de organisatie."

Kijk, daar worden we natuurlijk blij van. Maar er kwam ook kritiek, goede kritiek, die we meenemen voor toekomstig onderzoek naar BPM.

Vanaf deze plaats kan ik alleen maar zeggen: als je nog niet hebt meegedaan, en geinteresseerd bent in de resultaten van het onderzoek - doe dan mee! Je input is waardevol.
www.bpmsurvey.nl. De vragenlijst is nog tot en met 25 april actief.

Voor meer informatie over het onderzoek, zie ook:
http://www.bpmsurvey.nl/BPMuitnodiging.html

Business Process Control in two loops

Earlier I blogged about the role of Business Activity Monitoring. When talking to various vendors I found different views on the use of this. Again - this blogitem's inspiration I got from a presentation from Pallas Athena (www.pallas-athena.com)

Basically there are two efforts going on in a BPM environment that require monitoring, as part of the Plan-Do-Check-Act loop:

1. Operational management (let's call this loop 1)
This is: making sure that current procesflows (real orders, cases, complaints, whatever) deliver within acceptable scoring range.
This is the daily management process to make sure all customer/stakeholder expectations are met. It could include firefighting to make sure that one order gets delivered on time, the certain complaint gets the right attention, that the illness of employee XYZ is not impacting the question a customer had, etc, etc.

2. Process improvement management (let's call this loop 2)
This is the more structural view on the process performance. Now we are not interested in making sure a certain process instance (order, complaint, etc) is executed on time, within budget, but we want to look at the process performance as a whole. And analyse the process - where are bottlenecks, in what type of instances we typically end up with trouble, what are average leadtimes, costs, etc?

I see a number of things in the BPMS market:
1. Some vendors do not see the difference, or limit their view on only one type of management.
2. Most vendors promise that "the BPMS will help you to improve", but most vendors deliver for only one thing: Business Activity Monitoring.

My main point: BAM is not a solution. BAM can be a supporting role (CHECK) to be able to manage both management processes, but we need more in a BPMS. We need to be able to ACT.

A simple analogy:
When I see smoke pooring out of my oven, and the temperature-meter of the oven is well in the red, I have information: my food is burning, my process is out of acceptable KPI ranges.
However, the key question: what can I DO to 1. fix this now, and 2. Fix this from happening again?
My control in this situation is:
Process 1. Switch oven off, take food out, curse, start over (or eat out)
Process 2. Read the recepy, use the oven timer, set the right temperature, and maybe have my girlfriend doublecheck, plus check progress every 5 minutes

BAM is nice, but we need a linked feature called "Business Process Control" in BPMS (and some already have it, but name it differently) - the ability to:
1. Fix current process instance that are off limits (or are in danger to become that)
For instance:
- Reassign staff, temporarely hire new staff
- Prioritize processes / tasks / certain customers
- Say sorry to the customer pro-actively and negotiate new delivery conditions
(Can you think of other control activities?)

2. Fix the process
Usually people think "change process activities" when improving. But my believe is: usually much can be done through:
- Changing assignment business rules (triage, priority based, etc)
- Tune process flow rules
- Increase staff
- Train staff
(Can you think of other control activities?)

BPC - Business Process Control. Now that would be a nice feature in a BPMS.
And maybe even BPCC - Business Process Coaching and Control: a BPMS that alerts you (BAM), suggests (Coaching) possible actions ("why don't you assign this task to Mary?") and allows you to take control measures on loop 1 and loop 2.

But then again, we have enough TLA and FLA's....

New BPMS feature: process mining

Recently I attended a meeting where a BPMS vendor (Pallas Athena, http://www.pallas-athena.com/) presented a new (for me) feature: process mining.
They worked on this concept together with the Eindhoven University (Van der Aalst, a well-known name in BPM research, also see http://www.processmining.org/ and http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/process%20mining.htm)

Basically, the concept is:
- the BPMS reads all kinds of logfiles from various computersystems.
- The BPMS analyses the logfiles and will construct a processmodel automatically
- The data + model can be used for animation and simulation

That's interesting for multiple reasons:
- It usually takes quite some time to construct a procesmodel manually - talks to stakeholders, workshops, etc. Process mining can save time (and cost)
- Even when interviewing stakeholders, they might not have the correct overview and the modelled process might not match reality. Process mining can confront stakeholders and improve model quality.

There is catch of course:
1. The logfiles need to provide data that a BPMS can interpret - aka some type of task identification, a timestamp and a unique ID (of a certain flowing object, such as customer, order, process, etc)
2. Process models that are "mined" will only contain the reality as is presented in the logfiles, and no more. They will miss:
- Business rules for decisions and assignments (why did this instance go left, why was person X the performer of the task)
- Manual activities or activities not traced in logfiles

Still, I saw some cool stuff, that could have added value in BPM efforts:
1. A logfile of a helpdesk application was analysed. Step by step you saw the processmodel appear and get refined, based on the logfile entries

2. A time-based animation could be run, based on the original logfile, showing the flow (little dots) through the process model. This was quite interesting, because it visually showed the execution, quickly pointing to bottlenecks and opportunities for improvement
(Note: if would even be better if the system would be able to present possible improvement actions, based on process improvement frameworks such as Lean and Six Sigma)

3. When the animation was shown to the stakeholders, they did not believe the process - certain flows where against company policy, but did happen. Compliance issues became clear.

4. Based on the logfiles, various KPI's could be calculated. In addition, various statistical facts could be derived, usefull for subsequent simulation

5. If the eventlog also contained userdata, it was possible to analyse and visualize the "social map" - who is involved when, where and is linked to other people.

So, even though the technology is quite new, needs refinement and has limitations, I do see interesting benefits:
- Quickly "mine" a starting point for a processmodel, and then add tasks and business rules
- Visualize currect processes and analyse bottlenecks

For more information - see: http://tabu.tm.tue.nl/wiki/_media/pressrelease/press_release_stw_project_ned2.pdf?id=news&cache=cache

Disclosure: I have no commercial relation with Pallas Athena.

BPM - Thoughts about change

BPM projects are change projects. And I want to address a number of thoughts about change.

1. Likelihood of change

Thinking about change (and mainly based on my sometimes painfull lessons on projects that actually did not lead to sustained change) I came up with a simple formula to make me once and for all remember factors required for change. They prevent me from being overly optimistic (as I sometimes have the tendency to run too far from the troops...)

The formula: Likelyhood of sustainable change =

Need x Awareness x Sense Of Urgency x Ambition x Priority x Vision x Resources x Courage / Risks

Need: is there current pain? Something that the people want to get away from?

Awareness: is there real awareness of the pain, the causes and the need to get away from it?

(sidenote: in learning theory you have the powerful model of:

UU - Unaware Unable - We are not able to do something, but unaware....

AU - Aware Unable

AA - Aware Able

UA - Unaware Able
In this case: are the key stakeholders at AU level?)

Sense of Urgency: do key people, with power, affected by the pain (directly or indirectly) really want to get away from it?

Ambition: is there an ambition to spend time, energy and resources to actually do something?

Priority: is this required change and the effort it requires a priority? Or are there other things more important?

Vision: do we have a vision how the TO BE situation looks like and how to get there (more about this later)
Resources: do we have money, people, some time, etc to get there?

Courage: do the leaders, excuses le mot, have the BALLS to actually stick their heads out and get it going?

Risks: how much risk is involved (the bigger, the less likely change will occur, unless.... Courage and Vision is available...)

My lesson: check this formula in the beginning of your efforts on a specific project/change.

And if the outcome is too low, ask yourself: Am I in control to influence the factors? If yes - make an effort, and check again. If no, or if after a number of interventions no significant likelihood is garantueed: go and pick another change worth fighting for.... And if you are working for a manager or client: tell them the outcome and tell them NO.

2. A word on Vision.

As a consultant I learned there are two ways to implement change:

1. Design approach

In this case, we approach the required change from a "blueprint" perspective. E.g. we try to work out a model of the to be situation as much as possible, then perform a gap analysis, leading us to actions required to get from the As-is to the To-be

Base assumption: the future can be designed in a blueprint. The vision can be expressed in a model of the desired state.

2. Development approach

In this case, we work with the people to develop, step by step, required change, and implement it, learning from our efforts, and then get on with the next step.

Base assumption: the future is what happens here and now, and we work together, without a blueprint, but with common goals. The vision needs to be expressed in "common ground", and we need to trust and enable people to create results, develop insights and learn/adapt.

Is there a prefered way? No. Use them both, when appropriate.

I am, for some reasons, too impatient to go with 2, hate unclarity and risk, so I love blueprint visions. That hinders me a lot.

However, a key lesson on 1: think about the number of factors you want to include in the blueprint. I often (and still do :-)) tend to include too many factors. Why? Because I find blueprinting so #^&#$! interesting. But I forget the key thing: the blueprint is there to create a direction, a vision and movement. People are better directed with a strong but simple blueprint, then one with 30 factors, covering 20 slides or so... The elephant is eaten in small pieces...

A word on following the change path....

In my naive starting years, I always thought change went like this:

Right. Of course, this was not reality. It was more like...

An important thing I learned was: if the path of change seems to wander away from the vision, do not immediately start spending lots of energy to push it back. Mischa, a collegue of mine, drew the diagram above and made it suddenly very clear: Groups of people can wander around, and do not follow straight lines. It can cost a LOT of energy (believe me, I learned :-)) to push back. A better way is to see where things are going (and they might suddenly turn...), and only if a certain boundary is crossed, you push back to get them back between the boundary lines.

But, how much clarity and detail is needed in the blueprint? As said, I tend to included too many factors, because I like it and gives me a feeling of direction and risk-reduction.
Some lessons here:
- The more factors you stick in, the more energy it will take you to make people see, buy in, and reach the change factor. Links back to likelihood of change....
- The more factors you try to stick in the blueprint, the more factors are likely to change. To my sad realization, I have to admit that even my blueprints are far from the reality that was finally delivered. Lessons on the way and changed circuimstances change the required TO BE, all the time...
So, that's why I am more and more a fan of incremental, iterative change, where we mix design and development approaches and create interim TO BE's that get refined on the way, as shown in the diagram...

(Dutch) Onderzoek "BPM in Nederland - 2008" gestart

[This is a dutch message, requesting dutch people to participate in a BPM survey covering BPM in the Netherlands]

Uitnodiging deelname onderzoek “Business Process Management in Nederland - 2008”

Beste lezer,

Graag wil ik je uitnodigen om deel te nemen aan het onderzoek “BPM in Nederland - 2008”, uitgevoerd door de Hogeschool Utrecht in samenwerking met Capgemini.

BPM is een relatief nieuw aandachtsgebied binnen organisaties
Binnen veel organisaties is de aandacht voor processen groeiende. Dit blijkt uit toenemende initiatieven in organisaties rond “Business Process Management”, afgekort als BPM.

Voorbeelden hiervan:

• Een bank analyseert en documenteert de activiteiten bij het afsluiten van hypotheken
• Een gemeentemedewerker is proceseigenaar “verstrekken bouwvergunningen” en coördineert uitvoering van activiteiten door functionele afdelingen in dit proces
• Een energiebedrijf meet structureel doorlooptijd en tevredenheid bij afhandeling van klachten en zorgt dat deze performance indicatoren binnen bepaalde normen blijven
• Klanten van een telefoonbedrijf vragen een telefoonaansluiting aan via het internet, waarna alle vervolgstappen volautomatisch worden uitgevoerd middels BPM technologie

Vanuit BPM streven organisatie naar wendbare, transparante en efficiënte processen.
De reden hiervoor: organisaties realiseren zich dat procesinrichting een belangrijk onderdeel is in concurrentievermogen en strategie.

Er zijn echter nog vele vragen rond BPM
Wat is BPM? Wat gaat BPM voor jouw organisatie betekenen? Wat doen andere organisaties in Nederland rond BPM en BPM technologie? Met welke resultaten?
Dit zijn essentiële vragen.

Onderzoek rond BPM is nodig, gericht op Nederland
Diverse onderzoeksorganisaties doen marktonderzoek naar BPM om deze vragen te beantwoorden. Echter – dit gebeurt primair buiten Nederland (met name de VS).
Onderzoeksresultaten zijn daarom maar beperkt toepasbaar in Nederland.
Om deze reden voert de Hogeschool Utrecht, in samenwerking met Capgemini, een onderzoek uit naar Business Process Management in Nederland.

Je bijdrage wordt gevraagd (20 minuten van uw tijd)
Om dit onderzoek uit te kunnen voeren hebben wij je hulp nodig.
Voor het onderzoek is een vragenlijst opgesteld die via een internetbrowser eenvoudig kan worden ingevuld.
Invullen duurt ongeveer 20 minuten.
Wil je deze vragenlijst invullen, op basis van je inzicht in BPM bij jouw organisatie?
Je levert daarmee een belangrijke bijdrage aan dit onderzoek.

Deelname levert inzicht op (en kans op een prijs)
Wij hopen uiteraard dat je mee wilt doen. Als deelnemer ontvang je in juni het onderzoeksrapport “BPM in Nederland – 2008”.
Het rapport geeft je inzicht in BPM bij Nederlandse organisaties rond de volgende onderwerpen:

• De huidige toepassing van BPM en ambities van organisaties op BPM gebied
• De resultaten, barrières en succesfactoren bij BPM initiatieven
• Het huidige en geplande gebruik van BPM technologie
  

Als blijk van waardering wordt elke 30ste deelnemer beloond met een boekenbon. Daarnaast worden nog enkele MP4 spelers verloot onder de deelnemers.

Heb je 20 minuten en wil je aan de slag?
Vul dan onderzoek in – klik hiervoor op de volgende link: http://www.bpmsurvey.nl/
Indien de link niet werkt, kun je het adres van de website http://www.bpmsurvey.nl/ in je browser invullen.

Alvast hartelijk dank voor je bijdrage!
Belangrijk: je kunt de vragenlijst tot uiterlijk 25 april 2008 invullen.

Heb je geen tijd of heb je onvoldoende zicht op BPM binnen je organisatie?

Indien invullen van de vragenlijst niet mogelijk voor je is, kun je dan een ander persoon binnen je organisatie vragen dit onderzoek in te vullen (middels het doorsturen van het adres van deze website: http://www.bpmsurvey.nl/)? Bij voorbaat dank!

Je gegevens en antwoorden worden zorgvuldig gebruikt
Je contactgegevens en antwoorden worden strikt vertrouwelijk behandeld en worden na analyse verwijderd. Het onderzoeksrapport is anoniem en niet herleidbaar tot een organisatie of persoon.

Hopelijk tot ziens op de BPM survey site - http://www.bpmsurvey.nl/

Met vriendelijke groet,

Onderzoeksteam “BPM in Nederland – 2008”

Tom Kastelein – Hogeschool Utrecht
Roeland Loggen – Capgemini Nederland BV