Zwinne (Agile) modelowanie procesów biznesowych, w moim odczuciu, musi zawierać minimum trzy zasadnicze kroki:
Powyższe linki przenoszą do miejsc, w których opisano te trzy działania.
To działanie polega na ustalaniu celów modelowania procesów biznesowych.
Celem tego działania jest:
określenie obszarów, które będą modelowane,
ustalenie zakresu prac w bieżącej i przyszłych iteracjach,
określenie wartości jakich spodziewa się po modelowaniu zlecający wykonanie modeli procesów biznesowych
Działania
Czynność ta rozpoczyna się od oceny organizacji pod kątem wyboru procesów, które podlegać będą modelowaniu. Podczas dokonywania oceny, może być konieczne, aby zacząć budować wykaz powszechnie stosowanych terminów i definicji, które będą ujęte w Słowniku Biznesu. Może być także konieczne uwzględnienie architektury biznesu i udokumentowanie jej w dokumencie: Opis Organizacji. Natomiast wszystkie reguły biznesowe odkryte podczas tych czynności muszą być ujęte w odpowiednio w dokumencie Opis Organizacji lub dokumencie Scenariusze Procesów Biznesowych.
W czasie szacowania potrzeb organizacji jest istotne, aby wyznaczyć jasne, realistyczne cele modelowania biznesu w celu określenia właściwego zakresu czynności modelowania biznesu, które mają być wykonane. Istotnym jest aby w tym zakresie osiągnąć porozumienie pomiędzy wszystkimi interesariuszami.
W czasie szacowania potrzeb organizacji potrzeba by poznać w miarę możliwości specyfikę działania organizacji oraz jej strukturę tak by móc oszacować zakres prac i produktów jakie zostaną wykonane w każdej iteracji.
Pozostałe kroki to:
Działanie to polega na identyfikacji procesów biznesowych znajdujących się w modelowanym obszarze organizacji.
Celem tego działania jest:
identyfikacja procesów biznesowych oraz tych elementów organizacji, które biorą udział w zidentyfikowanych procesów
hierarchizacja procesów pod kontem decyzji, które procesy trzeba opisać bardziej szczegółowo
Działania
Celem tej czynności nie jest szczegółowe opisanie całość organizacji tylko dostatecznej takiej ilości informacji, która umożliwi zespołowi określenie, na których częściach organizacji trzeba się skupić w pozostałej części projektu lub iteracji. Chodzi oto by nie modelować nieistotnych z punktu widzenia zlecającego model i zakresu iteracji części organizacji.
Czynności wykonywane w trakcie identyfikacji procesów biznesowych stanowią podstawę do opisu biznesowych przypadków użycia. Warto na tym etapie wstępnie wytypować byty biznesowe i pracowników biznesowych, którzy uczestniczą w tych procesach. Identyfikacja tych elementów pozwala na wytypowanie czynności, jakie są wykonywane w organizacji a to stanowi wstęp do budowy Modelu Biznesowych Przypadków Użycia, który zostanie uzupełniany Aktorami Biznesowymi i Biznesowymi Przypadkami Użycia, które powinny być uszczegółowione tylko na tyle, aby zrozumieć ich znaczenie i uporządkować je.
Po określeniu modelu biznesowych przypadków użycia należy zdecydować, które i w jakiej kolejności biznesowe przypadki użycia muszą być dokładniej opisane.
Należy pamiętać, że wszelkie zasady, koncepcje, a także definicje odkryte podczas dokonywania tych czynności muszą być ujęte w Słowniku Biznesu. Jeśli jest to konieczne należy poprawić dokument w którym znajduje się opis organizacji.
Pozostałe kroki to:
To działanie polega na uszczegółowieniu wybranych procesów biznesowych.
Celem tego działania jest:
identyfikacja wszystkie ról, produktów, zdarzeń w organizacji, a także opisanie, w jaki sposób biznesowe przypadki użycia będą wykonywane przez pracowników biznesowych i byty biznesowe,
dostarczenie szczegółów o bytach biznesowych, pracownikach biznesowych, zdarzeniach biznesowych,
sprawdzenie, czy wyniki modelowania biznesu są zgodne z wizją biznesu interesariuszy
Działania
W trakcie tej czynności trzeba dokładnie przeanalizować każdy biznesowy przypadek użycia i zastanowić się jakie byty biznesowe są potrzebne aby zrealizować scenariusz biznesowy, który jest reprezentowany przez dany biznesowy przypadek użycia. Należy określi także jakie produkty są potrzebne lub jakie warunki muszą być spełnione na początku scenariusza, aby mógł się on zacząć. Trzeba określić także co jest produktem końcowym scenariusza. W trakcie tej czynności należy spisać scenariusz słownie a następnie przedstawić go na odpowiednich diagramach, które stanowić będą realizację biznesowych przypadków użycia.
Wszystkie etapy, składające się na scenariusz procesu biznesowego, należy opisać w dokumencie Scenariusze Procesów Biznesowych. Należy pamiętać, że wszelkie zasady, koncepcje, a także definicje odkryte podczas dokonywania tych czynności muszą być ujęte w Słowniku Biznesu. Jeśli jest to konieczne należy poprawić dokument Opis Organizacji.
Po zbudowaniu modeli należy przedstawić interesariuszom do weryfikacji celem sprawdzenia, czy wyniki modelowania biznesu są zgodne z ich wizją biznesu.
Pozostałe kroki to:
Od kilku dni jest dostępne wiosenne wydanie The Rational Edge.
http://www.ibm.com/developerworks/rational/rationaledge/?S_TACT=105AGX15&S_CMP=EDGE
Jak zwykle garść dość ciekawych artykułów. Tym razem wydanie zostało poświęcone szacowaniu projektów. Wskazuje na to artykuł Colin O’Neill’a, w którym można znaleźć kompletne wzory i techniki pozwalające wyliczyć ROI projektu oraz (bardziej mnie) interesujący tekst dotyczący szacowania złożoności oprogramowania w oparciu o punkty funkcyjne. Wyliczanie złożoności i kosztów w oparciu o punkty funkcyjne jest o tyle istotne, że ROI jest złudne, o czym warto pamiętać. Ponadto czasem buduje się soft z ROI bliskim zera lub ujemnym co wynika np.: z wymogów prawa. Natomiast szacowanie oprogramowania w oparciu o punkty funkcyjne przypadków użycia pozwala na oszacowania nie tylko kosztów ale także złożoności. Może to być także klucz do planu iteracji. Po trzecie ja ten artykuł zaciekawił mnie szczególnie bo sam używam tej metody.
Nie mniej jednak oba teksty będą na pewno przydatne wszystkim osobom, które w “jakiś magiczny sposób” muszą oszacować oprogramowanie pod względem opłacalności.
Pracownik Biznesowy jest abstrakcją człowieka, oprogramowania lub urządzenia (lub nawet systemu, który się z nich składa), który reprezentuje rolę odgrywaną w Scenariuszu Procesów Biznesowych. Pracownik biznesowy współpracuje z innymi pracownikami biznesowymi i operuje bytami biznesowymi.
W ramach WMB Pracownicy Biznesowi dodatkowo za pomocą odpowiednich stereotypów wskazują na systemy komputerowe oraz ludzi.
Aktor biznesowy reprezentuje rolę odgrywaną względem biznesu przez kogoś lub coś znajdującego się w otoczeniu organizacji.
Aktorem może być człowiek lub system komputerowy. Aktor biznesowy pozwala określić granice organizacji oraz wskazać jakie byty z otoczenia organizacji korzystają z funkcji, których ona dostarcza.
Celem modelowania biznesowego jest:
Schemat organizacyjny nie jest wystarczający, aby zrozumieć działanie firmy. Potrzebujemy również dynamicznego widoku przedsiębiorstwa. Model biznesowy zapewnia statyczny widok konstrukcji organizacji i dynamiczny widok procesów w obrębie organizacji. Jedną z technik prezentacji dynamiki i struktury firmy jest język UML.
Słowo kryzys jest odmieniane i wymieniane tyle razy, że ja też nie chcę być gorszy. Panika kryzysowa chyba bardziej jest szkodliwa niż to co obserwujemy. Nie zmienia to faktu, że mimo trudności jakie firmy mają w związku z ze zmianami w gospodarce muszą się one rozwijać lub chociaż nie kurczyć – także w sektorze z wykorzystaniem IT. Tak zwani specjaliści mówią,ze w tym okresie wysiłek inwestycyjny zwróci się wielokrotnie w nadchodzących (choć nikt nie wie kiedy) czasach prosperity. Co mogą zrobić firmy? Moim zdaniem zainwestować w SOA. Architektura zorientowana na usługi (Service Oriented Architecture – SOA) umożliwia ściślejszą korelację działalności biznesowej i obsługi informatycznej, która prowadzi do większej elastyczności i sprawności działania, a przez to wzmacnia przedsiębiorstwo. SOA jest ukierunkowane na wiele czynników:
W konsekwencji architektura zorientowana na usługi pozwala dokonać innowacyjnych zmian w modelu biznesowym. SOA to odpowiedź na rosnące oczekiwania klientów co do jakości produktów i usług wsparcia oraz co za tym często idzie coraz bardziej złożone infrastruktury informatyczne. SOA nie jest łatwe w projektowaniu i wdrożeniu bo wymaga pełnej współpracy businessu z IT, gdyż przenosi technologię w sferę decyzji strategicznych. Tak sobie myślę, że być może warto pochylić się nad SOA w dobie podejmowania decyzji strategicznych dotyczących przetrwania dekoniunktury.
Każdy produkt informatyczny ma kilka faz a te najbardziej znane to:
Zazwyczaj dużo się mówi o pierwszych fazach a potem jakby zapomina o tym, że produkt żyje i musi ulegać zmianom. Stąd też faza konserwacji obejmuje zmiany w implementacji, projekcie, specyfikacji, a nawet wymaganiach. Czy można w jednej fazie objąć wszystkie wcześniejsze fazy. Moim zadaniem nie, ale w fazie konserwacji można wyznaczyć moment w którym podejmujemy decyzję o zmianie naszego produktu a to oznacza, że wszystkie fazy począwszy od wymagań (które mogą zmienić się minimalnie) zaczyna się od nowa.
Na moim blogu też nastąpił taki moment i dziś właśnie zakończyły się zmiany. Dotyczyły one nie tylko wyglądu (ujednolicenie kolorystyki), ale także strona została przeniesiona na nowy bardziej wydajny serwer. Przy okazji zmiany wyglądu strony dostosowałem ją do Google Chrome i Internet Explorera 8. Fani mobilnych urządzeń też powinni być zadowoleni bo strona jest dostępna, w specjalnym szablonie bez grafik (przepraszam za jakość zdjęcia), dla przeglądarek o mniejszej rozdzielczości działających na małych ekranach.
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
