ERP’yi buluta taşımak, bir sunucunun bulunduğu adresi değiştirmekten daha geniş bir projedir. Satın alma, satış, stok, üretim ve finans işlemleri aynı platformda buluştuğu için küçük bir teknik eksik farklı departmanlara yayılabilir. Başarılı bir geçişin ölçütü, yeni ortamın açılması kadar çalışanların iş akışlarını doğru ve güvenli biçimde sürdürebilmesidir.
Bu rehberde belirli bir ERP markasını veya tek bir bulut sağlayıcısını esas almıyoruz. Amaç; mevcut uygulamasını özel, genel veya hibrit bulutta çalıştırmayı değerlendiren işletmelerin karar noktalarını görünür kılmak. CieloSync yaklaşımında keşif, taşıma ve sonraki işletim aynı projenin birbirine bağlı parçalarıdır.
1. Taşınacak şeyi doğru tarif edin
“ERP sunucumuz var” ifadesi plan yapmak için yeterli değildir. Uygulama ve veritabanı sunucuları, raporlama servisleri, dosya ekleri, zamanlanmış işler, lisans bileşenleri ve özel geliştirmeler birlikte listelenmelidir. Sürüm, işletim sistemi, veritabanı motoru, güncel destek durumu ve sorumlu ekip bu envanterde yer almalıdır.
Uygulamanın üreticisi veya yetkili destek kanalıyla hedef ortamın desteklenip desteklenmediğini doğrulayın. Teknik olarak çalışan bir kurulum, destek sözleşmesine uygun olmayabilir. Lisansların yeni işlemci sayısına, sanallaştırma modeline veya barındırma koşullarına göre yeniden değerlendirilmesi gerekebilir. Bu noktaları taşıma gecesinde öğrenmek, maliyet ve takvim kontrolünü zorlaştırır.
2. Bağımlılıkları iş akışları üzerinden keşfedin
ERP’nin konuştuğu sistemleri yalnızca açık portlara bakarak anlamak her zaman mümkün değildir. Ayda bir çalışan muhasebe aktarımı veya belirli vardiyada kullanılan tartı entegrasyonu kısa bir gözlemde görünmeyebilir. Teknik envanteri; finans, depo, üretim ve satış ekiplerinin süreç anlatımlarıyla tamamlayın.
Bağımlı sistemleri birlikte değerlendirmek, geçiş dalgalarının temelidir. Microsoft’un geçiş dalgası planlama dokümanı da ortak veritabanı, kimlik ve bağlantı bağımlılıklarının gruplamaya etkisini açıklar. Kendi ERP projenizde uygulama ile veritabanını ayırmanın veya bazı bileşenleri yerinde bırakmanın sonuçlarını ölçerek karar verin.
- E-ticaret, pazaryeri ve bayi portalı bağlantıları.
- E-belge, kargo, banka ve dış muhasebe servisleri.
- Depo el terminalleri, etiket yazıcıları, tartılar ve üretim cihazları.
- Kimlik doğrulama, dosya paylaşımı ve raporlama araçları.
- Özel API’ler, aktarım dosyaları ve zamanlanmış görevler.
3. Yeni mimariyi mevcut kaynak miktarından ibaret görmeyin
Mevcut sunucunun işlemci ve belleğini aynen kopyalamak hızlı bir başlangıç gibi görünse de gerçek kullanım profilini yansıtmayabilir. Aylık kapanış, toplu fatura üretimi, stok sayımı ve rapor saatlerindeki davranışı inceleyin. Ortalama değerler kadar yoğun dönemleri ve işlemlerin birbirini beklediği noktaları da değerlendirin.
Yavaşlık yalnızca yetersiz işlemciden kaynaklanmaz. Veritabanı sorguları, disk gecikmesi, uygulama tasarımı ve ağ üzerinden tekrar eden küçük istekler de belirleyici olabilir. Yeni ortamda depolama performansını, büyüme alanını ve uygulama-veritabanı arasındaki bağlantıyı birlikte test edin. Kaynak artırımı bazı sorunları gizleyebilir; kalıcı çözüm için darboğazın nerede oluştuğunu belirlemek gerekir.
4. Şubeler, kullanıcılar ve bağlantı kesintileri için plan yapın
Merkezdeki uygulama buluta taşındığında şubelerin bağlantı ihtiyacı değişebilir. Kullanıcıların ERP’ye hangi yolla erişeceğini, kimlik doğrulamasını ve yetkilerini tasarlayın. Uzak masaüstü, uygulamanın web arayüzü veya başka bir erişim modeli seçildiğinde kullanıcı deneyimi ve çevre birimi desteği ayrıca sınanmalıdır.
İnternet bağlantısı kesilen bir deponun ne yapacağı da proje kapsamıdır. İkinci bağlantı, farklı operatör veya kontrollü bir çevrimdışı süreç değerlendirilebilir; tercih maliyet ve iş etkisiyle birlikte yapılır. Her şube için aynı çözüm gerekmez. Tek kasa kullanan küçük bir lokasyonla kesintisiz sevkiyat yapan büyük depo farklı ihtiyaçlara sahiptir.
5. Veri temizliği ile taşıma kapsamını birbirinden ayırın
Yıllardır büyüyen ERP veritabanında eski loglar, gereksiz ekler veya kullanılmayan test kayıtları bulunabilir. Bunların değerlendirilmesi taşıma süresini ve depolama ihtiyacını etkileyebilir. Ancak “temizlik” adı altında kaydın silinmesi ayrı bir karar ve kontrol süreci gerektirir. Saklama yükümlülüklerini veya denetim ihtiyacını teknik ekip tek başına belirlememelidir.
Önce hangi veri kümelerinin taşınacağı, hangilerinin erişilebilir arşivde tutulacağı ve hangi kayıtların silinmesinin onaylandığı yazılmalıdır. Temizlik yapılacaksa canlı geçişle aynı anda birçok değişiklik yapmak yerine ayrı bir çalışma olarak ele alın. Böylece ortaya çıkan farkın kaynağını anlamak ve geri dönmek daha kolay olur.
6. Pilot ortamda gerçek işlemleri temsil edin
Pilot testte yalnızca giriş ekranını açmak yeterli değildir. Satış siparişi, satın alma kabulü, stok hareketi, rapor üretimi ve dosya eki görüntüleme gibi işlemler iş sahipleriyle seçilmelidir. Test verilerinin korunmasına, dış sistemlere yanlış belge gitmemesine ve üretim kimlik bilgilerinin gereksiz kullanılmamasına dikkat edin.
Her senaryo için giriş verisi, beklenen sonuç ve kabul eden kişi belirleyin. “Hızlı görünüyor” yerine seçilmiş bir raporun çalışma süresini, işlemin hata verip vermediğini ve kullanıcıların erişim koşullarını kaydedin. Mevcut ortamla yeni ortamın aynı iş yükü altında karşılaştırılması, yatırım kararına daha anlamlı kanıt sağlar.
7. Kesim planını saatlere ve kararlara bölün
Canlı geçiş planı, kullanıcılara son işlem saatinin bildirilmesiyle başlar. Arka planda veri yazan servislerin, entegrasyonların ve zamanlanmış görevlerin durdurulması gerekebilir. Son veri eşitlemesi yapıldıktan sonra hedef ortam doğrulanır ve erişim yönlendirilir. Her adımın bir sorumlusu ve kontrol sonucu bulunmalıdır.
Örnek olarak cuma gecesi planlanan bir geçişte, cumartesi sabahı deposu çalışan bir şirketin test için sınırlı zamanı olabilir. Takvimi sadece IT ekibinin müsaitliğine göre seçmeyin; üretim, satış kampanyası, sayım ve mali kapanış dönemlerini dikkate alın. Süre tahmini pilotta ölçülen aktarım ve doğrulama sonuçlarına dayanmalıdır.
8. Geri dönüşün veri tarafını açık bırakmayın
Yeni ERP ortamında kullanıcılar işlem yaptıktan sonra eski sunucuyu yeniden açmak basit bir geri dönüş olmayabilir. İki ortamda farklı kayıtlar oluştuğunda bunların nasıl birleştirileceği ayrı bir sorundur. Bu nedenle geri dönüş kararının hangi aşamaya kadar verilebileceğini ve veri yazımı başladıktan sonra hangi prosedürün uygulanacağını tanımlayın.
Geri dönüş tetikleyicileri ölçülebilir olmalıdır: kritik entegrasyonun çalışmaması, kabul edilemez işlem süresi veya veri doğrulama hatası gibi. Kararı verecek kişi, son karar zamanı ve kullanıcı iletişimi önceden belirlenirse sorun anında daha hızlı hareket edilir. Yalnızca bir disk görüntüsünün bulunması bu karar modelinin yerini tutmaz.
9. Taşıma sonrası işletimi teslim edin
Geçiş tamamlandığında izleme eşikleri, yedek politikası, alarm alıcıları ve bakım sorumlulukları devrede olmalıdır. ERP desteği ile altyapı desteği arasındaki sınırı netleştirin. Veritabanı sorununda kimin ilk incelemeyi yapacağı, uygulama güncellemesini kimin onaylayacağı ve olay kayıtlarının nerede tutulacağı açık olmalıdır.
İlk günlerin performansını ve maliyetini düzenli takip edin. Eski ortamı kapatma kararı için de iş onayı, veri doğrulaması ve saklama planı gereklidir. Kullanılmayan kaynaklar açık bırakılırsa hem maliyet hem erişim yüzeyi büyür. Kapatma, proje planında sahibi ve tarihi olan bir teslimat olmalıdır.
ERP bulut geçişi için kabul dosyanızda neler olmalı?
- Güncel envanter, bağımlılık haritası ve üretici destek doğrulaması.
- Hedef mimari, lisans değerlendirmesi ve tahmini işletim maliyeti.
- Pilot test sonuçları ve iş birimi kabul kayıtları.
- Veri aktarımı, kesim, geri dönüş ve mutabakat adımları.
- İzleme, yedekleme, kurtarma ve destek sorumlulukları.
- Eski ortamın kapatılması ve dokümantasyon teslim planı.
CieloSync bulut çözümleri ile mevcut ERP’nizin altyapısını, bağlantılarını ve işletim modelini birlikte değerlendirebiliriz. Geçiş ihtiyacınızı paylaşın; takvimi ve kapsamı varsayımlara değil, keşif ve test sonuçlarına göre oluşturalım.