Process Cafe

7 Ways KPIs Can Make Your Process Worse

(Today's post is a guest post from Bernie Smith from madetomeasurekpis.co.uk. In it he lists seven ways in which the use of Key Performance Indicators can make your processes worse).

Most people nod vigorously and agree that KPIs and measures are a "good thing". Used sensibly they are, but many organisations are actively undermining their process improvement through the poor use of measures.

Here are some of the most common pitfalls and some ideas on how to tackle them.

1. KPIs that show you only part of the picture.

Even if your measures and KPIs are set up properly, you may be missing a big part of the picture giving a false sense of security - as they may not comprehensively cover the things you really care about. Some of the biggest process improvement opportunities come in the form of things that organisation may not even be aware are problematic. To find this type of opportunity you need a structured approach to mapping out the key drivers on the outcomes you are looking at (I use my Success Mapping approach, you could also use a modified version of TPM PM Analysis or derivative of the BSC approach)

2. KPIs that are WRONG

KPIs and measures can be wrong in a number of ways (and often several ways all at once!). They can be incorrectly defined (I've seen countless organisations define OEE incorrectly), there can be variable definitions within the same organisation, there can be spreadsheet arithmetic errors, and there can also be wide variations in the understanding of what those measures are showing.

The solution is simple, although it can be demanding: create a KPI database. This can be pretty simple (link to the checklist on my site: http://www.madetomeasurekpis.com/2011/post/tools_to_help/kpi-definition-checklist/) but it is key that there's one clear definition of each measure, with the issues and inaccuracies also recorded and maintained.

3. KPIs that drive the wrong employee behaviour

We have all been rushed off the phone by a call centre employee who is measured on AHT (average handling time) rather than something more meaningful (like total time to problem resolution). People generally behave rationally, it's often the measures that make then do odd things. One way to avoid this is to simply ask your team "What do you find yourself doing to make the numbers that doesn't feel right to you?".

4. KPIs that are out of date

There's an old joke about being able to produce a perfectly accurate 7 day weather forecast, only it takes 14 days to create. Often the analysis produced in organisations is too old to be enable effective decisions. This leads to one of two choices: stop producing the analysis or improve the KPI production process.

5. Sucking up valuable operational resource to produce them

I've worked with teams of 40 or 50, all dedicated to creating reports and dashboards. Some of the work will always require a human, but most won't. The first port of call should be looking to automate much of the tedious Excel legwork that seems to happen in most corporations. Next look at quick-to-implement BI tools like Qlickview and Tableau (there are a couple of first-look reviews http://www.madetomeasurekpis.com/2011/post/first-look-qlickview-10-data-visualisation-software/ and http://www.madetomeasurekpis.com/2011/post/review/first-look-tableau-6-1-data-visualisation-software/). In the long term a consolidated data warehouse can yield benefits, but has a high capital cost and can introduce as many problems as it solves.

6. KPIs as a management club to beat staff up

We've all seen it, measures being used as a club by aggressive managers. There really isn't a KPI fix here, it's all about addressing those behavioural issues with the managers and making it clear that KPIs are not an instrument of torture. But be certain that if you don't address this issue it will shatter peoples enthusiasm for measurement (and management).

7. Drowning process managers in detail - making sensible decisions impossible

Most humans can hold between 4 and 7 "chunks" of data in their mind at once, so how do they cope with 95 page "Risk and Compliance" reports. Put simply, they don't. In this situation they skim through, looking for exceptions and at their "pet" measures. Dashboard and report design is a big area, but this link http://www.madetomeasurekpis.com/2011/post/howto/how-to-build-a-brilliant-dashboard/ gives a few starting tips.

KPIs can be a great force for good, but if you fall into one, or more, of these traps you can miss out on much of the value they can deliver. For more practical advice on tackling some of these problems visit Bernie's site at www.madetomeasurekpis.com

About the author: Bernie has helped his clients deliver surprising levels of improvement across a wide range of industries over the past 15 years. His mission is to help clients with a repeatable, practical and jargon-free method for generating insightful and clear KPIs and management reports. He understands that most people don’t get excited by KPIs, but believes it’s a curable condition..

See related info below

Holiday Greetings from The Process Cafe

Wherever you are, and whatever your denomination, I would like to take the opportunity of thanking all my readers, subscribers, Twitter followers and Google+ circlers, and wishing you all the best for the New Year.

Thank you.
Gary

The System is not the Process. The Process is not the System

(In the style of Seth Godin)

It is well worth remembering that when you design a process it should be designed independently of the underlying system that will support it. That's what procedures are for.

Designing a process based on a specific piece of software means that when the software changes the process needs to change as well.

You don't want that.

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

All information is Copyright (C) G Comerford
See related info below

Levels of Detail.

I've spent a lot of the last month or so in process facilitation sessions with different departments of a specific company.

It's been a very interesting set of sessions. I've learned a lot of the particular business area (probably more than I really wanted to know), but I've also learned a lot about peoples attitude when it comes to the world of 'process'.

Let me see if this scenario rings true to any of my readers: (In the style of Adam Deane)

Me: So what I want to do is understand, at a high level, what are the main chunks of work you do from a process point of view
Attendee 1: Right, well, let's see. We produce the weekly TPM reports.
Me: OK. That's not a process, that's a deliverable. What's the process that produces that?
Attendee 1: I don't understand
Me: Producing the TPM reports is something that happens at the end of a particular process. What is that process.
Attendee 1 : It's the process to produce the TPM reports.
Me: Is that all you do?
Attendee 1: We send the TPM reports to management
Me: Prior to that?
Attendee: We run the programme to produce the TPM reports.
Me: Are those the only reports you run?
Attendee 2: Oh no. I run the quarterly QQZ report!
Me: So, what I'm hearing you say is that you have a process to 'Manage management reporting', and you both do that?
Attendee 1: Wait a minute. The TPM and the QQZ are different reports.
Me: And..?
Attendee 1: It's not the same process.
Attendee 2: Not the same process at all.
Me: Oh. So what's different?
Attendee 1: TPM reports are run off monthly.
Attendee 2: QQZ reports are run off quarterly.
Me: But other than that there are no differences?
Attendee 1: Oh yes, there are lots of differences. The TPM reports run off the transaction file and the QQZ reports run off the summary file.
Attendee 2: And I run the QQZ reports from menu 3, but the TPM reports are run from menu 1.
Me: But from a physical 'What is the process' point of view your process is basically 'Gather report data, produce reports, send to end user'?
Attendee 1: I send mine to different end users than she does.
Me: But you still send them to an end user?
Attendee 2: I send them to management
Me: But management do something with them?
Attendee 2: I don't know. I never asked..
Me: Right. So I think we defined a 'Manage management reporting' process at a high level. As we decompose that proccess we'll find differences specific to each report, but at a high level are we happy?
Attendee 1: Yes
Attendee 2: Yes
Me: So what else do you do?
Attendee 2: I update the system when somebody leaves
Me: Does that happen often?
Attendee 2: More often than you would imagine
Attendee 1: I update the system when somebody gets married. I change their marital status.
Me: Ok So I'm hearing that we have a 'Maintain employee data' process?
Attendee 2: But when they leave is different to when they get married. It's a different process.
Me: Is it?
Attendee 2: Oh yes. It uses completely different screens and different people approve it. It's completely different.
Me: So it's not a case of 'identify data to be modified. Modify data. Gain approval'?
Attendee 2: Er. Well.. yes. I suppose it is
Me: And is that what you do too?
Attendee 1: Yes. But using different scree--
Me: I understand the actual details are different, but is it fair to say you are performing the same basic process over a different set of data..?

(silence as this is digested)
Attendee 1: ...er.... Yes?

You can see where I'm going with this. People tend to get fixated at a very low level of detail when it comes to their processes. In fact, I would go as far as to say they're almost looking at procedures or work instructions in some cases.

The art of process mapping is to be able to roll that up to (or, indeed, drill down to it from) a high level. This gives the overall view of the business and helps to understand the touchpoints for other processes or functions. Sure, you can then start to drill down into the lower levels of detail and understand what and where things happen. At some point you'll decompose to the level where producing the TPM report is different to the QQZ report, or maintaining a marital status flag is different to maintaining an employment status flag. But at a higher level of detail this doesn't matter.

I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the 'whole level of detail' issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.

At the end of the day that's all you really need.... .

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

All information is Copyright (C) G Comerford
See related info below

When people don't understand controls.

I had an interesting situation occur today.

Recently I've been in discussion with an organisation who want me to do some work for them. As part of this, they set up a new e-mail account for me on their domain email system. I received the confirmation e-mail details from a third party supplier who deals with setting these things up for them. The third-party supplier had sent my username, e-mail, POP details, SMTP details, and other e-mail information to me, in an e-mail, in plain text. In addition, they had copied in two members of the third party and my potential future client contact. One of the third party addresses was a generic e-mail account for "IT Support".

So far, so straightforward.

Then I wrote back to the 3rd-party asking how can I change my e-mail password because it was sent in plain text to several people, most of whom I don't know and wouldn't trust. Their reply? "There is no way of changing your e-mail details. It's our policy." When I pointed out, from a process point of view, how much of a risk and liability this was, the organisation said that because theirs was a small business and everybody knew each other "it was okay".

Basically this organisation has now said to me (in not so many words) "We are setting up an email account for you. The password details are know to several members of the organisation, you can't change them and we're comfortable with that." The logical extension of this was that I personally now have no further accountability for anything sent from my e-mail account as I couldn't guarantee that I was the only person using it.

The next communication I received from this organisation was a note telling me they were terminating their agreement with me and we would no longer be working together.

Which I am actually quite pleased about.

Can you imagine the situation if something went out to a client under my e-mail account and it said something inaccurate, derogatory, racist, sexist, libelous, rude or illegal? The fact that it was under my name would immediately throw the finger of suspicion on me, whereas - in effect - anyone in the host company IT department could have sent it.

Of course my contact in the organisation was working on the basis that 'It won't happen because we trust each other', and I understand that. But trust in an organisation will last until an employee feels disgruntled, has been badly treated, or decides they no longer want to play by the rules. This increases dramatically when you bring in a third party IT service provider who has no vested interest in me as an individual.

All in all the situation was fraught with potential for disaster.

But it did bring up the bigger process question about controls. A process will only work well if it is controlled appropriately. This doesn't mean it needs lots and lots of checks and balances at all points, but it does need something in there to ensure that the actual outcome of a process is the same as the required outcome.

In audit terms this could be something such as segregation of duties (making sure no single role has too much power to be able to subvert the outcome), or appropriate authorisation (ensuring that there is more than one signature required on a check, for example). No single control will work for every step of a process, but taking an overall look at the process and understanding which are the key controls that are needed is one way of building integrity into the process itself.

How many of your processes have appropriate controls built in?

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

All information is Copyright (C) G Comerford
See related info below

Top Ten Tips for Business Process Projects

I recently read Jacob Ukelson's post: top 10 tips for integrating a start-up after an acquisition.

One thing that struck me about these top ten tips is that a lot of them apply equally validly to ensuring a BPM project is appropriately managed, and the resulting solution integrated into your enterprises.

Let's go through these and see:

Tip 1 - Make sure that someone is thinking about the day after. In M&A Jacob was referring to ensuring that the focus isn't just on the process of the integration but also on determining how things will run when the whole integration effort is finished. With BPM this is equally as important. Somebody who can ensure that the effort put in by the implementation teams is mirrored by the effort needed to ensure smooth running of new (or improved) processes on day one.

Tip 2, 3 & 4 - Communicate. Communicate. Communicate. As Jacob says, you can never communicate enough. This is equally as vital a comment when major change is happening to a department, a region, or an enterprise as a result of process implementation or modification. There will be fear, uncertainty and doubt on the part of the business. They will look at a lot of what is being done and consider that it is 'getting in the way' of allowing them to work. Appropriate communication will ensure they understand the importance of the BPM effort and their role in making it happen. This is also very important if there isn't a common language between implementation team and users.

Tip 5 - First do no harm This is an interesting tip because the definition of harm is very fluid depending on who you ask. If you are a dyed-in-the-wool long time employee who has worked in the same department for several years, has their own way of doing things and is comfortable with the work arounds, the short cuts and the omissions that can form part of your daily work, when someone comes in and want to replace these with a new, shiny process you will feel uncomfortable. You will see the possibility for control to get away from you and you will interpret this as 'harm'. But in the big scheme of things it is just old habits dying hard. But, likewise this applies to the BPM team who may come in with an attitude of "There is a big problem here so we need to ensure we do something to fix it". As a result they may ride rough shod over parts of the organisation before taking an opportunity to review what is the right way to do things rather than the quick way to do things. Do no harm!

Tip 6 - Get help. Thinking that process management is something that can be done in isolation, or can be done by someone with little knowledge of existing systems, departments and work, is likely to result in a failure. So ensure that the user base are involved in the process. Ensure that help is taken wherever it can be. After all, these people know their environment far better than you do. Make sure you use that knowledge whenever and wherever possible.

Tip 7 - Visit Early, Visit often. How many projects have you been in where the project team meet the implementation goal and then immediately transition off onto other projects leaving the newly implemented processes to work purely with the users? This is a recipe for disaster. Ensure you keep project team members in the loop. Keep up to date with how processes are running. Meet early and meet often!

Tip 8 - Remember that the company acquired is different than your own, with their own unique culture. Or - to put this into a BPM context - remember that the company having their processes implemented is not your own and that culture is the biggest thing you'll need to overcome to make your project successful.

Tips 9 & 10 - Make sure you remember why you did the transaction. Or - from a BPM point of view - remember why you have made process changes. It is easy to get lost in politics, budgets and the management of change in the user base. But being able to stand back and remember the situation as it was prior to the project starting is a great way of focusing people and helping them understand why you have made the changes you have.

Sure, not all the tips from Jacob's article translate neatly to a BPM context, but there are enough there to ensure that sooner or later a few of them will be relevant to the project you're currently working on.

How many of these do you recognise? Which ones are missing?

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

All information is Copyright (C) G Comerford
See related info below

Process Cafe

Pages

CATEGORIES

Free Publications

Blog Archive

7 Ways KPIs Can Make Your Process Worse

More reasons to document your 'As Is'

Holiday Greetings from The Process Cafe

The System is not the Process. The Process is not the System

Levels of Detail.

When people don't understand controls.

Top Ten Tips for Business Process Projects

Subscribers

Subscribe Now:

Process Articles in the news

Process Books at Amazon