Quick hello — where should we focus first?

• Who’s in the room for this initiative (name + role)?
• Which site, unit, or process area would you like us to prioritize?
• What is the primary objective you’d like analytics to deliver here? Options: Reduce unplanned downtime, Recover lost yield, Reduce energy consumption, Improve product quality, Shorten troubleshooting time, Demonstrate regulatory / safety adherence, Other
• How soon do you need to see a first actionable insight? Options: Within 2 weeks, Within 1 month, 1–3 months, 3–6 months, No firm deadline
• Who will be the day-to-day owner for analytics in your team? Options: Process Engineer, Reliability Engineer, Operations Manager, IT-OT Lead, Data Engineer/Scientist, Other

Are we settling for 'good enough' because change is hard?

• How often does a recurring upset, yield loss, or unexplained shift show up in your unit? Options: Weekly or more, Monthly, Quarterly, A few times a year, Rarely
• When one of those events happens, what’s the usual impact—cost, safety, throughput, or something else? Options: Yield loss, Production downtime, Safety/Risk event, Quality out-of-spec, Increased energy use, Regulatory/Environmental impact, Other
• Walk me through the last time an upset cost you meaningful production—what happened and how long did recovery take?
• What repeatable troubleshooting steps does your team take today (e.g., spreadsheet pulls, ad-hoc PI queries, whiteboard sessions)? Options: Ad-hoc historian queries, Manual spreadsheet analysis, Operator tribal knowledge, External consultant root-cause, DCS alarms only, No formal process
• How does it feel for the people who own reliability or operations when these events happen—frustrated, resigned, pressured, or energized to fix it? Options: Frustrated, Resigned/accepting, Under political pressure, Motivated to fix, Unsure

Why does the historian feel like a locked treasure chest?

• Which historian(s) and retention patterns do you have today? Options: OSIsoft PI (long retention), OSIsoft PI (short retention), Honeywell PHD, Other historian, Flat files / CSV archive, No centralized historian
• Are the specific tags/signals you need already being collected at a usable sample rate? Options: Yes, everything we need, Most signals but gaps exist, Significant gaps in tags or rates, We don’t know—need help to assess
• Who currently has access to run historian queries and pull samples (roles, tools used)? Options: Operators, Process engineers, Reliability engineers, Control systems/automation team, IT/Historian admins, External consultants
• What are the biggest data quality pain points you see (missing data, clock skew, changing tag names, compression)? Options: Missing data gaps, Inconsistent tag naming, Timestamp/clock issues, Compression/aggregation artifacts, No data contextualization, Other
• If we asked you to provide a 24–72 hour historian extract to reproduce an upset, how comfortable are you doing that today? Options: I can provide it today, I can get it with help from IT, It will take time/approval, Not possible without external support

Who’s driving this—and who will stop it?

• Who is the executive sponsor for this effort and what outcome will they use to judge it a success?
• Who must sign off on historian access, OT network connectivity, and cyber controls for a pilot? Options: IT/OT Security, Site Operations, Control Systems/Automation, Plant Management, Corporate IT, Other
• What are the non-negotiable cybersecurity or compliance requirements we must meet (network segmentation, jump-box, data diode, logging)? Options: Network segmentation, Read-only historian access, Data diode/one-way transfer, SIEM integration, Periodic pentest, Other
• How is budget approval typically handled for analytics pilots—central capital, site OPEX, or reallocated project funds? Options: Site OPEX, Site capital, Corporate/central approval, Reallocated project funds, Not yet budgeted
• Which internal metrics or KPIs will the decision-makers ask to see during pilot review? Options: Minutes to detect an upset, Repeat upset frequency, Yield delta, Energy per ton, MTBF/MTTR, Cost savings estimate, Other

If we could recreate the last upset right now, what would we learn?

• Describe a specific upset or yield event you want us to reproduce and examine during a pilot (date/time, unit, symptoms).
• Which variables or subsystems do you suspect were involved?
• What artifacts exist for that event (historian extract, shift log, DCS alarms, lab results, operator notes)? Options: Historian extract, Shift log/operator notes, DCS alarm logs, Lab/QA results, Inspection/maintenance reports, No artifacts available
• How would you validate that a model or alert was correct for that event—what evidence would convince you? Options: Matches known root cause, Leads to actionable operator steps, Reduces recurrence in follow-up period, Quantifiable cost avoidance, Peer review by engineers
• What is an acceptable false-alert rate or sensitivity trade-off for you during an initial pilot? Options: Very low false alerts (conservative), Balanced precision/recall, Favor sensitivity (catch everything)

What would a true 'first actionable insight' actually look like to your team?

• Which of these outcomes would make you call the pilot a success on day 1–90? Options: Clear root-cause candidate for a recurring upset, Dashboard that reduces time-to-investigation, Automated alert that leads to corrective action, Model that predicts an upset before impact, Improved data accessibility for engineers
• Who receives and acts on an alert today—and what exact action would you expect from them when the platform alerts? Options: Operator adjusts setpoint, Process engineer opens RCA, Reliability schedules inspection, Control systems team implements interlock, Shift manager escalates
• Which systems must be integrated for an alert to be actionable (DCS, MES, maintenance system, operator displays)? Options: DCS/HMI, MES, CMMS/maintenance system, Operator dashboards, Historian only (email/report), Other
• How would you like model tuning and support to be handled post-deployment? Options: Vendor performs tuning with SLA, Joint vendor+site team, Site-owned tuning after handover, Combination depending on complexity
• What acceptance criteria would you require for moving from pilot to production? Options: Reduction in incident frequency, Confirmed root-cause for target upset, Operator adoption rates, SLA for alerts and tuning, Security/compliance sign-off

Let’s map the next 90 days together — what’s realistic?

• What internal blockers could delay a pilot (procurement, cyber approvals, resource availability)? Options: Procurement lead time, Cyber/security approvals, Historian admin availability, Shift coverage for testing, Budget approval, Other
• Which pilot scope feels most valuable and doable: single upset replay, rolling 30‑day monitoring, or a proof-of-value dashboard? Options: Single upset replay, 30-day rolling monitoring, Proof-of-value dashboard, Small-scale production monitoring
• Which stakeholders should be present for a 90-day steering review (names/roles)?
• How will we measure ROI for the pilot—what financial or operational metrics must move? Options: $/hour reduced downtime, Yield percentage improvement, Energy reduction, Labor hours saved, Reduction in off-spec product
• Are you comfortable granting read-only historian access and a small, controlled OT path for a limited pilot if we meet your cyber controls? Options: Yes, Yes with conditions, Need more discussion, No
• If we could propose next steps after this discovery, what decision timeline would work for you? Options: Immediately, Within 1–2 weeks, Within a month, Longer / unsure

• Solution Experience - Pre‑Work Alignment Workshop
• Solution Experience - Data Validation & Connectivity Check
• Solution Experience - Live Upset Walkthrough (Diagnosis → Proof → Validation)
• Solution Experience - Outcome Validation & Business Case Review
• Solution Experience - Retrospective & Model Tuning Plan

