Quick orientation to align on the pilot line

• Tell me briefly which production line you're proposing for the proof of concept and why it is the priority today.
• Describe your line's typical shift pattern, target throughput, and the top three KPIs plant leadership watches for this area.
• When was the last time your line had a planned control or network change, and what went well or wrong during that effort?
• Who operates and maintains the PLCs on this line and who formally approves configuration or firmware changes?
• Which of your systems, such as MES, ERP, historian, or lab systems, currently receive any data from this line? Options: No downstream systems receive data, Historic CSV exports only, Local historian only, MES only, ERP only, MES and historian, Other
• How often do your technicians manually record machine status or quality readings during a typical shift? Options: Continuously with paper log, Hourly, Per shift, Only at shift end, Irregular / ad hoc
• State whether inability to provide vendor access to the line within two weeks would prevent the pilot from starting, and explain why or why not. Options: Yes, it would prevent the pilot, No, we can adjust schedule, Maybe, depending on scope

Where visibility actually fails, not where reports say it does

• If you had to point to one recurring blind spot on this line that costs time or scrap, what is it and how often does it occur?
• Give a concrete recent example when missing production data delayed a decision or concealed a quality issue, and walk me through the operational impact.
• Estimate the average minutes per shift your team spends on manual data collection or waiting for off-line reports for this line. Options: <15 minutes, 15–30 minutes, 30–60 minutes, 60–120 minutes, >120 minutes
• Choose the types of failures that cause the most unplanned stoppages on this line Options: Mechanical, Control logic/PLC, Network/connectivity, Material feed, Operator error, Quality inspection
• What single data gap would make you stop a pilot before it starts?

Which plant security or network rule will set the pilot scope

• Name the security policy or network rule that has blocked integrations in the past and how regularly it has prevented work at your site.
• List the network zones that are strictly air-gapped from your IT network and the role that can authorize temporary exceptions.
• Do you run industrial firewalls, protocol filters, or intrusion detection for OT, and which team owns their configuration? Options: No centralized OT controls, Basic firewall only, Dedicated OT firewall and IDS, Protocol filtering appliances, Other
• If a vendor required inbound connections for telemetry, would that be permitted by your current site policy? Options: Yes with approval, Not permitted, Only through a vetted gateway, Unsure, need to check
• Select the network segmentation model your site currently uses for OT systems Options: Flat OT network, Basic segmentation by line, Zone-based segmentation with jump hosts, Strict air-gapped cells, Hybrid segmented with gateways

Who needs to say yes and what would move them quickly

• Who are the decision makers across your operations, IT, and plant management who must approve a pilot and the rollout?
• For each role you named, state their primary success metric for the pilot, such as uptime, quality yield, cost per unit, or cycle time. Options: Uptime, Quality yield, Cost per unit, Cycle time, OEE, Other
• Assuming the pilot achieves the promised improvement in 60 days, what barriers would remain to approving expansion immediately?
• Identify the person or role who will be the day-to-day owner of the edge gateway and the person who will manage credentials.
• How senior is the person who must sign for the budget to proceed after a successful pilot? Options: Plant Manager, VP of Manufacturing, CFO, CTO/CIO, Cross-functional committee

The alternatives you're actually weighing

• What would have to be true about your incumbent or an internal build for you to keep it instead of changing?
• List the external vendors, pilot partners, or internal teams you are actively considering for connectivity, analytics, or integration work.
• Is there an internal team proposing a self-build approach and do they have an owned roadmap and budget? Options: Yes, roadmap and budget exist, Yes, roadmap exists but no budget, No internal plan, Undisclosed
• What single condition would cause you to abandon an external pilot and commit to an internal build?
• Choose the option your leadership currently favors Options: Keep incumbent vendor, Build internally, Run multiple vendor pilots, Select a new vendor after pilot, Undecided

Concrete constraints and the facts that will gate the pilot

