POC, Pilot ve Demo Yönetimi: Teknik Değerlendirmeyi Kazanmak

İyi Bir Pre-Sales Nasıl Olur? | Bölüm 10

Dört haftalık yoğun teknik çalışma. Her senaryo test edildi, her entegrasyon doğrulandı, sistem tam istenen şekilde çalışıyordu. Sonuç toplantısı iyiydi. Teknik ekip alkış aldı.

Üç gün sonra şu mail geldi: “Teknik değerlendirmeniz çok başarılıydı. Ancak bu çeyrekte bütçemiz kapandı. Süreci önümüzdeki yıla bırakıyoruz.”

Rakip vendor’ın sistemi altı ay sonra aynı müşteride devreye alındı.

Kaybedilen şey POC değildi. POC’a girmeden önce zaten kaybedilmişti.

Bu bölüm tam olarak bu noktayla başlıyor: Demo, POC ve pilot nedir, farkları nedir, ve her birinin yönetimi nasıl yapılır?

Demo, POC ve Pilot: Üç Farklı Oyun

Bu üç kavram pre-sales konuşmalarında birbirinin yerine kullanılır. Bu bir hatadır. Her biri farklı bir soruyu yanıtlar, farklı bir riski taşır ve farklı yönetilmelidir.

Demo şu soruyu yanıtlar: “Bu ürün var mı ve nasıl çalışıyor?” Genellikle 1–3 saatlik bir oturumdur. Müşteri tarafında teknik ve iş karar vericiler birlikte bulunabilir. Satış döngüsünün erken aşamasında yapılır. Amacı ilgi uyandırmak ve ürünün yeteneklerini göstermektir.

POC şu soruyu yanıtlar: “Bu ürün bizim spesifik ihtiyacımızı karşılar mı?” Genellikle 2–6 hafta sürer. Müşteri tarafında teknik ekip liderlik eder. Satış döngüsünün değerlendirme aşamasında yapılır. Amacı teknik uygunluğu kanıtlamaktır.

Pilot şu soruyu yanıtlar: “Bu ürün bizim üretim ortamımızda gerçekten çalışır mı?” Genellikle 1–3 ay sürer. Gerçek kullanıcılar ve gerçek verilerle yapılır. Teknik karar verilmiş, ticari karar hazırlanmaya başlanmış projelerde yapılır. Amacı operasyonel uyumu doğrulamaktır.

Bu üç aşama her zaman bu sırayla gelmez. Bazı müşteriler direkt POC ister. Bazı projelerde pilot atlanır. Ama her birinin hangi soruyu yanıtladığını bilmek, hangi aşamada ne yapman gerektiğini netleştirir.

[embed]

Demo: Sahne Ateşinin Riskleri

Demo hazırlığı çoğu zaman hafife alınır. “Sistemi biliyoruz, gösteririz” yaklaşımı yaygındır. Bu yaklaşım sürprizlere zemin hazırlar.

Demo günü konferans odasına geçtiniz. Müşteri tarafında üst yönetim de var. Sistemi açtınız. O an gördünüz: demo ortamındaki bir konfigürasyon farkı yüzünden göstereceğiniz özellik çalışmıyor.

Bu sahneyi yaşayan tek pre-sales değilsiniz. Demo ortamı ile test ortamı ile production ortamı birbirinden farklıdır. Bu farklar en kötü anlarda ortaya çıkar.

Demo başarısının üç koşulu vardır.

Birinci koşul: Scope’u daralt. Sisteminizin her özelliğini göstermek zorunda değilsiniz. Discovery sürecinde müşterinin öncelikli ihtiyaçlarını öğrendiniz. Demo’yu o ihtiyaçlara odaklayın. 45 dakikada güçlü olduğunuz üç senaryoyu göstermek, iki saatte her şeyi göstermeye çalışmaktan daha etkilidir.

İkinci koşul: Ortamı önceden test et. Demo günü “ilk çalıştırma” olmamalıdır. Demo environment’ı en az iki gün önce hazırlanmalı, tam senaryo akışı test edilmelidir. Veriler yüklenmiş, bağlantılar açık, akış kilitli olmalıdır.

