Prodi Bisnis Digital · FEB UNDIP

Perencanaan Sumber Daya Perusahaan

Teknologi ERP: Arsitektur, RDBMS, Normalisasi Database, SQL, Konfigurasi vs Kustomisasi, Cloud Computing

Fondasi teknis di balik satu sistem ERP — bagaimana data disimpan, diorganisasi, ditanya, dan dijalankan di server sendiri atau di awan.

RPS minggu 2 · 2x50 menit

Tujuan Pembelajaran Hari Ini

Memahami

Arsitektur

Bagaimana ERP disusun dari lapisan presentasi, aplikasi, dan basis data (3-tier), serta mengapa satu database terpusat adalah inti dari integrasi ERP.

Menguasai

RDBMS & SQL

Konsep tabel, kunci, normalisasi database, dan dasar perintah SQL (SELECT) untuk mengambil data dari database ERP.

Mengevaluasi

Konfigurasi vs Kustomisasi

Trade-off biaya, risiko, dan kecepatan implementasi antara menyetel opsi bawaan versus menulis ulang kode ERP.

Membandingkan

Cloud Computing

Model SaaS/PaaS/IaaS dan implikasinya bagi keputusan ERP on-premise vs cloud perusahaan Indonesia.

Mengapa "Di Balik Layar" ERP Penting?

Saat staf gudang input barang masuk di layar ERP, dan lima detik kemudian laporan keuangan CFO ikut berubah — apa yang sebenarnya terjadi?

Jawabannya bukan sihir. Semua modul ERP (Sales, Inventory, Finance) membaca dan menulis ke satu database yang sama. Tanpa memahami cara database ini disusun (RDBMS, normalisasi) dan cara data diambil (SQL), Anda sebagai calon manajer bisnis akan sulit menilai kualitas sistem ERP yang ditawarkan vendor, atau memahami mengapa kustomisasi berlebihan bisa "meledakkan" biaya proyek.

Kasus nyata: banyak proyek ERP di perusahaan Indonesia molor dan membengkak biaya karena tim proyek memutuskan kustomisasi besar-besaran tanpa memahami dampaknya pada struktur database dan proses upgrade di masa depan.

Bagian 1 dari 3

Arsitektur ERP & Fondasi Database

Bagaimana ERP disusun berlapis, dan mengapa satu database terpusat adalah jantung dari seluruh integrasi.

Arsitektur 3-Tier ERP

ERP modern umumnya disusun dalam tiga lapisan (tier) yang terpisah namun saling terhubung.

Pemisahan ini membuat ERP lebih mudah dipelihara: perubahan tampilan tidak mengganggu logika bisnis, dan perubahan database tidak mengganggu tampilan — selama "jembatan" antar-lapisan tetap konsisten.

Database Terpusat: Jantung Integrasi ERP

Sebelum ERP (Sistem Silo)

Setiap departemen punya database/file sendiri
Data stok gudang beda dengan data stok di sistem keuangan
Rekonsiliasi manual, sering telat & salah

Dengan ERP (Database Terpusat)

Satu Single Source of Truth (SSOT) untuk seluruh perusahaan
Modul Sales, Inventory, Finance baca-tulis ke tabel yang sama
Update di satu titik langsung terlihat di modul lain

Inilah alasan utama perusahaan investasi ERP: bukan sekadar aplikasi baru, tapi satu sumber data tunggal yang menghilangkan duplikasi dan inkonsistensi antar-departemen.

Coba Sendiri: Satu Database, Banyak Sudut Pandang

Jelajahi bagaimana modul Sales, Inventory, dan Finance melihat "sudut pandang" berbeda dari satu database fisik yang sama, mengikuti arsitektur 3-level.

RDBMS: Cara Data ERP Disimpan

RDBMS (Relational Database Management System) adalah perangkat lunak yang menyimpan data dalam bentuk tabel-tabel yang saling berelasi — mirip lemari arsip dengan banyak map, tapi map-map itu bisa saling "menunjuk" satu sama lain.

