Załącznik nr 1 do Zaproszenia nr GPZ-196

81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
Załącznik nr 1
do Zaproszenia
nr GP-Z/ 196 /2014
SPECYFIKACJA WYMAGAŃ UŻYTKOWNIKA
1.
Cel Dokumentu
Niniejsza Specyfikacja Wymagań Użytkownika (zwana dalej SWU) precyzuje wymagania techniczne dla dostawy
i montażu systemu nowoczesnego zarządzania obiektem z optymalizacją zużycia mediów wraz z kontrolą dostępu
w Gdańskim Parku Naukowo-Technologicznego w Gdańsku przy ul. Trzy Lipy 3, w ramach projektu pn. „Gdański Park
Naukowo–Technologiczny – Etap III”. Specyfikacja stanowi techniczną podstawę wyboru Wykonawcy oraz techniczną
podstawę podczas realizacji zamówienia. W każdym przypadku przedmiot zamówienia musi spełniać wymagania
określone w SWU oraz w umowie.
2.
Informacje ogólne i zakres zamówienia
System i jego elementy objęte przedmiotem zamówienia powinny spełniać wymogi niniejszej SWU. Zamawiający
dopuszcza możliwość zastosowania rozwiązań równoważnych, pod warunkiem, że zaproponowane rozwiązania
równoważne będą posiadały wszystkie parametry nie gorsze niż te, które są określone w przedmiotowych dokumentach.
W przypadku, gdy Wykonawca powołuje się na rozwiązania równoważne względem opisanych przez Zamawiającego, jest
zobowiązany wykazać, że oferowane przez niego usługi spełniają wymagania określone przez Zamawiającego.
Zamawiany System ma zostać dostarczony wraz z niezbędnymi komponentami i usługami związanymi z wdrożeniem,
w szczególności obejmującymi:
• Uzyskanie wszelkich niezbędnych dokumentów, uzgodnień, warunków i decyzji niezbędnych dla podjęcia,
przeprowadzenia i przyjęcia do użytkowania Systemu,
• Opracowanie projektu i dokumentacji wykonawczej,
• Dostawę i zabudowę dwóch kompletów bramek typu tripod wraz bramkami uchylnymi (dla niepełnosprawnych
i dostaw),
• Dostawę i montaż pięciu kontrolerów dostępu IP dwustronnych wraz czytnikami,
• Dostawę i montaż jednego stanowiska personalizacji kart i konfiguracji systemu,
• Dostawę i montaż pięciu zwór elektromagnetycznych,
• Dostawę i instalację okablowania strukturalnego oraz zasilającego,
• Dostawę i montaż zasilania awaryjnego dla elementów aktywnych,
• Połączenie drzwi ewakuacyjnych z systemem SAP,
• Instalację wszystkich przewidzianych modułów i komponentów Systemu, w tym platformy systemowej, bazodanowej,
dostępowej, etc. na platformie serwerowej udostępnionej przez Wykonawcę,
• Udzielenie nieodpłatnej licencji bezterminowej i niewyłącznej do wykonanego Systemu i wszystkich jego elementów
3.
Lokalizacja systemu
SWU dotyczy zaznaczonego na rysunkach Systemu objętego przedmiotem zamówienia, które należy dostarczyć
i zamontować we wskazanych pomieszczeniach w lokalizacji zgodnej z załączonymi rysunkami budynku „A”.
4.
Granice dostawy
Wykonawca ponosi pełną odpowiedzialność za System i wszystkie jego elementy objęte zakresem dostawy. Wykonawca
przed przystąpieniem do realizacji zamówienia (w szczególności dostawy elementów Systemu) jest zobowiązany
do dokonania szczegółowych pomiarów z natury pomieszczeń, w których zamontowane będą elementy Systemu, oraz
rozmieszczenia istniejących przyłączy instalacyjnych, które stanowić będą granicę dostawy.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 1 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
5.
Transport i dostawa
Dostawa Systemu nastąpi transportem Wykonawcy oraz na jego koszt i ryzyko. Wszystkie elementy zostaną zapakowane
w sposób uniemożliwiający ich uszkodzenie podczas transportu. Za jakiekolwiek uszkodzenia Systemu podczas
transportu odpowiedzialność ponosi Wykonawca.
Wykonawca ponosi pełną odpowiedzialność za spełnienie wszelkich wymagań importowych oraz za zgodność z polskimi
przepisami celnymi. W przypadku, gdy władze polskie wymagać będą dodatkowych informacji i zaświadczeń w celu
wyrażenia zgody na import wyposażenia do Polski, Wykonawca spełni te wymagania bez konieczności ponoszenia
dodatkowych kosztów przez Zamawiającego.
6.
Montaż/Instalacja
• Wykonawca dostarczy poszczególne elementy Systemu do odpowiednich pomieszczeń udostępnionych przez
Zamawiającego. Montaż, podłączenie do istniejących przyłączy instalacyjnych w pomieszczeniach i uruchomienie
Systemu nastąpi staraniem, na koszt i ryzyko Wykonawcy. Wykonawca przekaże System Zamawiającemu w stanie
kompletnym, wyregulowanym, wyczyszczonym i gotowym do pracy bez konieczności dodatkowego doposażenia
(za wyjątkiem materiałów eksploatacyjnych),
• Wykonawca usunie własnym staraniem i na własny koszt opakowania, elementy po montażu, elementy wadliwe, etc.
Wykonawca pozostawi po montażu pomieszczenia objęte dostawą w stanie nie gorszym niż zastany, w tym
uprzątnie na swój koszt i ryzyko wszelkie odpady, resztki, śmieci etc.,
• Przed przystąpieniem do wdrożenia Wykonawca przedstawi projekt wykonawczy zgodnie z obowiązującymi normami
i przepisami. Wdrożenie powinno obejmować montaż i instalację poszczególnych komponentów wraz ze szkoleniami
użytkowników w wymiarze min. 5 x 4h,
• W ramach wdrożenia Wykonawca wykona niezbędne okablowanie strukturalne oraz zasilające urządzenia.
Wszystkie elementy aktywne mają zostać umieszczone w szafie teleinformatycznej o wysokości przynajmniej 15U
wraz z zasilaniem awaryjnym (czas podtrzymania co najmniej 20 min). Dla drzwi (wskazanych na Planie) należy
dostarczyć zwory elektromagnetyczne (180 kg). W przypadku wyjść ewakuacyjnych wykonać odpowiednie
połączenie do systemu SAP.
7.
Gwarancja
Wykonawca udziela minimum 5-letniej gwarancji na każdy element Systemu. Szczegółowe warunki gwarancji określone
są w projekcie umowy.
8.
Wymagania dotyczące szkolenia
Wykonawca będzie odpowiedzialny za nieodpłatne przeszkolenie osób wskazanych przez Zamawiającego w zakresie
eksploatacji i konserwacji dostarczanego Systemu. W ramach czynności odbiorowych należy przeszkolić wyznaczone
osoby w zakresie wykorzystania i prawidłowej obsługi urządzeń, tak, aby upewnić się, że poinstruowany personel posiada
odpowiednie kompetencje do obsługi danego urządzenia. Przeprowadzenie szkolenia z zakresu obsługi i konserwacji
Systemu będzie warunkiem pozytywnego odbioru końcowego Systemu.
Zakres szkolenia powinien obejmować minimum następujące zagadnienia:
• działanie i obsługa urządzeń, budowa urządzeń oraz jego poszczególnych części/podzespołów
• uruchamianie urządzeń i ich regulacja
• postępowanie w przypadku awarii, zabiegi konserwacyjne
• zagrożenia wynikające z obsługi urządzeń zasady bezpieczeństwa
• część praktyczna z m.in. wykonaniem testów potwierdzających sprawność urządzenia oraz zgodność parametrów
z dostarczoną specyfikacją.
Szkolenie powinno być przeprowadzone przez wyznaczony personel Wykonawcy w miejscu zainstalowanego Systemu
najpóźniej w dniu odbioru końcowego Systemu, zgodnie z obowiązującymi przepisami BHP i Polskimi Normami. Szkolenie
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 2 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
powinno zapoznać personel z zagrożeniami wynikającymi z obsługi urządzeń, na których będzie pracował, sposobami
ochrony przed zagrożeniami oraz metodami bezpiecznego wykonywania pracy z danym urządzeniem.
Informację na temat szkolenia Wykonawca przedstawi Zamawiającemu w formie pisemnej przynajmniej 1 tydzień przed
planowaną data zgłoszenia gotowości do odbioru końcowego Systemu. Informacja ta musi zawierać:
• planowany czas trwania szkolenia
• program szkolenia z podziałem na:
- nazwę i zakres szkolenia,
- sposób organizacji szkolenia,
- cele szkolenia,
- plan zajęć z uwzględnieniem części teoretycznej i praktycznej,
- wykaz literatury oraz niezbędnych środków i materiałów dydaktycznych.
Na zakończenie szkolenia wymagane będzie sporządzenie przez Wykonawcę protokołu z przeprowadzonego szkolenia.
Protokół powinien zawierać rodzaj i program szkolenia, listę uczestników szkolenia wraz z podpisami Wykonawcy oraz
uczestników szkolenia (na potwierdzenie odbycia szkolenia). Protokół należy przekazać Zamawiającemu w dniu odbioru
końcowego po zakończeniu szkolenia. Uprawniony przedstawiciel Wykonawcy przygotuje również certyfikaty
dla uczestników potwierdzające ich udział w szkoleniu.
9.
Budowa i wdrożenie systemu
W ramach wdrożenia Wykonawca wykona niezbędne okablowanie strukturalne oraz zasilające urządzenia. Wszystkie
elementy aktywne mają zostać umieszczone w szafie teleinformatycznej o wysokości przynajmniej 15 U wraz z zasilaniem
awaryjnym (czas podtrzymania co najmniej 20 min). Dla drzwi (wskazanych na Planie) należy dostarczyć zawory
elektromagnetyczne (180 kg). W przypadku wyjść ewakuacyjnych wykonać odpowiednie połączenie do systemu SAP.
9.1. Analiza przedwdrożeniowa
Wykonawca zrealizuje analizę przedwdrożeniową w oparciu o informacje uzyskane w drodze wywiadów i spotkań
z przełożonymi i pracownikami poszczególnych działów Zamawiającego. W wyniku przeprowadzonych rozmów
(w wymiarze nie mniej niż 40 godzin) Wykonawca opracuje dokument Analizy przedwdrożeniowej zawierający zestaw
niezbędny do prawidłowego wdrożenia i konfiguracji Systemu. Elementem Analizy przedwdrożeniowej będzie również
szczegółowy harmonogram wdrożenia określający terminy instalacji, konfiguracji i uruchomienia poszczególnych
elementów systemowych i modułów funkcjonalnych oraz proponowany zakres i terminy instruktaży stanowiskowych.
9.2. Wdrożenie
Wdrożenie powinno obejmować:
• montaż i instalację poszczególnych komponentów
• szkolenie użytkowników w wymiarze min. 5 x 4h on – site
• szkolenie użytkowników on-line w wymiarze 3 x 2h,
• pakiet godzin programistycznych w wymiarze 100h.
Wdrożenie obejmuje całość prac wykonanych przez Wykonawcę w siedzibie Zamawiającego i zdalnie, w oparciu
o najlepszą wiedzę Wykonawcy oraz dane określone w Analizie przedwdrożeniowej, a w szczególności:
1. Instalację wszystkich przewidzianych modułów i komponentów Systemu, w tym platformy systemowej, bazodanowej,
dostępowej, etc. na platformie serwerowej udostępnionej przez Wykonawcę,
2. Konfigurację Systemu do poprawnej pracy w zakresie wszystkich funkcjonalności, w tym w zakresie
konfiguracji uprawnień dla poszczególnych ról użytkowników,
3. Uzupełnienie słowników Systemu,
4. Udostępnienie Systemu na serwerach testowych Wykonawcy,
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 3 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
5.
6.
7.
8.
Integracja z kontami e-mail udostępnionymi przez Zamawiającego,
Integrację z systemami Zamawiającego (Symfonia),
Import notatek dotyczących najemców z pliku XLS,
Przygotowanie dedykowanej strony logowania platformy, zawierającej logo oraz kolorystykę parku, animowane
zdjęcia obiektów oraz możliwość zmiany języków (PL/ENG),
9. Przygotowanie filmu instruktażowo-promocyjnego o długości minimum 3 min pokazujący możliwości platformy,
wartości i cele projektu oraz zapewniający niezbędny instruktarz dla najemców. Film umieszczony będzie na stronie
logowania do platformy
Wykonawca zapewni możliwość bezpłatnej migracji Systemu z serwerów Wykonawcy na serwery Zamawiającego
w okresie do 12 miesięcy od daty podpisania umowy. Zamawiający dostarczy serwer i wykona konfigurację usług
serwerowych w oparciu o dokumentację minimalnych wymogów technicznych dostarczonych przez Wykonawcę.
Wdrożenie powinno obejmować montaż i instalację poszczególnych komponentów wraz ze szkoleniami użytkowników
w wymiarze 5 x 4h on- site, 3 x 2h on-line oraz pakiet 100 godzin programistycznych.
10. Wsparcie techniczne
W ramach zadania Wykonawca zaoferuje wsparcie techniczne na poniższych zasadach:
• Wsparcie techniczne świadczone za pośrednictwem portalu: Wykonawca jest zobowiązany do posiadania
i utrzymywania przez cały okres wsparcia technicznego platformy internetowej umożliwiającej zgłaszanie usterek
Systemu,
• SLA czas reakcji na zgłoszenia według statusu usterki (wyrażone w dniach roboczych od godziny 9.00 do 17.00)
wyniesie w przypadku usterki
o Krytyczna - reakcja w 1 dzień,
o Standardowa – reakcja w 1 dzień,
o Kosmetyczna – reakcja w 2 dni.
• W ciągu miesiąca możliwe do wykorzystania 4h zdalnych, telefonicznych konsultacji,
• Utrzymanie środowiska testowego na serwerach Wykonawcy,
• Możliwe do wykorzystania trzech konsultacji on-site (w miejscu instalacji Systemu – budynek „A” GPNT) w wymiarze
łącznym do 12h rocznie,
• Miesięcznie możliwe do wykorzystania 10h usług programistycznych, polegających na modyfikacji
oprogramowania, zgodnie z zapotrzebowaniem zgłaszanym przez Zamawiającego/użytkownika.
11. Model licencjonowania
Wykonawca zobowiązany jest udzielić Zamawiającemu licencji na moduły Systemu, o których mowa poniżej pozwalające
na bezterminowe korzystanie z pełnego zakresu funkcjonalności Systemu określonej w niniejszej specyfikacji przez
nieograniczoną liczbę użytkowników Zamawiającego oraz użytkowników, którym Zamawiający udzieli praw dostępu.
Udzielona licencja dotyczy wszystkich nieruchomości i budynków Zamawiającego.
Wykonawca w ramach realizacji zlecenia zobowiązany jest dostarczyć wszelkich innych licencji i nośników
oprogramowania, niezbędnych i wymaganych do poprawnej i zgodnej z przepisami pracy Systemu.
Dotyczy to w szczególności wymaganych bezterminowych i nieodpłatnych licencji dla:
• serwerowych systemów operacyjnych wraz z licencjami na dostęp przez nieograniczoną liczbę użytkowników
Zamawiającego i podmiotów zewnętrznych,
• systemów bazodanowych oraz systemów aplikacji wraz z licencjami na dostęp przez nieograniczoną liczbę
użytkowników Zamawiającego i podmiotów zewnętrznych (baza danych musi kolekcjonować zebrane dane
z Systemu i musi być tak skonfigurowana, aby zapewnić sprawny i szybki dostęp do wszystkich zebranych wcześniej
informacji przez okres minimum 24 miesięcy wstecz) wykorzystywanych przez komponenty oferowanego Systemu
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 4 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
12. Szczegółowe wymagania techniczne
12.1 Oprogramowanie dla podsystemu kontroli dostępu
• Wieloczynnikowe uwierzytelnianie - możliwość wykorzystania różnych czynników uwierzytelniających (PIN, karty
zbliżeniowe, biometria),
• System musi rejestrować wszystkie zdarzenia, które zostały zarejestrowane przez terminal, w tym wejście
pracownika do pomieszczenia oraz wyjście pracownika z pomieszczenia (w wypadku Kontroli Dostępu obustronnej),
• Oprogramowanie musi obsługiwać czytniki z wbudowanym kontrolerem.
• Kontroler powinien umożliwiać pracę zarówno autonomicznie jak i w połączeniu z serwerem.
• Komunikacja kontrolera z wykorzystaniem co najmniej protokołu TCP/IP.
• Możliwość integracji systemu z bazą danych, w tym co najmniej Microsoft SQL Server oraz Oracle.
• Automatyczna identyfikacja użytkownika - System przeprowadza identyfikację użytkownika bez dodatkowych akcji
wykonywanych przez użytkownika.
• Współpraca z różnymi rodzajami kart zbliżeniowych - system powinien posiadać możliwość współpracy z co najmniej
trzema rodzajami kart zbliżeniowych (mifare, unique, HID).
• Wbudowany interfejs w standardzie Wiegand lub o analogicznych możliwościach.
• Praca w trybie weryfikacji i identyfikacji.
• Bieżące monitorowanie systemu - operator systemu powinien mieć możliwość ciągłego podglądu zdarzeń
w systemie: rejestracji użytkowników, działań administracyjnych oraz stanów połączeń między elementami systemu.
• Możliwość eksportu danych do plików o formacie: MDB, XLS, CSV.
• Możliwość zarządzania terminalami z poziomu serwera co najmniej w następujących obszarach: dodawanie
użytkowników, usuwanie użytkowników, przypisywanie użytkowników do wybranych: grup, terminali, stref czasowych
• Możliwość zaprogramowania przedziału czasowego, w którym użytkownik jest uprawniony do korzystania z terminala
(dla każdego użytkownika z osobna),
• Możliwość ustawienia harmonogramu pracy systemu - programowanie stanu terminala (otwarty, zamknięty)
dla odpowiedniego przedziału czasu, dni roboczych i świątecznych,
• Rejestracja gości - system powinien umożliwiać wprowadzenie użytkownika typu „gość” (użytkownik z dostępem
czasowy i możliwością zapisania go na stałe jako rezydenta i wielokrotnego używania w przyszłości),
• Filtrowanie dziennika zdarzeń – system powinien posiadać możliwość filtrowania dzienników zdarzeń według
co najmniej następujących kryteriów: wg grup, wg terminala, wg użytkownika, wg rodzaju zdarzenia,
wg odwiedzających,
• Możliwość podglądu spóźnień,
• System musi mieć możliwość utworzenia planu sytuacyjnego na podstawie umieszczonych terminali do Kontroli
Dostępu.
12.2 Sieciowe kontrolery IP
Architektura rozwiązania oparta powinna być oparta o sieciowe kontrolery dostępu, które do transmisji wykorzystują
standard IP, szczegółowe parametry podane są w punkcie 13,
12.3 Zakres funkcjonalny systemu
Celem platformy jest wsparcie zarządzania Parkiem Naukowo-Technologicznym w poszczególnych obszarach
funkcjonalnych. Aplikacja powinna posiadać panel administratora, do którego dostęp mają uprawnieni pracownicy parku
oraz interfejsy dla poszczególnych grup użytkowników zewnętrznych – najemców i zewnętrznych partnerów. Dostęp
do Systemu powinien być możliwy z dowolnego miejsca i w dowolnym czasie przez Internet. Aplikacja powinna być
w całości dostępna w dwóch wersjach językowych: polskim oraz angielskim.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 5 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
Interfejs użytkownika powinien zostać zrealizowany w architekturze aplikacji internetowej (dostępnej dla użytkowników za
pośrednictwem przeglądarki internetowej). System powinien wspierać w pełni co najmniej następujące przeglądarki
internetowe:
• Mozilla Firefox 28 i wyższych
• Google Chrome 35 i wyższych
• Safari
a) Administracja i bezpieczeństwo
Użytkownicy i uprawnienia
Aplikacja ma umożliwiać definiowanie użytkowników z możliwością przypisywania ich do poszczególnych typów
firm (najemca, serwis zewn., itp.) oraz przypisywania ich do ról.
Aplikacja ma zawierać listę uprawnień (operacji w aplikacji podlegających kontroli dostępu). Uprawnienia
przypisuje się do ról użytkowników. Uprawnienia można także nadawać/odbierać poszczególnym użytkownikom
(ma to priorytet nad przypisywaniem uprawnień do ról).
Katalog firm
Katalog firm rejestruje podmioty zewnętrzne współpracujące z parkiem z podziałem na typy (Najemcy, Partnerzy,
Serwisy zewnętrzne, Administracja, firmy inkubowane, itp.). Każda firma ma mieć pewien zestaw atrybutów
dostępnych do wglądu i edycji przez wszystkie osoby mające uprawnienie do katalogu firm: nazwa NIP, uwagi,
logo. Dostęp do pozostałych atrybutów i zakładek ma być warunkowany posiadaniem uprawnienia do danego
typu firmy – tzw. zakładki chronione. W ramach informacji chronionych aplikacja ma umożliwiać przechowywanie
następujących informacji:
• Lista osób – pracowników danej firmy z możliwością tworzenia dla nich kont dostępowych do aplikacji,
• Lista dokumentów powiązanych z firmą umieszczanych w definiowalnych katalogach, z możliwością
wyszukiwania i ustawienia przypomnienia dla pliku,
• Informacje rozliczeniowe,
• Notatki – zakładka umożliwia tworzenie, edycję i usuwanie notatek tekstowych powiązanych z firmą.
Użytkownik może mieć dostęp albo tylko do swoich albo do wszystkich notatek (możliwość kontroli poprzez
matrycę uprawnień). Notatki można importować z pliku XLS zawierającego następujące kolumny: NIP firmy
oraz treść notatki. Każda notatka posiada datę oraz godzinę, użytkownika który dodał notatkę oraz tekstową
treść notatki,
• Zgłoszenia powiązane z daną firmą.
Zabezpieczenia serwera
• Serwer powinien być zabezpieczony przy pomocy szyfrowanych protokołów,
• Systemowa baza danych nie powinna być udostępniana na zewnątrz serwera,
• Dostęp do aplikacji z poziomu klienta powinien być możliwy tylko poprzez szyfrowane połączenie SSL.
Zabezpieczenia aplikacji
i. Hasła dostępu
• Hasła użytkowników są zabezpieczane metodą szyfrowania jednokierunkowego i nie są przechowywane
poza systemem autoryzacji.
• Hasło musi posiadać przynajmniej 8 znaków w tym co najmniej: jedna duża litera, jedna cyfra, jeden znak
specjalny (nie może składać się z cyfr). Hasło nie może także być podobne do loginu,
• Aplikacja bezwzględnie wymaga zmiany hasła co 30 dni i nie akceptuje żadnego z 10 wcześniej
wybieranych haseł tego samego użytkownika,
• Pięciokrotne podanie błędnego hasła skutkuje zablokowaniem konta.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 6 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
ii. Pozostałe zabezpieczenia
• Wszystkie dane przesyłane przez użytkownika powinny być filtrowane a złośliwy kod automatycznie
usuwany (ochrona przed atakami typu XSS),
• Ciasteczko sesji użytkownika powinno być chronione przed odczytem z poziomu Javascript (zabezpieczenie
przed atakami typu session hijacking),
• Maile HTML importowane przez aplikację powinny być automatycznie filtrowane pod kątem złośliwego kodu,
• Potencjalnym niespójnościom w bazie powinny zapobiegać transakcje bazodanowe stosowane przez
system,
• W każdym odwołaniu do bazy danych powinny być stosowane zmienne związane, które uniemożliwiają
ataki typu SQL injection.
b) Kontrola dostępu
i. Księga gości
Księga gości ma składać się z interfejsu recepcji oraz interfejsu samoobsługowego, które umożliwiają
rejestrację wejść i wyjść gości z budynku. Rejestracja gościa ma być połączona z wydrukiem etykiety
za pomocą zewnętrznej drukarki etykiet. Etykieta powinna zawierać kod kreskowy z unikatowym numerem
wizyty i dzięki integracji ze skanerem kodów kreskowych umożliwić odnotowanie rozpoczęcia i zakończenia
wizyty. Po wskazaniu opiekuna (hosta) rejestracja wejścia ma wygenerować także powiadomienie email/sms
do osoby oczekującej gościa.
ii. Ewidencja kluczy i kart dostępowych
Interfejs recepcji księgi gości umożliwia definiowanie wypożyczanych zasobów (kluczy, projektorów, kart
dostępowych, itp.). Po zdefiniowaniu zasobu powinna istnieć możliwość rejestracji ich wypożyczenia poprzez
wskazanie osoby wypożyczającej oraz planowanego terminu zwrotu. Aplikacja ma umożliwiać przeglądanie
logów wypożyczeń/ zwrotów kart wraz z obrazkami podpisów.
c) Obsługa zgłoszeń
Elementarną funkcją modułu jest monitorowanie działań zarządcy nieruchomości oraz obsługi technicznej
budynku poprzez zarządzanie przebiegiem zgłoszeń (zleceń), tworzonych przez osoby uprawnione
(administratora lub najemcę) przypisanych do danego obiektu (budynku).
i. Obiekty (budynki)
Karta obiektu ma zawierać wymienione dalej informacje podzielone na sekcje.
Pierwsza sekcja powinna zawierać informacje ogólne - nazwę, adres, przynależność do grupy obiektów,
numer rozliczeniowy, dodatkowe informacje (edytowalne pole).
W kolejnej sekcji zawarte mają być lokalizacje wg podziału logicznego obiektu. Dla każdej lokalizacji
możliwość przypisywania kodu i nazwy. Sekcja „Najemcy” to lista najemców przypisanych do obiektu.
Zakładka „Pliki” powinna umożliwiać załączanie dowolnych plików, także kilku jednocześnie, do zbioru
katalogów i podkatalogów. Załączniki mają być sortowane po dacie dodania, można również zamieszczać
przy nich opisy i słowa kluczowe ułatwiające późniejsze wyszukiwanie. Wybrane przez administratora katalogi
powinno dać się udostępnić najemcom.
Dwie ostatnie sekcje to „Zlecenia” oraz „Urządzenia”.
ii. Tworzenie zlecenia
Zakładanie zlecenia będzie polegać na określeniu następujących jego parametrów: właściciel - pracownik
najemcy, wykonawca za wykonanie zlecenia (system wyświetla domyślne opcje do wyboru), obiekt,
lokalizacja na obiekcie, urządzenie (określane przy pomocy wyszukiwarki), tytuł i opis zlecenia, status
gwarancji (posiada / nie posiada / nie dotyczy), priorytet, system (określony na podstawie rozbudowanego
drzewa systemów), rodzaj działania (wybór z listy), data wprowadzenia zlecenia do systemu, MPK, status
zlecenia (w zależności od etapu: Otwarte, Anulowane, Wykonane, Zamknięte). Z poziomu panelu
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 7 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
administratora powinno być możliwe określenie planowanego terminu wykonania zlecenia. Podczas
zakładania zlecenia powinna być możliwość wyboru urządzenia, którego zlecenie dotyczy. Wyszukiwarka
urządzeń ma być zintegrowana z modułem urządzeń dostępnym w obiektach.
W przypadku wyboru określonego w panelu administracyjnym systemu z drzewa systemów, aplikacja
powinna wyświetlić formatkę umożliwiającą wpisanie w ujednolicony sposób danych kart dostępowych,
a następnie dodać odpowiednią zakładkę z kartami dostępowymi na ekranie zlecenia.
iii. Działania w obrębie zlecenia
Przy dodawaniu zlecenia system ma automatycznie wybierać wykonawcę – osobę, która aktualnie obsługuje
konkretną grupę obiektów i posiada w systemie najwyższy priorytet. Wybrana osoba ma otrzymywać
powiadomienie o założeniu zlecenia pocztą elektroniczną. Wykonawca może następnie przekazać zlecenie
do wykonania innemu Administratorowi.
Poza osobą odpowiedzialną oraz właścicielem zlecenie mogą obserwować również inne osoby, związane
z jego przedmiotem. System powinien umożliwiać nadanie statusu obserwatora Administratorom, jak
i osobom po stronie Klienta danego zlecenia. Obserwatorami zlecenia przekazanego do wykonania serwisowi
zewnętrznemu mogą być wybrani pracownicy serwisu.
Poszczególne klasy zleceń powinny posiadać opcję rejestrowania danych dotyczących identyfikatorów
dostępu np. nadanie uprawnień dostępu, cofnięcie czy inne zmiany.
Struktura zlecenia ma pozwalać na prowadzenie dialogu w jego obrębie oraz wymianę plików poprzez
załączanie ich bezpośrednio do zlecenia. Zlecenia serwisowe oraz przeglądy techniczne powinny posiadać
osobny moduł zarządzający załącznikami, który ma pozwalać na dodawanie plików powyżej 50MB,
załączanie kilku dokumentów jednocześnie oraz umożliwiać monitorowanie postępu ładowania pliku. Dodanie
notatki do zlecenia winno być sygnalizowane wszystkim osobom dodanym do zlecenia, poza właścicielem,
poprzez automatyczne wysłanie e-maila przez system. System powinien umożliwiać modyfikowanie
widoczności notatek poprzez określanie ich statusu jako publicznych – widocznych dla wszystkich osób
dodanych do zlecenia, wewnętrznych – widocznych dla wszystkich pracowników Klienta, bądź prywatnych –
widocznych jedynie dla osoby dodającej notatkę. Notatki powinny być dodawane do zgłoszenia, tworząc
dialog w odpowiedniej zakładce. Dodatkowo przechowywane mają być informacje dotyczące zmian statusów
oraz innych parametrów zlecenia. System przechowuje informację o wszystkich osobach które otrzymały
powiadomienia e-mail związane z dodaniem notatki.
Zlecenia mają posiadać także opcję dodawania wizyt serwisantów z podaniem osoby realizującej zlecenie
serwisowe, datę oraz godzinę wizyty, przedmiot wizyty oraz ewentualną odpłatność (możliwość wpisania
kosztu realizacji). Po zakończeniu wizyty system ma umożliwiać dodanie pod zlecenie (podpięcie) protokołu.
Wizyty, podobnie jak zlecenia, mają mieć opcję filtrowania, przeglądania, konwertowania do formatu xls oraz
podpinania pod kalendarz. Płatne wizyty powinno się określać na podstawie stawek godzinowych najemcy
(dni pracujące, weekendy oraz święta). System automatycznie powinien pobierać informację o aktualnych
świętach, sugerując odpowiednio stawkę godzinową i przemnażać przez czas. Dodatkowo powinno możliwe
być dodanie kosztów dodatkowych nie wynikających z godzin, określenie zużytych materiałów oraz
uzupełnianie opisu wizyty. System powinien umożliwiać przypisywanie do jednej wizyty więcej niż jednego
serwisanta. Wizyty powinny być możliwe do określenia jako widoczne w kalendarzu, pojawiają się wtedy
w kalendarzach poszczególnych pracowników odbywających wizytę.
Każda osoba dodana do zlecenia i posiadająca odpowiednie uprawnienie powinna móc wykonać operację
zamknięcia, a także zmiany jego priorytetu. Zamknięcie zlecenia ma być operacją nieodwracalną.
Administrator powinien móc ponadto określić ręcznie datę i godzinę rozwiązania zlecenia. Wszelkie zmiany
w zleceniu powinny być indeksowane w zakładce „Historia”.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 8 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
Dla kosztów związanych z realizacją zlecenia ma powstać osobna sekcja „Koszty”, która zawiera dane
na temat podstawy kosztu wraz z podaniem kwoty w PLN. Suma kosztów widoczna ma być także w części
nagłówkowej zlecenia.
Dla nowych zleceń związanych z przedmiotem danego zlecenia system powinien posiadać opcję tworzenia
zleceń powiązanych. Dane nowego zlecenia częściowo pokrywają się ze zleceniem pierwotnym,
co nie wyklucza ich ewentualnej modyfikacji. Numer, status oraz tytuł zlecenia powiązanego ma być
uwidoczniony w osobnej sekcji w obrębie zlecenia podstawowego.
W oparciu o terminy wykonania zleceń system ma automatycznie oznaczać wpisy przeterminowane.
W przypadku, gdy określono pierwszeństwo dla danego urządzenia, system kieruje się w pierwszej kolejności
SLA. Jeżeli do zlecenia dodano kilka urządzeń, system określa SLA na najniższym poziomie dla wszystkich
urządzeń. W przypadku przekroczenia ram czasowych realizacji, wykonawca oraz koordynator obiektu mają
otrzymać pocztą elektroniczną powiadomienie. E-maile mają być wysyłane regularnie, co 24h.
System ma umożliwiać przeglądanie zleceń wg wybranych atrybutów oraz konwersję na arkusz kalkulacyjny,
co powinno pozwalać na tworzenie raportów zawierających podstawowe informacje takie jak lista zadań
i urządzeń. Raport można konwertować także na plik PDF. System powinien umożliwiać delegowanie
zlecenia do innej osoby lub do zewnętrznego serwisu, który również może posiadać dostęp do systemu
z ograniczonymi uprawnieniami.
iv. Powiadomienia email
• Wysyłanie powiadomień
Utworzenie zlecenia ma powodować wysłanie powiadomienia email do osób zaangażowanych
w zgłoszenie, z pominięciem osoby tworzącej zlecenie. Analogicznie powiadomienia email mają być
wysyłane także w momencie dodania notatki do osób, które mają dostęp do danej notatki.
• Otrzymywanie i analizowanie odpowiedzi
System ma umożliwiać przypisanie dedykowanych kont pocztowych do grupy obiektów. W przypadku
otrzymania maila od klienta system automatycznie powinien dokonać konwersji go na notatkę
do odpowiedniego zlecenia, jeżeli w temacie maila zostanie umieszczony numer zlecenia np. #5643 adres
e-mail nadawcy będzie taki sam jak adres zamieszczony w systemie i przyporządkowany do tego zlecenia.
Jeżeli nie ma możliwości przekształcenia e-maila, ponieważ nie spełnia on powyższych warunków, system
ma zaimportować maila na ekran listy, gdzie można będzie ręcznie przekształcić go w nowe zlecenie, dodać
jako notatkę do zlecenia istniejącego, oznaczyć jako spam lub odrzucić (informacja zwrotna do adresata).
Przekształcenie emaila w nowe zlecenie ma spowodować automatyczne uzupełnienie danych w zleceniu:
firmy, osoby, tematu oraz opisu i ewentualnie załączników. Pozostałe dane mają być wpisywane ręcznie
przez osobę wprowadzającą zlecenie. System powinien umożliwiać dodanie maila także do istniejącego
zlecenia poprzez wyszukanie odpowiedniego zlecenia (system podpowiada ostatnio zarejestrowane
zlecenia danego klienta/najemcy). Nadawca wiadomości oraz moderator skrzynki pocztowej mają otrzymać
wtedy potwierdzenie zarejestrowania e-maila bezpośrednio po wpłynięciu do klienta poczty e-mail.
Wiadomość ma zawierać treść oraz temat oryginalnej wiadomości, a po przetworzeniu przez moderatora
klienta poczty e-mail ma być jej nadany unikatowy numer. Przekształcane wiadomości e-mail mają być
przetwarzane na tekst oraz ewentualne załączniki, pełna wiadomość html oraz nagłówek wiadomości ma
być natomiast przechowywana w aplikacji, dostępna z poziomu widoku notatki zgłoszenia.
v. Komunikaty
Moduł komunikatów służy do ogólnych kontaktów z najemcami. Tą drogą będą przekazywane informacje
dotyczące tematów niezwiązanych z konkretnymi zleceniami (przeglądy instalacji, reorganizacja parkingu,
audyty itp.). Komunikat można przypisywać do konkretnych najemców, którzy po dodaniu komunikatu
otrzymują powiadomienie mailowe. Dla komunikatu powinno być możliwe określenie daty wygaśnięcia.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 9 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
d) Kalendarz
i. Funkcje podstawowe
• Kalendarz ma umożliwiać wyświetlanie w trybie: dni roboczych, 7-dniowym oraz w skali miesiąca,
• Moduł ma umożliwiać tworzenie alokacji z opcjonalnym przypisywaniem do poszczególnych zleceń,
przeglądów, projektów, czy wydarzeń alokacji czasowych, a także możliwość raportowania czasu pracy
wg wielu kryteriów: projekt, najemca, osoba, itp.
• Alokacje mają mieć możliwość przenoszenia w obrębie widoku kalendarza metodą „przeciągnij i upuść”.,
• Bezpośrednio poprzez kalendarz ma być możliwość dokonywania rezerwacji (alokacji) na zasoby
np. samochody, sale konferencyjne,
• Użytkownicy o osobnych uprawnieniach mają mieć możliwość podglądu kalendarza innych osób.
ii. Synchronizacja i zaproszenia na spotkania
• Kalendarz ma mieć możliwość synchronizacji z innymi klientami (smartfony Android, iOS klient pocztowy
Thunderbird, Mac Mail) za pomocą protokołu CalDAV – synchronizacja kalendarza danego użytkownika
w systemie,
• Przy włączonej synchronizacji j.w. ma istnieć możliwość wysyłki zaproszeń na spotkania z poziomu klienta
aplikacji (telefon, program pocztowy). Informacja o liście zaproszonych osób i ich statusie (Oczekujący,
Potwierdzony, Odrzucony) ma być widoczna po stronie aplikacji (bez możliwości zmiany).
e) Moduł kontroli wykonania usług zarządzania oraz obsługi technicznej nieruchomości
Moduł ma umożliwiać Zamawiającemu kontrolę działań zarządcy nieruchomości i firmy facility management
w obszarze monitorowania stanu technicznego budynku. Działania te powinny być realizowane na podstawie
schematu przeglądów technicznych oraz stanu urządzeń (instalacji).
i. Urządzenia
Podstawowe parametry
Do każdego urządzenia mają być przyporządkowane określone atrybuty: obiekt, lokalizacja urządzenia
w obiekcie, jego typ, system, kod, nazwa, numeracja, MPK, numer UDT wraz z datą wygaśnięcia (system
wysyła powiadomienia do odpowiedniej osoby przed datą wygaśnięcia numeru UDT) data wygaśnięcia
gwarancji, a także status eksploatacji – określenie czy urządzenie nadaje się warunkowo bądź bezwarunkowo
do eksploatacji czy też nie, określenie fizycznego statusu urządzenia – czy jest w ruchu, czy też nie,
czy zostało sprzedane bądź zezłomowane. Dodatkowym atrybutem urządzenia powinien być priorytet SLA
(wybór z listy priorytetów z określoną ilością godzin na realizację zlecenia dotyczącego urządzenia
z możliwością ręcznego wpisywania ilości godzin w interfejsie dostępnym przy danych zleceniach
serwisowych).
Panel urządzenia
Panel urządzenia powinien zawierać w/w podstawowe parametry urządzenia. Na poziomie panelu urządzenia
administrator powinien móc uzupełniać także jego podzespoły. Podzespoły mają posiadać określone
parametry, w tym co najmniej: kod, nazwa, numer seryjny, nr inwentarzowy, numer UDT, data UDT, data
wygaśnięcia gwarancji, status (analogicznie jak dla urządzenia). Materiały eksploatacyjne przeznaczone
dla konkretnego urządzenia powinny być dodawane jako definicje pozycji magazynowych ściśle zintegrowane
z modułem magazynowym. Analogicznie jak do zleceń, do panelu urządzenia możliwe powinno być
dodawanie plików.
Spis urządzeń
Spis urządzeń powinien umożliwiać ich filtrowanie m.in. po systemach, kodzie, nazwie, numerze seryjnym
czy też słowach kluczowych. Podzespoły mają być możliwe do wyszukiwania także w liście urządzeń
pod konkretnym obiektem.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 10 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
ii. Schematy przeglądów technicznych
Moduł ma umożliwiać zarządzanie przeglądami technicznymi na podstawie schematu przeglądów
technicznych.
Parametry
Przeglądy techniczne powinny być opisywane przez podanie nazwy w języku polskim i angielskim, określeniu
grupy nieruchomości, jednego bądź większej ilości obiektów oraz opcjonalnie lokalizacji w budynkach, wybór
systemu oraz podsystemu z definiowalnej listy, wspólnej dla całej aplikacji oraz różnych typów zleceń.
Następnie użytkownik powinien określić właściciela, którym może być osoba spośród Administratorów oraz
Wykonawcę, którym może być osoba spośród Administratorów lub wyznaczony pracownik Serwisu
Zewnętrznego. Na podstawie płaskiej listy słownikowej, dostępnej dla Administratora, system powinien
umożliwiać klasyfikację (np. obchody / przegląd). Moduł powinien umożliwiać także określenie oczekiwanego
kosztu całkowitego oraz informacji czy koszt jest płatny przez najemcę oraz czasu trwania przeglądu
w dniach.
Generowanie przeglądów
System powinien generować przeglądy na podstawie określenia schematu cyklu – daty startu, daty
zakończenia, częstotliwości (liczby) oraz interwału (dzień/dzień roboczy/ tydzień/ miesiąc/ kwartał/
półrocze/rok). Po zapisaniu schematu przeglądów, po uruchomieniu dodatkowej funkcji, automatycznie,
powinny zostać utworzone przeglądy wg daty wynikającej z cyklu. Domyślnie przeglądy przypadające
na sobotę bądź niedzielę powinny być przesuwane wstecz na piątek poprzedzający tę datę.
Pliki
Do każdego schematu przeglądów powinno być możliwe dodawanie plików, które wyświetlane są
we wszystkich wygenerowanych zleceniach.
Zadania
Do schematu powinno być możliwe dodawanie dowolnej ilości zadań do wykonania w ramach przeglądu.
Ich kolejność powinna być możliwa do zmiany metodą „przeciągnij i upuść”. Zadania powinny być możliwe
do zaimportowania do systemu z arkusza XLS. Zadania winny być automatycznie kopiowane ze schematu
do wygenerowanych na jego podstawie przeglądów. Ewentualna zmiana zadań w schemacie powinna
skutkować automatyczną aktualizacją w jeszcze nie zamkniętych przeglądach. Zadania powinno dać się
pogrupować i zapisać na osobnej liście jako przykładowe objęte określanymi przez użytkownika etykietami.
Urządzenia
Administrator powinien móc dodawać do schematu dowolną ilość urządzeń serwisowanych w trakcie
przeglądu. Urządzenia powinny być automatycznie kopiowane ze schematu do wygenerowanych na jego
podstawie przeglądów, a ewentualna zmiana urządzeń w schemacie skutkuje automatyczną aktualizacją
w jeszcze nie zamkniętych przeglądach.
Duplikowanie
System powinien umożliwiać duplikowanie schematu przeglądu.
Przedłużanie
System powinien umożliwiać przedłużenie schematu przeglądu poprzez zmianę daty końca cyklu. Powoduje
to wygenerowanie nowych przeglądów w ramach tego samego schematu.
iii. Wygenerowane przeglądy techniczne
Przeglądy techniczne mają być w systemie osobnym rodzajem zlecenia tworzonym na podstawie schematu
przeglądu.
Parametry
Przegląd powinien być identyfikowany co najmniej przez następujące parametry: numer, tytuł, przypisanie
do schematu przeglądu oraz pobierane z niego dynamicznie parametrów powiązanych: grupy obiektów,
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 11 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
obiekt/obiekty, system z drzewa systemów i podsystemów. Dalsze opcjonalne parametry to data przeglądu,
edytowalny czas trwania w dniach, właściciel, wykonawca (analogiczne jak w zleceniach serwisowych), osoby
zaangażowane (analogiczne jak w zleceniach serwisowych), notatki wraz z plikami (analogiczne jak
w zleceniach serwisowych), automatycznie tworzona historia (analogiczne jak w zleceniach serwisowych),
procent zaawansowania (analogiczne jak w zleceniach serwisowych).
Statusy
W zależności od postępu przeglądu, przegląd powinien posiadać jeden z co najmniej następujących statusów:
Otwarty/Wykonany/Zamknięty. Możliwość oznaczenia przeglądu jako zamkniętego powinna być objęta
osobnym uprawnieniem. Podczas zamykania przeglądu powinna się pojawić opcja dodania uwag poprzez
określenie tematu, systemu oraz opisu. W konsekwencji tworzone powinno być zlecenie serwisowe połączone
z przeglądem.
Zadania
Zadania w przeglądzie powinny być pobierane ze schematu, z możliwością edycji. Zadanie w ramach
przeglądu można zamknąć.
Koszty
Do przeglądu powinno być możliwe dodawanie kosztów poprzez określenie nazwy oraz wartości. Jeśli
odnaleziono koszt o tej samej nazwie we wcześniejszych przeglądach, aplikacja powinna podpowiadać
ostatnią wartość kosztu.
Magazyn
W ramach wygenerowanego przeglądu system powinien umożliwiać rozchodowanie materiałów z magazynów
określonych w ramach danego obiektu. Dodanie poszczególnych materiałów powinny powodować ich
wydanie z magazynu na rzecz danego zlecenia powiązanego z najemcą. System ma automatycznie tworzyć
niezbędne dokumenty magazynowe takie jak dokument PZ.
Raport przeglądu oraz przydzielanie osób odpowiedzialnych
Dla przeglądu powinno być możliwe wydrukowanie raportu w formie pliku PDF.
Raport z przeglądu powinien zawierać wybrane informacje nagłówkowe, listę urządzeń, zadań do wykonania
z możliwością oznaczania ich jako wykonanych, listę plików (załączników) oraz miejsce na podpisy. System
powinien umożliwiać wydrukowanie gotowego raportu w formie PDF, co powinno być jednoznaczne
z odznaczeniem na liście odpowiednią ikoną przeglądów, dla których raport został już wydrukowany.
Jeśli do notatek przeglądu zostały załączone pliki, aplikacja powinna przypominać o konieczności ich
wydrukowania. System powinien także umożliwiać wydrukowanie zbiorcze dla zaznaczonych przeglądów,
bezpośrednio z listy przeglądów. System ma umożliwiać również zbiorczą zmianę osób odpowiedzialnych
w grupie uprzednio przefiltrowanych przeglądów.
iv. Raport długookresowy
Aplikacja ma umożliwiać wygenerowanie podsumowania przeglądów technicznych dla obiektów w ramach
wybranej grupy. W podsumowaniu w podziale na poszczególne systemy widoczne mają być przeglądy,
a w ich ramach zadania. Raport ma przedstawiać w formie graficznej długookresowy plan przeglądów
dla danego obiektu lub grupy obiektów w podziale na systemy i kolejne tygodnie. Czas trwania danego
przeglądu powinien być oznaczony różnymi kolorami, w zależności od jego statusu. Przykładowo na zielono
oznaczone mają być przeglądy otwarte, których termin zakończenia jeszcze nie minął, na czerwono –
przeglądy otwarte, których termin zakończenia minął, na szaro – przeglądy zamknięte. Podsumowanie
powinno być możliwe do filtrowania według kryterium grupy obiektów lub systemu przeglądu, a także powinna
istnieć możliwość eksportu do pliku XLS, który zawiera niezmienioną formę graficzną raportu (obejmuje
komórki, przeglądy, koszty oraz legendę).
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 12 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
v. Liczniki
Aplikacja powinna umożliwiać dodawanie dowolnej ilości liczników, a dla każdego licznika określanie
co najmniej następujących atrybutów: typ (gaz/prąd/woda), jednostka (kWh, m3), najemca (dla liczników
przypisanych do konkretnego najemcy) albo obiekt (dla liczników przypisanych do obiektu). System powinien
udostępniać możliwość rejestracji stanów liczników poprzez określenie daty pomiaru (należy wybrać ją
z kalendarza), licznik (wybór z listy), stan licznika.
Aplikacja powinna umożliwiać import stanów liczników z systemu BMS (import pliku w formacie XLS).
f) Integracja z programem finansowo-księgowym
• System ma umożliwiać integrację z systemem finansowo-księgowym Symfonia Handel w zakresie pobierania
informacji o fakturach wystawianych dla najemców.
• Program Symfonia Handel przy każdorazowym wystawieniu dokumentu (faktury) będzie generował plik PDF
z pełnym obrazem faktury oraz plik w formacie XML z pełnym opisem faktury. Po wygenerowaniu pliki będą
automatycznie przesyłane na wskazany przez Wykonawcę serwer FTP.
• Aplikacja cyklicznie sprawdzi czy na serwerze FTP pojawiły się nowe (niezaimportowane do tej pory
dokumenty).
• Jeśli istnieje nowy dokument system powinien pobrać plik PDF z obrazem faktury oraz przetworzyć plik XML
z opisem. W procesie przetwarzania system ma przypisać fakturę do najemcy na podstawie kodu kontrahenta
z programu Symfonia Handel.
• Kod kontrahenta z programu Symfonia Handel powinien być przechowywany w aplikacji jako osobny atrybut
firmy
• Po przypisaniu faktury do najemcy system ma pobierać informacje o fakturze z pliku XML (kwota brutto,
kwota netto, data wystawienia, sposób oraz termin płatności, a także numer dokumentu) i udostępnić te dane
odpowiedniemu najemcy. Z ekranu listy zaimportowanych faktur system ma umożliwiać również pobranie
pełnego obrazu faktury w formacie PDF.
• W sytuacji, jeśli ze względu na brak przypisania kontrahenta do najemcy lub błąd w pliku XML przetworzenie
faktury jest niemożliwe, system ma powiadomić o tym wskazanego w systemie użytkownika wysyłając
do niego informacje o pliku, którego przetworzenie nie było możliwe.
Przygotowanie programu Symfonia Handel do integracji w w/w zakresie leży po stronie Zamawiającego.
g) Wersja mobilna
Elementem systemu powinna być dedykowana aplikacja mobilna, zbudowana z myślą o ergonomicznym
użytkowaniu funkcji systemu na urządzeniach typu tablet oraz smartfon, opartych o system operacyjny Android
lub iOS. Aplikacja mobilna powinna udostępniać co najmniej następujące funkcje:
i. Obsługa zgłoszeń Helpdesk
• Tworzenie nowego zgłoszenia,
• Listowanie i filtrowanie zgłoszeń,
• Przeglądanie szczegółów zgłoszenia (notatki, pliki, wizyty, urządzenia),
• Aktualizacja zgłoszenia – tworzenie notatek, dodawanie zdjęć wykonanych aparatem urządzenia,
delegowanie, dodawanie obserwatorów, rejestrowanie wizyt, zmiana statusu.
ii. Obsługa przeglądów technicznych
• Listowanie i filtrowanie przeglądów,
• Przeglądanie szczegółów przeglądów (notatki, urządzenia, checklista),
• Aktualizacja przeglądu: dodawanie notatek, dodawanie zdjęć wykonanych aparatem urządzenia,
delegowanie, dodawanie obserwatorów, rejestrowanie wizyt, uzupełnianie checklisty zmiana statusu
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 13 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
iii. Obiekty
• Przeglądanie podstawowych informacji o obiektach,
iv. Firmy
• Przeglądanie i filtrowanie listy firm,
• Przeglądanie szczegółów firmy,
• Przeglądanie listy pracowników powiązanych z daną firmą,
• Przeglądanie dokumentów podpiętych pod kartę firmy.
h) Szkolenia i eventy
i. Wstęp
Moduł wydarzeń (szkoleń i eventów) będzie służył do zarządzania konferencjami, szkoleniami i innymi
wydarzeniami marketingowymi. Każde wydarzenie powinno posiadać funkcje podobne do zleceń
projektowych czy zleceń serwisowych, tj. tytuł, opis, zlecający, wykonawca, możliwość dodawania osób
zaangażowanych, notatek wraz z plikami i ich obserwatorów.
Wydarzenie może mieć status: Otwarte, Zakończone, bądź Anulowane.
ii. Czas i miejsce wydarzeń
Dla każdego miejsca administrator powinien móc określać miejscowość, zakres dat oraz opcjonalnie dokładną
lokalizację i opis. Dla konferencji/szkolenia można dodawać dowolną liczbę lokalizacji.
iii. Budżetowanie
Moduł wydarzeń powinien umożliwiać tworzenie listy kosztów, której pozycje zawierają numer dokumentu,
opis kosztu, kwotę, typ (wybierany z listy) oraz procent finansowania z przychodów. Do wydarzenia można
także analogicznie dodać listę przychodów.
iv. Uczestnicy wydarzenia
• Do danego wydarzenia powinno być możliwe dodawanie dowolnej liczby osób spośród ogólnej bazy
kontaktów, wg kryterium określonej grupy, bądź indywidualnie przy pomocy wyszukiwarki kontaktów,
• Każdy uczestnik wydarzenia powinien posiadać jeden z następujących statusów uczestnictwa:
Oczekujący, Potwierdzony, Obecny (Zakończony) oraz Brak obecności. Domyślnie każdy uczestnik ma
status „Oczekujący” a status można ręcznie zmienić na dowolnie inny,
• Lista uczestników wydarzeń powinna posiadać opcje przeszukiwania wg różnych kryteriów: nazwy
wydarzenia, statusu uczestnika, imienia, nazwiska, daty wydarzenia. W razie konieczności zmiany
statusu więcej niż jednego uczestnika naraz, można zaznaczyć na liście danych uczestników, których
ma objąć zmiana statusu,
• Rejestracja na szkolenie typu publicznego powinna być możliwa także za pośrednictwem zewnętrznej
strony internetowej (np. strony firmowej) za pomocą iframe z możliwością przekazania odnośnika
do własnego arkusza stylów. Rejestracja wymaga wtedy podania imienia, nazwiska i adresu e-mail oraz
wypełnienia ankiety, jeśli istnieje ankieta przypisana do danego wydarzenia. W przypadku, gdy adres
e-mail osoby rejestrującej pokrywa się z adresem jakiejś osoby w bazie systemu – osoba powinna być
podłączana pod to konto, w przeciwnym razie tworzone jest nowe konto w systemie. Rejestracja
powoduje wysłanie powiadomienia e-mail do osoby będącej właścicielem wydarzenia.
v. Integracja z e-mail
Moduł wydarzeń ma umożliwiać wysyłanie mailingu. Do odbiorców automatycznie powinni być dodawani
uczestnicy wydarzenia. Dzięki tej funkcji z poziomu wydarzenia powinno być możliwe wysyłanie
np. zaproszenia.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 14 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
vi. Ankietowanie
Do wydarzenia powinno być możliwe dodawanie powiązanej z nim ankiety pobranej z modułu ankiet.
Na ekranie wydarzenia powinny się pojawiać linki prowadzące bezpośrednio do przypisanych ankiet.
Załadowanie się do strony z ankietą nie powinno wymagać posiadania loginu i hasła do aplikacji. System
ma jednoznacznie identyfikować osobę wypełniającą ankietę w przypadku, w którym ankieta nie posiada
atrybutu „anonimowa”.
i) Ankiety
i. Redagowanie ankiet
Redagowanie ankiety ma polegać na określeniu jej tytułu oraz zdefiniowaniu listy pytań przypisywanych
do sekcji. Każde pytanie oprócz treści może mieć jedną z kilku możliwych form odpowiedzi: pole tekstowe,
wybór jednej opcji z listy albo wybór kilku opcji z listy. Ankieta może mieć status otwarta, bądź zamknięta oraz
ewentualnie datę wygaśnięcia. Ankieta może być anonimowa.
ii. Integracja z modułem mailingowym
W celu wysłania zaproszenia do uzupełnienia ankiety z poziomu modułu ankiet powinno być możliwe
przejście do modułu odpowiedzialnego za wysyłanie mailingu. Po wybraniu odbiorców (na podstawie wyników
wyszukiwania lub dla całej grupy) przy pomocy znacznika powinno być możliwe dodanie linku do ankiety. Link
może być anonimowy tzn. nie zawierać informacji o ankietowanym.
iii. Analiza wyników ankiety
Odpowiedzi udzielone przez ankietowanych powinny być możliwe do przeglądania w aplikacji bądź eksportu
do formatu XLS.
j) Moduł mailingowy
Moduł ma umożliwiać wysyłkę maili do osób zarejestrowanych w bazie. Wiadomość może pochodzić z modułu
wydarzeń lub modułu ankiet, może także zostać utworzona niezależnie od zleceń.
i. Redagowanie e-maili
Przy tworzeniu e-maili określa się co najmniej następujące atrybuty: tytuł wewnętrzny, temat, nadawcę
(ze słownika). Do wiadomości powinno być możliwe wyszukane osoby lub z grupy (domyślnie tylko spośród
osób z uaktywnionym statusem „odbiorca mailingu”). Obszar edycji powinien być podzielony na wstęp,
wysyłany w treści maila i rozwinięcie, widoczne już na poziomie aplikacji po kliknięciu w link „czytaj więcej”.
ii. Automatyczne tagi
Do treści wiadomości powinno być możliwe dodawanie znaczników automatycznie przetwarzanych
w momencie wysyłki mailingu. Zawsze mają być obsługiwane: imię i nazwisko odbiorcy oraz nazwa firmy.
Dla wiadomości pochodzących z wydarzeń powinno być możliwe używanie dodatkowo znaczników z linkiem,
miejscem i adresem wydarzenia. Dla wiadomości pochodzących z ankiet można dodatkowo używać
znacznika z linkiem do ankiety.
iii. Wiadomości wysłane
Aplikacja ma udostępniać listę wysłanych wiadomości, którą można filtrować. Po wejściu w zachowaną
wiadomość powinien być możliwy podgląd listy adresatów. Powinna również istnieć opcja tworzenia nowej
wiadomości na podstawie wcześniej zachowanej – system podpowiada wtedy treść.
iv. Analiza poczytności
E-mail ma zawierać obrazek o rozmiarze 1x1 piksela. Jeśli odbiorca otworzy wiadomość w programie
pocztowym, który nie ma zablokowanego pobierania obrazków, to system ma wykryć otwarcie wiadomości.
Ponadto system ma logować kliknięcia w link prowadzący do rozwinięcia wiadomości.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 15 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
k) Projekty
i. Słownik projektów
Aplikacja ma pozwalać na rejestrowanie nieograniczonej ilości projektów, które można dzielić na podprojekty.
Do projektów powinno być możliwe dodawanie kategorii zleceń oraz nieograniczoną liczbę firm/osób
zaangażowanych z bazy systemu. Osoby zaangażowane mają otrzymywać powiadomienia o zmianach
w obrębie zleceń przyporządkowanych do danego projektu.
ii. Kategorie zleceń i macierz wykonawców
W aplikacji powinno być możliwe definiowanie drzewa kategorii zleceń, np. Doradztwo -> Doradztwo prawne.
Do kategorii zleceń powinno być możliwe dodawanie wykonawców (osób odpowiedzialnych) wraz
z określeniem priorytetu (dalsze priorytety oznaczają zastępców osób o wyższych priorytetach).
iii. Zlecenia projektowe
System ma umożliwiać tworzenie i zarządzanie zleceniami projektowymi.
Podstawowe atrybuty
Przy tworzeniu zlecenia powinno się określać jego parametry tj. projekt (użytkownik administracyjny widzi
wszystkie projekty, użytkownik przypisany do firmy, np. najemcy, widzi jeden projekt ogólny oraz projekty
przypisane bezpośrednio do jego firmy), kategoria w ramach projektu, tytuł, opis oraz opcjonalne załączniki.
Na podstawie wybranej kategorii system automatycznie powinien wyznaczyć wykonawcę jako osobę obecną
o najwyższym priorytecie w strukturze osób odpowiedzialnych. Wykonawcę można w razie potrzeby zmienić
na inną osobę z listy.Po zapisaniu zlecenia automatycznie nadawany jest mu numer i wysyłane jest
powiadomienie e-mail.System powinien umożliwiać zmianę wykonawcy na dowolnym etapie przed
zamknięciem zlecenia (delegowanie zlecenia).
Notatki
Do zlecenia powinno być możliwe dodawanie dowolnej liczby notatek. Notatka ma być uaktualnieniem
zlecenia. Notatki mają mieć różne statusy widoczności. Notatki publiczne powinny być widoczne
dla wszystkich użytkowników mających dostęp do zlecenia, w tym osób z firm zewnętrznych. Notatki
wewnętrzne mają być widoczne dla wszystkich pracowników firmy. Natomiast treść notatek prywatnych widzi
jedynie ich autor. Podczas dodawania notatki powinna się pojawić opcja określenia kierunku, czyli
sprecyzowania kto powinien w dalszej kolejności podjąć aktywność w obrębie zlecenia (zgłaszający/
wykonawca). Powiadomienie o dodaniu notatki ma być wysyłane w formie maila, z numerem zlecenia
w temacie, do wszystkich osób do niego dodanych. Odpowiedź na wiadomość jest przesyłana do klienta
poczty e-mail, skąd trafia, wraz z załącznikami, do zlecenia w formie notatki.
Dodawanie plików i kolejnych wersji dokumentów
Do notatki powinno być możliwe dodawanie nieograniczonej liczby plików w formie załączników. Dodane pliki
mają być widoczne pod notatką oraz w formie listy, w odrębnej zakładce. W momencie wysyłania
powiadomienia e-mail o dodaniu notatki, pliki automatycznie załączają się do maila.
Do zlecenia powinno być możliwe dodawanie kolejnych wersji tych samych plików. System ma śledzić
numery wersji oraz rejestrować datę i autora zmiany oraz ewentualny komentarz. Dla plików wersjonowanych
aplikacja ma ostrzegać o ewentualnej próbie pobrania nieaktualnej wersji pliku. Dodatkowo system ma
udostępniać linki do plików nie wymagających zalogowania się oraz pobranie wszystkich plików z danego
zlecenia w formie archiwum skompresowanego. Wszystkie pliki o wielkości powyżej 5MB powinny być
dla użytkowników w formie linku umożliwiającego pobranie bezpośrednio z serwera.
Osoby zaangażowane
Do zlecenia powinno być możliwe dodawanie osób zaangażowanych. Obserwator zlecenia ma być
powiadamiany mailowo o wszystkich nowych widocznych dla danej osoby notatkach (poza tymi, które sam
dodał).
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 16 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
Alokacje
Do zlecenia powinno być możliwe dodawanie alokacji, które są zamieszczane w kalendarzu. Kalendarz ma
być widoczny jako jedna z zakładek zlecenia. Kalendarz powinien być przedstawiony w formie graficznej
z możliwością płynnego przełączania się pomiędzy widokiem tygodnia roboczego, pełnego tygodnia oraz
miesiąca. Każda z alokacji powinna być możliwa do przesunięcia przy użyciu mechanizmów przeciągnij
i upuść.
Statusy
Stopień zaawansowania prac nad zleceniami obrazują statusy. W momencie zakładania zlecenia status ma
zostać domyślnie określony jako „Otwarte”. W momencie realizacji wykonawca powinien móc zmienić status
na „Rozwiązane” i tym samym przekazać do sprawdzenia i zamknięcia przez właściciela, który
po sprawdzeniu może ustawić status na „Zamknięte”. Ostatnią z opcji, które ma udostępniać system, jest
nadanie statusu „Anulowane”, określanego dla zleceń niezrealizowanych.
Zmiany statusu powinny być rejestrowane poprzez zapisywanie osoby dokonującej zmiany, aktualnej daty
i ewentualnie treści notatki odpowiadającej zmianie.
Zlecenia powiązane
Z poziomu zlecenia powinno by możliwe dodawanie powiązania do innego zlecenia lub stworzenie nowego
zlecenia powiązanego. W karcie danego zlecenia powinny być widoczne inne zlecenia z nim powiązane wraz
z ich numerami, tytułami, statusami i linkami do ich kart.
Lista zleceń
System powinien umożliwiać filtrowanie listy zleceń wg co najmniej następujących kryteriów:, wykonawca,
projekt, partner, czy daty oddania. Często używane zestawienia kryteriów wyszukiwania powinny być możliwe
do zachowania w formie filtrów. Domyślnie każdy pracownik powinien widzieć zlecenia, w które jest
zaangażowany (jest osobą zgłaszającą, odpowiedzialną albo obserwatorem). Do pełnej listy zleceń mają
dostęp jedynie osoby posiadające do tego szczególne uprawnienie.
System powinien umożliwiać eksport zleceń do XLS (kolumny takie same jak na liście zgłoszeń).
l) Rekrutacja firm
Rekrutacja firm powinna być obsługiwana za pośrednictwem osobnego typu zgłoszeń. Każde zgłoszenie ma
określać przypisane do kategorii rekrutacji, z której wynika ankieta rekrutacyjna (z modułu ankiet). Dzięki temu
powinna być możliwa zbiorcza analiza wybranych danych z wniosków – eksport wybranych wyników ankiety
do XLS. Wypełnienie wniosku rekrutacyjnego powinno być zainicjowane ze zewnętrznej strony www (np. strony
firmowej), poprzez iframe z możliwością przekazania odnośnika do własnego arkusza stylów. Rejestracja ma
wymagać wtedy podania imienia, nazwiska, adresu e-mail, kategorii rekrutacji oraz wypełnienia ankiety, jeśli
istnieje ankieta przypisana do danej kategorii. W przypadku, gdy adres e-mail osoby wypełniającej formularz
pokrywa się z adresem jakiejś osoby w bazie systemu – osoba powinna być podłączana pod to konto,
w przeciwnym razie system ma utworzyć nowe konto w systemie. Rejestracja ma powodować wysłanie
powiadomienia e-mail do osoby przypisanej jako odpowiedzialnej za dane kategorie zgłoszeń.
Po utworzeniu wniosku rekrutacyjnego ma istnieć możliwość zmiany danych ankiety, dodawania załączników,
zmiany statusu wniosku rekrutacyjnego.
m) Rekrutacja pracowników
Najemca w osobnej zakładce ma mieć możliwość zgłoszenia rozpoczęcia procesu rekrutacyjnego, uzupełniając
nazwę stanowiska oraz opis wymagań. Niezakończone ogłoszenia rekrutacyjne powinny być zaprezentowane
w formie listy na zewnętrznej stronie internetowej poprzez iframe z możliwością przekazania odnośnika
do własnego arkusza stylów.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 17 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
n) Zgłoszenia rezerwacyjne
Aplikacja ma umożliwiać tworzenie zgłoszeń dot. rezerwacji zasobów (np. sal konferencyjnych, pokoi hotelowych,
itp.). Aplikacja powinna bazować w tym zakresie na liście zasobów, dla których ustawiono flagę „Dostępne
do rezerwacji”.
i. Tworzenie zgłoszenia
Zgłoszenie powinno być możliwe do utworzenia w imieniu osoby rezerwującej (np. najemcy) lub bezpośrednio
przez osobę – wymagane utworzenie konta w aplikacji. System powinien wymuszać wybór zasobu oraz
określenie terminu rezerwacji od-do. Wprowadzanie danych ma ułatwiać podgląd kalendarza zasobów.
ii. Zmiana statusów
Zgłoszenie-rezerwacyjne po utworzeniu ma posiadać status „Otwarte”. Następnie administrator ma mieć
możliwość zmiany statusu tego zgłoszenia na „Potwierdzone”, co powinno spowodować blokadę możliwości
zmiany terminu. Zmiana statusu może być dokonana w formie notatki publicznej, co powinno spowodować
wysłanie powiadomienia email do osoby rezerwującej.
iii. Ankietowanie
System ma umożliwiać podpięcie ankiety z modułu ankiet, która będzie wysyłana (w formie maila
z unikatowym linkiem) do osoby zgłaszającej po zamknięciu każdego zgłoszenia rezerwacyjnego.
Po kliknięciu w link użytkownik bez logowania się do systemu powinien zobaczyć ankietę i móc ją uzupełnić.
o) Raportowanie
i. Dashboard
System powinien być wyposażony w zindywidualizowany dla każdego użytkownika wewnętrznego ekran
startowy systemu, do którego można dodawać widgety, czyli dedykowane raporty przedstawiające wybrane
informacje. Użytkownik powinien móc samodzielnie ustalać rodzaj i położenie widgetów (funkcja przeciągnij
i upuść) oraz ich cechy (parametry takie jak np. okres).
Aplikacja powinna udostępniać co najmniej następującą listę widgetów:
• Zapisane filtry wyszukiwania (z listy zleceń),
• Ilość otwartych zleceń,
• Ilość zleceń w ostatnich dniach,
• Ostatnie zlecenia,
• Przeglądy – lista przeglądów najbliższych, przeterminowanych i w trakcie,
• Zlecenia wykonane poniżej i powyżej SLA,
• Najbliższe alokacje użytkownika,
• Ilość zleceń wg najemcy,
• Ilość zleceń wg klasyfikacji,
• Lista komunikatów,
• Sumaryczna pracochłonność w podziale na firmy,
• Sumaryczna pracochłonność w podziale na projekty.
ii. Raporty podręczne
System powinien być wyposażony w moduł odpowiedzialny za kreowanie i zarządzanie szybkimi raportami
tworzonymi na postawie wszystkich danych z systemu. Raporty powinny być możliwe do przygotowania
samodzielnie przez Zamawiającego poprzez konstrukcję odpowiedniego zapytania SQL. System powinien
udostępniać możliwość sortowania wyników i ich eksport do formatu XLS. Odpowiednio konstruując zapytanie
SQL, administrator powinien mieć możliwość dodania do raportu filtrów wejściowych w postaci
pól tekstowych.
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 18 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
13. Specyfikacje asortymentowe
Lp.
1.
2.
3.
Opis wymaganego wyposażenia / funkcji Wymagane parametry techniczne
Zasilanie prądem: 24 V AC,
Max. pobór mocy: 80 VA,
Temp. składowania: od -40°C do +50°C
Temp. pracy: od -20°C do +50°C
Minimalna szerokość przejścia: 518 mm
Materiał: stal nierdzewna
Możliwość konfiguracji przejść,
Dwa komplety bramek typu tripod
Pełna programowalność sygnałów sterujących,
Mechanizm dwuramienny z funkcją ewakuacji,
Pokrywa ograniczająca dostęp osób postronnych do mechanizmu
bramki – zamykana na kluczyk,
Sygnalizacja alarmowa informująca o próbie wejścia przez osobę
nieupoważnioną,
Automatyczne wspomaganie obrotu ramienia bramki.
Wewnętrzna blokada elektromechaniczna,
Szerokość: 1200 mm,
Materiał: stal nierdzewna,
Ramię bramki odblokowywane w obu kierunkach za pomocą sygnałów
Dwa komplety bramek uchylnych
z pulpitu sterowniczego,
W momencie odłączenia napięcia bramka powinna pozostać w stanie
odblokowanym,
Automatyczne wspomaganie obrotu ramienia bramki.
Zasilanie z sieci: 9-24V AC/DC
Zasilanie z akumulatora: 12V 7Ah (czas pracy do 10godzin),
Standard czytników: Wiegand lub równoważny,
Wejścia/ Klawiatura: 4 wejścia, możliwość zaprogramowania na
obsługę przycisków,
Wyjścia: 4 wyjścia bezpotencjałowe (przekaźnikowe) do sterowania
zamkami i zworami elektromagnetycznymi,
Porty komunikacyjne: RS-485 do podłączania ekspanderów, w tym
co najmniej:
- 4 kontrolery
- 16 czytników (RF, SC zbliżeniowych)
- 4 wyświetlacze LCD/LED (z dowolnymi komunikatami - kontroler nie
posiada wbudowanego wyświetlacza),
Komunikacja: za pośrednictwem sieci LAN (TCP/IP), możliwość
Sieciowe kontrolery IP
uruchomienia komunikacji do 2 sek. od podania zasilania,
Funkcje sprzętowe: bateryjne podtrzymanie zegara RTC,
sygnalizacja pracy kontrolera za pomocą co najmniej 5 diod
diagnostycznych, 4 diod sygnalizujących stan wyjść przekaźnikowych,
4 diody sygnalizujące działanie modułu sieciowego, 1 dioda
sygnalizująca stan zasilania
Funkcje programowe: możliwość mapowania czytników i wyjść
przekaźnikowych, praca w trybie jednostronnej i dwustronnej kontroli,
dla każdego czytnika i wyjścia osobno ,przechowywanie użytkowników
i zdarzeń w pamięci FLASH kontrolera; co najmniej 65 000
użytkowników, co najmniej 65 000 zdarzeń, możliwość konfiguracji
wejść cyfrowych (przyciski, wejścia alarmowe, PPOŻ itp.), możliwość
konfiguracji grup dostępu, stref i czasu dostępu, czarnej listy,
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 19 z 20
81-703 Sopot, ul. Władysława IV 9, • Tel.: 58 555 97 10 • Fax: 58 555 97 11 • E-mail: [email protected]
4.
Czytnik kart zbliżeniowych
5.
Stacja robocza
6.
Drukarka
7.
Pulpit sterowniczy
Pamięć: wymienna pamięć kontrolera powinna umożliwić
przenoszenie konfiguracji pomiędzy kontrolerami.
Zakres napięcia: 6V DC do 14V DC,
Pobór prądu (czuwanie): 75mA
Pobór prądu maks.: 120mA
Czujnik sabotażowy: akcelerometr
Aktywne wejścia: niskonapięciowe, programowalna kontrola LED /
kontrola brzęczka, impuls bezprądowy,
Wskaźnik LED: LED RGB
Format wyjściowy: Wiegand 26bit, Wiegand 32bit, Wiegand 34bit,
Clock&data, RS485 (z możliwością dostosowania), USB (opcja),
Czytnik kart zbliżeniowych: częstotliwość 13,56MHz,
Typy kart: Mifare® ISO14443A: MIFARE Mini, MIFARE 1K, MIFARE
4K, MIFARE Ultralight, MIFARE DESFire EV1, MIFARE Plus
Dystans odczytu kart: max 60mm,
Środowisko pracy: do użytku wewnątrz i na zewnątrz pomieszczeń,
Warunki pracy: Temperatura: -25 ° C do 40 ° C,
Wilgotność: 0 do 95%,Wodoodporność: co najmniej standard IP65
Obudowa typu Tower, procesor czterordzeniowy o wydajności
równoważnej lub lepszej procesorowi Intel Core i5-4670,pamięć RAM:
co najmniej 4 GB DDR3-1600, dyski HDD: co najmniej 2 dyski 1 TB
7200 SATA II, karta sieciowa: co najmniej Gbit Ethernet 10/100/1000
Base-T, napęd DVD,
system operacyjny Microsoft® Windows® 7 Professional 64-bit,
peryferia: mysz, klawiatura,
monitor 23" o rozdzielczości co najmniej 1920 x 1080, UPS co
najmniej 1000 VA
Rodzaj druku: termosublimacja, termotransfer
Druk: dwustronny, kolorowy, monochromatyczny
Rozdzielczość druku [dpi]: co najmniej 300
Obsługa kart: przynajmniej PVC kompozytowe, samoprzylepne, PVC
Grubość karty [mils]: co najmniej 30
Pojemność podajnika [karty 30mil]: co najmniej 100
Dostępne interfejsy: USB
Temperatura pracy: od 15°C do 30°C
Prędkość druku (kolor) [karty/h]: co najmniej 180
Prędkość druku (mono) [karty/h]: co najmniej 75
Sterowanie bramkami: możliwość zwolnienia blokady wybranej bramki
Trwała obudowa wykonana ze stal nierdzewnej
Min 4 przyciski do obsługi poszczególnych bramek
Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Rozwoju Regionalnego
Rejestracja Sąd Rejonowy Gdańsk-Północ w Gdańsku KRS 0000033744 • Regon: 190315182 • NIP: 588-00-19-192
Strona 20 z 20