Łańcuch wartości M.E.Porter

Wymagania na system ERP – co ma do tego M.E.Porter i rok 1985?

W poprzed­nim arty­ku­le napisałem:

Ogólnie opi­nia, zale­ca­ne podej­ście przez Fowlera to: jeże­li pro­ces wyma­ga­ją­cy wspar­cia nowym opro­gra­mo­wa­niem, to pro­ces klu­czo­wy dla utrzy­ma­nia kon­ku­ren­cyj­no­ści lepiej stwo­rzyć opro­gra­mo­wa­nie dedy­ko­wa­ne do tego pro­ce­su. Jeżeli to jeden z pro­ce­sów pomoc­ni­czych, efek­tyw­niej będzie kupić goto­we opro­gra­mo­wa­nie i dosto­so­wa­nie do nie­go pro­ce­su w fir­mie. Co cie­ka­we, podob­nie jak ja, zale­ca w przy­pad­ku goto­we­go opro­gra­mo­wa­nia dosto­so­wa­nie się do nie­go a nie dosto­so­wy­wa­nie opro­gra­mo­wa­nia do sie­bie. (czy­taj Dostosowanie opro­gra­mo­wa­nia: kie­dy?).

Dużo się mówi, i słusz­nie, o tym że ana­li­zę wyma­gań powin­na poprze­dzić rze­tel­na ana­li­za biz­ne­so­wa. Nie jest to jed­nak to, co robią w więk­szo­ści ana­li­ty­cy biz­ne­so­wi” dostaw­ców opro­gra­mo­wa­nia ERP. Ci przy­go­to­wu­ją swo­je fir­my i swo­ich klien­tów, do wdro­że­nia sprze­da­ne­go już oprogramowania.

Tym razem pociągnę” temat co dopasowywać i do czego”.

Jak już wspo­mnia­no potrzeb­na jest nam wie­dza o tym, któ­re pro­ce­sy są w naszej fir­mie pro­ce­sa­mi klu­czo­wy­mi, a któ­re pomoc­ni­czy­mi. Nie ma na to jed­no­znacz­nej odpo­wie­dzi. Jest teza, posta­wio­na przez [[Michaela E. Portera]] mówią­ca, że fir­ma powin­na mieć jed­ną spe­cja­li­za­cję, jeden klu­czo­wy czyn­nik budo­wy prze­wa­gi ryn­ko­wej nad kon­ku­ren­cją. Nie moż­na sku­tecz­nie kon­ku­ro­wać we wszyst­kim i ze wszyst­ki­mi”. Pewnej wska­zów­ki dostar­cza M.E.Porter w swo­im (obec­nie wręcz epo­ko­wym) dzie­le: Competitive Advantage” wyda­nym w 1985 roku (pol­skie wyda­nie: [[Strategie Konkurencji, Michael E. Porter, MT Biznes, Warszawa 2006]]).

Jednym z naj­słyn­niej­szych dia­gra­mów z tej książ­ki jest ten:

Łańcuch wartości M.E.Porter (Competitive Advantage, 1985)

Celowo przy­ta­czam wer­sją ory­gi­nal­ną, gdyż w bar­dzo wie­lu książ­kach i stro­nach WWW, model ten jest kale­czo­ny”: po pierw­sze błęd­nie nazy­wa­ny meto­dą”, po dru­gie inbo­und logi­stics” jest błęd­nie tłu­ma­czo­ne na logi­sty­ka wewnętrz­na” zamiast logi­sty­ka zaopa­trze­nia (pro­duk­cji, przyp. mój)”. Kolejnym, pomi­ja­nym czę­sto ele­men­tem tego dia­gra­mu, jest mar­gin” czy­li mar­ża (tu jako mone­tar­nie wyra­żo­na war­tość doda­na) jaką two­rzą te pro­ce­sy, a war­tość tę two­rzą wszyst­kie pro­ce­sy, nie tyl­ko te głów­ne. Wystarczy jed­nak prze­czy­tać treść książ­ki, by nie mieć tych wątpliwości.

Jak to się ma do wymagań?

