Podcast

Dobrý den, moje jméno je Jirka Vyšerek.
Já jsem Šimon Prohajský.
A vítáme vás u nového dílu Datatalk podcastu. Naším dnešním hostem je Přemysl Voráž, vedoucí oddělení EMS ve společnosti ČEPS.
Ahoj, Přemku.
Ahoj, zdravím vás.

Přemku, my většinou začínáme historií a určitě se dostaneme i k té tvojí. Než tak ale začneme, myslím, že spousta lidí vůbec netuší, co je ČEPS, co děláte. A přitom máte celkem důležitou úlohu v naší kritické infrastruktuře. Tak představ na začátek ČEPS, než se dostaneme k tobě samotnému.

Určitě rád. ČEPS je vlastně provozovatel přenosové soustavy České republiky. Přenosovou soustavu si můžete představit jako dráty vysokého napětí, které míjíte například, když jedete po dálnici – jsou to ty vysoké stožáry. My máme na starosti správu a rozvoj elektrické přenosové soustavy na úrovních 400 až 220 kV. Nižší napětí na nižší úrovni má na starosti provozovatel distribučních soustav, což je v České republice například ČEZ, PRE v Praze nebo E.ON. Takže my máme na starosti přenos energie na nejvyšších napětích.

Dneska se spolu budeme bavit o tom, jak v ČEPS funguje IT infrastruktura a jak do ní implementujete AI. Než se dostaneme i k tomu oddělení EMS, které teď vedeš, jak ses k tomu dostal, jaká byla tvá cesta?

Ta cesta byla vlastně delší. Jsem původem student Západočeské univerzity, katedry kybernetiky a zároveň i Fakulty ekonomické. Když jsem nastupoval ke studiu na těchto školách, dával jsem si přihlášky na několik škol a říkal si, že bych chtěl určitě studovat na FAV, což byla v té době taková hezká technická škola, která mě lákala, ale přihlásil jsem se i na jiné školy. Nakonec mě vzali na více škol a přemýšlel jsem, že bych zkusil nejen studium na FAV, ale chodil třeba i na přednášky na ekonomickou fakultu. Chtěl jsem to zkusit, než mě z ekonomky vyhodí, protože mi přišlo zajímavé si rozšířit rozhled i v manažerské oblasti. Nakonec jsem tam vydržel tři, pět let a nevyhodili mě, tak jsem si říkal, že je to vlastně dobré.

Přišlo mi skvělé spojit technický pohled s ekonomickým a manažerským, protože člověk získá úplně jiné dovednosti z obou stran. Snažil jsem se vzít si z těchto dvou světů to nejlepší, takže to bylo na úrovni inženýrského studia. Potom jsem přemýšlel, jak dál, a dostal nabídku na doktorské studium na Fakultě aplikovaných věd, konkrétně v menším oddělení, které tehdy vedl pan docent Janeček. Nabídl mi, abych se zabýval energetikou, což bylo pro mě tehdy trochu neznámé, ale šlo o aplikaci principů a teorií řízení, které jsem uměl, a optimalizačních metod. Musím říct, že mě toto téma obecně strašně nadchlo a fascinovalo, protože svět energetiky je svým způsobem velmi specifický – musí být totiž neustále vyrovnaná nabídka a poptávka…

Tady je opravený text:

Když se na to podíváte z ekonomického hlediska, tak třeba ty trhy nejsou v ekvilibriu, tedy že by nabídka byla vyrovnaná s poptávkou, což v energetickém světě vždycky musí být. Je potřeba do toho systému dávat nějakou zpětnovazebnou regulaci – automatickou nebo i ruční – tam musí člověk zasahovat. A to znamená, že tam vlastně všechny ty věci, co se člověk naučil technicky, se daly do systému zakomponovat.

Takže říkáš: v jakém roce se bavíme, kdy jsi absolvoval, abychom to zařadili do nějakého časového rámce?

Inženýrské studium jsem dokončil v roce 2011, to už je pár věcí zpátky.

Následovalo potom doktorandské studium, které bylo velmi zajímavé tím, že téma mi přišlo unikátní. Když si dneska představíte nějaké energetické výpočty, většinou se ptáte: kolik může nějaká sada generátorů vyrábět? Například distributorka nebo někdo, kdo spravuje elektrárnu, chce vědět, kolik může ta elektrárna vyrábět přesně. Tam většinou je jedno číslo, uvádí se nějaká hodnota.

Téma mé práce v této oblasti bylo zkusit lidem nedat jen jedno číslo, ale dát jim nějaký interval. Generátor může vyrábět od–do a zaručíme, že ten interval bude vždycky bezpečný. Může jít o jeden generátor, ale takhle to lze udělat i pro čtyři, pět, nebo obecně n generátorů, nebo pět nějakých takových zařízení.

A to, co jsem vlastně obhajoval, byla metoda, která má zajistit bezpečnost pro n takových kombinací intervalů.

Potom jsem začal pracovat jako specialista, který měl na starosti transformaci dat, transformaci modelů přenosové soustavy z různých formátů do jednoho nového standardu, který se nazývá Common Grid Model Exchange Standard (CGMES). Když se na to dívám zpětně, tak mi v roce 2015 říkali, že tohle je budoucnost a že je to skoro hotové. Teď je rok 2024 a my se snažíme ten model vlastně dostat do provozu. Já už to nedělám, ale snažíme se po devíti, tedy skoro deseti letech, ho prosadit.

Takže moje cesta byla vlastně specialistou, který měl na starosti vývoj v Pythonu a modelování. Kdybychom se například podívali na Common Information Model, což je americký standard pro modelování zařízení a různých objektů, tak CGMES je jeho derivát. A já jsem se právě k tomu dostal.

A vlastně nějakou souhrou náhod, možná i politiky, jsem po asi pěti letech dostal nabídku vést tým, ve kterém jsem byl. Tou nabídkou přišel můj současný šéf, a musím říct, že si jí moc vážím, protože mi předával tým složený ze samých specialistů – expertů na danou problematiku v rámci celé České republiky. Nešlo o běžné zaměstnance, ale o respektované osobnosti, kteří už v posledních pár letech odcházeli do důchodu. Bylo to skvělé vést takové lidi, například pana Bohumila Seredského nebo Miloslavu Chladovou, ti byli bezva…

Pokud chcete, mohu text ještě dále upravit, zkrátit nebo upravit styl.

Jistě, zde je opravený a upravený text:

Adní experti. Chceš nám ten tým představit a říct, co dělá?
Určitě. Co znamená EMS? Musím říct, že na tuhle otázku se mě spousta lidí ptá, protože zkratka EMS může mít různé významy, ale v našem případě to znamená Energy Management System.

