Ten artykuł jest dla Ciebie, jeśli prowadzisz MSP (Managed Service Provider) i obsługujecie IT więcej niż jednej firmy. Omawiamy architekturę systemów ITSM przeznaczonych do pracy wielodzierżawczej, najczęstsze błędy przy wyborze narzędzia oraz matrycę decyzyjną, która pomoże dopasować rozwiązanie do skali Twojej organizacji.
1. Czym różni się ITSM dla MSP od ITSM korporacyjnego
Większość systemów ITSM powstała dla jednej organizacji: jeden tenant, jeden zestaw procesów, jedno SLA, jedno logo na portalu. Doskonale sprawdza się to w korporacji obsługującej własnych pracowników, ale nie pasuje do modelu MSP.
MSP zarządza IT wielu niezależnych klientów jednocześnie. Każdy z nich ma inne:
- Priorytety i kategorie incydentów: klient produkcyjny zgłasza awarię linii, klient biurowy problemy z Outlookiem
- Umowy SLA: czas reakcji 1h dla klienta premium, 8h dla basic
- Godziny pracy i okna serwisowe: jeden klient pracuje w systemie zmianowym 24/7, drugi tylko od 8 do 17
- Modele rozliczeń: pakiet godzin, abonament, stawka za incydent
- Wymagania dotyczące izolacji danych: klient z sektora finansowego nie może widzieć danych klienta z handlu detalicznego
Dla MSP liczą się: izolacja danych, osobne portale klientów, billing per klient i raporty per klient, zarządzane z jednego panelu. Bez tych elementów zespół tonie w ręcznej administracji zamiast obsługiwać zgłoszenia. Więcej o budowaniu rentownego modelu MSP znajdziesz w artykule model wartości MSP: jak budować ofertę.
Kluczowa różnica
ITSM korporacyjny optymalizuje jeden proces dla jednej organizacji. ITSM dla MSP musi równocześnie obsługiwać wiele niezależnych procesów, SLA i modeli biznesowych, bez ładu i składu administracyjnego.
2. Największy błąd MSP przy wyborze systemu
Rozmawiamy z dziesiątkami MSP i niemal zawsze słyszymy ten sam scenariusz: firma zaczyna od jednego lub dwóch klientów, wdraża system ITSM przeznaczony dla jednej organizacji (np. Jira Service Management, klasyczny GLPI, lub darmowa wersja Freshdesk). Działa. Potem przychodzi trzeci klient. Czwarty. Siódmy.
I zaczyna się era workaroundów:
- Osobna instancja systemu per klient: pięć instancji Jira, pięć osobnych logów, pięć odrębnych konfiguracji
- Projekty jako symulacja multi-tenant: jeden system, ale każdy klient to osobny "projekt", zarządzanie uprawnieniami ręcznie
- Excel do rozliczeń, bo system nie umie billingować per klient
- Ręczne filtrowanie raportów: eksport do CSV, obróbka, wysyłka e-mailem
Uwaga: Symulowanie multi-tenant przez osobne instancje lub projekty nie jest rozwiązaniem skalowalnym. Przy 8-10 klientach czas administracji może przewyższać czas faktycznej obsługi zgłoszeń. Szacujemy, że MSP z 8 klientami na osobnych instancjach traci średnio 12-18 godzin miesięcznie wyłącznie na administrację systemami.
- Osobne instancje = wiele loginów, wiele konfiguracji
- Brak centralnego przeglądu wszystkich klientów
- Ręczne zarządzanie SLA per klient
- Brak wbudowanego billingu: Excel lub zewnętrzne narzędzia
- Raporty per klient wymagają ręcznego filtrowania
- Eskalacje niespójne między klientami
- Onboarding nowego klienta = nowa konfiguracja systemu
- Jeden panel admina, pełna kontrola nad wszystkimi klientami
- Izolacja danych na poziomie architektury
- SLA konfigurowane per klient, eskalacje automatyczne
- Billing wbudowany: raport czasu pracy per klient, eksport do faktury
- Portal klienta z własną domeną i brandingiem
- Onboarding nowego klienta: kilka kliknięć w panelu
- Integracja z Endpoint Central MSP oraz zewnętrznymi RMM przez REST API
3. Czym jest natywny multi-tenant
Termin "multi-tenant" bywa używany luźno. Doprecyzujmy, co rozumiemy przez natywną architekturę wielodzierżawczą w kontekście ITSM.
Architektura
W natywnym multi-tenancy jeden system przechowuje dane wszystkich klientów (tenantów), ale na poziomie bazy danych i logiki aplikacji zapewniona jest pełna izolacja. Klient A nie widzi danych klienta B. Nie dlatego, że filtry są dobrze ustawione, ale dlatego, że architektura tego nie pozwala.
Co wchodzi w skład natywnego multi-tenant dla MSP
- Osobne portale klientów: każdy klient ma własną stronę (np.
klientA.rotechgroup.eu), z własnym logo i brandingiem - Jeden panel administracyjny MSP: z lotu ptaka widzisz wszystkich klientów, otwarte tickety, zalegające SLA, obciążenie zespołu
- Konfiguracja per klient: SLA, kategorie, formularze, godziny pracy, eskalacje, wszystko definiowane odrębnie dla każdego tenanta
- Billing per klient: system śledzi czas pracy agentów na konkretnych ticketach i przypisuje koszty do odpowiedniego klienta
Jira Organizations vs SDP MSP: praktyczna różnica
Jira Service Management oferuje funkcję "Organizations" (Organizacje), która pozwala grupować klientów. To jednak podejście naklejone na jednodzierżawczą architekturę: zarządzanie uprawnieniami wymaga ręcznie tworzonych reguł na poziomie projektów, portale klientów są wspólne, a billing nie istnieje jako natywna funkcja.
ManageEngine SDP MSP został zbudowany od podstaw z architekturą MSP: każdy tenant to oddzielona jednostka, portal klienta z własną domeną jest wbudowany, a moduł billing jest częścią podstawowej platformy.
4. ManageEngine SDP MSP: dlaczego dominuje w tym segmencie
ManageEngine ServiceDesk Plus MSP (SDP MSP) to dedykowana platforma dla dostawców zarządzanych usług IT. Jej przewaga nie wynika z marketingu, wynika z architektury.
Natywna architektura MSP
Jeden system, wiele tenantów: izolacja danych na poziomie architektury, nie filtrów.
Billing wbudowany
Śledzenie czasu pracy per klient, generowanie raportów do rozliczeń, eksport PDF.
Portal klienta z domeną
Każdy klient ma własny portal pod własną subdomeną z logo i brandingiem.
Integracje RMM
Natywna integracja z Endpoint Central MSP: alerty z monitorowania tworzą tickety automatycznie. Integracja z innymi systemami RMM dostępna przez REST API.
Raporty per klient
Gotowe szablony raportów: SLA compliance, czas reakcji, obciążenie agentów, per klient.
Jeden panel admina
Pełen przegląd wszystkich tenantów z jednego miejsca, bez przeskakiwania między loginami.
SDP MSP integruje się także z szerszym ekosystemem ManageEngine (OpManager, Endpoint Central, ADAudit Plus), co umożliwia budowę kompletnego stosu IT managementu bez konieczności integrowania narzędzi firm trzecich.
5. Ile klientów możesz obsługiwać zanim system zacznie Cię hamować
Odpowiedź zależy od architektury narzędzia, nie od jego nazwy. Poniżej matryca oparta na liczbie aktywnie obsługiwanych klientów MSP:
Startujący MSP
Na tym etapie prawie każde narzędzie działa, workaroundy są jeszcze do opanowania. Priorytetem jest prostota i niski koszt.
Rozwijający się MSP
Tutaj workaroundy zaczynają boleć. Administracja pochłania godziny. Obowiązkowo natywny multi-tenant, inaczej koszty operacyjne szybko zjadają marżę.
Dojrzały MSP
Na tym poziomie brak natywnej platformy MSP to hamulec wzrostu. Wymagana jest automatyzacja, zaawansowany billing i integracje RMM.
Ważna zasada
Migracja systemu przy 15 klientach jest 3x trudniejsza niż przy 5. Im wcześniej wybierzesz skalowalną platformę, tym mniej bólu migracyjnego. Planuj architekturę na następne 3 lata, nie na teraz.
6. SLA per klient: jak to skonfigurować poprawnie
SLA (Service Level Agreement) to kontrakt operacyjny z klientem. Jeśli Twój system nie umie egzekwować odrębnych SLA per klient, Twój zespół będzie ręcznie śledzić priorytety, co prowadzi do błędów i napięć z klientami.
Co powinno być konfigurowane oddzielnie per klient
Klient premium: reakcja 1h, rozwiazanie 8h. Klient basic: reakcja 8h, rozwiazanie 48h.
Klient 24/7: SLA chodzi non-stop. Klient biurowy: SLA aktywne 8:00–17:00, pon–pt.
Eskalacja do managera po 80% czasu SLA. Inna osoba eskalacji u każdego klienta.
Klient produkcyjny: "awaria linii" = krytyczny. Klient biurowy: brak takiej kategorii.
Cotygodniowy raport SLA compliance wysyłany automatycznie do wskazanego kontaktu u klienta.
SLA nie biegnie podczas planowanych przerw konserwacyjnych, definiowane per klient.
W natywnym systemie MSP (jak SDP MSP) powyższe konfiguracje są osobnymi profilami per tenant. W systemach z workaroundami to ręcznie utrzymywane zasady, które łatwo zapomnieć zaktualizować, gdy zmienia się umowa z klientem.
7. Rozliczenia i raportowanie dla klientów
Dla MSP rozliczalność pracy to podstawa rentowności. System ITSM powinien być jednocześnie narzędziem operacyjnym i źródłem danych do fakturowania.
Co powinien umieć system w zakresie billingu
Agenci logują czas na ticketach. System sumuje per klient, per agent, per projekt.
Klient A: 150 zł/h. Klient B: 200 zł/h dla prac poza godzinami. Konfiguracja w panelu.
Gotowy wydruk z listą ticketów, czasem pracy, całkowitym kosztem, brandowany logo MSP.
Klient kupił 40h/miesiąc. System pokazuje zużycie w czasie rzeczywistym, alert przy 80%.
Archiwum miesięcy z możliwością porównania: ile klient generuje pracy w trendzie.
CSV lub PDF z danymi gotowymi do przepisania na fakturę lub importu do systemu FK.
MSP z 8 klientami: migracja z osobnych instancji Jira do SDP MSP
Firma IT zarządzająca infrastrukturą dla 8 klientów przez 2 lata działała na 8 oddzielnych instancjach Jira Service Management. Każdy klient = osobna subskrypcja, osobna konfiguracja, odrębny login dla agentów.
Problemy: agenci co rano sprawdzali 8 różnych paneli, rozliczenia ręczne w Excelu (ok. 6h tygodniowo), brak centralnego widoku obciążenia zespołu, niemożność priorytetyzacji między klientami.
Po migracji do SDP MSP: jeden panel, automatyczne SLA per klient, wbudowany billing, raporty generowane jednym kliknięciem. Czas administracyjny spadł o 60% w pierwszym miesiącu po migracji.
8. Matryca: który system dla MSP jakiej wielkości
| Skala MSP | Rekomendacja systemu | Multi-tenant | Billing wbudowany | Dlaczego |
|---|---|---|---|---|
| 1–5 klientów | Freshdesk, Zammad, Jira JSM Starter | Ograniczony | Nie | Niski koszt, prosta administracja. Planuj migrację na wzrost. |
| 5–15 klientów | ManageEngine SDP MSP | Natywny | Tak | Natywna architektura MSP, billing, portale klientów z domeną. |
| 15–50 klientów | ManageEngine SDP MSP | Natywny | Tak | Kluczowa automatyzacja, integracje RMM, zaawansowane SLA. |
| 50+ klientów | SDP MSP Enterprise lub PSA + ITSM | Natywny | Tak | Wymagane zaawansowane PSA (Professional Services Automation) lub integracja z Connectwise Manage. |
| Jira JSM (wszystkie) | Workaround przez Organizations | Nie natywny | Nie | Wymaga ręcznie utrzymywanych uprawnień per projekt, brak billingu, brak izolacji danych. |
| Oxari | MSP do ok. 10 klientów | Częściowy | Ograniczony | Polskie narzędzie z opcją multi-tenant. Fokus na enterprise, sektor publiczny i szpitale. Możliwości MSP warto zweryfikować bezpośrednio z producentem (Infonet Projekt SA). |
Jira Service Management sprawdza się dla wewnętrznych działów IT lub MSP obsługujących jednego dużego klienta. Nie ma jednak natywnej architektury wielodzierżawczej. Przy skalowaniu do wielu klientów koszty administracyjne rosną szybko. Jeśli szukasz narzędzi do całego stosu MSP, przeczytaj ManageEngine vs NinjaOne dla MSP.
9. FAQ: często zadawane pytania
ManageEngine ServiceDesk Plus MSP (SDP MSP) to osobny produkt ManageEngine dedykowany dostawcom usług zarządzanych (MSP). Główna różnica w porównaniu do standardowego ServiceDesk Plus polega na natywnej architekturze wielodzierżawczej: jeden system obsługuje wielu klientów z pełną izolacją danych, oddzielnymi portalami klientów (z własnymi domenami), konfigurowalnymi SLA per klient oraz wbudowanym modułem billing do rozliczeń. Standardowy SDP jest zoptymalizowany pod jedną organizację: wewnętrzny helpdesk. SDP MSP jest zoptymalizowany pod doświadczenie wielu niezależnych klientów zarządzanych z jednego panelu.
ManageEngine SDP MSP jest licencjonowany w modelu per technik (agent), nie per klient. Oznacza to, że możesz dodawać kolejnych klientów bez dodatkowych kosztów licencji, płacisz za liczbę agentów obsługujących zgłoszenia. Konkretne ceny zależą od liczby agentów, wybranego planu oraz ew. dodatkowych modułów. Skontaktuj się z partnerem po aktualny cennik. Jako certyfikowany partner ManageEngine, Rotech Group może dostarczyć wycenę i demo środowisko.
Jira Service Management to świetne narzędzie, ale nie zostało zaprojektowane z myślą o MSP zarządzających wieloma klientami jednocześnie. Funkcja "Organizations" pozwala na pewne grupowanie klientów, ale nie jest to natywna architektura multi-tenant: brak pełnej izolacji danych, brak wbudowanego billingu, brak osobnych portali klientów z własną domeną. W praktyce MSP z Jira budują workaroundy (osobne projekty lub instancje), które dobrze działają do ok. 5 klientów. Przy większej skali koszty administracyjne rosną wyraźnie. Jira nadaje się natomiast świetnie, gdy MSP obsługuje jednego dużego klienta i chce mu zaoferować system z silnymi integracjami Atlassian (Confluence, Bitbucket).
Migracja zwykle przebiega w czterech etapach: (1) Audyt obecnej struktury: katalog klientów, ich SLA, kategorie incydentów, modele rozliczeń. (2) Konfiguracja tenantów w SDP MSP: tworzenie profili klientów, portali, SLA i kategorii. (3) Migracja historii ticketów (opcjonalnie, przez API lub import CSV). (4) Szkolenie agentów i przełączenie aktywnych klientów. Przy dobrym przygotowaniu migracja 5-10 klientów może trwać 2-4 tygodnie. Rotech Group prowadzi tego typu projekty. Skontaktuj się po bezpłatną konsultację wstępną.
ManageEngine SDP MSP integruje się natywnie z Endpoint Central MSP: alerty z monitorowania i zarządzania urządzeniami automatycznie tworzą tickety w SDP MSP z przypisaniem do właściwego tenanta (klienta). Nie tracisz czasu na ręczne przepisywanie alertów, system sam je przetwarza i priorytetyzuje zgodnie z SLA klienta. Integracja z innymi systemami RMM (NinjaRMM, ConnectWise Automate i inne) dostępna jest przez REST API.
Chcesz ocenić, czy Twój MSP jest gotowy na natywny multi-tenant?
Przeprowadzimy bezpłatny przegląd Twojego obecnego stosu ITSM i pokażemy, gdzie tracisz czas na administrację.
Umów bezpłatną konsultacjęPowiązane artykuły
ManageEngine ServiceDesk Plus: cena i wycena Co to jest RMM: przewodnik po Remote Monitoring ManageEngine CVE i bezpieczeństwo: co powinieneś wiedzieć Integracja ERP z helpdeskiem: jak ją zrobićSzukasz rozwiązania ITSM dla swojego MSP? Sprawdź jak wygląda wdrożenie z Rotech Group →