Industrial & Manufacturing
›
Energy, Utilities & Sustainability
›
Grid Modernization & Distributed Energy
Grid Management Software
Long-cycle programs where regulation, capital, and grid reliability define the pace.
Example organizations in this space:
OSIsoft (AVEVA)
GE Vernova
Oracle Utilities
Itron
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify and diagnose before investing in a full evaluation cycle.
-
Qualification
Confirm budget window, decision roles, procurement constraints, and timeline before investing in full diagnostic work.
Qualification Questions
Procurement constraints and compliance
- So we make the best use of your time: are there procurement rules or contracting constraints we should know about (for example, an RFP, sole-source restrictions, or state procurement law)?
- Will this project need to meet NERC CIP, NIST, or other regulatory cybersecurity standards?
Decision roles and authority
- Who is the ultimate decision maker for a purchase like this? (role or title)
- Which teams will materially influence the decision?
Budget
- Is there an allocated budget range or approval threshold for this initiative?
- What is the likely funding route if budget is not yet defined?
Timeline and critical dates
- What is your target decision window or go-live timeframe?
- Are there external deadlines driving the timing (regulatory compliance date, grant expiration, asset replacement window) we should coordinate with?
-
Operational Discovery
Map current grid operations, DER patterns, integration points, cybersecurity posture, and measurable reliability and regulatory goals.
Discovery Questions
Starting Short: Your operational snapshot
- Tell me about your current control-region footprint, including number of substations, feeders, and sites with active DER controls.
- Provide the typical number of DER endpoints reporting telemetry to your operations center on a busy day.
- Select the DER asset types that create the most operational variability for you.
- Name the team that monitors real-time DER behavior and who your team notifies first when an anomaly appears.
- Describe telemetry latency, typical polling frequencies, and any buffering or gateway behavior you see from relays, RTUs, and inverter gateways.
- Give the SCADA or EMS functions you consider untouchable during integration, the reasons they are protected, and the stakeholder who insists on that protection.
Where operations break most often
- If a morning DER upset could cascade into a feeder outage, which event is most likely to start that cascade?
- Walk me through the last time automated switching or FLISR behaved incorrectly, what sequence of events unfolded, and who had to intervene.
- Estimate how often protection mis-operations occur during your highest-DER-penetration hours.
- When unexpected DER behavior appears, how long does it typically take your team to identify root cause and clear the issue?
- What single operational failure would make you halt a new control deployment immediately?
- List recurring manual workarounds operators use during DER events and indicate how they increase staffing or risk.
The hidden costs you are carrying
- How much additional O&M, outage minutes, or dispatch labor do you attribute to DER-related variability each month?
- Estimate the financial impact of a single protective-device mis-operation in terms of lost load, penalty risk, or emergency dispatch costs.
- Tell me about any regulatory penalties, compliance reporting hits, or formal inquiries tied to DER-influenced reliability events in the last 24 months.
- Where do DER-related fixes currently land in your budget structure, operations O&M, capital projects, or emergency funds?
- If you could measure avoided cost from improved DER coordination, which approval authority would unlock funding for a pilot?
- Do you have a procurement or finance payback window required to justify this type of investment?
Integration reality, the systems you cannot replace
- Who owns your integration contracts and which incumbent systems would block any change to how operations runs?
- List the field protocols and telemetry formats you must support, for example DNP3, IEC 61850 GOOSE, Modbus, MQTT, or REST APIs.
- Provide the SLA, throughput, and uptime expectations you require for any new integration endpoints.
- Walk me through your typical integration handoff, from ticket to active endpoint, who signs off, and which steps most often cause delay.
- Can your team provision a one-off substation gateway and grant field access within a 12-week pilot window?
- What single integration dependency would force you to pause the project if it could not be met?
Cybersecurity, controls, and the things you cannot ignore
- Imagine an attacker gained write access to field gateways during a DER event, what immediate operational consequence would you expect?
- Identify the teams accountable for NERC CIP, OT cybersecurity, and who is the final decision maker for remediation actions.
- How often do you run incident response drills that include a simulated field-device compromise and manual control takeover?
- Do you require vendor evidence such as penetration test reports, SOC 2 Type II, or NERC alignment documentation before connecting OT components?
- Describe the control-plane fail-safe that would make your team comfortable allowing automated switching under DER stress conditions.
- Would the compliance team's inability to accept a vendor data handling policy stop the project?
Regulatory and procurement gates that set your timeline
- To what degree is your procurement calendar tied to regulatory funding windows or rate-case cycles?
- Who in procurement or finance must approve a vendor relationship to meet those windows and what objections do they raise?
- When is your next major capital approval or rate case decision that could influence schedule for this work?
- Name procurement requirements that typically add six to twelve weeks to vendor onboarding, for example security questionnaires or insurance limits.
- Which contingency plans shorten implementation risk if regulatory approvals or budget windows slip?
- Would escrowed source code, extended warranties, or phased payments change how quickly you could commit?
The other options you are weighing
- Which alternatives are you evaluating, including the incumbent, an internal build, or other vendors?
- For each alternative, indicate whether it feels like a short-term patch, a long-term replacement, or an active internal project.
- Under which conditions would your organization choose to retain the current system instead of switching to a new platform?
- Has anyone inside proposed delivering a replacement internally, who would lead it, and what timeline did they propose?
- Rate executive stakeholder conviction for moving off the incumbent on a scale from 1 to 5.
- Assuming the pilot proves the numbers you need, what practical barrier remains that would keep you from signing within 30 days?
Concrete readiness, what must be true to proceed
- Assume key telemetry sources are not accessible for two weeks, how will that affect your timeline and go/no-go decision?
- Inventory the third-party systems that must integrate for success, and identify the owner of each API or data feed.
- Identify the person or team who can grant API credentials and field access during integration, and the typical response SLAs they provide.
- Summarize the state of your historical load, DER generation, and outage data, including completeness and accessibility for migration or modeling.
- Detail any regulatory approvals, permits, or external agreements that could gate deployment and the expected lead time for each.
- Should your team lack required headcount or OT expertise, what resourcing options would you consider to bridge the gap?
If this works, who and how will move it forward
- Assuming the pilot proves the acceptance criteria, what would accelerate a signed agreement within 30 days?
- Point to the single decisive blocker that would stop you from moving forward even if technical criteria are met.
- Specify the acceptance metrics you require for operator handoff, SCADA integration, and DER control performance.
- Enumerate the final sign-offs required for budget, operations, and legal approval and the names of the roles who hold them.
- Are you open to a phased commercial structure that ties final payment to live KPI performance during an initial warranty period?
- At what remediation timeline would an unanticipated integration gap become a deal-breaker for you, for example two, six, or twelve weeks?
-
-
Solution Experience
Translate the customer's operational findings into concrete workflows showing how the platform addresses real-time control, DER management, and cybersecurity scenarios.
Solution Experience
- Solution Experience Workshop
- Confirm the current state and what it costs you
- You confirm the demonstrated real-time control workflow eliminates the manual interventions and reduces outage duration you described.
- Provide representative feeder topology, DER telemetry samples, and recent fault logs for the agreed test scenarios.
- Seller to produce a tailored performance validation plan with detailed test scenarios and target KPIs, and deliver it before the Technical Evaluation.
- Scenario A — Real-time control for DER-driven overload
- You confirm the cybersecurity response and audit trail align with your NERC/NIST acceptance expectations.
- Scenario B — Fault isolation and FLISR with DER interaction
- You agree on a prioritized list of remaining evidence and a tailored validation plan to advance to Technical Evaluation.
- Agree on the acceptance KPIs and a target timeline for the integration pilot and Technical Evaluation.
- Scenario C — Cybersecurity integration and response
- Validation checkpoint, confirm this matches your needs
- Evidence and next steps to decision
- Solution Experience Workshop
- Solution Experience Deck
- Solution Brief
- meeting
- slides
- document
-
Solution Scope
Define modules, integration responsibilities, data migration boundaries, operator training, and measurable acceptance criteria.
Scope Configuration
- Integrate SCADA telemetry and control interfaces
- Migrate historical meter and telemetry data
- Deploy real-time energy management engine
- Configure ADMS FLISR and volt‑VAR optimization
- Implement distributed energy resource management controls
- Deploy load and generation forecasting models
- Integrate field devices and RTU/IED communications
- Activate outage management and crew dispatch workflows
- Deploy grid analytics dashboards and KPI reports
- Implement NERC CIP and NIST‑aligned cybersecurity controls
- Provision cloud, on‑premise, or hybrid infrastructure
- Operator training and operator‑in‑the‑loop simulation exercises
- System integration testing and performance stress testing
- Cutover, go‑live execution and rollback support
Scope Questions
Integrate SCADA telemetry and control interfaces
- How many SCADA telemetry points (analog + discrete) must be integrated at go‑live?
- Which SCADA protocols are active at your control center and on field RTUs (select all that apply)?
- List the control points that require write/control authority at go‑live (example: breaker IDs, recloser points, capacitor bank controls).
- Describe the required polling and event reporting rates for analog and discrete points (for example: analog 2s, discrete on-change, alarm on-state).
- Do you require redundant/hot‑standby SCADA links and automatic failover?
- Which mapping artifacts will you provide to map SCADA points to the platform (for example: point list, channel mapping spreadsheet, single‑line diagram)?
Migrate historical meter and telemetry data
- How many days or years of historical meter and telemetry time series must be migrated into the historian?
- Which source exports or historian formats will you provide for migration (select all that apply)?
- What timestamp resolution must be preserved for migrated data used in forecasting and state estimation (for example: 1s, 5min, 15min)?
- What completeness threshold defines a successful migration (for example: 99% of points with no gap larger than 1 hour)?
- Do you require reconciliation and validation reports that compare source counts and values to migrated data?
- Who in your organization will own sign-off of data migration reconciliation (title or team)?
Deploy real-time energy management engine
- Which real‑time control horizons must the engine support (select all that apply)?
- Which state estimation and model artifacts will you provide (for example: updated single‑line diagrams, network impedance matrices, zone boundaries)?
- Which telemetry and control performance metrics should be instrumented for monitoring (for example: control loop latency ms, state estimator residual MW, command delivery success rate)?
- What maximum end‑to‑end latency for a control command (UI → engine → field device) is acceptable for operational use?
- Do you require the engine to integrate with any existing AGC, EMS, or third‑party optimization tools?
- Who will provide the electrical boundary conditions and contingency lists used by the energy management engine (team or document names)?
Configure ADMS FLISR and volt‑VAR optimization
- How many distribution feeders are targeted for FLISR configuration in the initial deployment?
- Which protection device makes/models and relay settings will need to be accommodated when configuring FLISR?
- What volt‑VAR control objectives define acceptable outcomes (for example: maintain service voltage within ±3% of nominal, reduce feeder losses by X%)?
- Do you require IEC 61850 GOOSE or DNP3 control messages to execute sectionalizing and reclosing sequences?
- What customer outage reduction target should the FLISR configuration aim for (for example: percentage reduction in SAIDI)?
- Who will approve protection setting changes and provide change‑management records for the FLISR rollout?
Implement distributed energy resource management controls
- How many DER sites and aggregate capacity (kW/kVAR) must be under active control at go‑live?
- Which DER asset types are in scope (select all that apply)?
- Which inverter or DER communication standards must be supported (select all that apply)?
- What operational DER constraints must be enforced from day one (for example: export limit in kW, ramp rate kW/min, state of charge bounds)?
- Do you require islanding, anti‑islanding, or microgrid transfer tests as part of DER commissioning?
- Who will authorize remote DER setpoint changes and firmware updates during the project?
Deploy load and generation forecasting models
- Which forecasting horizons are required for operations (select all that apply)?
- What accuracy target do you require for day‑ahead load/solar forecasts (for example mean absolute percentage error)?
- Which historical datasets will you supply for model training (for example: AMI 5‑minute data, local weather station CSV, DER output logs)?
- How often should models be retrained and redeployed (for example: daily online retrain, weekly batch retrain)?
- What timestamp resolution should training and evaluation use (for example: 5‑minute aligned to top of hour)?
- Who will own ongoing forecast validation and provide labeled events for model improvements?
Integrate field devices and RTU/IED communications
- How many RTUs and IEDs must be integrated and tested during deployment?
- Which communication media and transport will be used to reach field devices (select all that apply)?
- Which device firmware versions or models require compatibility validation prior to integration?
- Do you require encrypted channels (for example TLS, IPSec VPN) or certificate‑based authentication for RTU/IED links?
- What device channel mapping artifacts will you provide (for example: point list CSV, register map, IEC 61850 SCL file)?
- Who coordinates field access, lockout/tagout (LOTO) windows, and crew schedules for on‑site commissioning?
Activate outage management and crew dispatch workflows
- Which outage detection sources will be used to create tickets (select all that apply)?
- What SLA targets do you require for ticket creation to crew dispatch (for example: dispatch within 15 minutes of confirmed outage)?
- Which crew management or CAD system must be integrated for dispatch and resource tracking?
- Do you require geospatial layers for isolation points, customer mapping, and crew routing in dispatch workflows?
- What cutover approach do you prefer for outage management workflows (for example: parallel run, shadow mode, immediate cutover)?
- Who is the operational owner for dispatch rules, escalation matrices, and post‑incident reviews?
Deploy grid analytics dashboards and KPI reports
- Which KPIs must be visible at go‑live (select all that apply)?
- Which user roles require dashboard access and role‑based views (for example: control‑room operator, planner, executive)?
- What dashboard data latency is acceptable for each role (for example: real‑time, 1x/min, 5‑minute)?
- Do you require scheduled email or PDF reports and defined retention windows for KPI artifacts?
- Are custom drill‑downs, root‑cause analysis workflows, or automated anomaly detection required at launch?
- Provide any existing dashboard mockups or KPI definitions that we should match or replace.
Implement NERC CIP and NIST‑aligned cybersecurity controls
- Which NERC CIP standards apply to your control environment (select all that apply)?
- Which cyber asset boundary and BES (bulk electric system) classification artifacts will you provide (for example: CIP‑002 BCS document, one‑line with critical assets highlighted)?
- Do you require identity provider integration for role‑based access (for example SAML 2.0, LDAP)?
- What logging retention period and SIEM integration are required for compliance evidence (for example: 1 year, 3 years)?
- Which vulnerability management cadence and patch windows are acceptable for control‑plane devices?
- Who is the named CIP/NIST compliance owner that will validate evidence and sign off on controls?
-
Technical Evaluation
Prove system performance, SCADA and field-device integration, and cybersecurity controls against buyer acceptance criteria under realistic load and fault scenarios.
- stakeholders
- current_state
- desired_state
- gaps
- success_criteria
- decision_readiness
- current_state
- decision_readiness
- desired_state
- success_criteria
- gaps
- stakeholders
- current_state
- success_criteria
- stakeholders
- gaps
- desired_state
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
Mutual Commit
Finalize commercial, legal, compliance, and operational commitments including SLAs, NERC/NIST controls, and deployment milestones.
Agreement Modules
- Master Services Agreement (MSA)
- Statement of Work (SOW)
- Subscription Agreement & Order Form
- Service Level Agreement (SLA)
- Data Processing Agreement (DPA)
- NERC CIP and NIST Controls Addendum
- Security & Compliance Attestation
- Deployment Milestone Schedule
- Go‑Live Acceptance Certificate
- Payment Schedule Agreement
- Change Order Agreement
- Termination & Transition Plan
- Source Code Escrow Agreement (optional)
-
Deployment
Operationalize rollout with readiness checks, execution, and go-live validation.
-
Pre-Deployment Readiness
Confirm concrete readiness facts — environments, data availability, access permissions, named owners, and regulatory approvals required before execution.
Pre-Deployment Questions
Environment and site access
- Which environments and sites will be included in the cutover (list each site with environment type: production, pre‑prod, pilot, edge cluster)? (This feeds the deployment runbook.)
- Is secure remote access to each environment available now? (select the best current state — if not 'Yes', we will need a provisioning date)
- If access is not 'Yes', for each environment/site provide the blocking task and the target date when access will be provisioned (so we can schedule remote tasks).
Data and configuration
- Which source systems must be available for initial configuration and testing? Select all that apply so we can inventory integrations.
- For each selected system above, name the source‑of‑truth owner (team/person) and confirm whether a validated sample dataset is available for acceptance testing (Yes / Partial / No). (We use this to build test cases.)
- Is historical operational data required for performance and resilience testing available and validated?
People and ownership
- Provide named owners (name, role, email) for these deployment gates: project sponsor, deployment manager, operations/control room owner, IT/security owner, field engineering owner. (These are the approvers for readiness gates.)
- Is an authorized operational approver identified to perform the formal go/no‑go at cutover?
Timing and constraints
- Identify fixed scheduling constraints that must be honored (select all that apply). If you select 'Other', specify below. (This determines feasible cutover windows.)
- Have the buyer secured all regulatory/compliance approvals required before deployment (examples: NERC/NIST controls, local permits, utility commission approvals)? If not, list pending approvals and estimated approval dates so we can sequence milestones.
- Who will provide and unlock integration access at cutover (select one)? If 'Third‑party vendor' is selected, name them below. (We need the accountable team for cutover handoffs.)
-
Configuration Details
Lock integration credentials, API endpoints, field-device mappings, protection and control thresholds, and cutover window details the deployment team will use.
Configuration Details
Environments & Endpoints
- Production platform instance name (enter the exact instance identifier used in deployment manifests; consumed by deployment manifests)
- Production API endpoint URL (format: https://your-prod-api.example.com — enter exact URL the integration endpoint will call; consumed by connector settings)
- Production deployment region (select the region used for provisioning; default is US-East)
Platform Build & Release
- Platform production version to deploy (enter exact semantic version, default: 1.0.0 — consumed by build pipeline)
Integration Credentials & Exchange (no secrets)
- SCADA connector integration identifier (enter integration username or client ID; do NOT paste secrets — consumed by connector configuration)
- Credential exchange method for SCADA connector (choose how the secret will be provided to the deployment process; the secret itself is provided out-of-band)
- If you selected 'Other' above, describe the credential exchange channel (otherwise enter N/A)
External System Endpoints
- Primary SCADA master endpoint (enter exact hostname or URL the platform will connect to; format: host.example.com or https://host.example.com — consumed by connector settings)
- Time-series historian endpoint type (select the protocol/type the platform will ingest from; consumed by integration adapters)
- Historian connection identifier (enter connection name or client ID used in your historian; do NOT paste secrets — consumed by connector settings)
Field Devices & Tag Mappings
- Primary field-device identifier namespace (enter exact namespace label used by the buyer, e.g., 'DeviceID', 'IED-Serial' — consumed by mapping rules)
- Field-device to platform-tag mapping file location (enter exact path the deployment will fetch, format examples: s3://bucket/path.csv or \\fileserver\share\path.csv — consumed by import job)
Protection Thresholds & Cutover Window
- Default overcurrent pickup threshold (amps) — numeric value to seed protection settings (Default: 100)
- Planned cutover window start (UTC) — enter exact start date/time in ISO format (YYYY-MM-DDTHH:MMZ) the deployment will use for scheduling
-
Deployment
Execute the cutover plan with sequenced tasks, operator training, staged testing, rollback contingencies, and escalation paths.
-
Go-Live Acceptance
Formal go/no-go acceptance: validate operational KPIs, safety and protection checks, cybersecurity hardening, and signed approvals before live operations.
Checklist items
- Receive formal KPI acceptance sign-off
- Deliver protection and safety functional test report
- Provide integration test report for SCADA and field devices
- Obtain operator UAT sign-off document
- Complete cybersecurity hardening checklist and obtain sign-off
- Complete tabletop incident response drill and attach after-action report
- Confirm validated rollback point and tested backup restore
- Receive signed cutover execution plan with approved window and escalation contacts
- Confirm LOTO removal and obtain re-energization authorization
- Obtain required regulatory and compliance approvals
- Obtain signed post-go-live support and SLA acceptance
-
-
Operational Success
Monitor reliability and performance against success criteria, run recurring success reviews with stakeholders, and track issues and enhancement requests.
Success Reviews
- Go-live Health Check (Weeks 1-4)
- First Measurement Review (Weeks 4-10)
- 90-Day Realization Review (Around Day 90)
- Operational Quarterly Review
- Annual Success Review
Issues & Enhancements
- Produce a prioritized backlog snapshot with expected delivery quarter for the top operational items.
- Execute the planned decommission or read-only retention steps for the legacy system and confirm data archival completion.
- Schedule any required follow-up field testing needed to verify remediation effectiveness.
- Trend review for core operational metrics
- Maintain or improve core operational KPIs in line with Solution Scope targets.
- Burn down the top 5 unresolved incidents or agree mitigation steps and dates.
- Keep the enhancement backlog prioritized for operational impact without adding new sales topics.
- Confirm agreed success criteria and named owners
- Implement agreed monitoring threshold changes and update the runbook entries accordingly.
- Provide updated incident resolution summaries for any items remaining open at the next quarterly review.
- Executive summary of year-to-date outcomes
- Confirm whether year-to-date availability and incident counts meet the commitments recorded in Solution Scope.
- Agree a one-year remediation and backlog closure plan for systemic reliability issues.
- Validate that compliance controls are on track and schedule any remediations required for audit readiness.
- Publish the annual reliability and incident report with recommended long-term actions and timelines.
- Create a compliance remediation plan for any NERC/NIST gaps with target completion quarters.
- Confirm the operational review schedule and escalation contacts for the next 12 months.
- Confirm the cutover checklist is complete and no unresolved rollback contingencies remain.
- Establish the remediation plan for any critical defects with target completion dates.
- Verify initial operator access and basic operational flows are functioning.
- Publish a short remediation plan for critical defects with tasks and dates.
- Deliver first-week telemetry extract for integrations and operator activity.
- Schedule targeted re-tests for any failed field-device integration points within 7 days.
- Present first measurement data
- Determine whether control system availability and mean time to restore meet interim thresholds or require remediation.
- Agree a specific corrective action plan with dates that closes top priority KPI gaps.
- Confirm the date for the 90-day realization review to reassess progress against Solution Scope targets.
- Produce a root-cause analysis document for any KPI shortfalls with proposed fixes and dates.
- Schedule integration re-tests and field-device validation steps needed to close identified defects.
- Provide updated metric extracts and logs covering the period since remediation work began.
- Restate targets recorded in Solution Scope
- Confirm which Solution Scope targets are met and which require remediation.
- Agree remediation items with clear resolution dates so the onboarding window is formally closed.
- Validate that the incumbent system has been decommissioned or formally retained and that data archival actions are completed or scheduled.
- Publish a consolidated 90-day outcome report showing pass/marginal/fail status per Solution Scope target and remediation timelines.
- Deployment and migration validation
- Open incidents and high-priority backlog triage
- Compliance and cybersecurity posture check
- Present 90-day outcome data against each target
- Diagnose root causes for any KPI gaps
- Agree corrective actions and timelines
- Document remaining remediation items and resolution timeline
- Long-term remediation and backlog closure plan
- Early adoption signals and usage patterns
- Enhancement requests and prioritization
- Blockers and open issues triage
- Adjust monitoring and alert thresholds
- Confirm ongoing review cadence and escalation paths
- Confirm stabilization timeline to steady-state operations
- Incumbent system decommission and data archival checkpoint
- Agree immediate remediation actions