Message Exchange in the Utility Market Using SAP for Utilities. Point of View by Marc Metz and Maarten Vriesema

Transcription

1 Eergy, Utilities ad Chemicals the way we see it Message Exchage i the Utility Market Usig SAP for Utilities Poit of View by Marc Metz ad Maarte Vriesema

2 Itroductio Liberalisatio of utility markets has required ubudlig, ew rules ad ew roles. This also meas ew processes i order to make the market work. How ca all these ew roles, market parties ad processes be liked together so that everythig falls ito place? The aswer, i short, is commuicatio or, more cocrete, exchagig iformatio through messages. are a vital igrediet of a competitive market sice they allow each market party to realise its iteded role ad execute the required processes. Without the ability to process messages a utility compay may as well close dow. This Poit of View will look ito the questio of how SAP for Utilities supports message exchage i a deregulated utility market. Because the messages are essetial as iput for uderlyig processes ad vice versa (as output from processes), this documet will also look ito the deregulated processes supported by SAP for Utilities. Basis is the fuctioality of the Itercompay Data Exchage module (IDE) available i SAP for Utilities versio This Poit of View will ot go ito the details of the differet market rules ad requiremets regardig messages ad processig thereof. However the ifluece of IT-architecture will ot be dealt with. Itercompay Data Exchage (IDE) explaied The followig high level outlie of the IDE fuctioality will help to uderstad how it fits i with the uderlyig processes i the system. I essece IDE supports the processig of iboud ad the creatio of outboud messages. IDE processes The IDE fuctioality is focussed o socalled IDE processes. A IDE process is the defiitio of the exchage of a sigle message type betwee two o specific parties. For istace a distributor seds message type x to a supplier. A IDE process is either iboud or outboud. High Level Overview of IDE IDE process 1 IDE process 2 IDE process 3 Iboud message Outboud trigger Message structure Programmig Market Party X Market Party Y The IDE process also defies the message structure used i the iformatio exchage ad it specifies the programs that ca either process a iboud message or that ca create ad populate a outboud message. With these two parts i place the basic requiremets for successful iformatio exchage are fulfilled. Market Parties ad Meter poits The IDE processes are assiged to each market party that is defied i the system for which the exchage process is applicable. I this way each party is subscribed to oe or more message exchage processes which eable the messages exchage requiremets for each market party. The relatioship betwee a market party ad a meter poit is defied by the role the party has at that meter poit. IDE task A iboud process hadles icomig messages. Iboud messages cotai the seder of the message ad relevat meter poit: therefore all iformatio ecessary for processig is icluded. Whe a iboud process is executed a IDE task is geerated that processes the data i the message received. Meter Poit 1 Meter Poit 2 Moitorig IDE task Outboud Processed Outboud processes are triggered by evets occurrig i the system. These processes take care of executig IDE tasks which create outboud messages. SAP has defied a umber of busiess evets that trigger outboud processes (e.g. customer data chaged, bill created, etc). I the case of a evet i the system, the system checks for which meter poits the evet is relevat. Next the system determies which market parties are assiged to the meter poit(s). For each market party foud that is subscribed to the process, a IDE task is created. The IDE task the takes care of creatig the messages with the proper data. The IDE task (both iboud ad outboud) ca be moitored ad maaged, thus providig valuable iformatio for process maagemet. A call cetre employee for istace ca retrieve iformatio o the progress of a chage of supplier process for a specific meter poit as part of a customer iquiry. 2