• Seller to produce concise one‑page 'What We Proved' summary tying findings to KPIs for executive sign‑off.
• One‑sentence Reminders
• Produce reproducible evidence that platform detects the upset in the customer's own data.
• Show quantified connection between detected root causes and the documented consequence.
• Obtain explicit customer confirmation (or corrected understanding) that the outputs reflect operational reality.
• Define acceptance tests and additional data needed for full confidence.
• Seller to share exported result dashboards and underlying analysis notebook/configuration for transparency.
• Customer to annotate any mismatches and provide additional contextual events (shift logs, maintenance actions).
• Seller to schedule a short iteration run to incorporate SME feedback and re‑execute acceptance checks.
• Recap Evidence & Accepted Findings
• Demonstrate the business impact of validated findings in monetized or KPI terms.
• Confirm acceptance criteria are met or document gaps to close before go/no‑go.
• Obtain stakeholder agreement to proceed to Solution Scope or identify required additional work.
• Document residual risks and mitigation plan tied to deployment commitments.
• Introductions & Objectives
• Customer to provide formal acceptance or list of gaps required for sign‑off within agreed SLA window.
• Jointly schedule the Solution Scope kickoff with owners and target dates for first actionable insight.
• Review Validation Feedback Loop
• Produce a concrete tuning plan with discrete tasks, owners, and SLAs.
• Establish monitoring/detection rules for model drift and ongoing accuracy checks.
• Agree on a realistic timeline and definition for first actionable production alert.
• Confirm communication cadence and escalation procedures for the deployment phase.
• Seller to create a detailed tuning ticket backlog with estimated effort and delivery dates.
• Customer process engineer to validate and prioritize the tuning backlog items.
• Both parties to agree on a monitoring dashboard and alerting thresholds to be deployed in production.
• Schedule a weekly checkpoint during tuning phase until first actionable alert is confirmed.
• Obtain a single, unambiguous one‑sentence description of the current state upset.
• Agree and document the explicit consequence metric(s) to be used during validation.
• Define a concise future state outcome to be proven in the experience.
• Collect and schedule delivery of required historian samples and contextual metadata.
• Assign clear owners for data delivery, SME participation, and platform access.
• Customer to export agreed historian tag sets and time ranges and upload to shared folder by agreed date.
• Customer to provide a short write‑up quantifying estimated cost/impact of the upset (hours, yield loss, $$$).
• Seller to confirm platform account, access method, and any connectivity constraints to IT‑OT lead.
• Schedule Data Validation & Connectivity Check meeting with named participants.
• Recap Pre‑Work Deliverables
• Verify platform can ingest and interpret submitted historian samples with acceptable data quality.
• Ensure tag/context mapping aligns to process semantics and the upset definition.
• Obtain IT‑OT sign‑off on connectivity approach and any temporary security exceptions required.
• Agree exact time windows and model templates for the live demonstration run.
• Seller to run automated data‑quality report and share issues found with customer SMEs.
• Customer IT‑OT to provide required read‑only credentials or confirm secure data‑transfer method.
• Customer process SME to annotate key events in supplied time windows (valve changes, manual interventions).
• Seller to stage pre‑built model templates configured to the customer's tag mapping for the live run.
• Sample Import & Quick QC
• Define Tuning & Testing Steps
• Map Findings to KPIs
• Run: Detect & Recreate Upset
• State Statement (Current)
• Run: Root Cause Correlation
• Context & Tag Mapping Review
• Acceptance Criteria Checklist
• Consequence Quantification
• Assign SLAs & Owners
• Monitoring & Drift Detection Plan
• Risk & Uncertainty Discussion
• Security & Connectivity Walkthrough
• Define Future State (Outcome)
• Tie Outputs to Consequence
• Customer Validation & Challenge

• Historian Connector and Tag Ingestion
• Tag Contextualization and Asset Hierarchy Mapping
• Time-Series Cleaning and Alignment
• Deploy Self-Service Trend Explorer
• Deploy Prebuilt Process Analytics Models
• Real‑Time Anomaly Detection and Alerts
• Automated Multivariate Root-Cause Workbooks
• KPI and Operator Dashboard Deployment
• Energy and Yield Optimization Analytics
• DCS/SCADA Integration and Data Writeback
• Continuous Model Retraining and Drift Monitoring
• Engineer Hands‑on Analytics Training

Historian Connector and Tag Ingestion

• Which historian(s) are present at the site? Options: OSIsoft PI, Honeywell PHD, Other (specify), None
• Approximately how many tags/tagsets do you expect to ingest initially? Options: Less than 1,000, 1,000-10,000, 10,000-100,000, More than 100,000, Unknown
• What ingestion frequency is required for operational value? Options: Sub-second/streaming, 1-60 seconds, 1-5 minutes, 5-15 minutes, Hourly/batch
• Are there existing tag naming standards or AF/asset frameworks we can leverage? Options: Full AF/standardized naming available, Partial mappings (spreadsheets), No organized mapping, Unknown
• Who will own connector installation and access (network/firewall configuration)? Options: Customer IT/OT, Vendor/implementation team, Joint, Other (please specify)
• Are any tags considered sensitive or restricted (safety, security, or PII)? Options: Yes - restricted, Yes - limited, No, Unknown

Tag Contextualization and Asset Hierarchy Mapping

