Wprowadzenie

Pod pojęciem audytu organizacji, kryje się przede wszystkim audyt dokumentacji jaką ona sama o sobie stworzyła. Powinna ona być “spójna, kompletna i niesprzeczna”. Druga część, to ocena zgodności stanu faktycznego z treścią tej dokumentacji, czyli sprawdzenie czy dokumenty mówią prawdę. Popatrzmy jednak na samą dokumentację organizacji i jej treść.

Każdy mój projekt zaczyna się od audytu dokumentacji. Jednak zanim zacznę analizować dokumenty operacyjne i modelować procesy biznesowe, sprawdzam spójność wizji i misji firmy. Dlaczego? Bo procesy te wraz z opisem strategii pozwalają zweryfikować cel projektu, a nie raz w ogóle go sformułować. Najgorszym celem biznesowym jaki można sobie wyobrazić, jest wdrożenie czegokolwiek dla samego wdrożenia. Wdrożenie rozwiązania z zasady jest środkiem do osiągnięcia celu organizacji a nie celem samym w sobie (to może być cel kierownika projektu odpowiedzialnego za samo wdrożenie).

Model Motywacji Biznesowej

Misja i wizja są (powinny być) z sobą powiązane logicznie, stanowią one podstawę dla ustalenia strategii i taktyki działania firmy.  Wyznaczają przysłowiowe “światełko w tunelu”. Narzędziem dla analityka zawsze powinien być formalizm, czyli możliwość sprowadzenia pozyskanej wiedzy do skończonej liczby pojęć i związków między nimi. Podobnie jak autor zestawów LEGO musi sprowadzić dowolny kształt do skończonej liczby i typów klocków. Jak wiemy, dowolne urządzenie składa się ze skończonej liczby podzespołów, dobre konstrukcje składają się z podzespołów standaryzowanych. Jeżeli uda się to analitykowi, to wtedy dopiero może on powiedzieć, że “zrozumiał mechanizm tego co opisał”.

Narzędziem do analizy obszaru opisu organizacji, jakim jest strategia i zarządzanie jej realizacją, jest system pojęciowy (notacja) znany jako Model Motywacji Biznesowej (¹). Jego szkielet to planowany stan docelowy i środki do jego osiągnięcia.  Do tego dodajemy ocenę aktualnej sytuacji oraz zidentyfikowane czynniki wpływu. Model ten konfrontujemy z modelem działania organizacji (procesy biznesowe i to co się z nimi wiąże). Swego czasu opisałem to:

Notacja BMM uzupełnia biznesowy system notacyjny o obszar pojęciowy (przestrzeń pojęciową) modeli biznesowych i biznesplanów. Pozwala opisać je w sposób formalny. Przestrzeń nazw, podstawowe pojęcia opisane w BMM: Ends (stan oczekiwany, przyszły) identyfikują cechy opisujące źródła motywacji (cele) tworzenia biznesplanu, Means (środki) identyfikują narzędzia i środki jakich planujemy użyć by osiągnąć (doprowadzić do) oczekiwany (planowany) stan. Assessement (ocena uwarunkowań) identyfikują wiedzę o warunkach projektu (w szczególności analiza SWOT), Influence (wpływ) identyfikują poznane czynniki mogące mieć (mające) wpływ na osiągniecie celu, Organisation (organizacja) identyfikuje zasoby i procesy zaangażowane w osiągnięcie celu. Całość stanowi rodzaj ?listy kontrolnej? zrozumienia postawionego problemu, jakim jest projekt biznesowy. Pozwala upewnić się, że znamy i rozumiemy to co ma na niego wpływ. (²) 

Misja i Wizja

Skupmy się na misji i wizji, gdyż te budzą najwięcej dyskusji i nieporozumień. Najpierw pojęcia i ich definicje (słownik języka polskiego PWN):

wizja ?czyjeś wyobrażenie jakichś zdarzeń mających zajść w przyszłości, zwykle przedstawiane w książce lub w filmie?

misja ?posłannictwo, ważne odpowiedzialne zadanie do spełnienia?

