Frequently Asked Questions

Traceability data is any information that links a finished product back to every input, process, and person involved in its creation. In manufacturing, this includes raw material lot numbers, machine settings, operator IDs, timestamps, inspection results, and quality check outcomes.

Full traceability means that if a product ever gets recalled, flagged by a customer, or fails in the field, you can pull up a complete birth history of that specific unit or batch quickly and accurately. Without traceability data, the fallback is paper logs that are incomplete, hard to search, and slow to produce during audits.

The two most common traceability models are lot-level (one record per batch of material) and serialized unit-level (one record per individual part). Serialized traceability is more granular and typically required in automotive and medical device manufacturing. Lot-level is more common in food and beverage and process industries.

The data has to be captured at the point of production. Records rebuilt from memory or paper at the end of the shift have gaps. It also needs to be stored in a structured, queryable format so it can be retrieved quickly when a customer or auditor asks.

Yes, with the right middleware. PLCs, CNC machines, sensors and conveyors generate real-time data, but they don't speak the same language as ERP systems like SAP, Oracle, or Microsoft Dynamics.

The two were built for different jobs. ERP systems manage business transactions such as orders, invoices and inventory movements. Shop floor equipment runs physical processes: machine states, cycle completions, sensor readings. Bridging them takes a system that understands both.

A Manufacturing Execution System (MES) typically handles this translation. It collects data directly from equipment, structures it into production records, and passes transactions such as production completions, scrap quantities, labor time and material consumption to the ERP, either on a schedule or when an event triggers them.

The connection method varies by equipment age and protocol. Modern equipment typically supports OPC-UA or Modbus TCP. Older equipment may require hardware interfaces or direct I/O connections. The ERP side usually accepts data through APIs, flat-file imports, or direct database writes depending on the system and version.

The most effective shift rosters in manufacturing account for three things a spreadsheet roster usually misses: real-time attendance, operator skills and certifications, and production demand by process.

A roster built without knowing who is certified for which process, or who called in sick, creates quality and safety risks. Supervisors end up assigning whoever is available instead of whoever is trained for that process.

Start with a current skills matrix: a record of which operators are qualified to run which machines or processes, and when each certification expires. Combined with real-time attendance data, it lets supervisors see coverage gaps before the shift starts and fill them before they turn into production problems.

For shift-based operations with variable demand, adding production targets by line or cell makes the roster more useful. If one area is running a high-complexity product that day, put your most experienced operators there instead of spreading them evenly across the floor.

The most important manufacturing data falls into four categories:

Production data: output counts, cycle times, target vs. actual performance, and any variance from planned rates. This is the basis of the OEE (Overall Equipment Effectiveness) calculation and the usual starting point for data collection projects.

Downtime data: when equipment stopped, for how long, and why. Without categorized downtime reasons, you can't prioritize improvement work. A plant can know it loses time to stops and still be unable to say where the time goes or what causes it.

Quality data: inspection results, defect types, scrap and rework counts, and SPC (Statistical Process Control) measurements. This tells you whether what you're producing meets specification, and gives you the data to find root causes when it doesn't.

Traceability data: material inputs, operator records, timestamps, and process parameters tied to specific units or batches. Required for customer audits, regulatory compliance, and field failure investigation.

Some of this data usually exists already, split across spreadsheets, paper logs, and systems that don't talk to each other. Bringing it into a single platform means managers make decisions from the same set of numbers.

Three practices do most of the work: digital quality checks, statistical process control (SPC), and classifying defects where they are found.

Paper inspection sheets leave gaps. Checks get missed, results are hard to add up, and trends stay hidden until a customer complains. When each digital check has to be acknowledged, it happens on schedule and every result is recorded, so conformance rates by line, area and shift are visible while the shift is running.

SPC monitors critical parameters and signals when a trend is moving toward a control limit, before an out-of-spec part is produced. The defect is prevented instead of being found at final inspection.

Defect classification at the source means the operator records the defect type at the station where it was found. Root cause analysis goes faster and Pareto data is more accurate, because each defect record shows where in the process it started and under what conditions.

Power BI is a visualization and analysis tool. It displays manufacturing data well, but it is not designed to collect data from equipment. To use it in a plant, you first need a system that connects to your machines and turns the raw signals into structured records.

Some teams build that connection themselves, writing queries against historian databases or pulling from PLCs with custom scripts. It often works at first, then turns into technical debt: the scripts need maintenance, break when equipment changes, and take IT time to support.

