Czy wdrożenie zawsze wymaga reorganizacji?

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi ini­cjo­wa­ny­mi przez śred­nie kadry kie­row­ni­cze dużych firm i urzę­dów, czę­sto mają one pew­ną wspól­ną cechę: nie może­my nic zmie­niać w stra­te­gii orga­ni­za­cji ale chce­my uspraw­nić pra­cę w naszym wydzia­le”. To z regu­ły bar­dzo cen­na ini­cja­ty­wa ale tak­że dobra dro­ga do poraż­ki pro­jek­tu. W urzę­dach czę­sto na gra­ni­cy łama­nia pra­wa… a nie raz z jego łama­niem. 

Projekty w admi­ni­stra­cji publicz­nej mają dodat­ko­wą spe­cy­fi­kę: zasa­dy usta­la pra­wo­daw­ca a nie mene­dżer orga­ni­za­cji. Bardzo dobrze opi­sał to zja­wi­sko prof. Bolesław Szafrański wska­zu­jąc przy­czy­nę wie­lu pora­żek wdro­żeń w admi­ni­stra­cji. Opisał trzy-eta­po­wy refe­ren­cyj­ny (i zale­ca­ny) pro­ces wdra­ża­nia nowych roz­wią­zań, a na jego tle, w swo­im opra­co­wa­niu, wska­zał dostrze­żo­ne zanie­dba­nia administracji:

(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, Architektura kor­po­ra­cyj­na ? pro­ble­my nie tyl­ko pojęciowe”)

Cytuję to opra­co­wa­nie, bo model ten jest bar­dzo podob­ny do ogól­nej trój­war­stwo­wej kon­cep­cji orga­ni­za­cji. Prof Szafrański zwra­ca uwa­gę na to (z czym się zga­dzam), że kolej­ność podej­mo­wa­nia decy­zji i dzia­łań, powin­na być nastę­pu­ją­ca: opra­co­wa­nie nowej lub zmie­nio­nej stra­te­gii (Dokument stra­te­gicz­ny), opra­co­wa­nie tak­ty­ki dzia­ła­nia (Model ope­ra­cyj­ny dzia­ła­nia) oraz opra­co­wa­nie pla­nu wdro­że­nia IT (Fundament dzia­łal­no­ści, w kon­tek­ście Architektury Korporacyjnej). Oczywiście nic nie stoi na prze­szko­dzie, by ini­cja­ty­wa wyszła od dołu”.

W swo­im opra­co­wa­niu prof. Szafrański wska­zu­je, że wdro­że­nie nowej stra­te­gii wyma­ga spraw­dze­nia i ewen­tu­al­ne­go opra­co­wa­nia nowych mecha­ni­zmów, pro­ce­dur, pra­wa, pozwa­la­ją­ce­go nie tyl­ko wdro­żyć nową stra­te­gię ale tak­że sku­tecz­nie ją wymu­sić”.

Jeżeli powyż­szy model uogól­nić do posta­ci obra­zu­ją­cej zwią­zek pomię­dzy: stra­te­gią ryn­ko­wą orga­ni­za­cji, wewnętrz­ną tak­ty­ką reali­za­cji misji oraz tym jak zosta­ły one zaim­ple­men­to­wa­ne, to powsta­nie taki oto dia­gram (po pra­wej zna­ne od lat opra­co­wa­nie Business Process Trends):

Jeżeli pomiąć for­mę praw­ną, każ­da orga­ni­za­cja ma stra­te­gię i każ­da jakoś ją reali­zu­je (imple­men­tu­je: ma pra­cow­ni­ków a Ci umie­jęt­no­ści i zakre­sy obo­wiąz­ków). Mało któ­ra orga­ni­za­cja ma tak zwa­ny model ope­ra­cyj­ny”, czy­li to co łączy stra­te­gię i ludzi z ich obo­wiąz­ka­mi i uzy­ski­wa­ny­mi efek­ta­mi pra­cy. Czym jest taki model? To model pro­ce­sów biz­ne­so­wych: środ­ko­wa war­stwa” powyż­sze­go dia­gra­mu po prawej.

