Successful companies change their processes more often
It must rank as one of the more popular myths that companies which seldom change their processes run a stable and successful ship. In reply to our question on how frequently companies change their processes, 44% responded with ‚at least once a year‘.  This number, while being surprisingly high in itself becomes even more significant when it’s put into the context of a companies market success: A full 63% of companies which change their processes at least once a year are more successful than their competitors from the same industry. This leads us to conclude that a high change frequency leads to a high level of process competency which in turn results in successful company performance.

>> Read on

Even though business process management still ranks as one of the leading topics for senior management (as it has for the past 10 years or so), the quality of the processes designed, implemented and operated does little to suggest that much attention is paid to delivering something that comes even close to the importance attached to it.

With just 4% of companies claiming that their processes are ready for operations once they leave the project phase and more than a third of companies having to invest substantial effort to re-work processes to turn them operational, it seems that a lot of the BPM initiatives are a far cry from anything that could be called successful.

Of course, all this is not from lack of trying: Many companies have invested in technology to support their processes, have created roles such as process managers, process owners and have even established some sort of process governance. Much is in fact being done and companies are continuing to invest heavily into BPM. Only it seems that more investment and technology are unrelated to the causes behind the lack of process quality.

Over the next few weeks we will look at some of the survey results in more detail on this blog. And despite the negative tone of this post let me assure you that the survey results also show some positives: There are clear indications which explain why companies which are more successful than the rest of the industry have achieved that status through their approaches to managing their processes -  from design to operations. So tune in again soon to find out more.

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.

• Nearly 50% of respondents say that they change their business processes at least once a year, with an additional 35% saying they do so on an event driven basis
• 2% of respondents say that processes delivered by projects require no further work and were ready for operations
• 73% of respondents say Cloud has no impact on their process strategy while 90% say the same of Adaptive Case Management
• 33% of respondents use no formal models during business process design

Note: All of the above comes from the raw data without any cross analysis and is based on the survey input received until last weekend.

Here’s your opportunity to benchmark your company against the overall results: Take the survey and once we’ve analysed all the data received we’ll supply you with a summary of the overall results and your individual input.

Survey website: www.q-in-bpm.org

Our team of enthusiastic students from the University of Applied Sciences Koblenz has already taken a look at the input they’ve collected so far and they’ve given us a quick update presentation this morning. I’ll probably do a write-up of the 4 or 5 biggest surprises as a teaser later today but let me tell you there are lots more from what I’ve seen so far.

So keep on sending us more input so that we can stabilize the results!

And as I know that our american readers always love a challenge: Canadian participation is higher than US participation. Are you going to settle for that?

Stay tuned for the teaser results!

“You do things so much better in Europe” Huh?

This posting has its origins in a LinkedIn discussion I had with Dick Lee a couple of years ago. As far as I can remember, Dick was at pains to point out that European companies were much more advanced in BPM than companies in the US. At the time I disagreed, pointing out the notable lack of uptake of BPM (in an organizational and/or technical sense) in Europe, the reluctance in particular of middle management to get involved with something that hasn’t produced a thousand success stories at the very least and could therefore be only regarded as a nice but untested concept and last but certainly not least the tendency to cling to process modelling as a way of saying ‘look, I’m already doing something with my processes, what more could you possibly want?’.

At the time I developed this picture in my mind of two ski jumpers standing at the top of the jump where the US jumper would at least make an attempt at jumping (proudly following the Eddie the Eagle example – British, I might add) whereas the European jumper would take off his skies to explore and take measurements of the hill to determine if jumping could actually be done without any danger to body and soul – and then taking the results home for closer study.

Fast forward to the present day (with lots of project and client related visits to different countries in-between) and I’ve come to the conclusion that Dick and I were both right – although for different reasons.

I’m just going to take a look at three areas for now: Uptake and scope, skill development and process awareness.

