Permintaan pembelian mendesak tertahan, tetapi tidak ada yang tahu siapa yang sedang memegang persetujuan tanpa menelusuri email. Bukti keputusan tersebar; sebagian pembelian akhirnya dilakukan sebelum persetujuan selesai.
Workflow orchestration menyimpan status setiap permintaan: menunggu siapa, langkah berikutnya, dan sudah berapa lama menunggu. IBM menjelaskan koordinasi tugas lintas aplikasi dan layanan. Pada pengadaan, lapisan kontrol ini menghubungkan aplikasi pemohon, ERP, master vendor, dan approver. Pilar AUTOMATE mengatur eksekusi, dengan kewenangan keputusan tetap jelas.
Contoh Pengadaan sampai PO Terbit
Alur ini ilustratif; kebijakan mengikuti perusahaan:
- Validasi permintaan dan dokumen sumber.
- Periksa vendor serta periksa dan cadangkan anggaran lewat mekanisme atomik di sistem pemilik anggaran. Pemeriksaan saja bisa meloloskan dua permintaan atas dana yang sama.
- Tentukan jalur berdasarkan matriks kewenangan perusahaan, nilai pembelian, anggaran, dan status vendor.
- Minta keputusan pihak berwenang. Vendor belum terdaftar memerlukan registrasi; anggaran kurang menghentikan atau mengeskalasi permintaan.
- Setelah validasi dan persetujuan selesai, buat PO di ERP dan kirim ke vendor.
- Catat hasil; lepaskan cadangan bila ditolak atau dibatalkan.
Pemohon tidak boleh menyetujui permintaannya sendiri. Cocokkan kewenangan approver dengan nilai transaksi; permintaan berulang tepat di bawah batas dapat ditandai untuk pemeriksaan. Dua tugas validasi dapat berjalan paralel selama kontrol anggaran tetap dijaga.
Tentukan Batas Keputusan Otomatis
Otomasi layak ketika aturan dapat ditulis tanpa tafsir, data tepercaya, dan kesalahan mudah dikoreksi. Keputusan material, sulit dibatalkan, diwajibkan kebijakan, atau memakai data ambigu diarahkan ke manusia. Workflow menjalankan matriks kewenangan yang sudah disetujui, bukan menetapkan kewenangan baru.
Contohnya, pembelian di luar anggaran atau vendor yang tidak disetujui tidak lolos hanya karena nilainya kecil. AI dapat membaca penawaran PDF atau mengusulkan kategori, tetapi hasilnya tetap divalidasi dan approver melihat dokumen sumber. AI tidak memperoleh hak menyetujui.
Microsoft Agent Framework membedakan tugas agent yang terbuka dari workflow dengan langkah yang ditentukan. Pengadaan membutuhkan kontrol urutan dan kewenangan; AI dapat menjadi salah satu tugas di dalamnya.
Menunggu Manusia Memerlukan Kontrol Identitas
Contoh callback Step Functions memperlihatkan mekanisme jeda dan lanjut. Implementasi bisnis tetap harus mengautentikasi approver, memeriksa kewenangan, serta mencatat identitas yang benar-benar memutuskan. Tautan email saja tidak cukup.
Tetapkan tenggat, pengingat, delegasi, tujuan eskalasi, dan hasil akhir tanpa respons. Tidak adanya respons harus menghasilkan status yang jelas, bukan dianggap sebagai persetujuan. Jangan mengandalkan batas maksimum engine sebagai SLA bisnis.
Pilih Mekanisme Sesuai Proses
| Kondisi | Pilihan awal | Konsekuensi |
|---|---|---|
| Hampir semua langkah di ERP | Workflow bawaan | Mengurangi komponen tambahan |
| Lintas sistem, berhari-hari, tugas manusia | Workflow engine/BPM | Perlu status persisten, timeout, identitas, dan pemulihan |
| Pertukaran SaaS dengan connector | Platform integrasi/iPaaS | Periksa kontrol keputusan dan status yang tersedia |
| Sistem tanpa API | Adapter atau RPA | Automasi tampilan mudah terdampak perubahan UI |
Engine seperti Camunda, Temporal, atau Step Functions memiliki kemampuan berbeda; periksa durasi proses, tugas manusia, dan retensinya. Pipeline batch data bukan pengganti otomatis bagi workflow persetujuan.
Pengadaan sampai PO terbit memiliki urutan dan kompensasi. Setelah itu, notifikasi dan dashboard dapat menerima PurchaseOrderIssued secara mandiri melalui EDA. Orchestrator tetap komponen kritis yang perlu pemantauan serta pemulihan; Microsoft Saga menjelaskan tradeoff koordinasi ini.
Retry dan Titik yang Sulit Dibatalkan
Timeout pembuatan PO mungkin terjadi setelah ERP menyimpannya. Gunakan idempotency key berbasis permintaan. Jika ERP tidak mendukungnya, korelasikan nomor permintaan dan gunakan deduplikasi atomik atau kontrol konkurensi; pemeriksaan keberadaan saja tidak aman saat dua retry berjalan bersamaan. Rekonsiliasi hasil ambigu sebelum mencoba lagi.
Gunakan retry terbatas dengan backoff dan jitter untuk gangguan sementara; variasi jeda mengurangi retry serentak. Penolakan bisnis memerlukan koreksi. Pelepasan cadangan merupakan kompensasi dan dapat gagal; antrean pengecualian harus memiliki pemilik.
Pengiriman PO ke vendor ditempatkan setelah validasi penting karena pembatalannya mengikuti kontrak. Kasus berdampak besar atau ambigu dijeda untuk keputusan manusia, termasuk saat kegagalan terjadi.
Versi Aturan, Audit, dan Ukuran Hasil
Jika batas persetujuan berubah, putuskan apakah permintaan berjalan memakai aturan lama atau dimigrasikan. Camunda menjelaskan versioning proses; perubahan kode tugas juga perlu kompatibilitas terhadap instance lama.
Catat pelaku, waktu, alasan, dokumen yang dilihat beserta versinya, dan versi aturan. Step Functions Standard menyimpan riwayat selesai selama 90 hari; catatan audit dengan retensi perusahaan perlu penyimpanan tersendiri. Rekonstruksi objek bisnis penuh dapat dievaluasi lewat Event Sourcing.
Petakan proses bersama pelaksana memakai Event Storming. Catat baseline dari permintaan sampai PO, waktu tunggu tiap level, serta persentase permintaan tanpa intervensi tambahan di luar persetujuan wajib. Jumlah bot bukan KPI utama.
Tinjau level yang hampir selalu menyetujui tanpa perubahan: pemilik proses dapat mengevaluasi batas kewenangan atau pemeriksaan sampel setelah transaksi sesuai kebijakan. Penolakan berulang menandakan validasi sebelumnya perlu diperbaiki. Sistem menangani eksekusi; manusia berfokus pada keputusan.
FAQ
ERP sudah memiliki approval. Perlu orchestrator lain?
Belum tentu. Evaluasi fitur bawaan terlebih dahulu; komponen lain diperlukan bila koordinasi lintas sistem dan pemulihan tidak terpenuhi.
Apa bedanya dengan RPA?
RPA menjalankan interaksi aplikasi; orchestrator mengatur status proses. Bot dapat menjadi pelaksana satu tugas.
Bagaimana saat aturan berubah?
Versikan aturan dan tentukan kebijakan untuk permintaan aktif sebelum rilis, termasuk kebutuhan migrasi serta audit.
Sagara Xinix – Solusi Teknologi Terintegrasi dan Terpercaya menyediakan perancangan sistem dan integrasi. Bawa satu proses, baseline, dan daftar titik keputusan beserta kewenangannya ke diskusi dengan Sagara.