Jeden partner IT czy wielu dostawców? Rachunek jest prosty
Każdy kolejny dostawca IT dodaje do firmy kilka nowych granic odpowiedzialności, a przy awarii na styku systemów koordynację przejmuje zwykle właściciel. Pokazujemy, jak policzyć koszt koordynacji, kto powinien odpowiadać za incydent i w jakich sytuacjach kilku dostawców ma uzasadnienie.

Rano przestaje działać program magazynowy. Firma od oprogramowania mówi, że to problem z siecią. Firma od sieci odpowiada, że łącze działa, a operator potwierdza, że po jego stronie wszystko jest w porządku. Każdy z dostawców ma rację w swoim zakresie, a magazyn stoi do popołudnia, bo nikt nie odpowiada za całość. Taki scenariusz jest w małych firmach typowy i dobrze pokazuje, gdzie leży prawdziwy koszt wielu dostawców IT.
Ile kosztuje koordynacja kilku dostawców IT
Rachunek jest prosty i nie dotyczy stawek godzinowych. Każde dwa systemy obsługiwane przez różnych dostawców tworzą styk, na którym może powstać problem bez właściciela. Liczba takich styków rośnie szybciej niż liczba dostawców:
| Liczba dostawców | Możliwe styki między nimi |
|---|---|
| 2 | 1 |
| 3 | 3 |
| 4 | 6 |
| 5 | 10 |
To proste działanie kombinatoryczne: przy n dostawcach styków jest n razy n minus jeden, podzielone przez dwa. Firma z operatorem, firmą od sieci, dostawcą programu księgowego, serwisem drukarek i informatykiem od komputerów ma dziesięć miejsc, w których awaria może „należeć do kogoś innego”.
Każdy styk kosztuje czas. Ktoś musi mieć kontakty do obu stron, przekazać opis problemu, umówić wspólne połączenie i pilnować, żeby diagnoza się nie zatrzymała. W firmie bez działu IT robi to właściciel albo kierownik biura. Godziny te nie pojawiają się na żadnej fakturze, ale są zwykle droższe niż różnica w cenie między dostawcami.
Kto odpowiada za awarię na styku systemów
W modelu z jednym głównym partnerem IT odpowiedź brzmi: ten partner. Przyjmuje zgłoszenie, diagnozuje, a jeśli przyczyna leży u operatora lub producenta oprogramowania, sam się z nimi kontaktuje i prowadzi sprawę do końca. Firma ma jeden numer i jedną osobę, która odpowiada za informację zwrotną.
W modelu wielu równorzędnych dostawców odpowiedzialność trzeba zapisać. Narzędziem jest macierz odpowiedzialności, czyli tabela, w której dla każdego systemu wskazuje się, kto wykonuje prace, kto zatwierdza zmiany, kogo się konsultuje i kogo informuje. Bez niej każdy dostawca odpowiada wyłącznie za swój fragment, co jest zgodne z jego umową i bezużyteczne dla firmy.
CERT Polska w przewodniku po komunikacji podczas incydentu zaleca, aby przed kryzysem ustalić zakres odpowiedzialności poszczególnych osób, w tym za komunikację z klientami i partnerami biznesowymi. Przy wielu dostawcach oznacza to aktualną listę kontaktów, ścieżkę eskalacji i wskazanie, kto prowadzi incydent, gdy dotyczy kilku systemów naraz.
Jak ta sama awaria wygląda z jednym partnerem IT
Wróćmy do programu magazynowego, który rano przestał działać. Pracownik zgłasza problem w jednym miejscu. Opiekun sprawdza w monitoringu, że serwer działa, a połączenie z bazą danych zrywa się po zmianie reguły zapory, którą dzień wcześniej wprowadził ktoś z zewnątrz. Cofa zmianę i prosi dostawcę oprogramowania o potwierdzenie wymagań dotyczących portów, a firma dostaje jedną informację zwrotną.
Szybsza diagnoza wynika z tego, że jedna osoba widzi sieć, serwer i historię zmian naraz. Przy kilku dostawcach te informacje są w trzech różnych miejscach i ktoś musi je ze sobą zestawić.
Kiedy jeden partner IT jest właściwym wyborem
Jednego głównego partnera rekomendujemy firmom do kilkudziesięciu stanowisk, które nie mają własnego działu IT. Taki partner obsługuje helpdesk, konta w Microsoft 365 lub Google Workspace, komputery, sieć, kopie zapasowe i podstawowe zabezpieczenia. To obszary silnie od siebie zależne: problem z pocztą może wynikać z DNS, problem z drukarką z sieci, a problem z kopią z uprawnień na serwerze.
Jeden partner prowadzi też wspólną dokumentację i stosuje te same standardy we wszystkich obszarach. Przy przeglądzie bezpieczeństwa widzi całość: kto ma konta administracyjne, gdzie są kopie, które urządzenia nie dostają aktualizacji. Przy kilku dostawcach ta wiedza jest rozproszona i nikt nie ma pełnego obrazu.
Na co uważać przy wyborze takiego partnera, opisujemy w artykule jak wybrać firmę do outsourcingu IT.
Kiedy wielu dostawców ma sens
Są sytuacje, w których osobny dostawca jest uzasadniony, a czasem konieczny.
- Specjalistyczne oprogramowanie branżowe. System ERP, program do projektowania czy oprogramowanie medyczne zwykle wspiera producent albo jego autoryzowany partner. Przy enova365 rolę tę możemy pełnić sami jako Autoryzowany Partner enova365 (wdrożenie enova365), przy innych systemach współpracujemy z ich dostawcami.
- Operatorzy i usługi infrastrukturalne. Łącze internetowe, telefonia i dzierżawa drukarek zawsze pozostają u swoich dostawców. Główny partner IT prowadzi z nimi kontakt w imieniu firmy.
- Niezależna kontrola. Audyt bezpieczeństwa albo test penetracyjny wykonany przez firmę, która nie administruje środowiskiem, daje bardziej obiektywny wynik. Rozdzielenie wykonania i kontroli jest tu zaletą.
- Firma z własnym kierownikiem IT. Jeśli w firmie jest osoba, która zarządza dostawcami zawodowo, koszt koordynacji spada, a możliwość wyboru najlepiej dopasowanego wykonawcy do każdego obszaru zyskuje na znaczeniu.
Model główny partner i wyspecjalizowani dostawcy
W większości małych i średnich firm rekomendujemy rozwiązanie pośrednie. Główny partner IT przyjmuje wszystkie zgłoszenia, obsługuje infrastrukturę i koordynuje wyspecjalizowanych dostawców. Dostawcy systemów branżowych odpowiadają za swoje oprogramowanie, a operatorzy za łącza.
Pracownik zgłasza problem zawsze w jednym miejscu i nie musi wiedzieć, czyja to wina. Główny partner ustala przyczynę i przekazuje sprawę dalej, jeżeli leży poza jego zakresem. Liczba styków, którymi musi zajmować się firma, spada do jednego. W umowie warto zapisać, że koordynacja innych dostawców jest częścią usługi, oraz jak liczy się czas reakcji, gdy problem leży po stronie trzeciej. Różnicę między czasem reakcji a czasem naprawy wyjaśniamy w artykule SLA w IT: czas reakcji a czas naprawy.
Dostęp dostawców do systemów firmy
Każdy dostawca z dostępem administracyjnym to kolejne konta i połączenia, które trzeba kontrolować. Brytyjskie NCSC opisuje bezpieczeństwo łańcucha dostaw w 12 zasadach podzielonych na cztery etapy: zrozumienie ryzyka, ustanowienie kontroli, sprawdzanie ustaleń i ciągłe doskonalenie. Wytyczne są pisane z myślą o większych organizacjach, ale ta sama kolejność działa w firmie z kilkoma dostawcami.
W praktyce wymagamy niezależnie od modelu:
- Imiennych kont dla każdego technika z drugim składnikiem logowania, bez wspólnego konta „serwis”.
- Minimalnych uprawnień, przeglądanych przynajmniej raz w roku.
- Zapisu działań administracyjnych tam, gdzie system to umożliwia.
- Odebrania dostępu w dniu zakończenia zlecenia lub umowy.
- Przekazywania haseł przez menedżer haseł. CERT Polska odradza wysyłanie haseł SMS-em lub e-mailem, nawet zaufanej osobie.
Jedno hasło znane kilku firmom uniemożliwia ustalenie, kto wykonał zmianę, która spowodowała awarię.
Jak nie uzależnić się od jednego dostawcy
Najczęstszy argument przeciw jednemu partnerowi to obawa przed uzależnieniem. Jest zasadna, ale rozwiązuje się ją umową i porządkiem, bez dzielenia obsługi między kilka firm.
Konta właścicielskie domen, subskrypcji Microsoft 365 lub Google Workspace i licencji są zarejestrowane na firmę, a dostawca ma do nich dostęp administracyjny. Dokumentacja środowiska jest własnością firmy i aktualizowana na bieżąco. Umowa określa, w jakim terminie i formie dostawca przekaże dane, konfiguracje i dostępy po jej zakończeniu. Przy takich zapisach zmiana dostawcy jest uporządkowanym projektem, takim jak procedura opisana w artykule zmiana firmy IT bez przestoju.
Przegląd współpracy z głównym partnerem robimy raz w roku. Sprawdzamy wtedy, czy dokumentacja jest aktualna, czy lista kont administracyjnych zgadza się ze stanem faktycznym i czy firma potrafiłaby przekazać środowisko innemu wykonawcy bez pomocy obecnego. Jeśli na któreś z tych pytań odpowiedź brzmi „nie”, uzupełniamy braki, zanim staną się problemem.
Pytania przed decyzją
- Ilu dostawców IT ma dziś Wasza firma i kto koordynuje ich pracę?
- Kto prowadził ostatnią awarię dotyczącą dwóch systemów i ile to trwało?
- Czy macie aktualną listę kontaktów i ścieżkę eskalacji dla każdego dostawcy?
- Czy konta właścicielskie i dokumentacja są po stronie firmy?
- Które systemy naprawdę wymagają specjalistycznego dostawcy, a które może obsłużyć jeden partner?
Jeśli odpowiedź na drugie pytanie brzmi „właściciel, przez pół dnia”, rachunek jest już policzony. Zakres, w jakim możemy pełnić rolę głównego partnera IT, opisujemy na stronie stała opieka IT.
Najczęstsze pytania
Czy jeden dostawca IT jest droższy niż kilku?
Na fakturach bywa różnie, bo wyspecjalizowany dostawca może mieć niższą stawkę w swoim obszarze. Po doliczeniu czasu koordynacji i dłuższych przestojów na styku systemów jeden główny partner w małej firmie według naszej oceny zwykle wychodzi taniej.
Czy główny partner IT może współpracować z dostawcą naszego ERP?
Tak, i tak powinno to wyglądać. Partner IT odpowiada za serwer, sieć, kopie i dostęp, a dostawca ERP za program. W umowie zapisujecie, kto kontaktuje się z producentem i kto zatwierdza zmiany.
Kto kontaktuje się z operatorem internetu przy awarii łącza?
W modelu z głównym partnerem robi to partner. Firma upoważnia go do zgłaszania awarii u operatora, przekazuje numer umowy i dane kontaktowe, a partner prowadzi zgłoszenie i informuje, kiedy łącze wróci. Operatorzy przyjmują zgłoszenia od abonenta albo osoby przez niego upoważnionej, więc bez upoważnienia przy każdej awarii i tak dzwoni właściciel.
Źródła
- National Cyber Security Centre, Supply chain security guidance: The principles of supply chain security, https://www.ncsc.gov.uk/collection/supply-chain-security/principles-supply-chain-security (dostęp 2.10.2026)
- CERT Polska, Przewodnik po komunikacji - Baza wiedzy CERT Polska, https://wiedza.cert.pl/obsluga-incydentow/komunikacja/ (dostęp 2.10.2026)
- CERT Polska, Hasła - Baza wiedzy CERT Polska, https://wiedza.cert.pl/dobre-praktyki/hasla/ (dostęp 2.10.2026)
Stan na 2 października 2026 r.