• Do you have an existing asset hierarchy or tag-to-equipment mapping file? Options: OSIsoft AF/Asset Framework, Excel/CSV mappings, CMMS/Asset DB, No mapping available
• Which asset modeling standard should we follow? Options: ISA-95, Company-specific standard, ISO/other, No standard / define new
• What depth of contextualization is required for initial scope? Options: Tag-level metadata only, Tag → Equipment → Unit mapping, Full equipment model with P&ID crosswalks, Other (describe)
• How many distinct units/areas should be modeled in the first phase? Options: 1 unit/area, 2-3 units/areas, 4-10, More than 10, Unknown
• Will subject-matter experts be available to validate mappings in workshops? Options: Yes - dedicated SME(s), Yes - part-time availability, No SME available, Unsure
• What is the acceptance criteria for correct contextualization (e.g., SME sign-off, % mapped)? Options: SME sign-off per unit, Critical tags 100% mapped, Automated validation pass (rules), Other - describe

Time-Series Cleaning and Alignment

• Should historic data be cleaned (missing values, spikes) as part of the scope? Options: Yes - full cleaning, Yes - limited to critical tags, No - flag only, Unsure
• Which handling methods do you prefer for missing or irregular samples? Options: Linear interpolation, Forward-fill/last known, Model-based imputation, Flag-only (no imputation)
• What target alignment/resampling frequency is required for modeling and dashboards? Options: Use native timestamps, 1 second, 10 seconds, 1 minute, 5-15 minutes, Hourly
• Should outliers and erroneous spikes be removed, clipped, or flagged? Options: Remove/clean automatically, Clip to thresholds, Flag for SME review, Leave as-is
• Estimate the historical data volume to process (for cleaning) in GB or time range. Options: Last 30 days, Last 90 days, Last 12 months, All available history, Specify exact GB in free text
• What validation/acceptance is required after cleaning is applied? Options: Automated QA checks (rules), SME spot-check sign-off, Backtest against known events, Other (describe)

Deploy Self-Service Trend Explorer

• Which user personas should have access to the trend explorer? Options: Process Engineers, Operations/Shift Engineers, Reliability Engineers, IT/OT, Management
• Which core features are must-haves for engineers? Options: Multi-tag overlay, Annotations/time-stamped notes, Compare runs/periods, Custom formulas/derived tags, Export to CSV/Excel
• What access control model is needed (role, site, tag-level)? Options: Role-based access, Tag-level restrictions, Site/plant-level separation, Open to all authenticated users
• Do you require single sign-on (SSO) or specific authentication (SAML/OAuth)? Options: SAML/SSO, OAuth, Local accounts only, Unsure / discuss
• Do you want the explorer available on mobile or HMI screens as well as desktop? Options: Desktop/web only, Desktop + mobile, Embed in HMI/OPS screens, All of the above
• What level of vendor-led training or enablement is required for self-service adoption? Options: Basic walkthrough (1 session), Hands-on workshops (engineer-focused), Admin/owner training, No training required

Deploy Prebuilt Process Analytics Models

• Which prebuilt model families are relevant to your processes? Options: Root-cause / upset analysis, Throughput / yield models, Fouling/efficiency models, Energy per unit models, Other (specify)
• How many models do you want deployed in the initial wave? Options: 1-3, 4-10, 11-25, More than 25, Unsure
• What data sources should models consume beyond historian (lab, CMMS, ERP)? Options: Historian only, Historian + lab results, Historian + CMMS/work orders, Multiple external sources
• Is model explainability/feature attribution required for operator acceptance? Options: Yes - required, Nice to have, No
• What performance acceptance criteria should models meet (example: detection rate, false positive rate)? Options: Specify numeric thresholds (free text), SME qualitative acceptance, Backtest pass on historical events, Other
• Who will own model sign-off and ongoing tuning? Options: Customer SMEs, Vendor implementation team, Joint responsibility, Other (specify)

Real‑Time Anomaly Detection and Alerts

