Kaip buvo pasirinkta Vilniaus savivaldybės administracijos komanda rengti techninės priežiūros paslaugų pirkimo dokumentus ir valdyti projektą iš VPT pusės.
Atsakymas. Projektą įgyvendina VPT darbuotojų komanda (valstybės tarnautojai ir darbuotojai, dirbantys pagal darbo sutartis) kartu su viešąjį pirkimą laimėjusia tiekėjų grupe, kurie rengia techninę specifikaciją ir vykdys techninę priežiūrą. Siekdami turėti kuo visapusiškesnį ir kritiškesnį sprendinių vertinimą, visus tarpinius projekto rezultatus viešinsime bei pasitelksime ekspertus, kurie teiks konsultacijas, rekomendacijas, kaip tinkamai pasiekti geriausią rezultatą.
2. Kas iš tikrųjų rengia Saulės IS architektūros projektus, ar For IT ir I/O projects komandose yra visų išvardintų pop-tech/hi-tec sprendimų specialistų?
Atsakymas. Projektą įgyvendina VPT darbuotojų komanda kartu su ForIT ir IOproject komanda. Saulės architektūros vizija buvo parengta siekiant, tiek patiems įsivaizduoti būsimą Saulės sistemą, tiek tikintis vertingų patarimų iš įvairių sričių ekspertų. Taip pat norime akcentuoti, kad pateikta Saulės vizija nėra privaloma būsimiems tiekėjams, kurie galbūt jau turės savo sprendinį ar kitokią architektūrą.
3. Kur galima būtų susirasti funkcinius reikalavimus didžiųjų duomenų platformos ir dirbtinio intelekto panaudojimui? Be šito susidaro stiprus įspūdis, kad architektūroje yra pop-tech perteklius, kurie iš esmės didins sistemos kūrimo ir eksploatacijos kaštus bei rizikas.
Atsakymas. Šiuo metu nėra baigti būsimi veiklos procesai bei Saulės funkciniai reikalavimai. Juos irgi pateiksime viešai ir lauksime vertingų pastabų bei komentarų. Taip pat reikėtų vertinti, kad Saulės projektas gyvuos ne vienus metus ir dabar sprendimai, kurie atrodo „futuristiniai“ gali tapti kasdieniniai ir todėl jiems numatoma galimybė įsiterpti ir tarp tradicinių funkcijų.
4. Kodėl buvo pasirinkta nesivadovauti Agile įgyvendinimo būdo ir techninės priežiūros rekomendacijomis (IVPK 2014 ir 2017m), bet rengiama gan detali technologinė architektūra prieš finalizuojant veiklos reikalavimus
Atsakymas. Projektą planuojama įgyvendinti pasitelkus geriausias žinomas Agile patirtis bei praktikas. Tačiau siekiant surinkti iš skirtingų sričių ekspertų vertinimus ir konkrečias pastabas, bei paskaičiuoti pirminius vertinimus dėl projekto vertės bei trukmės, buvo nuspręsta parengti pirminę Saulės architektūrą. Taip pat norime akcentuoti, kad pateikta Saulės vizija nėra privaloma būsimiems tiekėjams, kurie galbūt jau turės savo sprendinį ar kitokią architektūrą.
5. Matau repozitorijoje ir toliau važiuoja viskas per issues modulį. Reikia administratoriams parodyti, kaip github naudoti. Čia geras pavyzdys iš Alaskos viešojo sektoriaus https://github.com/AlaskaDHSS/RFP-Search-Unification
Atsakymas. Ačiū, kad pasidalinote puikiu pavyzdžiu. Į Github sudėjome ir dokumentus, tinkančius parsisiuntimui struktūruotu md formatu.
6. Prozorro netiko, savo nuo 0 kursite?
7. Kodėl buvo atsisakyta Prozorro ir jų siūlomo bendradarbiavimo, bet pasirinktas savo projektavimas nuo nulio, nors ir pasitelkta gerųjų praktikų (open source, viešumas etc)
8. Kurti tai kas jau yra sukurta, ir net yra iš ko rinktis?
9. Atrodo ne tik ukrainiečiai savo Prozzoro bet ir Moldavai MTender sistema vysto https://openprocurement.io pagrindu. Ar tikrai iš pagrindu darysite sistema?
Atsakymas. Saulės projektas buvo pradėtas nuo esamos situacijos įvertinimo bei surinktos tarptautinės patirties analizės (patalpinta github esama situacija). Kuriant Saulės procesus ir funkcionalumą bus vertinama užsienio šalių patirtis, o techninė specifikacija rengiama tokia, kuri leistų ateiti plačiam ratui potencialių tiekėjų, su įvairiais produktais, neapsiribojant tik Prozorro sistema. Techninėje užduotyje bus numatyti Saulės suinteresuotų šalių, kurios naudosis sistema, poreikiai, o įgyvendinimo sprendinius siūlys tiekėjai. Bet kokiu atveju kitoje šalyje sukurtą IS reikėtų adaptuoti naudojimui Lietuvoje, tad, mūsų manymu, tiekėjai ir su Prozorro ar analogišku sprendiniu galės drąsiai dalyvauti konkurse, siūlydami geriausią sprendimą. Pasirinkome viešinti visus tarpinius projekto rezultatus, kad „išgaudytume“ galimus netikslumus ar dirbtinius apribojimus kažkam dalyvaujant sistemos diegimo konkurse. Būsime dėkingi už konstruktyvią kritiką, nurodant, kas jūsų nuomone galėtų apriboti galimybę diegti tiek Prozorro, tiek MTender, tiek kitą jau sukurtą sprendinį, pritaikant jį Lietuvos rinkai.
10. Ar pati sistema bus atvirojo kodo? #publiccode
Atsakymas. Saulės projekte, tikimės, bus panaudota daug open source komponentų, bet tai priklausys ir nuo būsimų tiekėjų pasiūlymų kurie dalyvaus konkurse. Tikėtina, kad visa sistema negalės būti (dėl saugumo, dėl rizikų vertinimo ir kitų svarbių algoritmų) atviro kodo. Tačiau dalis komponentų tikrai galėtų būti atverti.
Kaip buvo pasirinkta Vilniaus savivaldybės administracijos komanda rengti techninės priežiūros paslaugų pirkimo dokumentus ir valdyti projektą iš VPT pusės.
Atsakymas. Projektą įgyvendina VPT darbuotojų komanda (valstybės tarnautojai ir darbuotojai, dirbantys pagal darbo sutartis) kartu su viešąjį pirkimą laimėjusia tiekėjų grupe, kurie rengia techninę specifikaciją ir vykdys techninę priežiūrą. Siekdami turėti kuo visapusiškesnį ir kritiškesnį sprendinių vertinimą, visus tarpinius projekto rezultatus viešinsime bei pasitelksime ekspertus, kurie teiks konsultacijas, rekomendacijas, kaip tinkamai pasiekti geriausią rezultatą.2. Kas iš tikrųjų rengia Saulės IS architektūros projektus, ar For IT ir I/O projects komandose yra visų išvardintų pop-tech/hi-tec sprendimų specialistų?
Atsakymas. Projektą įgyvendina VPT darbuotojų komanda kartu su ForIT ir IOproject komanda. Saulės architektūros vizija buvo parengta siekiant, tiek patiems įsivaizduoti būsimą Saulės sistemą, tiek tikintis vertingų patarimų iš įvairių sričių ekspertų. Taip pat norime akcentuoti, kad pateikta Saulės vizija nėra privaloma būsimiems tiekėjams, kurie galbūt jau turės savo sprendinį ar kitokią architektūrą.3. Kur galima būtų susirasti funkcinius reikalavimus didžiųjų duomenų platformos ir dirbtinio intelekto panaudojimui? Be šito susidaro stiprus įspūdis, kad architektūroje yra pop-tech perteklius, kurie iš esmės didins sistemos kūrimo ir eksploatacijos kaštus bei rizikas.
Atsakymas. Šiuo metu nėra baigti būsimi veiklos procesai bei Saulės funkciniai reikalavimai. Juos irgi pateiksime viešai ir lauksime vertingų pastabų bei komentarų. Taip pat reikėtų vertinti, kad Saulės projektas gyvuos ne vienus metus ir dabar sprendimai, kurie atrodo „futuristiniai“ gali tapti kasdieniniai ir todėl jiems numatoma galimybė įsiterpti ir tarp tradicinių funkcijų.4. Kodėl buvo pasirinkta nesivadovauti Agile įgyvendinimo būdo ir techninės priežiūros rekomendacijomis (IVPK 2014 ir 2017m), bet rengiama gan detali technologinė architektūra prieš finalizuojant veiklos reikalavimus
Atsakymas. Projektą planuojama įgyvendinti pasitelkus geriausias žinomas Agile patirtis bei praktikas. Tačiau siekiant surinkti iš skirtingų sričių ekspertų vertinimus ir konkrečias pastabas, bei paskaičiuoti pirminius vertinimus dėl projekto vertės bei trukmės, buvo nuspręsta parengti pirminę Saulės architektūrą. Taip pat norime akcentuoti, kad pateikta Saulės vizija nėra privaloma būsimiems tiekėjams, kurie galbūt jau turės savo sprendinį ar kitokią architektūrą.5. Matau repozitorijoje ir toliau važiuoja viskas per issues modulį. Reikia administratoriams parodyti, kaip github naudoti. Čia geras pavyzdys iš Alaskos viešojo sektoriaus https://github.com/AlaskaDHSS/RFP-Search-Unification
Atsakymas. Ačiū, kad pasidalinote puikiu pavyzdžiu. Į Github sudėjome ir dokumentus, tinkančius parsisiuntimui struktūruotu md formatu.6. Prozorro netiko, savo nuo 0 kursite? 7. Kodėl buvo atsisakyta Prozorro ir jų siūlomo bendradarbiavimo, bet pasirinktas savo projektavimas nuo nulio, nors ir pasitelkta gerųjų praktikų (open source, viešumas etc) 8. Kurti tai kas jau yra sukurta, ir net yra iš ko rinktis? 9. Atrodo ne tik ukrainiečiai savo Prozzoro bet ir Moldavai MTender sistema vysto https://openprocurement.io pagrindu. Ar tikrai iš pagrindu darysite sistema?
Atsakymas. Saulės projektas buvo pradėtas nuo esamos situacijos įvertinimo bei surinktos tarptautinės patirties analizės (patalpinta github esama situacija). Kuriant Saulės procesus ir funkcionalumą bus vertinama užsienio šalių patirtis, o techninė specifikacija rengiama tokia, kuri leistų ateiti plačiam ratui potencialių tiekėjų, su įvairiais produktais, neapsiribojant tik Prozorro sistema. Techninėje užduotyje bus numatyti Saulės suinteresuotų šalių, kurios naudosis sistema, poreikiai, o įgyvendinimo sprendinius siūlys tiekėjai. Bet kokiu atveju kitoje šalyje sukurtą IS reikėtų adaptuoti naudojimui Lietuvoje, tad, mūsų manymu, tiekėjai ir su Prozorro ar analogišku sprendiniu galės drąsiai dalyvauti konkurse, siūlydami geriausią sprendimą. Pasirinkome viešinti visus tarpinius projekto rezultatus, kad „išgaudytume“ galimus netikslumus ar dirbtinius apribojimus kažkam dalyvaujant sistemos diegimo konkurse. Būsime dėkingi už konstruktyvią kritiką, nurodant, kas jūsų nuomone galėtų apriboti galimybę diegti tiek Prozorro, tiek MTender, tiek kitą jau sukurtą sprendinį, pritaikant jį Lietuvos rinkai.10. Ar pati sistema bus atvirojo kodo? #publiccode
Atsakymas. Saulės projekte, tikimės, bus panaudota daug open source komponentų, bet tai priklausys ir nuo būsimų tiekėjų pasiūlymų kurie dalyvaus konkurse. Tikėtina, kad visa sistema negalės būti (dėl saugumo, dėl rizikų vertinimo ir kitų svarbių algoritmų) atviro kodo. Tačiau dalis komponentų tikrai galėtų būti atverti.