Industrial & Manufacturing
›
Industrial Manufacturing & Robotics
›
Industrial IoT & Digital Twins
Industrial IoT
Complex deployments where integration, safety, and operational handoff determine production success.
PTC ThingWorx
Siemens MindSphere
GE Predix
Bosch IoT Suite
Inside this journey
-
Pre-Discovery
Align the room on outcomes, decision process, and constraints before deeper discovery.
-
Stakeholder Alignment
Confirm decision roles across manufacturing, IT, OT, and plant management, timeline, and what success looks like for the POC.
Alignment Questions
Who’s in the room — and who actually decides?
- Which roles from your organization will actively participate in the POC conversations and execution?
- Please list the names, titles, and contact emails for the people you expect to be involved (or upload a quick list).
- Who holds final sign-off for POC success and budget release for scale?
- Thinking of past pilot projects, how did these stakeholders typically respond — fast alignment, slow deliberation, or frequent stalls?
- Which single stakeholder or group is most likely to block or delay this POC, and what is their most common concern?
If approval were an unopened box, what’s inside it?
- If a critical stakeholder said 'we need more time' one week before cutover, what would the impact be?
- What are the non-negotiable decision criteria your leadership will use to judge whether the POC moves forward?
- What is the expected internal approval timeline from pilot start to formal go/no-go, and are there fixed deadlines driving that (audit, board review, quarterly budgets)?
- Who in procurement or legal needs to approve terms, and what typical lead time do they require?
- How comfortable are your stakeholders with a 60–90 day POC cadence versus longer pilot phases?
When will you call this a win (and who rings the bell)?
- If the POC delivered continuous, accurate streaming from 5–15 machines but no immediate ROI, would you still consider it successful?
- Which of these success signals matter most to you? Select top three.
- For each signal you selected, what is an explicit acceptance threshold we should meet (e.g., data uptime 99%, dashboard variance <5%)?
- Who will own the formal POC acceptance test and sign the acceptance document?
- How do you prefer acceptance evidence to be presented—live demo, recorded sessions, KPI report, or operator sign-off?
What scares you most about connecting the line?
- Is cybersecurity the primary reason pilots get delayed here — or is there a different cultural or technical obstacle we should know about?
- Which OT security controls must be in place before any connection (select all that apply)?
- Describe any recent OT incidents or near-misses that influence your caution today and how long ago they occurred.
- Do you have an internal OT change control or maintenance window policy that will affect when we can install gateways or run tests?
- Which internal groups must be in the loop for security approvals (rank order if possible)?
What’s actually living on the line right now?
- How many machines and controllers do you expect to include in this POC line (give counts by machine type where possible)?
- Which PLC vendors and controller models are in scope (select known ones and add others)
- Which communication protocols are present on the line today?
- Do you currently have any historians, SCADA, or edge devices collecting this line’s data (names and brief description)?
- How is the OT network segmented for this line — fully isolated, DMZ-enabled, shared plant network, or other?
- What are the typical failure modes on this line that we should prioritize detecting during the POC?
If operators don’t love it, does the tech matter?
- Which operator or shift personas will use dashboards daily, and what is their comfort level with digital tools?
- How much training time can you realistically allocate during the 60–90 day POC for operators and engineers (hours per person)?
- Who will be responsible for daily monitoring of the POC data once live (name/role)?
- What would operator adoption look like for you after 90 days (example: 80% of shifts using dashboard daily)?
- Are there existing operator workflows or SOPs we need to respect or integrate into the dashboards?
Who will keep this ship moving when things get messy?
- If the project stalls for a week, who is empowered to escalate and recommit resources?
- What regular governance cadence do you prefer for POC reviews (frequency and attendees)?
- How many internal hours per week can your team commit to POC activities (engineering + ops + security)?
- Do you require a single named POC owner from our side and yours? If yes, please provide names and escalation contacts.
- What happens after a successful POC — is there a funded roll-out plan or a separate approval required?
The redlines: what would stop this before it starts?
- Which of these are absolute deal-breakers for you (select any that apply)?
- Are there contractual, legal, or regulatory approvals we must secure before any work begins? If yes, which ones and typical timelines?
- What access constraints should we plan around (e.g., night shifts only, weekends, maintenance windows)?
- What information or documentation would help you feel safe signing off to start (e.g., runbook, network diagram, security whitepaper)?
- Who should we contact immediately if a showstopper appears during the POC (name/role/phone)?
-
Current State Mapping
Inventory controllers, machine types, protocols, network segmentation, and failure modes that impact safe connectivity.
Current State
Quick Line Snapshot
- Which production line or cell will we use for the 60–90 day POC (name or ID)?
- How many machines on that line do you expect to include in the POC?
- What is the primary product or SKU family run on this line (brief description)?
- How many shifts and what is the typical uptime percentage for the line?
- Who is the day-to-day owner for this line (role/title) and who must sign off on POC access?
Are You Comfortable Having 'Unknown' Equipment on the POC?
- Do you have an up-to-date inventory of controllers and machine PLCs for this line?
- List the controller makes/models you believe are on the line (e.g., Allen-Bradley CompactLogix, Siemens S7-300).
- Roughly how many unique PLCs, RTUs, or embedded controllers are present on the line?
- Which of these machine types are on the line? (select all that apply)
- Are there any proprietary or OEM-only protocols/devices you know of (name vendor and device if known)?
When Connectivity Fails, Who Pays First?
- How often do connectivity-related incidents (data loss, PLC comms drop, gateway failure) occur on this line?
- Describe a recent incident where data or connectivity impacted production or safety—what happened and what fixed it?
- Which failure modes worry you most when adding a gateway or data collector to a line?
- When those failures happen, which teams get pulled in first and what’s the typical escalation path?
- How do operators currently work around missing or delayed data (manual logs, sampling, visual checks)?
Where Does Your Network Breathe—and Where It Holds Its Breath?
- Do you currently maintain a documented network segmentation/diagram that includes OT zones, VLANs, and firewall rules for this line?
- How isolated is the OT network for this line from enterprise IT and the internet?
- Which network controls are already in place that we must respect during POC (select all that apply)?
- Who owns network changes for POC work and what is the typical lead time for approvals?
- Do you allow direct outbound TLS connections from OT gateways to cloud services, or is an approved proxy/DMZ required?
If Data Could Talk, Would It Tell The Truth?
- Do you have an existing historian or SCADA that already collects tags from this line?
- Estimate the number of tags/points you’d like streamed during the POC (approximate ranges are fine).
- Which KPIs or signals are highest priority to validate in the POC (select up to 3)
- Have you observed data quality issues (missing timestamps, gaps, noisy readings)? If so, give an example.
- Is local edge buffering acceptable if temporary network interruptions occur (i.e., store-and-forward on gateway)?
What Would You Lose If This Line Went Quiet?
- If connectivity were lost for 4 hours during a production run, what would be the primary impact?
- Can you estimate the dollar-per-hour impact of an unplanned line stoppage on this line (ballpark)?
- When data is unavailable, how do downstream teams (quality, supply chain, ops) cope—do they delay decisions, use estimates, or stop processes?
- What manual checks, SOPs, or failsafes must remain in place while we run the POC to ensure safety and compliance?
- Who must be notified immediately if POC connectivity disrupts production or safety systems?
How Much Risk Are You Willing to Tolerate?
- Are remote vendor or cloud connections allowed from the OT environment for POCs, and under what constraints?
- Which OT security controls are mandatory for any new gateway or connector (select all that apply)?
- Do you have formal change control or safety review boards that must approve POC designs before any line connection?
- What is your patching and firmware update policy for OT devices—can we install temporary agents or do we need a no-change approach?
- Has your team completed any recent OT risk assessments for third-party connectivity on this line? If yes, summarize the outcome.
What Would Make Your Engineers Sleep Better?
- How much dedicated operator/engineer time can you commit during the 60–90 day POC (hours per week)?
- Do we have remote or physical access to cabinets, PLC programming ports, and network closets for gateway installation?
- Which vendor/OEM support commitments are available if we need access to proprietary PLC registers or protocol specs?
- What maintenance or change windows are acceptable for non-disruptive install and testing?
- Who are the key internal stakeholders we must keep aligned during the POC (names/roles), and how do they prefer updates (email, weekly review, Slack/Teams)?
Small Test, Big Proof — What Would Convince You?
- Which of these outcomes would most convince leadership to scale after the POC (select up to 2)?
- What specific acceptance criteria must we meet to mark the POC as successful (be specific and actionable)?
- How will POC results be validated—who signs off and what artifacts do they need (dashboards, logs, security test report)?
- If the POC meets technical success but fails to show ROI within 90 days, what would you consider an acceptable next step?
- What concerns or objections do you anticipate from IT, OT, or operations that we should address up front?
-
-
Outcome Discovery
Define POC success signals—reliable data flow, dashboard accuracy, security validation, and operator usability—within a 60–90 day window.
Discovery Questions
Start Here — Tell Us About This POC
- What's the single, practical goal you're hoping this 60–90 day POC will prove?
- Which POC timeline are you aiming for?
- Who are the core stakeholders that must be convinced by the outcome? (select all that will need to sign off)
- Status check: where are you in the internal approval/budget process for this POC?
- What constraints or non-negotiables should we know about before designing success signals (e.g., no external internet, maintenance windows, union rules)?
If We Only Had 60 Days, What Would Change?
- If you had to pick one outcome that would make you stop evaluating alternatives at the end of the POC, what is it?
- Which of these outcome signals are must-haves for your decision (select all that must be demonstrated)?
- For the signal you consider the single deal-breaker, what is the measurable threshold (e.g., % uptime, max latency, allowed data gap)?
- If that threshold isn't met, what is the realistic consequence for the project or team?
- Have you run similar POCs before that didn’t convince stakeholders? Briefly describe one and why it failed to land.
Where the Floor Really Talks (and Where It’s Silent)
- Which devices or controllers on the target line have historically been the hardest to extract reliable data from?
- Select all controller/device types present on your target POC line
- Approximately how many unique tags/points do you expect to stream from this line?
- Describe any intermittent failure modes you've observed that impact data (timeouts, controller reboots, cable faults, protocol errors).
- How is the OT network for this line currently segmented or accessed?
- Who owns PLC logic, tag definitions, and who can grant read access (roles/names)?
When Dashboards Don't Earn Trust
- When a dashboard 'looks right' but operations don’t act on it, what’s usually broken underneath?
- Which KPIs must be accurate in the POC dashboards for you to consider the visualization credible? (select all that apply)
- What tolerance or error margin would you accept for those KPIs to be considered accurate?
- Who on your team will be responsible for validating dashboard accuracy on the floor (role/name)?
- Will we be able to cross-validate dashboard numbers against a source-of-truth (select all that apply)?
- How frequently do dashboards need to refresh to be operationally useful?
Can Your Operators Actually Use This?
- If the platform delivered perfect data, would operators change how they work—or politely ignore it?
- Who are the primary users of the POC dashboards (select all that will actively use them)?
- Which training formats have proven most effective for your floor teams?
- How much time per operator can you realistically allocate to training during the POC?
- What concrete measure would demonstrate operator adoption in this POC (e.g., % daily active users, reduction in ad-hoc calls)?
- Are there SOPs, regulatory, or union constraints that affect screen access or data use on the line?
Security Is Not a Checkbox — What Keeps You Up?
- What's the single security concern that would prevent any line connection for a POC?
- Which of these OT controls are already in place for the POC line? (select all that apply)
- Are write-commands to controllers allowed during the POC?
- Which security validation steps must be completed before you can accept the POC? (select all that apply)
- Who signs the OT security approval (role/title) for the POC to proceed?
- If a security concern is discovered during the POC, what is the immediate escalation path you'd expect?
Decide Together: Acceptance Criteria That Don't Leave Room for Guesswork
- If acceptance criteria are vague, we’ll argue later—what’s one acceptance detail you refuse to accept after the POC?
- Data Flow — which metric will be our primary indicator that streaming is reliable?
- Dashboard Accuracy — how will we verify dashboards match reality?
- Security Validation — what combination constitutes a security pass for acceptance?
- Operator Usability — which single measurement defines success for adoption?
- Who is the final sign-off authority for POC acceptance (role/title)?
- If acceptance criteria are met earlier than planned, are you open to accelerating a scale plan?
Next Steps — Who Does What, When
- If roles and dates aren't nailed down now, the POC becomes everyone’s problem—who must be accountable for day-to-day execution?
- Who will be our primary technical contact for on-site access and troubleshooting (name/role)?
- Which of these milestones do you want explicitly included in the 60–90 day plan? (select all)
- How often should we review progress and KPIs together during the POC?
- What explicit access & approvals must be in place before any line connection (network access, admin creds, physical access, vendor approvals)?
- Are there any known blackout or plant maintenance windows during the POC that will affect schedules?
- Is there anything additional you'd like us to commit to measuring, protecting, or delivering during this POC?
-
Solution Experience
Use the customer’s line context to validate how the platform delivers measurable outcomes (data flow, dashboards, and operator workflows).
Experience Meetings
- Line Context Alignment (Pre-Experience)
- Data Flow Validation (Line-level Proof)
- Dashboard & KPI Validation (Outcome Proof)
- Operator Workflows & Handover (Usability Proof)
- Experience Review & Mutual Validation (Decision Meeting)
- Agree on runbook content, training schedule, and handover owners.
- Seller: Implement any immediate mapping fixes and schedule follow-up verification.
- Customer: Validate that test results match internal expectations or provide counterexamples.
- Status Check
- Confirm that KPIs and dashboards accurately reflect line performance against the defined consequence.
- Obtain operator/engineer validation that dashboard outputs match ground truth and are actionable.
- Document required dashboard adjustments and re-validation plan with owners and timelines.
- Seller: Deliver dashboard configuration export, KPI calculation doc, and a change log for requested updates.
- Customer: Provide baseline spreadsheets or shift logs for KPI cross-check where discrepancies appear.
- Seller: Implement agreed dashboard adjustments and schedule rapid re-validation with customer SMEs.
- Customer: Nominate the operator/engineer who will sign the dashboard acceptance.
- Purpose & Scope
- Prove operators can complete key tasks using the platform without data-science intervention.
- Identify usability gaps, training needs, and required changes to workflows or screens.
- Introductions & Objectives
- Customer: Provide 1–2 operators and a shift lead for hands-on validation and a quiet environment for the exercise.
- Seller: Produce a runbook draft, short training deck, and a checklist for operator handover.
- Seller & Customer: Schedule training sessions and assign ownership for ongoing operator support.
- Customer: Provide acceptance or list of usability fixes required before POC sign-off.
- One-sentence Recap (Current / Future) & Consequence
- Mutual agreement on whether the POC proves the defined future state against acceptance criteria.
- Documented remediation plan with owners and timelines if the POC is not accepted.
- If accepted, agree immediate next steps for scale, governance, and commercial progression.
- Seller: Produce a concise Experience Report that maps evidence to each acceptance criterion and includes log attachments.
- Customer: Provide official POC acceptance sign-off or a prioritized remediation list with owners and target dates.
- Seller & Customer: Schedule the Validation Checklist meeting and Deployment Readiness review if POC is accepted.
- Seller: If remediation required, provide a timeboxed remediation plan with estimated effort and resource needs.
- Produce a one-sentence current state that everyone can repeat.
- Surface and quantify the consequence of the current state for the business/line.
- Define a one-sentence future state (operational outcome) that the experience must prove.
- Agree explicit POC success signals and a list of pre-work artifacts with owners and deadlines.
- Customer: Deliver line inventory, network diagram, PLC/controller list, and sample tag list.
- Customer: Provide baseline KPI numbers or recent shift reports to quantify consequence.
- Seller: Draft proposed POC acceptance criteria and initial connectivity plan based on received artifacts.
- Seller: Share a short checklist of required access and security validations for pre-deployment.
- Recap Alignment
- Prove reliable, authenticated end-to-end data flow from PLC to analytics for selected tags.
- Measure buffering, latency, and data loss under controlled failure modes and compare to acceptance thresholds.
- Validate tag mapping and data integrity so dashboards can be trusted.
- Agree on remediation tasks and owners for any gaps found.
- Seller: Deliver connection logs, latency and buffering metrics, and a short report comparing raw vs platform values.
- Customer: Enable required access for any remaining PLCs/gateways and confirm point-of-contact for OT support.
- Current State — One Sentence
- Review Target Operator Tasks
- Agree KPI Definitions & Calculation Methods
- Connectivity Architecture Review
- Evidence Summary — Data, Dashboards, Operators
- Gap Analysis vs Acceptance Criteria
- Live Dashboard Walkthrough — Proof by Problem
- Roles & Test Plan
- Walkthrough of Operator Screens & Alert Flows
- Consequence — Quantify Impact
- Hands-on Operator Exercise
- Decision & Agreement
- Future State — One Sentence
- Live End-to-End Connection Test
- Edge Cases & Data Quality Discussion
- Buffering, Latency & Failure Mode Simulation
- Agree POC Success Signals & Acceptance Criteria
- Capture Training & Runbook Requirements
-
Solution Scope
Define the connectivity assessment, edge architecture, machines/tags, protocols, deliverables, and acceptance criteria for the POC and scale plan.
Scope Configuration
- Install and Configure Edge Gateways
- Connect PLCs via OPC UA/Modbus/EtherNet/IP
- Configure Read-Only PLC Access and Firewall Rules
- Deploy Local Data Buffering and Caching
- Stream Real-Time Telemetry to Analytics
- Create OEE and Production Dashboards
- Deploy Edge Anomaly Detection
- Implement Predictive Quality Models
- Integrate Platform with MES, ERP, CMMS APIs
- Configure Automated Reporting and Alerting Workflows
- Deliver OT Connectivity Runbook Documentation
- Train Plant Engineers on Platform Operation
Scope Questions
Install and Configure Edge Gateways
- Are edge gateways already installed on the target line(s)?
- How many gateway units do you expect to deploy for the POC line?
- Which gateway models or vendors are available or preferred?
- What physical installation tasks are required (mounting, conduit, power, grounding)?
- What network connectivity types are available at gateway locations?
- Are there power and environmental constraints for gateways (e.g., hazardous area, temperature)?
- Who will own and sign off gateway installation (Plant OT, Plant IT, vendor, contractor)?
Connect PLCs via OPC UA/Modbus/EtherNet/IP
- List the PLC vendors and models to be connected on the POC line.
- How many PLCs/controllers will be in-scope for the POC?
- Which industrial protocols are used by those PLCs?
- What is the available access method to each PLC (direct network, OPC server, serial/RTU, jump host)?
- What read/write permissions are acceptable for PLC access during the POC?
- Estimate the number of tags/points per PLC that should be collected for the POC.
- Do any PLCs require protocol translation or legacy adapters?
Configure Read-Only PLC Access and Firewall Rules
- Can the project obtain read-only accounts or credentials for PLC/OPC access?
- What is the current firewall policy between OT, DMZ, and IT for the target line?
- Which network architecture will host the gateway (OT VLAN, DMZ, separate subnet)?
- Are required IP addresses and port ranges for gateway communications available to share with the network team?
- Will firewall rule changes require a maintenance window or change control ticket?
- Is IP whitelisting or network scanning restriction required by OT policy?
- Provide any specific OT security constraints (e.g., no DNS, no outbound internet, jump host only).
Deploy Local Data Buffering and Caching
- Is intermittent connectivity to the analytics endpoint expected on this site?
- What retention window should edge buffers maintain during outages?
- Approximate average telemetry throughput to be buffered (per gateway)?
- Are there storage constraints on the gateway (disk size, SSD only)?
- Do buffered records need integrity checks (sequence numbers, checksums, timestamps)?
- Are there any regulatory or retention/compliance rules for local data storage?
- Should buffering include local preprocessing or aggregation before storage?
Stream Real-Time Telemetry to Analytics
- Where should telemetry be sent for analysis?
- What telemetry latency SLA is required for POC success?
- Estimate total telemetry channels/metrics to stream from the POC line.
- Which secure transport/protocols should be used for streaming?
- Is edge-level filtering or aggregation required before streaming to reduce bandwidth?
- Are there onboarding endpoints or API specifications available for ingestion?
- What data retention and access requirements apply on the analytics side for the POC?
Create OEE and Production Dashboards
- Which OEE components are required for the POC dashboards?
- How many dashboards or role-specific views are expected for the POC?
- Who are the primary users of these dashboards (operators, managers, quality, execs)?
- What refresh rate is required for the dashboards during the POC?
- Are there existing KPI definitions or a baseline OEE calculation to align with?
- Should dashboards include role-based access and scheduled exports/reports?
- Any visualization or branding preferences (templates, color schemes, device screens)?
Deploy Edge Anomaly Detection
- Which anomaly types should the POC target (sensor drift, spikes, missing data, equipment faults)?
- Is labeled historical data available to train or validate anomaly models?
- What false-positive tolerance is acceptable for alerts from the anomaly system?
- Should anomaly detection run on the edge or be cloud-hosted during the POC?
- Are compute and memory resources on the gateway sufficient for model inference?
- Do flagged anomalies need contextual information and suggested remediation steps?
- What alerting channels should anomaly alerts use during the POC?
Implement Predictive Quality Models
- Which quality metrics or defects should the predictive model target?
- Is historical labeled quality outcome data available for training?
- What prediction horizon is required (real-time, next batch, next shift)?
- Should models run locally on edge devices or centrally in cloud/on-prem?
- What validation metrics will define POC success for predictive models (accuracy, recall, precision)?
- Is integration with SPC/MES for feedback loops required during the POC?
- Describe the plan and ownership for model retraining and ongoing maintenance.
Integrate Platform with MES, ERP, CMMS APIs
- Which systems should be integrated in the POC (list MES/ERP/CMMS names and versions)?
- What integration direction is required (outbound to ERP, inbound from MES, bi-directional)?
- Are there existing middleware or connectors already in place?
- Is a data mapping/catalog available for the fields to be exchanged?
-
Mutual Commit
Agree commercial terms, responsibilities, POC acceptance criteria, timeline, and governance for the 60–90 day validation.
Agreement Modules
- Statement of Work (SOW)
- Master Services Agreement (MSA)
- Commercial Quote & Pricing Terms
- Purchase Order / Payment Authorization
- POC Acceptance Criteria Sign-off
- Roles & Responsibilities Matrix
- Timeline & Milestones Agreement
- Governance & Escalation Plan
- Security & Compliance Responsibilities
- Data Ownership, Access & Usage
- Data Processing Agreement (DPA)
- Site Access & Safety Authorization
- Change Order & Scope Management
- Termination & Exit Plan
- POC Support & Response SLA
- Insurance & Liability Evidence
-
Deployment
Operationalize rollout with readiness checks, enablement, and outcome validation.
-
Pre-Deployment Readiness
Confirm access, network segmentation, gateway placement, owner contacts, and OT security controls before any line connection.
Readiness Questions
Quick Line Snapshot — Getting Oriented Together
- Which production line, cell, or area will we connect for the 60–90 day POC?
- Please provide the exact name/ID, plant location, and a one‑sentence summary of what this line makes or does.
- What are this line’s normal operating hours and typical shift pattern (days, nights, weekends)?
- What uptime or throughput targets are we expected to avoid impacting during the POC (e.g., max allowable downtime window)?
- Who will be our day‑to‑day plant contact for scheduling and access (name, role, phone/email)?
Are We Ready to Plug In? — Physical Access & Practical Constraints
- If we asked for a 2–4 hour install window tomorrow, what would be the most likely reason you’d say no?
- What site permits, safety orientations, or lockout/tagout steps must our engineers complete before any work starts?
- Are the PLC/cabinet doors and control panels accessible during production, or do we need scheduled stoppages to open them?
- Do any of the machines on the line require special ESD, hazardous area, or cleanroom procedures for local connections?
- Who issues access badges or contractor authorizations, and what lead time is required to receive them?
Who's in the Room When Things Break — People, Authority & Escalation
- If our work caused a line alarm or stoppage, who has the authority to approve immediate corrective actions onsite?
- List the primary IT, OT, and plant contacts (name, role, email, phone) who must be looped in during install, test, and acceptance.
- Which organization signs the final POC acceptance (select all that apply)?
- Do you have an on‑call or escalation rota for nights/weekends if we need emergency remote support during the POC?
- Describe recent examples where a third‑party contractor caused unexpected production disruption — what happened and how was it resolved?
Is the Network Going to Protect or Prevent Us? — Segmentation, Rules, and Risk
- If someone says “we can’t expose OT to the internet,” what does that mean in practice here — no outbound, DMZ only, or strict firewall rules?
- Describe the network segmentation for this line: separate VLAN, shared OT VLAN, behind a firewall, or air‑gapped?
- Are there egress/ingress rules or a proxy that will block protocols/ports we need (OPC UA, MQTT, Modbus TCP, HTTPS)?
- Would IT prefer our gateway to use outbound TLS to a specific hostname/IP or to be routed through a customer proxy/forwarder? Please provide details.
- Do you require on‑premises data storage only, cloud outbound connections, or a hybrid model for the POC?
- Please attach or link to the network diagram, firewall rule set, or admin contact who can provide it.
Where Should the Gateway Live? — Placement, Power, and Environmental Constraints
- If we placed the gateway in your control cabinet, cell cabinet, or an equipment rack, which location do you prefer and why?
- Are there space, mounting, or cooling limitations at the proposed location (e.g., no rack space, limited DIN rail, high ambient temperature)?
- What power sources are available at the install point (24VDC from machine, 120/240VAC outlet, UPS/backup)?
- Do you require cellular (LTE/5G) fallback for outbound connectivity instead of plant LAN for install and testing?
- Will we need to provision static IPs or can we use DHCP on the OT VLAN for the gateway?
- Please note any physical entry restrictions (height, PPE, lockout schedules) the install team should plan for.
What Could Stop Data From Flowing? — Devices, Protocols & Known Quirks
- Which PLCs, controllers, or proprietary machines will we need to talk to on this line? (List make/model and firmware if known.)
- Select all protocols in use on the line that we must support during the POC.
- Are any control systems password‑protected, require explicit read/write credentials, or use certificate authentication that we must arrange for in advance?
- Do you have known machines that are sensitive to polling or will fault if polled aggressively (please name them)?
- Is there an existing tag list, PLC program map, or ladder/structured text documentation we can review before mapping tags?
- Have you experienced intermittent connectivity, cell‑level noise, or PLC crashes historically when integrating third‑party systems? If so, describe frequency and impact.
Last Mile: Approvals, Tests, and Acceptance — Defining Success Before We Begin
- If the POC must prove success in 60–90 days, what are the non‑negotiable acceptance criteria (select up to three)?
- What specific data quality metrics will you judge (sample rate, max missing samples per hour, latency SLA)? Please be specific.
- Who signs the POC completion certificate and what format of evidence do they need (dashboard screenshots, raw logs, OT security report)?
- Do you require a formal OT security test (vulnerability scan, firewall rule audit) before connecting to the line? If yes, who performs it and when?
- What is your rollback criteria and immediate action plan if the gateway or our integration impacts production? (e.g., immediate removal, revert config, emergency contacts)
- Would you like a pre‑deployment dry run (off‑hours simulation) before any on‑line connections? If so, preferred timing?
Scheduling & Logistics — Choosing a Launch Window that Works
- What are hard blackout windows for the next 90 days where no installs or changes are allowed (e.g., peak production runs, audits, holidays)?
- How much lead time does your OT, IT, and safety team need to approve and support an install (1 week, 2 weeks, 1 month)?
- For test and validation, do you prefer an initial remote setup followed by a single on‑site day, or a full on‑site two‑day install and validation?
- Who from your team will be available onsite for the initial install and the acceptance test (name/role/availability)?
- Are there logistics we should coordinate now (parking passes, gate codes, security escorts, or PPE provisioning)?
-
Deployment Enablement
Schedule and execute the POC: gateway install, tag mapping, secure connectivity, data buffering, and dashboard delivery with clear owners.
-
Validation Checklist
Verify data integrity, dashboard accuracy, OT security tests, and operator handover against acceptance criteria and document results.
Validation Questions
Quick confirmation — who’s in the room (and who signs off)?
- Who are the day-to-day contacts for the POC (name, role, and preferred contact method)?
- Who is the eventual sign-off authority for POC acceptance (role/title)?
- Which stakeholders must be engaged for any remediation that could affect production (list roles)?
- What is the agreed decision window for final acceptance once we deliver validation artifacts?
- Are there embargoed times (shifts/maintenance windows) when we must not run validation activities? List times and restrictions.
If the data looked great but production didn’t, what would you suspect?
- Where do you currently draw the line between ‘trusted’ machine data and ‘untrusted’ sources on this line?
- Which data quality issues have you historically seen on this line (select all that apply)?
- How much data latency is acceptable for POC dashboards to still be considered ‘real-time’?
- Describe a specific past example where data quality caused an operational error or false KPI — what happened and how long to detect it?
- What automated or manual checks would convince you that the streamed data is complete and untampered (e.g., CRC, sequence numbers, reconciliation)?
If a dashboard says ‘all clear’ while the line is actually struggling, who would you blame first?
- Which KPIs must be 100% accurate for you to accept the dashboard (pick top 3)?
- How do you currently validate dashboard numbers against ground truth (manual logs, MES, operator checks)?
- What margin of error is acceptable for KPI values during the POC (percentage or absolute)?
- Share a screenshot or example metric that has historically been misleading — what does it look like and why?
- Who from operations will be validating dashboards day-to-day and how will they log discrepancies?
What would make an operator refuse to use this new interface?
- How technically comfortable are your operators and engineers with web dashboards and basic troubleshooting?
- What handover format do your teams prefer: live training, recorded sessions, step-by-step runbook, or shadowing?
- What are the three must-have operator actions the POC dashboard must support without developer help?
- How many people need to be trained to reach basic operational self-sufficiency for this line?
- How will ownership transfer be measured — what does ‘operator-ready’ look like on day 1 post-handover?
If connecting this line could cause a near-miss, what single security lapse worries you most?
- Which OT security controls are mandatory before we connect (select all that apply)?
- What tests must pass to prove we did not degrade OT safety or availability (e.g., failover drill, CPU load test, protocol stress test)?
- Who in IT/OT must sign the security test results and what format do they require (report, logs, screenshots)?
- Do you require a dedicated window for security testing or can tests run during normal shifts? If dedicated, specify times.
- If a test revealed an anomaly, what is your maximum acceptable remediation time before rollback (minutes/hours)?
If I handed you the POC report today, what single artifact would make you say ‘this proves it’?
- Which of the following acceptance artifacts do you require for sign-off (pick all that apply)?
- For each acceptance artifact, what pass/fail thresholds should we apply (provide specifics or attach criteria)?
- Would you accept sampled evidence (spot checks) or require full-run validation for each KPI?
- Who is responsible for compiling the acceptance package, and who reviews it internally?
- How should discrepancies be documented and escalated during the acceptance review?
What would be embarrassing to exclude from the runbook?
- Which runbook components are non-negotiable for you (select all that must be included)?
- Where should the runbook live and who gets edit vs. view access?
- What SLAs do you expect for post-handover support (response and resolution targets)?
- Describe a realistic plan to keep the runbook current — who owns updates when you change tags, machines, or network?
- Which metrics will indicate the runbook and training were effective (e.g., fewer tickets, reduced mean time to resolve)?
If the POC proves value, what’s the single fastest thing that could derail your scale plan?
- Assuming acceptance, what is your target timeline to approve budget and begin line-by-line scaling?
- What dependencies must be resolved before scale (budget, staffing, network upgrades, vendor approvals)?
- Who will govern post-POC decisions (steering committee, monthly review, single approver)?
- What would you like our team to deliver in the final validation package to make the next steps frictionless?
- Finally, what outstanding concerns or risks should we address in the final validation review that we haven’t covered here?
-
-
Success
Review POC outcomes, capture the runbook and training handover, and maintain a shared channel for issues and enhancements.
Success Reviews
- POC Outcome Review & Acceptance
- Runbook & Operational Handover
- Training & Operator Handover Workshop
- Shared Channel, Support & Enhancement Governance
- Scale Planning & Executive Alignment
Issues & Enhancements
- Publish the incident triage template and escalation matrix to the channel and runbook.
- Deliver and obtain acknowledgement of the runbook and architecture diagrams by IT/OT and plant operations.
- Ensure on-site owners understand operational and troubleshooting procedures.
- Define document control and where operational artifacts are stored and updated.
- Publish final runbook, network diagrams, and configuration snapshots to the agreed document repository and share links.
- Record baseline configuration exports (gateway configs, firewall rules) and attach them to the runbook.
- Assign a runbook owner for ongoing maintenance and a cadence for periodic review.
- Training Objectives & Roles
- Ensure operators can use dashboards and respond to alerts independently.
- Ensure engineers and IT staff can validate data, remap tags, and perform routine maintenance.
- Obtain formal training sign-off and identify any gaps requiring follow-up sessions.
- Deliver training slide deck, quick-reference job-aids, and recorded session to the shared channel.
- Schedule follow-up refresher sessions and advanced workshops for engineers if gaps were identified.
- Create competency checklist and capture participant sign-offs in the project folder.
- Purpose of Shared Channel
- Create and populate the shared channel with the right participants and set clear usage rules.
- Agree SLAs and escalation paths so incidents are handled predictably and quickly.
- Establish an enhancement backlog process and cadence for prioritization and delivery.
- Create the shared channel, invite the defined list of participants, and post the communication charter.
- Introductions & Objectives
- Set up the recurring operational cadence meeting and initial reporting dashboard for data health and open tickets.
- POC Key Learnings Recap
- Obtain alignment on a prioritized, resourced plan for Wave 1 of scale and the timeline to execute it.
- Confirm required approvals, budget owners, and governance checkpoints for roll-out.
- Identify key risks and assign mitigation owners before execution.
- Produce a one-page Scale Plan (scope, timeline, resources, budget ask) for executive approval.
- Schedule kickoff for Wave 1 with detailed line-level assessments and dates.
- Assign program governance leads and set the first executive checkpoint date.
- Reach a clear POC acceptance decision agreed by IT, OT, Plant Management and Manufacturing Technology.
- Document measurable outcomes and quantify operational benefits or remaining risks.
- Agree remediation plan and owners for any outstanding gaps with target dates.
- Publish the POC Results Report (evidence, metrics, decision rationale) to the shared project repo.
- Assign owners and schedule remediation tickets for each identified gap with target completion dates.
- If accepted, initiate scale planning meeting and prepare executive summary for sponsor approval.
- One-sentence System State
- Current State Summary (one-sentence)
- Define Target Scope for Wave 1
- Architecture & Network Diagram Review
- Issue Triage & Escalation Workflow
- Operator Workflow: Dashboards & Alerts
- Runbook Walkthrough: Install & Configuration
- Acceptance Criteria Recap
- Engineer Workflow: Tag Mapping & Data Validation
- Resource & Staffing Plan
- SLA & Response Targets
- Runbook Walkthrough: Operations & Troubleshooting
- Enhancement Backlog & Prioritization
- IT/OT Workflow: Connectivity & Security Maintenance
- Integration & Dependency Review
- Measured Outcomes & Evidence
- Commercial & Contract Considerations
- Consequence & Benefit Quantification
- Operational Cadence & Reporting
- Security & Access Controls
- Run-through: Simulated Incident
- Gap Analysis & Remediation Options
- Assessment & Training Sign-off
- Onboarding & Access for Channel
- Sign-off Criteria & Repository
- Risks, Mitigations & Governance