Portföy Kapsamı, Uyum ve Yaşam Döngüsü

Ön koşul: Vendor rollerini, Arven'in iş akışını, gereksinim kaydını, mimari kararlarını ve BoM'u okuyabilmelisin. Bu dersten sonra portföyde görünen bir özelliği müşteri gereksinimi, desteklenen konfigürasyon, işletim yükü ve yaşam döngüsü boyunca izlenebilir biçimde değerlendireceksin. Yaklaşık 28 dakika anlatı, 28 dakika çalışma, 12 dakika kontrol önerilir. Ürün kataloğu bir başlangıç envanteridir, çözüm kanıtı değildir. Bir üreticinin 'yüksek erişilebilirlik', 'ERP entegrasyonu' veya 'gelişmiş güvenlik' başlığını açması, Arven'in belirli iş süresini, veri akışını veya toparlanma hedefini karşılayacağı anlamına gelmez. Önce iş sonucunu ölçülebilir kabul ölçüsüne çevir: vardiya başında sipariş portalı hangi yanıt süresinde işlem yapacak, ERP'ye hangi kayıt en fazla ne kadar gecikmeyle ulaşacak, hata olduğunda kim tekrar deneyecek? Ardından bu sonucu hangi ürün kabiliyeti, edisyon, lisans hakkı, konfigürasyon ve hizmet akışının sağladığını ara. Ürün uyumu tek bir kutucuk değil, gereksinim–tasarım–kanıt–kabul zinciridir.

Fonksiyonel gereksinimi, kalite niteliğini ve koşulu ayrı tut. 'API var' fonksiyonel bir kabiliyet olabilir; saniyede işlem kapasitesi, idempotency, şifreleme, hata görünürlüğü ve desteklenen sürüm kalite veya işletim koşuludur. Teklifteki ürün adı bu alt gereksinimleri karşılıyor mu, emin değilsek hangi test bunu gösterecek? Arven için her kriteri 'zorunlu', 'tercih' ve 'gelecek faz' diye ayır; ağırlıkları müşterinin onayladığı iş önceliğine göre ver. BoM satırı aynı ürün ailesinden diye mevcut lisans, servis veya destek hakkını var sayma. Ürün seçimi ile ticari hak ve operasyon kabiliyeti ayrı kanıt nesneleridir. Aynı anda tüm özellikleri aramak gereksiz kapsam şişirebilir; gerekli olmayan özelliği satın almanın ve işletmenin maliyeti de karara girer.

Birlikte çalışabilirlik birden fazla katmandan oluşur: protokol konuşmak, veri semantiğini anlamak, desteklenen sürüm kombinasyonunda çalışmak, istenen performansı sağlamak ve bir arıza anında ortak teşhis yapabilmek. Portalın ERP'ye JSON göndermesi, para birimi, stok kodu, işlem sırası ve hata tekrarlarının doğru yorumlandığını göstermez. Ürün belgeleri hangi özelliğin genel olarak bulunduğunu söyler; uyumluluk matrisi belirli sürüm/firmware/driver/topoloji sınırını gösterebilir; POC gerçek veri ve yükle davranışı ölçer; sözleşme ise destek yükümlülüğünü bağlar. Microsoft'un mimari tasarım spesifikasyonu, bileşen, veri akışı ve operasyon gereksinimlerinin izlenebilir tasarım kararlarına dönüşmesini vurgular. Bu yaklaşım Arven'de vendor bağımsız bir çalışma yöntemi olarak kullanılabilir, fakat Microsoft rehberi başka üreticiye destek garantisi vermez.

Uyumluluk doğrulamasında tek bir 'evet' hücresi yerine kaynaklı matris kullan: kaynak sistemin sürümü, hedef sistemin sürümü, bağlantı türü, kimlik yöntemi, sertifika/şifreleme, ağ sınırı, throughput, hata davranışı, destek durumu ve test tarihi. Sürüm destekleniyor ama kimlik akışı desteklenmiyor olabilir; ağ erişimi var ama veri modeli uyumsuz olabilir. Ayrıca tedarikçi onaylı entegrasyon ile müşteri tarafından geliştirilen özel kodu ayır. Özel kod işlevi açabilir fakat hata çözümü, güncelleme uyarlaması ve devir işi müşteride kalabilir. 'Çalıştı' sonucunun hangi veri kümesi ve test süresiyle elde edildiğini yaz. Yeni ürün sürümü veya API değişikliği, mimari kaydı ve kabul testini yeniden açmalıdır.

Portföy seçiminin başlangıç maliyeti kadar kullanım ufku da önemlidir. Ürünün satışa sunulma, genel destek, güvenlik güncellemesi, genişletilmiş destek ve tamamen hizmet dışına çıkma tarihlerinin anlamı üreticiye ve ürün ailesine göre değişir. 'EOL' her yerde aynı kesinti noktası değildir; resmî yaşam döngüsü politikasının hangi ürün ve sürüme uygulandığını oku. CISA'nın iletişim altyapısı rehberi, donanım, işletim sistemi ve yazılım için vendor EOL duyurularının izlenmesini ve yükseltmenin planlanmasını önerir. Bu, Arven için belirli bir tarih vermez; tarih ürün kaynağından alınmalıdır. NIST tedarik zinciri rehberi de ürünü satın alırken ve işletirken riskin yaşam döngüsü boyunca değerlendirilmesine çerçeve sunar. Teklif üç yıllık kullanım hedefliyorsa birinci yılın sonunda destekten çıkacak bileşen stratejik uyumsuzluk doğurabilir.

Roadmap ve duyuru ayrımını koru. Yol haritasındaki gelecek özellik bugünkü sözleşmesel kabiliyet değildir; henüz yayınlanmamış sürümün tarihini garanti gibi yazma. Gerekli bir özelliğin gelecekte gelmesi bekleniyorsa teklif ya geçerli alternatifle kurulmalı ya da açık koşul ve çıkış yolu göstermelidir. Donanım için yedek parça ve firmware, yazılım için güvenlik yaması ve API uyumu, bulut hizmeti için hizmet sürümü/duyuru politikası, entegrasyon için bağımlı uçların değişimi ayrı izlenir. Lisans yenilemesi de yaşam döngüsünün parçasıdır fakat ürün desteği ve kullanım hakkı eşanlamlı değildir. Arven'de tüm kritik bileşenlerin teklif başlangıcı, planlanan kullanım sonu, duyuru tarihi, beklenen yükseltme penceresi ve bütçe sahibi tek çizelgede görünmelidir.

Portföy karşılaştırmasını tek bir toplam puanla gizleme. Zorunlu kabul ölçütleri karşılanmıyorsa yüksek puanlı aday da uygun değildir. Önce eleme koşullarını yaz: kritik iş sonucu, güvenlik/veri şartı, desteklenen entegrasyon, lisans ve minimum destek ufku. Sonra uygun adayların maliyet, işletim yükü, geçiş riski, öğrenme ihtiyacı ve esneklik farklarını tart. Ağırlıkları satış ekibi değil müşteri karar sahipleri onaylamalıdır. Bir kriterin 'bilinmiyor' olması sıfır puan ya da kabul edilmiş uyum değildir; kanıt kapanışına bağlı koşullu durumdur. Üretici dokümanı, POC sonucu, sözleşme ve müşteri kararı farklı sütunlarda tutulur. Bu bölümde marka sıralaması veya gerçek fiyat önerisi yapılmaz; Arven öğretim senaryosunda nasıl karar verileceği gösterilir.

Arven karar sayfasını HLD/LLD, BoM, lisans ve TCO ile bağla. Örneğin portal API adaptörü için özel geliştirme gerekiyorsa BoM'da entegrasyon eforu, test ortamı, işletim sorumluluğu ve değişiklik bakım maliyeti görünmelidir. Vendor'ın sunduğu özellik müşterinin mevcut sözleşmesinde yoksa satın alma ve kullanım hakkı doğrulanır. Mevcut sürüm destek ufkuna yetişmiyorsa upgrade bağımlılığı tasarıma eklenir. Bir ürün çıkarıldığında hangi veri, konfigürasyon ve otomasyonların taşınması gerekeceği kaydedilir; bu konu sonraki çoklu vendor ve çıkış stratejisi dersinde derinleşir. Karar kaydı tarihli olmalı: bugünkü matrise dayalı öneri gelecekte ürün/sürüm değiştiğinde otomatik geçerli sayılmaz.