Audyt i Zgodność ILMT

Wiemy, jak wyglądają audyty IBM od środka. Pomagamy się do nich przygotować — albo przejść przez nie z jak najmniejszym ryzykiem.

Jak naprawdę wygląda audyt licencji IBM?

Pewnego dnia przychodzi pismo. Nadawca: IBM lub firma audytorska działająca w ich imieniu — najczęściej Deloitte, PwC albo KPMG. Treść jest uprzejma, ale jednoznaczna: IBM realizuje przysługujące mu prawo do weryfikacji zgodności licencyjnej. Macie 90 dni na dostarczenie danych.

Audytor żąda raportów z ILMT, listy wszystkich serwerów z oprogramowaniem IBM, dokumentacji licencyjnej (Proof of Entitlement) i dowodów na ciągłość raportowania za ostatnie dwa lata. Sprawdza pokrycie agentami, aktualność software catalog, poprawność reguł bundlingu i czy raporty nie mają przerw. Każda luka w danych to argument za naliczeniem opłat za pełną pojemność serwerów (full capacity) zamiast faktycznego zużycia (sub-capacity).

Różnica potrafi być ogromna. Firma z 200 serwerami, która płaci za sub-capacity, może nagle otrzymać roszczenie liczone w milionach złotych — bo 30 serwerów nie miało agentów przez pół roku.

Problem w tym, że większość firm dowiaduje się o stanie swoich danych ILMT dopiero w momencie audytu. Agenty przestały raportować po migracji. Software catalog nie rozpoznaje nowej wersji produktu. Raporty generowane raz na kwartał nie były nigdy analizowane. To typowe scenariusze — i każdy z nich oznacza kłopoty.

Co robimy — konkretnie

Przegląd przed audytem

Robimy dokładnie to, co zrobi audytor — tylko wcześniej i po Waszej stronie. Sprawdzamy pokrycie agentami na wszystkich serwerach (fizycznych i wirtualnych), weryfikujemy ciągłość raportowania, przeglądamy software catalog pod kątem nierozpoznanych sygnatur i analizujemy historię danych za ostatnie 2 lata. Efekt to lista konkretnych problemów z priorytetami: co naprawić natychmiast, co wymaga planowania, a co można wyjaśnić dokumentacją.

Analiza luk w zgodności

Porównujemy dane z ILMT z faktycznym stanem infrastruktury i posiadanymi uprawnieniami licencyjnymi (PoE). Szukamy serwerów bez agentów, produktów wykrywanych nieprawidłowo, błędnych reguł bundlingu i rozbieżności między raportowanym zużyciem a konfiguracją procesorów. Uczciwie — przegląd zgodności może ujawnić, że firma ma zobowiązania wobec IBM. Ale lepiej dowiedzieć się o tym samemu niż podczas audytu.

Weryfikacja raportów ILMT

Raporty ILMT to dokument, który trafia bezpośrednio do audytora. Sprawdzamy, czy wartości PVU odpowiadają konfiguracji procesorów w tabelach IBM PVU, czy bundling jest poprawnie ustawiony (np. WebSphere z Db2, MQ z Integration Bus), czy nie ma fałszywych detekcji i czy peak values mają sens w kontekście Waszej architektury wirtualizacji. Jeden błędnie skonfigurowany bundling potrafi zawyżyć raportowane zużycie o dziesiątki procent — albo, co gorsza, je zaniżyć.

Wsparcie w trakcie audytu

Audytorzy z Deloitte czy PwC wiedzą, jakie pytania zadawać i jak interpretować odpowiedzi. Uczestniczymy w spotkaniach jako niezależni doradcy techniczni — pomagamy przygotowywać odpowiedzi, pilnujemy, żeby nie dostarczać więcej danych niż wymagane, i wyjaśniamy kontekst techniczny, który audytor mógłby zinterpretować na niekorzyść firmy. To nie jest kwestia ukrywania czegokolwiek — chodzi o precyzyjną komunikację.

Nie jesteście pewni, jak wygląda Wasza pozycja licencyjna?

Porozmawiajmy. Krótka rozmowa wystarczy, żeby ocenić, czy Wasze dane ILMT wytrzymałyby weryfikację audytora. Bez zobowiązań.

Umów bezpłatną konsultację

Kiedy warto zrobić przegląd?

