Janitza.cz

Janitza Electronics se zabývá vývojem a výrobou energeticky úsporných systémů. Je výrobcem digitálních měřidel, systémů SEMS, univerzálních multimetrů, regulátorů jalového výkonu, systémů pro řízení spotřeby, ¼ hodinového maxima a dalších přístrojů nejvyšší kvality.

KBH.cz

Společnost KBH vyrábí, dodává a instaluje komponenty pro kompenzaci jalového výkonu. Zákazníky jsou elektromontážní firmy, výrobci rozvaděčů, projektanti, velkoobchody a velkoodběratelé elektrické energie. Společnost nabízí kvalitní komponenty a služby za velice příznivé ceny.

5. září 2008, Autor: varner
Nezařazené články

Kontinuální změna energetiky a její důsledky při integraci IT aplikací

Moderní utilitní společnosti v regionu střední a východní Evropy procházejí v poslední dekádě permanentní změnou, na kterou musí jejich management ve snaze o dosažení co nejlepších ekonomických výsledků neustále reagovat.

Samotný proces privatizace, ve kterém mnozí viděli spásu domácích utilitních společností, období změn odstartoval. V této etapě se zejména na energetickém a plynárenském trhu nejprve oddělovaly jednotlivé divize monopolních společností, aby pak následně docházelo ke vznikům holdingových struktur a nakonec ke vzniku nových subjektů na trhu.
Paralelně pak byl odstartován proces liberalizace, kdy mezi starými i novými subjekty byly vytvořeny a ustaveny nové vazby i procesy. V této etapě tak postupně nabývaly na významu subjekty regulátorů a operátorů domácích trhů s energií. Vznikly obchodní společnosti, na významu nabíraly zahraniční obchody na importní i exportní bilanční straně, kde proces predikce spotřeby a následného vyrovnávání odchylek tak byl povýšen téměř na umění.

Permanentní změna
Pověstnou poslední kapkou, s kterou se utilitní společnosti musely během posledních let vyrovnávat, pak nepochybně byla globalizace. Toto období s sebou spolu s téměř démonizací ekonomických výsledků společností přineslo do utilit dobré i zlé. Jednou z pozitivních výzev pro stávající managementy byla a je možnost nabídky nových produktů, nebo též leckde zvažovaná možnost slučování podobných podnikání do multiutilitních společností, případně dnes již běžné obchodování na zahraničních burzách. Ne vždy však všudypřítomný tlak na změnu proběhl zdárně – čehož jsme byli svědky v přímém přenosu nezvládnutých změn v podobě zkreslování ekonomických výsledků a následnému krachu Enronu a dalších společností.

Důsledky změn
V tomto turbulentním prostředí tak byl (a stále je) ovlivňován každý subjekt energetického, či oběcněji utilitního trhu. Přitom nelze jasně říci, kdy a kde se probíhající změny ustálí (a teď naprosto nemám na mysli přístup energetických legislativců). Charakteristický tak je stav, kdy výrobci, distributoři i obchodníci musí měnit či přizpůsobovat svoji strategii, své podnikatelksé cíle, či procesní model organizace, ale i podnikovou kulturu či skladbu zaměstnanců. Bez ohledu na zvolenou strategiii či podnikatelské cíle má však kontinuální změna energetiky pod taktovkou všudypřítomných ekonomických tlaků ještě jeden důsledek: neustálé přizpůsobování IT systémů, bez nichž již dnes žádná utilitka nemůže fungovat, natož pak přežít. A nároky na IT skutku nejsou nízké. Šéfové IT by to shrnuli jasně a pregnantně: musí se rychle přizpůsobit požadovaným změnám, musí být flexibilní, a přitom musí vystačit s omezenými lidskými i finančními zdroji, které CIO mají.
Co s tím? Je to vskutku téměř neřešitelná situace, jak vypadá? Nikoliv! Řešením je maximálně robustní využití velkých programových nástrojů (jako jsou SAP, Oracle či Microsoft) a doplnění zbývající či nově požadované funkčnosti samostatným systémem, který do celkového řešení bude zaintegrován.

