Production Andon: When Are Andon Tower Lights Enough, and When Do You Need a Digital Andon System?

A production Andon is useful when it shortens the time between detecting a problem and getting the right person to respond, while also capturing the data needed for further analysis. At a simple workstation, Andon tower lights may be enough. With more machines, shifts, and types of disruptions, a digital Andon system may be a better fit because it records events, assigns responsibility, and provides data for OEE analysis.

The most important question is not whether to buy an Andon system, but what level of Andon matches the way your plant operates.

Andon originated in the Toyota Production System and is closely related to the principle of jidoka, the rapid detection and visibility of abnormalities followed by an appropriate response. An operator or machine signals a problem, and the appropriate people should know what to do next.

The simplest form of Andon is a visual or audible signal. More advanced solutions may include operator buttons, boards, displays, notifications, event classification, and response history.

Simply having a signal light above a workstation does not mean a plant is managing problems effectively. The real value emerges when the signal triggers a clearly defined response.

If an operator reports a breakdown but the production leader, maintenance team, or quality department does not have an established process for taking ownership of the issue, even sophisticated smart Andon software will become just another communication channel.

The decision should primarily be based on the scale of the process and the need for data analysis.

Andon tower lights are sufficient when a problem can be noticed and handled locally. A digital Andon system becomes necessary when you also need to know what happened, how long it lasted, and who responded.

This distinction directly affects the purchasing decision. In a small production area, advanced Andon software solutions may not provide value proportional to the complexity of implementation. But once a facility has dozens of workstations, visual signaling alone will eventually stop being sufficient for effective problem analysis.

The easiest way to assess the maturity of an Andon system is through six stages:

This sequence distinguishes basic signaling from a system that genuinely supports production management.

If, at the end of a shift, all you know is that a red light came on several times, you have operational information. If you can identify the workstation, event type, duration, and response, you have data you can actually use.

The scope depends on the process, but before choosing software, it is worth determining whether you need to record:

Not every plant needs the full set. Collect data that leads to decisions.

If nobody later analyzes events across ten detailed categories, that level of classification only increases the operator’s workload without creating a clear benefit. If the production manager regularly analyzes downtime by cause, however, the right categories should be defined from the beginning.

With explitia.Andon, you can record workstation statuses, their duration, status history, operators, and OK/NOK counters, among other data. The information can be presented as a timeline and through Pareto analysis of downtime.

Andon and OEE provide different types of information. Andon shows what happened in the process and how the team responded, while OEE shows how losses affect availability, performance, and quality.

An OEE score may indicate that line availability was low, but it does not necessarily explain why. Data from an Andon system can add the downtime category, duration, and location of the event.

With an integrated Andon OEE approach, you can move from simply seeing that “OEE dropped” to understanding which events accounted for the largest share of the loss and which ones keep recurring.

The way short stops are classified depends on the OEE measurement methodology and the rules used within the plant. Before integrating Andon with OEE, you need to clearly define which events count as downtime, which affect performance, and how they are assigned to loss categories.

Without consistent rules, the report may look highly accurate while still leading to incorrect conclusions.

These three areas address different needs.

Within a manufacturing plant, they can complement one another.

If the Andon system records a quality issue at a workstation, traceability systems can help determine which batches, serial numbers, or operations were affected by the event. Root cause analysis may then lead to a process change or the implementation of poka-yoke.

For a production manager, this creates a logical sequence of questions:

Not every system needs to cover all of these stages, but the data should be connectable wherever doing so has an impact on operational or quality-related decisions.

Before speaking with a vendor, analyze one production area. Take several real events from recent shifts and look at how they were handled.

Answer the following questions:

If you can answer most of these questions without checking notes or asking several people, the process is probably already well structured. In that case, smart Andon software can make data collection and analysis faster.

If the answers vary depending on the shift, operator, or spreadsheet being used, the rules should be standardized first. The software should reflect a process that your organization already understands.

The production manager determines which events require a response and what information is needed during the shift. Maintenance adds requirements related to equipment failures and technical support workflows, while the quality department identifies events related to nonconformities. The person responsible for manufacturing systems or IT evaluates integration options and how data should flow between systems.

The level of involvement of each department should reflect the actual process.

If the Andon system is intended only to signal technical failures, involving multiple departments in every configuration decision may simply slow down implementation. But if it covers equipment failures, material shortages, and quality problems, responsibilities should be clearly divided in advance.

A digital Andon system makes sense when you need to preserve event history and use it later for production management.

explitia.Andon makes it possible to track workstation statuses, status duration, operators, OK and NOK parts, and status change history. It can also work with other areas of the Production Portal, including OEE.

If you are considering implementation, start with one production line and several real events. Determine what you cannot measure today: response time, causes of downtime, ownership, or event history.

This type of analysis provides a much better basis for defining requirements than a feature list created before the production process has been examined.

A production Andon should be only as advanced as your problem-response process requires. If a signal is enough to trigger an effective response, there is no reason to make the solution more complicated. If you need data after the event to support decisions, Andon tower lights alone are no longer enough.

No. The way an Andon system works depends on the process. An abnormal condition may trigger an automatic machine stop, a stop initiated by the operator, or simply a call for support.

Yes. Andon tower lights can operate as standalone visual or visual-and-audible devices. Software is needed when you want to record and analyze events.

No. They are two separate areas. However, status and downtime data from an Andon system can support Andon OEEanalysis when the events have been properly classified and the systems are integrated.

No. Andon signals an abnormal condition and supports the response to it. Poka-yoke is designed to prevent mistakes or detect them immediately.

When you need event history, response-time measurement, problem classification, root cause analysis, or integration with OEE, traceability systems, or other manufacturing systems.