CRM'de kullanıcı rolleri ve yetkiler: ekip büyüyünce kim neyi görmeli?

Ertem Medikal'de dokuzuncu kişi işe alındığında kimse bir şey fark etmedi. On dokuzuncuda fark ettiler. Yeni gelen bir stajyer, ilk haftasında bütün müşteri listesini, açık fırsatların tutarlarını ve geçen yılın iskonto oranlarını tek bir listede görebiliyordu. Kimse kötü niyetli değildi; kimse bir ayar da yapmamıştı. CRM ilk kurulduğunda beş kişiydiler ve herkesin her şeyi görmesi doğal geliyordu. Sorun şu ki o ayar hiç değişmemişti.

Ankara'daki firma 19 kişi: altı satış temsilcisi, bir satış müdürü, iki kişilik servis ekibi, ayda iki gün gelen bir mali müşavir, bir stajyer ve ofisi toparlayan bir yönetici. Medikal sarf malzemesi satıyorlar, müşterilerinin çoğu özel klinik ve hastane. (Demo verisi.) İhtiyaçları bir güvenlik projesi değildi, üç basit cümleydi: temsilci kendi portföyüne baksın, mali müşavir faturaları görsün ama fiyat pazarlıklarını görmesin, stajyer gelen adayları arasın ama müşteri listesini indiremesin.

Bu yazı o üç cümlenin CRM ayarına nasıl çevrildiğini anlatıyor: rol ile yetkinin farkı, en az yetki ilkesi, kimin ne görmesi gerektiği sorusunun pratik cevapları ve Ohana360'ta bu modelin gerçekte nasıl çalıştığı. Kişisel veri tarafındaki yasal çerçeve ayrı bir konu; onu KVKK uyumlu CRM yazısında ele almıştık.

Rol mü, yetki mi? İkisi aynı şey değil

Çoğu ekip bu ikisini tek kelimeyle karıştırır: "Ahmet'in yetkisini satış yaptım." Oysa iki ayrı soru vardır. Rol kişinin kim olduğunu söyler, yetki ne yapabileceğini. Bir kişi satış müdürü olabilir ama faturalara dokunmaması gerekebilir; iki kişi aynı işi yapıyor olabilir ama biri sadece kendi kayıtlarına bakmalıdır.

Ohana360'ta bu ayrım dört ayrı ayara dağılmıştır. Dördü birlikte çalışır ve hangisinin ne yaptığını bilmek, sonradan çıkan "neden bu kaydı göremiyorum" sorularının yarısını baştan keser.

Buna bir de obje başına paylaşım varsayılanı eklenir. Aşağıdaki çizim, bir kaydın bir kullanıcının ekranına düşmeden önce geçtiği beş kapıyı sırayla gösteriyor.

Beş kapının üçünü aynı anda kurcalamak gerekmez. Pratikte kurulum şöyle ilerler: önce herkese bir profil verilir, sonra hassas objelerin paylaşım varsayılanı kısılır, en son tek tek istisnalar paylaşım kuralı ya da yetki setiyle açılır.

En az yetki ilkesi nereden başlar?

En az yetki ilkesi tek cümledir: bir kişi, işini yapmak için gereken en az erişime sahip olmalıdır. Kulağa kısıtlayıcı gelir ama asıl amacı kısıtlamak değildir; kazayı ve belirsizliği azaltmaktır. Yanlışlıkla silinen kayıt, yanlış kişiye giden fiyat listesi ve "bunu kim değiştirdi" tartışması çoğu zaman kötü niyetten değil, gereksiz geniş yetkiden çıkar.

Uygulaması üç adımdır ve ilk ikisi CRM'de değil, kağıtta yapılır.

