Bir süre önce, birkaç lojistik şirketi tarafından kullanılan birleşik bir taşıma API/EDI standardının olup olmadığını öğrenmek için bir arayışa girdim. Günümüzde böyle bir şeyin mutlaka var olması gerekir, değil mi? Evrensel bir gönderim API formatı?
Kısaca söylemek gerekirse, böyle bir şey mevcut değil.
Ulaşabileceğiniz en yakın şey, çok sayıda taşıyıcı API bağlantısı kurmuş ve ardından farklı taşıma hizmet sağlayıcılarına erişmek için kendi API uç noktasını sunan bir API sağlayıcısıdır.
Bu makalede, birkaç farklı taşıyıcı API'sini ele alacak, kısaca yeteneklerini açıklayacak ve bunları uygulamanın yollarını tartışacağım.
Not! Sadece evrensel bir taşıma API protokolü arıyorsanız, işte benimle hızlı bir görüşme ayarlayabileceğiniz bir bağlantı.
Neyse, şununla başlayalım...
Gerçek hayattan bir örnek vaka
Önce hedefi tanımlayalım.
Hem yurtiçi hem de uluslararası müşterileri ve tedarikçileri olan ortalama bir üreticiyi düşünün. Malların tedarikçilerden alınıp üretim tesisine teslim edilmesi, nihai ürünlerin ise müşterilere gönderilmesi gerekiyor.
Güvenilir bir tedarik zinciri kurmak için, tipik bir orta ölçekli üreticinin 10-20 taşıma ortağına ihtiyacı olacaktır:
- Yurtiçi kargolar için bir set
- Yurtiçi paletler için başka bir set
- Komşu kuzey ülkeleri için rekabetçi fiyatlar sunan bir nakliye ortağı, diğer yönler veya daha uzun mesafeler için aynı teklifi sunmayabilir.
- Aynı durum grupaj, LTL veya tam kamyon yükleri (FTL) için de geçerlidir
- Denizaşırı müşteriler için tamamen farklı bir ortak seti gerekebilir
- ... ve benzeri.
Tüm bu ilişkileri yönetmek yeterince karmaşık. Ama asıl eğlence, onların BT sistemlerini entegre etmeye çalıştığınızda başlıyor! (birleşik bir nakliye API protokolü olmadığı için)
İkinci olarak, kapsam üzerinde anlaşmamız gerekiyor.
Tüm lojistik şirketleri aynı hizmet seviyesini sunmaz. Bazıları anlık navlun fiyatlandırması, rezervasyon, etiketler, takip, kurye talepleri vb. sağlayan çok gelişmiş API'lere sahipken, diğerleri sadece giriş yapıp rezervasyon gönderebileceğiniz bir portala sahip olabilir. Bazılarının hiç BT sistemi yoktur - sadece e-posta kullanırlar. Hedef senaryomuz için, işleri basit tutalım ve sadece şunları hedefleyelim:
- Bir taşıma siparişi göndermek
- Taşıma etiketlerini geri almak
- Şanslıysak belki tahmini taşıma fiyatını almak!
Kulağa oldukça basit geliyor, değil mi? Ah, keşke öyle olsaydı...
Taşıyıcı bağlantıları – ormana hoş geldiniz
Çoğu şirket için sektör standardı gibi görünen işleri ele almanın manuel yolu, mümkün olduğunca taşıyıcı portallarını kullanmayı ve geri kalan taşıma ortaklarıyla e-posta yoluyla iletişim kurmayı içerir. Örneğimizde, taşıma fiyat listelerinin, programların, teslim sürelerinin ve fatura işlemlerinin ayrı ayrı yönetildiğini varsayıyoruz. Rezervasyon gönderimleri için, ERP sistemimizden bir API bağlantısı kurmayı hedefliyoruz.
Aşağıdaki taşıma şirketleri listesini seçtiğimizi ve ERP yazılımımızdan onların sistemlerine doğrudan bir API bağlantısı kurmamız gerektiğini varsayalım. Bu seçim rastgeledir ve dışarıdaki farklı taşıyıcı API'lerinin sadece bir kısmını kapsar.
DHL Express – MyDHL adlı bir portal kullanır ve bu portalın aynı zamanda API yetenekleri vardır. Ancak, Freight, Express ve Global Forwarding bölümleri için farklı API'ler ve çeşitli bölgelerde farklı API yaklaşımları kullanır. Web servisine erişim SOAP protokolü, RESTful Hizmetleri veya düz XML gerektirir ve geliştiricilerin XML/JSON konusunda bilgili olmaları ve web servisleri hakkında temel bir anlayışa sahip olmaları gerekir. Sadece API spesifikasyonu 457 sayfa uzunluğundadır. Kapsamlıdır, ancak geliştiricinin sadece bunu okumak için harcadığı saatler için size ücret talep edeceğini unutmayın. Uygulandıktan sonra, kimlik doğrulamadan adres doğrulamalarına, uygunluk kontrollerine ve etiket taleplerine kadar, sevkiyat başına ortalama 5-12 istek tetiklemeniz gerekecektir.
Schenker – çeşitli bölgelerde farklı API/EDI çözümleri kullanır. En yaygın olarak, XML formatında bir SOAP protokolü kullanır. Tüm olası hatalar düzgün bir şekilde ele alındığı sürece mesajın kendisi basittir. Geliştiricilerin API'yi uygulamak için kişiselleştirilmiş erişime ihtiyacı vardır. Bulunduğunuz yere bağlı olarak, bunun yerine bir EDIFACT çözümü uygulamanız istenebilir, bunu daha sonra ele alacağım.
DSV – yakın zamanda MyDSV adlı API özellikli portallarına geçiş yaptı. API oldukça yeni olduğu için, API dünyasındaki en son ve en modern yaklaşımlardan bazılarından yararlanıyor. Kimlik doğrulama ve ürün kataloğunda gezinme karmaşıklığına rağmen, yaklaşım basittir. Yine, bulunduğunuz yere bağlı olarak, EDIFACT tercih edilebilir.
FedEx ve TNT – bu eğlenceli olabilir. Öncelikle, TNT mi yoksa FedEx hizmetlerini mi kullandığınızı belirlemeniz gerekiyor. Uzun yıllardır aynı şirket olmaları gerekmesine rağmen, geçiş hala beklemede. Sözleşmeniz TNT ile ise, büyük olasılıkla TNT Express Connect API'sini uygulamanız istenecektir. Uygulamanın kendisi ortalama karmaşıklıktadır. Dezavantajı, bu API'nin artık kullanımdan kaldırılmış sayılması ve sonunda kapatılacak olmasıdır. Öte yandan, FedEx API'si daha karmaşıktır ve bulunduğunuz bölgeye bağlı olarak çeşitli seçenekler sunar. Cargoson'da, FedEx Compatible API'yi uyguladık, bu API bazı çok güzel ek işlevsellikler sunuyor ancak sadece FedEx Compatible ortakları için mevcut.
UPS – kimlik doğrulama için JSON tabanlı bir API ve OAuth kullanır, bu da rezervasyonunuzu geçirmeden ve etiketleri geri almadan önce tetiklemeniz gereken oldukça fazla istek olduğu anlamına gelir.
Sonra, DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics vb. gibi birçok taşıma şirketi tarafından kullanılan EDIFACT var. Bu çok eski bir standarttır ve birkaç lojistik şirketi için tek bir API entegrasyonuyla işinizi halledebileceğiniz gibi görünse de, tekrar düşünün. En büyük dezavantajı, dosya değişimine dayalı bir bağlantı olmasıdır, yani gerçek, fiziksel bir dosya oluşturmanız, sonra bunu FTP üzerinden iletmeniz ve her şeyin yolunda olduğunu ummanız gerekir çünkü hatalar ve uyarılar hakkında çok zahmetli bir geri bildirim vardır.
EDIFACT'e benzer olan FORTRAS, aynı eksikliklere sahip dosya tabanlı bir bağlantıdır. Daha çok Almanya ve komşu ülkelerde kullanılmaktadır. Sadece dosya değişimi zorlu değil, aynı zamanda dosya formatının kendisi de okunması zor ve bu nedenle hataların ayıklanması çok zaman alıcıdır. Bunu kullanan bazı tanınmış şirketler arasında Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss vb. bulunmaktadır.
Yukarıda bahsedilen tüm entegrasyonları uyguladıktan sonra bile soru şu kalıyor:
Herhangi bir BT sistemi veya portalı olmayan, taşıma siparişlerini kabul etmek için bir API'si olmayan taşıyıcı şirketlerle ne yaparsınız?
En basit çözüm, basit bir e-posta göndermektir. Bu kulağa basit gelse de, biraz daha derine inelim. Mail sunucunuza teknik bağlantıyı kurmak bir şeydir, peki ya kişiler? Normalde, farklı yönler farklı kişiler tarafından ele alınır ve insanlar pozisyonlarını değiştirir. Bu nedenle, ERP'nize oldukça kapsamlı bir iletişim matrisi eklemeniz gerekecektir.
Peki, farklı taşıyıcı API'leri ve EDI protokolleriyle uğraşmaya alternatifler nelerdir?
Düşünülmesi gereken bir seçenek çoklu taşıyıcı API'sidir. Esasen bu, modern API'ler, eski EDIFACT veya FORTRAS tabanlı EDI protokolleri veya e-posta entegrasyonları olsun, tüm taşıyıcı bağlantılarını kurmuş ve bunları kendi standartlaştırılmış gönderim API'si aracılığıyla kullanıma sunmuş bir hizmet sağlayıcısıdır. Çeşitli taşıyıcı API'lerini uygulamak ve güncel tutmak yerine, sadece bir çoklu taşıyıcı API standardı uygulayabilir ve tüm taşıma siparişlerinizi bunun üzerinden tetikleyebilirsiniz.
Ama biz daha da ileri gittik.
Çoklu taşıyıcı yazılımı – mevcut taşıyıcılarınızı daha iyi hale getirmek?
Farklı lojistik şirketleri farklı hizmet seviyeleri sunar. Bazıları rezervasyon API'si sunarken diğerleri sunmaz; bazıları takip yetenekleri sunarken diğerleri bu özellikten yoksundur. Cargoson'da, her taşıma şirketi için boşlukları dolduran tüm özellikleri uyguladık.
Örneğin, bir taşıyıcı çevrimiçi rezervasyon sunmadığında, biz bunun için bir portal sağlıyoruz. Takip özelliği eksikse, biz ekliyoruz. Teslimat kanıtı (POD) ve diğer belgeleri yüklemek için sistemlerimiz, tam özellikli çoklu taşıyıcı API'miz, ETA tahminleri, taşıma fiyatı hesaplamaları, performans istatistikleri ve hatta taşıma CO2 emisyonu rakamları var. Temel olarak, bir taşıyıcının eksik olduğu her şeyi, taşıyıcılarınız arasındaki BT veya hizmet seviyesi farklılıkları hakkında endişelenmenize gerek kalmaması için biz inşa ettik.
İşte gerçek dünyadan bir örnek: FedEx, TNT ve DHL Express gibi büyük oyuncular bir fiyatlandırma API'si sunar. Bu, Cargoson'dan bir fiyat talebi tetiklediğinizde, fiyatların doğrudan taşıyıcının sisteminden çekildiği anlamına gelir. Ancak, DSV gibi bir şirketin fiyatlandırma API'si sunmadığı durumlarda, DSV tarafından sağlanan Excel veya PDF fiyat listesi Cargoson'a yüklenir ve fiyat hesaplaması sistemimiz içinde gerçekleştirilir. Bunun için güçlü bir navlun fiyatı yükleme ve hesaplama motorumuz var. Aynı yaklaşım tüm diğer taşıma şirketleri için de uygulanabilir ve diğer özellikler için de geçerlidir.
Amacımız basit: hepsi aynı yeteneklerle başlamasalar bile, tüm taşıyıcılar arasında tutarlı, yüksek kaliteli bir deneyim sunmak. Bir nevi de facto evrensel taşıyıcı API standardı ve çoklu taşıyıcı platformu bir arada.
Taşıyıcı entegrasyonlarınızı yönetmek için daha iyi bir yol arıyorsanız, Cargoson size yardımcı olabilir. Platformumuz, bireysel yeteneklerinden bağımsız olarak tüm taşıyıcılarınıza bağlanan tek, standartlaştırılmış bir taşıma API'si sağlar. Bu, altta yatan teknik farklılıklar hakkında endişelenmeden tüm gönderim hizmetlerinize tek bir birleşik arayüz üzerinden erişebileceğiniz anlamına gelir.
Bunun işletmeniz için nasıl çalışabileceğini görmek ister misiniz? Mevcut kurulumunuzu ve özel entegrasyon zorluklarınızı tartışmak için hızlı bir görüşme yapalım. Cargoson'un sizinkine benzer durumlarda şirketlere nasıl yardımcı olduğuna dair bazı gerçek dünya örneklerini gözden geçirebiliriz: