Arven Bütünleşik Karar Kurulu

Arven Holding sürekli vakasının son oturumunda teknik sunumu bir karar kuruluna taşıyacaksın. Bu bir müşteri sözleşmesi simülasyonu değil, eğitim için yapılandırılmış karar provasıdır. Açıklanmış Arven çekirdeği yaklaşık çalışan sayısı, İstanbul birincil veri merkezi, Ankara DR lokasyonu, VMware tabanlı sanallaştırma, yaklaşık 5–6 yıllık altyapı, Veeam kullanımı ve modernizasyon değerlendirmesiyle sınırlıdır. Önceki derslerin sabah raporu gecikmesi ve ay sonu veri artışı yalnız etiketlenmiş alıştırma varsayımlarıdır. Kurulun sorusu 'hangi ürünü alıyoruz?' diye başlamaz; 'hangi iş sonucunu hangi kanıtla ve hangi açık koşullarla seçebiliriz?' diye başlar. GOV.UK discovery rehberi sunulan çözümün arkasındaki problemi yeniden tanımlamayı ve varsayımları parçalamayı önerir. Kurul bu yöntemi kamu hizmeti prosedürü olarak değil, erken teknoloji sıçramasını yakalayan soru disiplini olarak kullanır. 30 dakika karar hazırlığı, 35 dakika kurul provası ve 15 dakika öz denetim planla. Çıktın tek sürümlü, izlenebilir bir Arven karar paketidir.

Kurulda en az dört rol konuşsun: iş sonucu sahibi, teknik mimar, operasyon/DR temsilcisi ve ticari karar sahibi. Aynı kişinin tüm kararları onayladığını varsayma. İş rolü ölçülen etki ve kabul sınırını, mimar alternatif ve kanıtı, operasyon temsilcisi işletim ve kurtarma koşullarını, ticari taraf maliyet ve sözleşme sınırını sorgular. Önce sunum tarihindeki bilgi kesitini dondur: hangi müşteri notu, hangi gereksinim sürümü, hangi ADR, HLD, BoM, TCO ve POC raporu geçerli? Farklı ekipler farklı sürüm taşıyorsa karar o anda durur; eski belgeler silinmez, geçerli sürüm ve değişiklik gerekçesi belirlenir. Karar paketi başında KNOWN, ASSUMED, UNKNOWN ve TBD için küçük bir durum çizelgesi bulunsun. KNOWN kaynağa bağlı açıklanmış bilgi, ASSUMED sınanacak hipotez, UNKNOWN henüz elde edilmeyen olgu, TBD ise owner ve tarihle açılmış doğrulama işidir. 'Ankara DR var' KNOWN olabilir; RPO, restore başarısı ve tatbikat sonucu UNKNOWN kalır. Bu ayrım yapıldığında kurul, etkileyici bir slaytla gizlenen eksik kanıtı fark eder.

Kurulun ana görünümü tek bir ürün matrisi değil, iş hedefinden karara uzanan iki yönlü izdir: müşteri sözü, kaynak ve yetki → aday gereksinim → risk/varsayım → mimari alternatif → HLD/BoM/lisans/TCO → POC veya pilot kanıtı → teklif ve karar. NASA Systems Engineering Handbook gereksinimlerin üst ihtiyaçla izlenebilir tutulması ve varsayımların doğrulanması için genel sistem mühendisliği çerçevesi sunar. NASA'nın görev süreçleri Arven'in satın alma şartı değildir; buradaki uygulama açıklanabilir karar izidir. Her satırda öne ve arkaya gidilebilmeli: pahalı BoM satırının hangi ölçüye karşılık geldiği, kritik iş hedefinin hangi tasarım ve testle karşılandığı görülebilmeli. İz kırılıyorsa satırı kesin vaat olarak kullanma. Kurgusal rapor senaryosunda ek kapasite, uygulama/veri akışı iyileştirmesi ve iş zamanlaması değişimi üç alternatif olabilir. Bunlar onaylı seçenek değil, test edilecek açıklamalardır. Aynı başarı ölçüsü, aynı maliyet dönemi ve aynı risk ölçeğiyle kıyasla. Bir alternatifin yalnız güçlü yönünü diğerinin yalnız maliyetini sunmak karşılaştırma değildir.

Kurul soruları özellikle planın zayıf yerine yönelmeli. 'POC hızlı çıktı' dendiğinde kaç koşu, hangi veri, hangi ortam, hangi baseline, hangi geçersiz koşu ve hangi müşteri gözlemcisi olduğunu sor. 'Üretime hazır' dendiğinde güvenlik, izleme, rollback, operasyon runbook'u, yedek geri yükleme ve DR kabulünü ayır. 'Daha ucuz' dendiğinde aynı dönem ve kapsamda lisans, destek, geçiş ve çift işletim maliyetinin yer alıp almadığını denetle. 'Compliant' dendiğinde iddianın hangi şartname satırı ve kanıt belgesiyle desteklendiğini göster. Microsoft Learn ADR rehberi bağlamı, alternatifleri, gerekçeyi ve değişen kararların sürümünü açık tutmayı önerir. ADR bir satış sloganı değil, kurulun 'neden bu seçenek?' sorusuna denetlenebilir yanıttır. Bir kanıt yalnız sentetik POC ortamında üretildiyse üretim ölçeğine genelleme yapma. POC başarılı olduğu halde lisans hakkı belirsiz kalabilir. Kritik boşluk için yeni keşif, kontrollü POC, ticari açıklama veya no-bid seçeneklerini masaya koy.

