Otomasyon Projesine Nasıl Başlanır? Dört Adımlık Yöntem

Araçtan değil problemden başlarım. İlk yapılan iş kod yazmak değil, iki şeyi ölçmektir:

• Hangi iş, ne sıklıkla tekrarlanıyor?
• Mevcut süreçte zaman tam olarak nerede kayboluyor?

Bu iki soru kulağa basit gelir ama cevapları çoğu zaman sürprizlidir. Bir ekip "modelleme çok uzun sürüyor" der; ölçtüğünüzde asıl kaybın modellemede değil, teknik resim çıktılarının elle düzenlenmesinde olduğu görülür. Yanlış yeri otomatikleştiren bir proje, teknik olarak kusursuz çalışsa bile hissedilir bir kazanç üretmez.

İki haftalık ölçüm nasıl tutulur

Ölçüm karmaşık olmak zorunda değil. Bir tablo, üç sütun ve iki hafta yeter:

Önemli olan hassasiyet değil, doğru kalemi bulmak. Dakikayı yuvarlamanız sonucu değiştirmez; yanlış işi seçmeniz her şeyi değiştirir.

Otomasyonun getirisi, kazanılan süre çarpı tekrar sayısıdır. Tekrar sayısı düşük bir işi mükemmel otomatikleştirmek, yüksek tekrarlı bir işi kabaca otomatikleştirmekten daha az değer üretir.

Ölçümü bozan üç alışkanlık

Hafızadan tahmin etmek. "Herhalde günde bir saat gidiyor" cümlesi ölçüm değildir. Kayıt tutulduğunda çoğu tahminin iki katı ya da yarısı çıkar.

En kötü günü örneklemek. İnsanlar en can sıkıcı işi hatırlar, en çok zaman alanı değil. İki hafta boyunca sıradan günleri kaydetmek bu sapmayı düzeltir.

Sadece "yapma" süresini saymak. İşin başlamasını bekleyen süre — dosyayı bulmak, doğru revizyonu teyit etmek, birinden bilgi beklemek — çoğu zaman asıl işten uzundur. Otomasyon bu bekleme süresine dokunmuyorsa, kazanç kâğıt üstünde kalır.

İkinci adım, birinci adımdan çıkan listeye bakıp şu ayrımı açıkça yapmaktır: neyin yazılıma, neyin insana kalacağı.

Bu adım atlanırsa proje şu iki şekilden biriyle bozulur:

1. Kapsam sürekli büyür. Her istisna yazılıma eklenir, sistem kural yığınına döner ve bakımı imkânsızlaşır.
2. Kimse güvenmez. Nerede devreye girip nerede çıkacağı belirsiz olan bir otomasyonun çıktısı, kullanıcı tarafından her seferinde baştan kontrol edilir — yani kazanılan süre geri verilir.

Sınırı çizerken işe yarayan pratik bir ayrım şudur: kural haline getirilebilen iş yazılıma, yargı gerektiren iş insana. Bir profilin uzunluğunu parametreden hesaplamak kuraldır. Müşteri özel bir talep gönderdiğinde bunun standart üretim akışına uyup uymadığına karar vermek yargıdır.

Sınırı yazıya dökmek

Sınırın nerede olduğu kadar, nerede olduğunun yazılı olması da önemlidir. Tek sayfalık bir belge yeter; içinde şu dört başlık bulunsun:

• Otomasyon şunu yapar: girdi listesi ve üretilen çıktı listesi, tek tek sayılmış.
• Otomasyon şunu yapmaz: özellikle sık istenecek ama kapsam dışı bırakılan işler.
• Şu durumda durur ve insana devreder: eksik parametre, aralık dışı ölçü, tanınmayan ürün ailesi.
• Bu belgeyi kim değiştirebilir: kapsamı büyütme kararının sahibi.

Sonradan gelen her istisna talebi bu belgeye karşı değerlendirilir. Belge yoksa, her talep haklı görünür ve kapsam sessizce büyür.

İstisnayı kural yapmayın

Sahada en sık gördüğüm bozulma şu: bir müşteri için yapılan tek seferlik istisna, kural motoruna if olarak giriyor. Altı ay sonra kural motorunda yirmi tane böyle if oluyor ve hiçbiri neden orada olduğunu söylemiyor.

Pratik önlem: istisnaları koda değil veriye koyun. Ürün ailesine bağlı bir yapılandırma tablosu, aynı işi yapar ama okunabilir kalır ve kaldırılması kolaydır.

Üçüncü adımda kod yazmaya başlanır — ama tamamı değil. Küçük ve sonucu ölçülebilir bir parça seçilir.

Pilotun iyi seçilmiş olduğunun ölçütü şudur: bittiğinde, işe yarayıp yaramadığı tartışmaya açık olmamalı. "Daha iyi hissettiriyor" bir sonuç değildir. "Aynı çerçevenin hazırlanması 40 dakikadan 6 dakikaya indi" bir sonuçtur.

Pilot ayrıca bir şeyi daha yapar: varsayımları erken kırar. Otomasyon projelerinde en pahalı hatalar, altı ay kod yazdıktan sonra üretim verisinin sandığınız formatta olmadığını fark etmektir. Küçük bir pilot bunu ikinci haftada gösterir.

İyi pilotun beş özelliği

