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…

Równo 10 lat temu napisałem:

Model firmy powinien w sposób jasny i zrozumiały dla pracowników firmy opisywać firmę, jej cel rynkowy oraz wszelkie jej wewnętrzne i zewnętrzne zachowania oraz reakcje. Poza tym, jest niezbędny do przewidywania zachowań firmy w tym także do przygotowania jej do wdrożenia systemów informacyjnych. Wiele firm doradczych i informatycznych pod pojęciem mapy i modelu procesów biznesowych dostarcza nieprzydatne, utrwalone na dziesiątkach diagramów opisy czynności realizowanych przez ankietowanych pracowników, które nie wiele mają wspólnego z planowanymi zmianami na lepsze.Większość modeli firm jakie widziałem to obrazki nie mające wiele wspólnego z procesami. Zdarza mi się otrzymywać zlecenia, których głównym celem jest ocena cudzej dokumentacji przedwdrożeniowej. Bardzo często jest to sieczka w postaci udokumentowanych życzeń i wyobrażeń ankietowanych pracowników firmy… (Źródło: Modelowanie biznesowe czyli pilnowanie hochsztaplerów)

I niestety nie wiele w tym względzie się zmieniło od tamtego czasu. Zmieniło się jednak to, że funkcyjna idea modelowania organizacji w postaci modelu procesów  biznesowych ma już ugruntowaną pozycję, i mamy postęp w postaci powstania, i ugruntowania sobie pozycji jako standardu de’ facto, notacji [cm_tooltip_parse]BPMN[/cm_tooltip_parse].

Wtedy powoływałem się na notacje IDEF0, w której fundamentem jest funkcyjny blok konstrukcyjny:

Powyższy diagram to wykonany w notacji [[IDEF0]] model procesu jako funkcji, jej wejścia, wyjścia, sterowania i mechanizmu działania. Systemowe (naukowe, czyli pozwalające na testowanie modelu i jego falsyfikacje) modelowanie organizacji nadal bazuje na pojęciach z tej (IDEF0) notacji i modelu procesu ICOM (ang. Input, Output, Controll, Mechanizm):

Idea ta bazuje na uznaniu, że każdy proces biznesowy to wnoszące wartość dodaną funkcja przekształcająca wejście w wyjście procesu, przekształcenie to, sposób jego realizacji, jest ograniczone a działania, ich mechanizm, mogą być definiowalne jako deterministyczne. Notacja IDEF0 była długo stosowana jednak miała podstawową wadę: znacznie strzałek (semantyka notacji) było uzależnione od ich położenia, co utrudniało weryfikację modeli, utrudniało ich tworzenie i narażało te modele na niejednoznaczność przy ich czytaniu (pamiętamy, że model to także treść czyli komunikacja).

Notacja BPMN nie ma tej wady ale też nie zawiera takich pojęć jak Controll i Mechanizm. BPMN to przede wszystkim przepływ pracy oraz dane wejściowe i wyjściowe (diagram powyżej). Jednak notacja ta pozwala na rozszerzanie semantyki o nowe symbole. Bardzo złą praktyką jest nanoszenie na modele procesów (diagramy BPMN dla tych procesów) detali związanych ze sposobem działania czyli logiką biznesową i mechanizmem podejmowania decyzji. Modele takie stają się bardzo szczegółowe a utrzymanie ich aktualności (stanowią dokumentację procesów) praktycznie nie jest możliwe (każda zmiana sposobu działania wymaga korekty tych diagramów). Tworzenie takich, zbyt szczegółowych, modeli określane jest w literaturze określane wręcz jako “utrata panowania nad szczegółowością projektu”.

Od lat stosowane są, jako uzupełnienie modelowania organizacji, macierze [[RACI]], pozwalają one, jako uzupełnienie np. modeli BPMN,  osobno udokumentować złożone zależności pomiędzy rolami w procesie (więcej o RACI…..). Takie elementy pojęciowe ICOM jak Controll i Mechanizm można (zaleca się) modelować jako system reguł biznesowych i tabel decyzyjnych.

Model procesu wykonany w notacji BPMN, uzupełniony o sterowanie i mechanizm podejmowania decyzji, wygląda tak:

Zadanie 1 zostało tu skojarzone z Reguła biznesową (Controll) i Tablicą decyzyjną (mechanizm). Reguły biznesowe to sformalizowane zapisy określające “panujące prawo” w organizacji (np. zarządzenia i regulaminy). Tablice decyzyjne to sformalizowane macierze opisujące deterministyczne decyzje (konkretna odpowiedź systemu w odpowiedzi na konkretny zestaw bodźców). Wejście i wyjście to nic innego jak odpowiednio oznaczone Dane (Obiekt danych w BPMN). Szczegóły wykonania Zadania to albo wiedza i umiejętności wykonawcy albo procedura (np. ISO). W dokumentacji  projektowej powołujemy się na (załączamy) wymagany zakres kompetencji wykonawcy (rola na diagramie procesu) lub załączamy stosowną procedurę (dokument, nie nanosimy na diagram BPMN). Takie niepodzielne już zadanie, wraz z jego wejściem, wyjściem i ewentualnymi regułami to elementarny proces biznesowy.

