TMS RFP Nasıl Yazılır: Deneyimlerimiz [+ 5 Ücretsiz Şablon]

Her hafta taşımacılık yönetim sistemi RFP'lerine (teklif talebi) yanıt veriyoruz. Bir kısmı üzerinde çalışmak gerçek bir zevk. Bir kısmı ise yapılmaması gerekenlerin ders kitabı gibi.

Bu makale, bugün sıfırdan bir TMS seçim süreci yürütsem nasıl kurardım sorusunun yanıtı. Yanıtladığımız RFP'lere, şirketler ve sektörler arasında tekrar eden kalıplara, çoğunun neleri kapsadığına ve sıkça karşılaştığımız hatalara dayanıyor.

Tedarik uzmanıysanız büyük bölümü zaten tanıdık gelecektir. Umarım en azından bir gereksiz açıklama turunu atlamanıza yardımcı olur.

TMS RFP nedir?

TMS RFP (teklif talebi), taşımacılık yönetim sistemi sağlayıcılarına gönderdiğiniz yapılandırılmış bir belgedir. Lojistik operasyonunuzu tanımlar ve her sağlayıcıdan sisteminin bu operasyonu aynı gereksinimler çerçevesinde nasıl karşılayacağını açıklamasını ister. Temel amaç karşılaştırılabilirliktir: aynı sorular, aynı format, aynı bağlam; böylece gelen yanıtlar beş ayrı satış sunumu olarak değil, yan yana sıralanabilir belgeler olarak okunabilir.

Her zaman buna ihtiyaç duymazsınız. RFP, karar karmaşık olduğunda ya da şirket içinde gerekçelendirilmesi gerektiğinde değerini gösterir. Lojistik operasyonlarınız basitse, birkaç ürün demosu ve taşıyıcılarla yapılan görüşmeler çoğu zaman yeterlidir.

Gerçekten bir TMS RFP ihalesi yürütmeniz gerekiyor mu?

Bunu yanlış değerlendirmek, tüm TMS seçim sürecindeki en maliyetli hatadır. Her şeyden önce bu soruyu yanıtlayın.

Belirleyici olan şirketinizin büyüklüğü değil, lojistiğinizin karmaşıklığıdır.

Yapılandırılmış bir TMS RFP ihalesi yürütün: birden fazla tesisten sevkiyat yapıyorsanız, birden fazla taşıma modu kullanıyorsanız ve sistemin ERP'nize entegre olması gerekiyorsa. Bu durumda her sağlayıcıyı yan yana görmeniz şarttır; aksi takdirde önemli bir ayrıntı gözden kaçabilir. Taşıyıcılar, taşıyıcılara bağlanma biçimleri açısından birbirinden çok farklıdır. Biri buna "yerel entegrasyon" derken diğeri sessiz sedasız işi başka bir tarafa yönlendirir. Gevşek bir süreçte bunu ancak sözleşmeyi imzaladıktan sonra fark edersiniz; o noktada iş işten geçmiştir.

Resmi RFP ihalesini atlayın: tek bir tesisi yönetiyorsanız, birkaç taşıyıcıyla çalışıyorsanız ve ne istediğinizi zaten biliyorsanız. Neden mi? Çünkü bir RFP başlattığınız anda kendinizi kurumsal fiyatlandırma segmentine yerleştirmiş olursunuz. Yerinde sorularla yapılan 2-3 iyi demo çoğu zaman daha iyi bir sistemi daha ucuza ve daha hızlı kazandırır. O 2-3 sağlayıcıya ne gönderdiğinizi ve neyi çözmeye çalıştığınızı anlatın, ardından canlı sistemlerinde göstermelerini isteyin. Bir saat içinde yanıtınızı alırsınız. Palet veya kargo yerine ağırlıklı olarak koli gönderiyorsanız tam kapsamlı bir TMS'e hiç ihtiyaç duymayabilirsiniz; çoklu taşıyıcı gönderim yazılımı bunun için tasarlanmış farklı ve daha hafif bir kategoridir.

Bu nedenle başlamadan önce hangisine gerçekten ihtiyaç duyduğunuzu dürüstçe değerlendirin. İhtiyaç duymadığınız bir RFP yürütmek, TMS satın almanın en yavaş ve en pahalı yoludur.

İhtiyaç duymadığınız bir RFP yürütmek, TMS satın almanın en yavaş ve en pahalı yoludur.

Tam RFP yolunu seçerseniz bir uyarı daha. Yönetişim diliyle, metodoloji çerçeveleriyle ve sabit fiyat talepleriyle dolu bir sürece yanıt vermek haftalar alır; bu yükü kaldırabilecek sağlayıcılar genellikle büyük ve köklü olanlardır. Dolayısıyla daha yalın ve modern bir platform aslında size daha iyi hizmet edecek olsa bile, aşırı bürokratik bir süreç onları bir demo bile göstermeden elemiş olabilir.

Amaç size uygun çözümü bulmaktır. Süreci buna göre tasarlayın, sürecin kendisini yönetmek için değil.

TMS RFP süreci: 9 adım

TMS seçimi karmaşık olmak zorunda değildir. Ancak net bir sıra gerektirir. Adımları atlarsanız bedelini sonradan ödersiniz; genellikle uygulama aşamasında, erken netleştirilmesi gereken varsayımlar pahalı sürprizlere dönüştüğünde.

İyi yönetildiğinde sürecin tamamı 8 ila 12 hafta alır. Basit bir kapsam için daha az sürer ve nadiren daha fazlasına ihtiyaç duyulur.

İşe yarayan sıra şöyledir:

1. Pazar taraması. Tek bir gereksinim yazmadan önce piyasada ne olduğunu anlamak için zaman ayırın. TMS pazarı son beş yılda önemli ölçüde değişti: iyi kurumsal platformlar, iyi orta ölçekli platformlar ve beş yıl önce var olmayan gerçek anlamda yetenekli modern SaaS taşımacılık yönetim yazılımı çözümleri mevcut. Yaklaşmaya değer 5-8 TMS sağlayıcısından oluşan geniş bir liste oluşturun.
2. Gizlilik sözleşmesi (NDA). Erken gönderin. Hacimler, taşıyıcı adları ve dahili sistem ayrıntıları gibi operasyonel veriler paylaşacaksınız; RFP gönderilmeden önce imzalanmış bir NDA her iki tarafı da koruyan standart bir uygulamadır.
3. RFI (isteğe bağlı). Geniş listeniz varsa ve tam RFP sürecine yatırım yapmadan önce eleme yapmak istiyorsanız kısa bir Bilgi Talebi (RFI) mantıklıdır. Tek sayfada tutun: şirket arka planı, temel yetenekler, kabaca fiyat aralığı. Sağlayıcıların uzun yazılar yazmasını istemeden kısa listeye almaya yetecek kadar bilgi.
4. RFP. Temel belge. Her sağlayıcıya doğru bir teklif hazırlamak için ihtiyaç duydukları bilgileri verir. Bir sonraki bölümde daha ayrıntılı ele alıyoruz.
5. Soru-cevap penceresi. Her zaman dahil edin. Sağlayıcıların soruları olacaktır ve bu sorulara verilen yanıtlar çoğu zaman aldığınız her teklifi iyileştirir. Yazılı olarak yürütün, tüm soru ve yanıtları tüm sağlayıcılarla eş zamanlı paylaşın. Süreci temiz ve karşılaştırılabilir tutar.
6. Kısa liste ve sunumlar. Yazılı teklifleri puanlayın, ardından 2-3 sağlayıcıyı sunum yapmaya davet edin. Sunum, genel bir demo değil, gerçek kullanım senaryolarınıza dayalı canlı sistem gösterimi içermelidir. Bir sağlayıcı senaryonuzu kendi sisteminde gösteremiyorsa bu da size önemli bir bilgi verir.
7. İkinci tur (gerekirse). Karmaşık bir karar için güvenlik, entegrasyon ve ticari koşullar gibi belirli boşluklara odaklanan daha derin bir oturum zamanınıza değer. Gerçek açık sorularınız yoksa planlamayın.
8. Karar ve sözleşme. Müzakereye başlamadan önce şirket içinde mutabık kalın. Vazgeçilmezlerinizi, kabul edilebilir uzlaşılarınızı ve geri çekilme noktalarınızı bilin.
9. Başlangıç (onboarding). İş imzayla bitmez. En iyi RFP sonuçlarında başlangıç planı sözleşme imzalanmadan önce kararlaştırılmıştır.

Kopyalayabileceğiniz TMS RFP zaman çizelgesi

Kapsama göre tahmini süre:

• Tek ve basit tesis: 6-8 hafta (tam kapsamlı RFP gerekmeyebilir).
• Birden fazla tesis + ERP entegrasyonu: 8-12 hafta.
• Küresel, çok birimli, karmaşık entegrasyon: muhtemelen iki sunum turuyla birlikte 12-20 hafta.

RFP zaman çizelgesi şablonunu indirin (.docx)

TMS RFP belgenize neler dahil edilmeli

RFP belgesi bu süreçteki en önemli araçtır. İyi hazırlanmış bir RFP belgesi değerlendirme işinin büyük bölümünü sizin yerinize yapar; bu nedenle odaklı tutun. Her şeyi kapsamaya çalışan 30 sayfalık bir RFP'den sıkı hazırlanmış 10 sayfalık biri çok daha etkilidir.

1. Ön yazı ve amaç

Tek sayfa. Kim olduğunuz, ne aradığınız, neden şimdi. Olgusal tutun. Sağlayıcıların vizyon bildirgesine değil, operasyonel sorununuzu anlamaya ihtiyacı vardır.

2. Zaman çizelgesi

Gerçek tarihlerle net bir takvim: RFP yayım tarihi, soru-cevap son tarihi, teslim, sunum penceresi, karar. Sağlayıcılar yanıt çabalarını buna göre planlar. Belirsiz zaman çizelgeleri belirsiz teklifler getirir.

3. Şirket ve operasyonel arka plan

Çoğu RFP'nin yetersiz kaldığı yer burasıdır ve karşılaştırılabilir teklifler ile açıklama turu arasındaki farkı yaratan da budur. Yalnızca işinizi değil, lojistik operasyonunuzu tanımlayın. Kaç tesis. Kaç tüzel kişilik. Hangi taşıma modları (koli, LTL, FTL, hava, deniz, demiryolu). Hangi bölgeler. Yaklaşık hacimler. Mevcut sistemler. "İyi"nin ne anlama geldiği sektöre göre de değişir; elektronik, makine, kimya veya baskı ve ambalaj üreticilerinin gereksinimleri birbirinden farklıdır. Sağlayıcıların tekliflerini doğru biçimde kapsamlandırabilmesi için bu bağlama ihtiyaçları vardır. Burada yeterli ayrıntı vermezseniz, baştan yanıtlanabilecek açıklama sorularını yanıtlamak için iki hafta harcarsınız. Bu konuya ayrı bir bölüm ayırdık.

4. İşlevsel gereksinimler

Önem derecesine göre önceliklendirilmiş, sistemin ne yapması gerektiğini gösteren bir tablo: zorunlu / olması gereken / olsa iyi olur (Excel uygundur). Sağlayıcılardan her gereksinim için kapsam düzeyini belirtmelerini isteyin: a) yerel, b) üçüncü taraf, c) özelleştirme veya d) desteklenmiyor. Teklifleri karşılaştırılabilir kılan budur. Listenin nasıl oluşturulacağına dair daha fazla bilgi ileride yer alıyor.

5. Değerlendirme kriterleri

Sağlayıcılara kararı nasıl vereceğinizi söyleyin: işlevsellik, fiyat, uygulama yaklaşımı, referanslar, güvenlik, ekip. İsterlerse ağırlıklandırmayı da paylaşın. Ne kadar şeffaf olursanız teklifler o kadar iyi olur.

6. Fiyatlandırma modeli

Tam bir döküm isteyin: abonelik, uygulama, işlem ücretleri, destek ve diğer her şey. Mümkünse örnek bir fatura isteyin. Fiyatlandırma yapıları sağlayıcılar arasında büyük farklılıklar gösterir ve gizli maliyetler geç ortaya çıkma eğilimindedir. Bunları erkenden öğrenmeye çalışın.

7. Yanıt formatı

Sağlayıcılara teklifin tam olarak nasıl yapılandırılmasını istediğinizi söyleyin; şablon sağlıyorsanız kullanımını zorunlu kılın. Karşılaştırılabilir teklifler değerlendirme sırasında günler kazandırır ve format tamamen sizin kontrolünüzdedir.

Yukarıdaki tam yapıdan başlamak için RFP belge şablonunu indirin:

RFP belge şablonunu indirin (.docx)

Çoğu TMS RFP'sinin atladığı operasyonel bilgiler ve bunların neden en önemli unsur olduğu

Her TMS RFP yazarının önce okumasını isteyeceğim bölüm bu.

Pek çok TMS ihalesine yanıt veriyoruz. Yazdığımız neredeyse her teklifin bir açıklama turuna ihtiyacı oluyor; bunun nedeni gereksinimlerin belirsiz olması değil, neredeyse hiçbir zaman. Sorun operasyonel bağlamın eksik olması: hacimler, tesis yapısı, taşıyıcı portföyü, mevcut sistemler.

Tam açıklama turu gerektiren RFP'lerin neredeyse tamamında ortak bir nokta var:

Şirketlerin değerlendirme kriterleri ve gereksinim listeleri hazırlamak için haftalar harcadığını, ardından ayda kaç sevkiyat işlediklerini bile belirtmeyen bir RFP gönderdiklerini görüyoruz.

Bu bilgi olmadan sağlayıcılar tahmin yürütür. Tahmin yürütüldüğünde teklifler genel kalır, fiyatlar kesinleşmez ve karşılaştırılacak somut bir şey kalmaz.

Örneğin, 10 deposu olan ve SAP kullanan küresel bir üretici, lojistiğini elektronik tablolarla yöneten tek tesisli bir distribütörden tamamen farklı bir teklif gerektirir. Sağlayıcı hangisi olduğunuzu anlayamazsa belirsiz kalır ve hiçbir şeye taahhüt etmeyen teklifler alırsınız.

Çözüm bir öğleden sonra alır. RFP gönderilmeden önce şu on soruyu yanıtlayın.

1. Organizasyon ve kapsam. Kapsama kaç tüzel kişilik ve tesis dahil? Yaygınlaştırma paralel mi yoksa aşamalı mı? Tesisler ne ölçüde bağımsız çalışıyor; ayrı taşıyıcı sözleşmeleri, ayrı ekipler?
2. Sevkiyat hacimleri. Tesis başına aylık ve günlük sevkiyat sayıları, ortalama ve zirve değerleri. Mevsimsellik varsa belirtin. Gelen ve giden sevkiyat oranı.
3. Taşıma modu dağılımı. Koli, LTL, FTL, hava, deniz payları nedir? Hangi modlar büyüyor? Operasyonel açıdan en kritik olanlar hangileri?
4. Taşıyıcı portföyü. Tesis ve mod başına kaç taşıyıcı? Tesisler arasında ortak mı yoksa yerel olarak mı yönetiliyor? Önceliklendirilmesi gereken stratejik taşıyıcılar veya değiştiremeyeceğiniz müşteri tarafından belirlenen taşıyıcılar var mı?
5. Coğrafya ve ticaret güzergahları. Kapsama hangi bölgeler dahil? En önemli güzergahlar hangileri: yurt içi, sınır ötesi, kıtalararası? Kilit limanlar veya lojistik merkezler?
6. Mevcut durum. Sevkiyatlar bugün nasıl planlanıyor, sipariş veriliyor ve takip ediliyor? ERP'de mi, elektronik tablolarda mı, taşıyıcı portallarında mı, e-postayla mı? Mevcut süreçteki başlıca sorunlar neler?
7. Finansal yapı. Taşıma bedelini kim ödüyor; tek bir tüzel kişilik mi yoksa birden fazla mı? Üçüncü taraf veya müşteri hesap numaraları var mı? Navlun maliyeti bugün nasıl kaydediliyor ve doğrulanıyor?
8. İş modeli. B2B mi, B2C mi? İkisi de varsa oranı nedir? Operasyonel ve sistem gereksinimleri oldukça farklılaşır.
9. Entegrasyon ortamı. TMS'e hangi sistemlerin bağlanması gerekiyor: ERP, WMS, CRM? Sürdürülmesi gereken mevcut taşıyıcı entegrasyonları var mı? Başlangıçtan itibaren ne ölçüde otomasyona ihtiyaç var?
10. Zaman çizelgesi ve kısıtlar. Hedeflenen bir canlıya geçiş tarihi var mı? Takvimi etkileyen mali yıl sonu, yoğun sezon, sistem göçleri gibi şirket içi kilometre taşları?

