NetSuite projelerinde en çok konuşulan an canlıya geçiş günüdür. Oysa sahada gördüğümüz şu: Go-live'ı başarılı kılan şey o gün yapılanlar değil, önceki haftalarda verilen kararlar ve sonraki 30 günde gösterilen disiplindir. Bu yazıda, Türkiye merkezli ve yurt dışı iştirakleri olan şirketlerde uyguladığımız canlıya geçiş yaklaşımını adım adım paylaşıyoruz.
Canlıya geçiş bir gün değil, bir süreçtir
Canlıya geçişi tek bir tarih olarak planlayan ekipler genellikle son haftada sıkışır. Daha sağlıklı yaklaşım, geçişi üç evreye ayırmaktır: hazırlık (cut-over planı ve provalar), geçiş penceresi (eski sistemin dondurulması, verilerin aktarılması ve ilk işlemler) ve hypercare (canlı sonrası yoğun destek dönemi). Her evrenin sahibi, çıktısı ve onay kriteri baştan yazılı olmalıdır. Proje başında belirlenen gerçekçi beklentiler de bu kriterlerin temelini oluşturur.
1. Cut-over planı: Kim, neyi, ne zaman yapacak?
Cut-over planı, geçiş haftasındaki her adımı saat bazında gösteren bir çalışma listesidir. İyi bir planda en az şu başlıklar yer alır:
Eski sistemin dondurulma zamanı: Hangi tarihten sonra eski sistemde fatura, irsaliye veya ödeme kaydı açılmayacağı net olmalı.
Aktarım sırası: Önce ana veriler, sonra açık kalemler, en son bakiyeler. Sıra bozulduğunda bağımlı kayıtlar hata verir.
Sorumlu ve yedek kişi: Her adım için bir sahip ve ulaşılamadığında devreye girecek bir yedek.
Kontrol noktaları: Her aktarımdan sonra hangi raporla, kim tarafından doğrulama yapılacağı.
Geri dönüş planı: Kritik bir sorun çıkarsa eski sisteme hangi koşullarda dönüleceği.
Bu planı en az bir kez, mümkünse iki kez sandbox ortamında prova etmenizi öneriyoruz. Provalar hem süreleri gerçekçi hale getirir hem de veri şablonlarındaki hataları canlıdan önce ortaya çıkarır.
Plana bir de iletişim takvimi eklemeyi unutmayın. Müşterilere ve tedarikçilere fatura formatının veya banka bilgilerinin değişip değişmeyeceği, iç ekiplere ise eski sistemin hangi gün salt okunur hale geleceği önceden duyurulmalıdır. Bu küçük adım, geçiş haftasında gelen telefon ve e-posta trafiğini ciddi ölçüde azaltır.
2. Açılış bakiyeleri ve veri aktarımı
Ana veriler
Müşteri, tedarikçi, ürün, hesap planı ve banka hesapları ilk aktarılan verilerdir. Burada en sık yaşanan sorun, eski sistemdeki tekrar eden ve pasif kayıtların olduğu gibi taşınmasıdır. Aktarımdan önce bir veri temizliği turu yapmak, canlı sonrası raporların güvenilirliğini doğrudan etkiler. Vergi numarası, adres ve ödeme koşulu gibi alanların e-Fatura süreçleri için eksiksiz olması da bu aşamada kontrol edilmelidir.
Açık kalemler
Kapanmamış müşteri ve tedarikçi faturaları, açık siparişler ve avanslar genellikle belge bazında aktarılır. Böylece canlıdan sonraki ilk tahsilat ve ödemeler doğru faturalarla eşleştirilebilir. Dövizli açık kalemlerde orijinal döviz tutarı ve işlem kuru ayrı ayrı taşınmalı; aksi halde ilk kur değerleme çalışmasında beklenmeyen kur farkları oluşur.
Bakiyeler ve mutabakat
Mizan bakiyeleri, açık kalemlerle çift kayıt oluşmayacak şekilde aktarılmalıdır. Pratikte açık kalemleri ilgili cari hesaplara, kalan bakiyeleri ise bir geçici açılış hesabı üzerinden yevmiye kaydıyla almak yaygın bir yöntemdir. Aktarım sonunda geçici hesabın sıfırlanması, mutabakatın tamamlandığının en net göstergesidir. Stok tarafında ise miktarlar lokasyon bazında, maliyetler kullanılacak maliyetleme yöntemine uygun şekilde girilmelidir.
3. Türkiye'ye özgü kontrolleri unutmayın
Yerel mevzuat gereklilikleri (Türkiye lokalizasyonu) go-live listesinde ayrı bir blok olarak yer almalıdır. Detaylar şirketin yapısına ve kullandığı entegratöre göre değişse de genel kontrol listesi şöyledir:
e-Fatura ve e-Arşiv entegrasyonunun canlı ortamda test faturası ile doğrulanması ve belge numara serilerinin eski sistemle çakışmayacak şekilde ayarlanması.
KDV kodlarının ve tevkifat senaryolarının gerçek işlem örnekleriyle denenmesi.
TCMB kur entegrasyonunun canlı ortamda çalıştığının ve doğru kur tipinin kullanıldığının teyit edilmesi.
e-Defter tarafında geçişin hangi dönemden itibaren yeni sistemden yapılacağının mali müşavirinizle birlikte netleştirilmesi.
Yurt dışı iştirakleri olan gruplarda (OneWorld ile çoklu firma yapısı) her subsidiary için ayrı bir kontrol listesi tutmak, yerel gereklilikleri birbirine karıştırmamanın en kolay yoludur.
4. Kullanıcı hazırlığı ve rol yetkileri
Teknik olarak kusursuz bir geçiş bile, kullanıcılar ilk gün ne yapacağını bilmiyorsa sorunlu görünür. Eğitimleri genel ekran turu yerine, her rolün ilk hafta yapacağı gerçek işlemler üzerinden kurgulamak çok daha etkilidir: satış ekibi için sipariş ve irsaliye, muhasebe için tahsilat ve banka mutabakatı, depo için mal kabul ve sevkiyat gibi.
Rol ve yetkiler de canlı öncesi mutlaka test edilmelidir. Provada yönetici rolüyle çalışıp canlıda kısıtlı rollerle karşılaşmak, ilk günün en sık destek talebidir. Onay akışlarının (satın alma, ödeme, yevmiye) doğru kişilere düştüğünü de bu aşamada doğrulayın.
5. Go / No-Go kararı
Geçiş tarihinden birkaç gün önce, proje ekibi ve iş birimi yöneticileriyle yazılı kriterlere dayanan bir karar toplantısı yapılmalıdır. Kriterler örneğin şunlar olabilir:
Son provada kritik seviyede açık hata kalmadı.
Mizan, açık kalem ve stok mutabakatları ilgili sorumlular tarafından onaylandı.
e-Belge entegrasyonu ve banka bağlantıları canlı ortamda test edildi.
Tüm kullanıcılar kendi rolleriyle sisteme giriş yaptı ve temel işlemlerini denedi.
Hypercare destek planı ve iletişim kanalları duyuruldu.
Kriterlerden biri karşılanmıyorsa tarihi birkaç gün kaydırmak, eksik bir sistemle canlıya geçip haftalarca düzeltme yapmaktan neredeyse her zaman daha ucuzdur.
6. Canlı sonrası ilk 30 gün
İlk hafta: Günlük kontrol
İlk hafta proje ekibi ve kilit kullanıcılarla her gün kısa bir durum toplantısı yapılmalıdır. Açılan destek talepleri tek bir listede toplanmalı, önceliklendirilmeli ve kullanıcıya geri bildirim verilmelidir. Bu dönemde özellikle e-Fatura gönderimleri, banka hareketleri ve stok hareketleri günlük olarak izlenmelidir.
İlk ay kapanışı: Gerçek sınav
Canlı sonrası ilk ay sonu kapanışı, sistemin gerçekten oturup oturmadığını gösterir. Kur değerleme, amortisman, tahakkuklar, şirketler arası mutabakat ve konsolidasyon adımlarını ilk kapanışta proje ekibiyle birlikte yapmak; sonraki aylarda ekibin bunu kendi başına yürütmesini sağlar. Kapanış adımlarını bir kontrol listesine dönüştürüp her ay aynı sırayla uygulamak kalıcı bir alışkanlık yaratır.
Sık yapılan hatalar
Veri temizliğini canlı sonrasına ertelemek.
Provayı sadece teknik ekiple yapıp iş birimlerini dahil etmemek.
Eski sistemi dondurmadan paralel kayıt girmeye devam etmek.
Hypercare dönemini kısa tutup ilk ay kapanışını desteksiz bırakmak.
Sık Sorulan Sorular
NetSuite'e canlıya geçiş ne kadar sürer?
Geçiş penceresinin kendisi genellikle birkaç gün sürer. Ancak hazırlık ve provalar birkaç hafta alır, hypercare dönemi de en az canlı sonrası ilk ay sonu kapanışına kadar devam etmelidir. Toplam süre veri hacmine, şirket sayısına ve entegrasyonlara göre değişir.
Canlıya geçiş için en uygun zaman ne zaman?
Pratikte bir ayın veya çeyreğin başı tercih edilir; böylece açılış bakiyeleri kapanmış bir dönemden alınır. Yoğun satış dönemlerinden ve yıl sonu kapanışının hemen öncesinden kaçınmak riski azaltır.
Eski sistemdeki tüm geçmiş hareketleri taşımak gerekir mi?
Çoğu projede gerekmez. Genellikle ana veriler, açık kalemler ve bakiyeler taşınır. Geçmiş hareketler raporlama ihtiyacına göre özet olarak alınır ya da eski sistem salt okunur bir arşiv olarak bir süre tutulur.
Hypercare dönemi ne kadar sürmeli?
En az canlı sonrası ilk ay sonu kapanışını kapsamalıdır. Kapanış adımları ekip tarafından desteksiz yürütülebilir hale geldiğinde ve açık destek talepleri azaldığında hypercare sonlandırılabilir.
Sonuç
Başarılı bir NetSuite canlıya geçişi şansa değil, iyi hazırlanmış bir cut-over planına, temiz veriye ve disiplinli bir hypercare dönemine dayanır. Minexa olarak Türkiye'de ve yurt dışında NetSuite projelerinde bu süreci baştan sona yönetiyoruz. Canlıya geçiş planınızı birlikte gözden geçirmek isterseniz bizimle iletişime geçebilirsiniz.
