Vendor Ekosistemi ve Portföy Stratejisi
Müşteri için Portföy Stratejisi ve Koşullu Karar
Portföy kararını eşik ve kanıtlarla kur
Ön koşul: Arven vendor rol haritası, portföy uyum kartı, yaşam döngüsü takvimi ve tek/çoklu vendor trade-off kaydını tamamlamış olmalısın. Bu son derste müşteriye sunulabilir bir portföy karar paketi hazırlayacaksın: zorunlu eleme eşikleri, seçenek karşılaştırması, tedarikçi kanıtı, ortak destek modeli, açık risk, koşullu teklif, owner ve fallback. Yaklaşık 31 dakika anlatı, 31 dakika uygulama ve 14 dakika değerlendirme önerilir. Karar problemi 'hangi markayı seviyoruz' değildir. Arven portal–ERP–üretim akışında doğru siparişin işlenmesi, hedef performans, güvenlik/veri sınırı, desteklenebilirlik ve planlanan kullanım ufku korunmalıdır. Bu sonuçlar olmadan düşük fiyat veya yüksek özellik puanı anlamlı değildir. Önce pazarlığa kapalı eşikleri müşteriyle belirle. Bir aday kritik arayüzü doğrulayamaz veya zorunlu destek süresini karşılayamazsa toplam puanda öne çıksa da koşulsuz önerilmez.
İki katmanlı matris kullan: birinci katman eleme eşikleri, ikinci katman uygun adaylar arasındaki trade-off. Eleme için her kriterin ölçüm yöntemi, kanıtı ve kabul eden rol yazılır. Örneğin 'ERP uyumu' bir broşür logosu değil, ürün/sürüm/topoloji belgesi ve negatif yol içeren POC sonucudur. İkinci katmanda üç yıllık maliyet, işletim becerisi, arayüz değişimi, partner bağımlılığı, veri çıkışı ve yol haritası etkisi değerlendirilir. Ağırlıklar müşterinin iş sahibi, BT operasyonu, güvenlik ve satın alma tarafından gözden geçirilir. Eksik kanıta sahte puan atama; Inconclusive durumu ve kapanış planı ver. İş sonucunu garanti edecek kanıt yoksa teklifi koşullu tut. Farklı para birimi veya süreleri aynıymış gibi karşılaştırma; TCO dönemi, kapsam, destek düzeyi ve büyüme senaryosu eşit olmalıdır.
| Eşik | Gerekli kanıt | Durum/karar |
|---|---|---|
| Portal–ERP akışı | Sürüm matrisi + uçtan uca POC | Pass/Conditional/Fail |
| Destek ufku | Ürün yaşam döngüsü ve sözleşme | Pass/Conditional/Fail |
| Olay koordinasyonu | Ortak destek playbook ve hizmet saatleri | Pass/Conditional/Fail |
| Veri çıkışı | Reverse POC ve sözleşme incelemesi | Pass/Conditional/Fail |
ÖRNEK
Yüksek puanlı aday elemeden kalabilir
Arven A adayı maliyet ve hızda yüksek puan alır fakat üretim ERP sürümü için yazılı destek teyidi yoktur. B adayı daha yavaş kurulur, ancak sürüm matrisi ve ortak POC kanıtı tamdır. Ekip A'yı 'kazandı' diye sunmaz; A Conditional kalır ve teyit tarihine bağlanır. Teyit olumsuzsa B veya geçici mevcut arayüz fallback olur. Nihai tercihi kanıt ve iş riskiyle müşteri verir.
MÜŞTERİYE SOR
Portföy seçiminde hangi kriterler eleme eşiğidir, kim kabul eder ve eksik kanıt için son karar tarihi nedir?
Skorun kritik uygunsuzluğu gizlemesini önlemek için.
ŞİMDİ SEN DENE
Arven karar kapısını yaz
Üç aday için dört zorunlu kriter ve dört trade-off kriteri tanımla. Her satıra kanıt bağlantısı, ölçüm tarihi, Pass/Conditional/Fail/Unknown, karar sahibi ve kapanış eylemi ekle. Bir adayın neden koşullu kaldığını müşteriye iki cümleyle açıkla.
BİLGİNİ KONTROL ET
Bir aday yüksek toplam puan aldı ama zorunlu ERP desteği teyitsiz. Karar?
Tedarikçi incelemesi ile ortak işletimi bağla
Teknik uyum tamam görünse de tedarikçi ve partner kanıtı eksikse öneri kırılgandır. NIST SP 1326 ICT tedarikçileri için due diligence alanları sunar: köken, dayanıklılık, temel siber uygulamalar ve tedarik zinciri katmanları. NIST SP 800-161 bu incelemeyi daha geniş risk yönetimi yaşam döngüsüne bağlar. Bunları tek tip anket olarak herkese göndermek yerine Arven'in riskine göre seç. Portalda sipariş verisi işleyen tarafın alt sağlayıcısı, güvenlik güncelleme kanalı, uzaktan erişim yetkisi ve kesinti devam planı ilgili olabilir. İnceleme sonucunu 'güvenli/güvensiz vendor' damgasına indirgeme; iddia, belge, tarih, kapsam ve müşteri güvenlik/satın alma kararını kaydet. Pre-sales'in görevi kanıt boşluğunu görünür kılıp yetkili uzmanı sürece almaktır.
Tedarikçi değerlendirmesi destek tasarımıyla birleşir. Müşteri tek iş olayı açtığında portal, ERP, altyapı ve mesaj servisi ekipleri hangi sırada devreye girer? İlk temas noktası, tanı verisi, eskalasyon, hizmet saatleri ve müşteriye güncelleme periyodu yazılmalıdır. 'Tek destek noktası' sözünün sağlayıcının gerçekten sorumlu olduğu ürün ve entegrasyonları kapsayıp kapsamadığı sözleşmede kontrol edilir. Arven vaka çalışmasında destek koordinatörü olayın bütününü izler; her vendor kendi yetki alanında teşhis yapar. Bir destek masası diğer vendor'ın sözleşmesini kendiliğinden genişletemez. Veri gizliliği de önemlidir: log paketinde müşteri verisi varsa paylaşım izni ve maskeleme kuralı önceden kararlaştırılır. Ortak POC'a bir arıza devir provası eklemek, kâğıt üzerindeki RACI'nin işlemesini sınar.
| Olay aşaması | Sahip | Kanıt |
|---|---|---|
| Tespit | Arven operasyon | İşlem kimliği ve alarm |
| İlk teşhis | Koordinatör + uygulama | İz, zaman damgası |
| Vendor devri | İlgili ürün ekibi | Sürüm ve yeniden üretim |
| Kapatma | İş sahibi + operasyon | Sipariş uzlaştırması |
ÖRNEK
SLA var, ortak olay yok
Portal vendor'ı ve ERP vendor'ı ayrı ayrı dört saatlik yanıt hedefi bildirir. Arven'de sipariş kaybının hangi ürün kaynaklı olduğu bilinmeyince iki ekip birbirine yönlendirir. Yeni playbook ortak olay numarası, ilk teşhis sahibi ve eşzamanlı eskalasyon tanımlar. Böylece iki SLA'nın müşteriye otomatik uçtan uca dört saat çözüm sözü vermediği açık kalır; müşteriyle gerçek hizmet hedefi ayrıca görüşülür.
MÜŞTERİYE SOR
Çok taraflı kritik olayda iş sonucunu kim sahipleniyor; log paylaşımı ve destek saatleri için hangi kısıtlar var?
Teknik ve sözleşmesel olay boşluğunu saptamak için.
ŞİMDİ SEN DENE
Ortak olay provası tasarla
Arven portal siparişinin ERP'ye geçmediği senaryo için tespit, ilk teşhis, vendor devri, müşteri güncellemesi, veri uzlaştırması ve kapatma adımlarını yaz. Her adıma owner, kanıt, hizmet saati ve açık sözleşme koşulu koy.
BİLGİNİ KONTROL ET
İki vendor da dört saat ilk yanıt veriyor. Uçtan uca dört saat çözüm garantisi var mı?
Risk ve belirsizliği koşullu teklife aktar
Karar paketi müşterinin anlayacağı bir öneri ve teknik ekten oluşmalıdır. Öneride hedef iş sonucu, seçilen yaklaşım, nedenleri, kapsam, kabul ölçütleri ve üç kritik koşul görünür olur. Teknik ekte her koşulun kaynak bağlantısı, test planı, ürün/sürüm, arayüz, sözleşme sahibi, BoM/TCO etkisi, son tarih ve fallback yer alır. 'Vendor teyit edecek' tek başına yeterli değildir: hangi soruya hangi formatta yanıt, hangi tarihe kadar gelecek; yanıt olumsuzsa mimari ve fiyat nasıl değişecek? Arven portal–ERP entegrasyonunun destek kapsamı açık değilse üretim geçişi yazılı teyide ve POC'a bağlanır. Teyit gecikirse mevcut arayüzün geçici korunması, kapsamın daraltılması veya farklı partner seçimi tartılır. Açık risk müşteriden saklanmaz; varsayımsal fiyat ve sertifika da üretilmez.
Koşullu teklif revizyonu HLD, BoM, lisans defteri, TCO ve destek playbook'u ile aynı sürümü göstermelidir. Teknik seçenek değiştiğinde destek sözleşmesi veya veri çıkış planı sessizce eski kalamaz. Satın alma fiyat ve hizmet süresini, güvenlik due diligence ile veri akışını, operasyon işletilebilirliği, iş sahibi sonuç ve geçiş riskini inceler. Bu tarafların onayları farklı soruları kapatır; bir kişinin imzası bütün teknik belirsizlikleri kapatmaz. Ürün yol haritasındaki yayınlanmamış kabiliyet bugünkü sözleşme özelliği gibi teklif edilmez. İnsan uzman incelemesi de dersin Draft durumundan ayrı kapıdır. Öğretim amaçlı Arven senaryosunda gerçek vendor fiyatı, özel anlaşma veya hukuki sonuç bilinmediği için bunlara ilişkin karar değil yöntem ve kanıt paketi üretilir.
ÖRNEK
Koşulu görünür olan öneri
Arven için seçici çoklu vendor yaklaşımı en iyi teknik uyumu verir, ancak mesaj servisi alt sağlayıcısının veri bölgesi teyitsizdir. Öneri bunun güvenlik incelemesine bağlı olduğunu söyler. Yanıt olumsuzsa müşteri kontrolündeki mesaj servisine geçiş seçeneği ve ek işletim maliyeti açılır. Belirsizlik yönetildiği için öneri tamamen çöpe atılmaz; fakat kesin olarak 'uyumlu' diye sunulmaz.
MÜŞTERİYE SOR
Hangi koşulları teklif imzasından önce, hangilerini üretim geçişinden önce kapatmak istersiniz; risk kabul yetkisi kimde?
Koşul son tarihini müşteri karar takvimine bağlamak için.
ŞİMDİ SEN DENE
Tek sayfalık müşteri özeti yaz
Arven için önerilen yaklaşımı, üç kanıtlı nedeni, iki açık koşulu, iki fallback'i ve üç yıllık maliyet kapsamını yaz. Her koşulun owner, tarih, BoM/TCO etkisi ve kabul mercii görünür olsun. Hukuki veya fiyat kesinliği uydurma.
BİLGİNİ KONTROL ET
Entegrasyon desteği yazılı teyitsiz. Teklifte ne görünmeli?
Kararı izle, yeniden aç ve devret
Portföy kararı imza anında donmuş bir gerçek değildir. ERP sürümü, portal sürümü, alt sağlayıcı, lisans paketi, destek sonu, müşteri iş hacmi veya veri bölgesi değiştiğinde daha önce verilen uyum ve maliyet kararı yeniden açılır. Her tetik için hangi kanıtın yenileneceği tanımlanır: sürüm matrisi, POC, sözleşme, destek playbook'u, TCO veya reverse POC. Operasyon ekibi vendor duyurularını ve olay eğilimlerini izler; satın alma yenileme ve fesih tarihlerini, mimari ekip değişiklik etkisini, iş sahibi kabul kriterini yönetir. NIST risk yaklaşımı bu yaşam döngüsü gözden geçirmesine çerçeve sağlar; hangi ürünün ne zaman değişeceği yine üretici ve müşteri kayıtlarından bulunur. 'Bir gün bakarız' yerine 90 gün önce yenileme ön kontrolü, büyük sürüm değişikliğinde regresyon, kritik alt sağlayıcı değişikliğinde risk incelemesi gibi somut tetikler yaz.
Son Arven paketi dört dersin çıktılarını birleştirir: birinci dersten aktör/sorumluluk haritası, ikinciden gereksinim–katalog–kanıt kartı ve yaşam döngüsü takvimi, üçüncüden trade-off, dikiş maliyeti ve çıkış deneyi, bu dersten koşullu karar ve ortak destek akışı. Dosyalarda aynı ürün/sürüm, mimari revizyonu ve teklif tarihi kullanılmalı. Çelişen iki kaynak sessizce birleştirilmez; yetkili tarafla çözülür. Son kullanıcıya kısa karar özeti, uzman incelemesine kaynaklı worksheet, operasyon ekibine playbook teslim edilir. 10 soruluk modül değerlendirmesi vendor ezberi değil doğru kanıt ve karar davranışını sınar. Rubric'te dört boyut puanlanır: iş uyumu, tedarik/sözleşme kanıtı, işletim/çıkış ve koşullu karar. Bu içerik Draft'tır; gerçek müşteri kullanımı için teknik uzman, güvenlik/satın alma ve editör incelemesi ayrıca gerekir.
ÖRNEK
Bir API değişikliği dört kayıt açar
Arven ERP API'si yeni sürüme geçer. Portföy uyum kartı yeni sürüm matrisini ister; ortak olay playbook'unda hata kodları değişir; entegratör bakım eforu ve TCO güncellenir; reverse POC'daki veri dönüşümü yeniden sınanır. Tek satırlık 'ERP güncellendi' notu karar geçmişini korumaz. Aynı teklif revizyonunda dört bağlantı izlenir.
MÜŞTERİYE SOR
Vendor duyurusu, yenileme ve API değişimini bugün kim izliyor; müşteri kararı hangi olayda yeniden açılmalı?
Portföy stratejisinin işletim sahipliğini sağlamak için.
ŞİMDİ SEN DENE
Arven portföy karar dosyasını tamamla
Aktör haritası, uyum kartı, yaşam döngüsü, seçenek matrisi, due diligence, ortak destek, çıkış deneyi ve koşullu teklif sayfalarını aynı revizyonda bağla. En az üç açık koşula owner, tarih, kanıt ve fallback ekle; rubric ile kendi kararını puanla.
BU DERSTEN AL
Bu dersten taşıyacağın düşünceler
- Karar önce zorunlu eşikleri, sonra uygun adaylar arasındaki trade-off’u karşılaştırır.
- Tedarikçi due diligence ve ortak destek akışı teknik uyumun yanında görünürdür.
- Her koşul test, owner, tarih, teklif etkisi ve fallback ile yazılır.
- Sürüm, partner, destek, lisans ve veri değişikliği kararı yeniden açar.