Selling the process to the enterprise is the prerequisite for your solution even having a chance to solve the problem. The challenge is really to understand the imbalance you’re facing: The problem is there but your solution isn’t.

First question therefore: Who is your customer? Just as you have (hopefully) made sure that the process you designed is suited to the process customers’ requirements, your solution development process should also address the customer – in this case, the people you stand to profit from your solution. Note that I didn’t say ‘the people facing the problem’, because they are in many cases not the same people.

When it comes to ‘selling’ processes to the enterprise you need to look at two different sets of people with different motivations.

Let’s start with the easier of the two groups, the people facing the process problem on a daily basis. They need to be convinced that your solution will make life just that little bit easier for them without causing new problems in other areas of their work. What you need from them is acceptance and at least tacit support. Nothing more but certainly no less. With the recent surge in collaborative approaches and ‘Social BPM’, communicating with the process ground force will become easier to accomplish.

The second group – and this is where we turn to the hard sell – are the decision makers. We may shake our heads as much as we like but this group usually has a different main interest and a totally different perception of processes. They are (and maybe need to be) primarily interested in risk: Risk that KPIs of processes they are formally responsible for will reflect badly on them, risk that they have to share responsibility and also the risk, that any decision taken will be boycotted by their staff. What they are looking for is predictability and reliability.

Decision makers are also driven by the results of processes, whereas business analysts are usually focussed on the causes of good or bad results.

So now we have this situation where management may be unhappy with the results but at least they know what they are getting. It’s ‘the devil you know’ thing at work. And now there’s you holding up your process maps, trying to talk about the detailed flaws and causes of the present situation before outlining why changing this and that in the process will produce better results. See anything wrong with this picture? Still wondering why so many project results never see the light of day?

Also consider this: Among the many qualifications and skills a good business analyst needs, the ability to create a good abstraction of the real world must rank near the top of the list. That is YOUR skill and now you’re asking someone else with a different skillset and different qualifications not only to understand and appreciate your work but to promote it from concept to reality. Aren’t the bells of risk beginning to ring in your head too? They’re certainly ringing close to the decision makers ears. Frustrating, isn’t it?

One approach to solving this problem is to translate your abstraction of the solution into a scenery and language your customers understand. We do this by way of process validation and simulation. Creating a setting for management to experience the effects of your solution provides a much better chance of uptake than explaining your idea. No danger of interpretation, no danger of using the wrong buzzwords. Simply create a new (temporary) reality for your customers. Forget the causes, allow them to view the effects.

The Process TestLab has recently seen an increase in the number of process validation sessions which were run solely to allow decision makers to understand the impact and consequences of potential process solutions – without having to commit themselves to financing a sandbox environment. Reduced risk, reduced cost: higher chances of management buy-in and solution uptake.

Singing We are the champions under the shower may be an enjoyable experience for you but it won’t turn you into a mega-selling rock star. For that you need an audience willing to listen and to give you that much needed break. The Process TestLab can do the same for your process ambitions: You provide the content, we provide the stage – and then you have a real chance at process stardom.

My keywords are: Common sense, business value, processes and business rules, stakeholder participation, architecture and structure, skill development, process testing, capabilities.

Common sense
Technology plus the ever increasing number of available methodologies could be regarded as a complete or at least sufficient toolset to deal with any number of process issues companies are facing. In fact the opposite is true: Too many toys to play with distract from what should be done and only lead to confusion. Several speakers pointed out this danger and stressed the importance of applying common sense and a ‘back to the roots’ approach. The role of business analysts and process experts should not predominantly lie in developing new methods but in solving business problems and making use of opportunities.

Business value
Really the key issue of the conference and at least during the keynote sessions the most often used phrase was ‘business value’. Does what you do and how you do it create business value? How do you demonstrate added value before you implement your solutions? Many comments by business analysts indicated that this is an area they are most uncomfortable with and pointed out that their inability to reach stakeholders and management is partly due to not knowing how to communicate the business value of their proposals, i.e. making the leap from process design to a business proposition that captures the imagination of decision makers.

