(Dutch) Onderzoek "BPM in Nederland - 2008" : resultaten beschikbaar

(This is a dutch message about the availability of the Dutch results of a BPM survey we ran earlier this year).

Eerder dit jaar berichtte ik over het onderzoek dat Hogeschool Utrecht en Capgemini hebben gedaan rond BPM in Nederland. De resultaten van dit onderzoek zijn inmiddels beschikbaar - het rapport kan aangevraagd worden op www.bpmsurvey.nl.

Interessant leesmateriaal!

Enkele bevindingen:
- BPM krijgt groeiende aandacht
- Hoewel de meeste deelnemers BPM als een management discipline zien, wordt ook gesteld dat BPM nog teveel als IT wordt gezien
- BPM initiatieven redelijk succesvol
- BPM technologie met name nog gebruikt voor procesbeschrijving en publicatie (BPA)
- Tevredenheid over BPM technologie matig
- BPM trajecten hebben last van functionele organisatie/cultuur
- Organisaties die BPM willen toepassen zijn met name op zoek naar ondersteuning bij training

Meer bevindingen in het eindrapport. Veel leesplezier - www.bpmsurvey.nl

Studying for OCEB fundamentals

I was lucky to become one of the beta-testers for the OMG's OCEB fundamental exam.

More info on: http://www.omg.org/oceb/

A great refresh (well, to be honest - some new stuff!). And the nice thing - some of the new material I could immediately use in my work. For instance the BMM standard is a great framework for strategy and planning concepts. And Martyn Ould's book about BPM is a nice read, I like his tone of voice - I will probably not just read chapter one, but continue.

A fair amount of BPM area's is covered :

- Process concepts

- Process modelling (BPMN)

- Maturity (BPMM)

- Compliance (but a warning: very USA centric)

- Process performance - KPI's, goal setting, etc

- General MBA stuff on business concepts

- Six Sigma (very very basic)

Stuff that I miss (maybe in a more advanced level?):

- Change management

- BPM technology (including BAM, Rules, Document management interfacing)

- How to do BPM projects (from pure processwork to BPM technology)

- Other process improvement methods such as Lean, TOC

- The relation between BPM and Business/IT architecture

- Other "activity coordination" approaches besides orchestration & choreagraphy: case management, human interaction management, collaborative BPM

A tip: Don't underestimate the work - it's quite a lot of material.
A question: any other Dutch participants? Would be nice to become the first Dutch OCEB certified (ah, my ego again ;-))

Friday exam. Will let you know more... (well, as far as the quite strict NDA will allow me….)

Just attended the virtual eBizq seminar

I just attended the eBizq virtual seminar on BPM.
Also see: http://expoq.unisfair.com/index.jsp?id=4616

Fun! And a great way to network, meet people and find information on BPM (although the number of vendor booths is not a bit low).

The presentations and webcasts will be available soon, which is nice, because I missed the first two parts (tip for Ebizq: publish not only the starttime US based, but also the time for people in other time zones ;-)).

He, and my question on collaborative BPM was even answered in the final panel. Nice, although the first speakers sticked too much to the casemanagement, 1 person handling tasks view of BPM technology. I am still looking for collaborative BPM (or HIMS) which can support process-fragments supporting people working concurrenly together on a certain process task (be it deciding, researching, issue-resolution, planning, whatever). See - most processes are partly structured (and can be supported by WFM), partly casemanagement, and some parts are just a total adhoc bunch of people running around, meeting and deciding.... collective intelligence at it's best, but hopefully supported by great BPM features in the future.

The virtual environment was a bit limited (chat rooms that echo-ed of emptyness, and booth chats with vendors, where people did not answer...hmmm).
But it saved me a lot of flying :-)

JIT training in a BPM technology environment

I cam across an interesting research paper on BPM and knowledge management:
http://www.ejel.org/Volume-5/v5-i3/Leyking_et_al.pdf