Máme to celkem kypé, máš kipo psaní — je to nějaký systém, který by měl podporovat rozhodování a snažit se nějak pomoci dispečerům nebo jiným operátorům v oblasti řízení přenosových soustav. Někteří tomu v ČEPSu říkají vyšší funkce dispečerského řídicího systému, ale dá se to vnímat také jako sada podpůrných funkcí, které mohou usnadnit rozhodování dispečerů nebo pracovníků přípravy provozu. Takže ve zkratce to je to, co děláme.

U nás jádro toho EMS už trochu přerůstá do většího portfolia věcí, které máme na starosti. Původní záměr byl vlastně vývoj těch vyšších funkcí, což mohou být například optimalizační metody nebo nějaké energetické výpočetní funkce přímo v dispečerském řídicím systému.

V současnosti tímto pracuje asi čtyři lidi, ale EMS funkce už také zahrnují vývoj vlastních aplikací, takže máme i frontendové a backendové vývojáře, databázové specialisty a nově patří do EMS i machine learning inženýři, data scientisté a ML ops tým, který vyvíjí aplikace.

Než se podíváme do těchto třech oblastí hlouběji, má ČEPS také vlastní IT tým, se kterým úzce spolupracujeme. Můžeš popsat organizační schéma a co spadá pod koho?
Určitě. Je dobré zmínit, že protože je ČEPS součástí kritické infrastruktury, nemůžeme úplně přejít do cloudu, takže máme velmi silné zázemí v on-premise řešeních a velký infrastrukturní tým. IT oddělení v ČEPSu je rozsáhlé a důležité, v současnosti má asi 120 lidí.

IT je organizované do větších odborů. Někteří lidé mají na starosti řízení požadavků, helpdesk, správu licencí. Je tu také tým, který spravuje telekomunikace, což je unikátní, protože máme vlastní oddělenou telekomunikační síť od internetu, nebo si pronajímáme jen části, ale většinu tvoří naše vlastní síť.

Dále máme tým zaměřený na dispečerské řízení a správu dispečerského řídicího systému. Já patřím k jednomu z těchto oddělení, které zajišťuje správu a rozvoj dispečerského řídicího systému. Ten má vlastní hardware, který je zcela oddělený od on-premise hardware ČEPSu, a zpracovává velké množství měření, která do něj musí přicházet. Tento dispečerský odbor je tedy zaparkovaný pod IT sekcí.

Kromě toho je v IT i market management systém, který je velmi důležitý, protože zajišťuje clearingy a ekonomické vyúčtování.

Co EMS konkrétně dělá? Vyvíjíme nové platformy, třeba pro výkonové rovnováhy a další funkce.

Pokud chceš, mohu pomoci s další úpravou nebo rozšířením textu.

Tady je opravený text s lepší srozumitelností a gramatikou:

Pak máme relativně nový odbor Enterprise architektury, který se snaží všechno v současné době vyzmapovat, protože firma je velká. Doufám, že jsem na nic nezapomněl. Pak je tu ještě podpora aplikací. Kolegovi by se určitě nelíbilo, kdybych ho nezmínil. Tam samozřejmě máme SAP a další věci, plus aplikace s dispečerským charakterem. Takže EMS patří pod velké IT, ano. Počítáš do svých 10 lidí i pod svůj odbor? Jsme jeho součástí. Super, díky. Tak jsme si organizačně vyjasnili, tak možná pojďme k vašim aplikacím, k tomu, co vlastně řešíte.

Nejprve jsi zmínil dispečerský systém. Ten má vlastní odbor, takže jaká je vaše úloha tam a jak to funguje? Možná na začátek popiš i, co to vlastně dělá.

My jsme vlastně součástí toho odboru. Když se podíváš do organizačního schématu, já jsem vedoucí toho odboru; pod ním jsou tři oddělení a MS je jedno z nich. Jsme tedy přímo v tomto odboru.

Dispečerský řídicí systém je velký systém. Když si to představíš, je postavený na vlastním hardwaru. Máme telemetrické, SCADA měření, které do systému musíme všechny přivést. Musíme do něj nasypat parametry a zapojení celé soustavy. Díky tomu, když to takto sestavíme dohromady, specialisté z EMSu, kolegové, kteří mají na starosti tzv. kreslení sestavy, jsou schopni vytvořit abstraktní model elektrizační soustavy nejen v České republice, ale i v celé observability area.

Observability area je Česká republika plus okolní státy – Polsko, Německo, kde je zajímavé, že Německo nemá jednoho, ale hned čtyři provozovatele přenosové soustavy. Takže v našem modelu jsou zastoupeni všichni tito čtyři němečtí PSO (i když ne celý, ale částečně), pak Rakousko, Slovensko a máme tam i Ukrajinu. Pamatujeme si, že Ukrajina se měla připojit v roce 2022 – myslím, že dva dny před únorem se skutečně připojila.

K čemu tento model slouží? Slouží právě k tomu, aby dispečeři věděli, co se děje. Systém je, jak jsem říkal, neuvěřitelně dynamický, výroba i spotřeba se neustále mění. Dispečer proto potřebuje znát aktuální stav, případné problémy, a když si poskládáme všechny tyto „kostičky“ dohromady, vidíme skutečný stav – tedy status quo.

Nad tím teď stavíme další funkce. Nejprve potřebujeme, protože do dispečerského řídicího systému přichází velké množství dat ze SCADA měření – prakticky na každém vývodu nějaké linky máme nejméně jedno, často i více měření.

Naše úloha, kterou se nyní snažíme řešit, je takzvaný přeurčený systém lineárních rovnic, tedy tzv. přeurčená úloha, …

Pokud chceš, mohu pokračovat a dokončit opravu podle původního textu.

Opravený text:

Musíme najít nějaké řešení, takzvaně estimujeme stav, tedy nejpravděpodobnější stav elektrizační soustavy. K tomu právě používáme nástroj zvaný estimace stavu, který není žádná velká věda – je to metoda vážených nejmenších čtverců. Snažíme se vlastně najít řešení nějakých lineárních rovnic na základě měření, která máme k dispozici. Díky tomu pak víme, v jakém stavu se soustava přibližně nachází. Dále pokračujeme s dalšími výpočty. Například se jedná o kontingenční analýzu, kdy si představujeme, že simulujeme výpadek libovolné linky, která může být v té středoevropské oblasti. Kdyby nastala nějaká porucha a linka vypadla, potřebujeme vědět, co by se v soustavě stalo. Jsme schopni provozovat soustavu i s výpadkem jedné linky. Tomu se říká kritérium N-1. Provozovatel přenosových soustav je nucen tuto soustavu provozovat právě v tomto režimu. Takže pokud by vypadla jedna linka například někde u Prahy, měli bychom být v bezpečí.

Na toto se pak dá navázat dalšími funkcemi, které jsou spíše optimalizačního či doporučovacího charakteru. Typickým příkladem je optimalizace napětí v přenosové soustavě. Jsme schopni ovládat například tlumivky – prvky, které ovlivňují jalový výkon v soustavě, a upravovat napětí tak, jak je zrovna potřeba, aby nedocházelo k problémům s napětím.

