Zaskoczył mnie ostat­nio jeden z moich czy­tel­ni­ków: zapy­tał mnie:

Od lat śle­dzę Pana blog i osią­gnię­cia w zakre­sie ana­li­zy sys­te­mo­wej i biz­ne­so­wej. Mimo, że nie zaj­mu­ję się zawo­do­wo mode­lo­wa­niem wyma­gań na opro­gra­mo­wa­nie sta­ra­łem się zro­zu­mie Pana podejście:

1) W pierw­szym eta­pie wyko­nu­je­my ana­li­zę biz­ne­so­wą pro­ble­mu klien­ta korzy­sta­jąc z BMM

2) Jeśli docho­dzi­my na tej pod­sta­wie do wnio­sku, że wła­ści­wym podej­ściem jest wytwo­rze­nie opro­gra­mo­wa­nia prze­pro­wa­dza­my ana­li­zę sys­te­mo­wą korzy­sta­jąc z UML i two­rzy­my model dzie­dzi­ny sys­te­mu, któ­ry jest pod­sta­wą do pro­jek­to­wa­nia i wytwa­rza­nia dedy­ko­wa­ne­go oprogramowania

Czy dobrze zrozumiałem?

Odpisałem, że tak, jed­nak war­to robić pomię­dzy punk­ta­mi 1) i 2) model fir­my opi­su­ją­cy jak ona dzia­ła, gdyż takie pro­jek­ty są bar­dzo dobry­mi momen­ta­mi na ewen­tu­al­ne reor­ga­ni­za­cje. I tu pada­ją tezy zwią­za­ne z mode­lo­wa­niem organizacji:

Przenosząc to na grunt wła­snym pro­ble­mów zawo­do­wych pró­bu­ję ana­lo­gicz­nie stwo­rzyć model postę­po­wa­nia w pro­ble­mach orga­ni­za­cyj­nych roz­wią­zy­wa­nych za pomo­cą stwo­rze­nia odpo­wied­nich pro­ce­dur postę­po­wa­nia (n.p. przy wdra­ża­niu sys­te­mów zarzą­dza­nia zgod­nych z ISO 27001, ISO 20000 i ISO 22301):

1) Podobnie jak powy­żej wyko­nu­je­my ana­li­zę biz­ne­so­wą pro­ble­mu klien­ta korzy­sta­jąc z BMM

2) Po stwier­dze­niu, że pro­blem moż­na roz­wią­zać zbio­rem pro­ce­dur prze­pro­wa­dza­my ana­li­zę orga­ni­za­cyj­ną (?) korzy­sta­jąc z BMPN i tworzymy??

No wła­śnie ? czy spo­tkał się Pan z odpo­wied­ni­kiem mode­lu dzie­dzi­ny sys­te­my w ?inży­nie­rii wyma­gań na orga­ni­za­cję?? Czyli ze zbio­rem wyma­gań na pro­ce­du­ry, któ­re powin­ny zostać wdro­żo­ne, aby roz­wią­zać okre­ślo­ny pro­blem biznesowy?

Niestety w Polsce nie spo­tka­łem, spo­ty­kam się jed­nak w lite­ra­tu­rze z teza­mi, że wdro­że­nie jakich­kol­wiek norm, nie tyl­ko jako­ści, powin­no być tak­że poprze­dzo­ne ana­li­zą. Innymi sło­wy nor­my jako­ści powin­ny być wdra­ża­ne jako odpo­wiedź (roz­wią­za­nie) na okre­ślo­ne wyma­ga­nia, a nie dla same­go fak­tu ich wdra­ża­nia. Owszem, bywa, że wyma­ga­niem jest np. wymóg prze­tar­go­wy (ofer­ty mogą skła­dać tyl­ko fir­my mają­ce okre­ślo­ny cer­ty­fi­kat), jed­nak moda na jakość, mimo że nie prze­mi­nę­ła cał­ko­wi­cie, powo­li prze­cho­dzi w racjo­nal­ne powo­dy wdra­ża­nia norm jakości.

