Zacznij od ostatniej trudnej sprawy, nie od listy funkcji.
Wybierz zamówienie, raport lub zgłoszenie, przy którym coś poszło nie tak. Odtwórz kolejne kroki: gdzie pojawiła się informacja, kto ją zmienił i kiedy ktoś zauważył problem. Zapisz również, co zespół musiał zrobić, aby naprawić sytuację.
Jeżeli przyczyną był brak uzgodnionej odpowiedzialności, nowy program sam jej nie ustanowi. Jeżeli dwie osoby edytowały różne wersje pliku, a nikt nie potrafi wskazać poprawnej, narzędzie może rzeczywiście ograniczać proces. Takie rozróżnienie chroni przed cyfrowym odtworzeniem tego samego chaosu.
- Co dokładnie się wydarzyło?
- Jak często podobna sytuacja wraca?
- Jaka informacja lub reguła mogłaby jej zapobiec?
Sygnał pierwszy: odpowiedź zależy od tego, kogo zapytasz.
Handlowiec podaje inny termin niż planista. Magazyn ma inny stan niż arkusz obsługi klienta. Kierownik czeka na osobę, która jako jedyna wie, gdzie jest aktualny plik. Problemem nie jest wtedy wygląd tabeli, lecz brak wspólnego źródła informacji.
Sprawdź, czy można wyznaczyć jeden system odpowiedzialny za każdą ważną daną. Czasem wystarczy uporządkowanie obecnych narzędzi. Dedykowany moduł staje się uzasadniony, gdy informacja musi przejść przez kilka ról, a dostępne rozwiązania nie potrafią obsłużyć wymaganych zmian i potwierdzeń.
- Wskaż właściciela statusu, terminu i danych klienta.
- Ustal, kto może zmieniać te informacje i gdzie powinien to robić.
Najważniejsze na początek
Wybierz rzeczywisty problem i odtwórz jego przebieg, zanim powstanie lista funkcji.
Porównaj konfigurację obecnych narzędzi, gotowy produkt i dedykowany moduł na tym samym procesie.
Pierwszy etap powinien kończyć konkretną sprawę, a nie tylko prezentować ekrany.
Sygnał drugi: reguły działają tylko dzięki pamięci pracowników.
Przed wysyłką trzeba sprawdzić partię, po zmianie ilości ponownie zatwierdzić ofertę, a przy określonym zleceniu dodać dodatkowy dokument. Jeśli zasady istnieją wyłącznie w głowach kilku osób, kolejne zastępstwo lub nowy pracownik ujawnia ryzyko.
Spisz warunki w formie „jeżeli wydarzy się X, potrzebujemy Y”. Przy każdej regule dodaj wyjątek. Dopiero taki opis pozwala ocenić, czy wystarczy konfiguracja gotowego produktu, prosta automatyzacja czy system z własnym przebiegiem pracy. Nie każdy wyjątek wymaga od razu osobnej funkcji; część może trafić do obsługi przez uprawnioną osobę.
Porównaj trzy drogi, używając tego samego scenariusza.
Nie porównuj gotowego programu z listą marzeń o własnej aplikacji. Przygotuj jeden reprezentatywny proces i sprawdź go w każdej opcji: obecnych narzędziach po uporządkowaniu, dostępnym produkcie oraz rozwiązaniu dedykowanym. Zwróć uwagę na ręczne obejścia, eksport danych, integracje i potrzebę szkolenia zespołu.
Własny system daje możliwość dopasowania, ale wymaga decyzji projektowych, utrzymania i dalszego rozwoju. Gotowy produkt może uruchomić pracę szybciej, jednak jego reguły, koszty dostępu i ograniczenia trzeba poznać przed wyborem. Rozwiązanie mieszane często pozwala zachować to, co już działa, i uzupełnić tylko brakujący obieg.
- Czy proces da się wykonać od początku do końca?
- Co nadal trzeba robić poza narzędziem?
- Jak odzyskamy dane i kto będzie utrzymywać rozwiązanie?
Policz koszt obecnej pracy oraz koszt przyszłej zmiany.
Zbierz przykłady z reprezentatywnego okresu. Oddziel czas aktywnej pracy od czasu oczekiwania na decyzję. Kilkanaście minut przepisywania i kilka dni oczekiwania to różne problemy, nawet jeżeli oba opóźniają klienta. Zanotuj również poprawki, duplikaty i sytuacje wymagające udziału kilku osób.
Po stronie nowego rozwiązania uwzględnij analizę, wykonanie, integracje, migrację, wdrożenie użytkowników i utrzymanie. Część korzyści może dotyczyć lepszej kontroli, nie bezpośredniej oszczędności etatu. Warto ją nazwać, zamiast przypisywać każdej funkcji pozornie precyzyjny zwrot z inwestycji.
Pierwsza wersja powinna zamykać jeden obieg.
Dla procesu ofertowego może to być przyjęcie zapytania, przygotowanie wersji oferty, decyzja oraz przekazanie zaakceptowanej sprawy do realizacji. Taką całość można ocenić w praktyce. Same ekrany klientów, dokumentów i ustawień, bez połączenia między nimi, nie dowodzą jeszcze użyteczności systemu.
Określ, co pozostaje poza pierwszym etapem. Zaawansowana analityka może poczekać, ale brak obsługi odrzuconej oferty prawdopodobnie zatrzyma codzienną pracę. Wybieraj zakres według kompletności procesu, a nie atrakcyjności funkcji podczas prezentacji.
- Początek: co uruchamia sprawę?
- Środek: kto wykonuje działanie i podejmuje decyzję?
- Koniec: jaki wynik oznacza zakończenie?
Przed decyzją uzgodnij, kto będzie właścicielem systemu.
Potrzebna jest osoba, która potrafi rozstrzygać pytania o proces i priorytety. Bez niej każda nowa sugestia może zmieniać kierunek projektu. Włącz do rozmowy również przyszłych użytkowników: ich codzienne wyjątki często nie mieszczą się w opisie przygotowanym przez kierownictwo.
Ustal sposób odbioru: kilka konkretnych scenariuszy z oczekiwanym wynikiem, osobami testującymi i przykładowymi danymi. Omów aktualizacje, kopie zapasowe, dostęp do dokumentacji oraz zasady dalszego rozwoju. Decyzja o budowie oprogramowania obejmuje cały okres jego używania, a nie wyłącznie dzień wdrożenia.
Zabierz to do swojej firmy
- Wyznacz właściciela procesu i sposób oceny poprawnego działania.
