Lojistik Otomasyon Sistemleri ve Tedarik Zincirinde Süreç Otomasyonu

Lojistik otomasyonu, bir sevkiyatın sipariş anından teslim kanıtına kadar geçtiği her adımı insan elinin veri kopyalamasına ihtiyaç duymadan yürüten; her adımın kanıtını kayıt altına alan ve hata olduğunda bunu sessizce yutmak yerine görünür kılan bir sistem kurmaktır. Kargo takip ekranına bakıp müşteriye tek tek mesaj yazmak, aynı sevkiyatı hem ERP'ye hem taşıma bildirimi ekranına elle girmek ve gecikmeyi ancak müşteri aradığında öğrenmek; bir yazılım eksikliği değil, veri akışının hiç tasarlanmamış olmasının sonucudur. Bu sayfa, tedarik zincirinde hangi adımın otomatikleştirilebileceğini, hangisinin insan onayında kalması gerektiğini ve Türkiye'de yasal olarak hangi bildirimin zaten elektronik ortamda beklendiğini uçtan uca anlatır.

Kısa cevap: Lojistikte otomasyona geçmenin doğru sırası "önce müşteri bildirimi" değildir. Doğru sıra; önce sevkiyatın tek bir kimlik altında tekilleştirilmesi, sonra zorunlu resmi bildirimlerin (U-ETDS yük bildirimi, e-İrsaliye) sisteme bağlanması, en son da müşteri ve operasyon bildirimlerinin bu tekil kayıttan beslenmesidir. Ters sıradan başlayan projeler, hızlı mesaj gönderen ama hangi sevkiyatın gerçekten bildirildiğini kanıtlayamayan bir yapı üretir.

Tedarik Zincirinde İletişim Kopukluğu Neyi Pahalıya Getirir?

Lojistik süreçlerinde gönderinin anlık durumunun (yüklendi, yolda, gümrükte, dağıtımda, teslim edildi) alıcıya ve operasyon ekibine zamanında iletilmemesi tek başına bir iletişim problemi gibi görünür. Oysa maliyeti üç ayrı yerden çıkar: müşteri destek hattına düşen "nerede" çağrıları, gecikmenin ancak şikâyetle fark edilmesi nedeniyle kaybedilen müdahale süresi ve aynı bilginin farklı sistemlere elle girilmesinden doğan tutarsızlık.

Bu üç maliyet kalemi birbirini besler. Operasyon ekibi gün içinde durumu manuel bildirdiği için kayıt tutmaya vakit bulamaz; kayıt olmadığı için hangi taşıyıcının hangi hatta kaç kez geciktiği ölçülemez; ölçülemediği için taşıyıcı performansı sözleşme yenilemesinde veriye değil hafızaya dayanır. Otomasyonun asıl kazancı mesajın hızlı gitmesi değil, her sevkiyatın arkasında sorgulanabilir bir kayıt bırakmasıdır.

Lojistik Otomasyon Sistemleri Tam Olarak Neyi Otomatikleştirir?

Lojistik otomasyon sistemleri tek bir üründen ibaret değildir; birbirine bağlanan dört katmandan oluşur. Bu katmanları ayırmadan yapılan platform seçimleri, çoğu zaman ihtiyacın yalnız bir bölümünü karşılayan bir araca tüm süreci yıkmakla sonuçlanır.

• Kayıt katmanı (ERP / WMS / TMS): Siparişin, stok hareketinin ve sevkiyat emrinin doğduğu yer. Otomasyon burada veri üretmez, üretilmiş veriyi okur.
• Entegrasyon katmanı (iş akışı motoru): Sistemler arasında veriyi taşıyan, dönüştüren, koşula göre dallandıran ve hata durumunda yeniden deneyen katman. Make.com veya kurum içi bir entegrasyon servisi bu görevi üstlenebilir.
• Yükümlülük katmanı (resmi bildirimler): U-ETDS yük taşıma bildirimi ve e-İrsaliye gibi, tercih değil zorunluluk olan elektronik bildirimler.
• İletişim katmanı (müşteri ve operasyon bildirimi): WhatsApp, SMS, e-posta ve iç bildirim kanalları. Bu katman her zaman en son kurulmalıdır, çünkü kaynağı diğer üçünün doğruluğudur.

