Modernizacja vs budowa od zera. Którą drogę wybrać?

Dlaczego stary system IT blokuje rozwój firmy

Kiedy masz w swojej organizacji starsze systemy informatyczne, to bardzo często okazuje się, że zaczynają one być takim hamulcowym twojego rozwoju, wzrostu, Twojego biznesu, czy w ogóle w jego prowadzeniu. Zaczynasz tracić przewagę konkurencyjną, no bo twoich rozwiązań nie da się rozbudowywać, rozwijać, często są wolne, często nie da się czegoś zrobić, takie słyszysz informacje, no i powstaje wtedy pytanie, a w zasadzie decyzja, zróbmy nowy system, przejdźmy na coś nowego, świeżego, co będzie super. No i teraz właśnie pytanie, czy będzie super. Na przykładzie jednego z case study, w którym mieliśmy okazję brać udział i działać u jednego z klientów, opowiem wam w tym odcinku.

Na początek kilka informacji o kliencie i o tym, co robiliśmy. Przede wszystkim klient firma e-commerce, głównie e-commerce, która sprzedawała bardzo dużo produktów, to był antykwariat online, mamy tocase study też na stronie.

Firma, która posiadała 700 tysięcy produktów w swojej ofercie w tamtym czasie, duża ilość sprzedaży przez jeden z aktualnie wiodących marketplace’ów. Wysokomarżowy produkt, co powodowało, że bardzo dużo było zleceń o małej, niskiej wartości, z małą liczbą produktów, czasem z większą, ale generalnie co do zasady to były takie low ticket’owe zamówienia, ale na dużej marży produkt. No i oczywiście chęć dalszego rozwoju tej organizacji, która już dość sprawnie rosła, ale od pewnego momentu właśnie nie potrafiła przeskoczyć pewnego pułapu z uwagi na ograniczenia technologiczne.

Architektura systemu: OMS, PIM, WMS i wspólna baza danych

No i te ograniczenia technologiczne, gdybyśmy się zagłębili pokrótce w to, jak działała organizacja, wyglądało to od strony technologicznej, wyglądało to w ten sposób, że organizacja miała swój sklep internetowy, który był połączony z takim OMS, czyli Order Management System, tego typu klasy rozwiązaniem, które było budowanym rozwiązaniem kiedyś, dawno temu od podstaw, które służyło firmie do tego, żeby zbierać tam wszystkie zamówienia i procesować te zamówienia. Służył też ten system do pracy w Biura Obsługi Klienta, czyli znowu organizacji, czy działu w firmie, który miał za zadanie z tymi zamówieniami pracować, odpowiadać na pytania klientów o wysyłki, o dostępność, przyjmować reklamacje. Firma miała też swój PIM, czyli taki system do, powiedzmy taki PIM, który służył właśnie do tego, żeby z kolei w jednym miejscu zbierać wszystkie produkty, czyli wszystkie kartoteki produktów, no i oczywiście miała swojego WMS, czyli system do zarządzania magazynem, do całej logistyki.

To wszystko działo się jako niezależny system. Celowo te trzy systemy tutaj zaznaczyłem w formie jednej, spiąłem je jedną klamrą, jednym kwadratem, czy prostokątem w tym wypadku, z uwagi na to, że to był tak naprawdę jeden duży system, który kiedyś ktoś próbował podzielić na mikroserwisy. Problem był tylko taki, że każdy ten mikroserwis, który tutaj widzimy, to były osobne aplikacje, ale które miały wspólną bazę danych, czyli dosłownie był jeden serwer bazodanowy, który scalał te wszystkie trzy systemy.

Dlaczego firmy chcą wymienić system IT

Mówię o tym dlatego, że klient nie był tego świadomy jako osoba nietechniczna, no i podejmując decyzję podjął ją właśnie w taki sposób, że ten stary system jest wolny, nie da się go rozwijać, nikt nie chce się tego podejmować, albo jego rozbudowa może być już czasochłonna, może być ogromnie ryzykowna, no bo po co ruszać te stare systemy, przejdźmy na coś zupełnie nowego. No i to jest koncepcja, która jest bardzo lubiana przez firmy na rynku, czyli kiedy pojawia się klient, który ma jakieś swoje stare systemy, najczęściej przejdźmy na coś nowego, dlatego, że no zwyczajnie firmom jest łatwiej wdrażać systemy zupełnie od podstaw, zupełnie łatwiej jest je budować, a przynajmniej tak się wydaje. No i teraz właśnie klient wpadł na pomysł, że zróbmy może coś nowego, no bo mamy słabą wyszukiwarkę, niski współczynnik konwersji, wolne działanie, jesteśmy po sezonie, więc klient podjął sobie taką swoją wewnętrzną decyzję w oparciu o te informacje, że skoro tak, teraz system ma niski współczynnik konwersji, więc siłą rzeczy, jeżeli chcemy dalej rosnąć, powinniśmy to nad tą konwersją popracować, powinniśmy coś zrobić z wolnym działaniem, które nawet nie wiemy do końca z czego wynika, no bo tutaj padały tego typu sformułowania, czy też mamy słabą wyszukiwarkę, klienci na nią narzekają, no i do tego jesteśmy po sezonie, więc siłą rzeczy przed kolejnym sezonem możemy podjąć współpracę z nową firmą i wdrużmy coś nowego.

