A sorozat első részében arról beszéltünk, hogyan válhatunk egészségtelenül függővé beszállítónktól, és – ami a legfontosabb – milyen problémákat okozhat ez a vállalatunk számára.
Ma megvizsgáljuk, mit tehetünk annak érdekében, hogy elkerüljük ezt a függőséget.
1. A folyamatokkal és rendszerekkel kapcsolatos szakértelem, valamint azok fejlesztési terveinek fenntartása
Ha úgy dönt, hogy nem akar az informatikai kérdésekkel foglalkozni, és csak általános utasításokat ad az informatikai szolgáltatójának, akkor egyenesen a függőség felé tart. Lehet, hogy meglepőnek tűnik, de ez a megközelítés gyakran problémákat okoz magának a szolgáltatónak is; ugyanis egy idő után az ügyfél igényei kezdik átfedni egymást és összekuszálódni, és az új követelmények teljesítése komoly gondot jelent a szolgáltató számára.
Egy olyan vállalat számára, amely versenyképes kíván maradni, fontos, hogy az informatikát a folyamatok támogatására, fejlesztésére és mérésére szolgáló eszközként tekintse. Nem nehéz kitalálni, hogyan lehet ezt megvalósítani, hiszen manapság elegendő módszertan és szabvány áll rendelkezésünkre, amelyek segítségével áttekintést nyerhetünk a folyamatokról és hatékony tervezést végezhetünk:
- Vállalati architektúra – egy módszer, amely leírja a szervezet céljait; azt, hogy ezeket a célokat hogyan valósítják meg az üzleti folyamatok révén; valamint azt, hogy ezeket a folyamatokat hogyan támogathatja a technológia. További információkért olvassa el a „Ne ragadjon le” című cikket, amely a gyenge vállalati architektúráról szól. A vállalati architektúra két legismertebb megközelítéséről az Open Group és Zachmann weboldalain találhat információkat.
- Folyamatleírás – a legismertebb és legszélesebb körben alkalmazott szabványokat az Open Management Group (www.omg.org) dolgozza ki. A folyamatok BPMN (Business Process Model and Notation) specifikáció szerinti leírása lehetővé teszi a vállalatvezetés számára, hogy könnyen áttekintse és rögzítse a vállalatán belül zajló folyamatokat.
- Felhasználói dokumentáció – ez nem feltétlenül egy olyan dokumentum, amelyet a szállító ír meg, majd egy fiókba zárva porosodik. Jó megoldás olyan videókat készíteni, amelyek bemutatják a felhasználóknak, hogyan használják az alkalmazást a mindennapi munkájuk során; ezáltal egyszerűsítve a termék támogatását és az új felhasználók képzését. A videók gyakran csak néhány percesek, és leírnak mindent, amit tudni kell a rendszer hatékony használatához. Például: nézze meg a Yammer használatáról szóló útmutatót egy kutatási projektben; vagy az útmutatót arról, hogyan rendeljen árukat egy online boltból.
Minden szabványhoz és módszertanhoz részletes dokumentáció és tanulási anyagok tartoznak, amelyek minden területet részletesen ismertetnek. Tapasztalatom szerint érdemes szakértőt megbízni azzal, hogy kiválassza a módszertan azon elemeit, amelyek az adott vállalat számára megfelelőek.
Ha know-how-ját egységes formában rögzíti, akkor nem csupán egy olyan eszközzel rendelkezik majd, amelynek segítségével a vállalat fejlesztését szolgáló témákat megvitathat, hanem biztos lehet abban is, hogy a jelenlegi és potenciális beszállítói túlnyomó többségével közös nevezőre jut.
Ha változtatni szeretne a folyamatain és az információáramláson, kezdje a munkaszervezés átalakításával – akár elméleti szinten, akár egy kísérleti projekt keretében –, és tesztelje, hogy a változás hozza-e a várt eredményeket. Ezután számolja ki a változás előnyeit és a megvalósítás költségeit. Ha minden a tervek szerint alakul, kezdje el módosítani a rendszereket; ha nem, gond nélkül leállíthatja a folyamatot. Ha ezt teljes mértékben egy külső szolgáltatóra bízza, kevesen mernek leállítani egy olyan projektet, amelybe már erőforrásokat fektettek be.
2. Az adatoknak minden körülmények között a sajátjaidnak kell lenniük
Az adatokat a szolgáltatónk tárolja; most azonban összevesztünk velük, és azt mondták nekünk, hogy az adatok az övék... Sajnos ez a helyzet nem is olyan ritka, mint gondolnánk. Nem a felhőszolgáltatóknál és a tárhelyszolgáltatóknál fordul elő gyakran – ahogyan azt sokan feltételezik –, hanem leginkább az egyedi fejlesztésű rendszerek esetében, ahol az adatok egy olyan „fekete dobozban” vannak tárolva, amelyet teljes mértékben a szolgáltató ellenőriz.
Ez egy hagyományos módszer arra, hogy a szállító ellenőrzése alatt tartsa az ügyfelet. A probléma általában kétféleképpen oldható meg: az adatok közvetlen ellenőrzésével, vagy annak biztosításával, hogy azokat megbízható módon, felhasználható formátumban lehessen beszerezni.
Például: egy olyan szolgáltatás, amely az e-mailes kapcsolattartók kezelésére szolgál, és amelyhez a szolgáltató weboldalán történő regisztrációval jutunk hozzá. Az első megközelítés az, hogy gondoskodunk arról, hogy az adatok szinkronizálva legyenek a saját rendszereinkben; a második pedig az, hogy rendszeresen letöltjük a szolgáltató rendszereiben tárolt információkat, és azokat „minden esetre” nálunk is tároljuk.
Még a saját rendszerünkben is – ahol az adattárolás jól dokumentált – az adatok szabványos táblázatba, adatbázisba vagy XML-formátumba történő exportálásának módszertana jelentősen megkönnyítheti egy új rendszer integrálását. Fontos, hogy eljárásokat hozzunk létre az adatok kivonására, az export működőképességének ellenőrzésére, valamint a formátum megfelelő dokumentálására, mert az a kritikus pillanat, amikor az adatokra szükségünk van, pontosan a legrosszabb pillanat arra, hogy kiderüljön, az export nem működik, vagy hogy a tökéletesen exportált adatok olyan formátumban vannak kódolva, amellyel nem tudunk dolgozni.
A fenti követelményeket minden esetben ellenőrizni kell, amikor a szállítótól új funkciókat vagy rendszermódosításokat veszünk át.
3. Az alkalmazások szellemi tulajdonjogainak megőrzése
Az alkalmazások tulajdonjoga az alkalmazás forráskódjának vagy tervezésének tulajdonjogát jelenti. Ha nincs ellenőrzésünk a forráskód felett, akkor annak a kockázatát vállaljuk, hogy amikor szolgáltatót szeretnénk váltani, kiderül, hogy a jelenlegi szolgáltató a kód egy kritikus részének tulajdonosa, és nem lesz hajlandó azt ingyenesen átadni. Ezt elkerülhetjük, ha a szerződésben egyértelműen meghatározzuk a tulajdonjogot, kijelentve, hogy a kért változtatások eredményeként kifejlesztett kód kizárólag a mi tulajdonunk, vagy hogy ezek a változtatások olyan licenc alapján készültek, amely lehetővé teszi számunkra azok ingyenes használatát és terjesztését.
Még ha szerződésben is biztosítottuk a tulajdonjogot, ez nem jelenti azt, hogy az a beszállító, akivel a szerződést felmondjuk, hozzáférést biztosít számunkra a kódhoz. Ezért erősen ajánlatos, hogy a forráskód-kezelő rendszert, a wikit és az egyéb dokumentumokat egy harmadik félnél tárolják, és hogy a partnert kötelezzék az adatok meghatározott helyen és időpontban történő tárolására, hogy mi hozzáférhessünk az aktuális verziókhoz.
4. Rendszerintegráció a funkciók bővítése helyett
A webszolgáltatások API-jai (alkalmazásprogramozási interfészek) manapság számos kereskedelmi és nyílt forráskódú alkalmazásban megtalálhatók. Ez azt jelenti, hogy az alkalmazások felhasználói számára elérhető összes szolgáltatás és funkció különböző rendszerek és alkalmazások között is használható.
Az interfész meghatározásához használt protokollok és szabványok révén ezek a szolgáltatások egységes kommunikációs csatornát és platformot biztosítanak; így egy adott nyelven vagy operációs rendszeren írt alkalmazás teljesen más módon írt rendszerek számára is elérhetővé válik. Az adatok átvitele közös formátumban történik – például XML-ben vagy JSON-ban –, miközben a két rendszer kódbázisa teljesen független marad egymástól.
Manapság minden felhasználó el tudja képzelni, hogyan működik a rendszerintegráció. Végül is mindannyian használunk egymással integrált webalkalmazás-szolgáltatásokat – például a Google Naptárat a Google Névjegyekkel és a Gmail-lel. Ha úgy döntünk, hogy a meglévő helyett egy másik naptárat kezdünk használni, csak össze kell kapcsolnunk a meglévő adatokkal. Ez a rendszerváltási módszer nem lehetséges, ha saját rendszerünk van, amelyet eredetileg csak könyvelésre vásároltunk, és fokozatosan a szállítóval fejlesztettünk ki hozzá CRM-modult, szolgáltatási modult stb.
Ugyanez a logika vonatkozik a felhőszolgáltatók által szolgáltatásként nyújtott rendszerekkel (SaaS – Software as a Service) való integrációra is. A webszolgáltatások használata elválasztja egymástól az egyes alkalmazásokat, így az egész rendszer rugalmasabbá és átláthatóbbá válik. Ezzel szemben a különböző modulok közötti rögzített kapcsolatok megkönnyítik a szolgáltató számára, hogy növelje a tőle való függőségünket, megnöveljék a kód bonyolultságát, és a rendszer rugalmassága a legkevésbé rugalmas rész szintjére csökken.
5. Próbálja meg a lehető legkisebb mértékben módosítani az alaprendszert
Próbálja meg a szükséges rendszert a standard megvalósításon végzett minimális módosításokkal megvalósítani. Általában nem Ön a szállító első ügyfele. A megvalósítás során próbálja meg a lehető legjobban kihasználni a szállító más ügyfelekkel szerzett tapasztalatait. Valószínűleg meg fog lepődni azon, hogy egyes folyamatok mennyivel hatékonyabban valósíthatók meg, vagy hogy bizonyos, korábban figyelmen kívül hagyott adatok versenyelőnyünkké válnak.
Ha az alkalmazás funkcionalitásában jelentős változtatásokra van szükség, ez jelentősen megnehezítheti a jövőbeli új verziókra való áttérést; és bármilyen áttérés kihívást jelent majd a fejlesztés és a bevezetés szempontjából.
6. Több beszállítót vegyen igénybe
Próbálja meg saját maga irányítani a rendszer teljes tervezését, fejlesztését, bevezetését és üzemeltetését, és ne bízza ezt a feladatot a beszállítóra. Célszerű például elkülöníteni az üzleti elemzőket a fejlesztőktől. Ajánlatos a rendszert a fejlesztői csapaton kívüli tesztelőkkel teszteltetni. Ők hatékonyabban végzik el a munkát, és így sokkal nagyobb az esélye annak, hogy hibátlan terméket kapjon. Ha egy másik fél felelős az üzemeltetésért (pl. egy felhőszolgáltató), győződjön meg arról, hogy ők is nyomást gyakorolnak a fejlesztőkre, hogy olyan terméket szállítsanak, amely minimálisra csökkenti a rendszer üzemeltetési problémáit.
7. A szerződésben határozza meg a szerződés felmondásának feltételeit, beleértve a szállítóval szembeni kártérítési kötelezettségeket is
Hogyan szabályozza a szerződés az együttműködés megszüntetését? Három hónapos felmondási idővel, amely után Ön leállítja a fizetést, a szolgáltató pedig megszünteti a támogatást? Ez teljesen elégtelen.
Meg kell határozni, hogy a szállító milyen dokumentációt és milyen minőségben köteles átadni Önnek – vagy közvetlenül az új szállítónak – a felmondási idő alatt. Ha biztosította a tervezéshez, a forráskódhoz és a 3. pontban említett dokumentáció egyéb részeihez fűződő szellemi tulajdonjogokat, az még jobb. A szállítóval kötendő szerződés megkötésekor célszerű megkérdezni a 2. és 3. helyen végzett vállalatokat, hogy mire lesz szükségük, ha átveszik a fejlesztést és a karbantartást a nyertestől.
8. Tájékoztassa a beszállítókat a jövőbeli fejlesztési tervekről
Építsen ki hosszú távú partneri kapcsolatot beszállítóival! Ha rendszeresen megbeszéli velük fejlesztési terveit és stratégiai kérdéseket – és nem csupán a funkciók aktuális változásait –, akkor a beszállító olyan javaslatokkal állhat elő, amelyek stabil, hatékony és költséghatékony rendszerarchitektúrát eredményeznek, nemcsak a jelenlegi, hanem a jövőbeli igényeinek is megfelelően. Az igényeinek pontosításához használhatja például a MuSCoW-módszert, amely a következő kategóriákba sorolja az igényeket:
- Elengedhetetlen – elengedhetetlen
- Kellett volna – kellett volna
- Lehetett volna – jó lett volna, ha
- Most nem kell – jelenleg nincs rá szükség
9. Gyűjtsön ötleteket és véleményeket más felektől
Ne ragadjon le egy helyen; kövesse a trendeket; keresse a legjobb megközelítéseket és gyakorlatokat; és tartsa szemmel az eseményeket. Vegyünk igénybe egy céget, hogy harmadik véleményt kapjunk – ők mind technikai, mind stratégiai szempontból értékelni fogják döntéseinket. Nem kell, hogy drága legyen. És egy ilyen tanácsadás megéri, mert segít elkerülni a hibákat. Tapasztalatom alapján ismerek egy esetet, amikor egy beszállító arra kényszerítette az ügyfelet, hogy több millió koronát fektessen be egy olyan probléma megoldásába, amelyet ő maga okozott; egy tanácsadó pedig megállapította, hogy a beruházás egyáltalán nem oldaná meg a problémát, mert az máshol rejlik.
Egy tanácsadó segíthet a stratégia kidolgozásában, a kereslet felkeltésében, a lehetőségek értékelésében, valamint abban, hogy a dolgokat egy váratlan szemszögből vizsgálja meg. Segíthet továbbá a beszállítók ellenőrzésében és abban, hogy a lehető legjobb eredményt érje el. A tanácsadónak mindig szem előtt kell tartania, hogy Ön független szeretne maradni egy adott beszállítótól, és hogy a saját szakértelmét versenyelőnyként értékeli.
A beszállítók megfelelő kiválasztása a kockázatkezelésről szól
Úgy gondolom, hogy a cikk elolvasása után már tisztább képet kapott arról, hogyan teheti beszállítóit sikerének partnereivé, anélkül, hogy azok alárendeltjévé válna. A kellemetlen helyzetek elkerülése a következetes kockázatkezelésen és olyan megoldások választásán múlik, amelyek egyensúlyt teremtenek a jelenlegi követelmények és a jövőbeli rugalmasság között. A fenti elvek betartásával biztosíthatja a beszállítók és az új rendszerek megfelelő kiválasztását.
