Pewna sieć przychodni postanowiła wdrożyć rejestrację online. Cel brzmiał rozsądnie: „przenieśmy zapisy z telefonu do internetu". Po pół roku i sporym budżecie system ruszył - i okazał się katastrofą. Pacjenci rezerwowali terminy, których recepcja i tak nie widziała, bo nowy system nie rozmawiał ze starym grafikiem lekarzy. Recepcjonistki musiały ręcznie przepisywać każdą wizytę. Zamiast usprawnienia dostali drugą, równoległą bazę chaosu. Dlaczego? Bo nikt nie zmapował, jak naprawdę działają zapisy dzisiaj - przeskoczono prosto do „nowego, lepszego", nie rozumiejąc starego.
To klasyczny błąd: cyfryzacja bałaganu. Jeśli zautomatyzujesz zły proces, dostaniesz szybszy zły proces. Metoda As-Is / To-Be istnieje właśnie po to, żeby tego uniknąć. As-Is to rzetelna diagnoza stanu obecnego. To-Be to zaprojektowany stan docelowy. Między nimi leży najważniejsza praca analityka: zrozumienie, dlaczego proces wygląda tak, jak wygląda, i co konkretnie chcemy poprawić. W tym artykule przeprowadzę Cię przez obie strony tego mostu na przykładzie sieci 12 przychodni MediFlow.
Pominięcie analizy As-Is to najdroższy skrót w analizie biznesowej. Oszczędzasz tydzień na mapowaniu, żeby stracić pół roku na wdrożeniu rozwiązania, które nie pasuje do rzeczywistości.
Czym jest As-Is i To-Be
As-Is (stan obecny) to szczegółowy, prawdziwy opis tego, jak proces działa dziś - ze wszystkimi krokami, uczestnikami, narzędziami, decyzjami i, co najważniejsze, problemami. Najważniejsze słowo to „prawdziwy". As-Is opisuje proces taki, jaki jest naprawdę, a nie taki, jaki widnieje w oficjalnej procedurze albo jaki wyobraża sobie zarząd.
To-Be (stan docelowy) to projekt procesu po usprawnieniu - zoptymalizowanego, zgodnego z celami organizacji i, co najważniejsze, realnego do wdrożenia. To-Be nie jest życzeniem ani wizją z prezentacji. To plan, który da się zrealizować.
Most między nimi to analiza luki (gap analysis) - odpowiedź na pytanie „co konkretnie musimy zmienić, żeby z As-Is dojść do To-Be". Bez tego mostu masz dwa oderwane obrazki zamiast planu transformacji.
As-Is - diagnoza, nie fikcja
Najtrudniejsze w mapowaniu stanu obecnego jest oparcie się pokusie, by od razu naprawiać. Na etapie As-Is Twoim zadaniem jest zrozumieć i opisać, a nie ulepszać. Każde „a tu powinniśmy zrobić to lepiej" odłóż na bok - przyjdzie czas To-Be.
Jak zmapować As-Is - krok po kroku
- Określ zakres i granice. Gdzie proces się zaczyna, gdzie kończy, kogo obejmuje. Dla MediFlow: od momentu, gdy pacjent chce się zapisać, do potwierdzonej wizyty w grafiku lekarza.
- Zbierz dane z wielu źródeł. Nie ograniczaj się do dokumentacji - ona kłamie. Rozmawiaj z ludźmi, którzy wykonują proces: recepcjonistkami, lekarzami, pacjentami. Obserwuj ich przy pracy. Sięgnij po dane z systemów (ile zapisów, ile odwołań, ile pomyłek).
- Zmapuj proces wizualnie. Najlepiej notacją BPMN - z torami pokazującymi, kto wykonuje który krok. Diagram As-Is często szokuje samych uczestników, gdy widzą, ile razy proces przeskakuje między działami.
- Zidentyfikuj problemy. Wąskie gardła, zbędne kroki, miejsca błędów, ręczne przepisywanie danych. Tu pomagają techniki przyczynowe: 5 Why i diagram Ishikawy (rybiej ości).
- Zweryfikuj z uczestnikami. Twój diagram to hipoteza. Pokaż go ludziom, którzy ten proces robią, i zapytaj: „czy tak to wygląda naprawdę?". Prawie zawsze coś poprawią.
Mini-case: As-Is zapisów w MediFlow
Mapując zapisy w jednej z przychodni MediFlow, odkrywamy proces, którego nikt wcześniej nie widział w całości:
- Pacjent dzwoni (jedyny kanał) - średnio 4 minuty oczekiwania, w szczycie 15
- Recepcjonistka sprawdza grafik w papierowym kalendarzu i równolegle w starym systemie - dwie wersje, które bywają niezgodne
- Zapisuje wizytę ręcznie w obu miejscach
- Jeśli lekarz zmieni grafik, zmiana trafia tylko do papieru - system zostaje nieaktualny
- Przy odwołaniu wizyty zwolniony termin często nie wraca do puli, bo recepcja zapomina go odznaczyć
Diagnoza As-Is obnaża prawdziwe problemy: brak jednego źródła prawdy (papier vs system), jeden wąski kanał (telefon), ręczne, podwójne wprowadzanie danych i tracone terminy. To są problemy, które To-Be ma rozwiązać. I to dopiero teraz, gdy je widzimy, ma sens rozmowa o rejestracji online.
Jak naprawdę zbierać dane do As-Is
Skoro As-Is ma opisać rzeczywistość, a nie fikcję z segregatora, najważniejsze jest, skąd czerpiesz wiedzę. Żadne pojedyncze źródło nie wystarczy - każde ma swoje przekłamania, a prawda wyłania się dopiero z ich zestawienia.
| Źródło | Co daje | Czego nie wychwyci |
|---|---|---|
| Dokumentacja, procedury | Jak proces ma działać oficjalnie | Jak działa naprawdę (obejścia, skróty) |
| Wywiady z wykonawcami | Codzienna praktyka, frustracje, obejścia | To, co robią automatycznie i nie nazywają |
| Obserwacja przy pracy | Rzeczywiste zachowanie, kroki nieuświadomione | Rzadkie przypadki i wyjątki |
| Dane z systemów | Twarde liczby: ile, jak często, jak długo | Dlaczego tak się dzieje |
Najcenniejsza jest triangulacja - gdy procedura mówi jedno, recepcjonistka robi drugie, a dane pokazują trzecie, to właśnie te rozbieżności wskazują, gdzie tkwią prawdziwe problemy. W MediFlow procedura mówiła „zwolniony termin wraca do puli automatycznie", recepcja przyznawała „czasem zapominamy odznaczyć", a dane pokazywały 18% wizyt oznaczonych jako zajęte mimo odwołania. Trzy źródła, jedna prawda: proces ma dziurę, której nikt nie chciał głośno przyznać.
Dwie techniki, które drążą do przyczyny
Zmapowanie problemu to za mało - trzeba zrozumieć jego źródło, bo To-Be ma leczyć przyczynę, nie objaw. Dwie sprawdzone techniki:
- 5 Why. Pięciokrotnie pytasz „dlaczego", schodząc od objawu do korzenia. „Tracimy terminy" → bo recepcja zapomina odznaczyć → bo robi to ręcznie w dwóch miejscach → bo system i papier to dwa źródła prawdy → bo nigdy ich nie połączono. Korzeń: brak jednego źródła prawdy. I to on, nie „zapominanie", trafia do To-Be.
- Diagram Ishikawy (rybia ość). Gdy jeden problem ma wiele przyczyn, porządkujesz je w kategoriach (ludzie, proces, narzędzia, dane). Pozwala zobaczyć, że „długi czas zapisu" to nie jedna sprawa, lecz wiązka: kolejka na telefonie + sprawdzanie dwóch grafików + ręczne wpisywanie.
To-Be - projekt, nie życzenie
Mając diagnozę, projektujemy stan docelowy. Dobry To-Be wynika wprost z problemów As-Is - każde usprawnienie odpowiada na konkretną bolączkę, a nie na modę czy efektowną funkcję.
Jak zaprojektować To-Be
- Zdefiniuj mierzalne cele. Nie „lepiej", tylko „skrócić czas zapisu z 4 minut do 1", „wyeliminować podwójne wprowadzanie danych", „zmniejszyć liczbę traconych terminów o 80%". Cele muszą być mierzalne, inaczej nie ocenisz sukcesu.
- Zaprojektuj nowy proces. Znów wizualnie, znów w BPMN. Dla MediFlow: pacjent rezerwuje online z jednego, wspólnego grafiku; system jest jedynym źródłem prawdy; odwołany termin automatycznie wraca do puli; recepcja widzi to samo, co pacjent.
- Oceń ryzyka i wykonalność. Czy mamy budżet, kompetencje, integracje? To-Be, którego nie da się wdrożyć, jest bezwartościowy. Tu kłania się studium wykonalności.
- Zaplanuj przejście. Migracja danych, szkolenia recepcji, okres równoległego działania starego i nowego procesu. To-Be bez planu wdrożenia to ten sam błąd, co rejestracja ze wstępu.
- Przetestuj przed wdrożeniem. Najlepiej na prototypie pokazanym recepcjonistkom i pacjentom, zanim cokolwiek zostanie zbudowane.
As-Is vs To-Be - porównanie wprost
| Wymiar | As-Is (stan obecny) | To-Be (stan docelowy) |
|---|---|---|
| Kanał zapisu | Tylko telefon | Online + telefon + recepcja, wspólny grafik |
| Źródło prawdy | Papier i system (niespójne) | Jeden system dla wszystkich kanałów |
| Wprowadzanie danych | Ręczne, podwójne | Jednokrotne, automatyczne |
| Odwołane terminy | Często tracone | Automatyczny powrót do puli |
| Czas zapisu | ~4 min (15 w szczycie) | ~1 min, bez kolejki |
| Skala | Każda przychodnia osobno | Spójnie w 12 placówkach |
Ta tabela to esencja gap analysis. Każdy wiersz pokazuje, co się zmienia i dlaczego - a luka między kolumnami to lista zadań do wdrożenia. Dopiero z takim materiałem rejestracja online ma sens. Bez niego powstaje druga baza chaosu.
Most między stanami - gap analysis i plan przejścia
Dwa piękne diagramy - As-Is i To-Be - same w sobie niczego nie zmieniają. Wartość rodzi się w tym, co między nimi: w wyliczeniu, co dokładnie trzeba zrobić, by przejść z jednego do drugiego. To jest gap analysis, a jej produktem jest konkretna lista zmian, z których każda ma swój typ.
| Typ luki | Co oznacza | Przykład MediFlow |
|---|---|---|
| Technologiczna | Brakuje systemu lub integracji | Połączenie grafików 12 przychodni w jeden |
| Procesowa | Trzeba zmienić sposób pracy | Rezygnacja z papierowego kalendarza |
| Kompetencyjna | Ludzie muszą się czegoś nauczyć | Szkolenie recepcji z nowego systemu |
| Danych | Trzeba uporządkować lub zmigrować dane | Scalenie kartotek pacjentów z różnych placówek |
Dopiero ta lista - a nie sam obrazek To-Be - jest planem projektu. Każda luka to zadanie do oszacowania i zaplanowania.
Plan przejścia - najczęściej zapominany element
Nawet idealnie zaprojektowany To-Be padnie, jeśli zabraknie przemyślanego przejścia. Tu właśnie wykłada się większość transformacji. Dobry plan przejścia odpowiada na cztery pytania:
- Migracja danych - co robimy z istniejącymi zapisami i kartotekami? Jak zapewniamy ich jakość przed przeniesieniem?
- Okres równoległy - czy stary i nowy proces działają chwilę razem (bezpieczniej, ale drożej), czy przełączamy się z dnia na dzień (taniej, ale ryzykowniej)?
- Szkolenia - kiedy i jak przygotowujemy ludzi? Pamiętaj o historii ze wstępu: w realnych wdrożeniach szkolenie recepcji to kamień milowy, nie dodatek na koniec.
- Komunikacja zmiany - jak informujemy pacjentów i personel, by nowy proces przyjął się, a nie spotkał z cichym bojkotem?
Pominięcie planu przejścia to dokładnie to, co zamieniło dobrą ideę rejestracji online ze wstępu w drugą bazę chaosu. Nowy system był poprawny - ale nikt nie pomyślał, jak ma współistnieć ze starym grafikiem i jak przeszkolić ludzi. To-Be bez planu przejścia to mapa skarbu bez drogi do niego.
Najczęstsze błędy w analizie As-Is / To-Be
- Pominięcie As-Is. Najdroższy błąd. Skok prosto do „nowego systemu" bez zrozumienia obecnego procesu kończy się cyfryzacją bałaganu - jak w historii ze wstępu.
- Mapowanie procesu z dokumentacji, nie z rzeczywistości. Oficjalna procedura opisuje, jak proces powinien działać. As-Is musi opisać, jak działa naprawdę - a różnica bywa ogromna. Idź do ludzi, nie do segregatora.
- To-Be jako lista życzeń. Stan docelowy naszpikowany efektownymi funkcjami bez powiązania z realnymi problemami i bez oceny wykonalności. Każde usprawnienie musi odpowiadać na konkretną bolączkę z As-Is.
- Brak mierzalnych celów. „Ma być lepiej" to nie cel. Bez liczb (skrócić czas o X, zmniejszyć błędy o Y) nie da się ocenić, czy transformacja się udała - zobacz metryki i KPI.
- Zbyt szeroki zakres. Próba zmapowania wszystkich procesów firmy naraz prowadzi do paraliżu. Skup się na procesie o największym wpływie na ból, który chcesz uleczyć.
- Brak zaangażowania ludzi z pierwszej linii. Najlepszą wiedzę o As-Is mają recepcjonistki, nie dyrektorzy. Najlepsze pomysły na To-Be też często od nich pochodzą. Pominięcie ich to gwarancja oporu przy wdrożeniu.
- Brak planu przejścia. Nawet idealny To-Be wymaga przemyślanej migracji, szkoleń i okresu przejściowego. Bez tego nowy proces się nie przyjmie.
Narzędzia i techniki wspierające
- BPMN - standard mapowania obu stanów; tory pokazują przeskoki między działami
- 5 Why - drążenie do prawdziwej przyczyny problemu z As-Is
- Diagram Ishikawy (rybia ość) - porządkowanie wielu przyczyn jednego problemu
- Warsztaty z użytkownikami - szybkie zebranie wiedzy o As-Is i pomysłów na To-Be
- Gap analysis - systematyczne wyliczenie różnic między stanami
- Narzędzia do diagramów - Bizagi, Lucidchart, Miro, draw.io
FAQ - analiza As-Is / To-Be
Czy zawsze trzeba mapować As-Is, czy można od razu projektować To-Be?
Przy realnych projektach transformacji - prawie zawsze trzeba. Wyjątkiem jest budowa czegoś zupełnie nowego, gdzie nie ma stanu obecnego do zdiagnozowania. Ale gdy usprawniasz istniejący proces, pominięcie As-Is to prosta droga do cyfryzacji bałaganu i rozwiązania, które nie pasuje do rzeczywistości.
Jak głęboko mapować As-Is?
Na tyle głęboko, by zidentyfikować realne problemy i ich przyczyny - ale nie głębiej. Mapowanie każdego wyjątku i każdej ścieżki bocznej w drobnym detalu to marnotrawstwo. Skup się na głównym przepływie i miejscach, gdzie boli.
Czym różni się gap analysis od analizy As-Is / To-Be?
To elementy tej samej układanki. As-Is i To-Be to opisy dwóch stanów, a gap analysis to systematyczne wyliczenie różnic między nimi - czyli lista tego, co trzeba zmienić, by przejść z jednego do drugiego. Więcej w artykule o analizie luk.
Kto powinien akceptować To-Be?
Zarówno sponsor biznesowy (czy cele i koszt mają sens), jak i przedstawiciele osób, które będą w nowym procesie pracować (czy jest realny i wygodny). Akceptacja samego zarządu bez głosu pierwszej linii to przepis na opór i ciche bojkotowanie zmiany.
Podsumowanie
As-Is / To-Be to nie technika rysowania diagramów, lecz dyscyplina myślenia: najpierw zrozum prawdę o stanie obecnym, potem zaprojektuj realny stan docelowy, a między nimi policz, co dokładnie trzeba zmienić. Pokusa, by przeskoczyć diagnozę i od razu kupić „nowy, lepszy system", jest wielka - i kończy się drugą bazą chaosu. Tydzień rzetelnego mapowania As-Is to najlepsza inwestycja, jaką możesz zrobić, żeby uchronić projekt przed wdrożeniem rozwiązania, które maskuje problemy zamiast je leczyć.
Analiza procesów łączy się z innymi kompetencjami analityka - sięgnij po BPMN do mapowania procesów, gap analysis do liczenia luki oraz metryki i KPI do mierzenia, czy transformacja się udała. Chcesz przećwiczyć mapowanie As-Is / To-Be na realnych procesach? Zajrzyj do szkoleń Analify.