Otomatikleştirilmemesi gereken adımlar da bu kadar nettir: gümrük beyanının içeriğine karar vermek, hasarlı teslimatta tazminat kabulü, tarife dışı fiyat onayı ve müşteriye geri alınamaz taahhüt vermek. Bu adımlarda sistemin görevi kararı vermek değil, kararı verecek kişiye eksiksiz dosyayı hazırlamak ve onayı beklemektir. Bu ayrımın mimarisini otonom ajanlarda insan onayı yazısında ayrıntılı anlatıyorum.

Ulaştırma Otomasyonu ve U-ETDS Yük Bildirimi Entegrasyonu

Türkiye'de ulaştırma otomasyonu konusunun en somut ayağı, Ulaştırma ve Altyapı Bakanlığı'nın işlettiği U-ETDS (Ulaştırma Elektronik Takip ve Denetim Sistemi) yük taşıma bildirimidir. Bakanlığın yayımladığı UETDS Yük Taşıma Bildirimi Kurum Entegrasyonu Teknik Tasarım Dokümanı (Sürüm 1.7, Kasım 2019) firmaların bildirimi e-Devlet ekranından elle girmek yerine kendi yazılımlarından web servis üzerinden yapabileceğini tanımlar. Doküman, sistemin temel veri iletişim yöntemi olarak HTTPS üzerinden SOAP web servislerini benimsediğini ve verinin XML tabanlı taşındığını açıkça yazar. Genel bilgi ve duyurular için Bakanlığın U-ETDS portalı güncel kaynaktır.

Entegrasyonun pratikte anlamı şudur: sevkiyat kaydınız ERP'de oluştuğu anda, aynı kaydın bildirim alanları otomatik doldurulup Bakanlığın servisine gönderilebilir. Teknik dokümanda tanımlı akış, bir bildirim gönderildiğinde geriye bir referans numarası döndüğünü; araç, şoför ve iptal işlemlerinin bu referans üzerinden yürütüldüğünü gösterir. Servisin ayakta olup olmadığını sınayan ayrı bir test metodu, yük türü ve yük birimi gibi kod listelerini veren parametre metotları ve sonuç kodunun sıfır dönmesiyle başarıyı ifade eden bir sözleşme vardır.

Buradaki en kritik tasarım kararı, firmanın kendi sefer numarasını bildirimle birlikte göndermesidir. Bu alan zorunlu değildir; ancak gönderilmediğinde Bakanlık tarafındaki kayıtla kendi sistemindeki kaydı eşleştirmenin güvenilir bir yolu kalmaz. Denetim anında "bu sevkiyatı bildirdik" demek yetmez, hangi bildirimin hangi sevkiyata ait olduğunu göstermek gerekir.

Nakliye Otomasyonu: Sefer Planlama, Araç ve Sürücü Atamasında Ne Değişir?

Lojistik otomasyonu ile nakliye otomasyonu çoğu zaman aynı anlamda kullanılır, oysa kapsamları farklıdır. Lojistik otomasyonu siparişten teslim kanıtına kadar uzanan bilgi zincirinin tamamını kapsar; nakliye otomasyonu ise bu zincirin taşıma icrasına bakan bölümüdür: seferin oluşturulması, araç ve sürücünün atanması, yükleme sırasının belirlenmesi ve teslim kanıtının toplanması. Ayrımı yapmak önemlidir, çünkü bir işletmenin gerçek darboğazı çoğu zaman bilgi akışında değil, bu atama kararlarının her sabah elle ve hafızadan verilmesindedir.

Atama kararı görünürde basittir, pratikte çok kısıtlı bir problemdir. Bir seferi bir araca bağlarken en az şu kısıtlar aynı anda sağlanmalıdır: aracın tonaj ve hacim kapasitesi, yükün gerektirdiği araç tipi (tenteli, frigorifik, tehlikeli madde uygunluğu), sürücünün yasal çalışma ve dinlenme süresi sınırları, aracın mevcut konumu ve bir sonraki randevusu, müşterinin teslim zaman aralığı. Bu kısıtlar bir planlayıcının zihninde tutulduğunda karar hızlıdır ama devredilemez; kişi izinliyken süreç durur ve verilen kararın gerekçesi kayıtlı değildir.

Otomasyon burada iki farklı olgunluk seviyesinde kurulabilir ve ikisini karıştırmamak gerekir. Birinci seviye kural motorudur: uygun olmayan araçları eleyip planlayıcıya sıralı bir aday listesi sunar, kararı insan verir. İkinci seviye rota ve yük optimizasyonudur: bir hedef fonksiyonu (toplam mesafe, boş kilometre, geciken teslimat sayısı) tanımlayıp çözümü sisteme bırakır. Çoğu orta ölçekli işletme için doğru başlangıç birincisidir; ikincisi ancak adres, kapasite ve süre verisi güvenilir biçimde toplanmaya başladıktan sonra anlamlı sonuç üretir. Kirli veriyle kurulan optimizasyon, güvenilir görünen yanlış planlar üretir ve planlayıcının sisteme güvenini kalıcı olarak bitirir.

Nakliye otomasyonunun sonu, seferin başlaması değil kapanmasıdır. Teslim kanıtının (imza, fotoğraf, teslim alan kişi bilgisi) sahadan yapılandırılmış biçimde dönmesi, hem müşteri bildirimini hem faturalamayı hem de gecikme analizini besleyen tek kaynaktır. Kanıt sahadan serbest metin olarak dönüyorsa zincir orada kopar. Bu verinin resmi bildirim ve belge katmanına nasıl bağlandığını yukarıdaki U-ETDS ve e-İrsaliye bölümlerinde ayrıntılandırdım.

Otonom Takip ve Bildirim Akışı Teknik Olarak Nasıl Çalışır?

Veri tabanındaki teslimat hareketleri entegrasyon senaryosu tarafından sürekli dinlenir. Bir kargo statüsü güncellendiğinde sistem önce kaydın tekilliğini kontrol eder, sonra durumu müşteriye iletir ve aynı olayı operasyon paneline yazar. Bu akışın kağıt üzerinde basit görünen kısmı ile üretimde ayakta kalan kısmı arasındaki fark, üç mekanizmadadır: tekilleştirme, hata rotası ve kanıt kaydı.

1. Olay yakalama: Taşıyıcı web kancası, ERP tetikleyicisi veya zamanlanmış sorgu ile durum değişikliği alınır.
2. Tekilleştirme: Sevkiyat kimliği ve durum kodu birlikte anahtar yapılır; aynı olay ikinci kez geldiğinde akış sessizce durur, müşteriye ikinci mesaj gitmez.
3. Zenginleştirme: Kayda alıcı dili, teslim noktası ve tahmini varış bilgisi eklenir.
4. Yükümlülük kontrolü: Bu sevkiyat için U-ETDS bildirimi ve e-İrsaliye durumu sorgulanır; eksikse iletişim adımı değil, istisna kuyruğu tetiklenir.
5. İletişim: Onaylı şablon üzerinden müşteri bilgilendirilir; iç ekibe yalnız eşik aşıldığında bildirim düşer.
6. Kanıt: Gönderim kimliği, servis yanıtı, sonuç kodu ve zaman damgası denetim tablosuna yazılır.

Dördüncü adım, çoğu lojistik otomasyon projesinde atlanan adımdır. Müşteriye "yolda" mesajı gitmiş olması, o taşımanın resmi bildiriminin yapıldığı anlamına gelmez. Doğru kurulmuş bir akışta iletişim katmanı, yükümlülük katmanı yeşil vermeden müşteriye ilerleme mesajı göndermez; aksi hâlde sistem operasyonu rahatlatırken denetim riskini büyütür. Bu tür akışların senaryo tasarımını Make.com nedir rehberinde temel seviyeden, kurumsal ölçekteki hata desenlerini ise Make.com ile güvenli kurumsal otomasyon yazısında anlatıyorum.

E-İrsaliye, ERP ve WMS Arasında Veri Sözleşmesi Nasıl Kurulur?

