Krzysztof Olszewski

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

Krzysztof Olszewski

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

Czasem jest tak – coś wydaje się bardzo sensowne, bardzo pomysłowe i przydatne, wydaje się, że rozwiązuje to wiele problemów i nieuniknione jest aby się spopularyzowało. Jeżeli jest to technologia, to ma szanse znaleźć się na krzywej Hype’u Gartnera. Krzywa ta od lat pokazuje (wg analityków firmy Gartner) jak rynek przyswaja innowacje. Analitycy wspomnianej firmy, zauważyli pewne powtarzające się prawidłowości i uznają, że każdy produkt, pomysł, technologia, jeżeli odnosi sukces, to przechodzi przez te same etapy. Uogólniony wykres takiego procesu wygląda tak:

krzywa Hype’u Gartnera

 

Wszystko zaczyna się od innowacji, która na początku nieznana, jeżeli jest „potencjalnie dobra” to będzie bardzo szybko zdobywać popularność, rozgłos, zachęcając wielu do jej wdrożenia. Zmierza w ten sposób do szczytu w którym zazwyczaj okazuje się, że znaczna część jej potencjału wynika z marketingu i początkowej euforii. W zderzeniu z realiami popularność zaczyna spadać, wychodzą wady, problemy, w efekcie dochodzimy do punktu rozczarowania. Jeżeli w tym punkcie nastąpi odbicie, a nasza innowacja staje się stabilna, rozwinięta, często już w drugiej czy trzeciej wersji, ma szanse wejść na krzywą wzrostową ale o rozsądnym, uzasadnionym nachyleniu. Po pewnym czasie podróżowania tą krzywą innowacja osiąga na tyle duży potencjał, że zaczyna być szeroko stosowana, staje się pewnym i sprawdzonym rozwiązaniem, które można bezpiecznie wdrażać. Oczywiście jest to ścieżka optymalna, obserwowana w produktach które odniosły rynkowy sukces, wiadomo, że w każdej chwili innowacja może wypaść z ścieżki, zwolnić tempo, nie osiągnąć kolejnego etapu, … zniknąć.

Prawie dokładnie tak stało się z wieloma technologiami z grupy BPM (Business Process Management). Patrząc na dane z 2015 roku, obszar „Plateau of Productivity” osiągnęło zaledwie kilka z kilkudziesięciu technologii pokrewnych BPM, co mnie osobiście w tamtych czasach bardzo dziwiło. Trudno mi było zrozumieć jak to możliwe, że powszechnie nie zarządzamy procesami w biznesie, nie traktujemy biznesu jako zbioru procesów, w końcu nie automatyzujemy, nie monitorujemy ani nie optymalizujemy tych procesów robiąc to wszystko w jakiś usystematyzowany sposób (wiem, lekko przesadzam, bo jednak były i są organizacje, które to w pewnym zakresie robią).

Jednym z kierunków który wyjaśnia w/w zjawisko mogła by być powszechna transformacja organizacji do tak dynamicznych struktur, że aż ocierających się o chaos. Pisałem kiedyś, że po dawnym „jedno co jest pewnie to zmiana”, w dzisiejszym biznesie przychodzi nowe hasło „jedno co jest pewnie to chaos”. Czy zdefiniowane i ustalone – jakby nie było – procesy mogą usprawniać zarządzanie dynamizmem tak znacznym, że aż bliskim chaosowi? Wydaje mi się, że tak. Tym bardziej, z dużym zadowoleniem, przyjmuje informacje o nowej odsłonie BPM. Gdy połączymy ze sobą nowoczesne technologie i narzędzia spod znaku Cloud Computing, LowCode, NoCode, AI, BPM, Workflow, WebServices, Automation – otrzymujemy w wyniku coś co nazwano:

iBPM
Intelligent Business Process Management

