Czy warto zagłębiać się w analizę procesów zamiast spokojnie prowadzić własny biznes? Nie wydaje mi się, żeby istniała jednoznaczna odpowiedź. Wielu ludzi jeździ samochodem, nie interesując się zbytnio, jakie kółka zębate obracają się pod maską. Kiedy coś się zepsuje, oddają samochód do warsztatu, idą na kawę, a potem płacą mechanikowi wyliczoną przez niego kwotę. Są też świadomi klienci, którzy dokładnie wiedzą, jakim rodzajem wtrysku charakteryzuje się ich silnik i kiedy wymienić olej w skrzyni biegów. Trudno wprost wartościować oba te podejścia, ponieważ oba mają tyle samo wad i zalet. Kierowca “laik” traktuje samochód jako narzędzie - pokrywa rachunki za naprawy, ale za to nie musi przejmować się technikaliami. Kierowca bardziej “techniczny” więcej czasu i uwagi poświęca na kontrolę pracy mechanika i odpowiednie użytkowanie pojazdu. On za to płaci mniej za naprawy.

Myślę, że - chociaż prosta - ta analogia sprawdzi się i tu. Można prowadzić zyskowną firmę i nie przejmować się teorią biznesu. Co więcej, podejrzewam, że większość małych i średnich przedsiębiorstw w Polsce prowadzona jest w ten właśnie sposób. Nie ma w tym nic złego. Nie trzeba wiedzieć, że mówi się prozą - wystarczy mówić z sensem. Jeżeli firma prowadzona jest zgodnie z regułami rynku, ma szansę działać bez analizy procesów, Business Intelligence i innych skomplikowanych konstruktów.

Inaczej wygląda to od naszej strony. Jesteśmy firmą, która specjalizuje się w informatycznym wsparciu biznesu. Dla nas znaczy to, że mamy obowiązek nie tylko tworzyć oprogramowanie, ale także rozumieć, po co je tworzymy. Nie stworzymy dobrego rozwiązania, nie znając do końca problemu, dlatego też każdy projekt rozpoczynamy właśnie od analizy procesów biznesowych klienta. Ponieważ jest to proces czasochłonny i złożony, ujednoliciliśmy jego przebieg i oferujemy jako usługę Analizy Biznesowej.

Dobrym przykładem analizy procesów jest wywiad, jaki musieliśmy przeprowadzić przed stworzeniem platformy do zarządzania wakeparkami. Zanim zespół developerski mógł choćby włączyć komputery, zanim zespół UX naostrzył ołówki, wyizolować każdy z zachodzących w wakeparku procesów, a następnie opisać go i zmodyfikować. Na przykład: Do systemu wpada rezerwacja. W ilu miejscach musi się pojawić ta informacja? Kto powinien ją otrzymać i jakie akcje powinna wywołać? W jakich raportach powinna się pojawić i jakie rejestry zmodyfikować? Kto ma wpływ na przebieg procesu, a kto ma dopasować do niego swoje działania? Są to wszystko pytania, na które musimy sobie odpowiedzieć, aby nie tylko rozwiązać pojedynczy problem techniczny, ale także przybliżyć klienta do realizacji biznesowego celu projektu.

Jesteśmy uważnymi słuchaczami - opowiedz nam o swoim biznesie i razem zastanówmy się, jak można pomóc mu rosnąć