Przygotowanie do audytu licencji IBM: co musisz wiedzieć

Co powoduje audyt licencji IBM?

Pierwsza i najważniejsza rzecz do zrozumienia: IBM ma umowne prawo do audytu każdego klienta Passport Advantage w dowolnym momencie. To prawo jest wpisane w samą umowę Passport Advantage, w sekcji zwykle zatytułowanej „Weryfikacja" lub „Prawa audytowe". Podpisując Passport Advantage, wyraziłeś na to zgodę. Każdy klient IBM to zrobił.

Nie oznacza to jednak, że IBM audytuje wszystkich co roku. Mają ograniczone zasoby audytowe, więc ustalają priorytety. Choć IBM nie publikuje kryteriów wyboru, na podstawie naszego doświadczenia w pomaganiu klientom wyłaniają się pewne wzorce.

Losowy wybór jest realny. IBM prowadzi rotację i niektóre audyty to po prostu Twój numer w kolejce. Nie mogłeś temu zapobiec i nie zrobiłeś nic, co to spowodowało. Po prostu tak się dzieje.

Fuzje i przejęcia to częsty wyzwalacz. Kiedy dwie firmy się łączą, ich pozycje licencyjne IBM muszą zostać uzgodnione. IBM wie o takich wydarzeniach (są publiczne) i często wszczyna audyty w trakcie lub krótko po okresie integracji. To również czas, gdy zgodność licencyjna jest najbardziej narażona na naruszenie, bo zespoły infrastrukturalne konsolidują środowiska, a śledzenie licencji zwykle traci na znaczeniu.

Znaczące zmiany w strukturze wydatków na IBM mogą przyciągnąć uwagę. Jeśli Twoje odnowienia Passport Advantage systematycznie maleją, IBM może chcieć zweryfikować, czy spadek wydatków odpowiada rzeczywistemu zmniejszeniu użytkowania. I odwrotnie, jeśli kupujesz bardzo mało nowych licencji przy dużej bazie zainstalowanego oprogramowania, to również może skłonić do przeglądu.

Informacje od byłych pracowników lub partnerów biznesowych zdarzają się rzadko, ale jednak się zdarzają. Ktoś, kto wie, że Twoje środowisko IBM jest niedolicencjonowane, kontaktuje się z IBM i to rozpoczyna dochodzenie.

Prawda jest taka: nie możesz zapobiec audytowi. Możesz się tylko przygotować. Traktowanie gotowości audytowej jako stałej praktyki, a nie gorączki po otrzymaniu pisma, to najlepsza rzecz, jaką możesz zrobić dla swojej organizacji.

Harmonogram audytu IBM

Zrozumienie harmonogramu pomaga zaplanować odpowiedź i zarządzać oczekiwaniami wewnątrz organizacji. Audyty IBM przebiegają według dość przewidywalnego procesu, choć czas trwania bywa różny.

Pismo audytowe. Otrzymasz formalne powiadomienie, zwykle mailem do głównego kontaktu Passport Advantage, a czasem listem poleconym. Pismo stwierdza, że IBM korzysta z prawa audytu wynikającego z umowy. Wskazuje firmę audytorską. W Europie najczęstszym audytorem jest Deloitte, który od lat prowadzi większość zleceń IBM w tym regionie. KPMG oraz, rzadziej, inne firmy pojawiają się przy niektórych zleceniach. PwC w audytach IBM to rzadkość. Jeśli pismo wskazuje firmę, której się nie spodziewałeś, to i tak jest to legalny, autoryzowany przez IBM proces. Zweryfikuj zlecenie przez swojego przedstawiciela IBM, ale nie traktuj samego wyboru audytora jako nietypowego. W Ameryce Północnej IBM czasem korzysta z własnego zespołu License Compliance lub angażuje podobne firmy. Pismo określa zakres audytu (które produkty, jaki okres) i proponuje początkowe spotkanie w celu omówienia procesu.

