Bir CX geçişi ters gittiğinde, otopsi neredeyse her zaman teknolojiyi işaret eder.
Eğer bu bir saçmalık olsaydı, teknoloji uşak, bariz ama çoğunlukla masum suçlu olurdu.
Muhtemelen “Platform henüz hazır değildi”, “Entegrasyon beklenenden daha karmaşıktı” veya “Satıcı fazla söz verdi” gibi şeyler duyacaksınız.
Güven verici bir hikaye çünkü sorumluluğu uzak tutuyor. Ama çoğu zaman yanlıştır.
McKinsey araştırması, büyük dönüşümlerdeki başarısızlık oranının %70 olduğunu tahmin ediyor. Özellikle CX'te kalıp iyice yerleşmiştir: projeler zaman aşımına uğrar, bütçeyi aşar veya hiçbir zaman söz verildiği gibi teslim edilmez.
Ve teknoloji suçu üstlenme eğilimindeyken, işin içini yeterince görmüş olan uygulayıcılar suçlanacak zorlu geçişler size gerçek suçluların tek bir iş yükü taşınmadan çok önce organizasyon şemasında beklediklerini söyleyecektir.
“Mücadele eden kuruluşların çoğunun yanlış yaptığı yer, teknolojiyi düzeltmeye başlamadan önce çalışma şekillerini düzeltmemektir” diyor Rupert Adair, ürün yönetimi direktörü Enghouse interaktif.
“Araçlara, platforma ve buluta odaklanıyorlar ancak müşteri deneyiminin kime ait olduğu, kararları kimin verdiği ve BT ile işletmenin nasıl birlikte çalışması gerektiği konusunda hiçbir zaman tam olarak anlaşamıyorlar.”
Ona göre sonuç tamamen öngörülebilir;
“İşler daha uzun sürüyor, insanlar farklı yönlere gidiyor ve sonunda bir şeyleri yeniden yapmak zorunda kalıyorsun.”
Mülkiyet sorunu
Ne yazık ki, bir CX modernizasyon projesine tam olarak kimin sahip olması gerektiği konusunda evrensel bir anlaşmaya varmak da göz korkutucu bir iştir.
Adair bu kararsızlığın projeleri neredeyse her türlü teknik başarısızlıktan daha fazla baltaladığını gördü.
“Çoğu zaman BT, çözümü başkaları ona sahip olmadan yönlendiriyor” diyor.
“Çok yönlü bir sahiplenme olmalı. Çağrı merkezi liderleri, ekipleri yöneten kişiler, KPI'lardan sorumlu kişiler; bunların kilit bir rol oynaması gerekiyor.”
Başarısızlıkların çoğu, BT ve CX ekipleri arasında öncelikler, sahiplik ve başarı ölçütleri konusunda uyum eksikliğinden kaynaklanmaktadır. Bu boşluk ortaya çıktığında, iyi finanse edilen programlar bile durur veya parçalanır.
Alternatif, teknik olarak teslim edilen ancak operasyonel olarak reddedilen bir geçiştir. Yani kağıt üzerinde çalışan ama pratikte kullanan herkesi hayal kırıklığına uğratan bir sistem.
Oraya ulaşmak, herhangi birinin bir proje planını açmasından önce bile gerçek bir çaba gerektirir. Adair, başarılı olan şirketlerin hiçbir şekilde teknolojiyle başlamadığına inanıyor:
“Sahipliği, öncelikleri ve gerçekte ne kadar iyi göründüğünü sıralayarak başlıyorlar. İşin özüne iniyorlar. Ne harekete geçmeden önce bir şeyi başarmaya çalışırlar Nasıl bunu yapacaklar.”
Ancak hedefler üzerinde anlaşmaya varıldığında teknik kararlar anlamlı olmaya başlar.
Entegrasyonun kör noktası
CX geçiş projelerindeki en pahalı sürprizlerden biri, entegrasyonun karmaşıklığının, canlıya geçişten önce değil, dağıtım sırasında keşfedilmesidir.
Bu noktada bütçe belirlenir, zaman çizelgesi belirlenir ve kararların geri alınması pahalı olacaktır. Ayrıca kişi itibarını kaybedebilir. Yüzü kurtarmak, bazı projelerin devam etmemesi gerekirken devam etmesinin bir başka nedenidir.
Adair, bunun izini işten ziyade teknoloji etrafında tasarlanan bir projenin aynı temel nedenine kadar uzanıyor.
“Şirketinizin müşteri deneyimi sunmak için ne yaptığını, iletişim merkezi ekiplerinin nasıl çalıştığını, müşteri etkileşiminin nasıl göründüğünü tam olarak anlamıyorsanız, herhangi bir değişikliğin etkisine hazırlıklı olamazsınız.”
Teknik olarak neyin kontrol edilebileceğine odaklanma isteğinin anlaşılabilir olduğunu kabul ediyor, ancak bunun gerçek maliyetleri de var:
“Teknoloji liderliğindeki ekipler teknolojiyi anlıyor, ancak gerçekte iş akışlarını veya insanlar ve müşteri üzerindeki etkisini anlamıyor.
“Müşterilerinizin şirketinizden nasıl hizmet beklediği ve bunun etkisinin ne olabileceği sorusunu teknik açıdan değerlendirmek onlar için daha az kolaydır.”
Onun tavsiyesi pratiktir. Şirket hakkındaki bilgilerinin yalnızca imzayı değil tasarımı da belirlemesi için doğru kişileri yeterince erken işe almayı savunuyor.
İyi geçiş uygulamaları aslında neye benziyor?
Enghouse'da bu modele verilen yanıt kasıtlı erken müdahaledir. Şirketin satış öncesi ekibi, teknik kapsam sertleşmeden önce görüşmeler yapmayı amaçlıyor, böylece müşteriler daha sonra sorun yaratacak kararlar vermek yerine tasarım hakkında en baştan düşünebiliyorlar.
Adair, “Bu, başlangıçta gerçek bir istişareye sahip olmakla ilgili” diyor. “Onları konuşturmak, farklı düşünmelerini sağlamak ve karar vericilerin bir yola çıkmadan önce uygulanabilir seçeneklerin tamamen farkında olmalarını sağlamak.”
Bu erken istişare aynı zamanda Enghouse'un, buluta büyük ölçekli bir geçiş de dahil olmak üzere herhangi bir geçişten önce dikkatli olunmasını ve durum tespiti yapılmasını tavsiye etme ilkesini de bilgilendirir.
“Veri egemenliği, bölgesel veya sektörel mevzuat uyumluluğu, iç kontrol ve yönetişim ya da sadece riskten kaçınma gibi nedenlerle hiçbir zaman tam buluta geçmeyecek kuruluşlar var.”
Karmaşıklığı ortadan kaldırdığınızda, Adair'in başarılı geçişleri başarısız geçişlerden ayıran şeyin ne olduğuna dair özeti neredeyse etkisiz hale getirecek kadar basittir.
“Başarılı ekipler önce ihtiyaç duydukları şeyi tasarlarlar ve sonra gerçekten taşınması gerekenleri hareket ettirirler. Temel nokta budur.
“Fakat bunun arkasında o noktaya ulaşmak için gereken çok fazla anlayış yatıyor.”
BT ve operasyon liderleri için içgüdü, varlık hizalamasını, iş akışı haritalamasını ve entegrasyon planlamasını proje başlamadan önce kontrol edilmesi gereken şeyler olarak görmektir.
Burası bir tanesi Enghouse gibi tedarikçi değer katıyor.
Deneyimli satış öncesi mühendislik ekibi yalnızca her müşterinin ihtiyaçlarını ve önceliklerini tam olarak değerlendirip araştırmakla kalmıyor, aynı zamanda kuruluşların pişmanlık duyabilecekleri kararlara zorlanmak yerine kendileri ve iş yükümlülükleri için neyin doğru olduğunu seçmelerine olanak tanıyan dengeli bir ürün portföyünü masaya getiriyor.
Uygulamada bu hazırlık çalışması yalnızca göçten önce gerçekleşmez; geçişin başarılı olup olmadığını belirler.
Bir yanıt yazın