SPECYFIKACJA. Istotnych Warunków Zamówienia

Transkrypt

1 Instytut Ogrodnictwa Skierniewice, ul. Konstytucji 3 Maja 1/3 tel , fax Nr postępowania: 50/ZP/2012 SPECYFIKACJA Istotnych Warunków Zamówienia (SIWZ) dla postępowania o udzielenie zamówienia publicznego prowadzonego w trybie przetargu nieograniczonego pod nazwą: Wykonanie i wdrożenie systemów informatycznych 1. Wykonanie i wdrożenie systemu elektronicznego obiegu dokumentów 2. Wykonanie modułów zarządzania projektami oraz wspomagania prowadzonych badań współpracujących z serwisem intranetowym Wartość zamówienia nie przekracza kwot określonych w przepisach wydanych na podstawie art. 11 ust. 8 ustawy Prawo zamówień publicznych (Dz. U. z 2010 r. Nr 113, poz. 759 z późn. zm.). Opracowanie W imieniu Komisji Przetargowej Zatwierdzam. (podpis)... (podpis kierownika zamawiającego) Skierniewice, dnia r.

2 Spis treści 1. Zamawiający Tryb udzielenia zamówienia Opis przedmiotu zamówienia Podwykonawstwo Oferty częściowe Oferty wariantowe Zamówienia uzupełniające Termin wykonania zamówienia Warunki udziału w postępowaniu oraz opis sposobu dokonywania oceny spełniania tych warunków Wykaz oświadczeń i dokumentów, jakie mają dostarczyć Wykonawcy w celu potwierdzenia spełniania warunków udziału w postępowaniu Wykaz dokumentów, jakie mają dostarczyć Wykonawcy w celu potwierdzenia, że oferowane dostawy odpowiadają określonym wymaganiom Informacje o sposobie porozumiewania się Zamawiającego z Wykonawcami oraz przekazywania oświadczeń i dokumentów, a także wskazanie osób uprawnionych do porozumiewania się z Wykonawcami Wymagania dotyczące wadium Termin związania ofertą Opis sposobu przygotowania ofert Miejsce oraz termin składania i otwarcia ofert Opis sposobu obliczenia ceny oferty Opis kryteriów, którymi Zamawiający będzie się kierował przy wyborze oferty Informacje o formalnościach, jakie powinny zostać dopełnione po wyborze oferty w celu zawarcia umowy w sprawie zamówienia publicznego Wymagania dotyczące zabezpieczenia należytego wykonania umowy Wzór umowy Pouczenie o środkach ochrony prawnej przysługujących Wykonawcy w toku postępowania o udzielenie zamówienia Załączniki

3 1. Zamawiający Instytut Ogrodnictwa Skierniewice, ul. Konstytucji 3 Maja 1/3 tel , fax zwany dalej Zamawiającym. Godziny pracy: od poniedziałku do piątku. 2. Tryb udzielenia zamówienia Niniejsze postępowanie prowadzone jest w trybie przetargu nieograniczonego na podstawie art. 39 i nast. ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2010 r. Nr 113, poz. 759 z późn. zm.) zwanej dalej ustawą Pzp. 3. Opis przedmiotu zamówienia Przedmiotem zamówienia jest wykonanie i wdrożenie systemów informatycznych składających się z części: Nr 1. Wykonanie i wdrożenie systemu elektronicznego obiegu dokumentów EOD Nr 2. Wykonanie modułów zarządzania projektami oraz wspomagania prowadzonych badań współpracujących z serwisem intranetowym SRP, a w szczególności: wykonanie, dostarczenie, instalacja i wdrożenie systemów klasy ERP (ang. enterprise resource planning), oraz szkolenie użytkowników, wykonanie dokumentacji powykonawczej i zintegrowanie z istniejącymi systemami klasy ERP. Systemy mają wspomagać zarządzanie Instytutem Ogrodnictwa w zakresie: 1. Systemu elektronicznego obiegu dokumentów EOD (obejmuje obieg formularza zamówienia, obieg faktury zakupu, obieg karty czasu pracy, obieg wniosku o urlop). 2. Systemu do zarządzania projektami oraz wspomagania prowadzonych badań (moduły współpracujące z serwisem intranetowym) SRP. Zakres przedmiotu zamówienia obejmuje ponadto: 1) Wykonanie analizy przedwdrożeniowej. 2) Integrację wdrożonych systemów obiegu dokumentów i zarządzania projektami z systemem księgowym posiadanym przez Zamawiającego, tj. system klasy ERP Xpertis, którego producentem jest firma Macrologic S.A. 3) Przekazania kodów źródłowych. 4) Przekazanie autorskich praw majątkowych i praw pokrewnych do dzieł powstałych specjalnie na potrzeby realizacji przedmiotu zamówienia. 5) Przeprowadzenie szkoleń pracowników w zakresie obsługi systemów we wszystkich jednostkach organizacyjnych Zamawiającego. 6) Przeprowadzenie asysty przy pracy na danych rzeczywistych podczas uruchomienia systemów. 7) Świadczenie bezpłatnej opieki serwisowej nad wdrożonymi systemami w okresie gwarancji. 8) Zapewnienie bezpłatnej obsługi gwarancyjnej. 3

4 CZĘŚĆ NR 1: ELEKTRONICZNY OBIEG DOKUMENTÓW WYMAGANIA ZAMAWIAJĄCEGO 1. System elektronicznego obiegu dokumentów musi być polskojęzyczny oraz posiadać dokumentację w języku polskim (w postaci wydruku lub na nośniku CD / DVD) pozwalającą na samodzielną naukę. 2. System do elektronicznego obiegu dokumentów musi zapewnić wydajną pracę dla ok. 500 pracowników Instytutu Ogrodnictwa. 3. System elektronicznego obiegu dokumentów musi pracować w technologii trójwarstwowej: Serwer bazy danych Serwer aplikacji Cienki klient, umożliwiającej pracę w sieci LAN jak i WAN. 4. Dostęp do systemu elektronicznego obiegu dokumentów dla pracowników Instytutu Ogrodnictwa (500 pracowników) musi być realizowany za pomocą przeglądarki internetowej. Dodatkowo musi być możliwość pracy w aplikacji bez wykorzystywania przeglądarki internetowej w standardowym interfejsie okienkowym Windows i X-Window (Linux). 5. System elektronicznego obiegu dokumentów musi zapewnić integrację z systemem ERP Xpertis, którego producentem jest firma Macrologic S.A. w celu zapewnienia jednokrotnego wprowadzania danych. 6. System elektronicznego obiegu dokumentów musi posiadać możliwość utworzenia witryny WWW na potrzeby firmy witryna firmy, lub witryna wewnętrzna (portal internetowy dla pracowników) jako system zarządzania treścią (CMS Content Management System). 7. System elektronicznego obiegu dokumentów musi zapewnić: publikowanie danych na witrynie WWW, które pobierane są bezpośrednio z systemu ERP Xpertis, wprowadzanie i modyfikację danych w systemie ERP Xpertis z poziomu systemu elektronicznego obiegu dokumentów. 8. Wykonawca musi zapewnić możliwość rozszerzania funkcjonalności oraz dostosowania systemu na etapie wdrożenia oraz podczas trwania opieki serwisowej do indywidualnych wymagań Zamawiającego. 9. Wymagane jest, aby serwer bazy danych, na którym pracować będzie oprogramowanie do elektronicznego obiegu dokumentów pracował w systemach z rodziny Windows (Windows 2000 Server, Windows 2003, Windows 2008) oraz Linux. Ponadto powinno być możliwe przeniesienie danych pomiędzy platformami bez zmiany ich formatu oraz migracja z systemu Windows na Linux nie powinna wymagać dostosowywania aplikacji do nowego środowiska czyli: modyfikacji algorytmów aplikacji, konwersji bazy danych itp. 10. Wymagane jest aby oferowany system obiegu dokumentów obsługiwał dwie wersje serwera bazy danych w zależności od wielkości obsługiwanych zasobów serwer bazy danych w wersjach: 32 i 64-bitowych zarówno dla środowiska Windows jak i Linux. 11. Niezależnie od systemu operacyjnego Windows czy Linux system elektronicznego obiegu dokumentów powinien posiadać taki sam interfejs i taką samą funkcjonalność. 12. Wymagane jest aby końcówki klienckie na których działać będzie elektroniczny obieg dokumentów działały w środowisku Windows oraz w środowisku graficznym X Windows System pod Linuksem. 13. System elektronicznego obiegu dokumentów musi być zgodny z systemami: Windows 7, Windows Vista, Windows XP Pro i SUSE Linux (Compatible with Microsoft Windows 7, Certified for Microsoft Windows Vista, SUSE Linux Ready). 14. Połączenia pomiędzy końcówkami użytkownika a serwerem aplikacji muszą być szyfrowane protokółem SSL. 4

