Service Blueprint'te Doğru Deneyimi Seçmek

Service blueprint'in zor kısmı şemayı çizmek değil, neyi çizeceğine karar vermek. Kapsamı yanlış seçilen bir blueprint ya haftalarca bitmez ya da bittiğinde kimsenin değiştirme yetkisi olmayan bir süreci anlatır. Aday deneyimi seçerken kullanılan ölçütlerin ikisi de birbiriyle çelişiyor, o çelişkiyi baştan görmek gerekiyor.

Kapsamın maliyeti hücreyle ölçülür

Blueprint'in yatay ekseni dokunma noktalarını, dikey ekseni şeritleri taşır: kullanıcı eylemi, sahne önü, sahne arkası, destek süreçleri, bir de kanıtlar. Beş dokunma noktalı bir akış bu haliyle yirmi beş hücre demek, üstüne kırılma noktalarını ve şeritler arası okları ekleyin. "Baştan sona tüm yolculuk" hedefiyle başlayan ekiplerin ilk denemede bitirememesinin sebebi budur, karmaşıklık dokunma noktası sayısıyla doğrusal değil çarpım halinde büyür.

Kapsam üç ölçüde düşünülebilir:

• Küçük: en çok iki dokunma noktası. Öğrenci portalında mezuniyet başvurusu gibi tek amaçlı bir işlem.
• Orta: beşe kadar dokunma noktası. Sipariş verip teslim almak gibi hedefi belli bir akış.
• Büyük: birimlerden bağımsız, uçtan uca yolculuk.

İlk blueprint için küçük ya da orta kapsam seçin. Büyük kapsamı yasaklamıyorum, ama onu bir keşif aracı değil, daha önce çizilmiş küçük blueprint'leri birleştiren bir üst harita olarak görmek daha doğru sonuç veriyor.

Aday listesini çıkarma sırası

Sırayla ilerleyin, seçim tek adımda yapılmıyor.

Önce şikayet kayıtlarına, destek taleplerine ve terk oranı yüksek adımlara bakıp sorunlu akışları listeleyin. Sonra her aday için iki soruyu cevaplayın: bu süreçte değişiklik yapma yetkisi kimde ve elinizde bu süreci anlatan veri var mı? Üçüncü adımda yol haritasına bakın, yakın dönemde yeniden tasarlanacak süreçler analiz için doğal aday. Son adımda listeyi paydaşlarla birlikte sıraya koyun; kurumsal ortamlarda önceliklendirme matrisi tartışmayı öznellikten çıkarmak için işe yarıyor.

Çelişen iki ölçüt: sorun nerede, kontrol kimde

Rehberler genellikle "sorunlu bir deneyim seç" ve "kontrolündeki bir deneyim seç" ölçütlerini yan yana yazar. Pratikte bu ikisi çoğu zaman aynı süreci işaret etmez. Hizmetlerdeki tıkanmalar en sık devir teslim noktalarında, yani bir ekibin işi bitirip diğerine aktardığı yerde oluşur; o noktalar da tanımı gereği tek bir ekibin kontrolünde değildir. Tamamen sizin kontrolünüzdeki bir akışı seçerseniz zaten bildiğiniz şeyi güzel bir şemaya dönüştürmüş olursunuz.

Buradaki tercih şöyle: sorunun olduğu yeri seçin, kontrol eksikliğini ise blueprint'in çıktısı olarak raporlayın. Sahne arkası şeridinde başkasına ait bir adım varsa onu boş bırakmayın, sahibinin adıyla yazın. Bir iade akışını haritalarken tıkanmanın çağrı merkezinde değil, onay bekleyen finans kuyruğunda olduğunu ancak sahne arkası şeridini doldurunca görmüştük.

Aynı çelişki üçüncü bir yerde daha çıkıyor: "yakında yeniden tasarlanacak süreci seç" ile "az araştırma gerektiren süreci seç" ölçütleri de birbirini çeker. Yeniden tasarlanacak süreçler genelde ölçümü en zayıf olanlardır, zaten bu yüzden sıraya girmişlerdir. İkisinden birini seçmek gerekirse veriyi tercih edin; blueprint tahminle doldurulduğunda ekibin varsayımlarını doğrulayan bir belgeye dönüşür.

Ne zaman blueprint çizmemeli

Sorun tek bir ekranda, tek bir formda yaşanıyorsa blueprint fazla ağır bir araç. Kullanılabilirlik testi ya da olay kaydı incelemesi aynı cevabı birkaç saatte verir. Blueprint, sorunun kullanıcının gördüğü yüzeyde değil arkasındaki sırada, kuyrukta veya el değiştirmede olduğundan şüphelendiğinizde değerini gösteriyor. Küçük bir alanı seçmekten çekinmeyin, çünkü bitmiş küçük bir blueprint yarım kalmış büyük bir haritadan daha çok karar üretir.