Stara platforma blokuje wzrost. Dlaczego firmy decydują się na kosztowny re-platforming [wywiad]

Re-platforming w e-commerce przestaje być projektem technologicznym, a staje się decyzją strategiczną, która wpływa na tempo wzrostu, koszty operacyjne i zdolność do skalowania biznesu. O tym, kiedy zmiana platformy ma sens i jakie błędy najczęściej popełniają firmy, rozmawiamy z Agą Orłowską – senior business consultant & sales team lead w Divante, specjalizującą się w łączeniu celów biznesowych z technologią – oraz Michałem Frydrychem, head of delivery w Divante, który odpowiada za realizację złożonych projektów technologicznych i wspiera organizacje w wyborze optymalnej architektury e-commerce.

Aga Orłowska, senior business consultant & sales team lead w Divante. Specjalizuje się w łączeniu celów biznesowych z możliwościami nowoczesnych rozwiązań, wspierając firmy w podejmowaniu trafnych decyzji inwestycyjnych i budowaniu skalowalnych e-commerce. Łączy podejście biznesowe z technologicznym, koncentrując się na budowaniu relacji i poszukiwaniu rozwiązań, które realnie wspierają rozwój organizacji i ich produktów cyfrowych.

Michał Frydrych, head of delivery w Divante. Odpowiada za obszar delivery, nadzorując realizację złożonych projektów i pracę zespołów technologicznych. Łączy perspektywę biznesową i technologiczną, dbając o to, aby rozwiązania realnie wspierały cele organizacji. Rozpoczął karierę jako programista, następnie lider techniczny oraz analityk biznesowy z silnym doświadczeniem w e-commerce, budowaniu custom rozwiązań (w tym AI) i poszukiwaniu innowacji. Wspiera firmy w wyborze takiej ścieżki technologicznej, która najlepiej odpowiada ich długofalowej strategii.

Słuchaj podcastu „E-commerce bez tajemnic”

Czym właściwie jest dziś re-platforming w e-commerce i jak często firmy się na niego decydują? Jakie korzyści daje?

Aga Orłowska: Dziś replatforming często nie zaczyna się od problemu z samą platformą. W pracy najczęściej spotykam się z sytuacją, w której system działa, ale przestaje nadążać za tempem biznesu lub realnie go ogranicza. Najczęściej widać to przy integracjach, wejściu na nowe rynki albo przy próbie szybkiego wdrażania zmian. W praktyce replatforming jest dziś elementem dojrzałej strategii rozwoju e-commerce, a nie wyłącznie projektem IT. To moment, w którym organizacja zadaje sobie pytanie, czy obecne rozwiązanie jeszcze wspiera ambicje biznesowe, czy już je ogranicza.

Michał Frydrych: Najczęstszym triggerem jest rosnący koszt utrzymania – licencje, dług techniczny i customizacje, które pochłaniają większość budżetu IT – oraz zbyt wolne tempo wprowadzania zmian, gdy wdrożenie nowej funkcji trwa miesiące zamiast tygodni. Efektem udanej migracji jest niższe TCO, szybszy time-to-market i większa autonomia biznesu wobec IT. Trzeba jednak powiedzieć wprost: to kosztowne i ryzykowne przedsięwzięcie, które dla dużego klienta trwa 12–24 miesiące – dlatego zawsze warto najpierw sprawdzić, czy problem leży w platformie, czy w procesach.

Firmy coraz częściej podejmują taką decyzję, ale nie dlatego, że chcą „zmienić system”, tylko dlatego, że chcą odzyskać tempo. Z raportów wynika też, że dla wielu organizacji modernizacja platformy to dziś element strategii wzrostu, a nie tylko projekt technologiczny.

Aga Orłowska : Z danych rynkowych wynika, że firmy jako główne powody wskazują właśnie potrzebę większej skalowalności, szybszych wdrożeń i lepszego UX. Najczęściej zgłaszają się wtedy, kiedy pojawia się zderzenie między ambicją biznesową, a możliwościami obecnej platformy. Słyszę to bardzo często w rozmowach z klientami. Chcemy szybciej wdrażać zmiany. Chcemy wejść na nowe rynki. Chcemy poprawić UX. Chcemy lepiej wykorzystywać I nagle okazuje się, że obecny system wymaga zbyt wielu obejść i kompromisów.Firmy deklarują zwykle, że chcą poprawić doświadczenie klienta, zwiększyć skalowalność i przyspieszyć innowacje. W praktyce często zaczyna się od bardzo konkretnych problemów operacyjnych, takich jak zbyt długi time to market albo wysokie koszty utrzymania. To właśnie te obszary najczęściej uruchamiają decyzję o zmianie

