Transparentny proces

Widzisz "wdrożenie IT".
My otwieramy każdy etap.

Q: Co dokładnie dostajemy po każdym etapie?

Discovery: raport z analizą obecnego stanu i zdefiniowanymi problemami. Architektura: dokument projektowy (Architecture Decision Record) z diagramem i uzasadnieniem. Implementacja: skonfigurowane środowisko z protokołem testów. Go-live: działający system produkcyjny + runbook operacyjny + materiały szkoleniowe. Hypercare: raport z pierwszych 4 tygodni + plan utrzymania.

Q: Co się dzieje, jeśli pojawi się problem po go-live?

Przez pierwsze 4 tygodnie po go-live jesteśmy dostępni jak wewnętrzny zespół - SLA godzinowy w godzinach biznesowych, 4h na incydenty krytyczne. Po hypercare: utrzymanie na kontrakcie lub pakiety wsparcia godzinowego. Każde wdrożenie kończymy incident playbook - dokumentem, który opisuje co robić przy typowych awariach, zanim zadzwonisz do nas.

Q: Czy musimy uczestniczyć w całym procesie? Ile czasu to zajmuje naszemu zespołowi?

Minimalnie: 2-3h tygodniowo dla sponsora projektu (decyzje, akceptacje) i 4-6h tygodniowo dla IT leadera (konfiguracja, testy). Warsztaty discovery: 1 dzień. Szkolenia przed go-live: 4-8h dla administratorów, 2h dla użytkowników. Nie wymagamy pełnego zaangażowania - ale projekt bez dostępności decyzyjnej po stronie klienta trwa dłużej.

Q: Co jeśli scope zmieni się w trakcie projektu?

Zmiany scope są normalne - i mamy na to procedurę. Każda zmiana jest oceniana pod kątem wpływu na czas i budżet, a klient dostaje pisemną wycenę w 48h. Drobne zmiany konfiguracyjne (do 2h roboczogodzin) realizujemy w ramach projektu. Istotne zmiany zakresu wymagają aneksu - nigdy nie realizujemy zmian 'na słowo', bo to najczęstsza przyczyna sporów po zakończeniu projektu.

Żadnych czarnych skrzynek. Konkretne kroki, realistyczne terminy, lista tego co dostajesz - i co się dzieje po go-live, kiedy większość vendorów znika.

Omów projekt z nami Zobacz etapy

Przegląd harmonogramu - standardowe wdrożenie ManageEngine SDP (50-600 użytkowników)

Discovery

Architektura

Implementacja

Testy i szkolenia

Go-live

Hypercare + support

Skąd ten proces pochodzi

Ten proces
nie powstał
na szkoleniu.

Przez 10 lat zarządzaliśmy infrastrukturą IT w środowiskach, gdzie przestój ma konsekwencje - nie tylko finansowe. Kliniki, apteki, szkoły, instytucje publiczne. Umowy SLA z realnymi karami za każdą godzinę niedostępności. Awaria aptecznego systemu o 2 w nocy to nie "niski priorytet". Kiedy tak zarządzasz infrastrukturą przez dekadę - inaczej projektujesz procesy wdrożeń.

Rollback plan zanim wciśniemy "start"

W środowiskach medycznych go-live bez procedury cofnięcia to błąd, za który się płaci. Dlatego rollback plan jest gotowy przed go-live - nie "na wszelki wypadek".

Monitoring konfigurowany przed odbiorem - nie po

Widzieliśmy 400 alertów dziennie, których nikt nie czytał. Alert fatigue = brak monitoringu. Dlatego monitoring i alerty to warunek odbioru, nie opcja "do zrobienia potem".

Living documentation przez cały okres utrzymania

Konfiguracja z dnia wdrożenia po 2 latach jest fikcją. Dlatego każda zmiana jest dokumentowana na bieżąco.

Sygnały z pola - bez nazw klientów

Apteka, 5 godzin przestoju. Backup "był skonfigurowany". Restore nie zadziałał - nikt nie weryfikował od 8 miesięcy. Odkryliśmy to podczas audytu przed wdrożeniem. Gdyby nie audyt - odkrycie nastąpiłoby podczas awarii.

