Process Cafe

Showing posts with label tips. Show all posts

The Redundant Back-Up

I worked at a location that was running a single, world-wide instance of SAP. The whole of their HR, Finance, and some of their manufacturing was running from this single instance, twenty four hours per day, seven days per week. Naturally, the process analyst in me (and to some extent, the pragmatist) had a number of questions about this:

- “How do you back-up?” - “We mirror and back-up the mirror”

- “How do you do maintenance?” - “We have a back-up machine at a separate location across town. We transfer the users to that and perform the maintenance then”

The questions went on and on. Each one had a suitable reply. But then I started thinking about this single instance and it didn’t seem to sit right with me. For some reason I could foresee problems with it. Finally, I was able to verbalise the issues I was having: “How do you deal with disaster recovery?”

Most of my readers will know what disaster recovery is, but for those that do not, a quick explanation. When something happens to a computer system that renders it unusable, a business continuity plan (BCP) needs to kick in. This is where processes are enacted that allow the business to continue operating without the damaged/unusable machine. Running in parallel with this is a recovery process that attempts to repair or replace the damaged/unusable machine and reinstate all the data and transactions that were damaged or missing as a result of the disaster. I had concerns that because this was a single instance, and because it was being used globally, BCP and disaster recovery would be a nightmare.

The project team had already thought about this.

They told me that for BCP purposes, every affiliate running the software had processes on-site that would kick in if the system was unavailable. Even in the worst case scenario, the system would not be offline for any more than 48 hours because they had an agreement with a third-party provider to have a hot-site at a remote location which would be implemented at the first signs the redundant back-up didn’t work.

I asked if this had been tested. It hadn’t. But I was assured that it had been implemented in other organisations within 48 hours.

I turned my attention to the redundant back-up. What happens if there is a fire that destroys the main machine? The redundant back-up would kick in, and all systems would be re-routed. How is the rerouting done? Through underground cables that link the two sites. What happens if someone cuts through the underground cables? There are redundant underground cables that route North and South of the city between the two sites. The chances of both being cut are infinitesimally small. What happens if there is a power spike that takes out both systems? Both systems run off separate power supplies. A power spike would only take out one, not both. What happens if a small nuclear device takes out the town, both sites and the power sources? We would have bigger things to worry about than the system, but in that case the hot-site would kick into action.

I grilled the technical operators and designers of this system for almost two days, coming back to them time and time again when a new scenario occurred to me. They had a suitable answer for every single one of my questions. So, at the end of it - despite my reservations - I had nothing concrete to justify them

Then, a couple of weeks after I left the site they ran a new interface program. It was an HR population interface that filled in specific records on an HR master file. The interface had not been tested properly and it went into a loop. The program ran all day and most of the night. It kept populating the file overnight, making this file larger and larger and larger. It made it so large, in fact, that it completely filled all the disk space on the system.

The main computer, and global SAP instance, shut down.

As designed, it failed over to the redundant back-up across town. The system was on-line, ready to go as expected. It dutifully continued running all the processes it should be running - including the HR population interface. This ran for the rest of the night until it, too, had filled up the disk space on the redundant back-up.

That machine failed.

Plan C was, of course, the hot-site located in another town. A town which was, in fact almost 500 miles away from where the two main sites had been. The hot site didn’t work. It took almost 72 hours to get up and on-line and even then all the information needed to make the system run globally wasn’t there. The comms lines to the global sites were not connected. Anything that could go wrong, did go wrong.

The rest of the story gets a little fuzzy. All I know is that the global SAP system did not come back on line in the host town for almost six weeks. Retrofitting all the missed transactions from within the BCP took another few months.

Nobody lost their job over this. The hot-site provider lost their contract, I believe. I sat there shaking my head.

But that wasn’t the worst of it. The worst part came when I spoke to people who were affected by the outage. I asked them what their BCP was for when they had no access to the system. (remember I had been told by the tech crew that each affiliate had processes for dealing with on-going business when the system was down). They told me “We wait.” The BCP for operating a multi-billion dollar global business across numerous affiliates, sites and countries was “Wait”. Wait until the redundant back-up kicks in and, if this doesn’t work, wait 48 hours until the hot-site is ready to run. I wondered how they dealt with a six week backlog of waiting? Nobody was able to tell me. But I’m reasonably sure it involved manual work arounds.

The moral of the story?

Your redundant back-up isn’t. There is always the scenario where you will find yourself without it. Plan for that scenario. Make sure that you have processes in place to deal with it - even if the chances of that happening are remote. Remember the Twin Towers of the World Trade Centre were designed to withstand the impact of commercial airliners when they were built. The chances of an airliner destroying more than a few floors was negligible. But the impact of the jets didn’t bring down the towers. It was the thousands of gallons of jet fuel burning away at vital support beams that did it. Once a couple of these had weakened, gravity did the rest.

Photo Credit: pchow98 via Compfight cc

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

The CPO

In the style of Seth Godin.