Przytoczmy jesz­cze raz, dla przy­po­mnie­nia, wspo­mnia­ny na począt­ku cytat:

…jeże­li pro­ces wyma­ga­ją­cy wspar­cia nowym opro­gra­mo­wa­niem, to pro­ces klu­czo­wy dla utrzy­ma­nia kon­ku­ren­cyj­no­ści lepiej stwo­rzyć opro­gra­mo­wa­nie dedy­ko­wa­ne do tego pro­ce­su. Jeżeli to jeden z pro­ce­sów pomoc­ni­czych, efek­tyw­niej będzie kupić goto­we opro­gra­mo­wa­nie i dosto­so­wa­nie do nie­go pro­ce­su w firmie…

Powyższy model, już po prze­tłu­ma­cze­niu i drob­nej korekcie:

Procesy (kon­kret­ne aktyw­no­ści) Porter dzie­li na dwa ich obszary:

  1. wspie­ra­ją­ce
  2. klu­czo­we (głów­ne)

Podział ten ma swo­je źró­dło w tym, gdzie powsta­je (poten­cjal­nie może powstać) naj­więk­sza war­tość doda­na (źró­dło zysku). Porter uwa­ża, że obsza­ry, w któ­rych fir­my powin­ny budo­wać swo­ją prze­wa­gę to te, któ­re doty­czą bez­po­śred­nio ofe­ro­wa­nych usług i pro­duk­tów. Pozostałe jed­nak nie mogą być pomi­ja­ne gdyż, jak widać na dia­gra­mie, mar­że budu­ją wszyst­kie pro­ce­sy. Firma jed­nak może być np. mistrzem logi­sty­ki w swo­jej bran­ży (ma naj­lep­szy sys­tem zaopa­trze­nia w surow­ce, albo naj­spraw­niej dostar­cza pro­duk­ty do klien­tów) czy mistrzem sku­tecz­no­ści docie­ra­nia z ofer­tą do klien­tów (mar­ke­ting i sprze­daż) ale trud­no budo­wać prze­wa­gę np. Kopalni, i być mistrzem wła­snej księ­go­wo­ści wewnętrz­nej czy zaopa­trze­nia w segre­ga­to­ry wła­snych pra­cow­ni­ków (Zaopatrzenie).

Tak więc (w pew­nym uprosz­cze­niu) moż­na w ciem­no” wybrać na ryn­ku goto­wy pro­dukt i wdro­żyć go, nawet poświę­ca­jąc pew­ne wła­sne zwy­cza­je w obsza­rze zarzą­dza­nia per­so­ne­lem, wewnętrz­ną admi­ni­stra­cją, rachun­ko­wo­ścią, roz­wo­jem tech­no­lo­gii. Tu war­to zwró­cić uwa­gę na to, że uży­wa­ne maszy­ny – poza posia­da­ny­mi paten­ta­mi – może mieć każ­dy nasz kon­ku­rent, dla­te­go budo­wa trwa­łej prze­wa­gi na środ­kach pro­duk­cji jest raczej wąt­pli­wa strategią.

Tak więc ana­li­zu­jąc fir­mę i okre­śla­jąc wyma­ga­nia na sys­tem ERP war­to roz­wa­żyć podej­ście, w któ­rym w obsza­rze pro­ce­sów wspo­ma­ga­ją­cych wdro­żo­ne zosta­nie goto­we opro­gra­mo­wa­nie bez żad­nych kasto­mi­za­cji (czy­li szyb­ko i rela­tyw­nie tanio), a w któ­rym war­to zapro­jek­to­wać coś spe­cjal­nie dla sie­bie. Analiza biz­ne­so­wa i wewnętrz­ny model war­to­ści wska­że nam obszar, któ­ry nale­ży zin­for­ma­ty­zo­wać dokład­nie tak jak obec­nie pra­cu­je, bez żad­nych kom­pro­mi­sów, bez nagi­na­nia się do dostar­czo­ne­go ERP. Jak to zro­bić? Stworzyć popraw­ny model całej fir­my, wska­zać na nim klu­czo­we źró­dło zysku i prze­wa­gi ryn­ko­wej, i dla tego obsza­ru dzia­łal­no­ści stwo­rzyć dedy­ko­wa­ne roz­wią­za­nie (prze­czy­taj arty­kuł o ana­li­zie gap/fit).

Podejście takie jest sto­so­wa­ne. Badania poka­zu­ją, że lide­rzy ryn­ku, bez wzglę­du na bran­żę, to fir­my dobrze zarzą­dza­ne a nie te, któ­re naj­wię­cej wyda­ły na IT. Podejście to wyma­ga dużej odwa­gi i samo­dziel­no­ści, igno­ro­wa­nia tak zwa­nych mode­li refe­ren­cyj­nych (bo te są dobry­mi prak­ty­ka­mi a nie czymś co nale­ży sko­pio­wać), owo­cu­je jed­nak suk­ce­sa­mi. Niestety czę­sto zda­rza się, że wdro­że­nie sys­te­mu ERP nisz­czy prze­wa­gę fir­my, gdyż nowa tech­no­lo­gia zamiast ją umoc­nić nisz­czy kom­pro­mi­sa­mi i kopio­wa­niem mode­li innych firm (nie raz kon­ku­ren­tów) wszyst­ko to co odróż­nia­ło ją od innych.

Za zakoń­cze­nie pole­cam gorą­co dru­gą ksiąz­kę Portera: [[Porter o kon­ku­ren­cji, Michael E. Porter, PWE, Warszawa 2001]]. W tej znaj­dzie­my zbiór dzie­wię­ciu arty­ku­łów na temat budo­wa­nia kon­ku­ren­cji i jej utrzy­ma­niu. W szcze­gól­no­ści war­to poznać arty­kuł „[[W jaki spo­sób infor­ma­cja wpły­wa na prze­wa­gę kon­ku­ren­cyj­ną]]”. Pięć zasad, któ­re mogą pomóc w budo­wa­niu prze­wa­gi na bazie infor­ma­cji, odsy­łam do książ­ki , war­to. To przy­czy­nek to napi­sa­nia kil­ku słów o sys­te­mach wspo­ma­ga­nia decy­zji ale to inny temat, nie ERP…

Na zakończenie

Wdrożenie sys­te­mu wspo­ma­ga­ją­ce­go zarzą­dza­nie powin­no być poprze­dzo­ne wni­kli­wą ana­li­zą, pozwa­la­ją­cą zro­zu­mieć zna­cze­nie i wpływ na wyni­ki fir­my, każ­de­go jej obsza­ru dzia­ła­nia. Wybór sys­te­mu ERP powi­nien być świa­do­my: celu każ­de­go jego ele­men­tu i skut­ków jego zasto­so­wa­nia. Wdrażanie przy­pad­ko­wo (na bazie ogól­nych ocze­ki­wań) wybra­ne­go sys­te­mu ERP daje tak­że przy­pad­ko­we efek­ty, zaś póź­niej­sze kosz­tow­ne dosto­so­wy­wa­nie go do wła­snych potrzeb, z regu­ły nisz­czy poten­cjal­ne finan­so­we korzy­ści z jego wdrożenia. 

CRM – jaką pełni rolę

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:

Kontekst BPM

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?

Za system IT odpowiada Prezes a nie informatyk

Osobą odpo­wie­dzial­ną za sys­tem IT zawsze będzie zama­wia­ją­cy. Dlatego zama­wia­ją­cy powi­nien jed­no­znacz­nie opi­sać swo­je ocze­ki­wa­nia i zro­zu­mieć potem odpo­wiedź czy­li pro­po­zy­cję ich wyko­naw­cy. Menedżer nie musi uczyć się dia­gra­mów UML ale powi­nien rozu­mieć mode­le pro­ce­sów tak by mieć moż­li­wość ich oce­ny i zatwier­dza­nia. Dlatego mode­le pro­ce­sów powin­ny być two­rzo­ne meto­da­mi zro­zu­mia­ły­mi dla mene­dże­rów, moim zda­niem nie jest to nota­cja UML. Notacja ta jed­nak jest nie­wąt­pli­wie dosko­na­łym narzę­dziem do udo­ku­men­to­wa­nia i prze­ka­za­nia swo­ich ocze­ki­wań przy­szłe­mu wyko­naw­cy sys­te­mu: inte­gra­to­ro­wi IT. Tak więc wyko­naj model pro­ce­sów biz­ne­so­wych, określ któ­re pro­ce­sy chcesz infor­ma­ty­zo­wać. Potem przy­go­tuj na bazie tej ana­li­zy listę przy­pad­ków uży­cia przy­szłe­go sys­te­mu, uzu­peł­nij ją o model poję­cio­wy two­je­go biz­ne­su i fir­my i prze­każ to do reali­za­cji wyko­naw­cy sys­te­mu. Na koniec pozo­sta­je wdro­że­nie a to już osob­ny pro­jekt :), socjologiczny.