Sevkiyatın belge tarafında Gelir İdaresi Başkanlığı'nın e-İrsaliye uygulaması vardır. GİB'in e-İrsaliye hakkında resmi sayfası, kağıt ortamda düzenlenen sevk irsaliyesinin elektronik ortamda düzenlenmesi, iletilmesi, muhafaza ve ibraz edilmesini kapsayan uygulamayı tanımlar; sayfa ayrıca belirli sektörler ve belirli ciro eşiğini aşan e-Fatura mükellefleri için geçiş zorunluluğunu listeler. Kendi işletmenizin kapsamda olup olmadığı ve güncel eşikler her zaman bu resmi sayfadan doğrulanmalıdır; ikincil kaynaklardaki tarih ve tutarlar eskimiş olabilir.

Entegrasyon tarafında kritik olan nokta belgeyi üretmek değil, aynı sevkiyatın üç sistemde aynı kimlikle anılmasıdır. Pratikte kurduğum veri sözleşmesi şu beş alan üzerine oturur:

• Sevkiyat kimliği: ERP'de üretilen, değişmeyen tekil numara. Tüm sistemlerin ortak anahtarı budur.
• Durum sözlüğü: Taşıyıcıların farklı isimlendirdiği durumların (in transit, yolda, hareket etti) tek bir iç sözlüğe eşlenmesi.
• Zaman damgası kaynağı: Hangi zamanın esas alınacağı (taşıyıcı olay saati mi, sistem alma saati mi) baştan sabitlenir.
• Belge referansı: e-İrsaliye ve U-ETDS referanslarının sevkiyat kaydına iliştirilmesi.
• Hata sınıfı: Geçici hata (yeniden dene) ile kalıcı hata (insana taşı) ayrımı.

Bu sözleşme yazılı hâle gelmediğinde her yeni taşıyıcı entegrasyonu, önceki akışı bozan bir istisna yığını üretir. Sözleşmeyi bir tabloya yazmak, entegrasyon kodundan daha uzun ömürlüdür.

Müşteri Bildirimlerinde WhatsApp Şablonu, Onay ve Maliyet Modeli

Teslimat bildirimlerinin WhatsApp üzerinden gönderilmesi, ulaşılabilirlik açısından e-postadan güçlüdür; ancak kendi kuralları vardır. Meta'nın WhatsApp Cloud API dokümantasyonu, müşteri hizmetleri penceresi dışında yalnız önceden onaylanmış şablon mesajlarının gönderilebileceğini belirtir. Yani "kargonuz yola çıktı" bildirimi serbest metin değil, önceden onaylatılmış bir şablondur ve şablonun kategorisi maliyeti belirler.

Fiyatlandırma tarafında Meta, 1 Temmuz 2025'ten itibaren konuşma başına değil mesaj başına ücretlendirmeye geçtiğini ve ücretin yalnız teslim edilen şablon mesajları için alındığını belgeliyor. Aynı kaynak, açık müşteri hizmetleri penceresi içinde gönderilen belirli hizmet amaçlı şablonların ücretlendirilmediğini de açıklıyor. Bu detay lojistikte doğrudan bütçe kalemidir: müşteri sorusuna yanıt olarak gönderilen durum bilgisi ile kendiliğinden gönderilen kampanya mesajı aynı maliyet sınıfında değildir.

Üçüncü kural izindir. WhatsApp Business mesajlaşma politikası, bir kişiye mesaj gönderebilmek için hem numarasının verilmiş olmasını hem de sonraki mesajları almak istediğini teyit eden bir onayın alınmış olmasını şart koşar. Lojistikte bu, sipariş formuna eklenen tek bir onay kutusuyla çözülür; ancak onayın ne zaman ve hangi metinle alındığı kayıt altına alınmalıdır. Onay kaydı olmayan bir bildirim akışı, teknik olarak çalışsa bile politika riski taşır.

Uçtan Uca Örnek Senaryo: Bir Sevkiyatın Dokuz Adımlık Yolculuğu

Aşağıdaki örnek, orta ölçekli bir dağıtım firmasında kurduğum akışın sadeleştirilmiş hâlidir. Vaka; yurt içi karayolu taşıması yapan, kendi ERP'si olan ve iki farklı taşıyıcıyla çalışan bir işletmedir.

