Drugim typem rozwiązania jest struktura z centralnym wsparciem dla całej organizacji. W jednej fizycznie lokalizacji znajduje się dział wsparcia, obsługujący incydenty dla określonej liczby podmiotów. Podmiotem mogą być różne działy w tej samej firmie, różne budynki, działy regionalne, krajowe, międzynarodowe. Korzyścią wynikającą z zastosowania takiego modelu jest zredukowanie kosztów, ponieważ mniejsza ilość zasobów zostanie przypisana do obsługi określonych incydentów. Dodatkowo dzięki integracji różnych elementów zarządzania rozwiązywanie problemów staje się bardziej efektywne. Istnieje możliwość zmniejszenia ilości lokalnych punktów wsparcia technicznego poprzez stworzenie struktury z centralnym punktem wsparcia technicznego. Powoduje to znaczące ograniczenie kosztów i jest zdecydowanie bardziej efektywne finansowo. Czasami nadal w takim modelu może istnieć konieczność fizycznej obecności części działu IT w lokalizacji użytkowników, ale nadzór może być realizowany z jednego miejsca.

Najbardziej zaawansowaną z punktu widzenia IT jest konfiguracja wirtualnego wsparcia, zazwyczaj oferowana w formie zewnętrznej usługi. Struktura oferuje zbliżone korzyści do architektury centralnej. Istnieje jednak dodatkowa możliwość rozproszenia funkcjonalności pomiędzy różne lokalizacje centrów wsparcia, do których ruch kierowany jest z wykorzystaniem różnych parametrów (przykładowo stref czasowych). W tym modelu personel obsługujący wsparcie techniczne może być rozproszony - zlokalizowany w różnych geograficznie miejscach. Szczególnie taka konfiguracja jest propagowana w modelu wsparcia 24h - określana często nazwą "Follow the Sun". Niektóre organizacje globalne wymagają wsparcia oddziałów w różnych strefach czasowych. Model wirtualny często jest dostarczany w formie SaaS (Software as a Service).

Zobacz również:

• Krótka lista najbardziej niedocenianych technologii w IT

Umowy serwisowe

Działania ServiceDesk / HelpDesk zazwyczaj oparte są o umowy serwisowe, zawierane pomiędzy różnymi podmiotami. Najczęściej stosowane umowy to SLA (Service Level Agreement), OLA (Operational Level Agreement), UC (Underpining Contract). Usługodawca IT oferuje usługi opisane w katalogu usług. Katalog usług to pierwszy element w implementacji SLA. Jeżeli organizacja posiada katalog usług, konieczne jest przygotowanie realistycznego wsparcia dla zdefiniowanych usług. To właśnie jest rola umowy OLA. Jeżeli OLA jest zdefiniowane, można przystąpić do realizacji SLA. Typowo umowa OLA powinna zawierać zakres, role i odpowiedzialności, schemat priorytetyzacji, formy raportowania, a także kluczowe wskaźniki wydajności (KPI - Key Performance Indicators).

Zarówno umowa OLA jak i SLA są dość powszechnie stosowane w przypadku usług IT. SLA stanowi kontrakt pomiędzy dostawcą usługi a klientem. OLA to umowa pomiędzy wewnętrzną grupą wsparcia, a grupą realizującą SLA w ramach tej samej organizacji. SLA powiązuje dostawcę usługi z użytkownikiem. SLA skupia się na części usługowej umowy, jak czas poprawnej pracy usługi czy jej wydajność. Grupa docelowa SLA jest większa od grupy docelowej OLA. Z kolei OLA jest bardziej techniczną umową niż SLA.

Umowa UC określa natomiast wymagania pomiędzy zewnętrznym dostawcą w celu upewnienia się, że będzie dostarczał usługi zgodne z SLA.

Rynek rozwiązań ServiceDesk/HelpDesk

Do niedawna rynek rozwiązań ITSM był zdominowany przez stabilne, ale wolno rozwijające się rozwiązania pochodzące od producentów IBM, CA, BMC Remedy, HP. Tradycyjne produkty były dość drogie i mało elastyczne. Pewnym przełomem okazało się wprowadzenie usług ITSM w formie SaaS. Pojawiły się produkty typu ServiceNow, Remedyforce, Nimsoft czy Charwell. Na starcie działalności produkty SaaS były zdecydowanie tańsze od dużych rozwiązań, a często do pewnej wielkości wdrożenia darmowe. Przykładem może być Servicedesk Plus (ManageEngine). Warto wspomnieć także o rozwiązaniach Samanage, Freshservice, Zendesk, Freshdesk, Desk.com, SysAid, Zoho, Frontrange, Agiloft, Hornbill, Kaseya.

System ServiceDesk/HelpDesk powinien umożliwiać zapisywanie zgłoszeń w bazach danych, umożliwiać śledzenie i automatyzować proces zarządzania zdarzeniami. To podstawa, ale warto sprawdzić czy system ma możliwość rozbudowy o dodatkowe mechanizmy. Ważnym elementem jest baza wiedzy KMS (Knowledge Management System), która zawiera opisy znanych lub ostatnio rozwiązanych problemów. Taka baza powinna zostać udostępniona bezpośrednio użytkownikom lub służyć jako wsparcie dla przyjmujących zgłoszenia. System powinien zawierać narzędzia (IT Asset Management System) umożliwiające inwentaryzację i śledzenie zmian w sprzęcie, oprogramowaniu, konfiguracjach, zasobach. Zarządzanie powinno pozwalać na monitorowanie wydajności działu wsparcia w oparciu o określone metryki. Obligatoryjnym zadaniem powinno być wsparcie dla SLA. Powinna istnieć możliwość zdefiniowania parametrów umów wraz z automatycznym wyzwalaniem zdarzeń. Coraz częściej w systemach ITSM stosowane są narzędzia umożliwiające zdalny dostęp do komputera użytkownika i przejęcie kontroli w celu lokalizacji, diagnostyki lub rozwiązania zgłoszonego zdarzenia.