Zanim zamówisz system dla całej organizacji, chcesz sprawdzić go w jednym dziale. To rozsądny punkt wyjścia, o ile wiadomo, co taka próba ma udowodnić. Inaczej łatwo zbudować fragment, który dobrze wygląda, lecz nie odpowiada na najważniejsze pytania.
Zacznij od zdania: „Po pilotażu zdecydujemy, czy…”. Dopisz konkretną decyzję, np. czy proces da się obsłużyć bez ręcznego przepisywania danych.
Wybierz zakres, który sprawdza ryzyko
Jeżeli największą niewiadomą jest integracja, sama prezentacja interfejsu nie wystarczy. Jeśli problemem jest praca kilku oddziałów, próba z jednym użytkownikiem nie pokaże przepływu odpowiedzialności.
Wybierz możliwie mały, ale pełny scenariusz. Ustal uczestników, dane, wyjątki i czas potrzebny na rzeczywiste wykonanie zadania. Wyjaśnij, które warunki różnią się od docelowego wdrożenia.
Umów się na sposób oceny
Zapisz, co obserwujecie, jak zbieracie wyniki i kto podejmuje decyzję. Mogą to być ukończone sprawy, miejsca wymagające ręcznej pomocy oraz błędy uniemożliwiające pracę. Kryteria powinny wynikać z pytania pilotażu.
Nie zmieniaj ich dopiero po zobaczeniu wyniku, żeby próba wyglądała na sukces. Jeżeli pojawi się nowe ważne pytanie, nazwij je osobno i ustal, czy potrzebny jest kolejny zakres.
Sprawdź, co zostanie po próbie
Czy kod, konfiguracja i dane nadają się do dalszego użycia? Czy część rozwiązania powstała wyłącznie na potrzeby demonstracji? Ile będzie kosztować przejście do pełnej skali i jakie ograniczenia nadal pozostaną?
Wynikiem pilotażu powinny być obserwacje, odpowiedź na główne pytanie i warianty dalszych działań. Także decyzja o zmianie podejścia może być wartościowym rezultatem, jeśli pomaga uniknąć większego zamówienia opartego na błędnym założeniu.
Wszystkie liczby z artykułu i tysiące innych umów znajdziesz w bazie.
Otwórz bazę umów