3 Eergy, Utilities ad Chemicals the way we see it Flexibility of IDE i various markets With the itroductio of the IDE process cocept, SAP has provided a framework for implemetig message exchage i a variety of markets. The same IDE process eve allows processig of multiple message formats, thus providig optios for usig the same system to support differet markets. Sice iboud IDE processes are triggered by receipt of a message, ay iboud process ca be built although i may cases custom developmet is required. Outboud IDE processes however are triggered by SAP provided system iteral evets. Whe there are requiremets for outboud processes for which SAP has o evets defied, userexits ca ofte be used to provide the required fuctioality. Realisatio aspects For some markets (e.g. the Germa, Nordic ad America markets) SAP delivers message structure defiitios ad supportig programs. For most markets, however, the implemetatio of the IDE processes requires customer specific developmet. Besides additioal programmig, workflow fuctioality is also usually required whe implemetig IDE. The reaso for this is that a IDE process defies a sigle message exchage whereas busiess processes ofte require multiple messages (both iboud ad outboud), maual itervetios uder specific circumstaces or timig depedecies betwee messages ad/or process executio. Workflow fuctioality allows cotrol over these depedecies. The compay-specific implemetatio of IDE ot oly depeds o the exteral requiremets ad rules but also o the iteral IT-architecture. The basic questios here are: Ca ay oe outboud message be built completely by a sigle applicatio or is data required that is maitaied i differet applicatios i order to fully ad correctly populate a message? ad Does ay oe iboud message eed multiple applicatios for processig? Obviously a requiremet for support of Techical realisatio: Coectig SAP for Utilities to the outside world IS-U System R/3 - IDoc Third Party Product CCS - System Seder EDI Traslator Seder Data i proprietary format like ASCII Data i stadard Format like EDIFACT, ANSI X.12 multiple applicatios would icrease the complexity substatially. As stated i the itroductio this Poit of View will ot explore the impact of IT architecture sice it is a topic i its ow right. Aother realisatio aspect is that the IDE toolbox oly has fuctioality withi the SAP for Utilities boudary. A separate system is required to coect to the outside world. This ca be SAP Netweaver, SeeBeyod, WebMethods or other EAI packages. For a iboud message, these systems hadle the traslatio of for istace XML format (or other market defied stadard)t ito Idoc format ad the postig of that Idoc i SAP for Utilities. The postig triggers the executio of a IDE process. Vice versa a iteral evet, for istace the billig of a meter read, triggers the executio of a outboud IDE process. This process will create a Idoc. SAP Basis fuctioality takes care of iformig the EAI system that a Idoc is ready to be set. This system will the traslate this Idoc ito for istace XML ad sed it to the iteded recipiet via the commuicatio chael that has bee agreed. As far as the IDE process is Trasmissio Facilities X400, VAN, leased lie, etc. Data i proprietary format like ASCII Data i stadard Format like EDIFACT, ANSI X.12 CCS System Seder EDI Traslator Seder cocered, the correct creatio of the Idoc eds the process successfully: the IDE process has o kowledge of the result of the traslatio ad trasmissio outside the SAP for Utilities boudary. ad the processes i SAP for Utilities I the itroductio the poit was made that messages are oe importat aspect i makig utility markets work. play a eablig role i the deregulated utility processes. Therefore examiig how messages are hadled by SAP for Utilities should also ivolve how messages itegrate i supported processes. Gettig iformatio through messages is ot eough; a system eeds to be able to process the cotet of the messages. I order to clarify i a structured way how SAP for Utilities itegrates messages ad processes, the followig framework is used to differetiate groups of similar messages ad idetify the mai processes they belog to. Message Exchage i the Utility Market Usig SAP for Utilities 3

4 SAP Netweaver High Level ad Processes i Utility Markets Uder the ame Netweaver, SAP markets a set of techologies that are aimed at itegratig (complex) IT eviromets ad thus lowerig the Total Cost of Owership (TCO). SAP Netweaver eables the cocept of a Eterprise Service Architecture (ESA). The objective of ESA is to add ew levels of flexibility to IT eviromets by itegratig Process: Balacig Data Balacig Master Data Master Data Maagemet I The Utility Market Meter & meter works related Switch Billig related Meterig Switchig Billig people iformatio ad processes Example: Aggregated cosumptio for allocatio Chaged customer details (e.g. bak accout) Chage of meter details Validate meter readigs Request for a chage of supplier Ope items for 3rd party billig The itegratio is across orgaisatioal boudaries ad betwee SAP, o-sap ad legacy systems. This is realised by a applicatio platform that offers iteroperability with IBM websphere ad Microsoft.NET techology. At the process level SAP Netweaver cotais SAP Exchage Ifrastructure (XI). XI provides the XML based messagig i a complex systems ladscape that will allow Idocs to be commuicated to other market parties. Example i the Dutch Utility Market I The Netherlads the customer paymet method was ofte used to iclude trasportatio costs o the supplier s bill. Clear rules aroud opaymet however were ot agreed yet. A supplier wet bakrupt ad the distributor dued the customers from which he had ot received ay paymets for the trasportatio costs. It tured out that the customers had paid the supplier already, however the supplier had ot trasferred the paymets to the distributor. Legal actios were take o both sides to resolve the situatio. Result of this is that combiig bills has dropped dramatically thus icreasig the total costs of billig. SAP for Utilities is a itegrated system based o sigle registratio of data. I SAP for Utilities the meter ad meter readig data is the sigle basis that is used for multiple processes such as balacig, meterig ad billig. The followigs paragraphs ivestigate how these processes iteract i SAP for Utilities. 1 Meterig O a high level, meter ad meter works related messages are part of two geeral processes: Meter Readig admiistratio (recordig ad maagig the readigs that are take from a meter) ad Meter admiistratio (techical aspects of meters like storage, istallatio, (re)placemet). This sectio first explores these two geeral processes i SAP i order to examie how the system fits with market reality. Before explorig this, it is importat to realize that i SAP cosumptio is calculated i meterig processes for validatio purposes oly; the fial cosumptio determiatio ad capture is part of the billig process. Cosumptio determiatio is therefore covered i the part o billig ad ot i this paragraph o meterig. Meter Readig admiistratio. First examiig the iput side of the meter readig process i SAP for Utilities, messages cotaiig meter readig data per meter poit are iput for the role of supplier or market parties like a metered data aggregator. The SAP system provides stadard fuctioality to process meter readig data. However this fuctioality requires a certai data format as iput. Therefore the cotet of messages with meter readig data must be trasformed to fit the required iput format. Oce this fuctioality is programmed the meter readig data from the messages is stored ad ca be used for further processes such as billig. Examiig the output side of the meter readig process i SAP for Utilities, the system has o stadard trigger to idepedetly sed meter readig data. This meas, for example, that a compay with the role of metered data collector usig IS-U has o stadard startig poit that eables sedig messages with meter readig data. I the system meter readig data eeds to be billed first before a outgoig message cotaiig meter readig data ca be triggered. 4

