Ontwikkeling Belgisch centraal energiedatasysteem kostte 113 miljoen euro

Atrias, het Belgische centrale energiedatasysteem dat sinds 1 november 2021 actief is, heeft 113 miljoen euro gekost om te ontwikkelen. Het project werd in 2011 aangekondigd en moest in 2015 klaar zijn. De ontwikkelkosten werden toen geraamd op enkele tientallen miljoenen euro's.

Logo Atrias

In een interview met Tweakers vertelt Atrias-woordvoerder Björn Verdoodt dat de kosten voor de ontwikkeling van het centrale energiedatasysteem 'een stuk hoger' uitvallen dan verwacht. Dat komt volgens de man omdat de energiemarkt sinds 2011 behoorlijk veranderd is. "Verschillende partners hadden gaandeweg andere behoeften. Er was dus meer tijd en geld nodig om een goede dienst te ontwikkelen die ook toekomstgericht was", zegt hij.

Volgens Verdoodt is die 113 miljoen euro de afgelopen jaren via de Belgische distributienettarieven verrekend. "Er ligt geen factuur van 113 miljoen euro meer op ons te wachten", zegt hij. De Vlaamse distributienettarieven zijn volgens de woordvoerder de afgelopen jaren niet de hoogte in geschoten door de ontwikkeling van Atrias. "Die dalen al voor het vijfde jaar op rij."

Een energiedatasysteem wisselt data uit tussen de verschillende marktpartijen, zodat een correcte afhandeling van energietransacties mogelijk wordt. België kende tot voor kort meerdere verschillende datasystemen en in 2011 werd beslist om een centraal datasysteem op te richten, genaamd Atrias. Dankzij Atrias zou data op de Belgische energiemarkt efficiënter kunnen worden gedeeld. Elke Belgische energieconsument met een digitale meter zal in de toekomst dankzij Atrias ook gebruik kunnen maken van dynamische energietarieven, maandelijkse afrekeningen en contracten bij verschillende energieleveranciers, afhankelijk van het type energiegebruik.

Uit de publicatie van de overheidsopdracht uit 2015 blijkt dat het oorspronkelijke budget voor Atrias op ongeveer 65 miljoen euro lag. Na jarenlange vertragingen werd Atrias op 1 november 2021 eindelijk in gebruik genomen. Tweakers schreef een achtergrondartikel over de lange weg die het Belgische centrale energiedatasysteem heeft afgelegd.

Reacties (103)

Het uiteindelijk project kostte meer dan twee keer zoveel en op dit moment is men nog bezig met de opkuis van de rommel die live gegaan is.

Voor de geïnteresseerden, Atrias is door Deloitte in 2018 doorgelicht. Als je graag wil lezen wat er zoal mis ging verwijs ik jullie graag naar het rapport: https://www.vreg.be/sites...arlementaire_vraag_1x.pdf

Bron: ik werk in de energiesector.

Ik ben zelf bezig met een soortgelijk IoT data platform als Atrias, vermoedelijk zal op termijn zelfs de vraag komen om met Atrias te koppelen alsook zit Deloitte al aan tafel.

Een van de zwaarste obstakels waar ik tegen aanloop is enerzijds IT'ers die 0 ervaring hebben met IoT koppelingen & IoT data interpretatie en anderzijds met OT'ers die nog graag in bits spreken maar niet veel begrijpen van hogere interfaces.

Atrias is gebouwd op SOAP via een VPN verbinding, Atrias, als je meeleest, daar kijk ik alvast tegenop om mee te koppelen. Maar het kon erger en het is typerend want momenteel wissel ik data uit met Fluvius via CSV via FTP... Als je met zoveel partijen moet samenwerken waarbij overal de kennis ontbreekt dan word er heel vaak terug gegrepen naar scripting, XML, FTP en nee het is niet enkel in België zo, Franse overheid vraagt ook gewoon CSV via FTP. Langs de andere kant, dat SOAP verhaal zal ook met veel scripting aan elkaar hangen.

Bij de IT'ers van SAP, Oracle, Azure,.. is de kennis om te IoT te koppelen niet aanwezig, het kan wel (vaak weten ze het zelf niet) maar om het effectief te doen is het vaak zoeken naar IT'ers die er wel al ervaring mee hebben. Het is ook niet enkel koppelen maar data intrepreteren.

Simpel voorbeeld, ik stuur je een IoT signaal dat het niveau meting aangeeft van een opslagtank, als die > 40% komt moet het systeem een bestelling plaatsen. Gewoon een regeltje zetten if < 40 then order toch? Niet echt want die meting gaat op 39,9999 zitten om dan terug op 40,0001, heb je plots 100 orders uitgegeven wat 1 order moest zijn. Of er een spanningsprobleem en de tankmeting valt even weg van 80 naar 0 om terug naar 80 te gaan, heb je een order uitgestuurt voor een tank die vol is.

Ofwel zit ik dan met de verkeerde IT'ers aan tafel maar als ik dat uitleg dat ze daar wat logica rond moeten bouwen om dat signaal te intrepreteren in SAP dan word ik nog net niet aan de deur gezet. Dan begint men te pushen dat men in het IT systeem geen tankmeting binnenkrijgt maar simpelweg een signaal "je moest bestellen" = True. En dan zijn we weer vertrokken in een discussie dat het IT order systeem dan geen order systeem meer is maar een simpel doorgeefluik, over dat de ontvanger diegene is die data moet intrepreteren niet de verzender. Dan is de vraag kunnen we dan geen systeem ertussen zitten dat die logica afhandeld wat dan weer afgewezen word met de uitleg, "de postbode doet ook mijn brieven niet open om ze voor mij te intrepreteren".

Dat is dan nog allemaal op voorwaarde dat je erin geslaagd bent daadwerkelijk een IoT signaal te communiceren want van het moment je technisch spreekt over de standaard IoT protocollen zoals MQTT, OPC, OPC-UA, Azure IoT, dan ben je meestal al meteen heel de IT afdeling kwijt.

Concluderend begrijp ik heel goed dat Atrias geen cadeau was om opgezet te krijgen.

Simpel voorbeeld, ik stuur je een IoT signaal dat het niveau meting aangeeft van een opslagtank, als die > 40% komt moet het systeem een bestelling plaatsen. Gewoon een regeltje zetten if < 40 then order toch? Niet echt want die meting gaat op 39,9999 zitten om dan terug op 40,0001, heb je plots 100 orders uitgegeven wat 1 order moest zijn. Of er een spanningsprobleem en de tankmeting valt even weg van 80 naar 0 om terug naar 80 te gaan, heb je een order uitgestuurt voor een tank die vol is.

Ik ben verre van een IoT-expert, maar daar schrijf je zelf toch geen software voor? Gebruik je toch een bestaand alerting systeem of zo? Laat die tanks metrics exposen die in een metric-db komen (Prometheus, InfluxDb, whatever), en die hebben toch alerting rules die rekening houden met gemiddelde waardes over verloop van tijd en wat nog allemaal? En als die alert uiteindelijk wordt getriggerd, webhook aanroepen om de bestelling te doen (of doorgeeft aan ERP)? Die metrics kunnen perfect over een message queue (RabbitMq, MQTT,..) gaan. Gewoon zien dat je de juiste timestamp er op zit zodat je metric db ze juist interpreteert.

Soit, ben maar effe luidop aan het denken

https://openmetrics.io/
OpenMetrics is released. It specifies the de-facto standard for transmitting cloud-native metrics at scale, with support for both text representation and Protocol Buffers.

Standardization into OpenMetrics
There is an effort to promote Prometheus exposition format into a standard known as OpenMetrics. Some products adopted the format: InfluxData's TICK suite,InfluxDB, Google Cloud Platform and DataDog.

Kort door de bocht is het dus de standaard van Prometheus omgezet naar een open standaard (die Prometheus zelf uiteraard ook gebruikt).

En inderdaad, je gaat zelf geen software schijven voor iets waar al een goede open standaard voor bestaat...... Maar @sprankel verwijst vooral naar het punt dat je aan tafel zit met mensen uit het stenen (onpremise) tijdperk. Die denken dat FTP (1971) en CSV (1972) slim zijn tegenwoordig nog in te zetten.

