Dbałość o jednoznaczność i spójność dokumentacji to kluczowa cecha analityka, pisałem o tym między innymi w artykule o tępieniu niejednoznaczności. Uznawanie, że to nie ważne, dopuszczanie do nieprecyzyjnych definicji, uznawanie pewnych pojęcia za bliskoznaczne czy wręcz synonimy, prowadzi do nie tylko do emocji w rozmowach ale to nieprzydatności tworzonych dokumentów.
Tak więc brak (umiejętności) stosowania abstrakcji w modelowaniu czyni te i inne modele (schematy blokowe) nieczytelnymi, trudnymi do interpretacji, kosztownymi w wytworzeniu i utrzymaniu. To ostatnie powoduje, że większość takich dokumentów szybko kończy życie na półkach, bo dezaktualizują się jak tylko dojdzie do jakiejkolwiek, nawet najdrobniejszej, zmiany w organizacji. Co ciekawe, biorąc pod uwagę czas trwania przeciętnego wdrożenia oprogramowania, taki zbyt szczegółowy model nie ma szans być przydatnym w toku takiego projektu, tu rację mają developerzy, którzy twierdzą, że im takie dokumenty im w niczym nie pomagają.
Tak więc modele procesów, w których pojawiają się tory reprezentujące jakiekolwiek oprogramowanie gwałcą tę podstawową zasadę: organizacja to celowe działanie ludzi, narzędzia im w tym tylko pomagają, narzędzia nie są istotą działania organizacji. Można to sprawdzić czymś co ja nazywam testem wyłączenia zasilania: czy wyłączenie automatów pozbawi organizację sensu jej istnienia? Jeżeli nie to znaczy, że automaty nie pełnią ról w procesach, a są jedynie narzędziami w rękach ludzi. Narzędzi nie umieszczamy więc w modelach procesów.
Mój niedawny referat na temat trendów w wyborze i wdrażaniu systemów workflow i zaproszenie na kolejną konferencję z tego zakresu, skłoniły mnie do przerzucenia ciężaru referatu z istoty przepływu dokumentów, na przepływ dokumentów w kontekście wdrożenia narzędzia. które w tym pomaga. Poniżej prezentacja ilustrująca referat: http://www.slideshare.net/zelinski/zarzdzanie-informacj-i-automatyzacja-procesw-biznesowych-40106919 Na koniec tego krótkiego wpisu dodam, że w swej głównej części, system obiegu dokumentów to jeden przypadek użycia. (referat był wygłoszony na konferencji EOIF GigaCon, 9 Października 2014 we Wrocławiu).
Autor prezentuje podejście, które nazywam podejściem "opartym na danych". Co mam na myśli? Otóż podejście to zakłada, że istotą "systemu" jakim jest organizacja są gromadzona i zarządzane dane (wiedza). Inne podejście, nazwę je operacyjne (lub procesowe), zakłada że istotą organizacje jest odgrywanie określonej roli na rynku (dostawca produktów, usługodawca, itp.). Innymi słowy istotne jest to co potrafię zaoferować a nie to jakimi danymi dysponuję.
Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju "ale ja chcę zobaczyć to wszystko na jednym diagramie" pchamy projekt w kierunku "utraty panowania nad złożonością"... To prosta droga do klęski projektu.
Analizy biznesowe wymagają oderwania się od technokracji, nie ma czegoś takiego jak dziesiątki przypadków użycia dla jednej faktury, nie ma systemowych przypadków użycia (nawet w specyfikacji UML ich nie znajdziecie), są kompletne (dające jako efekt przydatne produkty) usługi aplikacyjne i korzystający z tych usług aktorzy, w tym inne aplikacje lub komponenty. Dokumentacje zawierające setki przypadków użycia to nieporozumienie, technokratyczni zabójcy projektów. Warto się zastanowić zanim powierzycie analizę i projekt logiki systemu technokratycznemu developerowi...
Ta konferencja przekonała mnie, że w sumie to jestem zwinny, bo: moje umowy mają zakres i harmonogram, praca jest iteracyjna, całość bazuje na wizji, opisuję jak stwierdzimy, że wykonałem swoją prace... a specyfikacje wymagań jakie opracowuję, mają nie setki i tysiące pozycji, a góra kilkadziesiąt.
Swego czasu pisałem na temat granic systemu i o analizie systemowej (analiza systemowa). Rzecz w tym, że pojęcie "analiza systemowa" jest używane najczęściej (jak obserwuję, prawie zawsze) w znaczeniu analizy i projektowania oprogramowania (systemy IT) co jest błędem.Tak zwane "całościowe myślenie" (holistyczne) to uznanie, że system to nie tylko oprogramowanie. Literatura przedmiotu, praktyka moja i nie tylko, potwierdza jedno: wymagania biznesowe to całościowe spojrzenie na biznes i cele biznesowe, wymagania wobec oprogramowania to dopiero "wymagania wobec rozwiązania" (polecam [[BABoK]] z IIBA). Jakiś czas temu zamówiłem książkę Systems Thinking. Potwierdza, że…
Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.
Wakacje sprzyjają filozofii. Tym razem kontynuacja opisanej tu niedawno książki Kotarbińskiego: Kurs logiki. Logika bardzo pomaga w analizie. Prawie trzy lata temu pisałem o Trzech zasadach logiki, jedna z nich jest kluczem w analizie, to zasada wyłączonego środka. Brzmi ona: jeżeli p to nie q Można ją wyrazić prościej słowami: jeżeli coś jest czymś, to nie jest niczym innym. Czemu jest tak ważna? Zobaczmy najpierw znaczenie słowa analiza (źr. sł. j.polskiego PWN, pominąłem chemiczne, trzecie znaczenie): analiza 1. ?rozpatrywanie jakiegoś problemu, zjawiska z różnych stron w celu jego zrozumienia lub…
PwC przedstawiła wyniki badań statystycznych i sugestie przyczyn prezentowane przez dystrybutorów, innymi słowy zadała wiele pytań i uporządkowała odpowiedzi na nie. Znamienne jest także to, że Raport ?Analiza wpływu zjawiska piractwa treści wideo na gospodarkę w Polsce? przygotowany przez PwC przygotowano na zlecenie Stowarzyszenia Dystrybutorów Programów Telewizyjnych "Sygnał". Nie mam podstaw do oskarżania PwC o stronniczość, ale na pytanie: czy Stowarzyszenie promowało by raport uderzający w ich interesy, sami Państwo musicie sobie odpowiedzieć, ja jestem wyłącznie niezależnym analitykiem :) i na tym się skupię.