Mohu se na chvíli zastavit a zeptat se z jednoho pohledu – co vlastně je jalový výkon?

Určitě. Když se podíváme na soustavu a na Kirchhoffovy zákony, což je elektroenergetika nebo obecně energetika, tak při zjednodušeném pohledu, kdy například platí Ohmův zákon U = R × I (to je střední školská fyzika), tak výkon, který může téct drátem v přenosové soustavě, se skládá ze dvou částí – činný výkon…

Činný výkon je ten, který nám skutečně dodává energii a je schopný vykonávat práci. Pak je tu jalový výkon, který většina energetiků vnímá jako něco, co energii nedodává, není aktivní. Jak se tomu říká nebo s čím se to přirovnává? Ve školách třeba používají obrazné přirovnání – když máte nalité pivo, tak činný výkon představuje tekuté pivo a jalový výkon je pěna nahoře. To je pěkná pomůcka.

Z matematického hlediska je činný výkon reálnou částí komplexního výkonu, zatímco jalový výkon je jeho imaginární částí. Když se snažíte řídit soustavu, často pomocí určité aproximace abstrahujete od jalového výkonu a řídíte soustavu pouze podle činného výkonu. To se nazývá DC aproximace střídavé elektrizační soustavy. Jalový výkon totiž snižuje napětí ve soustavě tím, že má… (pokračování textu podle potřeby).

Jasně, tady je opravený text s lepší gramatikou, interpunkcí a stylistikou:

Jaké menší napětí vlastně? Jalový výkon se používá pro korekci amplitudy napětí. Když do systému dodáte nějaký větší jalový výkon, tak tento jalový výkon dokáže ovlivňovat, respektive korigovat amplitudy napětí v určitých uzlech, podle toho, jak pracuje daná tlumivka. Pokud tedy máme problém s nízkým napětím, můžeme pustit tlumivku, která dodá jalový výkon, a tento výkon má vliv na amplitudu napětí na vybraných místech. Takže to není jen otázka srovnání poptávky a nabídky, ale existuje zde mnohem víc proměnných – a je to určitě tak.

ČEPS má na starosti to, aby frekvence v síti byla neustále 50 Hz. Pohybujeme se v jistém tolerančním pásmu, ale pokud se něco stane, musíme mít v elektrárnách po republice rezervované výkony, abychom byli schopni výkyvy frekvence kompenzovat. Takže to je další důležitá věc. Není to primárně otázka napětí, ale právě frekvence, kterou se snažíme řídit.

A musím říct, že dispečeři si zaslouží obdiv – zvládají to opravdu skvěle.

Tím pádem rovnou skočím k dispečerovi. Tak co jsou ta rozhodnutí dispečera, která nyní přispívají k řízení systému? Co mu vy pomáháte dělat dalšími opatřeními? Rozhodnutí může být například zapnout tlumivku, přidat výkon do řízené sítě z nějaké baterie nebo elektrárny, kterou máte nasmlouvanou. Je tam spousta věcí, které dispečer musí řešit.

Na dispečerském sále je několik dispečerů – celkem jich je pět: dva síťoví dispečeři, obchodní dispečer, vedoucí směny a dispečer pro mimořádné události (emergency dispečer). Síťový dispečer musí zajistit bezpečnost celé soustavy. Tyto role jsou hlavními uživateli systému, kterým nabízíme různé služby – samozřejmě i emergency dispečeři a obchodní dispečeři.

Typická práce síťového dispečera spočívá v manipulaci se sítí – snaží se upravovat cokoli, co je v soustavě ovladatelné. Jedna z jejich zajímavých funkcí je například sepnutí nebo rozepnutí nějakého spínače či vypínače. Musí samozřejmě zajistit, aby ustálení přechodových dějů fungovalo správně, což také zahrnuje řešení otázek dynamické stability. To jsou taky důležité věci. V momentě, kdy dispečer něco změní,

to musí fungovat. K tomu je třeba, aby výpočty byly správné. Znamená to, že napětí musí být v mezích, proudy musí být v mezích, což je velké téma. Když dispečer něco změní, zpravidla se provádí odpovídající výpočty.

Kolik akcí proti tomu obvykle dispečer provede za hodinu? Já si to představuji trochu jako Homera Simpsona, který tam čeká, jestli se neobjeví nějaké varovné znamení, aby něco udělal. Ale podle toho, jak to popisujete, to spíš zní jako téměř hudební virtuóz, který plynule přechází od jednoho ovladače k druhému. Asi je to podle dne.

Já ale nechci mluvit za…

Pokud chcete, můžu text dále zkrátit, zpřehlednit nebo upravit pro konkrétní styl.

Opravený text:

Naše dispečery čekají určitě dny, kdy mají menší provoz, a kdy zase větší. Myslím si, že to je docela zátěž. Rozhodně jsou dispečeři, například emergency dispečer, na kterého se valí spousta nových věcí. Třeba validace, flow-based capacity – musí každý den vytvářet předpovědní modely. Takže nejen síťoví dispečeři, ale i emergency dispečeři a obchodní dispečeři teď také řeší spoustu nových věcí. Musí se nějakým způsobem popasovat s novými službami výkonové rovnováhy, kdy máme celoevropské platformy, které se jmenují Marii a Picasso. Emergency dispečer tam nyní musí řešit i poptávku na celoevropském trhu podpůrných služeb.

Nevím, jestli jste slyšeli, jak se občas ve zprávách objeví otázka, proč je elektřina levná v Německu a v Česku drahá, nebo naopak. Tam totiž fungují tržní mechanismy na principu aukcí a dispečer se s tím musí nějakým způsobem vypořádat. Takže velký klobouk dolů před těmi lidmi – jsou hrdiny naší moderní doby. Takto na dálku děkujeme dispečerům, že nám tady svítí světlo a že nahrávací zařízení funguje.

Tak co EMS, co vy vlastně pro ty dispečery děláte? Když bychom šli do konkrétních projektů, myslím si, že nejpokročilejší věcí, kterou jsme teď dodávali, byl Security Constraint Optimization. Není to úplně nová věc, ale je to takový téměř state of the art v oblasti energetických funkcí. Jde o nástroj, který doporučuje nápravná opatření na základě aktuálního stavu. Vstupem do tohoto problému je seznam, co dispečer může buď vypnout, zapnout, nebo případně i nastartovat, i když to už jsou dražší záležitosti. Většinou se snažíme najít nápravná opatření, která jsou takzvaně nenákladová, například přepnutí některého odboče transformátorů nebo přepnutí v rozvodnách či na vedeních, aby se snížilo přetížení sítě.