5 15. Do pracy w sieci rozległej w środowisku graficznym nie może być wymagane dodatkowe oprogramowanie terminali Windows (Windows NT TSE, Terminal Services w Windows 2000/2003/2008, oprogramowanie Citrix Metaframe, itp.). 16. System powinien umożliwiać uzależnienie dostępu do określonych danych i funkcjonalności od roli jaka jest przypisana do użytkownika. 17. System powinien być wyposażony we wbudowany debugger oraz profiler w celu śledzenia wykonania kodu oraz wykrywania długotrwających lub często wykonywanych operacji. 18. Możliwość dostępu do danych umieszczonych w bazie za pomocą co najmniej sterownika baz danych: ODBC. 19. Możliwość automatycznego wprowadzania aktywacyjnych kluczy licencyjnych poprzez internet z serwera producenta oprogramowania. WYMAGANIA ZAMAWIAJĄCEGO W ZAKRESIE PRZEPROWADZENIA WDROŻENIA, SZKOLENIA ORAZ ASYSTY PRZY PRACY NA DANYCH RZECZYWISTYCH. 1. System do elektronicznego obiegu dokumentów musi wydajnie usprawnić procesy: obiegu formularza zamówienia obiegu faktury zakupu obiegu karty czasu pracy obiegu wniosku o urlop 2. Celem wdrożenia obiegu zamówienia o zapotrzebowanie zakupu oraz obiegu faktury zakupu jest uzyskanie przez Instytut Ogrodnictwa analiz wykonania budżetu prowadzonych projektów i zadań w zakresie porównania budżetu z wykonaniem (tj. dokumentami zaksięgowanymi) oraz z wartością zamówień o zapotrzebowanie zakupu oraz wartością faktur, które dotarły do Instytutu, a które nie zostały jeszcze zaksięgowane w systemie finansowo-księgowym. 3. Celem wdrożenia obiegu karty czasu pracy jest uzyskanie przez Instytut Ogrodnictwa analiz wykonania budżetu prowadzonych projektów i zadań w zakresie porównania zaplanowanej liczby godzin na projekt i zadanie z wykonaną liczbą godzin. Ponadto celem jest usprawnienie pracy w Dziale Płac dzięki automatycznemu wczytywaniu godzin z kart czasu pracy do systemu kadrowo-płacowego. 4. Celem obiegu wniosku o urlop jest usprawnienie pracy w Dziale Kadr dzięki automatycznemu wczytywaniu wniosków o urlop do systemu kadrowo-płacowego. 5. Wdrożony system elektronicznego obiegu dokumentów musi zostać w pełni dostosowany przez Wykonawcę do potrzeb Zamawiającego poprzez przeprowadzenie parametryzacji systemu, konfiguracji, niezbędnych modyfikacji czy uzupełnień oprogramowania. 6. Wykonawca będzie zobowiązany do przeprowadzenia testów poprawności działania elektronicznego obiegu dokumentów w warunkach rzeczywistych Zamawiającego. 7. Wykonawca będzie zobowiązany do: a) Przeprowadzenia analizy wdrożeniowej celem szczegółowego rozpoznania procesów związanych z: obiegiem zamówienia o zapotrzebowanie zakupu obiegiem faktury zakupu obiegiem karty czasu pracy obiegiem wniosku o urlop b) Integracji wdrożonego systemu obiegu dokumentów z systemem klasy ERP Xpertis, którego producentem jest firma Macrologic SA w zakresie co najmniej: słowników projektów i zadań, struktury organizacyjnej, zależności służbowej stanowisk, 5

6 bazy kontrahentów, bazy pracowników, przekazywania danych z faktur zakupu do systemu finansowo-księgowego celem ich dekretacji, przekazywania danych z kart czasu pracy do systemu kadrowo-płacowego celem naliczenia list płac, przekazywania wniosków urlopowych do systemu kadrowo-płacowego celem aktualizacji karty urlopowej pracownika. c) Przeprowadzenia szkoleń pracowników w zakresie obsługi systemu do elektronicznego obiegu dokumentów. Szkolenia będą musiały być przeprowadzane w siedzibie i we wszystkich jednostkach organizacyjnych Zamawiającego oraz na dokumentach Zamawiającego. d) Przeprowadzenia asysty przy pracy na danych rzeczywistych podczas uruchomienia systemu elektronicznego obiegu dokumentów. Asysta będzie musiała być przeprowadzona w siedzibie i we wszystkich jednostkach organizacyjnych Zamawiającego oraz na dokumentach Zamawiającego. 8. Wykonawca będzie zobowiązany do przygotowania i utrzymania środowiska produkcyjnego oraz testowego wdrażanego systemu elektronicznego obiegu dokumentów. Środowisko testowe będzie zainstalowane na tym samym sprzęcie co środowisko produkcyjne. Parametry środowiska testowego będą takie same jak środowiska produkcyjnego. Zamawiający posiada serwer i infrastrukturę techniczną przeznaczoną na realizację przedmiotu zamówienia. 9. Zamawiający przeznacza na powyższe czynności w ramach przedmiotu zamówienia dla Elektronicznego Obiegu Dokumentów 300 godzin pracy asysty, szkolenia itp. świadczone przez specjalistów Wykonawcy. Wykonanie planowanych godzin zostanie potwierdzone przez Zamawiającego wraz z ich szczegółowym rozliczeniem. WYMAGANIA ZAMAWIAJĄCEGO W ZAKRESIE OPIEKI SERWISOWEJ NAD WDROŻONYM OPROGRAMOWANIEM. 1. Klasyfikacja wad: a) wada krytyczna oznacza zaprzestanie działania oprogramowania elektronicznego obiegu dokumentów, b) wada niekrytyczna oznacza ograniczenie działania oprogramowania elektronicznego obiegu dokumentów. 2. Wykonawca ponosi wobec Zamawiającego odpowiedzialność za wady przedmiotu zamówienia. 3. Wszelkie koszty związane z usunięciem wad w ramach gwarancji ponosi Wykonawca. 4. Wykonawca zobowiązany jest do utrzymywania gotowości do czynności serwisowych, przyjmowania zgłoszeń i podejmowania czynności serwisowych. 5. Zamawiający wymaga, aby Wykonawca posiadał aplikację internetową do przyjmowania i obsługi zgłoszeń, będącej podstawą komunikacji między Zamawiającym i Wykonawcą w zakresie zgłoszeń dotyczących wdrożonego systemu elektronicznego obiegu dokumentów. 6. Wszelkie wady oraz zgłoszenia dotyczące bieżącej eksploatacji systemu elektronicznego obiegu dokumentów będą zgłaszane przez Zamawiającego poprzez dedykowaną aplikację internetową. 7. Wykonawca zobowiązany jest do dostosowania systemu elektronicznego obiegu dokumentów przy każdej zmianie przepisów prawnych dotyczących Zamawiającego w trakcie trwania umowy, w tym w okresie gwarancyjnym. 8. W okresie opieki serwisowej Zamawiający ma prawo do korzystania z usługi hot-line Wykonawcy. 6

