Dokumentasikan aturan bisnis untuk aplikasi AI dengan bahasa sederhana

Mengapa aturan yang tidak jelas membuat aplikasi tak dapat diandalkan

Aturan bisnis memberi tahu aplikasi apa yang harus dilakukan dalam situasi nyata. Mereka menjawab pertanyaan seperti siapa yang dapat menyetujui permintaan, bagaimana total dihitung, dan apa yang terjadi saat sebuah kasus berada di luar pola biasa.

Jika aturan itu samar, aplikasi tetap harus memilih jalur. Hanya saja mungkin bukan jalur yang Anda harapkan.

Contoh aturan seperti "pengeluaran besar perlu persetujuan manajer." Seorang manusia mungkin menganggap itu jelas. Pembuat aplikasi tidak. Apa yang dihitung sebagai besar: $500, $5,000, atau apa pun di atas anggaran tim? Manajer mana: atasan langsung, kepala departemen, atau keuangan? Jika tidak ada yang merespons dalam dua hari, apakah permintaan menunggu, kadaluarsa, atau diteruskan ke orang lain?

Itulah mengapa aturan samar menyebabkan aplikasi menjadi tidak andal. Pembuat hanya bisa setegas instruksi yang diterima. Ketika kata-kata memberi ruang untuk menebak, aplikasi bisa berperilaku satu cara hari ini dan cara lain besok saat situasi sedikit berbeda.

Masalah terbesar biasanya muncul di beberapa area:

• perhitungan dengan detail yang hilang, seperti pembulatan, pajak, diskon, atau rentang tanggal
• pengecualian yang semua orang anggap ada tetapi tidak ada yang menuliskannya
• langkah persetujuan tanpa pemilik, urutan, atau fallback yang jelas

Contoh sederhana menunjukkan masalahnya. Seorang pendiri membuat aplikasi pengeluaran internal di Koder.ai dan menulis, "Ganti biaya perjalanan kecuali terlihat tidak biasa." Itu terdengar masuk akal, tetapi aplikasi tidak punya cara andal untuk menilai "tidak biasa." Satu karyawan taksi-nya disetujui, yang lain yang mirip ditandai, dan tidak ada yang tahu kenapa.

Perilaku yang dapat diandalkan dimulai dengan aturan yang bisa diikuti dengan cara yang sama setiap kali. Kata-kata seperti "besar," "mendesak," dan "kasus khusus" perlu diganti dengan batas, kondisi, dan tindakan yang tepat. Jika dua orang berbeda akan menerapkan aturan dengan cara yang sama, aplikasi jauh lebih mungkin melakukan hal yang sama.

Bentuk aturan bisnis yang jelas

Aturan yang jelas mencakup satu keputusan atau satu tindakan, bukan seluruh proses. Ini lebih penting daripada yang kebanyakan tim perkirakan. Ketika satu aturan mencoba mencakup persetujuan, penetapan harga, pengecualian, dan notifikasi sekaligus, pembuat harus menebak bagian mana yang paling penting.

Aturan yang baik mudah dibacakan keras-keras. Seseorang di luar tim Anda harus memahaminya tanpa perlu singkatan internal Anda. Ganti istilah seperti "fast-track," "kasus standar," atau "tanda tangan manajer" dengan bahasa sederhana yang mengatakan persis apa yang terjadi.

Sebagian besar aturan yang jelas menjawab empat pertanyaan dasar:

• Siapa yang mengambil keputusan atau tindakan?
• Kapan aturan ini berlaku?
• Apa yang berubah di aplikasi?
• Apa yang terjadi selanjutnya?

Struktur itu menjaga aturan terkait dengan perilaku nyata. Daripada menulis, "Pesanan besar perlu ditinjau," tulis, "Jika sebuah pesanan lebih dari $5,000, manajer penjualan harus menyetujuinya sebelum dikirim ke pemenuhan." Satu kalimat, satu keputusan, satu hasil.

