Veri temizliği geçmişi düzeltir; ortak kayıt kuralları aynı karışıklığın yeniden oluşmasını önler.
Yazan: Mehmet Durak | ESPADE ERP-AI Dönüşüm Merkezi Kurucusu
Depoda tek bir malzeme olduğunu düşünün. Satın alma ekibi bir kodla, üretim başka bir adla takip ediyor. Stok hareketleri bir kayıtta, tüketim bilgisi diğerinde birikiyor. Bir rapor malzemenin yeterli olduğunu söylerken diğeri yeni sipariş ihtiyacı gösteriyor. Hangi rapora güvenecek, önce neyi düzelteceksiniz?
İlk tepki iki kaydı birleştirmek olabilir. Ama isim benzerliği yeterli değil. Biri eski teknik özelliği, diğeri yeni özelliği temsil ediyorsa bu ayrım korunmalı. Bu örnek senaryoda standardın amacı her şeyi aynılaştırmak değil; aynı olanı aynı, farklı olanı farklı kurallarla tanımlamaktır.
Tek kod yetmez; ortak anlam gerekir
Ürün kartınin tek olması işi kolaylaştırabilir. Fakat satın alma paket, depo kilogram, üretim adet üzerinden çalışıyorsa bu birimler arasındaki ilişki de açık olmalı. Dönüşüm katsayısı yanlışsa sistem gerçekte bulunmayan bir miktarı kullanılabilir sanabilir. Ardından satın alma ve üretim planı aynı hatayı farklı ekranlarda tekrarlar.
Bu nedenle kartın hangi alanlarınin zorunlu olduğunu, kimin açabileceğini ve hangi değişikliğin kimin onayını gerektirdiğini birlikte belirlemeyi önemsiyorum. Satın alma için pratik bir kısaltma, üretim için belirsiz bir tanıma dönüşebilir. Kuralı yalnızca kartı açan ekip değil, o kaydı kullanan ekipler de anlamalı.
Aynı mesele müşteri kayıtlarında da karşımıza çıkar. Aynı gruba bağlı iki şirketin ticari ve tahsilat sorumlulukları ayrı olabilir. Sadece isimler benzediği için tek kayıtta toplanmaları, görünürde düzen sağlarken riskin anlamını bozabilir. Ortak dil, kodun yazılışından daha fazlasıdır.
Temizlik yaparken geçmişi kaybetmeyin
Kart birleştirmek ya da kod değiştirmek, yalnızca bugünkü listeyi etkilemez. Geçmiş siparişlerin, faturaların, stok hareketlerinin ve maliyetlerin hangi tanıma bağlanacağı da planlanmalı. Eski kod ile yeni ortak kimlik arasındaki ilişki korunmazsa, dünku raporla bugünkü raporun neden farklı olduğunu açıklamak zorlaşır.
Seçilen malzemenin özelliğini, birimini ve belge bağlantılarını ilgili süreç sahipleri doğrulamalı. Teknik ekip eşleştirmeyi uygulayabilir; ama kayıtların aynı iş gerçeğini temsil ettiğine yalnızca açıklamalarına bakarak karar verilmemeli. Düzeltme öncesinde hangi raporların ve planların etkileneceği de görülmeli.
Bu noktada standart, geçmişi sessizce silen bir temizlik değil, izlenebilir bir değişiklik haline gelir. Kim, neyi, ne zaman ve neden değiştirdi? Bu kayıt hem yeni raporu anlamaya hem de hata çıkarsa doğru yere dönmeye yardımcı olur. Daha güçlü bir yapay zekâ modeli, kaybedilmiş bu ilişkiyi kendiliğinden geri getirecek bir güvence değildir.
Rakamdan önce hesabın adını koyun
Ortak anlam yalnızca ürün koduyla sınırlı değil. Yönetim “Hangi müşteri kârlı?” diye sorduğunda da hangi hesabın yapılacağı belirlenmeli. Satıştan hangi maliyet düşülüyor? İade ve iskonto hangi döneme yazılıyor? Özel ambalaj veya nakliye gideri hangi yöntemle müşteriye yansıtılıyor?
Brüt kâr ile müşteriye atfedilen giderlerden sonraki katkı aynı gösterge değil. Doğrudan izlenebilen bir giderle varsayıma dayalı dağıtım da ayrı gösterilmeli. Yapay zekânın akıcı bir açıklama yazması, ekiplerin üzerinde uzlaşmadığı hesabı ortak tanıma dönüştürmez.
Bu yüzden veri sözlüğünü sadece teknik bir dosya olarak görmüyorum. Hangi kaydın ne anlama geldiğini ve hangi göstergenin nasıl hesaplandığını açıklayan ortak çalışma belgesi olmalı. Yönetici sonucu okurken kapsamını bilmeli; çalışan da o sonucu besleyen bilgiyi hangi kuralla kaydedeceğini anlayabilmeli. Veriyle karar arasındaki ortaklık burada kurulur.
Yeni kayıt doğru oluşmuyorsa iş bitmemiştir
Veri kalitesindeki sorunları ayırarak izleyebiliriz. Boş vade alanı eksikliktir; dolu ama anlaşmayla uyuşmayan vade doğruluk sorunudur. Aynı müşterinin tekrar açılması mükerrerlik, ödemenin geç işlenmesi güncellik meselesidir. Bunların her biri farklı kontrol ve düzeltme ister.
Başlangıçta sınırlı bir ürün grubuyla çalışalım. Satın alma, depo, üretim ve finans aynı örnek kartı kullanarak işlemi yürütsün. Zorunlu alanları, birim ilişkisini ve onayı gerçek görevleri üzerinde sınasın. Eğitimde doğru cevabı vermekle yoğun bir iş gününde doğru kayıt oluşturmak aynı kanıt değildir.
Bir kural değiştiğinde yalnızca kartı açan kişiyi bilgilendirmek yeterli olmayabilir. Maliyet hesabı, birim ilişkisi veya ürün tanımı değiştiğinde bunu kullanan diğer ekipler de aynı bilgiyi almalı. Eski raporla yeni raporun karşılaştırması etkileniyorsa nedeni açıklanmalı. Eğitimde sınanan kuralın günlük işte belirli bir örneklemle izlenmesi, standardın gerçekten benimsendiğini gösterir. Kullanıcılar sürekli açıklama istiyorsa bu geri bildirim, kuralın sadeleştirilmesi gerektiğine işaret edebilir.
Acil işlem için istisna gerekiyorsa kimin izin vereceği ve eksik bilginin ne zaman tamamlanacağı da belli olsun. Hata listesi üretmek tek başına düzen kurmaz; hatanın sahibine ve kapanışına ihtiyaç vardır. Standart, klasörde duran bir belge değil, yeni kayıt açılırken kullanılan bir kural olmalı. Bir sonraki adımda bu kurallarla oluşan kayıtların departmanlar arasındaki bağlantısına bakacağız.
Bu hafta ekibinize sorun
Karışan bir ürün kaydını seçin. Özellik, birim ve geçmiş belge ilişkisini doğrulamadan kayıtları birleştirmeyin. Ardından şu soruyu yanıtlayın: Yarın aynı malzeme yeniden açılırsa hatayı hangi kural önleyecek?
