Bagaimanakah saya mengekstrak peraturan perniagaan daripada sistem lama saya dengan AI?

Anda mengekstrak peraturan perniagaan daripada sistem lama anda dalam 3 langkah: AI membaca kod dan menulis setiap peraturan sebagai ayat yang jelas yang dipautkan kepada baris asalnya; pemilik proses menyemaknya lalu mengesahkan atau membetulkannya; dan anda membandingkannya dengan apa yang sebenarnya dilakukan sistem pada invois sebenar. Alat seperti AWS Transform untuk kerangka utama menulis peraturan sebagai keperluan yang boleh disemak, dan dalam pengumuman Thought Machine bersama Amazon pada 29 September 2026, pengekstrakan melalui 4 peringkat yang berakhir dengan kelulusan manusia. Jangan tulis kod baharu sebelum peraturan disahkan.

Dalam bahagian 3 anda telah menghasilkan inventori dan keputusan sementara bagi setiap sistem. Sistem yang anda putuskan untuk dibina semula atau ditukar ialah sistem yang paling awal memerlukan langkah ini.

Mengapa peraturan perniagaan ialah bahagian paling berharga dalam sistem lama anda

Peraturan perniagaan ialah cara syarikat anda mengira atau memutuskan sesuatu: bagaimana diskaun pelanggan borong dikira, bila caj lewat bayar ditambah, siapa yang meluluskan pesanan belian melebihi had tertentu, bagaimana jumlah ansuran dibundarkan. Peraturan ini terkumpul sepanjang bertahun-tahun perubahan, dan banyak daripadanya tidak pernah ditulis dalam mana-mana dokumen.

• Dalam kod: syarat dan pengiraan yang ditulis oleh seorang pengaturcara bertahun-tahun lalu atas permintaan pengurus yang sudah meninggalkan syarikat.
• Dalam pangkalan data: jadual harga, kadar dan had yang diubah secara manual oleh seseorang tanpa mengetahui apa yang bergantung padanya.
• Dalam kepala pekerja: pengecualian yang dikendalikan oleh akauntan secara manual kerana sistem tidak mengendalikannya.
• Dalam hamparan: formula yang menampung kekurangan sistem, seperti yang kami terangkan dalam helaian mana yang sebenarnya sistem anda.

Jika anda membina semula sistem tanpa peraturan ini, anda akan membina sistem baharu yang mengira secara berbeza, dan anda hanya akan sedar apabila pelanggan mempertikaikan invois. Yang mesti dipindahkan ialah peraturannya; bahasa pengaturcaraan lama hanyalah bekasnya.

Cara AI membaca kod dan menulis peraturan

Mengekstrak peraturan dahulunya kerja manual yang panjang: seorang pengaturcara membaca kod baris demi baris dan mencatat apa yang difahaminya. Alat hari ini membaca keseluruhan kod, menjejak dari mana setiap angka datang dan ke mana ia pergi, kemudian menulis dapatannya dalam bahasa yang mudah difahami. Satu contoh: Amazon menyatakan di halaman AWS Transform untuk kerangka utama bahawa perkhidmatan ini mengekstrak setiap peraturan perniagaan daripada kod sumber dan menjejakinya ke asalnya, kemudian menjana keperluan sedia pembangunan yang boleh disemak oleh pasukan anda, setiap satunya boleh dijejak kembali ke kod asalnya. Itu penerangan Amazon tentang perkhidmatannya sendiri, bukan hasil yang dijamin.

Format penulisan peraturan itu penting. Salah satu format yang terkenal ialah EARS, Easy Approach to Requirements Syntax, yang dibangunkan oleh Alistair Mavin dan rakan sekerjanya di Rolls-Royce dan mula diterbitkan pada 2009. Ideanya ialah setiap peraturan ditulis dalam susunan tetap: keadaan, kemudian pencetus, kemudian apa yang mesti dilakukan sistem. Ia mempunyai 5 corak asas; berikut ialah contoh ilustrasi daripada dunia perniagaan:

Nilai format ini ialah pemilik proses boleh membaca dan menilainya tanpa perlu tahu mengaturcara. Satu ayat bagi setiap peraturan, dan dia menjawab ya, tidak atau tidak lengkap.

Contoh daripada perbankan: niat perniagaan, bukan terjemahan baris demi baris

Contoh terkini yang paling jelas datang daripada perbankan, di mana peraturan faedah, yuran dan pembayaran balik telah wujud berdekad-dekad dalam kod COBOL pada kerangka utama. COBOL ialah bahasa pengaturcaraan lama yang masih menjalankan banyak sistem dalam perbankan dan insurans. Dalam pengumuman 29 September 2026, Thought Machine, sebuah syarikat teknologi perbankan, menyatakan bahawa ia bekerjasama dengan Amazon dalam satu aliran yang tidak menterjemah kod baris demi baris, sebaliknya mengekstrak niat perniagaan yang tulen. Menurut pengumuman itu, aliran tersebut melalui 4 peringkat:

1. Pengekstrakan: AWS Transform membaca aplikasi warisan dan mengekstrak logik perniagaan ke dalam spesifikasi yang ditulis dalam format EARS.
2. Penyatuan: ratusan variasi berulang bagi produk yang sama digabungkan menjadi spesifikasi moden yang ringkas.
3. Sintesis: ejen AI menjana produk kewangan dan ujiannya dalam Python.
4. Pengesahan: semakan manusia, di mana pasukan kejuruteraan dan pasukan risiko bank memegang kuasa kelulusan yang jelas.

