The upset that brought you here

• In one sentence, describe the recurring process upset, yield loss, or energy waste that prompted you to explore OT analytics.
• How often does that issue recur in a typical month? Options: Multiple times per week, Weekly, A few times a month, Monthly, Quarterly or less
• Which asset or unit is most affected when this happens? Options: Distillation column, Reactor or vessel, Compressor or pump, Boiler or turbine, Heat exchanger, Utility system (steam or cooling), Entire unit or site, Other
• Walk me through the last time it happened, including how it was detected, who responded, and what the immediate workaround was.
• Who on your team typically recognizes the problem first and who approves remedial actions? Options: Process engineer, Shift operations lead, Maintenance supervisor, Control room operator, Reliability engineer, IT-OT lead, Other
• Estimate the operational cost or lost throughput per event in the terms you use to justify projects. Options: Less than $5k, $5k–$25k, $25k–$100k, More than $100k, Estimate not available
• Give the single reason that would make you decide not to proceed with an external analytics pilot.

Where your historian and spreadsheets stop helping

• What single analysis gap causes your team to stop short of a permanent fix when investigating an upset?
• Which artifacts do you rely on most during investigations? Options: Raw historian queries, Excel exports and ad hoc spreadsheets, Shift logs and incident reports, Control narratives, Alarm and event lists, Custom scripts or notebooks, Operator tribal knowledge, Other
• Describe how long it usually takes from first detection to a confident root-cause hypothesis.
• How often do you need to involve a data specialist or IT-OT engineer to get the data required for analysis? Options: Often, Almost always, Sometimes, Rarely, Never
• When investigation findings arrive late, what downstream decisions or operations are most affected?
• Which recurring missed insight would, if fixed, free up the most engineering hours each month?

Constraints that can stop a trial fast

• If there is one infrastructure or approval gap that would force you to pause a live connectivity trial, what is it?
• Do you have a documented OT change management or vendor access policy that governs external analytics connections? Options: Yes, documented and approved, Yes, draft in review, No, informally managed, No, nothing exists, Not sure
• List the historian and DCS access methods available to you and the teams that own each, for example read-only API, scheduled file export, or ODBC.
• Typically, how long does cybersecurity approval take for a new read-only integration window? Options: Less than 2 weeks, 2–4 weeks, 1–2 months, More than 2 months, Not sure
• Who will be the named approver for production historian access and are they likely to approve within your target timeline? Options: Named approver identified and available, Approver identified but timeline uncertain, No clear approver, Not sure
• If connectivity or approvals were the only barrier, what is the earliest realistic start date you could commit to? Options: Within 2 weeks, 2–4 weeks, 1–2 months, Longer than 2 months, No commitment possible

The data reality and how far models can go

• Too many models fail in production because events are unlabeled; how many of the events you want detected are consistently labeled and timestamped in your historian and shift records? Options: Most (>75%), Some (25–75%), Few (<25%), Almost none, Not sure
• Describe the typical sampling rate and retention policy for the tags most relevant to these events.
• Are tag names, units, and contextual metadata standardized across the unit or do local conventions vary by shift or equipment vendor? Options: Standardized and documented, Mostly standardized with exceptions, Highly variable by shift or area, Not standardized, Not sure
• What percentage of time-series data for the critical tags contains gaps or sustained missing values? Options: Less than 1%, 1–5%, 5–15%, More than 15%, Unknown
• If a model trained on historical regimes loses accuracy under shifted operating conditions, what is your fallback for detection and alerting? Options: Return to manual monitoring and spreadsheets, Use simpler threshold-based alarms, Engage SMEs for manual review, Pause analytics until retuned, Other

Who will judge success and how they will measure it

