Najpierw pewien nagłó­wek i cytat:

Koszmar każ­de­go sze­fa. Jak zarzą­dzać fir­mą, z któ­rej nagle zni­ka­ją wszy­scy klu­czo­wi pra­cow­ni­cy? Taki sce­na­riusz to dra­mat dla każ­de­go sze­fa. Wyobraź sobie, że rzą­dzisz fir­mą, z któ­rej nagle zni­ka 25 klu­czo­wych pra­cow­ni­ków. Kiepsko, praw­da? (Koszmar każ­de­go sze­fa. Jak zarzą­dzać fir­mą, z któ­rej nagle zni­ka­ją wszy­scy klu­czo­wi pra­cow­ni­cy | NaTemat​.pl).

To chy­ba będzie pierw­szy przy­pa­dek, gdy odra­dzam czy­ta­nie arty­ku­łu, z któ­re­go pocho­dzi cytat, gdyż dys­ku­sja poli­tycz­na jest ostat­nią rze­czą, jakiej tu ocze­ku­je (i ostrze­gam, będę mode­ro­wał takie wpi­sy ;)). Kluczem jest sam ten cytat oraz to, że to nie jest niemożliwe.

Często w pro­jek­tach i na szko­le­niach zwra­cam uwa­gę, że jed­nym z powo­dów, dla któ­rych robi się ana­li­zę biz­ne­so­wą i mode­lo­wa­nie orga­ni­za­cji jest zapew­nie­nie cią­gło­ści jej dzia­ła­nia. Aby to zapew­nić, model musi być obiek­tyw­ny, dla­te­go zle­ca się to (mode­lo­wa­nie) zewnętrz­ne­mu wyko­naw­cy, podob­nie jak inne audy­ty (samo­opi­sy­wa­nie – auto­por­tret – nie jest kon­tro­lą ani weryfikacją).

po raz kolej­ny przy­to­czę zna­ny już Wam zapew­ne diagram:

Jest na nim nie­po­zor­ny, w sto­sun­ku do resz­ty, ele­ment Wykonawca procesu”.

Teraz robi­my test myślo­wy, każ­dy z czy­tel­ni­ków sam: patrz­my na powyż­szy dia­gram (model defi­ni­cji pro­ce­su biz­ne­so­we­go) i sami sobie odpo­wia­da­my na pyta­nie: ile w danym kon­kret­nym (Waszym jako prze­ło­żo­ne­go) przy­pad­ku wie­dzy” tkwi w oso­bie Wykonawca pro­ce­su” (tu sym­bol kar­tecz­ka” sym­bo­li­zu­je tre­ści zna­ne tyl­ko jemu, nie­za­pi­sa­ne nigdzie indziej) a ile zosta­ło udo­ku­men­to­wa­ne w pozo­sta­łych. Druga faza eks­pe­ry­men­tu: zni­ka” oso­ba Wykonawca pro­ce­su”, jak zadzia­ła pro­ces i ile cza­su zaj­mie uzu­peł­nie­nie tego bra­ku kadrowego.

