Grudzień, ostatnie tygodnie przed zamknięciem roku fiskalnego. Email od account managera Microsoft: “Przypominam o zbliżającym się true-up. Proszę o przesłanie aktualnych danych użycia do 15 stycznia.” IT manager otwiera Excel z licencjami - ostatnio aktualizowany 8 miesięcy temu. Próbuje policzyć: ile mamy użytkowników Office 365? Ile serwerów Windows? Ile Core SQL Server? Panika narasta. Deadline za 3 tygodnie.
Przeczytaj także
- Audyt Oracle 2026: Jak przygotować firmę na weryfikację licencyjną?
- Audyty licencyjne Microsoft 2026: Co oznacza koniec zniżek wolumenowych dla Twojej firmy
- AI i automatyzacja w SAM: jak inteligentne zarządzanie licencjami może obniżyć twoje koszty IT o 30%?
Historia powtarza się w tysiącach firm co roku. True-up - roczne rozliczenie wykorzystania licencji w ramach umów Enterprise Agreement (Microsoft) czy Unlimited License Agreement (Oracle) - to moment prawdy. I dla wielu firm to moment drogiej prawdy. Badania Flexera pokazują, że przeciętne przedsiębiorstwo przepłaca na true-up średnio 340,000 PLN rocznie z powodu złego przygotowania, overcounting i braku optymalizacji.
Czym jest true-up i dlaczego firmy regularnie na nim tracą?
True-up to mechanizm w umowach Enterprise, który pozwala firmie rozpocząć korzystanie z dodatkowych licencji w trakcie roku, płacąc za nie dopiero przy rocznym rozliczeniu. W teorii - elastyczność biznesowa. W praktyce - pułapka dla nieprzygotowanych.
Microsoft Enterprise Agreement z true-up działa tak: na początku umowy deklarujesz baseline liczby użytkowników/urządzeń/core. W trakcie roku możesz dodawać więcej. Na koniec roku (anniversary date) raportujesz faktyczne użycie - i płacisz za przyrost. Problemy zaczynają się, gdy nie wiesz ile faktycznie używasz.
Oracle Unlimited License Agreement (ULA) to inna bestia. Przez okres umowy (zazwyczaj 3-5 lat) możesz deployować nielimitowane ilości określonych produktów. Na koniec ULA “certyfikujesz” ile deployowałeś - i ta liczba staje się Twoim perpetual entitlement. Undercounting = tracisz licencje, za które zapłaciłeś. Overcounting = płacisz support od zawyżonej bazy.
Dlaczego firmy tracą? Po pierwsze: brak visibility. Nie wiedzą ile naprawdę mają użytkowników, instalacji, core. Shadow IT, niezarządzane deployments, legacy systemy - to wszystko wymiyka się ewidencji. Po drugie: złe timing. Optymalizacja na tydzień przed deadline to za późno - decyzje o wyłączeniu systemów wymagają czasu.
Po trzecie: asymetria informacji. Vendor wie więcej o swoich produktach i licensing rules niż Ty. Account manager jest zmotywowany do maksymalizacji sprzedaży. Bez ekspertyzy SAM, negocjujesz z zamkniętymi oczami. Po czwarte: strach przed niedoliczeniem. Lepiej przepłacić niż ryzykować audit - myśli IT manager. I płaci za licencje, których nie potrzebuje.
Jak wygląda cykl przygotowania do true-up i kiedy zacząć?
Przygotowanie do true-up nie zaczyna się w grudniu - zaczyna się w styczniu. Albo, realnie, powinno być continuous practice przez cały rok. Ale jeśli nie robiliście tego wcześniej, minimum 3 miesiące przed anniversary date to absolutne minimum.
Miesiąc -6 do -3: Discovery i baseline. Zinwentaryzuj wszystkie aktywa - serwery, urządzenia, użytkownicy, aplikacje. Porównaj z posiadanymi entitlements. Zidentyfikuj gaps i overcounts. To wymaga narzędzi (SCCM, ServiceNow, Flexera) i czasu na konfigurację i zebranie danych.
Miesiąc -3 do -2: Analysis i optimization. Przeanalizuj wyniki discovery. Które licencje są niewykorzystywane? Które deployment można zkonsolidować? Które użytkownicy mają za wysokie tier licencji? Opracuj plan optymalizacji i execution timeline.
Miesiąc -2 do -1: Execution optymalizacji. Wyłącz nieużywane serwery, zdecommissionuj legacy, przepnij użytkowników na niższe tiery gdzie uzasadnione, zwirtualizuj gdzie opłacalne. Zmiany muszą być dokonane PRZED true-up date, żeby były uwzględnione.
Miesiąc -1 do 0: Finalizacja i raport. Ostateczne zliczenie, przygotowanie raportu dla vendora, review z prawnikiem/SAM expertem, przygotowanie do negocjacji. Bufor na unexpected issues.
Po true-up: Negocjacje i future planning. True-up to też moment na renegocjację warunków, dodanie produktów, zmianę struktury umowy. Wykorzystaj dane zebrane w procesie.
Jak przeprowadzić skuteczny discovery licencji Microsoft przed true-up?
Microsoft licensing jest notoryczne złożone - różne produkty, różne metryki (per user, per device, per core), różne edycje (Standard, Enterprise, Premium). Discovery musi uwzględnić wszystkie te wymiary.
Active Directory jako źródło prawdy o użytkownikach - ale tylko częściowej. AD pokazuje wszystkich użytkowników, ale nie wszystkich użytkowników AD potrzebujesz licencjonować. Service accounts, inactive users, terminated employees, external guests - wszystko wymaga klasyfikacji.
Azure AD i Microsoft 365 Admin Center dla cloud subscriptions. Ile masz licencji Office 365 E3, E5, F3? Ile jest assigned vs. available? Ile użytkowników jest “active” (logowało się w ostatnich 30 dniach)? Inactive licenses to opportunity do downgrade lub usunięcia.
System Center Configuration Manager (SCCM) lub Intune dla endpoint discovery. Ile urządzeń ma zainstalowany Windows Enterprise (a ile Pro wystarczy)? Ile ma Office lokalnie (a może można przenieść na web-only)? Ile ma aplikacje wymagające CAL?
SQL Server discovery to osobne wyzwanie. Ile instancji? Ile cores na każdej? Edycja (Standard, Enterprise)? Features używane? SQL licensing jest notoriously expensive - difference między proper i improper sizing to setki tysięcy złotych. SQL Assessment Tools od Microsoft pomagają.
Virtualization host licensing dla Windows Server i SQL wymaga zrozumienia reguł. Windows Server 2022 w Datacenter edition licencjonuje wszystkie VM na hoście. Standard - tylko 2 VM per 2-socket host. SQL w virtual wymaga liczenia fizycznych cores hosta, nie VM. Błędy tu są kosztowne.
Jak przeprowadzić skuteczny discovery licencji Oracle przed true-up ULA?
Oracle licensing jest jeszcze bardziej skomplikowane niż Microsoft - i Oracle jest znacznie bardziej agresywne w audytach. ULA certification to moment, gdy precyzja jest krytyczna - overcounting oznacza wyższy support na zawsze, undercounting oznacza compliance risk.
Oracle LMS (License Management Services) scripts są standardem do inventory Oracle databases. Uruchom je na wszystkich serwerach - fizycznych i wirtualnych. Output pokazuje: editions, features używane, processor type i count. Ale uwaga: scripts czasem overcountują.
Named User Plus (NUP) vs. Processor licensing - musisz wiedzieć który model masz w ULA i jak liczyć. NUP wymaga policzenia użytkowników z dostępem (bezpośrednim i pośrednim). Processor wymaga policzenia fizycznych cores (z processor multiplier factor zależnym od CPU type).
Enterprise features activation check. Oracle Database Enterprise Edition ma wiele optional features (Partitioning, RAC, Advanced Compression) - każda osobno licencjonowana. Nawet jeśli feature jest włączony ale nieużywany - Oracle twierdzi, że potrzebujesz licencji. Sprawdź DBA_FEATURE_USAGE_STATISTICS i wyłącz co niepotrzebne PRZED certification.
Virtualization complexity - Oracle nie uznaje soft partitioning (VMware, Hyper-V). Jeśli Oracle DB działa na VM, musisz licencjonować wszystkie physical cores w klastrze, do którego VM może migrować. Wyjątek: hard partitioning (Oracle VM, Solaris Zones, IBM LPAR z DLPAR disabled). To często szokuje firmy przy certification.
Cloud i outsourcing - czy masz Oracle w AWS, Azure, GCP? Czy outsourcer używa Oracle w Twoim imieniu? ULA może nie pokrywać tych scenariuszy - sprawdź termy umowy. Oracle Authorized Cloud Environments mają specjalne zasady.
Jakie optymalizacje można zrobić przed true-up, żeby zmniejszyć koszt?
User cleanup - usunięcie nieaktywnych użytkowników. Pracownik odszedł 6 miesięcy temu, ale nadal ma licencję Office 365? Usuń. Service account ma pełną licencję E5, gdy potrzebuje tylko Exchange? Downgrade. External guest ma licencję, gdy wystarczyłoby free tier? Zmień.
Tier optimization - dopasowanie licencji do potrzeb. Czy każdy użytkownik naprawdę potrzebuje E5 (najdroższej) czy wystarczy E3 lub E1? Czy każdy serwer SQL potrzebuje Enterprise czy wystarczy Standard? Analiza feature usage ujawnia overtier-ing, który jest często znaczący.
Server consolidation i decommission. Stary serwer, który “jeszcze działa” ale nikt nie wie po co - wyłącz przed true-up. VM, który był “temporary” 2 lata temu - czy nadal jest potrzebny? Test environment działający 24/7 zamiast on-demand - zmień model.
Edition downgrade gdzie możliwe. Windows Server Datacenter na hoście z 3 VM? Standard (z 2 licencjami) byłby tańszy. SQL Enterprise używany tylko do podstawowych operacji? Standard może wystarczyć (z ograniczeniami RAM i cores, ale dla wielu workloads OK).
True virtualization optimization. Przegrupowanie VM na fewer physical hosts może zmniejszyć licensing footprint. Ale wymaga coordination z operations - nie rób tego na deadline.
Hybrid benefit i license mobility. Jeśli masz on-premise licencje z Software Assurance, możesz użyć ich w Azure zamiast płacić za included licenses. Upewnij się, że wykorzystujesz te opcje przed true-up cloud subscriptions.
Jak negocjować z vendorem przy true-up?
Przygotowanie danych jest negocjacyjną bronią. Jeśli wiesz dokładnie ile masz i potrzebujesz - negocjujesz z pozycji siły. Jeśli nie wiesz - przyjmujesz co vendor powie. Vendor zazwyczaj wie więcej o Twoim środowisku niż Ty (przez telemetrię) - wyrównaj tę asymetrię.
Timing leverage. True-up to nie tylko moment płacenia - to moment renegocjacji. Umowa EA może być przedłużona, zmieniona, rozszerzona. Vendor chce Twojego biznesu na kolejne 3 lata. Wykorzystaj to: “rozważamy alternatywy” (nawet jeśli nie rozważasz poważnie) daje leverage.
Bundle negotiation. Zamiast płacić za individual products, może korzystniejszy jest bundle (Microsoft 365 zamiast osobno Office + EMS + Windows)? Może dodatkowe produkty w pakiecie za marginalny koszt? Vendor woli sprzedać bundle niż stracić całość.
Multi-year commitment za lepszą cenę. Jeśli jesteś pewien że zostaniesz z vendorem - dłuższa umowa może mieć lepsze terms. Ale uwaga: lock-in na 5 lat to też ryzyko (jeśli technologia się zmieni).
Realne alternatywy wzmacniają pozycję. Migration do Google Workspace, Linux, open source - czy to realna opcja? Jeśli tak, wspomnienie o tym zmienia dynamikę rozmowy. “Analizujemy TCO alternatyw” to signal, że nie jesteś captive customer.
Avoid paying for shelfware. Jeśli produkty w EA nie są używane - nie odnawiaj ich. “Ale mamy package deal” - może, ale może da się renegocjować package bez unused components. Account manager ma flexibility, której nie pokaże bez pytania.
Jakie są najczęstsze błędy przy true-up i jak ich uniknąć?
Last-minute panic counting. Na tydzień przed deadline próba policzenia wszystkiego - niedokładnie, pośpiesznie, z błędami. W stresie overcountujesz (bo lepiej przepłacić niż ryzykować). Rozwiązanie: start early, continuous tracking.
Counting virtual cores instead of physical. Microsoft i Oracle w większości przypadków liczą fizyczne cores hostów, nie virtualne. Jeden VM z 4 vCPU na 24-core serwerze wymaga licencji na 24 cores (z pewnymi wyjątkami). Ten błąd kosztuje fortunę.
Ignoring SAM tools output. Masz ServiceNow czy Flexera, ale raporty są stare, niekompletne, nieużywane. Narzędzie jest tak dobre jak dane w nim - wymaga maintenance i trust w output.
Not understanding licensing rules. “Myślałem że tak to działa” - famous last words. Licensing rules Microsoft i Oracle wypełniają tomy i zmieniają się co roku. Bez eksperta SAM, prawdopodobnie źle interpretujesz.
Forgetting about edge cases. Disaster recovery site - wymaga licencji (z wyjątkami). Dev/test environments - wymagają licencji (ale mogą mieć specjalne programs). External users accessing internal systems - mogą wymagać External Connector lub per-user licensing. Edge cases są drogie.
Not negotiating at all. Przyjęcie pierwszej liczby od vendora bez dyskusji. Account manager podał estimate - nie musisz go akceptować bez weryfikacji. True-up to negotiation, nie invoice do zapłaty.
Jak wygląda proces certification dla Oracle ULA i jakie są pułapki?
ULA certification to formalny proces na koniec Unlimited License Agreement, w którym deklarujesz ile deployowałeś produktów. Ta deklaracja staje się Twoim perpetual entitlement - błąd jest trudny do skorygowania później.
Timeline certification: zazwyczaj 30-45 dni przed końcem ULA musisz złożyć certification notice. Potem 30 dni na zebranie danych i przygotowanie raportu. Oracle ma prawo weryfikacji (quasi-audit). Po zaakceptowaniu - perpetual licenses są wydane.
Undercounting risk - jeśli zadeklarujesz mniej niż faktycznie masz deployowane, po ULA masz compliance gap. Oracle może auditować po zakończeniu ULA i zażądać zakupu brakujących licencji po list price. Defense jest trudna.
Overcounting risk - jeśli zadeklarujesz więcej niż faktycznie potrzebujesz, płacisz support od wyższej bazy. Support to ~22% rocznie od license value - overcounting o 20% to 4.4% extra cost rocznie, na zawsze.
Virtual deployment sprawia najwięcej problemów. Jeśli Oracle DB działa na VMware, musisz policzyć wszystkie physical cores w całym klastrze (nie tylko VM cores). Firmy często są w szoku gdy to odkrywają. Solutions: hard partitioning, dedicated hosts, lub akceptacja higher count.
Feature usage audit. Oracle może kwestionować Twój count jeśli scripts pokazują feature usage, której nie certyfikujesz. Wyłącz niewykorzystywane features PRZED certyfikacją, udokumentuj że zostały wyłączone.
Rozważenie ULA renewal vs. certification. Czasem lepiej jest extend ULA o kolejne 3-5 lat zamiast certyfikować - jeśli planujesz dalszy growth, jeśli certification count jest bardzo wysoki, jeśli warunki nowej ULA są korzystne. To strategiczna decyzja.
Jaką rolę pełni profesjonalny SAM w procesie true-up?
Inventory i discovery expertise. SAM specjaliści wiedzą jak skonfigurować i interpretować narzędzia discovery. Wiedzą jakie raporty generować, jakie dane są potrzebne, jak klasyfikować edge cases. Bez tej ekspertyzy, DIY discovery jest podatne na błędy.
Licensing rules expertise. Microsoft licensing: PUR (Product Use Rights), SPUR (Services PUR), Product Terms - setki stron, zmieniające się. Oracle licensing: własne zasady, processor factors, named user minimums. SAM konsultant zna te reguły i ich interpretację.
Optimization identification. Doświadczony SAM widzi opportunities, które IT pomija. “Tu możesz przenieść workload i zaoszczędzić 50%”, “Ten deployment nie wymaga Enterprise”, “Ta konfiguracja jest licencjonowana suboptymally”. Fresh eyes + expertise = found savings.
Negotiation support. SAM może uczestniczyć w negocjacjach z vendorem jako Twój advisor. Zna market rates, zna typowe concessions, wie jakie argumenty działają. Poziomuje pole gry z account managerem, który ma lata doświadczenia w selling.
Audit defense preparation. True-up data może być później wykorzystana w audycie. SAM dba, żeby dokumentacja była kompletna, defensible, zgodna z best practices. Jeśli audit przyjdzie - jesteś przygotowany.
Long-term SAM practice establishment. True-up to nie jednorazowy event - powinien być częścią continuous SAM practice. SAM pomoże ustanowić procesy, narzędzia, governance na cały rok, nie tylko przed deadline.
Tabela: True-up preparation checklist
| Obszar | Działanie | Timeline | Owner | Status |
|---|---|---|---|---|
| Discovery | Uruchomienie inventory tools | M-6 | IT Ops | ⬜ |
| AD user extraction i klasyfikacja | M-5 | Identity team | ⬜ | |
| Server inventory (physical + virtual) | M-5 | IT Ops | ⬜ | |
| Cloud subscription audit | M-5 | Cloud team | ⬜ | |
| Database discovery (SQL/Oracle) | M-4 | DBA | ⬜ | |
| Analysis | Entitlement vs. deployment comparison | M-3 | SAM | ⬜ |
| Optimization opportunities identified | M-3 | SAM | ⬜ | |
| Cost impact analysis | M-3 | Finance + SAM | ⬜ | |
| Optimization | Inactive user removal | M-2 | IT Ops + HR | ⬜ |
| License tier optimization | M-2 | IT Ops | ⬜ | |
| Server decommission/consolidation | M-2 | IT Ops | ⬜ | |
| Feature/edition downgrade | M-2 | DBA + IT Ops | ⬜ | |
| Preparation | Final count validation | M-1 | SAM | ⬜ |
| Report preparation | M-1 | SAM | ⬜ | |
| Legal review (jeśli needed) | M-1 | Legal | ⬜ | |
| Negotiation strategy | M-1 | IT + Procurement | ⬜ | |
| Execution | Report submission | M-0 | SAM | ⬜ |
| Negotiation meetings | M-0 | IT + Procurement | ⬜ | |
| Sign-off i payment | M-0 | Finance | ⬜ | |
| Post | Documentation i archiving | M+1 | SAM | ⬜ |
| Lessons learned | M+1 | All | ⬜ | |
| Next year planning | M+1 | SAM | ⬜ |
True-up to moment, w którym lata (lub brak) SAM practice widać w twardych liczbach na fakturze. Firmy przygotowane płacą za to, czego potrzebują. Firmy nieprzygotowane płacą za chaos, błędy i brak optymalizacji - często setki tysięcy złotych więcej niż muszą.
Kluczowe wnioski:
- Przygotowanie do true-up to proces całoroczny, nie last-minute sprint
- Discovery wymaga narzędzi, czasu i ekspertyzy - nie zgaduj, mierz
- Optymalizacja przed deadline wymaga execution time - zacznij minimum 3 miesiące przed
- Negocjacje są możliwe - nie przyjmuj pierwszej liczby od vendora
- Oracle ULA certification to moment, który definiuje koszty na lata
- Profesjonalny SAM płaci się sam wielokrotnie w znalezionych oszczędnościach
True-up nie musi być stresujący. Z odpowiednim przygotowaniem staje się rutynową operacją, która potwierdza że masz kontrolę nad swoimi licencjami - nie odwrotnie.
ARDURA Consulting specjalizuje się w Software Asset Management i wsparciu klientów przez procesy true-up Microsoft, Oracle i innych vendorów. Nasze audyty przed true-up regularnie identyfikują oszczędności rzędu setek tysięcy złotych. Skontaktuj się z nami minimum 3 miesiące przed Twoim anniversary date.