A more durable approach is a dedicated shop floor data collection platform underneath. It handles equipment connectivity, data engineering and storage, and produces a structured database that Power BI (or any other BI tool) can query for custom analytics and executive dashboards.

Plants that go this route often find that the standard reports in the data collection platform cover most day-to-day needs. Power BI earns its place in cross-functional reporting that combines shop floor data with ERP, financial, or supply chain data.

IIoT stands for Industrial Internet of Things: the network of physical devices, sensors, machines, and systems in industrial environments that collect and share data over digital networks.

In practical manufacturing terms, IIoT refers to the connectivity layer that allows production equipment to send data to software systems for monitoring, analysis, and control. A temperature sensor that feeds data to a quality system, a PLC that reports cycle counts to a production tracking platform, and an energy meter that logs consumption per shift are all IIoT applications.

The most common IIoT protocols in manufacturing include OPC-UA (the current standard for interoperability), Modbus (widely used on older equipment), MQTT (common in cloud-connected sensor networks), and proprietary protocols from major PLC manufacturers like Siemens, Allen-Bradley, and Mitsubishi.

Connectivity on its own produces streams of raw signals. They become useful once a platform structures and stores them as production records, quality results and maintenance events that people can analyze.

FTT stands for First Time Through. It is the percentage of units that complete every required production and quality step without rework, repair, re-test, or scrap on the first attempt.

The standard calculation is: FTT = (Units Entering the Process − Scrapped − Reworked − Repaired − Re-tested) ÷ Units Entering the Process.

For example: 1,000 units enter a line, 20 are scrapped, 35 are reworked and 10 are repaired. FTT = (1,000 − 20 − 35 − 10) ÷ 1,000 = 93.5%.

Across a route with several operations, plant-level FTT is the product of the individual operation rates (FTT₁ × FTT₂ × … × FTTₙ). Averaging them is a common mistake. A route of five operations each running a respectable 98% produces roughly 90% overall, so averaging the station numbers makes first-pass performance look considerably better than it is.

FTT is stricter than a simple pass/fail yield because a unit that shipped but needed a touch-up along the way does not count. The metric is meant to show whether the process gets the part right on its own, so a part that inspection and rework eventually fixed is still a first-pass loss. FTT also feeds the Quality component of OEE, so first-pass losses show up in both numbers.

OEE (Overall Equipment Effectiveness) measures how efficiently a piece of equipment or production line is running compared to its maximum theoretical capacity during scheduled production time. It's expressed as a percentage. A score of 100% means producing only good parts, as fast as possible, with no unplanned stops.

OEE is calculated as the product of three components: Availability × Performance × Quality.

Availability: what percentage of scheduled production time is the equipment actually running? A machine that runs for 7 of 8 available hours has 87.5% availability. Unplanned breakdowns, material shortages, and late starts all reduce availability.

Performance: when the equipment is running, how fast is it producing relative to its target rate? A line producing 80 parts per hour against a 100-part target has 80% performance. Minor stoppages and reduced speeds show up here.

Quality: of the total parts produced, what percentage pass inspection? A run of 800 good parts out of 1,000 total is 80% quality. Both scrap and rework reduce this figure.

Multiplied together: 87.5% × 80% × 80% = 56% OEE. World-class OEE is typically considered 85% or above. Because the three components multiply, a line that looks respectable on each one can still land well below that. OEE is most useful when tracked by individual machine or line, since a plant-wide average hides where the losses are.

Without data, decisions run on intuition, what someone happened to see on the floor, and end-of-shift summaries that are already hours old. That makes it hard to tell a systemic problem from a one-off, or to know which issue to take on first when several things go wrong at the same time.

Downtime data shows how often equipment stopped, for how long, and why, so you can pick out the biggest source of lost production instead of guessing. Quality data shows trends before they turn into customer complaints. Production data shows where actual cycle times drift from targets, and by how much.

A supervisor who can see during the shift that a line is running below target rate can step in while there is still time to recover. Without that, the same problem turns up in next week's meeting as a number on a spreadsheet.

The usual objection is cost or complexity. In practice, the machines usually produce the signals already. What's missing is a way to capture, structure and present them so the operations team can act on them.

Start with the data tied to your one or two biggest operational problems, usually output counts and downtime, and add more once that is running reliably. Trying to capture every signal in the first phase is a common reason these projects stall.

The technical starting point is equipment connectivity. Usually that means connecting PLCs, sensors, or control systems over industrial protocols such as OPC-UA or Modbus. Newer equipment typically has these capabilities built in. Older equipment may need a hardware input module or a signal tap on an existing output. An OPC server is often the cleanest way to standardize communication across machines from different manufacturers and eras.

