Najpierw pewien nagłówek i cytat:
Koszmar każdego szefa. Jak zarządzać firmą, z której nagle znikają wszyscy kluczowi pracownicy? Taki scenariusz to dramat dla każdego szefa. Wyobraź sobie, że rządzisz firmą, z której nagle znika 25 kluczowych pracowników. Kiepsko, prawda? (Koszmar każdego szefa. Jak zarządzać firmą, z której nagle znikają wszyscy kluczowi pracownicy | NaTemat.pl).
To chyba będzie pierwszy przypadek, gdy odradzam czytanie artykułu, z którego pochodzi cytat, gdyż dyskusja polityczna jest ostatnią rzeczą, jakiej tu oczekuje (i ostrzegam, będę moderował takie wpisy ;)). Kluczem jest sam ten cytat oraz to, że to nie jest niemożliwe.
Często w projektach i na szkoleniach zwracam uwagę, że jednym z powodów, dla których robi się analizę biznesową i modelowanie organizacji jest zapewnienie ciągłości jej działania. Aby to zapewnić, model musi być obiektywny, dlatego zleca się to (modelowanie) zewnętrznemu wykonawcy, podobnie jak inne audyty (samoopisywanie – autoportret – nie jest kontrolą ani weryfikacją).
po raz kolejny przytoczę znany już Wam zapewne diagram:
Jest na nim niepozorny, w stosunku do reszty, element “Wykonawca procesu”.
Teraz robimy test myślowy, każdy z czytelników sam: patrzmy na powyższy diagram (model definicji procesu biznesowego) i sami sobie odpowiadamy na pytanie: ile w danym konkretnym (Waszym jako przełożonego) przypadku “wiedzy” tkwi w osobie “Wykonawca procesu” (tu symbol “karteczka” symbolizuje treści znane tylko jemu, niezapisane nigdzie indziej) a ile zostało udokumentowane w pozostałych. Druga faza eksperymentu: “znika” osoba “Wykonawca procesu”, jak zadziała proces i ile czasu zajmie uzupełnienie tego braku kadrowego.
Tu czynimy założenie: im mniej “wiedzy” w pozostałych “karteczkach” a więcej w głowie Wykonawcy procesu, tym bardziej ciągłość działania procesu (firmy, organizacji) jest zagrożona… Po drugie, na początek warto w ogóle mieć wiedzę, gdzie i co jest pozapisywane i czy w ogóle gdzieś jest… a cytat, jest po to, by nikt mi tu nie pisał, że to niemożliwe ;), bo to, że to mało prawdopodobne to wiemy, ale wiemy także, że bardzo boli jak się przytrafi.
Bardzoooo przedmiotowe traktowanie pracowników 🙁 Ludzie to nie trybiki procesu biznesowego. Jeśli przyjmie się takie podejście do zarządzania, to ryzyko odejścia kluczowych pracowników znacznie maleje.
Nie neguję dokumentowania procesów, ale wiedza przelana “na papier” ma wiele wad. Wymienię trzy: jest ZAWSZE niepełna, jest STATYCZNA – nie reaguje na zmiany i jest A-KREATYWNA – wpływa negatywnie na kreatywność uczestników procesu i przez to hamuje rozwój/ulepszanie procesu.
Paradoksalnie ostatnia wada może też być zaletą :), bo spisanie procesu, często ujawnia jego słabość. Czyli jak to często bywa należy “wszystkiego próbować”, ale z umiarem.
Pytanie: uzupełnienie zasobu czyli jak będzie wyglądała rekrutacja nowego pracownika w miejsce tego, który znienacka zniknie z firmy (wypadek, zwolnienie dyscyplinarne, przejęcie przez konkurencję, inne…) bez informacji o tym jaką rolę pełnił i co powinien umieć (a od niego się tego już nie dowiemy)?
Jeśli ma Pan na myśli rekrutację to sprawa prosta. Każdy zatrudniony pracownik w dziale kadr ma/powinien mieć opis stanowiska pracy/zakresu obowiązków + wysokość uposażenia + miejsce w hierarchii.
Zapewne miał Pan też na myśli, wdrożenie nowego pracownika. Tak jak napisałem wcześniej: “nie neguję potrzeby dokumentowania”. Zwracam też Pana uwagę, że większość opisów procesów biznesowy dezaktualizują się tuż po ich dokończeniu lub nawet przed. Dlatego należy zachować z tym umiar tak w szczegółowości dokumentowania (aby nie przedłużać), jak i sposobie traktowania uczestników (aby nie sprowadzać pracowników do poziomu przedmiotów).
Najlepszym sposobem zachowania umiaru jest wplecenie uczestników w same opisywanie procesu biznesowego – będzie to wymagało uproszczenie narzędzi. Oraz maksymalne skrócenie drogi pomiędzy modelem, a działającym systemem wspierającym model. Idealne byłoby by system był 100% odbiciem modelu.
Skoro zgadzamy się co do potrzeby posiadania udokumentowanych zakresów obowiązków i wymaganych umiejętności na danym stanowisku pozostaje kwestia:
Jeżeli zachodzi sytuacja zdania pierwszego to znaczy, ze model był (jest) po prostu zły. Co do zdania drugiego, owszem ale umiar tu powinien polegać na umiejętnym odcięciu zbędnych/złych szczegółów a nie na skróceniu czasu trwania samego modelowania 🙂
“Jeżeli zachodzi sytuacja zdania pierwszego to znaczy, ze model był (jest) po prostu zły. ”
Model nie musiał być zły, często proces jego tworzenia był zbyt długi.
“Co do zdania drugiego, owszem ale umiar tu powinien polegać na umiejętnym odcięciu zbędnych/złych szczegółów a nie na skróceniu czasu trwania samego modelowania”
A jakie szczegóły są zbędne/złe? 🙂 A może to co “odciął” analityk są “solą” samego procesu?
Nie zgodzę się, czas ma decydującą rolę. Podstawowa rola systemów informatycznych to skrócenie czasu przetwarzania informacji. Co po systemie, który powstaje za późno w stosunku do realiów biznesu?
BTW: Uważam, że nie ma systemów/aplikacji skończonych. Aplikacje mają nieskończony cykl życia, tylko czasami jak są nierozwijane powoli umierają.
Widzę kolejny przykład mieszania poziomu szczegółów. Po pierwsze na odpowiednio wysokim poziomie abstrakcji należy opisać proces z perspektywy celowości a nie szczegółów danych jakie są przetwarzane (najpierw upewniamy się, że jakiś proces w ogóle czemuś służy, a potem dopiero ponosimy koszty jego projektowania). Jeżeli ktoś uważa, że wystarczy poznać szczegóły treści dokumentów (sól procesu) a nie ma czasu na zrozumienie samej jego celowości ich użycia (lub jej braku) to już ma kłopoty, implementując jakieś procesy nie mając pewności czy są w ogóle potrzebne lub w jakiej postaci. Największym błędem wielu firm programistycznych jest uznanie, że stan jaki zastali u klienta, pozyskany z ust jego pracowników jest stanem oczekiwanym i właściwym. Większość firm programistycznych zachowuje się jak kiepski lekarz: wypisują receptę pod dyktando pacjenta.
Co to znaczy, że “tworzenie modelu trwa zbyt długo?”. To brzmi troszkę jak “nie ma czasu na badania, żryjmy w końcu jakieś piguły”. Zbędne szczegóły to podejście “nie wiemy co jest istotne więc spisujemy wszystko”. To bardzo kosztowne projekty. Dobrze wykonana analiza ma ogromną zaletę: pokazuje to co istotne. a nie wszystko. Czym, są rzeczy “nieistotne”? To te, które nie mają wpływu na projekt a wiemy że się u klienta dzieją.
Podstawową rola systemów nie jest skracanie, a umożliwianie. Prosty przykład: kiedyś, w dobie ręcznej księgowości, księgowanie trwało tak samo długo, bo dłużej nie mogło trwać (terminy urzędowe). Dzięki systemom FK teraz można (ledwo mieszcząc się przed terminem składania deklaracji podatkowych) liczyć koszty mając więcej danych niż 20 lat temu czyli dokładniej, nie raz faktycznie także szybciej. Pewne rzeczy wręcz nie było robione, aktualizacja kart magazynowych odbywała się po pewnym czasie na bazie faktur, teraz stan magazynu mamy w “czasie rzeczywistym” – to jest korzyść. Szybkość przetwarzania to faktycznie kluczowa cecha komputera ale samo “robienie szybkiej” nie jest postępem, postęp to często “robienie inaczej”. Typowym przykładem jest email, komputery i sieci nie spowodowały szybszego ruchu listonosza, zastąpiły bo innym medium, nowym nośnikiem treści listów. Komputer nie spowodował, szybszego księgowania na tak zwanej “amerykance” tylko pozwolił na przebudowę systemu zarządzania finansami (jedyne co się nie zmienia to system kont) itd. Bardzo kiepską firmą jest ta, która tylko spisuje dokładnie to co robi użytkownik na “papierze” i przenosi mu to do komputera. To jest model biznesowy IT “analityk dyktafon i programista skryba”.
“Dobra komputeryzacja” to zmiana a nie “przyśpieszanie”….
Co do aplikacji biznesowych. One nie mogą być “nigdy nie nieskończone” bo biznes wymaga choć troszkę stabilności. Dobrze zarządzany cykl życia produkty ma okresy stabilne, zmiany są wprowadzana w jakimś cyklu a nie “na już” bo wtedy użytkownik nie jest w stanie przewidzieć zachowania własnego narzędzia pracy. Dobre system, ERP i nie tylko, bo operacyjne także, żyją od wersji do wersji, w między czasie są wprowadzane jedynie krytyczne poprawki. To, że cykl życia jakiegoś produktu nie zakończył się, że nie znaczy, że ma byc permanenetnie “rozgrzebany”.
JŻ:”Widzę kolejny przykład mieszania poziomu szczegółów…”
Pisząc o “soli procesu” miałem na myśli główną istotę/sens procesu niezależnie od tego na jakim poziomie szczegółowości on się pojawi. Np. może to być: podbicie pieczątki przez wartownika na bramie (duża szczegółowość) lub świadomość, że przesyłka jest w drodze (wysoki poziom abstrakcji).
JŻ:”Największym błędem wielu firm programistycznych jest uznanie, że stan jaki zastali u klienta, pozyskany z ust jego pracowników jest stanem oczekiwanym i właściwym.”
Tak, czasami tak się zdarza. Ale częściej jest tak, że powodem problemów jest nieporozumienie wynikające ze wzajemnego niezrozumienia ról: dostawcy i klienta.
JŻ:”Dobrze wykonana analiza ma ogromną zaletę: pokazuje to co istotne. a nie wszystko. Czym, są rzeczy ?nieistotne?? To te, które nie mają wpływu na projekt a wiemy że się u klienta dzieją.”
Definicja “pożerającego samego siebie węża”:
Co jest istotne -> to co ma wpływ na projekt -> a co ma wpływ na projekt -> to co jest istotne 🙂
Ja wolę definicję taką: Istotne dla projektu jest to co dla klienta przyniesie WARTOŚĆ. A WARTOŚĆ testujemy poprzez weryfikowanie przez klienta.
JŻ:”Podstawową rola systemów nie jest skracanie, a umożliwianie.”
Proponuję jeden test na obalenie tej tezy: proszę podać jeden przykład, czego nie można zrobić bez ERP, przy założeniu, że mamy dowolnie dużo czasu.
JŻ:”Co do aplikacji biznesowych. One nie mogą być ?nigdy nie nieskończone? bo biznes wymaga choć troszkę stabilności. ”
Ależ one zawsze są nieskończone 🙂 ZAWSZE pojawi się użytkownik, który dostrzeże możliwość zmiany/ulepszenia.
JŻ:”Dobrze zarządzany cykl życia produkty ma okresy stabilne, …”
Tu zaprzecza Pan sam sobie. Cykl to RUCH nie STAN. Zrozumiałe jest, że aby “biec czasami trzeba postawić nogę na ziemi” i przez moment jest niby stabilnie. Ale bez świadomości, że to tylko na chwilę inaczej byśmy stawiali nogi. To jest kwestia myślenia do przodu, a nie zachowawczego/bezpiecznego. Konsekwencje wybrania drugiej drogi: “Kto stoi w miejscu ten się cofa.”
JŻ:”..bo wtedy użytkownik nie jest w stanie przewidzieć zachowania własnego narzędzia pracy.”
Zmiana wcale nie musi być widoczna dla użytkownika. A często zmiana na lepsze mimo tego, że jest widoczna, jest dla użytkownika niezauważana. Ze zmianami na gorsze tak już nie jest 🙂
1. podbicie pieczątki na branie to element procedury wejścia na strzeżony teren a nie proces.
2. rola dostawcy i klienta w projekcie to treść zawartej umowy, nie ma tu nie nieporozumień a co najwyżej zła lub nieprzestrzegana umowa.
3. np. usprawnienie procesu sprzedaży jest celem klient, projekt informatyczny to wykonanie programu do tworzenia faktur VAT, o wartości dla klienta decyduje on sam, programista na wykonać na bazie wymagań, program do wystawiania faktur VAT i tylko to jest tu istotne.
4. podobnie jak Archimedes (dajcie mi punkt oparcia a poruszę Ziemię) nikt nie ma nieograniczonych zasobów i nie jest to żaden dowód. Ja świadomie napisałem o ograniczonym czasie
5. Pomysł użytkownika, gdy się pojawi, nie oznacza, że należy ten pomysł realizować.
6. pojawianie się nowych wersji np. kwartalnie a nie co sekundę nie ma nic wspólnego z zastojem,
7. jeżeli użytkownik nie widzi zmiany tego co zaszło w oprogramowaniu, to zapewne mamy do czynienia z refaktoryzacją a nie zmianą.
Na koniec: to Zarząd firmy nią zarządza a nie dostawca oprogramowania, ta druga sytuacja bardzo źle świadczy o tym Zarządzie i wtedy właśnie mamy przypadek pomieszania ról w projekcie.
Dyskusje o szczegółowości “modelu procesów” pojawiają się niemalże w każdym projekcie, powyższy artykuł zawiera diagram jaki stanowi podstawę analizy. problem pojawia się w tych projektach, w których analityk nie potrafi właściwe przypisać odkrywanych faktów (szczegółów) i z wszystkich tworzy “kroki i elementy procesu” co jest poważnym błędem.
Ad.1 Tak.
Ad.2 Oczywiście, że umowa. Ale jakże często umowa zawiera : umowa na wykonanie systemu XYZ 🙂
Ad.3 A nie lepiej jak programista wie jaki jest cel klienta?
Ad.4 Przekornie odwracając: dlatego, że nie mamy ograniczonych zasobów czasu robimy dużo by go mniej marnować. Np. wspomniane “usprawnienie procesu sprzedaży” czyż nie chodzi tu o zmniejszenie czasu obsługi jednego klienta? Wszystko odbywa się w funkcji czasu. Po prostu aplikacje są po to by ludzie mieli więcej czasu na myślenie.
Ad.5 Oczywiście. Nierealizowanie też niesie ze sobą naukę/rozwój aplikacji.
Ad.6 Co sekundę to przesada :), ale nie wiadomo kiedy to stagnacja.
Ad.7 A zmiana protokołu sieciowego lub polegająca na pobieraniu kursów walut z innego banku?
Ad.8 W kontekście budowania architektury, projektowania, implementacji i utrzymania aplikacji to źle wróży dla końcowych efektów. Nawet jak Zarząd posiada odpowiednie umiejętności, może mu wtedy zabraknąć czasu na zarządzanie.
Ogólnie: Umowa na wykonanie powinna zawierać opis przedmiotu jaki ma powstać. Umowa na wykonanie to nie umowa na zarządzanie i podejmowanie decyzji menedżerskich. Umowa na wykonanie to nie jest umowa ana projektowanie. W przeciwnym wypadku mamy właśnie pomieszanie ról w projekcie.
JŻ:”Ogólnie: Umowa na wykonanie powinna zawierać opis przedmiotu jaki ma powstać”
To za mało. Nie wystarczy zapisać, że dostawca ma dostarczyć produkt. Muszą być też opisane odpowiedzialności, albo inaczej produkty przejściowe – jak np. analiza/dokument analizy.
Z braku określenia odpowiedzialności w umowie pojawiają problemy ze zrozumieniem ról. Te problemy wynikają z braku zrozumienia co jest decyzją techniczną/technologiczną, a co jest decyzją zarządczą/biznesową. Oczywiście z każdą umową można sobie poradzić na projekcie 🙂
No i mamy konkluzję: ” Umowa na wykonanie powinna zawierać opis przedmiotu jaki ma powstać” i oczywiście powinności (role) każdej ze stron umowy.
🙂
Dobrego Świętowania i Najlepszego Nowego Roku
Dziękuję 🙂 i wzajemnie