Starsze oprogramowanie w firmach - dlaczego modernizacja systemów IT staje się koniecznością

Są takie decyzje w firmie, które dojrzewają latami, np. chęć wymiany systemu informatycznego na inny. Ten moment, kiedy każdy już wie, że nas to czeka, bo obecne rozwiązanie zaczyna stanowczo blokować rozwój. Pojawia się pomysł na nowy produkt, albo nowy model współpracy z nowym, super ważnym klientem, ale ten powód będzie wymagał od nas wprowadzenia modyfikacji do obecnie używanego systemu. I od razu słyszycie od firmy informatycznej, system tego nie obsługuje, albo moje ulubione, nie da się, nie da się tego zrobić. No czyli po prostu nie da się, zamykaj firmę, nie będziesz się rozwijał, nie ma takiej opcji.

I wtedy zaczynasz robić obejścia. Pojawiają się wokół Excel, pojawiają się w większej ilości maili, ale pojawia się też myśl, a w zasadzie dwie myśli. Po pierwsze, może wymieńmy w końcu ten system, albo po drugie, może wymieńmy firmę, która nas obsługuje.

Co ciekawe, zauważam u swoich klientów, że starsze systemy, klienci chcą od razu wymieniać na nowe. No bo jak usłyszeli tysiąc razy, że się nie da, no to jakie jest rozwiązanie? Trzeba przejść na coś, na czym będzie się dało.

Przechodząc do konkretów, na początek odcinka pozwoliłem sobie sprawdzić, co mówią badania i ile może być jeszcze takiego starszego oprogramowania w firmach na rynku. Według raportu McKinsey ponad 70% oprogramowania używanego przez firmy z listy Fortune 500 ma fundamenty starsze niż 20 lat. 20 lat.

Wiecie, pomijając ostatnie czasy, kiedy wiadomo, mamy wokół wszechobecny AI, pomysły na rozwój z nim związane, czy też pomysły na automatyzację, to zwyczajnie wystarczy zobaczyć, jak przez te 20 lat zmienił się biznes. Nic dziwnego, że takie systemy sprzed 20 lat, nawet jeśli są jeszcze jakkolwiek wspierane, coraz częściej nie nadążają za tym, jak dziś działa właśnie biznes. No ale dobrze, jak już wiemy, że ten nasz system to prędzej czy później padnie, albo będzie wymagał wymiany, to myślimy sobie też, powiedzmy w tle, przy okazji spraw bieżących, co by tu z nim zrobić.

Low-code w firmie – kiedy platformy low-code są dobrą alternatywą dla systemu IT

Zacznijmy od rozwiązania, o którym w pewnym czasie naprawdę dużo się mówiło, czyli od opcji low-code. To opcja, która na pierwszy rzut oka brzmi bardzo kusząco.

Nie musisz programować, wystarczy poukładać elementy, klocki i system gotowy. Weźmy przykład Webcon, bo to jest jeden z mocniejszych graczy w Polsce. Otrzymujesz dostęp do platformy, na której możesz budować system na bazie procesów biznesowych w dość intuicyjny sposób.

Masz taki swego rodzaju wizualny designer, w którym układasz workflow trochę jak takie klocki, bez pisania kodu, bez budowania wszystkiego od zera.

Dla kogo system low-code – procesy powtarzalne i uporządkowane

Dla kogo to rozwiązanie będzie dobre? Najczęściej dla firm, które mają sporo procesów, ale są to procesy dość uporządkowane, powtarzalne i raczej standardowe. Różnego rodzaju wnioski, akceptacje, obiegi dokumentów.

Coś, co nie wymaga bardzo złożonej logiki biznesowej, ani nie wymaga dużej ilości przetwarzania danych, czy wielu złożonych integracji zewnętrznych. Low-code dobrze sprawdza się też wtedy, gdy zależy ci na większej samodzielności po stronie biznesu. Oczywiście, to nie oznacza pełnej niezależności od IT, ale często wystarczy dobry analityk biznesowy, który dobrze rozumie procesy, ma znajomość Webcon i potrafi tę znajomość i zarówno procesów, jak i Webcon przełożyć na konfigurację systemu.

I to będzie na pewno przewaga, bo nie musisz stać w kolejce do deweloperów za każdym razem, kiedy chcesz coś zmienić. Low-code rzadko zastępuje całe rozbudowane systemy typu ERP, czy systemy produkcyjne. Częściej staje się taką warstwą, która porządkuje, automatyzuje procesy wokół nich, czy też głównie realizuje obieg dokumentów, czy właśnie obsług jakiś wniosków. To są takie najczęstsze przypadki tutaj użycia.

Ograniczenia i vendor lock-in w systemach low-code

Jeśli jednak mówimy o systemie, który ma stać się operacyjnym centrum firmy i obsługiwać złożoną logikę biznesową, warto sprawdzić granice jego elastyczności. Low-code najlepiej działa przy procesach o wyraźnym początku i końcu.

Im więcej niestandardowych zależności i dynamicznych reguł, tym bliżej jego naturalnych ograniczeń. Najczęściej pojawiającą się wątpliwością jest kwestia zależności od dostawcy, czyli tzw. vendor loc.

W praktyce oznacza to, że procesy, które zbudujesz w platformie takiej jak Webcon, są w 100% tak naprawdę osadzone w jej ekosystemie. To naturalne dla tego typu platform. Problem pojawia się dopiero wtedy, gdy skala projektu rośnie, albo pojawia się więcej użytkowników, albo kierunek rozwoju dostawcy przestaje być spójny z Twoimi potrzebami.

Koszty systemów low-code – licencje, skalowanie i długofalowa opłacalność

Jest jeszcze kwestia kosztów, o której dobrze pomyśleć trochę szerzej niż tylko na etapie startu. Na początku model low-code bywa bardzo atrakcyjny. Pojawia się opłata licencyjna liczona z reguły od ilości użytkowników, ewentualne szkolenia, jakieś dodatkowe moduły, konfiguracja i wydaje się, że minimalne wdrożenie, no bo przecież wszystko poukładamy z tych klocków i projekt rusza.

Oczywiście im więcej użytkowników, tym większe te koszty stałe, te koszty licencji płatne per użytkownik. W porównaniu do klasycznego developmentu próg wejścia często jest znacznie niższy, ale wraz ze wzrostem ilości potrzeb i zbiegiem czasu, jeśli nie zostaną one dobrze zmapowane, zarówno te potrzeby, jak i procesy na starcie prac, może się okazać, że takie rozwiązanie nie będzie wystarczające w długiej perspektywie. I w pewnym momencie naturalnie pojawia się pytanie, czy ten model finansowy nadal jest dla nas optymalny, czy przy tej skali to wciąż najlepsza proporcja między elastycznością, kontrolą i kosztem.

I na te pytania wybierając jakąkolwiek gotową platformę, warto sobie odpowiedzieć, zanim się ją de facto wybierze i wdroży. Podsumowując tę część, low-code świetnie nadaje się w środowisku, gdzie jest mało użytkowników i relatywnie proste procesy i nieduże ilości danych. Jest to rozwiązanie typu biała kartka, gdzie dużo rzeczy możemy dostosować pod siebie, ale raczej są to systemy typu proste workflow czy obieg dokumentów, czyli na białej kartce w określonej kolejności przybijamy sobie pieczątki, jakimi są określone funkcjonalności i według tego następuje później działanie tego systemu, czyli zamiana tych pieczątek, funkcjonalności czy na rzeczywiste funkcjonalności właśnie.

Systemy pudełkowe - gotowe rozwiązania przy wymianie systemu IT w firmie

Druga opcja, którą firmy bardzo często rozważają przy wymianie systemu, to gotowe rozwiązania pudełkowe, czyli system, który już istnieje, ma jakąś określoną funkcjonalność, ma jakąś roadmap rozwoju i tysiące wdrożeń za sobą. Przy rozwiązaniu low-code otrzymujesz pustą kartkę, którą musisz zapełnić klockami, rysunkami czy tymi pieczątkami i de facto zrobić pod siebie. Przy rozwiązaniach pudełkowych masz już gotowe moduły, elementy, które można skonfigurować i od ręki uruchamiać, czyli wchodzisz w zaplanowany przez kogoś w pewien gotowy sposób działania.

Ta duża ilość funkcjonalności to tak naprawdę ogromna zaleta. Przy mądrym wdrożeniowcu, który umie poustawiać system pod ciebie, unikasz konieczności budowania mechanizmów zupełnie od podstaw. Jednak to, że system ma gotowe funkcjonalności powoduje też, że ktoś, kto go budował, robił to z myślą o jakimś rodzaju firm i ustawiał, czy w ogóle budował ten system, ustawiał jego fundamenty w pewne ramy.

Wybór systemu IT – kiedy gotowy system ma sens w procesach firmy

Im bardziej twoja organizacja odbiega od tego schematu, tym częściej pojawia się pokusa, żeby system dopasować pod siebie. Często towarzyszy temu uspokajająca narracja dostawcy, spokojnie, wszystko da się dostosować. I w pewnym zakresie to prawda.

Konfiguracja, dodatkowe moduły czy rozszerzenia są naturalną częścią tego typu wdrożeń. Warto jednak pamiętać, że te systemy mają już rozbudowaną, spójną logikę działania, dostosowaną do założonej przez dostawcę oprogramowania pewnej rynkowej logiki biznesowej, takiej powiedzmy uśrednionej. Im głębiej ingerujemy w ich rdzeń, tym bardziej rośnie złożoność projektu, zarówno na etapie wdrożenia, jak i późniejszego utrzymania.

Dlatego przy wyborze systemu pudełkowego, ważniejsze od pytania, czy można go zmodyfikować, jest pytanie, gdzie postawić granicę między dopasowaniem systemu do siebie, kontra dopasowania siebie, działania swojej firmy, do tego jak działa dany system. To odwieczny dylemat, który mocno definiuje, czy wybrać gotowe rozwiązania na rynku, czy budować coś swojego.

Customizacja systemu pudełkowego - gdzie postawić granicę dopasowania?

Moja opinia tutaj jest taka, że jeżeli mamy zebrane swoje założenia i mamy zebrane wymogi biznesowe co do systemu, a także zmapowany nasz proces, przynajmniej wysoko poziomowo od A do Z jak działamy i gotowy system pasuje do wszystkich głównych miejsc tego procesu, a te, które trzeba byłoby customizować, dostosować pod siebie, da się na bazie wymagań procesu i funkcjonalności rozwiązania przewidzieć i oszacować ich złożoność i koszt przed etapem wdrożenia i jest to zaledwie kilka procent wszystkich funkcjonalności, które ten dany system będzie posiadał, to wtedy z reguły warto go wdrożyć.

Natomiast jeżeli na każdą naszą prośbę i oczekiwanie pada hasło, bo tak da się to zrobić, a kiedy pytamy czy taka funkcjonalność jest już dostępna i chcemy aby na przykład ktoś nam ją pokazał, to kiedy w odpowiedzi słyszymy, że to będzie jednak customizacja, to trzeba dopisać, czyli da się, ale będziemy musieli to dopisać, to bałbym się podjąć taką współpracę z uwagi na to, że gotowe systemy, szczególnie te napisane powiedzmy 15-20 lat temu, bardzo źle radzą sobie z długoterminowym utrzymywaniem i podstawy systemu, która została te x lat temu napisana i tych customizacji obok niej, które są dodawane. Ale to jest temat z pewnością na inny odcinek, który niebawem pewnie nagram.

Koszty systemów pudełkowych – licencje, wdrożenie, moduły i TCO

Warto też spojrzeć na temat kosztów, podobnie jak w systemach low-code. Na początku systemy pudełkowe często wydają się bardzo atrakcyjne finansowo. Koszt prezentowany jest zazwyczaj w formie licencji, rocznej, miesięcznej, co daje poczucie przewidywalności i kontroli budżetu. Jednak pamiętać trzeba o tym, że licencja to tylko część całkowitego kosztu projektu.

Do tego dochodzą koszty wdrożenia, konfiguracji, tych customizacji i dlatego to tak ważne, aby w kontekście optymalizacji kosztowej system zapewniał te ponad 90-90 parę procent funkcjonalności pasujących do twojej firmy w standardzie. W miarę rozwoju firmy pojawiają się kolejne elementy. Dodatkowe licencje dla nowych użytkowników, czyli każda nowa osoba w systemie to z reguły jakaś osobna opłata, czy to utrzymaniowa, czy wdrożeniowa.

