Książka inspiruje, skłania do rewidowania swojego podejścia i korygowania popełnianych błędów. Pan Żeliński przygotował wyjątkowy zbiór felietonów. Bazuje on na treściach z bloga o analizie IT-Consulting z najdłuższą historią w Polsce.

Tytuł „Analiza biznesowa. Praktyczne modelowanie organizacji” świetnie zgrywa się z hasłem wpisanym na odwrocie książki: „Zrozum, zanim zaproponujesz rozwiązanie”. To właśnie, w moim odczuciu, główne przesłanie książki (jak i analizy biznesowej) – abyśmy jako analitycy biznesowi, managerowie czy prezesi, nie rozwiązywali problemów bez zrozumienia jak organizacja działa, jakich dokładnie zmian potrzebuje i jaki one wywrą wpływ na inne części firmy. Organizacja to w końcu system naczyń połączonych. Wprowadzane zmiany oddziałują na inne jednostki, procesy i systemy. Często te, które nie przyszły nam do głowy.

Książka porusza dwa problemy: weryfikowanie, czy rozwiązujemy właściwy problem organizacji oraz wskazówki jak ten problem rozwiązać w sposób właściwy, prawidłowo stosując analityczne narzędzia.

Autor wychodzi od sytuacji bardzo często spotykanych na rynku, na których notorycznie wykłada się biznes i analitycy. Czy zakup dobrze zareklamowanego rozwiązania rzeczywiście pomoże firmie? Czy będzie pasowało do jej funkcjonowania? Czy rozwiązuje właściwy problem? Błędy na tym polu powodują, że wprowadzane systemy IT wręcz firmom szkodzą.

Autor przedstawia proste kroki pomagające zrozumieć działanie organizacji a następnie przejście do zaproponowania właściwego rozwiązania. Dalej omawia najczęściej wykorzystywane techniki analizy (przypadki użycia, modele procesów, diagramy komponentów, sekwencji, modele faktów, pojęć, itd.) tłumacząc na przykładach ich właściwe i praktyczne zastosowanie.

Wielokrotnie krytykowane jest podejście do analizy polegające na spisywaniu wywiadów, tworzeniu setek stron dokumentów, w których znajdziemy opisy konkretnych zaobserwowanych przypadków (choć pewnie nie wszystkich możliwych), brakuje tam natomiast zrozumienia ogólnych zasad działania. Jeśli zrozumiemy zasady funkcjonowania, możemy przewidzieć dowolną sytuację i zaplanować reakcję na nią. Przy podejściu zapisywania poszczególnych przypadków jesteśmy zdani na to, czy nasze setki stron spotkaną sytuację opisują czy pomijają. Jeśli pomijają, to wtedy nie mamy odpowiedzi na pytanie „i co teraz?”.

Problem w tym, czy analitykowi uda się to zrozumienie osiągnąć, odkryć wzór, mechanizm rządzący organizacją. Wiem, że to niekiedy bardzo trudne. Z wielu powodów. Za mało znamy działanie firm w ogólności, daną firmę, ograniczenia. Nie potrafimy jednoznacznie opisywać wniosków z analizy, docierać do źródeł, syntezować informacji, uogólniać zależności. Niektórzy wręcz zakładają, że takie pełne zrozumienie jest nieosiągalne i nie próbują. Nastawiają się bardziej na podejście eksperymentalne, przyrostowe, z częstą informację zwrotną od ekspertów dziedzinowych czy użytkowników.

Podobnie niełatwe było odkrycie przez Kopernika, że tory ruchu planet, dotychczas obserwowane z Ziemi i rozumiane jako dziwnie pokręcone, nie dające się dobrze opisać żadnym równaniem, w rzeczywistości są banalnie proste – to okręgi wokół Słońca. Takie zrozumienie tak wiele upraszcza. Umiejętność zrozumienia i tworzenia prostych zasad to powód, dla którego warto czytać pana Żelińskiego. Co prawda droga do tego jest często wyzwaniem intelektualnym i sprawdzianem odpowiedniego zaopatrzenia w narzędzia.