5 Eergy, Utilities ad Chemicals the way we see it Meter admiistratio. Secodly, lookig at SAP for Utilities for Meter admiistratio processes, the system supports the geeratio ad sedig of messages for chages i the techical meter data through a IDE process. A example is the exchage of a meter. The messages triggered by processig the meter chage, however, do ot iclude meter readig data. This fits with some markets where techical meter data ad meter readig data are exchaged i separate messages. Market fit. After this descriptio of how meter readig admiistratio ad meter admiistratio processes support the hadlig of messages, it becomes iterestig to explore the fit with the reality of the market. Lookig at the market orgaizatio two situatios ca exist. Market rules either require the exchage of meter readigs for calculatig cosumptio or the rules require the exchage of cosumptio data. If the market rules require the exchage of meter readigs ad each market participat is resposible for calculatig cosumptio, techical meter data is imperative as part of the message exchage. Without this techical meter data it is impossible for the recipiet to uambiguously calculate cosumptio. Moreover, whe techical chages occur, a eed for timely exchage of data to other market parties exists because their processes deped o the same techical iformatio for cosumptio calculatio. O the other had, should the market rules require the exchage of cosumptio, possibly with meter readigs ad techical meter data for iformatioal purposes oly, the eed for exact sychroizatio is far less. The reaso for this is that meter readigs ad techical data are ot required whe billig cosumptio. Besides the market rules regardig what data exchage are required, busiess requiremets o how to process correctios o both the meter readig ad meter admiistratio processes ca have a profoud ifluece o decisios o how to implemet the market rules. This leads to the coclusio that both market orgaizatios ca be supported. However the first optio, exchagig meter reads ad techical data ca lead to complex processes, whereas the secod optio, exchagig cosumptio, leads to simpler processes. 2 Billig Billig i SAP is the process whereby cosumptio is determied ad used to calculate payable amouts. It is the cetral cyclical process i SAP for Utilities. From the perspective of message exchage, billig i SAP has two key aspects. First key fuctio is calculatig ad capturig cosumptio from meter readigs. I the process flow of the system, it is ot util billig that cosumptio is calculated from start ad ed meter readigs. I this calculatio trasformatio factors ad losses, calorific values for gas, etc are take ito accout. The importat implicatio of this is the depedecy o billig for commuicatig cosumptio data to other market parties. The secod key fuctio of billig i SAP for Utilities is esurig that ay data used i billig, icludig meter readig data, caot be chaged freely aymore. This allows creatio of a full audit trail of ay chages i data that are used i billig sice a reversal of billig is ecessary before the data (ad thus the readig) is ready to be chaged agai. Because of the cosumptio calculatio fuctioality ad the full audit trail that is available aroud billig, it is the billig process that results i a trigger for sedig messages cotaiig cosumptio data ad meter readig data. I the Utility idustry billig is usually a tightly maaged cyclical process. The requiremet to bill i order to create outboud messages for either meter reads or cosumptio iformatio iflueces the desig of the billig process. This becomes evidet whe lookig at iterim customer reads or meter exchage readigs which ormally would ot trigger billig. Whe market rules or busiess rules require the exchage of those readigs, SAP for Utilities requires a ad-hoc billig process ext to the ormal cyclic billig. The recipiet of the message with cosumptio or meter read data, usually a Supplier, also eeds to have a close look ito the desig of its billig process. Here also it is a tightly cotrolled cyclical process. However sice it is ot (precisely) kow whe he will receive meter reads or cosumptio, he must allow cosumptio or meter read data to be received ad processed i his system outside his ormal billig schedule. Also if o data is received at the time of his billig schedule he will most probably bill o estimated meter reads or estimated cosumptio. Bills based o estimates ofte require re-billig or recalculatio whe actual cosumptio becomes available. SAP for Utilities supports this, but it ca complicate the desig of the billig process. The implicatio of billig beig required to sed cosumptio ad/or meter read data to other market parties must ot be uderestimated. The billig egie of SAP for Utilities is highly flexible. However commuicatio requiremets ca easily lead to complex situatios that have to be resolved i both the desig ad implemetatio of the billig process. Aother implicatio is of orgaizatioal ature. The usual place for maagig meter read ad cosumptio messages is the data processig departmet. With SAP for Utilities this is ow pushed ito the billig departmet with its orgaizatioal implicatios. Message Exchage i the Utility Market Usig SAP for Utilities 5

