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.