Wprowadzenie
Artykuł analizuje strategiczny paradoks Booking.com, gdzie mechanizmy sukcesu stały się barierą rozwoju. Dowiedz się, jak kultura ekstremalnej optymalizacji może prowadzić do systemowej sztywności.
Przeanalizujemy pułapkę lokalnej racjonalności, która utrudnia przejście od ulepszeń inkrementalnych (rozwój od 1 do 1,5) do radykalnych innowacji typu 0 → 1. Tekst wyjaśnia wpływ długu technologicznego na strategię biznesową.
Gil lian Tans i pułapka pamięci instytucjonalnej
Gil lian Tans, CEO w latach 2016–2019, uosabiała etos firmy: nieformalność i sceptycyzm wobec korporacyjnych rytuałów. Jej kapitałem była głęboka pamięć instytucjonalna, wspierana przez nieformalną sieć wpływów zwaną Dutch Mafia.
To zakorzenienie pomogło utrzymać kulturę przedsiębiorczą, ale stworzyło zamknięty krąg interpretacyjny. W efekcie organizacja mogła mieć trudność z kwestionowaniem przekonań ukształtowanych przez dawne sukcesy.
Przykładem jest konflikt między autonomią amsterdamskiego biura a dążeniem centrali do globalnej integracji portfela marek, co utrudniało synergię wewnątrz holdingu.
Pułapka racjonalności lokalnej i bariera optymalizacji
Booking.com perfekcyjnie opanowało optymalizację istniejących systemów, lecz utknął w pułapce racjonalności lokalnej. Firma faworyzuje projekty z mierzalnym wzrostem BPD, co blokuje innowacje typu 0 → 1, których wartości nie dadzą się zmierzyć testem A/B.
Ogromne zasoby danych o hotelach paradoksalnie utrudniają kreację nowych usług. Modele predykcyjne działają w znanej przestrzeni, ale są bezużyteczne przy budowaniu zupełnie nowej kategorii biznesowej.
W efekcie nowe produkty konkurują o zasoby z rentownym rdzeniem. Każda inwestycja w niepewną przyszłość jest postrzegana jako koszt alternatywny utraconej okazji do poprawy konwersji.
Starcie modelu doświadczenia z aparatem dystrybucji
W odpowiedzi na wzrost Airbnb Booking.com wykorzystało swoją skalę i aparat dystrybucyjny, by szybko asymilować alternatywne noclegi. Podczas gdy Airbnb oferowało narrację autentyczności, Booking redukował tarcie w rezerwacji.
Przejście do modelu Connected Trip (loty, atrakcje) okazało się trudniejsze niż ekspansja w noclegach. Wymagało to bowiem interoperacyjności różnych rynków i przebudowy fundamentów technologicznych.
Główną przeszkodą stał się dług technologiczny oparty na języku Perl. Choć system był efektywny, stał się sztywnością podstawową (core rigidity), ograniczającą możliwość szybkiej integracji nowych pionów biznesowych.
Podsumowanie
Historia Booking.com pokazuje, że najgroźniejszym dziedzictwem jest system, który wciąż znakomicie działa. Bieżąca efektywność staje się argumentem przeciwko zmianie, zamieniając sukcesy w niewidzialne więzienie.
Przejście do chmury nie usuwa długu architektonicznego, gdyż kod przechowuje zakodowaną teorię biznesu. Prawdziwym wyzwaniem jest zdolność do zburzenia mostu, który wciąż nas niesie, zanim doprowadzi on donikąd.
Często zadawane pytania
Kto była Gillian Tans i w jaki sposób jej zakorzenienie w kulturze Booking.com wpłynęło na zarządzanie firmą?
Gillian Tans to była CEO Booking.com, która objęła to stanowisko w 2016 roku po wieloletniej karierze w organizacji. Jej głębokie zakorzenienie w kulturze firmy i pamięć instytucjonalna obniżały koszty koordynacji dzięki sieciom zaufania, ale jednocześnie mogły tworzyć zamknięty krąg interpretacyjny utrudniający kwestionowanie dotychczasowych przekonań.
Dlaczego firma tak skuteczna w ulepszaniu swoich produktów ma problem z tworzeniem zupełnie nowych usług?
Firma opiera się na danych historycznych i optymalizacji istniejących systemów, co daje jej przewagę poznawczą nad tworzeniem nowych usług. Nowe projekty muszą konkurować z produktami doskonalonymi latami, a kultura wymagająca eksperymentalnego dowodu wartości utrudnia wdrażanie rozwiązań, których przyszłych korzyści nie da się jeszcze zmierzyć.
Jak Booking.com zareagował na wzrost popularności alternatywnych noclegów i w czym różniła się jego strategia od podejścia Airbnb?
Booking.com zareagował na wzrost popularności alternatywnych noclegów, rozszerzając swoją ofertę o domy i apartamenty w oparciu o analizę zachowań użytkowników oraz własną skalę i kanały dystrybucji. W przeciwieństwie do Airbnb, które budowało narrację autentyczności i lokalnych doświadczeń, Booking.com skupił się na byciu narzędziem redukującym tarcie w procesie rezerwacji.
Dlaczego Booking.com miał trudności z wprowadzeniem nowych usług, takich jak loty czy atrakcje, mimo sukcesu w obszarze noclegów?
Booking.com zoptymalizował swoje procesy i narzędzia pod konkretną transakcję hotelową, co stworzyło tzw. zależność od ścieżki ograniczającą przyszłe możliwości. Wprowadzenie lotów czy atrakcji wymagało integracji zupełnie innych architektur podaży, rytmów transakcyjnych oraz modeli odpowiedzialności.
Czy projekt Connected Trip był całkowitą porażką i dlaczego tak trudno jest wdrażać w Booking.com zupełnie nowe produkty?
Projekt Connected Trip nie był całkowitą porażką, lecz pozostaje elementem długoterminowej strategii firmy, choć napotyka trudności i opóźnienia. Wdrażanie nowych produktów w Booking.com jest utrudnione przez wysoką rentowność obecnego biznesu oraz system oceny pomysłów, który faworyzuje przewidywalne zyski nad ryzykownymi inwestycjami strategicznymi.
Dlaczego posiadanie ogromnej ilości danych o rezerwacjach hoteli może paradoksalnie utrudniać wprowadzanie radykalnych innowacji w Booking.com?
Ogromna ilość danych tworzy nierówność epistemiczną, przez co nowe projekty oparte na hipotezach wydają się mniej „naukowe” niż dojrzały biznes. Ponadto dane historyczne służą do predykcji zachowań w znanej przestrzeni, a nie do kreowania zupełnie nowych modeli podróży.
Dlaczego Booking.com jako firma mogła być w konflikcie z własnym holdingiem mimo świetnych wyników finansowych?
Konflikt wynikał z różnicy między lokalną optymalizacją Booking.com a globalną optymalizacją portfela holdingu. Podczas gdy centrala dążyła do integracji marek i wykorzystania synergii, kierownictwo Booking.com obawiało się, że ingerencja w ich model osłabi najskuteczniejszy element grupy.
Dlaczego firma tak skuteczna w optymalizacji ma problem z tworzeniem zupełnie nowych produktów?
Firma posiada system organizacyjny wyspecjalizowany w skalowaniu innowacji kompatybilnych z istniejącym rdzeniem, co utrudnia budowanie przedsięwzięć wymagających przebudowy fundamentów. Dodatkowo barierą jest historyczna architektura technologiczna, która z czasem stała się mało elastyczna i przekształciła kompetencję podstawową w tzw. sztywność podstawową.
Dlaczego samo testowanie A/B i dotychczasowa technologia nie wystarczyły do stworzenia nowego ekosystemu podróżniczego?
Dotychczasowa technologia i testy A/B były niewystarczające, ponieważ służyły do optymalizacji znanych zachowań (zarządzania ryzykiem), a nie do tworzenia nowej strategii w warunkach głębokiej niepewności. Realizacja wizji „Connected Trip” wymagała przesunięcia granic możliwości i przebudowy przestarzałej architektury systemowej, która stała się hamulcem dla niezbędnej integracji produktów i danych.
Czy używanie starego języka programowania (Perla) jest główną przyczyną problemów technologicznych Booking.com?
Nie, samo używanie starszej technologii nie jest główną przyczyną problemów, gdyż system oparty na Perlu niezawodnie przetwarza ogromną liczbę transakcji. Kluczowym wyzwaniem jest narastający dług techniczny i złożoność architektury, które sprawiają, że wprowadzanie zmian biznesowych wiąże się z nieproporcjonalnie dużym nakładem pracy i ryzykiem.
W jaki sposób stara architektura technologiczna wpływa na strukturę zespołów i możliwość wprowadzania nowych usług w Booking.com?
Stara, silnie sprzężona architektura techniczna wymusza na wielu zespołach ciągłą koordynację, co ogranicza ich autonomię i spowalnia tempo eksperymentów. Dodatkowo przestarzałe modele biznesowe zakodowane w systemie utrudniają wdrażanie nowych usług, gdyż wymagają one dopasowania do nieaktualnych założeń dotyczących np. noclegów.
Dlaczego firma o takich zasobach jak Booking.com nie może po prostu przepisać starego systemu na nowy?
Stary system zawiera ogromną ilość sprawdzonej wiedzy biznesowej i obsługuje krytyczne procesy, których nie da się bez ryzyka odtworzyć. Koszt jego zastąpienia jest drastycznie wysoki ze względu na sieć zależności oraz fakt, że platforma musi działać w sposób ciągły, co uniemożliwia jej czasowe wyłączenie w celu przepisania kodu.
Dlaczego usunięcie starego kodu i modernizacja architektury w dużej firmie jest tak trudne i ryzykowne?
Modernizacja starego kodu jest ryzykowna, ponieważ doświadczeni inżynierowie wiedzą o istnieniu licznych historycznych przypadków brzegowych, których usunięcie mogłoby przerwać działanie systemu. Dodatkowo brak dokumentacji sprawia, że systemy legacy stają się „czarnymi skrzynkami”, a gwałtowne zmiany niosą ze sobą niebezpieczeństwo szerokich i dotkliwych awarii (tzw. blast radius).
Czy przejście do chmury Google lub Amazon rozwiązało problemy technologiczne Booking.com?
Sama chmura nie rozwiązuje długu architektonicznego, ponieważ migracja typu lift-and-shift jedynie przenosi problemy z jednego serwera na drugi. Może ona jednak pomóc w konkretnych obszarach, czego przykładem jest system rankingowy wyszukiwania, gdzie przejście do AWS umożliwiło bardziej elastyczne testowanie modeli uczenia maszynowego i skalowanie zasobów.
Dlaczego firma, która tak szybko wdraża drobne zmiany, ma problem z przebudową swoich fundamentów technologicznych?
Szybkie wdrażanie drobnych zmian powierzchniowych jest łatwiejsze niż przebudowa fundamentów, ponieważ głęboka architektura jest bardziej złożona i obciążona ryzykiem awarii kluczowego systemu. Im większą wartość generuje system i im więcej funkcji od niego zależy, tym trudniejsza staje się jego radykalna zmiana bez przerywania ciągłości działania.
Dlaczego system, który wciąż świetnie zarabia i działa, może być jednocześnie największym zagrożeniem dla przyszłości firmy?
System, który wciąż świetnie zarabia, może być zagrożeniem, ponieważ jego sukces dostarcza argumentów przeciwko radykalnym zmianom i przebudowie. Z czasem staje się on kosztownym dziedzictwem, które coraz drożej pozwala dostosowywać się do zmieniającego się otoczenia.
