W toku niejednej analizy można spotkać się z sytuacją gdy standardowe podejście polegające na badaniu dokumentów i analizie zstępującej (od ogółu do szczegółu, ang. top-down) może być trudne lub wręcz nie możliwe. Dotyczy to analizy systemów słabo udokumentowanych lub wręcz nieudokumentowanych, gdzie jedyne dostępne dane to obserwacja lub relacja obserwatora (uczestnika, itp. czyli relacja z drugiej ręki). Jest to sytuacja podobna to serii (pakietu) zebranych "user story" (w nomenklaturze metodyk zwinnych historyjki użytkownika), nieformalnych relacji. Jak ugryźć taką sytuację? Z pomocą przychodzi pojęcie specyfikacji instancji w UML, zapewne brzmi to…
?Wszystko powinno być tak proste jak jest to możliwe, ale nie prostsze.? (Albert Einstein) Stosunkowo niedawno (piałem o tym już) Roger Burlton (Chairman, Board of Advisors, BPTrends) opublikował na stronie Business Process Trends Manifest Procesu Biznesowego. Podejrzewam, że to efekt lekkiej" konkurencji z [[Business Rules Group]] i Ronaldem G. Rossem ;) ale dobrze bo taka konkurencja jest twórcza a ich (głównie Ronald G. Ross BRGroup oraz Paul Harmon z BPTrends) obecne ich polemiki na stronach LinkedIn są bardzo pouczające i myślę, że obie strony na tym zyskują, że nie wspomną o pozostałych…
We wtorek miałem referat na warsztatach zorganizowanych przez MMC Polska: KPI ? Zarządzanie wskaźnikami w praktyce. Mój referat i warsztat zarazem był zatytułowany: KPI a system zarządzania przez cele. Nie będę streszczał 1,5 godzinnego warsztatu, raczej zapraszam na następne. Tu zwrócę uwagę na kilka ciekawych i ważnym moim zdaniem kwestii. Niestety w literaturze i w sieci jest wiele dziwnych, moim zdaniem tez, np. Punktem wyjścia do doboru wskaźników powinna być strategia organizacji. Dlaczego strategia? Wskaźnik opisuje jakiś parametr obszaru działania organizacji, z reguły jest miernikiem wskazującym to czy zrealizowano jakieś zadanie. Strategii nie…
Jeżeli uznamy, że modelowanie zachowania organizacji w postaci modelu procesów polega wyłącznie na tworzeniu diagramów zawierających kolejno wykonywane detaliczne czynności, to znaczy że wszelkie powyżej opisane zachowania znajdą się jako "równoprawne" aktywności na tych diagramach. Powstają monstrualne nieczytelne schematy blokowe, zawierające setki detali, trudne do interpretacji, trudne i kosztowne w utrzymaniu (aktualizacja), i przede wszystkim nie pozwalające na wyprowadzenie wprost z nich wymagań na oprogramowanie. Można w zasadzie zaryzykować tezę, że tak tworzone modele, w których cała wiedza o organizacji została zapisana jako łańcuchy detalicznie zobrazowanych czynności, tak na prawdę do niczego nie są przydatne. [...] Czemu więc służą żmudne wywiady, warsztaty, burze mózgów w toku analiz firm? Zaryzykuję, tezę, że niczemu nie służą.
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
Cztery lata temu, pisałem o regułach biznesowych jako elemencie modelu biznesowego i ich roli w zarządzaniu: Na czym więc polega skuteczne zarządzanie? Na zrozumieniu, posiadaniu planu działania i przemyślanym tworzeniu ograniczeń.Robi tak każda większa firma: powstają zakresy obowiązków, wewnętrzne zarządzenia i procedury. To wszystko to nic innego jak ograniczenia.Opracowanie modelu organizacji więc, to nie tylko opisanie procesów bo te są jedynie efektem istniejących ograniczeń. Pełny model organizacji, dający zrozumienie tego jak ona działa, to kompletny model pojęciowy ? nazwy i definicje podstawowych pojęć opisujących jej działanie (co to jest klient, produkt, kontrahent, ?), specyfikacja wszelkich…
Wprowadzenie Ukazują się różne opracowania na temat tytułowej transformacji. Jednym z takich opracowań jest tekst Transformacja Modeli Pana Piotra Carewicza z firmy 300 D&C, opublikowany w periodyku Analiza Biznesowa Lato 2015 firmowanym przez Warszawski oddział IIBA. Pozwolę sobie na pewną polemikę z przedstawionym tam procesem transformacji modelu procesów biznesowych BPMN na Przypadki Użycia notacji UML. Autor powołuje się na OMG.org i specyfikacje BPMN i UML. Dlatego dla porządku przytoczę kluczowe definicje. 10.3 ActivitiesAn Activity is work that is performed within a Business Process. An Activity can be atomic or non-atomic(compound). The types…
Co prawda formalna publikacja wersji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie utonie (spokojne przebrnięcie tych 794 stron wymaga czasu i cierpliwości), czyli wzmianka i kilka słów z pierwszych wrażeń. Specyfikacja do pobrania tu: Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5) Zdaję sobie sprawę z tego, że poniższe nie wszystkim z Was wszystko wyjaśni ale ten akurat wpis adresuję dla tych z Was, którzy korzystają już z UML, nawet w bardzo prosty sposób. Wersja 2.5 UML to wersja chyba przełomowa, bo: zrezygnowano w…
Pół roku temu artykuł o roli Product Ownera kończyłem słowami: Tak więc nasuwa się wniosek, że rolę PO powinien pełnić ten człowiek, który właśnie skończył analizę biznesową i napisał raport z niej. Raport, który zawiera specyfikacją wymagań (najlepiej w formie jak opisana powyżej). W zasadzie nadzór autorski nad realizacją taktyki wdrożenia systemu ERP (oprogramowania w ogóle) to nic innego jak ?bycie product ownerem? w projekcie na etapie jego realizacji a SCRUM faktycznie, na dzisiejsze czasy, wydaje się być najlepszą metodą zarządzania takimi projektami a utrzymywanie aktualności dokumentu analizy biznesowej i…
Dzisiaj bardzo krótko. Bardzo lubię termin "inżynieria wymagań" dlaczego? Po kolei. Z wiedzy o semantyce i semiotyce wiemy, że zastąpienie pojęcia jego definicją nie może zmienić (nie może, jeżeli definicje są poprawne) znaczenia całości. Więc zastąpmy w zwrocie "inżynieria wymagań" oba słowa ich definicjami (definicje ze słownika j.polskiego PWN): inżynieria ?projektowanie i konstruowanie obiektów oraz urządzeń technicznych? wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać? Po podstawieniu otrzymamy zwrot mówiący, że "inżyniera wymagań" to: ?projektowanie i konstruowanie? ?warunków, którym ktoś lub coś musi odpowiadać? Więc nie jest to…
Napisałem ten artykuł jako zapowiedź tego, że będę pisał od czasu do czasu o ekonomii bo przedsiębiorstwa, organizacje, my wszyscy, tkwimy w jakimś systemie ekonomicznym. Systemy informatyczne i systemy informacyjne to fascynująca dziedzina, systemy te są częścią systemu ekonomicznego w jakim funkcjonują, lub będą funkcjonowały jako planowane do wdrożenia. To powoduje, że planowanie takich wdrożeń powinno być - dla zminimalizowania ryzyka porażki - robione świadomie i ze zrozumieniem. Ekonomia zawsze stanowi kontekst wdrażanych systemów ERP i innych, skoro tak nie można nie brać jej pod uwagę w toku analiz z nimi związanych. Do tej pory nie poruszałem tej wiedzy w swoich postach ale przyszła pora i na to.
Wstęp Temat wynagrodzeń dyskutowany jest od pewnego czasu, na ich zbyt niski poziom narzeka wielu. Pracodawcy i szeroko pojęci liberałowie, bronią się przed zarzutami o wyzysk [[machiawelizmem]]: "wolno wszystko to co nie jest zabronione" i dodają, że przecież ludzie się na niskie wynagrodzenia godzą, nikt ich nie zmusza, więc w czym problem? Czy aby na pewno nikt lub nic ich nie zmusza? Bardzo ciekawa ocena zjawiska w Forbes: Wiadomo bowiem nie od dziś, że na etapie negocjowania wynagrodzenia między zatrudniającym a zatrudnionym, istotne znaczenie ma różnica miedzy tym, co pierwszy…
Szperałem w sieci szukając informacji o architekturze i microservisach, a wpadłem na to: ... communication between two different software modules is proportional to the communication between the designers and developers of these modules. Conway?s law exposes the vulnerability in monoliths as they grow in size. Micro-services may not be the best, but better than monoliths for the contemporary web based applications. (Źródło: Micro-Services: A comparison with Monoliths | My Blog) To "prawo" wyjaśnia dlaczego powstają złe interfejsy a nawet zła architektura: z reguły dlatego, że to - architektura - jest lepszym lub…