გარკვეული დროის წინ დავისახე მიზნად გამერკვია, არსებობდა თუ არა ერთიანი სატრანსპორტო API/EDI სტანდარტი, რომელსაც რამდენიმე ლოგისტიკური კომპანია იყენებს. რა თქმა უნდა, დღევანდელ ეპოქაში ასეთი რამ უნდა არსებობდეს, არა? უნივერსალური გადაზიდვის API ფორმატი?

მოკლედ რომ ვთქვათ, ასეთი რამ არ არსებობს.

ყველაზე ახლოს რაც შეიძლება მივიდეთ, არის რომელიმე API პროვაიდერი, რომელსაც აქვს ბევრი გადამზიდავის API კავშირი და შემდეგ გვთავაზობს საკუთარ API წერტილს სხვადასხვა სატრანსპორტო სერვისის პროვაიდერებთან წვდომისთვის.

ამ სტატიაში განვიხილავ რამდენიმე სხვადასხვა გადამზიდავის API-ს, მოკლედ აღვწერ მათ შესაძლებლობებს და განვიხილავ მათი დანერგვის გზებს.

შენიშვნა! თუ უბრალოდ ეძებთ უნივერსალურ სატრანსპორტო API პროტოკოლს, აქ არის ბმული, სადაც შეგიძლიათ დაჯავშნოთ სწრაფი ზარი ჩემთან.

ყოველ შემთხვევაში, დავიწყოთ...

პირველ რიგში, განვსაზღვროთ მიზანი.

წარმოიდგინეთ საშუალო მწარმოებელი როგორც ადგილობრივი, ასევე საერთაშორისო მომხმარებლებითა და მომწოდებლებით. საქონელი უნდა აიღონ მომწოდებლებისგან და მიაწოდონ საწარმოო ადგილს, ხოლო საბოლოო პროდუქტები უნდა გაიგზავნოს მომხმარებლებთან.

საიმედო მიწოდების ჯაჭვის დასამყარებლად, თქვენს ტიპურ საშუალო ზომის მწარმოებელს დასჭირდება 10-20 სატრანსპორტო პარტნიორი:

ყველა ამ ურთიერთობის მართვა საკმაოდ რთულია. მაგრამ ნამდვილი გართობა იწყება მაშინ, როცა ცდილობთ მათი IT სისტემების ინტეგრაციას! (რადგან არ არსებობს ერთიანი სატვირთო API პროტოკოლი)

მეორე, უნდა შევთანხმდეთ მოქმედების სფეროზე.

ყველა ლოგისტიკური კომპანია არ გთავაზობთ ერთნაირ მომსახურების დონეს. ზოგიერთს აქვს ძალიან დახვეწილი API, რომელიც უზრუნველყოფს მყისიერ სატვირთო ფასებს, დაჯავშნას, ეტიკეტებს, თვალყურის დევნებას, კურიერის მოთხოვნებს და ა.შ., მაშინ როცა სხვებს შეიძლება მხოლოდ პორტალი ჰქონდეთ, სადაც შეგიძლიათ შეხვიდეთ და შეიტანოთ დაჯავშნა. ზოგიერთს საერთოდ არ აქვს IT სისტემები - მხოლოდ ელფოსტა. ჩვენი სამიზნე სცენარისთვის, მოდით, შევინარჩუნოთ სიმარტივე და უბრალოდ მივისწრაფოთ:

ჟღერს საკმაოდ მარტივად, არა? ოჰ, ნეტავ ასე იყოს...

საქმეების მართვის მანუალური გზა, რომელიც ჩანს, რომ არის ინდუსტრიის სტანდარტი უმეტესი კომპანიებისთვის, მოიცავს გადამზიდავების პორტალების გამოყენებას, სადაც ეს შესაძლებელია, და ელფოსტით კომუნიკაციას დანარჩენ სატრანსპორტო პარტნიორებთან. ჩვენს მაგალითში, ვვარაუდობთ, რომ სატრანსპორტო ფასების სიები, განრიგები, მიწოდების ვადები და ინვოისების მართვა ხდება ცალკე. დაჯავშნის წარდგენისთვის, ჩვენ მიზნად ვისახავთ API კავშირის აგებას ჩვენი ERP სისტემიდან.

