W jed­nym z poprzed­nich arty­ku­łów napi­sa­łem: System CRM to narzę­dzie wspie­ra­ją­ce budo­wa­nie war­to­ści doda­nej, jeśli tego nie robi sta­no­wi raczej zbęd­ny koszt (źr. Jak nale­ży wybie­rać sys­tem CRM, by zwięk­szyć zyski w fir­mie?). Jeden z czy­tel­ni­ków słusz­nie zaś napisał:

Czy chcia­łeś napi­sać, że CRM to budo­wa­ne świa­do­mo­ści poprzez kana­li­za­cję pro­ce­sów sprze­da­ży czy obsłu­gi wg naj­lep­szych prak­tyk ? […] pro­ce­sy sprze­da­ży, jak widzę u sie­bie zabi­ja­ją to co leży u jej pod­staw, czy­li kre­atyw­ność, spryt i inwen­cję. A może CRM 2.0 , czy­li mądrość ludo­wa ? Tylko jak mądrość wyod­ręb­nić? A może nie pro­ce­sy, tyl­ko BPM , czy­li dowol­nie jak, byle do celu ? Słucham, co się mówi u mnie w fir­mie o CRM i nic się nie wyła­nia. Chyba zosta­nie­my na kon­takt mana­ge­rze, z kil­ko­ma atry­bu­ta­mi do zestawień ?.

Ale po kolei, zasta­nów­my się w czym problem.

Proces ale jaki?

Weźmy na tape­tę dział sprze­da­ży (bo mia­ło być o [[CRM]]). Obsługuje np. trzy typo­we zdarzenia:

1. poja­wi­ło się zapy­ta­nie ofertowe,
2. poja­wi­ło się zamówienie,
3. poja­wi­ła się reklamacja.

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

[sin­gle­pic id=124 w=550 h=550 float=center]

Nie jest to jeden pro­ces sprze­da­ży a trzy odręb­ne! Powyższy dia­gram powstał z zasto­so­wa­niem kil­ku wzor­ców i tak zwa­nych dobrych prak­tyk mode­lo­wa­nia pro­ce­sów (dobry model powi­nien mieć okre­ślo­ną [[prag­ma­ty­kę]]): tyl­ko zda­rze­nia ini­cju­ją pro­ce­sy ([[Event Driven Analysis]]), pro­ces zawsze odpo­wia­da pro­duk­tem ([[Product Oriented Design]]), pro­ce­sy komu­ni­ku­ją się poprzez współ­dzie­le­nie danych lub prze­chwy­ty­wa­nie publi­ko­wa­nych zda­rzeń ([[publish/subscribe pro­cess pat­tern]]). Takie podej­ście uła­twia i for­ma­li­zu­je iden­ty­fi­ko­wa­nie pro­ce­sów, pozwa­la unik­nąć two­rze­nia zło­żo­nych mode­li i pro­wa­dzi do lep­sze­go zro­zu­mie­nia tego co się dzie­je. W mode­lo­wa­niu nie cho­dzi bowiem o to by jak naj­wię­cej nary­so­wać, a o to by wszyst­ko zrozumieć.

Przykładowy model jed­ne­go z pro­ce­sów, obsłu­gi zapy­tań ofer­to­wych czy­li two­rze­nia ofert, obra­zu­je poniż­szy diagram:

[sin­gle­pic id=125 w=550 h=550 float=center]

Jak widać nie jest to skom­pli­ko­wa­ny dia­gram jed­nak poka­zu­je sed­no spra­wy. Ktoś może zarzu­cić temu mode­lo­wi, że ukry­wa istot­ne szcze­gó­ły. Bingo! Tak ma być, te szcze­gó­ły są gdzie indziej bo pro­ces to tyl­ko, i aż zara­zem, łań­cuch wyda­rzeń, jak ktoś woli (np. ja) łań­cuch war­to­ści w two­rze­niu pro­duk­tu. A gdzie się podzia­ły istot­ne szcze­gó­ły?

Zanim rzu­ci­my się na pro­blem stwórz­my model tego o czym tu piszemy:

Diagram obra­zu­je w pew­nym uprosz­cze­niu to z czym każ­dy z nas ma do czy­nie­nia w fir­mie (dowol­nej orga­ni­za­cji): ktoś jest odpo­wie­dzial­ny za efekt jakiejś pra­cy, któ­rą nale­ży wyko­nać. I było by to pro­ste gdy­by nie to, że fir­ma chce pano­wać nad tym co robi czy­li efek­ty są góry usta­lo­ne, no może ocze­ki­wa­ne (pla­no­wa­ne).

Tak więc klu­czo­wa para pojęć to Efekt pra­cy i Odpowiedzialny co razem two­rzy Proces. Zwracam uwa­gę, że w wie­lu fir­mach ist­nie­ją, nie raz nawet for­mal­nie, tyl­ko te dwa obiek­ty: kto i za co odpo­wia­da. Zwracam tak­że od razu uwa­gę, że Odpowiedzialność nie ozna­cza bycia wyko­naw­cą. Klasycznym przy­kła­dem jest np. Dyrektor Handlowy, któ­ry odpo­wia­da za efek­ty pra­cy swo­ich han­dlow­ców ale nie on fizycz­nie (nie zawsze) jest auto­rem ofert.

Powyższy dia­gram poka­zu­je, że poza pro­ce­sa­mi i oso­ba­mi odpo­wie­dzial­ny­mi za nie, ale w powią­za­niu z nimi, istnieją:

1. kom­pe­ten­cje pracowników,
2. pro­ce­du­ry,
3. regu­ły biznesowe,
4. doku­men­ty (zda­rze­nia) ini­cju­ją­ce pro­ce­sy i będą­ce ich produktami,

Diabeł tkwi w szcze­gó­łach i są to świę­te sło­wa :). Ale model pro­ce­sów nie jest miej­scem na umiesz­cza­nie tych szcze­gó­łów! Powyższe szcze­gó­ły są zawar­te w: struk­tu­rze orga­ni­za­cyj­nej, doku­men­tach opi­su­ją­cych zakre­sy obo­wiąz­ków, pro­ce­du­rach, tym co każ­dy ma w swo­im CV i tym co mu powierzono.

Analiza firm (orga­ni­za­cji) nie pole­ga na nary­so­wa­niu setek dia­gra­mów opi­su­ją­cych wszyst­ko co wie­my. One i tak do nicze­go nie są w sta­nie się przy­dać! Ich zło­żo­ność czę­sto powo­du­je, że sta­no­wią swe­go rodza­ju beł­kot łączą­cy to co ludzie robią, jak, po co, dla­cze­go itp. Stanowią pomie­sza­nie wszyst­kie­go ze wszyst­kim. Nie dzi­wię się, że są potem igno­ro­wa­ne, bo nikt poza ich auto­rem nie jest w sta­nie nic z nich wyczy­tać (a nie raz i autor po pew­nym cza­sie także).

Analiza fir­my to roz­ło­że­nie jej na czyn­ni­ki pierw­sze. Nie po to by było ich dużo, a po to by zro­zu­mieć wpływ i rolę każ­de­go z nich. Teraz dia­gram dla twardzieli:

[sin­gle­pic id=126 w=550 h=550 float=center]

To przy­kład tak zwa­nej tak­so­no­mii (jako narzę­dzie wyko­rzy­sta­no [[dia­gram klas]] nota­cji [[UML]]). Pomijając zna­cze­nie linii łączą­cych poszcze­gól­ne poję­cia, moż­na (i nale­ży) to potrak­to­wać jak słow­nik pojęć. Wszystko co wie­my o fir­mie, lub odkry­je­my w trak­cie ana­li­zy, nale­ży jed­no­znacz­nie zakwa­li­fi­ko­wać: czy jest to pro­ces, czy jest to pro­ce­du­ra, czy jest to może regu­ła biz­ne­so­wa, i tak dalej. Model pro­ce­sów (wcze­śniej­sze dia­gra­my) obra­zu­je wyłącz­nie [[wewnętrz­ny łań­cuch war­to­ści]]. Jako, że jest tak­że listą czyn­no­ści, może posłu­żyć np. do iden­ty­fi­ka­cji wyma­gań funk­cjo­nal­nych na opro­gra­mo­wa­nie. Na mode­lu pro­ce­sów moż­na jed­nak umie­ścić infor­ma­cje o tym, że do wyko­na­nia jakiejś czyn­no­ści wyma­ga­ne jest poza dany­mi wej­ścio­wy­mi tak­że doku­men­ty opi­su­ją­ce procedurę.

Na zakończenie

Tak więc odpo­wia­da­jąc na tytu­ło­we pyta­nie czy­tel­ni­ka: nie wiem co to jest CRM ale mogę powie­dzieć, że zarzą­dza­nie to okre­śle­nie cze­go i od kogo ocze­ku­je­my, okre­śle­nie swo­bód i ogra­ni­czeń każ­de­mu pra­cu­ją­ce­mu, okre­śle­nie miar, któ­rych uży­je­my do oce­ny speł­nie­nia tych ocze­ki­wań. Zarządzanie to cią­gły pro­ces, w któ­rym mene­dże­ro­wie, usta­la­jąc te swo­bo­dy i ogra­ni­cze­nia kształ­tu­ją śro­do­wi­sko pra­cy w orga­ni­za­cji tak, by moż­li­wie naj­efek­tyw­niej speł­nia­ła ona swój cel: two­rzy­ła war­to­ścio­wy pro­dukt dla klienta.

