Yapay zeka projeleri pilot aşamasında neden kalıyor?
Yazar Can KuşaklıYayın tarihi
Bir şirket yapay zeka projesine başlar. Bir tedarikçi seçilir, bir pilot tanımlanır, üç ay çalışılır. Pilot başarılı olur. Sunum yapılır, yönetim memnun kalır.
Sonra hiçbir şey olmaz.
Altı ay sonra o çözüm ya hiç kullanılmamaktadır, ya da depoda bir bilgisayarda açılmayan bir sekme olarak durmaktadır. Proje resmî olarak "başarılı" sayılır ama kimse bir daha konusunu açmaz.
Bu tablo istisna değil, kural. Ve sebebi çoğu zaman sanıldığı gibi teknoloji değil.
Yapay zeka projeleri pilot aşamasında neden kalıyor?
Kurumsal yapay zeka projelerinin çoğu aynı duvara çarpıyor: yapay zekayı bilen ERP'yi bilmiyor, ERP'yi bilen yapay zekayı bilmiyor.
Bu cümle kulağa fazla basit geliyor olabilir. Somutlaştıralım.
Yapay zeka tarafındaki ekip - ister bir startup, ister bir danışmanlık firması, ister şirketin kendi veri bilimi ekibi - modeli kurmayı biliyor. Neyin mümkün olduğunu, hangi verinin ne işe yarayacağını, çözümün nasıl ölçüleceğini biliyor. Bilmediği şey, o şirketin sipariş sürecinin neden böyle şekillendiği. Neden iki ayrı ürün kodunun var olduğunu, neden bir onay adımının atlanamayacağını, neden depodaki kişinin sabah altıda o ekrana bakacak vakti olmadığını bilmiyor.
ERP tarafındaki ekip bunların hepsini biliyor. Sistemin neresinde ne olduğunu, hangi alanın gerçekte ne için kullanıldığını, hangi raporun neden yanlış çıktığını biliyor. Bilmediği şey, bugün teknik olarak neyin mümkün olduğu. Elindeki problemin çözülebilir bir problem olduğunu çoğu zaman fark etmiyor bile.
İki taraf da işini iyi yapıyor. Sorun, aradaki çeviriyi kimsenin yapmaması.
Pilot aşamasında bu boşluk görünmez, çünkü pilotlar kontrollü ortamlarda, seçilmiş veriyle, hevesli bir ekiple yürür. Boşluk üretime geçerken ortaya çıkar - gerçek veriyle, gerçek yetki kısıtlarıyla ve o işi zaten bir şekilde yapmakta olan gerçek insanlarla karşılaşınca.
Eksik olan, bu çeviriyi yapan katmandır. Otomasyon katmanı, mevcut iş sisteminin - SAP olsun, Microsoft altyapısı olsun - üstünde duran ve bir insanın elle yaptığı tekrarlı işi, sisteme dokunmadan ve aynı yetkilerle yürüten yazılım katmanıdır.
Geride mi kaldınız, yoksa katmanı yazan mı çıkmadı?
Bu konuyu konuştuğumuz ekiplerin çoğu, konuşmaya bir özürle başlıyor. "Biz bu konuda biraz geridiz" ya da "bizde işler hâlâ çok manuel" gibi.
Bu teşhis yanlış, ve yanlış olduğu için de zarar veriyor.
Geride kalmış değilsiniz. Sistem sizde. Veri sizde. Süreci bilen insanlar sizde. Eksik olan tek şey, elinizdekiyle yapılabilecekleri yazacak birinin bugüne kadar o pozisyonda durmamış olması.
Bu ayrım önemli, çünkü "geride kaldık" teşhisi şirketleri yanlış çözüme itiyor: büyük, kapsamlı, pahalı dönüşüm projelerine. Oysa gerçek teşhis - "aradaki katmanı kimse yazmadı" - çok daha küçük ve çok daha hızlı bir çözüme işaret ediyor.
Pilotta kalan, boşlukta duran süreçler neye benziyor?
Akyalabs'ın çalıştığı işler tam olarak bu boşlukta duranlar. Ortak özellikleri şunlar:
Otomatikleşemedikleri için değil, kimse yazmadığı için elle yürüyorlar. Teknik bir engel yok. Sadece o işi tanımlayacak, sisteme bağlayacak ve devreye alacak kimse olmamış.
Tek bir kişinin kafasında duruyorlar. Süreci gerçekten bilen bir kişi var ve hiçbir yerde yazılı değil. O kişi izne çıktığında iş duruyor.
Kimse şikayet etmiyor. En belirleyici işaret bu. Herkes o raporun pazartesi sabahı elle çekildiğini biliyor, ama kimse bunu bir problem olarak adlandırmamış. "İş böyle yürüyor" kategorisine girmiş.
Bunlar SAP, Netsis, Canias, yerel bir CRM ya da Microsoft tabanlı bir altyapı üzerinde duruyor olabilir. Sistem markası belirleyici değil - belirleyici olan, sürecin sistemle insan arasındaki boşlukta kalmış olması.
Tipik örnekler: sipariş ve irsaliye eşleştirmesi, cari hesap yaşlandırma takibi, üretim planı revizyon bildirimleri, ay sonu kapanış kontrol listeleri, işe alım sürecindeki aday bilgisi aktarımları. Hiçbiri egzotik değil. Çoğu şirkette en az ikisi var. Somut bir liste için: SAP/Netsis kullanan şirketlerde hâlâ elle yürüyen 5 süreç.
Pilotu aşmak için ne gerekiyor?
Pilotta kalan projelerle üretime geçenler arasındaki fark, üç şeyde toplanıyor:
| Şart | Pilotta kalan proje | Üretime geçen proje |
|---|---|---|
| Büyüklük | "Tüm tedarik zincirini optimize edelim" | Tek bir rapor, tek bir bildirim, tek bir eşleştirme |
| Süreç tanımı | Anlatılanla yetinilir, yazılmaz | Süreç yazıya dökülür, istisnalar çıkarılır |
| İşi yapan kişi | Dışarıda bırakılır | Tasarımın merkezinde yer alır |
Birincisi: doğru büyüklükte başlamak. Pilotlar genelde fazla iddialı seçiliyor. Üretime geçen işler ise genelde utanç verecek kadar küçük başlıyor. Küçük iş üretime geçer, çünkü kimseyi ikna etmeye gerek kalmadan çalışmaya başlar. Marka Araçları bu ölçekte bir örnek: tek bir tekrarı hedefliyor, TÜRKPATENT bülteninin okunmasını ve ePats sorgularının tek tek yapılmasını. Bir ofiste bu sorgu ayda yaklaşık 8 bin kez elle tekrarlanıyordu.
İkincisi: süreci yazıya dökmek. Bir sürecin otomatikleştirilebilmesi için önce tanımlanması gerekiyor, ve bu iş çoğu projede hiç yapılmıyor. Yazıya dökme adımı sıkıcı görünür ama projenin en değerli kısmıdır: o kişiye olan bağımlılığı bitiren tek adım budur. Otomasyon çalışmasa bile bu adımın değeri kalır.
Üçüncüsü: işi yapan kişiyi sürecin içine almak. Raporu bugün elle hazırlayan kişi, o sürecin gerçek uzmanıdır. Projeler o kişiyi dışarıda bırakınca iki şey oluyor: süreçteki istisnalar kaçırılıyor, ve o kişi haklı olarak çözümü sahiplenmiyor. Aynı kişi sürece dahil edildiğinde hem tasarım doğru oluyor hem de devreye alma sorunsuz geçiyor.
Bu üçünün hiçbiri teknoloji sorunu değil. Üçü de yaklaşım sorunu - ve pilotta kalan projelerin çoğu tam da bu yüzden kalıyor.
Kullanılmayan pilotların ortak bir dördüncü sebebi de çıktının yanlış yere konması. Bir üretim tesisinde bakım dokümanları klasörlerde, dosyalarda ve kişilerde dağınıktı. Bakımcı bunları tek bir sohbet asistanında topladı: teknisyen emin olmadığında soruyu yazıyor, cevabı tesisin kendi dokümanlarından alıyor. Asistana her yerden ulaşılıyor, kimsenin bilgi aramak için ofise dönmesi gerekmiyor. Yani çözüm, işin zaten yapıldığı yere gidiyor.
Katmanın teknik olarak nasıl kurulduğunu ayrı bir yazıda anlattık: SAP'ı değiştirmeden raporlamayı nasıl otomatikleştirirsiniz?
Akyalabs pratikte ne yapıyor?
Üç şekilde çalışıyoruz, ve hangisinin doğru olduğu şirkete göre değişiyor.
Uygulama eğitimleri. Ekibinizin bu işi kendi başına yapabilmesi için. Bir araç satın alıp ummak yerine, kendi süreçlerinizi kendi insanlarınızın otomatikleştirebilmesi. Uzun vadede en sağlıklı yol, çünkü katmanı kuran da bakımını yapan da içeride oluyor.
Belirli süreçler üzerinde birebir işbirliği. Somut bir süreç seçilir, birlikte tanımlanır, kurulur ve devreye alınır. Kapsam baştan dar tutulur. Amaç, ilk çalışan şeyi mümkün olan en kısa sürede üretime almak.
Özel ürün geliştirme ortaklıkları. Sadece anlamlı olduğunda. İhtiyaç tekrar eden ve standart çözümlerle karşılanamayan bir şeyse, birlikte geliştirilir.
Üçünün de ortak noktası şu: mevcut sisteminize dokunmuyoruz. ERP'nizi değiştirmiyor, yükseltmiyor, yerine bir şey koymuyoruz.
Nereden başlanır?
Kendi başınıza yapabileceğiniz ilk adım basit: ekibinizde hangi işlerin elle yürüdüğünü bir hafta boyunca not edin. Sonra her biri için tek bir soru sorun - bu işte karar gerektiren bir adım var mı?
Cevabı "hayır" olan her iş, bugün otomatikleşebilir durumda demektir.
Bu listeden birkaç satır çıktıysa, konuşmaya değer. Başlamanın en kolay yolu bir teklif değil, bir sohbet: hangi süreç sizde elle yürüyorsa, birlikte bakalım.
Eksik olan otomasyon katmanı - sistem değil.
Sık sorulan sorular
Pilotumuz teknik olarak başarılıydı ama kullanılmadı. Nerede hata yaptık?
Büyük ihtimalle çözüm, işi bugün yapan kişilerin akışının dışına konmuş. Çıktı kimsenin açmadığı yeni bir panele gidiyorsa doğruluğu ne olursa olsun kullanılmaz. Kural basit: rapor bugün e-posta ile geliyorsa otomatik hali de e-posta ile gelmeli. Yeni bir alışkanlık isteyen her çözüm, o alışkanlığı kazandırma maliyetini de üstlenmek zorundadır.
Yapay zeka projesini kendi ekibimizle mi yapmalıyız, dışarıdan destek mi almalıyız?
İkisi karşıt değil. Uzun vadede en sağlıklısı, katmanı kuranın da bakımını yapanın da içeride olması, çünkü süreçler değişir ve her değişiklikte dışarıya bağımlı olmak işi yavaşlatır. Pratikte işe yarayan model, ilk bir iki süreci birlikte kurmak ve ekibin izleyerek öğrenmesidir. Dışarıdan alınan şey iş gücü değil, aynı hatayı daha önce yapmış olmanın kısayoludur.
Küçük bir şirketiz, yapay zeka otomasyonu bizim için erken mi?
Hayır, belirleyici olan şirket büyüklüğü değil tekrar sayısıdır. Haftada bir tekrar eden manuel bir iş varsa, şirket ne kadar küçük olursa olsun otomasyon anlamlıdır. Küçük şirketlerde etkisi çoğu zaman daha büyük olur, çünkü o işi yapan kişinin zamanı oransal olarak daha değerlidir ve kişiye bağımlılık riski daha yüksektir.
Verimiz dağınık, önce veriyi mi düzeltmeliyiz?
Genelde hayır. 'Önce veriyi düzeltelim' projeleri kendi başlarına yıllar sürer ve çoğu hiç bitmez. Doğru sıra tersidir: tek bir sürece odaklanıp yalnızca o süreç için gereken veriyi düzeltmek. Kapsam bir süreçle sınırlandığında veri temizliği de yönetilebilir bir işe dönüşür ve otomasyon beklemeden başlayabilir.
Yapay zeka pilotunun başarısını nasıl ölçeriz?
Baştan tek bir sayı belirleyin ve otomasyondan önce ölçün. En anlamlısı genelde sürecin talep edildiği andan teslim edildiği ana kadar geçen süredir. Harcanan iş saatinden daha çok şey anlatır, çünkü bekleme sürelerini de kapsar. Pilot sonunda aynı sayıyı yeniden ölçüp kendi önceki-sonraki değerlerinizle kıyaslayın, tedarikçi ortalamalarıyla değil.
İşletmeniz için doğru otomasyonu birlikte belirleyelim
Süreçlerinizi birlikte değerlendirelim ve yapay zekanın size nerede en çok zaman kazandıracağını görelim.
Keşif görüşmesi başlat