Ile systemów IT naprawdę potrzebuje Twoja firma?

Pytanie, które zwykle zadawane jest za późno

Rozmowa o architekturze IT w firmie rzadko zaczyna się od strategii. Zaczyna się od problemu: handlowcy nie raportują, produkcja nie widzi zamówień, dział finansowy zamyka miesiąc w Excelu, a zarząd czeka trzy tygodnie na dane, które powinny być dostępne codziennie. Wtedy pojawia się pomysł: potrzebujemy systemu.

I to jest moment, w którym warto się zatrzymać. Bo pytanie „jakiego systemu potrzebujemy?” jest wtórne wobec pytania „ile systemów IT naprawdę potrzebuje nasza firma i po co?”.

Z doświadczeń naszych ekspertów wynika, że w średnich przedsiębiorstwach liczba realnie używanych narzędzi cyfrowych jest zwykle wyższa, niż zarząd zakłada. Do ERP dochodzi CRM, do CRM osobne narzędzie do ofertowania, do tego system kadrowo-płacowy, program do fakturowania, arkusze planistyczne, komunikator, dysk chmurowy, narzędzie do zarządzania projektami, platforma marketing automation oraz kilka aplikacji, które kupił jeden dział i nikt ich nie wyłączył. Formalnie każde z nich rozwiązywało jakiś problem. W sumie tworzą jednak środowisko, w którym nikt nie jest w stanie odpowiedzieć na proste pytanie: gdzie jest prawda o tym kliencie, zamówieniu albo marży.

Nadmiar systemów to nie problem IT. To problem procesowy

Większość „chaosu systemowego” nie powstaje z powodu złych decyzji zakupowych. Powstaje dlatego, że proces nie był zdefiniowany, a system miał go zastąpić.

To bardzo częsty mechanizm. Coś nie działa w organizacji — na przykład sprzedaż nie jest przewidywalna. Zamiast opisać, jak wygląda ścieżka od leada do zamówienia, kto za co odpowiada i w którym momencie następuje decyzja, kupowany jest CRM. Po sześciu miesiącach okazuje się, że CRM jest wypełniany wybiórczo, prognoza wciąż jest życzeniowa, a menedżerowie i tak prowadzą własne zestawienia. Wniosek, który zwykle pada, brzmi: „ten system się nie sprawdził”. Prawdziwy wniosek jest inny — system odwzorował nieuporządkowany proces i pokazał jego braki w sposób bardziej widoczny niż wcześniej.

Dlatego liczba potrzebnych systemów nie wynika z wielkości firmy ani z branży. Wynika z liczby i dojrzałości procesów, które faktycznie muszą być zarządzane danymi.

Ile realnie kosztuje jeden system za dużo

Koszt licencji jest zwykle najmniej istotnym elementem rachunku. Znacznie więcej kosztuje to, czego nie widać w budżecie IT:

- czas pracowników na podwójne wprowadzanie danych i ręczne uzgadnianie zestawień, - czas menedżerów na weryfikację, która wersja liczby jest właściwa, - opóźnione decyzje, bo dane spływają po fakcie, - błędy w ofertach, zamówieniach i rozliczeniach wynikające z rozjazdu między bazami, - integracje i utrzymanie, które rosną nieliniowo wraz z liczbą połączonych narzędzi, - uzależnienie od kilku osób, które „wiedzą, jak to działa”.

Ten ostatni punkt bywa najbardziej kosztowny w dłuższym horyzoncie. Firma, w której wiedza o przepływie informacji jest rozproszona po głowach kilku pracowników, jest trudniejsza do skalowania, trudniejsza do przekazania nowemu zarządowi i niżej wyceniana przy transakcji. Uporządkowana architektura systemowa nie jest tylko kwestią wygody operacyjnej — jest elementem wartości przedsiębiorstwa.

Cztery pytania, które porządkują myślenie o architekturze IT

Zanim podejmiesz decyzję o kolejnym wdrożeniu, warto przejść przez kilka pytań. Brzmią prosto, ale odpowiedzi rzadko są oczywiste.

1. Jaką decyzję biznesową ten system ma poprawić?

Nie „jakie funkcje ma mieć”, ale jaka decyzja będzie podejmowana szybciej, trafniej lub taniej. Jeśli nie da się wskazać konkretnej decyzji i osoby, która ją podejmuje, prawdopodobnie kupujesz narzędzie, nie rozwiązanie.