Key points:
- Most training efforts are not linked to the situational context - so the learning is too remote from reality, in terms of content and timing
- A process focus can increase the value of training - process context can support modeling of required knowledge areas to complete an activity in the process

In my view there is a strong link between BPM and knowledge management. Many processmodelling efforts, as a start, where created from a knowledge perspective - helping new (and existing) employees in the business to understand the processes and activities to be done, so that they could perform their work accordingly.
And of course, when executing processes, the right employees with the right skills and knowledge are needed for performing certain tasks.
Some BPM technology vendors are already taking some steps to support knowledge management in the context of process. Simple example: a user can click on "show the process map" when working on an activity, and the processmap + highlighted activity is shown, helping the user to understand the context of the activity.

The paper triggered me to think a bit further -

Wouldn't it be great to have a BPM technology solution that enabled us to trigger "just in time" learning?

The scenario:
An employee gets a task assigned. The BPM suite identifies that the person has never performed this task before (of possibly other triggers: the employee scores low on certain other KPI's around this activity such as errors made, throughput time, etc).
The BPM suite suggest to the user, prior to activity start: "Do you want to follow a quick Just In Time training on how to succesfully complete this activity"?
And from that point on, a link is provided to some training environment, which trains the user, through video, text, quizes etc to understand the link to strategy, process context, activity and best practices for the activity.

Benefit: Just in Time, so very closely linked to the context of the actual work to be done.

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

There must be 50 ways... to view your process

While working with quite of lot of different people in the area of business process management, I am starting to see the value of different viewpoints on various concepts.
One of these concepts is "process". And I want to share with you some of the views I have encountered. All of them have helped me to understand the concept of "process" in different ways, and (from time to time) have prevented me from blindness to certain factors.

Let's list them (and as always - I am very curious on other views you might have!)...
So... hop on the bus, gus!

1. As a transformation from input to output

2. As a operationalization of strategy ("great slides - but let's get to work")

3. As a series of events, activities and decisions (based on business rules)

4. As a social/antropological context for people working/playing together

5. As a means to delight a customer (or scare him/her away)

6. As some "trainable thing" that you can improve forever (faster, quicker, cheaper, better)

7. As something that can be ill, like a patient, and should be diagnosed and cured

8. As something for which you can define targets, then measure it, and steer it

9. As a means for intervention in human and systems activity

10. As a psychology domain, full of emotions, unconscious behaviours and interactions

11. As something (we think) we can model in a process diagram using graphical symbols such as BPMN.

12. As something that is way too complex and too adhoc to model usefully...

13. As something that allows various stakeholders to understand your business

14. As something that gives people context, clarity and safety

15. As something people sometimes cling to "this is the way we have always done it"

16. As something which has historically grown, but nobody can tell me why it is

17. As something you should automate as fast as possible, so you can fire all the people and save a lot of money

18. As something in which SOA/services can be orchestrated

19. Something you can label as best practice and copy to other organisations

20. As something that will always grow into complexity (following the rules of entropy)

21. As a series of resonsible people doing little things, that all added up define your competive edge

22. As something that is compliant to certain laws or certificationrules, or not...

23. As something that you can outsource (or view as your "core competency")

24. As something that can expose you to risk

Well, that's 24. Know more??

(Dutch only) Hulp gevraagd! BPM onderzoek gaande.

Hallo lezers,

Ik heb een verzoek.
Ik ben betrokken bij een onderzoek vanuit de Hogeschool Utrecht rond business process management (BPM) (ik begeleid hierbij een stagiare, sponsor is Capgemini, mijn werkgever).

Doel van het onderzoek is inzicht te krijgen in...
- De huidige activiteiten en plannen van bedrijven rond BPM
- De "maturity" van de BPM activiteiten
- De huidige en geplande inzet van BPM technologie
- Succes en faalfactoren rond BPM en BPM technologie

Mijn vraag aan jullie - ik ben op zoek naar mensen (uit bepaalde doelgroepen) die onze online enquete willen gaan invullen. Duurt ongeveer 20 minuten en er zijn "perks" - kans op wat prijzen (IpodTouch, boeken rond BPM).
En uiteraard een uniek inzicht in de ontwikkelingen rond BPM in Nederland (BPM onderzoeken zijn nog niet eerder op deze schaal in NL gedaan!).

We zoeken met name bedrijven (andere ook welkom):
- > 500 medewerkers
- In Nederland gevestigd
- In branches Financieen, Overheid, Telecom, Utilities ofbeursgenoteerd

En in die bedrijven zoeken we met name:
- CIO's of Informatie managers
- BPM afdelingshoofden
- Afdelingshoofden Processen & Organisatie
- Business en IT consultants bezig met BPM en/of BPM technologie

Als je zelf iemand bent, of mensen kent die aan deze criteria voldoen en je wilt ons helpen, dan verzoek ik je:
- Ofwel mij (roeland punt loggen apestaartje capgemini punt com) de contactgegevens van jezelf of deze mensen te sturen:
- Naam
- Organisatie
- Functie
- Emailadres

- Ofwel deze email door te sturen naar mensen die mogelijk geinteresseerd zijn in dit onderzoek en de uitkomsten ervan, en ze te vragen aan mij hun contactgegevens door te sturen (en laat ze jouw naam noemen).

Mijn dank zou groot zijn - mensen die ons hierbij helpen zal ik ook op de prijstrekking-lijst zetten.

NB: Deze contactgegevens zullen ALLEEN gebruikt worden voor het verzenden van het enqueteverzoek en zullen na verzending van enqueteresultaten worden verwijderd.

Alvast bedankt,
Met vriendelijke groet,
Roeland Loggen

Process footprint - a new, green, element in BPM

Interesting - the link between BPM and the Green movement is there.

I stumbled on...
http://greenbpm.com/
and
http://www.global360.com/collateral/blog_articles/greenbpm.pdf

When definining and analysing processes I typically look at:
- Effectiveness/alignment with strategy
- Performance/Efficiency (cost, lead time, etc)
- Profitability
- Agility
- Compliance
- Customer satisfaction
- Employer satisfaction

I will add a new one: the environmental footprint of a process. As a logic extension of the efficiency - can we optimize the process in such a way, that we minimize the impact of environment..

For the dutch readers:
It made me realize that the COPAFIJTH abbrevation (see older post) for making sure all aspects of a change are thought through, needs an extension. Let's start talking about COMPAFIJTH! (Milieu as integral part of any change effort).

From current BPM patterns to the future patterns of BPM technology....

I read a number of recent postings on the various "BPM technology patterns":
http://www.bpm.com/FeatureRO.asp?FeatureId=242 (bij Peter Fingar) and http://www.global360.com/blog/index.php/2008/03/04/prevalent-process-patterns-enable-bpm-benefits-differently/ (by Jim Sinur).

(updated: Sandy - www.column2.com - pointed to the correct article on BPM.com that I actually intented to link to. Thanks!)

Interesting typology of various BPM technology patterns - but, in my view incomplete and (a bit) outdated. STP, Workflow and Casemanagement is stuff that we understand now.
My interest is:
- What other (future) types of BPM technology patterns can we see ?
- How are the various patterns positioned?

To answer the second question, I tried to create a model, based on two dimensions.
See the following diagram:

It tries to map out BPM patterns on:
1. The process - how structured is it?
With "structured" I mean processes that we can map out, in terms of predictable events, activities and business rules. Based on incoming data (from events and activities) during the execution of the proces, certain activities are performed and decision rules determine the flow. Example: quoting a new car insurance.
With semi-structured I mean processes that are more tricky to model - some of the business rules can not be formalized and stay in the head of people as knowledge. And some of the events might not be predictable.
Example: trying to decide on a complex insurance claim
Unstructured are processes (if we can still speak of process) in which in advance very little can be said on flow, events, activities and business rules.
Example: the way I clean my house ;-)

