Ketika alur persetujuan mulai menyentuh banyak sistem, email, ERP, HRIS, e-procurement, hingga e-signature, masalah biasanya muncul bukan di formulirnya, tetapi di titik perpindahan data. Integrasi yang dirancang tepat dapat memangkas waktu siklus approval, menurunkan risiko otorisasi yang salah, dan membuat jejak audit lebih rapi. Panduan ini membantu tim IT menilai kapan integrasi benar-benar diperlukan, seberapa dalam integrasinya, dan kontrol apa yang wajib ada agar operasional tetap lincah tanpa mengorbankan keamanan.
mulai dari proses bisnis dan risiko, bukan dari API
Penilaian integrasi yang baik dimulai dengan memetakan proses: siapa yang mengajukan, siapa yang menyetujui, syarat apa yang harus dipenuhi, dan kapan keputusan dianggap final. Banyak organisasi langsung bertanya “bisa integrasi ke X?” Padahal pertanyaan yang lebih berguna adalah: titik mana yang paling sering menimbulkan rework, keterlambatan, atau temuan audit? Dari situ tim bisa menentukan integrasi mana yang memberi dampak terbesar.
Praktik efektif adalah membuat daftar keputusan berbasis kebijakan, misalnya limit nominal, kategori belanja, lokasi, atau jenis kontrak, lalu menilai sumber datanya. Jika aturan bergantung pada data master di ERP atau HRIS, integrasi sering kali bukan opsi karena tanpa itu penetapan approver dan validasi kebijakan rawan salah. Sebaliknya, bila persetujuan hanya memerlukan lampiran dan komentar tanpa ketergantungan data master, integrasi bisa ditunda.
Untuk memprioritaskan, gunakan penilaian sederhana berbasis risiko dan volume. Misalnya, persetujuan pengadaan dengan nominal besar dan dampak kepatuhan tinggi biasanya layak mendapat integrasi lebih awal dibanding persetujuan perjalanan dinas bernilai kecil. Di Indonesia, kebutuhan audit internal dan bukti saat pemeriksaan sering menjadi alasan kuat agar jejak keputusan, alasan, dan identitas konsisten lintas sistem.
- Frekuensi & volume: berapa transaksi per minggu, dan berapa persen yang terlambat.
- Dampak finansial: apakah keputusan memicu pembayaran, kontrak, atau komitmen anggaran.
- Risiko akses: apakah ada segregation of duties (SoD) yang harus dijaga.
- Kualitas data: seberapa sering terjadi duplikasi vendor, salah cost center, atau salah kategori.
- Kebutuhan audit: apakah diperlukan bukti persetujuan yang tidak mudah diubah.
audit integrasi yang sudah ada: data, identitas, dan titik kegagalan
Sebelum menambah integrasi baru, inventarisasikan integrasi yang sudah ada: metode (file batch, API, webhook), jadwal sinkronisasi, pemilik, dan SLA. Banyak masalah approval berakar dari integrasi warisan yang tidak memiliki monitoring dan alerting memadai. Satu kegagalan sinkronisasi cost center saja bisa mengalihkan permintaan ke approver yang salah.
Fokus pertama biasanya pada identitas dan otorisasi. Pastikan ada sumber kebenaran untuk identitas pengguna dan struktur organisasi, misalnya directory/IdP dan HRIS. Jika approver ditentukan oleh jabatan atau atasan langsung, integrasi data organisasi harus memiliki aturan fallback saat data atasan kosong, user pindah unit, atau terjadi reorganisasi.
Fokus kedua adalah model data: definisi entitas seperti “request”, “approval step”, “vendor”, “GL account”, atau “budget owner” harus konsisten. Tim IT sering menemukan sistem berbeda memakai kode yang mirip tetapi maknanya berbeda. Buat data contract yang jelas: field wajib, format, referensi, versi skema, lalu tentukan siapa yang berwenang mengubahnya dan bagaimana perubahan memengaruhi workflow.
Fokus ketiga adalah titik kegagalan dan rekonsiliasi. Alur persetujuan jarang benar-benar real-time di semua titik; karena itu Anda perlu strategi idempotency, retry, dan mekanisme rekonsiliasi. Contoh: sistem pengajuan mengirim event “approved” ke ERP, tetapi ERP sedang down; tanpa antrean atau retry yang aman, status akan tidak sinkron dan memicu proses manual yang rawan salah.
tentukan pola integrasi yang tepat: batch, event, atau orkestrasi
Pola integrasi sebaiknya dipilih berdasarkan kebutuhan bisnis, bukan tren arsitektur. Untuk approval, tiga pola yang paling sering dipakai adalah batch, event-driven, dan orkestrasi (workflow sebagai pengendali proses). Masing-masing punya trade-off pada latensi, kompleksitas, biaya operasional, dan risiko inkonsistensi.
Batch cocok untuk data referensi yang berubah periodik, seperti daftar proyek atau mapping cost center, selama ada timestamp dan kontrol versi. Batch lebih mudah diaudit karena jelas kapan snapshot diambil, tetapi bisa menimbulkan gap jika approval membutuhkan data terbaru. Event-driven cocok untuk perubahan status yang harus segera memicu tindakan, misalnya “approved” yang mengaktifkan PO atau release pembayaran, dengan syarat ada desain event schema, deduplikasi, dan observability yang matang.
Orkestrasi berarti satu komponen workflow mengendalikan langkah lintas aplikasi, misalnya memvalidasi budget di ERP, meminta review legal, lalu mengirim dokumen ke e-sign. Pola ini memberi visibilitas end-to-end, namun menuntut disiplin dalam penanganan error, kompensasi transaksi, dan pembagian tanggung jawab antar sistem. Jika organisasi Anda menilai bagaimana workflow internal memengaruhi efisiensi lintas fungsi, rujukan seperti pembahasan tentang efisiensi operasional melalui workflow internal bisa membantu menyamakan ekspektasi sebelum memutuskan pola orkestrasi.
Untuk memperjelas keputusan, tuliskan kebutuhan non-fungsional yang terukur. Misalnya: “SLA sinkronisasi approver < 5 menit”, “status harus konsisten maksimal 1 kali retry failure”, atau “jejak audit harus bisa diekspor per permintaan audit internal”. Kebutuhan seperti ini memudahkan penilaian apakah batch cukup atau harus event-driven.
- Latensi: seberapa cepat perubahan harus tercermin di sistem lain.
- Konsistensi: apakah toleran terhadap eventual consistency atau harus strong consistency.
- Kompleksitas operasi: monitoring, tracing, dan kemampuan tim untuk menjaga integrasi.
- Biaya kegagalan: apa dampaknya jika satu event hilang atau terlambat.
- Audit trail: kebutuhan pelacakan siapa melakukan apa, kapan, dan atas dasar data apa.
kontrol keamanan dan kepatuhan: akses, jejak audit, dan retensi
Integrasi pada sistem persetujuan hampir selalu membawa data sensitif: struktur organisasi, informasi gaji untuk kasus tertentu, data vendor, hingga dokumen kontrak. Karena itu, penilaian integrasi harus berjalan bersamaan dengan desain kontrol keamanan. Tujuannya untuk mencegah jalur bypass yang membuat approval tampak sah padahal tidak memenuhi kebijakan.
Mulailah dari kontrol akses: terapkan prinsip least privilege, jangan beri peran yang terlalu luas, dan hindari shared account untuk tindakan persetujuan. Untuk integrasi antar aplikasi, gunakan identitas mesin (service account) yang dibatasi scope dan masa berlaku kredensialnya, idealnya dengan secret management dan rotasi. Jika menggunakan SSO, pastikan mapping atribut (department, manager, employment status) di IdP konsisten agar deprovisioning karyawan otomatis menghapus akses approval.
Selanjutnya, perhatikan integritas keputusan. Persetujuan harus dapat dipertanggungjawabkan, jadi log harus mencatat identitas, timestamp, konteks (misalnya perubahan nominal sebelum disetujui), dan alasan jika ada override. Pertimbangkan non-repudiation untuk dokumen tertentu, misalnya melalui e-signature yang diakui praktiknya di Indonesia. Untuk keamanan data saat transit, wajibkan TLS; untuk data tersimpan, atur enkripsi at-rest sesuai standar internal dan klasifikasi data.
Terakhir, tetapkan retensi dan e-discovery secara realistis. Banyak organisasi menyimpan log terlalu singkat sehingga ketika audit berlangsung, bukti sudah hilang; menyimpan terlalu lama tanpa klasifikasi juga menambah risiko. Selaraskan dengan kebijakan arsip perusahaan dan kewajiban perlindungan data pribadi yang berlaku di Indonesia; untuk rujukan resmi terkait kerangka perlindungan data, lihat informasi dari otoritas terkait di Indonesia. Pastikan akses ke bukti persetujuan dibatasi, dan ada proses permintaan akses yang tercatat.
Jika seluruh penilaian di atas terdokumentasi dalam bentuk keputusan arsitektur (ADR), Anda akan lebih mudah menjelaskan mengapa beberapa integrasi dibuat real-time, sementara yang lain cukup batch. Dokumentasi yang ringkas tetapi tegas juga membantu saat terjadi insiden, karena tim dapat menelusuri dependensi dan mengetahui siapa pemilik tiap titik integrasi.
Pertimbangkan membuat workshop singkat lintas fungsi untuk memvalidasi prioritas integrasi dan skenario kegagalan utama.
Ketahui aspek keamanan dan integrasi di Epruvo