1. Uçtan uca, ama dar. Tek ürün varyantı için parametre girişinden üretim çıktısına kadar tüm zincir. Zincirin yalnızca ortasını otomatikleştiren pilot, gerçek darboğazları göstermez.
2. Gerçek veriyle. Temizlenmiş örnek dosyayla değil, sahadan gelen dosyayla. Kirli veri, pilotun asıl sınavıdır.
3. Tek bir kullanıcıyla. Beş kişiye aynı anda vermek geri bildirimi bulanıklaştırır.
4. Süresi belli. Dört-altı hafta. Bitiş tarihi olmayan pilot, pilot değil, süresiz bir projedir.
5. Başarı ölçütü önceden yazılı. "Hazırlık süresi %40 azalırsa devam" gibi. Sonradan konan ölçüt, her sonucu başarı gösterir.

Pilot bittiğinde sorulacak tek soru

"Çalıştı mı?" değil, şu: aynı işi otomasyon olmadan yapan kişi, otomasyona geri dönmek ister mi? Cevap "hayır"sa, kazanç sayısı ne gösterirse göstersin bir yerde yanlış vardır — genellikle doğrulama yükü hafife alınmıştır.

Son adım, kapsamı genişletmektir — ama kanıtla, tahminle değil.

Pilot sahada çalıştığını gösterdikçe bir sonraki varyant, bir sonraki ürün ailesi, bir sonraki çıktı tipi eklenir. Her genişleme öncesinde aynı soru sorulur: bu ekleme, birinci adımda ölçtüğümüz kayıp kalemlerinden hangisine karşılık geliyor?

Bu disiplin olmadan otomasyon projeleri, kimsenin kullanmadığı özelliklerle şişer. Kullanılmayan her özellik yalnızca boşa harcanmış zaman değildir; bakım yükü olarak kalıcı bir maliyet üretir.

Büyüme sırasını belirleyen basit puanlama

Genişleme adaylarını sıralamak için kullandığım üç çarpanlı puan:

Üç sayının çarpımı, hangi işin sırada olduğunu şaşırtıcı derecede iyi gösteriyor. Özellikle üçüncü çarpan önemli: kuralı henüz oturmamış bir işi otomatikleştirmek, hareketli bir hedefi sabitlemeye çalışmaktır.

Bir yöntemi anlatırken neyi kapsamadığını söylemek, kapsadığını söylemek kadar önemli.

• Yargı gerektiren kararlar. Yapay zeka araçlarını hız ve iterasyon için kullanırım; mimari kararlar, doğrulama ve test yükü bende kalır. Bu ayrımın kod tarafındaki karşılığını yapay zeka ile SolidWorks eklentisi yazmak yazısında ayrıntılandırdım.
• Az tekrarlanan işler. Ayda bir yapılan bir işi otomatikleştirmek, çoğu zaman elle yapmaktan pahalıdır.
• Henüz oturmamış süreçler. Sürekli değişen bir iş akışını otomatikleştirmek, hareketli bir hedefi sabitlemeye çalışmaktır. Önce süreç oturur, sonra otomatikleştirilir.
• Doğrulaması olmayan çıktılar. Üretime giden bir çıktının doğruluğunu kontrol edecek deterministik bir kural yoksa, o adım otomatikleştirilmez.

Ölçüm ve sınır belliyse araç kararı mekanik hale gelir. Kaba eşikler:

Bu üç yolun teknik farkını makro, API ve add-in arasındaki fark yazısında; Python tarafının nerede bitip C# tarafının nerede başladığını Python ile SolidWorks otomasyonu yazısında ayrıntılı anlattım.

Otomasyon projesine başlamak için kaç kişilik ekip gerekir? Pilot aşaması için tek bir geliştirici ve tek bir kullanıcı yeterlidir. Ekip büyüklüğü, kapsam sahada kanıtlandıktan sonra artırılmalıdır; başta kalabalık bir ekip, ölçülmemiş varsayımların üzerine paralel iş yığar.

Bir işin otomatikleştirilmeye değip değmediğine nasıl karar verilir? Kazanılan süreyi tekrar sayısıyla çarpın ve bakım yükünü düşün. Aylık toplam kazanç, otomasyonun geliştirme ve bakım süresini makul bir sürede (tipik olarak altı ay) karşılamıyorsa o iş elle kalır. Ölçüm yönteminin ayrıntısını otomasyon kazancını ölçmek yazısında anlattım.

Pilot projenin süresi ne kadar olmalı? Dört ile altı hafta. Daha kısası varsayımları kırmaya yetmez, daha uzunu pilot olmaktan çıkıp süresiz projeye döner. Bitiş tarihi ve başarı ölçütü baştan yazılı olmalıdır.

Otomasyon projesinde en sık yapılan hata nedir? Ölçüm yapmadan araç seçmek. İkinci sırada, otomasyonun sınırını yazıya dökmemek geliyor: sınır yazılı değilse her istisna talebi haklı görünür ve kapsam sessizce büyür.

CAD otomasyonu için hangi dili seçmeliyim? Keşif ve fikir doğrulama için Python, üretime giden kalıcı akışlar için C# / .NET. Tek seferlik küçük işlerde VBA makrosu hâlâ en hızlı yoldur. Karar, işin kim tarafından sürdürüleceğine ve ne kadar yaşayacağına göre verilir.

Otomasyonun başarısını hangi metriklerle takip etmeliyim? Dört kalem yeterlidir: hazırlık süresi, düzeltme oranı, ilk seferde doğru çıktı yüzdesi ve üretime kaçan hata sayısı. Yalnızca üretim süresini ölçmek, kazancı olduğundan büyük gösterir.

Otomasyon projesinin başarısı, ilk gün seçilen kütüphaneyle değil, ilk hafta sorulan sorularla belirlenir:

Araç seçimi bu dört sorunun cevabından sonra gelir — ve genellikle o noktada zaten belli olmuştur.