Specyfikacja Wymagań System Obsługi

Specyfikacja Wymagań
System Obsługi Zgłoszeń Serwisowych
Polfa Warszawa S.A.
Załącznik nr 1
1.
Wymagania sprzętowe i środowiskowe
1.1.
Wymagania podstawowe
Nowy system ma być dostępny dla wszystkich pracowników Spółki
za pośrednictwem przeglądarki WWW oraz korzystać z infrastruktury serwerowej
i bazodanowej Spółki.
Powinien zostać dostarczony opis modelu danych zawartych w bazie.
Wymagane jest wsparcie dla przeglądarki MS Internet Explorer 8.0 lub nowszej
oraz Firefox 3.5 lub nowszej.
System musi dawać użytkownikowi możliwość
Wymagane języki to przynajmniej polski i angielski.
1.2.
wyboru
języka
interfejsu.
Dostęp do systemu
System powinien być dostępny dla wszystkich pracowników Polfy Warszawa S.A.
posiadających dostęp do sieci teleinformatycznej. jak również może być
udostępniony dla użytkowników sieci w spółkach zależnych. System powinien
korzystać z Active Directory w celu autoryzacji użytkowników. W przypadku, gdy
dany użytkownik nie ma dostępu do Active Directory, system musi mieć możliwość
korzystania z własnej bazy użytkowników.
1.3.
Konfigurowanie systemu
System powinien być elastyczny (szeroki zakres konfigurowalności, możliwość
tworzenia własnych rozszerzeń) i pozwalać na modyfikacje wynikające
ze zmieniających się potrzeb Spółki. Wskazane jest, aby Polfa miała możliwość
modyfikacji i tworzenia nowych raportów. System musi być skalowalny,
aby umożliwić rozwój w ramach nowopojawiających się wymagań
np. wydajnościowych.
1.4.
Integracja z innymi systemami
Nowy system powinien zapewniać bogate mechanizmy integracji. Umożliwiać
integrację z innymi systemami różnych producentów, zwiększający zakres
zastosowania narzędzia IT w Spółce (np. gospodarka środkami trwałymi IT,
zarządzanie licencjami). System musi posiadać możliwość importu i eksportu
danych.
1.5.
Bezpieczeństwo
Środowisko zarządzane przez Polfę Warszawa wymaga przestrzegania bardzo
wysokich standardów bezpieczeństwa, zatem dostarczony system powinien takie
standardy wspierać.
System musi posiadać możliwość definiowania uprawnień dostępu zarówno
do modułów, raportów jak i do bazy.
2.
Wymagania funkcjonalne
2.1.
System powinien wyróżniać następujące role:
a) Użytkownik – pracownicy Spółki z możliwością zdefiniowania dodatkowych
uprawnień dla kierownika działu/oddziału występujących o uprawnienia
dla podległych pracowników,
b) 1. linia wsparcia – pracownik zespołu Service Desk,
c) 2. linia wsparcia – pracownik Oddziału Serwisu lub pracownik innego
oddziału w ramach działu IT,
d) Gestor systemu – właściciel systemu decydujący o nadaniu uprawnień
do poszczególnych funkcjonalności systemu i odpowiadający za kierunki
rozwoju systemu,
e) Administrator – kierownik zespołu Service Desk,
2.2.
Obsługa zgłoszeń serwisowych:
a) rejestracja i obsługa
towarzyszącymi:
zgłoszeń
serwisowych
wraz
z
dokumentami
- Zgłoszenia Serwisowe,
- Wnioski Nadania Uprawnień (WNU),
b) system musi mieć możliwość wystawienia zgłoszenia wieloma kanałami,
w szczególności przez stronę WWW i e-mail,
c) system powinien posiadać mechanizm automatycznego przekształcania
wiadomości e-mail we wniosek o usługę lub incydent,
d) system musi umożliwiać użytkownikom przeglądanie na stronie www
statusu własnych zgłoszeń oraz bazy wiedzy znanych problemów
i sposobu ich rozwiązań,
e) system musi mieć możliwość klasyfikacja zgłoszeń w oparciu o priorytet
i pilność,
f) system musi mieć możliwość przypisywanie zgłoszeń do określonego
serwisanta i zmiany przypisanego serwisanta,
g) system powinien automatycznie wypełniać formularz danymi użytkownika
tworzącego zgłoszenie na podstawie loginu,
h) system powinien mieć możliwość przypisania zgłoszenia do danego
użytkownika w przypadku, gdy jest ono wystawiane w jego imieniu przez
pracownika działu IT lub innego użytkownika systemu,
i)
system musi umożliwiać sklasyfikowanie wniosku (wielopoziomowe
drzewko kategorii), wskazanie zasobów, których dotyczy zgłoszenie,
dołączanie dowolnego dokumentu w postaci elektronicznej (np. zrzut
z ekranu z komunikatem błędu),
j)
system musi posiadać możliwość automatycznego (w oparciu o elastycznie
definiowalne kryteria) przypisania odpowiednich pracowników lub grup
wsparcia jako odpowiedzialnych za obsługę wpływającego wniosku,
k) system powinien umożliwiać tworzenie szablonów typowych wniosków,
z możliwością aktywacji i dezaktywacji wybranych pól, w zależności
od typu zgłoszenia i jego parametrów,
l)
system powinien umożliwiać kontakt elektroniczny lub telefoniczny
z użytkownikiem w celu weryfikacji danych zawartych w zgłoszeniu,
m) system powinien mieć
zamkniętego zgłoszenia,
możliwość
ponownego
otwarcia
uprzednio
n) system powinien mieć możliwość ręcznego i automatycznego zamykania
zgłoszeń o statusie Zrealizowane po określonym i odpowiednio
zdefiniowanym czasie,
o) system powinien mieć możliwość zmiany statusu zgłoszenia (wymagany
opis przyczyny zmiany przez osobę dokonującą zmiany),
p) system powinien mieć możliwość zmiany etapu realizacji zgłoszenia przez
pracowników działu IT,
q) system musi zapewnić monitorowanie zgłoszenia od momentu powstania
aż do momentu jego rozwiązania i zamknięcia z uwzględnieniem tego,
kto i kiedy był odpowiedzialny za jego obsługę, jakie czynności zostały
wykonane w trakcie jego realizacji i kto i kiedy je wykonał,
r) system
powinien
mieć
możliwość
wyszukiwania
zgłoszeń
po identyfikatorze zgłoszenia, loginie osoby wystawiającej, loginie osoby
realizującej zgłoszenie, po dowolnym fragmencie tekstu zgłoszenia,
s) w przypadku pojawienia się masowych zgłoszeń dotyczących tej samej
kwestii, system musi posiadać mechanizm grupowania wniosków
w ramach jednego rekordu nadrzędnego, tak aby oddział wsparcia
pracował z jednym rekordem, a do rekordów podrzędnych była
przenoszona komunikacja, rozwiązania i zmiany statusów,
t)
system powinien posiadać mechanizmy ułatwiające pracownikom Service
Desku identyfikację podobnych wniosków o usługę lub incydentów,
u) aby uniknąć ponownego wykonania tej samej pracy, system musi posiadać
efektywny mechanizm przeszukiwania z jednego miejsca zarówno
wniosków o usługę, incydentów, problemów jak i bazy wiedzy,
v) system musi mieć możliwość dodawania komentarzy i opisów dotyczących
przebiegu obsługi zgłoszenia na każdym etapie jego realizacji,
w) system powinien mieć mechanizm powiadamiania (np. e-mail) – określenie
i kontrola czasu pozostałego do odpowiedniego obsłużenia zgłoszenia,
wysyłając powiadomienia do właściwych osób,
x) system musi posiadać mechanizm automatycznego przypisywania
odpowiednich pracowników lub grup wsparcia, jako odpowiedzialnych
za obsługę wpływających zgłoszeń od użytkowników.
2.3.
Pola obowiązkowe/wymagane przy wystawianiu nowego zgłoszenia:
a) ID zgłoszenia,
b) status,
c) autor zgłoszenia,
d) priorytet,
e) kategoria,
f) temat,
g) opis,
h) data zgłoszenia.
2.4.
Pola nieobowiązkowe/ nie wymagane przy wystawianiu nowego zgłoszenia:
a) produkt,
b) nazwa programu,
c) nazwa/numer menu,
d) określenie sprzętu,
e) lokalizacja sprzętu,
f) uwagi.
2.5.
Status zgłoszenia
a) Nowe
b) Do uzupełnienia
c) Oczekujące
d) Zatwierdzone
e) Realizowane
f) Odrzucone
g) Zrealizowane
2.6.
System musi posiadać tzw. bazę wiedzy – w której użytkownik sam może
wyszukać rozwiązania znanych problemów i uzyskać odpowiedzi na często
zadawane pytania. Baza wiedzy musi posiadać możliwość dodawania
do rekordów poszczególnych rozwiązań plików z dokumentacją, wykresami oraz
plików multimedialnych.
2.7.
Rejestracja czasu obsługi zgłoszenia
Na każdym etapie zgłoszenia musi być rejestrowany czas jego obsługi. System
powinien umożliwiać rejestrowanie aktywności związanych z poszczególnymi
incydentami oraz śledzenie czasu pracy personelu.
Pola obowiązkowe dotyczące czasu obsługi zgłoszenia:
a) przewidywany czas realizacji,
b) faktyczny czas realizacji,
c) sumaryczny czas realizacji – liczony automatycznie przez system,
jako suma faktycznych czasów realizacji zgłoszenia.
2.8.
Generowanie raportów
a) system powinien umożliwiać generowanie raportów na podstawie
zadanych parametrów; podstawowe niezbędne raporty to co najmniej:
 obciążenie serwisanta lub podanej grupy serwisantów,
 średni czas realizacji zgłoszeń wg daty/ serwisanta/ identyfikatora
