Outsourcing and Process Management

Image via Wikipedia

My next door neighbour works for a military contractor. They are looking at taking over a division of another company on an outsourced basis and I asked him if he had done the process work behind this. He looked at me a little quizzically. "What do you mean?" he asked. I shook my head a little ruefully and asked him "Presumably you will be putting together contracts that define service levels around the outsourced division? Presumably these contracts will have financial penalties if you can't meet any given contractual clause? Presumably you have therefore, asked for (or created) a detailed process map for exactly what it is this division does and exactly how this division does it. This will then give you enough information to be able to negotiate better penalty clauses and payments based on actual data rather than something the outsourcing division is arbitrarily asking for?"

I think I hit a nerve there as my neighbour retreated quickly into his house with a nasty facial tick starting just above his left eye.

It never ceases to amaze me how companies - respected companies at that - can hope to enter into outsourcing agreements without knowing (from either side) what exactly they are outsourcing.

But it doesn't have to be that way.

I worked a couple of years ago with a pharma company that was outsourcing part of their clinical trial work to a third party clinical trial organisation. The first thing we did prior to bringing anyone in was to create a current state process map of the whole of the process to be outsourced. This allowed us - in negotiation with potential outsourcing companies - to delineate exactly which part of the process would fall under the jurisdiction of our company and which would be their responsibility. It also defined what the interactions would be between the two companies (the hand-offs and 'white space' which cause so much problem). Ultimately when we got into negotiations about the terms of the outsourcing we were in a much better position to be able to state our case for what was needed. It also meant that the outsourcing company was clear on expectations and responsibility.

With the current economic climate there are numerous companies that may be considering putting up some or all of their internal work for outsourcing. It is essential that you know and understand exactly where the demarcation lines are on this outsourced work.

Here are a few tips:

1) Before you go to any external company create an 'as-is' view of your current process. (I'll be talking about 'as-is' and 'to-be' processes in a later post). If the outsource company wants to change this process when they are managing it then they can do so. But only within the context of the following point.

2) Identify from your as-is process exactly which steps you are willing to outsource. (The whole philosophy of what to outsource is outside the mandate of this post but suffice it to say that you should not outsource your key business process - whatever that may be). Changes to the process by the outsourcing company must still fall within the steps you have defined above.

3) Concentrate on the linkages between your in-house and outsourced processes. What are the hand-offs? Who has responsibility? What is the regularity of data transfer? Again, if the outsourcing company has changed the process internally then they should still provide the appropriate linkages, to your satisfaction of course, back to your process.

4) Identify and define the expectations around those linkages. This is your means of controlling the outsourced process. The whole outsourcing contract will revolve around the ability of the company to provide what you need via the linkages you have defined. If they cannot provide what you need through these linkages then they are not the right outsourcing company for your needs.

5) If internal quality of process is key, define metrics to manage this. In other words if you are only bothered about what comes out of the process at the hand-off's, then only measure the hand-offs. If you are concerned with how the outsourced process is working then put measures in place to track this: For an outsourced clinical trial you would want, for example, to track patient enrollment rates, patient drop-out rates and adverse event information. But for outsourced printing you might only want to track quality of received product and turn-around times.

Outsourcing is probably one of the better ways of reducing your bottom line in the curent economic times, but it will only do so if you are aware of exactly what you are outsourcing and why. Address a couple of the points raised in this post (and get the right people in to help you define your process) and you are well on the way to doing this.

---

Reminder: 'The Perfect Process Project' is still 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.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

The "As-is" vs 'the "To-Be"

Image via wikipedia

I am a big proponent of 'As-is' modeling. Unfortunately I appear to be in something of a minority.

When I work with clients I am constantly reminding them to document what they are currently doing before they move onto their future state. Quite often the reply I get is "If we're going to move to our future state we shouldn't waste time documenting the old way of doing things" I can certainly see the logic in this statement. However it does ignore one of the fundamental issues which cause problems on projects and that is "Change". Let me explain:

In 'Alice In Wonderland' Lewis Carrol wrote 'If you don't know were you are going any road will get you there'. I think this is the polite thinking behind a lot of process project leaders. They don't know where they are going and therefore they try to manufacture a way of getting to this destination not even knowing where they are going from.

In real life if you are using a satnav to navigate to a destination it always has to know where you are starting from in order to determine the best way to the destination. Granted, it can produce a number of different routes to get there, but they are all predicated on the fact that you know where you are starting from. No navigation system in the world can work effectively without knowing a starting and ending location.