• What maximum alert latency is acceptable? Options: Sub-second, Within 1 minute, 1-5 minutes, More than 5 minutes
• Which delivery channels should alerts use? Options: Email, SMS/pager, SCADA/HMI, PI/AF notifications, Ticketing/CMMS, Third-party (PagerDuty)
• Should alerts be threshold-based, model-based, rule-based, or a combination? Options: Static thresholds, Model-based anomaly detection, Rule-based (logic), Combination
• Who should receive and acknowledge alerts? Options: Control room/operators, Process engineers, Reliability/maintenance, Shift supervisors, Management
• Is integration with existing on-call rotations or SLA processes required? Options: Yes - integrate with on-call, Yes - define new SLAs, No integration required, Unsure
• What escalation workflow or ticketing integration is required when alerts are not acknowledged? Options: Auto-escalate to next role, Create CMMS ticket, Manual escalation, No escalation

Automated Multivariate Root-Cause Workbooks

• Should a workbook be generated automatically for every alert/upset? Options: Yes - automatic generation, Only for severe/priority upsets, Manual trigger only, Hybrid (auto + manual)
• What should trigger workbook creation (alert, threshold breach, scheduled analysis)? Options: Alert-triggered, Threshold breach, Scheduled (daily/weekly), Manual by engineer
• Should workbooks include ranked root-cause candidates and suggested corrective actions? Options: Yes - include ranked causes + actions, Include causes only, Include actions only, No suggestions
• Do you want integration of shift logs/operator notes into workbooks for context? Options: Yes - integrate logs, No - separate, Unsure
• How many upset types or scenarios should be supported initially? Options: 1-3 priority upsets, 4-10, More than 10, Unknown
• What acceptance criteria will determine workbook usefulness (time-to-first-insight, SME validation)? Options: SME validation required, Time-to-insight target (specify), Reduction in troubleshooting time, Other (describe)

KPI and Operator Dashboard Deployment

• Which KPIs must be included in the initial dashboards? Options: Yield, Throughput, Energy per unit, Downtime, MTBF/MTTR, Custom KPI (specify)
• How many dashboards and distinct user views are required in phase 1? Options: 1-5 dashboards, 6-20 dashboards, 21-50, More than 50
• Do dashboards require role-specific views (operators vs engineers vs managers)? Options: Yes - role-specific, No - one view fits all, Some role-specific, some shared
• What dashboard refresh cadence is required for operational decisions? Options: Real-time/streaming, 1 minute, 5 minutes, 15 minutes, Hourly
• Should dashboards be exportable, printable, or embeddable in other systems? Options: Export to PDF/CSV, Embed in intranet/HMI, Print-ready, No special export
• Who will sign off on dashboard acceptance (role or person)? Options: Process Engineer, Operations Manager, Reliability Lead, IT/OT Lead, Other (specify)

Energy and Yield Optimization Analytics

• What is the primary optimization objective? Options: Energy reduction, Yield improvement, Both energy and yield, Cost reduction, Other (specify)
• What baseline period should we use to calculate improvements and ROI? Options: Last 30 days, Last 90 days, Last 12 months, Custom - specify
• Are there operational constraints that must be honored (quality spec, throughput, emissions)? Options: Quality constraints, Throughput constraints, Emission/permit limits, Safety constraints, None
• Do you want prescriptive setpoint recommendations or only diagnostic insights? Options: Prescriptive with recommended setpoints, Insights only (no setpoint), Hybrid - suggest then human approve
• Is automatic DCS writeback for setpoints allowed or will it be suggestion-only? Options: Automated writeback allowed, Suggestion-only (manual apply), Restricted writeback with approvals, No writeback allowed
• What ROI acceptance metrics would validate success (e.g., % yield, kWh reduction, $/month)? Options: Specify numeric target (free text), SME qualitative approval, Reduction in variability, Other

DCS/SCADA Integration and Data Writeback

• Which DCS/SCADA vendors and controller types are in scope? Options: Honeywell, Emerson, ABB, Siemens, Rockwell/Allen-Bradley, Other (specify)
• Is writeback to DCS allowed and under what control model? Options: Full automated writeback, Writeback with manual approval, Suggestion-only (no writeback), No writeback allowed
• Which communication protocols must be supported for integration? Options: OPC-UA, OPC-DA, Modbus, Vendor API, Custom/Proprietary
• What cybersecurity/networking constraints must we follow (DMZ, jumpbox, no direct access)? Options: Use DMZ with controlled gateways, Allow direct OT access, Only read-only historian access, Customer-defined standard
• Who is the approver for any changes that affect DCS configuration or setpoints? Options: Control Room/Operator, Automation Engineer, Operations Manager, Joint approval
• Is a formal test and rollback plan required prior to any writeback or control changes? Options: Yes - required, No - not required, Depends on change type