7 9. Zamawiający zapewni Wykonawcy zdalne połączenie do serwera na którym zainstalowany będzie system elektronicznego obiegu dokumentów. Wymagania integracyjne Szczegółowe wymagania z zakresu integracji Elektronicznego Obiegu Dokumentów z obecnymi systemami Zamawiającego Zamawiający wykorzystuje zintegrowany system informatyczny klasy ERP (w skrócie ERP) Xpertis firmy Macrologic S.A. w technologii MacroBase, z którym dostarczony Elektroniczny Obieg Dokumentów (w skrócie EOD) musi współpracować w opisanym poniżej zakresie. Integracji podlegać będą: 1. Baza Kontrahentów 1.1. Zakres danych podlegający integracji Szczegółowy zakres danych podlegający integracji zostanie finalnie określony w fazie analizy przedwdrożeniowej Zakres tych danych będzie obejmował: Akronim (nazwa skrótowa) Nazwę Firmy Imię Nazwisko Adres głównej siedziby firmy lub oddziału (ulica, numer budynku, numer lokalu, poczta, miejscowość, kod pocztowy, państwo) Adres korespondencyjny (ulica, numer budynku, numer lokalu, poczta, miejscowość, kod pocztowy, państwo) tylko jeśli jest inny niż adres głównej siedziby. NIP NIPUE REGON KRS PESEL Numer telefonu Numer faksu Adres strony internetowej Adres Numer podstawowego rachunku bankowego 1.2. Model synchronizacji Utworzenie lub modyfikacja zbioru danych kontrahenta spośród danych zdefiniowanych w punkcie 1.1 wyżej w dostarczonym EOD powinno zaskutkować dodaniem rekordu do Specjalnie Przygotowanej Tabeli Rejestru Zmian Kontrahentów informującego o utworzeniu lub modyfikacji kontrahenta. Specjalnie Przygotowana Tabela Rejestru Zmian Kontrahentów utworzona będzie po stronie EOD, a jej szczegółowa struktura zdefiniowana będzie w trakcie analizy przedwdrożeniowej ale obejmować musi co najmniej następujące atrybuty: Jednoznaczny Identyfikator Kontrahenta w dostarczonym EOD, Datę operacji (utworzenia lub modyfikacji danych kontrahenta), Nazwę Użytkownika (wykonującego tę operację), oraz Atrybut Systemu EOD który będzie miał ustaloną wartość domyślną na np. N. 7

8 Okresowo System ERP będzie sprawdzał Specjalnie Przygotowaną Tabelę Rejestru Zmian Kontrahentów pod kątem obecności w niej rekordów informujących o zmianach danych kontrahenta i w przypadku ich wystąpienia za pomocą Pierwszej Procedury Integrującej Kontrahentów udostępnianej przez EOD pobiorą aktualne dane dotyczące kontrahenta z dostarczonego EOD i dokonają aktualizacji danych tego kontrahenta we własnych strukturach danych, a następnie zmienią zawartość skojarzonego z tym systemem Atrybutu Systemu EOD na wartość np. T oznaczającą, że aktualizacja danych kontrahenta w dostarczanym EOD została pobrana do ERP Utworzenie lub modyfikacja zbioru danych kontrahenta spośród danych zdefiniowanych w punkcie 1.1 wyżej powinno skutkować uruchomieniem przez EOD Drugiej Procedury Integrującej Kontrahentów wywołanej ze zbiorem atrybutów odpowiadającym liście danych kontrahenta zdefiniowanej w punkcie 1.1 wyżej poszerzonej o Jednoznaczny Identyfikator Kontrahenta w dostarczonym EOD (ten parametr wykorzystywany będzie tylko przy modyfikacji danych istniejącego już Kontrahenta). Druga Procedura Integracyjna Kontrahentów powinna, po dodaniu lub modyfikacji danych kontrahenta w dostarczonym EOD, dodać rekord do Specjalnie Przygotowanej Tabeli Rejestru Zmian Kontrahentów informującego o utworzeniu lub modyfikacji kontrahenta W trakcie tworzenia nowego kontrahenta w ERP, przed utworzeniem nowego kontrahenta we własnych strukturach, za pomocą udostępnionej przez dostarczany EOD, Trzeciej Procedury Integracyjnej Kontrahentów należy sprawdzić, czy taki kontrahent już istnieje wśród kontrahentów EOD. W takim przypadku Trzecia Procedura Integracyjna Kontrahentów powinna zwrócić Jednoznaczny Identyfikator Kontrahenta w dostarczonym EOD a ERP powinien zapamiętać go we własnych strukturach danych Dostarczony EOD musi udostępniać jeszcze Czwartą Procedurę Integracyjną Kontrahentów, której zadaniem będzie zwrócić zbiór danych zdefiniowanych w punkcie 1.1 wyżej dla wskazanego, za pomocą Jednoznacznego Identyfikatora Kontrahenta w dostarczonym EOD, kontrahenta Funkcje pomocnicze Dostarczony EOD ponadto udostępni jeszcze dwie procedury: Piątą Procedurę Integracyjną Kontrahentów, której zadaniem będzie na podstawie wskazanego Unikalnego Identyfikatora Kontrahenta po stronie EOD zwrócić informację o tym, czy kontrahent jest zablokowany, czyli że nie można dla niego wystawiać faktur. 2. Faktury Zakupu 2.1. Obieg Faktur Zakupu (różne rodzaje, np. faktura VAT, pro-forma, faktura korygująca) odbywać będzie się w systemie EOD, a niektóre jego stany będą uruchamiać procedury integracyjne po stronie ERP Tworzenie Proces skanowania papierowego dokumentu Faktury Zakupu w Kancelarii Instytutu Ogrodnictwa, zgodnie z obowiązującą w Instytucie Ogrodnictwa procedurą, powinien zakończyć się utworzeniem w systemie EOD dokumentu przychodzącego Po oznaczeniu przez Kancelarię dokumentu przychodzącego jako Faktura Zakupu i uzupełnieniu minimalnego zestawu danych opisujących Fakturę Zakupu, tj. wartość netto/brutto, forma płatności, termin płatności, numer 8

