Veri temizleme, ERP geçişinizin başarılı olup olmayacağını veya çöpleri bir sistemden diğerine taşımak için pahalı bir egzersiz haline gelip gelmeyeceğini belirleyen gösterişsiz temeldir. Her geçiş danışmanı size toplam proje çabasının %30-40'ının veri temizlemeye ayrılması gerektiğini söyleyecektir, ancak çoğu kuruluş bu konuda acele eder çünkü verileri temizlemek ana hedeften bir sapma gibi gelir. Sonuç tahmin edilebilir: Satış ekiplerinin kafasının karışmasına neden olan yinelenen müşteri kayıtları, mali raporları bozan yetim işlemler ve envanter yönetimini raydan çıkaran tutarsız ürün verileri. Bu kılavuz, kaynak veya hedef sisteminiz ne olursa olsun, herhangi bir ERP geçişi öncesinde verilerinizi temizlemeniz için sistematik bir çerçeve sağlar.
Önemli Çıkarımlar
- Veri temizleme, toplam geçiş zaman çizelgesinin %30-40'ını tüketmelidir; bunu proje zamanlamanızda açıkça planlayın
- İşlemsel verilerden önce ana verilerle (müşteriler, ürünler, satıcılar) başlayın - ana veri hataları art arda
- Tam eşleşmeyi, bulanık eşleşmeyi ve iş kuralı eşleşmesini birleştiren kopya tespit algoritmaları kopyaların %95'ini yakalar
- Yetim kayıtlar (silinen ana verilere referans veren işlemler), içe aktarma hatalarının en yaygın nedenidir
- Veri kalitesi puanlaması, temizleme ilerlemesini izlemek ve "tamamlandı" kriterlerini tanımlamak için objektif ölçümler sağlar
- Silmek yerine arşivleyin — vergi, uyumluluk veya trend analizi için geçmiş verilere ihtiyacınız olabilir
- Veri sahiplerini varlık türüne göre atayın — sahiplik olmadan temizleme, parmakla işaretlemeye dönüşür
Temiz Veri Neden Düşündüğünüzden Daha Önemli?
Yeni bir ERP'de kirli verilerin maliyeti teorik değildir. İşte somut sonuçlar:
Finansal hatalar. Mükerrer müşteri kayıtları, mükerrer faturalar, bölünmüş ödeme uygulamaları ve hatalı yaşlandırma raporları anlamına gelir. Bir müşterinin aslında iki kayıtta 25.000 $ borcu olmasına rağmen 50.000 $ borcu var gibi görünüyor. Tahsilat ekibiniz hayalet dengelerin peşinde zaman harcıyor.
Envanter yanlışlığı. Biraz farklı adlara sahip yinelenen ürün kayıtları, stoğun kayıtlar arasında bölündüğü anlamına gelir. Aynı üründen 25 adet varken sisteminizde 10 adet "Widget Blue, Large" ve 15 adet "Blue Widget - LG" görünüyor. Yeniden sıralama noktaları hatalı şekilde tetikleniyor.
Bozuk otomasyon. ERP otomasyon kuralları belirli kayıtlara referans verir. Vadesi geçmiş faturaları olan müşterilere ödeme hatırlatıcısı gönderen bir iş akışı, mükerrer kayıtları olan müşterilere iki hatırlatıcı gönderecektir. Her yinelenen ürün için otomatik yeniden sıralama kuralları tetiklenecektir.
Bozulmayı bildirin. Satış raporları şişirilmiş müşteri sayılarını gösterir. Ürün raporları parçalanmış envanteri gösteriyor. Mali raporlar, mükerrer kayıtlarla ilişkili gelirleri veya giderleri iki kez sayar.
Kullanıcı hayal kırıklığı. ERP'nin benimsenmesini ortadan kaldırmanın en hızlı yolu, kullanıcıların yeni sistemdeki kirli verileri görmesidir. Bir satış elemanı bir müşteriyi arar ve neredeyse aynı olan üç kayıt bulursa, sisteme ve geçiş projesine olan güvenleri anında buharlaşır.
Adım 1: Yinelenen Kopyaların Tespiti
Tekrarlı Tespitin Üç Seviyesi
Düzey 1: Tam eşleşme. Anahtar alanlarda aynı olan kayıtlar. Tespit edilmesi kolaydır ancak yalnızca en belirgin kopyaları yakalar.
- Aynı e-posta adresi
- Aynı telefon numarası (biçimi normalleştirdikten sonra)
- Aynı vergi numarası / şirket kayıt numarası
- Aynı SKU / ürün kodu
Seviye 2: Bulanık eşleşme. Benzer ancak aynı olmayan kayıtlar. Levenshtein mesafesi, Soundex veya Jaro-Winkler benzerliği gibi algoritmalar gerektirir.
- "ECOSIRE Pvt Ltd" ve "ECOSIRE Private Limited" ve "Ecosire Pvt. Ltd."
- "123 Ana Cadde" ve "123 Ana Cadde" ve "123 Main St, Suite 100"
- "Mavi Widget (Büyük)" ve "Widget - Mavi, L" ve "BLU-WDGT-LG"
Seviye 3: İş kuralı eşleşmesi. İş bağlamına göre farklı görünen ancak aynı varlığı temsil eden kayıtlar.
- Aynı şirket adı + aynı şehir (farklı adreslere sahip olsa bile muhtemelen aynı müşteri)
- Aynı ürün boyutları + aynı malzeme (muhtemelen farklı adlarla aynı ürün)
- Aynı satıcı + aynı banka hesabı (muhtemelen mükerrer satıcı kaydı)
Yinelenen Tespit Süreci
| Adım | Eylem | Araç/Yöntem |
|---|---|---|
| 1 | Varlıktaki tüm kayıtları dışarı aktar | CSV veya API dışa aktarımı |
| 2 | Metin alanlarını normalleştirin (küçük harf, noktalama işaretlerini kaldırın, boşlukları kırpın) | Komut Dosyası veya ETL aracı |
| 3 | Benzersiz tanımlayıcılarda (e-posta, vergi numarası, SKU) tam eşleşme çalıştırın | SQL GRUP TARAFINDAN + SAYIM > 1 |
| 4 | İsim + adres kombinasyonlarında bulanık eşleşme çalıştırın | Python (fuzzywuzzy kütüphanesi) veya özel yinelenenleri kaldırma aracı |
| 5 | Bağlama dayalı eşleştirme için iş kurallarını uygulayın | Varlık türüne göre özel kurallar |
| 6 | Güven puanlarıyla yinelenen gruplar oluşturun | İnsan kararı için inceleme kuyruğu |
| 7 | Kopyaları birleştirin veya arşivleyin (asla doğrudan silmeyin) | Birleştirme aracı veya manuel birleştirme |
Varlık Türüne Göre Birleştirme Kuralları
Müşteri birleştirme kuralları:
- En son işlem etkinliğinin kaydını tutun
- Tüm adresleri birleştirin (birincil olarak işaretleyin, diğerlerini gönderim/fatura alternatifi olarak tutun)
- Hayatta kalan kayıt altındaki tüm irtibat kişilerini birleştirin
- Tüm siparişleri, faturaları ve ödemeleri hayatta kalan kayda yeniden atayın
- En eski oluşturma tarihini koruyun (müşteri kullanım süresi hesaplamaları için)
Ürün birleştirme kuralları:
- Kataloğunuzla eşleşen aktif SKU ile kaydı tutun
- Stok miktarlarını yinelenen kayıtlar arasında birleştirin
- Tüm sipariş satırlarını ve fatura satırlarını hayatta kalan kayda yeniden atayın
- Yinelenen SKU'yu, hayatta kalan kayda işaret eden bir notla arşivleyin
Satıcı birleştirme kuralları:
- Mevcut banka bilgileri ve ödeme koşullarının kaydını tutun
- Tüm satın alma siparişlerini ve faturalarını hayatta kalan kayıt altında birleştirin
- Satıcı iletişimlerini birleştirin
- Hayatta kalan kayıtta vergi bilgilerinin güncel olduğunu doğrulayın
Adım 2: Yetim Kaydının Belirlenmesi
Yetim kayıtlar, artık mevcut olmayan veya yanlış bağlanmış ana verilere referans veren işlemlerdir. Bunlar, kopyalardan sonra içe aktarma hatalarının en yaygın ikinci nedenidir.
Yaygın Yetim Kalıpları
| Yetim Türü | Örnek | Etki |
|---|---|---|
| Müşterisiz sipariş | Satış siparişi silinmiş bir müşteri kimliğine başvuruyor | İçe aktarma başarısız oluyor veya anonim sipariş oluşturuyor |
| Ürünsüz fatura satırı | Fatura satırı, mevcut olmayan bir ürün SKU'suna başvuruyor | İçe aktarma başarısız oluyor veya boş satır öğesi oluşturuyor |
| Faturasız ödeme | Ödeme kaydı, silinmiş bir fatura numarasına atıfta bulunuyor | Ödeme uygulanamıyor, AR/AP'yi bozuyor |
| Departmanı olmayan çalışan | Çalışan, kaldırılan bir departman koduna atıfta bulunuyor | Yeni sistemde çalışan kaydı eksik |
| Ürün olmadan BOM | Malzeme listesi üretimi durdurulan bir ürüne gönderme yapıyor | Üretim verileri eksik |
| Projesiz Zaman Çizelgesi | Zaman çizelgesi girdisi kapatılmış ve silinmiş bir projeye referans veriyor | Zaman verileri kayıp veya ilişkilendirilemez |
Yetim Tespiti Sorgu Modeli
Her işlem varlığı için, ana ana verilerine karşı bir çapraz referans kontrolü çalıştırın:
For every sales order line:
→ Does the customer_id exist in the customers table?
→ Does the product_id exist in the products table?
→ Does the salesperson_id exist in the employees table?
For every invoice:
→ Does the customer_id exist in the customers table?
→ Does each line's product_id exist in the products table?
→ Does the payment_term reference exist in the payment terms table?
For every purchase order:
→ Does the vendor_id exist in the vendors table?
→ Does each line's product_id exist in the products table?
Yetim Çözüm Stratejileri
Strateji 1: Yeniden bağlanma. Ana kayıt silindiyse ancak mevcut olması gerekiyorsa, onu yeniden oluşturun ve yetim işlemleri bağlayın. Bu, üretimden kaldırılmış ancak geçmiş siparişleri olan ürünler için yaygındır.
Strateji 2: Yeniden sınıflandırma. Yetim işlemleri, tümünü kapsayan bir ana kayda atayın. Bir "Eski Müşteri" iletişim kişisi veya "Arşivlenmiş Ürün" kaydı oluşturun ve yetimleri buraya yeniden atayın. Bu, veri kalitesi sorununu kabul ederken finansal toplamları korur.
Strateji 3: Arşivle. Yetim işlemleri taşıma kapsamı dışındaki bir arşiv tablosuna taşıyın. Bunları referans olarak ayrı bir geçmiş veri aktarımına ekleyin ancak yeni ERP'ye aktarmayın.
Adım 3: Veri Doğrulama Kuralları
Alan Düzeyinde Doğrulama
Dışa aktarmadan önce bu doğrulama kurallarını her kayda uygulayın:
Metin alanları:
- Başta veya sonda boşluk yok
- Metin içinde çift boşluk yoktur
- Tutarlı büyük harf kullanımı (Adlar için Başlık Harfi, kodlar için BÜYÜK HARF)
- Alfasayısal olması gereken alanlarda (SKU'lar, kodlar) özel karakter yok
- Karakter kodlaması tutarlıdır (baştan sona UTF-8)
E-posta alanları:
- Tam olarak bir @ sembolü içerir
- Etki alanında @'dan sonra en az bir nokta bulunur
- E-posta adresinde boşluk yok
- Küçük harf (e-posta adresleri büyük/küçük harfe duyarlı değildir)
- Yer tutucu değil ([email protected], [email protected])
Telefon alanları:
- Tutarlı format (birini seçin: +1-555-123-4567 veya +15551234567)
- Uluslararası numaralar için ülke kodu dahildir
- +, -, (, ) dışında harf veya özel karakter kullanılamaz
- Ülke için geçerli uzunluk
Tarih alanları:
- Tutarlı format (ISO 8601: YYYY-AA-GG)
- Mantıksal olarak imkansız olan gelecek tarihler yok (ör. 2030'daki fatura tarihi)
- Makul olmayan eski tarihler yok (örneğin, sipariş tarihi 1900-01-01, birçok sistem için varsayılan)
- Tarih aralıkları mantıksaldır (başlangıç tarihi bitiş tarihinden öncedir)
Sayısal alanlar:
- Sayısal alanlarda metin yok (binlik ayırıcılar içe aktarma hatalarına neden olduğundan virgüller)
- Tutarlı ondalık hassasiyet (para birimi için 2 basamak, küçük değerli birim fiyatlar için 4 basamak)
- Mantıksal olarak imkansız olan durumlarda negatif değer yoktur (miktarlar, fiyatlar)
- Para birimi değerleri beklenen aralıkta (Boeing değilseniz 999.999.999 dolarlık fatura yok)
Gerekli alanlar:
- Müşteri adı hiçbir zaman boş bırakılmaz
- Ürün adı ve SKU hiçbir zaman boş bırakılmaz
- Fatura numarası hiçbir zaman boş bırakılmaz ve asla kopyalanmaz
- Tüm yabancı anahtar referansları mevcut kayıtlara işaret eder
Çapraz Kayıt Doğrulaması
Bireysel saha kontrollerinin ötesinde, ilgili kayıtlar arasındaki tutarlılığı doğrulayın:
- Fatura satırı tutarlarının toplamı fatura toplamına eşittir
- Faturaya uygulanan ödemelerin toplamı fatura toplamını geçmiyor
- Eldeki stok negatif miktarları göstermiyor (sistem izin vermediği sürece)
- Çalışanın başlangıç tarihi, ilgili zaman çizelgesi girişlerinden öncedir
- Ürün oluşturma tarihi, ilgili satış siparişi satırlarından öncedir
Adım 4: Arşivleme Stratejisi
Tüm verilerin taşınması gerekmez. Uyumluluk gerekliliklerini, iş ihtiyaçlarını ve geçiş karmaşıklığını dengeleyen bir arşivleme politikası tanımlayın.
Karar Çerçevesinin Arşivlenmesi
| Veri Türü | Yeni ERP'ye Geçiş | ERP Dışında Arşiv | Sil |
|---|---|---|---|
| Aktif müşteriler (son 24 aydaki işlemler) | Evet | — | — |
| Aktif olmayan müşteriler (24+ ay boyunca işlem yapılmadı) | Hayır (uyumluluk gerektirmedikçe) | Evet — CSV + güvenli depolama | — |
| Siparişleri ve faturaları açın | Evet | — | — |
| Kapalı siparişler (son 24 ay) | Evet | — | — |
| Kapalı siparişler (24+ ay) | Hayır | Evet | — |
| Mevcut envanter seviyeleri | Evet | — | — |
| Geçmiş stok hareketleri (24+ ay) | Hayır | Evet | — |
| Aktif ürünler | Evet | — | — |
| Üretimi durdurulan ürünler (sipariş geçmişiyle birlikte) | Evet (arşivlenmiş/etkin değil) | — | — |
| Üretimi durdurulan ürünler (sipariş geçmişi yok) | Hayır | Hayır | Evet |
| Çalışan kayıtları (aktif) | Evet | — | — |
| Çalışan kayıtları (7+ yıl önce sonlandırıldı) | Hayır | Evet (yasal saklama) | — |
| Test/numune/kukla veriler | Hayır | Hayır | Evet |
| Sistem denetim günlükleri | Hayır | Evet (uyumluluk) | — |
Arşiv Formatı Önerileri
ERP dışında arşivlediğiniz veriler için:
- **Anlaşılır sütun başlıkları ve UTF-8 kodlamasıyla CSV'ye aktarın
- Her sütunu, veri türünü ve geçerli değerleri tanımlayan bir veri sözlüğü ekleyin
- Sürümlendirilmiş, değiştirilemez bir konumda saklayın (Sürüm oluşturma veya şifreli yedekleme ile S3)
- Bir saklama planı belirleyin (çoğu yargı bölgesinde finansal veriler için 7 yıl, bazı sektörlerde daha uzun)
- Arşivi, içerik, tarih aralığı ve saklama politikası da dahil olmak üzere uyumluluk kayıtlarınıza belgeleyin
Adım 5: Ana Veri Yönetişimi
Veri temizleme tek seferlik bir olay değildir. Yönetişim olmadan, yeni parlak ERP'niz 12-18 ay içinde aynı veri kalitesi sorunlarını biriktirecektir.
Veri Sahipliği Matrisi
| Veri Varlığı | Veri Sahibi (Rol) | Sorumluluklar |
|---|---|---|
| Müşteriler | Satış Müdürü | Yeni müşteri oluşturmayı, üç ayda bir tekrarlanan incelemeyi, birleştirme isteklerini onaylama |
| Ürünler | Ürün Müdürü | SKU standartları, yeni ürün onayı, sonlandırma süreci |
| Satıcılar | Satınalma Müdürü | Satıcı katılım standartları, yıllık satıcı incelemesi, mükerrer önleme |
| Hesap Planı | Finans Kontrolörü | Hesap oluşturma onayı, dönem sonu incelemesi, yapı değişiklikleri |
| Çalışanlar | İK Müdürü | Çalışan verilerinin doğruluğu, yaşam döngüsü yönetimi (işe alımdan işten çıkarılmaya kadar) |
| Fiyatlandırma | Ticari Direktör | Fiyat listesi bakımı, indirim yetki matrisi |
Veri Giriş Standartları
Her kuruluş için standartları belgeleyin ve uygulayın:
Müşteri yaratma standartları:
- Şirket adı: Resmi yasal ad (kayıt belgelerine göre doğrulayın)
- Ticari isim: Yasal addan farklıysa ayrı olarak saklanır
- Adres: Ülkeye ait posta hizmeti biçimini kullanın
- Birincil iletişim kişisi: İsim + e-posta + telefon gerekli
- Ödeme koşulları: Varsayılan, oluşturma sırasında belirlenir, değişiklik için onay gerekir
- Kredi limiti: Satışlara göre değil finansa göre belirlenir
Ürün oluşturma standartları:
- Ürün adı: [Marka] [Ürün] [Çeşit] [Boyut] (ör. "ECOSIRE Widget Blue Large")
- SKU: [Kategori]-[Sıra]-[Varyant] (ör. "WDG-001-BL")
- Açıklama: Minimum 50 karakter, açıklamalarda HTML formatı yok
- Kategori: Mevcut kategoriler arasından seçim yapılmalıdır (serbest metin kategorisi yoktur)
- Ölçü birimi: Onaylanan listedeki standart ölçü birimi kullanılmalıdır
- Resimler: Minimum bir resim, maksimum boyutlar 2048x2048, beyaz arka plan
Otomatik Veri Kalitesi Kuralları
Kirli verileri en baştan önlemek için yeni ERP'nizde bu kuralları yapılandırın:
- Yinelenmeyi önleme: Aynı e-posta, telefon veya vergi numarasına sahip bir kayıt zaten mevcutsa kayıt sırasında uyarı verir
- Gerekli alan uygulaması: Zorunlu alanlar boşsa oluşturmayı engelle
- Biçim doğrulama: Geçersiz e-posta biçimlerini, telefon biçimlerini ve tarih biçimlerini reddet
- Onay iş akışları: Yeni müşteri ve satıcı oluşturma, yönetici onayı gerektirir
- Periyodik inceleme: 12+ ay boyunca güncellenmeyen kayıtları vurgulayan otomatik raporlar
Adım 6: Veri Kalitesi Puanlaması
Puanlama Metodolojisi
Her veri varlığını, her biri 1-5 arasında derecelendirilen dört boyuta göre puanlayın:
| Boyut | Puan 1 | Puan 3 | Puan 5 |
|---|---|---|---|
| Bütünlük | >Gerekli alanların %30'u boş | %10–30 boş | <%5 boş |
| Tutarlılık | Standart yok, çılgınca değişen formatlar | Bazı standartlar, kısmi uyumluluk | Net standartlar, >%95 uyumluluk |
| Doğruluk | >%20 örnek kayıtlarda hata var | %5–20 hatalar | <%2 hata (doğrulanmış örnek) |
| Benzersizlik | >%10 tekrarlama oranı | %3–10 kopya | <%1 kopya |
Puanlama Süreci
- Örnek: Kayıtların rastgele %5'i (minimum 100, maksimum 500)
- Etkinliği kontrol edin: Boş zorunlu alanları yüzde olarak sayın
- Tutarlılığı kontrol edin: Metin, tarih, telefon ve e-posta alanlarının format uyumluluğunu inceleyin
- Doğruluğunu kontrol edin: Örneklenen kayıtları harici kaynaklara (web sitesi, kayıt veritabanları, fiziksel envanter sayımı) göre doğrulayın
- Benzersizliği kontrol edin: Tüm veri kümesinde kopya tespitini çalıştırın, oranı hesaplayın
Taşıma için Minimum Kalite Eşikleri
| Varlık | Minimum Ortalama Puan | Önerilen |
|---|---|---|
| Müşteriler | 3.5 | 4.0+ |
| Ürünler | 3.5 | 4.0+ |
| Satıcılar | 3.0 | 3,5+ |
| Hesap Planı | 4.0 | 4,5+ |
| Açık Siparişler | 3.5 | 4.0+ |
| Faturaları Aç | 4.0 | 4,5+ |
| Çalışanlar | 3.5 | 4.0+ |
Minimum eşiğin altında puan alan kuruluşlar için taşıma işlemine devam etmeyin. Verileri içe aktarmadan sonra temizlemenin maliyeti, içe aktarmadan önce temizlemeye göre 3-5 kat daha yüksektir.
Veri Temizleme Zaman Çizelgesi Şablonu
| Hafta | Etkinlik | Teslimat |
|---|---|---|
| 1 | İlk kalite değerlendirmesi ve puanlama | Varlık başına kalite puanı raporu |
| 2 | Yinelenen algılama çalıştırması + birleştirme planlaması | Önerilen birleştirme eylemleriyle yinelenen gruplar |
| 3 | Yetim kayıt tespiti | Çözüm önerileri içeren yetim raporu |
| 4 | Veri sahibi ataması ve standartlar dokümantasyonu | Veri yönetimi belgesi |
| 5–6 | Toplu temizleme: kopyalar, yetimler, format standardizasyonu | Temizlenmiş ana veri aktarımları |
| 7 | Doğrulama kuralının yürütülmesi ve istisna yönetimi | Doğrulama istisnaları raporu |
| 8 | Yeniden puanlama ve sertifikasyon | Nihai kalite puanları (hepsi eşik değerlerin üzerinde) |
| 9 | Eski verileri arşivleme, belge saklama politikaları | Arşiv dosyaları + saklama planı |
| 10 | Geçiş ithalatı için son ihracat | Temiz, doğrulanmış, geçişe hazır veri dosyaları |
Araçlar ve Kaynaklar
Açık Kaynaklı Veri Temizleme Araçları
- OpenRefine: Dağınık verileri kümelemek, şekillendirmek ve dönüştürmek için güçlü veri temizleme aracı
- dedupe.io: Python için makine öğrenimi tabanlı veri tekilleştirme kitaplığı
- Büyük Beklentiler: Otomatik kalite kontrolleri için veri doğrulama çerçevesi
- pandalar (Python): Özel temizleme komut dosyaları için esnek veri işleme
- csvkit: CSV incelemesi ve doğrulaması için komut satırı araçları
Ticari Veri Kalitesi Platformları
- Informatica Veri Kalitesi: Kurumsal düzeyde temizleme ve eşleştirme
- Talend Veri Kalitesi: Profil oluşturma, temizleme ve standardizasyon
- Melissa Data: Adres doğrulama, e-posta doğrulama, kopya tespiti
- IBM InfoSphere QualityStage: Ana veri eşleştirme ve standardizasyon
Sıkça Sorulan Sorular
Veri temizleme işlemi ne kadar sürer?
Orta ölçekli bir işletme için (5.000–50.000 müşteri kaydı, 1.000–10.000 ürün), 6–10 haftalık özel çabayı planlayın. Bu, bir tam zamanlı veri analistinin yanı sıra her departmandaki veri sahiplerinin yarı zamanlı katılımını varsayar. Yüzbinlerce kayda veya karmaşık çoklu sistem ortamına sahip daha büyük kuruluşların 12-16 haftaya ihtiyacı olabilir.
Eski sistemdeki verileri mi yoksa hazırlama dosyalarındaki verileri mi temizlememiz gerekiyor?
Canlı sistemde değil, hazırlama dosyalarını (dışa aktarılan CSV'ler veya hazırlama veritabanı) temizleyin. Bu, üretim verilerinizi bir yedek olarak korur, birden fazla kişi tarafından paralel temizleme yapılmasına olanak tanır ve günlük operasyonların kesintiye uğramasını önler. Temiz veriler yeni ERP'ye aktarılana kadar canlı sisteminiz dokunulmadan çalışmaya devam eder.
Minimum kalite eşiğine ulaşamazsak ne olur?
Belirli bir varlık minimum puana ulaşamıyorsa temel nedeni araştırın. Veri hacmiyle ilgili bir sorun varsa (manuel olarak temizlenemeyecek kadar çok kayıt varsa), yalnızca en güncel veya en aktif alt kümeyi içe aktarmayı ve geri kalanını arşivlemeyi düşünün. Bu yapısal bir sorunsa (veriler hiçbir zaman yeni ERP'nin ihtiyaçlarını destekleyecek şekilde tasarlanmamıştır), verileri dış kaynaklardan zenginleştirmeniz veya bazı kayıtların geçiş sonrasında manuel olarak ilgilenilmesini gerektireceğini kabul etmeniz gerekebilir.
Veri temizliğinden kim sorumlu olmalıdır?
Veri temizleme bir BT sorumluluğu değil, bir iş sorumluluğudur. BT, araçları ve altyapıyı sağlar, ancak hangi kopya kaydın tutulacağı, yetim bir siparişin yeniden bağlanması mı yoksa arşivlenmesi mi gerektiği ve doğru ürün adı formatının ne olması gerektiği gibi kararları iş kullanıcılarının vermesi gerekir. Her departmandan veri sahiplerini atayın ve onları varlık kalite puanlarından sorumlu tutun.
Veri temizlemeyi otomatikleştirebilir miyiz?
Kısmen. Otomatik araçlar, format standardizasyonunu (telefon numaraları, adresler, tarihler), tam eşleşme tekilleştirmeyi ve doğrulama kuralı kontrolünü yönetir. Ancak bulanık eşleşme kopyalarını birleştirmek, yetim kayıtları çözümlemek ve veri doğruluğunu doğrulamak insan muhakemesini gerektirir. %60 otomatik / %40 manuel çaba için plan yapın.
Taşıma sonrasında veri kalitesi sorunları keşfedersek ne olur?
Geçiş sonrası temizleme, geçiş öncesi temizlemeye göre 3-5 kat daha pahalıdır çünkü artık değişikliklerin etkin iş akışlarını etkilediği canlı bir sistemle uğraşıyorsunuz. Canlı kullanıma geçtikten sonra sorunlar keşfederseniz, iş etkisine göre önceliklendirin: önce finansal doğruluğu etkileyen kayıtları, ardından müşteriye yönelik kayıtları ve ardından dahili operasyonel kayıtları düzeltin.
ECOSIRE veri temizlemeye yardımcı olur mu?
Evet. Veri temizleme, ECOSIRE'ın geçiş hizmetlerinin temel bir bileşenidir. Her geçiş projesinin bir parçası olarak veri profili oluşturma, otomatik veri tekilleştirme, kalite puanlama ve temizleme komut dosyası oluşturma sağlıyoruz. Ekibimiz, iş bağlamının her temizleme kararını yönlendirmesini sağlamak için veri sahiplerinizle birlikte çalışır. Veri kalitesiyle ilgili karşılaştığınız zorlukları tartışmak için bize ulaşın.
Veri Kalitesi Değerlendirmesiyle Başlayın
Herhangi bir geçişin ilk adımı verilerinizin mevcut durumunu anlamaktır. Veri kalitesi değerlendirmesi 3-5 gün sürer ve her büyük kuruluş için tekrar oranlarını, tamlık puanlarını, format tutarsızlıklarını ve yetim kayıt sayılarını gösteren ayrıntılı bir rapor üretir.
ECOSIRE, geçiş planlama hizmetlerimizin bir parçası olarak ücretsiz veri kalitesi değerlendirmeleri sunar. Mevcut verilerinizi analiz edeceğiz, en yüksek etkili temizleme görevlerini belirleyeceğiz ve geçişe hazır kaliteye ulaşmak için gerçekçi bir zaman çizelgesi ve çaba tahmini sunacağız.
Ücretsiz veri kalitesi değerlendirmenizi isteyin ve temiz, başarılı bir geçişe yönelik ilk adımı atın.
Yazan
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
Odoo ERP ile İşinizi Dönüştürün
Operasyonlarınızı kolaylaştırmak için uzman Odoo uygulaması, özelleştirme ve destek.
İlgili Makaleler
Axelor ve Odoo (2026): İki Açık Kaynak ERP'nin Dürüst Karşılaştırması
2026'da Axelor ve Odoo: Axelor'un düşük kodlu, BPM odaklı ERP'si Odoo'nun uygulama ekosistemiyle nasıl kıyaslanır — gerçek güçlü yönler, lisanslama, fiyatlandırma ve hangisinin ne zaman kazandığı.
Bulut ERP Toplam Sahip Olma Maliyeti: Gerçek 5 Yıllık Rakamlar
Bulut ERP için şeffaf bir 5 yıllık TCO modeli: abonelik, uygulama, özelleştirme, veri taşıma, eğitim, barındırma, yükseltmeler ve şirket içi yönetim süresi; 25 kullanıcılı bir KOBİ için Odoo, NetSuite sınıfı ve ERPNext karşılaştırmasıyla.
Proje odaklı KOBİ'ler için monday.com ve Odoo (2026)
Proje odaklı KOBİ'ler için monday.com ve Odoo: monday.com pano deneyimi ve ekip koordinasyonunda öne çıkar; Odoo, projeleri tekliflere, zaman çizelgelerine ve faturalamaya bağladığında kazanır.