6 3rd Party billig. Aother ofte required fuctioality is the iclusio of third party items o the customers bill. For istace a Supplier ca iclude trasportatio costs billed by the Distributor. The fiacial relatioship betwee the billig parter ad the parter hadlig the customer cotacts is oe of the determiig aspects i the implemetatio of this fuctioality. SAP for Utilities supports three possible fiacial relatioships: Sole provider - the party that seds the customer s bill becomes the ower of the ope items ad rus the fiacial risk Advaced paymet - the party that seds the customer s bill pays the 3rd party whe the bill is issued Customer paymet - the party that seds the customer s bill pays the 3rd party whe the customer has paid A example of the sole provider optio is the bill of a supplier that icludes items of a distributor o that bill. If the customer does t pay, the supplier is still required to pay the distributor. I the other two optios the distributor is still fiacially resposible for the ope items. Therefore it has to be decided how to maage o paymet by customers. I IDE the sedig of bill iformatio by the distributor to the supplier i the example above is triggered by ruig a program that creates a message for each meter poit of that supplier based o the ope items posted. The receivig party most probably will wat to implemet a bill verificatio process. SAP for Utilities supports a framework of verificatio of iboud messages with bill iformatio, creatio of billig iformatio to be icluded o the ext customers ivoice ad creatio of remittace advices ad paymets. The receipt of a customer paymet ca also trigger the creatio of remittace advice. The remittace advices received by the distributor are used to settle the ope items. I short IDE supports various fiacial relatioships for 3rd party billig well. Billig reversal. Oe other aspect of usig billig for triggerig message exchages is the reversal of billig a meter poit. The reversal usually implies that some error occurred that eeds rectificatio. Therefore reversal also triggers the creatio of outboud messages ad thus allows iformig the recipiet about the reversal. I some cases, however, the reaso for reversal is ot relevat for other market parties. For example a distributor used the wrog price data which does t impact the cosumptio iformatio used by a supplier. Still, a message exchage will be triggered by the reversal though the iformatio should ot be set. To suppress this, programmig is required as part of the sedig process to hadle this properly. A importat observatio is that the proper hadlig of the messages ca become highly depedet o the correct use of the system by the employees. May activities i the system are tied to other, ew processes that are less visible to ed users. These ew processes cross compay boudaries ad therefore mistakes by ed-users ca have far reachig implicatios. Extesive traiig ad careful selectio of well qualified employees are o loger just costs but essetial ivestmets. 3 Balacig SAP for Utilities supports balacig ad the sedig of the results usig IDE well. However market rules ca hamper easy implemetatio whe there are coflictig requiremets betwee billig (ad the eed for billig to process meter reads) ad balacig. 4 Switchig I all markets, switchig suppliers is a complex process i which a umber of differet messages are exchaged betwee a umber of participats. All kids of rules ad regulatios gover the process ad there are huge differeces betwee markets. Therefore SAP for Utilities delivers a template implemetatio of the process oly for Germay. As a cosequece ay implemetatio will require a substatial build effort. IDE supports the process by usig a socalled switch documet. I this documet all data relevat to the switch process for a specific meter poit are stored ad ca thus be shared betwee the differet steps of the process. These steps are coected usig workflow. The ew supplier starts the process by maually activatig a workflow. The first step of that workflow creates a switch documet ad geerates ad seds the required message(s) to the Distributor. O the Distributors side the process is started by the receipt of the message. The receipt of the message triggers a IDE task. This task creates a switch documet, message(s) to the old supplier ad kicks-off a workflow which will hadle all follow-o activities. The ed of the process for both Supplier ad Distributor is a stadard SAP trasactio for a move-out ad/or a move-i of a customer o a meter poit. Those trasactios take care of registerig the proper market parties ad their roles o the meter poit. Depedig o the market rules, there ca be great differeces i the Distributors relatioship with the old ad the ew supplier. The old supplier for istace icluded the trasportatio costs o the ivoice to the customer whereas the ew supplier does ot. Therefore i the ew situatio the Distributor must sed his ow ivoice to the customer. To support the chageover from the old to the ew situatio, oe ca cofigure ad develop so-called supply scearios. SAP supports the switchig process properly. 6