9 własny faktury i kontrahent, przy pierwszym zapisie Faktury Zakupu system EOD uruchomi automatycznie, udostępnioną przez EOD, Pierwszą Procedurę Integracyjną Faktur Zakupu, której efektem będzie utworzenie po stronie ERP nowego dokumentu zakupowego w statusie Nowy albo podobnym, oznaczającym że zarejestrowano nowy dokument zakupu, który widoczny jest w rejestrze zakupu, w rozrachunkach z klientem, ale nie jest on jeszcze zaksięgowany. Pierwsza Procedura Integracyjna Faktur Zakupu powinna zwracać, jako wynik Unikalny Identyfikator Dokumentu zakupu po stronie dostarczonego EOD. Identyfikator ten będzie wykorzystywany przez pozostałe procedury integracyjne faktur zakupu Jednym z obowiązkowych parametrów Pierwszej Procedury Integracyjnej Faktur Zakupu będzie adres hiperlinku do oryginalnego dokumentu Faktury Zakupu po stronie systemu EOD W kolejnym kroku Kancelaria lub Dział Księgowości uruchamia w systemie EOD obieg dekretacji Faktury Zakupu. Operacji tej towarzyszyć będzie automatyczne wywołanie, po stronie dostarczonego EOD, Drugiej Procedury Integracyjnej Faktur Zakupu, której zadaniem będzie zmienić status dokumentu zakupu po stronie EOD na W dekretacji lub podobny oznaczający, że dokument zakupu podlega opisowi merytorycznemu. Opis merytoryczny faktury będzie wymagał wskazania dla całej faktury lub poszczególnych jej pozycji źródła finansowania w postaci: symbolu Projektu, numeru zadania tej karty i rodzaju kosztów co powinno jednoznacznie wskazać numer konta księgowego po stronie ERP Obieg dekretacji Faktury Zakupu po stronie systemu EOD powinien kończyć się w Dziale Księgowości. Po zaakceptowaniu przez pracownika Działu Księgowości dekretacji dokumentu system EOD automatycznie uruchomi, po stronie EOD, Trzecią Procedurę Integracyjną Faktur Zakupu, której zadaniem będzie zmienić status dokumentu zakupowego po stronie ERP na W akceptacji lub podobny oznaczający, że dokument zakupu jest już opisany merytorycznie i oczekuje na akceptację. Jednocześnie w systemie EOD uruchomiony zostanie obieg akceptacji dokumentu zakupu zgodnie z obowiązującą w Instytucie Ogrodnictwa procedurą Obieg akceptacji Faktury Zakupu po stronie systemu EOD powinien kończyć się automatycznym uruchomieniem, po stronie dostarczonego EOD, Czwartej Procedury Integracyjnej Faktur Zakupu, której zadaniem będzie zmienić status dokumentu zakupu po stronie ERP na Do księgowania lub podobny oznaczający, że dokument zakupu jest już opisany merytorycznie, zaakceptowany i może zostać zapłacony i zaksięgowany Ponowna edycja Do chwili zakończenia obiegu dekretacji Faktury Zakupu możliwa będzie zmiana danych opisujących Fakturę Zakupu na dokumencie w systemie EOD. Każda taka zmiana powodować będzie automatyczne uruchomienie Pierwszej Procedury Integracyjnej Faktur Zakupu z parametrem wskazującym na Unikalny Identyfikator Dokumentu zakupu po stronie dostarczonego EOD, który należy zmodyfikować zgodnie ze zmianami dokonanymi w dokumencie Faktury Zakupu po stronie systemu ERP. 3. Wnioski urlopowe 3.1. Tworzenie Dokument Wniosku o Urlop (różne rodzaje: wypoczynkowy, okolicznościowy, bezpłatny, urlop na żądanie, opiekę nad dzieckiem, 9

10 wychowawczy) powinien powstawać w systemie EOD i może być utworzony przez dowolnego pracownika zgodnie z procedurami obowiązującymi w systemie EOD W momencie pierwszego zapisania dokumentu Wniosek o Urlop w systemie EOD w dostarczonym EOD powinna automatycznie uruchomić się Pierwsza Procedura Integracyjna Urlopów. Automatyczne uruchomienie tej procedury inicjowane będzie przez system EOD. Pierwsza Procedura Integracyjna Urlopów utworzy po stronie dostarczonego EOD odpowiedni dokument nieobecności w statusie Wystawiony lub podobnym oznaczającym utworzenie dokumentu wniosek urlopowy, który jeszcze nie jest obowiązującym dokumentem nieobecności, który np. może być uwzględniany przy bilansowaniu czasu pracy czy bilansowaniu listy płac. Status ten należy traktować, jako nieobecność planowaną i wystawioną, ale jeszcze nieobowiązującą. Pierwsza Procedura Integracyjna Urlopów powinna zwracać, jako wynik Unikalny Identyfikator Dokumentu nieobecności po stronie dostarczonego EOD. Identyfikator ten będzie wykorzystywany przez pozostałe Procedury Integracyjne Urlopów Jednym z obowiązkowych parametrów Pierwszej Procedury Integracyjnej Urlopów będzie adres hiperlinku do oryginalnego dokumentu Wniosku o Urlop po stronie systemu EOD Zatwierdzanie W momencie uruchomienie obiegu zatwierdzania dokumentu po stronie systemu EOD system EOD będzie automatycznie uruchamiał po stronie dostarczonego EOD, Drugą Procedurę Integracyjną Urlopów, której zadaniem jest zmiana statusu dokumentu nieobecności po stronie ERP na W zatwierdzaniu lub podobny oznaczający, że zakończyła się faza tworzenia i planowania nieobecności i że jej autor próbuje wprowadzić dokument nieobecności w stan obowiązujący W momencie zakończenia obiegu zatwierdzania ze skutkiem negatywnym (odrzucenie wniosku) system EOD będzie automatycznie uruchamiał w EOD Trzecią Procedurę Integracyjną Urlopów, której zadaniem będzie zmienić status dokumentu nieobecności po stronie ERP na Odrzucony lub podobny oznaczający, że osoba zatwierdzająca nieobecność nie wyraziła na nią zgody W momencie zakończenia obiegu zatwierdzania ze skutkiem pozytywnym (zatwierdzenie wniosku) system EOD będzie automatycznie uruchamiał w dostarczonym EOD, Czwartą Procedurę Integracyjną Urlopów, której zadaniem będzie zmienić status dokumentu nieobecności po stronie ERP na Zatwierdzony lub podobny oznaczający, że osoba zatwierdzająca nieobecność wyraziła na nią zgodę. W przypadku, gdy Urlop nie wymaga zatwierdzania np. urlop na żądanie Czwarta Procedura Integracyjna Urlopów może zostać uruchomiona bezpośrednio po Pierwszej Procedurze Integracyjnej Urlopów (odpowiedzialny za sekwencyjne uruchomienie tych dwóch procedur integracyjnych będzie system EOD) Anulowanie Każdy wniosek o urlop może być anulowany w całości lub w części. Operacja anulowania wykonywana będzie w dostarczonym ERP przez pracownika Działu Kadr Anulowanie urlopu po stronie dostarczonego EOD powinno skutkować utworzeniem w Specjalnie Przygotowanej Tabeli bazy danych po stronie 10

11 dostarczonego EOD odpowiedniego rekordu informującego o anulowaniu dokumentu wniosek o Urlop Okresowo, po stronie systemu EOD, uruchamiana będzie Procedura Kontrolująca sprawdzająca czy w Specjalnie Przygotowanej Tabeli występują nowe rekordy sygnalizujące anulowanie dokumentu Wniosek o Urlop. W przypadku występowania takiego rekordu Procedura Kontrolująca anuluje po stronie systemu EOD dokument Wniosku o Urlop oraz anuluje wpis tej nieobecność do kalendarza pracownika, a następnie oznaczy rekord w Specjalnie Przygotowanej Tabeli jako przetworzony. 4. Projekty Projekty realizowane w Instytucie Ogrodnictwa mają swoje odzwierciedlenie w dokumencie Projekt w systemie ERP Dokument Projekt zawiera informacje o: typie projektu, czasie jego trwania, jego kierowniku, zadaniach do realizacji szczegółowych planowanych kosztach rodzajowych każdego z zadań, planowanych terminach realizacji każdego zadania, planowanych przychodach Każda zmiana, usunięcie lub dodanie nowego projektu w ERP powinna skutkować dodaniem do Specjalnie Przygotowanej Tabeli po stronie dostarczonego EOD nowego rekordu informującego o dokonanej zmianie Okresowo, po stronie systemu EOD, uruchamiana będzie Procedura Kontrolująca sprawdzająca czy w Specjalnie Przygotowanej Tabeli występują nowe rekordy sygnalizujące modyfikację, utworzenie lub usunięcie dokumentu Projektu. W przypadku występowania takiego rekordu Procedura Kontrolująca zmodyfikuje, utworzy lub usunie po stronie systemu EOD dokument Osoby oraz oznaczy rekord w Specjalnie Przygotowanej Tabeli jako przetworzony. 5. Pracownicy 5.1. Kartoteka pracowników zarządzana jest po stronie ERP Integracji kartoteki pracowniczej pomiędzy dostarczonym EOD a systemem ERP podlegać będą następujące dane osobowe: Pierwsze imię Drugie imię Nazwisko Nazwisko rodowe Nr ewidencyjny Płeć Tytuł naukowy Identyfikator jednostki organizacyjnej, w której zatrudniony jest pracownik Nazwa stanowiska, na którym zatrudniony jest pracownik Forma zatrudnienia (na etat, okres próbny, staż itp.) Wymiar zatrudnienia (pełen etat, ½ etatu, ¼ etatu itd.) Data rozpoczęcia aktualnej formy zatrudnienia Czy na wypowiedzeniu Data początku okresu wypowiedzenia Data końca okresu wypowiedzenia Kategoria zaszeregowania 11

