Permintaan persetujuan yang terlihat sederhana sering menjadi hambatan saat volume naik, akses perlu dibatasi ketat, dan audit rutin diminta. Saat memilih antara cloud atau on-premises, kesalahan teknis sering baru terlihat setelah sistem berjalan: integrasi mandek, kontrol akses sulit dibuktikan, atau biaya operasional membengkak. Artikel ini memandu cara mengevaluasi kriteria teknis terpenting untuk sistem persetujuan, dengan fokus pada keamanan, integrasi, dan kebutuhan operasional di Indonesia.
Mulai dari kebutuhan: alur persetujuan, risiko, dan batasan operasional
Langkah awal bukan membandingkan vendor, melainkan memetakan kebutuhan yang menentukan arsitektur. Buat daftar jenis persetujuan paling kritis, misalnya pengadaan, akses aplikasi, pembayaran vendor, atau perubahan konfigurasi produksi. Tiap jenis punya tingkat risiko dan jejak audit berbeda, sehingga memengaruhi pilihan cloud atau on-premises.
Buat konkret dengan tiga pertanyaan: siapa pemohon dan approver, data apa yang diproses, dan apa konsekuensi jika terjadi penyalahgunaan. Jika approval menyentuh data sensitif seperti nomor rekening vendor atau kontrak, maka enkripsi, pengelolaan kunci, dan kebijakan retensi menjadi prioritas. Bila menyangkut sistem produksi, fokus pada integritas, non-repudiation, dan kontrol perubahan yang ketat.
- Target RTO/RPO: berapa toleransi downtime dan kehilangan data untuk proses approval.
- Lokasi pengguna: kantor pusat saja atau juga cabang, remote, dan pihak ketiga.
- Dependensi integrasi: HRIS/ERP, email, chat, ticketing, IAM, dan direktori.
- Kebutuhan audit: bukti siapa menyetujui, kapan, dari mana, dan apa yang berubah.
- Kebijakan data: klasifikasi data, retensi, dan kebutuhan e-discovery internal.
Dengan peta ini, Anda bisa menilai apakah alasan memilih on-premises benar-benar didorong oleh kebutuhan risiko atau hanya kebiasaan. Dalam banyak kasus, arsitektur hybrid masuk akal: alur persetujuan berjalan di cloud, sementara konektor atau komponen tertentu tetap di jaringan internal untuk mengakses sistem lama.
Keamanan dan kepatuhan: identitas, akses, audit, dan residensi data
Untuk sistem persetujuan, keamanan bukan sekadar enkripsi. Penting mengetahui siapa yang bisa melakukan apa, kapan, dan bagaimana bukti aktivitas diverifikasi. Periksa kemampuan kontrol akses berbasis peran dan atribut (RBAC/ABAC) serta dukungan pemisahan tugas.
Di sisi identitas, prioritas teknis umumnya integrasi SSO dengan IdP (SAML/OIDC) dan dukungan MFA adaptif. Cloud sering lebih matang dalam integrasi IdP dan kebijakan akses kondisional, sementara on-premises lebih mudah disesuaikan untuk direktori internal kompleks. Pastikan juga dukungan untuk akses just-in-time bagi admin dan pencatatan aktivitas administratif.
Auditability menjadi pembeda utama: cari bukti teknis seperti immutable audit log, time-stamping, korelasi dengan log SIEM, dan kemampuan mengekspor log tanpa kehilangan konteks. Pada on-premises Anda harus merancang ketahanan log sendiri (misalnya WORM storage) dan kontrol akses agar log tak mudah dimodifikasi. Untuk cloud, pahami lokasi penyimpanan log, periode retensi default, serta opsi bring your own key (BYOK) atau manajemen kunci terpusat.
Dalam konteks Indonesia, perhatikan kewajiban internal terkait kerahasiaan data, permintaan audit, dan praktik tata kelola TI. Organisasi yang memproses data pribadi perlu menyelaraskan kebijakan internal dengan kerangka kepatuhan dan penilaian risiko, termasuk pilihan lokasi pusat data dan prosedur akses vendor. Jika butuh rujukan praktik resmi, lihat informasi perlindungan data di situs Kominfo: kominfo.go.id.
Terakhir, uji skenario respons insiden. Tanyakan seberapa cepat Anda bisa menonaktifkan akun yang disusupi, menarik token sesi, dan menghasilkan laporan kejadian yang dapat diaudit. Jawaban yang baik harus menjelaskan prosedur, bukan hanya fitur.
Integrasi dan arsitektur: konektivitas, API, dan keterikatan pada sistem lama
Sistem persetujuan jarang berdiri sendiri. Nilai sebenarnya muncul ketika sistem bertindak sebagai gerbang keputusan untuk ERP, HRIS, repositori dokumen, sistem keuangan, dan pipeline DevOps. Karena itu nilai opsi cloud vs on-premises harus dinilai dari sisi integrasi: protokol, stabilitas API, pola event, dan orkestrasi.
Untuk cloud, fokus pada bagaimana koneksi aman ke sistem internal dibuat. Opsi umum meliputi VPN site-to-site, private link, atau agen konektor yang berjalan di jaringan internal. Pastikan konektor mendukung outbound-only jika kebijakan Anda melarang inbound, serta ada kontrol versi dan pemantauan kesehatan konektor.
Di on-premises, integrasi bisa lebih dekat dari sisi latensi, tetapi beban integrasi bergeser ke tim Anda. Siapkan load balancer, pengelolaan sertifikat, pembaruan dependensi, dan cek kompatibilitas API. Sistem lama sering memakai autentikasi non-standar atau format data yang tidak konsisten, sehingga membutuhkan middleware atau iPaaS internal.
Contoh praktis: persetujuan pengadaan yang harus menghalangi pembuatan PO di ERP sampai approval final. Di cloud, pola ideal adalah event-driven: approval memicu event, lalu integrasi memanggil API ERP dengan token layanan yang dibatasi scope. Di on-premises, integrasi langsung ke database atau service internal mungkin dipilih, tetapi berisiko tanpa kontrak API yang stabil dan kontrol perubahan disiplin.
Jika ingin menilai kesiapan organisasi untuk mendapat manfaat dari otomasi workflow, indikator adopsi dan perilaku pengguna sering lebih menentukan daripada lokasi penempatan. Sinyal-sinyal tersebut membantu memvalidasi asumsi non-teknis yang memengaruhi desain: indikator adopsi yang menunjukkan nilai aplikasi workflow internal.
Biaya, operasional, dan keandalan: apa yang benar-benar Anda kelola
Perbandingan biaya sering salah kaprah karena hanya melihat lisensi versus server. Yang relevan adalah total biaya kepemilikan: waktu engineering, patching, monitoring, backup, uji DR, dan dukungan audit. Cloud biasanya memindahkan sebagian pekerjaan ke penyedia, tapi Anda tetap harus mengelola konfigurasi, kebijakan akses, dan integrasi.
Pada on-premises, keandalan bergantung pada desain dan disiplin operasional. Anda butuh HA untuk aplikasi dan database, strategi backup yang diuji pemulihannya, serta DR site jika RTO/RPO ketat. Jika tim SRE atau infrastruktur terbatas, sistem persetujuan bisa jadi prioritas rendah padahal berpengaruh langsung pada operasi harian.
Sisi lain dari cloud adalah risiko ketergantungan pada vendor dan perubahan layanan. Mitigasinya bukan menolak cloud, melainkan menuntut detail: SLA, kebijakan pemeliharaan, notifikasi perubahan, mekanisme ekspor data, dan kemampuan data portability. Evaluasi juga kemampuan memisahkan lingkungan dev/test/prod, dukungan IaC untuk konfigurasi, serta audit konfigurasi agar perubahan tercatat.
Untuk keputusan lebih terukur, buat matriks penilaian sederhana yang memberi bobot pada: keamanan (IAM, audit log, key management), integrasi (API, konektor, event), operasional (patching, monitoring, DR), dan biaya (langsung dan tidak langsung). Uji matriks itu pada 2–3 alur approval paling kritis, bukan hanya pada demo fitur.
Pada akhirnya, pilihan terbaik adalah yang paling konsisten dengan profil risiko, kapasitas operasional, dan kebutuhan integrasi Anda.
Jika Anda perlu, susun matriks evaluasi satu halaman dan uji dengan satu alur persetujuan paling kritis.
Ketahui aspek keamanan dan integrasi di Epruvo