• Identify the single infrastructure gap that would prevent a 60 to 90 day line-level pilot from proceeding at your site.
• Does your site have defined physical access windows and who provides badge or escort access during those windows? Options: Yes, defined windows and escort, Yes, windows but no escort, No defined windows, Access handled case by case
• Are your MES, ERP, or historian APIs accessible and documented, and who on your team owns those endpoints? Options: APIs documented and accessible, APIs exist but access restricted, No APIs available, Unknown
• Estimate the internal headcount you can dedicate to pilot support, expressed in full time equivalents. Options: <0.5 FTE, 0.5–1.0 FTE, 1–2 FTE, 2–5 FTE, >5 FTE
• Is there any legal, safety, or regulatory approval that would outright block a pilot at your location and what is the expected lead time? Options: No blocking approvals known, Yes, requires safety review (2–6 weeks), Yes, requires legal review (2–12 weeks), Unsure
• Select your site's network change window availability Options: Daily maintenance window, Weekly window, Monthly window, No scheduled window, ad hoc only

Exact controllers, protocols, and the machines we must touch

• Name the top five controller models, their manufacturers, and the firmware generations we will encounter on your line.
• For each controller, indicate the protocol in use on the wire, for example OPC UA, MQTT, Modbus, EtherNet/IP, PROFINET, proprietary, or serial. Options: OPC UA, MQTT, Modbus, EtherNet/IP, PROFINET, Proprietary, Serial/Legacy
• Provide the count of unique PLCs, HMIs, and smart sensors that are in scope for the pilot. Options: 1–5, 6–10, 11–20, >20
• Point to one machine on the line that poses the highest connection risk because of proprietary firmware, an undocumented protocol, or lack of spare parts.
• Which controller on your line communicates only with a vendor tool and would require vendor-approved connector or supervised integration? Options: No vendor-only controllers, One or more vendor-only controllers, Unknown, need to confirm
• Select the protocols we should prepare mapping rules for during the pilot Options: OPC UA, MQTT, Modbus RTU/TCP, EtherNet/IP, PROFINET, Serial ASCII/Proprietary

Assuming this proves out, how do we move fast

• Assuming the pilot proves reliable data flow, security, and operator adoption in 60 days, describe the sign-off package and the roles that must authorize rollout for your site.
• Provide the measurable KPIs that will determine pilot success, include target values, measurement windows, and the data owner for each KPI.
• State the single budget or contractual approval that must be completed before expansion and the typical approval lead time.
• Pick the pilot length your team will commit to Options: 30 days, 60 days, 90 days, 120 days
• Share the on-site primary contact, the escalation contact, and the IT or OT gatekeeper we will need for access and approvals, include role and contact method.
• Pick the access window types your site can provide for on-site work Options: Day shift only, Night shift only, Off-shift maintenance window, Weekend windows, Ad hoc with escort

• Install and commission edge gateway hardware
• Configure PLC and controller protocol adapters
• Implement OT network segmentation and firewall rules
• Deploy local data buffering and edge storage
• Stream data pipelines to analytics endpoint
• Provision on‑premises analytics appliance
• Configure real-time production dashboards
• Deploy OEE and availability calculation engine
• Implement quality-correlation analytics
• Configure downtime capture and Pareto reports
• Enable energy monitoring and consumption dashboards
• Integrate with MES, ERP, and CMMS endpoints
• Deliver operator and engineer hands-on training
• Provide OT connectivity runbook and handover docs

Install and commission edge gateway hardware

• For the target production line, list the specific machines by asset tag or station ID where you expect an edge gateway to be installed.
• Where in the plant (control room, cell cabinet, conveyor pedestal) do you prefer gateway mounting for each machine group? Options: Control room rack, Local cell cabinet, Machine pedestal, Other
• How many separate environmental zones (temperature, washdown, dust) will each gateway need to support? Options: 1, 2, 3+, Not sure
• Provide the available power circuit details (voltage, breaker rating) and whether an uninterruptible power supply is present at each intended gateway location.
• State any physical access restrictions (lockout/tagout procedures, required PPE, safety interlocks) that will affect gateway installation timing or personnel.

Configure PLC and controller protocol adapters

