Podstawowe definicje

PROCES: Czynność lub grupa czynności, które rozpoczynają się od pobrania czegoś na wejściu, dodają do tego wartości (przetwarzają) a następnie dostarczają to coś (rezultat) wewnętrznemu lub zewnętrznemu klientowi. Proces zużywa zasoby organizacji aby zapewnić określone rezultaty.

PROCES PRODUKCJI: Każdy proces angażujący fizycznie hardware (przedmioty) i software (informacje, wiedzę), które podlegają przetwarzaniu z przeznaczeniem dla zewnętrznego klienta; proces produkcji dostarcza swój produkt do miejsca pakowania/załadunku. Przewóz produktów i ich dystrybucja nie należą do procesu produkcji.

Przykłady: wytwarzanie komputerów, przetwórstwo żywności dla potrzeb masowego konsumenta, rafinacja paliw płynnych, przerabianie żelaza na stal.

PROCES BIZNESOWY: Każdy proces tworzenia usług oraz każdy proces wspierający procesy produkcji. Proces biznesowy składa się z połączonych logicznie zadań, w których wykorzystuje się zasoby organizacji aby zaperwnić określony rezultat wspierający cele organizacji. Przykłady: Sporządzanie zamówień, projektowanie zmian, wynagradzanie, projektowanie procesu produkcji.

FUNKCJA: Grupa realizująca określoną część procesów biznesowych. Typowe funkcje to marketing i sprzedaż, rachunkowość, projektowanie i rozwój, zakupy i zapewnienie jakości.

SYSTEM: Punkty kontrolne stosowane w procesie aby upewnić się (sprawdzić), czy przebiega on wydajnie i skutecznie.

Podstawowe przesłanki metody BPI

• W każdej organizacji codziennie realizuje się setki procesów biznesowych. Na ogół około 80% z nich to procesy powtarzalne, wykonywane regularnie w podobny sposób. Tego rodzaju procesami można i powinno się sterować (kontrolować) podobnie jak steruje się procesami produkcji.
• Dzisiaj sam proces produkcji, technika i technologia wytwarzania, nie decydują o powodzeniu w biznesie. Decyduje o nim zarządzanie, nakładające punkty kontrolne i techniki sterowania (sprzężenia zwrotnego) do wszystkich działań odbywających się w firmie i biorące pod uwagę organizację jako całość, jako kompleks powiązanych ze sobą procesów.

Ogólne określenie BPI

Business Process Improvement (BPI) można określić jako metodę ulepszania procesów wspierających produkcję i świadczenia usług, wykorzystującą dorobek praktyczny z zakresu diagnostyki procesów i kierowania zmianami organizacyjnymi oraz zestaw specjalnie zmodyfikowanych narzędzi Praktycznej Inżynierii Przemysłowej.

Jedną z charakterystycznych cech BPI jako metody ulepszania zarządzania jest jej koncentracja na procesie a nie na strukturze organizacyjnej. Różnicę tę można ukazać za pomocą następującego zestawienia:

Jakość procesu i ulepszanie procesu

Procesy biznesowe wymagają ulepszania, gdyż w typowej organizacji proces pracy przebiega „w poprzek” pionowej struktury organizacyjnej, co powoduje, że w wielu miejscach pojawiają się luki, nakładanie się czynności, nadmiar czynności kontrolnych itp., zjawiska pogarszające jakość procesów.

Jakość procesu biznesowego definiuje się na dwa sposoby. Po pierwsze – jako cele procesu ulepszania:

Trzy cele (ang. objectives) BPI:

• podnieść skuteczność procesów – aby produkowały pożądane rezultaty,
• podnieść wydajność procesów – aby oszczędniej zużywały zasoby,
• podnieść elastyczność procesów – aby lepiej adaptowały się do zmian wymagań klientów i biznesu.

Drugie określenie odpowiada na pytanie, czym charakteryzuje się dobrze zdefiniowany i dobrze zarządzany proces

Dobrze zdefiniowany i dobrze zarządzany proces to taki, który:

a) ma kogoś, kto jest odpowiedzialny za sprawny przebieg procesu, kto dba, aby proces był skuteczny, wydajny i elastyczny, aby produkował pożądane rezultaty; osoba taka nazywana jest właścicielem procesu (process owner),

b) ma dobrze zdefiniowane granice (zakres),

c) ma dobrze zdefiniowane wewnętrzne połączenia i odpowiedzialność,

d) ma udokumentowane zadania, procedury i wymagania szkoleniowe,

e) ma instrumenty pomiaru i kontroli (punkty kontrolne) umieszczone w miejscach bliskich wykonywanym działaniom,

f) ma instrumenty pomiaru zorientowane na wymagania klienta oraz wartości docelowe (określone wyniki, jakie należy uzyskać, targets),

g) ma znany czas cyklu,

h) ma sformalizowane procedury zmian,

i) ma w sobie wiedzę o tym, jak dobry może być (benchmarks).

Cel BPI

Głównym celem realizacji BPI w przedsiębiorstwie jest zapewnienie, aby w organizacji zachodziły procesy biznesowe które:

• eliminują błędy,
• redukują opóźnienia,
• maksymalizują wykorzystanie aktywów,
• promują rozumienie biznesu,
• są łatwe do prowadzenia,
• są przyjazne dla klienta,
• adaptują się do zmiennych wymagań klienta,
• wyposażają organizację w przewagę konkurencyjną,
• redukują nadmiar pracy

C. d. n.

————————-

[1] Harrington H. J., Business Process Improvement. The Breakthrough Strategy for Toatal Quality, Productivity and Competitiveness, MaGraww-Hill, Inc. 1991

—

Przypadek

Fabryka produkuje wyroby na oba rynki: konsumpcyjny i profesjonalny. Odkąd klienci profesjonalni zwiększyli częstotliwość zamawiania wyrobów niekatalogowych (tzn. w wykonaniu specjalnym), fabryka odczuwa ekonomiczne i organizacyjne konsekwencje nieuporządkowanej polityki wobec takich klientów. Potwierdzanie zamówień „nietypowych” trwa zbyt długo, trudno jest także opracować politykę cenową oraz ocenić opłacalność realizacji takich zamówień (zwłaszcza składanych przez nowych, obiecujących klientów).

Wstępna analiza procesu potwierdzania zamówień miała na celu znalezienie miejsc w procesie, które wymagają przeprojektowania, aby skrócić jego czas. Została przeprowadzona przez konsultanta wewnętrznego, przy pomocy autora i pod jego nadzorem. Niniejszy opis wykracza nieco poza to, co zrobił ów konsultant.

Poniższa ilustracja pokazuje schemat blokowy procesu wykonany w ramach wspomnianej analizy.

Ilustracja

Schemat blokowy przykładowego procesu potwierdzania zamówień.

Przebieg analizy wstępnej

1. Przy definiowaniu (identyfikowaniu) procesu biznesowego należy trzymać się zasady, że zaczynamy od identyfikacji końca procesu, pytając, co proces produkuje. Obserwacja i rozmowy z pracownikami pozwoliły stwierdzić, że proces zawsze produkuje odpowiedź kierowaną do Działu Sprzedaży, a jeśli stan negocjacji z klientem na produkt niekatalogowy pozwala, proces produkuje także zlecenie do Sekcji Harmonogramowania Produkcji.
2. Następny krok to wyznaczenie początku procesu biznesowego, czyli zdarzenia, które „wyzwala” bądź „inicjuje” proces, czy też „mobilizuje” zasoby ludzkie. Zdarzeniem tym jest w naszym przypadku otrzymanie zamówienia od klienta.
3. Ustalenie modelu procesu (podejścia). W naszym przypadku wchodziły w grę 2 możliwości:
   • potraktowanie procesu jako „posiadanego” i prowadzonego („pilotowanego”) przez osobę odpowiedzialną; wówczas wszelkie zasoby dodatkowe potrzebne do potwierdzenia zamówienia należałoby potraktować jako zasoby pobierane przez proces, spoza tzw. granicy górnej procesu;
   • potraktowanie procesu jako przetwarzania informacji (ang. processing – tu zbieranie odpowiedzi na pytania, stawianie pytań rutynowych i odpowiadanie na nie, wreszcie budowanie dokumentu/ów z odpowiedziami)

   Sprawdzono, że możliwość pierwsza miałaby zastosowanie do potwierdzania zamówień na wyroby katalogowe, ale w przypadku produktów niekatalogowych właściwie nie wiadomo, kto jest odpowiedzialny za opracowanie odpowiedzi klientowi (dokumentację po prostu puszcza się obiegiem). Dlatego przyjęto model processing.

4. Prześledzono „ścieżki” przetwarzania informacji od końca do początku. Najłatwiej było stwierdzić, że odrzucenie zamówienia jest „filtrowane” przez Szefa Wydziału Produkcyjnego. To było stwierdzenie zdumiewające, a jeszcze bardziej zaskakujące było to, że bardzo rzadko zdarza się potwierdzanie zamówienia bezpośrednio po uzyskaniu pozytywnej opinii specjalistów (wykryto to dopiero analizując dokumentację z 25 ostatnich zamówień „nietypowych”). Inaczej mówiąc, w większości przypadków decyzję o przyjęciu bądź odrzuceniu zamówienia podejmował Szef Wydziału Produkcyjnego, niezależnie od opinii specjalistów. UWAGA: Na wykresie powinno być napisane „opinie negatywne i pozytywne”, a nie tylko „opinie negatywne”, ale przytaczam rysunek w wersji oryginalnej, „chroniącej skórę” menedżerów ;).
5. Dla upewnienia się, że proces został prawidłowo przeanalizowany, prześledzono przebieg 25 ostatnich zamówień nietypowych oraz 25 zamówień typowych od początku do końca procesu.

