RPA and Lean, A Must

I have read a number of papers and articles on the reasons RPA projects struggle or fail and have personally witnessed a number of struggling RPA initiatives.  For anyone that has seen a mature RPA tool in action, you will be surprised to hear that failure numbers as high as 50% are being reported.  RPA tools are very easy to use, lightweight on the network, and easy to adjust as needed.  I have seen very capable RPA bots built in less than a day and complex bots built in a couple of weeks.  So why are so many RPA initiatives struggling?

One of the key reasons for RPA project struggling and even failure is a lack of true process expertise.  Process expertise is needed in the assessment, design, and implementation of bots.  It is also needed for the bot building process itself.  To solve this problem, enlightened organizations are adopting the proven methods and principles of Lean.

In this article, I provide a quick overview of the Lean principles that apply to RPA and how, along with a glimpse into the powerful body of knowledge MSI has developed in our Lean Automation practice.

Lean Facilitation Skills: A true Lean Master has conducted dozens and sometimes more than one hundred Lean process events of various types from Lean Strategy (a.k.a. Hoshin Kanri) to Lean Design through basic Lean Improvement events.  These Lean facilitation skills are vitally important in the RPA bot building process to move swiftly to the ideal process and to get stakeholder agreement on what a bot is supposed to do and how.  In our experience, stakeholder agreement on the steps a bot will take is often the most time-consuming task in the bot life-cycle.

Value Stream Analysis: The ability to define and assess value is a vital first step in the creation of a bot project portfolio. Understanding value, defining value streams, and the subsequent analysis allows us to create an orchestrated bot portfolio that actually reduces the time from input to outcome.  This is a serious problem with most RPA implementations.  They are speeding up micro level subtasks within value streams that merely create backlogs and do nothing to actually reduce the time to value or increase throughput.  Further, the definition of Value Streams provides us a meaningful basis for measuring the ROI of an RPA initiative.

Lean Process Design and Improvement: Matrix Based Design or Axiomatic Design combined with Lean thinking enables you to create profoundly complete and capable requirements for one or more bots in a single pass when your processes need a serious overhaul. For tweaking well designed processes, Lean process improvement will help identify common mistakes such as batch processing and other forms of waste ensuring that processes being automated don’t just speed up bad processes.

Lean Work Cells: Lean Work Cells (a.k.a. Scrum Teams) should be deployed for the bot building life-cycle to ensure work is conducted at its finest practical increment and focus on production is maintained with no hand-offs. The Lean RPA Work Cell may be the most important Lean method you can apply to your RPA program. Clear accountability for bot production and elimination of bot life-cycle hand-offs is of paramount importance.

Kan Ban: Kan Ban should be used by RPA Work cells to control rate of work in a “pull system”, Work In Process (WIP), and to ensure quality specifications for each project.

One Piece Flow: One Piece Flow should be used to ensure in-process inventories/backlogs are not created, that projects are right sized, and that the workload is balanced across work cells.

Poke Yoke: Mistake proofing should be employed in both the bot life-cycle as well as the process automated by each bot. A Lean expert will be familiar with mistake proofing techniques in the digital world making a significantly more robust system.

Be warned, simply doing the same old stuff and calling it Lean will not deliver results. Hanging post-it notes on walls to map processes is not Lean. You must incorporate actual Lean expertise that is only forged through Master’s level eduction, industry experience, and industrial certification to properly adopt and train Lean methods in your organization.

At MSI, we have 18 years of corporate Lean consulting experience and numerous highly respected Lean experts. We have a similar number of years with process automation using various process automation technologies and with the introduction of RPA, MSI has become a pioneer in the adaptation of our Lean Automation and Process Oriented Design techniques into the deployment and management of this breakthrough technology.

Our Lean RPA framework contains all aspects for Lean execution of a Lean Automation program from the Center of Excellence and strategic integration with the business down to hands on Lean RPA Bot development. RPA is coming to your organization, like it or not. Many organizations will stumble and flail about for years attempting to control RPA and turn it into ROI, while those adopting a Lean Thinking approach will benefit early and often.

A subject for another article is Hoshin Kanri, the Lean approach to operationalizing strategy. RPA programs should promote the use of Hoshin Kanri within their organizations and integrate a bot candidate review process for strategic initiatives within the Hoshin Plan. By integrating RPA into strategic initiatives, RPA can propogate throughout an organization strategically, prove its value, increase the probability of success for initiatives, and increase the measurability of initiatives.

Using Lean Practices in IT, Big Savings and Performance Improvement

It has been a busy 2012 for everyone, It seems everyone I know is like me, working harder than ever, hoping the economy picks up and that our Government gets budgeting and contracting plans set and in motion.  While weathering the current economic storm, I had the opportunity to work with a client in the first quarter of this year in one of my favorite environments – IT.  I have found myself in various IT positions and consulting roles throughout my career, picking up technical skills as well as experience with ITIL, CMMi, and various development methodologies.  I have in many cases applied Lean and Six Sigma in conjunction with IT best practices to help organizations improve performance and save money.  Recently, I helped an organization shave millions in annual operating costs while significantly improving performance by applying agile work cells and leveraging a few simple Lean techniques such as one-piece-flow.  This article summarizes three methods nearly any IT support organization can use to drastically cut costs and improve performance.  Given the current economic and budget environment, this may be a timely read for some of our followers.


A graduate school professor assigns a software development final class project to teams of five students each.  All students on each five person team will receive the same grade and it accounts for 50% of the final grade for the class.  Team 1 (Sally, Jack, Dan, Tom, and Ken) and Team 2 (Bill, Dave, Will, Cindy, and Beth) take two different approaches to tackling the project. Team one assigns requirements to Sally, Design to jack, Development to Dan, testing to Tom, and presentation of the product to Ken.  Each person will perform their respective part of the project and then hand their work to the next until all work is complete and the final product is handed off to Ken who will present the final product to the professor and his assistant and the grade for the project will be determined.

