3 Lean Tips to Enhance Your Everyday ITSM Activities

In the development and adoption of an IT service management (ITSM) ecosystem, people will spend many hours working on the design and development of processes, procedures, and plans. However, regardless of the best practice approach you use, no approach is prescriptive on the leadership you need to help teams be productive and effective in their design work. Instead you’ll need to find the tools, tricks, and tips that help you build trust and get things done. To this point, this blog offers up three Lean concepts that will both help the team with work tasks and enhance your leadership abilities.

While Lean originated in manufacturing, and is primarily referenced as a manufacturing framework, many of its concepts can easily translate into usable functions for other industries including the one you and I both love – ITSM. In fact, you might have already heard of Lean IT.

Lean has now been in use for many years, but it initially came to prominence as the Toyota Production System (TPS) in Japan. This has two core pillars: respect for people, and continuous improvement; and both of these things dovetail nicely into the core philosophy of ITSM.

In this blog, I’d like to explain more about how these two pillars are underpinned by three tangible working methods, three key Lean concepts, that can be incorporated into your ITSM workflows for a better way of working for everyone:

1. Pull the Andon
2. Genchi Genbutsu (Gen-Chee Gen-boot-sue) and Gemba
3. Nemawashi (neh-ma-wa-shee)

1. Pull the Andon

It’s time for me to go all international on you…

In Japanese culture, an Andon is a traditional lamp made of paper pulled over bamboo that was used simply as a light source. 

Fast forward a few thousand years and the Andon is reimagined on the manufacturing floor as a lighted notification, or alert, to management or other workers of an issue that’s affecting quality or a process problem. In the early days of manufacturing the Andon, the worker would activate the light by pulling an attached cord (like a pull light switch). Thus, the term “Pull the Andon” was born. The concept is to stop the production line so the process or quality problem can be immediately addressed.

Both event management and incident management can be tied to this concept, as both processes have the intent to “stop the line” and “fix the issue” so that quality can be delivered as part of the service package.

How to Use “Pull the Andon”

While you can have event and incident flows take care of this need in your production service environment, you should also have an Andon pull for other parts of your ITSM practice. For instance meetings or design sessions. Setting the conditions for when a pull can happen also helps the team work independently and can promote a feeling of trust in judgment.

Examples:

• A design team pulls the Andon because they are stuck in how to reach an outcome and need assistance to interpret the design package requirements.
• Team members are encouraged to pull the Andon during a team meeting when they are unclear on their role in a new objective.

2. Genchi Genbutsu and Gemba

Taiichi Ohno, who is credited with founding the TPS, also created the concept of Genchi Genbutsu and Gemba. As Ohno taught new engineers the TPS system, he would often take the engineers to the shop floor, draw a chalk circle on the floor, and ask the engineers to stand in the circle to observe the various production flows.

This methodology taught the engineers that they must go to the source of the work to understand what is really happening. The engineers were then expected to “get their boots on and go” (Genchi Genbutsu) and experience the problem or propose change in the work location (Gemba).

How to Use Genchi Genbutsu and Gemba

When you’re working on a process design or if there’s an incident in a process flow, get up out of your chair and go see the issue. Follow the data path in the tools, go talk to the people who are executing the process at their work station, and ask them to demonstrate the issue on their computer or in the manual steps. Gather the first-hand knowledge of how, when, where, and why the issue occurs.

Examples:

• A problem management team member, after reviewing trends, goes to a customer location to see how data is input into the process, then follows the data through each process step.
• ITSM team members are considering purchase of a new tool. Prior to purchase, the team schedules time with one of the vendor’s current customers to see the tool in action. 

3. Nemawashi

In the United States’ work culture (as well as many others), it’s common to hold large group meetings to discuss issues. Sometimes, these meetings do nothing more that draw battle lines, hurt feelings, and waste time. If you’re inclined to not believe this, ask yourself if you’ve ever uttered the phrase “…seems like we’re meeting to plan another meeting…”

In the Japanese Lean work culture, the concept of having many one-to-one meetings is taught. Big meetings are only ever held to ratify important decisions. The difference is that a Japanese worker NEVER goes into a big meeting without knowing the answer to the decision and if the answer is “No,” they don’t ask for the topic to be put on the agenda. This is accomplished via Nemawashi.

How to Use Nemawashi

A loose translation of Nemawashi is “prepare the ground for planting.”

The concept is simple. You go to the key stakeholders and discuss the idea. You listen to their concerns. You make adjustments to your proposal. You grow consensus. Only then does the big meeting occur with everybody standing behind the proposal.

If your proposal is not gaining acceptance, you have the choice to continue to work with the stakeholders to adjust it, or to drop the idea and move on. The whole point being, you don’t proceed on a change, new implementation, new service, or any other ITSM task unless the team is supporting the proposal.

Example: Prior to submitting a change request to adjust a process, the IT process owner meets with the business process owner, the leads of the IT processes that may be impacted, any IT senior managers, and any service owners. Once the process owner has a consensus, the change will be supported, then a change record is submitted.

These Lean concepts could be very useful in your daily work. One should note, however, as with any new method or tool you try, it can take time to mature. You’ll also need to determine how to fit Lean in with your working style and the additional value it’ll provide for your team(s).

If you can find ways to integrate these concepts into your daily activities, they will be a platform from which to build better working relationships, build trust, and improve your leadership abilities.

Finally, if you want to read more about blending Agile, Lean, and ITSM for better business outcome, then this blog is for you.