Müzakere Platformlarının Bittiği Yer ve CLM ile Tedarik Çözümlerinin Başladığı Yer

Bir müzakere platformu pazarlık sürecine sahip olur: hedefler, sınırlar, ödünleşimler, teklifler, tavizler, karşı teklifler ve sonuç analizi. CLM sözleşme yaşam döngüsüne sahip olurken, bir tedarik paketi tedarikçi rekabetine ve ihale verme iş akışına sahip olur. Müzakere yazılımı ise hazırlık araçlarından redline süreçlerine ve teklif alışverişine kadar her şeyi kapsayan daha geniş bir şemsiye terimdir.

Bu, müzakere platformu vs CLM, müzakere yazılımı vs CLM ve tedarik paketi vs müzakere platformu için doğrudan yanıttır. Kategoriler örtüşür; bu nedenle alıcılar ürünleri, pazarlama sayfalarında “AI” veya “negotiation” geçip geçmediğine göre değil, yetkili kayıtlarına ve iş akışı sorumluluklarına göre sınıflandırmalıdır.

Kısa cevap

Bir müzakere platformu pazarlık mantığını ve alışverişleri yönetir. CLM sözleşme dilini, onayları, imzaları ve yükümlülükleri kontrol eder. Bir tedarik paketi gereksinimleri, rekabetçi etkinlikleri, teklif değerlendirmesini ve ihale vermeyi yönetir. Müzakere yazılımı ise hem nokta çözümleri hem de platformları içeren şemsiye kategoridir. Özellikler örtüştüğünde, hangi sistemin etkinlik, müzakere geçmişi, imzalanmış sözleşme ve satın alma işlemi için yetkili kaldığını belirleyin.

Pratik sınır: her sistem hangi kayda sahip olur?

“Negotiation platform” evrensel olarak standartlaştırılmış bir yazılım kategorisi değildir. Aşağıdakiler, düzenleyici bir tanım değil, Kurumsal satın alma için pratik bir taksonomidir.

En net sınır, her kategorinin kontrol ettiği birincil iş nesnesidir:

• Bir Müzakere platformu pazarlık sürecini ve teklif geçmişini kontrol eder.
• CLM sözleşmeyi, onaylı dili ve yükümlülükleri kontrol eder.
• Bir tedarik paketi tedarik projesini, rekabetçi etkinliği ve ihale vermeyi kontrol eder.
• Procure-to-pay veya ERP siparişler, teslim alımlar, faturalar ve ödemeler gibi satın alma işlemlerini kontrol eder.
• Müzakere yazılımı yalnızca hazırlık, simülasyon, redline, koçluk veya analitik gibi tek bir görevi destekleyebilir.

Bu ayrım önemlidir çünkü komşu sistemler giderek daha fazla müzakere özelliği içermektedir. Örneğin SAP, guided sourcing içinde ihale öncesi müzakereyi ve tedarik iş akışları içinde alıcı-tedarikçi hedef fiyat alışverişlerini belgelendirir. SAP ayrıca karşı öneriler, belge sürümleri ve izlenen değişikliklerin kabulü veya reddini içeren CLM müzakere görevlerini de belgelendirir. Bunlar örtüşmenin doğrulanmış örnekleridir; her tedarik veya CLM ürününün aynı işlevselliği sunduğunun kanıtı değildir (SAP guided sourcing; SAP contract negotiation tasks).

Özgün kategori karşılaştırma matrisi: RECORD testi

Bir ürün kategorisini değerlendirirken bu yeniden kullanılabilir RECORD testini kullanın:

1. R — Responsibility (Sorumluluk): Ürün hangi iş akışını tamamlamaktan sorumludur?
2. E — Evidence (Kanıt): Hangi girdileri, alışverişleri ve onayları saklar?
3. C — Control (Kontrol): Neyi önerebilir, iletebilir, kabul edebilir veya yürütebilir?
4. O — Object (Nesne): Hangi birincil iş nesnesini yönetir?
5. R — Record (Kayıt): Yetkili sonuç nerede yaşar?
6. D — Downstream (Aşağı akış): Sonucu hangi sistem operasyonelleştirir?

Bu matris yaygın bir satın alma hatasını ortaya çıkarır: bir özelliği sistem sahipliğinin kanıtı olarak görmek. Bir CLM aracı, ticari taviz stratejisine sahip olmadan karşı önerileri destekleyebilir. Bir tedarik paketi, imzalanmış yükümlülüklerin deposu haline gelmeden birden fazla etkinlik turunu destekleyebilir. Bir Müzakere platformu, işi verme veya sözleşme imzalama yetkisine sahip olmadan önerilen bir sonuç üretebilir.

Müzakere Yazılımı ve CLM Karşılaştırması

Müzakere Yazılımı ve CLM Karşılaştırması, şemsiye kategori ile kayıt sistemi arasındaki bir karşılaştırmadır.

Müzakere yazılımı şunları içerebilir:

• hazırlık çalışma alanları;
• senaryo ve ödünleşim modelleme;
• simülasyonlar;
• koçluk araçları;
• mesajlaşma veya teklif alışverişi;
• sözleşme redline süreçleri;
• konuşma analizi;
• taviz ve sonuç analitiği.

CLM genel olarak sözleşme taleplerini, onaylı şablonları, madde kütüphanelerini, taslak hazırlamayı, redline’ları, iç onayları, yürürlüğe almayı, depo kayıtlarını, değişiklikleri, yükümlülükleri ve yenilemeleri kapsar. Ağırlık merkezi, tam ticari pazarlık stratejisi değil, icra edilebilir sözleşmedir.

Örtüşme en görünür şekilde sözleşme redline sürecinde ortaya çıkar. Her iki kategori de sapmaları belirleyebilir veya alternatif ifade önerebilir. Ayırt edici sorular şunlardır:

• Sistem fiyatı, hacmi, ödemeyi, hizmeti ve süreyi tek bir paket olarak modelleyebilir mi?
• Tavizlerin arkasındaki gerekçeyi ve sıralamayı korur mu?
• Onaylı hukuki maddeleri ve geri dönüş seçeneklerini uygular mı?
• Gerekli hukuk ve iş onaylarını yönlendirir mi?
• İmzalanmış sürümü saklar ve yükümlülükleri izler mi?

Ağırlıklı olarak sorumluluk, veri koruma, fikri mülkiyet veya tazminatla ilgili olan bir satın alma müzakeresi büyük ölçüde CLM ve hukuk incelemesine aittir. Fiyat, hacim, teslim süresi, ödeme koşulları ve hizmet seviyeleri paketlerini içeren bir görüşme ise daha doğal olarak bir Müzakere platformunda yönetilir; onaylı şartlar CLM’ye yazılır.

Bu iş akışı sınırının daha derin bir incelemesi için bkz. Contract Negotiation AI vs CLM: Where Procurement Still Needs a Negotiation Platform.

Tedarik Paketi ve Müzakere Platformu Karşılaştırması

Tedarik Paketi ve Müzakere Platformu Karşılaştırması, öncelikle rekabetçi süreç yönetimi ile pazarlık yönetimi arasındaki bir karşılaştırmadır.

Bir tedarik paketi yaygın olarak şunlara sahip olur:

• gereksinimler ve etkinlik kurulumu;
• tedarikçi davetleri veya yeterlilik;
• RFI, RFP ve RFQ’lar;
• açık artırmalar ve etkinlik turları;
• teklif normalizasyonu ve karşılaştırması;
• değerlendirme puanları ve senaryoları;
• ihale önerileri ve kayıtları.

Bir Müzakere platformu yaygın olarak şunlara sahip olur:

• hedef ve arzu edilen pozisyonlar;
• rezervasyon noktaları veya masadan kalkma sınırları;
• takas edilebilir değişkenler ve paket tasarımı;
• taviz stratejisi;
• teklifler ve karşı teklifler;
• eskalasyon kuralları;
• sonuç ve taviz analizi.

Örtüşme, tedarik etkinliklerinin revize edilmiş tekliflere, hedef fiyatlara veya müzakere edilmiş etkinlik şartlarına izin verdiği durumlarda ortaya çıkar. ABD Federal Acquisition Regulation kavramsal ayrım için yararlı bir kamusal örnek sunar: FAR 15.306, müzakereleri teklif revizyonuna izin vermeyi amaçlayan alışverişler olarak tanımlar ve pazarlığın fiyatı, takvimi, teknik gereksinimleri, sözleşme türünü ve diğer şartları kapsayabileceğini belirtir. Ayrı olarak FAR 15.308, ihale kararında kaynak seçimi otoritesinin bağımsız muhakemesini gerektirir (FAR Subpart 15.3; FAR 15.308).

Bu federal kurallar özel Kurumsal satın almayı otomatik olarak yönetmez. Ancak daha geniş ölçekte yararlı bir ayrımı gösterirler: bir alışverişi yürütmek, bir tedarikçi seçme veya kurumu bağlama yetkisine sahip olmakla aynı şey değildir.

Varsayımsal uçtan uca iş akışı