If process is so important, and everything that happens in a company is a result of process occurring, why doesn't every company have a Chief Process Officer?

Reason: We haven't built a compelling, cost-effective, and succinct reason to install a CPO.

But the bigger question is : Why haven't we?

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

Why our processes aren't perfect.

Photo Credit: pshegubj via Compfight cc

A perfect process is - by definition - the ultimate way in which a process can be defined and managed. So you would think that everyone would be striving for the perfect process.

Unfortunately, that isn’t always the case. People tend to strive for ‘good enough’ when it comes to many things. That report you are creating could do with a further grammar check, but we won’t do it. It’s good enough. The decorations on the Christmas tree could do with being tidied up and made absolutely symmetrical, but we’ll leave them as they are. They’re good enough.

Why is this?

A lot of it is to do with the Pareto rule. The Pareto rule states that 80% of the work is done by 20% of the effort. The remaining 20% will take 80% of the time.

(From Wikipedia: The distribution is claimed to appear in several different aspects relevant to entrepreneurs and business managers. For example:

80% of your profits come from 20% of your customers

80% of your complaints come from 20% of your customers

80% of your profits come from 20% of the time you spend

80% of your sales come from 20% of your products

80% of your sales are made by 20% of your sales staff

Therefore, many businesses have an easy access to dramatic improvements in profitability by focusing on the most effective areas and eliminating, ignoring, automating, delegating or retraining the rest, as appropriate.)

The same happens with processes. An amount of time and energy can be spent reviewing, revising, improving, and implementing processes, but on further review it is discovered that they are only 80% of the way there. To move the process the remaining 20% will take a disproportionate amount of time and energy, sometimes to the point that it becomes economically unwise to pursue.

But is this right?

On a fundamental level the answer is “yes”. If the return on investment of performing the additional 80% the work is less than the benefit of improving the 20% that’s remaining, then ‘good enough’ will suffice. But there are certain points where it becomes less a matter of ROI and more a matter of other things.

Let’s take airplane construction, for example: Would you fly on an aircraft that had only had 80% of the testing done on it? Would you trust an airline navigation system that had only had 80% of the coding tested? What about a surgeon who had only done 80% of his training?

I know I wouldn’t.

These are examples of when the 80/20 rule needs to be ignored and 100% of the effort needs to be put in.

Can you think of any of your processes where this is the same?

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

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?

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

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.

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?

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

The distraction of BPM

(In the style of Seth Godin)

For many project people the tools and associated detritus around BPM are what makes the project interesting: Get a good tool, implement it, either with your SI or internally, roll it out and watch the users flock to this brand new way of doing thngs.

Except that's not what happens.

Your user base couldn't care less about a new tool, or some new way of doing things. All they want is to be able to finish their work in the quickest, easiest way possible and go home.

Anything you put in the way of that will meet resistance

(And everything you do is in the way of that!)

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

The No. 1 Success Factor for BPM Projects

In the style of Seth Godin

I recently asked The $64m question about BPM and the answers I received were many and diverse.

So it got me thinking "What is the number one success factor you need to have for BPM projects".

Is it training?
Is it C-Suite buy-in?
Is it an understanding of the benefits?
Is it dealing with the hottest burning issue?

The answer is "Yes". It's all of those.

And none of those.

What is most important to your organisation is the factor that will get BPM implemented quicker and easier.

It might be getting C-suite buy-in. It might be getting people trained. It might be making sure everyone understands the benefits of BPM. It might be finding a burning issue that you need to solve.

One thing's for sure: There is always a key success factor in each project.

The next time you're starting a BPM project, consider that the reason the last one failed might be because you had the wrong factor identified. Your challenge is to identify what the right one is and make sure everyone is aligned.

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

Why BPM Won't Work In Your Organization

In the style of Seth Godin

Because it's hard work. Because it involves change. Because you don't know what you don't know about the project.

Your BPM project will take longer, cost more and hurt more people than you imagine. Make sure you know this in advance and work through it.

The world is full of BPM projects that didn't achieve their potential.

Don't let yours be one of them.

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

The Unseen Face of Process projects - A summary of the series

This is the final post in a series focused on process work. Particularly process work being carried out in projects. It links in closely to my eBook ‘The Perfect Process Project’, version 2 of which has been released. If, after reading these posts, you want to purchase a copy of the book please feel free to click over to the appropriate page and do the business.

[Click to read more..]

The Unseen Side of Process Projects - Part Six : Doing the wrong things

This is the next in a series of posts focused on process work - particularly process work being carried out in projects. It links in closely to my eBook ‘The Perfect Process Project’, version 2 of which has been released. If, after reading these posts, you want to purchase a copy of the book please feel free to click over to the appropriate page and do the business.

[Click to read more..]

The Unseen side of Process Projects - Part Five : User involvement

[Click to read more..]

The Unseen side of Process Projects - Part Four : Measures

[Click to read more..]

The Unseen Face of Process Projects - Part Three: Process Ownership