• Name the single operational metric that, if improved by a clear margin, would secure immediate sponsorship from your operations sponsor.
• List the stakeholders who must sign off to move from pilot to production and the primary concern each would raise.
• In practice, would your operations team prefer success measured as reduced downtime hours, fewer upsets per month, improved yield percentage, reduced energy use, or a combination? Options: Reduced downtime hours, Fewer upsets per month, Improved yield percentage, Reduced energy consumption, Faster time-to-hypothesis, Improved alarm-to-acknowledge times, Combination, Other
• Pinpoint the single internal approval, contract clause, or budget item that could delay a purchase even if the pilot meets targets.
• Assuming approvals align, how quickly could procurement approve a purchase if the pilot proves the expected benefit? Options: Within 2 weeks, 2–4 weeks, 1–2 months, More than 2 months, Unsure

The other paths you might choose

• Suppose you keep your current approach, what would need to change by next quarter to avoid switching to an external analytics platform?
• Choose all alternatives you are evaluating or have recently considered Options: An incumbent vendor or existing contract, An internal engineering automation project, A consulting engagement or system integrator pilot, In-house scripting and Excel workflows, Open-source toolchain, Do nothing and accept current methods, Other
• Has anyone proposed solving this entirely with internal resources instead of hiring a vendor? Options: Yes, formal proposal exists, Yes, informal suggestion, No one has proposed it, Not sure
• Explain what measurable advantage your current approach would need to show to justify keeping it rather than switching.
• Name the person or group most likely to advocate for an internal build and what authority they have to block vendor engagement.

Operational readiness and practical blockers

• Imagine your network policy forbids new inbound connections, what is your plan to provide the platform with the necessary data?
• Select the infrastructure items already provisioned for a pilot Options: Read-only historian API endpoint, Scheduled CSV or flat-file exports, A DMZ or jump host for transfers, VPN or site-to-cloud tunnel, Dedicated on-prem appliance, No infrastructure yet, Other
• Designate the individual or role who will own day-to-day coordination during deployment and confirm whether they have capacity to support scheduled work windows. Options: Process engineer, IT-OT engineer, Project manager, Automation lead, Reliability engineer, Other
• Provide your typical maintenance window length available for initial historian connectivity work. Options: 2 hours or less, 2–4 hours, 4–8 hours, Full shift or overnight, Planned outage only, Not available
• For any contractual or regulatory controls on sharing timestamped process data, which role or committee must approve a temporary exception for the pilot? Options: IT security, Legal or compliance, Operations leadership, Process safety, Data governance, Not applicable/None, Other

Acceptance criteria and next steps

• Assuming the pilot demonstrates the expected improvement, what remaining barrier would keep you from contracting within the quarter?
• Provide the specific acceptance criteria you will use, including thresholds and the data sources you will use to validate them.
• Select the earliest realistic pilot start window after access approvals are in place Options: Within 2 weeks, 2–4 weeks, 4–8 weeks, After the next planned turnaround, Unsure
• State the final commercial signatory and describe any procurement steps we should expect.
• Tell me the top three deliverables you would expect from the seller in the first two weeks to feel confident the pilot is on track. Options: Historian connectivity confirmed and sample extracts, Baseline report identifying initial candidate issues, Dashboard mockups showing target metrics, Named owners and a deployment plan, Security and access documentation, Other

• Solution Experience, Engineer-Led Analytics

• Confirm the current state and its cost
• You confirm the demonstrated diagnosis workflow replaces the manual historian queries and materially shortens time-to-root-cause for the selected upset.
• Deliver a 48-hour insight report using the provided historian extract, showing model outputs, identified root causes, and recommended corrective actions within 5 business days.
• You and the seller agree on a pilot scope, the pilot unit, and 2-3 measurable acceptance criteria for success.
• Run a real upset scenario from your historian end-to-end
• Provide the historian endpoint (read-only) or data extract, the list of candidate tags for the pilot unit, and two upset incident timestamps with associated shift notes.
• Demonstrate monitoring and alerting tied to the scenario
• You commit to providing the historian endpoint and two upset incident timestamps so the seller can run the pilot evidence package.
• Identify the pilot unit and confirm the operational owner and an initial acceptance metric (for example, minutes to detect or kilograms of yield recovered) before the pilot begins.
• Validate the demonstrated outcome
• Agree pilot scope and measurable acceptance criteria

