Przy piąt­ku naszło mnie na zesta­wie­nie pew­nych tre­ści (cyta­ty).

Podczas codzien­nej pra­sów­ki” wpa­dłem na arty­kuł Najczęściej popeł­nia­ne błę­dy pod­czas wdro­że­nia ERP”, oto cytat pierwszy:

- Największym błę­dem popeł­nia­nym przy wdro­że­niach jest nie­zna­jo­mość potrzeb fir­my i nie­wła­ści­we roz­pla­no­wa­nie eta­pów i zakre­su wdro­że­nia… (Najczęściej popeł­nia­ne błę­dy pod­czas wdro­że­nia ERP.).

Katastrofa_budowlana

W pro­jek­tach IT mamy jed­nak naj­czę­ściej tyl­ko dwie stro­ny: inwe­stor (nabyw­ca opro­gra­mo­wa­nia) oraz wyko­naw­ca (dostaw­ca opro­gra­mo­wa­nia i wdro­że­nio­wiec, z regu­ły wysta­wia tak­że kie­row­ni­ka projektu).

Raport z 2011 roku na temat przy­czyn nie­po­wo­dzeń moż­na pod­su­mo­wać tak:

Ponad 80% pro­jek­tów pro­gra­mi­stycz­nych ma prze­kro­czo­ne ter­min i budżet. Największą trud­no­ścią w tych pro­jek­tach oka­za­ło się jasne zro­zu­mie­nie tego, cze­go tak napraw­dę klient potrze­bu­je, oraz udo­ku­men­to­wa­nie jego wyma­gań. Do prze­cho­wy­wa­nia wyma­gań uży­ty był głów­nie word i excel oraz ema­il. Przyznajemy jed­nak, że dia­gra­my naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi to mode­le pro­ce­sów i pro­to­ty­py, jed­nak nie sto­su­je­my ich. ( 2011 State of Requirements Management Report.)

Innymi sło­wy: pomi­ja­my rze­tel­ne ana­li­zy i pro­jek­to­wa­nie poprze­dza­ją­ce reali­za­cje pro­jek­tu, nie mamy pew­no­ści cze­go potrze­bu­je zama­wia­ją­cy, nie mamy doku­men­tów na bazie któ­rych pro­wa­dzi­my pro­jekt. Owszem, wytwo­rze­nie ich to są pew­ne kosz­ty, ale kto odno­si korzyść z takich oszczęd­no­ści”? Nie twier­dze, że jest tak zawsze ale 80% pro­jek­tów wadli­wych to nie tak mało. Gdyby to były budo­wy, licz­ba ofiar na dro­gach to był­by przy nich przy­sło­wio­wy pikuś”.

Inwestycje w opro­gra­mo­wa­nie ERP (i nie tyl­ko) są czę­sto, nie przy­pad­kiem, porów­ny­wa­ne z inwe­sty­cja­mi budow­la­ny­mi. Głównym powo­dem jest podo­bień­stwo eta­pów, względ­nie porów­ny­wal­ne budże­ty i porów­ny­wal­ne ryzy­ko, klu­czo­wą róż­ni­cą jest to, że tyl­ko kata­stro­fa budow­la­na rodzi ogrom­ne ryzy­ko ofiar.

Ustawodawca co praw­da nie­ste­ty nie chro­ni budże­tów IT, chro­ni jed­nak życie swo­ich oby­wa­te­li i powsta­ło Prawo Budowlane, poni­żej cytat. Proszę poniż­sze na spo­koj­nie prze­czy­tać i wyobra­zić sobie, że pra­wo narzu­ci­ło ana­lo­gicz­nie prze­pi­sy dla pro­jek­tów IT, i zasta­no­wić się, co jest przy­czy­ną tego, że takie pra­wo w ogó­le powsta­ło i przed czym chro­ni inwe­sto­ra. W szcze­gól­no­ści pole­cam ostat­ni punkt.

Rozdział 3. Prawa i obo­wiąz­ki uczest­ni­ków pro­ce­su budow­la­ne­go. Artykuł 17 – 27

Dział: Prawo budow­la­ne

Art. 17. Uczestnikami pro­ce­su budow­la­ne­go, w rozu­mie­niu usta­wy, są: 
1) inwestor;
2) inspek­tor nad­zo­ru inwestorskiego;
3) projektant;
4) kie­row­nik budo­wy lub kie­row­nik robót.
[…] 

