Jak w strategii make-or-buy sprawdza się podejście „buy"? Kiedy jest lepszym wyborem?
Decyzja zawsze jest poprzedzona dogłębną analizą rynkową i oceną TCO [Total Cost of Ownership] w długim terminie, bo szukamy rozwiązań zrównoważonych i przewidywalnych kosztowo. Podejście „buy” sprawdza się dobrze, gdy potrzebujemy skokowego wzrostu zasobów, gdy system nie jest krytyczny, gdy nie chcemy budować własnych kompetencji w określonym obszarze (bo nie jest strategiczny), albo gdy system jest ściśle powiązany z szybko zmieniającymi się przepisami i wysoką specjalizacją.
Jakby wyglądała taka analiza np. w przypadku systemu bilingowego?
Przeanalizowalibyśmy na początek z czego składa się taki system i czy w przypadku któregoś z jego elementów własne rozwiązanie dałoby nam wartość ‒ choćby jakich zasobów obliczeniowych potrzebuje, lub czy odpowiada zapotrzebowaniu, jakie zgłasza biznes, a które są zbyt trudne lub zbyt drogie do wdrożenia w rozwiązaniu zewnętrznym. Kolejna sprawa, to w jakim czasie jesteśmy w stanie wdrożyć własne rozwiązanie i czy Proof of Concept daje nadzieję na końcowy sukces. Dokładnie przyjrzelibyśmy się stronie finansowej ‒ nie tylko niezbędnym nakładom inwestycyjnym, ale także długoterminowemu TCO z uwzględnieniem konieczności utrzymania systemu legacy do czasu migracji na nowe rozwiązanie. Zapewne równolegle prowadzilibyśmy dialog z dotychczasowym dostawcą, aby sprawdzić, czy jest w stanie zaproponować wariant konkurencyjny wobec insourcingu.
Czyli określacie potrzeby i kalkulujecie, czy korzystniej je zaspokoić w modelu in-house lub w ramach współpracy z zewnętrznym partnerem.
Realną korzyść daje nam także większa szybkość wdrożenia w modelu in-house oraz swoboda zarządzania takim rozwiązaniem. Autonomia oczywiście idzie w parze z odpowiedzialnością ‒ ostatecznie to my jesteśmy stroną świadczącą usługę klientom, a nie strona trzecia, która zaangażowana jest w jej realizację czy utrzymanie.
Jaki jest udział filozofii Grupy iliad w tych decyzjach?
Bycie częścią Grupy iliad daje nam dostęp do benchmarków z innych krajów i możliwość wymiany doświadczeń. iliad na rynku francuskim rozwija wiele systemów in-house – nawet urządzenia klienckie, które wydawałoby się, że można łatwo nabyć z rynkowej półki.
Nie chcecie wdrożyć ich w Polsce?
Braliśmy taki scenariusz pod uwagę, jednak obecnie nie jest to możliwe technicznie. Analizując ten przypadek musieliśmy wziąć też pod uwagę fakt, że ceny usług telekomunikacyjnych w Polsce należą do jednych z najniższych w Europie.
Czy istnieje możliwość ‒ powiedzmy ‒ wdrożenia wspólnego bilingu dla całej Grupy iliad?
Billing jest akurat trudnym przykładem. Rynki europejskie są bardzo różnorodne pod względem ofert czy reguł taryfowych i poziomu konkurencji, co utrudnia wdrożenie jednej platformy. Żadne rozwiązanie software'owe nie funkcjonuje w próżni – architektura sieci, interfejsy, ekosystem technologiczny musiałyby być zbieżne lub dostosowane. Na razie w ramach całej Grupy skupiamy się przede wszystkim na benchmarkach, inspiracji i dzieleniu się doświadczeniami. Nie wykluczam jednak, że wdrożony z sukcesem system na jednym rynku może być w kolejnym kroku dostosowany do wymagań innego podmiotu w grupie.
Eksportowaliście pracę polskich informatyków do innych podmiotów Grupy iliad?
Możliwości są otwarte, ale jeszcze nie było takiej potrzeby.
Porozmawiajmy o wadach podejścia in-house?
Internalizacja wiąże się z koniecznością dobrego dokumentowania kodu, zarządzania nim, dbania o poufność i bezpieczeństwo. To realne wyzwania, niemniej nie startujemy od zera – w obszarze sieciowym, na przykład w Network Operations Center, znacząca część wykorzystywanych narzędzi została opracowana wewnętrznie i dostosowana do naszych potrzeb. Taka od początku była filozofia działania Play.
