Selfishness and Process.

Back in the mists of time I used to have a valid private pilots licence (PPL). One of the things I wanted to do was get a share of an aircraft so I could increase my flying hours and learn more about this great pastime of flying. I inquired at the local airport and found a great little plane that was within my price range at the time.

But when I looked into the small print of the costs there appeared to be something which - at first - struck me as strange, but than raised a red flag.

As a bit of background: when using a plane there is always a cost involved. This cost varies depending on whether you own a piece of the plane or are borrowing it without an equity involvement. But regardless of whether you are, or are not, there is always the cost of fuel that needs to be factored in. In many cases you take the plane, use it for however long you want and then fill it up when finished, at your own cost. In some instances you can fill it up on a company account and it gets charged to your costs or - and this was the case with the plane I was looking at - you were charged a fixed amount per hour for fuel, regardless of what you used.

The problem with this was the behaviours it promoted. Imagine the situation: regardless of how fast or how far you fly, you are going to be charged a set amount of money for fuel. This was not an insignificant amount either. It equated to 55 litres of fuel per hour for a single engine Cessna. (That's pretty much the same amount of fuel as my road car uses in about 8 days - and aviation fuel is more expensive). So in that situation, would you take it easy with the plane? Would you lean the fuel mixture to be as conservative as possible? Or would you just slam those throttles open and scream across the sky as fast as you could and as inefficiently as you could? Human nature would expect us to do the latter rather than the former. After all if there are ten people renting this plane in a week and they are all paying the same amount per hour, why should you be the one who only uses 75% as much fuel as them but still gets charged for 100%?

There was a knock on effect of this, too. The amount per hour was calculated on the average fuel usage that the owners of the plane were being charged. (They paid for all the fuel themselves and offset it against the hourly fuel rate). But the rate they set was based on current behaviour rather than future expected behaviour. Which means that after a few months of running at the new fuel amount (55 litres per hour), they discovered that they were actually paying for 70 litres per hour of usage (for example). Therefore the owners were losing out on this deal. So what did they do? That's right, the increased the hourly fuel charge to 75 litres regardless of actual usage.

Can you see how this would then become a bit of a problem? The upshot was that a lot of the guys who were renting the plane found that the fuel cost became prohibitive (even though they were using that much fuel per hour), and stopped flying. The owners then started to lose out on the rental charges for the plane. When it came to doing routine maintenance such as replacing the engine or the propellor, they found they had to stump up the money from their own pockets.

As I thought about this today I realised that there is a lesson in there from a process point of view. The process that was being initiated had measures or metrics that were - effectively - Key Performance Indicators for the whole process. They determined the efficacy of the process (after all, if the plane was using more than 55 litres of fuel per hour then the ROI on the process was reduced). But what had happened to this process was that it had become driven by the KPI rather than measured by the KPI. This was an occasion when the adage "What gets measured gets rewarded" did not apply. Quite the opposite intact.

The process had been designed with a flaw in it. The measure was inappropriate for the process. A more correct measure would have been to remove the fixed cost per hour and replace it with a variable cost based on actual usage. This added a small administrative burden to the billing process, but resulted in more flexible (and better run) flights, where the fuel usage wasn't excessive.

It might be worth having a look around your current process and seeing if there is anything in there which is working in a counterintuitive way. Do you have any process steps that are time dependent and allow a larger amount of time than is needed? Could you cut down that time to enforce the right behaviours of efficiency and speed? Could you organise your workflow in such a way that you are not encouraging unwanted behaviours from the participants.

You might be surprised at what you can change.

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

Shadow IT - Good or Bad?

In a recent post about ‘shadow processes’ I mentioned how they are apt to be a result - in some cases - of departments running their own IT functions to try and bypass the inefficiencies of the proper IT department.
Well, the Harvard Business a review has published an article on Shadow IT and it hits the nail on the head quite succinctly in this regard.

If I may quote the opening passage as an example: Five years ago, “shadow IT” efforts were the dirty little secret of organizations. An impatient marketing or finance manager would, on the sly, secure some extra budget money and hire a contractor to build a little database that tracked mailing addresses or top-line financials. Slowly but surely, as the little database grew bigger and bigger, the manager would wedge the cost into her operating budget. Other managers might take notice and started building their own databases.

To my mind this encapsulates the key problem with IT departments in the business. They are not responsive enough to the needs of the end users.

Of course there are numerous reasons why this can be so:

The need to a manage and maintain existing legacy systems
The need to appropriately manage funding by prioritising the most important requirements.
Long lead times of larger projects diverting resources from being more responsive

These are just a few of the reasons that shadow IT functions exist.
But the most telling item in the HBR article relates to the concept of ‘departmental IT’. What they are saying is that shadow IT has now come into the open, been acknowledged by the business as viable and valuable to the end user community, and is being named as a separate function within the business.

Does anyone else feel as worried about this as I do?

The Big Issue

“But why shouldn’t the departments have their own IT function if the central IT function isn’t providing what they need?” you may ask.

There are numerous reasons but let me just pick on a couple of key ones.

Legacy maintenance. I once worked on a project which was tasked with identifying all the systems that needed to be replaced by a single ERP implementation worldwide. It took the project team about fifteen minutes to identify the centralised, IT-managed, legacy systems that were in place across the 40 affiliates worldwide. It took another six months, and many thousands of dollars, to identify all the local shadow IT implementations of Access databases, Excel spreadsheets and local portals that had spring up in the local affiliates. It also added a considerable amount of time, effort and money to the ERP project to understand and replace these with functionality in the implementation. This is the Enterprise Architecture issue.
Processes. By definition if you have implemented some sort of shadow IT system in your business then you will have modified, updated, or created some process to include the usage of the resulting IT system. This process will - by definition - not be part of your centralised process world. It will not be audited properly and it may not be the best way of doing the work.

So looking at these two items, it becomes apparent that shadow IT as a concept is not something that should be encouraged.

However, if I am a salesman out in the business trying to sell something to end customers and that lack of IT support for my needs is becoming a hindrance, I can fully understand how it is that I might try and put some sort of Shadow IT function in place to help me achieve my goal. Unfortunately while is will solve a short term goal it will create longer term problems.

In my book The Perfect Process Project, I talk about having a single owner for a process across the enterprise. The reason I say that is because having multiple owners will result in process changes that optimise the process for a specific section but sub optimise it for the whole process. If your purchase-to-pay process cuts across procurement, Accounts Payable and General Ledger, each one of these will try and optimise the process to make their life easier whilst not being cognisant of the effect such optimisation might have on the other parts of the process. Such sub-optimisation across the process will result in lower efficiencies and - hence - higher costs.

Shadow IT suffers from the same problem. You may - as a local sales manager - be optimising your IT functions to best leverage your budget and increase your sales, but any increased profits you are raising as a result of this, will likely be absorbed into the increased infrastructure and maintenance costs of having that unauthorised IT implementation there. This may not manifest itself until someone comes to upgrade or replace your systems (as in the above example), but it will always be there.

The Solution

So how do we deal with this issue? Human nature is going to keep causing people to do their own thing in order to try and improve their own situation. The key is education and reinforcement.
If you can make an affiliate or department head accountable for the increased costs as a result of shadow IT (or sub optimised, local processes), rewarding him or her for staying as close as possible to the company line, then human behaviour will be influenced by the reward system. Good managers get paid better than bad managers,
But the flip side of this is that you also need a mechanism whereby the local managers must have a way of highlighting local needs that are not being dealt with by a central solution. This is applicable to both shadow IT and localised processes. There has to be a prioritisation process to decide where scarce IT budgets are going to be focused. If the money doesn’t go your way, the incentive to not do it yourself is managed by the reward system for aligning with centralised directives.

Summary

Nobody wants to have inefficient systems and processes in place. Everyone wants to be set up in the best possible way to allow them to succeed. But sometimes the success of the overall entity must take precedence over the success of the constituent parts.

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

Dark processes and the implication for your business

Jim Sinur recently posted a piece which discussed Dark Processes. These are the unofficial processes used to deliver results that are not visible to management. Jim mentions that there are a number of ways Dark Processes (or Shadow Processes) come into being, these being - for example - when a variation is needed in a process that has no flex, or when an IT limitation inhibits the ability of a process to work as required or - my personal favourite - because Old Habits Die Hard. I wrote something akin to this a few years ago when talking about “The Way Its Always Been Done”.

Jim finishes up his piece by saying

“Dark processes are here to stay. Let’s not fear them, but reduce the number of opportunities to create and feed them for no good reason. Intelligent business operations allows for intelligence built into processes to reduce the need for dark processes.”

I couldn’t agree more.

What does this mean?

But lets have a look, for a moment, about what these dark processes mean for your business, shall we?

If you have a process which is inflexible enough to deal with variation, or where IT inadequacies have put some sort of constriction on the ability of people to do their job, you will get a shadow process building up. I have encountered these in many, many organisations.
If you have a finance department that uses Excel as a means of creating management information using data imported from your ERP and ‘manipulated’, than you have a shadow process.
If you have employees keeping paper records of transactions with customers because the customer wants something that the system can’t appropriately handle, you have shadow processes.

The existence of shadow process do - in themselves - indicate some sort of underlying issue that needs to be dealt with. Why is an employee having to record transaction off the books to assist a customer? Why are the finance department recording different figures for MI than are shown on the system?
Sometimes the issue is simple. In the case of Finance it could be that they are taking figures from several systems and using Excel to amalgamate and ‘pretty them up’. But sometimes there is a deeper-seated underlying reason.

I worked at one organisation that took centrally affiliated reporting criteria and ‘massaged’ the figures each month in Excel prior to submitting them to corporate for review. The reason was that they were accounting for things in a none standard way and knew that taking the figures directly from the system would show them as having sold less than they actually had. Rather than change the way they accounted for things they decided to alter the figures instead. This resulted in a shadow process which allowed them to do what they needed. The issue came to a head when I implemented a new financial system that allowed all figures to be queried centrally without the affiliate themselves doing any manipulation of the data. That particular shadow process didn’t last long.

How do you remove them?

But overall a shadow process needs to be identified and the underlying cause removed. But how do you do this?

As Jim himself says:

Intelligent business operations allows for intelligence built into processes to reduce the need for dark processes

What this means, in my opinion, is that when new processes are put in, adding a sensible amount of intelligence into the processes will reduce the scope for a dark process to appear. But this doesn’t remove the existing ones that we haven’t found yet.

Identification of a dark process is - by definition - quite difficult. If you knew the dark process existed you would try and stop it (or understand why it exists).

One solution is the one listed above: replace their process with another one and see what breaks. That’s a little radical for my liking (but very effective)

Another slightly less radical way of doing this is to put someone new into the role and ask them to report back to you with their impressions of what happens. You can compare that with what should happen (You do have documented your processes, right?) and identify the discrepancies. But this isn’t always the best thing to do. Employees get distrustful when you suddenly introduce someone new to the company, and rightfully so in this case.

No, the easiest way to identify a shadow process is to go, systematically through your existing processes and document them appropriately. That way you will understand what the employees are actually doing rather than what they think they are doing.

I facetiously asked earlier in this post “You have documented your processes, right?”. In actual fact this appears to be a key factor in understanding where dark processes occur. Get your users into a room, start to ask them what they do. Work through the details until you understand the points at which the current process breaks down. Sure, it'll take a while, and probably cost you a fair amount of money. But compare that with the amount of money you're losing by having the processes there in the first pace and you'll understand the importance of doing this.

Summary

We know they're there. We know they're happening. Understand that they happenmand understand why they happen. If you can life with that, fair enough, go ahead and do what you do. But if you think the dark processes are costing you time and money (and they almost certainly are) then you need to start looking in detail at where they occur and trying to stop them.
It's the only sane thing to do.

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

Who's your vendor? And why?

New BPM systems

Everybody sees them. Everybody knows about them. It seems that a week doesn’t go by without some new system coming to market.

So the dilemma which exists for a prospective purchaser of these systems is “How do I differentiate between all these systems?”. In previous posts I’ve looked at some of the criteria that are used for selecting these tools, but at a more macro level I’m interested in understanding what it is about one software company that will encourage you to work with them over a software company which has a broadly similar offering?

As an example: If I worked in the sales department of a major multinational and I needed a CRM tool, there are a number of tools I could use that are on the market. Some are stronger in one area relative to another, but overall they are very similar in what they do and how they do it. Price is always a factor when it comes to software packages, but as the size of the company increases, the price factor lessens (after all you’re going to be spending millions on the project it doesn’t really matter if it costs £1000 per seat or £2500 per seat). So what is it that I would look for in a company that I am going to work with on a large project such as a BPM implementation?

Possible options

Is it the size of the company itself? Would you work with a smaller company if it could convince you that it was more agile and responsive to your needs?
Is it the track record of the company? Does it need to have had many similar implementations with companies your size before you will even look at it? If this is the case, how is the company meant to get started with doing this as it appears to be a Catch 22?
Is it the people you deal with? Mostly - when looking at software tools - you end up dealing with sales people or folks from the marketing or pre-sales team. They are trained to be polite and helpful, and in many cases will promise things that in reality might be difficult to provide. They are usually very pleasant people but they aren’t going to be the ones your project is dealing with after the contract is signed.
Is it case studies? Do you look for organisations that can provide case studies which align with the kind of things you are looking to do by implementing your software package or finishing your project?
Is it references? Do you try and speak to other companies that have implemented this tool? Does it matter if a company cannot produce these references?
Is it accolades from research organisations such as The Gartner Group or Forrester? Lots of organisations subscribe to research provided by groups such as this and they provide “Magic Quadrants” and “Wave” diagrams which identify the top vendors in particular market areas. How much influence does this have on your thinking?

Summary

I’m very interested to understand what it is that helps influence a project to decide on a particular software vendor. Any of your thoughts would be greatly appreciated.

The BPM Project - What's next?

It seems in the world of BPM that we end up with something cool and new every so often, or some major software update/release on a regular basis and yet - despite the best efforts of many people - I don't think anyone has solved the undying problem of getting BPM into the organisation at the right level

I've talked in the past about BPM by stealth, where I have implemented BPM at a low level in the organisation as a means of seeding the capability in the business. This can then lead to growth at a larger level. The downside to doing that is that we end up with BPM being implemented in several smaller “bottom-up” implementations. These are better than nothing, but can lead to silo mentality in the organisation. Ideally we would enter the business at the top level of Management and get buy-in and sign-off at the board level to implement across the organisation. Obviously this is a major nut to crack when trying to put forward the Tao of BPM, but I believe it is one thing that is absolutely vital to happen

The problem is that the benefits of BPM at this level are not always obvious. The work involved in documenting and managing a whole enterprises process is huge. It is, without doubt though, the best approach to take. This can be either with an outside-in approach or an inside-out approach (and the merits of each of these are discussed endlessly across the BPM world). But holistically the benefit to the organisation has to come from integrating and managing the whole of the business, not just small silos.

The problem is that the huge amount of work involved in doing this is something that the top level of management will often baulk at approving. Because, despite the amount of work and effort that we in the BPM community have put in to promoting the benefits of our product, there is still an approach held by many vendors that implementing the software solution is the aim of BPM. This means that the focus is on the nuts-and-bolts of BPM/BPMS systems rather than the holistic approach of ensuring the best thing is being done for the business.

And I can understand why. When the CIO looks to the project manager to see how the project is progressing he’s going to want to see metrics reflecting the successful implementation of licences or affiliates/sites to a particular software tool. After all, nobody ever got promoted from project manager because the project they had for implementing an ERP system successfully reviewed how six affiliates could improve their cash-flow. They got promoted because they actually improved the cash-flow and implemented something to make sure this happened (usually a piece of software).

The same thing happens in BPM. Projects are deemed to be successful not because somebody was able to improve a process (even though that is the end result of the work), but because a piece of software was implemented and the users are using it.

I worked for an American multi-national organisation for some years and they replaced their ERP system with a competitors tool. The competitors tool was no better than the one they had in places already (in fact in some respects it was worse). After several years of work the global organisation had created ancillary processes and work abounds to deal with the fact that the required software didn't work. Overall the project was a waste of a large amount of money and the benefits were never going to be materialised. BUT, the software had been implemented successfully across the globe and the project was deemed a success. We can argue for days about the relative merits of different pieces of software and whether the project should have been approved at all, but this doesn't change the fact that the negative aspects of the implementation (frustration, need for work around, user dissatisfaction etc) we're outweighed at the senior management level by the fact that software had been successfully implemented. This was despite the fact that the company was (allegedly) spending over $100,000 per week on external consultants to do this.

I was in meetings recently with a software vendor and we were discussing the barriers that they were hitting when trying to get their software into various businesses. It fell very neatly into the points that I have raised here in this post, namely: We want to get in at the top but were being forced in at the bottom level

So how do we get the business to understand that BPM as a capability is an enterprise-wide requirement rather than a project specific need? How do we get the CIO to sign-off on implementing BPM across the organisation rather than approving just a project to implement software?

It's the million dollar question (quite literally).

Here's my solution: We don't.

This is like the old eastern saying “How do you eat an elephant? One piece at a time”. We can't go around trying to push the CIO’s into doing what we want, anymore than they can push their boards into doing what they want. There is always a cost/benefit that needs to come with projects like these. This is the reason the software implementations are always looked at from a deliverables point of view. Tangibles are the thing that the CIO will be looking at. A process is not a tangible thing that an be seen and held for inspection (although some would say that a process diagram is a tangible, and I accept that).

The simple fact of the matter is that I don't think the software vendors are doing a good enough job of selling BPM as a concept to C-level management. They seem to think that showing an expense claim process with the appropriate approvals and routing will convince a CxO to spend a fortune on putting such a thing into their organisation. It won't. What the vendors and the consultants - and I include myself in that group - need to do is to position the capability of BPM as a prerequisite to implementing a tool or solution. They need to be able to enumerate the tangible benefits to having a good BPM capability in an organisation, and they need to be able to show good case studies about where this has happened and what the benefits were. A good case study is not a vendor-provided example of where their software has caused a company to become mildly excited about the potential. A good case study is independent, non-vendor specific, and covers more than just the software solution.

Only then will we be able to go to the CIO (Or any other member of the board) and show them why they need to be looking seriously at BPM.

Or am I completely off-base?

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

On Choosing a Vendor

We've spoken before about the criteria companies use to chose a BPM vendor, but I want to revisit this in light of conversations I've been having recently with vendors.

The fact of the matter is that there are a large number of vendors on the market with products that are not differentiated to any great extent from the others on the market (no names, as that is not the point of this post).

Sure, they have the odd bell or whistle that might be useful to one organisation (or part of an organisation), so the differentiator is not in the software itself.

So what is it that a company will/should look for when looking at vendors where the product itself is not a differentiator.

As examples I've spoken to vendors who cite their excellent after-sales service as a differentiator. Also vendors who use the fact that they are small and responsive as a great selling point. Others point to their training offerings, Gartner approbation and other things as reasons why you would want to look at them rather than the competition.

Of course price will certainly be a differentiator for many companies. If your product costs peanuts (The 'Microsoft Visio' approach), you can put thousands of copies into an organisation and use other means to get your main income (consulting, training etc). On the other hand if you are selling a product that has a substantial cost per license, and the company needs many licences to make a project worthwhile, you are looking at an uphill struggle in many cases to sell your product. But there are companies in this situation at the moment and they seem to be selling a substantial number of copies of their product to both large and small organisation around the world.

See here' my question: What are the differentiators you would look at when choosing your software provider for BPM software?

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

What's your experience of BPM so far?

It seems to me that a lot of the work I am currently doing is related to "Let's see what we’ve got and document it" rather than ”OK, I'm wanting to make this more efficient, how can I do that?”.

As an example I spent time last year working with a large merchant bank who were wanting to document their sales process to help them understand how they could better sell to customer. This included understanding what was ”core” to their business and what was ”ancillary, but still profit-worthy”. The whole thrust of the BPM side of things was just to understand what they did and how they did it. We used a process management tool to do this, but at no point where we considering understanding how we could automate this or anything similar to that. It was purely a documentation effort.

My last job, similarly, was with a large aerospace manufacturer who were looking to document their HR processes. They had built up over a period of about 50 years by acquisition and this had resulted in over 250 separate companies being brought into the fold. Each of these companies had their own ways of on-boarding people, promoting people, recruiting people etc. the company wanted to document and define a single method of doing all this and rolling it out to the all the divisions. Again, nothing about automating anything, mostly about documenting.

Now I'm in discussions with a UK based transportation company who are looking to document all their existing internal processes to ensure that everything is being done correctly.

Could it be that my experience is just limited in that I tend to do a lot of the ”Let's document what we do” type of work, rather than any of the ”Let's take what we do and improve it”? Or is everyone in a similar situation? Obviously if you are a vendor selling the tools that do this you're going to have a different view of this. But for the consultants out there who are actually at the coal face doing the work, what is the nature of the work you are doing?

I think it's important to understand where the market is at the moment. There are many tools out there to help document and automate, but if the end customer is more concerned with just seeing what they've already got (or want if they don't like doing ’as-as’ documentation) rather than taking that documented state and doing something with it, then we have a different environment (and a different level of maturity) than if the market was interested in improving and automating their processes to gain efficiencies and ”synergies” (excuse the buzzword).

I'm also aware that in ”the market” there are going to be companies that are more advanced in their thinking, and, indeed, in their projects, than some of the companies I'm working with. They will have documented, improved, automated, and implemented their processes already, either as a stand-alone project or as part of a bigger project implementation. And thats all right. But I'm trying to gauge an overall level of maturity across the people who read this blog.

If we were to look at the CMM scale for maturity I'm seeing companies at level 1 or level 2 when it comes to their processes. I think that a lot of vendors are looking at their clients as being at a level 3 and above. What's the truth to this? (The above statements are based purely on anecdotal, not empirical data)

Look forward to hearing your comments and thoughts.

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

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

Process Cafe

Pages

CATEGORIES

Free Publications

Blog Archive

Selfishness and Process.

Shadow IT - Good or Bad?

Dark processes and the implication for your business

What does this mean?

How do you remove them?

Summary

Who's your vendor? And why?

New BPM systems

Possible options

Summary

The BPM Project - What's next?

On Choosing a Vendor

What's your experience of BPM so far?

Top posts for January 2012

7 Ways KPIs Can Make Your Process Worse

More reasons to document your 'As Is'

Subscribers

Subscribe Now:

Process Articles in the news

Process Books at Amazon