zgłoszenia,
 czasu obsługi zgłoszeń określonych typów na poszczególnych etapach,
 ilość zgłoszeń w zdefiniowanym przedziale czasowym z podziałem
na rodzaje zgłoszeń i komórki organizacyjne,
 ilość zgłoszeń według użytkownika lub podanej grupy użytkowników,
 ilość zgłoszeń według serwisanta,
 ilość zgłoszeń według statusu zgłoszeń,
 ilość negatywnych cykli „Do poprawki”,
 ilość zgłoszeń ponownie otwartych,
b) system powinien posiadać graficzne narzędzie do prezentowania raportów,
c) system musi posiadać mechanizm do uruchamiania raportów na bazie
zadanego harmonogramu i przesłanie wyników pocztą elektroniczną,
d) system musi posiadać możliwość definiowania prostych raportów ad-hoc,
raportowanie to powinno umożliwiać wybór kolumn raportu, kolumn
do grupowania i sortowania wg identyfikatora zgłoszenia (rosnąco
i malejąco), priorytetu, statusu zgłoszenia (rosnąco i malejąco), daty
zgłoszenia, użytkownika, komórki organizacyjnej, serwisanta,
e) system musi posiadać możliwości zabezpieczające przed uruchomieniem
raportów zwracających za dużą liczbę rekordów,
f) system musi mieć możliwość dostosowania interfejsu do indywidualnych
potrzeb użytkownika.
3.
Wymagania dodatkowe (nieobligatoryjne)
3.1.
System powinien posiadać moduł do zarządzania umowami SLA (zewnętrznymi
i wewnętrznymi).
3.2.
System powinien zapewniać mechanizmy umożliwiające współdziałanie
z istniejącą infrastrukturą programową Spółki, a w kolejnych etapach rozwoju
systemu zarządzania IT nie ograniczać wyboru dostawcy.
3.3.
Powinna istnieć możliwość dokupienia standardowych adapterów do wiodących
systemów klasy ERP.
3.4.
System powinien automatycznie wypełniać formularz danymi użytkownika
tworzącego zgłoszenie na podstawie loginu oraz ustawić kontekstowy filtr
na zasoby (takie, jakie są przypisane osobie wystawiającej zgłoszenie)
umożliwiający użytkownikowi szybkie odnalezienie należącego do niego sprzętu
i oprogramowania, którego używa.
3.5.
System powinien udostępniać mechanizm tzw. tablicy ogłoszeń, poprzez którą
pracownicy Service Desk komunikują się z użytkownikami. System powinien
rejestrować fakt przeczytania komunikatu.
3.6.
System powinien umożliwiać pracownikom Serwisu zdalne przejmowanie kontroli
nad stacjami użytkowników w celu przyspieszenia diagnozy i usunięcia
incydentów.
3.7.
System powinien zapewniać możliwość szyfrowania wskazanych danych w bazie
tak, aby dostęp do bazy innymi narzędziami nie dawał możliwości odczytu
ich wartości.
3.8.
System powinien umożliwiać wysyłanie do użytkownika „Ankiety satysfakcji”
w celu oceny realizacji zgłoszenia.
3.9.
Powinna istnieć możliwość udostępnienia
źródłowych dostarczonego oprogramowania.
Polfie
Warszawa
S.A.
kodów
3.10. System powinien udostępniać funkcjonalności zgodną z ITIL v.3
3.11. System powinien działać z różnymi relacyjnymi bazami danych, w szczególności
Oracle, MySQL, MS SQL.