Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: “nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale”. To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa… a nie raz z jego łamaniem. 

Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji. Opisał trzy-etapowy referencyjny (i zalecany) proces wdrażania nowych rozwiązań, a na jego tle, w swoim opracowaniu, wskazał dostrzeżone zaniedbania administracji:

(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, “Architektura korporacyjna ? problemy nie tylko pojęciowe”)

Cytuję to opracowanie, bo model ten jest bardzo podobny do ogólnej trójwarstwowej koncepcji organizacji. Prof Szafrański zwraca uwagę na to (z czym się zgadzam), że kolejność podejmowania decyzji i działań, powinna być następująca: opracowanie nowej lub zmienionej strategii (Dokument strategiczny), opracowanie taktyki działania (Model operacyjny działania) oraz opracowanie planu wdrożenia IT (Fundament działalności, w kontekście Architektury Korporacyjnej). Oczywiście nic nie stoi na przeszkodzie, by inicjatywa wyszła “od dołu”.

W swoim opracowaniu prof. Szafrański wskazuje, że wdrożenie nowej strategii wymaga sprawdzenia i ewentualnego opracowania nowych mechanizmów, procedur, prawa, pozwalającego nie tylko wdrożyć nową strategię ale także skutecznie ją “wymusić”.

Jeżeli powyższy model uogólnić do postaci obrazującej związek pomiędzy: strategią rynkową organizacji, wewnętrzną taktyką realizacji misji oraz tym jak zostały one zaimplementowane, to powstanie taki oto diagram (po prawej znane od lat opracowanie Business Process Trends):

Jeżeli pomiąć formę prawną, każda organizacja ma strategię i każda jakoś ją realizuje (implementuje: ma pracowników a Ci umiejętności i zakresy obowiązków). Mało która organizacja ma tak zwany “model operacyjny”, czyli to co łączy strategię i ludzi z ich obowiązkami i uzyskiwanymi efektami pracy. Czym jest taki model? To model procesów biznesowych: środkowa “warstwa” powyższego diagramu po prawej.

Rozwijające się ewolucyjnie organizacje zawsze dokumentują detale prac (informacje w procedurach zarządzania jakością i tak zwanych dokumentach kadrowych), często dokumentują to, jaką rolą pełni organizacja w swoim otoczeniu (misja, wizja, strategie itp.) i bardzo rzadko dokumentują wewnętrzny łańcuch wartości czyli procesy biznesowe oraz, no najważniejsze,  logika tego jak “to wszystko działa” w środku (i czy działa z sensem). Wadą większości tego typu projektów, jakie obserwuję, jest skupianie się na detalach i pomijanie pryncypiów. W efekcie projekt pochłania wiele pracy i nadal nie mamy zrozumienia całości (w lit. ang. “big picture”), osiągane efekty są losowe. 

 

Pokażę na dość prostym przykładzie o czym mowa (polecam ww. opracowanie prof. Szafrańskiego, opisał w nim błędy popełnione w przypadku informatyzacji Państwa). 

Poniższy diagram to uproszczony model organizacji z zainstalowanym systemem EOD (Elektroniczny Obieg Dokumentów)  oraz zachowanym, nadal wykorzystywanym “po staremu” oprogramowaniem poczty elektronicznej.  

Linie ciągłe to droga jaką pokonują dokumenty z użyciem EOD. Linie przerywane to poczta elektroniczna. Jeżeli zostanie w jakiejś organizacji zainstalowany EOD (celowo nie używam słowa “wdrożony”) i nie zostanie z niej usunięty email jako narzędzie alternatywnej wewnętrznej komunikacji, to użytkownik będzie sam decydował, o tym którym kanałem przekaże daną treść. W efekcie EOD, który miał “mieć wszystko” nie ma wszystkiego, dane w EOD są niewiarygodne i niekompletne. Jeżeli jest to urząd, to metryka sprawy w zasadzie nie ma sensu, celem jej tworzenia była możliwość odtworzenia pełnego przebiegu sprawy, a tu urzędnik sam decyduje, które informacje i dokumenty przekazuje kanałem formalnym (EOD), a które “na boku”. Czy wszystko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tylko uznaniowym archiwum dokumentów. 

