UML – Page 37 – JZ IT Consulting Ltd

Za system IT odpowiada Prezes a nie informatyk

Post author:Jaroslaw Zelinski
Post published:2 October 2007
Post category:Analizy biznesowa i projektowanie oprogramowania

Osobą odpowiedzialną za system IT zawsze będzie zamawiający. Dlatego zamawiający powinien jednoznacznie opisać swoje oczekiwania i zrozumieć potem odpowiedź czyli propozycję ich wykonawcy. Menedżer nie musi uczyć się diagramów UML ale powinien rozumieć modele procesów tak by mieć możliwość ich oceny i zatwierdzania. Dlatego modele procesów powinny być tworzone metodami zrozumiałymi dla menedżerów, moim zdaniem nie jest to notacja UML. Notacja ta jednak jest niewątpliwie doskonałym narzędziem do udokumentowania i przekazania swoich oczekiwań przyszłemu wykonawcy systemu: integratorowi IT. Tak więc wykonaj model procesów biznesowych, określ które procesy chcesz informatyzować. Potem przygotuj na bazie tej analizy listę przypadków użycia przyszłego systemu, uzupełnij ją o model pojęciowy twojego biznesu i firmy i przekaż to do realizacji wykonawcy systemu. Na koniec pozostaje wdrożenie a to już osobny projekt :), socjologiczny.

Modelowanie a rysowanie

Post author:Jaroslaw Zelinski
Post published:25 September 2007
Post category:Analizy biznesowa i projektowanie oprogramowania

Model to przede wszystkim narzędzie analityczne i komunikacyjne. Analityczne bo model powinien bez potrzeby kontaktu z pierwowzorem zachowywać sie tak jak on (w wybranym kontekście oczywiście). Komunikacyjny bo powinien być zrozumiały dla osoby nie biorącej udziału w jego tworzeniu. Po trzecie model powinien odwzorowywać istotę badanego zjawiska a nie kopiować jego poboczne cechy lub opisywać nie wnoszące nic do badania informacje oczywiste lub wręcz zaciemniające istotę problemu. Model wieży Eiffla do celów zbadania oporów powietrza nie musi zawierać informacji o kolorze i o tym ile schodów należy pokonać by na nią wejść. Na tej samej zasadzie rysowanie na diagramie faktu, że np. dokument jest komukolwiek przekazywany z ręki do ręki jest rysownictwem a nie modelowaniem.

O błędach w modelowaniu

Post author:Jaroslaw Zelinski
Post published:31 August 2007
Post category:Analizy biznesowa i projektowanie oprogramowania

Poprawny model organizacji, w szczególności mapa procesów biznesowych, powinien opisywać tylko przedmiot analizy np. specyfikę organizacji będąca np. źródłem jej przewagi konkurencyjnej i to jak organizacja tę specyfikę tworzy. Model powinien się odwoływać do innych istniejących już dokumentów, np. zakresu kompetencji pracownika czy instrukcji stanowiskowej. Model zawsze powinien mieć jakiś cel swojego powstania i kontekst.

Czy juzkejsy zabijają innowacyjność?

Post author:Jaroslaw Zelinski
Post published:15 June 2007
Post category:Analizy biznesowa i projektowanie oprogramowania

Tak więc, model biznesowy, udokumentowane procesy i role powinny być kluczowym wymaganiem jakie stawiać należy systemom IT. Powinny one wspierać model biznesowy i strategię firmy a nie być tylko nowym fajnym i wizerunkowym zasobem. Moim zdaniem wymagania na systemem powinny być oczekiwaniem wsparcia dla modelu biznesowego a nie tylko prostą listą kilku tysięcy funkcjonalności.

Model biznesowy: co to za zwierze?

Post author:Jaroslaw Zelinski
Post published:21 September 2006
Post category:Analizy biznesowa i projektowanie oprogramowania

Ano mamy opis firmy i możliwość wskazania priorytetów w obszarach wymagań na system, tak ważnych przy określaniu wykonywalności projektu IT, w szczególności jego rentowności. Mając model łańcucha wartości można łatwo zbudować model wewnętrznych procesów biznesowych , gdyż jest on ta na prawdę niczym innym jak dekompozycją modelu łańcucha wartości. Idąc wiec droga od opisu firmy do modelu jej procesów można zbudować np. taki oto model w notacji BPMN (od góry: model biznesowy, model procesów, wymagania na system IT) :