Jaké systémy dnes utility běžně používají
Podpora procesů v prostředí utilitní společnosti je v praxi obvykle realizována následujícími informačními systémy:
• FIS - finanční informační systém tvořící jádro IS z pohledu finačního řízení společnosti. Zde se uplatňují balíky ERP (SAP, Oracle eBusiness Suite ad.).
• ZIS - zákaznický informační systém, tvořící jádro pro poskytování služeb související s dodávkou médií, odečty, fakturací a styku se zákazníkem. V této oblasti se uplatňují specializované aplikace nebo nejrůznější odvětvová řešení jako např.mySAP.com Utilities, SGC Soluziona ad.
• PTIS - provozně-technický infromační systém, který podporuje činnosti v oblasti správy a rozvoje distribuční sítě. Je často úzce integrován s GIS.
• GIS -grafický infromační systém
• SCADA systémy - nástroje pro řízení distribuční sítě v reálném čase
• ostatní IS - jako jsou např.CRM -customer relationship management systémy, TRM - trade and risk management systémy - systémy pro obchodování s energií
Lze konstatovat, že ani jeden z dnes dostupných produktů na trhu nepokrývá požadavky na funkcionalitu v celém rozsahu.
Z výše uvedených skutečností vyplývá, že podpora procesů utilitní společnosti z IT bývá v praxi realizována několika/mnoha IS, které však musí spolu velmi úzce komunikovat.

Jak integrační projekt souvisí s optimalizací interních procesů
Ideální situací je podpora všech procesů jedním IS. Z výše uvedeného kratičkého rozboru je však zřejmé, že celé informační prostředí z hlediska počtu systémů, použitých technologií a rozdílné filozofii je značně nehomogenní. V takto nehomogenním prostředí roste potřeba po efektivním přístupu k řešení problematiky integrace IS.
Vzhledem k otvírajícímu se trhu v oblasti utilit v celé EU a privatizačnímu procesu ve střední a východní Evropě často dochází k přehodnocení požadavků zejména v oblasti ZIS, což vede k postupné obměně nebo úpravám těchto systémů. V důsledku je to další tlak na flexibilitu v oblasti integrace se stávajícími IS.

Integrace z technického pohledu
Integrací se myslí úzké propojení dvou a více systémů, a to často nejenom na datové, ale také funkční úrovni. Pokud se jedná o jednoduchou replikaci dat, řešení bývají stejně jednoduchá jako problém samotný, provádí se dávkový export a import, při větších objemech dat v noci nebo o víkendu. Mnohem komplikovanější už jsou replikace online, ještě komplikovanější pak složitější toky dat, kterých se účastní další systémy, v nejhorším případě pak i uživatelé sami svými vstupy.

Datová replikace
Datové replikace vyplývají z požadavků na synchronizaci kmenových dat jako jsou číselníky zaměstnanců, odběratelů a dodavatelů, jejich adres apod. Typickým příkladem této potřeby může být změna v evidenci zaměstnanců, kdy už není možné používat rodné číslo jako identifikátor (kvůli ochraně osobních dat) a je nutné generovat unikátní klíč jinak – a tento pak přenášet do ostatních systémů. Velmi často se tento požadavek objevuje po nebo (v lepším případě) během zavádění CRM systému. Velmi často je také celý rozsah problému podceněn.
Z technického pohledu je řešení poměrně jednoduché. Jelikož se tyto data nacházejí v databázích typu ORACLE, SQL server, Informix, v některých případech i FoxPro nebo dBase apod, každý z těchto systémů umožňuje data v rozumné struktuře exportovat a importovat. Ideálně ve formě flat-file struktury, kdy je každý záznam reprezentován jedním řádkem, pole jsou odděleny tabelátory, znakem pipe nebo jiným vhodným způsobem, případně jsou pevné délky. Samotná manipulace s nimi pak probíhá až v databázi, kam jsou nahrána nějakým standardním importním programem.
U datové replikace se nepředpokládá komplikovanější manipulace s daty ani procesní logika a je vhodnější ji řešit dávkově (ať už inkrementálně nebo celý objem dat).
Online replikace jsou mnohem náročnější a spadají spíše do oblasti jednoduché integrace.

