Załącznik nr 1 do SIWZ Opis przedmiotu zamówienia Przedmiotem zamówienia jest: A. Część nr 1. W części nr 1: Wdrożenie systemu zarządzania projektami klasy Enterprise Project Management. W części nr 2: Dostawa oprogramowania standardowego do modelowania architektury systemów IT. Wdrożenie systemu zarządzania projektami klasy Enterprise Project Management. I) Zamawiający przewiduje Wdrożenie Systemu w 3 Etapach: 1. Etap I: Uruchomienie Systemu dla projektów Zamawiającego, obejmujące następujące Produkty Cząstkowe: 1.1 Dokument Zarządczy - Ustalenie zasad realizacji Projektu, spotkanie inicjujące projekt - co najmniej całodniowy warsztat dla przedstawicieli Zamawiającego (10 osób) przybliżający możliwości Systemu EPM, 1.2 Projekt Techniczny Systemu poprzedzony analizą przedwdrożeniową. Analiza przedwdrożeniowa uwzględniająca działania optymalizacyjne realizowane przez Zamawiającego, jak również zatwierdzone przez Zamawiającego sugestie Wykonawcy w zakresie optymalizacji zasad zarządzania projektami, oparte na możliwościach wynikających z wdrożenia Systemu, na podstawie, której Wykonawca opracuje Projekt Techniczny Systemu, 1.3 Konfiguracja i modyfikacja oprogramowania. Konfiguracja i modyfikacja oprogramowania w celu dopasowania go do specyficznych potrzeb Zamawiającego w zakresie zarówno dostosowania funkcjonalności standardowych Systemu, jak i dostarczenie funkcjonalności dedykowanych wykraczających poza standardową funkcjonalność Systemu, wynikającą z nw. wymagań i analizy przedwdrożeniowej, stosownie do postanowień Projektu Technicznego, 1.4 Integracja. Integracja Systemu z : 1.4.1 systemem poczty elektronicznej (Microsoft Exchange Server 2010): powiadomienia mailowe, zadania, 1.4.2 usługami katalogowymi Systemu operacyjnego Microsoft Active Directory Windows Server 2003: zarządzanie użytkownikami i zasobami, 1.4.3 pakietem Microsoft Office 2007 lub wyższym, tak aby System pozwalał: 1.4.3.1 aktualizować plany i przedstawiać je w postaci raportów z wykorzystaniem takich narzędzi, jak Microsoft Project, Excel, PowerPoint i Word.
1.4.3.2 pobrać dane z bazy danych na potrzeby planowania co ma pozwolić szybko tworzyć niestandardowe raporty z dokładnymi informacjami i automatycznie odświeżać raport, gdy wykorzystane w nim dane ulegną zmianie. 1.5 Migracja danych. Przeprowadzeniu migracji określonej przez Zamawiającego części danych z wybranego przez Zamawiającego projektu, w celu umożliwienia kompleksowego przetestowania Systemu (migracja danych z dokumentów /formularzy w wersji edytowalnej elektronicznej (Word, MS Project, Excel, plików OpenProj (.mpp), itp.) co najmniej po jednym pliku z każdego typu. 1.6 Testy Systemu 1.7 Start produkcyjny Systemu. 2. Etap II: Szkolenia i dokumentacja techniczna 2.1 Szkolenia. 2.1.1 Szkolenie użytkowników i kierowników projektów. Przeprowadzenie instruktażu z użytkowania Systemu dla wszystkich użytkowników Systemu w wymiarze 16 godzin w sali przygotowanej przez Wykonawcę na terenie Warszawy dla nie więcej niż 50 osób oraz dostarczenie materiałów szkoleniowych w formie papierowej i elektronicznej na płycie dla nie więcej niż 50 osób, Szkolenie odbędzie się w grupach nie większych niż 25 osób. Szkolenia powinny być przeprowadzone w dni robocze w g. 8-16. Zakres szkolenia powinien być odpowiedni dla kierowników i dla pracowników tj. tematyka powinna być odrębna dla tych grup w związku z tym grupy kierowników i pracowników powinny być przeszkolone oddzielnie. Dodatkowo zakres szkolenia powinien umożliwić pracownikom zapełnienie Systemu (migrację danych do systemu). 2.1.2 Szkolenie administratorów. Przeprowadzenie szkolenia dla Administratorów Systemu (3 osoby) w siedzibie Zamawiającego z zakresu Administracji Systemem w wymiarze 8 godzin 2.2 Dokumentacja techniczna. W szczególności: aktualizacja Projektu Technicznego. 3. Etap III: Asysta techniczna i optymalizacja Systemu, w ramach puli do 50 roboczogodzin konsultacyjno-programistycznych do wykorzystania przez Zamawiającego w terminie od daty zakończenia Etapu 2 do wyczerpania godzin Asysty technicznej bądź w przeciągu 12 miesięcy od daty zawarcia Umowy, obejmujące: 3.1 Zapewnienie pomocy technicznej Zamawiającemu, w szczególności: rozwiązywanie problemów technicznych związanych z funkcjonowaniem Systemu, pomoc przy rekonfiguracji architektury Systemu, aktualizacji oprogramowania, instalacji nowych wersji oprogramowania, a także przy bieżącej eksploatacji. 3.2 Optymalizację Systemu polegającą na dalszym jego rozwoju i konfiguracji nowych funkcjonalności wynikającą z doświadczeń w użytkowaniu narzędzia i pojawiających się nowych potrzeb, 3.3 Aktualizację dokumentacji technicznej i materiałów szkoleniowych wynikającą z wprowadzonych zmian, w szczególności z rozwoju Systemu. II) Szczegółowe wymagania dotyczące Produktów Cząstkowych str. 2 z 17
1. Analiza przedwdrożeniowa, o której mowa w pkt. I. 1.2. Wykonawca przeprowadzi analizę przedwdrożeniową, która powinna obejmować w szczególności: 1.1 Analizę kontekstu organizacyjnego w zakresie zarządzania projektami i portfelem projektów 1.2 Analizę obecnych procesów, procedur i instrukcji związanych z zarządzaniem projektami, 1.3 Analizę obowiązujących procesów, procedur i instrukcji w zakresie zarządzania usługami na styku z zarządzaniem projektami, 1.4 Analiza przedwdrożeniowa będzie stanowiła podstawę do aktualizacji zasad zarządzania projektami oraz do wdrożenia zasad w Systemie informatycznym wspomagającym zarządzanie projektami i portfelem projektów w organizacji. 2. Dokument Zarządczy, o którym mowa w pkt. I. 1.1. Wykonawca opracuje i dostarczy Dokument Zarządczy, który powinien zawierać w szczególności: 2.1 Opis organizacji procesu wdrożenia Systemu. 2.2 Szczegółowy Harmonogram Wdrożenia uwzględniający podział na Etapy Projektowe i m.in.: 2.2.1 Datę spotkania inicjującego projekt 2.2.2 Daty rozpoczęcia i zakończenia prac nad Projektem Technicznym, 2.2.3 Daty zakończenia przygotowania środowiska produkcyjnego, 2.2.4 Daty rozpoczęcia i zakończenia finalnej konfiguracji rozwiązania 2.2.5 Daty rozpoczęcia i zakończenia testów, 2.2.6 Daty rozpoczęcia i zakończenia migracji, 2.2.7 Daty opracowania założeń i narzędzi dodatkowych takich jak raporty, interfejsy i innych, 2.2.8 Daty rozpoczęcia i zakończenia szkoleń użytkowników końcowych, 2.2.9 Daty opracowania dokumentacji dla użytkowników końcowych, 2.2.10 Datę startu produkcyjnego. 2.3 Plan testów m.in. rodzaj i przebieg testów. 2.4 Plan szkoleń 2.5 Plan migracji 2.6 Wykaz produktów projektu wraz z kryteriami odbioru. 2.7 Opis struktury organizacyjnej projektu mieszczącej się w uwarunkowaniach Umowy. 2.8 Opis krytycznych czynników ryzyka i sukcesu. str. 3 z 17
2.9 Opis procedur zarządzania Projektem w zakresie: komunikacji, kontroli zmian, monitorowania i raportowania postępu prac, zarządzania problemami i ryzykiem. 2.10 Proponowane procedury powinny uwzględniać uwarunkowania Umowy, czyli powinny być ich potwierdzeniem lub ewentualnie uszczegółowieniem dotyczy to również wymaganych Umową procedur usuwania wad oraz świadczenia usług w zakresie gwarancji. 2.11 Skład osobowy zespołów projektowych. 2.12 Opracowany przez Wykonawcę Dokument Zarządczy powinien zostać przekazany w formie papierowej (w dwóch egzemplarzach) oraz w formie elektronicznej na nośniku CD-ROM w formacie MS Word i PDF. 2.13 Działania Wykonawcy związane z opracowaniem oraz odbiorem Dokumentu Zarządczego w żaden sposób nie wstrzymują Wykonawcy z realizacji zobowiązań wynikających z Umowy. 3. Projekt Techniczny Systemu, o którym mowa w pkt. I. 1.2. Wykonawca opracuje i dostarczy Projekt Techniczny Systemu, który powinien zawierać w szczególności: 3.1 Wstęp 3.1.1 Założenia Projektu Technicznego 3.1.2 Słownik pojęć i skrótów 3.1.3 Spis załączników 3.2 Opis funkcjonalny 3.2.1 Słownik pojęć 3.2.2 Aktorzy 3.2.3 Przypadki użycia 3.2.4 Opis funkcjonalności 3.2.5 Zasilanie Systemu danymi 3.2.6 Komponenty formularzy 3.2.7 Walidacje 3.2.8 Walidacja składniowa 3.2.9 Walidacja semantyczna 3.2.10 Maskowanie pól 3.2.11 Spójność bazy danych 3.2.12 Wprowadzanie danych z pliku XLS 3.3 Integracje 3.3.1 MS Exchange 3.3.1.1 Zakres integracji str. 4 z 17
3.3.1.2 Interfejsy 3.3.1.3 Konfiguracja 3.3.1.4 Wymagania 3.3.1.5 Zakres danych 3.3.1.6 Możliwe błędy 3.3.2 Serwer poczty elektronicznej 3.3.2.1 Zakres integracji 3.3.2.2 Interfejsy 3.3.2.3 Konfiguracja 3.3.2.4 3.3.2.4. Wymagania 3.3.2.5 3.3.2.5. Zakres danych 3.3.2.6 3.3.2.6. Możliwe błędy 3.3.3 Active Directory 3.3.3.1 Zakres integracji 3.3.3.2 Interfejsy 3.3.3.3 Konfiguracja 3.3.3.4 Wymagania 3.3.3.5 Zakres danych 3.3.3.6 Możliwe błędy 3.3.4 Backup 3.3.4.1 Zakres integracji 3.3.4.2 Interfejsy 3.3.4.3 Wymagania 3.4 Architektura Systemu 3.4.1 Otoczenie biznesowe 3.4.2 Architektura logiczna 3.4.3 Architektura fizyczna 3.4.3.1 Wymagania dla architektury fizycznej 3.4.3.2 Koncepcja architektury 3.4.3.3 Sposób instalacji i konfiguracji narzędzi dodatkowych 3.4.3.4 Konfiguracja maszyn wirtualnych 3.4.4 Bezpieczeństwo 3.4.4.1 Kontrola dostępu 3.4.4.2 Uwierzytelnianie str. 5 z 17
3.4.4.3 Rozliczalność 3.4.4.4 Poufność 3.4.4.5 Integralność 3.4.4.6 Dostępność 3.4.5 Projekt bazy danych 3.5 Procedury utrzymania Systemu 3.5.1 Obsługa błędów 3.5.2 Kopie zapasowe 3.5.3 Procedury utrzymania 3.5.4 Procedury postępowania po awarii Systemu 3.5.5 Procedury konserwacji Systemu 3.6 Testy 3.7 Możliwości rozwoju Systemu 3.7.1 Rozwój i tworzenie nowych procesów 3.7.2 Integracje 3.7.3 Raportowanie 3.7.4 Rozwój z wykorzystaniem dostarczanego API 3.7.5 Skalowanie wydajnościowe sprzętu 3.8 Lista zagadnień do zrealizowania w kolejnych fazach i etapach rozwoju Systemu 3.9 Dokumentacja powykonawcza 3.10 Spis rysunków 3.11 Modyfikacje III) System po wdrożeniu ma spełniać rolę: 1. Centralnego repozytorium (lokalnych repozytoriów) wiedzy o działaniach o charakterze projektowym w CPI, 2. Centralnego repozytorium dokumentów projektowych, 3. Centralnego repozytorium wiedzy o zajętości/dostępności pracowników zaangażowanie/obciążenie pracowników w prace projektowe, 4. Narzędzia do wielowymiarowego raportowania umożliwiającego m.in. śledzenie postępów w realizowanych projektach poprzez m.in. dedykowane raporty przedstawiające poziom zaawansowania projektów z uwzględnieniem takich aspektów jak: harmonogram, ryzyka, budżet, zasoby; 5. Narzędzi wspierającego ustalanie priorytetów dla realizacji projektów oraz optymalizację portfela projektów, analizę różnych scenariuszy. IV) System po wdrożeniu ma zapewnić w szczególności: str. 6 z 17
1. Rejestrowanie i planowanie przedsięwzięć projektowych, o różnej charakterystyce. W tym celu powinny być dostępne zdefiniowane szablony przepływów workflow dla projektów różnego typu. Zakres i typy szablonów zostaną określone w Projekcie Technicznym po uzgodnieniu z Zamawiającym. 2. Funkcjonowanie w Systemie takich dokumentów jak: Karta Projektu, Raport Okresowy, Wniosek Projektowy o Decyzję, Raport Zamknięcia Projektu, Miesięczny Rejestr Projektów dane potrzebne do przygotowania tych dokumentów powinny być wprowadzone do Systemu. Dokumenty powinny być generowane z Systemu EPM do postaci PDF, Word, Excel, PowerPoint, itp. w odpowiedniej oprawie graficznej. 3. Zarządzanie inicjatywami: 3.1 Zgłaszanie inicjatywy projektowej, 3.2 Opiniowanie inicjatywy projektowej, 3.3 Rejestrowanie, weryfikacje, priorytetyzacje inicjatyw projektowych, 3.4 Uruchomienie inicjatywy projektowej powoływanie projektu, 3.5 Wygenerowanie raportu rocznego z portfela projektów 4. Zarządzanie projektami, cyklem życia projektu, w tym określanie ogólnej kondycji projektu oraz kondycji projektu w poszczególnych obszarach, takich jak w szczególności: czas, budżet zakres, ryzyka. Możliwość określenia kondycji projektu według oceny Kierownika Projektu, oraz automatyczna ocena przy określonych parametrach (KPI- Key Performance Indicators Kluczowe Wskaźniki Efektywności) dokonywana przez System, 5. Harmonogramowanie projektów, 6. Rejestrowanie i harmonogramowanie procedur przetargowych poprzez w szczególności: wskazanie identyfikatora procedury przetargowej, pozycji w planie zamówień publicznych, możliwość skorzystania z gotowego szablonu (przygotowanego przez Wykonawcę) harmonogramu procedury przetargowej określającego jej kluczowe punkty kontrolne (np. powołana komisja przetargowa, opublikowane ogłoszenie/siwz, otwarte wnioski/oferty, ogłoszony wynik, ogłoszony wybór oferty najkorzystniejszej, zawarta umowa, KIO itp.), przypisywanie zasobów i budżetów. 7. Planowanie i harmonogramowanie budżetu projektu (m.in. wielowalutowość, klasyfikacja budżetowa: zadania, rozdziały, paragrafy, lata, środki inwestycyjne, środki bieżące, pozycja w planie zamówień publicznych, wykonanie (poniesione), planowane, klasyfikacja w układzie budżetu zadaniowego (działanie), sumowanie po wszystkich ww. klasyfikacjach). Plan budżetu projektu powinien być zsynchronizowany z harmonogramem projektu, aby zmiany w harmonogramie projektu automatycznie przekładały się na zmiany w harmonogramie budżetu (zmiany w harmonogramie budżetu mające wpływ na rozliczenia roczne, powinny automatycznie być eskalowane do zdefiniowanych osób). Rozwiązanie pozwalające na planowanie i zarządzanie finansami oraz korzyściami projektów powinno: 7.1 Pozwalać na planowanie i monitorowanie kosztów oraz korzyści projektowych. 7.2 Pozwalać na definiowanie drzewiastych struktur kosztów. 7.3 Pozwalać na definiowanie centrów powstawania kosztowych. str. 7 z 17
7.4 Pozwalać na monitorowanie rzeczywistych kosztów projektu i porównywanie ich z wcześniej zdefiniowanymi planami. 7.5 Pozwalać na realizację ww. działań co najmniej 50 użytkownikom. 7.6 Być zintegrowane z centralnym serwerem projektów, co w szczególności oznacza: 7.6.1 Administracja ustawieniami z poziomu centralnego serwera projektów. 7.6.2 Zarządzanie uprawnieniami do części finansowej z interfejsu centralnego serwera projektów. 7.6.3 Interfejs użytkownika wspólny z interfejsem centralnego serwera projektów dla użytkownika końcowego moduł finansowy musi być wyświetlany i zachowywać się jak integralna część centralnego serwera projektów (integracja z wstążką, stronami projektu, itp.) 7.6.4 Integracja z przepływem pracy dla projektów w centralnym serwerze projektów polegająca na: 7.6.4.1 Możliwości definiowania granulacji danych finansowych gromadzonych na poszczególnych etapach / fazach cyklu życia projektu. 7.6.4.2 Możliwość definiowania czy w danym etapie cyklu życia projektu dane finansowe dostępne są do odczytu czy zapisu. 7.6.4.3 Możliwość definiowania czy na danym etapie cyklu życia projektu gromadzone dane finansowe stanowią plan czy rzeczywiste wykonanie. 7.6.4.4 Wszystkie powyższe czynności powinny być zarządzane z interfejsu administracyjnego. 8. Zarządzanie ryzykami i problemami (zagadnieniami), w tym możliwość zarejestrowania ich w Systemie określając w szczególności: 8.1 Identyfikator, 8.2 Typ np.: ryzyko, problem, 8.3 Rodzaj np. projektowe, portfelowe, operacyjne, strategiczne, 8.4 Kategoria np. finansowe, organizacyjne, prawne, techniczne, zewnętrzne, inne; 8.5 Zgłaszający, data zgłoszenia, data zamknięcia, 8.6 Opis: powód/przyczyna, zdarzenie, wpływ; 8.7 Funkcjonujące mechanizmy kontrolne 8.8 Terminu wystąpienia lub prawdopodobnego wystąpienia, 8.9 Ekspozycja: prawdopodobieństwo (1=niskie, 2=mało prawdopodobne, 3=średnie, 4=prawdopodobne, 5=prawie pewne, data wystąpienia), istotność oddziaływania-skutki (1=nieznaczne, 2=małe, 3=średnie, 4=wysokie, 5=bardzo wysokie, w odniesieniu do Budżetu, Harmonogramu, Zakresu); 8.10 Właściciel (możliwość przypisywania do osób odpowiedzialnych za monitorowanie i działania mitygujące), 8.11 Reakcja, str. 8 z 17
8.12 Działania zapobiegawcze (m.in.: opis, data rozpoczęcia i zakończenia działań, osoba wykonująca, koszt, stopień realizacji działań zapobiegawczych, przyczyny braku realizacji działań zapobiegawczych.); 8.13 Status (np. otwarty, zamknięty); 8.14 Powiązania z zadaniami/produktami z harmonogramu, 9. Prowadzenie rejestru doświadczeń projektowych, 10. Prowadzenie rejestru zmian, 11. Zarządzanie zasobami ludzkimi, w tym możliwość zdefiniowania struktury organizacyjnej projektu w metryce/karcie Projektu oraz wizualizacji tej struktury za pomocą diagramów. Standardowo występują następujące role w strukturze organizacyjnej projektu: 11.1 Komitet Sterujący Projektem w skład którego wchodzą: 11.1.1 Właściciel Projektu - Przewodniczący Komitetu Sterującego może pełnić jednocześnie funkcję Głównego Użytkownika i Głównego Dostawcy (jeżeli nie wskazano innych osób do pełnienia tych funkcji); 11.1.2 Główny Dostawca dopuszczalna jest sytuacja, w której Główny Dostawca jest jednocześnie Właścicielem Projektu lub Przewodniczącym Komitetu Sterującego; w uzasadnionych przypadkach może być wielu Głównych Dostawców (odpowiedzialnych za różne obszary wg kompetencji) System powinien stwarzać możliwość doprecyzowania obszaru kompetencji Głównego Dostawcy 11.1.3 Główny Użytkownik dopuszczalna jest sytuacja, w której Główny Użytkownik jest jednocześnie Właścicielem Projektu lub Przewodniczącym Komitetu Sterującego, w uzasadnionych przypadkach może być wielu Głównych Użytkowników (odpowiedzialnych za różne obszary wg kompetencji) np. ds. projektów informatycznych, technicznych, kadrowych itp.) System powinien stwarzać możliwość doprecyzowania obszaru kompetencji Głównego Użytkownika 11.2 Kierownictwo Projektu w skład którego wchodzą: 11.2.1 Kierownik Projektu; 11.2.2 Architekt Projektu ( rolę Architekta Projektu i Kierownika Projektu może pełnić ta sama osoba, może być wielu Architektów Projektu np. ds. informatycznych, technicznych, kadrowych itp. System powinien stwarzać możliwość doprecyzowania obszaru kompetencji Architekta); 11.3 Zespół projektowy kierowany przez Kierownika Projektu, w skład którego mogą wchodzić (w liczbie mnogiej): 11.3.1 Zespoły zadaniowe kierowane przez Liderów Zespołów zadaniowych, mogą podlegać bezpośrednio Kierownikowi Projektu lub Architektom 11.3.2 Lider Zespołu Zadaniowego ds. (jeżeli istnieją zespoły zadaniowe) 11.3.3 Ekspert ds... 11.3.4 Kierownik Projektu ds. 11.3.5 Analityk ds.. str. 9 z 17
11.3.6 Administrator ds.. 11.3.7 Inne role nie wchodzące w skład struktury organizacyjnej projektu (mogą to być osoby z zewnątrz CPI, może nie być ich w AD): 11.3.7.1 Doradcy 11.3.7.2 Biegli 11.3.7.3 Konsultanci 11.3.7.4 Nadzorujący 11.3.7.5 Inni System ma zapewnić możliwość przypisywania do osób realizacji zadań, możliwość przypisania do wielu osób jednego zadania. System ma zapewnić możliwość wygenerowania raportu z zadania oraz wysłania go jako załącznika do zadania pojawiającego się w Outlooku właściciela i/lub osoby wskazanej jako wykonującą zadanie. Raport powinien być aktywny, jego modyfikacja powinna aktualizować dane dot. tego zadania w Systemie. 12. Prowadzenie rejestru wniosków do decyzji. Zgłaszanie tematów projektowych wymagających decyzji Komitetu Sterującego w formie Wniosków do decyzji Komitetu Sterującego. Wnioski służą podejmowaniu decyzji w kluczowych sprawach dotyczących Projektu. System powinien umożliwić zastąpienie funkcjonowania dokumentu w formie papierowej tzn. dane służące do generowania dokumentu powinny być wprowadzane do Systemu, a następnie powinien być generowany raport w odpowiedniej oprawie graficznej. 13. Zarządzanie Portfolio projektów poprzez w szczególności możliwość ustalania różnego typu powiązań (zależności) pomiędzy projektami, możliwości dokonywania symulacji realizacji projektu w portfelu przy określonym czasie i budżecie. 14. Dostęp do dokumentacji projektu z poziomu witryny projektowej w Systemie 15. Publikowanie w Intranecie CPI raportu zawierającego wybrane informacji o projektach, takie jak opis projektu, dane kontaktowe, aktualny harmonogram, itp. Raport powinien być aktywny, tak aby publikowany raport zawierał aktualne informacje o projektach. 16. Generowanie raportów lub wyświetlania danych z poniższych zakresów: 16.1 Karty Projektu, 16.2 Okresowy, 16.3 Wniosek Projektowy o decyzję, 16.4 Raport Zamknięcia Projektu, 16.5 Miesięczny Rejestr Projektów, 16.6 z portfela projektów, 16.7 z portfela zakupów 16.8 dostawców 16.9 z powiązań pomiędzy innymi projektami str. 10 z 17
16.10 z punktu kontrolnego, 16.11 końcowy etapu, 16.12 nadzwyczajny, 16.13 zagadnień, 16.14 rejestr produktów projektowych 16.15 rejestr doświadczeń, 16.16 rejestr ryzyk, 16.17 rejestr problemów, 16.18 rejestr wniosków do decyzji, 16.19 rejestr zmian 16.20 zadania 16.21 metryki ryzyka 16.22 metryki problemu 16.23 odchyleń 16.24 końcowy projektu, 16.25 zaangażowania zasobów ludzkich 16.26 rejestr z przeglądu projektów 16.27 roczny z portfela projektów 16.28 porównawczy z ubiegłymi latami 16.29 wg statusu projektów 16.30 administracyjne (np. użytkownicy Systemu, wykorzystanie licencji) Poszczególne raporty powinny być dostępne w dowolnej konfiguracji danych poprzez użycie funkcji filtrowania po różnych parametrach i wskaźnikach (KPI- Key Performance Indicators Kluczowe Wskaźniki Efektywności), np. pokaż wszystkie projekty opóźnione o jakiś okres czasu. Możliwość generowania raportów w postaci różnego rodzaju wykresów. Raporty powinny być dostępne w zależności od poziomu uprawnień dla poszczególnych użytkowników, komórek organizacyjnych i dla centralnego PMO - biura projektów. Raporty wymienione powyżej takie jak Karta Projektu, Raport Okresowy, Wniosek Projektowy o Decyzję, Raport Zamknięcia Projektu, Miesięczny Rejestr Projektów mają być generowane z Systemu EPM do postaci PDF, Word, Excel, PowerPoint, w odpowiedniej oprawie graficznej - dane potrzebne do przygotowania tych dokumentów powinny być wprowadzone do Systemu. Przykładowy wzór jednego z tych dokumentów, stanowiący wyłącznie materiał poglądowy, stanowi załącznik do niniejszego opisu przedmiotu zamówienia. V) Wykonawca zapewni i przekaże Zamawiającemu wszelkie wymagane licencje na oprogramowanie niezbędne dla wdrożenia (lub dokona podniesienia wersji do wersji niezbędnej str. 11 z 17
dla prawidłowego funkcjonowania Systemu) i korzystania z Systemu przez użytkowników Systemu w wersji cienkiego klienta (zintegrowanego z SharePoint) i kierowników korzystających z Systemu w wersji grubego klienta (osobnego oprogramowania instalowanego na klienckich stacjach roboczych komunikującego się z centralnym serwerem projektów). Zamawiający posiada licencje na oprogramowanie MS Sharepoint Server 2007 wraz z 110 szt. licencji dostępowych w wersji Std, MS SQL Server (licencja na procesor), MS Exchange Sever 2010 wraz z licencjami dostępowymi, oraz 8 licencji na oprogramowanie MS Project Professional 2013 które planuje wykorzystać we wdrożonym Systemie o ile System zapewni taką możliwość. Wdrożony System powinien być możliwy do korzystania przez 32 użytkowników wersji cienkiego klienta i 14 użytkowników wersji grubego klienta (kierowników) W przypadku gdy posiadane przez Zamawiającego 8 licencji Project Pro 2013 będzie można wykorzystać w Systemie Wykonawca będzie musiał zapewnić 6 licencji wersji grubego klienta do łącznej liczby 14 licencji. Wersja cienkiego klienta i wersja grubego klienta powinny posiadać następującymi możliwości: Praca podstawowa Gruby klient Cienki klient Zapisywanie pliku do SharePoint Współpraca nad projektem na listach SharePoint Tworzenie projektu z list SharePoint Konwertowanie listy SharePoint do pliku Project Synchronizacja z SharePoint Publikowanie na witryny SharePoint, otrzymywanie aktualizacji zadań Planowanie projektów Pola niestandardowe Umożliwiają dodawanie własnych definicji pól Zadania aktywne/nieaktywne Przeglądanie Możliwość przeprowadzania analiz "co-jeśli" wyłączając bądź włączając zadanie Automatyczne harmonogramy bez edycji Możliwość automatycznego układania zadań Ręczne harmonogramy Możliwość sterowania definiowania zadań ręcznie Zarządzanie czasem nieprojektowym możliwość definicji czasu wolnego dla zasobów Kreator tworzenia kalendarzy Przeglądanie Pozwala łatwo utworzyć nowe kalendarze Widok Linii czasu bez edycji Wizualizacja całości projektu na jednej linii czasu Master projekty Przeglądanie Tworzenie z wielu plików projektów jednego bez edycji Edycja projektów zależnych Przeglądanie Możliwość edytowania projektów wstawionych w Master bez edycji projekcie str. 12 z 17
Tworzenie kodów WBS Przeglądanie Definiowania niestandardowych kodów Struktury podziału Prac bez edycji Właściwości Projektu Definiowanie pul i właściwości na poziomie projektu Publikowanie projektów do Project Server możliwość wysyłania do serwera w celu współpracy Planowanie w oparciu o interfejs Web Możliwość pracy z harmonogramami w przeglądarce internetowej Definiowanie elementów dostarczanych wprowadzanie zależności pomiędzy projektami związanych z dostarczanymi elementami Kalendarz organizacji Możliwość tworzenia wspólnego kalendarza dla wszystkich projektów w organizacji Pola niestandardowe organizacji Definicja niestandardowych pól do wykorzystania we wszystkich projektach organizacji Tworzenie zadań przez członków zespołu Możliwość dodania zadań do projektu przez członków zespołu Proces zarządzania projektami Definiowanie ustrukturyzowanego procesu zarządzania projektem od jego planowania, poprzez projektowanie, realizację i zamknięcie Zarządzanie zasobami Zasoby pracy, materiałowe, kosztowe oraz rodzajowe definiowanie zasobów odpowiadających potrzebom Terminarz zespołu Wizualne planowanie pracy zasobów Zasoby zespołowe Połączenie zasobów przedsiębiorstwa w zespoły dla zwiększenia efektywności rejestracji czasu Jedna pula zasobów organizacji umieszczenie wszystkich zasobów organizacji w jednym miejscu Filtrowanie zasobów po działach Łatwiejsze lokalizowanie zasobów Śledzenie zajętości zasobów Raporty pokazujące zajętość zasobów w ramach organizacji Przypisywanie wielu zasobów Możliwość przypisywania wielu zasobów do zadania Przypisywanie zasobów kosztowych i materiałowych Przeglądanie Możliwość przypisania do zadań zasobów materiałowych i bez edycji kosztowych str. 13 z 17
Zmiana przypisania zadania Przydzielenie zadania innemu członkowi zespołu Śledzenie projektu Aktualizacja zadań Ręczna aktualizacja przez PM Aktualizacja projektu przez członków zespołu Możliwość przesyłania informacji o wykonanej pracy Indywidualne witryny dla członków zespołu Zindywidualizowana praca w oparciu o interfejs Web Publikowanie grafików Rozliczanie pracy projektowej/ nie projektowej w oparciu o grafiki Kontrolowanie wpisów grafiku Możliwość sprawdzania i akceptacji przez przełożonych rozliczanej pracy Wysyłanie i aprobowanie pracy w imieniu Uzyskanie uprawnień do wysyłania zestawień pracy w imieniu osób nieobecnych Skonsolidowane widoki postępu projektów Możliwość przeglądu wszystkich prowadzonych w organizacji projektów i ich postępu Integracja raportowania czasu pracy z systemami finansowymi Możliwość integracji z zewnętrznymi systemami finansowymi Integracja z zadaniami Outlook Możliwość umieszczenia zadań do wykonania w Outlook Komunikacja z zespołem projektowym Przesyłanie automatyczne informacji o przydzielonych zadaniach Raportowanie Standardowe raportowanie Wykorzystanie gotowych raportów Centrum Raportowania analiz biznesowych Funkcjonalności do tworzenia raportów i pulpitów nawigacyjnych Proste tworzenie niestandardowych raportów Możliwość dowolnego kreowania raportów Dostarczanie raportów poprzez SharePoint Wytworzone raporty publikowane na witrynach SharePoint'a Multiwymiarowe kostki i usługi analityczne Definiowanie i budowanie kostek OLAP dla analiz i str. 14 z 17
raportowania z wieloma wymiarami zawierającymi dane projektowe związane z zadaniami, zasobami projektami i grafikami Śledzenie stanu projektów w oparciu o wskaźniki KPI Budowanie wskaźników Key Performance Indicator w celu prezentacji danych (statusu projektu, kosztów, terminów) Pulpity nawigacyjne Tworzenie pulpitów prezentujących raporty dedykowane dla określonych odbiorców Integracja z narzędziami BI Zarządzanie Programem Definicje programów Tworzenie programów (informacje podstawowe, koszty, zalety, wpływ strategiczny) Łączenie programów i projektów Połączenia projektów w jeden nadrzędny program Zarządzanie Portfelowe Definiowanie strategii organizacji Tworzenie i rozpowszechnianie czynników i wskaźników Priorytetyzacja czynników Możliwość zbudowania priorytetów projektowych zgodnie ze strategią organizacji Identyfikowanie zależności biznesowych Śledzenie zależności pomiędzy projektami wpływających na wybór i uruchomienie projektów Identyfikowanie portfela optymalnego z nałożonymi ograniczeniami Uruchamianie analiz "co-jeśli" pozwalających wybrać optymalne projekty z punktu widzenia strategii, posiadanego budżetu i innych ograniczeń Dołączanie projektów strategicznych Wymuszanie wykonania wskazanych projektów Porównywanie zapisanych analiz portfelowych Łatwe porównywanie ze sobą w predefiniowanych raportach zapisanych analiz Zarządzanie finansami Estymacje kosztów projektów Definiowanie projekcji kosztów w każdej fazie życia projektu Definicja korzyści projektowych str. 15 z 17
Definiowanie korzyści z uruchomienia projektów każdej fazie życia Wskaźniki finansowe Definiowanie wartości wskaźników finansowych (NPV, ROI, IRR, itp..) Definicja budżetów wysokiego poziomu dla Programów/ Projektów Definiowanie budżetów umożliwiające porównywanie PM aktualnych kosztów do wartości budżetowych Wsparcie dla planowania rocznych budżetów Zarządzanie wartością wypracowaną Wykorzystanie obliczeń EVA zawierających wskaźnik wydajności harmonogramu (SPI), Indeks wydajności kosztów (CPI,), wskaźnik wariancji kosztów (CV%), itp. Współpraca Witryny zespołowe Miejsce składowania dokumentów dla każdego projektu Śledzenie ryzyk i problemów projektowych Możliwość przypisywania ryzyk i problemów do zasobów Zarządzanie dokumentami projektowymi Funkcjonalność obiegu dokumentów, wersjonowania i akceptacji Wystandaryzowane dokumenty Umieszczenie w repozytorium gotowych szablonów dokumentów projektowych Wyszukiwanie dokumentów przeszukiwanie dokumentów projektowych ze wszystkich projektów VI) Interfejs Systemu musi być wdrożony w polskiej wersji językowej. VII) System musi być zgodny z ustawą z dnia 29 sierpnia 1997 r. o ochronie danych osobowych oraz aktami wykonawczymi do tej ustawy a przede wszystkim z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych. VIII) Wszystkie dokumenty wytworzone przez Wykonawcę i przekazane Zamawiającemu w ramach realizacji Zamówienia muszą być oznakowane zgodnie z zasadami określonymi w Przewodniku w zakresie promocji projektów finansowanych w ramach Programu Operacyjnego Innowacyjna Gospodarka, 2007 2013 dla beneficjentów i instytucji zaangażowanych we wdrażanie Programu IX) System powinien być zgodny z Rozporządzeniem Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych określającym protokoły komunikacyjne i szyfrujące umożliwiające wymianę danych z innymi systemami teleinformatycznymi używanymi do realizacji zadań publicznych. str. 16 z 17
X) Wdrożenie Systemu stanowi logiczne rozszerzenie funkcjonalności posiadanego przez Zamawiającego Serwera SharePoint 2007 i będzie przeprowadzone w istniejącej architekturze Zamawiającego, na tych samych serwerach co SharePoint 2007. Planuje się uruchomić System na platformie wirtualnej. Zamawiający, na podstawie projektu technicznego, przygotuje przy współpracy Wykonawcy niezbędne zasoby na środowisku wirtualnym, dostęp do tak przygotowanego środowiska zostanie przekazany Wykonawcy do dalszych prac projektowych, w tym do administrowania do czasu przekazania Systemu EPM Zamawiającemu, po podpisaniu protokołu odbioru końcowego. Administrowanie całym środowiskiem wirtualnym, w tym elementami sieciowymi w obecnie pracującym środowisku jest po stronie Zamawiającego. B. Część nr 2. Dostawa oprogramowania standardowego do modelowania architektury systemów IT. I. Szczegółowe wymagania dotyczące oprogramowania standardowego do modelowania 1. Oprogramowanie musi być narzędziem typu CASE. 2. Oprogramowanie musi umożliwiać natywny odczyt, zapis i edycję plików o rozszerzeniu EAP. 3. Oprogramowanie musi umożliwiać tworzenie diagramów w co najmniej następujących notacjach/językach: a. UML 2.x, b. BPMN, c. Archimate. 4. Oprogramowanie musi posiadać moduł wspierający zarządzanie wymaganiami użytkownika. 5. Oprogramowanie musi mieć możliwość zapisu modelu jako plik graficzny lub jako plik PDF. 6. Oprogramowanie musi umożliwiać dołączanie do modeli plików tekstowych RTF, jak również posiadać funkcjonalność śledzenia wprowadzanych do pliku RTF zmian. 7. Oprogramowanie musi umożliwiać generację plików XSD oraz WSDL na podstawie utworzonych modeli UML. 8. Oprogramowanie musi posiadać funkcjonalność generowania na podstawie modelu UML kodu np. data definition language dla baz danych SQL. 9. Oprogramowanie poprawnie działać co najmniej na systemie operacyjnym Windows 7. 10. Wykonawca musi dostarczyć 7 niewyłącznych licencji na oprogramowanie opisane w/w wymaganiami. 11. Przez okres 12 miesięcy od dnia podpisania protokołu odbioru Wykonawca zapewni Zamawiającemu dostęp do: - wszystkich aktualizacji i nowych wersji (update i upgrade) oprogramowania w zakresie wynikającym z postanowień EULA w obszarze gwarancji i wsparcia, - wsparcia technicznego świadczonego drogą e-mail oraz poprzez dostęp do dedykowanej zarejestrowanym użytkownikom oprogramowania strony WWW zawierającej co najmniej porady, tutoriale, forum. 12. Dostarczane licencje nie muszą być licencjami typu float. str. 17 z 17