Annak ellenére, hogy a három-négy évtizeddel ezelőtti állapothoz képest egy-egy területen is rengeteg IT-szállítóból választhatnak a vállalatok, a szállítóhoz kötöttség, azaz a vendor lock-in problémája csak nem akar megoldódni. Egy korábbi tanulmányában az IDC összesítette az egyes IKT-szegmensek költéseit, és mellé tette, hogy az adott szegmensen hány szállító osztozott (lásd a lenti táblázatot). Még az olyan szűk területen is, mint a highend szerverek és mainframe-ek piaca, tíz szállító osztozik.
A választék tehát óriási. Miért téma akkor mégis a szállítóhoz kötöttség? És miért van szükség egyre felkészültebb VSMO-kra (Vendor and Sourcing Management Officer) a vállalatoknál?
A szállítók nem jótékonysági intézmények
A szállítókat saját érdekeik motiválják. Nem akarják leveszíteni bevételeiket, sőt mindig új bevételi forrásokat keresnek. Az új ügyfelek esetében számtalan olyan fogást alkalmaznak, amely vonzóvá teszi az adott szállítót és megoldását. Bevezető kedvezményeket kínálnak, egyszerűsített licencelési modelleket alkalmaznak, és szigorú vállalásokat tesznek a szolgáltatási szintre vonatkozóan.
Mindez nagyon vonzó lehet az adott vállalatnak, ám amikor lejár a szerződés, jön a feketeleves. A szerződés lejártakor, ha az ügyfél nem elégedett maradéktalanul az adott megoldással, elvileg válthat, hiszen számtalan opciót találhat a piacon, melyekből a számára optimálisat kiválaszthatja. Csakhogy a technológia vagy a szolgáltatás olyan mélyen integrálódott a vállalat infrastruktúrájába, folyamataiba, üzleti tevékenységébe, hogy a váltás csak távoli lehetőségként merülhet fel. A költségek ugyanis olyannyira magasak, hogy a váltás gazdaságilag nem indokolható meg. Az eredmény tehát nem más, mint a vendor lock-in.
Ehhez persze a vállalatok is hozzátették a magukét. Nagyon sok energiát fektettek abba, hogy az egyes megoldásokat testre szabják, sokszor anélkül, hogy ennek a logikáján elgondolkodtak volna. A túlzott testre szabásnak azonban évtizedes távlatban az lesz a következménye, hogy egy idő után a mögöttes kód már nem frissíthető anélkül, hogy a rendszerbe fektetett munkát ne dobnánk ki. És ugyanezért az is nagyon nagy költségekkel járna, ha más szállító más megoldását választaná az adott cég.
Ugyanez egyébként a felhős megoldásoknál, például a platformszolgáltatásoknál (PaaS) is lejátszódhat. Egyfelől ugyan a PaaS használatával lerövidülhet a fejlesztési ciklus, és gyorsabbá válhat a piacra vitel, de mindaz a kompetencia, amely a PaaS-hoz kötődik, teljes mértékben hiányozni fog az azt használó szervezetből. Tehát egy váltás ismét csak nagy költségekkel járna, ami üzletileg már nem biztos, hogy kifizetődő.
A nyílt forráskód és a felhő csapdája
Kézenfekvő lenne, hogy a vállalatok a nyílt forráskódú megoldások felé forduljanak. Itt az alapeset az, hogy van a szabadon hozzáférhető forráskód, ami nyílt szabványokon alapul, és a szervezet szabadon dönthet, hogy melyik szállítótól vesz igénybe hozzá szolgáltatásokat, például terméktámogatást. Csakhogy ez a modell így tiszta formában nem létezik – állítja az IDC. Az idő elteltével ugyanis a teljes stackben egyre több olyan kiegészítő – és már zárt – kód jelenik meg, amely az open source tartalmak kezeléséért felel. Minél mélyebben ágyazódnak be ezek a kiegészítő kódok a teljes stackbe, annál nagyobb erőfeszítést igényel egy esetleges szállítóváltás. Azaz hosszabb távon paradox módon a nyílt forráskódú rendszerekben is ott van a szállítóhoz kötöttség veszélye.
A felhős szolgáltatások rugalmasságot és szabadságot ígérnek. De a felhős platformokra érdemes inkább úgy tekinteni, mint egy operációs rendszerre. És ha így nézzük, akkor már jobban látható az is, hogy egy felhőszolgáltatás igénybe vételekor milyen súlyos és hosszú távú döntés kell hozni. Ha egy alkalmazást egy operációs rendszerre fejlesztenek, azt egy másikra portolni meglehetősen nagy munka. Ugyanígy van ez a felhős platformokonál is. Ha évekig egy felhős környezethez igazított a vállalat mindent – alkalmazásokat, terhelést stb. –, emberes feladat lesz azt átpakolni egy másik, bár ugyancsak felhős, környezetre.
Önmagában egy SaaS (Software as a Service) szolgáltatás könnyen megszüntethető. Csak épp az adatok migrálása nem lesz olyan egyszerű. Egyfelől az a probléma, hogy a projektben három fél közreműködésére van szükség. Az ellenérdekelt régi szolgáltató, az új szolgáltató és az ügyfél között kell biztosítani valamiféle összhangot. És akkor még ott vannak a technikai problémák, például az architektúra átvihető-e az egyik szolgáltatótól a másikhoz, és milyen módosításokkal.
Nem véletlen, hogy a szakértők szerint a felhős szerződések tárgyalásakor mindig a végén kell kezdeni: mi történik akkor, ha valaki felmondja a szerződést? De ha még szerződésben is rögzítik a szolgáltató kötelezettségeit, voltaképpen csak a váltáskor derül ki, hogy rendelkezik-e olyan mechanizmusokkal, amelyek biztosítják az adatok biztonságos átvitelét az új szolgáltatóhoz.
Sok szervezet a felhős szolgáltatás esetében igénybe vesz olyan adatokat is, melyek nem a belső folyamataiból származnak. A szolgáltató egyben integrációs pontot is biztosít a különböző adatforrásoknak (vállalati, third-party, felhőszolgáltató). A váltáskor értelemszerűen ez a helyzet megváltozik, és egy adatforrás biztosan kiesik. Az ilyen helyzetekre a szolgáltatói szerződés megkötésekor nagyon oda kell figyelni.
Egyenrangú kapcsolatot kell kialakítani
A szervezetek általában alaposan körbejárják a lehetőségeket, amikor egy szállítói szerződést megkötnek. Egyes esetekben az üzleti előnyök miatt tudatosan vállalják a szállítóhoz kötöttség kockázatát, és a megkötött szerződésben minden lehetséges problémára megpróbálnak felkészülni.
A technológiai azonban túl gyorsan változik ahhoz, hogy minden lehetséges helyzetre fel lehessen készülni. Az ebben rejlő kockázatokat csak azzal lehet csökkenteni, hogy a szervezetek jó kapcsolatot alakítanak ki a kulcsszállítóikkal. Ha a megfelelő szinten történik és folyamatos a kapcsolattartás, a felmerülő szolgáltatási vagy minőségi problémák megoldásában is sokkal együttműködőbb lesz a szállító.
Ehhez azonban pontosan kell azonosítani azokat a technológiákat, melyek jelentős hatást gyakorolnak a szervezet működésére. És persze ezzel együtt azokat a technológiákat is azonosítani kell, melyek lecserélésének a költségei a legmagasabbak, és ezeket folyamatosan újra is kell értékelni.
A NIS2-megfelelőség néhány technológiai aspektusa
A legtöbb vállalatnál a megfeleléshez fejleszteni kell a védelmi rendszerek kulcselemeit is.
CIO KUTATÁS
TECHNOLÓGIÁK ÉS/VAGY KOMPETENCIÁK?
Az Ön véleményére is számítunk a Corvinus Egyetem Adatelemzés és Informatika Intézetével közös kutatásunkban »
Kérjük, segítse munkánkat egy 10-15 perces kérdőív megválaszolásával!
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak