Optymalizacja chmury obliczeniowej w RECKITT: nieustanna gra o efektywność

Reckitt zbudował model obsługujący dynamiczne, efektywne środowisko wielochmurowe. O historii jego budowy, założeniach, wyzwaniach i korzyściach z posiadania takiej struktury opowiadają Piotr Hołownia, IT & Digital Director, Global Tech Platforms – Marketing & Sales i Krzysztof Kwiatek, IT& Digital Director – Product Stream Architect, Marketing & Sales.

W toku spotkań o FinOps często zastanawiamy się, w którym momencie model optymalizacji pojawia się w transformacji chmurowej. Czy w przypadku Reckitt optymalizacja stanowiła od początku element strategii podejścia do technologii i relacji z dostawcami?

Piotr Hołownia (PH): W naszym przypadku potrzeba optymalizacji kosztów infrastruktury była zasadniczą przyczyną migracji do modelu chmurowego. Chmura miała zastąpić sieć własnych centrów danych rozproszonych na całym świecie. Migracja oznaczała więc zarazem optymalizację strukturalną i kosztową. Wybraliśmy  moment, kiedy rozwiązania chmurowe i oferta operatorów chmurowych stały się bardziej dostępne pod względem cenowym.

Krzysztof Kwiatek (KK): Intencją tej decyzji było też pokazanie, że zmieniamy zasady i chcemy stać się firmą cloud-first. Doszliśmy do wniosku, że utrzymywanie data center on-premises jest kosztowne i zabiera nam czas, ponieważ musimy się skupiać na serwerach, bateriach, zasilaczach i temu podobnych zagadnieniach. Na poziomie korporacyjnym zapadła decyzja, aby uwolnić się od tego balastu w sposób bardzo zdecydowany. Byliśmy jedną z firm FMCG, która podjęła decyzję o migracji wszystkiego z on-premises do chmury.

Dlaczego wejście do chmury dokonało się „w dwóch krokach”? Czy to historia typu „lessons learned”?

KK: Za pierwszym razem nasza migracja przebiegała w sposób nieuporządkowany, bez planu strategicznego, gdzie chcemy być i jak chmura powinna wyglądać. Nie zaplanowaliśmy dobrze, jak powinna wyglądać infrastruktura.

Decyzja o migracji zakładała przeniesienie wszystkich aplikacji z on-premises do Azure, jak najszybciej ze względów kosztowych i kontraktowych.

Po analizie doszliśmy do wniosku, że modernizacja aplikacji rozciągnęłaby migrację na kilka lat. Podjęliśmy decyzję o tzw. “lift and shift”, czyli przeniesieniu tego, co mieliśmy on-premises, do chmury. Zbudowaliśmy Azure, który był imitacją dotychczasowego środowiska z wirtualnymi maszynami takimi, jak w on-premises. Byliśmy na tyle zdeterminowani, że do chmury przenieśliśmy nawet SAP-a.

To był błąd, co teraz wiemy. Stworzyliśmy pewnego rodzaju molocha, którym nie sposób było zarządzać. Widoczność kosztów była słaba, a rozliczenie kosztów produktów zgoła niemożliwe.

Drugim błędem było dalsze rozwinięcie migracji chmurowej w oparciu o pierwotne zasady na kolejne środowisko – Google Cloud. W Azure chmura była konstruowana z myślą o przyjęciu ruchu z on-premises, pod to skrojone były polityki i zasady bezpieczeństwa. Google Cloud miał natomiast być chmurą zorientowaną wokół produktów komercyjnych i marketingowych, opierającą się na nowoczesnych, natywnych komponentach chmurowych, a nie na wirtualnych maszynach i klasycznych architekturach. Ponownie jednak, pod presją czasu, próbowaliśmy skopiować do tego ekosystemu założenia, które zrobiliśmy w Azure, chociaż nie planowaliśmy przecież migracji z on-premises do Google Cloud. Szybko okazało się, że są one niedostosowane do konkretnych potrzeb produktowych. Dopuściliśmy pracę manualną, nie myśląc o infrastrukturze jako kodzie i DevOps, co było drugim błędem. Pozwoliliśmy, aby każdy produkt był budowany według własnych zasad, byleby mieścił się w ustalonych ramach bezpieczeństwa i infrastruktury.

Czy sytuację można było naprawić?