Processes and business rules
This is still one of the great challenges in that both fields have progressed over the last few years albeit mostly independent of each other. But when the application of rules invokes processes and processes contain rules, independence and isolation is not the order of the day. Business analysts need to get a better understanding of business rules and rules experts need to come out of hiding. If you want processes to work and deliver you need both in combination.

Stakeholder participation
This is a subject I’m currently writing a longer piece on, so I’ll keep it short here. Business analysis, process analysis and process design all need to serve a purpose or else they are reduced to meaningless fooling around with tools. The only way to provide meaning is by getting results taken up by the business and for that stakeholder involvement is critical. I witnessed a couple of discussions along the lines of ‘we need to get management to read and understand our process models’. Wrong! You as designers or analysis need to tell the business value story and ensure that the main points are covered by your design and solution. Embed them in context, provide meaning. You may well have the best intentions for your business at heart but if you’re unable to show how stakeholders and decisions makers will directly profit from your suggestions the business as a whole will never get to see what you dreamt up.

Architecture and structure
The sessions at the business architecture summit provide some good examples of how the business can benefit from structure but they also showed some of the practical difficulties: When setting out, do you create an empty structure and try to fill it later with process, data, service and information content? Or do you base your architecture on existing processes (data,….) and build it up from there? Does architecture provide a framework for a running business or should it work primarily as a guideline for projects? There are no right or wrong answers to these questions but you do need to make sure that you have a consistent approach.

Skill development
One of my pet subjects and bbccon11 has done nothing to tell me that we are anywhere close to the skill levels demanded by the issues we’re dealing with. True, proficiency in handling and using tools is at a higher level than 10 years ago and tools and methodologies have a much broader user and fan base nowadays. But being able to drive a car when you have no sense of direction is not the smart solution. Process and business awareness should be foremost on everyones mind. Train people in process thinking and not just in how use the latest user interface. Reduce the time needed to discover current processes by making people process- instead of system- aware.

Process testing
OK, so I’m biased as this was the topic of my presentation. Doesn’t make it less important though. If your processes contain errors that will prohibit implementation, IT will need to design workarounds which in turn will increase project costs which in turn will not put a smile on stakeholders faces. The same goes for processes which may work but don’t deliver. And even if they do, if stakeholders and other interested parties had a different understanding of the problem and solution at the outset, you will not have provided them with what they expected. Process quality has as much to do with delivering capabilities as with delivering to expectations. Validation may therefore be key to your success. Likewise process dynamics. At a rough guess, every second presentation mentioned ‘global markets’, ‘changing conditions’ and ‘agile ability’. Designing a business solution without validating it against a real-life dynamic environment (simulation and stress test) means that your design brings with it the risk of limited usability. Test and check before you implement was the message I tried to get across. Of course, that’s why we set up the Process TestLab in the first place.

Capabilities
This is what the conference was all about. What capabilities do companies need? (Luckily, I didn’t get to hear any general meaningless answers but often very individual, company-specific input). How do process capabilities feed into business capabilities? (Depends on what the business capabilities are and there’s that tiny problem of translating business strategy into process strategy). What skills and employee capabilities are needed? (see above).

Summary
A lot of the issues I’ve mentioned here do not require a general state of the art solution. There already are many (too many?) tools and methodologies available. The secret lies in being smart: Smart in deciding what you need and how to create a solution using what’s already available. Smart integration. Smart processes that people want to use. Smart solutions that can be managed. We already have most of what we need but it takes brains to figure out the smart combination for smart businesses.

Basically here’s what you can expect to hear during our presentation “Improving Process Quality: Sharing Insights from the Process TestLab”:

• A short introduction to process quality
• Four approaches to improve process quality
  • Identification of process defects – When things can‘t work
  • Process validation – Experience your process design
  • Process simulation – Benchmarking models against reality
  • Process stress tests – Getting to know the limits before you reach them