Nowy system e-commerce: obietnice wdrożenia w 3 miesiące

No i pojawia się firma, organizacja, która mówi tak, słuchajcie, to wszystko co wy macie, to trzeba zrobić tak, sklep na magento, w tym się specjalizujemy, to robimy, zrobimy to super i to będzie szybko, sprawnie i w ogóle nawet nie poczujecie różnicy, jeżeli chodzi o migrację, wdrożymy wam taką drugą aplikację, która będzie takim ala ERP-em, takim trochę mózgiem operacji, która będzie miała za zadanie zebrać produkty, zamówienia w jedno miejsce, będzie się komunikowała z waszym WMS-em, wdrożymy to za swego rodzaju okrągłą sumkę, ale co ważne, wdrożymy to w tylko trzy miesiące. Taka poda tutaj deklaracja, czyli klient mówi tak, ok, jeżeli do sezonu mamy około siedmiu miesięcy, tutaj w trzy miesiące nastąpi wdrożenie, będziemy mieli te nowe systemy, one, ta firma zrobiła dobre wrażenie, przyjechała w kilka osób na spotkanie, no po prostu bardzo dobrze poprowadzony proces sprzedaży, patrząc z perspektywy tego wykonawcy, natomiast nie padały tutaj żadne takie konkrety, żadne sformułowania, oprócz tego, że spisano user stories, szczególnie właśnie wokół tego sklepu internetowego i na tym się skupiono, jeżeli chodzi o realizację. No i teraz minęło pół roku, czyli już nie trzy miesiące, tylko pół roku, klient poprosił nas o audyt tych prac, z uwagi na to, że firma stwierdziła, że one są gotowe, że można wdrażać ten system produkcyjnie.

Audyt wdrożenia IT: co poszło nie tak

No i teraz tak, przeprowadzono z naszej strony audyt, który wykazał, że z tego zakresu user stories, które były spisane,tylko 23% było zrealizowane w 100%, bodajże około 14-15% było zrealizowanych tak połowicznie, czyli czegoś tam im brakowało, ale to nie było już dużo, czyli poniżej połowy zakresu mieliśmy zrealizowane w tego typu podejściu, w tego typu projekcie. Co więcej, brakowało kluczowych integracji, na przykład z hurtowniami, brakowało integracji właśnie z jednym z marketplace’ów, który miał bardzo duży udział, jeżeli chodzi o procentowo, patrząc w sprzedaży. No i to wszystko doprowadziło do tego, że teraz firm miał do podjęcia decyzję, albo wracamy do tych naszych starych systemów, w rozumieniu wracamy, że zaczynamy je dalej rozwijać, no bo oczywiście, kiedy podjęto decyzję o tym, żeby podjąć współpracę z nową firmą, to ten rozwój siłą rzeczy hamowano, wstrzymywano, no bo to miało zająć tylko 3 miesiące.

Czyli tak, albo wracamy do tych starszych systemów, albo próbujemy uratować to wdrożenie. Z naszej perspektywy padła tutaj rekomendacja, żeby absolutnie nie kontynuować tego wdrożenia, no bo jeżeli ono nie miało kluczowych, podstawowych rzeczy, typu projekt architektury, typu mapa procesów w organizacji klienta, typu mapa integracji, złapane wymiany danych, typu, no właśnie rozwiązania technologiczne, które faktycznie da się dopasować do potrzeb klienta, bo tutaj akurat było to wszystko trochę nad wyrost, no to my zarekomendowaliśmy, żeby absolutnie tego wdrożenia nie kontynuować i jednak wrócić do tego systemu, który klient miał, czyli do tych problemów. Co jest jeszcze, czyli do tych problemów i do tego problematycznego systemu w tej problematycznej architekturze.

