Prezentacja handlowa pokazuje system w warunkach, które wybrał dostawca. Test na własnych procesach pokazuje go w warunkach magazynu. Pierwszy z nich trwa godzinę. Drugi wymaga przygotowania danych i zapisanych kryteriów zaliczenia, ale tylko on odpowiada na pytanie, czy system poradzi sobie z konkretnym asortymentem.
Ten tekst opisuje dwa poziomy testu: środowisko dostępne w przeglądarce oraz kopię z danymi firmy. Wprowadzenie do samego systemu daje strona o systemie Warehouse Management System, a moduły środowiska pokazowego wymienia osobny tekst o wersji demo Magazyn.
Do czego służy WMS demo on-line, a do czego demo z danymi klienta
Środowisko dostępne przez przeglądarkę nie wymaga instalacji. Wystarczy adres i dane logowania, a test można prowadzić z biura albo z hali. Dostawca zasila taką instancję danymi przykładowymi. Kartoteki i dokumenty wyglądają więc spójnie, ale nie odpowiadają żadnej rzeczywistej firmie. Demo Studio WMS.net udostępnia SoftwareStudio pod adresem demo.softwarestudio.com.pl/demo-magazyn.
Demo z danymi klienta to osobna instancja, do której trafia wycinek własnych kartotek i stanów. Kosztuje więcej czasu po obu stronach, ale odpowiada na pytania niedostępne w wersji ogólnej: czy indeksy z ERP mieszczą się w polach systemu i czy jednostki miary przeliczają się poprawnie.
| Kryterium | Demo ogólne w przeglądarce | Demo z danymi klienta |
|---|---|---|
| Dane | Przykładowe, przygotowane przez dostawcę | Wycinek własnych kartotek i stanów |
| Przygotowanie | Brak, dostęp od razu | Eksport z ERP i import do osobnej bazy po anonimizacji |
| Co można ocenić | Układ ekranów i logikę dokumentów | Zgodność kartotek, przeliczenia jednostek, własne wydruki |
| Czego nie pokaże | Zachowania na własnym asortymencie | Wydajności przy pełnej bazie i pracy wielu terminali naraz |
Demo ogólne jako narzędzie wstępnej selekcji
Na wczesnym etapie test w przeglądarce pozwala odrzucić rozwiązania wyraźnie niedopasowane. Wystarczy przejść jeden dokument od przyjęcia do wydania i sprawdzić, ile kliknięć wymaga każda operacja. System, w którym zwykłe przyjęcie wymaga kilkunastu ekranów, nie stanie się szybszy po wdrożeniu.
Warto też wziąć do ręki terminal. Tekst o programie magazynowym online z dostępem zdalnym opisuje, jak ten sam system działa w oknie przeglądarki i na kolektorze, a różnica w ergonomii bywa większa niż różnica w funkcjach.
Demo z danymi klienta, gdy zostają dwa systemy
Instancję z danymi firmy opłaca się przygotować dopiero dla dwóch lub trzech systemów, które przeszły wstępną selekcję. Przygotowanie angażuje konsultanta dostawcy, a po stronie firmy kogoś, kto zna kartoteki i potrafi wyeksportować je z ERP. Scenariusz takiej oceny opisuje strona o demo WMS dla magazynu wysokiego składowania.
Przygotowanie danych do testu na własnym asortymencie
Jakość demo z danymi klienta zależy od jakości pliku wejściowego. Reprezentatywny wycinek to kilkaset indeksów, które obejmują różne typy towaru: sprzedawane na sztuki i na palety, z terminem ważności, z numerem seryjnym. Osobno trzeba dodać pozycje o dwóch jednostkach miary. Losowe pierwsze tysiąc wierszy z ERP zwykle zawiera same najprostsze pozycje i test niczego nie wykryje.
Kartoteki z ERP przed importem trzeba oczyścić. Duplikaty indeksów i puste jednostki miary wychodzą w teście jako błędy systemu, choć są błędami danych. To samo dotyczy kodu kreskowego przypisanego do dwóch towarów. Strukturę kartotek w Studio WMS.net omawia strona o kartotekach magazynowych, a sposób ładowania danych z arkusza tekst o migracji z Excela do programu magazynowego.
-- przykładowe zapytanie na kopii danych: kody przypisane do kilku indeksów
SELECT KodKreskowy,
COUNT(DISTINCT Indeks) AS liczba_indeksow
FROM dbo.KodTowaru
GROUP BY KodKreskowy
HAVING COUNT(DISTINCT Indeks) > 1;Zapytanie wskazuje kody, które w teście dałyby niejednoznaczny skan. W ten sam sposób sprawdza się indeksy zduplikowane po usunięciu spacji i różnic wielkości liter, bo ERP często je toleruje, a system magazynowy zgłasza konflikt.
Anonimizacja danych kontrahentów
Kopia testowa nie powinna zawierać danych osobowych w postaci jawnej. Nazwy firm i adresy dostaw są potrzebne do wydruków. Dane osób kontaktowych można zastąpić wartościami syntetycznymi jeszcze przed przekazaniem pliku dostawcy. Zakres anonimizacji warto uzgodnić z inspektorem ochrony danych.
-- przykładowy schemat, do uruchomienia na kopii bazy, nie na produkcji
UPDATE dbo.KontaktKontrahenta
SET Nazwisko = CONCAT('Kontakt ', KontaktId),
Telefon = '000000000',
Email = CONCAT('kontakt', KontaktId, '@example.test');Reguła: plik z danymi do demo powstaje z kopii bazy, a nie z produkcji, i przed wysyłką przechodzi anonimizację danych osobowych.
Alternatywą dla przepisywania danych jest maskowanie na poziomie zapytań, które opisuje dokumentacja Microsoft o dynamicznym maskowaniu danych w SQL Server. Maska ukrywa wartość przed użytkownikiem bez uprawnienia UNMASK, ale nie zmienia danych zapisanych w bazie, więc kopia przekazywana poza firmę wymaga trwałej anonimizacji.
Określenie skali testu
Dostawca powinien znać rozmiar bazy źródłowej, bo od niego zależy dobór sprzętu i interpretacja wyniku. Zapytanie poniżej zwraca dziesięć największych tabel wraz z liczbą wierszy i można je uruchomić w każdej bazie SQL Server.
SELECT TOP (10)
t.name AS tabela,
SUM(ps.row_count) AS wiersze
FROM sys.dm_db_partition_stats AS ps
JOIN sys.tables AS t ON t.object_id = ps.object_id
WHERE ps.index_id IN (0, 1)
GROUP BY t.name
ORDER BY wiersze DESC;
Scenariusze testowe oparte na własnych procesach
Scenariusz testowy opisuje dane wejściowe oraz wynik, który uznaje się za poprawny. Bez zapisanego kryterium zaliczenia rozmowa po teście sprowadza się do wrażeń. Cztery scenariusze przydają się prawie w każdym magazynie, a kolejne dokłada się z własnych problemów.
| Scenariusz | Co sprawdzić | Kryterium zaliczenia |
|---|---|---|
| Przyjęcie niezgodne z zamówieniem | Nadwyżka albo towar spoza zamówienia | System pokazuje różnicę i pozwala ją zatwierdzić albo odrzucić |
| Kompletacja z wielu lokalizacji | Pobranie jednej pozycji z dwóch miejsc składowania | Lista prowadzi po kolei, a stan każdej lokalizacji spada poprawnie |
| Korekta po zatwierdzeniu dokumentu | Zmiana ilości albo lokalizacji po zamknięciu | Powstaje dokument korygujący, a historia zachowuje oba zapisy |
| Wydruk w formacie odbiorcy | Etykieta i dokument wydania z wymaganymi polami | Wydruk zgadza się z wzorem od odbiorcy bez ręcznej poprawki |
Sytuacje spoza prezentacji
Pokaz zwykle omija przypadki brzegowe, a w nich system się sprawdza. Towar bez kodu kreskowego oraz pozycja z dwiema jednostkami miary to codzienność wielu magazynów. Warto je przećwiczyć osobno i zapisać, ile czasu zajęło znalezienie rozwiązania.
Osobny scenariusz dotyczy błędu operatora. Skan złej lokalizacji oraz dwukrotne potwierdzenie tej samej pozycji pokazują, czy system chroni dane przed pomyłką, czy dopiero po niej pozwala ją naprawić.
Scenariusze zależne od branży
Zakres testu warto dopasować do specyfiki magazynu, bo uniwersalny skrypt prezentacji pomija to, co wyróżnia daną firmę.
- E-commerce - kompletacja pojedynczych sztuk z wielu lokalizacji i obsługa zwrotów.
- Produkcja - powiązanie przyjęć surowców ze zleceniami oraz śledzenie partii.
- Towary z terminem ważności - kontrola dat i rotacja według zasady FEFO.
- Operator logistyczny - rozdzielenie stanów wielu zleceniodawców i osobne raportowanie.
Role i uprawnienia w środowisku testowym
Test na jednym koncie administratora daje fałszywy obraz systemu. Administrator widzi wszystkie ekrany i może zatwierdzić każdy dokument, a operator na hali dostaje wyłącznie swoje zadania. Dlatego przed testem warto poprosić o konta odpowiadające rzeczywistym rolom i przejść scenariusze z poziomu każdej z nich. Zakres ról opisuje strona o rolach i użytkownikach w systemie WMS.
| Rola | Co sprawdzić w teście | Typowa nieprawidłowość |
|---|---|---|
| Operator terminala | Lista własnych zadań i potwierdzanie skanem | Dostęp do zadań z cudzej strefy |
| Kierownik zmiany | Zatwierdzanie różnic i korekty dokumentów | Korekta bez śladu, kto i kiedy ją wykonał |
| Rozliczenia | Podgląd dokumentów i zestawień bez zmiany stanów | Możliwość edycji zatwierdzonego dokumentu |
| Administrator | Słowniki i konfiguracja wydruków | Zmiana konfiguracji bez wpisu w dzienniku |
Kolejność prac w dniu testu
Test przebiega szybciej, gdy kolejność jest ustalona z góry. Poniższy plan zakłada, że dane zostały wcześniej załadowane, a konta mają nadane role.
- Logowanie - sprawdzenie, czy każde konto widzi tylko przypisane menu i magazyny.
- Przyjęcie - przejście scenariusza z niezgodnością dostawy z poziomu operatora i kierownika.
- Wydanie - kompletacja z wydrukiem dokumentu oraz kontrola stanów po operacji.
- Korekta - zmiana zatwierdzonego dokumentu i odczyt historii zmian w koncie rozliczeń.
Po zakończeniu dnia zespół zbiera oceny do wspólnego arkusza. Zapis obejmuje wynik oraz czas potrzebny na każdą operację, bo ten wskaźnik da się później porównać między systemami.
Czego środowisko demonstracyjne nie zmierzy
Demo działa na małym zbiorze danych i na infrastrukturze dobranej przez dostawcę. Nie odpowie więc na pytanie, jak system zachowa się przy kilkuset tysiącach rekordów w tabeli ruchów magazynowych ani przy dwudziestu terminalach potwierdzających zadania w tej samej minucie.
Przy większej liczbie użytkowników znaczenie mają blokady. Dwie osoby zapisujące ruch na tej samej lokalizacji nie mogą zmienić stanu jednocześnie, więc jedna transakcja czeka na drugą, a przy dużej liczbie wierszy SQL Server może zamienić blokady wierszy na blokadę całej tabeli. Test obciążeniowy odpowiada na to pytanie, a prezentacja nie. Dostawcę warto poprosić o wyniki z wdrożeń o zbliżonej skali, a nie o ogólne zapewnienie o skalowalności.
Integracje i sieć hali
Integracje wyznaczają kolejną granicę. Środowisko pokazowe rzadko łączy się z ERP używanym w firmie, więc pytanie o format wymiany i obsługę błędów trzeba zadać wprost. Mechanizmy opisuje strona o integracji WMS z ERP przez REST i kolejki.
Sieć bezprzewodowa jest trzecim obszarem. Terminal w demo działa w biurowym Wi-Fi, a w hali sygnał słabnie między wysokimi regałami. Zasięg i przełączanie między punktami dostępowymi sprawdza się na miejscu, w trakcie pilotażu, a nie w środowisku dostawcy.
Reguła: wyniki demo dotyczą funkcji oraz ergonomii, a skalę i integracje potwierdza się osobno, na danych o skali produkcyjnej.
Ocena wyniku testu i pytania do dostawcy
Test warto prowadzić w kilka osób, bo pracownik magazynu i osoba od rozliczeń oceniają co innego. Każdy wypełnia ten sam arkusz scenariuszy i wpisuje wynik: zaliczony albo niezaliczony, z krótkim opisem. Rozbieżność ocen widać na tym etapie, a nie po podpisaniu umowy. Później ten sam zespół łatwiej przejdzie przez wdrożenie systemu WMS, bo zna podstawowe funkcje.
Dokument z wynikami staje się załącznikiem do negocjacji. Lista wymagań spełnionych i niespełnionych porządkuje rozmowę o cenie i harmonogramie, a przy odbiorze wdrożenia służy jako punkt odniesienia. Kryteria oceny prezentacji systemu zebrano w tekście o prezentacji systemu WMS.
Przy porównaniu dwóch systemów pomaga prosta punktacja. Każdemu scenariuszowi przypisuje się wagę zależną od częstości procesu: przyjęcie wykonywane wiele razy dziennie waży więcej niż inwentaryzacja raz w roku. Suma ważonych ocen nie zastępuje decyzji, ale pokazuje, gdzie różnice są największe, i pozwala zapytać dostawcę o konkretne braki.
Pytania do dostawcy po zakończonym teście
Po teście rozmowa handlowa staje się konkretniejsza. Cztery pytania okazują się najczęściej rozstrzygające.
- Czas realizacji zmian - ile trwa zmiana zgłoszona po wdrożeniu i kto ją zatwierdza.
- Dostępność wsparcia - czy zgłoszenia są przyjmowane w godzinach pracy magazynu, także w okresach szczytu.
- Warunki SLA - jaki jest czas reakcji przy zgłoszeniach o różnym priorytecie.
- Eksport danych - czy kartoteki i historię dokumentów da się wyeksportować do formatu niezależnego od producenta.
Ostatnie pytanie bywa pomijane, a ma znaczenie praktyczne. Eksport w otwartym formacie chroni firmę przed uzależnieniem od jednego dostawcy i skraca ewentualną migrację do innego systemu.
Wnioski z testu najlepiej zapisywać zaraz po każdym scenariuszu. Lista spisana tydzień później z pamięci pomija drobne szczegóły, które przy wdrożeniu kosztują najwięcej.
Koszt testu i koszt błędnej decyzji
Środowisko pokazowe i czas konsultanta finansuje dostawca, który wlicza je w koszt sprzedaży, a nie w cenę licencji. Firma testująca płaci własnym czasem: przygotowaniem danych i udziałem zespołu w scenariuszach. Demo z danymi klienta bywa uzależnione od wstępnej deklaracji zainteresowania zakupem.
Koszt błędnej decyzji wynika z dwóch źródeł. Pierwszy to dostosowania, których nie przewidziano w wycenie, bo system nie obsługiwał własnego procesu, a drugi to przestoje po uruchomieniu, gdy okazuje się, że wydajność nie wystarcza. Test na własnych scenariuszach i zapisane pytania o skalę zmniejszają oba ryzyka, ale ich nie eliminują.