• Three case studies from Process TestLab clients
  • Telecommunication client:
    Error analysis in business requirement processes
  • Health Care client:
    Validating new HR processes before implementation
  • Public Sector client:
    Reengineer processes or change resource allocation?
• The business case for process quality

If you’re interested in learning how to avoid unnecessary change requests to processes, lower process risks and determine beforehand the limitations of your processes, we hope to see you on Thursday, Nov. 3rd, 11:30am to 12:30pm in Room Diplomat 1 at the conference site.

]]> http://taraneon.de/blog/2011/10/22/preview-to-our-bbc-presentation-on-process-quality/feed/ 0 http://taraneon.de/blog/2011/10/17/thank-you-adam/#comments Mon, 17 Oct 2011 12:37:38 +0000 Thomas J. Olbrich http://taraneon.de/blog/2011/10/17/thank-you-adam/ Comments to blog posts tend to get overlooked and to be honest, our posts don’t tend to invite people to leave notes. But as the following comment from Adam Deane was particularly nice, I thought it deserved a complete entry on its own:

Congrats on the new website. […] If you can test and analyse your business processes even before they are implemented, you have found the real silver bullet.

Thank you Adam!

www.processtestlab.com

The Process TestLab has a new home on the web. Following the successful launch of the german language site, we have now completed phase 1 of the english language site.

What you will currently find at the new Process TestLab site:

• Background information on process quality
• Descriptions of our testing procedures, incl. defect identification, process validation, simulation and stresstest
• Examples of how clients use the Process TestLab
• Explanations of the various benefits of process testing, incl. risk and cost reduction, increased process acceptance and uptake, improved implementation quality, reduced number of change requests …
• Links and downloads

In the run up to the Business Process Forum in Fort Lauderdale we’ve also included a form to let you put questions to us, which we will try to answer during our Process TestLab presentation.

DANGER: This process can seriously damage your wealth

I’ve always had this a vague picture in my mind of an analogy between wearing a seatbelt while driving and using process testing methods during projects. So I took a quick look at some stats and here’s what I found:

In Germany we have around 7.8 car accident fatalities per billion kilometres travelled. With an average driving distance of 10000 kilometres per year and driver, this translates into 100.000 drivers of whom 7.8 come to a sad ending. That’s 0.0078%. I’ve also recently read that without seatbelts alone (that’s discounting airbags and other safety measures) the fatality rate would have been 30 times higher, which would increase the rate to 0.234%. So, anything that helps us reduce the danger of injury (or worse) even in the highly unlikely case of an accident is generally accepted and we are fortunately seeing a continuous development of safety measures which will hopefully reduce the numbers even further.

The reason I mention this is that there are two important aspects to look at:

• Accident prevention and
• Reduction of the consequences of accidents

I’d think that nobody would dispute the sense in addressing both aspects.

Changing the subject completely (or so you’d think), we know that 82% of all process initiatives fail to reach their targets.

In many cases, the causes are located in design phase: Errors in process logic that prohibit implementation, workable but inefficient processes that lead to constant change requests long after the processes have been put into operations and the curious realisation that somehow reality always refuses to conform to project assumptions and process models.

This begs the question of what could be done. Well, most of us buckle up BEFORE we take to the road and not AFTER we’ve reached our destination. So why do we only test our processes only after we’ve implemented them and even then leave the final testing to our customers (always assuming you even get to that stage)?

This is of course what the Process TestLab is all about: Providing you with an independent assessment of the quality and risks associated with your process design. Will they work? How will they work? What happens if …?

Buckle up your processes!

Image by Juan de Dios Santander Vela

Deutsche Bahn, the german railway and network company, has just provided a great example of how to mend a small fracture by applying a sledgehammer and then describing the resulting hole in the wall a successful application of modern house insulation techniques – a breath of fresh air so to speak.

