Thank you.
Gary
Holiday Greetings from The Process Cafe
Wherever you are, and whatever your denomination, I would like to take the opportunity of thanking all my readers, subscribers, Twitter followers and Google+ circlers, and wishing you all the best for the New Year.
Thank you.
Gary
Thank you.
Gary
The System is not the Process. The Process is not the System
(In the style of Seth Godin)
It is well worth remembering that when you design a process it should be designed independently of the underlying system that will support it. That's what procedures are for.
Designing a process based on a specific piece of software means that when the software changes the process needs to change as well.
You don't want that.
All information is Copyright (C) G Comerford
See related info below
It is well worth remembering that when you design a process it should be designed independently of the underlying system that will support it. That's what procedures are for.
Designing a process based on a specific piece of software means that when the software changes the process needs to change as well.
You don't want that.
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
Levels of Detail.
I've spent a lot of the last month or so in process facilitation sessions with different departments of a specific company.It's been a very interesting set of sessions. I've learned a lot of the particular business area (probably more than I really wanted to know), but I've also learned a lot about peoples attitude when it comes to the world of 'process'.
Let me see if this scenario rings true to any of my readers: (In the style of Adam Deane)
Me: So what I want to do is understand, at a high level, what are the main chunks of work you do from a process point of view
Attendee 1: Right, well, let's see. We produce the weekly TPM reports.
Me: OK. That's not a process, that's a deliverable. What's the process that produces that?
Attendee 1: I don't understand
Me: Producing the TPM reports is something that happens at the end of a particular process. What is that process.
Attendee 1 : It's the process to produce the TPM reports.
Me: Is that all you do?
Attendee 1: We send the TPM reports to management
Me: Prior to that?
Attendee: We run the programme to produce the TPM reports.
Me: Are those the only reports you run?
Attendee 2: Oh no. I run the quarterly QQZ report!
Me: So, what I'm hearing you say is that you have a process to 'Manage management reporting', and you both do that?
Attendee 1: Wait a minute. The TPM and the QQZ are different reports.
Me: And..?
Attendee 1: It's not the same process.
Attendee 2: Not the same process at all.
Me: Oh. So what's different?
Attendee 1: TPM reports are run off monthly.
Attendee 2: QQZ reports are run off quarterly.
Me: But other than that there are no differences?
Attendee 1: Oh yes, there are lots of differences. The TPM reports run off the transaction file and the QQZ reports run off the summary file.
Attendee 2: And I run the QQZ reports from menu 3, but the TPM reports are run from menu 1.
Me: But from a physical 'What is the process' point of view your process is basically 'Gather report data, produce reports, send to end user'?
Attendee 1: I send mine to different end users than she does.
Me: But you still send them to an end user?
Attendee 2: I send them to management
Me: But management do something with them?
Attendee 2: I don't know. I never asked..
Me: Right. So I think we defined a 'Manage management reporting' process at a high level. As we decompose that proccess we'll find differences specific to each report, but at a high level are we happy?
Attendee 1: Yes
Attendee 2: Yes
Me: So what else do you do?
Attendee 2: I update the system when somebody leaves
Me: Does that happen often?
Attendee 2: More often than you would imagine
Attendee 1: I update the system when somebody gets married. I change their marital status.
Me: Ok So I'm hearing that we have a 'Maintain employee data' process?
Attendee 2: But when they leave is different to when they get married. It's a different process.
Me: Is it?
Attendee 2: Oh yes. It uses completely different screens and different people approve it. It's completely different.
Me: So it's not a case of 'identify data to be modified. Modify data. Gain approval'?
Attendee 2: Er. Well.. yes. I suppose it is
Me: And is that what you do too?
Attendee 1: Yes. But using different scree--
Me: I understand the actual details are different, but is it fair to say you are performing the same basic process over a different set of data..?
(silence as this is digested)
Attendee 1: ...er.... Yes?
You can see where I'm going with this. People tend to get fixated at a very low level of detail when it comes to their processes. In fact, I would go as far as to say they're almost looking at procedures or work instructions in some cases.
The art of process mapping is to be able to roll that up to (or, indeed, drill down to it from) a high level. This gives the overall view of the business and helps to understand the touchpoints for other processes or functions. Sure, you can then start to drill down into the lower levels of detail and understand what and where things happen. At some point you'll decompose to the level where producing the TPM report is different to the QQZ report, or maintaining a marital status flag is different to maintaining an employment status flag. But at a higher level of detail this doesn't matter.
I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the 'whole level of detail' issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.
At the end of the day that's all you really need.... .
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
When people don't understand controls.
I had an interesting situation occur today.
Recently I've been in discussion with an organisation who want me to do some work for them. As part of this, they set up a new e-mail account for me on their domain email system. I received the confirmation e-mail details from a third party supplier who deals with setting these things up for them. The third-party supplier had sent my username, e-mail, POP details, SMTP details, and other e-mail information to me, in an e-mail, in plain text. In addition, they had copied in two members of the third party and my potential future client contact. One of the third party addresses was a generic e-mail account for "IT Support".
So far, so straightforward.
Then I wrote back to the 3rd-party asking how can I change my e-mail password because it was sent in plain text to several people, most of whom I don't know and wouldn't trust. Their reply? "There is no way of changing your e-mail details. It's our policy." When I pointed out, from a process point of view, how much of a risk and liability this was, the organisation said that because theirs was a small business and everybody knew each other "it was okay".
Basically this organisation has now said to me (in not so many words) "We are setting up an email account for you. The password details are know to several members of the organisation, you can't change them and we're comfortable with that." The logical extension of this was that I personally now have no further accountability for anything sent from my e-mail account as I couldn't guarantee that I was the only person using it.
The next communication I received from this organisation was a note telling me they were terminating their agreement with me and we would no longer be working together.
Can you imagine the situation if something went out to a client under my e-mail account and it said something inaccurate, derogatory, racist, sexist, libelous, rude or illegal? The fact that it was under my name would immediately throw the finger of suspicion on me, whereas - in effect - anyone in the host company IT department could have sent it.
Of course my contact in the organisation was working on the basis that 'It won't happen because we trust each other', and I understand that. But trust in an organisation will last until an employee feels disgruntled, has been badly treated, or decides they no longer want to play by the rules. This increases dramatically when you bring in a third party IT service provider who has no vested interest in me as an individual.
All in all the situation was fraught with potential for disaster.
But it did bring up the bigger process question about controls. A process will only work well if it is controlled appropriately. This doesn't mean it needs lots and lots of checks and balances at all points, but it does need something in there to ensure that the actual outcome of a process is the same as the required outcome.
In audit terms this could be something such as segregation of duties (making sure no single role has too much power to be able to subvert the outcome), or appropriate authorisation (ensuring that there is more than one signature required on a check, for example). No single control will work for every step of a process, but taking an overall look at the process and understanding which are the key controls that are needed is one way of building integrity into the process itself.
How many of your processes have appropriate controls built in?
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
Top Ten Tips for Business Process Projects
I recently read Jacob Ukelson's post: top 10 tips for integrating a start-up after an acquisition.
One thing that struck me about these top ten tips is that a lot of them apply equally validly to ensuring a BPM project is appropriately managed, and the resulting solution integrated into your enterprises.
Let's go through these and see:
Tip 1 - Make sure that someone is thinking about the day after. In M&A Jacob was referring to ensuring that the focus isn't just on the process of the integration but also on determining how things will run when the whole integration effort is finished. With BPM this is equally as important. Somebody who can ensure that the effort put in by the implementation teams is mirrored by the effort needed to ensure smooth running of new (or improved) processes on day one.
Tip 2, 3 & 4 - Communicate. Communicate. Communicate. As Jacob says, you can never communicate enough. This is equally as vital a comment when major change is happening to a department, a region, or an enterprise as a result of process implementation or modification. There will be fear, uncertainty and doubt on the part of the business. They will look at a lot of what is being done and consider that it is 'getting in the way' of allowing them to work. Appropriate communication will ensure they understand the importance of the BPM effort and their role in making it happen. This is also very important if there isn't a common language between implementation team and users.
Tip 5 - First do no harm This is an interesting tip because the definition of harm is very fluid depending on who you ask. If you are a dyed-in-the-wool long time employee who has worked in the same department for several years, has their own way of doing things and is comfortable with the work arounds, the short cuts and the omissions that can form part of your daily work, when someone comes in and want to replace these with a new, shiny process you will feel uncomfortable. You will see the possibility for control to get away from you and you will interpret this as 'harm'. But in the big scheme of things it is just old habits dying hard. But, likewise this applies to the BPM team who may come in with an attitude of "There is a big problem here so we need to ensure we do something to fix it". As a result they may ride rough shod over parts of the organisation before taking an opportunity to review what is the right way to do things rather than the quick way to do things. Do no harm!
Tip 6 - Get help. Thinking that process management is something that can be done in isolation, or can be done by someone with little knowledge of existing systems, departments and work, is likely to result in a failure. So ensure that the user base are involved in the process. Ensure that help is taken wherever it can be. After all, these people know their environment far better than you do. Make sure you use that knowledge whenever and wherever possible.
Tip 7 - Visit Early, Visit often. How many projects have you been in where the project team meet the implementation goal and then immediately transition off onto other projects leaving the newly implemented processes to work purely with the users? This is a recipe for disaster. Ensure you keep project team members in the loop. Keep up to date with how processes are running. Meet early and meet often!
Tip 8 - Remember that the company acquired is different than your own, with their own unique culture. Or - to put this into a BPM context - remember that the company having their processes implemented is not your own and that culture is the biggest thing you'll need to overcome to make your project successful.
Tips 9 & 10 - Make sure you remember why you did the transaction. Or - from a BPM point of view - remember why you have made process changes. It is easy to get lost in politics, budgets and the management of change in the user base. But being able to stand back and remember the situation as it was prior to the project starting is a great way of focusing people and helping them understand why you have made the changes you have.
Sure, not all the tips from Jacob's article translate neatly to a BPM context, but there are enough there to ensure that sooner or later a few of them will be relevant to the project you're currently working on.
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
The Two Axioms explained
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.
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
- Fear of looking bad if the cause of the problem is my responsibility - "blame" culture
- Fear of reprisal if I make someone else look bad if the cause of the problem is someone else's responsibility - "management by fear" culture
- Deep-set organisational beliefs that people are always the cause of problems, not processes - often leads to ineffectual productivity drives, training, coaching/performance management, i.e. get people to work harder rather than actually fixing the process
- Desire for instant gratification - fixing root causes can take time; I need to say I've done something NOW
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?
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
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
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)
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
