Arsitektur ERP untuk 100 pengguna (penjualan, gudang, produksi, pembelian, keuangan): hubungan komponen, keamanan akses, pencadangan, aliran data pembelian, potensi kegagalan, dan simulasi gangguan yang dicatat di database.
1. Hubungan pengguna, antarmuka aplikasi, server aplikasi, database, dan sistem pencadangan.
Gambar 4. Arsitektur teknis ERP tiga lapis untuk 100 pengguna
Alasan pemilihan rancangan
Tiga lapis: pengguna tidak pernah langsung ke database; semua lewat server aplikasi yang memeriksa login dan hak akses.
Dua server aplikasi + load balancer: 100 pengguna bersamaan butuh kapasitas dan tidak boleh bergantung pada satu server.
Database + replika (RAID 10): data keuangan tidak boleh hilang; replika siap mengambil alih.
Backup 3-2-1: melindungi dari kerusakan disk, kesalahan pengguna, ransomware, dan bencana lokasi.
VPN + MFA, HTTPS: pegawai di luar kantor tetap aman.
Mengapa pengguna gagal akses saat server aplikasi gangguan?
Semua permintaan harus melewati server aplikasi untuk login, otorisasi peran, dan logika bisnis. Bila server aplikasi mati dan tidak ada cadangan, tidak ada yang menerjemahkan permintaan ke database (single point of failure). Karena itu dipasang server standby dan load balancer.
2. Kebutuhan keamanan akses setiap departemen & matriks hak akses pengguna.
Departemen
Data yang diakses
Kebutuhan keamanan
Penjualan
Pesanan, pelanggan, stok siap jual
Hanya buat/ubah pesanan sendiri; tidak boleh mengubah harga pokok atau jurnal.
Gudang
Stok, penerimaan, pengiriman
Hanya input penerimaan/pengiriman terhadap dokumen resmi (PO/DO); tidak boleh melihat laporan keuangan.
Produksi
BOM, Work Order, pemakaian bahan
Ubah jadwal produksi; hanya lihat stok; membuat PR bahan, tidak membuat PO.
Pembelian
PR, PO, pemasok
Buat/ubah PO; PO di atas Rp 5 juta menunggu persetujuan Pimpinan; tidak boleh memposting pembayaran.
Keuangan
Jurnal, buku besar, piutang/utang
Akses terbatas & paling sensitif; hanya Keuangan yang posting jurnal; wajib audit trail.
Prinsip Least Privilege & Separation of Duties (SoD): Setiap peran dibatasi hanya pada wewenang tugasnya. Staf non-keuangan dilarang keras memposting jurnal akuntansi.
Keterangan Wewenang: L = Lihat • B = Buat • E = Edit • S = Setujui • P = Posting Jurnal • — = Tanpa Akses
Peran / Jabatan (Role)
Penjualan
Gudang
Produksi
Pembelian
Keuangan
Pengaturan Sistem
Staf Penjualan
L, B, E
L (Cek Stok)
L (Status)
—
—
—
Staf Gudang
L (Kirim DO)
L, B, E (GR)
L
L (PO Masuk)
—
—
Staf Produksi
—
L
L, B, E
L, B (PR Bahan)
—
—
Staf Pembelian
—
L
L
L, B, E (PO)
L (Status Bayar)
—
Staf Keuangan
L (Faktur Jual)
L
—
L (Faktur Beli)
L, B, E, P
—
Pimpinan / Direktur
L
L
L
L, S (PO > 5Jt)
L, S (Lap. Keu)
—
Administrator IT
—
—
—
—
—
L, B, E (User/DB)
3. Pencadangan database dan prosedur pemulihan data.
Strategi Pencadangan 3-2-1
3 Salinan Data: 1 database produksi aktif, 1 salinan lokal di storage NAS, 1 salinan offsite di cloud.
2 Media Berbeda: SSD Server Array RAID-10 dan Cloud Storage Terenkripsi.
1 Salinan di Luar Lokasi: Pusat data terpisah untuk mengantisipasi bencana fisik gedung.
Jadwal: Full Backup tiap Minggu malam, Differential Backup harian, dan log transaksi tiap 15 menit.
Target Pemulihan: RPO = 15 menit; RTO = 4 jam.
Prosedur Pemulihan (Disaster Recovery)
Hentikan transaksi dan bekukan sesi pengguna agar integritas data terjaga.
Identifikasi sumber kerusakan (kerusakan disk, korupsi data, atau malware).
Pulihkan full backup terakhir ke server pengganti.
Terapkan differential backup dan roll-forward log transaksi hingga titik waktu sebelum insiden.
Verifikasi integritas saldo buku besar, neraca saldo, dan saldo fisik gudang.
Buka kembali akses bertahap dimulai dari staf kunci.
4. Aliran data saat pengguna melakukan transaksi pembelian.
Gambar 5. Aliran data transaksi pembelian dari pengguna sampai database
5. Potensi kegagalan teknis dan dampaknya terhadap operasional (minimal tiga; di sini lima).
No
Potensi kegagalan
Dampak operasional
Pencegahan
1
Server aplikasi mati (SPOF)
100 pengguna tidak bisa transaksi; pengiriman & produksi tertunda.
Server standby + load balancer, monitoring.
2
Database rusak / disk gagal
Seluruh data transaksi tidak tersedia; laporan keuangan terhenti.
RAID 10, replika, backup 3-2-1.
3
Jaringan / internet terputus
Pegawai jarak jauh tidak bisa akses; transaksi gagal terkirim.
LAN internal, ISP cadangan, retry transaksi.
4
Backup gagal / tidak teruji
Data hilang permanen saat bencana.
Alarm kegagalan backup, uji restore berkala.
5
Akses tidak sah / hak akses terlalu luas
Kebocoran & manipulasi data keuangan.
RBAC, MFA, audit log, least privilege.
Simulasi gangguan — dosen memilih satu kondisi; sistem mencatat tindakan penanganannya ke audit log. Simulasi ini aman: tidak mematikan server dan tidak menghapus database.
Kondisi
Tindakan penanganan
1. Database tidak dapat diakses
Failover ke database replika (standby); server aplikasi diarahkan ke replika; transaksi baru ditahan beberapa menit lalu dibuka kembali. Jika replika ikut rusak: restore full backup + diff + log transaksi (RPO 15 menit, RTO 4 jam).
2. Server aplikasi mengalami gangguan
Load balancer otomatis memindahkan pengguna ke server aplikasi cadangan (standby); server utama diperiksa log-nya dan diperbaiki; sesi pengguna login ulang.
3. Koneksi internet terputus
Pengguna kantor tetap berjalan lewat LAN internal (server on-premise). Pengguna jarak jauh beralih ke jalur ISP cadangan/hotspot lewat VPN. Transaksi yang gagal dikirim disimpan sementara lalu dikirim ulang (retry).
4. Pengguna tidak berwenang membuka menu keuangan
Sistem menolak (HTTP 403) berdasarkan matriks RBAC, menampilkan pesan "akses ditolak", dan mencatat percobaan di audit log. Percobaan berulang memicu notifikasi ke Administrator IT.
5. Data transaksi hilang akibat backup tidak berjalan
Hentikan transaksi, cari backup valid terakhir (NAS lalu cloud), pulihkan full backup + differential + log transaksi, verifikasi neraca saldo & stok fisik. Perbaiki jadwal backup dan pasang alarm kegagalan backup.
Pengujian Kontrol Hak Akses (RBAC Enforcement)
Simulasikan apakah sistem menolak akses pengguna yang tidak memiliki wewenang pada modul tertentu.