Tak więc zasady naukowego modelowania (a wcześniej analizy) nie zmieniają się:

1. zdefiniowanie i określenie problemu,
2. analiza i opracowanie hipotezy (modelu, tu badanej organizacji czyli jej modelu procesowego: tak organizacja realizuje swoje cele),
3. testowanie (próba falsyfikacji modelu) w postaci sprawdzania czy są w organizacji dane przetwarzane inaczej niż na modelu,
4. opracowanie wyników, lub korekta modelu w przypadku jego udanej falsyfikacji (wtedy powtarzamy pkt 2. i 3.)
5. opracowanie rekomendacji czyli odpowiedź na pytanie zadane w pkt. 1.

Notacja BPMN do duży krok do przodu, bo narzędzie to ma precyzyjną (poddającą się walidacji), semantykę i syntaktykę, a możliwość nadania modelom kontekstu poprzez dodatkowe użycie macierzy RACI, reguł biznesowych i tablic decyzyjnych, pozwala tworzyć bardzo precyzyjne modele biznesowe możliwe do zarządzania (nie obarczone nadmiarem szczegółów). Wydzielenie poziomu szczegółowości związanego z podejmowaniem decyzji,  poza diagramy (jako załączone elementy), pozwala po pierwsze utrzymać rozsądny  poziom szczegółowości samych diagramów, ich czytelność i zarządzalność, np. zmiana mechanizmu podejmowania decyzji nie wymaga aktualizacji diagramów, bo przepływ pracy nie zmienia się. Poniżej wielokrotnie tu przytaczany model warstwowy;

Środkowa warstwa to wskaźniki (np KPI), architektura procesów, strategie itp. Najniższa warstwa to wszelkie szczegóły takie jak instrukcje stanowiskowe, procedury, zakresy obowiązków, opisy wymaganych umiejętności, instrukcje dla użytkowników urządzeń i oprogramowania, wszelkie inne szczegóły opisujące sposób pracy (nie raz mechanizm jej wykonywania). Środkowa warstwa  to właśnie abstrakcja, jaką jest model procesów biznesowych, jest on opisem przepływu pracy. Na tym poziomie opracowujemy model, który w literaturze z zakresu strategii i zarządzania jest nazywany wewnętrznym łańcuchem wartości w organizacji. Na tym poziomie nie dokumentujemy żadnych szczegółów (powołujemy się na nie, załączamy je), na tym poziomie pokazujemy wyłącznie CO i PO CO się dzieje a nie JAK.  Opis tego jak JAK to się dzieje to właśnie owe Controll i Mechanizm.

Owszem wymaga to użycia dodatkowych elementów na diagramach BPMN, wymaga także także odpowiedniego narzędzia CASE, które na to pozwala, ale warto bo dokumentacja taka staje się łatwa w korzystaniu z niej, mamy zapewniony odpowiedni poziom abstrakcji samych modeli procesów, mamy także osobno udokumentowane szczegóły logiki biznesowej, co bardzo ułatwia (w zasadzie przekazujemy jej bez modyfikacji) postawienie wymagań przed oprogramowaniem, które miało by je implementować (reguły biznesowe i tablice decyzyjne stają się w takim wypadku wymaganiem).

Wprowadzenie

Tym razem coś pozornie całkiem innego niż zwykle: żadnych klas ani procesów :). Bardzo rzadko o tym (tytuł) pisze, ale nie mało moich projektów, także tych związanych z wdrażaniem IT, zawiera w swoim zakresie “rekomendacje związane z poprawą funkcjonowania przedsiębiorstwa”. Nie możemy się tu zatrzymać na poziomie “automatyzacji przepływu pracy i efektywności interfejsu użytkownika “bo to tylko narzędzia, a narzędzia nie czynią sukcesu (no, bardzo rzadko).

Poprawa funkcjonowania firmy

Trzeba mieć świadomość, że poprawa funkcjonowania organizacji to nie tylko szybszy nowy komputer i nowe funkcjonalności oprogramowania. Warto pamiętać, że nie wykazano żadnej korelacji pomiędzy tym, które miejsce w rankingach liderów rynku zajmuje firma a tym ile wydaje ona na IT.  

Niedawno pisałem czego potrzebują dostawy aplikacji biznesowych. Dostawcy oprogramowania, które ma wspierać zarządzanie firmą…

… Potrzebują bardzo zwięzłej i spójnej dokumentacji (ale raczej 50-ciu stron niż setek, że nie wspomnę o kilku tysiącach, tak ? widywałem takie), i po stronie klienta (jednej) osoby, która ten dokument zna, rozumie, ma dostęp do kluczowych osób w organizacji. Najchętniej do autora tego dokumentu? (Źródło: Kim jest product owner? | Jarosław Żeliński IT-Consulting)

