Connecting process maps to journey maps

Bir bankanın kredi kartı başvuru sürecini haritalayın, ardından aynı bankanın müşteri yolculuğu haritasına bakın. Genellikle iki belge birbirini tanımaz. Süreç haritası "form doğrulama > kredi skoru kontrolü > onay > kart üretimi" der; yolculuk haritası "heyecanlı > endişeli > bekleme > hayal kırıklığı" der. Aynı olayı anlatıyorlardır ama iki farklı dilde yazılmış gibi dururlar. Sorun tam da burada başlar.

Süreç haritaları ile yolculuk haritaları birleştirilmediği sürece, operasyon ekipleri verimliliği optimize ederken deneyimi kör noktada bırakır; CX ekipleri ise duyguyu tasvir ederken hangi adımın, hangi sistemin veya hangi onay zincirinin o duyguyu ürettiğini göremez. Bu iki haritayı aynı çalışmanın parçası hâline getirmek, kozmetik bir egzersiz değil; şikayetin kök nedenine, memnuniyetsizliğin gerçek kaynağına ulaşmanın tek yoludur. Bu makale, iki haritayı nasıl birleştireceğinizi, hangi ekiplerin masada olması gerektiğini ve bu birleşimin operasyonel mükemmelliği neden doğrudan beslediğini adım adım gösteriyor.

Süreç haritası ile yolculuk haritası arasındaki fark nedir?

Süreç haritası, bir işin nasıl yapıldığını gösterir: girdiler, karar noktaları, onaylar, sistemler, sorumlu birimler. Yolculuk haritası ise müşterinin o işi nasıl hissettiğini gösterir: beklentiler, duygular, temas noktaları, kırılma anları. Biri iç bakışlıdır, diğeri dış bakışlı. Biri "ne oluyor" sorusuna, diğeri "müşteri için bu ne anlama geliyor" sorusuna cevap verir.

Hizmet tasarımı literatüründe bu ayrımın köklerini G. Lynn Shostack'ın Harvard Business Review'da 1984 yılında yayımlanan "Designing Services That Deliver" makalesine kadar geri götürebiliriz. Shostack, hizmetlerin görünmeyen operasyonel katmanla görünür müşteri katmanının birlikte tasarlanması gerektiğini, aksi halde işletmelerin kendi süreçlerine kör kaldığını yazmıştı. Kırk yılı geçen bu tespit, bugün dijital kanalların, botların ve üçüncü taraf entegrasyonların eklendiği bir ortamda daha da geçerli.

Pratikte fark şu şekilde ortaya çıkar: bir sigorta şirketi, hasar sürecini 11 adımlık bir akış şeması olarak tanımlar. Müşteri yolculuğu haritası ise aynı süreci "bildirim > belirsizlik > sabırsızlık > rahatlama" olarak dört duygusal evreye indirir. İki haritayı yan yana koyduğunuzda, dördüncü adımdaki "ekspertiz ataması" ile üçüncü duygusal evredeki "sabırsızlık" arasındaki bağlantı görünür hâle gelir. Bu bağlantı görünmeden, hiçbir CSAT anketi size neden müşterinin sabırsızlandığını söylemez.

İki harita neden birbirinden kopuk kalıyor?

Kopukluğun kaynağı örgütsel değil, sıklıkla metodolojiktir: farklı ekipler, farklı zamanlarda, farklı amaçlarla çıkarırlar bu haritaları. Operasyon ekibi süreç haritasını maliyet düşürmek, hata oranını azaltmak veya bir denetimi geçmek için çizer. CX veya pazarlama ekibi yolculuk haritasını atölye çalışmalarında, genellikle müşteri temsilcisi görüşmelerinden ve varsayımlardan yola çıkarak üretir. İkisi de doğru bir resim çizer ama farklı ölçekte, farklı kaynaktan.

Bunun bir başka nedeni de kurumsal hafızanın nasıl işlediğidir. Süreç haritaları genellikle sistemler ve prosedürler üzerinden güncellenir; kimse "müşteri bu adımda ne hissediyor" sorusunu sorma yükümlülüğü taşımaz. Yolculuk haritaları ise sıklıkla bir kerelik proje çıktısı olarak kalır, kartona yapıştırılır, sunulur, sonra rafa kaldırılır. Hiçbiri canlı, birbirini besleyen bir veri kaynağına dönüşmez.