• Rolleri işe göre yazın, unvana göre değil. "Satış müdürü" bir unvandır; "kendi ekibinin fırsatlarını görür, iskonto onaylar, faturaya dokunmaz" bir iştir. Ayar yazılabilen şey ikincisidir.
• Veriyi hassasiyetine göre ayırın. Çoğu ekipte üç grup çıkar: herkesin görmesi sorun olmayan veri (ürün kataloğu, bilgi bankası), ekip içinde paylaşılan veri (adaylar, talepler) ve dar tutulması gereken veri (fiyat pazarlığı, faturalar, çalışan kayıtları).
• Farkı kapatın, sonra istisnaları açın. Kapalı başlayıp açmak, açık başlayıp kapatmaktan hem güvenli hem kolaydır: açarken kimin neye ihtiyacı olduğunu soruyorsunuz, kapatırken kimin neyi görmemesi gerektiğini tahmin ediyorsunuz.

Satış temsilcisi kendi kayıtlarını mı, tüm kayıtları mı görmeli?

Bu sorunun tek doğru cevabı yok, iki ucu ve bir orta yolu var. Herkesin her fırsatı gördüğü org'da temsilciler birbirinin müşterisini arar, pazarlık geçmişi karışır, ayrılan kişi bütün portföyü dışa aktarır. Herkesin yalnız kendi kaydını gördüğü org'da ise müdür hiçbir şey göremez, izinli temsilcinin müşterisi ortada kalır ve rapor tutmaz.

Ohana360'ta orta yol üç ayarın birleşimidir. İlki paylaşım varsayılanı: Kurulum içindeki Paylaşım Ayarları ekranında her obje için üç seçenekten biri seçilir.

İkincisi rol hiyerarşisi. Kurulumda gelen merdiven beş basamaklıdır (Uzman Yardımcısı, Uzman, Yönetici, Müdür, Genel Müdür) ve org'a göre değiştirilir. Kural basittir: üst basamaktaki kişi, alt basamaklardaki kişilerin sahip olduğu kayıtları görür. Fırsatlar Özel olsa bile satış müdürü ekibinin fırsatlarını görmeye devam eder, çünkü basamağı yukarıdadır.

Üçüncüsü paylaşım kuralları. Bir kural kapalı kapıyı seçilmiş bir hedefe açar: kaynağı sahip bazlı (şu roldeki kişilerin kayıtları, şu rol ve altındakiler, şu grup, şu kuyruk) ya da kriter bazlı (tutarı şu rakamın üstünde olan kayıtlar) tanımlanır, hedefi bir rol, bir genel grup ya da tek bir kullanıcı olur, erişim düzeyi okuma veya okuma ve yazma seçilir. Tipik kullanım: fırsatlar Özel, ama "Satış rolündeki herkesin fırsatları, Servis grubuna okuma olarak açılsın" diye tek bir kural.

Dördüncü bir araç daha var: kuyruklar. Bir kaydın sahibi bir kişi yerine bir kuyruk olabilir; kuyruğun üyeleri o kaydı kendi kayıtları gibi görür ve sahiplenir. Gelen adayların bir havuzda toplanıp sahiplenilmesi gereken düzenlerde, herkesi tek tek yetkilendirmekten çok daha temizdir.

Yönetici, muhasebe ve stajyer nasıl ayrılır?

Ertem Medikal'in kurduğu düzen aşağıdaki tabloda. Dikkat edilecek nokta şu: beş kişinin hiçbiri Admin rolünde değil. Admin rolü profil kısıtlarını ve paylaşım kurallarını tamamen atladığı için, ofisin işleyişi için Kurulum'a girmesi gereken kişiye bile Admin verilmemiş; onun yerine bir yetki seti kullanılmış.

Temsilci (Zeynep). Adaylar ve Fırsatlar objelerinde okuma ve düzenleme Kendi düzeyinde. Faturalar objesi profilinde tamamen kapalı, yani o obje uygulamada hiç görünmüyor. Ekip sohbetine, bilgi bankasına ve ortak ürün kataloğuna erişimi tam.