Mały wstęp dla informatyków

Menadżera inte­re­su­ją pro­ce­sy biz­ne­so­we a nie przy­pad­ki uży­cia. System IT kupu­je­my po to by te pro­ce­sy wes­przeć a nie po to by mieć system.

Coraz czę­ściej mene­dże­ro­wie są jed­nak obcią­ża­ni decy­zja­mi o ocze­ki­wa­nej funk­cjo­nal­no­ści sys­te­mów, za któ­re potem pła­cą. Paradoksem wie­lu nie­uda­nych pro­jek­tów jest to, że dostaw­cy roz­wią­zań IT po pierw­sze doku­men­tu­ją sami sobie wyma­ga­nia, po dru­gie robią to meto­da­mi nie­jed­no­krot­nie nie­zna­ny­mi mena­dże­rom (np.. wła­śnie dia­gra­my UML), ci pod­pi­su­ją doku­men­ty nie przy­zna­jąc się, że ich nie zro­zu­mie­li (takie strasz­nie mądre te kwi­ty), dostaw­ca reali­zu­je pro­jekt a na koń­cu mena­dżer mówi: TO NIE TO CHCIAŁEM!

UML czy­li jak napi­sać doku­men­ta­cję nie­zro­zu­mia­łą dla jej adresata

Systemy czę­sto są opi­sy­wa­ne od razu za pomo­cą przy­pad­ków uży­cia, te zaś opi­su­ją zaso­by ale już nie rela­cje mię­dzy nimi. Problem, któ­ry prze­wi­jał się w więk­szo­ści refe­ra­tów na kon­fe­ren­cji to moim zda­niem mie­sza­nie pro­ce­sów, zaso­bów i pro­duk­tów okra­szo­ne wpla­ta­niem w to tak zwa­nych przy­pad­ków uży­cia. Do tego docho­dzi wier­ność meto­dom ana­li­zy zorien­to­wa­nym wła­śnie na przy­pad­ki uży­cia, któ­re to meto­dy są moim zda­niem nie­kom­plet­ne i powo­du­ją wie­le nie­po­ro­zu­mień. Przypadki uży­cia to pod­zbiór peł­nej listy dzia­łań w fir­mie. Dlatego bazo­wa­nie tyl­ko na nich skut­ku­je czę­sto zupeł­ną utra­tą kon­tek­stu pro­jek­tu wdrożeniowego.

Próbą napra­wy tego fak­tu są mode­le tak zwa­nych biz­ne­so­wych i sys­te­mo­wych przy­pad­ków uży­cia, któ­re jed­nak moim zda­niem zaciem­nia­ją tyl­ko obraz. Twierdzenie zaś, że biz­nes powi­nien się nauczyć ana­li­zy obiek­to­wej sko­ro zama­wia sys­te­my jest moim zda­niem tyle samo war­te co twier­dze­nie, że kie­row­cy powin­ni się uczyć ter­mo­dy­na­mi­ki sil­ni­ków spalinowych.

Wiec jed­nak pro­ce­sy i ich analiza