Once machines are connected, the raw signals need structure. A pulse from a proximity sensor means nothing on its own. It has to become a production record with a timestamp, operator, product and shift. Defining that data model before collection begins saves a lot of rework later.

Then put the data where people will see it. Data sitting in a system operators never open doesn't change what happens on the floor. Show it to the operators, supervisors and engineers running the process, in a format they can read and act on during the shift.

You need to know where time and good parts are being lost, and be able to act on it while the shift is still running. Three levers usually matter most: downtime, the constraint, and quality at the source.

Downtime analysis is usually the place to start, because unplanned stops take more production time than plant logs tend to show. Once downtime is tracked by category (equipment failure, material shortage, changeover, operator absence), patterns show up quickly. Working on the top two or three categories typically recovers more capacity than most other initiatives combined.

Constraint management comes next. In any production system, one process limits the output of the entire line. Speeding up the other processes doesn't raise throughput; it only piles inventory in front of the bottleneck. Finding the true constraint and protecting it from upstream starvation and downstream blockage is often the highest-ROI move an operations team has.

Quality at the source is the third. A defect that reaches the end of the line, or the customer, has already used up material, labor and machine time. SPC monitoring and scheduled quality checks catch deviations earlier, so fewer bad parts get made in the first place.

Progress on one lever helps the others. Fewer defects means more good output through the constraint, and a protected constraint limits what downtime elsewhere on the line costs you.

Cp and Cpk are both process capability indices used in Statistical Process Control (SPC) to measure how consistently a manufacturing process produces parts within specification limits. They're often reported together, but they answer different questions.

Cp (Process Capability Index) measures the spread of the process relative to the allowable tolerance range. It answers: "is the process variation narrow enough to fit within spec?" The formula is Cp = (USL − LSL) ÷ (6σ), where USL and LSL are the upper and lower specification limits and σ is the process standard deviation. A Cp of 1.0 means the process spread exactly equals the specification range, leaving no margin for drift. A Cp of 1.33 or above is generally considered capable.

The limitation of Cp is that it says nothing about where the process is centered. A process could have tight, consistent variation but be aimed near one edge of the specification, producing parts that are technically in spec but with almost no margin. Cp would look acceptable while a centering problem goes undetected.

Cpk accounts for both spread and centering. It calculates the distance between the process mean and the nearest specification limit, relative to the process spread: Cpk = min[(USL − Mean) ÷ 3σ, (Mean − LSL) ÷ 3σ]. A Cpk below 1.0 means the process is producing out-of-spec parts, or is at risk of it. Cpk is always equal to or less than Cp. When the two values are close, the process is well-centered. A large gap between them signals a centering problem that Cp alone would miss.

In practice, Cpk is the more meaningful index for day-to-day quality monitoring. Tracking both gives the most complete picture: Cp tells you whether the process is inherently capable, Cpk tells you whether it's currently performing that way.

Pieces per labor hour (PPLH) is a productivity metric that measures how many units are produced for every hour of direct labor invested. It normalizes output against the labor applied, making it meaningful to compare across shifts, lines, or time periods even when crew sizes differ.

The calculation is straightforward: PPLH = Total Units Produced ÷ Total Direct Labor Hours. For example, a line that produces 480 parts during an 8-hour shift with four operators has used 32 labor hours, a PPLH of 15. If the same line produces 360 parts the following shift with the same crew, PPLH drops to 11.25 and the variance is immediately visible.

PPLH becomes most useful in trend analysis. A declining figure typically points to one of a handful of causes: increased downtime, slower cycle times, higher rework volumes, absenteeism reducing effective crew size, or a product mix shift toward more complex parts. Tracking PPLH alongside downtime and scrap data usually isolates the root cause quickly.

PPLH has limits worth understanding. It doesn't account for differences in product complexity, machine-constrained operations where adding labor wouldn't change output, or changeover-heavy schedules where a significant portion of shift time is non-production. Like OEE, it works best as one metric within a broader performance dashboard rather than as a standalone target. Using it as the sole productivity measure can inadvertently incentivize rushing at the expense of quality.

An MES (Manufacturing Execution System) and a CMMS (Computerized Maintenance Management System) address different aspects of plant operations, though modern platforms often integrate them or build them to share data.

An MES focuses on production: tracking what is being made, how fast, by whom, and with what results. It connects to production equipment to capture output counts, cycle times, downtime events, quality results, and traceability data in real time. The primary users are production operators, supervisors, and operations managers.

