źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
Kolejny artykuł z gatunku "przemyślenia i rady na koniec roku" :) Często spotykam się traktowaniem reguł biznesowych jak jakiegoś piątego koła u wozu (o ile w ogóle się ktoś nimi zajmuje w projekcie). Pół roku temu pisałem, że reguły biznesowe to, jeżeli stają się wymaganiem, stanowią kluczowy element realizowanej logiki biznesowej: Sprawdzoną metodą skutecznego (spójność, kompletność, niesprzeczność) zapisywania wymagań dziedzinowych (w tym ?walidacje?) jest wydzielenie w dokumentacji: słownika pojęć słownika reguł biznesowych specyfikacji tablic decyzyjnych jako uzupełnienia reguł biznesowych. (Gdzie są te cholerne szczegóły). Jest jednak drugi, nie mniej ważny, element każdego…
Dzisiaj niespodzianka pod choinkę :) czyli VP wersja 12.00. Zaczynam prace a tu taki email: Dear Jarek Zelinski,We are thrilled to introduce to you the brand new Visual Paradigm - Visual Paradigm 12.0 with a new user interface and suite of new tools which improves your modeling efficiency. One of the highlighted improvements is the increase in diagram editing space, which means you have more room for editing your design and can be more focused on modeling. Click here to watch the introduction video of the Sleek UI, the official…
Jaki opis powstanie po przeprowadzeniu kilku dni warsztatów z graczami, którzy grają od lat, zasady gry znają na pamięć, bywa ze podejmują próby łamania zasad dla osiągnięcia doraźnych efektów? To będą długie, nie raz niespójne wywody. Każdą z wymienionych gier opisują jednak jednoznacznie dwa bardzo krótkie dokumenty: reguły gry oraz minimalne umiejętności i wiedza każdego z graczy. Z takim dokumentem każdy projektant oprogramowania sobie poradzi bez problemu.
Na pytania dotyczące notacji BPMN i źródeł informacji odpowiadałem, że jedynym wyjściem na początek jest oryginalna specyfikacja, dawałem od razu wskazówki, które treści można pominąć, bez uszczerbku dla poznania samej notacji jako takiej. Nie mniej jednak specyfikacja ta, to kilkaset stron trudnego, naukowego tekstu, do zrozumienia którego wymaga się jednak biegłej znajomości i czytania modeli pojęciowych (diagramy klas notacji UML), co jest cechą wszystkich specyfikacji z OMG.org. Na szczęście pojawiła się książka Szymona Drejewicza. Nie jest to książka o analizie i modelowaniu procesów biznesowych, jest to książka o notacji, w…
Książka Business Analyst?s Mentor Book mile mnie zaskoczyła. Dość często spotykam się z polecaniem książki Business Analysis, którą ja niestety raczej odradzam z uwagi na bardzo mechaniczne, uproszczone porady a nie raz wręcz fałszywe. Ta książka zaś, dla odmiany, nie skupia się na narzędziach (to nie jest lista porad w rodzaju "w celu ... zrób to ... używając tego...) bo nie da się żadnej analizy sprowadzić do procedury. Ta książka to praktyczne, rzetelne rady i dobre praktyki. Autorzy zwracają uwag na to, że analiza i projektowanie (no bo czym są rekomendacje…
Dzisiaj będzie bardzo krótki wpis, którym niemalże w całości będzie cytat z artykułu pewnego programisty. Każdy analityk i projektant powinien przeczytać cały artykuł (nie jest długi) i koniecznie komentarze pod nim. Jeden komentarz zacytuje bo jest znamienny, choćby dlatego, że moje doświadczenia są dokładnie takie same: Co Ty człowieku, życia nie znasz? Przecież w realu jakbyś poszedł do takiego i podzielił się takimi uwagami to foch na pare tygodni co najmniej gwarantowany. Kiedyś miałem podobną sytuację (a raczej serię sytuacji, ale dotyczących rzeczy o mniejszej skali) to efekt był taki,…
Tym razem małe "case study". Poniżej opis , tak wygląda większość mich projektów. Najczęściej mam kontakt z firmami, które przekonały się, że zawarcie umowy od razu na analizę wymagań i realizację projektu bez projektowania, i to w dodatku jako umowę T&M (czas i materiał) rodzi problemy. Prezes EXTREM, lubi zadawać wiele pytań, miał doświadczenie z poprzedniego wdrożenia (w zasadzie nie doprowadzonego nigdy do końca): Firma EXTREM w 2013 roku rozpoczęła proces wyszukiwania na rynku oprogramowania CRM i jego dostawcy. W toku prowadzanych prezentacji okazało się, że oferty różnią się od…
Równo 10 lat temu (wtedy to na full time stałem się niezależną jednoosobową firma analityczną) napisałem: Decyzja o wdrożeniu jakiegokolwiek systemu informatycznego wspierającego działalność firmy wymaga oceny zasadności takiego projektu oraz wskazaniu obszarów działalności firmy, które zyskają na takim wdrożeniu. Bardzo często popełnianym błędem jest rozpoczęcie rozważań dotyczących potrzeby i możliwości wdrożenia konkretnej aplikacji. Jest to dość typowe działania inicjowane najczęściej złożeniem oferty przez dostawcę aplikacji a nie raz także znalezieniem reklamy danego produktu obiecującej poprawę funkcjonowania firmy w wyniku li tylko wdrożenia oferowanego rozwiązania. Dlaczego to jest błąd? Odpowiedź…
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).
