Bevezetés

Gazdaságinformatikus gyökerekkel rendelkezem, úgyhogy engem mindig érdekelt a projektek pénzügyi oldala is. Szeretem mindig azonosítani, hogy mi milyen költségekkel járhat és az hogyan tud megtérülni. Egy termelő vállalatnál sincs ez másképp, ott is tudni akarják a menedzserek, vezetők, hogy milyen veszteséges működés rejlik a folyamatok mélyén. Ezt csak akkor tudjuk azonosítani, ha célirányosan adatokat kezdünk el gyűjteni, majd ezeket az adatokat értelmezzük, levonjuk a következtetéseket és döntést hozunk a működésre vonatkozóan. Azt gondolom - saját tapasztalataimból kiindulva -, hogy ha az iménti folyamat szükségességét belátja egy vállalati- vagy egy termelésvezető, az már fél siker.

Az általam bemutatott esettanulmányban szerencsére az adatgyűjtő és -megjelenítő keretrendszert már kiépítettük. Láthatóak voltak az villamosenergia fogyasztásból adódó veszteségek éves / havi / napi / műszak / 10 perces (ez a legkisebb) intervallumban, de még csak kWh mértékben meghatározva. Ahogy azt már korábban említettem, egy nem feltétlenül hozzáértő (nem villamosmérnök vagy szakember) nem tudja elhelyezni a világában, hogy adott esetben 10-100-1000 kWh veszteség mit is jelent a vállalat számára pénzben.

Az üzleti intelligencia rendszerek képesek a múltbéli és a jelenlegi adatokból információt kinyerni. Az általuk használt modern technológiák is egyre pontosabb előrejelzéseket tesznek lehetővé. Így könnyebben hozhatók stratégiailag pontosabb döntések. Az iménti ábrán például olyan adatok láthatók egy üzleti intelligencia rendszerben, amely több termelő gép (vízszintes tengely) adott hónapra vonatkozó hasznos (világoszöld) és haszontalan (piros) energiafogyasztásait mutatja. Mindezeket kibővítve a támogató berendezés hasznos és haszontalan energiafogyasztásával, mivel néha ezek is jelentős többletet jelentenek a fogyasztások felmérésénél. Így a villamosenergia fogyasztással összefüggő veszteségek döntő része könnyen azonosítható már.

Hogyan tudnánk csökkenteni anélkül a veszteségeket, ha még mi magunk sem ismerjük a pontos számokat azt illetően, hogy mennyi volt az ára a haszontalan működésünknek? Egy konferencián azt a tanácsot kaptam, hogy mutassam ki, mennyi is ez a veszteség, és a számok minél inkább fájdalmasak ("fájjon!"), annál inkább sarkallhatja a vezetőket arra, hogy beruházzanak azért, hogy a veszteségek csökkenthetők legyenek.

Célkitűzés

A veszteségek összesítése során és a hónap végi jelentések közlése után a vállalat dolgozói joggal mondhatják azt, hogy nehéz értelmezni, hogy mennyi is volt igazából a veszteség az azonosított pazarló működések miatt. Ezért is határoztam meg egy olyan célt, hogy mutassuk ki a konkrét - haszontalan működéshez kapcsolódó - költségeket a működés során.

Követelményleírás, specifikáció

A követelményleírás és specifikáció készítése során számba vettem, hogy milyen adatokat ismerünk, mik voltak adottak:

1. Villamosenergia fogyasztási adatok termelő gépekre és támogató berendezésekre lebontva 10 perces mérési intervallumokkal
2. Termelési adatok: milyen termékből, melyik termelő gép, mikor, mennyit (darabszám vagy négyzetméter) termelt.
3. Az előző két adatsor összekapcsolását már megvalósítottuk a termelő gépazonosító és a (kerekített) időbélyegek által. Így tudható volt, hogy adott mennyiség legyártásához mennyi villamosenergia fogyasztás tartozott.
   

A cél eléréséhez olyan peremfeltételeket térképeztem fel, amely arra ösztönzött, hogy inkább egy egyedi webes alkalmazásfejlesztéssel valósítsuk meg ezt a projektet, mintsem egy üzleti intelligencia rendszer segítségével (de nem állítom, hogy azzal nem lenne megvalósítható). Ezek a peremfeltételek a következők voltak:

1. Bár az energiaárak az egyszerű lakossági fogyasztók számára is jól látható módon váltakoznak (nőnek) hónapról-hónapra (manapság már inkább napról-napra), nekünk ezt a kihívást kezelnünk kell. A villamosenergia szolgáltató biztosít egy olyan táblázatot, amelyben összesíti a termelő vállalat számára, hogy az hónapon és napon belül az adott órában mennyi volt a villamosenergia ára, amelyért értékesítette (felszámolta) a cég számára a MWh (nem kilo!) mennyiség árát.
• A kimutatásról azt érdemes tudni, hogy ez egy Excel táblázat, amelynek adott lapján, adott celláiban helyezkednek el a villamosenergia fogyasztás értékesítési árai Euróban.
• A mérési gyakoriság (intenzitás) tehát a villamosenergia fogyasztásnál 10 perces, míg az Excel táblázatban 60 perces az időköz. Itt tehát egy standardizálásra van szükség.
  
• Megjegyzések:
  
• Mivel ez csak egy Excel táblázat, ha a későbbiekben megváltoztatja a villamosenergia szolgáltató a szerkezetét, akkor a mi alkalmazásunk könnyen "eltörhet", így az utánkövetést folyamatosan felügyelni és ellenőrizni kell.
• Kutatásainkhoz ez az összesítő táblázat egyfajta ellenőrzésként is szolgált, hiszen a gépeknél és berendezéseknél kihelyezett fogyasztásmérő szenzorok nem hatóságilag hitelesített mérőeszközök, a villamos főmérő viszont az. Úgyhogy ennek a méréseit felhasználva, képesek vagyunk felmérni, hogy milyen szinten áll a vállalat főbb fogyasztóinak és azok fogyasztásainak az azonosítása. Tehát, hogy mennyire vagyunk előrehaladott állapotban ezen a területen (ehhez lásd majd az utolsó példát a bejegyzés végén). Ugye ez az ISO 50001-es szabvány betartása és a tanúsítvány megítélése során is fontos mérőszám.
  
2. Az előző felsorolásban említettem, hogy a fogyasztási árak Euróban érkeztek a villamosenergia szolgáltatótól. Az energiaárak mellett pedig talán a HUF-EUR árfolyam, amely a legkevésbé tekinthető stabilnak és kiszámíthatónak. Így az a lehetőség nem volt megfelelő, hogy próbáljunk meg "kitűzni" egy olyan átváltási árat, amely nagyjából fixnek tekinthető az adott időszakra vonatkozóan. Szerencsére létezik olyan webszolgáltatás, amely a Magyar Nemzeti Bank (MNB) hivatalos valuta- és devizaárfolyamait szolgáltatja és az adatok egy dátum- és pénznemszűrés után publikusan elérhetőek a dátumokhoz tartozó átváltási számok.
   

Megvalósítás: háttér (backend)

A háttér megvalósítása során az adatintegráció volt talán a legnehezebb feladat. Hiszen négy heterogén forrás adatait kellett egységesen kezelni (beolvasni, hozzáférni - az első két pont esetén - lásd alább; feltölteni, eltárolni, kiolvasni - a második két pont esetén):

1. A termelési adatok, mivel egy fix vállalatirányítási rendszer (dobozos termék) alatt tárolódtak, ezért ennél fixen egy Microsoft SQL Server-hez kellett kapcsolódni és a vállalatirányítási rendszer adattárolási struktúráját megismerve, kinyerni a számunkra releváns adatokat (mikor, miből, mennyit, mivel gyártottak). (Microsoft SQL Server-hez a Laravel-es adatkapcsolat létrehozását ebben a blogbejegyzésben részleteztem)
2. Energiafogyasztási adatokat teljes mértékben mi felügyeltük, így az annál alkalmazott adatszerkezet és az adatok jellegzetességeivel, tulajdonságaival tökéletesen tisztában voltunk.
3. A villamosenergia szolgáltatótól érkező havi kimutatást (Excel fájlt) először értelmezni kellett, hogy azonosítsuk, melyik lapokra és cellákra van szükségünk a kalkulációkhoz. Mindehhez a webalkalmazásban egy fájlfeltöltő és értelmező felületre volt szükség. Itt említem meg, hogy természetesen a különböző funkcionalitások eléréséhez más-más jogosultsági szintű felhasználó szükségeltetik (például a fájlfeltöltéshez csak egy arra jogosult felhasználó férhet hozzá, míg mondjuk a későbbi eredményeket egy adatelemzési jogkörrel rendelkező felhasználó tudja böngészni). A fájlfeltöltés megkezdésekor ellenőrizni (validálni) kellett, hogy a feltölteni kívánt fájl szerkezete megfelel-e elvárásainknak, hogy ne kezdjen el az alkalmazás olyan fájlt feldolgozni, ami nem felel meg a követelményeknek (szerkezeteknek). Ha minden megfelelő volt, akkor következhetett az adatok beolvasása és eltárolása, amit havonta egyszer kell elvégezni.
4. A HUF-EUR árfolyamnál egy webszolgáltatást használtunk adatforrásként, amely az MNB hivatalos napi középárfolyamait mutatja. (Nyilván ez nem a legpontosabb, hiszen attól függően nagyban eltérhetnek, hogy a vállalat milyen kereskedelmi banknál vezet számlát és annál milyen árfolyamok vannak.)

