A Gartner felmérése szerint az utóbbi években megnőtt a gyártói szoftverlicen-auditok száma, így ugyanis két legyet üthetnek egy csapásra a fejlesztőcégek. Az átvilágítási folyamat nem csak licencbevételeikre van pozitív hatással, hanem egyúttal a (nagy)vállalati "szoftverkalózkodás" mértékét is vissza tudja szorítani. Szoftvergazdálkodási (Software Asset Management, SAM) eszközökkel azonban minimalizálható az ebből származó nem kívánt kiadás, relatíve egyszerűen betarthatók lesznek a megfelelőségi (compliance) szabályok.

Változó licencelési modellek

A feladat megkönnyítését nagyban elősegíti, ha ezen a téren is folyamatos és magától értetődő az informatikai és a gazdasági osztályok közötti párbeszéd. Ennek révén lesz gazdasági szempontból is nyomon követhető a szoftverek életciklusa, a beszerzéstől egészen a használatból való kivonásig. Fontos tisztában lenni azzal, milyen szoftverlicencet vásárolt meg a vállalat, a használati szabályokhoz képest hogyan alkalmazzák azt, milyen lehetőségek vannak az eszközök közötti átjárhatóságra, és persze az sem árt, ha a vásárlás mellékleteként csatolt pénzügyi/jogi dokumentumok is rendelkezésre állnak.

Ugyanakkor nem teszi egyszerűvé a szoftvergazdálkodás kezelését a licencelési modellek változása – a processzorra, processzormagra, minimális felhasználószámra (NUP) stb. lebontott struktúrák heterogén környezetben akár szoftverenként különböző számítási módszerek alkalmazását igényelhetik. Ezt képes bonyolítja tovább a virtualizáció és a cloud computing alkalmazása.

Könnyen belátható tehát, hogy az informatikai döntéshozók közel sincsenek egyszerű helyzetben ezen a téren (sem). A licencszabályok gyakori változásai, kiegészítve a szoftvergazdálkodási és -ellenőrzési eszközök hiányával, figyelmet érdemlő pénzügyi kockázatot jelent a vállalatok számára. Egy gyártói audit viszonylag könnyen és gyorsan rávilágít ezekre a hiányosságokra.

Mi váltja ki a jogtulajdonosok figyelmét?

A meteorológiai előrejelzésekkel analóg módon a gyártók is olyan mintákat keresnek a termékeiket használók szoftveres történetében, melyek megléte esetén sokkal hajlamosabbak auditot kezdeményezni. Számos ilyen jel létezik, lássunk néhány példát!

Egy fúzió vagy felvásárlás önmagában is akkora feladatot ad az érintettek számára, hogy azzal kisebb-nagyobb döccenők nélkül megbirkózni csak nagyon alapos tervezéssel lehet. Különösen igaz ez a szoftverlicenc-használatra: a felek használta szellemi tulajdonok transzfere és konszolidációja gyakran nem megfelelő mértékű, ha egyáltalán sor kerül rá. Nem ritka, hogy az üzleti egyesülést követően nem (megfelelően) rendeződik a gyártói compliance kérdése, ez pedig előszeretettel váltja ki a szoftverfejlesztő vállalatok figyelmét.

Egy lépéssel tovább menve újabb figyelmeztető jelzés bukkan fel: az adott cég akvizíciós története és hivatalos üzleti adatai közötti korrelációt szintén előszeretettel vizsgálják a szoftvergyártók. Könnyen belátható, ha a használt licencek száma nem, vagy nem megfelelő mértékben bővül a pozitív gazdasági események (cégérték-növekedés, az alkalmazotti létszám bővülése stb.) tekintetében, akkor okkal feltételezhető, hogy az adott vállalat elmaradóban van a használt szoftverek szellemi tulajdonjogának pénzügyi ellentételezésével.

De ugyanilyen kiváltó okot jelent a gyártók számára, ha más szoftverfejlesztők fontosnak tartották a célkeresztben levő cég auditját, vagy, ha a korábban használt licencszerződéseket nem újítják meg. Utóbbi helyzetben persze lehet szó más gyártók termékeinek alkalmazására való áttérésről, de a gyakorlat azt mutatja, hogy még ilyen esetekben is könnyen kimutatható némi elmaradás a licencdíjak kiegyenlítésében (ami pedig máris magával vonhat némi büntetésfizetési kötelezettségét).

Kicsit vagy nagyon fog fájni?

Ha sor kerül rá, kétféle átvilágítással kell szembenéznie az érintetteknek. "Puha audit" esetén könnyebb a dolga az azon áteső vállalatnak: leltárt kell készíteni a használt licencekről, melyet aztán el kell küldeni a kíváncsi gyártó számára. Ezen utóbbi kockázatelemzést végez többek között a fent említett kritériumok alapján, majd döntést hoz a mélyebb vizsgálat szükségességéről.

Egy fokkal bonyolultabb (és költségesebb) a helyzet akkor, ha "kemény auditra" kerül sor. Ezt nem az érintett cég, hanem minősített – a gyártó érdekeinek képviseletében cselekvő – auditor végzi. Jogi lehetősége van megvizsgálni a licenchasználati bizonyítékokat, helyszíni technikai ellenőrzéseket végezhet, az eredményeket pedig természetesen közli a szoftvergyártóval.

Jellemzően öt felvonásból áll ez az eljárás, melyet egy projektindító megbeszélés vezet fel. Ennek során az auditor képviselői felvázolják a folyamat egyes fázisait és egyeztetik időbeli lefolyását a vizsgálandó céggel. Ezt követi az adatgyűjtés: az auditor számára biztosítani kell a felmérés véghezviteléhez szükséges informatikai infrastruktúra leírását, például az eszközök hardveres konfigurációját, az azokra telepített alkalmazások és a vele dolgozó alkalmazottak listáját, és a licencfizetés bizonyítékait.

Onsite visit névre hallgat a harmadik fázis, melynek során az auditor képviselői fizikai valójukban is felkeresik a cégek telephelyeit, irodáit a számukra korábban átadott információk valóságtartalmának ellenőrzése és további adatgyűjtés céljából. Ezek alapján jön létre a jelentéstervezet, melyet ellenőrzés végett elküldenek az auditon átesett cégnek.

A folyamatot egy virtuális vagy a helyszínen történő, az összes érintett fél részvételével zajló megbeszélés zárja, ahol az auditor bemutatja végső jelentését és megválaszolja az azt érintő kérdéseket. A következtetések pénzügyi és jogi vonzatainak megtárgyalását a szoftvergyártó és a vizsgálaton átesett cég képviselői folytatják le.