A szerződés nem indítja újra a szervert
A félelem, hogy egy kis stúdió eltűnik, jogos. Egy két-öt fős csapatnál a betegség, a kilépés vagy a profilváltás valós forgatókönyv, és nincs mögötte több száz fős ügyfélszolgálat, amely a hiányt átmenetileg elfedné. A kockázat kezelése azonban nem a szerződésnél kezdődik, hanem a fiókoknál.
A jól megírt szerződés kártérítési igényt alapoz meg és rögzíti a felhasználási jogokat. Amit nem tud: nem ad belépést egy domainregisztrátor felületére hétfő reggel, amikor a weboldal és a céges levelezés áll, mert egy megújítási értesítő olyan postafiókba érkezett, amelyet már senki nem olvas. A per hónapokig tart, a leállás órákban méri a kárt.
A kiszolgáltatottság ezért üzemeltetési és nem jogi kérdés. A védelmet az adja, hogy minden fiók a Megrendelő nevére, a Megrendelő e-mail-címével és a Megrendelő bankkártyájával nyílik meg, a fejlesztő pedig meghívott, jogosultsággal rendelkező felhasználó — akit egyetlen kattintással el lehet távolítani, és aki távozáskor semmit nem visz magával, mert semmi nem az ő nevén állt. Ez nem szerződéses záradék, hanem regisztrációs sorrend kérdése, és a projekt első napján dől el.
A tizenkét tétel közül kilenc valóban fiók, amelynek tulajdonosa van. Három — az adatbázis és a mentése, az alkalmazáskulcsok írásos listája, valamint a telepítési leírás — nem áll senki nevén: ezek olyan átadandó anyagok, amelyeket a Megrendelőnek birtokolnia kell ahhoz, hogy a rendszer nélküle is elindítható legyen. A kettő ugyanazt a célt szolgálja, ezért kerül egy listára.
Egy pontosítás elöljáróban: az alábbi lista kizárólag hozzáférési kockázatot kezel. Nem ad teljes körű biztonságot, és nem garancia adatvesztés ellen. A rendszerbiztonság ennél lényegesen tágabb terület, a mentések helyreállíthatóságát pedig külön, próbával kell igazolni.
Nem az a kérdés, kié — hanem ki kapja a jelszó-visszaállító levelet
A tulajdonosi kérdést szóban nehéz tisztázni. Arra a kérdésre, hogy kié a domain, a jóhiszeműen adott válasz is lehet téves: a fejlesztő is úgy tudhatja, hogy a fiók az ügyfélé, miközben az évekkel korábban, egy gyors indulás kedvéért a saját e-mail-címére nyílt meg.
A gyakorlati teszt három jelből áll. Az első: kinek a postafiókjába érkezik a jelszó-visszaállító levél. A második: kinek a nevére és adószámára szól a szolgáltató számlája. A harmadik: van-e a cég oldalán legalább két, egymástól független adminisztrátori belépés, és hol tárolódnak a kétlépcsős azonosítás helyreállítási kódjai — ha ezek a fejlesztő telefonján vannak, akkor a fiók gyakorlatilag nála van. A három jel együtt tárgyi alapon eldönthetővé teszi, ki az érdemi tulajdonos, függetlenül attól, mit tartalmaz a projektdokumentáció.
Az első két jel a fejlesztő közreműködése nélkül is ellenőrizhető és dokumentálható: egy sikeres jelszó-visszaállítás és egy, a cég nevére kiállított szolgáltatói számla többet mond minden szóbeli megerősítésnél. A harmadik jel egyik fele — hány cégoldali adminisztrátori belépés létezik — szintén látszik a szolgáltató saját felületén. A helyreállítási kódok tényleges helyét viszont a Megrendelő önállóan nem tudja megállapítani: ezt írásban, az átadási jegyzékben kell tisztázni, majd a kódokat célszerű újragenerálni, és az új kódokat a cég saját jelszókezelőjébe tenni. Így a válasz nem szóbeli megerősítésen, hanem ellenőrizhető tényen nyugszik.
Az ellenőrzés eredményét célszerű rögzíteni. Elegendő egy táblázat tizenkét sorral: szolgáltató neve, a fiókhoz tartozó e-mail-cím, ki fér hozzá, mikor történt az utolsó ellenőrzés. Ennek negyedéves átnézése körülbelül fél óra, és ez az a fél óra, amely egy váratlan helyzetben a különbséget jelenti.
A tizenkét tétel és az ötperces ellenőrzés
A lista az üzemeltetési láncot követi: a névtől a futtatáson át az adatig és a működtető szolgáltatásokig. Minden sor önállóan ellenőrizhető, a legtöbb néhány perc alatt.
A táblázat után három tétel külön magyarázatot érdemel, mert ezeknél a tétel megnevezése és a tényleges hozzáférési helyzet eltérhet.
- Alkalmazáskulcsok: egy éles rendszerben jellemzően több külső szolgáltatás kulcsa fut egyszerre — térkép, számlázás, levélküldés, fizetés, tárolás. Ha ezekről nincs írásos lista, akkor a rendszer működése egyetlen ember emlékezetén nyugszik. A lista elkészítése néhány óra munka, és ettől kezdve egy kulcs pótlása vagy visszavonása nem függ attól, elérhető-e az, aki annak idején létrehozta.
- Adatbázis-mentés: a mentés léte és a mentés használhatósága két különböző állítás. Amíg nem történt legalább egy visszatöltés egy különálló környezetbe, addig a mentés csak feltételezés. A próbát érdemes félévente megismételni, a dátumot és a visszatöltés időtartamát pedig feljegyezni — utóbbi mutatja meg, mennyi a valós leállás egy éles helyreállításnál.
- Telepítési leírás: a mérce nem az, hogy a fejlesztő megérti-e, hanem az, hogy egy hozzáértő kívülálló a leírásból el tud-e indítani egy futó másolatot. Ha a szöveg olyan lépéseket említ, amelyek részletei csak beszélgetésből derülnek ki, akkor a leírás hiányos.
| Tétel | Ötperces ellenőrzés | Rendben, ha |
|---|---|---|
| 1. Domainregisztrátor | Belépés a regisztrátor felületére a cég e-mail-címével, jelszó-visszaállítással | A domain adatlapján a cég neve és adószáma szerepel regisztrálóként |
| 2. DNS-kezelés | A domain adatlapján látszik, mely névszerverek szolgálják ki, és a hozzájuk tartozó fiókba a cég be tud-e lépni | A DNS-rekordokat a cég önállóan tudja módosítani |
| 3. Tárhely- és felhőfiók | A szolgáltató felületén a számlázási adatok megnyitása | A számlák a cég nevére szólnak, a kártya a cégé |
| 4. Forráskódtároló | A tároló beállításainál a tulajdonos szervezet megtekintése | A tároló céges szervezet alatt van, két cégoldali tulajdonossal |
| 5. Adatbázis és mentése | A mentések listájának megnyitása: mikor készült az utolsó, hol tárolódik | Van napi mentés, és készült már sikeres visszatöltési próba |
| 6. TLS- (SSL-) tanúsítvány | A böngésző címsorában a lakat megnyitása: kibocsátó és lejárat | A megújítás automatikus, és a cég fiókjához kötött |
| 7. Alkalmazáskulcsok | A rendszer beállításfájljában vagy a szolgáltató felületén a kulcsok listázása | Létezik írásos lista arról, melyik kulcs melyik fiókban keletkezett |
| 8. E-mail-küldő szolgáltatás | Egy rendszerlevél feladójának és fejlécének megnyitása | A küldő fiók a cégé, a domain hitelesítése a cég DNS-ében van |
| 9. Számlázóprogram | Belépés a számlázó felületére cégoldali adminisztrátorként | Az integrációs kulcs a fejlesztő közreműködése nélkül visszavonható |
| 10. Felügyeleti eszközök | A hibanapló, az üzemidő-figyelő és az analitika riasztási címzettjeinek megnyitása | A riasztások cégoldali címre is megérkeznek |
| 11. Jelszókezelő | A megosztott széf bejegyzéseinek átnézése | A széf a cég tulajdona, a fejlesztő meghívott tagja |
| 12. Telepítési leírás | A leírás megnyitása és végigolvasása kívülállóként | Egy külső szakember el tudna indítani belőle egy másolatot |
Mibe kerül, ha egy tétel hiányzik
Az elvesztett hozzáférés ára gyakorlatilag az újraépítés ára. A nagyságrendek nyilvánosak: egy bemutatkozó weboldal 500 ezer forint, prémium kivitelben 2 millió forint, egy webshop 1,5 millió forinttól indul, egy egyedi belső rendszer 3 millió forinttól, egy egyedi ERP 30 millió forinttól. Ha a forráskód nem hozzáférhető, a pótlás nagyságrendileg ugyanezt az összeget jelenti, az adatok kimentése és átemelése pedig ezen felül jelentkezik — feltéve, hogy az adat egyáltalán elérhető marad.
A nagyobb rendszereknél az iparági arányok mutatják meg, hol van a valódi érték. A licencdíj a teljes ERP-költség 20–30 százaléka, a bevezetés a licencdíj 100–200 százaléka, az éves karbantartás pedig a licencdíj 15–22 százaléka. Vagyis maga a szoftver a teljes költségnek csak töredéke: az összeget a beállítás, a betanítás és az adat viszi. Éppen ezért drága, ha ez a három egyetlen külső fél kezében marad.
Az arányok egy levezetésen látszanak a legjobban. Tízmillió forintos licencdíj mellett a bevezetés 10–20 millió forint, az éves karbantartás 1,5–2,2 millió forint. Öt év teljes költsége tehát a licencdíj, a bevezetés és öt év karbantartása együtt: az olcsóbb ágon 10 + 10 + 7,5, a drágábbon 10 + 20 + 11 millió forint, vagyis 27,5–41 millió forint. A licencdíj aránya ebben 24 és 36 százalék között mozog. A 20–30 százalékos iparági hüvelykujjszabály tehát attól a ponttól teljesül, ahol az ötéves összköltség eléri a 33 millió forintot; az ennél olcsóbb bevezetés ágán a licencdíj aránya a sáv fölé kerül. A két számítás eltérése önmagában is tanulságos: az arányszám becslésre való, a tényleges összeget a bevezetés terjedelme dönti el. Amiben viszont mindkét ág megegyezik: a licencdíj a kisebbik tétel, a nagyobbikat — a bevezetést és a karbantartást — az adja, ami a szállítóhoz köt. Ilyen nagyságrend mellett a hozzáférési lista átnézésére fordított fél nap elhanyagolható ráfordítás, elmaradása viszont a teljes beruházást teszi függővé egyetlen szállítótól.
Maga az ellenőrzés ingyenes, a fenti táblázat végigvihető külső segítség nélkül. Ha mégis külső szem szükséges, egy weboldalaudit 200 ezer forint, a rendszer- és folyamataudit 300–500 ezer forint, és az audit díja beszámít a későbbi projekt árába. Folyamatos üzemeltetésnél — weboldal-karbantartás havi 30 ezer forint, rendszerüzemeltetés havi 100, 200, 300 vagy 600 ezer forint — érdemes szerződéskötéskor kikötni, hogy a havi díj tartalmazza a hozzáférési lista karbantartását és a mentés-visszatöltési próbát. Minden ár nettó.
Amikor nem érdemes fejlesztetni
A hozzáférési lista logikája ugyanoda vezet, mint minden józan beruházási döntés: az számít, mennyi munkát vált ki a rendszer, és ki tartja életben. Több helyzetben a helyes válasz az, hogy nem indul fejlesztés.
Egy számpélda arra, hogyan néz ki ez a mérlegelés. Egy folyamat automatizálása 500 ezer forint. Ha havi 20 munkaórát szabadít fel, és egy munkaóra teljes költsége 5 ezer forint, a megtakarítás havi 100 ezer forint, a megtérülés öt hónap — ez jó döntés. Ha ugyanez a folyamat havonta csak két órát érint, a megtakarítás havi 10 ezer forint, a megtérülés 50 hónap, vagyis több mint négy év. Ilyenkor a fejlesztés nem hibás, hanem fölösleges.
A hozzáférési szempont pedig egy további esetet is kizár: ha a cégen belül senki nem vállalja a fiókok gazdaszerepét, akkor a rendszer az átadás pillanatában gazdátlanná válik. Ezt a kérdést a fejlesztés megkezdése előtt kell rendezni, nem az átadáskor.
- Ha egy dobozos, előfizetéses szoftver a szükségletek 80 százalékát lefedi, és a maradék 20 százalék nem versenyelőny — a havi előfizetés töredéke az egyedi fejlesztésnek.
- Ha maga a folyamat nincs kitalálva: egy rossz folyamat automatizálva csak gyorsabban lesz rossz, és a hibák drágábban javíthatók.
- Ha a cég 6–12 hónapon belül átalakulás, tulajdonosváltás vagy profilváltás előtt áll — a követelmények menet közben elavulnak.
- Ha nincs kijelölt belső felelős, aki a fiókokat birtokolja és a szállítóval tartja a kapcsolatot — enélkül a legjobb rendszer is elszigetelődik.
- Ha az adat jelenleg is rendezetlen: az adattisztítás olcsóbb és hasznosabb első lépés, mint a fejlesztés.
A kilépési csomag négy eleme
Ha a fenti tizenkét tétel rendben van, akkor a kilépési csomag nem külön szolgáltatás, hanem a napi működés mellékterméke. Négy elemből áll, és bármikor előállítható.
Az első a futtatható forráskód: nem tömörített állomány egy levélben, hanem a cég saját tárolójában folyamatosan frissülő, teljes változat, a beállítási példafájlokkal együtt. A második a telepítési leírás, amely lépésről lépésre végigvezet egy üres környezetből egy futó rendszerig, és megnevezi a szükséges futtatókörnyezetet és külső szolgáltatásokat. A harmadik a hozzáférési lista: a tizenkét tétel aktuális állapota, szolgáltatóval, fiókcímmel és felelőssel. A negyedik az adatbázis-kivonat, friss dátummal, olyan formátumban, amely egy másik szolgáltatóhoz is betölthető.
Forráskódletétről vagy letéti megállapodásról csak akkor van értelme beszélni, ha ilyen megállapodás ténylegesen létrejött, aláírt formában, megnevezett letéteményessel. Enélkül az ígéret üres, és biztonságérzetet ad valódi fedezet helyett. A gyakorlatban egyszerűbb és olcsóbb megoldás, ha az anyagok eleve a Megrendelő fiókjaiban állnak, folyamatosan.
A jogi oldal külön szakértelmet igényel. Az, hogy a Megrendelő tulajdonjogot vagy felhasználási engedélyt szerez, milyen terjedelemben, továbbadható-e, és hogyan viszonyul mindez a rendszerben használt, harmadik féltől származó komponensek licencfeltételeihez, szerződéses kérdés. Ez a szöveg nem jogi tanács, és nem is adótanácsadás: a megfogalmazáshoz ügyvédi közreműködés szükséges, és ezt a lépést nem célszerű megspórolni egy több milliós beruházásnál.
Végül egy szokás, amely többet ér minden nyilatkozatnál: évente egyszer érdemes megkísérelni a rendszer elindítását a kilépési csomagból, a fejlesztő bevonása nélkül. Ha sikerül, a kockázat kezelve van. Ha nem, akkor pontosan kiderül, melyik sor hiányzik a tizenkettőből — és ez a legolcsóbb pillanat, amikor ez kiderülhet.
A lista szándékosan olyan, hogy külső segítség nélkül is végigvihető: egy délelőtt alatt kiderül, hol áll ma a felelősség. A Fabrio úgy dolgozik, hogy minden fiók a Megrendelő nevére nyílik meg, és az átadás után a rendszer futtatásához nem szükséges a fejlesztőt megkeresni; ha a meglévő működés átvilágításához külső szem kell, a rendszer- és folyamataudit erre való.