Kurulun dört meşru sonucu olsun: kanıtla ilerle, ölçülü koşulla ilerle, ek doğrulamaya dön veya dur/no-bid. Her sonuç aynı formatta yazılır: karar tarihi ve yetkilisi, değerlendirilen sürüm, seçilen veya reddedilen alternatif, gerekçe, kabul edilen kanıt, açık risk, koşul ownerı ve kapanış tarihi. 'Şartla ilerle' açık şartların kaydı olmadan kullanılmaz; 'ilerle' ise kesin satın alma emri değildir. Müşteri iş hedefini onaylamamışsa iç mimari öneri dış müşteri kabulüne dönüşmez. Satış fiyatı onaylanmış olsa bile teknik performans garantisi ayrı kanıt ve sözleşme sınırı ister. Uzlaşı yoksa azınlık itirazını kaydet. Operasyon temsilcisi DR testini yetersiz buluyorsa bu itirazı ortalama puan içinde eritme; etkiyi, alternatif telafiyi ve yetkili risk kabulünü göster. Karar sahibinin yokluğu da sonuçtur: TBD ve toplantı sonrası doğrulama işi açılır. Öğrenci kurulu 'mutlaka evet' sonucuna zorlamamalı; yeterli veri yoksa bilinçli bekleme iyi pre-sales davranışıdır.

Kurul sırasında alıştırma için ay sonu yükünün sabah raporundan daha yüksek olduğu söylensin. Bu açıklama yeni kanonik Arven gerçeği değildir; sözlü senaryo girdisidir. Önce kaynak ve yetkiyi doğrula. Teyit gelirse gereksinim, POC veri profili, ADR seçeneği, HLD, BoM, lisans, TCO, compliance ve teklif satırlarını etki taramasına al. Bazı satırlar etkilenmeyebilir, fakat 'etkilenmiyor' da gerekçeli kaydedilir. Eski sürümü sessizce değiştirme; v1→v2 farkı ve iletişim tarihi yaz. Yeni yük POC kapsamının dışındaysa önceki test başarısını yeni kapsam için yeniden etiketle. Maliyet artışı yalnız BoM düzeltmesi değil, bid/no-bid ve müşteri önceliği sorusu olabilir. Microsoft ADR yaklaşımındaki karar sürümü, kurulun daha sonra yeni bilgiyle farklı sonuç vermesini anlaşılır kılar. Karar tutanağında açık risk ownerı ve gerekli kanıt yoksa uygulama ekibi bilinmeyeni tasarım kararı sanabilir. Müşteriye gönderilecek özet, onaylanmış bilgiyle hipotezi ayrı tutmalı ve taahhüt sınırını açık yazmalıdır.

Kurul bitince tek sayfalık yönetici özeti ve ayrıntı eklerini üret. Özette karar sorusu, önerilen sonuç, en güçlü iki kanıt, en büyük iki belirsizlik, maliyet aralığı ve sonraki kapı yer alır. Eklerde sürümlü gereksinim defteri, ADR, HLD, BoM/TCO, compliance matrix, POC raporu, risk ve değişiklik kayıtları bulunur. Bir özette 'POC geçti' yazıyorsa hangi ölçü, ortam ve temsil sınırıyla geçtiği ayrıntıda izlenebilmeli. Yetkili müşteri kararı henüz alınmadıysa bunu 'onay bekliyor' diye yaz; iç kurul önerisini müşteri kabulü gibi sunma. Devir alan ekip her açık şartın owner, tarih, test yöntemi ve başarısızlık hâlindeki kararını bulabilmeli. Kişiye özel vaka kilitleri ileride uygulanırsa kilitli bilgi tarayıcıya gizlenmiş payload olarak gönderilmemeli; sunucu/veritabanı yetkisiyle açılmalıdır. Bu modül yalnız açıklanmış olgular ve etiketli kurgusal örnekler kullanır. Böylece öğrenciye erken verilmeyen bilgiyi yanlışlıkla çözüm içinde sızdırmaz.

Öz değerlendirmede dört düzeyi kontrol et. İlk düzey kaynak disiplini: kanonik olgu, müşteri sözü, senaryo varsayımı ve bilinmeyen ayrı mı? İkinci düzey karar izi: iş sonucu, gereksinim, mimari seçenek, maliyet, test ve teklif arasında bağ var mı? Üçüncü düzey teknik dürüstlük: POC'nin sınırı, DR ve lisans boşlukları, istisnalar ve koşullu sözler açık mı? Dördüncü düzey kurul davranışı: karşı itiraz duyuluyor mu, no-bid veya bilgi isteği meşru seçenek olarak kalıyor mu, yetkili imza doğru kişide mi? Rubric her ölçütte sıfır, bir veya iki puan verir; sekiz puan ancak dört ölçütte de iki puanla alınır. Düşük puan öğrenciye hangi kanıtı yeniden toplaması gerektiğini göstermelidir, ürün tercihinin yanlışlığını otomatik söylemez. On soruluk değerlendirme tanım ezberini değil; sınırlı olgudan çıkarım yapmayı, kanıt sınırını, değişiklik etkisini ve koşullu kararı seçmeyi ölçer. Gerçek müşteri toplantısında bu eğitim puanı sözleşmesel yetki yerine geçmez.