Project

General

Profile

Úkol #3933

Specifikace veř. zakázky

Added by Ondřej Profant almost 3 years ago. Updated 8 months ago.

Status:
Uzavřeno
Priority:
Normální
Start date:
2017-01-02
Due date:
% Done:

100%

Spent time:
Garant:
Vhodné pro dobrovolníka:
No

Description

Cíl vytvoření specifikace registru smluv 2.0. Nepředpokládám, že bychom to dělali dorovolnicky.

Je třeba vejít se do daného budgetu: 600 000 Kč (rok 2016)

Hlavní funkcionality:

  • jednoduché embedování smluv na svůj web
  • inteligentní zadávání smluv (validování etc.)
  • standardizovat další metada
  • trigery nad firmami (neexistující, nedůvěryhodná, ...)
  • ...

History

#10 Updated by Ladislav Nešněra 8 months ago

  • Status changed from V řešení to Uzavřeno
  • % Done changed from 0 to 100

#9 Updated by Jiří Ulip over 2 years ago

Jěště mne napadá k bodu: 6. Portál s vyhledáváním agregující dokumenty a metadata z RS, sekundárního repozitáře a registru metadat. Možnost vytvořit si jednoduchá view (ideálně asi předáním vyhledávacích parametrů přes URL).

Stálo by za zvážení využití existujícího https://www.hlidacsmluv.cz/ - podle mne by autor @michalblaha mohl být ochotný připojit i sekundární repozitář. Mohl by se nad tím Výbor zamyslet?

#8 Updated by Jiří Ulip almost 3 years ago

Na základě debaty s Ondrou a Láďou jsem updatnul zadání. Domluva je, že teď je potřeba provést porovnání našeho zadání s tím, co mají v plánu v rámci BISONU, a potom se rozhodnout jak postupovat. Optimální se jeví nějaká forma spolupráce. Láďa se uvolil, že si vezme na starost průzkum a osobní schůzku.

Upravená verze zadání:

Funkcionality https://smlouvy.gov.cz/ (dále jen RS) chceme rozšířit, nikoliv nahradit. Jednotlivé komponenty jsou na sobě +- nezávislé, takže by měly jít dodat nezávisle na sobě. Do podmínek dejme, že všechny komponenty musí být Open Source a musí mít plně funkční API a také důkladnou dokumentaci. Krom ostrého prostředí musí být součástí i dodávka dev a test prostředí a zálohování dat. Součástí dodávky každého modulu musí být uživatelská dokumentace a elearning. Veškerá data v systému musí být přístupná jako Open Data, jedinou výjimkou bude použití sekundárního repozitáře pro vlastní dokumenty (indikace takových dokumentů musí být součástí standardu). Provoz systému bude primárně řešen jako SaaS pro členy. Nicméně potřebujeme umožnit i on premises instalaci a tím pádem nastavit mechanismus pro slévání dat z lokálních instancí do naší.

  1. Vypracování metodiky a revize standardu smluv tak, aby byl kompatibilní s RS. Je pak nutné vyznačit v něm metadata, která sice nejsou povinná ze zákona (a tudíž je RS ignoruje), ale která zlepší práci se smlouvami. 15 MD
  2. Sekundárního repozitář na dokumenty, které není možné nahrávat do RS (faktury?) Bude třeba nadimenzovat jeho velikost podle zkušeností s RS30 MD
  3. Systému pro správu metadat (třeba tomu říkejme registr metadat) k dokumentům v RS i sekundárním repozitáři. 25 MD
    1. Vytvořit pumpu na metadata z RS do registru metadat, abychom měli i soborům, které budou stále ležet jen v RS základní metadata, která pak budeme moci obohatit o vlastní. Bod vzešel z diskuse s Jiřím Skuhrovcem jako předběžné tržní konzultace. (§ 36 (4) Zákona 134/2016 Sb.) ​​​​4 MD?
  4. Identity Management pro správu subjektů, kteří budou nahrávat dokumenty a data do RS, do sekundárního repozitáře i do registru metadat. IdM bude muset umět zachytit vztahy mezi subjekty (např. městská firma nebo příspěvkovka). Autentizaci bych nechal přes datové schránky, které uže beztak všichni musí mít pro RS35 MD
  5. Rozhraní pro upload dokumentů (i samotných metadat), které umožní vyplnění základních i rozšířených metadat, a provede jeho validaci. Rozhraní musí být přístupné uživatelsky i programaticky a musí podporovat dávkový upload. Pokud bude nahrán dokument patřící výhradně do RS, pak se tam předá i se základními metadaty; rozšířená metadata (+ kopie základních metadat?) bude zanesena do registru metadat. Pokud je nahrán soubor nespadající pod RS, bude uložen do sekundárního repozitáře a jeho metadata budou jen v registru metadat. 35 MD
  6. Portál s vyhledáváním agregující dokumenty a metadata z RS, sekundárního repozitáře a registru metadat. Možnost vytvořit si jednoduchá view (ideálně asi předáním vyhledávacích parametrů přes URL). 35 MD
  7. Možnost embedovat view z portálu do cizích stránek (možnost přestylovat je). 5 MD
  8. Příprava mechanismu pro zpřástupnění aktuálních self deployment balíčků jednotlivých modulů systému. 3 MD
  9. Mechanismus na slévání dokumentů a metadat z lokálních instancí do centrální. 10 MD

 