Początkowe spotkanie i zapotrzebowanie na dane. W ciągu pierwszych dwóch do czterech tygodni odbędzie się rozmowa telefoniczna lub spotkanie z zespołem audytowym. Wyjaśnią proces, przekażą formalną listę wymaganych danych i ustalą harmonogram ich dostarczenia. Początkowe Data Request Letter zwykle wymaga odpowiedzi w ciągu 30 do 45 dni. Rozszerzenie do około 90 dni jest częste, jeśli poprosisz wcześnie, a audyt przebiega w trybie współpracy. Audytorzy zwykle wolą czyste dane z opóźnieniem niż bałagan na czas. Potraktuj pierwszą datę jako pozycję negocjacyjną, a nie twardy deadline, ale od razu zacznij pracę wewnętrzną. Spalisz więcej czasu, niż się spodziewasz, szukając dokumentów PoE i uzgadniając dane z ILMT.

Zbieranie i przekazywanie danych. Tu zaczyna się prawdziwa praca. Gromadzisz wymagane raporty ILMT, dokumentację uprawnień, dane infrastrukturalne i wszystko inne z listy. Jakość i kompletność przekazanych danych determinuje przebieg reszty audytu. Co dokładnie wymagają audytorzy, opisujemy w następnej sekcji.

Faza analizy. Firma audytorska analizuje Twoje dane. Może to trwać od jednego do trzech miesięcy w zależności od złożoności środowiska. W tym czasie mogą wrócić z dodatkowymi pytaniami lub prośbami o uzupełnienie danych. Odpowiadaj szybko i precyzyjnie. Opóźnienia z Twojej strony wydłużają cały harmonogram audytu.

Wstępne ustalenia. Audytorzy przedstawiają początkowe wyniki. Ten dokument wymienia wszelkie rozbieżności między Twoimi uprawnieniami licencyjnymi a faktycznym wdrożeniem oprogramowania. Ważne jest zrozumienie, że wstępne ustalenia to punkt wyjścia do dyskusji, a nie końcowa faktura. O negocjacjach powiemy później.

Rozwiązanie. Analizujesz ustalenia, zgłaszasz zastrzeżenia, dostarczasz dodatkowe dowody w razie potrzeby i pracujesz nad rozwiązaniem. Może to obejmować zakup dodatkowych licencji, zaakceptowanie kwoty ugody lub wykazanie, że ustalenia audytora były nieprawidłowe. Faza rozwiązania może trwać od kilku tygodni do kilku miesięcy.

Cały proces, od pierwszego pisma do ostatecznego rozwiązania, trwa zwykle od 3 do 12 miesięcy. Złożone audyty obejmujące wiele produktów, duże środowiska lub znaczne luki w zgodności mogą trwać ponad rok.

Czego faktycznie wymagają audytorzy

Wiedza o tym, jakie dokładnie dokumenty i dane audytorzy będą wymagać, pozwala przygotować się z wyprzedzeniem. Oto typowa lista wymaganych danych, oparta na audytach, w których uczestniczyliśmy.

Raporty Audit Snapshot z ILMT. To główny dowód Twojej pozycji licencyjnej sub-capacity. Audytorzy oczekują raportów Audit Snapshot pokrywających cały badany okres, czyli zwykle cały okres raportowania sub-capacity od ostatniego audytu lub ostatnie dwa do trzech lat. Każdy snapshot powinien być kompletnym eksportem z serwera ILMT, nie filtrowanym ani częściowym raportem. Snapshoty zawierają identyfikację produktów, zużycie PVU, inwentarz serwerów i dane topologii wirtualizacji.

Dokumenty uprawnień Passport Advantage. To Twoje dokumenty Proof of Entitlement (PoE). Pokazują, jakie licencje na oprogramowanie IBM faktycznie posiadasz, w jakich ilościach i od kiedy. Audytorzy porównają dane z ILMT o wykorzystaniu z dokumentami PoE potwierdzającymi uprawnienia. Jeśli nie jesteś w stanie dostarczyć dokumentów PoE, audytorzy będą pracować na podstawie własnych danych IBM, które mogą nie odzwierciedlać wszystkich Twoich zakupów (szczególnie jeśli część licencji została nabyta od stron trzecich lub od poprzedników w ramach fuzji).