Pak máme optimalizační nástroj, který tohle umí udělat. To je super a hodně se teď využívá právě při validaci kapacit přeshraničních přenosů. Minulý nebo předminulý rok jsme ještě dodělali jeden nástroj, který pomáhá právě těmto platformám – myslím ty platformy pro nákup služeb výkonové rovnováhy, Marii a Picasso. Dodali jsme nástroj, který se snaží vzít jednotlivé nabídky (bidy), které jsou na trzích, a vytvořit optimální portfolio těchto nabídek tak, aby nákup byl co nejlevnější. Pomáhá to dispečerům sestavit toto portfolio – z matematického a optimalizačního pohledu je to úloha typu batohu, což je technický termín. Řešíte problém, kdy máte poptávku třeba 100 megawattů a snažíte se ji složit co nejlevněji z toho, co máte na trhu dostupné. To je vlastně další důležitá věc z oblasti dispečerské práce.

Pokud chcete, můžu text ještě více upravit stylisticky či zjednodušit podle potřeby.

Takový jako, myslím, že velká část všeho z těch dispečerských aplikací… Můžu se zeptat, jak to dělali ti dispečeři před tím, než jste jim dodělali tenhle systém? No, snažili se expertně odhadnout ten stav. To samozřejmě… my můžeme…

Máme nakoupit tak, aby to všechno bylo co nejlevnější. Nějakým způsobem se s tím museli popasovat. Ani ty služby výkonové rovnováhy přes ty platformy nejsou tak úplně nová věc. Myslím, že je teď rok 2023, možná 2022, ten čas letí, je to už nějakou dobu zpátky, ale stále relativně nový.

No a říkal jsi, že jste více, že jsi jeden ze tří týmů, že vedeš jeden ze tří týmů, který se stará o ten dispečerský systém. Tak jaká je vaše role, když třeba jednu z těch aplikací dodáváte? Kde končí vaše práce a přebírají ji jiní? Vlastně u nás dispečerský řídící systém nevyvíjíme my. Naše role je na úrovni uživatelů a správců toho systému, ne s vývojem dispečerského systému od píky. To s sebou nese velké množství práce a velkou míru zodpovědnosti za systém. Teď to vlastně zkouší Němci, je to společnost, která se jmenuje Fiftyherci, snaží se vyvíjet vlastní systém úplně od začátku. Lidé tam do toho dávají velké množství prostředků a snaží se to posunout. Ale u nás to tak není. My máme externí firmu, která nám zajišťuje služby, aby systém fungoval. My jsme na úrovni správců, takže jsme, jak jsem zmínil, schopní třeba vytvořit nějakou sestavu, což je grafický editor.

Musíme dostat všechna data, telemetrii a data v reálném čase, zajistit i topologické zpracování, tedy jakým způsobem jsou linky navzájem propojené, a potom vytvořit celý model tak, aby byl živý a fungoval v té granularitě, kterou jsem zmiňoval – že máme teď tu obsáhlost a zároveň vidíme celou distribuční soustavu. Tento model máme na úrovni 22 kV. To všechno dělají lidé z našeho týmu TEMS. K tomu přistupují i výpočetní funkce. My tedy nejsme programátoři v této oblasti. Dá se říct, že jsme na úrovni skriptování, například v Koronu, kde píšeme drobné skripty nebo dopočty v proprietárním jazyce dispečerského systému, ale určitě nejsme schopni začít programovat celý systém od základu.

Ale to není jediná věc, kterou děláte, je to tak? Máte tam programátory a programujete, jak jsi říkal? Jo, jo. My jsme vlastně… To má taky svou historii. Když jsem nastupoval do tohoto oddělení v roce 2015, byl jsem jediný programátor a byl jsem takový nadšenec pro věc. Snažil jsem se programovat sám, nechtěl jsem být jen konzument aplikací, ale chtěl jsem být tvůrcem kódu a aplikací a mít tu doménovou a expertní znalost. Snažil jsem se ji budovat uvnitř. A tím se vlastně snažíme dělat věci on-premise, protože jako součást kritické infrastruktury nemůžeme úplně přejít do cloudu, takže cloud u nás není preferovaný. A ten stack, ty aplikace, jsou napsané v Pythonu, ten…

Backendová část. Když pracujeme s daty, využíváme MongoDB pro nestrukturovaná data a SQL pro strukturovaná. Backendová část je tímto způsobem obsloužená. Pak aplikaci běžně používají uživatelé.

Zkoumáme interakce, vytváříme nějaké GUI, kde musí být frontend. Na frontendu pracujeme s Vue.js a využíváme Apache eCharts a FastAPI. To vše spolu ladí a jsme schopni vytvářet specializované aplikace, například pro přípravu provozu. Výborný use case jsme měli před třemi lety, kdy za námi přišli lidé ze zabezpečení provozu, kteří potřebovali pomoci s tvorbou dlouhodobějších modelů. V dispečerském systému dnes dokážeme dělat modely a vytvářet nejlepší možnou predikci, jak bude vypadat přenosová soustava dnes a zítra, tedy dva dny dopředu. Ti kolegové ze zabezpečení provozu však potřebovali predikce na týden, měsíc, nebo rok dopředu. Řekli jsme si, že tento požadavek můžeme řešit v dispečerském řídicím systému, ale tím ztratíme vlastnictví znalostí a know-how, což se nám zdálo škoda. Proto jsme šli do vlastní aplikace.

Tato aplikace nyní dokáže sesbírat data, použít model přenosové soustavy a vytvořit predikci na týden, měsíc i rok dopředu. Nyní máme vše pod kontrolou, včetně know-how a výpočetních metod, což je obrovský krok vpřed.

Jak vyhodnocujete přesnost těchto predikcí? Je obtížné vyhodnotit přesnost modelu proti reálným datům. Kolegové chtěli nástroj, který by srovnával třeba dvoudenní predikci se skutečným výsledkem. Tento nástroj zatím nemáme, ale máme po něm poptávku. Prozatím to děláme ad hoc – člověk si musí vzít model a porovnat výsledky. Model obsahuje tisíce časových řad, například injekce z obnovitelných zdrojů, jako jsou solární a větrné elektrárny. Tyto zdroje se kombinují s odběry a výrobou. Nasazení zdrojů je relativně jednoduché – existuje plán, podle kterého se jede. U obnovitelných zdrojů a spotřeb však vznikají rozdíly, které je potřeba kontrolovat. Jde o velmi velké množství dat, které se dosud kontrolovalo ručně. Plánujeme tuto kontrolu automatizovat.

Když jsi mluvil o kategoriích, které řešíte, třetí byla umělá inteligence. Než se k ní dostaneme, co je nejmenší vlastní aplikace, kterou vyrábíte? Tohle, o čem jsi mluvil – predikce – znělo dost jako predikční modelování a AI heavy aplikace s front-endem.

Nejjednodušší aplikace je třeba menší nástroj, který například transformuje Excelovská data pro dispečery, kteří zaj… (pokračování by bylo potřeba podle dalšího zadání).