Let's go back to our early map reading days before the satellite navigation systems became ubiquitous. We used to start with a road map, or an Ordnance Survey map, and plot our route to our destination But we always started on the page which showed us where we were at the beginning of the journey. There was no other way of doing this. It happens in the world of aviation, marine navigation, and orienteering. There is no way of navigating to an unknown destination without knowing where you are starting from.

So why do projects try and do this when implementing processes?

Not creating an as-is situation is tantamount to starting your journey to a new destination without knowing where you are now. It is like opening your road atlas at the destination age and hoping to navigate their without checking the page that has your origin location. It just won't happen.

However there is a flip side to this argument. There is an old joke which goes something like this "A guy was lost in the countryside and he stopped to ask one of the locals. He said 'How do I get to the castle'. The local shook his head and said 'If I was going to the castle I wouldn't start from here'" In other words 'This is the wrong starting point to get to where you need to be'. In the process world there are also 'bad' or 'wrong' starting points. Heavily outdated manual processes that no longer reflect current working practices and which are due to be replaced by automated systems, are an example of this.

But even so, documenting what actually happens (as opposed to what should happen) is usually a good place to start

Can anyone think of a reason why an 'as-is' process would not be documented?

---

Reminder: 'The Perfect Process Project' is still 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.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Dead Time... How do you treat yours?

Image by Stuck in Customs via Flickr

Craig over at The Process Ninja has an interesting little post discussing 'Dead Time' in processes. Basically it comes from a study which occurred many years ago where 'fast' workers could only work flat out for a length of time before dropping back and becoming unproductive, whereas 'productive' workers worked constantly at a lower efficiency rate. Overall the 'productive' workers beat the 'fast' workers. The difference between the 100% worker rate and the 'productive' rate is what Craig calls "Dead Time". He gives a couple of, admittedly simple, examples:

...is it worth installing new lifts in a building that are super fast to enable employees to get to their desks quicker? I'd say probably not as this period of time may fall into 'dead time'. Is it worth spending money on a super fast coffee machine in the kitchen? Probably not because people will still stand around and talk to whoever is in the kitchen at the time.

Now this got me thinking about the application of 'dead time' within process management itself. It obviously has applications within aspects such as simulation: Whenever you are working through simulation there is always the temptation to try and load the figures one way or another to affect the results. In a given simulation step you will have metrics values such as 'Total work time' and 'total delay time' as well as 'transit time' and 'queuing time'. Nominally these times are gathered by monitoring existing processes and recording the time for the process steps there. The problem with that is that you can quite easily forget about the dead time in the process. Isn't it easy to watch two or three people who are working a process step and capture the fastest time as a 'best practice' timing? The obvious problem with this is that if this person is not the most productive person you could be falling into the trap of ignoring the 'dead time'

The other thing with 'dead time' is that it affects productivity for some people but can also then start to reduce the productivity of unproductive people even more. Let's follow Craig's example of the super fast coffee machine. If the '30%' worker comes into the kitchen and sees the '100%' worker chatting with someone over a super-fast cappuccino isn't there a chance that he or she will also stop and chat for a while? Suddenly the 30% worker then become a 50% worker. It's a slippery slope.

I honestly don't think we understand - or at least acknowledge - the concept of 'dead time' enough. Fundamentally it has the ability to change the way we view processes - or at least to alter our perception of productivity within a process. It can do this either in a positive or a negative fashion too.

I'm going to do some thinking about the effects of this and get back to you with more about this soon. In the meantime, do you have examples of 'dead-time'?

(You should follow me on Twitter by clicking here)

---

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link now and follow the instructions to get the book.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Simplify!

If I was to sum up the whole concept of process improvement in one word it would be 'Simplify'.