Michał Frydrych: Dokładnie to widzę w praktyce – decyzja o re-platformingu rzadko rodzi się w dziale IT, coraz częściej przychodzi z biznesu, od CDO albo CMO, którzy po prostu nie mogą już realizować roadmapy na obecnym systemie. I tu jest kluczowa zmiana mentalna: kiedyś to był „projekt technologiczny z budżetem IT”, dziś coraz częściej traktowany jest jako inwestycja wzrostowa z biznesowym sponsorem i mierzalnymi KPI. Zgadzam się też z obserwacją Agi – operacyjny ból (koszty, TTM) jest tym, co uruchamia rozmowę, ale ambicja biznesowa jest tym, co ją domyka i nadaje projektowi właściwy priorytet w organizacji.

Jakie są najczęstsze powody rozpoczęcia procesu re-platformingu? Czy firmy częściej działają proaktywnie (planując rozwój), czy raczej reaktywnie (gasząc problemy)?

Aga Orłowska: Odpowiem moją ulubioną frazą “to zależy”. Zazwyczaj zaczyna się od: „mamy za dużo ograniczeń”, „za długo wdrażamy zmiany”, „koszt utrzymania jest za wysoki”, „za dużo rzeczy robimy ręcznie”. Czyli impulsem jest konkretna bariera operacyjna albo biznesowa. Dopiero później ta potrzeba jest ubierana w język transformacji. Muszę jednak przyznać, że potwierdzają to też trendy rynkowe, jak i rozmowy z biznesami, że coraz częściej spotykam się z dojrzałym, proaktywnym podejściem. To oni wygrywają, bo zmieniają się przed kryzysem. Jeden z naszych klientów, sponsor jednego z największych wydarzeń sportowych, przewidział, że ten event wymagać będzie pełnej gotowości e-commerce na ogromny ruch, a my odpowiednio wcześniej pomogliśmy im się przygotować. Ta różnica może zdecydować o przewadze: zamiast gasić pożary, lepiej proaktywnie budować przyszłość.

Michał Frydrych: Ten podział na reaktywnych i proaktywnych klientów bardzo dobrze widać też z perspektywy delivery. Reaktywni przychodzą z gotowym pożarem – mają deadline, presję zarządu i chcą działać „na wczoraj”, co z definicji utrudnia dobre zaplanowanie migracji i zwiększa ryzyko projektu. Proaktywni dają sobie i nam przestrzeń na porządną analizę, discovery, wybór architektury – i efekty są nieporównywalnie lepsze. Przykład z eventem sportowym jest świetny, bo pokazuje coś ważnego: re-platforming ma sens tylko wtedy, kiedy nowa platforma jest gotowa zanim pojawi się prawdziwe obciążenie – nie w trakcie. Z mojego doświadczenia firmy, które podchodzą do tego proaktywnie, traktują technologię jako dźwignię wzrostu, a nie zaplecze do obsługi zamówień. I to widać potem w wynikach projektu.

Jak powinien wyglądać etap przygotowawczy? Jakie analizy, dane i decyzje są absolutnie kluczowe, zanim jeszcze zacznie się wybór technologii?

Aga Orłowska: To kluczowy moment, w którym najłatwiej popełnić kosztowny błąd. Są firmy, które zaczynają od wyboru platformy, zamiast sprawdzenia, co realnie nie działa. Czasami problem jest jedynie symptomem. Na tym etapie kluczowe są dane! O sprzedaży, konwersji, porzuceniach koszyka, kosztach operacyjnych, sytuacji rynkowej i od samych użytkowników. Równie ważne jest zmapowanie procesów wewnętrznych, które decyzje są blokowane przez technologię. W praktyce przygotowanie do replatformingu powinno kończyć się wspólnym obrazem tego, co działa, co należy usprawnić, a co przebudować.

