10 oznak, że architektura IT hamuje rozwój firmy

Kiedy firma przestaje rosnąć w tempie, którego oczekuje zarząd, pierwsze pytania zwykle kierowane są do sprzedaży. Potem do marketingu. Czasem do operacji. Rzadko ktoś od razu pyta o architekturę IT — bo systemy przecież działają, faktury się wystawiają, zamówienia spływają, raporty są.

A jednak w wielu organizacjach właśnie tam znajduje się cichy hamulec. Nie w formie awarii, tylko w formie kosztu każdej zmiany. Z doświadczeń naszych ekspertów wynika, że problem architektury IT ujawnia się nie wtedy, gdy coś się psuje, ale wtedy, gdy firma chce zrobić coś nowego: wejść na nowy rynek, uruchomić inny model sprzedaży, przejąć spółkę, obsłużyć dwa razy większy wolumen.

Poniżej dziesięć oznak, które w praktyce najczęściej sygnalizują, że architektura IT hamuje rozwój firmy.

1. Każdy nowy projekt zaczyna się od pytania „czy to w ogóle da się zintegrować?”

Jeśli dyskusja o nowym produkcie, kanale sprzedaży czy modelu rozliczeń natychmiast schodzi na temat ograniczeń systemów, to nie jest kwestia ostrożności IT. To informacja, że architektura narzuca ramy strategii, a nie odwrotnie. W zdrowej organizacji technologia jest przedmiotem decyzji biznesowej. W zablokowanej — jest jej warunkiem wstępnym.

2. Ta sama informacja żyje w kilku miejscach i nigdzie nie jest prawdziwa

Klient w CRM, klient w ERP, klient w arkuszu u kierownika regionu. Trzy wersje, trzy stany, trzy różne odpowiedzi na to samo pytanie. Konsekwencja jest znacznie poważniejsza niż bałagan w danych: zarząd podejmuje decyzje na podstawie liczb, w które sam nie do końca wierzy. To bezpośrednio wydłuża czas reakcji i podnosi ryzyko błędnych decyzji o cenach, zapasach czy inwestycjach.

3. Raport zarządczy powstaje ręcznie i zajmuje kilka dni

Jeżeli zamknięcie miesiąca albo przygotowanie danych o marżowości wymaga kilkudniowej pracy zespołu, to nie jest problem pracowitości. To koszt architektury, którą płaci się co miesiąc, w godzinach ludzi, którzy powinni analizować, a nie sklejać dane.

4. Wzrost wolumenu oznacza wzrost zatrudnienia niemal proporcjonalnie

To jeden z najbardziej wymownych testów. Firma z dobrze zaprojektowaną architekturą przy podwojeniu liczby transakcji nie podwaja backoffice'u. Jeśli w Twojej organizacji każde 20% więcej sprzedaży wymaga 20% więcej rąk do obsługi, skalowalność jest pozorna, a rentowność wzrostu — dużo niższa, niż wynika z prognoz.

5. Wiedza o systemach jest w głowach dwóch osób

Jest osoba, która „wie, jak to działa”. Zwykle pracuje w firmie od lat, napisała pół integracji sama i nikt nie ma pełnej dokumentacji tego, co zrobiła. Ryzyko operacyjne jest tu oczywiste, ale jest też drugi, mniej widoczny efekt: taka zależność blokuje zmiany, bo każda modyfikacja wymaga czasu jednej konkretnej osoby.

Warto dodać, że w procesach due diligence przy sprzedaży spółki ten punkt bywa wyceniany bardzo dosłownie. Uzależnienie od pojedynczych osób obniża wartość przedsiębiorstwa.

6. Integracje są punktowe i nikt nie ma ich pełnej mapy

Systemy łączone „na szybko”, po dwa, przy okazji kolejnych projektów, tworzą sieć zależności, której z czasem nikt nie potrafi odtworzyć. Efekt jest taki, że zmiana w jednym miejscu wywołuje skutki w trzech innych — zwykle odkrywane po fakcie, przez klientów.