• Confirm the controller inventory by listing PLC/controller model numbers, rack IDs, and firmware revisions for the line.
• Specify which industrial protocols each controller exposes (OPC UA, Modbus TCP, EtherNet/IP, PROFINET, serial) and provide port numbers or endpoint URIs if available. Options: OPC UA, Modbus TCP, EtherNet/IP, PROFINET, Serial/ASCII, Other
• Identify any proprietary device endpoints, serial devices, or custom ASCII protocols that will require driver development or serial-to-Ethernet adaptors.
• List the approximate number of tags/registers per controller you expect to collect for the POC dashboards. Options: <100, 100-500, 500-2,000, 2,000+
• Describe any read/write restrictions, safety interlocks, or controller scan rate limits that prohibit certain polling frequencies or control writes. Options: Read-only polling required, Read/write allowed with controls, Writes prohibited, Not sure

Implement OT network segmentation and firewall rules

• Indicate the current VLAN IDs, subnets, and gateway IPs assigned to the target line on the OT network.
• Do you have an existing demilitarized zone (DMZ) or jump host pattern for gateway-to-analytics traffic? If so, attach a current network diagram or single-line diagram. Options: Yes - DMZ exists, No - none, Unknown
• When are maintenance windows available for applying segmentation or firewall rule changes on the plant network? Options: Daily shift change, Weekly maintenance window, Monthly window, No windows available
• Will the IT/OT change control process permit temporary firewall rule changes for the 60–90 day POC and how should approvals be submitted (ticketing system, email, emergency change)? Options: Ticketing system, Email approval, Change board, Need to define
• Are there regulatory or corporate policies (for example IEC 62443, facility safety rules) that dictate segmentation, encryption, or access controls for this equipment? Options: Yes - IEC 62443 required, Yes - other standard, No specific policy, Unknown

Deploy local data buffering and edge storage

• Who will be responsible on-site for hardware staging, racking, and cabling during gateway commissioning (roles and contact names)?
• Name the local storage capacity requirement per gateway in gigabytes and the minimum free space threshold you require. Options: <16 GB, 16-64 GB, 64-256 GB, 256+ GB
• Attach or specify the maximum acceptable local retention period for edge-buffered data (hours or days) before forwarding to the analytics endpoint. Options: 1 hour, 6 hours, 24 hours, 7 days, Custom
• Upload any ISA-95, PLC tag mapping, or historian export files you maintain to accelerate tag mapping and buffering rules.
• Select the preferred encryption-at-rest approach for edge storage. Options: AES-256 full-disk, Filesystem-level encryption, No encryption required for POC, Other

Stream data pipelines to analytics endpoint

• Estimate the peak data throughput you expect from gateways to the analytics endpoint (approximate KB/s or records/min) during peak production.
• Validate the acceptance metric for reliable data flow for the POC (for example: >=95% sample delivery per tagged point over a rolling 30-day window; maximum 1% packet loss). Options: >=99% delivery, >=95% delivery, >=90% delivery, Custom
• Approve the preferred connection initiation pattern for gateway communications: gateway-initiated outbound only, or analytics-initiated inbound (requires inbound firewall changes). Options: Gateway outbound only, Analytics inbound allowed, Hybrid/other
• Assign the network owner who will provide NAT, DNS entries, and outbound allowlist entries required for gateway connectivity.
• Choose the transport protocol to the analytics endpoint. Options: MQTT over TLS, HTTPS REST API, AMQP, Other

Provision on‑premises analytics appliance

• Outline available rack space, network ports, and power circuits for an on-premises analytics appliance (rack units, PDU details).
• Detail whether you require bare-metal or virtualized deployment of the analytics appliance and any hypervisor constraints. Options: Bare-metal, VMware/Hyper-V, Not sure, Other
• Point to any internal server provisioning tickets or asset tags required before appliance delivery and installation.
• Include data residency or data sovereignty constraints that mandate on-premise analytics rather than cloud ingestion. Options: On-premise required, Cloud acceptable, Hybrid required, Undecided
• Note whether high-availability (clustering, failover) is required for the POC appliance or deferred to scale phase. Options: HA required for POC, HA deferred, Undecided

Configure real-time production dashboards