Literatura przedmiotu zawiera niekończące się spory na temat wizji, dotyczą one określenia tego o jaką i czyją przyszłość chodzi.  Idąc tropem tych, którzy uważają, że wizja to opis stanu organizacji, dochodzimy to pewnej kolizji (sprzeczności) z pozostałymi elementami opisu organizacji. [akapit dodany dwa dni po publikacji] Jest pewna zgoda co do tego, że misja opisuje dlaczego organizacja istnieje i jaki jest cel jej działań. Jeżeli oferuje ona coś rynkowi (klientom) to znaczy, że istnieje dla nich a nie dla siebie. Skoro zaś organizacja istnieje dla klientów znaczy, że jako organizacja ma jakieś wyobrażenie o tych klientach i o tym czym oni są, w konsekwencji to wyobrażenie: wizja, to opis tego kim mogli by być klienci  w przyszłości dzięki tej organizacji. To daje spójność misji i wizji. Czym więc jest wizja firmy mówiąca “będziemy liderem na giełdzie”? Jest oświadczeniem przeciwnym, jest formą egoizmu: wydajecie u nas pieniądze i My, a nie Wy, mamy z tego korzyść. Skąd się biorą w prospektach emisyjnych wizje mówiące “My…. będziemy…”? Prospekty emisyjne, ich treść,  są adresowane do akcjonariuszy a nie do klientów tych firm. Jednak poprawna misja i wizja firmy to metoda budowania wizerunku na rynku, więc adresatem misji i wizji nie są (nie powinni być) właściciele organizacji…

Na bazie modelu pojęciowego notacji BMM (pojęcia i ich znaczenia) można stworzyć taki oto, podstawowy model opisu organizacji, zachowujący spójność, kompletności i niesprzeczność:

Kluczowe elementy opisu “stanu przyszłego” (docelowego) to: wizja, zadania i rezultaty. Jeżeli więc zadaniem byłoby zdobycie pozycji lidera na rynku a miernikiem realizacji tego zadania była co najmniej trzecia pozycja w rankingu, to znaczy że wizja nie może być ani zadaniem ani tym bardziej rezultatem (logika modeli pojęciowych, w tym słowników pojęć, wymaga by definicje pojęć w tej samej dziedzinie wzajemnie się wykluczały).

Ważne! Oprogramowanie (system IT jako całość) to zasób i tylko zasób. Warto pamiętać, że z zasobów korzystają ludzie w ramach realizowanych czynności (procesów biznesowych).  Bez pełnego zrozumienia co i po co robią ludzie ocena systemu IT czy też specyfikowanie wymagań wobec niego są praktycznie pozbawione sensu.

Czym więc jest wizja firmy?

W arsenale analityka, wśród “narzędzi” diagnozujących i opisujących organizację, jest bardzo popularna i łatwa w użyciu “analiza SWOT” z ang. Silne i Słabe strony, Okazje i Zagrożenia (Strengths, Weaknesses, Opportunities, Threats).  Silne i słabe strony to cechy organizacji a okazje i zagrożenia to cechy jej otoczenia. Stan docelowy jest stanem oczekiwanym, obserwowalnym z zewnątrz, rynku oraz organizacji, którą opisują jej zadania i ich mierniki. Jakimi środkami organizacja osiąga cele? Są to strategia i taktyki, które razem realizują Misję firmy. Siłą sprawczą są tu ludzie, Ci zaś realizują swoje zadania w ramach realizowanych procesów.

Powyższy diagram pokazuje dwa istotne obszary opisu organizacji: prawy to to, do czego ona dąży i jakimi środkami. Lewa strona to ocena sytuacji. Gdybyśmy więc opisywali hipoteczną piekarnię osiedlową, możliwa byłaby sytuacja, w której:

• Wizją piekarni byłoby to, że ich osiedle skupia wyłącznie mieszkańców odżywiających się zdrowo,
  • celem było by bycie piekarnią pierwszego wyboru dla wszystkich mieszańców osiedla,
  • miernikiem była by ankieta, która potwierdzi, że każdy badany mieszkaniec osiedla dokonuje zakupu pieczywa w innej piekarni dopiero, gdy nie ma możliwości zakupu w piekarni badanej,
• Misją piekarni było by krzewienie zdrowego odżywiania się poprzez oferowanie wyłącznie zdrowych i ekologicznych gatunków pieczywa w akceptowanych dla większości mieszkańców cenach,
  • strategią było by otwarcie sklepu na każdy tysiąc mieszkańców
  • taktyka na pierwszy rok, były by promocje dodawania zdrowych bułek (po jednej) do każdego zakupionego kilograma chleba.

Analizy SWOT w detalach nie będę tu opisywał, jest to dość proste i zrozumiałe narzędzie, o którym napisano wiele. Warto tu jedynie podkreślić i przypomnieć, że zawiera ona ocenę otoczenia organizacji i jej samej.

Podsumowanie

Powyższy diagram pokazuje opisane pojęcia oraz, co tu najważniejsze, ich wzajemne związki. Całość dla zachowania spójności, kompletności i niesprzeczności powinna pozwalać na takie zobrazowanie, a związki między tymi pojęciami (typy tych związków) nie mogą prowadzić do jakichkolwiek sprzeczności czy braku logiki w toku ich czytania (zgodnie z kierunkiem i opisem strzałek).

