Veri Modeli ve Özelleştirme

Talep formundaki her alan üç gruptan birine girer. Bu ayrımı yapmak, alan enflasyonunu tek başına engeller.

Üçüncü satır, gördüğümüz kurulumların çoğunda yanlış yapılır. Kök sebep, ürün grubu, çözüm tipi gibi analiz alanları talep açılırken sorulur. Oysa bu bilgiler talep açılırken bilinmez; ancak çözüldükten sonra doğru doldurulabilir. Açılışta sorulan sınıflandırma alanı, ya boş kalır ya da rastgele doldurulur; ikisi de raporu bozar.

Bir alanı zorunlu yapmak beş saniye sürer. Sonuçları aylarca yaşanır. Zorunlu alan, temsilcinin işini yapmasını engelleyen tek yapıdır ve engellendiğinde temsilci kuralı değil veriyi bozar: alanı rastgele doldurur.

Zorunlu alan kararı için tek ölçü şudur: bu alan boş kalırsa bir sonraki adım gerçekten yapılamaz mı?

• Doğru zorunluluk: talep kapatılırken çözüm tipi. Boş kalırsa raporlama tamamen çalışmaz ve alan sonradan geriye dönük doldurulamaz.
• Doğru zorunluluk: yüksek önceliğe çekilirken gerekçe. Boş kalırsa öncelik ölçeği anlamını yitirir.
• Yanlış zorunluluk: talep açılırken müşteri sektörü. Bu bilgi hesapta durur, her talepte sorulmaz.
• Yanlış zorunluluk: temsilcinin tahmin etmek zorunda kaldığı her alan. Tahmin, veri değildir.

Farklı talep tipleri farklı bilgi ister. Bir arıza bildirimi ile bir fatura talebi aynı formu paylaştığında, ikisinde de alanların yarısı boş kalır. Bu sorun iki farklı araçla çözülür ve ikisi karıştırılır.

Düzen (layout)

Alan setinin kendisini değiştirir. Farklı talep tipleri için farklı alanlar, farklı zorunluluklar ve farklı ekran düzeni tanımlar. Yapısal bir ayrımdır.

Talep şablonu

Aynı düzen içinde önceden doldurulmuş bir başlangıç noktası sunar. Sık tekrar eden talep tiplerinde temsilcinin işini hızlandırır. Kolaylık aracıdır.

Karar ölçüsü şudur: alanların kendisi mi değişiyor, yoksa yalnızca varsayılan değerler mi? Alanlar aynı kalıyorsa şablon yeterlidir. Bir tipte olup diğerinde hiç olmayan alanlar varsa düzen gerekir.

Düzen sayısını az tutun. Her düzen kendi alan setini, kendi zorunluluklarını ve kendi raporlama davranışını taşır. Beş düzenli bir kurulumda "toplam kaç talepte şu alan doldurulmuş" sorusu zorlaşır. Sürüm karşılaştırmasında düzen ve doğrulama kuralı gibi bileşenlerin hangi seviyede geldiğini sözleşme öncesinde teyit edin; bu kısıtlar kurulum planını doğrudan etkiler.

Talep tek başına yaşamaz. En az bir kişiye, çoğu zaman bir hesaba ve bazen bir ürüne bağlanır. Bu bağlantıların doğru kurulması, ileride sorabileceğiniz soruların sınırını belirler.

Kurumsal müşterilere hizmet veriyorsanız hesap bağlantısı ihmal edilemez. Aynı şirketten beş farklı kişi yazdığında, hesap bağlantısı yoksa bu beş talebin aynı müşteriye ait olduğunu göremezsiniz. Bireysel tüketiciye hizmet veren yapılarda ise hesap katmanı gereksiz karmaşa üretir ve boş bırakılabilir.

Veri kalitesini korumanın iki yolu vardır: kullanıcıyı eğitmek ve sistemi kurallamak. Birincisi kalıcı değildir, ikincisi ölçekle çalışır.

1. 01Düzen kurallarıyla listeyi daraltın

   Kısa liste, doğru seçim demektir.

   Kısa liste, doğru seçim demektir. Kategori seçildiğinde alt kategori listesinin daralması, hem seçimi hızlandırır hem de anlamsız kombinasyonları engeller. Bağımlılık kurulmamış iki seviyeli liste, raporda birbiriyle uyumsuz çiftler üretir.

2. 02Doğrulama kuralını dar tanımlayın

   Geniş doğrulama, kullanıcıyı çıkmaza sokar.

   Geniş doğrulama, kullanıcıyı çıkmaza sokar. Kural yalnızca gerçekten hatalı olan durumu engellemelidir. "Yüksek öncelik seçildiyse gerekçe zorunlu" iyi bir kuraldır. "Her talepte üç alan dolu olmalı" değildir.

3. 03Hata mesajını insan diliyle yazın

   Anlaşılmayan hata mesajı, kuralı düşman haline getirir.

   Anlaşılmayan hata mesajı, kuralı düşman haline getirir. "Geçersiz değer" bilgi vermez. "Yüksek öncelik seçtiğiniz için gerekçe alanını doldurmanız gerekiyor" verir. Mesaj, ne yapılması gerektiğini söylemelidir.

4. 04Kuralı canlıya almadan önce gerçek veriyle test edin

   Mevcut kayıtlar yeni kurala uymuyorsa, güncelleme işlemleri kilitlenir.

   Mevcut kayıtlar yeni kurala uymuyorsa, güncelleme işlemleri kilitlenir. Yeni bir zorunluluk, eski kayıtlar düzenlendiğinde de devreye girer. Bu, günlerce süren toplu güncelleme işini beklenmedik biçimde durdurabilir.

Bazı bilgiler ne talebe ne kişiye ne de hesaba sığar. Cihaz envanteri, saha ziyareti, garanti kaydı gibi kendi yaşam döngüsü olan varlıklar bunlardır. Bu noktada özel modül gündeme gelir; en üst sürümün yeteneğidir.

Özel modül kararı için ölçü şudur: bu varlığın kendi durumu, kendi geçmişi ve kendi sahibi var mı? Varsa modüldür. Yoksa bir alan veya bir eklenti listesidir.

• Modül gerektirir: müşteri sahasındaki cihazlar. Her cihazın kendi seri numarası, garanti tarihi ve arıza geçmişi vardır; talepler bu cihazlara bağlanır.
• Modül gerektirmez: talep başına bir kez yazılan referans numarası. Bu bir alandır.
• Modül gerektirir: yinelenen bakım sözleşmeleri. Kendi başlangıç ve bitiş tarihi, kendi kapsamı vardır.
• Modül gerektirmez: talebin çözüm adımları. Bunlar açıklama ve yorum alanında yaşar.

Kurulum sonrasında da alan talebi gelmeye devam eder. Her talebi şu beş soruyla süzün; çoğu bu süzgeci geçemez.

• Bu alanı hangi raporda göreceğiz? Yanıt yoksa alan gereksizdir.
• Kim dolduracak ve ne zaman? "Herkes, uygun olduğunda" yanıtı, alanın boş kalacağı anlamına gelir.
• Bu bilgi başka bir kayıtta zaten var mı? Varsa kopyalamayın, bağlayın.
• Doldurulmazsa ne olur? Hiçbir şey olmuyorsa alan gerçek bir ihtiyaç değildir.
• Altı ay sonra bu alanı kim savunacak? Sahipsiz alan, ilk temizlikte silinecek alandır.

Veri modeli sağlam kurulduğunda otomasyon kolaylaşır; çünkü otomasyon zaten var olan veriye tepki verir. Sıradaki rehber bu tepkileri kurmayı ele alıyor: Otomasyon ve Süreç Yönetimi.