"Effektivt sluttbrukermarked for kraft" (pdf.) - NVE
"Effektivt sluttbrukermarked for kraft" (pdf.) - NVE
"Effektivt sluttbrukermarked for kraft" (pdf.) - NVE
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
ealistisk å få på plass en datahub løsning til 01.10.15, hvis kravspesifikasjonen starter<br />
tidlig høsten 2012.<br />
Kravspesifikasjon (inkludert anbudsunderlag <strong>for</strong> kommunikasjonshub): 10-12<br />
mnd.<br />
Anbudsrunde: 3-5 mnd.<br />
Implementering av datahub og tilpasning av aktørenes løsninger: 12–18 mnd.<br />
Test og verifikasjon: 4-6 mnd. (i tillegg til en start parallelt med<br />
implementering)<br />
10.3 Overgangsordning<br />
10.3.1 Kommunikasjonshub<br />
Med en kommunikasjonshub vil funksjonaliteten tilgjengeliggjøres av aktørene, slik at<br />
en eventuell overgangsløsning vil kunne ha <strong>for</strong>m som en fasedelt flytting av<br />
kommunikasjon rundt prosessene fra dagens mange-til-mange kommunikasjon til en<br />
kommunikasjon via en kommunikasjonshub. Det er lite sannsynlig av en fasedeling av<br />
implementering av en kommunikasjonshub vil påvirke totalt kost eller tid i vesentlig<br />
grad verken opp eller ned. Grunnen til dette er at når motoren er på plass, er<br />
implementeringen av nye prosesser og meldinger relativt enkel. Det vil være en<br />
tilleggskostnad <strong>for</strong> å kjøre prosjektet, men samtidig reduseres risikoen og<br />
test/verifisering <strong>for</strong>enkles per fase. En kan velge å gjøre dette av praktiske og risikomessige<br />
grunner, men ikke <strong>for</strong> å spare tid/kost.<br />
10.3.2 Datahub<br />
En datahub vil være et omfattende prosjekt i alle faser. Avhengig av antall prosesser<br />
som skal sentraliseres, vil en kunne få deler av løsningen etablert raskere ved å<br />
faseinndele implementeringen. Men en slik faseinndeling vil høst sannsynlig øke den<br />
totale kostnaden og den totale implementeringstiden betydelig. Risikoen vil derimot<br />
også reduseres betydelig ved en faseinndeling i <strong>for</strong>hold til et big-bang prosjekt.<br />
En annen grunn til å faseinndele, er at siden funksjonsansvar flyttes fra nettselskap til<br />
datahub over en periode der en samtidig endrer markedsmodeller, måleverdioppløsning<br />
og beregningsalgoritmer, vil en kunne <strong>for</strong>enkle datahuben ved kun å supportere<br />
fremtidig/endret funksjonalitet. Dagens regelverk vil håndteres av nettselskapene i<br />
dagens systemer. Ulempen med en slik modell er at overgangsordningene kan bli<br />
kompliserte, og over en periode på flere år, vil bransjen måtte operere, drifte og betale<br />
lisenser <strong>for</strong> parallelle system som utfører samme oppgaver, men basert på nytt og<br />
gammelt regelverk.<br />
Samtidig er det grunn til å tro av merkostnaden ved å legge til support <strong>for</strong> dagens<br />
regelverk i en datahub er lav, da dette er kjent funksjonalitet som alle de etablerte<br />
systemleverandørene har støtte <strong>for</strong>. En lav tilleggskostnad, men lav teknisk risiko taler<br />
<strong>for</strong> å flytte funksjoner med støtte fra dagens prosesser tidligst mulig, da det vil være<br />
klare stordrifts<strong>for</strong>deler med å kjøre prosesser som profilavregning og saldooppgjør<br />
sentralt.<br />
Hvis en likevel velger en faseinndeling kombinert med overgangsordninger, er det<br />
naturlig se disse i <strong>for</strong>hold til innføringen av AMS. AMS vil være triggeren til at flere<br />
127