Rozwijające się ewo­lu­cyj­nie orga­ni­za­cje zawsze doku­men­tu­ją deta­le prac (infor­ma­cje w pro­ce­du­rach zarzą­dza­nia jako­ścią i tak zwa­nych doku­men­tach kadro­wych), czę­sto doku­men­tu­ją to, jaką rolą peł­ni orga­ni­za­cja w swo­im oto­cze­niu (misja, wizja, stra­te­gie itp.) i bar­dzo rzad­ko doku­men­tu­ją wewnętrz­ny łań­cuch war­to­ści czy­li pro­ce­sy biz­ne­so­we oraz, no naj­waż­niej­sze, logi­ka tego jak to wszyst­ko dzia­ła” w środ­ku (i czy dzia­ła z sen­sem). Wadą więk­szo­ści tego typu pro­jek­tów, jakie obser­wu­ję, jest sku­pia­nie się na deta­lach i pomi­ja­nie pryn­cy­piów. W efek­cie pro­jekt pochła­nia wie­le pra­cy i nadal nie mamy zro­zu­mie­nia cało­ści (w lit. ang. big pic­tu­re”), osią­ga­ne efek­ty są losowe. 

Pokażę na dość pro­stym przy­kła­dzie o czym mowa (pole­cam ww. opra­co­wa­nie prof. Szafrańskiego, opi­sał w nim błę­dy popeł­nio­ne w przy­pad­ku infor­ma­ty­za­cji Państwa). 

Poniższy dia­gram to uprosz­czo­ny model orga­ni­za­cji z zain­sta­lo­wa­nym sys­te­mem EOD (Elektroniczny Obieg Dokumentów) oraz zacho­wa­nym, nadal wyko­rzy­sty­wa­nym po sta­re­mu” opro­gra­mo­wa­niem pocz­ty elektronicznej. 

Linie cią­głe to dro­ga jaką poko­nu­ją doku­men­ty z uży­ciem EOD. Linie prze­ry­wa­ne to pocz­ta elek­tro­nicz­na. Jeżeli zosta­nie w jakiejś orga­ni­za­cji zain­sta­lo­wa­ny EOD (celo­wo nie uży­wam sło­wa wdro­żo­ny”) i nie zosta­nie z niej usu­nię­ty ema­il jako narzę­dzie alter­na­tyw­nej wewnętrz­nej komu­ni­ka­cji, to użyt­kow­nik będzie sam decy­do­wał, o tym któ­rym kana­łem prze­ka­że daną treść. W efek­cie EOD, któ­ry miał mieć wszyst­ko” nie ma wszyst­kie­go, dane w EOD są nie­wia­ry­god­ne i nie­kom­plet­ne. Jeżeli jest to urząd, to metry­ka spra­wy w zasa­dzie nie ma sen­su, celem jej two­rze­nia była moż­li­wość odtwo­rze­nia peł­ne­go prze­bie­gu spra­wy, a tu urzęd­nik sam decy­du­je, któ­re infor­ma­cje i doku­men­ty prze­ka­zu­je kana­łem for­mal­nym (EOD), a któ­re na boku”. Czy wszyst­ko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tyl­ko uzna­nio­wym archi­wum dokumentów. 

Aby sku­tecz­nie wdro­żyć EOD nale­ży naj­pierw opra­co­wać nowy model ope­ra­cyj­ny dzia­ła­nia orga­ni­za­cji, model uwzględ­nia­ją­cy nowe narzę­dzie pra­cy, model któ­ry w spo­sób sys­te­mo­wy wyeli­mi­nu­je nie­po­żą­da­ne ele­men­ty złe­go sta­re­go sys­te­mu”. Dla przy­kła­du powy­żej nale­ży wyeli­mi­no­wać kana­ły komu­ni­ka­cyj­ne ozna­czo­ne linią prze­ry­wa­ną. Domyślam się, że wie­lu czy­tel­ni­ków myśli teraz no jak to tak bez maila?!”. Po wdro­że­niu EOD, wewnętrz­ny mail jest już nie potrzeb­ny (a nawet jest szko­dli­wy), a na zewnątrz nadal jest narzę­dziem komu­ni­ka­cji fir­ma-fir­ma (tak np. dzia­ła mój sys­tem komu­ni­ka­cji z klien­ta­mi). Bardzo czę­sto spo­ty­kam urzę­dy i fir­my, w któ­rych obieg ema­il i obieg for­mal­ny” to uzna­nio­wość pra­cow­ni­ków. Te wdro­że­nia nie speł­nia­ją pod­sta­wo­wej roli sys­te­mów EOD: śle­dze­nie spraw, sta­ty­sty­ki zaję­to­ści pra­cow­ni­ków, wychwy­ty­wa­nie wąskich gar­deł, łatwe zastę­po­wa­nie się pra­cow­ni­ków, moż­li­wość skon­tro­lo­wa­nia i prze­ję­cia spra­wy w dowol­nym momen­cie, peł­na histo­ria wymia­ny informacji. 