W toku analizy systemowej organizacji zbierane są więc informacje i podejmowana jest próba odtworzenia (zbudowania) na ich podstawie analogicznego jak powyżej modelu. Wszelkie wykryte luki i niespójności są natychmiast sygnałem do tego by je wyjaśnić i – jeżeli taki jest cel analizy – uzupełnić. Zapisy, jakoby wizją firmy było np. osiągnięcie określonego pułapu obrotów, nie da się obronić na gruncie logiki…

Tym razem natchnieniem do napisania tego tekstu była krótka dyskusja w internecie i to stwierdzenie jednego z jej uczestników:

“…strategia budowana przez Zarząd”. Gdyby chciał Pan na tym bazować to w przypadku 90% małych i średnich firm w Polsce bazowałby Pan na niczym. Nawet jeśli któraś z tych firm ma strategię (lub wydaje się jej, że ma) brzmi ona mniej więcej tak: “W najwyższym możliwym stopniu zaspokoić potrzeby klientów przy minimalnych możliwych kosztach własnych”. Obaj wiemy, że to nie jest żadna strategia. Trzeba szukać innego fundamentu.

…nie zgodzę się. Firma i jej właściciel, która istnieje na rynku kilka lat ma strategię tyle, że bardzo intuicyjną i nie uświadomioną. Tu analiza polega na zrozumieniu tego, dlaczego dana firma, mimo przeciwności losu, nie upadła i istnieje np. 10 lat …. Co do zaś “W najwyższym możliwym stopniu zaspokoić potrzeby klientów przy minimalnych możliwych kosztach własnych” to proszę poczytać prospekty emisyjne spółek giełdowych, jest dokładnie to samo …  … a ten tekst nie jest strategią a raczej manifestem maksymalizacji zysków , który uprawia większość korporacji, dlatego w toku analizy warto po prostu pochylić się nad firmą i zrozumieć jakim cudem udało się jej nie zbankrutować . 

Jak to mawiał mój dawny profesor filozofii: “gdy dwóch mówi to samo to już nie jest samo”.  To co nazywamy “zwinnym podejściem” to coraz częściej uznanie nieskuteczności metody polegającej na “zbieraniu wymagań” i obrona przed “obiecaniem z góry tego co ma powstać”, bo nikt nie wie czym to coś będzie jak już powstanie…(o ile powstanie). Takie głosy pojawiają się coraz częściej, i to nie od wczoraj….

Dzisiaj metody oparte na abstrakcji

Takie “pomysły” jak MDA (architektura bazująca na modelowaniu), MDE (inżynieria bazująca na modelowaniu), notacje BPMN, UML, SysML, SoaML i podobne, stanowiące sobą formę rysunku technicznego na wysokim poziomie abstrakcji, to ścieżka nie raz ratująca projekty informatyczne. To metoda pozwalająca radzić sobie z rosnącą złożonością inżynierii jako całości. Te narzędzia powstają i są rozwijane od ponad 20 lat… Konstrukcji dzisiejszego tramwaju czy złożonego oprogramowania, nie da sie już rzetelnie  i precyzyjnie opisać z pomocą “listy wymagań zebranych w trakcie spotkań warsztatowych” na rozsądnej ilości stron papieru. Ich podział na “funkcjonalne i poza funkcjonalne” nie wprowadza niczego nowego do takiej listy. Ta technika specyfikowania (IEEExxx-1998^?1?) ma swoje początki ponad 30 lat temu!

W czym problem?

Niedawno ukazał się kolejny ciekawy artykuł na ten temat.

Requirements gathering is one phrase I have learned not to use with stakeholders as I deliver projects. It appears to have struck fear, cynicism and/or anxiety in many of the user groups I have to engage at the most important stage of the solution ? the beginning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution²) 

Popularne słowo “elicitation” to “uzyskiwanie, wydobywanie”. Branża IT poszła w kierunku uznania, że zainteresowany (stakeholder) ma rozumieć “wymagania”. To jednak nie działa.

Elicitation And Other Animals The industry then moved on with the terminology, to use the term ?elicitation.? To add complexity, there were separate definitions of functional requirements, being different to business requirements, then getting technical and coming up with system requirements. All of the types of requirements have clouded the understanding by stakeholders, and then time is lost in the defining the terminology before any discussions have begun. A plethora of white papers and authored article can describe the differences and it?s absolutely clear in some of those esoteric minds.. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution²).