Varsayımsal örnek—bir kıyaslama veya müşteri iddiası değildir: Bir üretici, birkaç tesis genelinde kritik bir bakım hizmeti tedarik etmektedir.

1. Tedarik rekabete sahip olur

Tedarik paketi gereksinimleri saklar, nitelikli tedarikçileri davet eder, teklifleri alır ve değerlendirme puanlarını kaydeder. Satın alma, onaylı etkinlik kuralları kapsamında uygulanabilir iki finalisti belirler.

2. Müzakere platformu pazarlık mantığına sahip olur

Onaylı teklif verileri Müzakere platformuna girer. Ekip fiyat, yanıt süresi, ödeme koşulları, mobilizasyon tarihi ve hizmet kredileri dahil değişkenleri tanımlar. Ayrıca yasak tavizleri ve eskalasyon eşiklerini de kaydeder.

Bir AI negotiation yeteneği paketler önerebilir veya sınırlandırılmış karşı teklifleri iletebilir. Bir teklifi iletip iletemeyeceği veya geçici olarak kabul edip edemeyeceği, yalnızca teknik yeteneğe değil, devredilmiş yetkiye bağlıdır.

Bu katmanı değerlendiren ekipler AI negotiation overview sayfasını inceleyebilir ve iş akışı gereksinimlerini procurement negotiation software ile karşılaştırabilir. Negotiations.AI için somut bir rol, sonucun ilgili kayıt sistemine geri dönmesinden önce onaylı tedarik, sözleşme ve tedarikçi girdilerinden yönetilen ticari paketler hazırlamak olabilir. Bu iş akışı yine de gerçek entegrasyonların ve kontrollerin doğrulanmasını gerektirir.

3. Bir insan ihaleyi onaylar

Tedarik otoritesi değerlendirmeyi, müzakere sonucunu, tedarikçi riskini ve belgelenmiş istisnaları gözden geçirir. Kurumsal politika hesap verebilir muhakeme gerektirdiğinde, ihaleyi model değil kişi onaylar.

4. CLM sözleşme oluşumuna sahip olur

Onaylı ticari sonuç CLM’ye girer. Hukuk ve iş sahipleri sapmaları gözden geçirir, onayları tamamlar ve sözleşmeyi yetkili imza sahipleri aracılığıyla yürürlüğe alır.

5. ERP yürütmeye ve gerçekleşen değere sahip olur

Onaylı satın alma verileri işlemsel sisteme akar. Satın alma siparişleri ve faturalar daha sonra müzakere edilen fiyatların ve şartların kullanılıp kullanılmadığına dair kanıt sağlar.

Hiçbir tekil devir, bir öneriyi sessizce bir taahhüde dönüştürmemelidir.

AI negotiation için kanıt gereksinimleri

AI negotiation, yönetilen kanıta bağlıdır. Cilalı bir öneri, yalnızca spesifik olduğu için güvenilir değildir.

Doğrulanmış gerçekler

Doğrulanmış girdiler; imzalanmış sözleşme şartlarını, mevcut katalog fiyatlarını, kabul edilmiş tedarikçi tekliflerini, fatura geçmişini ve resmi olarak onaylanmış yetki sınırlarını içerebilir. Her alan, kaynağını, sahibini ve yürürlük tarihini belirtmelidir.

Varsayımlar

Beklenen talep, öngörülen geçiş yapılabilirliği veya bir tedarikçinin daha uzun bir süreye değer verdiği inancı buna örnektir. Bunları varsayım olarak etiketleyin ve doğrulamaları için bir sahip atayın.

Tahminler

Should-cost modelleri, tahmini hacimler ve öngörülen tedarikçi yanıtları tahmindir. Metodolojilerini, tarihlerini, güven düzeylerini ve hassasiyetlerini koruyun. Bunları gözlemlenmiş gerçekler olarak sunmayın.

Öneriler

Hedefler, açılış pozisyonları, taviz sıraları ve önerilen paketler öneridir. Bunlar mevcut kanıt, politika, tedarikçi bağlamı ve yetki karşısında hesap verebilir inceleme gerektirir.

Pratik bir girdi kaydı şu şablonu kullanabilir:

Tedarikçi risk yönetişimi de özerkliği etkilemelidir. Stratejik, sıkıntıdaki, tek kaynaklı veya ilişki açısından hassas tedarikçiler, harcamaları parasal bir eşik altında kalsa bile otomatik alışveriş için zayıf adaylar olabilir.

İnsan yetkisi ayrı bir kontrol katmanıdır

Bir sistem dört farklı eylem gerçekleştirebilir:

1. teklif hazırlamak;
2. teklif önermek;
3. teklif iletmek;
4. bir sonucu kabul etmek veya taahhüt etmek.

Bu eylemlerin ayrı izinleri olmalıdır. Yazılım analizi sözleşmesel yetki yaratmaz. Örneğin ABD federal satın alımında, sözleşme yetkilileri hükümeti yalnızca devredilmiş yetki sınırları içinde ve geçerli gereksinimler, izinler ve onaylar karşılandıktan sonra bağlayabilir (FAR 1.602-1). Özel kuruluşların kendi yetki matrislerine ihtiyacı vardır.

Hesap verebilir insan incelemesi veya onayı, yasa, politika veya devredilmiş yetkinin gerektirdiği her yerde zorunlu olmaya devam eder ve en azından şunları içermelidir:

• hedeflerin, rezervasyon noktalarının ve yasak şartların belirlenmesi;
• otomatik etkileşimin tedarikçi ilişkisine uygun olup olmadığına karar verilmesi;
• sorumluluk, gizlilik, siber güvenlik, yaptırımlar veya fikri mülkiyet içeren hukuki sapmaların onaylanması;
• tutarsız verilerin, belirsiz tekliflerin veya şüpheli suistimalin çözülmesi;
• hesap verebilir muhakemenin gerekli olduğu yerde ihale kararı verilmesi;
• nihai sözleşmenin onaylı ticari sonuçla eşleştiğinin doğrulanması;
• imzanın veya kurumu bağlayan herhangi bir eylemin yetkilendirilmesi;
• gerçekleşen değerin siparişler, faturalar ve tedarikçi performansına göre doğrulanması.

NIST’in AI Risk Management Framework’ü gönüllü rehberliktir, ancak AI yaşam döngüsü boyunca hesap verebilirlik, şeffaflık, geçerlilik, güvenlik, emniyet, gizlilik ve adaleti kapsayan yararlı bir yönetişim referansı sağlar (NIST AI RMF).

Yedi adımlı platform-sınırı değerlendirmesi

Adım 1: Yetkili kayıtları adlandırın

Tedarik etkinliği, müzakere geçmişi, imzalanmış sözleşme, tedarikçi ana verisi ve satın alma işleminin sahiplerini yazın.

Adım 2: İş akışı tetikleyicilerini tanımlayın

Bir müzakereyi neyin başlattığını belirtin: süresi dolan bir sözleşme, tamamlanmış teklif turu, tedarikçi zam talebi veya onaylı tedarik stratejisi.

Adım 3: Verileri kanıt durumuna göre ayırın

Her önemli girdiyi doğrulanmış gerçek, varsayım, tahmin veya öneri olarak işaretleyin. Belgelenmemiş piyasa kıyaslamalarını reddedin.

Adım 4: Yetkiyi eyleme göre haritalayın

Kimin hazırlayabileceğini, önerebileceğini, iletebileceğini, geçici olarak kabul edebileceğini, ihaleyi onaylayabileceğini ve imzalayabileceğini belgelendirin. Tek ve geniş bir “müzakereci” izninden kaçının.

Adım 5: İstisna yollarını test edin

Çelişen bir sözleşme şartı, eski fiyat girdisi, korkuluk ihlali, yüksek riskli tedarikçi ve belirsiz karşı teklif içeren senaryolar kullanın.

Adım 6: Geri yazma ve mutabakatı test edin

Etkinlik sonuçlarının tedarike geri döndüğünü, onaylı sözleşme dilinin CLM’ye girdiğini ve işlem verilerinin manuel yeniden yorumlama olmadan ERP’ye ulaştığını doğrulayın.

Adım 7: Sonuç ölçümünü doğrulayın

Fiyat indirimi, önlenen zam, ödeme koşulu değeri ve fiyat dışı risk azaltımını ayırt edin. Ardından iddia edilen sonucun sözleşmelerde, siparişlerde, faturalarda veya performans verilerinde görünüp görünmediğini test edin.

Ayrı bir Müzakere platformunun uygun olmayabileceği durumlar

Ayrı bir platform şu durumlarda gereksiz karmaşıklık ekleyebilir:

• tedarik zaten basit, rekabetçi fiyat keşfini yeterince iyi yönetiyorsa;
• müzakere neredeyse tamamen hukuk ve CLM tarafından kontrol edilen sözleşme redline sürecinden ibaretse;
• işlem hacmi başka bir yönetilen iş akışını haklı çıkarmayacak kadar düşükse;
• kuruluşun temiz sözleşme, tedarikçi ve satın alma verisi yoksa;
• yetki kuralları belgelenmemişse;
• entegrasyonlar yinelenen veya çelişen kayıtlar oluşturacaksa;
• tedarikçi ilişkisi tekrarlanabilir alışverişlerden ziyade özel yönetici etkileşimi gerektiriyorsa.

