So, agility it is. Who wouldn’t want to be agile? Who would want to state that their company does not need to be agile? Being an agile company is a good thing and using agile processes to create value sounds like the right thing to do.

And can I state for the record that I love the concept of agility. There are too many examples of businesses with untapped potential, businesses which could do much better if only those barriers to change like time and effort to change processes and/or change IT didn’t exist or were significantly lower. In that sense, the promise of agility through better integrated BPMS which allow you to design a process (or a change to a process) and get it to run at the push of a button is a promise worth taking note of. Anyone involved with workflow management system implementations in the 90s or BPMS implementations in the following years will remember the projects that took longer to complete (and delivered less than promised) than … say the building of a new multi-story office tower. Four months of project work to design and implement an employee self-service process to speed up handling of applications for leave? This could be a thing of the past, at least from a technical perspective. BPMS have certainly improved in that respect and even if they don’t deliver push button implementation, they have come a long way from where they used to be.

Thankfully, this goes for the industry as a whole. Their promise of agility is something they can deliver on, regardless of whether you take vendor x, y or z. (Which by itself is remarkable for an industry that has lived on making promises and prayed to be able to fullfil them 5 years later)

Unfortunately, this does not benefit most businesses in any way – and this is unlikely to change any time soon. The very simple reason for my negative view is that businesses are basically unprepared for agility. They may want it, they may even need it but they can’t handle it. We have mentioned this before on our blog and I spoke at length on the topic of business readiness some weeks ago at an international conference. The shoe is now on the other foot. Instead of IT failure we are now seeing employees who are starved of process awareness, process managers who are unable to manage processes (though they administer them beautifully and use dashboards to watch them just like train spotters standing on the platform and ticking the arrivals off in their notebooks) and senior management which fails to provide process strategies and prefers to remain blissfully ignorant of all process things.

Preparing the enterprise for what comes out of process projects and for using the potential of what BPMS could deliver is the dominant challenge to business process success. Agility begins in the mind, though it very quickly moves on to aspects like governance, strategy, centres of excellence and many other very concrete issues which need to be addressed in order to turn a successful project into a successful process operation.

My guess is that this may also turn out to be the greatest challenge to new concepts like Outside-In. O/I, which is based on the approach of customer-driven rather than capability-driven processes, makes enormous demands on business agility. Think ‘push button process change’ and then extend the image to have the customer pushing the button. From a customers perspective this would be paradise and anyone who can provide that paradise can be sure of my life-long friendship. But even moving in that direction takes more than an agile IT. In requires an understanding of the customers, of their individualism, the dynamics of changes to their processes and the consequences and implications to the business in order to accommondate the customers requirements. Outside-In, probably more than any other process strategy, needs agility AND process management to make it work.

So, while agility sounds good, it needs a [mentally] agile business to make it work. Only then will agile-in lead to agile-out. Otherwise it’ll be the usual ten seconds of project fame stuff that basically means ‘seen to be doing something’. We should all have realized by now that while it may be easy and quick to buy the software, it won’t compensate for lack of knowledge and experience – something that takes far longer to build.

This posting wouldn’t be complete without mentioning that taraneon provides guidance and support on developing business readiness capability….but I think you’ve guessed that already.

Now we come to the $100.000 question:

The speed at which a football travels through the air in Johannesburg is – as compared to Berlin – and presuming an otherwise identical force of kicking it:
a) lower
b) identical
c) greater
d) I don’t know what a football is

Ok, so you might just have the feeling that answer d) is probably not what we’re looking for. And you’d be right to think that this question will never be asked on ‘Who wants to be…’ or a business process quiz show (now there’s an idea). But there is a connection, but more on that later. First let us find the right answer to the question.

By the way, the usual BPM approach would be to kick a ball in Berlin, buy a first class ticket to Johannesburg, kick another ball and then decide you couldn’t have cared less and start looking for someone to blame.

But here’s how we get to the real answer:

Johannesburg lies 1.800m above sea-level while Berlin rests at a lowly 100m. Using the standard barometric formula we can calculate that the atmospheric pressure is 19% lower in Johannesburg. Assuming identical outside temperatures the rules of the ideal gas law apply which means that air density is also 19% lower. This results in a horizontal speed of the football which increases by the cube root of the inverse density.

