Yatırım kararını ürün listesinden değil, şirketin cevap bekleyen tek bir sorusundan başlatmak.
Yazan: ESPADE ERP-AI Dönüşüm Merkezi Kurucusu Mehmet Durak
Bir üretim şirketi düşünün. ERP’si var, raporları hazırlanıyor. Yönetim şimdi nakit riskini daha erken görmek için yapay zekâ kullanmak istiyor. Fakat satış ekibinin müşteriyle anlaştığı yeni vade ayrı bir tabloda duruyor. Finansın sisteminde eski tarih kayıtlı. Aynı müşteri iki farklı kartla izleniyor.
Bu şirkete yeni bir uygulama eklendiğinde ilk soru şu olmalı:
Uygulama hangi bilgiyi doğru kabul edecek? Yeni ekran, eski vadeyi daha hızlı gösterebilir. Ama hızlanması, bilginin doğru olduğu anlamına gelmez. Bu örnek senaryoda yatırımın başlangıcı yazılım seçimi değil, hangi kararın hangi bilgiyle verileceğini netleştirmektir.
Bir teknoloji niyeti, henüz proje değildir
“Yapay zekâ kullanmak istiyoruz” değerli bir niyet. Ancak şirketin neyi iyileştireceğini tek başına anlatmıyor. “Önümüzdeki dönemde hangi ödemeleri, hangi tahsilat beklentisiyle karşılayacağız?” sorusu ise çalışılabilir bir başlangıç sunuyor. Hangi kayıtların gerekli olduğunu, hangi ekibin katılacağını ve sonucun nasıl kontrol edileceğini konuşabiliyoruz.
Benim için iyi bir ilk toplantınin çıktısı uzun bir özellik listesi değildir. Yönetimin hangi kararı, neden bugünkünden daha iyi vermek istediğini açıklayabilmesidir. Daha erken uyarı almak, raporu daha kısa sürede hazırlamak ve hesabı daha tutarlı yapmak birbiriyle ilişkili olabilir. Yine de ilk olarak hangisini ölçeceğimiz belli olmalı.
Bunun için bugünkü yönteme bakarız. Finans bilgiyi kimden alıyor? Hangi alanı elle düzeltiyor? Rapor hangi aşamada bekliyor? Yönetim rapor geldiğinde ne yapıyor? Bir satın alma onayının sahibi belirsizse, tahmin ekranı o sorumluluğu kendiliğinden oluşturmaz. Teknolojiden beklenen işle şirketin kendi içinde çözmesi gereken işi ayırmak gerekir.
Yazılımın üzerine kurulacağı zemin
Örneğimizde nakit görünümü için müşteri kimliği, geçerli vade, tahsilat kaydı ve güncelleme sorumluluğu birlikte ele alınmalı. Sadece eski kayıtları düzeltmek de yetmez. Satış yarın yeni bir vade anlaştığında bu bilginin nerede, kim tarafından ve ne zaman kaydedileceği bilinmeli.
ESPADE’in eğitim ve dönüşüm danışmanlığı burada başlıyor. ERP veya yapay zekâ yazılımı satmak yerine, iş ihtiyacını, süreci, veriyi ve ekiplerin hazırlığını birlikte ele alıyoruz. Yazılım proje ortağı mutabık kalınan teknik kapsamı uygular; işletme yönetimi hedefi ve karar sorumluluğunu üstlenir. Görevlerin kesin sınırı proje planında yazılmalıdır.
Yaklaşımımızdaki 70-20-10 çerçevesi de bu önceliği anlatır: yüzde 70 süreçler ve insan, yüzde 20 veri ve güvenlik, yüzde 10 teknoloji. Bu, başarı istatistiği veya bütçe dağılımı değil, bir öncelik çerçevesidir. İnsan emeği her aşamada vardır; teknik geliştirme de ayrı uzmanlık ve bakım gerektirir. Alanlardan birinin önemini vurgulamak, diğerini küçültmek anlamına gelmez.
Hazırlık, bütün şirketi bekletmek değildir
“Önce hazırlanalım” derken şirketin bütün kayıtlarının kusursuz olmasını beklemeyi önermiyorum. Seçtiğimiz karar için hangi eksiklerin kritik olduğunu bilmemiz gerekiyor. Nakit uygulamasında vade bilgisi gerekli olabilir; o kararda kullanılmayan eski bir açıklama alanı aynı önceliği taşımayabilir.
Bazı işler birlikte ilerleyebilir. Müşteri kartları eşleştirilirken arayüz tasarımı hazırlanabilir. Fakat müşteri risk listesinin yönetim tarafından güvenilir kabul edilmesi, bu eşleştirmenin doğrulanmasına bağlıdır. Tasarımın tamamlanmasıyla kullanıma hazır olması aynı karar değildir.
Benzer şekilde, mevcut ERP’nin korunması onun içindeki her bilginin doğru kabul edilmesini gerektirmez. Sistem günlük işlemleri yürütürken üzerinde karar desteği geliştirilebilir; bunun koşulları veri erişimi ve kayıtların kullanılabilirliğiyle değerlendirilir. Yatırımı ertelemekle yatırımın ön koşullarını yazmak arasında önemli bir fark var.
İlk teslimatınız bir ekran olmayabilir
İlk çalışmanın sonunda bir sayfalık iş hedefi belgesi hazırlanabilir: Seçilen karar, mevcut sorun, kapsam, gerekli veri, süreç sahibi ve başarı ölçüsü. Bu belge, teknik ekibin ihtiyacı anlamasını ve yönetimin neye kaynak ayırdığını görmesini sağlar. Yöneticilerle süreç sahiplerinin birlikte çalıştığı eğitim de böyle bir çıktıya dönüşebilir.
Proje bütçesinde yalnızca lisans ve kurulum bulunmamalı. Veri düzenleme, çalışan zamanı, bağlantıların bakımı ve kontrol ihtiyacı da görünür olmalı. Başlangıçta nakit takibi diye açılan kapsama sonradan üretim tahmini eklendiğinde, bunun ayrı veri ve doğrulama ihtiyacı olduğu unutulmamalı.
Bir yazılım projesinin hedefe ulaşmamasını hemen ürüne, bayiye veya kullanıcıya bağlamamak gerekir. Ürün eksiği, uygulama hatası ve işletmenin hazırlık eksiği ayrı ayrı incelenmeli. Kurulumun tamamlanması, satın alma yetkisinin veya maliyet kuralının tanımlandığını göstermez. Yönetimin bu ayrımı yapması, bir sonraki yatırımda aynı sorunu tekrar etmemek için önemlidir. Hazırlığın tamamlandığını da toplantı yapılmış olmasıyla değil, onaylanan tanım ve doğrulanan kayıtla anlayabiliriz.
Yazılımın iyi olması önemli. Ama hangi işi, hangi koşullarda iyileştireceğini bilmediğimiz bir üründen dönüşüm beklemek yeterli değil. İlk kararı netleştirdiğimizde, bir sonraki adım da açık hale geliyor: Şirket bu karara bugün ne kadar hazır?
Bu hafta ekibinize sorun
Tek bir yönetim raporu seçin. Hangi karara hizmet ettiğini, hangi kayıtlara dayandığını ve nerede elle düzeltildiğini birlikte yazın. Hazırlık gündeminiz, cevaplayamadığınız noktada başlayabilir.
