Załącznik nr 1 – Specyfikacja zakresu prac. Cel Celem projektu jest

Załącznik nr 1 – Specyfikacja zakresu prac.
I.
Cel
Celem projektu jest przygotowanie i wdrożenie nowych funkcjonalności w systemie ERP
SAP 6.0 ECC związanych z modułami MM, IM-PS oraz aplikacją SEU (System Ewidencji
Umów).
II.
Stan obecny
Zamawiający posiada wdrożony system ERP SAP 6.0 ECC. w systemie tym działa
mechanizm jednokrokowego zatwierdzania Wniosków zakupowych inwestycyjnych
(zgłoszeń zapotrzebowania wg standardowego mechanizmu zatwierdzania SAP dla
pozycji dokumentu). Działa również mechanizm tworzenia różnego rodzaju wniosków
zakupowych (zgłoszeń zapotrzebowania wg SAP) oraz działa moduł/aplikacja SEU (System
Ewidencji Umów), w którym rejestrowane są umowy i aneksy do umów wraz z
odpowiednimi załącznikami. Zamawiający posiada uruchomiony system pocztowy
działający w oparciu o MS Exchange w wersji 2010 obsługujący następujące protokoły:
smtp, mapi, pop3, imap4 i http. W chwili obecnej nie posiadamy integracji SAP-Exchange
w zakresie przesyłania notyfikacji z SAP na skrzyni pocztowe.
III.
Stan docelowy
Zamawiający oczekuje rozwoju istniejących funkcjonalności systemu SAP oraz aplikacji SEU
w zakresie:
1. Przygotowania i wdrożenia rozwiązania do ewidencji kar umownych naliczonych dla
umów zaewidencjonowanych w aplikacji SEU.
2. Przygotowania i wdrożenia rozwiązania do ewidencji referencji wydanych dla
zakończonych umów zaewidencjonowanych w aplikacji SEU.
3. Przygotowania i wdrożenia rozwiązania dla oceny umów zakończonych w SEU oraz
budowania w oparciu o dokonane oceny umów Listy Wiarygodnych Dostawców.
4. Wykonania drobnych modyfikacji w SAP SEU w zakresie opisanym poniżej w treści
dokumentu
5. Przygotowania i wdrożenia rozwiązania dla prezentowania daty ważności umowy wraz z
aneksami, wartości umowy wraz z aneksami oraz pozostałej wartości umowy.
6. Przygotowania rozwiązania do tworzenia w systemie SAP Wniosków wykonawczych do
wcześniej zwartych umów ramowych – zwanych dalej Wnioskami wykonawczymi ZWZ4.
7. Modyfikacji mechanizmu pobierania danych z portalu zakupowego do aplikacji SEU
mającej na celu przekazywanie danych o umowach wykonawczych do umów
ramowych oraz modyfikacji mechanizmu importu danych umów wykonawczych do
umów ramowych z tzw. poczekalni umów (modyfikacji interfejsów obukierunkowych SAPPortal Zakupowy).
8. Dla 3 utworzonych rodzajów zamówień ZSI, ZSB, ZSM zdefiniowania jednokrokowej
strategii zatwierdzania bazującej
na standardowym mechanizmie zatwierdzania
zamówień wg SAP. Zamówienia te będą wykorzystywane wyłącznie do rozliczania umów
w statusie „Z” zakończona.
9. Wykonanie drobnych prac modyfikacyjno-rozwojowych mających na celu poprawę
czytelności danych w aplikacji SEU wraz z podmianą wszelkich wpisów Centralny Rejestr
Umów na System Ewidencji Umów (CRU na SEU).
10. Rozwoju mechanizmu akceptacji Wniosków zakupowych tworzonych w systemie SAP w
zakresie strategii zatwierdzania ich z wykorzystaniem rozwiązań SAP. Strategią
zatwierdzania mają być objęte następujące rodzaje Wniosków zakupowych:
10.1.
Wnioski do Planu Zamówień ZWZ1
10.2.
Wnioski Poza Planem Zamówień ZWZ2
10.3.
Wnioski bieżące ZWZ3
10.4.
Wnioski Wykonawcze do Umów Ramowych ZWZ4
10.5.
Wnioski – Zobowiązania pozostałe ZPS
11. Zintegrowania systemu SAP z pocztą korporacyjną. Notyfikacje e-mailowe powinny być
ustawione dla punktów 3.5, 3.6, 3.8, 3.9 OPZ. Notyfikacje e-mail będą trafiać na e-maila
odpowiednich użytkowników wraz z linkiem, po wciśnięciu którego nastąpi otwarcie okna
SAP w odpowiednim miejscu (widoku).
IV.
Przedmiot Zamówienia
1. Wymagania ogólne:
1.1. Przedmiotem zamówienia jest wykonanie prac konfiguracyjnych i programistycznych
w systemie SAP, które pozwolą na wykonywanie czynności i operacji wymienionych i
opisanych poniżej w dokumencie.
1.2. Wszystkie wykonywane zmiany powinny być kompatybilne z już istniejącymi
rozwiązaniami.
1.3. Przygotowywane rozwiązania powinny dawać możliwość zmiany parametrów
aplikacji przez zamawiającego (możliwość parametryzacji aplikacji przez
zamawiającego).
1.4. W zakresie strategii zatwierdzania Wniosków zakupowych rozwiązanie powinno
bazować na standardzie SAP dotyczącym mechanizmu startegii zatwierdzania dla
zgłoszeń zapotrzebowania wraz z niezbędnymi modyfikacjami.
2. Zakres prac wymagany dla każdego z rozwiązań
2.1. Przygotowanie funkcjonalnego i technicznego projektu rozwiązania, zawierającego:
2.1.1.Opis funkcjonalny rozwiązania i konfigurację techniczną dla docelowego
rozwiązania
2.1.2.Scenariusze testów akceptacyjnych,
2.1.3.Harmonogram prac w MS Project,
2.1.4.Projekt ma być wykonany i zatwierdzony w ciągu 8 tygodni od dnia podpisania
Umowy. Dokumentacja powykonawcza musi być dostarczona w postaci:
 dokumentu papierowego lub pliku /plików elektronicznych na dowolnym
standardowym nośniku optycznym (cd/dvd/br) lub pendrive z możliwością
ich odczytu w programie Adobe Reader (pliki zapisane w formacie PDF)
 zapisów i plików zgromadzonych w systemie SQA