Als een IT applicatie een deftige IoT interface heeft zou die de interpretatie zelf moeten afhandelen, van wat ik heb begrepen is dat voor SAP technisch alvast geen probleem behalve dan een SAP expert vinden die daadwerkelijk de kennis ervoor heeft.

Hoe jij nu denkt is een van de problemen waarom je dit net niet wilt doen, jij denkt ik heb IoT data links en ik heb IT applicatie rechts, laat ik er een gemakkelijke software tussen zetten en ik ben klaar.

Ik denk ik heb 20 OT systemen die IoT data opleveren, ik heb een onpremise live IoT netwerk dat ik via cloud ook extern ga brengen. Aan interne IT klanten ga ik 20 applicaties hebben die gaan inprikken op dat netwerk en extern gaan het er nog veel meer zijn.

Als je dan begint met daar ook nog postbodes tussen te zetten of nog erger, dat de verzender de data interpreteert voor de ontvanger dan krijg je een grote soep want dan heb ik OT stysteem X dat hetzelfde signaal 50 keer moet uitsturen want applicatie 1 wilt het zo en applicatie 2 wilt het anders. En begin dan achteraf maar te zoeken, wie is signaal 25698 aan het genereren? Het OT systeem? Het Cloud uitwisselingssyteem? Postbode A? Postbode B? De IT applicatie zelf?

Daarom wil je dat de verzender zijn data op het netwerk zet zonder te editeren, dat het netwerk de data communiceert, opnieuw zonder te editeren en dat de ontvanger er mee aan de slag gaat, dan is het héél eenvoudig troubleshooten en ook duidelijk welke partij verantwoordelijk is.

Wat wel kan is dat je zegt ik heb applicatie X, applicatie X kan die intrepratie niet zelf doen en ik zet er een interpretatielaag voor zoals je voorstelt maar dan beschouw ik dat als onderdeel van applicatie X alsook het probleem van applicatie houder X. Op het niveau van het IoT netwerk wil ik daar geen rekening mee houden dus geen gegenereerde interpretaties die over het IoT netwerk gecommuniceerd worden.

Als SAP dit soort logica zelf kan afhandelen, des te beter Ik ben niet vertrouwd met SAP, dus ken de mogelijkheden niet. Was gewoon voor mezelf wat aan het brainstormen hoe ik zo'n probleem zou aanpakken met de oplossingen die ik zelf ken, in geval ik zelf met zo'n situatie te maken zou krijgen.

Maar denk wel dat Iot+SAP expertise vinden in Belgie of Nederland, toch wel op zoek gaan is naar een witte raaf

Daarom wil je dat de verzender zijn data op het netwerk zet zonder te editeren, dat het netwerk de data communiceert, opnieuw zonder te editeren en dat de ontvanger er mee aan de slag gaat, dan is het héél eenvoudig troubleshooten en ook duidelijk welke partij verantwoordelijk is.

Is toch eigenlijk wat mijn oplossing doet? de IoT laag zelf stuurt alleen metrics uit zonder die te editeren, op het netwerk gebeurt er ook niks mee. Verwerking of interpretatie gebeurt pas na de data is toegekomen in een metrics-optimized database. Vanaf dan is het toch gewoon verwerking door de business-laag?

[Reactie gewijzigd door Anoniem: 368883 op 30 maart 2022 09:53]

Als ik het zo lees heb je goed verstand van IoT maar de ballen verstand van ERP no offense, niemand kan alles weten.
Overigens heeft SAP ook een realtime dataplatform voor IoT, waar je wel dergelijke oplossingen bouwt. Dat doe je niet in het “ordersysteem”.

Hij geeft toch aan dat hij met specialisten van ERP systemen aan tafel zit en dat zij niet met de oplossing komen?

Ze komen wel met een oplossing, maar hij wil dat niet horen
En daarmee dus: welkom complexiteit. De een weet niet wat de ander doet, en dit is nog op het relatief eenvoudige technische deel. Dan heb je nog de menselijke factor, powerplays, interne en externe politiek, sturing, overhead, ketens, planning…
Maar nee hoor, het ligt aan de andere ITers.

[Reactie gewijzigd door Deleon78 op 29 maart 2022 13:35]

Heel herkenbaar dat gesteggel tussen twee IT leveranciers. Één van de twee moet zich aanpassen aan de standaard van de ander (security, design, interface etc.) maar de budgetten liggen al vast. Dan krijg je dat ze naar elkaar gaan wijzen om dat aanpaswerk te gaan leveren.

SAP heeft daar inderdaad opties voor, het probleem is dat de SAP expert voor mijn neus bij hoog en laag beweerden dat SAP daar geen ondersteuning voor heeft. SAP heeft zelf opties om zelf volledig IoT data platform te spelen, al lijkt mij SAP daar niet de juiste applicatie voor te zijn als je serieus met IoT data aan de slag gaat (iets met relationele databases die aan de basis niet geschikt zijn voor de gigantische volumes data die daar door durven gaan maar dat is nog een geheel ander verhaal)

Ik heb inderdaad de ballen verstand van ERP maar geloof mij, ze komen niet zelf met een oplossing af behalve dan kan je het niet via een XML of een ander scriptje doen. Overigens is mijn achtergrond zelf oorspronkelijk IT maar ik ben overgestapt naar OT omdat ze daar eindelijk door hebben dat ze serieus wat IT in te halen hebben (dat is tevens ook nog een geheel ander verhaal)

Uiteindelijk was besloten met de SAP IoT experts (ingehuurd) om het via MQTT te doen, ik heb de MQTT verbinding tot op hun SAP geinstalleerd => 6 maanden later is besloten dat ze het toch niet zagen zitten met die SAP module, nu willen ze het via Azure koppelen. Ik ben zelf al een jaar in gesprek met die SAP experts terwijl het verhaal al 2 jaar aansleept. Ik hoop dat ik dit jaar nog eindelijk een koppeling heb maar dan moet ik hetzelfde verhaal met Oracle en nog 10 andere systemen herhalen.

[Reactie gewijzigd door sprankel op 29 maart 2022 19:21]

Wederom onbegrip omdat je wederzijds niet weet wat de ander doet.
Als je spreekt met SAP MM experts, is dat heel wat anders dan een SAP Basis of SAP Leonardo expert. Of een van de andere tientallen expertise-gebieden van het SAP ecosysteem.

Atrias is een bedrijf. Het CMS, of Central Market System waarover het hier gaat is een clearing house voor partijen in de energiesector. Het is geen "IoT platform".

Het centrale marktsysteem centraliseert en coördineert alle gegevens die via de datasystemen van de distributienetbeheerder en leveranciers worden uitgewisseld. De overstap zorgt ervoor dat energiedata sneller en volgens nieuwe, moderne standaarden tussen alle partijen kunnen worden gedeeld.

Met energiedata word bijvoorbeeld slimme meters bedoeld. Een slimme meter is een OT systeem, als je OT systemen gaat interconnecteren en met name als je gaat interconnecteren naar IT systemen spreken we over IoT.

De gegevens die ik naar Atrias zou sturen zou bijvoorbeeld om stoomleveringen gaan, hoeveel druk en debiet we geleverd hebben. Die IoT gegevens gaan momenteel naar rechtstreeks naar Fluvius maar zouden dus ook via Atrias uitgewisseld kunnen worden.

Om nog even het verschil aan te duiden tussen OT en IT, IT houd zich bezig met informatie, OT houd zich bezig met fysieke aansturing maar beide gebruiken dezelfde basis als microchips, software en programmeurs. Het verschil is niet zozeer wat ze gebruiken (wat overigens ook meer en meer naar elkaar groeit) maar eerder wat ze doen en waar hun focus/prioriteiten liggen.

[Reactie gewijzigd door sprankel op 29 maart 2022 19:38]

Ja maar CMS was in eerste instantie niet ontwikkeld als IoT platform.
De "OT data" bij Fluvius moet niet klakkeloos gepusht worden naar CMS, zij kunnen het al vertalen naar "IT data".

