Vendor lock-in, azaz szállítófüggőség – a vállalatvezetők rémálma. A függőség azóta különösen fontos kérdés, hogy technológiák életciklusa drámaian lerövidült. Egyre gyakrabban kell új technológiákkal megismerkedni, és ilyenkor a szállítóváltás is felmerül. Csakhogy azzal mindenki tisztában van, hogy egy ilyen váltással jön az adatmigráció és/vagy az architektúraváltás is annak minden nyűgével és költségével.

És kockázatával... Egy új technológia implementálása, a megtartandó rendszerekkel történő integráció stb. nehézségei és kockázatai, valamint ennek költségei egyaránt ott vannak a várható előnyökkel szemben. És a legfőbb: nincs garancia arra, hogy a vállalat az egyik szállítói kötöttségből nem egy másikba lavírozta magát.

Nem a hosszú távú szerződéssel van a baj

A szállítóhoz kötöttség alapvetően két módon valósul meg: hosszú távú szerződéssel vagy technológiai kötöttséggel. Az mindkét fél felelőssége, hogy kölcsönösen előnyös szerződést kössenek, és mindkettőjük kötelessége azt be is tartani. A vitás kérdéseket pedig vagy megoldják egymás között, vagy majd a bíróság dönt.

A technikai kötöttség ennél sokkal rafináltabb. Sokszor észrevétlenül kúszik be a vállalathoz, ahol a vezetők egyszer csak azt veszik észre, hogy egyetlen CRM-szállítótól (esetleg szolgáltatótól) vagy egy adatbázis-szállítótól függ a vállalat működése. Mindaddig ez nem gond, amíg a felek kölcsönös megelégedéssel együttműködnek. Ha azonban a szállító például a karbantartási és támogatási díjat emelni kényszerül, vagy az ügyfél technológiai váltást szeretne, súlyos problémává válik ez a helyzet. A szállítók mindent meg is tesznek azért, hogy a lehető legnehezebben lehessen megszabadulni a terméküktől, például rendkívül bonyolult felhasználási feltételeket szabnak. Ez aztán továbbgyűrűzik, és sokféle formában ölt testet, és van hatással a döntésekre, mint az Gregor Hohpe architekt-tanácsadó egy cikkében kifejti. (Hohpe jelenleg az AWS szekerét tolja, de korábban volt a Google Cloud műszaki igazgatója is.)

Ilyen hatás például, hogy a felhasználó a költségek csökkentése miatt inkább verziófüggőséget (version lock-in) alakít ki. Ennek eredménye lesz például a kényszerű verzióváltás (például az adott verzió támogatásának megszűnése miatt), ami általában aránytalanul magas költségekkel jár.

Észrevétlenül belopakodhat a szervezetebe például a belső kompetenciáktól, a munkatársaknál felhalmozódott know-how-tól való függőség is (skill lock-in). Ha az IT nem építi be a folyamatos változást, a technológiai és tudásmegújítást a működésébe, gyorsan csökken a változásra való képessége, és észrevétlenül sodródik afelé, hogy beleragadjon egy elavult technológiába.

Önmagában a felhő sem megoldás

A felhőtől sokan remélték, hogy végérvényesen megoldja a vendor lock-in problémáját. De ez hamis reménynek bizonyult. Attól, hogy nem a vállalat helyi adatközpontjában, hanem egy felhőszolgáltatóéban tárolódnak az adatok, futnak az alkalmazások stb., még nem változik semmi: az Oracle ott is Oracle, az SAP sem lesz más, ellenben egy újabb nehézséggel bővült a paletta, ha a cég váltani szeretne mondjuk AWS-ről Azure-ra vagy viszont. (További komoly kockázatot jelent a nagy szolgáltatók piaci túlsúlya, amivel Gazdag Ferenc 2016-os, de máig aktuális kétrészes cikke is foglalkozott.)

Ennek kivédésére jött a 'hibrid-multicloud' stratégia: vannak egy saját on-premise infrastruktúra az üzletileg érzékeny adatok kezelésére, amit egy nyílt forráskódú absztrakciós réteggel kötnek össze a különböző felhőszolgáltatásokkal. Az absztrakciós réteg feladata, hogy közös nevezőre hozza a felhőszolgáltatók egyedi különbségeit. Most attól eltekintve, hogy a közös osztóból kiindulás nem feltétlenül jó stratégia, itt is vannak azért kockázatok: magasak a személyi költségek (nyílt forráskód, saját fejlesztés), ami nem mindig tartható fenn hosszú távon.

A fentiekből látható, hogy nem lehet és nem is szabad csak szállítófüggőségre redukálni a problémát. És nem lehet cél – tekintve, hogy lehetetlen célkitűzés –, a teljes függetlenség. Reálisan bármely vállalat egyet tűzhet ki maga elé: megtalálni az egyensúlyt a saját képességei, az üzleti célok és a kötöttségek (vendor/version/skill lock-in) elfogadható szintje között. Azaz pontosan ismerni kell a belső kompetenciákat (a munkatársak tudása) és az abban rejlő innovációs tartalékot, valamint meg kell határozni azokat a kulcsterületeket, melyeken a vállalat maximálisan rugalmas szeretne maradni. Hogy egy egyszerű példát hozzunk: értelmetlen célkitűzés lenne leváltani a Windowst a vállalat desktopjain, de az már egyáltalán nem biztos, hogy ugyanazt a CRM-et vagy marketingautomatizációs eszközt kell használni, amit az előző tíz évben.

Elemezni, elemezni, elemezni

A fent említett Gregor Hohpe, aki pozíciójából – és meggyőződéséből is – eredően a felhős konstrukciókat előnyeit hangsúlyozza, a döntéshez két egyszerű, kétszer két mezős mátrix alkalmazását javasolja. Az első mátrixban négy mező van a váltás költsége és a megoldások nyújtotta egyedi előnyök tengelyén (a lenti ábrán a bal oldali). Ide kell besorolni a különböző megoldásokat.

Vannak a bármikor könnyen lecserélhető megoldások (Disposable), ezeket bármikor, viszonylag olcsón ki lehet váltani, ha találunk jobbat, vagy probléma lenne velük. Vele átellenben helyezkednek el a mátrixban azok a termékek, melyek csak komoly befektetéssel válthatók ki mással, de ezt elfogadjuk (Accepted Lock-in), mert egy sor olyan egyedi funkciót, eszközt biztosítanak, ami a vállalatnak fontos.

Mellé kerülnek azok a megoldások, melyek leváltása nagyon drága, ellenben kevés egyedi szolgáltatást adnak (Caution). Tipikusan ilyen egy relációs adatbázis, nem véletlen, hogy kevesen szánják rá magukat a cseréjére. És vannak az ideális megoldások (Ideal) – minden informatikai vezető álma –: egyedi szolgáltatásokat és eszközöket adnak az IT-nak, de bármikor és egyszerűen át lehet térni valami konkurens termékre. (Az ilyen termékek képtelenségét persze Hohpe is elismeri: ha egy megoldás egyedi funkciókat ad, definíció szerint a versenytársai épp azokat nem tudják biztosítani, tehát nincs mire áttérni.)

Az egyes megoldásoknál érdemes összevetni a váltás költségeit a váltás valószínűségével (fent a jobb oldali mátrix). A legnagyobb figyelmet azoknak a megoldásoknak kell szentelni, melyeknél magas a váltás valószínűsége annak ellenére, hogy az drága művelet lesz (Caution). Az architekt-tanácsadó szerint azonban érdemes az "Agility" mezőbe kerülő megoldásokkal is kiemelten foglalkozni. Ezek gyorsan cserélődnek, és a váltás költsége sem számottevő. Az ilyen termékek hatóköre többnyire cégen belül is lokális, ám ezek az apró változások gyorsan képesek összeadódni, akár a költségekben is.