In January I interviewed Thomas as part of my An Audience With… series, co-founder of Taraneon which is a respected BPM consultancy in Germany. Since then they’ve not rested on their laurels and last week won an award for innovation in BPM at CeBIT for their new Process TestLab service which I announced exclusively first on Monday in the News section of Redux. It seemed appropriate to revisit the original interview with Thomas and get more information on PTL which takes process simulation to another, more accessible and valuable level for clients.
Congratulations on winning an innovation prize at CeBIT under the BPM category for the new PTL service, what was it like given you’ve only just announced the Test Lab ?
It was quite an unexpected surprise, given that there were 2.000 entries in the various categories – so it’s really a perfect start to what will become an essential part of the taraneon portfolio. I think the judging panel recognized not only the innovative aspects of the Process TestLab itself but also the importance of the problems companies are facing when changing their business processes – that journey into the unknown.
When you bring to mind that only 18% of process reengineering projects are regarded as successful, something in our usual approach to improving processes must be wrong.
Maybe the message is finally hitting home that there’s a difference between improving a process model for its own sake and improving the process to obtain certain results. Either way, it’s nice to get a pat on the back when you’ve done something good.
PTL is a joint effort with another party, can you tell us more about this and how the idea was conceived and developed ?
The idea and concept behind the Process TestLab is something we had been kicking around for some years. When Norbert Kaiser, the co-founder of taraneon, was still vice president at Deutsche Telekom we used to discuss how to get a better grip on and better control over the literally hundreds of process change projects going on at any given point in time.
The usual approach companies take is to wait until process design and implementation is completed only to then find out what percentage of projects they have to send back to start again. A very unsatisfactory approach, not to say inefficient and risky. And there are not too many companies out there who can really afford this trail and error method and fewer and fewer customers are willing to accept being used as guinea pigs. Unfortunately we’ve all grown used to this state to things. Maybe it’s one of the reasons why the level of confidence in BPM is so low.
So, with the Process TestLab, we were looking to fill that validation void between design and delivery. Few companies are willing to risk investments into BPM and process implementation projects when the initial process design bears no visible and reliable relation to its later operational performance and quality. Plus, we wanted something that was neither a software product nor a consulting service, both of which we saw as at least being part of the cause of why process projects have failed to deliver.
What finally made it happen was that we sat down one day with Herbert Kindermann, the CEO of jCOM1, who I had worked with at IDS Scheer for some years. He liked the idea of the Process TestLab so much that he was willing to dedicate his own resources to supplying a core part of the technology of the TestLab. So we collected all of our ideas and concepts and wrote down the functional specifications. It’s not the only system in our engine room but as we’re not in the business of selling software but of providing answers to questions, the resources we use at the TestLab need to cover the whole range of issues our clients are facing.
So say I want to improve my mortgage application process and have 2-3 scenarios in mind as an end state I want to reach, can you walk me through how taraneon and the Process TestLab would engage in this instance ?
Roughly put, there are three quality gates at the TestLab: completeness, risk & performance and acceptance.
Firstly, we feed your process scenarios into our Lab systems to create a calculable and executable process.
Next, we check the completeness of the scenarios, i.e. are there gaps with bits and pieces of logic missing etc. Our systems also check the loops, the branchings and other design elements that might lead to problems.
This check shows us whether we’re actually working with an executable process, regardless of performance issues.
- Risk and Performance
If the scenarios check out ok, we start with the risk and performance tests. What we’re looking at here is to determine how the variations of the various input parameters affect the process and what consequences this would have. Quite a mouthful so I better break that down into separate points.
Let’s start with the stresstests. The first stresstest we run calculates the performance of the scenarios under a given set of conditions. The second stresstest does the opposite, it varies the conditions under which the scenarios would operate. Again, we conduct these tests by actually running the processes, so it goes much further than just checking a process model.
The reason for this two-tiered approach is that while a certain scenario might reach its objectives under one set of conditions it might well fail when those conditions change. So, with the second stresstest we’re identifying the operational limits of a process scenario.
This gets us to a point where we know that a) the process scenarios are complete and b) how they would perform under real life conditions.
Now, a particular change to a process may not only have direct effects on its performance but may also – adversly – affect other areas of that same process as well as having implications on other processes. When we run that process through the TestLab we can identify these positive and negative impacts across all possible permutations – which is next to impossible to do on a manual basis. Taken in context with the stresstests this gives you a risk assessment which may lead you to either discard scenario or to strengthen the management of the process to control those risks.
The third area the Lab evaluates is the ressource allocation. What are the optimum staffing numbers to achieve an intended result? Another question that’s repeatetly asked is how downsizing would affect the process and where it could be done with minimum impact on quality and performance.
So this gets us to a point in our analysis where we have proven that the process is executable and how it would perform. But as we all know, a process doesn’t work all by itself it also has to fit to the company and staff using it. This is were the acceptance tests come in.
This is the really good bit. As we’ve validated the scenarios by RUNNING the processes in our TestLab environment, we can also use that same environment to let the process users put their seal of approval – or not – on your scenarios. For this we’re using an extention of the stresstest approach: First off, our validation system takes the users through the process step by step. By that I mean through the actual runtime process with simulated applications. Data can be entered a
nd forwarded, decisions made, pe
rformance watched, in short, the process can be experienced. The advantage of this ‘employee validation’ is that they are the ones best qualified to judge the effects of the scenarios on their daily work. How does it tie in with their tasks in other processes? What are the implications from their perspective? And it also provides them with a much better sense and feel of the scenarios as they are actually experiencing them and not only looking at a model they have to interpret.
Once we’ve completed this step-by-step validation, we subject the process workers to the stress validation, this time not focussing on whether the process can handle the stress but if the ‘loaded’ process can be handled by employees working on numerous process instances. Working through one instance of a process is vastly different to working on a multitude of process instances in a given period of time. This is what we let them experience, and it can be a deciding factor when it comes to process acceptance.
The Process TestLab provides a detailed report on each of the tests conducted, allowing our clients to decide on whether to progress to the next stage or to maybe abandon one of the scenarios. We don’t make those decisions, the Process TestLab just provides the clients with the facts from which they can draw their own conclusions. The Process TestLab provides the basis for an informed judgement.
One thing that springs to mind is that if I have an existing BPM/ BPA tool which allows simulation, what further value can PTL add to this over and above my existing investment ?
As I mentioned earlier, simulation is only one of the methods we use at the Process TestLab. It all depends on what you want to achieve. If you simply want to simulate a process model for whatever reasons, you’re probably going to start with using the tools you already have available.
On the other hand, if you’re focussed on the risk and performance assessment of your processes or process scenarios, using a model won’t get you far, you will need to RUN the process to analyse and evaluate its behaviour – which is actually what companies do although involontarily: They design and implement the process to find out what it does. The Process TestLab creates that same realistic process with a simulated environment under lab conditions – only we’re doing it before the client has implemented a potentially flawed or inefficient process. This way, companies don’t have to use their customers as guinea pigs for process change and neither do they need to risk implementing a process that only might deliver to requirements.
So, what we do at the Process TestLab goes far beyond simulation. The other aspect of course is that the TestLab provides independent analysis. It’s not a tool, it’s not software and it’s not consultancy. We don’t tailor simulation runs to confirm the personal opinions or wishes of a project manager – we provide him with the facts, reliable and untainted. Finally, using the Process TestLab you’re really avoiding investing into additional tools and trainings by investing into process and project results.
Finally, can you tell me what the pricing model is for the TestLab service ? Is there a tiered structure, on a “per process validated” basis or another method of evaluating the cost v benefit I can take away with me ?
Let’s take the benefit issue first: Maybe you should ask a leading technology company how much money it cost them to put out a twitter-like service only to find out that their processes couldn’t handle the demand. Or ask companies whose customers are walking off to their competitors because well-intentioned processes simply didn’t deliver according to expectations. These are the obvious examples of where early – design-based – analysis and validation can help save money, time and last not least reputation. What makes these cases stand out is simply the public spotlight they’re under. But what happened to them happens in many businesses around the world.
So yes, there is a price tag attached to the Process TestLab services but it’s a lot cheaper than losing your customers or having to re-design and re-implement a process all over again – with the same level of uncertainty attached to it.
Let’s look at the numbers. In 2008 companies in the US and Europe spent in excess of euro 20bn on process reengineering and only 18% of the BPR projects were judged completely successful. Take this down to the senior management level of a single company and tell them that their latest process project stands only a 18% chance of success and they start to ask all the difficult questions ‘Have you checked your assumptions? Can you prove that this will work? What effect will this or that change have … and why?’ Addressing these issues on a manual basis, project costs will go through the roof and you’ll be tied down more months doing the calculations. We can do it better, faster and cheaper.
And to anyone asking whether these types of analysis should be done at all, the answer is simple: Core business processes make up for 40 percent of the costbase of the average enterprise.
So how can anyone not afford to look at the cause and effect of process change and try to get things right first time?