Aspiryna na kryzys czyli czego pilnować w firmie i na co wydawać

„Jeżeli nie potrafimy czegoś narysować to znaczy, że to dla nas nie istnieje.
Jeżeli potrafimy coś narysować to znaczy, że rozumiemy jak to funkcjonuje.”
Aspiryna na kryzys czyli czego
pilnować w firmie i na co
wydawać pieniądze w kryzysie
Na kompletne ERPII? Nie! Firmy produkcyjne powinny inwestować w podsystemy
MRPII, firmy handlowe w podsystemy logistyczne i zaopatrzenia, firmy usługowe w
podsystemy zarządzania projektami itp. Ktoś zapyta a gdzie CRM? Hm…
Kryzys zmusza do jeszcze bardziej wnikliwego myślenia i o strategiach rynkowych i o
strategiach IT, bez których w sumie trudno sobie wyobrazić te pierwsze. Dwa lata temu
pisałem o tym, że nadejdzie koniec systemów zintegrowanych w roli jednego uniwersalnego
systemu w firmie:
http://it-consulting.pl/php/html/modules.php?name=News&file=article&sid=213
Jak pokazuje rynek i dotychczasowe wdrożenia, systemy ERP stają się raczej szkieletem,
kręgosłupem, a nie jedynym i zintegrowanym pakietem wspomagającym zarządzanie w
firmie. Dlaczego tak się dzieje można przeczytać między innymi w powyższym artykule, tu
wspomnę tylko o tym, że zależnie od firmy czy organizacji różne elementy (procesy
biznesowe) są tymi kluczowymi i nie zawsze te same. Skoro tak jest to znaczy, że kluczowe
elementy organizacji zaopatrzymy w możliwie najlepsze rozwiązania (czytaj kosztowne) a
pozostałe w „wystarczająco dobre” (czytaj ekonomiczne) i nie dla każdej firmy będą to te
same elementy.
Referencyjny model podmiotu rynkowego
Co prawda modele referencyjne dla firm wzbudzają moją nieufność ale dla rynku czemu nie,
warto je stosować, są bowiem pewne prawdy, które spokojnie można uznać za ogólne. Za
jedną z takich prawd ja uznaję model działania podmiotu na wolnym rynku. Model ten
zakłada, że firma powstała by dostarczać pewnych wartości na rynku (czy generować
bezpośredni zysk to już osobna kwestia modelu biznesowego).
Model ten u różnych autorów wygląda różnie a u mnie? Po kolei. Łańcuch kluczowych
procesów uznawany za taki w wielu firmach to: zapytanie, oferta, zamówienie, faktura aż do
wpływu środków na konto. Jednak takie przedstawienie sytuacji ma pewną wadę: moim
zdaniem nie prawdą jest, że pieniądze na koncie są efektem zapytań (a tak często są
modelowane główne procesy w firmach). Jak proces to proces a ten przekształca wejście
wyjście.
Gdzie problem? Po pierwsze liczba faktur (zamówień, umów itp.) nijak się nie ma do liczby
zapytań nie licząc statystyki opisującej skuteczność procesu ofertowania. Po drugie skoro nie
ma obligatoryjnego powiązania oferty z zamówieniem (nie licząc ich logicznego związku
Jarosław Żeliński http://IT-Consulting.pl , 05-130 Zegrze, ul. Osiedle Wojskowe 55 m24, NIP: 536-137-05-83,
REGON: 012633010, wpis do ewidencji działalności gospodarczej prowadzony przez Wójta Gminy Nieporęt
nr.: 2734, NRB: 42 1240 1024 1111 0010 0268 0324
IT-Consulting.pl
jakim jest powołanie się na ofertę przy zamówieniu ale nie koniecznie!) to nie jest to jeden
proces a co najmniej dwa osobne. Tak więc brak obligatoryjnego następstwa zamówienia po
ofercie, nieznany (nie da się go zaplanować!) czas pomiędzy wysłaniem oferty a otrzymaniem
zamówienia (lub zawarcia umowy) oraz możliwość otrzymania zamówienia bez dedykowanej
oferty powodują, że osobiście klasyfikuje działania ofertowe i realizacje zamówień jako dwa
procesy: obsługa zapytań i obsługa zamówień.
Kolejna rzecz to „generowanie” zapytań, pozyskiwanie kontaktów itp. Tu, w ramach
segmentacji rynku odbiorców, możemy wyróżnić:
1. działania masowe (np. wartość przeciętnej transakcji mniej niż - tu kłania się strategia
firmy),
2. działania indywidualne (np. wartość przeciętnej transakcji więcej niż i tu także kłania się
strategia firmy).
Ale … na początek dodam jednak jeszcze „stwarzanie mechanizmu kierowania zapytań
ofertowych dla naszej firmy”. Mamy więc cały łańcuch wydarzeń, który po drobnej korekcie
wygląd a następujący sposób:
1. Generowanie zainteresowania ofertą (produktem są po pierwsze produkty rynkowe firmy
po drugie ich rozpoznawalność na rynku i wizerunek firmy jako ich dostawcy)
2. Obsługa zapytań (produktem jest oferta)
3. Obsługa zamówień (produktem są środki ze sprzedaży na koncie).
Przyszła pora na coś co nazywa się modelowanie (zarządzanie) zorientowane na zdarzenia
(ang. Event Driven Modeling). Tu tylko zaznaczę, że te trzy odrębne procesy zamiast jednego
„dużego” to efekt właśnie analizy i modelowania zorientowanych na zdarzenia. Osoby
zainteresowane tą technika analizy i modelowania zapraszam na mój kurs modelowania
procesów biznesowych. Taki jak ten, esej nie jest niestety dobrym miejscem na dodatkowe
wykłady.
W co inwestować?
Przede wszystkim w główny proces. Kluczem są przychody i koszty więc firmy produkcyjne
powinny inwestować w podsystemy MRPII, firmy handlowe w podsystemy logistyczne i
zaopatrzenia, firmy usługowe w podsystemy zarządzania projektami itp. Ktoś zapyta a gdzie
CRM? Hm… należy upewnić się od czego zależy nasza rentowność, liczba naszych
klientów. W kryzysie przede wszystkim należy utrzymać swoich klientów bo to tańsze niż
skupiać się na ich pozyskiwaniu bo to znacznie kosztowniejsze. Pozyskania klienta oznacza
odebranie go konkurentowi, co robią nasi konkurenci? Wielu z nich próbuje nam właśnie
odebrać stałych klientów wiec jak nie pozyskamy nowych klientów to zapewne nie
zwiększymy sprzedaży ale jak stracimy klientów to spadnie nam sprzedaż.
http://it-consulting.pl/php/html/modules.php?name=News&file=article&sid=264
© Jarosław Żeliński
2/4
środa, 10 marca 2010
IT-Consulting.pl
W zasadzie każda firma
Problemem wielu modeli procesów jakie widuje jako ich audytor jest to, że mówią
nieprawdę. Jak to się dzieje? Otóż skoro model to uproszczony opis rzeczywistości to znaczy,
że mimo uproszczeń musi „mówić prawdę”. Gdzie tu kłamstwa? Jeżeli na modelu już
umieścimy jakiś symbol obrazujący np. decyzje TAK lub NIE to znaczy, że innych być nie
może! Nie jest poprawnym modelem diagram, który opisuje kilka z wszystkich wybranych
wariantów, i nie jest wytłumaczeniem, że nie znamy wszystkich. Podstawowym źródłem tej
tezy jest założenie, że model MUSI się zachowywał tak jak ORYGINAŁ. W przeciwnym
przypadku nie jest modelem tylko jakimś opisem części rzeczywistości.
Spójrzmy na diagram:
Jak nietrudno się domyśleć, romby to miejsca powstawania wariantów (różnych scenariuszy),
karteczki t treść dokumentów jakie „płyną” wzdłuż tego procesu . Pytanie brzmi: czy w
zaznaczonych punktach (romby decyzyjne), w swoich firmach, znamy wszystkie możliwe
warianty? Jeśli nie to znaczy, że nie potrafimy opracować kompletnej (pełnej) listy
wszystkich możliwych decyzji w punktach oznaczonych rombem. Wniosek? Powyższy model
jest zły bo może się wydarzyć coś czego ten model nie przedstawia. Czy to źle? Moim
zdaniem tak, bo wtedy model przestaje być modelem a staje się jakimś diagramem, opisem
pewnych, nie wszystkich, zachowań modelowanej organizacji.
Jakie są tego skutki? Np. takie, że jeśli na podstawie takiego modelu opracujemy wymagania
na oprogramowanie lub zaprojektujemy zmiany organizacyjne to prawie na pewno podczas
wdrożenia lub po nim, zdarzy się coś, czego nowe oprogramowanie nie obsłuży bo model,
który posłużył do analizy wymagań tego nie zawierał! Co zrobić? To proste: modelować
prawdę . Jak? Popatrzmy na model poniżej:
© Jarosław Żeliński
3/4
środa, 10 marca 2010
IT-Consulting.pl
Jest to tak zwany model zorientowany na zdarzenia (kółeczka to zdarzenia obrazujące stan
początku i końca procesu). Co się zmieniło? Skoro nie potrafimy zdefiniować sytuacji
warunkowej nie próbujmy jej modelować, uznajmy, że np. po wysłaniu oferty czekamy na
zamówienie (lub inne zdarzenie) bo i tak nie wiemy i nie będziemy wiedzieli co się może
wydarzyć u klienta od momentu gdy dostał ofertę do momentu gdy zamówił (choć wiem, że
chcielibyśmy). Uznajmy także, że nie wiemy (nie zawsze wiemy) co powoduje, że czasem
zamówienie nie nadejdzie.
W poprzednim przypadku dokument oferty był przekazywany do procesu obsługi zamówień.
Czy to prawda? Myślę, że nie. Nie wystawiamy faktur na bazie ofert, czekamy na
zamówienie, które nie musi nadejść (pominąłem tu zupełnie osobne działania nakłaniające
klienta do złożenia zamówienia ale to inny proces). Tu mamy bliższe prawdy udostępnienie
np. w procesie obsługi zamówień dane o złożonych ofertach. Obsługa zapytania nie naturalna
konsekwencją wysłania oferty, obsługa naprawy nie jest naturalna konsekwencja sprzedaży
produktu. Pierwsze zdarza się z jakimś prawdopodobieństwem zależnym od naszej
skuteczności drugie od jakości produktu.
A gdzie tu np. księgowość czy informatyka? Nie ma  bo to nie procesy tylko zasoby!
Polecam także:
O modelowaniu:
http://it-consulting.pl/php/html/modules.php?name=News&file=article&sid=210
© Jarosław Żeliński
4/4
środa, 10 marca 2010