Art. 18. 1. Do obo­wiąz­ków inwe­sto­ra nale­ży zor­ga­ni­zo­wa­nie pro­ce­su budo­wy, z uwzględ­nie­niem zawar­tych w prze­pi­sach zasad bez­pie­czeń­stwa i ochro­ny zdro­wia, a w szcze­gól­no­ści zapewnienie:
1) opra­co­wa­nia pro­jek­tu budow­la­ne­go i, sto­sow­nie do potrzeb, innych projektów,
2) obję­cia kie­row­nic­twa budo­wy przez kie­row­ni­ka budowy,
[?]

Art. 20. 1. Do pod­sta­wo­wych obo­wiąz­ków pro­jek­tan­ta należy:

1) opra­co­wa­nie pro­jek­tu budow­la­ne­go w spo­sób zgod­ny z usta­le­nia­mi okre­ślo­ny­mi w decy­zji o warun­kach zabu­do­wy i zago­spo­da­ro­wa­nia terenu,

[?]

4) spra­wo­wa­nie nad­zo­ru autor­skie­go na żąda­nie inwe­sto­ra lub wła­ści­we­go organu [?]

[?]

Art. 22. Do pod­sta­wo­wych obo­wiąz­ków kie­row­ni­ka budo­wy należy:

1) pro­to­ko­lar­ne prze­ję­cie od inwe­sto­ra i odpo­wied­nie zabez­pie­cze­nie tere­nu budo­wy wraz ze znaj­du­ją­cy­mi się na nim obiek­ta­mi budow­la­ny­mi, urzą­dze­nia­mi tech­nicz­ny­mi i sta­ły­mi punk­ta­mi osno­wy geo­de­zyj­nej oraz pod­le­ga­ją­cy­mi ochro­nie ele­men­ta­mi śro­do­wi­ska przy­rod­ni­cze­go i kulturowego;
2) pro­wa­dze­nie doku­men­ta­cji budowy;

Art. 24. 1. Łączenie funk­cji kie­row­ni­ka budo­wy i inspek­to­ra nad­zo­ru inwe­stor­skie­go nie jest dopuszczalne.
[?]

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

  1. Sławomir Niemiec

    Miałem kie­dyś przy­jem­ność pra­co­wać w bar­dzo poucza­ją­cym mię­dzy­na­ro­do­wym pro­jek­cie mają­cym na celu wdro­że­nie duże­go sys­te­mu IT. Dla mnie, oso­by z Polski, mają­ce­go doświad­cze­nie i spo­strze­że­nia z lokal­ne­go podwór­ka IT” nie­sa­mo­wi­te było to, jak bar­dzo oddzie­la­no gru­bą kre­ską etap ana­li­zy od kolej­nych dzia­łań pro­jek­to­wych. Co wię­cej, warun­kiem koniecz­nym wystar­to­wa­nia jakie­go kol­wiek pro­jek­tu było przed­sta­wie­nie sponsorowi/inwestorowi obec­ne­go mode­lu reali­za­cji dane­go pro­ce­su biz­ne­so­we­go i ocze­ki­wa­ne­go mode­lu pro­ce­su po wdro­że­niu wyma­ga­ne­go oprogramowania/funkcjonalności. W zależ­no­ści od kra­ju mode­le te były two­rzo­ne wewnątrz orga­ni­za­cji lub zle­ca­ne zewnę­trzym firmą.

    1. Jarek Żeliński

      Przyznam, że znam to z nie tyl­ko z lite­ra­tu­ry (ale mam tu na myśli książ­ki pisa­ne przez prak­ty­ków na eme­ry­tu­rze”) czy kulu­aro­wych roz­mów na kon­fe­ren­cjach. Spotkałem się z tym kil­ka razy, pra­cu­jąc razem albo po” ludziach z zacho­du”. Tam każ­dy kolej­ny etap pra­cy był dowo­dem słusz­no­ści roz­po­czy­na­nia następ­ne­go. Swego cza­su pewien nie­miec­ki kon­sul­tant powie­dział mi: nie pla­nu­je wyłącz­nie ten kto nie rozu­mie tego co robi lub rozu­mie i boi się ujaw­nie­nia (nie­ko­rzyst­nych dla sie­bie) kolej­nych eta­pów planu”.

Dodaj komentarz

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