Back office yazılımı genellikle en son tasarlanır ve müşterinin ilk hissettiği şeydir. Gecikme için edilen özür, tutarsız yanıt ve belirli bir kişi vardiyadayken belirgin biçimde iyileşen hizmet; hepsi bir iç ekranda başlar.
Bu rehber bu maliyetin dışarıdan nasıl görüleceğini, personelin geçici çözümlerinin ne anlattığını ve hangi iki rakamın birlikte okunması gerektiğini anlatıyor.
Kısa cevap
- Back office'i müşteri hisseder: Tekrarlanan özürler ve tutarsız yanıtlar, insanları değil araçları işaret eder.
- İstisna yolunu izleyin: Personelin kendisi için kurduğu geçici çözüm, sistemin ne yapması gerektiğinin en net ifadesidir.
- Hızı ve tekrar işi birlikte okuyun: Her biri diğerini kötüleştirerek iyileştirilebilir; ne olduğunu yalnızca ikisi birlikte gösterir.
- Açık pencereleri sayın: Bir kişinin sıradaki işi bulmak için kaç yere baktığı, iş gerekçesini tek rakama indirir.
İş sonucunu ve kullanıcıyı netleştirin
Back office çalışmasının hedefi, içerideki iyileşmenin müşteride görünmesidir. Hangi iç rolün hangi müşteri sonucunu etkilediğini yazın; bağ kurulmazsa proje verimlilik başlığında kalır. Bu bağ kurulmazsa proje yalnızca iç verimlilik olarak sunulur ve bütçe sırasında geri plana düşer.
En yoğun rolün yanında bir gün geçirin. Açılan uygulama sayısı, yeniden yazılan bilgiler ve meslektaşa sorulan sorular, memnuniyet anketinden daha ikna edici bir iş gerekçesi üretir. Gözlemi tek bir günle sınırlayın ama yoğun bir gün seçin; sakin gün sorunları göstermez.
Personelin kendi kurduğu tabloları ve notları isteyin. Her biri, mevcut sistemin karşılayamadığı bir gereksinimdir ve aynı çözümü kaç kişinin kullandığı önceliği belirler. Aynı geçici çözümü kaç kişinin kullandığını sayın; bu sayı genel bir eksikle kişisel tercihi ayırır.
Back office kullanıcı deneyimi için dört karar alanı
Temiz kuyruk
En yoğun iç rolün sırada ne olduğunu nasıl bildiğini ve bunu öğrenmek için kaç yere bakmak zorunda kaldığını çıkarın. Üç ekran ve ortak bir gelen kutusundan derlenen bir kuyruk, işin yaşlanma nedenidir ve ekip dışından kimse bunu göremez.
Güvenli işlem
Hatanın kolay ve pahalı olduğu adımı bulun ve sistemin bu hatayı zorlaştırması mı yoksa yalnızca kaydetmesi mi gerektiğine karar verin. Back office yazılımlarının çoğu kaydetmeyi seçer; bu da size her hafta tekrarlayan aynı hatanın kaydını verir.
İstisna yolu
Vaka kalıba uymadığında personelin ne yaptığını, geçici çözümün ne kadar sürdüğünü ve nerede tutulduğunu izleyin. Kendileri için kurdukları tablo, sistemin ne yapması gerektiğinin en net ifadesidir.
Müşteri sonucu
İçerideki işi, o sırada müşterinin yaşadığıyla ve geçici çözüm devreye girdiğinde yaşadığıyla ilişkilendirin. Bir back office iyileştirmesini verimlilik gerekçesinden hizmet gerekçesine çeviren şey bu bağdır.
İlk sürümü bir özellik listesinden farklı planlayın
Ekran tartışmasına girmeden önce bir gün boyunca işi izleyin. Kaç uygulama açıldığını, neyin yeniden yazıldığını ve vaka kalıba uymadığında ne yapıldığını sayın; şartname bu gözlemden çıkar.
Riskleri erken görünür hale getirin
- Kuyruk ekranlara dağılmıştır: Bir kişinin sıradaki işi bulmak için kaç yere baktığını sayın ve bunu tek bir yere indirmeyi hedefleyin. Bakılan yer sayısını düşürmeden ekran değiştirmenin faydası sınırlıdır.
- Hata kaydedilir, önlenmez: Maliyetli adımda sistemin hatayı zorlaştırmasını mı yoksa yalnızca kaydetmesini mi istediğinize karar verin. Sistem yalnızca kaydediyorsa aynı hata her hafta tekrarlar.
- Geçici çözüm serbest metne taşınır: Değişiklikten sonra not alanlarına ne yazıldığını okuyun ve ne sıklıkla yazıldığını sayın. Serbest metne taşınan çözüm hiçbir raporda görünmez.
- Müşteri hiçbir şey fark etmez: İç verimlilik ölçüsünün yanına müşterinin gördüğü bir rakam koyun. Müşteri tarafında ölçü yoksa iyileşme yalnızca içeride iddia edilir.
Hayata geçirilebilir bir yol haritası yazın
- Bir gün izleyin. En yoğun iç rolün yanında oturun, açılan ekranları ve sorulan soruları sayın.
- Geçici çözümleri toplayın. Kişisel tabloları ve notları isteyin, aynı çözümü kaç kişinin kullandığına göre sıralayın.
- Tek kuyruğu düzeltin. En kötü ekranı ya da kuralı değiştirin ve iki hafta işlem süresiyle tekrar işi birlikte izleyin.
- Ekibe sorun. Değişikliği sürdürmek isteyip istemediklerini sorun; yanıt benimsemeyi rakamlardan iyi öngörür.
İş ortağı ve teklif değerlendirmesi
Back office kullanıcı deneyimi için kısa listenin tamamına aynı iş sonucu, temsilî yolculuk, bilinen sistem sınırları ve açık varsayımları verin. Teklifleri yalnızca toplam tutarla değil; dahil edilen akışlar, ekip yapısı, erken risk testleri, kalite yaklaşımı, bağımlılıklar, hariç tutulanlar ve değişiklik kuralıyla karşılaştırın.
- back office kullanıcı deneyimi iş hedefini hangi ilk sürüm kararlarına çevireceksiniz?
- back office kullanıcı deneyimi için kullanıcı değeri için hangi kullanıcı kanıtını geliştirme öncesinde toplayacaksınız?
- back office kullanıcı deneyimi için veri ve sistem sınırları içinde en riskli varsayım nedir ve nasıl test edilecek?
- Normal akış bozulduğunda kullanıcı ile operasyon ekibi ne görecek?
- Kalite, güvenlik, erişilebilirlik ve performans hangi teslimat kanıtlarıyla değerlendirilecek?
- Lansman, izleme, bakım ve gelecekteki devirde sorumluluk nasıl paylaşılacak?
Fırsatı içeriden değil dışarıdan okuyun
İç ekranların değerini içeriden değil müşterinin yaşadığından okuyun. Müşteri ne kadar bekliyor, kendisine ne söyleniyor ve vaka kalıba uymadığında ne oluyor? Buradan içeri doğru giderek kuyruğun nerede dağıldığını, hangi adımda hata pahalı olduğunu ve geçici çözümün nerede devreye girdiğini bulun.
Sonraki adım
Back office kullanıcı deneyimini iç verimlilik başlığından çıkarıp müşteri sonucuna bağlayın. İşlem süresi ile tekrar işi aynı sayfada yayınlayın ve yanına müşterinin fark ettiği bir rakam koyun.
İlgili rehber: Şube Yönetim Platformu: Bağlamı Kaybetmeden Ortak Kontrol.
30 günlük doğrulama planı: Back office kullanıcı deneyimi
1-5. günler: bir gün boyunca tek bir kişinin arkasında oturun. En yoğun iç rolü seçin ve müdahale etmeden bir tam gün izleyin. Açtığı uygulamaları, bir şeyi yeniden yazdığı anları ve ekran söylemediği için meslektaşına sorduğu durumları sayın. İş gerekçesi o sayımdır ve herhangi bir memnuniyet anketinden daha ikna edicidir. Aradaki boşluklarda ne yaptıklarını da not edin; küçük toparlamalar ve çift kontroller, hiçbir süreç şemasında görünmeyen iştir.
6-15. günler: geçici çözümleri toplayın. Ekipten kendi tablolarını, notlarını ve kısayollarını göstermelerini isteyin. Bunların her biri mevcut sistemin karşılayamadığı bir gereksinimdir. Aynı geçici çözümü kaç kişinin kullandığına göre sıralayın; genel bir eksikle tek kişinin tercihi arasındaki fark budur. Her geçici çözümün ne kadar süredir var olduğunu sorun; iki sistem yükseltmesinden sağ çıkmış bir çözüm, kimsenin kapatmayı düşünmediği bir eksiği anlatır.
16-30. günler: bir kuyruğu değiştirin ve iki rakamı birden ölçün. En kötü tek ekranı veya kuralı düzeltin, ardından iki hafta boyunca işlem süresi ile tekrar iş oranını birlikte izleyin. İşlem süresi düşerken tekrar iş artıyorsa değişiklik işi kaldırmamış, yerini değiştirmiştir; testi bu ölçekte yapmanın amacı bunu iki haftada öğrenmektir. İki haftanın sonunda ekibe değişikliği sürdürmek isteyip istemediklerini sorun; yanıtları, benimsemeyi iki rakamdan daha iyi öngörür.
Pratik çalışma sayfası: Back office kullanıcı deneyimi
Back office ekranları genellikle en son tasarlanır ve müşterinin ilk hissettiği şeydir. İşletmenizdeki en yoğun iç rolü seçin ve gününün her parçası için bir satır doldurun.
| Karar alanı | Kaydedilecek bilgi |
|---|---|
| Temiz kuyruk | Bu kişinin sırada ne olduğunu nasıl bildiği ve bunu öğrenmek için kaç ayrı yere bakmak zorunda kaldığı |
| Güvenli işlem | Hatanın kolay ve pahalı olduğu adım ve sistemin bu hatayı zorlaştırıp zorlaştırmadığı, yoksa yalnızca kaydedip kaydetmediği |
| İstisna yolu | Vaka kalıba uymadığında ne yaptıkları, geçici çözümün ne kadar sürdüğü ve nerede tutulduğu |
| Müşteri sonucu | O kişi çalışırken müşterinin ne yaşadığı ve geçici çözüm devreye girdiğinde ne yaşadığı |
| Ölçüm | İşlem süresi ile tekrar iş oranı birlikte okunur; çünkü her biri tek başına, diğerini kötüleştirerek iyileştirilebilir |
Bir şey tarif etmeden önce bir sabah boyunca istisna yolunu izleyin. Çalışanların kendileri için kurduğu geçici çözüm, sistemin ne yapması gerektiğinin en net ifadesidir ve genellikle yazılı süreçten daha doğrudur.
İlgili rehberler
- Planlama aşamasını geçtiyseniz şunu okuyun: Özel Yönetim Panosu Geliştirme: Metrikten Aksiyona.
- Doğru yapılması gerekenler şurada toplanmış: Operasyonel Dashboard: KPI'lar, Örnekler ve Tasarım.
Back Office Kullanıcı Deneyimi Müşterileri Neden Etkiler? ortadan kaldırmaya değer manuel adımları görünür kılıyorsa Operasyon Platformunuzu Konuşalım.
Ali Boran Gazel