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?

Brak komentarzy:

Prześlij komentarz