Od dziurki w karcie do zamówienia w OMS. Krótka historia łączenia firmowych danych

Zamówienie jest w sklepie, ale ktoś musi jeszcze przepisać jego pozycje do programu handlowego. Komputer pomógł przyjąć zakup, a dalszą drogę informacja pokonuje dzięki człowiekowi. Ten widok dobrze wprowadza w historię firmowych danych: maszyny uczyły się je liczyć, odnajdywać i przekazywać. Każda z tych umiejętności rozwiązywała inny problem.

1890: zanim maszyna policzyła, człowiek robił dziurki

Przy amerykańskim spisie ludności z 1890 roku wykorzystano system Hermana Holleritha. Urzędnicy przenosili odpowiedzi z papierowych formularzy na karty dziurkowane. Otwór w odpowiednim miejscu oznaczał określoną cechę osoby. Czytnik rozpoznawał zapis za pomocą styków elektrycznych, a liczniki rejestrowały wynik. Tak przebieg pracy opisuje archiwum historii IBM.

Karta była więc przygotowaną dla maszyny postacią informacji. Wcześniej człowiek musiał odczytać formularz i poprawnie odwzorować jego treść. IBM opisuje też późniejsze zastosowania tabulatorów w przedsiębiorstwach, między innymi na kolei i w domach towarowych. Zmieniało się miejsce pracy urządzenia, ale pozostało znaczenie starannie przygotowanego zapisu.

1956: potrzebny zapis można odnaleźć na dysku

Kolejną przeszkodą był dostęp do informacji. W IBM 305 RAMAC z 1956 roku zastosowano dysk o dostępie swobodnym. Magnetyczna głowica docierała do danych zapisanych na obracających się dyskach. Zamiast szukać potrzebnego zapisu przez przeglądanie stosu kart, można było sięgnąć do określonego miejsca w pamięci dyskowej.

Było to osiągnięcie dotyczące przechowywania i odszukiwania danych. Samo w sobie nie uzgadniało jednak, jak inna firma ma odczytać zamówienie. Wygodniejszy dostęp do własnej informacji i możliwość przekazania jej partnerowi pozostawały odrębnymi zadaniami.

EDI: po co drukować coś, co już jest w komputerze?

Poradnik NIST z lutego 1996 roku opisuje znajomy paradoks. Firma wprowadza dane do programu, drukuje formularz i wysyła go partnerowi. Odbiorca ponownie wpisuje otrzymaną treść do swojej aplikacji. Komputery pracują po obu stronach, lecz pomiędzy nimi nadal znajduje się papier i ręczne przepisywanie.

EDI, czyli elektroniczna wymiana danych, pozwala przekazywać między komputerami uporządkowane informacje biznesowe. Początkowe uzgodnienia formatów między parami partnerów utrudniały współpracę z kolejnymi firmami. Potrzebne były wspólne reguły. NIST podaje, że w 1979 roku ANSI powołało komitet ASC X12 do opracowywania standardów takiej wymiany.

Innym ważnym punktem było zatwierdzenie reguł składni UN/EDIFACT jako standardu ISO w 1987 roku. Wytyczne UNECE wyjaśniają, że nastąpiło to po zbliżeniu propozycji ONZ i amerykańskiego ANSI. Sednem tej historii jest wspólnie uzgodniony sposób zapisu, dzięki któremu odbiorca może przetworzyć otrzymane dane.

EDI, API i OMS nie są kolejnymi nazwami tego samego

EDI dotyczy wymiany uporządkowanych informacji handlowych według uzgodnionych reguł. API jest ustalonym sposobem udostępniania danych lub funkcji innemu programowi. Pozwala aplikacji poprosić inną aplikację o wykonanie określonej czynności lub przekazanie informacji. OMS to system do zarządzania przebiegiem zamówienia, od jego przyjęcia po realizację i obsługę po sprzedaży.

To różne role, a nie ranking nowoczesności. Wybór dla sklepu warto oprzeć na tym, co trzeba połączyć i jak ma wyglądać obsługa zakupów. Sam skrót na ofercie nie jest powodem, aby wdrażać wszystkie rozwiązania naraz.

Co z tej historii wykorzystać w swoim sklepie?

Poniższe wskazówki są naszą propozycją organizacji pracy. Zacznij od prześledzenia przykładowego zamówienia w obecnych programach. Zapisz, gdzie zostaje przyjęte, kto sprawdza możliwość realizacji, skąd magazyn bierze listę do przygotowania i gdzie powstaje dokument sprzedaży. Zaznacz miejsca, w których pracownik ponownie wpisuje tę samą informację.

Przy każdym przekazaniu sprawdź znaczenie danych. Czy kod wskazuje ten sam wariant produktu? Czy ilość oznacza sztuki, czy opakowania? Co dla obsługi oznacza status „gotowe”? Takie pytania pozwalają ustalić, co właściwie ma być przekazywane. Przeniesienie liczby bez wyjaśnienia jej znaczenia nie daje jeszcze pewności, że odbiorca wykona właściwą czynność.

Następnie ustal, który program ma rozstrzygać o danej informacji oraz co pracownik robi, gdy przekazanie się nie powiedzie. Sprawdź również anulowanie i zmianę zamówienia: gdzie zostają odnotowane i kto musi je zobaczyć przed wysyłką. Dopiero z takim opisem porównuj możliwości połączeń. Kryterium jest konkretne: czy obsługa potrafi przeprowadzić zakup przez uzgodnioną drogę i rozpoznać wyjątek wymagający działania.

Jeśli potrzebujesz pomocy w ułożeniu tego procesu, Grupa Wdrożeniowa prowadzi płatne wdrożenia i konsultacje. Zakres możesz omówić z Marcinem pod numerem 666 998 847.

Źródła

• IBM — The punched card tabulator
• IBM — RAMAC
• NIST SP 500-231 — Guidelines for the Evaluation of Electronic Data Interchange Products
• UNECE — UN/EDIFACT Syntax Implementation Guidelines
• IBM — What is an API?
• IBM — What is order management?
• Grupa Wdrożeniowa — Wdrożenia i konsultacje

Powiązane materiały