Bunları yazmak zor değil. Ama geri dönen teklifleri tamamen değiştiriyor.

Bu on soruyu doğrudan RFP'nize ekleyebileceğiniz doldurulabilir bir tabloya dönüştürmek için operasyonel bilgi kontrol listesini indirin:

Operasyonel bilgi kontrol listesini indirin (.docx)

TMS işlevsel gereksinimleri nasıl yazılır

İşlevsel gereksinimler RFP'nin özüdür. Doğru yaparsanız her sağlayıcının neler yapıp yapamadığına dair net ve karşılaştırılabilir bir tablo elde edersiniz. Yanlış yaparsanız hepsinin "evet" dediği yanıtları çözümlemeye haftalar harcayabilirsiniz.

Amaç en uzun listeyi değil, en dürüst olanı oluşturmaktır.

Acımasızca önceliklendirin: zorunlu, olması gereken, olsa iyi olur

İstediğiniz her şey eşit derecede önemli değildir. Üç kategori kullanın ve buna sadık kalın:

1. Zorunlu (Z): pazarlık konusu değil. Bunu karşılayamayan bir sağlayıcı, başka ne getirirse getirsin elenmiştir.
2. Olması gereken (O): önemli, ancak geçici bir çözüm veya yakın vadeli bir yol haritası taahhüdüyle idare edilebilir.
3. Olsa iyi olur (İ): bilinmesi güzel, ancak yukarıdakilerin gerisinde kalır.

Çoğu listede zorunlu gereksinim sayısı çok fazladır. Her şey kritikse hiçbir şey kritik değildir. Sistemi gerçekten işlevsiz kılacak olanları dürüstçe belirleyin ve yalnızca onları zorunlu olarak işaretleyin.

Sağlayıcılardan işlevsellik kapsamını sınıflandırmalarını isteyin: yerel / üçüncü taraf / özelleştirme

Her gereksinim için şu seçeneklerden biriyle yanıt vermelerini isteyin:

Tekliflerin güven kazanıp kaybettiği sütun burasıdır. Gerçekten desteklemediği yerde desteklenmiyor yazan bir sağlayıcı, iş ortağı olarak nasıl davranacağını gösteriyor demektir. Her şeye yerel yanıtı veren bir sağlayıcı da size önemli bir şey söylüyor.

Soruyu somut tutun

"Sistem taşıyıcı fiyatlandırmasını destekliyor mu?" sorusu size işe yaramaz bir "evet" getirir. "Sistem, fiyatlandırma API'si olmayan taşıyıcılar dahil tüm taşıyıcılar için navlun fiyatını hesaplayıp sevkiyat başına yan yana gösterebiliyor mu?" sorusu ise gerçekten değerlendirebileceğiniz bir yanıt sağlar.

ERP nerede biter, TMS nerede başlar?

Taşımacılık yönetim sistemi değerlendirmelerinde en yaygın karışıklık kaynaklarından biri TMS'in nerede bitip ERP'nin nerede başladığıdır.

GL kodlama, iniş maliyeti ve navlun denetimi gibi finansal süreçler genellikle ERP tarafında yönetilir; TMS verileri ERP'ye besler. Bu normaldir ve çoğu zaman doğru yapılandırmadır. Ancak açıkça belirtilmesi gerekir. Bir sağlayıcı zorunlu gereksinimlerinizden birine "ERP entegrasyonu aracılığıyla yönetilir" yanıtını verdiğinde, bunun uygulamanız için tam olarak ne anlama geldiğini ve bunu kimin geliştireceğini derinlemesine sorgulayın.

Teknik çözümü değil, hedefi belirtin

Sistemin teknik olarak nasıl çalışması gerektiğini değil, neyi başarmanız gerektiğini tanımlayın. Aşırı ayrıntılı gereksinimler, iyi çözümleri yanlış nedenlerle eleyebilir. Sağlayıcılara aklınızdakinden daha iyi bir yol gösterme fırsatı bırakın, çünkü bazen gerçekten daha iyi bir yol biliyorlar.

Dürüstçe önceliklendirilmiş 30 satırlık bir liste, her şeyin kritik olduğu ve her sağlayıcının her kutuyu işaretlediği 150 satırlık bir elektronik tablodan çok daha fazlasını anlatır.

Uyarlayabileceğiniz başlangıç TMS gereksinimleri seti

İlk kez bu süreci yürütenler genellikle listeye nereden başlayacaklarını merak eder. İşte deneyimlerimizden derlediğimiz, zaten kategorize edilmiş ve kendi operasyonunuza uyarlayabileceğiniz örnek bir set. Tam liste aşağıdaki puanlama tablosunda indirilebilir; bu bölüm genel yapıyı görmek için yeterlidir.

Sağlayıcı başına öncelikler ve kapsam sütunuyla hazır işlevsel gereksinimler puanlama tablosunu indirin:

İşlevsel gereksinimler puanlama tablosunu indirin (.docx)

TMS maliyeti nasıl karşılaştırılır (ve üç yıllık model nasıl oluşturulur)

