BoM, Ticari Koşullar ve Yönetici Teklifi

Capstone’un üçüncü dersinde Arven Holding için teknik kararı yönetici teklifinin ekonomik diline taşıyacaksın. İlk ders kaynaklı Discovery ve REQ kaydını, ikinci ders ölçüm planı, senaryo hassasiyeti, alternatif mimari ve koşullu ADR/HLD iskeletini kurdu. Şimdi bunlardan bir BoM ve maliyet modeli tasarlarsın; gerçek adet, SKU, lisans hakkı veya fiyat uydurmazsın. Arven’in kanonik açıklamasında yaklaşık 1.200 çalışan, İstanbul birincil DC, Ankara DR lokasyonu, VMware, Veeam, yaşlanan altyapı ve modernizasyon değerlendirmesi vardır. İş yükü, kapasite, RPO/RTO, bütçe ve mevcut sözleşmeler açıklanmadığı için tüm sayısal BoM örnekleri sentetik alıştırmadır. Ders çıktısı ürün kataloğu değil; her satırı REQ, sizing varsayımı, ADR/HLD, test koşulu ve ticari kanıta bağlanan sürümlü BoM/TCO paketi ile bir sayfalık yönetici teklifidir. Yaklaşık 25 dakika BoM izi, 30 dakika maliyet/uyum, 20 dakika yönetici anlatısı ve 10 dakika kontrol planla. Microsoft maliyet optimizasyonu rehberi altyapı, destek ve uygulama dahil toplam maliyet modeli ile iş ihtiyacı arasında ilişki kurmayı önerir; bu Arven’e bir bulut veya vendor seçtirmez.

BoM satırlarını işlevsel gruplar halinde kur: compute, storage, ağ/SAN, yedek/DR, güvenlik/izleme, yazılım ve destek, geçiş/kurulum hizmeti. Her satırın ID’si, tanımı, hangi mimari alternatife ait olduğu, ölçü birimi, adet belirleme formülü, kaynak veri, revizyonu, lisans/bakım bağı ve sahibi olsun. Adet henüz ölçülmediyse boş hücreyi sıfır sayma; UNKNOWN veya aralık/taslak statüsü kullan. 'İki host daha' gibi alıştırma sayısı gerçek müşteri teklifine taşınmamalı. BoM’da depolama brüt ve kullanılabilir kapasite, yedek saklama, arıza toleransı ve büyüme aynı tabloda izlenir; çift sayımı önlemek için hangi veri setinin hangi kopyada tutulduğunu göster. Alternatifler farklı kapsam içeriyorsa aynı tablo başlığı altında fiyat farkı üretme. Bir SKU’yu seçmeden önce teknik uyumluluk, destek yaşam döngüsü, yerel politika, lisans metriği ve tedarik koşulu doğrulanmalıdır. Satırın iş ölçüsüyle bağı yoksa neden alındığını sorgula; ters yönde kritik REQ için BoM ve doğrulama satırı yoksa kapsam açığı yaz.

İki alternatifin maliyetini karşılaştırırken dönem, para birimi, vergiler, destek düzeyi, amortisman yaklaşımı, kur varsayımı ve dahil edilen hizmetler aynı olmalıdır. TCO yalnız ilk alım değildir: lisans yenilemesi, bakım, güç/alan, işletim personeli, eğitim, veri taşıma, paralel çalışma, POC, izleme ve DR tatbikatları değişik senaryolarda önemli olabilir. Arven’in gerçek bütçesi ve fiyat listesi bilinmiyor; bu ders oran ya da rakam vaat etmez. Microsoft maliyet optimizasyonu ilkeleri teknoloji, lisans, eğitim, operasyon ve değişim yönetimi giderlerini toplam modele almayı, iş gereksinimini kesen sahte tasarruftan kaçınmayı anlatır. Maliyet tablosunda varsayımın kaynağını ve güven düzeyini ekle. Eksik fiyat bir alternatife sıfır maliyet avantajı sağlamaz. A seçeneğinin üç yıllık lisansı varken B’nin yalnız ilk yıl ürün bedelini kıyaslama; aynı döneme getiremediğinde sonuç Inconclusive kalır. Capstone aracı fiyat teklifi üretmez; doğru teklif için hangi veri ve onayın gerektiğini öğretir.

Lisans/uyum alanı teknik sunumdan ayrı teyit ister. VMware ve Veeam kullanımı kanonik olarak bilinse de sürüm, SKU, mevcut hak, destek bitişi, DR kullanım hakkı, çekirdek/socket metriği veya yeni platformda taşınabilirlik bilinmiyor. 'Zaten lisanslı' veya 'DR ücretsiz' cümlesi teklifin en pahalı hatalarından olabilir. Lisans satırında yetkili sözleşme/ürün belgesi, kullanım topolojisi, normal ve arıza senaryosu, dönem, metrik, hak/eksik hak, kimin doğrulayacağı ve ne zamana kadar doğrulayacağı yer alır. Uygunluk matrisi her teknik şartın Compliant, Conditional, Gap veya Inconclusive durumunu kanıt belgesiyle taşır. Açık Gap’i küçük dipnotta saklama; teklif kapsamını, fiyatı veya no-bid kararını etkileyebilir. Eşit TCO görünse bile lisans riski farklıysa karar koşulu yazılır. Yeni bilgi geldiğinde BoM, TCO, uyum ve teklif aynı revizyonda taranır; eski sürüm saklanır, geçerlilik durumu güncellenir.