W ana­li­zie pro­ce­so­wej opi­su­je­my orga­ni­za­cje poprzez pro­duk­ty (głow­nie doku­men­ty ale nie tyl­ko) jakie ona wytwa­rza i pro­ce­sy wyma­ga­ne by pro­duk­ty te powsta­wa­ły. System IT jako zasób dla pro­ce­sów jest z natu­ry rze­czy opi­sy­wa­ny rola­mi ludz­ki­mi (akto­rzy) i zaso­ba­mi sys­te­mo­wy­mi, któ­ry­mi są pro­gra­my i sprzęt infor­ma­tycz­ny . Procesy to sieć dzia­łań. Pojęcie sie­ci dzia­łań i kło­po­tów zwią­za­nych z opi­sy­wa­niem ich za pomo­cą przy­pad­ków uży­cia wią­żą się moim zda­niem z tym, że opis pro­ce­so­wy bazu­je na łań­cu­chach war­to­ści będą­cych łań­cu­chem następstw prze­twa­rza­nych pro­duk­tów o czym zapo­mi­na­ją ana­li­ty­cy pro­gra­mi­ści a przy­pad­ki uży­cia to lista tych momen­tów, gdy czło­wiek korzy­sta z sys­te­mu by pro­ces zrealizować.

Jak więc opi­sać wyma­ga­nia na sys­tem IT

Kluczowym ele­men­tem pro­ce­su przej­ścia od opi­su orga­ni­za­cji do opi­su sys­te­mu IT jest trans­for­ma­cja pro­ce­sów biz­ne­so­wych, czy­li wewnętrz­ne­go łań­cu­cha war­to­ści, na zaso­by je wspie­ra­ją­ce i przy­pad­ki ich uży­cia czy­li funk­cjo­nal­no­ści sys­te­mu. Kluczowym ele­men­tem jest decy­zja czy wszyst­kie pro­ce­sy i przy­pad­ki uży­cia sys­te­mu będą imple­men­to­wa­ne w sys­te­mie czy nie, co nazy­wa się po pro­stu ana­li­zą ren­tow­no­ści projektu.

Patrząc na pro­ce­sy biz­ne­so­we musi­my mieć umiar w szcze­gó­ło­wo­ści ich defi­nio­wa­nia, tak by nie dopro­wa­dzić do pró­by algo­ryt­mi­za­cji fir­my. Pamiętajmy, że musi­my zawsze bazo­wać na kom­pe­ten­cjach ludzi i ich wie­dzy o tym co i jak mają robić. Jeżeli nie weź­mie­my tego pod uwa­gę to stwo­rzy­my sys­tem prze­pły­wu pra­cy łączą­cy przy­pad­ki uży­cia w cią­gi o skoń­czo­nej licz­bie kom­bi­na­cji. Pozornie jest to sku­tecz­niej­sze jed­nak klu­czo­wą war­to­ścią firm jest to, że czło­wiek radzi sobie z nie­ty­po­wy­mi sytu­acja­mi co z kolei powo­du­je, że nie moż­na mu wią­zać rąk sce­na­riu­szem. Szczegółowe sce­na­riu­sze mogą mieć zasto­so­wa­nie tam, gdzie 100% pra­cy jest opi­sa­na np. w KPA (Kodeks Postępowania Administracyjnego dla Urzędów) ale i tak bał­bym się je zbyt szcze­gó­ło­wo opi­sy­wać. W fir­mach ryn­ko­wych klu­czo­wym ele­men­tem są kom­pe­ten­cje i doświad­cze­nie ludzi i tu typo­we sys­te­my prze­pły­wu pra­cy (ang. work­flow) stwa­rza­ją nie raz wie­le kło­po­tów odzie­ra­jąc ludzi z pra­wa uży­cia ich wła­snej inwencji.

System dla ludzi