Juga membantu untuk memisahkan aturan yang terkait. Aturan persetujuan harus berdiri sendiri. Aturan untuk mengirim email harus terpisah. Aturan untuk memblokir pengiriman juga terpisah. Itu membuat tiap aturan lebih mudah diuji, diperbarui, dan diperbaiki.

Perbedaannya mudah dilihat:

"Pelanggan premium mendapatkan penanganan prioritas" itu samar.

"Jika pelanggan memiliki paket premium, permintaan dukungan ditandai Prioritas Tinggi saat tiket dibuat" itu jelas.

Versi kedua menyebut pemicu, kondisi, dan perubahan di dalam aplikasi. Itu memberi tahu pembuat seperti apa perilaku yang dapat diandalkan.

Jika Anda menggunakan builder berbasis chat, jenis kata-kata ini membuat perbedaan besar. Aturan yang jelas tidak perlu bahasa legal. Mereka perlu kata-kata sederhana, satu ide per waktu, dan hasil yang diharapkan yang muat dalam satu kalimat.

Menulis perhitungan dengan bahasa sederhana

Perhitungan sering tampak sederhana sampai seseorang mencoba membangunnya. Pendekatan paling aman adalah mulai dengan satu kalimat sederhana yang mengatakan persis apa yang harus dilakukan aplikasi.

Aturan yang baik terdengar seperti ini: "Jumlah penggantian sama dengan mil yang disetujui dikalikan dengan tarif per mil." Itu jauh lebih jelas daripada "hitung gaji perjalanan" atau "terapkan standar penggantian."

Setelah kalimat pertama itu, definisikan setiap input yang harus digunakan aplikasi. Jadilah cukup spesifik sehingga pembuat tidak perlu menebak.

Apa yang harus didefinisikan untuk setiap perhitungan

Untuk setiap perhitungan, jelaskan:

• input, dengan nama sederhana dan satuan
• dari mana setiap nilai berasal
• aturan pembulatan
• nilai minimum atau maksimum jika ada
• apa yang terjadi jika sebuah nilai hilang

Detail kecil penting. "Bulatkan jumlah akhir ke 2 tempat desimal" memberi hasil berbeda dari membulatkan setiap baris terlebih dahulu. Jika ada batas maksimum, katakan apakah aplikasi harus berhenti pada batas itu atau menampilkan peringatan.

Aturan yang ditulis dengan bahasa sederhana bisa terlihat seperti ini: "Jumlah penggantian perjalanan sama dengan mil yang disetujui x $0.67. Bulatkan jumlah akhir ke 2 tempat desimal. Maksimum penggantian $300 per perjalanan. Jika mil yang disetujui kosong, jangan hitung jumlahnya. Tandai permintaan sebagai tidak lengkap dan minta pengguna memasukkan mil."

Lalu tambahkan satu atau dua contoh kerja dengan angka nyata. Contoh mengekspos celah lebih cepat daripada rumus abstrak.

Example 1: "Jika mil yang disetujui adalah 120, penggantian adalah 120 x $0.67 = $80.40. Karena ini di bawah batas $300, jumlah akhir adalah $80.40."

Example 2: "Jika mil yang disetujui adalah 500, penggantian adalah 500 x $0.67 = $335.00. Karena maksimum adalah $300, jumlah akhir adalah $300.00."

Gaya ini lebih mudah untuk direview oleh orang dan lebih mudah bagi pembuat untuk mengubahnya menjadi perilaku aplikasi.

Menangkap pengecualian tanpa kebingungan

Kebanyakan aplikasi tidak gagal pada aturan utama. Mereka gagal pada kasus tepi.

Jalur normal mungkin sederhana, tetapi pekerjaan nyata mencakup pengembalian dana setelah batas waktu, pelanggan VIP, dokumen yang hilang, dan persetujuan satu kali. Jika pengecualian dibiarkan, aplikasi mengisi celah sendiri, dan di situlah hasil menjadi tidak konsisten.

Cara sederhana menulis pengecualian adalah menggunakan aturan if-then singkat. Pertahankan tiap aturan fokus pada satu kondisi dan satu hasil.

