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

Bir maden işletmesinde ERP görüşmesi finans ekranlarıyla başladığında toplantının önemli bölümü doğru sorular sorulmadan geçebilir. Muhasebe, vergi ve genel satınalma elbette zorunludur; fakat cevher hareketi, ekipman bakımı, laboratuvar sonucu, vardiya tüketimi ve proje maliyeti farklı dosyalarda kaldığında yönetim aynı işletmeye ait birden fazla gerçekle karşılaşır. Finansal kapanış düzgün olsa bile operasyonel karar gecikebilir.

Business Central, Dynamics 365 Finance and Supply Chain, IFS ve benzeri platformların her birinin güçlü olduğu alanlar ve farklı uygulama yükleri vardır. Ürün adından önce işletme modelini anlamak gerekir. Biz seçim çalışmasını demo özelliklerinden değil, ocaktan veya yer altından başlayıp stok, işleme, satış ve finans kaydına uzanan uçtan uca senaryolardan yürüttük.

Sorunun ortaya çıkışı

Mevcut sistem temel muhasebe ve bordro ihtiyacını karşılıyor, ancak bakım planları ayrı uygulamada, depo hareketleri tabloda, laboratuvar sonuçları başka bir veritabanında tutuluyordu. Ekipman duruşunun üretim ve maliyet etkisi ancak ay sonunda elle birleştirilebiliyordu. Yeni ERP talebi önce finans yenilemesi gibi tanımlandı. Süreç haritası çıkarıldığında asıl ihtiyacın varlık yoğun operasyonu bütünleştirmek olduğu ortaya çıktı.

İlk belirtiler ve yanlış varsayımlar

“Her ERP aynı muhasebeyi yapar, geri kalanı özelleştiririz” varsayımı tehlikeliydi. Yoğun özelleştirme yükseltme ve destek maliyetini artırır. Diğer uçta, sektör etiketli ürünün tüm süreçleri hazır getireceği düşünülebilir; yerel mevzuat, işletme yöntemi ve entegrasyonlar yine çalışma ister. En çok ekranı gösteren demo da en uygun çözüm değildir. Kritik senaryonun standartta ne kadar karşılandığı ölçülmelidir.

Teknik analiz

Üretim miktarı ve kalite, varlık hiyerarşisi, önleyici bakım, yedek parça, seri ve lot takibi, laboratuvar entegrasyonu, saha bağlantısı, proje bütçesi ve birim maliyet için gereksinimler yazıldı. Her madde must-have, differentiator veya sonraki faz olarak sınıflandı. Offline çalışma, mobil kullanım, API, raporlama, yerel destek ve veri taşıma kapasitesi incelendi. Tedarikçilere aynı uçtan uca senaryolar canlı gösterim için verildi.

Uygulanan çözüm veya önerilen mimari

Önerilen mimari ERP’yi finans, tedarik, stok, proje ve varlık kayıtlarının omurgası yaptı; uzman saha ve laboratuvar sistemleri doğrulanmış entegrasyonlarla bağlı kaldı. Ana veri sahipleri ekipman, malzeme, lokasyon ve maliyet merkezi bazında belirlendi. Fazlandırma önce temel finans ve tedarik, sonra bakım ve üretim, ardından ileri planlama olacak şekilde risk bazlı yapıldı. Her faz için veri, süreç ve kabul sahibi atandı.

Alternatifler ve karar gerekçesi

Daha hafif bir finans ERP’si hızlı ve düşük maliyetli olabilir; uzman bakım ve üretim araçlarıyla entegrasyon olgunluğu varsa geçerli seçenektir. Geniş kurumsal platform daha bütünleşik yapı sunar fakat proje kapasitesi ve değişim yönetimi ister. Best-of-breed yaklaşımı fonksiyon derinliği sağlar, veri ve entegrasyon yönetişimini zorlaştırır. Kararı marka büyüklüğüne değil, standart uyum, toplam sahip olma maliyeti ve kurumun işletme kapasitesine dayandırdık.

Güvenlik ve operasyonel riskler

ERP kesintisi saha ve finansı aynı anda etkileyebileceği için yüksek erişilebilirlik, yedekleme ve geri dönüş testleri tasarıma dahil edildi. Görev ayrılığı; tedarikçi açma, sipariş, mal kabul ve ödeme zincirinde test edildi. Saha entegrasyonları doğrudan geniş veritabanı yetkisiyle kurulmadı. Ticari tekliflerde gerçek üretim ve rezerv verisi paylaşılmadı; maskelenmiş senaryolar kullanıldı. Bulut veya şirket içi tercihte veri konumu ve bağlantı bağımlılığı değerlendirildi.

Çıkarılan Dersler

Kontrol Listesi