Czy można pokazać więcej?

Zanim spróbuję odpowiedzieć na pytanie postawione w tytule. Kilka słów komentarza. Przyjęcie pewnych założeń – np. mamy system ERP – powoduje inne spojrzenie na prowadzoną analizę i nie pozwala w pewnych sytuacjach na znalezienie najlepszego rozwiązania, czy może zaprezentowania jak najlepiej efektu, który chcielibyśmy osiągnąć. Może aktualne mechanizmy zastosowane w systemie ERP są niewystarczające, co może być skutkiem ubocznym prowadzonej analizy. Tzw. dostosowywanie się do istniejących narzędzi powoduje, że w jakiś sposób dostosowujemy nasze myślenie, czy docelowy obraz procesów do już znanych mechanizmów. Nie pozwala na spojrzenie szersze, czy nawet wzbudzenie inicjatywy ze strony osób zaangażowanych w projekt. Mało tego czasami zdarza się, że koszty dostosowania się do istniejącego systemu są tak duże, że sam pomysł realizacji usprawnienia czy zmiany przestaje być korzystny albo nie jest wykonalny w akceptowalnym czasie. Zależności między wymaganiami/jakością, czasem realizacji oraz budżetem to już inna kwestia, nad którą nie chciałbym się teraz rozwodzić…

Tymczasem mała dygresja z innego podwórka. W bankowości bardzo często budując strategię sprzedaży staje się przed wyborem: elastyczne procesy i produkty czy standaryzacja produktów. Wydaje się może, że nie jest to kwestia powiązania, ale jak się przyjrzeć bliżej… Opis wymagań abstrahujący od sposobu wykonania, czy ograniczeń na pewnym etapie działania może przynieść w ostateczności bardziej elastyczne rozwiązanie. Stosowanie gotowego rozwiązania i trzymanie się cały czas jego wymagań jest to jakby trzymanie się/powielanie standardów postępowania. Wszystko zależy od tego, co chcemy osiągnąć.

Spójrzmy na poniższy diagram (zamieszczony na stronie it-consulting.pl/blog we wpisie „Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny”):

 

Diagram powstał jako odpowiedź na mój diagram z wpisu o „Reinżynierii” diagramu klas. Zgadzam się z komentarzem, że mój diagram jest pewnym modelem pojęciowym. Pokazuje jednak pewne zależności między elementami i zatrzymuje się na pewnym etapie ogólności pozwalającym na dyskusję: jakie informacje są potrzebne o produktach? w jaki sposób obsłużyć płatność? czego brakuje? który element jest wykorzystywany przez użytkownika, a co dzieje się automatycznie? Itd. W kolejnych iteracjach mogły zostać dodane kolejne elementy. Zaletą moim zdaniem jest to, że abstrahuje od rozwiązania informatycznego, pokazując pewne informacje logiczne. Wadą jest to, że brakuje wstępnego opisu przypadków użycia, aby przybliżyć dziedzinę. We wpisie o dynamice próbowałem pokazać pewne zachowania, które mogą nastąpić, schodząc na niższy poziom analizy.

Na wcześniejszym diagramie  brakuje mi przestawienia tego w jaki sposób wybierane są produkty i spośród jakich produktów są wybierane. Z doświadczenia wiem, że taka informacja na etapie prezentacji analizy jest cenną informacją. W przypadku nowej aplikacji internetowej pokazuje potencjalny zakres wykorzystywanych źródeł informacji. W przypadku istniejącej aplikacji pokazuje jakie informacje będą potencjalnie wykorzystywane w interakcji z użytkownikiem. Trzymając się zaproponowanego rozwiązania możemy to pokazać jak na poniższym diagramie.

Na diagramie zostały pozostawione operacje tylko z „Zarządcy”. Dodane jednak zostały, trzymając się metody „Role, odpowiedzialność, współpraca”, z zastosowaniem wzorca „Tablica”:

• tzw. „źródła wiedzy” („Promocje”, „Inni kupowali”, „Wcześniej zakupione”);
• tzw. „tablica” („Baza produktów”);
• tzw. „sterownik” („Wyszukiwarka produktów”);

Można by pójść dalej, analizując różne statusy zamówienia i skutki dla systemu, użytkownika. Podobnie można się zastanowić, czy „tablicy” nie zastąpić przez dostawcę usług („interfejs do ERP”).

Podsumowując, myślę, że odpowiedź na pytanie zawarte w tytule jest twierdząca. Stosując zaproponowane metody można pokazać więcej, w szczególności trzymając się pewnego poziomu uogólnienia.

Reklama

Dynamika – szczegółowość opisu

Trochę zainspirowany komentarzem do jednego z poprzednich wpisów, prowadzącym do artykułu „Diagram klas – czyli „reinżynieria” analizy biznesowej” (z it-consulting.pl/blog), a trochę w wyniku krystalizacji pomysłu na kolejny wpis, postanowiłem spojrzeć na diagram klas z poprzedniego wpisu w sposób bardziej dynamiczny. Jest to o tyle ważne, że sposób prezentacji diagramu klas i wykorzystane konstrukcje wpływają później na sposób implementacji takiego rozwiązania, przedstawiającego w bardziej lub mniej szczegółowy wymagania użytkownika. Chciałbym się skupić na elemencie „Zamówienia” wraz z operacjami wykonywanymi na nim.

Zastanówmy się najpierw czego oczekuje użytkownik systemu do składania zamówień od tego elementu. Odpowiedź nasuwa się sama, chce zaspokoić, w szczególności, dwie swoje potrzeby:

• potrzebę dodania produktu do zamówienia oraz
• potrzebę (ewentualnego) usunięcia produktu z zamówienia

Po prostu wyszukuje produkt i dodaje go do zamówienia, bądź wchodzi do „zamówienia” (listy dodanych produktów) i usuwa dany produkt. Świadomie nie wpisałem powyżej zmiany ilości, ponieważ tak naprawdę zwiększenie/zmniejszenie ilości produktu można zinterpretować jako dodanie/usunięcie produktu. Zostańmy jednak przy operacjach dodaj/usuń.

Użytkownik wybiera daną opcję i nie interesuje go co się dzieje wewnątrz systemu. Poniższy diagram w notacji BPMN jest próbą zaprezentowania tego, co mogłoby się dziać.

Diagram obrazuje, że system może kilka różnych czynności wykonać po wybraniu opcji przez użytkownika. Kilka kwestii wymaga jednak komentarza. Na poziomie Klienta zostały przedstawione operacje na najwyższym poziomie tożsame wręcz przyciskom w systemie. Natomiast na poziomie Systemu pojawiają się operacje wskazane na diagramie klas. Użytkownik dodaje produkt do zamówienia, określając jego ilość, a system tworzy pozycję na zamówieniu, dla danego produktu wraz z odpowiednią ilością. Pozycje zamówienia w tym wypadku nie są współdzielone (zastosowano kompozycję).

Można byłoby dalej dodać mechanizmy zabezpieczające przed dodaniem większej ilości produktu niż jest dostępna. Można także określić operacje proklienckie.  Wraz z kolejnymi zamówieniami sytuacja klienta w systemie oraz określonych produktów w pewnym sensie się zmienia. Zwiększając precyzję opisu wymagań można wskazywać kolejne ograniczenia czy też możliwości.

Rozbudowa opisu może przejść od typowej „narracji” (przykład w poprzednim wpisie), przez konkretne „scenariusze” (repezentowane przez tabele, diagramy) po „komunikację” (między elementami, wymianę komunikatami, co częściowo zostało pokazane w niniejszym wpisie).

Diagram klas – „reinżynieria” (etap 2)

Kolejnym etapem tworzenia diagramu klas, przedstawionego w poprzednim wpisie (Diagram klas – reinżynieria (etap 1)) jest uzupełnienie go o atrybuty oraz metody. Poniższy diagram zawiera takie przykładowe uzupełnienie:

Diagram klas – „reinżynieria” (etap 1)

Wcześniej zostały zaprezentowane dwa diagramy klas (pierwszy i drugi), które prezentowały w różny sposób, mniej lub bardziej poprawny, pewną dziedzinę. Na diagramach zostały wskazane metody, atrybuty oraz zostały opisane związki. Po dyskusjach na wcześniej wspomnianym forum, przemyślałem propozycje i postanowiłem, że stworzenie tego diagramu klas to będzie dobry przykład podejścia o charakterze reengineeringu lub benchmarkingu, zależy jak na to spojrzeć. Zacznę od początku, a to jest cecha bliska reengineeringu. Zastosuję wskazówki, wnioski z dyskusji, porównania się z doświadczeniami innych, co przypomina benchmarking (o różnicy między tymi dwoma podejściami, w zakresie procesów, postaram się napisać w kolejnym wpisie).

Kilka słów o tym, co chciałbym przedstawić:

• mamy klienta (klientów), który składa zamówienia on-line u dostawcy pewnych produktów,
• u dostawcy dostępne jest wiele produktów, o różnych cenach, parametrach, wadze itp.,
• zamówienie może się składać z od jednego do wielu produktów,
• za zamówienie klient może dokonać płatności na 3 różne sposoby: kartą kredytową, przelewem lub gotówką.

Mamy więc: Klienta, Zamówienie, Produkt oraz Płatność, co na diagramie można przedstawić następująco:

Reinżynieria procesów – modne sformułowanie?

Często można przeczytać, że ktoś przeprowadza, albo zajmuje się reinżynierią procesów biznesowych. Warto jednak zadań pytanie, co to jest w ogóle ta reinżynieria. Sformułowanie wzięło się angielskiego – Business Process Reegineering, w skrócie BPR. Jest to metoda restrukturyzacji działalności przedsiębiorstwa, a dokładniej przeprojektowywania jej procesów. To przeprojektowywanie może być rozumiane zarówno jako wymyślenie nowej postaci procesu, jego racjonalizacja lub też porzucenie – takie wytłumaczenie można znaleźć w literaturze dotyczącej szeroko pojętej dziedziny modelowania i przeprojektowywania procesów – Abramowicz, W. (red), Reorganizacja procesów biznesowych. Business Information Systems ’97.

Jakkolwiek się spróbuje zinterpretować reinżynierię procesów biznesowych, zawsze można wrócić do źródła tego pojęcia i definicji. Metoda ta pojawiła się na początku lat 90-tych, wraz z ukazaniem się publikacji J. Champy’ego i M. Hammera „Reegineering the Corporation”. W publikacji tej podana metoda ta jest rozumiana jako „fundamentalne przemyślenie od nowa i radykalne przeprojektowanie procesów w firmie, prowadzące w sposób dramatyczny do przełomowej poprawy według współczesnych, krytycznych miar jak: koszt, jakość, serwis i szybkość” (zgodnie z tłumaczeniem z książki: Kupczyk, A., Korolewska –Mróz, H., Czerwonka, M. Radykalne zmiany w firmie. Od reengineeringu do organizacji uczącej się.).

Zgodnie z zasadami reengineeringu, proces zmian obejmuje firmę całościowo, począwszy od jej strategii, wartości wewnątrzorganizacyjnych po działalność, możliwości, uprawnienia pojedynczego pracownika. Odbywa się to na wielu płaszczyznach. Jednak trzeba zaznaczyć, że podstawą jest proces. Każde usprawnienie, zmiana pozwala na poprawę, zmianę jednej z miar krytycznych dla firmy.