10x Business Analyst

10xPojęcie 10x Developer już chyba weszło do języka powszechnego i jest dość dobrze zrozumiałe. Gdyby w przypadku zaciekawionego tytułem wpisu czytelnika, tak nie było, polecam krótkie jego wyjaśnienie. Naszła mnie niedawno myśl, dlaczego nie mówi się o 10x Analitykach Biznesowych? A przynajmniej, nie słyszałem, aby się mówiło.

W całej swojej karierze zawodowej poznałem (ale za to, dość dobrze) jednego 10x Dewelopera. Ponieważ miałem okazję zetknąć się z tą osobą już na początku mojej zawodowej przygody z IT, bardzo szybko zrozumiałem, że nigdy nie będę dobrym deweloperem, i pomyślałem, że może lepiej będzie jeśli zajmę się analizą. Próbuję sobie w głowie ułożyć charakterystykę teniksa i jawi mi się ona następująco:

  • ogromna wiedza z zakresu programowania zarówno w obszarze teoretycznym (algorytmy + struktury danych) jaki i językowym (zapomniane już prawie COBOLE, Prologi, Lispy, Pascale a nawet Turbo, SmallTalki, C, i bardziej współczesne C++, Java, VS, itd…),
  • duża wiedza o tzw. okolicach programowania (projektowanie, architektura systemów, także analiza systemowa),
  • koncentracja na zadaniu,
  • stałe dokształcanie się (doczytywanie, dyskutowanie, weryfikowanie).

Z mojego punktu widzenia, była to osoba, do której na tzw. pewniaka szedłem, gdy potrzebowałem zrozumiałego wyjaśnienia jakiegoś pojęcia z zakresu projektowania, architektury systemów czy technologii IT. W 90% przypadków otrzymywałem satysfakcjonującą mnie odpowiedź – nawet jeśli była daleka od tego, co aktualnie robiliśmy, a w pozostałych przypadkach, odpowiedź uzyskiwałem po chwili, po doczytaniu.

Przez ostatnie naście lat miałem okazję trafić do małych, średnich, dużych i bardzo dużych zespołów analitycznych u naszych Klientów. Próbuję sobie przypomnieć, ilu 10x Analityków Biznesowych czy Systemowych napotkałem. I wyszło mi, że jednego (słownie: jednego). A w zasadzie, jedną. Oczywiście, poznałem mnóstwo dobrych, czy nawet bardzo dobrych analityków, ale 10x, jak wyżej.

Próbując znaleźć wspólne cechy, od razu przyszło mi na myśl – stałe dokształcanie się. W obydwu przypadkach, gdy widziałem, że osoby te nie realizują aktualnie niczego bieżącego (nawet jeśli to był krótki odpoczynek pomiędzy zadaniami) na monitorze widać było jakiś portal albo blog zawodowy. Pamiętam, że parokrotnie zapytałem, skąd zainteresowanie tematem – odpowiedzi padały także w stylu Nie wiem tak do końca, gdzieś zauważyłem hasło i doczytuję.

Bardzo rzadko widzę takie czytelnicze odruchy w projektach wśród analityków biznesowych i systemowych. Nie mam wiedzy, by podać przyczyny źródłowe takiego stanu rzeczy, ale fakt pozostaje faktem. Rzadko prowadzę też rozmowy rozpoczynające się od sformułowań Wiesz, czytałem ostatnio o, nie orientujesz się co to jest, wiesz, że w takiej publikacji zalecono. Często natomiast słyszę, że w prawdziwym świecie, gdybym był na uczelni, tak w teorii. Na pytanie, czy coś więcej o tym wiesz, czy próbowałeś najczęściej słyszę różne odmiany sformułowania Panie! Kto ma na to czas?

Kto ma na to czas? Gdy znajdę drugiego 10X Business Analyst, dam znać.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Analiza biznesowa jest zbyt trudna, czy brakuje kompetentnych analityków biznesowych?