7 Eergy, Utilities ad Chemicals the way we see it Cocludig Remarks I this Poit of View we have explaied/ivestigated the basic workigs of Itercompay Data Exchage (IDE) i SAP for Utilities. SAP has itegrated this fuctioality i the existig system that was already market leader for the regulated markets. IDE is a toolbox, i.e. SAP does ot deliver all fuctioality required for a specific market. It delivers fuctioality by which a customer ca implemet custom developmets withi a supported framework. If market requiremets caot be supported by customizatio withi the framework, SAP will strive to ehace the system with required fuctioality. Implemetig IDE therefore requires a substative effort (amout of time ad moey). Sice IDE is a more techical module, implemeters with more techical kowledge are required tha i a regular implemetatio of the system. Because workflow is itercoected with IDE, skills i this area are also ecessary. This Poit of View also touched o implicatios of a orgaizatioal ature. The iterdepedecies betwee processes as a result of the exchage of messages lead to higher requiremets o the skills ad competeces of employees. Also the resposibilities of departmets ca icrease or shift as was described i the case of a billig departmet becomig resposible vfor maagig meter read ad cosumptio messages. These are topics for chage maagemet durig system implemetatio. With IDE, SAP delivers a cosistet set of fuctioalities. It is up to the customer to determie how well it fits with the market rules ad regulatios for which the system is to be implemeted. The decisio betwee usig a coglomerate of best-of-breed packages or usig a sigle itegrated system is ot easily made. For some markets, packages are available focused o message processig for that market. However these packages still require itegratio with the processes that use or geerate those messages. They will ot solve the problems caused by market rules havig differet requiremets for meter readig processig, billig ad data aggregatio/recociliatio. Our view o possible future developmets i the IDE area, is to focus o reducig the depedecy o billig ad improvig the meter readig fuctioality. It would be a beefit if meter reads could be set out idepedetly from billig ad if audit trails for chages were available. Sice billig is the core of this system it is ot surprisig to coclude that IDE heavily depeds o billig. It is therefore also ot surprisig that it will fit better i markets where cosumptio is exchaged tha i markets where meter readigs ad techical meter data are exchaged. Both market types ca be supported as ca be see from implemetatios i the Nordic, the US, Germay ad the UK. The latter market type however will eed more developmet ad the itegratio with billig will be less straightforward. I both cases a high level of expertise is required i the areas of billig ad meter data processig. About Capgemii ad the Collaborative Busiess Experiece Capgemii, oe of the world s foremost providers of Cosultig, Techology ad Outsourcig services, has a uique way of workig with its cliets, called the Collaborative Busiess Experiece. Backed by over three decades of idustry ad service experiece, the Collaborative Busiess Experiece is desiged to help our cliets achieve better, faster, more sustaiable results through seamless access to our etwork of world-leadig techology parters ad collaboratio-focused methods ad tools. strategies, leverage techology, ad thrive through the power of collaboratio. Capgemii employs approximately 61,000 people worldwide ad reported 2005 global reveues of 6,954 millio euros. With 1 billio euros reveue i 2005 ad 8,000+ dedicated cosultats egaged i Eergy, Utilities ad Chemicals projects across Europe, North America ad Asia Pacific, Capgemii's Eergy, Utilities & Chemicals Global Sector serves the busiess cosultig ad iformatio techology eeds of may of the world s largest players of this idustry. Through commitmet to mutual success ad the achievemet of tagible value, we help busiesses implemet growth More iformatio about our services, offices ad research is available at Copyright 2006 Capgemii. All rights reserved. EUC _474

8