Ketika satu pengguna ERP dapat membuat vendor, memasukkan tagihan, menyetujui pembayaran, dan mengubah rekening tujuan, persoalannya bukan sekadar hak akses yang terlalu luas. Perusahaan kehilangan pemisahan kontrol pada rangkaian transaksi yang bernilai. Segregation of duties ERP atau pemisahan tugas membantu memastikan satu orang tidak mengendalikan seluruh tahapan proses kritis tanpa pemeriksaan pihak lain.
Kontrol ini penting untuk perusahaan dengan banyak unit, cabang, gudang, atau entitas. Semakin kompleks operasi, semakin mudah konflik akses tersembunyi di balik role yang diwariskan, akses sementara, integrasi antarsistem, dan perubahan tanggung jawab pegawai. Karena itu, SoD perlu dirancang dari proses bisnis dan risiko transaksi—bukan hanya dari daftar menu aplikasi.
Apa Itu Segregation of Duties dalam ERP?
Segregation of duties (SoD) adalah prinsip membagi aktivitas yang berpotensi menimbulkan konflik kepada orang atau role yang berbeda. NIST SP 800-53 Rev. 5, kontrol AC-5, meminta organisasi mengidentifikasi tugas yang perlu dipisahkan dan mendefinisikan otorisasi akses sistem untuk mendukung pemisahan tersebut. Dalam konteks ERP, pemisahan ini diterjemahkan menjadi kombinasi transaksi, data, organisasi, dan tingkat persetujuan yang tidak boleh dikuasai sendirian.
Contoh sederhana terdapat pada proses procure-to-pay. Pengguna yang membuat atau mengubah master vendor idealnya tidak sekaligus memiliki kewenangan untuk menyetujui invoice dan mengeksekusi pembayaran. Pada order-to-cash, pembuat pelanggan atau pengubah limit kredit tidak semestinya bebas membuat penyesuaian piutang tanpa review. Di gudang, pencatat penerimaan barang sebaiknya tidak dapat menghapus jejak selisih stok dan menyetujui koreksi sendiri.
SAP menjelaskan SoD sebagai kebutuhan melibatkan lebih dari satu orang dalam penyelesaian tugas agar satu individu tidak menguasai beberapa fase transaksi. Oracle juga menempatkan analisis SoD preventif pada proses provisioning akses untuk memisahkan aktivitas seperti approval, recording, dan processing. Prinsipnya sama, tetapi implementasi harus mengikuti proses, struktur organisasi, dan risiko perusahaan sendiri.
Mengapa Role ERP Sering Tetap Mengandung Konflik?
Role bernama “Finance”, “Purchasing”, atau “Admin Cabang” terlihat rapi, tetapi nama role tidak membuktikan bahwa kombinasi izin di dalamnya aman. Konflik biasanya muncul melalui akumulasi akses: pegawai berpindah jabatan tetapi role lama tidak dicabut, akses darurat menjadi permanen, atau dua role yang aman secara terpisah menjadi berbahaya ketika digabungkan.
Konflik juga dapat melintasi aplikasi. Seseorang mungkin hanya membuat data vendor di ERP, tetapi memiliki hak menyetujui pembayaran di internet banking atau aplikasi treasury. Karena itu, evaluasi SoD tidak boleh berhenti di satu modul. Peta kontrol perlu mencakup ERP, aplikasi pendukung, integrasi, dan aktivitas manual yang melengkapi transaksi.
Contoh Matriks Konflik SoD ERP
| Proses | Aktivitas A | Aktivitas B yang Berkonflik | Risiko Utama |
|---|---|---|---|
| Procure-to-pay | Membuat atau mengubah vendor | Menyetujui invoice atau pembayaran | Transaksi kepada pihak yang tidak semestinya |
| Order-to-cash | Membuat pelanggan atau limit kredit | Membuat credit memo atau write-off | Penyesuaian piutang tanpa review independen |
| Inventory | Mencatat penerimaan atau mutasi | Menyetujui stock adjustment | Selisih persediaan tidak terdeteksi |
| Payroll | Mengubah data pegawai atau rekening | Memproses dan menyetujui payroll | Perubahan data sensitif tanpa verifikasi |
| General ledger | Membuat jurnal manual | Menyetujui atau mem-posting jurnal | Koreksi keuangan tanpa pemeriksaan kedua |
Matriks tersebut adalah titik awal, bukan template universal. Risiko dan kontrol harus diturunkan dari SOP, nilai transaksi, volume, struktur cabang, kewenangan manajerial, serta sistem yang benar-benar digunakan.
Desain SoD yang Praktis untuk ERP
1. Mulai dari proses end-to-end
Petakan alur dari permintaan sampai pencatatan final. Tandai siapa yang membuat data, memverifikasi, menyetujui, mengeksekusi, merekonsiliasi, dan memantau. Pendekatan ini sejalan dengan kebutuhan ERP discovery dan audit requirement: keputusan akses harus dapat ditelusuri ke proses dan pemilik bisnis.
2. Tetapkan pasangan aktivitas yang berkonflik
Jangan hanya membuat daftar role. Definisikan pasangan atau rangkaian aktivitas yang tidak boleh dimiliki oleh satu identitas. Sertakan akses melalui API, service account, aplikasi mobile, dan fitur impor massal karena jalur tersebut dapat menghasilkan dampak yang sama dengan transaksi manual.
3. Gunakan prinsip least privilege
Berikan akses sesuai tugas aktual, lingkup organisasi, nilai transaksi, dan periode kebutuhan. Hubungkan desain SoD dengan prinsip Zero Trust pada aplikasi enterprise: identitas yang valid tetap perlu dibatasi menurut konteks dan kewenangan.
4. Pisahkan maker, checker, dan executor
Untuk proses berisiko tinggi, pisahkan pembuatan transaksi, pemeriksaan, persetujuan, dan eksekusi. Workflow approval harus mencegah self-approval dan mencatat siapa bertindak pada setiap tahap. Nilai ambang dapat digunakan agar transaksi material memperoleh tingkat persetujuan tambahan.
5. Pastikan audit trail mendukung investigasi
SoD mencegah atau menahan konflik, sedangkan audit trail aplikasi enterprise membantu merekonstruksi peristiwa. Sistem perlu mencatat identitas, tindakan, objek, waktu, nilai sebelum dan sesudah perubahan, hasil, serta correlation ID bila transaksi melintasi integrasi.
Bagaimana Menangani Konflik yang Tidak Bisa Dihindari?
Pada cabang kecil atau tim dengan personel terbatas, pemisahan penuh mungkin tidak praktis. Kondisi ini bukan alasan untuk mengabaikan risiko. Gunakan kontrol kompensasi yang jelas: review harian oleh atasan, laporan pengecualian, pembatasan nominal, dual authorization, rekonsiliasi independen, atau akses berjangka yang otomatis kedaluwarsa.
Setiap pengecualian sebaiknya memiliki pemilik risiko, alasan bisnis, ruang lingkup, kontrol kompensasi, bukti review, dan tanggal evaluasi ulang. SAP memperingatkan bahwa aturan organisasi yang dirancang keliru dapat menyaring terlalu banyak temuan dan menghasilkan false negative. Karena itu, pengecualian perlu diuji, bukan sekadar dicatat.
Roadmap Implementasi 90 Hari
Hari 1–30: Inventaris dan prioritas risiko
- Inventaris pengguna, role, privilege, service account, serta akses aplikasi terkait.
- Pilih tiga sampai lima proses paling material, misalnya pembayaran, pengadaan, persediaan, payroll, dan jurnal.
- Susun matriks aktivitas berkonflik bersama process owner, finance, internal control, dan IT.
- Identifikasi akses dorman, role ganda, shared account, serta approval yang dapat dilakukan sendiri.
Hari 31–60: Remediasi dan workflow
- Pecah role yang terlalu luas dan tetapkan lingkup organisasi atau nilai transaksi.
- Perbaiki alur maker-checker, self-approval, delegasi, dan akses darurat.
- Tentukan kontrol kompensasi untuk konflik yang diterima sementara.
- Uji perubahan bersama pengguna agar kontrol tidak memutus operasional yang sah.
Hari 61–90: Monitoring dan governance
- Jalankan review akses berkala dan analisis konflik saat provisioning atau perubahan role.
- Bangun laporan pengecualian untuk akses, transaksi, dan override berisiko.
- Tetapkan SLA remediasi, pemilik kontrol, serta bukti persetujuan pengecualian.
- Masukkan skenario SoD ke UAT ERP sebelum go-live dan regression test setelah perubahan role.
Checklist Evaluasi Segregation of Duties ERP
- Apakah proses kritis sudah memiliki process owner dan risk owner?
- Apakah konflik didefinisikan sampai tingkat aktivitas, bukan nama role saja?
- Apakah akses lintas aplikasi dan service account ikut diperiksa?
- Apakah sistem mencegah self-approval dan mencatat delegasi?
- Apakah akses sementara mempunyai tanggal kedaluwarsa?
- Apakah pengecualian memiliki kontrol kompensasi dan bukti review?
- Apakah perubahan pegawai memicu pencabutan akses lama?
- Apakah audit trail cukup untuk merekonstruksi transaksi?
- Apakah temuan diuji ulang setelah remediasi?
Sumber Acuan
Artikel ini menggunakan NIST SP 800-53 Rev. 5 kontrol AC-5 Separation of Duties, NIST SP 800-53A Rev. 5 untuk prinsip assessment kontrol, dokumentasi SAP Access Control tentang Segregation of Duties dan organization rules, serta dokumentasi Oracle Access Governance tentang preventive SoD analysis. Nama sumber dicantumkan tanpa tautan keluar.
Kesimpulan
Segregation of duties ERP bukan proyek merapikan role sekali selesai. Ini adalah kontrol berkelanjutan yang menghubungkan proses bisnis, akses, workflow approval, audit trail, monitoring, dan review berkala. Prioritas terbaik adalah memulai dari transaksi paling material, membuktikan konflik secara end-to-end, lalu memperluas kontrol berdasarkan risiko.
Perlu memetakan konflik akses sebelum implementasi atau perbaikan ERP?
Layana.ID dapat membantu memetakan proses, role, matriks SoD, workflow approval, kontrol kompensasi, dan kebutuhan audit trail sebagai bagian dari IT blueprint atau pengembangan sistem enterprise.
Diskusikan kebutuhan kontrol akses dan proses ERP perusahaan Anda.
FAQ
Apakah SoD sama dengan role-based access control?
Tidak. Role-based access control mengelompokkan izin berdasarkan peran. SoD mengevaluasi apakah kombinasi izin atau aktivitas dalam satu maupun beberapa role menciptakan konflik pada proses bisnis.
Apakah perusahaan kecil tetap membutuhkan SoD?
Ya, tetapi bentuknya dapat disesuaikan. Jika personel terbatas, perusahaan dapat memakai approval tambahan, pembatasan nilai, review independen, rekonsiliasi, atau laporan pengecualian sebagai kontrol kompensasi.
Kapan matriks SoD perlu ditinjau ulang?
Tinjau saat ada perubahan proses, modul, organisasi, integrasi, kewenangan, atau personel; setelah temuan audit atau insiden; serta secara berkala sesuai tingkat risiko perusahaan.