The background to this unbelievable story: Twice this year, a high speed train, the ICE, failed to stop at Wolfsburg, home of VW. Passengers then had to get off at the next regular stop and were shuttled back to Wolfsburg by bus. Initial comments by Deutsche Bahn blamed the train drivers. The Deutsche Bahn marketing department sought to make the best of the situation by providing free tickets to train drivers to see VFL Wolfsburg, the 2009 german Bundesliga champions, in order to make them more aware of Wolfsburg. Plus of course a lot of the usual ‘won’t happen again’, ‘once – sorry, twice – in a lifetime occurrence only’, ‘train drivers are only human you know’ and ‘Deutsche Bahn loves Wolfsburg’ stuff in the press.

Last week, yes, you’ve guessed it, it happened again. I for one was certainly surprised to find that a ticket to a soccer match does not provide enough braking power to get a train to stop. Of course, using our unique Process TestLab approach I immediately set about throwing a piece of paper on the road … but while this got me some funny looks from my neighbours, it did little to actually bring a single car to a halt. Then I had a stroke of pure genius: I devised something I’m tempted to call a timetable, listing all the stops, their duration plus the exact hour and minutes when to enter and leave a train station. Not only might this timetable be used by train drivers, it could even – hold on tight to your seats – be used to replace the work of fiction currently on offer for passengers.

But maybe this is still a bit too futuristic for some. Instead, Deutsche Bahn has now issued the following decree to all train drivers: Whatever you do and even if you’re not meant to stop at Wolfsburg, stop anyway. So the non-stop train from Hamburg to Berlin (if there were such a thing) would now be a non-stop train with a stop at Wolfsburg.

I have no idea what this will do to the punctuality-drive recently announced by Deutsche Bahn, personally I’d much rather have a train stop when and only when it’s supposed to.

Of course, there are two positive aspects to this: Wolfsburg could now easily become the city boasting the highest number to high speed train stops in Germany and passengers no longer need to ask if a particular train heading in the general direction of Wolfsburg will stop there – all trains stop at Wolfsburg.

Btw, Deutsche Bahn has now identified the root cause of the problem – a mistake in the electronic timetable (huh?). So this story serves as a simple reminder that a problem in one process may lead to unforeseen consequences in other processes. The analysis of impacts of one process on other processes is of course something we pride ourselves on at the Process TestLab, so much so that we spend a lot on time on train journeys, travelling to meet clients. Although travelling to Wolfsburg I’ll probably use my car.

Update: I’ve been reminded that despite all attempts to standardize processes, Wolfsburg has not been made a mandatory stop for passengers travelling from Guildford to London in the UK. But should the list of (planned) stops take you from Cobham to Oxshot to Claygate to Wolfsburg to Hinchely Wood and on to Waterloo Station, at least make sure that you get a stop over receipt in Wolfsburg. Somehow I doubt that compensation claims for an undocumented 2.000km detour are covered by normal compensation processes.

Illustration by Dimitry Klimenko

We’re very much looking forward to this years Business Process Forum taking place in Ft. Lauderdale on Oct.30 – Nov.4. With more than 1000 attendees and a great list of presenters and sessions on the agenda, the event promises to be something special.

Thomas will be presenting case studies and results from the Process TestLab. In keeping with recent presentations you can be assured of a couple of surprises  in his presentation. Thomas will also be available for 1 on 1 talks on process testing, process validation and simulation over the course of the conference.

We’ve created a short form on the Process TestLab website on which you can put your questions to us before the conference. We’ll try to cover as many of your questions as we can during our presentation.

I, the customer, hereby promise that I will never change my mind once I have placed the burden of delivery on my supplier. So help me God.

Customer integration, Outside-In, consumer-orientation, social BPM … the list of terms describing the shift from process silo thinking to a more inclusive approach is as long as the list of companies proclaiming that their customers have always been the centre of their universe.

Slight hesitation. Does that mean that the whole company is turning around the axis called customer or do they just mean the place where they left the customer dead and buried?