Mensen zijn later pas allerlei data naar Atrias gaan pushen, en dan gaan klagen dat het systeem duur is en niet goed werkt.

Wanneer is "OT data" dan "IT data" in jou uitleg?

Een daadwerkelijk OT systeem heeft geen data, enkel live waarden. Neem een hartslag meting van een smartwatch, het enigste wat die kan vertellen is wat de hartslag nu, live is. Net zoals ik op een "OT systeem" enkel kan vragen wat de live waarden zijn, je kan daar niet historisch in gaan.

Van het moment je dat gaat registeren en opslaan is dan is het informatie en is het IT data, Google fit is toch geen "OT systeem" met "OT data"?
Omdat het IT data is op basis van een OT systeem gaan we het gemakshalve IoT data noemen om duidelijk te maken wat voor format het is en waar het oorspronkelijk vandaan komt maar een technisch correctere term is "time based data", je harstlag uitgedrukt tov tijd, energie geleverd uitgedrukt tov tijd, de koers van de Nederlandse beurs uitgedrukt tov tijd => allemaal dezelfde format.

Voor ik de opmerking krijg dat "OT systemen" wel degelijk historische waarden kunnen weergeven, ja dat kan, daar zit dan vaak een SQL databank achter. OT en IT zijn aan het vermelten net zoals Cisco "IoT" switchen heeft onder de noemer "industrial ethernet" bedoeld voor "OT toepassingen" maar de switchen hebben alle catalyst "IT switchen" functies aan boord. Eenmaal je voorbij de generieke termen IT, IoT & OT gaat dan word het heel snel 1 grote pot nat.

Dus dan volg ik niet hoe Fluvius de "OT data" ik heb gisteren X volume energie geleverd aan partij Y moet vertalen naar "IT data", wat moet er dan met die data gedaan worden? Enigste wat ik mij kan bedenken is ze aggregeren naar hoeveel energie heb ik op maandbasis geleverd ipv per dag.

[Reactie gewijzigd door sprankel op 30 maart 2022 01:09]

Ik had het over jou voorbeeld, een order naar atrias is "it" maar raw data van een IoT sensor is dat nog niet.

Simpel voorbeeld, ik stuur je een IoT signaal dat het niveau meting aangeeft van een opslagtank, als die > 40% komt moet het systeem een bestelling plaatsen. Gewoon een regeltje zetten if < 40 then order toch? Niet echt want die meting gaat op 39,9999 zitten om dan terug op 40,0001, heb je plots 100 orders uitgegeven wat 1 order moest zijn. Of er een spanningsprobleem en de tankmeting valt even weg van 80 naar 0 om terug naar 80 te gaan, heb je een order uitgestuurt voor een tank die vol is.

In mijn ogen kan fluvius de IoT connecties ontvangen en zaken zoals in de quote hierboven oplossen voordat ze het naar CMS sturen. CMS is gewoon een ERP met SQL databank he. Akkoord er is heel wat time series data maar dat wil niet zeggen dat je ineens duizenden, of zelfs miljoenen IoT devices rechtstreeks laat loggen naar CMS.

Ik had het eerder over de puur technische implementatie/data, dat de batch API interface tussen Fluvius en Atrias niet gemaakt is voor IoT toestellen, dat dat niet de bedoeling was en dus daarom ook niet moet gezeurd worden. En nu afkomen met allemaal technologieën die nog niet bestonden of bewezen waren toen de blueprints gemaakt werden is ook gemakkelijk.

Vergelijkbaar met hoe veel IoT "experts" denken dat MQTT een goed protocol is om field devices te verbinden met een cloud-backend, omdat dat is wat cloud providers goed ondersteunen. Meestal is CoAP / LwM2M een beter idee.

Er wordt naar mijn gevoel te weinig pragmatisch nagedacht in IT, zeker aan de managementzijde. Als SAP die tussenlaag niet kan of wilt bouwen en jij kan of wilt die niet bouwen dan moet iemand anders die bouwen. Echt moeilijk is zo'n extra laag meestal niet (programmeer zelf vaak tussen SAP en andere systemen).

Ik heb het gevoel dat het vaak vanuit management is dat elke partij op zijn strepen staat. Haantjesgedrag uit onzekerheid (ik ga me niet laten doen en wat gaat dat kosten in tijd en geld). Daarbij "vergetend" dat met 8 consultants gedurende maanden één keer per week een uur fel discussiëren en belangrijk doen ook veel geld kost.

De vraag is, waarom men belastinggeld (of gewoon enige soort geld) in een organisatie spilt dat duidelijk niet de expertise vertoont om z'n taken te voldoen?

[Reactie gewijzigd door harakiri576 op 30 maart 2022 10:43]

Tsja, noem eens één overheidsproject wat op tijd en binnen budget af is gekomen, met mijn 40 jaar kan ik er in ieder geval geen één noemen in mijn leven.

Trouwens 113 miljoen klinkt veel, maar dat is een tientje per persoon, dus een euro per jaar... Als die dynamische tarieven er komen kun je dat in een half jaartje terugverdienen door de (af)was op het beste moment te doen of je vriezer op een tijdschakelklok te zetten.

Er worden genoeg overheidsprojecten op tijd opgeleverd. Of het altijd binnen het budget is weet ik niet.

Voor het project waar ik nu werk kunnen we regelmatig het tarief dat de burger betaalt verlagen omdat we steeds efficiënter werken.

Ik heb de afgelopen 25 jaar zelf voor verschillende overheidsinstanties gewerkt, zowel als interne als inhuur.

Vooral de projecten die mislukken krijgen de aandacht. Als het goed gaat heeft het geen nieuwswaarde.

113 miljoen is veel, waarschijnlijk als je een stel studenten 1 miljoen had gegeven, had je de software sneller en voor veel minder geld.

Ik heb een IT project gezien voor het beheer van onderdelen wat dan 30 miljoen euro gekost heeft. Niet mee te werken, rete traag. Daar hadden ze beter 2 middelbare scholieren op kunnen zetten, want die kunnen zich ook nog verdiepen in eindgebruikers ipv helemaal verzandt te zijn als een stel database fetishisten.... En dan had je het waarschijnlijk in een jaar voor een krat kindercola ipv na 10 jaar nog een draak van een klote systeem.

Ik snap wel dat de scope hier tussendoor flink veranderd is, maar dan nog blijft het een bak geld. Het geld goedpraten door 10 sec per keer minder te douchen of wat ook om het weer financieel recht te praten, vind ik een dooddoener. Mensen moeten requirements een keer serieus nemen en betere plannen bedenken voor grote veranderingen of in kleinere stapjes ontwikkelen, zodat je niet eens 180 graden moet draaien.

En leveranciers moeten gewoon keihard aan de afspraken gehouden worden, dit is heel normaal voor fysieke productie faciliteiten, maar bij software wordt er maar aangeprutst en als het niet goed is, gaan ze nog wel een paar jaar aanprutsen voor nog een berg geld. Dat is exact wat bij de zuiderburen is gebeurd dus.

Sorry maar... wat een onzin. "Gewoon een paar studenten" leveren echt niet even een beter systeem op. Software is ingewikkeld en dus duur om te ontwikkelen, vooral als er veel stakeholders zijn met eisen die onduidelijk zijn en in de loop van het project aan verandering onderhevig.

Treft de ontwikkelaars geen blaam? Vast wel. Geen idee, ik ken dit project niet. Maar meestal zijn ook opdrachtgevers of andere stakeholders (mede-) verantwoordelijk voor het uit de hand lopen van projecten.

Het zal je verbazen hoe minder mensen iets beters neer kunnen zetten, mede omdat er meer overzicht is en mensen verantwoordelijkheid durven/moeten nemen ipv verstoppen achter de anonieme massa. Ik heb dit zo vaak gezien.

Ik geef niet alleen de ontwikkelaars de schuld, waar lees je dat? De hele keten stinkt, van diegene die de opdracht geeft tot diegene die het uitvoeren.

Als jij echt goede mensen (professionals) met de juiste kennis, ervaring en ondersteuning hebt, kun je idd met minder meer presteren, maar de suggestie dat "een paar studenten" die misschien wel kennis maar zeker geen praktijkervaring of ondersteunende organisatie hebben, het wel ff beter en een factor 100 goedkoper zouden doen... sorry, dat gaat er bij mij niet in.