Michał Frydrych: Największe błędy, które widziałem w projektach migracyjnych, wynikały właśnie z tego, że ktoś przyszedł z gotową decyzją o platformie, zanim w ogóle zrobił rzetelną analizę. Z perspektywy delivery dodałbym jeszcze jeden element, który często jest pomijany: audyt integracji i zależności technicznych. Firmy przychodzą z listą 5 integracji, a w trakcie discovery okazuje się, że jest ich 40, część nieudokumentowana, część trzymana przez zewnętrznych dostawców, którzy już nie istnieją. To potrafi podwoić budżet i harmonogram projektu. Dlatego etap przygotowawczy powinien zawsze kończyć się nie tylko wspólnym obrazem stanu obecnego, ale konkretną mapą ryzyk i jasną odpowiedzią na pytanie: co migrujemy, co przepisujemy od zera, a co celowo wyrzucamy. Bez tego wybór platformy to wróżenie z fusów.

W praktyce często pojawia się napięcie między „odtworzeniem starego systemu” a jego przebudową. Jak podejść do decyzji: co migrujemy 1:1, a co redefiniujemy od zera?

Aga Orłowska: Często okazuje się, że część procesów istnieje tylko dlatego, że kiedyś były koniecznym workaroundem lub reliktem legacy. Staram się oddzielić to, co realnie wspiera biznes, od tego, co jest przyzwyczajeniem. Replatforming nie powinien polegać na kopiowaniu starego systemu, tylko na odtworzeniu wartości, którą ma przynosić.

Michał Frydrych: Z perspektywy delivery mam prostą heurystykę, której używam w rozmowach z klientem: jeśli nie potrafisz wyjaśnić, dlaczego dany proces działa tak, a nie inaczej, bez odwoływania się do historii systemu – to jest kandydat do redefinicji, nie do migracji. Problem w tym, że organizacje mają naturalną tendencję do kopiowania tego, co znają, bo to minimalizuje opór wewnętrzny. „Zróbcie dokładnie to samo, tylko na nowej platformie” – to zdanie słyszę regularnie i zawsze jest sygnałem ostrzegawczym. W praktyce stosuję podejście trzech koszyków: migrujemy to, co realnie tworzy wartość i działa dobrze, redefiniujemy to, co działa, ale generuje niepotrzebne koszty lub tarcia, i świadomie wyrzucamy to, co istnieje tylko dlatego, że kiedyś nie było innego wyjścia. Ten trzeci koszyk jest zazwyczaj największym zaskoczeniem dla klienta – i największą oszczędnością.

Na ile re-platforming może/powinien być impulsem do zmiany modelu biznesowego, a nie tylko warstwy technologicznej?

Aga Orłowska: Sama technologia tego nie zrobi, ale może bardzo mocno przyspieszyć realizację nowej strategii lub otworzyć zupełnie nowe, nieznane drzwi. Zamiast tylko technologicznego liftu, staje się okazją do redesignu całego sposobu zarabiania. Z mojego doświadczenia w projektach wynika, że klienci, którzy wykorzystują moment replatformingu na realny redesign, na przykład wdrożenie B2B self-service w trakcie migracji, budują przewagę konkurencyjną na lata. Z kolei organizacje skupione wyłącznie na warstwie technologicznej często tracą tę szansę. Potwierdzają to również dane. Raport commercetools z 2025 wskazuje, że „90% organizacji po re-platformingu raportuje wzrost przychodów i sprzedaży”, często dzięki nowym możliwościom, takim jak modele oparte na AI. To jasno pokazuje, że zmiana platformy to nie lift and shift, ale realna szansa na transformację biznesową.

Michał Frydrych: Re-platforming jako impuls do zmiany modelu biznesowego działa wtedy, kiedy ta ambicja jest zdefiniowana przed projektem, nie w jego trakcie. Jeśli klient w połowie migracji decyduje, że „przy okazji” wdraża B2B self-service i nowy model subskrypcyjny – to prawie zawsze kończy się przekroczeniem budżetu, opóźnieniem i frustracją po obu stronach. Dlatego z perspektywy delivery zawsze pytam na samym początku: jakie drzwi chcecie otworzyć za 2–3 lata? Nie po to, żeby to wszystko wdrożyć od razu, ale żeby wybrać architekturę, która to umożliwi, zamiast ją blokować. Te 90% organizacji raportujących wzrost przychodów, o których wspomina raport commercetools, to właśnie firmy, które miały tę wizję z góry – technologia była narzędziem do jej realizacji, a nie celem samym w sobie.

W kontekście wyboru technologii: jakie są dziś najczęstsze błędne założenia firm e-commerce przy podejmowaniu decyzji o platformie?