PH: Nie, zdecydowaliśmy się zresetować tę chmurę. Drugie wejście do chmury było już strategicznie przemyślane. Przygotowanie zajęło 12 miesięcy, a dopiero potem zaczęliśmy stawiać produkty w chmurze.

Oczywiście, za pierwszym razem zapłaciliśmy cenę za brak modernizacji aplikacji. Teraz modernizacja jest już założona w ramach migracji iodpowiednio widoczna w kosztach.

Druga migracja dokonywała się już stopniowo, aż do obecnej chwili, kiedy na różnych warstwach korzystamy z ekosystemów Amazon, Microsoft, a także naszego najnowszego nabytku – Google Cloud.

KK: Reset polegał na tym, że przestaliśmy budować nowe produkty w chmurze Google i przenosiliśmy stopniowo umieszczone w Azure aplikacje do on-premise. To był proces, Azure był cały czas dostępny, więc jeśli była krytyczna aplikacja, mogliśmy użyć jej z chmury. Nawet dotąd mamy jeszcze kilka produktów na tzw. Legacy Landing Zone, czyli na starej chmurze. Równocześnie przygotowywaliśmy zasady i strategię wykorzystania chmury oraz nowe podejście.

Jakie nowe „zasady” pojawiły się przy okazji drugiego otwarcia na chmurę?

PH: Reset to był ważny moment, kiedy jako organizacja stwierdziliśmy, że musimy przedefiniować naszą strategię technologiczną. Obecnie myślimy w sposób cloud-native i traktujemy chmurę jako kod (Infrastructure as Code), unikając manualnej modyfikacji chmury i wszystko wykonując z kodu.

Siłą chmury są natywne usługi, które skalują się w zależności od potrzeb. Dlatego – to nasza rekomendacja – jeśli chcesz wejść na nową chmurę, to wykorzystaj siłę natywnych usług dostawcy. Migracja będzie trwała dłużej, ale w dłuższej perspektywie się opłaci. Inaczej zapłacisz „frycowe”, zarówno w wymiarze czasu, jak i kosztów.

KK: Mamy nową strategię, która składa się z elementów adopt, adapt, assemble & buy and build – w skrócie “Triple A & B”. Kategoryzujemy wszystkie inwestycje chmurowe według tej metodyki.

Systemy, które klasyfikujemy jako „adopt” albo „adapt” to głównie systemy SaaS, gotowe rozwiązania od dostawców. Nasze zaangażowanie w utrzymanie infrastruktury jest bardzo małe, a zespoły są lekkie, oparte głównie na analitykach biznesowych. To po prostu gotowa usługa, którą musimy skonfigurować. Wówczas jest to “adapt”, kiedy zaś jest bardzo mała ilość konfiguracji – klasyfikujemy rozwiązanie jako “adopt”.

Trzecia kategoria, to “assemble”. To inicjatywy, projekty, produkty, serwisy, które budujemy wewnętrznie. Są to nasze perły w koronie, które pozwalają nam uzyskiwać przewagę konkurencyjną. Realizują zadania, których nie oferują produkty dostępne na rynku ani używane przez inne firmy. Możliwość budowy specyficznego modelu i/lub uzyskanie przewagi konkurencyjnej uzasadniają powołanie zespołu deweloperów, inżynierów, architektów i tworzymy produkt na chmurze, korzystając z jej możliwości.

Najgorsze z punktu widzenia efektywności strategii chmurowej są systemy, które klasyfikujemy jako “buy and build”. Wymagają dużego zaangażowania zespołów wewnętrznych, zespołu inżynierów i deweloperów, utrzymania pełnej infrastruktury, ale zarazem systemy te nie budują żadnej przewagi konkurencyjnej. Nie ma tam żadnego wkładu intelektualnego, który moglibyśmy przekuć na zysk, jak to ma miejsce w przypadku systemów sklasyfikowanych jako „assembly”.

Dlatego unikamy kategorii “buy and build”, nie budujemy wielu produktów na chmurze, chyba że uzasadniana to szansa na uzyskanie przewagi konkurencyjnej i własność intelektualna, którą można zmonetyzować. W innym wypadku wybieramy spośród oferty rozwiązań na rynku i kupujemy usługi, minimalizując koszty utrzymania takich systemów.

W raporcie State of Application Strategy 2024 firmy F5 pojawiła się informacja, że około 40% firm zarządza środowiskiem złożonym z sześciu chmur. Jak złożone jest środowisko chmurowe w przypadku Reckitt?

