AS-IS pokazuje, jak praca przebiega obecnie — także z obejściami, kolejkami i wyjątkami. TO-BE opisuje uzgodniony sposób działania po zmianie. Nie są to dwa obrazki „przed i po”. Pomiędzy nimi musi istnieć ślad: problem, decyzja projektowa, wymaganie, właściciel i miara potwierdzająca efekt.
AS-IS: obserwuj pracę, nie tylko procedurę
Zacznij od granicy i celu procesu. Łącz wywiady z obserwacją spraw, logami, raportami oraz próbką dokumentów. Procedura mówi, jak powinno być; log i użytkownik pokazują, co się dzieje. Oznacz osobno fakty, szacunki i hipotezy. Zbieraj wolumen, czas pracy, czas oczekiwania, odsetek powrotów, błędy i ręczne obejścia. Bez danych TO-BE łatwo staje się estetycznym życzeniem.
TO-BE: projektuj od celu i ograniczeń
Nie zaczynaj od usuwania prostokątów z AS-IS. Najpierw ustal docelowy rezultat, miary, zasady, ograniczenia prawne i zdolności organizacji. Potem zdecyduj, co eliminujemy, upraszczamy, standaryzujemy, automatyzujemy lub pozostawiamy ręcznie. Każda zmiana musi mieć założenie, np. „95% wniosków ma dane pozwalające na automatyczną kontrolę”. Założenie wymaga testu.
Przypadek: zakładanie konta dostawcy
AS-IS ujawnił przesyłanie arkusza pocztą, ręczne przepisywanie danych i trzy sekwencyjne akceptacje. Mediana trwała 6 dni, choć sama praca zajmowała 42 minuty. W 28% spraw brakowało rachunku albo danych podatkowych. Nieformalna kontrola duplikatu odbywała się dopiero przed księgowaniem.
W TO-BE portal sprawdza kompletność przy wprowadzaniu, automatycznie wyszukuje duplikat, a kontrole podatkowa i zakupowa biegną równolegle. Sprawy wysokiego ryzyka trafiają do dodatkowej weryfikacji. Projekt nie „automatyzuje całego procesu”: decyzja o wyjątku pozostaje u człowieka, a migracja wymaga uporządkowania słownika dostawców.
| Luka AS-IS | Decyzja TO-BE | Założenie/ryzyko | Miara |
|---|---|---|---|
| 28% niekompletnych formularzy | Walidacja przy wprowadzaniu | Reguły kompletności są stabilne | Braki poniżej 5% |
| Kontrole po kolei | AND: podatki i zakupy równolegle | Zespoły mogą pracować niezależnie | Mediana do 2 dni |
| Duplikat wykrywany późno | Kontrola przed utworzeniem | Dane referencyjne są wystarczające | Duplikaty poniżej 1% |
| Wyjątki w e-mailach | Kolejka z kodem przyczyny | Uzgodniona taksonomia | 100% wyjątków ze statusem |
Rejestr dowodów dla AS-IS
Do każdego istotnego kroku dołącz źródło i poziom pewności. Obserwacja pięciu spraw może potwierdzić przebieg, ale nie roczny wolumen. Deklaracja kierownika może opisać regułę, lecz wykonawcy ujawnią obejście. Rejestr dowodów zawiera identyfikator kroku, źródło, okres, próbkę, wynik i osobę potwierdzającą. Sprzeczności pozostają widoczne aż do decyzji — nie uśredniaj dwóch wersji procesu.
| Twierdzenie | Dowód | Status | Dalsze działanie |
|---|---|---|---|
| Każda sprawa wymaga akceptacji zakupów | Procedura P-12 | Sprzeczne | Porównać z logiem i wyjątkami |
| Mediana oczekiwania 4 dni | Log 1 240 spraw / kwartał | Potwierdzone | Użyć jako baseline |
| Duplikaty wynikają z literówek | Opinia dwóch osób | Hipoteza | Zakodować próbkę duplikatów |
Warianty TO-BE i decyzja projektowa
Warto przygotować co najmniej wariant minimalny, docelowy i awaryjny. Minimalny usuwa największe źródło straty bez kosztownej integracji. Docelowy wykorzystuje pełne dane i automatyzację. Awaryjny opisuje pracę po niedostępności systemu lub integracji. Porównuj warianty według tych samych kryteriów: czasu, kosztu, ryzyka, jakości, pracy operacyjnej i odwracalności. Wybrany model powinien zawierać uzasadnienie odrzuconych opcji.
Dla dostawców wariant minimalny mógł wprowadzić jeden formularz i kontrolę kompletności, zanim powstanie automatyczna integracja podatkowa. Pozwala to szybko sprawdzić, czy brak danych rzeczywiście odpowiada za opóźnienia. Taki etap ogranicza ryzyko zautomatyzowania błędnej diagnozy.
Plan przejścia jest trzecim artefaktem
Poza modelami potrzebny jest transition state: zmiany ról, danych, instrukcji, uprawnień, integracji i mierników. Ustal kolejność wdrożenia oraz procedurę powrotu. Przykładowo walidację formularza można uruchomić przed równoległymi kontrolami, ale dopiero po ustaleniu źródła danych podatkowych.
Warsztat projektowy bez przeskakiwania do rozwiązania
Na pierwszej części warsztatu pokazuj wyłącznie AS-IS, dowody i problemy. Uczestnicy zaznaczają miejsca oczekiwania, ponownej pracy, ryzyka oraz utraty informacji. Dopiero po uzgodnieniu diagnozy otwórz rozmowę o wariantach TO-BE. Ta kolejność ogranicza zakotwiczenie na pierwszej propozycji technologicznej i pozwala oddzielić przyczynę od objawu.
Dla każdej propozycji stosuj kartę eksperymentu: jaka obserwacja ją uzasadnia, jaki mechanizm ma poprawić wynik, jaka metryka to pokaże i co zrobimy, jeśli założenie okaże się fałszywe. Przykład: „Walidacja przy wprowadzaniu zmniejszy braki z 28% do 5% w pilotażu 200 spraw; jeśli nie, przeanalizujemy czy problemem jest dostępność danych, a nie formularz”.
Właściciele i rytm aktualizacji
Właściciel procesu zatwierdza zachowanie i miary, właściciele kroków potwierdzają operacje, a analityk utrzymuje spójność modeli oraz rejestru luki. Po większej zmianie lub ustalonym okresie porównaj model z logami i praktyką. AS-IS przestaje być prawdziwy, a TO-BE po wdrożeniu staje się nowym stanem obecnym — dokumenty muszą odzwierciedlać tę zmianę.
Walidacja po wdrożeniu
Po uruchomieniu porównuj metryki w ustalonym oknie i według porównywalnych segmentów. Spadek mediany może ukrywać pogorszenie najtrudniejszych 10% spraw, dlatego obserwuj także percentyle, powroty i wyjątki. Jeżeli założenie nie zostało potwierdzone, właściciel procesu podejmuje decyzję o korekcie, a model TO-BE aktualizuje się do rzeczywistego sposobu pracy.
Checklista analizy luki
- AS-IS został potwierdzony danymi i osobami wykonującymi proces.
- TO-BE realizuje nazwany cel, a nie tylko wdraża wskazane narzędzie.
- Każda różnica ma decyzję, właściciela, wymaganie i miarę.
- Wyjątki, role ręczne i ograniczenia nie zniknęły z modelu.
- Istnieje plan przejścia, pilotażu i pomiaru po wdrożeniu.
Do oceny potencjału użyj także materiału analiza procesu do automatyzacji. Błędy semantyczne modeli pomoże wychwycić checklista błędów BPMN.