• Non-Disclosure Agreement (NDA)
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Order Form / Commercial Terms
• Pricing & Payment Schedule
• Support & Model‑Tuning SLA
• Cybersecurity & OT Access Addendum
• Data Processing & IP License Agreement
• Acceptance Criteria & Milestone Sign‑off
• Implementation Timeline & Go/No‑Go Criteria
• Training & Engineer Enablement Commitment
• Change Order Agreement
• Termination, Exit & Data Return Plan
• Renewal & Expansion Options

• KPI Validation Review
• Lessons Learned & Continuous Improvement Workshop
• Model Health & Drift Review
• Issue Triage & Enhancement Prioritization
• Success Governance & Shared Channel Kickoff

• Ensure customer stakeholders understand trade-offs and upcoming delivery commitments.
• Schedule a follow-up validation meeting to re-check remediated KPIs.
• Timeline Recap
• Document a concise lessons-learned register covering people, process, and technology.
• Agree on 3–5 high-impact improvements with owners and timelines.
• Update runbooks, escalation paths, and training plans based on workshop outcomes.
• Produce a Lessons Learned document and circulate to stakeholders for acknowledgment.
• Update operational runbooks and model tuning playbooks with agreed changes.
• Schedule targeted enablement sessions for engineers on any newly adopted workflows.
• Review Open Incidents & Status
• Have a prioritized backlog with clear owners and target release windows.
• Agree SLAs and escalation procedures for different issue severities.
• Model Inventory & Versions
• Update the shared backlog with priority, owner, estimated effort, and planned release.
• Open development tickets for high-priority defects and schedule hotfixes as needed.
• Publish the upcoming release plan to stakeholders and the shared channel.
• Governance Roles & Cadence
• Create an agreed governance model with named roles and meeting cadence.
• Operationalize a shared communications channel with clear triage and notification rules.
• Agree reporting cadence and which artifacts will be auto-shared to stakeholders.
• Create the shared channel, invite stakeholders, and post the triage/playbook pinned message.
• Publish the governance RACI and meeting schedule to the channel and stakeholder list.
• Configure automated dashboard reports to post to the shared channel on the agreed cadence.
• Establish current model health status and agree concrete drift thresholds.
• Agree a retraining cadence, triggers, and acceptance criteria for model updates.
• Assign model owners and SLAs for detection-to-resolution of model degradation.
• Set up automated model-health dashboards and drift alerts routed to the shared channel.
• Create a retraining ticket with defined data window, validation tests, and owner.
• Document the rollback plan and test it in a dry-run environment.
• Welcome & Objectives
• Confirm which KPIs have been met and capture sign-off or formal exceptions.
• Produce a prioritized list of KPI gaps with proposed remediation actions and owners.
• Agree timeline and criteria for revalidation of any unmet KPIs.
• Publish a KPI Validation Report with evidence snapshots and sign-off fields for each KPI.
• Create remediation tasks for unmet KPIs with owners and target dates.
• Shared Channel Setup & Rules
• Prioritization Framework Recap
• Recap of Agreed KPIs & Baseline
• Performance Metrics & Trend Analysis
• What Worked Well
• Backlog Review: Enhancements & Defects
• Drift Indicators & Case Studies
• What Didn’t Work & Root Cause Analysis
• Delivered Outcomes & Evidence
• Reporting & Dashboard Distribution
• Retraining / Tuning Plan
• Improvement Ideas & Prioritization
• Decide Next Releases & SLAs
• Change Control & Release Process
• Gap Analysis by KPI
• Ownership & Implementation Plan
• Monitoring & Alerting Configuration
• Customer Validation & Acceptance
• Communication & Escalation Paths
• Close & Schedule Cadence
• Decide Next Steps
• SLA for Model Tuning & Ownership