W kontekście poziomów modelowania polecam książkę How Works Get Done , którą właśnie kończę czytać. Bardzo dobre kompendium wiedzy o modelowaniu procesów w kontekście tytułowego „jak ta praca jest wykonywana”.
Nie będę tu pisał streszczenia ;). Książkę gorąco polecam, jest napisana pragmatycznie przez praktyka, który jednak zaznacza, że skuteczne modelowanie, analiza, usprawnianie procesów i firm wymaga pełnego zrozumienia działania tych firm, zrozumienia wzajemnego wpływu ludzi, zasobów, mechanizmów, celów na produkty procesów, podkreśla także znaczenie i wskazuje korzyści z formalnego podejścia to analizy i modelowania (z naciskiem na słowo modelowanie a nie mapowanie).
Autor wskazał w niej także drugą, po modelowaniu procesów, ważną rzecz w projektach tego typu: model danych. Nie chodzi to jednak o modele baz danych (choć wspomina o nich) a o model struktury informacji. Każdy obiekt danych (dokument itp.) na modelach BPMN to abstrakcja „dokumentu” (zestawu danych). Prędzej czy później pojawia się potrzeba udokumentowania: struktury informacji i tego czym ona jest.
To na czym chce się tu skupić to fakt, że autor opisał co rozumie pod pojęciem „poziomów modelowania”, powołując się na takie nazwiska jak: Roger T. Burlton, G. A. Rummler i A. P. Brache , których spokojnie można już traktować jako autorytety, twórców pewnego ustalonego podejścia, nie raz zresztą nazywanego ich nazwiskami.
Diagram zaczerpnięty z książki:
źr. How work gets done, Artie Mahal, Amazon.
Poziomy te są bardzo wyczerpująco opisane, tu chce tylko wskazać na pewne „pryncypia”, na które wskazywałem w moim niedawnym artykule o poziomach modelowania procesów: Poziomy te to nie „warstwy zagnieżdżania” proces/podproces, poziomy te to ustalona ich szczegółowość. Idąc w gorę model staje się coraz bardziej abstrakcyjny, idąc w dół model zawiera coraz więcej szczegółów.
Najwyższy poziom to „łańcuch wartości”, jest to odpowiednik procesu end-2-end. łańcuch wartości pokazuje role modelowanej organizacji w rynkowym łańcuchu wartości: „co do niej wchodzi i co z niej wychodzi”. Poniżej są procesy (i podprocesy) opisujące wewnętrzny łańcuch wartości firmy. Najniżej mamy poziom zarządzania: konkretne prace i zadania do wykonania wraz ze szczegółowymi opisami. reguły biznesowe są tu traktowane jako element sterujący wykonaniem pracy.
Porównajmy to z tym, znanym nam już, modelem:
(źr. http://www.bptrendsassociates.com/)
Poziom 0 (zero) to poziom strategi. Poziomy 1 i 2 to procesy biznesowe, łańcuch wejść i wyjść kolejnych procesów, abstrakcja opisująca jak firma realizuje swoją misję: dostarcza produkty na rynek. Poziomy 3, 4, 5, to najniższy poziom opisujący detalicznie czynności, zadania i procedury oraz zasoby. Liczba tych poziomów zależy już od tego jakie proporcje przyjęto pomiędzy procedurami i regułami biznesowymi a kompetencjami i automatyzacją. Poziomy te to stopień uszczegółowienia opisu (modelu) procesu ale nie hierarchia procesów.
Liczba poziomów modelowania zależy od skali działania firmy, jak widać są zawsze trzy kluczowe poziomy, w ramach każdego z nich można wydzielić ich szczegółowe warstwy (z możliwością dodawania kolejnych szczegółów 5+).
Na każdym poziomie używamy innych narzędzi, w szczególności poziomy 3 i niższe to raczej dokumenty: opisy procedur i szczegółowe instrukcje a nie modele i diagramy. Zaleca się na poziomie procesów biznesowych (poziom 1 i 2) stosowanie notacji BPMN. Najwyższy poziom nie wymaga aż takich formalizmów ale nic nie stoi na przeszkodzie by ich użyć.
Tyle moich komentarzy. Książkę polecam do przeczytania. Jak widać, pewne elementy analizy i modelowania są swego rodzaju kanonem, wymyślanie własnych może mieć sens ale wtedy wymaga to umiejętności udzielenia odpowiedzi na pytanie „dlaczego”. Od siebie mogę powiedzieć, że podejście bardzo podobne do opisanego powyżej stosuje od wielu lat, jako efekt własnych doświadczeń i analiz, które ku mojej radości jak widać nie są odosobnione. Ich zbieżność z cudzymi dokonaniami utwierdza mnie tylko w przekonaniu, że to właściwa droga.
A książkę polecam każdemu kto ma do czynienia z procesowym podejściem do zarządzania, jest napisana bardzo przystępnie, choć po angielsku.
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.
Kwestia „liczby poziomów modelowania procesów” pojawia się na każdym moim szkoleniu w postaci pytań uczestników. Często także spotykam się z tym „zagadnieniem” w projektach i w literaturze. Można np. spotkać modele z procesami ponumerowanymi poziomami modelowania: procesy główne 0.1; 0.2 itp., procesy pierwszego poziomu: 1.1; 1.2; 1.3, dalej 2.2.4 itd. W czym problem?
Po pierwsze: proces np. archiwizacji dokumentu może się pojawić na każdym z tych poziomów, jaki numer mu nadać? Po drugie pewne obszary działania są mało złożone i możliwe, że wystarczy jeden „poziom”, inne złożone i potrzebne będą może cztery poziomy?
Elementarny proces, podobnie jak klocek LEGO, może się pojawić wszędzie, niezależnie od poziomu, np. realizacja zobowiązania finansowego, czyli zapłata za coś, może się pojawić jako zapłata za fakturę wystawioną przez kancelarię prawną w procesie negocjowania umowy handlowej (czyli bardzo „wysoko”) jak i w procesie regulowania zobowiązań za dziurkacze (raczej nisko w takiej hierarchii).
Najpierw dwie kluczowe definicje za normą terminologiczną ISO 9000 (jakość zarządzania):
Proces to: każde działanie, które przekształca wejście (dane wejściowe) na wyjście (dane wyjściowe). Proces może w swoim „wnętrzu” zawierać zbiór różnych operacji (działań) wzajemnie ze sobą powiązanych i na siebie oddziałujących.
Procedura to: określony sposób realizacji działań lub procesów.
Powyższa definicja jest łatwa do przyjęcia i często stosowana, jednak jest zbyt uboga (pojęcie proces jest tu dość pojemne) by stanowiła podstawę do formalnego modelowania organizacji, dlatego dodatkowo przytoczę tę, nieco pełniejszą:
(cytat, str. 41) Proces biznesowy jest chronologicznym i logicznym ciągiem funkcji (zadań) wykonywanych w toku pracy nad określonym obiektem w ramach racjonalnego działania.
(cytat, str. 431) Proces biznesowy stanowi zbiór powiązanych ze sobą czynności ukierunkowanych na realizację określonego celu biznesowego w oparciu o wykorzystywane zasoby. Proces biznesowy jest sterowany poprzez strategię organizacji definiującą cele oraz produkty tworzone przez procesy.
Przeglądając literaturę przedmiotu (w tym powyższe) można dojść do następującej definicji procesu biznesowego:
Proces biznesowy: czynność, lub logicznie powiązany chronologiczny łańcuch czynności, przekształcający stan wejścia procesu w stan jego wyjścia, mający wartość dla odbiorcy. Proces do wykonania, wymaga określonych zasobów, sposób jego realizacji może być ograniczony. (opr. własne)
Do modelowania procesów obecnie używa się najczęściej notacji BPMN (obecnie tak zwany standard de’facto), specyfikacja tej notacji tak definiuje proces:
A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows that define finite execution semantics. Processes can be defined at any level from enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped together to achieve a common business goal.
Warto zwrócić uwagę na fakt, że z perspektywy notacji, ta jest jedynie językiem wyrazu, proces to „sekwencja aktywności w organizacji, której celem jest dostarczenie określonego efektu”. Dalej: proces jest obrazowany z pomocą grafu złożonego z elementów o określonej semantyce (mających sztywno określone znaczenia). Proces może być definiowany na dowolnym poziomie. Procesy na najniższym poziomie mogą być grupowane np. wspólnym celem. Tyle notacja. Definicja procesu w BPMN jest zgodna z ISO.
Tak więc procesem jest tu każdy przepływ pracy, zaś procesem biznesowym są te przepływy, których granice (początek i koniec) wyznaczają produkty biznesowe (określone obiekty, cele biznesowe).
Co to oznacza? Oznacza to, że skoro celem biznesowym jest np. wystawienie faktury za dokonaną sprzedaż, zaś przygotowanie samej treści faktury jest jedynie jednym z etapów jej tworzenia (krok), procesem biznesowym jest wystawienie faktury, ale nie jest nim samo jej zredagowanie (krok, kolejne zadanie) bo poza redagowaniem mamy także czynności sprawdzenia, księgowania i wydruku. Tak więc na najniższym poziomie hierarchii mamy proces Fakturowanie, dalsze szczegóły wystawienia faktury to procedura jej tworzenia składająca się z kolejnych, ustalonych kroków (zadań do wykonania).
Proces biznesowy Fakturowanie może być (i z reguły jest) częścią nadrzędnego procesu Realizacja zamówienia. Pierwszym produktem tego procesu jest Zamówienie gotowe do wykonania, proces ten to np. sekwencja Rejestracja Zamówienia i Weryfikacja Zamówienia. Cały proces Realizacji zamówienia ma więc dwa podprocesy: Rejestracja zamówienia oraz następujący po nim proces biznesowy Fakturowanie. Produktem pierwszego jest Zatwierdzone zamówienie a produktem drugiego Faktura sprzedaży.
Poszczególne wewnętrzne kroki obu procesów, same z siebie, nie tworzą produktu (np. zarejestrowane ale niesprawdzone Zamówienie nie ma wartości biznesowej, to krok który należy wykonać ale nie jest to samodzielny proces biznesowy).
Popatrzmy na poniższy diagram:
Pokazuje trzy kluczowe poziomy procesowego opisu organizacji: na samym dole mamy zasoby, ich umiejętności wspierane procedurami. To warstwa realizacji, ta która jest udokumentowana w każdej niemalże organizacji jako zakresy obowiązków, procedury i zarządzenia. Najwyższa warstwa to kluczowe elementy strategii, architektura kluczowych procesów. Na tym poziomie można mówić o tak zwanych procesach end-2-end czyli o tym jak organizacja reaguje na bodźce zewnętrzne (np. na każde zapytanie ofertowe odsyłana jest oferta). Ten poziom także jest prawie zawsze udokumentowany jako strategia i plan marketingowy. Warstwa środkowa, procesy biznesowe, to abstrakcja opisująca (modelująca) logikę działania organizacji – jej wewnętrzny łańcuch wartości.
Popatrzmy teraz na jeden ze sposobów ustalenia liczby poziomów modelowania, bardzo często spotykany:
Level 1 ? End-to-end processes: Span across functions, e.g. market-to-cash.
Level 2 ? Main process areas: Typically function-specific, e.g. accounts receivables.
Level 3 ? Sub-processes: Sequence of related activities, e.g. goods invoicing.
Level 4 ? Activities: Key steps within sub-process, e.g. printing invoices.
Level 5 ? Tasks: Specific user actions or system transactions, e.g. send invoice to print. A step contains a description of how to perform the task.
Poziom oznaczony Level‑1 jak najbardziej mamy „zawsze”. Różnica pomiędzy poziomami 4 i 5 jest dla mnie niezrozumiała. Angielskie słowa acitivity i task to odpowiednio czynność i zadanie. Trudno mi sobie wyobrazić drukowanie faktury bez wysłania faktury do druku. Czy to dwa poziomy szczegółowości? To co tu widzę, i nie tylko tu, to mieszanie obszaru działania organizacji (ludzi) z obszarem realizowanym przez „zasoby”. To troszkę (podane przykłady) jak by ktoś uznał, że czynność (poziom 4) to zmiana biegu w samochodzie a zadanie (poziom 5) to zazębienie się właściwych kół zębatych w skrzyni biegów. Ma to sens?
Poziomy 2 i 3 to modele procesów, liczba tych poziomów może być różna o czym dalej.
Przykład
Poniżej procesy end-2-end (celowo nie nadałem im rzeczywistych nazw by nie sugerować się konkretną firmą czy branżą):
Pokazuje jak organizacja reaguje na zdarzenia generowane przez jej otoczenie biznesowe. Kolejny etap (poziom ?) to model (diagram) dla każdego tego procesu:
- proces A
- proces B
Proces A zawiera (tworzy) pośredni produkt (Dane 5) oraz produkt Dane4. Zgodnie z definicją procesu, oznacza to, że A składa się dwóch podprocesów, pierwszy tworzy produkt Dane5 a drugi Dane4. Proces tworzący Dane5 jest wykonywany np. na bazie wiedzy wykonawcy (rola), który posiada wymaganą umiejętność, ta jest opisana w dziale HR więc powielanie zapisów z karty obowiązków jest zbędne, wystarczy się na nią powołać w dokumentacji procesu. Czynność tworząca Dane4 jest na tyle „złożona”, że wiedza wykonawcy to za mało (albo jest ryzyko, że się pomyli) dlatego dokumentujemy (formalizujemy) sposób tworzenia produktu Dane4 jako proces C składający się z określonych czynności:
Proszę zwrócić uwagę, że proces B i C to procedury (wewnątrz nie powstają produkty biznesowe), to tylko opis kroków jakie należy wykonać by powstał produkt procesu. Procedury z powodzeniem można, zamiast tworzyć takie diagramy, opisać znanym z projektów ISO strukturalnym tekstem, diagram raczej nie wnosi tu wartości dodanej. Tworzenie diagramów dla procedur miało by sens, gdyby zrezygnować z procedur w formie tekstowej, w przeciwnym wypadku tworzymy redundantne opisy wymagające synchronizacji. W praktyce robi się tak, dokumentuje procedury diagramami, w przypadkach gdy procedura jest złożona i jej opis tekstowy może być nieczytelny lub trudny w zrozumieniu. Analogicznie ma się sytuacja w przypadkach gdy sposób tworzenia produktu (proces biznesowy) w 100% jest efektem wiedzy posiadanej przez wykonawce (rola): tu powołujemy się wyłącznie na stosowne zapisy w dziale HR, nie tworzymy ich kopii w postaci diagramu.
Zobrazowanie powyższych diagramów, ich powiązań:
Tu mamy diagram obrazujący „podległość”, czyli to jak się one wzajemnie zagnieżdżają i to jak najbardziej obrazuje strukturę całego modelu. Jednak próba ponumerowania konkretnych procesów i zbudowania ich hierarchii zachowującej drzewiastą logikę jest nierealna z powodu własnie tego, że procesy są inicjowane zdarzeniami, te zaś nie są „poziomowe” (np. proces opisany na początku archiwizacji dokumentu może się pojawić na każdym poziomie/diagramie). Numerować hierarchicznie jednak można diagramy, które jak widać, mają strukturę podobną do systemu folderów.
Ile więc mamy poziomów modelowania organizacji? Trzy (patrz pokazany wcześniej diagram BPTrends): najwyższy czyli strategia i procesy end-2-end, najniższy czyli procedury i instrukcje stanowiskowe (implementacja) oraz środkowy czyli abstrakcję – model procesowy – opisującą jak to się wszystko do siebie ma (środkowy poziom ma strukturę zagnieżdżania się diagramów/modeli procesów jak wyżej ale procesy mają jedynie swoje nazwy jako identyfikatory).
Proszę zwrócić uwagę, że:
w zasadzie każda organizacja ma udokumentowany poziom najwyższy (strategia) i najniższy (procedury, zarządzenia, instrukcje)
warstwa środkowa jest tworzona wtedy, gdy chcemy zrozumieć wewnętrzne zależności, których może być dużo, i mogą być złożone (zawiłe); to ile „poziomów” powstanie w warstwie środkowej, zależy wyłącznie od stopnia złożoności danej organizacji i zawsze jest to indywidualna jej cecha, tylko w części zależna od wielkości organizacji.
Często można się spotkać z nieformalnymi (o niezdefiniowanych granicach procesów) diagramami w postaci:
Poziom najwyższy:
i poziomy niższe:
Czy taki diagram nam coś nam daje? Jest w zasadzie graficzną formą tekstowego (niejednoznacznego) opisu.
Modelowanie procesów biznesowych to nie rysowanie diagramów, to tworzenie modeli, które poddają się walidacji i testowaniu zgodności z rzeczywistością. Poprawne modele pozwalają przewidywać reakcję organizacji na planowane zmiany.
Na zakończenie
Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości „map procesów”, które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia.
Po więc robimy te modele? Przytoczę znowu cytat inicjujący pewną dyskusję na forum:
I think the only reason to conduct any project is to improve one or more processes. This means that if you don’t know which process(es) you are trying to improve, you should not start the project. Comments? (Process before project | LinkedIn).
W wolnym tłumaczeniu ;):
jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.
Procesy modelujemy więc po to, by zrozumieć jak działa organizacja oraz po to, by przewidzieć jak się ona zachowa, jeżeli jakiś proces zmienimy, bo może się nie raz okazać, że nie warto się pewnych projektów podejmować z uwagi na skutki.
Modelowanie, jak widać, nie jest procesem obrazkowego zapisu tego co wiemy od pracowników tej czy innej firmy, to jest stenotypia. Modelowanie to trudny proces odkrywania prawdziwej logiki działania organizacji (i wypada mi teraz zaprosić na moje szkolenia :)).
Skersys, T., Tutkute, L., Butleris, R., & Butkiene, R. (2012). Extending BPMN business process model with SBVR business vocabulary and rules. Information Technology and Control, 41(4), 356 – 367.
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.
Mój serwis systematycznie płynie w stronę marketingu i strategii, chyba nie ma od tego odwrotu. Praktyka pokazuje, że wybór i próba wdrożenia jakiegokolwiek systemu bez związku ze strategią firmy, że już nie wspomnę, przy jej braku, nie wróży dobrze.
Często spotykam się z twierdzeniem, że do wdrożenia nowego systemu trzeba tylko spisać wymagania i przeprowadzić przetarg. Cała sztuka w wymaganiach. Modne są tak zwane ankiety, na bazie których zbiera się informacje o tym co robią pracownicy i na ich podstawie spisuje wymagania. Opis taki staje się wyznacznikiem tego co ma robić wdrażany system i najczęściej pierwszym gwoździem do trumny wdrożenia.
W czym kłopot? W tym, że taka procedura to zastój a nie rozwój.
Firmy, które wdrożyły z sukcesem jakikolwiek system wiedzą, że w większości przypadków stan organizacji pracy osiągnięty po wdrożeniu nijak się nie ma do dawnych opisów z ankiet przedwdrożeniowych, wiec po co je robić?
Więc jak to robić? Firmę można opisać (zamodelować) na trzech podstawowych poziomach:
Cel rynkowy, podstawowa wartość dodana oferowana na rynku czyli położenie w łańcuchu wartości
Opis tego w jaki sposób realizowany jest przez firmę podstawowy produkt rynkowy czyli opis łańcucha procesów biznesowych (przypominam, że proces to zespół czynności tworzący wartość)
Opis tego, w jaki sposób pracownicy firmy realizują prace opisane łańcuchem procesów (łańcuch czynności, pracy.
Czym jest strategia firmy? Jest tym co stanowi podstawę planowania działań nad rozwojem firmy. Jeżeli plan to stan firmy przewidywany jako osiągalny w założonym czasie to strategia jest receptą na realizację tego planu. To lista działań i sposobów ich prowadzenia.
Jak więc można podejść do wyboru i wdrożenia systemu
Powyższy diagram (opracowanie własne) to model procesu realizacji planu rozwoju w kontekście wdrożenia systemu informacyjnego. Każdy z elementów zobrazowanych na diagramie powinien być w firmie zdefiniowany czyli:
Opisana strategia rozwoju
Opisany model funkcjonowania (model procesów biznesowych)
Procedury czyli recepty na wykonywanie czynności
To ostatnie podlega zmianom w trakcie wdrożenia. Dlaczego? Powodem jest właśnie to, że wybierany i potem wdrażany system stanie się nowym narzędziem pracy, które na pewno zmieni (powinno) sposób wykonywania większości czynności. Podejście polegające na spisaniu ankietami obecnie wykonywanych czynności i zaimplementowanie ich prowadzi do sytuacji, w której kierowcę przesadzamy z samochodu na śmigłowiec ale nadal karzemy mu poruszać tylko nad drogami i zatrzymywać na czerwonym świetle.
Należy się pogodzić z reorganizacją, określić cele wdrożenia jednak celem tym nie powinna być sama tylko automatyzacja. Nowy system powinien wnieść do firmy nową jakość, nowe możliwości. W przeciwnym wypadku trudno jest mówić o podnoszeniu konkurencyjności czy uzyskiwaniu istotnej przewagi rynkowej. Bo na czym miała by ona wtedy polegać? Jazda na szybszym rowerze sama z siebie nie jest sposobem na osiąganie istotnej przewagi. Należy najpierw obrać nową drogę i potem dobrać do niej najlepszy pojazd.
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.