Experience you can trust.
Developing an MDM Solution
It’s All Business
2
This presentation will discuss several aspects of developing a Meter Data Management (MDM) solution:
• Defining MDM – What it is and isn’t
– Risks
• Generating functional requirements– Process
– Key Decision Points
• Lessons learned– Case study examples
– Helpful hints
Table of Contents
3
Defining MDM
4
Definition: Meter data management systems (MDMS) systems thatlink a utility’s meter data to its back-end enterprise systems.¹
Source: Chartwell, Meter Data Management, Analysis, Case Studiesand Vendor Profiles 2007
5
An MDM helps to limit risk exposure and provide the ability to fully leverage AMI-collected data.
Overload resources, delay implementation(s), exceed budget
Implementing MDM, CIS and AMI systems concurrently
Potential limited functionality vs. Uncertain integration
AMI and MDM: Use same vendor?
Does not meet performance requirements, cost overruns, limited future support
Customization of software
Waste millions of dollarsNot getting maximum use out of timely meter data
Potential RiskScenario
Defining MDM
6
Specifying Functional and Non-Functional Requirements
7
MDM requires a Business Solution – not a technical solution. AMI systems create a great opportunity to improve operational efficiency. It’s a transformational technology. The key question: how do you ensure the MDM system becomes an enabler?
CustomizedCustomized
BillingBilling
PackagesPackages
IntelligenceIntelligence --
basedbased
TargetedTargeted
ProgramsPrograms
InteractiveInteractive
ChoiceChoice
andand
ComfortComfort
CustomizedCustomized
BillingBilling
PackagesPackages
IntelligenceIntelligence --
basedbased
TargetedTargeted
ProgramsPrograms
InteractiveInteractive
ChoiceChoice
andand
ComfortComfort
DADA
OnOn -- linelineOnOn -- lineline
IntervalInterval
DataDataIntervalInterval
DataData
DADA
OutageOutage RealReal -- timetime TheftTheftOutageOutage RealReal -- timetime TheftTheft
OverOver
UsageUsage
IsolationIsolation
ProPro --
activeactive
OverOver
UsageUsage
IsolationIsolation
ProPro --
activeactive
Customer Customer
InformationInformation
CustomerCustomer
CareCareBillingBilling
DisDis --
tributiontributionForecastingForecasting
MarketingMarketing
CollectionsCollections
Repair/Repair/
DispatchDispatchCustomer Customer
InformationInformation
CustomerCustomer
CareCareBillingBilling
DisDis --
tributiontributionForecastingForecasting
MarketingMarketing
CollectionsCollections
Repair/Repair/
DispatchDispatch
Meter Data
CustomizedCustomized
BillingBilling
PackagesPackages
IntelligenceIntelligence --
basedbased
TargetedTargeted
ProgramsPrograms
InteractiveInteractive
ChoiceChoice
andand
ComfortComfort
CustomizedCustomized
BillingBilling
PackagesPackages
IntelligenceIntelligence --
basedbased
TargetedTargeted
ProgramsPrograms
InteractiveInteractive
ChoiceChoice
andand
ComfortComfort
DADA
OnOn -- linelineOnOn -- linelineOnOn -- linelineOnOn -- lineline
IntervalInterval
DataDataIntervalInterval
DataData
DADA
OutageOutage RealReal -- timetime TheftTheftOutageOutage RealReal -- timetime TheftTheft
OverOver
UsageUsage
IsolationIsolation
ProPro --
activeactive
OverOver
UsageUsage
IsolationIsolation
ProPro --
activeactive
Customer Customer
InformationInformation
CustomerCustomer
CareCareBillingBilling
DisDis --
tributiontributionForecastingForecasting
MarketingMarketing
CollectionsCollections
Repair/Repair/
DispatchDispatchCustomer Customer
InformationInformation
CustomerCustomer
CareCareBillingBilling
DisDis --
tributiontributionForecastingForecasting
MarketingMarketing
CollectionsCollections
Repair/Repair/
DispatchDispatch
Meter Data
AMR
One-way
AMR Plus
AMI(Full two-way)
Fin
anci
al In
vest
men
t/ P
oten
tial R
etur
n
Operational Functionality/ Flexibility
• Automated monthly reads• Tamper reporting• Data aggregation• Load profiling• Meter diagnostics reporting
• Daily or on-demand reads-• Hourly interval data• Outage notification• Other commodity reads
• Integrated disconnect• Advanced time-based rates-• DG detection and control• Remote meter programming• PQ monitoring/ reporting• Home area network interface• Security
AMR vs. AMI Capability
Defining MDM
8
• Customer Service/Billing• Regulatory• Rate Engineering• IT• Metering/Meter Shop• Corporate Accounting• Engineering/Distribution Operations • Dispatching/Workforce Management• Revenue Protection
To truly take advantage of MDM and any other automation, utility executives need to plan for process-change now. The first step – even as your team evaluates various technologies – is to begin assessing new processes.
Functional Requirements
9
Start with the end in mind. Identifying specific needs and requirements as early as possible is vital to program success.
• Identify and Document Needs and Requirements– What data can the AMI system
obtain?– Will MDM handle Asset
Management (including meters)?
– What new functions can departments perform with that data?
– What interfaces are needed?– Where will validation occur?– Do we need a System
Integrator?
• Develop Your Fantasy “Functionality” List by creating a matrix that– Prioritze functionality
• Must Have• Like to Have• Nice to Have
– RFP to the Vendor emphasizes function, not design
Functional Requirements
10
As a prelude to vendor procurement, KEMA has helped a number of utilities in applying the Use Case tool to develop system requirements.
• Business narrative that describes a set of activities to achieve a desired end state or goal
• Includes a set of Actors, Triggering event(s), Scenario Steps, Assumptions, & Dependencies – leading to a set of desired Functional and Non-functional requirements
• Benefits of using Use Case design– Encourages creativity and brainstorming
– Facilitates greater enterprise stakeholder consensus
– Enables greater alignment between business needs and
system design
– Provides project documentation for subsequent testing,
training, and regulatory support
– Feeds directly into vendor procurement process
AMIUse Cases
Use Case Process
11
Lessons Learned
12
There are many challenges associated with implementing an MDM systems
• Vendor selection• VEE location and throughput• Changes of ownership• Changes of interval size• Incomplete/Missing data• Data versions• Embedded business rules• Settlement requirements• Processing deadlines• Multiple commodities• Dispute processing, and reruns• Tariff changes• Interfaces, interfaces, interfaces• Regional vs Centralized
• Timescales, contracts• Data ownership• Auditability• Aggregate/Net readings• Time of Use• Data archival• Meter/premise/customer/account• Daylight savings• Data denormalization• Common identifiers• Settlement day• Communications• Units of measure• Minimum requirements
Data Management, Process and Market Rules, Impact of Change
13
• Software– License
– Configuration
– Enhancements
– Integration (interfaces)
– Data warehouse
• Hardware– Processors
– Storage
– Disaster Recovery
• Development– Product Selection
– Business Process Definition
– Architecture & Design
– Testing
• Operations & Maintenance– Ongoing Software Licenses
– Internal Application Support
– Capital refresh of hardware (after
5 years)
Source: SCE filing with PUC, Date XXXXXXX
Lessons Learned
Southern California Edison estimated MDM costs at $101, but be careful in making apples-to-apples comparisons.
14
San Diego Gas & Electric is following an 8-month timetable just for developing an MDM architecture and selecting a vendor.
AMI Requirements
VendorSolicitation
Evaluate& Analyze
Architect &Recommend
Month 7-8
• Solution architecture
• Solution
implementation roadmap
Month 5-6
• Vendor evaluation criteria
• Vendor scoring
& ranking
Month 3-4
• Comprehensive requirements
• Vendor
solicitation development
Month 1-2
• Benefits quantification
• Business
process design• Functional
requirements
• Information
requirements
Source: SDG&E filing with Calif. PUC - xxxxxx
Lessons Learned
15
Pacific Gas & Electric followed a business process to develop its large-scale requirements.
• Requirements: store 9 million-plus customer reads
• Architecture: – Separate Data Warehouse and
MDM
• MDMS
– Will hold customer data for 14
months
– Perform VEE of raw data
• Data Warehouse will store data
for seven years as required by
PSC
“It wasn’t driven by technical outlook per se; it
was more driven by the business in terms of what
we want to accomplish and achieve.”
– Bevin Louie, PG&E IT Solutions Architecture.
Source: Chartwell Inc., “Meter Data Management: Analysis, Case Studies & Vendor Profiles
Lessons Learned
16
Best practices are starting to evolve for MDM implementation and vendor selection.
• Vendor Evaluation– Pricing
– Architecture
– Functionality
– Program Support
– Experience
– Schedule
• MDM can increase the life of a utility CIS
• Limit customization
• MDM must be flexible enough to:– Meet unknown future requirements
– Integrate with new systems
– Possibly perform VEE at multiple
stages
• Ask MDM vendors:– How they identify and handle
certain problems
– What is included in the price
Lessons Learned
17
Best practices (cont.)
• Determine whether MDM should:– Manage assets
– House “Battery Replacement Schedule”
• Spend money wisely on synchronization– “A little redundancy is OK”
• Test and go live with one application (e.g., billing) before rolling out others
• AMI does not replace the need for OMS• Plan for transitional period• Find Business partner (not just a technology
provider)
Lessons Learned
18
MDM will transform the way
your utility does business.
Designing it requires a Business
Solution.
Final Words
Experience you can trust.
Questions?
Garrett JohnstonSr. Consultant – KEMA Inc.
(404) [email protected]
20
Start with a bottoms-up approach to develop high-level requirements. Move to top-down approach by educating other departments on AMI capabilities.
Top Down- Use Cases
- Data Architecture
Bottoms Up- Develop conceptual model
(functional)- Validate with Utilities,
Industry Experts
Desired FutureState
Functional Requirements
21
Supplementary Slides
22
• The choice between less intelligent devices reporting frequently or more intelligent devices reporting more data infrequently is one of the key performance factors that can establish the overall communications network requirements and design.
• How many databases? (As few as possible)• How big should the database be?
23
• “Conference Room User Test” (SCE)– Evaluate user interface and usability
– Perform application scalability testing
• how does it perform under various
operating conditions?)
Source: SCE filing with Calif. PUC - xxxxxx
SCE also included specific test processes for its MDM. Others have done likewise, although the specific procedures vary.
24
Utilities are starting to form MDM strategies and select vendors. Many lessons can be learned from their experiences.
• SCE• SDG&E • Anonymous 1• Anonymous 2
25
Validation and editing flexibility are key requirements for this utility, while going live “one route at a time” will enable a smooth transition.
• Final scoring (sample utility – see Alinta)– Technical architecture to scale– Residential account/VEE flexibility– Complex billing flexibility– Online presentment and rate analysis– Timeline/Schedule
• 16 months including 6 months working with vendors on exact requirements (1 year needed to integrate any system)
• Go “live” one route at a time