Notebook and coffee with copy space on a wooden background. selective focusTakie pytanie (wydaje się, że retoryczne) padło podczas dzisiejszej, niespodziewanej, popołudniowej rozmowy telefonicznej zainspirowanej wpisem o architekturze procesów. A nawet się nie wydaje – jest retoryczne. Wykształconych analityków biznesowych brakuje. Głównie dlatego, że żadna uczelnia, w cyklu dziennym, ich nie kształci. Kształcą studia podyplomowe, ale pół roku, czy rok to zdecydowanie za mało. Brakuje mistrzów, przy których młody adept (dawniej, czeladnik) mógłby się uczyć i nauczyć. Mistrzów brakuje, ponieważ jeśli ktoś jest wyjątkowo zdolny i jakimś cudem dane mu było pracować i poszerzać przez dziesiątki lat swoją wiedzę i praktykę, to pracuje na 200% i nie ma czasu na dyrdymały. Brakuje wewnątrzorganizacyjnych metodyk analizy, gdyż brakuje mistrzów, którzy dostosowaliby dziesiątki standardów analizy biznesowej do realiów firmy, a mianowani, trzydziestoletni Senior Specials, Evangelists, Experts nie radzą sobie z zadaniem (i nic w tym dziwnego).

Pojawia się pytanie, czy jest szansa na poprawę? Systemowej, nie widzę. Mój rozmówca, także. Rynkowa…może, wraz ze wzrostem (powolnym) świadomości, że kapitałem firmy są kompetentni i zmotywowani ludzie oraz tego, że są problemy, których nie da się rozwiązać tuzinem (i wielokrotnością) dobrych ludzi, lecz jedynie co najmniej jednym wybitnym, coś ulegnie poprawie? Kto wie?

Trzymam(y) kciuki. Na razie jest smutek.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Evergreen, czyli architektura procesów biznesowych część 2

Fred Astaire Small

Fred Astaire

 

Przeglądnąłem wczoraj statystykę popularności wpisów, i ku mojemu miłemu zaskoczeniu, w czołówce, przez prawie dwa lata, znajduje się krótka wypowiedź o znaczeniu architektury procesów dla prac analitycznych. Oczywiście, na podstawie jednego spostrzeżenia nie należy wyciągać żadnych głębokich wniosków, ale żywiąc nadzieję, iż jeden z nich jest zbliżony do choć odrobinę trafnego, postanowiłem rozszerzyć temat, i sięgnąć zarówno do klasyki (Geary Rummler), jak i współczesności (Martyn Ould). I nie będzie to żaden cover, tylko pokazanie, w jaki sposób można, łącząc różne doświadczenia, uporządkować to co często bywa nieuporządkowane. Czyli architekturę procesów. A nawet ciut więcej – architekturę biznesową.

Zarządzamy procesami (a przynajmniej tak twierdzimy), mamy ich tysiące (to widać w repozytorium), poświęcamy na ich opisanie mnóstwo czasu (to widzimy po niskiej dostępności analityków procesowych), procesy są bardzo złożone i wyjątkowo specyficzne (bo my w ogóle jesteśmy inni niż setka innych firm działających w tej branży i robiących to samo).

-I co?

I jakoś nie udaje nam się nad tym zapanować na wysokim poziomie. Mamy poczucie, że szlifujemy szczegóły, które nie „spinają się” na poziomie makro. Więc szlifujemy dalej szczegóły … może się zepnie.

Szerzej oczywiście można byłoby pisać o symptomach świadczących o „nie spinaniu się”, ale temu być może poświęcę osobny wpis. W bieżącym, szybko będę zmierzał do pomysłu na zredukowanie problemu. Geary Rummler (jeden z moich tzw. guru), lata (świetlne, z punktu widzenia szybkozmiennego, współczesnego świata) temu, w ramach ogólnej koncepcji zarządzania wykonaniem (ang. performance improvement) opracował koncepcję Mapy Supersystemowej (ang. supersystem map). Mapa supersystemowa obrazuje otoczenie organizacji oraz jej wewnętrzną strukturę. Kluczowym z punktu widzenia rozważań niniejszego wpisu elementem mapy jest jej centralny blok zawierający działania zarządcze (ang. managing), wspierające (ang. contributing) oraz systemy tworzenia wartości (ang. value creation system) . Tak opisana struktura działań organizacji stanowi podstawę do stworzenia zarządzalnego, w oparciu o koncepcję procesową, systemu. Warto przy okazji pamiętać, iż system to układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość (definicja zaczerpnięta ze Słownika Języka Polskiego PWN). Aby stwierdzić, czy organizacja stanowi system, należy uwidocznić jej strukturę – czyli stworzyć jej model.

VCS

Mapa supersystemowa