Perhatikan dua pengajarannya: peringkat penyatuan menunjukkan bahawa sistem lama membawa banyak salinan peraturan yang sama, dan peringkat terakhir sepenuhnya dilakukan oleh manusia. Ini ialah dakwaan kedua-dua syarikat tentang aliran mereka, dan contoh mereka ialah bank, tetapi kaedahnya sesuai untuk mana-mana syarikat: ekstrak, gabungkan pendua, kemudian bina, dan jangan luluskan apa-apa sebelum pemilik keputusan menandatanganinya.

Mengapa pemilik proses mesti mengesahkan setiap peraturan

AI membaca apa yang dilakukan kod, bukan apa yang dikehendaki syarikat. Jurang antara keduanya ialah tempat berlakunya kesilapan pemodenan:

• Kod mati: ia mungkin mengekstrak peraturan daripada bahagian yang sudah bertahun-tahun tidak digunakan, sehingga kelihatan seperti peraturan yang masih aktif.
• Pepijat lama yang menjadi kebiasaan: sistem membundarkan jumlah dengan cara yang salah dan kakitangan membetulkannya secara manual. Peraturan yang diekstrak akan membawa pepijat itu bersama melainkan ada yang mengatakan ia pepijat.
• Peraturan di luar kod: pengecualian yang dikendalikan oleh akauntan secara manual tidak akan muncul dalam hasil pengekstrakan.
• Peraturan yang bercanggah: dua versi pengiraan diskaun di dua tempat berbeza. Yang mana betul ialah keputusan perniagaan, bukan keputusan teknikal.

Oleh itu, berikan setiap peraturan seorang pemilik dari pihak perniagaan yang menandatanganinya: pengurus jualan untuk peraturan diskaun, pengurus kewangan untuk caj lewat bayar dan kelulusan. Peraturan yang disahkan menjadi asas dokumen keperluan sistem baharu, dan cara menulisnya kami terangkan dalam panduan kami untuk menulis keperluan perisian. Ingat bahawa kod dan pangkalan data mungkin mengandungi data pelanggan atau pekerja, jadi sebarang alat yang membacanya di luar Kerajaan Arab Saudi memerlukan semakan yang kami bincangkan dalam bahagian 3, bersama garis panduan Pihak Berkuasa Data dan Kecerdasan Buatan Saudi (SDAIA).

Pandangan Origami

Apabila kami memodenkan sistem lama, kami menganggap peraturan perniagaannya sebagai perkara paling penting untuk dipindahkan, bukan kodnya. Kami menggunakan alat AI untuk membaca kod dan menulis peraturan sebagai ayat yang jelas pada kelajuan yang dahulunya mustahil, tetapi kami tidak menganggap satu peraturan pun muktamad sebelum pemilik proses membacanya dan menandatanganinya.

Kemudian kami menguji setiap peraturan yang disahkan dengan data sebenar daripada sistem lama sebelum membina sistem baharu di sekelilingnya, supaya sistem baharu mengira seperti yang dijangka syarikat, bukan seperti yang diteka oleh alat. Jika anda ingin melihat cara kami bekerja, lihat perkhidmatan kami.

Latihan minggu ini: satu peraturan, tiga invois

Anda tidak perlu menunggu alat untuk bermula. Pilih satu peraturan yang kerap dipertikaikan, seperti diskaun atau caj lewat bayar, dan ikuti langkah-langkah ini:

1. Minta pemilik proses menulis peraturan itu dalam satu ayat, dalam bentuk: Apabila..., sistem mesti...
2. Tarik 3 invois sebenar daripada sistem yang dikenakan peraturan itu: satu biasa, satu di had dan satu dengan pengecualian.
3. Kira setiap invois secara manual menggunakan ayat yang ditulis, dan bandingkan hasilnya dengan keluaran sistem.

Jika ketiga-tiganya sepadan, peraturan itu telah didokumenkan. Jika satu berbeza, anda telah menemui peraturan tersembunyi atau pepijat lama, dan itulah yang perlu anda ketahui sebelum sebarang pemodenan.

Dalam bahagian seterusnya

Kini anda mempunyai peraturan yang disahkan untuk sistem anda. Seterusnya tiba keputusan besar: adakah anda memindahkan sistem seadanya, menukar kodnya ke platform moden, membinanya semula di sekeliling peraturan yang diekstrak, atau menggantikannya dengan produk siap dan menyimpan data sahaja? Dalam bahagian 5 kami membandingkan laluan-laluan ini dalam satu jadual: bila setiap satu sesuai, apa yang dikekalkan, apa risikonya dan siapa yang perlu terlibat.

Sumber

• AWS Transform untuk kerangka utama: halaman rasmi — pengekstrakan peraturan perniagaan yang dijejak ke kod asal, keperluan yang boleh disemak dan ujian kesetaraan.
• Thought Machine dan AWS: pengumuman 29 September 2026 — empat peringkat: pengekstrakan EARS, penyatuan, sintesis dan pengesahan manusia.
• EARS: panduan rasmi Alistair Mavin — format, lima coraknya dan penerbitan pertamanya pada 2009.
• SDAIA: perlindungan data peribadi.