• Enter the list of KPIs and the exact PLC tag names or calculated fields that should appear on the primary production dashboard.
• Supply any existing dashboard templates, operator screens, or visuals you want matched for operator familiarity.
• Share the target user roles and permission levels (operator, supervisor, engineer) who should see each dashboard or alert. Options: Operator, Supervisor, Engineer, Manager, Other
• Confirm the numeric acceptance criteria for dashboard accuracy that will define POC success (for example dashboard metrics match manual counts within 5% or within X units). Options: Within 1%, Within 5%, Within 10%, Custom
• Present the expected refresh cadence for each dashboard (real-time stream, 5s, 30s, 1min) and any dashboards that may be historical-only. Options: Real-time (<1s), 5s, 30s, 1min, Historical

Deploy OEE and availability calculation engine

• Flag which sources should feed availability, performance, and quality calculations (PLC cycle counts, sensor pulses, SCADA event markers, MES counts). Options: PLC cycle counts, Sensor pulses, SCADA events, MES counts, Other
• Record the expected production shift schedule and planned downtime windows to be used in OEE calculations.
• Clarify the operational definition of 'run' and 'stop' for this line (for example conveyor motion threshold, spindle RPM) to ensure consistent availability metrics.
• Verify the acceptable percent error tolerance for OEE calculations compared to current manual reports that will be used as a POC acceptance criterion. Options: <=1% error, <=5% error, <=10% error, Custom
• Measure whether raw inputs required for performance (cycle times, throughput) are available in PLC tag lists or whether additional sensors or counters are required. Options: All available in PLC tags, Partial - some sensors needed, Sensors required, Unknown

Implement quality-correlation analytics

• Quantify the quality events you currently record on the line (defect codes, scrap counts, rework flags) and the tag/register where each is stored.
• Map available quality sensors and their PLC tag names to the product/process step they relate to (e.g., station ID, recipe name).
• Catalog historical batch or lot identifiers and indicate whether batch timestamps are correlated with PLC timestamps for root-cause analytics. Options: Batch IDs available and timestamped, Batch IDs available but not timestamped, No batch linkage
• Reference any lab test results, SPC outputs, or quality logs that should be ingested for correlation with sensor streams.
• Signal whether quality events are available in a historian, MES, or only as PLC discrete flags. Options: Historian, MES, PLC only, Other

Configure downtime capture and Pareto reports

• Capture your current downtime categories and root-cause taxonomy used by maintenance that should map to automated Pareto reports.
• Tag the PLC event codes or discrete inputs that indicate machine stoppage or fault states for automated downtime capture.
• Correlate shift logs and operator entries with PLC event timestamps to validate downtime attributions during the POC.
• Aggregate the minimum time slice for downtime reporting that aligns with your maintenance process (1 minute, 5 minutes, 15 minutes). Options: 1 minute, 5 minutes, 15 minutes, Other
• Align required Pareto reports to maintenance meeting cadences (daily standup, weekly review, monthly RCA) and preferred formats (CSV, PDF, dashboard). Options: Daily, Weekly, Monthly, Other

Enable energy monitoring and consumption dashboards

• Authorize access to PLC energy registers or direct meter read points and specify meter register mapping if known.
• Register the metering points required (main feed, per-machine, per-panel) and indicate measurement units (kW, kWh, Amps).
• Delegate who on your team will validate initial energy baselines and confirm meter calibration during POC baseline capture.
• Schedule any planned plant power events that would affect baseline energy measurements during the POC period.
• Book a time for an initial energy baseline capture with operations and maintenance present for verification.

Integrate with MES, ERP, and CMMS endpoints

• Reserve API credentials or interface accounts for each target endpoint and specify authentication method (API key, OAuth2, basic auth). Options: API key, OAuth2, Basic auth, Other
• Configure the specific MES/ERP/CMMS endpoints you want to sync by providing endpoint URLs and example payloads or field mappings.
• Set the data exchange cadence for each integration (real-time, hourly batch, daily batch) and the direction of sync (to the system, from the system, bi-directional). Options: Real-time, Hourly batch, Daily batch, Other
• Enable which fields or entities must be written back to enterprise systems from the platform (production counts, downtime events, quality flags).
• Disable automatic writebacks if your change control requires manual approvals for first-phase integrations. Options: Disable writebacks for POC, Enable controlled writebacks, No writebacks required

