Dzisiaj kiedy 80% funkcjonalności procesu biznesowego można narysować za pomocą strzałek i kwadracików, najważniejszą kompetencją konsultanta BPM jest umiejętność zrozumienia zagadnień biznesowych.
Do tej pory obowiązek wyspecyfikowania algorytmów biznesowych leżał (i leży jeżeli programujemy system) po stronie biznesu zamawiającego.
Wykonywało się to za pomocą żmudnej analizy biznesowej, to dlatego tak ważna była (i jest [...]) funkcja analityka, który stawał się tłumaczem świata biznesowego na programistyczny.
W przypadku nowoczesnej platformy BPM programista jest już prawie nie potrzebny, a analityk może bezpośrednio przekładać wymagania biznesowe na diagramy BPMN. Pod tym względem nie wiele się dla niego zmienia bo każda analiza zawiera diagramy UML, arkusze XLS z obiektami biznesowymi, tabeli DOC ze spisanymi parametrami, ścieżkami przepływu i innymi ustaleniami.
Niestety pracą Analityka jest analiza, czyli:
Analiza (łac. [now.] analysis, od gr. ἀναλύειν analyein, „rozdzielić”, od ἀνα- ana- oraz lyein, „rozluźnić, rozwiązać, zniszczyć”) – rozkład na składniki/czynniki (w sensie materialnym i niematerialnym); przeciwieństwo syntezy.
Zatem analityk przyjmuje postawę reaktywną i spisuje to czego się dowie na spotkaniach. Oczywiście dobry analityk tak poprowadzi spotkanie, by złożone zagadnienie rozłożyć na czynniki pierwsze. Jednak docelowe rozwiązanie zawsze podaje Klient.
Paradoks polega na tym, że w większości Klient, który decyduje się na zakup dedykowanego systemu, robi to bo jego obecne rozwiązanie przestało działać, a więc jest nieadekwatne do sytuacji.
Jeżeli takie rozwiązanie zaimplementujemy w nowej aplikacji, nic się nie zmieni....
Nowoczesne platformy BPM pozwalają na to by zaraz po analizie zrobić syntezę i zaproponować Klientowi biznesowe rozwiązanie, pasujące do nowej rzeczywistości.
Synteza (z gr. σύνθεσις synthesis, „zgoda”, od συντιθέναι syntithenai, „składać”, od συν- syn- i τιθέναι tithenai, „umieścić, położyć”) – termin oznaczający tworzenie bardziej złożonego dzieła z prostszych elementów; może mieć charakter materialny (np. w chemii) jak i abstrakcyjny (w literaturze). Przeciwieństwem syntezy jest analiza (lub rozkład, rozpad).
A więc konsultant BPM powinien umieć analizować i syntezować.
Przy czym syntezy wykonanej na papierze nie da się odebrać (jest nowa, nie zrozumiała, za bardzo abstrakcyjna dla biznesu), dlatego warto aby synteza odbywała się na platformie BPM, wtedy od razu jej wynik będzie można dotknąć, sprawdzić, zweryfikować.
Szkoda tylko, że Klient zaczyna doceniać taką pracę po kilku miesiącach czarnego PR, który jest naturalną konsekwencją przystawiania miary dla programowalnych systemów do projektów BPM.
Chodzi o to, że synteza wymaga szereg prób, których część to ślepe uliczki. Według stereotypu podejścia programistycznego, ślepa uliczka to błąd (techniczny, architektoniczny, biznesowy).
piątek, 17 stycznia 2014
piątek, 20 grudnia 2013
Co obejmuje środowisko BPM?
Aplikacja silosowe mogą działać samodzielnie.
Mogą mieć dowolną liczbę środowisk (DEV, TST, QAS, PRD etc.)
i zawsze można wykazać, że działają poprawnie
lub szybko zdiagnozować błąd.
Inaczej jest w przypadku BPM.
Wzorcowy BPM powinien przechowywać wyłącznie dane dotyczące przepływu oraz dane dla maszyny stanów.
Cała reszta (czyli treść biznesowa) powinna być w aplikacjach lub zbiorach danych, które za nie odpowiadają. Oto kilka przykładów:
- dane pracownicze => system HR
- dane finansowe => system FI
- dane majątkowe => system ERP
- dane o klientach => system CRM
- dane raportowe => system BI
Do tego warto aby w komunikacji pośredniczyła szyna ESB.
Niestety im bardziej wzorcowe jest wdrożenie BPM tym trudniej takie rozwiązania się utrzymuje.
Dlaczego ?
Po prostu błędy techniczne i biznesowe w aplikacjach objawiają się jako błędy techniczne lub wady procesowe w BPM.
Ich diagnoza wymaga udowodnienia, że błąd leży poza BPM.
Ich korekta często wymaga zmian w BPM (które traktowane są jako błąd, bo przecież są błędem w aplikacjach silosowych).
Do tego dochodzi konieczność utrzymywania całych środowisk nieprodukcyjnych inaczej konsultanci BPM działają po omacku, co wprost przekłada się na jakość rozwiązania.
Jednak BPM wymaga wysokiej kultury IT, a o niej nie często pisze się w wymaganiach w postępowaniach zakupowych.
Mogą mieć dowolną liczbę środowisk (DEV, TST, QAS, PRD etc.)
i zawsze można wykazać, że działają poprawnie
lub szybko zdiagnozować błąd.
Inaczej jest w przypadku BPM.
Wzorcowy BPM powinien przechowywać wyłącznie dane dotyczące przepływu oraz dane dla maszyny stanów.
Cała reszta (czyli treść biznesowa) powinna być w aplikacjach lub zbiorach danych, które za nie odpowiadają. Oto kilka przykładów:
- dane pracownicze => system HR
- dane finansowe => system FI
- dane majątkowe => system ERP
- dane o klientach => system CRM
- dane raportowe => system BI
Do tego warto aby w komunikacji pośredniczyła szyna ESB.
Niestety im bardziej wzorcowe jest wdrożenie BPM tym trudniej takie rozwiązania się utrzymuje.
Dlaczego ?
Po prostu błędy techniczne i biznesowe w aplikacjach objawiają się jako błędy techniczne lub wady procesowe w BPM.
Ich diagnoza wymaga udowodnienia, że błąd leży poza BPM.
Ich korekta często wymaga zmian w BPM (które traktowane są jako błąd, bo przecież są błędem w aplikacjach silosowych).
Do tego dochodzi konieczność utrzymywania całych środowisk nieprodukcyjnych inaczej konsultanci BPM działają po omacku, co wprost przekłada się na jakość rozwiązania.
Jednak BPM wymaga wysokiej kultury IT, a o niej nie często pisze się w wymaganiach w postępowaniach zakupowych.
wtorek, 3 grudnia 2013
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.
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.
wtorek, 26 listopada 2013
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?
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?
piątek, 22 listopada 2013
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.
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.
piątek, 15 listopada 2013
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.
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.
wtorek, 8 października 2013
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.
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.
Subskrybuj:
Posty (Atom)