Process Cafe

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.... .

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?

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 Two Axioms explained

I posted the following last week

I wanted to explain a little more about what I meant, having listened to and read the replies that came forward on this.

1) There are a large number of process issues that are common amongst most companies, regardless of market sector and line of business

By this I mean that using Pareto's rule (80/20) 80% of the process issues that turn up in a company are similar across most organisations. These include items such as Segregation of Duties not being managed appropriately; Authorisations taking to long or being inappropriately routed; Inappropriate reward systems leading to processes being bypassed; Silo behaviour and Inappropriate process ownership. Of course a business that is manufacturing widgets at a rate of 10,000 per hour using automated manufacturing processes is going to have a large number of process issues that lack any commonality with a service company operating a 1000 person call centre. But at a macro level I am willing to bet that there are a lot of process issues that are common amongst both these types of business.

2) Most people in the company know what their process issues are but don't address them

Back when I used to work with the internal audit group of a large American multinational I used to spend two weeks in a specific business function looking at their processes and talking to the people that design, manage and operate them. At the end of the two weeks I would present a report - along with the rest of the audit team - that would identify weaknesses or deficiencies we had identified. In 80% of the cases the reply from management would be some variation of "We already knew that". Of course my reply would be "Well if you already knew that why hasn't it been fixed?" There were always reasons : Time, money, resources, priorities etc. But it didn't remove the fact that this were generally known issues that could have been fixed. The reason many of these were not fixed was because the department didn't realise, or understand, the business impact of not fixing them. It's ironic that it usually takes a major catastrophe that loses the company money to identify why a relatively small change should have been made. (Think of the company that kept it's computer back-ups in an on-site cupboard and lost both the computer room and the storage cupboard in a major fire. Sourcing a back-up computer to run their business on was easy, finding a back-up of their customer and transaction database was less so.

There are, of course, other reasons why these processes were not followed. I am indebted to Stephen Baishya for providing a small list from his own experience

These are all valid reasons, but do point, fundamentally, to a cultural issue where the company is not set up to appropriately manage the issues that come with running effective processes.

So, given that you know what the problems usually are, and you have pretty common problems that are not specific to your industry, why are you not addressing these issues already?

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

The two axioms of process management

There are two axioms that I have found to be true in almost 100% of the places I have visited to work on their processes :

1) There are a large number of process issues that are common amongst most companies, regardless of market sector and line of business
2) Most people in the company know what their process issues are but don't address them

Discuss.

(P.S. A more detailed post about this will be forthcoming in the near future. I just wanted readers opinions at this time)

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

Silo thinking - It's still bad!

The most popular post on this blog (by a long way) is one entitled "Silo thinking and why it is bad...". It was written back in January of 2010 and appears to consistently get the highest number of views of any post I have written. Obviously I'm looking at it thinking "Why is that?'

Sure, it's a well reasoned, thoroughly researched treatise on the nature of the silo mentality in organisations, along with accurate and incisive commentary on how to get around it. (At least in my own mind it is...) but there's obviously something more than that.

So what?

I think it's because it hit a nerve with a large number of the readers of this blog (over 4,500 last month - thank you!), and it is apparently something that everyone can identify with.

The first paragraph read:

I believe this to be as true now as the day it was written. The beauty is that it isn't just a process thing but a company wide thing.

The main thrust of that post relates to how a process is usually optimised to run as well as it can within a single department (or silo) and as such is not optimised to run as well across other departments or silos. I'm sure you've heard the tale of the manufacturing process which created some sort of metal engineering device. At the first department responsible for the manufacturing they put together the main three components of the device - the hub, the sprocket and the flange. They then boxed these up and sent them across to the next step where the electronics were added. The first thing this department did was remove the flange that had been added in the previous step. Then they fitted their electronic wiring & circuits and refitted the flange.

This sounds like an apocryphal tale, but it does illustrate quite graphically the ability of two departments working in the same company and producing the same product to - effectively - be working against each other. The first department had an optimised sub-process that meant it was efficient enough to be able to manufacture and construct the three main parts of the assembly, and - without reference to any further parts of the process - they were able to make themselves as efficient as possible. Across the whole of the process, though, this silo mentality was having an adverse effect.

I was reminded of this recently when working on a guest post for Squawkpoint.com which covered the topic of 'Who owns your processes'. In that post I mentioned that the process owner wants to be

It we take the example given above it means that we want to be able to make the first step of the manufacturing process slightly less efficient whilst, at the same time, making the overall process more efficient. Having someone owning the individual parts of the process (silo'd) does not allow that to happen.

The other point I mentioned in the original post was that reward plays a large part in this. It has been proven in survey after survey, and experiment after experiment, that people generally tend to focus on the things that will reward them the best. If I am a department boss and I tell my workers "Your annual review and associated compensation is based on your ability to process 1000 widgets per day come hell or high water" you can bet that my employees will be focused on finding ways to process 1000 widgets per day. If it means that they have a way of doing this which is optimal for their own department but sub-optimal for the rest of the widget manufacturing process then that's not their fault.

This is how silos occur.

The solution is - obviously - to reward and recognise people based not on their own individual performance, but on the company performance as a whole. The correct statement should be "Your annual review and compensation is based on the company as a whole being able to produce 1000 quality widgets per day come hell or high-water". The approach is still the same - the employees how to find a process which works in their best interests - but the end result is different - you finish up with a process optimised for the whole process rather than one which is optimised for individual departments.

It is my opinion that - despite the interest in the original post from nearly two years ago - there still appears to be a large amount of silo thinking happening in organisations.

Am I right?

.

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

Business Process Management and Common Sense

This is a guest post by James Lawther:

In the beginning all businesses start out as small businesses. They start with one, two or at most a handful of employees with a vision to give customers something new and different, or just better. They then focus like crazy on those illusive customers, doing everything that they can to find and please them.

If the new, different or just better is truly new, different or just better; then slowly but surely the customers start to materialise, they like what they see and what they are getting and then they start to hand over their hard earned cash so they can have it.

And then the company grows.

If things go well the business won't be a small business any more. It will have a hundred employees and it will be time to become organised like a big business. Groups of accountants and IT professionals start to congregate, a sales force is born, a human resources manager is hired, functions develop.

Sensible business owners put dynamic pushy people in charge of these new functions and give them targets to hit, financial targets, cost targets, revenue targets, growth targets. Now success looks like hitting your targets and those dynamic pushy people start to optimise away like crazy. They start to focus on the internal mechanisms of their organisations and before you know it you have Sales people who are dragging in sales, Operations people who are slashing costs and Marketing people who are building new markets.

And they all do this with gleeful disregard to one another. After all no operations guy is going to be rewarded if the accountants hit their target.

As all this happens the customer who everybody started off obsessing about becomes of secondary importance, and their sales orders, complaints and queries start to fall between the cracks of the SLA’s, targets and departmental objectives.

Then things start to stagnate, accusations are thrown and the functions become more and more retrenched, each striving harder than before to hit their targets. And so it goes on.

Maybe I have painted a very black picture, maybe a truthful one; either way the solution is not very difficult. It is remarkably simple. Get your business to re-focus on the customer and optimise around them not their functions.

And that is all business process management asks you to do. There is nothing very clever about it, it is just common sense.

Are you using yours?

Author Bio

James Lawther is a middle aged middle manager.

To reach this highly elevated position he has worked for numerous organisations, from supermarkets to tax collectors and has had several operational roles including running the night shift for a frozen pea packing factory and doing operational research for a credit card company.

As you can see from his CV he has either a wealth of experience, or is incapable of holding down a job. If the latter is true his post isn’t worth a minute of your attention.

Unfortunately, the only way to find out is to read it and decide for yourself.

Visit his web site “The Squawk Point” to find out more about service improvement.

www.squawkpoint.com

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

Process Cafe

Pages

CATEGORIES

Free Publications

Blog Archive

Levels of Detail.

When people don't understand controls.

Top Ten Tips for Business Process Projects

The Two Axioms explained

The two axioms of process management

Silo thinking - It's still bad!

Business Process Management and Common Sense

Subscribers

Subscribe Now:

Process Articles in the news

Process Books at Amazon