Wat ik in de jaren gelezen en gehoord heb is het grootste probleem veranderende specificaties waardoor gedurende projecten de hele basis overhoop geschopt moet worden. Alsof als je een standaard huis op papier koopt en "alleen eventjes dat tussenmuurtje weg wil hebben" zonder enig idee te hebben dat het een "dragende muur" is of wat dat betekend - ja een studentje met een sloophamer kan dat voor een paar tientjes in een middagje voor je doen, maar durf jij dan nog in dat huis te wonen?

De veranderde specs moeten dus aangepakt worden, dan blijft de scope niet steeds heftig wijzigen, dan hadden ze al 100 miljoen bespaard.

En heb je een systeem wat in de praktijk niet levert wat er nodig is. "Change is the only constant" dus je moet een proces hebben wat hiermee kan omgaan. Mijn ervaring is dat het juist daar aan schort en dat er dus teveel problemen pas in de implementatiefase aan het licht komen terwijl die tijdens de "impact analyse" fase al onderkent hadden moeten worden.

sorry, maar nee... je schreeuwt weer lekker makkelijk een bedrag van 100 miljoen - maar je leest toch in de tekst dat het oorspronkelijk begrootte bedrag 65 miljoen is?

Dat er miljoenen bespaart kunnen worden door niet de specs na de eerste offerte/begroting aan te passen zeker, maar je moet ook lange termijn denken: is het beter om in plaats van 65 miljoen nu 110 miljoen uit te geven aan een systeem wat dan wel kan wat je wil, of een systeem van 65 miljoen binnen een aantal jaren compleet te moeten vervangen voor weer 65 miljoen waarmee het totaal op 130 miljoen zou komen?

Heel stoer zo op internet in een post van 5 minuten zeggen dat de hele keten stinkt. Ik werk bij grote bedrijven en de overheid en er is één zaak die de prijs doet ontploffen: veranderende specificaties (en in mindere mate onoverzichtelijke complexiteit).

Dan is de aansturende factor het probleem, plus ook diegene die werken onder de veranderingen (vaak ervaren de programmeurs dat na enkele jaren eerder als bezwijken onder de steeds veranderende scope...) en dan toch doorwerken, terwijl je gewoon terug moet naar de tekentafel en een nieuw plan moet trekken.

Ja, het is complex en onoverzichtelijk en vooral groot met heel veel afhankelijkheden en waarschijnlijk veel koppelvlakken (wat een nog complexer maakt), maar dat is geen argument om lang aan te prutsen. Een goede project manager en goede software architecten moeten daar mee om kunnen gaan. Er zijn zat voorbeelden waar het blijkbaar wel kan, hoewel ik ook vaak dit soort drama's van heel dichtbij heb mee gemaakt.

Je houd ook geen rekening mee dat tijdens het maken van de software, wetten worden aangepast/aangevuld/nieuw verzonnen. Dat veroorzaakt vaak een flinke deuk in planning en opzet van software.

Wat jij dacht dat nooit zou veranderen, daar maak je ontwerpkeuzes voor in software. Als je met relationele databases werkt, maak je er specifieke schema's voor enz. Nu ben je al een jaar bezig met de gehele opzet, je hebt al een aantal goedgekeurde sprints achter de kiezen en ineens is er een nieuwe wet waardoor de zaken waarvan jij dacht dat deze niet zouden veranderen, nu ineens heel anders geinterpreteerd dienen te worden.

Kan je weer bijna van voren af aan moeten beginnen als het een beetje slecht uitvalt. De sprints moeten worden aangepast, moeten weer opnieuw door de vooraf ingestelde interne en/of externe test procedures, nieuwe/aangepaste documentatie en opnieuw worden aangeboden voor goedkeuring en alle administratie (en bijbehorende kosten) die daar bij komt kijken. O ja, ISO standaarden doen ook nog een duit in die zak.

Programmeerwerk is verre van goedkoop. Maar daar zit over het algemeen niet de grootste kostenpost. Die studenten die je zo graag aandraagt, die hebben vaak niet het overzicht voor consequenties die aan hun ontwerpkeuzes hangen. Iemand die wel van de hoed en de rand weet, mag dan initieel meer kosten, aan het eind van de rit heb je een beter systeem voor alle partijen die zich met de materie bezig houden.

In de energiemarkt zijn echt heel veel verschillende soorten bedrijven aktief. En dat is echt een must. Heb hier in Paraguay al verschillende universitair opgeleidde programmeurs gezien die bijna huilend wegliepen van alles wat er komt kijken in de NL energie markt. Niet alleen voor electriciteit, maar ook gas en water.

De software waar ik aan werk word ook gebruikt in de UK, Belgie, Duitsland, Frankrijk en Tsjechie. GazProm had ook interesse een jaar of wat terug. Dat levert een nog onduidelijker beeld op. Hier heb je echter 1 staatsbedrijf voor electriciteit, Ande. En 1 staatsbedrijf voor watervoorzieningen, Essap. Een heel andere opzet en daar hoort een heel andere denkwijze bij.

Ironisch genoeg is deze software ooit eens opgezet door een 20-tal studenten van de TUe bijna 20 jaar terug. 2 personene van die ploeg zijn nog bij het project betrokken, de rest heeft allang afgehaakt vanwege alle complicaties die er door de markt zelf en de wetgevers in zijn gebouwd.

Het is schrikbarend, hoe jij de zaak onderschat. En niet echt wil luisteren naar anderen met duidelijk meer ervaring en/of kennis.

Ja, dat het project 55 miljoen duurder is uitgevallen, is inderdaad geen kattenp.s. Maar er zijn meer dan genoeg goede redenen voor te bedenken dat dit toch is voorgekomen. Niet iedereen is ook heel goed in het inschatten van de tijd die nodig is en/of de kosten die erbij horen. En dan lopen de verwachtingen en realiteit al heel vlug ver uiteen.

Je bevestigt gewoon exact wat ik aangeef als de problemen (en verwijt me daarna dat ik niet wil luisteren met "duidelijk meer ervaring en/of kennis", wat aan hun reactie duidelijk pertinent niet waar is), de wijzigingen in wetgeving is nog een mooie aanvulling.