Jistě, zde je opravený text s úpravou gramatiky, pravopisu a stylistiky, aby byl plynulejší a srozumitelnější:

Zajišťujeme jenom transformaci z něčeho jako XML, tedy Excelové reprezentace do XML, a následně zasílání přes nějaký integrační kanál, třeba do zahraničí. Jsou to takové menší věci, které například distribuují data mezi jednotlivými systémy. Až na menší záležitosti je tento nástroj pro tvorbu predikčních modelů už komplexní věc, tedy skutečně větší. Takže nám řekni víc o té AI, protože chápu, že není součástí těch APK?

Celé to oddělení je vlastně stále jeden útvar, organizačně je to jeden celek, ve kterém pracují specialisté MS. My jsme se ale někdy od roku 2020 začali zabývat otázkou, zda by nedávalo smysl využít metody strojového učení nebo umělé inteligence v energetice. Když to zkrátím, vznikla z toho naše interní AI kompetence, máme možnost tým budovat. Zatím nejsme ve stavu, že by byl úplně hotový, ale pracujeme na něm a snažíme se vytvořit tým lidí, kteří budou schopni a ochotní vytvářet aplikace svým technologickým stekem od začátku.

Přitom ale stále zůstávají součástí technické infrastruktury, což znamená, že musí splnit i další požadavky, nejenom načíst tyto notebooky či základní aplikace.

Určitě. Oblast umělé inteligence v energetice je velmi specifická v tom, že musíme neustále usilovat o vytváření vysvětlitelných metod. Dbáme také na to, aby výstupy z těchto modelů byly robustní. Nemůžeme si dovolit vytvořit nestabilní model strojového učení či umělé inteligence, který by byl nekvalitní. Proto je kladen velký důraz na to, aby byly modely vysvětlitelné a kvalitní.

Co se nyní snažíme zavádět v praxi, je definice interního machine learning operation cyklu, který obsahuje i etické posouzení daného use case. Zatím jsme na to připraveni a uvidíme, kdy se tato část začne skutečně používat.

A co se musí eticky posuzovat v energetice? U cenotvorby si třeba dokážu představit, že by tam mohla být diskriminace. Dále je důležité dbát na aspekty compliance – pokud se model vytváří, musí splňovat všechny náležitosti. Kolegové mají na starosti třeba GDPR a otázky zpracování dat, aby model neměl přístup k datům, ke kterým nemá mít přístup, nebo aby nebyl biasovaný například strukturou dat z hlediska pohlaví (muži vs. ženy) a podobně.

Právě to je další důležitá věc. Nechali jsme zpracovat studii o etice v AI a energetice a podle mě je klíčové vůbec se na toto téma ptát. Je potřeba zvážit, jestli v novém projektu není nějaký potenciální dopad. Obvykle se totiž nejdřív jdou business požadavky, které se transformují do user stories, a pak se už zahajuje práce.

Pokud chceš, můžu text ještě více zjednodušit nebo upravit do formálnějšího stylu.

Zde je opravený text:

A když se posoudí, že ta úloha je vhodná pro umělou inteligenci a dává smysl, aby ji řešila umělá inteligence, tak si to třeba můžeme ještě říct. Ale nesmí ten model dělat něco, co by mohlo být potenciálně neetické. Jenom si to lze udělat jako myšlenkové cvičení a říct si: „Hele, tohle možná stojí za to, abychom se nad tím zamysleli.“

Jak tahle pečlivost v plánování a posuzování dopadů ovlivňuje váš technologický stack a běžnou každodenní práci vašich AI vývojářů?

Ten dopad určitě máme. Museli jsme se nad tímto tématem důkladně zamyslet. Nechtěli jsme totiž využívat uzavřená řešení – já sám se držím podobných principů, tedy mít know-how doma a snažit se vytvořit tým lidí, kteří problematice rozumí. Chtěli jsme jít v oblasti umělé inteligence a strojového učení cestou otevřeného zdroje a otevřených řešení. Nepoužíváme tedy žádné převratné, speciální nástroje, ale standardní knihovny jako Python, Scikit-learn, Keras, TensorFlow a podobně.

Navíc se nám docela osvědčilo využívat MLflow jako nástroj pro správu modelů umělé inteligence. Tento technologický stack zatím vnímám jako vhodný. Na začátku používáme virtualizaci, v této virtuální infrastruktuře potom aplikace běží. Máme MLflow server, do kterého nahráváme modely, a pomocí REST API lze volat inferenční služby — zadat vstupní data a získat výstup. To je fajn. Rádi bychom však také postupovali k nějaké kontainerizaci a využívání clusterů, ideálně na Kubernetes, abychom dosáhli lepší škálovatelnosti a dostupnosti.

A protože některé use casey, které máme na starosti, vyžadují skutečně pravidelné predikce, například každých 15 minut, potřebujeme zajištění co nejvyšší dostupnosti.

Sledujete i metriky kolem režijních konceptů jako drafty a podobně?

Ano, snažíme se monitorovat KPI modelů. Pomocí MLflow sledujeme především metriky, jako jsou MIE (Mean Integrated Error), MAP (Mean Average Precision) a podobné indikátory. Když dojde k nějakému dramatickému zhoršení nebo nárůstu těchto metrik, je samozřejmě potřeba se zabývat tím, jestli model nemá nějaký problém. V takovém případě může být potřeba upravit feature vector, či dokonce změnit modelovací přístup. To rozhodně provádíme.

Kde umělou inteligenci nasazujete? Do jakých use caseů? Jak je vybíráte? Co byly první pilotní projekty a do čeho jste se pustili?

Začali jsme někdy v roce 2020. To bylo období, kdy jsme si řekli, že to pro nás má nějaký význam. Já sám jsem Power System Engineer a neměl jsem velkou doménovou znalost v oblasti AI, takže nás zajímalo, co vlastně metodami strojového učení můžeme řešit. Nejdřív jsme si nechali udělat studii, kde jsme se podívali na nejzajímavější možnosti…

Pokud chcete, mohu s textem pomoci dále.

Jasně, tady je opravený text:

…jší oblasti, kdyby se to umělá inteligence v energetice vůbec dala použít, kde by dávala smysl.

My jsme vlastně začínali nějakou studií, ze které nám vypadlo přibližně 30 use caseů, což nás překvapilo. V té době jsme byli překvapení, že teoretických prací je dost, ale reálných aplikací v provozu u operátorů přenosových soustav nebylo tolik, nebo k nim nebyly dostupné žádné use casey či reference, že by někdo úspěšně dostal řešení do provozu.