• Solution Experience, Engineer-Led Analytics
• Solution Experience Deck
• Solution Brief, Engineer-Led Analytics

• meeting
• slides
• document

• Connect to source historian
• Map tags and asset context
• Ingest and normalize time-series data
• Deploy pre-built analytics models
• Configure custom process models
• Build real-time monitoring dashboards
• Set up automated alerts and escalations
• Integrate DCS real-time feeds
• Install edge data collector
• Provide model tuning and support
• Enable self-service analytics workspace
• Deliver user training and handover

Connect to source historian

• Provide the network endpoint (hostname or IP) and port for the source historian instance for the target unit
• Specify the authentication method your historian will accept for connector access Options: Service account (username/password), Certificate-based TLS, API token, Windows integrated authentication (Kerberos)
• Select the industrial data protocols exposed by the historian endpoint we should plan to use Options: OPC UA, REST API, ODBC/JDBC, Proprietary historian API, Other
• Identify the archival time range we must access on the historian for the engagement (example: 2018-01-01 to 2026-06-01)
• Provide the typical sample or scan rate for the critical tags you want analyzed (choose the closest) Options: Sub-second (<1s), 1-5 seconds, 5-30 seconds, 30 seconds to 1 minute, >1 minute
• What acceptance evidence will validate a successful historian connection for the selected unit (examples: authenticated session log, sustained tag read rate of N tags/min, retrieval of a 7-day timeseries sample)
• Name the network and OT owners we must coordinate with for firewall rules and VLAN access to the historian endpoint (include contact role and email)

Map tags and asset context

• List the primary assets/units (by unit name or tag prefix) to include in the asset hierarchy mapping
• Which tag naming convention or tag prefix patterns does your historian use for the selected units (examples: UNIT1:TAG, PUMP_01_FLOW)?
• Specify the canonical equipment identifiers or asset codes from your CMMS or EAM that must map to historian tags
• Identify any existing asset hierarchy documents (P&IDs, single-line diagrams, or asset CSV) you will provide for contextualization Options: Piping and Instrumentation Diagram (P&ID), Asset CSV export, Single-line electrical diagram (SLD), No documents available
• Which control loops or PID controllers should be flagged in the context model for monitoring (provide loop IDs or tag prefixes)
• Name the domain owner who will approve tag-to-asset mappings and final asset hierarchy (role and contact)
• List any tags that must be excluded from mapping due to sensitive data or licensing constraints (examples: operator logon events, security system tags)

Ingest and normalize time-series data

• Specify the historical completeness target for ingested data (percentage of non-missing samples in the requested range) we must meet for acceptance Options: >99%, 95-99%, 90-95%, <90%
• Indicate the timezone and timestamp standard used in your historian (examples: UTC, local plant time, timezone-aware timestamps) Options: UTC, Local plant time, Timezone-aware timestamps, Mixed/unsure
• Identify the method we should use for handling gaps and irregular sample intervals in your tags (options include forward-fill, interpolation, flag-as-missing) Options: Forward-fill (last value carried), Linear interpolation, Mark as missing and skip, Custom rule — describe in free text
• Provide typical ranges and engineering units for 5-10 representative tags we will use to validate normalization (examples: flow m3/h, temp degC, level %)
• State the expected cardinality of tag-series to ingest for the initial scope (estimate number of tags and approximate daily data volume) Options: <500 tags, 500-2,000 tags, 2,000-10,000 tags, >10,000 tags
• Which data quality KPIs should we report after ingestion (examples: percent completeness, timestamp drift, duplicate timestamps)? Options: Percent completeness, Timestamp alignment drift (seconds), Duplicate timestamp count, Outlier rate (per tag), Custom KPI
• How will you verify the normalized timeseries against your operational records (examples: compare to shift logs, compare to PLC historian snapshots)

