Checkup, modülleri saymaktan çok, seçilen kararın verisini ve işleyişini sınamaktır.
ESPADE ERP-AI Dönüşüm Merkezi Kurucusu Mehmet Durak
Açık faturalarınızın toplamını ekranda görüyorsunuz. Peki bu faturalardan birini seçtiğinizde müşterinin kimliğini, geçerli vadeyi, kısmi tahsilatı ve varsa itirazını aynı açıklıkla takip edebiliyor musunuz? ERP’de bir tutarın bulunmasıyla o tutardan hareket ederek karar verebilmek arasındaki fark bazen burada ortaya çıkar.
Bir üretim işletmesi üzerinden düşünelim. Sistemin modülleri aktif, kayıtları yıllara yayılıyor. Ancak tüketimler ay sonunda topluca işleniyorsa, gün içinde malzeme sapmasını izlemek için gereken bilgi henüz oluşmamış olabilir. Bu, şirketin her açıdan hazırsız olduğu anlamına gelmez. Hangi karar için hangi ayrıntı ve güncellik gerektiğini sormamız gerektiğini gösterir.
Modül listesi yerine bir kaydın peşine düşün
ESPADE ERP-AI Checkup yaklaşımında ilk mesele, yazılımın tanıtımındaki kabiliyetler değil, işletmede gerçekte nasıl kullanıldığıdır. Ön başvuru görüşmeyi ve katılımcıları hazırlar. Envanter kullanılan ERP sürümünü, modülleri, özelleştirmeleri ve bağlantıları gösterir. Saha incelemesi ise anlatılan durumu kayıt, ekran ve rapor üzerinde sınar.
Nakit takibi için başladığımızı varsayalım. Birkaç açık faturayı seçer, siparişten tahsilata kadar izleriz. Vade müşteriyle anlaşılan tarihle uyumlu mu? Ödemenin bir bölümü geldiyse hangi faturaya işlendi? İhtilaflı bir tutar normal alacakla birlikte mi görünüyor? Toplam doğru görünse bile bu soruların cevabı eksik olabilir.
Birkaç kaydın doğru çıkması bütün verinin doğru olduğunu kanıtlamaz. Bu inceleme, daha geniş kontrolün nereye yöneleceğini gösterir. Sonra ilgili kapsamda eksik vadelerin, tekrarlanan müşteri kartlarının veya bağlantısız ödemelerin ne kadar yaygın olduğuna bakılır. Böylece “veri kalitemiz düşük” gibi genel bir cümle yerine araştırılabilir bir bulgu oluşur.
Veriyi alabiliyor olmak, kullanabiliyor olmak değil
BT ekibinin “ERP’den veri alabiliriz” demesi önemli bir başlangıç. Fakat hangi alanların alınabildiği, geçmiş değişikliklerin saklanıp saklanmadığı ve verinin ne zaman güncellendiği de bilinmeli. Bir dosyanın dışarı çıkarılabilmesi, içinde karar için gereken bütün bilginin bulunduğunu göstermez.
Örneğin açık siparişin yalnızca bugünkü durumu saklanıyorsa, geçmişte yapılan teslimat tahminini o günün bilgisiyle sınamak zorlaşabilir. Bu eksik erken görülürse gerekli kayıt düzeni kurulabilir. Geliştirme bittikten sonra fark edilirse, pilotun değerlendirilmesi beklemeye girebilir.
Kişisel tabloları da bu nedenle incelemeye dahil ederim. Teslim tarihleri, sipariş değişiklikleri veya yeni vadeler mesajlaşmada kalıyorsa ERP, işin tamamını temsil etmiyor olabilir. Çalışanın dosyası bazen hatanın kendisi değil, sistemde karşılanmayan bir ihtiyacın işaretidir. Önce o dosyanın hangi boşluğu doldurduğunu anlamak gerekir.
Hazırlığı tek bir puana sığdırmayın
Yönetim için bir hazırlık göstergesi yararlı olabilir. Ama yüksek toplam puan, seçilen uygulamanın kritik eksiğini ortadan kaldırmaz. Ürün kartları düzenli, kullanıcılar istekli ve raporlar hızlı olsa da nakit pilotunun ihtiyaç duyduğu vade alanı güvenilir değilse, o kapsam için hazırlık tamamlanmamıştır.
Benim önemsediğim soru “Kaç puan aldık?”tan önce “Neye başlayabiliriz, neyi önce düzeltmeliyiz?”dir. Her eksik aynı önemi taşımaz. Sonucu değiştiren bir alan, raporun görünümünü etkileyen bir ayrıntıdan farklıdır. Yetki veya güvenlik sorunu ise bazı kullanımları durdurmayı gerektirebilir.
Çalışanın hangi veriyi paylaşabileceğini bilmemesiyle, şirketin kayıtlarının eksik olması farklı hazırlık ihtiyaçlarıdır. Birine veri düzenlemesi, diğerine güvenli kullanım ve doğrulama çalışması gerekebilir. Bu nedenle değerlendirmenin hangi kapsamı ve hangi modeli kullandığı açık tutulmalı; farklı ölçeklerin puanları birbirine eklenmemeli. Ekipler aynı rapora baktığında, hangi sonucun kanıtlandığını ve hangi konunun hâlâ teyit beklediğini ayırt edebilmelidir. Hazırlık raporunun işi, belirsizliği iyi görünen bir ortalamada saklamak değil, kararı etkileyen yerde göstermektir.
Sonuç; başlanabilir, belirli düzeltmelerden sonra başlanabilir veya bugün uygun değil biçiminde gerekçelendirilebilir. Bunlar evrensel bir sertifika değil, belirli iş ihtiyacına ilişkin değerlendirmelerdir. Ayrıca şirketin süreç ve veri hazırlığıyla çalışanın yapay zekâ okuryazarlığı ayrı incelenmelidir. Araçları iyi kullanan bir ekip, eksik veriyle yine zorlanabilir.
Bulgu, sorumlusu olan bir işe dönüşmeli
“Eksik vade var” demek yerine hangi kayıtların etkilendiğini, doğru bilgiyi kimin sağlayacağını ve düzeltmenin nasıl kontrol edileceğini yazalım. Gözlem, kanıt, iş etkisi, teyit bekleyen nokta ve sorumlu birlikte görünür olduğunda yönetim kaynak ayırabilir. Aksi halde bulgu bir sonraki toplantıya ertelenir.
Düzeltme iki yönlüdür: Geçmişteki eksik vade tamamlanırken, yarın kararlaştırılacak yeni vadenin kayda girme yolu da kurulmalı. Yalnızca geçmişi temizlemek hatanın yeniden oluşmasını önlemez. Geçmişte güvenilir biçimde bulunamayan bilgi ise varsayımla doldurulup gerçek kayıt gibi sunulmamalı; kullanıma etkisi açıklanmalı.
Checkup’ın değeri böylece raporla sınırlı kalmaz. Bulgu, gerektiğinde bir veri atölyesine, görev düzenlemesine veya kaynak kontrolü eğitimine bağlanır. Her işin hedef tarihi ve yeniden kontrol zamanı belirlenir. Şirketin tamamını kusursuzlaştırmaya çalışmak yerine, seçilen karar için gereken zemini kurarız. Sonraki adım, bu zeminin yeni kayıtlarda da korunmasını sağlayacak ortak standartlardır.
Bu hafta ekibinize sorun
Bir açık faturayı kaynağına kadar izleyin. Müşteri, vade, kısmi tahsilat ve ihtilaf bilgisini kim doğruluyor? Açıklayamadığınız bir fark varsa sorumlusunu ve sonraki kontrol tarihini yazın.
