Pöytäkirja 1 (5) Datahub - tietokonversiotyöryhmän kokous Aika 18.5.2017 klo 8.00 14.00 Paikka Läsnä, Läkkisepäntie, Helsinki Jari Jaakola Erika Lietzen Hannu Santala Jukka Luoma Saila Turunen Minna Pajunen Sari Wessman Jaakko Lehtomäki Katja Repo Tia Kautto Fredrik Södö, pj Jukka Rinta-Luoma Lauri Jännes, siht. Pohjois-Suomen Energiatieto Oy Caruna Oy Fortum Markets Oy Suomen Voimatieto Oy Pohjois-Karjalan Sähkö Oy KSS Energia Oy Jyväskylän Energia Oy Elenia Oy Nivos Oy Vattenfall Oy Poissa Birgitta Polojärvi Loiste Sähkönmyynti Oy Pöytäkirjaan on tehty muutamia tarkennuksia 19.6. 1. Työpajan avaus, agenda, läsnäolijat Puheenjohtaja avasi kokouksen 8:00 ja esitteli päivän agendan 2. Edellisen kokouksen muistio Rinta-Luoma kävi läpi edellisen työpajan muistion ja silloin Fingridin vastuulle sovittujen tehtävien tilanteen. Kuolinpesä herätti jälleen keskustelua. Puheenjohtaja totesi, että prosessin näkökulmasta kuolinpesätieto sukunimen yhteydessä ei aiheuta ongelmaa. Konversion kannalta tämä on kuitenkin todella iso ongelma. Tietokonversio -projekti haluaa kuolinpesätiedon pois sukunimen yhteydestä ja tiedon redundanttisuus on myös ongelma. Wessman totesi, että kuolinpesä tiedon poistaminen aiheuttaa ongelmia monille toimijoille, koska järjestelmissä ei ole paikkaa kyseiselle tiedolle. Puheenjohtaja sanoi, että Datahubiin ei ole järkevää toteuttaa logiikkaa sukunimikentän parsimiseen. Puheenjohtaja kertoi, että prosessiryhmä on ehdottanut asiointitavan siirrettävän asiakastiedoista sopimustietoihin. Puheenjohtaja sanoi, että ET:n näkemyksen mukaan tämä tieto sopimustiedoissa on ongelmallinen ja voi olla että koko asiointitapa tieto poistuu Datahubista.
Pöytäkirja 2 (5) Aputoiminimien käytöstä sopimuksissa keskusteltiin myös. Sopimusosapuolen tuli siis olla varsinainen yhtiö, eikä sopimuksia ei voisi tehdä aputoiminimellä. Sopimus siis tulisi tehdä Y-tunnuksen varsinaisen haltijan kanssa eikä aputoiminimiä saa käyttää, aputoiminimi käyttää samaa Y-tunnusta kuin varsinainenkin yhtiö, sopimustiedoissa voidaan sitten tarkentaa tätä tietoa. Santala kysyi, eikö aputoiminimi löydy YTJ:stä? Puheenjohtaja vastasi, että löytyy kyllä mutta useat sopimukset samalla Y-tunnuksella, mutta eri toiminimillä, aiheuttavat ongelmia. Lietzen pohti, että tämä varmaan vaatii asiakaskommunikointia, koska tällöin nimi muuttuu sopimuksella. Toivottiin, että prosessiryhmä ottaa tämän asian pohdittavakseen. Puheenjohtaja kertoi, että VRK:n rekisteriä ei voida hyödyntää, mutta käytetään palveluntarjoajaa, joka on todennäköisesti halvempi. On myös olemassa yhdenluukun palveluita, joista löytyy sekä henkilötiedot ja Y-tunnukset. Puheenjohtaja kertoi, että VRK:n rekisterissä on kiinteistötunnus kaikille rakennuksille ja tätä tietoa voidaan mahdollisesti hyödyntää osoitetietojen tarkistuksessa. Lietzen kysyi, onko kesämökeille myös kiinteistötunnus VRK:n rekisterissä? Tämä on vielä epäselvää, mutta jos sellainen löytyy, helpottanee se osoitetietojen tarkistusta. Puheenjohtaja kertoi, että lakimuutoksen osalta työ käynnistynyt ministeriössä ja luonnos lähtee lausuntokierrokselle kevään aikana. Jaakola kysyi, kuinka kauan lausuntokierros kestää? Puheenjohtajalla ei ollut tästä tietoa. 3. Kyselyiden tilanne Jännes esitteli lyhyesti seurantakyselyiden tilanteen. Ensimmäiseen kyselyyn on vielä joiltain osapuolilta vastauksia saamatta, vastausprosentti on tällä hetkellä n. 90 %. Toisen kyselyn takaraja oli 1.4. ja siihen on tähän mennessä tullut 70 vastausta verkoilta ja 62 vastausta myyjiltä, verkkojen vastausprosentti on siten 91% ja myyjien 79%. Jännes kertoi myös, että kolmas ja viimeien seuranta kysely tullaan lähettämään vielä kuluvan viikon aikana ja sen vastausten takaraja on 1.7.2017. Kolmannessa kyselyssä tullaan keskittymään järjestelmä päivityksiin ja muutoksiin sekä niiden aikatauluun. Kyselyssä kysytään myös poimintatyökalujen tilanteesta ja tietojen korjaamisen automatisoinnista. Kolmannen kyselyn tietoja järjestelmä päivitysten ja muutosten aikatauluista tullaan huomioimaan konversiopalvelun aikataulun suunnittelussa. Luoma kysyi vastausten luottamuksellisuudesta. Kaikki vastaukset tullaan käsittelemään luottamuksellisesti eikä yksittäisen yhtiön tietoja tulla julkaisemaan missään. Vastauksista tullaan julkaisemaan koko alaa koskevia keskiarvoja ja yhteenvetoja, mutta näistä ei kuitenkaan voi yksittäistä yhtiötä tunnistaa. Fingrid pitää myös avointa listaa kyselyihin vastanneista ja vastaamatta jättäneistä yhtiöistä. 4. Tietokonversiohankinnan tilanne Puheenjohtaja kertoi Tietokonversion hankinnan tilanteesta ja aikataulusta. Alustavat tarjoukset saatiin maaliskuun puolessavälissä ja neuvottelut tarjoajien kanssa saatiin päätökseen huhtikuussa. Lopulliset tarjoukset saatiin viikolla 19 ja hankintapäätös tehdään näillä näkymin viikolla 21. Päätöksen jälkeen odotusaika on 21 päivää, joka sisältää 14 päivän valitusajan. Odotusajan jälkeen voidaan allekirjoittaa
Pöytäkirja 3 (5) sopimus. Odotusaikana ei voida millään tavalla edistää tietokonversiopalvelua yhdessä valitun toimittajan kanssa. Tietokonversiopalvelu tullaan pystyttämään tämän vuoden aikana ja tietokonversiotyöryhmä osallistuu demotilaisuuksiin, jotta toimiala pääsee vaikuttamaan erityisesti käyttöliittymän toteutukseen. Palvelu tullaan tietoturva-auditoimaan ennen käyttöönottoa. Turunen kysyi, onko tarkoitus, että ensimmäisessä iteraatiokierroksessa on kaikki tiedot toimitettu konversiopalveluun kerran vai riittääkö, että jotain tietoa on toimitettu palveluun. Puheenjohtaja vastasi, riittää, että jotain tietoa on toimitettu ja lisäsi, että auditointi tuo epävarmuutta palvelun käyttöönotto aikatauluun ja aikataulua tullaan tarkentamaan myöhemmin lisää. 5. Ryhmätyö Sopimustietojen yhdenmukaistaminen Puheenjohtaja alusti ryhmätyön, jonka tehtävän oli pohtia pienryhmissä sopimustietojen yhdenmukaistamista ja pohtia miten päätetään, mikä tieto viedään Datahubiin jos lähtötiedoissa on ristiriitoja. Puheenjohtaja myös totesi, että sopimustiedot sinänsä eivät ole mielenkiintoisia, mutta riippuvuudet muihin tietoihin tuovat monimutkaisuutta sopimustietoihin. Rinta-Luoma alusti henkilötietojen ja sopimustietojen välisen ongelman mahdollisten ristiriitojen tapauksessa. Turunen kysyi, että ainakin syksyllä sanottiin, että verkon tiedot viedään Datahubiin, onko tämä asia vielä auki? Turunen myös totesi, että pitäisikö tässä ottaa tavoitteeksi toimittaa paras tieto. Todettiin, että parhaan tiedon määritteleminen voi joissain tapauksissa olla hankalaa. Ryhmillä oli 40 minuuttia aikaa pohtia asiaa, jonka jälkeen läpikäyntiin oli varattu aikaa tunti. Ryhmässä heräsi todella paljon keskustelua tietojen yhdenmukaistamisesta ja korjaamisesta. Tässä tärkeimpiä nostoja eri osa-alueista. Todettiin, että sopimusten voimassaoloissa voi olla paljonkin poikkeamia ja ehdotettiin, että näiden virheiden etupainotteinen selvittäminen tasesarjoilla voisi olla järkevää. Puheenjohtaja kannatta ajatusta ja ehdotti, että tähän olisi varmaan hyvä saada jonkinlainen ohjeistus ET:ltä. Lehtomäki totesi, että myyjä voi pyytää verkolta listauksia myynnissään olevista käyttöpaikoista, vertaillakseen tietojaan verkon tietojen kanssa. Osa myyjistä ei tällä hetkellä pyydä tätä tietoa koskaan ja ehdotettiin, että verkot voisivat alkaa lähettää listoja myyjille pyytämättäkin. Listojen avulla voitaisiin saada korjattua eri myyjien päällekkäiset sopimukset pois järjestelmistä, jotta ne eivät aiheuttaisi konversiossa virheitä. Sopimusten alku- päättymispäivät voivat myös aiheuttaa ongelmia, koska yhtiöt tallentavat tiedot eri tavalla järjestelmiinsä, vaikka sanomaliikenteessä tiedot menisivätkin täysin oikein. Lehtomäki ehdotti, että ainakin olisi helppo tarkistaa sopimusten alku- ja päättymisajankohtien ajoittuminen vuorokauden vaihteeseen. Muuttojen siirtyminen voi myös aiheuttaa eroja päivämäärissä. Todettiin myös, että kaikki ristiriitaisuudet ovat merkittäviä, koska virheillä saattaa olla vaikutusta taseisiin koko 6 vuoden ajalta, jolta tieoja viedään Datahubiin. Asiakkaan nimessä esiintyvät erot voivat olla todella hankalia, koska asiakas voi käyttää eri nimeä tai vain osaa virallisesta etunimestä. Samoin, jos on useampia asiakkaita samalla käyttöpaikalla, voi myyjällä olla tiedossa vain yksi henkilötunnus ilmoitettuna. Ongelmia tulee varsinkin, jos usealla toimijalla on henkilötunnus tiedossa, mutta tiedot muuten poikkeavat. Ryhmässä heräsi kysymys, voidaanko pitää kiinni periaatteesta, että asiakas on yksilöity vain kerran Datahubiin. Verkon pitäisi
Pöytäkirja 4 (5) voida helpommin ilmoittaa, kuka on sen mielestä myyjä käyttöpaikalla. Tällä hetkellä toisen myyjän tietoja ei saa kilpailijalle kertoa, sama koskee ristiriitaisia asiakastietoja. Tällä hetkelläkin myyjän pitäisi tarkistaa Z04 -sanomasta asiakkaan nimi, jos nimi eroaa tämä tulisi selvittää. Näin ei aina tehdä. Todettiin myös, että asiakaskommunikaatio voi olla hankalaa, jos usealla osapuolella on poikkeavat tiedot oletettavasti samasta asiakkaasta. Ovatko kaikki yhteydessä asiakkaaseen vai koordinoiko joku yhteydenottoja. Tähän olisi hyvä saada ohjeistus ET:ltä. Käyttöpaikan keskeytyskriittisyys herätti paljon näkemyksiä. Keskeytyskriittisyyden ilmoittavat sekä myyjä että verkko. Ryhmässä keskusteltiin paljon siitä, että pitäisi riittää, että vain toinen ilmoittaa keskeytyskriittisyyden. Todettiin kuitenkin myös, että ylipäätään tämä tieto voi aiheuttaa paljon ongelmia Datahubissa, koska Datahubissa on vain yksi boolean tyyppinen kenttä keskeytyskriittisyydelle, kyllä/ei. Todellisuudessa yhtiöillä voi olla useita eri kriteerejä eri tasoisille keskeytyskriittisyysmääritelmille ja nämä ovat hyvin yrityskohtaisia ratkaisuja. Verkolla voi olla hankaluuksia varmistua käyttöpaikan todellisesta keskeytyskriittisyydestä. Puheenjohtaja sanoi, että konversiossa voidaan toki tarkastaa, jos myyjän ja verkon tiedot poikkea käyttöpaikan keskeytyskriittisyydessä. Sovittiin, että katkaisuuskriittisyys ja sen ilmoittaminen Datahubissa viedään prosessiryhmän käsiteltäväksi. Puheenjohtaja muistutti ryhmäläisiä myös, siitä että tietojen oikeellisuus on jatkossa entistäkin tärkeämpää. Tämä vaatimus on myös tulevana tietosuoja-asetukseen. 6. Mittaustietojen toimitus ja tarkistus Puheenjohtaja kertoi, että siirtotiedosto-ohjeistus on päivitetty loisenergian osalta ja tähän liittyvät esimerkit on myös lisätty ohjeistukseen. Konversiossa ei kuitenkaan tulla vaatimaan loisenergian tuontia. Puheenjohtaja esitteli mittaustietojen tietokonversioprosessin ja tarkistussumman hyödyntämisen. Wessman kysyi, onko SAF-formaattiin mahdollista saada samanlaista summatietoa kuin on MSCONS:ssä käytössä? Puheenjohtajan mukaan SAF ei sisällä summatietoa ja siksi tietojen lähetyspäähän on saatava erillinen summatietojen laskentatyökalu. Näiden summasarjojen kautta voidaan tarkistaa tiedostojen eheys ja oikeellisuus erittäin tehokkaalla tavalla. Tietojen jatkuva muuttuminen lähdejärjestelmissä tulle aiheuttamaan ongelmia, koska tiedoston luonnin jälkeen tiedot voivat muuttua ja tiedoston sisältö ei vastaa enää lähdejärjestelmää. Jaakola kysyi, miten teollisuus- ja alueverkot aiotaan hallita Datahubissa, koska taseselvitys voidaan tehdä vain, jos kaikista verkoista on riittävät tiedot. Sovittiin, että selvitetään prosessiryhmän kanssa, miten menetellään teollisuus- ja alueverkkojen kanssa Datahubissa. Alueverkoissa ja teollisuusverkoissa ei kuitenkaan toimita samalla tavalla kuin vähittäismarkkinoilla. Tuotantoverkot toki ovat Datahubissa, mutta ne mallinnetaan tuotantoyksikköinä. Puheenjohtaja huomautti, että käyttöönottosuunnitelmassa täytyy huomioida paljoin asioita, jotta saadaan taseet kuntoon ja summasarjat täsmäämään. Näiden lisäksi olisi hyvä saada myös häviöt laskettua. Datahubissa ei voida välttämättä laskea häviöitä oikein, koska lähtötilanne lähdejärjestelmissä pitäisi tietää tietojen poimimisen hetkellä. Poikkeamat voivat johtua isosta virheestä, vaikka poikkeama olisikin itsessään pieni.
Pöytäkirja 5 (5) Jaakolla kysyi, eikö kannattaisi pohtia, miten häviöt saataisiin oikein. Puheenjohtaja totesi, että haluaisi päivittää suunnitelmaa siten, että saadaan taseet ja häviöt laskettua oikein ja samoin siis summasarjat. Wessman totesi tähän, että jos lasketaan 6 vuotta taaksepäin ei arvoja saada mitenkään täsmäämään. Häviösähkön laskentasääntö on muuttunut verkkoyhtiökohtaisesti. NBS:n myötä häviölaskenta standardoituu. Häviöitä ei voida tarkistaa ajalta ennen NBS:n käyttöönottoa. Puheenjohtaja kysyi, pystyttäisiinkö mitenkään tarkistaa arvotasolla aikasarjoja. Jaakola totesi tähän, että NBS:n myötä lasketaan häviöprosentti auki ja lasketaan profiilien 1, 2 ja 3 summat yhteen. Puheenjohtaja sanoi olevansa samaa mieltä, että olisi hyvä, jos laskettaisiin häviöt ja häviöistä lähtien voitaisiin tarkistaa tietojen oikeellisuutta. Puheenjohtaja havainnollisti tietojen poimintaan ja poimittujen tietojen käsittelyyn kuluvaa aikaa kuvalla ja kysyi, miten poiminnan aikana tapahtuneet muutokset hallitaan? Tallennetaanko ne johonkin poiminnan ajaksi, jonka jälkeen muutokset voidaan käsitellä Datahubissa? Puheenjohtaja myös totesi, että taseet eivät välttämättä ole täysin kunnossa Datahubin käyttöönotosta eteenpäin, mutta taseikkunaa ei voida pitää pitempään auki johtuen NBS:stä. Jaakola ehdotti, että, eikö jokainen voisi laskea itse omat taseensa siihen asti, että kaikki muu saadaan ensin toimiaan Datahubissa. Puheenjohtaja sanoi, että Datahubissa voidaan mahdollisesti toteuttaa taseen varjolaskenta ja annetaan tilanteen tasoittua, jossain vaiheessa vastuu siirretään Datahubille. Jaakola sanoi, että tässä on myös vastuu kysymys, kuka vastaa virheestä? Onko Datahub vastuussa vai verkko tai joku muu? Puheenjohtaja totesi myös, että pitää myös pohtia mitä tiedostoformaattia käytetään tietojen tuontiin. Toivottiin myös, että suuren tietomäärän lataaminen toteutettaisiin vain kerran, jonka jälkeen hallittaisiin vain muutoksia. Joillain toimijoilla voi suuren tietomäärän takia mennä tietojen keräämiseen todella paljon aikaa, mikä voi aiheuttaa suorituskyky ongelmia. 7. Jatko Seuraava työpaja sovittiin pidettäväksi 21.6, jolloin myös tietokonversiopalvelun toimittajan olisi tarkoitus osallistua työpajaan. Toimittaja esittää ratkaisunsa ja silloin sovitaan loppuvuoden aikataulusta tarkemmin. Jakelu Läsnäolijat