A CMMS focuses on maintenance: managing work orders, scheduling preventive maintenance, tracking parts inventory, and recording equipment repair history. When a machine breaks down, the CMMS is where maintenance technicians document what failed, what was done to fix it, and how long it took. The primary users are maintenance technicians, maintenance supervisors, and reliability engineers.

The two systems intersect most significantly around equipment downtime. When an MES detects that a machine has stopped, it can automatically generate a work order in the CMMS, so the maintenance request exists as soon as the stop is detected. When maintenance closes the work order, the completion data flows back to the MES.

In plants where the two systems are separate and don't communicate, this handoff typically happens by phone, radio, or paper, which brings delays, miscommunication, and gaps in the maintenance record. Integration between MES and CMMS is one of the more impactful connectivity improvements a plant can make.

No. An MES and an ERP serve different purposes and operate at different levels of the business, and plants usually run both.

An ERP (Enterprise Resource Planning) system manages business-level transactions: customer orders, purchase orders, inventory valuation, financials, HR, and scheduling at a high level. It operates in terms of orders and quantities — what has been ordered, what has been shipped, what is in inventory.

An MES operates at the shop floor level, in real time. It tracks production as it happens: which machine is running, what product is being made, how many pieces have been completed, what downtime has occurred, what quality checks have been performed. An MES works in seconds and minutes. An ERP works in hours and days.

The value of connecting an MES to an ERP is that shop floor data flows automatically to business systems without manual entry. Production completions post to inventory, labor hours flow to payroll, quality results attach to work orders, and nobody enters the same data twice. This reduces transcription errors and gives ERP data the accuracy of the machine-collected source.

The practical decision is how tightly to connect the two systems, and which transactions are worth automating versus managing manually.

Start by measuring all of it. Stops of a minute or two rarely get written down, yet together they can account for a significant share of lost production time without ever appearing on a report. Record every stop, including the ones nobody would have remembered to log.

Then give each stop a reason. A total of downtime minutes doesn't tell you what to fix; downtime sorted by reason (equipment failure, changeover, material shortage, operator absence, tooling, quality hold) does. Two or three categories usually account for most of the lost time, and those are the ones to work on first.

From there, the approach depends on the category. Equipment failures are best addressed through preventive maintenance: scheduled inspections and part replacements before failures occur, based on equipment history and manufacturer intervals. Changeover time is typically reduced with SMED (Single-Minute Exchange of Die), which separates internal setup steps (done while the machine is stopped) from external ones (done while it's still running). Material-related downtime usually points to scheduling or supply chain issues upstream.

Whatever the category, make the downtime data visible while the shift is running. When operators and supervisors can see it by machine, reason and shift, problems get escalated sooner, and patterns that a weekly summary would hide become obvious.

MES implementation timelines vary significantly depending on the scope of the deployment, the number of machines being connected, the complexity of the data model, and the maturity of the plant's existing infrastructure.

A focused first deployment, one production line with standard data collection (output, downtime, quality checks), typically goes live in two to four weeks. Rolling out to several lines typically takes four to eight weeks. This assumes equipment connectivity is straightforward and the plant team is available to participate in configuration and testing.

Larger deployments covering multiple lines, complex traceability requirements, ERP integration, or custom reporting can take three to six months. Getting reliable signals from every machine into the system usually takes the most time.

A few factors consistently extend timelines: equipment that requires custom hardware interfaces, ERP integrations that need IT involvement on both sides, unclear data requirements at the start of the project, and plant teams that are too stretched to dedicate time to validation and testing.

Phasing the rollout shortens the path to results. Start with the highest-priority lines, get them stable, then expand. Integration problems then surface a few at a time instead of all together on go-live day.

Your own team maintains the day-to-day. Once 10in6 is set up, plant staff manage operators, downtime and scrap reason codes, products, part numbers, cycle times and targets, shift schedules, scheduled checks, alerts, emailed reports, and real-time boards using the board builder. Showing your team how is part of go-live, and none of those changes needs a support ticket or an invoice.

A few things come through 10in6: connecting new machines and assets, adding modules or anything else that needs extra licensing, and custom reports built around your processes. A project manager who already knows your deployment handles those. If you would rather have 10in6 make everyday changes too, that is available as an optional service.

That sits between two common alternatives. Standardized platforms often make you adapt your process to theirs; do-it-yourself platforms leave your team to build and maintain everything from scratch. For a real example, Stackpole completed 75% of its rollout itself after 10in6 trained the team on a small set of checks.