Całkowity koszt posiadania oprogramowania obronnego: przewodnik zakupowy

Program obronny zaplanował budżet w wysokości 2,4 mln euro na platformę świadomości sytuacyjnej. Dwa lata po wdrożeniu łączne wydatki wynoszą 6,1 mln euro. Różnica – 3,7 mln euro – nie figurowała w żadnej linii budżetowej. Narosła na skutek nakładów na integrację, rotacji szkoleń, trzech cykli ponownej akredytacji bezpieczeństwa, dużej migracji wersji i zastrzeżonej warstwy oprogramowania pośredniego, której dostawca wymagał, lecz nigdy nie ujawnił w wstępnej ofercie.

Ten wzorzec jest na tyle powszechny, że można go uznać za strukturalny, a nie przypadkowy. Całkowity koszt posiadania (TCO) oprogramowania obronnego jest systematycznie i niekiedy drastycznie niedoszacowywany na etapie zamówienia – nie dlatego, że oficerowie ds. zamówień są niedbali, lecz dlatego, że model kosztów stosowany w momencie nabycia jest z założenia niepełny. Niniejszy przewodnik dostarcza ram do budowania wiarygodnego szacunku TCO przed udzieleniem zamówienia.

Dlaczego TCO oprogramowania obronnego jest systematycznie niedoszacowywany

W komercyjnych zamówieniach oprogramowania koszt nabycia i TCO są na tyle zbliżone, że używanie jednego jako przybliżenia drugiego jest uzasadnione. Środowisko integracji jest względnie standardowe, baza szkoleniowa to ogólna siła robocza, a cykl utrzymania podąża przewidywalnymi normami komercyjnymi.

Zamówienia obronne funkcjonują w odmiennym środowisku pod każdym z tych względów. Warstwa integracji łączy się z sieciami niejawnymi, zastrzeżonymi wojskowymi formatami danych i dziesięcioletnimi starszymi systemami, które powstały przed erą nowoczesnych konwencji API. Baza szkoleniowa składa się z operatorów wojskowych o określonych profilach ról i wysokiej rocznej rotacji. Proces utrzymania obejmuje ponowną akredytację bezpieczeństwa przed wdrożeniem jakiejkolwiek łatki w systemie niejawnym – proces, który dodaje tygodnie lub miesiące do każdego cyklu aktualizacji.

Strukturalnie problem jest pogłębiany przez sposób organizacji budżetów obronnych. Koszt nabycia pojawia się w budżecie zamówień. Nakłady na integrację – w budżecie inżynieryjnym biura programowego. Szkolenia – w alokacji szkoleniowej jednostki. Podtrzymanie – w wieloletniej linii utrzymania, negocjowanej oddzielnie od umowy wstępnej. Żaden właściciel budżetu nie ma wglądu we wszystkie cztery kategorie. W rezultacie dostawcy konsekwentnie wygrywają na niskim koszcie nabycia, a marżę odrabiają na kosztach, których nikt nie zabudżetował.

Pięć składników TCO i sposób ich ważenia

Kompletny model TCO oprogramowania obronnego obejmuje pięć kategorii kosztów. Ich względny udział różni się zależnie od programu, jednak poniższy rozkład odzwierciedla typowe 10-letnie programy obserwowane w europejskich zamówieniach obronnych:

Koszt nabycia (15–25% TCO w perspektywie 10 lat)

To liczba z oferty dostawcy: opłaty licencyjne, subskrypcyjne, per użytkownik i jednorazowe opłaty konfiguracyjne. Dla licencji wieczystych jest to w dużej mierze koszt roku pierwszego. Dla modeli subskrypcyjnych należy prognozować roczną opłatę naprzód z zastosowaniem umownego pułapu podwyżek dostawcy – zazwyczaj 3–8% rocznie dla oprogramowania obronnego – i zdyskontować do wartości bieżącej na przestrzeni życia programu.

Zwróć uwagę na ceny per użytkownik, które skalują się w nieoczekiwany sposób. Platforma wyceniona na 40 000 euro rocznie dla 50 użytkowników może osiągnąć 320 000 euro rocznie, jeśli program rozszerzy się do 400 użytkowników w koalicji. Modeluj realistyczny pułap użytkowników, a nie liczbę pilotażowego wdrożenia.

