RegułyChaosu

Pracując z różnymi firmami mam okazje obserwować ich działania z różnych perspektyw. Daje to często możliwość porównania sposobu ich działania. Ostatnie okoliczności u jednego z moich klientów zainicjowały porównanie z innym moim klientem, z nieodległej przeszłości. Firmy z zupełnie różnych branży, podobne jednak w charakterze wsparcia technologicznego (automatyka przemysłowa, IT, sieć), a jednak realizujące odmienne podejście do zagadnienia „robić właściwie rzeczy właściwe”.

Naruszenia bezpieczeństwa dotyczą najczęściej nie tych, którzy są uzbrojeni po zęby lecz tych, którzy są bezbronni – często na własne życzenie. Pracując w projektach IT obserwuję często „drogi na skróty”, także w sferze bezpieczeństwa. Najczęstsze samousprawiedliwienie – „ten projekt ma zrobić <to, czy tamto>, a nie naprawiać cały świat w zakresie bezpieczeństwa” – działa doskonale. Wszak, skoro nikt wcześniej nie zrobił tego „zgodnie i od początku do końca”, to „ja też nic nie muszę z tym zrobić”. W efekcie każdy projekt pogarsza sytuację, choć wystarczyłoby zachować minimalną higienę działania. I to naprawdę kosztem niewielkiego wysiłku.

Do tego, że składową przekazu dotyczącego Cloud Computing  jest marketingowo wzmacniany hype nie trzeba chyba przekonywać. O krytycznym spojrzeniu na skalę hype w komunikacji zagadnień chmurowych, na przykład w odniesieniu do uzasadnień finansowych usług chmurowych, napisano już wiele. Rzecz jasna, nie tak wiele, jak marketingu w tej sprawie. Dodałem także kilka groszy od siebie do tej publicznie prowadzonej dyskusji. Jednym z warunków urzeczywistniania tak fantastycznych business case jest zdolność do prowadzenia skutecznych procesów zakupowych. Czy kontekst zakupów chmurowych coś tu namiesza?

O tym, że co innego kieruje architekturą systemu chmurowego już uprzejmie donosiłem. Siły ekonomiczne, choć najmocniej odczuwalne w praktyce działań z rozwiązaniami chmurowymi, nie są jednak jedynymi czynnikami wpływu. W kilku innych przypadkach trzeba się będzie najprawdopodobniej od nowa nauczyć obsługi codziennych zadań związanych z posiadaniem ICT.

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

„Cloud, czy on-premises” wchodzi już na stałe do kanonu procesów decyzyjnych o sposobie realizacji przedsięwzięć informatycznych. Na szczęście mamy już za sobą czasy naiwnego rachunku kosztów i dysponujemy doświadczeniem pozwalającym na znacznie głębsze zrozumienie mechanizmów związanych z ekonomiką rozwiązań chmurowych i skutkujących racjonalizacją kosztów posiadania informatyki.

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.