• Jika pengeluaran di bawah $100, maka auto-approve.
• Jika pengeluaran di bawah $100 tetapi diajukan setelah 30 hari, maka kirim untuk tinjauan manual.
• Jika karyawan berada di tim eksekutif, maka lewati batas $100 dan arahkan ke keuangan.
• Jika admin keuangan menandai klaim sebagai mendesak, maka override manual berlaku dan klaim pindah ke bagian atas antrean.

Format ini membuat logika tersembunyi menjadi terlihat. Itu juga membantu Anda melihat tumpang tindih sebelum menjadi bug.

Sama pentingnya, katakan aturan mana yang menang ketika dua aturan bertabrakan. Seorang pelanggan mungkin memenuhi syarat untuk diskon, tetapi pesanan juga bisa masuk periode blackout liburan. Tulis prioritasnya dalam bahasa sederhana: "Jika aturan blackout liburan bertentangan dengan aturan diskon pelanggan, aturan blackout menang."

Tegaskan batasnya. Tanggal, tipe pengguna, lokasi, status akun, dan override manual sering mengubah hasil. Daripada menulis "pengajuan terlambat perlu persetujuan," tulis "Jika sebuah permintaan diajukan lebih dari 14 hari kalender setelah kejadian, maka persetujuan manajer diperlukan."

Juga katakan apa yang harus ditampilkan aplikasi kepada pengguna di setiap pengecualian. Aturan yang baik tidak berhenti pada keputusan. Ia juga mendefinisikan pesan, seperti "Diajukan setelah 14 hari. Persetujuan manajer diperlukan" atau "Override manual diterapkan oleh admin keuangan."

Ketika pengecualian ditulis dengan cara ini, kasus tidak biasa berhenti terasa tidak biasa. Mereka menjadi perilaku normal yang bisa diuji.

Menjelaskan logika persetujuan langkah demi langkah

Logika persetujuan bekerja paling baik saat ditulis sebagai urutan keputusan, bukan kebijakan samar. Setiap langkah harus menjawab lima pertanyaan: siapa yang bertindak, apa yang memicu peninjauan mereka, batas apa yang berlaku, berapa lama mereka punya waktu, dan status apa yang didapat permintaan setelah mereka memutuskan.

Mulailah dengan menyebut peran, bukan hanya tim. Daripada menulis "keuangan meninjau permintaan besar," tulis "Manajer Keuangan dapat menyetujui, menolak, atau mengembalikan permintaan apa pun di atas $5,000." Itu menghilangkan tebakan dan memudahkan pembangunan perilaku.

Lalu definisikan pemicu untuk setiap langkah. Pemicu adalah kondisi yang mengirim permintaan ke orang berikutnya. Bisa berdasarkan jumlah, departemen, tingkat risiko, jenis permintaan, atau gabungan.

Contoh:

• Jika permintaan di bawah $500, ketua tim meninjau.
• Jika permintaan $500 sampai $5,000, manajer departemen meninjau setelah ketua tim menyetujui.
• Jika permintaan di atas $5,000, keuangan meninjau setelah manajer departemen menyetujui.
• Jika permintaan ditandai berisiko tinggi, compliance harus meninjau sebelum persetujuan akhir.

Ambang batas perlu batas yang tepat. Jangan katakan "besar" atau "sensitif." Katakan "di atas $5,000," "dari departemen Penjualan," atau "skor risiko 8 atau lebih." Jika dua ambang bisa berlaku, katakan mana yang menang. Misalnya: "Risiko tinggi selalu pergi ke compliance, bahkan jika jumlah rendah."

Anda juga perlu aturan timeout. Jika tak ada yang merespons, aplikasi tidak boleh terdiam selamanya. Katakan apa yang terjadi setelah waktu tertentu, seperti 48 jam atau 3 hari kerja. Permintaan bisa saja ditingkatkan ke manager approver, dialihkan ke pengganti, atau otomatis dibatalkan.