O ile działania zarządcze oraz wspierające powinny być dobrze znane osobom zajmującym się wdrażaniem procesowego podejścia do zarządzania organizacją, o tyle systemy tworzenia wartości wymagają wyjaśnienia. Zgodnie z teorią Geary’ego Rummlera systemy tworzenia wartości powinny być konstruowane zstępująco (ang. top-down), poczynając od wyższych poziomów abstrakcji, a kończąc na poziomie pracy realizowanej na określonym stanowisku. Tak stworzona struktura jest nazywana w metodyce hierarchią tworzenia wartości (ang. value creation hierarchy). Poziom najwyższy, to deklaracja systemów tworzenia wartości. Duże organizacje zwykle będą miały wiele takich systemów – ich liczba stanowi wypadkową skali i różnorodności działania oraz granulacji systemów. W założeniu, pojedynczy system tworzenia wartości powinien być zarządzalnym jako całość przez określoną jednostkę biznesową, ciągiem działań prowadzących do dostarczania Klientom organizacji określonego rodzaju produktu, za który dana jednostka odpowiada. Dla przykładu, w instytucji finansowej można wyobrazić sobie jeden system tworzenia wartości produktu kredytowego, ale równie dobrze można wyobrazić sobie kilka systemów wartości w tym obszarze, na przykład biorąc jako dodatkowy wyróżnik segmentację Klientów. Wówczas można byłoby otrzymać system tworzenia wartości produktu kredytowego dla klientów korporacyjnych,  system tworzenia wartości produktu kredytowego dla małych i średnich przedsiębiorców oraz system tworzenia wartości produktu kredytowego dla klientów indywidualnych. Poziom granulacji systemów tworzenia wartości, jak łatwo się domyślić nie jest ustandaryzowany i wynikać powinien bezpośrednio ze specyfiki organizacji.

W kolejnym kroku dekompozycji, w ramach każdego z systemów wartości należy wyróżnić trzy obszary działań – wytworzenie (ang. launched), sprzedanie (ang. sold) oraz dostarczenie (ang. delivery). Każdy z obszarów jest odpowiedzialny za wiodące pojęcie:

  • wytworzenie – ma na celu dbać o cykl życia produktu (bądź usługi), począwszy od pomysłu nań, na wycofaniu z oferty zakończywszy.,
  • sprzedanie – ma na celu pozyskanie oraz utrzymanie Klienta na produkty (bądź usługi) wchodzące w zakres danego systemu tworzenia wartości,
  • dostarczenie – ma na celu obsłużenie zamówienia na określony produkt (bądź usługę), począwszy od złożenia zamówienia, na zakończeniu obsługi produktu zakończywszy.

Innymi słowy i w pewnym uproszczeniu, pierwszy z obszarów obejmuje cykl życia produktu, drugi – cykl życia Klienta, trzeci natomiast – cykl życia zamówienia. Między obszarami można sobie wyobrazić relacje wskazujące na fakt, iż dany obszar może funkcjonować przy założeniu, iż w poprzedzającym go obszarze wykonano już jakąś część prac (na przykład, Sprzedawanie może się rozpocząć, gdy Wytworzenie dostarczy opis finalnego produktu, aczkolwiek produkt może być jeszcze niedostępny dla Klientów). Relacje tego typu zostały na poniższym schemacie oznaczone linią ciągłą. Linia przerywaną zaznaczono potencjalną zasadność dostarczania informacji zwrotnych dla obszarów. Dla przykładu, może być zasadnym dostarczanie z poszczególnych wystąpień działań z obszaru dostarczania informacji o udzielanych upustach, reklamacjach oraz sugestiach odnośnie potencjalnych modyfikacji produktu zgłaszanych przez Klientów.

VCS (L2)

Pierwszy poziom dekompozycji systemu tworzenia wartości

Wnikliwemu czytelnikowi może szybko przyjść na myśl pytanie, czy ten poziom dekompozycji systemu tworzenia wartości ma na celu jedynie dostarczenie bazy do dalszych rozważań, czy tez może być wykorzystany do podejmowania jakichkolwiek decyzji biznesowych (pomimo faktu, iż każdy z systemów tworzenia wartości będzie dekomponowany w taki sam sposób). Pytanie trafne, a odpowiedź brzmi – na tym poziomie można już podejmować decyzje biznesowe. Jednym z przykładów jest poniższy rysunek koncepcyjny, prezentujący działania związane z obsługą Klienta jako wspólne dla wszystkich systemów tworzenia wartości. Podjęcie takiej decyzji, oznaczać będzie w praktyce konieczność zapewnienia między innymi  jednolitego spojrzenia na Klienta we wszystkich strumieniach produktowych, zapewnienia wsparcia narzędziowego (przede wszystkim wsparcia IT) umożliwiającego międzyproduktowe relacje z Klientami (np. crossselling), wdrożenia praktyk zarządczych umożliwiających utrzymanie jednolitości kontaktów z klientem w różnych jednostkach biznesowych.