12 Wynagrodzenie zasadnicze Data początku obowiązywania kategorii zaszeregowania i wynagrodzenia zasadniczego Liczba dni przysługującego urlopu wypoczynkowego w pierwszym dniu roku kalendarzowego Liczba dni opieki nad dzieckiem zdrowym przysługującej w pierwszym dniu roku kalendarzowego Kategoria pracownika 5.3. Każda zmiana, usunięcie lub dodanie nowej kartoteki pracowników w ERP powinna skutkować dodaniem do Specjalnie Przygotowanej Tabeli po stronie dostarczonego EOD nowego rekordu informującego o dokonanej zmianie Okresowo, po stronie systemu EOD, uruchamiana będzie Procedura Kontrolująca sprawdzająca czy w Specjalnie Przygotowanej Tabeli występują nowe rekordy sygnalizujące modyfikację, utworzenie lub usunięcie dokumentu Kartoteki Pracowników. W przypadku występowania takiego rekordu Procedura Kontrolująca zmodyfikuje, utworzy lub usunie po stronie systemu EOD dokument Pracownika oraz oznaczy rekord w Specjalnie Przygotowanej Tabeli jako przetworzony. 6. Struktura organizacyjna 6.1. Struktura organizacyjna zarządzana jest po stronie ERP Integracji struktury organizacyjnej pomiędzy dostarczonym EOD a systemem ERP podlegać będą następujące dane: Nazwa jednostki organizacyjnej /grupy Symbol jednostki organizacyjnej/grupy Jednoznaczny identyfikator jednostki organizacyjnej/grupy po stronie ERP Jednoznaczny identyfikator nadrzędnej jednostki organizacyjnej/grupy po stronie ERP Rodzaj obiektu (jednostka organizacyjna lub grupa) Data, od której wprowadzona zmiana ma zacząć obowiązywać Każda zmiana, usunięcie lub dodanie nowej jednostki organizacyjnej lub grupy w ERP powinna skutkować dodaniem do Specjalnie Przygotowanej Tabeli po stronie dostarczonego EOD nowego rekordu informującego o dokonanej zmianie Okresowo, po stronie systemu EOD, uruchamiana będzie Procedura Kontrolująca sprawdzająca czy w Specjalnie Przygotowanej Tabeli występują nowe rekordy sygnalizujące modyfikację, utworzenie lub usuniecie dokumentu jednostki organizacyjnej lub grupy. W przypadku występowania takiego rekordu Procedura Kontrolująca zmodyfikuje, utworzy lub usunie po stronie systemu EOD dokument Jednostki Organizacyjnej lub Grupy oraz oznaczy rekord w Specjalnie Przygotowanej Tabeli jako przetworzony. 7. Karty czasu pracy Rozliczanie pracy w projektach (Projekty) powinno odbywać się w systemie EOD. Efektem tego rozliczania jest wstępna Karta Czasu Pracy Pracownika (zbiór miesięcznych kart pracy pracowników), która dla każdego pracownika zawiera miesięczną informację o: Projektach, w których uczestniczył Numerach zadań w tych Projektach Liczbie dni/godzin przepracowanych na rzecz tych zadań Efekt ten będzie informacją o wartości i czasie trwania pracy pracownika na rzecz konkretnego zadania Projektu. Zbiór wszystkich takich selektywnych informacji 12

13 dotyczących pracy jednego pracownika w jednym miesiącu tworzy jego Miesięczną Kartę Czasu Pracy Pracownika Integracja Każdorazowe zaakceptowanie karty czasu pracy przez przełożonego powinno wywołać w EOD procedurę integracyjną, której zadaniem będzie przekazanie danych dotyczących Kart Pracy do ERP. Do tego przekazania danych wykorzystywana będzie, dostarczona przez Wykonawcę w ramach dostarczonego EOD, Pierwsza Procedura Integracyjna Miesięcznych Kart Czasu Pracy Pracowników. Zadaniem Pierwszej Procedury Integracyjnej Miesięcznych Kart Czasu Pracy Pracowników będzie na podstawie wymaganych przez nią parametrów dotyczących pracownika i danych z jego Miesięcznej Karty Czasu Pracy Pracownika utworzenie po stronie ERP odpowiedniego obiektu danych umożliwiającego przygotowanie rzeczywistej listy płac oraz zaksięgowanie każdej wykazanej w Miesięcznej Karcie Czasu Pracy Pracownika pracy (i wiązanym z nią kosztem powstałym podczas obiegu w EOD) na odpowiednie konta księgowe ewidencjonujące koszty pracy dla konkretnego zadania odpowiedniej Karty Programowej. Pierwsza Procedura Integracyjna Miesięcznych Kart Czasu Pracy Pracowników w wyniku zwróci Unikalny Identyfikator jednoznacznie wskazujący na obiekt danych reprezentujący Miesięczną Kartę Czasu Pracy Pracownika po stronie EOD Korekty W każdym momencie, aż do zamknięcia listy płac po stronie dostarczonego EOD, pracownik działu Kadr będzie mógł uruchomić po stronie systemu EOD procedurę aktualizacyjną, której zadaniem będzie ponowne przekazanie danych o Miesięcznej Karcie Czasu Pracy Pracownika do ERP. Do tego ponownego przekazania danych wykorzystywana będzie również Pierwsza Procedura Integracyjna Miesięcznych Kart Czasu Pracy Pracowników, do której w przebiegu korygującym przekazywany będzie również, zwrócony przez nią w pierwszym przebiegu, Unikalny Identyfikator wskazujący na odpowiedni obiekt danych reprezentujący korygowaną Miesięczną Kartę Czasu Pracy Pracownika po stronie ERP. Zakres podmiotowy integracji 1. Wykonawca przygotowuje w dostarczonym EOD wszystkie procedury integracyjne po stronie dostarczonego EOD w technologii umożliwiającej wywoływanie tych procedur przez system MacroBase ver W szczególności mogą to być: procedury składowane w bazie danych dostarczanego systemu, które mogą być wywoływane za pośrednictwem ODBC, inne spełniające wymóg współpracy z technologią MacroBase 2. Wykonawca odpowiedzialny jest za przygotowanie procedur integracyjnych inicjowanych po stronie systemu ERP a wykonywanych po stronie dostarczonego EOD. 3. Wykonawca odpowiedzialny jest za przygotowanie procedur integracyjnych inicjowanych po stronie dostarczonego EOD. 4. Wykonawca odpowiedzialny jest za przygotowanie wszystkich Specjalnie Przygotowywanych Tabel Integracyjnych po stronie dostarczonego EOD. 13