EDIT: Doplněno na základě feedbacku od Ládi.

EDIT2: Doplněn bod 3.1 . (31. ledna 2017)

#7 Updated by Jiří Ulip almost 3 years ago

Ondřej Profant napsal:

Z mých zkušeností se již na středně velké obci budou bát SAAS. Určitě tam vše nebude opendata, protože ten systém musí umožnit uložit i neanonymizovane věci - nebo to bude úřad tvrdit. Bez toho, aby to umělo i soukromá data to nebudou chtít reálně používat.

Ad SAAS: Chapu to spravne, ze ty bys nechal vyvinout balicky, ktere si kazdy bude moct nasadit a provozovat lokalne u sebe? Odpor k SAAS se podle mne da prekonat, drzet si neco on premises je pekelne neefektivni, zvlast pro male obce a u velkych je to taky problem, protoze se infrastruktura nevyuziva efektivne. Taky tim prijdeme (nebo minimalne zkomplikujememe) existenci jednoho mista, kde se daji vsechny smlouvy, sekundarni dokumenty i metadata k nim najit. Predstavuji si to tak, ze by ten SAAS poskytovala OM. Ale jako mozna jsem zaujaty, protoze v praci leta administruji Salesforce a jsem s jejich filosofii hodne szity.

Co se tyce tech OpenData, myslel jsem, ze nechceme duplikovat existujici document management systemy obci, ale dat jim nastroj na zverejneni toho, co zverejnit chteji. Ale v souvislosti s tim udelat a provozovat online anonymizer by mohlo byt dobre (ale zas je potreba udelat pruzkum trhu, bo je to vec, ktera uz dost mozna za rozumne penize existuje).

#6 Updated by Ondřej Profant almost 3 years ago

Z mých zkušeností se již na středně velké obci budou bát SAAS. Určitě tam vše nebude opendata, protože ten systém musí umožnit uložit i neanonymizovane věci - nebo to bude úřad tvrdit. Bez toho, aby to umělo i soukromá data to nebudou chtít reálně používat.

#5 Updated by Jiří Ulip almost 3 years ago

Ahoj,

Oproti tomu, jak jsme se bavili online, mi celkem jasně krystalizuje zadání. Prošel jsem si původní popis projektu a zjevně musíme líp nadefinovat, co chceme, protože projekt je do značné míry překrytý tím, co už nabízí https://smlouvy.gov.cz/ (dále jen RS). Jeho funkcionality chceme rozšířit, nikoliv nahradit. Jednotlivé komponenty jsou na sobě +- nezávislé, takže by měly jít dodat nezávisle na sobě. Do podmínek dejme, že všechny komponenty musí být Open Source a musí mít plně funkční API. Veškerá data v systému musí být přístupná jako Open Data.

  1. Revize standardu smluv tak, aby byl kompatibilní s RS. Je pak nutné vyznačit v něm metadata, která sice nejsou povinná ze zákona (a tudíž je RS ignoruje), ale která zlepší práci se smlouvami. 15 MD
  2. Sekundárního repozitář na dokumenty, které není možné nahrávat do RS (faktury?) 30 MD
  3. Systému pro správu metadat (třeba tomu říkejme registr metadat) k dokumentům v RS i sekundárním repozitáři. 25 MD
  4. Identity Management pro správu subjektů, kteří budou nahrávat dokumenty a data do RS, do sekundárního repozitáře i do registru metadat. IdM bude muset umět zachytit vztahy mezi subjekty (např. městská firma nebo příspěvkovka). Autentizaci bych nechal přes datové schránky, které uže beztak všichni musí mít pro RS. 35 MD
  5. Rozhraní pro upload dokumentů (i samotných metadat), které umožní vyplnění základních i rozšířených metadat, a provede jeho validaci. Pokud bude nahrán dokument patřící výhradně do RS, pak se tam předá i se základními metadaty; rozšířená metadata (+ kopie základních metadat?) bude zanesena do registru metadat. Pokud je nahrán soubor nespadající pod RS, bude uložen do sekundárního repozitáře a jeho metadata budou jen v registru metadat. 35 MD
  6. Portál s vyhledáváním agregující dokumenty a metadata z RS, sekundárního repozitáře a registru metadat. Možnost vytvořit si jednoduchá view (ideálně asi předáním vyhledávacích parametrů přes URL). 35 MD
  7. Možnost embedovat view z portálu do cizích stránek (možnost přestylovat je). 5 MD

