Krótka historia pewnego wymagania

Wprowadzenie

Zarówno w pro­jek­tach jak i w dys­ku­sjach np. na kon­fe­ren­cjach czy na LinkedIn, poja­wia się sta­le pew­ne nie­po­ro­zu­mie­nie: pro­jek­to­wa­nie to water­fall”. Myśli tak każ­dy, kto wyobra­ża sobie, że pro­jekt cze­goś to jakaś masa wszyst­kich moż­li­wych deta­li. Jednocześnie nie ja jeden widu­ję Dokumenty ana­li­zy biz­ne­so­wej” albo Dokumenty wyma­gań” zawie­ra­ją­ce set­ki pozy­cji o tre­ści sys­tem powi­nien…”, nie raz wyko­na­ne przez kry­ty­ków water fall”, któ­rzy repre­zen­tu­jąc deve­lo­pe­ra dekla­ru­ją­ce­go meto­dy agi­le”, zabez­pie­cza­ją się” przez odpo­wie­dzial­no­ścią za zakres projektu. 

Pierwsza waż­na uwa­ga: pro­jekt sys­te­mu to nie jest ani zestaw dzie­siąt­ków user sto­ry” ani deta­licz­na doku­men­ta­cja powy­ko­naw­cza! I o tym dzi­siaj będzie: abs­tra­ho­wa­nie od deta­li i jed­nak nadal zarzą­dza­nie logi­ką całości.

Poniżej wyma­ga­nie napi­sa­ne przez dział IT jed­ne­go z moich klientów:

1. System musi posia­dać wbu­do­wa­ne­go klien­ta pocz­ty elek­tro­nicz­nej obsłu­gu­ją­ce­go co naj­mniej pro­to­ko­ły IMAP i SMTP.
2. Wbudowany klient pocz­ty elek­tro­nicz­nej posia­da nastę­pu­ją­ce funkcje:
2.1. Utwórz wia­do­mość ? umoż­li­wia utwo­rze­nie nowej wiadomości,
2.2. Odpowiedz ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.3. Odpowiedz wszyst­kim ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy oraz z prze­sła­niem jej na pozo­sta­łe adre­sy ema­il wymie­nio­ne w polu Do, Do wia­do­mo­ści oraz Ukryty do wia­do­mo­ści wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.4. Prześlij dalej ? umoż­li­wia prze­sła­nie pocz­ty elek­tro­nicz­nej kolej­ne­mu odbiorcy,
2.5. Przenieś ? umoż­li­wia prze­no­sze­nie pocz­ty elek­tro­nicz­nej pomię­dzy fol­de­ra­mi na wybra­nym koncie,
2.6. Drukuj ? umoż­li­wia wydru­ko­wa­nie pocz­ty elektronicznej,
2.7. Dołącz ? umoż­li­wia dołą­cze­nie pocz­ty elek­tro­nicz­nej do spra­wy lub dokumentu,
2.8. Odbierz ? umoż­li­wia ręcz­ne ode­bra­nie pocz­ty elektronicznej,
2.9. Usuń ? umoż­li­wia usu­nię­cie wybra­nej pocz­ty elektronicznej,
2.10. Znajdź ? umoż­li­wia wyszu­ka­nie listu w fol­de­rach pocz­ty elektronicznej,
2.11. Rejestruj ? umoż­li­wia reje­stra­cję pocz­ty elek­tro­nicz­nej jako doku­men­tu w sys­te­mie w spo­sób ana­lo­gicz­ny do reje­stra­cji doku­men­tu zeskanowanego.
3. System musi udo­stęp­niać moż­li­wość kon­fi­gu­ra­cji kon­ta pocz­ty elek­tro­nicz­nej każ­de­mu użytkownikowi.
4. System zapew­nia moż­li­wość kon­fi­gu­ra­cji wie­lu kont pocz­ty elek­tro­nicz­nej dla każ­de­go użytkownika.
5. System musi umoż­li­wiać reje­stra­cję (przej­mo­wa­nie) pocz­ty elek­tro­nicz­nej przez użyt­kow­ni­ka, lub poprzez zde­fi­nio­wa­ną regu­łę (uwzględ­nia­ją­cą zapi­sa­ne­go wcze­śniej adre­sa­ta, oraz cią­głość kore­spon­den­cji w spra­wie), jako doku­men­tów w sys­te­mie z podzia­łem na treść, załącz­ni­ki i nagłówek.
6. W celu ogra­ni­cze­nia zbęd­nej dupli­ka­cji, nie­prze­ję­te maile muszą być odczy­ty­wa­ne z ser­we­ra pocz­to­we­go tyl­ko na żąda­nie użyt­kow­ni­ka (dostęp­ny listing nagłów­ków wia­do­mo­ści) i nie powin­ny być dodat­ko­wo prze­cho­wy­wa­ne w Systemie.
7. Dotyczy to rów­nież pocz­ty wysy­ła­nej przez klienta.
8. System musi umoż­li­wiać dołą­cza­nie pocz­ty elek­tro­nicz­nej do doku­men­tów lub spraw. Dołączenie musi być moż­li­we z pozio­mu klien­ta pocz­ty elek­tro­nicz­nej wbu­do­wa­ne­go w system.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę A

Inna oso­ba z tego same­go dzia­łu dodała:

1. Chcemy mieć klien­ta pocz­to­we­go w sys­te­mie, jest to wygod­ne rozwiązanie.
2. Chcemy aby klient pocz­to­wy miał moż­li­wość odczy­ta­nia i wysła­nia wia­do­mo­ści pocztowej.
3. Nie chce­my żeby EOD gro­ma­dzi­ło wszyst­kie wia­do­mo­ści syn­chro­ni­zo­wa­ne z ser­we­rem pocz­to­wym pro­to­ko­łem IMAP, a tyl­ko pobie­ra­ło nagłów­ki wiadomości.
4. Gdy użyt­kow­nik uzna, że wia­do­mość jest czę­ścią spra­wy ini­cju­je czyn­no­ści w EOD.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę B.

Świadomie poda­je źró­dło: dział IT tej instytucji.

Opublikowałem tyl­ko powyż­sze, bo resz­ta po ano­ni­mi­za­cji i tak była by pustą kart­ką (nie­ste­ty ten OPZ uka­że się dopie­ro za jakiś czas, a do tego momen­tu jest pouf­ny), ale mam nadzie­ję, że wyobra­że­nie sobie resz­ty jest dość pro­ste. I co z tym? Nic! Otóż nie jest pro­ble­mem taka for­ma wyra­że­nia wyma­gań przez Zamawiającego, bo on (biz­nes i nie tyl­ko jak widać) ina­czej nie potra­fi i nie jest to jego rola. Problemem jest uzna­nie tego za wyma­ga­nia wobec opro­gra­mo­wa­nia”. Powyższe jest raczej dopie­ro mate­ria­łem do ana­li­zy i projektowania. 

Wyobraźmy sobie teraz hipo­te­tycz­ny doku­ment wyni­ko­wy, czy­li kil­ku­na­stu (a może nawet kil­ku­dzie­się­ciu) nie­tech­nicz­nych pra­cow­ni­ków tej insty­tu­cji (księ­go­wość, admi­ni­stra­cja, itp.) z pomo­cą ana­li­ty­ka wyma­gań”, zebra­ło wyma­ga­nia, i pra­cu­jąc z edy­to­rem tek­stu w try­bie reje­stra­cji zmian, warsz­ta­to­wo, po iluś tam tygo­dniach wypra­co­wa­ło” osta­tecz­ną wer­sję wyma­gań” a potem nawet dzie­siąt­ki user sto­ry”. Ile stron będzie mia­ła taka Analiza Biznesowa Wymagań i co w niej będzie? 

Przykłady łatwo zna­leźć w Internecie:

przy­kład 1 (źr. https://​zamo​wie​nia​.mazo​via​.pl/​?​a​c​t​=​i​n​f​o​&​i​d​=​1​2​001):

Powyższe opra­co­wa­nie kosz­to­wa­ło 90 tys. zł. 

przy­kład 2 (źr. https://​plat​for​ma​za​ku​po​wa​.pl/​t​r​a​n​s​a​k​c​j​a​/​3​6​1​167):

Rozwiązanie

Od cza­su do cza­su przy­wo­łu­je tu na blo­gu podej­ście zwa­ne Model jako wyma­ga­nie” (popu­lar­ne skró­ty to: MDD – Model Driven Development, MBSE – Model Based System Engineering, MDSE – Model Driven System Engineering, o MBSE już pisa­łem ).

Kluczem są mode­le struk­tur tre­ści (doku­men­tów i ekra­nów GUI) . Powyższe życze­nia” jako spi­sa­ne wyma­ga­nia to (w peł­nej wer­sji) ogrom­na lista życzeń, nie pod­da­ją­ca się żad­nej kon­tro­li spój­no­ści i kom­plet­no­ści. Proszę podej­rzeć wska­za­ne wyżej przy­kła­dy, doku­men­ty na ponad 200 stron nie pod­da­ją­ce się żad­nej kon­tro­li… (pomi­jam, że wadli­we for­mal­nie, jeśli cho­dzi o uży­cie deka­ro­wa­nej notacji). 

Poniżej zamien­nik wyłącz­nie powyż­sze­go o poczcie elek­tro­nicz­nej, wyra­żo­ny mode­lem struk­tu­ry tre­ści. Jaką ma to zale­tę? Tę, że mamy zamknię­tą struk­tu­rę tre­ści i może­my ją mapo­wać na inne doku­men­ty (ich sza­blo­ny w pro­jek­cie) w celi wery­fi­ka­cji logi­ki spójności. 

Zakresy danych nie reali­zu­ją­ce logi­ki biz­ne­so­wej (i mało ryzy­kow­ne jeśli cho­dzi o pra­co­chłon­ność) moż­na mar­ko­wać z dokład­no­ścią do roli dane­go zesta­wu danych (poni­żej obsza­ry ozna­czo­ne linia prze­ry­wa­ną). Zgodnie z defi­ni­cją, sys­te­my infor­ma­cyj­ne prze­twa­rza­ją dane, więc dowol­ny sys­tem infor­ma­cyj­ny jest spro­wa­dzal­ny do skoń­czo­nej licz­by infor­ma­cji wyra­ża­nej jako doku­ment gru­pu­ją­cy okre­ślo­ne dane i reguł ich prze­twa­rza­nia . Rzecz w tym, że nie jest to baza danych i rela­cyj­ny model” (nie­ste­ty mono­lit moż­li­wy do wypra­co­wa­nia meto­dą water­fall), a odręb­ne doku­men­ty i ich struk­tu­ry (oraz słow­ni­ki zna­czeń uży­tych nazw). Każdy z nich może być pod­sta­wą opra­co­wa­nia odręb­ne­go, moż­li­we­go do samo­dziel­ne­go wyko­na­nia, modułu. 

Warto wie­dzieć, że:

Model rela­cyj­ny danych: zapi­sy­wa­nie ich w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, jest pozba­wio­ny kon­tek­stu , nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokument, tak­że w sen­sie praw­nym, nie może być gene­ro­wa­ną dyna­micz­nie (zapy­ta­nia SQL do bazy rela­cyj­nej) struk­tu­rą, bo jest wte­dy wir­tu­al­nym bytem, a taki nie sta­no­wi doku­men­tu w pra­wie (Kodeks Cywilny), nie da się tak­że zarzą­dzać jego cyklem życia. Dlatego doku­men­ty są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD i uzu­peł­nia­ne posta­cią ??do czy­ta­nia i dru­ku? w for­ma­cie pdf (real­nie sa to pli­ki pdf z załą­czo­ny­mi wer­sja­mi XML. (źr. Informacje dla korzy­sta­ją­cych z moich opra­co­wań – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Poniżej pro­sty model listy ode­bra­nych maili”:

Wymagania doty­czą­ce pra­cy z pocz­ta elek­tro­nicz­ną obra­zu­je ten oto – wery­fi­ko­wal­ny – model struk­tu­ry tre­ści otrzy­ma­nej mailem:

Aby poka­zać jak to dzia­ła” pisze­my sce­na­riusz (spe­cy­fi­ka­cja przy­pad­ku uży­cia) sta­no­wią­cy kon­tekst uży­cia tego doku­men­tu (for­mu­la­rza). Służy on tak­że jako test pro­jek­to­wa­nej logi­ki, a póź­niej jako test odbior­czy goto­we­go produktu: 

1. Pracownik wybie­ra opcję Poczta Elektroniczna
2. SYSTEM wyświe­tla Lista prze­sy­łek ema­il dla zalo­go­wa­ne­go użytkownika
3. Pracownik kli­ka wybra­na pozy­cje na liście ,
4. SYSTEM wyświe­tla Treść Poczty Elektronicznej
5. Pracownik dekre­tu­je ją lub ozna­cza do usu­nię­cia OK
6. if dekretacja
6.1. wska­za­nie punk­tu kan­ce­la­ryj­ne­go i OK
7. else if usuń
end if 
8. SYSTEM sys­tem potwier­dza operacje

W tym momen­cie będę koń­czył, bo kon­ty­nu­ację czy­tel­nik znaj­dzie w jed­nym z wcze­śniej­szych arty­ku­łów, frag­ment poniżej: 

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up?y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD jest wystar­cza­ją­ca. Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wie­lo­krot­nie. (źr. Modele infor­ma­cyj­ne – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

Źródła

Šilingas, D., & Butleris, R. (2009). Towards imple­men­ting a fra­me­work for mode­ling softwa­re requ­ire­ments in MagicDraw UML. Information Technology and Control, 38(2).
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.

Jak wyglądają przetargi?

Dzisiaj krót­ko. Frustracja dostaw­ców opro­gra­mo­wa­nia chy­ba nara­sta, bo tek­sty takie jak poni­żej, poja­wia­ją się coraz czę­ściej. Rzecz w tym, że rynek IT to nie tyl­ko fir­my ja te, repre­zen­to­wa­ne przez auto­ra tego tek­stu, któ­ry słusz­nie zauwa­ża, że:

1) Specyfikacje są napi­sa­ne bar­dzo ogól­ni­ko­wo. Trudno roze­znać się co autor miał na myśli.To jeden z naj­więk­szych pro­ble­mów w IT, zna­ny jako pro­blem huś­taw­ki. Kto bowiem pisze OPZ (Opis Przedmiotu Zamówienia) czy też SIWZ (Specyfikację Istotnych Warunków Zamówienia)? ? naj­czę­ściej dosta­je to zada­nie urzęd­nik. Urzędnik zara­bia znacz­nie poni­żej śred­niej w bran­ży IT. Nawet jeśli to infor­ma­tyk, na co przy zarob­kach urzęd­ni­ków szan­sa jest mini­mal­na) to jest mała szan­sa, że zna się i na stro­nach inter­ne­to­wych, apli­ka­cjach mobil­nych, hostin­gu i wszyst­kich roz­wią­za­niach SaaS. Pierwsza opcja to, że prze­klei to co znaj­dzie w inter­ne­cie (w innych prze­tar­gach). Druga opcja, to że wybie­rze dostaw­ce i dosta­nie spe­cy­fi­ka­cję od nie­go. A zapew­niam Was, że dostaw­ca zadba, by w OPZ czy SIWZ zna­la­zły się zapi­sy pre­fe­ru­ją­ce jego roz­wią­za­nie. Istnieje opcja trze­cia, czy­li wyna­ję­cie nie­za­leż­ne­go kon­sul­tan­ta. Zdarzało mi się być w takiej roli. Naprawdę tyl­ko bar­dzo świa­do­mi klien­ci wie­dzą, że nie­za­leż­ny kon­sul­tant musi być dobrze wyna­gra­dza­ny za swo­ją nie­za­leż­ność i eks­perc­ką wie­dzę. Dostępność kon­sul­tan­tów jest też bar­dzo nie­wiel­ka a mało któ­ra insty­tu­cja ma na nich prze­wi­dzia­ne budże­ty. (źr: Milion zło­tych za stro­nę www. Jak wyglą­da­ją prze­tar­gi? | INNPoland​.pl).

Od sie­bie dodam, że w moich oczach to nie tyle pro­blem w wyna­gro­dze­niu urzęd­ni­ka, a w tym, że pisa­nie OPZ to nie jest jego rola i kom­pe­ten­cja. Literatura przed­mio­tu (rola urzę­du w Państwie) zawie­ra wie­le róż­nych roz­wa­żań na ten temat, 

ja jed­nak zga­dzam z auto­ra­mi, któ­rzy twier­dzą, że rolą urzę­du jest wyko­ny­wa­nie pra­wa i wszel­kie dzia­ła­nia urzęd­ni­ka powin­ny być sto­so­wa­niem pra­wa. Jeżeli jakieś dzia­ła­nie nie jest sto­so­wa­niem pra­wa, urzęd­nik powi­nien zasię­gać opi­nii biegłego.

Urzędnicy (refe­ren­ci) powin­ni być z wykształ­ce­nia praw­ni­ka­mi (pra­wo admi­ni­stra­cyj­ne) z powo­dów oczy­wi­stych: sto­so­wa­nie pra­wa wyma­ga jego rozu­mie­nia. Polecam dosko­na­ły arty­kuł, któ­re­go frag­ment zacytuję:

Jeżeli twój praw­nik rozu­mie kon­trakt lepiej niż twoi ludzie z biz­ne­su, ozna­cza to że zarów­no praw­nik może mieć pro­blem z tłu­ma­cze­niem praw­nych kom­po­nen­tów całej trans­ak­cji, ale tak­że że twój biz­nes w nie­wła­ści­wy spo­sób komu­ni­ku­je praw­ni­ko­wi cele i zało­że­nia biz­ne­su, któ­re­go umo­wa doty­czy. Może czas coś z tym zro­bić? (źr. https://www.linkedin.com/pulse/tw%C3%B3j-prawnik-rozumie-kontrakt-lepiej-ni%C5%BC-twoi-ludzie-warchol-lewicka/ )

W sądzie spra­wa jest czy­sta”: sędzia nie może wyda­wać opi­nii innych niż praw­ne, kwe­stie spe­cja­li­stycz­ne musi zle­cać bie­głe­mu (dowód z opi­nii biegłego). 

Ludziom wmó­wio­no, że oso­bą wła­ści­wą do opi­su wyma­gań na opro­gra­mo­wa­nie jest przy­szły użyt­kow­nik. Nic bar­dziej błęd­ne­go: ma on takim sam kon­flikt inte­re­su jak dostaw­ca opro­gra­mo­wa­nia. Swego cza­su pisałem:

Ogłaszający taki prze­targ zapła­ci za:

  1. pra­wo korzy­sta­nia z Aplikacji (w usta­lo­nej fir­mie np. licencji),
  2. wszel­kie koniecz­ne usłu­gi poprze­dza­ją­ce nor­mal­ne użyt­ko­wa­nie Aplikacji,
  3. jeże­li na ryn­ku nie jest ofe­ro­wa­ne wyma­ga­ne opro­gra­mo­wa­nie, zosta­nie ono ?napi­sa­ne? na pod­sta­wie Specyfikacji spe­cjal­nie dla Zamawiającego.

[…] To co nazy­wa­my Opi­sem Przed­mio­tu Zamó­wie­nia jest czymś wię­cej niż tyl­ko Spe­cy­fi­ka­cja opro­gra­mo­wa­nia. Dobrą prak­ty­ką jest roz­dzie­la­nie tych trzech powyż­szych ele­men­tów, ogrom­ną wygo­dą jest jeże­li są to odręb­ne umo­wy lub odręb­ne załącz­ni­ki Umo­wy głów­nej. Spla­ta­nie razem tych aspek­tów naj­czę­ściej pro­wa­dzi do nie­po­ro­zu­mień, pro­ble­mów z inter­pre­ta­cją umo­wy w cza­sie spo­rów. W skąd­inąd cie­ka­wym arty­ku­le pew­na kan­ce­la­ria wska­zu­je przy­czy­ny, a jako roz­wią­za­nie pro­ble­mu wska­zu­je jedy­nie pra­wo do wyco­fa­nia sie z umo­wy:Nie ma recep­ty na popraw­ne opi­sa­nie przed­mio­tu świad­cze­nia. Jeśli mamy roz­bu­do­wa­ne, pre­cy­zyj­ne spe­cy­fi­ka­cje, to i tak musi­my w umo­wie opi­sać zarzą­dza­nie zmia­ną, ze szcze­gól­nym uwzględ­nie­niem roli ana­li­zy. (źr. Przedmiot Zamówienia – instruk­cja nie tyl­ko dla praw­ni­ków, na zupę pomi­do­ro­wą | | Jarosław Żeliński IT-Consulting)

Biorąc pod uwa­gę powyż­sze oraz to, że mowa tu o pro­duk­tach inży­nier­skich (opro­gra­mo­wa­nie) reko­men­du­je się:

  1. Opracowanie OPZ w posta­ci pre­cy­zyj­nych sche­ma­tów blo­ko­wych i wzo­rów mate­ma­tycz­nych, jest zawsze lep­sze niż nie­jed­no­znacz­ny opis wyko­na­ny języ­kiem natu­ral­nym, ten może być co naj­wy­żej uzu­peł­nie­niem lub komen­ta­rzem. Ideałem jest tu pre­cy­zyj­na doku­men­ta­cja tech­nicz­na (pro­jekt tech­nicz­ny). Należy pamię­tać, że taki OPZ (w odróż­nie­niu od SIWZ) jest zawsze przed­mio­tem pra­wa autor­skie­go (Koralewski, 2014).*
  2. OPZ, będą­cy doku­men­tem tech­nicz­nym, spe­cja­li­stycz­nym, nie musi być zro­zu­mia­ły dla praw­ni­ka, a nie raz nawet dla same­go Zamawiającego.
  3. Jeżeli sam zama­wia­ją­cy nie potra­fi stwo­rzyć popraw­ne­go OPZ, powi­nien naj­pierw zle­cić usłu­gę opra­co­wa­nia OPZ, a potem dopie­ro szu­kać dostaw­cy tego, co opi­sa­no w tym OPZ. (Urząd Zamówień Publicznych, 2009).
  4. Usługa tech­nicz­na, ocze­ki­wa­ny spo­sób jej świad­cze­nia, i jakość, to tak­że przed­miot zamó­wie­nia, sku­tecz­ną prak­ty­ką jest więc umiesz­cze­nie ich opi­su w OPZ a nie w tre­ści umowy.(Urząd Zamówień Publicznych, 2009)

Nieco ponad dwa lata temu napi­sa­łem, że od lat sto­su­ję w swo­ich ana­li­zach i pro­jek­tach (mię­dzy inny­mi) róż­ne­go rodza­ju dia­gra­my. Pomagają one usta­lić pre­cy­zyj­nie wszel­kie aspek­ty i praw­ne i pro­jek­to­we (źr. Opis przed­mio­tu zamó­wie­nia | | Jarosław Żeliński IT-Consulting)

Powyższe to kil­ka zebra­nych myśli, w odpo­wie­dzi na tekst auto­ra cyto­wa­ny na począt­ku. Ja adre­su­ję ten tekst Zamawiającym, bo to oni są bene­fi­cjen­ta­mi tego co zama­wia­ją i są tak­że spon­so­ra­mi swo­ich, nie­jed­no­krot­nie, pora­żek. Jak słusz­nie zauwa­ża autor: na wła­sne życzenie. 

Opis przedmiotu zamówienia

Nieco ponad dwa lata temu napi­sa­łem, że od lat sto­su­ję w swo­ich ana­li­zach i pro­jek­tach (mię­dzy inny­mi) róż­ne­go rodza­ju dia­gra­my. Pomagają one usta­lić pre­cy­zyj­nie wszel­kie aspek­ty i praw­ne i pro­jek­to­we w umo­wach, do cze­go gorą­co zachę­cam. Niestety wie­lu praw­ni­ków przyj­mu­je za cel swo­jej pra­cy ?obu­do­wa­nie? para­gra­fa­mi tego, cze­go żąda­ją od nich w umo­wach ich klien­ci. Owszem fir­my pła­cą praw­ni­kom za to, że Ci chro­nią ich inte­res, ale wie­le z tych umów to nie­ste­ty mani­pu­la­cje i korzy­sta­nie z nie­wie­dzy part­ne­ra, nie raz z jego gor­szej zna­jo­mo­ści (nie­zro­zu­mie­nia) pra­wa. ?(Żeliński, 2017)?

W tym arty­ku­le kil­ka uzu­peł­nień, gdyż uwa­żam że war­to nie zapo­mi­nać o tym, że ter­min ten (Opis Przedmiotu Zamówienia, dalej OPZ) nie doty­czy tyl­ko (jak się potocz­nie uwa­ża) Zamówień Publicznych.

Jednak Prawo Zamówień Publicznych ład­nie” opi­su­je czym jest OPZ. A celem jest tu zachę­ta do tego, by OPZ zawsze wyłą­czać z tre­ści umo­wy, jako jej załącz­nik. Na począ­tek pole­cam w tym miej­scu świet­ny tekst napi­sa­ny okiem prawnika:

Zdarza się wam cza­sem otwo­rzyć plik z umo­wą i po przej­rze­niu kil­ku aka­pi­tów zasta­na­wiać się czy aby na pew­no posłu­gu­je­cie się tym samym języ­kiem? Lękiem napa­wa już sam para­graf z defi­ni­cja­mi, któ­ry koń­czy się na?czwartej stro­nie? A kolej­ne nasu­wa­ją sko­ja­rze­nia z sza­tań­ski­mi wer­se­ta­mi? […] Jeżeli twój praw­nik rozu­mie kon­trakt lepiej niż twoi ludzie z biz­ne­su, ozna­cza to że zarów­no praw­nik może mieć pro­blem z tłu­ma­cze­niem praw­nych kom­po­nen­tów całej trans­ak­cji, ale tak­że że twój biz­nes w nie­wła­ści­wy spo­sób komu­ni­ku­je praw­ni­ko­wi cele i zało­że­nia biz­ne­su, któ­re­go umo­wa doty­czy. Może czas coś z tym zro­bić? ?(Lewicka, 2018)?

Prawnik to nie jest oso­ba, któ­ra wie (zna się na tym) co jest przed­mio­tem zamó­wie­nia, powin­na (ana­lo­gicz­nie jak sędzia, i z tego same­go powo­du) korzy­stać z wie­dzy bie­głe­go. Skoro tak, to OPZ, szcze­gól­nie gdy jest to roz­wią­za­nie tech­nicz­ne, nie powi­nien być tre­ścią czę­ści praw­nej umo­wy, powi­nien być do niej załącznikiem. 

Pojęcie przed­miot zamó­wie­nia, zgod­nie z Kodeksem Cywilnym, jako opis tego cze­go ocze­ku­je Zamawiający od Dostawcy, doty­czy każ­de­go zamó­wie­nia. Dlatego każ­da umo­wa, o ile tyl­ko doty­czy zaku­pu usłu­gi lub przed­mio­tu mate­rial­ne­go, nie tyl­ko ta z pod­mio­tem publicz­nym, powin­na zawie­rać wyod­ręb­nio­ny Opis Przedmiotu Zamówienia. 

Ustawodawca pisze ?(?Ustawa z dnia 29 stycz­nia 2004 r. Prawo zamó­wień publicz­nych,? 2004)?:

Art. 29. Opis przed­mio­tu zamówienia

1. Przedmiot zamó­wie­nia opi­su­je się w spo­sób jed­no­znacz­ny i wyczer­pu­ją­cy, za pomo­cą dosta­tecz­nie dokład­nych i zro­zu­mia­łych okre­śleń, uwzględ­nia­jąc wszyst­kie wyma­ga­nia i oko­licz­no­ści mogą­ce mieć wpływ na spo­rzą­dze­nie oferty.

[…]

3b. Zamawiający może okre­ślić w opi­sie przed­mio­tu zamó­wie­nia koniecz­ność prze­nie­sie­nia praw wła­sno­ści inte­lek­tu­al­nej lub udzie­le­nia licencji.

Jak widać, opis ten powi­nien speł­niać okre­ślo­ne rygo­ry, klu­czem jest zaś to, że opis ten słu­ży do zło­że­nia ofer­ty, a ta – po jej przy­ję­ciu – wią­że kupu­ją­ce­go w umo­wie. To głów­ny powód by OPZ był załącz­ni­kiem, odręb­nym bytem wydzie­lo­nym z umowy. 

Dialog pod­mio­tu szu­ka­ją­ce­go odpo­wied­nie­go dla sie­bie pro­duk­tu lub usłu­gi, z dostaw­ca­mi, wyglą­da z regu­ły podob­nie jak dia­log: A – Kto mi sprze­da Jabłko?, B- Ja sprze­dam Jabłko za 2 zł!, A – Poproszę to Jabłko i pła­cę.” Słowo Jabłko powta­rza się w całym tym dia­lo­gu, i jest to nic inne­go jak przed­miot zapy­ta­nia, przed­miot ofer­ty i przed­miot umo­wy zaku­pu, czy­li jest to to samo. Rozsądek więc, co naj­mniej, naka­zu­je, by był to tak­że ten sam i taki sam opis (ten sam dokument). 

Ważna rzecz: opis usłu­gi, np. wspar­cia tech­nicz­ne­go i utrzy­ma­nia, też powin­na sta­no­wić OPZ a nie treść umo­wy, z tego same­go powo­du: wyko­rzy­stu­je język tech­nicz­ny i opi­su­je tech­nicz­ne aspek­ty przed­mio­tu zapy­ta­nia i ofer­ty zarazem.

Jeżeli docho­dzi do nego­cja­cji, to nale­ży pamię­tać, że ich przed­mio­tem powi­nien być zakres opi­sa­ny w OPZ, a skut­kiem cena. W przy­pad­ku PZP takie nego­cja­cje (zmia­na OPZ) w zasa­dzie nie mogą mieć miej­sca, ostat­nim cza­sem na nie jest dia­log techniczny. 

W przy­pad­ku postę­po­wa­nia pro­wa­dzo­ne­go przez pod­miot nie pod­le­ga­ją­cy PZP, nego­cja­cje są jak naj­bar­dziej moż­li­we a nie raz wska­za­ne, gdyż w zasa­dzie peł­nią rolę dia­lo­gu technicznego. 

Kolejna waż­na rzecz, o któ­rej nie raz pisa­łem: kto jest auto­rem OPZ? I tu już w kon­tek­ście powyż­sze­go widać, że nie ma sen­su by wyma­ga­nia na opro­gra­mo­wa­nie pisał przy­szły jego dostaw­ca dopie­ro po zawar­ciu umo­wy. Ustawodawca i sądy, zwra­ca­ją uwa­gę, że to Zamawiający ma dostar­czyć opis przed­mio­tu zamó­wie­nia, a wyko­naw­ca ma wyja­śnić wszel­kie swo­je wąt­pli­wo­ści w toku skła­da­nia oferty. 

Odpowiednikiem obo­wiąz­ku nale­ży­te­go opi­sa­nia przed­mio­tu zamó­wie­nia leżą­ce­go po stro­nie zama­wia­ją­ce­go jest obo­wią­zek wyko­naw­cy zadba­nia o dopre­cy­zo­wa­nie i wyja­śnie­nie wszel­kich aspek­tów zamó­wie­nia istot­nych dla jego pra­wi­dło­we­go wyko­na­nia. O tym, że nie jest to obo­wią­zek jedy­nie teo­re­tycz­ny prze­ko­ny­wał Sąd Najwyższy w wyro­ku z dnia 5 czerw­ca 2014 r w spra­wie o sygn. IV CSK 626/2013. Sąd stwier­dził, iż nie­któ­rych ?oko­licz­no­ściach skła­da­ne­go i przyj­mo­wa­ne­go zamó­wie­nia publicz­ne­go oraz wąt­pli­wo­ści wystę­pu­ją­cych po stro­nie wyko­naw­cy, art. 38 p.z.p. sta­no­wi w związ­ku z art. 354 § 2 k.c. nie tyl­ko upraw­nie­nie, ale tak­że obo­wią­zek wyko­naw­cy zwró­ce­nia się do zama­wia­ją­ce­go o wyja­śnie­nie tre­ści SIWZ; zanie­cha­nie tej powin­no­ści może być pod­sta­wą zarzu­ce­nia wyko­naw­cy nie­do­cho­wa­nia nale­ży­tej sta­ran­no­ści wyma­ga­nej od przed­się­bior­cy przez art. 355 § 2 k.c.?Rozstrzygnięcie Sądu Najwyższego ma fun­da­men­tal­ne zna­cze­nie dla prak­ty­ki wyko­ny­wa­nia umów w spra­wie zamó­wie­nia publicz­ne­go.?(Wójcik, 2015)?

Innymi sło­wy, zło­że­nie ofer­ty jest oświad­cze­niem Wykonawcy o bra­ku wąt­pli­wo­ści co do tre­ści zapy­ta­nia, w szcze­gól­no­ści co do tre­ści Opisu Przedmiotu Zamówienia. 

Tak więc:

Podsumowując, opis przed­mio­tu zamó­wie­nia musi być:

1) jed­no­znacz­ny ? nie­bu­dzą­cy wąt­pli­wo­ści, dopusz­cza­ją­cy tyl­ko jed­ną moż­li­wość interpretacyjna;

2) wyczer­pu­ją­cy ? przed­sta­wia­ją­cy dane zagad­nie­nia wszech­stron­nie, szcze­gó­ło­wo; grun­tow­ny, dokładny;

3) spo­rzą­dzo­ny za pomo­cą dokład­nych i zro­zu­mia­łych okre­śleń, przy uży­ciu sfor­mu­ło­wań, któ­re są w danej bran­ży zro­zu­mia­łe, choć nie muszą być zna­ne ogó­ło­wi.?(?OPIS PRZEDMIOTU ZAMÓWIENIA,? 2018)?

Jaki z tego wnio­sek dla pra­cow­ni­ków firm, i ich praw­ni­ków, budu­ją­cych treść umów i doku­men­tów sta­no­wią­cych Specyfikacje Istotnych Warunków Zamówienia czy po pro­stu tyl­ko zapy­ta­nia ofertowe? 

…na zama­wia­ją­cym spo­czy­wa obo­wią­zek jasne­go i pre­cy­zyj­ne­go okre­śle­nia przed­mio­tu zamó­wie­nia, a co za tym idzie, wyko­rzy­sta­nia do jego opi­sa­nia stan­dar­do­wych okre­śleń tech­nicz­nych, któ­re są zwy­kle uży­wa­ne w danej dzie­dzi­nie, zro­zu­mia­łych dla wszyst­kich osób trud­nią­cych się dzia­łal­no­ścią w danej bran­ży.?(Urząd Zamówień Publicznych, n.d.)?

Biorąc pod uwa­gę powyż­sze oraz to, że mowa tu o pro­duk­tach inży­nier­skich (opro­gra­mo­wa­nie) reko­men­du­je się: 

  1. Opracowanie OPZ w posta­ci pre­cy­zyj­nych sche­ma­tów blo­ko­wych i wzo­rów mate­ma­tycz­nych, jest zawsze lep­sze niż nie­jed­no­znacz­ny opis wyko­na­ny języ­kiem natu­ral­nym, ten może być co naj­wy­żej uzu­peł­nie­niem lub komen­ta­rzem. Ideałem jest tu pre­cy­zyj­na doku­men­ta­cja tech­nicz­na (pro­jekt tech­nicz­ny). Należy pamię­tać, że taki OPZ (w odróż­nie­niu od SIWZ) jest zawsze przed­mio­tem pra­wa autor­skie­go ?(Koralewski, 2014)?.?*?
  2. OPZ, będą­cy doku­men­tem tech­nicz­nym, spe­cja­li­stycz­nym, nie musi być zro­zu­mia­ły dla praw­ni­ka, a nie raz nawet dla same­go Zamawiającego. 
  3. Jeżeli sam zama­wia­ją­cy nie potra­fi stwo­rzyć popraw­ne­go OPZ, powi­nien naj­pierw zle­cić usłu­gę opra­co­wa­nia OPZ, a potem dopie­ro szu­kać dostaw­cy tego, co opi­sa­no w tym OPZ. ?(Urząd Zamówień Publicznych, 2009)?.
  4. Usługa tech­nicz­na, ocze­ki­wa­ny spo­sób jej świad­cze­nia, i jakość, to tak­że przed­miot zamó­wie­nia, sku­tecz­ną prak­ty­ką jest więc umiesz­cze­nie ich opi­su w OPZ a nie w tre­ści umo­wy.?(Urząd Zamówień Publicznych, 2009)?

Źródła

  • ?
    Sąd Najwyższy wie­lo­krot­nie wska­zy­wał, że utwo­rem pod­le­ga­ją­cym ochro­nie praw­no­au­tor­skiej jest każ­de dzie­ło, jeśli przy­naj­mniej pod wzglę­dem for­my wska­zu­je pew­ne ele­men­ty twór­cze, choć­by mini­mal­ne (wyrok Sądu Najwyższego z 31 mar­ca 1953 r.; sygn. akt II C 834/52).

  1. Koralewski, M. (2014, April 28). Trzeba uwa­żać na pra­wo autor­skie w prze­tar­gach. Retrieved June 28, 2019, from por​talzp​.pl websi­te: https://​www​.por​talzp​.pl/​t​o​p​-​t​e​m​a​t​y​/​t​r​z​e​b​a​-​u​w​a​z​a​c​-​n​a​-​p​r​a​w​o​-​a​u​t​o​r​s​k​i​e​-​w​-​p​r​z​e​t​a​r​g​a​c​h​-​1​0​6​5​.​h​tml
  2. Lewicka, R. W. (2018, March 7). TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK. Retrieved June 28, 2019, from LinkedIn​.com websi­te: https://www.linkedin.com/pulse/twój-prawnik-rozumie-kontrakt-lepiej-niż-twoi-ludzie-warchol-lewicka/
  3. OPIS PRZEDMIOTU ZAMÓWIENIA. (2018, May 30). Retrieved June 28, 2019, from Portal Zamówień Publicznych websi­te: https://​www​.por​talzp​.pl/​o​/​o​p​i​s​-​p​r​z​e​d​m​i​o​t​u​-​z​a​m​o​w​i​e​n​i​a​-​8​9​0​4​.​h​tml
  4. Urząd Zamówień Publicznych. (2009). UDZIELANIE ZAMÓWIEŃ PUBLICZNYCH NA SYSTEMY INFORMATYCZNE (p. 33) [REKOMENDACJE]. Urząd Zamówień Publicznych.
  5. Urząd Zamówień Publicznych. (n.d.). Opinia doty­czą­ca opi­su przed­mio­tu zamó­wie­nia. Retrieved June 28, 2019, from Urząd Zamówień Publicznych website: 
  6. Ustawa z dnia 29 stycz­nia 2004 r. Prawo zamó­wień publicz­nych. (2004, February 9). Retrieved June 28, 2019, from Internetowy System Aktów Prawnych websi­te: http://​pra​wo​.sejm​.gov​.pl/​i​s​a​p​.​n​s​f​/​D​o​c​D​e​t​a​i​l​s​.​x​s​p​?​i​d​=​W​D​U​2​0​0​4​0​1​9​0​177
  7. Wójcik, P. (2015, May 25). Precyzyjny opis przed­mio­tu zamó­wie­nia to obo­wią­zek zama­wia­ją­ce­go. Retrieved June 28, 2019, from Prawo​.pl websi­te: https://​www​.pra​wo​.pl/​s​a​m​o​r​z​a​d​/​p​r​e​c​y​z​y​j​n​y​-​o​p​i​s​-​p​r​z​e​d​m​i​o​t​u​-​z​a​m​o​w​i​e​n​i​a​-​t​o​-​o​b​o​w​i​a​z​e​k​-​z​a​m​a​w​i​a​j​a​c​e​g​o​,​2​3​0​5​5​0​.​h​tml
  8. Żeliński, J. (2017, February 16). Przedmiot Zamówienia ? instruk­cja nie tyl­ko dla praw­ni­ków, na zupę pomi­do­ro­wą. Retrieved June 28, 2019, from IT​-Consulting​.pl websi­te: https://it-consulting.pl//2017/02/16/przedmiot-zamowienia-instrukcja-dla-prawnikow-na-zupe-pomidorowa/

Tajemnica przedsiębiorcy

Niedawno pisa­łem, że zapy­ta­nie ofer­to­we (prze­tar­gi) stan­dar­do­wo zawie­ra Opis Przedmiotu Zamówienia (OPZ), któ­rym może być pro­dukt lub usłu­ga. Oferta prze­tar­go­wa to jedy­nie odpo­wiedź (pomi­jam for­ma­li­zmy w rodza­ju wadium czy pod­pis oso­by upraw­nio­nej itp.), brzmią­ca: ?to co opi­sa­no w OPZ u nasz kosz­tu­je tyle?. Zasada prze­tar­gu jest pro­sta. Nie widzę tu nigdzie miej­sca na ?wraż­li­wość infor­ma­cji?. (Jawność ofert ? zawsze mów praw­dę). Mimo to jed­nak sta­le podej­mo­wa­ne są pró­by omi­ja­nia zasa­dy jaw­no­ści postępowania.

Niektóre fir­my skła­da­ją­ce ofer­ty pod­no­szą, że nie chcą by do ich ofert mia­ła dostęp kon­ku­ren­cja. Niestety nie tyl­ko kon­ku­ren­cja ma pra­wo je poznać, każ­dy oby­wa­tel ma takie pra­wo, mimo nie­chę­ci skła­da­ją­cych ofertę:

W szcze­gól­no­ści zastrze­że­niem taj­no­ści nie mogą być obję­te nazwy (fir­my) oraz adre­sy wyko­naw­ców, a tak­że infor­ma­cje doty­czą­ce ceny, ter­mi­nu wyko­na­nia zamó­wie­nia, okre­su gwa­ran­cji i warun­ków płat­no­ści zawar­tych w ofer­tach. Nie może sta­no­wić tajem­ni­cy przed­się­bior­stwa infor­ma­cja tech­nicz­na, tech­no­lo­gicz­na, orga­ni­za­cyj­na, któ­ra jest zna­na lub moż­na się o niej dowie­dzieć zwy­kła dro­gą. Nie może też sta­no­wić tajem­ni­cy przed­się­bior­stwa tech­no­lo­gia czy orga­ni­za­cja powszech­nie zna­na czy sto­so­wa­na (tak wyrok Zespołu Arbitrów z 25 kwiet­nia 2003 r. UZP/ZO/0 – 466/03). (Jawność umo­wy o zamó­wie­nie publicz­ne – - Prawo zamó­wień publicz­nych – e‑prawnik.pl).

Zjawisko sta­ło się na tyle jaskra­we, że Polska Izba Informatyki i Telekomunikacji opu­bli­ko­wa­ła ofi­cjal­ną opi­nię w tej sprawie:

Izba oce­nia zde­cy­do­wa­nie nega­tyw­nie sto­so­wa­nie prak­tyk pole­ga­ją­cych na nie­uza­sad­nio­nym wyko­rzy­sty­wa­niu prze­pi­sów dopusz­cza­ją­cych nie­ujaw­nia­nie infor­ma­cji wyłącz­nie w celu wyłą­cze­nia moż­li­wo­ści kon­tro­li utaj­nio­nych infor­ma­cji przez kon­ku­ru­ją­cych wyko­naw­ców. Działanie takie w opi­nii Izby posia­da zna­mio­na czy­nu nie­uczci­wej kon­ku­ren­cji i może być potrak­to­wa­ne, jako dzia­ła­nie nie­le­gal­ne. Dalsza akcep­ta­cja takich dzia­łań sta­no­wi­ła­by wyłącz­nie zachę­tę do takich prak­tyk i przy­czy­nia­ła­by się do wypa­cze­nia zasa­dy jaw­no­ści w sys­te­mie zamó­wień publicz­nych. (peł­na treść: Opinia Polskiej Izby Informatyki i Telekomunikacji [PIIT] w spra­wie jaw­no­ści postę­po­wa­nia i doku­men­ta­cji prze­tar­go­wej w postę­po­wa­niach o zamó­wie­nia publiczne)

A co Prawo Zamówień Publicznych mówi o przed­mio­cie zamówienia:

Art. 29.

1. Przedmiot zamó­wie­nia opi­su­je się w spo­sób jed­no­znacz­ny i wyczer­pu­ją­cy, za pomo­cą dosta­tecz­nie dokład­nych i zro­zu­mia­łych okre­śleń, uwzględ­nia­jąc wszyst­kie wyma­ga­nia i oko­licz­no­ści mogą­ce mieć wpływ na spo­rzą­dze­nie oferty.

2. Przedmiotu zamó­wie­nia nie moż­na opi­sy­wać w spo­sób, któ­ry mógł­by utrud­niać uczci­wą kon­ku­ren­cje.

Tak więc (wytłusz­cze­nie moje) ofe­ren­to­wi pozo­sta­je zło­żyć ofer­tę w posta­ci ceny i uzu­peł­nień, jeże­li wyma­ga takich SIWZ (np. kry­te­ria wybo­ru wykonawcy).

Popatrzmy jed­nak na usta­wo­wą defi­ni­cje tajem­ni­cy przed­się­bior­stwa, defi­niu­je ją art. 11 ust. 4 usta­wy z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej konkurencji:

Przez tajem­ni­cę przed­się­bior­stwa rozu­mie się nie­ujaw­nio­ne do wia­do­mo­ści publicz­nej infor­ma­cje tech­nicz­ne, tech­no­lo­gicz­ne, orga­ni­za­cyj­ne przed­się­bior­stwa lub inne infor­ma­cje posia­da­ją­ce war­tość gospo­dar­czą, co do któ­rych przed­się­bior­ca pod­jął nie­zbęd­ne dzia­ła­nia w celu zacho­wa­nia ich poufności.

Pytanie moje: sko­ro OPZ opi­su­je [przed­miot zamó­wie­nia] w spo­sób jed­no­znacz­ny i wyczer­pu­ją­cy oraz zastrze­że­niem taj­no­ści [w ofer­tach prze­tar­go­wych] nie mogą być obję­te nazwy (fir­my) oraz adre­sy wyko­naw­ców, a tak­że infor­ma­cje doty­czą­ce ceny, ter­mi­nu wyko­na­nia zamó­wie­nia, okre­su gwa­ran­cji i warun­ków płat­no­ści zawar­tych w ofer­tach, to gdzie tu miej­sce na inne taj­ne infor­ma­cje infor­ma­cje posia­da­ją­ce war­tość gospo­dar­czą” w ofertach?

Kiedy ofer­ta może zawie­rać (bywa, że na żąda­nie ogła­sza­ją­ce­go prze­targ) infor­ma­cje będą­ce tajem­ni­cę przed­się­bior­stwa”? Hipotetyczne powo­dy tłu­ma­czą takie zapi­sy: ogła­sza­ją­cy prze­targ ma inny (ukry­ty) cel niż opi­sa­ny w SIWZ/OPZ, prze­targ ogła­sza się w celu pozy­ska­nia pouf­nych infor­ma­cji od dostaw­ców oraz, umiesz­cza je ofe­rent świa­do­mie w celu ogra­ni­cze­nia dostę­pu do tre­ści ofer­ty czy­li w celu ogra­ni­cze­nia nad­zo­ru nad postę­po­wa­niem. W przy­pad­kach pato­lo­gicz­nych, taki cel (ogra­ni­cze­nie dostę­pu) mogą mieć obie stro­ny (zresz­tą doty­czy to nie tyl­ko prze­tar­gów na sys­te­my IT).

Nadzór nad taki­mi postę­po­wa­nia­mi i ich wyni­ka­mi jest fak­tycz­nie trud­ny, popa­trz­my na pery­pe­tie wnio­sku­ją­cych o dostęp do doku­men­tów prze­tar­go­wych w try­bie dostę­pu do infor­ma­cji publicz­nej, moż­na śle­dzić na blo­gu Piotra VaGla” Waglowskiego, to jeden z przy­kła­dów: Wniosek do KPRM zwią­za­ny z prze­cho­wy­wa­ny­mi tam tajem­ni­ca­mi przed­się­biorstw | pra­wo | VaGla​.pl Prawo i Internet.

Co mnie zasta­na­wia? To, że bar­dzo wie­le zna­nych mi prze­tar­gów w sfe­rze IT jest wła­śnie anty przy­kła­da­mi ich ogłaszania. 

Niedawno pisa­łem też o innej pato­lo­gii: nie ma sen­su ogła­sza­nie jed­ne­go prze­tar­gu na ana­li­zę, pro­jek­to­wa­nie i wykonanie”:

Jak widać pró­ba wyce­ny całe­go pro­jek­tu już na samym jego począt­ku to wró­że­nie z fusów, wyko­naw­ca przyj­mie war­tość bez­piecz­na dla sie­bie, a tak okre­ślo­ny budżet i tak zosta­nie skon­su­mo­wa­ny (co poka­zu­je prak­ty­ka, tak się skła­da ofer­ty w prze­tar­gach publicz­nych, taka jest jakość więk­szo­ści zapy­tań przetargowych!).

Wystarczy wydzie­lić etap pro­jek­to­wa­nia (ana­li­za i pro­jek­to­wa­nie to ok. 20% kosz­tu deve­lop­men­tu) i zawrzeć umo­wę na eta­pie co naj­mniej wstęp­ne­go pro­jek­tu, wte­dy ?zawy­ża­nie? (narzu­ca­nie zapa­su na nie­wie­dzę) spa­da dwu­krot­nie. Opracowanie kom­plet­ne­go pro­jek­tu przed wyce­ną prac deve­lop­men­tu to obszar bli­ski pra­wej czę­ści: esty­ma­cja kosz­tu z bar­dzo małym błę­dem. (Jak wyce­niać pro­jek­ty IT?).

Powyższe jest wręcz oczy­wi­ste, co nie prze­szka­dza urzę­dom ogła­szać wła­śnie takich pato­lo­gicz­nych prze­tar­gów. Tę pato­lo­gię prak­ty­ku­ją i chro­nią nie­ste­ty obie stro­ny postę­po­wań przetargowych.

A na grzyba nam Pan Analityk?

Przecież ana­li­zę zro­bi­my sami, a jak nie – to zro­bi to dostaw­ca. Tak czę­sto roz­po­czy­na się tak zwa­na Droga do klę­ski”. Jednym z typo­wych listów ini­cju­ją­cych współ­pra­ce z wie­lo­ma moimi klien­ta­mi był ten:

Planujemy wdro­że­nie nowe­go opro­gra­mo­wa­nia, chce­my tym razem unik­nąć pre­sji ze stro­ny dostaw­cy opro­gra­mo­wa­nia. Poprzednim razem dostaw­ca opro­gra­mo­wa­nia uprasz­czał sobie pra­cę, już na eta­pie ana­li­zy, któ­rą wyko­ny­wał sam. Analiza wyma­gań pole­ga­ła na wywia­dach i warsz­ta­tach gru­po­wych, skoń­czy­ła się zwy­kłym opi­sem, tabel­ka­mi i kil­ko­ma nie­czy­tel­ny­mi sche­ma­ta­mi. Podczas ana­li­zy i wdro­że­nia sta­le wma­wia­no nam, że tego nie moż­na”, to nale­ży upro­ścić” albo tak się nie robi” my zaś nie potra­fi­li­śmy tego oce­nić. Wiele naszych potrzeb odkry­wa­li­śmy dopie­ro pod­czas insta­la­cji kolej­nych pro­to­ty­pów, zaś dostaw­ca uni­kał wpro­wa­dza­nia zmian i obie­ca­nych dosto­so­wań. Dostaliśmy w efek­cie nie­przy­dat­ne i nie­zgod­ne z biz­ne­so­wy­mi potrze­ba­mi opro­gra­mo­wa­nie. Czy może nam Pan tym razem pomóc?

Czy to pro­pa­gan­da? Niestety nie. W czym pro­blem? A mia­no­wi­cie w meto­dzie pro­wa­dze­nia ana­li­zy i potem tre­ści spe­cy­fi­ka­cji wyma­gań. Łatwo powie­dzieć: zebrać wymagania.

Powszechnie uwa­ża się, że ana­li­za wyma­gań na opro­gra­mo­wa­nie to pro­sty, ale pra­co­chłon­ny pro­ces pro­wa­dze­nia wywia­dów i skrzęt­ne­go zapi­sy­wa­nia tego, cze­go ocze­ku­je przy­szły użyt­kow­nik. Nic bar­dziej błęd­ne­go – jest to naj­gor­szy sposób.

Wśród wie­lu tego typu metod są te naj­prost­sze i naj­bar­dziej ryzy­kow­ne a mia­no­wi­cie: wywia­dy, ankie­ty, [[sesje JAD]]. Sama ich isto­ta zakła­da, że klient wie co chce, nale­ży to tyl­ko z nie­go wycią­gnąć i upo­rząd­ko­wać. Być może cza­sa­mi tak jest, ale z regu­ły koń­czy się to kla­sycz­nym stwier­dze­niem klien­ta na koniec projektu:

Tak, dostar­czy­li nam Państwo dokład­nie to co chcie­li­śmy ale zupeł­nie nie to, cze­go potrzebujemy.

Dlaczego tak się dzie­je, choć wie­lu (ana­li­ty­ków) tak bar­dzo się sta­ra? Jak ana­li­za może wyglą­dać napi­sa­łem tu już nie raz. Ale po co tyle zacho­du? Dlaczego upie­ram się przy tych śmiesz­nych for­ma­li­zmach, sko­ro moż­na po ludz­ku zapi­sać co powie­dział user a potem zamie­nić to na wypunk­to­wa­ne listy lub wier­sze ład­nej tabe­li? Najlepiej jesz­cze gdy liczą sobie naj­mniej kil­ka­set pozy­cji. Jednak tak pra­cu­je ana­li­tyk dyk­ta­fon.

Dobra spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie, to wynik ana­li­zy i mode­lo­wa­nia orga­ni­za­cji, kom­pro­mis pomię­dzy moż­li­wo­ścia­mi tech­no­lo­gii a cela­mi biz­ne­so­wy­mi wdro­że­nia. Nie ma tu zna­cze­nia czy będzie to goto­wy sys­tem ERP, czy dedy­ko­wa­ne roz­wią­za­nie. Ale po kolei.

Czym gro­zi ana­li­tyk dyktafon?

Tu pozwo­lę sobie sko­rzy­stać z zawar­to­ści krót­kie­go arty­ku­łu kole­gi pro­wa­dzą­ce­go blog O wyma­ga­niach. Poniżej kil­ka sta­ty­styk oraz mój komen­tarz co do ich przy­czyn. a że pro­blem jest poważ­ny wystar­czy wie­dzeć, że:

Błędy w wyma­ga­niach to jed­na trze­cia wszyst­kich defek­tów w pro­jek­tach. [Dean Leffingwell, Don Widrig – Managing Software Requirements” (1999)]

Produktem ana­li­zy wyma­gań są wyma­ga­nia, jak już wspo­mnia­łem, moż­na je zbie­rać meto­da­mi reje­stra­cyj­ny­mi” (odpy­ty­wa­nie klien­tów) oraz badaw­czy­mi”. Te dru­gie to kolej­no: ana­li­za i model orga­ni­za­cji klien­ta, iden­ty­fi­ka­cja celów biz­ne­so­wych i czyn­ni­ków wpły­wa­ją­cych na ich osią­gnię­cie, pro­jekt roz­wią­za­nia: co ma zostać dostar­czo­ne, opis pro­jek­tu czy­li spe­cy­fi­ka­cja pro­duk­tu. Wywiady są łatwe a peł­na ana­li­za trud­na. Nie trud­no się więc domy­ślić, któ­rych się robi naj­wię­cej. I mamy głów­ną przy­czy­nę, to właśnie:

Procesy zwią­za­ne ze zbie­ra­niem wyma­gań są źró­dłem więk­szo­ści poważ­nych pro­ble­mów z jako­ścią. [Gerald Weinberg – Quality Software Management” (1997)]

Jakość spe­cy­fi­ka­cji wyma­gań to mię­dzy inny­mi jej kom­plet­ność, spój­ność itp. Jak doku­ment wyma­gań jest niskiej jako­ści to typo­wym obja­wem jest tak zwa­ne odkry­wa­nie wyma­gań w trak­cie trwa­nia pro­jek­tu, czy­li zmia­ny zakre­su pro­jek­tu, a:

Zmiany zakre­su są jed­nym z naj­częst­szych źró­deł dodat­ko­wych kosz­tów w pro­jek­tach i czę­sto pro­wa­dzą do porzu­ce­nia pro­jek­tu. [Capers Jones – Assessment and Control of Software Risks” (1994)]

Co jesz­cze? Skąd te roz­dę­te budże­ty, prze­ter­mi­no­wa­ne pro­jek­ty typu czas i mate­riał”? Bo:

Naprawa błę­dów zwią­za­nych z wyma­ga­nia­mi pochła­nia 70 – 80% kosz­tów ponow­nej pra­cy w pro­jek­tach IT. A cał­ko­wi­te kosz­ty ponow­nej pra­cy zja­da­ją nawet do 50% kosz­tów pro­jek­tu. [Dean Leffingwell – Calculating and Return on Investment from More Effective Requirements Management” (1997)]

Kolejny etap, to kosz­ty utrzymania:

Szukanie i napra­wia­nie błę­dów wyma­gań po wdro­że­niu sys­te­mu jest 100 razy kosz­tow­niej­sze niż szu­ka­nie i napra­wia­nie tych samych błę­dów pod­czas zbie­ra­nia wyma­gań. [Barry Boehm, Victor R. Basili – Software Defect Reduction Top 10 List” (2001)]

I tyle o złych wymaganiach.

Analityk zamiast dyktafonu

Jeżeli wyma­ga­nia spe­cy­fi­ku­je się meto­dą pro­stej obser­wa­cji (odsłu­chu) otrzy­mu­je­my opis fak­tów a nie ich przy­czyn. Rzecz a tym, że fak­ty nic nie mówią o ich przy­czy­nach. Kolejny cytat:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.” Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre opro­gra­mo­wa­nie. (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997).

Inny przy­kład, z nie­co innej dzie­dzi­ny ale dosko­na­le odda­ją­cy efek­ty pole­ga­nia na obser­wa­cji. Przez wie­le lat uzna­wa­no, że Ziemia to cen­trum wszech­świa­ta. Ludzie obser­wo­wa­li Niebo z Ziemi. To co widzą, po pro­tu reje­stro­wa­li ufa­jąc, że sama obser­wa­cja da wła­ści­wy wynik. W efek­cie uzy­ski­wa­li takie oto tra­jek­to­rie pla­net i gwiazd:

geocentryczny

Nie dawa­ły się opi­sać żad­nym pro­stym rów­na­niem, a te rów­na­nia któ­re powsta­wa­ły były nie tyl­ko przy­bli­że­nia­mi ale tak­że bar­dzo zło­żo­ny­mi zależ­no­ścia­mi dla każ­de­go cia­ła nie­bie­skie­go z osob­na. Powyższy rysu­nek to namiast­ka tego przy­no­szą z sobą ana­li­ty­cy obserwatorzy.

Prawdę odkrył i udo­ku­men­to­wał Kopernik, czło­wiek któ­ry nie szu­kał pokla­sku ani u zwy­kłych ludzi patrzą­cych z wia­rą w nie­bo, ani u tych, w któ­rych inte­re­sie było, by Ci ludzie wie­rzy­li, że Ziemia to sta­no­wi cen­trum ich świa­ta. Odkryta praw­da w efek­cie wszyst­kim dobrze słu­ży ? mimo począt­ko­we­go opo­ru, a wyglą­da ona tak:

heliocentryczny

System helio­cen­trycz­ny jest pro­sty, zro­zu­mia­ły dla każ­de­go, łatwy do opi­sa­nia (mimo to wie­lu ludziom nadal trud­no się pogo­dzić z tym, że nie są pęp­kiem świa­ta a jedy­nie jego czę­ścią i to nie cen­tral­ną). Poszczególne komór­ki orga­ni­za­cyj­ne w fir­mach i orga­ni­za­cjach, owe fir­my na ryn­ku, są jak poszcze­gól­ne cia­ła nie­bie­skie we wszech­świe­cie, pra­cow­ni­cy tych orga­ni­za­cji jak róż­ni obser­wa­to­rzy tego same­go Nieba. Każdy ma swo­je oso­bi­ste spoj­rze­nie na swo­ją część ale nikt z nich nie widzi cało­ści «z góry”. Każdy ma swój, geo­cen­trycz­ny widok. Typowe wywia­dy to zle­pek takich opisów.

Praktyka poka­zu­je, że sys­te­my (fir­my, orga­ni­za­cje) obser­wo­wa­ne z ich wnę­trza wyda­ją się bar­dzo skom­pli­ko­wa­ne i tak też są opi­sy­wa­ne przez więk­szość ludzi (patrz wyżej dia­gram sys­te­mu geo­cen­trycz­ne­go). W rze­czy­wi­sto­ści więk­szość sys­te­mów jest znacz­nie prost­sza, jed­nak odkry­cie tego wyma­ga głę­bo­kie­go spoj­rze­nia z zewnątrz.

Rzemieślnicy pro­du­ku­ją­cy ?przed Kopernikiem? skom­pli­ko­wa­ne i kosz­tow­ne przy­rzą­dy do okre­śla­nia poło­że­nia pla­net i gwiazd z wia­do­mych powo­dów nie byli zain­te­re­so­wa­ni uprasz­cza­niem tego mode­lu i swo­ich skom­pli­ko­wa­nych przy­rzą­dów. Dlatego zapew­ne nie raz jesz­cze usły­szę, że dobra ana­li­za to set­ki stron, tysią­ce wyma­gań, mie­sią­ce pracy.

Jednak dobra ana­li­za to tyl­ko: dzie­siąt­ki stron i wyma­gań, tygo­dnie pra­cy ale zaawan­so­wa­ne meto­dy takie jak for­mal­na ana­li­za sys­te­mo­wa opar­ta na mode­lach i ich testowaniu.

Warto jed­nak zazna­czyć, że tak jak pro­jek­ty dedy­ko­wa­ne mają sens od ok. 75 tys. zł. (wyli­cze­nie w jed­nym zw wcze­śniej­szych arty­ku­łów) tak zaprzę­ga­nie takich metod ana­li­zy ma sens nawet jeże­li war­tość pro­jek­tu (war­tość ryzy­ka) prze­kra­cza już 10 tys. czy­li nie tak wie­le.… (koszt tego typu ana­liz to ok. 20% budże­tu projektu).

Na zakon­cze­nie cytat:

Niestety naj­częst­szy­mi przy­czy­na­mi [pro­ble­mów i dużych kosz­tów w pro­jek­tach] są źle prze­pro­wa­dzo­na ana­li­za przed­wdro­że­nio­wa i nie­ste­ty zbyt małe doświad­cze­nie part­ne­ra wdro­że­nio­we­go. Zwłaszcza przy dużych pro­jek­tach, gdzie spe­cy­fi­ka przed­się­bior­stwa wyma­ga oddziel­nych roz­wią­zań uzu­peł­nia­ją­cych i dużej wie­dzy pro­gra­mi­stycz­nej, poja­wia­ją się pro­ble­my. (źr. Wdrożenie ERP ? koszt czy zysk? – ERP ‑view​.pl.)

Czym jest obieg dokumentów i BPM? Dlaczego pozornie prosty system obiegu dokumentów

Zarządzanie pro­ce­sa­mi biz­ne­so­wy­mi to tak na praw­dę okre­so­we robie­nie zdjęć lot­ni­czych nad rze­ka­mi, sku­tecz­ne ste­ro­wa­nie ich bie­giem pole­ga wyłącz­nie na two­rze­niu wła­ści­we­go śro­do­wi­ska a nie tyl­ko koryt i wałów, jak się oka­zu­je i tak nie­trwa­łych, nie wytrzy­mu­ją sytu­acji eks­tre­mal­nych a to one budu­ją prze­wa­gę firm na rynku.

Niedawno (14 – 15 Lipca 2010) odby­ła się kon­fe­ren­cja EOIF GigaCon 2010 poświę­co­na sys­te­mom obie­gu doku­men­tów. Nie jest moim celem stresz­cza­nie tej kon­fe­ren­cji, jed­nak po niej nasu­nę­ło mi się kil­ka prze­my­śleń. Pierwsze to, czym tak na praw­dę są te sys­te­my, po dru­gie, dla­cze­go ich wdro­że­nia są tak mało prze­wi­dy­wal­ne. Po kil­ku roz­mo­wach z ich użyt­kow­ni­ka­mi w kulu­arach moż­na odnieść prze­ko­na­nie, że ana­li­zy wyma­gań są tu nie­po­trzeb­ne bo w więk­szo­ści przy­pad­ków to co zosta­je, w efek­cie wie­lu prób, wdro­żo­ne i ode­bra­ne jako koń­co­wy pro­dukt, nie­wie­le ma wspól­ne­go z wyni­ka­mi pier­wot­nej ana­li­zy wyma­gań. Jednym z wie­lu przy­kła­dów jakie pozna­łem to pewien urząd, w któ­rym ana­li­za przed­wdro­że­nio­wa opi­sy­wa­ła pra­wie 300 pro­ce­sów, po wdro­że­niu oka­za­ło się, że jest ich 15 (!). W efek­cie pro­jek­ty tego typu cechu­ją się znacz­nie więk­szym kosz­tem niż pla­no­wa­ny lub nawet wstrzy­ma­niem pro­jek­tu z powo­du wyczer­pa­nia fun­du­szy. Dlaczego tak się dzie­je? Otóż mode­lo­wa­nie prze­pły­wu pra­cy, doku­men­tów i pro­ce­sów jest na eta­pie ana­li­zy bar­dzo czę­sto błęd­nie utoż­sa­mia­ne z ?zapi­sy­wa­niem tego co robią ludzie? co jest poważ­nym błę­dem. (tu stresz­cze­nie, kom­plet­ny doku­ment PDF do pobra­nia, link na koń­cu tekstu)

Elementem two­rzą­cym momen­ta­mi nawet cha­os jest moim zda­niem tak­że pewien bała­gan poję­cio­wy, pre­le­gen­ci (kon­sul­tan­ci) czę­sto bez poda­wa­nia defi­ni­cji uży­wa­li takich pojęć jak: zarzą­dza­nie pro­ce­sa­mi, mode­lo­wa­nie pro­ce­sów, mapo­wa­nie pro­ce­sów, zarzą­dza­nie prze­pły­wem pra­cy, zarzą­dza­nie prze­pły­wem doku­men­tów, rein­ży­nie­ria pro­ce­sów, być może poja­wia­ły się jesz­cze inne, któ­re mi umknę­ły ale i to już daje obraz tego bałaganu. […]

Korzyści z formalnego podejścia do modelowania

Podstawową korzy­ścią jest jed­no­znacz­ny model orga­ni­za­cji nio­są­cy istot­ne infor­ma­cje i oczysz­czo­ny z tak zwa­nych ?śmie­cio­wych danych? czy­li tego co nam powie­dzia­no o orga­ni­za­cji a nie jest istot­ne w kon­tek­ście pro­jek­tu. Ta cecha for­mal­nych metod mode­lo­wa­nia pro­ce­sów pozwa­la po pierw­sze pano­wać nad zło­żo­no­ścią mode­li po dru­gie pro­wa­dzi do ich uogól­nie­nia. Uogólnianie na tym eta­pie przy­no­si dużo korzy­ści gdyż po pierw­sze mode­le sta­ja się prost­sze, opi­su­ją stan fak­tycz­ny i sku­pia­ją uwa­gę tyl­ko na tym co istot­ne czy­li na celu pra­cy a nie na tym jak jest w danym momen­cie wyko­ny­wa­na, bo nie raz może ona być wyko­na­na na wie­le rów­no­praw­nych spo­so­bów, któ­rych doku­men­to­wa­nie jest wła­śnie ?zaśmie­ca­niem? modeli.

Zawsze istot­ny jest tyl­ko pro­dukt pro­ce­su i ewen­tu­al­ne ogra­ni­cze­nia w jego powstaniu.

Praktyka poka­zu­je, że wie­le map pro­ce­sów zawie­ra­ją­cych dzie­siąt­ki dia­gra­mów tak na praw­dę poka­zu­je warian­ty tego same­go pro­ce­su. Bardzo czę­sto tak­że to co jest mode­lo­wa­ne jako jeden skom­pli­ko­wa­ny pro­ces to tak na praw­dę kil­ka pro­ce­sów współ­dzie­lą­cych dane (jest to bar­dzo czę­sto spo­ty­ka­ny przy­pa­dek w audy­tach jakie pro­wa­dzę). Na zakoń­cze­nie przy­kład, któ­ry poka­że opi­sa­ne zja­wi­ska i korzy­ści z formalizacji. […]

Konkluzja: prze­pływ danych nie jest toż­sa­my z prze­pły­wem pracy!

Dlaczego niektóre rozwiązania sprawiają kłopoty wdrożeniowe

Jak część z Państwa zapew­ne wie, bo doświad­czy­ła tego, wdro­że­nie sys­te­mu work­flow (uży­wam tego poję­cia celo­wo zamiast obieg doku­men­tów czy zarzą­dza­nie pro­ce­sa­mi dla odróż­nie­nia i wska­za­nia go jako pew­nej abs­trak­cji), przej­ście od map pro­ce­sów z fazy ana­li­zy wyma­gań do imple­men­ta­cji w fazie wdro­że­nia potra­fi spra­wić wie­le kło­po­tów. To co moż­na bez pro­ble­mu nary­so­wać nie zawsze da się potem wdro­żyć (zaim­ple­men­to­wać w kupio­nym opro­gra­mo­wa­niu). Dlaczego?

Po pierw­sze nie­sfor­ma­li­zo­wa­ne mode­le w zasa­dzie nie nada­ją się imple­men­ta­cji w jakim­kol­wiek opro­gra­mo­wa­niu i są głów­nym ryzy­kiem w pro­jek­cie, a po dru­gie na ryn­ku moż­na spo­tkać dwa rodza­je opro­gra­mo­wa­nia: do zarzą­dza­nia prze­pły­wem doku­men­tów i do zarzą­dza­nia prze­pły­wem pra­cy. Jest to ogrom­na róż­ni­ca gdyż więk­szość mode­li pro­ce­sów opi­su­je prze­pływ pra­cy zaś wie­le pro­duk­tów nazy­wa­nych ?zarzą­dza­nie obie­giem doku­men­tów? fak­tycz­nie słu­ży do zarzą­dza­nia prze­pły­wem doku­men­tów. W efek­cie ma miej­sce pró­ba doko­na­ni nie­moż­li­we­go. Na czym pole­ga róż­ni­ca? Źródło kło­po­tów tkwi w mode­lu danych (mode­lu dzie­dzi­ny) dla obu tych rozwiązań. […]

Dla zain­te­re­so­wa­nych: nota­cja BPMN imple­men­tu­je wła­śnie taki model dzie­dzi­ny dla­te­go moż­na powie­dzieć, że jeże­li pod­czas ana­li­zy biz­ne­so­wej mode­le wyko­na­no w tej nota­cji z uży­ciem peł­nej seman­ty­ki tej nota­cji, to pro­gram któ­ry miał by posłu­żyć do wdro­że­nia tych pro­ce­sów MUSI na liście swo­ich wyma­gań mieć peł­ną zgod­ność z powyż­szym mode­lem refe­ren­cyj­nym. Nie wol­no łamać for­ma­li­zmów nota­cji BPMN (seman­ty­ka i syn­tak­ty­ka nota­cji), w prze­ciw­nym wypad­ku wdro­że­nie pro­ce­sów w for­mie opi­sa­nej dia­gra­ma­mi się nie uda!

Dlatego każ­da ana­li­za biz­ne­so­wa ukie­run­ko­wa­na na sys­tem obie­gu doku­men­tów (czy­li tak na praw­dę prze­pły­wu pra­cy) musi zawie­rać etap for­ma­li­za­cji mode­li pro­ce­sów jeże­li pro­jekt ma być wykonywalny.

Zarządzanie procesami biznesowymi

Popularny skrót BPM (ang. Busienss Process mana­ge­ment ? Zarządzanie Procesami Biznesowymi) budzi coraz więk­sze moje roz­cza­ro­wa­nie wie­lo­ma fir­ma­mi. To nowe sło­wo klucz (ang. buz­zword) sta­ło się ostat­nio przy­pra­wą do wie­lu ofert mają­cą je dodat­ko­wo uatrak­cyj­nić. Tak więc czym to zarzą­dzać? Procesem? Czy samo nary­so­wa­nie dia­gra­mu prze­pły­wu pra­cy cokol­wiek zmie­ni w orga­ni­za­cji? NIE, wie to każ­dy kto brał udział w pro­jek­cie ?rein­ży­nie­rii pro­ce­sów? (BPR, ang. Business Process Reengineering, prak­ty­ka wręcz skom­pro­mi­to­wa­na w latach 90-tych) wdra­żał nor­my jako­ści ISO meto­dą naj­pierw doku­men­ta­cja ISO potem jej wdro­że­nie (to moim zda­niem powód kom­pro­mi­ta­cji idei wdra­ża­nia norm ISO w wie­lu organizacjach).

Całe śro­do­wi­sko orga­ni­za­cji to ludzi i komu­ni­ka­cja mię­dzy nimi. Komunikujemy się bez­po­śred­nio lub pośred­nio za pomo­cą doku­men­tów (maile, komu­ni­ka­to­ry, doku­men­ty, inne).[…] Jeżeli jakiś ciąg zda­rzeń, czyn­no­ści dopro­wa­dza do powsta­nia jakiejś tre­ści lub zaist­nie­nia zda­rze­nia i powta­rza się (lub chce­my by się powta­rzał) ?ubie­ra­my? go ?nazwę? a na dia­gra­mach zazna­cza­my sym­bo­lem ozna­cza­ją­cym pro­ces. Na tym wła­śnie pole­ga mode­lo­wa­nie pro­ce­sów, któ­re tym się róż­ni od mapo­wa­nia (ryso­wa­nia), że nie jest tyl­ko ryso­wa­niem a ana­li­zą i doku­men­to­wa­niem jej wyni­ków: zobra­zo­wa­niem tego co i po co się dzie­je w organizacji.

Co to więc jest to BPM? Moim zda­niem mode­le pro­ce­sów (mapy pro­ce­sów) to sku­tek, Wyjście pro­ce­su wdra­ża­nia zmian a nie jego Wejście!. Zarządzanie pro­ce­sa­mi pole­ga na zarzą­dza­niu ogra­ni­cze­nia­mi (np. poprzez two­rze­nie pro­ce­dur, poli­tyk bez­pie­czeń­stwa, itp.), któ­re w efek­cie skut­ku­ją takim a nie innym prze­pły­wem pracy.

Miałem kon­takt z wie­lo­ma fir­ma­mi, któ­re dały się namó­wić na pro­jekt ?Zarządzanie Procesami Biznesowymi?. Kupiły kosz­tow­ne narzę­dzia do mode­lo­wa­nia pro­ce­sów, zarzą­dza­nia zaso­ba­mi, moni­to­ro­wa­nia KPI (Key Performance Indicators, ang. Kluczowy mier­nik efek­tyw­no­ści), zle­ci­ły kosz­tow­ne usłu­gi mapo­wa­nia i opty­ma­li­za­cji pro­ce­sów. I co? I wszyst­ko na pół­kę bo real­ne pro­ce­sy daw­no ?roze­szły? się z tymi w doku­men­ta­cji. Dlaczego tak się dzie­je? Bo pro­ces to stan a nie cel zarząd­czy, ludzie pra­cu­ją w spo­sób będą­cy wyni­kiem warun­ków pra­cy a nie recepty.

Woda pły­nie zawsze z góry i nie pły­nie pod gór­kę, wyty­cze­nie bie­gu rze­ki kijem na pia­sku nicze­go nie zmie­ni, zbu­do­wa­nie beto­no­wej ryn­ny i nawet pomp (pod gór­kę?J) jest nie­trwa­łe (patrz ostat­nie powo­dzie i wały przeciwpowodziowe).

(peł­na treść opra­co­wa­nia dostęp­na do naby­cia klik­nij poniżej)