Wspomniany przez czy­tel­ni­ka na począt­ku kon­takt mene­dżer to nic inne­go, jak współ­dzie­lo­ne dane o kon­tra­hen­tach i doku­men­tach z nimi powią­za­nych. To dla­te­go bar­dzo czę­sto, repo­zy­to­rium doku­men­tów z meta­da­ny­mi (w tym tak­że powią­za­nia doku­ment – kon­tra­hent) wystar­czą. Jeżeli chce­my dodat­ko­wo uspraw­nić pra­cę z pomo­cą takie­go repo­zy­to­rium, powin­no ono mieć funk­cjo­nal­ność gene­ro­wa­nia zda­rzeń powią­za­nych z doku­men­ta­mi i moni­to­wa­nie ich: fakt ich poja­wie­nia się oraz zde­fi­nio­wa­nych, powią­za­nych ter­mi­nów. Każde takie zda­rze­nie ma (może mieć) swo­ich sub­skry­ben­tów. Skoro dane są prze­cho­wy­wa­ne, sys­tem rapor­to­wy poda nam każ­dą pożą­da­ną sta­ty­sty­kę, na ich zaś pod­sta­wie moż­na wycią­gać wnio­ski co do wpro­wa­dze­nia ewen­tu­al­nych zmian w ogra­ni­cze­niach. I pętla zarzą­dza­nia się zamyka!

Złożoność więk­szo­ści orga­ni­za­cji, powo­du­je, że bez peł­ne­go zro­zu­mie­nia niu­an­sów jej dzia­ła­nia, zarzą­dza­nie sta­je się serią przy­pad­ko­wych decy­zji i ich efek­tów. Reagowanie na nie czę­sto przy­po­mi­na poko­ny­wa­nie przez szczu­ra labi­ryn­tu: uczy się on, ale jest to nauka bez zro­zu­mie­nia, bazu­je tyl­ko na okre­śla­nia tego co i jakie efek­ty przy­no­si jed­nak bez wie­dzy dla­cze­go aku­rat takie a nie inne. Niestety więk­sze labi­ryn­ty powo­du­ją, że wie­le szczu­rów ginie z gło­du nie osią­ga­jąc celu. Inne żyją w spo­sób przy­pad­ko­wy i nigdy nie wie­dzą dla­cze­go jesz­cze żyją, kie­dy i dla­cze­go umrą.

Gdzie tu procesy?

Proces to sku­tek a nie przy­czy­na… wystar­czy go tyl­ko zro­zu­mieć i udo­ku­men­to­wać. To tak jak z rze­ką: to któ­rę­dy pły­nie woda to efekt ukształ­to­wa­nia tere­nu a nie decy­zji. Woda nigdy nie popły­nie pod gór­kę… Analiza biz­ne­so­wa to spo­sób na udo­ku­men­to­wa­nie i zro­zu­mie­nie tego. Tak więc po pro­tu prze­pro­wadź ana­li­zę biz­ne­so­wą, powiedz co chcesz osią­gnąć, sprawdź czy to moż­li­we, jeśli tak to wpro­wadź w życie ale nie szu­kaj żad­ne­go akro­ni­mu by nazwać to co robisz. Używanie takich skró­tów jak CRM, ERP, SCM i innych to nowo­mo­wa, któ­ra – poza dostaw­ca­mi pro­duk­tów z tymi skró­ta­mi w nazwach – niko­mu w niczym nie pomogła.

A gdzie te śmiesz­ne ​„przy­pły­wy doku­men­tów”? One są albo skut­kiem ogra­ni­czeń, albo wymu­szo­ne przez pro­ce­du­rę albo efek­tem reguł biz­ne­so­wych i kom­pe­ten­cji. Bez ana­li­zy tych zja­wisk nie da się jed­no­znacz­nie opi­sać tak zwa­nych ​„prze­pły­wów doku­men­tów” bo tyl­ko mała cześć z nich to efekt sztyw­nej pro­ce­du­ry, któ­rą fak­tycz­nie cza­sa­mi moż­na opi­sać diagramem.

Wymagania na oprogramowanie

Kolejne zakoń­cze­nie. Czym są [[wyma­ga­nia na opro­gra­mo­wa­nie]]? Mając powyż­sze dane można:

1. wska­zać, któ­re czyn­no­ści mają być wspo­ma­ga­ne przez opro­gra­mo­wa­nie i zapi­sać je jako przy­pad­ki uży­cia (wyma­ga­nia funkcjonalne),
2. wska­zać, któ­re doku­men­ty (ich wzo­ry) nio­są dane istot­ne dla nowe­go sys­te­mu i zde­fi­nio­wać ich tak­so­no­mię, na jej pod­sta­wie zapro­jek­to­wać model dzie­dzi­ny systemu,
3. zebrać regu­ły biz­ne­so­we, wybrać te któ­re chce­my uczy­nić ogra­ni­cze­nia­mi w sys­te­mie i dokład­nie je udokumentować.

I radzę od tego zacząć o potem dopie­ro szu­kać dostaw­cy. Jeśli powierz­my tę pra­cę (ana­li­zę) od razu dosta­wy jakie­go­kol­wiek roz­wią­za­nia to reko­men­da­cje z takiej ana­li­zy będą wska­zy­wa­ły na potrze­bę zaku­pu… no czego?