Sam zresz­tą wdra­żam pew­ne pro­ce­du­ry w każ­dym moim pro­jek­cie, np. zaka­zu­ję” wymia­ny doku­men­tów ema­ilem, są współ­dzie­lo­ne w repo­zy­to­rium pozwa­la­ją­cym na ich wer­sjo­no­wa­nie i komen­to­wa­nie (skrzyn­ki mailo­we to jeden z naj­gor­szych spo­so­bów zarzą­dza­nia doku­men­ta­cją pro­jek­to­wą, nie tyl­ko z powo­du bra­ku pouf­no­ści). Uwagi do doku­men­tów naka­zu­ję” zgła­szać pisem­nie osob­na notat­kę, a nie w macie­rzy­stym doku­men­cie meto­dą nano­sze­nia i reje­stra­cji zmian. W tym przy­pad­ku po pro­stu nikt nie panu­je nad tre­ścią doku­men­tu, roz­my­wa się jego autor­stwo (a jako oso­ba reali­zu­ją­ca umo­wę o dzie­ło nie mogę do tego dopusz­czać), no nie moż­na mieć pew­no­ści, że ktoś okre­ślo­nych uwag nie zaakc­pe­to­wał”, cze­go już nie widać, a wyszu­ki­wa­nie zmian w nawet śred­niej wiel­ko­ści doku­men­cie, potra­fi być żmud­ne. (prze­czy­taj o wadach pra­cy z narzę­dzia­mi biu­ro­wy­mi w pro­jek­tach).