Środowisko medyczne, pojedynczy punkt awarii. Cała sieć kliniki zależna od jednego switcha core'owego. Redundancja "planowana od 2 lat". Kosztowna lekcja - serwer wymieniany awaryjnie w weekend.

Przejęcie po poprzednim partnerze. Dokumentacja: jeden plik Word z datą sprzed 3 lat. Jeden admin, który "wszystko wiedział" - odszedł 4 miesiące wcześniej. Środowisko działało, ale nikt nie wiedział dlaczego ani jak długo.

Szkoła, monitoring skonfigurowany. 400+ alertów dziennie. Nikt nie reagował od tygodnia - "tyle ich zawsze jest". Faktyczna awaria przyszła cicho, bez alertu. Szukanie zajęło 3h.

Wdrożenie ITSM, 8 miesięcy po go-live. Vendor odebrał projekt, zapłacony. Klient odkrył, że 40% użytkowników nadal zgłasza mailem - "bo tak jest szybciej". Adopcja: 58%. Nikt nie zmierzył, nikt nie interweniował.

Etap po etapie

Co robimy - i kiedy.
Bez niespodzianek.

Każdy etap ma jasny cel, listę aktywności i coś, co od nas dostajesz na koniec. Jeśli coś wymaga decyzji po Twojej stronie - mówimy to wprost, z wyprzedzeniem.

Przed podpisaniem lub tuż po kickoffie

Discovery - rozumiemy problem, zanim zaproponujemy rozwiązanie

Najpierw słuchamy. Warsztaty z Twoim zespołem IT i business ownerami, przegląd obecnej infrastruktury, rozmowy z użytkownikami końcowymi. Na tym etapie jedynym naszym celem jest zrozumieć, co tak naprawdę jest zepsute - nie to, co jest napisane w zapytaniu ofertowym.

Co robimy

Warsztaty discovery (1 dzień) z IT leaderem i business ownerami
Przegląd obecnych narzędzi i procesów
Rozmowy z użytkownikami końcowymi (minimum 3 role)
Inwentaryzacja integracji i zależności systemowych
Ocena dojrzałości IT i gotowości organizacji do zmiany

Co Ty robisz

Zapewniasz dostęp do IT leadera i 2-3 business ownerów (1 dzień)
Udostępniasz dokumentację obecnych systemów (jeśli istnieje)
Wskazujesz 3-5 "pain points" z Twojej perspektywy
Umożliwiasz rozmowę z wybranymi użytkownikami końcowymi

Ryzyka na tym etapie

Niekompletna wiedza po stronie klienta o własnych procesach - rozwiązujemy przez warsztaty, nie ankiety
Rozbieżność między tym, co mówi IT, a co mówi biznes - dokumentujemy obie perspektywy
Brak jednej osoby z mandatem decyzyjnym - eskalujemy przed startem, nie w połowie

Raport Discovery Mapa problemów i procesów Lista integracji do zbadania Ocena gotowości organizacyjnej Zakres projektu (scope)

Co dostajesz: Pisemny raport z analizą stanu obecnego - nie slajdy marketingowe, ale dokument, na którym możesz podjąć decyzję: czy zakres wdrożenia jest właściwy, czy może trzeba go dostosować. Zatwierdzone na tym etapie scope jest podstawą kontraktu.

Projekt techniczny - zanim ruszy implementacja

Analiza i architektura - projekt, który możesz zakwestionować

Na podstawie discovery projektujemy architekturę rozwiązania. Każda decyzja jest uzasadniona - cloud vs. on-premise, licencje, integracje, deployment model. Dostajesz dokument, który możesz zabrać do swojego architekta IT i zapytać "czy to ma sens".

Co robimy

Projekt architektury systemu (ADR - Architecture Decision Record)
Wybór modelu deployment: cloud SaaS / on-premise / hybrid
Projekt integracji z AD/LDAP, infrastrukturą sieciową, systemami zewnętrznymi
Plan licencyjny (moduły, liczba agentów, progi SLA)
Projekt struktury CMDB i kategorii zgłoszeń
Przegląd architektury z Twoim zespołem - Q&A, korekty

Co Ty robisz

Przegląd dokumentu ADR (2-3h IT leadera)
Decyzja cloud vs. on-premise (jeśli nie była w scope)
Potwierdzenie planu licencyjnego
Akceptacja struktury CMDB i kategorii zgłoszeń
Wskazanie okna maintenance dla instalacji

Ryzyka na tym etapie

Odkrycie nowych zależności technicznych - obsługujemy przez ADR revision, nie zaskoczenie na produkcji
Zmiana decyzji cloud/on-prem po fazie discovery - możliwe, ale wymaga rewizji scope
Niejasne wymagania bezpieczeństwa/compliance - weryfikujemy z Twoim security teamem

Architecture Decision Record (ADR) Diagram architektury Plan licencyjny Projekt integracji Projekt CMDB Harmonogram projektu (Gantt)

Co dostajesz: Dokument projektowy, który pozostaje Twój niezależnie od dalszych losów projektu. Jeśli zdecydujesz się na innego partnera - masz gotowy blueprint architektury. Jeśli projekt startuje - ADR jest umową techniczną między nami a Twoim zespołem.

Główna faza techniczna - tu dzieje się 70% pracy

Implementacja - konfiguracja, integracje, migracja danych

Instalacja, konfiguracja zgodna z ADR, integracje z istniejącym ekosystemem, migracja danych historycznych (jeśli w scope). Raporty tygodniowe - co zrobione, co dalej, czy coś blokuje. Zmiany poza scope wyceniamy w 48h, nigdy nie realizujemy "po cichu".

Co robimy

Instalacja i konfiguracja bazowa środowiska
Konfiguracja ról, uprawnień, workflow i eskalacji SLA
Integracja z Active Directory / Azure AD
Integracje z systemami zewnętrznymi (ERP, monitoring, email)
Migracja danych historycznych (tickety, CMDB, KB) - jeśli w scope
Konfiguracja monitoringu i alertów operacyjnych
Cotygodniowe statusy z raportem postępu

Co Ty robisz

Dostęp administratora do środowisk (AD, sieć, serwery)
Przegląd i akceptacja konfiguracji co tydzień (1-2h IT leadera)
Decyzje o zmianach scope (z 48h wyprzedzeniem od nas)
Udostępnienie danych do migracji w uzgodnionym formacie
Wyznaczenie 1-2 "power users" do pre-testów

Ryzyka na tym etapie

Niespójność danych do migracji - audytujemy dane przed migracją, nie liczymy na "jakoś będzie"
Zmiany scope mid-sprint - każda zmiana przez formal change request
Zależność od zewnętrznych systemów (API niedostępne, legacy) - identyfikujemy w discovery, planujemy obejście

Skonfigurowane środowisko produkcyjne Raport z testów integracji Dokumentacja konfiguracji Zamigrowane dane (historyczne) Tygodniowe raporty statusu

Co dostajesz co tydzień: Krótki raport (max. 1 strona) - co zostało zrobione, co jest na tapecie, jakie decyzje są potrzebne po Twojej stronie i czy harmonogram jest zachowany. Jeśli coś jest opóźnione - piszemy o tym pierwsi, nie czekamy aż zapytasz.

UAT i przygotowanie do go-live

Testy i szkolenia - system weryfikowany przez ludzi, nie tylko narzędzia

User Acceptance Testing z udziałem Twoich użytkowników - nie testy deweloperskie. Scenariusze testowe oparte na rzeczywistych przypadkach z Twojej organizacji. Szkolenia dla administratorów i użytkowników końcowych. I jeden element, który większość vendorów pomija: ćwiczenie scenariusza awaryjnego przed go-live.

Co robimy

Przygotowanie scenariuszy testowych UAT (na podstawie Twoich procesów)
Wsparcie UAT z Twoim zespołem (weryfikacja, naprawa błędów)
Szkolenie administratorów systemu (4-6h, nagrywane)
Szkolenie użytkowników końcowych (2h, skrypt + nagranie)
Ćwiczenie scenariusza incydentowego - "co robimy gdy X padnie"
Konfiguracja monitoringu produkcyjnego i alertów

Co Ty robisz

Zapewniasz 3-5 użytkowników do UAT (po 2-4h każdy)
Zbierasz feedback z UAT i zgłaszasz do nas priorytetowo
Uczestniczysz w ćwiczeniu incydentowym (IT leader + 1 admin)
Komunikujesz go-live do organizacji (my pomagamy z treścią)

Ryzyka na tym etapie

Niedostępność użytkowników do UAT - planujemy UAT z 2-tygodniowym wyprzedzeniem
Krytyczny bug odkryty w UAT - mamy priorytet bugfix, nie odkładamy na "po go-live"
Słaba frekwencja na szkoleniach - nagrywamy wszystko, materiały online dostępne po szkoleniu

Protokół UAT z wynikami Nagrania szkoleń admin Nagrania szkoleń użytkowników Incident playbook (v1) Plan komunikacji go-live Checklist gotowości go-live

Ćwiczenie incydentowe: Symulujemy jeden typowy incydent produkcyjny - np. niedostępność serwera, błąd integracji AD - i przechodzimy przez procedurę razem z Twoim zespołem. Celem jest to, żeby pierwsza prawdziwa awaria nie była pierwszą lekcją reagowania.

Przełączenie na produkcję

Go-live - przełączamy, monitorujemy, korygujemy

Go-live to nie koniec projektu - to początek operacji. Przełączamy w oknie maintenance (zazwyczaj wieczór lub weekend), przez 48h jesteśmy dostępni na bieżąco, a przez kolejne 4 tygodnie w trybie podwyższonej gotowości. Rollback plan jest gotowy, zanim wciśniemy "start".

Co robimy

Finalna weryfikacja checklist gotowości (dzień przed)
Przełączenie na produkcję w uzgodnionym oknie maintenance
Monitoring przez pierwsze 48h - jesteśmy dostępni
Korekta konfiguracji na podstawie pierwszych danych produkcyjnych
Komunikacja do użytkowników (we współpracy z działem HR i komunikacji)
Aktywacja monitoringu i dashboardów operacyjnych

Co Ty robisz

Zatwierdzasz datę i okno go-live minimum 7 dni wcześniej
Zapewniasz dostępność IT leadera przez pierwsze 48h po go-live
Komunikujesz zmianę do użytkowników (materiały od nas)
Zbierasz feedback z pierwszych dni produkcji

Ryzyka na tym etapie

Nieoczekiwany problem produkcyjny - rollback plan gotowy, czas wykonania max. 2h
Niski wskaźnik adopcji w pierwszych dniach - to normalne, interweniujemy z komunikacją i micro-szkoleniami
Problem z integracją zewnętrzną po go-live - eskalacja do vendora z naszym udziałem

Protokół go-live Raport z pierwszych 48h Aktywny monitoring produkcyjny Rollback plan (na wypadek cofnięcia)

Rollback plan: Zanim włączymy produkcję, mamy gotową procedurę cofnięcia zmian - snapshot środowiska, lista kroków, czas wykonania. Nie liczymy na to, że wszystko pójdzie dobrze. Przygotowujemy się na scenariusz, że nie pójdzie.

Hypercare · Utrzymanie lub kontrakt wsparcia

Hypercare i support - tu jesteśmy, gdy inni już znikają

Hypercare to nie "helpdesk na 2 tygodnie". To aktywna asekuracja: monitorujemy KPI systemu, reagujemy na sygnały zanim staną się incydentami, doszkalamy użytkowników tam gdzie pojawiają się luki. Po hypercare: kontrakt utrzymania lub pakiet godzin wsparcia - decyzja po Twojej stronie, bez presji.

Co robimy (hypercare)

Monitoring KPI systemu: czas odpowiedzi, wskaźnik adopcji, SLA breach
Cotygodniowe call statusowe z IT leaderem
Micro-korekty konfiguracji na podstawie pierwszych danych
Doszkalanie użytkowników, gdzie pojawiają się luki
Weryfikacja, że monitoring i alerty działają poprawnie
Raport końcowy z pierwszych 4 tygodni operacji

Co Ty robisz

Zbierasz i przekazujesz feedback od użytkowników co tydzień
Uczestniczysz w tygodniowych callach (30 min)
Decydujesz o modelu wsparcia po hypercare (bez presji)
Aktualizujesz wewnętrzną dokumentację procesów

Ryzyka na tym etapie

Niska adopcja - aktywna interwencja w pierwszych 2 tygodniach jest decydująca
Zakopanie się w nawykach (stary system "obok") - identyfikujemy i adresujemy natychmiast
Odejście kluczowego admina po go-live - living documentation + nagrania szkoleń chronią przed tym scenariuszem

Raport hypercare (4 tygodnie) Living documentation (finalna) Runbook operacyjny Incident playbook (finał) Plan utrzymania i roadmapa

Po hypercare: Nie zostawiamy Cię bez niczego. Masz do wyboru: kontrakt utrzymania (SLA godzinowy), pakiety godzin wsparcia (prepaid, bez zobowiązań miesięcznych) lub "ad-hoc" - zadzwoń kiedy potrzebujesz, wyceniamy projekt. Żaden wariant nie jest wymagany do zamknięcia projektu.

Krytyczny etap - tu rodzi się sukces lub porażka wdrożenia

Co się dzieje po go-live.
To jest ważniejsze niż samo wdrożenie.

Większość vendorów optymalizuje pod odbiór projektu. My optymalizujemy pod to, żeby system działał za rok. Te dwa cele są różne - i przekładają się na różne decyzje przez cały projekt.

Stabilizacja i korekta konfiguracji

Pierwsze dane produkcyjne ujawniają to, czego nie widać w testach. Kategoryzacja zgłoszeń nie pasuje do rzeczywistości? Poprawiamy. SLA zbyt restrykcyjne dla jednej grupy użytkowników? Kalibrujemy. Micro-korekty na tym etapie kosztują godziny - te same zmiany po 3 miesiącach kosztują dni.

Wskaźnik adopcji - najważniejsza metryka

Mierzymy, jaki % zgłoszeń idzie przez system, a jaki nadal mailem. Identyfikujemy zespoły z niską adopcją i adresujemy to konkretnie - dodatkowe mini-szkolenie (30 min), materiał wideo, rozmowa z managerem. Ignorowanie adopcji w pierwszych 4 tygodniach to najczęstszy błąd po go-live.

Raport operacyjny + plan na 6 miesięcy

Podsumowanie: co zadziałało, co wymagało korekty, jakie metryki osiągnięto vs. zakładano. I rekomendacja na kolejne 6 miesięcy: które moduły warto dodać, gdzie jest optymalizacja, jakie integracje mają sens. Nie żeby sprzedać - żeby mieć roadmapę, którą możesz zaakceptować lub odrzucić.

Living documentation - system wiedzy, który żyje

Konfiguracja ewoluuje - dokumentacja musi za nią nadążać. Co miesiąc aktualizujemy ADR o zmiany, które weszły w życie. Po 3 miesiącach każda zmiana jest udokumentowana.

Weryfikacja SLA i optymalizacja workflow

Po 3 miesiącach danych widać, które SLA są realistyczne, a które są deklaratywne. Które workflow są używane, a które omijane. Robimy przegląd i rekomendujemy konkretne zmiany. System ITSM, który jest skonfigurowany "na papier", nie daje żadnej wartości.

Incident response - zanim zadzwonisz do nas

Każde wdrożenie kończymy incident playbook: co robisz sam w pierwszych 15 minutach każdej typowej awarii, kiedy eskalujesz do nas i jak (telefon / ticket / email zależnie od severity). Pierwsza awaria produkcyjna nie powinna być pierwszą lekcją reagowania.

Zarządzanie ryzykiem

Rzeczy, które się psują.
I jak je obsługujemy.

Każdy projekt ma ryzyka. Różnica między dobrym a złym vendorem to nie "my nie mamy ryzyk" - to przejrzystość w tym, jakie ryzyka identyfikujemy i jak są zarządzane.