No doubt you will have done the calculations in your head by now and correctly come up with a 7% increase in speed in Johannesburg. Answer c) is the right answer, which not only goes to explain some of the appalling goalkeeping we’ve seen but might be just as surprising as some of the results we’ve seen in the Process TestLab recently.

The following chart makes for a nice example:

What the graph shows is the work time required by 100 instances of the same process. Now, this was a process of which the process owner had told us that it got the job done and worked just fine. When we put the process through the Process TestLab and came up with the result that work time more or less continuously varied by factor 5 to 7 and that the reason for that lay in some unfortunate combination of business rules which led to process instances being handed back repeatedly to the originating department for no reason.

Looking at his departments method to validate processes, it was easy to determine why they didn’t (and couldn’t have) spotted this earlier: Even a detailed validation run using just a single process instance cannot provide you with a realistic view of a days business – in particular not if the validation is based on a model rather than a process. Anyway, a few simple changes to the process have now helped him not only in improving on those 100 process instances, but in making the process more efficient 365 days a year – rather like getting the $100.000 football question right not only once but every day. Which is why we think the Process TestLab provides great long term value.

(Final note to our friends everywhere except the UK: It’s only a proper World Cup if Germany beat England on penalties, otherwise it’s just some guys kicking a fast ball around, though Arsenal are the best team in the world)

(Chart: taraneon, pictures (licenced for re-use): flickr, army.mil)

So now we (minus the dinosaurs of course) have to content with business processes as a cheap substitute for roaming the the earth and demonstrating our power. And contrary to dinosaurs our communication has evolved (!) from growls to beautiful terms and expressions like ‘Customer satisfaction index’, ‘Service orientation’, ‘Customer experience’ and ‘Outside-In’. Great stuff and it all seems to suggest that we have actually understood that customers are not only at the center of an enterprises’ strategy but are the sole raison d’etre of an enterprise.

I raise my hat and solute you with a glass of champagne if that’s the case with your company. And I can well afford to do so because I won’t be needing too many hats and open that many bottles of France’s finest.

My hypothesis (being very careful now) is that we have over the past 10 years not nearly done enough to be able to make the leap to customer experience and Outside-In. In general, employees (the process workers) are too seldom involved when it comes to process improvement, have mostly too little knowledge about the processes they work in and how their actions interact with other processes and the so-called process managers are often simple process administrators. As one CPO (that’s Chief Process Officer hey, another pointer in the right direction?) said at a conference last year: ‘Good process management should not be left in the hands of our current process managers – they are not qualified.’ I might add that even if they were qualified, their skills would probably cover tools and tricks but certainly not how to evolve a companys mindset towards customer-oriented thinking and lets not even mention Outside-In.

Being in a lucky position to have been able to closely monitor several companies over the past 10 years I can barely count the number of service initiatives and improvement drives they have started and which were ordered by the top management. Glossy brochures for the employees, posters and multi-coloured charts lining the walls is about all these programmes managed to produce. Because if you take todays processes and substract the IT that supports them what remains are basically the same processes with the same kinds of objectives defined from the same internal (!) perspective as 10 years ago. It’s just that IT has provided a comfortable – if rather expensive – veil to cover the fact that nothing has really changed.

Understanding where you are is just as important as creating a vision of where you’d like to go. Once you have those two elements in place – and only then – can you really come up with something like a planned evolution. It takes just one single competitor in your market who has managed to develop a workforce and processes entirely fixated on customers to start a process that will leave you looking like dinosaurs (and end up like they did). And before you know it, your customers will be hitting you over your head – probably with the odd dinosaur bone they picked up along the way.

Of course, many will say that my hypothesis doesn’t apply to their company (and in that case I sincerely apologize to them), but take a look at the quality of process documentation we’ve seen at the Process TestLab and you can’t help but wonder how we want to evolve if we can’t even properly describe where we are. Like John Cleese would have said 40 years ago: ‘This is a (future) ex-process, it has seized to be, it is no more and the (IT-)plumage doesn’t enter into it’.

Process evolution begins in the mind and might end up in IT as well, but never the other way round.