Dlatego wie­le goto­wych uda­nych sys­te­mów w efek­cie ma postać zbio­ru usług wspie­ra­ją­cych zaso­by (ludzi) w reali­za­cji ich bie­żą­cych prac. Proces to poję­cie w 100% abs­trak­cyj­ne nie mają­ce bytów rze­czy­wi­stych, jest to abs­trak­cja łączą­ca ze sobą poję­cia: pro­duk­tów, zaso­bów, reguł, war­to­ści i jako­ści (dla­te­go jest tak trud­ny do zro­zu­mie­nia jako poję­cie). Próba ich opi­su meto­da­mi obiek­to­wy­mi, nie tyl­ko moim zda­niem, jest ska­za­na na nie­po­wo­dze­nie. Opis pro­ce­sów czę­sto bywa przez nie­któ­rych ana­li­ty­ków dodat­ko­wo kom­pli­ko­wa­ny prze­pły­wem samych danych. Prawdopodobnie jest więc tak, że:

  • Procesy są łań­cu­cha­mi two­rzą­cy­mi war­tość dodaną,
  • Procesy są fizycz­nie reali­zo­wa­ne przez zaso­by (ludzi, systemy),
  • Komunikują się z sobą zaso­by (ludzie, akto­rzy) a nie procesy,
  • Przepływ danych nie musi być toż­sa­my z łań­cu­chem pro­ce­sów (nawet rzad­ko taki jest).

Ostatni a uwa­ga jest jed­nym z powo­dów dla któ­rych w lite­ra­tu­rze moż­na spo­tkać się z opi­nia­mi, że przy­czy­ną fia­ska wie­lu pro­jek­tów była ana­li­za wyma­gań bazu­ją­ca tyl­ko na Diagramach Przepływu Danych (ang. DFD: Data Flow Diagram). Pominięcie mode­lu pro­ce­so­we­go rodzi ryzy­ko utra­ty zro­zu­mie­nia kon­struk­cji wewnętrz­nej organizacji.

Model pro­ce­sów powi­nien być uprosz­cze­niem, abs­trak­cją sku­pia­ją­cą się na celo­wo­ści dzia­łań a nie na szcze­gó­łach ich reali­za­cji. Te ostat­nie mogę pod­le­gać sta­łym zmia­nom w fir­mie. Należy wręcz uni­kać na eta­pie zbie­ra­nia wyma­gać zbyt­nie­go uszcze­gó­ła­wia­nia opi­su. Powinno się zamiast opi­so­we­go pre­cy­zo­wa­nia wyma­gań dla pro­ce­su ope­ro­wać przy­kła­da­mi, wzo­ra­mi pro­duk­tów każ­de­go pro­ce­su. Minimalizuje to moż­li­wość nie­po­ro­zu­mień oraz czy­ni taki opis bar­dziej jednoznacznym.

Prawdopodobnie więc na eta­pie opi­su wyma­gań zupeł­nie wystar­cza­ją­ce jest napi­sa­nie, że sys­tem powi­nien wspie­rać wysta­wia­nie fak­tur i dodać wzór tego doku­men­tu niż wyli­sto­wać cechy tego doku­men­tu takie jak: moż­li­wość wpi­sa­nia nazwy pro­duk­tu, licz­by sztuk, nazwy jed­nost­ki, war­to­ści podat­ku, auto­ma­tycz­ne wyli­cza­nie war­to­ści pośred­nich, sum czę­ścio­wych i sum­my cał­ko­wi­tej, wypi­sa­nie ter­mi­nu płat­no­ści , ?. Wzór doku­men­tu z jego opi­sem jest sku­tecz­niej­szym i tań­szym spo­so­bem spe­cy­fi­ko­wa­nia wymagań.

