Merancang dan Menguji Arsitektur Teknis ERP
Indikator: arsitektur teknis ERP. Studi kasus: perusahaan dengan 100 pengguna di bagian penjualan, gudang, produksi, pembelian, dan keuangan.
1. Diagram Arsitektur
flowchart TB U["Pengguna
Penjualan, Gudang, Produksi,
Pembelian, Keuangan"] UI["Antarmuka Aplikasi
(browser / klien ERP)"] FW["Jaringan LAN / VPN
+ Firewall"] APP["Server Aplikasi
logika ERP, autentikasi, hak akses"] DB[("Server Database
data transaksi")] BK[("Penyimpanan Cadangan
lokal + offsite/cloud")] U --> UI --> FW --> APP --> DB DB -- "backup terjadwal otomatis" --> BK
Alur utama: pengguna → antarmuka → jaringan/firewall → server aplikasi → database. Database dicadangkan otomatis ke penyimpanan terpisah.
Fungsi tiap komponen
| Komponen | Fungsi |
|---|---|
| Pengguna | Menjalankan transaksi sesuai peran departemen |
| Antarmuka aplikasi | Tampilan untuk input dan melihat data (browser atau klien ERP) |
| LAN / VPN + Firewall | Menghubungkan pengguna ke server; firewall menyaring lalu lintas, VPN mengamankan akses dari luar |
| Server aplikasi | Menjalankan logika bisnis ERP, memeriksa login dan hak akses, memvalidasi transaksi |
| Server database | Menyimpan seluruh data transaksi dan data master |
| Penyimpanan cadangan | Menyimpan salinan data untuk pemulihan saat terjadi kerusakan atau kehilangan data |
2. Kebutuhan Keamanan Akses Tiap Departemen
| Peran | Penjualan | Gudang | Produksi | Pembelian | Keuangan |
|---|---|---|---|---|---|
| Staf Penjualan | RW | R | - | - | - |
| Staf Gudang | R | RW | R | R | - |
| Staf Produksi | R | R | RW | - | - |
| Staf Pembelian | - | R | R | RW | R |
| Staf Keuangan | R | R | - | R | RW |
| Manajer | Approve | Approve | Approve | Approve | Approve |
Keterangan: R = hanya lihat, RW = lihat dan ubah, Approve = menyetujui transaksi. Prinsipnya least privilege: setiap peran hanya mendapat akses yang dibutuhkan pekerjaannya.
3. Pencadangan dan Pemulihan Data
| Aspek | Rancangan |
|---|---|
| Full backup | Harian, malam hari |
| Incremental backup | Setiap jam |
| Lokasi salinan | Lokal dan offsite/cloud |
| Pemantauan | Notifikasi otomatis jika backup gagal |
| Uji pemulihan | Berkala (misalnya bulanan) di lingkungan uji |
| Target RPO | Maksimal 1 jam data hilang |
| Target RTO | Sistem pulih maksimal 4 jam |
Prosedur pemulihan
- Pastikan penyebab kerusakan dan hentikan akses pengguna.
- Restore full backup terakhir ke server database (atau lingkungan uji dulu).
- Terapkan backup incremental secara berurutan sampai titik terbaru.
- Verifikasi integritas data (jumlah transaksi, saldo, stok).
- Buka kembali akses pengguna dan catat kejadian.
4. Aliran Data Transaksi Pembelian
sequenceDiagram
actor U as Staf Pembelian
participant UI as Antarmuka
participant A as Server Aplikasi
participant D as Database
participant M as Manajer
U->>UI: Login dan buka menu pembelian
UI->>A: Kirim kredensial
A->>A: Periksa hak akses
U->>UI: Input Purchase Order
UI->>A: Kirim data PO
A->>A: Validasi (stok, anggaran, pemasok)
A->>D: Simpan PO (status menunggu persetujuan)
A-->>M: Notifikasi persetujuan
M->>A: Setujui PO
A->>D: Perbarui status PO
A-->>UI: Konfirmasi ke pengguna
4A. Input Purchase Order (Terhubung Database)
Simulasi alur pada diagram di atas: staf pembelian menginput PO, sistem menyimpannya dengan status Menunggu Persetujuan, lalu manajer menyetujui atau menolak. Data tersimpan di database.
Form Purchase Order (Staf Pembelian)
Daftar Purchase Order (Persetujuan Manajer)
| No. PO | Pemasok | Bahan | Jumlah | Total | Status | Aksi |
|---|---|---|---|---|---|---|
| Memuat data... | ||||||
5. Potensi Kegagalan Teknis dan Dampaknya
| Potensi kegagalan | Dampak operasional |
|---|---|
| Server aplikasi mati (single point of failure) | Seluruh pengguna tidak bisa bekerja walaupun database aktif |
| Database rusak atau tidak bisa diakses | Transaksi berhenti, ada risiko kehilangan data |
| Backup gagal tanpa terpantau | Data tidak bisa dipulihkan saat dibutuhkan |
| Jaringan atau internet putus | Akses terputus, terutama untuk pegawai yang bekerja jarak jauh |
Simulasi Gangguan
Database tidak dapat diakses
- Cek koneksi jaringan dan status layanan database.
- Jika ada replika, alihkan (failover) ke replika.
- Jika tidak ada, restore dari backup terakhir di lingkungan uji dulu, lalu produksi.
- Beri tahu pengguna dan catat waktu gangguan.
Server aplikasi mengalami gangguan
- Restart layanan aplikasi dan periksa log kesalahan.
- Jika gagal, alihkan ke server cadangan (jika tersedia).
- Data tetap aman karena tersimpan di database, bukan di server aplikasi.
Koneksi internet terputus
- Pegawai di kantor tetap bekerja lewat LAN karena server berada di jaringan lokal.
- Pegawai jarak jauh menunggu atau memakai jalur cadangan (ISP kedua).
- Hubungi penyedia layanan dan informasikan estimasi pemulihan.
Pengguna tidak berwenang membuka menu keuangan
- Sistem menolak akses berdasarkan peran (matriks hak akses).
- Percobaan dicatat di log audit (siapa, kapan, menu apa).
- Admin menelusuri log, memastikan tidak ada kebocoran, lalu menindaklanjuti sesuai kebijakan.
Data hilang karena backup tidak berjalan
- Selidiki penyebab kegagalan jadwal backup.
- Pulihkan dari backup valid terakhir, lalu input ulang transaksi dari dokumen sumber.
- Jalankan backup manual segera, perbaiki penjadwalan, dan pasang alert kegagalan.
Pelajaran
Backup harus dipantau dan diuji pemulihannya secara berkala, bukan hanya dijadwalkan.
Alasan Pemilihan Rancangan
- Pemisahan server aplikasi dan database memudahkan pengamanan dan penambahan kapasitas.
- Firewall dan VPN melindungi akses dari luar kantor.
- Hak akses berbasis peran membatasi risiko penyalahgunaan data.
- Backup otomatis dengan salinan offsite menurunkan risiko kehilangan data.
Kelemahan yang disadari
Server aplikasi tunggal masih menjadi titik kegagalan. Jika anggaran memungkinkan, tambahkan server aplikasi kedua dengan load balancer.
Bukti yang Dikumpulkan
- Diagram arsitektur (bagian 1)
- Matriks hak akses pengguna (bagian 2)
- Rencana pencadangan dan pemulihan (bagian 3)
- Hasil simulasi gangguan (bagian simulasi)
- Penjelasan alasan pemilihan rancangan (bagian terakhir)