7. Dział sprzedaży pracuje obok systemu, a nie w systemie

Jeśli handlowcy prowadzą swoje pipeline'y w Excelu, bo CRM „jest niewygodny”, to formalnie firma ma system, a faktycznie nie ma danych o sprzedaży. Prognozowanie staje się kwestią wyczucia, a nie procesu. To jedna z najczęstszych przyczyn niskiej przewidywalności przychodów — i bardzo rzadko rozwiązuje się ją samą wymianą narzędzia.

8. Koszty utrzymania rosną, a możliwości nie

Budżet IT rośnie z roku na rok, ale niemal całość idzie na utrzymanie status quo: licencje, poprawki, łatanie. Udział wydatków na rozwój systematycznie się zmniejsza. To sytuacja, w której firma płaci coraz więcej za coraz mniejszą elastyczność.

9. Czas wdrożenia zmiany liczy się w kwartałach

Zmiana cennika, nowy sposób rozliczania rabatów, inny model subskrypcyjny — jeśli takie rzeczy trwają miesiące, firma traci nie tylko czas, ale i możliwość eksperymentowania. Organizacje, które szybko testują, wygrywają nie dzięki lepszym pomysłom, ale dzięki krótszemu cyklowi uczenia się.

10. Nikt nie odpowiada za architekturę jako całość

Jest osoba odpowiedzialna za ERP, ktoś inny za CRM, ktoś za infrastrukturę. Nie ma nikogo, kto patrzy na całość i zadaje pytanie, czy ten układ w ogóle wspiera strategię firmy na najbliższe trzy lata. To najczęściej spotykana i najbardziej kosztowna luka.

Dlaczego to nie jest problem IT

Kuszące jest potraktowanie tej listy jako zadania dla dyrektora IT. W praktyce problem bywa gdzie indziej. Architektura systemów jest odbiciem tego, jak firma podejmowała decyzje przez ostatnie kilka lat: które projekty dostawały budżet, gdzie szukano oszczędności, jak szybko trzeba było „coś dowieźć”. Każdy taki wybór zostawił ślad.

Dlatego uporządkowanie architektury bez uporządkowania procesów i modelu decyzyjnego zwykle kończy się nowym systemem odwzorowującym stary chaos. Widzieliśmy to wystarczająco często, by traktować to jako regułę, a nie wyjątek.

Drugi wniosek jest taki, że nie każdy z tych dziesięciu sygnałów wymaga natychmiastowej reakcji. Klucz to rozstrzygnięcie, które z nich blokują konkretne cele biznesowe na najbliższe dwa–trzy lata. Firma planująca akwizycje ma inne priorytety niż firma budująca kanał e-commerce.

Od czego zacząć

Zanim pojawi się rozmowa o narzędziach, warto odpowiedzieć na trzy pytania:

- Jakie decyzje biznesowe chcemy móc podejmować w ciągu najbliższych trzech lat i czego wymagają od systemów? - Gdzie dokładnie tracimy czas i pieniądze dzisiaj — w których procesach, w jakiej skali? - Które elementy obecnej architektury są aktywami, a które wyłącznie kosztem?

To pytania, które warto zadać wcześniej niż zapytanie ofertowe do dostawców. Odpowiedzi na nie zwykle zmieniają zakres projektu, a czasem pokazują, że problem da się rozwiązać znacznie mniejszym nakładem, niż zakładano.

Jeżeli rozpoznajesz w tej liście własną organizację, warto spojrzeć na architekturę IT nie jako na temat techniczny, ale jako na element zdolności firmy do wzrostu. W ITTC pracujemy z zarządami właśnie w tym miejscu: od diagnozy, przez projekt docelowego modelu procesów i systemów, po wdrożenie i pomiar efektów — łącząc transformację cyfrową z transformacją operacyjną, bo w praktyce jedna bez drugiej nie działa.