V té době kolem roku 2020, když jsme se ptali ostatních TSO, tak si nebyli úplně jistí a nedokázali nám dát nějakou přínosnou zpětnou vazbu. Takže jsme si řekli, že máme tady nějakou sadu use caseů a pokusíme se z té baterie vybrat nějakou podmnožinu. My jsme si vybrali vlastně tři, ze kterých jsme vytvořili pilotní projekt, na kterém jsme chtěli otestovat funkčnost a schopnost interního týmu společně s externím dodavatelem vytvořit modely.

Takže jsme v roce 2020 prezentovali představenstvu business case, ve kterém jsme se snažili obhájit ekonomickou návratnost investice do této oblasti. Bylo to zábavné, jsem rád, že to schválili, díky čemuž jsme se mohli posunout dál.

Teď, když se posouváme dál, jak se staví takový business case pro někoho, kdo nás poslouchá? Jak k tomu přistupuješ? Co jsou slepé uličky, vábění a mámení, a jak to udělat dobře?

Určitě jsme si z toho vzali několik poznatků. Na začátku managementu většina vrcholových manažerů potřebuje tvrdá čísla, potřebují, aby business case ekonomicky vycházel. Například jeden z pilotovaných use caseů byla predikce ztrát v přenosové soustavě, kdy jsme měli přesnost měřenou pomocí MIE asi na úrovni 13 megawattů pro jednodenní predikci.

Podařilo se nám hodnotu snížit, myslím, že jsme byli na úrovni asi 11 megawattů, takže jsme se o 2 megawaty přiblížili ideálu. Když si vezmeš, kolik stojí 2 megawaty pro nás, kteří nakupujeme energii ve velkém… jsou to nižší desítky milionů korun. To znamená, že jsme tímto jediným use casem dokázali zaplatit pilotní projekt za přibližně tři měsíce jeho provozu. To je skvělé, že jsme měli use case, který byl ekonomicky rentabilní.

Pak jsme se snažili využít metody strojového učení k identifikaci chyb v modelu elektrizační soustavy. Jak jsem zmínil na začátku, dispečerské řízení zahrnuje správu celého modelu, který sahá od Baltu po Jadran. Model musí být v pořádku, ale představ si, že máme třeba 30 000 měření, 40…

Pokud chceš, můžu ti opravit i zbytek, který jsi nenapsal celý.

Opravený text:

00 uzlů, velké město uzlů a velké město měření. Tam samozřejmě člověk udělá chybu, kolegové to kreslí všechno ručně. Máme nástroje, které samozřejmě hledají potenciální chyby, ale přišlo nám dobré v té době vzít si nějaký model a natrénovat klasifikátory, které by byly schopné hledat potenciální chyby v tom modelu. Potom je už práce na specialistech, kteří ten model kreslí. Může se stát, že když je v tom modelu nějaká větší chyba nebo se provozní stav a situace tý síť nějakým způsobem „zamotají“, tak ta estimace, která je fakt kritická, začne divergovat. V momentě, kdy by divergovala nějakou další dobu, třeba půl hodiny a víc, je to velký problém. Pak dispečer může hlásit větší problém, než hlásí ostatní TSU v okolí, že už se něco děje.

Toto je špatné a my jsme se snažili tady pomoci specialistům, aby se tohle nedělo a aby chybu našli co nejdřív. To bylo taky super. Problém tohoto přístupu zpětně je v tom, že jsme tu úlohu definovali jako úlohu supervised learning (učením pod dohledem). Supervised learning je super, když máte dostatečné množství trénovacích dat a model natrénujete na to, na co je natrénován, a on to pak hledá. Problém je, že musíte modelu říct, kde chyba skutečně je a nějak ji nasimulovat. Ukázalo se, že v tomto případě je velmi náročné neustále generovat trénovací množiny pro obrovský model, ve kterém hledáte chyby.

Zpětně bych tedy rozhodně volil nějaký jiný přístup než supervised learning, protože trénování by bylo potřeba neustále opakovat, protože model se často mění a úpravy v sestavě jsou velmi časté, takže je to náročné. Ale je skvělé, že okamžitě po nasazení modelu člověk vidí změnu. Není to žádný model na to, která reklama by se měla zobrazovat více, aby se prodalo o něco víc utěrek. V ČEPSu je super, že i když stavíme tým a děláme nové věci – například nové prediktory – tak je opravdu cítit, že to roste. Celý ten model, při kterém lidé mají možnost si sáhnout na data i na modelovací části a mohou si ho třeba nasadit, to je obrovská přidaná hodnota, když je člověk v týmu.

Teď hledáme lidi do týmu a dost často se mi stává, že si povídám s lidmi, kteří pracují v nějakém velkém nadnárodním projektu, třeba na části nějakého obrovského modelu pro zpracování obrazu, ale dodávají jen velmi malou část. U nás lidé mají na starosti to, že to mohou vzít za své a přizpůsobit si to. Neříkám, že by to byla one-man show, ale tým reálně vidí svůj produkt, který může nasadit a provozovat.

Mně přijde, že brand energetiky se v posledních letech dost změnil a posunul. Dříve jsem ji vnímal jako průmysl, něco takového…

Tady je opravený text:

Mé. Ale s pokračující invazí na Ukrajině a všemi výstrahami blackoutů a tím, jak se energetický trh významně mění s obnovitelnými zdroji, mi přijde, že energetika se stává jedním z nejdůležitějších oborů. Trochu mě překvapuje, že vlastně s AI to byl takový velký krok pro vás. Jak jsi mluvil předtím o tom, jak modelujete přenosovou soustavu a jak nad tím přemýšlíte, tak to byla pro mě celkem pokročilá matematika, která už k data science, tedy ke statistice, je velmi blízko.

Jo, já zase nemůžu říct, že bychom… Je otázka, jakým způsobem stanovíme hranici mezi statistickými metodami a datovou vědou nebo datovým inženýrstvím. Určitě když řeknu například regresní modely, volbinární regrese nebo základní detekci odlehlých hodnot, i to v rámci dispečerského řízení máme, takže zase nechci tvrdit, že jsme vůbec neměli nějaké takové analytiky a vědce. To jo, jenom spíš jsme sami nevěděli, že takoví lidé vlastně jsou data scientisti a pořád jsou. Kdybychom to vzali do důsledků, tak rozesetí lidé po firmě mají znalosti datové analýzy nebo datové vědy.

Ale i v rámci AI týmu, který se tady nějakým způsobem buduje, nemáme ambici řídit veškeré věci v rámci ČEPSu, spíš chceme být nějaký orgán nebo útvar, který je schopný poskytovat službu, vytvořit nějaký model, a když bude poptávka a dohodneme se, můžeme konzultovat některé věci. Neznamená to ale, že nemáme chytré lidi schopné dělat datové analýzy a datové inženýrství.

Jaké hlavní úlohy v AI váš tým řeší? Jedná se hlavně o predikci časových řad. Jak jsme se bavili na začátku, ČEPS má na starosti vyrovnávání rozdílu mezi výrobou a spotřebou. Pro nás jsou velmi důležité takzvané systémové veličiny, jako je celková výroba, celková spotřeba, a proto mají tyto predikční úlohy velký význam.