Wnioski

1. Procedura analizy. Wyznaczenie końca procesu było stosunkowo łatwe, gdyż praca Działu Sprzedaży jest dobrze zbiurokratyzowana: każdy temat ma odrębną dokumentację papierową i komputerową, a większość korespondencji wewnętrznej przechodzi przez dziennik podawczy. Nawiasem mówiąc dzięki temu również analiza pracy specjalistów (konsultantów) nie nastręczała trudności.
2. Następne kroki. Do analizy przeglądowej przepływu procesu skierowano 2 główne zagadnienia:
   • Dlaczego mimo opinii specjalistów decyzje podejmuje w większości przypadków Szef Działu Produkcyjnego oraz jakie ma to konsekwencje ekonomiczne? W rozmowach z pracownikami stwierdzono bowiem, że w przypadku opinii negatywnych przyjęcie zamówienia wiąże się z koniecznością zastosowania „obejść”, czyli projektów i technologii nieuzasadnionych z punktu widzenia inżynierskiego, ale być może uzasadnionych z punktu widzenia biznesowego (np. możliwość „złapania” dużego klienta). Dobrze opracowana analiza powinna być jedną z podstaw standardowej polityki wobec zamówień „nietypowych”.
   • Jakie są możliwości skrócenia cyklu opiniowania? Stwierdzono bowiem, że opinowanie trwa nadmiernie długo w porównaniu z benchmarkami.
3. Następne kroki. Dodatkowo postawiono zagadnienie odbiorcy odpowiedzi. W analizowanym procesie odpowiedź jest przekazywana do Działu Sprzedaży, podczas gdy benchmark z przedsiębiorstw fińskich wskazuje, że możliwe jest na tym etapie przeniesienie kontaktów z klientem bezpośrednio w ręce wykonawców zamówienia (mistrza kierującego realizacją zlecenia) z bardzo pozytywnymi skutkami.

Dalszy ciąg analizy omawianego przypadku przedstawiono w artykule Karta przepływu procesu biznesowego – przykład.

—

Przypadek

Jest to dalszy ciąg analizy przypadku, dla którego sporządzono schemat blokowy procesu. Karta przepływu procesu (ang. flowchart) przedstawiona jest na rysunku poniżej.

Główny cel tej analizy to sprawdzenie możliwości skrócenia procesu konsultacji, który trwa ok. 10 dni. Dodatkowo postanowiono nieco głębiej rozpoznać przyczyny nieskuteczności opinii konsultantów, przejawiającej się w tym, że niezależnie od ich opinii ostateczną decyzję podejmował Kierownik Wydziału Produkcyjnego. Przypuszczano bowiem, że przyczyny obu wad procesu mogą być wspólne albo powiązane.

Ilustracja

Karta przepływu przykładowego procesu potwierdzania zamówień.

UWAGI

Wnioski:

1. Na karcie przepływu procesu ujawniono błędy organizacji procesu. Pierwszy z nich jest widoczny na pierwszy rzut oka: linie biegnące od liter T („tak”) i N („nie”) spotykają się. Postawiono hipotezę, że kryteria profesjonalne konsultantów są niewłaściwe bądź niewystarczające, aby spowodować właściwą reakcję. Drugi błąd, to sekwencyjna praca konsultantów, która jest przyczyną nadmiernie długiego czasu procesu.
2. Mimo, że rozwiązania obu problemów wydają się oczywiste, w praktyce wymagały eksperymentowania.

—

Dwa rodzaje wskaźników operacyjnych

Wskaźnik operacyjny (ang. operation rate, operating rate) stanowi miarę wykorzystania zasobów przedsiębiorstwa. W praktyce stosowane są dwa rodzaje wskaźnika operacyjnego.

Pierwszy mierzy stopień wykorzystania zasobów z punktu widzenia pracy ludzi i urządzeń. Najczęściej jest to po prostu stopień wykorzystania zdolności produkcyjnych (tzw. factory operation rate, factory operating rate).

Drugi mierzy stopień wykorzystania zasobów z punktu widzenia przetwarzanego materiału bądź informacji (ew. dokumentu), czyli w perspektywie processing (patrz. schemat blokowy dla przykładu). Najczęściej stosowanym wskaźnikiem tego rodzaju jest stosunek czasu elementów procesu przynoszących wartość dodaną do całkowitego czasu przerobu.

Przykład

Poniższy przykład ilustruje metodę pomiaru wskaźnika operacyjnego drugiego rodzaju. Pomiar przeprowadzono w celu oceny opłacalności uwolnienia części wydatków NIEPLANOWANYCH, ponoszonych przez kierowników wydziałów spod kontroli kontrolera budżetu.

Pomysł był prosty: skoro zatwierdzanie nieplanowanych wydatków angażuje pracę biurową oraz dramatycznie opóźnia zaopatrzenie w rzeczy niezbędne, choć nieprzewidziane, to może wyposażyć kierowników w rezerwę, którą dysponowaliby samodzielnie, bez potrzeby zgłaszania wydatków kontrolerowi.

Pomiar

Ilustracja

Zestawienie czasu elementów procesu zatwierdzania dokumentu.

Dalszy ciąg przykładu

Mimo ewidentnej potrzeby upoważnienia kierowników do samodzielnego dokonywania drobnych zakupów nieplanowanych pomysł nie został zrealizowany. Odmówili kierownicy, którzy nie chcieli wziąć na siebie odpowiedzialności za samodzielne zatwierdzane takich zakupów, chociaż nie wymagano od nich nawet uzasadniania – wystarczyć miało oświadczenie (konieczne z uwagi na spójność systemu księgowania), że zakupów dokonali zgodnie z potrzebami oraz ze swoją najlepszą wolą i wiedzą.

—

Zasada oceny

Ocena jakościowa wartości dodanej przez poszczególne procesy biznesowe polega po prostu na ich klasyfikacji. Harrington proponuje 3 kategorie takiej klasyfikacji, wyróżniając:

• procesy dodające rzeczywistej wartości klientowi,
• procesy nie dodające bezpośrednio wartości klientowi, ale niezbędne dla funkcjonowania biznesu,
• procesy bez wartości dodanej.

Klasyfikacji dokonuje się, wg Harringtona, w kilku krokach przedstawionych na poniższym schemacie.

Ilustracja

Schemat klasyfikacji procesów biznesowych ze względu na wartość dodaną.

UWAGI

Najtrudniej jest ustalić, jakiego rodzaju proces daje biznesową wartość dodaną. Pomocną wskazówką może być stwierdzenie, że do tej kategorii zaliczmy procesy:

• zapewnienia zasobów niezbędnych dla funkcjonowania procesów dających rzeczywistą wartość dodaną,
• te, które wypełniają wymagania innych, niż klient, kontrahentów społecznych.

Zestawienie elementów procesu biznesowego, takie jak w przykładzie jest punktem wyjścia do analizy cykl-koszt. Prowadząc tę analizę często posiłkujemy się wykresem, na którym w kierunku pionowym nanosimy koszt procesu narastająco (skumulowany), a w kierunku poziomym nanosimy czas trwania poszczególnych elementów cyklu.

Poniższy przykład pokazuje taki właśnie wykres, ale uzupełniony o wyniki oceny procesu pod kątem wartości dodanej w taki sposób, że każde działanie ujęto z uwzględnieniem towarzyszących mu elementów z biznesową wartością dodaną oraz elementów bez wartości dodanej.

Rys. 1. przedstawia wyniki takiej analizy przed usprawnieniem procesu.

Rys. 1.

Wykres koszt-czas cyklu przed ulepszeniem.

Oznaczenia w legendzie rysunku:

• RVA – elementy dające rzeczywistą wartość dodaną (ang. Real Value Added)
• BVA – elementy dające biznesową wartość dodaną (ang. Business Value Added)
• NVA – elementy bez wartości dodanej (ang. No Value Added)

Należy zwrócić uwagę na to, że elementy BVA zostały zakreskowane lekko, elementy NVA zacienione mocniej. W ten sposób największe pola powierzchni wskazują ewentualne priorytety usprawnień, a wśród tych priorytetów pola zacienione, a w dalszej kolejności zakreskowane, sugerują rangę priorytetów.

Rys. 2.

Wykres koszt-czas cyklu po ulepszeniu.

Rys. 2. przedstawia wykres koszt-cykl tego samego procesu po usprawnieniu, narysowany na tle konturu procesu przed usprawnieniem. W ten sposób na pierwszy rzut oka można ocenić wielkość postępu w ulepszaniu procesu.

Oznaczenia legendy takie same, jak w Rys. 1.

—

Na konferencji we Wrocławiu Keith Harrison-Broninski przedstawił koncepcję uznawaną za przełom w metodologii opisu i modelowania współpracy ludzi tworzących usługi.

Andrzej Góralczyk

