RPA, The Lean Six Sigma Game Changer

If you are a Lean Six Sigma Black Belt, Master Black Belt or another type of process engineer / business process reengineering expert, you need to be aware of and get smart on Robotic Process Automation (RPA) technologies.  As a Master Black Belt that has participated in hundreds of process improvement projects in a career spanning more than twenty years, I have seen process improvements attempted in practically every manner possible with varying degrees of executive support, stakeholder commitment, etc.  This is not a post on the importance of leadership commitment or approach.  Plenty of articles and papers are published on those topics.  This is about a technology that will become part of every business computer user’s world within the next five years and it is targeted directly at creating efficiency.

I can tell you that without question, the most successful Lean Six Sigma projects I have been part of all embraced technology as a means for implementing improvements, measuring performance, and driving continuous improvement.  They often leveraged Business Process Management (BPM) or workflow technologies as a program-wide platform.  While very successful, these projects often take longer and require serious dedication from the process improvement team.  They also require an LSS Black Belt capable of Systems Thinking (not all are) and comfortable with technology.


With RPA this is all about to change.  Even in its infancy, RPA is a user-friendly technology that allows users to build digital assistants that automate pretty much any task performed on a computer.  It is like having a multiple application macro builder that watches what you do and then does it for you, over and over again.  For example, one can very easily build an RPA Robot (a.k.a. a bot) that reads all the emails sent to your inbox on a given day, moves all the ones from your retailers into a separate folder, then identifies all the ones with the word return anywhere in the email, then copies all the return forms into a folder, and then copies all the relevant data from each return into an Excel spreadsheet that totals the amounts, and then emails you or sends you a text letting you know that the daily items return list is ready for action with the total number of items in the list and the total dollar amount.  If you want, you could even have it post the returns to your accounting system.  This would all happen within seconds of launching the bot each day rather than the hours it would take to perform by hand.  Other common applications include collecting invoices from vendors and creating consolidated bills for building tenants or collecting personnel data on a single form and then having a bot post it to numerous internal IT systems rather than entering into each system manually.  Bots can take scanned applications, merge them with electronic applications, and then disseminate the information to other systems or create additional documentation and analysis based on the inputs.  Industry is recognizing tremendous savings already in call centers and large-scale financial service centers.  Corporations at the Intelligent Automation Conference in Austin last week including Kraft, Coca Cola, and John Hancock were reporting saving tens of thousands of man-hours and we are aware of Federal Agencies targeting man-hour work reductions on repetitive tasks in the tens of thousands for FY19.  This is just the tip of the iceberg.

I am personally interested in investigating the application of RPA to the massive wave of FOIA requests submitted to the Government each month.  Imagine if a bot simply read each request and then did a scan of each relevant agency system and file server for all related content and then ran a scan for sensitive content and then placed the information in a staging folder for someone to review prior to release.  The Government annually spends millions responding to FOIA requests and rarely meets statutory timelines.   RPA could be a game changer.

If you are like me, you are probably saying to yourself: “This sounds like task automation, not process automation.” If so, good job.  You are right.  RPA is really more about automation of repetitive tasks, not processes with all of their handoffs, business rules, waiting, rework loops, etc.  Other technologies such as BPM and Workflow platforms are very good for that and RPA bots can operate well underneath a workflow technology.  This does not mean that RPA is not a process tool. What it means is that people will be using RPA to automate tasks in silos, or worse, creating the appearance of process improvement and reducing the need for process improvement projects, because they will be reporting a tremendous reduction in man-hours and cost.  If you have read The Goal or you are a process improvement expert that understands Lean, yield, and throughput, you understand how dangerous this could be if real process experts are not involved.

RPA can and should represent a breakthrough for process improvement professionals around the world.  We can leverage RPA to drive significant savings and efficiencies as mentioned above.  We can clearly articulate and execute implementation of process improvements.  We can reduce the LSS project timeline and drastically reduce the need for training.  We can implement a well-constructed architecture of bots that provide real-time process telemetry and drive continuous improvement.  Heck, we can finally start doing SPC and SQC on soft processes!   We can stop process users from blaming the lack of integration among IT systems as the reason they cannot implement efficiencies.  RPA can represent the tangible execution of Improve and Control phases of the DMAIC methodology while getting LSS projects back to a more agile and focused outcome oriented endeavor like they were meant to be.