Sonuç: şikayet analizinde "uzun bekleme süresi" çıkar, ama kimse bu bekleme süresinin hangi onay adımından, hangi manuel kontrolden veya hangi sistem arayüzünden kaynaklandığını gösteremez. Süreç tasarımı ve yolculuk tasarımı ayrı çalıştıkça, iyileştirme çabaları da birbirinden bağımsız ve genellikle çelişkili ilerler — operasyon bir adımı hızlandırırken CX ekibi aynı adıma bir "kişiselleştirme" katmanı eklemeye çalışıyor olabilir.

Süreç ve yolculuk haritalarını birleştirmenin adımları nelerdir?

Birleştirme, iki haritayı üst üste bindirip "işte, aynı şeymiş" demekten ibaret değildir. Aşağıdaki sıra, saha çalışmasında işe yarayan bir yöntemdir:

1. Aynı yolculuğu, aynı sınırlarla tanımlayın. Süreç haritası "başvuru kabulünden karta kadar" başlıyorsa, yolculuk haritası da tam aynı başlangıç ve bitiş noktasında çalışmalı. Sınırlar uyuşmazsa, üst üste bindirme anlamsızlaşır.
2. Her yolculuk adımını, arkasındaki süreç adımıyla eşleştirin. Bu eşleştirme genellikle bir-çoktur: bir müşteri temas noktası, arka planda üç veya dört süreç adımını tetikler. Bu çoklu ilişkiyi görmek, tek başına büyük bir farkındalık yaratır.
3. Her eşleşmeye bir zaman ve emek ölçütü ekleyin. Müşterinin algıladığı süre ile operasyonun gerçek işlem süresi arasındaki fark, çoğu zaman şikayetin asıl kaynağıdır. Müşteri "üç gün bekledim" der; sistem kaydı "işlem 40 dakika sürdü, kalan süre onay kuyruğunda geçti" der. İkisi de doğrudur, ama farklı hikayeler anlatır.
4. Kırılma noktalarını iki katmanda da işaretleyin. Yolculuk haritasındaki "hayal kırıklığı" ile süreç haritasındaki "manuel istisna işlemi" aynı hücrede buluştuğunda, kök nedene ulaşmışsınız demektir.
5. Sahiplenmeyi netleştirin. Birleşik haritada her kırılma noktasının bir süreç sahibi ve bir deneyim sahibi olmalı; ikisi aynı kişi olmayabilir ama ikisi de aynı toplantıda bulunmalı.
6. Haritayı yaşayan bir belgeye dönüştürün. Statik bir slaytta kalan birleşik harita, altı ay içinde eskir. Sistem değişikliği, yeni bir kanal veya bir politika güncellemesi olduğunda haritanın da güncellenmesi bir sürece bağlanmalı.

Bu adımlar tamamlandığında elinizde tek bir belge değil, iki dilin ortak sözlüğü olur. Bu sözlük, yolculuk tasarımı çalışmalarının operasyonel gerçeklikten kopmadan ilerlemesini sağlar.

Arka ofis darboğazları müşteri deneyimini nasıl bozar?

Müşteri, arka ofisi görmez ama sonucunu hisseder. Bir onay kuyruğunda tıkanan dosya, müşteri için "cevapsız kalan e-posta" ya da "sürekli tekrarlanan aynı soru" olarak yüzeye çıkar. Bu yüzden birleşik haritalama, darboğazı bulmanın en hızlı yoludur: yolculuk haritasındaki en düşük memnuniyet notunun altına indiğinizde, altta genellikle tek bir kişiye bağlı bir onay adımı, bir manuel veri girişi veya bir sistem entegrasyon boşluğu bulursunuz.