Mam zwyczaj przygotowywać się do wysłuchania ważnego wykładu, więc przed wyjazdem do Wrocławia przejrzałem literaturę. Od razu znalazłem rzecz najciekawszą – autorzy oceniający pozytywnie koncepcję Keitha jednocześnie stawiają poważne zarzuty całemu nurtowi BPM – Business Process Management. Lektura sugeruje więc, że Human Interaction Management (HIM)  rozwija się w opozycji do BPM, ale historia myśli ludzkiej uczy, że opozycja jest zarazem kontynuacją. Zapewne za jakiś czas okaże się, w wyniku studiów metodologicznych, że nie inaczej jest w omawianym przypadku. Przy okazji znalazłem odpowiedź na pytanie, na które przed laty nie odpowiedział mi prof. Scheer – co to jest BPM? Otóż BPM jest rozszerzeniem technologii workflow, czyli jest technologią informatyczną i wbrew swej nazwie nie ma wiele wspólnego z procesami biznesowymi[1]. Spostrzeżenie zdumiewające i zarazem potwierdzające moje wcześniejsze podejrzenia[2].

Krytyka BPM ma niedługą tradycję, więc siłą rzeczy jest fragmentaryczna i sporo w niej uproszczeń. Jeden z zarzutów brzmi podobnie, jak główny zarzut wobec radykalnego reengineeringu – że ignoruje ludzi uczestniczących w procesie. Bardziej precyzyjnie – że projekt procesu nie uwzględnia różnorodności rzeczywistych sytuacji i ludzkich zachowań, lecz jest wyrazem iluzji, że ludzie będą robili dokładnie to, co zaprojektowano. Ja czasem strzelam z grubszej armaty gdy narzekam, że metoda modelowania procesu biznesowego nie respektuje podstawowej zasady Inżynierii Przemysłowej, wg której punktem wyjścia do modelu ma być proces rzeczywisty, a zadaniem projektanta jest przeprojektowanie go. Zamiast tego projekty BPM biorą za podstawę wyobrażenie systemu, który wydaje się projektantowi idealny, a ludzie uczestniczący w procesie mają być perfekcyjnymi wykonawcami procedur systemowych. Co gorsza, często takie wyobrażenie jest dowolne, co widać np. na diagramach rysowanych z wykorzystaniem notacji opracowanej specjalnie dla BPM[3] (ten zarzut domaga się bardziej gruntownego omówienia, na które nie ma tu miejsca). Kolejny koronny zarzut mówi o tym, że procesy projektowane w konwencji BPM ujmują wyłącznie przemieszczanie się pracy od jednego zasobu (stanowiska pracy bądź np. komputera) do drugiego, gdy tymczasem ponoć aż 85% procesów biznesowych przebiega inaczej[4]. Na przykład wtedy, gdy ludzie współpracują.

Rozpisałem się na temat krytyki BPM nieprzypadkowo – metodologia Human Interaction Management jest pod wieloma względami zupełnie odwrotna. Przede wszystkim opisuje współdziałanie ludzi uczestniczących w procesie biznesowym, w tym także ludzi będących klientami zewnętrznymi procesu. Po drugie, nie ogranicza opisu do działań z wykorzystaniem komputerów, lecz ujmuje także „ręczną” pracę papierową i komunikowanie się ludzi. Po trzecie, opisuje pracę taką, jaką ludzie wykonują w rzeczywistości, a nie w ramach jakiegoś wymyślonego systemu. Zresztą w ogóle mało prawdopodobne, aby „nachylenie systemowe” pojawiło się w takim opisie, gdyż to sami uczestnicy projektują przebieg swojej pracy, a nie tzw. analitycy biznesowi. Toteż mogą projektować różne wersje przebiegu swego współdziałania, uwzględniając różnorodność sytuacji, ról przyjmowanych w procesie i działań. Konsekwencją owego realizmu jest piąte założenie – HIM uwzględnia fakt nieprzewidywalności ludzkich działań i „pozwala” ludziom usprawniać proces w ramach realizacji konkretnych instancji procesu.

Notację HIM opracował Keith Harrison-Broninski na podstawie wyników wieloletnich badań nad procesami tworzenia usług (wykorzystując symbole notacji Rapid Application Development). Na etapie projektowania usługi opisuje się interakcje zachodzące pomiędzy rolami, które następnie – w fazie realizacji – są przypisywane Osobom (identity). Interakcje warunkują się kolejno, tzn. dana interakcja zachodzi w odpowiedzi na poprzednią. Opis „tego co ma być zrobione” zasadniczo ujmuje aspekt komunikacyjny interakcji. Treść komunikatu (message) może należeć do jednej z 44 kategorii i przybrać jedną z 23 form. Działania natomiast są domeną ról. Działanie może należeć do jednej z pięciu kategorii – może to być badanie (Research), ocena (Evaulate), analiza (Analyze), ograniczenie (Constrain) i zadanie (Task). Sekwencja tych pięciu działań w przytoczonej kolejności (REACT) stanowi jeden z podstawowych – wykrytych w badaniach – wzorców zachowania ludzi „produkujących” usługę. W różnych kontekstach biznesowych mają zastosowanie różne wzorce, a działania podlegają regułom. Na etapie realizacji konkretne działania (sekwencję działań) podejmuje ta osoba, która przyjęła daną rolę.

Keith sam przyznaje, że w odniesieniu do usług wykonał podobną robotę, jak pierwsi przedstawiciele naukowej organizacji pracy w odniesieniu do przemysłowych procesów wytwarzania wyrobów. Myślę, że dlatego właśnie HIM uznawany jest za przełomowy moment w analizie procesów tworzenia usług opartej na naukowych podstawach. Podzielam tę opinię.

Dysponując wspomnianym powyżej słownikiem interakcji i działań można zaprojektować „to, co ma być zrobione”. Boję się pisać „proces”, gdyż taki projekt silnie eksponuje działania i interakcje zachodzące między ludźmi, ale na skutek tego „to co ma zostać przetworzone” (processing) umyka trochę z pola widzenia i wygląda czasem na nie zdefiniowane – przynajmniej w moich oczach tak wygląda. Nie zawsze jasne jest także kryterium startu, które powinno być nieodzownym elementem każdego opisu procesu. Być może Keith także w ten sposób widzi swoje dzieło, gdyż nie używa słowa „proces”, lecz „opowieść” (story).

Opowieści można projektować na zwykłej kartce papieru, ale można także posłużyć się programem komputerowym HumanEdj. Spróbowałem i okazało się, że jest to trudne. Główną trudność sprawia mnogość kategorii opisu interakcji, a właściwie komunikatów. Moim zdaniem jest to sygnał, że metodologia HIM  będzie musiała przejść – podobnie jak niegdyś klasyczne narzędzia naukowej organizacji pracy – szereg uproszczeń. Druga porcja trudności wynika z niezbyt szczęśliwego doboru platformy, w której program został zrealizowany. Jest to wtyczka do Eclipse, działająca w środowisku maszyny wirtualnej Java i w związku z tym cały projekt (opowieść) ma strukturę drzewa – strukturę ewidentnie zbyt sztywną, nie pasującą do przedmiotu opisu.

Moje wątpliwości wzbudza też użycie słowa „management” w nazwie omawianej metodologii. Co prawda Keith wyróżnia dwa poziomy zarządzania działaniami, operacyjny i wykonawczy, lecz w opisach i diagramach HIM nie potrafię się tego dopatrzeć. Brakuje mi bowiem istotnego elementu zarządzania, mianowicie sprzężenia zwrotnego, dzięki któremu możliwe jest sterowanie przebiegiem działań. Moim zdaniem słowo „inżynieria” lepiej oddawałoby sens tego, czym jest HIM. Lecz skoro entuzjaści BPM mylą swoje projekty i programy z zarządzaniem, to może taka niewielka doza anarchii terminologicznej jest do zaakceptowania?

