Opis organizacji to dość trudna profesja. Wymaga z jednej strony doświadczenia analitycznego a drugiej wiedzy z zakresu zarządzania i marketingu. Model organizacji to nie jest bowiem tylko jej wewnętrzny przepływ pracy. To także wymiana informacji z jej otoczeniem oraz cała harmonia zasobów jakie organizacja angażuje do tych działań. Dobry model powinien pokazać wszystkie te aspekty organizacji i związki między nimi. Jak nie trudno sie domyśleć, robienie tego (tworzenie diagramów) ręcznie “na piechotę” jest pracą wykraczającą poza możliwości pojedynczego człowieka.  Dla zespołu ręczna praca była by benedyktyńskim wyzwaniem. Dlatego warto korzystać z narzędzi  wspomagających tego rodzaju prace. Tym razem w numerze coś dla analityków i nie tylko. Pakiet iGrafx w wersji testowej.

Wskazywać korzyści z używania notacji UML w pracach  projektowych nad systemami IT chyba nie trzeba jednak zaznaczę tylko, że moim zdaniem projektant i analityk ma dzisiaj dwa wyjścia: zapewnić by projekt był jednoznaczny i spójny oraz czytelny dla zespołu architektów systemów i programistów albo powinien przestać być analitykiem i projektantem.

Dziś wybrałem dwa artykuły

Narzędzia iGrafx (wersja ewaluacyjna)

Modelowanie procesów biznesowych to często projekty związane głównie albo tylko z reorganizacja firmy.  W takich przypadkach pełny opis firmy powinien obejmować nie tylko diagramy procesów ale także schematy organizacyjne, strukturę komórek organizacyjnych, zasoby informatyczne inne. Programy klasy CASE (Computer Aided System Engineering), pomimo, że  zawierają coraz częściej narzędzia do modelowania procesów, nadają się doskonale do dokumentowania analiz projektów, których celem jest powstanie lub wybór oprogramowania jednak nie spełniają wielu wymagań w projektach których celem jest reorganizacja, zarządzanie jakością czy wdrażanie metod controlingu. Pakietem, który nie jest narzędziem CASE ale jest bardzo dobrym narzędziem wspierającym szeroko rozumiane Zarządzanie Zorientowane na Procesy (BPM, ang. Business Process Management) jest właśnie iGrafx.

Pakiet zawiera między innymi moduły:

iGrafx? FlowCharter?
iGrafx? Process?
iGrafx? Process? for Six Sigma
iGrafx? Enterprise Modeler?
iGrafx? Process Central?
iGrafx? Small Busienss Edition (5x FlowCharter + Process Central dla 5 użytk.)
iGrafx? Enterprise Central?
iGrafx? BPEL interface
iGrafx? Process Converter
iGrafx? IDEF0?
iGrafx? Viewer
iGrafx? Viewer Plus

Pakiet ten można polecić każdemu kto zajmuje się dokumentowaniem i analizą wszelkich aspektów organizacji związanych z procesami biznesowymi. Wersja testowa to sposób by sprawdzić to przed ewentualnym zakupem.

UML – modelowanie dynamicznych aspektów oprogramowania

Niewątpliwie UML (według mnie) to notacja nie dla biznesu. Jednak analityk, projektant i architekt  systemowy to właściwe osoby. Niekończące się dywagacje kto jakiej notacji powinien używać i do czego prowadzą tlyko do akademickich dyskusji i do kłopotów komunikacyjnych tam, gdzie niewłaściwym językiem przemawia sie do niewłaściwych ludzi.  Moim zdaniem komunikacja powinna wyglądać tak:

[BUSINESS] <<—BPMN— [ANALITYK] —UML—>> [PROJEKTANT-PROGRAMISTA]

W środku mamy analityka, który nie jest ani prezesem ani programistą ale za to zna biznes i zna systemy. Do każdego zwraca się w jego języku. Ale… tu ma być tym razem o UML.

Prezentacja wymagań na system do trudne zajęcie. Praktyka pokazuje, ze im więcej zwykłego tekstu tym więcej problemów podczas tworzenia systemu. Dlaczego? Bo tekst (proza ;)) nie jst jednoznaczny, jest podatny na interpretację czytelnika. Diagramy cechuje jednoznaczność i praktycznie brak możliwości interpretacji innej niż jedna, ta jaką miał na myśli autor. Wyobraźmy sobie zresztą jak wyglądałyby nasze domy, gdyby jedynym elementem dokumentacji architektonicznej był słowny opis architekta.

