Analiza pionowa (wertykalna):

• Dużo R: Czy osoba(y) może odpowiadać (realizować) na bieżąco za tak wiele zagadnień? Czy zadania mogą być rozdzielone pomiędzy różnych uczestników?
• Wszystkie pola wypełnione: proces jest uzależniony od danego uczestnika.
• Brak R lub A: Kto faktycznie wykonuje zadanie, kto powinien być odpowiedzialny? Czy ta osoba jest konieczna?
• Zbyt wiele A: Kto tak naprawdę jest ostatecznie odpowiedzialny? Czy mamy do czynienia z „one-man-show”? Dana osoba odpowiada za (zbyt) wiele spraw.
• Dużo I: Czy nie jest to ciągle spamowanie jednej osoby zbędnymi informacjami?
• Kwalifikacje (specyficzne wymagania dla realizacji kroku): Przyporządkuj zadanie odpowiednim zestawom umiejętności i osobom. Czy są dostępne, czy są zastępowalne?
• Ciąg czynności z wyłącznie A/R: Monodram, rozważyć połączenie w jedną całość (przedmiot instrukcji stanowiskowej, a nie mapy RACI).

Analiza pozioma (horyzontalna)

• Brak R: BŁĄD! Czy praca jest w ogóle wykonywana? Czy uczestnicy chcą wyłącznie decydować, konsultować lub być informowanymi? Nikt nie chce podjąć odpowiedzialności za realizację?
• Zbyt wiele R: Kto nie musi w tym uczestniczyć aktywnie? Może należy rozdzielić czynności na kilka?
• Brak A: BŁĄD! Musi być A. Odpowiedzialność powinna być przekazana na jak najniższy (ale odpowiedni) szczebel.
• Wiele A: BŁĄD! Kto dowodzi? Dodatkowe zamieszanie powstaje, ponieważ każda osoba z A ma inny obraz tego, jak to jest lub powinno być zrobione. A powinno być jedno i tylko jedno.
• Zbyt mało R: Czy na pewno opieramy się tylko na jednej osobie? Czy proces nie jest spowalniany przez to, że jedyny wykonawca ma na niego za mało czasu i realizuje go doraźnie?
• Dużo C: Czy wszystkie funkcjonalne role naprawdę muszą być konsultowane? Czy istnieją uzasadnione korzyści w konsultacji ze wszystkimi?
• Dużo I: Czy wszystkie role muszą być regularnie informowane czy też tylko w wyjątkowych okolicznościach? Czy masowe informowanie nie wynika z chęci zabezpieczenia się zamiast potrzeby biznesowej?
• Wszystkie pola wypełnione: Być może zbyt wiele osób jest zaangażowanych, zwykle zbyt wiele C i I.
• Identyczny zestaw ról w sąsiednich krokach: być może warto rozważyć połączenie kroków.

Czytaj też: Mapowanie ról i odpowiedzialności (RACI) oraz inne artykuły z cyklu MAP

Dla realizacji procesu nie jest istotne, kto (personalnie) realizuje jego działania, ani jakie stanowisko w organizacji zajmuje. Ważne jest, by te działania zostały wykonane prawidłowo (do czego wymagane są odpowiednie kompetencje) oraz terminowo. Uczestnicy, którzy poczuwają się do odpowiedzialności za realizację określonych działań oraz posiadają niezbędne umiejętności często będą w stanie zrealizować wspólnie proces pomimo słabej dokumentacji (lub jej braku) dotyczącej jego szczegółowego przebiegu.

Podstawowym narzędziem służącym do mapowania ról i odpowiedzialności jest macierz RACI. Nazwa jest skrótem od „Responsible – Accountable – Consult – Inform”. Zakłada ona przypisanie do poszczególnych kroków procesu uczestników, „aktorów”, pełniących różne rodzaje ról. Same kroki procesu powinny być wcześniej określone, choć podczas analizy RACI często lista kroków ulega zmianom. Nie ma też dużego znaczenia kolejność wymienionych kroków (choć ułożenie ich sekwencyjnie ułatwia analizę) ani ich przepływ (pętle w procesie, warunki itp.).