Problem w tym, że nie jest sztuką napisać (opisać) to co firma robi, sztuką jest wiedzieć i rozumieć dlaczego tak robi i czy nie może tego robić lepiej. Product Owner to ktoś decyduje o tym czym jest wdrażane oprogramowanie a najlepszym kandydatem jest autor opisu wymagań na ten produkt.

Zawsze mnie zastanawiało na jakiej podstawie dostawca oprogramowania, będąc pierwszy raz w firmie swojego potencjalnego klienta, ma odwagę powiedzieć, że jego oprogramowanie cokolwiek poprawi w tej firmie?

Analiza organizacji i projektowanie zmian

Podmiot gospodarczy to podmiot działający na rynku, i w związku z tym podlega prawom ekonomii. Szeroko pojętej ekonomii. Bez jej znajomości i rozumienia, żadna analiza biznesowa nie ma sensu! To co widzę pod nazwą Analiza Biznesowa, to nie żadna analiza biznesowa tylko lepszy lub gorszy opis (struktura) funkcjonowania firmy. Dobry opis działania jest jak opis gry w szachy: reguły gry, zły opis to kilkaset godzin filmu nakręconych nad planszą do gry w szachy [zotpressInText item=”{5085975:3K664DGK}”].

Opis działania firmy to opis mechanizmu jej działania a nie jej historia. Ta może być dowodem poprawności opisanego mechanizmu [zotpressInText item=”{5085975:6J8ZX2MR},{5085975:EMPAJKU9}”].

Druga ważna rzecz: jeżeli firma to system, to jej otoczenie rynkowe jest drugim systemem, albo “nad-systemem (super-systemem)”, albo jeżeli rynek to system, to firma jest jednym z jego podsystemów. To bardzo ważne, nie zapominajmy, że “to wszystko – rynek – to system współdziałających obiektów”. Kluczem jest to rozumienie mechanizmu jego działania, a ten mechanizm to prawa ekonomiczne [zotpressInText item=”{5085975:6J8ZX2MR},{5085975:EMPAJKU9}”].

Dzisiaj skupie się na kilku aspektach, mających duży wpływ na zrozumienie tego dlaczego firma ma pieniądze (lub zaczyna ich nie mieć…). Brzmi dziwnie ale po kolei. Powszechnie spotykanym terminem w analizach biznesowy jest “model biznesowy”. W 2006 roku już pisałem, że

Pojęcie modelu biznesowego plącze się po sieci i literaturze. Praktycznie każda firma go ma ale mało, która wie o tym i potrafi go udokumentować. Ma taki model, bo funkcjonuje na rynku ale ile firm ma te zasady udokumentowane w sposób spójny i zrozumiały dla pracowników i otoczenia? Osobną kwestią jest to, czy aktualny model jest dobry dla tej firmy bo okazuje się, że nie raz nie koniecznie. Nie raz okazuje się, że aktualny model prowadzi prostą drogą do bankructwa jednak o tym dowiadują się właściciele firm już po fakcie. (Źródło: Modele biznesowe | Jarosław Żeliński IT-Consulting)

Popatrzmy na definicje:

Model biznesowy – jest to plan, który tworzy przedsiębiorstwo w celu wygenerowania przychodu i maksymalizacji zysku operacyjnego. Określa relacje pomiędzy uczestnikami rynku, informuje jak przedsiębiorstwa działają, tj. w jaki sposób tworzą wartość dla klientów, towary i usługi oraz z czego czerpią zyski.

Jak podaje Timmers, model biznesowy to struktura produktu, usługi i przepływu informacji, zawierająca wyszczególnienie tzw. aktorów biznesowych wraz z ich rolami i opisem potencjalnych korzyści jakie odnoszą. Innymi słowy, jest to definicja źródeł przychodów[1].

Amit i Zott określają model biznesowy jako zawartość, strukturę i kierowanie transakcjami zaprojektowany w taki sposób, aby tworzyć wartość poprzez wykorzystywanie szans biznesowych.

Według Portera model biznesowy jest opisem działalności przedsiębiorstwa, które zapewniają mu zyski. Sprowadza się to do określenia roli organizacji w łańcuchu wartości, w jakim działa.

W kompleksowym ujęciu chodzi o metodę przyjętą przez firmę, przez realizację której będzie ona powiększać i wykorzystywać zasoby tak, aby oferować klientom większą wartość od konkurencji. Dzięki temu przedsiębiorstwo osiągnie wyższe zyski, a może nawet uzyska i utrzyma trwałą przewagę konkurencyjną.

Obłój definiuje model biznesowy jako ?połączenie koncepcji strategicznej firmy i technologii jej praktycznej realizacji, rozumianej jako budowa łańcucha wartości pozwalającego na skuteczną eksploatację oraz odnowę zasobów i umiejętności?. Wskazuje, że model biznesowy powinien odpowiadać na pytania: Co firma będzie robić? Jaki są jej podstawowe zasoby i kompetencje? W jaki sposób zasoby i kompetencje są skonfigurowane w praktyce codziennego działania? (Źródło: Model biznesowy ? Encyklopedia Zarządzania)