2. Who is performing the process?
In some cases processes can be fully performed by a computer, based on predefined rules and transactions.
Other processes need human activity, based on certain knowledge and the realisation that life is more fuzzy than a computer can handle (at this stage). We can see processes in which there is most of the time one person in the lead, performing work without a lot of communication during the execution of the activity. There could be more people involved but either they are working serially or they are working on separate process parts without direct contact.
And most complex are processes where people are collaborating together at the same time, working together on performing activities, making decisions, etc.

Now, if we use these two dimensions, one can map out a number of BPM patterns...

First the well-understood patterns ...
STP - Straight Through Processing - in which a computer fully handles the execution of a process. No people involved, hands-off. Great business case for high volume, low revenue transactions.

E-Forms - this is my entry level workflow. People fill in eForms, which are send around for approval, with not much (complex) integration or complex business rules. Think - reserving parkingspaces or rooms.

Workflow - this is the typical inbox, task, form, more complex business rules and back-end integration, with some process monitoring on top. Great business case for process control, compliance, worker-support and efficiency.

Case management - a lot of discussion on the defition on this one. My view: automated process support where one can perform tasks in any order, skip tasks, add tasks. Usually quite data & document centric. Great for loosely structured processes, where we want to keep control, and support the knowledge worker with a one-stop place for all work to be done, data, documents and activity-history.