Konferencję Business Process Management Forum Practices for Business Agility zorganizowała wrocławska firma AION (http://www.aion.com.pl). Na stronie http://www.process.com.pl/ można znaleźć m. in. podsumowanie obrad.

———————–
[1]    Pyke, J. Why workflow sucks, ebizQ, 2006/11/29, http://www.ebizq.net/hot topics/bpm/features/7462.html
[2]    Por dyskusja w http://www.dyrekcja.objectis.net/biblioteka/techniki/bpi/schematblokowy01 oraz http://www.dyrekcja.objectis.net/biblioteka/techniki/bpi/flowchart02
[3]    Por np. http://en.wikipedia.org/wiki/Business Process Modeling Notation.
[4]    Pyke, J., op. cit.

—

Najistotniejsze problemy, które dzisiaj nie pozwalają firmom w pełni wykorzystać okazji stwarzanych przez koniunkturę, to ułomna współpraca w ramach łańcucha dostaw oraz niedoskonałe systemy planowania, zwłaszcza produkcji. Taki jest główny wniosek z majowego badania Business Dialog.

Iwona D. Bartczak

Z badania „Mądrość firm w czasach koniunktury: upraszczanie procesów i minimalizowanie strat” przeprowadzonego w maju 2007 przez Business Dialog we współpracy z HADATAP wynika niezbicie, że największym dzisiejszym zagrożeniem firm jest zaniedbywanie doskonalenia struktur i procesów wewnętrznych (67%), koncentracja na inwestycjach w zdobywanie rynku, kosztem wewnętrznych usprawnień (47%). W trzeciej kolejności wskazano zaniechanie unowocześniania zasobów produkcyjnych (40%), a jako czwarte – lekceważenie doskonalenia kwalifikacji kadry (33% odpowiedzi). Firmy doskonale wiedzą, że warto w czasie koniunktury inwestować w usprawnianie procesów i badania. Obie te pozycje wskazało po 60% respondentów. 53% wskazało modernizację zasobów produkcyjnych.

Paradoksem jest więc, że firmy wiedzą, jak powinny się zachowywać w czasie koniunktury, jakiej hierarchii celów przestrzegać, a jednak bardzo często tak nie czynią. Co jest przyczyną tego zjawiska? Brak wiedzy wewnątrz firmy? Brak motywacji do wyznaczania długofalowych celów? Interesy grup menedżerów i pracowników, które mogłyby być zagrożone w wyniku doskonalenia? W każdej firmie odpowiedź będzie inna, jednak samo zjawisko powinno pobudzić do działania właścicieli i rady nadzorcze oraz zarządów, pilnujących długoterminowych interesów całej firmy.

W badaniu szczególnie interesowano się procesem produkcyjnym. Po czym firmy poznają, że ten proces źle funkcjonuje? Przede wszystkim sygnalizuje im to niestabilna jakość produktów (60% odpowiedzi). Następnie równorzędny procent odpowiedzi uzyskały: wąskie gardła i spiętrzenia oraz trudności w synchronizacji procesu przy zwiększonej różnorodności produktów (47%). Zwracano również uwagę na nieterminowość wysyłek do klientów i brak informacji o produkcji w toku. Większość firm posiada systemy informatyczne wspomagające zarządzanie produkcją. Czy one źle wywiązują się ze swojego zadania? „Im więcej czasu mija od wdrożenia w przedsiębiorstwie zintegrowanego systemu informatycznego, tym bardziej rozwiązania biznesowe oddalają się od tego, co można osiągnąć przy pomocy nowszych technologii IT. Postęp w tej dziedzinie jest ogromny i pracownicy w firmie, mający wiele zadań, nie są w stanie na bieżąco śledzić nowych rozwiązań” – komentuje Zenon Parol, menedżer HADATAP. Jego opinie potwierdza odpowiedź menedżerów na pytanie ankiety o rolę systemów IT. Niemal wszyscy odpowiedzieli, że są użyteczne pod warunkiem, że systematycznie unowocześnia się je lub wymienia na bardziej odpowiadające biznesowi.

Na pytanie szczegółowe, jakie są najistotniejsze przyczyny strat, opóźnień i błędów w procesie produkcyjnym aż 80% respondentów wskazało brak współpracy w łańcuchu dostaw, 73% – niedoskonałość systemu planowania produkcji, a 60% opóźnienia w pozyskiwaniu istotnych informacji. Z praktyki najlepszych firm wynika, że eliminacja strat, opóźnień i błędów powinna być pierwszym działaniem usprawniającym funkcjonowanie firmy. Przeważnie daje to od razu znakomite rezultaty, a także jest punktem wyjścia do bardziej wyrafinowanych projektów doskonalenia i podnoszenia efektywności działania firmy.

Rozkład odpowiedzi w poszczególnych pytaniach wskazuje, że prezesi i dyrektorzy generalni analizują pracę firmy, a więc pracę ludzi, w kategoriach skutku i wyniku, natomiast dyrektorzy operacyjni częściej widzą proces i jego niedoskonałości. Większy potencjał jest w podejściu procesowym, ponieważ pracownicy uczestniczący w procesie mają realną możliwość zmieniania go, doskonalenia. Muszą jednak mieć do tego motywację i akceptację zwierzchników oraz poznać techniki ulepszania procesów. Gromadzeniem wiedzy o biznesie i procesach powinni zajmować się pracownicy w firmie, ale wiedzę o metodykach, rozwiązaniach, narzędziach i trendach najlepiej kupić od zewnętrznych dostawców.

Dyrektor informatyki uczestniczący w badaniu generalnie zgadzają się w swoich opiniach z dyrektorami biznesowymi, jednak widać pewne charakterystyczne różnice. Po pierwsze, są bliżej procesów, więc widzą, że negatywne wyniki firmy, np. dotyczące zdobywania rynku czy niestabilna jakość produktów wynikają właśnie z niedoskonałości w sterowaniu procesem lub w ustawieniu procesu. Szefowie IT nie są związani z praktyką produkcyjną i w związku z tym bardziej przejmują się wyeksploatowanym parkiem maszynowych i przestarzałą technologią niż menedżerowie biznesowi nawykli do codziennych problemów z tego wynikających. Po drugie, szefowie biznesowi bardzo mocno akcentują znaczenie kwalifikacji kadry, zdobywanie utalentowanych pracowników i menedżerów. Są skłonni w to inwestować. Szefowie IT nie dostrzegają tych problemów, być może dlatego, że nie odczuwają niedoboru kompetencji wśród swoich podwładnych.

Wydaje się, że jedni drugich mogą twórczo zainspirować. Menedżerowie odpowiedzialni za wyniki powinni dostrzec, że poprawia się je umożliwiając ludziom dobrą pracę poprzez prawidłowe ustawienie procesu i sterowanie nim, a nie tylko przez presję na pracowników, aby zwiększali wysiłek. Menedżerowie IT natomiast – dobrze, jakby nabyli silniejszego nastawienia na wynik, zwłaszcza gdy podejmują wdrożenia rozwiązań wspomagających i upraszczających procesy biznesowe. Z dialogu między tymi dwiema grupami menedżerów mogą powstać bardzo skuteczne pomysły usprawniania firm.

Poniższe dwa zestawienia prezentują część wyników badania.

1. Jakie są najważniejsze zagrożenia czyhające na dobrze rozwijającą się firmę w czasach koniunktury, zagrożenia płynące z jej organizacji i systemu zarządzania?

47%    a. silna koncentracja na zdobywaniu udziałów w rynku i zwiększaniu sprzedaży, lekceważenie wewnętrznych usprawnień
13%    b. rozdźwięk między rosnącym popytem a możliwością jego zaspokojenia w terminie
27%    c. lekceważenie jakości, gdyż „rynek i tak weźmie wszystko”
67%    d. zaniedbanie doskonalenia struktur i procesów wewnętrznych
33%    e. lekceważenie doskonalenia kwalifikacji kadry
40%    f. zaniechanie inwestycji w unowocześnianie technologii produkcyjnych
7%    g. spowolnienie rozwoju systemów wsparcia biznesu
20%    h. niska motywacja do innowacyjności
13%    i. brak umiejętności lub niechęć do ujawniania strat i błędów
7%    j. wewnętrzne słabości, które nie pozwalają wykorzystać wszystkich okazji rynkowych

2. W co najlepiej inwestować podczas dobrej koniunktury?

20%    a. marketing i promocję
20%    b. infrastrukturę i kadrę handlową
20%    c. nowe produkty
53%    d. modernizację zasobów produkcyjnych
27%    e. systemy informatyczne wspierające biznes
60%    f. usprawnianie procesów biznesowych
60%    g. badania i rozwój
20%    h. pozyskanie dobrej kadry menedżerskiej i specjalistów
13%    i. szkolenie

Pojęcie procesu biznesowego na dobre zadomowiło się w biznesowej rzeczywistości i nikogo nie dziwią inicjatywy, często bardzo kosztowne, mające na celu opisanie czy usprawnianie procesów biznesowych. Niestety, wraz z popularyzacją podejścia procesowego do zarządzania organizacją, pojęcie procesu biznesowego uległo rozmyciu.

Artur Kasprzyk

Procesem biznesowym nazywa się całe obszary funkcjonowania organizacji, takie jak marketing czy sprzedaż, procesem biznesowym jest zarazem dużo mniejszy obszar działania, taki jak obsługa zamówienia; równie często procesem biznesowym nazywa się opis działań realizowanych przez narzędzia informatyczne klasy BPMS. Z drugiej strony opis procesów biznesowych jest najczęściej wykonywany na poziomie „ogólnej” koncepcji działania, bardzo często z łamaniem zasad języka wykorzystywanego do utworzenia opisu. Z przykrością należy stwierdzić, iż w dużym stopniu do takiego stanu rzeczy przyczyniają się projekty związane z pozyskaniem normy ISO, w ramach których firmy audytorskie akceptują niepoprawne opisy, sankcjonując tym samym brak precyzji i niejednoznaczność. Na skutek tego  rodzi się przekonanie, iż opis procesów służy głównie pozyskaniu normy ISO oraz jakiejś wąskiej grupie ludzi, która jest za nie odpowiedzialna. Podawana jest także w wątpliwość sama idea procesowości, poprzez podniesienie prostych, ale jakże trafnych argumentów w stylu „skoro tak prosto działamy, jak nam tutaj zaprezentowano, to skąd się bierze tylu sprinterów w garniturach na korytarzach firmy?”. Codzienne życie organizacji jest niewrażliwe na wyniki certyfikacji.

Splot tych czynników powoduje, iż z uruchamianych projektów wdrażania podejścia procesowego do zarządzania organizacją niewiele kończy się sukcesem biznesowym.

Niniejszy artykuł ma na celu zaprezentowanie obecnego stanu adaptacji podejścia procesowego i zagrożeń, jakie przy tym występują oraz wskazanie tych kierunków jego rozwoju, które stwarzają nadzieję na osiągnięcie większych korzyści z  inwestycji w projekty wdrażania procesowych metod zarządzania. Z uwagi na objętość materiału, w artykule nie zostanie zaprezentowane powiązanie pomiędzy mapami strategii a modelem procesowym organizacji.

Obecny etap adaptacji podejścia procesowego

Z punktu widzenia dostępnych technik opisu procesów wydaje się, iż w Polsce1 większość projektów jest realizowana z wykorzystaniem podejścia opartego na karcie przepływu procesu (flowchart), popularnego na rynku od kilkudziesięciu lat. Omawianą technikę opisu można z powodzeniem stosować w wielu obszarach funkcjonowania organizacji, w których „liniowość” jest naturalną cechą prowadzonych działań. Typowymi przykładami są liniowe procesy produkcyjne, procesy administracyjne czy też procesy w organizacjach podlegających ścisłym rygorom prawnym (np. w bankach). Zgodnie z tym podejściem w dalszych fazach wdrażania zmian w organizacji procesy są uzupełniane procedurami postępowania uwzględniającymi reguły biznesowe zidentyfikowane podczas opisu. Podstawowym ograniczeniem tego podejścia jest konieczność opisania wszystkich dozwolonych sekwencji działań oraz zbyt skromne możliwości reprezentacji działań uruchamianych współbieżnie (w tym także innych procesów) w zależności od stanu realizacji danego procesu. Słabości te czynią metodę mało użyteczną w sytuacjach, w których nie sposób przewidzieć wszystkich możliwych konfiguracji działań. Typowa sytuacja tego rodzaju to działania sprzedażowe, w trakcie których kolejne czynności są na bieżąco wybierane – spośród  określonego dozwolonego zbioru – na podstawie stanu realizacji negocjacji handlowych.

Przykładem języka modelowania omawianego typu jest mocno już okrzepła i popularna metoda Rummlera-Brache’a. Inny przykład to notacje konstruowane ad hoc na potrzeby poszczególnych projektów w oparciu o podstawowe symbole przepływu pracy dostępne w popularnym pakiecie Visio.

W praktyce opis oparty na flowchart okazuje się często zbyt uproszczony, nie odzwierciedla złożoności i różnorodności współczesnych procesów biznesowych. Trudno jest na podstawie takiego opisu sformułować specyfikację oczekiwanego wsparcia działań organizacji technologiami informatycznymi – zestawy wymagań są bądź zbyt ogólne, by mogły stanowić podstawę do świadomego ich zatwierdzenia, bądź zawierają zbyt wielką mnogość oczekiwań, znacznie ponad rzeczywiste zapotrzebowanie. W efekcie może to prowadzić do budowy lub zakupu systemów, z których spora część funkcjonalności będzie niewykorzystana, a brakować będzie kluczowych funkcjonalności, które nie zostały zidentyfikowane z powodu zbyt ogólnego opisu zasad działania organizacji.

Informatyka skupia swoje zainteresowanie na procesach biznesowych gdyż potrzebuje precyzyjnych i kompletnych specyfikacji wymagań biznesu wobec narzędzi, które biznesowi udostępnia – narzędzi wspomagających zarządzanie procesami poprzez integrowanie działania systemów informatycznych oraz działania pracowników w ramach jednego wspólnego środowiska pracy. O wpływie tychże narzędzi na model procesowy organizacji traktuje następny rozdział.

BPMS

Wraz z falą fascynacji architekturą zorientowaną na usługi (Service Oriented Architecture, SOA) rośnie zainteresowanie tzw. systemami zarządzania procesami biznesowymi, określanymi akronimem BPMS. Są to systemy informatyczne, których zadaniem jest definiowanie procesów biznesowych oraz umożliwienie ich późniejszego nadzoru. Lecz dla potrzeb systemu informatycznego procesy muszą być opisane w sposób jednoznaczny i dokładnie odpowiadać rzeczywistości. Zestawienie tego wymogu z dotychczasową praktyką zarządzania, dopuszczającą pewien margines dowolności (jak w przypadku opisanej wyżej metodologii wykorzystującej flowcharts) rodzi zasadniczą wątpliwość. Z jednej bowiem strony narzucenie ścisłych wymogów formalnych na opis procesu daje spore szanse na usprawnienie pracy, ale z drugiej strony spore zagrożenie jej paraliżu, a co najmniej odczuwalnych niedogodności. Moim zdaniem jedynym powodem tej kontrowersji jest stale jeszcze otwarte pytanie o możliwość oddania rzeczywistości przy pomocy dostępnego języka modelowania.

Zakładając umiejętność precyzyjnego modelowania, o tym, czy ostatecznie projekt zaowocuje sukcesem czy porażką w dużej mierze zadecyduje, czy przyjęty przez narzędzie paradygmat modelowania umożliwia odzwierciedlenie rzeczywistości. Jeżeli modelujemy przy pomocy np. coraz popularniejszego języka BPMN, wówczas jesteśmy w stanie perfekcyjnie oddać wszystkie wariancje w ramach procesów przemysłowych. Aczkolwiek, istnieje ryzyko pojawienia się problemów, jeśli naszym zadaniem będzie wsparcie narzędziami do zarządzania procesami działów sprzedaży czy marketingu. Przed jeszcze trudniejszym zadaniem staniemy w przypadku firm produkujących oprogramowanie, w których jedne procesy są definiowane ad hoc w ramach realizacji innych procesów.

Rozwiązania komplementarne

W sukurs obecnym już na rynku metodom modelowania i zarządzania procesami przychodzą nowe podejścia, uzupełniające dotychczas stosowane techniki i narzędzia. Część z nich już została uznana na rynkach bardziej dojrzałych i chętniej adaptujących nowe trendy, część z nich dopiero zaczyna „nabierać rumieńców”.

Jedną z technik modelowania struktur procesowych, pozwalającą uczynić z monolitycznych konstrukcji swobodnie powiązane fragmenty działań, jest Event-Driven Architecture (EDA). Według tej koncepcji, której stosowanie jest niesłusznie zawężane jedynie do rozwiązywania problemów informatycznych, opisywany organizm (bez względu na to, czy jest to proces biznesowy, czy też działanie wewnątrz infrastruktury IT, np. opartej na SOA) składa się z wielu autonomicznych składowych, komunikujących się wzajemnie w sposób asynchroniczny poprzez wysyłanie i odbieranie zdarzeń. Koncepcja taka zbliża zdecydowanie tworzony model procesów biznesowych do realiów funkcjonowania organizacji, w której jedne działania (np. obsługa zgłoszenia reklamacyjnego) komunikują się z innymi obszarami funkcjonowania organizacji (np. obsługa usterki) poprzez przesłanie komunikatów (np. e-mail). Organizacja jest wówczas postrzegana jako zestaw „uruchomionych” drobnoziarnistych działań, które w odpowiednich momentach wysyłają do organizacyjnego uniwersum sygnały o osiągnięciu określonego stanu, w efekcie czego może dojść do uruchomienia, zakończenia czy też wybudzenia innych działań. Oczywiście, można zarzucić pomysłowi, iż miast wielkich bloków działań („na których wszystko widać”), uzyskujemy dużo większą liczbę działań drobniejszych, powiązanych wzajemnie pajęczyną niejawnych zależności. Ale czy nie tak wyglądają nasze organizacje?

Innym kierunkiem rozwoju podejścia procesowego jest koncepcja zarządzania sprawami (case management, case handling), według której w ramach obsługi sprawy (instancji procesu), zespół przypisany do jego realizacji współdzieli informacje powstające w ramach obsługi tej sprawy, a działania (ciągi akcji) są podejmowane w momencie, gdy spełnione są wymagane do tego warunki (np. informacja opisująca osiągnęła określony stan). Osoba pracująca nad sprawą decyduje (a nie „wnioskuje” z przygotowanego wcześniej opisu) o kolejnym działaniu, jakie ma zostać wykonane. W przeciwieństwie do wcześniej wymienionych technik, podejście zakłada, iż w ramach obsługi sprawy mogą się pojawić dane (dokumenty itp.), których nie przewidziano w opisie procesu (w „tradycyjnym” podejściu procesowym projektant procesu określa jakie dane będą przetwarzane). Przykładem obszarów zastosowań tego typu podejść mogą być sprawy sądowe, czy zgłoszenia szkód w firmach ubezpieczeniowych.

Kolejne podejście, nazywane zarządzaniem ludzkimi interakcjami (human interaction management, HIM) uwzględnia jeszcze większą „nieprzewidywalność” działań w ramach opisu procesów. Zgodnie z teorią HIM, ludzie wykonujący pracę umysłową pracują według określonych wzorców postępowania. Przez większą część czasu wykonywana praca, mogąca trwać tygodnie, miesiące czy lata, może nie przynosić wymiernych efektów, jakich oczekuje się od procesu, co nie oznacza, iż proces nie jest realizowany. Podejście zakłada bowiem, iż kluczową rzeczą – z punktu widzenia procesów opierających się na pracy umysłowej – jest zdefiniowanie interakcji pomiędzy rolami (rozumianymi w znaczeniu zdefiniowanym w technice RAD2) biorącymi udział w realizacji procesów oraz wskazanie warunków wejściowych pozwalających na uruchomienie danego działania i wyjściowych pozwalających uznać je za zakończone. Przy takim podejściu, realizowany proces jest postrzegany jako zbiór wykonywanych „atomowych” działań, a każda z ról biorących udział w procesie postrzega go jako zestaw działań, które powinna w danym momencie wykonywać. Kolejną, cechą charakterystyczną dla omawianego podejścia jest założenie, iż w ramach ról biorących udział w realizacji konkretnego procesu istnieje wystarczająca kompetencja oraz organizacyjne umocowanie, by móc zredefiniować proces w trakcie jego wykonywania (można uznać, iż początkowo każda instancja procesu jest uruchamiana zgodnie z ustalonym wzorcem, ale w toku realizacji prac kształt instancji procesu może ulec zmianie). Przykładem tego typu procesów są działania związane z opracowywaniem kampanii marketingowej czy budową systemów informatycznych, w których ciężko a priori przewidzieć działania, które będą wykonywane w celu doprowadzenia  przedsięwzięcia do końca.

Podsumowanie

Obserwacja działań podejmowanych w naszym kraju w obszarze modelowania procesów biznesowych nie napawa optymizmem. Spośród sporej liczby projektów, które mieliśmy okazję audytować, czy po prostu przyglądać się im, duża część (50-60%) była realizowana bez jasnego i przemyślanego pomysłu, nie mówiąc już o systematycznej metodyce. To przeraża. Szczególnie niedobrze jest w projektach, w których modele procesów biznesowych tworzone są  przez zespoły pracujące nad wdrożeniem rozwiązania informatycznego. Pomijając ewentualny wpływ kwestii etycznych (konflikt interesów: albo poprawnie albo tak, aby model procesów pasował do systemu, który akurat mamy), w wielu przypadkach powodem takiego stanu rzeczy jest najzwyczajniej w świecie brak odpowiednich kompetencji w zespole realizującym projekt. Na to nakłada się bardzo często brak wystarczającej wiedzy o sposobach modelowania procesów oraz o korzyściach z tego płynących po stronie zamawiającej. W efekcie powstają modele procesów, których nikt nie czyta, do których nikt się nie stosuje i których nikt nie utrzymuje. Opisy procesów na potrzeby norm ISO, które pracownicy „wkuwają” na dzień przed wizytą audytora, by dzień później o nich zapomnieć. Opisy procesów rozpoczęte na początku uruchomienia projektu wdrożenia systemu informatycznego i porzucone gdzieś w trakcie ich realizacji, gdyż „nie było już czasu”. I co gorsza, ogólne przekonanie, iż modelowanie procesów niewiele jest warte, bo nie ma z tego żadnych biznesowych korzyści, a za to całe mnóstwo problemów.

No ale czemu się dziwić? Żyjemy w kraju, w którym występuje chyba ewenement w skali światowej – wykładowcy na konferencjach „branżowych” muszą zapłacić za możliwość wystąpienia! Skoro tak się sprawa ma, to inwestycja musi się zwrócić. Toteż uczestniczymy w imprezie bardziej propagandowej niż merytorycznej i otrzymujemy taką wiedzę, na otrzymanie jakiej zgodziliśmy się. Kolejna obserwacja – z jakiś nieznanych powodów, jesteśmy bardzo wrażliwi na brak wdrożeń referencyjnych w Polsce. Bardzo często oceniając dojrzałość rozwiązań nie ufamy temu, iż na świecie od lat pracuje się jakimiś metodami, czy wykorzystuje określone narzędzia. A przecież dość oczywistym jest fakt, iż w gospodarkach znajdujących się na wyższym poziomie rozwoju, w których dysponuje się większymi budżetami, ale też i konkurencja jest ostrzejsza, szybciej próbuje się adaptować nowe technologie. Czekamy na sukcesy krajowych wdrożeń owych sprawdzonych już na świecie podejść i narzędzi, a tymczasem świat ucieka nam do przodu. Na własne życzenie czekamy, aż ktoś nas wyprzedzi.

Sprawdzajmy więc to, co jest dostępne w ramach szeroko pojętego podejścia procesowego. Dostępne na świecie, a nie tylko w okolicznych województwach. Oceniajmy dostępne rozwiązania i nie bójmy się eksperymentować; wybierajmy konferencje, które nie noszą znamion wydarzenia marketingowego (często marka organizatora wskazuje na charakter konferencji); czytajmy uznaną literaturę branżową i na niej starajmy się wyrabiać swoją opinię. Przy takim podejściu do wdrażania nowych myśli i technologii mamy szansę na rzeczywiste usprawnienia i czerpanie garściami korzyści, jakie daje dobrze wdrożony pomysł. A mamy z czego wybierać, co starałem się pokazać powyżej.

—

Marek Szelągowski

Druga część niniejszego opracowania została opublikowana w tym samym dziale.

Szybkość zmian zachodzących w otoczeniu biznesu, ale także ich jakościowy charakter i nieprzewidywalność powodują, że nie są już wystarczające podstawowe zasady zarządzania oparte na specjalizacji ludzi i komórek organizacyjnych oraz na odgórnym lub ręcznym zarządzaniu [Po5]. Współczesne zarządzanie stanęło bowiem przed problemem: co zrobić, aby lepiej od konkurencji – szybciej i taniej – sprostać indywidualizacji potrzeb klientów, w warunkach zmiennych i w znacznej części nieprzewidywalnych? W głównym nurcie poszukiwań właściwiej odpowiedzi znajdują się rozwiązania wykorzystujące cały dynamizm, całą wiedzę i potencjał ludzki istniejący w przedsiębiorstwie. Cechy takiego nowego ładu organizacyjnego nie są jeszcze dokładnie znane, wiadomo jednak generalnie, że organizacje nowego typu będą “odchudzone”, o płaskiej strukturze, w większym stopniu oparte na pracy zespołów, elastyczne poprzez delegację uprawnień dla pracowników liniowych, nieustannie adaptujące swoje działanie do potrzeb i wymagań klientów.

W artykule zamierzam wykazać, że szanse powodzenia mają tylko koncepcje takiego przedsiębiorstwa, w którym zmiany organizacyjne czy rewolucje technologiczne są podporządkowane wykorzystaniu i rozwijaniu kapitału wiedzy istniejącego w przedsiębiorstwie. Najpierw postaram się opisać na czym polega odpowiedź na indywidualizację wymagań klienta w małej rodzinnej firmie, która akurat ten problem rozwiązuje z powodzeniem, chociaż nie osiąga szybkości procesu głównego ani oszczędności kosztów typowych dla przedsiębiorstwa dużego. Następnie spróbuję scharakteryzować główne bariery stojące na przeszkodzie elastyczności w przedsiębiorstwie dużym i zarządzanym konwencjonalnie. W dalszej części artykułu zarysuję koncepcję zarządzania w oparciu o dynamiczne procesy biznesowe, która w moim przekonaniu stanowi jedno z możliwych trafnych rozwiązań problemu indywidualizacji w dużym przedsiębiorstwie, zachowując zarazem wszystkie plusy wynikające ze skali działania i rozmiaru zasobów.

Jak funkcjonują małe, rodzinne firmy?

Problemów z adaptacją do zmieniających się coraz szybciej wymagań klienta oraz do ich coraz wyraźniejszej indywidualizacji nie mają małe, rodzinne firmy. Panuje w nich kultura pracy i odpowiedzialności podporządkowanej klientowi, z naturalną indywidualizacją działania dla znanego, konkretnego klienta. Indywidualizacja wymagań klientów, której nie może sprostać zdecydowana większość dużych firm, jest dla małych, często rodzinnych przedsiębiorstw od zawsze naturalna. Np. mały zakład krawiecki szyje każdy garnitur dokładnie na wymiar klienta, czego nie potrafi żaden z wielkich, globalnych kreatorów mody. Podobnie prywatny korepetytor dostosowuje szybkość i sposób nauki do możliwości każdego ucznia, czego nie potrafią żadne gminne szkoły zbiorcze, ani prywatne ani państwowe. Jeżeli jakieś indywidualne wymagania czy problemy tego wymagają, tworzony jest indywidualny plan nauki – proces jest dynamicznie dostosowywany do oczekiwań i możliwości klienta.

Przykład działania małego przedsiębiorstwa

Prześledzimy jak się to dzieje opierając się na przykładzie procesu, w którym mały zakład krawiecki realizuje zamówienie od indywidualnego klienta:

Proces „Pozyskania kontraktu”.

Krawiec musi umieć dowiedzieć się od klienta jakie są jego oczekiwania. Z oczywistych powodów ich przewidzenie nie jest możliwe. Czasami klient ma konkretne oczekiwania – zakupiony przez siebie materiał, czasem gotową formę albo przynajmniej fotografię oczekiwanego garnituru. Jednak zdecydowanie częściej jest to wiedza ukryta, której klient sam nie potrafi sformułować („garnitur ma być ładny”, tzn jaki?). Zadaniem wykonawcy jest więc przede wszystkim wydobycie, zweryfikowanie i potwierdzenie oczekiwań klienta. Wydobycie tej wiedzy jest możliwe tylko wtedy, gdy dostawca jest profesjonalistą, który wie o co i w jakiej kolejności pytać. Poszukując analogii z procesami znanymi gdzie indziej można powiedzieć, że potwierdzenie oczekiwań klienta jest odpowiednikiem sakramentalnego „ostatecznego potwierdzenia” w systemach internetowych. Zapisanie, obok wymiarów klienta, informacji o rodzaju klap w marynarce i o mankietach nogawek można uznać za odpowiednik kodyfikacji wiedzy ukrytej klienta i dzielenia się nią w dużych korporacjach.

Proces „Przygotowania produkcji”

często wiąże się z innowacyjnym wykorzystaniem posiadanej wiedzy fachowej. Takim wyszukaniem i dobraniem materiału, wykończeń, a nawet technologii łączenia materiałów (np. klejenia), aby spełnić oczekiwania klienta. Często angażowani są w ten proces nie tylko pracownicy zakładu, ale także zaprzyjaźnieni dostawcy, inne zakłady, a współcześnie także fachowcy „spotkani” w Internecie.

Proces „Produkcji”

zazwyczaj wymaga dostosowania do oczekiwań klienta przebiegu standardowego procesu realizacyjnego. W małej pracowni krawieckiej od złożoności zamówienia, ale także od terminu czy figury klienta, zależy sposób krojenia materiału (tzw. rozkrój), ilość przymiarek, dobór dodatków i sposób wykończenia. W przeciwieństwie do garniturów z wielkich standardowych kolekcji, w garniturze szytym przez krawca na indywidualne zamówienie, można np. ukryć nierówność ramion klienta. Mimo, że standardowy proces jest taki sam, różnice w szczegółach wynikające z uwzględnienia oczekiwań i możliwości klienta mogą być ogromne. Mimo braku formalnych procedur i modeli procesów (a może dlatego że ich nie ma?) każdy krawiec w małym zakładzie, może i potrafi dostosować swoją prace do wymagań konkretnego zamówienia. W sposób naturalny jest on odpowiedzialny za powierzony materiał oraz za sukces całego przedsięwzięcia. Równocześnie akceptuje nadzór, a w przypadku trudności prosi o wsparcie starszego pracownika czy też właściciela. W małych firmach jest niewyobrażalne, aby w odpowiedzi na taką prośbę, współpracownik czy właściciel odmówili przekazania swojej wiedzy lub wsparcia w dotarciu do potrzebnej wiedzy.

Proces „Obsługi gwarancyjnej”

jest całkowicie dostosowany do wymagań klienta i do nieprzewidywalnych zdarzeń losowych (np. rozdarcia, utraty guzików, …). Poza wynikiem finansowym, jedynym kryterium jego oceny jest podtrzymanie dobrych relacji w celu zbudowania lojalności klienta, która może znaleźć wyraz w następnym zamówieniu lub poleceniu usług kolejnym osobom.

W małej firmie wykonawca procesu (szewc, krawiec, szef małej budowy, …) widzi cały proces. Klient nie jest tak oddalony, ani anonimowy jak to zazwyczaj ma miejsce w dużym przedsiębiorstwie. Dzięki temu możliwa jest natychmiastowa, prosta weryfikacja wykonywanego procesu z oczekiwaniami klienta. Dlatego Business Process Reengineering w małych firmach nie jest potrzebny. One już są elastyczne i na bieżąco adaptują swoje procesy do wymagań klientów. Osoba lub mały zespół obsługujący klienta (wykonawcy procesu), bez ociężałości decyzyjnej wielkiej hierarchii organizacyjnej, zawsze pozyskiwały i wykorzystywały wiedzę w ramach procesów nakierowanych na indywidualnego klienta. W sposób naturalny rozwiązania sprawdzające się u jednego klienta są w małych firmach proponowane i weryfikowane oraz ulepszane w kontakcie z innymi klientami. Nie wymaga to oceny zarządów czy audytów przez sztaby doradców, bo najbardziej obiektywnym weryfikatorem jest sam klient! Nie wymaga to poprawiania i zatwierdzania zmian obowiązujących procedur, bo małe firmy funkcjonują dzięki operatywności i odpowiedzialności swoich pracowników, a nie dzięki certyfikowanym systemom. Powtórzmy to jeszcze raz: małe firmy istnieją i rozwijają się dzięki profesjonalizmowi i odpowiedzialności pracowników, dzięki umożliwieniu im samodzielnego działania i dzięki kulturze dzielenia się wiedzą.

Podstawowe problemy dużych organizacji

W przypadku małych firm, takich jak zakład krawiecki z powyższego przykładu, trudno mówić o jakichś formalnych procedurach czy systemach zarządzania wiedzą, dzięki którym wiedza zweryfikowana w kontakcie z klientem wraca do wykonawcy procesu oraz do innych pracowników przedsiębiorstwa. Pozyskiwanie i weryfikowanie wiedzy jest w nich w sposób nierozdzielny związane z podstawowymi procesami biznesowymi. Nie jako oddzielny system funkcjonujący sam dla siebie, ale jako część działań nakierowanych na spełnienie wymagań klienta. A w ilu dużych przedsiębiorstwach, posiadających nieraz bardzo rozbudowane systemy i certyfikaty, popełnia się wielokrotnie te same błędy? W ilu całymi latami funkcjonują procedury nieaktualne, błędne czy po prostu głupie? Ile razy firmy konsultingowe usprawiedliwiają dziesiątki stron raportów zadrukowanych „mądrościami” nie na temat, słowami: „taką mamy procedurę”?

Przed 5 laty w jednej z firm budowlanych wdrażano system workflow zgodny z ISO9000. Przygotowano szczegółowe procedury i taksonomie obejmujące ponad 800 możliwych sytuacji i kategorii. Celem było zestandaryzowanie jak największej części, a docelowo całej działalności przedsiębiorstwa. Lecz mimo wielkiej szczegółowości nie oddawało to konkretnych sytuacji występujących w różnych projektach budowlanych prowadzonych dla różnych inwestorów. W praktyce taksonomia okazała się nie wsparciem, lecz dodatkiem utrudniającym bieżącą pracę. W efekcie pracownicy potraktowali system jako zbędny obowiązek i większość wpisów do systemu opatrzone była kategorią „inne”. Prawie wszystkie wpisy wprowadzano po zakończeniu prac, kiedy znany był już rezultat prowadzonego procesu. W zamyśle projektantów systemu wpisy miały oddawać indywidualną specyfikę prowadzonych projektów, aby można było wykorzystać je jako źródło wiedzy przy prowadzeniu podobnych inwestycji W praktyce znacznie częściej służyły do manipulacji np. do tworzenia post factum uzasadnień dla opóźnień czy kłopotów jakościowych. Rozwiązanie wprowadzone odgórnie, bez powiązania z codzienną pracą, nie ułatwiło ani pracy ani kontroli pracy, nie zapewniło przepływu rzetelnej wiedzy o doświadczeniach wynikających z wykonanej pracy. Przykład ten pokazuje 3 podstawowe problemy dużych organizacji:

Działania nie łączą się w płynny proces

Funkcjonalna struktura współczesnych organizacji stworzona została w celu polepszenia kontroli i lepszego wykorzystania walorów specjalizacji pracy. Równocześnie jednak bardzo często prowadzi ona do zagubienia podstawowego celu działania przedsiębiorstwa, którym jest zaspokajanie potrzeb klienta. Granice funkcjonalnych jednostek organizacyjnych powodują poszatkowanie procesu podstawowego, który ma tworzyć wartość dla klienta, na nie łączące się ze sobą, odrębne części. Optymalizacja, a właściwie suboptymalizacja procesów w ramach takich struktur może łatwo prowadzić do realizacji celów poszczególnych jednostek organizacyjnych sprzecznych z celami procesu podstawowego nakierowanego na klienta. W ten sposób w jednym z obserwowanych przeze mnie przedsiębiorstw dział finansowy tak usilnie realizował swój cel, polegający na uzyskaniu jak największych zysków z lokat i innych instrumentów finansowych, że zaprzestał terminowych płatności dla dostawców, co doprowadziło do zatrzymania realizacji jednego z kluczowych kontraktów!

Jest to problem dostrzegany od dawna. Obecnie powszechnie podejmowane są próby jego rozwiązania poprzez wdrażanie zarządzania procesowego.

Nienadążanie z adaptacją do zmian wymagań klientów i otoczenia

Przedsiębiorstwo zorganizowane hierarchicznie nie jest w stanie zidentyfikować wiedzy posiadanej oraz pozyskiwanej z kontaktów z klientami, czy szerzej – z rynku. Spowodowane jest to dążeniem kierownictw przedsiębiorstw do rozciągnięcia na zarządzanie wiedzą ścisłej kontroli, analogicznej jak np. na zarządzanie finansami. W efekcie zamiast wiedza przepływa przez hierarchiczne meandry przedsiębiorstwa ulegając zniekształceniu lub w ogóle zagubieniu! Skutkiem jest znaczące spowolnienie reakcji przedsiębiorstwa na zmiany otoczenia. Nagminnie powtarza się te same błędy, forsując działania i rozwiązania zgodne z poglądami kierownictwa, wielokrotnie ponosi się trud i koszty na wypracowywanie rozwiązań już istniejących, lecz nie znajdujących uznania w oczach decydentów. Równocześnie nie dostrzega się albo ignoruje istotne szanse na wyprzedzenie konkurencji tylko dlatego, że nie przewidywały ich procedury lub formalnie zatwierdzone strategie, a wykonawcy procesów nie mieli dostatecznej samodzielności aby spróbować wykorzystać wyłaniające się szanse. W ten sposób zarząd jednej z nieistniejących już firm budowlanych zlekceważył 10 lat temu zgłaszaną przez kierowników kontraktów szansę specjalizacji w dającej doskonałe wyniki finansowe budowie małych basenów pływackich. Kiedy po 2 latach bardzo wyraźnie wzrosła liczba budowanych basenów, próbowano poprawić strategię i powrócić do tego pomysłu, lecz okazało się że szansa przepadła i jest już inna firma powszechnie uważana za specjalizującą się w takich inwestycjach.

Jest to problem, który został dostrzeżony w ostatnich latach. Próbą jego rozwiązania jest m. in. wdrażanie zarządzania wiedzą przez wspólnoty praktyków (community of practice).

Niezdolność do indywidualizacji procesów

Duże organizacje wdrażają procedury, instrukcje, przepisy wewnętrzne, uzyskują certyfikaty ISO zapewniające pełną i stale kontrolowaną powtarzalność procesów. Jednak na skutek tego tracą zdolność do szybkich zmian, nie mówiąc nawet o reakcji na indywidualne potrzeby klientów! Przecież każda zmian szczegółowej procedury wymaga decyzji Zarządu lub co najmniej grupy kluczowych dyrektorów. Nietrudno wyobrazić sobie, co dzieje się w sytuacji, gdy w związku z oczekiwaniami klientów niezbędne jest dokonanie zmian wzajemnie się wykluczających! Szczegółowe procedury czy modele procesów biznesowych standaryzujące działanie przedsiębiorstwa w zasadzie uniemożliwiają dostosowanie procesów do wymagań klienta, niezbędne w takich branżach jak budownictwo, konsulting, przemysł stoczniowy, a coraz częściej także w handlu, telekomunikacji, informatyce itp. A przecież już teraz np. współczesne banki internetowe są zmuszone do konkurencji na rynku indywidualnego klienta, podobnie jak dostawcy przeglądarek internetowych. Przykłady można mnożyć.

Jest to nowy problem, coraz wyraźniej występujący w ostatnich latach. Próbą jego rozwiązania jest dynamiczne zarządzanie procesami biznesowymi, które zostanie przedstawione w dalszej części artykułu.

Dynamiczne zarządzanie procesami biznesowymi

W normie ISO 9000:2000 procesowe podejście do zarządzania przedsiębiorstwem osiągnęło status unormowanych działań podlegających certyfikacji. Stało się tak dzięki dostrzeżeniu i docenieniu procesowej natury związku przedsiębiorstwa z klientem. Dlatego już teraz każda organizacja, która ma ambicję prosperować w XXI wieku, musi przejść swoistą terapię, której istotą jest koncentrowanie się na procesach widzianych z perspektywy klienta i partnerów biznesowych, a nie z perspektywy tradycyjnej hierarchii organizacyjnej [H99]. W praktyce oznacza to m. in. konieczność przełamania barier między jednostkami organizacyjnymi.

Skąd więc problemy przedsiębiorstw, nawet tych które wdrożyły zarządzanie procesowe zgodnie z normą ISO9000:2000 i uzyskały potwierdzający to certyfikat? Skąd liczne żarty z procedur i instrukcji „opisujących wszystko, w tym także sposób użycia papieru toaletowego i włączania wtyczek do kontaktu”? Może problemem jest właśnie dążenie do skrupulatnego wypełniania procedur? Do opisania i ciągłej „optymalizacji przez standaryzację” jak największej liczby procesów? Według zasady, że im więcej procedur tym lepiej, bo od strony formalnej pozwalają one uwolnić przedsiębiorstwo od ryzyka, a kierowników i wykonawców procesów od myślenia i odpowiedzialności! Takie podejście prowadzi do dwóch zagrożeń zabójczych dla przedsiębiorstwa: do zahamowania innowacyjności na skutek ograniczeń narzucanych przez procedury; odgrywają przy tym rolę 2 wzmacniające się czynniki:

• opóźnienia wprowadzane przez biurokratyczne procedowanie zmian w zatwierdzonych mapach procesów oraz ograniczenia poglądami decydentów zazwyczaj nie mających bezpośredniego kontaktu z realizacją pracy;
• do „uśrednienia” procesów, przybierających postać modelową, zaprojektowaną z myślą o spełnianiu wymagań średniego statystycznego klienta, czyli nikogo.

Korzyści z wdrożenia tradycyjnego zarządzania procesowego będą niweczone przez omawiane zagrożenia tym szybciej, im większe będzie tempo zmian otoczenia konkurencyjnego i technologii. W czasach kiedy konkurencję dzieli od nas tylko „jedno kliknięcie”[So4], liczy się szybkość, z jaką jesteśmy w stanie wykorzystać informację i zastosować wiedzę w celu dostosowania kluczowych procesów biznesowych do wymagań indywidualnych klientów. Indywidualizacja wymagań klientów wymaga indywidualizacji procesów biznesowych przedsiębiorstwa. Przewaga innowacyjności i szybkości adaptacji małych firm nad dużymi, nawet międzynarodowymi koncernami wyraźnie pokazuje, że kluczem do sukcesu staje się nie „optymalny proces biznesowy”, ale umiejętność dynamicznego kształtowania procesów biznesowych zgodnie z wymaganiami klienta.

Przypisy

[P05] Piotr Płoszajski, „Wstęp:10 lat w wieku nieciągłości” w: „Przerażony kameleon. Eseje o przyszłości zarządzania”, Płoszajski P. (red.), Fundacja Rozwoju Edukacji Menedżerskiej SGH, Warszawa 2005, www.e-mentor.edu.pl/biblioteka/kameleon.pdf, dnia 31.03.2007, s. 10.

[H99] Michael Hammer, „Reinżynieria i jej następstwa – jak organizacje skoncentrowane na procesach zmieniają naszą pracę i nasze życie” („Beyond Reengineering. How the Process-Centered Organization is Changing our Work and our Lives”), Wydawnictwo Naukowe PWN, Warszawa 1999, s. 11.

[S04] Hubert Salik, „Google zadebiutowało na giełdzie”, Gazeta Wyborcza, 20.08.2004, serwisy.gazeta.pl/wyborcza/1,34513,2238826.html, dnia 20.08.2004. („Z wyszukiwarkami jest tak, że wystarczy jedno kliknięcie, by skorzystać z innej. A jednak ludzie wybierają naszą. Bo chcą – powiedzieli Page i Brin”).

—

Seria dyskusji pod wspólnym hasłem „Konteksty outsourcingu” rozpoczęła się przed długim majowym weekendem (2006 r.). W spotkaniu uczestniczyli menedżerowie z różnych sektorów: od energetyki po media, a debata dotyczyła głównie trzech tematów: stosunków dostawca-odbiorca usług outsourcingowych, zarządzania ryzykiem po obu stronach kontraktu i ekonomiki przedsięwzięcia. Spojrzenie na outsourcing z obu stron naprawdę inspiruje.

W projekcie „Konteksty outsourcingu” na warsztat wzięto procesy biznesowe, ale – tak jak się spodziewałem – dyskusja dotyka również „egzotycznych” obszarów i przykładów, np. outsourcingu pracy twórczej :-).