14 CZĘŚĆ NR 2 - MODUŁY ZARZĄDZANIA PROJEKTAMI ORAZ WSPOMAGANIA PROWADZONYCH BADAŃ WSPÓŁPRACUJĄCYCH Z SERWISEM INTRANETOWYM SRP WYMAGANIA ZAMAWIAJĄCEGO 1. System do rozliczania projektów musi być polskojęzyczny oraz posiadać dokumentację w języku polskim (w postaci wydruku lub na nośniku CD / DVD) pozwalającą na samodzielną naukę. 2. System do rozliczania projektów musi zapewnić wydajną pracę dla pracowników Komórki Wspierania Badań Sekcja Planowania Instytutu Ogrodnictwa oraz pracowników pełniących funkcję Kierownika Projektu lub Kierownika Zakładu, przy obsłudze średnio w roku ok. 100 projektów. 3. System do rozliczania projektów musi pracować w technologii trójwarstwowej: Serwer bazy danych Serwer aplikacji Cienki klient, umożliwiająca pracę w sieci LAN jak i WAN. 4. Dostęp do oferowanego systemu rozliczania interfejs dla interfejsie Instytutu Ogrodnictwa w funkcję Kierownika Projektu lub Kierownika Zakładu musi być realizowany za pomocą przeglądarki internetowej. Dodatkowo musi być interfejs pracy w aplikacji bez wykorzystywania przeglądarki internetowej w standardowym interfejsie okienkowym Windows. 5. System rozliczania projektów musi posiadać możliwość utworzenia witryny WWW na potrzeby firmy witryna firmy, lub witryna wewnętrzna (portal internetowy dla pracowników) jako system zarządzania treścią (CMS Content Management System). 6. System rozliczania projektów musi zapewnić integrację z systemem ERP Xpertis, którego producentem jest firma Macrologic S.A. w celu zapewnienia jednokrotnego wprowadzania danych. 7. System rozliczania projektów musi zapewnić: publikowanie danych na witrynie WWW, które pobierane są bezpośrednio z systemu ERP Xpertis, wprowadzanie i modyfikację danych w systemie ERP Xpertis z poziomu systemu rozliczania projektów, zarówno z wykorzystaniem przeglądarki internetowej jak i bez przeglądarki w standardowym interfejsie okienkowym Windows. 8. Wykonawca musi zapewnić możliwość rozszerzania i modyfikacji funkcjonalności oraz dostosowania systemu na etapie wdrożenia oraz podczas trwania opieki serwisowej do indywidualnych wymagań Zamawiającego. 9. Wymagane jest aby serwer bazy danych na którym pracować będzie system do rozliczania projektów pracował w systemach rodziny Windows (Windows 2000 Server, Windows 2003, Windows 2008). 10. Wymagane jest aby system rozliczania projektów obsługiwał dwie wersje serwera bazy danych w zależności od wielkości obsługiwanych zasobów serwer bazy danych w wersjach: 32 i 64-bitowych dla środowiska Windows. 11. Wymagane jest aby końcówki klienckie na których działać będzie system rozliczania projektów działały w środowisku Windows. 12. Oferowany system rozliczania projektów badawczych musi być zgodny z systemami: Windows 7, Windows Vista, Windows XP Pro i SUSE Linux (Compatible with Microsoft Windows 7, Certified for Microsoft Windows Vista, SUSE Linux Ready). 13. Połączenia pomiędzy końcówkami użytkownika a serwerem aplikacji muszą być szyfrowane protokołem SSL. 14

15 14. Do pracy w sieci rozległej w środowisku graficznym nie może być wymagane dodatkowe oprogramowanie terminali Windows (np. Windows NT TSE, Terminal Services w Windows 2000/2003/2008, oprogramowanie Citrix Metaframe, itp.). 15. System powinien umożliwiać uzależnienie dostępu do określonych danych i funkcjonalności od uprawnień jaka jest przypisana do użytkownika. 16. System powinien być wyposażony w wbudowany debugger oraz profiler w celu śledzenia wykonania kodu oraz wykrywania długotrwających lub często wykonywanych operacji. 17. Możliwość dostępu do danych umieszczonych w bazie za pomocą co najmniej sterownika baz danych: ODBC. 18. Możliwość automatycznego wprowadzania aktywacyjnych kluczy licencyjnych poprzez internet z serwera producenta oprogramowania. WYMAGANIA ZAMAWIAJĄCEGO W ZAKRESIE FUNKCJONALNOŚCI SYSTEMU DO ROZLICZANIA PROJEKTÓW BADAWCZYCH - Wykonanie modułów zarządzania projektami oraz wspomagania prowadzonych badań współpracujących z serwisem intranetowym SRP 1. System do rozliczania projektów powinien wydajnie usprawnić procesy: 1.1. Sporządzania i rozliczania budżetów poszczególnych tematów badawczych Instytutu: Tematów badawczych, w tym projektów badawczych, Tematów statutowych, 1.2. Kontroli przekroczenia budżetów w zadaniach badawczych z dokładnością do poszczególnych projektów badawczych, 1.3. Oceny bieżącej sytuacji ekonomiczno-finansowej Instytutu oraz usprawnienia budżetowania i sprawozdawczości, 1.4. Dystrybucji raportów w zakresie wykorzystania budżetów projektów badawczych dla Kierowników Projektów i Kierowników Zakładów. 2. System rozliczania projektów musi umożliwiać dowolne określenie jednostek budżetowych np. projekt, temat, zadanie, Dział, Zakład, rodzaj kosztu, MPK, źródło finansowania itp.). Każdy Kierownik tematu badawczego musi mieć dostęp do systemu. 3. Jednostki budżetowe zdefiniowane w systemie rozliczania projektów muszą mieć możliwość budowy hierarchicznej (np. podział działalności badawczej na tematy, tematów na projekty i dalej projektów na zadania itd.). 4. System rozliczania projektów musi mieć możliwość kontroli wykonania budżetu za dowolny okres (miesiąc, kwartał, rok) w ujęciu wartościowym i ilościowym (np. ilość roboczogodzin). 5. System rozliczania projektów musi mieć możliwość budowania raportów dotyczących kosztów na zróżnicowanym poziomie szczegółowości (np. koszty Zakładów w podziale na projekty i koszty rodzajowe lub koszty materiałów w Zakładzie). 6. System rozliczania projektów musi możliwość kontrolę budżetu również w przypadku gdy w projekt zaangażowanych jest kilka zakładów. Oczekiwane raporty to np. projekt w podziale na zakłady i koszty rodzajowe, projekt w podziale na koszty rodzajowe, zestawienie roboczogodzin dla projektu na zakłady itd. 7. System rozliczania projektów musi kontrolować wykonanie budżetu nie tylko na poziomie zagregowanym ale również z drążeniem danych tj. możliwość wejścia do szczegółu, czyli do pojedynczego zaksięgowanego dokumentu. 8. System rozliczania projektów musi mieć rozbudowane mechanizmy raportujące (np. możliwość definiowania różnych raportów dla tych samych okresów). 9. System do rozliczania projektów powinien być na tyle elastyczny, aby użytkownicy systemu mieli łatwość uwzględniania w sprawozdaniu dowolnych danych. Szczególnie istotne jest zapewnienie łatwości generowania nowych, elektronicznych szablonów 15

