niedziela, 4 grudnia 2016

Analiza, czyli projekt, czyli decyzja

Przemierzając bezkresy internetów zwracam szczególną uwagę na wszystko co jest związane w mą profesją, czyli analizą biznesowo-systemową i architekturą (nie wiedzieć czemu  po polsku zwaną "korporacyjną", gdyż angielskie "enterprise" oznacza przedsiębiorstwo, ale również przedsięwzięcie,  bez względu na rozmiar i formę prawną).
Ze zdziwieniem stwierdzam, że pomimo licznych  "body-of-knowledge", które starają się na różne sposoby zdefiniować pojęcie analizy, architektury, zmiany, ryzyka, projektu, systemu itd, itp,  nadal trwa burzliwa dyskusja wśród moich kolegów po fachu, co właściwie robi analityk. Analizuje czy syntetyzuje? Kompletna pojęciowa "galareta". Wobec tego i ja dorzucę 3 grosze.

Stawiam następującą tezę:

Analitycy biznesowo-systemowi zajmują się głównie projektowaniem.


Kto ma inny pogląd – ręka do góry ! Wszyscy?
Ok. Już wyjaśniam.

Cóż to jest właściwie „analiza”. Jako rzecze polska Wikipedia, analiza to  „rozkład na czynniki, wyodrębnienie cech, właściwości, składników badanego przedmiotu lub zjawiska”.
Czy to jest to, czym zajmuje się analityk biznesowo-systemowy? Chyba nie. Może, jednak, miał rację Alvin  Toffler twierdząc, że:
„Współczesna nauka tak dobrze radzi sobie z rozkładaniem problemów na części, że często później zapomina złożyć je w całość.”
Nie jest aż tak źle. Są tacy co pamiętają o składaniu - to właśnie my, analitycy, jakby to paradoksalnie nie brzmiało.

Chciałem przytoczyć również definicję projektowania, ale nie ma w polskiej Wiki definicji projektowania jako pojęcia ogólnego (sic!). Posłużmy się zatem słownikiem PWN . "Projektować" to "układać plany, zamyślać coś". Czyż nie tym właśnie zajmujemy się, Drogie Koleżanki i Koledzy Analitycy - de facto kreowaniem "planów" dla interesariuszy, PM-ów, projektantów i programistów. Czymże jest zbiór wymagań lub feature backlog jak nie planem, przynajmniej w zakresie przedmiotowym? Jako analitycy jesteśmy zatem projektantami! Ciągle coś "zamyślamy".

Pytanie pomocnicze: co jest celem analizy biznesowo-systemowej ?
Odpowiedź (w skrócie):
  1. Zdefiniować problem;
  2. Zdefiniować  rozwiązanie problemu;
  3. Zdefiniować metodę implementacji i wdrożenia rozwiązania.
Czy powyższy proces to analiza? Nie. To projektowanie  sposobu realizacji zmiany,  a projektowanie czegokolwiek  to podejmowanie decyzji "jak ma być". Gołym okiem widać, że analiza biznesowo-systemowa to nie analiza, lecz projektowanie,  c.b.d.u.

Kto ma inny pogląd – ręka do góry ! Widzę jeszcze nieprzekonanych.
Ok. Już tłumaczę.

Pytanie pomocnicze: Jeśli analiza biznesowo-systemowa to projektowanie sposobu rozwiązania problemu, to co to jest „problem”?
I to jest właśnie problem. Odpowiedź nie jest prosta.

Umówmy się, że „problem” to jedno z następujących pytań:

1/ Co jest rozważanym obiektem/sytuacją, a co jego  otoczeniem/kontekstem, czym jest rozważany obiekt/sytuacja  (synteza wyobrażenia obiektu / sytuacji);

2/ Z czego składa się obiekt/sytuacja, jak jego elementy składowe są powiązane (rozpoznanie struktury obiektu / sytuacji);

3/ Jak obiekt/sytuacja się zmienia,  jak oddziałuje z otoczeniem, jak oddziałują na siebie elementy obiektu/sytuacji (rozpoznanie zachowania obiektu / dynamiki sytuacji).