Müdür (Barış). Profili temsilciyle aynı olabilirdi; farkı hiyerarşi rolünden geliyor. Müdür basamağında olduğu için altındaki basamaktaki altı temsilcinin bütün adaylarını ve fırsatlarını görüyor. Faturalarda okuma var, düzenleme yok: profilde Fatura objesinin okuması Tümü, düzenlemesi Yok.

Mali müşavir (Neslihan). Finansçı profilinde: Fatura, Sipariş ve Tahsilat objelerinde tam yetki; Fırsat ve Kişi objelerinde salt okunur; Aday objesi kapalı. Bu sayede tahsilat takibini yapabiliyor ama iskonto pazarlığının geçmişine giremiyor.

Stajyer (Efe). En dar profil. Fırsatlar ve faturalar kapalı, yalnız Adaylar açık ve o da Kendi düzeyinde. Web formundan gelen adaylar bir kuyruğa düşüyor; Efe kuyruktaki adayları görüp sahipleniyor, sahiplenmediği hiçbir adayı göremiyor. Dışa aktarma yetkisi hiç verilmemiş, çünkü dışa aktarma bir profil ayarı değil, ayrı bir yetki setidir ve varsayılan olarak kimsede açık değildir.

Ofis yöneticisi (Pelin). Kullanıcı açmak, şifre sıfırlamak ve denetim günlüğüne bakmak istiyor ama org ayarlarına dokunması gerekmiyor. Ona Admin rolü yerine Kullanıcı Yöneticisi yetki seti verilmiş. Bu set Kurulum'un yalnızca kullanıcı ve erişim bölümlerini açar; şirket ayarları, fatura ve güvenlik bölümleri kapalı kalır. Üstelik bir sınır daha var: bu yetkiyle Yönetici rolü verilemez ve yönetici hesaplarına dokunulamaz.

Hazır yetki setleri arasında Veri Yöneticisi, Rapor ve Dışa Aktarma, Denetçi, Destek Uzmanı, API Entegratörü ve Kurulum Yardımcısı gibi şablonlar var. Hepsinin ortak mantığı aynı: profili değiştirmeden tek bir hakkı eklemek.

Dışarıdan çalışan için hangi yol doğru?

Serbest çalışan bir tasarımcı, ayda iki gün gelen bir mali müşavir, üç aylık bir stajyer. Bu üç durumda üç farklı cevap var.

• Sizin verinizde çalışacaksa kullanıcı açın, dar profil verin. Mali müşavir örneğindeki gibi. Hesabın kapatılması kolay olduğu için bu en esnek yol.
• Yalnız kendi kayıtlarını görecekse portal kullanıcısı açın. Bir tedarikçi ya da müşteri firma, Portal rolüyle sadece kendi siparişlerini, taleplerini ve paylaşılan belgeleri görür; CRM ekranlarına hiç girmez. Kurulumu müşteri portalı yazısında anlatmıştık.
• Aralıklı geliyorsa hesabı ziyaretler arasında pasifleştirin. Pasif hesap giriş yapamaz, kayıtları ve geçmişi yerinde kalır, bir tıkla geri açılır. Neslihan'ın hesabı ayın iki günü aktif, kalan günlerde pasif.

Stajyer için ek bir alışkanlık: staj başlarken bitiş tarihini takvime bir görev olarak yazın. Süresi biten erişimi kapatmanın en yaygın unutulma sebebi, kapatmayı hatırlatan bir kaydın hiç olmamasıdır.

Kim sildi, kim değiştirdi? İz nerede tutulur?

Yetki düzeni ne kadar iyi kurulursa kurulsun, "bunu kim yaptı" sorusu er geç gelir. Ohana360'ta bunun cevabı tek bir ekranda değil, dört ayrı izde durur.