Dokumentacja infrastruktury. Audytorzy chcą zrozumieć Twoją infrastrukturę fizyczną i wirtualną. Obejmuje to inwentarze sprzętu serwerowego, eksporty z VMware vCenter pokazujące mapowania VM-host i alokacje zasobów, dane HMC dla środowisk Power Systems oraz dane konfiguracyjne hostów Hyper-V. Używają ich do weryfikacji krzyżowej z raportami ILMT. Jeśli ILMT pokazuje maszynę wirtualną na hoście z 20 rdzeniami, a eksport vCenter pokazuje 40 rdzeni, audytor użyje wyższej liczby.

Szczegóły konfiguracji wirtualizacji. Poza podstawową topologią audytorzy mogą zapytać o szczegółowe ustawienia wirtualizacji. Dla VMware oznacza to konfiguracje klastrów vCenter, ustawienia pul zasobów, reguły DRS i konfiguracje CPU affinity. Dla PowerVM chcą konfigurację LPAR, ustawienia współdzielonych pul procesorów i informacje o cappingu. Te szczegóły decydują o tym, czy maszyna wirtualna kwalifikuje się do licencjonowania sub-capacity, czy musi być liczona przy pełnej pojemności.

Informacje organizacyjne i umowne. Audytorzy mogą zażądać listy wszystkich podmiotów prawnych objętych umową Passport Advantage, relacji między spółkami zależnymi oraz szczegółów dotyczących fuzji lub przejęć w badanym okresie. Licencjonowanie IBM jest powiązane z podmiotami prawnymi, a produkty używane przez podmiot nieobjęty umową tworzą ekspozycję na niezgodność.

Lista kontrolna danych ILMT

Dane z ILMT to fundament Twojej obrony podczas audytu. Jeśli są czyste, spójne i kompletne, audyt jest do opanowania. Jeśli nie, zaczynasz z pozycji słabości. Oto co „czyste dane" oznaczają w praktyce.

Pokrycie agentami musi być kompletne. Każdy serwer w Twoim środowisku z oprogramowaniem IBM potrzebuje agenta BigFix, który aktywnie raportuje do instancji ILMT. Dotyczy to środowisk produkcyjnych, deweloperskich, testowych, stagingowych, disaster recovery i szkoleniowych. Obejmuje serwery fizyczne, maszyny wirtualne i partycje LPAR. Jeśli audytor odkryje oprogramowanie IBM na serwerze, o którym ILMT nie wie, całe wdrożenie oprogramowania na tym serwerze staje się ustaleniem audytowym. Wykonaj porównanie inwentarza serwerów (z CMDB, Active Directory lub inwentarza VMware) z listą endpointów ILMT. Wszelkie rozbieżności muszą być rozwiązane przed audytem.

Ciągłość raportowania nie może mieć przerw. ILMT musi działać nieprzerwanie przez cały badany okres. Przerwy w raportowaniu oznaczają przerwy w dowodach sub-capacity. Sprawdź dane ILMT pod kątem okresów, w których liczba raportujących agentów znacząco spadła, serwer ILMT był wyłączony lub importy danych się nie powiodły. Nawet kilka dni brakujących danych może być problematyczne, jeśli przypadają na czas zmian w środowisku (nowe serwery, migracje maszyn wirtualnych lub zwiększenie pojemności).

Katalog oprogramowania musi być aktualny. ILMT identyfikuje produkty IBM dopasowując zainstalowane pliki do katalogu oprogramowania. Jeśli katalog jest nieaktualny, ILMT może nie rozpoznać nowszych wersji produktów lub nieprawidłowo je zaklasyfikować. Sprawdź wersję katalogu w ustawieniach ILMT i porównaj ją z najnowszą dostępną od IBM. Jeśli jesteś o więcej niż jedną wersję w tyle, zaktualizuj natychmiast.