1. Sipariş onayı: ERP'de sevkiyat emri oluşur ve tekil sevkiyat kimliği üretilir.
2. Belge hazırlığı: e-İrsaliye taslağı üretilir; zorunlu alanlar eksikse akış durur ve muhasebeye görev açılır.
3. Resmi bildirim: Yük bildirimi Bakanlık servisine gönderilir, dönen referans numarası sevkiyat kaydına yazılır.
4. Araç ve şoför bilgisi: Plaka ve sürücü bilgisi aynı referans üzerinden bildirime eklenir.
5. Müşteri onayı kontrolü: Alıcının bildirim izni var mı, hangi dilde iletişim kurulacak; yoksa yalnız e-posta kanalı kullanılır.
6. Yola çıkış bildirimi: Onaylı şablon ile alıcıya tek mesaj gider; aynı olay tekrar gelirse mesaj tekrarlanmaz.
7. Gecikme izleme: Tahmini varış saati aşıldığında müşteriye değil önce operasyona uyarı düşer; müşteri mesajı ancak yeni tahmin netleştiğinde gönderilir.
8. Teslim kanıtı: Teslim bilgisi ve varsa imza/fotoğraf kaydı sevkiyat kaydına iliştirilir.
9. Kapanış ve denetim: Bildirim referansı, belge numarası, mesaj kimlikleri ve süreler tek satırda denetim tablosuna yazılır.

Bu senaryoda dikkat çeken tasarım kararı yedinci adımdadır. Gecikmede ilk mesajın müşteriye değil operasyona gitmesi, otomasyonun müşteriye "gecikti" deyip sonra "yok aslında gelmiş" demesini engeller. Otomasyon güveni hızla değil tutarlılıkla kazanır.

Zaman Tasarrufu ve Performans Metrikleri: Hangi Veri Nasıl Ölçülür?

Lojistik otomasyonunda en sık gördüğüm ölçüm hatası, kazancın "tahmini kazanılan saat" olarak sunulmasıdır. Bu sayı denetlenemez. Ölçülebilir olan; sistemin ürettiği kayıtların kendisidir. Aşağıdaki tablo, projeye başlamadan önce ve sonra aynı yöntemle toplanması gereken veri kalemlerini gösterir; sayı üretmez, ölçüm yöntemini sabitler.

Bu tablonun kıymeti, projenin ikinci ayında "işe yaradı mı" sorusuna hafızayla değil raporla cevap verebilmektir. Ölçüm altyapısı akışla birlikte kurulmazsa, sonradan geriye dönük veri üretilemez.

Lojistik Otomasyonunda En Sık Görülen Hata Desenleri ve Riskler

Aşağıdaki hataların hepsini sahada gördüm; hiçbiri egzotik değil, hepsi tasarım aşamasında ucuza kapatılabilecek risklerdir.

• Tekilleştirme yokluğu: Taşıyıcı aynı olayı iki kez gönderdiğinde müşteriye iki mesaj gider. Sevkiyat kimliği ve durum kodundan üretilen anahtar bu riski kapatır.
• Referans numarasının saklanmaması: Resmi bildirim yapılır ama dönen referans kaydedilmez; iptal veya güncelleme gerektiğinde kayıt bulunamaz.
• Sonuç kodunun okunmaması: İsteğin gönderilmiş olması başarı sayılır. Oysa kanıt, servisin döndürdüğü başarı kodudur.
• Sabit IP varsayımı: Bulut tabanlı otomasyon aracının çıkış IP'si değişkendir; IP tanımı gerektiren servislerde akış aniden durur.
• Şablon onayının ertelenmesi: Mesaj şablonu önceden onaylatılmadığı için canlıya geçiş günü bildirimler gönderilemez.
• İzin kaydının tutulmaması: Bildirim izninin ne zaman alındığı kaydedilmez; şikâyet hâlinde kanıt yoktur.
• Hata rotasının olmaması: Geçici ağ hatası ile kalıcı veri hatası aynı kovaya düşer; akış ya sonsuz döner ya sessizce ölür.
• Tek kişiye bağımlılık: Senaryoyu kuran kişinin hesabına bağlı bağlantılar, o kişi ayrıldığında tüm akışı düşürür.

