I have done some more thinking about an approach that would produce significant Lean benefit without having to issue an RFP. I shared this thought with a young man I had a discussion today about Strategic Lean Thinking.
Early in my executive career, I made a mistake and authorized purchase of a software solution to our payroll process. It was implemented without Kaizen and standardization of our processes. In much later payroll Kaizen, my team asked me to suspend use of the software. It turns out that the minimum cost was 2.5 days of waste per week (18.75 hours a week or 975 hours annually). Our payroll clerk had to come in very early to communicate with the software consultants and stay late to complete the work within our process to ensure payroll was made on Friday. I was unaware of the added stress our software purchase cost our employees and our finances. 975 hours at an all inclusive rate of employment at $50 an hour is $48,750 annually. We paid slightly more than $40,000 for the software and invested a lot of time installing, maintaining and training for it. The expense was considerable, but we did not sufficiently keep track of the cost our software contributed to company waste. It was substantial. The same is true of our inability to assess the waste associated with the ongoing use of our payroll software. We did not construct a current state that included other waste from other parts of our organization.
I made a mistake early in my career looking for a software solution before we has assessed our existing system, stabilized it, and created a future state that might have included software at a time when it would have added value. Software, in my experience, should only be added to a process when the process is stable, has eliminated a lot of waste, and can take over repetitive processes that don’t require judgement. People can generally perform as good or better in a Lean improved process than in a non lean automated process. I admitted the mistake because that is what Lean Practitioners do. And I learned from it, because that is what Lean is all about.
Applying this lesson to the RFP was a wonderful teaching opportunity with this young man.
The RFP reference a process manual and a backlog of 10,000 applications. It asks for what appears to be Kaikaku (rapid improvement instituted by a Sensei) and not Kaikaku. The pressure seems to be a less than successful software implementation. Although I hope I am proved wrong, I did not see a pathway to success as a lean project in the RFP. What I saw was a desire to recover from a software implementation that was not properly timed. The potential cost is $800,000.
Without knowing any more details that shared in the RFP, I would propose an alternate solution. It should cost far less than the $800,000. This proposal would use existing resources with a smaller improvement window. The client needs to hold a Kaizen to look at the application process(es). In a well planned week, you can actually look at a number of processes through a team of about 10 to 12 people. The education portion of a Kaizen is attended collectively with breakouts of 6 people into 2 mapping sessions. By the end of the week, at least 7 proposed improvements have already been started. What would I need to know in order to see improvement? Here’s the progression. What is the Takt Time. That is, how many applications are received in an average week and what is the distribution of receipt. Once we have a current state map in place, we will have an idea of what cycle time is. We will have identified the waste existing in the system (as they say, at least good enough for government work), what the average cycle time is, and begin looking at how we can eliminate that waste and reduce the cycle time. Batching is probably one of the wastes. There will be many others. As we work on the Future State, we will propose at least 7 strategies for improvement, and by the end of the say Friday will have starting working on one or more of them. At the end of the process, we will know a target reduction for cycle time. We used a completely speculative example to discuss this. I suggested that cycle time was 20 minutes, and we could reduce it to 10 minutes. I also used 480 as the Takt Time. That’s because there are 480 minutes in an 8 hour work day. This meant we needed to clear 480 applications a day to avoid a backlog. A 20 minute cycle time meant an ability to clear 24 applications a day per employee, which would require 20 employees to accomplish. If we reduced the cycle time to 10 minutes, we would need only 10 employees to achieve the same result. In my experience, that is very much achievable.
With 10 employees freed up on a daily basis, we could then use a few of them to improve other parts of the process. And for training. At this point, we are accumulating savings. I used an $80,000 annual cost (rounded to $40 per hour for ease of calculations. Every day (8 hour days) produces $3,200 in savings ($800,000 annually). That’s the cost of the contract, but we will achieve some much more than the RFT anticipates. What’s the upfront investment? Hiring a Sensei for the department. The cost is likely to be about $150,000 plus expenses. The savings accrue rapidly once the backlog has been eliminated. 10,000 backlogged applications, spread out among 10 employees with a cycle time of 10 minutes, will take about 21 days, or 4 weeks of work.
The cost of eliminating the backlog doesn’t seem to be calculated into the RFT, except through any improvements made. If we calculate one week for the Kaizen, 2 weeks for the improvements to be implemented and tested, and 4 weeks for absorbing the backlog, we will have a stable system in about 2 months and be ready to tackle the software integration.
I know it’s a bit more complex than this simple scenario, but the approach is sound. It’s one I have seen followed hundreds of times with success.
Food for thought.