This is the next in a series of posts focused on process work. Particularly process work being carried out in projects. It links in closely to my eBook ‘The Perfect Process Project’, version 2 of which has been released. If, after reading these posts, you want to purchase a copy of the book please feel free to click over to the appropriate page and do the business.

If you are already a subscriber to The Process Cafe you will receive these update automatically in your RSS reader or inbox. If you don’t already subscribe you might wish to do so by clicking the RSS icon on the right of this post.

[Click to read more..]

The Unseen Face of Process Projects - Part Two: Managing project change

[Click to read more..]

The Unseen Face of Process Projects - Part One: An Introduction

Background :
This is the first in a series of posts focused on process work, particularly process work being carried out in projects. It links in closely to my eBook ‘The Perfect Process Project’, version 2 of which has been released. If, after reading these posts, you want to purchase a copy of the book please feel free to click over to the appropriate page and do the business.

Over the next four weeks I am going to be publishing posts which relate to each of the five entries listed below. I’ll be discussing the type of problems that occur along with how to solve them or what to do to address these issues. If you are already a subscriber to The Process Cafe you will receive these update automatically in your RSS reader or inbox. If you don’t already subscribe you might wish to do so by clicking the RSS icon on the right of this post.

[Click to read more..]

Who's running your process project - The Chicken or the Pig?

Over my 20-odd years in the business I have worked on countless projects. Most of them have been deemed to be ‘successful’ (sometimes in the context of ‘We put a project in place to implement xyz and we have implemented xyz therefore the project has been successful’) and a number of them have, unfortunately, been unsuccessful. It is always easy in hindsight to look back and understand what it is about a project that made it less successful than it may have been - and the reasons are numerous. But in my experience the main reason that a lot of projects fail is change management (or lack of it). I have written about this previously. What I want to do today is to look in a little more depth at one facet of change management which is - in my opinion - a prime candidate for ‘reasons most projects are unsuccessful': Lack of senior management buy-in.

[Click to read more..]

Pay me now - pay me more later

Here's the situation: You've documented some of your current processes, created your organisation chart, got a small team together to define your future state and now you're pushing them to finish this because you have an ERP solution waiting to be implemented with your processes. Congratulations you've fallen into the trap of "Pay me now, Pay me more later". This trap occurs when you try to short-cut the whole process definition stage. You'll recognise this when you hear phrases such as "Why do we need a current state?", or "Let's define what we want our organisation to look like then define the processes"

[Click to read more..]

Processes by stealth - Gartner recommends it!

In a recent comment about how to set up organisational supports for BPM initiatives, Gartner's Jim Sinur remarked:

I almost jumped for joy when I read this as it, basically, aligns with a concept I tried about 7 years ago known as 'Processes implementation by stealth'. The basic issue was that the company I was working for at the time had very little knowledge and understanding of how to start a process management capability. As a result they were reluctant to move forward with creating this in light of other, more pressing, business issues. To try and move things forward I became involved with a number of projects where we 'insinuated ourselves' into the project and started to define process type activities as part of this. For example I worked with a department that was looking to outsource a large part of the work they were doing to a third party organisation. I managed to convince them that if they had a neatly defined (and agreed) process map of what their department did, they would be able to take that to a prospective third party and easily identify the hand off points and the deliverables. As an added bonus we were able to remove a number of non-value-added activities as part of the process discovery exercise.

Over the course of a number of months we took this concept of process discovery by stealth and enlarged it to some more important projects. What this gave us a chance to do was to identify a business case for including process work in all projects. Once that case was approved the organisation mandated this across all IT projects and the capability was started from there.
The end result is that a little bit of 'process management by stealth' led to a global process organisation being created where a direct approach to create that would not have happened. Ultimately the CIO took responsibility for the process capability and this gave us the senior management ownership that we needed to make this happen.

Processes by stealth - it can happen and it does happen. Where is it happening in your organisation? Or alternatively - where should it be happening in your organisation?

Process Cafe

Pages

CATEGORIES

Free Publications

Blog Archive

The Redundant Back-Up

The CPO

Why our processes aren't perfect.

The BPM Project - What's next?

7 Ways KPIs Can Make Your Process Worse

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

Top Ten Tips for Business Process Projects

The distraction of BPM

The No. 1 Success Factor for BPM Projects

Why BPM Won't Work In Your Organization

The Unseen Face of Process projects - A summary of the series

The Unseen Side of Process Projects - Part Six : Doing the wrong things

The Unseen side of Process Projects - Part Five : User involvement

The Unseen side of Process Projects - Part Four : Measures

The Unseen Face of Process Projects - Part Three: Process Ownership

The Unseen Face of Process Projects - Part Two: Managing project change

The Unseen Face of Process Projects - Part One: An Introduction

Who's running your process project - The Chicken or the Pig?

Pay me now - pay me more later

Processes by stealth - Gartner recommends it!

Subscribers

Subscribe Now:

Process Articles in the news

Process Books at Amazon