Demo, POC ve Pilot: Hangi Soruyu Kanıtlıyoruz?

Arven yöneticisi 'bir POC yapalım' dediğinde hemen ortam kurma. Önce kararın ne olduğunu sor: ERP entegrasyonunun üretim hacminde 15 dakikalık pencereye yetişmesi mi, geri dönüşün hedef RPO'yu karşılaması mı, yoksa kullanıcıların yeni hizmeti işletip işletemeyeceği mi? Bu üç soru aynı deneyle cevaplanmaz. Önceki görüşmede 100 kayıt için 4,8 dakikalık POC-07 v2 sonucu vardır; bu gözlem 1 milyon kayıt hedefini doğrulamaz. Bir demo algıyı düzeltmeye, dar bir POC teknik belirsizliği sınamaya, pilot ise sınırlı gerçek operasyonu değerlendirmeye yarayabilir. Etiket tek başına kabul standardı değildir; müşteriyle amaç, kapsam ve karar eşiği yazılır. Microsoft'un POC rehberi POC'u sınırlı kapsam ve olgunlukta ilk uygulama olarak tanımlar; amacı açık varsayımları sınamak, veri/ortam/success kriterini başlangıçta belirtmektir. Bu Power BI örneğinin yaklaşımını Arven'in altyapı kararına uyarlıyoruz, belirli ürüne özgü adımları taşımıyoruz. Yaklaşık 27 dakika anlatı, 29 dakika vaka çalışması ve 14 dakika kontrol planla. Ders çıktın, doğrulama türü ve karar hipotezi seçimini gerekçelendiren tek sayfalık Arven kartıdır.

Karar hipotezini 'ürün hızlıdır' gibi doğrulanamaz bir kanaat olarak yazma. 'Arven'in ERP iş yükü, kabul edilen veri hacmi ve eşzamanlı kullanıcı sayısıyla, ölçüm penceresinde en fazla 15 dakikada tamamlanırsa seçili mimari bir sonraki karar kapısına geçer' daha sınanabilir. Burada 15 dakika kurgusal vaka hedefidir; gerçek müşteride kaynak belgesi ve karar sahibiyle doğrulanmalıdır. Hipotezin dört parçası olsun: hangi iş kararı, hangi gözlenebilir ölçü, hangi test koşulu, başarısızlıkta hangi seçenek. İş sonucu bağlantısı kurulmadıysa teknik benchmark kazansa bile yatırım kararı açıklanamaz. Önceki dersin itiraz defterinden soru, claim ID, açık Gap ve müşteri teyit ihtiyacını al. Karar öncesi veri gizliliği, erişim, lisans, test ortamı ve operasyon sahibi de ölçümün sınırını belirler. Demo talebi aslında yöneticinin 'bu iş akışı kullanılabilir mi?' sorusu olabilir; POC talebi ise test edilmemiş kapasite varsayımına işaret edebilir. Dinleyicinin kendi kelimesiyle soruyu tekrar edip doğrula. Hiç karar etkilemeyen teknoloji gösterisi, müşterinin ve ekibin zamanını tüketir.

Demo, belirlenmiş bir senaryoda çözümün nasıl çalıştığını görünür kılar. İyi demo müşterinin rolü, iş akışı, giriş verisi, beklenen çıktı ve başarısızlık halinde gözlenecek davranışı önceden tanımlar. Örneğin Arven operasyon ekibine olay açma, eskalasyon ve rapor görme akışı gösterilebilir. Demo, üretim ölçeğinde performans veya sözleşme garantisi kanıtlamaz. POC dar bir teknik hipotezi gerçekçi ama sınırlı koşulda test eder: veri hacmi, eşzamanlılık, altyapı konfigürasyonu, izleme ve hata senaryosu yazılır. Microsoft Learn, küçük veri kümesinden performans ve veri kalitesinin güvenle genellenemeyeceğini açıkça uyarır; ayrı sandbox ortamı ve önceden başarı/başarısızlık eşiği önerir. Bu uyarı Arven'in 100 kayıt POC sonucunu yorumlarken doğrudan önemlidir. POC başarılı olsa bile veri koruma, lisans hakkı, destek kapsamı ve operasyonel hazır olma ayrı kapılardır. Deneyin başlığını 'başarılı POC' koymak yerine ölçümü, sürümü ve sınırı kaydet. Gözlem yoksa iddia doğrulanmış değildir.

Pilot, sınırları belirlenmiş bir kullanıcı veya iş alanında uçtan uca çalışma ve işletim davranışını izler. AWS'nin pilot rehberi teknik, iş ve son kullanıcıların dahil edilmesini, başarı ölçülerinin başlamadan tanımlanmasını, geri bildirim ve değişikliklerin kayıtla kapatılmasını anlatır. Rehberin kendi bağlamı göç ve müşteri deneyimi platformudur; Arven altyapısına ilkeleri uyarlanır, hizmete özgü ölçüleri kopyalanmaz. Arven için pilot grubu gerçek iş akışını temsil ederken kritik üretim hizmetini korumalıdır. Destek çağrısı, eğitim ihtiyacı, rollback denemesi, veri doğruluğu ve yük eğrisi gibi günlük işletim gözlemleri toplanır. Pilotun sınırı 20 kullanıcıysa 20 bin kullanıcı performansı kanıtlanmaz. Pilot, sözleşmesiz 7/24 hizmeti kendiliğinden sağlamaz. Birden fazla araç ardışık kullanılabilir: senaryo demosu ile yanlış anlama kapanır, POC ile ölçek riski sınanır, pilot ile işletim/devralma riski gözlenir. Her geçişte yeni karar ve maliyet onayı gerekir; ilk deneyin başarısı sonraki kapıları otomatik geçirmez.

İyi doğrulama çalışmasının başlangıcında müşterinin ve iç ekibin aynı deney sözleşmesini okuması gerekir. Sözleşmede amaç, hipotez, kapsam içi ve dışı, veri/erişim, ortam ve sürüm, ölçümler, kabul eşiği, roller, takvim, durdurma koşulu ve rapor teslimi yer alır. Arven ERP POC için 'gerçekçi veri' ifadesi yetmez; kayıt hacmi, veri karmaşıklığı, eşzamanlı iş sayısı, ölçümün başlangıç/bitiş olayı ve tekrar sayısı belirtilir. Veriye erişim yetkisi yoksa test planı başlamaz; kurgusal veya sentetik veri kullanılıyorsa üretim temsiliyeti sınırlanır. Kritik iş yükünü deney ortamında etkileyebilecek ağ veya depolama değişiklikleri için geri dönüş planı ve sorumlu gerekir. Başarı eşiği deneyden önce yazılır, sonuca göre geriye dönük gevşetilmez. Microsoft Learn'in POC planında amaç/kapsam, veri, ortam, demo ve başarı/başarısızlık eşiği ayrı maddelerdir; burada bu iskelet Arven'in kurumsal altyapı risklerine genişletilir. Eşikler müşteri şartnamesinden veya yetkili karardan türetilir; eğitim örneğindeki sayı gerçek taahhüt değildir.

Başarısızlık tanımı yalnız 'sunucu çöktü' değildir. Ölçü hedefi kaçarsa, kanıt eksik kalırsa, veri bütünlüğü bozulursa veya kabul edilen test koşulu sağlanmazsa sonuç başarısız, geçersiz ya da tekrar gerektirir olarak ayrılır. Örneğin test esnasında üretimden düşük veri hacmi kullanıldıysa sürenin iyi çıkması başarı değil kapsam dışı ölçümdür. Ağ kesintisi kontrolsüzse neden ve tekrar koşulu kaydedilir. Başarısız sonuç değerli veri sağlayabilir: mimariyi yeniden boyutlandırma, iş hedefini müzakere etme, alternatif çözüm veya no-bid. AWS pilot rehberinin kusur ve değişiklikleri olumlu bulgu olarak izleme yaklaşımı, 'sıfır öneri' beklentisinden daha gerçekçidir. İyi rapor yalnız ortalama süreyi değil aralığı, tekrar sayısını, anomaliyi ve sınırı gösterir. Seçilmiş tek koşunun ekran görüntüsü kanıt paketi değildir. Test yürütücüsü, müşteri gözlemcisi ve karar sahibi farklı rol olabilir; kimin sonucu onaylayacağı önceden yazılmalıdır. Ölçüm sırasında değişiklik yapıldıysa konfigürasyon ve sürüm yeni deney olarak kaydedilir; eski ve yeni değerler karıştırılmaz.

Doğrulama tamamlandığında raporu karar veren kişi için yaz. İlk satırda hangi karar hipotezinin sınandığı, sonuç ve geçerlilik sınırı bulunur. Ardından konfigürasyon, veri, ölçüm, başarısız denemeler, sapmalar ve açık riskler gelir. Demo için senaryo ile katılımcı geri bildirimi, POC için ölçüm kanıtı, pilot için teknik veri ve kullanıcı/operasyon geri bildirimi ayrı tutulur. Sonuç 'geçti' ise bile hangi kapsamda geçtiğini yaz. 'Kısmen geçti' ise hangi alt koşulların kapandığını, hangilerinin yeni çalışma istediğini göster. Müşteri kararını teknik raporun sonuna gizleme; alternatif A/B, maliyet ve takvim etkisi, owner ve onay makamını tabloya koy. POC sonucu BoM kapasitesini değiştirirse teklif fiyatı, HLD ve risk defteri yeniden gözden geçirilir. Pilotta destek ekibi hazır değilse ürün performansı iyi olsa dahi operasyonel go ertelenebilir. Sonraki ders başarı ölçütlerini ve POC planını derinleştirecek; burada araç seçimini ve karar hipotezini kurmuş olmalısın.

Bir doğrulama isteği sınırsız ücretsiz danışmanlık yetkisi değildir. Kapsam, süre, harcama, müşteri kaynakları, veri sorumluluğu, çıktı kullanım hakkı ve sonraki karar kapısı iç onayla netleşir. Bu ticari sözleşme tavsiyesi değil, pre-sales işinin kontrollü yönetimidir. Arven 'POC'dan sonra bütün entegrasyonu da bitirin' derse ilk onaylanan hipotez ve teslimatı göster; yeni isteğin hedef, maliyet, takvim ve risk etkisini çıkar. Müşteri baskısı var diye belirsiz çalışmayı ücretsiz vaat etme, ama gerçek karar sorusunu da gereksiz bürokrasiyle boğma. En küçük geçerli deney, riskin en yüksek kısmını güvenli ve ölçülebilir biçimde sınar. Microsoft POC rehberi sınırlı kapsam/olgunluk uyarısı yapar; AWS pilot rehberi pilot sonrası değişikliklerin takip edilmesini ve paydaş onayıyla sonraki adıma geçilmesini önerir. Bu kaynaklardan genel ilkeleri al, Arven için bağlayıcı müşteri şartını ve yetki zincirini ayrıca doğrula. Deney sonunda üç sonuç mümkündür: koşullu ilerle, deneyi değiştirip tekrar et veya dur. Her biri kanıtlı karar olabilir.