PH: Mamy dużych hiperskalerów, trzy największe ekosystemy, ale mamy też np. Salesforce, który jest chmurą rozbitą na Marketing Cloud, Service Cloud i Sales Cloud. To dodatkowe rozwiązania, które muszą być zintegrowane. Podobnych chmur – które serwują nam różne rozwiązania – jest więcej.

Można więc powiedzieć, że mamy wiele chmur, które zostały dopasowane do konkretnego biznesu, także pod względem zdolności do integracji oraz możliwości przenoszenia pomiędzy nimi aplikacji czy funkcji.

Widzimy tu trzy kluczowe elementy. Po pierwsze – dostosowanie do specyfiki branży, czyli „chmura „dla banku” nie będzie dobrym rozwiązaniem dla firmy sprzedażowo-produkcyjnej. Po drugie – niezbędna jest sprawna komunikacja i integracja aplikacji, mimo, że leżą w różnych środowiskach. I wreszcie, pPo trzecie, jeśli aplikacja przestaje działać efektywnie, musimy płynnie przenieść ją do innego środowiska albo pozyskać nową.

Kto uczestniczy w określaniu kategorii adopt, adapt & build and buy?

KK: Kategoryzacja rozpoczyna się, kiedy rozważamy, jakie możliwości, potencjał i potrzeby reprezentuje dany produkt. Jeśli uznamy, że potrzebujemy specyficznych możliwości i należy pozyskać nowy produkt wewnętrzny, to produkt otrzymuje plakietkę “adopt” albo “adapt”. Jeśli te cechy i możliwości nie tworzą unikalnej wartości, jeśli produkt nie buduje przewagi konkurencyjnej, to wchodzimy w proces wyboru dostawcy. Szukamy wtedy usług typu SaaS (Software as a Service). Taka klasyfikacja zaczyna się już na poziomie Request for Proposal (RFP). Do każdego RFP przypisany jest architekt, który kategoryzuje usługę.

Jeśli na rynku nie dostrzeżemy odpowiednich rozwiązań, wówczas inwestujemy w zespół z deweloperami i architektami. Zwykle współpracujemy z partnerami, ale w oparciu o koncepcję zespołu podstawowego i rozszerzonego. W zespole podstawowym zatrudniamy ludzi, którzy wewnętrznie pracują nad projektem i gromadzą wiedzę na temat rozwiązania. Uzyskujemy wiedzę także od partnerów i tworzymy wspólnie z nim rozszerzone zespoły. Zwykle pomagają one budować produkty typu “assemble”. Takich rozwiązań jest 5-10%.

PH: Dążymy także do tego, aby zmieniać aplikacje typu “buy and build” na bardziej efektywne. Staramy się je konwertować, zmniejszając wolumen aplikacji. Przy pomocy rozwiązań chmurowych integrujemy je lub zamieniamy na bardziej uniwersalne. Nazywamy to działanie “as common as possible”. Podejście platformowe zakłada, że możliwości danej platformy lub rozwiązania będą używane w maksymalnie dużej liczbie produktów, nie można więc mnożyć specyficznych funkcji i cech dla każdego produktu.

Nasz tryb optymalizacji zakłada także stałe uzyskiwanie oszczędności. Można je osiągać dopuszczając przenoszenie zasobów do środowiska o korzystniejszych warunkach. Korzyści z migracji płyną z oszczędności czasu, kosztów lub zwiększaniamożliwości rozwiązań w trakcie tranzycji. Na przykład zmieniamy system “buy and build” na unikalne IP, które przynosi nam przewagę konkurencyjną.

W praktyce często migracja jest sfinansowana z różnicy w kosztach utrzymania. Tak jest obecnie w przypadku migracji z innych środowisk chmurowych do Google Cloud. Kalkulacja kosztów obejmuje także wybory pomiędzy wykorzystaniem kompetencji partnera a budową ich wewnątrz firmy. Dążymy bowiem do stałego wzbogacania ich zestawu. Procentuje to w procesie walidacji i optymalizacji. Dzięki kompetencjom wewnętrznym trafniej wybieramy rozwiązanie, dostawcę i środowisko.

Jakiego rzędu są to korzyści – żeby w skali globalnej opłacało się utrzymywać taką dynamikę portfela?

PH: Zmiana chmury i rozwiązania potrafi nam przynieść nawet nam trzy-czterokrotną redukcję kosztów, uwzględniając lepsze dopasowanie do aktualnych potrzeb biznesowych, koszty integracji, czas zmiany oraz przychody uzyskiwane przez produkty dzięki możliwościom nowego środowiska.

