Mam takie swoje stare powiedzenie, które często pomaga mi w pracy: jeżeli czegoś nie da się narysować lub opisać to znaczy, że to nie istnieje. Pozornie proste ale okazuje się, że nie zawsze. To opracowanie dotyczy celów i metod modelowania i optymalizacji organizacji i przepływu pracy. Brak modelu funkcjonowania firmy jest najczęstszą przyczyną porażki projektów związanych z wdrażaniem technologii informacyjnych.
W obecnym czasie jednym z głównych czynników sukcesu na rynku jest czas obsługi kontrahenta oraz czas reakcji na zmiany na rynku. W efekcie niektóre firmy popadają w cykl kosztownych i czasochłonnych chronicznych zmian i zatwierdzeń schematu organizacyjnego i oferty w odpowiedzi na każda zmianę na rynku. Okazuje się, że proces taki i tak nie jest w stanie nadążyć za potrzebami. Dlatego w model firmy powinien być wbudowany sprawny mechanizm zmian.Bardzo wiele firm ma jeszcze strukturę organizacyjną nastawioną na wielokrotną kontrolę aż do szczytu hierarchii bez delegacji uprawnień. Jest to wynik trendów w zarządzaniu z czasów, gdy czas podejmowania decyzji nie był krytyczny zaś komputery wspierały tylko pojedyncze stanowiska pracy a nie skoordynowaną pracę całej firmy. Władza w firmie i kierowanie nią są jeszcze często realizowane za pomocą dyrektyw i ich zatwierdzania. Jest to jednak kosztowny i mało elastyczny sposób kierowania firmą.
Czego nie robić:
- Nie robić żadnej szczegółowej mapy procesów i procedur na dziesiątki stron! 80% z nich i tak ulegnie zmianie w trakcie wdrożenia, w końcu wdrożymy narzędzie do pomocy, które ma zmienić, ulepszyć te procedury wiec po co? Przykład: nie ma znaczenia jak jest dokument zatwierdzany obecnie a jak w nowym systemie, ma być zatwierdzany szybko i z małym ryzykiem pomyłki.
Nie szukać systemu który ?pasuje do nas? bo raczej żaden od razu nie pasuje. Ostrożnie podchodzić do ?dobrych praktyk? i ?modeli referencyjnych?. Zgodnie z zasadą: Jeżeli w dwóch różnych firmach, nawet w tej samej branży, funkcjonuje taki sam model biznesowy i procesowy to w jednej z nich na pewno jest zły! System informatyczny powinien pozwolić obsłużyć nasze wymagania (procesy) ale nie procedury. Procedury tworzy się w tracie wdrażania.
Pobierz cały artykuł:
