Rozdeľovanie IT zákaziek na časti (návrh verejnej politiky)

Nemozem si pomoct ale toto su hrusky s jablkami. Rozdelovat dodavku a SLA a rozdelovat velky projekt na slabo previazane moduly su podla mna uplne zasadne odlisne temy.

Koniec citacie priamo z dokumentu, o ktorom tu diskutujete.

Nehovoriac o tomto:

no ked uz pri najmensom projekte to prinieslo problemy, tak je dost odvazne tvrdit ze to bude vyborne fungovat pri vacsom.
A len tak bokom, ked ani 18F nezvladlo riadit ani samo seba, tak to naordinovat ako zazracne doporucene riesenie je urcite inovativne, a uspech bude na slovensku s temou nedostatocneho IT staffu zaruceny.

Ok, skúsil som. Nedá sa diskutovať. Tak zase niekedy.

ved hej. Ale aj hrusky aj jablka su ovocie. Ide po princip - rozdelovanie v IT projektoch. Este nevieme ako dopadlo jedno rozdelenie v malickom projekte (a siria sa zbytocne rumours ze nie tak slavne ako boli ocakavania) a uz sa ide navrhovat dalsie rozdelovanie vo velkom IT projekte. No posobi to zvlastne a moc dovery v rozdelovanie za sucasneho nastavenia na SK v statnej sprave (hlavne VO a eurofondy) to nevyvolava. Ze ci by nebolo dobre sa zamysliet v prvom rade nad prerekvizitami za ktorych to rozdelovanie bude vobec na SK fungovat.
To je vsetko k teme odomna, kazdemu je to asi jasne co chcem povedat.

To, ze nefunguje VO v statnej a verejnej sprave tak ako ma, je fakt. To uz je rozumnejsia zalozit stanu IT firmu, cez nu vsetko pojde a gta bude mat svojich certifikovanych dodavatelov a bude rozdelovat pracu. To teoreticky moze fungovat, ale mysliet si, ze ked rozdelim 100 zakaziek na 500, ze to bude dovod aby to zafungovalo, tak to je podla mna hlboky omyl (ano su firmy, ktore radsej nerobia kvoli korupcii, su ktore sa tam nemaju snacu dostat, ale chciet viacej zakaziek aby sa vyriesil tento problem, neviem preco si niekto mysli, ze toto je riesenie, hodne velky BUG). SS nevie zvladnut tych 100 tendrov za 5 rokov, tak uz 500 nezvladne vobec, ak sa nezmeni prostredie a sposob fungovania, nehovoriac o tom, ze keby to aj vedeli vytendrovat, tak to nebude mat kto zosynchronizovat a skoordinovat aby to dokopy fungovalo. Proste z blata do kaluze. Preco sa neurobi VO, tak napr, ako funguje v inych statoch, su tam aj vacsie tendre ako uu nas a su tam aj male, ale nie pre vleke statne organizacie.

suhlasim s tym čo píšeš vo vzťahu k našej domácej úlohe na SND a dovolím si dať protiotázku - aká je alternatíva? Pokračovať v modeli generálnych dodávateľov?

Predstava, že unikátne SW dielo vytvorí firma XY a bude nad ním (a nad všetkými subdodávateľmi a cenami) držať ochrannú ruku a SLA ďalších 20 rokov jeho životnosti bez akéhokoľvek konkurenčného tlaku mi príde smutná a dnes vidíme, že to nerobí dobrotu. Prevziať kompletné dielo a subdodávateľské štruktúry po niekom je veľmi náročné, ak nie nemožné. Takže aj odtiaľ plynie moje racionale pre takéto rozdeľovanie zákaziek.

tu sme sa nepochopili. Ja nehovorím, že 100 tendrov má nahradiť 500 tendrov. Zákazka sa dá rozdeliť aj tak, že v rámci jedného tendra sa nakupujú samostatné časti (moduly) a rola integrátora je buď jednou z častí, alebo pripojená k jednej z tých častí, alebo na strane klienta. Takže čo sa týka počtu VO, pokojne to môže ostať na čísle 100.

Ano tender moze mat samostatne LOTy a firmy sa moze prihlasit na tie ktore si vyberu a niekedy je povedane, ktore sa navzajom vylucuju. ALe ono je to takto zlozitejsie tiez. Toto sa myslelo, pretoze inak jedno obstaravanie a n-vitazov, nepoznam ako by to bolo mozne.

nikto netvrdi, ze tento model je jednoduchsi. Ale v porovnani s alternativou, ktoru som popisal vyssie (generalny dodavatel na celu zivostnost) my ta kompleita za to stoji.

P.S.: nevymyslame nic nove, toto je bezna prax vo verejnej sprave v zahranici a v komercii este viac. Vzhladom na velkost projektov, ake sa v slovenskom publicu robia, sme tu rolu integratorov mali mat uz davno

Standardne v EU ziadna zmluva nemoze byt dlhsia ako 4 roky, teda generelny alebo iny dodavatel sa obstarava na mx. 4 roky a povinnoctou a sucastou zmluvy je prebratie riesenia (ak nie je nove) a odovzdanie riesenia a su to platene cinnosti. Samozrejme ak je s dodavatelom spokojnost, tak ma aj dobre predpoklady uspiet. toto je standard a preco taky nezaviest tu?

Rola integratorov bola v SK tendroch pred 20, 15 aj 10 rokmi, posledne roky to nesledujem a velke organizacie mali SI (vcelmi to aj tak nefungovalo, bol to skor alibizmus)

Zaklad je napisat dobre VO a dobre zadanie. Popravde v SK som take este nevidel, preco sa neberu vzory z tendrov vonku ako detailne/jasne je popisane zadanie ale ja vztahy na okolie a ine moduly. Riadenie je druhy problem a ano podtstany nicitel IT na Slovensku je korupcia.

Už ho navrhujeme v pracovnej skupine Nákup IT - konkrétne max. 2 ročné opcie na prevádzku. Je fajn mať v tých 20 rokoch momenty, keď sa dá umožniť súťaž. Ale aj ako vidíme dnes, pokiaľ ide o model generálneho dodávateľa na celý systém, tak je minimálna šanca, že to niekto prevezme pretože existujúci dodávateľ drží kľúče od miešačky a všetky obchodné vzťahy. Pokial by sa zákazka rozdelila a obchodné vzťahy na jednotlivé časti má samotné OVM, ich výmena by bola jednoduchšia.

A nech to nie je len o tvrdeniach, nech sa páči príklad: Zabezpečenie údržby a SLA parametrov systému Centrálneho elektronického priečinka (IS CEP)

Ak toto vyhrá niekto iný ako DITEC, tak asi zamrzne peklo… A najhoršie je, že po tých 5 rokoch SLA bude FSSR úplne v rovnakej situácii a zase to vyhrá ten istý dodávateľ - na základe toho ako je ten tender napísaný, si dovolím tvrdiť, že takáto budúcnosť FSSR čaká.

To co plati vo velkom, asi plati aj v malo, rovnako tazko je vymeniut dodavatela velkeho systemu ako maleho, akurat nieco je vyzva pre velku firmu a nieco pre malu, principy a pravidla su vsak rovnake