Terakhir, definisikan status setelah setiap keputusan. Pertahankan label singkat dan konsisten:

• Disetujui: permintaan maju atau selesai.
• Ditolak: permintaan ditutup dan tidak ada tindakan lebih lanjut.
• Dikembalikan: pemohon harus mengedit dan mengajukan ulang.
• Ditingkatkan: permintaan pindah ke pengganti atau approver yang lebih tinggi.

Saat logika persetujuan ditulis seperti ini, pembuat punya lebih sedikit ruang untuk menebak dan alur kerja menjadi jauh lebih andal.

Template aturan sederhana yang bisa Anda pakai ulang

Jika Anda ingin perilaku konsisten, beri setiap aturan bentuk yang sama. Gaya penulisan campur sering menghasilkan hasil yang campur. Format sederhana bekerja untuk kebanyakan kasus: pemicu, kondisi, tindakan, hasil. Pendek dan cukup jelas untuk direview.

Gunakan satu aturan, satu unit

Pertahankan tiap aturan di baris, kartu, atau bloknya sendiri. Jangan memadatkan beberapa ide dalam satu paragraf. Jika aturan mencakup harga, persetujuan, dan pengecualian sekaligus, menjadi sulit diuji dan mudah disalahpahami.

Format praktis seperti ini:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

Anda tidak perlu setiap kolom setiap saat. Tetapi menjaga urutan yang sama membantu orang memindai aturan dengan cepat.

Contoh:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

Perhatikan bahwa contoh berada di bawah aturan, bukan di dalamnya. Itu menjaga aturan tetap bersih. Contoh hanya membuktikan bagaimana aturan harus berperilaku.

Tandai asumsi dengan jelas alih-alih menyembunyikannya di dalam kalimat. Catatan kecil seperti "Asumsi" atau "Perlu konfirmasi" membuat pertanyaan terbuka mudah direview sebelum waktu pembangunan.

Juga bantu dengan mempertahankan konsistensi kata-kata. Selalu mulai pemicu dengan "When," kondisi dengan "If," dan tindakan dengan "Then." Pola kecil seperti ini mengurangi kebingungan, terutama saat aturan diterjemahkan ke logika aplikasi.

Uji cepat berguna di sini: bisakah seseorang menguji aturan ini, dan bisakah seseorang salah membacanya? Jika jawaban untuk yang pertama tidak, atau yang kedua ya, perketat bahasanya.

Contoh: aplikasi persetujuan pengeluaran

Aplikasi pengeluaran karyawan adalah kasus uji yang baik karena kebijakan sudah familier dan kasus tepi muncul cepat. Staf bisa mengklaim makan, taksi, hotel, dan biaya kecil untuk klien, tetapi tiap klaim punya batas, pengecualian, dan langkah persetujuan. Inilah jenis proses di mana bahasa sederhana sangat penting.

Kebijakan sampel

Tulis aturan makan seperti ini: karyawan dapat mengklaim hingga $40 per hari untuk makan pada hari kerja normal. Aplikasi harus menjumlahkan semua tanda terima makan untuk tanggal yang sama dan membandingkan total itu dengan batas harian, bukan tiap tanda terima sendiri.

Jika karyawan menghabiskan $12 untuk sarapan dan $22 untuk makan siang pada hari Selasa, totalnya $34, jadi klaim lolos. Jika mereka menambahkan makan malam $15 pada hari yang sama, total menjadi $49, sehingga aplikasi harus menandai klaim melebihi batas.

Sekarang tambahkan pengecualian. Jika makan terjadi selama perjalanan bisnis yang disetujui atau pertemuan klien, batas makan harian naik menjadi $75. Pengecualian itu hanya berlaku ketika karyawan memilih Travel day = Yes atau Client meeting = Yes dan menambahkan catatan singkat dengan nama klien atau tujuan perjalanan.

Ini lebih andal daripada kata-kata samar seperti "kasus khusus mungkin diizinkan" karena pengecualian terkait kondisi yang jelas.