De crux zit (wat iemand anders ook al terecht aankaartte): de specificaties/randvoorwaarden kan door de users / opdrachtgeven niet 100% aangegeven worden. Verder zijn er wijzigingen op spec vlak of randvoorwaardes, zoals koppelvlakken, wellicht wisseling van leveranciers, wetgeving wat jij heel mooi aangeeft. Dan komt het probleem: ze gaan op de zolder zitten, gordijnen dicht, gaan jaren keihard met de beste bedoelingen programmeren. Zijn klaar, doen de gordijnen open en .... de wereld is veranderd. Goh. Het bedrijf waar ik werkte, heeft ook vaak zat tegen dat probleem aangelopen en uiteindelijk waren ze zelf-kritisch genoeg om tot te conclusie te komen dat dit echt niet kan. Dus voor andere ontwikkel methodes gekozen en met succes (niet altijd zonder slag of stoot he, begrijp me niet verkeerd, maar niet meer dit soort drama's).

Omdat ik vaak zat met dit bijltje heb gehakt, onderschat ik de werkwijze en de problematiek niet, waar je mij van beschuldigd (zonder dat je mijn achtergrond kent....), maar open jij nu eindelijk mijn ogen dat ik vooral de developers maar vooral de architecten en project leiders in deze moet onderschatten!

Zoals je zegt: gaande de (vaak lange) weg, veranderen er heel veel dingen. Je weet niet wat er gaat veranderen, maar wel dat er dingen gebeuren. Die kun je niet wetenschappelijk vooraf al incalculeren, maar je kunt er rekening mee houden en als er echt schokkende zaken het revue passeren, kun je even op de rem trappen en terug naar de tekentafel gaan om scope, kosten en doorlooptijd weer te evalueren en af te spreken met de stake holders.

Dat lees ik uit het idee dat je poneert dat een clubje studenten wel even snel iets beters neer zullen weten te zetten. Daarmee leg je m.i. de schuld bij degene die het systeem gebouwd heeft.

Maar goed, ik zal er wel geen verstand van hebben.

* ATS gaat verder met zijn werk als consultant software engineer voor een klant...

Ik ben student-zelfstandige en heb ook al voor mijn lokale gemeente overheidsprojecten gerealiseerd. Binnen budget en binnen tijd af. Andere kandidaten (allemaal grote webbedrijven) konden niet opleveren wat ik opleverde.

Dus jawel, gewoon een paar 'studenten' kunnen meer dan jij denkt.

Tussen een lokale gemeente (hoeveel inwoners?) en de federale overheid + x aantal energie leveranciers zit nogal een schaalverschil denk je niet?

Mwah valt mee hoor. Gigantisch veel overhead voor zulke grote projecten met weinig betere resultaten. Vaak zitten grote bedrijven nog vastgekleeft aan talen en frameworks uit het jaar nul "omdat ze daar altijd al mee hebben gewerkt". 90% van hun "werk" is onderhand al weggeautomatiseerd door libraries.

Meer man ergens tegenaan gooien klinkt leuk maar tenzij het fysiek werk is krijg je alleen maar verdeeldheid en discussies over vrij onbelangrijke zaken. En zoals we bij onze zien is alles wat door Deloitte e.d. wordt gemaakt nog steeds zo lek als een zeef en ook nog steeds onstabiel.

Dat is precies waar oa Centric en de andere grote boys tegenaan lopen. Veel mensen er tegenaan gooien maar effectief weinig presteren. Ze kunnen het wel, maar mogen het vaak niet!
Veel met oude standaard meuk en libraries werken, inderdaad!

Die reeks artikelen op GeenStijl vond ik ook zo mooi; de reeks "UWV: Kroniek van een faalfabriek". Daar staat prachtig in beschreven waarom alles zo fout gaat.

Ow die ouwe frameworks of inmiddels minder geschikte programmeeromgevingen is inderdaad vaak een reden om daarop voort te blijven borduren. Killing voor je product.

En bij ons werd een keer zo'n hele buslading dure IBM programmeurs ingezet. Reteduur en 1 fiasco.

Schaalgrootte wel, ontwikkelmethodiek niet.

Het is echt nergens voor nodig je concurrenten naar beneden te halen en je eigen ongelooflijk talent/werklust te bestoefen. Komt erg onzeker over.

Ik haal niemand naar beneden. De andere concurrenten gaven zelf toe het niet te kunnen in de vooropgestelde deadline.

En na het afstuderen blijken die studenten in de praktijk ineens "klunzen" te zijn als ze zijn gaan werken bij, grote, bedrijven? Ik kan heel goed voorstellen dat de scope van wat er gebouwd moest worden beter paste bij een zelfstandige dan een web-bedrijf die volgens processen die hier gewoon weg niet efficient voor zijn. Andersom geld dit namelijk ook, zat klussen die ik nooit en te nimmer aan een zelfstandige zou overlaten gewoon weg omdat die daar de bedrijfsprocessen niet voor heeft. Denk aan bijvoorbeeld opleveren van trainingen, meerjarige ondersteuningen, etc.

Probleem is vaak dat de scope van een software systeem nogal lastig te bepalen is door de klant zelf.

Het aantal niveaus waar je doorheen moet worstelen voor je in contact met een eindgebruiker is vaak immens.
Software ontwikkeling is vaak chinees fluisteren (telefoonspel) voor grote mensen.

Een leverancier kan zich wel aan de afspraken houden ... en dan krijg je misschien wel het systeem dat je gevraagd hebt, maar of dat het systeem is dat je nodig hebt of kunt gebruiken is weer een heel andere vraag.

Iteratief werken is idd iets beter - maar zelfs in de privé werkt dat vaak nog maar half zijn gat omdat de business/organisatie niet echt mee kan. Laat staan bij de overheid waar dat allemaal nog veel stroever gaat.
Ook hier weer met al die extra laagjes ertussen.

Daar hadden ze beter 2 middelbare scholieren op kunnen zetten, want die kunnen zich ook nog verdiepen in eindgebruikers ipv helemaal verzandt te zijn als een stel database fetishisten....

Sorry dat is gewoon klinklare onzin. Veel van die projecten gaan de mist in doordat: project managers dit weinig op deze schal gedaan hebben, gebruikers geen idee hebben wat ze willen, omstandigheden veranderen.

Enkele scholiertjes die amper kennis hebben gaan daar niks aan veranderen. Denken dat je het allemaal wel even beter weet is redelijk arrogant .

[Reactie gewijzigd door k995 op 29 maart 2022 11:11]

De ellende en het bijbehorende bedrag goedpraten is pas arrogant! Zolang die software bedrijven niet stevig op de flikker krijgen, blijf je deze zooi houden!

Je hebt deels gelijk: de project leiders zijn vaak incompetent voor dingen die in begin kleiner lijken dan de draak die het uiteindelijk wordt.

Verder worden eindgebruikers niet (of zelden) bevraagd, maar denkt iemand anders - aan de klantzijde, niet van de leverancierzijde - dat ze wel weten hoe de gebruikers werken en wat er nodig is.

De requirements vertellen is iets wat geen enkel bedrijf waterdicht kan doen, de requirements ophalen is een vak apart en deze software leverancier is dat duidelijk niet machtig. Dit wordt vaak versterkt doordat men zich opsluit in een donker hok tot de software "klaar" is, ipv tussendoor 'wekelijks' key users te betrekken.

Omstandigheden veranderen, absoluut, dus is het zaak om kleinere sprints te maken zodat je daar op kunt anticiperen. Daar zijn zoveel standaard, goed werkende methodes voor.

Uit ervaring weet ik dat enkele mensen met een frisse blik lastige trajecten sneller en effectiever kunnen doorlopen dan een software team van 120 man, waar we pijnlijk achter kwamen (meermaals ook nog).

De ellende en het bijbehorende bedrag goedpraten is pas arrogant! Zolang die software bedrijven niet stevig op de flikker krijgen, blijf je deze zooi houden!

Sorry maar je doet alsof het louter de fout is van " software bedrijven" uit ervaring kan ik zeggen dat het dat zeer zeker niet is.

Voor de rest heb ik nog geen enkel groot project gekend waar de eindgebruikers/stakeholders niet bij betrokken waren, je scheert dus alles over een veel te grote kam.

Uit ervaring weet ik dat enkele mensen met een frisse blik lastige trajecten sneller en effectiever kunnen doorlopen dan een software team van 120 man, waar we pijnlijk achter kwamen (meermaals ook nog).

Enkele mensen kunnen net zo goed of slecht werk afleveren als 120 mensen, de grootte van de groep die het werk doet maakt weinig uit voor de kwaliteit.

Dat de wereld slecht en inefficiënt gerund wordt weet ik wel, net zoals jij weet dat je voorstel van studenten of scholieren nergens op slaat.

Ik bedoel het enkel in perspectief te plaatsen, hoeveel miljard geven alle Belgen samen per jaar uit aan stroom? En wat kost het fysieke stroomnet aan onderhoud en investeringen? En blijft ook daar niet genoeg (te veel) aan de strijkstok hangen?

Waarom je best doen als de overheid de rekening toch wel betaald?

De overheid is de perfecte opdrachtgever.

Commercieel gezien heb je gelijk

Waar ik ooit werkte, heb ik altijd gezegd dat wanneer ik ooit werkloos wordt, daar leverancier zou worden. Die stellen ook geen vragen, ongeacht wat je vraagt en hoe lang je er over doet.

Hoe hebben wij dit in Nederland geregeld, weet jij dat?

dat loopt via https://www.edsn.nl/

Bijna

We gaan het in Nederland ook beter organiseren:

https://www.mffbas.nl/

MFFBAS is een overlegplatform; waar P_de_B op doelt is C-AR, C-ARM en CERES (drie systemen van EDSN die onder water ook weer met elkaar zijn verbonden). Wat wel te vergelijken valt met wat men nu in België heeft gedaan.

MFFBAS zit overigens in hetzelfde gebouw als EDSN in Amersfoort.

Dan is de vraag: Waarom heeft België zijn eigen systeem ontwikkeld en niet een bestaande herbruikt?

Nou... Opa mag daar helaas niet heel veel over vertellen. :-) Maar het komt er op neer dat de Belgische energiemarkt iets complexer in elkaar zit dan de Nederlandse energiemarkt. Het vergt dus meer intelligentie om een goed systeem te bouwen en die hebben de simpele zielen uit Nederland niet ;-)

