Sygn. akt: KIO 3313/25
POSTANOWIENIE
Warszawa, dnia 23.09.25 r.
Krajowa Izba Odwoławcza - w składzie:
Przewodnicząca:Agata Mikołajczyk
Członkowie:M.M.
M.R.
po rozpoznaniu na posiedzeniu niejawnym bez udziału Stron w dniu 23 września 2025 r. w Warszawie odwołania
wniesionego do Prezesa Krajowej Izby Odwoławczejw dniu 7 sierpnia 2025 r. przez wykonawcę: Comarch Polska S.A.
z/s w Krakowie (Al. Jana Pawła II 39a, 31864 Kraków) w postępowaniu prowadzonym przez zamawiającego:Urząd
Komunikacji Elektronicznej z/s w Warszawie (ul. Giełdowa 7/9, 01211 Warszawa),
postanawia:
1.Umorzyć postępowanie odwoławcze;
2.Nakazać zwrot z rachunku bankowego Urzędu Zamówień Publicznych na rzecz
Odwołującego: Comarch Polska S.A. z/s w Krakowie(Al. Jana Pawła II 39a, 31864 Kraków)kwotę 13.500 zł 00
gr (słownie: trzynaście tysięcy pięćset złotych zero groszy), stanowiącą 90 % kwoty wpisu uiszczonego przez
Odwołującego od odwołania.
Na orzeczenie - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby
Odwoławczej do Sądu Okręgowego w Warszawie - Sądu Zamówień Publicznych.
………………………………………
………………………………………
………………………………………
Sygn. akt: KIO 3313/25
Uzasadnienie
Odwołanie zostało wniesione do Prezesa Krajowej Izby Odwoławczej w dniu 7 sierpnia
2025 r. przez wykonawcę Comarch Polska S.A. z/s w Krakowie (Odwołujący) w postępowaniuprowadzonym w trybie
przetargu nieograniczonego na podstawie ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz. U. z
2024 r. poz. 1320 ze zm.), [ustawa Pzp lub Pzp lub Ustawa PZP]przez Zamawiającego: Urząd Komunikacji
Elektronicznej z/s w Warszawie. Przedmiotem zamówienia publicznego jest: „Zaprojektowanie, budowa wdrożenie i
serwis Systemu finansowo księgowo-kadrowo-płacowego wraz z migracją danych i Pracami Analityczno-Rozwojowymi”.
Ogłoszenie o zamówieniu zostało opublikowane 28/07/2025 w Dz. Urz. UE Nr: 492381-2025. Wykonawca podał: (…)
Odwołujący wnosi odwołanie od czynności sformułowania treści dokumentacji zamówienia i ogłoszenia niezgodnie z
PZP zarzucając Zamawiającemu naruszenie:
1. art. 112 ust. 1 PZP w zw. z art. 112 ust. 2 pkt 4 PZP w zw. z art. 16 pkt 3 PZP poprzez określenie warunków udziału w
postępowaniu dotyczących zdolności technicznej i zawodowej w zakresie doświadczenia wykonawcy w sposób w
sposób nieproporcjonalny do przedmiotu zamówienia;
2. art. 239 ust. 1 i 2 PZP w zw. z art. 240 ust. 1 i 2 PZP w zw. z art. 241 ust. 1 PZP w zw. z art. 16 PZP poprzez
sformułowanie kryterium oceny ofert „Ocena próbki” w sposób niejednoznaczny i niezrozumiały, poprzez sformułowanie
kryterium oceny ofert „Ocena próbki” w zakresie funkcjonalności niezwiązanych z przedmiotem zamówienia, poprzez
zaniechanie określenia w dokumentach zamówienia kryterium oceny ofert „Ocena próbki” w sposób pozwalający na
wybór najkorzystniejszej oferty z zachowaniem uczciwej konkurencji i równego traktowania wykonawców, a
sformułowanie kryterium oceny ofert „Ocena próbki” w sposób pozostawiający Zamawiającemu nieograniczoną swobodę
wyboru najkorzystniejszej oferty oraz uniemożliwiający weryfikację i porównanie poziomu oferowanego wykonania
przedmiotu zamówienia na podstawie informacji przedstawianych w ofertach, a także poprzez sformułowanie kryterium
oceny ofert „Ocena próbki” w sposób niepozwalający na wybór najkorzystniejszej oferty tj. oferty przedstawiającej
najkorzystniejszy stosunek jakości do ceny, a w konsekwencji z naruszeniem zasady przejrzystości, proporcjonalności i
zachowania uczciwej konkurencji i równego traktowania wykonawców;
3. art. 99 ust. 1 i 4 PZP w zw. z art. 16 pkt 3 PZP w zw. z art. 353¹ k.c. w zw. z art. 8 ust. 1 PZP poprzez wadliwe
(niejednoznaczne, niewyczerpujące, bez dokładnych i zrozumiałych określeń) sformułowanie definicji Oprogramowania
Standardowego i Oprogramowania Dedykowanego oraz poprzez nieproporcjonalne i niejednoznaczne żądanie
przeniesienia praw autorskich i kodów źródłowych do Oprogramowania Standardowego, a w konsekwencji naruszenie
zasady, proporcjonalności i zachowania uczciwej konkurencji i równego traktowania wykonawców;
4. 99 ust.1 i ust. 4 PZP w zw. z art. 16 PZP w zw. z art. 8 ust. 1 PZP w związku z art. 3531 k.c. poprzez zaniechanie
opisu zobowiązań wykonawcy z uwzględnieniem wszystkich wymagań i okoliczności mogących mieć wpływ na
sporządzenie oferty, w szczególności na jej wycenę, a to zaniechanie jednoznacznego i wyczerpującego zwymiarowania
(w roboczogodzinach) zobowiązań Wykonawcy wynikających z opisanego w § 20 Umowy tzw. Exit Plan, co oznacza, iż
złożone oferty nie będą porównywalne, co godzi w zasadę zachowania uczciwej konkurencji i równego traktowania
wykonawców. (…)
Odwołujący wniósł o uwzględnienie odwołania oraz podał: „Żądania odwołania zostały przedstawione pod uzasadnieniem
każdego z zarzutów”.
Wykonawca także wskazał: (…) Interes Odwołującego oraz możliwość poniesienia przez Odwołującego szkody
Odwołujący ma interes w uzyskaniu zamówienia, ponieważ jest podmiotem zdolnym do jego wykonania, posiadającym w
tym zakresie odpowiednie kompetencje i doświadczenie. Poprzez sformułowanie przez Zamawiającego postanowień
SW Z w sposób naruszający przepisy ustawy Odwołujący może być pozbawiony możliwości złożenia oferty i uzyskania
zamówienia, tym samym w wyniku naruszenia przez Zamawiającego przepisów ustawy Odwołujący może ponieść
szkodę polegającą na braku uzyskania przedmiotowego zamówienia. Ponadto Odwołujący wskazuje, że ma interes we
wniesieniu odwołania, gdyż w wyniku uregulowania zapisów SW Z w sposób naruszający przepisy ustawy został
pozbawiony uczestnictwa w postępowaniu na uczciwych i zgodnych z prawem warunkach, w tym możliwości złożenia
ważnej i konkurencyjnej oferty przez wykonawców gwarantujących prawidłowe wykonanie zamówienia ze względu na
posiadanie odpowiedniego doświadczenia. Odwołujący ma interes w uzyskaniu zamówienia, a w wyniku działań
Zamawiającego Odwołujący został narażony na szkodę. Gdyby nie naruszające przepisy zaskarżone elementy SW Z,
Odwołujący mógłby z powodzeniem ubiegać się o przedmiotowe zamówienie, co w razie jego uzyskania wiązałoby się z
określonymi korzyściami finansowymi. Na tym etapie postępowania krąg podmiotów mogących skutecznie bronić swoich
interesów w uzyskaniu zamówienia obejmuje każdego potencjalnego wykonawcę, mogącego samodzielnie zrealizować
zamówienie. Interes Odwołującego wyraża się również w tym, aby postępowanie o udzielenie zamówienia
przeprowadzone zostało zgodnie z przepisami prawa. (…)
Do postępowania odwoławczego przystąpienia nie zgłosił żaden wykonawca.
Zamawiający w odpowiedzi na odwołanie (pismo z dnia 11.09.2025 r.) wniósł w o jego oddalenie w części. W
uzasadnieniu stanowiska podał: (...)
Zarzut 1 Warunek udziału w postępowaniu
Naruszenie art. 112 ust. 1 PZP w zw. z art. 112 ust. 2 pkt 4 PZP w zw. z art. 16 pkt 3 PZP poprzez określenie warunków
udziału w postępowaniu dotyczących zdolności technicznej i zawodowej w zakresie doświadczenia wykonawcy w
sposób w sposób nieproporcjonalny do przedmiotu zamówienia;
Zamawiający sformułował w SWZ następujący warunek udziału w postępowaniu:
„1.4. Warunki dotyczące zdolności technicznej lub zawodowej
[DOŚWIADCZENIE]
Wykonawca, dla spełnienia warunku, zobowiązany jest wykazać, że w okresie ostatnich 3 lat przed upływem terminu
składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, należycie wykonał lub nadal
wykonuje usługi dla podmiotów sektora finansów publicznych lub dla podmiotów gospodarczych o łącznej wartości co
najmniej 1 000 000 zł brutto (słownie: jeden milion złotych brutto), których przedmiotem jest dostawa, wdrożenie oraz
świadczenie usługi powdrożeniowej przez okres co najmniej 12 miesięcy systemu klasy ERP obejmującego co najmniej
obszar finansowo-księgowy oraz kadrowo-płacowy”.
Natomiast w rozdziale 6 OPZ – Terminy realizacji, Zamawiający zawarł następującą informację: „Świadczenie Asysty
Powdrożeniowej dla całości systemu musi obejmować okres 6 miesięcy od podpisania Końcowego Protokołu Odbioru
Wdrożenia.” Oznacza to, że przedmiot zamówienia obejmuje 6 miesięcy świadczenia Asysty (usługi) powdrożeniowej.
Odpowiedź Zamawiającego:
Celem Zamawiającego jako jednostki sektora finansów publicznych jest zagwarantowanie efektywnego, proporcjonalnego
i zgodnego z prawem wydatkowania środków publicznych. W tym przypadku dotyczy to określenia odpowiednich
warunków dostępowych, weryfikujących czy dany podmiot posiada odpowiedni potencjał techniczny i zawodowy
umożliwiający realizację przedmiotu zamówienia. Dlatego podmiot ubiegający się o to zamówienie publiczne powinien
wykazać, że posiada odpowiednie doświadczenie w realizacji usług związanych z zakresem zamówienia tj. dostawą i
wdrożeniem systemu klasy ERP oraz świadczeniem usługi powdrożeniowej. Zamawiający omyłkowo wskazał okres 12
miesięcy doświadczenia w świadczeniu usługi powdrożeniowej. Zamawiający przychyla się do stanowiska oferenta i
dokonuje zmiany brzmienia w SWZ pkt 1.4 warunki dotyczące zdolności technicznej lub zawodowej w SWZ
(…)
Jest (po zmianie):
Wykonawca, dla spełnienia warunku, zobowiązany jest wykazać, że w okresie ostatnich 3 lat przed upływem terminu
składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, należycie wykonał lub nadal
wykonuje usługi dla podmiotów sektora finansów publicznych lub dla podmiotów gospodarczych o łącznej wartości co
najmniej 1 000 000 zł brutto (słownie: jeden milion złotych brutto), których przedmiotem jest dostawa, wdrożenie oraz
świadczenie usługi powdrożeniowej przez okres co najmniej 6 miesięcy systemu klasy ERP obejmującego co najmniej
obszar finansowo-księgowy oraz kadrowo-płacowy”.
Zarzut nr 2 Kryterium oceny ofert: Ocena próbki
a) brak opisu kryteriów oceny ofert w sposób jednoznaczny i zrozumiały. Odwołujący zarzuca Zamawiającemu, że nie
opisał kryteriów oceny ofert w sposób jednoznaczny i zrozumiały.
Odpowiedź Zamawiającego
Zamawiający dąży do wdrażania rozwiązań wpisujących się w kierunek cyfrowej transformacji, w tym wykorzystania
nowoczesnych technologii już sprawdzonych w praktyce rynkowej. Przedstawione w dokumentacji wymagania odnoszą
się do funkcjonalności, które mają realne zastosowanie, zostały przetestowane i są dostępne na rynku, a jednocześnie
odpowiadają na potrzeby związane z rozwojem organizacji. Opis wymagań został sformułowany w sposób pozwalający
wykazać, że dana funkcja jest możliwa do zrealizowania przez wykonawcę, bez narzucania nadmiernie szczegółowych
rozwiązań technicznych. Zamawiający świadomie unikał zbyt szczegółowego doprecyzowania technologii czy
parametrów, aby – zgodnie z zasadą uczciwej konkurencji – umożliwić udział w postępowaniu jak największej liczbie
wykonawców. Zamawiający w celu doprecyzowania sposobu oceny próbki oraz zapewnienia jednoznaczności wymagań
obligatoryjnych związanych z przedmiotem zamówienia wprowadza zmianę w pkt 7 Opisu Przedmiotu Zamówienia
polegającą na usunięciu wymagania:
Nr 13 System będzie umożliwiał biometryczną weryfikację głosową na podstawie unikalnych cech głosu danego
pracownika w komunikacji Dział Kadr – pracownik.
Nr 14 System winien umożliwiać automatyczne rozpoznawanie treści dokumentów (OCR), klasyfikowanie ich według
typów i zawartości przy użyciu narzędzi sztucznej inteligencji oraz wspomagać operatorów w digitalizacji i walidacji
dokumentów, umożliwiając łatwe wyszukiwanie, identyfikację metadanych i wykrywanie duplikatów. System powinien być
skalowalny oraz umożliwiać obsługę dokumentacji archiwalnej zgromadzonej na przestrzeni ponad 20 lat przez Centralę
UKE i 15 delegatur.
b) brak korelacji próbki
Odwołujący zarzuca także, iż zdecydowana większość wyspecyfikowanych w ww. tabeli funkcjonalności nie
koresponduje z treścią przedmiotu zamówienia. Odwołujący jest świadomy tego, że wskazane wymagania są w
większości funkcjonalnościami fakultatywnymi, za które Zamawiający będzie przyznawał dodatkowe punkty w ramach
kryteriów oceny. Jednakże w ocenie Odwołującego nie ma wystarczającego związku pomiędzy przedmiotem
zamówienia (wdrożenie Systemu finansowo-księgowo-kadrowo-płacowego), a wymaganiami wskazanymi przez
Zamawiającego w kryterium oceny ofert „Ocena próbki”. Zdaniem Odwołującego próbka w ramach postępowania na
dostawę systemu ERP (finansowo-księgowo-kadrowo-płacowego) powinna odnosić się do specyfiki systemu ERP.
Przykładowo, biometria głosowa nie stanowi standardowej funkcjonalności systemu ERP (zdaniem Odwołującego nie
sposób przyjąć, że ta funkcjonalność ma coś wspólnego z systemem ERP). Zdaniem Odwołującego, z kolei
funkcjonalność OCR to domena systemów workflow (Elektronicznych Obiegów Dokumentów), a nie systemów ERP –
nie ma nic wspólnego z systemem ERP.
Odpowiedź Zamawiającego:
Zarzut Odwołującego jest niezasadny. Wymagania wskazane w tabeli w ramach kryterium „Ocena próbki” zostały
sformułowane celowo w taki sposób, aby umożliwić Zamawiającemu uzyskanie systemu ERP wyposażonego w
nowoczesne technologie i funkcjonalności odpowiadające współczesnym trendom cyfrowym oraz wyzwaniom
przyszłości. Podział na systemy ERP i EOD w nowoczesnych rozwiązaniach ulega zatarciu – współczesne systemy
ERP implementują mechanizmy procesowości, obiegów dokumentów i narzędzi optymalizacji procesów. Nowoczesne
systemy ERP nie tylko obsługują tradycyjne funkcje rachunkowo-kadrowe — coraz częściej integrują również
zaawansowaną procesowość, która kiedyś była domeną systemów EOD (Elektronicznego Obiegu Dokumentów).
Współczesne platformy ERP, realizują obieg zadań i dokumentów, zarządzanie procesami oraz automatyzację w
sposób wbudowany — bez konieczności korzystania z dodatkowych, zewnętrznych systemów.
W związku z powyższym, wymagania z tabeli „Ocena próbki” — w tym automatyzacja procesów, inteligentne
powiadomienia, dostęp mobilny, zarządzanie dokumentami, biometryka — znajdują pełne uzasadnienie. Stanowią
naturalne elementy współczesnych, zintegrowanych systemów ERP, na których zależy Zamawiającemu jako
nowoczesnej instytucji. Również wymagania związane z biometrią głosową oraz innymi mechanizmami bezpieczeństwa
stanowią odpowiedź na rosnące zagrożenia cybernetyczne i odzwierciedlają nowy poziom zabezpieczeń w użytkowaniu
systemów ERP. Brak ich obecności w standardowej ofercie jednego z wykonawców nie może być traktowany jako
przesłanka do uznania ich za niepowiązane z przedmiotem zamówienia. Zamawiający, planując wdrożenie systemu
ERP, kieruje się nie tylko bieżącymi potrzebami, lecz również przewidywanymi wymaganiami wynikającymi z rozwoju
technologii, cyfryzacji administracji i bezpieczeństwa danych. Wymagania z tabeli w sposób bezpośredni wspierają
realizację tych celów, a tym samym pozostają w pełnej korelacji z przedmiotem zamówienia.Ponadto w uzupełnieniu
opisu kryteriów oceny próbki Zamawiający wyjaśnił cel poszczególnych rozwiązań i ich związek z przedmiotem
zamówienia.
c) brak scenariuszy, zasad punktacji i regulaminu oceny próbki
Odwołujący zarzuca Zamawiającemu, że Zamawiający nie przedstawił żadnych (jednoznacznych, zrozumiałych i
klarownych) zasad, w oparciu o które wykonawcy będą prezentować realizację wykazanych w tabeli funkcjonalności ani
nie przedstawił, na jakich zasadach będą przyznawane (wskazane w kolumnie „Maksymalna liczba punktów
cząstkowych”) punkty cząstkowe za każdą zaprezentowaną i prawidłowo zrealizowaną funkcjonalność (…).
Odwołujący zarzuca Zamawiającemu sformułowanie kryterium oceny ofert „Ocena próbki” w sposób, który przyznaje
Zamawiającemu właściwie nieograniczoną swobodę wyboru najkorzystniejszej oferty, gdyż nie umożliwia weryfikacji i
porównania poziomu oferowanego wykonania przedmiotu zamówienia na podstawie informacji przedstawianych w
ofertach.
Odpowiedź Zamawiającego
Zamawiający nie podziela argumentów podniesionych w zarzucie przez Odwołującego. Zamawiający pragnie wskazać,
że przewidział to, że ocena w ramach kryterium „Ocena próbki” odbywa się na podstawie stopnia realizacji zadań
wynikających z opisanych w dokumentacji wymagań. Komisja przetargowa będzie przyznawać punkty proporcjonalnie do
liczby i jakości zrealizowanych funkcjonalności, zgodnie z ich opisem w SW Z, przy czym każdy element będzie
weryfikowany poprzez przedstawienie dowodu jego spełnienia. Wraz z realizacją kolejnych zapisów wymagań, popartą
stosowną demonstracją lub dowodem, Komisja będzie przyznawała punkty częściowe lub pełne, odzwierciedlające
stopień spełnienia danej funkcjonalności. Taki model oceny zapewnia równe traktowanie wykonawców i pozwala na
obiektywne porównanie ofert. Jednocześnie, mając na względzie postulaty dotyczące transparentności, Zamawiający
wprowadzi modyfikację dokumentacji postępowania polegającą na dołączeniu szczegółowych scenariuszy prezentacji
dla poszczególnych funkcjonalności, które będą stanowić podstawę zarówno dla przygotowania próbek przez
wykonawców, jak i dla ich oceny przez komisję. Scenariusze te będą opisane w sposób jednoznaczny i zrozumiały, aby
wyeliminować ewentualne wątpliwości interpretacyjne.
d) nieproporcjonalna, nieefektywna waga kryterium
Odwołujący zarzuca, że Zamawiający dla kryterium „Ocena próbki” przypisał wagę aż 40% (40 punktów), co jest
wielkością bardzo znaczącą i determinującą łączną punktację jaką mogą uzyskać wykonawcy w kryteriach oceny.
Wykonawca, który nie uzyska żadnych punktów w tym kryterium nie jest w stanie złożyć konkurencyjnej oferty, nawet
minimalizując cenę do 0,01 zł.
Odpowiedź Zamawiającego
Zamawiający dąży do wyboru rozwiązania najbardziej nowoczesnego, kompleksowego i przyszłościowego, dlatego
przypisanie temu kryterium znaczącego udziału procentowego w ocenie ofert jest w pełni uzasadnione.Jednocześnie,
mając na względzie postulaty proporcjonalności i równowagi między kryteriami, Zamawiający wprowadza w SW Z
następującą modyfikację wagi kryterium „Ocena próbki” – z dotychczasowych 40% do poziomu 25%, co zachowuje jego
istotność, a jednocześnie lepiej równoważy wpływ wszystkich kryteriów oceny na wynik końcowy.
(…)
JEST
Lp.
Nazwa kryterium
Cena (C)
Termin realizacji (R)
Ocena próbki (P)
Waga kryterium [%]
50,00% =50 punktów
25,00%= 25 punktów
25,00%= 25 punktów
Zarzut nr 2 - Podsumowanie
Podsumowując kryterium „Ocena próbki” zostało sformułowane zgodnie z przepisami PZP i stanowi istotny element
oceny ofert, umożliwiający wybór rozwiązania nowoczesnego, kompleksowego i odpowiadającego bieżącym oraz
przyszłym potrzebom Zamawiającego. Opis wymagań jest na tyle precyzyjny, aby umożliwić ich realizację szerokiemu
gronu wykonawców, a jednocześnie pozostaje na poziomie funkcjonalnym, co zapobiega ograniczaniu konkurencji
poprzez narzucanie konkretnych rozwiązań technologicznych. Wskazane w kryterium funkcjonalności, w tym związane z
procesowością, obiegiem dokumentów oraz bezpieczeństwem (np. biometrią głosową), są obecnie integralną częścią
nowoczesnych systemów ERP, czego przykładem są dostępne na rynku rozwiązania. Komisja przetargowa oceniać
będzie stopień realizacji poszczególnych wymagań, przyznając punkty na podstawie przedstawionych dowodów ich
spełnienia, a dla pełnej transparentności Zamawiający wprowadzi modyfikację dokumentacji poprzez dołączenie
scenariuszy prezentacji funkcjonalności. Jednakże, by wyeliminować ewentualne wątpliwości potencjalnych Oferentów
co do sposobu, kryteriów oraz zasadności poszczególnych elementów zawartych w kryterium „Ocena próbki”
Zamawiający uzupełnia SWZ o doprecyzowanie opisu kryteriów oceny próbki, tj.:
1. Integracja z inteligentnym asystentem (AI Chat) w celu wyszukiwania i analizy danych z umów. Funkcjonalność
umożliwia zadawanie pytań w języku naturalnym i uzyskiwanie precyzyjnych odpowiedzi bezpośrednio z treści
dokumentów. (max. 4 pkt).
Cel funkcjonalny
Umożliwienie użytkownikowi zadawania pytań w języku naturalnym dotyczących treści umów i uzyskiwania precyzyjnych
odpowiedzi bezpośrednio z tych dokumentów. Wirtualny asystent (oparty na AI) ma zrozumieć kontekst pytania i
przeszukać dane umów w systemie, aby udzielić konkretnej odpowiedzi. Dzięki temu obsługa zapytań o informacje z
umów jest szybsza i łatwiejsza, np. użytkownik może zapytać: „Kiedy wygasa umowa z kontrahentem X?”, a system
natychmiast poda datę zakończenia.
Kroki działania w systemie
1. Z poziomu interfejsu systemu użytkownik otwiera okno systemu.
2. Użytkownik wpisuje pytanie w języku polskim dotyczące konkretnej umowy, np.: „Jaka jest data umowy o świadczenie
usług IT z firmą ABC?”.
3. Asystent AI przetwarza zapytanie – rozpoznaje, że dotyczy ono danych z dokumentów typu Umowa – i przeszukuje
bazę umów w systemie (ew. analizuje treść załączonego pliku umowy, jeśli jest przeszukiwalny).
4. System wyświetla w oknie czatu odpowiedź asystenta AI – np.: „Umowa z firmą ABC obowiązuje do 31 października
2025 r.”. Asystent może dodatkowo wskazać źródło informacji, np. numer umowy lub sekcję dokumentu.
Oczekiwany rezultat
System poprawnie interpretuje pytanie w języku naturalnym i zwraca precyzyjną informację z treści umowy. Odpowiedź
pojawia się szybko w oknie czatu i odpowiada na zadane pytanie (bez potrzeby ręcznego przeglądania dokumentu).
Użytkownik otrzymuje np. konkretną datę, kwotę lub zapis umowny, którego zażądał. Asystent powinien wykazać się
rozumieniem kontekstu (np. wie, której umowy dotyczy pytanie na podstawie nazwy kontrahenta).
Skala punktowa
0 pkt – Brak integracji z asystentem AI lub asystent nie potrafi odpowiadać na pytania o treść umów. W próbie
demonstracyjnej funkcjonalność nie została pokazana lub odpowiedzi asystenta są całkowicie niepoprawne/niezwiązane
z pytaniami.
1 pkt – Asystent AI jest obecny i pozwala na zadawanie pytań, ale nie pobiera informacji z treści dokumentów. Może
udzielać odpowiedzi ogólnych lub dotyczących tylko podstawowych danych (np. dostępnych w kartotekach), bez sięgania
do pełnego tekstu umowy. Np. pytanie o datę końca umowy zwraca jedynie komunikat błędu albo wymaga podania
numeru umowy ręcznie.
2 pkt – Asystent potrafi udzielić częściowych odpowiedzi związanych z umowami. Np. rozpoznaje pytanie o datę
końcową umowy i zwraca ją, ale tylko jeśli data jest wpisana w strukturze danych (metadanych) umowy. Nie analizuje
pełnego tekstu dokumentu lub ma trudności ze zrozumieniem pytań w języku naturalnym (wymaga bardzo konkretnej
frazy). Odpowiedzi mogą być niepełne lub wymagające doprecyzowania.
3 pkt – Asystent AI poprawnie odpowiada na większość pytań dotyczących danych z umów zapisanych w systemie.
Rozumie pytania kontekstowo (np. identyfikuje umowę po nazwie kontrahenta) i przytacza prawidłowe informacje
znajdujące się w strukturze danych lub załączonym tekście. Mogą wystąpić drobne ograniczenia – np. asystent nie
interpretuje skanowanych dokumentów nieprzetworzonych na tekst lub myli się przy bardzo złożonych pytaniach – ale
zasadniczo funkcja działa.
4 pkt – Pełna realizacja funkcjonalności. Asystent AI swobodnie komunikuje się z użytkownikiem w języku naturalnym i
precyzyjnie odpowiada na pytania dotyczące treści umów, korzystając zarówno z metadanych, jak i pełnego tekstu
dokumentów.
W odpowiedziach uwzględnia kontekst (wie o którą umowę chodzi bez podawania numeru, jeśli pytanie jednoznacznie
identyfikuje kontrahenta/temat) i przytacza informacje takie jak daty, kwoty, klauzule umowne itp. Odpowiedzi są trafne
nawet dla pytań sformułowanych potocznie lub przy drobnych literówkach. Funkcja działa płynnie, a wszystkie
zaprezentowane przykładowe pytania (np. o datę, kwotę, warunki umowy) zostały poprawnie obsłużone przez asystenta.
2. Automatyczne klasyfikowanie i ekstrakcja kluczowych metadanych z umów lub dokumentów kadrowych i innych, przy
użyciu AI i OCR (max. 4 pkt).
Cel funkcjonalny
Zautomatyzowanie procesu wprowadzania dokumentów (np. umów, dokumentów kadrowych, faktur) poprzez
wykorzystanie sztucznej inteligencji (AI) i OCR do odczytu treści i wyciągania kluczowych metadanych. System powinien
samoczynnie rozpoznać typ dokumentu (np. odróżnić umowę od innego pisma) oraz wydobyć istotne informacje – takie
jak strony umowy, daty obowiązywania, kwotę wynagrodzenia, numer dokumentu, itp. – i zapisać je w odpowiednich
polach systemu. Celem jest ograniczenie ręcznego przepisywania danych i przyspieszenie digitalizacji dokumentów.
Kroki działania w systemie
1. Użytkownik dodaje nowy dokument do systemu lub wybiera importuj dokument i wskazuje plik PDF skanu umowy.
2. Przetwarza dokument za pomocą OCR. Ewentualnie system automatycznie wykrywa nowy dokument w
wyznaczonym katalogu do przetwarzania OCR.
3. System przesyła dokument do usługi OCR. Mechanizm AI+OCR rozpoznaje tekst na wszystkich stronach skanu
(technologia rozpoznawania tekstu) oraz analizuje jego strukturę.
4. Klasyfikacja: Na podstawie zawartości tekstu AI stwierdza, że jest to umowa (np. wykrywa słowa kluczowe typu
„Umowa nr…”, „Strony: …” itp.). System przypisuje dokumentowi odpowiedni typ lub znacznik (np. Umowa o pracę).
5. Ekstrakcja danych
OCR wspomagany AI wyodrębnia z tekstu dokumentu kluczowe informacje. Przykładowo:
o „Numer umowy” – znajduje ciąg znaków odpowiadający numerowi i wypełnia pole numeru.
o „Data zawarcia” i „Data obowiązywania od/do” – rozpoznaje daty i przypisuje do odpowiednich pól.
o „Strony umowy” (nazwy kontrahentów/pracownika i pracodawcy) – odnajduje nazwy podmiotów i wypełnia pola
kontrahenta.
o Inne metadane jak kwota wynagrodzenia czy stanowisko (jeśli to umowa o pracę) – identyfikuje w tekście i przypisuje
do odpowiednich pól.
6. Po zakończeniu przetwarzania system automatycznie tworzy w bazie nowy rekord umowy. Pola metadanych są
uzupełnione wartościami odczytanymi z dokumentu. Sam oryginał skanu zostaje zapisany jako załącznik/element do
tego rekordu (możliwy do podejrzenia przez użytkownika).
7. Użytkownik otwiera utworzoną kartę umowy w systemie i weryfikuje wyniki: sprawdza, czy kluczowe pola zostały
poprawnie uzupełnione zgodnie z treścią dokumentu.
8. W celach demonstracyjnych użytkownik dodaje drugi dokument (np. skan świadectwa pracy lub innego rodzaju
dokumentu kadrowego) i powtarza procedurę, pokazując że system potrafi odmiennie zaklasyfikować dokument (np. jako
Dokument kadrowy zamiast Umowa) i wyciągnąć z niego inne zestawy metadanych.
Oczekiwany rezultat
System automatycznie rozpoznaje i rejestruje dokument. Po zaimportowaniu skanu umowy pojawia się nowy rekord w
systemie, gdzie pola takie jak kontrahent/pracownik, daty, numer umowy, itp. są już wypełnione bez ręcznej ingerencji.
Typ dokumentu jest poprawnie ustawiony (umowa vs inny dokument).
Skala punktowa
0 pkt – Brak działającej funkcji OCR/AI. System nie potrafi automatycznie przetworzyć dodanego skanu – użytkownik
musiałby ręcznie wprowadzić wszystkie dane, co zostaje wykazane podczas prezentacji (np. importowany dokument
trafia tylko jako skan do repozytorium bez żadnej analizy).
1 pkt – Częściowe działanie mechanizmu. System podejmuje próbę rozpoznania dokumentu, ale zakres jest bardzo
ograniczony. Np. OCR odczytuje tekst, ale nie klasyfikuje rodzaju dokumentu ani nie wypełnia pól automatycznie – jedynie
umożliwia użytkownikowi
skopiowanie tekstu. Ewentualnie rozpoznaje tylko nieliczne dane (np. numer dokumentu), podczas gdy resztę trzeba
wprowadzić ręcznie.
2 pkt – System poprawnie rozpoznaje tekst z dokumentu (działa OCR) i częściowo uzupełnia pola. Na przykład potrafi
wypełnić podstawowe metadane (numer, datę dokumentu), ale nie identyfikuje wszystkich kluczowych informacji lub myli
typ dokumentu. Użytkownik musi część danych poprawić lub uzupełnić ręcznie. Ogólnie widać automatyzację, lecz jej
skuteczność jest umiarkowana (np. działa dla faktur, ale nie dla umów – w demonstracji dane z umowy nie zostały w
pełni odczytane).
3 pkt – Znaczna automatyzacja. System rozpoznaje typ dokumentu i wypełnia większość istotnych pól poprawnie. Np.
po wczytaniu umowy identyfikuje strony, daty, numer i część klauzul finansowych, choć mogą zdarzyć się drobne
pomyłki (np. OCR błędnie odczyta jedno nazwisko z powodu jakości skanu). Konieczne jest niewielkie korygowanie
danych przez użytkownika. Funkcja klasyfikacji działa dla głównych typów dokumentów przewidzianych w systemie.
Demonstracja pokazuje, że np. dla dwóch różnych dokumentów mechanizm zadziałał, choć przy jednym z nich pewne
pole pozostało niewypełnione albo system poprosił o akceptację odczytanej wartości.
4 pkt – Pełna funkcjonalność AI+OCR. W pokazie system bezbłędnie klasyfikuje przedstawiony dokument (rozpoznaje
rodzaj umowy lub innego pisma) i automatycznie ekstraktuje wszystkie kluczowe metadane. Użytkownik nie musi nic
dopisywać ręcznie – jedynie weryfikuje poprawność. Wszystkie ważne informacje z dokumentu (przynajmniej te
wymienione w scenariuszu) są poprawnie uchwycone: kontrahent, daty, numer, kwoty itp. System radzi sobie nawet z
dokumentem wielostronicowym i o mniej standardowym układzie. Wskazanie pliku skutkuje utworzeniem nowego obiektu
w systemie z uzupełnionymi danymi, a oryginał jest dostępny jako załącznik. Funkcjonalność cechuje się wysoką
skutecznością i niezawodnością (np. praktycznie brak błędów odczytu w zaprezentowanych przypadkach).
3. Proaktywne generowanie przez system rekomendacji dotyczących optymalizacji procesów w oparciu o analizę danych
i wzorców w obiegu dokumentów. (max. 2 pkt).
Cel funkcjonalny
Proaktywne wsparcie użytkownika poprzez analizę wzorców i danych gromadzonych w systemie w celu znalezienia
usprawnień w procesach biznesowych. System powinien automatycznie generować rekomendacje – np. sugestie zmian
organizacyjnych, podpowiedzi automatyzacji, wskazanie wąskich gardeł w obiegu dokumentów – na podstawie wykrytych
trendów lub anomalii. Celem jest zwiększenie efektywności pracy z systemem i procesów urzędu dzięki AI, która uczy
się z danych historycznych i na ich podstawie wskazuje optymalizacje.
Kroki działania w systemie
1. Administrator lub użytkownik przechodzi do panelu analiz procesów, gdzie zbierane są potencjalne rekomendacje.
2. Użytkownik inicjuje analizę danych – np. wybiera polecenie „przeanalizuj obieg dokumentów za ostatnie 6 miesięcy pod
kątem opóźnień”.
3. System (silnik AI) przetwarza dane z logów i historii dokumentów. Wyszukuje wzorce: np. zauważa, że dokumenty
typu Umowa mają średni czas akceptacji 15 dni, podczas gdy oczekiwany to 7 dni.
4. Generowanie rekomendacji
Na podstawie wykrytych odstępstw lub możliwości poprawy, system formułuje komunikaty. Przykłady rekomendacji:
o „Proces akceptacji umów trwa średnio 2 razy dłużej niż zakładano. Rekomendacja: skrócić liczbę wymaganych
akceptacji z 4 do 3 dla umów o wartości < …. zł.”
o „W ostatnim kwartale 25% wniosków urlopowych przekroczyło czas akceptacji o
>24h. Rekomendacja: dodać zastępcę do akceptacji wniosku w razie nieobecności przełożonego.”
5. System wyświetla listę wygenerowanych rekomendacji na ekranie. Użytkownik je przegląda.
6. Użytkownik klika konkretną rekomendację, aby zobaczyć szczegóły.
Oczekiwany rezultat
System prezentuje czytelne, sensowne rekomendacje poparte danymi. Każda sugestia optymalizacyjna jasno odnosi się
do konkretnego procesu i problemu zidentyfikowanego w analizie. Np. w scenariuszu na ekranie pojawia się komunikat
wskazujący długi czas akceptacji umów i sugerujący działania naprawcze – jest to zrozumiałe dla komisji oceniającej i
odpowiada rzeczywistym danym (prezentowany wykres/raport pokazuje, że faktycznie większość umów przekracza
zakładany czas). Rekomendacje są mierzalne (tzn. wskazują co ulepszyć i jak to wpłynie na proces). System zachowuje
się proaktywnie – informacje pojawiają się bez zapytania użytkownika bądź w odpowiedzi na proste polecenie analizy,
zamiast wymagania od użytkownika samodzielnego wyciągania wniosków z surowych raportów.
Skala punktowa:
0 pkt – Brak funkcji generowania rekomendacji. W prezentacji nie pokazano żadnej proaktywnej sugestii dotyczącej
ulepszeń – system ogranicza się do standardowych raportów. Żaden element UI czy raportu nie wskazuje, by AI
analizowała i proponowała usprawnienia procesów.
0,5 pkt – Rekomendacje w formie szczątkowej. System może wyświetlać pewne statyczne podpowiedzi lub
komunikaty, ale nie są one wynikiem analizy danych z kontekstu urzędu. Np. ogólne wskazówki typu „możesz skorzystać
z modułu X, by zautomatyzować pracę” niezwiązane z realnymi danymi lub pojedyncze ostrzeżenia bez konkretnych
sugestii (np. informacja o przekroczeniu terminu bez rekomendacji co z tym zrobić). Sugestie są niepersonalizowane,
jednak sygnalizuje to próbę doradzania użytkownikowi.
1 pkt – Pojawiają się pierwsze oznaki inteligentnych rekomendacji, ale o ograniczonym zakresie. Np. system
identyfikuje 1-2 proste wzorce (tylko w jednym obszarze, np. finanse) – np. podpowie automatyzację raportu
miesięcznego – ale nie obejmuje to szerszych procesów. Rekomendacje mogą być dość oczywiste lub generowane
rzadko. Użytkownik w prezentacji musiał np. ręcznie wywołać analizę i otrzymał jedną sugestię optymalizacji.
Funkcjonalność działa, lecz ma wąski zakres (np. tylko dla modułu księgowego) lub jej wiarygodność jest niska (sugestie
mało trafne).3 pkt – Funkcjonalność działa w zadowalającym stopniu. System potrafi wygenerować kilka przydatnych
rekomendacji na podstawie danych. Obejmują one więcej niż jeden obszar procesu (np. zarówno obieg dokumentów
kadrowych, jak i finansowych). Sugestie są konkretne i poparte danymi – w prezentacji pokazano, że system wskazał np.
konkretny krok w procesie, który wydłuża całość i zaproponował zmianę. Nadal jednak mogą istnieć pewne ograniczenia:
np. rekomendacje pojawiają się tylko po ręcznym uruchomieniu analizy (nie w trybie ciągłego monitoringu) lub nie
obejmują bardziej złożonych zależności. Być może system nie uwzględnia jeszcze wszystkich historycznych danych
albo pomija czynniki jakościowe. Ogólnie jednak większość wygenerowanych podpowiedzi jest sensowna i komisja
uznaje je za wartościowe.
2 pkt – Zaawansowane, proaktywne rekomendacje procesowe. System stale analizuje dane z różnych modułów i
automatycznie informuje użytkowników o możliwościach ulepszeń. W demonstracji pokazano, że system sam
zidentyfikował kilka istotnych obszarów do poprawy i dla każdego przedstawił mierzalną propozycję usprawnienia.
Rekomendacje mogą dotyczyć organizacji pracy (np. zmiana obsady akceptacji, skrócenie obiegu), wykorzystania funkcji
systemu (np. włączenie automatycznych przypomnień, które są wyłączone), a nawet wskazywać potencjalne
oszczędności czasu lub kosztów. Sztuczna inteligencja wychwytuje ukryte wzorce (np. zależności między obciążeniem
pracą a opóźnieniami) i trafnie je
komunikuje. Funkcja jest uniwersalna – można ją zastosować do różnych procesów (kadry, finanse, zamówienia).
System w punktach oceny próbki zaprezentował kilka różnych rekomendacji, z których każda była jasna, poprawna
merytorycznie i weryfikowalna na podstawie danych (np. poparta wykresem lub raportem). Taki poziom realizacji
pokazuje realne wykorzystanie AI do ciągłego doskonalenia procesów w organizacji.
4. Definiowanie i modelowanie procesów za pomocą jednego z ogólnie dostępnych języków programowania (max. 2 pkt).
Cel funkcjonalny
Umożliwienie definiowania i dostosowywania logiki procesów biznesowych za pomocą powszechnie dostępnego języka
programowania (np. Python, C#, VB lub innego języka skryptowego). Chodzi o to, aby system był otwarty na
rozszerzenia i pozwalał programistom (lub zaawansowanym administratorom) modelować niestandardowe procesy,
reguły czy integracje poprzez kod. Dzięki temu bardziej złożone wymagania można zaadresować pisząc odpowiedni
skrypt lub moduł, który będzie współpracował z systemem.
Kroki działania w systemie:
1. Programista/administrator otwiera środowisko do rozszerzeń. Może to być:
o Edytor skryptów wewnątrz aplikacji (jeśli system taki posiada, np. edycja skryptu procesu).
o Zewnętrzne IDE do napisania kodu korzystającego z API ERP.
2. Tworzy nowy proces/rozszerzenie – np. definicję procedury, która będzie reagować na zdarzenie w systemie:
o Przykład
Skrypt wywoływany przy dodaniu nowej umowy. Skrypt ten pobiera dane umowy i automatycznie tworzy powiązane
zadanie w zewnętrznym systemie , używając API ERP do odczytu danych i utworzenia zadania.
o Inny przykład
Skrypt generuje specjalny raport i wysyła e-mail, uruchamiany codziennie jako zadanie.
3. Użytkownik testowy wykonuje czynność inicjującą proces (np. dodaje nową umowę w systemie).
4. Skrypt/rozszerzenie uruchamia się i wykonuje zaprogramowane działania. Oczekujemy, że:
o W systemie pojawiły się dodatkowe efekty zaplanowane w kodzie (np. dodano automatycznie kolejny dokument,
zmieniono status, wyliczono jakieś pole niestandardowe).
o lub zewnętrzne efekty, np. w logach widać, że system wywołał zewnętrzny webservice, utworzono plik, wysłano e-mail.
5. W ramach prezentacji, wykonawca pokazuje fragment kodu, wyjaśnia logikę oraz demonstruje, że po stronie systemu
ERP proces został pomyślnie dostosowany (np. mamy „szytą na miarę” funkcję, której nie dałoby się osiągnąć bez
programowania). Może to zilustrować działaniem: np. tworzy dokument, co skutkuje automatyczną akcją – komisja widzi
rezultat tej akcji.
Oczekiwany rezultat
W demonstracji pojawia się rzeczywisty kod źródłowy integrujący się z systemem. Rezultat działania tego kodu jest
zgodny z oczekiwaniami: np. po zdarzeniu w systemie nastąpiła oczekiwana, zaprogramowana czynność (system
utworzył dokument, zmienił dane, wywołał integrację). Dla oceny ważne jest, że nie jest to tylko teoria – wykonawca
praktycznie pokazał działający kod powiązany z systemem. Np. w logach systemu widać wywołanie przez API operacji
utworzenia dokumentu handlowego, co potwierdza możliwość sterowania ERP poprzez zewnętrzny program.
Skala punktowa
0 pkt – System nie umożliwia modelowania procesów poprzez kod lub nie zostało to zaprezentowane. Wszelkie
procesy są sztywno zdefiniowane i nie ma API ani mechanizmu skryptowego. Wykonawca nie przedstawił żadnego
sposobu na dodanie własnej logiki – tylko konfigurację przez interfejs. (Jeśli system jest zamknięty na integracje
programistyczne, otrzyma 0 pkt).
1 pkt – System posiada pewne API lub mechanizm rozszerzeń, ale jego użycie jest bardzo ograniczone albo nie
pozwala na pełne modelowanie procesów. Przykład: Można co najwyżej wywołać kilka metod do pobrania danych, ale
brak możliwości ingerencji w obieg dokumentów. Albo: system pozwala na skrypty, lecz tylko w bardzo podstawowym
zakresie (np. proste makra, które nie mogą wpływać na głębszą logikę). Być może wykonawca pokazał fragment kodu,
ale nie udało się nim wiele zdziałać (np. potrzebna funkcja API nie istnieje). Ogólnie – funkcjonalność częściowa.
2 pkt – System jest otwarty programistycznie i umożliwia realizację niestandardowego procesu poprzez kod – co
zostało skutecznie zademonstrowane. Wykonawca przedstawił działający przykład rozszerzenia: użyto popularnego
języka (np. VB, C#, Java, Python lub wbudowany język skryptowy) do implementacji logiki biznesowej. Rozszerzenie
integruje się z systemem (np. poprzez oficjalne API) i osiąga zamierzony efekt. Oceniający widzą, że wymagało to
napisania kodu, ale dzięki temu uzyskano funkcję ponad standard systemu. Przyznane zostanie maks. 2 pkt, ponieważ
pełna zdolność do modelowania w języku programowania została potwierdzona. (Uwaga: Skala do 2 pkt – 2 oznacza
spełnienie wymogu. Jeśli system dodatkowo oferuje wyjątkowo łatwe i mocne narzędzia dla programistów – można to
docenić w komentarzu, ale punktacja powyżej 2 nie jest tu przewidziana).
5. Zaawansowany dostęp mobilny do repozytorium umów (max. 2 pkt).
Cel funkcjonalny
Zapewnienie zaawansowanego dostępu mobilnego do dokumentów umów – to znaczy, że uprawniony użytkownik
korzystający ze smartfona lub tabletu może przeglądać, wyszukiwać, jak na komputerze. Mobilny dostęp ma umożliwić
pracę zdalną i ciągłość działania: np. kierownik w terenie może szybko odszukać konkretną umowę i sprawdzić jej
warunki, a także wykonać na niej operacje (podpisać elektronicznie, dodać komentarz, itp.). Rozwiązanie mobilne
powinno być wygodne (dostosowany interfejs) i bezpieczne.
Kroki działania w systemie
1. Na urządzeniu mobilnym użytkownik uruchamia aplikację związaną z systemem (np. system na smartfonie, lub
otwiera przeglądarkę i loguje się do webowej wersji repozytorium umów).
2. Po zalogowaniu, użytkownik przechodzi do umów lub wyszukiwarki dokumentów. Interfejs jest dostosowany do ekranu
mobilnego – np. lista umów wyświetla podstawowe informacje w kompaktowej formie.
3. Użytkownik korzysta z wyszukiwarki, wpisując np. nazwę kontrahenta lub numer umowy. System szybko filtruje i
wyświetla wyniki. Możliwe jest też zastosowanie filtrów (typu listy rozwijane użytkownika, daty).
4. Użytkownik wybiera konkretną umowę z listy. Otwiera się podgląd dokumentu:
o Wyświetlane są metadane umowy (kontrahent, daty, status, itp.).
o Dostępna jest opcja podglądu załączonego pliku (np. skanu/pdf umowy). Użytkownik klika podgląd – dokument jest
renderowany na ekranie telefonu.
5. System rejestruje te zmiany w bazie, tak jakby zostały wykonane z poziomu komputerowej aplikacji.
Oczekiwany rezultat
Możliwy dostęp do umów z urządzenia mobilnego. Użytkownik jest w stanie w kilka chwil odnaleźć potrzebny dokument i
wyświetlić jego zawartość na ekranie telefonu. Wszystkie elementy interfejsu są czytelne i interaktywne na małym
ekranie. Wykonane operacje (np. akceptacja) są natychmiast odzwierciedlone w systemie centralnym. System
demonstruje cechy takie jak:
Responsywność - szybkie działanie, dostosowanie UI.
Kompletność funkcji - mobilnie dostępne są nie tylko podglądy, ale i akcje (przynajmniej podstawowe, jak akceptacja,
komentarz).
Synchronizacja w czasie rzeczywistym - np. gdy w mobilnej app dokonano zmiany statusu, komisja może zobaczyć
na komputerze, że status uległ zmianie – i odwrotnie.
Skala punktowa:
0 pkt – System nie posiada realnego dostępu mobilnego. Być może jedyną opcją jest użycie pulpitu zdalnego lub brak
jest w ogóle interfejsu dla urządzeń mobilnych. W prezentacji nie pokazano działania na smartfonie/tablecie lub próba
takiego działania była kompletnie nieudana (interfejs nieładowalny, bardzo nieczytelny).
0,5 pkt – Ograniczony dostęp mobilny. Np. system można co prawda otworzyć na tablecie/telefonie (przez
przeglądarkę), ale nie jest on zoptymalizowany – widać pełny interfejs desktopowy, który jest trudny w obsłudze dotykiem.
Aplikacja natywna może nie istnieć lub oferuje tylko podgląd kilku prostych danych. Użytkownik w demonstracji ledwo
może wyszukać dokument (np. musi przewijać duże tabele, które się niewygodnie skalują). Ogółem mobilność jest tylko
hasłowa.
1 pkt – System oferuje podstawową aplikację mobilną lub responsywny portal, który umożliwia przeglądanie
dokumentów i wykonywanie tylko prostych czynności. Przykładowo: użytkownik może wyświetlić listę umów i podejrzeć
szczegóły, ale nie może ich edytować ani zatwierdzać. Albo może zatwierdzać, ale nie obejrzy załącznika PDF, bo
aplikacja go nie wyświetla poprawnie. Możliwości są ograniczone, choć samo logowanie i nawigacja działają. W skali
ocen: system spełnia minimalny wymóg posiadania mobilnego dostępu, ale nie realizuje w pełni idei „zaawansowanego”
dostępu.
1,5 pkt – Pełny dostęp mobilny z drobnymi brakami. Aplikacja (lub strona mobilna) pozwala na prawie wszystko, co jest
potrzebne: wyszukiwanie, przeglądanie załączników, akceptacje, komentarze. Prezentacja pokazuje, że kierownik na
telefonie mógł znaleźć i zatwierdzić dokument, co zostało odnotowane w systemie. Ewentualne braki mogą dotyczyć
wygody lub rzadziej używanych funkcji: np. brak możliwości edycji pewnych pól metadanych, albo brak powiadomień
push (użytkownik musi sam sprawdzać). Jednak core funkcjonalności mobilnej jest dostępny i działa poprawnie. Interfejs
jest przyjazny (np. specjalne uproszczone ekrany dla najważniejszych czynności). Komisja mogła zaobserwować, że
mobilne narzędzie realnie wspiera pracę zdalną.
2 pkt – Zaawansowany, w pełni funkcjonalny dostęp mobilny. Użytkownik na urządzeniu mobilnym może zrobić
praktycznie wszystko, co w aplikacji desktopowej, przy zachowaniu wygody i ergonomii. Pokazano, że aplikacja mobilna
umożliwia wszystkie kluczowe operacje na umowach: wyszukiwanie po różnych kryteriach, filtrowanie, podgląd
wielostronicowych skanów, zatwierdzanie/odrzucanie, edycję atrybutów, dodawanie zdjęć/załączników np. z aparatu,
podpis elektroniczny (jeśli wspierany).
6. Inteligentne alertowanie o kluczowych terminach umownych. System automatycznie monitoruje daty i wysyła
powiadomienia. (max. 2 pkt).
Cel funkcjonalny
Zapewnienie, że system monitoruje terminy wynikające z umów (np. daty wygaśnięcia, odnowienia, terminy
wypowiedzenia, przeglądu umowy, ważności gwarancji itp.) i wcześniej powiadamia odpowiednie osoby o zbliżających
się kluczowych datach. Celem jest uniknięcie sytuacji, w której ważny termin zostanie przeoczony. Funkcjonalność
alertowania powinna działać automatycznie – użytkownik nie musi samodzielnie sprawdzać kalendarza każdej umowy;
zamiast tego system generuje powiadomienia/alerty gdy zbliża się określony termin (na podstawie reguł). Inteligencja
może polegać np. na dostosowaniu, kogo powiadomić i kiedy (np. miesiąc przed końcem umowy z co najmniej rocznym
okresem wypowiedzenia).
Kroki działania w systemie
1. Automatyczne monitorowanie
W tle system codziennie (lub w określonych odstępach) sprawdza wszystkie terminy w bazie umów. To może być
zrealizowane poprzez zdefiniowane reguły: np. „jeśli data zakończenia umowy T – dzisiejsza data <= 30 dni, a umowa w
statusie aktywna, to wygeneruj alert”.
2. Wygenerowanie alertu
Dla każdej umowy spełniającej kryterium zbliżającego się terminu, system tworzy powiadomienie. Powiadomienie może
mieć formę:
o Wewnętrznego komunikatu/zdarzenia (np. trafia do Centrum powiadomień w aplikacji albo do modułu
"Informacje"/dashboard).
o Wiadomości e-mail wysłanej do opiekuna umowy lub grupy.
3. Użytkownik prezentuje centralny widok alertów
Np. informacje bieżące, kończące się umowy z listą umów, których termin upływa w określonym okienku czasu. Na liście
widoczne są np. nazwy kontrahentów i daty końca umowy.
4. Użytkownik pokazuje swój widok: otrzymał np. e-mail od systemu z przypomnieniem o wygasającej umowie.
5. Użytkownik klika link w powiadomieniu lub przechodzi w systemie do danej umowy, aby podjąć działania (np.
rozpoczyna proces przedłużenia lub przygotowuje wypowiedzenie).
Oczekiwany rezultat
System aktywnie ostrzega o zbliżających się terminach związanych z umowami. Komisja widzi, że użytkownicy
otrzymują wyraźne powiadomienia (na ekranie, mailowo lub mobilnie) z odpowiednim wyprzedzeniem.
Skala punktowa
0 pkt – System nie oferuje żadnego automatycznego alertu o terminach. Użytkownik musiałby ręcznie przeglądać daty
w umowach lub prowadzić je w zewnętrznym kalendarzu. W prezentacji brak wzmianki o powiadomieniach, a zapytany
wykonawca stwierdza, że takiej funkcji nie ma lub nie pokazał jej działania.
0,5 pkt – Pojawia się częściowa funkcjonalność alertów, lecz mocno ograniczona. Być może system posiada tylko
statyczne raporty o terminach (np. lista wygasających umów, ale nie generuje automatycznych powiadomień –
użytkownik sam musi zajrzeć do raportu). Ewentualnie powiadomienia istnieją, ale tylko w systemie (np. mały wskaźnik
na dashboardzie), bez wysyłki maili czy notyfikacji. Funkcja może wymagać manualnego uruchomienia raportu z
terminami. Nie jest to w pełni automatyczne czuwanie, ale podstawowe informacje o kończących się terminach są
dostępne.
1 pkt – System generuje powiadomienia, jednak nie w sposób kompleksowy. Np. potrafi wysłać e-mail, ale tylko do
jednego, stałego adresu (nie do opiekuna umowy). Albo alerty wyświetlają się użytkownikom w aplikacji, lecz bez
personalizacji (każdy widzi tylko własne, brak globalnego zestawienia). Możliwe, że brakuje konfigurowalności – terminy
są z góry ustalone (np. zawsze 7 dni przed końcem – co nie zawsze wystarczy). Mimo to, mechanizm działa:
wykonawca pokazał np. przykładowy e-mail z systemu z informacją o terminie, co oznacza, że pewna automatyka
istnieje.
1,5 pkt – Pełne działanie alertów z drobnymi ograniczeniami. System monitoruje kluczowe daty i wysyła/pokazuje
przypomnienia odpowiednim osobom. W demonstracji widać, że np.
opiekunowie umów dostali e-maile zgodnie z oczekiwaniem, a w aplikacji jest miejsce, gdzie zbiorczo te alerty widać.
Mechanizm może wymagać drobnej konfiguracji, ale jest elastyczny (można ustawić np. horyzont powiadamiania).
Istnieje możliwość różnych kanałów (np. mail, okienko w aplikacji). Być może brak jest jedynie bardziej zaawansowanych
opcji (np. kaskadowych przypomnień: 30 dni i 7 dni przed – system wysyła tylko raz). Ogólnie jednak nic ważnego nie
umyka – zaprezentowano, że umowy testowe z terminami generują spodziewane alerty.
2 pkt – Inteligentne i wszechstronne alertowanie. System nie tylko wysyła standardowe przypomnienia, ale pozwala też
na dostosowanie reguł i harmonogramu powiadomień. W prezentacji wykonawca mógł np. pokazać, że dla różnych
typów umów można ustawić różne wyprzedzenie (np. dla umów rocznych – 1 miesiąc przed, dla umów
krótkoterminowych – 1 tydzień) i system to wspiera. Alerty są wysyłane wiele razy, jeśli termin minął a brak akcji (np.
powiadomienie ponowne w dniu terminu). Ponadto, mechanizm jest zintegrowany z innymi funkcjami – np. jeśli umowa
jest przedłużona, alert automatycznie znika. Możliwe są powiadomienia do wielu kanałów jednocześnie. Najwyższa
punktacja zakłada, że zaprezentowane alertowanie działa niezawodnie, jest konfigurowalne i powiązane z rolami
użytkowników (właściwe osoby dostają właściwe alerty) oraz że nie ogranicza się tylko do jednego rodzaju terminu, ale
obejmuje całość istotnych terminów umownych.
7. Wersjonowanie dokumentów zintegrowane z pakietem Microsoft Office. (max. 1 pkt).
Cel funkcjonalny
Zapewnienie mechanizmu wersjonowania dokumentów (śledzenia zmian i przechowywania historycznych wersji) w taki
sposób, by był on zintegrowany z pracą w programach Office (Word, Excel). Oznacza to, że gdy użytkownik edytuje
dokument przechowywany w systemie, zmiany zostają zapisane jako nowa wersja dokumentu automatycznie lub
półautomatycznie, a użytkownik może z poziomu systemu przeglądać poprzednie wersje, porównywać je i ewentualnie
przywracać. Integracja z MS Office powinna ułatwiać edycję – np. otwarcie pliku z repozytorium uruchamia Worda, a
zapis w Wordzie oddaje nową wersję do systemu, bez ręcznego eksportu/ponownego wgrywania pliku.
Kroki działania w systemie
1. Użytkownik znajduje określony dokument (np. poprzez listę dokumentów lub wyszukiwarkę).
2. System pobiera plik i otwiera go np. w Word na stanowisku użytkownika. (Jeśli jest plugin, może to zrobić
automatycznie; jeśli nie – użytkownik może otworzyć plik ręcznie, zapisawszy go lokalnie).
3. Użytkownik dokonuje zmian w treści dokumentu w Word – np. aktualizuje paragraf z kwotą, zmienia datę lub inne
postanowienia.
4. System tworzy kolejną wersję dokumentu. Poprzednia wersja jest archiwizowana.
5. Użytkownicy mają dostęp do historii wersji.
6. W systemie wersjonowanie może obejmować dynamiczne blokowanie edycji.
Oczekiwany rezultat
System zachowuje pełną historię zmian dokumentu i integruje się z typowym narzędziem biurowym, jakim jest MS
Office, aby ułatwić proces edycji. Po zakończeniu scenariusza, komisja widzi:
W obszarze dokumentów jest dokument z dwiema (lub więcej) wersjami, które można wyświetlać.
Treść wersji poprzedniej i nowej różni się dokładnie w tych miejscach, gdzie użytkownik dokonał edycji.
Użytkownicy mogą łatwo otworzyć starą wersję (np. Word z wersją tylko-do-odczytu) oraz przywrócić ją, jeśli to
konieczne.
Wersje są numerowane, datowane i podpisane kto dokonał zmian. Np. Wersja 2 z datą i nazwiskiem Użytkownika.
Skala punktowa:
0 pkt – Brak funkcji wersjonowania dokumentów. System przechowuje tylko aktualną wersję pliku – nadpisanie
powoduje utratę poprzedniej treści. W demonstracji nie widać opcji wersji, ani możliwości odzyskania starego pliku.
0,5 pkt – Podstawowe wersjonowanie, brak integracji. System może zachować historię plików, ale w sposób mało
wygodny. Np. użytkownik musi ręcznie tworzyć kopie lub system tworzy wersje, ale nie ma powiązania z edycją w Office
– użytkownik sam musi wgrać nowy plik jako kolejną wersję. Wersje są przechowywane, lecz brak głębszej integracji
(np. brak blokowania edycji, brak porównywania różnic, brak automatycznego zapisu). Funkcjonalność istnieje, lecz
wymaga dużej uwagi od użytkowników.
1 pkt – Pełne wersjonowanie z integracją Office. System automatycznie tworzy nowe wersje przy edycji dokumentów i
jest to zintegrowane z procesem edycji. W demonstracji widać, że edytowanie pliku Word z repozytorium skutkuje
utworzeniem kolejnej wersji przy zapisie, a poprzednia pozostaje dostępna. Można wygodnie przeglądać historię i
pobierać stare wersje. Użytkownicy nie muszą myśleć o numeracji plików – system robi to za nich.
8. Mechanizm zarządzania Voiceprintami, (max. 2 pkt).
Cel funkcjonalny
Udostępnienie w systemie mechanizmów zarządzania danymi biometrycznymi głosu użytkowników (tzw. voiceprintami,
czyli wzorcami głosowymi). Chodzi o to, by administratorzy mogli tworzyć, usuwać i importować profile głosowe
wykorzystywane do uwierzytelniania lub identyfikacji użytkowników. Funkcja ta jest istotna w kontekście wdrożenia
biometrii głosowej – system powinien pozwalać np. na zarejestrowanie głosu pracownika podczas rozmowy, zapis tego
wzorca w bazie, ewentualnie usunięcie (gdy pracownik odchodzi lub odwoła zgodę) oraz import już wcześniej nagranych
voiceprintów (np. z innej bazy voiceprintów). Celem jest centralna administracja voiceprintami oraz zapewnienie
zgodności z przepisami (np. łatwe usunięcie danych biometrycznych na żądanie).
Kroki działania w systemie
1. Użytkownik otwiera zarządzanie voiceprintami.
2. Na liście użytkowników widzi kolumnę z informacją, kto ma zarejestrowany wzorzec głosu
3. Tworzenie voiceprintu podczas rozmowy. Użytkownik inicjuje proces rejestracji głosu. Może to wyglądać tak:
o Wywołuje funkcję dodawania voiceprint przy danym użytkowniku. System przechodzi w tryb nasłuchiwania (o ile stacja
robocza ma mikrofon) lub generuje link/kod dla urządzenia mobilnego użytkownika.
o Użytkownik (w obecności administratorki lub poprzez swój telefon/aplikację) czyta na głos przedstawiony przez system
tekst (np. kilka zdań lub ciąg cyfr). System nagrywa próbkę głosu i automatycznie tworzy z niej wzorzec głosowy.
o Postęp jest widoczny: np. wskaźnik nagrywania, informacja „Proszę mówić przez 10 sekund… zakończono”.
o Po zakończeniu, system wyświetla komunikat „Voiceprint utworzony pomyślnie” i nowy status przy Użytkowniku:
zarejestrowano (dzisiaj, przez użytkownika).
4. Usuwanie voiceprintu: Użytkownik demonstruje usunięcie. Np. dla Użytkownika klika
„Usuń voiceprint”. System pyta o potwierdzenie (bo to działanie nieodwracalne). Użytkownik potwierdza. Status
Użytkownika zmienia się na brak voiceprintu, a dane biometryczne zostają usunięte z bazy.
5. Import voiceprintu: Teraz Użytkownik chce zaimportować istniejący wzorzec (np. z zewnętrznego systemu). Wybiera
opcję „Importuj voiceprint” i wskazuje plik voiceprintu
danego użytkownika oraz dane użytkownika, do którego ma zostać przypisany (Użytkownik). System zapisuje voiceprint
Użytkownika (ew. nadpisując to co nagrano przed chwilą, albo scenariusz alternatywny: najpierw usunięto i teraz import).
Status Użytkownika pozostaje „zarejestrowany”, a w logach odnotowano import (źródło zewnętrzne).
6. Użytkownik prezentuje w logach audytu, że wykonane zostały operacje: utworzenie voiceprintu dla Użytkownika,
usunięcie dla Użytkownika, import dla Użytkownika – wraz z czasem i swoim identyfikatorem, co dowodzi pełnej kontroli i
audytowalności tych działań.
Oczekiwany rezultat
System oferuje intuicyjne narzędzia do pełnego cyklu zarządzania voiceprintami:
Dodawanie (rejestrowanie) głosu użytkownika przebiega sprawnie – wystarczy krótka próbka, po której system
potwierdza pomyślną rejestrację.
Usuwanie natychmiast usuwa powiązane dane i zmienia status użytkownika (co jest ważne np. w kontekście RODO –
prawo do usunięcia danych biometrycznych).
Import umożliwia przeniesienie danych biometrycznych z innej bazy, co przydaje się przy migracji systemu lub
integracji z dedykowanym modułem biometrii.
Voiceprinty nie umożliwiają syntezy głosu użytkownika poprzez operację odwrotną do tworzeni voiceprintu
Po tych operacjach użytkownicy mogą np. korzystać ze swoich voiceprintów do logowania, a system od strony
administracyjnej ma nad tym pełną kontrolę. W efekcie, mechanizm zarządzania spełnia wymagania bezpieczeństwa
(np. nie można podejrzeć samego nagrania – tylko usunąć lub zastąpić, co chroni prywatność; dostęp do funkcji mają
tylko admini). W komisji buduje to zaufanie, że biometria głosowa jest dobrze zaimplementowana i daje się zarządzać.
Skala punktowa
0 pkt – System nie obsługuje voiceprintów w ogóle. Brak jakichkolwiek funkcji związanych z biometrią głosową. W
konsekwencji nic nie zostało zaprezentowane w tym obszarze.
0,5 pkt – System posiada mechanizm weryfikacji głosowej ale voiceprinty są tworzone w sposób umożliwiający
odtworzenie na ich podstawie próbki głosu z jakiego zostały utworzone przez co nie spełniają elementarnych wymagań w
zakresie bezpieczeństwa danych biometrycznych
1 pkt – System posiada pewne elementy biometrii głosowej, lecz zarządzanie nimi jest bardzo słabo rozwinięte. Np.
voiceprint tworzy się ewentualnie podczas rejestracji użytkownika, ale administrator nie ma opcji samodzielnego
wywołania procesu lub usunięcia wzorca (musiałby np. skasować całe konto). Import zewnętrznych voiceprintów nie jest
możliwy. Demonstracja być może pokazała tylko, że ktoś ma już voiceprint, ale nie jak go tam umieszczono. Ogólnie
zarządzanie nie jest udostępnione jako oddzielna funkcja – voiceprinty działają jak ukryty element systemu
1,5 pkt – Podstawowe funkcje zarządzania voiceprintami są dostępne: rejestracja i usunięcie. Wykonawca pokazał, że
może nagrać wzorzec głosu użytkownika (np. za pomocą aplikacji) i że może go usunąć z bazy. Jednak brakuje importu
lub innych zaawansowanych działań. System więc pozwala na budowę bazy voiceprintów i ich kasowanie, ale nie
obsługuje przenoszenia danych między systemami. Ewentualnie import jest możliwy tylko w formie nieoficjalnej (np.
bezpośrednia manipulacja bazą, nie przez interfejs)
2 pkt – Wzorcowe zarządzanie voiceprintami. System oferuje bogaty, dopracowany interfejs do administrowania
biometrią głosową. W prezentacji wszystko przebiegło sprawnie: rejestracja głosu w czasie rzeczywistym (jedna próba,
10 sekund – gotowe), usunięcie jednym kliknięciem, import szybko i bez błędów. Dodatkowo mogą istnieć dodatkowe
funkcje warte odnotowania: np. możliwość testowego zweryfikowania voiceprintu (sprawdzenie jakości wzorca), eksportu
(kontrolowanego) w celach backupu czy podglądu listy wszystkich zarejestrowanych voiceprintów z informacją o
jakości/aktualności. Mechanizmy te działają
zgodnie z oczekiwaniami i są zabezpieczone (np. potwierdzenia przy usuwaniu). System, który może być zintegrowany,
prawdopodobnie dostarcza takie możliwości – zakładamy, że demonstracja je uwzględniła. Przyznane 4 pkt oznacza, że
komisja nie ma wątpliwości co do możliwości zarządzania bazą voiceprintów – jest ona w pełni pod kontrolą
Zamawiającego.
9. Mechanizm skuteczności biometrii głosowej (max. 2 pkt).
Cel funkcjonalny
Ocena, na ile efektywnie system potrafi weryfikować tożsamość użytkownika na podstawie głosu, czyli jaki jest poziom
skuteczności zastosowanej biometrii głosowej. Innymi słowy, mechanizm ten powinien potwierdzić, że logowanie lub
identyfikacja za pomocą głosu działa dokładnie i niezawodnie, odróżniając właściwych użytkowników od niepowołanych z
wysoką trafnością. Celem jest wykazanie, że biometria głosowa jest praktycznie użyteczna – akceptuje prawidłowych
użytkowników (ich głos) i odrzuca osoby podszywające się.
Kroki działania w systemie
1. Użytkownik próbuje zalogować się głosem. Użytkownik czyta na głos wymaganą frazę ().
o System porównuje próbkę głosu z voiceprintem Użytkownika.
o Rezultat: Pozytywna weryfikacja – system rozpoznaje, że głos należy do Użytkownika (prawowitego użytkownika).
Wyświetla komunikat np. „Weryfikacja głosowa pomyślna” i pozwala na dalsze działanie.
2. Impostor (osoba nieuprawniona) – teraz testujemy sytuację ataku:
o Podszywający się użytkownik () wypowiada tę samą frazę co Użytkownik (ale może też inną).
o System dokonuje analizy i porównuje z voiceprintem Użytkownika.
o Ponieważ głos nie należy do Użytkownika, wynik powinien być negatywny. System odrzuca próbę – np. komunikat
„Weryfikacja głosowa nieudana – głos niezgodny z wzorcem”. Brak dostępu.
3. Można powtórzyć różne warianty:
o Uzytkownik loguje się swoim głosem – powinna zostać poprawnie rozpoznana (sukces).
o Użytkownik próbuje użyć cudzego konta (ale i tak musi swoim głosem – co system odrzuci, bo głos nie pasuje do
voiceprintu konta innej osoby).
o Test odporności: odtwarzamy nagranie Użytkownika sprzed lat lub z zakłóceniami, by zobaczyć czy system nadal go
rozpozna (zakładamy, że tak, o ile jakość nie spadła drastycznie).
4. W przypadku zaawansowanych systemów, mechanizm skuteczności może pokazywać pewne metryki:
o Np. po każdej próbie wewnętrznie liczony jest score dopasowania (np. 87%).
o Administrator może mieć dostęp do statystyk: ile prób logowania głosowego się powiodło, ile nie, czy wystąpiły jakieś
fałszywe akceptacje/odrzucenia.
o Dla prezentacji, można pokazać np. w logu technicznym, że dla próby Użytkownika score był 98% (powyżej progu 90%
– akceptacja), dla impostora 40% (poniżej progu – odrzucenie).
5. Użytkownik (admin) może zademonstrować konfigurację progu wrażliwości: np. ustawić poziom bezpieczeństwa
wyżej czy niżej i powtórzyć test. Ale to opcjonalne.
Oczekiwany rezultat
Mechanizm biometrii głosowej demonstruje wysoką skuteczność i wiarygodność. Wszystkie przeprowadzone próby
autentycznego użytkownika kończą się pozytywną weryfikacją, a próby oszustwa – negatywną, co oznacza, że system
nie dopuścił nieautoryzowanego dostępu. Jeśli testowano graniczne przypadki (np. nieco zniekształcony głos
prawidłowego użytkownika),
system nadal sobie poradził albo pokazał, że ma pewien zapas tolerancji (np. poprosił o powtórzenie frazy, ale nie
wpuścił kogoś o innym głosie). W idealnym przypadku zaprezentowano też liczbowo skuteczność: np. „system
rozpoznaje głos z 99% dokładnością” – jednak nawet bez tego, sam fakt bezbłędnego rozpoznania w kilku próbach jest
dowodem jakości.
Skala punktowa:
0 pkt – Nie pokazano działania biometrii głosowej lub jest ona nieskuteczna. Np. system w ogóle nie rozpoznaje nawet
poprawnego użytkownika (liczne błędy odrzucenia) albo – co gorzej – przepuszcza obce głosy. Jeżeli w demonstracji
próba uwierzytelnienia głosem zawodzi dla właściwej osoby, lub uda się zalogować „cudzym” głosem, oznacza to
poważny problem – skuteczność bliska zeru – i 0 punktów.
0,5 pkt – System wykazuje niski poziom skuteczności. Pojawiają się częste błędy: np. prawidłowy użytkownik musi
kilkukrotnie powtarzać próbkę, bo system go nie rozpoznaje za pierwszym/drugim razem. Albo dopuszczono pewien
przypadek niepoprawny (np. inna osoba o bardzo podobnym głosie mogła przejść – może nie celowo zaprezentowane,
ale wykonawca nie gwarantuje, że do takich sytuacji nie dojdzie). Widać, że technologia jest zawodna lub bardzo
wrażliwa na warunki (np. minimalny hałas powoduje problemy). Ogólnie zaufanie do mechanizmu jest niskie.
1 pkt – Umiarkowana skuteczność. System generalnie rozpoznaje właściwy głos i odrzuca obcy, ale w testach mogły
się zdarzyć drobne potknięcia. Na przykład:
o Pierwsza próba logowania Użytkownika nie powiodła się (może mówił za cicho lub za szybko), dopiero druga się udała
– co sugeruje, że trzeba uważać.
o System rozpoznał obcy głos poprawnie jako obcy (czyli zablokował), jednak demonstrujący ostrzegł, że w pewnych
okolicznościach, np. przy bardzo podobnych głosach, może być pomyłka.
o Podsumowując, mechanizm jest funkcjonalny, ale nie bezbłędny. Komisja widzi, że działa, ale z pewną ostrożnością.
1,5 pkt – Wysoka skuteczność w praktyce. W trakcie demonstracji system nie popełnił żadnego błędu rozpoznania w
zaprezentowanych przypadkach. Zarówno Użytkownik, jak i Anna byli prawidłowo uwierzytelnieni, a obcy głos został
odrzucony natychmiast. Wykonawca zapewnił, że EER ma wartość nie większą niż 6% i wykazał metodę wyznaczenia
EER.
2 pkt – Nadzwyczajna skuteczność i odporność mechanizmu. Oprócz spełnienia warunków z poziomu 3 (bezbłędne
rozpoznania w testach), system wykazuje odporność na próby obejścia z użyciem zaawansowanych metod ataku. W
prezentacji mogło to zostać zademonstrowane lub omówione. Przykładowo:
o Dodatkowo mechanizm może adaptować się do użytkownika (aktualizować voiceprint po udanych logowaniach, żeby
uwzględnić naturalne zmiany głosu, np. starzenie, drobne choroby, różne tło).
10. Skuteczność działania mechanizmu zabezpieczającego przed atakami (max. 2 pkt).
Cel funkcjonalny
Wykazanie, że system posiada zaimplementowane solidne mechanizmy bezpieczeństwa chroniące przed atakami
prezentacji. Mechanizm ma za zadanie zabezpieczyć system przed logowaniem z wykorzystaniem odtworzonego
nagrania w scenariuszu, gdy po rozpoczęciu procesu logowania osoba mówiąca przestaje mówić i zaczyna odtwarzać
nagranie lub syntezowany głos. Scenariusz ten ma za zadanie wykluczyć przypadki, w których proces logowania
rozpoczyna się od mowy przez osobę o niskiej spójności biometrycznej z voiceprint ale 100% żywotności głosu, a po
chwili następuje podmiana na odtwarzany głos o 0% żywotności, ale wysokiej spójności biometrczynej. W sytuacji takiej
wiele
systemów wykaże uśredniony wynik spójności biometrycznej, który może spowodować spełnienie kryterium akceptacji
użytkownika
Kroki działania w systemie
W procesie logowania głosowego na początku mówi osoba o bardzo niskiej spójności biometrycznej z voiceprintem
Użytkownika (lub wszystkimi voiceprintami z bazy).
Po 2 sekundach osoba logująca się przestaje mówić i zaczyna odtwarzać nagranie z głosem Użytkownika, na którego
konto chce zalogować się.
System automatycznie wykrywa zmianę źródła emisji głosu z człowieka na głos odtwarzany i blokuje możliwość
logowania wraz z odpowiednim komunikatem systemowym oraz wpisem w logu zdarzeń ze wszystkimi szczegółami.
Oczekiwany rezultat
System efektywnie identyfikuje i zapobiega próbom ataku prezentacji. Przy pierwszej próbie realizacji ataku poprzez
zamianę źródła emisji strumienia głosowego następuje zablokowanie możliwości zalogowania.
Oczekiwane jest 100% skuteczne działanie przy odtwarzaniu nagrania w jakości SACD.
Skala punktowa
0 pkt – System nie zabezpieczony przed atakami prezentacji
0,5 pkt – Minimalne zabezpieczenia. System zabezpieczony przed atakami prezentacji, ale przy nagraniach o jakości
gorszej niż SACD oraz skuteczny dla mniej niż 95% ataków
1 pkt – Działające kluczowe mechanizmy bezpieczeństwa. System zabezpieczony przed atakami prezentacji przy
nagraniach o jakości SACD oraz skuteczny dla mniej niż 95% ataków
1,5 pkt – Zaawansowane zabezpieczenia i monitorowanie. Oprócz bazowych mechanizmów (jak blokada), system
oferuje coś więcej: np. wykrywanie podejrzanej aktywności (co w demo mogło być zainscenizowane) i reagowanie na
nią. Administrator dysponuje czytelnym podglądem zdarzeń bezpieczeństwa, a system być może integruje się z SIEM
(jeśli to wspomniano). W każdym razie, w ocenie komisji rozwiązanie posiada solidną wielowarstwową ochronę,
wykraczającą poza minimum. Wykonawca mógł wspomnieć np. że hasła są przechowywane hashowane, że każda
próba logowania jest logowana wraz z IP, że po godzinach pracy dostęp jest wyłączany – choć nie wszystko da się
pokazać, buduje to obraz wysokiej dbałości o bezpieczeństwo.
2 pkt – Wzorcowe bezpieczeństwo, w pełni potwierdzone działaniem. System zabezpieczony w 100% przed atakami
prezentacji z odtwarzaniem w nagrań w jakości SACD dla opisanego scenariusza
11. Mechanizm dwuetapowej autentykacji przy logowaniu. (max. 2 pkt).
Cel funkcjonalny
Zaprezentowanie procesu dwustopniowego uwierzytelniania (2FA) w oparciu o technologie głosowe. Podczas logowania
musimy jedynie przeczytać krótką sekwencję znaków/tekstową znajdującą się na ekranie. Logowanie dwustopnione jest
niezwykle bezpieczne poprzez podwójną autentykację. Podczas czytania tekstu weryfikowane są jednocześnie
zgodność odczytanych słów (pierwszy stopień) z wzorcem jak również biometryczna zgodność głosu mówcy z jego
VoicePrintem (drugi stopień).
Kroki działania w systemie
1. Użytkownik rozpoczyna logowanie do systemu (np. na laptopie z mikrofonem lub smartfonie). Na ekranie logowania
pojawia się tekst do przeczytania i startuje licznik 10 sekund w którym Użytkownik musi przeczytać tekst
2. System rozpoznaje zgodność przeczytanego tekstu z wyświetlonym (1 stopień) oraz spójność biometryczną głosu z
voiceprintem (2. stopień)
3. W przypadku zgodności w obydwu stopniach następuje zalogowanie a w przypadku niezgodności chociaż jednego
stopnia następuje odrzucenie logowania.
4. Przy próbie kolejnego logowania wyświetlany jest nowy tekst do przeczytania
w każdym przypadku logowania (sukces/porażka) w logu systemowym następuje zarejestrowania danych logowania
wraz ze wszystkimi informacjami takimi jak data i czas zdarzenia, tekst do przeczytania, tekst rozpoznany, spójności
biometryczna głosu.
Oczekiwany rezultat
System pomyślnie demonstruje pełen proces VoiceToken logowania. Dla komisji ważne jest zobaczenie, że:
Cały proces jest przyjazny użytkownikowi: interfejs wyraźnie informuje co zrobić (tekst do odczytania jest czytelny) i
obywa się w pełni automatycznie.
Bezpieczeństwo: tekst do przeczytania jest zawsze inny, składa się z losowych elementów, co utrudnia podszycie się
Logowanie jest w pełni dwustopniowe za sprawą wykorzystania dwóch odmiennych technologii logowania
Skala punktowa
0 pkt – Funkcjonalność nie istnieje lub nie została pokazana. Np. system wspiera tylko zwykłe logowanie hasłem;
wykonawca nie ma możliwości pokazać drugiego etapu z głosem.
0,5 pkt – Częściowe wdrożenie 2FA głosem. Być może system umożliwia co prawda potwierdzanie głosem, ale w
sposób niepełny. Przykład: nie generuje dynamicznego tekstu – użytkownik zawsze powtarza tę samą frazę (co jest
mniej bezpieczne, bo może być nagrana). Albo procedura jest bardzo niezgrabna technicznie (np. użytkownik musi sam
uruchomić nagrywanie w oddzielnej aplikacji i załadować plik – mało przyjazne). Jeśli w demonstracji pojawiły się
znaczne trudności (kilkukrotne powtarzanie frazy, bo nie rozumie, długi czas analizy) – to również wskazuje na niski
poziom tej funkcji. Punkt 1 jeśli coś jest, ale raczej jako ciekawostka niż użyteczne rozwiązanie.
1 pkt – Dwuetapowe logowanie głosem działa, ale z pewnymi problemami. Mechanizm VoiceToken jest
zaimplementowany podstawowo: pseudolosowa fraza jest wybierana bazy predefinownych haseł, która nie jest silnie
zabezpieczona lub liczność bazy umożliwia stworzenie listy haseł po do odczytania po wielokrotnym logowaniu. Mimo to
finalnie udało się zalogować i zabezpieczenie zadziałało. Inaczej mówiąc – spełniono wymóg, ale mechanizm logowania
przynajmniej w jednym stopniu jest relatywnie łatwy do złamania
1,5 pkt – Pełna realizacja funkcji VoiceToken bez zauważalnych wad. W demonstracji logowanie dwuskładnikowe
głosem przebiegło sprawnie za pierwszym razem i system poprawnie uwierzytelnił użytkownika. Nie było wątpliwości co
do działania (żadnych błędów rozpoznania, komunikaty jasne). Wykonawca wykazał, że mechanizm jest dobrze
zintegrowany i przemyślany. To najpewniej zadowoli Zamawiającego – stąd wysoka ocena. Aby osiągnąć jeszcze
wyższą, musiałby zostać pokazany dodatkowy kontekst bezpieczeństwa. Jeśli wszystko poszło gładko i zgodnie z
opisem, 3 pkt to odpowiednia ocena.
2 pkt – Wyróżniająca się prezentacja dwuetapowej autentykacji głosem. Poza poprawnym działaniem (jak w pkt 3),
wykonawca mógł zaprezentować dodatkowe scenariusze i informacje, które dowodzą, że system jest bardzo dojrzały w
tym obszarze. Np.:
o Generalnie, komisja jest pod dużym wrażeniem – funkcja działa jak reklamowana: „dwustopniowa, silna autentykacja
przy użyciu samego głosu”. Najwyższa ocena wskazuje, że rozwiązanie VoiceToken zostało kompletnie i przekonująco
przedstawione i działa bez zarzutu, zapewniając zarówno bezpieczeństwo, jak i wygodę użytkownika na poziomie
wyższym niż tradycyjne metody.
Zarzut nr 3 Definicja Oprogramowania Standardowego i Oprogramowania Dedykowanego
Odwołujący zarzuca, iż w dokumentacji przetargowej występują wadliwie, niejednoznacznie sformułowane definicje
Oprogramowania Dedykowanego, które uniemożliwiają złożenie oferty.
Odpowiedź Zamawiającego:
Zamawiający, określając definicje Oprogramowania Standardowego i Oprogramowania Dedykowanego, kierował się
koniecznością zabezpieczenia interesu publicznego oraz zapewnienia możliwości samodzielnego lub zleconego
dalszego rozwijania systemu w zakresie modyfikacji i rozbudów stworzonych w ramach realizacji umowy. Z tego
względu modyfikacje i rozbudowy Oprogramowania Standardowego, powstałe w toku realizacji zamówienia, stanowią
Oprogramowanie Dedykowane i w tym zakresie Zamawiający ma prawo żądać przekazania kodów źródłowych oraz
praw autorskich. Takie podejście jest uzasadnione potrzebą zapewnienia ciągłości działania i możliwości
dostosowywania systemu do przyszłych wymagań prawnych, organizacyjnych i technologicznych, bez uzależnienia od
jednego wykonawcy. Brak pozyskania praw i kodów źródłowych do stworzonych lub zmodyfikowanych elementów
mógłby uniemożliwić dalsze utrzymanie i rozwój systemu, a tym samym narazić Zamawiającego na istotne ryzyko
organizacyjne i finansowe. Jednocześnie, by wyeliminować niejasności interpretacyjne dotyczące zakresu
znaczeniowego Oprogramowania Standardowego i Oprogramowania Dedykowanego Zamawiający w definicji
Oprogramowania Standardowego zawartego w Opisie Przedmiotu Zamówienia (tabela z definicjami, definicja
„Oprogramowanie”) wprowadza następującą modyfikację polegającą na wykreśleniu konieczności przekazania kodów
źródłowych w przypadku oprogramowania standardowego. Ten element został ujęty przez Zamawiającego w definicji
omyłkowo.
(…)
JEST
Oprogramowanie - całość lub dowolny element oprogramowania dostarczany lub wykonywany w ramach realizacji
Umowy. W skład oprogramowania wchodzi:
1) „Oprogramowanie Standardowe” – oprogramowanie będące podstawą do budowy Systemu i/ tworzące środowisko, w
którym uruchamiany jest System, istniejące i dystrybuowane przed zawarciem Umowy.
2) „Oprogramowanie Dedykowane” – oprogramowanie tworzone przez Wykonawcę lub osoby, którymi się posługuje w
wykonaniu zobowiązań z Umowy, w tym rozbudowa lub modyfikacja Oprogramowania Standardowego.
Oprogramowanie dedykowane jest specjalnie stworzone tylko do realizacji przedmiotu Umowy lub stworzenie jego
wynika z potrzeb Zamawiającego. Na oprogramowanie dedykowane Wykonawca przekazuje kody źródłowe oraz
wszelkie prawa autorskie do oprogramowania.
Zarzut nr 4 Exit Plan
Odwołujący nie może zaakceptować tak ogólnych zapisów, które mogą być bardzo szeroko interpretowane i mogą
zmaterializować się w bardzo kosztowny projekt doradczo-konsultingowy. Odwołujący na etapie składania oferty nie jest
w stanie zidentyfikować tak blankietowo opisanych zobowiązań, a w konsekwencji ich wycenić.
Odpowiedź Zamawiającego:
Zamawiający nie podziela zarzutu sformułowanego przez Odwołującego. Zakres obowiązków wynikających z tzw. Exit
Planu zależy w istotnym stopniu od rodzaju i architektury zastosowanego oprogramowania, a także od przyjętych
rozwiązań technicznych i organizacyjnych po stronie Wykonawcy. W związku z tym to Wykonawca, dysponując wiedzą
o proponowanym przez siebie systemie i sposobie jego wdrożenia, jest w stanie najlepiej oszacować nakład pracy
niezbędny do realizacji zobowiązań wynikających z Exit Planu. Określenie w dokumentacji postępowania sztywnej liczby
roboczogodzin mogłoby prowadzić do sytuacji, w której przyjęty limit byłby nieadekwatny – zbyt wysoki lub zbyt niski –
względem rzeczywistych potrzeb. W pierwszym przypadku powodowałoby to niegospodarność, w drugim zaś ryzyko
niewystarczającego wykonania zobowiązań. Dlatego Zamawiający pozostawił tę kwestię do oceny Wykonawcy,
zobowiązując go do uwzględnienia kosztu realizacji Exit Planu w kalkulacji ceny ofertowej. Takie rozwiązanie jest
racjonalne i zgodne z zasadami efektywnego wydatkowania środków publicznych. (…)
Odwołujący w piśmie procesowym z dnia 22 września 2025 r. wskazując na art. 520 ust. 1 i 2 ustawy z dnia 19
września 2019 r. – Prawo zamówień publicznych oświadczył: (...) po zapoznaniu się z odpowiedzią Zamawiającego na
odwołanie z dnia 7 sierpnia 2025 i zapowiedzianymi zmianami w SW Z, które realizują co do zasady żądania odwołania,
niniejszym cofam odwołanie (sygn. akt KIO 3313/25) w całości.”.
Izba ustaliła i zważyła, co następuje:
Postępowanie odwoławcze w niniejszej sprawie podlega umorzeniu na podstawie art. 520 ust.1 ustawy Pzp w
związku z oświadczeniem złożonym przez wnoszącego odwołanie wykonawcę o cofnięciu odwołania. Zgodnie z art. 520
ust. 1 ustawy Pzp: „Odwołujący może cofnąć odwołanie do czasu zamknięcia rozprawy”.
W niniejszej sprawie ma zastosowanie wskazany przepis, albowiem Odwołujący w piśmie z dnia 22 września
2025 r. - przed wyznaczeniem terminu posiedzenia i rozprawy jednoznacznie oświadczył, że cofa odwołanie wniesione
w przedmiotowym postępowaniu o udzielenie zamówienia publicznego.
Izba dodatkowo zauważa, że w myśl art. 520 ust. 2 Pzp: „2.Cofnięte odwołanie nie wywołuje skutków prawnych,
jakie ustawa wiąże z wniesieniem odwołania do Prezesa Izby”. Odwołujący – jak podkreśla się w orzecznictwie i doktrynie
Prawa zamówień publicznych - jest dysponentem wniesionego przez siebie odwołania, co przejawia się również w
uprawnieniu do jego wycofania. Krajowa Izba Odwoławcza nie bada i nie ocenia przyczyn cofnięcia odwołania. Bada
wyłącznie formalną skuteczność złożenia oświadczenia o jego cofnięciu. Skuteczne cofnięcie odwołania jest wiążące dla
Krajowej Izby Odwoławczej. Ponadto cofnięcie odwołania nie wymaga zgody pozostałych stron i uczestników
postępowania.
Tym samym Izba na podstawie art. 568 pkt 1 ustawy Pzp w związku z art. 520 ust.1 powołanej ustawy
postanowiła o umorzeniu postępowania odwoławczego.
Orzekając o kosztach postępowania odwoławczego Izba miała na uwadze art. 557 ustawy Pzp oraz § 9 ust. 1 pkt
3 lit. a) rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów
postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania (Dz.U. z 2020 r.,
poz. 2437) i uwzględniając wskazane przepisy, nakazała zwrócić na rzecz Odwołującego 90% kwoty wpisu uiszczonego
od odwołania w wysokości 15.000 zł.
Mając powyższe na uwadze postanowiono jak w sentencji.
………………………………………
………………………………………
………………………………………