Koszt integracji (25–35% TCO w perspektywie 10 lat)

Integracja jest największym pojedynczym źródłem niedoszacowania TCO w programach obronnych. Obejmuje nakłady pracy i infrastrukturę potrzebną do podłączenia nowego oprogramowania do istniejącego środowiska operacyjnego: systemów C2, strumieni sensorowych, baz danych wywiadowczych, platform logistycznych, zarządzania tożsamością i infrastruktury sieciowej.

Integracja obronna nie jest pracą towarową. Każdy punkt połączenia wymaga niestandardowej transformacji danych (wojskowe formaty danych nie są przyjazne dla REST), mediacji warstwy bezpieczeństwa (każde połączenie przekraczające granicę klasyfikacji wymaga kryptograficznego rozdzielenia) oraz testowania na żywych lub reprezentatywnych danych operacyjnych. Dokumentacja integracji dostawcy jest pisana z myślą o środowiskach komercyjnych. Dostosowanie jej do niejawnego środowiska obronnego zazwyczaj mnoży udokumentowany nakład przez 1,5 do 2.

Koszt szkoleń (20–30% TCO pierwszego roku; 10–15% rocznie w kolejnych latach)

Szkolenia wstępne obejmują operatorów, administratorów systemu i oficerów bezpieczeństwa. Dla średniej wielkości wdrożenia w trzech jednostkach zazwyczaj wynosi to 400–800 osobogodzin instruktażu plus koszty pośrednie instruktora i obiektu. Liczba, której konsekwentnie brakuje w szacunkach zamówień, to koszt szkoleń cyklicznych wynikający z rotacji personelu.

Wojskowe jednostki operacyjne wymieniają 20–35% personelu rocznie. Dla systemu z 200 aktywnymi użytkownikami oznacza to 40–70 nowych operatorów wymagających szkolenia co roku – bezterminowo, przez cały czas trwania programu. Materiały szkoleniowe również wymagają utrzymania: każda duża zmiana wersji oprogramowania unieważnia istniejące materiały i wymaga cyklu rewizji dokumentacji, którego dostawcy nie finansują i rzadko wspierają.

Koszt utrzymania i wsparcia (20–30% TCO w perspektywie 10 lat)

Roczne opłaty serwisowe za oprogramowanie obronne zazwyczaj wynoszą 15–22% początkowego kosztu licencji rocznie. Opłaty te pokrywają po stronie dostawcy tworzenie łatek i dostęp do wsparcia. Nie obejmują wewnętrznych nakładów pracy niezbędnych do walidacji, testowania i wdrażania tych łatek w środowisku niejawnym – procesu, który jest znacznie droższy niż komercyjny odpowiednik ze względu na wymogi ponownej akredytacji.

Poziomy SLA mają większe znaczenie w kontekście obronnym niż komercyjnym, ponieważ konsekwencje przestoju mają charakter operacyjny. Oceniaj zobowiązania dotyczące czasu reakcji wsparcia dla incydentów P1, udokumentowaną pojemność wsparcia dostawcy (obsada i ścieżka eskalacji) oraz długość okna długoterminowego wsparcia w odniesieniu do operacyjnego czasu życia programu. Dostawca oferujący 5 lat wsparcia dla programu 15-letniego tworzy strukturalną lukę, którą umowy zamówień rzadko adresują.

Koszt ewolucji (10–20% TCO w perspektywie 10 lat)

Programy oprogramowania obronnego przechodzą co najmniej dwie duże zmiany wersji w ciągu 10-letniego cyklu życia. Każda z nich w środowisku niejawnym wiąże się z: nakładami na migrację, ponowną akredytacją (przegląd bezpieczeństwa i formalne zezwolenie na eksploatację nowej wersji), ponownym szkoleniem i ponownym testowaniem integracji. Koszty usług profesjonalnych dostawcy na potrzeby migracji są rutynowo niedoszacowywane w wstępnych ofertach, ponieważ złożoność migracji nie jest w pełni znana w momencie udzielenia zamówienia.

Zaplanuj rezerwę na ponowną akredytację w wysokości 40–80% pierwotnego wysiłku integracyjnego dla każdej dużej zmiany wersji. To liczba, której najczęściej brakuje w szacunkach biur programowych.

Model kosztu integracji: szacowanie nakładów przed udzieleniem zamówienia

