Aspiryna na kryzys czyli czego pilnować w firmie i na co wydawać
Transkrypt
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