Eski sistemimdeki iş kurallarını yapay zekâ ile nasıl çıkarırım?

Eski sisteminizdeki iş kurallarını 3 adımda çıkarırsınız: yapay zekâ kodu okur ve her kuralı geldiği satıra bağlı açık bir cümle olarak yazar; süreç sahibi kuralı inceler, onaylar ya da düzeltir; siz de kuralı sistemin gerçek faturalarda fiilen yaptığıyla karşılaştırırsınız. Ana bilgisayarlar için AWS Transform gibi bir araç kuralları incelenebilir gereksinimler olarak yazar ve Thought Machine'in 29 Eylül 2026 tarihli Amazon duyurusunda çıkarma işlemi insan onayıyla biten 4 aşamadan geçer. Kurallar onaylanmadan yeni kod yazmayın.

3. bölümde her sistem için bir envanter ve geçici bir kararla çıktınız. Yeniden inşa etmeye ya da dönüştürmeye karar verdiğiniz sistemler bu adıma ilk ihtiyaç duyanlardır.

İş kuralları neden eski sisteminizin en değerli parçasıdır

İş kuralı, şirketinizin bir şeyi hesaplama ya da karara bağlama biçimidir: toptan müşterinin indirimi nasıl hesaplanır, gecikme cezası ne zaman eklenir, belli bir limitin üstündeki satın alma siparişini kim onaylar, bir taksit tutarı nasıl yuvarlanır. Bu kurallar yıllar süren değişikliklerle birikmiştir ve birçoğu hiçbir belgeye yazılmamıştır.

• Kodda: bir programcının yıllar önce, artık şirkette olmayan bir yöneticinin isteğiyle yazdığı koşullar ve hesaplamalar.
• Veritabanında: birinin neyin onlara bağlı olduğunu bilmeden elle değiştirdiği fiyat tabloları, oranlar ve limitler.
• Çalışanların kafasında: sistem yapmadığı için muhasebecinin elle çözdüğü istisnalar.
• Elektronik tablolarda: sistemdeki eksikleri kapatan formüller; bunu hangi tablo asıl sistemdir yazısında anlattık.

Sistemi bu kurallar olmadan yeniden kurarsanız, farklı hesaplayan yeni bir sistem kurmuş olursunuz ve bunu ancak bir müşteri faturaya itiraz ettiğinde fark edersiniz. Taşınması gereken kurallardır; eski programlama dili yalnızca bir kaptır.

Yapay zekâ kodu nasıl okur ve kuralları nasıl yazar

Kural çıkarmak uzun bir el işiydi: bir programcı kodu satır satır okur ve anladığını not ederdi. Bugünün araçları kodun tamamını okur, her rakamın nereden gelip nereye gittiğini izler ve bulduklarını anlaşılır bir dille yazar. Bir örnek: Amazon, ana bilgisayarlar için AWS Transform sayfasında hizmetin her iş kuralını kaynak koddan çıkarıp kökenine bağladığını, ardından ekibinizin inceleyebileceği, her biri geldiği koda kadar izlenebilen geliştirmeye hazır gereksinimler ürettiğini söylüyor. Bu, Amazon'un kendi hizmetine dair açıklamasıdır, garanti edilmiş bir sonuç değildir.

Kuralın hangi formatta yazıldığı önemlidir. Bilinen formatlardan biri EARS, yani Easy Approach to Requirements Syntax'tır; Alistair Mavin ve Rolls-Royce'taki meslektaşları tarafından geliştirilmiş ve ilk kez 2009 yılında yayımlanmıştır. Fikir şudur: her kural sabit bir sırayla yazılır; önce durum, sonra tetikleyici, sonra sistemin yapması gereken. 5 temel kalıbı vardır; işte iş dünyasından açıklayıcı örnekler:

Bu formatın değeri, süreç sahibinin programlama bilmeden onu okuyup değerlendirebilmesidir. Her kural için tek cümle; cevabı evet, hayır ya da eksik.

Bankacılıktan bir örnek: satır satır çeviri değil, iş niyeti

En açık güncel örnek, faiz, ücret ve geri ödeme kurallarının onlarca yıldır ana bilgisayarlarda COBOL kodu içinde yaşadığı bankacılıktan geliyor. COBOL, bankacılık ve sigortacılıkta hâlâ birçok sistemi çalıştıran eski bir programlama dilidir. Bir bankacılık teknolojisi şirketi olan Thought Machine, 29 Eylül 2026 tarihli duyurusunda, Amazon ile kodu satır satır çevirmeyen, bunun yerine saf iş niyetini çıkaran bir süreç üzerinde çalıştığını açıkladı. Duyuruya göre süreç 4 aşamadan oluşuyor:

1. Çıkarma: AWS Transform eski uygulamaları okur ve iş mantığını EARS formatında yazılmış şartnamelere çıkarır.
2. Birleştirme: aynı ürünün yüzlerce gereksiz varyasyonu sade ve modern şartnamelerde birleştirilir.
3. Sentez: yapay zekâ ajanları finansal ürünleri ve testlerini Python ile üretir.
4. Doğrulama: bankanın mühendislik ve risk ekiplerinin açık onay yetkisine sahip olduğu insan incelemesi.