• decision_readiness
• gaps
• desired_state
• success_criteria
• current_state
• stakeholders
• desired_state
• stakeholders
• gaps
• decision_readiness
• success_criteria
• current_state
• current_state
• decision_readiness
• stakeholders
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Subscription Agreement / Order Form
• Master Services Agreement (MSA)
• Statement of Work (SOW) — Scale Rollout
• Acceptance Criteria & Signoff Certificate
• Data Processing & Access Authorization (DPA)
• Deployment Prerequisites & Network Authorization
• Change Order Agreement
• Regulatory Compliance Addendum (conditional)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Review (around day 90)
• Monthly Operations Check-in (ongoing operational cadence)
• Quarterly Value Review

• Close top 3 high-priority operational incidents and document permanent fixes or workarounds.
• Create a remediation tracker for failed criteria with target dates for resolution and re-test.
• Record the final configuration values and put them into the runbook for ongoing operations.
• Operational ticket and incident review
• Reduce open OT data incidents and improve mean time to resolve against the post-acceptance baseline.
• Increase the number of weekly active plant users or surface specific training or UX fixes needed to reach adoption targets.
• Prioritize and schedule high-impact enhancement requests for the upcoming delivery window.
• Re-confirm success criteria and owners
• Deliver a short user training refresh and usage tips summary for plant staff.
• Publish the agreed enhancement prioritization list and target delivery windows for the next month.
• Value realization report
• Confirm the solution is delivering the agreed operational value measured as hours saved on manual reporting and OEE improvement versus the baseline in Solution Scope.
• Validate that the enhancement backlog is progressing and that top requests have clear delivery windows.
• Set measurable checkpoints for the next quarter to monitor sustained adoption and value.
• Produce and distribute the quarterly value report with metric trends and supporting data extracts.
• Update the enhancement backlog with committed delivery dates for the top 5 items.
• Schedule the next quarterly review and define the metrics and data extracts to be provided in advance.
• Confirm the environment is configured as specified in Solution Scope and that the deployment baseline is stable.
• Enumerate and prioritize the top deployment issues with clear remediation actions and target dates.
• Confirm preliminary user onboarding progress and any required follow-up training.
• Publish the deployment verification checklist and current status for async review.
• Document each open issue with reproduction steps and target remediation windows.
• Schedule any required network maintenance windows to implement remediation work.
• Present measured data against target metrics
• Determine whether data collection reliability (percentage of expected PLC tags streamed) meets or is trending to Solution Scope targets.
• Verify dashboard data freshness (median latency in seconds) is within acceptable bounds or capture remediation needed.
• Agree on corrective actions and a re-measure schedule before the acceptance gate.
• Record and publish a tag-level gap list with required configuration or wiring changes.
• Schedule gateway firmware and mapping updates in the next maintenance window and document rollback steps.
• Provide a re-measurement report by the agreed date to confirm remediation effectiveness.
• Restate acceptance criteria and numeric targets
• Produce a documented acceptance decision with pass/fail recorded against each numeric target in Solution Scope.
• For any failed criteria, agree a remediation plan, re-test date, and final acceptance path.
• Ensure the acceptance decision and supporting data are archived for audit and operational handoff.
• Publish the acceptance decision document with pass/fail status and the named signatory or documented approval.
• Deployment and connectivity validation
• Adoption and user feedback
• Backlog and enhancement delivery summary
• Present outcome data against each criterion
• Diagnose root causes for any gaps
• Agree corrective actions with timelines
• Document pass/fail per criterion and capture signatory
• Operational health and adoption trends
• Early adoption signals and usage patterns
• Enhancement request triage
• Open issues triage
• Escalations and persistent blockers
• Agree next-quarter measurement checkpoints
• Confirm readiness timeline to acceptance gate
• Agree remediation plan for any failed criteria
• Agree short-term remediation actions