1. How was the Vilnius Municipality Administration Team selected to prepare the procurement documents for maintenance services and to manage the Project on the part of the PPO?
Answer. The Project is implemented by a team of PPO employees (civil servants and employees working under the Employment Contract) together with a group of successful suppliers who prepare the technical specification and carry out the maintenance. To have the most comprehensive and critical assessment of solutions, we will publish all the intermediate results of the Project and attract experts who will provide consultations, recommendations on how to properly achieve the best result.
2. Who actually prepares Saulė IS Architecture Designs? Do ForIT and IO Projects teams have all the listed Pop-Tech / Hi-Tec solution specialists?
Answer. The project is implemented by a team of PPO employees together with the ForIT and IO Project team. The vision of Saulė IS architecture was developed both to imagine the future Saulė system and to expect valuable advice from experts in various fields. We also would like to emphasize that the presented Saulė vision is not mandatory for future suppliers who may already have their own solution or other architecture.
3. Where could the functional requirements for the use of the large data platform and artificial intelligence be found? It seems that there is pop-tech excess in the architecture, which will substantially increase the costs and risks of system development and operation.
Answer. Currently, future business processes and Saulė functional requirements have not been completed. We will also make them public and welcome valuable comments and remarks. It should also be noted that Saulė Project will last for many years and now solutions that seem “futuristic” may become usual and therefore we provide an opportunity to intervene between traditional functions.
4. Why it was chosen not to follow the Agile implementation method and maintenance recommendations (IVPK 2014 and 2017), but to prepare a rather detailed technological architecture before finalizing the operational requirements?
Answer. The Project is planned to be implemented using the best-known Agile experience and practices. However, in order to gather expert assessments and specific comments from different fields, and to calculate initial assessments of the value and duration of the Project, it was decided to develop an initial Saulė architecture. We also would like to emphasize that the presented Saulė vision is not mandatory for future suppliers who may already have their own solution or other architecture.
5. I see everything in the repository continues to run through the “issues” module. Administrators need to be shown how to use github. Here is a good example from the Alaskan public sector https://github.com/AlaskaDHSS/RFP-Search-Unification
Answer. Thank you for sharing a great example. We have also uploaded documents in Github suitable for download in a structured md format.
6. It seems not only the Ukrainians are developing their Prozzoro but also the Moldovan MTender have been developing their system based on https://openprocurement.io. Will you really make the system from the ground up?
Answer. Saulė Project has started from the assessment of the current situation and the analysis of the collected international experience (the current situation is placed in the github). The development of Saulė processes and functionality will consider the experience of foreign countries, and the technical specification is prepared in such a way as to allow a wide range of potential suppliers to come, with a variety of products, not limited to the Prozorro system. The Technical Task will provide the needs of Saulė interested parties that will use the system, and implementation solutions will be proposed by suppliers. In any case, the IS created in another country should be adapted for use in Lithuania, so in our opinion, suppliers will be able to boldly participate in the tender with Prozorro or a similar solution, offering the best solution. We have chosen to publish all the intermediate results of the Project to "catch" possible inaccuracies or artificial limitations when someone participates in the tender for the implementation of the system. We will be grateful for constructive criticism, stating what in your opinion could limit the possibility of implementing both Prozorro, MTender and another already developed solution, adapting it to the Lithuanian market.
7. Will the system itself be open source? #publiccode
Answer. Saulė project will hopefully use many open source components, but it will also depend on future tenders of suppliers who will participate in the tender. It is likely that the entire system will not be able to be open source (due to security, risk assessment and other important algorithms). However, some components could certainly be opened.