Kurumsal IT sistemlerinin çoğunda kayıt sahipliği tartışmalıdır. CRM’de daha da fazla.
Esasında bu oldukça politik bir başlık halini alabilir. Neyse ki iyi bir yönetim çoğu CRM veri sahipliği problemini çözebilir.
Çoğu kurumsal uygulamada, bireysel bir kaydın sahipliği o kadar önemli değildir. Evet, gizli bilgileri meraklı gözlerden uzak tuttuğunuzdan emin olmak istersiniz ama bilgiler genellikle bütün bir veri sınıfı olarak ele alınır; “tüm maaşlar”, veya “şu grubun ücretleri” gibi. Bu arada erişim ayrıcalıklarının yönetimi sıklıkla kullanıcı grubu hiyerarşilerinin takip edilmesinden ibarettir.
Bir CRM sistemindeki bazı veriler bu kalıbı izliyor. Söz gelimi, kullanıcılarınızla ilgili veriler için (“isim” veya “telefon” gibi) erişim ayrıcalıkları basit bir yoldan ele alınabilir. Sıra CRM verisine (irtibatlar, ilişkiler, hesaplar, anlaşmalar, vakalar vs.) geldiğinde ise söz konusu kayıtlar için erişim ayrıcalıkları yüksek seviyede bireyselleştirilmiş bir temelde yönetilmelidir. Ayrıcalıkları yanlış belirlediğinizde, yüksek hacimli telefon görüşmeleri aracılığıyla saniyeler içinde bunu fark edeceksiniz.
Bunun temel nedeni satış ekibidir. Onların bakması gereken aileleri vardır ve eğer sizin firmanız prim sistemini yoğun bir biçimde kullanıyorsa, onların güzel bir tatil yapmasının tek yolu anlaşmalar yapmalarıdır. İçinde bulunduğunuz endüstriye ve firmanızın satış kültürüne bağlı olarak, satışçılar neredeyse çılgınlar gibi savunmacı olabilir. Görülebilirliği azaltmak veya onların müşterilerini ve ilişkilerini kontrol etmek çalmakla benzer. Onları suçlayamayız çünkü sadece yönetimin onlara verdiği kurallarla oynuyorlar.
CRM Veri Sahipliği Karmaşıklaşıyor
Çoğu CRM sisteminde görülebilirlik için ilk kontrol noktası kayıt sahibidir. Bu tek bir kullanıcıya atanabilir ve böylelikle “sahip”, “satış ekipleri” ve paylaşımlı erişim sağlayan “destek ekipleri” ile tamamlanabilir. Buna ek olarak sisteminiz global hesaplar için koşullu sahiplik ayrıcalıklarına sahip olabilir; iş akışlarının gün içinde farklı iş bölgelerine aktarıldığı destek modellerinde ve bazen yerel hesap yöneticilerinde görürsünüz. İşleri ilgi çekici tutmak için, birden çok paylaşım seviyesi olabilir.
Bu mekanizmalar karmaşık hale geliyor. Ne yazık ki, gerçekten fantezi sahiplik modelleriyle birlikte, neler olduğunu görmenin sadece iki yolu vardır: Tepeden aşağı, genelin içindeki tüm kural ve kodları inceleyerek, aşağıdan yukarı, özel olarak hazırlanmış test durumlarıyla çalışarak. Burada herhangi bir güzel grafik bulamayacaksınız (en iyi ihtimalle, bir dizi tabloları) ve problem çözümü sıklıkla beyaz tahta ve konferans çağrılarını içerir.
Bir diğer karmaşıklık seviyesi daha mevcut. Çoğu durumda, her bir objenin sahipliği neredeyse tamamen bağımsızdır; siz katı bir ana ayrıntı ilişkisi belirleyene dek. (Gerçekten.) Bu bir hesap sahipliğinin, o hesaptaki irtibat ve durumlar sahipliğinden hemen hemen bağımsız olması manasına gelir. Ayrıcalıkları tanımlayan özel kurallar tipik olarak bağımsızdır ve kodunuzun bir bölümünü tali kayıtları “ana kayıtları izleyecek” şekilde güncellemek üzere yazmadıkça, kayıt güncellemeleri bağımsızdır (Gerçekten.)
Bu da hatalı sahiplikler için tonlarca fırsat manasına geliyor. Örneğin, GM hesabı yeni bir satış ekibine kaydırılmış olabilir. Bu potansiyel müşteriler, irtibatlar, durumlar, fırsatlar ve ikincil kayıtların da kaydırılmış olması demek değildir; veya onların da kaydırılmış olması gerektiği manasına gelmez. Bu tamamen iç ilkelere bağlıdır ve elbette siz bir uygulama ya da sorguyu bunu yapması için yazmadıkça CRM sistemleri bu ilkelerin herhangi birini zorlamayacaktır. Sahip alanı tüm dahili CRM hesaplama türlerinde (söz gelimi bir potansiyel müşterinin içerideki satıştan dışarıdaki bir temsilciye ne zaman ve neden aktarılması gerektiğini belirleyen) kullanıldığından hatalı bir kayıt sahipliği bazı şaşırtıcı dallanmalara neden olabilir.
CRM Verisi Muammasını Yönetimle Çözün
Tüm bunları otomatik olarak güncel tutmak için CRM sistemine güvenemeyeceğinizden, bunu yönetmesi için bir yönetim sistemi ayarlamalısınız; en küçük CRM oturumları içinde bile. Çoğu durumda, büyük bir komite olması gerekmiyor. Tipik olarak bu bir veya iki kişiyle kontrol edilebilir.
Ardından, kim meselesi geliyor. Sistem yöneticisi ayrıcalık ve yeteneklerine sahip birisi olmalı. Bu neredeyse tümden bir veri sorunu olduğundan bir dizi tablo veya küçük bir veritabanı tercih edilen araçlar olacaktır. Ancak SysAdmin’in farklı çeşitleri mevcutsa, bunu da akılda bulundurun.
Benim deneyimime göre bu, pazarlama veya finans tarafından kontrol edilmesi gereken bir şey değil. Onlar yeterli beceri ve bilgiye sahip olsalar da, onlar oyun içindeki ekibin bir parçası değiller.
Tipik olarak satış operasyonları bunun yönetimi için doğru departmandır. Onlar sizi gerçekten önemseyenlerle etkileşim halindedir ve kuralları koyanlara erişimleri vardır. Eğer organizasyonunuz destek ve profesyonel servisleri güç yapısının üzerine yerleştiriyorsa, o zaman bu göreve destek ekibine en yakın SysAdmin sahip olmalıdır.
Dışarıdaki sistemler yeni CRM verisi enjekte ettiğinde, sahiplik değerlerini belirlemeleri veya değiştirmeleri gerekebilir. Genel olarak konuşursak, tüm atama, sahiplik ve yönlendirme mantığının tek bir yerde olmasını tavsiye ediyoruz: ister CRM sistemi içinde isterse de tamamen dışında olsun. Bu mantığı çift taraflı olarak oluşturmak her zaman problem için bir reçetedir. Bunu şimdi doğru olarak alsanız da, zaman içinde yönetmek neredeyse imkansız hale gelir.
Bunun yerine hangi kayda kimin sahip olduğu kararını verdiğinizden ve neden her zaman aynı yerde yapıldığından emin olmak için Web servislerini veya diğer uzak yordam çağrı mekanizmalarını kullanın.
