Autonomation and the Helper Robots

adult-ai-artificial-intelligence-1020325

I first worked with and learned Lean (with Six Sigma) in a manufacturing environment. Manufacturing is where Lean originated; used successfully for decades. I learned a great deal about Lean in that environment, but I think the most important part about Lean- the focus it requires on quality. Everyone was involved in ensuring high quality. Quality was part of the culture, it was clear that we expected high quality.

I later encountered Lean in the office environment being used in a much less dogmatic way. It was there, but you almost had to have seen it before to notice its presence. While adopting Lean has had success outside of manufacturing, the lack of focus on it is really a missed opportunity to make Lean an ingrained part of the culture.

Agile seems to be an attempt to correct that some, with Lean being a core component of many Agile methodologies; Agile really must become the focus of the culture if it is to be fully implemented.  But I am not going to discuss Agile here, but you can certainly use this within Agile or use Agile projects to implement some of it.

Instead, I am going to talk about another way to help bring Lean into your organization, and then I am going to work to convince you to make Lean a part of your organization’s culture. This probably should be split into two posts, but oh well. I made a Jidoka explainer video a couple of months ago and I really wanted an excuse to use it here.

Jidoka and Poka-Yoke

Lean itself tends to focus more on the speed and waste of the process and controlling inventory (Six Sigma is more about process variation). Within Lean is a concept that can help reduce variation and improve overall quality. It is called Jidoka.

Jidoka means autonomation (not automation). Jidoka is automation that is not designed to replace a person but to assist them in doing a better job.  It is automation that consists of five, easy to remember, steps.

  1. Discover a flaw
  2. Stop the process
  3. Fix the flaw
  4. Investigate the root cause
  5. Correct the root cause

Jidoka in manufacturing requires creating some way to help the machine detect a flaw in produced parts and when detected, shut the machine down. This is now done with various sensors that allow for quite a lot of error detection ability.

What about in the office, how is it possibly useful?

Mixed with the idea of mistake proofing (Poka-Yoke), it can help improve just about any process as long as you can identify four things:

  1. The process flow (flow of information or product)
  2. Defined individual processes
  3. The output of each process
  4. Identified areas that can be improved within the process

The moment I say this, I will probably be proven wrong, but you cannot completely get rid of people in every single job role (yet?). It is possible to help a lot more people do their job more efficiently and at a higher level of quality. You may have to think a little bit differently to pull it off, but putting it into practice could give you a bunch of little helper robots, running around telling you the answers and stopping you if you get them wrong.

Brief Explainer Video on Jidoka

 

Some Office Based Ideas

Those who have worked with me or know me personally may know a bit about my hatred of the overuse of Excel files. Excel has great uses, but it is not a database and it should not be used like one. That being said, a lot of companies still stretch the uses of Excel and quite simply won’t or can’t spend the money to build a better system. So number one on my list – utilize some of the features of Excel to help you.

Excel has the built-in ability to create applications that help control the Excel file you are working on, interact with other Excel files, interact with other Microsoft Office applications, interact with web pages, and more (Access, PowerPoint, Word etc. also have this ability). It can be a nice cheap alternative to more expensive options (it can also be a nightmare that is affectionately known as “Excel Hell”, so be careful).

  • Utilize Excel VBA (or any Microsoft Office applications VBA ability)
  • Use Web API’s for internal applications
  • Take advantage of screen scraping technology
  • DOM for web applications allows for external applications to enter in data
  • Built-in features of an application to help prevent error entry
  • Develop automated alerts when errors are detected
  • Consider full blown robotics tools such as Pega (OpenSpan) and UIPath. These are way more impressive than Excel VBA

I have also seen HP UFT used to fill out and populate legacy desktop applications as part of standard operations. I personally wouldn’t recommend that one, at some point it just becomes cobbling garbage together – but it actually worked. I can’t really fault something that actually worked, improving both quality and time spent on the process. You sometimes have to work with the tools you have on hand I guess.

A Change of Perspective

Most likely, you have already seen some of this in action. The web form that reminds you that you forgot to enter in a value for example, or maybe your company has already embraced tools like UIPath. You probably didn’t know there were names for it from a Lean perspective. Their inclusion may not even have been motivated by these concepts. That is where the problem is I think.

Something amazing begins to happen when you have an idea, define that idea, and give it a name. You begin to think about it as an entity and it can help change your perspective (you can also debate people about small nuances with it online, but that is a different issue and I only do it with Agile… usually). When I worked in manufacturing, quality was treated very differently. It was always there, and it had names to define it. Within more office-oriented environments, these names are not readily present and not part of the culture.

If we could define the terms within the office environment, we could change the perspective. Instead of explaining a big long automation process, we could bring up Jidoka or Poka-Yoke and have people understand it. They become familiar with the names and begin to think about things in terms of the entity of Jidoka, Poka-Yoke, or even Kaizen and Kanban.

This can have the benefit of, instead of reacting to a problem, proactively trying to stop problems from happening. Why do we include alerts on forms in the first place? How much of that was proactive thought vs. we saw other people doing it vs. we had complaints about it? How do you go about organizing the effort to implement these features? Do we even know which fields are most likely to be filled out incorrectly?

We can ask dozens of questions about these processes, but if it lacks a structure it can become haphazard guesswork. We also lose some ability to react to problems because we haven’t made quality the focus, and when users encounter these problems they may not always raise flags about them. They may just take the process as some unmoveable and unchangeable object they have to deal with.

To put it another way, the users of your systems and processes are your operators. Their work outputs are the manufactured products. They either think about things that can be done to improve the product/process or they don’t.

Reflection

Office work contains some tedious aspects. Some of those aspects may be able to be eliminated, others could be improved upon. You don’t always need artificial intelligence to gain some benefit from detecting errors or providing assistance during the task to help prevent errors (called Poka-Yoke or mistake proofing). Your improvement ideas could be as simple as shoving some VBA into an Excel file to help fill out the Excel file faster, or it could be as complex as building an automated tool to populate applications based on different documents.

The important takeaway here is to remain focused on the quality and waste reduction by defining tools you can use to improve both. Once you start looking and thinking about things from a quality-centered perspective, you will begin to get a lot of ideas on how to improve. You may just need a little technical help to get there.

 

 

 

Sources

Images from https://www.pexels.com

 

Additional Information

You can learn about Lean and its use in Information Technology here: https://www.leanitassociation.com/.

Lean principles in the office: http://www.velaction.com/the-principles-of-a-lean-office/



Categories: Lean Six Sigma

Tags:

1 reply

Trackbacks

  1. A Tale of Two Kanbans – Agile-Mercurial

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: