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.