Satıcının senaryosu mu, sizin senaryonuz mu? ERP demo değerlendirme rehberi

Çoğu ERP demosu aynı senaryoyla ilerler: birkaç düzine temiz ürün, sorunsuz davranan birkaç müşteri, hatasız işleyen basit işlemler. Satıcı ekibi kendi hazırladığı akışta gezdirir, işlevleri en iyi göründüğü sırayla gösterir ve karar verici kendi işinin gerçek karmaşıklığını — istisnaları, iade süreçlerini, çoklu depo veya çoklu para birimi işlemlerini — hiç görmeden toplantıdan çıkar. Panorama Consulting'in ERP demo değerlendirmesine dair yayınladığı rehber bu durumu net koyuyor: satıcı hazır senaryodan çıkmayı reddediyorsa bu bir kırmızı bayrak sayılmalı. Doğru soru "yazılım neler yapabiliyor" değil, "bu yazılım benim işimin şu belirli anındaki şu belirli sorununu nasıl çözüyor" sorusu.

Bu yazı, demoyu satıcının senaryosundan çıkarıp karar vericinin senaryosuna çekmenin somut yollarını ve demo notlarını karşılaştırılabilir bir karara dönüştürecek çerçeveyi ele alıyor.

Demo neden çoğu zaman satıcının lehine kurulur

Demo ortamı satış sürecinin bir parçasıdır ve bu doğal bir çıkar çatışması yaratır: satıcının hedefi ürünü en iyi ışıkta göstermek, alıcının hedefiyse ürünün kendi iş modeline uyup uymadığını görmektir. Bu iki hedef aynı toplantıda otomatik olarak örtüşmez. Standart demo verisi genelde ürünün en güçlü olduğu senaryolara göre kurgulanır; zor entegrasyonlar, yavaş raporlar veya kullanıcı arayüzünün karmaşıklaştığı ekranlar akışın dışında bırakılır. Satış mühendisi de günde birkaç kez aynı akışı tekrarladığı için sisteme alıcıdan çok daha hakimdir — bu fark, alıcının gözünde gerçekte olduğundan daha akıcı bir deneyim izlenimi bırakabilir.

Bunun kötü niyetli olması gerekmiyor; her satıcı kendi ürününü en iyi durumda göstermek ister ve bu satış sürecinin doğal bir parçasıdır. Sorun, alıcı tarafın bu eğilimi hesaba katmadan demoyu tek bilgi kaynağı olarak değerlendirmesinde başlıyor.

Kendi demo senaryonuzu nasıl hazırlarsınız

Demoyu satıcının standart akışından çıkarmanın en etkili yolu, toplantıdan önce yazılı bir senaryo göndermek. Bu senaryo gerçek iş akışlarınızı, gerçek ürün/hizmet karmasını ve — mümkünse — gerçek istisna durumlarını içermeli:

• Bir siparişin girişten faturaya kadar geçtiği tam adım dizisi, sizin gerçek ürün kodlarınız ve fiyatlandırma kurallarınızla.
• Sık karşılaşılan bir istisna: iade, kısmi teslimat, fiyat değişikliği, döviz kuru farkı gibi.
• Farklı departmanların aynı veriye eriştiği bir an — örneğin satış temsilcisinin girdiği bir sipariş depoda ve muhasebede nasıl görünüyor.
• Raporlama ihtiyacınızın en az biri: yönetim kurulu toplantısında sorulan tipte bir soru, canlı olarak sistemden üretilebiliyor mu.

Senaryoyu satıcıya toplantıdan en az birkaç gün önce iletmek, satış ekibinin kendi standart demosunu bu senaryoya göre hazırlamasını zorunlu kılar. Bir satıcı bu senaryoyu görmezden gelip yine kendi standart akışına dönüyorsa, bu davranış demo sırasında değil, demo öncesinde bile bir sinyal.

Demo sırasında sorulacak sorular

Demo ilerlerken ürünün ne yaptığından çok, nasıl yaptığına odaklanan sorular gerçek bilgiyi ortaya çıkarır:

• Bu ekran kaç tıklamayla açıldı? Aynı işlemi günde onlarca kez tekrarlayan bir kullanıcı için bu adım sayısı gerçekçi mi?
• Az önce gösterdiğiniz rapor, standart mı yoksa özel olarak mı hazırlandı? Aynı raporu farklı bir kriterle şimdi, canlı olarak üretebilir misiniz?
• Bu işlemi yaparken kaç farklı modül veya ekran arasında geçiş yapıldı?
• Hata durumunda kullanıcı ne görüyor — anlaşılır bir uyarı mı, yoksa teknik bir hata kodu mu?
• Bu özelliği görmek isteyen kaç müşteriniz gerçekten kullanıyor, yoksa çoğunlukla demo amaçlı mı gösteriliyor?

Satıcının demoyu son sıraya bırakma isteğine veya toplantı ajandasını genişletip kendi öne çıkan özelliklerine kayma girişimine izin vermemek de değerlendirme sürecinin kontrolünü elde tutmanın bir parçası. Aynı şekilde demoya işi fiilen kullanacak kişilerin (sadece BT değil, satış, depo, muhasebe temsilcileri) katılması, "bu ekranı ben günlük işimde nasıl kullanırım" sorusunun toplantı sırasında sorulmasını sağlar.

Referans görüşmesi: demoyu doğrulamanın ikinci katmanı

Demo tek başına yeterli bir doğrulama katmanı değil; satıcının seçtiği referans müşteriler de genelde en memnun olanlardır. Buna rağmen referans görüşmesi atlanmamalı — sadece görüşmenin nasıl yapıldığı fark yaratıyor. Satıcının sunduğu referans listesindeki isimlerle görüşmek yerine, mümkünse aynı sektörde ve benzer ölçekte, kendi ağınızdan bağımsız bir referansa ulaşmak daha güvenilir bilgi verir; bu her zaman mümkün olmasa da, en azından satıcının önerdiği referansa demo sırasında sorulmayan somut sorular yöneltilmeli: kurulum ne kadar sürdü, ilk üç ayda hangi süreç beklenenden zor çıktı, destek talebine ortalama yanıt süresi ne kadar. Referans, demo sırasında "elbette yapabiliriz" denilen bir özelliğin gerçekte nasıl çalıştığını doğrulayan tek bağımsız kaynak; demo notlarında işaretlenen belirsiz maddeler referans görüşmesinde tek tek sorulmalı.

Referans görüşmesi ayrıca demoda gösterilmeyen bir şeyi de ortaya çıkarır: destek modelinin gerçek işleyişi. Bir özelliğin var olması ile o özelliğe ihtiyaç duyulduğunda destek ekibine ne kadar sürede ulaşılabildiği aynı şey değil; bu fark genelde ancak canlı kullanan bir referansla konuşulduğunda görülür.

Demo notlarını karar tablosuna çevirmek

Birden fazla satıcı demosu izlendiğinde izlenimler hızla birbirine karışır. Her demo sonrası aynı kritere göre puanlanan bir tablo, karar aşamasında öznel "iyi hissettirdi" değerlendirmesinin önüne geçer:

Tablo tek başına kararı vermez ama farklı satıcıları aynı kritere göre karşılaştırmayı mümkün kılar; toplantıdan hemen sonra, izlenim tazeyken doldurulmalı — bir hafta sonra hangi satıcının hangi soruya nasıl yanıt verdiği genelde hatırlanmaz.

Sık yapılan değerlendirme hataları

• Tek kişiyle demo izlemek. BT yöneticisi tek başına katıldığında, günlük kullanıcıların fark edeceği pratik sorunlar gözden kaçabilir.
• Satıcının önerdiği sırayı kabul etmek. Hangi satıcının önce, hangisinin son demo yapacağına alıcı karar vermeli; son sırada demo yapan satıcı genelde önceki demoların eksiklerine göre kendi sunumunu ayarlama avantajı elde eder.
• Fiyatı demo aşamasında konuşmamak. Fonksiyonel değerlendirme bitmeden fiyat teklifi istenirse, satıcı teklifini "önce ikna et, sonra pazarlık et" mantığıyla erteleyebilir; net kapsam olmadan alınan erken fiyat teklifleri genelde sonradan değişir.
• Raporlamayı sona bırakmak veya hiç sormamak. Günlük işlem ekranları genelde iyi görünür; asıl fark raporlama ve entegrasyon tarafında ortaya çıkar.
• Demo sonrası notları hemen yazmamak. İki-üç satıcı demosu art arda izlendiğinde detaylar hızla birbirine karışır.
• Veri taşıma sürecini demoda hiç konuşmamak. Mevcut sistemdeki veri yeni ürüne nasıl aktarılacak sorusu genelde kurulum aşamasına bırakılır; oysa aktarımın ne kadar süreceği ve hangi veri temizliğinin önceden gerektiği demo aşamasında sorulabilecek bir soru.
• Mobil veya uzak erişim senaryosunu atlamak. Saha ekibi, depo veya şubeler arası kullanım varsa, bu senaryo masaüstü demosunun ayrı ve mutlaka istenmesi gereken bir parçası olmalı.

Türkiye'deki işletmeler için pratik çıkarım

Demo değerlendirmesinin ağırlığı, ürünün kurulum modeline göre de değişir. Yerli bulut tabanlı ürünlerde (örneğin Qera ERP veya Birasyo ERP) demo genelde satıcının kendi ekibi tarafından, Türkiye mevzuatına (e-fatura, e-irsaliye gibi) hazır bir yapı üzerinden yürütülür; bu senaryolar demo sırasında ayrıca istenmeden de genelde gösterilir. SAP Business One veya Microsoft Dynamics 365 Business Central gibi küresel ürünlerde ise demoyu genelde yerel iş ortağı yürütür; bu durumda mevzuat entegrasyonunun canlı gösterilmesi ayrıca talep edilmeli, çünkü bu kısım bazen "ek modülle sağlanır" notuyla geçiştirilebilir.

Sektöre özgü süreçler de senaryo hazırlığında öncelik almalı. Üretim tarafında MRP ve parti izlenebilirliği, lojistik tarafında sevkiyat planlama ve filo entegrasyonu gibi konular genel bir demo akışında kolayca atlanabilir; bu yüzden sektöre özel en az bir senaryo demo öncesinde mutlaka iletilmeli. Yerli ve küresel ürünler arasındaki demo/destek modeli farkını yerli mi yabancı mı ERP karşılaştırmamızda daha ayrıntılı ele aldık; demo aşaması aslında bu daha büyük kararın ilk somut test alanı.

Demoyu kendi senaryonuzla değerlendirmek zaman alıyor ama seçim sonrası ortaya çıkacak sürprizlerin çoğu, aslında demo aşamasında sorulmayan sorularda saklı. Kendi iş akışınız üzerinden tarafsız bir değerlendirme için bir keşif görüşmesi talep edilebilir; hangi satıcıların ölçeğinize ve sektörünüze uygun olduğunu daraltmak için uygun ERP bul aracı da kullanılabilir. Demo aşamasını geçtikten sonra sözleşme detaylarında dikkat edilmesi gerekenleri ERP sözleşmesi imzalamadan önce kontrol listesinde ayrıca topladık.

Kaynaklar

• Panorama Consulting — ERP demolarında dikkat edilecekler
• ERP sözleşmesi imzalamadan önce kontrol listesi
• İç ekip mi, dış danışman mı? ERP projesinde liderlik kararı