(tekst ten to moje prze­my­śle­nia po wysłu­cha­niu refe­ra­tów na kon­fe­ren­cji UML – zasto­so­wa­nia w biz­ne­sie http://​www​.cpi​.com​.pl/​i​m​p​r​e​z​y​/​2​0​0​7​/​u​m​l​/​i​n​d​e​x​.​php ).

Na pod­sta­wie tego tek­stu powstał arty­kuł Za sys­tem IT nie odpo­wia­da infor­ma­tyk”, któ­ry uka­zał się w nume­rze 12.2011 pisma Kadra Kierownicza w admi­ni­stra­cji. Wszelkie pra­wa do tre­ści arty­ku­łu zastrzeżone.

Zrównoważona Karta Wyników – po co i dla kogo?

Kto z Państwa wie co to jest? Dużo się o tym pisze i mówi, ale o co cho­dzi? Domyślam się, że część z Państwa wie, jed­nak ilość publi­ka­cji i ich treść nie czy­ni tego tak oczywistym.

Pojawiają się arty­ku­ły mówią­ce o Balanced Scorecard (ang. BSC), o Zrównoważonej Karcie Wyników i o Strategicznej Karcie Wyników. To czym więc ona jest? Jest to narzę­dzie do sta­łe­go moni­to­ro­wa­nia sku­tecz­no­ści reali­za­cji zapla­no­wa­nej stra­te­gii roz­wo­ju fir­my. Nie tyl­ko dla wiel­kich, tak­że malut­ka fir­ma może wdro­żyć i śle­dzić kil­ka klu­czo­wych dla niej wskaźników.

Może od począt­ku. Każda fir­ma, któ­ra cokol­wiek w swo­jej dzia­łal­no­ści pla­nu­je, a pla­ny te mają mieć sens, ma (powin­na mieć) narzę­dzie do mie­rze­nia stop­nia osią­ga­nia tych pla­nów. Najczęściej są to pla­ny sprze­da­ży uzu­peł­nio­ne ewen­tu­al­nie ren­tow­no­ścią. Oceniane są (mie­rzo­ne) okre­so­wo np. mie­sięcz­nie, kwar­tal­nie, rocznie.

Niestety ta meto­da ma poważ­ną wadę: mamy obraz jedy­nie efek­tu koń­co­we­go nie uwzględ­nia­ją­ce­go nie­fi­nan­so­wych aspek­tów dzia­łal­no­ści takich choć­by jak jakość pro­duk­tów czy rota­cja kadry albo oce­ny efek­tyw­no­ści pra­cy itp.

Często więc mamy sytu­ację, w któ­rej śle­dzi­my przy­cho­dy (być może nawet rosną­ce) ale nie zauwa­ża­my postę­pu­ją­ce­go pro­ce­su degra­da­cji fir­my. Jak zauwa­ży­my, czę­sto jest za póź­no. Z tego powo­du fir­my czę­sto kon­tro­lu­ją na bie­żą­co wskaź­nik płyn­no­ści finan­so­wej co chro­ni je przed nie­spo­dzie­wa­nym” ban­kruc­twem ale tyl­ko przed tym.

Zrównoważona Karta Wyników

Osobiście jestem zwo­len­ni­kiem pro­ste­go tłu­ma­cze­nia tego poję­cia czy­li Zrównoważona Karta Wyników. Kluczowe jest tu moim zda­niem sło­wo Zrównoważona. Dlaczego?

Wskaźniki do moni­to­ro­wa­nia powin­ny obra­zo­wać w rów­nym stop­niu finan­so­we (twar­de) jak i poza­fi­nan­so­we (mięk­kie) aspek­ty funk­cjo­no­wa­nia fir­my. Dlatego wła­śnie sło­wo Zrównoważona ma tu tak duże zna­cze­nie. Używanie nazwy Strategiczna jest moim zda­niem zabie­giem mar­ke­tin­go­wym w naszym (nie tyl­ko chy­ba nawet) kra­ju. Moda na stra­te­gie nie­ste­ty przy­no­si temu ter­mi­no­wi wię­cej szko­dy niż pożyt­ku. Postrzegana jest jak kolej­ny motor napę­dza­nia przy­cho­dów dla firm kon­sul­tin­go­wych. Szkoda, nie­ste­ty one same są sobie win­ne (ja tam jestem analitykiem :)).

Strategia to opis spo­so­bu poko­na­nia dro­gi od dnia dzi­siej­sze­go do dnia osią­gnię­cia pro­gno­zo­wa­nych (pla­no­wa­nych) rezultatów.

Po pierw­sze jed­nak nale­ży zde­fi­nio­wać mier­ni­ki tego suk­ce­su po dru­gie na dro­dze tej nale­ży moni­to­ro­wać postę­py i reago­wać na odchył­ki od pla­nu. Do tego wła­śnie słu­ży Zrównoważona Karta Wyników: do zde­fi­nio­wa­nia celu, opi­sa­nia stra­te­gii jego osią­gnię­cia oraz mie­rze­nia postępów.