Zmiňoval jsem předchozí predikci ztrát v přenosové soustavě, což je velmi důležitá úloha, protože musíme nakupovat energii na různých trzích, abychom vyrovnali tyto ztráty. Dále jde o predikci obnovitelných zdrojů, které mají náhodný charakter podle toho, jak svítí slunce nebo fouká vítr, což je další oblast.

A teď se objevuje elektromobilita, což je obrovské téma, protože si představte, že v jednom velkém městě je mnoho elektromobilů – to přinese do soustavy obrovskou nejistotu, protože ty baterie se musí někdy nabíjet. A když musíte dimenzovat nejen přenosovou, ale i distribuční soustavu, nastává problém, například když všichni lidé najednou odjedou na hory nebo jinam a začnou tam nabíjet auta – znamená to, že na horách musíte mít…

Pokud chcete, můžu vám ještě s textem pomoci pokračovat nebo ho více upravit.

Zde je opravený text:

Máme soustavu připravenou i na takové případy, nebo to je jeden příklad, ale obecně predikce flexibility, obnovitelných zdrojů a těchto intermitentních časových špiček je něco, čím se hodně zabýváme. Je to velmi důležité pro operátora přenosové soustavy. Takže to je ta predikční část, ale existují i další.

Například otázky spojené s bezpečností. Pořád máme rozsáhlé rozvody, které musí být nějakým způsobem zabezpečeny. Řešíme širokou paletu problémů. Tam se bavíme například o computer vision, tedy o zpracování obrazu, spíše jako o dispečerském řízení energetického obchodu, což je také důležitý use case. Potom jsou složitější věci. Na začátku jsem zmiňoval flow-based doménu. To je takový hypotetický prostor, nějaký endrozměrný prostor, ve kterém se mohou pohybovat přeshraniční výměny v rámci nějakého regionu. My pracujeme v regionu Core, například v CHEPS, a tato úloha spočívá v tom, že na základě známého modelu přenosové soustavy na určitou dobu dopředu zkusíme odhadnout, jak bude vypadat doména bezpečných toků mezi jednotlivými profily. To je také velmi zajímavá věc. Ještě jsme se k tomu úplně nedostali, uvidíme, co nás čeká v rámci celé řady use case, které máme – asi jich je teď asi třicet. Takže to je taková ochutnávka.

Když se podíváme na jednotlivé úlohy a modely, můžeme je přibližně rozdělit: co jsou studie, tedy jednorázové výpočty, které dávají nějakou predikci, co jsou systémy, které opakovaně ukazují predikce a vysvětlují je někomu denně, a co z toho jsou automatizované systémy, které už běží samostatně a nahrazují manuální rozhodovací práci někoho v organizaci. To je dobrá otázka. Některé prediktory jsou už ve fázi, kdy operátor jen sleduje hodnoty a podle nich nakupuje, takže to slouží jako podpora člověka, který má na starosti danou činnost. U jiných prediktorů uvažujeme o integraci přímo do dispečerského řídícího systému, případně je obalit nějakou optimalizací. V takovém případě nejprve vypredikujeme hodnotu, kterou pak můžeme použít k optimalizaci nákupu služeb výkonnostní rovnováhy – například pro danou predikovanou hodnotu část služby nakoupit a část nechat na rozhodnutí dispečera nebo uživatele. Když to shrnu, tak se spíše zaměřujeme na úlohy, které jsou svým charakterem systémy nebo aplikacemi vytvářejícími predikce na základě vstupu. To, jakým způsobem je integrujeme, je zatím na úrovni poloviční automatizace, přičemž v budoucnu bychom některé z těchto use case mohli automatizovat. Technicky bychom to samozřejmě zvládli, ale zatím to tak neděláme. Raději necháváme člověka, aby měl konečné rozhodnutí. Takže spíše jsou to takové… (text končí).

Opravený text:

Máme jeden dodatek, jsou to kopiloti. Tam může být ještě hodně zajímavých jednotlivých úloh. My jsme tady, já jsem docela rád, že jsme zatím vlastně nezmiňovali velké jazykové modely. Pro mě je to určitě zajímavé téma. My třeba pro dispečery připravujeme specializovaného chatbota, který by měl pracovat s nějakou sadou informací. Dispečer pracuje s něčím, co se nazývá provozní instrukce – jsou to instrukce o tom, jakým způsobem pracovat, manipulovat, dělat zásahy v daném modelu, o kterém jsme se bavili. Nebo to může být nějaká sada postupů, jak reagovat v konkrétní situaci. Tyto data máme k dispozici. Dispečer o nich ví, ale když něco potřebuje udělat, musí si danou provozní instrukci najít, přečíst a vědět, že existuje, což by měl, ale přesto se musí podívat do dokumentu.

Co bychom chtěli teď udělat, je uspořádat tyto informace pro dispečery do nějaké vektorové databáze a mít je jako podporu pro dispečera. Zároveň je tu velká otázka, zda by dispečer měl pracovat přímo s LLM. LLM by bylo super a bylo by dobré, kdybychom měli LLM přímo on-prem, což si ale do příštího roku nedokážeme představit. Díky tomu, že nyní máme – nebo spíše Meta vydala – otevřený model LLaMA 70 miliard parametrů, tak nám to dává skvělou příležitost nasadit si tuto LLaMA 70 on-prem a udělat takovou podporu. Pravděpodobně to tak dopadne, uvidíme, jak se projekt bude v příštím roce koncipovat. Vezmeme tuto LLaMA, nasadíme ji on-prem a vložíme do ní příslušné instrukce, aby skutečně dispečerovi odpovídala na otázky, jak v daných situacích reagovat.

Takže dispečer se může ptát a dostávat odpovědi. Ideálně by věděl… Což je pro mě další důležitá věc, jak dispečerovi pomáhat – najít mu adekvátní podporu. Z jedné strany zkoumáme chyby v modelu, na tom budeme stavět dál, ale z druhé strany chceme mít jakéhosi „buddyho“, který mu bude pomáhat. Zatím ne zcela automaticky, ale zatím jako copilota. Lokální deployment jazykového modelu je tak vlastně na hranici možného.

Dobře to jsi řekl. Lokální deployment velikých jazykových modelů je opravdu na hranici dostupných technologií. Máte na to lidi, nebo to budete hledat? Rádi bychom do vznikajícího týmu vytvořili pozici tzv. LLM inženýra. Nevím, jestli je tento pojem ustálený, ale do čtyřčlenného týmu, který by měl obsahovat machine learning inženýry a data scientisty, řešící machine learning operations, chceme přidat člověka, který se bude starat přímo o LLM. Když budeme mít on-prem řešení, bude se starat také o infrastrukturu – doslova o chovatele LLaMA. Ten by se mohl starat i o nějaké jiné modely, například Mistral nebo budoucí varianty. To je můj skromný názor, který zatím mám.