Michał Frydrych: Pierwszym i najczęstszym błędnym założeniem jest przekonanie, że platforma rozwiąże problem organizacyjny. Widziałem firmy, które wdrożyły najnowocześniejszy composable commerce stack, a po 18 miesiącach miały dokładnie te same problemy co wcześniej – bo problem leżał w procesach i strukturze zespołów, nie w technologii. Drugi błąd to wybór platformy pod demo. Platforma, która wygląda świetnie na prezentacji vendora, potrafi być koszmarem w utrzymaniu przy specyficznych wymaganiach klienta. Dlatego zawsze rekomendujemy proof of concept na realnych procesach klienta, nie na przykładowych scenariuszach ze slajdów. Trzeci, bardzo kosztowny błąd, to niedoszacowanie kosztów operacyjnych na rzecz kosztów wdrożenia. Firmy negocjują twardo cenę licencji i budżet projektu, a potem okazuje się, że utrzymanie zespołu zdolnego obsługiwać wybraną architekturę kosztuje dwa razy więcej niż zakładano. Composable commerce to świetne podejście, ale wymaga dojrzałego zespołu.

I ostatni, który boli mnie najbardziej: wybór technologii pod aktualny trend, a nie pod realny kontekst biznesowy. Nie każda firma potrzebuje headless. Nie każda potrzebuje mikroserwisów. Czasem najlepsza decyzja to solidna platforma SaaS z mniejszym stopniem swobody, ale znacznie niższym TCO i krótszym time to market. Dopasowanie architektury do skali i dojrzałości organizacji to trudniejsza rozmowa niż wybór między vendorami – ale to właśnie ta rozmowa decyduje o sukcesie projektu.

Jakie znaczenie mają integracje (API, systemy zewnętrzne) w całym procesie? Czy chmura to już standard przy re-platformingu, czy nadal są przypadki, gdzie nie jest najlepszym wyborem?

Michał Frydrych: Integracje to absolutnie krytyczny element i, szczerze mówiąc, najczęściej niedoceniany na etapie planowania. Z mojego doświadczenia to właśnie integracje – nie sama migracja platformy – pochłaniają największą część budżetu i czasu w projekcie. Wspomniałem już wcześniej o audycie integracji jako obowiązkowym elemencie discovery i to nie jest przesada. Co do chmury – powiem wprost: dla zdecydowanej większości firm e-commerce to dziś de facto standard i trudno mi wyobrazić sobie rekomendowanie on-premise w nowym projekcie bez bardzo konkretnego uzasadnienia. Elastyczność kosztowa, auto-scaling w peakach sprzedażowych, bezpieczeństwo, ekosystem gotowych usług – to argumenty, które wygrywają praktycznie zawsze.

Są jednak przypadki, gdzie chmura nie jest oczywistą odpowiedzią. Przede wszystkim regulowane branże – fintech, część healthcare – gdzie wymagania compliance i lokalizacji danych potrafią bardzo komplikować architekturę chmurową. Drugi przypadek to firmy z bardzo specyficznym, przewidywalnym ruchem i własną infrastrukturą, gdzie TCO chmury po prostu nie domknie się finansowo. Ale to są wyjątki, nie reguła. W praktyce częściej rozmawiam z klientami o tym, który cloud i jaką strategię multi-cloud, niż o tym, czy w ogóle iść w chmurę.

Przejdźmy do realizacji: jaką rolę powinien pełnić partner technologiczny – wykonawcy czy doradcy?

Aga Orłowska: Dobry partner to most między wizją biznesu a realiami technologicznymi. Powinien pełnić rolę doradcy z kompetencjami wykonawcy, pomagając nie tylko realizować założenia i zakres, ale przede wszystkim dociekać i kwestionować niektóre założenia. Pomaga uporządkować działania i transparentnie wskazuje ryzyka, zanim staną się problemem.

Michał Frydrych: Aga powiedziała to bardzo dobrze i ja bym dodał tylko jedną rzecz z perspektywy osoby, która stoi po stronie delivery: dobry partner technologiczny powinien być w stanie powiedzieć klientowi „nie” – i to jest najtrudniejsza część tej roli. Nie „nie” jako blokada, ale „nie” jako sygnał, że proponowane rozwiązanie nie dowiezie zakładanej wartości, że zakres jest zbyt szeroki na dany budżet, że harmonogram jest nierealny. Firmy, które szukają wyłącznie wykonawcy, który kiwnie głową i dowiezie to, co dostał w specyfikacji, bardzo często kończą projekt z działającym technicznie systemem, który nie rozwiązuje żadnego z pierwotnych problemów biznesowych.

