Wymagania biznesowe i Siatka Zachmana

Cztery lata temu pisa­łem o książ­ce Ronalda Rossa Building Business Solutions”:

Druga to pozy­cja nowa, cało­ścio­wo opi­su­ją­ca podej­ście pole­ga­ją­ca na mode­lo­wa­niu orga­ni­za­cji w ana­li­zie biz­ne­so­wej (zawie­ra część mate­ria­łu pierw­szej) . Zwraca uwa­gę na fakt, że nie cho­dzi w ana­li­zie o two­rze­nie mnó­stwa dia­gra­mów a o to, by zro­zu­mieć jak orga­ni­za­cja funk­cjo­nu­je opi­su­jąc to, oraz stwo­rzyć model, któ­ry pozwo­li na pro­gno­zo­wa­nie zacho­wa­nia orga­ni­za­cji w odpo­wie­dzi na bodź­ce, nawet te któ­re jesz­cze nie zaist­nia­ły. (Źródło: Business Rule Concepts ? czy­li jak ?wyłu­skać isto­tę rze­czy? | | Jarosław Żeliński IT-Consulting)

Niedawno wpadł mi w skrzyn­kę kolej­ny wpis na blo­gu R.Rossa:

Zachman?s basic pre­mi­se is that whe­ne­ver you engi­ne­er any­thing of com­ple­xi­ty, no mat­ter what ? a com­plex machi­ne, a sky­scra­per, a micro­chip, a spa­ce­craft, a pro­duct, a busi­ness (an enter­pri­se), or some part of a busi­ness (a busi­ness capa­bi­li­ty) ? the­re are two basic aspects that need to be addres­sed. These two aspects cor­re­spond to the columns and rows of the Framework. (Źródło: What the Zachman Architecture Framework Is ? And How It Relates to Business Rules & Business Analysis | Ronald Ross | LinkedIn, Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edi­tion, by Ronald G. Ross & Gladys S.W. Lam, 2015)

I oka­zu­je się, że zawsze war­to wra­cać do ksią­żek :). Od daw­na pra­cu­je nad uwol­nie­niem spon­so­rów pro­jek­tów od wyma­ga­nia by rozu­mie­li tech­no­lo­gię i teo­rie sys­te­mów. W lite­ra­tu­rze nie raz mozna spo­tkać poję­cie wyma­gań biz­ne­so­wych, pisa­łem o tym trzy lata temu:

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofer­to­wych). (Źródło: Inżynieria wyma­gań | | Jarosław Żeliński IT-Consulting)

Wymieniona wyżej książ­ka Rossa zawie­ra roz­dział Understanding Business Requirements i takie jego sło­wa pod tym tytułem:

RonRossBuildingBusinessSolution_17_1

Model biz­ne­so­wy two­rzy­my by opi­sać daną dzia­łal­ność, może być on tak­że uży­ty do stwo­rze­nia wyma­gań biz­ne­so­wych.” Nieco dalej czytamy:

RonRossBuildingBusinessSolution_17_2

Bardzo waż­ne: wyma­ga­nia biz­ne­so­we defi­niu­je­my wobec sys­te­mu a nie wobec biz­ne­su (fir­my). I to fak­tycz­nie jest powo­dem wie­lu nie­po­ro­zu­mień. W tym samym roz­dzia­le Ross powo­łu­jąc się na Siatkę Zachmana przy­wo­łu­je definicje:

RonRossBuildingBusinessSolution_17_3

Od dłuż­sze­go cza­su sto­su­ję w pro­jek­tach poję­cie Wymagań Biznesowych (opi­sa­ne w cyto­wa­nym wyżej, moim arty­ku­le Inżynieria wyma­gań), i po raz kolej­ny zno­wu, skła­niam się do pró­by wyko­rzy­sta­nia siat­ki Zachmana w tym celu, gdyż jeże­li ten szkie­let archi­tek­to­nicz­ny (Siatka Zachmana to tak zwa­ny szkie­let archi­tek­to­nicz­ny archi­tek­tu­ry kor­po­ra­cyj­nej) fak­tycz­nie pozwo­li spraw­nie zarzą­dzać wyma­ga­nia­mi i ich śla­do­wa­niem, to war­to z tego sko­rzy­stać, na razie porów­nu­je się (nakła­da się) ten szkie­let z MDA i jak widać jest świa­teł­ko w tunelu :):

MDA2Zachman

Dla uła­twie­nia siat­ka Zachmana w pol­skiej wer­sji (kard z pakie­tu Visual-Paradigm).

Siatka Zachmana zakres analizy