Tady je opravený text s lepší gramatikou, interpunkcí a stylistikou:

Dělám to tak, že ty LLM se, doufám, budou postupně zmenšovat a obecnější modely by mohly být čím dál menší a zároveň použitelnější v nějaké rozumné míře. Ale tady ten „chovatel“ by se v podstatě mohl starat jak o on-premise řešení, tak o další rodiny LLM modelů. Vlastně máme interně — a dnes už asi každá firma má — velkou poptávku po LLM uvnitř firmy. Musíme se postavit k tomu tak, že přijdeme s nějakými produkty, které budou schopné obsloužit co největší množství interních uživatelů. Zároveň ale nechceme mít situaci, kdy je LLM využíváno i produktováno až příliš — nechceme mít 40 různých produktů. Chceme navrhnout takové portfolio, které budeme interním zákazníkům nabízet, abychom se z toho sami nezbláznili.

Moje představa, o které s kolegy hodně diskutujeme, je taková, že pro ty nejkritičtější úzké případy, kde je třeba, aby data neopouštěla například náš perimeter, bychom navrhovali on-premise LLM, třeba LLaMA pro dispečery. A jak bychom se posunuli mimo tuhle úroveň bezpečnosti informací, mohli bychom nabídnout buď nějaké customizované řešení pomocí Azure OpenAI studia, anebo naprosto obecné řešení, třeba placené GPT, chat GPT nebo Perplexity. Chceme to tedy nějak stabilizovat jako produkty, ale na tom ještě pracujeme — je to velmi dynamické a aktuální téma, nejen ve světě, ale i v ČEPSu. Vy jste to tady vyřešili první?

Co se týká tebe, máš specifický způsob, jak najímáš a manažuješ lidi, že?

Jo, jo. Vlastně mi to dává docela smysl. Když nabíráme lidi a starám se o členy týmu, snažím se pracovat s každým individuálně. Moji kolegové dělají práci, která je charakterem velmi specializovaná — jsou to specialisté. Nejde o to, že by byli oceněni za to, že vyrobí určité množství výrobků. Spíše se jedná o kreativní práci, kde člověk musí vytvářet abstraktní produkty nebo IT řešení.

Když tedy najímám a starám se o tým, každý člověk je svým způsobem jedinečný. Co se mi osvědčilo, je využívat silné stránky a rozvíjet je. Používám k tomu test Clifton Strengths od Gallupu, který naši kolegové udělali. Ten test definuje deset nejsilnějších „perků“ každého člověka — představte si to třeba jako perky z her Fallout. Já si na ně právě vzpomněl. A když už jsme v té energetice… To je pravda — tak vlastně…

Pokud chceš, mohu text ještě upravit do formálnější nebo stručnější podoby. Stačí říct.

Jistě, zde je opravený text s lepší strukturou, gramatikou a stylistikou:

Tam se dá pracovat třeba s prvními pěti nebo prvními deseti silnými stránkami. Ty jsou totiž hodně dominantní v rámci každého člověka a dá se s nimi efektivně pracovat. Já osobně, když to shrnu, tak mých prvních pět silných stránek jsou například: learner (učedník), což znamená, že rád učím a jsem schopný se učit nové věci; achiever (dokončovatel), což je člověk, který rád dokončuje práci a vidí výsledky své snahy; a competition (soutěživost), tedy snaha vyhrávat a účastnit se soutěže. A takhle to pokračuje dál s dalšími silnými stránkami.

Existuje celkem 34 takovýchto perkusí a je velmi obtížné, aby dva lidé měli stejné pořadí. Když máte tým, každý člověk funguje a přemýšlí trochu jinak, má rád úkoly jiného charakteru. Proto, když pracuji s lidmi, snažím se nejdřív definovat jádro pracovní pozice.

Například jsme historicky měli člověka, který se staral o systém sbírající data ve velmi vysokém rozlišení, například 50 vzorků za vteřinu. Tento systém, který se jmenuje VAMS, byl spravován člověkem velmi orientovaným na výkon a výkonovou efektivitu. Prošli jsme spolu testem silných stránek a došli jsme k závěru, že ačkoliv je on orientovaný na výkon, téma VAMS je spíše strategické a analytické s dlouhodobým horizontem.

V rámci diskuze, za podpory managementu, jsme vytvořili novou pozici, která má více programátorský charakter. Tento člověk se tak posunul profesně z oblasti energetiky (kde začal) do oblasti programování, navíc si studuje bakalářské studium na FITu a chtěl by se stát programátorem. Díky tomu, že jsem s lidmi vedl individuální rozhovory, jsem mohl přispět k nasměrování tohoto člověka do nové oblasti. Takovéto příběhy se nám často ukazují.

Takže z nestrategického energetika se stal výkonný programátor? Ano, přesně tak. To je jeden z příkladů, ale takových je víc. Každý den člověk nějakým způsobem profesně roste a vyvíjí se. Já se s těmito lidmi snažím pracovat, například za mnou chodí kolegové, a společně řešíme, kde se sami vidí. Bavíme se o tom: „Jsi analytický typ, máš silnou stránku jeden na jednoho, jsi dobrý v analytických návrzích jako UML nebo BPM, teď jsi na této pozici – jak to vidíš? Kde se vidíš? Jaká je tvoje pracovní náplň?“

S tímto přístupem se dá skvěle pracovat a pokud je člověk otevřený vlastní reflexi, je úžasné, jak se dokáže posunout. Pro mě jako vedoucího je to jedna z nejvíc naplňujících věcí, jaké tato práce přináší, a proto jsem v tom rád.

Pokud chceš, můžu ti pomoci také s dalšími částmi textu.

Opravený text:

Om týmu dál. Mně se líbí, že psychometrie je vždy jenom model, ale může to být nová sada dat, která vám pomůže lépe řídit celý tým a jeho dynamiku. Každopádně, Přemku, moc ti děkujeme za tento velký deep dive do světa energetiky a přenosové soustavy a držíme palce, ať najdeš ty správné lidi se správnými hard skills i psychometrickým strength profilem. Těšíme se na příště, co zase vymyslíte v ČEPSu. Vůbec jsem netušil, jak fascinující je tato organizace a za co všechno vám můžeme být vděční. Děkuji moc za pozvání. Hodně štěstí.

Děkujeme, že jste doposlouchali až sem, a díky také našim partnerům, členům Data Talk klubu. Těmi jsou: Intex, Saska, Bystreet, Colors of Data, Revolt BI, Good Data, Kebula, Emark, Carl Data Company, Data Mind, Notino a Flo.

A pokud chcete zůstat v obraze, co se týče české datové scény i globálních datových technologií, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz. Nechť vás provází data.