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.
piątek, 20 grudnia 2013
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.
niedziela, 29 września 2013
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:
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ć....
środa, 25 września 2013
Co założyć by oferta była bezpieczna i nie została odrzucona przez Zamawiającego
- 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.
poniedziałek, 23 września 2013
Zaraza, która zwie się kombinatoryka
Zwykle zamodelowany proces w narzędziu klasy BPA jest bardzo skomplikowany.
Ma bardzo dużo decyzji (więcej niż 5),
Ma bardzo dużo elementów w linii (więcej niż 5),
Ma bardzo dużo linii (więcej niź 5),
I ma bardzo mało basen (zwykle 1).
Do tego dochodzi zamęt Informatyczny w biznesowej notacji, który przybiera formę stawiania na równi z działem biznesowym nazwy systemu.
No i jeszcze kwestia notacji dla interfejsów, co wdrożenie to inaczej się to zapisuje.
Skąd to się bierze?
Według mnie jest to próba odwzorowania biznesu i jego wszystkich ścieżek alternatywnych.
Wystarczy spojrzeć na proces logowania, klasyka przypadku, w którym każdy polski programista, może udowodnić, że w BPMN nie można opisać każdego procesu.
Ale czy rzeczywiście biznes jest tak bardzo skomplikowany?
Gdyby tak było, to nawet przy darze kombinowania, w jaki obdażony jest prawie każdy Polak, ten biznes po prostu by nie działał.
Znacznie bardziej ciekawa przyczyna powyższego stanu wynika z psychologii.
Otóż istnieją dwa dobrze zbadane prawa, które tłumaczą powody, przez które komplikujemy opis codziennych praktycznych metod postępowania.
Pierwsze to prawo koleracji, według którego nieświadomie naciągamy rzeczywistość (symptomy i fakty) do jednostkowego przypadku, który nie jest dojrzały statystycznie, ale który przeżyliśmy z dużą dawką emocji. W efekcie modelujemy alternatywne ścieżki (które same w sobie są często bardziej złożone, niż ścieżka główna) dla funkcjonalności, które najprościej by było zablokować lub obsłużyć mechanizmem wyjątków biznesowych.
Drugie prawo to prawo perspektywy według, którego każdy inaczej interpretuje te same liczby, dla mnie 5 to bardzo dużo, a dla innej osoby to śmiech na sali. Ta interpretacja wynika z doświadczeń, ale nie tylko tych bezpośrednich i biznesowych, ale szeroko kontekstowych (dla osoby, która w szkole dostawała zwykle 3 i była z tej oceny zadowolona to i 4 będzie bardzo dużo).
Wracając do modelowania...
Niestety nie da się modelować symultanicznie (mam tu na myśli automatyczne odtwarzania rzeczywistości), zatem do modelowania wybierane są kluczowe osoby i to ich magię koleracji według ich indywidualnej perspektywy odtwarzamy w modelu. Naturalnie każdy taki proces będzie oderwany od biznesowej rzeczywistości.
Taki ułomny model (mimo poniesienia znaczych środków w jego wytworzenie), staje się wsadem do procesu BPM, który bezdusznie obnaża koleracje i perspektywę. Niestety robi to w pierwszym okresie po wdrożeniu. Ocena jest oczywista: jakość procesu jest fatalna....
Dostrzegam tylko jedno sesnsowne rozwiązanie:
W ramach BPM wdrażamy tylko ścieżkę główna, cała reszta jest generycznym biznesowym wyjątkiem. Takie rozwiązanie wdrażamy na produkcję, tak by biznesowa społeczność mogła je poddać systemowej ocenie. Po krótkim okresie użytkowania zmierzymy skalę najczęstrzych wyjątków.
W ten sposób zamienimy indywidualną kolerację i perspektywę na obiektywną statystykę. To ona będzie definiować priorytety i kolejne przyrosty lub sprinty dalszych prac.
Biznesowy sprzeciw
Naturalny jest opór i sprzeciw użytkowników biznesowych. Wynika on z odkrycia biznesowych patologii i powiedzeniu "nie" dla ich implementacji (gdybyśmy zrobili ścieżki alternatywne, to reaktywnie byśmy się na to zgodzili).
Do wyboru mamy jednak dwie opcje:
1. Konflikt na początku projektu, który grozi nam wykluczeniem.
2. Zgodę na patologię i kiepski PR na końcu projektu, który grozi nam wyłączeniem naszego rozwiązania.
Ja wybieram opcję 1. Zdrowy sens zawszę prędzej czy później wypłynie na wierzch.
A i jeszcze jedno, wygrać tą batalię może tylko ta osoba, która wierzy w to o co walczy ...
poniedziałek, 16 września 2013
BPM chyba jest jednak BI'em
BPM potrafi zmierzyć tylko dwa rodzaje KPI:
- ilościowe, czyli jest w stanie na bieżąco podawać liczby wystąpień danych kroków
- czasowe, czyli jest w stanie na bieżąco podawać czasy realizacji human tasków
oczywiście, zwykle jest w stanie zrobić to rozbiciu na używaną strukturę operacyjną.
Co to oznacza?
Nie dowiemy się na jaką kwotę opiewają przyjęte faktury, w procesie kancelaryjnym.
Nie dowiemy się ile dni nieobecności ma dany pracownik, w procesie inwestycyjnym.
Nie dowiemy się jaka jest bieżąca wartość realizowanych inwestycji, w procesie zarządzania majątkiem.
Etc ...
Problem polega na tym, że organizacja zamawiając proces kupuje coś więcej niż tylko opanowanie, ogarnięcie czy też optymalizację aktywności biznesowej.
Kupując BPM kupuje dostęp do wyników.
Czyli, prędzej czy później skończy się na raportach.
Wygląda na to, że wdrażając silnik BPM warto od razu zrzucać obiekt biznesowy przy każdej zmianie stanu do zewnętrznej bazy danych, a do niej podłączyć silnik BI, tak by móc tworzyć dynamiczne raporty.
Tworzenie raportów w BPM jest dużym customem i kończy się ograniczeniem możliwości analitycznych.
Jeżeli powyższy obraz rozszerzymy o repozytorium dokumentów z BPM zaczyna się tworzyć złożona architektura.
Może to jest powodem, że BPM z trudem się przebija, a nawet jak mu się uda to ma tak liczne nawroty do aplikacji silosowych, w których wszystko można oprogramować w jednym miejscu.
- ilościowe, czyli jest w stanie na bieżąco podawać liczby wystąpień danych kroków
- czasowe, czyli jest w stanie na bieżąco podawać czasy realizacji human tasków
oczywiście, zwykle jest w stanie zrobić to rozbiciu na używaną strukturę operacyjną.
Co to oznacza?
Nie dowiemy się na jaką kwotę opiewają przyjęte faktury, w procesie kancelaryjnym.
Nie dowiemy się ile dni nieobecności ma dany pracownik, w procesie inwestycyjnym.
Nie dowiemy się jaka jest bieżąca wartość realizowanych inwestycji, w procesie zarządzania majątkiem.
Etc ...
Problem polega na tym, że organizacja zamawiając proces kupuje coś więcej niż tylko opanowanie, ogarnięcie czy też optymalizację aktywności biznesowej.
Kupując BPM kupuje dostęp do wyników.
Czyli, prędzej czy później skończy się na raportach.
Wygląda na to, że wdrażając silnik BPM warto od razu zrzucać obiekt biznesowy przy każdej zmianie stanu do zewnętrznej bazy danych, a do niej podłączyć silnik BI, tak by móc tworzyć dynamiczne raporty.
Tworzenie raportów w BPM jest dużym customem i kończy się ograniczeniem możliwości analitycznych.
Jeżeli powyższy obraz rozszerzymy o repozytorium dokumentów z BPM zaczyna się tworzyć złożona architektura.
Może to jest powodem, że BPM z trudem się przebija, a nawet jak mu się uda to ma tak liczne nawroty do aplikacji silosowych, w których wszystko można oprogramować w jednym miejscu.
piątek, 13 września 2013
Pierwszorzędnie drugorzędna rola BPM
Rozwiązania BPM muszą zapłacić słoną cenę za wejście i zadomowienie się w architekturach IT.
Taką samą cenę zapłaciły platformy dziedzinowe (ERP, CRM, etc...).
Chodzi o to, że zanim procesy BPM, zajmą należną im rolę, czyli staną się sposobem na spinanie i sterowanie rdzeniowymi procesami przechodzącymi przez całą organizację, muszą udowodnić swoją przydatność.
A mogą to zrobić jedynie poprzez tzw księgi pomocnicze, czyli aplikacje które rozszerzają rozwiązania platformowe lub zastępują niekoszerne funkcjonalności. Zwykle są odpowiedzią na model licencjonowania, ciężkiego klienta, czy duży koszt dopasowania platformy.
Bycie księgą pomocniczą sprawia jednak, że to w procesie BPM objawiają się błędy, wynikające z:
Zatem na dostawcy BPM spoczywa obowiązek wytworzenia procesów ale też (może nawet zwłaszcza też) koordynowanie całej edycji zmiany.
Problem w tym, że o ile rola integratora jest już powszechna i znana,
to rola integratora BPM, to ciągle nowość, w dodatku nowość taka, która na pierwszy rzut oka jest niepotrzebna.
Wystarczy zapytać się dowolnego biznesu, czy diagram BPMN stworzony na warsztatach analitycznych jest kompletny, czyli:
- zawiera wszystkie ścieżki?
- obejmuje wszystkie obiekty biznesowe?
- zawiera docelowy proces?
Odpowiedź jest oczywista TAK i 3xTAK.
Podczas gdy biznes (i konsultanci BPA) wpadają w zakłopotanie, po uszczegóławiających pytaniach:
- czy model zawiera ścieżki: główną, krytyczne, alternatywne i przechwytywanie wyjątków biznesowych?
- czy model opisuje atrybuty obiektów biznesowych, ma obiekt kierowania procesem i definiuje mapowanie na obiekty zewnętrzne?
- czy model opisuje stan TOBE? Jeżeli tak to jakim cudem, jeżeli na ten moment dostępna jest tylko subiektywna wiedza wybranych użytkowników (nie ma danych statystycznych)?
Taką samą cenę zapłaciły platformy dziedzinowe (ERP, CRM, etc...).
Chodzi o to, że zanim procesy BPM, zajmą należną im rolę, czyli staną się sposobem na spinanie i sterowanie rdzeniowymi procesami przechodzącymi przez całą organizację, muszą udowodnić swoją przydatność.
A mogą to zrobić jedynie poprzez tzw księgi pomocnicze, czyli aplikacje które rozszerzają rozwiązania platformowe lub zastępują niekoszerne funkcjonalności. Zwykle są odpowiedzią na model licencjonowania, ciężkiego klienta, czy duży koszt dopasowania platformy.
Bycie księgą pomocniczą sprawia jednak, że to w procesie BPM objawiają się błędy, wynikające z:
- biznesowych patologii rozwiązania z platformy,
- słabej lub braku procedury zarządzania zmianą,
- głuchego telefonu pomiędzy biznesem - IT - dostawcy platform - dostawca BPM,
- braku stabilności rozwiązań integracyjnych,
- słabości mechanizmów testowania.
Zatem na dostawcy BPM spoczywa obowiązek wytworzenia procesów ale też (może nawet zwłaszcza też) koordynowanie całej edycji zmiany.
Problem w tym, że o ile rola integratora jest już powszechna i znana,
to rola integratora BPM, to ciągle nowość, w dodatku nowość taka, która na pierwszy rzut oka jest niepotrzebna.
Wystarczy zapytać się dowolnego biznesu, czy diagram BPMN stworzony na warsztatach analitycznych jest kompletny, czyli:
- zawiera wszystkie ścieżki?
- obejmuje wszystkie obiekty biznesowe?
- zawiera docelowy proces?
Odpowiedź jest oczywista TAK i 3xTAK.
Podczas gdy biznes (i konsultanci BPA) wpadają w zakłopotanie, po uszczegóławiających pytaniach:
- czy model zawiera ścieżki: główną, krytyczne, alternatywne i przechwytywanie wyjątków biznesowych?
- czy model opisuje atrybuty obiektów biznesowych, ma obiekt kierowania procesem i definiuje mapowanie na obiekty zewnętrzne?
- czy model opisuje stan TOBE? Jeżeli tak to jakim cudem, jeżeli na ten moment dostępna jest tylko subiektywna wiedza wybranych użytkowników (nie ma danych statystycznych)?
BPM z perspektywy użytkownika wygląda zupełnie inaczej!
BPM z perspektywy użytkownika wygląda zupełnie inaczej!
Zacząłem tworzyć na własne potrzeby procesy BPM.
Po uzyskaniu pewnej płynności wytwórczej,
czyli opanowaniu platformy na tyle by się nie douczać w trakcie realizacji,
mogę wdrażać całkiem złożone potrzeby w kilka godzin.
Dzięki temu konsekwentnie przestaje używać Excela do zarządzania pracą.
W BPM staje się to znacznie łatwiejsze.
To jednak pozwala mi doświadczyć tego co doświadcza użytkownik dla własnego biznesowego procesu.
Tak, żadne testy nie oddadzą realnej pracy i to takiej od której zależą decyzje w realnym świecie.
Z przerażaniem odkryłem,
że dla użytkownika cała BPM'owa wartość dodana (modelowanie, konfiguracja, środowiska, elastyczność, etc...) jest bezużyteczna i niezauważalna, jeżeli nie może on zrealizować ścieżki głównej dla swojej potrzeby.
Do tego pojawiają się "strachy", wynikające z doświadczenia z BPM:
- może się nie dać zmigrować danych do nowej wersji procesu (a te są liczne, choć drobne)
- nie wiadomo co się będzie działo w następnym tasku (diagram BPMN jest kompletnie niezrozumiały, pokazuje tylko czubek góry lodowej, a cały sens i tak dzieje się wewnątrz tasków).
No i na koniec pojawia się poczucie bezsensu: "Zaraz ..., przecież to miało mi pomóc..., tymczasem wprowadza dodatkową biurokrację i masę ograniczeń..., po co mi to?"
PS:
Ja cały czas jestem entuzjastą BPM, należy jednak pomyśleć jak zmniejszyć powyższe negatywne emocje lub jak zamienić je pozytywną energię do działania, ale to już zupełnie inna bajka...
Zacząłem tworzyć na własne potrzeby procesy BPM.
Po uzyskaniu pewnej płynności wytwórczej,
czyli opanowaniu platformy na tyle by się nie douczać w trakcie realizacji,
mogę wdrażać całkiem złożone potrzeby w kilka godzin.
Dzięki temu konsekwentnie przestaje używać Excela do zarządzania pracą.
W BPM staje się to znacznie łatwiejsze.
To jednak pozwala mi doświadczyć tego co doświadcza użytkownik dla własnego biznesowego procesu.
Tak, żadne testy nie oddadzą realnej pracy i to takiej od której zależą decyzje w realnym świecie.
Z przerażaniem odkryłem,
że dla użytkownika cała BPM'owa wartość dodana (modelowanie, konfiguracja, środowiska, elastyczność, etc...) jest bezużyteczna i niezauważalna, jeżeli nie może on zrealizować ścieżki głównej dla swojej potrzeby.
Do tego pojawiają się "strachy", wynikające z doświadczenia z BPM:
- może się nie dać zmigrować danych do nowej wersji procesu (a te są liczne, choć drobne)
- nie wiadomo co się będzie działo w następnym tasku (diagram BPMN jest kompletnie niezrozumiały, pokazuje tylko czubek góry lodowej, a cały sens i tak dzieje się wewnątrz tasków).
No i na koniec pojawia się poczucie bezsensu: "Zaraz ..., przecież to miało mi pomóc..., tymczasem wprowadza dodatkową biurokrację i masę ograniczeń..., po co mi to?"
PS:
Ja cały czas jestem entuzjastą BPM, należy jednak pomyśleć jak zmniejszyć powyższe negatywne emocje lub jak zamienić je pozytywną energię do działania, ale to już zupełnie inna bajka...
poniedziałek, 9 września 2013
Ciężar ścieżek alternatywnych
W trakcie tworzenia funkcjonalności procesowych,
istnieje wielka pokusa by zrobić proces dobrze,
czyli obsłużyć wszystkie możliwe przypadki,
ułatwić wprowadzanie informacji na wszystkie możliwe sposoby,
zoptymalizować dane do co najmniej 3 postaci normalnej,
zadbać o wszelkie możliwe wyjątki techniczne
i ująć wszystkie możliwe komponenty (silnik BPM, silnik BI, silnik DMS, silnik RR, ESB).
Problem tkwi w tym,
że im więcej z powyższego zrobimy,
to tym więcej artefaktów będziemy mieli do zmiany,
jeżeli będzie zmiana biznesowa.
Zmiany biznesowe wynikają
z kreatywności i twórczości,
jaka jest wzbudzana,
w trakcie pracy w uporządkowanych założeniach,
które są wynikiem automatyzacji przebiegu pracy.
Jest tak, bo już nie trzeba używać wyobraźni,
by zdefiniować jak ma działać biznes,
bo widać braki, patologie i utrudnienia.
Kluczem jest zupełnie inna kolejność niż przy podejściu do aplikacji silosowych.
istnieje wielka pokusa by zrobić proces dobrze,
czyli obsłużyć wszystkie możliwe przypadki,
ułatwić wprowadzanie informacji na wszystkie możliwe sposoby,
zoptymalizować dane do co najmniej 3 postaci normalnej,
zadbać o wszelkie możliwe wyjątki techniczne
i ująć wszystkie możliwe komponenty (silnik BPM, silnik BI, silnik DMS, silnik RR, ESB).
Problem tkwi w tym,
że im więcej z powyższego zrobimy,
to tym więcej artefaktów będziemy mieli do zmiany,
jeżeli będzie zmiana biznesowa.
Zmiany biznesowe wynikają
z kreatywności i twórczości,
jaka jest wzbudzana,
w trakcie pracy w uporządkowanych założeniach,
które są wynikiem automatyzacji przebiegu pracy.
Jest tak, bo już nie trzeba używać wyobraźni,
by zdefiniować jak ma działać biznes,
bo widać braki, patologie i utrudnienia.
Kluczem jest zupełnie inna kolejność niż przy podejściu do aplikacji silosowych.
środa, 4 września 2013
Poziomy implementacji BPM
W jednym z moich pierwszych projektów BPM kierownikiem był fan wzorców projektowych w obszarze dobrego programowania.
Jednym z głównych założeń dobrego kodu jest wytwarzania kawałków funkcjonalnych, tak by miały zakodowane wszystkie docelowe mechanizmy.
W efekcie gdy mieliśmy ok 40% funkcjonalności biznesowych, które zostały dobrze oprogramowane, skończył się czas i budżet. Niestety bez brakujących 60% cały proces nie zadziałał (KP, jeżeli to czytasz to przepraszam Cię za sarkazm).
Problem polega na tym, że jak zwykle musieliśmy jak najszybciej i jak najtaniej zrealizować te braki (tak pominęliśmy zasady dobrego programowania).
No i te 60% funkcjonalności cały czas generuje błędy i sprawia, że rozwiązanie jest bardzo niestabilne.
Gdzie został popełniony błąd.
Otóż w rozwiązaniach BPM istnieje macierz funkcjonalności, poziomo są funkcjonalności biznesowo pionowo funkcjonalności technologiczne.
W ramach danego sprintu powinniśmy określić, które kwadraty będziemy realizować, a każdy kwadrat powinien być objęty zasadami dobrego programowania.
Uwaga, kolejność jest nieprzypadkowa, choć w zależności od priorytetów może ulec zamianie!
Oto funkcjonalności biznesowe (wiersze):
1. Ścieżka główna
2. Wyjątki główne
3. Ścieżki krytyczne
4. Wyjątki krytyczne
5. Ścieżki alternatywne
6. Wyjątki niezidentyfikowane
Oto funkcjonalności technologiczne (kolumny):
1. Obsługa struktury operacyjnej
2. Kierowanie procesem
3. Obiekt biznesowy
4. Obiekt kierowania procesem
5. Wsparcie diagnozy patologii
6. Wsparcie konserwacji środowiska produkcyjnego
7. Testy automatyczne
8. Wsparcie migracji instancji
9. Wsparcie wznawiania procesów
10. Przygotowanie danych BI
11. Raportowanie jakościowe i strategiczne
12. Raportowanie ilościowe i operacyjne
13. BAM
14. Archiwum dokumentów
Dla przykładu zrobienie ścieżki głównej z 14 funkcjonalnościami technologicznymi, sprawi że biznes zapomni o tym, że dla niego realizujemy projekt.
Jednym z głównych założeń dobrego kodu jest wytwarzania kawałków funkcjonalnych, tak by miały zakodowane wszystkie docelowe mechanizmy.
W efekcie gdy mieliśmy ok 40% funkcjonalności biznesowych, które zostały dobrze oprogramowane, skończył się czas i budżet. Niestety bez brakujących 60% cały proces nie zadziałał (KP, jeżeli to czytasz to przepraszam Cię za sarkazm).
Problem polega na tym, że jak zwykle musieliśmy jak najszybciej i jak najtaniej zrealizować te braki (tak pominęliśmy zasady dobrego programowania).
No i te 60% funkcjonalności cały czas generuje błędy i sprawia, że rozwiązanie jest bardzo niestabilne.
Gdzie został popełniony błąd.
Otóż w rozwiązaniach BPM istnieje macierz funkcjonalności, poziomo są funkcjonalności biznesowo pionowo funkcjonalności technologiczne.
W ramach danego sprintu powinniśmy określić, które kwadraty będziemy realizować, a każdy kwadrat powinien być objęty zasadami dobrego programowania.
Uwaga, kolejność jest nieprzypadkowa, choć w zależności od priorytetów może ulec zamianie!
Oto funkcjonalności biznesowe (wiersze):
1. Ścieżka główna
2. Wyjątki główne
3. Ścieżki krytyczne
4. Wyjątki krytyczne
5. Ścieżki alternatywne
6. Wyjątki niezidentyfikowane
Oto funkcjonalności technologiczne (kolumny):
1. Obsługa struktury operacyjnej
2. Kierowanie procesem
3. Obiekt biznesowy
4. Obiekt kierowania procesem
5. Wsparcie diagnozy patologii
6. Wsparcie konserwacji środowiska produkcyjnego
7. Testy automatyczne
8. Wsparcie migracji instancji
9. Wsparcie wznawiania procesów
10. Przygotowanie danych BI
11. Raportowanie jakościowe i strategiczne
12. Raportowanie ilościowe i operacyjne
13. BAM
14. Archiwum dokumentów
Dla przykładu zrobienie ścieżki głównej z 14 funkcjonalnościami technologicznymi, sprawi że biznes zapomni o tym, że dla niego realizujemy projekt.
poniedziałek, 2 września 2013
Proces BPM, a polska kombinatoryka
Nie wnikam, w to dlaczego tak jest, ale polski biznes cechuje duży poziom kombinatoryki.
Z pewnością wielu menadżerów uznaję ją za coś co trzeba zwalczać, jednak ona pozwala nam szybko reagować na zmieniający się kontekst biznesowy.
Proces BPM zamraża ścieżki główne, krytyczne a także definiuje katalog ścieżek alternatywnych. Zatem wydawałoby się, że kombinatoryka została opanowana.
Niestety obietnice elastyczności rozwiązań BPM nie spełniają się w naszym kraju, bo:
- procesy są skomplikowane, a wynika to z próby opisania naszej kombinatoryki
- w takich procesach instancje są niemigrowalne
- cały czas mamy problem z architekturą i bardzo często wykorzystujemy BPM do analityki strategicznej (raportowanie)
Wszystko powyższe sprawia, że drobna zmiana ciągnie się tygodniami i trwa dłużej niż zmiana w aplikacji silosowej.
Co więcej na koniec dnia okazuje się, że kombinatoryka jest w stanie przebić się przez BPM. Jeżeli może to używa do tego powrotu w wyjątkowych sytuacjach do Excella i papieru, a jeżeli jest to zakazana używa administratorów IT do zmian danych w procesach z użyciem API REST lub bezpośredniej zmiany w bazie BPM.
Od strony technologicznej to tykająca bomba.
Może jednak warto zawrzeć pokój z kombinatoryką, a można to zrobić za pomocą następujących założeń:
1. Po każdym HT i kroku wyliczeniowym ustawiamy task systemowy, w którym zrzucamy obiekt biznesowy do dedykowanej dla procesu struktury w pomocniczej bazie danych.
2. Budujemy mechanizm automatycznych testów, w którym każdy HT i krok wyliczeniowy jest zrównoleglony i pobiera on dane z bazy dla danego kroku dla wskazanego procesu (wcześniej zapisanego przez mechanizm z kroku 1)
W ten sposób otrzymujemy możliwość automatycznego testowania, automatycznego doprowadzania procesu do określonego kroku oraz możliwość sklonowania procesu (i odwzorowania w bazie kombinatoryki).
W ten sposób na jednym ogniu pieczemy, aż trzy pieczenie:
1. Automatyczne testy
2. Zbieranie danych dla zewnętrznego BI
3. Wznawianie procesów wzbogaconych kombinatoryką
Warto jest dodać więcej zadań systemowych…
wtorek, 27 sierpnia 2013
BPM musi być ładny!
BPM musi być ładny!
Dlaczego?
Sprawa jest prosta o wdrożeniu projektu BPM decydują nowocześni Menadżerowie, którzy są przyzwyczajeni do Web 2.0.
A co ze społecznością użytkowników końcowych?
Otóż oni przy przejściu do pracy zadaniowej muszą z wielu rzeczy zrezygnować:
Dlaczego?
Sprawa jest prosta o wdrożeniu projektu BPM decydują nowocześni Menadżerowie, którzy są przyzwyczajeni do Web 2.0.
A co ze społecznością użytkowników końcowych?
Otóż oni przy przejściu do pracy zadaniowej muszą z wielu rzeczy zrezygnować:
- z pracy z wykorzystaniem papieru, maila, czy telefonu
- starych kartotekowych aplikacji
- z przywilejów jakie dawały lokalne interpretacje centralnych procedur
- a przede wszystkim z wynagrodzenia za dostępność
Wartość dodana dobrze zrobionego procesu szybko przewyższy powyższe koszty.
Jednak w okresie przejściowym, musimy jakoś zrekompensować opór społeczny użytkowników końcowych.
Okres stabilizacji jest normą.
Optymalizacja leży u podstaw.
Ergonomia pracy, staje się ważna po nauczeniu się procesu.
Jednak kiepskiego wyglądu nikt nam nie wybaczy już od samego początku.
poniedziałek, 26 sierpnia 2013
Co tak na prawdę jest produktem wdrożenia BPM?
Dzisiaj miałem ciekawą rozmowę z prezesami średniej firmy usługowej, którzy chcą rozszerzyć usługi o obszar BPM.
Po długiej rozmowie, zadali mi takie oto proste pytanie:
Co tak naprawdę będziemy sprzedawać?
Tak proste pytania, zawsze dotykają sedna sprawy.
Oto tradycyjna perspektywa programistyczna:
W projekcie BPM dostarczamy system, w którym zaimplementowany jest proces lub zestaw procesów biznesowych.
Jednak by taki proces był w praktyce używany, w trakcie implementacji musi zajść kilka innych zjawisk biznesowych:
- w trakcie implementacji musimy zadbać o wszystkie ścieżki, zatem wykonywana jest standaryzacja procedury, która za tym procesem stoi
- w trakcie implementacji ścieżek alternatywnych zwykle odkrywamy, że w dużej mierze się powtarzają, zatem optymalizujemy procedurę biznesową
- w trakcie implementowania decyzji stwierdzamy nadmierny poziom skomplikowania procedury, zatem wykonywane jest odchudzanie procedury (lean)
- w trakcie dzielenia zadań pomiędzy aktorów, ustalamy co i jak poszczególne osoby mogą realizować, zatem porcjujemy wiedzę i minimalizujemy barierę wejścia pracowników w efektywną pracę
- w trakcie konfigurowania struktury operacyjnej odkrywamy rządzące nią patologie
Dodatkowo wbudowane w platformę mechanizmy SLA, eskalacji i BAM, eliminują subiektywną ocenę pracy, a także dostarczają informacji w trybie rzeczywistym w jakim stanie są obiekty biznesowe, a nie czy i jak pracują poszczególni pracownicy.
Z tej perspektyw wdrożenie projektu BPM jest projektem konsultingowo - doradczym, którego celem jest standaryzacja procedur i zwiększenie efektywności pracy, a sam proces jest tylko i wyłącznie narzędziem diagnostycznym dla badań prowadzonych w rzeczywistych warunkach, bez zniekształcenia o wiedzę badanej osoby.
Po długiej rozmowie, zadali mi takie oto proste pytanie:
Co tak naprawdę będziemy sprzedawać?
Tak proste pytania, zawsze dotykają sedna sprawy.
Oto tradycyjna perspektywa programistyczna:
W projekcie BPM dostarczamy system, w którym zaimplementowany jest proces lub zestaw procesów biznesowych.
Jednak by taki proces był w praktyce używany, w trakcie implementacji musi zajść kilka innych zjawisk biznesowych:
- w trakcie implementacji musimy zadbać o wszystkie ścieżki, zatem wykonywana jest standaryzacja procedury, która za tym procesem stoi
- w trakcie implementacji ścieżek alternatywnych zwykle odkrywamy, że w dużej mierze się powtarzają, zatem optymalizujemy procedurę biznesową
- w trakcie implementowania decyzji stwierdzamy nadmierny poziom skomplikowania procedury, zatem wykonywane jest odchudzanie procedury (lean)
- w trakcie dzielenia zadań pomiędzy aktorów, ustalamy co i jak poszczególne osoby mogą realizować, zatem porcjujemy wiedzę i minimalizujemy barierę wejścia pracowników w efektywną pracę
- w trakcie konfigurowania struktury operacyjnej odkrywamy rządzące nią patologie
Dodatkowo wbudowane w platformę mechanizmy SLA, eskalacji i BAM, eliminują subiektywną ocenę pracy, a także dostarczają informacji w trybie rzeczywistym w jakim stanie są obiekty biznesowe, a nie czy i jak pracują poszczególni pracownicy.
Z tej perspektyw wdrożenie projektu BPM jest projektem konsultingowo - doradczym, którego celem jest standaryzacja procedur i zwiększenie efektywności pracy, a sam proces jest tylko i wyłącznie narzędziem diagnostycznym dla badań prowadzonych w rzeczywistych warunkach, bez zniekształcenia o wiedzę badanej osoby.
piątek, 23 sierpnia 2013
Metoda kaskadowa nie dla BPM!
"Chodzenie
po wodzie i tworzenie oprogramowania wg specyfikacji są łatwe, o ile woda i
specyfikacja są zamrożone" - Edward V. Berard
Czy można zamrozić specyfikację procesu?
BPA miał w latach 2008-2012 swoje 5 minut.
Wiele dużych korporacji opisało w narzędziach klasy BPA (Business Process Analysis), zwykle w ARIS, swoje procesy biznesowe. Powstały opasłe księgi procesów.
Domek ARIS'a pilnował by zarówno konsultanci jak i biznes nie schodzili zbyt głęboko. Co więcej modelowane były procesy w wersji ASIS oraz życzeniowej TOBE.
Poza autorami, tak naprawdę nikt nie mógł tego zweryfikować, ani sprawdzić. A autorzy, kluczowi użytkownicy, po roku 2010 głównie brani z łapanki, rysowali diagramy na bazie własnej subiektywnej, ograniczonej lokalnie percepcji.
W efekcie do puki procesy były w ARIS i DOC'ach działały znakomicie.
Wtedy nadeszła era lekkich silników BPM.
Okazało się, że większość modeli BPA nie odpowiada nawet faktycznej ścieżce głównej, nie mówiąc o ścieżkach alternatywnych.
Źródłem tej rozbieżności, nie są ani brak kompetencji BPM konsultantów, ani brak woli i wiedzy Biznesu.
Nagle okazało się, że proces BPM musi być deterministyczny. Każdy proces musi mieć początek i koniec, każda usługa, human task, czy task systemowy musi mieć wejście i wyjście, a każda decyzja określone alternatywy.
Wpp wypadku proces BPM nie mógł być skończony.
A nawet gdy udało się zdeterminizować całość w oparciu o wiedzę kluczowego użytkownika, wychodziła na jaw skala jego subiektywnej interpretacji, która objawiała się oporem pozostałych użytkowników, czyli lawiną zmian i zgłoszeń błędów.
Jedynie charyzmatyczny lider po stronie Biznesu zamawiającego proces, mógł wyjść z twarzą z takiego procesu, poprzez siłowe narzucenie go wszystkim pracownikom.
Tylko jak w zleceniu zapisać taki wymóg: "Aby skutecznie wdrożyć proces BPM, konieczny jest charyzmatyczny lider biznesowy".
Pozostaje tylko AGILE i wdrażanie kolejnych działających iteracji.
czwartek, 22 sierpnia 2013
Magia platformy BPM
Platformy BPM mają swoje własne życie.
Realizując procesy biznesowe, które odzwierciedlają interpretację procedur i nawyki użytkowników biznesowych, podejmuje wyzwanie zrobienia z tego entropicznego systemu deterministycznego algorytmu.
Super...
Jednak nasza praca bazuję na abstrakcji platformy BPM jaka została wytworzona przez innych ludzi.
Super do potęgi 10'tej.
Tak jestem sfrustrowany tym, że zginęły mi baseny z funkcjonalnościami w obecnej wersji i wszystkich historycznych.
Realizując procesy biznesowe, które odzwierciedlają interpretację procedur i nawyki użytkowników biznesowych, podejmuje wyzwanie zrobienia z tego entropicznego systemu deterministycznego algorytmu.
Super...
Jednak nasza praca bazuję na abstrakcji platformy BPM jaka została wytworzona przez innych ludzi.
Super do potęgi 10'tej.
Tak jestem sfrustrowany tym, że zginęły mi baseny z funkcjonalnościami w obecnej wersji i wszystkich historycznych.
wtorek, 20 sierpnia 2013
Ile to jeszcze będzie kosztować?
Okazuje się, że znacznie ważniejszym pytaniem od "Kto za to zapłaci?",
jest pytanie "Ile to będzie jeszcze kosztować?".
To pytanie oddaje miejsce, w którym jest polski rynek BPM.
Niestety cały czas patrzymy na funkcjonalności procesowe przez pryzmat systemów IT.
Paradoksalnie dobry proces to taki, który ciągle wymaga optymalizacji.
Jeżeli uda nam się ustabilizować proces, oznacza to że zamroziliśmy biznes.
A zdrowy biznes jest w ciągłej zmianie.
Tylko jak zafiksować te prace?
jest pytanie "Ile to będzie jeszcze kosztować?".
To pytanie oddaje miejsce, w którym jest polski rynek BPM.
Niestety cały czas patrzymy na funkcjonalności procesowe przez pryzmat systemów IT.
Paradoksalnie dobry proces to taki, który ciągle wymaga optymalizacji.
Jeżeli uda nam się ustabilizować proces, oznacza to że zamroziliśmy biznes.
A zdrowy biznes jest w ciągłej zmianie.
Tylko jak zafiksować te prace?
poniedziałek, 19 sierpnia 2013
Kto ma za to zapłacić?
Obserwacja: "Od siebie wymaga się inaczej, niż za odpłatną usługę."
Podczas użytkowania aplikacji BPM kluczowi użytkownicy odkrywają, że coś można zrobić lepiej lub łatwiej. To coś traktowane jest jako wada aplikacji. Zatem zgłaszane jest jako usterka gwarancyjna.
Z takich zgłoszeń robi się lista, którą jeżeli policzymy według instancji procesów, rozrasta się do kilkudziesięciu prostych zagadnień.
Do tego część z tych zagadnień dotyka core aplikacji, czyli długu technologicznego jaki zaciągnęliśmy (wykonawcy lub platformy).
Tylko kto ma za nią zapłacić?
Za tym wszystkim kryje się mechanizm psychologicznego sumowania.
Użytkownik, podczas zgłaszania problemów, każde zagadnienie widzi oddzielnie, co więcej widzi tylko warstwę prezentacji, a nawet widzi wyłącznie to biznesowo mu źle działa (np. w kolumnie Cel wyjazdu wyświetla się miejscowość, do której jedzie delegowana osoba w procesie obsługi delegacji).
Biznesowo jest to oczywisty błąd i nie ma znaczenia, że w trakcie opracowywania prototypu i testów nie wyszło, że w polu cel ma się pojawiać opis wydarzenia na które jest wystawiona delegacja.
Jest to oczywisty błąd bo konsultant powinien to wiedzieć, skoro mu się płaci za jego usługę.
A konsultant godzi się na to, bo przecież zamianę jednej zmiennej można zrobić przy okazji.
W ten sposób powstaje zbiór małych zadań, który przy wyliczaniu pracochłonności jest sumowany.
Niestety funkcja suma nie oddaje istoty rzeczy. Bo za każdym małym zagadnieniem stoi dług technologiczny, do którego nie wypada nam się przyznać.
Wszędzie tam gdzie jest choć mały element subiektywności suma całości nie jest równa sumie części.
W efekcie za brakującą resztę nie ma kto zapłacić.
Rozwiązanie hipotetyczne:
1. Zbieramy małe zgłoszenia i naprawiamy je
2. Wdrożenie nowej paczki zawsze jest odpłatnym wydarzeniem i zawiera:
a. Przygotowanie listy zmian
b. Przygotowanie skryptów instalacyjnych
c. Przepracowanie testów automatycznych dla ścieżek głównych
d. Przeprowadzenie testów ręcznych dla ścieżek alternatywnych
e. Wdrożenie nowej wersji
f. Migrację procesów
Wydarzenie takie, powinno zawsze kosztować tyle samo i powinno być nie zależne od ilości zmian.
Tylko, czy jeżeli wprowadzimy taką procedurę BPM nadal będzie elastyczny?
Podczas użytkowania aplikacji BPM kluczowi użytkownicy odkrywają, że coś można zrobić lepiej lub łatwiej. To coś traktowane jest jako wada aplikacji. Zatem zgłaszane jest jako usterka gwarancyjna.
Z takich zgłoszeń robi się lista, którą jeżeli policzymy według instancji procesów, rozrasta się do kilkudziesięciu prostych zagadnień.
Do tego część z tych zagadnień dotyka core aplikacji, czyli długu technologicznego jaki zaciągnęliśmy (wykonawcy lub platformy).
Tylko kto ma za nią zapłacić?
Za tym wszystkim kryje się mechanizm psychologicznego sumowania.
Użytkownik, podczas zgłaszania problemów, każde zagadnienie widzi oddzielnie, co więcej widzi tylko warstwę prezentacji, a nawet widzi wyłącznie to biznesowo mu źle działa (np. w kolumnie Cel wyjazdu wyświetla się miejscowość, do której jedzie delegowana osoba w procesie obsługi delegacji).
Biznesowo jest to oczywisty błąd i nie ma znaczenia, że w trakcie opracowywania prototypu i testów nie wyszło, że w polu cel ma się pojawiać opis wydarzenia na które jest wystawiona delegacja.
Jest to oczywisty błąd bo konsultant powinien to wiedzieć, skoro mu się płaci za jego usługę.
A konsultant godzi się na to, bo przecież zamianę jednej zmiennej można zrobić przy okazji.
W ten sposób powstaje zbiór małych zadań, który przy wyliczaniu pracochłonności jest sumowany.
Niestety funkcja suma nie oddaje istoty rzeczy. Bo za każdym małym zagadnieniem stoi dług technologiczny, do którego nie wypada nam się przyznać.
Wszędzie tam gdzie jest choć mały element subiektywności suma całości nie jest równa sumie części.
W efekcie za brakującą resztę nie ma kto zapłacić.
Rozwiązanie hipotetyczne:
1. Zbieramy małe zgłoszenia i naprawiamy je
2. Wdrożenie nowej paczki zawsze jest odpłatnym wydarzeniem i zawiera:
a. Przygotowanie listy zmian
b. Przygotowanie skryptów instalacyjnych
c. Przepracowanie testów automatycznych dla ścieżek głównych
d. Przeprowadzenie testów ręcznych dla ścieżek alternatywnych
e. Wdrożenie nowej wersji
f. Migrację procesów
Wydarzenie takie, powinno zawsze kosztować tyle samo i powinno być nie zależne od ilości zmian.
Tylko, czy jeżeli wprowadzimy taką procedurę BPM nadal będzie elastyczny?
Start UP
W tym blogu zebrane są moje doświadczenia z wdrożeń rozwiązań BPM.
Głównie będę się skupiać na aspektach psychologicznych jakie występują w rzeczywistych projektach.
Mam możliwość opisania wielu kontekstów:
Głównie będę się skupiać na aspektach psychologicznych jakie występują w rzeczywistych projektach.
Mam możliwość opisania wielu kontekstów:
- Wykonawcy
- Zamawiającego
- Konsultanta BPM
- Użytkownika BPM
Jak również, mam możliwość opisania projektów, które są wdrażana w różnorodnej kulturze IT i świadomości BPM.
Wszystkie opublikowane posty mają charakter subiektywny i będą pisane według mojej interpretacji.
Subskrybuj:
Posty (Atom)