Nowe działy oznaczają rozszerzenie zakresu licencji o kolejne moduły. Koszty utrzymania bazy danych i czasami także licencji dla niej, która potrafi być kosztowna. Dodatkowe moduły i integracje często wiążą się z dodatkowymi kosztami, opłatami, czy też bardziej zaawansowane funkcjonalności mogą wymagać wyższych pakietów, czy jakichś dodatkowych opcji premium.

Vendor lock-in w systemach pudełkowych – zależność od dostawcy i architektura zależności

I tu pojawia się jeszcze jeden aspekt. Podobnie jak w przypadku danej platformy low-code'owej, zależność od ekosystemu dostawcy, czyli vendor lock. To jest w pełni w porządku, żeby tego vendor lock mieć, ale warto ograniczać ryzyka z tego wynikające.

Jak radzić sobie z vendor lock mówiłem już w innym razem. Mając już wdrożony nowy system, z czasem gdy firma rośnie i pojawiają się nowe potrzeby, naturalnym kierunkiem jest sięganie po kolejne rozwiązania tej samej rodziny produktowej od tego samego dostawcy. Często dlatego, że integracja będzie łatwiejsza, spójniejsza i mniej ryzykowna, no bo w końcu będzie realizował ją ten sam dostawca, który wdrażał nasz system od podstaw.

W praktyce oznacza to, że z czasem organizacja coraz mocniej opiera się na jednym dostawcy i na jednym oprogramowaniu, czy rodzinie, grupie oprogramowań. Zmiana kierunku staje się trudniejsza, a alternatywne rozwiązania z zewnątrz wymagają większego nakładu pracy, na przykład integracyjnej. Dlatego przy systemach pudełkowych warto patrzeć nie tylko na pojedynczą decyzję zakupową, ale na długofalową architekturę zależności, którą ta decyzja tworzy i na tak zwany całkowity koszt posiadania oprogramowania w perspektywie na przykład 5 lat.

Podsumowując tę część, rozwiązania gotowe, pudełkowe polecam dla osób, które albo są w stanie się dostosować z działaniem firmy niejako do tego, jak działa dane oprogramowanie, albo znalazły system, który pasuje do procesów działających w firmie w obszarze, gdzie ten system będzie wdrażany.

System dedykowany - budowa systemu IT od podstaw jako strategia rozwoju firmy

Trzecią ścieżką przy wymianie systemu jest rozwiązanie dedykowane, czyli budowa systemu zupełnie od podstaw. I tutaj ważną kwestią jest to, że możemy zaprojektować ten system zupełnie pod działanie swojej organizacji.

Czyli w przeciwieństwie do rozwiązań pudełkowych, nie zaczynasz od gotowego schematu procesów. Punktem wyjścia są Twoje realne potrzeby, to jak działają procesy w Twojej organizacji, to nie musi oznaczać budowy ogromnego kombajnu od pierwszego dnia. Projekt można realizować etapami, zaczynając od kluczowego obszaru, który dziś najbardziej ogranicza rozwój i stopniowo rozbudowywać system w kolejnych fazach.

Różnica polega na tym, że architektura powstaje wokół Twojej logiki biznesowej, a nie w ramach wcześniej zdefiniowanego modelu rynkowego.

Kiedy system dedykowany ma sens - przewaga konkurencyjna i elastyczność skalowania

Dedykowany system ma największy sens wtedy, gdy obecny system działający już w organizacji nie tylko nie domaga, ale realnie ogranicza model działania firmy. Na przykład, gdy procesy są tak specyficzne, że każda próba dopasowania gotowego rozwiązania kończy się nieakceptowalnym kompromisem.

Gdy system ma być elementem przewagi konkurencyjnej. Gdy firma dynamicznie się rozwija i potrzebuje elastyczności w skalowaniu swoich działań. Gdy integracje między systemami stają się kluczowe dla sprawnego działania. W takim scenariuszu budowa własnego rozwiązania staje się de facto decyzją strategiczną. Ale dedykowane rozwiązanie oznacza też większą odpowiedzialność. Nie masz producenta, który rozwija system za Ciebie.