Tabel (Table)

Entitas

Contoh: tabel Pelanggan, tabel Produk, tabel Transaksi.

Baris (Row)

Record

Satu baris = satu data spesifik, mis. satu pelanggan bernama Budi.

Kolom (Column)

Atribut

Sifat dari entitas, mis. nama, alamat, no. telepon.

Contoh RDBMS populer di dunia ERP: Oracle Database, Microsoft SQL Server, PostgreSQL, dan MySQL. SAP dan Oracle ERP Cloud umumnya berjalan di atas salah satu mesin ini.

Primary Key & Foreign Key: "Perekat" Antar-Tabel

Primary Key (PK)

ID Unik

Penanda unik tiap baris dalam satu tabel, tidak boleh sama atau kosong.

Foreign Key (FK)

Penghubung

Kolom di satu tabel yang "menunjuk" ke Primary Key tabel lain — inilah relasi.

Coba Sendiri: Menyusun JOIN dari PK ke FK

Hubungkan Primary Key tabel Pelanggan dengan Foreign Key tabel Transaksi, lalu lihat bagaimana JOIN menghasilkan satu laporan gabungan.

Masalah Tanpa Normalisasi: Redundansi & Anomali

Bayangkan satu tabel besar yang mencampur data pelanggan dan transaksi tanpa dipisah:

Tabel Transaksi (Belum Ternormalisasi)

ID_Transaksi	Nama Pelanggan	Kota	Produk
T101	Budi	Semarang	Kemeja
T102	Budi	Semarang	Celana
T103	Budi	Semarang	Jaket

Redundansi: nama dan kota Budi diulang 3 kali. Anomali update: kalau Budi pindah kota, staf harus mengubah data di banyak baris — kalau satu baris terlewat, data jadi tidak konsisten.

Hitung dari Nol: Normalisasi Bertahap (1NF → 3NF)

Tahap	Aturan yang Diterapkan	Hasil
1NF	Hilangkan grup berulang; tiap sel hanya 1 nilai	Tabel Transaksi flat, tanpa daftar produk dalam satu sel
2NF	Hilangkan dependensi parsial pada sebagian kunci	Pisah data Pelanggan (Nama, Kota) ke tabel Pelanggan sendiri
3NF	Hilangkan dependensi transitif (kolom bergantung pada kolom non-kunci lain)	Pisah data Produk (Nama, Harga) ke tabel Produk sendiri

Hasil Akhir 3NF

3 Tabel

Pelanggan · Produk · Transaksi (terhubung via PK–FK)

Mari kita telusuri langkah demi langkah, karena ini konsep yang sering membingungkan mahasiswa baru. 1NF, atau First Normal Form, mewajibkan setiap sel dalam tabel hanya berisi satu nilai — tidak boleh ada sel berisi "Kemeja, Celana, Jaket" sekaligus. 2NF melangkah lebih jauh: kita pisahkan data yang sebenarnya milik entitas lain, seperti nama dan kota pelanggan, ke tabel Pelanggan tersendiri, supaya tidak berulang di setiap transaksi. 3NF menyempurnakan dengan memisahkan data produk, seperti harga, ke tabel Produk sendiri, karena harga bergantung pada produk, bukan pada transaksi. Hasil akhirnya adalah 3 tabel yang rapi dan saling terhubung lewat primary key dan foreign key yang sudah kita bahas sebelumnya. Ini persis yang terjadi di balik layar SAP atau Oracle setiap kali Anda mendesain modul baru.

Coba Sendiri: Normalisasi Tabel Langkah demi Langkah

Klik tombol 1NF, 2NF, lalu 3NF dan amati bagaimana satu tabel besar pecah menjadi tabel-tabel kecil yang saling berelasi.

Trade-off Normalisasi: Kapan Berhenti?

Langkah 1 — Manfaat Normalisasi