no skusme sine ira te studio.
Porovnavajme alternativy :
. Rozsah projekti je dany studiou v OPII. z pohladu delenia su dve moznosti.

  1. Rozdelit to na mensie dodavky
    2.Nedelit

  2. delenie zakazky aspon teoreticky umozni vacsiu konkurenciu pri sutazi, co moze priniest nizsiu cenu.
    Zaroven uplne urcite prinasa vyssie riziko zlyhania celeho projektu.
    Aby sa to dalo aspon skusit je potrebne mat velmi silne ludske zrdoje u obstaravatela alebo mat systemoveho integratora, ktory to nahradi. Urcite budu vznikat problemy na hraniciach medzi dodavatelmi, co vyzaduje vellmi dobre zmluvy, silne riadenie od pociatku, nastroje na eskalaciu a realne paky na vsetkych.
    V pripade zlyhania jedneho dodoavatela zlyha cely projekt, kedze nebude mozne vcas vysutazit nahradu.
    Princip ze zlyhanie je pripustna moznost je v tomto pripade vazne varovanie.

  3. Sutazit na jedneho dodavatela a naopak pozadovat co najmenej subdodavatelov. Riziko je vyssia cena pre mensiu konkurenciu. Ale je jasna zodpovednost a su nizsie naroky na obstaravatela.

A len pre zaujimavost, jedna velka nadnarodna firma pri urcovani ceny ma pravidlo, ak je jeden subdodavatel tak rizikova marza je 10%, pri troch je 100 % a nad 5 je projekt prilis rizikovy a zamieta sa.
To su dlhorocne skusenosti.

A dalsie poznamky. 18F je priklad ze dobre napady nestacia, vyskusali svoju metoodiku na internych projektoch a vysledkom je ze nezvladli to spravit v rozpocte ani v rozsahu. Aj ked sa to suchalovi nepaci, tak fakty nie su tak presvedcive. Stoji to mozno za vyskusanie v malom ale skusat to experiment na celom state ?

preco prave 2 roky ? Preco nemat povinne moznost vypovedat kedykolvek ci vyjednavat kazdy rok ? Alebo po troch rokoch ?. Co okrem pridanej administrativy to prinesie ?
A v com obchodne vztahy ma OVM jednoduchsie ? Nie je to len zelanie? Su aspon priklady kde sa to da demonstrovat ?

A aky je pohlad napriklad komercneho sektora ?
Preco mam pocit ze mate riesenie a teraz hladate k nemu problem ?

Uplne som nepostrehol, kde 18f zlyhalo. Bol tu nejaky odkaz?

Tu zopar faktov zo stranky, ktoru tu linkujem uz asi piaty krat. GitHub - 18F/Modular-Contracting-And-Agile-Development: Modular contracting and agile development resources.

A kedze 18F to ma presne rovnake problemy, tak tato medicina je skor homeopatikum :slight_smile:
Alebo presnejsie nie je to este dospele riesenie a nie je vhodne ako obecne doporucenie.

No uz asi chapem podstatu toho kde je problem. Ak nejaky modul je natolko kriticky, ze kvoli nemu zlyha vsetko okolo, tak v prvom rade je to problem rozdelenia modulov. (hint: klucove slovo je “volne previazane moduly”). Pointou modularizacie je presny opak toho, cim tu strasite.

Inak kde v tych dvoch reportoch sa spomina cokolvek o rozdelovani IT zakaziek na casti?

priklad : Modul IAM, dobre oddelitelny, jasne rozhranie, obecne zname co bude robit. Je mozne ho oddelit ?
A je jasne ze ked zlyha tak zvysok nebude fungovat ?
A dalsi povedzme ze nejaky modul reportov, ktory zbiera data a vytvara vykazy. Je sice zavisly na vsetkom ale on sam ziadne zavislosti nevytvara. Ak zlyha, tak vsetko ostatne bude sice fungovat ale nenaplni sa ciel projektu a projekt bude neuspesny.

Co je tu pointou modularizacie ? Mam pocit ze sa bavime v inych rovinach, tu nejde o technicke riesenie ale o projektove. Technicky je to dobre oddelitelne ale projektovo nie.

A strasenie ? :slight_smile: nuz preco tak vela projektov zlyhava ? Sktocne su vsetci na svete blbci ?
Je tak mila predstava ze kazdy komplexny sa da rozdelit na nezavisle problemy a mame mily znamy svet malych rieseni. Az na to ze realny svet pozna pojem neredukovatelna komplexnost. Preto sa nie vzdy daju velke problemy nahradit suborom malych.