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ć:

  1. 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ł:

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.