Czy jakość pracy da się zmierzyć, inaczej niż przez wynik finansowy?

W zasadzie sprawa jest prosta...
Im pracownik lepiej pracuję tym większy przychód generuje.

Zatem można go zmierzyć stosując miarę odwrotną:
Im dany pracownik ma lepszy wynik finansowy tym jego praca jest większej jakości.

Ale czy to jest takie proste?

Dołóżmy do naszego wnioskowania element kosztowy,
a powyższy algorytm stanie się mało miarodajny.

Konieczne stanie się mierzenie współczynnika rentowności przychód/koszty.
Im współczynnik jest większy od 1 tym jakość jest lepsza.

Dołóżmy do kilka wymiarów,
a otrzymamy wzajemnie wykluczające się mierniki.

Klasyką przypadku jest miernik sprzedawcy usług liczony od obrotu
i miernik wykonawcy usługi liczony od marży.

Otrzymujemy paradoks im więcej sprzeda handlowiec tym marża wykonawcy może być mniejsza.
A są to przecież kwestie finansowe, które mają bezpośrednie przełożenie na wynagrodzenie pracowników.

Konflikt gwarantowany.

Niestety finansowe systemy motywacyjne potrzebują algorytmu opartego o wymierne dane.

Premie uznaniowe, bardzo szybko zaczynają być normalnym składnikiem wynagrodzenia, a ich brak karą.
System motywacyjny błyskawicznie przestaje pełnić swoją rolę, polegająca na zwiększaniu zaangażowania pracowników, co najwyżej walczy o jej utrzymanie na danym poziomie.

Platforma BPM może dać zbiór zupełnie nowych informacji, które z powodzeniem mogą być zaszyte w algorytmy motywacyjne.

Oto zestaw podstawowych informacji, które są podstawą do monitorowania aktywności biznesowej w perspektywie konkretnych pracowników:
- czas trwania zadania (im mniejsze odchylenie od średniej, tym lepiej)
- ilość wykonanych zadań (im większe odchylenie od średniej, tym lepiej)
- ilość otwartych zadań (im mniejsze odchylenie od średniej, tym lepiej)
- ilość powtórzeń danego zadania (im mniejsze odchylenie od średniej, tym lepiej)
- ilość eskalacji na ścieżce głównej i ścieżkach krytycznych (im mniejsze odchylenie od średniej, tym lepiej)

Oczywiście, każde średnie odchylenie również jest automatycznie wyliczane.

Oto przykład:

Zadanie	Średnia	Prac A	Prac B	Wsp. A	Wsp. B
czas trwania zadania	15	10	20	150%	75%
ilość wykonanych zadań	150	200	100	133%	67%
ilość otwartych zadań	15	5	20	300%	75%
ilość powtórzeń danego zadania	2	3	1	67%	200%
ilość eskalacji na ścieżce głównej i ścieżkach krytycznych	10	20	5	50%	200%
Średnia jako współczynnik motywacyjny:				140%	123%

Może to być dodatek do części zmiennej zależnej od jakości pracy.

Dlaczego, aby coś było proste, najpierw trzeba to maksymalnie skomplikować?

Prawie każdy proces BPM ma bardzo podobny cykl życia:

1. Prototyp ze ścieżką główną (1 - 4 tygodnie)
2. Wersja działająca w wąskim gronie użytkowników kluczowych ze ścieżką główną i kilkoma krytycznymi (1 - 4 tygodnie)
3. Budowa wersji docelowej w której jest kilkadziesiąt ścieżek alternatywnych, customowy routing po strukturze, zestaw raportów dla alternatywnych przebiegów (3 - 9 miesięcy).
4. Wdrożenie produkcyjne
5. Konsternacja użytkowników, ale o co w tym wszystkim chodzi?
6. Nowa wersja procesu, w którym wszystko zostaje uproszczone do prototypowej ścieżki głównej