2. Gdzie jest jedno źródło prawdy o kliencie, produkcie i zleceniu?

W dojrzałej architekturze każda kluczowa encja ma jednego właściciela systemowego. Klient jest zakładany w jednym miejscu, produkt w jednym miejscu, zlecenie w jednym miejscu. Wszystko inne pobiera te dane. Brak tej zasady jest najczęstszą przyczyną tego, że firma ma dane, ale nie ma informacji.

3. Czy proces jest opisany na tyle, żeby dał się zapisać w systemie?

Jeśli w rozmowie o procesie pojawia się „to zależy”, „u nas różnie” albo „każdy handlowiec robi to po swojemu”, wdrożenie systemu tego nie naprawi. Najpierw decyzja o standardzie, potem narzędzie.

4. Co wyłączamy?

To pytanie prawie nigdy nie pada, a jest jednym z najważniejszych. Każde wdrożenie powinno mieć zdefiniowaną listę narzędzi, arkuszy i obiegów, które przestają być używane. Bez tego firma nie wymienia systemu — dokłada kolejną warstwę.

Zasada minimalnej wystarczającej architektury

Dobra odpowiedź na pytanie o liczbę systemów zwykle brzmi: tyle, ile potrzeba, aby każdy krytyczny proces miał jedno miejsce zapisu danych — i ani jednego więcej.

W praktyce w firmie produkcyjnej lub handlowej średniej wielkości oznacza to zazwyczaj trzon w postaci systemu klasy ERP, warstwę relacji z klientem, warstwę raportowania i analityki oraz obsługę obszaru ludzi. Reszta powinna być albo elementem tych systemów, albo mieć bardzo wyraźne uzasadnienie własnego istnienia. Nie jest to sztywna reguła — architektura firmy inżynieryjnej, e-commerce i usługowej będzie różna. Zasada jest jednak wspólna: integralność danych jest ważniejsza niż bogactwo funkcji pojedynczych narzędzi.

Warto też uczciwie przyjąć, że część redukcji nie polega na wyłączaniu systemów, ale na ograniczaniu ich użycia do ról, w których rzeczywiście dodają wartość. Nie każde narzędzie musi być używane przez całą organizację.

Jak podejść do porządkowania

Sensowna sekwencja jest zwykle odwrotna do tej, którą narzuca presja czasu.

Pierwszym krokiem jest inwentaryzacja: lista narzędzi, kosztów, właścicieli, liczby użytkowników i procesów, które obsługują. Bardzo często już na tym etapie widać nakładające się funkcje i systemy, za które firma płaci, choć praktycznie z nich nie korzysta.

Drugim krokiem jest mapa procesów krytycznych — nie wszystkich, tylko tych, które decydują o przychodzie, marży i terminowości. Trzecim: decyzja o docelowej architekturze i o źródłach prawdy dla kluczowych danych. Dopiero czwartym — wybór dostawcy i wdrożenie.

Najtrudniejszy element jest zwykle poza technologią. To decyzja o standaryzacji sposobu pracy i konsekwencja w jej utrzymaniu. Transformacja cyfrowa, która nie jest jednocześnie zmianą nawyków menedżerskich, kończy się jako droga wymiana interfejsu.

Praktyczny wniosek

Jeśli w Twojej firmie dane nie zgadzają się między działami, raporty powstają ręcznie, a każde nowe pytanie zarządu wymaga kilkudniowej pracy analitycznej, problemem najprawdopodobniej nie jest brak systemu. Problemem jest architektura, która nigdy nie została zaprojektowana — tylko narosła.

Dobra wiadomość jest taka, że uporządkowanie zwykle nie wymaga rewolucji ani wymiany całego środowiska. Wymaga natomiast decyzji, których nie da się delegować do działu IT, bo dotyczą sposobu zarządzania firmą.

Jeżeli rozpoznajesz ten obraz w swojej organizacji, warto spojrzeć na niego szerzej niż przez pryzmat kolejnego wdrożenia. W ITTC pracujemy z zarządami nad diagnozą procesów, projektowaniem docelowej architektury i przeprowadzeniem zmiany tak, aby technologia realnie wspierała wyniki, a nie generowała kolejną warstwę pracy.