KK: Są również wyjątki, kiedy dostrzegamy, że system “adapt” albo “adopt” jest wyjątkowo drogi. To także skłania nas do zmiany. Jeśli jest olbrzymia marża na takim serwisie, a system jest krytyczny, rozważamy, czy warto płacić za taką usługę. Mieliśmy niedawno sytuację, kiedy przenieśliśmy usługę na naszą wewnętrzną chmurę. Uzyskaliśmy trzykrotne zejście z kosztów, ponieważ marża dostawcy była bardzo wysoka, a nie było uzasadnienia budowy tej usługi na chmurze. Przejście i odbudowa tej usługi trwały około czterech miesięcy, więc opłacało się.

Jak często weryfikujecie samą kategoryzację?

KK: W podejściu produktowym opieramy się na katalogu produktów i platform IT. Każdy produkt i każda platforma mają swojego menadżera, który ma za zadanie zwiększenie efektywności czy liczby funkcjonalności. Stale monitoruje produkt, aplikacje i usługi, które go budują, aby zapewnić, że są one najlepsze. Generalna rewizja tych warunków ma miejsce przynajmniej raz w roku. Dokonujemy ją z biznesem, aby sprawdzić, czy produkt spełnia warunki i metryki, oraz czy coś należy zmienić.

A sytuacja jest rzeczywiście dynamiczna – inaczej mówiąc: mamy komfort i duże pole manewru, zmiany. Możemy rozpatrywać różne scenariusze. Na przykład niedawno zainwestowaliśmy w duże, drogie usługi, których funkcjonalności nie bylibyśmy w stanie zbudować wewnętrznie ze względu na bardzo zaawansowane algorytmy. Po roku zaczęliśmy się zastanawiać, czy chcemy utrzymywać tak drogie usługi, czy przynoszą oczekiwaną wartość. Myślimy o podzieleniu ich na mniejsze usługi lub zostawieniu tylko jądra i odbudowaniu reszty we własnym zakresie.

To jest zatem stałe doskonalenie, nieustanna gra o efektywność. Rozwój technologii jest bardzo szybki. Dlatego projektujemy naszą architekturę w sposób modularny, aby łatwo włączać i wyłączać usługi w naszym ekosystemie. To nie jest za darmo, ale wnosi bardzo cenną, wymierną wartość w postaci stałej gotowości na zmiany.

Jakie jeszcze czynniki wpływają na potrzebę utrzymania tej stałej gotowości, zdolności do zmiany w układzie środowisk chmurowych?

PH: Z pewnością dynamiczny rozwój AI mocno testuje możliwości i założenia naszego modelu operacyjnego. W naszym przypadku bardzo stawiamy na generatywną AI, która intensywnie korzysta z chmur.

Dzisiaj chmury stały się już enablerem a nie celem samym w sobie. Dane, które posiadamy muszą być scentralizowane i łatwo dostępne dla rozwiązań AI. Kluczowa dla nas jest wiedza o tym jakie dane udostępniamy i z jakich systemów źródłowych je pozyskujemy, żeby je efektywnie dostarczyć do produktów analitycznych a następnie do docelowych front-endów.

Wykonaliśmy Proof-of-Concept kilku rozwiązań AI i już widzimy, że wdrażanie sztucznej inteligencji szybko zmienia zasady gry w naszym biznesie. Mogę przytoczyć kilka wartości. Na przykład w obszarze kreacji i tworzenia nowych zasobów wizualnych, np. grafik do naszych reklam, czas przygotowania konceptu można zredukować o 60%, przy równoczesnej znacznej poprawie jakości wyjściowych materiałów. Dzięki generatywnej AI i optymalizacji wykorzystania chmur, mamy też 30% redukcji czasu wymaganego do lokalizacji reklam i komunikacji na poszczególnych rynkach. Potrafimy też zredukować powtarzalne czynności w procesach. Czas analizy skuteczności kampanii zredukowaliśmy o 90%, a jakość wyników poprawiła się dwukrotnie. Te konkretne, wymierne korzyści płyną z faktu, że chmury są zintegrowane i dostarczają właściwe dane dla rozwiązań analitycznych.

