Technology within Kaizen

Nowadays, there are countless technological tools available to organizations that promise to help manage, carry out, follow up, and improve processes at all levels. However, investment in technology does not always guarantee the success expected by the organization, or even worse, sometimes hinders its operations and development.

In this article, I intend to express my views on the implementation of technology across an organization from a lean perspective.

Visual Management in the Digital Age

The main purpose of visual management is creating awareness about the state, progress, and other relevant conditions of a process. While it is true that fancy big screens showing information can be visually attractive, when too much technology is used, the purpose of the visual management can be negatively affected.

It is important for people to be deeply involved with the information they need to manage the processes; they need to own the data for the processes that they are responsible for. With the intention of reducing the waste associated with manual data entry we might implement automatic data collection systems; however, this misses the point that manual data entry often plays an important role in ensuring staff, typically team leaders and above, maintain awareness in real-time as to what is happening in their area of responsibility.

The simple act of writing with pencil and paper the current state of operations, for example, volume produced in the past hour, forces one, at least for a brief moment in time, to reflect on issues affecting production. It is the action of manually entering data that brings attention back to the key objectives of their work.

It is important to understand what needs to be measured in order to keep track of KPIs (quantities, hours, etc.) that need to be managed, monitored, and acted upon by the people responsible for the process by performing genba and genchi genbutsu activities. Sometimes technology works against these activities by detaching people from the real status of their responsibility scope, removing the focus from the responsibility and commitment and the information that is very necessary for the control and improvement of the process; or even worse, transferring the responsibility for this valuable information to the IT department because the system does not work, or they are not even trained to use it or understand it.

Additionally, it is very difficult to find the “perfect” piece of technology that covers all of the needs of the organization, and this results in additional tasks that staff must perform to somehow cover the system’s deficiencies; these extra activities are a source of error, do not add value, and therefore are a waste that also generates suspicion about the system itself, resulting in a distrust of the information provided by it and affecting the commitment of the people involved in the process.

 

My Visual Management Board

As an electronics engineer, I like technology and I am always on the lookout for new developments and their applications. Every time I incorporate some hardware into my personal or professional life, I try to get the most out of it by using it as much as possible. Particularly with my tablet, which I use extensively to take notes, edit files, and for many other activities; I am also constantly using it as my task management board, always intending to get the most out of that piece of hardware.

My task management dashboard is extremely simple and has a few rules to follow for it to operate correctly and serve me well. There are many applications available in the market capable of providing a visual task manager showing tickets (cards) that you can move from one status to another; let’s say for example from “To Do” to “Doing” status. After some research, I downloaded an application on my tablet to implement my task board, which after a few minutes was up and running.

I must admit that the software provided me with the functionalities I needed for the board to operate (almost) in the manner in which I required, at least that’s what I thought at the beginning when I only had a static overview of the board. When I started using it, I was very excited to manage my dashboard with my brand-new hardware, however, I started to detect some drawbacks. For example:

• Quick input: every time I had to incorporate a task I had to, at worst, turn on the tablet, open the app, and load the task; which led me to write the activity on a piece of paper (so I wouldn’t forget) and then rewrite it in the app – clearly a wasteful approach.
• Classification: although it is quite easy to categorize activities by their importance or urgency, many times one needs particular categories or tags for certain situations, such as when a task could not be completed on time and must be re-entered into the flow later, or when it did not have the expected results and must be performed again.
• Workload and progress awareness: since my hardware was not on 100% of the time, either because I turned it off or because it went into sleep mode, I did not always have the board in sight, so I lost track of how much work I had to do, and sometimes I invested my energy in activities (even personal ones) without being aware that I had to put my energy into the activities on the board, which was “hidden”.

As I said before, I always try to make the best use of the technology I have available, so I have tried in many ways to fix these issues. However, on some occasions, I have not been able to find a way, and for the issues that I could resolve, I realized that I had to make an extra effort (waste) to make the software fit my needs.

For these reasons, I decided to stop using my tablet and go back to my original manual dashboard. Although it is rustic and not very pleasing to the eye, it satisfies 100% of my needs and is better suited to my way of working. Further, it aligns with the concept of creating genba awareness in lean management as I can enter activities quickly, identify at a glance (without turning anything on) my workload, see the progress status of each activity and, in addition, and fundamentally, I can improve the dashboard as needed without relying on third parties. Finally, from an economic perspective, my manual method has essentially zero cost.

