System A ma dłuższą listę funkcji, system B pokazuje krótszy formularz, a system C obiecuje integrację potrzebną firmie. Z tych informacji nie wynika jeszcze wybór. Najpierw trzeba ustalić, które potrzeby są konieczne i jak dostawca potwierdzi ich obsługę.
Oddziel warunki konieczne od wygody
Przygotuj krótką kartę wymagań. Warunek konieczny to taki, bez którego firma nie może przeprowadzić uzgodnionego procesu, np. przekazać określonych danych do rozliczeń. Wygoda może dotyczyć sposobu wyszukiwania lub układu widoku. Nie równoważ tych pozycji samym sumowaniem punktów.
Dla każdej potrzeby zapisz oczekiwany rezultat, sposób sprawdzenia i osobę odbierającą. „Obsługa dokumentów” jest tematem. „Znalezienie dokumentu wskazanego zlecenia po jego numerze i udostępnienie go właściwej roli” nadaje się do próby.
Przed prezentacją usuń wymagania oparte tylko na przyzwyczajeniu do starego menu. Zachowaj te, które opisują wynik pracy, potrzebne dane lub odpowiedzialność.
Nie porównuj trzech różnych prezentacji
Przekaż dostawcom ten sam przykładowy zestaw danych i scenariusz. Użyj danych przygotowanych do prezentacji, bez zbędnych informacji o rzeczywistych kontrahentach. Próbę powinny oglądać osoby wykonujące później te czynności.
Załóżmy fikcyjne zlecenie z dwiema dopłatami i dokumentem dodanym po wykonaniu transportu. Poproś o pokazanie, gdzie zapisano aktualne ustalenia, kto może je zmienić i jak trafiają do rozliczenia. To propozycja próby, nie opis możliwości konkretnego programu.
Zmierz liczbę czynności, ręcznie przepisywanych danych i czas pracy przy podobnym przygotowaniu użytkownika. Zapisz, kiedy potrzebna była pomoc prezentera. Jedna szybka demonstracja prowadzona przez eksperta nie jest tym samym co samodzielna obsługa po szkoleniu.
Deklaracja funkcji potrzebuje statusu i dowodu
| Odpowiedź dostawcy | Co zapisać w porównaniu |
|---|---|
| Działa obecnie | Pokazany wynik i zakres dostępny w wycenionej wersji |
| Wymaga konfiguracji | Zakres, odpowiedzialność, koszt i warunek odbioru |
| Wymaga dodatkowej pracy | Uzgodnione zamówienie, termin i sposób sprawdzenia |
| Jest w planach | Osobna pozycja; bez uznawania za gotową funkcję |
To własna metoda zapisu. Pomaga odróżnić brak funkcji od funkcji nieuruchomionej, ale również obietnicę od wykonanego rezultatu. Jeśli warunek jest konieczny, nie zastępuj potwierdzenia ogólnym opisem rozwoju produktu.
Integracja: dane, kierunek i sytuacja po błędzie
Logo innego systemu nie opisuje zakresu wymiany. Zapytaj, które rekordy i pola przechodzą, w jakim kierunku oraz co uruchamia przesłanie. Ustal obsługę zmiany i ponowienia po przerwaniu wymiany.
Potrzebny jest też właściciel problemu: kto sprawdza zgodność wersji i kto reaguje, gdy dane nie docierają? Sprawdź koszt uruchomienia, późniejszego utrzymania i ewentualnych limitów. Tych warunków nie da się wywnioskować z samej obecności API.
Policz koszt dla tego samego zakresu i okresu
Zestaw koszty startu oraz pracy w wybranym okresie: dostęp, wdrożenie, konfigurację, szkolenie, integracje, utrzymanie i wsparcie. Przyjmij tę samą liczbę ról lub użytkowników, potrzebny zakres i sposób rozliczenia kwot.
Dopisz warunki zmiany ceny, dodawania dostępu oraz zakończenia współpracy. Sprawdź użyteczność eksportu wraz z dokumentami i relacjami, a nie tylko możliwość pobrania dowolnego pliku. Pytania o przygotowanie danych rozwija artykuł o migracji do TMS.
Decyzja powinna wskazywać także braki
Porównanie zakończ listą spełnionych warunków, niewyjaśnionych pozycji i kosztów wynikających z przyjętych założeń. Nie pozwól, aby atrakcyjny element prezentacji przesłonił niespełniony wymóg konieczny.
Po wyborze programu pozostaje organizacja uruchomienia. Opisuje ją poradnik o przygotowaniu wdrożenia. Porównanie dostawców ma dać udokumentowaną podstawę decyzji; pilotaż sprawdzi później uzgodniony proces w firmie.