Deploy pre-built analytics models

• Select which pre-built model families you want included in the initial deployment for the specified unit Options: Anomaly detection (pattern-based), Energy-performance baseline, Yield-loss root-cause patterns, Control-loop performance metrics, Custom unit-specific pattern
• Provide 3 example historical process-upset events (by timestamp and tag set) we should use to validate each pre-built model
• Identify the minimum acceptable model performance threshold for deployment validation (examples: true positive rate, precision) for each model family Options: Precision >=80%, Recall >=80%, F1 >=75%, Custom metric — describe
• Which process KPIs should a model map to as expected outcomes (examples: reduced cycle time, increased yield %, energy kWh/ton)
• What acceptance criteria will confirm each deployed pre-built model is operational against your historian (examples: reproducible alert on a known upset, documented model score time series)
• Who on your operations or process team will be the model validation owner to approve go-live of each analytics model (role and contact)
• List any regulatory or process constraints that limit automated model actions (examples: cannot auto-change setpoints, alerts must flow to duty operator only)

Configure custom process models

• Describe the custom process behavior or KPI you want modeled (examples: unmeasured catalyst deactivation, intermittent fouling on heat exchanger HX-02)
• Provide representative training windows (dates and upset examples) we should use to build the custom model
• Which input signals (by tag names) must be included in the custom model feature set for the specified unit
• Specify any control actions, setpoints, or manual interventions that should be treated as exogenous inputs during model training
• Identify the required model update cadence after deployment (examples: weekly retrain, monthly recalibration, on-demand after major maintenance) Options: Weekly, Biweekly, Monthly, On-demand after event
• Who will own acceptance of custom model outputs (role that signs off model performance on the unit)
• List any operational thresholds or alarm limits from your unit procedures that the custom model must respect or reference

Build real-time monitoring dashboards

• Select dashboard audiences you require for the initial release Options: Process engineers, Operations supervisors, Reliability team, Shift operators, Management
• Provide 5 core metrics or KPIs (by tag or calculation) to appear on the unit overview dashboard (examples: unit throughput t/h, energy kWh/ton, cumulative yield %)
• Specify the update cadence desired for the dashboard widgets (examples: streaming, 30s, 1min, 5min) Options: Streaming/near-real-time, 30 seconds, 1 minute, 5 minutes
• Identify any role-based visibility rules for dashboard panels (examples: hide raw sensor readings from operators)
• Which contextual artifacts should be linked from dashboard panels (examples: P&ID link, shift log entry, recent maintenance work order ID) Options: P&ID link, Shift log entry, Maintenance work order ID, No links required
• State the acceptance check to confirm a dashboard is ready for handover (examples: load time under X seconds, correct KPI calculation validated against historic report)

Set up automated alerts and escalations

• Which alert channels do you use for operations notifications that we should integrate with Options: Email distribution list, SMS gateway, Operator console/SCADA alarm, Incident management tool
• Provide the alert severity tiers and example escalation paths for the unit (examples: Info -> operations tech; Critical -> operations supervisor + on-call engineer)
• Identify the alert thresholds or model scores that should trigger an automated notification for the selected KPI or tag
• Specify any suppression windows or maintenance windows when automated alerts must be muted for the unit (provide local times and recurrence)
• Name the on-call roster or duty rotation we should use for escalations (include role and contact method)
• Select whether alerts should create a ticket in your work-order system automatically and which fields must be populated Options: Create ticket with minimal fields, Create ticket with full contextual payload (tags, recent trends), Do not auto-create tickets
• List any regulatory or safety constraints that restrict automated escalations for the unit (examples: must notify shift supervisor before external emails)

Integrate DCS real-time feeds

