BTS Group’s interoperability solutions and methodologies were employed by Energy America to build and host an online Energy Service Provider Billing Solution.
Energy America LLC is the largest unregulated energy wholesaler in North America. Energy America is owned by Centrica PLC, a leading provider of energy and other essential services. In the UK, Centrica offers simple solutions to everyday service needs, ranging from energy supply, telecoms, roadside recovery and financial services. It does this through its major consumer brands, the AA, British Gas, Scottish Gas, Goldfish and One.Tel.
This engagement consisted of building a new back office solution to support the management and billing of retail gas customers for Energy America (EA). EA is a customer service and enrollment agency used by utilities in deregulated markets. The system was built in support of their first customer, Atlanta Gas and Light (AGL), and the deregulated gas marketplace emerging in their existing service territory. The scope of the system was to interface with Energy America’s existing enrollment system, interchange data with the utility and all business partners, calculate and send monthly bill statements, make the system available online to the customer care team, remit payments and manage collection events.
Energy America was to be the source of all customer information for AGL. At that time, an existing call center, located in Toronto, of about 50 Customer Service Representatives (CSRs) was in place. They were already supporting two other deregulation market areas but the local Utility Distribution Centers (UDCs) for those areas handled all of the back-office support for them. With the Atlanta market however, Energy Service Providers had full responsibility for billing, remittance and collection. EA needed an online IT and business process outsourcing solution, in record time, in order to enter into this new market.Business RequirementsThe requirements for the system were obtained during a five day period using BTS’s Solution Needs Acquisition Process (SNAP). SNAP is an intense and rapid requirements collection regimen in which all stakeholders, decision-makers, and subject matter experts are brought together in a retreat-like atmosphere (for more information see: Using the Soluiton Needs Acquisition Process to Define Requirements). The SNAP ground rules (e.g. no phones or pagers) and isolated environment eliminate external distractions and facilitate the swift accumulation of pertinent information, action items and critical decisions.During the five day period, close to 100 documents were generated containing the requisite information to begin development of the solution and go live within the 12 week window that was allotted for the project. The information collected in the Energy America SNAP pertained to or included: Project Scoping
- Billing Rate Design
- Billing and Collections
- Termination and Account Maintenance
- Commodity Acquisition and Settlement
- Payment Processing
- Call Center Processing and Operations
- Consolidated Financials
- Bulk Processing Requirements
- B2B Requirements
- A2A Requirements
- Workflows for all Business Processes
- Key Milestones
- Rollout Plan
The primary objective communicated during the SNAP was the ability to receive payments on April 1, 1998 automatically via a clearing house. In addition, the billing system needed to seamlessly pass information between all systems involved in the solution. This meant that EA required not only a fully comprehensive billing system, but the development of functional B2B interoperability for seven different entities within 12 weeks. This situation dictated the use of an interoperability membrane that loosely coupled systems together, rather than employing tightly integrated and inflexible interfaces.
As the general contractor for all support services, we were tasked with providing the complete back office IT solution as well as a Business Process Operations staff. The responsibilities spanned from the integration of all business partners to the execution of major workflow processes including:
- Produce accurate billsPrint/mail bills & letters
- Handle all of the remittance processing
- Provide support for collection
- Hosting and management of the system
- Building the Solution
The core interoperability requirements included the passing of data between the EA enrollment system, the billing system which we procured, and a variety of systems at AGL that held the customer consumption information. In addition, business partners needed to be quickly identified, evaluated, selected, certified and implemented. This included institutions such as ACH (Automatic Clearing House) processors, Bill Printing partners, Lock-box partners for handling remittance through the mail, and Cash Payment processors for handling cash payments at grocery stores in Atlanta. The interoperability and the implementation with all partners was part of the scope of the initial implementation that was to be completed by April 1. The following table shows the business partners that needed to work with the billing system via the interoperability membrane and their respective business role:
|Energy America||Customer Service & Enrollment||Toronto, Ont|
|Atlanta Gas Light||Gas Production||Atlanta, GA|
|Doculink||Bill Print and Mail||Ottawa, Ont|
|Sempra Energy Trading||Energy Trader||Stamford, CT|
|Western Union||Wire Payments||Bridgeton, MO|
|GEIS||EDI Gateway||Gaithersburg, MD|
|First Union Bank||ACH||Charlotte, NC|
Best-of-breed solutions were selected to begin building the solution toolkit. A billing (CIS) system was procured to serve as the core and, where possible, other tools and frameworks were selected to build the interoperability membrane. In some cases, custom code was written to accommodate gaps in the COTS packages. The solution required that a workflow engine be used to broker all exchanges and ensure that transactions can be monitored, audited and traced by the operations team. An Enterprise Interoperability Framework (EIF) was built to accommodate the variety of data sources and formats that were part of the solution and fill gaps in the COTS packages that were available at the time. The interoperability needs of the solution included multiple database types COBOL applications, variable length record files, EDI transactions, XML files, CSV files, and Uniface applications. Components that utilized EIF for processing included:
- The AGL interface processed variable length transactional records from/to AGL that contained customer information and meter reading data. From this exchange, gas was to be procured and customers were to be billed according to rates and promotional contracts in accordance with the rules and regulations specified by the Public Utility Commission (PUC).
- The Bill Printing interface gathered appropriate data for bill printing information and created records based on the specification provided by the printing company.
- The Gas Procurement interface was a component that collected accurate information about individual accounts for gas procurement and built a CSV file according to the specification agreed to by the gas trading company.
- The Financial interface component extracted financial information to be made available to the financial agency.
- The ACH interface component created payment information in an ACH formatted file and interfaced to First Union Bank’s system and processed the file in the appropriate scheduled window.
- The Lockbox interface processed lockbox payments and updated the CIS system timely and accurately. Penalties were assessed for late payments accordingly. The lockbox interface processed data using the COBOL Adaptor built and embedded in EIF
- The Cash Payment component was also a COBOL based transaction, but it involved more effort in coordination with Western Union for groceries payments. Since cash payments involve manned transactions, it was necessary for errors and exceptions to be processed, flagged and handled with special conditions.
Given the very short window of opportunity, the team was created with clear roles, responsibilities and a system of accountability. The development progress had to be monitored very closely from all aspects: our internal interface development, interoperability with and implementation of the billing system, partner development and implementation as well as all of the testing and formal certifications. We defined touch points early and solidified public interfaces in the beginning of the project. Then, with short milestones, we proceeded with the development in parallel and closed the loop with full interoperability testing.
As planned, we enrolled the first wave of customers by February 15. The gas was procured on-time for the flow started on March 1. The bills were sent in late April and we received payments through ACH on March 31, 2010, one day earlier than the objective.
Building the Business Processes
Business Process Operations was developed in parallel with the technical solution. Based on the information gathered from the SNAP sessions, Operations personnel formalized all the process workflows and worked with the technical development team to see that the necessary modifications were made to the CIS system and workflow engine. The BPO team developed processes related to both the internal workings of the billing system as well as the interrelation of all the stakeholders and partners who were involved in delivering the solution. For example, the BPO group drove the development of RACI (Responsible, Accountable, Consulted, and Informed) charts and escalation matrices to identify clear lines of communication between all parties in all possible operational situations. They coordinated efforts between EA, the IT development team, the IT hosting Team, AGL and all other partners at all times.
Using existing tools and frameworks, an interoperability membrane was developed for these disparate services (B2B) and applications (A2A) and a higher-level end-to-end business solution for supporting Energy Service Provider billing was created. At the same time, the entire management infrastructure for supporting the BPO such as workflow management and process scheduling was developed in the span of 12 weeks.
After the first implementation of the Atlanta market, Energy America requested more implementations for different energy providers such as PSE&G, PECO, and Ontario. Because of the component re-usability, the development cost was substantially reduced for additional engagements even when employing disparate technologies such as EDI and XML. While Atlanta was built to support the data exchange related to 125,000 customers, PSEG was earmarked to reach 350,000 and DEML 500,000.
Over the next several monthss the EA offering was expanded to include: A Data Warehouse solution to help analyze business operations and financial results such as customer payment patterns, effectiveness of specific customer programs, collection events, etc. (for more information see: Centrica: A Case Study for Business Intelligence using Data Driven Analytics)
The development of a web-based customer enrollment module extended to include self-care services, Electronic Bill Payment and Bill Presentment (Review).
Energy America also received a complement from the PSC commissioner:
“To their credit, we never hear about billing problems from them . . . Here’s a company that at least seems to understand billing”
[Georgia PSC Commissioner] Wise added that he has no qualms about Energy America taking over some 50,000 customers of Titan Energy.
“Gas Daily”, July 19, 2000
The BTS Group is a technology services company that assists business owners and executives use technology and business process analysis to reach their strategic objectives. We implement the appropriate combination of consulting, managed and sourced services that enable successful completion of their initiatives and the quantifiable measurement of that success. For more information on how BTS can help you get more from your technology, contact us at firstname.lastname@example.org.