Reguły bundlingu muszą być prawidłowe. Produkty IBM często zawierają uprawnienia do innych produktów. WebSphere Application Server Network Deployment obejmuje ograniczoną licencję na IBM HTTP Server. DB2 Enterprise Server Edition zawiera kilka narzędzi DB2. Jeśli reguły bundlingu w ILMT nie odzwierciedlają Twoich rzeczywistych uprawnień, raporty będą zawyżać zużycie licencji. Przejrzyj konfigurację bundlingu w odniesieniu do uprawnień Passport Advantage i skoryguj wszelkie niezgodności.

Dane wirtualizacyjne muszą być kompletne. Połączenia VM Managera w ILMT muszą działać i być aktualne. Sprawdź, czy każdy klaster VMware jest połączony przez vCenter, każde środowisko PowerVM jest połączone przez HMC, a każdy host Hyper-V ma aktywnego agenta BigFix. Brakujące dane wirtualizacyjne oznaczają, że ILMT nie może obliczyć wartości sub-capacity dla dotkniętych maszyn wirtualnych, a audytor zastosuje kalkulacje pełnej pojemności.

90-dniowy termin wdrożenia musi być weryfikowalny. Klienci sub-capacity mają obowiązek wdrożyć zatwierdzone narzędzie (ILMT, BigFix Inventory lub jedną z opcji Flexera) w ciągu 90 dni od pierwszego uruchomienia produktu kwalifikującego się w środowisku wirtualnym. Jeśli audytor zapyta, kiedy wdrożyłeś ILMT, a odpowiedź brzmi „rok po tym, jak produkt już działał", ta luka jest liczona przy pełnej pojemności. Przechowuj daty wdrożeń udokumentowane w miejscu, które łatwo znajdziesz, a nie tylko w głowie osoby, która robiła instalację.

Audit snapshoty muszą sięgać co najmniej dwóch lat wstecz. Warunki sub-capacity IBM wymagają zachowania audit snapshotów przez minimum dwa lata. Jeśli generujesz raporty kwartalnie i trzymasz je przez dwa lata, jesteś zgodny. Jeśli masz tylko ostatnie pół roku, masz lukę za wcześniejszy okres, a audytor może zaliczyć te miesiące jako full capacity. Przestrzeń dyskowa jest tania, archiwizuj snapshoty.

Co idzie nie tak podczas audytów

Na podstawie naszego doświadczenia w pomaganiu organizacjom podczas audytów IBM, oto problemy, które powodują największe straty finansowe.

Luki w danych ILMT i przejście na pełną pojemność

To najdroższy problem, jaki spotykamy. Gdy dane ILMT mają przerwy, czy to z powodu wyłączenia serwera, braku raportowania agentów czy nieudanych importów danych, IBM może traktować te okresy tak, jakby dowody sub-capacity nie istniały. Oznacza to kalkulacje pełnej pojemności. Dla środowiska VMware nawet ze skromną liczbą hostów różnica między sub-capacity a pełną pojemnością może być ogromna. Pracowaliśmy z organizacją, w której trzymiesięczna przerwa ILMT podczas migracji serwera zaowocowała wstępnymi ustaleniami przekraczającymi 400 000 euro. Rzeczywiste zużycie sub-capacity w tym okresie byłoby ułamkiem tej kwoty, ale bez danych ILMT nie było sposobu, żeby to udowodnić.

Nieprawidłowy bundling zawyża wartości PVU

Gdy reguły bundlingu w ILMT nie odpowiadają rzeczywistym uprawnieniom Passport Advantage, raporty pokazują wyższe zużycie PVU niż w rzeczywistości. Produkty, które powinny być objęte pakietem, są liczone jako oddzielne instalacje. To zawyża pozorne zużycie licencji, a podczas audytu daje audytorowi większą lukę zgodności na starcie. Można wprawdzie poprawić bundling w trakcie audytu, dostarczając dokumentację uprawnień, ale znacznie lepiej mieć czyste raporty od początku. Audytorzy bardziej ufają danym, które były konsekwentnie dokładne, niż danym korygowanym po tym, jak zaczęli je analizować.

Brak serwerów deweloperskich i testowych