2.1.5.Kolejność wykonywania prac zostanie opisana w projekcie technicznym. Jest
ona uzależniona od potrzeb Zamawiającego.
2.2. Wdrożenie produkcyjne
2.2.1.Asysta przy testach akceptacyjnych dostarczonego rozwiązania
2.2.2.Przygotowanie planu startu produkcyjnego i przygotowanie do startu
produkcyjnego
2.2.3.Wsparcie przy starcie produkcyjnym
2.2.4.Wdrożenie produkcyjne zostanie wykonane nie później niż 30 tygodni od dnia
podpisania Umowy
2.3. Dokumentacja powykonawcza
Dostarczenie kompletnej dokumentacji powykonawczej rozwiązania, zawierającej:
2.3.1.Opis wdrożonego rozwiązania z uwzględnieniem jego komponentów, ich
konfiguracji i wzajemnych powiązań
2.3.2.Dokumentację użytkową w tym instrukcje stanowiskowe i kursy e-learning
przygotowane w oparciu o RWD uPerform
2.3.3.Dokumentację administracyjną
2.3.4.Dokumentację testów obejmującą scenariusze testów wraz z przebiegiem
realizacji i protokołem zawierającym wyniki testów
2.3.5.Dokumentacja powykonawcza musi być dostarczona w postaci:
 dokumentu papierowego lub pliku /plików elektronicznych na dowolnym
standardowym nośniku optycznym (cd/dvd/br) lub pendrive z możliwością
ich odczytu w programie Adobe Reader (pliki zapisane w formacie PDF)
 zapisów i plików zgromadzonych w systemie SQA