Buna karşılık, pazarlık sık, çok boyutlu ve kategoriler arasında tekrarlanabilir olduğunda ve kuruluş veri, izinler, istisnalar ve geri yazmayı yönetebildiğinde ayrı bir katmanı gerekçelendirmek daha kolay hale gelir.

Satın alma satın alma kontrol listesi

Herhangi bir kategoriyi seçmeden önce, tedarikçilerden etkinlikten gerçekleşen sonuca kadar tek bir senaryoyu göstermelerini isteyin:

• Onaylı teklifleri ve sözleşme kısıtlarını kaynak bilgisiyle içe aktarın.
• Doğrulanmış verileri model tahminlerinden ayırın.
• Birkaç ticari ve operasyonel değişkeni birlikte modelleyin.
• Yasak tavizleri kısıtlayın.
• Öneri, iletişim ve kabul izinlerini ayırın.
• Belirsizliği ve korkuluk ihlallerini adı belirlenmiş kişilere eskale edin.
• Teklifleri, karşı teklifleri, onayları ve kural sürümlerini koruyun.
• İhale kanıtını tedarike geri döndürün.
• Onaylı şartları bağlamı kaybetmeden CLM’ye gönderin.
• Müzakere edilen sonucu PO’lar ve faturalarla mutabık hale getirin.
• Tam kaydı kullanılabilir bir formatta dışa aktarın.
• Model, kural ve denetim kaydı değişiklik kontrollerini açıklayın.

Yalnızca kategori etiketine göre satın almayın. Kuruluşunuzun test edebileceği iş akışına, yetkili kayıtlara ve kontrol gereksinimlerine göre satın alın.

SSS

Bir Müzakere platformu CLM’nin yerine geçer mi?

Genellikle hayır. Bir Müzakere platformu pazarlık stratejisine, alışverişlere ve sonuçlara odaklanır. CLM ise onaylı sözleşme metni, imzalar, yükümlülükler, değişiklikler ve yenilemeler için doğal otorite olmaya devam eder. Yer değiştirme ancak bir ürünün her iki kategorinin de gerektirdiği tam kontrolleri ve yaşam döngüsünü açıkça sağladığını göstermesi halinde makul olabilir.

Bir tedarik paketi müzakereleri yürütebilir mi?

Evet. Bazı tedarik paketleri revize edilmiş teklifleri, açık artırmaları, hedef fiyat alışverişlerini ve ihale öncesi müzakereyi destekler. Tedarik paketi yine de tipik olarak etkinliğe ve ihaleye sahip olurken, uzman bir platform daha derin taviz mantığı, paket modelleme veya yönetilen karşı taraf alışverişleri sağlayabilir.

Müzakere yazılımını platforma dönüştüren şey nedir?

Evrensel bir standart yoktur. Yararlı bir pratik eşik; strateji, karşı taraf etkileşimi, iş akışları, izinler, kanıt, entegrasyonlar ve sonuç kayıtlarını birleştiren entegre, tekrarlanabilir ve yönetilen bir ortamdır. Bir nokta çözüm bu işlevlerden yalnızca birini destekleyebilir.

Tedarikçi risk verisi nerede yaşamalıdır?

Yetkili kaydı tedarikçi yönetimi, risk veya ana veri sistemlerinde kalabilir. Müzakere platformu güncel, yönetilen risk sinyallerini tüketmeli ve bunları uygunluk, eskalasyon veya özerklik kurallarına uygulamalıdır; kontrolsüz yinelenen bir kaynak haline gelmemelidir.

AI bir tedarikçi teklifini otomatik olarak kabul edebilir mi?

Teknik yetenek, kurumsal yetki değildir. Otomatik veya geçici kabul yalnızca belgelenmiş yetki devri, doğrulanmış korkuluklar ve geçerli onay gereksinimleri içinde gerçekleşmelidir. Yeni, stratejik, yüksek riskli veya hukuken önemli sonuçlar hesap verebilir insan kararı için eskale edilmelidir.

Ek okuma

• FAR Subpart 15.3: Source Selection
• SAP: Pre-Award Negotiation in Guided Sourcing
• SAP: Management of Negotiation Tasks
• NIST AI Risk Management Framework

Feragatname: Bu makale hukuki, finansal veya sözleşmesel tavsiye değil, genel satın alma ve teknoloji bilgisi sunar.