Szacunek kosztu integracji przed udzieleniem zamówienia jest z konieczności niedokładny, lecz szacunek rzędu wielkości jest zdecydowanie lepszy niż żaden. Poniższy model zapewnia ustrukturyzowany punkt wyjścia.

Dla każdego punktu integracji przyznaj ocenę złożoności API od 1 do 5 na podstawie czterech czynników: złożoności protokołu (REST/JSON ocena 1; niestandardowe protokoły binarne ocena 5), wymagań uwierzytelniania (klucz API ocena 1; wzajemne TLS z infrastrukturą PKI ocena 4–5), złożoności transformacji danych (bezpośrednie mapowanie pól ocena 1; semantyczne tłumaczenie między modelami danych ocena 4–5) oraz dostępności SDK (SDK dostarczony przez dostawcę ocena 1; brak dokumentacji ocena 5).

Bazowy szacunek nakładów to: (ocena złożoności × 20 godzin) na punkt końcowy, plus stały dodatek 80 godzin na przegląd bezpieczeństwa na punkt integracji w środowisku niejawnym, plus 40 godzin na testy akceptacyjne na punkt końcowy. Dla systemu z 8 punktami integracji o średniej ocenie złożoności 3 bazowy szacunek wynosi (3 × 20 × 8) + (80 × 8) + (40 × 8) = 480 + 640 + 320 = 1 440 godzin przed uwzględnieniem rezerwy.

Zastosuj mnożnik awaryjny 1,3–1,5 dla niejawnej infrastruktury, gdzie dostęp do narzędzi, segmentacja sieci i procesy zatwierdzania ograniczają produktywność. Skorygowany szacunek 1 872–2 160 godzin (około 12–14 osobomiesięcy) jest realistyczną wartością planistyczną dla integracji systemu obronnego o średniej złożoności.

Koszt szkoleń: modelowanie obciążenia cyklicznego

Modelowanie kosztu szkoleń zaczyna się od zróżnicowania ról. Nie wszyscy użytkownicy mają takie same wymagania szkoleniowe. Operatorzy wymagają szkolenia funkcjonalnego dotyczącego ich konkretnych procesów pracy. Administratorzy systemu wymagają pełnego szkolenia z platformy, w tym konfiguracji bezpieczeństwa. Oficerowie bezpieczeństwa wymagają szkolenia specyficznego dla akredytacji, dotyczącego funkcji bezpieczeństwa systemu i procedur audytowych.

Dla wdrożenia obejmującego 200 operatorów, 10 administratorów i 3 oficerów bezpieczeństwa bazowy budżet szkoleń na pierwszy rok może wyglądać następująco: 200 operatorów po 16 godzin każdy (3 200 godzin), 10 administratorów po 40 godzin każdy (400 godzin), 3 oficerów bezpieczeństwa po 24 godziny każdy (72 godziny), plus koszty instruktora i materiałów – łącznie około 3 700 osobogodzin bezpośredniego nauczania plus koszty pośrednie.

Roczny koszt cykliczny przy 25% rotacji to 50 operatorów po 16 godzin (800 godzin) plus proporcjonalna rotacja administratorów i oficerów bezpieczeństwa – około 900 godzin rocznie. W ciągu 10-letniego cyklu programu cykliczne nakłady szkoleniowe przekraczają wstępną inwestycję szkoleniową w czwartym roku. Programy, które planują wyłącznie szkolenia wstępne, odkrywają tę rozbieżność w trzecim lub czwartym roku eksploatacji.

Utrzymanie materiałów szkoleniowych jest oddzielną pozycją. Każde duże wydanie oprogramowania – zazwyczaj co 18–24 miesiące – wymaga rewizji materiałów. Zaplanuj 200–400 godzin pracy technicznej i projektowania dydaktycznego na duży cykl wydań.

Utrzymanie i wsparcie: poziomy SLA i ryzyko kondycji dostawcy

Ocena SLA wsparcia dla oprogramowania obronnego wymaga zbadania trzech wymiarów, które standardowe listy kontrolne komercyjnych zamówień pomijają.