Kilka wniosków z pierwszych debat „Konteksty outsourcingu” w Salonie Business Dialog

Outsourcing jest to przekazanie firmie zewnętrznej aktywów materialnych i niematerialnych, z zamiarem czerpania większych pożytków z nowej kompozycji aktywów, traktowanych jako źródła wartości. W przedsięwzięciu outsourcowania szczególną wagę ma przepływ aktywów niematerialnych oraz pożytków z nich czerpanych.

Myślenie o outsourcingu należy zaczynać od odpowiedzi na pytanie, które nasze zasoby wykorzystujemy w 100%, a które nie. Zasoby nie w pełni wykorzystane są pierwszymi do zastanowienia, czy aby ich nie oddać firmie zewnętrznej w zarząd. Outsourcing jest metodą synchronizacji zasobów z potrzebami. W języku finansowym nazywa się to transformacją kosztów stałych w koszty zmienne. Potencjalnie transformacja ta może przyczynić się do redukcji rezerwy zasobów niezbędnej do elastycznego reagowania na zmiany warunków biznesu.

Jeśli firma chce być elastyczna na co dzień, chce szybko reagować na rynek, na zmiany, to musi pogodzić się z wyższymi kosztami, bo po prostu musi mieć nadwyżkę – w stosunku do aktualnych potrzeb – zasobów, aby ta reakcja była możliwa. Posiadanie zasobów jest więc kosztowne, ale daje elastyczność w reagowaniu na bieżące sytuacje. Outsourcing zmniejsza koszty posiadania, ale w niektórych przypadkach odbiera tak rozumianą elastyczność. Daje elastyczność innego rodzaju: środki, która firma wcześniej angażowała w administrację i rozwój obszaru obecnie outsourcowanego, może obecnie zaangażować w inne obszary, zwiększające jej konkurencyjność.