Kolumny typowej macierzy RACI określają role w procesie, a wiersze — kroki procesu. W polach macierzy umieszcza się rodzaj pełnionej roli. Podstawowy standard rodzajów ról jest następujący:

• A – Accountable (decydent, odpowiedzialny końcowy) to osoba odpowiedzialna za zatwierdzenie, będąca z reguły ostatnią osobą w danym ciągu działań (kroku) — dla każdego kroku musi istnieć jeden i dokładnie jeden uczestnik „A”;
• R – Responsible (wykonawca odpowiedzialny) to osoba odpowiedzialna za wykonanie określonych działań (problem, projekt) i ich rezultat (produkt), wspiera bezpośrednio osobę odpowiedzialną — w każdym kroku musi być co najmniej jeden „R” (może być razem z „A”);
• C – Consult (konsultowany) to osoba posiadająca wiedzę o przedmiocie procesu, która zwykle konsultuje i zatwierdza merytorycznie podejmowane przez powyższe osoby decyzje — występuje opcjonalnie;
• I – Inform (informowany) to osoba, która jest informowana o podejmowanych działaniach, lecz nie ma na nie wpływu — występuje opcjonalnie.

Metoda RACI posiada wiele wariantów. Najczęściej spotykane to rozszerzenia o typy ról dotyczące zatwierdzania, wsparcia i nadzoru lub użycie innych akronimów (np. wynikających z zastosowanego języka). Istotne jest konsekwentne zastosowanie jej w danej organizacji i precyzyjne określenie reguł.

Określenia poszczególnych ról niekoniecznie mają związek ze stanowiskami — powinny odzwierciedlać działanie w procesie, np. rola „Prawnik” zazwyczaj będzie obsadzana przez pracownika departamentu prawnego, ale może (jeśli odpowiednie regulacje tego nie zabraniają) pełnić ją dowolna osoba posiadająca do tego kompetencje (np. prezes, który z wykształcenia jest prawnikiem). Role mogą być czasami również zespołowe (np. cały dział otrzymujący pewną informację), ale w przypadku niejednoznaczności konieczna jest bardziej szczegółowa analiza.

Macierz RACI jest mapą ról i odpowiedzialności w procesie. Może być rozszerzana o inne rodzaje mapowania i metody, ale sama w sobie stanowi solidną podstawę do elementarnej standaryzacji procesu. Typowa macierz RACI wygląda następująco i jest uzupełniana (po analizie) o szczegóły realizacyjne poszczególnych kroków:

Czytaj też: Identyfikacja powiązań procesu (SIPOC) oraz inne artykuły z cyklu MAP

Odbiorcami wyjść procesu są klienci tego procesu, którymi mogą być podmioty zewnętrzne, jednostki bądź osoby wewnętrzne organizacji lub inne procesy. Nie istnieje — a przynajmniej nie powinno istnieć — takie wyjście z procesu (produkt procesu), które nie posiada swojego klienta (odbiorcy). Sytuacja taka oznacza zbędne działanie. Odbiorca (bądź odbiorcy) danego wyjścia jest podmiotem, który może i powinien określać wymagania i kryteria akceptacji wobec produktu procesu. Właściwa identyfikacja odbiorców i ich wymagań pozwala na całościowe określenie wymagań wobec procesu i eliminację wymagań nadmiarowych lub wzajemnie sprzecznych.

Dostawcami wejść procesu, analogicznie, mogą być klienci tego procesu, jednostki wewnętrzne i zewnętrzne oraz inne procesy. Każde wejście procesu powinno mieć określonego dostawcę odpowiedzialnego za jego dostarczanie. Jedno wejście może być zapewniane przez różnych dostawców (np. surowiec do produkcji może być pozyskany z magazynu bądź kupiony na rynku), ale sposób ich wyboru i postępowania powinien być określony. W stosunku do swoich dostawców proces pełni rolę klienta — określa wymagania i kryteria akceptacji wobec dostarczanych produktów (wejść procesu). Kompleksowa identyfikacja i analiza wejść procesu pozwala na ograniczenie ryzyka braku lub nieprawidłowej realizacji procesu (kontrolowane są wymagania zewnętrzne dla realizacji procesu).

