RozstrzygniętyZapytanie ofertowe (fundusze)
Dostawa aplikacji mobilnej dla studentów kierunku zarządzanie Wydziału Nauk Ekonomicznych
Uniwersytet Mikołaja Kopernika w Toruniu17 aktualnych · 163 w archiwum·NIP 8790177291·kujawsko-pomorskie
Rozstrzygnięcie
Kto wygrał, za ile i ilu było chętnych.
WygrałaPaweł Kwiatkowski
NIP zwycięzcy8672257376
Kwota oferty61 500,00 zł
Złożonych ofert18
Widełki ofert61 500,00 zł – 329 475,18 zł
Najtańsza oferta wygrałatak
Przedmiot zamówienia
AIOpracowanie, wdrożenie i utrzymanie dedykowanego systemu informatycznego składającego się z aplikacji mobilnej oraz responsywnego panelu administracyjnego.
- Projekt koncepcji biznesowej, interfejsu użytkownika oraz architektury bazy danych.
- Dostarczenie oprogramowania na urządzenia mobilne (systemy Android i iOS) oraz przeglądarkowego panelu do zarządzania treścią i użytkownikami.
- Przeprowadzenie szkoleń dla administratorów i redaktorów (zespół Zamawiającego).
- Utrzymanie techniczne, wsparcie serwisowe oraz usuwanie błędów przez okres 12 miesięcy od zakończenia wdrożenia.
- Przekazanie kompletnej dokumentacji systemowej oraz otwartych kodów źródłowych.
Trudność: wysoka
Zamówienie wymaga stworzenia od podstaw dedykowanego oprogramowania z rozbudowaną logiką biznesową (grywalizacja), spełnienia specyficznych wymogów bezpieczeństwa i dostępności, a także zapewnienia długoterminowego wsparcia technicznego.
Kryteria wyboru oferty
AIWagi punktowe, według których zamawiający oceni oferty.
- Cena ofertowa brutto: 100%
Czerwone flagi
AISygnały, na które warto zwrócić uwagę przed startem.
Termin składania ofert: 3 dni (mediana dla CPV 72: 10 dni)
Termin jest znacznie krótszy niż typowy dla tej branży (30% mediany). Może to ograniczać liczbę oferentów.
Termin składania ofert przypada na okres wakacyjny (16 lipca)
Termin w okresie wakacyjnym (lipiec-sierpień) może ograniczać liczbę oferentów ze względu na urlopy.
Kary i sankcje
AI- Kary umowne: szczegółowe zapisy w projekcie umowy (załącznik nr 2 do zapytania ofertowego)
Pytania i odpowiedzi
60Wyodrębnione z wyjaśnień treści SWZ.
1Czy mechanikę gry (zasady punktacji, balans, logikę grywalizacji) projektuje Wykonawca w ramach koncepcji biznesowej Etapu I, czy Zamawiający dostarcza gotowe, kompletne reguły?
Zamawiający potwierdza, że czynności te są po stronie Zamawiającego.
1W punkcie 4.2 (tabela WTS.5) pojawia się zapis: "Aplikacja będzie wykonana za pomocą narzędzi do tworzenia aplikacji natywnych (samodzielnych)". Czy jest to bezwzględne wymaganie, czy Zamawiający dopuści wykonanie aplikacji w technologii cross-platform (np. Flutter)?
Dopuszczalne jest zastosowanie rozwiązania międzyplatformowego, w tym technologii React Native, pod warunkiem spełnienia wszystkich wymagań określonych w OPZ.
2Punkt 2.3 wspomina o "fabule" i "bohaterze". Pytanie 2.1: Czy Zamawiający oczekuje, że Wykonawca zaproponuje spójną i rozbudowaną fabułę (scenariusz, narracja, bohaterowie), która będzie przewijać się przez wszystkie rundy, czy chodzi raczej o prostą oprawę graficzną (tzw. skin) dla mapy postępu?
Wykonawca wykona oprawę graficzną dla mapy postępu. Fabułę przygotuje Zamawiający.
2Czy katalog typów zadań i wyzwań z rozdz. 8.1 OPZ (drzewo decyzyjne/ankieta, wideo/grafika z polubieniami, predykcja kursów walut, zdarzenia losowe, koło fortuny z odgadywaniem hasła, dopasowanie kart) jest zamknięty i ostateczny?
Tak, katalog typów zadań i wyzwań jest zamknięty i ostateczny.
3Punkt 8.1 opisuje różne typy zadań (kwestionariusz, wybór walut, mini-gry). Czy Zespół Projektowy będzie miał możliwość dynamicznego tworzenia nowych typów zadań za pomocą panelu administracyjnego, czy pula typów zadań jest zamknięta i zostanie zdefiniowana na stałe na etapie programowania?
Pula typów zadań jest zamknięta i zostanie zdefiniowana na stałe. Zespół Projektowy będzie miał możliwość wyboru, które z typów zadań zostanie wykorzystane w danej rundzie.
3[KRYTYCZNE] Czy "mapa analogiczna jak w grach planszowych" (OPZ 2.3) musi być graficzną planszą 2D, czy Zamawiający dopuszcza uproszczoną ścieżkę/pasek postępu?
Zamawiający dopuszcza zastosowanie rozwiązania w formie uproszczonej ścieżki / paska postępu, w celu zachowania optymalnej czytelności interfejsu. Mapa nie musi być planszą graficzną 2D.
4Czy obie minigry "wyzwania dnia" są obowiązkowe w zakresie podstawowym?
Tak, obie minigry „wyzwania dnia” są obowiązkowe w zakresie podstawowym zamówienia.
4W punkcie 1.14 wskazano, że daną identyfikującą użytkownika będzie numer indeksu, natomiast w punkcie 2.2 opisano logowanie poprzez adres e-mail w domenie @stud.umk.pl oraz link aktywacyjny. Prosimy o doprecyzowanie docelowego modelu uwierzytelniania i identyfikacji użytkowników: a) Czy numer indeksu ma być wykorzystywany jako login, identyfikator techniczny użytkownika czy wyłącznie dana przechowywana w systemie? b) Z jakiego systemu Zamawiającego będą pobierane dane studentów, w tym numer indeksu, adres e-mail, status studenta oraz ewentualnie przypisanie do kierunku lub grupy? c) Czy Zamawiający przewiduje integrację z uczelnianym systemem tożsamości lub systemem dziekanatowym, np. SSO, LDAP, Active Directory, USOS albo innym systemem? d) Czy autoryzacja ma odbywać się wyłącznie przez jednorazową aktywację linkiem wysłanym na adres w domenie @stud.umk.pl, czy wymagane będzie dodatkowe uwierzytelnienie, np. login i hasło uczelniane lub logowanie jednokrotne? e) Czy Wykonawca otrzyma dostęp do API, dokumentacji technicznej, środowiska testowego oraz osoby kontaktowej po stronie systemu źródłowego? f) Czy zakres integracji ma obejmować wyłącznie weryfikację uprawnienia studenta do korzystania z aplikacji, czy również automatyczną synchronizację danych studentów, ich statusu, numerów indeksów, kierunków i grup? g) Czy w przypadku braku dostępnej integracji Zamawiający dopuszcza samodzielną rejestrację użytkownika na podstawie adresu @stud.umk.pl, z ręcznym lub automatycznym przypisaniem numeru indeksu? To pytanie jest ważne, ponieważ dokument zawiera dwie potencjalnie różne koncepcje: numer indeksu jako identyfikator użytkownika oraz e-mail uczelniany z aktywacją linkiem jako mechanizm logowania.
a) Czy numer indeksu ma być wykorzystywany jako login, identyfikator techniczny użytkownika czy wyłącznie dana przechowywana w systemie?
Odp.: Adres email w domenie @stud.umk.pl lub @umk.pl ma być niezbędny jedynie jako forma autoryzacji.
b) Z jakiego systemu Zamawiającego będą pobierane dane studentów, w tym numer indeksu, adres e-mail, status studenta oraz ewentualnie przypisanie do kierunku lub grupy?
Odp.: Zamawiający nie zamierza integracji aplikacji z API, Wykonawca ma weryfikować dostęp do aplikacji jedynie poprzez adres email i link aktywacyjny (ew. ponowne logowanie w przypadku ponownej instalacji aplikacji – np. na nowym telefonie)
c) Czy Zamawiający przewiduje integrację z uczelnianym systemem tożsamości lub systemem dziekanatowym, np. SSO, LDAP, Active Directory, USOS albo innym systemem?
Odp.: Zamawiający nie przewiduje integracji z uczelnianym systemem tożsamości lub systemem dziekanatowym, np. SSO, LDAP, Active Directory, USOS albo innym systemem.
d) Czy autoryzacja ma odbywać się wyłącznie przez jednorazową aktywację linkiem wysłanym na adres w domenie @stud.umk.pl, czy wymagane będzie dodatkowe uwierzytelnienie, np. login i hasło uczelniane lub logowanie jednokrotne?
Odp.: Wystarczy jednorazowa aktywacja linkiem, uwzględniając zastrzeżenie z pkt. B (możliwość ponownego dostępu w przypadku preinstalacji aplikacji.
e) Czy Wykonawca otrzyma dostęp do API, dokumentacji technicznej, środowiska testowego oraz osoby kontaktowej po stronie systemu źródłowego?
Odp.: Dostęp do API nie jest potrzebny – Wykonawca nie otrzyma do niej dostępu.
f) Czy zakres integracji ma obejmować wyłącznie weryfikację uprawnienia studenta do korzystania z aplikacji, czy również automatyczną synchronizację danych studentów, ich statusu, numerów indeksów, kierunków i grup?
Odp.: Zamawiający nie przewiduje integracji.
g) Czy w przypadku braku dostępnej integracji Zamawiający dopuszcza samodzielną rejestrację użytkownika na podstawie adresu @stud.umk.pl, z ręcznym lub automatycznym przypisaniem numeru indeksu?
Odp.: Rejestracja użytkownika jest wyłącznie na podstawie aktywacji linku, który został przesłany na adres w domenie @stud.umk.pl lub @umk.pl. Zaznaczamy, że adres email jest skonstruowany w następujący sposób: „numer indeksu”@stud.umk.pl lub „numer indeksu”@umk.pl, zatem identyfikator użytkownika jest związany z adresem email.
5Czy parametry minigier (hasła do koła fortuny, zestawy kart) mają być w pełni konfigurowalne przez Zespół Projektowy w panelu, czy mogą być zdefiniowane statycznie na wdrożeniu?
Tak, w pełni konfigurowalne przez Zespół Projektowy, Zamawiający nie dopuszcza statycznej wersji.
5W punkcie 8.1 wskazano, że panel administracyjny ma umożliwiać “zaprojektowanie, zapisanie i uruchomienie gry dla studentów wybranego kierunku”. Czy system ma obsługiwać wyłącznie jedną grę dla kierunku zarządzanie, czy również wiele niezależnych gier, edycji i grup uczestników? Czy jedna gra może być aktywna dla kilku grup studentów w różnych terminach, z osobnymi rankingami i harmonogramami rund? Czy redaktorzy ZP powinni mieć możliwość kopiowania, archiwizowania oraz edycji istniejących gier i rund, aby wykorzystać je ponownie w kolejnych edycjach? Czy podczas trwania aktywnej gry ZP może zmieniać treść zadań, punktację lub logikę odpowiedzi, które zostały już udostępnione studentom? Jeżeli tak, czy system ma przechowywać wersję historyczną treści i wyników? Czy drzewo decyzyjne w zadaniach ma umożliwiać wyłącznie przejście do kolejnego pytania zależnie od odpowiedzi, czy również zmianę punktacji, uruchomienie zdarzenia losowego, wyświetlenie komunikatu lub zakończenie zadania? Czy punktacja ma być przyznawana wyłącznie za odpowiedzi, czy również za czas wykonania zadania, aktywność, przesłanie materiału lub ocenianie materiałów innych studentów? Czy odznaki i nagrody, opisane w punkcie 2.3, mają być jedynie elementem informacyjnym w aplikacji, czy ZP ma móc samodzielnie definiować ich nazwy, grafiki, warunki przyznawania i wartości punktowe? Jakie dokładnie zasady powinny obowiązywać w rankingach: ranking globalny, ranking dla danej rundy, ranking dla konkretnej gry, ranking dla grupy studentów czy kilka rodzajów rankingów jednocześnie? Czy ranking powinien prezentować nicki studentów, numer indeksu, anonimowe identyfikatory czy wyłącznie pozycję danego studenta bez możliwości identyfikacji innych osób? Czy student ma mieć dostęp do wyników i rankingu dopiero po zakończeniu rundy, czy również w jej trakcie?
1. W jednym czasie będzie realizowana jedna gra składająca się z kilku rund. Czas rundy będzie jednakowy, tzn. w tym samym momencie, nie będzie realizowanych (otwartych) kilku rund.
2. Nie.
3. Tak.
4. Podczas trwania aktywnej gry ZP nie może zmieniać treść zadań, punktacji lub logikę odpowiedzi, które zostały już udostępnione studentom.
5. Drzewo decyzyjne ma możliwość zmiany punktacji, uruchomienia zdarzanie losowego, wyświetlenia komunikatu lub zakończenie zadania
6. Aplikacja powinna mieć możliwość przyznawania punktacji za wszystkie wymienione aspekty, nie tylko za odpowiedzi
7. ZP może samodzielnie definiować nazwy, grafiki, warunki przyznawania odznak i nagród.
8. Podstawowym rankingiem jest ranking globalny, który jest sumą rankingów z rund, gier i zadań.
9. Student może mieć możliwość ustawienia nicku. Ranking powinien prezentować nick studenta lub numer indeksu. Student może mieć dostęp do rankingu dopiero po zakończeniu rundy.
6Czy “utracone korzyści” mają być wyłącznie komunikatem o maksymalnej liczbie punktów możliwych do zdobycia, czy także szczegółowym wyjaśnieniem, które decyzje wpłynęły na wynik?
Utracone korzyści to wyjaśnienie, jakie decyzje wpłynęły na wynik.
6Ilu studentów (rząd wielkości) przewiduje się jako użytkowników i ile równoległych rund/gier może być aktywnych jednocześnie?
W danym roku kalendarzowym Zamawiający szacuje liczbę studentów na około 150. Równocześnie aktywna jest jedna runda, a Zespół Projektowy ma możliwość jej rozpoczęcia i zakończenia. Nie przewiduje się, aby w tym samym czasie aktywna była więcej niż jedna runda.
Historia zmian
30.06.2026 — publikacja ogłoszenia
30.06.2026 — aktualizacja ogłoszenia (Wartość szacunkowa: brak → 128 331 zł)
02.07.2026 — aktualizacja ogłoszenia (Termin składania: 08.07.2026 → 16.07.2026 · Wartość szacunkowa: 128 331 zł → brak)
16.07.2026 — upływ terminu składania ofert
16.07.2026 — ogłoszenie o wyniku postępowania