Tu czy­ni­my zało­że­nie: im mniej wie­dzy” w pozo­sta­łych kar­tecz­kach” a wię­cej w gło­wie Wykonawcy pro­ce­su, tym bar­dziej cią­głość dzia­ła­nia pro­ce­su (fir­my, orga­ni­za­cji) jest zagro­żo­na… Po dru­gie, na począ­tek war­to w ogó­le mieć wie­dzę, gdzie i co jest poza­pi­sy­wa­ne i czy w ogó­le gdzieś jest… a cytat, jest po to, by nikt mi tu nie pisał, że to nie­moż­li­we ;), bo to, że to mało praw­do­po­dob­ne to wie­my, ale wie­my tak­że, że bar­dzo boli jak się przytrafi.

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 15 komentarzy

  1. jacek2v

    Bardzoooo przed­mio­to­we trak­to­wa­nie pra­cow­ni­ków 🙁 Ludzie to nie try­bi­ki pro­ce­su biz­ne­so­we­go. Jeśli przyj­mie się takie podej­ście do zarzą­dza­nia, to ryzy­ko odej­ścia klu­czo­wych pra­cow­ni­ków znacz­nie maleje.
    Nie negu­ję doku­men­to­wa­nia pro­ce­sów, ale wie­dza prze­la­na na papier” ma wie­le wad. Wymienię trzy: jest ZAWSZE nie­peł­na, jest STATYCZNA – nie reagu­je na zmia­ny i jest A‑KREATYWNA – wpły­wa nega­tyw­nie na kre­atyw­ność uczest­ni­ków pro­ce­su i przez to hamu­je rozwój/ulepszanie procesu.
    Paradoksalnie ostat­nia wada może też być zale­tą :), bo spi­sa­nie pro­ce­su, czę­sto ujaw­nia jego sła­bość. Czyli jak to czę­sto bywa nale­ży wszyst­kie­go pró­bo­wać”, ale z umiarem.

    1. Jarek Żeliński

      Pytanie: uzu­peł­nie­nie zaso­bu czy­li jak będzie wyglą­da­ła rekru­ta­cja nowe­go pra­cow­ni­ka w miej­sce tego, któ­ry znie­nac­ka znik­nie z fir­my (wypa­dek, zwol­nie­nie dys­cy­pli­nar­ne, prze­ję­cie przez kon­ku­ren­cję, inne…) bez infor­ma­cji o tym jaką rolę peł­nił i co powi­nien umieć (a od nie­go się tego już nie dowiemy)?

  2. jacek2v

    Jeśli ma Pan na myśli rekru­ta­cję to spra­wa pro­sta. Każdy zatrud­nio­ny pra­cow­nik w dzia­le kadr ma/powinien mieć opis sta­no­wi­ska pracy/zakresu obo­wiąz­ków + wyso­kość upo­sa­że­nia + miej­sce w hierarchii.
    Zapewne miał Pan też na myśli, wdro­że­nie nowe­go pra­cow­ni­ka. Tak jak napi­sa­łem wcze­śniej: nie negu­ję potrze­by doku­men­to­wa­nia”. Zwracam też Pana uwa­gę, że więk­szość opi­sów pro­ce­sów biz­ne­so­wy dez­ak­tu­ali­zu­ją się tuż po ich dokoń­cze­niu lub nawet przed. Dlatego nale­ży zacho­wać z tym umiar tak w szcze­gó­ło­wo­ści doku­men­to­wa­nia (aby nie prze­dłu­żać), jak i spo­so­bie trak­to­wa­nia uczest­ni­ków (aby nie spro­wa­dzać pra­cow­ni­ków do pozio­mu przedmiotów).
    Najlepszym spo­so­bem zacho­wa­nia umia­ru jest wple­ce­nie uczest­ni­ków w same opi­sy­wa­nie pro­ce­su biz­ne­so­we­go – będzie to wyma­ga­ło uprosz­cze­nie narzę­dzi. Oraz mak­sy­mal­ne skró­ce­nie dro­gi pomię­dzy mode­lem, a dzia­ła­ją­cym sys­te­mem wspie­ra­ją­cym model. Idealne było­by by sys­tem był 100% odbi­ciem modelu.

    1. Jarek Żeliński

      Skoro zga­dza­my się co do potrze­by posia­da­nia udo­ku­men­to­wa­nych zakre­sów obo­wiąz­ków i wyma­ga­nych umie­jęt­no­ści na danym sta­no­wi­sku pozo­sta­je kwestia:

      Zwracam też Pana uwa­gę, że więk­szość opi­sów pro­ce­sów biz­ne­so­wy dez­ak­tu­ali­zu­ją się tuż po ich dokoń­cze­niu lub nawet przed. Dlatego nale­ży zacho­wać z tym umiar tak w szcze­gó­ło­wo­ści doku­men­to­wa­nia (aby nie prze­dłu­żać), jak i spo­so­bie trak­to­wa­nia uczest­ni­ków (aby nie spro­wa­dzać pra­cow­ni­ków do pozio­mu przedmiotów).

      Jeżeli zacho­dzi sytu­acja zda­nia pierw­sze­go to zna­czy, ze model był (jest) po pro­stu zły. Co do zda­nia dru­gie­go, owszem ale umiar tu powi­nien pole­gać na umie­jęt­nym odcię­ciu zbędnych/złych szcze­gó­łów a nie na skró­ce­niu cza­su trwa­nia same­go modelowania 🙂

  3. jacek2v

    Jeżeli zacho­dzi sytu­acja zda­nia pierw­sze­go to zna­czy, ze model był (jest) po pro­stu zły. ”
    Model nie musiał być zły, czę­sto pro­ces jego two­rze­nia był zbyt długi.

    Co do zda­nia dru­gie­go, owszem ale umiar tu powi­nien pole­gać na umie­jęt­nym odcię­ciu zbędnych/złych szcze­gó­łów a nie na skró­ce­niu cza­su trwa­nia same­go modelowania”
    A jakie szcze­gó­ły są zbędne/złe? 🙂 A może to co odciął” ana­li­tyk są solą” same­go procesu?
    Nie zgo­dzę się, czas ma decy­du­ją­cą rolę. Podstawowa rola sys­te­mów infor­ma­tycz­nych to skró­ce­nie cza­su prze­twa­rza­nia infor­ma­cji. Co po sys­te­mie, któ­ry powsta­je za póź­no w sto­sun­ku do realiów biznesu?
    BTW: Uważam, że nie ma systemów/aplikacji skoń­czo­nych. Aplikacje mają nie­skoń­czo­ny cykl życia, tyl­ko cza­sa­mi jak są nie­roz­wi­ja­ne powo­li umierają.

    1. Jarek Żeliński

      Widzę kolej­ny przy­kład mie­sza­nia pozio­mu szcze­gó­łów. Po pierw­sze na odpo­wied­nio wyso­kim pozio­mie abs­trak­cji nale­ży opi­sać pro­ces z per­spek­ty­wy celo­wo­ści a nie szcze­gó­łów danych jakie są prze­twa­rza­ne (naj­pierw upew­nia­my się, że jakiś pro­ces w ogó­le cze­muś słu­ży, a potem dopie­ro pono­si­my kosz­ty jego pro­jek­to­wa­nia). Jeżeli ktoś uwa­ża, że wystar­czy poznać szcze­gó­ły tre­ści doku­men­tów (sól pro­ce­su) a nie ma cza­su na zro­zu­mie­nie samej jego celo­wo­ści ich uży­cia (lub jej bra­ku) to już ma kło­po­ty, imple­men­tu­jąc jakieś pro­ce­sy nie mając pew­no­ści czy są w ogó­le potrzeb­ne lub w jakiej posta­ci. Największym błę­dem wie­lu firm pro­gra­mi­stycz­nych jest uzna­nie, że stan jaki zasta­li u klien­ta, pozy­ska­ny z ust jego pra­cow­ni­ków jest sta­nem ocze­ki­wa­nym i wła­ści­wym. Większość firm pro­gra­mi­stycz­nych zacho­wu­je się jak kiep­ski lekarz: wypi­su­ją recep­tę pod dyk­tan­do pacjenta. 

      Co to zna­czy, że two­rze­nie mode­lu trwa zbyt dłu­go?”. To brzmi trosz­kę jak nie ma cza­su na bada­nia, żryj­my w koń­cu jakieś pigu­ły”. Zbędne szcze­gó­ły to podej­ście nie wie­my co jest istot­ne więc spi­su­je­my wszyst­ko”. To bar­dzo kosz­tow­ne pro­jek­ty. Dobrze wyko­na­na ana­li­za ma ogrom­ną zale­tę: poka­zu­je to co istot­ne. a nie wszyst­ko. Czym, są rze­czy nie­istot­ne”? To te, któ­re nie mają wpły­wu na pro­jekt a wie­my że się u klien­ta dzieją. 

      Podstawową rola sys­te­mów nie jest skra­ca­nie, a umoż­li­wia­nie. Prosty przy­kład: kie­dyś, w dobie ręcz­nej księ­go­wo­ści, księ­go­wa­nie trwa­ło tak samo dłu­go, bo dłu­żej nie mogło trwać (ter­mi­ny urzę­do­we). Dzięki sys­te­mom FK teraz moż­na (led­wo miesz­cząc się przed ter­mi­nem skła­da­nia dekla­ra­cji podat­ko­wych) liczyć kosz­ty mając wię­cej danych niż 20 lat temu czy­li dokład­niej, nie raz fak­tycz­nie tak­że szyb­ciej. Pewne rze­czy wręcz nie było robio­ne, aktu­ali­za­cja kart maga­zy­no­wych odby­wa­ła się po pew­nym cza­sie na bazie fak­tur, teraz stan maga­zy­nu mamy w cza­sie rze­czy­wi­stym” – to jest korzyść. Szybkość prze­twa­rza­nia to fak­tycz­nie klu­czo­wa cecha kom­pu­te­ra ale samo robie­nie szyb­kiej” nie jest postę­pem, postęp to czę­sto robie­nie ina­czej”. Typowym przy­kła­dem jest ema­il, kom­pu­te­ry i sie­ci nie spo­wo­do­wa­ły szyb­sze­go ruchu listo­no­sza, zastą­pi­ły bo innym medium, nowym nośni­kiem tre­ści listów. Komputer nie spo­wo­do­wał, szyb­sze­go księ­go­wa­nia na tak zwa­nej ame­ry­kan­ce” tyl­ko pozwo­lił na prze­bu­do­wę sys­te­mu zarzą­dza­nia finan­sa­mi (jedy­ne co się nie zmie­nia to sys­tem kont) itd. Bardzo kiep­ską fir­mą jest ta, któ­ra tyl­ko spi­su­je dokład­nie to co robi użyt­kow­nik na papie­rze” i prze­no­si mu to do kom­pu­te­ra. To jest model biz­ne­so­wy IT ana­li­tyk dyk­ta­fon i pro­gra­mi­sta skryba”.

      Dobra kom­pu­te­ry­za­cja” to zmia­na a nie przy­śpie­sza­nie”.…

      Co do apli­ka­cji biz­ne­so­wych. One nie mogą być nigdy nie nie­skoń­czo­ne” bo biz­nes wyma­ga choć trosz­kę sta­bil­no­ści. Dobrze zarzą­dza­ny cykl życia pro­duk­ty ma okre­sy sta­bil­ne, zmia­ny są wpro­wa­dza­na w jakimś cyklu a nie na już” bo wte­dy użyt­kow­nik nie jest w sta­nie prze­wi­dzieć zacho­wa­nia wła­sne­go narzę­dzia pra­cy. Dobre sys­tem, ERP i nie tyl­ko, bo ope­ra­cyj­ne tak­że, żyją od wer­sji do wer­sji, w mię­dzy cza­sie są wpro­wa­dza­ne jedy­nie kry­tycz­ne popraw­ki. To, że cykl życia jakie­goś pro­duk­tu nie zakoń­czył się, że nie zna­czy, że ma byc per­ma­ne­net­nie roz­grze­ba­ny”.

  4. jacek2v

    JŻ:„Widzę kolej­ny przy­kład mie­sza­nia pozio­mu szczegółów…”
    Pisząc o soli pro­ce­su” mia­łem na myśli głów­ną istotę/sens pro­ce­su nie­za­leż­nie od tego na jakim pozio­mie szcze­gó­ło­wo­ści on się poja­wi. Np. może to być: pod­bi­cie pie­cząt­ki przez war­tow­ni­ka na bra­mie (duża szcze­gó­ło­wość) lub świa­do­mość, że prze­sył­ka jest w dro­dze (wyso­ki poziom abstrakcji).

    JŻ:„Największym błę­dem wie­lu firm pro­gra­mi­stycz­nych jest uzna­nie, że stan jaki zasta­li u klien­ta, pozy­ska­ny z ust jego pra­cow­ni­ków jest sta­nem ocze­ki­wa­nym i właściwym.”
    Tak, cza­sa­mi tak się zda­rza. Ale czę­ściej jest tak, że powo­dem pro­ble­mów jest nie­po­ro­zu­mie­nie wyni­ka­ją­ce ze wza­jem­ne­go nie­zro­zu­mie­nia ról: dostaw­cy i klienta. 

    JŻ:„Dobrze wyko­na­na ana­li­za ma ogrom­ną zale­tę: poka­zu­je to co istot­ne. a nie wszyst­ko. Czym, są rze­czy ?nie­istot­ne?? To te, któ­re nie mają wpły­wu na pro­jekt a wie­my że się u klien­ta dzieją.”
    Definicja poże­ra­ją­ce­go same­go sie­bie węża”:
    Co jest istot­ne -> to co ma wpływ na pro­jekt -> a co ma wpływ na pro­jekt -> to co jest istotne 🙂
    Ja wolę defi­ni­cję taką: Istotne dla pro­jek­tu jest to co dla klien­ta przy­nie­sie WARTOŚĆ. A WARTOŚĆ testu­je­my poprzez wery­fi­ko­wa­nie przez klienta.

    JŻ:„Podstawową rola sys­te­mów nie jest skra­ca­nie, a umożliwianie.”
    Proponuję jeden test na oba­le­nie tej tezy: pro­szę podać jeden przy­kład, cze­go nie moż­na zro­bić bez ERP, przy zało­że­niu, że mamy dowol­nie dużo czasu.

    JŻ:„Co do apli­ka­cji biz­ne­so­wych. One nie mogą być ?nigdy nie nie­skoń­czo­ne? bo biz­nes wyma­ga choć trosz­kę stabilności. ”
    Ależ one zawsze są nie­skoń­czo­ne 🙂 ZAWSZE poja­wi się użyt­kow­nik, któ­ry dostrze­że moż­li­wość zmiany/ulepszenia.

    JŻ:„Dobrze zarzą­dza­ny cykl życia pro­duk­ty ma okre­sy stabilne, …”
    Tu zaprze­cza Pan sam sobie. Cykl to RUCH nie STAN. Zrozumiałe jest, że aby biec cza­sa­mi trze­ba posta­wić nogę na zie­mi” i przez moment jest niby sta­bil­nie. Ale bez świa­do­mo­ści, że to tyl­ko na chwi­lę ina­czej byśmy sta­wia­li nogi. To jest kwe­stia myśle­nia do przo­du, a nie zachowawczego/bezpiecznego. Konsekwencje wybra­nia dru­giej dro­gi: Kto stoi w miej­scu ten się cofa.”

    JŻ:”..bo wte­dy użyt­kow­nik nie jest w sta­nie prze­wi­dzieć zacho­wa­nia wła­sne­go narzę­dzia pracy.”
    Zmiana wca­le nie musi być widocz­na dla użyt­kow­ni­ka. A czę­sto zmia­na na lep­sze mimo tego, że jest widocz­na, jest dla użyt­kow­ni­ka nie­zau­wa­ża­na. Ze zmia­na­mi na gor­sze tak już nie jest 🙂

    1. Jarek Żeliński

      1. pod­bi­cie pie­cząt­ki na bra­nie to ele­ment pro­ce­du­ry wej­ścia na strze­żo­ny teren a nie proces.
      2. rola dostaw­cy i klien­ta w pro­jek­cie to treść zawar­tej umo­wy, nie ma tu nie nie­po­ro­zu­mień a co naj­wy­żej zła lub nie­prze­strze­ga­na umowa.
      3. np. uspraw­nie­nie pro­ce­su sprze­da­ży jest celem klient, pro­jekt infor­ma­tycz­ny to wyko­na­nie pro­gra­mu do two­rze­nia fak­tur VAT, o war­to­ści dla klien­ta decy­du­je on sam, pro­gra­mi­sta na wyko­nać na bazie wyma­gań, pro­gram do wysta­wia­nia fak­tur VAT i tyl­ko to jest tu istotne.
      4. podob­nie jak Archimedes (daj­cie mi punkt opar­cia a poru­szę Ziemię) nikt nie ma nie­ogra­ni­czo­nych zaso­bów i nie jest to żaden dowód. Ja świa­do­mie napi­sa­łem o ogra­ni­czo­nym czasie
      5. Pomysł użyt­kow­ni­ka, gdy się poja­wi, nie ozna­cza, że nale­ży ten pomysł realizować.
      6. poja­wia­nie się nowych wer­sji np. kwar­tal­nie a nie co sekun­dę nie ma nic wspól­ne­go z zastojem,
      7. jeże­li użyt­kow­nik nie widzi zmia­ny tego co zaszło w opro­gra­mo­wa­niu, to zapew­ne mamy do czy­nie­nia z refak­to­ry­za­cją a nie zmianą. 

      Na koniec: to Zarząd fir­my nią zarzą­dza a nie dostaw­ca opro­gra­mo­wa­nia, ta dru­ga sytu­acja bar­dzo źle świad­czy o tym Zarządzie i wte­dy wła­śnie mamy przy­pa­dek pomie­sza­nia ról w projekcie.

  5. Jarek Żeliński

    Dyskusje o szcze­gó­ło­wo­ści mode­lu pro­ce­sów” poja­wia­ją się nie­mal­że w każ­dym pro­jek­cie, powyż­szy arty­kuł zawie­ra dia­gram jaki sta­no­wi pod­sta­wę ana­li­zy. pro­blem poja­wia się w tych pro­jek­tach, w któ­rych ana­li­tyk nie potra­fi wła­ści­we przy­pi­sać odkry­wa­nych fak­tów (szcze­gó­łów) i z wszyst­kich two­rzy kro­ki i ele­men­ty pro­ce­su” co jest poważ­nym błędem.

  6. jacek2v

    Ad.1 Tak.
    Ad.2 Oczywiście, że umo­wa. Ale jak­że czę­sto umo­wa zawie­ra : umo­wa na wyko­na­nie sys­te­mu XYZ 🙂
    Ad.3 A nie lepiej jak pro­gra­mi­sta wie jaki jest cel klienta?
    Ad.4 Przekornie odwra­ca­jąc: dla­te­go, że nie mamy ogra­ni­czo­nych zaso­bów cza­su robi­my dużo by go mniej mar­no­wać. Np. wspo­mnia­ne uspraw­nie­nie pro­ce­su sprze­da­ży” czyż nie cho­dzi tu o zmniej­sze­nie cza­su obsłu­gi jed­ne­go klien­ta? Wszystko odby­wa się w funk­cji cza­su. Po pro­stu apli­ka­cje są po to by ludzie mie­li wię­cej cza­su na myślenie.
    Ad.5 Oczywiście. Nierealizowanie też nie­sie ze sobą naukę/rozwój aplikacji.
    Ad.6 Co sekun­dę to prze­sa­da :), ale nie wia­do­mo kie­dy to stagnacja.
    Ad.7 A zmia­na pro­to­ko­łu sie­cio­we­go lub pole­ga­ją­ca na pobie­ra­niu kur­sów walut z inne­go banku?
    Ad.8 W kon­tek­ście budo­wa­nia archi­tek­tu­ry, pro­jek­to­wa­nia, imple­men­ta­cji i utrzy­ma­nia apli­ka­cji to źle wró­ży dla koń­co­wych efek­tów. Nawet jak Zarząd posia­da odpo­wied­nie umie­jęt­no­ści, może mu wte­dy zabrak­nąć cza­su na zarządzanie.

    1. Jarek Żeliński

      Ogólnie: Umowa na wyko­na­nie powin­na zawie­rać opis przed­mio­tu jaki ma powstać. Umowa na wyko­na­nie to nie umo­wa na zarzą­dza­nie i podej­mo­wa­nie decy­zji mene­dżer­skich. Umowa na wyko­na­nie to nie jest umo­wa ana pro­jek­to­wa­nie. W prze­ciw­nym wypad­ku mamy wła­śnie pomie­sza­nie ról w projekcie.

  7. jacek2v

    JŻ:„Ogólnie: Umowa na wyko­na­nie powin­na zawie­rać opis przed­mio­tu jaki ma powstać”
    To za mało. Nie wystar­czy zapi­sać, że dostaw­ca ma dostar­czyć pro­dukt. Muszą być też opi­sa­ne odpo­wie­dzial­no­ści, albo ina­czej pro­duk­ty przej­ścio­we – jak np. analiza/dokument analizy.

    Z bra­ku okre­śle­nia odpo­wie­dzial­no­ści w umo­wie poja­wia­ją pro­ble­my ze zro­zu­mie­niem ról. Te pro­ble­my wyni­ka­ją z bra­ku zro­zu­mie­nia co jest decy­zją techniczną/technologiczną, a co jest decy­zją zarządczą/biznesową. Oczywiście z każ­dą umo­wą moż­na sobie pora­dzić na projekcie 🙂

    1. Jarek Żeliński

      No i mamy kon­klu­zję: ” Umowa na wyko­na­nie powin­na zawie­rać opis przed­mio­tu jaki ma powstać” i oczy­wi­ście powin­no­ści (role) każ­dej ze stron umowy.

  8. jacek2v

    🙂
    Dobrego Świętowania i Najlepszego Nowego Roku

Dodaj komentarz

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