Zarząd MediFlow chciał „cyfrowej transformacji rejestracji”. Brzmiało ambitnie, kosztowało budżet jak mały dom i nikt nie potrafił powiedzieć, co konkretnie ma się zmienić. Poprosiłem o jedną rzecz przed wydaniem pierwszej złotówki: zróbmy analizę luk. Po dwóch tygodniach mieliśmy tabelę z 14 wierszami - 14 konkretnych różnic między tym, jak rejestracja działa dziś, a tym, jak ma działać. Nagle „transformacja” przestała być hasłem, a stała się listą. A listę da się wycenić, podzielić i odhaczać.
Gap analysis - analiza luk - to jedna z najprostszych i najczęściej niedocenianych technik w arsenale analityka. Jej idea jest banalna: opisujesz, gdzie jesteś (stan As-Is), opisujesz, gdzie chcesz być (stan To-Be), a to, co między nimi, to luki do zamknięcia. Diabeł, jak zwykle, tkwi w tym, jak to zrobić, żeby wynik był listą działań, a nie kolejną prezentacją do szuflady. W tym artykule przejdę z Tobą przez całą metodę krok po kroku, na spójnym przykładzie systemu rezerwacji wizyt firmy MediFlow.
Czym jest gap analysis i kiedy ją stosować
Gap analysis to systematyczne porównanie stanu obecnego ze stanem pożądanym w celu zidentyfikowania różnic (luk) i zaplanowania działań, które te różnice zamkną. Stosujesz ją, gdy:
- organizacja chce się gdzieś przesunąć, ale nie wie, co konkretnie ją dzieli od celu,
- oceniasz, czy nowy system pokryje wszystkie obecne i przyszłe potrzeby (fit-gap analysis przy wdrożeniach gotowego oprogramowania),
- sprawdzasz zgodność z normą lub regulacją (np. RODO) - luka to każdy wymóg, którego jeszcze nie spełniasz,
- uzasadniasz projekt przed zarządem - lista luk to gotowa lista korzyści, które przyniesie inwestycja.
Gap analysis jest tak dobra, jak dobry jest opis stanu obecnego. Większość nieudanych analiz luk poległa nie na wizji przyszłości, lecz na tym, że nikt rzetelnie nie opisał, jak naprawdę działa „dziś” - opierano się na tym, jak proces miał działać według procedury, a nie jak działa naprawdę.
Cztery kroki gap analysis
Krok 1: Opisz stan obecny (As-Is)
To fundament. Opisujesz rzeczywistość - nie procedurę, nie wyobrażenie, tylko to, co dzieje się naprawdę. Źródła: wywiady, obserwacja, dane systemowe, mapa procesu As-Is. W MediFlow stan obecny rejestracji wyglądał tak: pacjent dzwoni (jedyny kanał), rejestratorka ręcznie sprawdza grafik w Excelu, zapisuje wizytę, nie ma automatycznych przypomnień, odwołania też tylko telefonicznie, brak danych o no-show.
Najważniejsze: opisuj mierzalnie tam, gdzie się da. Nie „długi czas oczekiwania na połączenie”, tylko „średni czas oczekiwania na infolinii: 6 minut, 40% połączeń w godzinach 8-10”.
Trzy źródła, których używam do rzetelnego As-Is, bo żadne pojedyncze nie wystarcza:
- Co ludzie mówią - wywiady i warsztaty. Pokazują, jak proces jest postrzegany, ale bywają ubarwione lub idealizowane.
- Co ludzie robią - obserwacja na żywo. Najcenniejsza, bo ujawnia kroki, których nikt nie opisuje, bo „przecież to oczywiste”. To tu znajdujesz ręczne obejścia i shadow-procesy.
- Co mówią dane - logi, statystyki, raporty z systemów. Twardy grunt, który weryfikuje opowieści. Gdy rejestratorka mówi „dużo telefonów”, dane mówią „6 200 połączeń miesięcznie, 40% w godzinach 8-10”.
Triangulacja tych trzech źródeł chroni przed najczęstszą pułapką: opisaniem procesu takim, jakim go sobie wszyscy wyobrażają, a nie takim, jaki jest. Gdy opis z wywiadu rozjeżdża się z danymi, prawda zwykle leży w obserwacji.
Krok 2: Zdefiniuj stan docelowy (To-Be)
Teraz przyszłość - konkretna i mierzalna. To-Be MediFlow: pacjent rezerwuje, przekłada i odwołuje wizyty online (24/7), system wysyła automatyczne przypomnienia SMS na 24h przed wizytą, grafik aktualizuje się w czasie rzeczywistym, panel pokazuje statystyki no-show. Cel mierzalny: odciążyć infolinię o 50% w 6 miesięcy, obniżyć no-show z 18% do 10%.
Bez mierzalnego celu nie poznasz, czy luka została zamknięta. „Lepsza rejestracja” to nie cel To-Be. „No-show poniżej 10%” - to jest cel.
Krok 3: Zidentyfikuj luki
Luka to każda różnica między As-Is a To-Be. Zestaw je w tabeli - to serce całej analizy:
| Obszar | As-Is (dziś) | To-Be (cel) | Luka do zamknięcia |
|---|---|---|---|
| Kanał rezerwacji | Tylko telefon | Online 24/7 + telefon | Brak modułu rezerwacji online |
| Przekładanie wizyt | Telefonicznie | Samoobsługa online | Brak funkcji przełożenia |
| Przypomnienia | Brak | SMS 24h przed | Brak integracji z bramką SMS |
| Aktualizacja grafiku | Ręcznie w Excelu | Czas rzeczywisty | Brak centralnej bazy terminów |
| Dane o no-show | Brak | Panel statystyk | Brak rejestrowania i raportowania no-show |
Krok 4: Zaplanuj zamknięcie luk i priorytetyzuj
Każda luka dostaje działanie, oszacowanie wysiłku i priorytet. Nie wszystkie luki są równe - niektóre dają dużą wartość małym kosztem, inne odwrotnie. Tu wchodzi priorytetyzacja: która luka, zamknięta najpierw, da największy zwrot? W MediFlow przypomnienia SMS okazały się małą integracją o ogromnym wpływie na no-show - więc poszły pierwsze, mimo że „transformacja” brzmiała jak budowa wszystkiego naraz.
Macierz wpływ vs wysiłek - jak przełożyć luki na kolejność prac
Sama tabela luk nie mówi, od czego zacząć. Do tego służy prosta macierz dwuwymiarowa: na jednej osi wpływ (ile wartości daje zamknięcie luki), na drugiej wysiłek (ile kosztuje). Powstają cztery ćwiartki:
| Ćwiartka | Wpływ × Wysiłek | Co z tym zrobić |
|---|---|---|
| Szybkie wygrane | Duży wpływ, mały wysiłek | Rób natychmiast - to dowód wartości projektu |
| Projekty główne | Duży wpływ, duży wysiłek | Planuj, dziel na etapy, to sedno transformacji |
| Wypełniacze | Mały wpływ, mały wysiłek | Rób mimochodem, gdy jest okazja |
| Pułapki | Mały wpływ, duży wysiłek | Odłóż lub w ogóle nie rób - to pożeracze budżetu |
Najwięcej decyzji rozstrzyga się w ćwiartce „pułapki”. To tam siedzą luki, które brzmią efektownie na prezentacji („zintegrujmy wszystko z AI”), a dają znikomy zwrot za ogromne pieniądze. Umiejętność powiedzenia „tej luki świadomie nie zamykamy w tej fazie” jest równie ważna, jak umiejętność jej znalezienia. Analityk, który tylko dokłada do listy, a nigdy z niej nie skreśla, nie pomaga - generuje koszty.
Przykłady źle → dobrze: jak opisać lukę
Sposób, w jaki zapiszesz lukę, decyduje o tym, czy da się ją zaadresować. Porównaj:
| Źle (mglista luka) | Dobrze (luka działania) |
|---|---|
| „Słaba komunikacja w procesie” | „Brak automatycznego powiadomienia pacjenta o zmianie terminu - dziś dzwoni rejestratorka, w 30% przypadków nie dodzwania się” |
| „Przestarzała technologia” | „Grafik prowadzony w Excelu offline - brak współbieżnego dostępu dla 3 rejestratorek, ryzyko podwójnej rezerwacji” |
| „Brak raportowania” | „Brak rejestrowania no-show - nie wiemy, ilu pacjentów nie przyszło, więc nie umiemy tego ograniczać” |
Mglista luka nie ma właściciela ani działania - nikt nie wie, co z nią zrobić, więc nikt nic nie robi. Luka opisana konkretnie (z liczbą i skutkiem) niemal sama podpowiada rozwiązanie i da się przypisać do osoby. Zasada: jeśli z opisu luki nie wynika, kto i co ma zrobić, opis jest za słaby.
Mini-case MediFlow: od „transformacji” do roadmapy
Wróćmy do tych 14 wierszy. Po zestawieniu w tabeli luk pogrupowaliśmy je i oceniliśmy wpływ vs wysiłek:
- Szybkie wygrane (mały wysiłek, duży wpływ): przypomnienia SMS, samoobsługowe odwołania. Razem zamykały ~40% telefonów do rejestracji. Poszły do pierwszego wydania.
- Projekty główne (duży wysiłek, duży wpływ): rezerwacja online z grafikiem w czasie rzeczywistym. Sedno transformacji, ale wymaga centralnej bazy terminów. Drugie wydanie.
- Później (duży wysiłek, średni wpływ): panel statystyk no-show. Ważny, ale ma sens dopiero, gdy zbierzemy dane z poprzednich funkcji. Trzecie wydanie.
Dwutygodniowa analiza luk zamieniła nieuchwytną „cyfrową transformację” w trzy wydania z jasnym uzasadnieniem kolejności. Zarząd zatwierdził budżet w jednym spotkaniu - bo zamiast hasła zobaczył listę różnic, z których każda miała cenę i wartość. To jest cała wartość tej techniki: odbiera projektom mgłę.
Częste błędy - czego unikać
- As-Is z procedury, nie z rzeczywistości. Opisujesz, jak proces „powinien” działać według dokumentu, a nie jak działa naprawdę. Cała analiza jest wtedy zbudowana na fikcji.
- Niemierzalny To-Be. „System ma być nowoczesny” nie jest stanem docelowym. Bez liczby nie wiesz, czy luka jest zamknięta.
- Luki bez priorytetów. Lista 30 luk bez kolejności to nie plan, tylko lista życzeń. Bez priorytetyzacji zespół zacznie od najłatwiejszej, nie najwartościowszej.
- Mylenie luki z rozwiązaniem. „Luka: brak Salesforce” - to nie luka, to rozwiązanie wpisane za wcześnie. Luka to „brak centralnej bazy klientów”. Rozwiązań szukaj po zidentyfikowaniu luk.
- Pomijanie luk miękkich. Nie wszystkie luki są technologiczne. Brak kompetencji w zespole, brak procesu, brak właściciela danych - to też luki, często ważniejsze niż brakujący system.
- Analiza, która kończy się prezentacją. Gap analysis bez planu działania i przypisanej odpowiedzialności to dokument do szuflady. Każda luka musi mieć działanie i właściciela.
Rodzaje luk - nie wszystkie są jednakowe
„Luka” to słowo-worek. W praktyce spotkasz kilka różnych typów, a każdy domyka się inaczej. Świadomość tego chroni przed sytuacją, w której wszystkie luki próbujesz zasypać tym samym narzędziem (zwykle: nowym systemem):
- Luka technologiczna - brakuje funkcji lub narzędzia. Domyka się rozwojem albo zakupem systemu. Najbardziej widoczna, ale nie zawsze najważniejsza.
- Luka procesowa - proces jest źle ułożony, niezależnie od technologii. Domyka się przeprojektowaniem przepływu (As-Is → To-Be).
- Luka kompetencyjna - zespół nie umie czegoś, czego wymaga stan docelowy. Domyka się szkoleniem lub rekrutacją, nie wdrożeniem oprogramowania.
- Luka danych - nie zbieramy informacji potrzebnych do decyzji (jak no-show w MediFlow). Domyka się dodaniem rejestrowania i raportowania.
- Luka organizacyjna - brak właściciela procesu, niejasne odpowiedzialności. Domyka się decyzją zarządczą, najtaniej ze wszystkich, a często najtrudniej.
Najczęstszy błąd zarządów: każdą lukę widzą jako technologiczną i chcą ją „kupić”. Tymczasem luka kompetencyjna kupiona systemem zamienia się w drogie narzędzie, którego nikt nie umie używać. Klasyfikacja typu luki to często ważniejsza decyzja niż sama jej identyfikacja.
Gap analysis a inne techniki - jak się łączą
Gap analysis rzadko działa sama. Stan As-Is i To-Be najlepiej opisać mapą procesu (BPMN), a kontekst strategiczny zbudować analizą SWOT (mocne strony to fundament To-Be, słabe strony często wskazują luki). Same luki przy wdrażaniu gotowego systemu przyjmują formę fit-gap analysis - gdzie dla każdego wymagania oceniasz: standard (system to ma), konfiguracja (da się ustawić), customizacja (trzeba dorobić), luka (nie da się). To jedno z najczęstszych zastosowań tej techniki w realnych projektach.
Fit-gap analysis - gdy kupujesz gotowy system
Najczęstsza odmiana gap analysis w realnych projektach to fit-gap analysis - gdy organizacja kupuje gotowe oprogramowanie (ERP, CRM, system rezerwacji) i musi ocenić, na ile pokrywa ono jej potrzeby. Dla każdego wymagania przypisujesz jedną z czterech kategorii:
| Kategoria | Co znaczy | Koszt / ryzyko |
|---|---|---|
| Fit (standard) | System ma to od ręki | Zero - najlepszy przypadek |
| Konfiguracja | Da się ustawić bez programowania | Niski - czas wdrożeniowca |
| Customizacja | Trzeba dorobić / rozszerzyć | Wysoki - kod, utrzymanie, ryzyko przy aktualizacjach |
| Gap (luka) | System tego nie obsłuży | Krytyczny - workaround procesowy albo rezygnacja z wymagania |
Gdyby MediFlow kupował gotowy system rezerwacji zamiast budować własny, fit-gap pokazałby na przykład: rezerwacja online - fit, przypomnienia SMS - konfiguracja, integracja z lokalnym systemem rozliczeń NFZ - customizacja, a specyficzna reguła „blokada terminu 15 minut” - być może gap. Liczba i waga luk z kolumny „customizacja” i „gap” to często decydujący argument: budować samemu czy kupować gotowca. Im więcej customizacji i luk, tym bardziej gotowy system traci sens, bo płacisz za pudełko, które i tak musisz przerobić.
Luka zgodności (compliance) - ta jedna nie podlega priorytetyzacji
Wszystkie luki opisane wyżej są kompromisem: ważysz wpływ, wysiłek i decydujesz, co robisz najpierw. Luka zgodności łamie tę regułę i dlatego wymaga osobnego traktowania. Albo spełniasz wymóg, albo go nie spełniasz - nie ma stanu pośredniego, a termin nie pochodzi od sponsora, tylko z zewnątrz. Macierz wpływ vs wysiłek przestaje tu być narzędziem decyzji, bo decyzja już zapadła poza projektem.
Zmienia się też źródło stanu docelowego. Przy zwykłej analizie luk To-Be wypracowujesz z biznesem na warsztacie. W analizie zgodności To-Be jest zapisane w dokumencie: w przepisie, w standardzie branżowym, w umowie z klientem albo w raporcie z audytu. Twoja robota nie polega na wymyślaniu stanu docelowego, tylko na przetłumaczeniu go na zdanie, które da się sprawdzić.
I to tłumaczenie jest całą trudnością. Zdecydowana większość rejestrów zgodności, które widziałem, ma wiersze w rodzaju „system musi być zgodny z RODO”. To nie jest wymaganie, tylko cytat - nie da się go przetestować ani odhaczyć. Wersja, z którą można pracować, brzmi inaczej:
- Źle: „Przetwarzanie danych pacjenta zgodne z przepisami o ochronie danych.”
- Dobrze: „Dane kontaktowe pacjenta, który nie odbył wizyty przez 24 miesiące, są usuwane automatycznie, a fakt usunięcia zapisuje się w logu.”
Druga różnica wobec zwykłej tabeli luk: przy zgodności stan obecny musi mieć dowód. Nie „wydaje się, że nie usuwamy”, tylko wynik zapytania do bazy, zrzut konfiguracji albo procedura z datą. Powód jest prozaiczny - o ten wiersz zapyta ktoś z zewnątrz, kto nie zna waszego kontekstu i nie przyjmie „sprawdzaliśmy” jako odpowiedzi. Dlatego rejestr luk zgodności ma jedną kolumnę więcej niż zwykły: wymóg, źródło (konkretny dokument i sekcja), stan obecny, dowód, luka, działanie, termin, właściciel.
W MediFlow ta luka wyszła przy okazji, choć nikt jej nie szukał. Rejestracja trzymała dane kontaktowe bezterminowo, bo nikt nigdy nie podjął decyzji, jak długo mają być trzymane. Odruch zespołu był techniczny: „dopiszemy kasowanie”. Tyle że luka nie leżała w braku przycisku, tylko w braku decyzji - nikt nie odpowiadał za to, ile czasu dane mają żyć. Dopisanie funkcji bez tej decyzji dałoby system, który kasuje według liczby wymyślonej przez programistę.
Najczęstsza pułapka w tej robocie to potraktowanie ustalenia z audytu jako wymagania. Ustalenie audytora to objaw i jedna z możliwych interpretacji, a nie źródło. Jeśli przepiszesz je wprost do rejestru, zamkniesz lukę tak, jak widział ją audytor w dniu wizyty, i otworzysz ją ponownie przy następnym audycie z innym audytorem. Wymóg zawsze bierz z dokumentu źródłowego, a ustalenie audytu traktuj jako sygnał, że warto tam zajrzeć.
Na koniec rzecz, która chroni projekt przed nadużyciem w drugą stronę. Luka zgodności idzie w planie pierwsza, ale dalej ją wyceniasz i opisujesz. Słowo „compliance” bywa używane jako wytrych do przepchnięcia prac, które z regulacją nie mają wiele wspólnego - a rozpoznasz to po jednym pytaniu: który zapis konkretnie tego wymaga? Jeśli nie ma odpowiedzi ze wskazaniem dokumentu i sekcji, to nie jest luka zgodności, tylko zwykła luka, która wróciła do kolejki przebrana za pilną.
FAQ
Ile czasu zajmuje gap analysis?
Od kilku dni do kilku tygodni, zależnie od skali. Mała analiza jednego procesu - 2-3 dni. Transformacja całego obszaru - 2-4 tygodnie. Najwięcej czasu pochłania rzetelny opis stanu As-Is (wywiady, obserwacja, dane). To czas dobrze wydany - błąd na tym etapie psuje całą resztę.
Czym różni się gap analysis od analizy As-Is/To-Be?
As-Is/To-Be to opis dwóch stanów. Gap analysis to ta para PLUS systematyczne wskazanie różnic między nimi PLUS plan ich zamknięcia. Można powiedzieć, że As-Is/To-Be dostarcza materiału, a gap analysis robi z niego wnioski i działania.
Kto powinien robić analizę luk?
Prowadzi ją analityk, ale nie sam. Stan As-Is znają ludzie wykonujący proces, stan To-Be definiuje biznes i sponsor, priorytety ustalacie wspólnie. Analityk jest tu dyrygentem, nie solistą - jego rola to struktura, mierzalność i pilnowanie, żeby luki nie zamieniły się w przedwczesne rozwiązania.
Jak priorytetyzować zidentyfikowane luki?
Najprostsza metoda to macierz wpływ vs wysiłek: szybkie wygrane (duży wpływ, mały wysiłek) idą pierwsze. Przy większej liczbie luk sięgnij po MoSCoW albo WSJF, które uwzględniają też pilność i koszt opóźnienia. Najważniejsze, żeby kolejność wynikała z wartości, a nie z tego, co najłatwiej zrobić.
Podsumowanie i następny krok
Gap analysis to technika, która odbiera projektom mgłę. Cztery kroki - opisz As-Is rzetelnie, zdefiniuj To-Be mierzalnie, wypisz luki w tabeli, zaplanuj i spriorytetyzuj zamknięcie - zamieniają hasło „transformacja” w listę, którą da się wycenić i odhaczać. Klucz to uczciwy opis rzeczywistości i mierzalny cel; reszta jest mechaniczna.
Żeby porządnie opisać oba stany, przyda Ci się modelowanie procesów: zacznij od analizy procesów As-Is / To-Be i BPMN dla początkujących, a kontekst strategiczny zbuduj analizą SWOT i PESTLE. A jeśli chcesz sprawdzić, czy odróżniasz lukę od rozwiązania - zrób darmowy test wiedzy BA i zobacz, gdzie masz własne luki kompetencyjne do zamknięcia.