Üçüncü koşul: Plan B hazır ol. Her demo’nun bir kurtarma planı olmalıdır. Sistem canlı bağlantı gerektiriyorsa ağ kesintisi senaryosuna hazırlıklı olun. Offline moda geçilebilecek bir ekran görüntüsü seti veya kayıtlı video segmenti hazır tutun. “Şu an gösteremesem de neden çalıştığını açıklayayım” moduna her an geçilebilmelidir.

Demo öncesinde müşteriyle kısa bir ön toplantı yapılmalıdır. Bu toplantıda şu sorular sorulur: Bugün en çok görmek istediğiniz iki veya üç senaryo nedir? Katılımcılar arasında teknik karar vericiler kimler olacak? Demo sonrasında hangi ekiple teknik tartışma yapmak istersiniz?

Bu sorular hem demo’yu kişiselleştirir hem de doğru beklentiyi kurar.

POC Plan: Başlamadan Önce Kazanmak

POC’un en tehlikeli anı başladığı an değildir. Sona erdiği andır.

Başarı kriterleri önceden yazılı olarak belirlenmemişse, POC sonunda müşteri “teknik olarak yeterliydi ama…” cümlesini kurabilir. Bu cümlenin sonu her şeye gelebilir: bütçe, öncelik, organizasyon değişikliği, rakip vendor’ın daha iyi fiyatı.

POC başlamadan önce imzalanması gereken bir POC Plan belgesi olmalıdır. Bu belge dört soruyu yanıtlamalıdır.

Başarı kriterleri nedir? POC sonunda “başarılı” diyebilmek için hangi teknik eşikler karşılanmalıdır? Bunlar sayısal olmalıdır. “Sistem hızlı çalışmalı” değil, “sistem 1000 eşzamanlı kullanıcı altında 2 saniyenin altında yanıt vermeli” olmalıdır.

Kapsam nedir? POC süresince test edilecek senaryolar listesi. Kapsam dışı olanlar da yazılmalıdır. Çünkü müşteri POC sürecinde yeni gereksinimler ekleyebilir. Kapsam dışı liste olmadan buna “hayır” demek zorlaşır.

Süre ve kaynak nedir? Kaç hafta sürecek? Her iki taraftan kimler dahil olacak? Haftalık ilerleme toplantısı olacak mı? Bu sorular önceden yanıtlanmazsa süreç belirsiz hale gelir.

Çıkış koşulu nedir? Başarı kriterleri karşılanırsa bir sonraki adım nedir? Satın alma kararı mı, pilot onayı mı, ticaret görüşmesi mi? Bu soruyu önceden sormak POC’u sonraki adıma bağlar. Yanıtsız bırakılan her POC “belirsiz başarı” olarak kapanır.

Bu belge hazırlanmadan POC başlatılmamalıdır.

POC Trap: Ücretsiz Danışmanlık Riski

POC trap, teknik ekibin müşteriye farkında olmadan ücretsiz danışmanlık hizmeti verdiği durumdur.

Belirtileri tanınabilirdir:

• POC kapsamı toplantıdan toplantıya genişler
• Müşteri teknik ekipten kapsam dışı konularda araştırma ister
• POC ortamı giderek production ortamına benzer hale gelir
• Teknik ekip müşterinin iç çalışmalarına dahil edilmeye başlanır
• Satın alma kararı sürekli ertelenir

Bu noktada olan şudur: Müşteri vendor’ın bilgisini ve zamanını kullanarak kendi teknik kapasitesini artırmaktadır. Satın alma niyeti zayıftır ya da yoktur.

Bu durumu erken tespit etmek için iki soru sorulur. Birincisi: POC Plan belgesi imzalandı mı ve kapsam değişti mi? İkincisi: Champion aktif mi yoksa süreci kendi iç çalışmalarına araç olarak mı kullanıyor?

Kapsam genişlediyse ve champion sessizleştiyse bir reset görüşmesi yapılmalıdır. Bu görüşmede orijinal POC Plan belgesine dönülür. Scope genişlemesi kabul edilmez. Bir sonraki adım netleştirilir. Müşteri esneklik göstermezse POC durdurulabilir.

Bu karar o an yanlış hissettiribilir. Uzun vadede doğru olan genellikle budur.

Pilot Yönetimi: Sınırlı Üretimden Tam Satışa

Pilot, teknik kararın verildiği ve ticari kararın hazırlandığı aşamadır.