Yönetici teklifinin ilk sayfası ürün listesiyle değil Arven’in teyit ettiği iş sorunu, çözülürse oluşacak değer, seçenekler ve önerinin kanıt sınırıyla başlar. Yönetici için beş soru nettir: neden şimdi, hangi iş sonucunu etkiliyor, hangi seçenekler değerlendirildi, bunun maliyet ve riski ne, bugün hangi kararı isteyebiliriz? Arven’de 'neden şimdi' kısmı yalnız modernizasyon değerlendirmesine dayanabilir; çoktan teyit edilmiş bir performans krizi veya bütçe deadline’ı uydurulmaz. GOV.UK yarar ölçüm rehberi Discovery sırasında problemin ve mevcut maliyetin anlaşılmasını, daha sonra yararın ölçülmesini önerir. Bunu Arven için genel anlatı disiplini olarak kullan: fayda hipotezini ölçüm ve owner ile bağla. Teklifte üç alternatifin aynı kriterle kısa özeti, koşullu tercih, POC ihtiyacı, açık RTO/RPO ve lisans belirsizliği bulunur. 'En iyi teknoloji' sloganı yerine hangi müşteri ihtiyacının hangi kanıtla karşılanacağı yazılır. Yöneticinin zamanını korurken kritik itirazı silme; riskin karar etkisini kısa ve açık söyle.

Teklifin teknik eki ile yönetici özeti aynı sürümden beslenmelidir. Yönetici özeti 'Ankara DR hazır' derken HLD 'failback planı TBD' diyorsa belge kendi kendini çürütür. Satır bazında iş amacı, REQ, mimari alternatif, BoM/TCO, POC/test, risk/varsayım, kapsam/istisna ve kabul ownerı arasında bağlantı kur. Teknik taahhüt ancak doğrulanmış müşteri hedefi ve testle savunulabilir; sentetik sınıf çalışması garanti değildir. Bir teklif seçeneği ancak koşullu öneri ise bunu başlıkta ve karar isteğinde belirt. 'Sınırlı POC’a onay', 'ölçüm/veri paylaşımına onay' veya 'eksik lisans doğrulaması sonrası fiyat revizyonu' birbirinden farklı yönetici kararlarıdır. Müşteri satın alma kabulünü iç teknik kurulun önerisiyle karıştırma. Eğer kritik şartname maddesi Gap ve giderilemiyorsa no-bid veya kapsamı yeniden tanımlama da dürüst seçeneklerdir. Yönetici sunumunda karşı görüşün sahibi ve kapanış planı tek satırda görünebilir; ayrıntılı kanıt eki onu destekler.

Teklif hazır gibi görünürken yeni veri gelebilir: eğitim senaryosunda Arven’in iş sahibi büyüme beklentisini veya saklama süresini açıklasın. Bu yeni değer gerçek müşteri olgusu değil, capstone değişiklik provasıdır. Önce bilgi kaynağını ve onayını kaydet; ardından REQ, sizing, ADR/HLD, BoM/TCO, lisans, POC ve teklif sayfasındaki etkiyi tararsın. Önceki v1’i silme; v2’de hangi varsayımın değiştiği, hangi satırın geçersiz olduğu ve kararın yeniden açılıp açılmadığı gösterilir. Fiyat delta’sı tek başına yeterli değildir; yeni büyüme bir teknik alternatifin uygulanabilirliğini veya DR kapasitesini bozabilir. Tam tersine değişikliğin yalnız maliyet satırını etkilediği kanıtlanabiliyorsa bunu da gerekçeli yaz. Microsoft ADR rehberi karar değişiminde yeni kaydın eskiyi izlemesini önerir; maliyet optimizasyonu rehberi de tasarım değişikliğinin finansal etkisinin iletilmesini vurgular. Bu ikisini sürümlü teklif disiplinine dönüştürürüz.

Dördüncü dersteki teknik savunmaya hazırlanmak için teklifin zayıf yerini sen sorgula. 'Bu host sayısı nereden geldi?', 'Yedek restore kanıtı var mı?', 'DR lisansı hak ediyor mu?', 'B seçeneği niçin daha pahalı?', 'Sözleşmeye hangi SLA girebilir?', 'Müşteri hedefi değişirse ne olur?' sorularına kaynak veya açık TBD ile yanıt ver. Cevap yoksa komiteye sahte güven verme. Savunma paketinde güncel charter, REQ register, risk/varsayım defteri, sizing veri talepleri, ADR/HLD, BoM/TCO, uyum istisnaları, yönetici özeti ve POC kararı aynı bilgi kesitini taşımalıdır. Bağımsız gözden geçiren biri v2 fiyatının hangi yeni gereksinimle değiştiğini ileri ve geri izleyebilmelidir. Çıktı öğrenci alıştırmasıdır; dış müşteri için bağlayıcı teklif veya onaylı fiyat değildir. Teslim sonunda teknik, operasyon ve ticari itirazları ayrı kaydet; sonraki derste bu itirazların kapatılma veya koşullu kabul şekli rubric ile değerlendirilecek.