დავუშვათ, რომ შევარჩიეთ შემდეგი სატრანსპორტო კომპანიების სია და გვჭირდება პირდაპირი API კავშირის აგება მათ სისტემებთან ჩვენი ERP პროგრამული უზრუნველყოფიდან. ეს შერჩევა შემთხვევითია და მოიცავს მხოლოდ მცირე ნაწილს იმ სხვადასხვა გადამზიდავის API-ებიდან, რომლებიც არსებობს.

DHL Express – იყენებს პორტალს სახელწოდებით MyDHL, რომელსაც ასევე აქვს API შესაძლებლობები. თუმცა, ის იყენებს სხვადასხვა API-ებს Freight, Express და Global Forwarding განყოფილებებისთვის და სხვადასხვა API მიდგომებს სხვადასხვა რეგიონში. ვებ სერვისზე წვდომა მოითხოვს SOAP პროტოკოლს, RESTful სერვისებს ან უბრალო XML-ს, და დეველოპერები უნდა იცნობდნენ XML/JSON-ს და ჰქონდეთ ვებ სერვისების საბაზისო გაგება. მხოლოდ API სპეციფიკაცია 457 გვერდიანია. ის საფუძვლიანია, მაგრამ თქვენი დეველოპერი დაგარიცხავთ საათებს მხოლოდ მის წაკითხვაზე დახარჯული დროისთვის. დანერგვის შემდეგ, თქვენ დაგჭირდებათ საშუალოდ 5-12 მოთხოვნის გაგზავნა თითოეული გადაზიდვისთვის, დაწყებული ავთენტიფიკაციიდან, მისამართების ვალიდაციით, ხელმისაწვდომობის შემოწმებით და ეტიკეტების მოთხოვნით.

Schenker – იყენებს სხვადასხვა API/EDI გადაწყვეტილებებს სხვადასხვა რეგიონში. ყველაზე ხშირად იყენებს SOAP პროტოკოლს XML ფორმატით. თვითონ შეტყობინება მარტივია, თუ ყველა შესაძლო შეცდომა სწორად არის დამუშავებული. დეველოპერებს სჭირდებათ პერსონალიზებული წვდომა API-ის დასანერგად. თქვენი მდებარეობის მიხედვით, შეიძლება გთხოვონ EDIFACT გადაწყვეტილების დანერგვა, რასაც მოგვიანებით განვიხილავ.

DSV – ახლახანს გადავიდა თავის API-უნარიან პორტალზე სახელწოდებით MyDSV. იმის გათვალისწინებით, რომ API საკმაოდ ახალია, ის იყენებს API სამყაროს ზოგიერთ უახლეს და ყველაზე თანამედროვე მიდგომებს. მიუხედავად სირთულისა ავთენტიფიკაციისას და მათი პროდუქტების კატალოგში ნავიგაციისას, მიდგომა მარტივია. კვლავ, თქვენი მდებარეობის მიხედვით, შეიძლება უპირატესობა მიენიჭოს EDIFACT-ს.

FedEx და TNT – ეს შეიძლება იყოს გასართობი. პირველ რიგში, უნდა განსაზღვროთ, იყენებთ TNT-ის თუ FedEx-ის სერვისებს. მიუხედავად იმისა, რომ ისინი უკვე რამდენიმე წელია ერთი და იგივე კომპანია უნდა ყოფილიყვნენ, მიგრაცია ჯერ კიდევ მიმდინარეობს. თუ თქვენი კონტრაქტი TNT-სთან არის, სავარაუდოდ, გთხოვენ TNT Express Connect API-ის დანერგვას. თვითონ დანერგვა საშუალო სირთულისაა. უარყოფითი მხარე ისაა, რომ ეს API მოძველებულად ითვლება და საბოლოოდ გაუქმდება. მეორე მხრივ, FedEx API უფრო რთულია და გთავაზობთ რამდენიმე ვარიანტს იმის მიხედვით, თუ რომელ რეგიონში ხართდაფუძნებული. Cargoson-ში ჩვენ დავნერგეთ FedEx Compatible API, რომელიც გვთავაზობს ზოგიერთ ძალიან მოხერხებულ დამატებით ფუნქციონალს, მაგრამ ხელმისაწვდომია მხოლოდ FedEx Compatible პარტნიორებისთვის.

