We wdrożeniu i utrzymaniu EZD RP biorą udział cztery strony: urząd (klient), wykonawca wdrożenia (firma zewnętrzna), NASK PIB (producent systemu) i — w modelu SaaS/Private SaaS — dostawca infrastruktury chmurowej. Niejasny podział odpowiedzialności prowadzi do sytuacji, w której każda strona uważa, że problem należy do kogoś innego. Poniżej praktyczna matryca.
Kto jest kim
| Strona | Rola | Charakter relacji |
|---|---|---|
| Urząd / jednostka | Klient — odpowiada za użycie systemu i własne procesy | Decydent + użytkownik |
| Wykonawca wdrożenia | Firma realizująca wdrożenie i wsparcie (np. Lynx360) | Umowa odpłatna na podstawie PZP |
| NASK PIB | Producent EZD RP — utrzymanie kodu, aktualizacje, dokumentacja | Brak relacji umownej z urzędem (program rządowy) |
| Dostawca chmury (przy SaaS) | Hosting infrastruktury — Min. Cyfryzacji (KPO) lub komercyjny | SLA dostępności |
Macierz odpowiedzialności RACI — kluczowe obszary
R = Responsible (wykonuje), A = Accountable (odpowiada), C = Consulted (konsultowany), I = Informed (informowany).
| Obszar | Urząd | Wykonawca | NASK | Dostawca chmury |
|---|---|---|---|---|
| Decyzja o wdrożeniu | A | C | I | I |
| Wybór modelu (SaaS/on-premise) | A | C | I | I |
| Audyt przedwdrożeniowy | A | R | I | I |
| Aktualizacja JRWA | A | C | I | I |
| Konfiguracja infrastruktury (on-premise) | I | R/A | I | — |
| Konfiguracja infrastruktury (SaaS) | I | C | I | R/A |
| Wgranie aktualizacji EZD RP | I | R | A (publikacja wersji) | C (SaaS) |
| Zgłoszenia użytkowników (1 linia) | C | R/A | I | I |
| Eskalacja błędu kodu EZD RP | I | R | A (fix w kodzie) | I |
| Awaria infrastruktury (SaaS) | I | C | I | R/A |
| Awaria infrastruktury (on-premise) | C | R/A | I | — |
| Backup | C | R/A | I | R (SaaS) |
| Bezpieczeństwo / RODO danych w systemie | A | R | C | C |
| Konfiguracja KSeF (certyfikat, konto) | A | R | I | I |
| Konfiguracja e-Doręczeń (skrzynka, BAE) | A | R | I | I |
| Szkolenia użytkowników | A | R | I | I |
| Komunikacja zmiany do pracowników | A | C | I | I |
| Migracja danych ze starego systemu | C | R/A | I | I |
| Audyt powdrożeniowy | A | R | I | C |
| Aktualizacja dokumentacji wewnętrznej urzędu | R/A | C | I | I |
Częste spory graniczne
System nie działa — czyja to wina
Schemat diagnostyki:
- Czy infrastruktura jest dostępna? (sprawdź monitoring) → Jeśli nie: dostawca chmury (SaaS) lub wykonawca (on-premise)
- Czy konfiguracja jest poprawna? (logi, sekretne klucze, certyfikaty) → wykonawca
- Czy to bug w kodzie EZD RP? → eskalacja do NASK przez wykonawcę (urząd nie kontaktuje się bezpośrednio z NASK)
- Czy to błąd procedury / użycia? → szkolenie / dokumentacja → urząd + wykonawca
Kto kontaktuje się z NASK?
Z zasady — wykonawca. NASK PIB nie świadczy bezpośredniego wsparcia technicznego dla użytkowników końcowych. Urząd zgłasza problem wykonawcy, wykonawca eskaluje do NASK przez kanały dla integratorów / wdrożeniowców (forum, kontakt techniczny, zgłoszenia).
Kto aktualizuje JRWA?
Formalnie urząd (sekretarz, koordynator kancelaryjny) — to jest wewnętrzny dokument jednostki. Wykonawca może doradzać i konfigurować technicznie w EZD RP, ale nie może sam zmieniać klasyfikacji bez decyzji urzędu (to byłoby wkroczenie w odpowiedzialność administracyjną jednostki).
Co warto zapisać w umowach
Umowa urząd ↔ wykonawca
- Zakres prac (audyt / konfiguracja / migracja / szkolenia / wsparcie)
- SLA wsparcia (czas reakcji per kategoria zgłoszenia)
- Procedura eskalacji do NASK
- Odpowiedzialność za bezpieczeństwo i ochronę danych (RODO, umowa powierzenia)
- Aktualizacje EZD RP (czy w cenie, kto wgrywa)
- Backup i odtwarzanie (kto, jak często, gdzie)
- Procedura odbioru i kar umownych
- Klauzula wyjścia (co dzieje się po zakończeniu umowy — eksport danych, dokumentacja)
Relacje z dostawcą chmury (SaaS)
- SaaS w KPO: relacja z Ministerstwem Cyfryzacji — bezpośrednio przez gov.pl, brak umowy z dostawcą infrastruktury
- SaaS komercyjny: umowa z dostawcą + SLA dostępności + miejsce przechowywania danych (lokalizacja serwerów)
- Private SaaS (firma wdrożeniowa hostuje): wszystkie zobowiązania w umowie z wykonawcą
- EZD RP — odpowiedzialność programu (gov.pl) →gov.pl / NASKRola NASK PIB i Min. Cyfryzacji
- Kanały kontaktu dla wykonawców
- Forum EZD RP →gov.pl / NASKSpołeczność wdrożeniowców
- Ustawa o RODO →akt prawnyWymogi umowy powierzenia danych
Audyt obecnych umów + propozycja klauzul + matryca RACI dostosowana do Waszej organizacji.
Umów konsultacjęNajczęstsze pytania
Czy NASK ma SLA wobec urzędu?
Nie ma bezpośredniego SLA — NASK PIB jest producentem programu rządowego, nie dostawcą usługi. Wykonawca wdrożenia odpowiada za wsparcie operacyjne, eskalacja do NASK idzie przez wykonawcę.
Co jeśli wykonawca obwinia NASK za błąd, a NASK twierdzi, że to konfiguracja?
To częsty problem. Rozwiązanie: w umowie z wykonawcą zapisać odpowiedzialność za diagnozę — wykonawca musi wykazać, że problem jest po stronie kodu (np. zgłoszeniem na forum NASK z odpowiedzią), zanim odeśle sprawę.
Czy w SaaS w KPO mogę wybrać innego wykonawcę wdrożenia?
Tak — SaaS w KPO to tylko infrastruktura. Wdrożenie (audyt, konfiguracja, szkolenia, integracje) jest niezależne i wybierasz wykonawcę przez postępowanie publiczne.
Kto odpowiada za incydent bezpieczeństwa?
Urząd jest administratorem danych osobowych (RODO) i odpowiada wobec UODO. Wykonawca jako podmiot przetwarzający odpowiada zgodnie z umową powierzenia. NASK i dostawca chmury — w zakresie określonym ich rolą (kod / infrastruktura).