Technology vs. Flexibility

By design, each piece of technology performs its task or process in a particular way and obtains a result. It is to be expected that the method used is efficient and that the result obtained is effective since the technology was created for that specific purpose. On the other hand, it is the very way in which the technology operates that prevents it from changing its method or result without affecting its efficiency and/or effectiveness.

The argument “why would we want the acquired technology to change the way it operates or the results it achieves?” is entirely valid since designers and creators make technology to act in some way and we are the ones who need it, at first, to perform that action. It is in the phrase at first where the above argument starts to run into some problems.

The world, and all businesses that develop in it, are constantly changing, which affects how processes must be carried out and the results that must be obtained. From this point of view, it is in our interest to have technological solutions that reasonably adapt to these changes and allow us to adapt in a relatively simple, efficient, and effective way.

This is not easy since most of the technology we have are manufactured by third parties who, in addition to being in another place (sometimes another continent), are not always eager to modify designs, either for capacity or convenience.

Having “technological flexibility” must be part of a larger strategy that considers several variables:

Internal technology development: having an in-house technology development structure that can be applied both to the organization itself and to subsidiaries is ideal since the know-how is available within the company, where the technical details of what is needed are fully comprehended, and forecasts of volume or business changes are known. As a result, a structure that impacts fixed costs is required.

Development of local suppliers (last pillar of TPM): an alternative to avoid being burdened with this fixed structure is to develop suppliers that know and understand the ideology and technology standards of the company so that we can count on them to operate and generate technology in the way that is convenient for us.

Rational atomization of technology: large technological projects that include several processes and results are not the best option when it is time to modify or update them, therefore, rationally “atomizing” the implementation of technology helps to split the processes, making it possible to apply continuous improvement to them.

Standardization: of technologies, brands, protocols, etc.

Teamwork: with the product development department to be able to manufacture new products with current technologies.

 

An Example of Flexible Technology

During my professional career at Denso, I was fortunate to be able to work in a number of subsidiaries in different continents. Particularly in Brazil, I was able to collaborate with a production line development project of HVAC designed by Denso for Honda.

The problem was that the projected volumes were low for the entire life of the project, which made it difficult to achieve a return on the investments required. Although low-cost technology such as karakuri is always available, both the basic infrastructure of the line (conveyor, etc.) and the more complex infrastructure (test bench) were already difficult to amortize.

A few meters away from the space allocated for the new Honda production line, we had an HVAC production line for Toyota that was also a Denso design. This production line was extremely traditional and simple, it was conveyorized, had very few off-line JIGs, and was not 100% saturated over the three shifts of operation. The idea was to include the Honda HVAC volume on that line, whilst meeting the quality and volume standards required by both customers.

The technological and infrastructural simplicity of the Toyota line allowed us to make changes in the workstations (JIGs, feeding shelves, etc.) so that by applying SMED we could switch not only between models of the same customer but also between different customers and we could perform the time studies and standard work for all the products manufactured on that production line.

Benefits:

• Increased profitability of the Honda project due to the low level of investment.
• Higher return on investment for the Toyota project as more volume was produced on this technology.
• Increased saturation of the machines.
• Increased capabilities (versatility) of the associates, who were involved in producing both models, implementing SMED, maintaining the equipment, and implementing kaizen proposals at a high level.
• There was no need to hire additional personnel.
• Savings of 200m2 (approx.) of productive space, since a new production line was not needed.

 

Don’t Rush to Invest

Whether by enthusiasm, training, or apparent function, process engineering departments, technology, maintenance, and – let’s face it – ourselves, tend, as a first approach, to reach for technology to improve processes or solve problems. This approach often neglects the essence of continuous improvement and problem solving, and does little to address the root cause. Consequently, we do not see the problem or the opportunity for improvement from all possible angles (4M), which leads us to treat the symptoms or partially improve the process, with a high risk of recurrence of the problem or, in the case of an improvement, to an unstable process since the inclusion of technology only improved one aspect of the process, whilst the others remained as before (or worsened).