Jednoduchá integrace (point-to-point)
Jednoduchou integrací by šlo nazvat online propojení dvou systémů, kdy alespoň jeden je aktivní, tj. vznikají v něm požadavky propojení – exporty dat do druhého systému nebo požadavky na data z druhého systému. V tomto případě se už neobejdeme bez fyzického online propojení mezi těmito systémy a záleží na jejich technologických možnostech. V ideálním případě, kdy je technologická platforma homogenní, tedy např. ORACLE-ORACLE nebo SQL Server – SQL Server, je možné si vystačit s prostředky těchto systémů (databázové linky, triggery, ODBC napojení apod.). Naprostou většinou je nutné modifikovat systém, který je aktivní, a to ve smyslu změny „druhé vrstvy“, tj. logiky v obsluze databáze. Netýká se to většinou front-endu, tedy uživatelského rozhraní, toto je možné ponechat beze změn. V případě potřeby je nutné celý proces změn dohodnout s dodavatelem aplikace.
Pro heterogenní systémy je online přenos komplikovanější a je nutné si vypomoci další technologií, buď jednoduchým systémem, který v podstatě simuluje middleware, nebo samotným middlewarem. Tyto systémy jsou pak kontaktovány z prostředí aplikace nebo si samy zjišťují příslušné změny a provádí přenos dat.
Další komplikace mohou nastat v případě požadavků na modifikaci dat (změna typu dat, spojení nebo rozdělení, logická operace nad daty) nebo online přístupu do druhého systému (např. doplnění ID zákazníka do právě vytvářených dat). Tyto problémy je možné do jisté míry řešit databázovými prostředky, pak ale nejsou rozhraní tak standardní, jak by měla být, navíc je problém s definicí datové struktury, která by měla být předávána mezi systémy. Řešení jsou různá, od proprietárních prostředků middleware řešení (Integrator pro TUXEDO) až po dneska velmi preferovanou strukturu XML a s ní spojené XSLT převody.
Samostatným problémem je synchronní a asynchronní přenos dat.
Pro synchronní platí, že systém čeká na odpověď vzdáleného systému a po tuto dobu je jeho činnost blokována. V nejhorším případě, když je vzdálený systém nedostupný, není provozuschopný. Asynchronní přenos je často prakticky stejně rychlý (z hlediska uživatele) a není náchylný k blokaci primárního systému. Tento způsob je většinou preferován, kromě případů, kdy vznikají požadavky na data v primárním systému, zde je jednodušší, často kvůli logice aplikace, spoléhat na synchronní přenos. Je nutné pečlivě zvážit, kterému způsobu se dá přednost a proč.
Každopádně, a to platí i v dalším případě, je nutné koncipovat vstupní a výstupní rozhraní systému (ať už nativní – tj. např. PL/SQL v případě ORACLE databáze – nebo jiné) jako otevřené a standardní. Každé z API by mělo být možné zavolat i z jiné technologické platformy a mělo by být svým způsobem standardizované (např. každé API obsahuje návratový kód a případně text chyby, vstupuje pak ID požadavku).
Dalším jakýmsi stupněm integrace je pak integrace několika systémů, což je nastíněno v dalším odstavci.

Integrace více systémů
Zde se těžko obejít bez technologické platformy a určité standardizace. Zcela určitě bude nutné provádět převody dat, velmi často je požadavek na logické operace nad těmito daty, jednoho toku dat se může účastnit i více systémů, některé požadavky budou synchronní, některé asynchronní, operace je nutné logovat, limitujícím faktorem může být i výkonnost systému.
V zásadě je nutné dodržet všechny praktické postupy jako v předchozím případě:
• unifikovat API systémů (pokud je to možné)
• unifikovat a standardizovat rozhraní adaptérů vůči integrační platformě, např. XML rozhraním přes http komunikaci
• zvolit datovou strukturu pro přenos (často XML)
• zvolit vhodnou technologickou platformu
• u všeho dodržet zásadu „Keep it simple“, tj. nekomplikovat už tak složitý systém.

Unifikace API znamená, že se systém mnohem jednodušeji spravuje – jestliže každé API používá stejný způsob předávání chyby, je možné ji pak jednotně zpracovat v rámci integrační platformy. Jestliže existuje jednotný způsob předávání dat mezi adaptéry a platformou, je možné některé vrstvy adaptérů použít vícekrát (samozřejmě, stále se budou lišit v oblasti samotného napojení podle aplikace). Vhodné je také zvolit stejnou technologii (pro méně náročné přenosy dat Java, při velkých požadavcích na výkonnost pak C, C++). Datová struktura by měla být velmi flexibilní, umožňovat manipulaci s daty a změnu vlastní struktury. Při použití flat-file vzniká problém s předáváním strukturovanějších dat, jako např. faktury, která má hlavičku a řádky. Některá řešení, jako např. IDoc SAPu, toto umožňují, manipulace s takovou strukturou je ale velmi náročná.
Samozřejmě, nejvděčnějším tématem je samotná integrační platforma. Existují různé přístupy, v poslední době se prosazují řešení na bázi J2EE (Weblogic, 9iAS), tedy Java, pro řešení náročná na výkonnost jsou stále nepřekonatelné systémy založené na C++ a nativním kódu (Tuxedo, MQ Series). Jejich rychlost je samozřejmě vykoupena mnohem menší flexibilitou z hlediska programování. V tomto je Java výborným kompromisem mezi rychlostí a flexibilitou, náročností na tvorbu. Svébytným systémem je pak BizTalk a .NET, který jde trochu jinou cestou a měl by pokrývat rozsahem středně náročná integrační řešení.
Logické procesy a převody dat jsou často součástí integračních platforem, a jsou také často nutné. Pro převody dat je možné použít nějakou vlastní komponentu, hlavně v případě XSLT, kdy jsou šablony uloženy v souborech, ale procesní logika je velmi náročná na implementaci a tvorba vlastního řešení je téměř stejně náročná jako integrace samotná. Proto je vhodné v případě požadavku na složité procesní toky prověřit možnosti platformy a přizpůsobit se jejím možnostem.
Jako nástavba pak bývá součástí platforem webový portál, kde je možné doplnit procesní logiku interakcí s uživateli a výstupy, pro správu systému existuje administrační konzole celého systému.
Poslední, snad nejdůležitější bod je udržet všechno co nejjednodušší. Samotná integrace je velmi složitá z hlediska návrhu procesů, řízení a řešení vztahů s dodavateli systémů a vlastní implementace by ji neměla dále komplikovat. Zvládnout správně poměr mezi flexibilitou a složitostí samotného jádra integrace je jedním z klíčových faktorů úspěchu a není dobré jej podceňovat.

Závěrem
Manažeři utilitních firem se dnes více než jejich kolegové musí dnes a denně ptát – co musí udělat k udržení společnosti na trhu? Co mají udělat k zajištění větší konkurenceschopnosti? Co musí udělat pro udržení růstu společnosti a tím i ke spokojenosti investorů, ať již státních či privátních? K těmto rozhodnutím potřebují dnes a denně spolehlivé a včasné informace nezbytné pro rozhodování o dalším směrování společnosti.
Integrace IT aplikací je z tohoto úhlu pohledu nezbytná, pokud má IT dobře plnit jednu ze svých základních rolí – dobře informovat management společnosti o jednotlivých klíčových parametrech, a dodávat tak informace včas, v požadované kvalitě a v požadované struktuře.

Kolektiv konzultantů utilit NESS CEE

Sdílet

Komentáře

Najdete nás na Facebooku
Odběr novinek
Server CESKAENERGETIKA.cz
Česká Energetika s.r.o. a Česká energetická asociace provozují portál www.ceskaenergetika.cz, vydávají dva časopiy z oblasti energetiky a OZE, pořádají na tato témata semináře a konference pro laickou i odbornou veřejnost.
Důležité odkazy
Spolupracujeme
Najdete nás také na
Portál www.ceskaenergetika.cz © 2011 pohání redakční systém MultiCMS. Grafické zpracování Cossi Design.