Na tym poziomie opisu organizacji można także pokusić się o przypisanie jednostek organizacyjnych do realizacji prac w każdym z trzech obszarów systemu tworzenia wartości. Przypisanie to może w niektórych przypadkach rodzić konieczność podjęcia istotnych decyzji biznesowych i tym samym dostarczyć jako technika zauważalne korzyści.

VCS (L2) v1

Przesądzenia architektury biznesowej na wysokim poziomie opisu organizacji

Kolejnym poziomem dekompozycji systemów tworzenia wartości jest wskazanie procesów uczestniczących w realizacji poszczególnych obszarów. Jest to więc moment, w którym dotykamy bezpośrednio tematyki architektury procesów biznesowych, a tym samym problemu, jak ja tworzyć. Metodyka G. Rummlera, nie będąc wyjątkiem, pozostawia analityka procesowego (analityka biznesowego, architekta biznesowego) samemu sobie, nie podając wskazówek, jakimi należy się kierować podczas próby interpretacji pracy realizowanej w organizacji w terminach procesów. Jest to moim zdaniem spory jej mankament, gdyż utworzenie spójnego w ramach organizacji systemu procesów jest zadaniem bardzo trudnym, i bez podania choćby podstawowych kryteriów identyfikacji procesów, prawdopodobieństwo uzyskanie jednolitego podziału jest nieduże.

W sukurs dojrzałej i ustabilizowanej metodyce może przyjść Trzecia Fala Procesowości, czyli metodyka Riva opracowana przez Martyna Oulda. Okrzyknięta przez specjalistów z szeroko pojętego obszaru zarządzania procesami (ang. Business Process Management) jako powiew świeżego powietrza w dojrzałej już dziedzinie, Riva dostarcza kilka fundamentalnych wartości, spośród których do najważniejszych należy zaliczyć kilkuetapowy proces dochodzenia do architektury procesów biznesowych.

Punktem wyjścia do rozważań na temat architektury procesów w metodyce Riva jest model pojęć (albo model informacyjny organizacji, który jest tworzony na tym samym poziomie abstrakcji), którego przykład prezentuje poniższy rysunek. Na potrzeby dalszych rozważań, przyjmijmy, że Produkt, jako pojęcie abstrakcyjne jest konkretyzowany między innymi poprzez Produkt kredytowy. Każdy produkt wprowadzany na rynek wymaga przeprowadzenia określonej liczby Badań jakościowych, które mają potwierdzić bądź obalić czynione przy jego konstruowaniu założenia. Produkty tworzone są z myślą o określonych Segmentach, które kategoryzują Klientów obsługiwanych przez organizację.

MP (1)

Model pojęć

Model pojęć, opisany diagramem, stanowi integralną część modelu opisującego organizację na poziomie biznesowym, dostarczając aparatu pojęciowego potrzebnego do właściwego rozumienia pozostałych składowych modelu architektury biznesowej. Podobnie i w tym przypadku, model ten będzie stanowił punkt wyjścia do określenia architektury poprzez:

  1. zaklasyfikowanie poszczególnych pojęć do kategorii przedmiotu pracy (ang. unit of work),
  2. określenie relacji typu generates, pomiędzy przedmiotami pracy,
  3. utworzenie sieci procesów skupionych wokół pojedynczego przedmiotu pracy oraz relacji generates z innymi przedmiotami pracy według określonego wzorca,
  4. dostosowanie wzorcowej architektury do specyfiki organizacji.

W opisywanym podejściu, za przedmiot pracy należy uznać takie pojęcie, co do którego możemy powiedzieć, iż z biznesowego punktu widzenia praca jest wykonywana i rozliczana po to, by zmieniać stan tego pojęcia. W naszym przypadku, oznacza to, iż specjaliści dziedzinowi zgodzili się co do tego, iż praca wykonywana jest wokół poszczególnych rodzajów produktów finansowych (którego przykładem jest Produkt kredytowy) oraz Badań jakościowych. Co więcej, uznano, iż podczas pracy nad produktem powstaje konieczność uruchomienia prac nad badaniami jakościowymi, co zostało jawnie zaznaczone relacją generates. Mając to na uwadze, możemy już stwierdzić, iż procesy biznesowe będą stworzone dla tych dwóch przedmiotów pracy, oraz że wystąpią relacje pomiędzy procesami skupionymi wokół nich, o czym za chwilę.