Analizy powiązań procesu dokonuje się w oparciu o model SIPOC: Supplier-Input-Process-Output-Customer (z ang. Dostawca-Wejście-Proces-Wyjście-Klient), służącego do przedstawienia w formie graficznej (zazwyczaj w przypadku pracy warsztatowej, w odniesieniu do pojedynczych procesów), bądź tabelarycznej (sumarycznie, dla wielu procesów jednocześnie) inwentaryzacji powiązań i wymagań procesu z otoczeniem. Narzędzie to może być rozszerzone do formy SIRPORC, poprzez dodanie aspektu określenia wymagań (ang. Requirements) w odniesieniu do poszczególnych wejść i wyjść procesu. Analiza SIPOC pozwala na identyfikację wszystkich interesariuszy procesu, jak również na weryfikacje prawidłowości zdefiniowania samych procesów i ich produktów (np. w przypadku identyfikacji wymagań niemożliwych do spełnienia przez rozważany proces lub niemożliwych do oceny).

W odniesieniu do środowiska zewnętrznego SIPOC stanowi zmapowanie procesu lub grupy procesów na to środowisko, określając obustronne powiązania pomiędzy procesem i jego interesariuszami. Poprzez wyróżnienie interesariusz procesu będących innymi procesami (zarówno na wejściu, jak i na wyjściu) SIPOC jest podstawą do określenia architektury procesów — kompleksowej mapy wzajemnych powiązań procesów analizowanego obszaru organizacji.

Czytaj też: Wejścia i wyjścia: główne i pomocnicze oraz inne artykuły z cyklu MAP

Bez istnienia wejścia głównego proces nie powinien się rozpocząć. Może ono być w trakcie trwania procesu uzupełnione lub zmienione (jeśli nie powoduje to zmiany lub ponownego rozpoczęcia procesu).

Wejścia pomocnicze określają elementy, które powinny się pojawić na początku lub w trakcie trwania procesu. Mogą one być potrzebne warunkowo (w zależności od konkretnej sytuacji). Pochodzą od różnych podmiotów, w tym również od klienta procesu. Przykładami są: doprecyzowanie wymagań klienta (np. co do koloru towaru), informacja o fizycznej dostępności towaru, środki budżetowe na realizację produkcji, akceptacja transakcji „na drugą rękę”, zakup surowca itp.

Wejścia pomocnicze zazwyczaj są wywoływane (żądane) przez proces. Jeśli są dostępne wcześniej, korzystanie z nich rozpoczyna się dopiero podczas realizacji procesu. W przypadku braku wejścia pomocniczego może ono często zostać zastąpione przez inne (może to być przewidziane zarówno w standardzie działania danego procesu, jak i jako działanie doraźne).

Wyjściem głównym procesu jest jego produkt, wynik, realizujący potrzebę głównego klienta procesu. Nie musi być bezpośrednio do niego dostarczany, ale powinna być możliwa (przynajmniej potencjalnie) jego weryfikacja przez klienta. Może to być: dostarczony do klienta towar, wyprodukowana partia produkcyjna, zrealizowany przelew, zakup surowca itp.

Brak lub niezgodność z wymaganiami wyjścia głównego oznacza niepowodzenie realizacji danego przebiegu procesu.

Wyjścia pomocnicze określają elementy, które powinny lub mogą pojawić się w trakcie trwania procesu lub na jego końcu. Mogą być wynikiem doraźnej potrzeby lub stałego wymagania któregoś z interesariuszy procesu (niekoniecznie głównego klienta procesu). Przykładami są: dokumenty sprzedaży, raporty produkcyjne, dane w systemie ERP itp.

Wejścia pomocnicze są wymaganiem wobec procesu, natomiast ich dostarczenie nie warunkuje skuteczności realizacji celu procesu, choć może być obligatoryjne z przyczyn niezwiązanych z klientem procesu.

Czytaj też: Struktura zewnętrzna procesu oraz inne artykuły z cyklu MAP

Infrastruktura procesu jest zestawem stałych zasobów umożliwiających realizację procesu. Składają się na nią między innymi:

• zasoby osobowe (odpowiednia liczba pracowników),
• zasoby kompetencyjne (wyszkolenie i doświadczenie pracowników),
• narzędzia pracy,
• zasoby lokalowe (biura, hale, magazyny itp.),
• zasoby teleinformatyczne (oprogramowanie, komputery, łączność),
• dokumentacja (procedury, instrukcje, polityki, receptury itp.),
• surowce i materiały.

Zdarzenie inicjalne jest impulsem do rozpoczęcia realizacji procesu i nie stanowi odrębnego wejścia do procesu. Często jest powiązane z wejściem głównym (np. złożenie zamówienia), ale może też mieć charakter odrębny (np. akwizycja telefoniczna, uwolnienie zasobów na realizacje kolejnego zlecenia itp.). Zdarzenie inicjalne może mieć charakter terminu – jednorazowego lub cyklicznego – proces jest wtedy uruchamiany w określonym momencie (np. realizacja sprawozdawczości finansowej, naliczanie płac, kontrola bieżąca stanów magazynowych, przeprowadzenie audytu itp.).

Czytaj też: Poziomy dojrzałości procesowej oraz inne artykuły z cyklu MAP

• Poziom 1 – brak świadomości procesowej, standardów, powtarzalność jest przypadkowa. Dostarczanie wyrobu końcowego opiera się na kompetencjach i odpowiedzialności poszczególnych osób i może każdorazowo odbywać się inaczej.
• Poziom 2 – zauważalna powtarzalność (przynajmniej głównych) procesów, ale oparta głównie o przekazywaną informację i tradycję od mistrza do ucznia, nieliczne procedury mają charakter lokalny.
• Poziom 3 – powtarzalność zapewniona poprzez systematyczne, proceduralne ujęcie. Można określić cele poszczególnych procesów, natomiast nie ma systemu wskaźników pozwalających na zarządzanie procesem. Można już zauważyć świadomość istnienia systemu (podejścia) procesowego i pracy w nim. Prawidłowo skonstruowany system zarządzania oparty o ISO 9001 powinien umożliwić osiągnięcie tego poziomu.
• Poziom 4 – ustalone mierniki dla poszczególnych elementów składowych procesu (podprocesów, kroków, czynności), używane do bieżącego sterowania procesem i korekty na poziomie lokalnym. Nie ma natomiast pełnego zarządzania rozumianego jako kompleksowe doskonalenie.
• Poziom 5 – procesy modelowane i doskonalone (na każdym poziomie). Zarządzanie całą organizacją odbywa się przez system procesowy, będący jedynym systemem zarządzania.

• Znikomy ułamek organizacji osiąga poziom piąty, podobnie jak i czwarty, który czasem jest osiągany fragmentarycznie, w odniesieniu do wybranego obszaru firmy. Najczęściej organizacje (różnej wielkości) znajdują się pomiędzy poziomem drugim i trzecim. Należy też pamiętać o braku jednolitego i jednoznacznego narzędzia oceny, zaś samoocena kierownictwa jest zazwyczaj wyższa niż ocena średniej kadry zarządzającej.
• Powyższą (i podobne) skalę dojrzałości należy traktować umownie, jako orientacyjny punkt odniesienia oraz możliwość benchmarku, a nie jako jednoznaczną ocenę pozwalającą na podejmowanie szczegółowych decyzji i działań. Dla potrzeb mierzenia i badania postępów w rozwoju podejścia procesowego niezbędne jest opracowanie szeregu kryteriów do przeprowadzania szczegółowej oceny poziomu dojrzałości.

Czytaj też: Poziomy logiczne procesów oraz inne artykuły z cyklu MAP

Najczęściej można wyróżnić pięć następujących poziomów logicznych:

• Poziom 1. to obszary procesów, powiązanych tematycznie, ale nie operacyjnie, określane (zwłaszcza w stosunku do procesów głównych) procesami End-to-End (E2E, czyli obejmującymi całość relacji i działań z klientem procesu). Przykładem takiego obszaru mogą być procesy produkcyjne, HR-owe, zaopatrzenie czy relacje z klientami.
• Poziom 2. to grupy procesów, powiązane ze sobą celami na poziomie strategicznym, np. planowanie produkcji, produkcja niskoseryjna (dla procesów produkcyjnych) zatrudnianie i ruch pracowników, szkolenia i rozwój, rachuba płac (dla procesów personalnych), rozwój dostawców, zakupy (dla procesów zaopatrzenia), pozyskanie klienta, sprzedaż, obsługa posprzedażowa (dla procesów klienckich).
• Poziom 3. to właściwe procesy operacyjne, wynikające z potrzeby klienta procesu i w celu jej spełnienia dostarczające klientowi produkt procesu. Na tym poziomie należy określać powiązania i przepływy pomiędzy różnymi procesami. Przykłady: montaż wyrobu końcowego, rekrutacja pracownika, ocena roczna pracownicza, zakup produkcyjny, ocena roczna dostawców, obsługa zapytania klienta.
• Poziom 4. to podprocesy w ramach danego procesu. Mogą nie występować (proces składa się z jednego podprocesu), natomiast ułatwiają prezentację i zrozumienie procesu podzielonego na sekwencję działań. Dodatkowo każdy podproces może być analizowany i modelowany jak kompletny proces (ma początek i koniec, ustalony przebieg), natomiast w odniesieniu do klienta całego procesu i pełnego zrozumienia ma sens dopiero w zestawieniu w pozostałymi podprocesami. Podprocesy najczęściej stanowią podstawę do opisu w postaci odrębnych procedur. Przykłady: wyszukanie optymalnej oferty zakupowej, montaż obudowy, wyliczenie premii rocznej, fakturowanie sprzedaży.
• Poziom 5. to poszczególne zadania (czynności) w ramach procesu, opisane w postaci punktów procedur lub instrukcji stanowiskowych.

Czytaj też: Typologia procesów oraz inne artykuły z cyklu MAP

Abstrahując od literaturowych, często teoretycznych, klasyfikacji, jedna z najczęściej stosowanych jest prosty podział na procesy główne, zarządcze i pomocnicze:

• procesy zarządcze, które kierują działaniem systemu/firmy. Typowym przykładem może być proces planowania budżetu, budowa planu strategicznego, S&OP („sales and operational planning), zarządzanie biurem projektów (PMO);
• procesy operacyjne / biznesowe / główne, które stanowią istotę biznesu i są pierwotnym źródłem wartości dodanej, np. realizacja zamówienia, zakup surowców, wytwarzanie produktu, obsługa reklamacji, windykacja należności przeterminowanych, sprzedaż;
• procesy pomocnicze / wsparcia, który wspierają pozostałe procesy; można je podzielić na dwie podgrupy:
  • procesy wsparcia procesów głównych, np. marketing, logistyka, magazyny, fakturowanie itp.,
  • procesy wsparcia całej organizacji, takie jak finanse, HR, IT, administracja itp.

Nawet tak prosto określona klasyfikacja pozwala na podejmowanie decyzji o wyborze procesów do modelowania i zapewnienia kompletności architektury procesowej.

Jedną z najbardziej szczegółowo rozpisanych klasyfikacji procesów jest Model Klasyfikacji Procesów (Process Classification Framework) opracowany przez APQC (American Productivity Quality Center). Wprowadza on 12 kategorii procesów podzielonych na dwie grupy:

• procesy operacyjne
  • 1.0 – Opracowanie wizji i strategii
  • 2.0 – Rozwój i zarządzanie produktami i usługami
  • 3.0 – Marketing i sprzedaż produktów i usług
  • 4.0 – Zaopatrzenie, realizacja i dostawa produktów/usług
  • 5.0 – Zarządzanie obsługą klienta
• procesy wsparcia
  • 6.0 – Organizacja i zarządzanie kapitałem ludzkim
  • 7.0 – Zarządzanie technologią informatyczną
  • 8.0 – Zarządzanie zasobami finansowymi
  • 9.0 – Nabywanie, budowa i zarządzanie mieniem
  • 10.0 – Zarządzanie ochroną środowiska oraz bezpieczeństwem i higieną pracy
  • 11.0 – Zarządzanie relacjami zewnętrznymi
  • 12.0 – Zarządzanie wiedzą, doskonaleniem i zmianą