W książce spotkamy też krytykę opierania analizy jedynie na licznych wywiadach. Widzę podobne zagrożenie. Jesteśmy ludźmi, a co za tym idzie, mylimy się, przekręcamy fakty, zapominamy i bazujemy na przypuszczeniach. Jeśli omawiamy kwestię, której źródło leży gdzie indziej – w przepisach, w bazie danych, w funkcjonowaniu systemu, warto sprawdzać informacje u źródła, by zminimalizować ryzyko pomyłki. Kontakt z przyszłymi użytkownikami jest niezastąpiony i szalenie cenny. Warto jednak wiedzieć, jak, kiedy i do czego wykorzystywać go optymalnie. W dużych organizacjach działalność może być bardzo rozległa, a osoby prezentujące jednostki, choć są ekspertami w swoich tematach i choć nawet bardzo angażują się w projekt z najlepszymi intencjami, niekoniecznie muszą wiedzieć o wszystkich wpływach wywieranych na inne części organizacji, w szczególności, jeśli nie są one dla nich ewidentne. Analityk ma za zadanie składać obraz całości, rzeczywistości, działania organizacji ze skrawków dostarczanych z różnych perspektyw („To drzewo”. „Nie, to wąż”. „Nie, to słoń”) i brać odpowiedzialność za ocenę skutków wprowadzania zmian.

Pan Żeliński pokazuje swoją bogatą wiedzę i znajomość przeróżnych technik, notacji i podejść. Z tekstu płynie też niespotykane zrozumienie ich przeznaczenia i właściwego zastosowania. Ponadto widać także znakomitą umiejętność porządkowania pojęć. Docenią to w szczególności ci, którzy doświadczali już jak brak jasności w myśleniu przekładał się na zagmatwanie w projektach.

Prezentowane w książce podejście doskonale sprawdza się w projektach informatyzowania działalności organizacji. Projekty takie angażują ogromne zasoby i pewnie większość specjalistów i budżetów.

Spotykamy także inne typy projektów wymagających eksperymentów i dużej dozy kreatywności. Nie bazują one na stanie obecnym organizacji. Może to być innowacyjny produkt lub atrakcyjny, sprzedający produkty lub usługi interfejs czy serwis informacyjny z banalną logiką (zapis i odczyt prostych informacji z bardzo prostym przetwarzaniem). Nie znalazłam w książce odniesienia do takich sytuacji. Sądzę, że w takich projektach krytykowany proces prototypowania znajduje jednak zastosowanie. Jednakże tu również można czerpać z uniwersalnych metod analizy prezentowanych w książce na przykładach.

Czytając artykuły Pana Żelińskiego czytelnik napotyka co chwilę nazwy stosowanych podejść czy notacji. Skłania to do poszukiwania, odkształcania się i poszerzania horyzontów. Gdyby nie to, myślę, że metody te nie rozprzestrzeniałyby się tak szybko i szeroko w Polsce.

Jeśli jesteś osobą początkującą i masz nadzieję, że znajdziesz tu wyjaśnienie analizy od A do Z, to niestety nie ten adres. Jak napisał autor – książka to zbiór felietonów i tak właśnie należy ją traktować. Książka jest raczej dla praktyków, którzy mogą się już odwołać do swoich doświadczeń z projektów i do wiedzy na temat UML i różnych technik. Początkujący również mogą dowiedzieć się z niej ciekawych rzeczy, zyskać wartościową perspektywę, jednak nie zastąpi to czytania wielu innych pozycji na temat podstaw oraz specyfikacji języków modelowania.

Ta książka to przede wszystkim inspiracja, nawołanie do przemyślenia tego co i jak robimy w analizie oraz źródło do stworzenia listy lektur obowiązkowych takich jak specyfikacje metod i języków modelowania. Jednak czytanie samej teorii nie gwarantuje jej właściwego zrozumienia i zastosowania. Książka Pana Żelińskiego wypełnia tę lukę – pokazuje praktyczne zastosowanie, częste wypaczenia i przypomina nieustannie o prawdziwym celu pracy analityka.

Cześć! 7 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Analizuję, prowadzę bloga, piszę artykuły, kursy, prezentuję, uczę na uczelniach i robię szkolenia. Przygotowuję także procesy analizy w firmach. Badając rynek szukam odpowiedzi na pytania: jak zostać dobrym analitykiem? Co to oznacza dla różnych odbiorców - kolegów z zespołu, managerów i klientów? Jak analitycy powinni się rozwijać? Po godzinach uczę się czegoś nowego i biegam do morza i z powrotem. Jestem ciekawa Twoich doświadczeń, wyzwań i problemów. Zostaw komentarz o sobie :)

5 KOMENTARZE

  1. Po takiej recenzji, nie miałem wyjścia. Musiałem sprawdzić sam co i jak :-). Poświęciłem więc 30 pln i cały wieczór na przeczytanie tej książki.

    Zacznę od tego, co mi się podobało. Na pewno wartościowy jest przegląd najważniejszych modeli i pokazanie kiedy i z którego modelu warto skorzystać, a także jak one uzupełniają się między sobą (BTW, mam nadzieje, że jest to fundament, którego uczą już na studiach, a nie dopiero w pracy). Cenne jest podkreślenie, że niejednoznaczność analizy oznacza bardzo duże problemy i jest chyba najcięższym grzechem w tym zawodzie. Każdy, kto wchodzi w rolę analityka, musi umieć z kakofonii mniemań, poglądów i opinii wyciągać fakty, a z nich – definiować ogólne zasady działania organizacji. Modele zaś, co podkreśla autor, mają mu w tym pomóc. Kluczem do sukcesu jest metodyczne i zdyscyplinowane podejście do dziedziny, którą się zajmujemy. Inaczej osoba w roli analityka ryzykuje bycie „dyktafonem”, co nie ma nic wspólnego z faktyczną analizą i kończy się najczęściej rozczarowaniem interesariuszy.

    I to by niestety było tyle pozytywów. Z rzeczy, do których można się przyczepić, choć pewnie nie są jeszcze dyskwalifikujące, to:
    1. brak powoływania się na źródła (np. raport Forrrestera bez wskazania nawet roku, w którym badania zostały przeprowadzone ani ich dokładnej nazwy, str. 102);
    2. brak odwołania się do uznanej literatury czy dobrych praktyk. Nie mogę pojąć jak autor, który cały rozdział poświęca przypadkom użycia (str. 71) nie znalazł odrobiny miejsca, aby przynajmniej wspomnieć, że warto sięgnąć do A. Cockburna, aby przedstawić różne szablony opisywania przypadków (nie tylko własny!), wyjaśnić czytelnikom znaczenie takich elementów jak cel przypadku, zdarzenie inicjujące, warunki wstępne, lub aby wyjaśnić z jakimi innymi artefaktami pracy analitycznej można je łączyć (np. prototypy). Nawet jeśli autor hołduje podejściu zakładającemu redukowanie opisu do minimum, warto przynajmniej wspomnieć, że są też inne szkoły i pokazać ich źródła, albo chociażby, że są różne dobre praktyki (np. używanie nazw w trybie rozkazującym, „złota 7” przy dekompozycji. itp.), z których czytelnik może chcieć skorzystać. Znalazło się za to miejsce, by wspomnieć o cloud computing (sic!);
    3. wybiórcze posługiwanie się cytatami (np. bardzo kłuje w oczy powoływanie się w książce, która w tak krytyczny sposób odnosi się do metodyk zwinnych, na Deana Leffingwella, który jest gorącym orędownikiem agile’a i historyjek, twórcą jednego z bardziej popularnych framework’ów do skalowania zwinnego wytwarzania, autorem książki „Agile Software Requirements”);
    4. myślenie życzeniowe (np. „diagram przypadków użycia ma fundamentalne znaczenie bo zostanie przeczytany i jest zrozumiały”, str. 31), fundamentalizm pozbawiony naukowej weryfikacji („niezależnie od doświadczenia programiści nie powinni realizować części analitycznej projektów, bo dziedzina ich klienta nie jest ich dziedziną”, str. 58), nierealne oczekiwania (np. rozpoczynanie analizy od opisania całego przedsiębiorstwa, aby dopiero potem przejść do wdrożenia systemu, str. 14) albo zwyczajne mijanie się z prawdą (jak opis na czym polega programowanie zwinne ze str. 119 i sugerowanie w nim, że w zwinnym podejściu cały zespół będzie potrzebował kilku iteracji by dojść do tego, co analitykowi zajmie 1 dzień – wciąż nie rozumiem, za co autor tak strasznie nienawidzi programistów i dlaczego uważa ich za tępe bezmózgi, których jedyną dziedziną jest machanie łopatą, a jak się wezmą za analizę – to na pewno zepsują);
    5. brak trzymania się tych samych konwencji nazewniczych (np. autor czasem opisuje relacje pomiędzy klasami czasownikami, a czasem – nie wiedząc czemu – używa rzeczowników, str. 49);
    6. literówki (choć to pewnie bardziej świadczy o redaktorze książki, niż o autorze);
    7. uwiarygadnianie się m.in. członkostwem w IIBA, a jednocześnie tworzenie własnej definicji analizy biznesowej, która, delikatnie mówiąc, kładzie akcent na coś zupełnie innego (JŻ: „Analiza biznesowa prowadzona jest w celu stworzenia modelu (…) funkcjonowania i zrozumienia zasad działania.” vs. IIBA: „practice of enabling change (…) by defining needs and recommending solutions that deliver value to stakeholders.”); w pierwszym przypadku celem jest wyspecyfikowanie wymagań i budowa modeli, w drugim – jest to jedynie narzędzie do prawdziwego celu, jakim jest rozwiązanie dające wartość interesariuszom. Nie mam nic przeciwko tworzeniu własnych definicji, ale wydaje mi się, że warto przynajmniej wspomnieć tę najbardziej uznaną i wyjaśnić czemu się z nią nie zgadzamy;
    8. nic niewnoszący bełkot („Całość będzie zgodna z fazami CIM/PIM. Projekt dziedziny (…) będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycję (zamiast dziedziczenia) i DDD.” str. 103)

    To wszystko co powyżej, to są jednak wciąż detale. A teraz, wg mnie, grzechy kardynalne.

    Niewłaściwy tytuł. Książka powinna być zatytułowana: „Analiza wymagań na systemy IT w podejściu obiektowym”, bo tylko taki wąski wycinek analizy biznesowej rozważa. Do tego podejście OOAD traktuje bezkrytycznie, nie wskazując też ani słowem, że można inaczej. Utrwala szkodliwy stereotyp, że miejsce każdego analityka jest w projekcie, pomiędzy biznesem a programistą (bo przecież to są ludzie z 2 różnych światów i potrzebują proxy, aby się dogadali). Nie ma ani słowa o analizie organizacji, strategicznej, architekturze korporacyjnej, czyli o ogromnych połaciach poza-projektowych, gdzie analiza biznesowa również występuje. Ani nawet jak umiejscowić analizę, jeśli oprogramowanie jest wytwarzane zwinnie. Jest tylko o tym, że zwinność jest zła ;-)

    Mało praktycznych porad. W podręcznikach o BPMN, UML, przypadkach użycia, historyjkach znajdziemy o wiele więcej szczegółów jak korzystać z tych technik. To czego ja oczekiwałem po książce, która praktyczność ma w tytule, to wskazanie rozmaitych tips&tricks, które stosowane w modelach czy opisach zwiększają ich przejrzystość, np. wspomniane już konwencje nazewnicze (na poziomie klas, atrybutów, przypadków użycia), sztuczki przy graficznym przedstawianiu modelu (włącznie z pokazaniem jak ważne jest stosowanie kolorów, pogrubień, wyrównań do osi/marginesu), zestawienie dobrych/złych praktyk (tak rób vs. tak nie rób), pokazanie wzorców dla różnych powtarzalnych zachowań procesu (np. pętle, zdarzenia asynchroniczne, obsługa wyjątków, itp.) – czyli właśnie rzeczy, których analityk nie znajdzie w ogólnych podręcznikach, a których najbardziej brakuje jak się zaczyna pracę w tym zawodzie i ma się do wyspecyfikowania rzeczywisty problem w rzeczywistym projekcie.

    Od książki, która chce być praktyczna, oczekiwałbym zdecydowanie większego rozwinięcia opisu różnych odcieni zawodu analityka, wskazania czym się różni praca analityka po stronie dostawcy od tej wewnątrz zamawiającego albo od tej w firmie consultingowej, na co zwracać uwagę gdy jest się bardziej analitykiem od danych, a co jeśli bardziej zajmujemy się procesami. Na co zwracać uwagę gdy się buduje rozwiązania od zera, a na co – gdy się wdraża systemy z pudełka. O czym pamiętać gdy się wdraża hurtownie, a o czym gdy systemy core, workflow albo rozwiązania portalowe/mobilne. Oczekiwałbym opowiedzenia czego oczekują architekci, deweloperzy, testerzy, a czego interesariusze biznesowi, jak z nimi rozmawiać, na co zwracać uwagę, jakich słów nie używać, co jest ważny gdy specyfikuje się interfejs plikowy, a co gdy WS, itp. To jest dopiero praktyczna strona tego zawodu.

    Intelektualizm i racjonalizm. Autor reprezentuje ewidentnie podejście do analizy jako do procesu w pełni racjonalnego, pozwalającego poprzez spekulację zaprojektować kompletne, całościowe i optymalne rozwiązanie. Gdzie potem wystarczy usiąść i zakodować jednym strzałem. Tyle tylko, że ponad 30-letnie doświadczenie w budowaniu złożonych systemów IT mówi nam co innego. Badania Standish Group pokazują, że zaledwie 3% dużych projektów realizowanych w ten sposób kończy się sukcesem (w przypadku podejścia zwinnego – 18%).

    Autor przywołuje metaforę budowy domu, która jest chybiona. Bo każdy, kto budował dom wie doskonale, że po wprowadzeniu się do niego i rozpoczęciu korzystania, wychodzi cała lista rzeczy, które zrobiłoby się inaczej, a o których się nie myśli dopóki się w tym domu nie mieszka. I sztuką jest złapać równowagę między tym, co jest niezbędne by zacząć prace (np. konstrukcja nośna, technologia budowy, przyłącza, itp.), a tym, co może być ustalone później. Glazurnik, parkieciarz czy gipsiarz, który potrafi zamawiającemu doradzić i wprowadzić zmiany na etapie wykończenia, zamiast bezmyślnie kierować się tylko tym, co architekt narysował w projekcie, to dopiero prawdziwy skarb. Nie znam zamawiającego, który by się z tym nie zgodził. Zaś najlepsze efekty zawsze powstają z rozmowy architektów i budowlańców, zwłaszcza gdy pojawia się problem. Nie z pochylania się nad nawet najlepszym projektem i zastanawiania się, co autor miał na myśli. Tylko z tego, że ludzie siądą i zaczną ze sobą rozmawiać.

    Zupełnie nie rozumiem, jak ktoś z takim doświadczeniem analitycznym może widzieć tak czarno-biały świat. Przecież cała nasza praktyka zawodowa uczy nas poruszania się w sferze niuansów, odcieni szarości, eklektyzmu łączącego zarówno metody analityczne, jak i kreatywne. Uczy nas pracy z ludźmi, którzy są po prostu zagubieni. Którym ich przełożeni stawiają coraz bardziej ambitne cele, a oni nie wiedzą czego potrzebują, by je osiągnąć. I nie potrafią, spekulując nad czystą kartką, dojść do tej wiedzy w sposób czysto racjonalny, wnioskując logicznie na podstawie zebranych informacji. Większość ludzi nie ma predyspozycji analitycznych, przyjmują opinie za fakty, nie potrafią (lub nie mają czasu) oddzielić bełkotu od istotnych informacji. Bo też nie od tego są. Są od zarabiania pieniędzy. Założenie, że pomimo tego będą w stanie zanurzyć się w model analityczny i zatwierdzić go raz a dobrze jest wg mnie błędem tej metody. I szkodzi naszemu zawodowi. Trendy bowiem pchają nas w zupełnie inną stronę, ale o tym w tej książce nie ma ani słowa.

    Anachronizm. W pełni podpisuję się pod recenzją, która pojawiła się na stronie Heliona. Książka przeciętna, chaotyczna, istnieje wiele innych, znacznie lepszych pozycji. A do tego spóźniona o jakieś 20 lat. Wybaczyłbym gdyby była pisana w XX wieku. Ale że A.D. 2016 ktoś całkowicie ignoruje takie trendy jak agile (tendencyjność rozdziału poświęconego user stories zasługuje na zupełnie osobną recenzję), UX, architektura korporacyjna jest dla mnie nie do pomyślenia. Nie ma tam nawet najmniejszej próby pokazania/wytłumaczenia jak analiza biznesowa może wyglądać we współczesnym świecie, ani jakie są kluczowe kompetencje i umiejętności, by zmiany, które się obecnie toczą, nie okazały się dla analityków zabójcze.

    Czytając tę książkę, stanął mi przed oczami jeden z moich wykładowców, uczący socjologii polityki na początku XXI wieku z pożółkłych, 25-letnich skryptów, i odwołujący się w nich do osiągnięć marksizmu-leninizmu. Można? Można. Tylko po co?

    Jeśli ktoś wiąże swoją przyszłość z tym zawodem i ma wystarczająco dużo ambicji, by grać w ekstraklasie (czytaj: zarabiać tak, jak zarabiają analitycy górnego kwartyla, a nie ciągnąć się w ogonie przeciętniaków), zdecydowanie odradzam lekturę, bo ryzykuje później bolesne zderzenie z rzeczywistością. Lepiej kupić dobry podręcznik, aby się nauczyć wybranej techniki, a potem, szukając inspiracji dla swojej roli; sięgnąć do źródeł, do takich autorów jak R. Pichler, S. Blais, D. Leffingwell, czy J. Appelo. I zobaczyć w którą stronę to wszystko zmierza.

    • @Michał Mroczek

      Dzięki za podzielenie się opinią. Korci mnie jedno tylko pytanie.
      Odnosząc się do tego, że napisałeś „Zupełnie nie rozumiem, jak ktoś z takim doświadczeniem analitycznym może widzieć tak czarno-biały świat” – jaki wniosek z tego należy wyciągnąć?

      • Najpiękniejsze w wolnym świecie jest to, że każdy może wyciągać takie wnioski, jakie chce. Dzięki różnym wnioskom jest o czym rozmawiać. Ja dla siebie na pewno kilka wyciągnąłem, np. że mam dużo za dużo wolnego czasu, skoro popełniłem tak długi tekst :-) Albo, że jestem już stary, bo sam pamiętam jak 10 lat temu bezkrytycznie przyjmowałem wszystko, co pojawiało się na blogu it-consulting. Albo, że pewnie mam spaczone podejście, bo jestem tylko i wyłącznie praktykiem, który nie raz w projektach szedł na kompromisy, na które iść nie powinien. Ale też, że jestem ogromnym szczęściarzem, że nigdy nie utknąłem w żadnym dogmacie… i mam nadzieję, że nigdy nie utknę :-) W. E. Deming miał rację pisząc: „It is not necessary to change. Survival is not mandatory.”

  2. Apropos uwag od developerów (i architektów) to jestem za. Warto chociaż zapytać co sądzą o proponowanym rozwiązaniu. W najgorszym razie się z tej uwagi nie skorzysta. W najlepszym – poprawisz dzięki temu coś, co wnosiło ryzyko albo zwiększało koszty. Różne są sytuacje. Zależy też co i gdzie analizujemy. Czasem programiści mają merytoryczną przewagę, np.
    – kiedy wprowadzasz zmiany do systemu, który oni budowali od lat i znają go bardzo dobrze, a Ty nie
    – kiedy są w danej branży znacznie dłużej niż Ty
    – mogą szybko sprawdzić ograniczenia rozwiązania
    – kiedy spędzają w danym module 100% swojego czasu a Ty 5% z doskoku
    – mają świetne z relacje z otoczeniem, znają wiele osób, szybko docierają do ważnych informacji, a analityk z jakiegoś powodu nie

    W kwestiach ogarniania strategii, znajomości rynku, planów zarządczych, analizy procesów, znajomości przepisów, polityk, użytkowników, wolałabym, żeby analityk coś wiedział czy sprawdził zamiast polegać na tym, że developerowi się wydaje inaczej. Niektóre propozycje zmian wynikają z nie brania pod uwagę ważnych czynników biznesowych. Po prostu z perspektywy developera niektórych rzeczy nie widać albo nie wydają się istotne. Zdarzą się programiści, którzy się tym interesują i na coś zwrócą uwagę – ile ludzi, tyle przypadków. Więc w zasadzie to warto posłuchać i zweryfikować jak jest naprawdę.

    Jeszcze ciekawa jest kwestia czy musimy przeanalizować całą firmę w czasie analizy? Wydaje się przesadnie pracochłonne. Jednak niektóre rzeczy wystarczy zrobić raz i korzystać przez wiele lat. Np. jak często można spisywać plany strategiczne firmy? Jak często tworzy się i zmienia mapę procesów? Jak często zmieniają się procesy na wysokim poziomie ogólności? Jak często wywracamy do góry nogami raz opisaną architekturę korporacyjną? To są zasoby przydatne do każdej inicjatywy prowadzonej w organizacji, nie tylko pod konkretny projekt czy zadanie.

    Czy trzeba to wszystko robić w analizie „dodajcie tu pole X”? Niby nie. Czasem od razu widzisz, że to banał. Albo zapisz, odczytaj formularz. Przelicz coś wg standardowego wzoru. Czasem nie trzeba nic pisać, nad niczym myśleć, bo wszyscy wiedzą jak to zrobić.

    Czasem jednak pojawiają się inny scenariusze.
    Np. w połowie pracy nad dużym modułem ktoś się orientuje, że on wprost przeciwstawia się celowi projektu. Po roku pracy wstrzymują kilkadziesiąt osób.
    Np. mamy zautomatyzować działanie całego pionu, ale że nikt dokładnie nie zna ich procesów, więc zaczyna się kreatywne uszczęśliwianie nietrafionymi ficzerami
    Np. do zmiany było jedno pole. Ktoś w podskokach przygotował krótką i przyjemną analizę. Potem zaczynają się błędy z produkcji i sypie z bardziej i mniej oczekiwanych miejsc. Kto by się spodziewał, że to pole wpłynie na niedostępność sprzedawanych klientom produktów? Zależności są ogromne. Słysząc prawdziwy impact biznes nakrywa się nogami. Przecież ostatnio zrobiliśmy to w 1 dzień! Ale pominęliśmy analizę skutków. To jest częsty przypadek zbytniego optymizmu i skracania sobie pracy. Pominięcia, nieprzewidziane sytuacje i błędy z produkcji.
    Np. wdróżmy sobie system. Nie wiadomo w jakim celu, nie wiadomo jak teraz działamy, ale będzie fajnie.
    Np. mamy nowe przepisy regulacyjne. Tylko gdzie je wdrożyć? Do którego z tych 100 systemów? Nie wiadomo. Czy uwzględniliśmy wszystko i przejdziemy audyt.

    True story.

    Albo ciekawe dylematy:
    – Naprawcie problem wydajnościowy.
    – Ale czy faktycznie mamy problem wydajnościowy? [?] Czy wymaganie jest zdefiniowane poprawnie? [TAK] Czy wymaganie jest osiągalne? [NIE] Zatem trzeba zmienić wymaganie na osiągalne. Ale jakie jest osiągalne? Trzeba przetestować wartości graniczne funkcji systemu. Trzeba poznać też rzeczywistą ilość wprowadzanych danych. Trzeba sprawdzić w bazie produkcyjnej stan dotychczasowy. Trzeba dowiedzieć się od biznesu jakie są plany na przyszłość – będzie tych danych więcej czy mniej? Okazuje się, że biznes używa systemu niezgodnie z przeznaczeniem. Co wynika z działania innych systemów realizujących podobną funkcję. Jeśli analizowany system przejmie rolę wiodącą, wtedy danych będzie X, jeśli strategią jest zostawienie obu, to wtedy Y. W zależności od odpowiedzi podejdziemy do tego inaczej. Jest jeszcze jedna opcja poprawy wydajności – zmiana sposobu współdziałania z innymi komponentami aplikacji. Wpłynie to jednak na 4 inne aplikacje i działanie 3 pionów firmy. Czy warto robić optymalizację? Czy zmienić sposób wprowadzania danych, a co za tym idzie proces biznesowy? Czy wprowadzić zmiany we współpracy głównych pionów firmy?
    – Bez zastanowienia nad tym, rzucilibyśmy się do pracy nad optymalizacją funkcji pod źle zdefiniowane wymagania wydajnościowe.

    Także, warto wiedzieć, co się dzieje wyżej. Nie za każdym razem trzeba tę wiedzę budować od zera.

    • Jestem jak najbardziej za tym, aby przy okazji analizy porządkować informacje i odkładać wiedzę w taki sposób, aby była ona potem re-używalna. Tylko znowu, skoro książka miała być praktyczna, to brakuje w niej komentarzy kiedy i jak warto to robić. Chociażby banalny przykład struktury repozytorium analitycznego byłby pomocny dla młodych analityków, rekomendacje jak porządkować dokumenty projektowe i artefakty analityczne, podpowiedzi które informacje bardziej się przydają po zakończeniu projektu i warto je porządkować od razu z myślą o re-używalności, a które nie, kiedy warto robić pełną dokumentację up-front, a kiedy można ją zrobić po developmencie – to są prawdziwie praktyczne wskazówki. Bo oczywiście, jak się jest analitykiem-firmą to można klientowi powiedzieć: „pracuję tak i tak, a jak się wam nie podoba – to wynocha”, ale większość analityków nie ma takiego komfortu. Większość z nich musi się dostosować do otoczenia. A co za tym idzie, potrzebują odrobiny sprytu, cwaniactwa, dyplomacji i doświadczenia, by przekonać innych, że warto robić tak, jak oni proponują.
      Są projekty, zwłaszcza na wczesnym etapie rozwoju, gdzie można sobie pozwolić na zadawanie pytań o strategię, cele, podważać zakres projektu, szukać i porównywać różne rozwiązania. I udowadniać, że jest potrzebny albo że nie jest potrzebny CRM. Ale są też i takie projekty, w których jest już absolutnie za późno na takie ćwiczenia (z różnych powodów, nie tylko merytorycznych), albo projekt przypomina chodzenie po polu minowym. I dobry analityk musi być w stanie rozpoznać w jakiej sytuacji się znajduje, rozumieć np. że zupełnie inna jest awersja sponsorów do ryzyka w projektach R&D, a zupełnie inna w projektach regulacyjnych gdzie np. ryzykują własną odpowiedzialność karną, że zupełnie inaczej wygląda realizacja projektu narzuconego przez właściciela, a zupełnie inaczej, gdy firma ma pełną autonomię, że zupełnie inaczej wygląda realizacja projektu małego, realizowanego pół-amatorsko albo zajmującego się realizacją „quick-win’ów” w perspektywie kilku tygodni-miesięcy, a zupełnie inaczej realizacja wieloletniego, strategicznego projektu transformacji przedsiębiorstwa.

      Ocenę otoczenia i sytuacji robi się po to, aby: a) dobierać właściwie środki i metody – a przez to być bardziej skutecznym, b) nie roztrzaskać się na najbliższej ścianie (np. z napisem „Zarząd”) szarżując 100 km/h, bo właśnie się odkryło, że ten projekt, co to go zarząd z pompą odpalił się nie spina, więc przecież to oczywiste, że cała firma będzie nas nosić na rękach za to odkrycie :-)
      I to jest właśnie dla mnie „praktyczne modelowanie organizacji”.

ZOSTAW ODPOWIEDŹ