Too often today we get lost in the morass of detail and unnecessary detritus which detracts from the key fundamental of process design which is to keep things as straightforward as possible. After all it was the great Albert Einstein who said "Make everything as simple as possible, but not simpler." and by that I think he mean that the ideal approach to almost everything is to ensure that you have got the easiest, quickest, least complex solution to any problem that will actually solve the problem itself. That last phrase is actually critical and is often lost on people. it is very easy to make a simple solution which - when implemented- will not actually solve the problem (or - more particularly - will solve the problem in it's pure form but not in an adulterated form)

For example if I was trying to streamline an on-line ordering function the simplest it can be is to be able to buy something with 'one-click'. Our good friends at Amazon.com have mastered this level of simplicity but still there are sites around which make you go through several hoops to try and give them money. When I come across sites like that they generally don't end up received a purchase request from me. However even Amazon.com 'one-click' ordering does not work when you have 'non-standard' requests to make. These can include shipping to multiple addresses or requesting gift wrap options. This needs an alternate method of purchase. Yet again Amazon does have this purchase method included in their site. This is an example of making things as simple as they need to be but no simpler.

Recently I had cause to contact my bank to query a transaction on my account. Previously I could contact my branch directly and speak to a personal account manager who has been assigned to me. But recently the process has changed and I now contact a call centre who deal with the query. This works very well until I have a non-standard request. In this case I was asking for a refund on more than one bank charge. I was told that I couldn't request this over the phone. Despite the fact that I had answered four security questions prior to the discussion taking place they call centre employee said I would have to make a personal visit to the bank (my branch is 200 miles away) to speak to someone personally about this so they knew it was really me... I suggest this is a case where they have simplified the process BEYOND the state where it is useful.

I would imagine that if you were to think long and hard about processes you encounter on a daily basis you would find examples of both under- and over-simplification. Case in point would be a low-cost airline I have used recently who pride themselves on having the lowest fares. They was they achieve this is twofold - 1) They get the passengers to do as much of the work as possible and 2) they charge for everything they can that is not included in the ticket price. As far as getting the passengers to do as much of the work as possible is concerned, the upshot it that their processes are somewhat confused - as evidenced by the following example:

I had one bag and a set of golf clubs. The bag had been paid for as part of the check in (an additional charge over and above the original ticket price), but the golf clubs had not. The process was as follows:

* Queue up
* Give details to check-in lady
* Show passport
* Check one bag in
* Take second bag (golf clubs) round to another desk
* Queue up
* Give details to second check-in lady
* Pay for second bag
* Receive confirmation slip/receipt
* Take second bag (golf clubs) back to first desk.
* Queue up
* Give confirmation slip/receipt to first check-in lady
* Receive boarding card
* Take clubs to a third check-in area
* Show boarding card to guard behind glass screen
* Drop clubs on conveyer belt - hope they get treated well and arrive at destination.

16 steps including three queue's to check in one bag, one set of clubs and receive a boarding card. Multiply this by 180 people on a plane (although not all of them will have additional charges to pay) and pretty soon you can see the issue with the complexity of this particular process. Compare this with a similar flight I took to the US a couple of years ago:

• Queue up
• Hand passport to check-in lady
• Put bags on belt
• Select 'Aisle' or 'window'
• Receive boarding pass
• Drop clubs on an oversized baggage belt nearby

As you can see this was significantly less hassle and more efficient. Of course looking at this from the airline's point of view there is no efficiency to be gained by changing the process. There is no financial gain to them, merely improvement in their customer service. However the airline have made it perfectly clear that their priority is extracting the maximum amount of revenue from each customer rather than providing a quick and efficient service to them. Therefore a change to the check in procedure would not benefit them at all.

Have a look around your organisation or workplace. Identify where you have overly complex processes. Would they benefit from becoming simpler?

Lessons Learned - Why do we never learn the lessons?

Image via Wikipedia

I've worked in companies in the past who insist on performing "lessons learned' exercises after each of their projects. This is an excellent idea.

When each project has finished, the team gets together and dissects what went wrong, what went right and what they would do differently the next time. The points are noted down and documented in a "lessons learned' document.

I remember after we had implemented a particular financial system (Which I came in on the back end of, I might add) we sat around the table and came up with the following points:

• Better communication of objectives
• Keep the users informed. Often!
• Identify Early Adopters and use them to move the project forward
• Build great buzz to get the project excited
• Allocate budget for celebrating success.

....(The list went on and on)

