Developing an MDM Solution Johnston… · Non-functional requirements •Benefits of using Use Case design – Encourages creativity and brainstorming – Facilitates greater enterprise

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


BillingBilling

PackagesPackages


basedbased

TargetedTargeted

ProgramsPrograms


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


CustomerCustomer


DisDis --


MarketingMarketing


Repair/Repair/

DispatchDispatch

Meter Data


BillingBilling

PackagesPackages


basedbased

TargetedTargeted

ProgramsPrograms


ChoiceChoice

andand

ComfortComfort


BillingBilling

PackagesPackages


basedbased

TargetedTargeted

ProgramsPrograms


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


CustomerCustomer


DisDis --


MarketingMarketing


Repair/Repair/

DispatchDispatchCustomer Customer


CustomerCustomer


DisDis --


MarketingMarketing


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


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


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

Documents

Developing an MDM Solution Johnston… · Non-functional requirements •Benefits of using Use Case design – Encourages creativity and brainstorming – Facilitates greater enterprise