Bir ayrıntı özellikle önemli: Onun gibi gir (başka bir kullanıcının hesabına geçme) hem Denetim Günlüğü'ne hem Giriş Geçmişi'ne kimin kime geçtiği bilgisiyle yazılır. Bu yetki de ayrı bir yetki setindedir ve yönetici hesaplarına geçilmesine izin vermez.

Biri işten ayrılınca ne yapmalı?

Ayrılık günü yapılacaklar listesi kısa olmalı, çünkü uzun listeler o gün uygulanmaz. Sıra önemli: önce kayıtlar devredilir, sonra erişim kapatılır.

Dahil değil: Ohana360'ın yetki tarafında yapmadıkları

• Alan seviyesinde güvenlik yok. İzinler obje düzeyindedir: bir objeyi tamamen kapatabilir, salt okunur yapabilir ya da Kendi düzeyine indirebilirsiniz, ama tek bir alanı kişiye göre kilitleyemezsiniz. Sayfa düzeninde profil bazlı alan gizleme vardır; bu bir görünüm ayarıdır, güvenlik katmanı değildir. Gerçekten saklanması gereken veriyi ayrı bir objede tutup o objeyi kapatın.
• Tek kayıt paylaşımı yok. "Bu kaydı şu kişiyle paylaş" düğmesi yoktur. Kayıt sayfasındaki Paylaş düğmesi kaydın bağlantısını gönderir, erişim vermez: bağlantıyı alan kişinin yetkisi yoksa kaydı yine göremez. Tekil erişim için paylaşım kuralı, kuyruk üyeliği ya da sahip değişikliği kullanılır.
• Rol hiyerarşisi bir merdivendir, ağaç değil. Basamaklar alttan üste tek sıra halindedir; paralel dallar (ayrı satış kolu, ayrı servis kolu) yoktur. Müdür basamağındaki bir kişi, hangi bölümde olursa olsun, altındaki bütün basamakların kayıtlarını görür. Bölüm bazlı ayrım gerekiyorsa genel gruplar ve paylaşım kurallarıyla kurulur.
• Uygulama erişimini kapatmak veriyi kapatmaz. Profilde bir uygulamayı kapatmak onu Uygulama Başlatıcı'dan kaldırır. O uygulamanın kayıtlarının da görünmemesi için aynı profilde ilgili objelerin okumasını Yok yapmanız gerekir. Hazır profiller bu ikisini birlikte kurar, kendi profilinizi yazarken atlamayın.
• IP ve giriş saati kısıtı yok. Şifre politikası, org geneli zorunlu iki aşamalı doğrulama ve oturum süresi ayarı vardır; "yalnız ofis IP'sinden" ya da "yalnız mesai saatlerinde" girilsin kuralı yoktur.
• Cihazlar listesi tarayıcı oturumlarını göstermez. Kurulum > Cihazlar ve Oturumlar yalnız mobil ve masaüstü uygulamasının oturumlarını listeler. Tarayıcı oturumları listede görünmez; onları düşürmek için kullanıcı satırındaki Tüm oturumlarını kapat kullanılır.
• Denetim günlüğü sınırsız değil. Org başına en son 1000 yönetim işlemi tutulur. Alan Geçmişi ayrı bir eklentidir ve yalnız açıldıktan sonraki değişiklikleri yazar, geçmişe dönük iz üretmez.
• Yetki setleri yetki eksiltmez. Tasarım gereği yalnız ekler. Bir kişiden bir hakkı almak için setini kaldırmanız ya da profilini değiştirmeniz gerekir.

İlk hafta: yetki düzenini kurma takvimi

Yedinci gündeki sınama en değerlisidir. Yetki düzeninin doğru olup olmadığı ayar ekranından değil, kullanıcının ekranından anlaşılır. Ertem Medikal bu turda iki şey buldu: servis ekibi fiyat listesini hâlâ görüyordu ve stajyerin profili aslında hiç atanmamıştı. İkisi de on dakikada düzeldi, ama sorulmasaydı aylarca öyle kalacaktı.

Sık sorulan sorular