Dodam tu, że procesy są tworzone przez doświadczonych konsultantów BPM, którzy tłumacza brak sensu w zapętlaniu ścieżek alternatywnych, niestety nie oni o tym decydują.

Dzieje się tak, bo proces BPM jest lustrem w którym przegląda się cała sfera interpersonalnych relacji ludzi wykonujących zadana w obszarze, który proces automatyzuje, optymalizuje, stabilizuje i normalizuje.

Relacje interpersonalne wymykają się logice i stają się niedeterministyczne. W konsekwencji w procesie tworzy się stado decyzji, w których warunki dynamicznie się zmieniają.

Aby to obsłużyć konieczne są algorytmiczne potworki, które z każdą zmianą przybierają na sile.
BPM pozwala je obiektywnie zobaczyć na diagramie BPMN, gdzie zdrowy rozsądek mówi, że powinno być 10 kroków, a jest ich ponad 50, gdzie przejrzystość diagramu BPMN ginie w gąszczu zapętlonych strzałek.

Czy jest na to sposób?
Stawiam śmiałą tezę, że tak, ale tylko wtedy gdy analiza IT zostanie zastąpiona warsztatami interpersonalnymi, na których za pomocą różnych psychologicznych technik odkryjemy wspólnie z uczestnikami co jest sensem, a co balastem społecznym wynikającym z mechanizmów obronnych każdego człowieka.

Tylko czy na taką pracę jesteśmy gotowi?

Czy jakość pracy da się zmierzyć?

Często zadaje pytanie:
Czy mierzycie Państwo jakość pracy swoich pracowników?

Zazwyczaj uzyskuje 2 odpowiedzi:
1. Tak przez wynik finansowy, bo im ktoś lepiej pracuje tym większy wynik wypracowuje
2. Tak przez ocenę pracowniczą, którą wykonujemy kilka razy w roku

Ale czy rzeczywiście jest to mierzenie jakości pracy?

Miara przez wynik finansowy obejmuje fragment rzeczywistości i bardzo łatwo prowadzi do wykluczania się celów, oto kilka przykładów:
a. sprzedaż krótkoterminowa, może wykluczać stałą współpracę
b. optymalizacja produkcji w jednym miejscu, może spowodować lawinę problemów w innych
c. rozliczanie liczby rozmów w Call Center, prowadzi do częstych zwolnień konsultantów i niezadowolenia klienta, który ma wrażenie, że rozmawia z automatem.

Natomiast miara przez ocenę pracy, jest obarczona subiektywnością osób współpracujących, która często ma swoje źródło w relacji interpersonalnej, a nie sposobie pracy.

Po co mierzyć jakość pracy?
Oczywista odpowiedź: jest to wsad do systemu motywacyjnego.

Jak BPM może pomóc w mierzeniu jakości?

Oto wybrane KPI, które bez trudu można ustawić w procesie dla każdego pracownika:
1. Lista zadań wykonanych
2. Lista zadań wykonanych w terminie
3. Czas wykonywania zadania
4. Liczba podejść do zadania
5. Liczba osób, które obsługiwały dane zadanie, po danej osobie

Oto KPI jakie można ustalić by określić wpływ jakości zadania na pozostałe kroki w procesie:
1. Średnia liczba ścieżek alternatywnych uruchamianych przez wynik pracy danego pracownika
2. Średnia liczba ścieżek, które zakończyły się biznesowym sukcesem
3. Średni czas trwania procesów, w których pracownik bierze udział
4. Średnia liczba eskalacji w procesach, w których pracownik bierze udział

Mając te dane, stworzenie algorytmu wyliczającego jakość pracy pracownika staje się możliwe.

Mając miarę jakości pracy system motywacyjny wchodzi w nowy wymiar:
- Wynik + Ocena interpersonalna + Jakość pracy

To może wyeliminować te jednostki, które znalazły sposób na oszukanie systemy motywacyjnego opartego o wynik i ocenę pracowniczą.

