Servis Tasarımı: Arka Sahne, Blueprint ve Gerçek Sistemler
Servis tasarımı tartışmaları hızla ön yüze kayıyor: ekran akışı, mikro kopya, temas noktaları. Asıl iş arka sahnede yapılıyor. Tasarımcının çizdiği kutuların çalışan sistemlerde karşılığı yoksa blueprint bir temenni listesinden ibaret kalır, ölçüsü de basittir: her arka sahne satırının bir sahibi ve bir karşılığı var mı.
Ön sahne ve arka sahne ayrımı nerede işe yarar
Tiyatrodan alınan bu ayrım popüler olduğu kadar yüzeysel de kullanılıyor. İşe yaradığı tek yer şurası: bir aksaklığın nerede doğduğunu gösterir. Müşteri aynı bilgiyi üç kez giriyorsa sorun form tasarımında değil, üç sistemin ortak bir kayıt paylaşmamasındadır. Arayüzü yeniden çizmek burada hiçbir şeyi düzeltmez, sadece aynı boşluğun üstünü daha düzgün örter.
Ön sahne, kullanıcının gördüğü her şey: arayüz, e-posta, mağaza, çağrı merkezindeki kişi. Arka sahne ise entegrasyonlar, yetki kuralları, veri modeli ve şirket politikaları. İkisi ayrı hızda değişir; ön yüz bir haftada, arka sahne bir çeyrekte.
Servis tasarımı ile hizmet tasarımı iki ayrı disiplin değil
Kaynaklarda sık rastlanan bir ayrım var: "servis tasarımı arka planla, hizmet tasarımı müşteri yolculuğuyla ilgilenir." Bu ayrım literatürde yok. İkisi de aynı terimin, service design'ın Türkçesi; birini diğerinin alt kümesi yapmak sadece çeviri kararından doğmuş bir yanlış anlama.
Ayrımın anlatmak istediği şey gerçek, adlandırması yanlış. Müşterinin dokunduğu katmanın adı arayüz tasarımı ya da daha genel olarak kullanıcı deneyimi tasarımıdır. Servis tasarımı ikisini birden kapsar, dolayısıyla "biz servis tasarımı yapıyoruz ama ön yüze bakmıyoruz" cümlesi kendi içinde tutarsızdır.
Blueprint'i kurgudan ayıran şey
Blueprint, temas noktalarını üstte, destek süreçlerini altta gösteren bir tablodur; NN/g'nin tanımı bu yapıyı iyi özetler. Sorun tanımda değil, doldurulma biçiminde.
Arka sahne satırına "sistem müşteriyi tanır" yazmak kolaydır. Bunun karşılığı, iki farklı veritabanında aynı kişiyi eşleyen bir kimliktir ve o kimlik çoğu kurumda yoktur; CRM'deki kayıt ile destek sistemindeki kayıt arasında e-posta dışında ortak alan bulunmaz, e-posta da değişir. Böyle bir satır blueprint'te yeşil görünürken sahada kırmızıdır.
Çözüm, çizimi tek başına yapmamak. Her arka sahne satırının yanına o adımı gerçekten yapan sistemin ve sahibinin adı yazılmalı; adı yazılamayan satır tasarım değil, taleptir (tek başına çizilmiş blueprint'lerin çoğunu kurgu buluyorum).
Sıra nasıl kurulur
Uygulamada işe yarayan sıralama kısa:
- Çalışan tarafıyla başla. Bir hizmetin en hızlı teşhisi, o hizmeti veren kişinin gün içinde kaç kez sisteme rağmen çalıştığını saymaktır.
- Mevcut durumu çiz, ideali değil. İdeal blueprint hiçbir tartışmayı çözmez.
- Tek bir kırık geçişi düzelt ve ölç. Aynı bilgiyi tekrar isteme sayısı, çözüm süresi, elle yapılan aktarma sayısı.
Bu üçünü yapan bir ekip, altı aylık bir dönüşüm programından daha fazla yol alır. Servis tasarımının değeri de zaten süreçlerin tamamını yeniden kurmakta değil, kimsenin sahiplenmediği geçişleri görünür kılmakta.