W jakim stopniu w obecnym modelu zarządza się zmianami? Z jednej strony falą wniosków o zmianę ze strony biznesu, z drugiej ciągłymi zmianami w środowiskach dostawców? Te ostatnie mogą przecież wymagać ponownej walidacji sensowności, oceny konieczności np. całej gałęzi usług czy produktów.

PH: Dużą rolę w zapewnieniu elastyczności odgrywają narzędzia, które zbudowaliśmy. Postawiliśmy na Enterprise Multi-Cloud Landing Zone, gdzie mamy zintegrowane bezpieczeństwo, standardy i automatyzację. Na landing zone dla naszego całego ekosystemu wielochmurowego mamy współdzieloną zabezpieczoną i zintegrowaną infrastrukturę.

Bardzo ważne jest wspólne repozytorium, do którego ma dostęp także zespół ds. bezpieczeństwa. Repozytorium nie służy jedynie do przechowywania i zrzutu obrazów danych, ale także do weryfikacji, czy moduły, które wchodzą na produkcję lub do poszczególnych środowisk, są bezpieczne. Repozytorium pełni zatem dodatkową funkcję zabezpieczenia. Mamy ponadto bibliotekę modułów Terraform, która jest zintegrowana logicznie z innymi hiperskalerami. Korzystamy w dużej mierze z gotowych modułów i przygotowanych setów. Jeśli jest duże zapotrzebowanie ze strony biznesu na środowiska dla zespołów aplikacyjnych, korzystamy z rozwiązania Project Factory. To automatyczne powoływanie środowisk, proste i transparentne.

KK: Użytkownicy biznesowi czy menedżerowie produktów poszczególnych marek na różnych rynkach korzystają z wystawionego interfejsu. Naszym zadaniem jest przygotowanie platformy i rozwiązania z back-end’em, który działa automatycznie.

Aby temu podołać wdrożyliśmy zautomatyzowane podejście DevOps’owe. Celem jest zapewnienie dobrego funkcjonowania dla klienta końcowego, czyli na przykład w e-commerce czy warstwach klienckich naszych aplikacji B2B. Stworzyliśmy środowisko narzędziowe dla chmur, które jest maksymalnie zautomatyzowane.

Mówimy tutaj już o ulokowaniu zespołu platformowego w modelu operacyjnym.

KK: Model operacyjny daje nam możliwość szybkiego skalowania. Obejmuje zespół platformowy, który dba o komponenty, bibliotekę artefaktów i bezpieczeństwo, ale nie buduje produktów. Produkty tworzą wyznaczone zespoły, które posiadają autonomię w wyborze partnerów z zatwierdzonej przez zespół platformowy listy. Tę swobodę wyboru nazywamy “freedom in the box”. Są oparte o zasady bezpieczeństwa, ale sama budowa produktu pozostaje już do decyzji „produktowców”. Niekiedy wymagają one zaangażowania inżynierów tworzących je od zera, kiedy indziej zespoły ograniczone są do zespołu partnerów, naszego menedżera produktu i analityka biznesowego. Takie podejście pozwoliło nam na uniknięcie ryzyka wąskich gardeł: każdy pracuje trochę inaczej, ale zgodnie z modelem.

Czy istnieje potrzeba i możliwość rozmywania granicy w relacji między twórcami produktu a dostawcami platformy, np. poprzez narzędzia typu prosty kalkulator, który przedstawia wybory i ich konsekwencje architektoniczne?

KK: Mamy architektów, którzy doradzają zespołom produktowym. Każdy strumień IT jest podzielony na strumienie produkcyjne, przypisane do łańcuchów wartości. My reprezentujemy strumień marketingowy i serwisowy. Tak jak pozostałe nasz strumień posiada jednostkę produktową z architektami doradzającymi menedżerom produktu jak powinien on wyglądać, z czego korzystać i przypominać główne zasady. Zespół dba o efektywność produktu, wykorzystanie strategicznych platform i capabilities, które mamy, aby nie budować czegoś od nowa.

Czy koszt całego tego aparatu jest szacowany i jest on opłacalną inwestycją?

KK: Warto może na wstępie uporządkować, dlaczego model produktowy znacząco zredukował koszt operacyjny IT.

Wpływ na to miało kilka rzeczy, w tym strategia lokalizacyjna. Inżynierowie są zlokalizowani w dwóch hubach: w Warszawie i indyjskim Hajdarabadzie. W Warszawie skoncentrowaliśmy kompetencje analityki danych i marketingu, a w Indiach kompetencje w klasycznych systemach, takich jak SAP i finansowe. To była pierwsza rzecz, którą zrobiliśmy podczas transformacji z organizacji projektowej do produktowej.

Zrezygnowaliśmy dzięki temu także z wielu dostawców, bo to było nieefektywne. Każdy rynek miał swoich partnerów. Zmniejszyliśmy także liczbę kontraktorów, którzy byli z nami bardzo długo, co również było nieefektywne. Wiele projektów realizowało ten sam cel, tylko dla różnych regionów. Skonsolidowaliśmy te potrzeby i stworzyliśmy globalny, skalowalny produkt. Oraz jeden zespół produktowy, który dostarcza produkt na wiele rynków. Konsolidacja tych potrzeb i analiza modelu możliwości pozwoliła nam ograniczyć portfolio przynajmniej o 20%.

Po drugie, nastąpiła zmiana na strukturę, w której redukujemy liczbę kontraktorów na rzecz zespołów wewnętrznych. Wiele osób jest zaskoczonych, że utrzymywanie zespołów wewnętrznych na dłuższą metę jest bardziej opłacalne. W naszym wypadku – zdecydowanie tak, ponieważ mamy zdefiniowany trzyletni, kroczący plan pracy dla tych zespołów.

Te dwie zmiany czynią model racjonalnym i opłacalnym.

PH: Ja trochę odwrócę pytanie. Nie bedę mówił o mechanice wyliczania kosztów, bo musielibyśmy wejść w zbyt duży poziom szczegółowości. Wyjdźmy raczej od zagadnienia unikania niepotrzebnych i niekontrolowanych kosztów.

Przy środowisku wielochmurowych niezbędne jest posiadanie dobrze zorganizowanej struktury FinOpsa. Muszą w niej działać ludzie, którzy potrafią liczyć utylizację chmury, na bieżaco optymalizować koszty chmury, robić audyty i dostrzegać luki w możliwościach narzędzi. Niezbędne są też dobre kompetencje w zakresie bezpieczeństwa. Jeśli chce się myśleć na poważnie o działaniu w multi-cloud to tych ludzi po prostu mieć lub zatrudnić jeśli nie ma ich w organizacji. Z kolei dobry zespół SecOps pozwoli zabezpieczyć środowisko chmurowe, zwłaszcza jeśli krytyczne biznesowo procesy są realizowane za pośrednictwem „chmur”.

Decydując się na środowisko wielochmurowe, można też spróbować pozyskać kompetencje na zewnątrz. Czasem rzeczywistość weryfikuje te plany, ponieważ nie wszyscy partnerzy są na to gotowi dostarczyć gotowe do pracy zespoły o wymaganych kompetencjach chmurowych. Z koleitworząc wewnętrzny zespół najlepiejod razu szukać specjalistów, którzy posiadają wiedzę o wielu chmurach, a nie tylko o jednej.

Generalnie potrzebny jest wszechstronny zespół, który ma mocne umiejętności w zakresie budowania platform technologicznych. Budowa takiego zespołu to w zasadzie niezbędny element długofalowej strategii chmuorwe. Taki zespółrozwija się wraz z nabywaniem poszczególnych chmur, migracjami i tak dalej. To zespół, który jest zespołem DevSecOps albo zespołem SRE, w zależności od podejścia technologicznego i inżynierskiego w organizacji.

I to są w zasadzie kluczowe aspekty, na których należy się skupić aby uniknąć dużych kosztów „chmur” a same koszty migracji nie wymknęły się spod kontroli,

KK: Warto dodać jeszcze jedno: skupić się na produktach, które przynoszą wartość. Przy podejściu projektowym zauważyliśmy, że robiliśmy tysiące projektów i nikt do końca tego dobrze nie rozliczał. Przy podejściu produktowym, menedżerowie produktów czuwają nad wdrożeniem ich i na bieżąco monitorują wskaźniki jego efektywności.

Raz w roku z biznesem robimy wielkie ćwiczenie, tzw. roadmap planning. Angażujemy odbiorców końcowych naszych produktów technologicznych i oni definiują biznesowy kierunek rozwoju. Odrzucamy w tym procesie dużą ilość pomysłów, które nie przynoszą wartości. Produkt jest budowany z biznesem, jesteśmy dla nich partnerem, a nie centrum kosztów, jak było za czasów organizacji projektowej. Jesteśmy współodpowiedzialni za to, gdzie firma idzie, jeśli chodzi o rozwiązania digitalowe.