Pilot’un amacı teknik kanıtı tamamlamak değildir. O iş POC’ta bitti. Pilot’un amacı, çözümün gerçek üretim koşullarında operasyonel olduğunu göstermek ve organizasyonun çözümle birlikte çalışmayı öğrenmesini sağlamaktır.

Bu ayrım kritiktir. Pilot sürecinde pre-sales’in rolü azalır, post-sales ve implementation ekibinin rolü artar. Pre-sales burada iki görev üstlenir.

Birinci görev: Pilot metriklerini takip et. Pilot sonunda hangi sonuçlar elde edildi? Bu sonuçlar finansal karar vericiler için nasıl çerçevelenir? Pilot raporu, ticari teklife dönüştürülecek son içeriktir. Bunu kimse sizin yerinize yazmaz.

İkinci görev: Executive sponsor iletişimini koru. Teknik ekip pilot detaylarıyla meşgulken, pre-sales karar verici seviyesindeki ilişkiyi canlı tutar. Pilot sonunda “ne öğrendik ve neden devam etmeliyiz” sorusuna hazır bir cevap oluşturulur.

Pilot bitmeden kapanış için beklemek yanlıştır. Pilot tamamlanmadan ticari görüşme başlatılabilir. “Pilot başarıyla ilerliyor, bu aşamada bütçe sürecini başlatmak ister misiniz?” sorusu doğal bir geçiştir.

Üç Katman: Junior, Mid-Level, Senior

Junior pre-sales için: Demo ve POC süreçlerinde güvenilirliğini teknik doğrulukla kur. Demo ortamını hazırla, senaryoları test et, sürpriz çıkmadığından emin ol. POC Plan belgesi yoksa POC’a girme. Kapsam genişlediğinde hemen kıdemli mühendisine bildir. Başarı kriterlerini anla ve bunların ölçülebilir olduğunu kontrol et.

Mid-level pre-sales için: Başarı kriterlerini müşteriyle birlikte yaz. POC’un kapsam dışı olanlarını belgele ve savun. Demo öncesinde ön toplantı yap. POC trap belirtilerini erken fark et ve reset görüşmesi başlat. Pilot sürecinde executive sponsor iletişimini koru. Pilot metriklerini ticari argümana dönüştür.

Senior pre-sales için: POC kararını satın alma kararıyla bağla. POC başlamadan önce champion’ın iç karar sürecini anla. Pilot’u ticari kapanışın hazırlığına dönüştür. Scope creep yaşandığında süreci durduracak otoriteyi kullan. Müşterinin bütçe takvimiyle POC ve pilot zamanlamasını hizala.

Bir Sahne Daha

Bir müşteri üç ay boyunca POC istedi. Her toplantıda kapsam genişledi. Başarı kriterleri yazılı değildi. Satın alma yetkisi olmayan bir teknik çalışan süreci yürütüyordu.

Reset görüşmesi yapıldı. “POC planımızı gözden geçirelim ve bir sonraki adımı netleştirelim” dendi. Müşteri “şu an önceliklerimiz değişti” dedi. POC durduruldu.

Altı ay sonra aynı müşteri geri döndü. Bu sefer bütçesi vardı, onayı vardı ve kararı alacak stakeholder’ları yanında getirmişti. POC üç haftada tamamlandı. Satın alma gerçekleşti.

Reset kararı o an yanlış hissettirdi. Sonuçta doğru çıktı.

POC Scope Guard

Bu bölümün skill’i: POC Scope Guard.

POC başlamadan önce başarı kriterleri belirler, kapsam sınırlarını çizer ve süreç boyunca scope drift izler. Haftalık ilerleme raporunu otomatik oluşturur ve POC trap belirtilerini işaretler.

github.com/diabolikss-debug/poc-scope-guard

POC, pilot ve demo pre-sales’in teknik yüzüdür. Ama kazanmak ya da kaybetmek bu yüzde gizli değildir. Bu süreçlere nasıl girdiğinizde ve nasıl çıktığınızda gizlidir.

Demo bir performanstır. POC bir sözleşmedir. Pilot bir geçiştir.

Her birini ne olduğunu bilerek yönetmek, teknik mükemmeliyetin ötesinde bir beceridir.

Spotify Podcast:

**POC, Pilot ve Demo Yönetimi: Teknik Değerlendirmeyi Kazanmak**