Autorami kon­cep­cji Zrównoważonej Karty Wyników są Robert S. Kaplan i David P. Norton. W ich pier­wot­nej wer­sji wskaź­ni­ki pogru­po­wa­no w czte­ry obsza­ry mierzenia:

  • Finanse
  • Klient
  • Procesy
  • Zasoby ludz­kie

Każdy z tych obsza­rów obej­mu­je pomiar zde­fi­nio­wa­nej gru­py mier­ni­ków poprzez poda­nie dla każ­de­go z nich:

  • celu (np. zwięk­sze­nie lojal­no­ści klientów)
  • wskaź­ni­ka (np. churn)
  • zało­żeń (np. zmniej­sze­nie wskaź­ni­ka churn do war­to­ści 5%)
  • dzia­łań (np. wpro­wa­dze­nie pro­gra­mów lojalnościowych)

Całość jest wła­śnie mie­rzal­nym opi­sem stra­te­gii firmy.

Jak to zrobić?

Pozornie wyglą­da na to, że jest to pro­ste. Jednak jak to zro­bić, by wskaź­ni­ki dawa­ły moż­li­wie naj­peł­niej­szy obraz fir­my i stop­nia reali­za­cji stra­te­gii i żeby mie­ści­ły się np. na jed­nej stro­nie A4? Wygenerowanie wie­lo­stro­ni­co­we­go rapor­tu z księ­go­wo­ści czy z sys­te­mu ERP (dane nie tyl­ko finan­so­we) nie roz­wią­zu­je pro­ble­mu, żeby nie powie­dzieć kom­pli­ku­je spra­wę. Takie wdro­że­nia BSC … nie będą tu opisywane.

Po pierw­sze nikt tego nie czy­ta. Po dru­gie nie o ilość cho­dzi. Więc jak do tego podejść?

Należy zbu­do­wać model fir­my. Stworzyć opis oto­cze­nia ryn­ko­we­go, łań­cu­cha war­to­ści, opis posia­da­nych zaso­bów, pro­ce­sów biz­ne­so­wych oraz budżet. Mając to wszyst­ko stwo­rzyć jed­no­li­ty obraz fir­my z powią­za­nia­mi pomię­dzy budże­tem, ryn­kiem, zaso­ba­mi i pro­ce­sa­mi biz­ne­so­wy­mi. Mając taki peł­ny obraz fir­my może­my wybrać kil­ka klu­czo­wych danych oraz co naj­waż­niej­sze: miej­sca pomia­ru i mia­ry. Zwróćcie Państwo uwa­gę na to, że żeby cokol­wiek mie­rzyć trze­ba wie­dzieć gdzie i czym.

Dla jakich firm ta Karta?

Wielkość fir­my nie ma tu prak­tycz­nie żad­ne­go zna­cze­nia. Koszt? To tyl­ko kwe­stia zde­fi­nio­wa­nia celu, budże­tu na pro­jekt wdro­że­nio­wy i … zmo­dy­fi­ko­wa­nia pla­nu kont (tu ury­wam temat księ­go­wo­ści i księgowych).

Tak więc jak to zrobić:

  1. Przekonać Dział Księgowości
  2. Przekonać kie­row­ni­ków
  3. Zbudować model firmy
  4. Zdefiniować cel do reali­za­cji: stra­te­gię roz­wo­ju fir­my (co i po co kontrolujemy)
  5. Wskazać miej­sca pomia­ru (na mode­lu fir­my) i mierniki.

Acha na począt­ku powie­dzieć sobie, że nie robi­my tego dla mody i zabrać się za to oso­bi­ście (tu mówię do Zarządów i Właścicieli). Zrzucenie tego na gło­wę jakie­muś pra­cow­ni­ko­wi jako dodat­ko­wą robo­tę skoń­czy się naj­praw­do­po­dob­niej zamie­sza­niem i pie­niędz­mi wyrzu­co­ny­mi w błoto.

A teraz pro­po­nu­je prze­rwę na kawę 🙂

Zainteresowana(y) takim pro­jek­tem? Napisz do mnie: Jarek Żeliński