Groupware - all solutions that enable sharing information (Wiki's, email, discussion boards). Very handy, but unfortunately it creates a lot of "setup time" every time you dive into one of these components, because the process context often is missing or is not easy to establish (what't this about? what't the status? what's expected of me, now?)

Automated BPM patterns of the future

I see CEP (Complex Event Processing) as a new area, that might grow into a BPM pattern that can support complex interrelated processes. Think inter-process coordination (don't process a new policy, if we just got word that the client is in financial trouble) and more complex rule based event driven stuff (analyse this cloud of data, and determine appropriate pre-defined actions, that need to be started)

Agents and AI will provide possibilities to go even further. I am thinking of self-learning systems, that can formulate a process, based on clouds of data/events, perform it, and if needed adjust it....

Then - Collaborative BPM patterns of the future

What happens if you have a process which requires many people to work together to perform a process? Currenly we know the answer - manually planning of meetings, meeting minutes/recording of decisions, and email - lot's of email.
Typical "knowledge worker" processes are currently not well supported by BPM technology. We are far from the "high performance workplace".
Some patterns I see:

Collaborative BPM
Process engines that support working together around a structured process: automatically planning a meeting, calling a client, opening and recording a chat/IM session. All still activity focused - making sure the process can finish.
(Note: Collaborative BPM is also used as a "design time" concept, in "together defining a procesmodel")

HIMS
Wilder stuff. Process engines and collaboration platforms that can handle less structured processes in the form of "processes on the fly" with "stories" that the group can create, evolve and finish. Where messaging is structured (assignments, decisions, data). See the thoughts around "Human Interaction Management".

CEBP
A platform that would enable users to manage all communication around a process as well. Unified, connected to the process as context. Could probably support both CBPM and HIMS.
I see a platform in which I...
- Can manage my presence (for these types of processes, please contact me via phone of IRL unless it's weekend, than only contact me if status is RED, via SMS)
- Can route voicemails, calls, emails, documents, linked to a certain process context and activity context

It this still vague? You bet. I don't know where it's going - but I can see that the current IT support for working together is not sufficient. That troubling me. .. the growth in information overload, the growth in "setup time" to get (re)started, and the economic reality that productivity improvement in knowledgeworkers intensive processes has not significantly grown, while this area of work (services) is outgrowing manufacturing by the day...
To compete in the next 20 years, something will need to be done...

Let's check in 5 years!

Key skills on a BPM technology project

The last year, while doing BPM technology projects, I learned a number of lessons on skillsets that you will need on a BPM project. Some lessons the hard way (e.g. missing them, and needing to fight for them :-)).

Let's take a "typical" BPM technology project where...
- A company wants to improve certain processes (think efficiency, visibility and agility)
- A project has been started that tries to tackle this from two sides:
1. BPM as a set of process interventions (proces analysis, design, and implementation of a new operating model around processes - ranging from process ownership, measurements/KPI's to improving the process awareness end to end, and breaking functional silos)
2. Introducing BPM technology (I prefer to call this BPMS or BPM technology, instead of just BPM, to avoid confusion - some people unfortunately still think you can do BPM with only this 2nd item...). Think BPM Suite, maybe a Portal, maybe some ECM/Document management, some or much back end integration, realizing a mix of use cases around human centric workflow, straight through processing and business/process intelligence.

I found the following skills extremely needed:
1. Projectmanagement
2. Changemanagement
3. Process analist and processdesigner, with Lean/Six Sigma skills
4. Requirements/Functional analist
5. Business intelligence specialist
6. Interaction design/usability specialist
7. Solution architect
8. BPM technology/development infrastructure specialist
9. Software engineers
10. Testing specialists

Some remarks per skillset:

1. Projectmanagement
Managing scope, expectations, budget, timeline and issues. The usual. Someone that knows how to let things get done!

2. Changemanagement
BPM in the end is about people working in new ways. You will need skills on your team to be able to involve people, get ideas, stimulate thinking and collaboration, identify risks, etc.
I am not a proponent of the typical "changemanagement" concepts as "communicate" "train" "push down their throats".... What I mean is people that can build a process culture, where people are valued and are actively involved in making their daily joblife meaningfull, fun and effective. I am thinking of the Toyota culture here..

3. Process analist/designer
Analysing processes is a skill. A skill that in the end more and more people in your business should possses, but in the beginning you will need to have a specialist here - don't try this on your own. I am thinking of someone with Lean Six Sigma skills, that can work with key stakeholders in analysing and designing processes. Preferably someone that can teach the people involved how to keep this going themselves for process refinements

4. Requirements analist/Functional designer
Again, being able to look at a new process and translate it to a meaningfull set of software requirements is a skill. You will need someone that understands possibilities of modern technology such as BPM, Portals, Web 2.0, etc. If possible, find someone that is also able to translate requirements into solutions. Of course this person also finds and details business rules.

5. Business/process intelligence specialist
How do you measure a process? What does need to be measured? How will you present the information to people? How will this enable them to steer and control processes? Key questions that a BI/Process intelligence specialist should be able to answer, leading to data/reporting requirements

6. Interaction design/Usability specialist
Unfortunately, with the whole BPM thinking, some people believe that applying BPM is simply defining a process, defining forms that end up in people's inbox, and voila, BPM is running.
It reminds me of the horrible user interfaces we ended up with, when working with IT people doing prototype sessions and building client-server apps. No!
Realize - the user interface of your BPM solution will give people feelings (about your company and your brand) and has a immense influence on their ability to work and trust the solution. I have seen interaction designers that have created wonderfull easy effective user interfaces, thet people loved!
The funny thing is also: during your BPM project you will need to keep selling your projectgoals and future system. Do you think CEO's and users get impressed with your service bus based, SOA super duper EDA CEP Agile BPM solution? I think not. But you can reach out to them with a good user interface - crystal clear...

7. Solution architect
The person that is able to understand the processes, requirements and functional design, have an overview of the backend systems and all technology layers and stacks, and come up with a firm architecture. A person that can guide the engineers and make sure quality is delivered.

8. BPM & development technology specialist
This new BPM technology is new stuff. Many settings, many known bugs. You will run into problems. Don't let your solution architect or engineers get bogged down with this stuff - get someone in with close ties to the vendor. Let this person (or another) also create the best development environment - source control/config management, automatic builds & automatic testscripts execution, deployments, server maintenance, etc.

9, Software Engineers
This is the gold in your team - the people that actually create working software (and that's in the end what is all boils down to, right?). Depending on the scope you might see various skillsets centralized or distributed in your team: people that can magically connect to backend systems and understand transactions, services, etc. People that can build user interfaces. And people that understand how to translation process data to meaningfull BI solutions.

10. Testing specialist
If you use TDD, then you might be able to combine this with 9. But in general, you will often need testingspecialists on your team. And realize - this is not trivial testing. You will need testers that are able to test end-to-end processes from a process, functional and non-functional perspective.

Hope this helps! If you are about to start a BPM technology project, use this as a checklist. And realize - if you ommit some of these skills, the issues and activities will not go away, but simply haunt you during the project....

The trap of IT focused change

Sometimes we forget what the essence is of business change.

Picture an example situation: a business understands that they want to improve their customer relation processes. Several painpoints were found - complaints were lost, addresses of customers incorrect, wrong shipments, whatever. The company understands something must be done, and since data plays a big role, a project is started with a large IT component (and sometimes even a "communication plan" is included).
During the project a lot of effort is spent on the IT part. But, during the project the projectmanager of the IT part starts encountering various issues that he of she can not solve, and does not see as part of the scope. It's the " fluffy" stuff around business change - responsibilities in the to-be organisation, training, the full process, process management of the new CRM department, hiring people, etc etc. The issues get signaled (if we are lucky) to the steering group, but most of them are not picked up and acted upon. In the end the IT project delivers, stuff is installed, and hell appears: confusion, frustrated users, boycots, desperate management, and the easy one to blame: the PM.....

Hm....

In the Netherlands we have a nice Dutch abbreviation that businesses are more and more using:
It's called COPAFITHJ. In essence it's a list of factors that you need to cover as a project/program, when dealing with change. It tries to make us clear that when changing a business IT is only one factor, and that time/effort/money/people will need to be directed to the other factors as well, to make a change succesful.

COPFITHJ stands for:
- Commercial: will our change effect our commercial position (products/services/markets, customer relations)?
- Organisation: will our change effect the structure in which people work, in terms of home base, power, communitity, management?
- People: will the change impact people, in terms of their role, communication, relations, work, responsibilities, required level of expertise/required training & coaching
- Administration, will the change impact required handling and storage of information, including reporting, etc
- Finance, will the change impact current and future budgets, allocation of budgets etc?
- Information, will the change impact the information we require and produce, to perform our work, answer questions and allow the management to steer our work?
- Technology, will the change impact the technology we have in our business? Software, hardware/infrastructure
- "Huisvesting" - Worklocation, will the change effect the psysical location we work at?
- "Juridisch" - "Legal", will the change impact our legal situation.

Is it a great abbreviation? I don't know. But I am glad I can use it to make people aware that change is something bigger than just IT. Too often I still see projects where on the basis of some vague improvement needed by management, some SME's and IT people start running the IT game (requirements, design, build, test), and sometime along the project the "Fluff" start hitting in, gets lost or given too little attention, and we end up with a mess...

The key lesson: approach your business challanges in a holistic way, and do this right from the start until the end. Do not think that IT change will magically result in change in the other dimensions. Focus on the complete business context.

As a sidenote: I am glad that BPM is getting more and more attention. It means that at least the P in the above abbrevation is getting more attention!

My rule of projectmanagement: smaller and deeper

December is for me a time to look back on the year and see what I've encountered and learned.

One observation keeps coming back every year, based on the IT projects I have done so far:

I call it the "It always gets smaller, but deeper" rule on projectmanagement.

This is the essence:



In a typical start of a project, your planned scope will look something like this:

But, after working hard and delivering results, slowly the team starts to realize that finally the scope will turn out like this:

The patterns in play:
- At the start we are optimistic, want to please the customer, maximize the business case value, but are unaware of the complexity of some of the requested features/requirements

- Optimistic planning does not cover all kinds of time-loss on inefficiencies and unplanned ubut needed activities

- During the course of the project, more and more insight develops (the "ouch, does this feature mean this/require this...." moments).

- Time pressure starts growing.... discussions on scope grow. The projectmanager will, depending on sr. level try to hide this or create an early and open discussion with the client

- Negotiations are done. Functionality is prioritized (again) - often succesful, because the client was not aware of the complexity either!

- And stuff is delivered (or another smaller but deeper iteration is started ;-))

Be aware....

Sanity in project processes - back to reality pleassseee

Sorry, cynical mode today....

Ah, I succeeded again... Finding myself suddenly being pulled into a, well, project from Hell.
We all know them. The ingredients are simple:
Mix:
- Not enough time
- No formal proces for requirements, design and build
- No test tools
- No issue tracking procedure and supporting tool
- A strict deathline
- No recording of decisions and knowledge
- Changes in project staffing

And within no time, everybody is running around, trying franticly to discuss, rediscuss, implement, change, discuss, test, discuss, report delays, etc. Working software? I think not.

Key ingredient is, I think, a recurring thing. Let's do a short parabel:

Company A wants a new building as headquarters. They approach a architect and a builder and tells them: well, we want a building, we don't know what we want yet, but why don't you start architecting and building already in parallel, we will test in parallel, so we can move on magicaly date XX-YY-ZZZZ, which we have promised to everyone in the world (and our heads will roll!) without knowing the scope of our demands or any knowledge of timelines for buildings anyway. Make sure it's on time, on budget, and to the right quality!
And what would the architect and builder tell them? Simply: "interesting, but no thanks. Good luck trying to find someone crazy enough to go nuts together with you. And when (or if) you come to your senses, don't hesitate to contact us, so we can tell you how you architect and build buildings for real, with lasting succes and sanity"...

But what do IT companies do? They say - sure. (because O my, it might go to the competitor).

It reminds me of a funny story (happened really!) I heard when working in Sweden.
The king wanted to build this great warship. So, he invited a shipbuilder (dutch, like me :-)), who promised to deliver a 3 deckship. After some years the king visited the king in Danmark, and oh my, saw that his ship had one deck in addition. King back to shipbuilder: I want an extra deck! Shopbuilder, knowing his stuff, tries to scope down, but the king insists, it's the extra deck or the shipbuilder's neck... Easy choice. The ship is delivered, and within about 15minutes of her maidenvoyage it sinks.

My lessons:
Projects should have:
- Realism in scope, cost and time
- Clear processes

Back to work, cleaning up :-)

BPM technology - what happened to two-phase commit?

Between Mid-80's and beginning 90's, when distributed databases and client/server applications began to become mainstream a great technology was introduced: two-phase commit. It basically meant that when a client (or middle tier) wanted to perform a data transaction (create, update, delete) over 2 or more separate databases, it was able to do this in a safe way: either the transation succeeded in all the involved back-end databases, or the complete transaction was rolled back. Various databases started to support this, using the (if I recall correctly) XA standard.

Now I find myself wondering what happened to that great transaction model.
In the current world that we call SOA and BPM technology, suddenly we talk about calling services, hoping everything goes well. And if not, well, there is Compensation. Which, by the way, might fail too. Ouch!

It's amazing - I've seen client/server development tools mature, until they provided a quite stable development and run-time environment, including transactions, debugging, etc.
Then, boom, came the webmodel, and we started all over, with buggy development, debugging ("println("I am at point X and variable Y has value:", y).
And now we have the BPM technology development and run-time environment, and I find myself once again missing all these things that used to be normal....

Anyone knows if there are BPM technology suites that support a two-phase commit like transaction model? Has any of those WS-* standards reinvented this yet? I hope so.
At least than we can think up a new technology to start all over again :-) Mobile?