Service Blueprint: Katmanlar, Çizgiler ve Bakım Maliyeti

Service blueprint, bir hizmetin müşteriye görünen yüzünü ve arkasında çalışan süreçleri aynı tabloda gösteren diyagramdır. Yolculuk haritasının bıraktığı yerden devam eder: bir temas noktası neden kötü çalışıyor sorusunun cevabı çoğu zaman görünmeyen tarafta durur. Peki tabloyu çıkarmak süreci gerçekten düzeltir mi, yoksa duvara güzel bir poster mi asar?

Dört satır, üç çizgi

İskelet satırlardan kurulur. Üstten aşağı: müşterinin yaptıkları, müşterinin gördüğü çalışan ve sistem hareketleri (frontstage), görmediği arka plan işleri (backstage), bunların tamamını mümkün kılan kurum içi destek süreçleri. Her temas noktasında elde kalan kanıtı da işaretlersiniz: e-posta, ekran, fatura, imzalanan form.

Asıl bilgiyi satırlar değil, onları ayıran çizgiler taşır.

• Etkileşim çizgisi: müşterinin kurumla temas ettiği yer. Üstünde kalan her şey deneyim, altı operasyondur.
• Görünürlük çizgisi: müşterinin görebildiğini göremediğinden ayırır. Bir işi bu çizginin altına mı üstüne mi koyacağınız, çalışmadaki tartışmaların çoğunun çıktığı yerdir.
• İç etkileşim çizgisi: müşteriyle temas eden ekiplerle destek ekipleri arasındaki sınır. Bir talebin kaç kez el değiştirdiğini burada sayarsınız.

Yolculuk haritası "müşteri burada sıkıldı" der ve durur. Blueprint aynı sütunda, sıkılmanın nedenini barındıran üç satır daha açar.

Görünürlük çizgisi hangi iddiayı test eder

Backstage satırındaki her kutu bir iddiadır: burada bir iş yapılıyor. Yapılıyor mu gerçekten? Şemada "sistem siparişi doğrular" yazan kutunun arkasında bir servis çağrısı, bir kuyruk, zamanlanmış bir görev var mı, yoksa o kutu birinin olduğunu varsaydığı bir adım mı? Blueprint'in ucu buradan koda değer, çünkü görünmeyen tarafın yarısı yazılımdır ve yazılımın yaptığı iş kayıt bırakır.

Toplantı odasında hafızadan çizilmiş bir blueprint'i, sistemin kendi kayıtlarından (loglar, kuyruk verisi, ticket geçmişi) çıkarılmış olanına göre belirgin biçimde daha az güvenilir bulurum. İlki ekibin süreci nasıl hatırladığını anlatır, ikincisi sürecin ne yaptığını. Aradaki fark genellikle hatanın yaşadığı yerdir. İki versiyonu yan yana koymak da ayrı bir çalışma gerektirmez, çoğu zaman bir öğleden sonra işidir.

Eklenen her satır bir bakım borcudur

Blueprint anlatımlarında iki tavsiye yan yana durur ve birbirini yer. Biri zenginleştirmeyi söyler: süre, duygu, metrik, politika satırları ekle. Diğeri canlı tutmayı: süreç değiştikçe şemayı güncelle.

Aritmetik bu ikisini aynı anda sevmiyor. On iki adımlık bir yolculuğa tek bir süre satırı eklemek, doldurulacak ve her değişiklikte gözden geçirilecek on iki yeni hücre demek; dört isteğe bağlı satır eklerseniz kırk sekiz. Şema güncellenmeyi bıraktığı anda yanlış bilgi üretmeye başlar, çünkü kimse ona bakıp "bu eskimiş" demez, bakıp karar verir.

Temel dört satırla başlayın, isteğe bağlı satırı ancak bir karar ona dayanacaksa ekleyin. Duygu satırı, ekip "hangi adımı önce düzeltelim" tartışmasını çözemiyorsa işe yarar. Herkes zaten hangi adımın kötü olduğunu biliyorsa o satır sadece süstür.

Kapsamı daraltmak

"Hizmetimizin blueprint'ini çıkaralım" diye başlayan çalışmalar üç hafta sürüyor, sonunda kimsenin güncellemediği bir poster bırakıyor. Tek bir yolculuk dilimi seçmek daha iyi sonuç veriyor: iade talebi, ilk kurulum, plan yükseltme. Başı ve sonu belli, sütun sayısı yirmiyi geçmiyor, bir oturumda bitiyor.

Ya süreç birden fazla dilime yayılıyorsa? O zaman ayrı blueprint'ler çizip aralarındaki devir noktalarını işaretlemek, hepsini tek şemaya sığdırmaya çalışmaktan daha iyi çalışır. Zaten aksaklıkların çıktığı yer o devir noktalarıdır: talebin bir ekipten diğerine geçtiği, sorumluluğun kimde olduğunun belirsizleştiği sütunlar. İki ayrı şemada o geçiş görünür kalır, tek büyük şemada kalabalığın içinde kaybolur.