Jak powinien wyglądać optymalny model współpracy między biznesem, IT i partnerem technologicznym, żeby uniknąć typowych „wąskich gardeł”?

Michał Frydrych: Z perspektywy delivery widzę jeden wzorzec, który niszczy projekty migracyjne częściej niż cokolwiek innego: brak jednego, decyzyjnego punktu po stronie klienta. Jeśli każda decyzja musi przejść przez komitet złożony z biznesu, IT, prawników i zarządu – projekt staje w miejscu, a koszty rosną. Dlatego pierwszą rzeczą, którą rekomendujemy na kickoffie, jest wyznaczenie product ownera z realnym mandatem decyzyjnym, nie figuranta, który i tak wszystko eskaluje wyżej.

Drugi element to unikanie klasycznego modelu „biznes mówi co, IT mówi jak, partner robi”. To trójkąt, który generuje szumy informacyjne i wzajemne obwinianie się przy problemach. Optymalny model, który widzę w najlepszych projektach, to jeden zintegrowany zespół z ludźmi ze wszystkich trzech stron, pracujący w tym samym rytmie, na tych samych danych, z tymi samymi priorytetami.

Trzecia rzecz, bardzo praktyczna: regularne, krótkie checkpointy decyzyjne zamiast wielkich milestone’ów co kwartał. Jeśli problem wychodzi po trzech miesiącach, jest już drogi w naprawie. Jeśli wychodzi po dwóch tygodniach, jest tylko niewygodną rozmową. Transparentność ryzyk w czasie rzeczywistym – nie w raporcie końcowym – to coś, czego pilnuję osobiście w każdym projekcie i co odróżnia partnerstwo od relacji vendor-klient.

Jakie są największe ryzyka w trakcie re-platformingu i jak można je minimalizować? Czy da się przeprowadzić re-platforming bez wpływu na sprzedaż i doświadczenie klientów?

Michał Frydrych: Zacznę od szczerej odpowiedzi na drugie pytanie: nie, nie da się przeprowadzić re-platformingu całkowicie bez wpływu na sprzedaż i doświadczenie klientów. Każdy, kto mówi inaczej, albo nie rozumie skali projektu, albo świadomie koloryzuje rzeczywistość na etapie sprzedaży. Pytanie nie brzmi „czy będzie wpływ”, tylko „jak duży i jak długo”.

Takie nieoczywiste ryzyka, które często są pomijane to np.: migracja danych. Brzmi technicznie i nudno, ale to właśnie tutaj projekty tracą miesiące. Dane produktowe, historyczne zamówienia, profile klientów, stany magazynowe – każde z nich ma swoją specyfikę i brudne przypadki brzegowe, których nikt nie dokumentował przez lata. Minimalizacja tego ryzyka to jedno: wczesny, brutalnie szczery audyt danych, zanim jeszcze zacznie się cokolwiek budować. Kolejne bardzo niedoceniane, to zmiana organizacyjna. Nowy system wymaga nowych kompetencji, nowych procesów, nowego sposobu pracy. Jeśli organizacja nie jest na to przygotowana, nowa platforma staje się droższą wersją starych problemów. Change management to nie miękki dodatek do projektu – to warunek jego sukcesu.

Najskuteczniejszą metodą minimalizowania wpływu na sprzedaż jest podejście stopniowe: zaczynamy od mniej krytycznych obszarów, uczymy się na mniejszym ruchu, budujemy zaufanie do nowego systemu zanim przeniesiemy na niego peak sprzedażowy. I absolutnie kluczowe – nigdy nie robimy go przed Black Friday, ani w żaden inny Friday.

Ile realnie trwa re-platforming i od czego zależy jego skala oraz tempo?

Michał Frydrych: Od 3 miesięcy do 3 lat – i obie liczby są prawdziwe, tylko dla zupełnie różnych organizacji i zakresów. Dla średniej firmy e-commerce z ograniczoną liczbą integracji i relatywnie czystym modelem biznesowym, realny horyzont to 3–14 miesięcy. Dla dużego gracza z rozbudowanym ekosystemem, wieloma rynkami, złożonym B2B lub własnym marketplace’em – 18–24 miesiące to minimum, które traktuję jako punkt wyjścia do rozmowy, nie jako wynik analizy.