Są to tzw. „problemy poznawcze”, które muszą być rozstrzygane jednocześnie i wzajemnie spójnie, konstytuując łącznie tzw. proces poznawczy.
Rezultatem rozstrzygnięcia problemów poznawczych jest subiektywne wyobrażenie o przedmiocie poznania.
Ciekawe jest to, że identyfikacja obiektu / sytuacji  może ewoluować po kolejnych iteracjach rozpoznania struktury i/lub zachowania. Należy przy tym zauważyć, że wyobrażenie pozbawione jednego z aspektów procesu poznawczego jest bezużyteczne, chyba że godzimy się na pozostawanie w stanie niepewności co do przedmiotu naszego poznania. Spotkałem się też z powiedzonkiem, że jeśli coś wygląda jak "coś tam", zachowuje się jak "coś tam", to na pewno jest tym "czymś tam". Czy na pewno?

Po poskładaniu wszystkiego "do kupy", czyli po dokonaniu SYNTEZY - czyli czegoś odwrotnego do analizy -  mamy obraz stanu bieżącego naszego obiektu rozważań. Jeśli ten stan wzbudza brak naszej akceptacji i motywuje nas do  zmiany, to musimy odpowiedzieć na kolejne pytania:

4/ Na co chcemy zmienić bieżący stan , który nas nie zadowala (wybór celu transformacji / opis stanu pożądanego);

5/ Co chcemy/powinniśmy/możemy  zmienić, aby osiągnąć stan pożądany (wybór przedmiotu/zakresu transformacji oraz określenie zasobów, czasu, warunków początkowych, ograniczeń, itd.);

6/ Jak przeprowadzić zmianę (wybór/optymalizacja  metody, zasobów, czasu, warunków początkowych, ograniczeń, itd.).




To są  tzw. „problemy decyzyjne”, które również powinny być rozstrzygane jednocześnie i wzajemnie spójnie, łącznie tworząc proces decyzyjny.
Rezultatem rozstrzygnięcia 3 problemów decyzyjnych jest decyzja - lub inaczej dyrektywa - która powstaje w wyniku wielokrotnych prób (iteracji) korelacji metody i przedmiotu  z celem transformacji. Uwaga! W trakcie procesu decyzyjnego wybór celu zmiany (transformacji) może ulec zmianie. Często bowiem


jak się nie może mieć co się lubi, to się lubi co może się mieć.


Tylko czy to, co może się mieć rozwiązuje problem, który nas trapi?

Decyzja podjęta w inny sposób, bez korelacji lub pozbawiona jednego z 3. aspektów,  nie powinna być kierowana przez decydenta do realizacji, chyba że decydent i wykonawca decyzji godzą się na działanie w warunkach niepewności co do optymalności decyzji, lub na przyznanie wykonawcy prawa dokonania arbitralnego wyboru brakującego aspektu na etapie realizacji decyzji. W takiej sytuacji dochodzi do rozmycia odpowiedzialności za wynik realizacji decyzji. Czy odpowiada decydent, który wydał wadliwą decyzję, czy wykonawca, który taką decyzje przyjął do realizacji?

Wykonawcy często popełniają błąd, przyjmując do realizacji decyzje niespójne lub niekompletne, zaciągając tym samym zobowiązania często niemożliwe do spełnienia.  Mądry wykonawca powinien sprawdzić, czy decyzja jest formalnie prawidłowa  i wykonalna. Ale młody-wyrywny, jak przysłowiowy "polski pilot co to na drzwiach od stodoły poleci", często daje wpuścić się w przysłowiowe maliny. 
Bywa, że decyzja o transformacji jest  negatywna z powodu niemożności skorelowania celu, przedmiotu i metody zmiany. I to jest odpowiedzialna postawa decydenta/analityka. 

Więcej TYPÓW  problemów w "przyrodzie" nie ma. Jest ich 6,  i tylko 6. Starczy.
Problemów konkretnych,  jak i technik ich stawiania oraz  rozwiązywania oczywiście jest  bez liku, ale na pewno należą do jednego z powyższych typów, lub dadzą się rozłożyć na problemy prostsze, które można klasyfikować  w ww. sposób.
Zaprezentowane podejście jest tyleż proste, co oczywiste i zawsze działa.
Kto ma inny pogląd – ręka do góry ! Widzę jeszcze kilku opornych.
OK. Już tłumaczę.

Do otaczającej nas rzeczywistości można podchodzić na jeden z dwóch możliwych sposobów:

  • pasywnie, czyli obserwować, poznawać -  czyli rozwiązywać 3 problemy poznawcze (pytania 1-3);