Środowiska deweloperskie i testowe są często pomijane we wdrożeniach ILMT. Logika jest zrozumiała, ale błędna: „to tylko serwer testowy, nie liczy się". Warunki licencyjne IBM obejmują wszystkie środowiska. Jeśli deweloper zainstalował DB2 na testowej maszynie wirtualnej w ramach weryfikacji koncepcji, ta instalacja wymaga licencji. Jeśli ta maszyna wirtualna nie ma agenta BigFix, ILMT jej nie widzi. Ale audytor, który przejrzy inwentarz vCenter lub Active Directory, ją znajdzie. A koszt licencji za oprogramowanie, które ILMT pominął, jest zawsze naliczany przy pełnej pojemności, bo nie ma danych sub-capacity wspierających niższą kalkulację.

Nieaktualny katalog oprogramowania pomija produkty

Gdy katalog oprogramowania ILMT nie jest na bieżąco aktualizowany, nowsze wersje produktów IBM mogą nie być rozpoznawane. Produkty są nadal zainstalowane i działają, ale ILMT ich nie raportuje. To tworzy fałszywe poczucie zgodności. Twoje raporty ILMT wyglądają czysto, ale analiza audytora, która korzysta z aktualnego katalogu IBM, identyfikuje produkty, które Twoje raporty pominęły. Rezultatem są ustalenia audytowe za produkty, o których istnieniu nawet nie wiedziałeś, liczone przy pełnej pojemności, bo ILMT nie ma dla nich historycznych danych.

Jak odpowiedzieć na pismo audytowe

Otrzymałeś pismo. IBM korzysta z prawa audytu. Oto co zrobić, krok po kroku, na podstawie tego, co widzieliśmy w praktyce.

Nie panikuj. Pismo audytowe to nie pozew. To nie oskarżenie. To IBM korzystający z umownego prawa, na które każdy klient Passport Advantage wyraził zgodę. Weź głęboki oddech i podejdź do tego metodycznie.

Nie spiesz się. Instynkt, żeby natychmiast odpowiedzieć i dostarczyć wszystko naraz, jest naturalny, ale kontrproduktywny. Masz czas. Początkowy termin dostarczenia danych to zwykle 90 dni, a przedłużenia są negocjowalne. Wykorzystaj ten czas na odpowiednie przygotowanie zamiast wysyłać niekompletne lub niedokładne dane pod presją.

Skompletuj zespół. Potrzebujesz kogoś, kto rozumie dane ILMT (administrator ILMT lub zespół BigFix), kogoś, kto zarządza uprawnieniami IBM (dział zakupów lub zarządzanie dostawcami) i kogoś, kto skoordynuje odpowiedź (często kierownik IT lub lider ds. zgodności). Jeśli nikt w zespole nie przechodził wcześniej audytu IBM, to jest moment, żeby rozważyć zaangażowanie zewnętrznej pomocy od kogoś, kto ma to doświadczenie.

Przejrzyj dane ILMT przed wysłaniem. Wygeneruj świeże raporty Audit Snapshot, przejrzyj je pod kątem kompletności, sprawdź pokrycie agentami, zweryfikuj połączenia VM Managera i napraw oczywiste problemy. Dane, które wysyłasz, muszą być możliwie czyste i dokładne. Pierwsze wrażenie ma znaczenie. Audytor, który od początku otrzymuje dobrze zorganizowane, kompletne dane, podejdzie do audytu inaczej niż ten, który dostanie chaotyczne, niekompletne materiały.

Dostarczaj dokładnie to, o co proszą. Odpowiedz na zapotrzebowanie na dane kompletnie, ale precyzyjnie. Nie udostępniaj dodatkowych informacji, o które nie proszono. Każdy element danych, który wyślesz, staje się częścią analizy audytora. Jeśli wyślesz kompletny inwentarz serwerów obejmujący 200 maszyn, a ILMT pokrywa tylko 150, właśnie zidentyfikowałeś 50 serwerów wymagających dalszego dochodzenia. Wysyłaj tylko to, co określono w zapotrzebowaniu.

