Bagaimana cara mengekstrak aturan bisnis dari sistem lama saya dengan AI?

Anda mengekstrak aturan bisnis dari sistem lama dalam 3 langkah: AI membaca kode dan menuliskan setiap aturan sebagai kalimat jelas yang terhubung ke baris asalnya; pemilik proses meninjaunya lalu mengonfirmasi atau mengoreksinya; dan Anda membandingkannya dengan apa yang benar-benar dilakukan sistem pada faktur nyata. Alat seperti AWS Transform untuk mainframe menuliskan aturan sebagai kebutuhan yang bisa ditinjau, dan dalam pengumuman Thought Machine bersama Amazon pada 29 September 2026, ekstraksi melewati 4 tahap yang diakhiri dengan persetujuan manusia. Jangan menulis kode baru sebelum aturannya dikonfirmasi.

Di bagian 3 Anda sudah memiliki inventaris dan keputusan sementara untuk setiap sistem. Sistem yang Anda putuskan untuk dibangun ulang atau dikonversi adalah yang paling dulu membutuhkan langkah ini.

Mengapa aturan bisnis adalah bagian paling berharga dari sistem lama Anda

Aturan bisnis adalah cara perusahaan Anda menghitung atau memutuskan sesuatu: bagaimana diskon pelanggan grosir dihitung, kapan denda keterlambatan ditambahkan, siapa yang menyetujui pesanan pembelian di atas batas tertentu, bagaimana jumlah cicilan dibulatkan. Aturan-aturan ini menumpuk selama bertahun-tahun perubahan, dan banyak di antaranya tidak pernah ditulis di dokumen mana pun.

• Di dalam kode: syarat dan perhitungan yang ditulis programmer bertahun-tahun lalu atas permintaan seorang manajer yang sudah tidak lagi di perusahaan.
• Di dalam basis data: tabel harga, tarif, dan batas yang diubah seseorang secara manual tanpa tahu apa yang bergantung padanya.
• Di kepala karyawan: pengecualian yang ditangani akuntan secara manual karena sistem tidak menanganinya.
• Di spreadsheet: rumus yang menutup kekurangan sistem, seperti yang kami jelaskan dalam lembar mana yang sebenarnya sistem Anda.

Jika Anda membangun ulang sistem tanpa aturan-aturan ini, Anda akan membangun sistem baru yang menghitung dengan cara berbeda, dan Anda baru tahu ketika pelanggan mempersoalkan sebuah faktur. Yang harus dipindahkan adalah aturannya; bahasa pemrograman lama hanyalah wadahnya.

Cara AI membaca kode dan menuliskan aturan

Mengekstrak aturan dulu adalah pekerjaan manual yang panjang: seorang programmer membaca kode baris demi baris dan mencatat apa yang ia pahami. Alat masa kini membaca seluruh kode, menelusuri dari mana setiap angka berasal dan ke mana perginya, lalu menuliskan temuannya dalam bahasa yang mudah dipahami. Satu contoh: Amazon menyatakan di halaman AWS Transform untuk mainframe bahwa layanan ini mengekstrak setiap aturan bisnis dari kode sumber dan menelusurinya ke asalnya, lalu menghasilkan kebutuhan siap pengembangan yang bisa ditinjau tim Anda, masing-masing dapat ditelusuri kembali ke kode asalnya. Itu deskripsi Amazon tentang layanannya, bukan hasil yang dijamin.

Format penulisan aturan itu penting. Salah satu format yang dikenal adalah EARS, Easy Approach to Requirements Syntax, yang dikembangkan oleh Alistair Mavin dan rekan-rekannya di Rolls-Royce dan pertama kali diterbitkan pada 2009. Idenya, setiap aturan ditulis dalam urutan tetap: keadaan, lalu pemicu, lalu apa yang harus dilakukan sistem. Format ini memiliki 5 pola dasar; berikut contoh ilustrasi dari dunia bisnis:

Nilai format ini adalah pemilik proses dapat membaca dan menilainya tanpa perlu bisa memprogram. Satu kalimat per aturan, dan ia menjawab ya, tidak, atau belum lengkap.

Contoh dari perbankan: maksud bisnis, bukan terjemahan baris demi baris

Contoh terbaru yang paling jelas datang dari perbankan, tempat aturan bunga, biaya, dan pelunasan telah hidup selama puluhan tahun dalam kode COBOL di mainframe. COBOL adalah bahasa pemrograman lama yang masih menjalankan banyak sistem di perbankan dan asuransi. Dalam pengumuman 29 September 2026, Thought Machine, sebuah perusahaan teknologi perbankan, menyatakan bekerja sama dengan Amazon pada alur yang tidak menerjemahkan kode baris demi baris, tetapi mengekstrak maksud bisnis yang murni. Menurut pengumuman itu, alurnya terdiri atas 4 tahap:

1. Ekstraksi: AWS Transform membaca aplikasi lama dan mengekstrak logika bisnis ke dalam spesifikasi yang ditulis dalam format EARS.
2. Konsolidasi: ratusan variasi berulang dari produk yang sama digabung menjadi spesifikasi modern yang ringkas.
3. Sintesis: agen AI menghasilkan produk keuangan beserta pengujiannya dalam Python.
4. Validasi: peninjauan manusia, tempat tim rekayasa dan tim risiko bank memegang wewenang persetujuan yang tegas.