Co jest super istotne, co warto, żebym jeszcze dopowiedział, to to, że w momencie, kiedy klient podejmował decyzję o tym, żeby przechodzić na nowy system, to te rzeczy opowiedział sobie wewnętrznie, natomiast temu nowemu wykonawcy w żaden sposób o tym nie powiedział, co powodowało, że tam ani nie było zaplanowanej lepszej wyszukiwarki, ani niekoniecznie było zaplanowane, jak sprawdzimy, czy współczynnik konwersji jest wyższy, czy niższy. Stąd decyzja z naszej perspektywy, czy rekomendacja decyzji o tym, żeby tamto wdrożenie zatrzymać. I teraz jesteśmy w momencie, kiedy klient jest już przed sezonem, tam już brakowało do niego bardzo niewiele czasu.

Jednocześnie ma ten swój starszy system oparty o jedną bazę danych, ma te problemy, które chciałby rozwiązać, no i musi jakoś funkcjonować dalej, zastanowić się, jak to, tę swoją technologię poukładać, żeby firma mogła dalej funkcjonować.

Wdrożenie systemu IT pod cele biznesowe: konwersja, wyszukiwarka, wydajność

No i teraz to, co my zaproponowaliśmy, to na początek zastanówmy się nad waszymi celami biznesowymi. Tutaj cel był jasny, chcemy zwiększać sprzedaż.

To nie jest etap na to, żeby optymalizować procesy, to nie jest etap na to, żeby automatyzować jakieś działania, to jest etap na to, że chcemy teraz poprawiać doświadczenia klienta i dzięki temu zwiększać sprzedaż. Podzieliliśmy sobie to na trzy takie najważniejsze właśnie kroki, które wydobyliśmy od klienta, które klient miał już de facto opowiedziane wcześniej, tylko nie przekazane do poprzedniego wykonawcy. Mianowicie chcemy poprawić współczynnik konwersji, chcemy wdrożyć lepszą wyszukiwarkę i chcemy sprawić, aby system działał szybciej.

Modernizacja systemu: UX, wyszukiwarka i wydajność

No i teraz w nawiązaniu do tych potrzeb

1. jeżeli chodzi o współczynnik konwersji, zorganizowaliśmy warsztat UX-owy, w ramach którego przygotowaliśmy wraz z klientem i nawiasem mówiąc też z grafikiem po stronie klienta, wspólnie we współpracy, nowe makiety, nowy projekt graficzny oraz ustaliliśmyw jaki sposób będziemy mierzyć konwersjepo wdrożeniu, no i jakie przyjmujemy scenariusze, w jaki sposób będziemy działać.

2. Po drugie, jeżeli chodzi o nową lepszą wyszukiwarkę, przyjęliśmy sobie tutaj założenie, że wdrażamy nowy mikroservice, czyli taką jakby nową mikro aplikację, która będzie odpowiedzialna tylko za wyszukiwanie i do tego wszystkiego dołożyliśmy jeszcze jasne kryteria odbioru, czyli innymi słowy w ramach warsztatu UX-owego zastanowiliśmy się jak klienci szukają tego produktu, w jaki sposób, jakie frazy wpisują, jakie kombinacje tych fraz i dzięki temu ta wyszukiwarka mogła działać zwyczajnie lepiej.

3. Jeżeli chodzi o szybsze działanie, no to przede wszystkim zmapowanie tej architektury, to co pokazałem wcześniej, czyli jak jest, architektury jak powinno być, no i według tego też dostosowanie i architektury oprogramowania i infrastruktury u klienta, czyli rozwiązań serwerowych, które miało to na celu to, żeby po prostu system działał stabilniej, szybciej i był skalowalny dzięki tym wprowadzonym zmianom.

I teraz, co tutaj się wydarzyło? To, co my zrobiliśmy, to przede wszystkim podzieliliśmy ten system na dwie części, na dwie części, ten, który klient już wcześniej miał, czyli system związany z zamówieniami i z produktami, zestawiliśmy w ramach tej wspólnej bazy danych, bo tutaj co do zasady nie było problemów z tym, żeby z niego korzystać, natomiast, bo to systemy jednak back-office’owe, gdzie grupa użytkowników była kilkudziesięciu osób i tutaj z powolnym działaniem nie obserwowano, natomiast to, co zrobiliśmy, to tutaj wprowadziliśmy znaczące zmiany, to znaczy wprowadziliśmy tak zwany load balancer, czyli rozwiązanie, które ma na celu przekierowywanie ruchu między różnymi serwerami. Na dwóch osobnych serwerach zainstalowaliśmy sklep internetowy, który miał po pierwsze poprawiony user experience i tym samym customer experience, no bo co do zasady działał zwyczajnie szybciej, działał lepiej, jednocześnie wdrożyliśmy rozwiązanie, które pozwala nam w dowolnym momencie dołożyć kolejną instancję tego typu, czyli możemy dosłownie zrobić copy-and-paste w cudzysłowie sklepu internetowego, podłączyć sobie integrację i kierować użytkownika na jeden z trzech już wtedy serwerów, a nie koniecznie na jeden z dwóch. Tego typu rozwiązanie powoduje, że ten front tam, gdzie ten największy ruch jest przyjmowany, siłą rzeczy jest skalowalny i to rozwiązało w ogóle pierwszy problem klienta, czyli to szybkie działanie.