Dokumentuj wszystko. Rejestruj każdą komunikację, każde przekazanie danych, każde spotkanie i każde pytanie uzupełniające. Jeśli audyt wejdzie w fazę negocjacji, jasna dokumentacja Twojej współpracy i jakości danych jest cenna.

Czy można negocjować ustalenia audytowe?

Tak, częściej, niż organizacje się spodziewają, ale w granicach rozsądku. Rzeczy, które możesz negocjować, to rozbieżności metodologiczne, liczenie produktów w pakietach, kolejność przypisywania licencji oraz sposób strukturyzacji ugody. Rzeczy, których zasadniczo nie wynegocjujesz, to twarde luki w danych ILMT, brakujące wdrożenia lub instalacje oprogramowania, których narzędzie nigdy nie zobaczyło. Ustalenie poparte dowodem trudno zepchnąć bez własnego dowodu. Im wcześniej zaangażujesz się w negocjacje, zanim wstępne ustalenia zostaną sfinalizowane, tym więcej jest pola manewru.

Dokument wstępnych ustaleń nie jest końcowym rachunkiem. To początkowa ocena firmy audytorskiej oparta na analizie Twoich danych. To punkt wyjścia do dyskusji, a audytorzy oczekują, że go przejrzysz i wrócisz z pytaniami, poprawkami i kontrargumentami.

Typowe obszary negocjacji obejmują następujące kwestie.

Rozbieżności metodologiczne. Sposób, w jaki audytor obliczył zużycie PVU, może nie zgadzać się z opisem kalkulacji w dokumentacji IBM. Jeśli potrafisz wykazać, że audytor zastosował niewłaściwą wartość PVU do typu procesora, użył błędnych liczb rdzeni lub nieprawidłowo obliczył wartości sub-capacity, te ustalenia powinny być skorygowane. Widzieliśmy przypadki, gdy firma audytorska użyła nieaktualnej tabeli PVU lub błędnie zidentyfikowała architekturę procesora, co skutkowało zawyżonymi kalkulacjami PVU skorygowanymi podczas przeglądu.

Kwestie bundlingu produktów. Audytorzy czasem liczą produkty jako samodzielne instalacje, podczas gdy są one objęte pakietem lub włączone w uprawnienia innego produktu. Jeśli Twoja umowa Passport Advantage obejmuje WebSphere Application Server Network Deployment, instancje IBM HTTP Server na tych samych maszynach są objęte. Jeśli audytor policzył je osobno, to jest korekta, którą powinieneś zgłosić.

Kalkulacja efektywnej pozycji licencyjnej. Sposób przypisywania uprawnień do zużycia może znacząco zmienić wynik. Kolejność, w jakiej produkty są dopasowywane do uprawnień, czy częściowe pokrycie z jednego uprawnienia może być łączne z częściowym pokryciem z innego, i jak historyczne uprawnienia mają zastosowanie do bieżącego użytkowania to obszary, w których rozsądni ludzie mogą się nie zgadzać. Kwestionuj kalkulacje, które nie odzwierciedlają Twojej faktycznej pozycji licencyjnej.

Kredyty remediacyjne. W wielu przypadkach negocjacje dotyczą nie tylko wysokości ustaleń, ale sposobu ich rozwiązania. IBM może zaproponować zaliczenie kwoty ugody jako kredytu na przyszłe zakupy. Jeśli Twoja organizacja i tak planowała odnowienie lub rozszerzenie portfolio IBM, ugoda zorganizowana jako zobowiązanie zakupowe może być łatwiejsza do zaakceptowania niż samodzielna opłata za niezgodność.

Kluczem jest konstruktywne zaangażowanie. Audytorzy dobrze reagują na organizacje, które starannie analizują ustalenia, przedstawiają jasne dowody na poparcie swojego stanowiska i negocjują profesjonalnie. Źle reagują na organizacje, które ignorują ustalenia, odmawiają współpracy lub wysuwają argumenty bez dowodów. Przygotuj się, trzymaj się faktów i traktuj proces jako negocjacje biznesowe, a nie konfrontację.

Najczęściej zadawane pytania