TR / EN

ERP Lisanslamasında Full User ve Limited Task User Nasıl Ayrılır?

ERP bütçesi hazırlanırken kullanıcı listesindeki herkese aynı lisansı vermek en kolay yöntemdir; genellikle en doğru yöntem değildir. Bir projede depo çalışanı mal kabul yapıyor, bakım teknisyeni iş emri kapatıyor, yönetici yalnızca onay veriyor ve finans uzmanı çok sayıda modülde kayıt oluşturuyordu. Hepsini “ERP kullanıcısı” başlığı altında saymak hem gereksiz maliyet hem de yanlış yetki tasarımı doğuruyordu.

Full User ve Limited Task User ayrımı ürün broşüründeki kısa tanımlarla yapılamaz. Lisans hakları sözleşme ve sürüme göre değişebilir; ayrıca teknik olarak yapılabilen işlem lisans açısından izinli olmayabilir. Biz önce kişileri değil işleri sınıflandırdık, sonra rol paketlerini lisans koşullarıyla eşleştirdik. Böylece görüşme fiyat pazarlığından önce gerçek kullanım modeline dayandı.

Sorunun ortaya çıkışı

İlk kullanıcı sayısı departman yöneticilerinden istenmiş ve sisteme erişebilecek herkes full lisans olarak yazılmıştı. Ancak bazı kişiler ayda birkaç onay yapacak, bazıları dashboard görecek, bazıları ise üretim ve finans süreçlerinde yoğun işlem gerçekleştirecekti. Vardiyalı büyüme ve dış hizmet kullanıcıları hesaba katılmamıştı. Bu liste üzerinden alınan teklif ileride gerçek kullanım ve denetim sorunu yaratabilirdi.

İlk belirtiler ve yanlış varsayımlar

Unvanı yönetici olan herkesin full, saha çalışanının limited olması gerektiği varsayıldı. Oysa yönetici bütçe düzenleyebilir, teknisyen farklı modüllerde planlama yapabilir. “Sadece okuyor” ifadesi de yeterli değildi; rapor üretme, veri dışa aktarma ve toplu işlem hakları farklı olabilir. Named user lisansını vardiya hesabıyla paylaşmak maliyet düşürmez; sözleşme ve izlenebilirlik riski yaratır.

Teknik analiz

Her rol için ekran adı yerine iş fiili yazdık: talep oluşturur, mal kabul eder, iş emri planlar, mali kayıt girer, workflow onaylar veya rapor görüntüler. İşlem sıklığı, modül kapsamı, veri değiştirme yetkisi ve görev ayrılığı eklendi. Bu matrisi üreticinin güncel lisans tanımı ve sözleşme maddeleriyle doğruladık. Geçici proje kullanıcıları, entegrasyon hesapları ve mobil kullanım ayrıca değerlendirildi.

Uygulanan çözüm veya önerilen mimari

Rol kataloğunu Full, Limited Task, Self-service ve salt raporlama adayları olarak grupladık; nihai sınıfı üreticinin yazılı teyidiyle belirledik. Kimlik yaşam döngüsü İK ana verisine bağlandı. Kullanıcı rol değiştirince lisans ihtiyacının yeniden değerlendirilmesi için workflow kuruldu. Lisans havuzuna büyüme payı eklendi ancak belirsizliği büyük bir yedek alımla örtmedik. Üç aylık kullanım ve yetki gözden geçirmesi planlandı.

Alternatifler ve karar gerekçesi

Concurrent lisans bazı platformlarda vardiyalı kullanım için uygun olabilir, fakat her ürün sunmaz ve kapasite tepe anına göre boyutlanır. İş ortakları için portal veya self-service lisansı daha doğru olabilir. BI aracı, ERP’ye salt raporlama amacıyla giren kullanıcı sayısını azaltabilir; bunun veri güvenliği ayrıca yönetilmelidir. Kararı yalnız ilk yıl fiyatına değil, beş yıllık rol büyümesi ve sözleşme esnekliğine göre verdik.

Güvenlik ve operasyonel riskler

Lisansı düşürmek amacıyla yetkiyi yapay biçimde bölmek kontrol boşluğu yaratabilir. Ortak hesaplar bireysel iz bırakmadığı için kullanılmadı. Full lisans verilen kişinin otomatik olarak geniş yetki almaması sağlandı; lisans hakkı ile uygulama rolü ayrı kavramlardır. Sözleşme yorumları yazılı teyit edildi, kullanım ölçümü kişisel performans takibine dönüştürülmedi ve ayrılan çalışanların erişim ile lisansı zamanında geri alındı.

Çıkarılan Dersler

Kontrol Listesi