(Written in a grumpy mood, last nights World Cup game wasn’t much to shout about)

Most people would say: This is the Mona Lisa … and they’d be wrong. The picture depicted someone who may or may not have looked like this 500 years ago. A picture showing what the lady looks like today would probably…well ashes to ashes etc.

The reason I mention this is that the same imprecision can found with regards to business process models. Many take such a long time to design that by the time they are finished they are already out of date. And just like old Leonardo depicted his view and perception of the lady, most process models are heavily influenced by the perception (or lack of) of reality by the modeler/business analyst. But while the artist had at least one person to validate the picture (the buyer), most companies rely on the analyst to validate/approve his own work. Why not let the people who will need to work with the process do the validation? At the end of the day what counts is the process and not the model, so get the process experts involved. Chances are that their verdict will be “We understand why you designed it this way but this is not how it works in practice”.

Gary Comerfords recent short posting on the Process Cafe seems to reflect a similar opinion, so you might want to take a look there as well.

Leonardo certainly knew what he was doing while the expertise of modelers seems to rest on brushes and paints – and not on results. Which is why the Process TestLab offers a unique way to validate processes before they are implemented. Process art is like Leonardos work…interesting in itself and usable. The rest is just expensive junk: process models for the sake of it!

(picture by artelista.com)

It’s nice to see 80% of all members making the move inside a couple of days without any major hiccups.

Curious to see that while many BPM vendors are making free or open source versions of their tools available, providers of social platforms seem to be going in the opposite direction, which was the prime reason for moving BPM Nexus to its new home.

Thanks to Gary Comerford for making the transfer run so smoothly.

Test 1: Validation – Completeness

This is where we check if the process description is in itself complete (are all necessary steps/tasks included in the process design, likewise roles, IT-systems etc.)
What we actually do in this step is to implement the process on our test systems and see where they come up with warnings.

Test 2: Validation – Content and Objectives

Once the client has updated his process to get rid of the warnings from Test 1, we let various teams from the client experience the process by running it on our systems with distributed roles. The fun part of this is that this is done on the basis of workflow and BPM technology, so the routing of the process across distributed roles and systems is comparable to the final process solution the clients would like to implement…but as this is done ‘only’ on our system system, the client doesn’t need to risk implementing the process before checking if it truly does what it should.

Test 3: Simulation

All process designs are based on assumptions. Assumptions about workload, about ressource availability, system response times, influences of other processes and not forgetting customer behaviour (for those who regard this as an essential design input). What the Process TestLab does is to take these different classes of assumptions and build scenarios around them by varying the assumptions. Then we subject the process to these scenarios to determine how the process will behave and perform.

Test 4: Stresstest

This comes in two parts. The first stresstest is rather like an extreme simulation to determine the limits or breaking points of a process. Sounds like a lot of theory until you think back to the latest case of birdflue, volcanic eruption etc. It’s all about the question of how much stress your process and its resources can take before they seize to be functional any longer. The second stresstest has turned out to be a real eye-opener for some clients: While during the validation test we looked only at single processes instances to determine the quality of the process, this stresstest puts the clients team under stress by producing increasing workloads. Not only does this tell where the cut-off point lies, the point at which the process and the organisational structure cannot provide the required support but it also offers a preview of the conditions employees would face after implementation.

I hope you get the general idea and I wonder how you think your latest process project would fare, because if the results of the past weeks are anything to go by …

A) No single process checked in the Process TestLab was complete and could have been implemented.

B) 80% of all processes that reached Test 2 contained logical errors, errors of routing and other types which would have led to unwanted and even wrong IT implementations. (Remarkebly even processes which had been pre-checked by internal business analysts were no better)

Test 3 provided some new insights to clients who thought they knew it all … although, who could have guessed that it would take them four times as long to process workqueues than they thought.

What this comes down to is a possible explaination of why implementation projects of BPM-Systems and of new processes are rarely regarded as successful and mostly blamed on IT. Faulty process design will inevitably lead to faulty processes. And it’s no secret that repair work on processes and process systems is always more expensive after the fact than the avoidance effort one might have invested before implementation.

