Siparişten tahsilata uzanan akışta tek tek doğru kayıtlar, her zaman ortak bir sonuç üretmiyor.
Yazan: Mehmet Durak | ESPADE ERP-AI Dönüşüm Merkezi Kurucusu
Satış ekibinin bir siparişin teslim tarihini müşteriyle değiştirdiğini düşünün. Müşteri yeni tarihi kabul etmiş, satışın notu güncellenmiş. Ancak üretim eski tarihe göre çalışıyor ve gecikme raporu hazırlıyor. Satış “gecikme yok” derken üretim “hedef kaçtı” diyor. İki ekip de elindeki bilgiyle konuşuyor.
Bu örnek senaryoda bir yapay zekâ uygulamasına iki raporu vermek, hangi tarihin geçerli olduğunu kendiliğinden netleştirmez. Önce değişikliğin nerede kaydedileceği, kim tarafından onaylanacağı ve diğer departmanlara nasıl ulaşacağı bilinmeli. Sorun, ekranların birbirine bağlanmasından önce işin nasıl bağlandığıyla ilgilidir.
Aynı iş, farklı “tamamlandı”lar
Sipariş, üretim, sevkiyat, fatura ve tahsilat aynı işin farklı aşamaları. “Tamamlandı” ifadesi satış için siparişin alınması, depo için ürünün gönderilmesi, finans için paranın gelmesi anlamına gelebilir. Her aşamanın durumu açık değilse yönetim tek kelimeden farklı sonuçlar çıkarır.
Bu nedenle bir süreç haritasına bakarken kutuların düzeninden önce kayıtlar arasındaki ilişkiyi sorarım. Siparişin hangi bölümü sevk edildi? Hangi teslimat faturalandı? Tahsilat hangi faturaları kapattı? Bir olayın başka bir departmanda hangi bilgiyi değiştirdiği anlaşılmıyorsa, harita günlük işi henüz anlatmıyor demektir.
Üstelik akış her zaman tek sipariş, tek teslimat, tek fatura biçiminde ilerlemez. Bir sipariş üç teslimata bölünebilir; bir tahsilat birkaç faturayı kapatabilir. Sipariş tutarı her teslimat satırında yeniden toplanırsa satış hacmi birkaç kez sayılabilir. Bağlantının teknik olarak kurulması yetmez; hangi tutarın hangi düzeyde hesaplandığı açık olmalı.
Tarih değiştiğinde kimin planı değişiyor?
Bir kaydın sisteme girildiği tarih ile işin gerçekleştiği tarih aynı olmayabilir. Fatura tarihi, vade, tahsilat tarihi ve kaydın işlenme zamanı farklı sorulara cevap verir. Tahsilat gerçekleşmiş ama kayda girmemişse, uygulamanın okuduğu veri nakit durumunu eksik gösterebilir.
Kayıtlar ay sonunda tamamlanıyorsa her dakika veri aktarılması, bilgiyi her dakika doğru hale getirmez. Önce olayın ERP’ye hangi zamanda işleneceğini belirlemek gerekir. Günlük karar ile aylık değerlendirme aynı güncellik ihtiyacına sahip olmayabilir; aktarım sıklığı bu ihtiyaca göre seçilmeli.
Teslim tarihi değişikliğine dönelim. Yeni tarih üretime, sevkiyata ve gerekiyorsa finansın tahsilat varsayımına nasıl yansıyacak? Eski tarihin üzerine açıklamasız yazılırsa, daha sonra gecikmenin nedenini araştırmak zorlaşabilir. Değişiklik nedeni ve onay bilgisi, işin takip ihtiyacına göre korunmalı. Yönetimin görmek istediği yalnızca son tarih değil, o tarihin hangi iş kararına dayandığıdır.
En yararlı örnek, sorunsuz ilerleyen sipariş olmayabilir
Süreç çalışmasına son dönemde zorlanılan bir işlemi getirmenin değerli olduğunu düşünüyorum. Kısmi teslimat, son anda değişen sipariş, kalite nedeniyle bekleyen malzeme veya iade, normal akışta görünmeyen ilişkileri ortaya çıkarır. Çalışanın sorunu nasıl çözdüğü ile sistemin bunu nasıl kaydettiği birlikte incelenir.
İade bilgisi alacak hesabına geç yansıyorsa tahsilat uygulaması, müşteriden artık geçerli olmayan bir borcu istemeyi önerebilir. Burada daha iyi bir iletişim metni yazmak sorunu çözmez. İadenin onayı, alacağa etkisi ve ihtilaflı tutarın tahsilat listesindeki durumu doğru kurulmalı. Önerinin insan kontrolünden geçip geçmeyeceği de ayrı bir adımdır.
Her istisna için yeni bir özel yazılım geliştirmek gerekmez. Sık tekrarlanan durum ortak bir kurala bağlanabilir; nadir durum için açık bir inceleme ve onay yolu yeterli olabilir. Önemli olan, çalışanların gerçekte nasıl davrandığını yok saymadan, bu davranışın veri ve karar üzerindeki etkisini görmektir.
Organizasyon şemasını işleyen bir akışa çevirin
Unvanların şemada bulunması, siparişin kimlerin kararıyla ilerlediğini tek başına göstermez. Ticari şartı satış, kredi sınırını yetkili finans birimi, üretilebilirliği planlama değerlendirebilir. Aynı kişinin birden fazla görev üstlendiği şirketlerde de hangi kararda hangi sorumluluğu taşıdığı açık olmalı.
Bu görevlerin birbirinden kopmaması için bütün akışı koordine eden bir süreç sorumluluğuna ihtiyaç vardır. Bu, her işi bir kişinin yapması demek değil; departmanlar arasındaki tarih, durum ve belge uyuşmazlığının nasıl çözüleceğinin bilinmesidir. Varsayılan yazılım akışı işletmeyle doğrulanmadığında, aradaki boşluk kişisel tablolar ve mesajlarla kapanabilir.
Departman hedefleri arasındaki ilişki de bu çalışmada görünür olmalı. Yalnızca ciroya odaklanan bir satış hedefi, ödeme ve üretim koşulları dikkate alınmadığında diğer alanlarda baskı yaratabilir.
Satışın teslim sözü kapasiteyle, malzeme ihtiyacı satın alma planıyla, müşteri vadesi nakit ihtiyacıyla birlikte değerlendirilir. Süreç haritası böylece sadece verinin hangi ekrana gittiğini değil, bir kararın başka bir ekibin hangi işini değiştirdiğini de anlatır.
Ortak bir atölyede tek siparişi baştan sona izlemek somut bir başlangıç sunar. Her aşamanın girdisi, çıktısı, kaydı, sorumlusu ve onayı yazılır. Ardından normal işlemin yanında bir kısmi teslimat veya iade de denenir. Başarı bütün kutuların çizilmesi değil, ekiplerin aynı işlemi aynı anlamla takip edebilmesidir. Yapay zekâya taşınacak ortak veri yapısı da bu ilişkilerin üzerine kurulmalıdır.
Bu hafta ekibinize sorun
Son değişen bir siparişi seçin. Satış, üretim, depo ve finansın hangi tarih ve duruma baktığını karşılaştırın. Bilgi nerede kopuyor, düzeltme kimin sorumluluğunda?