Imagine a simple order handling process in which an incoming customer order is first checked and the required product or service is then created in a number of steps before the result is shipped to the customer. Nothing fancy and nothing special.

When our clients validate this sort of process in the Process TestLab they usually do so to check if the process will deliver the desired result and how a process model would translate into a live process.

If the validation run leads to the intended result and the process steps/tasks used are logical and more or less aligned there’s an immediate temptation to sign off on the process. It works, it performs, what more do we need to do? And as the process was initiated by a customer order and the customer gets what he ordered it must be a customer-centric process. QED?

This is where we’ve recently added a little something to the validation scenarios: An unexpected customer change request that comes in while the original order is being processed. In 8 times out of 10 we observe the following:

First it’s consternation: Can’t be done, this sort of customer behaviour has not been provided for in the process.

Then the discussion leads to two possible solutions: Either cancel the original order and ask the customer to create a new one, or go ahead with the original order and tell the customer that he should have made up his mind before starting the process.

It’s at this stage that experience takes over: A clever employee will bypass the process to accommondate the customer. The result? A happy customer, a happy employee AND a lot of undocumented activities, no audit trail, possibly a failure to follow governance and compliance rules. To put it bluntly: You’ve worked outside the rules of your company. Do it once, it may be regarded as a heroic one-off exception and be tolerated, but do it more often (and successfully) you have in fact created an unmanaged, uncontrolled and unauthorized set of shadow processes.

The bottom line is that technically and logically in this example these change requests could be fulfilled. It is only the process design that limits the agility and flexibility that is essentially available.  In other words, the process is incomplete as it doesn’t take the dynamic behaviour of the customer into account. The customer – more often than not – is something we see stuck at the beginning and at the end of a process, totally ignoring the fact that not only we as vendors or suppliers have processes but that customers do as well.

So, when you check your processes, don’t only look at the business logic and process objectives but also ask yourselves if your static process models allow for dynamic behaviour. If you’re planning to provide quality processes, never forget that quality customers are usually alive.

“As Niel Nickolaisen says at SearchCIO, The best BPM implementations focus on keeping things simple, "My ‘fix processes before implementing technology’ attitude has influenced how I view such things as BPM systems." So do you think processes should be fixed before implementing a BPM system?”

Here’s what I wrote in my response:

Fixing processes comes in two parts. One deals with logical errors in the sense of processes or parts of them not working, not delivering the required results or functionalities. The other aspect deals with the improvement of existing and basically usable processes.

What we tend to see is that broken or unusable processes are fixed to the extent that they can be implemented. Curiously, this usually comes under the headline of business process improvement even though you’re not really improving the business process but only making the BPMS deployable.

The downside is that (technical) BPMS restrictions either lead to a change in the minimally repaired business processes (resulting in BPMS being blamed for performing below expectations) or in perpetuating the quick-fixes.

Unfortunately [and contrary to the expectations the BPMS industry has created], we are still unable to conduct the process equivalent of open heart surgery. Once implemented, most processes have a smaller change and update rate than processes not tied to a system. This may in part be down to the BPMS but it’s also down to the mindset and methodology employed.

In practice, most still regard the ‘process’ from design to implementation as a one way street with a definite and defined ending: The release of the BPMS supported process.

Were you to regard it as a life CYCLE and continuous task instead you could probably improve/fix a lot of process aspects after an initial implementation.

But again, looking at real life what we see is that the technical aspects (need a new button, can you change the layout of the screen) are changed and tend to get confused with the business process requirements.

The long and short of it all is that the garbage-in garbage-out argument may in some cases be valid and in others less so. This unpredictable state requires a thorough assessment of the risks and consequences involved in fixing problems before or after process implementation.

While I was putting down my thoughts other replies flooded in, creating a very interesting discussion that might get you to re-think how to approach process improvement and automation projects.

As this issue is something we deal with on a daily basis, why not pop over to the Process TestLab website to find out more on how you can improve the quality of your processes prior to implementation.