Team Two decides that they will tackle each task from requirements through final presentation together, but take turns as the task leader based on the strengths of each team member.  The members of team two do not completely trust each other and want to make sure the project progresses on schedule and with high quality since it can cause them to fail the class if done poorly.  They also want to make sure they are all at the presentation to the professor just in case something goes wrong.

Which team would you want to be on? On team one, you know your part of the work, you can focus on your piece and the roles and responsibilities are clear.  On team two, the roles and responsibilities are blurred and everyone on the team will be pounding away the entire time to create the best product possible.  Anyone that has been to graduate school knows that almost without exception, students inherently adopt the collaborative approach of Team Two.  Why do these young minds, yet to be trained by corporate master-minds and molded by policy, politics, bureaucracy, and standardization take this collaborative approach almost every time.  It is because they still have “common sense” and they feel a true sense of urgency and commitment to excellence.  They know their future is on the line with each major project.  They also know that the deadline cannot be changed, resources are constrained, and quality cannot be sacrificed.  Common sense brings them together into what Lean experts call a work cell and software professionals call a Scrum team using an agile approach.

Is this really the best approach?  Many managers will say “this approach is a waste of labor.” “By taking team one’s serial approach they can have multiple projects underway, or Work In Process (WIP) with the same labor pool, while the team two approach limits me to one project at a time with the same resources.”  This is a logical pitfall.  Managers should focus on level of effort in value adding activities and throughput while minimizing WIP.  The Team Two approach on the other hand ensures a “connection” among tasks and essentially eliminates rework within the process.  It also eliminates work waiting in queues and mitigates risks associated with single points of failure in your labor pool.

Lean/Operations Research people call this one-piece-flow in a cellular work cell system.  This article is not a lesson in Lean.  It is a message that assembly line type of thinking is simply wrong in diverse IT environments as proven by the many successful Lean/Agile Scrum implementations.  Yet, this thinking is still prevalent and still the dominant approach to tackling IT projects in most organizations.

I have worked with numerous IT organizations from the largest telecommunications companies to start-up software companies and internal IT shops and can tell you with certainty, that a serial assembly line approach is almost always the wrong way to complete IT projects.  I remember clearly how one of the telecommunications firms I worked with, rooted in old school Bell Corps thinking insisted on breaking the work of implementing new equipment at their Points of Presence (POPs) into a serial approach of power installation, rack installation, equipment installation, wiring, configuration, test, and turn-up.  They would go round-and-round trying to get vital services running with each step of the process pointing fingers at the other. Projects usually made their way to some ridiculous phone conference where the bosses of the various technical teams would accuse each other of various sins until someone higher up would finally tell them all to get their technicians to the site at the same time and don’t leave until the service is working.  In other words, they pulled together a collaborative work cell to get the job done.  The technical leads would declare victory after working nights and weekends to get the service running. This scenario would play out over and over, but the process never changed. That was well over a decade ago and I would like to believe things have changed, but from what I hear, they are only a little better.

To avoid these same inefficiencies, to improve quality, and to drastically cut costs there are three simple methods we recommend.  We call this the “Lean Agile Work Cell Approach”.

  1. Align your IT work force to customer value propositions (a.k.a. value streams)
  2. Implement a Lean centric, pull based cellular work cell approach.
  3. Adopt a unified process automation environment

Aligning your work force to customer value propositions is actually very simple.  Think in terms of the services your IT organization provides to the end customer.  For example, enterprise software projects and support, desk applications and support, and printer support.  You can also think in terms of Service Oriented Architecture (SOA).  You need to understand the Voice of the Customer (VOC) for each line of value.  You need to quantify the key metrics for satisfaction, performance, cost, etc.  You then need to align your teams and processes to these value propositions and measure everyone in them against the key metrics.

Agile work cells aligned to the customer value proposition

Creating pulled based cellular work cells is partially explained above.  As an example, consider the process of deploying new desk top operating systems in your enterprise.  If this process is done in a serial process, disconnected from the customer, you get a situation in which technical details and requirements are gathered for months, then handed off the a integrator that has to figure out the requirements and then develop integration scripts, which are then handed off to a testing team who will then get into a series of re-work loops with the integrator and after many months of testing, the operating system push will be sent to some type of distribution team that will then blindly launch the distribution process.  Alternatively, a series of small work cells containing integrators, testers, distributors, and customer technical liaisons can work together on a focused integrated project team to integrate, test, and deploy operating systems in a rapid order.  By testing at an incremental level and developing deployment scripts with an eye for testing and distribution at the same time, cycle time is significantly reduced and defects essentially eliminated.  This approach also allows for the operating system deployment team to learn from each iteration and get better with each operating system project from customer to customer.  In my firm, we have implemented similar work cells in various organizations with profound improvements in both effectiveness and efficiency.

Lastly, adopting a unified process automation platform is a powerful way to significantly reduce your IT license costs, maintenance costs, and software support costs while improving process performance.  For the last ten years, these tools have been called Business Process Management (BPM) and for the organizations that have adopted them and implemented well, great savings, process improvement, and transparency have been recognized.  The process automation environment becomes a process centric integrated development environment eliminating the need for custom software development, institutionalizing processes, but raising the need for proper IT Governance and enterprise architecture.  Today, process automation tools are available in cloud computing platforms and costs are falling precipitously.

In summary, the Lean Agile Work Cell approach to information system management creates agile work cells working in alignment with customer needs that are developing new software and managing their own work within a common process automation/development environment.  This is bad news for custom software development shops and great news for the CIO with a shrinking budget and pressure to show results.

%d bloggers like this: