Process transformation - perspectives on "Business Process Management"

There must be 50 ways to....

2011-06-14T23:03:00.002+02:00

There must be 50 ways to support the transparency, management and improvement of processes…..

I have tweeted it before: getting tired of the many people I meet that still associate process management first and most of all with documenting processes. Almost like a reflex "Ah, we will work with processes, so… we need to model and document this/all processes".
Sure it can help, but first of all it's not the only action a business can take. And second it may definitely not be the right action – other actions might add much more value.
Therefore, here are fifty (ok, some more) other possible interventions that can support the transparency, management and improvement of processes. Did I miss something? Let me know!

(Note, I concentrate on interventions focused on a specific process, and have left out the many interventions one can do to support implementation of process management and BPM within a company on a larger scale…)

The key activity
1. Understand all possible interventions, understand the context, and select, based on best practices, budget and requirements, a good set of interventions for the process, in close cooperation with key stakeholders and in line with your process management strategy (do you have one?)

High level understanding
2. Identify the process (and more important: the service/product that it delivers) and place it in a Product Catalogue
3. Identify the process (name it) and place it in a process architecture/decomposition
4. Identify all stakeholders in the process and understand their goals and high level role in the process
5. Identify all external stakeholders to a process (suppliers, partners, customers) and identify the primary interactions with the process (flows of information, physical goods)
6. Establish SIPOC – Supplier, Input, Process, Output, Customer, but only one a very high level
7. Understand how this process is related to other processes (input/output/supporting/managing) and the fit
8. Classify the process using certain classification criteria: high/low volume, routine – ad hoc, high/low cost, high/low strategic relevance
9. Understand how this process relates to your core competencies. Discuss and decide on sourcing strategies
10. Define the products and services that are output and that are input to the process, and establish quality criteria
11. Understand what IT-systems are supporting the process, with what functionality
12. Understand the relation between the process and core business objects (data) : Create, Read, Update, Delete.

Measurement & Governance
13. Establish goals, associated key performance indicators & targets for a process and start measuring
14. Define a Service Level Agreement with the key customers (internal/external)
15. Discuss and understand the control model: what can we do if all KPI's are in red?
16. Plan the process execution. Create a simple plan, that estimates demand, defines required capabilities and needed resources (per month, quarter, …)
17. Assign someone / people to be accountable for certain aspects of a process (execution, quality, performance measurement, improvement, improving maturity). Make sure there are clear lines of responsible for process vs. line management
18. Implement reporting lines and procedures for these accountable people
19. Set up a "quality circle" of process experts, that discuss and propose improvements
20. Establish a evaluation cycle that follows a Plan-Do-Check-Act cycle for the process
21. Implement a cross-function process governance board (strategic and tactical level) in which functional departments govern process performance and improvement activities
22. Implement procedures and supporting roles/resources for participant support (helpdesk), process incidents, problems and change requests/change management
23. Implement a regular customer satisfaction measurement/evaluation – outside in
24. Make sure all your process KPI measurements are stored safely, so that in time, you can do trend analysis and inline simulation
25. Audit compliance and report on findings

Analysis & Improvement
26. Determine the voice of the business: how this process needs to operate to execute the strategy
27. Adopt a best practice process framework (such as APQC, SCOR, eTOM, …) and assess the process
28. Understand all applicable regulations and policies and understand compliance requirements
29. Perform an outside in analysis of the customer: who is the customer and what is important for them (voice of the customer)
30. Determine the "voice of the employee": what do the process participants find important in terms of roles, development, employee happiness and fulfillment?
31. Assess the performance of the process (specific measurements, such as cycle time, throughput, cost, quality, compliance)
32. Perform a value added/waste analysis, and remove waste & non-value added activities
33. Perform a bottleneck analysis (ToC)
34. Understand process breakdowns, using a Rootcause analysis
35. Assess the capability of the process, based on the current resources: what are the limits & regular operating levels?
36. Identify the risks in the process and come up with/implement controls
37. Identity quality aspects and implement first time right / error proof interventions and checks where required + audits to proof adherence
38. Measure a certain aspect and it’s variance, and attempt to understand natural and special causes for the variation
39. Define a process improvement plan, including key indicators, and make someone / people responsible for executing it in a certain time frame

Maturity
40. Assess the maturity of a process and define the required maturity
41. Define a maturity improvement plan (based on a maturity model), including key indicators, and make someone / people responsible for executing it in a certain time frame
42. Implement PDCA cycle, roles and responsibilities focused on Maturity

Culture, awareness and HR
43. Train the process participants and managers in the process. Create a RACI matrix.
44. Understand the roles and come up with clear functions, with clear business rules around mandate and separation of duties
45. Understand the roles in a process (and the activities they execute and/or manage) and define required competencies
46. Organize awareness sessions to make people understand their role in a process and the impact of their behavior on customer, other people and process performance
47. Train relevant stakeholders in process thinking
48. Organize a BPM-game, where participants learn about the concepts of process, process improvement and process management through an engaging game
49. Organize a BPM day for various departments involved in a process, and use it to build (social) cohesion and alignment
50. Build awareness and capability at the management level in process thinking, process improvement and process stewardship
51. Implement incentives for process improvements (as opposed to rewarding repeated fire fighting behavior)

Technology
52. Go and buy a BPM Suite and automate the process and the BAM
53. Go and buy a BRM suite and support business rules and knowledge support

And finally: document your process(es) (are you really sure??)
54. Understand the stakeholders, goals, life expectation and required detail for documentation
55. Create a process model with supporting documentation, containing a detailed analysis of activities, events, business rules, roles, data flow, physical flow
56. Publish the process model & documentation to relevant stakeholders
57. Place the process model & documentation under configuration management and implement processes to signal updates/deviations and keeping documentation updated

BPM Research - 2011 live! Correlation BPM and Performance.

2011-06-07T20:02:00.005+02:00

General

We recently concluded a research into BPM, together with the University Utrecht.

Key facts: Focus on The Netherlands, web based Survey, 168 participants, statistically healthy, and from all major companies and organizations in The Netherlands (Private and Public sector).

One of the interesting findings

We asked various questions on the adoption of BPM practices (such as identifying processes, documenting them, assigning ownership, implementing plan-do-check-act, etc.). In addition we asked them about the satisfaction on process performance (cycle time, cost, quality, etc).

We calculated averages and found the following (in diagram):

We found a positive correlation (and yes, we did check all the statistics).

I would say: a first statistical finding that shows that BPM actually can help.

Interestingly, when you look at the point-cloud, you see a small top-performing group (high process performance) with average high BPM maturity. And a group with low performance satisfaction, that varies in BPM maturity.

We performed research to find out if there were significant BPM maturity factors in the top-performers, in comparison to the lowest performers. We found significant factors - the key one being "management has an active role in the improvement of processes".

Interested in more findings? Such as the 7 key trends in BPM adoption? The 10 critical barriers? The most used BPM technology in The Netherlands? The Dutch survey results can be found on http://bit.ly/jttlwv.

An english summary is available (mail Roeland dot Loggen at Capgemini dot com or twitter me - Roeland).

Sense-Research-Respond patterns

2011-05-19T20:27:00.004+02:00

In recent discussions and a number of projects we have done, we see an emerging pattern: Sense-Research-Respond.

Typical situation: the need to respond to an ever increasing number of alerts/signals/data, but to do this as cost effective as possible.

A number of business situations:

- An organisation knows it can and should detect signals of fraud by clients and internal workers and respond to it, but is trying to find an efficient way

- Inspection agencies that need to cut cost, and are moving to more risk-based inspections instead of trying to do 100%. But: how to pick the right risk-situations and tune the selection process, based on insights?

- Organizations that see the enormous growth in social media, and are finding references to their products and organization (positive and negative) and want an innovative but economic way to deal with these developments

In the last years we have seen the following pattern for these type of business situations:

The key ingredients:

- The capability to sense: to filter and detect data/events (and when needed correlated ones), that need attention. Usually driven by business rules ("risk profiles"), and easily tuned. The typical technology: Complex Event Processing, based on technology from for instance Tibco, IBM.

- The capability to research: advanced tooling, such as Palantir, SAS, to further research a certain situation, link it to other earlier events and to support decision making: will we need to react to this,and give it priority over other signals (as resources and time is constrained)

- The capability to effectively handle the situation, efficiently coordinating people in own and possibly other organizations. Sometimes this can follow pre-defined structured processes, but often, as situations can differ greatly, might require more flexible case management solutions. Technology such as Pega, Cordys, BeInformed, IBM.

And we have learned that technology is mature enough to handle these situations.

We have even developed a number of offerings around it, such as our "Grapevine" offering for social media. See here for a short video. Another is our Alert offering for Fraud detection.

Fascinating times. My lesson: don't ignore the growing available data-volumes (and become obsolete). Don't drown (and go under). But conquer in a smart way to use effectively. The ability to respond is a critical capability in modern organizations.

The Future Process-App: think Navigator

2011-05-18T12:58:00.005+02:00

Do you remember the time that we did not have navigators installed in our cars?

Two typical situations I remember:

1. Driving with my wife, on vacation, where she was frantically trying to understand the map, while I was stressed out, since our next exit might be the one, and the next one was 30 km ahead.

2. Coming well prepared with a Google Map's driving instruction, only to find out that at step 23 there was a roadblock, making the rest of the procedure unusable. (And the frustration that we saw beautiful other route possibilities, but were afraid to divert from our Google route).

Both situations show a remarkable similarity to the current support of IT-solutions for knowledge workers:

1. No process support at all, just data. IT solutions that are great at storing and providing information (system of record), but not helping to plan and coordinate activities. For the knowledge worker, this means that he or she needs to plan and coordinate actions with other means, such as e-mail, spreadsheets, notes, etc. And for managers it make it quite difficult to get an oversight of the work in progress (who does what, what is still ahead?)

2. Solutions that provide support for activities (systems of engagement), but only using a very rigid procedural template, that locks the knowledge worker in : current workflow solutions. For the knowledge worker, this often means: tweaking the workflow (filling in false data to get access to the right functionality later in the process) or turning to shadow systems for activity management, just to be able to serve the customer request correctly. Both choices lead to incorrect or incomplete management information for the manager.

Based on the projects we are doing for various customers, a new paradigm is dawning:

The navigator as metaphor for the modern process-driven knowledge worker IT-solutions!

Key features:

- It provides real-time situational awareness (where are you? Where do you want to go? What are possible routes? Where are the traffic jams, possible roadblocks? What traffic (business) rules limit your choices?

- It provides goal-driven suggestions, but the knowledge worker can still decide to change route, and the system will re-establish other suggestions. It gives the right balance between standardization and freedom, driven by business policies

- It's easy to use

That's exactly what our Advanced Case Management solutions are providing: a navigator for goal-driven case handling.

BPM and ERP - caution

2011-04-27T15:53:00.002+02:00

I see a number of blogitems on BPM and ERP appear.

A quick mindshare, based on some painful experiences (and a bit of bluntness, I admit)

So you have this big ERP system (or maybe even multiple). And you experience repeatedly how difficult it is to move from a datacentric to a agile process centric application view.... Adapting processes is a pain? UI is outdated? Connecting to eCommerce frontend a nightmare?

Then a BPMS supplier comes in, and sells you this great new layer of technology.

Beware....

Some simple questions:

- You invested heavily in the ERP system and now it is full of user screens.

Are you really going to rebuild (duplicating) all of them in a BPMS?

- Your ERP system is full of business rules

Are you really duplicating many business rules in your BPMS/BRMS?

- Your ERP system has workflow capabilities (that might even be growing in maturity)

Will you really move all workflow capability to the BPMS?

You might end up with an even bigger monster....

And another lesson: if you will deliver the project, and need to work together with the ERP vendor or other service partner, responsible (making money) of the ERP system - beware of politics...

Article published: 4+2 processmodel

2011-04-23T22:15:00.003+02:00

Just published a (dutch) article in BPM Magazine of April 2011:

The 4+2 Process model, a framework for better understanding of process area's you will need to cover in analysis and design.

Artikel 4+2 procesmodel v1.0

View more documents from rloggen

BPM: Regressing and forgetting 60 years of management thinking

2011-03-07T08:34:00.003+01:00

Around 2005 I first got involved in a project with some new innovative technology: Business Process Management (as we called it back then).

As business analyst, I was part of a team that also consisted of a number of developers.
And till today, I remember the look in their eyes when they started to understand the possibilities and implications of this technology. And the same look I saw in the business manager's eyes. And I did not like it.

The developers look: "Wow, before I could only drive the behavior of computers, but with this, this.... I can program people" (I won't go into the finer aspects of the developer psychology, including the way nerds are treated - hum ignored - by the cool business people - BPM as revenge!).
The manager's look: "Wow, so I get a process-driven application, which pushes my people's behavior, and gives me near real-time insight". (As most managers have had unsecure childhoods, BPM was the perfect way to regain control).

And the uneasy feeling I got, was also because at that stage as was reading lot's of management material, studying the history of management. The look in the eyes of these people felt "industrial revolution" or "Taylorian".
Interesting - a new innovative technology, that takes us back to the thinking of 80 years ago - ignoring all the developments in management thinking - empowerment, self-steering teams, work as social dimension, etc.
And it let back to the notion of "first process, than people".

Oh, by the way - the project failed. Insufficient user acceptance.

My lesson: Don't confuse the ends with the means. Process is not the goal - the goal is to support people collaborating and adding value to company and stakeholders. And process can be an element in helping these people structure and support their work. Process is (Capital) A means (and unfortunately often a barrier in many organizations...)

(This post also posted on http://www.noprocess.org/)

Proud to present: Capgemini's whitepaper on Case management

2011-03-05T13:25:00.000+01:00

See http://bit.ly/h39vAp

Understanding management's hesitance towards BPM

2011-03-04T20:46:00.003+01:00

Sometimes I get the feeling that BPM is a solution, still trying to find a problem to solve.
And I often hear BPM-specialists complain that "management does not support BPM".
Our research in the Dutch Market (this is a sneekpeek, watch this space, and Capgemini for more publications in a number of weeks!) suggests that BPM-specialists need to dare to apply a key BPM-principle on themselves: "Outside in thinking".
If management is the customer, why aren't they convinced of BPM?

In our research, we found a number of things, clarifying why management is not eagerly and happily jumping the BPM-train:

1. BPM is fairly complex and abstract

2. BPM takes time and requires a lot of energy from managers to fight the often dominant functional culture, existing in most organizations (and we all know: pick your fights carefully)

3. BPM has not delivered some of it's key promises (according to our findings):
- It has resulted at this stage in only limited increases in transparancy (process intelligence is mostly still a promise)
- Through BPM (as a discipline, with focus on maturity) organizations have not reached agility - changing processes is still hard and timeconsuming

4. Due to its history, BPM is often still viewed/confused as an IT-subject ("the new workflow")

5. The IT-promise of faster time to market of changes has not been delivered (and although our research does not give a cause, we suspect that many BPM-technology implementations are less flexible than expected and that many supporting IT-organisations still need to learn to increase speed, as they are likely caught in old-world "9 month" releasecycles, treating changes in processes and business rules as full fletched change requests)

Tricky situation. Even more if we see that research participants state that:
- The management of only a few organizations see and leverage processes as bridge between strategy and operations, using process interventions for change and improvements
- Management commitment is one of the key CSF's for BPM projects

My thoughts: for BPM to earn it's status as integral element in management and technology, we need to further develop BPM!
But.... We have some really interesting findings that suggest why BPM is already becoming an essential capability in best-in-class organizations - more on this later...

Short bookreview - ACM: Mastering the unpredictable

2011-02-27T23:02:00.002+01:00

Being very involved in the area of Adaptive Case Management at Capgemini, I am reading everything I find on the subject.

I recently finished "Mastering the unpredictable" - How Adaptive Case Management will revolutionize the way knowledge workers get things done. http://mtubook.wordpress.com/

A short review:

Pro's:

- Gives various, sometime overlapping, views on the subject of ACM

- Has some very clear viewpoints on the functionality and end-user perspective

Cons:

- No details on hard business cases - how can ACM actually be of real value to a business, besides the "improve productivity and increase transparency" promise?

- No information on approach. A lot of complaints about the traditional process-design methods, not suitable for knowledge work analysis, but no answers or a method on how to actually design a case management solution for a domain: how to deal with the complex set of rules, activities, data, functionality, input/output, events, etc.

- No case descriptions, with actual lessons learned by companies implementing ACM.

My conclusions: I was expecting more - am disappointed. Due to the overlap between the articles, no article really seem to go in depth towards practical implementation issues, business cases and tested approaches. Basically a lot of articles, each defining ACM and exploring some of the functional aspects. Good as an, somewhat lengthy, basic introduction to the subject (but much of that info can be found on the net as well...)

I won't enter the discussion of ACM being part of BPM or not. Well, a little bit: ACM is about activity, collaboration, transparency... If we restrict the "P" in BPM to Taylorian strict procedural processes, ACM would not be a part. But for me the P stands for productive people delivering results trough coordinated activities, making ACM part of BPM.

Maybe we should relabel BPM to BCM "Business Collaboration Management" or Business Value Delivery Management: the discipline of helping people to work together and deliver value....

By the way: Tips for better books are welcome....

Introduction to case management (presentation)

2011-02-22T23:31:00.001+01:00

I recently gave a presentation about Case management. It introduces case management as a business work pattern. I explore the characteristics of this workpattern, the current IT support, present the Capgemini BPM grid (a services classification method) and describe Capgemini's Case management framework. Various animations..

Introduction to case management - Roeland Loggen vs1.1

View more presentations from rloggen.

Dutch article: Link between BPM and groupdynamics

2011-02-22T22:48:00.003+01:00

Did you ever realize the strong relation between processes, BPM and groupdynamics?
Groupdynamics: http://en.wikipedia.org/wiki/Group_dynamics

The attached article explores the relationship, leading to valuable advice to business analysts and BPM consultants (note: written in Dutch).
Recently published in the Dutch BPM Magazine.

The article:

Artikel bpm en groepsdynamica vs1.0

View more documents from rloggen.

(Dutch) Onderzoeksenquete "BPM in Nederland - 2010" is live!

2010-12-16T12:09:00.002+01:00

[For Dutch readers only]

Actief met Business Process Management binnen uw organisatie?

Wij willen u graag uitnodigen om deel te nemen aan het onderzoek “Business Process Management in Nederland - 2010” , uitgevoerd door de Universiteit Utrecht in samenwerking met Capgemini.

Veel organisaties nemen initiatieven om beter grip te krijgen op hun processen. Dit blijkt uit toenemende initiatieven in organisaties rond “Business Process Management” (BPM). Maar wat doen organisaties rond BPM, welke resultaten bereiken ze hiermee, welke lessen hebben ze geleerd?
Belangrijke vragen die u, als u betrokken bent bij thema’s zoals bijvoorbeeld procesinrichting, procesmanagement, workflow, zaakgericht werken en operational excellence, waarschijnlijk ook zal hebben. De antwoorden uit dit onderzoek kunnen u helpen de BPM-aanpak van uw organisatie aan te scherpen.

Meedoen aan het onderzoek?
Wij vragen 20 tot 30 minuten van uw tijd voor het invullen van de vragenlijst over de adoptie van BPM binnen uw organisatie. U kunt de vragenlijst invullen via de volgende link: http://www.bpmsurvey.nl/Meedoen
Wij hopen uiteraard dat u mee wilt werken aan dit onderzoek.

Als deelnemer ontvangt u voorjaar 2011 het onderzoeksrapport “BPM in Nederland – 2010”.
Als blijk van waardering wordt elke 30ste deelnemer beloond met een boekenbon. Tevens wordt een e-reader verloot onder de respondenten.

Wat vindt u in het onderzoeksrapport?
Het rapport geeft u inzicht in de adoptie van BPM bij Nederlandse organisaties en omvat 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.

Heeft u nog vragen?Heeft u vragen over dit onderzoek dan kunt u contact opnemen met Joost Spekschoor via e-mail joost.spekschoor@capgemini.com of telefoonnummer 06-12545047.

We zien u graag via http://www.bpmsurvey.nl/Meedoen

Alvast hartelijk dank voor uw tijd en bijdrage!

Met vriendelijke groet,

Onderzoeksteam “BPM in Nederland - 2010”
Joost Spekschoor - Universiteit Utrecht
Michiel Havenith - Capgemini Nederland BVR
oeland Loggen - Capgemini Nederland BV

Stop thinking "Structure" is the answer!

2010-05-29T14:03:00.002+02:00

Sigh,

I see this pattern so often: a company is not delivering the expected results. And boom - management decides to change the structure. New departments, people moving. Networks lost.

Some say "In what re-organization are you working"?

My believe: it's NOT about structure. It's about people, network, patterns of interaction and trust, and, of course, processes.

And the sad thing is: with every structural reorganization, most attention and energy is spend on structure. And, with most "change capital" spent, people struggle to build up new network, patterns and processes (usually outside the sponsorship of management...) to deliver the same results (and in the beginning less) as a before.

Management, please: it's people, supported by their netwerk, interactions, trust and processes that deliver results. Structure is not the main thing, that's about power, and not about results...

Journey to the essence of BPM - part 1

2010-05-29T13:25:00.000+02:00

The last months I have been thinking a lot about BPM, trying to understand what's really the point. It started with doubts on the tangible benefits, but also on the true nature of BPM. What is it really? Still seeing a lot of definitions and notions around on BPM, I wanted to dive deeper and find some true meaning that really resonates, instead of the many "fluffy blabla" definitions.

First I want to share my thoughts about the concept of "process". Here I already see confusing notions and assumptions.

The common definitions of "process" typically resolves into something like "linked activities, reaching a certain goal, having inputs, outputs, people and machines performing them, adding some value to a customer, certain business rules that apply, etc etc".
The thing is: I have never touched a process. Never held one. And things not being physical means abstraction.

Let's get back to process. What is really?

Let's first agree a process is not a process-model. As the belgium painter Magritte stated "C'est ne pas un pipe": the drawing of a pipe is not the same as the real thing.

The only real thing I can think of is human (and systems) behavior. When one or more people and/or machines show certain behavioral patterns repeatedly, you might call that a process.

That already establishes a foundation for BPM. It's people (and machines), and their behavior.

What governs that behavior? What makes that we call certain behavior a process? Some explorations:

If a group of people has "behavioral" responsibilities in a certain area, I also could ask them "how they deliver certain results". Although differences will exist, they are probably able to recall their activities and can also tell me how they will behave the next time a certain result is expected. In that sense, "process" has a memory-construct, that will enable people to remember what to do.

In situations where people need to reach results, that require them to collaborate, people tend to communicate, negotiate and agree on required behavior (if you do.... then I will.....). In that sense, "process" is also about "social contracts".
A short side-step: I recently moved to a new apartment, and the movers showed a fascinating efficiency. The group of men clearly had worked many times together, and where really a team. Without much spoken communication, they rapidly worked together. And while watching them close, I could see various patterns and tacit communication. The "social contract" had been developed over a longer period of time, and was still evolving, improving, quickly reacting to new circumstances. When teams are really performing, process as a social construct does not seem to require "BPM sessions".

Am I getting closer to something that resonates as a true "process" concept?
- It's actual behavior of specific people and machines (without action, no process)
- It's about repetitive behavior of these people (only done once - no process)
- It's about knowledge and social contract (these people and machines are governed, and have, with more of less consent, agreed to/and know certain "playing rules")
- It's (sometimes!) about improvement and adaption (that might be done tacitly), when there is true "teamwork"

People behavior people behavior......sometimes is trying to tell me something, but I'm not there yet.
What I do know is that the traditional definitions of BPM are far from "specific people". It talks about process and maybe of people that are "resources" pushed as little pegs into RACI's. That does not feel right and also severely limits us in our BPM approach.

My gut feeling: BPM is about social interventions.
But more about this in the next parts of my journey!

Lean - can we also add value?

2010-05-20T22:10:00.003+02:00

Busy with a training on Lean. Interesting stuff, with powerful process improvement concepts and techniques.

One of the central concepts is value added. When analysing a process (or in Lean terms: value stream), one can find activities that do not add value to the customer. Basic question to find them: ask for each activity "is the customer willing to pay for this"?

To really be able to answer this question, one needs to understand how the customer views value: what is valuable for the customer, what does he/she expect - as a base, as extra value, etc. In Six Sigma terms "The voice of the customer".

This approach is strong, but has one risk: it might lead to a very reductionist view on process improvement: to (mainly) remove activities.
Great for lead time improvement and cost cutting. However....

What if, from a competitive perspective, there is a way to delight customers even better, by adding activities?? "Toolhead" lean will likely ignore this possibility....

Examples:
- The small gift my daughter got when she received an injection
- The extra time my dentist spends to explain the procedure and relax me
- The bicycle (hey, this is Holland :-)) the cardealer provides me for free, when my car is being serviced

These are the things that make me come back. Any examples you have?

This is the area of the strategy - process alignment: if you want to be special as a company, don't just remove waiste. Add extra value.

(Dutch) article published on Trends in BPM

2010-05-20T21:53:00.002+02:00

At the end of 2009, a number of colleagues and I published a (small) book on current trends in BPM (which is available in English in book and PDF-form, on request).

As an update, we recently published a Dutch article in the dutch BPM magazine, with 3 trend-updates. A version of this article can be accessed here: http://www.slideshare.net/htoebak/trends-in-bpm-2010-4149334

Feedback welcome!

Complexity Approach - A new perspective on organizations?

2009-11-17T10:52:00.004+01:00

When in the past, people discovered and created the clock, this new technology had great impact on the way they started seeing things. The clock, as concept, was used to understand other phenomena, such as our body, the movement of the planets, etc. As a model, it helped people conceptualize and understand things, which was great. But also – it limited their view (a model is less than reality). With the discovery of the computer, we did the same thing. Powerful, but we ran into difficulties, trying to explain, for instance, our brain-function, with the simplified concept of computer-concepts. Not everything was as deterministic as we needed, to apply the computer-concept.

More hidden, with the “discovery” of systems thinking, we have done the same. System thinking has lead to great conceptual tools, to….

Divide the complex reality in parts, that are interconnected, and as group, can be seen as a new part of a large system
Define “control” as a concept, where a part is steered (plan-do-check-act) by a “managing part”

This thinking and tools have helped us understand, model, realize and operate complex structures, such as IT-systems. Of course, we have used these concepts for other complex areas. So we started to use this in our view of organizations. And that’s where things started to become messy.
Are organizations systems? Are groups of people able to be divided in parts, where some parts are planning and controlling others, measuring output, and intervening when needed, to get the desired results? Or it this view limiting? Possibly even dangerous?

Last Friday, I visited an interesting seminar on a new approach to view (and intervene in) organizations: the Complexity Approach (or also known as Complex Responsive Processes). Some of the key people involved with this new view were present: Ralph Stacey, Douglas Griffin and Thijs Homan. In addition, Nol Groot (former director of the NS, the Dutch Railways) was present, as one of the people that have actively applied this new view in the NS).

Their research in organizations suggested that the system’s approach to organizations is limited. And that it had lead to surreal mythical set of beliefs in leadership and the ability to control and change the performance of an organization. A new view is needed.

So they decided to step back, and try to look at organizations in a fresh way: how are things done here, actually, really? What do we really experience?

This lead to the following observations:

People interact with other people (usually not the whole organization, but a smaller set) in varying interaction patterns. These “local patterns” (or “self-organizing collectives”) might be totally different than the formal organization structure (they may be based on friendship, identity, role, process, etc).
This is also true for managers (although in larger meetings they might send a lot, but is essence they don’t know how people interpret their message), breaking one myth “the manager knows all, oversees everything”
These local interaction patterns emerge – they are not created “by design” but appear and develop over time, through complex influences
Through interaction patterns, people get informed, negotiate and decide, based on their plans, intentions (I want....). In these patterns people confirm their values.
These interactions (or “interplays of intention”) produce results. Interaction patterns lead to meaning, changed attitudes, conflict, choices, activity and constraints. However, these results might not be the ones that the people had intended upfront (and might not be in line with manager’s plans and intentions!)
Example: two people want to eat together, and end up at a Italian restaurant, while neither had that in mind at the start
One of the results of local patterns are so-called “social objects”: agreements on how people should behave and perform activities in certain situations.

An example:

A manager gets his unit in the central hall, and tells them that the organization needed to be more customer-friendly. He explains his plans, and communicates that he expects everyone to commit to the plans.
People leave the hall, and in various complex interaction patterns, the view of the manager is given meaning, mixed with history (“we have done this before”) and own intentions, in various groups of people. Each group will develop their own meaning, interpretation. And the “company-wide plan” becomes a myth.
And change might come, yet not predictable, and maybe even in despite of all change management efforts

This new view leads to a number of important (and maybe even scary) questions:

Can a manager “be in control”, if activity and change is dependent on complex interaction patterns which are mostly unpredictable?
Is change “manageable”?
Is “resistance to change” something we see as a sign that our plans have not been executed enough yet, something that we need “to handle” and then reach success in the end?
Can we speak of organization? Or is it more a network of people (with endless dynamics in interconnections)? Can we speak of organization boundaries? Or again – complex interactions with people “inside” and “outside”?
Is an organization a set of local patterns of interaction?

(These questions resonate with various uneasy feelings I have about BPM and the "organization-people-process-by-design" myth, it implicitely suggests)

Yet, organizations seem to work, sometimes even great. So, the key question is: if an organization does not function well, what can we do as managers (and for me, as consultant)?
Some of my starting points:

Many instruments of intervention can still be applied. Be aware that interventions however produce non-predictable results (and non-linear: a small intervention might explode through all interaction patterns, a large intervention might be reduced to nothing....)
The process of giving meaning (how people perceive the need for change and the desired outcomes) is very difficult to manage. Even through various facilitation workshops, etc, people will have a “on-stage” face and a “off-stage” face. And the “off-stage face” will influence many people in their networks. In a typical organization many “clouds of meaning” might exist around certain themes. However, meaning is often given by fixed groups, based on their intentions and history. Investigation and narrative interventions could help here.
Be very aware of the existence of the (emerging) patterns, through all networks (visible, invisible). These “cells of people” have large influence. If needed (and possible), intervene in this patterns (for instance: break up the organization in smaller teams, build relations, make sure teams interact with each other, as a manager participate on one or more local groups, getting their respect)
Develop the ability/competency of people to effectively perform local patterns of interaction, and support them by providing clear intentions (on WHAT is needed, not HOW). Help them to be able to address concerns within the group. And become connected!
Become aware of the “social objects”, and how these objects are created and changed. Who has influence? Through what patterns?
Change occurs through interacting cells, that see the need for change, form new ideas and create new social objects.

This complexity approach is interesting stuff, which will probably have a large impact on how I see organizations, change, but also BPM! There is much more I could write, but let’s stop for now!
Ok, one last thought for us, consultants: We often see our project (which is a change intervention!) as a set of people, doing the planned activities. During the project, often “fuss”, “discussion”, “resistance” is born and needs to be handled. Often, I saw this stuff as uneasy, difficult, nagging stuff, that was extra effort and thus delayed the project. But maybe this stuff IS THE REAL the project!?

For more information on the Complexity Approach, see for instance:
http://www.amazon.com/Strategic-Management-Organisational-Dynamics-5th/dp/0273708112
http://www.herts.ac.uk/courses/schools-of-study/business/research/complexity-and-management-centre/complexity-the-experience-of-organizing.cfm

Sigh! Process as intervention is just not sexy...

2009-11-08T21:06:00.006+01:00

I am jealous.
I see many types of interventions that management can choose to influence people behaviour in their company...

I see great workshops focused on culture, people doing fun-games at remote locations, deep and inspired discussions on values
I see managers working on mission, vision and strategy in expensive resorts, golfvenue around the corner
I see IT-systems being designed, and delivered, forcing people to follow the screens and workflows embedded in these systems, with all kinds of cool UI-widgets
I see budgets being given or denied
I see people in fun training
I see promotions, new hero-managers, with powerfull mandate
I see jobpromotions, jobdescriptions and evaluation cycles that will actually hit people in their wallet, with big bonusses for the right behaviour

And then there is us, process consultants, proudly showing the next swimminglane model and desperately trying to find someone to take process-responsibility...

How sexy and influencial is that??????

Can anyone help this disillusioned BPM-practioner with concrete examples of process-interventions that inspired, motivated, improved, e.g. sexy?????

10 easy? questions for managing IT-change

2009-11-08T19:58:00.006+01:00

Where various parties from business and IT collaborate in deciding on IT-change (implementing changes, based on various new or changing requirements), a complex playingfield arises.
Often, in my observation, many companies struggle, in terms of "who will need to decide what", during the preparation and delivery-phases of IT-changes. With a more fundamental understanding of the types of questions that needs to be answered and the ownership of these answers/decisions, more clarity can be created (and confusion avoided...).

I think, in essence, we have to deal with 10 easy questions. Well, easy, in terms of the answers provided, they are easy, but to answer them with confidence, based on the right information, might be quite complex....

Here are the 10 questions, that should drive your change-process (for instance your ITIL change process, or any other changeprocess, for instance in deciding and implementing change-requests for your software applications) and create a clear demand/supply relation:

Before realizing the change:
1. Do we understand and really want this change? (business)
2. Are we willing to invest to research solutions? (business)
3. Is the change really feasible, what solution-scenarios exist? (IT)
4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)? (business)
5. Can we agree on a realistic start- and enddate? (Business and IT)
6. Do we commit to adequately lead the change from the business perspective? (business)
7. Are we, as IT, willing and able to commit to deliver the chosen solution? (IT)

After realizing the change:
8. Do we accept the delivered solution? (business)
9. Are we willing to implement the solution in our operations (and supporting IT-layer)? (business)
10. Are we done, happy and ready to move on? (business and IT)

I hope that during your changeprocess these questions are clearly answered by the right stakeholder!

In more detail:

1. Do we understand and really want this change?
Key owner: business (and IT to advise)
Remarks: we need to adequately understand a change-request, and assess (preliminary) if it is realistic (we want our app to make coffee, but the end of this week)...
Subquestions:
- Is the submitted change-request clear and understandable? Is the context (Why, Who) clear? Is it (preferably) mainly stated in "what" terms (business requirements), and possibly supported by (preliminary) "how" statements. Is there a "When"?
- Is the requested change (in principle) feasible? (IT advise!)
- Is the (preliminary) "When" (in principle) realistic? (IT advise!)

2. Are we willing to invest to research solutions?
Key owner: business
Remarks: only for very simple requests, we might directly see the solution and required changes in our IT-landscape. More often, IT will need to research the request, and come up with various possible solution-scenario's, that each has it's pro's/cons and consequences
Subquestions:
- Are we willing to free and assign capacity @ IT to research the requirement, and wait for some time to let them deliver? Do we accept the cost? Owner: business
- Are we, if needed, willing to deprioritize other IT-activities, to let this research be executed? Owner: business, with strong IT advise
- Are we able (as business) to further guide IT (and answers business related questions about the requested change)? (business!)
- Are we able to deliver adequate research? Do we have the resources with the right experience and knowledge available? (IT!)

