Bir ekip sürekli aynı bilgiyi başka bir tabloya yazıyorsa otomasyon isteği anlaşılır. Fakat o bilgi neden iki yerde tutuluyor? Hangi kayıt doğru kabul ediliyor? Bir alan değiştiğinde diğerini kim güncelliyor?
Bu sorular yanıtlanmadan yapılan otomasyon, mevcut karışıklığı daha hızlı yayabilir. Başlamadan önce kısa bir süreç incelemesi yapmak, bazen geliştirilecek sistemi küçültür; bazen de otomasyona ihtiyaç kalmadığını gösterir.
İşin başladığı ve bittiği noktayı belirleyin
“Sipariş süreci” tek başına yeterince açık değildir. Başlangıç, müşterinin e-posta göndermesi mi, satışın siparişi onaylaması mı? Bitiş, ürünün hazırlanması mı, sevk edilmesi mi, müşteriye teslim edilmesi mi?
Bir başlangıç ve bir bitiş seçin. Aradaki adımları işi yapan kişilerle birlikte yazın. Resmi talimatta görünen akışla günlük uygulama farklıysa bu farkı da kaydedin. Otomasyonun işleyeceği yer, çoğu zaman gerçek uygulamadır.
Her adımda neyin taşındığına bakın
Bir adımdan diğerine sadece görev geçmez; bilgi ve sorumluluk da geçer. Satış sipariş miktarını iletir, planlama teslim tarihini değerlendirir, depo ürün durumunu kontrol eder. Bu geçişlerde eksik olan şey bazen yazılım değil, net bir bilgidir.
Her adım için girdiyi, çıktıyı ve sorumluyu belirleyin. “İlgili ekip bakar” yerine hangi rolün hangi koşulda karar vereceğini yazın. Kişi izinli olduğunda veya bilgi gelmediğinde ne olacağını da sorun.
İşlem süresi ile beklemeyi ayırın
Bir işin tamamlanması iki gün sürüyor olabilir ama bunun yalnızca bir bölümü aktif çalışmadır. Kalan zaman bilgi beklemek, onay almak veya doğru kişiye ulaşmakla geçebilir.
Diyelim ki varsayımsal bir talebin hazırlanması 20 dakika, onay beklemesi bir iş günü sürüyor. Hazırlığı 10 dakikaya indirmek yararlı olsa da ana gecikme yerinde kalır. Bu örnek gerçekleşmiş bir ölçüm değil; hangi süreyi iyileştirdiğinizi ayırmanın önemini gösterir.
İstisnaları ayrıca konuşun
En kolay akış çoğu zaman demoda gösterilen akıştır. Gerçek işte eksik ürün kodu, değişen teslim tarihi, mükerrer talep veya iptal bulunur. Bu durumların sisteme nasıl yansıyacağını önceden düşünün.
- Eksik bilgi varsa süreç nerede duracak?
- Aynı talep ikinci kez gelirse nasıl fark edilecek?
- Yanlış kayıt oluşursa kim düzeltecek?
- Dış sistem yanıt vermezse yeniden deneme nasıl yapılacak?
- İşlem yarıda kalırsa tamamlanmış adımlar yeniden çalışacak mı?
Bu soruların tamamına ilk gün kusursuz cevap vermek gerekmiyor. Ancak belirsiz olanları görünür kılmak gerekir. Kritik bir istisna bilinmiyorsa denemenin kapsamını daraltabilirsiniz.
Gereksiz adımı otomatikleştirmeyin
Bir alan artık kullanılmıyorsa otomatik doldurmak yerine kaldırmak daha iyi olabilir. İki rapor aynı bilgiyi taşıyorsa ikisini de hızlandırmadan önce neden ayrı olduklarını inceleyin. Her onayın gerçekten karar üretip üretmediğini sorgulayın.
Bu aşama çalışanların işini eleştirmek için değil, sistemi anlamak için yapılmalı. İnsanların eklediği küçük bir kontrol adımı, geçmişteki gerçek bir hataya karşı geliştirilmiş olabilir. Amacını öğrenmeden kaldırmak yeni sorun yaratabilir.
Dar bir pilot ve geri dönüş yolu kurun
Bir ürün grubu veya tek bir talep türüyle başlayın. Başarı ölçütünü ve durdurma koşulunu önceden yazın. İşlem kaydını görebileceğinizden, hataları düzeltebileceğinizden ve gerekirse önceki çalışma biçimine dönebileceğinizden emin olun.
Yapay zekâ kullanacaksanız ayrıca hangi kararların modele bırakılacağını ve hangi işlemlerin insan onayı gerektirdiğini belirleyin. Her adımın yapay zekâ içermesi gerekmez. Açık bir kural, çoğu yerde daha anlaşılır bir çözüm olabilir.
Otomasyon öncesi incelemenin sonunda elinizde büyük bir sunum olması şart değil. Ekibin aynı anladığı bir akış, belirlenmiş sorumlular ve ölçülebilir bir deneme planı yeterli bir başlangıçtır.
İlgili okuma
Yapay zekâ içeren akışlarda görev ve risk kapsamını düşünmek için NIST AI Risk Management Framework incelenebilir. Bu yazıdaki süreç inceleme sırası ve süre örneği, uygulama önerisi olarak hazırlanmıştır.