Outsourcing może pomóc w harmonijnym inwestowaniu, ustrzec przed przeinwestowaniem, skokowością pozyskiwania zasobów.

Outsourcing zmienia sposób zarządzania całą pozostałą działalnością po oddaniu w outsourcing pewnego obszaru działalności. Im większy i bardziej znaczący jest to obszar, tym większych zmian wymaga sposób zarządzania tym, co w firmie zostało. Co zatem musimy zmienić w zarządzaniu naszymi aktywami wewnętrznymi, jeśli określone aktywa oddamy w outsourcing? — oto kluczowe pytanie.

Tymczasem, jeśli decyzję o outsourcingu w danym obszarze, np. w IT podejmuje arbitralnie zarząd, to tak naprawdę na niższym szczeblu zarządzania, choćby szefa tego obszaru, nie ma merytorycznej dyskusji o tym, jakie są prawdziwe uwarunkowania outsourcingu, co trzeba zmienić w strukturach zarządzania, jak zagospodarować uwolnione zasoby. Przez ten brak debaty wiele potencjalnych korzyści z outsourcingu staje się utraconymi korzyściami, a firma w końcu centralizuje wcześniej wydzielone funkcje i procesy. Bez względu na tryb podejmowania decyzji o outsourcingu, muszą ją zrozumieć wszyscy menedżerowie, tylko wtedy wypracują nowe zasady.

Outsourcing może skutkować odcięciem od rynku, od wiedzy rynkowej w obszarze outsourcowanym. Trzeba stworzyć mechanizm zachowania takiej wiedzy – a także wiedzy merytorycznej – w firmie macierzystej.

Strony kontraktu outsourcingowego powinny mieć jednakową świadomość kosztów i ich struktury w obszarze, który jest przedmiotem kontraktu.

Kryteria dla podjęcia decyzji o outsourcingu, zarówno co do obszaru, jak i opłacalności, dają się sformułować w kategoriach bilansowania wartości: kosztów i tworzonych dzięki niemu korzyści.