Üç farklı yazılımın demosunu izleyen bir acente ekibi, toplantı odasından çoğu zaman üç farklı görüşle çıkar. Biri arayüzü beğenmiştir, diğeri raporlamayı, bir başkası mobil uygulamayı. Bu dağınıklık doğaldır; ama karar anında “Hangisi daha iyi hissettirdi?” sorusuna dönüşürse seçim, gerekçesi zayıf bir tercihe dönüşür. Ağırlıklı puanlama matrisi, bu izlenimleri ölçülebilir ve tartışılabilir bir tabloya çevirmek için kullanılan basit bir karar aracıdır.
Matrisin mantığı
Yöntem üç bileşenden oluşur: değerlendirme ölçütleri, her ölçütün ağırlığı ve her aday için verilen puan. Ölçütün ağırlığıyla adayın puanı çarpılır, çarpımlar toplanır ve her aday için tek bir toplam elde edilir. Bu toplam kararın kendisi değildir; kararı tartışmak için ortak bir zemin sağlar. Asıl değer, ağırlıkları belirlerken ekibin neyi önemsediğini açıkça konuşmak zorunda kalmasıdır.
Adım 1: Ölçütleri sınırlı tutun
Elli satırlık bir matris kimsenin dikkatle dolduramayacağı bir tabloya dönüşür. Sekiz ile on iki arası ölçüt çoğu acente için yeterlidir. Örnek bir ölçüt seti şöyle olabilir:
- Branş bazlı teklif akışları: trafik, kasko ve DASK için ayrı ve branşa uygun sorgu ekranları
- Teklif karşılaştırma ve müşteriye sunum kolaylığı
- Müşteri kartı ve iletişim geçmişi
- Yenileme ve görev takibi
- Tahsilat kayıtları
- Kullanıcı, şube ve yetki yönetimi
- Mobil erişim ve web ile aynı veriyle çalışma
- Raporlama ve yönetici görünürlüğü
- Güvenlik: iki aşamalı doğrulama, işlem kayıtları
- Destek, eğitim ve geçiş desteği
Ölçütleri yazarken her birinin ne anlama geldiğini bir cümleyle tanımlayın. “Raporlama” bir kişiye göre şube kırılımlı tablolar, bir başkasına göre tek ekranlık özet olabilir.
Adım 2: Ağırlıkları puanlamadan önce belirleyin
Ağırlıkları demolardan sonra belirlemek, beğenilen adayın öne çıktığı ölçütlere bilinçsizce yüksek ağırlık verilmesine yol açar. Bu yüzden ağırlıklar, hiçbir demo izlenmeden kararlaştırılmalıdır. Pratik bir yöntem, toplam yüz puanı ölçütlere dağıtmaktır. Örneğin teklif akışlarına daha yüksek, arayüz kişiselleştirmeye daha düşük pay ayrılabilir. Rakamların kendisi acenteye özeldir; önemli olan dağılımın ekipçe kabul edilmesidir.
Ağırlık tartışmasını kolaylaştıran soru
“Bu ölçüt hiç karşılanmasaydı yazılımı yine de kullanır mıydık?” sorusu, ağırlık konuşmasını somutlaştırır. Cevap “hayır” ise o ölçüt yüksek ağırlık almalı, hatta eleme ölçütü olarak ayrı tutulmalıdır.
Adım 3: Puan ölçeğini tanımlayın
Bir ile beş arası bir ölçek yeterlidir, ancak her puanın ne anlama geldiği yazılı olmalıdır:
- Karşılanmıyor
- Kısmen ve geçici yollarla karşılanıyor
- Temel düzeyde karşılanıyor
- İhtiyacı rahatça karşılıyor
- İhtiyacın ötesinde, sürecimizi iyileştiriyor
Tanımlı bir ölçek, “Bence dört, sence üç” tartışmasını “Demoda gördüğümüz şey hangi tanıma uyuyor?” sorusuna çevirir.
Adım 4: Puanlamayı bağımsız yapın
Her değerlendirici matrisi önce tek başına doldurmalıdır. Ortak toplantıda puanlar yan yana konur ve büyük farklar konuşulur. İki kişi arasında iki puandan fazla fark varsa, genellikle aynı özelliği farklı biçimde anlamışlardır ya da biri demoda o bölümü görmemiştir. Bu farkları netleştirmek, matrisin en öğretici kısmıdır.
Adım 5: Puanı kanıtla destekleyin
Her puanın yanına kısa bir not ekleyin: Demoda hangi senaryo denendi, ne görüldü? Örneğin bir değerlendirici kasko teklif akışına dört verdiyse, notta “Araç bilgisi girildikten sonra teminat seçenekleri ayrı adımda gösterildi, karşılaştırma ekranından PDF teklif formu oluşturuldu” gibi bir gözlem yer almalıdır. Bu notlar, karar aylar sonra sorgulandığında da işe yarar.
Toplamı okurken dikkat edilecekler
- Yakın skorlar eşit sayılabilir: Toplamlar arasında küçük farklar varsa, matris kesin bir kazanan göstermiyor demektir. Bu durumda eleme ölçütlerine ve geçiş riskine bakın.
- Eleme ölçütü ayrı değerlendirilir: Vazgeçilmez bir ihtiyacı karşılamayan aday, toplamı yüksek olsa bile elenmelidir.
- Maliyet ayrı bir sütunda tutulabilir: Fiyatı puanlamaya katmak yerine, işlevsel skoru ve maliyeti yan yana görmek daha şeffaf bir karar sağlar.
Matrisi demo hesabıyla beslemek
Sunum izlemek ile sistemi kendiniz kullanmak farklı deneyimlerdir. Mümkünse her aday için demo hesabı talep edin ve değerlendiricilere kendi senaryolarını denemeleri için birkaç gün verin. InsureHub'da örneğin bir DASK teklifi için adres ve yapı bilgileriyle ilerleyen akışı, trafik teklifinin araç sorgusundan başlayan akışıyla karşılaştırmak; bir alt kullanıcı oluşturup yetkilerini sınırlamak gibi denemeler, matrisin ilgili satırlarına doğrudan kanıt üretir. Teklif tarafındaki ölçütler için sigorta teklif programı, saha kullanımı ölçütü için mobil sigorta uygulaması sayfalarındaki akışları referans alabilirsiniz.
Örnek senaryo: İki adaylı bir değerlendirme
Dört kişilik bir acente düşünelim. Ekip, ağırlıkları belirlerken teklif akışları ve yenileme takibini en üst sıraya, arayüz kişiselleştirmeyi en alta koymuş olsun. İlk aday sunumda daha etkileyici bulunmuş, ancak bağımsız puanlamada yenileme takibinde düşük puan almıştır; çünkü değerlendiriciler yenileme listesini kullanıcı bazında filtreleyemediklerini not etmiştir. İkinci aday arayüzde daha sade kalmış, ancak branş bazlı teklif akışlarında ve görev atamada daha yüksek puan toplamıştır. Toplamlar yan yana konduğunda ekip, toplantı başındaki izleniminin ağırlıklı ihtiyaçlarla örtüşmediğini fark eder. Matrisin değeri tam olarak budur: duyguyu yok saymaz, ama onu öncelikler karşısında sınar.
Karar toplantısının çıktısı
Matris tamamlandığında karar toplantısından tek bir sonuç değil, üç çıktı beklenmelidir: seçilen aday, seçimin gerekçesi ve seçilen adayda zayıf kalan ölçütler için bir telafi planı. Son madde sıklıkla atlanır. Hiçbir yazılım her ölçütte en yüksek puanı almaz; zayıf kalan alanları baştan bilmek, kurulum ve eğitim planını gerçekçi kılar.