Próbując nałożyć model pojęć na wcześniej zdekomponowany system tworzenia wartości, moglibyśmy stwierdzić, iż wyróżnione przedmioty pracy w pełni zawierają się w pierwszym z jego etapów – Wytworzeniu. Przypisanie to, zilustrowane poniżej, należy traktować jako koncepcję, która niekoniecznie musi znaleźć odzwierciedlenie w diagramie.

VCS (L2) v2mp

Przypisanie przedmiotów pracy do obszaru systemu tworzenia wartości

 

W kolejnym kroku metodyki Riva, z każdym z przedmiotów pracy należy związać trzy rodzaje procesów, kategoryzowanych jako:

  • case process – proces, którego instancje będą tworzone dla każdej instancji przedmiotu pracy (w naszym przypadku, dla każdego z produktów kredytowych, rozumianych katalogowo) i będą odpowiadały za operowanie na instancji przez cały cykl jej życia.
  • case management process – proces jednoinstancyjny, którego zadaniem jest zarządzanie instancjami typu case process, uruchomionymi dla określonego przedmiotu pracy,
  • strategy process – proces jednoinstancyjny, którego celem jest dokonywanie strategicznych przesądzeń dla danego przedmiotu pracy (na przykład, ustalanie reguł biznesowych związanych z danym przedmiotem pracy).

Prócz utworzenia procesów, metodyka wskazuje na relacje je łączące, bazując jednakże bardziej na charakterze relacji, niźli konkretnym jej kontekście. Przykład przekształcenia  omawianych dwóch przedmiotów pracy oraz relacji generates na architekturę procesów przedstawia poniższy diagram. Zgodnie z regułą, dla każdego z dwóch przedmiotów pracy utworzono po 3 diagramy różnych typów. Bazując na relacji generates prowadzącej od Produktu kredytowego do Badania jakościowego, utworzono dwie relacje:

  • jedną pomiędzy procesem Utrzymanie produktu kredytowego a Zarządzanie badaniami jakościowymi, reprezentującą prośbę o uruchomienie badania jakościowego (a precyzyjniej, utworzenie instancji procesu Przeprowadzenie badania jakościowego), za których koordynacje proces odpowiada.
  • drugą pomiędzy Zarządzaniem produktami kredytowymi a Zarządzaniem badaniami jakościowymi, reprezentującą fakt mediacji pomiędzy procesami zarządczymi w sytuacji, gdy nie można uzyskać kompromisu w poprzednio opisanej komunikacji.

 

APB.png

Architektura procesów biznesowych

 

Opisany sposób transformacji przedmiotów pracy na architekturę procesów zgodnie z przedstawionym wzorcem jest nazywany w metodyce Riva tworzeniem pierwszej wersji architektury procesów (ang. first cut architecture). W kolejnym kroku, należy skonfrontować tak powstały obraz architektoniczny z rzeczywistością organizacyjną, w efekcie czego może dojść do uproszczenia modelu – na przykład poprzez redukcję relacji, przypisanie odpowiedzialności niektórych procesów, w sytuacji, gdy działania w procesach są trywialne, do innych procesów, itp. Oczywiście, na potrzeby niniejszego wpisu, zasady tworzenia powiązań pomiędzy przedmiotami pracy oraz transformacji na pierwszą wersję architektury zostały przedstawione wybiórczo, aby jedynie zaprezentować samą koncepcję. Cała pozostała złożoność metodyki Riva w tym zakresie pozwala na pokazanie większej liczby odcieni szarości, jakie mogą wystąpić podczas tworzenia architektury procesów.

Zidentyfikowane w powyżej przedstawiony sposób procesy oraz relacje występujące pomiędzy nimi, stanowią kolejny etap, jawnie ujęty w metodyce G. Rummlera, dekompozycji systemu tworzenia wartości. W rozważanym przykładzie, udało nam się stworzyć fragment architektury w pełni zawierający się w obszarze Wytworzenia, systemu wartości dla Produktu kredytowego. Docelowo, w ten sposób można byłoby wytworzyć architekturę dla wszystkich trzech obszarów, pokazując w jaki sposób, na poziomie samych deklaracji procesów realizowana jest praca (łącznie z informacjami zwrotnymi) mająca na celu dostarczać Klientom produktu i usługi z danego obszaru biznesowego.

 

VCS (L2) v3ap

Drugi  poziom dekompozycji systemu tworzenia wartości

Metodyka G. Rummlera wprowadza kolejne poziomy dekompozycji, prowadzące, poprzez opisy przebiegów poszczególnych procesów biznesowych, do poziomu opisu odpowiedzialności na poszczególnych rodzajach stanowisk pracy. Z uwagi jednakże na fakt, iż wpis dotyczy jedynie tematu architektury procesów, na tym etapie zakończę już wpis.

Na zakończenie pragnę zwrócić jeszcze uwagę na kilka mniej, lub bardziej jawnie ujętych wcześniej zagadnień, które warto przy tej okazji zgłębić.

Po pierwsze, z przedstawionej koncepcji dochodzenia do architektury procesów biznesowych jawnie wynika, iż jest ona integralną częścią większego systemu, jakim jest opis organizacji. Co więcej, nie jest nadrzędnym elementem, co oznacza, iż tworzenie architektury procesów biznesowych musi być poprzedzone wcześniejszymi pracami, mającymi skutkować utworzeniem kontekstu biznesowego dla niej. W aktualnie obowiązującej terminologii, można byłoby stwierdzić, iż architektura procesów biznesowych jest składową architektury biznesowej, z którą powinna być zgodna.

Po drugie, koncepcje Mapy supersystemowej oraz systemów tworzenia wartości zostały przedstawione jedynie w aspekcie dochodzenia do architektury procesów. Zupełnie pominąłem aspekt zarządzania wykonaniem organizacji (ang. performance management), bez którego w praktyce nie ma sensu tworzyć takiego modelu. Bardzo upraszczając, konstruowany opis organizacji należy uzupełnić o stawiane na różnych poziomach cele, uwzględnić zakres oraz sposoby pomiarów celów oraz przewidzieć mechanizmy, które pozwolą na analizę i podejmowanie działań, mających na celu usunięcie nieakceptowalnych rozbieżności pomiędzy planem a realizacją.

Po trzecie, chciałbym jawnie stwierdzić, iż architektura biznesowa obejmuje zakres jeszcze szerszy, niż to co zostało opisane we wpisie i dodane w pierwszych dwóch punktach uzupełnienia. Patrząc z punktu widzenia samej struktury informacji, pominąłem modele decyzyjne, reguły biznesowe, cały model opisujący plan biznesowy organizacji oraz wiele innych elementów, których stosowanie jest uzależnione od specyfiki organizacji. Warto mieć to na uwadze próbując wdrażać techniki analizy biznesowej, gdyż praktyka pokazuje, że bardzo często realizacja jednych prac rodzi konieczność wdrożenia do analitycznego przybornika nowych technik, które to z kolei… w ten sposób, ewolucyjnie, można wdrażać analizę biznesową i architekturę biznesową. Aby to jednak zadziałało należy mieć metodykę, należy dysponować mechanizmami pozwalającymi na jej rozbudowę, zasobami ludzkimi, które tę trudną pracę wykonają oraz dużo cierpliwości, gdyż nie od razu Kraków zbudowano. Próba pójścia na skróty z pewnością, wcześniej, czy później, zawiedzie.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Analiza biznesowa w korporacji, czyli starcie ogromnej szansy z poważnym zagrożeniem

jjsKorporacje istnieją długo, wcześniej oczywiście jako nie korporacje, a od pewnego czasu już jak najbardziej i w krasie pełnej. Historia rozwoju firmy odciska w każdym jej zakamarku swoje piętno, czy to w formie przestarzałych technologii, nie do końca zrozumiałych podziałów organizacyjnych, wszelkiej maści szarych eminencji, kultury organizacyjnej, czy też, w wielu przypadkach, braku jawnego właściciela firmy, który swoim gospodarskim okiem ogarnia całość i wyznacza kolosowi jednoznaczną (na tyle, na ile można) marszrutę rozwoju. Takie środowisko sprzyja powstawaniu wewnętrznych niespójności, luk organizacyjno-technologicznych, siedlisk partykularnych interesów i lokalnych konfliktów, które często przysłaniają ogólnoorganizacyjne dobro (jeśli o czymś takim można w ogóle mówić w przypadku korporacji).

Praktyki analizy biznesowej (rozumianej bardzo szeroko, na przykład tak, jak definiuje to IIBA), właściwie stosowane, mogą w ogromnym stopniu przyczynić się do identyfikacji miejsc wymagających poprawy, określenia potencjalnych kierunków usprawnień oraz wypracowania rozwiązań. Usprawnienia, w skali korporacyjnej, mogą się przekładać na zauważalne, niemałe korzyści finansowe.

Wdrożenie takich praktyk, na dużą skalę, bynajmniej nie jest zadaniem trywialnym a czas trwania takiej zmiany kulturowej należy liczyć w latach. Moje doświadczenie pokazuje jednakże, iż trud jest opłacalny, a często pierwsze biznesowe efekty pilotażowych wdrożeń można uzyskać w dość niedługim czasie. Procesem zaszczepiania nowych praktyk należy oczywiście właściwie zarządzać, dostosowując tempo oraz zakres wdrożenia do specyfiki organizacji (brzmi troszkę na okrągło, ale bez wnikania w szczegóły trudno jest napisać coś mniej ogólnego).

Bez względu na tempo i zakres, wcześniej czy później napotka się miejsca usprawnień, które paradoksalnie mogą stać się przyczyną porażki. A to znajdziemy bowiem Ukryte Tajemnice jednostki, a to wypadnie nam Znany Powszechnie trup z wydziałowej szafy, którego nikt nie miał odwagi bądź chęci zauważyć, a to znowu, wdrażając metody analizy natkniemy się na departament, który część pracy analitycznej powinien wykonywać, ale z różnych powodów mu nie śpieszno do tego. Można tłumaczyć, podawać obiektywne z punktu widzenia organizacji argumenty, zachęcać, mediować, ale często to ludzie, ich interesy oraz tak zwane okoliczności będą wzięte pod uwagę przy ocenie pracy analityków i osób analizę wdrażających. Nie zawsze będzie to zbieżne z mitycznym ogólnoorganizacyjnym dobrem.

Co więc robić, by nie wpaść w taki impas? Dobre pytanie. Co zrobić, gdy już się wpadnie w taką nieciekawą sytuację? Równie dobre pytanie, co poprzednie. Jedno, co warto mieć na uwadze, to to, że z bardzo dużym prawdopodobieństwem taki impas nastąpi. Nie raz, nie pięć. Jeśli można, przygotujmy się na taką okoliczność.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Edżajl. 2017.

omtTo „hasło”jest w moim przekonaniu jednym z najczęściej aktualnie odmienianych przez przypadki wyrazów w środowisku IT. Jesteśmy edżajl, będziemy edżajl, organizacje edżajl, zespoły edżajl, to jest edżajl, to nie jest edżajl. Drugim, co do popularności „hasłem”, jest już chyba pośmiertnie wyróżniony łoterfol. To jest jak w łoterfol, tak nie robimy, bo to będzie łoterfol, przechodzimy z łoterfol na edżajl. Dobre i złe.

Początek lat 90-tych, studiuję informatykę na Uniwersytecie Wrocławskim, rok czwarty studiów…wpada mi w ręce jakiś artykuł o obiektowości. Jeszcze niewiele o tym wiem, ale czuję, że jest w tym moc. Rok czwarty, kilka miesięcy później. Koledzy z roku jadą do Holandii sprzedawać jakieś druciane cudeńka…proszę ich o przywiezienie mi dwóch książek o obiektowości. Przywożą. Object-oriented Modeling and Design. James Rumbaugh. Object-oriented Analysis and Design. James Martin, James Odell. Czytam od deski, do deski. Kilkukrotnie. Nie mogę uwierzyć – metody strukturalne są takie złożone, a w metodach obiektowych wszystko jest takie proste. I obiecują, że to wystarczy.

Piszę pracę magisterską. Sytuacja komfortowa, gdyż na całym Uniwerku, oprócz mnie i kolegi z roku, nikt się na tym nie zna. Łącznie z opiekunem. Po studiach kolega pisze bazę obiektową w Turbo Pascalu, ja drążę analizę obiektową. Piszemy pierwszy system. Modelujemy na kartkach, potem w ABC FlowCharter. Prosto, łatwo i przyjemnie. We dwóch daliśmy radę. Kurcze, to jednak nie były czcze obietnice z tą obiektowością. Analiza (mój konik) – trzy diagramy! Rok 1993…wpada mi w ręce Object-oriented Software Engineering: A Use Case Driven Approach. Ivar Jacobson. Pojawiają się przypadki użycia. Proste. Dodajemy do zestawu naszych technik. Końcówka lat 90-tych, pojawia się praca Dougha Rosenberga i Robustness Analysis. Fajne. Przerabiamy tę technikę na odpowiednik w UML. Bo powstał UML. Guru obiektowości połączyli siły i powstał standard. Teraz już będzie marsz ku sukcesowi.

