SRM Projeleri: Tedarikçi Adayından Onboarding Sürecine Dijital Yönetim

SRM yazılımı almak, tedarikçi yönetimini çözmez. Bu cümleyi ilk kez bir Kayseri metal imalatçısının satın alma direktörüne söylediğimde, masanın karşı tarafından uzun bir sessizlik geldi. Firma, imalat sektöründe 312 çalışanıyla orta ölçeğin üst bandında yer alıyor; yıllık satın alma hacmi kırk farklı tedarikçiyle döngü yapıyor ve bu tedarikçilerin üçte birinden fazlası her üç yılda bir değişiyor. Satın alma direktörü, e-posta klasörlerinde boğulmuş teklif formlarından, onaylanmamış fiyat listelerinden ve kimin hangi tedarikçiyi ne zaman ‘aktif’ saydığından söz etti. Çözüm olarak ERP üzerinde bir SRM modülü kurulmasını istiyordu. Ama sorun yazılımda değildi. Sorun, o ana kadar hiç tanımlanmamış bir sürecin yazılım aracılığıyla tanımlanacağı yanılgısındaydı. Bu yanılgı, Türkiye’deki SRM projelerinin büyük bölümünü başlamadan çürüten asıl kırılma noktasıdır.SRM, yani Tedarikçi İlişkileri Yönetimi (Supplier Relationship Management), bir yazılım kategorisi olmaktan çok bir süreç yetkinliği meselesidir. Kavram teoride nettir: potansiyel tedarikçileri sistematik biçimde değerlendirmek, onaylı listeye almak, performanslarını izlemek ve ilişkiyi veri üzerinden yönetmek. Ancak Türkiye’deki imalat ve tedarik ekosistemi bu teorinin üzerine oturduğu altyapıdan yoksundur. Küçük ve orta ölçekli işletmelerin çoğunda tedarikçi kaydı ya muhasebe yazılımının cari kart ekranından ibarettir ya da Excel tablolarına dağılmış birbirinden kopuk veri adacıklarından oluşur. ERP sistemine sahip firmalarda bile satın alma modülü çoğunlukla sipariş ve fatura akışını takip eder; tedarikçiyi stratejik ortaklık perspektifinden değerlendiren bir yapı kurulmamıştır. SRM projesine başlamadan önce bu boşluğu göremeyen ekipler, yazılımı açtıklarında ne gireceğini bilmez hale gelirler. Sistem açılır, alanlar boş kalır, proje altı ay sonra ‘aktif ama kullanılmayan bir modül’ olarak kapanır.Peki hangi koşulda SRM gerçekten değer üretir? Bunu Kayseri vakasında somut biçimde gördüm. İlk yaptığımız şey yazılım kurmak değil, tedarikçi yaşam döngüsünü kâğıda dökmekti: aday belirleme, ön değerlendirme formu, saha ziyareti veya belge incelemesi, onay komitesi kararı, sisteme kayıt, ilk sipariş, performans takip periyodu. Bu sekiz adımın hiçbiri resmi bir prosedüre bağlanmamıştı; her adım bir kişinin alışkanlığına göre şekilleniyordu. Satın alma direktörü adayları değerlendirirken hangi kriterleri kullandığını sorduğumda ‘tecrübe ve sezgi’ dedi. Bu yanıt, SRM projesinin gerçek başlangıç noktasını işaret ediyordu: önce kriterler, sonra yazılım. Üç haftalık süreç haritalama çalışmasının ardından firma, tedarikçi değerlendirme matrisini ilk kez belgelemiş oldu. Bu matris olmadan hiçbir yazılımın değer üretemeyeceği açıktı.Dijital onboarding süreci, SRM’nin en kritik ve en çok ihmal edilen bölümüdür. Onboarding, yeni bir tedarikçiyi sisteme kayıt etmekten ibaret değildir; o tedarikçinin firmaya entegre edilmesi, beklentilerin iki yönlü aktarılması ve verinin doğru noktadan sisteme girmesi demektir. Türkiye pratiğinde bu süreç çoğunlukla tek bir e-posta zinciriyle yürütülür: vergi levhası ve imza sirküleri gönder, sana cari kodu verelim, iş başlasın. Bu yaklaşımın maliyeti, ilk sorun çıktığında ortaya dökülen veri kaosunda kendini gösterir. Kayseri firmasında, onboarding sürecini yapılandırdıktan sonra tedarikçi kayıt süresinin on dört iş gününden dört iş gününe indiğini ölçtük; bunun da ötesinde, eksik belge kaynaklı ödeme gecikmelerinin oranı ilk 90 günde yaklaşık olarak yarı yarıya geriledi. Bu rakamlar süreci tanımlamanın, doğru yazılım seçmekten önce geldiğini kanıtlar nitelikteydi.ERP entegrasyonu noktasında ise Türkiye’ye özgü bir gerilim kendini gösteriyor: e-Fatura ve e-Defter yükümlülükleri 2012’den itibaren kapsamı genişleyen bir zorunluluk olarak zaten ERP sistemlerine baskı uyguluyor. Tedarikçi bazlı e-Fatura akışının SRM modülüyle tutarlı biçimde çalışması, entegrasyon mimarisinin baştan doğru kurulmasını gerektiriyor. Tedarikçi cari hesabı, satın alma siparişi, teslimat kaydı ve fatura akışı arasındaki veri tutarlılığı; ERP’nin hangi modülünün hangi veriye ‘kaynak’ kabul edileceği sorusunu kaçınılmaz kılar. Bu soruyu proje başında yanıtlamayan firmalar, ilerleyen dönemde aynı tedarikçinin iki farklı kayıtla sistemde yaşadığını, ödeme geçmişinin tutarsız göründüğünü ve raporların birbirini çürüttüğünü fark eder. Küçük ölçekli bir muhasebe yazılımından ERP’ye geçiş sürecinde olan firmalarda bu risk daha da belirgindir; çünkü eski sistemdeki cari yapısı çoğunlukla SRM’nin beklediği tedarikçi hiyerarşisiyle örtüşmez.Bir yönetici olarak SRM projesine başlamadan önce yanıtlamanız gereken üç soru var; bunları sormazsanız yazılım bütçenizin büyük bölümü gereksiz özelleştirme ve danışmanlık saatine gider. Birinci soru: Tedarikçi değerlendirme kriterleriniz belgelenmiş mi? Kriterlerin yalnızca bilinmesi yeterli değil; yazılıya dökülmüş, ekip içinde mutabık kalınmış ve periyodik olarak gözden geçirilen bir matris var mı? İkinci soru: Onboarding sürecinde kim, ne zaman, hangi belgeyi kim onaylıyor? Bu sorunun yanıtı bir süreç haritasında açıkça görünmüyorsa, yazılım bu belirsizliği çözmez; yalnızca dijitalleştirir. Üçüncü soru: ERP’nizdeki tedarikçi veri yapısı, SRM’nin ihtiyaç duyduğu hiyerarşiyle uyumlu mu? Bu üç soruyu yanıtlamadan başlanan SRM projeleri, Türkiye’de büyük oranda hedefine ulaşamıyor. Projenin ilk sekiz haftasını yazılım kurmakla değil, bu soruları yanıtlayan süreç dokümantasyonu ile geçirmek; sonraki on bir ayın kalitesini doğrudan belirliyor.Kayseri’deki satın alma direktörü, projenin sonunda bana şunu söyledi: ‘Yazılımı altı ayda aldık, süreci tanımlamak iki ay sürdü. Ama o iki ay olmasaydı altı aylık yazılım boşa giderdi.’ Bu cümle, SRM projelerindeki öncelik sıralaması için en net özettir. Teknoloji, tanımlı bir süreç üzerinde hız ve görünürlük kazandırır; ama sürecin kendisini icat etmez. Eğer pazartesi sabahı bir SRM projesi başlatmayı düşünüyorsanız, ilk adımınız yazılım değerlendirme tablosu oluşturmak olmamalı. İlk adımınız, mevcut tedarikçi yaşam döngünüzü bir beyaz tahtaya çizmek ve her adımın sahibini, giriş belgesini ve çıkış kriterini not etmek olmalı. O harita tamamlanmadan aldığınız her SRM yazılımı, içi boş bir çerçevedir.


entegrasyon katmanı yalnızca verimlilik gündemiyle ele alınırsa eksik kalır. Müşteri deneyimi, çalışan davranışı, finansal etki ve operasyonel dayanıklılık birlikte değerlendirilmelidir. Çünkü kurumsal teknoloji, tek bir departmanın değil, işletmenin tamamının çalışma biçimini değiştirir.


Gökhan Mercanoğlu
ERP ve Kurumsal Yazılım