Procedury to efekt wyma­gań jakie ja sta­wiam przed pro­ce­sem ana­li­zy i pro­jek­to­wa­nia, mie­dzy innymi:

  1. musi być zacho­wa­ne jed­no­oso­bo­we autor­stwo doku­men­tów (każ­dy doku­ment ma wyłącz­nie jed­ne­go auto­ra): wpro­wa­dza­nie do nie­go zmian przez inne oso­by jest niedopuszczalne, 
  2. musi być dostęp do histo­rii prac nad doku­men­tem: uwa­gi do tre­ści, w tym pro­po­zy­cje zmia­ny, do doku­men­tów są zgła­sza­ne wyłącz­nie w try­bie zgła­sza­nia zmian” (każ­dy taki doku­ment ma tak­że jed­ne­go auto­ra: oso­bą zgłaszającą
  3. tyl­ko uza­sad­nio­ne zmia­ny pod­le­ga­ją roz­pa­try­wa­niu: każ­da uwa­ga do recen­zo­wa­nej tre­ści musi zawie­rać uza­sad­nie­nie (jakie ryzy­ko nie­sie obec­na treść, jak ją zmienić).
  4. doku­men­ty nie mogą ginąć, nie mogą byś usu­wa­ne, kolej­ne wer­sje muszą być ozna­cza­ne nume­rem wer­sji, każ­dy czło­nek zespo­łu pro­jek­to­we­go musi mieć iden­tycz­ne infor­ma­cje: musi być wdro­żo­ne współ­dzie­lo­ne repo­zy­to­rium pli­ków pro­jek­to­wych, doku­men­ty są zna­ko­wa­ne cza­sem i godzi­ną dostarczenia.
  5. musi być moż­li­wa pra­ca zdal­na bez koniecz­no­ści insta­lo­wa­nia na kom­pu­te­rze jakie­go­kol­wiek dodat­ko­we­go opro­gra­mo­wa­nia: repo­zy­to­rium pli­ków powin­no pra­co­wać poprzez prze­glą­dar­kę WWW.

Tak więc mamy okre­ślo­ne wyma­ga­nia i ich reali­za­cję (opis wyma­ga­nia i pro­ce­du­ra po dwu­krop­ku). Normalnym try­bem w więk­szych pro­jek­tach, pro­wa­dzo­na jest ana­li­za fir­my i budo­wa­ny jest jej model pro­ce­so­wy. Na nim wyszu­ku­je­my” miej­sca stwa­rza­ją­ce ryzy­ka, opi­su­je­my je. Jeżeli uzna­my, że chce­my te ryzy­ka eli­mi­no­wać lub zmniej­szać, mamy tym samym wyma­ga­nia biz­ne­so­we. Kolejny krok to opra­co­wa­nie roz­wią­za­nia, w moim przy­pad­ku powy­żej, były to trzy pro­ce­du­ry oraz wyma­ga­nie na elek­tro­nicz­ne repo­zy­to­rium. Można więc sobie wyobra­zić, że w kate­go­riach całej fir­my powsta­ną wyma­ga­nia, któ­re moż­na zre­ali­zo­wać wdra­ża­jąc kon­kret­ną nor­mę ISO.

Zastanawiam się rów­nież co taki model powi­nien zawie­rać? (ana­lo­gicz­nie do mode­lu dzie­dzi­ny systemu):

- listę ról (odpo­wied­nik obiektów/klas?)

- listę umie­jęt­no­ści danej roli (odpo­wied­nik cech obiektu/klasy?)

- listę pro­ce­dur jakie uży­wa dana rola (odpo­wied­nik metod obiektu/klasy?)

Powyższe to raczej mate­riał na model pro­ce­so­wy. Prawdą jest, że role to pew­ne obiek­ty w sys­te­mie jakim jest orga­ni­za­cja, jed­nak już ich umie­jęt­no­ści i pro­ce­du­ry to wie­dza o tym jak wyko­nać daną pra­ce, pro­ce­du­ra (jej utwo­rze­nie) to mini­ma­li­za­cja ryzy­ka, że pra­ca ta zosta­nie wyko­na­na źle. I tu przy­to­czę mój model pro­ce­su w organizacji:

Jak opisać firmę wewnątrz: model procesów biznesowychTak więc każ­dy ele­men­tar­ny pro­ces zawie­ra ele­men­ty, o któ­rych wspo­mi­na mój czy­tel­nik. Owszem model obiek­to­wy jest tu moż­li­wy do wyko­na­nia ale będzie to sta­tycz­na struk­tu­ra (któ­ra tak­że bywa potrzeb­na jako model) jed­nak model orga­ni­za­cji w posta­ci pro­ce­sów, to fun­da­ment tej doku­men­ta­cji. Proszę zwró­cić uwa­gę, że to co jest wokół pro­ce­su (pro­ce­du­ry, regu­ły biz­ne­so­we, struk­tu­ra orga­ni­za­cyj­na, zakre­sy kom­pe­ten­cji, inne) to w więk­szo­ści ele­men­ty doku­men­ta­cji sys­te­mów zarzą­dza­nia jako­ścią. Mając model pro­ce­su, po jego ewen­tu­al­nej opty­ma­li­za­cji, mamy bar­dzo dobry mate­riał do opra­co­wa­nia wyma­gań na System Zarządzania Jakością: wie­my jakie dokład­nie doku­men­ty mają powstać a jakie nale­ży zmo­dy­fi­ko­wać, wie­my po co powstają.

Zaletą takie­go postę­po­wa­nia jest moż­li­wość uza­sad­nie­nia biz­ne­so­we­go (śla­do­wa­nie) każ­de­go wyma­ga­nia. Innymi sło­wy, jeste­śmy w sta­nie wyka­zać, że każ­da pro­po­no­wa­na nowa lub zmie­nio­na pro­ce­du­ra, wspie­ra okre­ślo­ny cel biz­ne­so­wy oraz wyni­ka z napra­wy” okre­ślo­ne­go procesu.

Po prze­czy­ta­niu powyż­sze­go, w kolej­nym liście mój czy­tel­nik pisze porządkując:

Chciałbym się jesz­cze podzie­lić jed­ną obser­wa­cją a pro­pos ISO ? być może uzna Pan ją za błędną ?

Otóż aku­rat nor­ma ISO 27001, z któ­rą mam aktu­al­nie do czy­nie­nia defi­niu­je coś takie­go co nazy­wa prze­pro­wa­dze­niem ana­li­zy ryzy­ka, a efek­tem ma być plan postę­po­wa­nia z ryzy­kiem. Na począt­ku nie mogłem sobie tego wyobra­zić, ale po Pańskiej odpo­wie­dzi spra­wa wyda­je się jasna:

- na pod­sta­wie ana­li­zy orga­ni­za­cji defi­niu­je­my kla­sy­fi­ka­cję infor­ma­cji ? to defi­niu­je nor­ma ([…] punk­tem wyj­ścia są doku­men­ty i arte­fak­ty (fizycz­na reprezentacja/lokalizacja doku­men­tów), któ­re zawie­ra­ją infor­ma­cje. Przykładowo umo­wa z kon­tra­hen­tem i ofer­ta (doku­men­ty) zawie­ra wyce­nę usłu­gi (infor­ma­cja), któ­ra powin­na być chro­nio­na na okre­ślo­nym pozio­mie. Związanie doku­men­tów i ich repre­zen­ta­cji za pomo­cą ?infor­ma­cji? pozwa­la usta­lić poziom ochro­ny okre­ślo­nych doku­men­tów i ich fizycz­nych repre­zen­ta­cji i loka­li­za­cji. Z kolei poziom ochro­ny infor­ma­cji jest czy­stym wyma­ga­niem biz­ne­so­wym ? to biz­nes okre­śla jakie ?infor­ma­cje? nale­ży ?jak? chro­nić. Model ?infor­ma­cji? powi­nien pozwo­lić na pod­sta­wie kla­sy­fi­ka­cji usta­lo­nej z biz­ne­sem okre­ślić poziom ochro­ny doku­men­tów i ich fizycz­nych realizacji/lokalizacji. Stąd już pro­sta dro­ga do okre­śle­nia ryzy­ka zwią­za­ne­go z prze­twa­rza­niem doku­men­tów i spo­so­bów zabez­pie­cze­nia. Prosty przy­kład ? umo­wa (doku­ment) pozba­wio­na infor­ma­cji o warun­kach han­dlo­wych (tajem­ni­ca przed­się­bior­stwa) może mieć niż­szy poziom ochro­ny (wyni­ka­ją­cy wyłącz­nie z praw autor­skich) niż umo­wa z tymi infor­ma­cja­mi?)

- potem okre­śla­my jak są prze­twa­rza­ne infor­ma­cje, któ­re chce­my chro­nić two­rząc model orga­ni­za­cji za pomo­cą BPMN

- ana­li­zu­jąc ten model może­my usta­lić miej­sca w mode­lu prze­twa­rza­nia, gdzie wystę­pu­je ryzy­ko utra­ty bez­pie­czeń­stwa i gdzie nale­ży wdro­żyć pro­ce­du­ry kontrolne

- wte­dy mamy listę pro­ce­dur do wdro­że­nia dla kon­sul­tan­ta ISO.

Podsumowując nor­ma narzu­ca wyko­na­nie ana­li­zy orga­ni­za­cyj­nej i okre­śle­nie wyma­gań na pro­ce­du­ry. Niestety załącz­ni­ki do nor­my poda­ją przy­kła­dy takich pro­ce­dur, więc uprosz­czo­ne podej­ście kon­sul­tan­tów ISO spro­wa­dza­ło­by się do wdro­że­nia pro­ce­dur ?gotow­ców? według załącz­ni­ka do nor­my, z pomi­nię­ciem zro­zu­mie­nia co, jak i dla­cze­go nale­ży chronić.

Oczywiście punk­tem wyj­ścia jest doku­men­ta­cja klien­ta, a więc wspo­mnia­ne doku­men­ty HR, opi­sy sta­no­wisk, obo­wiąz­ków, archi­tek­tu­ra danych/systemów. Zrozumiałem, że na tej pod­sta­wie two­rzy­my dia­gram fak­tów (na pod­sta­wie, któ­re­go moż­na wyge­ne­ro­wać słow­nik) i dalej ana­li­zu­je­my jak dzia­ła orga­ni­za­cja i co nale­ży zabezpieczać.

No i mamy, naj­praw­do­po­dob­niej, goto­wy spo­sób postę­po­wa­nia. Co cie­ka­we dopie­ro po prze­czy­ta­niu tego listu zda­łem sobie spra­wę, że w wie­lu pro­jek­tach wyko­ny­wa­łem powyż­sze pra­ce, w róż­nym zakre­sie (ja już nie two­rzy­łem typo­wych dla ISO pro­ce­dur) z zupeł­nie inne­go powo­du: popra­wa jako­ści dzia­ła­nia fir­my, zanim zosta­nie wdro­żo­ne opro­gra­mo­wa­nie. Po co? Żeby nie infor­ma­ty­zo­wać bała­ga­nu. Jak widać, do pod­no­sze­nia jako­ści pro­wa­dzi wie­le dróg.

(cyta­ty pocho­dzą z listu Pana Michała Gładysza)

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. majki_84

    W arty­ku­le zain­te­re­so­wa­ło mnie w szcze­gól­no­ści podej­ście do zarza­dza­nia uwa­ga­mi do doku­men­tów. Jak to połą­czyć z budo­wą mode­lu w narzę­dziu CASE? Czy nano­si Pan wszyst­kie uwa­gi ręcz­nie, czy ma Pan jakąś meto­dę auto­ma­ty­zu­ją­cą pra­cę? Czy model w tym narzę­dziu zawie­ra całą doku­men­ta­cję zmian i mapo­wa­nie na odpo­wied­nie doku­men­ty ze zgłoszeń?

    1. Jarek Żeliński

      Robię to na dwa spo­so­by: w sytu­acjach bar­dziej sfor­ma­li­zo­wa­nych Klient dosta­je plik PDF z doku­men­tem i zwra­ca notat­kę z uwa­ga­mi w rodza­ju: Paragraf 2.2. – sprze­daw­ca po każ­dej sprze­da­ży wysta­wia fak­tu­rę VAT”, nale­ży dodać dodać fak­tu­rę lub para­gon”. I podob­ne. W przy­pad­kach mniej sfor­ma­li­zo­wa­nych VP TeamWorkServer pozwa­la na uru­cho­mie­nie mini­fo­rum dla każ­de­go dia­gra­mu. Co do śle­dze­nia histo­rii ser­wer któ­ry sto­su­je ma funk­cje ana­lo­gicz­ne do Subversion (każ­de zała­do­wa­nie nowej wer­sji jest wer­sjo­no­wa­ne). Takie podej­ście powo­du­je, ze uwa­gi są zgła­sza­ne w spo­sób bar­dziej prze­my­śla­ny i są archiwizowane.

    2. Jarek Żeliński

      Czy model zawie­ra całą doku­men­ta­cję? Otóż po wie­lu róż­nych doświad­cze­niach mogę powie­dzieć, że: pro­jekt musi mieć cel i opis tego co i po co ma powstać na każ­dym eta­pie, wobec tego uwa­gi do doku­men­tu muszą (dopusz­cza się tyl­ko takie) doty­czyć nie­zgod­no­ści z celem lub uzgod­nio­nej zawar­to­ści. Tak więc per­ma­nent­ne popraw­ki świad­czą tyl­ko o tym, że nie ma jasne­go celu, że doku­ment powsta­je meto­da prób i błę­dów. Mając kolej­ne wer­sje doku­men­tu w repo­zy­to­rium mogę porów­nać dowol­ne dwie wer­sje ze sobą i wychwy­cić róż­ni­ce (to aku­rat robi auto­mat). Co do nano­sze­nia zmian: część ana­li­tycz­na powo­łu­je się na dane źró­dło­we, więc muszą to być notat­ki pro­jek­to­we a nie to co usły­sza­łem od…”, wnio­sek o zmia­nę jest tak­że taką notat­ką i w doku­men­cie ana­li­zy powo­łu­je się na nią.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.