Pierwszy to częstotliwość łatania a obciążenie ponowną akredytacją. Dostawca publikujący łatki bezpieczeństwa co miesiąc tworzy miesięczne obciążenie ponowną akredytacją dla wdrożeń niejawnych. Kwartalna częstotliwość łatania – z awaryjnymi łatkami dla krytycznych CVE – jest bardziej kompatybilna operacyjnie z ograniczeniami wdrożeń niejawnych. Oceń historyczną częstotliwość wydawania łatek przez dostawcę w odniesieniu do pojemności akredytacyjnej Twojej organizacji.

Drugi wymiar to ryzyko kondycji dostawcy. Dostawcy oprogramowania obronnego na rynku europejskim obejmują znaczny odsetek małych i średnich firm o ograniczonej głębokości finansowej. Dostawca zatrudniający 40 pracowników, dostarczający platformę krytyczną dla misji, reprezentuje ryzyko koncentracji: zależność od kluczowych osób, ryzyko przejęcia i potencjalne porzucenie produktu. Oceń kondycję finansową dostawcy, strukturę własności i długoterminowe zobowiązania wsparcia w umowie. Escrow kodu źródłowego jest standardowym zabezpieczeniem – dostawca deponuje kod źródłowy i instrukcje kompilacji u neutralnego agenta escrow, z udostępnieniem wyzwalanym przez zdefiniowane zdarzenia dotyczące ciągłości działania.

Trzeci wymiar to ekspozycja na komponenty open-source. Większość oprogramowania obronnego zawiera biblioteki open-source, których utrzymanie jest finansowane przez społeczność. Znaczące komponenty open-source, których wsparcie społecznościowe spada, generują przyszły koszt: albo dostawca przejmuje wewnętrzne koszty utrzymania (które ostatecznie przekładają się na opłaty wsparcia), albo komponent staje się zobowiązaniem bezpieczeństwa. Zażądaj wykazu komponentów oprogramowania (SBOM) i oceń kondycję głównych zależności open-source w ramach należytej staranności wobec dostawcy.

Szczegółowe ramy oceny możliwości dostawcy przed udzieleniem zamówienia znajdziesz w artykule ocena dostawców oprogramowania obronnego: przewodnik po technicznej należytej staranności dla oficera ds. zamówień.

Budowanie vs. zakup vs. COTS: kiedy własne oprogramowanie wygrywa pod względem TCO

Standardowe założenie zamówieniowe jest takie, że oprogramowanie COTS (commercial off-the-shelf, czyli gotowe komercyjne) jest tańsze niż własne oprogramowanie, ponieważ amortyzuje koszty R&D wśród wielu klientów. Założenie to jest trafne w środowiskach komercyjnych i zawodzi w określonych kontekstach obronnych.

Własne oprogramowanie staje się konkurencyjne pod względem TCO wobec COTS, gdy zbiegają się trzy warunki. Po pierwsze, model danych produktu COTS jest architektonicznie niekompatybilny z systemem ewidencji, wymagając warstwy oprogramowania pośredniego, która sama w sobie jest znaczącym projektem programistycznym. Warstwa pośrednia dodaje koszt integracji, koszt utrzymania i pojedynczy punkt awarii – i jest niewidoczna w cenniku dostawcy COTS. Po drugie, zastrzeżona warstwa integracji produktu COTS tworzy uzależnienie od dostawcy narastające z biegiem czasu: przyszłe migracje wersji stają się zakładnikami narzędzi migracyjnych dostawcy, a alternatywni dostawcy stają w obliczu tego samego problemu z warstwą pośrednią od zera. Po trzecie, zakres funkcjonalny jest wąski i stabilny. Dedykowane narzędzie, które wykonuje jedno zadanie dobrze – fuzja śladów dla konkretnego typu sensora na przykład – może być zbudowane, przetestowane i utrzymywane przez mały zespół przy niższym koszcie 10-letnim niż szeroka platforma COTS z 80% niewykorzystanej funkcjonalności.

Obliczenie punktu przełomu: jeśli nakłady na integrację COTS w roku pierwszym przekraczają 150% kosztu licencji, a roczna opłata serwisowa jest powyżej 20% licencji, a czas trwania programu przekracza 8 lat – modeluj własne oprogramowanie jako opcję konkurencyjną przed udzieleniem zamówienia. Porównanie musi uwzględniać pełny koszt własnego oprogramowania (nie tylko wstępne budowanie – bieżące utrzymanie, łatanie bezpieczeństwa i ewolucję) prognozowany na tym samym horyzoncie.