Sama główna definicja w moich oczach nie budzi wątpliwości. Popatrzmy jednak na rozwinięcia różnych autorów. Timmer mówi, że to “struktura”. U Amita i Zott’a pojawia się pojęcie “kierowanie”. Porter pisze, że to rola organizacji w łańcuchu wartości [zotpressInText item=”{5085975:2QJ8TSR7}”]. To co nazwano “kompleksowe ujęcie” zawiera pojęcie “metoda”. Obłój także raczej opisuje “strukturę”. Widać tu więc dwa główne sposoby postrzegania modelu biznesowego: (1) jest to struktura, (2) jest to mechanizm działania.

Osobiście jestem za tym, że “model” to “mechanizm” (ten zawsze zawiera swoją strukturę) z bardzo prostego powodu: model biznesowy to także model systemu jakim jest dana organizacja. Jeżeli uznamy, że model systemu to:

przedstawienie interesujących nas istotnych właściwości rzeczywistego (lub tworzonego) systemu w dogodnej dla nas postaci. Model systemu jest z reguły uproszczeniem rzeczywistości. Powinien zewnętrznie zachowywać się podobnie jak system, aczkolwiek może mieć inną strukturę wewnętrzną [zotpressInText item=”{5085975:UVCQZPJU}”].

to jeżeli ma się on (model) “zachowywać podobnie jak system (modelowany)”, to model ten musi także zawierać “mechanizm działania” (zachowania, czyli reakcje na bodźce). Mechanizm działania opisują “prawa” (reguły działania, i te narzucone i te naturalne).

 

Tak więc dochodzimy do sedna: model biznesowy. pojmowany jak wyżej, musi zawierać poza swoją wewnętrzną strukturą, także mechanizmy działania, to jak się zachowuje w określonych warunkach. Wynika z tego, że definicje modeli biznesowych określające je jako “struktury” są gruntu złe. Powodem dla których tworzymy modele, jest przewidywanie (zachowań, reakcji np. na zmiany).  Model nie zawierający mechanizmu jego działania na nic nie reaguje więc nie posłuży do żadnej analizy.

Na tym tle model (wzorzec) Lean Canvas jest wyłącznie pewną strukturą, która może posłużyć do oceny oceny organizacji, ale nie jest to model.  Model oparty np. na BMM (Business Motivation Model) zawiera między inny: strategię, taktykę, reguły biznesowe, polityki działania, czyli ustalone mechanizmy zachowania się (ograniczenia to także mechanizmy, opisałem to tu: Strategia, model biznesowy, architektura korporacyjna…).

Ekonomia i rynek

Teraz pora na ekonomię ;). Pewnie większość z Was słyszała o czymś takim jak “prawo popytu i podaży” na rynku. Otóż to znane prawo ma szerszy kontekst. Jest bardzo ważne w analizie biznesowej, bo modelując organizacje (przypominam, że model zawiera mechanizm działania i zachowania czyli reakcje na bodźce: reguły i prawa) należy zrozumieć jak się zachowują, dlaczego, i umieć to zapisać (stworzyć model). Jednak sama podaż i popyt to mało. Idąc za Porterem, kluczem jest pojęcie postrzeganej wartości dodanej, niedoboru czy nasycenia rynku.

Prawo popytu i podaży mówi, że w warunkach niezmienności innych zjawisk rynkowych, popyt zmienia się z reguły w odwrotnym co cena, a podaż w tym samym kierunku co popyt. Nadwyżka popytu nad podażą powoduje wzrost ceny, nadwyżka podaży nad popytem jest przyczyną spadku ceny. Prawo to jest słusznie uznawane za podstawę ekonomii, jednak ono samo z siebie nie daje się stosować bezpośrednio gdyż, założenie “niezmienności innych zjawisk rynkowych” jest na dzisiaj nie do przyjęcia, a same zależności nie są jednak liniowe. Tak więc to, fundamentalne prawo wskazujące na ogólny mechanizm, jest w warunkach rzeczywistych zbyt proste i ogólne, jest bezwartościowe. Do analiz należy użyć modeli zawierających opis mechanizmu działania rynku odwzorowujący rzeczywistość czyli fakty.

Pierwsza rzecz to cena tego samego lub takiego samego, produktu.

Najprostsza z tych zależności, pokazuje, że cena spada wraz zer wzrostem popytu (bo, jak pamiętamy rośnie podaż)  rośnie podaż. Jednak nie jest to spadek liniowy i ma określony próg:  jest to koszt produktu w miejscu jego sprzedaży. Świadomie nie napisałem “koszt wytworzenia” bo to nie prawda. Koszt w miejscu sprzedaży to koszt wytworzenia plus koszt dystrybucji plus koszt sprzedaży (lokal, wynagrodzenie sprzedawcy, itp.).  Dla porządku dodałem pojęcie dumpingu czyli sprzedaż po cenie niższej od kosztów (element spekulacji i nieuczciwej konkurencji, w wielu krajach tyleż zakazany co trudny do udowodnienia).