3. Zakres wdrożenia
3.1. Wdrożenie obejmuje:
3.1.1.Przygotowania rozwiązania, które prezentować będzie dodatkowe dane w
aplikacji SAP SEU tj.
- Wartość umowy wraz z aneksami,
- Pozostała wartość umowy (pole prezentujące pozostałą do realizacji wartość
umowy wraz z aneksami.
- Data ważności umowy wraz z aneksami.
3.1.2.Przygotowanie aplikacji jako elementu składowego SAP SEU w zakresie
mechanizmu ewidencji kar umownych wraz z wymaganymi raportami oraz
systemem kontroli uprawnień
3.1.3.Przygotowanie aplikacji jako elementu składowego SAP SEU w zakresie
mechanizmu ewidencji referencji wydanych przez Spółkę dla zrealizowanych
umów na rzecz GAZ-SYSTEM S.A. wraz z wymaganymi raportami oraz systemem
kontroli uprawnień
3.1.4.Wykonanie drobnych prac rozwojowych dotyczących aplikacji SAP SEU, w
zakresie już istniejących funkcjonalności.
3.1.5.Wykonanie mechanizmu tworzenia Wniosków wykonawczych
ramowych wraz ze wszelkimi mechanizmami kontrolnymi.
do
umów
3.1.6.Przygotowanie aplikacji SORU do oceny umów zrealizowanych dla GAZ-SYSTEM
S.A. zewidencjonowanych w aplikacji SEU wraz ze wszelkimi mechanizmami
kontroli uprawnień oraz systemem raportowania.
3.1.7.Przygotowania mechanizmu strategii zatwierdzania dla Wniosków zakupowych
wraz z mechanizmami kontroli budżetów.
3.1.8.Przygotowanie mechanizmów workflow dla elementów systemu wczesnego
ostrzegania o zbliżających się terminach ważności umów oraz o zbliżających się
progach wykorzystania kontraktów zakupowych.
3.1.9.Zmodyfikowanie mechanizmów wykorzystywanych do pobierania danych z
portalu zakupowego odnośnie danych umów wykonawczych oraz
importowania danych tych umów z poczekalni do aplikacji SEU oraz
mechanizmu zwrotu danych o zaewidencjonowanych umowach w SEU do
Portalu zakupowego.
3.1.10. Utworzenie nowej transakcji ZSEU zastępującej obecną transakcję ZCRU.
3.1.11. Wykonanie wszystkich modyfikacji w aplikacji SEU mających na celu
zastąpienie wpisów Centralny Rejestr Umów na System Ewidencji Umów.
3.2. Wymagania dla rozwiązania prezentowania danych dodatkowych w aplikacji SEU
3.2.1
3.2.2
3.2.3
Wartość umowy wraz z aneksami – w polu tym powinna być prezentowana
wartość umowy wraz ze wszystkimi aneksami do niej, której mają wpływ na zmianę
wartości umowy (aneksy zwiększające lub zmniejszające kwotę umowy)
Pozostała wartość umowy (pole prezentujące pozostałą do realizacji wartość
umowy wraz z aneksami. Wartość tego pola będzie wyliczana poprzez odjęcie od
„Wartości umowy z aneksami” sumy wartości wszystkich dokumentów zamówień
zakupowych. Każda zmiana kwoty w zamówieniu będzie powodowała
aktualizację Pozostałej kwoty umowy. W przypadku umów ramowych, w polu tym
ma być prezentowana kwota pozostała do wykorzystania z tej umowy, pod
odjęciu sumy wartości umów wykonawczych zaewidencjonowanych w referencji
do umowy ramowej. W przypadku umów wykonawczych w polu tym powinna
być prezentowana kwota wyliczana w sposób analogiczny jak dla umów
zwykłych. W przypadku umów tzw. Licznikowych/stawka w polu tym powinna być
prezentowana suma wartości zamówień utworzona w referencji do tej umowy.
Może być to rozwiązane poprzez dodatkowe pole w tej sekcji, które będzie się
pojawiać tylko dla umów licznikowych/stawka).
Data ważności umowy wraz z aneksami – e polu tym powinna być prezentowana
data ważności umowy wraz z aneksami, które mają wpływ na zmianę daty
ważności, wydłużenie lub skrócenie terminu ważności umowy. Wyróżnikiem będzie
tu pole wskaźnikowe „Zakończenie umowy”.
3.3 Wymagania dla aplikacji Ewidencji Kar Umownych w SEU
3.3.1
Aplikacja musi wspierać proces ewidencji kar umownych naliczonych dla
dostawcy/-ów z umowy na skutek nierzetelnego wykonania przedmiotu
umowy.
3.3.2
Aplikacja musi być uruchamiana z poziomu wybranej umowy w aplikacji SEU.
3.3.3
Ewidencja nowej kary musi być inicjowana poprzez mechanizm importu
danych z tzw. poczekalni dla naliczonych kar umownych lub w wyjątkowych
sytuacjach poprzez operację dodaj nową karę umowną Podczas ewidencji
danych nowej kary umownej aplikacja musi zezwalać na uzupełnienie danych
dotyczących daty naliczenia kary, kwoty naliczonej kary, opisu naliczonej kary,
nr noty obciążeniowej, ewentualnie dodatkowe uwagi. W przypadku
importowania danych z tzw. poczekalni, dane te powinny być pobierane z
poczekalni.
3.3.4
Podczas ewidencji danych nowej kary umownej aplikacja musi numerować
kary w sposób automatyczny na podstawie przypisanego zakresu numerów.
3.3.5
Podczas ewidencji danych nowej kary umownej aplikacja musi dokonywać
powiązania (referencji) kary do umowy.
3.3.6
Aplikacja powinna zapewniać ewidencję historii czynności na danej karze
(takich jak np. data zapłaconej kary, kwota wpłaconej kary) oraz
korespondencję dotycząca zmian w naliczonej karze.
3.3.7
Aplikacja powinna zapewniać ewidencję statusów dla kary oraz zmianę
statusu w zależności od zarejestrowanej czynności w systemie.
3.3.8
Aplikacja powinna posiadać możliwość
zaewidencjonowanej kary umownej.
3.3.9
Aplikacja powinna posiadać system kontroli uprawnień do wykonywania w
niej czynności takich jak: dodawanie, zmiana, wyświetlanie czy usuwanie
danych
kary
lub
zaewidencjonowanych
czynności
dotyczących
historii/korespondencji dla danej kary.
dodawania
załączników
3.3.10 Aplikacja
powinna
zapewniać
możliwość
rozwijania
(wykorzystywanych w aplikacji) przez zamawiającego.
dla
słowników
3.3.11 Aplikacja
powinna
pozwalać
na
przeglądanie
kar
umownych
zaewidencjonowanych dla umów w SEU z poziomu transakcji do obsługi
danych podstawowych dostawcy tj. MK02, MK03, Xk02, XK03, FK02, FK03. Z
poziomu tych transakcji ma być widoczny tylko sam rejestr kar bez możliwości
zmian.
3.3.12
Aplikacja
powinna
posiadać
możliwość
sporządzenia
raportu o
zaewidencjonowanych karach umownych wg zadanych parametrów, np.
daty naliczenia kary, status kary, kwota kary . Raport powinien bazować na
raporcie dla umów i aneksów. Raport powinien być przygotowany jako układ
z siatką ALV z możliwością eksportu danych do np. Excel..
3.3.13 Aplikacja powinna posiadać możliwość zbierania (eksportu) danych o
wystawionych notach uznaniowych wg zadanych parametrów dla rodzaju
noty i umieszczania tych danych w tzw. poczekalni.
3.3.14 Aplikacja powinna posiadać mechanizm tzw. importu danych kary umownej
na podstawie wystawionych not uznaniowych. Mechanizm ten powinien być
powiązany z czynnością ewidencji nowej kary umownej.
3.4 Wymagania dla aplikacji Rejestr referencji wydanych przez Spółkę
3.4.1
Aplikacja musi wspierać proces rejestrowania referencji wydanych przez
spółkę na rzecz podmiotów realizujących przedmiot umowy zarejestrowanej w
aplikacji/module SEU.
3.4.2
Aplikacja musi być uruchamiana z poziomu wybranej umowy w aplikacji SEU.
3.4.3
Ewidencja nowej referencji musi być inicjowana poprzez operację dodaj
nową referencję.
3.4.4
Podczas ewidencji danych nowej referencji aplikacja musi zezwalać na
uzupełnienie danych dotyczących daty wydania referencji, nr pisma w
sprawie, dane osoby, która podpisała referencję.
3.4.5
Podczas ewidencji danych nowej referencji aplikacja musi numerować
referencje w sposób automatyczny na podstawie przypisanego zakresu
numerów.
3.4.6
Aplikacja powinna posiadać
zaewidencjonowanej referencji.
3.4.7
Aplikacja
powinna
posiadać
możliwość
sporządzenia
raportu
o
zaewidencjonowanych wydanych referencjach wg zadanych parametrów,
np. data wydania referencji. Raport powinien bazować na raporcie dla umów
i aneksów przygotowany w aplikacji SEU. Raport powinien być przygotowany
jako układ z siatką ALV z możliwością eksportowania do Excel.
3.4.8
Dane o zaewidencjonowanych referencjach powinny być również widoczne z
poziomu transakcji do obsługi danych podstawowych dostawcy tj. MK02,
MK03, XK02, XK03, FK02, FK03. Z poziomu tych transakcji ma być widoczny tylko
sam rejestr wydanych referencji bez możliwości zmian.
możliwość
dodawania
załączników
dla
3.5 Wymagania dla obsługi zdefiniowanych nowych rodzajów zamówień
3.5.1
Dla nowozdefiniowanych rodzajów zamówień (ZSB, ZSI, ZSP) powinien być
przygotowany mechanizm 1 krokowej akceptacji wg standardu SAP.
3.5.2
Dla mechanizmu zatwierdzania zdefiniowanych zamówień powinien być
zdefiniowany mechanizm workflow do powiadomień w SAP o operacjach
wykonanych na zamówieniu, tj. zatwierdzenie lub odrzucenie.
3.5.3
Dla zdefiniowanych zamówień powinien być przygotowany mechanizm
zezwalający na powiązanie ich z umowami zaewidencjonowanymi w SEU
(zakładka Dane SEU) ale tylko w stanie „zakończona”. Modyfikacja już
funkcjonującego mechanizmu.
3.6 Wymagania dla drobnych prac rozwojowych w SEU
3.6.1
Drobne prace rozwojowe dotyczące aplikacji SEU obejmować będą zarówno
prace modyfikacyjne – poprawa drobnych błędów jak i rozwojowe. Zakres
tych prac przedstawia się następująco:
lp
SEKCJA
ZAKRES
1
TREŚĆ
Widok przedmiotu umowy- rozszerzenie widoczności
pola na wszystkie znaki
2
UWAGI
Widok uwagiwszystkie znaki
3
Kontrahent
4
PODPISAŁ
5
IDENTYFIKACJA
6
ADMINISTRACJA - osoba
odpowiedzialna/ podpisał
7
ADMINISTRACJA - osoba
odpowiedzialna
widoczności
pola
na
Dla pól Dostawca/Odbiorca prezentowanie nazwy tak
samo jak w raporcie, tj. dane z linii pierwszej i drugiej dla
nazwy z danych dostawcy/odbiorcy
Widok
numeru
pełnomocnictwarozszerzenie
widoczności pola na wszystkie znaki
Wyświetlanie nazw elementu PSP – krótki opis dla
elementu PSP
Wyświetlanie
imion
osób
podpisujących
i
odpowiedzialnych za realizację umowy
Zmiana nazwy osoba odpowiedzialna na osoba
odpowiedzialna za realizację umowy, dodanie kolumny
z opisem L.p. (Liczba porządkowa). Pole powinno
pozwalać na wpisywanie liczby porządkowej i
sortowanie danych wg tego pola.
Powiadomienia mailowe do osób wskazanych jako
odpowiedzialne za realizację umowy w momencie
zatwierdzenia umowy w SEU
8
ELEMENTY DODATKOWE
9
10
ZAŁACZNIKI
11
rozszerzenie
Powiadomienia mailowe o zbliżającym się terminie
realizacji umowy wysyłane do osób odpowiedzialnych
za realizację umowy. Należy przewidzieć możliwość
definiowania parametru z liczbą dni, na podstawie
którego będzie wysłane powiadomienie do użytkownika
jak również wskazanie dla jakich umów ma być
wysyłane powiadomienie.
Wyświetlanie nazw załączników poprzez rozwinięcie
katalogu z załącznikami (nazwy załączników widoczne
są dopiero po wklikaniu się w katalog, a powinny być
widoczne w momencie rozwijania zawartości katalogu).
Dodanie kolumny nazwa pliku w ekranie przeglądu
załączników.
Umożliwienie powrotu do wpisu o umowie po wklikaniu
się w folder załączników i skorzystaniu z opcji powrotu.
Obecnie przy próbie powrotu po wklikaniu się w folder
12
Wskaźnik obowiązku
utworzenia kontraktu do
umowy
13
Wskaźnik Umowa
licznikowa/stawka
14
Wskaźniki dla aneksów:
Rozwiązanie
umowy/Odstąpienie od
umowy
15
Historia zmian w MPK
załączników, system przekierowuje użytkownika do
transakcji ZCRU (wycofujemy się z przetwarzanej/
przeglądanej umowy)
W sekcji Charakter umowy należy dodać pole typu
„check box” – z opisem „Kontrakt wymagany”. Pole to
powinno być automatycznie zaznaczane w momencie
rejestrowania nowej umowy ze wskaźnikiem „Charakter
ramowy”.. Użytkownik rejestrujący umowę nie ma
możliwości zdjęcia tego wskaźnika. Wskaźnik może
zostać zdjęty wyłącznie poprzez osobę dokonującą
zatwierdzenia umowy w SEU. Po zatwierdzeniu umowy w
SEU, prawo zdjęcia wskaźnika będzie pozostawało w
gestii osoby, która posiada stosowne uprawnienia w
systemie – czyli zgodę na zmiany w umowach
zatwierdzonych.
Dodatkowo należy przygotować mechanizm kontrolny.
Mechanizm ten będzie miał za zadanie w momencie
tworzenia lub edycji zamówienia (zapis zamówienia lub
użycia ikony „Kontrola” powiązanego z umową)
sprawdzenie w danych umowy SEU czy ma ona
przypisany wskaźnik „Kontrakt wymagany”. Jeżeli tak to
powinna nastąpić weryfikacja czy każda z pozycji w
dokumencie zamówienia jest powiązana z pozycją
kontraktu. Jeżeli przynajmniej jedna pozycja w
zamówieniu nie jest powiązana z pozycją kontraktu, nie
jest możliwe zapisanie zamówienia leczy jedynie jego
zachowanie (tylko w przypadku tworzenia nowego
zamówienia). Dopóki zamówienie nie ma przypisanych
pozycji kontraktu nie jest możliwe jego zapamiętanie.
W sekcji Charakter umowy należy dodać pole typu
„check box” – z opisem „U. Licznikowa/Stawka”. Pole to
powinno być zaznaczane przez użytkownika w
momencie rejestrowania nowej umowy, tylko dla umów,
które nie mają zdefiniowanej wartości progowej, zwykle
są to umowy z wartością 1 zł.
Dodanie 2 nowych wskaźników dla rejestrowanych
aneksów, które będą wskazywały na Rozwiązanie
umowy lub Odstąpienie od Umowy. Pola te powinny
być dodane również w raporcie o umowach i
aneksach.
Dodanie funkcjonalności, która pozwalać będzie na
prezentowanie danych MPK z uwzględnieniem zmian
czasowych. tj. jeżeli w danych MPK zostaną
wprowadzone zmiany np. z opisem, które są zależne od
daty, to w danych umów i aneksów powinna być
zachowana historyczność zmian. Umowy sprzed zmiany
opisu MPK powinny mieć stary opis, a umowy i aneksy
po zmianie nazwy – nowy opis.
3.7 Wymagania obsługi Wniosków Wykonawczych do Umów Ramowych
3.7.1
Wnioski zakupowe do planu zamówień i poza planem zamówień powinny
posiadać wskaźnik „Umowa ramowa”.
3.7.2
Wskaźnik „Umowa ramowa” powinien być kopiowany do wszystkich pozycji
wniosku zakupowego.
3.7.3
Dla pozycji wniosku zakupowego z ustawionym wskaźnikiem „Umowa
ramowa” powinien zostać przygotowany mechanizm, który będzie
automatycznie blokował możliwość przetwarzania pozycji dokumentu w
dalsze dokumenty zakupowe.
3.7.4
Mechanizm automatycznego ustawiania wskaźnika
sprawdzać zgodność ze wskaźnikiem „Umowa ramowa”.
3.7.5
Wnioski zakupowe bez zgodności wskaźników „Umowa ramowa” i „Zamknięte”
nie będą możliwe do zapisania.
3.7.6
Wnioski zakupowe ze wskaźnikami „Umowa ramowa” powinny po zakończeniu
procesu przetargowego zostać uzupełnione o wybrane dane umowy
zaewidencjonowanej w SEU (mechanizm automatyczny przekazujący dane w
momencie zatwierdzenia zaewidencjonowanej umowy w SEU. Dane o umowie
powinny być również przekazywane do Portalu zakupowego).
3.7.7
Wnioski wykonawcze do umów ramowych powinny być
zgłoszeniach zapotrzebowania jako nowy rodzaj dokumentu.
3.7.8
Procedura tworzenia wniosków wykonawczych powinna bazować na
funkcjonalności kopiowania danych z wniosków o umowę ramową, zarówno
do planu zamówień jak i poza planem zamówień.
3.7.9
Wnioski zakupowe wykonawcze powinny być możliwe do utworzenia tylko w
odniesieniu do wniosków ze wskaźnikiem „Umowa ramowa”
„Zamknięte”
oparte
musi
na
3.7.10 Wnioski wykonawcze do umowy ramowej powinny zawierać informacje o
numerze umowy ramowej zaewidencjonowanej w SAP SEU, dane o
przedmiocie umowy, kwocie umowy, dane dostawcy oraz rodzaju
postępowania i numerze postępowania. Powinny one tworzyć obligo
finansowe.
3.7.11 W trakcie tworzenia wniosków wykonawczych do umowy ramowej powinna
być wykonywana kontrola na kwotę umowy ramowej.
3.7.12 Kontrola powinna blokować możliwości utworzenia kolejnego wniosku
wykonawczego, jeżeli została przekroczona wartość umowy ramowej
(mechanizm ten powinien kontrolować wartość wniosku wykonawczego z
wartością w polu „Pozostała wartość do wykorzystania” w umowie ramowej
3.7.13 Podczas zapisywania wniosku lub zapisywania zmian na wartościach we
wniosku i jego pozycjach powinna następować kontrola czy nie została
przekroczona pozostała wartość do wykorzystania z umowy ramowej
3.7.14 Proces zapisu wniosku wykonawczego do umowy ramowej powinien czyścić
powiązania z planem zamówień.
3.7.15 Dla wniosków wykonawczych do umów ramowych należy przygotować
dodatkowe reżimy prawne oraz tryby postępowania.
3.7.16 Dla obsługi procesu tworzenia wniosków wykonawczych do umów ramowych
należy dokonać niezbędnych modyfikacji w istniejących interfejsach tj. SAPPortal zakupowy w zakresie danych z wniosków, Portal Zakupowy -SAP w
zakresie danych o zawartych umowach oraz mechanizm importu danych o
umowach. Dane o umowach wykonawczych podpisanych w wyniku
zakończonych postępowań powinny być przekazywane do poczekalni umów
a stamtąd powinny być możliwe do zaimportowania w aplikacji SEU.
3.8 Wymagania dla rozwiązania do oceny umów SEU (dedykowana aplikacja)
3.8.1
Aplikacja musi wspierać proces oceny umów zaewidencjonowanych w
aplikacji SEU, które zostały zakończone (zrealizowane).
3.8.2
Aplikacja musi być powiązana z aplikacją do ewidencji umów SEU.
3.8.3
Aplikacja musi posiadać elementy konfiguracji możliwe do wykonania przez
administratora aplikacji, takie jak:
3.8.3.1
Lista kategorii zakupowych podlegających ocenie w umowach – lista
kategorii powinna być definiowana dla każdego roku oddzielnie.
3.8.3.2
Lista cech podlegających ocenie wraz z przypisaniem im wag.
3.8.3.3
Lista parametrów do wysyłania monitów przypominających o wykonaniu
określonej czynności w ocenie umowy (parametr w postaci liczby dni).
3.8.3.4
Lista parametrów do komunikacji wewnętrznej w SAP, komunikaty
wewnętrzne w SAP dla zdarzeń z procesu oceny umowy.
3.8.3.5
Lista parametrów definiowania liczby pozycji na liście rankingowej
dostawców.
3.8.3.6
Lista parametrów do oceny okresowej dostawcy – parametry do
mechanizmu oceny okresowej dostawcy.
3.8.4
Aplikacja do oceny realizacji umów ma za zadanie gromadzić dane o ocenie
każdej umowy w następującym zakresie:
- Kolejny numer oceny – numer systemowy,
- Nr umowy SEU,
- Nr dostawcy SAP,
- Pełna nazwa dostawcy SAP,
- Data obowiązywania umowy od …,
- Data obowiązywania umowy do… (wraz z aneksami)
- Wartość umowy wraz z aneksami,
- Przedmiot umowy,
- Kategoria zakupowa - kod konsolidacyjny z umowy wraz z opisem (krótki
tekst materiału),
- Data zarejestrowania wpisu – data systemowa,
- Osoba odpowiedzialna za ocenę umowy,
- Data oceny umowy – data przekazania umowy do zatwierdzenia przez
Dyrektora,- Data zatwierdzenia oceny – data zaakceptowania oceny przez
Dyrektora.
- Status oceny umowy,
- Przypisane cechy oceny umowy,
- Ocena umowy – sumaryczna liczba punktów uzyskanych z cech
podlegających ocenie w danym roku.
- Komentarz – pole tekstowe,
- Okres do oceny okresowej dostawcy – data w formacie MM.RRRR
3.8.5
Przekazywanie danych o umowie do oceny powinno być wywoływane z
aplikacji do ewidencji umów, na podstawie pola w umowie „Data ważności
wraz z aneksami”.
3.8.6
Przekazywanie danych o umowie do oceny powinno następować
następnego dnia kalendarzowego po dacie ważności w polu opisanym w
punkcie powyżej.
3.8.7
Razem z mechanizmem przekazywania danych umowy do oceny (do
dedykowanej aplikacji)
powinien być przekazywany komunikat to
użytkownika o konieczności dokonania oceny umowy.
3.8.8
Komunikat powinien być wysyłany za pomocą wewnętrznej poczty SAP.
Należy również przygotować mechanizm połączenia z pocztą korporacyjną w
spółce, który wysyłałby powiadomienie na e-mail użytkownika wraz z linkiem,
za pomocą którego następowałoby przejście do właściwej czynności w SAP.
3.8.9
Z poziomu wysłanego komunikatu z numerem umowy do oceny powinien być
wysyłany link do aplikacji z oceną wskazanej umowy.
3.8.10 Dane ocenionej umowy powinny być zapisane i możliwe do zmiany we
właściwym statusie dokumentu (mechanizm kontroli uprawnień)
3.8.11 Po dokonaniu oceny umowy i jej zapisaniu użytkownik powinien mieć
możliwość skierowania oceny umowy do zatwierdzenia przez ustalonego
przełożonego (ustalenie konfiguracyjne mechanizmu workflow).
3.8.12 Z poziomu aplikacji powinien zostać wysłany komunikat do przełożonego o
konieczności dokonania zatwierdzenia oceny.
3.8.13 W przypadku potrzeby dokonania korekty oceny przełożony powinien mieć
możliwość modyfikacji oceny.
3.8.14 Po zatwierdzeniu oceny przez przełożonego powinien być wysyłany komunikat
do osoby odpowiedzialnej za umowę o zakończeniu procesu oceny realizacji
umowy.
3.8.15 Podczas zatwierdzania oceny umowy na podstawie daty zatwierdzenia
powinien być do niej przypisywany okres do oceny okresowej dostawcy.
3.8.16 W przypadku gdy do umowy przekazanej do oceny zostanie zawarty aneks
mający wpływ na jej ważność, dane takiej umowy skierowane do oceny
powinny być usuwane i jednocześnie powinien być zamykany obieg workflow
dla tego dokumentu.
3.8.17 Dane o zakończonej ocenie dla umowy powinny być zwracane do aplikacji
SEU do wskazanej sekcji – pole Data oceny umowy.
3.8.18 Na podstawie przypisanego do ocenionej umowy okresu do oceny okresowej
dostawcy powinna być sporządzana ocena okresowa dostawcy.
3.8.19 Ocena okresowa powinna być wyliczana wg określonego algorytmu i
zapisywana w aplikacji (algorytm powinien być oparty na sumie iloczynów
ilości punktów uzyskanych w w każdej kategorii pomnożonej przez wagę
przypisaną do kategorii) .
3.8.20 W procesie oceny okresowej powinna być możliwość wykonania „przebiegu
testowego” oceny okresowej dostawcy.
3.8.21 Aplikacja powinna umożliwiać wyeksportowanie
testowego oceny okresowej dostawcy do Excel’a.
danych
z
przebiegu
3.8.22 Dane oceny okresowej dostawcy powinny mieć przypisany okres oceny, do
którego zostały wykorzystane
3.8.23 Aplikacja oceny umów powinna pozwalać
Wiarygodnych Dostawców” – jako formy raportu
na
sporządzanie
„Listy
3.8.24 Lista Wiarygodnych Dostawców powinna być budowana w oparciu o
kategorie zakupowe przewidziane do oceny w danym roku oraz oceny
okresowe dostawców uzyskane w poszczególnych okresach oceny umów.
3.8.25 Mechanizm budowania Listy Wiarygodnych Dostawców w danej kategorii
zakupowej powinien być uruchamiany tylko wówczas, gdy liczba ocen
okresowych dostawców w danej kategorii jest większa niż 1.
3.8.26 Aplikacja musi posiadać mechanizm przypisywania pozycji rankingowej do
dostawcy w danej kategorii zakupowej i w danym okresie czasu.
3.8.27 Na Liście Wiarygodnych Dostawców mogą być umieszczeni tylko ci dostawcy,
którzy będą spełniać określone warunki. Jeżeli dostawca w danym okresie nie
będzie spełniał takich warunków powinien on być eliminowany z listy.
3.8.28 Do sporządzania LWD będzie brany pod uwagę okres 12 miesięcy
poprzedzających ocenę okresową dostawcy. Wynik oceny okresowej stanowił
będzie podstawę do umieszczenia na LWD.
3.8.29 Na LWD mogą być umieszczeni tylko ci dostawcy, który uzyskali wymagane
mininum punktów (obecnie próg 7 punktów) w danej kategorii zakupowej.
Brak uzyskania takiego minimum w kolejnej ocenie powoduje brak
umieszczenia tego dostawcy na LWD.
3.8.30 Budoanie listy LWD powinno uwzględniać następujące ustalenia: ważność
wpisu na LWD ustala się na okres 12 miesięcy od daty ostatniej pozytywnej
oceny. Jeżeli dostawca w okresie ostatnich 12 miesięcy uzyskał 2 oceny
okresowe poniżej 6 punktów, wówczas powinien on zostać usunięty z listy LWD
pomino ważnego wpisu (zasada dwóch żółtych kartek).
3.8.31 Budowanie listy LWD powinno uwzględniać zapisy na LND, dostawca który
został wpisany na LND powinien być automatycznie skreślany z LWD.
3.8.32 Mechanizm budowania listy LWD powinien uwzględniać tzw. okres karencji
dostawcy, który był wcześniej umieszczony na LND (okres 3 miesięcy).
Warunkiem kolejnego wpisu na LWD jest uzyskanie w okresie oceny okresowej
wymaganego minimum punktów (pozytywna ocena okresowa) oraz ocena z
ostatnich 12 miesięcy jest również oceną pozytywną (na poziomie co najmniej
7 punktów).
3.8.33 Oprócz Listy Wiarygodnych Dostawców w aplikacji powinna być możliwość
budowania tzw. Listy Nierzetelnych Dostawców. Umieszczenie na tej liście
powinno się odbywać na podstawie wpisu ręcznego (Wniosek o wpisanie na
listę).
3.8.34 Aplikacja w momencie sporządzania Listy Wiarygodnych Dostawców powinna
kontrolować czy dany dostawca nie został umieszczony na Liście
Nierzetelnych Dostawców. Jeżeli dostawca taki został na nią wpisany
powinien być automatycznie usuwany z LWD w kolejnym okresie.
3.8.35 Wpis na listę LND powinien wykluczać dostawcę z LWD na określony okres
czasu.
3.8.36 Aplikacja powinna również posiadać mechanizm budowana tzw. List
rankingowych Dostawców LRD. Lista LRD powinna być budowana w każdej
kategorii, w której dokonywana jest ocena okresowa umów.
3.8.37 LRD powinna być aktualizowana cyklicznie wg określonych parametrów, tj. na
listę LRD w danym okresie i w danej kategorii powinno znajdować się 10
podmiotów z najwyższą średnią oceną, jeżeli jest kliku dostawców z taką samą
średnia, umieszczani są oni wszyscy na LRD.
3.8.38 Na liście LRD zostały są umieszczani wg gradacji punktów (z dokładnością do
setnych części), pod warunkiem posiadania ważnego wpisu na LWD. Jeżeli
dostawca został wyeliminowany w LWD na skutek nie uzyskania wymaganej
liczby punktów w ocenie okresowej, przez okres 6 miesięcy od uzyskania
kolejnej pozytywnej oceny okresowej powinien być umieszczany na niższych
pozycjach LRD.
3.8.39 Na liście LRD na pozycjach niższych są również umieszczani Ci dostawcy, którzy
byli umieszczeni na LND i uzyskali w kolejnej ocenie okresowej wymagany limit
punktów. Okres ten wynosi 12 miesięcy.
3.8.40 Aplikacja powinna posiadać mechanizm eksportu przygotowanie listy LRD,
która powinna być zaimportowana po stronie Portalu Zakupowego w
momencie jej przekazania z aplikacji w SAP.
3.8.41 Aplikacja powinna korzystać z mechanizmu workflow w SAP.
3.8.42 Mechanizm workflow powinien być wykorzystywany w poszczególnych
krokach oceny umowy.
3.8.43 Liczba kroków decyzyjnych w poszczególnych etapach powinna być
zdefiniowana w aplikacji.
3.8.44 Mechanizm workflow powinien być skorelowany
przekazywanymi do użytkowników aplikacji.
z
komunikatami
3.8.45 Liczba kroków decyzyjnych powinna być uzgodniona na etapie budowania
koncepcji. Zakłada się 4 kroki w etapie I i 2 kroki w etapie II. Krokom tym
powinny towarzyszyć odpowiednie mechanizmy wykonywania czynności w
aplikacji.
3.8.46 Jednym z elementów rozwiązania powinny być mechanizmy przypominające
o konieczności dokonania oceny umowy wraz z przekazywaniem
komunikatów do przełożonych.
3.8.47 Dla aplikacji Systemu Oceny Okresowej Umów należy zdefiniować 5raporty oparte
o siatkę ALV.
3.8.47.1 Raport z ocen cząstkowych umów.
3.8.47.2 Raport z oceny okresowej dostawcy
3.8.47.3 Raport Lista Wiarygodnych Dostawców
3.8.47.4 Raport Lista Nierzetelnych Dostawców
3.8.47.5 Raport Lista Rankingowa Dostawców
3.9 Wymagania dla rozwiązania mechanizmów automatycznej
zatwierdzania wniosków zakupowych
kontroli budżetu
i
3.9.1
Cele rozwiązania jest opracowanie mechanizmów automatycznej kontroli
poziomu
konsumpcji
zatwierdzonego
budżetu
dla
zadania/kierunku
inwestycyjnego oraz mechanizmów powiadamiania w procesach obsługi
wniosków zakupowych używanych przez Spółkę.
3.9.2
Kontrolą dostępności budżetu na poziomie zadania i równocześnie na poziomie
kierunku powinny być
objęte zakupy realizowane w obszarze inwestycji i
remontów.
3.9.3
Poziom wolnych środków dla zadania/projektu jak i kierunku powinien być
sprawdzany w momencie zapisywania dokumentu wniosku/zgłoszenia
zapotrzebowania.
3.9.4
Weryfikacji powinny być poddawane kwoty z pozycji wniosku w stosunku do
zaplanowanych wartości na lata w planie inwestycyjnym.
3.9.5
Procedurą kontroli budżetu powinny być wszystkie typy wniosków zakupowych
obsługiwane w Spółce.
3.9.6
Kontrolą dostępności budżetu powinny być objęte pozycje ujęte w planie
inwestycyjnym i remontowym, czyli zakupy na czynności sieciowe, zlecenia
remontowe.
3.9.7
Mechanizmem zatwierdzania wniosków powinny być również objęte wnioski
zakupowe na cele inne niż inwestycje i remonty.
3.9.8
Dla obsługi procesu zatwierdzania wniosków zakupowych powinien być
wykorzystany standardowy mechanizm strategii zatwierdzania dla zgłoszeń
zapotrzebowania oparty na procedurze z klasyfikacja.
3.9.9
Dla prawidłowości obsługi tego procesu powinna być zdefiniowana jedna klasa z
przypisanymi do niej cechami.
3.9.10 Zdefiniowane cechy mogą się odwoływać do pól poza standardem SAP.
3.9.11 Każda ze zdefiniowanych cech powinna bazować na słownikach zdefiniowanych
dla nich.
3.9.12 Dla zdefiniowanych kroków w strategii zatwierdzania powinny być zdefiniowane
odpowiednie kody zatwierdzania.
3.9.13 Dla wniosków objętych procedurą zatwierdzania z kontrolą budżetu na zadaniu
należy zapewnić blokowanie dokumentu do zmian po przekazaniu go do
akceptacji na kolejnym kroku.
3.9.14 Przygotowany mechanizm automatycznej kontroli budżetu na zadaniu musi być
zgodny z obowiązującym w Spółce układem planu inwestycyjnego i
remontowego.
3.9.15 Przygotowane rozwiązanie musi zapewniać mechanizm kontrolny, który w
momencie zapisywania wniosku będzie dokonywał weryfikacji budżetu na
zadaniu i kierunku inwestowania.
3.9.16 Podczas wykonywania mechanizmu kontroli budżetu w procesie tworzenia
wniosku zakupowego, w przypadku jego przekroczenia system powinien
prezentować stosowny komunikat informujący o tym fakcie.
3.9.17 Kontrola budżetu powinna być aktywna nie tylko dla nowych dokumentów ale
również dla dokumentów utworzonych przed uruchomieniem mechanizmu
kontroli, jeżeli w dokumentach dokonywane będą jakiekolwiek zmiany.
3.9.18 Dla mechanizmu kontroli budżetu na zadaniach inwestycyjnych i remontowych
należy przygotować mechanizm informujący wskazanych użytkowników systemu
o fakcie pozytywnej kontroli budżetu i utworzeniu nowego wniosku zakupowego
(zgłoszenia zapotrzebowania).
3.9.19 Dla przedmiotowego mechanizmu zatwierdzania wniosków i kontroli budżetu
należy przewidzieć możliwość stosowania wyjątków w procedurze kontroli budżetu
dla zakupów kosztowych związanych z inwestycjami.
3.9.20 Dla wniosków inwestycyjnych wymagających tzw. zgód korporacyjnych należy
uwzględnić istniejący mechanizm ustawiania właściwych wskaźników na pozycji
wniosku.
3.9.21 Dla rozwiązania należy przewidzieć mechanizm kontrolny, którego zadaniem
będzie sprawdzanie uzupełnianie danych w polach związanych z uzyskaniem
zgód korporacyjnych, w przypadku braku uzupełnienia tych pól wniosek powinien
być zablokowany do przekazania do Portalu zakupowego (dotyczy wniosków do
Planu zamówień, poza Planem zamówień oraz wniosków wykonawczych do
umów ramowych).
3.9.22 Zakłada się, że rozwiązanie powinno działać tak samo dla wszystkich rodzajów
wniosków i być oparte na 3 krokach zatwierdzania. Dotyczy to wniosków
zakupowych o podanej kwocie progowej, która może ulegać zmianie. Kwota ta
wynika z polityki zakupowej Spółki.
3.9.23 Dla rozwiązania strategii zatwierdzania z kontrolą budżetu należy przygotować
(zmodernizować) mechanizm workflow.
3.9.24 Mechanizm workflow powinien bazować na istniejącym rozwiązaniu w Spółce i
może podlegać modyfikacjom.
3.9.25 Zadaniem mechanizmu workflow dla każdego kroku zatwierdzania powinno być
wysyłanie komunikatów do użytkowników o konieczności zatwierdzenia
dokumentu w kolejnym kroku(wykonawca w kolejnym kroku) oraz o zatwierdzeniu
dokumentu w korku poprzednim (komunikat do autora). W przypadku odrzucenia
wniosku komunikat będzie wysyłany do akceptującego w korku poprzednim oraz
autora wniosku, a w przypadku odrzucenia na kroku pierwszym do autora wniosku.
3.9.26 Mechanizm strategii zatwierdzania dla wniosków poza planem zamówień
przekraczających kwotę progową wynikającą z polityki zakupowej Spółki
powinien być oparty o 4 krokową strategię zatwierdzania.
3.9.27 Mechanizmy kontroli budżetu dla wniosków z punktu powyżej powinny działać w
analogiczny sposób jak dla wniosków z 3 krokową strategią zatwierdzania.
3.9.28 Dla
przygotowywanego
rozwiązania
należy
przygotować
mechanizm
przypominający osobom odpowiedzialnym za zatwierdzeniu wniosku na danym
kroku o konieczności wykonania tej operacji po określonym terminie.
3.9.29 Powinien również być przygotowany mechanizm powiadamiania dysponenta
środków o przedłużającym się procesie akceptacji wniosku.
3.9.30 Dla rozwiązania należy przygotować mechanizm kontroli uprawnień,
przygotowanie lub modyfikacja ról pozwalających na akceptowanie wniosków z
odpowiednimi kodami zatwierdzania.
3.9.31 Mechanizm Workflow w celu komunikacji z aplikacją mobilną poprzez SAP Mobile
Platform powinien udostępniać informację o danych potrzebnych użytkownikowi
do akceptacji kroku worfklow, które będą wizualizowane w aplikacji mobilnej oraz
umożliwiać akceptację kroku workflow poprzez jedną z następujących metod:


Poprzez protokół RFC/BAPI – zapewnienie dostępu do parametrów
wejścia i wyjścia BAPI wraz z opisem parametrów
Poprzez WebService SOAP zgodnie ze standardem WSDL, w
szczególności zawierający poprawnie zdefiniowany plik XSLT
Niezależnie od wybranej metody powinien zostać dostarczony opis struktury
danych wraz z opisem parametrów wejścia i wyjścia.
VI. Wymagania dodatkowe:
1. Wykonawca przeprowadzi instruktaż i wewnętrzne szkolenie z działania aplikacji i
rozwiązań biznesowych w ilości 6 dni szkoleniowych. Szkolenie odbędzie się w siedzibie
spółki w Warszawie oraz w Oddziałach.
2. Gwarancja i wsparcie techniczne.
Wykonawca będzie świadczył usługi gwarancyjne i wsparcia technicznego na
zasadach określonych w umowie i załącznikach do umowy.
3. W ramach Wsparcia technicznego Wykonawcy Zamawiający otrzyma prawo do:


Zlecenia wprowadzania drobnych zmian konfiguracyjnych i usprawnień do
Modyfikacji
doraźnej asysty dla użytkowników i administratorów Systemu
w wymiarze do 80 roboczogodzin konsultanta/programisty, do wykorzystania przez
Zamawiającego w dowolnym momencie do czasu zakończenia Umowy. Wykonawca
jest odpowiedzialny za dokumentowanie utylizacji ww. puli roboczogodzin.
4. Testowanie i zapewnienie jakości produktów.
W ramach procesu SQA Zamawiający wymaga m.in.:
1.
2.
3.
4.
realizacji modyfikacji na środowisku deweloperskim;
realizacji testów akceptacyjnych zrealizowanych modyfikacji;
realizacja nagrania przejścia testu akceptacyjnego;
realizacja testów regresji na środowisku testowym Zamawiającego, w zakresie
adekwatnym do zrealizowanych modyfikacji;
5. dostarczenia kodów źródłowych modyfikacji wraz z dokumentacją kodów
źródłowych;
Proces SQA Zamawiającego wykorzystuje następujące narzędzia:
1. SharePoint (dedykowany dla procesu SQA)
2. SAP Solution Manager
3. HP ALM
4. HP QTP
5. uPerform
Zamawiający może udostępnić skrócony opis procesu SQA.
5. Kody źródłowe
Jako kody źródłowe należy rozumieć wszystkie elementy składowe wytworzonych
Modyfikacji jak również skrypty tworzące struktury w bazie danych lub zasobach
plikowych. Wykonawca zobowiązany jest dostarczyć kody źródłowe zgodnie z
poniższym wykazem :
1.
2.
3.
4.
kody źródłowe nieskompilowane (tzn. zapisane w języku programowania)
opis środowiska developerskiego pozwalającego na
kompilację kodów
źródłowych do postaci wykonywalnej, wdrożonej i uruchomionej na
środowisku produkcyjnym Zamawiającego
dokumentację kodów źródłowych (rozumianą jako komentarze w treści
kodów źródłowych)
dokumentację opisującą strukturę kodów źródłowych
Kody źródłowe mają być dostarczone w postaci identyfikowalnych zapisów w bazach
danych środowiska deweloperskiego, testowego i produkcyjnego SAP Zamawiającego
Dostarczone kody muszą być ustrukturyzowane i udokumentowane zgodnie ze
standardami właściwymi dla wybranego języka programowania.
6. Integracja systemów zgłoszeniowych
W ciągu 22 tygodni od zatwierdzenia projektu Wykonawca dokona integracji swojego
systemu przyjmowania zgłoszeń z system Zamawiającego.
a. Integracja powinna odbywać się za pomocą powiadomień mailowych
wysyłanych z systemu Zamawiającego i z systemu Wykonawcy.
Komunikacja i rejestracja zgłoszeń serwisowych będzie odbywać się w
sposób automatyczny na podstawie przesyłanych maili.
Każde mail będzie miał w tytule dołączony numer zgłoszenia nadany przez
system zgłoszeń Zamawiającego – Atmosfera SD /NR_ZLECENIA/
Każdy mail odesłany do Zamawiającego na adres: ServiceDesk@gaz-
system.pl w tytule maila musi posiadać numer nadany przez system
Atmosfera SD /NR_ZLECENIA/
Oprócz NR_ZLECENIA w tytule maila musi być zawarte słowo klucz
identyfikujące wykonaną czynność. Przykłady tematów maili:
Potwierdzam przyjęcie zlecenia serwisowego NR_ZLECENIA
Rozwiązanie zlecenia serwisowego NR_ZLECENIA
Pytanie do zlecenia serwisowego NR_ZLECENIA
Wykonawca zobowiązuje się udostępnienia dedykowanego numer do
przyjmowania zgłoszeń serwisowych
b. Zamawiający dopuszcza zastąpienie integracji mailowej w przypadku gdy
Wykonawca udostępni interfejs API, który umożliwia komunikację i
rejestrację zgłoszeń w sposób automatyczny. W przypadku integracji za
pomocą interfejsu API, stroną aktywną będzie system Zamawiającego,
stroną pasywną będzie system Wykonawcy. Udostępniony interfejs API
musi spełniać następujące funkcje:
i. dostępność z sieci Wykonawcy
ii. możliwość rejestracji nowego zgłoszenia
iii. możliwość rejestracji sprostowania, ponaglenia, pytania i
odpowiedzi
iv. możliwość zmiany statusów zgłoszeń serwisowych
5. Niezależnie od sposoby dostarczenia zgłoszenia serwisowego Wykonawca jest
zobowiązany niezwłocznie, jednak nie później niż w ciągu jednej godziny od momentu
zgłoszenia potwierdzić przyjęcie zgłoszenia z informacją o szacowanym czasie
rozwiązania problemu, nadanym numerze i dacie oraz godzinie przyjęcia zgłoszenia.
6. Wykonawca jest zobowiązany niezwłocznie po rozwiązaniu problemu określonego w
zgłoszeniu poinformować Zamawiającego o:
a. dacie i godzinie zamknięcia zgłoszenia
b. przyczynie wystąpienia problemu jednoznacznie określającego czy
problem wystąpił z przyczyn leżących po stronie Zamawiającego czy
Wykonawcy
7. Zamawiający po otrzymaniu informacji, o której mowa powyżej:
a. w przypadku usunięcia problemu, potwierdzi Wykonawcy usunięcie
problemu u wyda zgodę na zamknięcie zgłoszenia
b. w przypadku kiedy pomimo zamknięcia zgłoszenia, Zamawiający uzna, że
problem nadal występuje, Zamawiający ponownie otworzy zgłoszenie. W
takiej sytuacji termin określony w umowie na usunięcie problemu biegnie
dalej.