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ć:

  • 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.

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.

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?

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?

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:

  • 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.