Service Blueprinting: Kapsam, Veri ve Bakım Sorunları
Service blueprint çıkarmak teknik olarak zor değil. Zor olan, şemayı kimsenin açmadığı bir sunum dosyasına dönüşmeden önce karar masasına sokmak. Projelerin takıldığı yerler de neredeyse her seferinde aynı dört başlıkta toplanıyor: destek bulmak, kapsamı kesmek, veriye ulaşmak ve şemayı canlı tutmak.
Destek almadan başlamak
Blueprint bir ekibin ortak kabulüne dönüşmediği sürece sadece bir çizim kalır. O yüzden ilk iş şema değil, çekirdek ekip. İki ila dört kişi yeterli; daha kalabalığı toplantı takvimine yenilir.
Ekipte karar verme yetkisi olan biri bulunmalı, hizmetin kâğıt üzerinde değil sahada nasıl yürüdüğünü bilen operasyon tarafından da biri. Geri kalanlar sonradan katılabilir. Projeyi kurum içinde "bir araştırma çalışması yapıyoruz" diye anlatırsan ilgi ikinci haftada düşer. "Şu üç şikâyetin nereden çıktığını bulacağız" dersen kalır, çünkü ortada herkesin tanıdığı bir sorun var.
Kapsam bir zevk meselesi değil, hesap
Kapsam tartışması genelde "ne kadar detaya girelim" diye sorulur. Oysa cevap sayılabilir. Standart şablon beş satır taşır: fiziksel kanıt, müşteri aksiyonları, sahne önü, sahne arkası, destek süreçleri. On müşteri aksiyonu tanımladığında elinde elli hücre olur ve her hücre doğrulanması gereken bir iddiadır. Yirmi aksiyona çıkarsan yüz hücre.
Yük doğrusal büyüyor, ekibin dikkati büyümüyor. Blueprintlerin yarısının ilk sürümde donup kalmasının sebebi budur; sekiz ila on iki aksiyon tavsiyesi de oradan geliyor. Kapsamı daraltırken üç şeye bak: hizmetin sahibi sen misin, verisine erişebiliyor musun, bulgunun uygulanacağı bir karar var mı. Üçü birden yoksa o hizmetle başlamayın.
Veri yoksa varsayımla başla, ama varsayımı işaretle
Görüşme ayarlamak, katılımcı bulmak, mevcut kayıtlara erişmek, bu adımlar takvimin çoğunu yiyor. Pratik çıkış yolu, verisi hâlihazırda duran bir süreçle başlamak ve onu vaka çalışmasına çevirmek. İkinci blueprint için kapıyı o açar.
Varsayımla ilerlemek de meşru, hatta eksikleri görünür kıldığı için faydalı. Tek şartı var: varsayım hücreleri şemanın üzerinde ayrı işaretlenmeli. Bir ay sonra şemaya bakan kişi neyin ölçüldüğünü, neyin tahmin olduğunu ayırt edemiyorsa blueprint bilgi değil güven üretir, bu da onu daha tehlikeli yapar.
Moderatör ve katılımcı aynı kişi olmaz
Çalıştayda hem tartışmayı yönetip hem içeriğe katkı vermeye çalışmak ikisini de bozar. Rolü paylaş: biri akışı ve saati tutsun, diğeri alan bilgisini getirsin.
Konuya uzak bir moderatör ilk bakışta kayıp gibi görünür, değildir. Ekibin yıllardır sorgulamadığı adımları o sorar. Grup büyüklüğü de sonucu doğrudan etkiliyor; on kişilik bir odada üç kişi konuşur, beş kişilik iki grupta herkes konuşur.
Blueprintin asıl sorunu bakım
Blueprint iletişiminde verilen iki tavsiye genelde yan yana durur ve birbirini keser: şemayı etkileyici biçimde görselleştir, bir de sürekli güncel tut. Görsel ne kadar cilalıysa güncellenme olasılığı o kadar düşer, çünkü küçük bir süreç değişikliğini işlemenin maliyeti artmıştır. Donmuş güzel bir şema, çirkin ama doğru bir tablodan daha az işe yarar.
Blueprinti tablo ya da metin olarak tut, görseli sunum gerektiğinde üret. Değişikliğin satır satır görünür olur, sürüm bilgisini elle yazmaktan kurtulursun, bir çizim aracının dosya formatına da bağlı kalmazsın. Şemanın altına "son güncelleme" tarihi düşmek işe yarıyor gibi görünür ama o tarihi kimse güncellemez; güncellemeyi hatırlatan şey, şemanın değişiklikle birlikte bakılan bir yerde durmasıdır.
Bir de şu: blueprint bir kere çıkarılıp arşivlenen belge değil. Hizmet değiştikçe değişir. Değişmiyorsa ya hizmet durmuştur ya şemaya kimse bakmıyordur, ikisi de kötü haber.