• Specify the DCS interfaces available for streaming (examples: OPC UA server endpoint, PLC tag gateway, historized DCS API)
• Provide the list of control-system tag prefixes or ranges we must subscribe to for real-time monitoring (examples: LOOP_*, PLC1:TAG123)
• Which latency SLA do you require for DCS-to-platform real-time feeds on the unit Options: <1 second, <5 seconds, <30 seconds, <5 minutes
• Identify any control-layer tags that must never be transmitted out of the OT network for compliance reasons (examples: safety interlock tags)
• Who is the DCS administrator we will coordinate with for subscription and certificate exchange (role and contact)
• List the authentication and encryption requirements for DCS feed integration (examples: mutual TLS, VPN, jump host) Options: Mutual TLS, VPN tunnel, Jump host with firewall rules, No special encryption beyond TLS

Install edge data collector

• Indicate whether an on-premise edge collector is required for this unit due to network segmentation Options: Required, Not required, Undecided — need assessment
• Provide the preferred physical location and hostname for the edge collector (examples: control room server rack, skid PLC cabinet)
• Specify required connectivity from the edge device to the historian and to the platform (examples: direct LAN to historian, outbound only to cloud on port 443)
• Select the edge hardware constraints we must respect (examples: CPU cores, RAM, storage retention for N days) Options: Low-spec (2 cores, 4GB RAM), Standard (4 cores, 8GB RAM), High-spec (8+ cores, 32GB+ RAM), Custom — describe
• Identify procedures for physical installation and safety around the edge device (examples: lockout/tagout (LOTO) requirement, hazardous area rating)
• Name the OT security checklist items we must validate on the edge collector before go-live (examples: disk encryption, hardened OS image, approved firewall rules)

• Subscription Order Form
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Data Processing Addendum (DPA)
• Security and Network Access Authorization
• Mutual Commitments & Readiness Checklist

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate and Incumbent Wind-down (around day 90)
• Quarterly Success Review

• Schedule the next model retraining or parameter review and publish the objectives for that work.
• Create a remediation plan with deadlines for the top 3 blockers and circulate to stakeholders.
• Present initial outcomes against targets
• Determine whether monthly process upset rate and percent yield loss are trending toward Solution Scope targets and document variance explanations.
• Agree a prioritized corrective action list with deadlines to address any gaps before the acceptance gate.
• Deliver a measurement packet that maps each acceptance criterion to the supporting data and variance analysis.
• Open prioritized tickets for model tuning or data fixes with target completion dates aligned to the acceptance gate.
• Restate acceptance criteria and targets
• Produce a documented pass/fail result for each acceptance criterion recorded in Solution Scope and capture the named signatory for formal acceptance.
• Agree remediation actions and timelines for any failed or conditional criteria and confirm the incumbent wind-down approach.
• Publish the acceptance decision document with pass/fail status for each criterion and the named signatory.
• Produce and circulate the incumbent wind-down checklist showing data migration, archiving, contract/renewal disposition, and evidence that fallback habits are closed.
• Performance metrics review
• Validate whether monthly process upset rate and model alert precision are within acceptable ranges relative to Solution Scope targets or require further action.
• Maintain a prioritized backlog with clear target dates for model tuning, data fixes, and usability improvements.
• Update the shared backlog with the agreed top 3 priorities and expected completion windows.
• Re-confirm acceptance criteria and owners
• Confirm all deployment checklist items are complete or have a documented fix plan with dates.
• Identify and document the top 3 go-live blockers with resolution dates for the next 30 days.
• Publish a go-live validation report summarizing connectivity, model status, and any open defects.
• Deployment validation
• Present outcome data against each criterion
• Root-cause diagnosis for any gaps
• Support ticket and backlog burn-down
• Planned model lifecycle and tuning schedule
• Document pass/fail and formal acceptance decision
• Model tuning and support requests
• Early adoption and usage signals
• Open issues and blockers
• Adoption and training health
• Backlog and corrective action plan
• Remediation plan for failed criteria
• Immediate remediation and next steps
• Agree next quarter priorities
• Confirm timeline to acceptance gate
• Incumbent system wind-down check