Mengurangi redundansi & risiko anomali
Data lebih konsisten & hemat ruang
Update cukup di satu tempat

Langkah 2 — Biaya Normalisasi Berlebihan

Terlalu banyak tabel → query harus "menggabungkan" (JOIN) banyak tabel
JOIN yang kompleks memperlambat laporan besar
ERP modern kadang sengaja denormalisasi sebagian untuk laporan cepat

Praktik umum: desainer database ERP menormalisasi hingga 3NF untuk data transaksional, tetapi membuat tabel ringkasan terpisah (data warehouse) yang lebih "flat" khusus untuk pelaporan dan analitik.

Bagian 2 dari 3

SQL: Bahasa untuk "Bertanya" ke Database

Dari tabel yang sudah rapi ternormalisasi, sekarang kita belajar cara mengambil informasi darinya.

SQL: Structured Query Language

SQL adalah bahasa standar untuk berkomunikasi dengan RDBMS — mengambil, menambah, mengubah, atau menghapus data. Setiap laporan yang Anda lihat di layar ERP sebenarnya adalah hasil dari perintah SQL yang dijalankan di belakang layar.

SELECT kolom FROM tabel WHERE kondisi;

SELECT

Ambil

Kolom mana yang ingin ditampilkan

FROM

Sumber

Dari tabel mana data diambil

WHERE

Saring

Kondisi/filter data yang dicari

Coba Sendiri: Susun Perintah SELECT-WHERE-ORDER BY

Ubah kondisi WHERE dan urutan ORDER BY, lalu amati bagaimana hasil baris data ikut berubah secara langsung.

Contoh: Query SQL di Tabel Transaksi

Kasus: Cari Semua Transaksi Pelanggan "Budi"

SELECT ID_Transaksi, Total
FROM Transaksi
WHERE ID_Pelanggan = 'P001';

ID_Transaksi	Total
T101	Rp250.000
T102	Rp180.000

Perintah JOIN dipakai saat kita perlu menggabungkan informasi dari lebih dari satu tabel — misalnya menampilkan nama Budi (dari tabel Pelanggan) bersama total transaksinya (dari tabel Transaksi) dalam satu laporan.

Coba Sendiri: Agregasi Data dengan GROUP BY

Kelompokkan data transaksi berdasarkan kota atau produk, lalu lihat bagaimana SUM/COUNT menghasilkan satu baris ringkasan per kelompok.

Hitung dari Nol: Dampak Kustomisasi pada Waktu Implementasi

Sebuah UMKM naik kelas mengimplementasi ERP dasar dengan estimasi awal 100 hari kerja. Setiap modul yang dikustomisasi menambah 15% waktu dari estimasi dasar.

Langkah	Perhitungan	Nilai
Estimasi dasar (konfigurasi murni)	Diberikan	100 hari
Tambahan akibat kustomisasi 2 modul	2 × 15% × 100	30 hari
Total estimasi waktu implementasi	100 + 30	130 hari
Kenaikan waktu terhadap rencana awal	30 / 100 × 100%	30%

Kesimpulan

+30% Waktu

Kustomisasi 2 modul memperpanjang proyek ~sepertiga dari rencana awal

Bagian 3 dari 3

Konfigurasi vs Kustomisasi, dan Cloud Computing

Dua keputusan strategis: seberapa jauh mengubah ERP, dan di mana ERP itu dijalankan.

Konfigurasi vs Kustomisasi

Konfigurasi (Configuration)

Menyetel opsi/parameter yang sudah disediakan vendor
Tidak mengubah kode program inti
Contoh: atur mata uang Rupiah, format tanggal, alur approval
Risiko rendah, mudah di-upgrade

Kustomisasi (Customization)

Menulis kode baru untuk mengubah fungsi inti ERP
Contoh: bikin modul khusus pelaporan pajak daerah
Biaya & waktu tinggi, sulit di-upgrade
Risiko: "vendor lock-in" pada konsultan tertentu

