Budować czy kupić oprogramowanie enterprise: ramy decyzyjne

Źle postawione pytanie, zadawane co roku

Każda organizacja prędzej czy później organizuje to spotkanie: budujemy ten system sami czy go kupujemy? Debata jest zwykle inscenizowana jako porównanie kosztów — oferta dostawcy kontra wewnętrzna wycena — i zwykle rozstrzygana na podstawie niewłaściwych dowodów. Cena zakupu i początkowy koszt budowy to dwie najmniejsze liczby w tym równaniu. Decyzja, która naprawdę się liczy, dotyczy własności: kto kontroluje tempo zmian zdolności, od której zależy biznes, i ile ta kontrola kosztuje w perspektywie dekady.

Ten artykuł pokazuje, jak prowadzimy tę analizę z CTO: całkowity koszt posiadania liczony uczciwie, dług integracyjny wyceniony przed podpisem oraz test różnicowania, który pokazuje, gdzie inżynieria na zamówienie naprawdę się opłaca.

Całkowity koszt posiadania, liczony uczciwie

Oba obozy upiększają własne liczby. Zespoły wewnętrzne wyceniają budowę i pomijają lata utrzymania; dostawcy podają licencję za pierwszy rok i pomijają wszystko, co następuje później. Uczciwy model TCO wycenia pełny cykl życia po obu stronach:

• Budowa: pierwsze wdrożenie plus 15–20% kosztu budowy rocznie na utrzymanie, aktualizację zależności i prace nad bezpieczeństwem — przez całe życie systemu
• Budowa: zespół. System zbudowany przez zespół projektowy, a potem osierocony, niszczeje szybciej niż cokolwiek, co można było kupić
• Zakup: ceny za użytkownika, które rosną wraz z zatrudnieniem, a nie z wartością — proszę przeliczyć umowę przy trzykrotności dzisiejszych licencji
• Zakup: koszty kastomizacji i konsultingu, które na dużych platformach regularnie przewyższają samą licencję
• Obie strony: koszt wyjścia. Migracja z jakiegokolwiek systemu w piątym roku to projekt, którego nikt nie budżetuje w roku pierwszym

Model warto policzyć w horyzoncie siedmiu–dziesięciu lat, nie trzech. Większość kupionych systemów wygląda tanio w trzy lata i drogo w dziesięć; systemy budowane — odwrotnie. Wybrany horyzont jest w istocie samą decyzją.

Dług integracyjny: ukryta pozycja kosztorysu

Żaden system enterprise nie działa w pojedynkę. Każdy zakup dodaje węzeł do grafu integracji, a budżety umierają na krawędziach: tożsamość, dane podstawowe, potoki raportowe i synchronizacje punkt-punkt, które narastają wokół każdego kupionego produktu. Kupione platformy integrują się na warunkach dostawcy — jego limitów API, jego rytmu aktualizacji, jego modelu danych. Każda dokładana kastomizacja przybliża do najgorszego z obu światów: kosztów utrzymania jak przy budowie i kontroli jak przy zakupie.

Pracę integracyjną należy wycenić wprost przed decyzją, nie po niej. Jeśli podłączenie kupionej platformy do istniejącego krajobrazu systemów kosztuje więcej niż połowę samodzielnej budowy tej zdolności, opcja zakupu nigdy nie była naprawdę zakupem.

Test różnicowania

Najsilniejszy filtr nie jest finansowy. Warto zapytać, czy dana zdolność wyróżnia Państwa na rynku. Zdolności standardowe — płace, obsługa zgłoszeń, e-mail, rozliczanie wydatków — należy kupować bez ceremonii; nikt nie wybiera dostawcy ze względu na jego narzędzie do delegacji. Zdolności, które pojawiają się w ofercie handlowej, marżach lub doświadczeniu klienta, zasługują na inżynierię na zamówienie, bo panowanie nad tempem ich zmian jest właśnie sednem sprawy.

• Proszę kupować tam, gdzie wystarczy parytet — płace, HR, obsługa zgłoszeń, zarządzanie dokumentami
• Proszę budować tam, gdzie mieszka przewaga — silniki cenowe, procesy zwrócone do klienta, proces, który prowadzą tylko Państwo
• Warto prześwietlić szarą strefę: jeśli w kupionym produkcie powstają ciężkie kastomizacje, rynek daje znać, że ta zdolność jest kluczowa

Strategie hybrydowe, które się bronią

W praktyce dojrzała odpowiedź rzadko jest czysta. Wzorce hybrydowe, które w naszej ocenie działają, łączy jedna cecha: czysty szew między tym, co się posiada, a tym, co się wynajmuje.

• Kupić silnik, zbudować doświadczenie — kupiony system źródłowy za zbudowanym na zamówienie interfejsem, z którego zespoły i klienci naprawdę korzystają
• Zbudować rdzeń, kupić obrzeża — własna logika domenowa otoczona standardowymi usługami tożsamości, komunikacji i analityki
• Owinąć przed wymianą — własna warstwa API nad systemem odziedziczonym lub systemem dostawcy, tak aby dało się go później wymienić bez dotykania konsumentów

Wzorcem, który zawodzi, jest fork z głęboką kastomizacją: modyfikowanie platformy dostawcy tak głęboko, że każda aktualizacja staje się migracją. Łączy on profil kosztowy budowy z ograniczeniami zakupu.

Ramy decyzyjne na jedno spotkanie

Przed kolejną dyskusją o tym, czy budować, czy kupić, warto położyć na stole pięć pytań:

• Czy ta zdolność nas wyróżnia, czy wystarczy nam parytet z resztą rynku?
• Czy nasze wymagania będą zmieniać się szybciej niż roadmapa któregokolwiek dostawcy?
• Jak wygląda uczciwe dziesięcioletnie TCO — utrzymanie, licencje, kastomizacja, integracja, wyjście?
• Czy jesteśmy w stanie obsadzić i utrzymać zespół na całe życie systemu, a nie tylko na czas budowy?
• Ile kosztuje odejście — w 36. miesiącu, na każdej z dwóch ścieżek?

Odpowiedzi mówiące o różnicowaniu, szybkich zmianach i zespole na lata wskazują na budowę. Parytet, stabilność i cienka integracja wskazują na zakup. Wszystko pomiędzy prowadzi do hybrydy ze szwem poprowadzonym świadomie. Systemy enterprise to jedna z części pracy inżynierskiej, którą wykonujemy w Vendenis — a gdy analiza wskazuje budowę albo zakup z integracją, pomagamy organizacjom zrealizować odpowiedź w obu wariantach.