Hopefully, the results the Process TestLab is currently seeing will improve over time, but the ‘better safe than sorry’ motto is something all too many projects cherish their ignorance on.

So don’t rely on guesswork and the look-good factor of your process models. The Process TestLab can provide you with the facts for your decision making.

“The Outside-In approach to business is a “rule-buster” of the first order. It’s also a fundamental response to new, customer-driven market conditions that will remain with us for the foreseeable future.

The core premise of O-I is that adding new value to customers presents the only sustainable way to continue adding new value to the company. To create new customer value, O-I rethinks the company from the customer in―first aligning strategies with customers; next aligning process to customer-focused strategies; then aligning technology to customer-focused process.

The outcomes of going Outside-In can be transformational. Market-leading companies either “born” O-I or successfully migrating to this customer-centric philosophy include: Amazon.com, Apple, Fed-X, Nordstrom (U.S.), Singapore Airlines, Tesco (U.K.), the Virgin companies and Zappo’s.”

(Dick Lee is founder and principal of St. Paul, Minnesota-based High-Yield Methods. His work and perspectives have been featured in “Business Week,” National Public Radio’s “MarketPlace,” “Newsweek,” “The Wall Street Journal” and numerous other print and web-based publications.)

Readers will know that we recently launched the Process TestLab (PTL), an independent facility to analyze, validate and simulate processes and their behaviour under varying circumstances. One of the tests the PTL conducts is a stresstest on processes. For this test the PTL subjects the process structure, its logic, to stress by varying the load it handles while keeping the available resources at a fixed level. The reason for this test is to identify the critical upper and lower limits a process can handle.

If you’re involved with operating processes you know that the relationship between input (stress) and output (performance) is seldom a fixed ratio. In most cases that relationship is more like the fuel consumption of your car: If you increase your speed, consumption will likely increase disproportionately. As most business analysts and process designers tend to base their design on certain assumptions (we usually have 10 enquiries per hour, average interest rate was 6%, cost of an office worker is 20$ per hour) the processes tend to perform well enough when these assumptions correspond to reality. This is what’s usually known as the sunshine case. But unless you’re living in the west saharan desert, we are all aware of the phenomenon of precipitation…some of us have even got soaked once in a while. So, while it might not be necessary to carry your umbrella with you all the time, the basic understanding that deviation from the sunshine case can have consequences should not be too much to ask for (particularly when you’re holding a well paid managerial position).

So when the representatives from Citigroup (among them their former chief risk officer) admitted at a recent hearing of the Financial Crisis Inquiry Commission that they conducted their stresstests in such a narrow range of margin that the results had to show good results, you can only wonder why they spent any money and effort on doing the stresstest at all. Of course, the main excuse behind it all was that the stresstests had really only been performed for the benefit of the regulators and not for the bank itself, which had always seen itself above those petty requirements. Come to think of it, it’s rather like ordering the safety belts and airbags only when you know that you’re crash -  and as you never think that it’s going to happen…

Exceptional behaviour under exceptional circumstances in an exceptional industry? I think not! The same sort of attitude can also be found among process managers across the board. And they all have the same attitude: Too big to fail – and if it doesn’t work anymore we’ll just have to get the money for the next reengineering project (not that that will improve things, but it’ll show that we’re doing something about it).

We recently had a very interesting meeting with a project manager who proudly showed us all the process models his team had designed over the past 12 months. The PTL did a couple of quick tests for him, among them a stesstest on one of the processes and an analysis of the implications of failure of critical IT systems. When we presented the report, the response was ‘As long as the process works when everything else works, I’ll have done my job’. Quite funny, given that the results showed that a 5% variation of the number of customer complaints would lead to a complete breakdown of his process and that a 24 hour system breakdown would require one month to work through the backlog. While one might have expected a different reaction to our findings, at the very least the future manager of that process will now be keenly aware of the critical issues and will keep an eye on them. This is what process management is about – not trying (and failing) to build the perfect process but managing the unavoidable shortcomings and risks to ensure quality and performance, which implies knowledge of the inner workings and behaviour of the process.

So, while the Process TestLab can’t predict when it will rain, it does tell you what would happen if it did and what you could do about it. The Process TestLab: Putting stress on your processes so that reality can’t!