Manifest Procesu Biznesowego c.d.

?Wszystko powin­no być tak pro­ste jak jest to moż­li­we, ale nie prostsze.? 
(Albert Einstein)

Stosunkowo nie­daw­no (pia­łem o tym już) Roger Burlton (Chairman, Board of Advisors, BPTrends) opu­bli­ko­wał na stro­nie Business Process Trends Manifest Procesu Biznesowego. Podejrzewam, że to efekt lek­kiej” kon­ku­ren­cji z [[Business Rules Group]] i Ronaldem G. Rossem 😉 ale dobrze bo taka kon­ku­ren­cja jest twór­cza a ich (głów­nie Ronald G. Ross BRGroup oraz Paul Harmon z BPTrends) obec­ne ich pole­mi­ki na stro­nach LinkedIn są bar­dzo poucza­ją­ce i myślę, że obie stro­ny na tym zysku­ją, że nie wspo­mną o pozo­sta­łych uczest­ni­kach tych dys­ku­sji. Osobiście doce­niam doro­bek zarów­no Ronalda Rossa jak i Rogera Burltona czy Paula Harmona (ten dru­gi czę­ściej się udzie­la na LinkedIn). Burlton tak wyja­śnia potrze­bę jego – tego mani­fe­stu – powstania:

  • Istnieje wie­le nie­ja­sno­ści doty­czą­cych kon­cep­cji Procesu Biznesowego i jego terminologii.

  • Brakuje aktu­al­nych stan­dar­dów doty­czą­cych fun­da­men­tal­nych pojęć odno­śnie Procesu Biznesowego.

  • Zastosowania kon­cep­cji zwią­za­nych z Procesem Biznesowym sta­ły się zbyt zło­żo­ne, co unie­moż­li­wia ich łatwe zro­zu­mie­nie i sto­so­wa­nie w praktyce.

  • Błędy popeł­nia­ne we wdro­że­niach stra­te­gii Procesu Biznesowego, archi­tek­tu­ry pro­ce­sów, jak rów­nież w ana­li­zie i pro­jek­to­wa­niu Procesu Biznesowego, są rezul­ta­tem nie­zro­zu­mie­nia­po­jęć i prak­tyk doty­czą­cych Procesu Biznesowego.

  • Istnieje potrze­ba pro­fe­sjo­nal­ne­go, uży­wa­ne­go w spo­sób zdy­scy­pli­no­wa­ny, zin­te­gro­wa­ne­go i powta­rzal­ne­go zesta­wu prak­tycz­nych spo­so­bów postę­po­wa­nia doty­czą­cych Procesu Biznesowego.

  • Istnieje potrze­ba, aby Procesy Biznesowe były zarzą­dza­ne jako akty­wa orga­ni­za­cji, któ­re mogą być powszech­nie rozu­mia­ne, współ­dzie­lo­ne i wie­lo­krot­nie wykorzystywane.

  • Bez solid­nej, opar­tej na fun­da­men­tal­nych zasa­dach pod­sta­wy seman­tycz­nej nie może ist­nieć uży­tecz­ny zasób wie­dzy o Procesie Biznesowym.

(źr. BPYtends​.com, ? Prawa autor­skie BPTrends, LLC. – Opracował Roger Burlton. Niniejszym udzie­la się zgo­dy na nie­ogra­ni­czo­ne powie­la­nie i roz­po­wszech­nia­nie tego doku­men­tu pod nastę­pu­ją­cy­mi warun­ka­mi: (a) Umieszczenia w widocz­nym miej­scu praw autor­skich i niniej­szej noty praw­nej. (b) Zaznaczenia, że zawar­tość doku­men­tu jest wła­sno­ścią inte­lek­tu­al­ną BPTrends, LLC. © Żadna z czę­ści niniej­sze­go doku­men­tu, łącz­nie z tytu­łem, tre­ścią, pra­wa­mi autor­ski­mi i niniej­szą notą praw­ną nie może zostać zmie­nio­na, skró­co­na bądź posze­rzo­na w jaki­kol­wiek spo­sób. Komercyjne wyko­rzy­sta­nie tego doku­men­tu, w cało­ści lub czę­ścio­wo, jest ści­śle zabronione.)

Polecam cały doku­ment, do pobra­nia tu: BPManifesto_PL_A4.

Od sie­bie dodam, że moje pra­ce zwią­za­ne z mode­lo­wa­niem orga­ni­za­cji pro­wa­dzą do wnio­sku, że nie moż­li­we jest opi­sa­nie orga­ni­za­cji w jed­nym tyl­ko para­dyg­ma­cie, np. pro­ce­so­wym. W 2012 roku pisałem:

Cieszy mnie ten Manifest tak­że dla­te­go, że moje dąże­nie do pro­sto­ty i for­ma­li­za­cji w posta­ci prag­ma­ty­ki jaką sto­su­ję w swo­jej meto­dy­ce, są zgod­ne z tym Manifestem. (Źródło: Business Process Manifesto | Jarosław Żeliński IT-Consulting).

Skłaniam się ku tezie, że orga­ni­za­cja, jak każ­dy sys­tem otwar­ty, to kil­ka róż­nych aspek­tów jej dzia­ła­nia: struk­tu­ra, dyna­mi­ka, mecha­nizm dzia­ła­nia czy­li regu­ły. Obecne spo­ry pomię­dzy R.Rossem i śro­do­wi­skiem [[Busieness Ruless Group]] a P.Harmonem i Business Process Associates przy­po­mi­na­ją mi daw­ne spo­ry pomię­dzy trze­ma twór­ca­mi obec­ne nota­cji UML (pier­wot­nie każ­dy opra­co­wał swo­ją gru­pę modeli/diagramów dia­gra­mów z okre­ślo­nej per­spek­ty­wy, oryg. ang. [[The Three Amigos, a nick­na­me given to James Rumbaugh, Grady Booch and Ivar Jacobson, deve­lo­pers of Unified Modeling Language (UML)]]).

Wydaje mi się, że obec­ny stan nota­cji UML pozwa­la mode­lo­wać wszel­kie obiek­to­wo zorien­to­wa­ne aspek­ty orga­ni­za­cji sta­no­wią­ce nie­ja­ko mecha­nizm jej dzia­ła­nia, to model obiek­to­wy sys­te­my (w sumie nie ma zna­cze­nia czy będzie on odwzo­ro­wy­wa­ny w apli­ka­cji pod posta­cią Model Dziedziny czy nie). BPMN to nota­cja stric­te biz­ne­so­wa, słu­ży do mode­lo­wa­nia abs­trak­cji jaką jest łań­cuch war­to­ści doda­nej wewnątrz niej. Te mode­le są bar­dzo istot­ne dla zro­zu­mie­nia co i po co się dzie­je”. Nad tym wszyst­kim jest moty­wa­cja czy­li sfor­ma­li­zo­wa­ne pryn­cy­pia: model moty­wa­cji biz­ne­so­wej, są to te ele­men­ty któ­re na naj­wyż­szym pozio­mie opi­su­ją orga­ni­za­cję jako pod­miot na ryn­ku (nie zapo­mi­naj­my, że urzę­dy tak­że uczest­ni­czą w ryn­ku bo mają na nie­go wpływ lub wręcz kształ­tu­ją jako regulator).

Czy aby na pewno zarządzamy procesami biznesowymi?

Swego cza­su w arty­ku­le na temat reguł biz­ne­so­wych, pra­wie dwa lata temu, napi­sa­łem że pro­ces biz­ne­so­wy to nie przy­czy­na a sku­tek ogra­ni­czeń. W jed­nym ze swo­ich arty­ku­łów Ronald Ross (autor i współ­za­ło­ży­ciel Business Rules Group) napi­sał niedawno:

?Rules defi­ne the boun­da­ry betwe­en accep­ta­ble and unac­cep­ta­ble busi­ness acti­vi­ty.? (w dys­ku­sji o regu­łach: When can you call a busi­ness archi­tec­tu­re ?smart??) 

Przypominam ten cytat, gdyż regu­lar­nie sły­chać mod­ny slo­gan ostat­nich lat: zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi”. Tak więc sko­ro regu­ły wyzna­cza­ją gra­ni­cę pomię­dzy akcep­to­wal­ny­mi i nie­ak­cep­to­wal­ny­mi zacho­wa­nia­mi w biz­ne­sie” to zna­czy, że zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi” ozna­cza zarzą­dza­nie tymi gra­ni­ca­mi a nie pro­ce­sa­mi, bo te są efek­tem ist­nie­nia tej gra­ni­cy a nie odwrotnie.

Chyba nikt roz­sąd­ny nie powie, że ma bez­po­śred­ni wpływ na nurt wody w rze­cze, zarzą­dza­my linią brze­go­wą, bo ją może­my inży­nie­ryj­nie kształ­to­wać, woda popły­nie zawsze z góry na dól, nigdy pod górkę.

