Felmérésünk alapján cikkünk a következő kérdésekre igyekszik választ adni:

• Az IoT implementációk során – akár megelőzően, akár már a projekt kellős közepén - milyen jellemző vezetői/megrendelői dilemmák merülnek fel?
• Hogyan lehet ezeken átlendülni? Milyen technológiai, skálázási, megtérülési kérdéskörök kerülnek elő ilyenkor?
• Milyen mélységben érdemes megtervezni egy implementációs projektet ahhoz, hogy megfelelő magabiztossággal vágjunk bele?

A továbbiakban vázolt dilemmák priorizálása, súlya nagyban függ attól is, hogy a szervezet mely szintje tölti be a megrendelői szerepet. Tapasztalatunk alapján tipikusan azok a stakeholderek kerülnek megrendelői pozícióba, akik az IoT projekteket kezdeményezik, ötletgazdaként fellépnek, vagyis a következők:

• Tulajdonos/anyavállalat – jellemzően a csoporton belül máshol már működő funkciók roll-out-ját próbálják a lehető leghatékonyabban „exportálni” korlátozott figyelemmel a helyi sajátosságokra.
• Felsővezetés - felülről érkező problémamegértés, (vagy éppen meg nem értés), ami jellemzően középvezetői szinten csapódik le, így rajtuk múlik, mennyire engedik be például a transzparenciát növelő technológiákat.
• Maga az üzleti terület (kereskedelem, gyártás, minőségellenőrzés stb.), középvezetői szint, mely esetben az üzleti buy-in, azaz a megfelelő hajtóerő adott, a felsővezetői támogatást viszont meg kell szerezniük ekkor is.
• Informatikai terület – jellemzően technológiai fókuszú projektek, amelyekhez, ha nem szerzik meg az üzlet elkötelezettségét, csak egy újabb játszóteret alkotnak saját maguknak.   
• Munkatársi szint – sokszor egy nem kívánatos feladat elkerülésére kiharcolt egyedi, szigetszerű megoldás.
• Inkumbens szolgáltató / gyártó – mint ötletgazda tud megjelenni, természetesen nem mint megrendelő.

IoT projektek kapcsán az első és talán legfontosabb kérdés az üzleti probléma megértése. Nagyvállalati környezetben nagyon sok egyedi igénnyel, kihívással találkozunk, ugyanakkor ez nem zárja ki a dobozos célmegoldások alkalmazását, főleg, ha a gyártó mutat némi rugalmasságot. A vezetői dilemma tehát úgy merül fel, hogy érdemes-e nulláról kifejleszteni egy olyan megoldást, amely 100%-ban lefedi az üzleti igényt, képes-e ebből némileg engedve alkalmazkodni egy meglévő funkcionalitáshoz, vagy rá tudja-e venni a gyártót arra, hogy egyedi fejlesztésekkel testre szabja az alkalmazást. Tapasztalatunk szerint - még akkor is, ha a kiinduló alap szenzorikus adatgyűjtő megoldás dobozos -, jellemző, hogy az adatok integrálása a vállalati működésbe, IT ökoszisztémába már egyedi fejlesztéssel oldható csak meg. Hiába léteznek például akár tucatjával beltéri nyomkövetést biztosító alkalmazások, azok önmagukban a vállalati alaprendszerekben fellelhető egyéb információk nélkül annyit érnek, mintha a „régi offline világban” iránytűt próbálnánk használni térkép nélkül.

A dilemma feloldását ugyanakkor pontos use case definícióval, szállítói megoldások strukturált összehasonlításával kezdhetjük meg.

Sok esetben az a technológiai szállító partner, aki már jelen van a vállalatnál, helyzeti előnyéből fakadóan továbbfejlesztési ajánlásokat tud megfogalmazni, szakmai okok mellett neki fel nem róható üzleti érdekből.  A dilemma ezzel kapcsolatban vezetői szinten úgy merül fel, hogy ezen ajánlások esetén mennyire érdemes folyamatosan megszondáznia a piacot alternatív megoldások után keresve. Ha minden funkció esetében újabbnál újabb technológia kerül a rendszerbe a heterogenitásból eredő komplexitás - gondoljunk csak a különböző adatforrások megfeleltetésének nehézségeire – előbb-utóbb fenntarthatatlanná kezd válni. Ha viszont egyetlen gyártóra épít, - ami valljuk be sokszor a legkényelmesebb megoldás -, akkor hamar felléphet a „vendor lock-in” jelenség, azaz amikor annyi szállal kötődik már a vállalat egyetlen szállítóhoz, hogy az ebből fakadó technológiai és akár pénzügyi kockázatai is az egekbe emelkednek.

Ezen dilemma feloldására az egyes technológiai alternatívák gondos összehasonlítása, pénzügyi és nem pénzügyi szempontokból történő kielemzése segíthet, ha másért nem, az árak kordában tartása végett. Fontos továbbá, hogy olyan központi IoT adatplatformot alakítson ki a vállalat, amely lehetőség szerint flexibilisen, jól skálázható módon tud különböző technológiákkal kommunikálni, integrálódni.

Amikor magát a konkrét felhasználási célt már kidolgozták, további dilemmát okoz a megrendelőknek annak konkrét technológiai leképezése. Az IoT szenzor kínálat ma már például olyan széles, hogy könnyű elveszni az egyes alternatívák között. Nehéz is elsőre átlátni mi okoz akár 10-20-szoros különbséget 1-1 szenzortípus árában. További kérdés, hogy legyen vezetékes vagy vezetéknélküli a választott megoldás, ami a use case-től, illetve a vállalat azon környezeti adottságaitól függ leginkább, amelyek mellett a telepítést el kell végezni. Az árnyékolás, elvárt flexibilitás, tápellátás, vezetékezés kivitelezési nehézségei mind olyan tényezők, amelyeket figyelembe kell venni. További dilemma szokott lenni az, hogy létezik ugyan valamilyen adatgyűjtés (gyártó cégeknél tipikus probléma), de a hozzáférés az adatokhoz már nehézkes. Ilyenkor a redundáns mérés kialakítása is felmerülhet alternatívaként az adatintegráció mellett.

A megfelelő adatplatform kiválasztása további nehézséget jelent. Az IoT projektek esetén ma már a legtöbb esetben felhőtechnológia jelenti a legmegfelelőbb megoldást, ugyanakkor ezt a kérdést is körbe kell járni, nem száll le közénk magától. Felhős adatplaformból a legismertebb szolgáltatókon túl (Microsoft Azure, Google Cloud Platform, AWS) több száz adatplatform áll rendelkezésre a piacon, így a kiválasztás e tekintetben sem triviális. Természetesen irányadó a vállalat meglévő IT landscape-je, ugyanis szigetszerű megoldások helyett a jellemző üzleti igény a legmagasabb fokú integráció, de azért költséghatékony biztosítása meglévő rendszerek, adatforrások felé.

Adatfogyasztási kérdéskörökben pedig azt szükséges eldönteni, hogy az egyes, az IoT alkalmazás által kiszolgált felhasználói szintek számára melyek a takarékos, de egyben felhasználóbarát eszközök. Ezek a szintek akár határozottan elkülönülhetnek, gondolhatunk egy telefonos riasztástól kezdve, egy, a gyártósor mellett nagyképernyőre kitett operációs dashboardon keresztül egy felsővezetői aggregált riportra is, vagy akár csak egy olyan automatizmusra, amelyet az alkalmazás indít el (pl. italautomata készletszint-figyelés esetén automatizált belső megrendelésindítás).

A fenti dilemmák összegzése a technológiai architektúrában kerül kitisztázásra, ami szoros összefüggésben áll a megtérülésszámítással (business case), hiszen az egyes technológiai alternatívák költségvonzata akár nagyságrendekkel eltérhet egymástól, így a két nézőpont - technológiai és gazdasági - pengeváltásából alakul ki a végleges, megtérülő opció.