"TMS ne kadar maliyetlidir?" sorusu alıcıların en çok yanıt istediği, sağlayıcıların ise en çok kaçındığı sorudur. Ancak abonelik ücreti nadiren nihai maliyetinizdir. Orta ölçekli, çok tesisli bir işletme için uygulama ve entegrasyon, üç yıllık toplamı aylık ücretin bile önüne geçebilir; üstelik sağlayıcıların bu konuda en belirsiz kaldığı kalem de budur. Dolayısıyla buradaki beceri, soruyu yanıtların karşılaştırılabilir gelmesini ve gerçek maliyetin görünür olmasını sağlayacak biçimde yapılandırmaktır.

Kaba bir yönelim olarak, orta pazar bulut tabanlı TMS genellikle aylık birkaç yüzden birkaç bine euro arasında seyrederken, geleneksel kurumsal sistemler yılda on binlerden bir milyonun üzerine çıkabilir; uygulama maliyetleri ise altı ya da yedi haneli rakamlara ulaşabilir. Bu geniş aralık, tek bir rakamdan çok eşdeğer karşılaştırma modelinin neden önemli olduğunu açıkça ortaya koyuyor. Gerçek TMS sağlayıcılarının ne kadar talep ettiğine dair bir fikir edinmek için en iyi TMS sağlayıcıları üzerine yaptığımız araştırmaya bakabilirsiniz.

TMS fiyatlandırma bileşenleri

Neredeyse her TMS teklifi şu bileşenlerin bir karışımından oluşur:

Karşılaştırmadan önce üç yıllık maliyet modeli oluşturun

Abonelikte ucuz görünen bir TMS sağlayıcısı, uygulama, işlem başına ücretler ve taşıyıcı başlangıcı hesaba katıldığında en pahalısı çıkabilir. Her sağlayıcıyı aynı modelden geçirin:

3 yıllık maliyet = uygulama + (yıllık abonelik × 3) + (sevkiyat başına ücret × yıllık hacim × 3) + destek + beklenen taşıyıcı ve entegrasyon eklentileri.

Sağlayıcının düzenli örneğini değil, gerçek hacimlerinizi kullanın. Bu tek tablo kısa listeyi yeniden sıralamaya yeter.

Yalnızca temel ücrete değil, farklı fiyatlandırma bileşenlerine dikkat edin

Bazı sağlayıcılar aboneliği düşük tutar ve işlem ücretleri ya da taşıyıcı başına ücretlerle telafi eder. Bu otomatik olarak kötü bir şey değildir, ancak büyüdükçe kimin daha ucuz olduğunu değiştirir. Hacminiz artıyorsa sevkiyat başına model, sabit olanı hızla geçebilir. Örnek bir fatura isteyin ve abonelik koşullarını inceleyin; böylece başlık rakamını değil, gerçekten ödeyeceğinizi karşılaştırırsınız.

Her sağlayıcıya sormaya değer bir soru: yeni taşıyıcı entegrasyonları dahil mi, yoksa her seferinde ayrıca mı faturalandırılıyor? Bazı TMS platformları yeni taşıyıcı entegrasyonu başına 5.000-10.000 € talep eder ve bu aylar alır; diğerleri ise yeni taşıyıcı entegrasyonlarını ek ücret almadan gerçekleştirir. Yıllar içinde taşıyıcı ekleyen orta ölçekli bir işletme için bu tek yanıt, üç yıllık toplamı abonelik kaleminden çok daha fazla etkileyebilir.

TMS tekliflerini fiyatın ötesinde nasıl değerlendirirsiniz

Teklifler geldi. Hepsi makul görünüyor, çoğu gereksinimlerinize evet diyor ve fiyatlar benzer aralıkta. Şimdi ne yapacaksınız?

Bu noktada ekipler sessiz sedasız fiyata geri döner, çünkü diğer her şeyi karşılaştırmak daha zor hissettiriyor. Bunu yapmayın. İşte onları gerçekten birbirinden ayıran şeyler.

1. Taşıyıcı bağlantısı.

TMS için taşıyıcı bağlantısı temeldir. Sağlayıcı taşıyıcılara gerçekte nasıl bağlanıyor; doğrudan API/EDI entegrasyonları, üçüncü taraf toplayıcılar veya hiç bağlanmıyor mu (BT yeteneklerinden bağımsız olarak e-posta + PDF siparişleri)? Henüz desteklemedikleri bir taşıyıcıya ihtiyaç duyduğunuzda ne oluyor, bu ne kadar sürüyor ve maliyeti ne?

Derin, doğrudan taşıyıcı bağlantısına sahip bir sağlayıcı, her şeyi bir ara katman üzerinden yönlendirenden tamamen farklıdır. Bu farkı sipariş güvenilirliğinde, takip kalitesinde ve her yeni taşıyıcı eklemek istediğinizde yeni bir ticari müzakere açmak zorunda kalıp kalmadığınızda hissedersiniz.

2. Taşıyıcı hizmet düzeyi uyumlaştırması — bu, çoğu kişinin fark ettiğinden daha önemlidir.

Taşıyıcılar dijital yetenekler açısından eşit değildir. Bazıları gerçek zamanlı fiyatlandırma, ETA tahmini, adres doğrulama, etiket oluşturma ve ayrıntılı takip olaylarını kapsayan gelişmiş API'lere sahiptir. Diğerleri e-postayla sipariş onayı gönderir ve bu kadar. Çoğu taşıyıcı ağında her iki türden de bulunur.

Bu durum, ERP veya WMS'inizi TMS'e bağladığınız anda sizin sorununuz haline gelir. Entegrasyonunuz her taşıyıcıdan sipariş onayı, takip bağlantısı, etiket ve maliyet tahmini gibi eksiksiz veri bekliyorsa, ancak bazı taşıyıcılar bunu sağlayamıyorsa istisnalar, manuel geçici çözümler ve veri boşlukları ortaya çıkar. Tek bir zayıf taşıyıcı tüm iş akışının tutarlılığını bozar.