Znacznie trudniej jest oszukać BPM, który zbiera dane jakościowe przy okazji wykonywania zadań biznesowych. To już nie jest XLS lub inny system, który zbiera informacje deklaratywne.

Ja już nie chcę pamiętać...

Aplikacje kartotekowe dostarczają bardzo potrzebnych funkcjonalności.
Często obrastają one w katalog funkcjonalności dodatkowych,
dzięki czemu wiele rzeczy można zrobić na wiele sposobów.

Ponadto użytkownicy końcowi wykorzystują ów zbiór funkcjonalności do wytworzenia własnych strategii omijania procedur biznesowych. Robią to całkowicie legalnie, bo przecież aplikacja na to pozwala.

Z czasem te spontaniczne strategie stają się norma, a ich autor lokalnym guru.

Niestety staje się on wąskim ogniwem, bo musi o nich pamiętać i tłumaczyć wszystkim innym, bo choć aplikacja na to pozwala, to nie była stworzona z myślą o tych alternatywnych ścieżkach, zatem nie jest ona opisana w dokumentacji, instrukcji, ani też nie jest pokazywana na szkoleniach wprowadzających.

Bardzo szybko sukces guru, staje się jego przekleństwem, ale ze względu na dobro sprawy biznesowej nie może o swoim rozwiązaniu zapomnieć.

Druga kwestia, którą warto zapomnieć jest sekwencja zdarzeń. W aplikacjach kartotekowych musimy pamiętać w jakiej kolejności wchodzić w poszczególne kartoteki, co więcej nie wszystkie zadania biznesowe są odwzorowane w aplikacji, zatem sekwencja formatek, przeplatana jest czynnościami manualnymi, często takimi których nie znajdziemy w formalnych procedurach.

Co ciekawe, nowemu pracownikowi odkrycie i praktyczne poznanie tego przebiegu zajmuje średnio 2 lata (dopiero wtedy lokalny guru może pójść na urlop i biznes się nie zatrzyma, jak go nie będzie).

BPM bez trudu pozwala zapomnieć i odciążyć guru.

A jednak mimo tak wielkiej wartości, cały czas przegrywa z aplikacjami kartotekowymi, a nawet z Excelem.

Jest tak, bo tworząc proces BPM najważniejsza jest sekwencja, a nie kolor przycisków i zaokrąglone rogi pól. W konsekwencji pozwalając na pełną otwartość i elastyczność w zmienianiu poziomu entropii w biznesowym chaosie ogranicza możliwości tego co użytkownik może zrobić w swoim GUI.

W efekcie poczucie bezpieczeństwa przegrywa z potrzebą natychmiastowego dotykania efektu, na czym cierpi wydajność osobista i biznesowa.

Jeszcze trochę społeczność BPM'owa musi się napracować by przekonać społeczność biznesową, że najważniejsza jest ścieżka główna.

No i trochę poczekać, aż biznes zrozumie, że zyski z wdrożenia ścieżki głównej mogą sfinansować realizację ścieżek alternatywnych.

A może kiedyś przekona się również do tego, że tak zapracowany guru, może mieć jednego automatycznego asystenta, zamiast rzeszy pijących kawę pomocników.

Najbardziej dramatyczna różnica między aplikacją BPM a aplikacją Customową....

Aplikacja BPM to funkcjonalność w całości oparta o proces BPM zdeployowany na platformie BPM.
Aplikacja Customowa to funkcjonalności w całości oparta o wybrany framework developerski.

Paradoksalnie owa różnica wynika z największej zalety BPM, jaką jest elastyczność.

Gdy piszemy aplikację customową, to następuję wyraźny rozdział pomiędzy formą a treścią.
Forma ukryta jest w kodzie, treść zapisana jest w bazie danych.
Tak osiągnięta niezależność sprawia, że można zmieniać formę bez wpływu na historyczne dane.
Dzięki czemu zmiana wynikająca ze dynamiki zakresu, czy też zmiana wynikająca z naprawy błędu,
ma niewielki wpływ na już zgromadzone dane.

