Wyniki wyszukiwania dla „UML diagram klas” – Strona 20

Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

Proces biznesowy, nie procedura i nie opis przepływu pracy, to prosty ciąg czynności, których celem jest konkretny rezultat: produkt procesu (jego wyjście).

Proces ma cel, stanowi prosty łańcuch pracy wykonawcy (Rola), radzi sobie z wydarzeniami „utrudniającymi”. Główny ciąg (oczekiwany) zaznaczono szarą strzałką. Pozostałe „atrakcje” to czynności wymuszone pewnymi nie oczekiwanymi (a raczej nie chcianymi), ale przewidzianymi zdarzeniami. Tu nie ma „rombów”, bramek decyzyjnych bo one są cechą „procesów decyzyjnych”, procedur, a te to reguły biznesowe i „wiedza o biznesie” a nie proces biznesowy. Pewne czynności mogą być ograniczone Procedurą, która mówi, że „tylko tak wolno tę pracę wykonać”.

Reguły biznesowe to wewnętrzne (np. zarządzenia) lub zewnętrzne (prawo) ograniczenia. Pojawia się rola czyli wykonawca (tu rola działu HR – opis kompetencji pracowników), on posiada niezbędną wiedzą i umiejętności, potrafi obsługiwać „maszyny” (także oprogramowanie). Tak więc definicja mówiąca, że proces wykonuje się w w środowisku ograniczeń i wymaga zasobów tak właśnie wygląda: zasoby to ludzie (role), ich wiedza i narzędzia pracy, ograniczenia to reguły biznesowe i procedury.

Czytaj dalej

Czym jest Piąty element – Audyt organizacji czyli analiza biznesowa

Mało która firma ma modele procesów a każda jakoś istnieje! Można żyć bez map procesów, straszne! Co więc oferują firmy doradcze „sprzedające” usługę modelowania procesów biznesowych?

Sedno sposobu pracy organizacji to reguły biznesowe. One rządzą tym, co jest wykonywane i jak. Proces (to jak jest wykonywana praca) to abstrakcja, efekt istnienia ograniczeń (w tym właśnie reguł biznesowych). Tak wiec można zarządzać firmą nie mając modeli procesów podobnie jak można mieszkać w mieście nie mając jego planu.

W czym problem? Bez „mapy” nie rozumiemy wielu zjawisk mimo, że występują. Jednak przydatny model biznesowy to model procesów powiązany z pozostałymi czterema składnikami opisu organizacji (ludzie, prawo, wewnętrzne zarządzenia i procedury).

Model biznesowy to nie są dziesiątki i setki nieczytanych diagramów, pokazujących szczegółowo to co robię pracownicy bo mogą to robić na nieskończenie wiele sposobów. Istotne jest to co powstaje, po co i dlaczego akurat tak.

Na zakończenie: np. model pracy operacyjnej każdego urzędu można kompletnie opisać jednym diagramem. Jeżeli chcesz na prawdę poznać swoją firmę, opracuj jej model. Ale nie w postaci setek diagramów będących suchym zapisem wywiadu.

Rozłóż firmę na czynniki pierwsze i zrozum ją. Bez tego nie zarządzasz a próbujesz zarządzać!

Wykonaj sformalizowany notacjami i słownikiem pojęć, audyt firmy, sposobu funkcjonowania i zrozum jak na prawdę działa.

Czytaj dalej

Analiza biznesowa

Stosowanie opisanych tu formalizmów to uznanie, że dobre i sprawdzone standardy pozwalają zminimalizować ryzyko projektów analitycznych.

Analiza to nie zbieranie danych o firmie i ich sortowanie, bo czy to nie brzmi jak ekologiczne zbieranie śmieci? Analiza to porządkowanie zebranej wiedzy o organizacji, korzystając z wypracowanych systemów pojęciowych, czyli przyporządkowywanie wszystkiego co wiemy do skończonej liczby pojęć, oraz uzupełnianie lub naprawianie wszystkiego czego zabranie w tak opracowanym modelu. Kluczem dobrej analizy jest uogólnianie czyli wychwytywanie rzeczy istotnych oraz odsiewanie informacji zbędnych, nie mających wpływu na cel projektu a zaciemniających go. Analiza to odkrywanie i rozumienie reguł, panowanie nad złożonością organizacji.

Większość projektów takich jak np. wdrażanie nowych metod kontrolingu, zrównoważonej karty wyników, nowych systemów IT itp. cierpi głównie z powodu posiadania nadmiaru informacji z jednej strony i kompletnego jej niezrozumienia z drugiej. Sławne już w badaniach „złe i niekompletne wymagania” czy „zmiany zakresu projektu w trakcie jego trwania” to klasyczne skutki złej (a często pomijania!) analizy biznesowej. Koszty tych porażek wielokrotnie przewyższają koszt takich analiz.

Czytaj dalej

Czas nie jest aktorem dla Systemu c.d. czyli projekt

aktorem absolutnie nie jest Czas, aktorem jest inny system, tu źródło sygnału czasu. Diagram UC jest zgodny ze standardem a my „zrozumieliśmy istotę rzeczy”. Stosowanie w analizie standardów prowadzi do rozumienia i ma taką właśnie zaletę: analiza i modelowanie prowadzi do zrozumienia problemu, łamanie zasad notacji ukrywa niezrozumienie problemu (o co chodzi z tym oczekiwanym przez klienta czasem).

Czytaj dalej

Czas nie jest aktorem Systemu

Tak więc radzę ostrożnie z Wikipedią. Wprowadzanie pojęć ukrywających istotę rzeczy to moim zdaniem, ukrywanie niewiedzy na etapie analizy i projektowania. To jedna z przyczyn złej jakości procesu tworzenia oprogramowania. Niezależnie od tego jak ładnie umotywujemy istnienie aktora Czas, programista i tak musi ten problem rozwiązać i nie będzie to na pewno interfejs „interakcji Systemu z Czasem”… A co z czasem? No cóż, albo człowiek klika co godzinę w coś, albo wewnątrz systemu jest moduł, który generuje zdarzenie wywołujące te samo operację co klikający użytkownik… Moduł wewnętrzny systemu nie jest jego aktorem.

Jak w takim razie w ogólności modelować cykliczność? Np. „prenumerata czasopisma na okres 12 m-cy”, „codzienne generowanie raportu”, „zbieranie wskazań licznika co N jednostek czasu” ? Po pierwsze usługa systemu to odpowiednio: zarządzanie prenumeratami, generowanie raportów, przetwarzanie pomiarów. Prenumerata to zapis mówiący, że mam otrzymać np. każde wydanie jakiegoś periodyka w ciągu danego roku. Generowanie raportów to czynność człowieka (raport na życzenie) albo automatu reagującego na zdarzenie „konkretny czas”, zdarzenia takie generuje np. zegar systemowy. Zbieranie wskazań licznika to cykliczne zdarzenie inicjowane przez System. Implementacja tych wymagań to element projektowania logiki biznesowej i nie jest to już diagram przypadków użycia a model dziedziny systemu bo to tu jest logika biznesowa.

Czytaj dalej

Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Mapa (model) procesów oraz struktura organizacyjna, by były jednoznaczne, muszą być także zestawem zdefiniowanych pojęć. Musimy wiedzieć co znaczy słowo: przełożony, podwładny, komórka organizacyjna czy jej kierownik. Jeszcze większym wyzwaniem zdefiniowanie systemu pojęć dla mapy procesów (proces, czynność, zdarzenie, dokument…). Budowanie systemów pojęciowych spełniających powyższe warunki jest bardzo trudne dlatego dla modeli procesów biznesowych najlepiej wykorzystać gotowy model pojęciowy: jest nim notacja. Najlepiej obecnie opracowanym takim modelem pojęciowym jest gotowa notacja [[BPMN]]. Tworzenie własnych jest kosztowne (czas i wiedza osoby opracowującej) i bardzo ryzykowne (może się nie udać). Dlatego używanie dzisiaj własnych lub innych (np. dostosowywane profilami diagramy UML) jest w moich oczach nieracjonalnym podejściem.

Model pojęć specyficzny dla danej organizacji niestety musi powstać „od zera”, podobnie jak powiązana z nim specyfiakcja reguł biznesowych. Jest to trudne bo tworzenie przestrzeni nazw wymaga utrzymania niezależności poszczególnych definicji i spójności i zupełności całego ich systemu. Niedochowanie tych wymagań prowadzi do niepełności a nawet sprzeczności reguł biznesowych, które w końcu są budowane (odkrywane i dokumentowane) z pomocą tych pojęć. Zanim wiec zaangażujesz kogoś do modelowania własnej firmy, upewnij się, komu zlecasz tę pracę…

W bardzo dużym więc skrócie:

procesy biznesowe to faktyczny, widoczny sposób pracy firm (ludzi w nich zatrudnionych),
procesy to efekt funkcjonowania ludzi w środowisku ograniczeń,
należy poznać tych ludzi,
ograniczenia to: procedury, prawo, zarządzenia wewnętrzne oraz specyficzne dla firmy wewnętrzne normy zwane regułami biznesowymi,
opracowanie biznesowego modelu firmy wymaga zrozumienia i opisania tego co powyżej opisałem,
nie istnieje droga na skróty.
…

Czytaj dalej

Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

W czym problem z kiepskiej jakości analizami i modelami? W tym, że ich autorzy podejmują próby dodawania nowych symboli do notacji, psując spójność i jednoznaczność diagramów, stosują symbole notacji niezgodnie z nadanymi im znaczeniami albo łamią zasadę wyłączonego środka mówiącą w uproszczeniu, że jeżeli coś jest czymś to znaczy, że nie jest już niczym innym (np. jeżeli coś jest zdarzeniem to na pewno nie jest ani czynnością, ani danymi, ani regułą decyzyjną). Innymi słowy: jeżeli jakieś ziarno węgla jest kostką to na pewno nie jest ani groszkiem, ani orzechem ani miałem.

A co jeżeli jednak wynik analizy jest opisem w języku naturalnym lub zestawem diagramów łamiących zasady notacji? Wtedy tak naprawdę analitykami są programiści, bo oni i tak muszą to zamienić na kod w języku programowania, którego używają. Czy to dobry pomysł? Pozostawię odpowiedź czytelnikowi…

Czytaj dalej

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że „nie święci garnki lepią”) dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi „projektowania” czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.

Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:

Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu.
Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: „wiedza organizacji” tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalej