Dwa oblicza procesu zarządzania

W literaturze najczęściej spotykanym przedstawieniem procesu zarządzania jest podział na 4 etapy: „planowanie, organizowanie, kierowanie oraz kontrola” (podział z książki J.A.F. Stonera „Kierowanie”). Można powiedzieć, że dwa pierwsze etapy odpowiadają na pytania: „Co chcemy zrobić?” oraz „Jak chcemy zrobić?” Potem następuje działanie kierowane przez odpowiednich członków organizacji. Zaplanowane zadania są wykonywane przez ludzi na odpowiednich stanowiskach. Na koniec szukamy odpowiedzi na pytanie „Co i jak zrobiliśmy?”, czyli następuje kontrola, a dokładnie porównanie efektów działań z planem. Ideę tej zależności prezentuje poniższy diagram.

Strzałki wskazują, że:

• proces jest inicjowany na pewnym poziomie struktury organizacyjnej.
• działanie związane z planem jest realizowane na innym jej poziomie.

Równocześnie strzałki pokazują połączenie między dwoma perspektywami procesu – stroną dynamiczną, w ramach której wykonywane są kolejne etapy, przynoszące określone efekty oraz stroną statyczną, czyli strukturą organizacyjną i z nią związanym podziałem zadań. Zadania są podzielone, procesy są inicjowane przez jednych pracowników, a wykonywane przez innych.

Istotnym elementem jest to, że między poszczególnymi etapami procesu następują powiązania i sprzężenia zwrotne. Postęp działania oraz kontrola może powodować nawrót do planowania, zmiany definicji celów, a to powoduje, że zmieniają się kryteria oceny działań. I tym momencie można wskazać, że proces jest inicjowany przez kogoś innego niż początkowo, a to już jest uzależnione od wcześniej wspominanego podziału zadań, a dokładnie tego, kto jest odpowiedzialny za kontrole, kto za zakomunikowanie zmian, a kto za ponowną definicję celów i aktualizację planów. Ta strona statyczna, przejawiająca się podziałem zadań, w pewien sposób powoduje, że proces jest dynamiczny i musi nieustannie reagować na zmiany.

Reklama

Od sprawności do efektywności procesu

Ostatnio płaciłem za usługę za pomocą mechanizmu płatności elektronicznych, inicjowanych z poziomu panelu administracyjnego, jednego z dostawców usług (nazwijmy internetowych). Wybrałem usługę do opłacenia, wskazałem rodzaj pakietu, wybrałem sposób płatności, kilka razy potwierdziłem, a na koniec otrzymałem komunikat „Niestety nie udało się. Spróbuj jeszcze raz”. Pomyślałem, będą musiał powtórzyć ostatni krok. Niestety okazało się, że całość. Czy było to efektywne? Czy można powiedzieć, że proces jest sprawny? Proces w uproszczeniu został zaprezentowany na poniższym diagramie (w BPMN).

Fakt, za drugim razem, proces zakończył się oczekiwanym efektem – usługa została opłacona i jej czas obowiązywania został przedłużony na następny okres. Jednakże sama realizacja nie odbyła się jak dla mnie w najlepszy możliwy sposób – zarówno ze względu na poświęcony czas, kilkakrotne potwierdzanie czy też wątpliwość czy przypadkiem jakaś płatność nie została jednak wykonana, a jedynie potwierdzenie nie zadziałało, czy też powrót do panelu.

Sformułowanie „oczekiwany efekt” wskazuje na tzw. efektywność procesu, natomiast „najlepszy możliwy sposób” wskazuje na tzw. sprawność procesu. W internecie można znaleźć różróżnienie, dla ułatwienia posłużę się angielskimi definicjami:

• Effective: Adequate to accomplish a purpose; producing the intended or expected result ( =oczekiwany efekt).
• Efficient: Performing or functioning in the best possible manner (=najlepszy możliwy sposób) with the least waste of time and effort.

Definicje idealnie pokazują, że proces efektywny to taki, który generuje właściwe efekty, a proces sprawny, który doprowadza do tych efektów w najlepszy możliwy sposób, biorąc pod uwagę czas, koszt realizacji. W przypadku powyższego procesu należałoby poprawić sposób działania i obsługi wyjątków, aby był realizowany szybciej. Można by, jak w przypadku niektórych sklepów internetowych, zapisywać etapy zrealizowane i umożliwić podjęcie procesu od pewnego kroku, ostatniego zaakceptowanego. Jeżeli chodzi o efektywność procesu to efekt jest prawidłowy. Myślę, że warto najpierw zadbać, aby z punktu widzenia użytkownika, proces przynosił oczekiwany efekt, a następnie poprawiać sprawność procesu, tak, aby efekt końcowy przewyższał oczekiwania użytkownika.

Ryzyka w procesie biznesowym

Załóżmy, że otrzymaliśmy zamówienie klienta i jako firma/dostawca próbujemy je zrealizować. W czasie procesu, którego efektem będzie realizacja zamówienia klienta, można powiedzieć, że rośnie jego poziom ryzyka. Spróbuję rozłożyć ryzyko na osi czasu odpowiadającej czasowi realizacji procesu. Poniższy diagram prezentuje, że w trakcie realizacji można zidentyfikować kolejne ryzyka, dla których należy przygotować odpowiednią strategię postępowania – zgodnie z procesem zarządzania ryzykiem.
W szczególnych przypadkach pewne zdarzenia mogą spowodować, że konieczna jest realizacja dedykowanego procesu – o czym więcej we wcześniejszym wpisie o materializacji ryzyka.Diagram prezentuje tylko przykładowe ryzyka występujące w procesie biznesowym. Można zauważyć, że:

• pierwszym ryzykiem pojawiającym się w trakcie realizacji procesu jest Ryzyko niespełnienia oczekiwań klienta, które istnieje na do zakończenia procesu. Można sobie z nim poradzić przez dyskusję z klientem i poznanie jego potrzeb, ankiety, badania itp.
• po przyjęciu zamówienia, proces jest wspierany przez narzędzia informatyczne, które mogą być niedostępne, nie działać poprawnie lub zbyt wolno. Jest to tzw. Ryzyko operacyjne. Materializacja tego ryzyka może wymagać zainicjowania osobnego procesu, oznaczonego jako „RO” na diagramie.
• na pewnym etapie procesu, pracownik firmy może napotkać wątpliwości w wykorzystaniu systemu wspierającego lub w zakresie działań do wykonania, może źle zinterpretować zapisy procesu bądź podręcznika użytkownika. Podobnie może źle rozpoznać informację pozyskaną od klienta – Ryzyko błędnej interpretacji na diagramie. Istotny jest tu element odpowiedniej komunikacji wewnętrznej.
• jeżeli czas realizacji procesu się wydłuża i może się pojawić zapytanie klienta, co się dzieje z zamówieniem, może być konieczne zainicjowanie dedykowanego procesu – oznaczonego przez „RT”. Takim procesem może być np. proces powiadomienia klienta, a może być wynikiem materializacji Ryzyka terminu.