UPS – იყენებს JSON-ზე დაფუძნებულ API-ს და OAuth-ს ავთენტიფიკაციისთვის, რაც ნიშნავს, რომ საკმაოდ ბევრი მოთხოვნის გაგზავნა მოგიწევთ, სანამ თქვენი დაჯავშნა გავა და ეტიკეტებს უკან მიიღებთ.

შემდეგ გვაქვს EDIFACT, რომელსაც იყენებს ბევრი სატრანსპორტო კომპანია, როგორიცაა DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics და ა.შ. ეს არის ძალიან ძველი სტანდარტი და მიუხედავად იმისა, რომ შეიძლება მოგეჩვენოთ, რომ შეგიძლიათ ერთი API ინტეგრაციით გამოხვიდეთ რამდენიმე ლოგისტიკური კომპანიისთვის, კიდევ ერთხელ დაფიქრდით. ყველაზე დიდი ნაკლი ისაა, რომ ეს არის ფაილების გაცვლაზე დაფუძნებული კავშირი, რაც ნიშნავს, რომ მოგიწევთ რეალური, ფიზიკური ფაილის გენერირება, შემდეგ მისი გადაცემა FTP-ით და სიტყვასიტყვით იმედი უნდა გქონდეთ, რომ ყველაფერი კარგადაა, რადგან შეცდომებისა და გაფრთხილებების შესახებ უკუკავშირი ძალიან მოუხერხებელია.

EDIFACT-ის მსგავსია FORTRAS, ფაილზე დაფუძნებული კავშირი იმავე ნაკლოვანებებით. ის უფრო მეტად გამოიყენება გერმანიაში და მეზობელ ქვეყნებში. არა მხოლოდ ფაილების გაცვლაა გამოწვევა, არამედ თვითონ ფაილის ფორმატი რთულად წასაკითხია და, შესაბამისად, შეცდომების გასწორება ძალიან დროის მომცმელია. ზოგიერთი ცნობილი კომპანია, რომელიც მას იყენებს, მოიცავს Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss და ა.შ.

ზემოთ ხსენებული ყველა ინტეგრაციის დანერგვის შემდეგაც კი, კითხვა რჩება:

რას აკეთებთ იმ გადამზიდავ კომპანიებთან, რომლებსაც არ აქვთ არანაირი IT სისტემა ან პორტალი, არათუ API სატრანსპორტო შეკვეთების მისაღებად?

ყველაზე მარტივი გამოსავალია მარტივი ელფოსტის გაგზავნა. მიუხედავად იმისა, რომ ეს შეიძლება მარტივად ჟღერდეს, მოდით უფრო ღრმად ჩავუფიქრდეთ. თქვენს საფოსტო სერვერთან ტექნიკური კავშირის დამყარება ერთი საქმეა, მაგრამ რა ხდება კონტაქტებთან დაკავშირებით? ჩვეულებრივ, სხვადასხვა მიმართულებას სხვადასხვა საკონტაქტო პირი მართავს და ადამიანები იცვლიან პოზიციებს. ამრიგად, თქვენს ERP-ში საკმაოდ ყოვლისმომცველი საკონტაქტო მატრიცის აგება მოგიწევთ.

მაშ, რა არის ალტერნატივა გადამზიდავების განსხვავებულ API-ებთან და EDI პროტოკოლებთან ბრძოლის?

ერთ-ერთი ვარიანტი, რომელიც უნდა განიხილოთ, არის მრავალი გადამზიდავის API. არსებითად, ეს არის სერვისის პროვაიდერი, რომელმაც ააგო ყველა გადამზიდავის კავშირი, იქნება ეს თანამედროვე API-ები, ძველი EDIFACT- ან FORTRAS-ზე დაფუძნებული EDI პროტოკოლები თუ ელფოსტის ინტეგრაციები, და გახადა ისინი ხელმისაწვდომი საკუთარი, სტანდარტიზებული გადაზიდვის API-ის მეშვეობით. სხვადასხვა გადამზიდავის API-ების დანერგვისა და მათი განახლების ნაცვლად, შეგიძლიათ დანერგოთ მხოლოდ ერთი მრავალი გადამზიდავის API სტანდარტი და გააგზავნოთ ყველა თქვენი სატრანსპორტო შეკვეთა მის მეშვეობით.

მაგრამ ჩვენ კიდევ უფრო შორს წავედით.

მრავალი გადამზიდავის პროგრამული უზრუნველყოფა – თქვენი არსებული გადამზიდავების გაუმჯობესება?