Takt Time, Cycle Time, UPH, OEE, OLE, RTY and Productivity: Indicators That Drive Real Line Performance

Every production line produces numbers, and most of them are used too late. A supervisor learns that yesterday's output missed plan, a plant manager sees the scrap report at the end of the month, and a software team is asked to "improve productivity" without a clear definition of what that means. The fix is not more dashboards. It is agreeing on a small set of indicators, defining each one precisely, and understanding what each number can and cannot tell you.

This article covers the indicators you will hear most often in manufacturing and operations: Takt Time, Cycle Time, Units Per Hour (UPH), Overall Equipment Effectiveness (OEE), Overall Line Effectiveness (OLE), Rolled Throughput Yield (RTY), and productivity. It explains how each is calculated, how they relate to one another, and includes a small Java model that computes them from shift data. For software engineers building MES, data pipelines, or line dashboards, these definitions are the requirements. For engineering managers, they are the vocabulary for talking to operations.

Takt Time: the pace the customer sets

Takt Time is the rate at which you must produce units to meet customer demand. It is not a measure of how fast your line runs. It is the target pace derived from demand.

The formula is simple:

Takt Time = Available production time / Customer demand

If a line has 27,600 seconds of available time in a shift (after breaks and planned maintenance) and the customer needs 920 units, the takt time is 30 seconds per unit. Every station on the line should be designed to complete its work within that pace. A station with a cycle time of 45 seconds is a bottleneck, regardless of how well it performs otherwise.

Takt time changes when demand changes or when planned downtime changes. It should be recalculated, not treated as a constant.

Cycle Time: how long one unit actually takes

Cycle Time is the time from the start of one unit at a station to the start of the next unit at that same station. It is measured, not planned. Comparing cycle time with takt time shows whether a station can keep up with demand.

If the cycle time is below takt, the station has spare capacity. If it is above takt, the station limits the whole line, and any improvement elsewhere will not increase output. This is why bottleneck analysis begins with measured cycle times at every station.

Units Per Hour (UPH): output in a form people can act on

UPH is the number of good or total units produced per hour. It is a practical, easy-to-read metric for shift supervisors, and it is often the number that appears on a floor display.

UPH = Units completed / Operating hours

UPH is only as useful as its definition. A line that reports total units including scrap will show a higher UPH than one that reports good units. Decide whether UPH counts good units, and make sure every report uses the same rule.

OEE: how much of the planned time was productive

Overall Equipment Effectiveness is the standard measure of how well a machine or line uses its planned time. It is the product of three factors:

• Availability = Operating time / Planned production time. This captures stops such as breakdowns, changeovers, and material shortages.
• Performance = (Ideal cycle time × Total units) / Operating time. This captures slow cycles, minor stops, and speed losses.
• Quality = Good units / Total units. This captures scrap and rework.

OEE = Availability × Performance × Quality

A world-class OEE is often quoted around 85 percent, but the number matters less than the breakdown. A line with 60 percent OEE because of long changeovers needs a different response than one with 60 percent OEE because of scrap.

OLE: the whole line, not one machine

Overall Line Effectiveness extends the OEE logic to the entire production line, including the time lost between stations. Teams often find that each machine has a respectable OEE while the line as a whole produces far less than expected, because stations starve or block one another.

OLE is best understood as the line-level version of the same thinking: how much of the planned time did the entire line convert into good output at the target rate? In practice, OLE is calculated from the line's planned time, actual good output, and ideal cycle rate of the bottleneck. Teams should document the exact definition they use, because published variants differ.

RTY: quality across the process

Rolled Throughput Yield is the probability that a unit passes every station without rework. It is the product of the first-pass yield of each station. RTY is covered in more depth in the PCBA article in this series, but it belongs in the same conversation as OEE and OLE. A line can have excellent availability and performance and still lose a large share of its output to rework spread across many small steps.

Productivity: the broadest and most abused term

Productivity usually means output divided by input, such as units per labor hour. It is a useful concept, but it is often used loosely. "Productivity improved" can mean fewer hours worked, more units produced, or fewer defects, and these can move in opposite directions.

When you use the word, define the numerator and the denominator, state whether quality is included, and name the time period. A productivity number without those three details is an opinion.

Calculating the indicators together

The following Java model computes takt time, UPH, availability, performance, quality, OEE, and RTY from one shift's data. It is intentionally simple, so the formulas can be checked by hand.

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.List;

public class LineIndicators {

    public record ShiftData(
            double plannedSeconds,
            double downtimeSeconds,
            double idealCycleSeconds,
            int totalUnits,
            int goodUnits,
            double customerDemandUnits,
            List<Double> stationFpy) {

        public ShiftData {
            if (plannedSeconds <= 0) throw new IllegalArgumentException("plannedSeconds must be positive");
            if (downtimeSeconds < 0 || downtimeSeconds > plannedSeconds)
                throw new IllegalArgumentException("downtime out of range");
            if (goodUnits < 0 || goodUnits > totalUnits)
                throw new IllegalArgumentException("goodUnits out of range");
        }

        double operatingSeconds() { return plannedSeconds - downtimeSeconds; }
    }