Sok esetben háttérbe szorulnak a projekt kezdetén azok a kérdések, amik arra irányulnak, hogy az új, IoT technológiára épülő alkalmazás hogyan építhető be szervesen a vállalati működésbe? Lakossági példával élve nem azért veszünk okos sportórát, hogy sportosnak tűnjünk – bár ilyen indíttatás is lehet – hanem hogy az edzéseinket, versenyeinket pontosan, real-time követve, tendenciákat figyelve tudjuk a teljesítményünket, étrendünket, akár alvásunkat optimalizálni. Vállalati viszonylatban hasonló a helyzet. Milyen folyamatainkat kell ahhoz átalakítani, hogy a bevezetett IoT alkalmazás ne csak „szexinek” tűnjön egy vállalati prezentációban, hanem valódi hasznot hajtson? Milyen másodlagos/harmadlagos hatásokkal kell számolni? Sokszor magára az új funkcióra koncentrál a vállalat és a folyamati integrációt magától értetődőnek veszi. Az, hogy egy real-time adatfolyam végén előáll egy riport, az még nem jelenti automatikusan azt, hogy a vállalat döntéshozatali mechanizmusai átalakulnak. Körbe kell tehát járni azt is, hogy a napi működés során mit és milyen formában fog a vállalat az alkalmazás hatására másként csinálni, mint korábban. Például az energiafogyasztás nagyon precíz nyomon követése mit sem ér akkor, ha az adatokból nem definiálunk energiamegtakarítási intézkedéseket, ha ennek nincs meg a felelőse (jellemző eset a „felülről” jövő kezdeményezések esetén). Ezeket a kérdéseket jó előre, az üzleti koncepciótervben érdemes rögzíteni és az implementáció során akár folyamatutasítás szintjéig levinni szorosan bevonva a majdani felhasználói kört.

További fenntarthatósági dilemmák közé sorolható az, hogy egyáltalán ki lesz az az alkalmazásgazda, aki felel az új funkcióért, vagyis akár 5-10 technológiai komponensből álló adatfolyam zavartalan működtetéséért, továbbfejlesztéséért. Szükséges tisztázni, mely funkciók támogatása marad házon belül és hol kell támogatási szerződéseket kötni külső partnerekkel (pl. szenzorkarbantartás területén).

További eldöntendő kérdés, mely adatainkat, milyen időtávon tároljuk abban a mélységben, amelyben azok elsőre rendelkezésre állnak – IoT projektek során nagyon könnyű hatalmas adattömegeket előállítani, aminek a költségmenedzsmentje is külön feladat – főként felhős környezetben.

A szolgáltatói támogatási szerződések mellett üzemeltetési utasítás és data retention policy áll segítségünkre ezen kérdések átgondolásában, szabályozásában.

Felmérésünk tapasztalata alapján nagyon kevesek számszerűsítik a várható hasznokat és költségeket, ezáltal 1-1 IoT projekt valós gazdasági hozzáadott értékét. Ennek számtalan oka van a túlzott magabiztosságtól kezdve a számszerűsítési nehézségekig. Egy jó ötlet még nem feltétlenül garantálja a gazdasági, vagy arra lefordítható hasznot. Mindazonáltal kiemelendő, hogy a számok nyelvén a fenti dilemmák közül jó néhány feloldhatóvá válik. Továbbá egy gondosan elkészített megtérülésszámítás kikényszeríti azt, hogy a IoT implementáció teljes egészét a vállalat végiggondolja, végigszámolja – még akkor is, ha szükséges benne feltételezésekkel élni. A számszerűsítés tudja megalapozni egy pilot projekt folytatását, de akár egy megvalósult teljes implementáció valós megítéléséhez is hozzájárulhat.

Összegzésül annyit kijelenthetünk, hogy nem érdemes az utolsó részletig mindenre kiterjedő terveket készíteni a projekt legelején. Ugyanakkor az IoT projektek sikeres lebonyolítása érdekében az már szükséges, hogy a fent vázolt főbb témakörökről az - üzleti céltól a fenntartási időszakig - időben legyen elképzelése a vállalatnak, amit menet közben egyre mélyebben kibont.

Nézze meg az IFUA Horváth tanulmányát a magyarországi IoT implementációs gyakorlatokról! Szakértőink készítették el az első magyarországi, nagyvállalati IoT implementációs projektekkel kapcsolatos átfogó felmérést, ennek eredményét és saját projekttapasztalataikat foglalták össze a tanulmányban.

A szerző az IoT Business Unit vezetője