Een citaat uit het verleden https://www.febeg.be/site...5_jaarverslag_2009-nl.pdf
Data clearing house
In opdracht van FEBEG heeft Logica Management
Consulting in 2009 een studie uitgevoerd over de
oprichting van een centraal clearing house. Deze
studie concludeert dat naast een goede organisatie
en governance-structuur van het centraal clearing
house (de missie, de reikwijdte van de opdracht, de
besluitvorming met begrip van haar afdwingbaarheid, een evenwichtige verdeling van de
vertegenwoordigers, …) het investeringsbeleid
ruimer dient te zijn dan voorzien in de huidige
regulering en budgetten: er moet gestreefd
worden naar een federaal model dat bovendien
klaar is voor de implementatie van smart meters
en smart grids. Daarom heeft FEBEG gepleit voor
een betere samenwerking tussen de leveranciers,
de evenwichtsverantwoordelijken, de shippers, de
transport- en distributienetbeheerders en de overheden om een tijdige en correcte overdracht van
gegevens tussen de partijen te verzekeren.

Sorry, geen idee.

Erger nog. Een maand nadat de boel in productie gegaan kwam Atrias af dat er voor nieuwe functionaliteit die deze zomer klaar moet zijn (aanlevering capaciteitstarief) een nieuwe manier van werken ontwikkeld moet worden. De bestandsstructuur die men nu gebruikt voldoet niet om met die hoeveelheid van data te werken, dus is men nu rap-rap bezig een alternatieve manier van aanleveren aan het ontwikkelen.

Maw: het nieuwe platform voldeed al bij de go-live niet aan de normen.

De leveranciers zijn 'not amused'...

Slechts twee keer zoveel is best netjes voor een landelijk project.

In Nederland kunnen we er wel een paar opnoemen die een veelvoud over de kop gingen qua kosten.

Na het rapport gelezen te hebben is ‘wat er zoal mis ging’ overdreven voor een project van deze complexiteit en het grote aantal stakeholders. Dat na 5 jaar strikter project management wordt voorgesteld door Deloitte is voor de hand liggend.

Wanneer komen er in NL echt dynamische tarieven? Mijn oom had dat 10 haar geleden al in Tsjechië, 6 verschillende tarieven per dag, de wasmachine draaide daar praktisch gratis (tussendemiddag was er een uurtje dat stroom bijna letterlijk niets kostte als de lokale fabriek lunchpauze had)

In Nederland heb je al jaren verschillende bedrijven die uurprijzen aanbieden. easyEnergy, Frank en zo zijn er nog enkele. Zie bijvoorbeeld halverwege deze pagina voor de tarieven die Frank vandaag berekent.

En zie dit topic op GoT.

[Reactie gewijzigd door Timmy op 29 maart 2022 09:25]

Het energieverbruik heeft steeds minder pieken en dalen dus verschillende tarieven zijn dan niet meer zo relevant.

Maar we hebben met zonne-energie wel wisselend aanbod Zo zou een een zonnige zondagmiddag in Mei goedkope energie moeten opleveren.

en dat is dus precies de @418O2 (baduum tss...) van de day ahead prijzen.
Zonne energie zorgt voor een enorme dip in de prijzen tussen 12-16, soms gaat het op dat moment zelfs negatief waardoor je geld krijgt als je energie gebruikt.

Als je zonnepanelen hebt ben je, zolang er nog een salderingsregeling bestaat, dief van je eigen portemonee met een day ahead contract. Indien de energieprijs negatief is moet je namelijk betalen voor de stroom die je teruglevert. Het belangrijkste probleem is echter dat de stroomprijs op dit moment dusdanig variabel is dat je bvb om 14u geen geld krijgt voor je teruggeleverde stroom en dan 's avonds als het tussen 1800-1900 60 cent per kwh kost kan dit niet gesaldeerd worden (enkel het energie belasting deel wordt in dit scenario nog gesaldeerd, de kwh kosten tegen elkaar weggestreept maar als het overdag 3 cent kost en 's avonds 60 cent dan ben je netto nog 57 cent kwijt en daarmee is het voordeel van salderen helemaal weg.

Negatieve energie prijzen in belgie zijn enkel voor grote gebruikers en bedrijven/instellingen niet voor de burgern is dit dan in nederland niet het geval?

[Reactie gewijzigd door k995 op 29 maart 2022 11:13]

Zie de opmerking van catch hieronder, we krijgen juist veel meer pieken en dalen door gebruik van zon en wind te maken. Juist daardoor kunnen prijzen zelfs negatief worden zagen we vorige zomer.

Het wachten is tot de meeste elektrische autos als thuis accu gebruikt kunnen gaan worden, dan kunnen we een efficiëntie slag maken!

Mits het niet (veel) uitmaakt of je auto dan daadwerkelijk fysiek thuis staat, of bij de baas voor de deur aan een laadpaal hangt. En ja... ik kan zeker begrijpen dat het bouwen van een robust systeem dat dat soort scenarios ondersteunt best complex is.

Stel ik heb een lading panelen thuis, maar mijn auto staat elders aan een laadpaal. Dan zou het toch geweldig zijn als ik "mijn eigen" energie dáár kan afnemen op het moment dat die energie anders toch te veel is op het net, uiteraard tegen betaling van een kleine netwerkvergoeding?

Het probleem bij dat soort snelle berekeningen is dat de fysica gewoon niet klopt. Lokaal in de woonwijk waar alle omvormers tegen elkaar opboksen stijgt de spanning (bij gebrek aan verbruikers) dermate dat enkele omvormers zichzelf gewoon ontkoppelen/uitschakelen. Dat zou maar net de jouwe kunnen zijn.

Terwijl zit je enkele tientallen kilometers verder, wat sowieso al enig verlies met zich mee zou brengen en een grote netwerkvergoeding vraagt.. maar je omvormer is offline. Wiens energie gebruik je nu eigenlijk?

Dit gewoon administratief verwerken klopt niet bij de realiteit van energietransport. Opgewekte energie moet meteen gebruikt worden en spanning moet op lokaal niveau geregeld worden. Een auto die dus 15m van de omvormer(s) oplaadt helpt. Een auto die 50km verder staat niet (voor dat lokale netwerk).

Volgens mij gaat wat je beschrijft grotendeels in tegen het idee van dynamische tarieven - dat systeem is nu juist bedoelt om het net te ontlasten, als jij op één plek levert en op een andere plek gebruikt is dat in juist het tegenovergestelde. De netwerk vergoeding zal dan de prijs juist verhogen omdat je op piekmomenten het net juist extra belast - je wilt stroom juist daar gebruiken waar het opgewekt wordt. (nu zullen panelen van veel mensen wel dichter bij hun werk zijn dan de dichtstbijzijnde energiecentrale, maar toch - overbelasting door zonnepanelen en windmolen is een steeds groter probleem)

Ik heb het trouwens over dat het een deel van het systeem/oplossing is, wind waait ook 's nachts en in het weekend staat je auto wel thuis.