3. Is the change really feasible, and what solution-scenarios exist?
Key owner: IT
Remarks: Based on the changerequest, IT needs to research: can we do this, and how (not in all detail, but in enough detail to have enough trust to answer the question and allow the business to decide the next steps). Research in terms of technical scenario's, their functional and technical impact for the business and IT and the consequences of the solutionscenario, in terms of cost, required resources, time, risks. And an assessment how the scenario fits in the architecture(plans and guidelines).
Subquestions:
- Are there technical solutions that fulfill (fully or partly) the requirements from the change? If yes, what solutions?
- For each solution:
- what are functional consequences
- what are technical consequences?
- what are consequences for future maintenance and supportability?
- does the solution fit in the current/to be architecture?
- And for each solution: how can we realize this solution, in terms of approach, cost, time, required resources? What risks?

4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)?
Key owner: business
Remarks: In the end, business needs to decide the scenario and accept consequences (to it's operations and the related change-efforts/investments)

5. Can we agree on a realistic start- and enddate?
Owner: Business AND IT
Subquestions:
- Does this fit in current plans and available resources?
- If not, can we agree on re-priotizing/delay other requests?
- Are there other solutions (in terms of sourcing)?

6. Do we commit to adequately lead the change from the business perspective?
Owner: Business
Remarks: This is a critical question. Many IT-projects suffer from ambitious business, that fails to provide clear and adequate guidance (enough support and time from critical business people) and speed of decisionmaking
Subquestion:
- Can we, as business, free the required people as leaders and subject matter experts?
- Are we willing and able to setup a good issue-resolution process, and commit to it?
- Are we willing to steer the project, take part in steering organization and make tough decisions in a timely fashion?
- Are we willing to invest in the relations and social networks between business, IT and project?
- Do we have but also feel the trust that we can work together with the people on the IT-side?

7. Are we, as IT, willing and able to commit to deliver the chosen solution?
Owner: IT
Subquestions:
- Do we have the drive, trust, knowledge, experience to deliver?
- Do we have the maturity to manage this?
- Do we feel the circiumstances are right? All critical succesfactors covered?
- Do we have but also feel the trust that we can work together with the people in the business?

8. Do we accept the delivered solution?
Owner: business
Remarks: IT has delivered now, and we have taken various actions to gather information on the solution. We checked in various tests and reviews if the solution conforms to the change-requirements(verification) and also checked if the solution will work in our operations(validation).
Subquestions:
- Does the solution comply to the requirements?
- Will the solution fit in our operations?
- Do we have sufficient information to really assess and decide on acceptance?

9. Are we willing to implement the solution in our operations (and supporting IT)?
Owner: business
Remarks: now it's time to get the IT-change in production.
Subquestions:
- Are we ready?
- Has the change been rolled out correctly?
- Acceptable risks for operations?

10. Are we done, happy and ready to move on?
Owner: business and IT
Subquestions:
- Will the business case be reached?
- Is the change correctly functioning in operations?
- Can we close the change, with full satisfaction?
- Did we learn the right lessons? Will we remember them?
- Are we still respected partners?

Five models to assess your project and stay sane

2009-09-06T15:47:00.007+02:00

BPM, IT, and actually any type of project can sometimes be overwhelming in complexity, issues, social patterns and such. In my 17 years of projects, I have developed enough scartissue... And for the more junior-readers: yes, projects fail, including projects I was part of....
In the 17 years I also tried, every time, to learn and understand what happened in the project and why it was a failure, a challenge or a success. It lead to a large set of "sanity checklists" and other best practices. And also to quite some analysis-tools. In this post I want to share 5 easy diagrams as tools for analysis of the project you are working in (or better: about to work in). The tools deal with simple questions you can research within your project. It leads typically to 2 answers: the way it is currently, and the way it should be to be able to deliver succesfully.

Model 1:
Model 1 deals with the process or method you need to choose to deliver the projectproducts.
Two simple questions, try to answer them, map out where it lands in the diagram and then compare to the method that has been chosen for the project (hopefully it was a deliberate choice, and not the often occuring "goodwilling people, yet chaos approach").

Model 2:

Model 2 deals with the amount of ceremony in terms of process and documentation you will need. Again two simple questions.... This tool is great to work with people that either want to overstructure/overdocument when it is not required or people that want to travel very very light, when more is needed...

Model 3:
Model 3 deals with control on the content in your project (so, not on time/cost, which typically already gets enough attention). This deals with: how do we deal with uncertainty in requirements or design. I see many projects that fail to create control over these vital elements. The results are typically confusion, failing assumptions and rework...

Model 4:

Model 4 deals with leadership versus group-behaviour. I have seen projects deliver with low leadership or low groupcohesion, but the combination of these situations is typically deadly. I believe in groups and the great work that can be done by them, but only if they are willing to allign to goals and have enough social cohesion. Usually this occurs if you are working with people that have enough skills and limited ego to cooperate or a strong leader that is able to align people...

Model 5:

The last model is about you (or the people you depend on in the project, enabling you to deliver your scope of the project). I developed it when in a certain project I was very unhappy. I tried to understand why - and found that I was very involved/committed, but had no real influence, in a project which was heading for disaster. Stuck between a rock and a hard place, with only three options - get more influence (tried, no succes) or don't care anymore (not my style), or... get out. I choose the last option, with no regrets. The project failed 3 months later.
More lessons and tools welcome!

5 ways to green BPM

2009-07-22T12:28:00.003+02:00

In all the turnmoil on the global crisis, but also the media storms on "clouds" within the BPM community, I hope there is still some space left for sustainability, people/profit/planet and environmental issues.
In my opinion, a process-focus can strengthen our ability to improve the sustainability of our business and reduce the negative environmental footprint: P4 (people, profit, planet - and process).
BPM, as a framework for seeing your company through the lense of process, aims at understanding, measuring and improving your processes. While the traditional focus for BPM is things as cycle-time, cost, customer value/service, environmental aspects can be easily incorporated in the BPM approach.

I suggest 5 possible ways to use BPM in greening your processes and business:

1. Analyse - Measure - Select
As part of most BPM efforts current processes are modelled/documented and measured. This provides important insight to know where improvement-areas are. For sustainability we should be able to come up with "GPI's" (thanks to my collegueas for this term) - green performance indicators. Measurements based on these GPI's can give a company insight in their processes: which processes (and even which steps in these processes) have a large environmental footprint.
You can use this information to define an actionplan, and select the processes where the "biggest bang" can be reached. The starting-measurements can later be used to compare to improvement-results. And you might even want to decide to incorporate periodical measurements of your "GPI's" in your Green Balanced Score Card.
As a sidenote: measurement can also support benchmarking, which could help entire industries (why do we need 10 kg of paper in processing 100 insurance-policies, while our competitors can do with 1 kg?)
As part of the process-analysis, the company could attempt to find aspects of the processes, thay may drive environmental footprint - for instance: is there a lot of paper used, a lot of km's traveled, a lot of interaction between various locations/people to execute this process?

After step 1, a number of other steps can be taken:
- Optimize
- Recycle
- Innovate/Re-engineer
- Synergize

2. Optimize
Using techniques from Lean and Six Sigma, various Green optimizations can probably be found. The 7 Waste approach could for instance identify unneeded transport (CO2!). The Six Sigma Root-cause analysis could help identify unwanted environmental effects and their causes.
All these results can be used to gradually improve the process
Case: by stepwise improvements paper-production companies are lowering the amount of water needed, and reduce the water-pollution
Case: a company allowed people to work from home on certain days, using a PC, which reduced CO2 / transport

3. Recycle
It might be possible to recycle materials used as input or output (either process-products, or supporting material). In many industries bottles, glas, paper, etc. is being recycled.
Case: diary factory sells milk in bottles, which are being returned by customers for reuse

4. Innovate/Re-engineer
Taking the BPR approach, one might be able to totally reengineer the process, so that a radical better environmental effect can be used. In some radical cases, the process might not even be needed anymore
Case: various companies re-engineered their invoice-processes, making them all digital instead of paper. Paper and transport went down considerably.

5. Synergize
By closely looking at your process (inputs, outputs) and other processes (within you company or outside), it might be possible to identify ways to create environmental synergy.
Case: an IT-company located their datacenter in a greenhouse-area. The heat of the datacenter is used to warm the greenhouses.
Case: a Shrimp-farm located their farm next to a large energyfactor, the emitted heated water is used to warm the shrimp-bassins.

One might think that these steps can only be applied to production-industry. But....
In many administrative factories, processes consume large amounts of paper, storage and transport of paper, and transport of people for meetings. The 5 items above, combined with BPM technology, supported by ECM and Collaborative tools (videoconferences) can deliver great green effects (and hard Euro/Dollar-savings!).

Cases and Ideas welcome!

A day in the life of a processconsultant

2009-06-24T20:15:00.007+02:00

I am currently in the luxerious but also difficult position of a processconsultant in a quite demanding project, that requires effort from me in a wide range of (process)consultancy areas.
Warning: if you think processconsultants listen, then goto their room to draw and publish processdiagrams, and magically people will follow these... read on....

Here are 5 areas you may encounter as processconsultant depending on your scope and influence. Or in my case, because in these areas things were not evolving well, and were impacting my ability to deliver good results, so I, sigh, jumped in.... (but do check your client, to see if they want you there....)

Area 1. Power discussions
The funny thing about most processes, is that they cut through various functional areas, with their own reporting structure. When designing new processes, early on (or in some cases, too late) the powerquestion will pop up: who will be responsible for what part of the process. And this means the interesting culture of manager's ego's (score!) and risk-aversion (avoid!)
As a processconsultant you might find yourself in workshops, email fights, and waiting for the "oracles" to decide (and hope the verdict will stay the same for some time...)

Area 2. Strategy clarification/operationalization
The typical thing you want as an organization is that your processes actually support (or realize) your strategy. Porter calls it "FIT". And the funny thing about many organizations, especially during change-dynamics, is that some of the strategy might be defined (and sometimes even written down! Sorry, ironic), but often, the management "bla" is so high-level that even selling icecream might be a perfectly fine process with great strategy alignments in terms of "customer focus, quality, etc". So, to bridge the gap between strategy and operations, strategy will need to be detailed in more operational aspects. As a processconsultant you might find yourself coaching mid-level managers to translate the management bla to things that have meaning for the mortal souls, including yourself to be able to define the right process.

Area 3. Groupdynamics and coaching
So you think doing some interviews, showing the diagrams will create alignment? Will create support for new ways of working? Think again. Change is hard, and building support for blueprints describing the future, while it's being build is even harder. As a processconsultant you will find yourself often in groups that are in various forms of disagreement. And often they will look to you, to help/facilitate them to find the answers. Their points of view might confuse you, irritate you, and/or enlighten you (and possibly all at the same time). Help them to find consensus. But you will need their teamlead to decide and steer, where needed.

Area 4. Operational negotiations
Ah, the processdesign looks good, but now the real work starts: implementing it. This will lead to many additional process aspects. How will work be coordinated? Who will sit in what governance structure? Who does what in the processpart of this team? How will we split the work? How do we deal with performance requirements? Vacations and workschedules. A lot of processlogistics need to be settled. As a processconsultant you will find yourself in various HR type discussions, trying to get the team to work....

Area 5. Steering, coaching the manager/teamleads
You may have defined a great process, and even defined key performance indicators (KPI's), but the teamleads need to be empowered: what will they do when one of the KPI's goes off bounds? What steering mechanism do they have, and when will they use it? How to help them get beyond firefighting (which is often a start for processimprovement) culture and get them to start steering in a more tactical way?

Some tips and best practices
- Know your scope as processconsultant, and be conscious about extending your role (you might have too much work and/or too little influence)
- Know your groupdynamics (norming, forming, etc) and change (ADKAR, Carnall's Coping Cycle). Keep an open eye on what's happening in the team(s) around you.
- Be able to operate on strategic, tactical and operational level (including the people on these levels - culture, network, vocabulary)
- Be able to step into the facilitator's role, guiding people to make their own choices (it's their process anyway, "egoless processdesign")
- Ambitions for change might be high, but ability to deliver in the organization will determine the actual results. Be pragmatic, but also don't get crushed between vision and results.
- Maturity for an organization will take time and the right interventions. Be patient when needed, and let things fail even, if needed to get messages/learning across. "If that what must, can't, then make sure what can must" (freely translated from dutch).
- It's people, your work is about people (and a bit of process)

Concluding thoughts
I seem to return to a central purpose for a processconsultant - mainly: to create clarity, consensus and alignment (say 95% of your time), the rest: dropping it in (ever evolving) processmodels.

Last: spend your energy in your own developments accordingly (learning in 2 weeks all the details of BPMN might be interesting, but you might need other priorities ;-))

Work in a process. More then we typically see...

2009-06-14T22:00:00.004+02:00

Recently delivered training to a group of processconsultants. One item is "workflowmanagement" (no, I do not mean the technology). What we mean in the training when we talk about workflowmanagement is all the work and supporting business rules that coordinate the work being done, e.g. that make the work flow.

Interestingly enough, the students had a hard time seeing the point.

When we talk about a process, people typically limit their view to the direct work being done. If a process consists of activity A, B and C, then, when asked what work is done in the process, they will say "well, A, B and C". Sometimes we play a little game with them, to clarify: we assign tasks A, B and C, and tell them to go ahead and do the process. Work evolves and quickly we can point to new tasks that people suddenly are doing: coordination, making the work flow. Making sure the output of A is delivered to B, so the person doing B can continue. People than understand that transport is an additional activity. But unfortunately, they still don't see that the transport also has a hidden business rule for coordination "if you receive output of A, then start processing B".

The (unfortunately now technical) concepts of "orchestration" and "choreograpy" are two patterns that are used a lot when people are doing work and coordinating the work. Often we see choreography, where people have thought upfront on the process, and agreed on various actions and rules to let the work flow ("so if you are ready with X, you give it to me, and I will...."). Orchestration you see somewhat less: "Micromanaging supervisors", but in, for instance warehouse picking, there is usually a central coordinating unit that hands out work-orders, and triggers other work-orders when the earlier work-orders have been reported ready.

As part of an MBA training we played a process simulation game, to practice applying lean techniques to improve the process. When the group analysed the results of a round of playing, suddenly someone discovered her own "choreograph" activity and the bottleneck it created: the person "batched" outgoing work and delivered when the stack was getting too big (bottleneck 1) and also delivered the items as Last In, First Out order, which later in the process created longer and variating cycle times (bottleneck 2). A nice example of suboptimal workflowmanagement....

My point: in every process, there is a hidden set of activities and business rules, that make the work flow (in terms of activating/triggering people to wait/start/continue). When optimizing processes, this "hidden" process is a vital element in process optimization. We might blindly stare at improving executing A, B or C, but looking at the coordination and supporting rules will also often give a lot of optimization possibilities.

Assignment: next time you encounter a process (say, eating out) watch the process coordination going. You will see a lot of stuff happening and (sometimes) fail....

Process-design and your view on people

2009-06-14T21:45:00.004+02:00

Quite busy, so my flow of blogitems has been diminished considerably. But collecting a lot of thoughts, observations and lessons, so maybe some time soon....

Today's thought: view on people

As processconsultant, I think it's vital that you have a clear understanding of your own view on people in the context of processes.
I encounter two opposing variations in the BPM world (and anything in between):

1. As processconsultant, we gather input, then design the process, then implement it. Implementing means: pushing people in the pigeonholes (processes, activities, roles), and assume they will do their work, driven by KPI's and managers whipping the lot.
The basis assumption: if you design, they will come and do. The rest is "changemanagement", where we explain and assume that either "they" accept, or we encounter "resistance", which we will need to "overcome". We own the process, but accept "input".
I find this approach also a lot in the BPM technology space "Buy this tool, define the process, and your people will obey and empty their taskboxes....".
So, first goals, then process/technology, then people.

2. Processes are done by people, to reach certain goals. So... first we have goals, then people, then, as a supporting mechanism, we have processes. Quite a different viewpoint! Here we first have to understand the goals of the organization and find people willing to support these goals (if nobody found, the rest is pointless). Once we have these people, we work with them (as a supporting/facilitator) to help them structure their work to reach those goals. They own the process, we bring in the process-structuring knowledge.

I firmly believe in approach 2. Yes, it requires more talking, and even more scary: being vulnerable and sometimes unsure what the people/group will want/do/support. It means running workshops, not owning the result, only the way to get there.... It also means accepting that the quality of the outcoming processes is purely based on the maturity of the people you work with. And with careful interventions you might be able to stimulate/let them grow.
In my experience I have to often seen type 1 approaches result in a lot of paper or BPA tools filled with stuff, but no implementation or support from the key people you need for working processes: the process participants or better: the PEOPLE, that understand and are happy to be supported by the process.....

Need for other BPM patterns - business focused

2009-03-11T09:35:00.003+01:00

A lot of research has been done in the area of process patterns, mainly performed by the TUE (The Netherlands, see here) and QUT (Australia, see here). These patterns are great for validation of the capabilities and semantics of process languages (BPEL, BPMN) and technologies.

However, I think we are missing a set of process patterns, that are business focused. If we would have a good set, I think it will help us delivering projects better and quicker, and also improve our communication between business and BPM technology consultants.

Comment: When I was working on the patterns below, I found that these are mainly task focused. Flow aspects can be served well with the workflow patterns.

Based on my projects experience, I could already see a number of task patterns:

A. Simpel patterns - typical serial workflow based processes

A1. Information capture
A task in which a person is required to capture information from sources outside the system, such as a phonecall or paper-document and enter it as structured and unstructured data.

Typical context:
- Salesrep
- Call center
- Internal HR procedures

A2. Information extraction and structured storage
A task in which a person is required to review unstructured data in the system (such as the scanned image of a document) and extract data and enter it as structured data.

Typical context:
- Backoffice document processing

A3. Prepare advice
A task in which a person reviews the data of a specific request, refines the data using functionality of the system (for instance certain calculations, risk assessments, price, etc) and prepares an advice ("yes, I propose to sell this customer a policy type X, with these conditions")

Typical context:
- Front office processing, sales, underwriting

A4. Decision
A task in which a specific person, based on her/his role needs to decide on something. The task will provide for the required information (case specific, possibly also other data), and the person will need to make a decision.

Typical context:
- Approvals

A5. Review based on 4-eyes principle/judgment
A task for which a person needs to review the correct execution of an earlier task (usual: prepare advice, decision) and make a statement of the correctness of the execution, leading to acceptance of the tasks output or rework.

A6. Inform
A task (or better: a notification) informing a certain stakeholder about critical facts about the execution of a specific process instance ("your request was accepted, your loan will be payed ...."

B. More complex situations
Many more patterns can be defined for process execution. This would support more complex knowledge work situations.
Think of:
B1. Collaborative event for sharing (plan, execute)
When more than 1 person is concurrently needed for a task, in this case: sharing of information
B2. Collaborative event for decision
When more than 1 person is concurrently needed for a task, in this case: deciding
B3. Add a dynamic task
B4. Add process participants

C. Controling & Steering (operational management)
Each process also has a "control" proces (the P, D and C parts of the Plan-Do-Check-Act cycle). For this process it's valuable to also have standard patterns...

C1. Warn
Warn a certain person if specific KPI's of a certain process instance are out of bounds.

C2. Escalate
If a certain task has not been done in a certain predefined time period, escalate it to someone else (automatically, or manually after a signal), higher up the organization

C3. Re-assign
If the workload of a person or team is too high, reassign one or more tasks to another person/team, but on same organizational level

Has these types of patterns already been defined somewhere? Used? Curious.

9 best practices for a solution & process architect

2009-02-27T21:53:00.003+01:00

Recently, I participated in a survey where they asked: what are key best practices that a solution architect should remember. When I reread my answers, I found that my best practices actually also work fine for process architects.

Here they are:

1. Beware YAGNI (You are not going to use it): base your solution architecture on traceable requirements and no more

2. Mind the coupling of components: the less a component knows, the better

3. Beware TAGRI (They aren’t going to read it): travel light, document what’s necessary and translate/summarize to various stakeholder viewpoints to get buy-in (or at least understanding)
(TAGRI was defined by Scott Ambler, in a great essay: http://www.agilemodeling.com/essays/tagri.htm)

4. Business managers don’t care about SOA. They care about that customers are served, employees can do their job, cost, time to market and flexibility/agility

5. Have a clear conceptual model of the concepts that you will use (logical component, technical function, datamodel, etc) and how these concepts relate + trace back (and forward) to other artifacts

6. Talk to the system management people too – certain non-functionals (reliability, security, etc) will drive a lot of your architecture and these people need to become your friend too…

7. The sooner the people in your team start coding, the longer it’s going to take

8. Business analysts focus on the WHY and WHAT and represent demand, architects focus on the HOW (and WHY HOW) and represent supply, don’t get this mixed up

9. Focus on the complex scary stuff first, even though the simple stuff might make you seem to have a lot of progress

A new form of business rule mining and validation?

2009-02-26T20:03:00.003+01:00

I am fully emerged in a business rules automation project, as a process consultant for rules governance.

Last week I received training in the business rules management suite that is used within the project (Be Informed, a promising dutch player, see their website).
And it brought me back years ago, when I was programming (during my time @ university) in Prolog.
Part of my Prolog assignment back then, was to implement an algorithm (from Quinlan) from the Artificial Intelligence - Machine learning domain (see for instance http://en.wikipedia.org/wiki/Supervised_learning).

It worked basically as follows:

You gave it a set of examples, in which each example contained a set of variables and their data, and an associated classification.
For instance:
(Color=Red, Tiers=True, NrOfTiers=4, Engine=True, Sail=False, CanBeInWater=False) -> Car
(Color=Green, Tiers=True, NrofTiers=2, Engine=False, Sail=False, CanBeInWater=False) -> Bike
(Color=White, Tiers=False, NrOfTiers=n/a, Engine=False, Sail=True, CanBeInWater=True) -> Sailingboat
Etc.

When you ran the algorithm, it was able to analyse the examples and classifications, and come up with a minimum set of rules that matched the key determining variables and classification, e.g.:
(Tiers=True, NrOfTiers=4, Engine=True) -> Car
(Tiers=True, NrOfTiers=2, Engine=False) -> Bike

Back to the project....
Considerable time is currently spent in the project for business rule elicitation. Workshops, study of systems, analysing documents, analysing legislation, etc.
In a recent project someone in my company worked with Process Mining, in which logfiles were analysed, and based on the logfile a process diagram was constructed (+ all kinds of performance data).

Adding algorithm, effort and the concept of process mining, made me look up Rule Mining (see http://en.wikipedia.org/wiki/Business_rule_mining). Strangly enough this differs from the concept of Process mining (it does not analyse data, but code).

And this triggered the following "Wouldn't it be cool" idea:

What if we constructed a strong machine learning algorithm component in a business rules management suite, that was able to analyse great sets of (historic) production data and construct the business rule set that was apparently used?

Example: we have a large CRM database and a Billing system. We create a combined table:
(Customer data), (Order data), (Billing Data) and select certain variables that we want to explain, using business rules based on the remaining variables.
For instance: what are the rules for VAT, discount and Gold membership?

The algorithm would do it's work, and create the minimal rule set...
For instance:
(Country=Netherlands) -> (VAT=19%)
(Orderamount > 200, OrderAmount <300, country =" Germany," customerindustry =" Bank)"> (Discount = 5%)

I see a number of benefits:
- Saving time for rules elicitation
- Retroactively understand what rules where used, and compare them to the existing policies (compliance checks)

Do any of the current BRMS have this feature already? (Time to patent ;-))

For a great overview of machine learning basics:
http://www.informatica.si/PDF/31-3/11_Kotsiantis%20-%20Supervised%20Machine%20Learning%20-%20A%20Review%20of...pdf

BPM vendor brand confusion vs analyst power....

2009-02-19T22:55:00.003+01:00

Hmmm,

Received emails from two different vendors, with an invite for Gartner's European BPM conference. Strange, same template, same discount.
Singularity and Metastorm.
If I scan the text, appearantly the BPM vendors are allowed to place 1 - 2 line of own text. Talk about Analyst power....

Singularity will be demonstrating how you can urgently cut operational costs in the shortest possible timescales using our unique high-speed process reengineering approach.

Metastorm is the leading provider of business process solutions. Metastorm BPM® allows you to quickly implement, manage, monitor and analyze improved business processes.

===============

Gartner Business Process Management Summit 2009Using BPM to Thrive, Survive and Capitalize
Register Now
Summit Website
Other Gartner Events
Dear Roeland,Singularity is delighted to support the Gartner Business Process Management Summit 2009 taking place 23-25 February 2009 in London and, as sponsors, we are able to offer you a special 20% discount* on the standard registration fee!Gartner predicts: More than 50% of BPM programs will fail by 2011. How do you make sure your BPM program will be successful by 2011?While you can’t control the economy, you can control the business processes that lie at the very heart of your organization’s ability to survive, thrive and capitalize, even in the most volatile of circumstances.Hear it first at the Gartner Business Process Management Summit, 23 – 25 February, in London. Discover the latest BPM developments, business insights, research and case studies that will help you to:
•
Deepen your understanding of process-driven innovation, continuous process improvement and efficiency
•
Sell a BPM project’s value and obtain executive buy-in
•
Gain the latest change management advice to accelerate business transformation
•
Navigate the BPM vendor landscape to evaluate and select vendors and service providers to invest in the right tools for better planning, budgeting and forecast
•
Learn best practices with BPM project management do's and don'ts to save time, money and effort
•
Recognize the opportunity to avoid costly BPM integration nightmares!
Business Process Management has been at the top of the CIO’s agenda for the past several years and the challenging economic climate makes BPM even more of a strategic imperative.Make better BPM investment decisions, health check your plans and projects and get connected at the Gartner Business Process Management Summit, 23–25 February, in London, the most relevant, timely and important conference.Singularity will be demonstrating how you can urgently cut operational costs in the shortest possible timescales using our unique high-speed process reengineering approach. Review the program and register today.Your processes have never been more important.Online: europe.gartner.com/bpm Phone: +44 (0)20 8879 2430Email: enquiries.events@gartner.com*This discount offer does not apply retrospectively.
europe.gartner.com/bpm
Price Discount

We can offer you a special 20% discount on the standard registration fee - a saving of €539! Register Now and quote XXXXXX to receive your 20% discount.
Team Benefits

No single delegate can possibly cover an entire Summit and extract all of its value. That's why so many enterprises send entire teams.– Get preferential access, as a team, to your preferred analyst of choice – Exclusive meeting rooms for intrateam meetings onsite, subject to availability
Analyst One-on-One

Don't miss out on the opportunity to spend 30 minutes privately, for FREE, discussing a topic of your choice with a Gartner analyst who specializes in this area. (registration is required) Register Now
View the Brochure

© 2009 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates.
PrivacySingularity provides a variety of information through its website pages and offers readers of that information the opportunity to request further information or interaction with Singularity. This Privacy Policy outlines Singularity's approach to use of information you might supply to us during these interactions. Please read full Privacy Policy hereUnsubscribePlease send us an email with the title "Unsubscribe" to: m.white@singularity.co.uk

Gartner Business Process Management Summit 2009Using BPM to Thrive, Survive and Capitalize
Register Now
Summit Website
Other Gartner Events
Metastorm is delighted to support the Gartner Business Process Management Summit 2009 taking place 23-25 February 2009 in London and, as sponsors, we are able to offer you a special 20% discount* on the standard registration fee!Gartner predicts: More than 50% of BPM programs will fail by 2011. How do you make sure your BPM program will be successful by 2011?While you can’t control the economy, you can control the business processes that lie at the very heart of your organization’s ability to survive, thrive and capitalize, even in the most volatile of circumstances.Hear it first at the Gartner Business Process Management Summit, 23 – 25 February, in London. Discover the latest BPM developments, business insights, research and case studies that will help you to:
•
Deepen your understanding of process-driven innovation, continuous process improvement and efficiency
•
Sell a BPM project’s value and obtain executive buy-in
•
Gain the latest change management advice to accelerate business transformation
•
Navigate the BPM vendor landscape to evaluate and select vendors and service providers to invest in the right tools for better planning, budgeting and forecast
•
Learn best practices with BPM project management do's and don'ts to save time, money and effort
•
Recognize the opportunity to avoid costly BPM integration nightmares!
Business Process Management has been at the top of the CIO’s agenda for the past several years and the challenging economic climate makes BPM even more of a strategic imperative.Make better BPM investment decisions, health check your plans and projects and get connected at the Gartner Business Process Management Summit, 23–25 February, in London, the most relevant, timely and important conference.Metastorm is the leading provider of business process solutions. Metastorm BPM® allows you to quickly implement, manage, monitor and analyze improved business processes.Review the program and register today.Your processes have never been more important.Online: europe.gartner.com/bpm Phone: +44 (0)20 8879 2430Email: enquiries.events@gartner.com*This discount offer does not apply retrospectively.
europe.gartner.com/bpm

Price Discount

We can offer you a special 20% discount on the standard registration fee - a saving of €539! Register Now and quote XXXXXXXX to receive your 20% discount.
Team Benefits

No single delegate can possibly cover an entire Summit and extract all of its value. That's why so many enterprises send entire teams.– Get preferential access, as a team, to your preferred analyst of choice – Exclusive meeting rooms for intrateam meetings onsite, subject to availability
Analyst One-on-One

Don't miss out on the opportunity to spend 30 minutes privately, for FREE, discussing a topic of your choice with a Gartner analyst who specializes in this area. (registration is required) Register Now
View the Brochure

© 2009 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates.
Metastorm Ltd. is a company registered in England and Wales with company number 2322265.Keep email from Metastorm coming! To make sure you continue to receive our emails, please add contact_metastorm.com@mail.vresp.com to your address book or approved sender list.If you no longer wish to receive these emails, please reply to this message with "Unsubscribe" in the subject line or simply click on the following link: Unsubscribe

Click here to forward this email to a friend

MetastormCentral House,1 Alwyne Road,London, England SW19 7ABUK
Read the VerticalResponse marketing policy.

BRM - not: BR projects!

2009-01-29T20:39:00.002+01:00

As I am involved in trying to define, design and implement "business rules governance" (in terms of events, processes, roles, responsibilities, products, etc), I am amazed how tool focused the world currently is (both in rules and BPM).
Checking most vendors site's reveal most of them have "methodologies" to implement their tools, mainly on a project basis. But no word on what type of processes and governance you need when the project has ended.
I find that strange: agility comes after the project, and you will need more than a tool.
Additional confusing factor: that most vendors, when asked about "Business Rules Management" start talking about features in their tools.

I saw the same thing in the BPM market, but slowly, very slowly, BPM technology vendors start understanding the BPM is a management discipline credo, and see that features are there to support process governance processes.....

Execution excellence? Tools will help, but you need governance

2009-01-29T20:11:00.003+01:00

I am currently involved in a large transformation program for a Dutch governmental agency. They are busy with pretty innovative stuff: case management, business rules, automated decisions, rules engines, document management - e.g. all the ingredients for the modern data processing company.
A number of key goals:
- Agility - the ability to respond to changes in external (and internal) laws, policies rules in a quick and effective way, with low cost and low risk
- Visbility & Compliance - the assurance that policies and rules are followed
- Efficiency

This organization realized that these goals required more than just an innovative application landcape. They realized for instance that employing rules technology only brings real benefit if they build a capability to quickly and correctly analyse, change and deploy rules. This requires a number of clear processes, value adding workproducts, responsibilities, supporting tooling, trained resources.
I was brought in to support them to define these things and to implement them. I would call it: implementing business rules governance.

For me, partly this is a BPM job: making the organization more process focused, to that they can deliver change in a controlled but agile way. But as a BPM consultant, working also frequently in IT process improvement, I started thinking.
My key question is becoming: we have great control/process frameworks around managing aspects between business and IT:
- ITIL for infrastructure
- ASL (mainly used in Holland) for application maintenance and management
- BISL (mainly used in Holland) for information management and business oriented IT "functioneel beheer"

All of these items create control/governance for some (IT)support or change part of the business operations.
But we see slowly a trend that business/IT control and alignment is reached by creating control over the following items:
- Business Processes
- Business Rules
- Information
- Functionality

At this stage we tend to approach this things separately (expect maybe from a EA/business architecture perspective, but these initiatives never want to be involved in "support" or other nitty gritty detail). The result if we would follow all the Gartner and Forrester reports, is that we end up with at least 4 different center of excellences, governance structures and the lot. This is a bit strange, since these 4 areas are typically very related, and impacted with a change. Which would result in a lot of collaboration and possible confusions (since language/concepts in each area differs....)

My dream would be that some type of business oriented ITIL process framework would be created, that helps companies manage these 4 items in an integrated way. And when a change is needed, the companie capability based on this framework (people, processes, roles, departments, products, etc) would enable organizations to quickly respond..

The "integrated business & IT change governance" services library or something.
One stop shopping for your changes in business process, rules, information and requirements/functionality from systems.
"IBIGSL"?

Police and protocols

2009-01-06T20:54:00.002+01:00

Recently, by accident I was listening to the radio when a quite good show was on. The program gave an insight in the workings of the police. The story was about the arrest of three criminals, and as the reports was "embedded", one could follow all the activities.
It turns out that during arrests, three teams are involved:
- the "AT" - the arrest team
- the "OT" - the observation team
- the "RT" - the research team

The observation team was simply responsible for providing observation on all relevent information on the criminal's behaviour: where were they, what were they doing, how many other people where there, what where the properties of the location (rooms, setup, access points, etc), possibility of weapons. They provided the arrestteam with a constant stream of updates of relevant information.

The researchteam would have its role after the arrest, carefully researching the premises (including cars, computers, etc) on signs (fingerprints, drugs, administration, etc).

The arrestteam had a large responsibility: to arrest the criminals, in such a way that minimal risk was created for the police, citizens and the criminals.
A number of people were interviewed, being asked to comment on the succes of specific arrestteams. Two key succesfactors that came up were "protocols" and "local intelligence".

A protocol is a set of specific steps, triggered when a specific situation needed to be created and solved. It turned out that AT's had about 3 key protocols: make an arrest in a house, stopping a moving car (and arrest the people inside it) and arrest someone on the street. And it turned out that these protocols were practiced many many times, to the point that people would automatically be able to perform them.
Local intelligence is the ability to succesfully improvise when during execution of a protocol, the circuimstances required this.

Hm, protocol and local intelligence?
It triggered the following thoughts:

We are talking about helping a (interchangable) group of people to deliver optimal results when faced with a certain triggering situation. That's what I would call a business process.
They recognized that the better these people were able to perform the protocol the less risks and the more success the groups had. We tend to forget this in BPM, or leave it to "change management".
They practice these protocols many many times. This is something in business processes is not done often. We might get a bit of training, read the process instructions or get training on the job. Not a bad idea: process practice training.

As a side though: I see many (BPM/IT))projects struggle for a related reason: lack of protocol and lack of protocol practice.....

3 for 1 - There are more processes in your scope

2008-12-07T11:24:00.003+01:00

When analyzing and implementing processes, I found out that we (ok, that includes me...) often focus too much on the core "content" process at hand. We dive into the main "named" processes that are in our scope, focus on the participants, activities, rules, etc. - model them, design improved processes and implement them. But due to this focus on "named content" we tend to forget that every process actually turns out to be three processes (and maybe even 3 more, more on this later).

If we only explore the main one, the other's are either implicitely covered, or completely forgotten, with all negative (change) consequences.
As an example: suppose our scope is "provide quote", in, say, a credit lending bank area. As analysts we dive into the process, find and model all activities - receive quote request, determine credit worthiness, calculate proposed interest rate, create quote, send quote, etc.
And if we are lucky, some analyst might even ask - what are KPI's or what is the management information that is required for the people steering this process? That person felt possibly intuitively that there are other processes floating around.
We might end up with a great "provide quote" process, and yet we might face issues around change management and reinforcement of improvements.

Let's get to the point:
The three processes that "hide in every process" in my opinion are:
- The "content process" - e.g. the main process, aimed at fullfilling the specific customer request, activities leading to the transformation of input to output
- The "operational management process" - the proces (usually plan-do-check-act) of making sure that the "content process" keeps performing.
- The "improve and (re)align process" - the process of "sharpening the saw", making sure that the content process (and operational management process) are improved, and when strategy changes of the company occur, that these processes are adapted to the new strategy .

Some thoughts...

1. As said, most of analyst's attention typically is spend on the "content process". That's ok, since in the end, if that does not run well, we end up with nothing. But let's not forget the other processes....

2. If we look at the operational management process, we might have analysts remembering that we need "management information". That's a step, but not the complete one. Steering requires a number of "process items":
- Who is steering?
- What process is followed for the steering?
- What possibilities are there for interventions ("act"), if process performance is not acceptable? According to what policies and rules?
- What information is required to steer (for planning, for checking), with what frequencies, in what form?
If we only focus on management information, we forget to focus on understanding and implementing the operational management process. Something I earlier wrote about in
"driving 50 MPH without a steer".

3. Interestly, whenever I start talking about operational management, process participants start to look "upward" to a management level. That's a choice, and usually determined by company culture.
My point is: many of the operational management activities you can also place at the process participants level. Many principles ("when is our process functioning fine, and in what situations should we act to correct issues) can better be done by the process participants themselves - they have the knowledge and see things happening. Instead of thinking "I should focus on the process and not the issue, my manager should fix this", we can make them responsible for steering as well. "When I see someone in my team having too much work, I will jump in and help", "When I see an error, I fix it, and make sure we don't make the same error again"...

4. You might object, and say "operational management" and possibly even more "improve and (re)align" should be part of a top-down scope in which we create a BPM framework for management. Sure, that's fine - if it's there. But in many situations that might take a long time. Don't wait for it - start bottom-up/middle out, learn and evaluate.

Conclusion: focus on content is fine, but don't forget to implement operational management and improve/(re)align.

As a PS:
I talked about possibly three more. These are:
- Your supplier and customer processes. What steps do they need to take to deliver and get their need fulfillled? If we forget to look at these processes, then we also miss out on possibly great opportunities for improvement in their and our own processes.
- Supporting processes. I remember working on an improvement project, where we just could not figure out why a certain process step (content level) was taking 2 - 3 days. When diving deeper, we found a supporting process (deliver physical mail) where moving a certain paper-folder took 2 days. Ah.

Gosh - OCEB Fundamentals certified

2008-11-10T16:36:00.004+01:00

41 and getting a diploma....

As a betatester, I got certified as OMG's OCEB Fundamentals Certified Expert in BPM. Tada...

I think it is a good enough certification program, which is aware of the many schools in BPM thinking. The more European/Dutch focus on Risk management ("AO/IC") is lacking a bit, but in the Business Intermediate this is covered better.

Not sure if I will do betatesting for the rest. For some reason, OMG seems to be really pushing the schedule. For the Fundamentals exam, I received the invitation on June 25th, and had to do the exam before july 25th. The results I received only recently. The Business Intermediate invitation I received on October 10th, with a deadline of November 14. And now the Technical Intermediate has a deadline of Dec 4th - 3 weeks after the deadline of Business Intermediate. While the amount of materials is growing and growing.

Hm.... BPM consultants are busy and have family lives... (or is that a European bias?)

But anyway, I seem to be the first Dutch OCEB certified... Or?

BPM & Change - Five steps to change

2008-09-07T00:35:00.004+02:00

Based on a number of projects where we needed to implement new processes, supported by new technology, I start to see a pattern emerge, that seems to work helping people and organisations reach the goals of a certain change program.
The pattern consists of four phases that people can go through, if supported by the right interventions.

Suppose we have defined a certain change requirement (which could be a full blueprint, that needs to be implemented top-down, or, preferably, there is rooom to work together with the involved people to define and implement the required change)....

Then I see five steps/phases to get to a succesful change:

1. Awareness
Our business life is an attention economy: a lot of stuff is happening, and we only have so much time and processing power. If you want to involve people that will be affected by a change, you will need to get above the radar. So with a good combination of receiving/sending the goal is to make people aware that something is coming, something that will effect them. SThe objective is to touch people in three levels:
1. their thinking (understanding what's coming),
2. their feeling(make sure they associate the coming change with A:positive feelings, based on various values, such as "interesting", "fun", "will create new opportunities", "growth" and B: safety: "my needs & concerns will be addressed", "I will be able to handle this change"
3. Their actions (I want to know more, provide input)
But this is not something you can control - people are (fortunately) autonomous, and will react in different ways. All this is vital information.

2. Understand and commit
Where the first phase is still open and has room for "we will see", this phase is about making people really understand what change is coming and how it will effect their workreality. Here usually a lot of energy is created, which can be positive, but can also lead to sharp resistance if not handled properly. With the right combination of listening, telling, and honest but committed communication from the higher management level, people will need to be made aware that their worksituation will be changed. And that their input is vital - but that choices will need to be made, some of which not that great. Assurance on clear decision procedures/criteria is important.

3. Prepare to perform
The last step for the actual change implementation is the building of competences, skills and self-confidence of the people. Here we train people, do proof of concepts, dry-runs etc. All to assure that we all understand the change in all details and that we are able to work in the new situation and deliver the right performance.

4. The real GO
This is the moment of course, that we have planned so carefully. It's a period full of last minute adaptions, issues and, if all goes well, a growing stream of real work, in line with the required change. It's alive and working!

5. Discipline
We tend to forget this, and often as a consultant we miss this phase, but it is important to address already during earlier phases: making sure the changed situation keeps performing (no fall back to old procedure). This deals with interventions on rewards, jobdescriptions. And with a feedback loop that actively uses the input of people to fine tune the process...

I wonder if other people recognize these phases, or see other important steps and activities! I welcome feedback!

Borders of BPM - Process management

2008-09-06T23:46:00.006+02:00

There is a saying (hope I translate it right): Where people draw borderlines, there will be border-conflicts. In this post, I want to address a definition issue around BPM, based on observations in some recent client work. It deals with (in my view) the difference between business process management and process management. Two areas where the borderline seems blurred. In some discussions I had, due to this blurred borderline, confusion started to grow.

Let's try to find the difference and border conflicts between these area's.

Process management: the area of activity to plan the execution of a process and to steer the execution of a process (through interventions on specific "instances"), to make sure the objectives are met and that process performance is conforming to certain requirements.
(We could also call this: Operations or Operational management).

The managed object here is the performance of the process. The activity is done within the boundaries of the current process, e.g. the process in itself is not changed. Steering will be interventions on people, and work in progress. E.g. analyse a specific client-issue, re-assign work, re-prioritize, fix issues, etc.

Business process management: the area of activity to manage processes as an asset, and manage the life cycle of these processes, aimed at structuredly improving the processes (in a continous cycle).

Here the managed object is the structure/design of the process (perhaps even the existance of the process!)- e.g. in the BPM area of activity, processes are changed, to adapt to sharpened performance goals and/or to structural changing circuimstances (as opposed to reacting to an specific exception - which would be process management).

Activities here range from setting up target improvement goals, analysing/designing processes that can meet these goals, implementating these (changed) processes and checking the structured performance of these processes, to analyse and check if further improvement steps are needed. Here, we act on different levels - we select processes, plan/prioritize processes to analyse/improve, and on a detailed level work with a specifiek process design and adapt it (change activities, business rules for decisions and assignments, etc).

Is process management BPM? Is BPM process management? Difficult, because recursion effects occur: if we implement a process in a company, where this process goal is to increase the performance of other processes, and we are managing this process, uhm, .....

But I do know that if a company has implemented a process, and from that moment on is managing the performance of the process (and not changing anything in the structure), it would be weird to say that they are doing full-swing BPM.... Because a lifecycle perspective and governance is missing.

For me one part of BPM will be to design and implement a process. Part of the process is of course also the processpart that will manage that process (who wants to implement a process without any goverance/control structure?). This means that implementing the process will also create the process management of that process.

Confused? Here is a diagram that tries to show my point: a Plan-Do-Check-Act cycle is implemented and performed (e.g. process management) when (as part of the BPM cycle) the process has been deployed and is being executed for a certain period of time.

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

2008-07-30T22:37:00.002+02:00

(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

2008-07-23T23:00:00.002+02:00

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

2008-06-18T22:05:00.002+02:00

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

2008-05-02T17:37:00.002+02:00

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

2008-04-27T20:20:00.003+02:00

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

2008-04-27T20:07:00.004+02:00

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)

2008-04-17T22:56:00.003+02:00

(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

2008-04-12T17:58:00.004+02:00

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

2008-04-12T17:39:00.004+02:00

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

2008-04-03T20:00:00.006+02:00

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

2008-04-01T21:55:00.004+02:00

[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

2008-03-14T20:11:00.002+01:00

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.

2008-03-11T20:04:00.004+01:00

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

2008-03-09T23:29:00.004+01:00

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

2008-03-09T22:33:00.005+01:00

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

2008-02-01T21:46:00.000+01:00

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

2007-12-08T10:58:00.000+01:00

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

2007-12-08T10:41:00.000+01:00

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

2007-11-07T21:42:00.000+01:00

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?

2007-11-07T21:32:00.000+01:00

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?

SOA & BPM? Beware - two-tier solutions might be back...

2007-10-26T23:01:00.000+02:00

Lately, I have been seeing a lot of wonderfull features of a BPM technology suite.
Point, click, ah, building applications is so easy. Point to existing web services, pull them in a BPMN flow, create Xforms that talk to web services, no pains!
Really?
Sure, it's easy to create the application, given the current requirements and services.
But what if a service change?

Suddenly I found myself back in early 90's, with 2 tier client server tooling. Oh, what a delight after the green screen software. Widgets, windows, and click click link it to a database table, an SQL query, and tada, the software worked!
Until a requirement changed, we needed to make a small change to the database, and realized 40% of our windows would not work and needed fixing (even though their functionality did not change...).

It's called coupling....

I am assuming that many of these BPM tools have this risk: the risk that we build BPMN and presentation layer stuff, directly connecting to services. Leading to heavy coupling.

The alternative is supported by most tools too, I hope: an intermediate layer, that shields presentation to back-end services. Call it controller or business objects or whatever -
but please use it...

Towards a new TLA: ITPM

2007-10-26T00:50:00.000+02:00

Short post, it's late :-)

Interesting article at BPM enterprise about BPM for software development
(link: http://www.bpmenterprise.com/content/c071022a.asp)

What's missing is a key metric: the likelyhood/trackrecord that we deliver on scheduled date.

It's funny - all the effort in various software development methodologies.
In a way it's all (new TLA:) ITPM. IT Process management....

As a BA/BPM specialist, and 15 years of IT development/projectmanagement experience, it often happens that when starting on a new or running project, 20 - 40% of my time is actually spent on process improvement... in the project. E.g. implementing, structuring, refining and improving requirement management process, issue management, testing approach etc. :-).

Is your job also often ITPM?

Towards a new requirements framework

2007-10-15T22:05:00.000+02:00

James triggered me again, around Requirements in a BPM context. See http://www.ebizq.net/blogs/decision_management/2007/10/whats_the_difference_between_r.php
I notice in discussions with clients that there is a great deal of confusion about the notion of requirements. I get quite careful when clients start asking "are the requirements done?", "do we have clear requirements"?
Same with terms as "Software requirements" "Specifications" "Business Requirements". When I ask a bit further, the definition, content and context of these terms differ per person, even in the same organisation. If Standish sees 'Clear Requirements" as one of the top-3 CSF's for projects, then it would be quite nice if we all know what we mean by that. How I love clear concepts :-).

Working with a client recently, we discovered together that their change processes were, well, somewhat messy. As change as a process is clearly an element in your BPM strategy: e.g you want to have control over this process as well!, we researched the painpoints in more detail.

One central thema - you guessed it - no shared language around the concept of requirements.

If we don't share the same language on the meta-concepts and the quality criteria around requirements, how would we even start to hope that we understand the requirements in itself?

What we came up with was a high level Requirements Framework, which defines requirement area's. The following diagram is useful:

It defines a framework of types/areas of requirements.

The area's:

1. Business Requirements. As in: requirements you put upon your business.

Strategic Goals & Drivers

These are statements about the intent and plans of the organization. 'Be number 1 in market XYZ, region ABC". "We sell to <target audience> through channels X, Y and Z". "We want to have an operating income of at least XXXX".

Product requirements

All the properties of your products (or services). And the rules of engagement - when are you willing to sell a product? What terms and conditions?

Information requirements

What information do you need when performing your processes? Per process? Per activity? What information do you produce?

How is this information structured? What rules apply (correctness, etc)?

What information is needed to steer your organisation and it's processes?

What information is needed from external stakeholders?

Process requirements

What processes do you need to exist? To serve your customers, deal with suppliers, produce products, steer processes and change processes? What supporting processes?

Which steps in a process? Inputs, outputs, link to goals, etc.

Organisation requirements?

How do you want the organisation to be structured? Which roles? Which authorities? What skill levels?

How many people?

2. Software requirements. As in: requirements you put upon your IT systems?

Functional requirements

WHAT does the application need to be able to do.

Non-functional requirements

Think URPS. Number of users to support, performance, etc.

Architecture requirements

Often put in the same area as non-functionals, but in fact very different. These are requirements from another stakeholder group, and need another area: what (mostly longterm) structures, practices, and technology standards do you require the application to comply with.

A number of notes:

- Each area has it's own value and it's own techniques & best practices to understand, formulate and document the requirements in the area.

- Areas are interrelated. Actually, most interesting requirements you will find on the borders: when performing process A to sell product B with information do we need when in step C. When performing process B, what functionality is required from the IT system?

- In each area you will find hierarchy in terms of detail. In process, for instance, a high level services overview, then drill down in process architecture, process activity flows, etc.

- Functional Requirements is the area that gets most attention. Typical techniques to document requirements in this area are "System Should .....", use cases, business rules documents, etc.

- Note that business rules are types of requirements you will find in more area's. In information: an customer can order multiple products in one order... In process: if insured amount > XYZ manual approval by role ABC is needed. Etc.

- You could call this complete framework "business architecture". I am always a bit carefull with "architecture", since that's an even vaguer concept. My objectives are to have a framework that evryone in a company can understand (and not some ivory tower group).

- The pyramid is also a great tool for knowledge management. If you work somewhere, these are the area's you should understand, to know your own role and added value!

Observation:

I think that methodologies that play a part in changing a business, including software development life cycle methods such as RUP, SDM, etc. should be innovated to methods that understand that requirements can be defined on multiple levels (e.g. system - as in organization and in software system) and that are able to integrate into these broader frameworks. This to prevent the earlier blogged about "task oriented applications" (see http://process-transformation.blogspot.com/2007/10/need-for-new-requirements-approach-and.html).

Requirements vs Process and Rules

2007-10-13T00:54:00.001+02:00

James Taylor reacted to a posting about the importance of good Requirements. He sees process as something else than requirements. And he advocates a clear seperation of the concept of Rule and Requirement.
See http://www.ebizq.net/blogs/decision_management/2007/10/requirements_business_process.php

First on the process part vs requirements.
I see a process as a specific concept in requirements. It can be requirements towards a business:
- This is the way I want our people to perform this process (a business requirement)
Or it can form part of the requirements to a system (a software requirement)
- This is the process I want the system to follow when processing claims.
Or a mix of course.
So, is a process definition a software requirement? Sometimes.

Then the part of the rules: again, i don't fully agree.

First of all - YES. When we are trying to understand how an AS-IS situation is working or a TO-BE situation should be working, we can use various concepts in analysis. What processes do you have? What information flow, inputs, output? What do you do in an activity? And, what rules apply for decisions - why do you refuse this order, how do you calculate that price, why do you decide to escalate this?
Rules analysis are a great tool for understanding. And during requirements analysis, I typically seperate them out of the other requirements, simply because it's a separate set of things/concepts.
But are rules requirements or not? I think rules are, for a start, always a business requirement: "when we are doing business, I want our people to follow this rule".
And, in my opinion, when a rule will get automated, we will need a requirement defining the rule. The rule becomes a software requirement: we want to IT system to perform CHECK XYZ, and based on the results do A or B or C.

Now - before I continue, my requirement constraint: a requirement is part of the WHAT definition of a desired system, and does not define the solution.

I have the suspicion that people are separating rules out of the requirements, because they have the solution already in the back of their minds: a rules engine or BRMS.
This links back to my earlier posting on "pick the right technology for your functionality".
Rules can be put in a BRMS. Or programmed in Java. Or in Cobol. Or asked to a user (continue Y/N?). It depends on the requirements...mainly the non-functional ones.

Are the requirements that define this rules highly violatile? Or should they be maintainable by non-programmers? Well, don't put them deeeeep in code in that case.
Are rules quite fixed? Do you only have Java programmers and no money for a BRMS? Does the business delegate all IT rule keeping to the IT people? Go ahead, bury them in code (but do make sure you defined them as a seperate part in your requirements, and make them traceabile in your code...!)

/**=== Check business Rule XYZ , traceability: BR23.22 =======
if (bla.blo(var1, var2, var3)
{.....}
else
{....}

/** end check BR23.22

Conclusion: each technology has it's business case. BPMS and BRMS as well.

The right technology for the right functionality

2007-10-13T00:36:00.000+02:00

A number of posts reminded me about a discussion I had some years ago.

Situation: we were introducing advanced output management technology (e.g. a tool + programming language to create applications that were able to receive XML and generate output (PDF's, prints, etc)).
This technology had a number of advantages:
- Quicker time to market
- Powerfull language
- Easier testing (what you see is what you get programming environment)
- More possibilities in layout

The objective was to reduce the code base in the legacy area considerably. In those huge Cobol programs, many were programmed to generate output (line print, so very '70-ies output). Of course, whenever output needed to change - a new product, new rules, a new contract, quote, etc, Cobol programmers would need to start hacking. They did that for years and saw no issue with that. But the business did - waiting for 2 - 3 months of implementation time, a lot of testing, and that 70-ies layout.
The Cobol group had a lot of resistance towards the new technology. One argument was: well, now we can programm the WHOLE application in one language, but with this technology, we will need multiple skills in multiple languages.
Yep. And I explained that we don't use a hammer to crush coffeebeans to make coffee. We use a grinder. And the hammer we use for nails.

The lesson: when requirements ask for a certain solution, pick the right technology for it.

The same discussion I recognize in a number of postings on BPM (Why Java developers hate BPM tools):
http://weblogs.java.net/blog/johnreynolds/archive/2007/10/why_do_java_dev_1.html
http://www.oreillynet.com/onjava/blog/2007/10/do_i_hate_bpm_no_i_hate_bpm_pr.html?CMP=OTC-FP2116136014&ATT=Do+I+hate+BPM+No+I+hate+BPM+Products

The key question is again: what are the requirements, and what is the best technology to solve something. I am sure most BPM featurs you can easily develop in Java. Hell - you can develop a database with Java, but big chance is you don't....

The key advantages with using BPM technology:
- You can change a process quickly
- The process diagram reads (most of the time) quicker than 10 pages of a programming languages, heck - maybe some people on the business side even understand!
- The whole SOA calling is hidden - it helps you to focus on the process and information flow instead of Java and XML
- Process and activities are measured for you, in a standard way.

Case management - The empowered information worker...

2007-10-13T00:08:00.000+02:00

Recently I was at the Cordys Cordial (http://www.cordys.com/) day, a day were they presented the new version of their platform.

A funny statement by (I think John Pyke) was: processes are created when something failed. :-) - now, that's a nice start of BPM... And John also nagged towards SAP, which as an abbreviation would stand for Stone Age Processing or Spent All Profit. Hm.

A good presentation was on the new case management features of the Cordys platform.
These features were added to the platform when they discovered (while doing a project with my company) that certain processes are not that straight forward as hoped for. Aka - forget modelling it in BPMN, the diagram would be too complex and add no value. I sometimes wonder how many processes actually are really that structured, but that's another post...

A small summary on the case management features and thoughts behind Cordys:
- Where in production workflow, each process instance has a certain flow, each case will have a unique sequence of activities
- When a case is started (based on some event), certain activities are automatically opened, based on the type of the case and certain event criteria.
- A user is presented with activities, can open them (role bases), execute them, delegate them or create new activities (select or freely define).
- Status of cases and activities can be tracked, measured (monitoring)
- Three main components were presented:
+ Document matching - used to trigger creation of a case, or to be able to link an incoming document to a running case. Remark: strange - I would not have called this a document matching system. Incoming documents (and other information flows) basically define EVENTS. So - it's a CEP or Event Correlation Engine....
+ Case management - the actual presentation towards the user of all case activities, history, data, etc.
+ activity management - the ability to execute, define, delegate, etc activities.
- Another component is the maintenance area - in which case rules and activities can be defined, including roles etc.

They had a nice slide which defined a sliding scale between pure workflow and pure case management.
- 100% production workflow
- production workflow with small cases
- Flow + case
- Case management, with small flows
- Pure case management
I liked it a lot - since I do think you will encounter many processes where things are mixed. For instance a straight through processing unit, which asks for case management when exceptions occur.

Some remarks:
- Unfortunately, the "activities" are NOT integrated in the current BPM engine. E.g. when I create flows in the BPM engine, I can not mark them as optional or mandatory sets of activities in the case management component. Ideally, in the case environment, as a user (or automatic triggers by certain rules) I want to be able to pick: a listed activity, a free activity, a process fragment or a transaction. This also meant that in the current Cordys setup - the BPM inbox and the case management module are not integrated. Ouch!
- Cordys talked a lot about "the ability to measure status of all cases, allowing you to manage the workforce". Well - since Case flow can not be predicted, in my opinion, workforce management will be difficult. Sure I can see what activities are open NOW, but I have no clarity on the expected activities for these cases, and the required resources...
- What I see as a challenge is case data. When you are doing production workflow, most process instance data that you will need, is clear on design time. Each activity and decision needs certain data - and you will need to make sure it's available in the process instance. But what if you are working with cases, where you do not exactly know what information is needed to supply the knowledge worker with enough information to decide on activities and case closure.
- Another item is where to store this data? In the Cordys solution, all data is stored in unstructured documents. But what to do with all data that is stored in backend systems, which users maybe need to decide? Store in the case management system, or call/get every time the case is opened and viewed?

The demo showed a nice presentation layer which showed the case in full context. It allowed a user to understand the trigger, all done activities, notes, etc. A true process workbench.
The main lesson I started realizing, seeing the demo, was that whatever the type of process support a knowledge worker gets with his or her BPM application - the best would be to provide him or her with this full context. Don't make the mistake of underestimating your users and only give them the microscopic task view (aka inbox with single task - do this, no questions asked), without a clue about the full process!
Empowerment and process ownership are things that should be the basis for process workers..

BPM technology consolidation...

2007-10-12T18:06:00.000+02:00

Another one bites the dust...
http://www.ebizq.net/news/8554.html

Oracle to buy BEA.

Hm, interesting. Definitely a step towards further consilidation.
How many process engines will Oracle have now???

The need for a new requirements approach - and BPM's role

2007-10-09T23:42:00.000+02:00

Ok, it has happened again. Fortunately, it doesn't happen often, but from time to time, I find myself in the unlucky projectworld of "Type 2" , described by the Standish Chaos research as "Over time, Over budget and Less Functionality". Ouch.

Remember the Standish Chaos Report? Also see for instance http://www.projectsmart.co.uk/docs/chaos-report.pdf

It lists succesrates for projects, based on research. And it lists succes and failure factors.
It's findings (So, I am part of the majority with my project :-):
- 16.2% of all projects are Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified.
- 52.7% - Resolution Type 2, or project challenged: The project is completed and operational but
over-budget, over the time estimate, and offers fewer features and functions than
originally specified.
- 31.1% - Resolution Type 3, or project impaired: The project is cancelled at some point during the development cycle.

The failure factors for projects ending up as a 2 or 3:

The survey participants were also asked about the factors that cause projects to be challenged.
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%

And yes - in this project, for all kinds of reaons, these items are true.

It wasn't me, though, I was not working on the requirement side ;-). But a repeating lesson I learned: good requirements are essential. And in my opinion that needs process-context awareness.

Remember the old days of applicatie analysis and design? I call it feature oriented requirements engineering: talk to users, find out what's difficult in their job, and think up a set of features to cover their issues.
Example: we do sales, but miss information on our clients and status of orders.
Ah! We prototype a nice screen, build you a nice database with clients, and the order status we get through EAI from your order entry system. Problem solved!
Really? No.
You end up with a so-called data & isolated task oriented application. It's not aware of the process.
To be honest, as IT requirements person, I used to like this. Process was difficult, all those exceptions, terminology, discussions, yucky. Features where clear - a screen here, a database there, a business rule there, data and task oriented.

But in these days of evry growing complexity, task and data oriented requirements analysis will not do anymore. Why? Because it leads to suboptimal solutions, which force people to work AROUND an application, to perform the process. (And ask a random user how many systems he or she typically needs to use to execute a front to back process - usually a lot...)

Premises: EVERY application we use, we use in the context of a certain process. So, by carefully analysing the process, we can get to better requirements, more project succes (standish) and much better solutions.

There is a problem though. Most of the current Requirements frameworks are still in the Data/Task oriented mode. Think of...
- Feature driven development
- XP's User stories
- RUP's Use cases
All these items are focused on isolated functionality, that brings value to a user, in a logical transaction. Process is much more than that! So, how do we capture this.
Sure, some methods call for "business modelling", but most of these elements are, to say the least, not very developed.

BPM would be a great vehicle to improve this.
It asks us from an analysis perspective to:
- SCOPE: Define the scope for a to-be process area and supporting IT solution
- GET CONTEXT: Analyse the processes, front to back, including trigger, input, output, steps, information required in a step, data produced in a step, data flow, actors, KPI's, etc
- DEFINE HIGH LEVEL REQUIREMENTS And then dive deeper: per step, we can start thinking about the required IT support.

From this step, we can revert back to for instance use cases - to define the functionality a user needs to complete a logical process step. (So: a use case is not the same thing as a business process!)

My lesson: BPM is there for many reasons. And one of them is to help you improve your understanding of the business context and get to better requirements. Add it to the more IT driven methods, and you have a better chance of getting to project success.

2007-09-28T19:05:00.000+02:00

Came across the new BPM institute magazine, http://www.bpminstitute.org/magazine.html, and found the following diagram:

Some observations:

It's first of all a nice overview of the improvement frameworks existing today!
For some reason I always get a bit tired of the arrogant tone of voice of the Omega-6 and CEM/CEMM supplier (now Bennugroup). Well, I guess the above diagram tells enough - no trace....
I am glad to see Lean high on the list. In my opinion a great framework.
It would be nice to see this broken down by industry - for some reasons, in Finance, Lean is only slowly cathing on.
It would be nice to see this broken down by "reason/goals for improvement". My suspicion is that we can link goals and methods still quite a bit (visibility - balanced score card, EFQM - Quality, ISO - Compliance, etc)

From organisation chart to process chart

2007-09-22T17:01:00.001+02:00

When business analysts come into a new business, they need to quickly understand the structure, people, products and processes in the company.

One of the key things I usually ask for is the organizational chart (aka organigram, organogram).
As a side note: it's amazing how often I either get incomplete or outdated diagrams. I wonder in that case how the heck people in their own organization understand the structure, and can place themselves + link themselves to the goals of the organization. So much for knowledge management, in such a simple form!

In these process-orientation days, I have found organization charts more and more disfunctional. What do you get?

- Powerstructure/reportingstructure
- Functional area's and departments (but often functional departments support multiple processes, and only parts of it)
- Names of people

The thing is - the basic question: "What does this company do" is not easy to answer. For a process-oriented person (like me :-)), that is often difficult - I want to see the chain of actions that lead to results for customers, and their interrelation + the people responsible for the different elements in the chain. Stuff that not easily can extracted from the organization chart.

So - can we come up with a new standard? The processchart, procesogram? Some high-level, I understand this in 1 minute, easy to draw and maintain diagram?

That quickly answers:
- External stakeholders
- Key transactions
- Chains of actions/process areas that support and fullfill transactions
- Key people responsible for parts in the chain, chain accountability

I challenge the reader - do you know something like this??

Some of my thoughts:
- The dutch "Demo" method (http://www.demo.nl/) offers a very concise diagram (organisation construction diagram) - however, this misses the accountability structure.
- In the method of Cordys - there is a business model

Curious if other people have a better diagram technique!

Five areas you need in your process architecture

2007-09-22T15:26:00.000+02:00

Whether you are trying to understand processes enterprise wide, or just for a small department, in my opinion, there are always five process areas that you should consider.

Here in diagram:

1. Operational Processes

Processes in this area are considered core to the organization''s goals. They make up the business model of the company and focus on making customers happy, by procuring, producing, selling, marketing and servicing products/services. The value chain of your company.

2. Supporting Processes

Although not core, these processes facilitate all the other process areas and are often of crucial importance. Think Admin, HR, IT support, Finance, Legal, QC/QA.

3. Supplier and Customer processes

From an outside-in perspective, it is very important to understand (and help improve!) the processes of your main outside stakeholders: your suppliers and customers. By understanding their processes, you are able to help improve them, which in the end, will lead to competitive advantage. Model these processes from a supply chain perspective - optimize the chain in total.

4. Management processes

These processes steer the other processes (and cover the plan, check and act of the Demming cycle). They form the process control layer in your business.

5. Change processes
Yes, change is a process to. In modern days, change will occur more and more often. A repeatable framework for change, aka a process, will help you to become more agile: when a change is needed, all people will know their role and responsibility, to enable the business to respond fast. The change process includes detecting the need for change, understanding it, designing it, and implementing it, including all impact on the people and technology in all layers.

The 5 competence-areas for real process transformation

2007-09-22T14:42:00.001+02:00

I often use this model to explain but also check if a company is well positioned to achieve succesful process transformations - the 5 competence areas:

Process orientation
BPM technology
Change management
Process improvement
Subject matter expertise

1. Process orientation

This competence area is what I would call the typical "BPM as a discipline". It asks for people, supported by methods and techniques to see the processes that are embedded in the organization, see the interrelation between them and the alignment with the busines goals, and see opportunities and risks in the as-is process situation. It asks for people that understand how interventions in process, people and technology can help the company to perform better. Concepts, methods and tools that people should be able to understand/use are for instance:

Business model - linking goals, business services and processes
Business architecture
Process architecture
Business case - TCO of processes, sourcing
Process models for operational processes, supplier/client linked processes (supply chain understanding), management processes, supporting processes and change processes
Information architecture - what information concepts are used, and in which step in what process is what information needed to perform the step and what information is delivered
Performane measurement and process control models - what to measure when (based on CSF's and KPI's) for whom and to control what risk - and the possible steering that management can do when measures ask for action
Business rules - what rules and knowledge drives what decisions in the processes
Methods for analysis of processes, and problems-cause analysis and knowledge

2. BPM Technology

IT offers many powerful innovation possibilities. But, people are needed, with the ability to see the possibilities and potential benefits. This requires competences in the technology, including:

Business process analysis technology, to support people to model / visualize processes
BPM Suites - automated process coordination engines
BAM - process intelligence
WFM - Workflow management, often as part of the BPM suite, offering functionality to support people performing tasks in the context of a process
Case management - again, functionality to support people performing tasks in processes, where the processes are more difficult to predict and model, and part of the process execution is based on people knowledge and decisions at run-time
SOA - a way to architect automated processes, based on calling services
ESB / EAI - Enterprise Service bus (or SOA grids) and other ways to deliver functionality and data needed to perform processes or tasks in a process
STP - Straight through processing, where the process is coordinated and executed in a totally automated environment with no or very limited (exception handling, sample checks) human involvement
BRE - Business rules engines (or in EDM terms: platforms for Decision Services)

Important to note it that people are needed that can think outside the "tool". E.g. we do need people that understand specific vendor technology (BEA, IBM, ARIS, Oracle, Cordys, etc), but we also need people that see beyond the limitations and design patterns of these tools, and understand the bigger "process model, execute, measure, improve" needs and features of your business.

3. Change management

Process transformation is a change. And change, asking people and their supporting systems to change, can be hard. It's an area often forgotten - many BPM projects are, unfortunately, run either from a technology perspective or an architecture/blue print perspectice. Change is not following a design-implement paradigma, and asks for people oriented interventions - two-way communication, training, coaching, steering, etc. It asks for people with competence in:

Change management
People management, development of people
Project management
Requirements management (as-is, to-be)
Design, simulate, evaluate, test, learn

4. Process improvement

I am very happy that process improvement is slowing turning into a art and science on it's own. In fact, improvement can come in a number of impact/scope combinations:

BPI - Business process improvement : small changes within the current processes, e.g. removing or reshuffling tasks, tuning business rules and tuning work/workforce-assignments
BPT - Business process transformations: medium to large changes, were processes are analyzed and thoroughly adjusted, including BPM/Case management/STP automation
BPR - Full scale process redesign, with often a total new look at product-market-channels orientation.

Beware - do not let a simple business analist or architect design process improvements - it will lead to nothing. Process improvement asks for people with skills in:

Outside in thinking
Measurement & benchmarking, statistical process control
Lean
Six-Sigma
TOC
Operations Research and modern Logistical concepts (JIT, Kaizen, Flow, Pull, Agility)
Simulation

5. Subject Matter

Whenever you start a process transformation programme, make sure you involve the subject matters. The people you need, are people with extensive knowledge of

Your company's internal structure, network, power grid and culture
Your current process portfolio
Your products
Your customers
Your suppliers
Your legal and compliance environment

I hope this list can help you, as a checklist. Try to make sure you covers these skill area's. Whatever you miss - will mean risk to your transformation project. Risk is okay, as long as you are aware of it.

Being goal and result oriented

2007-09-22T14:34:00.001+02:00

Today I saw an add, with a sentence that lingered for a while:
"Innovation is an illusion, until you actually do something about it".

I remember, while studying, that I read the excellent book by Goldratt, "The Goal", about the Theory of Constraints. The thing that stuck was actually a more basic concept: whatever you do, be aware how it relates to your overal goal. Something that in modern management sometimes is called Alignment.

I have been involved with many projects and transformations, and I have always tried this. When I was still more involved into IT/software development, my motto was: "In the end, it's about working software for a happy business".
To my surprise in many situations, I had to fight for this motto. The countless meetings, email conversations and phone conferences where people forgot what we were really striving for, it is amazing.

So, ask yourself: what is it that you REALLY try to achieve. What's your goal?
Are you in IT development? Working software, for a happy business!
Are you in IT support? Working software and empowered users, for a happy business
Are you in process improvement? Better processes!
Are you in change? Real change!

All the rest, the blabla, the politics, the countless reports, the discussions, sure - they are often needed. But they are not the goal. So make sure - know your goal, and, whatever you do, ask yourself - is it helping us forward to our goals?

What's you goal? And what are you doing? Aligned?

A personal transformation

2007-09-22T14:32:00.000+02:00

It's been a while since I blogged, but that has to do with a large personal transformation. One that will definitely impact all my personal processes :-)

September 16th our first child Hannah Rosa was born. Mother and daughter are doing fine!

The challenge of being a BPM specialist

2007-09-05T15:02:00.000+02:00

As a "process therapist" I encounter many processes in trouble.

The most difficult one is the "But we have always done it like this" or "still in the dark" processes.
The trouble with this is to make people understand that there is a whole new world out there, which will soon replace your business, because customers will simply switch. A world of new practices, new technology, and new demands.

I often encounter these processes in organizations with an almost monopolistic nature, where customers are almost forced to accept the service, simply because of the trouble to switch.
Think - utilities companies - water, electricity, national phone company, internet provider, mobile phone company with the 1 year subscription lock-in, your pension provider, the law, mortgage handler, insurance company, car repair dealer.
Sometimes arrogant, mostly naive. "We have always done it like this".

E.g. it's normal that....
- Customers need to wait weeks, sometimes months on requests
- Things get lost, and are found again
- No insight in metrics such as progress, workload, speed
- If customers call, they need to call back later, because it takes a lot of time to findout the current status (and we can't call them)
- Decisions are taken, but no one knows or tracks why, or even evaluates the business case behind the decision
- Processes and channels are there for the company's efficiency, not for the customer "openinghours: 9:00 - 17:00, closed in the weekend", "no, we can not react to email" "please press XYZ, for ..... The waiting time is YY. This call will cost you XX per minute. There are 40 people before you in queue" "yes, you will need to fill out this form, even though we have all your data already"

We all know these types of companies, and those poor processes in there. And the even more poor customers having to deal with this.
I'm often amazed - how can the people working there, have become used to this, and think it's "normal". The boiling frog metaphore comes to mind... (cook them slowly and they won't notice and get used....until it's too late)

What to do? Can BPM be an answer? The answer is a complex and yet simple one:
Yes, but you need leadership from local managers that understand that they have a growing issue and have the courage and committment to really do something about it.

Without this, forget it.

So if, as a BPM specialist, you encounter the "we have always done it like this" type of process, find the leadership, grow it, test it, and let go if it's not there...There are always other companies that do understand the need for process improvement, and your BPM expertise is very welcome there!

SIG Pam articles - open

2007-09-01T13:49:00.000+02:00

I came accross this site through Sandy (column2.com).

A recent entree with some great research articles, freely published:
http://www.sigpam.org/2007/08/31/papers-presented-at-the-amcis-2007-minitrack-on-business-process-automation-and-management/

Package Vendors: Free your functionality, free your processes

2007-08-30T09:57:00.000+02:00

ebizq published a good whitepaper (
http://www.ebizq.net/to/BIANWP082907W, direct link to http://www.ebizq.net/views/download_raw?metadata_id=8345&what=white_paper) written by Tom Dwyer.

It's key points conform to my point of view, which, in a nutshell, is "free your functionality, free your processes".

Sadly, Tom's view at this point only advice package vendors to select a BPM vendor and implement it's technology, and not look further for an open standard solution for process technology.

Back to basics.

In many current software packages (COTS) that you buy, you will get great functionality and in some cases even automated process support (in the form of workflow and possible straight through processing capability).

We have come a long way from packages which stored their data in closed proprietary persistence layers. Now, many vendors agree with the adagium "Set your data free!". Many vendors have taken the step to become database neutral - e.g. you can stick any major database brand underneath these packages - Oracle, SQLserver, DB2 to MySql, etc. Great news for technology consilidation - vendors finally started to understand that customers did not like to keep thousands of databases running, based on many different database technologies (why? think high cost of licenses, knowledge of staff, lack of centralized monitoring, difficulties interfacing between databases, etc).
The next step they have started is publishing their data store structure or (better) have implemented decoupled logical views, so that we can access data in the application, directly through database calls or predefined API's. A good step but not enough...

The next step should be that vendors set their functionality and processes free.

:-) I can also see those nice pieces of functionality, and processes, sitting there, in their jails of closed code. Very sad indeed.

So free them? How? Like this...

Functionality not locked up, only to be used from user interfaces or very limited API's, but free, in the form of services. We can see a number of vendors that have been doing this, or are working hard on it now. It's basically opening up the business logic (and data) in the form of services, the SOA-fication of your functionality stack.

And the same for processes. First from a implementation perspective: What I mean is being able to put in ANY (standard) BPM engine. Away from proprietary process technology, towards standard BPEL engines, from for instance IBM, BEA, Appian, etc.

Again the business case is clear here: one BPM technology. In addition, the process technology many package vendors are offering, is very limited. No process modelling, but XML script hacking. No freely defined BAM functionality, but only what they provide.

Second is from a logical perspective: either being able to startup a process through a standard interface, or being able to simple reuse the process definition from the package, but place it as part of the total process. I still have thinking to do here, because how much influence do I want to give to a package, to determine part of my process view?

Where we want to go to, is this: if packages only support parts in the end-to-end processes in our companies, we do not want to interface. We want to create the overall process, and link it to services in all the apps we need for that process.

In the following diagram I show a typical example, that you will often encounter:

(click to enlarge)

From a IT perspective, this leads to:
extra technology, extra maintenance burden.

From a business perspective, if we look at this process from a LEAN point of view (http://www.lean.org/), we see there is waste:
- Extra tasks, that do not add value (starting B, nightly batch, rekey activity)
- Time waste, waiting a night before we can continue to serve this customer

What we want is shown in the following diagram:

A key question that is hidden in Tom's article is this:
Can you, as a package vendor, still offer packages that:
- Are only task based (e.g. no process awareness)?
- Offer limited proprietary process technology?
- Which therefore result in difficult integration and suboptimal business and IT solutions?

I think not...

Sure, one last statement - we are not there yet. A recent IDC study also showed that BPM engines are mainly implemented on a project basis, not from an infrastructural basis. This worries me, because we will end up as customers with many many BPM pockets of technology, each requiring licences, knowledge to support, etc. A great role for Enterprise Architecture to help prevent this.... with some help from package vendors that is...

Additional thoughts on BPM architecture

2007-08-28T21:38:00.000+02:00

James Taylor from EDM blog (http://www.edmblog.com/weblog/2007/08/process-transfo.html) and Phil Ayres of Improving NAO posted a reaction Improving New Account Opening: Component stack - a simplified architecture for applications - Solving complex business problems with financial services technology to my earlier post on an architecture around BPM.

A number of thoughts:

First on "liked his architecture except that I think the Decision Platform he identifies also needs to be able to support both the CEP and BAM components. After all, determining which process to trigger, which action to take or when to inform someone may be a non-trivial business decision and so require decision management. I also think that a decision platform needs both rules and predictive analytics, as you might expect, and that it needs to be available to all the various components that might need decisions (typically implemented through decision services perhaps as a decision service hub as Neil and I discussed in Smart (Enough) Systems). "

Yes - I agree on the coupling between CEP and Decision platform. Good point - knowing what to correlate when, and what process needs to be (re)started could be a complex task. I can see scenario's where for instance correlated events might (or might not) start up a fraud research process.
It's actually interesting to see that many BPM platforms currently have no to only limited inter-process synchronisation. This could also be a great area where the CEP & decision services could help out. For instance: deciding that a certain running process should wait, until a new event is handled by a new separate process. Think of for instance updating a customers address, while at the same time doing a claim process. You don't want to end up sending stuff to the old address (that just burned down!).

On the link between CEP and BAM I am still a bit puzzled. Possible one could see certain BAM data, that points to a certain event, which needs a decision? Not sure. And maybe only usefull in quite advanced BPM maturity environments (which, unfortunately also is true for the notion of CEP and Decision Services - I am not seeing them yet in client implementations - which will in the future lead to additional maintenance...)

For me a decision platform definitely contains BRM technology. What I am still thinking of is - what if a certain decision "service" actually needs some human knowledge? Does it mean that from the presentation layer we will get some possibility of opening a "decision to-be-taken inbox"? Or will decision services actually lead to a normal task (decide on XYZ and let the process know?".

Another thing I am still wondering is the balance between putting decision logic in components, or centralizing it all in a decision services hub. Sure, centralizing it sounds like a estethic architecture thing to do. But the amount of overhead is large. For every IF statement, a component would have to go centrally. And why? So that we can maintain it easier? A trade-off is needed.
A presentation I saw from the Business Rules Platform in the Netherlands talked about this as well. They proposed a mixed model where a decision service hub/business rules hub could either:
- Work as a central service
- Distribute the logic towards the components.
- Do both, but synchronize the logic
Interesting to see which model will emerge.

Phil proposed "James suggests some enhancements to the architecture, largely to ensure that the Decision Platform can interact with the Complex Event Processing (CEP) and Business Activity Monitoring (BAM) components. I agree with his rationale, and would even take it a step further - every component in an architecture (that isn't pure technology) should be able to interact with every other, ensuring that really advanced business requirements can be considered, offering more and more business value."

Hm. Not sure that I agree. Sure, interoperatability is a great thing. And yes, in my picture, although not shown, most components will be able to contact other services.
However, what we should not forget is, again, the notion of coupling. Providing a integration platform does allow for flexible communication between components, or call it services. However, this does not take away the notion of coupling. When I, as a service A, am using service B, I do know about it! I have knowledge of the provided functionality and data, so that I can use it and add value to it, for a certain requirement. Knowing about it is nice, because then I can make use of it. But it also leads to dependencies - changing B will need carefull consideration.
The more connections, the more "services governance" you need.
In advance one cannot predict the business requirements, so true: you would want an architecture that supports easy connectivity. But the objective of my architecture drawing was also maintainability and manageability. Based on an (okay, not disclosed :-) set of requirements, you would want to find the architecture coupling that is on one hand supporting the requirements and provide flexibility towards change cases, but on the other hand limits the coupling/knowledge. I wanted to create an architecture where most components know eachother on a lean, need-to-know basis.

Gentlemen, thanks for your feedback and reactions welcome!
Regards,
Roeland

BPM Suite as a component in a logical architecture

2007-08-26T22:44:00.000+02:00

In a number of assignments in the past, I was involved in defining a high level logical component architecture for organizations handling administrative processes. My thinking around this continuously develops (learning from mistakes ;-), so I decided to take a snapshot.
I am always interested in additional views....and still puzzling with roles of each component (for instance: who will have the knowledge to show a certain taskscreen, interfacing with the core admin platform, based on a certain task from a certain process? And what will trigger the output management platform - an event or a service call from the BPM engine)

Here is a diagram of the logical architecture:
Three notes:
- Components are rectangulars
- Arrows are showing dependence (e.g. knowledge of), not information flow.
- All arrows would use the integration component (call it ESB or SOA grid or message broker, or someone picking up the phone...)

A breakdown, by component:

Input management - component (consisting of people, technology, processes) responsible for receiving messages from outside the scope of this system: external parties, such as clients, other service providers etc. This would be multi-channel, e.g. able to serve incoming documents by regular mail, phone, email, internet, etc.

CEP - Complex Event Processing platform - component that is able to detect and interprete an incoming message (or other internal event), and, using business rules, translate it to an action. Most times this either means triggering a BPM engine to start a new process, or, in the event of a correlation, to restart/continue an existing process. Of course, the CEP Platform has its own datastore for events (logging) and provide services to ask what happened when, and why did it result in a certain action.

ECM Solution - used for storing all non-structured data, such as emails, documents, faxes, etc. It might also be used to store structured data (incoming XML), to have a complete overview of all incoming messages (incoming records management). It of course contains all index/meta data, and provide services to lookup, view, alter content.

BPM Engine - used for process coordination. Based on process templates, it can execute steps in a proces, including logistic decisions (if's, supported by decision or BRE platform). It can handle automated tasks (e.g. calling services), and it can handle manual tasks (assigning a task to a certain user/usergroup), using information from the workforce management system. It records various process execution statistics for business activity monitoring.

BAM Solution - used for process monitoring. Is able to analyse data in the BPM engine, and present it. Could have all types of additional services, around KPI calculation, SLA monitoring and alerts.

CRM system - used for customer information. Gives a complete oversight of the customer, in terms of profile, current products, processes/services running and done. Decoupled of core administration system (since you could have multiple core admin systems, but only one customer!).

Workforce system - used to supply BPM engine with appropriate information to be able to send tasks to the right user or usergroup (via pull or push). This could range from simple static user/usergroup assignment, to complex rule-driven skill/availability/workload driven assignments.

Core administration platform - this would be the core system for supporting the business of this organization. For instance: account administration for banking, insurance handling, claim handling, stock market transaction system, etc. The system allows functionality and data to be accessed through services, or through context driven screens (triggered by a certain task in a process).

PLM Platform (product life cycle management, or product configurator). A platform which allows for quick adaption of products, supported by the core platform. It supports definition of products, product components, data definitions, rules and calculations.

The Decision Platform has the responsibility to make decisions (or advice them), based on data and rules. This could be fully automated, or a more manual supporting service (think traffic light signaling, for instance, frequently done in credit scoring, where a employee can still decide to accept a loan-request, even though the signal is orange or red).

Security platform. Users, roles, etc. Should be implemented centrally, otherwise you end up with various platforms (usually as part of the other components), with less strength and much more synchronisation effort.

Presentation technology - this component is able to enable various users to interact with the components, and view data. Think of the regular inbox and task windows, document viewing, but also event monitoring, BAM and system admin.

Outputmanagement - this component is responsible for communication outward. Based on events (or a called service from the BPM engine, not sure yet!), it knows, using output rules, what to communicate, to whom, through what channel (paper, email, website, etc). It is able to format a message (email, pdf, Word file, etc) and send it directly or to a printing facility. Of course, output is also send to the ECM solution for storage.

A process model is not enough...

2007-08-05T16:32:00.000+02:00

A number of years ago, I worked for a system integrator, with a a manager that was, well, a bit limited in his overview of the IT best practices.
One day he came up with a great idea. Recently visiting a seminar, he had learned that UML was the answer for everything. And he had a solution to the workfloor's problem: unclear requirements and an expensive process to define them. His solution: use case diagrams. His expectations: we could draw these in 1 hour, and voila - we had our requirements - quickly, clear, and cheap!
It took a while to make him understand that a picture, with some actors, circles and words, where a great idea to structure requirements, but by now means, a use case diagram would cover the requirements in enough detail. So reluctantly he allowed us to continue to analyse and write good software requirement specs.... :-)

It seems that we seem to make the same mistake now with process models. In a number of situations now, a business person delivered a set of process models, and said "well, here are our processes, have fun analyzing them and supporting them with good IT solutions".

Right....

So for once and for all:
When people need to communicate about process - a lot more information is needed.
My checklist:
- The goal of the process, how does the goal relate to the strategic intent of the company
- The criticality of this process
- Compliance, legal and other regulation requirements for this process
- The involved stakeholders (internal, external)
- The power structure/organization structure of these stakeholders
- The trigger that starts the process + through what channels
- The process owner
- The place of this process in the process architecture
- Input to the process
- Output of the process (including exceptions)
- The central object of the process (document, case, transaction, claim, client request, etc) that flows through the steps
- Events during the process, and typical + exceptional sequences and timings
- Data involved through the process
> Logistics (who does what when)
> Execution (data needed to perform task, data produced by task)
> Management (measures)
- Business rules for process:
> Decisions on flow (what task now.... if XXX then do YYY)
> Decisions on assignment (task XXX will be done by YYYYexcept if AAAA then performed by BBBB)
- The critical decisions, rules or patterns associated with it, and required authority to take them
- Succes - when is execution of this process considered a success? What performance criteria?
- CSF's - what is needed to reach this performance? and KPI's
- History of the process - when was it created, how has it performed, when and why has it broken down, what are typical issues, when and why performed it exceptionally well

Well, that's a lot more than a process model. It's the process context that BPM specialists need.

Starting with BPM-Suites - but what to do with presentation layer

2007-08-05T16:18:00.000+02:00

It was nice to see some of my remarks on my previous post (BPM and packages) confirmed in a good state of the BPMS market item on bpm.com:
http://www.bpm.com/BriefingRO.asp?BriefingId=31
"The true upside opportunity for BPM is to evolve into a platform that supports rapid application development, change, and integration with a visual model-centric paradigm that represents a clear advantage over previous application development approaches."

E.g. A BPM-Suite currently is nothing more that a new custom development tool....

I want to address another limitation, that causes confusion.
Many BPM-Suite vendors proudly say: well, use our BPM-Suite, model your processes, link to your services, and voila, you have your SOA enable, process aware, WFM portal..... And, even better: you re-use your legacy.

I doubt it.
On a recent project, a client wanted to use a BPM Solution, integrated with their current core application. BPM vendor comes in, and says: shield your application, by wrapping services around it.

What this means:
About 65 screens, that users are used to, and that work fine, should be replaced by 1. Services, en 2. Well, screens again, but now in a Portal component of the BPM-Suite.

Added value? Good question...
- Rebuilding screens
- Rebuilding screen based business rules/validations

I am a bit puzzled. How can we deliver the power of BPM technology for human centric workflow, in the reality of existing applications....

On my wish list: a BPM vendor that comes in, and says...
Oh sure, we have a tool that analyzes all screens in your application, analyzes all user interactions over the last X years, and then generate a portal with optimized screens. With some minimal work, if needed, you can optimize these screens where needed. Oh, and the generated screens use common techology X, conforming to standards Y.

Then... I see BPM as a new tool, that can take over and integrate various packages and custom built apps, and integrate them from a process perspective.

Key challenge for BPM-technology: integration with packages

2007-08-01T23:09:00.000+02:00

I have now seen two major projects that decided not to go for a separate BPM technology layer.
Both had done a large package selection (both in the insurance market). And it turned out (surprise) that these packages had their own, simple but workable, workflow/orchestration technology component.

I participated in both projects during feasibility studies, aiming to analyse the possibility to integrate the package with the company's target BPM platform.

And in both situations, we had to conclude: yes it is possible, but it's complex, risky and leads to a lot of extra effort.

Hm. This is not the way that BPM Technology is going to be the next killer app....

Some facts
1. These package vendors build their own "BPM technology" type components, but with deep integration with their package. Make's sense from a vendor perspective (for the short run), but is a nightmare for integration and enterprise architecture goals for typical companies (that would like to limit different types of technology used for process coordination)
However, their defense is also: there is no consensus on what BPM technology should provide, and what standards it should follow. Result of course is a proprietary process language, and service integration platform.
As a result, it is very difficult to buy the package, but replace the BPM component with your own central platform.
So we end up with another process component, and extensive integration (back to EAI) with other software, that needs to play a role during the end-to-end processes (so we lose overall process views and coordination).

2. User interface issues around packages and human workflow components of your BPM platform is another pain. Typical requirements are:
- Inbox for tasks
- Ability to open, claim, pauze, intermediate save, finish task
- Context aware task windows (e.g. after claiming a task, open the right dialog and windows in the package
- Integrate with document management, showing for a task the related documents.

As there are no clear standards and answers in these area's, clients have the possibility to let the package do this (usually speedy, but limited and proprietary) or try to find a solution with BPM technology and some presentation layer, integrating BPM, package and ECM solution.
Unfortunately, this is for the most part hard coding, deep coupling web client, server and various other technology layers.
So we end with, again, package solution, proprietary presentation layer, including WFM user interface.

Question - Can we solve this?

Well - there will always be package vendors that provide their package with a proprietary BPM component. Just to be able to support client requirements, one stop shopping and to avoid being dependent on third party technology.

But I think from a customer perspective (mainly technology), customers and their IT architecture can require packages to be more open to integration with third-party BPM tools. Definitely a good advice.

And most vendors might not have an issue either - it's sometimes better to focus on the package functionality, and leave general functionality to others (see what happened to identity management/LDAP, database, app server, messaging). BPM technology is the next candidate for commodity infrastructural software.

However, the BPM vendors need to do something too - being able to standardize even more. Sure, the WFMC model is a start, and some standards are there. But solve the above two issues 9with minimal development required and customers can force package vendors to open up to process (as a next step, after opening up for data and services).

And then BPM technology has a chance to go more mainstream. Otherwise we will always view BPM technology as yet another 4GL, in which we can develop visually (but we still call it development...)

What's BPM and what's in your process portfolio?

2007-07-30T21:59:00.000+02:00

I had a funny discussion with a collegue on BPM and the contents of your process portfolio.
He, being a bit new to the area of BPM, first asked me to define it. Well, I used an old definition and talked him through the following story line...

"Hm, BPM. Business process management. Can you define it?"
"Well, sure. You know financial management?".
"?? Uh, yeah, of course, that's been around for ages"
"Ok, well, what is it, financial management?"
"Duh. It's taking care of your money".
"Hm. How?"
"Well, all sorts of concepts, techniques, organization, people, sometimes IT, so in total a lot".
"Explain?"
"Well, cash flow, boring accountants, activity based costing, accounting, budget, budget review, balance sheet, general ledger, accounts, and of course people, some activities, and they usually have some of this stuff automated in a financial system. Oh, and they have al kinds of techniques for investments, business cases, ROI, EVA, etc".
"Wow, you really grasp that. So, it's a lot of things, aimed at taking care of your money, right?"
"yes!".
"Why?"
"Well, otherwise the company would go broke. That's why!"
"Ah! Excellent. So... money seems an important resource. What other stuff do you see as important to manage?"
"Uhm, let me think. Well, people (ah! human resource management"), risk (ah! Enterprise risk management), uhm, products! (ah, product life cycle management), oh and of course customers (crm).
"What about process?"
"Hm. yes, those too - if your processes are bad, no money will flow, people will leave, products will not develop, risk will run around, and customers.... well, you won't have them"
"So, there's your BPM, BPM is a whole lot of stuff to take care of your processes".

So, the discussion continued...

"So, can you tell me about this BPM. I understand Financial management, but I guess BPM has other concepts"
"Indeed. In BPM we have....
- A process portfolio
- Proces models (of all important processes in your portfolio)
- Proces owners
- KPI's for some or all processes
- A process life cycle approach (from define/discover, analyse, model, implement, measure to improve, innovate,and phase out)
- All types of practices around these life cycle steps
- People with specific skills that takes care of process modeling, consulting, and helps to improve them
- Automation for process modelling, measuring and sometimes executions"

"What's in this process portfolio?"
"All the processes you have identified, and you feel strong about"
"Can you name some?"
"Sure,
- Operational processes (procure, pay, build, market, sell, deliver, invoice)
- Product lifecycle processes (invent, develop, test, maintain, phase out)
- Management processes (operational, tactical, strategic)
- Supporting processes (IT service management, HR, Finance, Risk & Compliance, etc).
"
"That's it?"
"No, there is one more. It's called your Change process"
"Change process? That's not a process. That's a project!"
"Oh, is it? I bed that everytime you adapt your company to new markets, new regulations, new risks and new chances, you take simular steps".
"Well, yes, but..."
"And that around these so-called projects, you have processes to select yearly what changes to do, what projects to run, to measure, re-evaluate, etc?"
"Hm, yes, but..."
"And that, if you would really succeed at being great in change, all your people should be able to understand and take change steps really good, by repeating this proces?"
"Yes..."
"So, it's a process. A process that delivers change to your company. And you should know it, measure it, improve it, manage it. Like crazy. Because if you don't, all the other stuff doesn't matter".
"He. It's the same as an important concept in Financial management! The only way to really take care of money!"
"Which one?"
"To Invest!"

"you got it :-)!"

-

Requirements - need for new approach

2007-07-16T19:07:00.000+02:00

Been doing some consultancy for a client, around the processes dealing with requirements. Yep, that's process management as well - making sure your innovation processes are able to capture requirements and initiate and guide change effectively and efficiently.

My client is struggling with two things:
- A large application, which misses a lot of baseline documentation (what else is new...), and no clear approach how to capture requirements for changes
- An unclear link between strategy/business drivers, business processes and the IT functionality to support the processes

Let's start with the first one - requirements methods for maintenance situations
It's amazing to see how little one can find on requirements management and engineering for existing applications. Sure, tons of stuff for "green-field, let's create a new application, with a great set of requirements". But honestly, how many times does that happen?
Right.
(One article I found was a good start, and I recommend it - www.processimpact.com/articles/reqs_not_green.pdf )

What is needed is a better, common way, of dealing with the requirements around an existing system. And how to define changes - so that business knows that it asked the correct things, designers/developers know what to build, testers know what to test (next to regression testing), and change management knows what to prepare the business with.
Something a bit light and agile (you know how many requirements an average system contains....many!) And.. With a clear process and clear artifacts.

For now, we came up with:
- Identify required change source, stakeholders and business drivers/strategy
- Understand requirements of change, in terms of changed/added/deleted
=> business requirements (e.g. what does the business want to reach)
=> process requirements
=> functional requirements (global and in the form of use cases or a functional decomposition)
=> non-functional requirements
=> information model
=> business rules
- Determine impact and possible solutions. Perform trade-off analysis
- Decide on scope and plan the change.
- Perform usual IT activities (refine, design, implement, test, etc)

Insights welcome!

And now the second one - the missing link between business intent, process, requirements and IT.
Most requirements methods are still focused on what I call "features". A business analyst will talk to users, understand processes and data, and will come up with a solution, expressed in a list of "the system should .... feature X". So, in the end we understand what functions it needs to do, maybe even understand the tasks they relate to, but we lost the link with process and with business drivers/intent.

What I hope, is that requirements methods will evolve, and will start linking to new developments in thinking around business architecture and process architecture.
In the end, we mainly build IT systems to support actors within businesses to perform tasks, that are executed in the context of processes!

So, what I would like is to see the convergence of:
- Business architecture concepts:
- What business intent/strategy do we want to implement?
=> Principles
=> Execution Objects (could be people, IT)
=> Data Objects
- Process architecture
=> What processes are needed to execute and deliver the strategic results?
- Requirements
=> Linked to process steps: this step, we want to automate, and it will require XYZ....
Hm, you might even call it: BPM driven requirements methods!

Again, comments welcome. I am puzzled by the naivitity of current requirements methods.

With BPM technology towards supportive, context-sensitive end-user applications

2007-07-16T18:37:00.000+02:00

Picture a complex application, full of user-oriented functionality. Thousands of forms.
An ERP system. Or some custom application for pensions, complex trade, transport, etc.

Now image the time, the training, the effort people need to get used to the user interface. To find their way to the correct windows, menu's, dialogs. Quite a challenge. And imagine users in a situation where every X months new features are rolled out. For a new product, a new service. A new menu item, hidden under three layers of other menu items.

And so, think of the amount of process tasks people are performing daily. And then the amount of time they need to...
- Understand the context of a task
- Remember what functionality to use to perform the task
- Navigate to the correct functionality
- Remember how this all works and how to perform the task...
All this, eevery day, every time a new task needs to be done...

Now let's look at what BPM technology can deliver, together with more smarter/opener, let's say service based applications (and possibly some rulebased layer, or context engine)

A process is started in a BPM engine. A task is delivered to someone's inbox.
The person opens the task, and wants to perform it.
And the task has knowledge. It knows its context! So, why not let the task tell the application?
E.g.
- User opens inbox
- User selects task to execute
- Task informs application (through a context engine) what is needed from the application
- Application shows just the functionality/windows needed for the task
- And if needed, shows detailed instructions, based on the task context

Basically: the context-sensitive application.
No more navigation. The task will lead the way. And the user gets the right information and functionality at her/his fingertips.

Result:
- Less unneeded navigation, getting lost, mouse clicks, etc.
- Faster processing
- Reduced training cost

But, how do you train someone new? Or when a trained person gets a new task, or needs to use new functionality?
Well, the BPMS can tell (BAM) that a certain task has never been performed by a certain user. So the BPM-S or an trainingmodule can warn the user, provide computer based instructions, and guide the user through her/his first time. And if needed, again, and again (e.g. task inbox item should have a button saying "I need some help with this"). That's what I call supportive.

New RSS feed available (full articles)

2007-07-12T20:18:00.000+02:00

As a result of Sandy's tip (http://www.column2.com/2007/07/links-for-2007-07-02/), I have now added an RSS feed with full articles. (And gosh, a quick search on Google showed me that there is a large discussion going on, on full or partial publishing. Hm, I vote full... ;-))

And: Other tips and comments always welcome!

Regards,
Roeland

(Just back from a lovely vacation in Italy - when in Umbrie, don't miss http://www.sanpietroinvalle.com/eng/, but don't tell others!)

From interface spaghetti to process coordination layer

2007-07-01T15:23:00.000+02:00

Remember the old days of system integration?

Requirement: When we have done task X in application A, we need to send data to application B, so we can continue doing stuff.

Solution: we create a system to system interface.

Purely datadriven. As an example:

- We enter an order in our ordersystem

- During the night, a batchjob will wake up, and send the order data to the invoicing system

- The invoicing system will send an invoice and update general ledger

In diagram:

The results are known:

- Many interfaces, spaghetti

- Applications become coupled, having knowledge about eachother

- Many types of technologies for integration (file/FTP, messaging, API calls)

- A system is responsible for only part of a process (do + send).

- When exceptions arise - who will fix? Extra knowledge of system B in system A.

- Process understanding disappears from business to IT (and from IT to technical batch schedules, that no-one really oversees)

- Difficult to maintain, a change leads to changes in many systems

- Many different ways of reporting status and issues (leading to tons of paper output that no-one dares to read or check...)

And of course, we have tried. We invented EAI. Companies bought ESB's. The result: the same spaghetti, but now standards based.

The lesson: put the process back in the solution. E.g. don't let systems do hand-offs, but let a process coordination engine do this for us....

The solution now looks like this:

Advantages:

- Clear process

- Part of exceptions can be handled by process engine itself

- Other exceptions can be forwarded as manual tasks to business and IT without additional changes in systems

- Systems are decoupled and have no knowledge of each other

- Integrated, process based (in stead of integration based) reporting

- Information flow can be real time (or can still be done in batch)

Realize - this should change your thinking. Don't think interface, think process:

Requirement: we want to correctly sell and invoice our products (process). As a first step, we want to capture order data (step in process). After that, we want to generate and send an invoice (step) and update this correctly in our general ledger.

Solution: define the process, link the process and the solutions for the steps, and use a process coordination layer.

Take-aways from a Microsoft BPM Seminar

2007-07-01T14:44:00.000+02:00

Recently I visited a seminar on BPM, organized by Microsoft and some of it's partners from the Microsoft BPM Alliance (in this case Ascentn, Ruleburst, IDS-Scheer and Amberpoint).

Ironic: the seminar was organized at the premises of the owner of Cordys, a direct competitor in the field of BPM-suites.
Another irony: while most Microsoft talks were about 30 - 50 minutes, each vendor was only allowed to speak for 10 minutes. How's that for powerplay. And that was unfortunate, because these partners seemed to understand BPM much better....
A bit scary is the strength of these parties in The Netherlands. When asked, most of these partners had only 1 or 2 implementations in the Netherlands.
Last.. I was surprised by the amount of people (about 100). Not bad for BPM.

On average, the BPM seminar was oriented at a fairly technical audience. Most talks were about SOA, services, engines, etc. E.g. not much attention to BPM as a business discipline. And as result, most talks were based on "if you built it, they will come...". Hm.

The typical SOA/BPM slides came along:
- Services from legacy and other apps
- A process layer to coordinate services and deliver outcome
- Business rules to drive decisions
- BI/BAM for process measurement/reporting
- Multichannel presentation layer for human interaction

And the typical promises on business case:
- Agility, nicely coordinated, loosely coupled...

It was nice that some anti-patterns were discussed:
- BDUF - Big design upfront , were architects design the grand future from an ivory tower
- "Buy an ESB and everything will go smoothly"
- Hacking it from the bottom-up

The suggestion was: Middle-Out, think big, act small, take incremental steps.

Two great presentations were given by David Chappel (http://www.davidchappell.com/blog/)
Some of his key statements:
- SOA has been around for years (DCE, Corba, COM). But now, with standards in place, we can really get it going (SOAP, WSDL).
- RPC standards are in place. However, a good standard for messaging is still missing.
- Reuse is unfortunately NOT the key business case driver for SOA. Did we ever leverage reuse that much? Remember OO? SOA's key driver is Agility. Reuse is limited to technical services, not business services.
- UDDI is a dead-end street. Nobody uses it.
- Business people developing and maintaining their own processes in a tool for execution - it is a myth.
- Business does not care about SOA.
- The future of Java is at risk. There is no clear process execution framework and infrastructure for Java, while Microsoft's Net.3.0 has this built in. In addition, there is no clear solution for business rules (repository and execution), where Microsoft has many.

He also went through the Microsoft technologies relating to BPM.
- Biztalk for system-2-system orchestration, with Workflow Foundation
- Sharepoint for Human processes
- Integration with browser and Outlook
- Ability to create process aware applications based on Office (OBA - Office Business Applications based on MOSS - Microsoft Office Services System)

An interesting thing was the Sharepoint Designer tool. Although only shown shortly, it was interesting to see that they had choosen not to use a traditional procesmodelling tool (activity, arrow, etc), but a rule-based (if XYZ happens, then create action ABC for person D), comparable with your "email rules".

I liked some of the collaborative options, with the integration of Outlook. For instance: define a proces, where a task will automatically schedule a meeting with certain stakeholders, to decide on a certain issue for this process.

But.... a key issue. If you want to define a business process (and rules) using Microsoft technology, and this process covers both System-2-System and Human workflow, you will need to work with 2 tools, and you will not have an integrated procesmodel.....
Microsoft and David did not see this as an issue "as there are not many other vendors that are supplying integrated process tools".

My soapbox...
I think they are wrong... In my opinion, this seriously limits the position of Microsoft in the BPM market. It leads to multiple technologies, competences, maintainance (2 repositories), and issues around BAM (where to measure what?).
They also said this themselves - MS will probably integrate the models.
Strangly, no word about Visio, which is I think a large player in the process modelling area.

Funny is that this lacking also explains partly the partner-strategy. But I wonder what will happen with the Alliance as soon as Microsoft has extended their capabilities.
In my view Microsoft is simply late, tries to compensates with partners, and will get back on track in some time. And some of the partners are so small in terms of ability to execute, lacking succesful implementations, I wonder who will go for these partners.
And as usual, no clear position on BPMN and BPEL (although BPEL seems to be supported end of this year...)

Take-aways from BPM-Forum session

2007-07-01T14:13:00.000+02:00

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?

2007-07-01T13:36:00.000+02:00

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?

2007-06-25T21:42:00.000+02:00

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

2007-06-21T16:42:00.000+02:00

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

2007-06-09T00:05:00.000+02:00

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

2007-06-05T21:44:00.000+02:00

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

2007-05-28T14:17:00.000+02:00

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

2007-05-08T11:37:00.000+02:00

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?

2007-05-06T17:47:00.000+02:00

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.

2007-05-03T00:04:00.000+02:00

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."

2007-05-02T13:58:00.000+02:00

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

2007-04-22T22:55:00.000+02:00

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

2007-04-21T00:41:00.000+02:00

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

2007-04-14T22:42:00.000+02:00

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

2007-04-11T23:44:00.000+02:00

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

2007-04-11T23:24:00.000+02:00

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!