Having now delivered many transactional projects I have noticed common themes repeatedly occurring. These include:

  • IT Systems that have been poorly designed or operated
  • Inadequately thought through policies & procedures
  • Opaque, non-existent or duplicate processes
  • Lack of viable information on process performance

But there is one area I would like to focus, decision points. People play a big part in the execution & success of many transactional processes. Every day, many times over, they need to rapidly assimilate a situation and make the right decision on what action to take for success.

Consider a manufacturing process; say a bottling factory continually producing 20-40% defective products. I suspect that would seem unbelievable. They may well go out of business. But in a transactional environment that kind of defect rate is not unusual and can sometime go much higher.

Take a look at a generic example, the IT Helpdesk; this front-line support team receives numerous requests each day. They review the details and forward the request to the relevant technical support team.

The core value-adding element here is to understand the issue and deliver it to the correct team. What sort of influences impacton correctly making that decision?

  • Staff Training, Skills & Experience
  • Policies & Procedures
  • Information Available
  • Incentives

Now imagine the IT Help Desk’s primary metric is based on the time taken to pass a request on. The business is looking for efficiency, do it quick…..no quicker…..no quicker than that!

So here we are at the most vital part of the process, the key point where the person is evaluating and making the decision, they are adding the value and what happens, they rapidly scan it and forward on to the most likely candidate, job done, service level hit, a new defect has been created. Into the rework loop we go, technical team A calls technical team B to see if they should have got the request, they then call technical team C to see if they will take it. Technical Team A passes the request onto Technical Team C (the hidden factory).

But it’s a balancing act between being effective and being efficient? Can’t have unlimited time the business can’t afford the cost.

Being effective means securing the right outcome, getting the request to the right team. Being efficient means securing the right outcome, with the minimum of waste, expense, or unnecessary effort. A process that is not firstly effective can never be efficient no matter how cheap it is to run (look at Rolled Throughput Yield).

And this is why Lean & Six Sigma combines so well in a transactional environment. The Six Sigma part focuses on the root-causes for ineffectiveness it provides a wealth of tools to understand and address the vital few. The Lean part strips the waste out of inefficient processes. Does that mean you go DMAIC and include Lean or Value Stream Management and include statistics?I think its about removing the defects then speeding the process by removing the waste, but its different for every project.

About the Author