Odoo Veri Taşıma İçin 7 Adım: Eski ERP’den Güvenli Geçiş Rehberi

Odoo veri taşıma, eski ERP veya dağınık sistemlerdeki müşteri, ürün, muhasebe ve operasyon verilerinin yeni yapıya kontrollü biçimde aktarılmasıdır. Başarılı bir geçiş için asıl kritik nokta yalnızca veriyi taşımak değil; veriyi temizlemek, doğru alanlara eşlemek, test etmek ve canlıya geçiş sonrası doğrulamayı eksiksiz yapmaktır. Türkiye’de e-Fatura, e-Arşiv, cari hesap, bordro ve stok gibi alanlarda bu disiplin kurulmadan yapılan geçişler, kullanıcı alışkanlığından çok veri kalitesi nedeniyle sorun çıkarır.

Öne Çıkanlar

• ERP geçişlerinde en büyük risk yazılım seçimi değil, kirli ve tutarsız verinin yeni sisteme aynen taşınmasıdır.
• Veri taşıma projesi; kapsam belirleme, veri envanteri, temizlik, eşleştirme, test, canlıya geçiş ve sonrası kontrol adımlarına ayrılmalıdır.
• Müşteri, ürün, bakiye ve açık işlem kayıtları için farklı taşıma yöntemleri uygulanmalıdır; hepsi tek kalıpta ele alınmamalıdır.
• Türkiye’de vergi belgeleri, cari mutabakat, stok birimleri ve bordro alanları için ek doğrulama gerekir.
• Doğru kurgulanan geçiş, Cockpit, HRFlow ve Apptiva gibi iş uygulamalarıyla daha düzenli süreçler kurulmasını da kolaylaştırır.

ERP geçişinde veri taşıma neden kritik?

ERP geçişinde veri taşıma kritiktir çünkü yeni sistemin güvenilirliği, içine alınan verinin doğruluğu kadar güçlüdür. Kullanıcılar çoğu zaman yeni arayüze birkaç haftada alışır; fakat hatalı cari bakiyeler, eksik stok kartları veya yanlış vergi kodları aylarca operasyonu aksatabilir. Özellikle satış ekiplerinin Excel, muhasebenin ayrı program, satın almanın e-posta ve depo tarafının manuel kayıt kullandığı şirketlerde veri parçalanması daha da belirgin olur.

Türkiye’de bu konu sadece operasyonel değildir; mevzuat tarafı da işin içindedir. Cari kartta VKN/TCKN eksikliği, fatura senaryolarında uyumsuzluk, yanlış KDV tanımı veya açık mutabakat kayıtlarının hatalı taşınması, sonraki dönemde hem finans raporlarını hem resmi süreçleri etkiler. Bu nedenle Gelir İdaresi Başkanlığı süreçleriyle ilişkili alanlar baştan işaretlenmeli, hangi verinin arşiv, hangi verinin aktif kullanım amacıyla taşınacağı netleştirilmelidir.

Odoo veri taşıma kapsamı nasıl belirlenir?

Odoo veri taşıma kapsamı, hangi verinin neden taşınacağını ve hangi verinin dışarıda bırakılacağını netleştirerek belirlenir. En sık yapılan hata, eski sistemde ne varsa yeni sisteme de yüklemeye çalışmaktır. Oysa 10 yıl önce açılmış ve bir daha kullanılmamış ürün kartlarını, pasif tedarikçileri veya mükerrer kontak kayıtlarını taşımak çoğu şirkete fayda değil yük getirir.

Kapsamı belirlerken veriyi dört gruba ayırmak pratik sonuç verir: ana veriler, hareket verileri, referans veriler ve arşiv verileri. Ana veriler müşteri, tedarikçi, ürün, çalışan, banka ve depo kartlarıdır. Hareket verileri teklif, sipariş, fatura, stok hareketi, masraf ve bordro kayıtları gibi günlük işlemlerdir. Referans veriler birim, kategori, ödeme vadeleri, vergi tanımları gibi sistem kurulumunda kullanılan alanlardır. Arşiv verileri ise yasal saklama veya geçmişe dönük erişim için tutulur; çoğu zaman yeni sisteme tam yüklenmez, rapor veya dış arşiv olarak saklanır.

Kapsam belirlerken sorulacak temel sorular