Farklı taşımacılık yönetim yazılımı sağlayıcılarının bununla başa çıkma biçimleri ikiye ayrılır; tek bir teklif okumadan önce hangisini istediğinize karar vermeniz faydalı olur:

• Daha ince bir TMS, her taşıyıcının sağladığını olduğu gibi aktarır; boşluklarla başa çıkmak ERP'nizde veya manuel çalışmada size kalır. Daha basit entegrasyon, ancak sizin tarafınızda daha fazla istisna.
• Verileri normalleştiren ve boşlukları kendisi dolduran bir TMS: fiyatlandırma API'si olmadığında yüklediğiniz navlun fiyat listesinden navlun maliyetini hesaplar; taşıyıcı tarafından ETA sağlanmadığında teslimat süresini tahmin eder; taşıyıcı üretemediğinde sevkiyat etiketleri oluşturur; takip yoksa taşıyıcılarınızın takip kilometre taşlarını manuel olarak girmesine olanak tanır ve daha fazlası. Yazılım, taşıyıcılarınızın teknik yeteneklerindeki boşlukları doldurur ve ERP'niz tek tutarlı bir yapı görür.

Teklifleri değerlendirirken sağlayıcılara doğrudan sorun: dijital yetenekleri sınırlı taşıyıcıları nasıl yönetiyorsunuz? Bu yanıt, platformlarının gerçekte ne kadar olgun olduğunu size çok şey anlatır.

3. Entegrasyon dürüstlüğü.

Sağlayıcıların entegrasyon kapsamını (kimin ne yapacağını) nasıl tanımladığına yakından dikkat edin. "ERP tarafındaki geliştirme size aittir, biz şunları sağlıyoruz ve bu şekilde destekliyoruz" diyen bir teklif, hangi tarafın hangi entegrasyonu üstlendiğini açıklamadan "sorunsuz entegrasyon" ima edenden çok daha güvenilirdir. Entegrasyon sürprizleri, TMS projelerinin zaman ve bütçeyi aşmasının en yaygın nedenlerinden biridir.

4. Uygulama yaklaşımı.

Önce manuel operasyonel doğrulama, sonra otomasyon şeklinde aşamalı bir yaklaşım, genellikle tek seferlik büyük bir başlangıçtan daha az risklidir. Tüm operasyonunuzu sisteme yaslamadan önce gerçek iş akışlarınız için çalıştığını doğrulama fırsatı bulursunuz. Bizim tarafımızdan bakıldığında, bunu kendiliğinden öneren sağlayıcılar genellikle daha önce karmaşık bir canlıya geçiş yaşamıştır. Başından itibaren tam otomasyon vadedenlerin ise çoğu zaman böyle bir deneyimi yoktur.

5. Referanslar

Yalnızca benzer büyüklükte veya çalışan sayısında değil, benzer operasyonlara sahip şirketlerden referans isteyin. Çok tesisli bir üretim operasyonu yürütüyorsanız ve SAP entegrasyonunuz varsa, tek tesisli bir distribütörden alınan referans pek işe yaramaz. Şu soruları doğrudan sorun: "Taşıyıcı başlangıcı nasıl geçti?" "Entegrasyon süreci nasıldı?" "Beklediğiniz gibi çalışmadığında ne oldu?"

6. Teklifin kendisi.

Bir TMS sağlayıcısının RFP'nize nasıl yanıt verdiği, iş ortağı olarak nasıl davranacağının habercisidir. Sorularınızı doğrudan yanıtladılar mı, yoksa her şeyi çekincelerle mi sardılar? Boşlukları dürüstçe belirttiler mi, yoksa her gereksinim için tam kapsam mı iddia ettiler? Operasyonunuzu anladıklarını gösterdiler mi, yoksa standart sunumlarının hafifçe değiştirilmiş bir versiyonunu mu gönderdiler?

İki yerde desteklenmiyor yazıp nedenini açıklayan bir teklif, her şeye evet diyen birinden çok daha değerlidir. Gerçeği her iki durumda da öğrenirsiniz; değerlendirme sırasında öğrenmek, canlıya geçişte öğrenmekten iyidir.

Sağlayıcıları ağırlıklı kriterlere göre puanlamak için taşıyıcı değerlendirme matrisini indirin:

Taşıyıcı değerlendirme matrisini indirin (.docx)

TMS sağlayıcı sunum turu

Yazılı teklifler size bir sağlayıcının ne iddia ettiğini söyler. Sunumlar ise bunu gerçekten yapıp yapamadıklarını ortaya koyar.

Bu aşamada 2-3 sağlayıcıdan oluşan bir kısa listeniz olmalı. Sunum turunun amacı teklifi gerçek baskı altına almak ve sistemin gerçek senaryolarınızda işleyip işlemediğini görmektir.

Demo değil, canlı gösterim isteyin

Demo, sistemi en iyi haliyle gösteren önceden hazırlanmış bir sıradır. Canlı gösterim ise sizin "Hollanda depomuzdaki bu sevkiyatı, bizim taşıyıcımızla, anlaşmalı fiyatımızla nasıl yönetirdiniz, gösterin" demeniz ve gerçekte ne olduğunu izlemenizdir.

Toplantıdan önce kendi operasyonunuzdan 2-3 gerçek senaryo hazırlayın: standart bir giden sevkiyat siparişi, spot teklif gerektiren bir sevkiyat ve gecikmiş bir sevkiyat ya da takip sağlamayan bir taşıyıcı gibi alışılmadık bir durum. Bir sağlayıcı senaryonuzu çalıştırmak yerine sürekli hazır demoya geri dönmeye çalışıyorsa bu başlı başına bir yanıttır.

Boşlukları sorgulayın

Her TMS teklifinde boşluklar vardır. Sağlayıcının kısmen yanıtladığı veya şüphe duyduğunuz noktalara doğrudan gidin ve orada kalın. Güzel çalışan bir şeye geri kaymalarına izin vermeyin. Bu tam olarak nasıl işliyor? Kim ne yapıyor? Beklediği gibi çalışmadığında ne oluyor?

Doğru kişileri toplantıya alın

TMS sağlayıcısı tarafında sunum yapanlar, uygulamanız üzerinde gerçekten çalışacak kişiler olmalı; yalnızca satış ekibi değil. Bunu açıkça isteyin. Kendi tarafınızda, entegrasyon kapsam dahilindeyse BT'den birini ve sistemi her gün gerçekten kullanacak en az bir kişiyi getirin. Onlar satın alma ekibinden farklı sorular sorar ve her iki soru setinin de sorulmasını istersiniz.

İkinci tur, yalnızca gerekirse

Karmaşık bir karar için belirli konulara odaklanan ikinci bir oturum zamanınıza değer. Ele alınabilecek örnek konular:

• Güvenlik ve veri koruma — BT veya bilgi güvenliği ekibiniz gerektiriyorsa sızma testi raporu veya güvenlik belgesi isteyin
• Entegrasyon mimarisi — BT ekibiniz ile sağlayıcının ekibi arasında teknik bir oturum
• Ticari koşullar — resmi müzakereye girmeden önce sözleşmeyi, iş kapsamı belgesini ve varsayımları satır satır inceleyin

Yalnızca daha fazla kişiyle ilk toplantıyı tekrarlamak için planlamayın. Ya belirli açık soruları çözüyor ya da gerçekleşmemeli.

Taahhütleri yazılı olarak teyit edin

Toplantıda sağlayıcının taahhüt ettiği ancak yazılı teklifte yer almayan her şeyin ilerlemeden önce yazılı olarak teyit edilmesi gerekir. Sözlü taahhütler sözleşme müzakerelerini atlatamaz. Bir TMS sağlayıcısı önemli bir konuda "evet, bunu yapabiliriz" diyorsa aynı gün e-postayla takip edin ve teyit etmelerini isteyin.

TMS sözleşmesi ve iş kapsamı belgesi (SOW): imzalamadan önce kontrol edilmesi gerekenler

Sağlayıcınızı seçtiniz. Çoğu ekip bu noktada "nefes alır." Ben almanızı önermiyorum; çünkü değerlendirme sırasında göz ardı edilen ayrıntılar tam burada sessiz sedasız sizin sorununuza dönüşür.

Müzakereye başlamadan önce şirket içinde mutabık kalın

Konuşma başlamadan önce vazgeçilmezlerinizi, kabul edilebilir uzlaşılarınızı ve geri çekilme noktalarınızı bilin. Müzakere ortasında gereksinimleri değiştirmek zaman kaybettirir, güveni zedeler ve zaman zaman gerçekten istediğiniz TMS sağlayıcısını kaybetmenize yol açar. Önce şirket içinde halledin, sonra müzakere edin.

Ne satın aldığınızı anlayın: lisans değil, SaaS

Modern TMS platformları yazılım lisansı değil, SaaS aboneliğidir. Bir sistemi doğrudan satın almıyor, sağlayıcının barındırdığı, bakımını yaptığı ve güncellediği bir hizmete abone oluyorsunuz. Bu, sözleşmenin kapsaması gerekenleri değiştirir: abonelik koşulları, fesih, veri sahipliği ve dışa aktarma hakları, çalışma süresi taahhütleri, destek yanıt süreleri. Standart tedarik şablonları bu model için yazılmamıştır; sizinkinin güncel olduğundan emin olun.

İş kapsamı belgesi (SOW) sözleşme kadar önemlidir

İş kapsamı belgesi, neyin, kim tarafından ve ne zaman teslim edileceğini açıklar: hesap yapılandırması, taşıyıcı başlangıcı, entegrasyon desteği, eğitim ve uygulamanın gerçekten tamamlandığını gösteren kabul kriterleri. SOW'da yer almayan şey dahil değildir; bir toplantıda veya e-postada ne söylenmiş olursa olsun. Özellikle varsayımlar bölümünü dikkatlice okuyun. Kapsam orada koşullu olarak tanımlanır. Taşıyıcı listeniz belirtilenden büyük çıkarsa veya ERP'niz standart dışı bir entegrasyon formatı gerektiriyorsa, varsayımlar bölümü bunun kısa bir görüşme mi yoksa fiyatlandırılmış bir değişiklik talebi mi olduğuna karar verir.

Kapsam dışındakileri açıkça belirtin

Özel geliştirme, yerinde eğitim, veri göçü, sistemlerinizdeki entegrasyon çalışmaları, taşıyıcı tarafındaki değişiklikler. Bunlar genellikle ayrıca fiyatlandırılır. İmzalamadan önce bunları kağıda dökmek, uygulama sürtüşmesinin en yaygın ve en önlenebilir kaynağını ortadan kaldırır: her iki tarafın da farklı bir şeyin dahil olduğunu varsaydığı durumlar.

Başlangıç planını imzalamadan önce kararlaştırın