Rok 2017. Obiektowość jest dalej obecna. Mamy UML 2.5. Kilkanaście typów diagramów. Do tego SysML, BPMN, ArchiMate i wiele innych języków. Zewsząd słychać, że UML jest zbyt skomplikowany. Ba! Jest bardziej skomplikowany niże metodyki strukturalne (sic!). Za nami także obietnice silwerbuletów: component – based development (CBD), SOA, BPMS. Każda z tych technik znalazła swoje miejsce i w odpowiednich sytuacjach jest stosowana.

Rok 2017. Edżajl. Wszędzie. Edżajl jest dobry, łoterfol jest zły. O łoterfolu mówią trzydziestolatkowie, którzy sami często przyznają, że nigdy nie zrealizowali dużego projektu w takim podejściu. [Hmmm…to ile projektów w podejściu strukturalnym zrealizowałem w 1992 roku?] To nie zmienia jednak faktu, że łoterfol jest zły. Jedynie dobry jest edżajl.

Zespoły mają być interdyscyplinarne, pracujemy razem na ołpenspejsie, dużo rozmawiamy, spotykamy się, warsztatujemy, piszemy historyjki, mamy łajtoardy, flipczarty, kanbamy, diołdi, diołar, dżiry. Mamy czas, przyzwolenie, nie mamy eMeSProdżekta, mamy za to dejli, retro, pibiary. Jesteśmy zmotywowani, samoorganizujący się, mniej lub bardziej dojrzali, mamy edżajl kołczów, a nawet łordy i eksele.

Mamy też złożone systemy. Projekty, które wymagają modyfikacji wielu systemów jednocześnie. Systemy rozwijane w różnych technologiach, w różnych departamentach, w różnych lokalizacjach, przez dostawców zewnętrznych jak i siły wewnętrzne. Mamy SLA, goniące terminy. Nie jesteśmy w stanie zmontować jednego interdyscyplinarnego zespołu, bo byłby za duży. I ludzie nie przyjadą na 100% z tylu lokalizacji. To zmontujmy wiele. Może analityczny i deweloperski? Ale to byłby łoterfol!! Nie, trzeba jakoś inaczej. Ważne, by deweloper, ramię w ramię, siedział z biznesem, analitykiem testerem…wówczas będzie dobrze.

Produkujemy jeszcze więcej historyjek, tasków, kontyngentów, akceptujemy nawroty (bo to edżajl), świętujemy oddania na sprincie, nie przejmujemy się kolejną przeróbką (bo to edżajl). Terminy gonią, zatrudniamy dodatkowe osoby, mamy więcej statusów międzyzespołowych, rozmawiamy, motywujemy się. Akceptujemy pomyłki.

I jest dobrze? Bo nie w łoterfolu? Bo nie w UMLu? Bo po nowemu?

Nie?

To może jednak jakiś enterprajs skram? SEJF, czy jakoś tak? Bo jednak nie da się ze wszystkim tak radośnie? No ale co…enterprajs skram, to enterprajs juzerstory? Hmmm…to może jednak coś zapisać nie w historyjce? To może jednak analiza biznesowa? Może jakaś analiza systemowa?

No dobrze, byleby prosto. Bez zbędnego ciężaru. Na tablicy. Edżajl modeling. Ma ktoś zdjęcie tablicy sprzed tygodnia? Nie? A ktoś pamięta?

To może czasami jakiś friłerUML? Darmowy. Zawsze to lepiej niż na tablicy. Każdy tyle, ile uważa za słuszne. Zespół zdecyduje ile. Każdy decyduje, jak chce. Oferta u Ciebie, to Offer mnie. Ale Twój Customer znaczy co innego, niż u mnie. To trzeba uspójnić. Zgłosimy to na dejli albo na retro.

Łotefol jakiego już nikt nie pamięta versus radosna twórczość. Mam wrażenie, że taki ostro spolaryzowany świat występuje w dyskusjach o Agile. Pośrodku są jednakowoż metody iteracyjne i przyrostowe, metody adaptacyjne (znane od lat), którymi przesiąkły rozsądne podejścia waterfall (które z tym mitycznym waterfall mają niewiele wspólnego).

To kiedy zaczniemy czerpać z doświadczeń?

Rok 2018…zobaczymy…

                     

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.