Drugi temat, czyli konwersja, właśnie została poprawiona poprzez ten lepszy UX wdrożony w sklepie, nowe makiety, które nie były rewolucyjne absolutnie, były bardziej ewolucyjne, czyli właśnie złapaliśmy sobie na przykładzie, na przykład Clarity, na przykładzie map ciepła, gdzie ten klient potencjalny nam tutaj ucieka z tego sklepu internetowego, dlaczego nie dokonuje zakupu, no i na bazie tych usprawnień stosunkowo niedużych udało nam się tą konwersję też poprawić. No i oczywiście trzecia rzecz, czyli wyszukiwarka, wdrożyliśmy ją jako osobny mikroserwis, dlatego aby nie obciążać już architektury dostępnej u klienta, czyli tego sklepu internetowego w starszej technologii, raczej go na tym etapie zostawić i docelowo go przemodelować na technologię nowszą. Natomiast tutaj już pracując na nowym stacu, gdzie stacu, czyli takim powiedzmy zbiorze rozwiązań technologicznych, który ma na celu to, żeby rzeczywiście łatwiej było nam to rozwijać w przyszłości.

Co to daje? Daje nam to, że w momencie, kiedy te systemy działają niezależnie od tych, jesteśmy w stanie przyjmować większy ruch, więcej klientów, obsługiwać więcej zamówień, obsługiwać bez problemów na back office i jednocześnie bez problemów tutaj na froncie, czyli z poziomu sklepu internetowego. Teraz na jakie wyniki to się przełożyło? Bo myślę, że to jest kluczowe. Przede wszystkim uratowaliśmy sezon sprzedażowy, udało nam się to wdrożyć przed sezonem sprzedażowym, mieć jeszcze około dwóch, trzech tygodni na testy.

Efekty wdrożenia: wzrost sprzedaży o 180%

To nie było dużo czasu, ale wystarczająco, żeby faktycznie projekt zakończyć sukcesem. Rok do roku sprzedaż u klienta wzrosła aż o 180% i oczywiście jest tutaj szereg rzeczy, które też wpłynęły na tę metrykę, natomiast jedną z nich jest właśnie to, że system stał się skalowalny i mógł obsłużyć więcej ruchu, bo to siłą rzeczy przez zwiększoną liczbę klientów w tym sklepie zwiększyła się także sprzedaż. System został przygotowany do architektura w taki sposób, aby był możliwy do dalszego rozwoju, a co ciekawe to wdrożenie zamknęło się mniej więcej w cenie 1 trzeciej wdrożenia tego rozwiązania wcześniejszego od podstaw, osiągając cele biznesowe, które klient na początku sobie wyznaczył.

Teraz podsumowując ten odcinek, tak żeby zbliżyć się do końca. Nie zawsze potrzebna jest rewolucja, często jest potrzebna, ale nie zawsze i tutaj się pojawia to słynne to zależy w IT i na tym warto też wziąć to pod uwagę, że jak ktoś mówi, że to zależy, to warto te różne zależności poznać. Warto poznać też swojego w cudzysłowie wroga, to znaczy jeżeli ten już starszy system absolutnie traktujemy jako zło konieczne i trzeba się go w cudzysłowie pozbyć, warto się zastanowić, czy to jest na pewno najlepszy czas, żeby się go pozbyć od razu poprzez jedno cięcie, czy może lepiej wyciągając pojedyncze odpowiedzialności i starając się krok po kroku odbierając odpowiedzialności staremu systemowi, przejść na nowy system, który te odpowiedzialności przejmuje już z wykorzystaniem nowszej technologii.

Tym samym warto rozważyć różne koncepcje rozwiązania problemu i tym samym też warto spojrzeć na to od strony takiej architektonicznej. Ja zachęcam zawsze wtedy, żeby ktoś z zewnątrz spojrzał na to od strony, czy to architekta, czy CTO z uwagi na to, że często jest tak, że ktoś patrząc na świeżo na te cele biznesowe i na świeżo na ten system, na który już być może nawet programiści w firmie narzekają, że tam się nic nie da zrobić, albo jak coś się zrobi, to trzy inne rzeczy się psują. Wtedy warto zasięgnąć porady kogoś, kto spojrzy na to na świeżo i jednocześnie będzie w stanie doradzić jak to wszystko poukładać.