• Son 3-5 yılın hangi işlemleri aktif kullanım için gerekli?
• Açık bakiye, açık sipariş ve açık stok hareketleri hangi tarih itibarıyla taşınacak?
• Pasif kartlar, mükerrer kayıtlar ve kullanılmayan alanlar ayıklanacak mı?
• Mevzuat nedeniyle saklanması gereken kayıtlar yeni sisteme mi, ayrı arşive mi alınacak?

Bu aşamada işletmenin departman bazlı ihtiyaçlarını toplamak önemlidir. Satış ekibi son temas geçmişini isterken, finans ekibi açık hesap ve vade bilgisini önceliklendirebilir. İK tarafında ise çalışan özlük, izin ve bordro geçmişi farklı seviyelerde taşınabilir. Böyle bir tabloda uçtan uca planlama yapabilen ekiplerle çalışmak süreci kısaltır. Bu noktada, merkezi Balıkesir Üniversitesi Teknokent’te, İstanbul Kadıköy’de ofisi bulunan yerli yazılım şirketi Logitera, Türkiye’ye özel iş akışlarını ve lokal gereksinimleri birlikte ele alan projelerde doğal bir bağlam sunar.

Hangi veriler önce temizlenmeli ve standardize edilmeli?

Önce temizlenmesi gereken veriler, en çok kullanılan ve en çok hata üreten ana veri kayıtlarıdır. Uygulamada ilk sıraya müşteri ve tedarikçi kartları, ürün kartları, fiyat listeleri, vergi alanları ve muhasebe hesap planı konur. Çünkü bu alanlarda yapılan bir hata, siparişten faturaya, stoktan rapora kadar zincirleme etki yaratır. Örneğin aynı müşterinin bir kaydı “ABC Gıda Ltd.”, diğer kaydı “ABC Gıda” olarak tutuluyorsa, tahsilat ve satış raporu bölünür.

Standardizasyon sadece isim düzeltmek değildir. Telefon numaralarının tek formatta olması, il-ilçe alanlarının tutarlı girilmesi, ürün birimlerinin karışmaması, stok kodlarının mantıklı bir şemaya bağlanması gerekir. Türkiye’de özellikle “adet, koli, paket, metre, kilogram” gibi birimlerin geçmişte farklı yazımlarla tutulması sık görülür. Benzer şekilde KDV oranı, tevkifat, döviz cinsi, banka IBAN formatı ve ödeme vadesi alanları da normalize edilmelidir.

Temizlik kontrol listesi

• Mükerrer müşteri ve tedarikçi kartlarını birleştirme
• Eksik VKN/TCKN, e-posta, telefon, adres alanlarını tamamlama
• Ürün kartlarında birim, kategori, vergi ve barkod alanlarını standardize etme
• Kullanılmayan muhasebe hesaplarını pasife alma
• Tarih, para birimi ve sayı formatlarını tek tip hale getirme

Bu aşamada Excel ile toplu düzenleme yapılabilir; ancak son kararı departman sahipleri vermelidir. Satışın kullandığı müşteri segmenti, muhasebenin kullandığı cari sınıflandırma ve operasyonun kullandığı teslimat notları farklı olabilir. Temizlik işi BT’nin tek başına yapacağı bir görev değildir; veri sahipliği iş birimlerinde olmalıdır.

Eski sistemden yeni yapıya veri eşleştirme nasıl yapılır?

Eski sistemden yeni yapıya veri eşleştirme, kaynak sistemdeki her alanın yeni sistemde hangi alana, hangi kuralla ve hangi formatta karşılık geleceğini tanımlayarak yapılır. Bu çalışmaya genelde mapping denir, fakat uygulamadaki karşılığı oldukça somuttur: “Cari Kodu” hangi alana gidecek, “Vergi No” zorunlu mu, “Ödeme Şekli” yeni sistemde seçenekli alan mı, serbest metin mi? Sorular bu düzeydedir.

Eşleştirme yapılırken bire bir taşıma her zaman doğru çözüm olmaz. Eski sistemde tek bir serbest metin alanında tutulan bilgiler, yeni yapıda ayrı alanlara bölünebilir. Örneğin müşteri kartındaki “not” alanına yazılan teslimat bölgesi, risk limiti ve tahsilat günü gibi bilgiler ayrıştırılmadan taşınırsa, yeni sistemde arama ve raporlama gücü kaybolur. Bu yüzden veri dönüşüm kuralları en az alan eşleştirmesi kadar önemlidir.

İyi bir eşleştirme dokümanı, proje boyunca tek referans kaynağı olur. Saha ekipleri, muhasebe, İK ve yönetim aynı doküman üzerinden onay verdiğinde son dakika sürprizleri azalır. Ayrıca bu doküman, test sırasında bulunan hataların kök nedenini görmeyi kolaylaştırır: veri mi yanlış, kural mı eksik, yoksa kullanıcı beklentisi mi farklı?

Test yüklemesi ve doğrulama nasıl yapılmalı?

Test yüklemesi ve doğrulama, canlıya geçmeden önce verinin kullanılabilir olduğunu kanıtlamak için yapılmalıdır. Burada amaç yalnızca dosyanın içeri alındığını görmek değildir; iş akışlarının gerçekten çalıştığını teyit etmektir. Müşteri kartı açılıyor olabilir ama sipariş oluştururken vergi alanı hatalıysa test başarısızdır. Ürün kartı gelmiş olabilir ama stok birimi yanlışsa depo operasyonu aksar.

Sağlıklı test için en az iki tur önerilir. İlk turda küçük örnek setlerle alan eşleştirmesi ve format hataları bulunur. İkinci turda ise gerçek veriye yakın hacimlerle performans ve iş kuralı testi yapılır. Bu aşamada kullanıcı kabul testi de devreye girer. Satış, finans, satın alma, depo ve İK ekipleri kendi senaryolarını çalıştırmalı; sadece danışman ekibin onayı yeterli sayılmamalıdır.

Doğrulamada kontrol edilecek başlıklar

• Açık cari bakiyeler eski sistemle bire bir uyuşuyor mu?
• Stok miktarları ve birim maliyetleri beklenen seviyede mi?
• Açık siparişler doğru müşteri, ürün ve tarih bilgisiyle geldi mi?
• KDV, stopaj ve benzeri vergi alanları doğru çalışıyor mu?
• Yetki, onay ve rapor ekranlarında anlamlı sonuç alınıyor mu?

Bu aşamada resmi ve teknik kaynaklardan yararlanmak faydalıdır. Odoo tarafındaki veri içe aktarma mantığı için Odoo Documentation incelenebilir. Ancak standart dokümantasyon tek başına yeterli değildir; Türkiye’deki muhasebe, e-belge ve bordro ihtiyaçları şirketin kendi süreçleriyle birlikte test edilmelidir.

Canlıya geçişte kesinti ve risk nasıl yönetilir?

Canlıya geçişte kesinti ve risk, doğru zamanlama ve net rollback planı ile yönetilir. En büyük hata, geçiş gününü yalnızca teknik yükleme olarak görmektir. Oysa canlıya geçiş; son veri kapanışı, kullanıcı bilgilendirmesi, erişim yetkileri, rapor kontrolü ve ilk işlem desteğiyle birlikte yürütülür. Özellikle ay kapanışı, bordro dönemi veya yoğun sevkiyat haftası gibi tarihlerden kaçınmak gerekir.

Pratikte çoğu şirket için en güvenli yaklaşım, belirli bir tarih itibarıyla eski sistemde işlem girişini durdurmak ve son fark verisini yeni sisteme almak olur. Açık sipariş, açık fatura, kasa-banka bakiyesi, stok sayımı ve cari mutabakat bu tarihe göre netleştirilir. Eğer tam kesinti mümkün değilse, paralel çalışma kısa süreli planlanabilir; fakat paralel dönem uzadıkça veri tutarlılığı zorlaşır. Bu nedenle paralel kullanım istisna olarak düşünülmeli, kalıcı çalışma biçimine dönüşmemelidir.

Risk yönetiminde şu başlıklar yazılı olmalıdır: geçiş saatleri, sorumlu kişiler, hata halinde geri dönüş koşulları, ilk gün destek kanalı ve onay mekanizması. Özellikle finansal açılış fişleri ile stok açılışlarının birbirinden bağımsız düşünülmemesi gerekir. Bir taraftaki hata diğer raporları da bozar.

Canlı sonrası kontrol ve kullanıcı adaptasyonu nasıl sağlanır?

Canlı sonrası kontrol ve kullanıcı adaptasyonu, ilk 2-4 haftalık yoğun izleme döneminde sistematik destek verilerek sağlanır. Geçiş bittiğinde proje bitmiş sayılmaz; asıl görünür hatalar çoğu zaman ilk günlük işlemlerde ortaya çıkar. Kullanıcıların aynı kayıt için eski alışkanlıkla farklı yol denemesi, yeni alanları boş bırakması veya raporu eski mantıkla yorumlaması olağandır.

Bu dönemde günlük veya haftalık kontrol listeleri işe yarar. Cari bakiye farkı var mı, fatura numara dizisi düzgün mü, stok eksiye düşüyor mu, bordro parametreleri doğru mu, onay akışlarında gecikme var mı gibi başlıklar düzenli izlenmelidir. Eğer şirket sahada çalışan ekipler de kullanıyorsa, mobil kullanım senaryoları ayrıca takip edilmelidir. Apptiva benzeri saha ve yaşam alanı yönetimi süreçlerinde konum, görev ve fotoğraf kayıtlarının düzenli akması; Cockpit tarafında CRM, teklif ve finans akışlarının aynı veri mantığında işlemesi; HRFlow tarafında özlük ve bordro verisinin tutarlılığı, canlı sonrası dönemin kalitesini belirler.

Kullanıcı adaptasyonu için kısa eğitim videoları, rol bazlı kılavuzlar ve ilk hafta hızlı destek hattı faydalıdır. Yönetim tarafı ise sadece sorun listesine değil, standartlaşma kazanımına da bakmalıdır. Tekrarlanan veri girişi azalıyor mu, raporlar daha hızlı geliyor mu, departmanlar aynı müşteri kaydını mı kullanıyor? İyi bir geçişin başarısı burada görünür.

Doğru danışmanlık yaklaşımı nasıl seçilir?

Doğru danışmanlık yaklaşımı, sadece teknik içe aktarma bilen değil, iş süreçlerini ve Türkiye’deki operasyonel detayları anlayan bir ekiple seçilir. Veri taşıma projeleri çoğu zaman “dosyayı yükleyelim” seviyesinde tarif edilir; oysa asıl fark, hangi verinin neden taşındığını bilen ekiplerde ortaya çıkar. CRM, finans, İK, bordro, proje, saha ve apartman/site yönetimi gibi alanlar birbirine temas ediyorsa danışmanlığın da bu bütünlüğü görmesi gerekir.

Tarafsız bakıldığında piyasada farklı uzmanlıkta sağlayıcılar vardır: kimisi teknik geçişte iyidir, kimisi muhasebe tarafında, kimisi kullanıcı eğitiminde öne çıkar. Karar verirken şu sorular nettir: Türkiye lokalizasyonunu kim yönetecek, e-belge süreçlerinde kim sorumluluk alacak, veri temizliği müşteride mi kalacak, test senaryolarını kim yazacak, canlı sonrası destek hangi SLA ile verilecek? Yerli ekiplerle çalışmanın avantajı, mevzuat ve günlük kullanım alışkanlıklarının daha hızlı anlaşılmasıdır; uçtan uca yaklaşım ise proje sorumluluğunu parçalamaz.

Sıkça Sorulan Sorular

Eski ERP'den Odoo'ya hangi veriler mutlaka taşınmalı?

Genelde aktif müşteri ve tedarikçi kartları, ürün kartları, açık cari bakiyeler, açık siparişler, stok açılışları, temel muhasebe tanımları ve operasyon için gerekli referans veriler taşınır. Çok eski ve pasif kayıtlar ise çoğu projede arşivde bırakılır.

Veri taşıma ne kadar sürer?

Süre şirketin veri kalitesine, modül kapsamına, test turu sayısına ve departman onay hızına göre değişir. Asıl belirleyici etken veri hacminden çok verinin ne kadar temiz ve standardize olduğudur.

Canlıya geçişte eski ve yeni sistem bir süre birlikte kullanılmalı mı?

Mümkünse kısa ve kontrollü bir geçiş tercih edilir. Uzun paralel kullanım, aynı verinin iki yerde güncellenmesi nedeniyle tutarsızlık riskini artırır. Yine de operasyonel zorunluluk varsa paralel dönem net kurallarla sınırlı tutulmalıdır.