iFAKT - OEE Done Right - Measuring Overall Equipment Effectiveness You Can Actually Trust 00:00:00 Speaker: Your shift misses its production target, but the equipment report looks healthy. The crew remembers lost time and rejected packs, yet the reported overall equipment effectiveness, or OE, suggests the equipment performed well enough that nobody can explain the gap. The arithmetic might be right, but if the production window part counts or ideal cycle standard, describe a different shift from the one people actually worked, the percentage won't help you decide anything. Let's follow one hypothetical packaging cell. We'll trace its minutes and parts from machine signals to an explainable number, then ask what that number supports doing next before we calculate OE. I'd ask what decision you're trying to make. If the answer is simply that management wants a daily percentage, you haven't yet defined what the measurement needs to explain about the equipment or its losses. Maybe you're deciding which recurring fault deserves maintenance time. Or perhaps your team needs to know whether changeover work would recover more useful production than chasing a speed loss that nobody has yet tied to a specific cause. Those questions give the metric a job. They also tell you what supporting evidence you'll need, because the same overall percentage can come from very different combinations of stop time, slow running and rejected output. Here's the physical meaning I want you to keep in mind. OE compares the ideal production time represented by your first pass. Good output with the time you plan to use for production within a clearly defined equipment boundary. First pass good output means output accepted without needing another attempt or repair. The ideal production time is how long that accepted output should take at the supported ideal rate for the product and equipment you're measuring under the conditions you've defined. That gives us a useful question how much planned production time became good output? We're expressing that output in time, so we can compare what the equipment delivered with the production opportunity you actually gave it, rather than judging a raw count alone. But first decide where the measurement begins and ends. If you measure one machine, the time and output must belong to that machine. Even when the surrounding production process creates some of the conditions that affect it. A cell needs its own shared boundary. You might choose finished packs, leaving the cell as its output, rather than treating everything produced by each machine inside that cell as separate finished production to add together a connected line raises the same question. On a wider scale, you need to agree which output represents the line's result before anyone compares that result with the time available. Otherwise, different teams can calculate different answers without making an arithmetic error, right the boundary down in plain language, someone from production and someone from the reporting team should be able to read it and identify the same equipment, the same production opportunity, and the same accepted output. Now the lost discussion has somewhere to start a repair priority concerns equipment that stops when production needs it, while changeover work concerns the time and effort required to move from one production requirement to the next, speed losses lead to a different kind of investigation. You want to understand why output falls short during running time, which could call for process work rather than another maintenance task on a machine that isn't breaking down. Scrap production asks whether that output meets requirements on the first pass. Running faster won't solve that problem. If the extra production needs repair or disposal, and a higher count won't tell you whether you've gained usable output. I wouldn't choose the action from the overall score alone. I'd use the score to locate the gap, then examine the loss evidence with the people who can explain the process and take responsibility for changing it. There's also a limit to what equipment effectiveness can tell you. A machine can use its assigned production time well while producing something that demand doesn't require, or while contributing little to the orders your customers need. Next, that's why OE belongs beside delivery, cost, demand, and safety. You still need to ask whether an improvement helps the production plan, whether its cost makes sense and whether the proposed operating conditions remain safe and acceptable. A higher score isn't permission to push equipment beyond approved conditions, nor should a lower score automatically trigger more production, because the right decision depends on what you need to deliver and what the rest of the process can handle. So we'll give this measurement a narrow, practical job. It should help explain where planned production opportunity turns into lost output, with enough evidence for a production team to choose a defensible action rather than argue about a percentage. Let's put that job into an actual shift using our hypothetical cell. Before we ask which calculation to trust, we need to understand what the crew experienced and what each source of production information claims occurred during that same period. Picture the cell half way through a busy morning. In this hypothetical setup, a filler feeds sealed containers onto a conveyor and an end of line Packer groups those containers into finished packs, ready to leave the cell. The crew starts with a familiar product. Containers move through the filler at a steady pace. The conveyor carries them forward, and the packer releases finished packs while the operator checks the material supply. Then the product changes. The crew adjusts the filler and packer for the next format, replaces the packaging material, and works through the first few packs until the new format runs properly. Production resumes, but the packer stops soon afterward. A fault prevents it from completing its sequence, so filled containers collect on the conveyor until the filler can no longer send more product downstream without filling the available space. The operator calls for help while someone investigates the packer. The filler remains ready for part of the interruption. Even though the cell releases no finished packs and the crew can't complete the order. Eventually, the packer restarts and clears the accumulated containers for a while. Finished packs leave the cell again, but the conveyor then develops a recurring jam where containers transfer into the Packers feed section. Each jam takes only a brief intervention. The operator clears the transfer, production restarts, and another jam follows later, often before anyone finds a convenient moment to record the previous interruption in the shift notes. Some packs also fail the required checks. A few show problems after the format change, and others leave the packer with packaging defects, so the crew sets them aside rather than sending them onward as accepted output by shift end. Everyone agrees the shift proved difficult, but when the production supervisor brings the records together, the operator notes, machine counters and production report describe different parts of that experience in ways that don't immediately fit the operator's notes. Focus on what needed attention they describe the product change, the Packer fault, and the repeated conveyor trouble, but they don't contain an exact start and finish for every brief interruption during production, the filler counter tells a different story. It records containers passing its count point, including containers that spend time waiting between machines and containers that later enter packs the crew can't accept without further work. The packer has its own count. Depending on what its counter represents, it might record completed machine cycles or discharged packs, and those aren't automatically the same thing if a cycle finishes without releasing a complete pack. Meanwhile, the production report contains order confirmations. Those entries reflect what people booked against the orders, perhaps after checking the paperwork rather than a direct account of every pack crossing the cell's output point during the shift. None of these records needs to be dishonest. Each source answers a narrower question, and the disagreement starts when someone treats an upstream container count a pack, a cycle count, and a confirmed order quantity as interchangeable measures of cell output. Asked the operator whether the cell kept producing during the Packer fault. They remember waiting for the packer while someone reviewing the filler might point to containers produced before the conveyor filled, and conclude that production continued for part of that period. Both accounts can describe real events. The distinction concerns which activity we're measuring. Because filling containers inside the cell doesn't mean the cell delivered finished packs through the output point we've chosen for this example. So let's make that count point concrete. We'll count finished packs leaving the end of line packer with accepted packs and packs set aside. Kept identifiable rather than adding filler containers to packer output or treating internal movement as another delivery. The unit is a finished pack. If one product uses a different number of containers per pack from another, the filler count still needs that product context before anyone can compare it with the cell's finished pack count. That resolves one source of disagreement, but another remains. The crew includes the format change in its account of the difficult shift. While the production report might describe only the period after someone released the next order for production, we're now talking about different stretches of time before assigning any loss to the cell. We need one agreed production window so the product change, the extended stop, the short jams and the finished packs all belong to the same account. Start with the calendar before opening the production schedule. Calendar time includes every hour that passes, whether the cell has an order to run, a crew assigned, or any expectation of producing anything at all scheduled shift time narrows that view to the hours assigned to a shift, but a shift can contain a meal break, a reserve maintenance period, or other time when the agreed plan doesn't require the cell to produce planned production time is the window we choose for measuring that production commitment. It includes the periods when the cell should produce under an agreed calendar policy, even if an interruption later prevents the crew from meeting that expectation. Runtime sits inside that planned production window. We reach it by subtracting the stop time classified as availability loss, while keeping the original production commitment intact, rather than shrinking it whenever production becomes difficult. Those distinctions need names that everyone uses consistently. If your production team calls the entire shift available time, but your reporting team uses that term after removing breaks and stops, the discussion will drift before anyone calculates anything. Take the cruise meal break as a practical test. If the cell is expected to stop because nobody is assigned to operate it, your policy might exclude that break from planned production time before the shift begins. Relief coverage changes that expectation if another operator should keep the cell producing during the break, removing the same period would hide production opportunity that the staffing plan actually intended to provide maintenance needs. The same clear treatment a reserve maintenance window can sit outside planned production time when the approved schedule takes the cell out of production, but an unexpected repair during committed production remains lost. Production time the word planned can cause confusion here. A planned stop isn't automatically an exclusion, because you can anticipate an interruption and still need to measure how much of your production window it consumes. Our format change is a good example. If the cell needs that change to complete the scheduled product sequence, keep it inside planned production time under the measurement policy we're using for the cell, then improvement work has an honest baseline. Reducing the changeover gives production some of that committed time back, rather than merely shortening an activity that the report removed from the measurement before calculating the result. Some plants use a different reporting convention. That's something to state plainly, including which changeovers sit outside the window, so nobody compares that result with another cell whose calculation includes the same work as a loss. A genuine no demand period also needs a defined place if the business hasn't assigned production to the cell because there's nothing required. Excluding that period separates equipment effectiveness during committed production from the separate question of capacity use. Keep that unused capacity visible elsewhere. Otherwise, a cell operating effectively for a small part of the week can appear fully occupied to someone who receives only the O e percentage without its production calendar. The harder case arrives when the schedule changes. Mid-shift. Suppose the supervisor cancels the remaining production after a long interruption, then asks the reporting team to remove those hours because the cell no longer has an active order. That edit needs more than a new end time. You need the previous schedule, the time of the decision, the reason for the change, and the person authorized to approve its treatment in the reported production window. A real business change can justify revising the plan, but preserve what the plant originally committed to because a later cancellation shouldn't silently turn in equipment loss into time when production supposedly never expected to run. I'd keep an approved baseline and a versioned record of revisions that lets you distinguish a corrected scheduling mistake from a decision taken after a breakdown, without forcing either event into an unexplained calendar. Edit set that rule before the shift starts. Production, maintenance, and reporting should agree who can change the window, which evidence supports an exclusion, and how changes affect results that people have already received. Now, every minute has an agreed place. With the production window fixed and its exclusions explained, we can separate the time lost to stops from the running time used to produce output, then give each calculation a physical meaning. Availability asks how much of that production window remained after availability stops you calculated by dividing runtime by planned production time using the same time unit for both quantities. So the result describes a share of the committed window. Read that ratio as a question about time of the minutes assigned to production. What proportion remained for running after we accounted for the stops that our agreed measurement rules treat as availability losses? Performance then asks how effectively the cell used its runtime to calculate it. Multiply the ideal cycle time by the total output count, then divide that ideal production time by the runtime used for the availability calculation. That numerator deserves some care. Ideal cycle time tells us the supported time per unit, so multiplying it by the number of units tells us how much time that output represents the ideal pace for our cell. The unit remains a finished pack if the cycle standard describes seconds per pack, multiplying it by packs produces seconds, which you can compare with runtime. Once both use the same unit, we're comparing time with time rather than packs with minutes. Performance expresses how much of the recorded runtime the total output accounts for at the ideal pace, including packs that might later fail. Acceptance quality handles that acceptance question separately. Divide the first pass good count by the total count, making sure both counts refer to the same output population rather than quantities drawn from different process stages or production windows. Notice that performance uses total output, not just accepted output. Producing a PAC consumes production opportunity, whether that PAC passes or fails, and the quality factor then accounts for the share that meets requirements on its first pass. The separation gives each factor a distinct job. Availability accounts for the loss before runtime. Performance accounts for the gap between runtime and ideal time for total output and quality accounts for rejected output. Multiply availability by performance, then multiply that result by quality. Use each ratio as a fraction during the calculation and express the final result as a percentage. Once you've completed the multiplication of all the factors, the multiplication follows the production opportunity. Through those successive reductions, you're applying performance to the time remaining after availability losses, then applying quality to the output represented by that performance result, rather than taking three independent percentages and averaging them A spoken formula can sound more complicated than the process. Think through the unit's availability divides time by time. Performance also divides time by time and quality divides accepted packs by total packs from the same population. Each factor becomes a ratio without a unit. When you multiply them. Runtime appears once as a numerator and once as a denominator, so it cancels. Total count cancels in the same way. That leaves a shorter expression. For this single product case o e equals ideal cycle time multiplied by first pass. Good count divided by planned production time provided the factors use consistent counts, time, boundaries, and the same cycle standard. The shorter expression provides a useful cross-check. Calculate o e through the separate factors and through equivalent good production time, and both routes should produce the same result when they describe exactly the same production window and output equivalent. Good production time isn't a separate reading from a machine clock, it's the accepted output expressed at the ideal cycle time, which lets you compare useful production with the time committed without claiming those minutes occurred as one uninterrupted stretch. Keep the separate factors even when the shorter calculation works, they preserve the distinction between losing production time to stops, using runtime below the ideal pace, and producing output that doesn't meet first pass requirements at the chosen boundary. The overall result alone can't preserve that distinction. Two shifts can return the same OE while differing in their availability, performance, and quality, so matching percentages don't establish that the crew faced the same production problem. Let's put actual quantities into those relationships. Next, we'll temporarily hold the product an ideal cycle standard constant, so you can check every step by hand and confirm that the factors reconcile with the shorter calculation. For this hand calculation, give our hypothetical cell an eight hour production window that's four hundred and eighty minutes already committed to production, with any agreed exclusions settled beforehand, so we won't subtract breaks or other calendar allowances. Again, we'll use deliberately simple quantities. During this window, the cell records sixty minutes of stops classified as availability losses, leaving four hundred and twenty minutes of runtime for the calculation. Hold the product constant. Throughout this example, we'll set its supported ideal cycle time at one minute per finished pack, purely to keep the arithmetic easy to follow without a calculator or written notes. The cell produces three hundred and fifty packs in total. Of those three hundred and thirty six parts on the first attempt, while the remaining fourteen fail. Acceptance with no inspection results outstanding in this example. Start with availability and leave the pack counts aside for a moment. We divide four hundred and twenty minutes of runtime by four hundred and eighty minutes of planned production time, which gives eighty seven point five percent. The sixty stop minutes explain that first production even before considering output speed or acceptance, one eighth of the committed production window has disappeared into the stops included in this calculation under our agreed rules. Next, keep those four hundred and twenty running minutes in mind. The three hundred and fifty packs represent three hundred and fifty ideal production minutes. Because each pack carries an ideal cycle time of exactly one minute. Performance comes out at about eighty three point three percent. That's three hundred and fifty ideal production minutes divided by four hundred and twenty running minutes using the total pack count, rather than only the packs that passed inspection. Keep the unrounded result when calculating the final score. Eighty three point three percent is convenient to say aloud, but using rounded percentages in the multiplication can produce a small difference that detracts from an otherwise correct reconciliation. Now bring in the acceptance result. Three hundred and thirty six first pass good packs divided by three hundred and fifty total packs gives ninety six percent quality, so four percent of the output fails our acceptance requirement. We can now multiply the factors eighty seven point five percent availability multiplied by the unrounded performance ratio multiplied by ninety six percent. Quality gives an E of exactly seventy percent for this hypothetical production window. There's a simpler way to check that answer. At one ideal minute per pack, the three hundred and thirty six accepted packs represent three hundred and thirty six ideal good production minutes, compared with four hundred and eighty planned minutes. 00:17:29 Speaker: That division also gives seventy percent. Both routes reach the same answer because the stop time, running time, total output, and accepted output all describe the same window. Using one product and one cycle standard, notice what the seventy percent actually describes. The cell delivers first pass good output representing seventy percent of its committed production time at the ideal pace. Rather than running for only seventy percent of the shift, its recorded runtime is much higher than that. Availability already tells us the cell retains eighty seven point five percent of the window as runtime, but the output produced during that time doesn't fully match the ideal pace, and not every produced pack passes inspection. That's why a supervisor remembering plenty of machine activity can still receive a seventy percent result without either the activity record or the o e calculation being wrong. One useful check involves the count you enter for performance. If you use three hundred and thirty six instead of three hundred and fifty, then apply the quality factor. Afterward, you'll penalize those rejected packs twice in the final result. Another check concerns the time used for performance. Dividing the total ideal production minutes by the full planned window would include the availability loss again, even though. Availability already accounts for that reduction before the factors are multiplied. The answer should survive both checks without adjustments. We don't need to change the window, remove rejected packs from total output or round a factor until the final percentage matches what someone expected from the shift. But seventy percent still doesn't tell the crew where to begin. We've reconciled the result with the shifts quantities. The next task is to examine the losses behind those factors, starting with the stopped minutes. Stopped minute needs a beginning and an end for the packaging cell. We need evidence of when production entered a stop condition and when that condition ended, rather than a list of faults with no elapsed time attached. Treat each stop as an interval. One recorded transition opens that interval and the transition back out closes it, giving us a duration we can place against the planned production window. Only the portion inside that window belongs in availability loss. If a breakdown begins before planned production starts and continues into production, count the overlapping portion rather than charging the entire repair duration to this production window. The same rule applies at the other end. When a stop continues beyond the production window, close its contribution to this calculation at the window boundary while retaining the full interruption for maintenance and operational review. An unfinished stop still needs an honest record if the cell hasn't restarted. When someone requests the result, calculate the elapsed stop time up to the reporting cutoff and identify the interruption as still open. Duration and explanation. Answer different questions. The interval tells us how much committed time the cell lost, while the reason attached to that interval helps the team decide who should investigate and what evidence they need. Choose reason categories that support actual work. A breakdown points toward an equipment problem. A changeover points toward format preparation and adjustment, and a material shortage points toward a supply interruption rather than a failed machine. Keep those labels clear enough for the crew to use. If setup, adjustment, and changeover all describe the same activity without agreed distinctions. Different operators can classify identical interruptions differently. While each believes they're following the rules. The category should describe the interruption, not assign blame. For example, recording material shortage establishes that production lacked a required input, but it doesn't establish whether purchasing internal transport, inventory accuracy or the production sequence caused that shortage. Alpaca fault gives us another accounting problem. During that interruption, several alarms might remain active together, and the filler might also report that it can't discharge because the conveyor has filled with waiting containers, those alarms don't create separate stretches of lost time. Adding their individual active durations would count some of the same elapsed minutes repeatedly, even though the cell experiences one continuing interruption at its chosen production boundary. Built the stopped duration from the combined timeline where recorded stop intervals overlap, count their shared elapsed time once, then keep the associated alarms and observations as evidence linked to that interruption for later investigation. One interval can carry several possible explanations. You might retain the packer fault, the conveyor condition and an operator comment together while using one agreed primary reason for the availability loss breakdown without adding more duration. Sometimes the reason changes before production resumes. If the Packer repair finishes, but the cell then waits for packaging material, divide the continuous interruption into consecutive reason segments. When the evidence supports that change in responsibility, the total stopped duration stays unchanged. You're separating one part of the interruption from another to explain where the time went, not creating additional lost minutes because two teams contributed to the same production delay. Don't force a reason when nobody knows it yet. A confirmed stopped interval can remain classified as unknown, while the operator or maintenance team checks the circumstances. With its duration still included in the availability calculation. An unknown reason isn't the same as an unknown duration. In the first case, you know the cell stopped and for how long. In the second, the evidence doesn't establish the elapsed time well enough to claim a measured stop. Keep that distinction visible. When reviewing the shift, a reporting team can ask production to complete a missing explanation. But filling a reason field won't repair a missing start or end event in the underlying record. Make corrections traceable rather than silently replacing the earlier entry. If maintenance later identifies the fault, retain who changed the reason and why. So the revised loss breakdown still refers to the same measured interruption. Long interruptions usually leave enough evidence to examine this way, the harder cases are the conveyor jams that clear before anyone writes a note, because their individual durations are brief, even when the crew encounters them repeatedly. Those brief jams need a rule before they need a category. Decide which interruptions you'll subtract as availability stops, and which you'll leave inside runtime, where their effect appears through output falling short of the ideal pace. A duration threshold can make that distinction practical. For this hypothetical cell, you might classify an interruption lasting less than one minute as a short stop, while a minute or longer becomes an availability stop. That's an example, not a universal setting. Choose the threshold to suit the process and the evidence you can capture. Then document exactly how an interruption at the threshold will be treated in the calculation. Keep short stops inside runtime. Under that policy, the clock continues contributing to the performance denominator while the interruption prevents output, so the reduced count carries the loss into performance. Without a separate subtraction of those seconds, the shortstop still consumes production opportunity, leaving it inside runtime assigns its effect to performance. It doesn't give anyone permission to erase the event or treat the interruption as productive activity. Store the interruption separately when your capture supports it. That lets the crew distinguish repeated conveyor jams from slower, continuous running, even though both reduce the same performance factor under the rule we've chosen. Watch for a common accounting mistake here. If someone subtracts short stop time from runtime and then deducts another estimated short stop penalty from performance, the calculation charges the same interruption twice. The opposite mistake can hide the loss, removing those seconds from planned production time simply because they fall below the threshold shrinks the production commitment. Instead of showing how the cell used it, you can test the classification rule without changing production. Recalculate the same complete record using a different threshold while keeping planned production time, output counts, acceptance results, and the ideal cycle standard fixed. Throughout that comparison, the factors will move in opposite directions. Classifying more interruptions as availability stops reduces availability, but it also leaves less runtime beneath the same ideal production time, which raises the calculated performance factor. Total OE should stay unchanged. Under those consistent assumptions, you're moving elapsed loss between factors rather than recovering output, so a threshold edit can't honestly count as an improvement in what the cell delivered. That matters when comparing shifts or equipment. A team using a different threshold can report better availability and worse performance for the same production behavior. So compare the classification rules before drawing conclusions about either factor. Capturing the short stops introduces a separate limit. If a conveyor jam begins and clears between two signal reads a system, polling periodically might miss the interruption completely, even though the missing output still affects performance. More frequent polling doesn't automatically establish exact stop duration. You need to understand when the controller updates the signal, how the gateway reads it, and whether those reads can resolve the interruptions you're trying to measure. test that against the actual conveyor behavior during an approved observation period, compare a witnessed jam and clearance with the recorded signal changes, rather than assuming that a timestamp proves the system captured the physical transition precisely, an output gap alone needs careful interpretation. Finished packs normally leave with space between them, and that spacing can vary during ordinary machine sequences without indicating that the conveyor has jammed or production has stopped. A gap rule needs a supported normal pattern. Establish what spacing the process should produce under the relevant operating conditions, before treating a longer gap as evidence of an interruption rather than ordinary cycle behavior. Be cautious about assigning the whole gap as stop time. Part of the gap might belong to the normal cycle, and the output signal alone might not tell you exactly when the interruption began or cleared. Keep the confidence of the record clear and observed. Stop signal, a gap based estimate and an operator's report of repeated jams. Support different claims about duration, even when they point toward the same recurring problem for the crew, frequency can matter as much as duration. Repeated interventions can explain why a shift feels constantly disrupted, even when no individual jam crosses the threshold used to classify an availability stop. Use that detail to investigate without changing the accounting once short interruptions have a consistent place. The remaining question concerns the production pace during runtime and the ideal cycle used to judge it. The cycle standard deserves an engineering review, not just a database lookup. A value copied from an old product record can change the reported performance of every shift, even when the equipment and the crew behave exactly as before. An ideal cycle time describes a supported production capability. Tie it to the product, the equipment, the tooling, and the unit counted. With the operating conditions clear enough that an engineer can explain where the value comes from. Our packaging cell needs more than a product name, pack size, material, behavior, and the installed format parts can affect its achievable pace. So the standard must describe the configuration actually producing the counted output. Specify those conditions without building everyday losses into the standard approved settings. Required product properties and normal material specifications describe the production task. Recurring jams and worn components describe problems that consume the opportunity you're trying to measure. I'd ask for evidence behind the selected value engineering calculations, equipment acceptance trials, and repeatable production tests can support it, provided those tests represent the required product and operating conditions rather than an easier demonstration set up. A brief burst doesn't establish repeatable capability if the packer reaches a fast rate for a few cycles but can't sustain that pace with an approved process limits, that observation alone doesn't justify adopting the rate as its ideal standard. The suppliers quoted capacity needs context to a rated speed might assume a particular pack format, material or feed condition, so check those assumptions before applying that speed to every product assigned to the cell planning times. Answer a different question. A planner might allow extra time for expected interruptions when estimating order completion, but using that allowance as the ideal cycle would absorb those expected losses into the performance. Baseline Historical averages need the same caution. An average drawn from ordinary shifts includes whatever slowdowns those shifts contain, so it can help describe past delivery without proving how quickly the process can produce under its defined ideal conditions. Unit conversion can create an equally misleading standard if a machine completes one cycle while producing several counted units, the ideal time per unit must reflect that output. Rather than treating the whole machine cycle as one unit. Take a hypothetical molding tool with four active cavities. If each cycle releases four parts and the counter records individual parts, divide the supported cycle duration by four before using it as time per counted part. Parallel lanes require the same physical check. Establish whether a completion signal represents one lane, several simultaneous lanes, or one combined discharge. Because multiplying a cycle count by the wrong lane quantity creates output that never crossed the count point. Batch equipment needs a stated output basis as well. Convert the supported batch cycle into ideal time per counted unit using the relevant batch quantity, while keeping any separate loading or unloading allowances consistent with the defined cycle boundary. Disabled cavities deserve an explicit policy. An approved reduced cavity production configuration might need its own standard, but disabling a cavity because of damage also represents lost capability that shouldn't disappear through an unexplained master data edit keep the configuration decision visible. Record whether the standard describes the approved production task or a temporary reduced capacity condition, and retain the capacity consequence. So a performance improvement can't come solely from lowering expectations. Performance above one hundred percent is a prompt to investigate. The recorded output represents more ideal production time than the recorded runtime, which means the observed production and the assumptions behind the calculation need reconciliation. Check the physical quantities before changing the standard account in containers paired with a cycle time per pack, a lane multiplier applied twice or output assigned to the wrong interval can all inflate the result. Then examine whether capability has genuinely changed. A proven process improvement might support a faster ideal cycle, but adopt that revision through an engineering decision with an effective date rather than editing the value until the percentage looks comfortable. Don't hide the discrepancy by capping the result. Retain the calculated value and flag the inconsistency because forcing it down to one hundred percent removes evidence that could reveal a count problem or an outdated standard speed still leaves an acceptance question unanswered. Once the ideal cycle accurately describes the production task, we can assess whether the resulting packs meet requirements on their first pass, rather than treating every completed pack as usable output. Acceptance needs a precise location in the process. For our packaging cell, define which checks. Establish whether a finished pack meets requirements at the chosen output boundary, and which later findings can revise that decision. A discharge sensor can't establish that acceptance on its own. It can confirm a pack passed its sensing point, while a seal, check or packaging inspection supplies the evidence that the pack meets the required specification. Give each produce pack a clear quality status where individual identification isn't practical. User controlled batch or quantity record that separates accepted output, rejected output and output still awaiting a decision without overlapping those quantities. Scrap and rework need different records. Scrap leaves the usable production population permanently, while rework enters another activity intended to bring the pack into specification after its first attempt failed. The required checks both consume first pass production opportunity, but they create different follow up work. Keeping them separate lets production distinguish material disposal from additional processing, rather than combining everything into a reject total that conceals what happened to the packs afterward. Startup output belongs in this account, too. If packs produced during format adjustment fall within the agreed production window and counted process boundary, their failure to meet requirements remains a quality loss rather than an unrecorded allowance. Define what counts as a produced pack during those trials. Loose material used for adjustment doesn't automatically become finished pack output, so the crew needs a consistent rule that distinguishes process waste from completed packs. Entering the quality calculation rework creates a particular risk at the discharge counter. Suppose an operator repairs a defective closure and sends the same pack through part of the cell again, where it crosses the output sensor for a second time. That second crossing isn't a second newly produced pack preserve the connection to the original production record, so the extra sensor event doesn't increase total first pass output or turn a previously failed pack into first pass. Good output track. The successful repair as recovered output. Instead, the business can recognize that the pack eventually becomes usable, while the OE quality record continues to describe what the original production attempt achieved without repair. This requires a practical way to identify repeat processing depending on the equipment that might involve pack identification, a marked rework batch, or a controlled rework mode whose output remains separate from newly produced packs. Pending inspection needs its own treatment rather than an optimistic assumption. If a pack awaits a required result, the record should preserve that unresolved status until the authorized inspection decision establishes whether it passes or fails. Don't silently treat pending packs as either accepted or rejected. Publish the quality result as provisional or incomplete under an agreed policy with the unresolved quantity clear enough that nobody mistakes an unfinished inspection for a settled production result, inspection time and production time can fall in different shifts. A laboratory or quality team might enter a rejection after the packaging crew leaves, but that finding still belongs to the packs produced earlier rather than the shift entering the result. Attach the finding through a supported production reference. A serial identifier, batch identifier or bounded production quantity can establish that connection, provided the reference actually distinguishes the affected output from other packs produced nearby. Avoid assigning a late rejection to whichever order is currently active. That shortcut can charge today's production for yesterday's defect, leaving both shifts with misleading quality results. Even though the plant's total rejected quantity remains unchanged, some findings cover a batch rather than individually inspected packs. Apply the authorized batch disposition to the affected quantity while retaining whether the decision came from individual checks, sampling or another approved inspection method. A correction should preserve the earlier status and its supporting evidence when quality changes a disposition record, the affected production reference and the reason. So the revised result explains why accepted output increased or decreased after the initial report. The cell's quality account now follows production rather than paperwork timing. Each pack contributes once to its original production population, and its acceptance history explains whether it qualified immediately required rework, became scrap or still awaits disposition. Different products introduce another question about combining those results once the shift contains packs with different ideal cycle times, the accepted quantities represent different amounts of production opportunity, which changes how we combine the shifts. Quality contribution a mixed product shift needs a calculation that preserves each product's production requirement. If we combine all the packs first and apply one cycle time afterward, the result can change simply because the crew runs a different product mix. Split the production record into segments before combining anything. Each segment needs a stable product and applicable ideal cycle standard and the same measurement boundary, so it's counted. Output has one clear conversion into ideal production time. 00:35:27 Speaker: A segment doesn't have to last an entire order. If an approved configuration change introduces a different cycle standard partway through production, close the earlier segment and start another. Rather than applying either standard across both conditions, keep the time between product runs in the shift account. Segmenting output lets us apply the correct standards. It doesn't remove change over time or leave inconvenient minutes outside the planned production window used for the overall calculation. Consider a separate, simplified mixed product example within our hypothetical cell. Suppose a small pack format has a supported ideal cycle of half a minute per pack, while a larger format needs two minutes per pack. Under its defined conditions, the cell produces one hundred packs of each format. The small packs represent fifty ideal production minutes, and the larger packs represent two hundred, giving two hundred and fifty ideal minutes for total output across both runs. Equal pack counts now represent very different production requirements. That's why adding the packs and choosing the standard from whichever product ran last would give a result driven by a reporting shortcut rather than the work completed. Apply the same conversion to accepted output within each segment. Multiply each product's first pass good count by its own ideal cycle time. Then add those good production minutes to obtain the numerator for the mixed product. OE calculation. Let's give the two formats different acceptance results. Suppose ninety small packs pass on the first attempt, while all one hundred larger packs pass. With every quality decision settled for this particular comparison, the accepted small packs represent forty five ideal production minutes. Add the larger packs, two hundred accepted ideal minutes, and the shift delivers two hundred and forty five ideal good production minutes from the two product runs combined. Divide that total by the shifts planned production time. The denominator still covers the agreed production commitment, while the numerator now preserves what each accepted pack represents. Instead of treating. Unlike packs as equal amounts of work, we also need the separate factors to reconcile. Calculate mixed product performance from the summed ideal time for all output divided by runtime, rather than averaging the performance percentages reported for the individual product segments. Quality needs a matching time basis for that multiplication. Divide the summed ideal time for first pass. Good output by the summed. Ideal time for all output. So the performance numerator cancels against the quality denominator. For this example, that quality contribution is ninety eight percent. It's two hundred and forty five good production minutes divided by two hundred and fifty. Total ideal production minutes. Preserving each product cycle standard throughout the calculation rather than mixing time with raw counts. The raw count based quality result tells a different valid story one hundred and ninety accepted packs out of two hundred produced gives ninety five percent, which describes the share of physical packs accepted without waiting their production requirements. Keep both measures. If both support useful questions, label the raw result as first pass acceptance by count and label the time weighted result clearly as the quality contribution used to reconcile mixed product OAE through the separate factors. Neither result needs to replace the other. The count measure describes how many packs pass, while the time weighted measure describes how much ideal production opportunity remains in accepted output across products with different cycle times. The distinction becomes clearer when you examine the rejected small packs. There are ten rejected units represent five ideal minutes, so the OO quality loss reflects five minutes, even though those units account for five percent of the total pack count. These rules depend on knowing which product produced each quantity before trusting a mixed product result. We need to establish whether the machines available signals can support those segment boundaries and counts, rather than assigning product context after the calculation. I'd begin that signal review with the controls engineer and an operator. The Programmable Logic Controller, or PLC executes the machine's control logic, but the signals available for reporting reflect what that logic needs to control, not necessarily what an OE calculation needs to measure. A tag name is a starting point, not proof. Before choosing signals, ask someone to explain the physical event behind each candidate and demonstrate when its value changes during an approved observation of the machine. Start with the cycle complete signal on alpaca. Ask whether that signal means the mechanism finished its sequence, the discharge opened, or a sensor confirmed that output actually passed a particular point. Those events can diverge during abnormal operation. A sequence might complete while a pack remains trapped, so a reporting system needs evidence that the selected signal represents the production event it claims to count. Next, examine the available cumulative production count. Ask which event increments it, whether manual operations can increment it, and whether it includes trial cycles or other activity that doesn't belong to normal production output. Check the reject signal just as closely. It might represent a failed inspection, a command to activate the reject mechanism, or confirmation that an item entered the reject chute, and those meanings support different claims. A reject command doesn't prove successful. Removal. If the mechanism misses an item, the machine may record the command while the item continues downstream, which means the quality record needs another source of confirmation. Operating mode adds context to those signals. Automatic manual setup and maintenance modes can change how the machine behaves, so establish whether each production signal retains the same meaning across the modes your crew actually uses. Manual jogging deserves a specific test. An operator might advance the mechanism to clear material, while a cycle related bit changes, even though the movement doesn't complete the production task that the reporting system assumes occurred. Now ask what the run command proves. Usually, it establishes that the controls requested operation while permissive downstream conditions or another part of the sequence can still prevent the machine from producing anything. Confirmed motion answers another narrower question. A motor running contact can confirm motion at that motor, but you still need to establish whether material moves through the process and whether the intended production event occurs. Observe start up before relying on either signal, the machine may accept a run command, start its drives and complete preparation steps before releasing output, so record how those signals behave throughout that startup sequence. Then observe a downstream blockage during an approved test or a naturally occurring interruption. Check whether the machine retains its run request while waiting, and which signals reveal that it can't discharge. Material starvation needs the same practical check. A machine waiting for input may remain enabled without generating a fault. So a fault free condition alone won't establish that production continues or that output remains possible. Fault signals need their own questions. Find out whether an alarm indicates an active obstruction, a remembered event awaiting acknowledgement, or a warning that permits production to continue under the machine's approved operating rules. Don't assume every alarm stops production. Ask the controls engineer which alarms interrupt the sequence and compare that explanation with observed behavior. Because an alarm list can include conditions with very different effects. Write down what each approved observation establishes for every signal you intend to use. Record its meaning, its physical source, the modes in which it applies, and the conditions under which its interpretation becomes uncertain. Bring the operator into that review. They can explain that an apparent weight followed a material splice, or a routine check, where the available control signals only established that the machine paused. Keep observation separate from explanation. The machine can provide evidence that an event occurred while the operator adds circumstances. The controls don't measure without either source needing to claim knowledge it doesn't contain. That leaves us with defined inputs rather than convenient tag names. The next step is deciding how those inputs work together when several signals remain active at once, so the reporting system can describe the cell's condition consistently. We need rules for resolving signals that appear to disagree. A state model takes the relevant inputs and assigns one reported condition to the equipment boundary. Using decisions that production and controls engineers can test together. Each moment needs one primary state for the time account. Other observations can remain attached as detail, but the same period can't count as both running and stopped. When we later add its duration to the shift. Define the states through conditions you can verify. Running should describe the expected production sequence progressing, including normal cycle phases, rather than requiring constant motion or a finished pack to appear at every instant. Stopped needs an equally explicit definition. It describes an interruption to that sequence under your agreed rules, while blocked and starved describes specific flow conditions that help explain why production can't proceed. Blocked means the equipment can't pass its output onward. Starved means it lacks the required incoming product or material with the relevant input and output defined for the equipment boundary, rather than assumed from a signal label. These labels need a mapping into the measurement account. You might retain blocked and starved as distinct operational states, then map their interruptions into availability or performance according to the stop policy. Already agreed. The state model also needs an unknown condition. Use it when the available inputs can't support a defensible classification. Instead of forcing contradictory evidence into whichever state makes the report easiest to complete, conflicting inputs need documented precedents, not an improvised choice. Suppose the Packer reports an interrupted sequence while another signal still indicates normal operation. The rules should specify which evidence governs and which contradiction remains flagged. Precedence depends on the boundary and the meaning of the inputs. A confirmed interruption might override a general operating indication, but an alarm that permits continued production shouldn't automatically override evidence that the normal sequence continues. Write transition rules as conditions the team can challenge for every move between states. Specify what evidence permits the change, what evidence prevents it, and what happens when the required inputs disagree or disappear. Consider a blockage clearing. While the packer still can't resume, the state shouldn't return to running just because one obstruction disappears when another confirmed condition still prevents the production sequence from progressing through its required steps. Cell level rules require more than combining machine labels during a temporary feed interruption. The packer might continue using material already inside the cell, so a starved filler doesn't automatically mean the entire cell has stopped producing internal buffers. Change how station conditions affect the cell. Define how the cell state follows supported production behavior across those buffers while retaining station states, so an investigator can follow how an interruption spreads through the equipment. The reverse can happen during an internal clearing sequence. A conveyor might move while the cell can't complete its production task, so the cell model needs evidence of that task progressing rather than a vote among running motors. Some signals also chatter around a transition. A sensor can flick between values because of vibration or contact behavior, creating a series of apparent state changes that doesn't match what the equipment actually does. Filtering can help, but its rules need testing. You might require an input to remain stable before accepting a transition, with the confirmation period chosen against observed equipment behavior rather than a convenient software default. Keep genuine short interruptions through that filtering. Compare the derived states with approved observations of actual jams. Because a filter that removes every brief transition can erase the recurring problem the crew needs to investigate. Specify what confirmation does to the reported transition point. If a rule waits before accepting a change, decide whether the transition refers to the first qualifying input or the later confirmation and retain that choice. Keep raw inputs alongside the states derived from them. When an operator disputes a classification, you should be able to replay the relevant sequence under the recorded rules and identify exactly which condition selected that state. A rule revision needs the same evidence trail. Preserve the earlier interpretation beside the revised result, so correcting a state definition doesn't leave the team unable to explain why a previously reported loss changed. We've now defined how the cell earns each state. The next question concerns how long it occupies that state, which depends on whether the recorded event times represent the physical transitions closely enough to measure them. A timestamp needs a stated origin for each transition. Distinguish when the machine recorded the event, when the gateway received it, and when the cloud accepted it. Because those times can describe different moments. Consider a packer stop during a temporary connection delay. The controller might record the transition immediately while the gateway forwards it later and the cloud receives it after newer messages from another source have already arrived. Cloud arrival time measures arrival not necessarily the production interruption. Calculating stopped duration from arrival times can stretch or compress the interval whenever transmission delays differ between the stop message and the message recording productions return. Keep those timestamps separate whenever the equipment supports them. Machine event time supports the production timeline. Gateway receipt time helps assess collection delay, and cloud arrival time. Helps explain what the reporting service knew at a particular moment. Older equipment might not supply a trustworthy event timestamp. In that case, a gateway can timestamp its observation, but describe it as an observation time with limits set by the collection method rather than an exact machine transition clock. Agreement becomes part of the measurement if the Packer clock runs ahead of the gateway clock. Records can appear to arrive before they occurred, leaving an investigation with a sequence that physically couldn't happen. Use an approved clock synchronization method and check its behavior. Agree with the plant's controls and network teams which time source each device follows, how often it checks that source, and what happens when synchronization fails. Synchronization status alone doesn't establish timestamp accuracy. Monitor, clock offset and drift where possible, and record timestamp trust at the source so downstream processing can distinguish checked event times from times whose accuracy hasn't been established. A controller restart deserves particular attention during commissioning. Some devices can restart with an incorrect clock until synchronization returns, so test that behavior and flag the affected timestamps instead of accepting their apparent precision without question. Store production timestamps against one consistent time reference. Coordinated Universal Time or UTC provides that reference, while the plant's local calendar determines which shift and local production date each event belongs to. For reporting purposes, local time still matters to the people working the shift. Keep the plant's time zone and its calendar rules with that interpretation, rather than treating a fixed offset from UTC as correct throughout the whole year. Daylight saving changes expose the difference when clocks move backward. The same local clock reading can occur twice, so a local timestamp without its offset can't uniquely identify an event during that repeated period. Use elapsed timestamps to measure duration, not local clock subtraction. When clocks move forward, a shift spanning the change contains fewer elapsed hours than its usual clock label suggest, and the production calendar needs to account for that. Midnight creates a reporting boundary, not a machine transition. A stop can continue across midnight without restarting, so preserve the elapsed interruption while allocating its time to the appropriate local shifts under the plant's calendar. Delayed messages need a defined correction window. Within that window processing can reorder records by their trusted event times and revise the affected interval when an earlier transition arrives after a later one, make that revision policy clear to production. A near live result can remain provisional while delayed records arrive, but events arriving beyond the window need an explicit correction path. Rather than silently changing an already settled shift. A missing message raises a different question from a late message. If the last confirmed condition indicates running and telemetry then disappears. The reporting system lacks evidence that running continued throughout the silence. Even if the machine eventually reconnects. Set a freshness limit suited to the signal's expected behavior. Once that limit expires, mark the unsupported period as uncertain rather than extending the last running condition indefinitely, and avoid assuming that silence proves a production stop. That requires a way to distinguish quiet equipment from broken communication. A state that changes infrequently can remain legitimate for hours, so use a heartbeat or another tested freshness indication before deciding that it's supporting. Telemetry has become stale. Timing uncertainty should remain visible in the result. Even with a defensible event timeline, though, we still need to establish how much output belongs to each period, especially when the machine's production counter spans a connection interruption. A cumulative counter gives us a total, not an output increment, to establish how many packs the cell produced between readings, subtract the earlier confirmed reading from the later reading provided both belong to the same uninterrupted counter sequence. Suppose the counter advances from twelve hundred to twelve hundred and eighteen. That supports an increment of eighteen packs between those observations. Assuming the counter hasn't reset wrapped around or changed its counting behavior during that interval, the first reading establishes a baseline. Connecting a gateway to a machine with years of accumulated output doesn't mean that entire total belongs to the shift. When someone connects the reporting system, a falling reading needs investigation before subtraction. If the counter drops from a large total to a small value, treating the difference as negative production creates a record that has no useful physical meaning. Find out what can clear the counter and operate a reset. A controller restart or a recipe action might begin a new counting sequence, and each needs a detectable boundary rather than a guess based only on the numbers. A restart doesn't always clear the value test, whether the controller retains the counter through a power interruption, and whether a restart indicator or sequence identifier can distinguish retained readings from a newly initialized total. A reset can leave output unrecoverable from the available readings if packs leave after the last captured value, but before an unrecorded reset. The next reading alone can't tell you how many disappeared from the counters. History. Record that gap. Instead of inventing a correction where the equipment provides a reset event and the final reset, value processing can close one sequence and begin another with evidence supporting both sides. Rollover is a separate, predictable behavior. A counter with a fixed numerical range can return to its starting value after reaching its limit, so calculate across that boundary only when the range and rollover behavior are confirmed. That calculation still has assumptions if the connection remains unavailable long enough for several rollovers. The two endpoint readings might support several possible output totals rather than one defensible answer for the missing interval. Unexpected upward jumps deserve checks as well. Compare the increment with the supported production capability over the elapsed period, allowing for how the machine updates its counter before deciding that the reading represents impossible output. Keep a suspicious reading available for review. Flag it rather than quietly trimming the increment to an expected quantity. Because a forced correction can conceal a controller issue, a configuration change, or a collection error. Reconnection introduces another way to inflate output. A buffered reading can arrive again after a retry, and the reporting system must recognize that repeated record rather than adding the same production increment for a second time. Give each captured reading a stable identity. Preserve its source and sequence through retries, and keep track of which reading pairs have already contributed increments, so replay doesn't create another copy of their output. 00:53:15 Speaker: Identical values don't always mean duplicate records. Two genuine observations can show the same cumulative total because no additional packs crossed the count point, while two deliveries of one observation represent a transport duplicate out of order readings also need controlled handling. Insert a delayed reading into its supported sequence and recompute the affected differences. Rather than treating arrival order as production order and creating false jumps or resets. Cumulative counts can help recover quantity after a connection outage. If the counter continues correctly and nothing resets. Subtracting the last pre outage. Reading from the first post outage reading establishes the output accumulated across that gap. A pulse stream has a different recovery limit if individual completion pulses aren't captured and retained locally. Pulses occurring while collection is unavailable can disappear, leaving no later total from which to recover them. Recovered quantity doesn't automatically supply recovered timing. A counter increase across an outage tells you how much output accumulated, but it doesn't establish exactly when each pack left or how output divides across a shift boundary. Retain the evidence behind every derived increment store the bounding readings, their sequence, and any reset or rollover interpretation with uncertain intervals identified. So a recovered total doesn't masquerade as precisely timed production that establishes what quantity the count evidence supports. Assigning those packs to the correct product and work order requires another connection, because a reliable counter doesn't itself explain which production task generated its increments. The connection starts with evidence of what the crew actually ran. A manufacturing execution system, or Mess can supply that execution context where it's installed and used to record the work taking place at the equipment. Check what its order status actually means. An order marked active might be dispatched to the cell, released for execution, or confirmed as physically running, depending on how your implementation handles those steps. Those statuses support different assignments. A reporting process that treats dispatch as the start of production can attach the previous product's final packs to the next order before the crew changes anything. Enterprise resource planning or ERP supplies another part of the account. It commonly holds production orders and business records, but the detail and timing of its shop floor information depend on the implementation and its connected systems. Decide which source governs each piece of context. The ERP might govern the order identifier and required product, while the mess records actual execution with a local operator declaration supplying details that neither system captures. That division needs explicit ownership. If both systems contain an actual start time, establish which event each time describes before selecting the one that assigns machine output to an order for our cell, consider the moment between two work orders. The supervisor releases the next order while the packer still contains material from the previous run, so administrative readiness precedes the physical change in output. An order release alone can't settle that transition. Use a supported execution event, an operator confirmed change point or a product identifier at the relevant process stage to establish which output belongs to each task, connect those events through a production segment. That segment links the equipment and work order to the product and tooling actually in use with an effective start and end supported by the execution record. The tooling reference needs to describe the installed configuration. A planned format kit on an order doesn't prove the crew installed it, so distinguish the requested tooling from any verified setup. Declaration used to interpret production equipment. Identity needs the same discipline. The controls project might call alpaca Pqr zero two, while maintenance and production use different names, and those names can accidentally point to separate records in reporting. Give the physical asset one stable identity. Maintain explicit mappings from each system's equipment reference to that identity with effective dates when names or assignments change, rather than matching records through similar looking text. Delayed confirmations need two separate times. Preserve when someone entered the confirmation and when they report the production activity occurred. So a late booking doesn't automatically move the output into the booking period. Resolve contradictions through a documented rule if an operator records one product while the execution system records another, hold the affected assignment for review instead of choosing whichever record arrived. Most recently, some quantities will remain unassigned temporarily. That's preferable to attaching them to a plausible order without evidence, because an unexplained assignment can silently apply the wrong cycle standard and distort the resulting loss account quality records then join through that production context. An inspection system might identify a serial number, a batch, or a defined portion of an order, and the connection must preserve that. References. Actual scope. An order number alone can be too broad if the order spans several runs or equipment configurations. A rejection against that order doesn't identify which segment produced the affected quantity without further evidence, require a narrower reference where the distinction affects the result. That could be a production batch tied to its segment, a serial range, or a documented quantity window whose start and end the plant can establish separate product identity from inspection identity, a supplier's material batch, the cell's production batch, and the inspection sample identifier can all differ, so retain their relationships rather than assuming that one batch field connects everything, test the connection with a real production trace. Ask the team to follow one bounded quantity from its equipment events through its executed order and setup, then into the inspection record. That settles its disposition. Any uncertain link should remain visible. Once those relationships hold. The next concern is keeping their supporting events available when the connection out of the plant fails without losing what happened at the machine. Put the first durable capture point inside the plant for a packaging cell, that means following the approved signals from the controller into an industrial gateway that can retain collected records before forwarding them over the onward connection. The gateway needs a defined collection job. It reads or receives the permitted signals, attaches the required source information, and writes the collected records into local storage without waiting for a remote service to acknowledge every observation that storage must survive more than a network interruption. Check whether the gateway preserves queued records through a service restart or power loss, because a buffer held only in memory won't protect the shift under those conditions. Separate collection from forwarding so each can progress independently when the external connection fails. Collection should continue within the gateways tested limits while the forwarding process waits and retrieves without blocking access to incoming machine information ownership crosses the boundary here. Operational technology or OT owns concerns around the equipment and its operation, while information technology or it brings responsibilities around managed infrastructure, network access, identity and the destination. Receiving the data. Agree on responsibilities before connecting anything someone needs to own gateway updates, storage, health network permissions and recovery with a clear escalation path. When a failure touches both plant equipment and enterprise infrastructure during production, buffer capacity needs an outage assumption. Estimate the volume generated during the longest interruption you intend to cover, then allow for storage overhead and bursts of activity, rather than sizing against a quiet machine's average message rate. Busy conditions can produce more records than steady production. A fault sequence might generate many transitions while output remains low, so test the buffer against observed event bursts. Instead of treating PAC rate as the only driver of data volume, recovery needs spare forwarding capacity, too. If the gateway can send records only as quickly as new records arrive, reconnecting won't clear the backlog, and the local store will remain exposed to another outage. Test catch up while the cell continues operating, the gateway needs enough processing and network capacity to forward retained records alongside current collection, without exceeding the limits agreed for either the controller or the plant connection. Define what happens when storage approaches its limit. Raise an actionable warning early, and document any retention or overflow behavior so the team knows whether collection will pause. Older records will disappear or another approved response will apply. Reconnects must preserve the source's sequence. Records waiting locally need to retain their original identities and ordering information through forwarding attempts, even when a partial transfer succeeds and the gateway can't immediately confirm which acknowledgements returned. Acknowledgement needs a precise meaning. Decide which receiving point must confirm durable acceptance before the gateway removes its local copy and test interrupted transfers, so an uncertain delivery doesn't quietly become a deleted record. The controller also needs protection from the collector. Have the controls engineer approved, read frequency, requested signals and connection count, then check controller load during normal production and fault conditions before expanding the collection scope. Read only access still consumes resources. A poorly configured collector can overload a communication interface without changing a single control value, so connection limits and retry delays belong in the commissioning checks, not just the network documentation. Respect the plant's network zones. Use the approved communication path between the machine network and the receiving network, with only the required access permitted. Rather than creating a general route into equipment for reporting convenience certificates need an owner and a renewal process test what happens when a certificate expires or changes, including whether the gateway keeps collecting locally while its onward connection remains unavailable pending an authorized repair. Keep reporting work outside the machine's control responsibilities. Installing or maintaining the gateway must follow the plant's change and safety procedures, and the collection failure shouldn't prevent the approved control system from carrying out its production functions. Commission the failure behavior, not just the successful connection with plant approval. interrupt the onward connection and restart the gateway, then verify retained records, backlog recovery, resource use and the operator's experience before accepting the installation. That gives the onward connection a bounded role. Once local capture can withstand the agreed interruptions, we can decide what belongs in the cloud without making remote availability a condition for preserving the cells production. Evidence for the cloud design. I'd separate connection management from analytical processing. Those jobs can share infrastructure, but choosing a service for receiving equipment messages doesn't settle how your organization validates production evidence or calculates a trusted o e result. Azure IoT hub is one option for the device facing connection. Its device identities and device management capabilities can fit an architecture where your team needs to manage gateways as identifiable devices, rather than merely receive messages from an application. That distinction affects what you operate. If each plant gateway needs its own authenticated connection and managed lifecycle. Assess IoT hub against those needs, including how the chosen gateway software supports that connection as your event hubs addresses event stream ingestion, it can receive streams from gateways or integration applications, but it doesn't provide the same device management model, so choose it for the ingestion role rather than assuming the services are interchangeable. An existing plant integration service can change that choice if it already manages equipment connections and publishes a consolidated stream. Event hubs might be the relevant cloud entry point without adding another device management layer solely for OE. You don't need both services by default. Start with who connects, what identity that connection requires and who manages it. Then select the receiving service that meets those requirements without adding responsibilities nobody intends to own after ingestion, consider what needs immediate validation. Azure functions can handle bounded tasks, such as checking whether a message contains required fields, validating a declared unit, or detecting an invalid message to a separate review path. Keep those tasks small enough to test independently. A function that validates a message shouldn't quietly become the only place where production calendars. quality decisions and every equipment specific exception combine into an undocumented calculation. Retrieves need deliberate handling in that processing step. If a function writes an accepted message and then fails before completing its invocation, a retry mustn't turn that successful write into another copy of production designed for repeat delivery. Rather than assuming it won't happen. Use the event's identity to control repeated writes and distinguish a temporary processing failure from an invalid message that needs investigation rather than endless automatic retries. Microsoft Fabric belongs in the analytical path. When it fits your platform, it can support retained analytical data transformations and reporting, allowing the information received from production to become a governed source for analysis rather than a transient message stream. The transformation work still needs a manufacturing specification. Fabric can execute the rules your team implements, but selecting a workspace or ingestion method doesn't establish whether a Packer interruption counts as downtime for the cell. That decision belongs to the plant's measurement owners. Production and engineering define the intended interpretation. While execution and inspection systems supply relevant context, and the integration team implements those agreements in the analytical processing. I'd make that responsibility explicit during design reviews. Ask who approves each manufacturing rule and who verifies its implementation. Because a technically successful pipeline can consistently calculate the wrong result when nobody owns the interpretation, service boundaries also affect how quickly results become usable. Receiving a message promptly doesn't guarantee that transformation and reporting have completed, so agree which operational questions need rapid updates and which can wait for a settled analytical result. Test the complete reporting delay against that requirement include ingestion, processing and report refresh behavior in the assessment, rather than describing the result as real time because one service accepts incoming messages quickly under normal conditions. None of this places machine control in the analytical chain. Keep approved control functions independent of the cloud reporting path, so a delayed function invocation or unavailable analytical service can't become an instruction for the packer to stop a cloud outage should affect reporting freshness, not production permission. The plant continues under its approved local controls while the analytical path catches up afterward. According to the recovery behavior, you've tested and accepted that separation gives each Microsoft service a specific job. The remaining question is what the records carry through those jobs. Because processing becomes difficult to defend when a received event loses the information needed to explain its origin. A replayable record needs more than the value that triggered processing. It needs enough information to establish what the event means, where it belongs, and which interpretation applied when the plant first used it in a calculation. Treat the event record as evidence you can examine independently. Someone investigating a disputed shift should be able to retrieve that record without relying on today's gateway configuration, or asking the original developer to remember how the integration worked. Begin with a stable equipment reference. Inside the record itself, a message is transport address can change when infrastructure moves, so the event needs an asset identity that remains meaningful after the connection carrying it has been replaced. the event. Identity needs a defined scope as well. If a source restarts its sequence numbers, combine that sequence with a source session reference or another controlled identifier so a new event can't collide with an older one. Preserve the source timestamp together with its stated meaning. A future investigation needs to know whether that timestamp came from the controller or the collector, without reconstructing the answer from an integration service that might no longer exist. Make units part of the records, meaning a numerical value accompanied by an explicit unit and measurement definition, gives later processing a defensible input, rather than requiring someone to infer what the source intended from the value alone. The schema version tells processing how to read the record. Think of it as the version of the message contract specifying which fields exist and what those fields mean when an event enters the retained history. A software update can change that contract if the gateway changes a field's meaning or introduces a different representation, record a new schema version instead of leaving old and new events looking interchangeable to downstream processing. Keep received events separate from interpreted production records. The original event remains unchanged, while derived state intervals and calculated results live in records that refer back to their supporting events and the processing version used. That separation gives corrections a clear place to happen if investigation changes in intervals. Classification publisher corrected interpretation without rewriting the source event into something the machine never reported when the observation originally occurred. The calculation also needs a record of its dependencies for each published result. Retain references to the production calendar cycle standards, stop recent definitions and state rules that governed its interpretation, including their applicable versions. An effective date alone can leave questions unanswered. You also need to know when the organization recorded a revision, because a correction entered today might apply to a production period that ended before anyone discovered the mistake. Consider a hypothetical review of our cells changeover. Record production discovers that an interval received the wrong reason under the existing definitions, so an authorized correction changes the classification while leaving the underlying event evidence untouched. record. Who approved that correction and the evidence supporting it. State which equipment and period it affects why the earlier interpretation needs changing, and which previously published results require recalculation because they depend on that interpretation. A rule revision is a different kind of change. Engineering might approve a revised state rule for future production or authorise a historical restatement, but those decisions shouldn't travel through the same process as correcting one misclassified interval. Give replay two explicit purposes. One reproduces a reported result using the original inputs and original rules, while the other recalculates an identified period using approved revisions that can legitimately produce a different answer. Label the second result as a restatement. Keep the original result accessible beside its replacement, with the reason for the difference, rather than allowing yesterday's published percentage to disappear when someone reruns the processing, a replay should also declare its input cut off. Otherwise, a reproduction can unexpectedly include records received after the original publication, and the team can't tell whether the changed answer came from revised rules or newly available evidence test reproduction. Before accepting the calculation into regular use, select a settled production period, retrieve its retained inputs and recorded dependencies, and confirm that replay reproduces the published result without relying on current master data that makes the history explainable. Beyond the latest processing run, the reporting model can now use derived production records with known origins and versions, instead of treating whichever values happen to exist today as the only account of the shift power, BI needs a model that preserves what each record represents. I'd start by asking the reporting developer to describe one row in each proposed table before creating relationships, or writing any calculation for the production report. That description is the table's grain. A state interval represents one condition over a bounded period, while a count increment represents output between supported observations and an inspection result represents a decision about identified production. Those records don't belong in one flat table. By default, their grains differ, so combining them requires more than finding an equipment identifier and a timestamp that appears somewhere in each of the incoming records. 01:11:26 Speaker: For our cell keep duration facts in their own table. Each row can describe a bounded interval with its start, end, elapsed duration, and references to the equipment and reporting contexts that genuinely apply throughout that interval. Production quantities need a separate fact table. Its rows represent supported count increments assigned to production segments, retaining the observation bounds when the evidence doesn't establish an exact completion time for each individual pack, inspection results need their own structure to. One result might cover a single identified pack, while another covers a bounded quantity. So define that grain explicitly rather than assuming every inspection row represents one produced unit. Shared dimensions connect these facts without pretending their rows are equivalent. A dimension holds the agreed descriptive records, such as equipment or product, that let your reporting selections refer consistently to the relevant facts across the model. Use the same equipment dimension for duration, production, and quality facts that gives a selection of our packaging cell one consistent meaning instead of relying on separate equipment, name columns whose contents can drift between tables over time, product and other dimensions provide similar shared references. Date and shift dimensions establish the reporting calendar, including a distinct identity for each actual shift occurrence rather than a repeated label such as night shift alone. Relationships still need to respect what the facts actually know. An interval without a supported order assignment shouldn't acquire one merely because an order exists for the same equipment on the same production date in another table. Reporting boundaries require preparation before power. Buy ads. Durations. If an interval crosses a shift boundary, create reporting portions on either side, preserving a reference to the original interval so their combined duration remains traceable. Apply that approach wherever duration must be allocated accurately. A change in product or order context can require another split, but only where the underlying records support that transition and establish which context applies on either side. Counts require more restraint than durations. Splitting a measured interval at a known boundary doesn't justify distributing its associated output proportionally, because production might occur unevenly within the period covered by the available count observations. Suppose a count increment spans two reporting shifts. Without intermediate observations, you can preserve the confirmed quantity and its timing bounds, but assigning half to each shift would introduce an assumption rather than recover a measured production history. Keep that unresolved allocation identifiable in the analytical model. Otherwise, a shift report can appear precise. While its production quantity depends on a distribution rule that nobody on the shop floor has accepted or verified. Another risk appears when someone joins the fact tables directly. Imagine one production segment with a duration record and several inspection records, all carrying the same segment identifier and therefore appearing straightforward to combine in a query. The join can repeat the duration for every matching inspection record, summing the resulting duration column then multiplies elapsed production time, even though each individual row looks plausible when someone checks its equipment order and inspection details. That's join Fanout and relationships alone won't automatically prevent every version of it. Keep different grain facts separate, connect them through controlled shared dimensions, and use an explicit mapping where an inspection population genuinely spans several production segments. Check row counts and totals after every model building join. Adding inspection contexts should never increase measured duration or newly produced quantity, so compare those totals before and after the transformation. Rather than testing only whether records matched with those relationships tested, the measures have defensible inputs. The next task is making sure each reporting selection recalculates the intended ratio from those facts, rather than combining percentages that no longer describe the selected production opportunity, the measure needs to answer the question your current selection asks in power BI data analysis expressions, or Dax, is the language used to define measures that calculate results from the records included in that selection. A measure runs within a filter context. That means your equipment shift product and order selections determine which records contribute to its result, together with the relationships and any filtering instructions written into the measure itself. Treat that context as part of the calculations, meaning selecting a shift should restrict the production opportunity and output consistently while selecting a product, raises a separate question about which portions of that opportunity genuinely belong to it. A product selection doesn't automatically establish the right time denominator. If the model filters output to one product but leaves the entire shift's plan time unchanged, the resulting percentage answers a different question from effectiveness during that product's assigned production. Decide which question the measure should support, then test that its numerator and denominator follow that decision, including whether shared time remains unallocated or belongs to a documented production segment under the measurement rules. I'd build the measures from additive quantities first sum the eligible planned duration, run duration, ideal time for total output, and ideal time for accepted output separately so each total can be checked before division occurs. Those totals become the inputs to the ratios. The report should divide the selected totals at calculation time, rather than retrieve percentages calculated for smaller periods, and assume those percentages remain suitable for every wider selection. Stored percentages can describe their original reporting periods, but a simple average gives each percentage equal influence, even when one period contains much more production opportunity than another. So it changes the question without warning. Consider two hypothetical production periods with unequal planned durations. If the shorter period performs well and the longer period performs poorly, an equal average gives the short period more influence than its share of planned production time. Supports. Recalculating from the underlying quantities. Preserves that difference in exposure. It also means a selection covering several shifts uses the production opportunity those shifts actually contain, rather than treating every shift label as an equal sized contribution. Division needs explicit behavior when its denominator disappears. Dax includes a function called divide that handles zero denominators, but choosing its alternate result remains a measurement decision rather than something the function can settle for you. Zero planned production time means there's no production opportunity to evaluate. I'd normally return a blank effectiveness result with a separate status explaining that condition. Instead of displaying zero percent and implying the equipment failed to deliver assigned production. Zero output requires a different interpretation when plant production time is positive and the evidence confirms no output, overall effectiveness can legitimately equal zero, even though a quality ratio with no produced population remains undefined. Don't turn every undefined factor into zero. A fully stopped period, for example, can have a defensible overall result. While performance has no runtime denominator and quality has no output denominator against which either factor can be evaluated missing. Telemetry is a question about evidence. A blank count caused by lost collection doesn't establish zero output, so the measure needs a completeness status that prevents missing observations from quietly becoming a claim about production. Keep incomplete inspection distinct from missing machine information when output is known, but some acceptance decisions remain outstanding. The result needs the agreed provisional treatment and an unresolved quantity, rather than a settled label borrowed from otherwise complete telemetry. Published status alongside the number so its interpretation survives selection changes. A broader selection can contain both settled and unresolved periods, and the measure should disclose that mixture rather than letting a clean looking total conceal an unfinished production account. I test selections as carefully as arithmetic, choose an equipment item, change the shift, then restrict the order or product and confirm which duration and output records. Enter each measure before accepting the resulting percentage. That check exposes filters that remove only half the evidence. Once the measures behave consistently for the cell across those selections, we can address a different question what a combined result means when the selection contains more than one equipment boundary? Selecting several assets introduces a choice about what the total represents. You can calculate a weighted equipment summary, but that summary measures the combined production opportunity assigned to those assets, not the effectiveness of an imagined machine containing all of them. Give that combined result a precise label calling it equipment weighted by planned production time, tells the listener what contributes to the calculation, whereas factory E can suggest a production boundary that nobody has actually defined for that equipment. Summary, add the equivalent good production time across the selected assets, then divide by their summed planned production time, retaining each asset's supported product standards and its own production commitment. Within the reporting period you've selected. The denominator is now accumulated equipment time two assets assigned production during the same elapsed hour. Contribute two equipment hours because you're measuring separate production opportunities, rather than claiming that two hours passed on the clock. That distinction limits what the summary can explain. It describes the share of those accumulated opportunities represented by first pass good output, but it doesn't establish how much finished production the factory delivered through a connected process. Different output units don't prevent this particular calculation. One asset can produce individual components while another produces finished cartons, provided each quantity converts into ideal production time using the appropriate standard for that asset and product. Keep those conversions attached to their source records. Adding component counts directly to carton counts would produce a quantity with no clear physical meaning, while adding their equivalent production minutes. Supports the specifically defined equipment time. Summary the combined percentage still needs its equipment context. A change in which assets receive production can move the summary even when no individual asset improves. Because the allocation of planned equipment time changes each asset's influence. Read the summary alongside its contributing equipment results. Otherwise, a strong result from a heavily scheduled asset can conceal poor performance elsewhere without telling you whether that poor result affects the production path your customers depend on. A connected line needs a different calculation. Return to our packaging cell and treat the filler conveyor and packer as one production system, with one agreed output boundary and one planned production window for that system. Calculate line E from the output crossing that boundary. Convert its first pass good output into ideal line production time. Then compare that time with the line's planned production time rather than adding the opportunities of its internal stations. The ideal line rate needs its own engineering support. It must describe what the connected equipment can repeatedly deliver for the product and configuration, including their interaction, rather than borrowing whichever station's rated speed happens to be easiest to find. A station rating can inform that assessment without settling it. Transfer behavior synchronization and the equipment configuration can restrict the supported line rate, even when each station can individually demonstrate a faster pace under different feeding conditions. Keep station E outside the line calculation. Multiplying station percentages would treat their losses as successive independent reductions, even though the same physical interruption can appear in several station records as it spreads through the connected equipment averaging station results doesn't establish line effectiveness either. It gives station measurements a combined value without establishing how their conditions affected output at the agreed line boundary, particularly when internal buffers temporarily separate one station's behavior from another's. Suppose the packer pauses while the conveyor still holds usable product. The filler may continue briefly, so its local production record can look satisfactory, even though the relationship between that activity and completed line output depends on the buffers changing condition. Station detail remains useful for explaining that sequence. Retain blocked and starved states so the team can distinguish equipment waiting for an incoming supply from equipment, unable to release output rather than interpreting every interruption as a local failure. Those states describe flow conditions not proven causes. A starved packer identifies a missing input at its boundary, while the upstream records help establish whether that condition followed another machine's interruption or something outside the measured line. The combined result now has a defensible meaning. An equipment summary describes accumulated equipment opportunity, while line E describes one connected production boundary. The next check is whether each result agrees with the production behavior its definition claims to measure. I'd ask the team to prove the calculation wrong before publishing it. Give it production cases with known outcomes, then check whether the reported result matches the evidence without manual adjustments introduced simply to make the test pass. Begin with a time reconciliation for one completed shift. The planned production window must equal runtime plus availability stop time with every included interval counted once and any unsupported duration explicitly identified rather than silently assigned. An unexplained difference is a failed test. If the components don't reconcile, inspect interval boundaries and overlapping records before reviewing percentages because a plausible score can conceal missing minutes or duplicated duration beneath the calculation. Apply a similar check to the production population. Every counted unit needs to reconcile to first pass accepted, first pass rejected or unresolved output under the stated quality rules, without allowing subsequent disposition records to create extra production. Check that reconciliation at more than one reporting level. A shift total might balance, while individual production segments don't, which can expose quantities attached to the wrong run even though their errors cancel across the wider period. Then feed the calculation a deliberately perfect production case. Use a complete record with no stops, output matching the supported ideal pace and every unit accepted, so all factors should reach one hundred percent without exceptions. A fully stopped case tests a different path. Give the model a positive production commitment. Confirmed stop duration covering that commitment and no output. The overall result should reach zero without inventing values for undefined factors. Slow running should produce a selective change with confirmed running throughout and all output accepted. Reduce the production quantity below ideal capability and verify that performance carries the loss while availability and quality remain unchanged and all reject case checks whether acceptance actually governs the final result. Feed the model confirmed production at the ideal pace. Reject the entire population and verify that the good output contribution disappears while the recorded production activity remains intact. Missing telemetry needs a test of its own. Remove a required portion of the evidence from an otherwise known case, then verify that the report exposes uncertainty instead of returning the same confident result as the complete record. After those controlled cases, test events around reporting boundaries, place a known stop across midnight and confirm that it's reporting portions reconciled to the original elapsed duration. With neither a missing slice nor an extra interval introduced. Counter tests should challenge recovery, not just ordinary increments, include a documented reset between valid readings and verify that the derived output follows the supported counter sequences with any unrecoverable quantity remaining uncertain instead of becoming negative production. Replay a captured group of messages through the same processing path. The resulting durations and quantities should remain unchanged, and the test should fail. If receiving those records again adds another copy of their production contribution. Product changes. Need a case with an awkward transition? Place confirmed output on both sides of the change and verify its assignment against the supported execution boundary. Checking that each quantity receives the applicable cycle standard. Late inspection should change only what its evidence supports. Enter a delayed decision against an identified production population, then verify that the affected quality result changes without moving production quantities or altering the measured duration of that earlier run. Keep expected outcomes with the test records that gives the team repeatable acceptance checks after a transformation change, rather than relying on someone to remember which report selections looked reasonable during the previous commissioning session. A disputed shift adds the human evidence those controlled cases can't supply. Ask the operator to identify one specific interruption or production quantity they challenge. Then start from the selected report, result and trace only that disputed contribution. Follow the measure into its contributing intervals or count increments from there. Retrieve the source events and relevant operator context checking where the reported interpretation first departs from the evidence rather than debating the overall percentage. Sometimes that trace exposes software. Sometimes it exposes an unsettled definition record, which kind of disagreement remains because correcting an implementation and deciding how the plant wants to classify an event require different decisions from different people. Testing can establish whether the calculation follows its stated rules when the unresolved dispute concerns the rules themselves. Someone with responsibility for that definition needs to decide. Which brings us to ownership of the metric. Who can approve a change to what the number means? That person needs authority over the production definition, not just permission to edit a power BI report or access the database where its settings live. The reporting developer shouldn't inherit that authority. By default, their job is to implement agreed definitions while the plant appoints people who can approve those definitions and answer for their operational consequences. When someone challenges a result, assign ownership by subject with a named person for each responsibility. Production planning might own calendars, process engineering might own cycle standards, and quality might own acceptance rules. Depending on how your plant actually assigns those decisions. Stop reasons and measurement boundaries need owners to include deputies and an escalation route, because a disputed shift shouldn't remain unresolved simply because the only person authorized to decide its treatment happens to be away. Put those responsibilities into a written measurement contract. I mean, a practical agreement that production, engineering, quality and reporting can use when an unfamiliar situation appears without needing to negotiate the meaning of O e during every review. The contract needs precise choices, not broad intentions. Specify the exclusions short stop threshold correction window and calculation version. Then identify who can propose a change and who must approve it before reporting adopts the revision. Separate approval of a definition from deployment of its implementation. An engineer can approve a revised rule, but someone still needs to verify that the deployed calculation follows that rule before the plant starts using its results. Give each approved change an effective period and a publication decision. The owner should state whether it applies only to future production, or also requires identified historical results to be restated with affected users. Told. What changed result status needs an owner as well. Someone must decide when a production period moves from provisional to settled using agreed closure conditions, rather than assuming that the next morning's report automatically contains everything required. Closure should require evidence, not just the passage of time. The responsible people need to confirm that expected event processing and required inspection decisions have completed, or explicitly accept and disclose any remaining limits under the plant's reporting policy. Settle doesn't mean immune to later correction, it means the agreed checks have completed and the result has passed its normal closure point. So reopening it requires an authorized exception rather than another routine refresh. 01:29:29 Speaker: Make that status survive beyond the report itself. If someone exports a percentage into a shift meeting pack, its provisional status and calculation reference should travel with it. Otherwise, an unfinished result can quickly become an apparently official record. Ownership also includes checking what the score encourages people to do if a supervisor's reward depends heavily on availability. A request to reclassify interruptions deserves scrutiny, even when the proposed wording sounds reasonable to everyone in the meeting. The same pressure can reach cycle standards. A slower standard can improve reported performance without changing production, so its owner needs engineering evidence for the revision and independence from the pressure to deliver a better monthly percentage. Don't treat every disputed change as attempted manipulation. People can reasonably seek a fairer description of their work, but the approval process must distinguish a better measurement from a more comfortable result before accepting either request. Keep operational targets separate from measurement. Maintenance a missed target can justify investigation, but it shouldn't authorize the target owner to change definitions until the score improves, particularly when the revised result affects their own assessment. Give disputes a route that doesn't involve editing the report. Record the challenge. Result the specific definition or evidence in question, the person responsible for deciding, and the decision deadline. So the issue has a visible path to resolution. The outcome needs a logged explanation, including rejected requests. Keeping the reason a proposed change didn't proceed helps the next shift understand the decision, rather than reopening the same argument after everyone involved has forgotten its details. A silent report edit bypasses that whole agreement. Even a well-intended correction can damage trust when the number changes without notice, because production can't distinguish repaired evidence from altered expectations or an unauthorized adjustment to the rules, that gives the crew a stable basis for choosing work with an agreed result and accountable owners behind its definitions, the discussion can move from who controls the percentage to who can address the production losses it describes. Put a duration beside each loss before assigning improvement. Work availability, performance and quality percentages use different denominators, so comparing their percentage point gaps directly won't tell you which loss consumed the most production opportunity during the shift. Convert those losses onto the same time basis, subtract runtime from planned production time for availability loss, then subtract ideal time for total output from runtime for performance loss. Preserving the accounting rules already agreed. Quality completes the loss account in equivalent minutes. Subtract ideal time for first pass. Good output from ideal time for total output using each product's applicable cycle standard where the production window contains different products. Hour hand check example now gives us a loss budget. It's sixty stopped minutes, seventy performance loss minutes and fourteen quality loss minutes account for the entire gap between the production commitment and the ideal time represented by accepted output. Those minutes describe different opportunities for investigation. The performance loss total, for example, doesn't mean someone observed seventy minutes of slow motion. It combines the output consequences of short interruptions and reduced running pace under our chosen policy. Don't assign that whole total to run faster. Break it into supported patterns using captured interruptions and production rate evidence to identify what the team can actually investigate, rather than naming an action from the factor alone. For the recurring conveyor jams, examine their distribution, check whether they cluster around a particular format, material, batch or point after changeover, and whether the event records support the crew's description of repeated manual clearance during those periods. Frequency helps define the work, but it doesn't prove the cause. A recurring transfer interruption might warrant a mechanical inspection, while its association with one format gives that inspection a bounded starting point rather than permission to change every conveyor setting. Rank candidates using evidence and realistic recovery, not duration alone. A large loss with an uncertain cause may need observation first, while a smaller recurring loss with a confirmed mechanism and a practical remedy can support an earlier controlled intervention. Ask how much accepted output the proposed change could recover. Removing an interruption doesn't guarantee that every recovered second becomes additional good production, because restart behavior and other operating conditions can consume part of the apparent opportunity. Avoid promising the full, measured loss as a benefit. Record the recoverable portion as an estimate with assumptions, then check whether the trial actually produces more accepted output under conditions that make the comparison fair enough to defend. Starvation needs particular care when choosing an owner. A packer lacking incoming containers gives you an observed condition, but the action could concern material delivery and upstream interruption, or another event that prevented the expected supply from arriving. Follow the preceding events before assigning responsibility. If records show the filler stopped, first, investigate that interruption. If the filler lacked material, follow the supply evidence instead of sending maintenance to repair a packer that merely waited. Give one improvement hypothesis to one accountable owner for our hypothetical cell. That could be a process engineer testing whether a specific transfer guide adjustment reduces the recurring jams on one pack format within approved operating limits. Write down the expected observation before making the adjustment. Fewer transfer interruptions per comparable production period would support the hypothesis, while unchanged interruption frequency would challenge it even if the overall shift score happened to rise for unrelated reasons. keep the trial bounded enough to interpret. Compare production with the same format and relevant material conditions. Account for differences in exposure, and record other changes that could explain the result instead of crediting everything to the adjustment. Check the outcome beyond the interrupted seconds. The adjustment needs to reduce the intended loss without increasing rejected packs or introducing another operational problem, and the owner needs enough evidence to decide whether to retain it. A failed hypothesis still needs a recorded outcome. Close the trial with what the evidence supports and what remains unresolved, rather than leaving an unsuccessful adjustment installed because nobody wants to admit the first explanation didn't hold. Recovered sell time is only the next testable result. Before treating that recovery as a wider production gain, we need to establish whether the rest of the process can turn the sells additional accepted output into useful delivery. Follow the extra output beyond the sells discharge point. If the next process can't use it, recovering sell time might create more waiting stock without changing the quantity the plant can ship against its delivery commitments. The governing constraint can change with the product on one format. The Packers handling sequence might limit our cells output, while another format places more demand on the filler and leaves the packer waiting for containers. Operating conditions can move that constraint during the run. A downstream interruption or a change in usable buffer space can alter which equipment currently limits flow. Even though the product and approved machine settings remain unchanged, that changes what a faster filler achieves when the packer already determines the cell's sustainable output. Pushing more containers onto the conveyor fills the buffer sooner rather than increasing finished packs, leaving the cell over that production period. A buffer can still protect production against brief upstream interruptions. Its useful size depends on that protective role, the product, and the available space, rather than a general assumption that keeping more unfinished production between machines always helps. Extra inventory carries practical consequences. Work in progress, meaning production started but not yet finished can occupy space, lengthen waiting time and increase the quantity affected. If quality later identifies a problem with that run, I'd ask whether shipments change before celebrating the local score. If the filler improves while the cell delivers no additional accepted packs and customer orders leave at the same time, describe the result as local improvement with an unproven delivery benefit. Throughput gives that discussion a physical reference. Measure usable output through the relevant process boundary over time, then check whether the local intervention increases that output under comparable demand and production conditions. Lead time asks a different question about the same orders. Track how long work takes from the agreed start point to completion, including waiting, because faster processing at one station can coexist with longer queues across the overall production route. Delivery keeps the customer commitment in the discussion. An order can move efficiently through our packaging cell and still miss dispatch, because another required operation or component isn't ready when the completed packs become available. Quality and safety remain operating limits, not tradable. Score adjustments a faster production route only supports the intended decision when output continues meeting requirements and the work remains within approved equipment handling and staffing conditions throughout that route. The production sequence can matter as much as the running rate. Scheduling several compatible formats together might reduce change over demand, but delaying an urgent order to achieve that grouping can create a delivery problem larger than the time recovered. This is where detailed scheduling earns its place. Advanced planning and scheduling, or APS, concerns building schedules against finite capacity using the available resources and production constraints. Instead of assuming every requested operation can start whenever its order needs it. The schedule needs more than machine availability for our cell. A proposed sequence may also depend on packaging material, qualified staff, and the required format tooling being available together when production is supposed to begin. Scheduling software needs those conditions represented in its inputs. A newly measured improvement in the cell's operating capability should enter scheduling through an approved capacity assumption, rather than treating the ideal o e cycle as a promise that every order will finish at that pace, ERP remains part of that planning conversation. It can hold requirements, production orders, inventory and business transactions. While the depth of detailed scheduling depends on the particular system configuration and processes your organization actually uses. Some ERP implementations already support capable finite scheduling. Others need a connected scheduling application to represent the required shop floor detail, so assess the actual planning gap before deciding that another software category belongs in the architecture. A feasible schedule still needs operational review. The planner and production team should confirm that its resource assumptions and sequence reflect the conditions they'll work under, especially where constraint changes with the format or the surrounding production flow. Now, the investigation has a better question to answer. Instead of asking how to raise the cells percentage, we can ask which recoverable loss prevents a required order from progressing through a feasible plan. With evidence ready for a more focused investigation, an assistant could help investigate that question, provided it can retrieve the evidence. Artificial intelligence, or AI, becomes useful here when it helps you find relevant production records and examine possible explanations with enough references to check its answer. Start with a question. The records can actually answer. You might ask which recorded interruptions delayed a particular packaging order, then request the associated operator comments and maintenance findings. Rather than asking why the cell's overall score fell. The application needs a controlled retrieval path. It should query authorized production records using the equipment order and period in your question, then return identifiable events rather than letting the language model invent a plausible shift narrative. A Microsoft based assistant could call a governed query service for that retrieval. Your team still defines which records the service, exposes how permissions apply, and which validated calculations the assistant can request without writing unrestricted queries against production systems. Keep the arithmetic in the tested calculation layer. The assistant can request a loss breakdown and explain its contents, while the Analytical Service supplies the quantities under a declared calculation version and returns references supporting those quantities. Free text reason notes provide another bounded use. Operators might describe similar interruptions with different wording, and a language model can propose groups of related comments that help an engineer find patterns without reading every entry individually. Treat those groups as suggestions not corrected. Production history. If the model groups guide jam with damaged guide, a reviewer needs to check whether the notes describe the same mechanism before using that grouping to support an investigation. Draft explanations can reduce preparation work for a production review. Ask the assistant to distinguish recorded observations, operator interpretations and unresolved questions. With each factual statement connected to a source, the reviewer can retrieve and inspect. The answer also needs its measurement context. Include the production segment, applicable calculation version, and data completeness status with the retrieved evidence so the assistant knows whether it's explaining a settled result or an account that still contains gaps require uncertainty to appear in the explanation itself. A missing period of telemetry should limit what the assistant claims about interruption frequency, rather than disappearing behind a fluent paragraph that sounds more complete than the supporting production record. Relationships can become difficult to retrieve across several systems. A knowledge graph models explicit connections between things, allowing an application to follow links from an order to its production segments, equipment configuration, and recorded losses when those relationships are maintained. Use that option where the relationship complexity warrants it. A well structured relational model may already answer the required questions, so adding a graph should solve a demonstrated retrieval problem rather than become another prerequisite attached to every AI proposal, a graph connection still needs a stated meaning. Linking a material batch to a production segment establishes where the material was used, while linking. A loss to that segment. Establishes co-occurrence without proving that the material caused the loss. That distinction belongs in every generated recommendation. The assistant might report that transfer interruptions appear more often in records associated with a particular material batch, but an engineer still needs to test competing explanations before naming a cause. Feasibility requires evidence beyond an apparent association. A suggestion to change the production sequence needs current resource and order constraints checked through the approved planning process rather than assuming that an explanation of past losses establishes a workable future schedule, keep machine actions behind a separate approval boundary. An assistant can prepare an investigation request or draft a proposed change, but authorized workflows and qualified owners must assess safety implications before anything affects equipment, operation or approved settings. Permissions should enforce that boundary, not just describe it. Give an investigative assistant access to the evidence it needs without granting control. Write privileges and record its retrieved sources and proposed actions so a reviewer can establish what supported the recommendation. The useful output is a reviewable claim with evidence attached that gives us a way to judge a bounded implementation. Can the team check the assistant's explanation, identify its limits, and decide whether the proposed investigation deserves action? Choose a starting cell that your team can actually verify. For the first implementation, I'd favor accessible signals, an observable count point, and operators willing to help check the record over an asset selected mainly for its financial importance. Access matters more than apparent simplicity. A modest cell with an understood controller and available production support can provide a better starting point than newer equipment, whose signals nobody has permission to inspect or explain. Make operator involvement part of the work allocation. Arrange time for someone familiar with the cell to review observations during commissioning, rather than expecting useful answers whenever an engineer interrupts them between production tasks. Agree on the measurement contract before expanding collection. Have the people responsible for the cell approve the specific choices that will govern its result? Then identify any unresolved decision that prevents the team from accepting the calculation. Keep the initial reporting scope equally narrow. You need enough detail to investigate the cell's result without building a plant wide reporting structure. Before anyone has demonstrated that the first equipment boundary produces a trustworthy account. Run the calculation alongside the existing production review for an agreed trial period. During that period. Use discrepancies to investigate the implementation rather than replacing an established record immediately and leaving the crew to resolve competing official numbers. Select observation periods deliberately include ordinary production and the operating situations that could challenge this particular cells interpretation. So acceptance doesn't depend entirely on a quiet run where almost any calculation would appear reasonable. Give the observer a specific recording task. They might note witness transitions and bounded output quantities, while another team member retrieves the corresponding production records and inspected quantities without changing either source to make them agree. Compare those accounts. While the circumstances remain familiar when a mismatch appears, ask whether it comes from observation limits, collection behavior, or an unresolved production definition before treating the reporting pipeline as either correct or defective. Define acceptance criteria before seeing the trial results. State the permitted timing and count differences based on what the collection method can support, with production approving whether those limits are adequate for the decisions being proposed. Unknown periods need an acceptance criterion to decide how much unsupported production evidence the team can tolerate for the intended use, and reject a seemingly complete result if its confidence depends on silently filling those periods. Include recovery in the acceptance session, ask someone other than the original developer to reproduce a selected result and explain any correction using the retained records and instructions, rather than undocumented knowledge from the implementation team. A successful demonstration isn't yet an operating arrangement. Assign the routine checks and the response to failures, then confirm that the people receiving those responsibilities can perform them with the access and time they've actually been given. Only then, choose the first loss reduction action. Use an accepted portion of the production record to support one bounded intervention, and establish beforehand which observation would count as evidence that the intended loss actually decreased. Follow that intervention through its verification period. If the record can't distinguish the effect of the change from differences in production conditions, extend the observation or narrow the claim instead of declaring the pilot successful. Scaling needs a release decision, not just another connection, before adding the next asset. Confirm that the first cell has both an accepted measurement and a verified improvement, with remaining limitations documented for whoever will operate the system. Carry the tested method forward. Not every cell specific assumption. The next asset needs its own signal review and boundary decisions. While the team reuses the acceptance process and recording practices that survived the first implementation pause expansion when the evidence stops holding together, connecting more equipment before resolving a recurring discrepancy increases the number of results that might need correction and makes the investigation compete with an expanding support workload. That pause protects the purpose of the investment. The first cell should leave your team able to defend a production decision from measured evidence, not merely demonstrate that machine messages can reach an attractive report. Publishing creates an obligation to answer questions. Once the score enters a production meeting, someone will use it to challenge a loss or justify work, and your team needs an explanation stronger than. That's what the system calculated. Trust rests on explainable minutes, counts, standards and corrections. When a score rises without a traceable production change, the next proposed action still lacks a defensible basis. However confidently the report presents its result. Which OE input causes the most disagreement in your plant. I'd be interested to compare how you're resolving that specific dispute, especially where the published number and the crew's account still point toward different work.