A kommunikációt a backend-frontend között egy saját API szolgáltatáson és végpontokon keresztül valósítottuk meg, így a felhasználók kéréseit a lehető leggyorsabban szolgáltuk ki a weboldal teljes újratöltődése nélkül. Emiatt a frontend részen is komoly fejlesztéseket kellett végrehajtani, főleg a diagramok és azok szűrői kapcsán.

Megvalósítás: felhasználói felület (frontend)

Az alkalmazás kinézetét egy ingyenesen alkalmazható, reszponzív (mobile first) sablon biztosította, amely kiválóan alkalmas olyan alkalmazásokhoz, ahol az adminisztrációs felületen van a fő hangsúly.

A diagramokat (alább látható példák) a chart.js osztálykönyvtár segítségével valósítottuk meg. Ezzel az eszközkészlettel olyan sokféle diagramtípus áll a rendelkezésünkre, amellyel gyakorlatilag az üzleti intelligencia rendszerek adatmegjelenítési része tökéletesen helyettesíthető. Persze ez akkor a leghatékonyabb, ha kiegészítjük mindenféle szűrési lehetőséggel, például a mi esetünkben: dátumszűrő, gép (vagy berendezés) szűrő. A szűrések érvényre juttatásához a backend részen elérhető API végpontokat szólítjuk meg, és így a diagramoknak csak az adathalmazát frissítjük.

Az elkészült alkalmazás telepítése a felhőbe

Mindezt a folyamat végén publikáltam a Microsoft Azure felhőjébe, így bárhonnan elérhető az alkalmazás. A Laravel projekt felhőbeli telepítéséhez korábbi tapasztalataim nyújtottak segítséget, amelyeket itt gyűjtöttem össze:

• Alkalmazás adatainak felhőbeli tárolása és hozzáférése
• Alkalmazás telepítése a felhőbe
• Felhőbeli alkalmazás tesztelése, frissítése
  

Maga az alkalmazás ezen a webcímen érhető el: https://electricity-consumption.azurewebsites.net/ (mivel felhőszolgáltatás, ezért nem fut az összes alatta lévő erőforrás, csak akkor, ha kérés érkezik, ezért előfordulhat, hogy újra le kell kérni az oldalt, mert 404-es hibakódot kaphatunk) azonban az adatok titkossága miatt minden funkcionalitáshoz olyan jogosultságot rendeltünk, ami bejelentkezés és azonosítás nélkül nem elérhető.

A kész alkalmazás diagramjai és szűrői (példák)

Itt látható néhány képernyőkép a webes alkalmazásról (a példaként szolgáló adatok egy hónapot fednek le, 2020. májusát):

Egy kiválasztott termelő gép működésének költségei adott hónapban órás bontásban:

Mindezekből a veszteséges működés ennyibe került ennél a kiválasztott termelő gépnél (látható, hogy jó veszteségesen működött az összes költséghez képest):

A szenzoros mérések ellenőrzése (saját szenzoradatok összegzése VS. hitelesített mérőműszer mérése)

Néhány szűrő (berendezés, berendezés típus, dátum intervallum), amit használtunk a diagramok adatainak frissítéséhez:

A diagramokon látható adatok csak tájékoztató jellegűek.

Együttműködés, köszönetnyilvánítás

A kutatást természetesen nem egyedül végeztem. Munkám során a vállalat szakembereivel mindig együttműködve haladtam a megoldás felé, míg kutatási szempontból Koncz Adrienn doktorandusz hallgatómmal, továbbá szakmai, fejlesztési oldalon ennél projektnél az Eötvös Loránd Tudományegyetemen (ELTE-n) hallgatómmal, Németh Erikkel együttesen tevékenykedtem.