Pierwszy sygnal: nowe potrzeby sa zawsze 'na chwile'
Jesli kazda nowa potrzeba konczy sie dopisaniem kolejnej wtyczki, pola, formularza albo instrukcji dla zespolu, to najczesciej znak, ze firma probuje naprawiac architekture dodatkami. To nie jest z definicji zle. Problem zaczyna sie wtedy, gdy obejscia sa juz stale i staja sie jedynym sposobem, by proces w ogole przechodzil dalej.
W pewnym momencie koszt tej improwizacji staje sie wyzszy niz koszt uporzadkowania logiki w jednym miejscu. To jest moment, w ktorym warto przestac myslec o funkcjach i zaczac myslec o systemie.
Drugi sygnal: nikt nie umie jednoznacznie powiedziec, gdzie jest logika procesu
Jesli odpowiedz brzmi 'troche w systemie, troche w mailach, troche w Excelu i troche w glowach ludzi', firma nie ma systemu. Ma zbior punktow, ktore akurat dzialaja razem. To nie skaluje sie dobrze, zwlaszcza gdy rosnie liczba klientow, partnerow, produktow albo wyjatkow.
Wlasny system nie zawsze oznacza ogromna platforme. Czasem to po prostu jedna warstwa, ktora przejmuje odpowiedzialnosc za krytyczne decyzje, statusy i zasady walidacji.
Trzeci sygnal: proces jest strategiczny dla wyniku firmy
Jesli dany proces wplywa na marze, przewage, zgodnosc formalna, jakosc obslugi albo szybkość realizacji, nie warto zostawiac go w przypadkowej architekturze. W takim obszarze firma potrzebuje kontroli nad tym, jak dziala logika i jak zmienia sie wraz z biznesem.
To jedna z glownych przyczyn, dla ktorych powstaja wyspecjalizowane systemy takie jak PluginVvest albo rozwiazania z zakresu konfiguratorow i automatyzacji ofertowania.
Czwarty sygnal: kazda zmiana kosztuje za duzo
Jesli drobna zmiana wymaga przejscia przez kilka narzedzi, poprawienia instrukcji dla zespolu i recznego dogrania danych, problem nie lezy w braku funkcji. Problem lezy w tym, ze firma nie ma jednego miejsca kontroli nad procesem. Wtyczka przestaje byc rozwiazaniem, a staje sie kolejnym miejscem podatnym na blad.
Wlasny system zaczyna wtedy dawac wartosc nie dlatego, ze jest 'customowy', tylko dlatego, ze obcina narastajacy koszt zmian.
Jak nie pomylic potrzeby systemu z przerośnietym projektem IT
Nie kazdy balagan oznacza od razu potrzebe budowy platformy od zera. Czasem wystarczy dobra integracja, middleware albo lepszy model odpowiedzialnosci. Dlatego decyzja o systemie powinna byc poprzedzona porownaniem scenariuszy. Temu sluzy tekst o wyborze miedzy systemem dedykowanym a SaaS.
Jesli jednak po takiej analizie wciaz wychodzi, ze problemem jest brak wlasnej logiki procesu, wtedy budowa systemu nie jest fanaberia. Jest naturalnym etapem dojrzewania organizacji.
