Üretici gereksinimlerini ve lisansları doğrulayın
Kullanılan ERP sürümünün desteklediği işletim sistemi, veritabanı ve sanallaştırma ortamını belirleyin. Sunucu taşıması veya uzak erişim lisans koşullarını etkileyebilir. Gerekli lisansların kim tarafından sağlanacağı teklif kapsamına yazılmalıdır.
Yazılım sağlayıcısının önerdiği minimum kaynaklar başlangıç içindir. Gerçek kapasite planında modüller, entegrasyonlar, raporlar ve eşzamanlı çalışan kullanıcılar değerlendirilmelidir. Hazır bir kullanıcı sayısına tek bir RAM veya CPU değeri atamak güvenilir bir yaklaşım değildir.
Veritabanı performansını dikkate alın
ERP performansında disk gecikmesi ve veritabanı sorguları belirleyici olabilir. Mevcut veri büyüklüğü, yıl içindeki artış, toplu işlemler ve rapor üretimi gözden geçirilmelidir. Bellek ve depolama kaynakları uygulamanın ihtiyaçlarına göre dengelenir.
Performans sorunu her zaman daha büyük sunucu gerektirmez. Sorgu yapısı, indeksler, uygulama ayarları ve ağ gecikmesi de incelenmelidir. Altyapı sağlayıcısı ile yazılım sağlayıcısının hangi kontrolleri yapacağı baştan belirlenirse sorun çözümü kolaylaşır.
Şube ve uzaktan erişimi planlayın
Birden fazla şubeden erişen kullanıcılar için bağlantı kalitesi, gecikme ve güvenli erişim yöntemi önemlidir. Yönetim arayüzlerini internet üzerinden herkese açık bırakmak yerine erişim kapsamını sınırlayan yöntemler değerlendirilmelidir.
VPN, uzak masaüstü veya uygulamanın kendi erişim modeli için lisanslar ve yetkiler kontrol edilir. Kullanıcıların görevlerine uygun izinleri olması, çalışan ayrılışlarında erişimin kapatılması ve yönetici hesaplarının ayrı tutulması planın parçasıdır.
Taşıma, yedekleme ve kabul testlerini belirleyin
Canlı sisteme geçmeden önce örnek verilerle oturum açma, kayıt oluşturma, rapor alma ve entegrasyon testleri yapılmalıdır. Veri aktarımını kimin gerçekleştireceği, son veri eşitlemesinin zamanı ve geçiş başarısız olursa geri dönüş adımları belirlenmelidir.
Yedek alındığını görmek yeterli değildir; uygulamanın açılabildiği bir geri yükleme testi de gerekir. Kabul edilebilir veri kaybı ve kesinti süresi iş birimleriyle kararlaştırılarak yedek sıklığı ve kurtarma yöntemi buna göre seçilir.
Örnek senaryo: aynı kullanıcı sayısı, farklı sunucu ihtiyacı
İki işletmenin de aynı sayıda ERP kullanıcısı olduğunu varsayalım. Birincisinde ekip gün içinde sipariş giriyor ve kısa raporlar alıyor. İkincisinde üretim hareketleri, stok eşitlemesi ve geniş tarih aralığındaki raporlar aynı anda çalışıyor. Kullanıcı sayısı aynı olsa da veritabanı işlemlerinin miktarı, kayıt büyüklüğü ve eşzamanlı yük farklıdır. Bu yüzden “şu kadar kullanıcıya şu kadar RAM” tablosu, uygulama verileri görülmeden kesin teklif için yeterli olmaz.
Bu örnekte ikinci işletmenin depolama gecikmesine, sorgu yapısına veya belleğe daha fazla dikkat etmesi gerekebilir. İlk işletmenin ihtiyacı daha küçük bir ortamla karşılanabilir. Sonuca örnekten değil, ölçümden ulaşılır. Teklifte uygulamanın yoğun döneminin nasıl ölçüleceği ve testin hangi verilerle yapılacağı konuşulmalıdır.
Ay sonu işlemleri günlük ortalamayı değiştirebilir
Günlük normal kullanımın rahat görünmesi, ay sonu veya dönem kapanışında aynı kaynakların yeterli olacağını göstermez. Toplu faturalama, stok sayımı, maliyet hesapları ve uzun raporlar bazı kurumlarda aynı zaman dilimine gelir. Kaynak planlamasında bu işlemlerin ne zaman başladığı, kaç saat sürdüğü ve kullanıcıların o sırada normal işlerine devam edip etmediği sorulmalıdır.
Ölçümler sadece mesai dışındaki boş saatlerden alınırsa ihtiyaç düşük görünebilir. Uygulama üreticisinin izin verdiği bakım veya toplu işlem takvimi de değerlendirilir. Bir işin geceye alınması yükü azaltabilir; fakat bu kararı iş birimi vermelidir. Altyapı sağlayıcısının kullanıcıların çalışma biçimini bilmesi, otomatik olarak en büyük sunucuyu önermek yerine gerekli kapasiteyi anlamasını sağlar.
Veritabanı ile dosya depolarını ayrı değerlendirin
ERP uygulamasının kullandığı veritabanı kadar ek dosyaları da önemlidir. Belgeler, taramalar, dışa aktarılan raporlar veya paylaşılan klasörler farklı yerlerde tutuluyor olabilir. Taşıma envanterinde bu depoların konumu ve erişim hakları belirtilmezse uygulama açıldığı halde bazı belgeler erişilemez kalabilir. Veritabanı boyutu ile sunucunun toplam disk ihtiyacını bu nedenle aynı sayı olarak kullanmayın.
Yedek kapasitesi de canlı veri alanından ayrı düşünülmelidir. Veritabanı yedeği, arşiv dosyaları ve geçmiş kopyaların büyümesi depolamayı etkiler. Yedek işleri yoğun saatlerde çalışıyorsa performansa etkisi izlenir. Depolama alanı dolduğunda oluşabilecek sorunlara karşı eşik ve alarm sorumlusu belirlenir. Kaynak planı, yalnızca ilk kurulumdaki veri boyutunu değil, verinin hangi hızda arttığını da içermelidir.
Kabul testini muhasebe ve operasyon ekibiyle hazırlayın
Teknik ekip sunucuya bağlanabiliyor olabilir; ancak kabul kararını uygulamayı her gün kullanan ekiplerle vermek gerekir. Kullanıcı oturumu, cari kayıt görüntüleme, sipariş veya fatura işlemi, rapor alma ve çıktı oluşturma gibi adımlar işletmenin gerçek akışından seçilir. Entegrasyon bulunan uygulamalarda stok veya sipariş aktarımı da bu teste eklenir.
Geçişten önce beklenen sonuçlar yazılmalıdır. Örneğin bir raporun açılması, tarih ve toplamlarının doğrulanması ve yetkisiz bir kullanıcının ilgili veriye erişememesi ayrı kontrol noktalarıdır. Test süresince değiştirilen örnek verinin canlı veriye karışmaması gerekir. Böyle bir plan, “program açıldı” kontrolüyle fark edilmeyen sorunları canlı kullanımdan önce ortaya çıkarır.
Arıza anında kurum, yazılım firması ve sunucu sağlayıcısı
ERP çalışmadığında üç farklı ekip devreye girebilir: kurumun IT ekibi, uygulama üreticisi ve altyapı sağlayıcısı. Sunucuya erişim sorunu, veritabanı hatası ve uygulama lisans sorunu aynı kişiye çözdürülemeyebilir. Kayıt açarken hata mesajı, başlangıç saati, etkilenen kullanıcılar ve son yapılan değişiklikler paylaşılmalıdır.
Geri dönüş gerektiğinde hangi yedeğin kullanılacağı ve işlemin iş birimince nasıl kabul edileceği ayrıca kararlaştırılır. Sunucunun tekrar açılması, muhasebe kayıtlarının doğru olduğunu kanıtlamaz. Veri sahibinin son kayıtları ve bekleyen işlemleri kontrol etmesi gerekir. Disket’e ERP altyapısı talebinde kullanılan yazılımı, üretici desteğini ve kurum içindeki görev dağılımını belirtmeniz, hizmet sınırlarının anlaşılmasını kolaylaştırır.
ERP taşıması için örnek kabul tablosu
| İşlem | Kontrol edilecek sonuç | İlgili ekip |
|---|---|---|
| Kullanıcı girişi | Doğru yetkiyle uygulamaya erişim | Kurum ve uygulama ekibi |
| Kayıt sorgulama | Güncel kayıt ve doğru veri | İş birimi |
| Rapor alma | Doğru toplamlar ve gözlenen süre | İş birimi ve uygulama ekibi |
| Dosya açma | Belgelere izinli erişim | Kurum ve altyapı ekibi |
| Entegrasyon | Bekleyen kayıtların doğru aktarımı | Entegrasyon ve uygulama ekibi |
Teklif öncesi kontrol listesi
- ERP sürümü, modüller ve veritabanı bilgisi
- Toplam ve eşzamanlı kullanıcı sayısı
- Şubeler, uzak erişim ve entegrasyonlar
- Veri hacmi, büyüme ve yoğun işlem saatleri
- Geçiş takvimi, lisanslar ve kabul testleri
Sık sorulan sorular
ERP için sabit bir sunucu kapasitesi önerilebilir mi?
Kullanıcı sayısı tek başına yeterli değildir. Yazılım sürümü, modüller, veritabanı ve eşzamanlı iş yükü incelenerek kapasite belirlenmelidir.
Sunucu sağlayıcısı ERP yazılımını da yönetir mi?
Bu sorumluluk hizmet kapsamına bağlıdır. Sunucu yönetimi, veritabanı bakımı ve ERP uygulama desteği ayrı görevler olarak teklifte netleştirilmelidir.
ERP taşımasında başarı nasıl kontrol edilir?
Kurumun günlük iş akışlarından seçilen kullanıcı girişi, kayıt sorgulama, rapor ve entegrasyon işlemleri denenir. Sonuçların doğruluğunu ilgili iş birimi kontrol eder. Yalnızca sunucuya bağlanılması veya programın açılması bütün uygulamanın hazır olduğunu göstermez.
Teknik kaynaklar
Disket Teknoloji’nin sektör faaliyetleri 2014 yılında şahıs şirketi olarak başladı. Bugün hizmetlerimiz Disket Teknoloji Ltd. Şti. bünyesinde sürüyor. Şirket geçmişimiz.