Prinsip umum vendor ERP: "konfigurasi sebisa mungkin, kustomisasi seperlunya" — karena tiap baris kode kustom harus diuji ulang setiap kali ERP di-upgrade ke versi baru.

Cloud Computing: Tiga Model Layanan

IaaS

Infrastruktur

Sewa server, storage, jaringan. Perusahaan install & kelola ERP sendiri di atasnya.

PaaS

Platform

Sewa lingkungan pengembangan siap pakai untuk membangun/menyesuaikan aplikasi ERP.

SaaS

Software

Sewa aplikasi ERP jadi, siap pakai lewat browser. Vendor kelola semua infrastruktur & update.

Mayoritas ERP untuk UMKM naik kelas di Indonesia (mis. Accurate Online, Jurnal by Mekari) memakai model SaaS — biaya berlangganan bulanan, tanpa perlu tim TI internal mengurus server.

Cloud computing itu seperti tinggal di apartemen sewa dibandingkan membangun rumah sendiri. Ada tiga tingkat "sewa" yang berbeda. IaaS mirip menyewa lahan kosong dengan listrik dan air sudah tersedia — Anda tetap harus bangun rumahnya sendiri, dalam hal ini menginstal ERP di server sewaan itu. PaaS mirip menyewa rumah setengah jadi yang tinggal Anda selesaikan interior dan tata letaknya, cocok untuk perusahaan yang ingin mengembangkan aplikasi tambahan di atas platform ERP. SaaS adalah yang paling praktis, mirip menyewa apartemen full furnished — Anda tinggal pakai lewat browser, semua perawatan, update, dan keamanan server jadi tanggung jawab vendor. Contoh nyata di Indonesia, banyak UMKM yang naik kelas memakai Accurate Online atau Jurnal dari Mekari, yang keduanya adalah ERP berbasis SaaS dengan biaya bulanan terjangkau.

On-Premise vs Cloud: Mana yang Dipilih?

Aspek	On-Premise	Cloud (SaaS)
Investasi awal (CAPEX)	Tinggi (beli server, lisensi)	Rendah (langsung pakai)
Biaya berjalan (OPEX)	Tim TI internal, perawatan server	Biaya langganan bulanan/tahunan
Kontrol data	Penuh, data di server sendiri	Bergantung kebijakan & lokasi server vendor
Kecepatan implementasi	Lebih lama (bangun infrastruktur)	Lebih cepat (tinggal aktivasi akun)
Skalabilitas	Terbatas kapasitas server fisik	Mudah, tinggal upgrade paket

Perusahaan dengan regulasi data ketat (mis. bank, BUMN strategis) sering tetap memilih on-premise atau private cloud demi kontrol penuh, sementara UMKM dan startup umumnya memilih SaaS demi kecepatan & biaya awal rendah.

Coba Sendiri: Bandingkan TCO On-Premise vs Cloud

Ubah skala perusahaan dan horizon waktu, lalu amati titik impas antara biaya on-premise (CAPEX besar di depan) dan cloud (OPEX berlangganan).

Rangkuman & Persiapan Minggu Depan

Cheat Sheet Hari Ini

Arsitektur 3-tier: presentasi, aplikasi, database
RDBMS: tabel + PK/FK sebagai perekat relasi
Normalisasi 1NF→3NF: kurangi redundansi & anomali
SQL: SELECT–FROM–WHERE untuk "bertanya" ke database
Konfigurasi murah & aman; kustomisasi mahal & berisiko
Cloud (IaaS/PaaS/SaaS) vs on-premise: trade-off kontrol vs kepraktisan

Minggu Depan

Pertemuan 3

Business Process Reengineering & Process Mapping — bagaimana proses bisnis didesain ulang sebelum diintegrasikan ke ERP. Baca ulang materi arsitektur & normalisasi minggu ini sebagai bekal.