Idealizacja w toku projektowania czyli proste jest piękne

Nie raz poja­wia­ły się tu (mój blog) odnie­sie­nia do tak zwa­ne­go ide­ału (ide­ali­za­cja ) jako wzor­ca lub szkie­le­tu. W arty­ku­le o stu­dium wyko­nal­no­ści pisałem:

Brak wie­dzy o sta­nie ide­al­nym moż­li­wym i brak mode­lu, czy­ni ana­li­zę wyko­nal­no­ści bar­dzo ryzy­kow­ną, więc prak­tycz­nie bez­war­to­ścio­wą. (Źródło: Studium wyko­nal­no­ści ? czym napraw­dę jest | | Jarosław Żeliński IT-Consulting)

Dzisiaj kil­ka słów o jed­nym z kile­rów” pro­jek­tów ana­li­tycz­nych: utra­ta pano­wa­nia nad szczegółowością.

Detale, detale…

Praktycznie zawsze w toku odbio­ru wyni­ków prac ana­li­tycz­nych sły­szę: ale tu nie ma wie­lu rze­czy”. I jest to praw­da, ale nie ma (zosta­ły po pro­tu pomi­nię­te) rze­czy nie­istot­nych z per­spek­ty­wy ana­li­zy i jej celu. Firmy ist­nie­ją i roz­wi­ja­ją się lata­mi, nie raz nawet kil­ka­dzie­siąt lat. W tym cza­sie obra­sta­ją” w róż­ne lokal­ne spo­so­by”, mnó­stwo warian­tów osią­ga­nia kon­kret­nych, tych samych celów, nawet tych malut­kich lokal­nych. Bywają ich set­ki. Bardzo popu­lar­nym, wśród firm dostar­cza­ją­cych opro­gra­mo­wa­nie, spo­so­bem ana­li­zo­wa­nia” jest pisa­nie tak zwa­nych user sto­ry (histo­ryj­ki użyt­kow­ni­ka). Są to, opi­sa­ne sło­wa­mi pra­cow­ni­ka ana­li­zo­wa­nej fir­my, zda­rze­nia sta­no­wią­ce pod­sta­wę zro­zu­mie­nia” jak dana orga­ni­za­cja dzia­ła. Metoda ta jest obcią­żo­na poważ­ną wadą:

User sto­ry to per­spek­ty­wa użyt­kow­ni­ka i to ska­żo­na jego ogra­ni­czo­ną wie­dzą lub jej bra­kiem oraz ogra­ni­czo­nym doświad­cze­niem lub bra­kiem doświad­cze­nia. Duże, zdo­by­te w jed­nym miej­scu, doświad­cze­nie pra­cow­ni­ka, bez głęb­szej i szer­szej ana­li­zy, też nie popra­wia sytu­acji, czę­ściej ją jesz­cze pogar­sza (bo nikt nie podej­mu­je dys­ku­sji z tym ?dużym doświad­cze­niem?). (Źródło: User sto­ry czy­li nic nie popra­wić a może nawet bar­dziej skom­pli­ko­wać | | Jarosław Żeliński IT-Consulting

Opisy te bywa­ją nie raz bar­dzo boga­te, zebra­ne w toku wie­lo­go­dzin­nych, tak zwa­nych, warsz­ta­tów lub ankiet. Spisywane są nie raz ogrom­ne ilo­ści deta­li, któ­re zamiast cokol­wiek wyja­śnić, zaciem­nia­ją isto­tę rzeczy.

Jajko1

Powyższe zdję­cie przed­sta­wia coś co nazwę sta­nem obec­nym”. To widok jaki zasta­je ktoś, kto spoj­rzy na daną orga­ni­za­cję teraz”. Opisanie tego co widzi­my może zająć elo­kwent­nej oso­bie nawet wie­le stron tek­stu. Czy opis ten przy­bli­ży nas choć trosz­kę do odpo­wie­dzi na pyta­nie co to jest i jak to działa”?

Celem ana­li­zy jest zro­zu­mie­nie, z czym na praw­dę mamy do czy­nie­nia. Analityk swo­ją pra­cą powi­nien dopro­wa­dzić do powsta­nia doku­men­tu (mode­li…) obra­zu­ją­cych isto­tę rze­czy”, powi­nien w koń­cu odkryć, że powyż­sze to jest to:

Jajko0

Owszem, lata roz­wo­ju bada­nej fir­my, zawsze dopro­wa­dzą do powsta­nia ogrom­nej masy deta­li towa­rzy­szą­cych celo­wi biz­ne­so­we­mu, jed­nak ten cel się nie zmie­nia (cały pro­ces powsta­wia tej pisan­ki: źr. http://​kur​sy​krok​po​kro​ku​.blog​spot​.com/​2​0​1​6​/​0​2​/​k​o​s​z​y​c​z​e​k​-​n​a​-​j​a​j​k​o​-​p​i​s​a​n​k​e​-​k​u​r​s​-​k​r​o​k​-​p​o​.​h​tml).

Jeżeli więc mamy opra­co­wać reko­men­da­cje do zmian, zapro­jek­to­wać opro­gra­mo­wa­nie, to albo zro­zu­mie­my co i po co dana fir­ma robi, czym na praw­dę jest, albo zabrnie­my w doku­men­to­wa­nie ogrom­nej licz­by deta­li, dotych­cza­so­wych spo­so­bów osią­ga­nia celów, co potra­fi zabić pro­jekt” swo­ją szcze­gó­ło­wo­ścią (i zabe­to­no­wać, nie koniecz­nie dobry, stan obecny).

Przeprowadzenie ana­li­zy ma jeden cel: zro­zu­mieć. Nie jest jej celem opi­sy­wa­nie” cze­go­kol­wiek. Niestety wie­le firm pomi­ja ana­li­zy, idzie ścież­ką opi­sze­my co robi­my i wystarczy”.

Czego się spo­dzie­wać po pro­jek­cie, gdy sły­szę: nie ma cza­su na ana­li­zę, myśmy już pod­pi­sa­li umo­wę z wyko­naw­cą bo nasza fir­ma nie ma cza­su. Niestety naj­czę­ściej taki pro­jekt trwa znacz­nie dłu­żej niż pla­no­wa­no, pie­nią­dze oszczę­dzo­ne na ?zbęd­nym? pro­jek­to­wa­niu ide­ału z ogrom­na nawiąz­ką są wyda­wa­ne na kolej­ne mody­fi­ka­cje i popraw­ki (Źródło: Utopia ? czy­li model ide­ału poma­ga w pro­jek­tach | | Jarosław Żeliński IT-Consulting)

Tak więc, doku­men­ta­cja zawie­ra­ją­ca 10 dia­gra­mów pro­ce­sów biz­ne­so­wych pra­wie zawsze będzie lep­sza od tej zawie­ra­ją­cej 100 dia­gra­mów. Ta, któ­ra nie zawie­ra żad­ne­go, jed­nak będzie znacz­nie gorsza.….

Na koniec pole­cam świet­ną książ­kę na ten temat, w któ­rej autor pisze we wstępie: 

Projektowanie ide­ału jest takim spo­so­bem myśle­nia o zmia­nie, któ­ry moż­na przed­sta­wić w spo­sób: w roz­wią­zy­wa­niu pro­ble­mów, prak­tycz­nie dowol­ne­go rodza­ju, moż­na uzy­skać naj­lep­sze wyni­ki dzię­ki wyobra­że­niu sobie ide­al­ne­go roz­wią­za­nia, a następ­nie cof­nię­ciu się aż do miej­sca, w któ­rym znaj­du­jesz się w chwi­li obec­nej. Dzięki temu unik­niesz uro­jo­nych przez sie­bie prze­szkód, zanim jesz­cze w ogó­le poj­miesz, jaki ma być ide­ał. .

Źródła

McMullin, E. (1985). Galilean ide­ali­za­tion. Studies in History and Philosophy of Science Part A, 16(3), 247 – 273. https://​doi​.org/​1​0​.​1​0​1​6​/​0​039 – 3681(85)90003 – 2
Niaz, M. (1993). If Piaget’s epi­ste­mic sub­ject is dead, shall we bury the scien­ti­fic rese­arch metho­do­lo­gy of ide­ali­za­tion? Journal of Research in Science Teaching, 30(7), 809 – 812. https://​doi​.org/​1​0​.​1​0​0​2​/​t​e​a​.​3​6​6​0​3​0​0​717
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.

Koncepcja to nie wymagania!

Dwa lata temu pisa­łem o tym, czym jest, po co się pro­wa­dzi i jak, stu­dium wyko­ny­wal­no­ści projektu:

W lite­ra­tu­rze moż­na spo­tkać róż­ne ?defi­ni­cje? stu­dium wyko­nal­no­ści, jed­nak ta któ­rą opi­sa­łem, zda­je się być naj­bliż­sza defi­ni­cji, któ­rą przy­to­czy­łem na począt­ku: bazu­ją­cej na zna­cze­niu słow­ni­ko­wym. Praktyka poka­zu­je, że inten­cje spon­so­rów tych ana­liz są z nią zbież­ne: celem jest pod­ję­cie decy­zji o naj­mniej­szym ryzy­ku w świe­tle posia­da­nej na dany temat wie­dzy. Definicje bazu­ją­ce na tech­nicz­nej i finan­so­wej wyko­nal­no­ści dane­go pro­jek­tu, są spo­ty­ka­ne dość czę­sto i w lite­ra­tu­rze i na stro­nach wie­lu insty­tu­cji. Metoda pro­wa­dze­nia takich ana­liz, bazu­ją­ca na mode­lo­wa­niu czy­li na ana­li­zie sys­te­mo­wej, wyda­je się być jed­nak naj­wła­ściw­szą. (Źródło: Studium wyko­nal­no­ści ? czym napraw­dę jest | | Jarosław Żeliński IT-Consulting)

W arty­ku­le tym zwra­ca­łem uwa­gę na war­tość mode­lo­wa­nia (a nie ryso­wa­nia…), war­to­ścią tą jest testo­wa­nie kon­cep­cji. Sama kon­cep­cja nie jest żad­nym wyma­ga­niem, co ilu­stru­je świet­ny arty­kuł na stro­nach Modernanalyst​.com:

Requirements must be based on facts and real-life sce­na­rios. When the con­cept is unte­sted or not ful­ly tested, then the requ­ire­ments are hypo­the­ti­cal. Moving to design and build with hypo­the­ti­cal requ­ire­ments, the design and/or build pha­se beco­mes the testing gro­und for the con­cept. This may lead to cla­shes as each par­ty has dif­fe­rent expec­ta­tions of the out­co­me of the ?hypo­the­ses?.

Źródło: Blueprints Are Not Requirements!

Powyższy dia­gram poka­zu­je głów­ne prze­sła­nie opi­sa­nej meto­dy, któ­ra jest zgod­na w 100% z peł­ną ana­li­zą sys­te­mo­wą: pierw­szy etap to opra­co­wa­nie kon­cep­cji czy­li hipo­te­zy mówią­cej taki sys­tem jest nam potrzeb­ny” do roz­wią­za­nia pro­ble­mu biz­ne­so­we­go (potrze­by biz­ne­so­we). Kolejny etap to stwier­dze­nie popraw­no­ści pomy­słu, to nic inne­go jak stu­dium wyko­nal­no­ści, testo­wa­nie pomy­słu. Tu waż­na rzecz: test musi być pro­wa­dzo­ny w opar­ciu o fak­ty i tyl­ko fak­ty, inny­mi sło­wy model nie może koli­do­wać z rze­czy­wi­sto­ścią, musi tak­że poka­zać, że zapro­jek­to­wa­ny nowy lub zmie­nio­ny mecha­nizm dzia­ła­nia orga­ni­za­cji da ocze­ki­wa­ne efek­ty. Dopiero gdy hipo­te­za mówią­ca, że taki sys­tem reali­zu­je nasze potrze­by” zosta­nie potwier­dzo­na testa­mi na mode­lu, ma sens opra­co­wy­wa­nie wyma­gań na to roz­wią­za­nie. W toku opra­co­wy­wa­nia wyma­gań, tak­że je testu­je­my. Tu zno­wu spraw­dza się sku­tecz­ność podej­ścia pro­jekt (model) jako wymaganie”.

Trzy lata temu opi­sa­łem cały taki pro­ces, na dość może try­wial­nym przy­kła­dzie (sza­chy), ale za to (mam nadzie­ję) przej­rzy­stym. Na zakoń­cze­nie arty­ku­łu zwró­ci­łem uwa­gę, że:

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko ?imple­men­ta­cja? kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakaś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję poka­za­łem. Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kur­sów. (Źródło: Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie | | Jarosław Żeliński IT-Consulting).

Autor arty­ku­łu przy­wo­łu­je nie­zmien­ną od lat statystykę:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

…i zwra­ca uwa­gę, że ich przy­czy­ny są od lat sta­le takie same…

Requirements must be based on facts and real-life sce­na­rios.” (wyma­ga­nia muszą być opar­te na fak­tach i real­nych sce­na­riu­szach). Więc ile war­te są wizje w pro­jek­tach agi­le albo wydu­ma­ne w toku warsz­ta­to­wych burz mózgów lita­nie życzeń i pomy­słów? Nie tyl­ko moim zda­niem: nie są wie­le war­te i nie powin­ny być wymaganiami.

Abstrakcja w Architekturze Biznesowej

W poprzed­nim arty­ku­le, Czy sys­tem peł­ni rolę w pro­ce­sie?, poja­wi­ła się pole­mi­ka, któ­ra jest dość powszech­nym problemem:

[czy­tel­nik] Są to pro­ce­sy (lub pod­pro­ce­sy), któ­re zosta­ły zastą­pio­ne w 100% i alter­na­tyw­na ich obsłu­ga będzie moż­li­wa tyl­ko w przy­pad­ku wystą­pie­nia jakie­goś błędu.

Przykładem takie­go pro­ce­su jest zauto­ma­ty­zo­wa­nie reje­stra­cji doku­men­tów (wpro­wa­dze­nie kana­łu mailo­we­go, odcię­cie cał­ko­wi­te moż­li­wo­ści wyko­rzy­sta­nia papie­ro­wych doku­men­tów). Test odłą­cze­nia prą­du ode­tnie orga­ni­za­cję od świa­ta zewnętrz­ne­go. Wyobrażam sobie wie­le biz­ne­sów opie­ra­ją­cych się w więk­szo­ści o chmu­ry, usłu­gi, któ­rych wycię­cie spro­wa­dzi ten aku­rat biz­nes do pozio­mu średniowiecznego.

[moja odpo­wiedź] odłą­cze­nie prą­du spo­wo­du­je zmu­sze­nie do prze­my­śle­nia i nazwa­nia pro­ce­su ?przyj­mo­wa­nie doku­men­tów? a mail to tyl­ko przy­ję­ta meto­da, tu błę­dem było nazwa­nie pro­ce­su biz­ne­so­we­go ?odbie­ra­ni maili? zamiast nazwa­nie go ?tym czym jest? czy­li ?przyj­mo­wa­nie korespondencji?.

Jest to kla­sycz­ny przy­kład bra­ku uogól­nień i abs­trak­cji w mode­lach, co pro­wa­dzi do zamu­la­nia” ich nad­mia­rem szcze­gó­łów, masko­wa­nia praw­dzi­we­go sen­su (isto­ty) zja­wi­ska. Problem sto­so­wa­nia abs­trak­cji w mode­lo­wa­niu a kon­kret­nie, pro­blem nie radze­nia sobie z abs­trak­cją, jest czę­sto w lite­ra­tu­rze nazy­wa­ny utra­tą pano­wa­nia nad szcze­gó­ło­wo­ścią pro­jek­tu”. Monstrualne ilo­ści dia­gra­mów pro­ce­sów, mon­stru­al­ne ilo­ści deta­li na dia­gra­mach, to efekt bra­ku abstrakcji.

Warto pamię­tać, że mode­le pro­ce­sów biz­ne­so­wych to ele­ment opi­su archi­tek­tu­ry biz­ne­so­wej. Po raz kolej­ny przy­po­mnę diagram:

(źr. http://www.bptrendsassociates.com/)
(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Najniższa war­stwa to imple­men­ta­cja pro­ce­sów, tu dopie­ro mamy wszel­kie szcze­gó­ły takie jak: zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we i pod­ręcz­ni­ki użyt­kow­ni­ków, pro­ce­du­ry, wyma­ga­ne umie­jęt­no­ści, kon­kret­ne roz­wią­za­nia np. opro­gra­mo­wa­nie. Są to te ele­men­ty, któ­rych nie umiesz­cza­my na mode­lu pro­ce­sów, bo pro­ce­sy biz­ne­so­we to czyn­no­ści prze­kształ­ca­ją­ce stan wej­ścia w stan wyj­ścia”. Proces biz­ne­so­wy to jeden blo­czek” wraz z jego wej­ściem i wyj­ściem (pro­ces defi­niu­ją te trzy ele­men­ty) na sche­ma­cie blo­ko­wym będą­cym mode­lem (mapą) pro­ce­sów. Bloczek repre­zen­tu­ją­cy czyn­ność (aktyw­ność, kwe­stia nazew­nic­twa), jest abs­trak­cją pro­ce­du­ry, umie­jęt­no­ści, instruk­cji obsłu­gi, itp. W doku­men­ta­cji więc powo­łu­je­my się na te np. pro­ce­du­ry (sto­sow­ne doku­men­ty), a nie odtwa­rza­my ich obraz­ko­wo” na mode­lu pro­ce­sów, bo to pro­wa­dzi po pierw­sze do dublo­wa­nia ist­nie­ją­cej doku­men­ta­cji oraz do strasz­nej kom­pli­ka­cji dia­gra­mów obra­zu­ją­cych procesy.

Problem ten dobrze opi­su­je autor tego artykułu:

One of the key cha­rac­te­ri­stics of archi­tec­tu­re is looking at the ?big pic­tu­re?, but a major chal­len­ge is that we can?t pre­sent the big pic­tu­re on one gre­at big pie­ce of paper ? it has to fit on a sin­gle she­et or model. In order to do that, we have to come up with new con­cepts that sum­ma­ri­ze the ove­rall pic­tu­re into a small num­ber of ele­ments and rela­tion­ships. We can do this thro­ugh a varie­ty of tech­ni­qu­es, like divi­de-and-conqu­er, cate­go­ri­za­tion, gene­ra­li­za­tion, and so on. (BPTrends | Business Archicture: Abstraction in Business Architecture).

Tak więc brak (umie­jęt­no­ści) sto­so­wa­nia abs­trak­cji w mode­lo­wa­niu czy­ni te i inne mode­le (tak­że UMl itp.) nie­czy­tel­ny­mi, trud­ny­mi do inter­pre­ta­cji, kosz­tow­ny­mi w wytwo­rze­niu i potem w utrzy­ma­niu. To ostat­nie powo­du­je, że więk­szość takich doku­men­tów szyb­ko koń­czy życie na pół­kach, bo dez­ak­tu­ali­zu­ją się jak tyl­ko doj­dzie do jakiej­kol­wiek, nawet naj­drob­niej­szej, zmia­ny w orga­ni­za­cji. Co cie­ka­we, bio­rąc pod uwa­gę czas trwa­nia prze­cięt­ne­go wdro­że­nia opro­gra­mo­wa­nia, taki zbyt szcze­gó­ło­wy model nie ma szans być przy­dat­nym w toku takie­go pro­jek­tu, tu rację mają deve­lo­pe­rzy, któ­rzy twier­dzą, że im takie doku­men­ty im w niczym nie pomagają.

No ale te szcze­gó­ły są potrzeb­ne. Owszem pyta­nie: któ­re oraz czy na pew­no musi­my je obraz­ko­wo prze­pi­sy­wać np. z doku­men­tów dzia­łu HR czy jako­ści. W doku­men­to­wa­niu (mode­lo­wa­niu) orga­ni­za­cji sto­su­je­my róż­ne per­spek­ty­wy”, kil­ka pro­stych sche­ma­tów lepiej mode­lu­je orga­ni­za­cję niż jed­ne, na któ­rych ktoś upy­cha wszyst­ko co wie” (jak to robić lepiej opi­sa­łem w arty­ku­le Gdzie są te … szcze­gó­ły).

Tak więc doku­men­to­wa­nie szcze­gó­łów” owszem jest potrzeb­ne, ale nie na dia­gra­mie pro­ce­su. Umiejętności i wie­dza wyko­naw­cy to rola w pro­ce­sie: każ­da powin­na mieć osob­ną doku­men­ta­cję (lub odwo­ła­nie do doku­men­tów w HR). Szczegóły reali­za­cji zadań (czyn­no­ści, aktyw­no­ści) to pro­ce­du­ry, na któ­re zno­wu się powo­łu­je­my, lub takie doku­men­ty jak macierz RACI i spe­cy­fi­ka­cja poli­tyk i reguł biz­ne­so­wych (opi­sa­łem to w arty­ku­le RACI … i wcze­śniej­szym RACI i SIPOC).

I tu mały przty­czek dla spon­so­rów pro­jek­tów zle­ca­ją­cych takie ana­li­zy: żąda­nia wobec ana­li­ty­ka w rodza­ju a ja chcę zoba­czyć jesz­cze to … na tym sche­ma­cie” to zabi­ja­nie pro­jek­tu. Są uzna­ne dobre prak­ty­ki, mię­dzy inny­mi mode­lo­wa­nie od ogó­łu do szcze­gó­łu, sto­so­wa­nie abs­trak­cji i per­spek­tyw. Nikt roz­sąd­ny nie będzie podej­mo­wał prób two­rze­nia pla­nu mia­sta, na któ­rym będą wszyst­kie te rze­czy, któ­re w danym mie­ście są np. przy­stan­ki środ­ków komu­ni­ka­cji publicz­nej, pod­mio­ty gospo­dar­cze, ale tak­że wyso­kość grun­tu, zna­ki dro­go­we, skle­py itp. Taka mapa, zakła­da­jąc jej roz­sąd­ną wiel­kość, była by nie­przy­dat­na, więc żąda­nie takiej od ana­li­ty­ka tak­że nie ma żad­ne­go sensu.

Opis stanowiska pracy architekta korporacyjnego

Architektura kor­po­ra­cyj­na wzbu­dza w wie­lu fir­mach, u wie­lu ludzi, wie­le emo­cji. Rola oso­by nazy­wa­nej Architektem Korporacyjnym budzi te emo­cje chy­ba z uwa­gi na nie­for­tun­na nazwę, będą­cą pro­stym tłu­ma­cze­niem Enterprise Architect. Tak na praw­dę, moim zda­niem, w języ­ku pol­skim owe sta­no­wi­sko” raczej powin­no mieć nazwę Architekt archi­tek­tu­ry kor­po­ra­cyj­nej”. Źródłem tych emo­cji jest też powszech­na dość opi­nia, że to sztucz­ne, nie­po­trzeb­ne stanowisko.

Czym jest Architektura Korporacyjna (w tym jej udo­ku­men­to­wa­na postać) nie raz tu pisa­łem. Aby nie powta­rzać tych tre­ści, tu napi­sze, że – w moich oczach – klu­czo­wą korzy­ścią z posia­da­nia takiej doku­men­ta­cji jest to, że kolej­ne wdro­że­nia nowe­go opro­gra­mo­wa­nia, a czę­ściej posze­rza­nia lub zmia­ny jego funk­cjo­nal­no­ści, nie wyma­ga­ją każ­do­ra­zo­wej, kosz­tow­nej ana­li­zy przed-wdro­że­nio­wej”. W więk­szo­ści przy­pad­ków prak­tycz­nie każ­de kolej­ne wdro­że­nie IT to ana­li­za sta­nu obec­ne­go” wyko­ny­wa­na przez dostaw­cę lub po stro­nie kupu­ją­ce­go, do tego kolej­ny etap czy­li ana­li­za potrzeb i spe­cy­fi­ko­wa­nie wyma­gań. Czy to zawsze musi być robio­ne od zera? Nie. Mając model cało­ści” w dowol­nym momen­cie może­my go użyć jako doku­men­ta­cji sta­nu obec­ne­go”, zaś fakt, że model archi­tek­tu­ry kor­po­ra­cyj­nej pozwa­la szyb­ko uak­tu­al­nić obszar mode­lu biz­ne­so­we­go” i na jego pod­sta­wie opi­sać to cze­go ocze­ku­je­my w związ­ku z tym” pro­wa­dzi do nie­ma­łych oszczęd­no­ści cza­su i pie­nię­dzy przy każ­dym wdrożeniu.

Kim jest ten, kto to ma na gło­wie”? Poniżej frag­ment pew­nej dys­ku­sji na forum o tym kim jest ów Architekt (pole­cam zaj­rze­nie do całej dys­ku­sji, tu cytu­ję jeden z moich wpisów):

Dla upo­rząd­ko­wa­nia przy­to­czę dia­gram, dość powszech­nie cyto­wa­ny i uznawany:

źr. Busnes Process Trends http://www.bptrendsassociates.com/
źr. Busnes Process Trends http://​www​.bptrend​sas​so​cia​tes​.com/

(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

ISO to naj­niż­sza war­stwa (naj­niż­sza abso­lut­nie nie zna­czy naj­mniej waż­na, bo jest raczej odwrot­nie), z regu­ły w fir­ma doku­men­to­wa­na i zarzą­dza­na jest tyl­ko ta naj­niż­sza warstwa.

Architektura kor­po­ra­cyj­na to abs­trak­cja (model, zestaw sko­ja­rzo­nych ze sobą dia­gra­mów) łączą­ca czu­bek tej pira­mi­dy z jej dołem, głów­nie pro­ce­sy biz­ne­so­we (one są zawsze abs­trak­cją), jeże­li dys­po­nu­je­my udo­ku­men­to­wa­nym sta­nem war­stwy imple­men­ta­cji (coraz czę­ściej spo­ty­ka­ny, tu ISO, COBIT, ITIL itp.) oraz (to aku­rat rzad­kie) dobry model war­stwy stra­te­gii (np. Business Motivation Model) i całość potra­fi­my połą­czyć od samej góry do same­go dołu (śla­do­wa­nie, wza­jem­ne wyni­ka­nie od ogó­łu do szcze­gó­łu) to teraz dopie­ro mamy moż­li­wość testo­wa­nia wpły­wu np. zmia­ny pro­ce­du­ry na reali­za­cję stra­te­gii albo wska­zać jakiej nowej usłu­gi w IT (ana­li­za wyma­gań) i nowych pro­ce­dur i kadr, będzie wyma­ga­ła np. zmia­na okre­ślo­nej taktyki.

Jeżeli fir­ma jest mała, w zasa­dzie dobry pre­zes da rade sam z note­sem, w mia­rę wzro­stu zło­żo­no­ści fir­my (orga­ni­za­cji) takie ana­li­zy wpły­wu zaczy­na­ją być coraz trud­niej­sze bez mode­li fir­my i dobrych narzę­dzi (zarzą­dza­nie kil­ku­dzie­się­cio­ma dia­gra­ma­mi, związ­ka­mi mie­dzy ich obiek­ta­mi itp).

W moich oczach Architekt Korporacyjny to oso­ba która:

  • potra­fi, jako ana­li­tyk, zbu­do­wać taki model (bez prze­sa­dy ze szczegółowością),
  • potra­fi go zako­mu­ni­ko­wać” zarządowi
  • zarzą­dza zmia­ną mode­lu, to jest na pyta­nie zarzą­du co będzie gdy…” odpo­wia­da natych­miast”, po pod­ję­ciu przez zarząd decy­zji wpły­wa­ją­cych na model, uak­tu­al­nia go.

(Opis sta­no­wi­ska pra­cy archi­tek­ta kor­po­ra­cyj­ne­go – Architekci IT – GoldenLine​.pl).

Tak więc moim zda­niem, celem jest ta doku­men­ta­cja (zawsze aktu­al­ne mode­le) a nie posia­da­nie” w zaso­bach Architekta Korporacyjnego. Wydaje mi się, że ten spo­koj­nie może być kon­trak­to­wym ana­li­ty­kiem na 1/n eta­tu lub na nie­du­żym ryczał­to­wym wyna­gro­dze­niu, za utrzy­ma­nie Architektury Korporacyjnej jako zesta­wu mode­li i zarzą­dza­nie zmia­ną tych mode­li (nowe projekty).

Bardzo cie­ka­wy arty­kuł o roli EA uka­zał się na stro­nach MSDN:

An enter­pri­se architect?s role is mul­ti-face­ted and extre­me­ly dyna­mic. Not only must they keep track of IT con­cerns, but also tho­se of the busi­ness. Through the work per­for­med on stra­te­gic ini­tia­ti­ve, EAs stri­ve to make ali­gn­ment betwe­en IT and the busi­ness more trans­pa­rent. (A Day in the life of an Enterprise Architect).

Podsumowaniem tego arty­ku­łu (pole­cam cały) może zaczerp­nię­ty z nie­go dia­gram (pozio­mo roz­le­głość wie­dzy, pio­no­wo jej głębokość):

Tak więc AK jest to ktoś, kto rozu­mie całość ale nie musi (nawet nie powi­nien) być tym, kto ją imple­men­tu­je, gdyż tu tak­że waż­ne jest roz­dzie­le­nie roli pro­jek­tu­ją­ce­go od wdra­ża­ją­ce­go. Role te mają nie raz sprzecz­ne inte­re­sy: im głę­biej w szcze­gó­łach tkwi dana rola (np. deve­lo­per) tym bar­dziej w jej inte­re­sie leży utrzy­ma­nie sta­tus quo, mniej­szą ma skłon­ność do wpro­wa­dza­nia zmian.

A po co nam ten SWOT

W poprzed­nim arty­ku­le (Ile jest tych wyma­gań na sys­tem ERP) pisa­łem, że nad­mier­ne sku­pia­nie się na szcze­gó­łach nie tyl­ko nie wno­si nicze­go do pro­jek­tu ale nie raz wręcz go nisz­czy. Dotyczy to zresz­tą ogól­nie pro­jek­tów ana­li­tycz­nych, nie tyl­ko w dzie­dzi­nie IT.

Na stro­nach jed­ne­go z bar­dziej poczyt­nych ser­wi­sów o ana­li­zie IT – http://​www​.moder​na​na​lyst​.com – poja­wił się jakiś czas temu cie­ka­wy arty­kuł o ana­li­zie SWOT. Autor opi­su­je jak tę ana­li­zę prze­pro­wa­dzić, ja opi­szę jak jej użyć w ana­li­zie sys­te­mo­wej orga­ni­za­cji i spe­cy­fi­ko­wa­niu wyma­gań. We wstę­pie arty­ku­łu czytamy:

Much of the busi­ness of busi­ness ana­ly­sis is in the deta­ils, and most busi­ness ana­ly­sts are by natu­re deta­iled, sys­te­ma­tic thin­kers. Occasionally most orga­ni­za­tions, tho­ugh, have times when they can?t see the forest for the tre­es. That is when the high-level, bro­ad-ran­ge view that SWOT Analysis affords is just as use­ful in avo­iding costly errors as unam­bi­gu­ous requ­ire­ments. (What is SWOT Analysis?).

W dużym uprosz­cze­niu: wie­lu ana­li­ty­ków sku­pia się od razu na szcze­gó­łach, bo to natu­ral­ne ele­men­ty nasze­go bez­po­śred­nie­go oto­cze­nia, nie potra­fią spoj­rzeć na orga­ni­za­cję z dale­ka, nie potra­fią dostrzec lasu patrząc na poje­dyn­cze drze­wa”. Analiza SWOT pozwa­la spoj­rzeć na pro­blem z innej, wyż­szej per­spek­ty­wy, sze­rzej, dzię­ki cze­mu jest bar­dzo uży­tecz­na w uni­ka­niu kosz­tow­nych błę­dów jaki­mi są nie­jed­no­znacz­ne wymagania. 

Jednym z zabój­ców pro­jek­tów” (a kon­kret­nie ich budże­tów i har­mo­no­gra­mów) są tak zwa­ne wyma­ga­nia osie­ro­co­ne i wyma­ga­nia nie­od­kry­te na eta­pie ana­li­zy. Są to odpo­wied­nio wyma­ga­nia zgło­szo­ne do spe­cy­fi­ka­cji i zre­ali­zo­wa­ne, z któ­rych następ­nie nikt nie korzy­sta, oraz te odkry­wa­ne dopie­ro na eta­pie wdro­że­nia. Nie da się zapro­jek­to­wać” lasu myśląc o drze­wach bo celem jest las, a nie kon­kret­ne drzewa. 

Jeden pro­jekt może mieć jeden cel, jeże­li jed­nak celem” ma być każ­dy kolej­ny krok, podróż nigdy się nie kończy.

Wymagania o jakich pisa­łem w poprzed­nim arty­ku­le to wyma­ga­nia wobec roz­wią­za­nia, któ­rym było jakieś opro­gra­mo­wa­nie”. Jednak to dru­gi etap ana­li­zy. Generalnie naj­pierw ana­li­zu­je się i defi­niu­je wyma­ga­nia biz­ne­so­we, a potem dopie­ro wyma­ga­nia wobec roz­wią­za­nia, wie­dząc już jakie warun­ki musi ono speł­niać. Przykładowym wyma­ga­niem biz­ne­so­wym może być pod­nie­sie­nie jako­ści obsłu­gi klien­ta (co by to tu teraz nie mia­ło zna­czyć), a dopie­ro reko­men­do­wa­nym roz­wią­za­niem może być, np. opro­gra­mo­wa­ne CRM albo reor­ga­ni­za­cja dzia­łu sprze­da­ży (co z resz­tą wie­le firm robi znacz­nie czę­ściej niż kupu­je nowy CRM ;)).

Wiele firm rzu­ca się na pro­jek­ty od razu z zało­że­niem, że musi­my mieć nowe opro­gra­mo­wa­nie”. Co nie raz bywa dużym błę­dem i masą zmar­no­wa­nych środ­ków. Jak się przed tym ustrzec?

Warto popa­trzeć na orga­ni­za­cję i kon­kret­ny pro­blem z pew­nej per­spek­ty­wy, z wyż­sze­go pozio­mu abs­trak­cji, niż tyl­ko sto­jąc mię­dzy biur­ka­mi widząc kon­kret­ne spra­wy i ludzi się nimi zaj­mu­ją­cy­mi. Narzędziem pozwa­la­ją­cym wznieść” się na wyż­szy poziom abs­trak­cji jest wła­śnie ana­li­za SWOT. Analiza ta pole­ga na ziden­ty­fi­ko­wa­niu czte­rech klu­czo­wych ele­men­tów wpły­wa­ją­cych na orga­ni­za­cję : czyn­ni­ki zewnętrz­ne jaki­mi są oka­zje i zagro­że­nia oraz czyn­ni­ki wewnętrz­ne czy­li sil­ne i sła­be stro­ny orga­ni­za­cji. Tu waż­na infor­ma­cja, ana­li­za SWOT to ana­li­za cze­goś kon­kret­ne­go” w okre­ślo­nym śro­do­wi­sku”. Czynniki wewnętrz­ne opi­su­ją to coś”, zaś czyn­ni­ki zewnętrz­ne opi­su­ją śro­do­wi­sko tego cze­goś”. Można tak ana­li­zo­wać orga­ni­za­cję (np. fir­ma i jej oto­cze­nie ryn­ko­we) czy też pro­duk­ty pro­jek­tów (np. kon­kret­ne opro­gra­mo­wa­nie w fir­mie) ale nie sam pro­jekt wdro­że­nio­wy czy pro­ces (one nie są czymś”).

Analiza SWOT może być ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji. Analiza SWOT to np. wstęp do opra­co­wa­nia reko­men­da­cji w odpo­wie­dzi na pro­blem biz­ne­so­wy. SWOT to iden­ty­fi­ka­cja i wpływ okre­ślo­nych ele­men­tów, pozo­sta­je oce­na tego jaki, i na co. Dlatego ana­li­za SWOT sta­ła się czę­ścią tak zwa­ne­go Modelu Motywacji Biznesowej (BMM). Model ten pozwa­la lepiej zro­zu­mieć oto­cze­nie pro­ble­mu” oraz śla­do­wać” ele­men­ty ziden­ty­fi­ko­wa­ne w ana­li­zie SWOT na kon­kret­ne pro­ce­sy biz­ne­so­we i struk­tu­rę organizacyjną.

SWOT

(dia­gram BMM: ana­li­za SWOT i przej­ście na pro­ce­sy biz­ne­so­we opr. wła­sne autora).

Z poprzed­nich moich arty­ku­łów wie­my, że wyma­ga­nia wobec roz­wią­za­nia (w tym wobec opro­gra­mo­wa­nia) mają swo­je źró­dło w pro­ce­sach biz­ne­so­wych i ich wyko­naw­cach. Jednak spi­sa­nie ich w posta­ci dekla­ra­tyw­nej listy pod­czas warsz­ta­tów i wywia­dów, pro­wa­dzi do powsta­nia dłu­giej i prak­tycz­nie nie­we­ry­fi­ko­wal­nej listy o jakiej pisa­łem w Ile jest tych wyma­gań na sys­tem ERP.

Lekarstwem na pro­blem jest wery­fi­ka­cja (two­rze­nie) listy wyma­gań wobec roz­wią­za­nia. Weryfikacja (dia­gram powy­żej) pole­ga na tak zwa­nym śla­do­wa­niu. Śladowanie to wywo­dze­nie każ­de­go wyma­ga­nia z pier­wot­nej potrze­by, jaką jest tak­ty­ka, któ­rą przy­ję­to by osią­gnąć cel. Taktyka ma swo­je źró­dło w stra­te­gii (tak­ty­ka imple­men­tu­je stra­te­gię). Strategia (jej skon­stru­owa­nie) jest odpo­wie­dzią na oka­zję ryn­ko­wą, któ­ra jest przy­czy­ną, dla któ­rej podej­mu­je­my dzia­ła­nia ryn­ko­we. Okazja ryn­ko­wa daje szan­sę na zysk” (pro­dukt dają­cy docho­dy) w posta­ci dostar­cze­nia swo­je­mu oto­cze­niu war­to­ści doda­nej. Warto tu zwró­cić uwa­gę na to, że ele­men­ty ana­li­zy SWOT tak­że powin­ny mieć swo­je uza­sad­nie­nie w posta­ci iden­ty­fi­ka­cji zewnętrz­nych i wewnętrz­nych czyn­ni­ków wpły­wu. Słabe stro­ny oraz zagro­że­nia powin­ny iden­ty­fi­ko­wać ryzy­ka pro­jek­tu. Analizę uzna­je­my za zakoń­czo­ną po ziden­ty­fi­ko­wa­niu wszyst­kich zna­nych klu­czo­wych czyn­ni­ków wpły­wu i ryzyk. Analiza taka jest ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji.

Wielu wła­ści­cie­li firm, ich zarzą­dy, pomi­ja ten etap w pro­jek­tach z uwa­gi na swo­je prze­ko­na­nie, że ich dotych­cza­so­we dzia­ła­nia i chęć ich kon­ty­nu­acji, nie wyma­ga­ją żad­nej korek­ty, ocze­ku­ją poda­nia na tacy opi­su narzę­dzia, któ­re­go – jak sądzą – potrze­bu­ją. Zachowują się jak pacjen­ci, któ­rzy mimo, że ostat­nie bada­nia robi­li wie­le lat temu, nie dopusz­cza­ją myśli, że lekarz może im prze­pi­sać na gorącz­kę coś inne­go niż kolej­ną aspi­ry­ną. Bywa, że zbyt póź­no odkry­wa­ją, że tym razem to nie było kolej­ne przeziębienie.

Praktyka poka­zu­je, coś bar­dzo cie­ka­we­go: zamiast pro­wa­dzić żmud­ne i kosz­tow­ne wywia­dy, sesje warsz­ta­to­we, burze mózgów, któ­rych pro­duk­tem jest dłu­ga lista dość przy­pad­ko­wych pomy­słów na wyma­ga­nia”, war­to docho­dzić do listy wyma­gań meto­dą od ogó­łu do szcze­gó­łu, wła­śnie od pozio­mu ana­li­zy SWOT (opar­tej na wizji i misji orga­ni­za­cji). Takie podej­ście od razu, naj­krót­szą dro­gą, pro­wa­dzi – przez model pro­ce­sów biz­ne­so­wych – do bar­dzo spój­nej i kom­plet­nej, bez nad­mia­ro­wych (osie­ro­co­nych) wyma­gań, spe­cy­fi­ka­cji wyma­gań wobec roz­wią­za­nia. Każde wyma­ga­nie ma swo­je uza­sad­nie­nie (śla­do­wa­nie) w stra­te­gii, nie ma ryzy­ka, że coś pomi­nie­my, bo tu wery­fi­ka­to­rem jest model pro­ce­su (kom­plet­na i spraw­dzo­na lista czyn­no­ści). Koszty uzy­ska­nia spe­cy­fi­ka­cji wyma­gań tą meto­dą, są znacz­nie niż­sze niż tra­dy­cyj­ny­mi (wywia­dy) meto­da­mi bo: nie anga­żu­je­my cza­su całych zespo­łów pra­cow­ni­ków na wywia­dy i warsz­ta­ty, ryzy­ko bar­dzo kosz­tow­nych pomi­nięć i nad­mia­rów jest mini­mal­ne, licz­ba ite­ra­cji w takim pro­jek­cie zbli­ża się do JEDNEJ! i nie trze­ba odkry­wać wyma­gań meto­dą kosz­tow­nych pro­to­ty­pów na eta­pie przed­wcze­snej imple­men­ta­cji. Jedyny pro­blem” to jej prze­pro­wa­dze­nie, mimo poku­sy”, roz­po­czę­cia pro­jek­tu od razu bo nie ma cza­su na ana­li­zę, i szko­da na to pieniędzy”.

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Struktura organizacyjna jako system

Dzisiaj mała (być może) nie­spo­dzian­ka. Bardzo czę­sto mówi­my o tym, że ana­li­za biz­ne­so­wa każe nam” mode­lo­wać pro­ce­sy biz­ne­so­we by zro­zu­mieć co i jak robi dana orga­ni­za­cja. Bywa, że pró­ba mode­lo­wa­nia pro­ce­sów koń­czy się mon­stru­al­ną ilo­ścią dia­gra­mów pro­ce­sów bo klient” zawsze ma jesz­cze w zana­drzu kolej­ny, inny spo­sób zała­twie­nia spra­wy”. To pro­wa­dzi czę­sto do tak zwa­nej utra­ty pano­wa­nia nad zło­żo­no­ścią projektu”.

Przypomnę, że (wśród wie­lu) mamy dwa para­dyg­ma­ty wg. któ­rych moż­na two­rzyć mode­le orga­ni­za­cji. Najczęściej sto­so­wa­ny jest para­dyg­mat pro­ce­so­wy. Paradygmat pro­ce­so­wy zakła­da, że świat moż­na przed­sta­wić (mode­lo­wać) jako zacho­dzą­ce pro­ce­sy prze­kształ­ca­nia lub two­rze­nia rzeczywistości.

Modelowanie orga­ni­za­cji z pomo­cą pro­ce­sów zakła­da, że zna­my wszyst­kie (lub głów­ne) zda­rze­nia na jakie orga­ni­za­cja reagu­je, i potra­fi­my prze­wi­dzieć (lub narzu­cić) pro­ce­sy (łań­cuch wyda­rzeń) jakie one zaini­cju­ją. Niestety nie zawsze jest to moż­li­we. Bywa, że nasze zor­ga­ni­zo­wa­ne zaso­by reagu­ją dyna­micz­nie na ota­cza­ją­ca rze­czy­wi­stość, nie wie­my jako to się sta­nie, ale potra­fi­my narzu­cić (żądać) ocze­ki­wa­ny efekt.

Modelowanie pro­ce­sów ma sens tam, gdzie mamy do czy­nie­nia z zarzą­dza­niem zorien­to­wa­nym na pro­ce­sy. Jeżeli z jakie­goś powo­du orga­ni­za­cja dzia­ła w spo­sób zorien­to­wa­ny na samo­dziel­ność i kom­pe­ten­cje, brnię­cie w model pro­ce­sów poni­żej” mode­li end-to-end pro­wa­dzi do ogrom­nej, nie­koń­czą­cej się licz­by moż­li­wych sce­na­riu­szy. Zaryzykuje tezę, że to nie ma żad­ne­go sensu.

Wtedy war­to przejść na para­dyg­mat obiek­to­wy mode­lo­wa­nia sys­te­mu jakim jest orga­ni­za­cja. Paradygmat obiek­to­wy zakła­da, że ota­cza­ją­ca nas rze­czy­wi­stość to współ­pra­cu­ją­ce ze sobą obiek­ty, reali­zu­ją­ce wspól­ny (narzu­co­ny) cel.

Popatrzmy na dział han­dlo­wy, wie­le orga­ni­za­cji daje dużą swo­bo­dę pra­cow­ni­kom tych dzia­łów. Reagują w spo­sób zależ­ny od zasta­nej sytu­acji, ogra­ni­cze­nia jakie mają, to regu­ły pra­cy narzu­co­ne przez prze­ło­żo­nych, Ci zaś mogą korzy­stać z zade­kla­ro­wa­nych w umo­wach o pra­ce, umie­jęt­no­ściach swo­ich pod­wład­nych i współpracowników.

Wyobraźmy sobie Dział Handlowy. Nieduża fir­ma: Asystent DH, Sprzedawcy i Dyrektor Handlowy. Dział dys­po­nu­je wie­dzą o tym co sprze­da­je, jakie doku­men­ty i dla kogo wytwo­rzył oraz wie­dzą o tym jakich reguł ma przestrzegać.

Aby opra­co­wać model tego dzia­łu nale­ży użyć goto­we­go lub opra­co­wać na uży­tek tego mode­lu, dedy­ko­wa­ny model poję­cio­wy (name­spa­ce, prze­strzeń nazw). Organizacje, w któ­rych klu­czo­wym zaso­bem są ludzie oraz to co wie­dzą i potra­fią, moż­na mode­lo­wać wła­śnie jako sys­tem ele­men­tów repre­zen­tu­ją­cych wie­dzę i umie­jęt­no­ści. Skorzystajmy, po raz kolej­ny, ze słow­ni­ka języ­ka pol­skie­go PWN:

wie­dza: zasób infor­ma­cji z jakiejś dziedziny

umie­jęt­ność: prak­tycz­na zna­jo­mość cze­goś, bie­głość w czymś

Podstawą defi­ni­cji sys­te­mu jest jego gra­ni­ca. Z wie­lu powo­dów war­to wyod­ręb­nić w sys­te­mie ele­men­ty łączą­ce sys­tem z jego oto­cze­niem. Nie ma takie­go obo­wiąz­ku ale dobrą prak­ty­ką jest wyod­ręb­nie­nie ele­men­tów, któ­rych jedy­nym zada­niem jest kon­takt sys­te­mu z jego oto­cze­niem (sepa­ru­ją one wła­ści­wy sys­tem od jego oto­cze­nia). Analogicznie ma to miej­sce z nami: nasze zmy­sły słu­żą wyłącz­nie do prze­ka­zy­wa­nia bodź­ców do wnę­trza, jest to ich jedy­na rola. My oddzia­łu­je­my na oto­cze­nie tym co wytwo­rzy­my (co robimy).

Tak więc ana­li­zu­jąc dział jakiejś hipo­te­tycz­nej orga­ni­za­cji, np. pla­nu­jąc okre­śle­nie wyma­gań na sys­tem CRM, uzna­je­my ten dział za odręb­ny sys­tem do ana­li­zy, two­rzy­my jego model, upew­nia­my się, że zro­zu­mie­li­śmy jak dzia­ła. W toku ana­li­zy roz­kła­da­my dział na han­dlo­wy na trzy typy ele­men­tów: obiek­ty repre­zen­tu­ją­ce umie­jęt­no­ści, repre­zen­tu­ją­ce wie­dzę i ten sepa­ru­ją­ce sys­tem od jego otoczenia:

Dział Handllowy jako System

Jeżeli jesz­cze ktoś nie wyczuł pod­stę­pu to niniej­szym infor­mu­ję, że powyż­szy dia­gram to dia­gram klas nota­cji UML. Jego cechą jest to, że kla­sy z odpo­wied­ni­mi ste­reo­ty­pa­mi, zosta­ły przed­sta­wio­ne z pomo­cą ikon, repre­zen­tu­ją­cych te ste­reo­ty­py. Zgodnie z UML, linie prze­ry­wa­ne z gro­tem repre­zen­tu­ją związ­ki uży­cia (grot wska­zu­je na uży­ty obiekt), aso­cja­cje z peł­nym rom­bem to kom­po­zy­cje (zwią­zek całość część). Trzy opi­sa­ne poję­cia (gra­ni­ca, umie­jęt­ność, wie­dza) to pro­fil uży­ty do stwo­rze­nia tego mode­lu (dia­gra­mu). Czy taki dia­gram, jak powy­żej, jest zro­zu­mia­ły dla biznesu?

Po co to? Powyższy dia­gram to model as-is nasze­go Działu han­dlo­we­go. Teraz wystar­czy okre­ślić, jego nową postać, prze­te­sto­wać efek­ty: skut­ki ewen­tu­al­nych zmian. Jeżeli oka­że się, że reko­men­do­wa­nym roz­wią­za­niem jest nowe opro­gra­mo­wa­nie, może­my w mode­lu to-be okre­ślić, któ­re jego obiek­ty zosta­ną odwzo­ro­wa­ne w posta­ci opro­gra­mo­wa­nia (doj­dzie kolej­na kla­sa na dia­gra­mie), i któ­re umie­jęt­no­ści zosta­ną prze­su­nię­te z ludzi na oprogramowanie.

Tylko… czy­li cze­ka nas żmud­na i nie łatwa ana­li­za 🙂 sys­te­mo­wa tego działu.

A po co dia­gra­my? Nie lep­szy tekst, jak do tej pory? Mając takie mode­le, może­my pano­wać nad: spój­no­ścią, kom­plet­no­ścią, nie­sprzecz­no­ścią, pro­wa­dzić ana­li­zy wpły­wu, wypro­wa­dzić model dzie­dzi­ny sys­te­mu, i inne czy­li zamiast meto­dą prób i błę­dów pra­co­wać na opro­gra­mo­wa­niem lub reor­ga­ni­za­cją, mar­no­wać czas i środ­ki na kolej­ne pró­by, może­my od razu w spo­sób prze­my­śla­ny i bez­piecz­ny, zapro­jek­to­wać nowy lub zmie­nio­ny system.

Mam tak­że nadzie­ję, że tu widać wyraź­nie, że mode­lo­wa­nie dzie­dzi­ny sys­te­mu w posta­ci klas połą­czo­nych z pomo­cą pro­stych opi­sa­nych licz­no­ścia­mi aso­cja­cji itp., to nie model obiek­to­wy a nie­udol­na atra­pa bazy danych, któ­ra z para­dyg­ma­tem obiek­to­wym nie wie­le ma wspólnego.