Takie wdro­że­nia to wła­śnie bar­dzo czę­sto ini­cja­ty­wy na śred­nich szcze­blach, gdzie mogą powstać decy­zje o wyda­niu środ­ków na takie wdro­że­nie, ale nie ma żad­nych szans na decy­zje o opra­co­wa­niu i wdro­że­niu zmian ope­ra­cyj­nych w ska­li orga­ni­za­cji (np. aktu­ali­za­cja instruk­cji kan­ce­la­ryj­nej w urzę­dzie, bez cze­go wdro­że­ni EOD nie ma tu żad­ne­go sensu).

Celowo poda­łem ten przy­kład, bo typo­wym powo­dem nie­po­wo­dzeń wdro­żeń sys­te­mów EOD czy CRM (te sys­te­my mają naj­gor­szą sta­ty­sty­kę nie­po­wo­dzeń, a są bar­dzo podob­ne do sie­bie), jest brak opra­co­wa­ne­go i wdro­żo­ne­go sku­tecz­ne­go nowe­go ope­ra­cyj­ne­go mode­lu dzia­ła­nia orga­ni­za­cji po wdro­że­niu”. Takim mode­lem są mode­le pro­ce­sów biz­ne­so­wych, ale nie w posta­ci mon­stru­al­nych ilo­ści deta­licz­nych dia­gra­mów (te są tu do nicze­go nie przy­dat­ne). Nie znam przy­pad­ku, by takie obraz­ki” się do cze­go­kol­wiek przy­da­ły. Chodzi o mode­le sfor­ma­li­zo­wa­ne, o ści­śle usta­lo­nym pozio­mie gra­da­cji pro­ce­sów. Ile dia­gra­mów powin­no być”? Tylko i aż tyle, ile trze­ba do roz­wią­za­nia pro­ble­mu… co opi­sa­łem mię­dzy inny­mi tu.

Powyższe ma tak­że inny istot­ny aspekt: pla­no­wa­nie i wdra­ża­nie zmian. Typowy roz­wój orga­ni­za­cji prze­bie­ga w spo­sób ewo­lu­cyj­ny, dość powol­ny. Nie wyma­ga żad­nych dodat­ko­wych zabie­gów poza prze­my­śla­nym wpro­wa­dza­niem nowych, poje­dyn­czych zarzą­dzeń czy drob­nych zmian orga­ni­za­cyj­nych. Jednak pró­by wdro­że­nia znacz­nych zmian w krót­kim cza­sie, z regu­ły skut­ku­ją nie­ocze­ki­wa­ny­mi efek­ta­mi, nie zawsze pożą­da­ny­mi. Moda” na re-inży­nie­rię pro­ce­sów biz­ne­so­wych w latach 90-tych prze­mi­nę­ła tak szyb­ko jak się poja­wi­ła. Dzisiejszy sil­nie kon­ku­ren­cyj­ny rynek nie daje cza­su na powol­ne, ewo­lu­cyj­ne zmia­ny. Bezpieczne zaś wpro­wa­dza­nie takich zmian nie jest moż­li­we bez przy­go­to­wa­nia. Opisane powy­żej pla­ny ope­ra­cyj­ne i ich testy, to nic inne­go jak wła­śnie przy­go­to­wa­nie się do takich zmian. Mając dobrze opra­co­wa­ne mode­le pro­ce­sów i archi­tek­tu­ry IT (jako całość Architektura Biznesowa/Korporacyjna), może­my prze­wi­dzieć i prze­te­sto­wać, więk­szość skut­ków pla­no­wa­nych zmian, i powo­li ale coraz wię­cej firm to robi… 

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)