Na kolejnych poziomach jest zdefiniowanych 62 grupy procesów, uściślone w liście 265 procesów, a te do poziomu 797 działań. Każda firma musi (stosując ten model) wybrać elementy adekwatne do jej rzeczywistości. Przykład klasyfikacji szczegółowej:

Czytaj też: Projekt a proces oraz inne artykuły z cyklu MAP

Projekt stanowi więc swoistą mini-firmę „celową”, powołaną wewnątrz organizacji dla osiągnięcia konkretnego, specyficznego rezultatu.

• Główne cechy projektu to:
  • tymczasowość (ma określony POCZĄTEK i określony KONIEC),
  • dobiega końca, gdy osiągnie swoje CELE lub zostanie przerwany,
  • w jego wyniku powstaje unikalny PRODUKT (wyrób, usługa lub rezultat),
  • jest ZŁOŻONY i składa się z powiązanych ze sobą ZADAŃ,
  • jego realizacja wymaga zaangażowania ZESPOŁU (więcej niż jednej osoby),
  • jego realizację cechuje dużo większa NIEPEWNOŚĆ niż zwykłą działalność biznesową.
• Różnice i podobieństwa pomiędzy PROJEKTEM i PROCESEM:

• Polskie słowo „projekt” ma dwojakie znaczenie:
  • techniczne [odpowiadające angielskim słowom: „design” lub „draft”] — efekt pracy konstruktora, projektanta, twórcy, autora (projekt domu, projekt umowy) ,
  • zarządcze [od słów „project”, „project management”] — jednorazowe przedsięwzięcie, zarządzanie projektem.

Brak rozróżnienia w tłumaczeniu często powoduje nieporozumienia i próby stosowania narzędzi projektowych (z zakresu zarządzania projektami) do powtarzalnych działań opracowywania projektów nowych produktów, dokumentacji, które powinny być traktowane jako procesy.

• Zarządzanie projektami, samo w sobie, w oderwaniu od przedmiotu projektu, jest procesem. W powtarzalny sposób zamienia wejście do niego (ideę projektu) w wyjście (produkt końcowy, realizację celu projektu), na drodze takich samych, co do ogólnej zasady, kroków (planowanie i organizacja, kolejne etapy realizacji projektu, zamykanie projektu), angażując takie same podmioty uczestniczące (komitet sterujący ze sponsorem, kierownikpProjektu, zespół projektowy, wsparcie projektu).
• Z drugiej strony, opracowanie i wdrożenie (uruchomienie) nowego lub istotnie zmienionego procesu może odbywać się na drodze zarządzania projektem zmiany organizacyjnej.
• Procesy i projekty stanowią dwa rodzaje działalności organizacji: stały i tymczasowy. Oba przebiegają z natury w poprzek struktur organizacyjnych: wykorzystują zasoby różnych, współdziałających ze sobą, komórek organizacyjnych, natomiast wymagają (dla efektywnego zarządzania) użycia różnych narzędzi.

Oprócz nich istnieją w każdej organizacji działania inne, drobne, które z jednej strony są zbyt mało powtarzalne, by traktować je jako procesy, a z drugiej są zbyt małe, by stosować dla nich mechanizmy zarządzania projektami. Określenie granic dla tych trzech grup należy do organizacji, natomiast brak takiego określenia powoduje zazwyczaj rozrastanie się działań „innych”, stanowiących swoistą niezarządzaną (lub trudno zarządzaną) strefę działań.

Chcesz skomentować, podyskutować lub nawiązać kontakt z autorem? Napisz: [email protected]

Czytaj też: Pojęcie procesu oraz inne artykuły z cyklu MAP

Formalnie nie ma znaczenia, czy działania te i ich wynik są powtarzalne, czy są realizowane po raz pierwszy, czy są realizowane każdorazowo w taki sami sposób, czy potrafimy mierzyć ich rezultat i śledzić stan ich realizacji itd. Te elementy stanowią o dojrzałości procesowej, natomiast nie o procesie jako takim.