Jesteśmy też bardzo selektywni, szczególnie teraz, gdy mamy różne wyzwania związane z kosztami stałymi. Czasami podejmujemy decyzję, że nawet jeśli produkt jest dobry i przynosi wartość, ale nie oczekiwaną wartość, to musimy go wycofać.

Rozmawialiśmy o wyzwaniu dla jakości multi-cloud jakim jest adaptacja Gen AI. Czy na rynku chmurowym rysują się jakieś inne “ruchy płyt tektonicznych”? Ryzyka lub wyzwania, zarówno w skali makro, jak i mniejsze?

KK: Ważnym uwarunkowaniem jest silna konsolidacja.

Z punktu widzenia rynku mamy 3-4 graczy. To oczywiście za mało. Silna konsolidacja największych graczy może być ryzykiem, tym bardziej że nie widać kolejnego, który próbowałby dojść do tej stawki. AI zmienia dużo, ale widać już, że raczej nie zmieni układu rynkowego, ponieważ dostawcy tych środowisk otwierają się na swoje modele.

Dostrzegam także poważny trend minimalizacji transferu danych klasycznymi ETL-ami (podejście Extract, Transfer, Load Balancer). Jest wiele usług, które w czasie rzeczywistym pozwalają czytać ogromne ilości danych bez potrzeby kopiowania ich z jednego miejsca do drugiego. Można zapuszczać zapytania na źródle i przetwarzać dane bezpośrednio ze źródła. Umozliwiją to na przykład DataBricks i Google BigQuery. To istotnie zmienia świat integracji, który będzie wyglądał już za chwilę inaczej.

Powstaje wiele platform z predefiniowanymi konektorami, które są dedykowane pod konkretne potrzeby. Nie trzeba budować integracji, bo posiadają gotowy zestaw 300 konektorów, wystarczy skonfigurować hasła i certyfikaty. Oferują one też szablony raportów pod specyficzne zastosowania. To jest kuszące dla firm branży FMCG, bo koszty wejścia i utrzymania są niskie, a czas dostarczenia na rynek produktu bardzo krótki. Pojawia się jednak ryzyko, że firma stanie się zakładnikiem takiej usługi i nie jest właścicielem danych. A dane to najważniejszy zasób firmy takiej jak nasza.

PH: Bardzo ważne jest to, że dostawcy chmurowi zorientowali się, że trzeba dostosować się do specyfiki sektora i biznesu. I dlatego potrafią integrować dedykowane rozwiązania i wystawiać je jako gotowe moduły do wykorzystania w poszczególnych branżach.

Można tę sytuację porównać do sytuacji z modelami AI. Generyczne modele, które korzystają z szerokiego spektrum danych są niedokładne. Przyszłość to wyspecjalizowane modele w konkretnych domenach, wertykałach, które dają wysoką jakość odpowiedzi i usprawniają konkretne procesy w konkretnych biznesach i branżach.

Bardzo zauważalna jest wysoka dostępność i otwartość dostawców chmurowych. Korzystamy z tego, ale staramy się postępować ostrożnie. Po prostu nie można mieć za wielu chmur, ponieważ stanowi to obciążenie kosztowe i obciążenie organizacyjne – zarządzanie staje się zbyt złożone.

KK: W takie pułapki często wpadają start-upy. Jak urosną szybko, koszty licencji mogą wzrosnąć błyskawicznie o 40-50%. To ryzyko, bo zarazem biznes jest mocno osadzony na tej usłudze. Dostawcy wiedzą, że nie wyjdziesz z niej w ciągu dwóch miesięcy. Widzieliśmy także sytuacje, gdzie usługa została przejęta przez dużego gracza i automatycznie zmieniły się koszty licencji.

PH: Dlatego lepiej skupić się na najważniejszych „chmurach” z punktu widzenia danej organizacji. Zidentyfikować kluczowe biznesowo dane i przy okazji wykonywania migracji zwiększyć ich dostępność cross-domenowo. I co bardzo ważne – pozostać właścicielem danych, które generują wartość i przewagę konkurencyjną. To elementarne zasady gotowości i bezpieczeństwa na wypadek zmiany chmury czy dostawcy.

Piotr Hołownia i Krzysztof Kwiatek będą bohaterami spotkania CXO HUB 26 września w Warszawie. Przedstawią koncepcję i rozwój strategii chmurowej w Reckitt. Serdecznie zapraszamy!