My initial thought on reading these was that they were all pretty valid and all pretty obvious. In fact I would go so far as to say that they were all common sense. (But as readers of this blog will know, I regularly remind them that 'The problem with common sense is that it isn't that common!')

Let's skip forward now about 5 years. The company had taken a decision to replace their multiple financial systems with a single, global SAP implementation. The project started and had been progressing for about 18 months. I spoke to one of the local folks who was working on it to understand what they were doing and how they were getting on. In the space of about 20 minutes I found out the following:

• Senior management had changed their minds 5 times about the objective of the implementation
• Nobody in the proposed user community had any idea what was happening with the project
• They were not involving early adopters or people who were anxious to be involved, instead they were using mostly internal project people to get this going
• Nobody had a good word to say about the project
• Budgets were so tight nobody could afford to even buy branded pens or mugs let along have a team dinner to celebrate when something was implemented. Moral was quite low.
  

About this time I started to remember the lessons learned from the previous financial implementation and I dug out a copy of the document. When I matched the problems the SAP implementation was having with the problems the previous project had I could see a very close similarity.What it meant, in reality, is that despite the fact that we had identified and documented the lessons learned from the previous project, NOBODY HAD, IN FACT LEARNED THE LESSONS. Which got me thinking: Why?

I was obvious that there were problems in the way this company ran projects. They were repeating the same problems over and over again without understanding why. They were also wasting time on capturing lessons learned as they obviously had no intention of referring to these lessons in future. Or maybe it was something a little simpler than that. Maybe it was simply the fact that there was no process to integrate the lessons learned into future projects. The documents were created and filed, but at no point in the project initiation processes was any further reference made to the previous documents. The effectively fell into a black hole never to be referenced again.

Another simple case whereby a small lapse in process had resulted in wasted time, effort and money.

I wonder how many 'lapses' like this exist in your organisation...?

The philosophy of BPM (Or 'The 3 questions you should ask yourself')

Image via Wikipedia

In today's modern world of tools, frameworks, standards and vendors it is often easy to forget that at its heart BPM is actually more of a philosophy surrounded by a lot of ancilliary detritus - at least that's my attitude when it comes to deciding what's important from a BPM point of view

As Dennis Parker from K2 said in a recent interview I did with him: "BPM is a completely overloaded term" and there is no clear definition of the term itself.

One of the key way's of ensuring success when it comes to process is to make sure you focus on the correct parts of the puzzle. It's too easy to get distracted with deciding what is the best tool to use or which third party systems integrator will provide the best value for your organisation. Don't get me wrong: Once you have your fundamentals in place and know what you want to achieve and why it is vitally important to have the right resources on board working in the right direction. This could be the correct tools, associated vendors, or system integrators, but fundamentally BPM comes down answering the following philosophical questions:

• What are you trying to achieve with your change?
• Who is responsible for making this happen?
• How are you going to manage the change in your organisation?

The last one is a key issue which is all too often left out of the equation. Change management is key to making most projects successful and BPM projects are no different. A survey I ran last year highlighted that point dramatically.

Knowing which tools to use is something that should come at the end of your BPM journey rather than at the beginning (which my experience tells me is quite often the way things actually happen). This could be a result of a couple of things. The first is that companies tend to approach BPM tool selection from two points of view. The first is the 'I need a tool for this job so I'll get procurement onto the task'. The second is 'I have an urgent need to solve a particular problem or problems so I'll get a tool to help me'. Fundamentally nothing is wrong with either of these approaches but in essence what you are saying is that you are more focused on the tool than the solution. A solution may be possible without having to resort to any sort of tool - at least not immediately.

This is why if you come to GCP Consulting I won't try to baffle you with lots of jargon or talk about all these different tools and solutions that I can help provide you (although there are several of those that we can discuss at the appropriate time). What I will do is have a detailed, focused discussion with you about what, exactly, it is you are wanting to achieve, who in your organisation is responsibly for making this happen, and how are you going to manage the inevitable change within your organisation. I firmly believe that if you don't have these fundamental concepts in place then there is nothing more worth discussing on your project. I also believe that if you have answered all these questions - or at least given them serious thought - then I can probably add value to your project with my knowledge and experience.

I would also suggest that if your are in discussion with system integrators, vendors or consultancies and they don't seem to be bothered about these questions then your project may end up being more 'interesting' than you originally planned.

So before you go off and waste/spend a lot of time looking at tools, frameworks, vendors, SI's, approaches, solutions et al just spend a few moments thinking philosophically about your project and trying to understand exactly what you are trying to achieve. Ask yourself the three questions listed above and see if any of the answers make you re-evaluate your current thinking.

Topics such as these listed above are covered in my eBook 'The Perfect Process Project" which is available here.

A big thank you to you all

Image via Wikipedia

This is a big thank you to everyone who took advantage of my 'Free Consultancy' offer. As I said in my earlier post I was astonished at the response especially in these times of economic cut-backs.

This offer is now closed for the summer. I am anticipating running a similar promotion in August so if you would like to be involved in this please drop me a line and I'll add you to the waiting list.

Remember first come, first served.