Firmy, szukające sposobów na redukcję kosztów i poprawienie sprawności obsługi klienta, prędzej czy później rozważają możliwość zintegrowania sklepu internetowego z resztą swojego systemu.
Najczęściej posiadają już jakiś program do prowadzenia magazynu, który nie jest związany ze sklepem. Jest to normalne zjawisko w przypadku, kiedy sprzedaż elektroniczna jest jedynie jednym z wielu segmentów działalności przedsiębiorstwa.
Nadchodzi ten moment, kiedy klient składa zamówienie w sklepie na towar, którego fizycznie na magazynie nie ma, co powoduje, że będzie czekał na swoje zamówienie znacznie dłużej niż powinien, co może zaszkodzić reputacji biznesu.
Dzieje się tak dlatego, że system, który odpowiada za liczenie stanów magazynowych w obrębie całej spółki, nie poinformował sklep o wyczerpaniu zapasów. Potrzeba wymiany danych między systemami stała się oczywista.
Informować o stanie czy o zdarzeniach?
Generalnie są różne sposoby na osiągnięcie tego samego stanu rzeczywistości w pożądanych obszarach w różnych systemach. Jeżeli chodzi o sklep internetowy, to możemy synchronizować zamówienia i stany magazynowe okresowo, na przykład codziennie, albo możemy też informować o zdarzeniu od razu, kiedy ono zaszło. Możemy ograniczyć się tylko synchronizacją stanów magazynowych, jeżeli dane o zamówieniu nie są potrzebne w innym systemie. Nie ma sensu raczej komunikować całości stanów.
Bardzo często bywa tak, że jesteśmy ograniczeni technicznie. Systemy magazynowe mogą liczyć stan towaru w oparciu o zapisy przychodów i rozchodów z dokumentów magazynowych, wtedy samego stanu jako takiego nie wystarczy i trzeba wymyślać bardziej skomplikowane integracje. Wtedy można komunikować ze sklepu do WMS coś na zasadzie zbiorczego WZ – dokumentu wydania magazynowego.
Każde rozwiązanie będzie miało swoje wady i zalety, synchronizacja na bieżąco bardziej obciąża system, ale pozwala na szybszą obsługę klienta i znacząco redukuje ryzyko błędów związanych z nieaktualnymi informacjami w sklepie. Okresowa masowa synchronizacja zaś może zostać wykonana w nocy, wtedy, kiedy nie będzie to spowalniać pracy użytkownikom systemu i klientom.
Ale jak systemy mają wiedzieć, jakie dokumenty powinny zostać pobrane? Jakich artykułów dotyczy zamówienie?
Po to jest ID
Każdy obiekt w systemie posiada własne ID. Czasami w systemach mogą istnieć dodatkowe identyfikatory, takie jak EAN, numer referencyjny, kod, także znany jako SKU, albo inne identyfikatory. Każda wymiana informacji pomiędzy systemami powinna się odbywać w oparciu o wspólny identyfikator, żeby systemy mogły jednoznacznie zinterpretować, jakiego artykułu dotyczyła dana operacja.
ID towaru jest jak PESEL dla człowieka, jest potrzebny po to żeby odróżnić jeden od drugiego, nawet jeżeli nazywają się tak samo. Dlatego, żeby WMS potrafił przekazać do sklepu stany magazynowe konkretnego artykułu, powinien posłużyć się komunikatem, który witryna zrozumie.
Układ takich komunikatów jest opisany w dokumentacji tzw. API, czyli interfejsu, który jest przeznaczony dla aplikacji. Mając podstawowe kompetencje informatyczne możemy takie komunikaty czytać, co daje nam możliwość tworzenia integratora, który możemy powiązać z jednym z systemów i wymusić do wysyłania takich komunikatów na zewnątrz, do aplikacji, z którą chcemy się zintegrować.
Prawie wszędzie w takich komunikatach będziemy mieli do czynienia z identyfikatorem obiektu, którego dotyczą informacje. Systemy mogą mieć różne ID dla tego samego towaru, gdyż powstają niezależnie jeden od drugiego, dlatego najczęściej spotykanym identyfikatorem jest kod EAN, czyli kod kreskowy.
Co dalej?
Wnioskując że każdy system, potrafiący posługiwać się dodatkowym identyfikatorem towaru, np. EANem, oraz posiadający API, można zintegrować, otwieramy przed sobą drzwi niekończących się możliwości.
Korzyści z połączenia między sklepem internetowym a systemem ERP, CRM, WMS lub każdym innym systemie informatycznym, mającym do czynienia z towarami, są niezmierne. O nich, jak i sposobach na projekt integracyjny w firmie, opowiemy już wkrótce w osobnym artykule.