Kevés dolog van, ami annyira el tudja rontani a napunkat, mint amikor auditálni jelentkezik az egyik gyártónk. Annak ellenére, hogy ez szerződésbe épített joga a szoftvert kibocsátó cégnek, mégis úgy vagyunk vele, mint a lyukas foggal: bármikor történik, az a legrosszabb időpont.
Pánikra azért nincs ok: ugyan szorít az idő, és ez behatárolja a lehetőségeinket, de végső soron ez az időszak pontosan arra való, hogy megfelelően felkészüljünk az auditor fogadására.
Egy tipikus licencszerződés szerint az előzetes írásos értesítést követően 30-45 nap múlva kell beengedni a gyártót vagy megbízott auditorát, hogy megvizsgálja a felhasználásunkat. Ennyi időnk van felkészülni arra, hogy az ellenőrt a lehető legpontosabb információkkal lássuk el a jelenlegi állapotról, hogy a megfelelő reakcióidővel tudjunk adatokat szolgáltatni.
A felkészülés és maga az audit időszaka is nagyon más élményt jelenthet attól függően, hogy milyen szinten foglalkozunk szoftvergazdálkodással.
Azok számára, akik ezt még nem kezdték el, vagy a folyamat elején járnak, túlórázással és idegeskedéssel terhes időszak következik. Rengeteg kérdés és megoldandó feladat merül fel. Milyen terhelésre és időtartamra lehet számítani? Mely termékeket fognak egyáltalán vizsgálni? Milyen pontossággal tudjuk, vagy sejtjük, hogy mit használunk? Van-e rálátásunk minden telepítésre? Egy vagy több területhez tartoznak ezek a szoftverek? Kik üzemeltetik? Tudjuk, hogy milyen licencekkel lehet lefedni azt, amit használunk? Mire van egyáltalán licencünk? Milyen nagyságrendben mozoghat a hiány, ha van? Hogyan kéne felkészülni az auditra? A sok munka ellenére jellemző érzés, hogy a kérdések csak újabb kérdéseket szülnek, és nem jutunk érezhetően megnyugtatóbb eredményre; a bizonytalanság szintje folyamatosan magas.
Azok számára, akik már korábban sok munkát fektettek a területbe, és előrébb tartanak a szoftvergazdálkodásban, szintén sok feladattal jár a felkészülés. A különbség ott van, hogy egészen más feladatok és problémák foglalkoztatják őket, mivel a kirakós (leg)több darabja már a helyén van. A befektetett munka eredményeként a fennmaradó teendők, amelyekkel ők foglalkozhatnak, már a licencelés és az auditálás finomabb részleteit ölelik fel. Mekkora változás volt a legutóbbi felmérés óta? Vannak-e eddig ismeretlen licencelési csapdák? Lesz-e egyáltalán nem tervezett kiadásunk? Milyen értelmezési vitákra számíthatunk? Előre hozzuk-e a tervezett infrastruktúra átalakítást vagy egyéb beruházást? Mennyi lesz az adatszolgáltatás költsége? Hogyan tudjuk a napi működést legkevésbé zavaróan végezni a felkészülést és az adatszolgáltatást, kell-e hangolnunk az ütemterven?
Az érettebb szoftvergazdálkodási gyakorlat természetesen nemcsak az audit folyamatában nyújt határozott előnyöket, hanem a végeredmény szempontjából is minőségi különbséget jelent. Az sem elhanyagolható helyzeti előny, hogy az információigény kiszolgálása egyenletesebb terheléssel teljesíthető, kevésbé zavarja meg a szokásos működést, és kisebb anyagi ráfordítást jelent.
Az első lépés: Felderítő Fázis ? ekkor határozhatjuk meg, kedvezőbb esetben pontosíthatjuk, hogy:
- mekkora az adott gyártó lábnyoma a cégünkben
- pontosan milyen termékeit és funkciókat használunk
- közülük melyek tartoznak az audit hatókörébe
- hol és milyen mértékben használjuk azokat
- az észlelhető felhasználás mennyire egyezik a szándékolt felhasználásunkkal.
A felhasználás 80 százalékát könnyű meghatározni, ezek a fősodorba tartozó, nyilvántartott, ismert elemek. A maradék 20 százalék már nehezebb dió. Minél tagoltabb a szervezet, annál több olyan szervezeti és infrastrukturális zseb, zug, ahol valami váratlanra lelhetünk. A leállítottnak mondott, de még ketyegő archivált rendszer jó példák erre. Drága lehet, ha engedjük, hogy ezekre legyintsünk, mert az ilyen ?az csak?? rendszerek az auditorokat nagyon érdeklik majd.
Amikor előállnak a nyers adatok, jöhet a Kiértékelési Fázis. Ki kell deríteni, hogy az azonosított felhasználást milyen licencekkel lehet legjobban lefedni, és össze kell vetni a licencleltárral. Könnyen gondolhatjuk azt, hogy ez a feladat könnyű része, de a licenctételek nevei és a csomagok tartalmának gyors változása nem könnyíti meg a feladatot. Sokszor jelent kihívást a szoftverben megjelenő funkciók megfeleltetése a termékek kereskedelmi elnevezésével. Emellett ne számítsunk arra, hogy a gyártó auditora a vizsgálat során a licencek kiosztása mellett ingyen el fogja végezni helyettünk annak optimalizációját is: ő a legkisebb erőfeszítéssel előállítható kiosztásra fog törekedni, aminél könnyen lehet ideálisabb megoldás is, és az is előfordul, hogy hibás eredményre jutnak, aminek költségét a végfelhasználó viseli, ha nem figyel eléggé.
Ha kiderül, miből van hiány, és milyen értékben, akkor következik a pénzügyi előkészítő fázis. A várható hiány nagyságrendje irányadó lesz abban, hogy milyen szintű döntés, illetve támogatás szükséges a megoldáshoz. Mivel a szoftverek árazása globális vagy regionális, nem veszik figyelembe a hazai vásárlóerőt, illetve az előállítható értéket, így nem csoda, ha sokan sarcnak, büntetésnek, lehúzásnak élik meg az auditokat, miközben nemzetközi összehasonlításban eleve erőn felül költenek ezekre a termékekre. A gyártói megállapítások így fájdalmasan belevághatnak, vagy akár meg is haladhatják a forrásgazda éves keretszámait. A hiányok rendezése így gyakran tervezett fejlesztések elhalasztásával, vagy törlésével is együtt jár, ami akkor különösen pikáns, ha egy másik gyártót célzó költségcsökkentő projekt esik áldozatul.
Szoftvergazdálkodással nem, vagy induló szinten foglalkozó szervezetek számára az audit által kikényszerített önvizsgálat lehetőséget teremt arra, hogy a szándékolt felhasználást tisztábban lássuk, és sok olyan szunnyadó fejlesztési ötlet tör ilyenkor felszínre, amelyek egyébként sokkal később, vagy egyáltalán nem valósulnának meg. Az elképzelések tisztázása nem csak általánosságban véve hasznos; a vizsgálatot záró kereskedelmi fázisban a jövőkép és a hozzá vezető lépések befolyásolhatják a rendezés módját.
A fenti folyamat ideális esetben saját szándékból és jóval az audit értesítés előtt kezdődik. A feladat időtartamát a szervezeti adottságok és a szóban forgó szoftvergyártó(k) is erősen befolyásolják, de egy nagyobb szervezetnél 12 hónappal érdemes számolni ? ne felejtsük el, hogy a résztvevők számára a munkaidejüket már kitöltő feladatokhoz teszünk hozzá. Emellett sok olyan, a napi rutinon kívül eső adatot, információt kell kinyerniük és összegyűjteniük, amelyek előállítása nem, vagy kevéssé automatizálható, illetve kutatást igényel. A szükséges ráfordítások alulbecslése éppoly általános, mint a hiányoké. Infrastrukturális változtatási igények esetén az időtáv megnő, könnyen átcsúszik a 12-24 hónapos sávba.
Persze sosem tudhatjuk, éppen mennyivel vagyunk az audit előtt, de akinek ez a kérdés, és nem az, hogy mit tegyen a hiányok megelőzéséért, annak biztosan ketyeg az óra!
