… nagyjából a kétezres évek közepén napjaim jelentős részét töltöttem egy ma is meghatározó CAD szoftver előtt rajzolgatással, tervezéssel. Boldog “békeidők”. Egy-egy új célszoftver beszerzése ekkoriban még a legtöbb - főleg KKV szektorba pozícionált - tervező/alkotóműhely esetében a DC++ valamely underground HUB-járól, vagy egy “fizetős” FTP-ről történő kalóz/tört verzió letöltését jelentette és bár minden cégnél akadt általában legalább egy “eredeti”, jogtiszta verzió, ennek célja azonban elsősorban az ekkortájt idehaza igen aktívan (bár sok tekintetben vitathatóan) tevékenykedő BSA lerázása volt.
Ma, az OEM szoftverek, a hatalmas mennyiségű nyílt forráskódú és szabadon, ingyenesen hozzáférhető alkalmazás és a még szélesebb körben, online elérhető integrált szolgáltatások korában már talán magyarázatra szorul, miért volt ez így: egyrészről a ‘80-‘90 évek hagyatékaként a köztudatban még ekkor is sokan úgy gondoltak a szoftverekre, mint valami megfoghatatlan, nem tárgyiasított, materializált dologra, s ezzel annak “illegális” használatát (az eltulajdonítás a másolás miatt már végképp nem volt értelmezhető) nem is igazán realizálták. A (munka)eszköznek a számítógépet tekintették, megvették, és ezzel az informatikai beruházás ki volt pipálva.
További fontos tényező volt a szoftverek ára. Egy, a bevezetőben említett studio szoftver (ne felejtsük, hogy ekkor még a később bevezetett butított, csökkentett funkcionalitású és így olcsóbb ún. “light”, “LT” vagy “Essentials” verziók csak korlátozottan voltak elérhetőek) költsége egy kisebb szakipari vállalkozás akár fél éves adózott eredményével volt összemérhető. Ördögi kör volt ez, mert valós szankciók és közbelépések elvétve következtek be (akkor viszont jó nagy port vert körülöttük a média), így pedig, aki nem állt be ebbe a sorba, az - mivel a szoftvereinek költségét kénytelen volt beépíteni az áraiba - jelentős hátrányból indult egy-egy tender elnyerésében.
Az iménti kis időutazásra azért invitáltam az olvasót, hogy megértsük, relatív rövid időtávban milyen messziről indultunk nemhogy a tudatosan licencelt szoftverek tekintetében, de úgy általában a legálisan használt szoftverbázis fenntartásában is.
A témánk felvezetéséhez szeretnék elmesélni egy másik történetet is: 2008-ban járunk, az akkori munkahelyem sok más egyéb között különböző objektumokban (privát és egyéb ingatlanok, stb.) telepített elektronikus vagyonvédelmi rendszerek távfelügyeletével is hosszú ideje foglalkozott, s ezen üzletágát adta el éppen egy Magyarországon akkor már jelentős szereplőként jelen lévő multinacionális vállalatnak. Az eladás során az ügyfelek részben olyan új technikai eszközöket (kommunikációs modulokat) is kaptak ingyen, melynek akkor az én szerény mércémmel mérve jelentős vagyoni értéke volt. Ma már tudom, naivitás, de egy alkalommal, amikor a beépítendő eszközöket vettem át a fogadó cég képviselőjétől megkérdeztem, miért éri meg ez nekik. A nálam egyébként jóval idősebb kolléga rám mosolygott és annyit mondott: “Ennek itt nincs jelentősége. Ezer ilyen áll még a raktárban, nekünk egy a fontos, hogy az ügyfél nálunk legyen és maradjon. Nem az egyszeri eladásban van a pénz, hanem a szolgáltatásban, az ügyfélkör és rajtuk keresztül a cég nettó értékének növekedésében.”
Bár ma ez már mindenkinek evidens, akkoriban sokkal kevésbé volt az, különösen ha a szoftvereket, mint szolgáltatásokat tekintjük.
Nem sokkal ezután, de már a 2010-es évek elején mélységes felháborodással olvastam a bejelentést, miszerint a tervezőszoftver, mellyel majd’ tíz éve dolgozom kivezeti az ún. perpetual (azaz “örökös”) licencet, és helyette csak fix terminusokra, bérleti konstrukcióban lehet majd használni. Idő és hely hiánya miatt nem mennék bele további részletekbe, de újabb két év és a Google Cloud kellett ahhoz, hogy belássam és rádöbbenjek:
a szoftverek tekintetében (is) a szolgáltatásban és a bérleti konstrukcióban van a jövő.
Egy egészséges üzleti kapcsolatban a partnerek nemcsak önmaguk, hanem egymás részére is keresik és hajszolják a minél teljesebb Win-Win megoldásokat, felismerve, hogy egy ettől eltérő alapokon nyugvó együttműködés eleve kudarcra ítélt, hiszen a Lose “komponenseket” elszenvedő fél vagy felek állandó elégedetlenség érzése mellett fognak folyamatosan kiutat keresni ebből, a közös utat (vagy sales ciklust) így egy vagy több pontszerű értékesítésre determinálva.
A jövőálló modellben az ügyfél folyamatosan azt keresi, és azt kapja, amire szüksége van, a szolgáltató pedig ezzel párhuzamosan igyekszik ugyanezt szolgáltatni, felmérni és előre kitalálni, mit kér(het)nek majd holnap. Erre persze a legtöbben rávágnánk, hogy evidens, mégis, privát és szakmai életben is keserű tapasztalat, hogy nagyon sok esetben sajnos egyik fél részéről sincs meg ez a fajta tudatos, felelős gondolkodás.
Sokszor hallom a fenti kijelentést, sőt, sokszor kommunikálom ezt kijelentésként magam is. Valóban, az ipar sok tekintetben jelentősen eltér a konzumer szektortól. Nem kivétel ez alól az informatika területe sem, ez azonban nem jelenti azt, hogy egy-egy paradigma szükségszerűen alkalmazhatatlan is az ICS (Industrial Control System - az ipari automatizálási rendszerek összessége) felett, csupán azt, hogy ésszerűen, az előnyeit kihasználva (átmentve) kell adaptívan átvenni azt.
Tíz évvel ezelőtt, ha bementem egy nagyobb multihoz azzal, hogy a rendszer, amit ajánlunk részben vagy egészben felhő alapú, akkor rövid ámde jelentőségteljes csendet követően diszkréten megnézték, van-e még kávé a csészémben, majd felajánlották, hogy szívesen kikísérnek a portáig, ha nem emlékeznék, merre jöttem be.
Mára a kis- és középvállalati szegmenstől egészen a multinacionális ipari vállalati szektorig aktívan fejlesztünk és értékesítünk részben vagy akár egészben cloud based megoldásokat, s míg korábban ez maximum egy-egy globális szolgáltató által kínált ügyviteli megoldás privilégiuma volt, mára már a MES, vagy alacsonyabb (direkt üzemi szintű, pl. SCADA) alkalmazás esetén sem tabu téma.
Érzésem szerint egy ugyanilyen utazás elején járunk ma a licencelés tekintetében is. A kulcskérdés az, hogy a gyártók/szolgáltatók milyen gyorsan képesek felismerni a szektor területre vetített sajátos igényeit, a felhasználók pedig képesek-e felismerni és kihasználni az “ortodox” hagyományoktól eltérő licenckezelésben rejlő előnyöket.
Az ICS, azon belül is a PLC (Programmable Logic Controller), a SCADA (Supervisory Control And Data Acquisition), a HMI (Human-Machine Interface) és a DCS (Distributed Control System) rendszerek az OT (Operational Technology) azon szegmensei, ahol az üzembiztonság és a rendelkezésre állás szélsőségesen (minden más aspektust prioritásban megelőzve) fontos. Kihozatal (hatékonyság), minőség (termék/szolgáltatás) és biztonság (élet- és vagyonvédelem). A saját tapasztalatom az, hogy nagyjából a sorrend is ez, amely persze régiónként és szektoronként eltérő lehet. A gazdaságosságot (pénzügyi szempontok) külön nem vettem fel, azt kezeljük amolyan konstansként, főleg mert a TCO (Total Cost of Ownership - azaz a pillanatnyi költséget a teljes életútra vetített költséggel szembeállító) szemlélet még mindig gyerekcipőben jár.
Mondhatnánk, hogy bármely egyéb területen is ugyanezt várjuk el (ami egyébként így is csak részben lenne igaz, hiszen egy asztali alkalmazás esetében a biztonság már egészen más értelmezéssel bír), azonban azok a tevékenységek, amelyek egy adott szoftver (által lefedett folyamat) ezen sarokpontokon belüli területen történő üzemeltetéséhez szükségesek már merőben eltérőek lehetnek.
Tegyük fel, hogy sok évvel ezelőtt egy komolyabb beruházás részeként megvettem egy tervezőszoftvert, amit kezdetben hatalmas megelégedéssel használtam, azonban az utóbbi időben egyre több a gond: más szakági kollégák is ugyanezen programot használják, de később vették mint én, így újabb verzióval dolgoznak, és bár van lehetőség kompatibilis mód használatára, ez azonban nehézkessé teszi a munkát: sokszor nem megfelelő formátumban kapom a dokumentumokat, így külön tortúra megnyitni őket. További probléma, hogy a legutóbbi, az operációs rendszerre érkező frissítés óta időről időre összeomlik, a nem mentett módosítások elvesznek, stb.
A válasz egy mondatban összefoglalva: az informatikai terület folyamatosan gyorsuló növekedése és fejlődése. Valószínűleg mindenki ismeri Gordon Moore nevét, aki még a hatvanas években az IC-kbe integrált tranzisztorok számának nagyjából másfél évenkénti duplázódását prognosztizálta. Kijelentéséből a legújabb kori informatika egyik alaptörvénye vált. Véleményem szerint dinamikájára nézve nagyon hasonló folyamat zajlik a szoftverek területén is, elsősorban azok összetettségét, egymástól történő függelmi viszonyát és ezekből adódóan kitettségüket tekintve.
Ma a redmondi mérnökök operációs rendszerének heti/havi rendszerességgel érkező kisebb biztonsági frissítéseinek mérete nagyobb, mint a kilencvenes évek közepén debütáló legendás OS teljes telepítőcsomagja. Az évenként érkező frissítés pedig összemérhető egy, az ezredfordulót követően a kereskedelmi forgalomban kapható nagyobb fizikai háttértár méretével.
Régen, ha megvettünk egy szoftvert, azt használtuk egy bizonyos célra, a munkánkat file-okba mentettük, lemezre, merevlemezre (ahol elérhető volt, lokális hálózaton keresztül központi tárhelyre) esetleg emailben továbbítottuk. Ma egy valamirevaló studio szoftver egy halom másik, az alkotói folyamatot különböző aspektusokból (projektmanagement, kollaboráció, felhő alapú adattárolás, központi adatbázisok, adatforrások, stb.) támogató másik szoftverrel tart kapcsolatot, melyek mind a saját életciklus modelljük szerint léteznek és fejlődnek, ez a fejlődés pedig hetekben, esetleg hónapokban mérhető, de aki ennél több ideig nem áll elő valami újjal, az már a kritikus mértékű lemaradást kockáztatja a konkurenciához képest. Fentiek megfontolása mellett magyarázat nélkül is egyértelmű, hogy egy gyártó szempontjából piacképes, felhasználó szempontjából naprakészen használható szoftver állandó karbantartást (ebben az esetben verziófrissítést és ehhez - adott esetben - támogatást) igényel. A Win-Win jegyében erre ad választ az előfizetéses rendszer: a korábbi élethosszig tartó licenc helyett ma egy adott terminusra fizetünk egy szoftver használatáért (majd igény szerint újabbra és újabbra), kevesebbet mint a perpetual licenc esetén, cserébe ezen időszak alatt folyamatosan “kapcsolatban állunk” a gyártóval, aki a terméket naprakészen tartja, illetve konstrukciótól függően különféle mértékű támogatást nyújt a használatához.
Ez a jelene a mai konzumer szektornak, és ez a jövője az ICS rendszereknek is.
Egyértelmű tehát, hogy az előfizetéses modellnek helye van az iparban is.
Tegyünk itt egy rövid kitérőt: jogi értelemben véve elvben elkülönül egymástól a Subscription based (azaz szabad fordításban “előfizetéses”) és a Term based (“időszakos”) licencelés, azonban ezek a különbségek egyrészt főként jogi természetűek, másrészt a tapasztalat az, hogy a gyártók ugyan ajánlják egyik vagy másik konstrukciót, általában ez alatt a kettő közötti hibrid megoldást értenek, azaz például egy Term based licencelési modellben használt szoftver esetén is legtöbbször elérhetőek az ingyenes szoftverkövetés vagy a terméktámogatás lehetőségei. Az egyszerűség kedvéért jelen írásban akár egyik, akár másik megnevezést használjuk, ha erre külön nem térünk ki, akkor az alatt az előfizetéses konstrukciót értjük.
Ahhoz, hogy a különféle gyártók versenyképes konstrukciót tudjanak biztosítani, nagyon fontos, hogy tisztán lássák azokat a sajátosságokat, amelyek az ICS rendszereket, azok üzemvitelének módját és életciklusát jellemzik, és amelyek miatt a már megszokott, kijárt megoldás itt egy az egyben nem, vagy legalábbis sikeresen nem alkalmazható.
Talán a leglényegesebb különbség az asztali és az ipari alkalmazások életútjában, hogy ellentétben az utóbbival, előbbinél a szoftver esetén az egyes állapotok (verziók, hibajavítások) nagyon szigorúan elhatárolva követik egymást. A “csak feldobok egy frissítést” megközelítésért az iparban szerződésbontás is járhat, az pedig még ma is szinte mindenütt kizártnak tekinthető, hogy az adott rendszer “kontrollálatlan” körülmények között, de legalábbis a végfelhasználótól kvázi függetlenül, automatikusan tölti le, és telepíti a legújabb frissítéseket és javító csomagokat. Egy-egy frissítést komoly, dokumentált felkészülés, kockázatelemzés előz meg, majd a telepítést követően több körben tesztelik, hogy minden az addig elvártaknak megfelelően működik-e. Ennek okait korábban már részletesen tárgyaltuk. Belátható, hogy az ezzel járó munka és esetleges termeléskiesés hatalmas költséggel jár, és - nem mellesleg - mindig kockázatos. Nem véletlen, hogy ezen a területen 3-4 évnél gyakrabban csak nagyon indokolt esetben frissítik a szoftverek verzióit és a Cyber Security jellegű kockázatokat (patchelés hiánya) is általában egyéb módon kontrollálják (pl.: hálózati céleszközzel történő izoláció, I/O interfészek kontrollált kezelése, részleges vagy teljes tiltása, stb.).
Ez persze nem azt jelenti, hogy az ICS kategóriába tartozó rendszerek esetén nem szoktuk a szoftvereket frissíteni, csupán azt, hogy szigorúan ellenőrzött keretek között telepítünk új verziót, a konzumer szektornál jóval ritkábban. Mindezek fényében a szoftverkövetés és a bérleti konstrukció pénzügyi fordulópontjait (azt az intervallumot, amely alatt az egyes terminusokra megfizetett bérleti díjak összege - az értelemszerű korrekciók (infláció, stb.) figyelembe vétele mellett - meghaladja a perpetual licenc beszerzésének költségeit.) ezt figyelembe véve kell meghatározni.
Minden olyan rendszer esetében - s így az ipari szektorban különösképpen - ahol a rendszerek, berendezések üzemideje állandónak tekinthető (7/24/365 vagy ehhez közeli) - kritikus, hogy legyen állandóan elérhető, naprakész támogatás. ICS területen azonban jellemzően kétféle végfelhasználó van: aki a rendszerét “fejlesztői” szempontból is átlátja, kezeli, karban tartja és - szükség esetén - javítja, illetve az, aki csak Black Box-nak tekinti, termel vele, de szakmai szempontból annak felügyeletét harmadik félként külső partnerre (elsősorban a rendszerintegrátorra) bízza. Tapasztalataim szerint még azon multinacionális vállalatok esetében is, akik megengedhetik maguknak, hogy kellő szakismerettel rendelkező üzemi mérnökö(ke)t tartsanak állományban, általában utóbbi a gyakorlat. Az Ő számukra a közvetlen gyártói support kisebb jelentőséggel bír, hiszen a - vélhetően a rendszert magas szinten ismerő - rendszerintegrátor a problémák jelentős részét képes saját hatáskörben kezelni. (Ne felejtsük el, hogy az általános support jellegű igények jelentős hányada az adott szoftver használatában való kellő jártasság hiányára és nem tényleges szoftver hibára vezethető vissza.)
Fontos ugyanakkor felismerni, hogy az esetleges hibajavítások, vagy a szoftver belső működését érintő hibák kivizsgálása nagyon nehéz (és így hosszadalmas), egyes esetekben lehetetlen a gyártói támogatás nélkül. Továbbá a szoftver kiadásakor egy azt kiszolgáló harmadik rendszerben még nem ismert hibából adódó sérülékenység kezelése is sokkal egyszerűbb és gyorsabb, ha van megfelelő support szerződés, így a gyártói támogatás minden felelősen gondolkodó végfelhasználó számára feltétlenül szükséges.
Cégünk jónéhány, az ipari megoldások élvonalába tartozó, prémium megoldásokat kínáló gyártó termékeit forgalmazza idestova több mint 35 éve. Ezen idő alatt volt lehetőségünk megfigyelni, hogyan ébrednek rá sorban az egyes szereplők, hogy egy-egy termék használatával kapcsolatos know-how kiadása (melyhez ma az internet és a rendelkezésre álló különböző multimédiás szolgáltatások már gyakorlatilag korlátlan lehetőségeket biztosítanak), sőt térítésmentes elérhetővé tétele nemcsak hogy kívánatos, de az így szabadon hozzáférhető információk alapján a terméket magabiztosabban ismerő és kezelő végfelhasználó mint visszatérő (vevő) üzleti szempontból sokkal fontosabb, mint a statikus tudásanyag egyszeri értékesítése. Az OPTO22 U, az Inductive University vagy épp a GE EDGE mind jó példa arra, hogy számos gyártó felismerte, a tudás megosztása nem versenyhátrány, hanem a tartós, sikeres CustomerCare alapfeltétele.
Végfelhasználói oldalról pedig mi sem természetesebb, mint hogy a saját rendszerek ismerete - mely adott esetben ingyenesen és/vagy egy állandó együttműködés keretében biztosított - csökkenti a kitettséget, gyorsítja a reakcióidőt, növeli egy projekten belül a (pénzügyi) tájékozottságot, azaz végső soron jelentős üzleti előnyt biztosít.
“Van rá x millió, ebből kell megoldani.” Ismerős mondat? Végfelhasználóként és szolgáltatóként is számtalanszor (talán túl sokszor) hallottam az idézett mondatot, mely sajnos nem ritkán prioritásban úgy előzte meg az “Egy idő/értékálló, hatékony rendszert szeretnénk” igényt, hogy egyébként egyik fél státusza sem indokolta azt. Az előfizetéses modell (és mellesleg a felhő alapú infrastruktúra) alkalmazása révén egy-egy projekt bekerülése ésszerű kezeléssel csoportosíthatóvá, szétoszthatóvá válik a különböző költséghelyek között, megkönnyítve így egy-egy beruházás megvalósítását és széles körű pénzügyi és műszaki mozgásteret biztosít az üzemi igényeknek megfelelően skálázott, gazdaságosan üzemeltethető rendszerek kialakítására.
Általános igazság, hogy az ipar nagyjából tíz évvel lemaradva és - felzárkózás tekintetében - évtizedekben mérhető átfutással követi a mainstream informatikát, ennek oka pedig a folyamatokban, azok kockázatainak és kezelésüknek sajátosságaiban, végső soron tehát az üzemviteli eltérésekben keresendő. Evidens tehát, hogy a konzumer szektorban már bevált előfizetéses licencelési modell egy az egyben nem alkalmazható, s egyben az is, hogy azok a piaci szereplők, akik jelen kihívásra kizárólag úgy próbálnak meg reagálni, hogy az imént említett szektorból szerződtetnek egyébként nagy tudású szakembereket, tévednek.
Ugyancsak hibát követ el az a gyártó, aki az előfizetéses rendszerből csak terminusok végén kvázi fixen kalkulálható és kivehető hosszabbítások bevételeit tartja szem előtt és ezzel egyenrangú prioritásban nem törekszik a konstrukcióval járó kiegészítő szolgáltatások biztosítására és fejlesztésére, melybe éppúgy beletartozik a szakmai és általános ügyfélelégedettségi szempontból kifogástalan support, mint az átfogó (online) oktatási rendszer vagy épp a közösség (Community), mely nélkül ma már egyetlen élvonalbeli szoftver sem tekinthető versenyképesnek.
Végezetül a végfelhasználóknak észre kell venni és el kell fogadni, hogy a jövőben az ICS rendszerek életútja a jelenleg megszokottnál sokkal dinamikusabb, sokkal több IT/OT jellegű üzemviteli tevékenységgel kiegészülő, állandó felügyelet mellett működő szolgáltatás lesz (részben egyébként már ma is az), melyet sokkal inkább üzemeltetési (OPEX kiadásként realizálódó) keretek között kell kezelni, mintsem egyszeri (CAPEX) beruházásként. A kettő megfér egymás mellett, de előbbi egyértelmű dominanciája vitathatatlan. Mindez természetesen egy folyamat, amelyben mindkét félnek aktív, sőt proaktív szerepe és felelőssége van.