To de facto Ty decydujesz o kierunku rozwoju, o tempie zmian, o priorytetach. To oznacza większe zaangażowanie po stronie biznesu i tego trzeba być świadomym. Na pewno większą potrzebę świadomego podejmowania decyzji technologicznych.

Odpowiedzialność za utrzymanie i dalszy rozwój systemu. Niezależnie od tego czy kompetencje budujesz wewnątrz organizacji czy współpracujesz z zewnętrznym software housem.

Koszty systemu dedykowanego - analiza, architektura, development

W przypadku systemów dedykowanych struktura kosztów wygląda nieco inaczej niż przy rozwiązaniach pudełkowych.

Inwestycja początkowa w system dedykowany jest zazwyczaj wyższa. Ponieważ obejmuje bardzo dokładną analizę, mapowanie procesów, projektowanie architektury i też development. Choć to już też się trochę zmienia.

Z drugiej strony nie funkcjonujesz w modelu licencyjnym. Nie płacisz za każdego użytkownika ani za kolejne moduły według zewnętrznego cennika. Struktura kosztów wygląda tak, że większy nacisk kładziony jest na budowę i rozwój rozwiązania niż na opłaty za korzystanie z gotowego produktu.

System dedykowany wymaga też stałego utrzymania, aktualizacji technologicznych oraz dalszego rozwoju wraz ze zmianami w biznesie. Aczkolwiek sprawny wykonawca takiego systemu powinien się mocno wspierać w tym procesie przede wszystkim. I tu warto dodać jedną ważną rzecz.

Jeżeli kilka lat temu projekty dedykowane były postrzegane jako bardzo kosztowne i bardzo długotrwałe, to development oznaczał z reguły duże zespoły, długi czas wytwarzania, wysoki próg wejścia finansowego. Dziś ta ekonomika wytwarzania oprogramowania wyraźnie się zmieniła. Narzędzia wspierane przez AI, automatyzacja testów, generowania dokumentacji czy zwyczajnie przyspieszone tworzenie kodu sprawiają, że czas developmentu może być krótszy, a koszty znacznie bardziej przewidywalne.

To nie oznacza, że system dedykowany stał się super tani, ale oznacza, że jeśli kilka lat temu wycena takiego projektu Cię zniechęciła, warto spojrzeć na to ponownie w dzisiejszych realiach technologicznych. Podsumowując część dotyczącą rozwiązań dedykowanych, można by powiedzieć, że one są idealne dla firm, które chcą zbudować coś swojego. Coś, co będzie miało sens dla firmy, która ma duże, skomplikowane procesy dziejące się symultanicznie, niektóre obok siebie, a jednocześnie na siebie wpływające i które można w pełni odtworzyć w systemie.

Rozwiązania hybrydowe – połączenie systemu open source i modułów dedykowanych

Ale jest jeszcze czwarta koncepcja. Coś, co warto rozważyć. Rozwiązanie, które łączy przewidywalność gotowych systemów z elastycznością rozwiązań dedykowanych.

Czyli tzw. rozwiązania hybrydowe. To podejście, w którym nie budujesz wszystkiego od zera, ale też nie zamykasz się w sztywnym gotowcu.

Tworzysz sobie projekt architektury, która łączy oba światy. Tak de facto. W praktyce wygląda to tak.

Wybierasz gotowe rozwiązanie open source'owe, czyli z otwartym kodem źródłowym jako fundament. Najlepiej takie, które daje dostęp do kodu źródłowego, do API, umożliwia integrację, no i zwyczajnie dzięki temu nie blokuje rozwoju. Dlaczego to ma sens? Bo jeśli spojrzysz na różne branże i różne modele biznesowe, to na poziomie fundamentu są one do siebie bardzo często podobne.

Zarządzanie klientami, obsługa zamówień, produkty, faktury, magazyn. To wszystko wygląda w gruncie rzeczy podobnie. Więc bierzesz sobie ten fundament, bo on już istnieje, już działa i obsługuje te standardowe obszary, ale zamiast budować od nowa, koncentrujesz się na tym, co naprawdę jest twoje.