Dla programów, gdzie COTS jest właściwym wyborem, lecz warunki zamówienia wymagają starannej struktury, przewodnik po zamówieniach obronnych od RFP do umowy omawia struktury umów chroniące przed eskalacją kosztów po udzieleniu zamówienia.

Składanie modelu: praktyczny przykład

Rozważmy platformę taktycznej fuzji wywiadowczej zamówioną dla kwatery głównej szczebla brygady. Oferta dostawcy opiewa na 1,8 mln euro za licencję 5-letnią dla 150 użytkowników. Kompletny model TCO dla 10-letniego cyklu programu:

Nabycie (10 lat): Licencja lata 1–5: 1,8 mln euro, przedłużenie lata 6–10 szacowane na 2,2 mln euro (3% roczna eskalacja). Łącznie: 4,0 mln euro.

Integracja: 10 punktów integracji przy średniej ocenie złożoności 3,5, z mnożnikiem awaryjnym dla niejawnej infrastruktury 1,4. Szacowane 2 100 godzin pracy przy stawce 120 euro/godzinę. Plus infrastruktura (serwer oprogramowania pośredniego, urządzenia bezpieczeństwa): 180 tys. euro. Łącznie: 432 tys. euro.

Szkolenia (10 lat): Szkolenie wstępne 3 700 osobogodzin po 85 euro/godzinę = 315 tys. euro. Roczne szkolenia cykliczne po 80 tys. euro/rok × 9 lat = 720 tys. euro. Utrzymanie materiałów 3 duże cykle wydań po 35 tys. euro każdy = 105 tys. euro. Łącznie: 1,14 mln euro.

Utrzymanie i wsparcie (10 lat): Roczne opłaty wsparcia przy 18% pierwotnej licencji (324 tys. euro/rok) × 10 = 3,24 mln euro. Wewnętrzne nakłady na zarządzanie łatkami przy 60 tys. euro/rok = 600 tys. euro. Łącznie: 3,84 mln euro.

Ewolucja (2 duże aktualizacje): Nakłady na migrację 2 × 1 000 godzin po 120 euro/godzinę = 240 tys. euro. Ponowna akredytacja 2 × 600 godzin po 120 euro/godzinę = 144 tys. euro. Łącznie: 384 tys. euro.

TCO za 10 lat: około 9,8 mln euro wobec nominalnej oferty nabycia wynoszącej 1,8 mln euro. Koszt nabycia stanowi 18% łącznego kosztu programu. Pozostałe 82% nigdy nie pojawiło się w ofercie dostawcy.

Strukturyzacja zamówień w celu kontroli TCO

Model TCO jest przydatny przed udzieleniem zamówienia. Po jego udzieleniu kontrola kosztów zależy od struktury umowy. Kilka mechanizmów znacząco redukuje ryzyko eskalacji kosztów po udzieleniu zamówienia.

Pułapy eskalacji cen subskrypcji zapobiegają efektowi kumulowania się rocznych podwyżek opłat przez długi cykl programu. Stawki usług profesjonalnych za integrację powinny być ustalone w momencie udzielenia zamówienia, a nie pozostawione do przyszłych negocjacji, gdy dostawca ma przewagę. Własność materiałów szkoleniowych powinna należeć do zamawiającej organizacji – materiały szkoleniowe będące własnością dostawcy są stałym centrum kosztów. Zobowiązania do wsparcia migracji powinny być określone: co dostawca zapewnia, po jakiej stawce, dla każdej dużej zmiany wersji. Oraz długoterminowe zobowiązania dotyczące okna wsparcia powinny być wyraźne – dostawca zobowiązujący się do 10 lat wsparcia w momencie udzielenia zamówienia różni się materialnie od dostawcy zobowiązującego się do 5 lat z przedłużeniem według jego uznania.

Modelowanie TCO nie jest gwarancją przed przekroczeniem kosztów. Programy się zmieniają, wymagania ewoluują, a dostawcy są przejmowani. Jednak decyzja zamówieniowa podjęta z pełnym obrazem kosztów – zamiast przybliżenia opartego na koszcie nabycia – wychodzi z pozycji strukturalnej świadomości, a nie strukturalnej ślepoty.