Najlepsza odpowiedź: zanim będzie pilnie potrzebny. Ale w praktyce firmy zgłaszają się w kilku typowych sytuacjach:

  • Pismo od IBM już przyszło — albo słyszycie, że audyty IBM nasiliły się w Waszym regionie. W takim przypadku liczy się czas. IBM daje 90 dni, ale logistyka i naprawy zjadają ten czas szybciej niż myślicie.
  • Duże zmiany w infrastrukturze — migracja na VMware, przeniesienie workloadów do chmury, konsolidacja data center. Każda taka zmiana może sprawić, że agenty ILMT przestaną raportować lub dane stracą spójność. Jeden klient po migracji na nowy klaster VMware stracił raportowanie z 40 serwerów na trzy miesiące — i nie zauważył tego do momentu audytu.
  • Renegocjacja umów z IBM — jeśli rozmawiacie o odnowieniu licencji, rzetelne dane o faktycznym zużyciu to Wasza najlepsza karta przetargowa. Bez nich negocjujecie na ślepo.
  • Nikt tego nie sprawdzał od ponad roku — jeśli ILMT "po prostu działa w tle" i nikt regularnie nie weryfikuje raportów, to jest właśnie moment, żeby to zrobić. Problemy narastają po cichu.

Tak to wygląda w praktyce

Nie pracujemy z checklistami. Każde środowisko jest inne — inna wirtualizacja, inne produkty IBM, inna historia zmian. Zaczynamy od danych: logujemy się do ILMT, przeglądamy konfigurację serwera, logi agentów, historię raportów i software catalog. Szukamy tego, czego szukałby audytor.

Pracujemy zdalnie, przez VPN lub dedykowany dostęp. Typowy przegląd trwa dwa do czterech tygodni — krócej przy mniejszych środowiskach, dłużej jeśli są poważne problemy do naprawy.

Na koniec dostajecie raport, który ma konkretną wartość: lista znalezionych problemów, rekomendacje naprawcze z priorytetami i ocena ryzyka licencyjnego. Dokument, który możecie wykorzystać wewnętrznie, a w razie audytu — jako dowód, że proaktywnie dbacie o zgodność.

Najczęściej zadawane pytania

Jak w praktyce wygląda audyt licencji IBM?

IBM wysyła oficjalne pismo z żądaniem audytu i wyznacza firmę audytorską — najczęściej Deloitte, PwC lub KPMG. Od momentu otrzymania pisma macie zazwyczaj 90 dni na dostarczenie danych. Audytor żąda raportów z ILMT, listy serwerów, dokumentacji licencyjnej i dowodów na ciągłość raportowania. Sprawdza pokrycie agentami, aktualność software catalog i czy raporty nie mają przerw. Każda luka w danych to argument za naliczeniem opłat za pełną pojemność serwerów zamiast sub-capacity.

Dlatego przygotowanie zaczynamy od pełnego przeglądu danych w ILMT — weryfikujemy te same elementy, które sprawdzi audytor, i pomagamy zamknąć luki zanim ktokolwiek ich szuka.

Ile czasu potrzeba na przygotowanie się do audytu IBM?

Realistycznie — od dwóch do sześciu tygodni, w zależności od wielkości środowiska i stanu danych. Jeśli macie 50 serwerów z aktualnymi agentami, dwie-trzy tygodnie mogą wystarczyć. Przy kilkuset serwerach, problemach z pokryciem agentami i nieaktualnym software catalog — potrzeba więcej czasu.

IBM daje standardowo 90 dni od pisma, ale część tego czasu zjada sama logistyka. Najgorsze, co można zrobić, to zacząć naprawiać dane po otrzymaniu pisma — audytor widzi daty zmian i wie, co było łatane na ostatnią chwilę.

Czy sam ILMT wystarczy, żeby obronić się przed roszczeniami IBM?

ILMT jest warunkiem koniecznym, ale nie wystarczającym. IBM wymaga go do korzystania z licencjonowania sub-capacity — bez ILMT automatycznie płacicie za pełną pojemność. Ale samo posiadanie ILMT to dopiero początek. Dane muszą być kompletne i ciągłe — agenty muszą raportować bez przerw, software catalog musi rozpoznawać Wasze produkty, a raporty muszą pokrywać się z faktycznym stanem infrastruktury.

Widzieliśmy przypadki, gdzie ILMT działał, ale 15% serwerów nie miało agentów. Audytor potraktował te serwery jako full capacity i naliczył różnicę.

Czy wspieracie klientów w trakcie samego audytu IBM?

Tak, i szczerze mówiąc — to często jest moment, kiedy nasza pomoc jest najbardziej potrzebna. Audytorzy z firm takich jak Deloitte czy PwC znają ILMT od podszewki i wiedzą, jakie pytania zadawać. Uczestniczymy w spotkaniach jako niezależni doradcy techniczni, pomagamy interpretować żądania dotyczące danych i przygotowujemy odpowiedzi.

Kluczowe jest to, żeby nie dostarczać więcej danych niż wymagane i żeby każda odpowiedź była technicznie precyzyjna. Jeden źle sformułowany e-mail potrafi otworzyć audytorowi nową ścieżkę dochodzenia.

Lepiej wiedzieć wcześniej niż dowiedzieć się od audytora

Niezależni specjaliści, bez powiązań z IBM. Mówimy wprost — nawet jeśli wnioski nie są wygodne. Bo o to właśnie chodzi.

Umów bezpłatną konsultację