EDIT: Ještě jsem zhruba odhadl náročnost jednotlivých komponent včetně testingu (budu rád za revizi). Celkově, 180 man-days, když k tomu připočtu, řekněme měsíc na výběrko, tak pokud to vypíšeme příští týden, tak ve worst case scénáři, kdy by to dělal jeden člověk (což ale u malého projektu nemusí být na škodu), jsme na nějakých deseti měsících, takže doable do konce roku. Ale jak říkám, tady určitě uvítám revizi

 

#4 Updated by Ondřej Profant almost 3 years ago

  • Description updated (diff)

#3 Updated by Ondřej Profant almost 3 years ago

Můj návrh z léta:

Chvíli jsem přemýšlel, jak vyřešit ten registr za nás. Zde jsou podle mě základní fakta:

1) Chceme nádstavbu nad registrem.
2) Nevíme přesně, co chceme. Rozhodně např. nemáme rozumné finanční a časové odhady konkrétních funkcí.
3) Nejsme si jisti kolik na to chceme uvolnit peněz, protože nevíme, co přesně za to dostaneme. Navíc můžeme růst a mít více peněz, nebo stagnovat a mít málo peněz.
4) Chceme něco relativně rychle.
5) Chceme vydávat prachy jen na základě veřejné soutěže

Přemýšlel jsem jak toto všechno splnit, aby to od nás nevyžadovalo extrémní nasazení (nemáme fulltime zaměstnance!) a nezazdili jsme si k něčemu cestu (problém zakázky je, že když jí zadáš, změníš, tak si tím zneplatnil předchozí soutěž).

Jako nejlepší mi přijde vytvořit něco ala soutěž o návrh (dle zákona o veř. zak.). V případě takhle malého rozsahu bych to viděl docela jednoduše. Vypíšeme zakázku, která bude hodnocena dle návrhu (jediné hodnotící kriterium). Tedy uchazeči dodají návrh v rozsahu cca 5 normostran, kde rozepíši, co chtějí kdy a za kolik dělat. A my z nich vybereme nejlepší.

V praxi to znamená, že někdo dodá např:

"Milník 1, říjen 2016: funkční synchronizace registrů, vlastní rest API, možnost nahrát z našeho registru do státního. Základní validace vstupů. Cena XY
Milník 2, únor 2017: napojení na agendový systém XY. Rozšířená validace vstupů, notifikace o problémech (protistrana v insolvenci...). Napojení na faktury. Cena XY
Milník 3, červen 2017: Celý proces veřejné zakázky (vypsání záměru, smlouva, faktury. Cena XY"

Někdo jiný napíše, že nám za milion nasadí Oracle...

Vzhledem k tomu, že pochybuji, že bude nějak hodně lidí ochotných to dělat, bude to relativně malé apod., tak si myslím, že je to zcela ok. Jen to klade velký důraz na kvalitu hodnotící komise.

Všechny další věci (záruka, opensource, prog. jazyk, DB...) budou uvedeny v kvalifikačních kriteriich a ve smlouvě.

Jediný problém je, že tím omezíme dobrovolníky, kteří chtějí pomoc. I když jim samozřejmě nic nebrání spojit se s dodavatelem. Ale dělat to jinak je ošemetné.

#2 Updated by Ondřej Profant almost 3 years ago

  • Description updated (diff)

#1 Updated by Ondřej Profant almost 3 years ago

  • Subject changed from Specifikace to Specifikace veř. zakázky
  • Description updated (diff)
  • Status changed from Nový to V řešení

Also available in: Atom PDF