Pracownik przychodzi i mówi: „Potrzebuję laptop". Bez request fulfillment to zgłoszenie idzie mejlem, czeka się 3 dni na odpowiedź, a potem jeszcze 2 dni na realizację. Z request fulfillment — wpina się w katalog, zatwierdzenie przez managera, realizacja w 1 dzień. Request fulfillment to proces, który standaryzuje dostarczanie usług IT zamiast robić to na „poproszę", bez procedury. W tym artykule pokazuję czym jest katalog usług IT, jak go zbudować, i jak zwiększyć self-service adoption żeby mniej requestów trafiało do techników.
Request vs Incident — czemu to inna kategoria i dlaczego to ważne
To gdzie większość firm się psuje. Mają incydent management zadziałany, ale wszystkie requesty trafiają do tego samego backloga co incydenty — i gubiąc się, bo mają różne SLA i różne procesy.
Incydent: Sieć pada. Drukarka nie drukuje. System ERP jest offline. Użytkownik nie może pracować. To reaktywne, ktoś jest zły, MTTR liczy się w godzinach.
Request: Pracownik nowy potrzebuje laptop. Chcę nową licencję Visio. Potrzebuję dostępu do SharePointa zespołu marketingu. Użytkownik coś chce, to proaktywne, fulfillment time to dni, nie godziny.
Konsekwencje mieszania requestów z incydentami:
- Request czeka jako incident — priorytet robi się chaos
- SLA dla requestu 5 dni vs incident 2 godziny — którego się trzymasz?
- Analityka nie pokazuje co jest requestem a co incydentem
- Technicy robią „na szybko" bez procedury
Service Portfolio vs Service Catalog — co się oferuje a co jest dostępne
Service Portfolio: to WSZYSTKO co IT teoretycznie może oferować. Zawiera:
- Pipeline: usługi w planie (nowy system CRM w Q4)
- Live: usługi dostępne teraz (Active Directory, Office365, Jira, VPN)
- Retired: usługi wycofane (stary Exchange server, StarOffice)
Service Catalog: to podzbiór Portfolio — tylko usługi dostępne TERAZ, których użytkownik może zamówić. Dla pracownika — katalog jest tym co widzi. Dla managera IT — portfolio to strategia.
Przykład: IT Portfolio zawiera „Custom development" jako potential service. Ale Custom development nie jest w Catalog bo nie macie kapacytetu. Ktoś z marketingu szuka custom dashboard — patrzy w Catalog, nie widzi, pyta CD czy mogą, odpowiedź „NIE". Zamiast tego mogą zaproponować gotowy Tableau license.
Top 5 requestów — co faktycznie zamawiają pracownicy w IT
1. Provisioning (40%)
Nowe konto w Active Directory, email, dostęp do systemów. Pracownik pierwszy dzień = 5–10 requestów jednocześnie.
- Czas: 1 dzień (jeśli zautomatyzowane)
- Effort: proceduralne, powtarzalne
- Best practice: workflow automation
2. Hardware (15–20%)
Nowy laptop, monitor, klawiatura. Upgrade RAM. Wymiana łamanych urządzeń.
- Czas: 3–5 dni (musi być na zamówienie)
- Effort: budżetowe + procurement
- Best practice: katalog ze specyfikacjami (Dell, Lenovo models)
3. Software Licenses (10–15%)
Nowa licencja Office, Visio, Slack, JetBrains IDE, Adobe Creative Suite.
- Czas: 1–2 dni (czekamy na delivery key/download)
- Effort: approval + compliance check
- Best practice: katalog ze wskazaniem kiedy kupić, kiedy nie
4. Access / Permissions (15%)
Dostęp do SharePointa zespołu, bazy danych, projektu Jira, folder sieciowy.
- Czas: kilka godzin (jeśli approval jest szybki)
- Effort: techniczne + compliance
- Best practice: manager approval + audit trail
Jak budować katalog usług — praktycz struktura
Katalog nie można skleić z nicości. Musi vyrośnie z rzeczywistych requestów które robisz.
- Audit: weź ostatnie 6 miesięcy ticketów, sklasyfikuj je na requestów vs incydentów (może 40/60). Pogrupuj requesty po kategorii. Pokaż top 10 kategorii.
- Konsolidacja: Z top 10 kategorii, zrób „usługę katalogową". Np. zamiast 15 żółnych requestów „potrzebuję konto", zrób jedną usługę „New Employee Onboarding" z formularzem.
- Szablon żądania: Dla każdej usługi katalogowej, stwórz formularz z polami. Np. dla „New Laptop":
- Employee name
- Department
- Laptop model (dropdown: Dell XPS 13, Lenovo ThinkPad, Apple MacBook)
- OS preference (Windows / Mac / Linux)
- Addons (second monitor, docking station)
- Workflow: Kto zatwierdza? Manager pracownika? IT Lead? Finance (dla budżetu)? Ustaw workflow approval dla każdej usługi.
- Fulfillment: Co dzieje się po zatwierdzeniu? Dla „New Laptop" — kto robi? Kto komunikuje się z pracownikiem? Czy to assignment do technika czy to procederuje automatycznie do procurement?
Katalog w ManageEngine SDP to moduł Service Catalog. Zaloguj się w Admin > Service Catalog i dodaj usługi.
Workflow request fulfillment — 5 kroków od zamówienia do realizacji
Krok 1: Request submission — Pracownik wpina request przez self-service portal lub mejl. Request ma ID (SR-1234) i status „New".
Krok 2: Routing & validation — System czy request jest kompletny (wszystkie pola wypełnione?). Router system czy zapytanie pasuje do procesu/workflow (czy jest w katalog?). Request zmienia status na „Assigned".
Krok 3: Approval — Zależy od usługi. Dla „nowy laptop" — musi manager. Dla „dostęp SharePoint" — musi team lead. Request czeka na approval, pracownik czeka (SR-1234 status: Approval). Po zatwierdzeniu — status „Approved".
Krok 4: Fulfillment — IT team robi pracę. Procure laptop, install software, set up account, etc. Jeśli jest to routine, może być sautomatyzowane (workflow rules). Request status: „In Progress".
Krok 5: Closure & verification — Pracownik potwierdza że dostał to co zamówił. Czy laptop się włącza? Czy konto działa? Request zmienia status na „Closed". Metryka: czas od New do Closed = fulfillment time (avg 2–5 dni).
Self-service portal — jak zwiększyć adoption i zmniejszyć mejle
Zmotywuj ludzi żeby używali portal zamiast mejla. Jak?
- Kampania świadomości: email + plakat + video 2min showing how to submit request w portalu. Pokaż że to szybsze niż mejl.
- UX portal musi być super: 2–3 klikni do requestu, nie 10. Portal musi mieć search „find service" (np. „laptop" i pokaż laptopy do zamówienia).
- Feedback loop: Po zatwierdzeniu requestu, pošli notifikację zaraz. Po fulfillment, pošli notyfikację. Pracownik widzi — mój request jest w transit.
- Gamification (optional): „W tym miesiącu 45% employeeów użyło portal. Dzięki temu zaoszczędziliśmy 20 godzin czasu IT. Dalej tak!"
- Disable alternative submission paths: Po Launch portal, nie robi mejli na helpdesk@... — forward je do portalu. Wymusza adopcję.
Metryki request fulfillment — co śledzić
KPI #1: Request fulfillment time — średni czas od submission do closure. Target: 2–5 dni (w zależności od typu). Měřit per category (laptop: 4 dni, access: 0.5 dnia).
KPI #2: Self-service adoption rate — % requestów przez portal vs mejl/phone. Target: 40–60% w 6 miesięcy. Track trend — powinno rosnąć.
KPI #3: Request volume per employee per month — baseline to 0.3–0.5 req/person/month. Jeśli masz 300 osób — 90–150 requestów/miesiąc to normalne. Jeśli masz 5000+ to coś jest nie tak (albo incydenty się mylą z requestami).
KPI #4: Approval rate & escalations — % requestów które przechodzą approval bez eskalacji. Target: 85%+. Jeśli mniej, workflow approval jest Source of bottleneck.
KPI #5: Customer satisfaction — Co myśli pracownik o usłudze? Po closure, send quick NPS survey: „Czy request został spełniony?" (Yes/No). Target: 80%+ yes.
FAQ
Jaka jest różnica między Service Catalog a Portfolio IT?
Service Portfolio to wszystkie usługi IT które oferujesz (lub planujesz oferować), niezależnie od stanu (pipeline, live, retired). Service Catalog to podzbiór Portfolio — tylko usługi dostępne teraz, gotowe do zamawiania. Catalog to to co widzi użytkownik. Portfolio to planowanie IT (biznesowe).
Ile requestów to „normalne" w firmie 300-osobowej?
Średnia to 30–60 requestów na 100 pracowników na miesiąc. Dla firmy 300-osobowej: 90–180 requestów/miesiąc. Requestów typu „laptop do nowego pracownika" powinno być ~3–5% wszystkich ticketów. Jeśli masz 5000+ ticketów rocznie i <100 to requestów, coś nie działa — albo request fulfillment jest źle zdefiniowany, albo ludzie go nie znają.
Czy request to to samo co incident?
Nie. Incident = coś się zepsuło (przywracać usługę). Request = coś chce nowy (zaopatrywać usługę). Request ma inny workflow, inne SLA (nie MTTR tylko fulfillment time), inne metryki. W ManageEngine SDP to różne moduły (Incident Management vs Request Management).
Jak zmotywować ludzi do korzystania z self-service portal zamiast maila?
1) Portal musi być znany — kampania email + plakaty, 2) portal musi być łatwy (2–3 klikni do requestu), 3) portal musi być szybki (approval w <1 dzień), 4) komunikuj efekty: „Po 3 miesiącach portal adoption 35%, average fulfillment time spada z 5 dni na 2 dni", 5) zachęcaj (monthly raport użytkownikom co zaoszczędzili czasu).
Jakie są główne requesty w IT?
Top 5: 1) Nowe konto użytkownika / provisioning (30–40% requestów), 2) Laptop / hardware (15–20%), 3) Oprogramowanie licencji (10–15%), 4) Reset hasła mogą zautomatyzować — to nie request (5%), 5) Dostęp do systemu / permissioning (10–15%). Reszta: zmiana konfiguracji, setup email, VPN.
Powiązane artykuły
Self-service portal IT — strategia wdrożenia i adopcji Knowledge Base w helpdesk — jak zmniejszyć powtarzające się zgłoszenia Incident management w produkcji — severities i priorytetyChcesz zbudować katalog usług IT dla swojej firmy?
Rotech Group przeprowadzi audit requestów, zbuduje katalog w ManageEngine SDP, skonfiguruje self-service portal i przeszkoliści zespół. Gwarancja zmniejszenia fulfillment time do 3 dni.
Umów konsultację →