Systemy
Jak zaprojektować system dopasowany do modelu biznesowego
Dobry system operacyjny firmy nie zaczyna się od wyboru narzędzia, tylko od zrozumienia, jak firma faktycznie pracuje. Oto proces, który stosujemy, zanim padnie choć jedna nazwa oprogramowania.
Większość rozmów o „nowym systemie dla firmy" zaczyna się od złego pytania: jakie oprogramowanie kupić. To pytanie ma sens dopiero na końcu procesu, nie na początku. Zanim padnie nazwa jakiegokolwiek narzędzia, trzeba odpowiedzieć na dużo trudniejsze pytanie — jak firma faktycznie pracuje, nie jak wyobraża sobie, że pracuje.
1. Dlaczego projektowanie nie zaczyna się od narzędzia
Wybór narzędzia przed zrozumieniem procesu to jak kupno butów przed zmierzeniem stopy — czasem się trafi, częściej nie. Firmy, które zaczynają od demo produktów i porównywania funkcji, kończą z systemem, który świetnie wygląda na prezentacji i słabo pasuje do tego, jak faktycznie płynie praca między działami.
Projektowanie systemu operacyjnego firmy zaczyna się od pytania o cele biznesowe — co ma się poprawić, o ile i w jakim czasie — a dopiero potem schodzi do poziomu procesów i na samym końcu do konkretnych narzędzi czy modułów.
Kolejność ma znaczenie, bo odwrócona zamienia projekt biznesowy w projekt techniczny. Zamiast pytać „jak chcemy pracować za dwa lata", firma pyta „co potrafi ten konkretny produkt" — i sama siebie ogranicza jeszcze przed pierwszym wdrożeniem.
2. Mapowanie procesów: jak firma naprawdę pracuje
Ten etap polega na rozmowach z ludźmi, którzy faktycznie wykonują pracę — nie tylko z zarządem. Handlowiec, który codziennie wprowadza dane o kliencie, wie o realnym procesie sprzedaży więcej niż jakikolwiek schemat organizacyjny. Mapowanie ujawnia rozbieżność między procesem „na papierze" a tym, co dzieje się w praktyce — a ta rozbieżność jest zwykle większa, niż zarząd się spodziewa.
Dobra mapa procesu pokazuje nie tylko kroki, ale też miejsca, w których dane giną, dublują się albo czekają bez powodu. To właśnie te miejsca są najlepszymi kandydatami do zaprojektowania od nowa, a nie „przeniesienia" do nowego systemu w niezmienionej formie.
3. Priorytetyzacja: nie wszystko trzeba rozwiązać naraz
Po mapowaniu zwykle wychodzi lista dwudziestu, trzydziestu problemów. Próba rozwiązania wszystkich naraz to najpewniejsza droga do projektu, który nigdy się nie kończy. Priorytetyzację warto oprzeć o dwa kryteria naraz:
- Wpływ na wynik firmy. Które procesy bezpośrednio wpływają na przychód, koszty albo satysfakcję klienta?
- Częstotliwość i skala bólu. Który problem powtarza się codziennie i angażuje najwięcej osób naraz?
- Łatwość wdrożenia. Co da się uruchomić szybko i pokazać zespołowi jako dowód, że zmiana działa?
4. Wdrożenie iteracyjne zamiast wielkiego skoku
Systemy projektowane od zera pod konkretną firmę wdraża się etapami, nie jednym „wielkim wybuchem" w weekend. Pierwszy moduł obejmuje zwykle najbardziej dotkliwy proces, działa równolegle ze starym rozwiązaniem przez krótki czas, a dopiero po potwierdzeniu, że działa poprawnie, przejmuje pracę w całości.
Zasada, którą trzymamy się przy każdym wdrożeniu: żaden etap nie startuje, dopóki zespół nie zna odpowiedzi na pytanie „co się stanie, jeśli coś pójdzie nie tak w tym module".
5. Pułapki, które najczęściej psują projekt
Najczęstsza pułapka to projektowanie systemu pod obecną strukturę firmy, zamiast pod strukturę, do której firma dąży za rok czy dwa. Druga to pomijanie ludzi, którzy będą z systemu korzystać na co dzień, na rzecz decyzji podejmowanych wyłącznie na poziomie zarządu. Trzecia to brak jasnego właściciela projektu po stronie klienta — bez niego nawet najlepiej zaprojektowany system rozmywa się w kolejnych priorytetach.
Czwarta pułapka, mniej oczywista, to traktowanie projektu jako jednorazowego wydarzenia zamiast żywego procesu. Firma się zmienia — rośnie zespół, pojawiają się nowe usługi, zmienia się rynek — a system, który nie ma wbudowanej możliwości ewolucji, staje się kolejnym gorsetem, tyle że lepiej skrojonym na start.
System dopasowany do modelu biznesowego nie jest projektem technicznym — jest projektem organizacyjnym, w którym oprogramowanie jest tylko narzędziem realizującym wcześniej podjęte decyzje o tym, jak firma chce pracować.
Zaprojektujmy system dopasowany do Twojej firmy Wróć do bloga