When we need to solve a problem or improve a process, a frequent approach is throwing money at outside solution providers. Many times we think that this will save us time and result in the best solution for what we need since, after all, the provider is the expert. However, this approach brings with it the following problems:

• Over-engineered solution
• More expensive than necesary
• Not perfect fit to requirements
• Difficult to adapt as needs change
• Difficulties or delays in repairs in case of a breakdown
• Problem-solving skills not developed in-house. Know-how is retained by the solution vendor

We shouldn’t forget that, although the supplier is the one who would know the most about the technological solution to be applied, we are the experts in our processes, and we deeply know the current situation, the goals, and the standards that must be met.

 

Blinded by Technology

In 2007, I was an electronic engineering student working for Denso’s process engineering department. To reduce the fixed costs associated with production, we were working on the material supply routes from the warehouse to the assembly lines and were presented with the opportunity to improve the routing of a logistics operator supplying the HVAC FCA (now Stellantis) assembly line.

The operator traveled 300 meters just to go back and forth from the warehouse to that line, which made it more than evident that the waste to be reduced or eliminated was those 300 meters. Immediately, wanting to show off my skills in electronics, I proposed (strongly) to manufacture and implement an autonomous guided vehicle (AGV). I convinced myself and the team that it was the best option to eliminate that waste and take advantage of that person to perform other activities.

After a few days and a relatively low investment, the AGV was implemented and supplying parts from the warehouse to the line. Proud of what we had accomplished, I had audacity to show our process engineering director, Mr. Nakamura, the work we had done.
After explaining why we were working on internal logistics supply routes, the conversation went as follows:

Mr. Nakamura: How much was the distance traveled (wasted) before the upgrade?
Me: 300m
Mr. Nakamura: And how much of that waste have you reduced?
Me: …complete silence…
Mr. Nakamura: Bertero-san, not only have you not reduced the waste, but worse, you have also automated it.

As discussed with the director after that event, there was indeed a benefit since the operator who used to perform that task was adding value in another sector, but the point here is that it was not prudent to incorporate, in that first instance, the AGV. The approach should have been to try in some total, partial or relative way to reduce the origin-destination distances of the routes so that once optimized to the maximum, the AGV could be included, in the second instance, not only to supply one line but several, for example.

 

Be Patient… But Start

Following the line of thought of not rushing, it is necessary to take the time to “manually” test the proposed solutions. In this way, we will have the opportunity to realize which is the best option for our situation since when experimenting with it we will see the important aspects that the final solution must fulfill. It does not mean that we should stay in an infinite test loop or not implement anything because we keep thinking about the best option, but rather that we should implement the initial solution and, applying continuous improvement, bring it to the ideal state.

Here is an example from the Isuzu (Metal One) Gifu Service Centre of a management board (KPI tracking) that they purposely used as a whiteboard and marker for about a year before they digitized it. Although they could see a benefit in having the information digitized and visible on a screen, they wanted first to ensure that it was useful and wanted to work with something that could easily be changed and improved during the first months of utilization.

Conclusion

From what has been narrated in this article, it would seem that I’m opposed to the implementation of technologies to manage, solve problems or improve processes; however, this is not so. Of course, implementing technology is good, and it will deliver the expected results as long as its implementation is thoroughly studied and tested.

In fact, technology by itself does not have a negative (or unexpected) impact on our organization, technology is just that, technology. We, the members of the organization, have to do our homework defining the objective, studying in-depth the current situation, and proposing alternatives to reach those objectives, among which a technological development can be included.

Each inclusion of technology must be studied thoroughly, conducting trial after trial with low-cost resources and with the participation of the people involved in the process. Following these steps, we will find that we arrive at a much better solution than if we had included a technological means purchased in the first instance. The solution will be adopted by all since it was the result of a consensus and testing period where all the aspects involved in the process were considered (4M), and it will respect the standards of the organization and be a technology open to modifications and improvements in the future. True, it may not be the most elegant solution, but it will certainly be the most efficient and effective. We have many examples of this in the company visits we have enjoyed as part of our Lean Japan Tour.

Technology? Yes, of course; as long as we fulfill our responsibility to analyze our current situation, understand what the objective is, and consider the inclusion of technology as part of the solution, not the only solution.