W marketingu znane jest pojęcie substytutu: jest to inny produkt ale niosący te same korzyści kupującemu: np. (nie zawsze) wypożyczenie samochodu jest w określonych sytuacjach substytutem jego zakupu a tabletka przeciw bólowi zęba może być substytutem usunięcia bolącego zęba. Te wszystkie niuanse należy zawsze zrozumieć tworząc model biznesowy.

Kolejny wykres to uzupełnienie poprzedniego:

Prawo popytu i sprzedaży, odbierane wprost, nie bierze pod uwagę pojęcia  wartości postrzeganej lub maksymalnej wartości akceptowanej. Przede wszystkim nie są to wartości obiektywne (w razie wątpliwości zastanówcie się ile Wy jesteście skłonni zapłacić za przedwojenny znaczek pocztowy). Należy więc, przed jej oszacowaniem, zdefiniować sobie cechy i motywację do zakupu potencjalnego klienta. To się nazywa definicją grupy docelowej. Istotne są także warunki, np. cena butelkowanej wody mineralnej rośnie natychmiast na terenach dotkniętych powodziami czy trzęsieniami ziemi (niedobór wody pitnej wywołany kataklizmem). Tak więc wzrost niedoboru jest przyczyną wzrostu cen tylko do pewnego określonego poziomu: jest nim maksymalna wartość postrzegana (wartość przy której jesteśmy skłonni do dokonania wymiany).

Popatrzmy na całość:

(wszystkie powyższe wykresy to opracowanie własne autora)

Na tym wykresie pokazałem wpływ podaży na cenę uwzględniając powyższe “cząstkowe zależności”.  Zaczynając od niedoboru (lewa strona), cena jest najwyższa, progowa (wartość postrzegana). W miarę rosnącej podaży zaczyna spadać. Tu mała uwaga: to podaż kształtuje cenę a nie cena podaż 😉 (nie jest to symetryczna zależność). Rosnąca podaż prowadzi do ceny najniższej możliwej wyznaczonej przez koszt.

Dopiero na takim wykresie można prowadzić “badania”, ten wykres to mechanizm działania rynku (z jakiejś perspektywy i w jakimś uproszczeniu). Tłumaczy on np. mechanizm akcyzy: produkt o bardzo wysokiej postrzeganej wartości, mimo dużej podaży (np. alkohol) może mieć na rynku wysoką cenę, za sprawą Państwa, które poprzez akcyzę podnosi koszty. Jak nie trudno się domyśleć, może to zrobić wyłącznie Państwo jako jedyny legalny monopolista. To także tłumaczy, dlaczego praktycznie na całym świecie Państwa uznają wszelkie zmowy (kartele, trusty) tworzące monopole, za nielegalne dlatego, że jest to mechanizm spekulacyjny. Owszem są legalne formy monopolu takie jak patenty i prawo autorskie, jednak prawo dopuszcza je wyłącznie wtedy, gdy dane dobro nie jest uznawane za podstawowe dla życia, bo wtedy wkracza Państwowy regulator. Jaskrawym przykładem była niedawna idea państwowego podręcznika jako odpowiedź na zmowę cen ich wydawców.

W tym miejscu mała niespodzianka. Napisałem na początku, że nie będzie dzisiaj żadnych klas ani procesów, i jest to “prawie prawda” :). Otóż, gdybyśmy chcieli modelować analizowaną firmę, mielibyśmy model w postaci dwóch obiektów: Firma oraz Rynek. Ten drugi miałby operację “Za ile kupisz mój produkt”, a wynikiem tej operacji była by Możliwa Cena Zakupu tego produktu, metoda (mechanizm realizujący tę operację) była by zależnością opisaną tym ostatnim wykresem.

Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje:
– sama struktura to nie model,
– tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury,
– dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]),
– bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek  zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.

(dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Bardzo często spotykam się z dokumentami, w których – na modelach procesów biznesowych – pojawia się rola System (nie raz konkretne oprogramowanie). Dość dawno temu także robiłem “podejścia” do takiego postrzegania organizacji, jednak z każdym kolejnym projektem przekonywałem się, że to jednak złe podejście. Po pierwsze dlatego, że mieszanie mających swobodę podejmowania decyzji ludzi, jako wykonawców czynności, i deterministycznego oprogramowania, jako kolejnych wykonawców, szybko prowadź do sytuacji, w której tracimy zrozumienie działania np. firmy. Pracownicy mają pewien zakres swobody działania (każdy ma jakieś umiejętności, które są celem jego zatrudnienia) zaś oprogramowanie to tylko narzędzie bez tożsamości. Po drugie istota funkcjonowania ludzi i organizacji z nich złożonych, tkwi w osiąganiu celów a te maja ludzie, maszyna nie ma celu, maszyna da określony, przewidywalny w 100% wynik działania. Owszem, i człowiek i maszyna wymaga impulsu do działania, ale jednak człowiek mając cel, podejmuje decyzję, w odpowiedzi na bodziec maszyna wykonuje jedynie program (deterministyczny algorytm, maszyny nie podejmują decyzji a wykonują program).

Przykładem porażek ponoszonych z powodu uznania “oprogramowania” (w tym automatyzacji pewnych czynności) jako “wykonawcy” (roli), są wdrożenia systemów  obiegu dokumentów. Objawem porażki jest omijanie oprogramowania wszędzie tam, gdzie stanowi ono przeszkodę w pracy (pracownik dla zrealizowania swojego celu szuka innej drogi niż ta na jaką mu pozwala oprogramowanie, nie mam tu na myśli nadużyć), a będzie tak zawsze gdy tylko uznany, że deterministyczne oprogramowanie będzie pełniło rolę “pracownika” realizującego określony etap pracy w procesie biznesowym. Owszem bywają miejsca, gdzie konkretną umiejętność człowieka można zakwalifikować jako “automat”, jednak nadal to człowiek powinien tego automatu świadomie używać, a nie być przez niego zastąpionym. W przeciwnym wypadku szybko odkryjemy coś co nazywamy “bezdusznością” systemu. Przesłanka do porażki są tworzone dziesiątki diagramów opisujących  procesy ze szczegółowością sięgającą pojedynczych prostych czynności takich jak “podaj, przekaż, wstaw do pole, itp….).

Granicę pomiędzy świadomą pracą człowieka a ewentualnym jej automatyzowaniem wyznaczają procedury. Pisałem o tym niedawno dość dokładnie w artykule Sekwencje a procesy. Tu tylko przypomnę, że proces (także ten elementarny, niepodzielny na podprocesy) jest wykonywany przez człowieka wg. jego woli albo zgodnie z narzuconą mu procedurą. Owszem, cała ta procedura może być deterministyczna i dająca się zautomatyzować, ale to człowiek decyduje o jej użyciu (uruchomieniu). Innymi słowy, niezależnie od tego czy potrafimy “w głowie” wykonać każde z czterech działań podstawowych (dodawanie, odejmowanie, mnożenie, dzielenie) czy używamy kalkulatora nadal to “my” np. mnożymy liczby a nie “kalkulator” (sam z siebie).

Dobrze opisuje to [[prakseologia]]:

Analizując dostępną literaturę, etapy działania można sformułować w następującej postaci: Sprawca działania chcąc osiągnąć zamierzony uprzednio cel oraz pod wpływem impulsu dowolnego, działając w danym otoczeniu, za pomocą narzędzi i metod oddziaływuje na tworzywo, czego skutkiem jest powstanie wytworu. Sprawcą działania zawsze jest człowiek a impulsem dowolny motywator do działania. (Prakseologia ? Encyklopedia Zarządzania).

Powyższe to nic innego jak definicja procesu: sprawca to rola (wykonawca), impuls to zdarzenie inicjujące proces, otoczenie to wszelkie ograniczenia, narzędzia to między innymi oprogramowanie (automaty), tworzywo to stan wejścia (informacje wejściowe, przetwarzane), wytwór to cel pracy, produkt procesu. Sprawcą jest zawsze człowiek, który do działania zawsze wymaga bodźca i użyje – jeżeli ma takie – narzędzi (np. oprogramowania).

Tak więc to zawsze człowiek decyduje o tym, co zrobi w reakcji na określony bodziec, nawet jeżeli ta reakcja ma się sprowadzić do naciśnięcia jednego guzika inicjującego automatyczną pracę wielkiej maszyny.

Takie postrzeganie systemu, jakim jest każda organizacja (wraz z jej zasobami, w tym narzędziami, oprogramowaniem), prezentuje model MDA (www.omg.org/mda) dzieląc modele opisujące organizacje na modele CIM i PIM. Ten pierwszy to model organizacji niezależny od “systemów informatycznych” (Computing Independent), tu jest miejsce na zrozumienie istoty działania organizacji , a narzędzie jakich organizacja używa nie stanowią tej istoty. PIM to model narzędzia, logiki jego działania (algorytmy) a nie organizacji.

Tak więc modele procesów, w których pojawiają się tory reprezentujące jakiekolwiek oprogramowanie gwałcą tę podstawową zasadę: organizacja to celowe działanie ludzi, narzędzia im w tym tylko pomagają, narzędzia nie są istotą działania organizacji. Można to sprawdzić czymś co ja nazywam testem wyłączenia zasilania: czy wyłączenie automatów pozbawi organizację sensu jej istnienia? Jeżeli nie to znaczy, że automaty nie pełnią ról w procesach, a są jedynie narzędziami w rękach ludzi. Narzędzi nie umieszczamy więc w modelach procesów. Narzędzia modelujemy osobno jako “system” i jego przypadki użycia (użycia przez aktora, jakim tu jest człowiek).

