Custom Software · Pogłębienie
Na zamówienie czy platforma: siatka decyzyjna build-vs-buy
Kiedy budować oprogramowanie na zamówienie, a kiedy kupić platformę: siatka decyzyjna oparta na dopasowaniu do procesu, całkowitym koszcie posiadania, lock-inie, własności danych i time-to-value.
ARCHITEKTURA · BUILD-VS-BUY
Wejście · Zdolności do uruchomienia
Wyjście · Build / Buy / Compose
Core vs commodity (mapa wartości)
Rozkłada system na jego zdolności i umieszcza każdą na osi core/commodity: oddziela to, co wyróżnia Cię na rynku — i zasługuje na własny kod — od tego, co stało się commodity i po prostu kupuje się u najtańszego dostawcy.
Dopasowanie do procesu
Mierzy, jak własnościowy jest Twój przepływ: proces generyczny z ustabilizowanymi standardami branżowymi pcha ku platformie, a przepływ będący częścią Twojej przewagi pcha ku rozwiązaniu na zamówienie, bo tutaj obejścia narzucone przez platformę kosztują więcej niż kod na zamówienie.
TCO na 5 lat
Liczy koszt pięcioletni wraz z utrzymaniem, integracją i szkoleniem — nie tylko licencję czy początkową wycenę — bo większość kosztu oprogramowania pojawia się po starcie produkcyjnym, i to właśnie odwraca werdykt.
Lock-in i prawa wyjścia
Waży koszt wyjścia, zanim wejdziesz: umowy, przenośność danych i zakodowane na sztywno integracje rozstrzygają, czy przy odnowieniu będziesz mieć siłę negocjacyjną, czy zostaniesz bez niej, naprzeciw dostawcy, który o tym wie.
Własność danych
Sprawdza, czy dane, które Cię wyróżniają, pozostają Twoje, eksportowalne w otwartych standardach i niezależne od dostawcy: jeden nieeksportowalny element może odwrócić decyzję, bo aktyw zamieniony w zakładnika waży więcej niż jakakolwiek oszczędność na cenie katalogowej.
Time-to-value
Równoważy pilność wartości z trwałością przewagi: sprawdzone, już dostępne rozwiązanie wprawia Cię w ruch teraz, podczas gdy strukturalny wyróżnik uzasadnia dłuższe, podtrzymane wdrożenie.
Sygnały, że Twoja linia build-vs-buy została wytyczona w złym miejscu
Pytanie nigdy nie brzmi „na zamówienie czy platforma”. Brzmi: która zdolność zasługuje na własny kod, a która jest commodity do kupienia. Te symptomy oznaczają, że linia została wytyczona w niewłaściwym punkcie.
- Dostosowujesz standardową platformę aż przestaje przypominać samą siebie: każde wydanie dostawcy psuje Twoją konfigurację, a „gotowe do użycia” stało się stałym projektem deweloperskim.
- Zbudowałeś commodity od zera — uwierzytelnianie, płatności, powiadomienia — wydając moce inżynierskie na problemy, które rynek już rozwiązał, zamiast na swoją przewagę konkurencyjną.
- Dane, które Cię wyróżniają, żyją u dostawcy w zamkniętym formacie bez eksportu do otwartych standardów: to już nie aktyw, to zakładnik.
- Nikt nigdy nie policzył liczby na pięć lat : decyzję podjęto na podstawie ceny licencji lub wyceny rozwoju, ignorując utrzymanie, integrację i szkolenia, które dominują w cyklu życia.
- Zmiana dostawcy jest nie do pomyślenia : wieloletnie umowy, nieprzenośne dane i zakodowane na sztywno integracje podniosły koszt wyjścia do poziomu, który odbiera Ci wszelką siłę negocjacyjną przy odnowieniu.
Dla dyrektorów ds. technologii, operacji i kierownictwa operacyjnego, którzy muszą zdecydować, gdzie inwestować moce inżynierskie, a gdzie oprzeć się na rynku — z kryteriami, które obronią się przed zarządem.
Kup commodity, zbuduj to, co Cię wyróżnia
Najtrwalsza reguła operacyjna nie jest finansowa, lecz strategiczna: umieść każdą zdolność na mapie wartości i decyduj według jej położenia, a nie według preferencji tego, kto pisze kod. Dyscyplina sformalizowana przez Wardley Mapping.
Core kontra commodity, nie osobisty gust
Zdolność, która wyróżnia Cię na rynku i szybko ewoluuje, zasługuje na własny kod. Zdolność, która stała się commodity — taka sama dla Ciebie i Twoich konkurentów — jest centrum kosztów: kupujesz u najtańszego dostawcy i idziesz dalej. Budowanie commodity to spalanie mocy inżynierskich na rozwiązanym problemie.
Dopasowanie do procesu to prawdziwa linia podziału
Jeśli Twój przepływ jest generyczny, a branża ma ustabilizowane standardy, platforma wygrywa szybkością. Jeśli przepływ jest własnościowy i częścią Twojej przewagi, platforma wymusza obejścia, które w sumie kosztują więcej niż kod na zamówienie. Platforma nagina Cię do swojego modelu; rozwiązanie na zamówienie nagina oprogramowanie do Twojego.
Konfigurowanie nie jest darmowe
Pomiędzy kupnem a budową jest trzecia droga — konfigurować i integrować — ale nie jest neutralna. Wpasowanie złożonej platformy w konkretny przepływ, z migracją danych i szkoleniem, niesie realny koszt jeszcze przed pierwszą transakcją. Pułapką jest nadmierna personalizacja: zacznij od zalecanej konfiguracji i iteruj na danych z użycia, nie przepisuj wszystkiego pierwszego dnia.
Compose: najlepsze z obu, z dyscypliną
Dojrzałe podejście jest hybrydowe: zdolności rynkowe do funkcji standardowych, połączone przez udokumentowane API, a wewnętrzne moce inżynierskie skoncentrowane na tym, co naprawdę Cię wyróżnia. To logika composable (mikroserwisy, API-first, cloud-native, headless): wymienne komponenty, które zmieniają się bez zawalenia wszystkiego, co jest z nimi połączone.
Decyzja musi być strukturalna, nie emocjonalna
Mapowanie zdolności czyni wybór czytelnym: widać, gdzie każdy komponent leży na osi geneza-commodity, od czego zależy i dokąd pcha ewolucja. Linia build-vs-buy przestaje być preferencją działu i staje się obronialną decyzją architektoniczną.
Jak wytyczamy linię, zdolność po zdolności
Nie decydujemy „na zamówienie czy platforma” dla całego systemu. Rozkładamy system na zdolności i przepuszczamy każdą przez te same bramki. Wynikiem jest mapa, nie opinia.
Rozkładamy system na jego zdolności i umieszczamy każdą na osi core/commodity: co Cię wyróżnia, co stało się standardem. To oddziela to, co warte własnego kodu, od tego, co po prostu kupujesz.
Dla każdej zdolności sprawdzamy, jak własnościowy jest Twój przepływ. 60-70% standardu z dającymi się ogarnąć wyjątkami: konfigurować. Przepływ będący częścią przewagi: budować. Przepływ generyczny: kupować.
Liczymy koszt pięcioletni wraz z utrzymaniem, integracją i szkoleniem — nie tylko licencję czy początkową wycenę. Równolegle mierzymy koszt wyjścia: przenośność danych, prawa eksportu, zależność od integracji.
Każda zdolność otrzymuje werdykt — build, buy lub compose — i swoje miejsce w architekturze. Commodity trafiają za udokumentowane API; wyróżnik staje się własnym kodem, z danymi pod Twoją kontrolą.
Od mapy zdolności do obronialnej siatki decyzyjnej w tygodnie, nie w kwartał analiz.
Build, Buy czy Compose: bramki decyzyjne
Każda zdolność przechodzi przez pięć dźwigni. To nie suma punktów: jedna dźwignia może odwrócić decyzję (własnościowe, nieeksportowalne dane ważą więcej niż jakakolwiek oszczędność na cenie katalogowej).
| Dźwignia decyzyjna | Pcha ku BUY / platforma | Pcha ku BUILD / na zamówienie |
|---|---|---|
| Pozycja na mapie | Zdolność commodity, identyczna jak u konkurentów | Zdolność core, która Cię wyróżnia i szybko ewoluuje |
| Dopasowanie do procesu | Przepływ generyczny, ustabilizowane standardy branżowe | Przepływ własnościowy; platforma wymusza kosztowne obejścia |
| TCO na 5 lat | Utrzymanie i ryzyko po stronie dostawcy | Wolumen i czas użytkowania amortyzują koszt budowy |
| Lock-in i wyjście | Eksport do otwartych standardów, wyjście dla wygody, integracje przez API | Krytyczne dane muszą pozostać własne, niezależne od dostawcy |
| Time-to-value | Wartość potrzebna od razu; sprawdzone rozwiązanie już dostępne | Przewaga uzasadnia dłuższe, podtrzymane wdrożenie |
Cztery aktywa, które siatka zabezpiecza
Dobra decyzja build-vs-buy nie tylko optymalizuje koszt. Chroni to, czego raz utraconego nie da się odkupić.
Własność danych
Dane, które Cię wyróżniają, pozostają Twoje — eksportowalne w standardowych formatach i niezależne od dostawcy. Nie zakładnik w zamkniętym silosie, lecz negocjowalny aktyw, który daje Ci siłę przy odnowieniu.
Dobrze wydane moce inżynierskie
Każda godzina rozwoju idzie na Twoją przewagę konkurencyjną, nie na commodity, które rynek już rozwiązał. Na zamówienie tam, gdzie się liczy, rynek tam, gdzie się nie liczy.
Prawa wyjścia
Przenośność danych, udokumentowane integracje przez API i brak własnościowego okablowania utrzymują niski koszt zmiany. Możliwość odejścia to właśnie to, co utrzymuje Cię na uczciwych warunkach.
Architektura composable
Wymienne zdolności połączone przez API: jeden komponent zmienia się bez zawalenia reszty. System pozostaje żywy w czasie, a nie monolitem do przebudowy.
Buduj to, co Cię wyróżnia, kupuj to, co dzielisz z konkurentami.
Pytania, które dostajemy przed decyzją
Czy na zamówienie jest zawsze droższe niż platforma?
Nie w cyklu życia. Większość kosztu oprogramowania pojawia się po starcie produkcyjnym — utrzymanie, integracja, szkolenie. Przy commodity platforma wygrywa, bo zrzuca ten koszt na dostawcę. Przy zdolności core z dużym wolumenem i długim czasem użytkowania rozwiązanie na zamówienie się amortyzuje, podczas gdy cena platformy rośnie z czasem. Odpowiedź tkwi w TCO na pięć lat, nie w cenie wejścia.
Czy mogę kupić teraz i zbudować później?
Tak, i często jest to właściwy ruch — pod warunkiem, że nie dasz się wpędzić w pułapkę. Kupno, by szybko ruszyć, ma sens, jeśli dane pozostają eksportowalne w otwartych standardach, a integracje idą przez udokumentowane API. Jeśli dostawca trzyma Twoje dane w zamkniętym formacie, „później” staje się kosztowną migracją, której nigdy nie wykonasz. Przenośność negocjuje się przy podpisie, nie przy rozwodzie.
Jak uniknąć budowania czegoś, co rynek robi lepiej?
Mapując każdą zdolność przed napisaniem kodu. Jeśli funkcja stała się standardem — taka sama dla Ciebie i Twoich konkurentów —, jej budowanie to spalone moce inżynierskie. Własny kod jest zarezerwowany dla tego, co Cię wyróżnia i ewoluuje; cała reszta jest kupowana lub komponowana przez API. Ta dyscyplina oddziela inwestycję od wydatku.
Przypadki
Od problemu do wyniku — anonimowo.
Wykrzywiona platforma
Problem Detalista dostosował standardową platformę e-commerce, aż przestała przypominać samą siebie: każde wydanie dostawcy psuło konfigurację, a „gotowe do użycia” stało się stałym projektem deweloperskim, z silnikiem pricingu — ich prawdziwym wyróżnikiem — uwięzionym w ograniczeniach, których nie kontrolowali.
Metoda Zmapowaliśmy zdolności na osi core/commodity: katalog, checkout i płatności utrzymane na platformie jako commodity za udokumentowanymi API; silnik pricingu i promocji, część przewagi konkurencyjnej, wyodrębniony jako własna usługa połączona w sposób composable.
Wynik Wydania dostawcy przestały psuć system, moce inżynierskie wróciły do pricingu zamiast obejść, a logika, która ich wyróżnia, stała się ich własnym kodem — wymiennym bez zawalenia reszty.
Dane wzięte na zakładnika
Problem Firma usług finansowych trzymała dane klientów, które ją wyróżniały, u dostawcy, w zamkniętym formacie bez eksportu do otwartych standardów: zmiana była nie do pomyślenia, a przy odnowieniu dostawca miał całą siłę negocjacyjną, bo wyjście było w praktyce zamknięte.
Metoda Zastosowaliśmy bramki lock-inu i własności danych: renegocjowaliśmy prawa eksportu do standardowych formatów przy rozwiązaniu umowy, przenieśliśmy krytyczne integracje na udokumentowane API i przywróciliśmy wyróżniające dane pod kontrolę wewnętrzną, zostawiając funkcje commodity tam, gdzie były.
Wynik Koszt wyjścia spadł do poziomu przywracającego siłę negocjacyjną przy odnowieniu, dane znów stały się negocjowalnym aktywem zamiast zakładnika, a możliwość odejścia to właśnie to, co utrzymało ich na uczciwych warunkach.
Commodity zbudowane od zera
Problem Operator logistyczny zbudował od zera zdolności będące już commodity — uwierzytelnianie, powiadomienia, zarządzanie użytkownikami — spalając moce inżynierskie na problemach, które rynek już rozwiązał, podczas gdy planowanie tras, ich prawdziwa przewaga, pozostawało niedoinwestowane.
Metoda Przepuściliśmy każdą zdolność przez mapę wartości i TCO na pięć lat: wycofaliśmy rozwiązania na zamówienie dla commodity na rzecz usług rynkowych za API, a deweloperów skoncentrowaliśmy na optymalizacji tras, gdzie wolumen i czas użytkowania amortyzują kod na zamówienie.
Wynik Każda godzina rozwoju wróciła do wyróżnika, utrzymanie commodity przeszło na dostawców, a architektura stała się composable — wymienne komponenty, które zmieniają się bez przebudowy całego bloku.
Pogłęb dalej