16 sprawozdań na podstawie istniejących wzorów, modyfikacji układu danych w szablonie, agregacji kwot pośrednich oraz selekcji i kojarzenia dowodów księgowych z komórkami danych poszczególnych szablonów. 10. System rozliczania projektów musi umożliwiać grupową pracę nad budowaniem budżetu Instytutu, wszystkim kierownikom tematów badawczych. Mechanizm budżetowania działalności badawczej powinien działać następująco: Pracownik Komórki Wspierania Badań Sekcja Planowania przygotowuje arkusz budżetu cząstkowego i wskazuje Kierownika Projektu, który powinien wypełnić arkusz budżetowy, Kierownik Projektu po zalogowaniu do strony internetowej pobiera arkusz budżetowy i wypełnia go, Kierownik Zakładu po zalogowaniu do strony internetowej ma wgląd do wszystkich budżetów swojego Zakładu, zatwierdza budżety lub modyfikuje i zatwierdza. Pracownik Komórki Wspierania Badań Sekcja Planowania ma wgląd we wszystkie budżety projektów poszczególnych Zakładów oraz cały budżet dla działalności badawczej, który zbudowany został automatycznie przez system na podstawie budżetów cząstkowych. 11. System rozliczania projektów musi umożliwiać agregację budżetu w różnych przekrojach w tym także zgodnie ze strukturą organizacyjną Instytutu. 12. System rozliczania projektów musi mieć możliwość definiowania i pamiętania różnych wersji budżetów oraz kontroli wykonania poprzez porównanie do dowolnej zapamiętanej wersji. W ciągu roku budżetowego może być pamiętana dowolna liczba wersji budżetu. 13. System rozliczania projektów musi w sposób automatyczny dystrybuować raporty dotyczące wykorzystania budżetu projektów dla Kierownika Projektu oraz Kierownika Zakładu. Mechanizm powinien działać następująco: Pracownik Komórki Wspierania Badań Sekcja Planowania przygotowuje szablon raportu dla Kierownika Projektu oraz szablon raportu dla Kierownika Zakładu wraz z określeniem uprawnień do danych, System z określoną częstotliwością uaktualnia dane dotyczące wykonań i umieszcza raporty do pobrania na stronie internetowej, Kierownik Projektu lub Kierownik Zakładu po zalogowaniu się do strony pobiera raporty prezentujące wykonanie budżetu. 14. System rozliczania projektów musi mieć możliwość weryfikacji budżetu czasu pracy (wgląd do karty czasu pracy z obszaru personel ERP Xpertis Kadry i Płace). 15. Możliwość rejestrowania kosztu w drodze tzn. rezerwacji budżetu poprzez ujęcie wartości zapotrzebowań zakupów i faktur zakupu, które są w akceptacji ale nie są zaksięgowane. Możliwość blokowania/ostrzegania o przekroczeniu budżetu z uwzględnieniem rezerwacji przy wprowadzaniu nowych zapotrzebowań zakupu (kontrola nad kosztami / wydatkami już zamówionymi, a jeszcze nie zaksięgowanymi; powiązanie z rejestracją faktury w kancelarii Instytutu czyli uchwycenie momentu wejścia faktury). WYMAGANIA ZAMAWIAJĄCEGO W ZAKRESIE PRZEPROWADZENIA WDROŻENIA, SZKOLENIA ORAZ ASYSTY PRZY PRACY NA DANYCH RZECZYWISTYCH - Wykonanie modułów zarządzania projektami oraz wspomagania prowadzonych badań współpracujących z serwisem intranetowym SRP 1. Wdrożony system do rozliczania projektów musi zostać w pełni dostosowany przez Wykonawcę do potrzeb Zamawiającego poprzez przeprowadzenie parametryzacji systemu, konfiguracji, niezbędnych modyfikacji czy uzupełnień oprogramowania. 2. Wykonawca będzie zobowiązany do przeprowadzenia testów poprawności działania systemu do rozliczania projektów w warunkach rzeczywistych Zamawiającego. 16

17 3. Wykonawca będzie zobowiązany do: 3.1. Przeprowadzenia analizy wdrożeniowej celem szczegółowego rozpoznania potrzeb związanych z: Budżetowaniem działalności badawczej (projektów, zadań), Budżetowaniem pozostałej działalności, Strukturą informacyjną Instytutu, Wymaganymi raportami i analizami na potrzeby sprawozdawczości wewnętrznej i zewnętrznej, Sposobu i zakresu dystrybucji raportów i analiz w zakresie badania stopnia wykorzystania budżetów projektów dla Kierowników Projektów wszyscy pracownicy Instytutu pełniących funkcję w roli Kierownika Projektu lub Kierownika Zakładu) Integracji wdrożonego systemu do rozliczania projektów z systemem klasy ERP Xpertis, którego producentem jest firma Macrologic SA oraz z systemem elektronicznego obiegu dokumentów, który jest przedmiotem części 1 w zakresie co najmniej: słowników projektów i zadań, struktury organizacyjnej wraz z zależnościami służbowymi stanowisk, bazy kontrahentów, bazy pracowników, dokumentów finansowych mających wpływ na pozycje przychodowe oraz kosztowe rozliczanych projektów(w tym: faktura zakupu, faktura sprzedaży, wniosek o zakup) z uwzględnieniem statusów tych dokumentów: w obiegu, zaakceptowany, zadekretowany kart czasu pracy, 3.3. Przeprowadzenia szkoleń pracowników w zakresie obsługi systemu do rozliczania projektów. Szkolenia będą musiały być przeprowadzane w siedzibie oraz na dokumentach Zamawiającego. Szkolenie powinno zostać przeprowadzone we wszystkich jednostkach organizacyjnych Zamawiającego Przeprowadzenia asysty przy pracy na danych rzeczywistych podczas uruchomienia systemu rozliczania projektów. Asysta będzie musiała być przeprowadzona w siedzibie, we wszystkich jednostkach organizacyjnych oraz na dokumentach Zamawiającego Zamawiający przeznacza na powyższe czynności w ramach przedmiotu zamówienia dla systemu rozliczania projektów 100 godz. pracy asysty, szkolenia, itp. Świadczone przez specjalistów Wykonawcy. Wykonanie planowanych godzin zostanie potwierdzone przez Zamawiającego wraz z ich szczegółowym rozliczeniem. 4. Wykonawca będzie zobowiązany do przygotowania i utrzymania środowiska produkcyjnego oraz testowego wdrażanego systemu do rozliczania projektów. Środowisko testowe będzie zainstalowane na tym samym sprzęcie co środowisko produkcyjne. Parametry środowiska testowego będą takie same jak środowiska produkcyjnego. Zamawiający posiada serwer i infrastrukturę techniczną przeznaczoną na realizację przedmiotu zamówienia. WYMAGANIA ZAMAWIAJĄCEGO W ZAKRESIE OPIEKI SERWISOWEJ NAD WDROŻONYM OPROGRAMOWANIEM. 1. Klasyfikacja wad: a) wada krytyczna oznacza zaprzestanie działania oprogramowania elektronicznego obiegu dokumentów, 17