Czyli budujesz dedykowane moduły tam, gdzie proces jest niestandardowy. Tworzysz integrację między systemami. Automatyzujesz elementy specyficzne tylko dla twojego modelu działania.

Dlaczego hybryda ma sens – standardowy fundament i własne procesy biznesowe

Dlaczego to działa? Bo nie marnujesz czasu i budżetu na odtwarzanie standardu. Inwestujesz tam, gdzie powstaje realna wartość, w procesy, które odróżniają cię od konkurencji i decydują o tym, jak będzie działał twój biznes ze wsparciem tego nowego systemu. I dzięki temu nie musisz budować całego zaplecza technologicznego od zera.

Ciężar inwestycji przenosisz tam, gdzie ma on największy sens. I finalnie masz system, który opiera się na stabilnym fundamencie, nie ogranicza cię w rozwoju i jest realnie dopasowany do twoich potrzeb i do tego, jak działa twoja organizacja. Takie hybrydowe podejście ma największy sens wtedy, gdy wymieniając system nie chcesz wszystkiego zaczynać od zera, ale też nie chcesz ponownie zamknąć się w jednym, sztywnym rozwiązaniu, na którego mechanikę, fundamenty nie masz kompletnie wpływu.

To dobry kierunek, gdy wiesz, że część obszarów w twojej firmie może działać w oparciu o standardowy system, ale inne wymagają większej elastyczności. Gdy zależy ci na nowym, stabilnym fundamencie operacyjnym, ale jednocześnie chcesz zostawić przestrzeń na rozwój specyficznych procesów. W takim podejściu wymiana systemu nie oznacza rewolucji wszystkiego naraz.

Ryzyka podejścia hybrydowego - brak wizji i decyzje punktowe

Warunkiem powodzenia takiego podejścia jest dobrze zaprojektowana architektura już na starcie i przemyślane integracje. Bez tego hybryda może zamienić się w zbiór połączonych systemów zamiast spójnego środowiska. W kontekście kosztów oznacza to, że część budżetu musi być przeznaczona nie tylko na nowe rozwiązania, ale również na zaprojektowanie sposobów, jakie będą ze sobą współpracować.

Integracje, wymiana danych, spójność raportowania to elementy, które w podejściu hybrydowym mają duże znaczenie. Z jednej strony nie ponosisz pełnego kosztu budowy wszystkiego od zera, z drugiej inwestujesz w architekturę i warstwę integracyjną, która pozwala całemu środowisku działać jak jeden system. Ryzyko pojawia się wtedy, gdy decyzje podejmowane są punktowo, system po systemie, ale bez całościowej wizji na starcie.

Podejście hybrydowe to świadoma decyzja o tym, że różne obszary firmy mogą potrzebować różnych rozwiązań, pod warunkiem, że są one częścią jednej spójnej koncepcji.

Wybór nowego systemu IT - jak dopasować rozwiązanie do kontekstu firmy

Jak widzisz, wybór nowego systemu to nie jest raczej szybka decyzja. Nie ma jednego złotego środka i żadna z tych opcji nie jest lepsza sama w sobie, nie ma jednej idealnej na rynku.

Każda z nich ma sens, ale tylko w określonym kontekście, tego jak na dziś pracujecie i jak chcecie pracować przez najbliższe lata. Warto najpierw odpowiedzieć sobie na dwa pytania. Po pierwsze, gdzie dziś jest mój biznes i jak sobie go wyobrażam za kilka lat, a następnie do tego zmapować swoje procesy, przygotować projekt architektury i na jego podstawie dokonać wyborów, w których miejscach można skorzystać z gotowych rozwiązań, a które nadają się na dedyka czy tak zwaną hybrydę.

Bo system, który wybierzesz, będzie wspierał nie tylko to, co robisz teraz, ale też to, a może przede wszystkim to, jak będziesz działać w przyszłości. Jeśli zmagasz się obecnie z poszukiwaniem pomysłu na podejście do systemu IT, który aktualnie u Ciebie nie domaga, umów wizję lokalną. To bezpłatna i niezobowiązująca konsultacja realizowana w siedzibie Twojej firmy, podczas której przeanalizujemy Twoją sytuację, możliwe scenariusze i jaka to by była realnie skala projektu.