albo 

  •  aktywnie, czyli starać się ją zmieniać - czyli rozwiązywać 3 problemy decyzyjne (pytania 4-6).
Innych opcji brak.

W praktyce nasze działanie zawsze polega na robieniu jednego i drugiego na przemian. Najpierw rozpoznajemy/obserwujemy sytuację, potem decydujemy co robić i znów rozpoznajemy, jakie są skutki naszych decyzji, by potem wypracować decyzje korygujące, by potem ..... itd.





Uwaga: nie zawsze jesteśmy wykonawcami własnych decyzji, ale to nie zmienia istoty zjawiska. ZAWSZE rozwiązywanie problemów poznawczych (analiza) przeplata się z rozwiązywaniem problemów decyzyjnych (synteza). Nie inaczej jest w analizie biznesowo-systemowej, a raczej w "analizo-syntezie biznesowo-systemowej".

Jeśli zgodzimy się, że powyższy wywód ma sens, to stawia on praktykę analityczną w zupełnie innym kontekście: jako element szeroko rozumianego zarządzania zmianą, a może nawet zarządzania decyzjami. Uwaga! Miny! Wchodzimy w obszar kompetencyjny tradycyjnie zarezerwowany dla "biznesu"!
Jeśli powyższe nie budzi protestu, to należy zastanowić się, czy analityk jest "decydentem", czy tylko "specjalistą" opracowującym materiały do decyzji. Jeśli decydentem,  to jak kształtować zakres jego odpowiedzialności? Jeśli tylko specjalistą, to problem komunikacji i dokumentacji procesu podejmowania decyzji  na linii biznes - analityk - wykonawca  staje się kluczowym. Rodzi się pytanie o sposób i technikę komunikacji oraz standardy dokumentacji: czy UML? BPMN? DMN? ArchiMate?  A może zestaw Word, Exel, PowerPoint? A może wystarczy white-board? A może wszystko naraz? Jak już dotknęliśmy standardów dokumentacji , to jak się ma do tego obecnie obowiązujące podejście agile, które nie przepada za dokumentacją i komplikuje kwestię przebiegu procesu decyzyjnego? Lepiej nie otwierajmy tej puszki Pandory.

Jak widać "czysta" analiza, rozumiana dosłownie,  jako rozkładanie na części i badanie elementów składowych, to tylko maleńka cząstka całego procesu. Znacznie częściej zachodzi akt syntezy, czyli PROJEKTOWANIA. W tyn sensie analiza-biznesowa jest działalnością stricte twórczą.

Jeśli ktoś ma inny pogląd - trudno, nic na to nie poradzę.


Niezależnie od tego, czy analityk to "decydent", czy nie,  zawsze warto mieć na uwadze, że:

„Chodzi o to, że poszukiwanie decyzji optymalnej będzie bezwartościowe, jeżeli postawienie problemu nie zostało zoptymalizowane. Jest zrozumiałe, że straty spowodowane błędami tego rodzaju będą tym większe, im większy system podlega optymalizacji.” (M.Mazur)


Wasz, 

 M.





Diagramy zamieszczone w niniejszym tekście zostały wykonane przy użyciu notacji ArchiMate®.

ArchiMate® jest znakiem zastrzeżonym The Open Group.



2 komentarze:

  1. Witam.
    Jak nazywa się "notacja graficzna" której Pan używa na diagramach ?
    Jeżeli od razu rzuciłby Pan więcej informacji (linków) to będę wdzięczny.
    Pozdrawiam, Tomasz M.

    OdpowiedzUsuń
    Odpowiedzi
    1. Panie Tomaszu.
      Proszę przyjąć moje szczere przeprosiny. Dopiero teraz goszcząca nas platforma blogowa raczyła mnie poinformować o Pana pytaniu. A może ja coś przeoczyłem?
      Notacja, której używam to ArchiMate®, język modelowania architektury i jej zmian , rozwijany przez The Open Group (https://pl.wikipedia.org/wiki/ArchiMate ).
      Używam jej od 2007 roku i coraz bardziej mi się podoba. Niedawno wyszła 3. wersja standardu, ale należy spodziewać się na dniach erraty, gdyż TOG (chyba z powodu pośpiechu) w kilku miejscach walnął istotne byki. Poza tym gorąco poleca. Jako analityk powoli zapominam o UML-u.
      Pozdrawiam,
      Marek

      Usuń