Powyższa obserwacja może kłócić się z pojęciem testów regresji.

Jednak:
"Regresja – zjawisko niezamierzonej utraty jakiejś funkcjonalności powstałe w nowej wersji programu i zwykle skutkujące komunikatem o błędzie lub brakiem działania. Do regresji dochodzi wskutek wprowadzania zmian w jakiejś części kodu programu. Skutkiem tych zmian jest błędne działanie innej funkcji programu, która w poprzednich wersjach działała prawidłowo."

Zatem regresja dotyczy tylko formy.

Inaczej jest w aplikacjach BPM. Tutaj forma i treść zawarta jest w instancji procesu. Można by powiedzieć, że 200 instancji to 200 aplikacji customowych. Nawet gdy obiekt biznesowy utrzymujemy w zewnętrznej bazie danych, to kluczowe informacje BPM, czyli maszyna stanów zawarte są w instancji.

Można tego uniknąć, poprzez stosowanie krótkich procesów kartotekowych, czyli takich które sterują odczytem i zapisem w zewnętrznej bazie danych, czyli przenieść maszynę stanów poza BPM, tylko po co wtedy stosować BPM?

No i dochodzimy do wspomnianego w tytule dramatu, którym jest migrowanie instancji procesów.
Gdy używana platforma BPM tego nie oferuje, to przy każdej zmianie, stajemy przed krytyczną decyzją:

Jak dokończyć trwające instancje procesów, jak w procesie jest błąd techniczny lub biznesowy?

Mamy dwie opcje:
1. Zamykamy instancje i zmuszamy użytkowników do ponownego uruchomienia procesu w nowej wersji (wzrost czarnego PR gwarantowany)
2. Piszemy aplikację customową, która po kolei każdą instancję skopiuje do nowszej wersji procesu z użyciem API REST (lub zrobi to administrator ręcznie w ramach konserwacji)

Oczywiście Vendorzy BPM zauważyli ten problem i tworzą mechanizmy migracji, ale nie potrafią one:
1. Zmienić danych w migrowanej instancji 
2. Zmienić przebiegu w tej części instancji, która jest historyczna
3. Gubią się, gdy usuniemy lub przesuniemy zadanie, w którym oczekuje instancja

Prędzej niż później aplikacja BPM wymaga opracowania mechanizmu migracji w modelu BPM (a nie na platformie BPM), który wesprze i uzupełni wbudowane w platformę BPM mechanizmy migracji, tak by było możliwe skopiowanie instancji z jej historią, obiektem biznesowym oraz dokonanie w nich stosownych wymaganych przez nową wersję zmian.

Jeżeli tego nie zrobimy, każda zmiana stanie się koszmarem, którego i Biznes i Wykonawca będą za wszelką cenę unikać, a patos elastyczności stanie się praktycznym mitem.

Po co Komu BPM?

Po co Komu BPM?
Jedna błędna odpowiedź i porażka gwarantowana.

Dla zamawiającego, bo otrzyma nie to co potrzebuje, a raczej dostanie zgniłe jajo trudne w utrzymaniu i rozwoju.
Dla wykonawcy, bo projekt będzie pod wodą, a i czarny PR raczej go skreśli z listy zaufanych dostawców.

Co sprawia, że to pytanie jest pomijane ... ?
Wiedza dostawcy, z którym relacje ma zamawiający.
A także to, że odpowiedź jest nietrywialna.

Poziom entropii podnosi fakt, że BPM jest zbiorem dedykowanych do różnych funkcjonalności silników licencjonowanych na różne sposoby.