Aby skutecznie wdrożyć EOD należy najpierw opracować nowy model operacyjny działania organizacji, model uwzględniający nowe narzędzie pracy, model który w sposób systemowy wyeliminuje niepożądane elementy “złego starego systemu”. Dla przykładu powyżej należy wyeliminować kanały komunikacyjne oznaczone linią przerywaną. Domyślam się, że wielu czytelników myśli teraz “no jak to tak bez maila?!”. Po wdrożeniu EOD, wewnętrzny mail jest już nie potrzebny (a nawet jest szkodliwy), a na zewnątrz nadal jest narzędziem komunikacji firma-firma (tak np. działa mój system komunikacji z klientami). Bardzo często spotykam urzędy i firmy, w których obieg email i obieg “formalny” to uznaniowość pracowników. Te wdrożenia nie spełniają podstawowej roli systemów EOD: śledzenie spraw, statystyki zajętości pracowników, wychwytywanie wąskich gardeł, łatwe zastępowanie się pracowników, możliwość skontrolowania i przejęcia sprawy w dowolnym momencie, pełna historia wymiany informacji. 

Takie wdrożenia to właśnie bardzo często inicjatywy na średnich szczeblach, gdzie mogą powstać decyzje o wydaniu środków na takie wdrożenie, ale nie ma żadnych szans na decyzje o opracowaniu i wdrożeniu zmian operacyjnych w skali organizacji (np. aktualizacja instrukcji kancelaryjnej w urzędzie, bez czego wdrożeni EOD nie ma tu żadnego sensu).

Celowo podałem ten przykład, bo typowym powodem niepowodzeń wdrożeń systemów EOD czy CRM (te systemy mają najgorszą statystykę niepowodzeń, a są bardzo podobne do siebie), jest brak opracowanego i wdrożonego skutecznego nowego operacyjnego modelu działania organizacji “po wdrożeniu”. Takim modelem są modele procesów biznesowych, ale nie w postaci monstrualnych ilości detalicznych diagramów (te są tu do niczego nie przydatne). Nie znam przypadku, by takie “obrazki” się do czegokolwiek przydały.  Chodzi o modele sformalizowane, o ściśle ustalonym poziomie gradacji procesów. Ile diagramów “powinno być”? Tylko i aż tyle, ile trzeba do rozwiązania problemu… co opisałem między innymi tu.

 

Powyższe ma także inny istotny aspekt: planowanie i wdrażanie zmian.  Typowy rozwój organizacji przebiega w sposób ewolucyjny, dość powolny. Nie wymaga żadnych dodatkowych zabiegów poza przemyślanym wprowadzaniem nowych, pojedynczych zarządzeń czy drobnych zmian organizacyjnych. Jednak próby wdrożenia znacznych zmian w krótkim czasie, z reguły skutkują nieoczekiwanymi efektami, nie zawsze pożądanymi. “Moda” na re-inżynierię  procesów biznesowych w latach 90-tych przeminęła tak szybko jak się pojawiła. Dzisiejszy silnie konkurencyjny rynek nie daje czasu na powolne, ewolucyjne zmiany. Bezpieczne zaś wprowadzanie takich zmian nie jest możliwe bez przygotowania. Opisane powyżej plany operacyjne i ich testy, to nic innego jak właśnie przygotowanie się do takich zmian. Mając dobrze opracowane modele procesów i architektury IT (jako całość Architektura Biznesowa/Korporacyjna), możemy przewidzieć i przetestować, większość skutków planowanych zmian, i powoli ale coraz więcej firm to robi…  

Jarosław Żeliński

Jarosław Żeliński: 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 wykładowca akademicki wizytujący (nieetatowy), 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). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.