Kaynak kayıt, ortak tanım, doğrulanmış hesap ve kullanıcıya verilen açıklama birbirinden ayırt edilebilmeli.
Yazan: ESPADE ERP-AI Dönüşüm Merkezi Kurucusu Mehmet Durak
Bir yönetici nakit ekranında beklemediği bir sonuç görüyor. Yapay zekâ açıklaması akıcı: Yaklaşan ödemeler ve geciken tahsilatlar nedeniyle baskı var. Peki hangi ödeme, hangi tahsilat, hangi tarih? Yönetici bu soruların cevabına ulaşamıyorsa, açıklamanın iyi yazılmış olması karar için yeterli değildir.
Bu örnek, “ERP’ye bağlandık” ile “güvenilir karar desteği kurduk” arasındaki farkı anlatıyor. Mimari dediğimiz yapı yalnızca kutular ve oklar değil. Verinin nereden geldiğini, nasıl hazırlandığını, hangi kuralla hesaplandığını ve kullanıcıya ne zaman sunulduğunu açıklıyor. Bağlantı aksadığında ne olacağı da bu yapının parçası.
Önce hangi işin nerede yapıldığını ayırın
ERP, sipariş, stok hareketi, üretim, fatura ve ödeme gibi günlük işlemleri yürütür. Ortak veri katmanı bu kayıtların analizde kullanılacak tanım ve ilişkilerini düzenler. Karar desteği ise doğrulanmış göstergeleri, senaryoları, gerektiğinde tahminleri ve açıklamaları kullanıcıya sunar. Bu görevleri ayırmak, hatayı nerede arayacağımızı da netleştirir.
Satış, finans ve üretim uygulamalarının aynı müşteriyi ayrı ayrı temizlediğini düşünelim. Bir yerde iki kart birleştirilirken diğerinde ayrı kalabilir. Ürün tanımı değiştiğinde birkaç farklı düzeltme gerekebilir. Ekranlar ayrı ayrı çalışsa da yönetim aynı müşteri veya ürün için farklı sonuçlar görebilir.
Bu nedenle ortak tanımların, eşleştirme kurallarının ve değişiklik geçmişinin yönetildiği bir düzen kurulmalı. Bu her şirkete büyük bir veri platformu almak demek değil. Küçük bir pilotta daha sınırlı yapı yeterli olabilir. Benim aradığım ölçü, aracın büyüklüğü değil; kaynaktan sonuca giden yolun izlenebilmesidir.
Hesabı açıklayan cümle, hesabın kanıtı değildir
Müşteri bakiyesi, stok miktarı veya gerçekleşmiş maliyet, işletmenin onayladığı hesaplama kurallarıyla elde edilmeli. Dil modeli bu sonucu anlatmak, soruyu ilgili göstergeye yönlendirmek veya bulguları anlaşılır hale getirmek için kullanılabilir. Fakat sayısal sonuç, yazılan açıklamadan bağımsız olarak kontrol edilebilmeli.
Nakit senaryosunda açılış bakiyesi, beklenen tahsilatlar ve planlanan ödemeler tanımlı hesapla bir araya gelir. Bir tahsilatın gecikmesi varsayımı değiştiğinde sonuç yeniden hesaplanır. Yapay zekâ bu değişimi açıklayabilir. Ancak kayıtta olmayan bir tahsilat tarihini kesin bilgiymiş gibi tamamlaması kabul edilmemeli; eksik bilgi eksik olarak kalmalı.
Belgelerde bilgi arama, talep tahmini ve anormallik uyarısı da aynı görev değildir. Her biri farklı veri ve değerlendirme düzeni gerektirebilir. Bazen mevcut ERP raporu veya basit bir kural ihtiyacı karşılar. Daha karmaşık bir model seçmek kendi başına daha iyi tasarım demek değil. Yönetim, kullanılan yöntemin daha basit seçeneğe göre neyi geliştirdiğini görebilmeli.
Veri gelmediğinde ekran ne yapacak?
Bağlantı yöntemi seçilirken ERP’nin sürümü, özelleştirmeleri, destek koşulları ve erişim olanakları değerlendirilir. Sistemin desteklediği bağlantı arayüzü (API), kontrollü veri erişimi veya planlı aktarım kullanılabilir. Ürünün tanıtımında bulunan bir özelliğin, işletmenin mevcut kurulumunda aynı şekilde çalıştığı varsayılmamalı.
Hangi alanların alınacağı kadar değişen ve silinen kayıtların nasıl izleneceği de belirlenmeli. Son başarılı aktarım zamanı ve eksik kaynaklar görünür olmalı. Aktarım tamamlandı mesajı, bütün verinin güncel olduğunu tek başına kanıtlamaz. Günlük işlemleri zorlayan kontrolsüz sorgular da sürdürülebilir bir çözüm oluşturmaz.
Kritik kaynak gelmediğinde hangi hesap duracak, hangisi son doğrulanmış veriyle gösterilecek? Eski veriyle karar vermek kabul edilmiyorsa sadece tarih etiketi koymak yeterli olmayabilir. Kullanıcının yanlışlıkla güncel sandığı bir sonuçla hareket etmemesi gerekir. Mimariyi bu hata durumlarıyla birlikte konuşmak, yalnızca normal akışta çalışan gösterimden daha açık bir tasarım sunar.
Bir kaydı baştan sona birlikte izleyin
Mimariyi sınamak için seçilen bir kaydın aktarımını, eşleştirilmesini, hesaba girmesini ve kullanıcıya sunulmasını birlikte izleyebiliriz. Aynı kayıt değiştiğinde sonuç nasıl güncelleniyor? Yeni bir kural önce test ortamında nasıl deneniyor? Kullanılan sürüm ve hesap tanımı korunuyorsa geçmiş sonucun neden değiştiği araştırılabilir.
ESPADE’in hazırlık rolü; iş ihtiyaçlarını, gösterge tanımlarını, süreç ilişkilerini ve kabul senaryolarını teknik ekibe aktarılabilir hale getirmektir. Yazılım proje ortağı mutabık kalınan teknik çözümü geliştirir. BT erişim ve sistem koşullarını, iş birimleri kayıtların anlamını ve sonucun doğruluğunu kontrol eder. Sınırlar proje kapsamında netleştirilir.
Bu çalışmaya iş birimi, BT, ERP uygulama ekibi ve yapay zekâ geliştirme ekibi aynı örnekle katılabilir. Nakit için alacağın kaynağı, vade bilgisi, kapatma ilişkisi ve mutabakat kontrolü birlikte gösterilir. Veri sözlüğü, süreç ilişkileri ve kabul senaryoları birbirini tutmuyorsa, çizim güzel olsa bile uygulamanın kapsamı henüz net değildir. İşletmenin kabul edeceği tasarım, bu belgelerde aynı kaydın aynı anlamla takip edilebildiği tasarımdır.
Teknik çizimin bütün ayrıntısını her yöneticinin bilmesi gerekmez. Ancak yönetici kendi kararının hangi veriye, hangi hesaba ve hangi güncelliğe dayandığını anlayabilmeli. Yalnızca teknik ekibin açıklayabildiği bir yapı, iş doğrulamasını zorlaştırır. Sonraki adım da bu bilgiye kimin ulaşacağını ve hangi yetkiyle hareket edeceğini belirlemektir.
Bu hafta ekibinize sorun
Bir yönetim göstergesi seçin. Kaynak kayda, hesap kuralına ve son güncelleme zamanına ulaşabiliyor musunuz? Kaynak veri gelmezse bu göstergeyi kullanıcıya nasıl sunacağınızı da açıklayın.
