You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Demo vs. Trial vs. PoC vs. Pilot. What are you running?


Learning about Opmantek's products and capabilities - is a trial the best place for info?

  • Website and Wiki
  • Webinars and videos
  • Presales presentations and live product demonstrations

Trial vs. PoC vs. Pilot

  • Trial; Adhoc, small usually run by the customer to discover one of two documented features
  • PoC; Proof of COncept; more defined, larger with Opmantek engineering support to prove new features
  • Pilot; large scale, demonstrating full capability under a commercial agreement

A PoC or Pilot should have:

  • A defined and agreed scope and a defined and agreed timeline
  • A pilot has a defined outcome, e.g. selection approval/purchase order

Running a PoC or a Pilot cost money for both the prospect and Opmantek - both parties should be sure of what they expect to gain and the probabilities.

  • The purpose of a PoC is to PROVE the concept and to remove any remaining doubt so that an agreement can be completed e.g. confirm a new type of device can be managed.
  • A Pilot is really about, yes we agree to proceed and we know your solution works, we need to see it working in our environment and let other people in the company see it to finalize an agreement.
  • Typically companies charge for running a Pilot vs. a PoC.

What do we need to start?

  • Scope of what is to be trialed (the trial checklist)
    • What and how many devices
    • Which products, features, and use cases to test
  • An agreed plan of how we set up and operate the trial
    • Staff commitments
    • Timelines
  • Support process during the trial
  • What equipment and environments do we have access to?


Documentation

Trial; at the very least, a trial should include a checklist covering the following areas:

General Requirements

  • System requirements
  • Security; including authentication mechanism, roles and group administration
  • Architecture options via opHA
  • User interface requirements
  • Usability and transition between performance, event, and configuration solutions
  • Reporting

Network Discovery and VIsualization

  • Test Open-AudIT discovery and auditing
    • Review Open-AudIT change reports
    • Review Open-AudIT network lists and use them to reseed discovery
    • Review MPLS inventory tables to understand VRF awareness
  • Test creation of Maps in opCharts
    • Topological (both dynamic and static)
    • Diagram
    • Geographic (both dynamic and static)
    • Review combining elements into Dashboards

Fault and Event Management

  • opEvents' Current Event Views, status, and actionable activity
  • Create event Correlation for common device attributes; Location, Customer, Business Service, Role, etc.
  • Create event Actions for common troubleshooting activities and diagnostics
  • Setup example external enrichments ad diagnostic actions using sample scripts

Performance Management Requirements

  • Desk-based views of:
    • Polling policy; timings and collection policies
    • Real-time Collection in opCharts
  • Business policy functions
    • KPI Adaptation
    • Roles based alarm criticality
  • Thresholding and statistics
    • Thresholding controls
    • RRD calculations on the fly (i.e. 95th percentile)
    • Plugin system

Configuration Management Requirements

  • Details to be added...


Example PoC/Pilot Roadmap

  • No labels