Sonra değil. Taşıyıcı önceliklendirmesi, yapılandırma zaman çizelgesi, entegrasyon kilometre taşları, canlıya geçiş kriterleri — hepsini hâlâ pazarlık gücünüz varken netleştirin. Sözleşme aşamasında size net bir başlangıç planı sunamayan bir sağlayıcı, taahhüt vermeden önce bilmek isteyeceğiniz bir şeyi söylüyor demektir.

İmzaladıktan sonra: TMS uygulaması ve başlangıç

Gerçek riskin büyük bölümü imzadan sonra yaşanır. Üç şey sonucu belirler.

1. Veri göçü

Taşıyıcı sözleşmeleri, fiyat listeleri, adres defterleri, geçmiş sevkiyatlar. Neyi taşımanız gerektiğine, neyin önce temizleneceğine ve işin kime ait olduğuna erken karar verin. Dağınık kaynak verisi, canlıya geçiş tarihinin sürekli ötelenmesinin en yaygın nedenidir. Göç ederken değil, göç etmeden önce temizleyin.

2. Taşıyıcı başlangıç sırası

İlk günden itibaren her taşıyıcıyı bağlamazsınız. Hacim ve kritikliğe göre önceliklendirin, en önemli birkaçını canlıya alıp doğrulayın, ardından genişletin. Değerlendirme sırasında sorduğunuz aşamalı yaklaşım tam olarak burada değerini kanıtlar.

3. Kullanıcı benimsemesi

Her gün sevkiyat siparişi veren kişilerin yeni sistemi kullanmak istemesi gerekir. En az birini RFP aşamasından itibaren sürece dahil edin, yoğun destek (onboarding) döneminde düzgün eğitin ve günlük iş akışının öncekinden gerçekten daha hızlı olduğundan emin olun. Ekibin kullanmadığı teknik açıdan kusursuz bir yaygınlaştırma yine de başarısız bir yaygınlaştırmadır.

10 yaygın TMS RFP hatası

En sık gördüğümüz kalıplar, hepsi bir arada:

• Operasyonel bağlam yok. En büyük hata. Sağlayıcılara hacim, tesis yapısı ve taşıyıcı portföyü bilgisi verilmemiş. Açıklama turu ve genel fiyatlandırma kaçınılmaz olur.
• Her şey zorunlu. Her gereksinim kritik olduğunda öncelik sütunu işlevsiz hale gelir ve pazarlık konusu olmayanı olsa iyi olurdan ayırt edemezsiniz.
• Belirsiz zaman çizelgesi. Tarih yoksa sağlayıcılar çabalarını tahmin edemez; teklifler de aynı şekilde belirsiz gelir.
• Nasıl yapılacağını aşırı belirtmek. Operasyonel sonuç yerine teknik uygulamayı dikte etmek, iyi çözümleri yanlış nedenlerle eler.
• ERP/TMS sınırını görmezden gelmek. TMS'in aslında ERP'nin sahip olduğu finansal süreçlere sahip olduğunu varsaymak ve bunu uygulama ortasında fark etmek.
• Fiyata sığınmak. Üç yıllık model oluşturmadan veya taşıyıcı bağlantısını ve entegrasyon dürüstlüğünü tartmadan abonelik başlık rakamına göre seçim yapmak.
• Canlı gösterim yerine demo izlemek. Sistemin gerçek senaryolarınızı test etmesini sağlamak yerine sağlayıcının hazır sırasını izlemek.
• Operasyonunuzla örtüşmeyen referanslar. Etkileyici logolara bakmak, ancak o şirketlerin lojistik operasyonları sizinkine hiç benzemiyor olabilir. Size benzeyen referanslar isteyin, ardından başlangıç ve entegrasyonun gerçekte nasıl geçtiğini sorun.
• Başlangıcı imzadan sonraya bırakmak. Pazarlık gücünüz varken müzakere ettiğiniz plan, yokken müzakere ettiklerinizden her zaman daha iyidir.
• Doğru sağlayıcı için çok ağır bir süreç. Size en iyi hizmet edecek modern platformları filtreleyebilecek bürokratik yük.

Ücretsiz TMS RFP şablonları

Yanıtladığımız RFP'lerden yola çıkarak beş şablon hazırladık; böylece boş sayfadan başlamak zorunda kalmayacaksınız:

1. RFP belge şablonu. Bu kılavuzdaki tam yapı.
2. İşlevsel gereksinimler puanlama tablosu. Sağlayıcı başına kapsam sütunuyla önceliklendirilmiş.
3. Operasyonel bilgi kontrol listesi. On soru doldurulabilir tablo olarak.
4. Taşıyıcı değerlendirme matrisi. Sağlayıcılar genelinde ağırlıklı puanlama.
5. RFP zaman çizelgesi şablonu. Faaliyetler, tarihler, sorumlular.

Paketi indirin — beşi birden, ücretsiz, e-posta gerekmez. İşinize yarayanı alın, gerisini bırakın:

Tam TMS RFP şablon paketini indirin (.zip)

Cargoson, Avrupa ve Kuzey Amerika genelinde orta ölçekli üreticiler ve toptancılar tarafından kullanılan bir taşımacılık yönetim sistemidir. Yazmak üzere olduğunuz gibi RFP'lere her zaman yanıt veriyoruz; gereksinimlerinizi yazmaya başlamadan önce konuşmayı tercih ederseniz, hiçbir yükümlülük olmaksızın düşüncelerinizi birlikte değerlendirmekten memnuniyet duyarız.

Ücretsiz 30 dakikalık danışma görüşmesi için buraya tıklayın

Süreci iyi yönetin; harcanan her saate değecektir.