Alternatively, RPA can be a major blow to our profession by creating the illusion of process improvement when in fact it is really only isolated tasks being improved.  I find that unacceptable.  Process improvement professionals need to take a leadership role in the adoption of RPA within every organization, they must play a key role if not the lead role on all bot implementations, and must ensure RPA deployment creates a more value-centric and measurable enterprise.  There are already numerous articles posted by experts on the extreme importance of process improvement when implementing RPA, see below.  We as process professionals must head the call.

If you are a process improvement professional here is what you need to do.

  • First, start reading on the topic.  You know how to do that, Google it!
  • Second, go to one of the free online training sites provided by vendors such as UiPath and take their free online training. You can get to the point where you can build simple bots on your own with the free training.
  • Third, start asking around about RPA in your organization and do what you can to make sure your CIO and Chief of Process Improvement are collaborating on the topic.  Your CIO is surely already aware of RPA. They must ensure a process improvement expert is on every RPA project.
  • Fourth, ensure your process improvement shop is establishing the standards and practices for process automation from assessment through control of each bot
  • Fifth, begin a campaign to make RPA a standard part of your continuous improvement toolkit such that all Black Belts are trained and able to use it in projects and events.
  • Lastly, via your gate review or some other project review process, ensure RPA is being considered as a tool for improvement on all existing process improvement projects.

As people see the power of RPA when combined with our knowledge of process and our facilitation skills, the entire practice of process improvement will take a giant step forward.

Here are a few links on RPA implementation. You will see they all refer to process selection, design, and change management.

7 key reasons why Robotic Process Automation can fail

Why RPA implementations fail

8 keys to a successful RPA implementation

Three factors for RPA implementation success

10 step RPA Implementation Guide: Pitfalls & Best Practices

What RPA Governance Model is Right for You: Take the Quiz and See

Agile Process Improvement

One of my favorite sayings is “if you want to learn somethig new, read an old book.” For years now, we have been hearing about this thing called Agile Development. It seems there are numerous definitions of what that is and even more variations of Agile in practical execution. I have seen everything from rigid compliance with modern Agile Development standards such as Agile Unified Process to stumbling through a series of high paced mistakes and calling it an Agile approach. The relevance of an Agile approach to software development in the modern age is clear. Numerous forces have converged to make the case for Agile very compelling: Cloud based systems; rapid technological change; useful standards; platform based development; and a growing knowledge gap between IT experts and business leaders. We have all witnessed or at least heard of high profile software failures using drawn out design engineering and waterfall approaches to software development. Examples include the massive Government HR systems, Global Combat Support Systems, and a countless number of industry ERP systems.

Many Agile Development texts, sites, etc. make the connection between Lean and Agile, recognizing that philosophically, Agile is an attempt to make a modern adaptation of agile process improvement methods developed by the likes of W. Edwards Deming, Walter Shewhart, and Joseph Juran as far back as 60 years. Yep, that`s right, Agile is not new. Oh sure, there’s a bunch of new terms and techniques and an emerging mess of beuracracy the merit of which is debatable, but the core value of Agile is the nested set of Agile experiments executed in concert as a learning system to drive superior outcomes in short order. My first exposure to effective implementation of Agile Software development was from a speaker at a Lean conference in 2011. The CEO of Menlo Innovations, Richard Sheridan gave a fantastic speech on the Lean agility that his company was using to reduce mistakes, meet schedules, improve culture, and drive learning. What they were doing was clearly rooted in Lean principles and concepts such as cellular work, one piece flow, in line quality, and visual management.

Now for the irony, the plethera of so called process improvement experts haunting the halls of our corporations and Government agencies are still stuck in the dogma of highly formal, sluggish methods such as the DMAIC. Our consultants regularly see process improvement efforts that span 12 or even 24 months to implement improvements that were generally conceived at the start of the project. In my role as a Master Black Belt for a client, I recently sat in on a final tollgate review so that I could bless a project and allow a trainee to receive his Lean Six Sigma belt certification. This particular project involved simple change of process and policy in only one region, yet took two years to complete. The team rigorously used analytic tools and went through methodology toll gates. After the presentation was over and I did my obligatory questioning on tools, measurements, and ongoing improvement it was decided the project was compliant and the trainee would be annointed. Afterward I asked the trainee if what they implemented was different than what he expected on day one. His answer, “no, my team new this was how to fix it.” So they took two years to do something that could have been done in one month using a more agile approach. The marginal utility of the extra 23 months was a bit more consensus and more certainty that the changes would work, but that’s about it.

I believe one reason this happens is because we have a massive community of Lean Six Sigma professionals that skipped over the foundational principles of Quality and jumped right into DMAIC centric Lean Six Sigma. To make matters worse, many of these LSS professionals have little to no practical experience in production or management. They have made a career of being an outsider that merely facilitates other people’s improvement efforts. One does not have to think too hard to see the potential conflict of interext. As a leader in the process improvement community, I tell you there must be a change. Process improvement experts must adopt, adapt, and use more agile methods where appropriate and in my experience that is at least 50 percent of all process improvement efforts.


At MSI, we have developed and proven an Agile process improvement approach driving rapid results for numerous clients. Of course, we have seasoned experts with many years of operational process improvement experience so we can see the right path well ahead of LSS belts that simply follow a methodology such as DMAIC without knowing where it is taking them or how long it will take to get there. MSI’s approach can be applied in part to isolated projects or in whole to serious transformation efforts incorporating a portfolio of improvement efforts. Applied in whole to serious efforts, the approach incorporates a rapid goal setting and high level systems thinking design endeavor to paint a clear and quantifiable picture of the enterprise’s future state, we then use simplified matrix management, chartering, and reporting techniques to priorItize, launch, and track the work. The process improvement work itself is predominantly a portfolio of nested PDCA projects taking 30 days or less each. Each project cycle generates common outputs feeding control/measurement, process architecture, training, and policy. Further, each cycle improves upon best practices and informs decision making on future cycles. Hence, the approach is a rapid execution, high functioning system that learns, informs, and improves as it rolls through the enterprise. When appropriate, methods such as DMAIC and DMADV are employed for larger scale or more design oriented efforts, but they are also conducted with an eye toward agility, understanding that time is our enemy and the perfect solution may also be the irrelevent solution if it is a day late.

Simple and Effective Process Tool

This month’s post is about a simple, effective, and often overlooked process mapping technique tool called the Trans Interaction Diagram also called a sequence diagram.  I have been using these diagrams for more than ten years with great success, especially when there is a software development element to the process improvement project.  Trans interaction diagrams are great facilitation tools and they can pack a ton of useful information into a simple to understand document.  Trans-interaction diagrams are rarely taught in Lean Six Sigma classes which is a shame.  I teach all Black Belts that I mentor how to use the trans-interaction diagram and without fail, they find it to be a useful tool in Defining, Analyzing, Designing, and validating improved processes.  Trans-interaction diagrams are particularly useful in documenting structure document centric processes and structured projects.  I believe anytime software is being developed to take an organization paperless or to automate a document/project flow with a finite number of statuses the item can enter and exit, the trans interaction diagram should be used.

Trans-interaction diagrams are made of a series of vertical bars that represent the “states” in which a document or project can reside.  For example: draft, technical review, legal review, financial review, pricing, clarifications, cancelled, approved, archived.  These are all answers to the question “What is the status of the document? (e.g., application, proposal, order)”.  The vertical bars are connected by transition arrows that indicate the paths the documents can follow from one state to another.  Below each state, you can pack in loads of information relevant to software developers, policy writers, and managers.  You can include information such as who has read and write access at each state; the owner; time metrics; system actions; decision criteria; and rules.  A simple example of the trans interaction diagram for a generic paperless document system is shown below.


You can easily see how the trans-interaction diagram communicates a wealth of information about the document or project.  Personnel in your organization should be able to answer the basic questions answered by the trans interaction diagram, such as what is the status of my request?  What happens next? How long does it take? Who can help me?

The trans-interaction diagram is also a great way to facilitate people in your organization toward consensus on how things should be processed and what rules should exist in the processing.  By asking people what can happen next who can do it, why, and so forth, staff can quickly see the paths documents can take as well as the impact of not doing things right the first time.

If it is decided to automate your process using a COTS system such as SharePoint, a BPM tool, or custom software, developers can get a great start on understanding what you want as your final product through review of the trans interaction diagram and you can use the trans interaction diagram as a QC tool to ensure the developers created the software as specified.

I hope you find this tool helpful for improving your business processes.  For more information or support in using this tool, send me an email at gsieber@msi6.com.

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.

Email, Email, Email – How to Survive the Information Flood

If you are like me, there is no way you can possibly keep up with the never ending flood of emails hitting your inbox.  Career professionals today have multiple personal and business email accounts and many of the people we work with from our customers to our children’s teachers depend on email to communicate important messages.

Unfortunately, not everyone observes the same email protocols and worse there are those that abuse email or even use it for malicious intent.  In this article, I share my research and practices my firm teaches to manage the flood of emails from those that are trying to send us messages they think are important.  With this article, I will share some best practices for effective and efficient email management and ask that readers please share their knowledge on this subject, as it is still a poorly defined body of knowledge.

I have researched email management several times in recent years in support of clients and spent time researching email management on the Internet and found many articles to find the latest trends.  The first thing I can tell you is that I could find no authoritative source for email management.  There are some good articles and blogs, but nothing one would consider a real standard for email centric personal planning and management.  If someone knows of such a standard setting organization, please post a comment letting us know.

My second major finding is that most of the articles and blogs say essentially the same things.  They say things like “setup email screening rules,” “keep replies simple and brief,” etc.  Rather than repeating the guidelines, here are three of the best articles I found on the subject.




From my research and experimentation, I have found six email management techniques that stand out.  These are the must have email management techniques.

  1. Ignore email.  Important messages will get to you.  Yes, this sounds risky, but I do it and it works.  Of course, your eyes are going to quickly identify emails from important people like your CEO, your customers, and your spouse.  Everyone knows how busy you are and if they do not hear from you on an important message, they will call, or instant message, or text message you.  Of course, you need to make sure you are technologically accessible to the people that matter in your life.
  2. Set an email schedule – Read emails on a schedule throughout the day, or limit yourself to a certain number of email minutes per time period.  To get thoughtful work completed, you must take time to focus without distractions and email is distraction number one for most people.  Some It firms are not allowing email for their developers and it significantly improves cycle times, quality, and even collaboration, because they are forced to actually talk about development ideas and issues.
  3. Keep it brief – Keep all messages to one subject per email and the same for all replies.  This is very important.  Emails are hard enough to interpret.  When people combine multiple subjects, the meaning of the message is lost.
  4. Enforce proper behavior – this is one not mentioned in the email articles I read, but I use it successfully.  Essentially, it goes like this.  If someone sends you an email with more than one topic, respond to them stating that you will review and respond to their email as soon as you can, but in the future they should only send emails with one topic per email.  That way you can quickly comprehend and succinctly respond to their email.  If the person persists in sending you voluminous emails, call the person and explain that you simply cannot take the time to read and comprehend his or her emails and that if they need to discuss complex topics to please pick up the phone and call.  Remember, the inverse of behavior shaping is also true.  If you behave badly with email, then your correspondents will do the same in return.  If you send large emails, they will probably give it right back.  If you respond quickly to every email, then people will continue to flood your inbox.  Email is not instant messaging and should not be used as such.
  5. Use lists and bullets – This is a great technique for communicating the steps you want a person to follow in a task, or the items you want them to deliver on a project.  Rather than weaving items into the text of email paragraphs, simply provide a list.  Many people consider lists to come across as harsh and impersonal and perception can be reality, but they are also more concise and accurate.  It is common practice these days to ask them to pardon your brevity at the end of an email, so if you are worried about hurting feelings by listing tasks, simply post that little disclaimer and they should get over any unhappy feelings.
  6. Use follow-up flags and categories – This is a great way to ensure the important emails that require your action get segregated from the masses of the marginally valuable.  Most email clients have some type of follow up flag or star you can click to tag the email.  When you are scanning your inbox, you should go through a process of deleting, flagging, and categorizing.  Personally, I prefer deleting emails, but that is not always an option.  Flag emails that need action and sort your inbox based on flag, then received date.  You can also categorize with most email clients and use hot key to quickly

There is also one recommendation from my research that I have not tried, but it is certainly interesting.  It is to charge a fee for emails.  The example given was an executive that takes a few dollars from the department of each person that sends him an email.  Supposedly, his inbox only contained important company emails because of this practice and collaboration with his leadership team was improved.  This sounds risky, but it may have a positive effect if people talk rather than email.  If someone tries it, please let us know how it goes.

Email is and will continue to be a major part of personal and professional life for years to come.  Like all technologies, it will eventually be replaced by something more efficient and effective.  Until then, we can hope that the ways in which email is used and managed will continuously improve.

Again, please post your comments and suggestions on how readers can improve email management.

This will be my last post of 2011 – Happy Holidays!!!

Level Zero Value Stream Maps

This week’s post is about a simple tool any group of managers can use to help clarify relationships and streamline operations among major organizations in a value stream.  Level Zero Value Stream Maps or Phase Maps as they are sometimes called are an excellent tool for gaining consensus on the way things are or should be accomplished at a strategic level across organizations.  The level zero map is a high level overview documenting who owns and who supports each phase of an enterprise value stream.  It communicates things like the major inputs and outputs of each phase, the objectives of each phase, information systems used, and the major tasks associated with each phase.  Something I like to add to my level zero maps is the overall set of objectives for the value stream.  In fact, I like to do this first.  It is a “begin with the end in mind” approach to documenting the value stream and it gets everyone on the team aligned to a common set of goals.  From this start, the first pass is to move backwards defining the inputs and outputs of each phase such that you can pull the string on a single objective and see how it draws on inputs and outputs all the way back to the beginning.  The second, forward pass is to flush out the details.

The minimum set of information a level zero value stream map should include is.

  • A brief description of each phase
  • Who leads, who executes, and who supports each phase
  • Inputs and outputs of each phase (documents, etc. for back office processes)
  • Entry and exit criteria for each phase
  • The objective of each phase
  • High level list of tasks for each phase
  • Information systems used
  • Policy, manuals, or other references
  • Each phase should be numbered
  • Give each phase a meaningful title
  • High level metrics
  • Identify the variants of the value stream, meaning the different ways things enter and flow through (e.g., [micro, normal, large] or [trucks, trailers, spare parts]).  Create level zero at an level where these variants can be generically described, but make it clear that each is actually processed differently.

Creating a level zero value stream map requires some facilitation skill and it is easy to document something a bit myopic if the wrong person is leading the team, but is not rocket science.  The key is to be open minded, focus on the objectives and be willing to ask dumb questions like “Why do we create that document every time when it does not seem to be part of an objective?”

During the process of creating the level zero map, keep the notes on easel pads or a large white board.  Capture lists of the following: Problems Identified; Risks to the Desired Outcomes; Action Items; and Ideas.  When documenting the problems and risks, make a note of where they reside in the process this will be your first indication of where you may want to start working on performance improvement of the value stream.  It usually makes sense to identify the serious problems within the final outputs of the value stream and then perform root cause analysis to find the places in the value stream where those serious problems are starting.  A cluster of problems in a specific area is not enough to decide where to start working.  Make sure the problems being fixed are the ones most important to the final outcomes.

The style of flow chart used at this level varies greatly.  The best advice when it comes to style is to choose a style for your level zero map that will be consistent with lower level detailed process maps and will enable upward and downward integration of the process maps.  An example of a simple level zero is shown below.

If the value stream you work in does not have a value stream map accurately representing how business is done, you need one.  Make the development of one an agenda item at the next executive off site, or pull together a workshop with your value stream stakeholder to build one together. It is a great exercise that brings management together, develops unified vision, and can be the starting point for serious process improvement.

Note: There are formal standards such as BPMN and the Learning to See approach for documenting your value streams.  I have often found these standards are a great starting point, but not the total solution.  Do some research on these standards and come up with an approach that works for you and your stakeholders.

For more information, visit us at http://www.msi6.com

A Simple Strategic Analysis Tool

Table of Strategic Constraints – A simple tool that exposes significant constraints in enterprise processes and value chains

Large organizations often find that the internal and external functions of supply chains and value chains are at odds with each other. They battle over lead times, quality of documentation, requirements, specifications, delivery schedules, pricing, engineering plans, etc.  A common example is the eternal battle between sales and delivery in numerous industries such as telecommunications, medical devices, and construction.  I will pick on telecommunications since I know that industry well.  Sales personnel sell circuits and value added services in various configurations across the globe.  Inevitably, what was sold is reviewed by a sales engineer under tremendous pressure to get reviews done.  Working with limited information and disconnected from the reality of field engineering, he does his best to approve the sale.  Once the sale is done, it ends up in the hands of some provisioning center and assigned to field installation and configuration personnel that immediately reach out to the customer to find out what they actually want and often to tell them they can’t get everything they were promised when it was promised or maybe not at all.  The same scenario plays out over and over in Government, DoD, and numerous industries.  While we all know this exists, it is often difficult to document and communicate.  This week, I am posting about a tool any manager or leader can use to document organizational misalignment and conflicts that cause these inefficiencies.

The tool is what I call the table of strategic constraints.  It is essentially a system analysis and optimization tool that anyone can use to quickly document certain important attributes of each major function in a supply chain or value stream to easily identify where functions, departments, or entire organizations are out of alignment and possibly even working against each other.  In a process, the optimization of a step or sub process places constraints upon related steps.  Sub system optimization creates whole system sub optimization. Yet, in many value streams each phase struggles to optimize itself at the expense of others.  The result is a never ending series of myopic initiatives to reduce costs and improve performance.  To solve this, the entire process must be optimized on the whole at a strategic or enterprise level.  This will ultimately lead to sub optimal performance of the steps within.  This model analyzes the root causes or drivers of sub process optimization and myopia by qualitatively assessing the objectives and incentives of each phase of the process.  An example of a completed table is shown below.

The concept and the process are simple.  Call a meeting of managers from each of the organizations in your supply chain or value stream.  You can make this as broad or narrow as you wish.  Use some common sense.  Explain to everyone that the exercise is to help everyone in the chain, not to point fingers at any one organization.  If they are honest, they will all learn things that can help everyone to better serve the end customer and streamline their relationships.  Starting at the top, list the phases as shown.  You can also list the organizations if desired.  Now continue to work your way down one row at a time with the team.  Identify the Primary Objectives, then the cost, cycle time, and performance objectives.

The motives and incentives is where cold hard honesty is required.  Ask “what are the people in this phase really incentivized to do.”  You should see things like “avoid getting called into the boss”, “earn commissions”, “execute the budget”, “sell the inventory”.  This is an area where you can truly expose a lack of alignment with the needs of the customer.  You can also expose root causes of lingering problems.  There are no hard and fast rules for completing the table, just enter honest and meaningful information that can be compared across the columns.   Use consistent terminology across the columns of each row.  In other words, for cycle time, don’t enter “yes”, “100%”, “per metrics”.  These entries are almost impossible to compare.  Rather, enter useful and comparable information, such as “top priority”, “no concern”, “based on artificial metrics”.  In this example, one can deduce that the first phase makes cycle time a priority with the customer and the rest of the value chain either does not care or has established internal metrics they probably fudge to make themselves look good.

Completing the table will take several iterations.  Once it is complete, simply scan each row, across the columns and identify the areas in which the phases/organizations are out of alignment.  Document these problems and discuss them with the team and brief them to leadership.  The findings can also become valuable inputs for your strategic planning process.

MMAP Your Processes

This week I am going tactical with an approach I have found very helpful in creating continually improving business systems.  As a Master Black Belt, I have seen numerous high profile, high impact performance improvement initiatives.  Many of them achieved great things, delivered ROI, and enhanced careers.  Far too often though, these business systems that rose to high performance slipped backward over time into a state of disarray and poor performance.  Alternatively, they sometimes maintain initially achieved performance levels, but do not continue to evolve.  MMAPing your process is a simple guide you can use to establish a process management framework ensuring long term continuous of any business system.

No, MMAP is not a typo.  It stands for Measurement system, Metrics, Accountability, and Process.  I tell the Lean Six Sigma Black Belts I mentor to “MMAP the control phase of your project and MMAP your processes or I will not sign off on your final toll-gate.”  This is a simple approach that any business person can apply, Lean Six Sigma Certification not required.

MMAP Defined

Measurement System:  How will the inputs, operating parameters, outputs, and outcomes of the process be measured?  Ideally it will be part of an automated enterprise measurement system.  However, it can be localized or even manual recording in MS Excel.  Either way, there should be clear definition of what is measured, how it is measured, why it is measured, standardized analysis such as control charts, and definition of how to calculate values.

Metrics: The performance thresholds, control limits, acceptable values, and other specific mathematical targets the measurement system is measuring.  These metrics must be represented within reports generated by the measurement system.

Accountability: Who is accountable for the continuous improvement of the process or business system.  Who ensures the measurement system works, the metrics are relevant and accurate, who analyses the data and reports, who stewards the process to improvement when data indicates change is required?

Process:  What is the process for conducting analysis, proposing change, vetting, approving, implementing improvements, and verifying outcomes?  Examples include the Deming Cycle (Plan Do Check Act) and the Six Sigma (DMAIC) – Define, Measure, Analyze, Improve, Control.

In government and some large businesses, one can add a second P to MMAPP the process.  This second P is for Policy.  In this case, we ask has policy been updated to ensure the MMAP will be enduring and enforced over time.

It has been my experience that even very expensive Lean Six Sigma Black Belt training often under emphasizes the importance of a solid approach to ongoing control of processes.  Much time is spent on how to define  and analyze processes.  Further, the tools of how to measure process performance are typically explained well.  However, the method for tying it all together in the control phase is often missing.  I have found this simple approach very useful in providing structure to continual process management.  I hope you find it useful in your process improvement endeavors.

“Processes do not manage themselves”

%d bloggers like this: