Od czasu do czasu spotykam się z zaskoczeniem, gdy mówię, że pewne słowa kluczowe w specyfikacjach są „standaryzowane”. Otóż specyfikacje notacji na OMG.org mają narzucone pewne słownictwo. Przykładem niech będzie specyfikacja notacji BPMN v.2.0.2, zawiera ona taki oto rozdział :
3.2 Normative OMG UML ? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 - (jest już UML 2.5.) OMG MOF ? Object Management Group – Meta Object Facility (MOF) Core Specification, V2.0 http://www.omg.org/spec/MOF/2.0 RFC-2119 ? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119, March 1997 http://www.ietf.org/rfc/rfc2119.txt
Oznacza to, że do poprawnej interpretacji specyfikacji notacji należy znać specyfikacje: MOF, UML oraz także RFC-2119. O MOF i UML pisałem nie raz, dzisiaj kilka słów o tej ostatniej.
Jest to dokument opisujący rekomendowany sposób formułowania wymagań (np. w stosunku do elementów diagramu i ich użycia). Wymagania są tu rozumiane szeroko, jako sformułowania normatywne. „Słowa kluczowe do wykorzystania, w RFC do wskazania poziomów wymagań” to słowa i zwroty o tu ustalonym znaczeniu :
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.?(?Key words for use in RFCs to Indicate Requirement Levels,? 1997)?
Wymienione słowa kluczowe odnoszą się do formułowania reguł (przy stosowaniu określonych zasad będących wymaganiami) i oznaczają:
MUSI (oryg. MUST) oznacza, że to zachowanie (określona reguła, wymaganie) jest absolutnym wymogiem, alternatywnie: WYMAGA SIĘ, NALEŻY
NIE MOŻE (oryg. MUST NOT) oznacza, że określone zachowanie jest absolutnie zakazane, alternatywnie: NIE NALEŻY
POWINIEN (oryg. SCHOULD) oznacza, że określone zachowanie jest rekomendowane, a więc jedynie w ściśle określonych okolicznościach, jeżeli istnieją określone powody, określone zachowanie może być pominięte, alternatywnie: REKOMENDUJE SIĘ,
NIE POWINIEN (oryg. SHOULD NOT) oznacza, że pewne zachowania odradza się (rekomenduje się nie wykonywać określonego zachowania), a więc zachowanie to jest dopuszczalne jedynie w określonych okolicznościach, alternatywnie: ODRADZA SIĘ, NIE REKOMENDUJE SIĘ,
MOŻE (oryg. MAY) oznacza, że określone zachowanie jest opcjonalne, a więc skutki tego realizacji lub pomięcia określonego zachowania są całkowicie neutralne, alternatywnie: OPCJONALNIE
Powyższe odnosi się do wszelkich wymagań, do decyzji o zastosowaniu czegoś (np. określonej konstrukcji w danej notacji). Pod pojęciem „zachowania (się)” rozumiemy interpretację zapisów np. o stosowaniu lub wymaganiu czegoś lub nie.
Biorąc pod uwagę fakt, że definicje pojęć to klasyfikatory i stanowią one sobą reguły (coś jest lub nie jest czymś) słowa te stanowią także bazowy element składni treści reguł biznesowych (elementy predykatów), np. „kierowca NIE MOŻE przekraczać dozwolonej prędkości”, „kierowca POWINIEN zachować bezpieczną odległość od poprzedzającego go pojazdu”, „kierowca MOŻE przewozić pasażerów”, a ogólnie rzecz biorąc „kierowca MUSI przestrzegać zasad Kodeksu Drogowego”, a ten to nic innego jak właśnie zbiór reguł.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Dwa miesiące temu pisałem o zarządzaniu z perspektywy tworzenia reguł biznesowych:
Dzisiaj o zarządzaniu zorientowanym na reguły biznesowe. Temat, z którym pierwszy raz zetknąłem się jakieś 15 lat temu w jednym z wydawnictw Harvard Business Review. Nie będę tu streszczał tego tekstu (pewnie nawet nie mogę ;)), generalnie przesłanie brzmiało:organizacją można zarządzać tworząc reguły a nie wydając polecenia przy każdym zdarzeniu. (Źródło: Reguły biznesowe i polityki jako mechanizm działania organizacji | | Jarosław Żeliński IT-Consulting)
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Cztery lata temu, pisałem o regułach biznesowych jako elemencie modelu biznesowego i ich roli w zarządzaniu:
Na czym więc polega skuteczne zarządzanie? Na zrozumieniu, posiadaniu planu działania i przemyślanym tworzeniu ograniczeń.Robi tak każda większa firma: powstają zakresy obowiązków, wewnętrzne zarządzenia i procedury. To wszystko to nic innego jak ograniczenia.Opracowanie modelu organizacji więc, to nie tylko opisanie procesów bo te są jedynie efektem istniejących ograniczeń. Pełny model organizacji, dający zrozumienie tego jak ona działa, to kompletny model pojęciowy ? nazwy i definicje podstawowych pojęć opisujących jej działanie (co to jest klient, produkt, kontrahent, ?), specyfikacja wszelkich ograniczeń czyli reguł biznesowych oraz specyfikacji stanowisk i wymaganych na każdym z nich umiejętności (pamiętamy, że ograniczeniem jest także obowiązujące prawo). (Źródło: Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć | Jarosław Żeliński IT-Consulting)
Dzisiaj o zarządzaniu zorientowanym na reguły biznesowe. Temat, z którym pierwszy raz zetknąłem się jakieś 15 lat temu w jednym z wydawnictw Harvard Business Review. Nie będę tu streszczał tego tekstu (pewnie nawet nie mogę ;)), generalnie przesłanie brzmiało:
organizacją można zarządzać tworząc reguły a nie wydając polecenia przy każdym zdarzeniu.
Artykuł 2. [reguły biznesowe] Oddzielone od procesów, a nie zawierające się w nich 2.1. Reguły są bezpośrednimi ograniczeniami narzuconymi na funkcjonowanie organizacji jak również mogą stanowić wsparcie dla jej funkcjonowania. 2.2. Reguły nie są procesami ani procedurami. Nie powinny być w nich zawarte. 2.3. Reguły mają zastosowanie ponad i pomiędzy procesami i procedurami. Powinny stanowić jeden spójny organizm, stosowany konsekwentnie w odpowiednich obszarach aktywności biznesowej. Artykuł 3. Świadomie rozwijana dziedzina wiedzy, nie produkt uboczny 3.1. Reguły budowane są na faktach, a fakty budowane są na koncepcjach wyrażonych poprzez terminy [błąd tłumaczenia, zamaist „koncepcjach” powinno być „pojęciach wyrażonych odpowiednimi słowami”]. 3.2. Terminy wyrażają koncepcje biznesowe [tu niestety także mamy błąd tłumaczenia, chodzi pojęcia biznesowe a nie „koncepcje”, w oryginale jest słowo „concept”]; fakty dostarczają stwierdzeń odnośnie tych koncepcji, reguły ograniczają oraz wzbogacają te fakty. 3.3. Reguły muszą być wyrażone explicite. Reguły nie stanowią domniemań odnośnie koncepcji, czy faktów. 3.4. Reguły stanowią podstawę tego, co biznes wie o sobie ? to znaczy, podstawę wiedzy biznesowej. Artykuł 4. Deklaratywne, nie imperatywne 4.1. Reguły powinny być wyrażane deklaratywnie w formie zdań w języku naturalnym dla docelowego odbiorcy biznesowego. 4.2. Jeżeli coś nie może być wyrażone, nie jest regułą. 4.3. Zbiór wyrażeń uznaje się za deklaratywny, gdy wyrażenia w zbiorze nie zależne od jakiegokolwiek uporządkowania. 4.4. Dowolne wyrażenie dotyczące reguł, które wymaga konstrukcji różnych od pojęć i faktów implikuje założenia odnośnie systemowej implementacji. 4.5. Reguła jest różna od jakiegokolwiek zastosowania dla niej zdefiniowanego. Reguła oraz jej zastosowanie powinny być rozważane oddzielnie. 4.6. Reguły powinny być definiowane niezależnie od tego kto, gdzie, kiedy i jak je zastosuje. 4.7. Wyjątki od reguł są wyrażane innymi regułami. 5.3. Logiki formalne, takie jak logika predykatów, są fundamentem dobrze wyrażonych reguł, wykorzystujących terminy biznesowe oraz technologii implementujących reguły. Artykuł 10. Zarządzanie logiką biznesu, nie platformami informatycznymi 10.1. Reguły biznesowe są wartościowym zasobem biznesowym. 10.2. W perspektywie długoterminowej, reguły są dużo ważniejsze dla biznesu od platform sprzętowych i programowych. 10.3. Reguły biznesowe powinny być organizowane i przechowywane w sposób umożliwiający ich późniejsze łatwe osadzenie na nowych platformach programowych i sprzętowych. 10.4. Reguły oraz możliwość efektywnego zarządzania ich zmianami są podstawą do usprawnienia zdolności organizacji do adaptacji do nowych warunków.
Warto zwrócić uwagę na kluczowe dla zarządzania organizacją i kluczowe dla tworzenia modeli biznesowych elementy:
Reguły biznesowe to ograniczenia zachowań (pożądane, dopuszczalne i niedopuszczalne fakty).
Reguły nie są ani procesami ani procedurami.
Reguły budowane są w oparciu o fakty.
Reguły wyrażane są zdaniami w języku naturalnym (muszą być zrozumiałe dla ich wykonawców).
Reguły są od siebie niezależne (nie ma znaczenia kolejność ich użycia).
Wyjątki są także regułami (tu niestety należy wystrzegać się bardzo głupiego przysłowia o „wyjątku potwierdzającym regułę”)
Zarządzanie zorientowane na reguły
Generalnie reguły biznesowe wyznaczają pożądane zachowania (coś nakazują, czegoś zakazują). W firmach są zawarte (ukryte) w regulaminach, statutach, zakresach obowiązków, bieżących zarządzeniach, innych dokumentach o podobnych charakterze. Wyzwaniem jest ich zebranie i uporządkowanie, gdyż to one tak na prawdę stanowią LOGIKĘ BIZNESOWĄ danej organizacji. Reguł tych w organizacji mogę być nie raz setki, dlatego bardzo ważne jest ich porządkowanie. W notacji BMM mamy dwa pojęcia z tym związane: polityka i reguła biznesowa. Polityka to nic innego jak określony kontekstowo zbiór reguł biznesowych (np. Polityka Bezpieczeństwa), tak więc reguły biznesowe grupujemy w tak zwane Polityki. Np. w ramach tworzenia Polityki Obsługi Klientów, można stworzyć regułę biznesową:
AKME Sp. z o.o.udziela odpowiedzi na każde otrzymanepismonie zaklasyfikowane jakospam.
Kursywą zaznaczono nazwę własną nie wymagającą definicji. Podkreśleniem oznaczono fakty, pogrubieniem oznaczono pojęcia w słowniku (predykaty). Określenie „każde” jest funkcją zdaniową. Jak widać np. słowo spam jest pewnym klasyfikatorem, definicja tego pojęcia powinna być w słowniku, będzie narzędziem odróżniania (klasyfikacji) pism wartościowych od bezwartościowych. Definicja pojęcia to atrybuty pozwalające uznać dane „coś” za przynależne do tego pojęcia, np. spam to „każdy list mający mający w polu nadawca wartość „reklamy.pl” (definicja pojęcia może być długą listą wartości atrybutów – cech). Definicja pojęcia to cechy jakie musi spełnić coś by zostało uznane za „to”. Reguły biznesowe to sądy czyli logiczne dania, pojęcia połączone faktami. Sądem jest także uznanie czegoś za zgodne z definicją (że ma określone cechy). Przypominam, że reguła biznesowa opisuje zachowania a nie pojęcia, te są tu jedynie narzędziem opisu rzeczywistości dla tego zdarzenia.
Tak więc zamiast brać na siebie, jako prezes firmy, menedżer średniego szczebla itd. ogrom zdarzeń w postaci podejmowania decyzji za każdym razem, gdy jest taka wymagana, można stworzyć system polityk, zestawów reguł biznesowych, skutkiem czego firma będzie sprawnie funkcjonowała nie angażując, nawet do bardzo trywialnych zadań, wysokich rangą pracowników. Nie jest to delegowanie uprawnień, polityki i reguły biznesowe to rodzaj z góry podjętych decyzji. Owszem żadnej firmy nie da się zalgorytmizować, dlatego zawsze wyższe kadry będą potrzebne jednak ich kluczową rolą jest ustalanie zasad i zarządzanie nimi a bezpośrednie reagowanie powinno dotyczyć tego „niezalgorytmizowanego” zakresu zdarzeń (op. 20% :), reguła Pareto).
Zarządzanie zorientowane na reguły biznesowe to właśnie takie podejście: to czego można się spodziewać, opisujemy regułami, zdarzenia wyjątkowe obsługujemy osobiście. Reguły biznesowe warto zebrać w jedno miejsce, „wyjąć” je z przerośniętych opisów zakresów obowiązków i kompetencji, uporządkować zarządzenia zarządu.
Tu ktoś może powiedzieć, że mało która firma taki „porządek” ma i mimo to całkiem sprawnie one funkcjonują, i będzie miała rację. Ludzie doskonale sobie radzą z niejednoznacznością i zaskakującymi zdarzeniami. problem pojawia się, gdy trzeba spisać wymagania na oprogramowanie, i pojawi się rozdział o nazwie „Logika biznesowa”. Tu niestety albo pojawi się spójny opis jednoznacznych reguł, albo
wdrożenie czekają potężne kłopoty bo żadne oprogramowanie nie poradzi sobie z niejednoznacznością.
Procesy biznesowe
O nich napisałem wiele, tu tylko skupię się na jednym: 2.2. Reguły nie są procesami ani procedurami. Nie powinny być w nich zawarte (Manifest). To kluczowa teza w modelowaniu procesów. Innymi słowy, przytoczonej reguły:
AKME Sp. z o.o.udziela odpowiedzi na każde otrzymanepismonie zaklasyfikowane jakospam.
nie „rysujemy” na diagramie BPMN jako sekwencji kroków w rodzaju:
„weź pismo, sprawdź czy nie zawiera domeny reklamy.pl w adresie nadawcy, jeżeli tak to wyrzuć do kosza, jeżeli nie to opracuj odpowiedź”.
bo to prowadzi do masakrycznej złożoności diagramów. Po drugie w każdym procesie mającym „w sobie” zdarzenie związane z odpisaniem na pismo musielibyśmy „narysować” powyższy ciąg czynności. Zarządzanie zmianą w takiej dokumentacji to koszmar. Model procesu powinien zawierać wyłącznie elementarne procesy biznesowe (aktywności z ich wejściem i wyjściem):
Proces biznesowy w notacji BPMN z wydzielonymi procedurą i reguła biznesową.
Wtedy będzie to bardzo treściwy i zrozumiały diagram. Tworzenie monstrualnych, nafaszerowanych szczegółami diagramów praktycznie niczemu i nikomu nie służy. Modele zawierające wrysowane „obrazkowo” reguły biznesowe i procedury to niestety bardzo kosztowne i całkowicie nieprzydatne dokumenty. Jeżeli mają być „wsadem” do analizy wymagań są wręcz szkodliwe bo ukrywają sens logiki biznesowej w masie nadmiarowych szczegółów.
[przyp. 13.12.2015: bardzo ciekawie o „zaszumieniu modeli procesów” napisał Girish K C (Vice President, Process Reengineering and Implementation at HSBC) w artykule Reducing «Noise» in a Business Process]
Kilka słów o logice dla zainteresowanych
Ważnym elementem jest tu „niestety” pojęcie predykatu, które jest fundamentem tworzenia reguł biznesowych (patrz pkt 5.3 Manifestu). W zdaniu „Jarek Żeliński jest człowiekiem” pojęcie „człowiek” jest predykatem, słowo „jest” jest funkcją zdaniową, zaś „Jarek Żeliński” jej argumentem. Predykat jest (może być) także nazwą klasy (klasyfikator: desygnuje grupę bytów mających wspólne cechy, to zgodne z pojęciem klasy w UML, cecha także może być predykatem, podobnie jak atrybut klasy może być osobną klasą).
Możliwe są zdania z dwoma predykatami, np. „Każdy pracownik firmy XXX jest prawnikiem”. Mamy to dwa predykaty wymagające zdefiniowania w słowniku pojęć: „pracownik” i „prawnik”. Słowo „jest” to funkcja zdaniowa, słowo każdy to kwantyfikator.
To dlatego bardzo ważne jet tworzenie słownika pojęć biznesowych. Pojęcie to jest „to coś” o co nam w danym momencie chodzi, słowo takie jest desygnatem (nazwą tego czegoś), użycie słowa wskazuje, że „właśnie to pojęcie mam na myśli”. Jak widać kluczem jest tu model pojęciowy, czyli zbiór predykatów i ich znaczeń. Ważne jest także to, że poprawny model pojęciowy ma kontekst, tu biznesowy, dlatego definicje pojęć powinny być tworzone w tym kontekście np. definicja: człowiek to „osoba dorosła” zamiast ?istota żywa wyróżniająca się najwyższym stopniem rozwoju psychiki i życia społecznego? (sł. j.polskiego). Bardzo ważnym elementem jest tu także prawo „wyłączonego środka” w logice, wyrażone językiem naturalnym brzmi: „jeżeli coś jest czymś, to nie jest niczym innym”. Innymi słowy, jeżeli coś „pasuje” do określonej definicji pojęcia, nie może pasować do żadnej innej (jeżeli definicje są poprawnie zbudowane, tak się zresztą testuje, tu polecam specyfikację SBVR OMG (Semantics Of Business Vocabulary And Rules).
Jeżeli to zdanie jest tak zwanym sądem, to znaczy, że „prawdą jest, że Jarek Żeliński jest człowiekiem” (to zdanie zawiera jeden predykat i jeden argument). Sądy, dla ich tworzenia, muszą być oparta na obserwowalnych fatach (porównaj z Manifest pkt. 3.1.). Reguły biznesowe to właśnie tak zwane „sądy bazowe” opisujące daną organizację (jej zachowanie się). O sądach bazowych i ich budowaniu pisze [[Bertrand Russell]]:
B. Russell: Badania dotyczące znaczenia prawdy
To dlatego między innymi [[logika]] i [[epistemologia]] nie powinny być obce dobremu analitykowi.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Regularnie widuję monstrualne diagramy, na których ich autorzy usiłują modelować decyzje podejmowane w toku przepływu pracy. Pierwsze nieporozumienie (i duży błąd pojęciowy) na tych diagramach, to łączenie na jednym diagramie elementów procesu biznesowego, z tym jaka „praca myślowa” wykonawcy ma być w danym procesie (aktywności) wykonana. Drugi błąd to mieszanie poziomów abstrakcji: proces biznesowy to dość duży poziom ogólności (uogólnienia), jego celem jest pokazanie celowości łańcucha pracy (procesy biznesowe to aktywności tworzące produkty) a nie tego, jak jest w detalach wykonywana: wnętrze tych aktywności – ich szczegóły – na tym poziomie są nieistotne.
Tak więc osobna specyfikacja reguł biznesowych stanowi system reguł dla całej organizacji. Nie musimy dziesiątki razy nanosić na diagramy symboli wyjaśniających detalicznie, dla każdego procesu i roli, że np. faktura zakupowa o wartości przekraczającej 1000zł musi być dodatkowo zatwierdzona .. i tu ścieżka zatwierdzeń, bo takich sytuacji mogą być w większej firmie nawet setki. Wystarczy, że raz zdefiniujemy (lub pomagamy analizowanej firmie zdefiniować w toku analizy i pisania rekomendacji) regułę brzmiąca np. że „żaden pracownik średniego szczebla nie może samodzielnie zatwierdzać kosztów przekraczających dwukrotność jego wynagrodzenia netto”. Takiej regule w dokumentacji nadajemy identyfikator i nazwę, i powołujemy się na nią w modelu procesów. Skutek jest taki, że diagramy stają się prostsze, zaś zmiana tej reguły nie wymaga przeglądu wszystkich modeli i ich aktualizacji, wystarczy korekta w specyfikacji tych reguł. Dodatkowo, w przypadku pisania wymagań na oprogramowanie, wystarczy załączyć specyfikacje reguł biznesowych zamiast wypisywać nie raz setki tak zwanych „case’ów”.
Na pytanie klientów: ile pracy trzeba żeby utrzymywać aktualność opracowanych modeli procesów biznesowych? Odpowiadam: bardzo mało, wystarczy zarządzać regułami biznesowymi a te są w Zarządzaniach Zarządu.
Tablice decyzyjne są kolejnym narzędziem w modelowaniu organizacji, z jednej strony porządkującym wiedzę o niej, z drugiej upraszczającą diagramy modeli procesów. Diagramy przestają być tak zwanymi „spaghetti modelami”, a zaczynają być zwięzłymi, mieszczącymi się na stronie A4, diagramami modelującymi procesy biznesowe. Przykładem dość często spotykanego „boju ze złożonością” są procesy, w których pojawia się rabat. Widuję je na diagramach modelujących procesy (np. w notacji BPMN) jako monstrualne „drzewa decyzyjne” i niekończące się ścieżki opisujące przypadki, w których komuś należy się określony rabat. O tablicach pisałem już kilka razy, jednak tym razem chciałem zwrócić uwagę na pewną przypadłość bardzo wielu projektów: utrata panowania nad złożonością opisu (modelu) i „płynięcie” w tak zwany „case management”. Pierwsze to umieszczanie na diagramach wszelkich poznanych szczegółów wiedzy o danym procesie (mieszanie poziomów abstrakcji), drugi to opisywanie konkretnych przypadków zamiast poprzestać na zasadach (regułach) (do opisu, zamodelowania, gry w szachy należy spisać tylko reguły gry, a nie tworzyć opisu setek poznanych partii, gdzie i tak wszystkich możliwych nie opiszemy).
Zamiast opisywać skomplikowane „procesy decyzyjne” w postaci niemalże „algorytmizacji świata” (model procesu wygląda jak rozbudowane drzewo decyzyjne z dziesiątkami wariantów) , lepiej skupić się (i poprzestać) w modelu na tym, jakie decyzje są faktycznie podejmowane, i na „skutkach”, które mają znaczenie w procesie biznesowym.
Bardzo często mamy do czynienia z dziesiątkami możliwości, dużymi ilościami potencjalnych faktów, jednak „obsługiwane są” (mają znaczenie, reagujemy na) tylko niektóre z nich lub ich kombinacje. Jak już w innym artykule wspominałem: ilość możliwych kombinacji trzech kolorów sygnalizatora na krzyżowaniu jest większa niż kombinacje opisane (mające znaczenie) w Kodeksie Drogowym, kierowca reaguje na określoną kombinację, nie analizuje w myślach tego, jak mogą być ze sobą skojarzone poszczególne kolory i w jakiej kolejności się pojawiać – to zbyt absorbujące. Tak samo „działa” biznes: reagujemy na konkretne fakty lub ich kombinacje, pozostałe po prostu ignorujemy bo nie mają znaczenia, nie ma więc sensu zajmowanie się nimi i dokumentowanie ich (modelowanie).
Przypuśćmy, że nasi klienci są podzieleni na cztery grupy docelowe, a do tego każdy z nich, zależnie od historii obrotów, może być sklasyfikowany jak Platynowy, Złoty, Srebrny i Ołowiany (:)). I teraz załóżmy, że mamy promocję, ta jednak obejmuje wyłącznie klientów Srebrnych z segmentu 2, o ile mają siedziby w woj. Mazowieckim oraz klientów Ołowianych z segmentu 3 o ile mają siedzibę w woj. Podkarpackim. Innymi słowy, z pośród setek możliwych kombinacji obsługujemy wyłącznie dwie. Tworzenie diagramu w sposób: czy klient jest Platynowy? Nie, Czy jest Srebrny, Tak, Czy jest z województwa.…… prowadzi do mega diagramu. Zamiast tego tworzymy prostą tablicę decyzyjną, która zawiera wyłącznie obsługiwane w procesie pojedyncze fakty lub ich kombinacje (reguły) oraz przyporządkowane im akcje (działania w postaci konkretnego upustu), nic ponad to (resztę kombinacji po prostu ignorujemy, nie ma potrzeby ich opisywania). Takie decyzje są podejmowane w „jednym kroku”. Tak jak kierowca: reaguje natychmiast na określoną kombinację kolorów na sygnalizatorze, nie analizuje tego jakie inne w ogóle są możliwe. Gdyby ktoś z nas zobaczył na sygnalizatorze zapalone światło czerwone i zielone jednocześnie, raczej uzna to za awarię i zignoruje, niż zacznie analizować jak się to ma do innych możliwych kombinacji i co ma z tym począć (inny, bardziej „prawdziwy” przykład).
Modele procesów, w których złożone decyzje są modelowane z użyciem reguł biznesowych i tablic decyzyjnych, a nie z pomocą kaskad dziesiątków bramek decyzyjnych, są prostsze w zrozumieniu, kontrola ich spójności i poprawności jest znacznie łatwiejsza. Reguły biznesowe i tablice decyzyjne pozwalają na ich bezpośrednią implementację w aplikacjach, a same diagramy są znacznie łatwiejsze w czytaniu i aktualizacji. Ich złożoność nie zabija wzroku ;).
Tablice decyzyjne, jako narzędzie na etapie analizy, pozwalają także na bardzo łatwe wychwytywanie reguł nadmiarowych, sprzecznych i innych pozbawionych sensu.
Na koniec kilka obrazowych przykładów, które nawet dla osób słabo znających język angielski powinny być łatwe do zrozumienia.
Na zakończenie zaryzykuję tezę, że autor diagramu nie mieszczącego się na stronie A4, utracił panowanie na złożonością projektu.… i diagram płynie w stronę talerza spaghetti…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Kolejny artykuł z gatunku „przemyślenia i rady na koniec roku” 🙂
Często spotykam się traktowaniem reguł biznesowych jak jakiegoś piątego koła u wozu (o ile w ogóle się ktoś nimi zajmuje w projekcie). Pół roku temu pisałem, że reguły biznesowe to, jeżeli stają się wymaganiem, stanowią kluczowy element realizowanej logiki biznesowej:
Sprawdzoną metodą skutecznego (spójność, kompletność, niesprzeczność) zapisywania wymagań dziedzinowych (w tym ?walidacje?) jest wydzielenie w dokumentacji:
słownika pojęć
słownika reguł biznesowych
specyfikacji tablic decyzyjnych jako uzupełnienia reguł biznesowych.
Jest jednak drugi, nie mniej ważny, element każdego projektu związanego z audytem i modelowaniem organizacji: zasady jej działania czyli właśnie reguły biznesowe. Taki audyt, ukierunkowany na kontrolę spójności i kompletności, prawie zawsze ujawnia luki. Pewnie znacie Machiavelliczną zasadę „wolno wszystko to czego nie zabroniono”? Należy się z tym liczyć zawsze, wręcz założyć, że zostaną podjęte próby szukania „luki w systemie”.
Analiza reguł biznesowych w wielu organizacjach, w zasadzie praktycznie w każdej, pozwala odkryć osobliwe „luki”. Zarządzenia wewnętrzne, regulaminy upustów, programy promocyjne, te i wiele innych to nic innego jak pakiety reguł biznesowych. Często, szczególnie właśnie w postaci regulaminu promocji, staramy się zwiększyć obroty, zmniejszyć straty itp. Co się dzieje jeżeli źle o opracujemy reguły? Tu np. opisano jedną z typowych takich wpadek:
Prokuratura oskarżyła ich o oszustwo i hakerstwo, ale sąd ich uniewinnił, bo przecież nigdzie nie jest napisane, że nie wolno wciskać pewnej konkretnej sekwencji przycisków w automacie. Ani też nie jest napisane, że jeśli automat niespodziewanie rozdaje karty tak samo jak wcześniej, to należy natychmiast przerwać grę i zgłosić obsłudze kasyna, że chyba jest jakiś błąd w systemie. (Wielkie linie lotnicze kontra chłopak, który wyszukuje ludziom tanie bilety… Pozywają go do sądu).
Słowa ?brzydko jest być nieuczciwym? płynące z ust stanowiących prawo, raczej rozśmiesza, bo to prawda, że brzydko, ale nie zmienia to faktu, że ekonomia jest bezlitosna i na pewno ludzie (wielu) znajdą ?wygrywającą? strategię, jeżeli tylko taka istnieje. Innymi słowy skoro miasto pobiera dwie różne opłaty za tę sama usługę (z karą i bez), wybrana zostaje wersja o niższej opłacie. (W strefie parkowania mandat się opłaca ? czyli analiza systemowa ? nie wykonana).
Warto przeczytać oba powyższe artykuły w całości, może natchnie to Was to pochylenia się nad regułami w Waszych firmach, na Waszych portalach, systemach CRM i nie tylko.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem?
Ten artykuł polecam „biznesowi” który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo „takie są fakty”.
Wpadłem jakiś czas temu na stronę SemanticCore.ORG, oto krótki cytat z pierwszej strony :
The semantic core represents a vision of complex systems that are defined and provisioned based on high-level models. This vision is being pursued by multiple groups in multiple organizations based on a variety of paradigms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the semantic core to integrate these diverse paradigms into family of languages that leverages their commonality while taking advantage of their unique capabilities. We will define normalized Meta-Models capturing unique semantics, independent of the notation. […] It is our intent to create a combined submission appropriate for multiple OMG initiatives including Ontologies, Business Rules, Business Process Modeling and a UML infrastructure library.[…] the semantic core will define models for a family of ontologically grounded models defining all aspects of systems, including their requirements, environment, specification and implementation. This will enable a transition from traditional and manual systems building techniques to an automated and human-focused paradigm. (źr. Semantic Core).
Powyżej (moje wytłuszczenia) główne cele tej organizacji (polecam zapoznanie się z całą stroną)
nasza wizja to złożone systemy opisywane i przedstawiane w postaci modeli na wysokim poziomie abstrakcji,
w tym celu definiujemy znormalizowany metamodel opisany systemem znaczeń (semantyka) niezależnym od notacji,
tworzymy to w zgodzie z inicjatywami OMG (www.omg.org),
„semantic core” określa standardowy zestaw kluczowych pojęć i ich znaczeń, opisujących wszystkie aspekty systemów, w tym ich wymagania, otoczenie, specyfikacji i implementacje.
Wygląda jak bajka ale nie jest tak źle, a coś takiego jest bardzo przydatne. Nie ma sensu budowanie jednej mega-notacji do wszystkiego, widać to po pracach OMG (i po tym, że UML jednak nie zastąpił innych notacji, i nikt rozsądny chyba już tego nie planuje). Jednak uznając fakt, że używamy (dobra praktyka) notacji właściwych dla rozwiązywanego problemu (zaryzykuję tezę: właściwa to możliwie najprostsza i wystarczająca) warto jednak zadbać o ich „kompatybilność”. Część wspólna to nie nowa notacja, a utrzymanie spójności znaczeń współdzielonych pojęć istniejących już notacji.
(źr. SemanticCore.org)
O złożoności
Na co warto zwrócić uwagę? Otóż w procesie każdej większej analizy pojawia się złożoność, nad którą należy zapanować. Bez tego opanowania pojawia się coś co zabija projekty analityczne: utrata panowania nad złożonością problemu, pojawiają się mega-diagramy i mega formularze danych.
Kilka tygodni temu, w jednym z moich projektów, miałem okazję wejść w mały spór na temat tego, kiedy udokumentować szczegółowo sposób klasyfikacji (oznaczania) pozycji budżetowych w systemie zarządzania procesem tworzenia budżetu i jego realizacji. Zamawiający od razu wchodził (wręcz żądał) w szczegóły, czyli naście rodzajów każdego z ogromnej liczby typów wydatków. Jeszcze bym dobrze nie ruszył z miejsca a już został bym zgnieciony liczbą tych szczegółów. Do tego dorzucano mi pełną szczegółowość struktury organizacyjnej (także przekłada się na budżet jako miejsca wydawania środków). Dodam, że struktura organizacyjna zmieniła się w ciągu roku trzy razy.
Co z tym zrobić? „Wyrzucić” te szczegóły na sam koniec! One są na początku zupełnie nieistotne (nie licząc zapoznania się nimi jako obecnie funkcjonującym systemem), każdy zaś kto twierdzi, że jednak są istotne już teraz, po prostu jeszcze nie zrozumiał analizowanego problemu.
Problemem są pryncypia czyli „co i po co” a nie „jak”. Owo „jak” to dopiero projektowanie. Tak więc np. budżet, proces jego tworzenia a potem realizacji, to jakiś system „pozycji budżetowych” i zdarzeń związanych z jego realizacją. Jakaś logika tej całości (dalej jako reguły biznesowe i decyzyjne). To jak zostanie oznaczona (jakim symbolem itp.) to efekt tego co chcemy osiągnąć. Każdy kto chwyci się od razu za te szczegóły (jakieś one są, mamy je już więc dlaczego się za nie nie zabrać), zaczyna od końca i w zasadzie zarzucił analizę i odciął sobie (klientowi) możliwość zbudowania optymalnego (nowego) rozwiązania (zapewne innego niż obecne) na rzecz obecnego.
Należy na początku pracować na abstrakcji, uogólnieniu pozwalającym skupić się na kilkunastu pryncypiach zamiast na tysiącach szczegółów. To pierwsze jest relatywnie łatwe, to drugie w zasadzie niemożliwe.
(źr. SemanticCore.org)
Modele
Jak wspomniano powyżej, typów modeli (notacji) mamy więcej niż jeden. Każdy model (rodzaj modelu) ma swój dedykowany system pojęć, po ubraniu go w ikony mamy notację (język obrazkowy), czyli język opisany semantyką (znaczenia pojęć) i syntaktyką (ich wzajemne, dopuszczalne relacje). Zestaw pojęć powinien być dobrany stosowanie do rozwiązywanego problemu (wybór właściwej do etapu pracy notacji).
Jak wskazano wyżej, mamy cztery kluczowe systemy pojęciowe:
UML czyli obiektowy paradygmat opisu i projektowania,
Ontologia (biznesowa, systemowa), którą obecnie reprezentują Model Motywacji Biznesowej (w między czasie także dorobił się ikon), SBVR i systemy pojęciowe opisywania architektury korporacyjnej, struktury organizacji,
Procesy biznesowe,
Reguły biznesowe.
Wspólny środek ma już swoje „zarzewie”. W 2010 roku wydano ostatnią specyfikację Modelu Motywacji Biznesowej (ang. BMM). Można przyjąć, że ten system pojęciowy (teraz także notacja) to element biznesowej ontologii. Pojawił się w niej dodatek F zatytułowany Powiązane specyfikacje modelowania w OMG. I co my tu mamy?
Ano mamy stwierdzenie, że ta kompatybilność jest potrzebna. Napisano, że BMM współdzieli pewne pojęcia z takimi systemami pojęciowymi jak:
BPMN (w BMM pojawia się pojęcie proces biznesowy)
OSM (Organization Structure Metamodel, BMM używa pojęcia „komórka organizacyjna”).
Co ciekawe pojęcia te mają w OMG wspólne definicje (te same pojęcia lub pojęcia dające się mapować 1:1). Utrzyma jest zgodność roli w procesie biznesowym i roli jako elementu struktury organizacyjnej w tych systemach (OSM, BPMN, BMM).
W specyfikacji BMM v.1.1 znajdziemy taki oto diagram:
Notacje, które „wpadły” w ręce OMG maja właśnie tę bardzo pożądaną i przyjemną cechę: są kompatybilne. Wspominałem swego czasu o notacji ArchiMate (obecnie należy do The Open Group podobnie jak i TOGAF). Niestety nie ma tu tej kompatybilności, mimo że TOGAF nie jest samowystarczalnym modelem (wymaga stosowania innych notacji poza ArchiMate), w efekcie nie widzę możliwości „prostego” zastosowania ram TOGAF”a jako bazowej architektury korporacyjnej, bo kolejne etapy uszczegóławiania modeli (a od tego nie ma ucieczki w projektach) albo będą miały kłopoty z jednoznacznością albo będą wymagały jakiegoś dedykowanego systemu tłumaczenia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostatniej wersji dubluje – nie wiem czy w 100% i po co – pojęcia modelu motywacji biznesowej.
Nie wymieniłem tu notacji UML bo ta służy do obiektowego modelowania (paradygmat obiektowy) systemów. Nie widzę sensu „wpychania” jej w dziedzinę ontologii zarządzania. Paradygmat obiektowy to inne spojrzenie, systemowe, opisujące „współdziałające obiekty”, jednak to wtórny model, bo te obiekty systemowe „reprezentują” komórki organizacyjne, strategie, reguły biznesowe, dokumenty itp. Modele obiektowe są doskonałe jako wstęp do projektowania oprogramowania implementowanego z pomocą obiektowo zorientowanych narzędzi. Są kompletnie nieprzydatne jako biznesowy system pojęciowy. Owszem, nie raz tu wspominany DDD (sposób modelowania dziedziny systemu) to pewne takie połączenie, ale to raczej most niż ekwiwalent. Patrząc na ten problem z perspektywy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyższe modele (BMM, BPMN), UML ma zastosowanie dla części PIM (wstępny model implementacji w postaci oprogramowania) i tu jest dopiero miejsce na DDD.
Tak więc bat na szczegóły jest: to prosta zasada „od ogółu do szczegółu”, na każdym etapie mamy stosowną notację (prosty system pojęć). Należy uogólniać i modelować, i potem stopniowo uszczegóławiać modele aż do momentu dojścia do implementacji danego systemu.
Powyżej obraz z naniesionymi etapami [[MDA]] (więcej o Model Driven Architecture oraz Meta Object Facility – powyższy rysunek – na stronach OMG). Core Semantic to szczyt (M3) powyższego. Wymienione wyżej notacje to warstwa M2 (UML dodatkowo obejmuje także M1).
Konkluzja jest taka: bazy danych zawierające szczegółowość systemu, projektujemy na końcu. Szczegóły elementów budżetu (przytaczany przykład) opracowujemy dopiero jako pomysł na implementację, mamy to jednak dwa poziomy implementacji:
rozwiązanie problemu efektywnego zarządzania budżetem w nowej formie np. system znakowania pozycji budżetowych,
implementacja tego systemu jako oprogramowania wspomagającego ten proces w organizacji.
To wszystko powinno być jednak poprzedzone analizą. Analiza obecnej sytuacji nie polega jednak na jej 100% odwzorowaniu w dokumentach analitycznych, a jedynie na poznaniu w celu zrozumienia celu biznesowego, opracowanie jego modelu, i potem dopiero rozwiązywanie problemu: jak to osiągnąć.
Na koniec pewna uwaga :). Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia „opinia prawna” oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.