Goedgekeurd Eindrapport. Ontwikkeling van een marktmodel voor de Vlaamse energiemarkt fase 1 bis. WERKTRAJECT 2 Operationeel

1

Goedgekeurd Eindrapport Ontwikkeling van een marktmodel voor de Vlaamse energiemarkt – fase 1 bis WERKTRAJECT 2 – Operationeel

Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

2

INHOUDSOPGAVE 1. INTRODUCTIE ............................................................................................................................................... 4 2. DOELSTELLINGEN, SCOPE EN PLAN VAN AANPAK ......................................................................................... 5 2.1. DOELSTELLINGEN WT2 ..................................................................................................................................... 5 2.2. SCOPE WT2-OP .............................................................................................................................................. 6 2.3. PLAN VAN AANPAK ........................................................................................................................................... 7 3. MANAGEMENT SAMENVATTING .................................................................................................................. 9 3.1. TOEGANG TOT INFORMATIE ................................................................................................................................ 9 3.2. ONTBREKENDE MEETGEGEVENS EN CONTRACTLOZE LEVERING ................................................................................. 13 3.3. INPUT WT1 EN WT3 ...................................................................................................................................... 14 3.4. CONCLUSIE .................................................................................................................................................... 14 4. TOEGANG TOT INFORMATIE ....................................................................................................................... 16 4.1. IDENTIFICATIE VAN DE KNELPUNTEN ................................................................................................................... 16

4.1.1. Probleemgebieden .............................................................................................................. 16 4.1.2. Concretisering .................................................................................................................... 18 4.2. BEHANDELING VAN DE KNELPUNTEN .................................................................................................................. 20

4.2.1. Onbeperkte toegang tot officiële databestanden .............................................................. 20 4.2.1.1. Probleemstelling .......................................................................................................................................... 20 4.2.1.2. Voorgestelde oplossing ................................................................................................................................ 21 4.2.1.3. Evaluatie ....................................................................................................................................................... 24 4.2.1.4. Conclusie ...................................................................................................................................................... 25

4.2.2. Ownership over het contactadres...................................................................................... 25 4.2.2.1. Probleemstelling .......................................................................................................................................... 25 4.2.2.2. Voorgestelde oplossing ................................................................................................................................ 27 4.2.2.3. Evaluatie ....................................................................................................................................................... 29 4.2.2.4. Conclusie ...................................................................................................................................................... 33

4.2.3. Toegang tot netgebruikergegevens .................................................................................... 34 4.2.3.1. Probleemstelling .......................................................................................................................................... 34 4.2.3.2. Voorgestelde oplossing ................................................................................................................................ 37 4.2.3.3. Evaluatie ....................................................................................................................................................... 39 4.2.3.3. Conclusie ...................................................................................................................................................... 42

4.2.4. Het veld res/niet-res en reëel verbruikspatroon ............................................................... 42 4.2.4.1. Probleemstelling .......................................................................................................................................... 42 4.2.4.2. Voorgestelde oplossing ................................................................................................................................ 43 4.2.4.3. Evaluatie ....................................................................................................................................................... 43 4.2.4.4. Conclusie ...................................................................................................................................................... 44

4.2.5. Het veld NACE code .......................................................................................................... 44 4.2.5.1. Probleemstelling .......................................................................................................................................... 44 4.2.5.2. Voorgestelde oplossingen ............................................................................................................................ 45 4.2.5.3. Conclusie ...................................................................................................................................................... 46

4.2.6. Toekenning van het sociaal tarief...................................................................................... 47 4.2.6.1. Probleemstelling .......................................................................................................................................... 47 4.2.6.2. Voorgestelde oplossing ................................................................................................................................ 48 4.2.6.3. Conclusie ...................................................................................................................................................... 48

4.2.7. Uniformisatie en standaardisatie van adresgegevens........................................................ 48 4.3. DOORVERWIJZING RESULTATEN WT1 EN WT3 M.B.T. TOEGANG TOT INFORMATIE .................................................... 49


3

5. ONTBREKENDE MEETGEGEVENS EN CONTRACTLOZE LEVERING ................................................................. 50 5.1. IDENTIFICATIE VAN DE KNELPUNTEN ................................................................................................................... 50 5.2. PROBLEEMSTELLING ........................................................................................................................................ 50 5.3. VOORGESTELDE OPLOSSINGEN .......................................................................................................................... 51

5.3.1 Voorstel leveranciers ........................................................................................................... 51 5.3.2. Voorstel DNB’s ................................................................................................................... 52 4.3.2.1. Overdracht van verantwoordelijkheid ....................................................................................................... 52 5.3.2.2. Vraag om afsluiting ...................................................................................................................................... 53 5.4. BESPREKING .................................................................................................................................................. 54 5.5. CONCLUSIE .................................................................................................................................................... 55 5.6. DOORVERWIJZING RESULTATEN WT1 EN WT3 M.B.T. VERHUIS ............................................................................. 55

APPENDIX 1: EANDIS – PROBLEEMANALYSE TOEGANG TOT INFORMATIE ...................................................... 59 APPENDIX 2: SPE – PROBLEEMANALYSE ONBEPERKTE TOEGANG TOT OFFICIËLE DATABESTANDEN .............. 59 APPENDIX 3: ELECTRABEL – CONTACTADRES OWNERSHIP ............................................................................. 59 APPENDIX 4: ELECTRABEL – TOEGANG TOT TOEGANGSREGISTER .................................................................. 59 APPENDIX 5: SPE – PROBLEEMANALYSE TOEGANG TOT NETGEBRUIKERGEGEVENS ....................................... 59 APPENDIX 6: DNB’S – TOEGANG TOT INFORMATIE ........................................................................................ 59 APPENDIX 7: ELECTRABEL – VERBRUIKSPATROON ......................................................................................... 59 APPENDIX 8: ELECTRABEL – NACE CODE ......................................................................................................... 59 APPENDIX 9: ELECTRABEL – SOCIAAL TARIEF .................................................................................................. 59 APPENDIX 10: ELECTRABEL – VERHUIS – SCHATTINGEN ................................................................................. 59 APPENDIX 11: ELECTRABEL – VERHUIS – CONTRACTLOZE PERIODE ................................................................ 59 APPENDIX 12: ELECTRABEL – VERHUISPROBLEMATIEK................................................................................... 59 APPENDIX 13: EANDIS – CONTRACTLOZE LEVERINGEN ................................................................................... 59 APPENDIX 14: CHECKLIST WT2-OP.................................................................................................................. 59


4

1. Introductie Werktraject 2 – Marktrollen maakt deel uit van de studie Marktmodel die onder impuls van de Vreg (de Vlaamse Reguleringsinstantie voor de Elektriciteits- en Gasmarkt) wordt uitgevoerd. De algemene doelstelling van de studie wordt als volgt geformuleerd (Bron: Discussiedocument – Ontwikkeling van een visie op een marktmodel voor de Vlaamse energiemarkt, Vreg, 2006):

“Het ontwikkelen van een marktmodel dat tegemoet komt aan de eisen van de stakeholders in de veranderende energiemarkt en het uitstippelen van een route naar dit marktmodel toe. De klant staat hierin centraal en wordt op een efficiënte manier bediend door de markt, waarin partijen eerlijk met elkaar kunnen concurreren en worden gefaciliteerd door een efficiënte marktomgeving waarbij juiste en tijdige informatievoorziening centraal staat”.

De studie Marktmodel werd door de Vreg in het leven geroepen als reactie op verschillende signalen dat de werking van de vrijgemaakte Vlaamse energiemarkt te wensen overliet, zowel in termen van effectiviteit (churn-rate, doorlooptijden van processen, …) als efficiëntie (cost-toserve, kosten van toezicht, …). In 2006 heeft de Vreg in een eerste fase een uitgebreide analyse gemaakt van de marktwerking. Uit deze analyse kwamen verschillende clusters van knelpunten naar voor (Bron: Discussiedocument – Ontwikkeling van een visie op een marktmodel voor de Vlaamse energiemarkt, Vreg, 2006, p.10).

Na de eerste fase konden de bedrijven uit de energiesector reageren op de vaststellingen. Op basis van deze reacties richtte de Vreg een advies aan toenmalig Vlaams minister van energie Kris Peeters. De minister droeg de Vreg op de studie verder te zetten in samenwerking met de energiesector, die zich hierin moest engageren. In oktober 2007 startte de tweede fase, aangestuurd door een Project Comité en praktisch uitgevoerd in 4 werktrajecten (Ref: Stand van zaken studie Marktmodel, Vreg, 2008).


5

2. Doelstellingen, scope en plan van aanpak

2.1. Doelstellingen WT2 WT2 werd opgestart om een oplossing voor de belangrijkste geïnventariseerde problemen te formuleren. Dit werktraject is erop gericht om overal waar nog onduidelijkheid of ambiguïteit blijkt uit het bestaande model, bijvoorbeeld waar de marktrollen nog niet duidelijk genoeg gedefinieerd zijn of waar nog verschillende mogelijkheden geboden worden voor eenzelfde actie/rol, deze weg te werken door een op marktniveau efficiënte oplossing te zoeken (Ref: Stand van zaken studie Marktmodel, Vreg, 2008).

De doelstellingen van WT2 zijn de volgende (Bron: Omschrijving opdracht externe deskundige Fase 1bis studie Marktmodel, Vreg): •

Formuleren van voorstellen om de bestaande marktprocessen te verbeteren en te vereenvoudigen.

•

Onduidelijkheden en ambiguïteiten in het huidige marktmodel wegwerken door een oplossing te kiezen die de efficiëntie op marktniveau optimaliseert.

•

In overleg met de marktpartijen het huidige marktmodel eenvoudiger en efficiënter maken op macro-economisch niveau.

•

Hierbij wordt gestreefd naar een daling van de kosten, die zich finaal zou moeten vertalen in een verlaging van de prijs die wordt aangerekend aan de eindafnemers.

Met het oog op bovenstaande doelstellingen heeft het Project Comité beslist om WT2 te ontdubbelen in WT2–Strategisch (WT2–ST) en WT2–Operationeel (WT2–OP). WT2–ST is een strategisch langetermijnproject, gericht op het ontwikkelen van een gemeenschappelijke visie op een toekomstig marktmodel. WT2–OP is een operationeel project op korte tot middellange termijn, gericht op het vinden van oplossingen voor de tussenperiode om een aantal knelpunten binnen het huidige marktmodel alsnog recht te trekken. Ook wat de graad van detail betreft, focust WT2-OP op een niveau dat zich situeert tussen strategie en dagdagelijkse praktijk. Op deze manier kunnen zowel strategische verbeteringen op lange termijn als meer operationele verbeteringen op korte en middellange termijn aan bod komen (Ref: Notulen WT2-OP Sessie 1).


6

WT2-ST behelst drie sessies met de CEO’s van de verschillende marktpartijen. WT2-OP omvat zes sessies met afgevaardigden van alle partijen. Om de interactie tussen beiden optimaal te laten verlopen, werden de deelnemers van WT2–OP aan volgende profielbeschrijving geacht te voldoen (Bron: Omschrijving opdracht externe deskundige Fase 1bis studie Marktmodel, Vreg):

“De inbreng van informatie voor de uitvoering van dit werktraject dient te gebeuren door mensen met een strategisch – operationele rol, die inzicht hebben in de bedrijfsprocessen binnen hun eigen organisatie en de wijze waarop deze interageren met de processen van de andere marktpartijen.”

WT2--OP 2.2. Scope WT2 In WT2–OP werden uitsluitend operationele onderwerpen behandeld die een impact hebben op de marktrollen. WT2–OP legde zich specifiek toe op de volgende twee onderwerpen: •

Toegang tot informatie: In dit traject werd herbekeken wie over welke informatie beschikt, wie het aan welke informatie ontbreekt en hoe de informatie-uitwisseling in functie daarvan georganiseerd kan worden op korte en middellange termijn.

•

Ontbrekende meetgegevens en contractloze levering: In dit traject kwamen vooral het verhuisproces en andere betrokken processen aan bod, zoals customer en combined switch en MOZA. Hieraan gerelateerde ‘governance issues’ konden eveneens worden aangekaart. Tijdens de eerste sessie van WT2–ST werden ‘governance issues’ gedefinieerd als inefficiënties waarvan de oorzaak niet technisch of operationeel van aard is, maar die hun oorsprong vinden in de geldende wetgeving (Ref: Notulen WT2-OP Sessie 1, p.2).

De keuze voor bovenstaande onderwerpen is tot stand gekomen in onderling overleg tussen de Vreg en de verschillende marktpartijen, vanuit het opzet pragmatisch en probleemoplossend te willen nadenken en niet academisch–theoretisch. Men heeft voorrang gegeven aan probleemgebieden waarvoor elders nog geen initiatieven lopende zijn, tenzij daar waar WT2-OP een meerwaarde kan bieden door het probleem in een ruimere context te bekijken. Een


7

bijkomende reden voor deze onderwerpkeuze was dat men tijdens de discussies van WT3 inhoudelijk een zijsprong had gemaakt van data-analyse naar data-interactie in processen. Omdat WT3 daardoor inhoudelijk parallel was komen te liggen met WT1, heeft de Vreg voorgesteld deze trajecten samen te behandelen en inhoudelijk te bundelen in WT2-OP (Ref: Notulen WT2-OP Sessie 1.doc).

