Za system IT odpowiada Prezes a nie informatyk

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.

Czytaj dalej Za system IT odpowiada Prezes a nie informatyk

Modelowanie a rysowanie

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.

Czytaj dalej Modelowanie a rysowanie

O błędach w modelowaniu

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.

Czytaj dalej O błędach w modelowaniu

Co tam Panie w Software czyli mały przegląd prasy

Wakacje spowodowały u mnie mały zator prasy dlatego postanowiłem napisać kilka słów o tym co w całej kupce a nie o tym co pojedynczym numerze. Od pewnego czasu jestem czytelnikiem miesięcznika Software Developer’s Journal (SDJ). Co prawda jestem analitykiem a nie np. koderem ale w końcu niektóre projekty i UML’owe obrazki piszę dla koderów właśnie a dobrze jest znać swojego “klienta” i jego potrzeby. A co znajdziemy w numerach z Czerwca, Lipca i Sierpnia? Kilka ciekawostek

Czytaj dalej Co tam Panie w Software czyli mały przegląd prasy

Modelowanie biznesowe, czy to już dojrzała dyscyplina?

Ideą twórców BPMN jest stworzenie narzędzia dla analityków ale takiego, którego produkty da się “tłumaczyć” na BPEL4WS. Bazą dla BPMN są sieci Petriego i EPC. Dla tego z jednej strony kompletna lista symboli BPMN to 38 symboli obrazujących typowe zdarzenia biznesowe dające się odwzorować za pomocą BPEL4WS, modelować zaś można już za pomocą sześciu podstawowych, które pozwalają na zbudowanie pełnego modelu procesów biznesowych. Pozostałe symbole służą do dodatkowego definiowania zdarzeń koniecznych z punktu widzenia inżynierii oprogramowania. Dlatego np. model wykonany za pomocą podstawowego zestawu symboli przez analityka da się łatwo uzupełnić jako kontynuacja projektu o brakujące elementy w celu wygenerowania kodu dla BPEL. ten zaś być może będzie standardem służących do generowania kodu aplikacji jak dawne systemu typu CASE.

Czytaj dalej Modelowanie biznesowe, czy to już dojrzała dyscyplina?

Zasoby IT a procesy przetwarzania informacji

W obecnych czasach informacja to towar tak potrzebny jak pieniądz a bywa, że bardziej. Narzędzia i wiedza używane do pracy z informacją powinny być adekwatne do jej znaczenia i wartości dla firmy. Informacja to zawarta danych wartość konieczna do pracy każdej firmy. Dane takie jak lista pracowników wraz z faktamni z okresu ich pracy zawierają informacje potrzebne do prawidłowej ich oceny i wypłaty wynagrodzenia. Dane o sprzedaży zawierają informacje o kontrahentach, ich preferencjach, ich wartości dla firmy. Przykłady można mnożyć w nieskończoność. Ale co tak na prawdę jest potrzebne firmie? Dane, informacje, moze coś innego…Po co przetwarzamy te informacje?

Czytaj dalej Zasoby IT a procesy przetwarzania informacji