Krótki wpis o śladowaniu

Dobrze opra­co­wa­ny, kom­plet­ny model orga­ni­za­cji, łączy w sobie:

model moty­wa­cji biznesowej,
[[model struk­tu­ry organizacyjnej]],
model pro­ce­sów biz­ne­so­wych (wymie­nio­ny już powyżej),
model reguł biznesowych.
Elementy każ­de­go z tych mode­li są ze sobą powią­za­ne: role w pro­ce­sach są wywo­dzo­ne ze sta­no­wisk w mode­lu orga­ni­za­cyj­nym, ana­li­zo­wa­ne pro­ce­sy są wywo­dzo­ne z mode­lu moty­wa­cji, regu­ły biz­ne­so­we są koja­rzo­ne z czyn­no­ścia­mi w pro­ce­sach i wywo­dzo­ne z aktów praw­nych i wewnętrz­nych zarządzeń.

Mając tak opra­co­wa­ny kom­plet­ny model orga­ni­za­cji, zawie­ra­ją­cy śla­do­wa­nie, i odpo­wied­nie opro­gra­mo­wa­nie CASE moż­na prze­pro­wa­dzić ana­li­zę oddzia­ły­wa­nia, np. spraw­dzić na jakie oso­by w orga­ni­za­cji prze­nie­sie się zmia­na wybra­nych reguł biz­ne­so­wych. Mając model sys­te­mu infor­ma­tycz­ne­go sko­ja­rzo­ny z pro­ce­sa­mi, moż­na spraw­dzić wpływ awa­rii poszcze­gól­nych pod­sys­te­mów na pro­ce­sy biz­ne­so­we i ich skut­ki dla fir­my. Takich ana­liz moż­na wyko­nać wie­le, nie było by to moż­li­we bez tak skon­stru­owa­ne­go modelu. 

Dlatego, pod­sta­wo­wą war­to­ścią popraw­nie wyko­na­nych mode­li orga­ni­za­cji i uży­cia wła­ści­wych narzę­dzi, jest nie tyl­ko opra­co­wa­nie wyma­gań np. na opro­gra­mo­wa­nie. Możliwe jest testo­wa­nie reak­cji ele­men­tów struk­tu­ry orga­ni­za­cji na zda­rze­nia np. awa­rie. Możliwe jest opra­co­wa­nie pro­jek­tów inte­gra­cji, wymia­ny opro­gra­mo­wa­nia. Możliwe jest spraw­dze­nie na co ma wpływ np. nie­ocze­ki­wa­na obec­ność pra­cow­ni­ka. To tyl­ko wybra­ne przy­kła­dy, jed­nak moż­li­we jest to wyłącz­nie pod warun­kiem posia­da­nie popraw­nie wyko­na­ne­go modelu.

Czytaj dalej Krótki wpis o śladowaniu

UML MDA czyli od biznesu do projektu logiki systemu

To co naj­czę­ściej wzbu­dza brak zaufa­nia to teza, że moż­na prze­pro­wa­dzić ana­li­zę i pro­jek­to­wa­nie opro­gra­mo­wa­nia na papie­rze”. Programiści w więk­szo­ści uwa­ża­ją, że to nie moż­li­we (rok temu na stro­nach tego blo­ga burz­li­wa dys­ku­sja z jed­nym z nich…). W więk­szo­ści przy­pad­ków pod­czas spo­tkań (kon­fe­ren­cje, pro­jek­ty itp.) z zespo­ła­mi pro­gra­mi­stów sły­szę: czy­ta­my wyma­ga­nia, kodu­je­my od razu i two­rzy­my kolej­ne wer­sje apli­ka­cji; ina­czej się nie da”. W przy­pad­ku szko­leń, ostat­nie­go dnia warsz­ta­tów naj­czę­ściej sły­szę: ooo, w cią­gu jed­ne­go dnia [teraz] powstał kom­plet­ny pro­jekt dzie­dzi­ny sys­te­mu [cho­dzi­ło o kom­po­nent], prze­te­sto­wa­ny i oczysz­czo­ny z wąt­pli­wo­ści, bra­ku logi­ki i nie­spój­no­ści, do tego łatwy w dal­szym roz­bu­do­wy­wa­niu; to co zro­bi­li­śmy teraz na dia­gra­mach UML w cią­gu dnia, jako zespół tra­dy­cyj­ną meto­dą robi­li­by­śmy co naj­mniej tydzień, bio­rąc pod uwa­gę kodo­wa­nie każ­de­go pomy­słu by go dać użyt­kow­ni­ko­wi do testów”. W zasa­dzie taki pro­ces ana­li­zy i pro­jek­to­wa­nia jest zna­ny od lat jako [[Model Driven Architecture]] (MDA). […] Larman w swo­jej książ­ce opi­su­je nie­mal­że iden­tycz­ne podej­ście (tabe­la poni­żej). Kluczową róż­ni­cą jest jed­nak źró­dło infor­ma­cji pier­wot­nej. U Larman’a jest to model przy­pad­ków uży­cia i ich sce­na­riu­sze. W porów­na­niu z mode­lem biz­ne­so­wym, pod­le­ga­ją­cym testo­wa­niu czy wali­da­cji, całe ryzy­ko pro­jek­tu spo­czy­wa na jako­ści mode­lu przy­pad­ków uży­cia. Jeżeli powsta­ły one jako efekt np. burzy mózgów, ankie­to­wa­nia pra­cow­ni­ków zama­wia­ją­ce­go czy tak zwa­nych sesji JAD (Joint Application Development) to jest bar­dzo praw­do­po­dob­ne, że całe ryzy­ko złej jako­ści takie­go mode­lu (a jest ono bar­dzo duże jak poka­zu­je prak­ty­ka) zosta­nie prze­nie­sio­ne na projekt.

To jest wła­śnie pro­blem nazy­wa­ny użyt­kow­nik nie wie cze­go chce”. Po to się robi ana­li­zy biz­ne­so­we by w koń­cu wie­dział. Nie zmie­nia to fak­tu, że książ­kę Larman’a gorą­co pole­cam każ­de­mu pro­jek­tan­to­wi i pro­gra­mi­ście z ambi­cja­mi na meto­dy obiek­to­we i wzor­ce projektowe.

Czytaj dalej UML MDA czyli od biznesu do projektu logiki systemu

Metoda naukowa w analizie biznesowej

Po kolei:

obser­wa­cje to ana­li­za tego co i jak się w fir­mie dzie­je (ana­li­za doku­men­tów i wywiady)
budo­wa­nie hipo­te­zy to two­rze­nie mode­lu pro­ce­so­we­go tej fir­my i mode­lu jej dziedziny
eks­pe­ry­men­ty to testo­wa­nie mode­li poprzez spraw­dza­nie czy model pro­ce­su da jako pro­dukt taki sam doku­ment jak te w praktyce
przy­ję­cie lub odrzu­ce­nie hipo­te­zy oraz jej powta­rza­nie to ite­ra­cyj­ne testo­wa­nie i ulep­sza­nie mode­lu (jeśli był wadliwy)

Czytaj dalej Metoda naukowa w analizie biznesowej

Rentowność projektu czyli jego wizja i wykonywalność – należy planować

Dlaczego takich ana­liz wyko­nu­je się mało? No cóż, nie są one w inte­re­sie dostaw­cy, któ­ry twier­dzi, że jego sys­tem np. ERP jest na pew­no dobry”. Po dru­gie wie­le firm uzna­je, że ich nie doty­czy ryzy­ko pro­jek­to­we i pomi­ja­ją ana­li­zy, a te są prze­cież niczym innym jak obni­że­niem ryzy­ka nie­po­wo­dze­nia takich pro­jek­tów. Pamiętajmy, że ponad 80% pro­jek­tów wdro­że­nio­wych w IT to pro­jek­ty z sil­nie prze­kro­czo­ny­mi budże­ta­mi i ter­mi­na­mi, część z nich (sza­cu­je się je na ok. 16%) to pro­jek­ty zanie­cha­ne z tego powodu.

Każdy z Państwa sam musi sobie odpo­wie­dzieć na pyta­nie: czy 20% budże­tu jest war­te tego by chro­nić pozo­sta­łe 80%.

Czytaj dalej Rentowność projektu czyli jego wizja i wykonywalność – należy planować

Analiza przedwdrożeniowa ? czym jest

…do cze­go zmie­rzam? Do tezy, mówią­cej: sko­ro dostaw­cy opro­gra­mo­wa­nia zaczy­na­ją od opra­co­wa­nia kon­cep­cji wdro­że­nia swo­je­go pro­duk­tu, to ktoś powi­nien przed nimi opra­co­wać spe­cy­fi­ka­cje potrzeb. Aby powsta­ła spe­cy­fi­ka­cja potrzeb powi­nien ktoś zde­fi­nio­wać pro­blem, wska­zać moż­li­we roz­wią­za­nia i oce­nić jego wyko­ny­wal­ność. Nie ma tak­że sen­su szu­ka­nie pro­ble­mu na siłę tyl­ko po to, by wdro­żyć jakieś opro­gra­mo­wa­nie bo jego sprze­daw­ca tak chce. Dostawcy goto­we­go opro­gra­mo­wa­nia powin­ni się w koń­cu pogo­dzić z pro­stym ryn­ko­wym fak­tem: to oni są wybie­ra­ni a nie oni wybie­ra­ją, dokład­nie tak jak każ­dy inny pro­dukt na rynku. 

Czytaj dalej Analiza przedwdrożeniowa ? czym jest

Reguły biznesowe ? czym są?

Wiele się mówi o regułach biznesowych jednak definicja tego pojęcia nie jest taka oczywista. Czym są te reguły? Po przejrzeniu Internetu i literatury uznałem swego czasu, że podejmę próbę stworzenia takiej…

Czytaj dalej Reguły biznesowe ? czym są?

Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Istotą opi­su wyma­gań na sys­tem jest kon­tekst całe­go pro­jek­tu i tej inwe­sty­cji a kon­tek­stem tym jest model biz­ne­so­wy i zakres pro­jek­tu. Model biz­ne­so­wy moż­na wyko­nać nawet meto­da­mi for­mal­ny­mi za pomo­cą pseu­do­ko­du czy języ­ka rela­cji logicz­nych jed­nak model taki jest bez­war­to­ścio­wy, jeże­li nie sta­no­wi sobą zro­zu­mia­łe­go prze­ka­zu dla każ­de­go zaan­ga­żo­wa­ne­go w pro­jekt czy­taj szcze­gól­nie klien­ta biz­ne­so­we­go”. Kluczem do suk­ce­su jest tu mode­lo­wa­nie czy­li zobra­zo­wa­nie w spo­sób zro­zu­mia­ły dla każ­dej stro­ny w pro­jek­cie IT isto­ty biz­ne­su i jego kon­tek­stu w pro­jek­cie two­rze­nia i wdra­ża­nia opro­gra­mo­wa­nia. Model biz­ne­so­wy i wewnętrz­na struk­tu­ra zarzą­dza­nia orga­ni­za­cji to nie obiek­to­we mode­le a pro­ce­so­we mapy łań­cu­chów two­rze­nia war­to­ści w fir­mie. Model obiek­to­wy ma zasto­so­wa­nie dopie­ro pod­czas two­rze­nia mode­li infor­ma­cyj­nych czy­li struk­tu­ry danych prze­cho­wy­wa­nych i prze­twa­rza­nych w fir­mie a dane to nic inne­go jak repre­zen­ta­cja tych infor­ma­cji, któ­re fir­ma chce prze­twa­rzać oraz spo­sób w jaki chce to robić o czym wie­lu ana­li­ty­ków zda­je się zapo­mi­nać. Jak więc pro­wa­dzić ana­li­zy wymagań?

Czytaj dalej Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Analityk czyli kto?

Ten artykuł to zanonimizowana korespondencja, na często pojawiający sie temat: zakres pracy analityka. O co chodzi Dzień dobry, piszę z prośbą/pytaniem czy byłby Pan w stanie polecić książkę albo inny…

Czytaj dalej Analityk czyli kto?