    public static double taktSeconds(ShiftData d) {
        return d.operatingSeconds() / d.customerDemandUnits();
    }

    public static double uph(ShiftData d) {
        return d.goodUnits() / (d.operatingSeconds() / 3600.0);
    }

    public static double availability(ShiftData d) {
        return d.operatingSeconds() / d.plannedSeconds();
    }

    public static double performance(ShiftData d) {
        return (d.idealCycleSeconds() * d.totalUnits()) / d.operatingSeconds();
    }

    public static double quality(ShiftData d) {
        return (double) d.goodUnits() / d.totalUnits();
    }

    public static double oee(ShiftData d) {
        return availability(d) * performance(d) * quality(d);
    }

    public static double rty(ShiftData d) {
        double rty = 1.0;
        for (double fpy : d.stationFpy()) rty *= fpy;
        return rty;
    }

    private static String pct(double v) {
        return BigDecimal.valueOf(v * 100).setScale(1, RoundingMode.HALF_UP) + "%";
    }

    public static void main(String[] args) {
        ShiftData shift = new ShiftData(
                28800,      // 8-hour shift
                2400,       // 40 minutes of downtime
                30,         // ideal cycle: 30 s per unit
                880,        // total units produced
                850,        // good units
                920,        // customer demand for the shift
                List.of(0.98, 0.985, 0.99, 0.975));

        System.out.printf("Takt time:    %.1f s/unit%n", taktSeconds(shift));
        System.out.printf("UPH (good):   %.1f%n", uph(shift));
        System.out.printf("Availability: %s%n", pct(availability(shift)));
        System.out.printf("Performance:  %s%n", pct(performance(shift)));
        System.out.printf("Quality:      %s%n", pct(quality(shift)));
        System.out.printf("OEE:          %s%n", pct(oee(shift)));
        System.out.printf("RTY:          %s%n", pct(rty(shift)));
    }
}

With these numbers, the line has 26,400 operating seconds for 920 units, so its takt time is about 28.7 seconds. The ideal cycle is 30 seconds, which means the line cannot meet demand even at perfect speed. It delivers 850 good units against 920 required. The breakdown shows where the gap comes from: availability is about 92 percent, performance 100 percent, and quality about 97 percent, for an OEE of about 89 percent. The largest loss is availability, so the first improvement effort should target the 40 minutes of downtime. A dashboard showing only UPH would hide that conclusion.

Note also that performance above 100 percent is a warning sign, not a success. It usually means the ideal cycle time is out of date or the units were counted incorrectly.

Common mistakes

Several patterns consistently distort these indicators.

Mixing definitions across sites. One plant counts scrap as output and another does not. Comparisons become meaningless until definitions are aligned.

Using takt as a target for speed. Takt is a pace to match demand, not a reason to run machines faster than they are designed for.

Optimizing a single machine's OEE. A station can improve its OEE while starving the bottleneck downstream. Line-level measures prevent that mistake.

Ignoring the time base. Planned time, available time, and operating time are different. Changing the denominator changes every result.

Reporting averages without distribution. A shift average hides the two hours when the line was down. Look at the time series.

Where software engineers add value

Most of these indicators depend on data that is spread across PLCs, MES, quality systems, and spreadsheets. Useful engineering work includes:

• Capturing machine states (running, idle, down, changeover) with timestamps and reason codes, so availability can be calculated from facts rather than estimates.
• Versioning the ideal cycle times and station definitions, because performance and OEE change meaning when those values change.
• Building one shared definition layer in code, so every dashboard and report calculates OEE and RTY the same way.
• Alerting on the leading indicator, such as a station whose cycle time is drifting toward takt, before output drops.

Practical guidance for engineering leaders

Before building a dashboard, ask:

1. Who makes decisions from each indicator, and what decision do they make?
2. Is the definition of each term written down, with the time base and what counts as a good unit?
3. Which loss is largest today: availability, performance, or quality?
4. Do the numbers reconcile across shifts, lines, and sites?

If you cannot answer the first question for a metric, it is probably not worth displaying.

Key takeaways

Takt Time sets the pace the customer requires. Cycle Time shows what each station can do. UPH makes output visible on the floor. OEE and OLE show how much of the planned time turned into good output at the line level. RTY shows the cost of rework across the process. Productivity is useful only when its numerator, denominator, and time period are stated. The most valuable habit is simple: define each indicator precisely, calculate it from facts, and always break it down until the largest loss is visible.