Langkah persetujuan

Logika persetujuan bisa tetap sederhana:

• Klaim di bawah $100 disetujui oleh manajer karyawan.
• Klaim $100 sampai $500 perlu persetujuan manajer, lalu persetujuan keuangan.
• Klaim di atas $500 perlu persetujuan manajer, persetujuan keuangan, dan persetujuan kepala departemen.
• Setiap klaim yang ditandai "travel" juga perlu tinjauan keuangan, meskipun jumlah di bawah $100.

Anda bisa menguji aturan dengan beberapa kasus sederhana. Klaim makan $36 pada hari kerja normal harus disetujui jika tanda terima dilampirkan. Klaim makan $60 pada hari perjalanan harus lolos jika travel ditandai dan catatan terisi. Klaim makan $60 pada hari normal harus ditolak atau dikembalikan untuk koreksi. Klaim hotel $650 harus melewati ketiga langkah persetujuan.

Itu tujuannya: aturan harus menghasilkan hasil yang sama setiap kali seseorang mengujinya dengan kasus nyata.

Kesalahan umum yang menyebabkan hasil buruk

Aturan bisa terdengar jelas bagi orang dan tetap membingungkan pembuat. Itu biasanya terjadi bila dokumen samar, penuh ide campur, atau tidak konsisten dari satu baris ke baris berikutnya.

Satu kesalahan umum adalah memasukkan beberapa aturan ke dalam satu paragraf panjang. Misalnya: "Manajer menyetujui perjalanan kecuali totalnya tinggi, keuangan memeriksa tanda terima, dan permintaan mendesak bisa melewati tinjauan." Itu mungkin terlihat efisien, tetapi menyembunyikan beberapa keputusan terpisah. Pisahkan menjadi aturan berbeda supaya tiap tindakan punya pemicu dan hasil sendiri.

Masalah lain adalah bahasa kabur. Kata-kata seperti normal, besar, mendesak, atau baru bekerja hanya jika didefinisikan. Jika "pengeluaran besar" berarti lebih dari $2,000, katakan itu. Jika "mendesak" berarti dibutuhkan dalam 24 jam, tulis kondisi itu secara tepat.

Data yang hilang adalah sumber besar lain masalah. Tim sering mendeskripsikan jalur bahagia dan lupa mengatakan apa yang harus terjadi ketika informasi tidak lengkap atau salah. Jika permintaan tidak punya jumlah, departemen, atau tanda terima, aturan harus mengatakan langkah selanjutnya.

Kesalahan yang paling bermasalah biasanya:

• menggabungkan beberapa aturan dalam satu paragraf
• menggunakan istilah tak terdefinisi untuk ukuran, waktu, atau prioritas
• lupa kasus error dan field yang hilang
• meninggalkan kewenangan persetujuan akhir tidak jelas
• mengubah nama untuk hal yang sama di tengah dokumen

Wewenang akhir penting lebih dari yang banyak tim duga. Jika seorang manajer dan peninjau keuangan tidak setuju, siapa yang membuat keputusan akhir? Jika tak ada yang memegang langkah terakhir, aplikasi bisa macet atau mengirim kerja berputar-putar.

Perubahan istilah menciptakan kesalahan yang lebih halus. Jika Anda mulai dengan "permintaan" dan kemudian menyebutnya "submission" atau "ticket," pembaca mungkin mengira itu item berbeda. Pilih satu istilah dan gunakan secara konsisten di seluruh dokumen.

Ini bahkan lebih penting di builder berbasis chat, di mana bahasa sederhana mengarahkan perilaku. Aturan yang jelas tak perlu terdengar formal. Mereka harus spesifik, konsisten, dan lengkap.

Daftar periksa cepat sebelum Anda membangun

Sebelum mengubah kebutuhan menjadi layar, alur, atau prompt, lakukan tinjauan singkat. Pemeriksaan kecil sekarang bisa menghemat jam memperbaiki perilaku aneh nanti.