je wilt stroom juist daar gebruiken waar het opgewekt wordt. (nu zullen panelen van veel mensen wel dichter bij hun werk zijn dan de dichtstbijzijnde energiecentrale,

En al naargelang de afstand volg je energiegewijs best het STOP-principe: eerst Stappen, dan Trappen (fiets), vervolgens Openbaar vervoer en dan pas naar Personenwagens. En dat de auto een efficiënt, snel en voordelig vervoersmiddel is blijkt niet noodzakelijk waar te zijn.

Hier in Stockholm, waar er niet heel veel zonne energie is vergeleken met Duitsland en Nederland zijn er toch grote verschillen! Niet overdag, maar 's avonds! Ik betaal hier per uur, en laat in de avond kost energie mij vaak maar 0,03 euro/kWh, vergeleken met nu, 10:00-11:00 0,21 euro/kwh. Er is netjes in hun app een grafiek van de hele dag, en optioneel een notificatie wanneer energie het goedkoopst/duurst is (of onder/boven bepaald bedrag).

In december en Januari waren de dal en piek prijzen soms wel in een dag 0,02 euro/kWh en 0,50 euro/kWh! Met de enorm goed geïsoleerde huizen hier kun je daar best leuk op inspelen (lage prijs? verwarming op 24! Hoog? pas aanzetten als het onder de 18 is.). Avond eten een uurtje later beginnen, en energie kan soms wel 2x zo goedkoop zijn.

uurprijzen voor stroom en dagprijzen voor gas zijn toch al mogelijk bij enkele leveranciers? Of bedoel je iets anders

Uur of kwartier prijzen bedoel ik ja, daar heb ik in NL nog niet van gehoord. (Maar ik ben sinds begin corona ook niet meer in NL geweest, dus niet heel erg op de hoogte)

Bij Frank energie is dat zo, en moet zeggen werkt perfect. verleden week zaterdagmiddag zelfs een paar uurtjes negatieve prijs van de stroom. Gasprijzen gaan per dag.

"Elke Belgische energieconsument met een digitale meter zal in de toekomst dankzij Atrias ook gebruik kunnen maken van dynamische energietarieven"

Dus als het koud is en er veel vraag naar energie is zullen mensen met weinig financiële middelen het zich niet kunnen veroorloven de verwarming aan te zetten.

[Reactie gewijzigd door Anoniem: 428562 op 29 maart 2022 09:12]

Dus als het koud is en er veel vraag naar energie is zullen mensen met weinig financiële middelen het zich niet kunnen veroorloven de verwarming aan te zetten.

Ja en nee. Het klopt dat de tarieven op zo'n moment hoger zijn, echter als je een "klassiek" contract hebt betaal je het uiteindelijk ook, maar gespreid over het hele contract en je hebt er geen invloed op.

Bij een klassiek contract is er een bepaald risico-marge wat een energieleverancier moet aanhouden, doen ze dit niet of is dit te laag dan heb je dik kans dat de leverancier omvalt bij sterk wisselende tarieven (bij grotere leveranciers worden de jaartarieven in de periode na een prijsstijging flink verhoogd).
Bij een dynamisch contract (cq: ieder uur een ander tarief, de dagmarkt wordt gevolgd) wordt dit risico bij alle klanten belegd.

Aan het eind van de keten is het duurder om tijdens pieken stroom op te wekken (want minder zon en meer afname), dus ergens moet dat terugbetaald worden (en uiteindelijk is dit de consument).

(bron/bias: werkzaam bij een energieleverancier welke met dynamische energietarieven werkt)

"Aan het eind van de keten is het duurder om tijdens pieken stroom op te wekken"

De kosten voor centrales die met gas, kolen of nuclear stroom produceren zijn tijdens een piek niet hoger.

Het is de wet van vraag en aanbod die de prijs omhoog stuwt tijdens een piek. Het aanbod is beperkt, klanten staan in de rij dus vraagt de producent een hogere prijs.

[Reactie gewijzigd door Anoniem: 428562 op 29 maart 2022 10:12]

"De kosten voor centrales die met gas, kolen of nuclear stroom produceren zijn tijdens een piek niet hoger."

Natuurlijk wel.

Bij hogere vraag, moeten de turbines in de centrale sneller draaien om meer vermogen te produceren. Die turbines draaien door meer kolen of gas "op het vuur" te gooien. Kolen en gas kosten geld.

Ontopic: in NL hebben we al een tijdje een centraal energiedatasysteem (EDSN). Stapje-voor-stapje worden steeds meer processen die lokaal bij de netbeheerders worden uitgevoerd, gecentraliseerd.

Het begon met de registratie van de aansluitingen (C-AR), gevolgd door wie van opwek (teruglevering) (eerst PIR, nu alweer in zijn tweede vorm als CERES). Meest recent is de verbruiksdataketen gecentraliseerd waardoor netbeheerders nu rechtstreeks verbruiken wegschrijven in een centraal register (C-ARM) en de leveranciers ze daar weer uit plukken. Ook correcties op verbruiken en disputen lopen via dat centrale register.

Voorheen liep dat allemaal via een complex berichtensysteem tussen de netbeheerders en leveranciers onderling. Een behoorlijke kostenbesparing dus.

[Reactie gewijzigd door Heroic_Nonsense op 29 maart 2022 10:50]

Een turbine draait constante snelheid onafhankelijk van het geleverde vermogen versnel je de turbine dan verandert de netfrequentie en die moet 50Hz blijven

Als turbine meer vermogen levert is er idd meer brandstof nodig maar wordt er ook meer elektriciteit opgewekt die verkocht wordt, op de kostprijs per kWh heeft het vrijwel geen invloed.

"De kosten voor centrales die met gas, kolen of nuclear stroom produceren zijn tijdens een piek niet hoger."

Natuurlijk wel.

Bij hogere vraag, moeten de turbines in de centrale sneller draaien om meer vermogen te produceren. Die turbines draaien door meer kolen of gas "op het vuur" te gooien. Kolen en gas kosten geld.

Dat klopt ook niet per se, want je krijgt gewoon xx KWH per M3 gas, dat zijn de grotendeels de variabele kosten. Het kan wel zijn dat het extra vermogen duurder is (bijv gas is over het al gemeen duurder dan kolen, maar makkelijker aan te zetten). Ook heb je een technisch maximum (het netwerk of maximum opwekcapaciteit). De prijs zal daardoor altijd omhoog moeten om de vraag te verlagen.
Uiteindelijk is het wel een vraag / aanbod spel, want je gaat niet extra investering doen in meer capaciteit als daar niet voor betaald wordt. Vandaar dat salderen ook een subsidie is, want bij normale marktwerking zal dat nooit gebeuren.

Die kunnen er dus voor kiezen om de wasmachine en vaatwasser te laten draaien op momenten dat stroom goedkoper is.

Het grootste deel van je energierekening bestaat uit kosten om te verwarmen. Een wasmachine en vaatwasser verwarmen allebei ook, maar de kosten daarvan vallen in het niet bij een complete woning warm houden/maken.

Dat zou alleen het geval zijn als je elektrisch verwarmt, dus of via straal kachels of warmtepompen, is het zo normaal in België om één van deze te gebruiken? Want gas verwarmen verbruikt heel weinig stroom.

Ik heb het specifiek over energierekening en niet stroomrekening.

Het tarief van een kWh stroom varieert in 2022 tussen de 15 en 62 cent, afhankelijk van je contract.
Het tarief van een m3 gas varieert in 2022 tussen de 80 cent en 2,79 euro, afhankelijk van je contract.

Bron

Een Nederlands huishouden verbruikt jaarlijks gemiddeld 1.169 kubieke meter (m3) gas en 2.479 kilowattuur (kWh) elektriciteit (bron). Met 1 m3 aan gas kun je ongeveer net zo veel verwarmen als met 8 kWh elektriciteit. Of je nu dus met gas of elektriciteit verwarmd maakt niet uit, de kosten voor verwarming zelf zijn vele malen hoger dan dat van al je andere elektrische verbruik.

Zulke opmerkingen vind ik soms toch wat kortzichtig...
Héél theoretisch benaderd heb je gelijk, maar in de praktijk werkt dit niet. Er zullen last minute noden zijn, waar er simpelweg niet de tijd is om 'even te wachten tot de stroom goedkoper wordt'. Ook slimme sturingen zullen hieraan kunnen helpen, maar die zullen in eerste fase de prijs enkel maar méér opdrijven.

Het zal er met deze strategie altijd op neerkomen dat mensen die het financieel minder breed hebben, benadeeld worden, of beperkt in hun vrijheden. Ga je hen dan financieel verplichten thuis te blijven als de zon schijnt om hun was te doen?

Zet ik toch maar even een aluhoedje op, maar ik vind het wat beangstigend dat er een extern controleorgaan is, wat voor ons gaat bepalen, hoe duur je energie wordt en of je er überhaupt nog wel toegang toe hebt. Ik heb momenteel niet het gevoel hier harde garanties over te hebben gekregen dat dit menselijk en redelijk zal verlopen.

Ik zou niet weten waarom het kortzichtig is.
Mijn moeder doet dit ook, om die reden ook en daar is niks mis mee.

Het is niet een alles bepalende oplossing, maar volgens mij is niks doen pas kortzichtig?

Het is niet mijn bedoeling je opmerking te banaliseren en er zijn zéker goede manieren om hiermee om te gaan. Ik wil enkel zeggen dat dit niet in alle situaties mogelijk zal zijn, en dat er mensen die vandaag al moeten vechten voor hun plaatsje er niet op zullen vooruit gaan. Integendeel.
Waar er nog nooit zoveel geld en mogelijkheden in de wereld zijn rondgegaan, gaat de verdeling ervan enkel maar meer gecontroleerd worden. Laat ons dan maar hopen dat dit redelijk gebeurd. Uiteraard kan ik er niks op tegenhebben dat de energie zo veel mogelijk moet worden gebruikt als hij word geproduceerd of opgewekt. Het is een steeds complexer worden verhaal, waar de gebruiker meteen met concrete (en mogelijk negatieve) gevolgen zit.

Zo pakte ik het ook niet perse op, no worries.

Maar wat ik vaker zie is dat stappen in de goede richting gezien worden 'het is geen oplossing' terwijl het ook niet de oplossing is maar enkel een stap richting een oplossing.

In dit geval kan er wel altijd maximale energie gegenereerd worden, dus kerncentrales die gebouwd worden voor piekmomenten terwijl de dalmomenten ze net zo hard doordraaien, maar beter is om te werken naar een manier waarbij energie beter verdeeld wordt.
(althans, volgens mij is dat het doel van het systeem?)

De optimalisering van vraag en aanbod is inderdaad een goede zaak. Maar wat me zorgen baart is dat er tegelijkertijd financiële druk gezet wordt. En het klopt ook dat (sommige) mensen een gevolg moet voorgehouden worden voor er een gedragswijziging komt.
De vraag lijkt mij eerder: waar stopt dit en waar liggen de grenzen van zulk beleid?

Start mooi, kan snel lelijk worden. En je zal maar bij de gedupeerden zijn... De maatschappelijke solidariteit gaat dan snel naar 'je had je machine maar tijdens de zonneschijn laten draaien'. Ik ben niet voor betutteling, maar wil wel graag weten welke de longterm spelregels zijn.

Je gaat op termijn dan natuurlijk ook toestellen krijgen die hier rekening mee houden. Je wasmachine zal dan bijvoorbeeld automatisch wachten op goedkopere tarieven vooraleer het start, of je auto laad enkel boven de 50% bij goedkope tarieven. Dit gaat natuurlijk weer een groter verschil maken tussen mensen die kunnen investeren in deze dingen en mensen zonder de financiële ruimte voor investeringen.

Maar tegelijk is het ook effectief nodig dat we ons energieverbruik meer gaan afstemmen op het aanbod. Willen we meer gebruik maken van groene energie moeten we ook energieverbruik dat kan uitgesteld worden uitstellen tot er veel zon of wind is.

Goede tussenoplossing zou zijn om de prijsstijgingen bij een tekort afhankelijk te maken van je verbruik dan. Je wasmachine dan opzetten zal maar 10% duurder zijn dan anders, maar een volledige fabriek laten draaien kan dan wel 100% duurder zijn dan normaal. Op die manier leg je de druk om hier goed mee om te gaan voornamelijk bij de echte grootverbruikers, die met 1 investering vaak een relatief grote invloed kunnen hebben op het geheel.

Ik woon in een appartement en nee je moet niet s'nachts de wasmachine aanzetten.

Zo negatief lees ik dat niet. Er staat '[...] energieconsument [...] kunnen [...]'. Dus niet 'moeten' of 'zijn verplicht tot'.
Ik lees dit als 'de consument kan een contract afsluiten voor langere tijd tegen vast tarief maar heeft nu ook de keuze voor een contract met een variabel tarief'.

Beide hebben zo zijn voordelen.
Bij een vast tarief zijn de maandlasten mogelijk wat hoger, maar over een lange tijd stabieler, en voordeliger als er een een onverwachtse prijsstijging plaats vind. Wisselen van energieleverancier zal niet mogelijk of kostbaar zijn wat nadelig is als er een langdurige prijsdaling plaatsvind.

Bij een variabel tarief zijn de maandlasten mogelijk wat lager, maar over een lange tijd onstabieler, maar mogelijk op de lange duur voordeliger ten opzichte van een vast contract als er een een prijsdaling plaats vind. Mogelijk zal, bij stijging van de energieprijzen, het overstappen naar een goedkopere leverancier makkelijk en kosteloos zijn.

Maar die keuze van een variabel tarief is er al bij ons in België. Alleen door de stijgende energieprijzen gaan alle energieleveranciers van een vast tarief naar een Variabele.

Dit is dus eerder dynamischer dan echt het verschil tussen variabel en vast.

Neen omgekeerd door juist te plannen als de stroom goedkoper is kunnen ze meer verbruiken.

"Elke Belgische energieconsument met een digitale meter zal in de toekomst dankzij Atrias ook gebruik kunnen maken van dynamische energietarieven"

Dus als het koud is en er veel vraag naar energie is zullen mensen met weinig financiële middelen het zich niet kunnen veroorloven de verwarming aan te zetten.

Merk op dat er (1) kunnen staat en niet moeten ; (2) doen we er goed aan om sociaal beleid te voeren door iedereen hetzelfde sociaal beleid te geven en (3) is sociaal beleid via de energiefactuur het meest efficiënt?

De kosten stegen omdat de behoeften van de marktpartijen veranderden.

Die behoeften veranderen voortdurend en iets in de zin hierboven zegt me dat erg veel zaken heel statisch, "hardcoded", zijn en dit systeem dus niet met de markt mee kan bewegen.

Volgens Verdoodt is die 113 miljoen euro de afgelopen jaren via de Belgische distributienettarieven verrekend. "Er ligt geen factuur van 113 miljoen euro meer op ons te wachten", zegt hij. De Vlaamse distributienettarieven zijn volgens de woordvoerder de afgelopen jaren niet de hoogte ingeschoten door de ontwikkeling van Atrias. "Die dalen al voor het vijfde jaar op rij."

Als ik dit stuk lees krijg ik toch echt het idee dat de Belgische consument de afgelopen jaren flink genaaid is. Dalende distributienettarieven maar wel genoeg overhouden om een onverwachte rekening van 113 miljoen euro af te tikken...

Belgie = 5 miljoen huishoudens, maal 10 jaar, totaal 113 miljoen, kortom: 2,26 euro per jaar.

Ongeveer de kosten voor pint in een goedkope Belgische kroeg.

Verschillende partners hadden gaandeweg andere behoeften. Er was dus meer tijd en geld nodig om een goede dienst te ontwikkelen die ook toekomstgericht was
...
Volgens Verdoodt is die 113 miljoen euro de afgelopen jaren via de Belgische distributienettarieven verrekend.
...
Elke Belgische energieconsument met een digitale meter zal in de toekomst dankzij Atrias ook gebruik kunnen maken van dynamische energietarieven, maandelijkse afrekeningen en contracten bij verschillende energieleveranciers, afhankelijk van het type energiegebruik.

winstoptimalisatie voor de leveranciers op de kap van de gebruikers noemen ze dat kort gezegd, want vergeet maar dat bedrijven dit doen om minder te verdienen aan hun klanten

113 miljoen maar ? Waar hebben we het over… daar kan je nog lang geen corona app voor bouwen in Nederland en , elk ander overheidsproject in NL kost een veelvoud van dit bedrag (en mislukt dan vaak alsnog)

Wij als verbruikers worden dus voor de zoveelste keer opgelicht - ten bate van hen die nog meer winsten kunnen boeken!