ERP Geçişinde Veri Taşıma Riskleri: Hangi Hatalar Projeyi Sarpa Sardırır?

Bir işletme sahibi, yeni sisteme geçişten üç hafta sonra hâlâ eski programı kapatamadığını anlatıyordu. Sebep yazılımın eksik olması değildi — geçiş sırasında bazı cari hesapların iki kez, bazı stok kartlarının hiç taşınmamış olmasıydı. Ekip, yeni sistemdeki rakamlara güvenip güvenmeyeceğini bilemediği için hem eski hem yeni programı paralel tutmaya devam etti. Proje kâğıt üzerinde tamamlanmıştı, fiilen bitmemişti.

ERP projelerinde yaşanan gecikmelerin büyük bölümü yazılımın kendisinden değil, veri taşıma aşamasında alınan kararlardan kaynaklanır. Yazılım seçimi haftalar sürebilir, ama asıl kırılma noktası genelde geçiş haftasında ortaya çıkar. Bu yazı, o haftaya girmeden önce görülmesi gereken riskleri ve bunları küçültmenin pratik yollarını ele alıyor.

Veri taşımada en sık görülen hata nedir?

Tek bir hata değil, birbirini besleyen üç hata kalıbı var:

Kaynağı temizlemeden taşımak. Eski programda yıllar içinde birikmiş mükerrer cari kartlar, kapanmış ama silinmemiş stok kodları, yanlış yazılmış vergi numaraları yeni sisteme olduğu gibi aktarılır. Yeni ekran daha modern görünür ama altındaki veri aynı karışıklığı taşır — sorun çözülmez, sadece yeni bir arayüzde devam eder.

Açılış bakiyesini son ana bırakmak. Cari, stok ve demirbaş açılış bakiyeleri geçiş gününe kadar netleşmezse, ilk faturalar ya eksik ya da çift kayıtlı bakiyeler üzerine kesilir. Bu farkın düzeltilmesi, açılışta bir gün ayırmaktan çok daha uzun sürer çünkü artık üzerine yeni işlem birikmiştir.

Geri dönüş planı olmadan başlamak. Taşıma sırasında bir sorun çıktığında eski sisteme dönülüp dönülemeyeceği, kimin karar vereceği ve ne kadar süre tanınacağı önceden netleşmemişse, ekip sorunla karşılaştığında ya taşımaya devam eder ya da belirsiz bir şekilde durur. İkisi de kontrolsüz bir durumdur.

Bu üç kalıbın ortak noktası, hepsinin proje planında "veri taşıma" tek bir madde olarak geçmesi ama gerçekte üç ayrı disiplin (temizlik, doğrulama, geri dönüş) gerektirmesidir.

Mükerrer ve eksik kayıt neden bu kadar pahalıya patlar?

Aynı müşteri iki farklı cari kodla sistemde duruyorsa, satış ekibi kredi limitini yanlış hesaplar, tahsilat ekibi vadesi gelmiş bakiyeyi eksik görür, finans raporu ciroyu ya şişirir ya da eksik gösterir. Sorun tek bir ekranda değil, o veriye dayanan her rapor ve her kararda tekrar eder.

Pratik karşılığı şudur: geçişten önce harcanan bir günlük veri temizliği, geçişten sonra harcanacak haftalarca süren düzeltme ve güven kaybını önler. Temizlik adımı atlandığında maliyet ortadan kalkmaz, sadece geçiş gününden sonraki aylara yayılır — ve o zaman fark edilmesi daha zordur çünkü üzerine yeni işlemler binmiştir.

Deneme taşıması neden atlanmamalı?

Asıl geçişten önce küçük bir örnek veri setiyle bir "deneme taşıması" yapmak, projedeki en ucuz ama en çok atlanan adımdır. Mantık basittir: tüm cari, stok ve fatura geçmişini tek seferde taşımadan önce, örneğin son üç ayın hareketli 30-40 cari kartını ve bunlara bağlı işlemleri yeni sisteme aktarıp sonucu kaynakla karşılaştırmak.

Bu deneme, gerçek taşımadan önce üç soruyu yanıtlar:

• Alan eşleşmesi doğru mu? Eski programdaki "vergi no" alanı yeni sistemde doğru sütuna mı düşüyor, yoksa "vergi dairesi" ile mi karışıyor?
• Bakiye hesaplama mantığı tutarlı mı? Vadeli/vadesiz ayrımı, döviz cinsinden cari bakiyeler, kısmi tahsilatlar doğru toplanıyor mu?
• Ne kadar sürüyor? Küçük bir örnek setin taşınma süresi, tüm veritabanının taşınma süresini tahmin etmeye yarar — geçiş günü için ne kadarlık bir pencere gerektiğini önceden gösterir.

Deneme taşıması sırasında bulunan bir hata, ucuza mal olur: sadece 30-40 kayıt yeniden kontrol edilir. Aynı hata gerçek taşımada fark edilirse, düzeltme binlerce kayıt üzerinde tekrarlanır ve üzerine yeni işlemler binmiş olabilir. Bu yüzden deneme taşıması "vakit kaybı" değil, gerçek taşımanın süresini kısaltan bir adımdır.

Paralel çalışma dönemi ne kadar sürmeli?

