Bardzo często spotykam się z ogromną złożonością (liczba i ich podziały) wymagań. Problem tkwi nie raz w tym, że „narosła” przez lata „sterta zarządzeń”, która zamiast zostać najpierw uporządkowana, jest „wprost” traktowana jako „wymagania”. Takie podejście to krok w stronę klęski projektu.
W „wymaganiach” często pojawia się coś co nazywamy „warunkiem logicznym”, może on być zarówno regułą biznesową, elementem prawa (rodzaj reguły ale z poza organizacji) jak i elementem dziedziny systemu (np. człowiek może podnieść tylko 20 kg).
W efekcie często powstają dziesiątki 'bardzo istotnych” szczegółów, które nie powiązane ze sobą, tworzą papkę wymagań, których implementacja albo wymaga uproszczeń (brak definiowalnej logiki pomiędzy tymi wymaganiami) albo wręcz wymaga rezygnacji z części z nich (a mogą być faktycznie ważne dla firmy). Nieuporządkowane reguły takie trwają w firmach, bo człowiek ma naturalną zdolność do radzenia sobie z, nie raz sprzecznymi, ograniczeniami w swojej pracy: dokonuje wyboru ad-hoc a rozliczany jest z efektów nie reguł. Czegoś takiego nie da się zaimplementować w oprogramowaniu.
Przykład dość typowy: w wielu różnych miejscach organizacji istnieją ograniczenia maksymalnej kwoty kosztu o jakim może zdecydować osoba na określonym stanowisku. Są to nie raz progi ustalane indywidualnie (latami) dla konkretnych typów kosztów, konkretnych stanowisk itp. Nie raz są ich nawet dziesiątki a ich wysokość jest różna, ustalana pod wpływem szkody, która była przyczyną ich ustalenia lub żądań danego menedżera. Takich „reguł” w dużej organizacji mogą być nie raz nawet setki. Są to pary w rodzaju „Dyrektor XXX w przypadku dokumentu typu YYY powyżej kwoty ZZZ musi…..”. „Reguły” takie warto przeanalizować i zamienić np. na kilka (albo i jedną!): każdy dyrektor średniego szczebla musi …. jeżeli koszt jaki wygeneruje jego decyzja przekroczy kwotę ZZZ. Ustala się jedną kwotę dla konkretnego szczebla menedżerów (wszystkich). Tu często pojawia się opór tych „menedżerów”, bo ciężko latami walczyli o swoje „kompetencje”. Niestety dla wielu menedżerów próg ich decyzji finansowych oznacza ich kompetencje i władze (a szkoda, że nie ich wiedza i umiejętności).
Podczas wdrożeń, np. systemów ERP, tego typu „reguły” (ich liczba i brak logiki) stanowią nie raz zmorę projektu a bywa, że potrafią taki projekt zabić. A ja tylko opisałem jedną z typów reguł, których są dziesiątki, a z opisanymi „wariantami”, w dużej firmie, nawet tysiące…
Procesy biznesowe są konsekwencją między innymi reguł biznesowych. Większość zarządów firm nie ma na półkach regałów map procesów, a firmy działają. Jednak każda firma ma zarządzenia Zarządu i to one tak na prawdę kształtują „procesy biznesowe”. Podobnie jak np. w muzeach: mamy duże sale i wiele możliwości przejść przez nie. Co decyduje o tym, jaką drogę przejdziemy przez sale pełne eksponatów? Linia na podłodze? Nie! Barierki! Czym one są? To ograniczenia! Zarządzenia Zarządu stwarzają ograniczenia, ich konsekwencją są takie a nie inne procesy biznesowe. Dlatego zrozumienie i uporządkowanie reguł biznesowych jest ważne, a nie modelowanie procesów. Te są ich skutkiem. Modelowanie procesów to odkrywanie ścieżek wyznaczonych ograniczeniami. Jeżeli jednak pozwolimy utrzymać opisany bałagan to modele procesów biznesowych (ścieżki postępowania) przybiorą postać zawartości monstrualnego talerza spaghetti.
A tak na prawdę polecam wystawę w Zamku Królewskim (Warszawa): Polska za czasów Jagiellonów oraz drugą: Historia krzyża Maltańskiego. Powody są dwa: to co można zobaczyć na ścianach czyli eksponaty oraz to w jaki sposób ten sam Zamek Królewski, tylko z sprawą barierek, można zmieniać w trasy dla zwiedzających nie naruszając samego Zamku.
Podpisuję się pod tym wpisem rękami i nogami.
Jestem członkiem zespołu, który tworzy oprogramowanie na potrzeby wewnętrzne organizacji i rzadko korzystamy z rozwiązań zewnętrznych. Liczba reguł jakie narosły w trakcie działania organizacji jest ogromna i próba ich uproszczenia trafia na ogromny opór. Skutkiem tego jest oprogramowanie które jest strasznie skomplikowane i posiada wiele czasem nawet nachodzących na siebie procesów. Nasz zespół widzi te problemy, ale mamy mały wpływ na decyzje naszych szefów.
może warto im to „uzmysłowić” 🙂 czyli pokazać skutki… Warto także 'lobbować’ za wydzieleniem (wstawieniem) etapu analizy wymagań i zarządzania nimi, pomiędzy „biznes” a development.
Niestety pokutuje tutaj stara zasada, że użytkownik dostaje to o czym mówił, ale nie to co chciał. Nie potrafi zdefiniować wymagań, no chyba, że to my zadajemy złe pytania 😉 Prawdę mówiąc więcej nasz zespół bazuje na własnych obserwacjach niż wymaganiach użytkownika. To jednak nie jest dobra droga, gdyż często zdarza się, że nasze przemyślenia nie są w 100% celne.
To niestety częste zjawisko, większość projektów to „komputeryzowanie bałaganu zamawiającego” z czego mało która firma (Zamawiający) sobie zdaje sprawę… W zasadzie przystąpienie do specyfikowania wymagań bez wcześniejszego upewnienia się, że logika działania firmy jest „uporządkowana”, prawie zawsze kończy się projektem który zawsze trwa dłużej i kosztuje więcej niś planowano…
Coraz bardziej widzę olbrzymie zalety stosowania reguł biznesowych, jednak ich „układanie”( po za przyporządkowaniem do konkretnego procesu bądź jego czynności) jest trudne. Nie udało mi się znaleźć innych sposobów podziału reguł biznesowych . Czy Pan jest w stanie wskazać takie metody ?
Robię to równolegle z analizą dokumentów operacyjnych i modelowaniem procesów, one powstają niejako równolegle. W panowaniu nad tym bardzo pomaga mi oprogramowanie Agilian (pakiet firmy Visual-Paradigm) oraz wbudowane narzędzia do analizy faktów i budowania reguł (w tym katalogowanie i testowanie). polecam stosowanie tak zwanego diagramu faktów do identyfikowania reguł biznesowych.
Diagram faktów i reguły biznesowe
Super artykuł. Niestety to problem również w wielu moich projektach a czytając – jakbym widział swoich klientów miksujących wymagania z procesami, procesy z regułami etc. Również brakuje mi „narzędzia”, w celu ogarnięcia całej masy tych reguł i będę musiał się uważniej przyjrzeć VP. Zgłoszę się na szkolenie 😉
Tymczasem, Szczęśliwego Nowego Roku!
Pozdrawiam,
RF
Także pozdrawiam. W nowym roku życzę sukcesów i … zapraszam na szkolenie 🙂
Również używam narzędzi Visual Paradigm do pracy z regułami biznesowymi i nie tylko. Diagram faktów jako taki nie definiuje reguł biznesowych – jest on za to dobrym źródłem do ich identyfikacji oraz weryfikacji. Narzędzia VP umożliwią zdefiniowanie reguł biznesowych na każdym rodzaju diagramu, jednak w praktyce identyfikuje się je głównie w dyscyplinie modelowania działalności organizacji (podczas modelowania słownika organizacji, jej struktury organizacyjnej oraz procesów biznesowych).
Trzymanie się mocno standardu SBVR oraz podejścia RuleSpeak przy definiowaniu reguł biznesowych łatwo prowadzi do powstania setek a czasami nawet tysięcy reguł. Jak słusznie autor zauważył – umiejętne zdefiniowanie reguł pozwała ograniczyć ich liczbę jednak to nie wszystko. W sytuacji kiedy dalej zmagamy się z ogromną liczbą reguł z pomocą może przyjść model tabel decyzyjnych – Table Decision Model, który uważam, że znakomicie pozwala zapanować nad złożonością reguł przenosząc ciężar zarządzania nimi na zarządzanie decyzjami biznesowymi, a nie elementarnymi regułami (co jest naturalne dla biznesu). Narzędzia VP swojego czasu wspierały ten model, ale autor TDM wprowadził na niego licencję, stąd wsparcie zostało wycofane. Dobrą wiadomością jest to, że OMG pracuje nad standardem TDM i już w połowie roku powinniśmy się doczekać jakiejś jego wersji.
Osobiście traktuje diagram faktów jako weryfikacje słownika. Z ilością reguł radzę sobie tak, że definiuje wyłącznie te zidentyfikowane w procedurach i na procesach, to pomaga.
Polecam również ciekawy artykuł na witrynie ModernAnalyst porównujący tradycyjne podejście do zarządzania regułami biznesowymi i TDM: We Already Have a BRMS, What are We Missing?
To bardzo ciekawy artykuł, pozwoliłem sobie podlinkować 🙂
Ja wciąż szukam sensownego sposobu opisu reguł biznesowych. Reguły biznesowe sterują przecież przepływem procesu oraz pojedynczymi zadaniami – jak je spójnie opisywać?
Tu, tak sądzę, należy zdefiniować co jest tą regułą. Osobiście praktykuję podejście polegające na kojarzeniu „zasad” z obiektem, którego zasady dotyczą: zasady specyficzne dla roli/stanowiska z ta rolą i te lądują w zakresach obowiązków ludzi. Zasady specyficzne dla „obiektów biznesowych” kojarzę z tym obiektami (lądują potem w kodzie). Pozostałe to zasady „ogólnokorporacyjne” i te nazywam „reguła biznesową” bo dotyczy „całego biznesu”, z tego co czytam to podobną metodę zaleca Ron Rose, jednak on więcej „pakuje” do „biznesu” , osiąga wyniki nawet setek reguł biznesowych w dokumentacji, chyba dlatego, że zalicza do niech także te, które ja kojarzę z zakresami obowiązków. Moje podejście pozwala „hermetyzować” odpowiedzialność za „zasady” już na poziomach średnich szczebli zarządzania. Nie wyobrażam sobie skutecznego (rozsądna pracochłonność) zarządzania setkami reguł biznesowych, nawet posiadając jakieś narzędzie do tego.
A tak przy okazji: tu doskonały przykład budowy reguł biznesowych:
http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471