Nie wolno zapominać, że zamawiający nie jest  inżynierem. To co potrafi powiedzieć zamawiający i to co jest w stanie zrozumieć to wyłącznie “wymagania biznesowe” i nic ponad to. Poprzestanie w projekcie na takich “wymaganiach” nie stanowi żadnych wymagań wobec inżynierskiej konstrukcji jaką ma wykonać developer (czyli inżynier). Nie należy także zapominać o tym, że każdy biznesowy “udziałowiec” ma “swój interes” do realizacji, wymagania biznesowe to nic innego jak cele tych ludzi. I teraz kluczowe pytanie: kogo pytać o wymagania np. dla oprogramowania wspomagającego sprzedaż: prezesa tej firmy czy jego sprzedawców walczących o prowizje mających nadzieję, że ktoś złoży im propozycję lepiej płatnej pracy? Sponsorem projektów są zarządy firm, oczekują terminów, nazw, opisów a nie nadziei…

Today?s project needs are for solutions measured in time-to-market, risk reduction, take-up rates, or better still, what you defined as measurable at the beginning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution²) 

Powiązany artykuł zawiera inne ciekawe pytanie:

Czego oczekuje biznes: efektu czy produktu?

What Is The Difference Between Outcome And Output? Before I go much further, I should probably explain what I mean when I use the words outcome and output in a context relevant to business analysts:
– Outcome is the change in the organization and changes in the behavior of stakeholders as a result of a project.
– Output is anything that your team delivers as part of your project. This could include requirements, documentation, processes, software, tests and other things that tend to be measured in order to gauge how the project is going.
(Źródło: Business Analyst | Your Job Is Not to Elicit and Document Requirements³) 

i tu pojawia się teza dla analityków:

Requirements Are (Not The Final) Output (wymagania nie są ostatecznym produktem analityka)

To co nim jest? Popatrzmy na proces tak zwanej analizy systemowej:

Gdzie jest faza “zbierania wymagań” w rozumieniu “elicitation”? W zasadzie jest to dopiero początek drogi czyli sformułowanie problemu. Następnie ktoś powinien zbadać środowisko problemowe czyli przeprowadzić badanie (analiza biznesowa organizacji) i opracować model (mapy procesów biznesowych, struktury informacyjne). Kolejny krok to interpretacja wyników badania. Co jest tą rekomendacją? Jest nią rekomendowane rozwiązanie problemu, tym rozwiązaniem może być oprogramowanie, zmiany organizacyjne a najczęściej jedno i drugie.

Jednak nie jest rozwiązaniem stwierdzenie: “powinniście sobie kupić jakieś oprogramowanie i poprawić organizację”. Rozwiązaniem (rekomendacją) jest raczej: “to jest struktura i logika działania oprogramowania, które rekomenduję a to są rekomendowane zmiany organizacyjne”. 

I to dopiero jest najwcześniejszy moment na “wpuszczenie” developera.

Nikogo w biznesie nie interesuje tak na prawdę suchy spis problemów (wymagania zebrane na warsztatach wśród pracowników), biznes jest zainteresowany czymś co można nazwać, kupić i wdrożyć w określonym czasie bo tylko to pozwala na oszacowanie korzyści z takiej inwestycji.

Rynek zmienia się szybko, więc nie ma sensu szczegółowe projektowanie czegokolwiek z uwagi na czas jaki zajmie takie projektowanie i ryzyko, że taki projekt stanie się szybko nieaktualny. Nikt rozsądny nie namawia dzisiaj do czegoś o wdzięcznej nazwie “waterfall”.  Co więc zrobić? Dla dużych projektów tworzymy architekturę, opisujemy mechanizmy działania, politykę rozbudowy i opis cyklu życia.  Czyli to co pozwoli rozwijać rozwiązanie metodą iteracyjno-przyrostową, w razie potrzeby pozwoli na przeprojektowanie, ale jako całość nadal będzie spójne, nie będzie wymagało wymiany całości gdy zmienią się warunki na rynku.

Można w tym miejscu zaryzykować tezę, że nie ma czegoś takiego jak “inżynieria wymagań” bo czym ona jest i co jest jej produktem? Uporządkowany spis życzeń? Mamy natomiast na pewno “inżynierię systemów“…. systemami są organizacje a także narzędzia jakich używają np. oprogramowanie…

Firma jako system

Każda organizacja to zbiorowy byt składający sie z komunikujących się ludzi. Jako ludzie, od wielu lata, wykorzystujemy komputery, które od początku swojego istnienia automatyzują wiele czynności, ale od niedawna służą przede wszystkim do komunikacji. Obliczenia stanowiły 100% zastosowań pierwszych komputerów, obecnie stanowią one tylko małą część tego do czego ich używamy, co całkowicie zmienia podejście do projektowania oprogramowania, które stało się integralną częścią organizacji.

(more…)