czyli inteligentną wersję klasycznego zarządzania procesami biznesowymi. A systemy informatyczne które to wspierają określa się mianem iBPMS (Intelligent Business Process Management Software). Nowa odsłona starej koncepcji? Tak, ale tym razem wydaje się, że widać większe szanse na popularyzację i sukces rynkowy. Może tym razem będzie lepiej. Gartner nie szacuje na razie zbyt wysoko samego rynku dla iBPM’a, ale wskazuje jednocześnie ogromną dynamikę rozwoju. Co mnie osobiście cieszy. Można by zapytać, dlaczego?

Czy wiecie jak wygląda 99% softu na świecie? No przecież wiecie. Są to pliki tekstowe (z różnymi rozszerzeniami) w środku z linijkami w których jest napisane dużo różnych znaczków, one coś tam znaczą, są napisane w jakimś języku (wielu), takich plików jest bardzo dużo, są pogrupowane, czasem lepiej, czasem gorzej, część tych plików nie robi nic przydatnego tylko ma wykazać, że tekst w innych plikach jest poprawny, znowu inne pliki mówią, jak to coś zamienić na działający program, system, jak dostarczyć do środowiska produkcyjnego, mogę tak wyliczać długo, znamy to. Dodajmy tylko, że dzisiaj nie ma już oprogramowania które powstaje ot tak sobie samodzielnie, te wszystkie pliki zależą od tysięcy innych plików z narzędziami, bibliotekami, framework’ami, uff. powstaje ogromna wieża Babel, tak złożona, że nie ma jednej osoby która by to wszystko rozumiała. Aż dziw bierze, że to działa. I teraz postawcie się w roli Biznesu.

Biznes mniej więcej zna zasady wg których funkcjonuje (zazwyczaj :)). Chciałby aby software definiował / zarządzał / usprawniał / automatyzował to, jak on działa. Co robi wtedy IT? IT siada do pisania tych swoich plików tekstowych, twierdząc, że to jest konieczne, że inaczej się nie da! Stawiam pytanie:

Dlaczego IT nie definiuje procesów biznesowych dokładnie

tak jak je Biznes opisuje i jak je rozumie?

Dlaczego wciąż budujemy ten mur niezrozumienia, tworzymy armagedon kosztów, brniemy w tą tekstową otchłań? Czy automatyzacja, zarządzanie, optymalizacja nie może odbywać się poprzez definiowanie zamiast poprzez kodowanie? Siadajmy z Biznesem i rysujmy diagramy zamiast ukrywać się za biurkami i pisać dziwne teksty. Twórzmy diagramy które z jednej strony pokazują proces, definiują go i dokumentują, a z drugiej strony są „uruchamialne”, działające, wykonywalne czy w końcu dają się monitorować, analizować, optymalizować. Czyż nie? …

Zobaczmy przykład z „naszego podwórka”. Jak w Streamsoft Verto zautomatyzować proces obsługi zamówienia? Można klasycznie, przechwycić zdarzenia, napisać reakcje na te zdarzenia w postaci prostego skryptu, wywołać kilka usług, bo cały system składa się z usług (super fajnie :), do tego pewnie jakieś zdarzenia okresowe, tak, to działa. Można też inaczej. Można w module Workflow zdefiniować jawnie proces, narysować jego schemat w notacji BPM, po czym wdrożyć go i już … działa.

proces obsługi zamówienia schemat

Zauważmy, że taki proces, dokładnie tak samo jak nasze kodowanie w skryptach, może reagować na zdarzenia zarówno techniczne jak i biznesowe. Może być wyzwalany zdarzeniami czasowymi, ponadto może angażować, kiedy trzeba, operatorów systemu do pewnych działań. Może zawierać dowolnie złożoną logikę z tą kodowaną skryptami włącznie. Po każdej instancji procesu pozostaje ślad, z dokładnymi parametrami ilościowymi i jakościowymi. Można te dane poddać analizie i na ich podstawie przeprowadzić optymalizację. Czyli też dobrze, a nawet lepiej i Biznes patrząc na tak zdefiniowany proces też go zrozumie … w końcu. Czy Workflow w Streamsoft Verto to już pełnokrwisty iBPMS? Nie, jeszcze nie, ale może już czas najwyższy pomyśleć, aby tak było.