18 b) wada niekrytyczna oznacza ograniczenie działania oprogramowania elektronicznego obiegu dokumentów. 2. Wykonawca ponosi wobec Zamawiającego odpowiedzialność za wady przedmiotu zamówienia. 3. Wszelkie koszty związane z usunięciem wad w ramach gwarancji ponosi Wykonawca. 4. Wykonawca zobowiązany jest do utrzymywania gotowości do czynności serwisowych, przyjmowania zgłoszeń i podejmowania czynności serwisowych. 5. Zamawiający wymaga, aby Wykonawca posiadał aplikację internetową do przyjmowania i obsługi zgłoszeń, będącej podstawą komunikacji między Zamawiającym i Wykonawcą w zakresie zgłoszeń dotyczących wdrożonego systemu elektronicznego obiegu dokumentów. 6. Wszelkie wady oraz zgłoszenia dotyczące bieżącej eksploatacji systemu do zarządzania projektami będą zgłaszane przez Zamawiającego poprzez dedykowaną aplikację internetową. 7. Wykonawca zobowiązuje się do zapewnienia bezpłatnej opieki serwisowej w okresie 36 miesięcy od daty zakończenia przedmiotu zamówienia. 8. W okresie opieki serwisowej Zamawiający ma prawo do korzystania z usługi hot-line Wykonawcy. 9. Zamawiający zapewni Wykonawcy zdalne połączenie do serwera na którym zainstalowany będzie system do rozliczania projektów. Wymagania integracyjne - Wykonanie modułów zarządzania projektami oraz wspomagania prowadzonych badań współpracujących z serwisem intranetowym. Zamawiający wykorzystuje zintegrowany system informatyczny klasy ERP (w skrócie ERP) Xpertis firmy Macrologic w technologii MacroBase oraz Elektroniczny Obieg Dokumentów (w skrócie EOD), z którymi dostarczony System Rozliczania Projektów (w skrócie SRP) musi współpracować w opisanym poniżej zakresie. Zakres przedmiotowy integracji: 1. Baza Kontrahentów 1.1. Zakres danych podlegający integracji Szczegółowy zakres danych podlegający integracji zostanie finalnie określony w fazie analizy przedwdrożeniowej Zakres tych danych będzie obejmował: Akronim (nazwa skrótowa) Nazwę Firmy Imię Nazwisko Adres głównej siedzimy firmy lub oddziału (ulica, numer budynku, numer lokalu, poczta, miejscowość, kod pocztowy, państwo) Adres korespondencyjny (ulica, numer budynku, numer lokalu, poczta, miejscowość, kod pocztowy, państwo) tylko jeśli inny niż adres głównej siedziby. NIP NIPUE REGON KRS PESEL Numer telefonu Numer faksu Adres strony internetowej 18

19 Adres Numer podstawowego rachunku bankowego 1.2. Model synchronizacji Utworzenie lub modyfikacja zbioru danych kontrahenta spośród danych zdefiniowanych w punkcie 1.1 wyżej w dostarczonym SRP powinno skutkować dodaniem rekordu do Specjalnie Przygotowanej Tabeli Rejestru Zmian Kontrahentów informującego o utworzeniu lub modyfikacji kontrahenta. Specjalnie Przygotowana Tabela Rejestru Zmian Kontrahentów utworzona będzie po stronie EOD, a jej szczegółowa struktura zdefiniowana będzie w trakcie analizy przedwdrożeniowej ale obejmować musi co najmniej następujące atrybuty: Jednoznaczny Identyfikator Kontrahenta w dostarczonym EOD, Datę operacji (utworzenia lub modyfikacji danych kontrahenta), Nazwę Użytkownika (wykonującego tę operację), oraz Atrybut Systemu EOD który będzie miał ustaloną wartość domyślną na np. N Okresowo System SRP będzie sprawdzał Specjalnie Przygotowaną Tabelę Rejestru Zmian Kontrahentów pod kątem obecności w niej rekordów informujących o zmianach danych kontrahenta i w przypadku ich wystąpienia za pomocą Pierwszej Procedury Integrującej Kontrahentów udostępnianej przez EOD pobiorą aktualne dane dotyczące kontrahenta z EOD i dokonają aktualizacji danych tego kontrahenta we własnych strukturach danych, a następnie zmienią zawartość skojarzonego z tym systemem Atrybutu Systemu SRP na wartość np. T oznaczającą, że aktualizacja danych kontrahenta w EOD została pobrana do SRP W SRP nie przewidziano możliwości tworzenia nowego i modyfikowania danych istniejącego kontrahenta 2. Faktury Zakupu 2.1. Obieg Faktur Zakupu (różne rodzaje, np. faktura VAT, pro-forma, faktura korygująca) odbywać będzie się w systemie EOD, a niektóre jego stany będą uruchamiać procedury integracyjne po stronie SRP Tworzenie Kancelaria lub Dział Księgowości uruchamia w systemie EOD obieg dekretacji Faktury Zakupu,. Operacji tej towarzyszyć będzie automatyczne wywołanie, po stronie dostarczonego SRP, Pierwszej Procedury Integracyjnej Faktur Zakupu, której zadaniem będzie utworzenie dokumentu zakupu po stronie SRP w statusie zadekretowany lub podobny oznaczający, że dokument zakupu został właśnie opisany merytorycznie. Opis merytoryczny faktury będzie wymagał wskazania dla całej faktury lub poszczególnych jej pozycji źródła finansowania w postaci: symbolu Projektu, numeru zadania tej karty i rodzaju kosztów co powinno jednoznacznie wskazać numer konta księgowego po stronie ERP oraz pozycję modelu analitycznego w systemie SRP Kierownik Projektu lub inna osoba uprawniona uruchamia w systemie EOD proces akceptacji dokumentu zamówienia w obiegu pt. Zamówienie. Operacji tej towarzyszyć będzie automatyczne wywołanie, po stronie dostarczonego SRP, Drugiej Procedury Integracyjnej Faktur Zakupu, której zadaniem będzie utworzenie dokumentu zaakceptowanego wniosku zamówienia po stronie SRP w statusie zaakceptowany lub podobny oznaczający, że dokument został właśnie opisany merytorycznie. Opis merytoryczny dokumentu będzie wymagał wskazania dla całej faktury lub poszczególnych jej 19

20 pozycji źródła finansowania w postaci: symbolu Projektu, numeru zadania tej karty i rodzaju kosztów co powinno jednoznacznie wskazać numer konta księgowego po stronie ERP oraz pozycję modelu analitycznego w systemie SRP 2.3. Ponowna edycja Do chwili zakończenia obiegu dekretacji Faktury Zakupu możliwa będzie zmiana danych opisujących Fakturę Zakupu na dokumencie w systemie EOD. Każda taka zmiana powodować będzie automatyczne uruchomienie Pierwszej Procedury Integracyjnej Faktur Zakupu z parametrem wskazującym na Unikalny Identyfikator Dokumentu zakupu po stronie EOD, który należy zmodyfikować zgodnie ze zmianami dokonanymi w dokumencie Faktury Zakupu po stronie systemu SRP Do chwili zakończenia obiegu Zamówienia możliwa będzie zmiana danych opisujących Dokument Zmówienia na dokumencie w systemie EOD. Każda taka zmiana powodować będzie automatyczne uruchomienie Drugiej Procedury Integracyjnej Faktur Zakupu z parametrem wskazującym na Unikalny Identyfikator Dokumentu po stronie EOD, który należy zmodyfikować zgodnie ze zmianami dokonanymi w dokumencie Faktury Zakupu po stronie systemu SRP 3. Projekty Projekty realizowane w Instytucie Ogrodnictwa mają swoje odzwierciedlenie w dokumencie Projekt w systemie ERP Dokument Projekt zawiera informacje o: typie projektu, czasie jego trwania, jego kierowniku, zadaniach do realizacji szczegółowych planowanych kosztach rodzajowych każdego z zadań, planowanych terminach realizacji każdego zadania, planowanych przychodach Każda zmiana, usunięcie lub dodanie nowego projektu w ERP powinna skutkować dodaniem do Specjalnie Przygotowanej Tabeli po stronie dostarczonego EOD nowego rekordu informującego o dokonanej zmianie Okresowo, po stronie systemu SRP, uruchamiana będzie Procedura Kontrolująca sprawdzająca czy w Specjalnie Przygotowanej Tabeli występują nowe rekordy sygnalizujące modyfikację, utworzenie lub usuniecie dokumentu Projektu. W przypadku występowania takiego rekordu Procedura Kontrolująca zmodyfikuje, utworzy lub usunie po stronie systemu SRP dokument Projektu oraz oznaczy rekord w Specjalnie Przygotowanej Tabeli jako przetworzony. 4. Pracownicy 4.1. Kartoteka pracowników zarządzana jest po stronie ERP Integracji kartoteki pracowniczej pomiędzy dostarczonym SRP a systemem ERP podlegać będą następujące dane osobowe: Pierwsze imię Drugie imię Nazwisko Nazwisko rodowe Nr ewidencyjny Płeć 20