Prisli nam vyjadrenia k nasim pripomienkam k projektu CES.
4.pripomienka: zavedenie CES predstavuje zásadný zásah do hosp. súťaže v danom segmente. Žiadajú preto dostatočné odôvodnenie postupu, identifikáciu a vyhodnotenie alternatív, nakoľko ciele uvedené pre tento projekt je možné dosiahnuť aj inými než len navrhovanými spôsobmi. Vyplýva aj potreba riešiť zamedzenie vzniku vendor lock-in - tento problém požadujú zaradiť do rizík projektu a identifikovať opatrenia, ktorými sa tomu predíde.
Reakcia MF: vybraný postup je v ŠU zdôvodnený dostatočne a jasne, RZ predstavuje rámec reformy. Alternatívy, ktoré boli zvažované, sú vypracované v zmysle platných metodických usmernení. MF kladie v tomto RZ vysoký dôraz na zabezpečenie “change managementu”, aby garantovalo aj uplatnenie zmien v praxi, nie len zrealizovanie dodávky IS, či iných výstupov. Zvolená platforma, ktorá má len na Slovensku desiatky stredných a veľkých implementátorov je dostatočným nástrojom pre mitigáciu vendor lock-in rizika. Týmto, ak o aj ďalším prípadným rizikám je v prílohách ŠU venovaná osobitná pozornosť.
V studii sa slovo “lock” nachadza 6x a z toho iba 2x to je relevantne:
riziko závislosti od vybraného dodávateľa (vendor lock) je možné mitigovať výberom platformy, ktorá ma na trhu prakticky desiatky možných dodávateľov, pričom súčasťou dodávky má byť aj kompletná dokumentácia (užívateľská, vývojárska a pod.), ktorá MF SR v budúcnosti „uvoľní ruky“ pri výmenách jednotlivých dodávateľov.
Riziko vendor-lock-in je možné mitigovať výberom platformy, ktorá ma na trhu prakticky desiatky možných dodávateľov, pričom súčasťou dodávky má byť aj kompletná dokumentácia (užívateľská, vývojárska a pod.)
Je toto dostatocne? Existuje vobec nejaka statistika kedy toto stacilo na prebratie projektu inym dodavatelom?
Co by ste potrebovali, aby ste skocili do projektu velkosti CES (niekolko desiatok milionov eur)?
Z mojho pohladu (ked si odmyslime, ze robit megaprojekty je riziko same o sebe), tak aby som vobec uvazoval o tom, ze preberiem po niekom projekt potrebujem:
- zaruku, ze tu je dostatok dodavatelov co v tom vie pokracovat (nie nejaky obskurny jazyk, framework alebo konvencie)
- kvalitnu dokumentaciu (od architektury, popisu modelov az po zdokumentovane - rozumne zdrojaky a popis instalacie)
- dodrzane coding standards (toto sa da automatizovat)
- kvalita kodu (toto sa da aspon trochu automatizovat)
- pokrytie testami (unit, integracne) aspon niekde na urovni 90%
- volny pristup k zdrojakom - nech si to viem pozriet a zistit ci to je pravda. (opensource - nech vidime co sa za verejne peniaze nakupuje)
Bez tohto by som sa nechytil ani maleho projektu niekoho ineho, lebo by som sa vystavil obrovskemu riziku, ze nebudem vediet nic urobit.
Ak chceme vyuzivat sutaz naplno tak je potrebne dodatocne zmeny vediet nejako efektivne obstaravat. Napriklad mikroobstaravania v US? Bola by toto schodna cesta? Ako to obstarat u nas? @ps-vo ?
Tento problem sa neustale opakuje. Kazdy jeden novy projekt, ktory nahradza stary legacy projekt robi tie iste chyby. Argumentuje sa, ze zmena stareho systemu by bola drahsia ako vytvorenie noveho. Tak sa postavi novy system, ktory je v momente prevzatia zase legacy system s rovnakym problemom. Nekonecny kruh.
Napady co s tym?