Podział historyczny:
- lekkie silniki BPM - to te w których z poziomu modelera można uruchomić proces (zaleta: szybka realizacja, wada: brak standaryzacji developementu)
- ciężkie silniki BPM - to te w których należy skompilować model i zainstalować go na silniku (zaleta: standaryzacji developementu, wada: długa realizacja)

Podział dziedzinowy (by IBM):
- human centric - procesy zorientowane na Human Taski
- document centric - procesy zorientowane na dokumenty
- integration centric - procesy zorientowane na integrację

Podział licencyjny:
- per użytkownik
- per procesor
- open source
- okresowa subskrybcja

Podział ze względu na wymagania Zamawiającego:

- zgoda na ograniczoną wydajność

- wymaganie skalowalności

- zgoda na ograniczenia platformy

- wymaganie pełnej realizacji wymagań biznesowych

- wymaganie wysokiej ergonomii formatek

- wymaganie wysokiej ergonomii skrzynki zadań

W efekcie to Zamawiający musi podjąć szereg kluczowych decyzji cząstkowych,

które na zasadzie eliminacji wskażą właściwy silnik.

Problem 1.

Trafną decyzję można podjąć wyłącznie w oparciu o istniejące doświadczenia (choć nie są one gwarancją).

Klient wybierając BPM'a nie ma jeszcze doświadczeń z BPM'a. 

Zatem musi zaufać dostawcy, w ten sposób koło się zamyka.

Wyjściem z tej patologii, mogło by być zapraszanie dostawców, którzy mają zrealizowane projekty w każdej kategorii, ale takich jeszcze w Polsce nie ma.

Problem 2 

Mimo rozwijającego się rynku BPM, nie ma takiej opcji, która spełni wszystkie potrzeby Zamawiającego, a to w prostej linii prowadzi do modelu BPM + Custom.

Niestety BPM i Custom to dwa równoległe światy, w których zarządzą zupełnie różne prawa zarządzania.

BPM to jednak już prawie świat konsultingu,

Custom to świat analityków i programistów.

Para (A+P) potraja koszt wdrożenia BPM, a konsultant jeżeli już zrobi Custom to z olbrzymim długiem technologicznym.

Odpowiedzią jest AGILE z umowy ramowej i robienie BPM przez Konsultantów a Customa przez Analityków i Programistów.

Trzymam kciuki za Zamawiających by jak najszybciej mogli tak kupować....

Co założyć by oferta była bezpieczna i nie została odrzucona przez Zamawiającego

1. 
   
   1.      Zakładamy, że wszystkie niespisane w ofercie założenia nie obligują nas do wykonania prac mających na celu ich realizację.
   2.      Zakładamy, że niniejsza oferta jest odpowiedzią na realizację wszystkich funkcjonalności określonych w zapytaniu za wyjątkiem wyspecyfikowanych w ofercie wyłączeń.
   3.      Zakładamy, że ogólny kierunek realizacji funkcjonalności biznesowych jest wyznaczony przez określoną przez zamawiającego architekturę IT. Natomiast sposób ich realizacji, jest w gestii dowolnej interpretacji, zgodnej z dobrymi praktykami Wykonawcy,
   4.      Zakładamy, że do realizacji wymagań Zamawiającego zostaną wykorzystane platformy programistyczne dedykowane do poszczególnych obszarów: OCR, BPM, BAM, BI, BD, Repozytorium dokumentów,
   5.      Do realizacji wymagań biznesowych zamawiającego Zakładamy wykorzystanie możliwości out of the box platform wchodzących w poszczególne elementy zaoferowanej architektury,
   6.      Zakładamy, że dopasowanie platform do szczegółowych wymagań zamawiającego wymagające dodatkowych rozszerzeń narzędzi, jest możliwe ale w ramach rozszerzenia zakresu i budżetu projektu,
   7.      Zakładamy, że stroną rozstrzygającą czy dana możliwość jest w danej platformie, czy też wymaga dodatkowego rozwiązania programistycznego jest Vendor danej platformy.