Specyfikacja Wymagań. System Obsługi Zgłoszeń Serwisowych Polfa Warszawa S.A. Załącznik nr 1

Transkrypt

1 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ść wyboru języka interfejsu. Wymagane języki to przynajmniej polski i angielski 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 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 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,

2 zarządzanie licencjami). System musi posiadać możliwość importu i eksportu danych 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 zgłoszeń serwisowych wraz z dokumentami towarzyszącymi: - 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 , c) system powinien posiadać mechanizm automatycznego przekształcania wiadomości 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ń,

3 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ć możliwość ponownego otwarcia uprzednio zamkniętego zgłoszenia, 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,

4 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. ) 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 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 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 Status zgłoszenia

5 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 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 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ń,

6 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) 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 Powinna istnieć możliwość dokupienia standardowych adapterów do wiodących systemów klasy ERP 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 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 System powinien umożliwiać pracownikom Serwisu zdalne przejmowanie kontroli nad stacjami użytkowników w celu przyspieszenia diagnozy i usunięcia incydentów 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.

7 3.8. System powinien umożliwiać wysyłanie do użytkownika Ankiety satysfakcji w celu oceny realizacji zgłoszenia Powinna istnieć możliwość udostępnienia Polfie Warszawa S.A. kodów źródłowych dostarczonego oprogramowania System powinien udostępniać funkcjonalności zgodną z ITIL v System powinien działać z różnymi relacyjnymi bazami danych, w szczególności Oracle, MySQL, MS SQL.