Buat setiap aturan dapat diuji. Setiap aturan harus berakhir dengan hasil jelas seperti ya atau tidak, setuju atau tolak, terapkan biaya atau tidak. Jika dua orang bisa membaca kalimat yang sama dan memberi jawaban berbeda, aturan perlu diperbaiki.

Jelaskan setiap perhitungan. Sebut nama input, rumus, dan kapan perhitungan terjadi. Tambahkan pembulatan, mata uang, penanganan tanggal, dan apa yang harus terjadi jika nilai hilang atau nol.

Pisahkan pengecualian. Tulis aturan default dulu, lalu tambahkan pengecualian sendiri. Batas pengeluaran utama tidak boleh terkubur dalam kasus khusus untuk kontraktor, pembelian mendesak, atau perjalanan yang disetujui.

Peta jalur persetujuan lengkap. Untuk setiap ambang, nyatakan siapa yang menyetujui dan apa yang terjadi selanjutnya. Tepat juga di tepi: katakan apakah aturan dimulai di atas $500 atau $500 ke atas.

Lalu lakukan tes orang baru. Beri aturan pada seseorang yang belum pernah mengerjakannya dan minta mereka menjelaskannya kembali dengan kata-kata sendiri. Jika mereka butuh konteks tambahan, aturan masih terlalu samar.

Contoh kecil menunjukkan mengapa ini penting. "Manajer menyetujui pengeluaran besar" terdengar jelas sampai seseorang bertanya apakah $500 termasuk besar. "Manajer menyetujui pengeluaran di atas $500. Direktur menyetujui pengeluaran di atas $2,000. Pengeluaran $500 atau kurang disetujui otomatis" jauh lebih sedikit memberi ruang untuk kesalahan.

Mengubah aturan menjadi aplikasi yang bekerja

Setelah aturan jelas, tinjau dengan orang yang menggunakan proses setiap hari. Manajer, koordinator, staf keuangan, dan approver sering melihat detail kecil yang tidak pernah masuk ke dokumen kebijakan. Detail itu biasanya membuat aplikasi terasa mulus atau membuat frustrasi.

Perlakukan dokumen aturan sebagai instruksi kerja, bukan draf sekali pakai. Ia harus menjelaskan apa yang terjadi, siapa yang memutuskan, apa pengecualian, dan apa yang aplikasi lakukan ketika informasi hilang.

Sebelum membangun aplikasi penuh, uji beberapa skenario nyata dari pekerjaan terbaru. Gunakan kasus bersih dan berantakan: permintaan standar yang harus lolos, permintaan dengan informasi yang hilang, pengecualian yang perlu tinjauan manual, dan kasus yang melewati batas pengeluaran atau ambang persetujuan.

Langkah ini menangkap celah lebih awal. Sebuah aturan mungkin terdengar jelas di kertas tetapi runtuh saat permintaan nyata tidak cocok pola yang diharapkan.

Setelah skenario itu tahan uji, masukkan ke builder Anda. Jika Anda menggunakan platform berbasis chat seperti Koder.ai, set aturan yang jelas membuat pembangunan jauh lebih cepat karena Anda menerjemahkan proses terdefinisi menjadi layar, tindakan, dan persetujuan alih-alih membuat keputusan secara spontan.

Setelah diluncurkan, jadikan dokumen itu sumber kebenaran. Ketika kebijakan berubah, approver baru ditambahkan, atau batas diperbarui, ubah dokumen dulu lalu perbarui aplikasi. Itu membuat perubahan di masa depan lebih sederhana dan mengurangi kemungkinan orang mengingat aturan berbeda-beda.

Kebiasaan kecil membantu di sini: tinjau aturan setiap kali proses berubah, bukan hanya saat aplikasi rusak. Pembaruan kecil yang dilakukan lebih awal jauh lebih mudah daripada memperbaiki perilaku membingungkan nanti.

Jika dokumen tetap mutakhir, aplikasi menjadi lebih mudah diuji, ditingkatkan, dan dipercaya seiring waktu.