W jednym z poprzednich artykułów napisałem: System CRM to narzędzie wspierające budowanie wartości dodanej, jeśli tego nie robi stanowi raczej zbędny koszt (źr. Jak należy wybierać system CRM, by zwiększyć zyski w firmie?). Jeden z czytelników słusznie zaś napisał:

Czy chciałeś napisać, że CRM to budowane świadomości poprzez kanalizację procesów sprzedaży czy obsługi wg najlepszych praktyk ? […] procesy sprzedaży, jak widzę u siebie zabijają to co leży u jej podstaw, czyli kreatywność, spryt i inwencję.  A może CRM 2.0 , czyli mądrość ludowa ? Tylko jak mądrość wyodrębnić?  A może nie procesy, tylko BPM , czyli dowolnie jak, byle do celu ? Słucham, co się mówi u mnie w firmie o CRM i nic się nie wyłania. Chyba zostaniemy na kontakt managerze, z kilkoma atrybutami do zestawień ?.

Ale po kolei, zastanówmy się w czym problem.

Proces ale jaki?

Weźmy na tapetę dział sprzedaży (bo miało być o [[CRM]]). Obsługuje np. trzy typowe zdarzenia:

1. pojawiło się zapytanie ofertowe,
2. pojawiło się zamówienie,
3. pojawiła się reklamacja.

Może to wyglądać np. tak (tak zwany [[model kontekstowy]]):

[singlepic id=124 w=550 h=550 float=center]

Nie jest to jeden proces sprzedaży a trzy odrębne! Powyższy diagram powstał z zastosowaniem kilku wzorców i tak zwanych dobrych praktyk modelowania procesów (dobry model powinien mieć określoną [[pragmatykę]]): tylko zdarzenia inicjują procesy ([[Event Driven Analysis]]), proces zawsze odpowiada produktem ([[Product Oriented Design]]), procesy komunikują się poprzez współdzielenie danych lub przechwytywanie publikowanych zdarzeń ([[publish/subscribe process pattern]]). Takie podejście ułatwia i formalizuje identyfikowanie procesów, pozwala uniknąć tworzenia złożonych modeli i prowadzi do lepszego zrozumienia tego co się dzieje. W modelowaniu nie chodzi bowiem o to by jak najwięcej narysować, a o to by wszystko zrozumieć.

Przykładowy model jednego z procesów, obsługi zapytań ofertowych czyli tworzenia ofert, obrazuje poniższy diagram:

[singlepic id=125 w=550 h=550 float=center]

Jak widać nie jest to skomplikowany diagram jednak pokazuje sedno sprawy. Ktoś może zarzucić temu modelowi, że ukrywa istotne szczegóły. Bingo! Tak ma być, te szczegóły są gdzie indziej bo proces to tylko, i aż zarazem, łańcuch wydarzeń, jak ktoś woli (np. ja) łańcuch wartości w tworzeniu produktu. A gdzie się podziały istotne szczegóły?

Zanim rzucimy się na problem stwórzmy model tego o czym tu piszemy:

Diagram obrazuje w pewnym uproszczeniu to z czym każdy z nas ma do czynienia w firmie (dowolnej organizacji): ktoś jest odpowiedzialny za efekt jakiejś pracy, którą należy wykonać. I było by to proste gdyby nie to, że firma chce panować nad tym co robi czyli efekty są góry ustalone, no może oczekiwane (planowane).

Tak więc kluczowa para pojęć to Efekt pracy i Odpowiedzialny co razem tworzy Proces. Zwracam uwagę, że w wielu firmach istnieją, nie raz nawet formalnie, tylko te dwa obiekty: kto i za co odpowiada. Zwracam także od razu uwagę, że Odpowiedzialność nie oznacza bycia wykonawcą. Klasycznym przykładem jest np. Dyrektor Handlowy, który odpowiada za efekty pracy swoich handlowców ale nie on fizycznie (nie zawsze) jest autorem ofert.

Powyższy diagram pokazuje, że poza procesami i osobami odpowiedzialnymi za nie, ale w powiązaniu z nimi, istnieją:

1. kompetencje pracowników,
2. procedury,
3. reguły biznesowe,
4. dokumenty (zdarzenia) inicjujące procesy i będące ich produktami,

Diabeł tkwi w szczegółach i są to święte słowa :). Ale model procesów nie jest miejscem na umieszczanie tych szczegółów! Powyższe szczegóły są zawarte w: strukturze organizacyjnej, dokumentach opisujących zakresy obowiązków, procedurach, tym co każdy ma w swoim CV i tym co mu powierzono.

Analiza firm (organizacji) nie polega na narysowaniu setek diagramów opisujących wszystko co wiemy. One i tak do niczego nie są w stanie się przydać! Ich złożoność często powoduje, że stanowią swego rodzaju bełkot łączący to co ludzie robią, jak, po co, dlaczego itp. Stanowią pomieszanie wszystkiego ze wszystkim. Nie dziwię się, że są potem ignorowane, bo nikt poza ich autorem nie jest w stanie nic z nich wyczytać (a nie raz i autor po pewnym czasie także).

Analiza firmy to rozłożenie jej na czynniki pierwsze. Nie po to by było ich dużo, a po to by zrozumieć wpływ i rolę każdego z nich. Teraz diagram dla twardzieli:

[singlepic id=126 w=550 h=550 float=center]

To przykład tak zwanej taksonomii (jako narzędzie wykorzystano [[diagram klas]] notacji [[UML]]). Pomijając znaczenie linii łączących poszczególne pojęcia, można (i należy)  to potraktować jak słownik pojęć. Wszystko co wiemy o firmie, lub odkryjemy w trakcie analizy, należy jednoznacznie zakwalifikować: czy jest to proces, czy jest to procedura, czy jest to może reguła biznesowa, i tak dalej. Model procesów (wcześniejsze diagramy) obrazuje wyłącznie [[wewnętrzny łańcuch wartości]]. Jako, że jest także listą czynności, może posłużyć np. do identyfikacji wymagań funkcjonalnych na oprogramowanie. Na modelu procesów można jednak umieścić informacje o tym, że do wykonania jakiejś czynności wymagane jest poza danymi wejściowymi także dokumenty opisujące procedurę.

Na zakończenie

Tak więc odpowiadając na tytułowe pytanie czytelnika: nie wiem co to jest CRM ale mogę powiedzieć, że zarządzanie to określenie czego i od kogo oczekujemy, określenie swobód i ograniczeń każdemu pracującemu, określenie miar, których użyjemy do oceny spełnienia tych oczekiwań. Zarządzanie to ciągły proces, w którym menedżerowie, ustalając te swobody i ograniczenia kształtują środowisko pracy w organizacji tak, by możliwie najefektywniej spełniała  ona swój cel: tworzyła wartościowy produkt dla klienta.

Wspomniany przez czytelnika na początku kontakt menedżer to nic innego, jak współdzielone dane o kontrahentach i dokumentach z nimi powiązanych. To dlatego bardzo często, repozytorium dokumentów z metadanymi (w tym także powiązania dokument – kontrahent) wystarczą. Jeżeli chcemy dodatkowo usprawnić pracę z pomocą takiego repozytorium, powinno ono mieć funkcjonalność generowania zdarzeń powiązanych z dokumentami i monitowanie ich: fakt ich pojawienia się oraz zdefiniowanych, powiązanych terminów. Każde takie zdarzenie ma (może mieć)  swoich subskrybentów. Skoro dane są przechowywane, system raportowy poda nam każdą pożądaną statystykę, na ich zaś podstawie  można wyciągać wnioski co do wprowadzenia ewentualnych zmian w ograniczeniach. I pętla zarządzania się zamyka!

Złożoność większości organizacji, powoduje, że bez pełnego zrozumienia niuansów jej działania, zarządzanie staje się serią przypadkowych decyzji i ich efektów. Reagowanie na nie często przypomina pokonywanie przez szczura labiryntu:  uczy się on, ale jest to nauka bez zrozumienia, bazuje tylko na określania tego co i jakie efekty przynosi jednak bez wiedzy dlaczego akurat takie a nie inne. Niestety większe labirynty powodują, że wiele szczurów ginie z głodu nie osiągając celu. Inne żyją w sposób przypadkowy i nigdy nie wiedzą dlaczego jeszcze żyją, kiedy i dlaczego umrą.

Gdzie tu procesy?

Proces to skutek a nie przyczyna… wystarczy go tylko zrozumieć i udokumentować. To tak jak z rzeką: to którędy płynie woda to efekt ukształtowania terenu a nie decyzji. Woda nigdy nie popłynie pod górkę… Analiza biznesowa to sposób na udokumentowanie i zrozumienie tego. Tak więc po protu przeprowadź analizę biznesową, powiedz co chcesz osiągnąć, sprawdź czy to możliwe, jeśli tak to wprowadź w życie ale nie szukaj żadnego akronimu by nazwać to co robisz. Używanie takich skrótów jak CRM, ERP, SCM i innych to nowomowa, która – poza dostawcami produktów z tymi skrótami w nazwach – nikomu w niczym nie pomogła.

A gdzie te śmieszne “przypływy dokumentów”? One są albo skutkiem ograniczeń, albo wymuszone przez procedurę albo efektem reguł biznesowych i kompetencji. Bez analizy tych zjawisk nie da się jednoznacznie opisać tak zwanych “przepływów dokumentów” bo tylko mała cześć z nich to efekt sztywnej procedury, którą faktycznie czasami można opisać diagramem.

Wymagania na oprogramowanie

Kolejne zakończenie. Czym są [[wymagania na oprogramowanie]]? Mając powyższe dane można:

1. wskazać, które czynności mają być wspomagane przez oprogramowanie i zapisać je jako przypadki użycia (wymagania funkcjonalne),
2. wskazać, które dokumenty (ich wzory) niosą dane istotne dla nowego systemu i zdefiniować ich taksonomię, na jej podstawie zaprojektować model dziedziny systemu,
3. zebrać reguły biznesowe, wybrać te które chcemy uczynić ograniczeniami w systemie i dokładnie je udokumentować.

I radzę od tego zacząć o potem dopiero szukać dostawcy. Jeśli powierzmy tę pracę (analizę) od razu dostawy jakiegokolwiek rozwiązania to rekomendacje z takiej analizy będą wskazywały na potrzebę zakupu… no czego?