Podstawową korzyścią z wyodrębnienia reguł biznesowych i słownika pojęć jest uporządkowanie słownictwa w dokumentacji i uczynienie jej jednoznaczną oraz weryfikacja ewentualnych sprzeczności regulacji wewnętrznych (Zarządzeń, Prawa). Powoływanie się na Reguły biznesowe na modelach procesów biznesowych, pozwala zachować ich prostotę nie tracąc szczegółowości wiedzy o procesach. Tak wykonana dokumentacja procesów nie wymaga częstej i kosztownej aktualizacji, z reguły aktualizowane są procedury i reguły biznesowe, na które modele procesów się powołują.Tak więc akty prawne to zakazy i nakazy, reguły biznesowe. Oprogramowanie, zależnie od przyjętej konwencji, nie powinno ograniczać ani nawet utrudniać postępowania zgodnego z prawem, może pojawić się oczekiwanie by nie pozwalało łamać prawa. Szczegółowa analiza aktów prawnych, w moich oczach, ma sens gdy projektujemy oprogramowanie. Gdy stawiamy wymagania przed już istniejącym oprogramowaniem, zakładamy że kupimy gotowe, wystarczy wymagać zgodności z prawem w obszarze stosowania oprogramowania. Jeżeli np. oprogramowanie ma pozwalać na wystawianie faktur to znaczy, że powinno być możliwe wystawienie każdej faktury przewidzianej prawem w sposób zgodny z nim. Możemy dodatkowo zażądać by nie było możliwe wystawienie faktury niezgodnej z prawem.
Wdrożenie systemu CRM poprzedzać powinna szczegółowa analiza procesów biznesowych oraz realnych potrzeb organizacjiTo w zasadzie podsumowanie powyższych uwag. CRM to praktycznie dwa kluczowe aspekty:procesy biznesowe związane z obsługą zdarzeń dotyczących klientów,
repozytorium dokumentów powiązanych z tymi zdarzeniami.
Te dwa powyższe punkty skłaniają mnie do postawienia tezy, mówiącej żedobry system CRM to system wspomagający procesy biznesowe związane z obsługą klientów oraz zarządzający informacjami związanymi z obsługą klientów. Powinien też integrować te dane w całej organizacji.Dlatego warto rozważyć, analizę obecnej sytuacji w firmie i wdrożenie, zamiast oprogramowania mającego w nazwie CRM, systemu typu workflow wraz z repozytorium dokumentów. Przy ograniczonym budżecie doskonale, w roli CRM, sprawdzają się same repozytoria dokumentów, które później zawsze można uzupełnić systemem wspierającym procesy biznesowe.
Do moich klientów należą także małe i średnie firmy. Każdy projekt związany z analizą i modelowaniem procesów biznesowych wymaga znajomości (posiadania) i rozumienia strategii firmy przez analityka. Moim zdaniem porażki wielu projektów związanych z modelowaniem procesów biznesowych, analizą wymagań na (jakiekolwiek) oprogramowanie wspomagające zarządzanie, mają swoje źródło w ignorowaniu strategii analizowanej firmy. Każdy taki projekt jak analiza procesów biznesowych i specyfikowanie wymagań na oprogramowanie, wymaga pewnej podstawowej informacji: cel biznesowy! Stanowi on podstawę odpowiedzi na jakiekolwiek pytanie zaczynające się od słów "do czego będzie służyło...". Jednak cele biznesowe to stanowczo za mało w takich projektach, konieczna jest także znajomość strategii (w ogóle jej istnienie). Czym jest…
Polecam ciekawy artykuł na temat definicji procesów, w szczególności Procesu Biznesowego. Zestawiono ze sobą rożne definicje na przestrzeni ostatnich niemal 20 lat. Najbardziej podoba mi się prostota: "a business process is a series of steps designed to produce a product or service" (proces biznesowy to sekwencja działań zaprojektowanych w celu wytworzenia produktu lub usługi).Jeśli uznamy, że produkt i usługa to "coś co ma wartość dla klienta" to powstaje prosta i prawdziwa moim zdaniem definicja opisująca "sedno sprawy". Ogólnie wymowa artykułu potwierdza moją tezę o abstrakcyjności "procesu", namacalne są za to pozostałe jego elementy: wejście i wyjście (produkty), zasoby (ludzie i maszyny) oraz reguły biznesowe (te są dokumentowane).
Wiele się mówi o regułach biznesowych jednak definicja tego pojęcia nie jest taka oczywista. Czym są te reguły? Po przejrzeniu Internetu i literatury uznałem swego czasu, że podejmę próbę stworzenia takiej definicji a raczej usystematyzowania tego co można przeczytać, bo faktycznie nowej definicji nie wymyśle i nie mam takich ambicji. Po drugie uporządkowania nazewnictwa w tej sferze wymaga formalizowanie modeli biznesowych: reguła biznesowa jako pojęcie musi, na użytek modeli, być dobrze zdefiniowana w tych modelach. Na początek warto przypomnieć czym jest model biznesowy: jest to opis tego w jaki sposób firma…
Tak więc stosowanie formalnych notacji i zasad obniża ryzyko projektu. Nie wyeliminuje go, bo model i jego jakość zależy bardzo od jego twórcy (modelowanie to jednak sztuka a nie rzemiosło), jednak łamanie zasad lub stosowanie nieformalnych diagramów stanowi kluczowe ryzyko projektów na etapie analizy.
Procesy biznesowe to nie kolejny termin do opanowania, lecz codzienność każdego przedsiębiorstwa. Z naszym udziałem, bądź nie ? procesy zachodzą. Tylko od podejścia kierownictwa zależy, czy będziemy nad nimi panować i sprawnie zarządzać, przyczyniając się do poprawy funkcjonowania firmy. Czy nam się to podoba, czy nie, procesy biznesowe to element naszej organizacji. Świadome i odpowiedzialne podejście pozwoli zarządzać nimi mądrze.
Z danymi jest troszkę tak jak z pieniędzmi i ludźmi: samo posiadanie pieniędzy z nikogo jeszcze nie uczyniło wielkiego człowieka co nie zmiania faktu że wielu stale i za wszelką cenę próbuje tylko mieć dużo pieniędzy. Posiadanie dużej ilości danych (w hurtowni) nie czyni z nich ani wiedzy ani narzędzia wspomagającego podejmowanie decyzji.
(więcej…)
Każdy model procesów nie spełniający powyższych zasad można nazwać właśnie naiwnym modelem czyli takim, w którym dowolne symbole, bez zdefiniowanych zasad zostały połączone ze sobą tak jak usłyszano np. w rozmowie z pracownikiem analizowanej organizacji. Modele takie są bardzo często narzędziem do planowania zmian organizacyjnych, specyfikowania wymagań na systemy IT, specyfikowania centrów kosztów w metodach ABC zarządzania kosztami, w wielu innych sytuacjach. Użycie w którejkolwiek z tych potrzeb złego, naiwnego modelu skazuje cały projekt na niepowodzenie.Tak więc model procesów bez zdefiniowanej i rygorystycznie przestrzeganej semantyki (słownika symboli), syntaktyki (zasad dopuszczalnych relacji pomiędzy tymi symbolami), pragmatyki (co modelujemy i jak) należy odrzucić!
Automatyzacja procesów biznesowych to nawet nie jest zarządzanie zorientowane na procesy, to zaprzeczenie idei procesowego zarządzania, gdzie nadrzędnym celem jest ustanowienie jakości produktu procesu jako jego jedynego miernika, zaś właściciela procesu jako jedynej osoby odpowiedzialnej za tę jakość. Model (mapa) procesów to nie algorytm (co niektórzy usiłują forsować) ale scenariusze powstawania wartości dodanej z odzwierciedleniem odpowiedzialności za te wartości, wskazaniem jej twórców czyli wykonawców czynności w procesach. Czym więc jest ta ?mapa procesu biznesowego?? Jest to model tworzenia wartości przez organizacje a nie algorytm pracy ? algorytm zastępuje mózg, ma to sens w komputerze bo ten nie ma mózgu i tylko tam?
Kolejna ślepa uliczka jaką dostrzegam w reklamach systemów klasy workflow to wskazywanie jako głównej korzyści ich wdrożenia narzucenie ścisłej kontroli poczynaniom pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników wbrew ich woli. Typowym przykładem są różnego typu restrykcyjne systemy kontroli czasu pracy czy kontroli pracy przy komputerze, nadzór urzędnika tą metodą także się nie sprawdza. Lepszy jest moim zdaniem system informatyczny zaprojektowany tak by pomagał pracownikom osiągać ich cele. On niejako wdraża się sam. Systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez ludzi.
Korzyścią jest to, że po wdrożeniu ofertę można przygotować w jeden dzień a nie w tydzień, że prezes dane do negocjacji może pozyskać w minuty a nie tygodnie itd. System może się zwrócić nawet w jedną godzinę. Jak? Wystarczy, że na bazie natychmiast dostępnych z systemu informacji złożona zostanie oferta lub podjęta zostanie szybka decyzja, przed konkurentem i dzięki temu zyskamy kontrakt o zysku porównywalnym z kosztem nabycia systemu IT.