Eski ve yeni sistemi aynı anda çalıştırmak, geçiş riskini azaltan en somut yöntemdir — ama süresi belirsiz bırakılırsa kendisi bir soruna dönüşür. Çok kısa tutulursa hatalar fark edilmeden üretime geçilir; çok uzun tutulursa ekip hangi sistemin "gerçek" kabul edileceğini bilemez, çift veri girişi kalıcı bir alışkanlık haline gelir.

Pratikte işe yarayan yaklaşım, paralel dönemi sabit bir takvime değil, belirlenmiş kontrol noktalarına bağlamaktır:

• Açılış bakiyeleri iki sistemde de eşleşiyor mu? Cari, stok ve kasa/banka bakiyeleri karşılaştırılır; fark varsa kaynağı bulunmadan bir sonraki adıma geçilmez.
• Bir tam işlem döngüsü (teklif → sipariş → irsaliye → fatura) yeni sistemde sorunsuz tamamlanıyor mu? Ekranların açılması yetmez, uçtan uca akışın hatasız çalışması gerekir.
• Mali müşavir e-Defter ve e-Fatura çıktısını yeni sistemden test etti mi? Bu adım beyanname döneminden önce yapılmazsa, sorun en kötü zamanda — beyan gününde — ortaya çıkar.

Üç kontrol noktası da geçildiğinde paralel çalışma sonlandırılır; geçmediyse, takvim ne olursa olsun eski sistem açık tutulur.

Geçiş sırasında kim hangi kararı verir?

Veri taşıma projelerinde en çok zaman, teknik sorundan değil, "bu farkı kim onaylayacak" belirsizliğinden kaybedilir. Açılış bakiyesinde küçük bir fark bulunduğunda muhasebe mi düzeltir, satın alma mı, yoksa geçiş projesini yürüten kişi mi karar verir — bu netleşmemişse, fark günlerce beklemede kalır.

Sorunu önceden küçültmenin yolu, geçiş öncesinde üç rolü yazılı olarak netleştirmektir:

Rol	Sorumluluk
Veri sahibi (muhasebe/satış/depo)	Kendi alanındaki (cari, stok, demirbaş) açılış bakiyesini onaylar
Geçiş sorumlusu	Taşıma takvimini yönetir, kontrol noktalarının geçilip geçilmediğine karar verir
Mali müşavir	e-Defter/e-Fatura/KDV çıktılarının yeni sistemde doğru üretildiğini test eder

Bu tablo proje başında doldurulmazsa, geçiş haftasında herkes birbirinin karar vereceğini bekler ve süre uzar.

Küçük ekipler için de aynı disiplin gerekli mi?

Evet — ölçek küçüldükçe risk azalmaz, sadece görünmez hale gelir. Beş-on kişilik bir işletmede tek bir kişi hem satış hem stok hem muhasebe verisini taşıyorsa, kontrol noktası eksikliği daha hızlı fark edilir ama düzeltecek yedek kişi de olmayabilir. Küçük ekiplerde açılış bakiyesi doğrulamasını atlamak, büyük ekiplere göre daha az veri üzerinde yapılsa bile aynı oranda hataya açıktır; sadece hatanın fark edilme süresi daha kısa ya da daha uzun olabilir, ekip büyüklüğüne göre değişir.

Birasyo'da veri taşıma nasıl kontrol altında tutuluyor?

Birasyo'nun Hızlı Devreye Alma modülü, yukarıdaki riskleri proje adımlarına dönüştürür: taşıma öncesinde kaynak veride mükerrer cari ve stok kartı taraması yapılır, sonuç raporu ekiple paylaşılır; açılış bakiyeleri cari, stok ve demirbaş bazında ayrı ayrı onaya sunulur; e-Defter ve e-Fatura çıktıları mali müşavirin erişimiyle geçiş haftasından önce test edilir. Eski program kapatılmadan paralel çalışma dönemi tanımlanır ve yukarıdaki üç kontrol noktası (bakiye eşleşmesi, uçtan uca işlem döngüsü, mali müşavir testi) geçilmeden üretime tam geçiş önerilmez. Geçiş sorumluluğu tek bir kişide toplanmaz; atanan kurulum danışmanı süreç boyunca ekiple birlikte ilerler.

Özet

• ERP projelerinde gecikmenin çoğu yazılımdan değil, veri taşıma aşamasındaki üç hatadan kaynaklanır: kaynağı temizlemeden taşımak, açılış bakiyesini son ana bırakmak, geri dönüş planı olmadan başlamak.
• Mükerrer veya eksik kayıt tek bir ekranda kalmaz; ona dayanan her rapor ve karar hatayı tekrar eder — bu yüzden geçiş öncesi temizlik, geçiş sonrası düzeltmeden çok daha ucuzdur.
• Paralel çalışma dönemi sabit bir takvime değil, üç kontrol noktasına (bakiye eşleşmesi, uçtan uca işlem döngüsü, mali müşavir testi) bağlanmalıdır.
• Geçiş sırasında kimin hangi farkı onaylayacağı proje başında yazılı olarak netleşmezse, en çok zaman teknik sorundan değil karar belirsizliğinden kaybedilir.
• Küçük ekiplerde de aynı disiplin geçerlidir; ölçek küçüldükçe risk azalmaz, yalnızca fark edilme hızı değişir.