RegułyChaosu

Temat zarządzania procesowego jest częstym tematem moich architektonicznych poszukiwań. Stąd i częstość powrotów tego tematu w formule mojego bloga. W dzisiejszych warunkach zarządzanie operacyjne (nie mylić z obrazem analityka biznesowego i nadzorczym, szczegóły rozróżniające we wcześniejszym wpisie) na bazie procesu end-to-end stało się już zbyt kosztowne, a zarządzać operacyjnie trzeba. Nawet zakładając, że są jeszcze jakieś firmy, które twierdzą, że funkcjonują w oparciu o procesy end-to-end, to bez hipokryzji – powszechna sytuacja wygląda tak, że istnieje „dział od procesów” żyjący w innym świecie, niż operacyjnie działająca firma.

Jak pisałem ostatnio, rozważając metody zarządzania procesowego trzeba stawiać na zdarzenia (w oparciu o architekturę EDA, Event-Driven Architecture) i regułową organizację działań (w oparciu o rozwiązania klasy BRM, Business Rules Management). Takie są bowiem na dziś uwarunkowania organizacji współczesnego biznesu. Na tym jednak nie kończą się możliwości oferowane przez koncepcję zdarzeń ani siła wyrazu zdarzeń.

Historycznie rzecz ujmując, koncepcja zdarzeń nie jest ani nowa, ani szczególnie odkrywcza. Nawet w oparciu o dość pobieżny przegląd stosowanych wzorców projektowych widać powszechność spojrzenia zdarzeniowego:

• sprzęt – w tej sferze w zasadzie nie ma innego trybu współpracy, każda komunikacja opiera się o sygnały i zdarzenia;
• model programowania systemowego – wszystkie systemy na najniższym poziomie, np. systemy operacyjne, aplikacje w środowiskach graficznych, działają na zasadzie odpowiedzi na zachodzące zdarzenia;
• modne obecnie metodyki projektowania rozwiązań – dla przykładu Domain-Driven Design i jego podstawa, czyli Event Storming, traktują zdarzenia jako fundament modelowania domeny biznesowej, a najczęstszym wzorcem implementacyjnym jest zapisywanie zachodzących zdarzeń z których odtwarza się stan obiektu (choć nie tylko to);
• obserwowanie zmian w danych – w sferze operacyjnej zdarzenia identyfikowane na podstawie stanu danych i korelacji zmian w danych (wraz z technologią dla tego celu, Complex Event Processing), w sferze analitycznej fundamentem jest identyfikacja zmian w danych obiektów pomiędzy cyklami zasilania hurtowni.

Takich przykładów jest więcej, ale taka ich porcja chyba już wystarczy. Dlaczego zdarzenia? Bo to jest naturalny sposób działania człowieka. Na najbardziej podstawowym poziomie wcale nie jesteśmy ani procesowi, ani racjonalni – na najbardziej naturalnym poziomie reagujemy na bodźce w określonym kontekście. Opis świata sformułowany w taki sposób rozumiemy instynktownie i potrafimy się w nim szybko odnaleźć. Takie właśnie, instynktowne zrozumienie przenosimy na różne sfery świadomego działania, między innymi zarówno na grunt tworzenia jak i użytkowania rozwiązań informatycznych.

Zdarzenia, zarówno ze względu na spójność z naturalnym sposobem postrzegania jak i z powodu efektywności obsługi „w systemach” stanowią wspólny mianownik na wszystkich poziomach abstrakcji architektury. To na nich należy budować fundamentalne pryncypia architektury korporacyjnej, rozwiązań i oprogramowania. Uproszczenia i spójność to najlepsza strategia i recepta na sukces.

W prostych skojarzeniach, zarządzanie procesowe = BPMS, wydawałoby się, temat znany i ograny. Wydawałoby się. Wpadłem ostatnio w środek dość już „nabrzmiałego wyzwaniami” projektu wyboru „platformy BPMS”. Projekt przeprowadził RFI, RFP i nadal nie było wiadomo, co wybrać. Pierwsza diagnoza polegała na tym, że pomylone zostały pakiety komercyjnych środowisk z BPMS w nazwie, z koncepcjami narzędzi zarządzania procesowego. To pomieszanie doprowadziło do serii nieporozumień, kilku awantur i braku decyzji. Ale udało się wyprostować, a przepis na to poniżej.

Skuteczne działanie musi cechować celowość. Sfera danych staje się coraz bardziej złożona, przez co zachowanie celowości i skuteczności w tych nowych warunkach staje się często poważnym wyzwaniem. Wszak operujemy na danych nie po to, żeby mieć raport. Zdecydowanie nie! Na danych operujemy po to, żeby rutynowo podejmować w codziennych działaniach operacyjnych trafniejsze decyzje i robić to szybciej. Wiedza i zrozumienie danych to krok do celu, a nie cel sam w sobie – tak samo, jak ze zrozumienia reguł rządzących giełdą nic nie wynika, a wynika dopiero z zastosowania tej wiedzy.

Rewolucja inteligencji obliczeniowej (Machine Learning, Deep Learning) trwa i w końcu zmieni wszystko. Zapewne potrwa to jeszcze kilka lat lub dekad, ale w końcu kod programu zostanie zastąpiony przez dane. Wartość z danych można jednak masowo wydobywać już teraz, bez uciekania się do tych najpotężniejszych narzędzi. Kluczowym terminem jest tu zwinność, której osiągnięcie zapewnia te możliwości. Wymaga to jednak wprowadzenia zmian w stanie posiadania i sposobie użytkowania parku maszynowego technologii informatycznych.

Zwinność (agile) i chudość (lean) to terminy, które na dobre już zintegrowały się z myśleniem o rozwoju systemów informatycznych. Wiemy już jak zwinnie realizować projekty informatyczne, a nawet z relatywnie dużym prawdopodobieństwem umiemy tę wiedzę wykorzystać w praktyce. Aplikujemy tę wiedzę jednak do sfery funkcjonalności rozwiązań informatycznych, nie zaś do sfery danych. Jak zbudować fundament dla zwinności w sferze danych? O tym właśnie poniżej.

CRM to filozofia działania. Choć to trywialne, bardzo rzadko spotykam się z przedsięwzięciem o nazwie CRM, które nie zaczynałoby się od „wdróżmy system CRM”. Równie trywialną jest konstatacja, że o skuteczności rozwoju organizacji trudno dzisiaj marzyć bez wsparcia rozwiązaniami informatycznymi. Jak określić rolę systemu CRM, aby pomagał on w realizacji filozofii CRM?

Wartość danych. To cyklicznie powracający temat dyskusji, naprzemiennie z szybkością budowy aplikacji. Kiedy, jak wynika z tego cyklu, przychodzi pora na dane, pojawiają się nowe odsłony rozwiązań skupiających się wyłącznie na przetwarzaniu danych. W efekcie, jak kiedyś w centrum uwagi znajdowały się hurtownie danych i rozwiązania Business Intelligence, tak teraz podstawowa tematyka dyskusji to BigData i sztuczna inteligencja.