In WT2–OP werden de resultaten van de voorgaande werktrajecten WT1 - Marktmodel en WT3 Data Cleansing gebruikt als input om de complementariteit ervan te benutten. De extra dimensie die WT2-OP aan voorgaande trajecten toevoegde, was het bekijken van de mogelijke problemen in een bredere context van de marktrollen. De discussies van WT1 en WT3 vonden plaats binnen het kader van de bestaande marktrollen, terwijl in WT2 de marktrollen zelf in vraag werden gesteld (Ref: Notulen WT2-OP Sessie 1, p.3

2.3 2.3. Plan van aanpak De concrete werkwijze bestond erin om voor de knelpunten verbeteringsinitiatieven te identificeren, de krijtlijnen ervan uit te tekenen en aanbevelingen tot doorverwijzing naar de geschikte fora te formuleren. Umix wordt verwacht hierin een belangrijke rol te spelen. WT2-OP was het geschikte forum om de eerste discussies te voeren en de krijtlijnen uit te tekenen voor initiatieven die het niveau en de bevoegdheden van Umix overschrijden. Vervolgens kon WT2OP voorstellen om bepaalde pistes door te verwijzen naar Umix, dat beter geplaatst is om deze grondig te onderzoeken en uitsluitsel te geven over de haalbaarheid ervan (Ref: Notulen WT2-OP Sessie 1).

Bij de aanvang van WT2–OP werd overeengekomen dat verbeteringsinitiatieven die voldoen aan de volgende criteria de voorkeur wegdragen: 1. De return on investment is positief op korte of middellange termijn, d.w.z. een vijf- tot zevental jaren. Dit impliceert dat de realisatie van het initiatief binnen de huidige governance structuren zal plaatsvinden, gezien wijzigingen van het governance model


8

binnen de huidige politieke legislatuur niet realistisch worden geacht (Ref: Notulen WT2OP Sessie 1). 2. De return on investment is positief op marktniveau. Het opzet van WT2–OP is het aankaarten van marktinefficiënties op een niveau dat de individuele spelers overstijgt. Investering en return van de verbeteringsinitiatieven situeren zich hierbij niet noodzakelijk binnen eenzelfde marktpartij. De deelnemers van WT2–OP hebben zich allen bereid verklaard om kosten en baten af te wegen op het niveau van de hele markt (Ref: Notulen WT2-OP Sessie 2, p.7).

In WT2-OP werd geopteerd voor een gefaseerde aanpak, waarbij aan zowel ‘Toegang tot informatie’ als ‘Ontbrekende meetgegevens en contractloze leveringen’

drie sessies werden

gewijd: een eerste sessie voor het afbakenen van de scope en probleemanalyse, een tweede sessie voor de bespreking van mogelijke oplossingen en een derde sessie om een conclusie te formuleren. Schematisch ziet dit plan van aanpak er als volgt uit:

Plan van aanpak

Topic 1 – Toegang tot informatie

Topic 2 – Ontbrekende meetgegevens en contractloze levering

Afbeelding 1: Plan van aanpak WT2 – OP


9

3. Management samenvatting samenvatting De uitgevoerde analyse binnen WT2-OP leidde tot een oplijsting van knelpunten betreffende (1) ‘Toegang tot informatie’ en (2) ‘Ontbrekende meetgegevens en contractloze leveringen’ die door de markt prioritair werden bevonden. De knelpunten werden vervolgens geanalyseerd en voorstellen tot oplossing werden ontwikkeld.

3.1. 3.1. Toegang tot informatie In dit traject werd herbekeken wie over welke informatie beschikt, wie het aan welke informatie ontbreekt en hoe de informatie-uitwisseling in functie daarvan georganiseerd kan worden op korte tot middellange termijn.

Een eerste knelpunt was de behoefte aan een unieke identificatie van de klant. Het gebruik van klantgebonden informatie in de procesvoering verloopt momenteel zeer moeizaam, wat zich op marktniveau vertaalt in hogere kosten en inconsequente toepassing van de regelgeving. Een onbeperkte toegang tot het rijksregister en de kruispuntdatabank van de sociale zekerheid zou de benodigde unieke klantidentificatie mogelijk maken.

In WT2-OP werd besloten dat dit punt wordt opgenomen als een nieuw governance issue dat naar de Vreg zal toekomen. De Vreg zal namens de sector een aanvraag indienen bij de Privacy Commissie om toegang te krijgen tot het rijksregister. Belangrijk is in het dossier kenbaar te maken dat de motivatie voor de aanvraag een betere toepassing van de SODV’s is. WT2-OP stelt voor dat het voorbereidend werk kan worden uitgevoerd door Umix.

Een tweede knelpunt was de onduidelijkheid rond het contactadres. Bij gebrek aan een geschikt contactadres komen meterkaartjes te vaak onbesteld terug, waardoor verbruiken geschat moeten worden door de DNB. Dit geeft aanleiding tot tal van marktinefficiënties, waaronder validatieproblemen, klachten van klanten die hun factuur betwisten en het opstarten van rectificatieprocedures.


10

In WT2-OP werd beoogd meer klaarheid te scheppen door een definitie van het contactadres vast te leggen en een duidelijke owner aan te wijzen. Het contactadres werd unaniem gedefinieerd als het adres waarnaar het meterkaartje verstuurd moet worden. Over een geschikte owner voor het contactadres bleek er echter geen consensus te zijn in de markt. Om alsnog op korte tot middellange termijn actie te ondernemen, werd in WT2-OP het volgende besloten: • Er zal bilateraal overleg plaatsvinden tussen de marktspelers. Dit laat toe een analyse te maken rond onbestelbare meterkaartjes en in een eerste fase foute contactadressen uit het verleden te elimineren. • Aanbeveling om dit knelpunt door te verwijzen naar Umix Monitoring, dat op middellange termijn een diepere analyse kan maken. Mogelijk levert dit nieuwe pistes op om incrementele procesverbeteringen te realiseren. De resultaten van het bilateraal overleg kunnen hierbij als input dienen: men kan aftoetsen in hoeverre de maatoplossingen die het bilateraal overleg heeft opgeleverd als best practice voor heel de markt kunnen worden beschouwd. • Op lange termijn – 2012 werd als tijdshorizon genoemd - kan dit probleem opgelost worden door de ontwikkeling van een nieuw datamodel voor de sector, waarbij mogelijks alle adresdefinities en bijbehorende rollen en verantwoordelijkheden worden herzien en verdere klaarheid wordt geschept over het ownership van data en processen.

Een derde knelpunt betrof de gebrekkige informatiebeschikbaarheid. Zowel leveranciers als netbeheerders rapporteren de nood aan een uitgebreidere toegang tot elkaars systemen. Bovendien is de bestaande toegang tot de systemen van de netbeheerders onvoldoende geharmoniseerd. De ontwikkeling van een uniforme en uitgebreide online – dus onmiddellijke - gegevenstoegang zou een snellere en efficiëntere klachtenbehandeling mogelijk maken.

In WT2-OP werd daartoe van zowel leveranciers als netbeheerders een principieel akkoord verkregen om op korte tot middellange termijn toegang te verschaffen tot UMIG-gerelateerde gegevens, d.w.z. alle gegevens die momenteel al via de UMIG circuleren. In eerste instantie zal de toegang tot de UMIG-gerelateerde gegevens een bilaterale één – op - één toegang zijn. De


11

marktpartijen waren akkoord dat een centrale interface geen prioriteit is en dat op korte termijn een aparte gegevenstoegang kan volstaan. Wel zal van meet af aan een gemeenschappelijke look– en–feel interface voor alle partijen worden nagestreefd.

Op lange termijn raadt WT2-OP aan om deze piste te koppelen aan de oprichting van een gemeenschappelijk dataportaal. In verschillende Europese landen worden dergelijke portalen opgezet, waaronder Zweden, Noorwegen en de UK. Een dataportaal zou een duidelijke meerwaarde

bieden in de vorm van een betere datakwaliteit en een daling van het aantal

rectificaties, zonder dat fundamenteel in de systemen moet worden ingegrepen. De Vreg heeft voorgesteld om voorbeelden uit verschillende landen te verzamelen en te documenteren. Deze informatie kan aan bv. het Marktforum worden voorgelegd om een project op marktniveau te lanceren.

Een vierde knelpunt was het problematische dataveld res/nres. Dit veld wordt momenteel gebruikt voor verschillende doeleinden, wat een nauwkeurige bepaling van het verbruikspatroon in de weg staat. Dit veroorzaakt uiteenlopende problemen, waaronder foute bepalingen van forfaits en SLP’s, verkeerde schattingen van meterstanden en verbruikspatronen en klachten van eindgebruikers. Verder bemoeilijkt het een correcte toepassing van SODV’s.

WT2-OP doet de aanbeveling dit knelpunt door te verwijzen naar Umix, aangezien Umix dit probleem in het verleden al heeft geanalyseerd. Men kan verifiëren in hoeverre deze analyse nog bruikbaar of relevant is. Indien blijkt dat de omstandigheden inmiddels sterk gewijzigd zijn, is het mogelijk nuttig de analyse te updaten met nieuwe elementen of volledig opnieuw te doen.

De problematiek rond NACE codes was een vijfde knelpunt. Jaarlijks stellen de DNB’s vast dat de kwaliteit van dit gegevenselement te wensen overlaat: een groot aantal codes ontbreekt, is incorrect of er treden grote verschillen met vorige rapporteringen op. Hierdoor verloopt de rapportering zeer inefficiënt, moeten regelmatig data cleanings worden uitgevoerd en bestaat het risico dat op beleidsniveau de verkeerde conclusies worden getrokken.


12

In WT2-OP werd vastgesteld dat er wel een consensus is over de probleemstelling, maar niet over een mogelijke oplossing. Men is het unaniem eens dat dit een probleem van data ownership is en dat een partij moet worden aangeduid die de verantwoordelijkheid voor de NACE code op zich neemt. Het VEA werd benaderd om over dit probleem overleg te plegen met de marktspelers. In de nabije toekomst - een precieze datum zal nog worden meegedeeld - zal een marktoverleg plaatsvinden tussen het VEA, de netbeheerders en de leveranciers. De namen van de afgevaardigden werden al bevestigd aan het VEA.

Een zesde knelpunt betrof de toekenning van het sociaal tarief. Wanneer de klant van leverancier verandert, wordt de nieuwe leverancier momenteel niet op de hoogte gebracht van het feit of de klant al dan niet recht heeft op het sociaal tarief. Vanaf 1 januari 2010 zullen eindgebruikers bovendien automatisch het sociaal tarief genieten vanaf de eerste dag dat zij daar recht op hebben. De nieuwe werkwijze zal erin bestaan dat de leverancier zijn databank dropt bij de FOD Economie, die een matching zal doen met de gegevens van de kruispuntdatabank en op basis hiervan zal aanduiden welke klanten recht hebben op sociaal tarief. De leverancier dient vervolgens deze gegevens te integreren in zijn facturatiesysteem.

In WT2-OP werden voor dit probleem geen quick wins geïdentificeerd. Door recente ontwikkelingen in de energiewetgeving zijn de marktspelers inmiddels aan nieuwe verplichtingen onderhevig.

Volgens de leveranciers is het aangewezen dat de sector een duidelijk standpunt inneemt en aangeeft of men verkiest om (a) de informatie die vanuit de overheid wordt gevraagd bij de leverancier te droppen, dan wel (b) de overheid te adviseren alle gevraagde informatie zelf te beheren en te coördineren. Indien men hierover een consensus kan bereiken, kan volgens de leveranciers een krachtig signaal worden gegeven naar de overheid toe.


13

Het laatste agendapunt was de behoefte aan uniformisering en standaardisatie van adresgegevens In WT2-OP werd geconfirmeerd dat Umix Structuring zich met dit probleem bezighoudt en werd beslist om hier in WT2-OP aldus niet verder op in te gaan.

3.2. meetgegevens 3.2. Ontbrekende meetge gevens en contractloze levering In het tweede traject van WT2-OP stond de verhuisproblematiek centraal. In dit traject kwamen vooral het verhuisproces en andere betrokken processen aan bod, zoals customer en combined switch en MOZA. De volgende knelpunten werden prioritair bevonden: •

Herschattingen van verbruiken en indexen in het kader van verhuis.

•

Verbruiksverlies tijdens de contractloze periode. Dit werd gelinkt aan de recuperatie van indexen van de vertrekkende klant in het MOZA proces.

Voor de probleemcluster verhuis, contractloze levering en MOZA werden in WT2-OP geen quick wins geïdentificeerd op marktniveau. De voorstellen tot oplossing die op tafel liggen hebben een te lange tijdshorizon om als quick win te kunnen worden beschouwd of vergen een wijziging van de bestaande wetgeving. Wel werd in WT2-OP een akkoord bereikt tussen de marktspelers over de volgende punten: •

Deze problematiek wordt als nieuw governance issue opgenomen voor de Vreg. De Vreg zal informeren in hoeverre men de plichten en verantwoordelijkheden van de huiseigenaar kan verankeren in de wetgeving om tussentijdse verbruiken aan de eigenaar te kunnen aanrekenen.

•

Aanbeveling om deze problematiek en haar oplossingen – in de vorm van mogelijk gewijzigde rollen en verantwoordelijkheden en aangepaste UMIG scenario’s - te koppelen aan de ontwikkeling van een nieuw datamodel voor de sector met 2012 als tijdshorizon.

Tenslotte waren alle partijen akkoord dat de problematiek van Mystery Switches geen prioriteit is, omdat dit via bilateraal overleg kan worden opgelost.


14

3.3. 3.3. Input WT1 en WT3 Tijdens de laatste sessie werd nagegaan of er eventueel openstaande punten uit WT1 of WT3 rechtstreeks naar het Project Comité konden doorvloeien, zonder expliciet in WT2-OP aan bod te zijn gekomen. Het opzet was de resultaten van deze werktrajecten maximaal te benutten en geen bruikbare voorstellen verloren te laten gaan. Met betrekking tot verhuis doet WT2-OP de aanbeveling om de volgende scenario’s uit WT3 gegroepeerd door te verwijzen naar Umix voor verdere analyse: •

Scenario 1 - Bijkomende informatie voor validatie: toevoeging van een gecodeerde reden aan de berichtuitwisseling waarom een index normaliter in orde zou moeten zijn. In functie daarvan kan de DNB grotere of kleinere validatiemarges toelaten. Volgens Umix kan dit scenario zeker als een quick win worden beschouwd en was hierover weinig discussie binnen WT3.

•

Scenario 2 – Hercalibratie en monitoring 60-dagen regel: uitbreiding van de customer switch van 60 naar 90 dagen in het verleden. Dit laat de leveranciers toe meer te automatiseren en asynchroniteit tussen index en datum te vermijden. In WT3 werd voorgesteld dit scenario gedurende 1 jaar proef te draaien in testpiloot, bij voorkeur op federaal niveau. Om echter niet te overhaast te werk te gaan, zal hieraan eerst een analyse voorafgaan waarbij de voor- en nadelen worden afgewogen.

•

Aanpassing MOZA document: opname van de index van de vertrekkende klant op het MOZA formulier. Aangezien de nieuwe klant de keuze heeft om de vertrekindex te verwerpen, houdt dit voorstel volgens de leveranciers geen grote risico’s in.

3.4. 3.4. Conclusie De uitvoering van de werkzaamheden in WT2-OP heeft het inzicht doen groeien dat het aantal potentiële quick wins momenteel eerder beperkt is. Naarmate het werktraject vorderde, werd steeds meer duidelijk dat het huidige marktmodel weinig ruimte biedt om operationele verbeteringen te realiseren met een positieve return op korte tot middellange termijn.


15

Hoewel de concrete uitkomst van WT2-OP dus eerder bescheiden is, heeft deze oefening wel het inzicht opgeleverd dat om wezenlijke verbeteringen te realiseren enkel een grondige herziening van het marktmodel soelaas kan bieden. Er was een algemene consensus tussen de partijen dat op lange termijn het marktmodel moet worden heropgebouwd, waarbij vanuit een top – down benadering alle processen, datavelden, rollen en verantwoordelijkheden volledig in kaart worden gebracht en vervolgens eenduidig worden vastgelegd. Dit is een werk van lange adem, dat de grenzen van WT2-OP ruimschoots overstijgt en een langetermijnperspectief vereist. We verwijzen daarom naar de discussies over een toekomstig marktmodel die gevoerd werden binnen WT2-ST.

De hierna volgende hoofdstukken bieden een gedetailleerd overzicht van de behandelde punten en de respectievelijke conclusies van WT2-OP.


16

4. Toegang tot informatie

4.1. Identificatie van de knelpunten Tijdens de eerste sessie van WT2-OP werd een eerste ruwe oplijsting gemaakt van probleemgebieden die binnen de scope van WT2-OP vallen en door de markt als prioritair worden ervaren. Een selectie van openstaande punten uit WT1 en WT3 werd hiervoor als vertrekbasis genomen. Tijdens een brainstormsessie konden de partijen dit aanvullen met concrete probleme waarvan zij vermoedden dat er op korte tot middellange termijn een oplossing voor te vinden zou zijn – of tenminste vooruitgang worden geboekt (Ref: Notulen WT2-OP Sessie 1, p.4). Deze aanpak leverde bij aanvang van WT2-OP de volgende probleemgebieden op (Ref: Notulen WT2-OP Sessie 1, p.9): 1. Data ownership 2. Concrete datagerelateerde problemen 3. Consulteerbaarheid 4. Uniformisering en standaardisatie van data en systemen

1.1.. Probleemgebieden 4.1.1 1. Data ownership •

Vanuit de “as is” situatie de ideale “to be” situatie definiëren en hoe deze te bereiken.

•

Oplijsten van alle problematische datavelden, zoals de NACE code en het veld res/niet-res.

•

Analyseren welke gegevens momenteel ontbreken en bepalen van mogelijke IT– oplossingen hiervoor. Dit kunnen structurele oplossingen zijn, zoals: o

Een link tot stand brengen met een kruispuntdatabank of een gemeentelijke databank. Dit schept mogelijkheden voor automatisering van processen, bijvoorbeeld automatische wijziging van de klantnaam bij een verhuis.

o

Oprichten van een gemeenschappelijke adressendatabank of van een clearing house.

o

Daarnaast komen – hoewel suboptimaal – ook minder structurele ‘work around’ oplossingen in aanmerking, op voorwaarde dat er op korte of middellange termijn een positieve return is op marktniveau en deze investeringen dus niet verloren zijn.


17

•

In lijn brengen van het proces van data-uitwisseling met de Europese wetgeving en de achterliggende EDI – filosofie. België werd door EBIX1 berispt wegens het foutief toepassen van rectificatieberichten: deze worden slechts verstuurd wanneer na validatie blijkt dat in het verleden foutieve data werden ontvangen. Conformiteit met de Europese wetgeving vereist echter onmiddellijke validatie van data bij ontvangst.

2. Concrete datagerelateerde problemen •

Netgebruikeridentificatie (Ref: Notulen WT2-OP Sessie 1): een openliggende piste uit WT3 is unieke identificatie van de netgebruiker. Er werd voorgesteld om een nieuw dataelement te introduceren dat toelaat de netgebruiker eenduidig te identificeren. Mogelijke nieuwe data-elementen die werden genoemd zijn het ondernemingsnummer, het rijksregisternummer (RRN) of de verblijfsvergunning.

•

Uniformisering van adressen en gebruik van een centraal adressendatabestand: in WT3 werd

geconcludeerd

dat

unieke

klantidentificatie

aan

de

hand

van

het

ondernemingsnummer, het rijksregisternummer of de verblijfsvergunning misschien wel wenselijk maar niet altijd mogelijk is. Standaardisatie van de adresgegevens lijkt daarom eveneens aangewezen. Momenteel zijn er meerdere adresvelden beschikbaar maar deze zijn niet eenduidig gedefinieerd. Men dient eerst te verduidelijken welk adres in welk scenario wordt meegegeven (Ref: Notulen WT2-OP Sessie 1). •

Verrijking van de inhoud van de metercertificaten die in de masterdata worden meegegeven (Ref: Notulen WT2-OP Sessie 1, p.6): Hiermee wensen de leveranciers gegevens te kunnen verifiëren bij de bron, zodat vragen over de plausibiliteit van meetgegevens efficiënt geanalyseerd kunnen worden voor de facturatie. Vaak is de informatie waarop de leveranciers steunen uitsluitend afkomstig van de DNB’s, vandaar het belang om hierin inzicht te verwerven.

1

Noot UMIX; EbIX zal de rectificatieprocessen zoals in Belgie gebruikt niet opnemen in haar standaarden. De optie die vanuit EDIFACT oogpunt is voorgesteld is APERAK. Bij aanvang van de vrijmaking werd deze keuze door de Belgische markactoren echter niet weerhouden gezien men niet was overtuigd van de baten.


18

•

Informatie-uitwisseling

betreffende

de

uitvoering

van

sociale

openbare

dienstverplichtingen (SODV’s), met name de toekenning van het sociaal tarief en de gratis kWh.

3. Consulteerbaarheid •

Bepalen welke data de leveranciers in de systemen van de DNB’s wensen te consulteren, en omgekeerd, op welke data de DNB’s zicht wensen te hebben in de systemen van de leveranciers. De leveranciers zijn vragende partij om de informatiebeschikbaarheid te verhogen zodat zij assetgegevens kunnen consulteren, klanten identificeren en de status van het access register en het proces bevragen (Ref: Notulen WT2-OP Sessie 1). De DNB’s zijn vragende partij om zicht te krijgen op onder meer de status EAN.

•

Een tweede stap is het identificeren van mogelijke IT-oplossingen om dit te bereiken. Een openliggende piste uit WT3 is het voorstel om extra functionaliteiten te voorzien die de informatiebeschikbaarheid verhogen. Technisch gezien zijn er twee trajecten: (1) een verdere ontwikkeling van de bestaande architectuur, (2) of de ontwikkeling van fundamenteel nieuwe structuren. Vooraleer men een keuze kan maken over het meest wenselijke traject, is eerst input van WT2-ST nodig (Ref: Notulen WT2-OP Sessie 1).

4. Uniformisering en standaardisatie van data en systemen Er is nood aan algemene uniformisering en harmonisatie van data en systemen, niet enkel van de adresvelden. WT2-OP is het geschikte forum om uniformisering en standaardisatie aan te kaarten. Alle aspecten betreffende harmonisatie worden, omwille van de tijdshorizon, in WT2-ST besproken.

1.2.. Concretisering 4.1.2 De geïdentificeerde probleemgebieden vervolgens uitgekristalliseerd in concrete knelpunten binnen de scope van WT2-OP, zoals weergegeven in de tabel hieronder:


19

1. Data ownership • Ownership over het contactadres

• Zie paragraaf 4.2.2.

• Res/niet-res en reëel verbruikspatroon


• Het veld NACE code


• Onbeperkte toegang tot officiële databestanden


• Standaardisatie

• Wordt behandeld in Umix Structuring.



• Toegang tot netgebruikergegevens


Uniformisering en standaardisatie van adressen.

• Uniformisering en standaardisatie van adressen.


Verrijking van inhoud metercertificaten die in de masterdata worden meegegeven.





• Toekenning sociaal tarief




Oplijsten van alle problematische datavelden, zoals NACE code en het veld res/niet-res.

Analyseren welke gegevens momenteel ontbreken en bepalen van mogelijke IT– oplossingen. Conformiteit met Europese wetgeving inzake data-uitwisseling (onmiddellijke validatie bij ontvangst).

2. Concrete datagerelateerde problemen

Netgebruikeridentificatie

Informatie-uitwisseling betreffende SODV’s.

3. Consulteerbaarheid Bepalen welke data men wenst te consulteren en identificeren van mogelijke IT oplossingen.

4. Uniformiseren en standaardiseren van data en systemen Algemene nood aan uniformisering en standaardisatie van data en systemen.

• Uniformisering en standaardisatie van adressen.



20

• Harmonisatie

• Wordt behandeld in WT2-ST.

4.2. Behandeling van de knelpunten De partijen werden verzocht een probleem- en oplossingenanalyse te maken van de opgelijste knelpunten. Om de consistentie tussen de verschillende analyses te bewaren werd een template ter beschikking gesteld. De partijen dienden hun analyse van het probleem uiteen te zetten aan de hand van de volgende vragen: •

Wat? (data met de grootste problemen, ontbrekende data, …)

•

Waar? (in welke processen, op welk moment)

•

Wie? (onduidelijkheden in rollen en verantwoordelijkheden, eigenaar data element, read/write, …)

•

Hoe? (gebrekkige/geen toegang, tijdigheid, functionaliteit, …)

Dit leverde een corresponderende lijst van mogelijke oplossingen op. Deze kunnen in Appendices 1 t.e.m.9 gevonden worden. Hieronder bespreken we voor elk knelpunt de probleemstelling, de voorgestelde oplossing(en) en de conclusie.

.1.. Onbeperkte toegang tot officiële databestanden 4.2.1 4.2.1.1. Probleemstelling Het gebruik van klantnamen bij het voeren van processen in de energie- en gasmarkt is zeer foutgevoelig. De reden hiervoor is dat de marktprocessen, vooral diegene tussen leverancier en netbeheerder, opgebouwd zijn rond toegangspunten (aangeduid met een unieke EAN code) en niet rond netgebruikers. Tot op heden is er in de markt geen unieke identificatie van de netgebruiker mogelijk.

Het gebrek aan unieke identificatie van de klant bemoeilijkt het inwinnen en beheren van klantgebonden informatie, waaronder (Ref: Appendix 2: SPE - Probleemanalyse toegang tot officiële databestanden.doc): Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

21

•

Domicilie: heeft de klant zijn domicilie op het adres waar hij elektriciteit of gas afneemt, of op een ander adres? Dit gegevenselement wordt onder meer gebruikt bij de toepassing van de procedure voor wanbetaling.

•

Toepassing van SODV’s: komt de klant in aanmerking voor bepaalde gunstmaatregelen, zoals toekenning van het sociaal tarief of van gratis kWh?

Momenteel moeten dergelijke klantgerelateerde gegevens steeds (1) rechtstreeks bij de klant worden verkregen of (2) bij derde partijen, zoals overheidsinstanties, worden ingewonnen.

De bestaande marktprocessen voor het inwinnen en beheren van klantgebonden informatie zijn zeer foutgevoelig en administratief belastend voor alle partijen, inclusief de klant zelf. Aangezien de basisprocessen al moeizaam verlopen, treden er nog meer problemen op in de rectificatieprocessen die fouten moeten corrigeren. Op marktniveau vertaalt dit zich in (1) hogere kosten en (2) inconsequente toepassing van de regelgeving, aangezien niet elke klant de bescherming of gunstmaatregel geniet waar hij wettelijk recht op heeft (Ref: Appendix 2: SPE Probleemanalyse toegang tot officiële databestanden.doc).

4.2.1.2. Voorgestelde oplossing Informatie zoals domicilie, recht op specifieke steun van een overheidsinstantie, recht op bescherming etc. wordt bijgehouden in officiële databronnen: •

het rijksregister van de natuurlijke personen en

•

de kruispuntbank van de sociale zekerheid.

Deze zijn opgericht met het oog op een vlotte, efficiënte en doelmatige dienstverlening aan de burger. Een mogelijke oplossing bestaat erin de sector een onbeperkte toegang tot deze officiële databronnen te verschaffen.

Momenteel beschikken de DNB’s enkel over een beperkte, inefficiënte of helemaal geen toegang tot officiële databronnen. Netbeheerder Eandis bijvoorbeeld, heeft momenteel: •

Beperkte toegang tot de kruispuntdatabank. Voor een specifiek segment van netgebruikers, de beschermde afnemers die zelf contact opnemen, beschikt Eandis over de


22

mogelijkheid het RRN te consulteren voor verificatiedoeleinden. Het is echter niet mogelijk om bijvoorbeeld een lijst op te vragen met het RRN van alle beschermde afnemers (Ref: Notulen WT2-OP Sessie 4, p.4). •

Toegang tot het kadaster, maar enkel op adresniveau. Wanneer adresgegevens niet matchen, ontvangt Eandis met andere woorden geen informatie uit het kadaster (Ref: Probleemanalyse toegang tot informatie – Eandis – v1.doc). Het kadaster is belangrijk voor de processen rond zowel MOZA als verhuis indien de afnemer van het aansluitingspunt niet gekend is (Ref: Notulen WT2-OP Sessie 3.doc, p.2)

Een onbeperkte toegang tot officiële databronnen zou unieke klantidentificatie mogelijk maken voor verschillende categorieën van netgebruikers: •

Rijksregisternummer (RRN) voor huishoudelijke netgebruikers. Deze piste vereist echter

nog

verdere

analyse

voor

wat

betreft

buitenlanders,

tijdelijke

verblijfsvergunningen, etc. •

Ondernemingsnummer voor niet-huishoudelijke netgebruikers.

Het gebruik van het RRN in de informatie-uitwisseling tussen leveranciers laat toe om snel en efficiënt op te zoeken of een klant al dan niet in aanmerking komt voor toepassing van een SODV. Bij uitbreiding kan het RRN gebruikt worden in het voorkomen en oplossen van problematische verhuizen (Ref: Appendix 2: SPE - Probleemanalyse toegang tot officiële databestanden.doc).

De realisatie van dit voorstel moet gefaciliteerd worden door de overheid. Als aan de energiebedrijven SODV’s worden opgelegd die steunen op informatie beheerd in de kruispuntbank, is het volgens de leveranciers niet meer dan logisch dat men ook beroep kan doen op de mogelijkheden die het rijksregister en de kruispuntbank bieden. We onderscheiden twee mogelijkheden (Ref: Appendix 2: SPE - Probleemanalyse toegang tot officiële databestanden.doc): 1. De machtiging krijgen om het rijksregisternummer (RRN) te gebruiken. Het RRN is de unieke identificatie van een natuurlijk persoon en wordt gebruikt in zowel het rijksregister als de kruispuntbank.


23

2. Toegang bekomen tot het rijksregister, de kruispuntbank en de gegevens in deze registers. Toegang tot het rijksregister impliceert ook toegang tot privégegevens in het register. Het is daarom gevoeliger dan het recht het nummer te gebruiken. De partijen zijn het eens dat deze twee mogelijkheden elkaar niet uitsluiten, maar complementair zijn. Idealiter kunnen ze gecombineerd worden (Ref: Notulen WT2-OP Sessie 4, p.3).

Voor bedrijven uit de private sector zijn hierop echter sterke beperkingen van toepassing. Zij krijgen enkel toegang indien dit nodig is voor het vervullen van (1) taken van algemeen belang die hen wettelijk zijn toevertrouwd of (2) taken die uitdrukkelijk als zodanig erkend worden door het sectoraal comité van de Privacy Commissie. Voor commerciële bedrijven is het daarom belangrijk om aan te tonen dat het gebruik van het RRN ten dienste zal staan van het algemeen belang.

Om het RRN te mogen gebruiken, moeten bedrijven bovendien de netwerkverbindingen vermelden die hieruit voortvloeien. Het doel van deze verplichting is de publicatie van een kadaster van de netwerkverbindingen mogelijk te maken.

Ondanks de strenge beperkingen zijn er verschillende private (nuts)bedrijven die toegang hebben verkregen tot het register of de kruispuntdatabank of gemachtigd zijn het RRN te gebruiken (Ref: Appendix 2: SPE - Probleemanalyse toegang tot officiële databestanden.doc): •

Telecombedrijven zoals Belgacom en Mobistar hebben via het BIPT (Belgisch Instituut voor Postdiensten en Telecommunicatie) toegang tot de kruispuntdatabank van de sociale zekerheid in het kader van de toekenning van sociale tarieven.

•

Banken nemen kopijen van identificatiebewijzen van hun klanten waarop het RRN wordt vermeld.

•

De watermaatschappijen vragen het RRN van hun afnemers voor de toekenning van een hoeveelheid gratis water.

•

Mutualiteiten/ziekenfondsen gebruiken eveneens het RRN, zelfs als klantnummer.

•

Vakbonden.


24

Deze precedenten scheppen volgens de marktpartijen een opening om dit ook in de energiesector mogelijk te maken. De kans op een gunstige beslissing zal groter zijn indien het RRN uitsluitend wordt gebruikt in de relatie tussen klant en leverancier, en niet tussen twee leveranciers – dus twee commerciële partijen – onderling.

Indien het sectoraal comité groen licht geeft en men besluit het RRN op te nemen in de berichtuitwisseling moeten volgende stappen nog ondernomen worden: 1. In de EDIEL - berichtuitwisseling tussen leverancier en netbeheerder wordt een bijkomend veld voorzien in de informatie over de netgebruiker. 2. Leveranciers en DNB’s voorzien de nodige bijkomende datavelden in hun databases (Ref: Appendix 2: SPE - Probleemanalyse toegang tot officiële databestanden.doc). 3. Een link creëren tussen een EAN en de bijbehorende RRN’s, aangezien men op basis van het RRN momenteel enkel een adres kan verkrijgen.

Een mogelijk alternatief dat door de leveranciers werd aangebracht, is niet het RRN zelf als gegevenselement op te nemen in de berichtuitwisseling, maar enkel de classificatie op basis van het RRN. Bijvoorbeeld, men kan op basis van het RRN een eindgebruiker als wel of niet beschermd classificeren en dit vervolgens als flag doorsturen. Op die manier verspreidt men het eigenlijke RRN niet als gegevenselement, enkel de gevolgtrekking. Een potentieel struikelblok bij dit scenario is dat niet iedereen een RRN heeft (Ref: Notulen WT2-OP Sessie 4, p.4).

4.2.1.3. Evaluatie Alle partijen gaan akkoord dat dit een interessante piste is, maar dat eerst de volgende zaken uitgeklaard moeten worden (Ref: Notulen WT2-OP Sessie 4, p.3): •

Een duidelijk antwoord formuleren op de volgende twee vragen: (1) Willen we dit veld toevoegen in EDIEL? (2) Hoe effectief kunnen we hiermee identificeren? Gebruik van het RNN is bijvoorbeeld niet van toepassing voor buitenlanders.

•

Een link tot stand brengen met een kruispuntdatabank of een gemeentelijke databank schept mogelijkheden voor automatisering van processen, bijvoorbeeld automatische


25

wijziging van de klantnaam bij een verhuis. Doch dit heeft zijn beperkingen, omdat deze (ge-update) informatie slechts beschikbaar is met vertraging. •

Gebruik van het RRN vereist dat er een sterke verbinding met de moederdatabases tot stand wordt gebracht. De marktpartijen achten het wenselijk dat hier een studie aan voorafgaat, zodat in een sterke sleutel kan worden voorzien. Mogelijk is Umix hiervoor een geschikt forum (Ref: Notulen WT-OP Sessie 4, p.3).

•

Indien dit voorstel bij Umix terechtkomt, moet men eerst bepalen welk type toegang men tot stand wil brengen: (1) automatische toegang op basis van het nummer of (2) berichtinvoer van transactionele aard, type EDIEL.

4.2.1.4. Conclusie Alle partijen waren het eens dat dit een interessante piste is, maar dat het niet als een quick win kan worden beschouwd. In WT2-OP werd geconcludeerd dat dit punt wordt opgenomen als een nieuw governance issue dat naar de Vreg zal toekomen. De Vreg zal bij de Privacy Commissie aftoetsen wat de mogelijkheden zijn voor de energiesector om: (1) toegang te krijgen tot het rijksregister en zijn gegevens, en/of (2) de machtiging te krijgen om het rijksregisternummer te gebruiken.

Een dossier met argumenten zal moeten worden opgebouwd om deze aanvraag kracht bij te zetten. Dit dossier zou voorbereid kunnen worden door Umix, waarna het eigenlijke voorstel het stempel van de Vreg zal dragen. Uit de uiteenzetting onder paragraaf 4.2.1.2. blijkt het belang om in het dossier kenbaar te maken dat de motivatie voor de aanvraag onder andere een betere toepassing van de SODV’s is (Ref: Notulen WT2-OP Sessie 4, p.4).

.2.2.. Ownership over het contactadres 4.2.2 4.2.2.1. Probleemstelling De meterkaartjes die de DNB opstuurt in het kader van meteropnames komen te vaak onbesteld terug. De reden is dat de netgebruikergegevens die de leverancier in een switchbericht (392 – velden NAD UD) meegeeft aan de DNB veelal facturatiegegevens zijn. Deze zijn geschikt om door Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

26

de leverancier te worden gebruikt voor het versturen van de energiefactuur, maar zijn minder geschikt als contactgegevens voor meteropnames of andere interventies door de DNB (Ref: Appendix 3: Electrabel – Contactadres ownership.doc). Een voorbeeld hiervan zijn multisites: wanneer de DNB enkel gebruik maakt van de facturatiegegevens, komen meterkaartjes vaak foutief op de hoofdzetel aan (Ref: Notulen WT2-OP Sessie 4, p.6). Het facturatieadres is enkel nuttig voor de DNB om administratieve informatie met de eindgebruiker uit te wisselen (Ref: Appendix 3: Electrabel – Contactadres ownership.doc).

De DNB haalt netgebruikergegevens uit de switchberichten van de leverancier (supplier switch, customer switch, combined switch en move-in) en gebruikt deze vervolgens in het meteringproces. De kwaliteit en de geschiktheid van deze gegevens heeft bijgevolg een invloed: •

op de opnameratio

•

op het facturatieproces bij de leverancier en

•

op de intensiteit van het gebruik van het rectificatieproces bij leverancier en DNB.

Doordat meterkaartjes onvoldoende op de juiste plaats terechtkomen: •

Gebeuren er te weinig reële meteropnamen en moeten verbruiken geschat worden door de DNB. De gegevens in de databank van de DNB lopen dan niet meer synchroon met de situatie op het terrein, wat aanleiding geeft tot validatieproblemen bij de verwerking van daaropvolgende meterstanden.

•

Rekent de leverancier een verbruik aan dat gebaseerd is op schattingen. Dit lokt reacties uit bij klanten die een correcte aanrekening eisen op basis van reële meterstanden die zij op dat ogenblik doorgeven.

•

Moet de leverancier het rectificatieproces gebruiken om het verbruik recht te zetten. De DNB verwerkt deze rectificatieberichten en verstuurt nieuwe consumptiegegevens.

De veroorzaakte inefficiënties zijn (Ref: Appendix 3: Electrabel – Contactadres ownership.doc):


27

•

Bij de DNB: verwerken van teruggekomen meterkaartjes en verloren kosten, schatten van niet opgenomen indexen - wat een impact heeft op daaropvolgende validatie en verwerken van rectificaties.

•

Bij de leverancier: behandelen en verwerken van klachten (via callcenter, website, …), herwerken van facturaties en versturen van rectificaties.

•

Bij de klant: opstarten van klachtenprocedure, toenemende ontevredenheid en een verhoogde kostprijs wegens doorrekening van inefficiënties in de distributiekost.

4.2.2.2. Voorgestelde oplossing Teneinde meer duidelijkheid te scheppen werd allereerst de definitie van het contactadres vastgelegd als het adres waarnaar het meterkaartje verstuurd moet worden.

Een algemene suggestie van de leveranciers voor een mogelijke aanpak van dit probleem is om, alvorens een oplossing te ontwikkelen, het hele proces eerst gedetailleerd in kaart te brengen binnen Umix. Vervolgens kan dit scenario dan procesmatig worden uitgetest door een aantal leveranciers (Ref: Notulen WT2-OP Sessie 4, p.6).

Verder waren de partijen waren het unaniem eens dat deze problematiek in feite een probleem van ownership is. Er moet daarom duidelijk vastgelegd worden wie verantwoordelijk is voor de contactgegevens. Er bestaan twee mogelijkheden (Ref: Notulen WT2-OP Sessie 2, p.6): (1) de leverancier is owner van het contactadres (2) de DNB is owner van het contactadres

Optie 1: de leverancier is owner van het contactadres De leverancier is verantwoordelijk voor het contactadres. Hij bekomt van zijn klant een adres dat expliciet voor het meterkaartje bedoeld is en bezorgt dit aan de DNB. De leverancier draagt ook de verantwoordelijkheid voor de kwaliteit van het contactadres.

Aangezien het contactadres momenteel niet bij de leverancier beschikbaar is, vereist deze optie de volgende investeringen (Ref: Appendix 3: Electrabel – Contactadres ownership.doc): Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

28

•

Grote impact op de systemen van de leverancier: toevoeging van het contactadres in de database, opname in het berichtenverkeer, in proces governance, in scripting, in onderhoudsdata, etc.

•

Impact op de duur van de calls. Een verhoogde call duration vertaalt zich in een hogere kost voor leverancier en klant.

•

De leverancier zal een gezamenlijke actie naar alle klanten toe op touw te zetten voor een globale aanmaak van het contactadres. Dit is niet realiseerbaar op korte termijn.

Optie 2: de DNB is owner van het contactadres De DNB is verantwoordelijk voor het contactadres, neemt contact op met de klant om dit adres te bekomen en stuurt hiernaar het indexkaartje. De DNB is verantwoordelijk voor de kwaliteit van het contactadres. Deze optie kan volgens de leveranciers gerealiseerd worden door toepassing van volgend cascadesysteem (Ref: Appendix 3: Electrabel – Contactadres ownership.doc): 1. De DNB stuurt het meterkaartje in eerste instantie op naar het leveringsadres. De leverancier zorgt voor de aanlevering van de naam van de eindgebruiker op het leveringsadres (in 392 veld NAD IC). 2. Indien er geen respons komt, kunnen de rappels in tweede instantie naar het facturatieadres gestuurd worden. Op deze manier worden twee informatiebronnen, leverings- en facturatieadres, optimaal gecombineerd om het meterkaartje bezorgd te krijgen. 3. Komen er nog steeds geen indexen door en dient de DNB over te gaan tot schattingen, dan kan de leverancier op de factuur de klant op het probleem attent maken. De leverancier kan de klant erop wijzen dat zijn factuur gebaseerd is op geschatte indexen en hem aansporen om contact op te nemen met het meteropnamebedrijf voor het doorgeven van een bruikbaar opnameadres. 4. In voor de hand liggende gevallen, bijvoorbeeld onbemande leveringspunten zoals GSMmasten, kan het kaartje rechtstreeks naar het facturatieadres gestuurd worden.

De vereiste investeringen voor de tweede optie zijn de volgende:


29

•

Voor de leverancier: eventueel de aansturing NAD IC in 392 wijzigen. Dit moet nog onderzocht worden.

•

Voor de DNB (Ref: Appendix 3: Electrabel – Contactadres ownership.doc): o Aanmaak van een database voor de contactadressen voor meterkaartjes, in zoverre deze nog niet bestaat. De initiële upload van de database kan “en masse”

gebeuren,

met

.csv

bijvoorbeeld.

Men

kan

de

huidige

contactgegevens als vertrekbasis nemen en updaten wanneer er geen respons komt volgens het hierboven beschreven cascadesysteem (eerst leveringsadres indien nog niet gebruikt, in tweede instantie het facturatieadres). Dit scenario is realiseerbaar op KT (6-tal maanden). o Onderhoud en governance van deze database. Adressen zouden moeten kunnen vastgezet worden wanneer de eindgebruiker expliciet een specifiek adres voor het meterkaartje opgeeft. Updates afkomstig van de leverancier worden enkel toegelaten bij klanten- en gecombineerde wissels. o NAD IC uitlezen en linken aan de database. Dit moet nog verder onderzocht worden.

4.2.2.3. Evaluatie Optie 1: de leverancier is owner van het contactadres De leveranciers achten de kans klein dat deze piste tot een significante verbetering van de huidige situatie kan leiden. De leverancier is volgens hen niet goed geplaatst om de kwaliteit van het contactadres te waarborgen, omwille van de volgende redenen: 1. De leverancier kan wel globaal actie ondernemen naar alle klanten toe om dit gegeven aan te maken, maar heeft geen controle op de omvang en de kwaliteit van de respons hierop. Zoals eerder opgemerkt is dit bovendien niet realiseerbaar in een korte tijdspanne. 2. Ownership over het contactadres impliceert dat de leverancier ook ingeschakeld wordt bij het onderhoud ervan. Indien de DNB een fout contactadres vaststelt, hetzij op het terrein, hetzij via briefwisseling of terugkerende meterkaartjes, dan moet hij dit via een rectificatiebericht melden aan de leverancier. Vervolgens moet de leverancier een update terugsturen naar de DNB. Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

30

3. Ten derde is de betrokkenheid van de leverancier in een voor hem hoofdzakelijk metering-aangelegenheid

niet

vanzelfsprekend

(Ref:

Appendix

3:

Electrabel

–

Contactadres ownership.doc).

Een bijkomende reden volgens de leveranciers waarom dit scenario geen optie is, is het feit dat in de UMIG momenteel maar plaats is voor één adres. Zelfs indien het contactadres beschikbaar zou zijn, zou het m.a.w. technisch niet mogelijk zijn om dit adres, bovenop het facturatieadres, naar de DNB door te sturen (Ref: Appendix 3: Electrabel – Contactadres ownership.doc). De DNB’s en Umix betwisten dit echter. Volgens hen biedt de UMIG wel degelijk de mogelijkheid om twee adressen door te sturen en kan het technische aspect dus onmogelijk een struikelblok zijn. Volgens Umix bestaat er een matrix die per scenario weergeeft welke adressen worden toegepast (Ref: Notulen WT2-OP Sessie 6, p.5).

De sterkte van dit scenario volgens de DNB’s is dat de leverancier de logische verantwoordelijke is voor het contactadres en voor het doorsturen ervan aan de DNB. De achterliggende logica is dat de leverancier, en niet de DNB, in contact treedt met de klant. Het contactmoment met de klant leent zich uitstekend als captatiemoment voor het contactadres. Volgens de DNB’s wegen de kosten van dit scenario voor de leverancier niet op tegen de meerkost voor de DNB indien deze zou moeten instaan voor het contactadres (Ref: Notulen WT2-OP Sessie 4, p.6).

Optie 2: de DNB is owner van het contactadres Het voordeel van dit scenario volgens de leveranciers is dat er maximaal gebruik wordt maakt van de reeds beschikbare en kwaliteitsvolle leverings- en facturatieadressen. Volgens de leveranciers kan men er immers ervan uitgaan dat de kwaliteit van zowel de leveringsadressen, waarvan de DNB owner is, als van de facturatieadressen, waarvan de leverancier owner is, momenteel zeer hoog is. Beide partijen hebben er immers alle belang bij om de kwaliteit zo hoog mogelijk te houden: •

de DNB als beheerder van het toegangsregister

•

de leverancier voor het aanrekenen aan de klanten en dus het genereren van inkomsten.


31

Volgens de DNB’s wegen de kosten van dit scenario echter veel zwaarder door dan de investeringen die de leveranciers moeten doen om het ownership van het contactadres op zich te nemen. Andere suggesties Daarnaast werden door de leveranciers nog enkele suggesties gedaan waarbij de leverancier niet de owner is van het contactadres, maar wel zijn medewerking verleent aan de kwaliteit ervan:

1. Een suggestie van leverancier SPE is dat de leverancier de rol van doorgeefluik op zich neemt. Aangezien enkel de DNB gebruik maakt van het contactadres, zou dit scenario in feite toereikend moeten zijn. Dit scenario houdt in dat de leverancier zich engageert om tijdens het contact met de klant het contactadres te capteren en dit via een EDIEL bericht onmiddellijk door te sturen naar de DNB. Stockage in de eigen systemen is dan niet nodig.

Aan een dergelijk scenario zou wel een analyse naar mogelijke captatiemomenten vooraf moeten gaan, waarin wordt nagegaan welke contactmomenten tussen leverancier en klant het meest geschikt zijn voor captatie van het contactadres. In functie van de bevindingen kan men het eigen datamodel aanpassen. Volgens dit scenario zou het uitgangspunt zijn dat elke partij – zowel DNB als leverancier – elke mogelijkheid benut om het contactadres te capteren (Ref: Notulen WT2-OP Sessie 6, p.3).

2. Een suggestie van leverancier Nuon is responsabilisering van de klant. Volgens dit scenario zou in het standaardgeval, waar het contactadres gelijk is aan het aansluitingsadres, de klant geen speciale acties hoeven te ondernemen. Zodra echter van het standaardgeval wordt afgeweken, dient de klant dit mee te delen aan de DNB. De leverancier zal in de mogelijkheid voorzien om in afwijkende gevallen het contactadres te capteren op het contract. De eindverantwoordelijkheid om de DNB op de hoogte te stellen van het juiste contactadres ligt in zulke gevallen echter bij de klant (Ref: Notulen WT2-OP sessie 6, p.3).


32

3. Een suggestie van leverancier Essent is de statistieken rond onbestelbare meterkaartjes mee op te nemen in de maandelijkse dashboard monitoring, om een incentive te creëren voor de leveranciers. De leveranciers kunnen dan een analyse doen op deze informatie: waar liggen de oorzaken? Komt het door drops, verhuizen, zitten er overlijdens bij …? Door de rapportering uit te breiden kan men de leveranciers motiveren om deze cijfers omlaag te krijgen.

De andere partijen sluiten zich vooralsnog niet aan bij deze suggesties.

Bilateraal overleg Aangezien er geen consensus bestaat tussen de marktpartijen over de aangewezen partij om het ownership van het contactadres op zich te nemen, stellen de leveranciers voor om voorlopig via bilateraal overleg te focussen op het opkuisen van foute contactadressen uit het verleden. In een tweede fase kan dan worden gewerkt aan het correct aanleveren van contactadressen naar de toekomst toe (Ref: Notulen WT2-OP Sessie 6, p.2).

Hoewel suboptimaal, is deze oplossing volgens de leveranciers een valabel alternatief omwille van verschillende redenen (Ref: Notulen WT2-OP Sessie 6, p.3): 1. Na eliminatie van de fouten uit het verleden, schatten de leveranciers dat er nog slechts een gering percentage van de huidige problemen zal overblijven. 2. Bovendien is dit volgens de leveranciers een vrij eenvoudige oefening: indien men focust op een aantal specifieke gevallen, bijvoorbeeld alle UMIG releases die in het verleden hebben plaatsgevonden, zal men de meeste fouten uit het verleden al kunnen opsporen. 3. Ten derde is er de mogelijkheid om deze oefening voorzichtig te benaderen: men kan in eerste instantie een pilootproject opzetten in één bepaald gebied en vervolgens de resultaten afwachten. 4. Ten vierde is het volgens de leveranciers vandaag alleszins nog veel te vroeg om te beslissen over de enorme investering die gepaard gaat met het stockeren van een derde adres in de systemen van de leveranciers (Ref: Notulen WT2-OP Sessie 6, p.3). De


33

leveranciers sluiten deze optie niet a priori uit, maar willen dat er eerst een business case wordt gemaakt waarbij alle kosten en baten grondig worden afgewogen (Ref: Notulen WT2 Sessie 6, p.4). Bilateraal overleg biedt de mogelijkheid om alvast tussentijds actie te ondernemen (Ref: Notulen WT2 Sessie 6, p.4).

Alle partijen waren het unaniem eens dat voor de opkuis van het verleden bilateraal overleg de beste oplossing is. Bovendien valt er al progressie te noteren, aangezien tussen bepaalde partijen het bilateraal overleg reeds is opgestart (Ref: Notulen WT2-OP Sessie 6, p.3)

4.2.2.4. Conclusie De conclusie die uit de discussies werd getrokken is tweeledig: 1. Heden bestaat er geen consensus tussen de marktspelers over wie de aangewezen owner is van het veld contactadres. 2. Wel werden de volgende afspraken gemaakt: •

De definitie van het contactadres werd vastgelegd als het adres waarnaar het meterkaartje moet worden verzonden.

•

Bilateraal overleg: in WT2-OP werd geconfirmeerd dat er op korte termijn bilateraal overleg zal plaatsvinden tussen de verschillende partijen om een analyse te doen rond onbestelbare kaartjes en onbestelbare post en in een eerste fase te focussen op het opkuisen van foute contactadressen uit het verleden (Ref: Notulen WT2-OP Sessie 3, p.4). Deze aanpak is suboptimaal, aangezien het enkel maatwerk en één – op één oplossingen opleveren, maar is de enige optie om op korte termijn toch resultaten te boeken. Bovendien laat bilateraal overleg toe dat elke partij de problemen op haar eigen tempo kan aanpakken.

•

WT2-OP doet het voorstel om de problematiek van onbestelde meterkaartjes door te verwijzen naar Umix Monitoring. Daar kan op middellange termijn een diepere analyse gebeuren die mogelijk nieuwe pistes oplevert om incrementele procesverbeteringen te realiseren. De resultaten van het bilateraal overleg kunnen als input dienen voor deze analyse: men kan aftoetsen in hoeverre de


34

maatoplossingen die het bilateraal overleg heeft opgeleverd als best practice voor heel de markt kunnen worden beschouwd. •

Leverancier Essent heeft zich formeel bereid verklaard om op middellange termijn over te gaan tot het capteren van het contactadres op het contract, stockeren ervan in de eigen systemen en mee doorsturen van het contactadres aan de DNB’s.

•

Koppeling aan een nieuw datamodel voor de markt: op lange termijn – 2012 werd als tijdshorizon genoemd - kan dit probleem opgelost worden via de ontwikkeling van een nieuw datamodel voor de sector waarbij alle adresdefinities en de bijbehorende rollen en verantwoordelijkheden worden herzien en klaarheid wordt geschept over het ownership van alle data en processen (Ref: Notulen WT2-OP Sessie 6, p.6).

4.2.3. Toegang tot netgebruikergegevens 4.2.3.1. Probleemstelling A. Voor leveranciers bij DNB’s Aan leverancierszijde is er behoefte aan een meer uitgebreide toegang tot en grotere beschikbaarheid van de informatie die aanwezig is in de systemen van de DNB, met name het toegangsregister, de assetgegevens en de meetgegevens. Deze gegevens zijn wel voorhanden - ze moeten m.a.w. niet meer gecreëerd worden - het komt er enkel op aan ze zichtbaar te maken voor de leveranciers (Ref: Notulen WT2-OP Sessie 3, p.5).

Onmiddellijke toegang tot deze gegevens bij de DNB zou volgens de leveranciers de accuraatheid van de doorgegeven indexen structureel verbeteren en veel verheldering brengen wanneer zich een probleem voordoet. Het is immers deze informatie die als basis dient voor de marktprocessen geïnitieerd door zowel DNB als leverancier. De databases van de DNB vormen de referentie in de markt om te bepalen welke processen wanneer moeten gebruikt worden (Ref: Appendix 4: Electrabel - Toegang tot toegangsregisters.xls).

Dat de bestaande toegang te beperkt is, laat zich voelen in verschillende processen telkens wanneer de leverancier vaststelt dat de informatie in de eigen systemen ontbreekt, ontoereikend Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

35

is, niet betrouwbaar of niet correct blijkt te zijn. Hiervoor bestaan verschillende oorzaken, zoals snapshots met een te groot interval, fouten in de berichtuitwisseling en fouten in de systemen van zowel leverancier als DNB (fouten in updates, nieuwe releases, …). Er is vooral een impact op de volgende processen:

•

Genereren van switchprocessen (move-in, combined switches, customer switches)

•

Contracting (identificatie installatie HS, LS, technische gegevens)

•

Metering (klachten van eindklanten over factuuronderdelen)

•

Correct uitsturen van rectificatieboodschappen

•

Opvolgen van de status van en vraag naar meer detail over een rechtzetting.

Concreet treden de volgende problemen op (Ref: Appendix 4: Electrabel - Toegang tot toegangsregisters.xls): •

Ontvangen van mystery switch notificaties veroorzaakt door een foutieve EAN.

•

Klachten van eindgebruikers over het niet respecteren van doorgegeven indexen (fout in combined switches, fout in doorgegeven index)

•

Klachten van eindgebruikers over bepaalde factuuronderdelen (verliesfactoren, tariefcode, metercertificaat, …)

•

Oproep door de leverancier van een geblokkeerde EAN voor move-in (foutieve EAN in geval van nieuwbouw)

•

Verwerpingen op switches (punt open of gesloten).

Op momenten waarop de leverancier niet (meer) kan vertrouwen op informatie in de eigen systemen wenst hij deze informatie te kunnen consulteren bij de DNB. Indien de benodigde gegevens echter niet onmiddellijk consulteerbaar zijn, moet de leverancier zijn toevlucht nemen tot suboptimale oplossingen, bijvoorbeeld: •

Switchen toch uitsturen, ondanks het feit dat er onvoldoende juiste informatie aanwezig is. Er bestaat dan een verhoogd risico op een fout en dus op verwerping.


36

•

De noodzakelijke data via een rectificatiebericht opvragen. Dit veroorzaakt echter rework en probleemdossiers blijven langere tijd onopgelost.

Het resultaat is dat in geval van nieuwe klanten de switch niet correct wordt uitgevoerd en in geval van bestaande klanten processen fout worden aangestuurd en klanten niet correct gefactureerd. Dit brengt voor de leverancier de volgende extra kosten mee: •

Rework in geval van foutief opgestarte processen

•

Additionele kosten voor de behandeling van klachten en voor het opstarten en opvolgen van corrigerende processen.

Er is dus nood aan een uitgebreidere toegang tot de informatie in de systemen van de DNB’s. In het kader van klachtenbehandeling moet de leverancier kunnen verifiëren of de eigen gegevens overeenstemmen met die van de DNB om rectificatieprocessen correct te kunnen opstarten. Verder moet ook in de mogelijkheid voorzien worden zijn om de status en de details van zowel afgewerkte als hangende processen op te vragen (Ref: Appendix 4: Electrabel - Toegang tot toegangsregisters.xls). Voor een gedetailleerd overzicht van de bestaande en de gevraagde functionaliteiten plus motivatie, verwijzen we naar Appendix 4.

Ook werd door de leveranciers de vraag geformuleerd naar een mogelijke verbetering van het supplierweb. Momenteel kan men enkel die gegevens consulteren waarvoor men de huidige leverancier is. Dit zou uitgebreid moeten worden naar de hele periode waarvoor men leverancier is geweest, ook als men dat nu niet meer is (Ref: Notulen WT2-OP Sessie 3, p.5).

Tenslotte is de bestaande toegang tot de systemen van de DNB’s te gedifferentieerd: •

Er is

geen uniforme opbouw

(Ref:

Appendix

4:

Electrabel - Toegang

tot

toegangsregisters.xls). •

De verschillende views (bijvoorbeeld op processen en op meetgegevens, gas en elektriciteit) zijn niet geïntegreerd.


37

•

De aangeboden functionaliteiten verschillen tussen de DNB’s onderling. Bij bepaalde DNB’s zijn sommige gegevens aanwezig, maar nooit allemaal. Een voorbeeld hiervan is de meterconfiguratie (register, meterconfig (dag/nacht)). Momenteel kan de leverancier hier slechts bij bepaalde DNB’s een zicht op krijgen (Ref: Eindrapport WT3, p.31). Over het algemeen zijn bij de zuivere DNB’s de technische gegevens beter uitgewerkt en bij de gemengde DNB’s de meetgegevens (Ref: Notulen WT2-OP Sessie 4, p.8).

B. Voor DNB’s bij leveranciers Ook aan de zijde van de DNB’s is er behoefte aan een uitgebreidere toegang tot informatie. Een voorbeeld hiervan is de toegang tot factuurgegevens: de DNB heeft deze nodig om aan de klant te kunnen meedelen welk volume hem werd aangerekend. Volgens de DNB’s zijn de doeleinden van een uitgebreidere informatietoegang dezelfde als waarom leveranciers toegang willen tot de gegevens van de DNB’s (Ref: Notulen WT2-OP Sessie 4, p.7): •

Om over meer controlemogelijkheden te beschikken.

•

Om in geval van problemen sneller de oorzaak van een probleem te achterhalen en een diagnose te stellen. Het systeem van online toegang laat onder meer toe te bepalen of het al dan niet om een intern probleem gaat (Ref: Notulen WT2-OP Sessie 3, p.5). Bijgevolg kan de klant sneller en beter worden geholpen (Ref: Notulen WT2-OP Sessie 4, p.7).

4.2.3.2. Voorgestelde oplossing A. Voor leveranciers bij DNB’s De voorgestelde oplossing omvat het ontwikkelen van een uniforme en uitgebreide online – dus onmiddellijke - toegang tot de gegevens in de systemen van de DNB.

In een eerste stadium kan men streven naar een uniforme en meer uitgebreide online interface met een ‘profile driven’ view op de interne databases van de DNB. Het gebruik van profielen biedt een oplossing om de confidentialiteit van de data te verzekeren. De aard van de toegang kan vastgelegd worden in lees- en schrijfprofielen. Interferentie met het EDIEL- berichtenverkeer


38

dient

hierbij

vermeden

te

worden

(Ref:

Appendix

4:

Electrabel

-

Toegang

tot

toegangsregisters.xls).

In een volgend stadium kan men, steunend op de ervaring met de online interface, de mogelijkheden uitbreiden voor het opvragen van informatie via EDIEL (“vraag naar informatie”) berichten. Men kan dan werken met een mix aan informatiebronnen. Een snapshot is bijvoorbeeld een andere mogelijke gegevensdrager – weliswaar met een beperkte houdbaarheidsdatum. Men zou online een bericht kunnen versturen, waarna men via EDIEL een ‘foto’ terugkrijgt van de gevraagde informatie die men kan integreren in de eigen systemen. Dit creëert meer mogelijkheden voor de automatisering van bv. correctieprocessen, maar geeft met de huidige VAN en de afspraken daar rond geen onmiddellijk resultaat (Ref: Appendix 4: Electrabel - Toegang tot toegangsregisters.xls).

B. Voor DNB’s bij leveranciers Deze oplossing is analoog aan deze die hierboven werd beschreven: het ontwikkelen van een geharmoniseerde online interface om de DNB’s toegang te verschaffen tot de gegevens in de systemen van de leveranciers. Zodoende kan de DNB de gevraagde gegevens bij de leverancier consulteren en vergelijken met wat in de eigen database staat (Ref: Notulen WT2-OP Sessie 4, p.7).

De gegevens waarop de DNB’s een zicht wensen te krijgen in de systemen van de leveranciers kunnen opgedeeld worden in 4 blokken (Ref: Notulen WT2-OP Sessie 4, p.7): •

Netgebruikergegevens (naam, facturatieadres, ondernemingsnummer, NACE, res/nres, …)

•

Metergegevens (index, verbruik, opnamemaand)

•

Factuurgegevens (status laatste factuur, gridfee, status metergegevens)

•

Status EAN (EAN, status, groen)

De volledige lijst van gevraagde gegevens kan gevonden worden in Appendix 6 (DNB’s - Toegang tot informatie.xls).


39

4.2.3.3. Evaluatie A. Voor leveranciers bij DNB’s Volgens de leveranciers zou een betere uitwerking van de technische gegevens het risico op schadekosten op twee manieren beperken (Ref: Eindrapport WT3, p.5): (1) Ten eerste zullen de gevraagde functionaliteiten toelaten fouten sneller te detecteren. Dit geldt zowel voor fouten ten gevolge van desynchronisaties als voor informatie die fout is binnengekomen in het systeem van de DNB. Een voorbeeld hiervan is een high register die is binnengekomen als een low register. (2) Ten tweede kunnen schadekosten vermeden worden doordat men meer inzicht verkrijgt in het combined switch scenario. Momenteel hebben de leveranciers in geval van een combined switch niet veel zicht op de feitelijke situatie. Als de klant al een index doorgeeft, bestaat er geen zekerheid of dit wel de correcte index is. De klant kan bijvoorbeeld de index van een verkeerde meter hebben afgelezen.

Andere voordelen van dit scenario zijn volgens de leveranciers: •

Minder rework, minder klachten en een snellere debugging.

•

Een deel van de rectificatieberichten die de leverancier momenteel uitstuurt zullen overbodig worden (Ref: Notulen WT2-OP Sessie 6, p.7). Dit zal zich vertalen in een daling van de kosten voor zowel DNB als leverancier en in een lagere prijs voor de eindgebruiker.

•

Bovendien is het een sterk toekomstgerichte oplossing. De installatie van een dergelijke toegang blijft immers in alle omstandigheden een nuttig werkinstrument, wat een belangrijk voordeel is in een steeds evoluerende markt (nieuwe releases, nieuwe reglementeringen, nieuw markmodel, ...).

Het nadeel van deze piste volgens Umix is dat dit geen EDIEL systeem meer is en een fundamentele wijziging van de bestaande architectuur vereist (Ref: Notulen WT2-OP Sessie 3, p.6). Volgens de leveranciers echter, zou deze piste het bestaande EDIEL rectificatieproces echter geenszins vervangen, enkel complementeren. Zij gaan akkoord dat de voorgestelde oplossing geen afbreuk mag doen aan de bestaande ‘formele’ uitwisseling van informatie (Ref: Appendix 5: SPE –


40

Probleemanalyse toegang tot netgebruikergegevens.doc). Het bestaande proces werkt volgens de leveranciers immers relatief goed – op enkele kleine verbeteringen na - en heeft bovendien juridische waarde. De leveranciers beschouwen de hierboven beschreven piste als een soort debugging systeem dat geraadpleegd kan worden wanneer er iets fout loopt. Zodra een probleem optreedt waardoor men de eigen data niet (meer) kan vertrouwen, kan men beroep doen op dit parallel systeem om data te verifiëren (Ref: Notulen WT2-OP Sessie 3, p.6).

Een nadeel van dit scenario dat door alle partijen werd erkend, is het risico op manuele correcties in geval van asynchrone data. Wanneer online consultatie uitwijst dat de eigen gegevens niet synchroon zijn met die van de DNB, bestaat het risico dat de leverancier zijn eigen gegevens in functie hiervan gaat aanpassen (Ref: Notulen WT2-OP Sessie 3, p.5). Dit scenario houdt dus het gevaar in dat gegevens worden overschreven die zelfs nooit via het berichtenverkeer werden doorgestuurd. Manuele correcties die niet gebaseerd zijn op berichtenverkeer vergroten de kans op datavervuiling.

Hoewel de beslissing om gegevens al dan niet manueel te overschrijven een interne kwestie is, waren alle partijen waren het erover eens dat men het aantal manuele correcties moet trachten te minimaliseren. In geval van asynchrone data moet men eerst nagaan of er geen bericht werd gemist. Veiligheidshalve zou men enkel manuele correcties mogen uitvoeren indien aan de volgende voorwaarden is voldaan: (a) er heeft EDIEL berichtenverkeer plaatsgevonden en (b) het gaat duidelijk om een intern probleem (Ref: Notulen WT2-OP Sessie 3, p.6).

Bij leverancier SPE-Luminus bijvoorbeeld, wordt het raadplegen van externe databronnen enkel aanvaard als het eigen systeem faalt in het ondersteunen van de bedrijfsprocessen. Een voorbeeld hiervan is de link tussen het toegangspunt (EAN-GSRN) en het aansluitingsadres. Hiervoor wordt bij SPE de CD-ROM ingeladen die, conform het technische reglement, door de DNB halfjaarlijks ter beschikking wordt gesteld. SPE laadt deze informatie op in het eigen systeem en draagt hierover de eindverantwoordelijkheid. Voor de meeste scenario’s gebruiken de operatoren in eerste instantie de gegevens in het dit systeem. Enkel in het geval van nieuwe aansluitingen


41

(move-in) wordt ter controle de online consultatietool van de DNB geraadpleegd, omdat deze meer recente informatie bevat (Ref: Appendix 5: SPE – Probleemanalyse toegang tot netgebruikergegevens.doc).

B. Voor DNB’s bij leveranciers De voor- en nadelen van dit scenario zijn eveneens dezelfde als hierboven. Volgens de DNB’s is het voordeel van een uitgebreidere gegevenstoegang dat oorzaken van problemen sneller kunnen worden gedetecteerd, waardoor de klant sneller en effectiever kan worden geholpen. Ook de monitoring zal beter kunnen gebeuren (Ref: Notulen WT2-OP Sessie 4, p.7). C. Lange termijn: ontwikkeling van een gemeenschappelijk dataportaal Een mogelijke oplossing die interessant werd bevonden maar die buiten de scope van WT2-OP valt, is de oprichting van een gemeenschappelijk dataportaal (Ref: Notulen WT2-OP Sessie 4, p.6).

In verschillende andere landen worden dergelijke dataportalen opgezet, volgens de Vreg omwille van hun duidelijke meerwaarde en zonder dat fundamenteel moet worden ingegrepen in de systemen van de marktspelers. Voorbeelden kunnen gevonden worden in Zweden, Noorwegen en de UK. De mate van centralisatie kan variëren van een systeem dat op volledig individuele basis wordt uitgewerkt, over centralisatie per DNB tot een volledige centralisatie. De Vreg heeft voorgesteld om voorbeelden uit verschillende landen te verzamelen en te documenteren. Deze informatie kan aan bv. het Marktforum worden voorgelegd om een project op marktniveau te lanceren.

Het voordeel volgens de Vreg van een dergelijke ‘data viewer’ is een betere datakwaliteit en een daling van het aantal rectificaties. Volgens Umix kunnen bovendien een aantal processen hierdoor eenvoudiger en gerichter worden.


42

4.2.3.3. Conclusie Van zowel leveranciers als DNB’s werd een principieel akkoord verkregen om op korte tot middellange termijn toegang te verschaffen tot alle UMIG-gerelateerde gegevens, d.w.z. alle gegevens die momenteel reeds via de UMIG circuleren.

Wat de niet-UMIG gegevens betreft, is volgens de leveranciers meer voorzichtigheid geboden (Ref: WT2-OP Sessie 6, p.7). De reden is dat in sommige gevallen, bijvoorbeeld wanneer de DNB factuurgegevens gaat opvragen bij de leverancier, bestaande problemen zouden kunnen verergeren. De leveranciers verkiezen om in dergelijke gevallen, wanneer toegang tot commerciële gegevens nodig is, zelf met de klant in contact te treden. De DNB kan de klant dan doorverwijzen naar de leverancier.

In eerste instantie zal de toegang tot de UMIG-gerelateerde gegevens een bilaterale één – op - één toegang zijn. Er is consensus dat een centrale interface geen prioriteit is en dat op korte termijn een aparte gegevenstoegang kan volstaan. Wel zal van meet af aan een gemeenschappelijke look– en–feel interface voor alle partijen worden nagestreefd (Ref: Notulen WT2-OP Sessie 6, p.7).

Op lange termijn (tijdshorizon: 2012) kan de ontwikkeling van een gemeenschappelijk dataportaal een oplossing bieden (Ref: Notulen WT2-OP Sessie 6, p.7).

2.4. 4.2. 4. Het veld res/nietes/niet-res en reëel verbruikspatroon 4.2.4.1. Probleemstelling Volgens de leveranciers wordt met het attribuut res/nres momenteel één veld gebruikt voor verschillende doeleinden, wat een nauwkeurige bepaling van het verbruikspatroon bemoeilijkt. Onder andere in de volgende gevallen geeft het attribuut res/nres onvoldoende de werkelijke aard weer van het verbruik op het toegangspunt (Ref: Notulen WT2-OP Sessie 3, p.8): •

Conform de nieuwe definitie van "huishoudelijke afnemer" in Vlaanderen worden in de toekomst "small offices" niet langer als residentieel beschouwd, hoewel het verbruik dikwijls een uitgesproken residentieel karakter heeft.


43

•

De klant kan zelf kiezen om een contract af te sluiten als professionele gebruiker dan wel als privépersoon. Bijgevolg komt het regelmatig voor dat de contractant professioneel is, terwijl het verbruik op het toegangspunt eerder residentieel is.

In dergelijke gevallen is de bepaling van de EAV bij onvoldoende historische gegevens niet meer in overeenstemming met het reële verbruik. Dit veroorzaakt volgende problemen: •

Foute bepaling van forfaits en verkeerde schattingen van meterstanden. De klant betwist de meterstand, waardoor de leverancier rectificatieberichten moet uitsturen. We verwijzen hiervoor eveneens naar het probleem van herschattingen dat in paragraaf 4.2.1. wordt besproken.

•

Bovendien leidt het in sommige gevallen tot het bepalen van een foute SLP (Synthetisch Last Profiel), een foute schatting van het verbruikspatroon.

•

Tenslotte bemoeilijkt een foute toewijzing van het veld res/nres ook een correcte toepassing van SODV’s (Ref: Appendix 1: Eandis – Probleemanalyse toegang tot informatie_v5.doc). Voor een verdere bespreking van dit probleem verwijzen we naar paragraaf 3.2.6.2.

4.2.4.2. Voorgestelde oplossing Dit probleem kan worden opgelost door ofwel (a) een extra veld toe te voegen in de EDIEL berichtuitwisseling, ofwel (b) de interpretatie van een bestaand veld aan te passen om een betere omschrijving van het verbruikspatroon te coderen. Dit nieuwe of geherinterpreteerde veld kan dan als bijkomende informatie opgenomen worden bij de bepaling van de EAV en SLP. De grootste moeilijkheid voor de realisatie van dit scenario is niet de creatie van een nieuw veld of de herinterpretatie van een bestaand veld, maar wel een goede koppeling ervan aan de validatie van indexen (Ref: Notulen WT2-OP Sessie 3, p.8).

4.2.4.3. Evaluatie Bij een goede implementatie zal het aantal rectificatieberichten zal dalen.


44

Het nadeel van dit scenario is de reikwijdte ervan. Het probleem beperkt zich immers niet tot het attribuut res/niet-res, ook alle afhankelijkheden moeten in de analyse worden opgenomen (Ref: Notulen WT2-OP Sessie 3, p.9). Dit scenario vereist zowel een aanpassing van de bestaande EDIEL logica als van alle achterliggende processen en systemen die zorgen voor de bepaling van de EAV in de databanken van de DNB en de daaruit afgeleide processen, zoals de validatie van meetgegevens (Ref: Appendix 7: Electrabel – Verbruikspatroon.xls).

4.2.4.4. Conclusie Er bestaat een consensus rond de probleemstelling, maar nog niet rond een mogelijke oplossing. WT2-OP stelt voor dit punt in zijn geheel door te verwijzen naar Umix, aangezien Umix dit probleem in het verleden al heeft onderzocht. De door Umix uitgevoerde analyse zou dan herbekeken worden. Men kan nagaan in hoeverre het al gedane werk nog bruikbaar of relevant is. Indien de omstandigheden inmiddels sterk gewijzigd zijn, kan het nuttig zijn de analyse te updaten met nieuwe elementen om na te gaan of er nu wel een oplossing is die een positieve ROI heeft op KT/MT termijn (Ref: Notulen WT2-OP Sessie 3, p.9).

2.5. 5. Het veld NACE code 4.2. 4.2.5.1. Probleemstelling De DNB’s zijn wettelijk verplicht om jaarlijks het totale verbruik per NACE code te rapporteren aan het Vlaams Energieagentschap (VEA). Hiertoe wordt van de leverancier verwacht in een switchbericht de NACE code mee te geven aan de DNB. Jaarlijks stelt de DNB echter vast dat de kwaliteit van dit gegevenselement te wensen overlaat (Ref: Appendix 8: Electrabel – NACE code.xls): •

Er is een groot aantal ontbrekende codes.

•

Er is een groot aantal incorrecte codes. Er zijn twee soorten incorrecte codes: (a) een foute syntax of (b) een foute link tussen onderneming en NACE code (Ref: Notulen WT2-OP Sessie 3, p.10)

•

Er bestaan grote verschillen met vorige rapporteringen.

Dit brengt de volgende kosten met zich mee: Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

45

De rapportering verloopt elk jaar opnieuw zeer inefficiënt, doordat de te rapporteren lijst

•

bijna punt voor punt moet worden overlopen (Ref: Notulen WT2-OP Sessie 3, p.10). •

Regelmatig moeten er data cleanings worden uitgevoerd.

•

Fouten in de rapportering leiden ertoe dat op beleidsniveau de verkeerde conclusies worden getrokken (Ref: Notulen WT2-OP Sessie 3, p.9).

De oorzaak ligt volgens de leveranciers in een onzorgvuldige toekenning van NACE codes. Hiervoor zijn verschillende oorzaken (Ref: Appendix 8: Electrabel – NACE code.xls): •

De klant geeft vaak een foute code door. Veel ondernemingen, KMO’s in het bijzonder, kennen namelijk hun eigen NACE code niet.

• Er is een fout opgetreden bij de aanmaak van de klant in de systemen. • Er is een fout opgetreden bij het doorsturen van de NACE code naar de DNB.

Daarenboven bestaat er slechts een beperkte controle op de toekenning van de code, aangezien de systemen momenteel elke geautoriseerde code aanvaarden. Volgens de netbeheerders zou het al een grote verbetering zijn indien tenminste controle kan worden uitgeoefend op de juistheid van de boom, zodat bijvoorbeeld aan een bakkerij geen code uit de chemiesector kan worden toegekend. Momenteel kunnen dergelijke flagrante fouten wel voorkomen en zelfs lange tijd onopgemerkt blijven (Ref: Notulen WT2-OP Sessie 3, p.9).

4.2.5.2. Voorgestelde oplossingen (1)

Een

mogelijke

oplossing

die

door

de

leveranciers

werd

voorgesteld

is

het

ondernemingsnummer als sleutel te gebruiken. De leverancier zou dan instaan voor de kwaliteit van het ondernemingsnummer. Op basis van een correct ondernemingsnummer kan de DNB de corresponderende NACE code opvragen in de kruispuntdatabank of in een andere centrale databank, zoals data brooker Graydon (Ref: Notulen WT2-OP Sessie 3, p.9).

Het voordeel van dit scenario is dat de DNB slechts eenmalig een link moet aanmaken met een databank om de NACE codes te bekomen. Dit zou een vereenvoudiging betekenen ten opzichte van de huidige situatie, waarin met elke leverancier apart contact moet worden opgenomen om de Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

46

NACE code te verkrijgen (Ref: Notulen WT2-OP Sessie 3, p.9). Er was echter geen consensus onder de partijen over dit voorstel.

(2) Een suggestie van de DNB’s was het vestigingsnummer in plaats van het ondernemingsnummer als sleutel te gebruiken. De realisatie hiervan is echter niet vanzelfsprekend, omdat er momenteel geen link bestaat tussen het vestigingsnummer en de NACE code. Indien men bv. ‘TOTAL’ opzoekt in de kruispuntdatabank, krijgt men als resultaat van deze zoekopdracht een reeks NACE codes, een reeks ondernemingsnummers en een reeks vestigingsnummers - maar zonder dat er een link bestaat tussen al deze gegevens. Volledige automatisering is bijgevolg niet mogelijk. Bijkomend probleem is dat de meeste ondernemingen hun vestigingsnummer niet kennen (Ref: Notulen WT2-OP Sessie 3, p.10).

(3) Een derde piste die werd aangehaald, is de kruispuntbank verantwoordelijk maken voor het creëren van een unieke link tussen onderneming en NACE code. De moeilijkheid hier is echter dat er voor sommige ondernemingen geen één–op–één link is. Een multisite- of multiactiviteitenonderneming als TOTAL bijvoorbeeld, kan aan meerdere NACE codes gelinkt worden.

4.2.5.3. Conclusie Er bestaat geen consensus in de markt over een mogelijke oplossing, enkel over de probleemstelling. Alle partijen waren het eens dat dit in feite een probleem van data ownership is. Men moet instaan voor de kwaliteit van een data-element waarvan men niet kan garanderen of het correct is. Men dient dus een partij aan te duiden die verantwoordelijk is voor de kwaliteit van de NACE code. Er zijn drie mogelijke opties: •

de DNB’s

•

de leveranciers

•

het VEA, waarbij het VEA zelf instaat voor het aanmaken van een link tussen onderneming en NACE code.


47

De Vreg heeft navraag gedaan bij het VEA rond de derde optie. Het antwoord van VEA luidde dat de organisatie meent onvoldoende kennis te hebben van de sector om zelf in te staan voor de kwaliteit van de NACE code.

Het VEA is echter wel bereid om over dit probleem overleg te plegen met de marktspelers (Ref: Notulen WT2-OP Sessie 4, p.9). In de nabije toekomst - een precieze datum zal nog worden meegedeeld - zal een marktoverleg plaatsvinden over dit probleem tussen het VEA, de netbeheerders en de leveranciers. De namen van de afgevaardigden werden reeds bevestigd aan het VEA (Ref: Notulen WT2-OP Sessie 6, p.7).

4.2.6. Toekenning van het sociaal tarief 4.2.6.1. Probleemstelling Volgens leverancier Electrabel vormt de informatie-uitwisseling rond sociaal tarief een parallel kanaal dat beter bij de DNB zou lopen. Momenteel dient de eindafnemer die recht heeft op het sociaal tarief een attest over te maken aan zijn leverancier. De leverancier kent het sociaal tarief toe van zodra hij dit attest ter beschikking heeft. Wanneer de klant van leverancier verandert, wordt de nieuwe leverancier echter niet op de hoogte gebracht van het feit of de klant al dan niet recht heeft op het sociaal tarief (Ref: Notulen WT2-OP Sessie 3, p.7).

Vanaf 1 januari 2010 zal bovendien een nieuwe wetgeving van kracht worden die vereist dat eindgebruikers automatisch het sociaal tarief genieten vanaf de eerste dag dat zij daar recht op hebben. De nieuwe werkwijze zal erin bestaan dat de leverancier zijn databank dropt bij de FOD Economie, die een matching zal doen met de gegevens van de kruispuntdatabank en op basis hiervan zal aanduiden welke klanten recht hebben op sociaal tarief. De leverancier dient vervolgens deze gegevens te integreren in zijn facturatiesysteem (Ref: Appendix 9: Electrabel Sociaal tarief.xls).

Daarnaast wordt een correcte toekenning van het sociaal tarief bemoeilijkt door het problematische veld res/nres dat in paragraaf 4.2.4. werd besproken. Indien de toewijzing van het veld res/nres niet correct is, zal de DNB onterecht toegangspunten afsluiten en/of onterecht Goedgekeurd eindrapport – WT2-OP – 30 maart 2009

48

budgetmeters plaatsen en energie leveren als sociale leverancier. Dit creëert meerkosten die uiteindelijk gesocialiseerd worden via het distributienettarief (Ref: Probleemanalyse Eandis v1.doc).

4.2.6.2. Voorgestelde oplossing Het voorstel van de leveranciers bestaat erin dit data-element toe te voegen aan het toegangsregister. Het probleem doet zich immers vooral voor bij leverancierswissels en verhuizen en is niet gerelateerd aan de klant, maar aan het leveringsadres/domicilieadres (Ref: Notulen WT2-OP Sessie 3, p.7). De netbeheerders zijn niet akkoord dat de informatie-uitwisseling betreffende het sociaal tarief via hen moet verlopen. Volgens de leveranciers moet in deze materie het belang van de klant centraal staan, en moet men een neutrale houding innemen tegenover de eigen werklast (Ref: Notulen WT2-OP Sessie 3, p.8).

Een tweede suggestie van de leveranciers is dat de sector unaniem een standpunt inneemt of men verkiest om (a) de informatie die vanuit de overheid wordt gevraagd bij de leverancier te droppen, dan wel (b) de overheid te adviseren alle gevraagde informatie zelf te beheren en te coördineren. Indien de sector hierover een consensus kan bereiken, kan een krachtig signaal worden gegeven naar de overheid toe (Ref: Notulen WT2-OP Sessie 3, p.8).

4.2.6.3. Conclusie Voor dit probleem werden geen quick wins geïdentificeerd. De partijen merken op dat zij door recente ontwikkelingen in de energiewetgeving inmiddels aan nieuwe verplichtingen onderhevig zijn (Ref: Notulen WT2-OP Sessie 6, p.8).

2.7.. Uniformisatie en standaardisatie van adresgegevens 4.2.7 Een unieke klantidentificatie aan de hand van ondernemingsnummer, rijksregisternummer of verblijfsvergunning is wenselijk, maar misschien niet altijd mogelijk. Daarom is unieke identificatie van adresgegevens eveneens wenselijk (NIS codes voor straten, gemeenten, strikte codering/standaarden van huisnummers, busnummers, ... ). Ook zaken zoals wijzigingen van straatnamen moeten op een coherente manier aangepakt worden.


49

In WT2-OP werd geconfirmeerd dat UMIX Structuring zich met dit probleem bezighoudt (Ref: Notulen WT2-Op Sessie 2, p.5) en werd aldus beslist hier in WT2-OP verder niet op in te gaan.

4.3. Doorverw Doorverwijzing ijzing resultaten WT1 en WT3 m.b.t. toegang tot informatie Tijdens de laatste sessie van WT2-OP werden de resultaten van WT1 en WT3 overlopen aan de hand van een checklist (zie Appendix 14: Checklist WT2-OP). In het bijzonder werd nagegaan of er openstaande punten uit WT1 of WT3 waren die, zonder expliciet in WT2-OP aan bod te zijn gekomen, toch rechtstreeks kunnen doorvloeien naar het Project Comité. De doelstelling was de resultaten van deze voorgaande werktrajecten maximaal te benutten en geen bruikbare voorstellen verloren te laten gaan (Ref: Notulen WT2-OP Sessie 6, p.7).

Wat ‘Toegang tot informatie’ betreft, waren er geen pistes uit WT1 of WT3 die in aanmerking kwamen voor rechtstreekse doorverwijzing. Alle pistes waren ofwel behandeld binnen WT2-OP, ofwel vielen ze buiten scope van WT2-OP. De tabel hieronder geeft een overzicht van de relevante resultaten van WT1 en WT3 en de conclusies van WT2-OP. Voor een gedetailleerder overzicht verwijzen we naar de checklist in Appendix 14.

Input WT1

Issue 1. 2. 3. 4.

Behandeld?

Conclusie WT2-OP

Ja

Zie de conclusies van WT2-OP

Efficiënte toegang en (gebrek aan) toegang tot informatie. Ter beschikking stellen van data. Gebrek aan centraal en uniform beheer van toegangs- en meetgegevens. Gebrek aan standaardisatie en een centraal federaal/europees standaardisatieorgaan.

Ja Nee Nee

m.b.t. ‘Toegang tot informatie’. Niet behandeld wegens buiten scope WT2 - OP. Wordt reeds behandeld in Umix Structuring.

Input WT3

Issue 5.

Behandeld?

Conclusie WT2-OP

Nee

Niet behandeld wegens buiten scope WT2-OP.

Marktdatamodel: idee van ontwikkelen van een datamodel voor de sector.


50

Marktforum: nood aan een geschikt marktforum om op structurele basis datakwaliteitsproblemen te behandelen Unieke identificatie netgebruiker Voorzien van extra functionaliteiten om de informatiebeschikbaarheid te verhogen.

6. 7. 8.

Nee Ja Ja

Zie de conclusies van WT2-OP m.b.t. ‘Toegang tot informatie’.

5. Ontbrekende meetgegevens en contractloze levering

5.1. .1. Identificatie van de knelpunten Voor het tweede traject van WT2-OP, waarin de verhuisproblematiek centraal stond, werd dezelfde werkwijze gevolgd als voor het eerste traject. De partijen werden verzocht om de belangrijkste knelpunten op te lijsten. De volgende knelpunten werden prioritair bevonden: •

Herschattingen van verbruiken en indexen in het kader van verhuis.

•

Verbruiksverlies tijdens de contractloze periode. Dit is gerelateerd aan de recuperatie van indexen van de vertrekkende klant in het MOZA proces.

Alle partijen waren akkoord dat de problematiek van Mystery Switches niet prioritair is, omdat dit via bilateraal overleg opgelost kan worden (Ref: Notulen WT2-OP Sessie 4, p.10).

De doelstelling was voor bovenstaande knelpunten verbeteringsinitiatieven te identificeren, de krijtlijnen ervan uit te tekenen en ze vervolgens door te verwijzen naar de geschikte fora voor gedetailleerde technische uitwerking. Aangezien de knelpunten sterk aan elkaar gelinkt zijn, werden ze gezamenlijk behandeld.

5.2. Probleemstelling De hoofdoorzaak in deze problematiek is steeds dezelfde, i.e. de startindexen voor de nieuwe klant sluiten niet of onvoldoende aan op de eindindexen van de vertrekkende klant. Bijgevolg kan het verbruik tijdens de contractloze periode ten laste van de leverancier onvoldoende of helemaal niet op de daarvoor verantwoordelijke eindgebruiker verhaald worden.


51

Daarnaast is er een verlies aan marge voor de leverancier van de nieuwe klant wanneer bij een combined switch de aankomstindex te hoog wordt geschat door de DNB.

De rechtzetting ervan zet een rectificatieprocedure in gang, die zowel bij de leveranciers als bij de DNB voor meerwerk zorgt

5.3. Voorgestelde oplossing oplossingen en 5.3.1 Voorstel leveranciers De leveranciers doen een overkoepelend voorstel tot oplossing waarbij de vertrekkende klant de trigger is. Concreet kan dit gerealiseerd worden door de creatie van een nieuw verhuisbericht (extended MOZA) dat de leverancier van de vertrekkende klant toelaat de verhuismelding te verwerken en het verbruik tijdens de contractloze periode gemakkelijker te recupereren. Dit nieuwe verhuisbericht heeft tot doel: 1. Het verkrijgen van een verbruik voor de opmaak van een slotfactuur voor de vertrekkende klant op basis van de meegegeven indexen. 2. Het kenbaar maken van een pending verhuis. 3. Het vastleggen van een referentiekader voor de validatie van indexen en van andere interacties (customer en combined switches, regularisatiedocument, …) tijdens de verdere afwerking van de verhuisprocedure. 4. Het definitief schrappen van de verantwoordelijkheid van de leverancier na x dagen. Dit aantal is vrij te kiezen door de leverancier met een minimum van 30 dagen, zoals wettelijk vastgelegd. Gedurende de periode > 30 dagen mag de DNB zelf geen actie ondernemen om dubbele acties te vermijden. De leveranciers merken op dat dit voorstel neerkomt op een aanvullend maar geen volledig nieuw proces. De huidige customer switch is volgens hen een zeer goed en adequaat proces voor nieuwe klanten maar levert problemen op wanneer men gecontacteerd wordt door een bestaande klant. De leveranciers pleiten voor een pragmatische, procesmatige benadering van deze problematiek.


52

Men moet niet louter naar de gegevensuitwisseling kijken, maar het hele proces in de analyse betrekken (Ref: Notulen WT2-OP Sessie 5, p.3).

.3.2.. Voorstel 5.3.2 Voorstel DNB’s DNB’s Het voorstel van de DNB’s bestaat erin om al vroeger in het proces het aantal problematische verhuizen - en dus het aantal contractloze leveringen - te minimaliseren. De DNB’s willen de klant responsabiliseren en maken hierbij een onderscheid tussen twee situaties wanneer de klant het pand verlaat (Ref: Eandis – contractloze leveringen.doc, Notulen WT2-OP Sessie 5, p.4): 1. Overdracht van verantwoordelijkheid 2. Vraag om afsluiting

4.3.2.1. Overdracht van verantwoordelijkheid De vertrekkende klant draagt de verantwoordelijkheid voor het verbruik op de meter over aan een andere partij. Dit kan gebeuren aan de hand van een verhuisformulier (Ref: Appendix 13: Eandis – contractloze leveringen.doc).

Indien de vertrekkende klant de nieuwe netgebruiker niet kent, dient hij de eigenaar van het pand aan te spreken. De eigenaar zou de verplichting moeten hebben om de verantwoordelijkheid op zich te nemen gedurende de periode die contractloze periode wordt genoemd. De leveranciers moeten dan wel in de mogelijkheid voorzien dat een huiseigenaar een contract van korte duur aan leegstandstarief kan aangaan.

Indien de nieuwe netgebruiker of de eigenaar het verhuisformulier heeft ondertekend, maar nalaat om een contract met een leverancier te ondertekenen, dan kan de leverancier van de vertrekkende klant een MOZA initiëren en de gegevens van het verhuisformulier meesturen in het bericht naar de DNB. De DNB zal de situatie op basis van deze gegevens regulariseren. De oude leverancier kan het verloren verbruik dan recupereren bij de nieuwe klant.


53

Dit voorstel vereist waarschijnlijk een aanpassing van het technisch reglement (betreffende de verantwoordelijkheid van de eigenaar) en van het Freya-akkoord (verzending van een slotfactuur na melding van een verhuis).

5.3.2.2. Vraag om afsluiting Indien de vertrekkende klant geen nieuwe verantwoordelijke voor het verbruik vindt, maar hij wenst toch garanties over zijn slotmeterstanden, dan kan hij een aanvraag doen bij de DNB om de meters te laten afsluiten. Dit gaat wel gepaard met een kost ten laste van de netgebruiker.

Enkel onder bovenstaande voorwaarden is de vertrekkende klant te allen tijde zeker van zijn slotmeterstanden. Indien de klant in één van bovenstaande situaties zijn verantwoordelijkheid niet opneemt, kunnen de slotmeterstanden niet gegarandeerd worden en blijft hij verantwoordelijk voor potentieel verbruik na verhuis.

Daarnaast moet in een klantenwissel steeds een index aanwezig zijn. De DNB’s merken op dat men momenteel in geval van MOZA steeds van een quasi blanco blad moet beginnen. Daardoor wordt in het regularisatieproces veel tijd verloren met de zoektocht naar de nieuwe netgebruiker. Volgens de DNB’s biedt de verplichting tot invullen van het verhuisformulier het voordeel dat men over een naam beschikt die men kan contacteren wanneer zich een probleem voordoet. (Ref: Notulen WT2-OP Sessie 5, p.4).

Volgens de leveranciers is het gebruik van een verhuisformulier echter niet realistisch: de klanten zullen dit al snel als te omslachtig ervaren. De slotfactuur zal bijgevolg niet betaald worden, waardoor men in een dunning proces terechtkomt (Ref: Notulen WT2-OP Sessie 5, p.4). Tot in de jaren ’90 werd met een verhuisformulier gewerkt, en zelfs toen al – in een niet-geliberaliseerde markt – bleek dit volgens de leveranciers niet werkbaar (Ref: Notulen WT2-OP Sessie 6, p.10).


54

5.4. Bespreking Uit de twee voorstellen blijkt dat er twee verschillende visies zijn op wat een haalbare oplossing is: (a) het proces aanpassen zodat indexen vaker op elkaar aansluiten, versus (b) responsabiliseren van de klant (Ref: Notulen WT2-OP Sessie 5, p.4).

De leveranciers maken een onderscheid tussen twee verschillende problemen: (1) het probleem van de captatie van indexen en (2) het zoeken naar een nieuwe gebruiker. Volgens de leveranciers leveren zij alle mogelijke inspanningen om de indexen maximaal te capteren, maar wordt dit belemmerd door het systeem. De slotindex van de vertrekkende klant kan in sommige gevallen niet gebruikt worden als beginindex van de nieuwe klant, louter omwille van systeembeperkingen, hoewel de klant deze slotindex in veel gevallen wel zou aanvaarden. De leveranciers pleiten er daarom voor deze muren in het systeem te slopen, zodat zij meer ruimte hebben om dit te onderhandelen met de klant zelf (Ref: Notulen WT2-OP Sessie 5, p.4).

Momenteel worden MOZA’s uitgestuurd wanneer zich gaps voordoen. Volgens de leveranciers zou men met een aangepast systeem het aantal gaps – en dus het aantal MOZA’s - gevoelig kunnen terugbrengen, wat ontegensprekelijk een win-win-situatie zou zijn (Ref: Notulen WT2-OP Sessie 5, p.4).

Volgens de DNB’s is het voorstel van de leveranciers een ingrijpend voorstel dat het marktmodel fundamenteel wijzigt, aangezien de DNB momenteel niet mag leveren als er geen leverancier is. Zij stellen daarom voor om eerst te onderzoeken vanwaar de zeer grote onderlinge verschillen komen tussen de leveranciers wat betreft het aantal ontbrekende indexen. De leveranciers zijn echter van mening dat hun voorstel niet raakt aan de fundamentele contouren van het marktmodel. Volgens hen schuilt de meerwaarde van hun scenario in de extra validatie, aangezien men over een akkoord van de vertrekkende klant beschikt. In feite introduceert dit scenario een penalisatie van de klant die zijn verantwoordelijkheid niet neemt en nalaat zijn verhuis te melden.


55

Alle partijen zijn het wel eens dat deze problematiek zeker op tafel moet liggen bij het ontwerp van een clearing house tegen 2012. Volgens de Vreg is het nog relevanter om dit punt te koppelen aan het ontwerp van een nieuw datamodel voor de sector (Ref: Notulen WT2-OP Sessie 6, p.10).

5.5. Conclusie Voor de probleemcluster contractloze levering, verhuis en MOZA werden geen quick wins geïdentificeerd op marktniveau. De voorstellen tot oplossing die op tafel liggen hebben een te lange tijdshorizon om als quick win te kunnen worden beschouwd of vergen een wijziging van de bestaande wetgeving en vallen daarom buiten scope van WT2-OP.

Wel was er eensgezindheid tussen de marktspelers over de volgende punten: •

Voorstel van WT2-OP om deze problematiek te koppelen aan de ontwikkeling van een nieuw datamodel voor de sector met 2012 als tijdshorizon.

•

Dit knelpunt wordt als nieuw governance issue opgenomen voor de Vreg. De Vreg wordt verzocht te informeren in hoeverre de plichten en verantwoordelijkheden van de huiseigenaar kunnen worden verankerd in de wetgeving, om zo tussentijdse verbruiken aan de eigenaar te kunnen aanrekenen (Ref: Notulen WT2-OP Sessie 6, p10).

5.6. Doorverwijzing resultaten WT1 en WT3 m.b.t. verhu verhuis is Tijdens de laatste sessie van WT2-OP werden de resultaten van WT1 en WT3 overlopen aan de hand van een checklist (zie Appendix 14). In het bijzonder werd nagegaan of er openstaande punten uit WT1 of WT3 waren die, zonder expliciet in WT2-OP aan bod te zijn gekomen, toch rechtstreeks kunnen doorvloeien naar het Project Comité. De doelstelling was de resultaten van deze voorgaande werktrajecten maximaal te benutten en geen bruikbare voorstellen verloren te laten gaan (Ref: Notulen WT2-OP Sessie 6, p.7).

Wat verhuis betreft, werd in WT2-OP voorgesteld om de volgende scenario’s uit WT3 gegroepeerd door te verwijzen naar Umix voor verdere analyse:


56

•

Scenario 1 - Bijkomende informatie voor validatie: dit scenario houdt in dat aan de berichtuitwisseling een gecodeerde reden wordt toegevoegd waarom een index normaliter in orde zou moeten zijn. In functie daarvan kan de DNB dan grotere of kleinere validatiemarges toelaten. Volgens Umix kan dit scenario zeker als een quick win worden beschouwd en was hierover weinig discussie binnen WT3 (Ref: Notulen WT2-OP Sessie 6, p.9).

•

Scenario 2 – Hercalibratie en monitoring 60-dagen regel: dit scenario houdt in dat de customer switch wordt uitgebreid van 60 naar 90 dagen in het verleden wat de leveranciers toelaat meer te automatiseren en asynchroniteit tussen index en datum te vermijden. In WT3 werd voorgesteld dit scenario gedurende 1 jaar proef te draaien in testpiloot - bij voorkeur op federaal niveau. De DNB’s willen echter niets overhaasten en hieraan eerst een analyse laten voorafgaan waarbij de voor- en nadelen worden afgewogen (Ref: Notulen WT2-OP Sessie 6, p.9).

•

Aanpassing MOZA document: Dit voorstel houdt in dat de index van de vertrekkende klant wordt opgenomen op het MOZA formulier. Aangezien de nieuwe klant steeds de mogelijkheid heeft om de vertrekindex te verwerpen, houdt dit voorstel volgens de leveranciers geen grote risico’s in (Ref: Notulen WT2-OP Sessie 6, p.11).

De volgende scenario’s uit WT3 werden niet weerhouden: •

Scenario 3 – Interactief maken van het validatieproces: dit scenario houdt in dat wanneer de index van een leverancier niet wordt aanvaard, de DNB een vraag tot rectificatie indient vooraleer een schatting te maken. Dit scenario zou gebruikt worden indien scenario 1 niet goed zou blijken te werken. Dit scenario werd door de partijen als niet compatibel beschouwd, omdat het afwijkt van het principe dat een vraag tot rectificatie enkel wordt gericht tot de master van het gegeven (Ref: Notulen WT2-OP Sessie 6, p.9).

•

Scenario 4a – Creatie van een nieuw verhuisbericht: dit scenario is hetzelfde dat door de leveranciers in WT2-OP naar voor werd geschoven. We verwijzen hiervoor naar paragraaf 5.3.1.2. Dit scenario beoogt de creatie van een nieuw verhuisproces waarbij de vertrekkende klant de trigger is (extended MOZA). In WT2-OP werd besloten dat:


57

o Dit voorstel een te lange tijdshorizon heeft om als quick win te kunnen worden beschouwd, en dus buiten de scope van WT2-OP valt. o Deze piste best gekoppeld kan worden aan de ontwikkeling van een nieuw datamodel voor de sector, met 2012 als tijdshorizon •

Scenario 4b - Combinatie van bestaande scenario’s: dit scenario dient samen met scenario 4a behandeld te worden en werd dus niet doorverwezen naar andere fora.

•

Mystery switches: in WT3 werd voorgesteld om een pre-switch proces te installeren en een structureel akkoord te bereiken rond correctie en settlement van mystery switches. Volgens de leverancier was dit een piste waarover weinig discussie bestond. Dit scenario werd door WT2-OP als niet prioritair beschouwd en bijgevolg niet behandeld, omdat dit via bilateraal overleg kan worden aangepakt (Ref: Notulen WT2-OP Sessie 6, p.11).

Tenslotte werd in WT2-OP nog teruggekomen op de afspraak uit WT3 om bilateraal overleg te plegen tussen leveranciers en DNB’s. In WT2-OP werd geconfirmeerd dat bilateraal overleg tussen de partijen aan de gang is of zal plaatsvinden om (1) een vergelijking te maken van het aantal onbestelde meterkaartjes en (2) inzicht te verwerven in ontbrekende/laattijdige informatie en mogelijke opportuniteiten voor procesverbetering (Ref: Notulen WT2-OP Sessie 6, p.11).

In de tabel hieronder worden de conclusies van WT2-OP over de resultaten van WT1 en WT3 beknopt weergegeven. Voor een gedetailleerd overzicht verwijzen we naar de checklist in Appendix 14.

Input WT1 Issue

1.

Complexe processen wegens, volgens de leveranciers, een suboptimale toewijzing van rollen en verantwoordelijkheden.

2.

Kwaliteit van de marktprocessen en de uitgewisselde gegevens.

Behandeld?


Nee

Ja

Conclusie WT2-OP Ontwikkeling van nieuw datamodel met herziening rollen/verantwoordelijkheden is lange termijn en dus buiten scope van WT2 - OP. Zie de conclusie van WT2-OP m.b.t. ‘Toegang tot

58

3. 4.

Ontbrekende meetgegevens Contractloze leveringen

5.

Mystery switches

Ja Ja Nee

netgebruikergegevens’ Zie de conclusies van WT2-OP m.b.t. verhuisproblematiek. Dit kan via bilateraal overleg worden opgelost.

Input WT3

6.

7. 8. 9.

10.

11.

Issue Customer/ combined switch scenario: Scenario 1 - Bijkomende informatie voor validatie Customer/ combined switch scenario: Scenario 2 – Hercalibratie en monitoring 60-dagen regel Aanpassing MOZA document Customer/ combined switch scenario: Scenario 3 – Interactief maken van het validatieproces Customer/ combined switch scenario: Scenario 4a – Nieuw te creëren verhuisbericht Customer/ combined switch scenario: Scenario 4b – Combinatie van bestaande scenario’s

12.

Mystery switches

13.

Bilateraal overleg onbestelde meterkaartjes

Behandeld?


Ja

Ja

Conclusie WT2-OP

Voorstel om deze scenario’s gegroepeerd door te verwijzen naar Umix voor verdere analyse.

Ja Ja

Ja

Ja Nee Ja

Dit scenario wordt als niet compatibel beschouwd en bijgevolg niet doorverwezen. Geen quick win en dus buiten scope van WT2-OP. Voorstel om deze piste te koppelen aan de ontwikkeling van een nieuw datamodel voor de sector (tijdshorizon: 2012). Dit kan via bilateraal overleg worden opgelost. Geconfirmeerd in WT2-OP.

59

APPENDIX 1: Eandis – Probleemanalyse toegang tot informatie APPENDIX 2: SPE – Probleemanalyse onbeperkte toegang toegang tot officiële databestanden APPENDIX 3: Electrabel – Contactadres ownership APPENDIX 4: Electrabel – Toegang tot toegangsregister APPENDIX 5: SPE – Probleemanalyse toegang tot netgebruikergegevens APPENDIX 6: DNB’s – Toegang tot informatie APPENDIX 7: Electrabel – Verbruikspatroon APPENDIX 8: Electrabel – NACE code APPENDIX 9: Electrabel – Sociaal tarief APPENDIX 10: Electrabel – Verhuis – Schattingen APPENDIX 11: Electrabel – Verhuis – Contractloze periode APPENDIX 12: Electrabel – Verhuisproblematiek APPENDIX 13: Eandis – Contractloze leveringen APPENDIX 14: Checklist WT2WT2-OP


Goedgekeurd Eindrapport. Ontwikkeling van een marktmodel voor de Vlaamse energiemarkt fase 1 bis. WERKTRAJECT 2 Operationeel

Recommend Documents