Co realnie determinuje tempo? Przede wszystkim złożoność integracji, o której już mówiłem – to największy nieznany w każdym projekcie na starcie. Drugi czynnik to jakość danych w starym systemie: im więcej lat zaniedbań i brudnych danych, tym dłuższa migracja. Trzeci, bardzo często pomijany, to dojrzałość decyzyjna organizacji klienta – projekt z rozproszonym centrum decyzyjnym potrafi trwać dwa razy dłużej niż analogiczny projekt u klienta z silnym product ownerem.

Osobna kwestia to zakres funkcjonalny. Widzę dwa przeciwstawne błędy: pierwsze to „big bang” – próba migracji wszystkiego naraz, co generuje ogromne ryzyko. Drugie to zbyt konserwatywny MVP, który po uruchomieniu jest tak okrojony, że biznes nie widzi wartości i traci cierpliwość do projektu. Znalezienie właściwego zakresu pierwszego release’u to jeden z najtrudniejszych trade-offów w całym projekcie.

Po wdrożeniu: jak mierzyć sukces re-platformingu? Jakie KPI i sygnały biznesowe naprawdę pokazują, że decyzja była trafna?

Aga Orłowska: Prawdziwy sukces widać w codziennej pracy. Nagle znika połowa ticketów do IT, sprzedaż przestaje się blokować, a marketing zaczyna testować pomysły bez stresu, że coś się wysypie. To jest ten moment, kiedy organizacja odzyskuje oddech, nie tracąc tempa.
Dane dobrze to uzupełniają. Baymard Institute pokazuje, że skrócenie checkoutu nawet o jeden krok może obniżyć porzucenia koszyka o 10–20%. Poprawa doświadczenia bardzo szybko przekłada się na wyniki.

W praktyce warto patrzeć na kilka kluczowych wskaźników jednocześnie: konwersję, porzucenia koszyka, czas wdrażania zmian,TCO, a także recurring revenue i NPS. To one pokazują, czy platforma nie tylko działa, ale realnie wspiera wzrost.

Michał Frydrych: Aga świetnie to ujęła i ten obraz „organizacji, która odzyskuje oddech” jest naprawdę trafny – to jeden z pierwszych sygnałów, które słyszę od klientów po udanej migracji, zanim jeszcze pojawiają się jakiekolwiek dane. Ja jednak zawsze rekomendujemy, żeby baseline KPI mierzyć jeszcze przed migracją, nie po. To brzmi jak oczywistość, ale w praktyce zaskakująca liczba firm startuje projekt bez rzetelnego punktu odniesienia, a potem nie jest w stanie udowodnić zarządowi wartości z inwestycji. Jeśli nie wiesz, ile kosztuje cię dziś jeden deployment, ile trwa wdrożenie nowej promocji i jaki jest aktualny wskaźnik porzuceń koszyka – po migracji masz tylko poczucie, że jest lepiej, a nie twarde argumenty.

Drugi element, który dodałbym do listy Agi, to czas odzyskania inwestycji w kontekście TCO. Re-platforming to wydatek, który zwraca się w czasie i zarząd powinien widzieć ten punkt na osi czasu. Jeśli po 18 miesiącach od uruchomienia koszty operacyjne nie zaczęły spadać, a time-to-market nie skrócił się mierzalnie – to jest sygnał, że gdzieś po drodze zeszliśmy z właściwego kursu.
I ostatnia rzecz, o której rzadko się mówi: sukces re-platformingu widać też w tym, czy organizacja chce dalej inwestować w platformę, czy znowu zaczyna jej unikać.

Gdybyście mieli wskazać jedną najważniejszą zasadę „re-platformingu z głową”, która wynika z Waszych doświadczeń projektowych – co by to było i dlaczego?

Aga Orłowska: Zacznij od biznesowego „dlaczego”, nie technologicznego „jak”, bo technologia jest narzędziem, a nie celem. Projekty z jasnym biznes case kończą najczęściej z sukcesem.

Michał Frydrych: Moja zasada to: przez cały czas trwania projektu, na każdym spotkaniu, przy każdej decyzji o zakresie, zadawaj jedno pytanie – czy to przybliża nas do celu, czy tylko wydaje się dobrym pomysłem? To proste pytanie potrafi oszczędzić miliony i miesiące. I to właśnie ta umiejętność – mówienia „nie” wszystkiemu, co nie służy celowi – odróżnia projekty, które kończą się sukcesem, od tych, które kończą się kompromisem, z którym nikt nie jest szczęśliwy.

Materiał reklamowy partnera