Kolejne analizy przedsiębiorstw za mną, a wraz z nimi obserwowane stereotypy i konformizm wielu moich klientów. Tym razem kilka słów o tym co to jest “system zintegrowany”. Otóż bardzo wielu ludzi utożsamia to pojęcie z “współdzieleniem danych”.  Sprzedawcy oprogramowania ERP jak mantrę powtarzają “nasz system jest zintegrowany bo wszystkie dane są wspólne, więc wszystkie informacje wprowadzany tylko raz i są wszędzie dostępne”. O ERP i integracji pisałem w Duży ERP czy integracja, o idei i wyższości integracji na poziomie usług zamiast współdzielenia danych pisałem w Wymagania pozafunkcjonalne … Teraz popatrzmy na to od strony architektury biznesowej.

 

Nie ulega wątpliwości, że np. pracodawca potrzebuje danych o nas, o naszym wykształceniu. Czy to znaczy, że optymalne jest, by systemy kadrowo-płacowe współdzieliły wszystkie dane z urzędami stanu cywilnego i ze szkołami? Wszyscy wiemy, że po wielu latach spędzonych w szkołach, mimo ogromnej ilości danych szczegółowych o naszej edukacji, zebranych w tych szkołach, pracodawcy wystarczy wymagane świadectwo jej ukończenia oraz nasze imię, nazwisko, data i miejsce urodzenia. Zarówno Szkoła jak i Urząd  Stanu Cywilnego mają znacznie bogatsze dane na nasz temat, co nie znaczy, że “inne podmioty” powinny je współdzielić. Szkoła na żądanie wyda odpis świadectwa a Urząd odpis aktu urodzenia (bo nawet nie poszczególne oceny czy poszczególne dane osobowe). Pisząc wcześniej o integracji wskazywałem na korzyści minimalizacji interfejsów i separacji danych.

Tak więc mityczna “integracja w systemach ERP”  w rozumieniu “wspólne dane” to może jednak relikty technologii z przed 30/40 lat, konformizm kupujących i opór przed zmianą u dostawców? Zaryzykuję tu tezę, że dostawcy wielu systemów ERP fundują nam po prostu dług technologiczny. Czy mam rację? Popatrzmy na jedne z ostatnich badań Gartnera:

Omawiając strategie firm, Gaughan podkreślił również znaczenie działających przy nich ośrodków badawczych. Ich nadrzędnym celem jest tworzenie innowacji w takich sposób, aby ? zachowując pozory rozwoju ? utrzymywać istniejący stan rzeczy tak długo, jak to tylko możliwe.(Czego największe firmy technologiczne nie mówią swoim klientom?)

O co tu chodzi?

 

Model rynku i przedsiębiorstwa

Najpierw dla porządku przypomnę pojęcie wartości dodanej Michaela Portera:

Wartość dodana pracy, to różnica postrzeganej wartości rynkowej produktu przed i po wykonaniu nad nim pracy. Skoro wartość rynkowa to konsekwencja powstającej wartości dodanej, nie trudno się domyślić, że cena rynkowa produktu także wzrośnie po jego “przetworzeniu”.  Powyższy diagram pokazuje ogólną zasadę wartości postrzeganej: dokonujący wyboru Nabywca wie, że cena towaru przetworzonego jest wyższa od ceny towaru uzyskanego bezpośrednio ze Źródła zaopatrzenia. Jeżeli mimo to decyduje się na ten droższy, oznacza to, że dostrzega wartość tego przetworzenia i jest skłonny za to zapłacić. Przykładem może być to, że dla rowerzysty stos żelaza i gumy ma jednak mniejszą wartość niż rower, ryba dostępna w sklepie 800 km od morza ma większą wartość niż ta sama ryba w tak oddalonym porcie. Tyle w kwestii wartości dodanej.

Popatrzmy teraz na to co się dzieje w powyższym “Podmiocie gospodarczym”. Powyższy Podmiot gospodarczy to taka oto struktura:

 

Podmiot gospodarczy tworzy wartość dodaną poprzez przemieszczenie produktu w przestrzeni i  czasie (ten sam produkt zostaje dostarczony w określone miejsce, np. sieci dystrybucji) oraz (lub) wytwarzając lub przetwarzając określone produkty (tu półprodukty) lub surowce. Generalizując: podmioty gospodarcze to złożenie (kombinacje) wytwarzania i dystrybucji. Aby możliwe było wytwarzanie, potrzebna jest aktywność polegająca na projektowaniu. Na diagramie połączono to wszystko w pewien określony ciąg logiczny działań. Z uwagi na to, że projektowanie z reguły nie odbywa się w sposób przypadkowy, w sposób przemyślany zbierane są informacje z rynku na temat potrzeb Nabywców (rynku).

System informacyjny

Aby możliwe było zarządzanie tym wszystkim, konieczne jest śledzenie tych aktywności, ich skutków i przyczyn. Śledzenie to nic innego jak zbieranie danych “o tym co chcemy wiedzieć”. Jak mawiają specjaliści z dziedziny zarządzania: “zarządzać można tylko tym co potrafimy mierzyć”.  O czym mowa? O faktach:

 

