Semakin banyak proses yang diotomatisasi, semakin sulit menjaga aturan bisnis tetap konsisten.
Finance memiliki threshold sendiri, sales menggunakan kebijakan berbeda, risk team memperbarui rule setiap bulan, sementara developer harus memastikan semua perubahan tidak merusak sistem lain.
Menggunakan Business Rules Engine dapat membantu mengatasi persoalan tersebut dengan menjadikan decision logic sebagai komponen tersendiri. Namun, tantangannya tidak berhenti pada membuat decision table.
Organisasi juga membutuhkan governance, testing, versioning, simulation, monitoring, dan jalur manual untuk kasus yang tidak aman diselesaikan sepenuhnya oleh automation.
Gunakan Rules Engine ketika Decision Logic Mulai Membesar
Tidak semua aplikasi memerlukan rules engine.
Jika hanya terdapat tiga aturan sederhana yang hampir tidak pernah berubah, menambah decision platform justru dapat meningkatkan kompleksitas.
Rules engine mulai menarik ketika terdapat banyak kondisi, kebijakan sering diperbarui, atau keputusan yang sama digunakan oleh beberapa proses.
IBM menjelaskan bahwa business rules dapat digunakan untuk menegakkan policy, membuat decision, atau menghasilkan informasi baru dari data yang tersedia.
Pendekatan tersebut sangat relevan ketika hasil keputusan perlu diubah saat runtime tanpa mengganti hard-coded logic.
Contohnya adalah proses underwriting.
Keputusan dapat mempertimbangkan usia customer, pendapatan, outstanding debt, risk score, histori pembayaran, lokasi, dan jumlah pinjaman.
Jika seluruh kombinasi tersebut dimasukkan ke service utama, business logic mudah berubah menjadi ratusan kondisi bercabang.
Decision engine memindahkan kompleksitas keputusan tersebut ke tempat yang memang dirancang untuk mengelolanya.
Gunakan DMN untuk Menjembatani Business dan IT
Salah satu masalah automation kompleks adalah perbedaan bahasa antara business analyst dan developer.
Business team mengatakan:
“Customer premium dengan risiko rendah boleh mendapat limit lebih tinggi.”
Developer kemudian menerjemahkannya menjadi kode.
Saat kebutuhan berubah, proses terjemahan tersebut terjadi lagi.
DMN atau Decision Model and Notation menyediakan bahasa standar untuk memodelkan keputusan. Camunda menjelaskan bahwa DMN membantu business stakeholder dan IT bekerja dengan decision model yang sama, termasuk decision table dan FEEL expression.
Misalnya business analyst dapat melihat tabel:
| Customer | Risk | Limit |
|---|---|---|
| Premium | Low | Rp500 juta |
| Premium | Medium | Rp250 juta |
| Standard | Low | Rp100 juta |
Developer tidak perlu menafsirkan dokumen policy terpisah secara manual setiap saat.
Model tersebut juga dapat digunakan kembali oleh beberapa workflow.
Kelompokkan Rule Berdasarkan Domain Bisnis
Jangan membuat satu ruleset raksasa untuk seluruh perusahaan.
Pisahkan berdasarkan domain.
Contohnya:
Pricing Rules
Credit Rules
Eligibility Rules
Fraud Rules
Approval Rules
Compliance Rules
Oracle mengelompokkan business rules dan decision tables ke dalam ruleset sehingga aturan dapat diorganisasi berdasarkan kebutuhan tertentu.
Pembagian domain mempermudah ownership.
Pricing team tidak perlu mengubah fraud rules. Risk team tidak perlu mempunyai akses edit terhadap loyalty policy.
Struktur ini juga mengurangi risiko perubahan kecil memiliki efek samping yang tidak terduga.
Hindari rule yang bergantung terlalu banyak pada ruleset lain karena hasilnya bisa menciptakan kompleksistas dependency baru.
Terapkan Versioning pada Setiap Perubahan Rule
Bayangkan customer ditolak pada tanggal 1 Juni.
Pada bulan September customer bertanya:
“Mengapa transaksi saya ditolak saat itu?”
Jika policy sudah berubah tiga kali, tim harus mampu mengetahui rule versi mana yang digunakan pada Juni.
Versioning adalah kebutuhan dasar pada proses kritis.
IBM Decision Center menggunakan decision services, releases, activities, serta branches untuk mengelola perubahan. Decision governance framework juga mendukung pengelolaan perubahan sebelum rule dideploy.
Simpan informasi seperti:
Rule version
Effective date
Author
Approver
Reason for change
Related policy
Jangan hanya overwrite rule lama.
Untuk sektor regulated atau proses finansial, kemampuan merekonstruksi keputusan historis bisa sama pentingnya dengan keputusan hari ini.
Buat Approval Workflow untuk Rule Change
Kemudahan mengubah rule merupakan keuntungan sekaligus risiko.
Kalau business user dapat mengubah threshold produksi tanpa review, automation bisa menghasilkan ribuan keputusan salah sebelum masalah ditemukan.
Gunakan governance.
Contohnya:
Rule Author membuat perubahan.
Risk Manager melakukan review.
Compliance memberikan approval jika terkait regulasi.
Configuration Manager melakukan deployment.
IBM Decision Center menyediakan governance berbasis release dan change activity, sementara akses deployment ke production dapat dibatasi berdasarkan role.
Dengan mekanisme tersebut, business masih memiliki agility tetapi perubahan kritis tetap terkontrol.
Buat pula emergency change procedure untuk situasi tertentu.
Namun emergency tidak boleh menjadi alasan seluruh perubahan melewati jalur informal.
Gunakan Simulation sebelum Mengubah Production
Bayangkan risk team ingin menaikkan threshold approval dari skor 60 menjadi 70.
Apa dampaknya?
Berapa persen transaksi yang sebelumnya lolos sekarang akan masuk manual review?
Daripada menebak, lakukan simulation.
IBM ODM memungkinkan rules dijalankan terhadap data operasional nyata atau data simulasi untuk melihat dampaknya terhadap KPI sebelum deployment. Testing juga membandingkan expected outcome dengan actual result.
Misalnya simulation menunjukkan:
Manual review naik dari 8% menjadi 21%.
Fraud exposure turun 4%.
Processing time diperkirakan naik 18%.
Business team kemudian bisa menentukan apakah trade-off tersebut diterima.
Ini jauh lebih baik daripada mengganti rule pada hari Senin dan baru menyadari dampaknya setelah antrean manual review menumpuk pada Rabu.
Tambahkan Human-in-the-Loop untuk Kasus Abu-Abu
Tidak semua keputusan harus menghasilkan APPROVE atau REJECT.
Gunakan hasil ketiga:
REVIEW_REQUIRED
Misalnya rules engine dapat otomatis menyetujui transaksi low-risk dan otomatis menolak kasus yang jelas melanggar policy.
Kasus di tengah dikirim kepada manusia.
Contohnya:
Risk score <30 → Approve.
Risk score >80 → Reject.
Risk score 30–80 → Manual Review.
Pendekatan ini membuat automation menangani keputusan rutin sementara manusia fokus pada kasus yang membutuhkan konteks atau judgement.
Ini juga lebih aman ketika kualitas data belum sempurna.
Jika mandatory input tidak tersedia, jangan paksa rules engine menebak. Gunakan eskalassi ke reviewer.
Gunakan Reason Code untuk Meningkatkan Explainability
Decision output sebaiknya tidak hanya menghasilkan “ditolak”.
Tambahkan alasan.
Contohnya:
DECISION = REJECTED
REASON_CODE = CREDIT_LIMIT_EXCEEDED
atau:
DECISION = MANUAL_REVIEW
REASON_CODE = INCOMPLETE_RISK_DATA
Camunda Decision Engine menyediakan history information mengenai input parameter, rules yang dipicu, dan output keputusan. Informasi seperti ini membantu memahami bagaimana hasil tertentu dihasilkan.
Reason code berguna untuk customer support, audit, analytics, dan monitoring.
Tim dapat menemukan bahwa 40% rejection berasal dari satu aturan tertentu.
Insight tersebut bisa memicu evaluasi policy atau memperbaiki input data.
Tanpa explainability, rules engine mudah berubah menjadi “black box” meskipun logic sebenarnya dibuat oleh organisasi sendiri.
Monitor Rule Performance setelah Deployment
Rule yang secara teknis bekerja belum tentu memberikan outcome bisnis yang baik.
Pantau distribusi keputusan.
Misalnya sebelum perubahan:
Approve 70%
Manual Review 20%
Reject 10%
Setelah perubahan:
Approve 40%
Manual Review 55%
Reject 5%
Perubahan sebesar itu perlu diperiksa.
Apakah memang disengaja atau ada condition salah?
IBM Decision Center menggunakan simulation dengan KPI untuk membantu mengevaluasi dampak rules terhadap business outcome.
Gabungkan monitoring teknis dengan metrik bisnis.
Contohnya:
Approval rate
False rejection
Fraud rate
Manual review rate
Average decision latency
Revenue impact
Dengan cara ini, rules management bukan hanya urusan konfigrasi IT.
Rule menjadi bagian dari continuous improvement bisnis.
Hindari Rule Explosion
Masalah baru dapat muncul ketika setiap exception menghasilkan rule tambahan.
Awalnya ada 30 aturan.
Setelah dua tahun menjadi 1.200 aturan karena setiap permintaan khusus ditambahkan tanpa cleanup.
Lakukan review berkala.
Cari duplicate rule, overlapping condition, rule yang tidak pernah dipicu, obsolete policy, serta dependency yang terlalu rumit.
Oracle decision table mempunyai kemampuan membantu menemukan conflicting conditions maupun gap pada kombinasi rule. Struktur tabel juga memudahkan aturan terkait dibandingkan secara visual.
Refactor rules seperti melakukan refactor kode.
Hapus yang sudah tidak berlaku, gabungkan condition yang sama, dan pertahankan vocabulary yang konsisten.
Jangan biarkan rules engine berubah menjadi gudang policy lama yang tidak ada yang berani menyentuhnya.
Menggunakan Business Rules Engine untuk proses kompleks membutuhkan lebih dari sekadar decision table.
Terapkan domain ownership, versioning, approval, testing, simulation, reason code, dan human-in-the-loop agar keputusan tetap cepat sekaligus dapat dikontrol.
Mulailah mengaudit satu area dengan rule paling banyak dan lihat apakah decision governance dapat mengurangi ketergantungan pada hard-coded logic.