Tālākizglītības informācijas sistēmas „Juhan“ uzturēšanas un attīstības darbi

The tender explicitly prohibits the involvement of subcontractors or suppliers associated with the Russian Federation. Failure to comply with this requirement could lead to disqualification or contract termination. This applies to citizens, residents, or entities established in, or owned or controlled by entities from, the Russian Federation.

The contracting authority will reject any bid that would lead to a contract that is void under RSanS § 7 lg 1, specifically referencing EU Council Regulation (EU) 2022/576. This implies a strict adherence to international sanctions.

The tender specifies a strict set of technologies for both front-end (Next.js, React, TypeScript) and back-end (Drupal 11+, PHP, Symfony, PostgreSQL), as well as other services (Elasticsearch, Redis, REST/JSON API, X-tee). Any bidder not proficient in these exact technologies will face significant challenges or be unable to bid.

All team members must confirm their Estonian language proficiency and ability to work with Estonian legislation. Failure to meet this requirement necessitates providing a permanent translator at the bidder's expense, who must be competent in translating IT texts. The criteria for translator competence are not clearly defined.

The document outlines very detailed and specific experience requirements for each team member role, including years of experience, project budget sizes, specific technologies (PHP, Symphony, PostgreSQL, REST API, X-tee services, two-factor authentication), and methodologies (Scrum). Meeting all these precise criteria for every individual may be challenging for bidders, potentially limiting the pool of qualified candidates.

The tender sets a minimum acceptable hourly rate of EUR 45.00. While it aims to prevent manipulation by setting a floor, it doesn't cap the maximum hourly rate. This could lead to significantly higher costs than anticipated if bidders propose very high rates above the EUR 45.00 threshold, impacting the overall project budget.

While a technical vision for the payment and billing solution is required, the tender document itself does not provide detailed specifications or existing architecture of this solution. This could lead to misinterpretation or a mismatch in proposed solutions.

Bidders must declare what information is considered a trade secret and provide justification. However, the law restricts what can be declared as a trade secret, explicitly excluding bid costs, sub-costs, and other numerical indicators relevant to evaluation criteria for services, and similar indicators for goods and works.

The evaluation of the test task vision and technical description is based on subjective criteria (e.g., 'very strong and well-thought-out solution') across four categories. This subjectivity can lead to inconsistent scoring and potential disputes if bidders feel their solutions were not fairly assessed.

The evaluation of the project plan's detail and realism is described with broad score ranges (e.g., 'general or incomplete', 'basic stages described', 'logical and structured', 'detailed and realistic'). The distinction between these levels, especially between 'logical and structured' and 'detailed and realistic', could be interpreted differently by evaluators.

The tender requires maintenance of the existing 'Juhan' system while simultaneously developing the new 'Juhan 2' version. This dual responsibility can be complex and requires careful resource allocation and management.

The tender relies heavily on specific tools like HTM Confluence, HTM Jira, and HTM Gitiserver for task management, bug tracking, and code management. If the bidder is not familiar with these exact tools, there will be a learning curve and potential integration challenges.

While the document allows for team members to fulfill multiple roles (up to two), it states that such individuals must meet the conditions for both roles. This could lead to complex CV analysis and potential disputes if the combined experience for dual roles is not clearly demonstrable or if the workload becomes unmanageable.

If team members change during the framework agreement period, replacements must meet the same stringent requirements. The bidder must also notify the contracting authority immediately. This adds administrative burden and potential delays if suitable replacements are hard to find quickly.

The Hankepass is described as a self-declaration for initial proof of qualifications and exclusion grounds, not a document to be filled out. Bidders must fill it electronically in a system or ESPD service. Misunderstanding this process could lead to submission errors.

The tender outlines mandatory exclusion grounds related to criminal convictions for participation in a criminal organization or corruption. Bidders must truthfully declare any such convictions and their status.

The system relies heavily on X-tee for data exchange with state registers. Proficiency and experience with X-tee are crucial for successful integration and data flow.

While the document outlines various communication channels (email, MS Teams, meetings), the specific conditions for when each should be used, especially for official notices versus daily communication, could lead to misinterpretations or delays if not strictly adhered to. The reliance on email confirmation for delivery adds a layer of potential delay.

The process for handling changes in work scope requires the bidder to provide a new workload estimate after changes are identified. While this is a standard process, the emphasis on the Contracting Authority's contact person approving changes before work continues, coupled with the possibility of schedule adjustments, could lead to delays if approvals are not timely or if the scope changes significantly.

The bid price must be final and include all costs necessary for proper contract execution. The contracting authority will not reimburse any additional costs or make additional payments.

While the document specifies that the translator must be competent in translating IT texts, it does not define the criteria for this competence. This could lead to disputes or delays if the contracting authority deems the proposed translator not sufficiently competent.

Document 1 (Vastavustingimused) states that bidders must declare what information is considered a trade secret and justify it, but also lists specific exclusions (bid costs, sub-costs, etc.). Document 4 (Hankepass) simply states 'The bidder must provide information regarding trade secrets.' without elaborating on the definition or exclusions, potentially leading to different interpretations of what can be protected.

Document 3 (Hindamiskriteeriumid) details the evaluation criteria for the 'test task' and its project plan, but the actual 'test task' itself is not provided or described in detail across any of the documents. This makes it impossible for bidders to fully understand what is being evaluated.

Document 2 (Meeskonna kinnituskiri) states that a translator must be 'competent in translating IT texts'. However, no specific criteria or qualifications are defined for this competence, leaving room for subjective interpretation by the contracting authority.

Document 2 (Meeskonna kinnituskiri) and Document 5 (Tehniline kirjeldus) require Estonian language proficiency, but do not specify the required level (e.g., CEFR levels). This leaves the assessment open to subjective interpretation.

Document 3 (Hindamiskriteeriumid) describes project plan evaluation with score ranges like 'general or incomplete', 'basic stages described', 'logical and structured', and 'detailed and realistic'. The distinction between 'logical and structured' and 'detailed and realistic' is not clearly defined, leading to potential interpretation differences among evaluators.

Document 5 (Tehniline kirjeldus) lists the technologies used, but lacks detailed information on the existing Juhan system's architecture, codebase, and specific integration points. This information is crucial for bidders to accurately assess maintenance effort and propose development strategies.

Document 1 (Vastavustingimused) states 'The Hankepass is the bidder's self-declaration, serving as initial proof of qualifications and exclusion grounds required by the contracting authority, not a document to be filled out.' However, Document 4 (Hankepass täiendatavate selgitustega) clarifies that it must be filled electronically in a system or ESPD service, implying it is a document to be completed, albeit electronically. This could cause confusion about the submission process.