Wszystkie aktywności podmiotu gospodarczego, tworzą określone fakty, jest nim np. sprzedaż (moment przeniesienia własności produktu na nabywcę), ten fakt jest dokumentowany fakturą VAT.  Oczywiście wiele takich faktów ma miejsce wewnątrz podmiotu (np. przekazanie wytworzonego produktu do magazynu wyrobów gotowych itp.).

Takich faktów w firmach jest wiele, jednak do celów zarządzania nią, kolekcjonujemy ich ściśle określoną liczbą. To, które fakty rejestrujemy (zbieramy dane) zależy od przyczyny np. prawo i podatki są przyczyną dokładnego śledzenia faktów związanych z wszelkimi operacjami dotyczącymi kosztów działalności i przychodów. Wewnętrzne potrzeby związane z zarządzaniem, są przyczyną zbierania (monitorowania) kolejnych szczegółów.

Poza opisem faktów, kolekcjonujemy w różnej formie, zasady regulujące to jakie fakty mają prawo lub muszą zajść: to reguły biznesowe. Zbiór tych danych (opisy faktów) i ich wzajemnej zależności to system informacyjny: informacje o tym co się wydarzyło. Czego nam tu “troszkę” brakuje? Tego co nazywamy np. księgowością czy zarządzaniem kadrami (w tym wynagrodzenia). Jednak one właśnie są “tylko” narzędziem do przetwarzania danych o faktach. Celowo nie umieściłem na diagramach tych “aktywności” bo one są pracami polegającymi na śledzeniu i monitorowaniu, na sprawozdawczości. Tak na prawdę wystawienie faktury VAT (opis faktu sprzedaży) jest częścią aktywności jaką jest sprzedaż. Do celów podatkowych potrzebne są tylko zagregowane dane z faktur. Itd.

Architektura biznesowa

Wiemy więc już, że Podmiot gospodarczy to określone aktywności: projektowanie, wytwarzania, sprzedaż, zaopatrzenie, obsługa “pytań” czyli tak na prawdę “różnych spraw” (mogą być jeszcze inne, zależnie od specyfiki podmiotu i branży, np. zarządzanie projektami w firmie usługowej). Każda z tych aktywności tworzy określone fakty, pewna część danych o nich – bo nie wszystkie – mogą być potrzebne “na zewnątrz”. Np. spośród wszystkich szczegółowych informacji o realizacji dużego projektu, do rozliczenia jego koszów i wystawieniu faktury, potrzebne są wyłącznie określone zagregowane dane a nie wszystkie jakie znamy. Dotyczy to praktycznie każdej z wymienionych aktywności. Jaki z tego wniosek? Nie musimy współdzielić w jednym miejscu wszystkich danych o poszczególnych aktywnościach. Poszczególne aktywności przekazują pomiędzy sobą tylko swoje produkty, i tylko przekazywanie danych je opisujące ma sens. Zarządzanie każda aktywnością odbywa się lokalnie (w niej) i tylko tu jest potrzebna “pełna wiedza”, każda z tych aktywności to zamknięty i względnie niepodzielny proces tworzenia wartości dodanej (hermetyzacja) od którego na zewnątrz wymagamy wyłącznie zagregowanej informacji, udostępnianie nadmiaru szczegółów na zewnątrz niczemu nie służy (poza przypadkami gdy część z nich udostępniamy do do szczegółowych analiz, te jednak także wykona zewnętrzny dedykowany podsystem. Prowadzenie rozliczeń i sprawozdawczość to kolejna aktywność, która także wymaga tylko określonych zagregowanych danych a nie “wszystkich jakimi dysponujemy”.

Systemy ERP (pierwotnie tylko FK, potem MRP i MRPII) powstawały jako systemy rejestrujące dla określonych podmiotów. W latach 80-tych i 90-tych (wtedy one powstawały), firmy raczej się rozrastały, ich wewnętrzna zmienność była bliska zeru, dlatego architektura w postaci jednej dużej relacyjnej bazy danych  i zestawu funkcji je przetwarzających, miała swoje uzasadnienie. Rozwój firmy wymagał praktycznie tylko dodawania nowych funkcji, czasem zmiany już istniejących, raczej nie wymagał zmian w modelu danych.

 

Opisane wyżej aktywności mogą być realizowane w jednym podmiocie, ale mogą to być odrębne podmioty. Dotyczy to także aktywności, jaką jest prowadzenie rozliczeń (np. zewnętrzne biuro rachunkowe, spółka zależna itp.).  Zmienność sytuacji rynkowej, zmiana strategii, przejęcia, wydzielanie spółek zależnych, to wszytko ma prawo przytrafić się każdej firmie i organizacji. To znaczy, że podmiot gospodarczy może być złożony z dowolnego, zmieniającego się,  zestawu powyższych aktywności. Jaki z tego wniosek?

Skoro powyższe aktywności są od siebie niezależne, takie też powinno być oprogramowanie, które pozwala nimi zarządzać. Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie.  Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość)  to niemalże “zabetonowanie” architektury biznesowej firmy.