Artykuł opisuje drugi, po przypadkach użycia i modelu dziedziny systemu, aspekt opisu wymagań: zachowania systemu. Nie jest to proste biorąc pod uwagę różnorodność problemów: obiekty stanowe (np. dokumenty, ludzie), współbieżność i transakcyjność i wiele innych. Opisanie tekstem w sposób jednoznaczny tych elementów wymagań jest praktycznie nie możliwe. Za pomocą diagramów: sekwencji, komunikacji, aktywności, maszyny stanów, czy przebiegów czasowych możliwe jest przekazanie  opisu budowy systemu np. programistom będąc niemalże pewnym, że napiszą kod taki jaki chciał projektant mimo, tego, że nie będzie go w tym procesie kodowania.

Artykuł polecam każdemu kto ma ambicje lub potrzebę poznania notacji UML.

Z jednej strony trudno się nie zgodzić z tezą, że elektroniczny obieg dokumentów to przyszłość. Z drugiej mam wrażenie, że podejście technokratyczne zmierzające do wyeliminowania papieru jest jednak chybione. Między innymi dlatego, że paradoksalnie papier jest najtrwalszym i najbezpieczniejszym w relacji do ceny sposobem przechowywania informacji a jego zużycie rośnie nie tylko w Polsce.

Dokumenty i procesy

Demagogią jest twierdzenie, że koszt przechowywania dokumentu elektronicznego to tylko kilka mikrometrów dysku i koszt tego mini obszaru. Prawdziwym kosztem przechowania dokumentu elektronicznego jest koszt całej infrastruktury wraz z jej zabezpieczeniem. Gdyby było inaczej każdy z nas miał by już w firmie elektroniczne super archiwum.

Po drugie obieg dokumentów to nie zarządzanie procesami. Dokumenty są tylko jednym z elementów mapy procesów organizacji. Więc systemy obiegu dokumentów to wsparcie zarządzania zorientowanego na procesy a nie systemy zarządzania procesami biznesowymi. Ale po kolei.

Wielu konsultantów utożsamia pojecie obiegu dokumentów, obiegu informacji z procesami biznesowymi i ich zarządzaniem. Jest to moim zdaniem kluczowe nieporozumienie, żeby nie powiedzieć błąd.

Proces biznesowy to działanie charakteryzujące się przede wszystkim wnoszeniem wartości dodanej, obecność papieru czy dokumentu w wersji elektronicznej nie ma tu nic do rzeczy. Na mapie procesów biznesowych dokumenty i ich kolejne wersje stanowią produkty procesów (nie jedyne). Proces polegający na podjęciu decyzji to praca człowieka niosąca dużą wartość dodaną ale nie obieg dokumentów będących śladami po niektórych tylko procesach w firmie.

Inny przykład: procesem jest wyprodukowanie podzespołu i nie ma to nic wspólnego z systemem obiegu dokumentów. Gdzieś po drodze będzie proces powstania dokumentacji technicznej ale to jeden z elementów systemu zarządzania procesami w firmie, jego podsystem.

Tak więc na pewno systemy obiegu dokumentów, obiegu informacji są ważnymi elementami w każdej organizacji ale są to tylko produkty i to nie wszystkie na mapie procesów biznesowych firmy dlatego właśnie nazywanie systemów klasy workflow systemami BPM (Business Process Management) uważam za poważne nadużycie.

Kolejna ślepa uliczka jaką dostrzegam w reklamach systemów klasy workflow to wskazywanie jako głównej korzyści ich wdrożenia narzucenie ścisłej kontroli poczynaniom pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników wbrew ich woli. Typowym przykładem są różnego typu restrykcyjne systemy kontroli czasu pracy czy kontroli pracy przy komputerze, nadzór urzędnika tą metodą także się nie sprawdza. Lepszy jest moim zdaniem system informatyczny zaprojektowany tak by pomagał pracownikom osiągać ich cele. On niejako wdraża się sam. Systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez ludzi.

Jednak coś w tym jest, obieg dokumentów (danych) czasami staje się modelem procesów.

Kompletne opracowanie:

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