Bu listedeki maddelerin ortak paydası şudur: hiçbiri "yapay zekâ" ile ilgili değildir. Lojistik otomasyonunda başarısızlığın kaynağı neredeyse hiçbir zaman model kalitesi değil, veri sözleşmesinin ve hata davranışının tasarlanmamış olmasıdır.

KVKK, Yurt Dışına Aktarım ve Taşıma Verisinde Veri Minimizasyonu

Taşıma verisi masum görünür; oysa alıcı adı, telefon numarası, adres ve teslim fotoğrafı kişisel veridir. Bulut tabanlı bir otomasyon aracı kullanıldığında bu verinin bir kısmı yurt dışındaki sunucularda işlenebilir. Kişisel Verileri Koruma Kurumu'nun yurt dışına aktarım sayfası, yeterlilik kararı bulunmayan hâllerde standart sözleşme, bağlayıcı şirket kuralları, taahhütname gibi uygun güvencelerin ve istisnai hâllerin çerçevesini açıklar.

Pratikte uyguladığım kurallar şunlardır: senaryoya yalnız akışın ihtiyaç duyduğu alanları almak (teslim bildirimi için alıcının doğum tarihine gerek yoktur), telefon numarasını yalnız iletişim adımında çözümlemek, çalışma geçmişinde hassas alanların görünürlüğünü kısıtlamak ve hata loglarını da kişisel veri envanterine dahil etmek. Loglar, envantere yazılmadığında görünmez bir veri deposuna dönüşür. Kişisel veri işleyen her akış canlıya alınmadan önce hukuk ve bilgi güvenliği sorumlusuyla birlikte değerlendirilmelidir.

30 Günlük Pilot: Nereden Başlamalı?

Tüm süreci tek seferde taşımak yerine, geri alınabilir ve ölçülebilir bir pilotla başlamak doğru yaklaşımdır. Aşağıdaki plan, tek bir hat veya tek bir taşıyıcı için uygulanır.

1. 1-5. gün: Mevcut süreç haritası, durum sözlüğü ve veri sözleşmesi yazılır; ölçüm tablosunun "öncesi" verisi toplanır.
2. 6-12. gün: ERP'den olay okuma ve tekilleştirme kurulur; hiçbir müşteri mesajı gönderilmez, yalnız iç kayıt üretilir.
3. 13-18. gün: Resmi bildirim entegrasyonu test ortamında örnek verilerle sınanır; sonuç kodu ve referans saklama doğrulanır.
4. 19-24. gün: Mesaj şablonları onaya gönderilir, izin kaydı akışa eklenir, iç ekip bildirimi devreye alınır.
5. 25-30. gün: Sınırlı hacimle müşteri bildirimi açılır; ölçüm tablosunun "sonrası" verisi toplanır ve karar raporu yazılır.

Pilotun çıktısı bir demo değil, karar belgesidir: hangi metrik iyileşti, hangi istisna insana taştı, hangi adım hâlâ manuel kalmalı. Aynı disiplini farklı sektörlerde nasıl uyguladığımı yapay zekâ ve iş akışı otomasyonu sayfasında, e-ticaret tarafındaki sipariş ve stok akışlarını ise e-ticaret entegrasyonu sayfasında bulabilirsiniz.

Kaynaklar ve Teknik Referanslar

• T.C. Ulaştırma ve Altyapı Bakanlığı — U-ETDS portalı ve kurum entegrasyonu teknik tasarım dokümanı (Sürüm 1.7, Kasım 2019).
• Gelir İdaresi Başkanlığı — e-İrsaliye uygulaması hakkında resmi bilgilendirme sayfası.
• Meta — WhatsApp Cloud API dokümantasyonu, mesaj başına fiyatlandırma sayfası ve WhatsApp Business mesajlaşma politikası.
• Kişisel Verileri Koruma Kurumu — kişisel verilerin yurt dışına aktarılması hakkında bilgilendirme.