Bir finans müdürü ayın 3’ünde nakit durumunu merak ettiğinde genelde iki yol vardır. Ya muhasebeye “şu raporu bir çıkarır mısınız” diye sorar ve öğleden sonrayı bekler, ya da kendi Excel dosyasını açıp üç ayrı ekrandan veri çekmeye başlar. İkisi de aynı sorunu paylaşır: soru anlık, cevap gecikmeli.
Son bir yılda ERP tarafında konuşulan değişikliklerden biri tam bu boşluğu hedefliyor. Rapor artık önceden tasarlanmış, sabit bir ekran olmaktan çıkıp soruya cevap veren bir katmana dönüşüyor. “Geçen ayki en çok gecikmiş 10 cariyi listele” ya da “Ekim’de hangi ürün grubunda marj düştü” gibi bir soru yazılıyor, sistem ekranı önceden tasarlamamış olsa bile cevabı üretiyor. Bu yazıda bu değişimin somut olarak neyi kapsadığını, hangi altyapıyı gerektirdiğini ve yönetilmezse nereye savrulabileceğini ele alıyoruz.
Klasik raporlamanın sınırı: soruyu önceden tahmin etmek
Geleneksel ERP raporlaması bir varsayıma dayanır: hangi soruların sorulacağı önceden bilinir ve o sorulara göre sabit rapor şablonları tasarlanır. Aylık satış özeti, stok yaşlandırma tablosu, cari yaşlandırma raporu — hepsi bu mantıkla kurulur.
Sorun, gerçek işin bu kalıba uymamasıdır. Bir bölge müdürü “geçen çeyrekle bu çeyreği aynı müşteri segmentinde kıyasla” demek isteyebilir; bu soru şablonda yoksa, ya IT’den özel rapor istenir ya da veri Excel’e çekilip elle birleştirilir. Her iki yol da gün kaybettirir ve sonucun doğruluğu, veriyi birleştiren kişinin dikkatine bağlı kalır.
Klasik raporlama yanlış değildir; sadece tek başına yetersiz kalmaya başlamıştır. Sabit rapor hâlâ düzenli takip için gereklidir, ama artık tek katman olmaktan çıkıyor.
Doğal dilde sorgulama gerçekte ne değiştiriyor
Doğal dil sorgulama, kullanıcının rapor tasarlamak yerine doğrudan soru sormasıdır. Teknik karşılığı şudur: yazılan soru, ERP’nin veri modelindeki tablo ve alanlara eşlenir, sonuç bir grafik veya tabloya dönüştürülür.
Burada abartılı bir vaat yok — sistem sihirli biçimde her şeyi bilmiyor, sadece ERP içindeki gerçek veriye soru üzerinden erişim sağlıyor. Pratikte fark şurada ortaya çıkıyor:
- Ekran tasarlamak yerine soru sormak. Yeni bir kırılım gerektiğinde IT’ye talep açmak yerine soru cümlesi değiştirilir.
- İlk seviye analiz karar vericide kalır. Veriyi çekip Excel’de birleştiren ara adım kalkar; sayı direkt karar vericinin önüne gelir.
- Takip sorusu doğal akışta sorulur. “Bu düşüşün hangi bölgeden kaynaklandığını göster” gibi bir sonraki soru, yeni bir rapor talebi değil, aynı konuşmanın devamı olur.
Burada dikkat edilmesi gereken nokta şu: doğal dil katmanı, altındaki veri doğru ve güncel değilse yanlış cevabı da aynı hızda ve aynı güvenle üretir. Yani bu katman, veri kalitesindeki eksikleri gizlemez, hızlandırır. Ana veri düzeni bozuksa sorgulama katmanı da o bozukluğu miras alır.
Geçmişe bakan rapordan geleceği işaret eden panoya
İkinci değişim, raporun zaman yönüyle ilgili. Klasik raporlama neredeyse tamamen geriye dönüktür: geçen ay ne oldu, geçen çeyrek nasıl geçti. Yeni nesil pano katmanı ise mevcut veri desenini ileri projekte etmeye çalışır.
Üç örnek üzerinden somutlaştıralım:
- Talep tahmini. Geçmiş satış hareketi, mevsimsellik ve açık siparişler birlikte okunarak önümüzdeki dönemin olası talep aralığı çıkarılır. Kesin rakam değil, aralık ve güven düzeyi ile sunulur.
- Nakit akışı projeksiyonu. Açık alacaklar, vadeli borçlar ve tahsilat geçmişindeki gecikme deseni birlikte işlenerek önümüzdeki haftaların olası nakit pozisyonu görülür.
- Tedarikçi risk skorlaması. Teslim gecikmesi, fiyat oynaklığı ve sipariş iptali geçmişi birlikte değerlendirilerek hangi tedarikçinin kritik dönemde risk taşıdığı işaretlenir.
Bu üçünün ortak noktası: hiçbiri kararı otomatik vermez. Karar destek üretir, kararın kendisi finans müdüründe, satınalma sorumlusunda ya da satış müdüründe kalır. Bu ayrım önemli; öngörücü panoyu “otomatik pilot” gibi sunmak beklenti yönetimini bozar ve ilk yanlış tahminde güveni sıfırlar.
Bu katmanın çalışması için gereken zemin
Doğal dil sorgusu ve öngörücü pano, üzerine oturacağı bir zemin olmadan çalışmaz. Üç şart öne çıkıyor:
Tek platform, dağınık veri değil. Satış ayrı sistemde, stok ayrı sistemde, finans ayrı sistemde tutuluyorsa, sorgulama katmanı önce bu parçaları birleştirmek zorunda kalır — ki bu genelde entegrasyon projesine dönüşür. Qera ERP’de modüller aynı veri omurgasını paylaştığı için sorgu katmanı ayrı bir birleştirme adımına ihtiyaç duymadan çalışır.
Temiz ve tutarlı ana veri. Mükerrer cari kart, tutarsız birim tanımı ya da terk edilmiş stok kartı varsa, sorgu sonucu da bu dağınıklığı taşır. Bu konuyu ana veri yönetimi yazımızda ayrıntılı ele aldık.
Gerçek zamanlıya yakın senkron. Rapor gece toplu işlemle bir kez güncelleniyorsa, gün içi soru sorma deneyimi anlamını yitirir. Bulut altyapısında çalışan bir sistemde bu senkron gecikmesi düşüktür; Qera ERP, Microsoft Azure altyapısında çalıştığı için veri, işlem anına yakın biçimde raporlama katmanına yansır.
Yetki, görünürlük ve denetim izi
Sorgulama katmanı serbestleştikçe bir soru kaçınılmaz olur: herkes her şeyi sorabilir mi? Cevap hayır olmalı, ve bu konuda üç kural pratikte işe yarıyor.
- Rol bazlı veri görünürlüğü. Bir satış temsilcisi kendi bölgesinin rakamlarını sorgulayabilir, şirket geneli kâr marjını sorgulayamaz. Yetkilendirme sorgu katmanında da satır ve sütun düzeyinde geçerli olmalı.
- Sorgu geçmişi kaydı. Kim, ne zaman, hangi soruyu sordu ve hangi veriye eriştiği loglanmalı. Bu hem güvenlik hem de “bu rakamı nereden aldın” tartışmalarını kapatmak için gerekli.
- Tahmin ile gerçek veri ayrımı net olmalı. Öngörücü bir panoda gösterilen rakamın “gerçekleşen” mi yoksa “tahmini” mi olduğu ekranda belirsizse, yönetim toplantısında iki kişi farklı sayıyı doğru sanabilir. Ayrım görsel olarak (renk, etiket) net konmalı.
Modüle göre örnek kullanım
| Modül | Klasik rapor | Sorgu + öngörü katmanıyla |
|---|---|---|
| Satış | Aylık satış özeti tablosu | ”Hangi müşteri segmentinde marj daraldı” sorusuna anlık cevap + önümüzdeki ay talep aralığı |
| Finans | Cari yaşlandırma raporu | Tahsilat geçmişine göre önümüzdeki 4 haftanın olası nakit pozisyonu |
| Satınalma / Stok | Kritik stok listesi | Tedarikçi teslim geçmişine göre risk skoru + yeniden sipariş önerisi |
| Üretim | Kapasite kullanım raporu | Darboğaz oluşma ihtimali yüksek iş merkezlerinin önceden işaretlenmesi |
Kurumsal değerlendirme süreci için kontrol listesi
Bir kurumun bu katmana geçmeye hazır olup olmadığını değerlendirirken bakılacak noktalar:
- Ana veri (stok kartı, cari kart, hesap planı) ne kadar tutarlı; mükerrer kayıt oranı nedir?
- Modüller tek bir veri omurgasında mı, yoksa ayrı sistemlerde parçalı mı tutuluyor?
- Rol bazlı erişim, mevcut ERP’de satır/sütun düzeyinde tanımlanabiliyor mu?
- Sorgu ve erişim geçmişi denetlenebilir biçimde kaydediliyor mu?
- Yönetim ekibi, tahmini rakam ile gerçekleşen rakamı ayırt edecek bir okuma alışkanlığına sahip mi?
Bu kriterler üzerinden net bir tablo isteyen kurumlar için ücretsiz demo talebi üzerinden görüşme planlanabilir; ön bilgi paylaşımı için bir taahhüt gerekmez.
Sıkça Sorulan Sorular
Doğal dil sorgulama, mevcut sabit raporların yerini alır mı?
Hayır, tamamlar. Düzenli takip edilen aylık kapanış raporları gibi sabit ekranlar kalmaya devam eder; sorgulama katmanı bunların dışında kalan, önceden tasarlanmamış soruları karşılar.
Öngörücü pano rakamları ne kadar güvenilir?
Geçmiş veri deseni ne kadar düzenliyse tahmin de o kadar isabetli olur. Mevsimsel dalgalanma ya da olağandışı bir olay (kampanya, tedarik krizi) varsa aralık genişler. Bu yüzden rakamlar tek bir sayı değil, aralık ve güven düzeyiyle sunulmalı.
Bu katman için ayrı bir yapay zekâ projesi mi başlatmak gerekir?
Genelde hayır. Tek platformda çalışan bir ERP’de bu katman modüllerin üzerine kurulan bir yetenektir; ayrı bir veri ambarı ya da entegrasyon projesi gerektirmez. Parçalı sistemlerde ise önce birleştirme adımı gerekir.
KVKK açısından dikkat edilmesi gereken bir nokta var mı?
Evet. Sorgu katmanı kişisel veri içeren alanlara (personel, müşteri iletişim bilgisi) erişebiliyorsa, rol bazlı görünürlük ve erişim logu KVKK kapsamındaki veri sorumlusu yükümlülükleri açısından da önemlidir.
Küçük ölçekli bir işletme için bu yatırımın anlamı var mı?
Ölçekten bağımsız olarak, kurum tek platformda çalışıyorsa bu katman ek bir donanım veya ayrı proje gerektirmeden devreye alınabilir. Asıl ön koşul ölçek değil, veri düzenidir.
Mevcut raporlarımızı bu katmana geçirmek ne kadar sürer?
Bu, mevcut ana veri düzeninin durumuna ve modüllerin tek platformda olup olmadığına bağlı değişir; net süre için kurum profiline özel bir değerlendirme gerekir.
Raporlamanın bu yönde ilerlemesi tek bir ürünün pazarlama iddiası değil; talep tahmini, nakit projeksiyonu ve doğal dil sorgusu farklı ERP sağlayıcılarının yol haritalarında benzer biçimde yer alıyor. Asıl ayrışma noktası, bu katmanın hangi veri zemini üzerine kurulduğu. Qera ERP’de tüm modüller tek platformda ve Microsoft Azure altyapısında çalıştığı için sorgu ve öngörü katmanı, ayrı bir entegrasyon projesi olmadan devreye alınabiliyor.
Konuyla ilgili diğer yazılarımız: ERP’de ana veri yönetimi ve ERP’de ajan tabanlı yapay zekâ.