Burada davranışsal ekonominin tepe-son kuralı (peak-end rule) devreye girer. Daniel Kahneman, Barbara Fredrickson ve meslektaşlarının 1993 yılında Psychological Science'da yayımlanan "When More Pain Is Preferred to Less" başlıklı çalışması, insanların bir deneyimi anımsarken ortalamayı değil, en yoğun anı ve son anı esas aldığını göstermiştir. Bu bulgunun operasyonel karşılığı açık: bir sürecin 9 adımı kusursuz işlese de, 10. adımdaki bir onay darboğazı — örneğin bir ihtiyati doğrulama için ekstra 48 saat — o yolculuğun tüm hatırlanışını belirler. Süreç haritasında bu adım "standart kontrol" olarak görünür; yolculuk haritasında ise "güven kaybı" olarak kayda geçer. Birleştirilmiş bir haritada ikisi aynı satırda oturur ve önceliklendirme kendiliğinden netleşir.

Bain & Company'nin 2005 yılında yayımladığı ve "Closing the Delivery Gap" başlıklı araştırması, şirketlerin %80'inin kendi müşterilerine üstün deneyim sunduğuna inandığını, ancak müşterilerin sadece %8'inin bu görüşe katıldığını ortaya koymuştu. Bu uçurumun büyük kısmı, tam da yönetimin süreç haritasına bakıp "her şey planlandığı gibi işliyor" demesinden, müşterinin ise yolculuk sırasında hissettiği sürtünmeyi hiç kimsenin görmemesinden kaynaklanır.

Birleşik haritalama operasyonel mükemmelliği nasıl besler?

Operasyonel mükemmellik genellikle maliyet ve hız merkezli tanımlanır: daha az adım, daha düşük hata oranı, daha kısa işlem süresi. Bu ölçütler doğru ama yetersizdir, çünkü bir sürecin "verimli" olması onun "iyi hissettirdiği" anlamına gelmez. Bir süreci beş dakikadan üç dakikaya indirmek övgüye değer bir kazanımdır; ama eğer o üç dakika içinde müşteri neden ödediğini anlamıyorsa, hız iyileştirmesi güven kaybını telafi etmez.

Birleşik haritalama, operasyon ekiplerine üçüncü bir ölçüt kazandırır: algılanan adalet ve şeffaflık. Richard Thaler'ın 2018 yılında Science dergisinde yayımlanan "Nudge, Not Sludge" başlıklı makalesinde tanımladığı "sludge" (bilinçli veya bilinçsiz sürtünme) kavramı burada devreye girer: bir sürecin gereksiz onay katmanları, tekrarlanan belge talepleri veya açıklanmayan bekleme süreleri, operasyonel açıdan "kontrol" gibi görünse de müşteri tarafında güvensizlik üretir. Süreç haritası tek başına bu sürtünmeyi bir maliyet kalemi olarak görür; yolculuk haritasıyla birleştiğinde ise bir güven kalemi olarak da görülür — ve genellikle önceliklendirme değişir.

Bu birleşik bakış, hizmet tasarımı disiplininin tam da var olma nedenidir: bir hizmeti, hem arka sahne verimliliği hem de ön sahne algısı aynı anda optimize edilecek şekilde kurmak. Nielsen Norman Group'un hizmet blueprint'leri üzerine yayımladığı "Service Blueprints: Definition" başlıklı incelemesi, blueprint'in tam olarak bu iki katmanı — müşteri eylemleri ile arka ofis destek süreçlerini — aynı zaman çizelgesinde göstermesi gerektiğini vurgular. Birleşik haritalama, bu prensibi organizasyonel bir alışkanlığa dönüştürür.

Bu çalışmaya hangi ekipler dahil olmalı?

Birleşik haritalama tek bir departmanın işi değildir. Sadece CX ekibinin yürüttüğü bir çalışma, operasyonel gerçekliği kaçırır; sadece operasyonun yürüttüğü bir çalışma, duygusal katmanı atlar. Sahada işe yarayan bileşim şu şekildedir:

• Süreç sahipleri (operasyon/BT): sistemleri, onay zincirlerini ve SLA'ları gerçek verilerle masaya getirirler; varsayım değil, log verisi taşırlar.
• CX veya deneyim tasarımı ekibi: müşteri geri bildirimini, şikayet kayıtlarını ve duygusal işaretleri sürece bağlar.
• Ön saflardaki çalışanlar (temsilciler, şube personeli, kurye ekipleri): haritada görünmeyen "gölge süreçleri" — yani resmi prosedürün dışında geliştirilen geçici çözümleri — açığa çıkarırlar. Bu bilgi genellikle en değerlisidir ve en az belgelenmiş olanıdır.
• Uyumluluk ve risk temsilcisi: hangi kontrol adımlarının kaldırılamayacağını, hangilerinin yeniden tasarlanabileceğini erken aşamada işaretler; aksi halde önerilen iyileştirmeler denetim aşamasında geri döner.
• Bir üst yönetici sponsoru: iki ekibin önceliklerinin çatıştığı noktalarda karar verebilecek yetkiye sahip biri olmadan, birleşik harita bir tartışma belgesine dönüşür, bir eylem planına değil.

Bu bileşim bir kerelik atölye için değil, düzenli bir ritim için kurulmalı. Aksi hâlde harita yine rafa kalkar. Kurumun neresinde durduğunu görmek isteyenler için CX Olgunluk Değerlendirmesi, süreç ve deneyim tasarımının ne kadar entegre çalıştığını da ölçen bir başlangıç noktası sunar.

Birleşik haritayı canlı tutmak için ne gerekir?

Bir kerelik birleştirme egzersizi, altı ay içinde iki ayrı belgeye geri döner — sistemler değişir, yeni bir ödeme sağlayıcısı eklenir, bir kanal kapatılır. Canlı kalması için birleşik haritanın bir uygulama yol haritasına bağlanması, her güncellemenin bir sahibi ve bir tetikleyicisi olması gerekir: bir sistem değişikliği, bir politika güncellemesi veya çeyreklik bir şikayet analizi, haritanın yeniden gözden geçirilmesi için otomatik bir tetik olmalı. Bu disiplin kurulmadan, en iyi tasarlanmış birleşik harita da bir defalık proje çıktısına indirgenir.

Bu noktada teknoloji seçimi de önem kazanır. Statik slaytlar ve ayrı akış şeması dosyaları, güncel tutmayı zahmetli hâle getirir; bu yüzden birçok ekip, süreç adımları ile deneyim puanlarını aynı canlı çalışma alanında tutan araçlara yöneliyor. Renascence'ın geliştirdiği René Studio, tam olarak bu ihtiyaca cevap veriyor: her yolculuk aşama, adım ve temas noktası olarak yapılandırılırken, her temas noktası aynı zamanda bir EXIS (Deneyim Etki Skoru) taşıyor; bu sayede bir süreç adımındaki değişikliğin deneyim skorunu nasıl etkilediği tek bir tuval üzerinde görülebiliyor, ayrı belgeler arasında dolaşmaya gerek kalmıyor.

İki haritayı bir arada tutmak neden bir disiplin meselesi?

İki haritayı bir kez birleştirmek kolaydır; onları birleşik tutmak zordur, çünkü organizasyonlar doğal olarak uzmanlaşmaya, uzmanlaşma da silolara doğru sürüklenir. Operasyon ekibi hız ve maliyet dilinde düşünmeye devam eder, CX ekibi duygu ve algı dilinde. Bu iki dilin ortak bir sözlükte buluşması, bir defalık proje değil, kurumsal bir alışkanlıktır — tıpkı bütçe gözden geçirmenin çeyreklik bir ritim olması gibi.

Bir kurumun bu alışkanlığı kazandığının en açık işareti, bir şikayet geldiğinde artık "hangi ekip sorumlu" tartışmasının yaşanmamasıdır. Süreç ve yolculuk aynı haritada oturduğunda, kök neden zaten görünür; tartışılan tek şey önceliktir, sorumluluk değil. Bu, hem daha hızlı çözüm hem de daha az savunmacı bir kurum kültürü demektir — ki bu da kendi başına bir rekabet avantajıdır. Müşteri deneyimi çalışmalarını gerçek operasyonel değişime dönüştürmek isteyen ekipler için bu birleşim, süslü bir ek değil, temel bir ön koşuldur.