İki derse dikkat edin: birleştirme aşaması eski bir sistemin aynı kuralın pek çok kopyasını taşıdığını gösteriyor ve son aşama tamamen insana ait. Bunlar iki şirketin kendi süreçleri hakkındaki iddialarıdır ve örnekleri bir bankadır, ama yöntem her şirkete uyar: çıkar, tekrarları birleştir, sonra inşa et ve karar sahibi imzalamadan hiçbir şeyi onaylama.

Süreç sahibi neden her kuralı onaylamalıdır

Yapay zekâ kodun ne yaptığını okur, şirketin ne istediğini değil. Modernizasyon hataları bu ikisi arasındaki boşlukta ortaya çıkar:

• Ölü kod: yıllardır kullanılmayan bir bölümden kural çıkarıp onu yaşayan bir kural gibi gösterebilir.
• Alışkanlığa dönüşmüş eski bir hata: sistem bir tutarı yanlış yuvarlar ve çalışanlar bunu elle düzeltir. Birisi bunun hata olduğunu söylemedikçe çıkarılan kural hatayı da taşıyacaktır.
• Kodun dışındaki bir kural: muhasebecinin elle çözdüğü istisna çıkarma sonucunda asla görünmez.
• Çelişen kurallar: indirim hesabının iki farklı yerde iki ayrı sürümü. Hangisinin doğru olduğu teknik değil, iş kararıdır.

Bu yüzden her kurala onu imzalayacak bir iş sahibi atayın: indirim kuralları için satış müdürü, gecikme cezaları ve onaylar için finans müdürü. Onaylanan kurallar yeni sistemin gereksinim belgesinin temeli olur; bunun nasıl yazılacağını yazılım gereksinimleri rehberimizde anlattık. Kodun ve veritabanlarının müşteri ya da çalışan verisi içerebileceğini unutmayın; bu yüzden onları Krallık dışında okuyan her araç, 3. bölümde ele aldığımız incelemeyi ve Suudi Veri ve Yapay Zekâ Otoritesi'nin (SDAIA) yönlendirmelerini gerektirir.

Origami'nin bakışı

Eski bir sistemi modernize ettiğimizde, taşınacak en önemli şey olarak kodu değil iş kurallarını görürüz. Kodu okumak ve kuralları daha önce mümkün olmayan bir hızla açık cümleler olarak yazmak için yapay zekâ araçlarını kullanırız, ancak süreç sahibi okuyup imzalamadan hiçbir kuralı kesin saymayız.

Ardından yeni sistemi onun etrafında kurmadan önce, onaylanan her kuralı eski sistemin gerçek verileriyle test ederiz; böylece yeni sistem bir aracın tahmin ettiği gibi değil, şirketin beklediği gibi hesaplar. Nasıl çalıştığımızı görmek isterseniz hizmetlerimize göz atın.

Bu haftanın alıştırması: bir kural, üç fatura

Başlamak için bir araç beklemenize gerek yok. Sık tartışılan bir kural seçin, örneğin bir indirim ya da gecikme cezası, ve şu adımları izleyin:

1. Süreç sahibinden kuralı şu biçimde tek cümleyle yazmasını isteyin: ... olduğunda, sistem ... yapmalıdır.
2. Sistemden kuralın uygulandığı 3 gerçek fatura çekin: biri olağan, biri sınırda, biri istisnalı.
3. Her faturayı yazılı cümleyle elle hesaplayın ve sonucu sistemin ürettiğiyle karşılaştırın.

Üçü de uyuşuyorsa kural belgelenmiştir. Biri farklıysa gizli bir kural ya da eski bir hata bulmuşsunuzdur ve herhangi bir modernizasyondan önce bilmeniz gereken tam olarak budur.

Sonraki bölümde

Artık sisteminiz için onaylanmış kurallarınız var. Sırada büyük karar var: sistemi olduğu gibi mi taşıyacaksınız, kodunu modern bir platforma mı dönüştüreceksiniz, çıkardığınız kuralların etrafında yeniden mi inşa edeceksiniz, yoksa hazır bir ürünle değiştirip yalnızca verileri mi saklayacaksınız? 5. bölümde bu yolları bir tabloda karşılaştırıyoruz: her biri ne zaman uygun, neyi korur, neyi riske atar ve kimlerin katılması gerekir.

Kaynaklar

• Ana bilgisayarlar için AWS Transform: resmî sayfa — özgün koda bağlı iş kuralı çıkarma, incelenebilir gereksinimler ve eşdeğerlik testleri.
• Thought Machine ve AWS: 29 Eylül 2026 duyurusu — dört aşama: EARS ile çıkarma, birleştirme, sentez ve insan doğrulaması.
• EARS: Alistair Mavin'in resmî rehberi — format, beş kalıbı ve 2009 yılındaki ilk yayımı.
• SDAIA: kişisel verilerin korunması.