Proces jest rozpoczynany przez konkretne ZDARZENIE.

Wynika ono z potrzeby klienta procesu i często jest przez tego klienta inicjowane. Przykładami są np. wejście konsumenta do sklepu w celu zakupu towaru, złożenia zamówienia wydania części z magazynu, zamówienie kawy w kawiarni itp. Może ono też być generowane przez inne procesy (np. rozpoczęcie realizacji zamówienia klienta po zarejestrowaniu wpływu płatności, generowanie sprawozdania podatkowego po zamknięciu księgowym miesiąca). Zdarzenie może być również wywołane przez upływ czasu (ale zgodnie z określonym wymaganiem klienta — np. tworzenie raportu miesięcznego sprzedaży dla dyrekcji każdego 5 dnia miesiąca, automatyczna synchronizacja stanów magazynowych co 2 minuty, rozpoczęcie akcji promocji świątecznych w połowie października itp.).

Proces ma dobrze określony CEL, który powinien być osiągany dla zaspokojenia POTRZEB KLIENTA

Oznacza to, że każde działanie w ramach procesu jest (powinno być) ukierunkowane na osiągnięcie założonego celu. Znaczy to również, że zawsze istnieje ktoś (lub coś), kto jest powodem realizacji procesu.

PODEJŚCIE PROCESOWE jest więc postępowaniem zorientowanym na osiąganie CELÓW BIZNESOWYCH, a nie tylko spełnianiem norm lub generowaniem danych.

Proces dostarcza (w przypadku prawidłowego zakończenia) WYNIK realizujący ten cel.

Określenie i odróżnienie wyniku od celu ma znaczenie ze względu na sposób oceny: cel, jako spełniający potrzebę klienta, jest oceniany przez tegoż klienta, natomiast wynik powinien być możliwy do poddania ocenia przez organizację czy osoby realizujące proces. Ponadto potrzeba klienta może ulec zmianie lub zniknąć (jest to czynnik zewnętrzny, niezależny), natomiast osiągnięcie prawidłowego wyniku, w przypadku zakończenia procesu, jest miarą wewnętrzną. Oczywiście, w wielu sytuacjach proces nie kończy się w sposób pożądany i prawidłowy — sam proces może zostać przerwany lub też osiągnięty wynik nie zaspokaja potrzeb klienta. Stopień spełnienia tych potrzeb jest miarą JAKOŚCI dostarczanych przez proces (a co za tym idzie — także przez całą organizację) produktów.

KLIENTEM procesu może być klient firmy, podmiot zewnętrzny, który płacąc za dostarczane mu produkty (wyniki procesów) warunkuje istnienie organizacji. Często klientem procesu jest także klient wewnętrzny (zarząd, dyrekcja, pracownik, dział), który bezpośrednio „nie płaci” za dostarczany wynik, ale pośrednio, dzięki zaspokojeniu jego potrzeb firma może dostarczać swoje produkty klientom zewnętrznym. W tej samej roli mogą występować inne procesy w firmie. Specyficznym klientem są również organy zewnętrzne nadzorcze, regulacyjne i certyfikacyjne, których niezaspokojone potrzeby (wymagania) mogą skutkować przerwaniem działalności organizacji.

Istnieją również klienci drugoplanowi, interesariusze procesu (choć to pojęcie jest zazwyczaj używane w zagadnieniach projektowych). Są oni odbiorcami całej gamy dodatkowych produktów (wyjść) procesu: raportów, informacji, produktów ubocznych, korzyści itp. Na wejściu do procesu, oprócz zdarzenia go wywołującego, również zazwyczaj wymagane jest istnienie szeregu elementów dodatkowych: odpowiedniej infrastruktury, informacji, kompetencji, danych, dokumentów itp.

Chcesz skomentować, podyskutować lub nawiązać kontakt z autorem? Napisz: [email protected]

Czytaj też: Projekt jako proces oraz inne artykuły z cyklu MAP