Uptake and scope
My impression is that companies in the US are quick to pick up on new topics, turning them into marketable ideas and then failing to follow through on them. One of the main reasons as far as I can make out is that BPM in US companies has two extreme positions and practically no middle ground: Processes are (and have been for a long time) a top management topic but as an abstract concept only. The other extreme is the business analyst and operational level: Lots of work in the trenches of daily business but so buried beneath methods and tools that it fails to get noticed. Accountability for processes? Nada. Process organisation? Nada. Middle management as the link between business strategy and processes? Doesn’t exist.

By contrast continental Europe prides itself on its wait and see approach (nastier minds than mine would call it complacency or even ignorance) with the consequence that once they do pick up on an idea someone’s bound to come in to tell them that it’s old hat and they should be looking at what’s new instead.

The other noticeable difference is with the scope of processes. End-to-end processes have always dominated European thinking. So the disappointment with many vendor strategies of ‘start small and grow later’ is understandable: Successfully implementing a highly automated employee self-service process to request a new desk or to put in your application for a business trip is really nothing more than a proof of concept when viewed against initial management expectations – in particular when they’ve spent nine to twelve months on a process to decide what BPM tool to use.

From the many conversations I’ve had, it looks as if this end-to-end thinking is regarded as nothing more than an abstract vision by many US companies. Quick wins, low hanging fruit, automation of a few small steps is the leading approach. Only…there are very few examples where a process fragment can actually deliver a ‘win’ that would lead management to think in bigger chunks.

Skill development
It has never ceased to surprise me how well US business analysts are trained. Formal certification is much more important in the US than it is in continental Europe. And while the content value of some of these certification courses is questionable, they do provide a basis for development. By contrast, many European business analysts I know are more or less self-trained, depending purely on project experience to increase their skills. This forces many of them to become deep-dive experts and losing contact with the world around them. Process model administrators, librarians of process maps is what we have plenty of, but this is clearly a case of administration beating content.

The second area where I feel more should be done concerns the actual management of processes. It shouldn’t come as a surprise to anyone that managing a process requires other (or at least additional) skill than managing a department. And those who are tasked with managing process have other information, IT and action requirements that need to be addressed for them to get the job done. In the words of a former Chief Process Officer of a large telecom provider “Don’t ask process managers to manage processes, they are simply not qualified for the job”.

Process awareness
This is where I believe both ‘cultures’ are equally weak. Ask people to describe the process they are working in and they will either tell you about their tasks and speculate on what might lie upstream and downstream from them or they will point to their desktop pc and explain how the system they’re using works. But being aware of the content and context of processes, of how processes interact, how processes behave and indeed how processes make up the business is not something we get to see often.

The most obvious sign to me that process awareness is underdeveloped is that processes are often confused with projects. While a project has a limited lifespan, business processes really only begin to exist once projects are finished. Hard to understand why we pay so much attention to creation and then forget about existence.

So, start with being Eddie the eagle, which is where I’m right, but keep the next level in sight and make sure you are able to get there – which is where Dick is right. 

Btw, the differences I’ve pointed out in this post not only reflect how successful (or not) companies are at managing processes, they may also go some way to explaining why vendors find it so hard to develop the right messages. You may like to check this recent blog post by Adam Deane and the resulting comments to understand the difficulties vendors can face when they try to sell a solution to a problem nobody really wants to be aware of – though everyone knows it exists.

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.

Get involved, let us know what your current situation and perspective on process quality is and take the survey: http://bit.ly/s3LaYO

Respondents will receive a free summary of results and can benchmark their answers against overall results.

Survey is conducted as a joint research project between the University of Applied Sciences Koblenz and the taraneon Process TestLab

Other than that, I still found time to listen to Kathleen Barret ‘On the future of business analytics’. Just one quick observation as I’ll be doing a separate piece on this later. There seems to be a fundamental difference in the role of business analysts between the US and Europe. What IIBA does with regards to qualification of business analysts but also role ‘marketing’ is not something I’ve encountered before on this level. Cultural? Maybe. On the other hand there seems to be a broader gap between what BAs could do and the willingness and capabilities of senior management to actually let them do their stuff than there is in Europe.

Oh yes … I also did the first formal presentation of the Process TestLab in the US. I was fortunate enough that Roger Burlton had the slot following me where he wanted to tell ‘Horror stories from business processes’. Being customer- or in this case attendee-focused I changed my presentation in a way that would help attendees avoid appearing on Rogers list next year. Accordingly I also changed the title of my presentation to ‘The Process TestLab: How to avoid being mentioned by Roger’. This may have caused some initial confusion for attendees but at least this way the Process TestLab has already provided some valuable help

I’ll point you to Column2 as Sandy has done an excellent write-up of the presentation itself on her blog and just mention that next week I’ll be posting about a couple of the slides and topics I had to skip over due to time pressures.

BBCCon11 in short: Great event, good speakers, good opportunity to swap and share experiences … glad I attended. And who knows, maybe I’ll even make it down to the beach next year.

Most remarkable sign of conference quality? On day 1 everyone was asking ‘How are you enjoying the event?’ By yesterday that had evolved to ‘Are you enjoying it as much as I am?’

Content? Visited some great session. The day presented a good opportunity to dive deeper into selected topics. Here the gist in no particular order:

James Taylor – he of decision management fame – made one decision before his presentation and that was to use no slides at all. So we had one hour of shared experiences on decisions rules. Thing that sticks to my mind: Tons of processes are not actually processes but decisions in disguise. James made a point of mentioning one case where he replaced 25 pages of Visio process documentation with just a couple of rules.

Listening to him made me wonder how many of our business analysts are really equipped to deal with processes AND rules and their interaction.

Sandy Kemsley led yet another panel yesterday, this time dealing with the relationship between business and IT architecture. From what I gathered from the panelists comments was that there’s no real formula for success and that is very much depends on the individual situation: If you’re fortunate enough to be able to start from scratch, start with the business architecture and develop everything else from there. If you’re dealing with an existing architecture, it might make sense for IT to take the initial lead. I particularly like the comment from Forrester analyst Jeff Scott that one of the main as yet unsolved issues is the tie-in from business strategy to business architecture.

Michael S Katz gave a very insightful presentation on ‘A cloud-based system provides timely cancer care information’. The very short version is that despite a whole range of available information on myeloma (or maybe because of it?) health care providers find it hard to keep up to date with current best practices of treatment. The International Myeloma Foundation has therefore developed an application which lets patients and doctors alike interpret and evaluate relevant data by entering data into the application where it is then set against certain rules which are based on the latest and most up-to-date research. The application then comes back to the user with information on how to interpret the clinical data. Note aside: While Michael was explaining the background to the system, I was wondering about issues like security of patient data. Michael picked up on this by mentioning that the one thing they had wanted to avoid at all cost was to have a solution that would need to store patient data, as in that case billions of regulatory requirements would set in. The neat solution they found was that the input data from the patient or person making the enquiry was stored of their local devices only.

I also sat in on the CDC presentation by Dr. David Lyalin and Warren Williams, which I found very interesting as they described how they developed, distributed and applied business rules and decision tables to track immunization. I admit I will have to re-read the handout material to fully understand why they went with rules and not processes but the ability to communicate rules and decision tables more easily than processes seemed to play a large part.

I also briefly spoke with Matthew Finley, the ‘Show Director’ for the event, discussing reasons why other BPM events were usually so bland. Not sure that it’s entirely down to culture, the ‘feel’ of an event and its accessibility also play a large part which seems entirely foreign to some event organisers.

Note of interest to european readers: Despite this being a very large conference, attendees used every available opportunity to ask questions. In fact the most interesting sessions grew out of the interaction between presenter and attendees. If you’re going to these events to learn something you’ve got to be prepared to ask questions.

If you want to know more about this days’ session, I suggest you pay a visit to Sandys Column2 blog. Having the dual advantage of knowing what she’s talking about and being a woman (multi-tasking), she can actually listen, understand, evaluate, write and post at the same time – and it all makes sense.