Perhatikan dua pelajarannya: tahap konsolidasi menunjukkan bahwa sistem lama membawa banyak salinan dari aturan yang sama, dan tahap terakhir sepenuhnya dilakukan manusia. Ini adalah klaim kedua perusahaan tentang alur mereka, dan contohnya adalah bank, tetapi metodenya berlaku untuk perusahaan mana pun: ekstrak, gabungkan duplikat, lalu bangun, dan jangan menyetujui apa pun sebelum pemilik keputusan menandatanganinya.

Mengapa pemilik proses harus mengonfirmasi setiap aturan

AI membaca apa yang dilakukan kode, bukan apa yang diinginkan perusahaan. Celah di antara keduanya adalah tempat kesalahan modernisasi terjadi:

• Kode mati: AI bisa mengekstrak aturan dari bagian yang sudah bertahun-tahun tidak dipakai, sehingga tampak seperti aturan yang masih berlaku.
• Bug lama yang menjadi kebiasaan: sistem membulatkan jumlah dengan cara yang salah dan staf memperbaikinya secara manual. Aturan hasil ekstraksi akan ikut membawa bug itu kecuali ada yang menyatakan bahwa itu bug.
• Aturan di luar kode: pengecualian yang ditangani akuntan secara manual tidak akan pernah muncul dalam hasil ekstraksi.
• Aturan yang bertentangan: dua versi perhitungan diskon di dua tempat berbeda. Mana yang benar adalah keputusan bisnis, bukan keputusan teknis.

Karena itu, tetapkan bagi setiap aturan seorang pemilik dari sisi bisnis yang menandatanganinya: manajer penjualan untuk aturan diskon, manajer keuangan untuk denda dan persetujuan. Aturan yang sudah dikonfirmasi menjadi dasar dokumen kebutuhan sistem baru, dan cara menulisnya kami jelaskan dalam panduan kami untuk menulis kebutuhan perangkat lunak. Ingat bahwa kode dan basis data bisa berisi data pelanggan atau karyawan, sehingga setiap alat yang membacanya di luar Kerajaan memerlukan peninjauan yang kami bahas di bagian 3, bersama panduan Otoritas Data dan Kecerdasan Buatan Saudi (SDAIA).

Pandangan Origami

Saat memodernisasi sistem lama, kami memperlakukan aturan bisnisnya sebagai hal terpenting untuk dipindahkan, bukan kodenya. Kami memakai alat AI untuk membaca kode dan menuliskan aturan sebagai kalimat jelas dengan kecepatan yang dulu tidak mungkin, tetapi kami tidak menganggap satu aturan pun final sebelum pemilik proses membaca dan menandatanganinya.

Kemudian kami menguji setiap aturan yang sudah dikonfirmasi dengan data nyata dari sistem lama sebelum membangun sistem baru di sekitarnya, agar sistem baru menghitung sesuai harapan perusahaan, bukan sesuai tebakan alat. Jika Anda ingin melihat cara kami bekerja, lihat layanan kami.

Latihan minggu ini: satu aturan, tiga faktur

Anda tidak perlu menunggu alat untuk memulai. Pilih satu aturan yang sering diperdebatkan, seperti diskon atau denda keterlambatan, lalu ikuti langkah-langkah berikut:

1. Minta pemilik proses menuliskan aturan itu dalam satu kalimat, dengan bentuk: Ketika..., sistem harus...
2. Ambil 3 faktur nyata dari sistem yang terkena aturan itu: satu yang biasa, satu di batas, dan satu dengan pengecualian.
3. Hitung setiap faktur secara manual dengan kalimat yang sudah ditulis, lalu bandingkan hasilnya dengan keluaran sistem.

Jika ketiganya cocok, aturan itu sudah terdokumentasi. Jika satu berbeda, Anda telah menemukan aturan tersembunyi atau bug lama, dan itulah yang perlu Anda ketahui sebelum modernisasi apa pun.

Di bagian berikutnya

Kini Anda memiliki aturan yang sudah dikonfirmasi untuk sistem Anda. Selanjutnya datang keputusan besar: memindahkan sistem apa adanya, mengonversi kodenya ke platform modern, membangunnya ulang di sekitar aturan yang telah diekstrak, atau menggantinya dengan produk jadi dan hanya menyimpan datanya? Di bagian 5 kami membandingkan jalur-jalur ini dalam sebuah tabel: kapan masing-masing cocok, apa yang dipertahankan, apa risikonya, dan siapa yang harus dilibatkan.

Sumber

• AWS Transform untuk mainframe: halaman resmi — ekstraksi aturan bisnis yang tertelusur ke kode asli, kebutuhan yang bisa ditinjau, dan uji kesetaraan.
• Thought Machine dan AWS: pengumuman 29 September 2026 — empat tahap: ekstraksi EARS, konsolidasi, sintesis, dan validasi manusia.
• EARS: panduan resmi Alistair Mavin — formatnya, lima polanya, dan terbitan pertamanya pada 2009.
• SDAIA: pelindungan data pribadi.