Käyttöönottotyöryhmän kokous 20.11.2017 Käyttöönottosuunnitelman luonnosta päivitettiin kokouksessa alle listatun mukaisesti: Vaiheistus on selkeästi jaettava ja sen on perustuttava tarkistuspisteisiin ja niihin määriteltyihin kriteereihin. Roolit ja mandaatit tässä prosessissa on oltava erittäin selkeät. Tarkentuu myöhemmin, päivitetään käyttöönottosuunnitelman versioon 2.0. Käyttöönoton vaiheistusluvussa sanotaan: "Näiden pohjalta voidaan laatia erilaisia tehtävä- ja tarkistuslistoja.." Käyttöönottoprojektiko laatii osapuolille ko. listoja? Käyttöönottosuunnitelmaan tullaan lisäämään käyttöönottotyöryhmässä tunnistettuja tehtäviä osapuolille, lisätään kohtaan viittaus suunnitelmasta löytyvään tehtävälistaan. Big bang -termin käyttö herätti ihmetystä, sillä puhutaan kuitenkin prosessikohtaisesta vaiheittaisesta alas-ajosta. Lisätään perustelut vaiheittaisesta alasajosta (jatketaan prosesseja mahdollisimman pitkään ja minimoidaan manuaalinen työ). Lisätään viittaus Käyttöönoton linjaukset -lukuun, missä asia on käsitelty tarkemmin. Tarkempi prosessikohtainen kuvaus päivitetään versioon 2.0. Käyttöönoton valmistelua kommentoitiin: Tämä ei ole kuvattuna lainkaan riittävällä tasolla vielä. Myös kuvaa tulisi muokata havainnollisemmaksi nyt siitä on erittäin vaikea saada todellista kokonaiskuvaa mm aikajanat ovat varsin tulkinnanvaraisia. Tiedostettu, päivitetään versioon 2.0 kun hankintapäätös on tehty. Miten järjestelmän sertifiointi hoidetaan? Järjestelmän sertifiointi olisi laajempi testi, mutta toimijan sertifiointi kevyempi prosessi. Vai testaavatko kaikki toimijat kaikki prosessit erikseen? GSRN käyttöönotto näyttäisi olevan jo paljon ennen datahub go liveä? Päivitetään versioon 2.0 Datahub-järjestelmän testaussuunnitelman mukaisesti. GSRN-tunnuksia ei käytetä PRODAT-sanomissa ennen käyttöönottoa, mutta tarvitaan tietokonversion iteraatiossa 3. Käyttöönoton valmistelun vaiheistus ja viitteellinen aikataulu -taulukon esitystapa ei ole kovin havainnollinen. Voisiko tätä ehkä esim. paloitella? Mitä aikamääreitä tässä on? Päivitetään versioon 2.0, kun hankintapäätös on tehty ja voidaan tarkentaa. Sertifioinnin menettelystä, laajuudesta ja ajankohdasta olisi tarpeellista saada lisätietoa mahdollisimman pian, koska se on yksi osakokonaisuus osapuolen käyttöönottosuunnitelmassa Aikataulu päivitetään versioon 2.0, kun hankintapäätös on tehty. Myyjien riippuvaisuus verkkojen GS1-kooditoimituksista. Ei pysty aloittamaan prosessia ennen kuin kaikilta verkoilta on saatu uudet koodit. Mahdotonta hallita
joidenkin manuaalisten taulukkojen perusteella. Asiakkaille toimitettava vahvistusilmoitukset viivytyksettä. Päivitetään versioon 1.0, lisätään viittaus prosessityöryhmän ohjeistukseen. GSRN-tunnuksia ei käytetä PRODAT-sanomissa ennen käyttöönottoa, mutta tarvitaan tietokonversion iteraatiossa 3. "GSRN-tunnusten käyttöönotto on suunniteltu tehtäväksi datahubin käyttöönoton yhteydessä. GSRN-tunnusta ei tulla lisäämään olemassa oleviin sanomamäärittelyihin, sillä se vaatisi merkittäviä muutoksia nykyiseen, datahubin käyttöönoton jälkeen poistuvaan tiedonvaihtoon." Osapuolten järjestelmissä on oltava myös GS1-tunnusten käyttöönoton osalta valmius palata takaisin point of no return - pisteeseen saakka. Lisätään osaksi paluusuunnitelmaa. "Tietokonversioiteraation 3 jälkeen jakeluverkonhaltijoiden on luotava sekä vanhan että uuden mallin mukaiset käyttöpaikkatunnukset kaikille uusille käyttöpaikoille. Markkinaosapuolet ylläpitävät järjestelmissään sekä uutta että vanhaa käyttöpaikkatunnusta." Tuotannossako? aiemmin linjattiin, että GSRN:ää ei oteta tuotantoon aiemmin. Hyvä sinänsä jos saadaan verkoilta lukkoon lyödyt GSRN:t myyjille, saataisiin konversiot tehtyä jo ennen datahubiin. Päivitetään versioon 1.0, lisätään viittaus prosessityöryhmän ohjeistukseen. GSRN-tunnuksia ei käytetä PRODAT-sanomissa ennen käyttöönottoa, mutta tarvitaan tietokonversion iteraatiossa 3. Käyttöönottosuunnitelman väliraportissa lukee: Fingrid ylläpitää taulukkoa, jossa vanhan ja uuden mallin mukaiset käyttöpaikkatunnukset on linkitetty toisiinsa. Nykyinen käyttöpaikkarekisteri ajetaan alas myöhemmin datahubin käyttöönoton jälkeen." Tarkoitetaanko Fingridin ylläpitämällä taulukolla konversion iteraatio 3 vaiheessa mainittua taulukkoa? Se on sidoksissa konversiotoimituksiin, joten miten GSRN tunnusten toimitus ja jakelu hoidetaan konversiotoimitusten välillä? Kappaleessa mainitaan nykyinen käyttöpaikkarekisteri, tuleeko sinne myös GSRN tunnukset? Lisätään maininta, että nykyiseen kp-rekisteriin ei tule GSRN-tunnuksia. Point of no return pitäisi olla ennen muutoshetkeä. siinä vaiheessa kun lähdetään purkamaan puskureita, ei voi enää peruuttaa takaisin PRODAT-maailmaan. Täsmentyy viimeistään versioon 2.0, siirretään pistettä kuvassa. Käyttöönottovaiheiden kuvauksesta puuttuu useita päätöksenteko-kohtia, esim. valmistautumisvaiheen alkaminen, siirtyminen ydinjäädytysjaksoon ja lupa aloittaa prosessien ylösajo. Lisäksi olisi lisättävä smoke test, jolla varmistetaan, jotta voidaan siirtyä puskureiden purkamiseen, Point of no return on oltava viimeinen asia jäädytysjaksolla. Puskuria aletaan tyhjentää vasta point of no returnin jälkeen. Lisätään tarkennus: päätöksentekokriteerit ja tarkistuspisteet tarkentuvat myöhemmin, kyseessä ylätason kuvaus jäädytysjaksosta.
Jos eri prosesseilla eri jaksot, voi olla haasteellinen hallittava. Jos on eri aikaan, pitää piirtää selkeä aikajana, milloin mikäkin prosessi sammutetaan. Vaikuttaisi siltä, että prosessikohtainen jäädytysjakso vaatii erilliskehitystä sekä hankaloittaa aikajanojen hallintaa. Lisätään tarkennus, että kuvataan tarkemmin prosessi- ja sanomakohtaisesti versioon 2.0. Miten ja millä järjestelmillä näin laaja kokonaisuus testataan ja kenraaliharjoitellaan? Määritellään markkinaosapuolten omissa käyttöönottosuunnitelmissa ja kenraaliharjoitukset testaussuunnitelmassa. Käyttöönoton syyskuuhun ajoittuessa valmistautumisjakso olisi elokuun puolella, joka on lomakaudella. Pääsiäiseen ajoittamalla saataisiin hyödynnettyä muutenkin hiljainen aika asiakaspalvelun suhteen ja jo oletettavasti kiinni olevat asiakaspalvelukanavat-> asiakasvaikutus mahdollisimman pieni. Päivitetään: "ensisijaisesti maaliskuussa ja vaihtoehtoisesti lokakuussa". Tarkennetaan, että kyseessä on käyttöönottotyöryhmän on ehdotus: "..ehdottaa Datahub-hankintaprojektille". Poistetaan maininta, että syyslomia on vältettävä. Lisätään markkinaosapuolten tehtävälistoihin maininta, että käyttöönoton ympärille (ennen ja jälkeen) on hyvä varata ylimääräisiä resursseja. Käyttöönottosuunnitelman väliraportissa ehdotettiin Datahubin käyttöönotto toteuttavaksi maaliskuussa tai vaihtoehtoisesti syyskuussa. Paras ajankohtina nähtiin kuukauden keskivaihe 10. 21.päivä. Tuli useita muitakin ehdotuksia ja kommentteja esim. 14.-25. päivä, jotta edellisen kuukauden mittaustiedot saataisiin luettua laskutusta varten. Käyttöönottoajankohta nostetaan seuraavan Energiateollisuus ry:n tiedonvaihdon menettelytapojen kehitysryhmän sekä Fingridin tiedonvaihdon kehitysryhmän yhteiskokouksen agendalle (28.11). "Eri syistä johtuvat viiveet (esim. win-back-soitot ) sanomien käsittelyssä lisäävät muutoslokeihin puskuroitavan tiedon (=työjonojen) ja siten myös manuaalisen työn määrää. " Katsooko käyttöönottoryhmä winback-prosessin tarpeettomaksi? Otetaan väliraportissa ollut esimerkki pois, jottei aiheuta epäselvyyksiä että katsottiin tarpeettomiksi. Väliraportissa sanotaan: "Markkinaosapuolet puskuroivat ydinjäädytysjaksolla markkinaprosesseihin liittyvät aikaleimatut tapahtumat ja muuttuneet tiedot omien järjestelmien ja sovellusten lokeihin". Järjestelmätoimittajan näkökulmasta tarkoittanee: EDIEL sanomien sisäänluku järjestelmätasolle keskeytetään. Ydinäädytysjakson jälkeen jäädytysjakson aikana saapuneet sanomat luetaan sisään, mutta sen sijaan että käynnistettäisiin tiedonvaihtoprosesseja, käynnistetäänkin Datahub prosesseja. Isovaikutteinen muutostyö pientä ajanjaksoa varten. Voidaanko miettiä muuta toimintatapaa? Versioon 1.0 pyritään kuvaamaan tarkemmin, mitä puskurilla tarkoitetaan. "Markkinaosapuolten ei tarvitse kuitenkaan ottaa kantaa siihen, kenen puskureista tiedot datahubiin puretaan. Tämä tapahtuu datahubissa automaattisesti
datahubin määrittelemillä säännöillä. " Mitä tämä tarkoittaa? Automatiikkaa puskurien tyhjentämiseen ei ainakaan datahubissa voi olla. Tarkoitetaanko sitä, että tiedot käsitellään datahubissa normaalien sääntöjen mukaisesti? Miten tässä huomioidaan se, että eri osapuolten tapahtumat käsitellään oikeassa järjestyksessä? Kuka on ensimmäinen sopimuksen tekijä? Tarkennettu, päivitetty käyttöönottosuunnitelman versioon 1.0. "Järjestelmälokeihin puskuroidut tiedot tulee purkaa datahubiin muutoshetken jälkeen viivytyksettä mutta viimeistään ensimmäisenä arkipäivänä muutoshetken jälkeen". Onko tämä ihan kohtuullista isoilla massoilla? Lisätty tarkennus, että isoilla massoilla tämän oletetaan olevan toteutettu järjestelmien avulla. "Muutosten ilmoittaminen takautuvasti (menneillä aikaleimoilla) datahubiin sallitaan määriteltyjen tapahtumien ja korjaustilanteiden osalta käyttöönoton jälkeen tilapäisesti. Tässä on oltava selkeä aikaraja ja säännöt. Lisätään huomio, että tarkennetaan versioon 2.0. "Ydinjäädytysjaksolla ensisijainen tiedonvaihtotapa on sähköposti...". Onko ediel.fi käyttöpaikkarekisteri käytettävissä? Lisätään huomio, että versiossa 2.0 tarkennetaan GS1-tunnusten osalta, mistä löytyvät. "Sanomaliikenne korvataan muilla kanavilla tapahtuvalla tiedonvaihdolla, joista ensisijaisia ovat sähköposti ja puhelin." Ensisijaisesti sähköposti? Kyllä, tarkennus päivitetty versioon 1.0. "Muun muassa seuraavat markkinaprosesseihin liittyvät tiedot on tunnistettu välttämättömiksi välittää toisille markkinaosapuolille myös ydinjäädytysjaksolla...". -> FG datahub projektin pitää tuottaa yksiselitteinen listaus mitkä ovat pakolliset tiedot eri tapauksissa. Tarkennettu / päivitetty versioon 1.0. "Ydinjäädytysjaksolla ensisijainen tiedonvaihtotapa on sähköposti...". Mitä tietoja tämä koskee? Onko huomoitu tarvittava tietoturva ja -suoja sähköpostipohjaisessa tiedonvaihdossa (erityisesti asiakas- ja sopimustiedot)? Ohjeistetaanko salaamaan sähköpostit? Lisätään huomio, että sähköpostien tulee olla salattuja. Lisätään markkinaosapuolille tarkoitettuihin tehtävälistoihin maininta, että markkinaosapuolten sähköpostien tulee tukea salausta. "Ydinjäädytysjaksolla ensisijainen tiedonvaihtotapa on sähköposti...". FG datahub projektin tehtäväksi: viestipohjat (sähköpostien malliviestit), jota kaikki käyttävät. Ja sääntö: Jos pyyntö ei ole mallin mukainen, osapuoli saa jättää sen huomioimatta.
Lisätään huomio, että käyttöönottotyöryhmä määrittelee sähköpostipohjat, jotka ovat käytettävissä ennen käyttöönottoa. " Ydinjäädytysjaksolle ajoittuvan myyjänvaihdon käynnistäminen ei ole sallittua sanomalla (Z03[1]), mikäli myyjänvaihtoprosessin ydinjäädytysjakson alkuun on aikaa alle 7 päivää (5 arkipäivää).)." Yksiselitteisyyden vuoksi voisi aina puhua vuorokausista. Päivitetään päivät vuorokausiksi, mutta jätetään arkipäivät. "Mikäli myyjänvaihtoprosessia ei ole saatu kokonaan päätökseen (Z04[1] lähetetty) ennen ydinjäädytysjaksoa, toimitaan, kuten myyjänvaihtoa ei olisi tapahtunutkaan. Uuden myyjän tulee käynnistää myyjänvaihtoprosessi uudelleen datahubissa." - Miten nykyinen myyjä voi tietää, että jo vahvistettu päättäminen ei toteutunutkaan? Jos myyjälle on lähetetty Z05[1], johon on vastattu Z08[1], on prosessi nykyisen myyjän näkökulmasta viety loppuun. Jos Z04[1] jää jostain syystä menemättä uudelle myyjälle, ei tästä vanhalle tule tietoa. Päivitetty: "Mikäli prosessi jää kesken Z08[1]-sanoman lähetyksen jälkeen, verkonhaltijan tulee ilmoittaa nykyiselle myyjälle myyjänvaihdon peruuntumisesta." " Myyjänvaihtoon liittyvä toimitus voi alkaa (tai päättyä) ydinjäädytysjaksolla, mikäli myyjänvaihtoprosessi on saatu päätökseen ennen ydinjäädytysjaksoa."* Yksiselitteisyyden vuoksi, onko prosessi päätöksessä, kun Z04 on vastaanotettu? Tarkennettu & päivitetty versioon 1.0. "Mikäli toimituksen aloitus peruuntuu ydinjäädytysjaksolla, peruuttavan myyjän tulee ilmoittaa peruutuksesta sähköpostilla jakeluverkonhaltijalle ja edelleen palautettavalle myyjälle. Osapuolten tulee varmistaa, ettei asiakas jää myyjättömäksi." Mitä tällä toimenpiteellä haetaan, jos ilmoitus tulee myöhemmin datahubista? Tarkennettu & päivitetty versioon 1.0. "Mikäli toimituksen aloitus peruuntuu ydinjäädytysjaksolla, peruuttavan myyjän tulee ilmoittaa peruutuksesta sähköpostilla jakeluverkonhaltijalle ja edelleen palautettavalle myyjälle. Osapuolten tulee varmistaa, ettei asiakas jää myyjättömäksi. " Emme näe perustetta muuttaa normaalia prosessia ydinjäädytysjaksonkaan ajalle. Peruuntuvan sopimuksen myyjä ilmoittaa verkolle ja verkko vanhalle myyjälle. Uusi/peruuntuva myyjä ei voi ottaa kantaa siihen mikä on edellinen myyjä. Tarkennettu & päivitetty versioon 1.0.