W ostat­nim roku bylem na kil­ku kon­fe­ren­cjach na temat obie­gu doku­men­tów, pro­ce­sach biz­ne­so­wych i zarzą­dza­niu tym wszyst­kim. Wszędzie moż­na było usły­szeć, że zarzą­dza się pro­ce­sa­mi”. Moim zda­niem to fałsz, uza­sad­nie­nie powyżej.

Wśród ogrom­nej licz­by funk­cjo­nu­ją­cych firm, jaki odse­tek ma mapy pro­ce­sów”? Znikomy. Czym więc zarzą­dza­ją tam Zarządy tych firm?

Poniżej umie­ści­łem pre­zen­ta­cje z kil­ku kon­fe­ren­cji na ten temat i na temat EOD (Elektroniczny Obieg Dokumentów). Opisałem tam pew­ne mecha­ni­zmy, któ­rych brak zro­zu­mie­nia jest jed­ną z głów­nych przy­czyn pora­żek wie­lu wdro­żeń sys­te­mów zwa­nych wdzięcz­nie work­flow czy docu­ment­flow. Należy pamię­tać, że pro­ces biz­ne­so­wy w orga­ni­za­cji to tak na praw­dę sekwen­cja prac koń­czo­nych doku­men­tem (opis tego co zro­bio­no, raport, notat­ka, dowód księ­go­wy, nowy doku­ment itp.)

Kluczowe tezy pierw­szej prezentacji:

  1. Przepływ doku­men­tów: prze­ka­zy­wa­nie tre­ści w wer­sji papie­ro­wej lub elek­tro­nicz­nej, pomię­dzy punk­ta­mi jej prze­twa­rza­nia. Ścieżka prze­pły­wu doku­men­tów może być z góry narzu­co­na lub kształ­to­wa­na decy­zja­mi w punk­tach prze­twa­rza­nia. Decyzje te tak­że mogą pod­le­gać ogra­ni­cze­niom (źr. opr. wła­sne autora).
  2. Procesy biz­ne­so­we są kształ­to­wa­ne przez sytu­ację praw­ną oraz struk­tu­rę orga­ni­za­cyj­na, zakre­sy obo­wiąz­ków i kompetencje.
  3. Pewne te same role są peł­nio­ne przez róż­nych pracowników.
  4. Przepływ doku­men­tów oraz ich repo­zy­to­rium to odręb­ne sys­te­my”.
  5. Większość wyma­gań funk­cjo­nal­nych jest reali­zo­wa­na wła­ści­wym zbu­do­wa­niem sys­te­mu meta­da­nych w repozytorium.
  6. Systemu ERP nie są sys­te­ma­mi pro­ce­so­wy­mi, to sys­te­my obsłu­gu­ją­ce sta­tu­sy poje­dyn­czych doku­men­tów, są nimi prak­tycz­nie tyl­ko dowo­dy księ­go­we (poza sys­te­ma­mi ERP prze­twa­rza­nych jest ok. 80% doku­men­tów takich jak umo­wy, ofer­ty, zapy­ta­nia, stro­ny WWW czy pro­ste notat­ki ze spo­tkań a tak­że doku­men­ty for­mal­ne np. zarządzenia).

Dlatego ana­li­za i spe­cy­fi­ko­wa­nie wyma­gań na sys­te­my prze­pły­wu doku­men­tów czy po pro­tu popra­wy pro­ce­sów biz­ne­so­wych to przy­go­to­wa­nie fir­my do zmian orga­ni­za­cyj­nych a nie spi­sy­wa­nie ocze­ki­wań pra­cow­ni­ków z nadzie­ją, że dział HR nie odczu­je tej zmia­ny. Nie zarzą­dza­my pro­ce­sa­mi, kształ­tu­je­my je.

Proponuje zapo­zna­nie się z tego­rocz­ny­mi moimi pre­zen­ta­cja­mi do refe­ra­tów na temat EOD:

  1. JZelinski – obieg infor­ma­cji co współ­dzie­li­my a co przepływa
  2. Kolejna rzecz to auto­ma­ty­za­cja, wie­le się o niej mówi, jed­nak nie jest to łatwe i rzad­ko kie­dy uda­je się osią­gnąć: Automatyzacja pro­ce­sów biz­ne­so­wych ? jak to zro­bić dobrze.
  3. Co nas cze­ka, co i jak wdra­żać, czy ERP to lekar­stwo na wszyst­ko? Kierunki roz­wo­ju sys­te­mów obie­gu doku­men­tów. 

Firmy zain­te­re­so­wa­ne szcze­gó­ła­mi refe­ra­tów a tak­że prze­pro­wa­dze­niem jed­no­dnio­we­go semi­na­rium dla pra­cow­ni­ków na ten temat zapra­szam do kontaktu.