00 — Ringkasan Eksekutif¶
Dibaca oleh: pemilik bisnis & calon ketua tim. Tidak perlu paham teknis dalam. Tujuan: memahami apa, kenapa, berapa lama, apa risikonya, dan tim seperti apa yang harus direkrut.
1. Situasi Saat Ini (Bahasa Sederhana)¶
Anda punya satu aplikasi inti yang menjalankan bisnis selama ±20 tahun. Aplikasi itu tumbuh mengikuti kebutuhan, tanpa rencana besar di awal. Akibatnya:
- Database punya 183 objek = 120 tabel + 63 view. Nama seperti
barang,barang_mini,baranglengkapbukan tabel kembar — itu view (jendela tampilan) yang sengaja dibuat agar data mudah ditampilkan. Itu praktik yang baik. Data barang sesungguhnya hanya di satu tabel (brg). Yang perlu dirapikan bukan "duplikasi tabel", melainkan penamaan & dokumentasi. - Nama tabel & kolom sangat singkat:
t,d,s,j,brg,ktk,kdtrans,norek,jharga. Hanya pembuatnya yang hafal artinya. - Hampir semua logika bisnis bersembunyi di dalam database (sekitar 100 trigger dan 150 prosedur). Ini sebetulnya pilihan yang bagus (cepat & konsisten), tetapi tidak terdokumentasi, sehingga sulit diwariskan.
- Datanya nyata dan besar: hampir 200 ribu transaksi, 850 ribu baris detail, 590 ribu baris jurnal akuntansi. Ini bukan mainan — ini buku besar perusahaan.
Inti masalahnya bukan "databasenya jelek". Strukturnya sebenarnya cerdas untuk zamannya. Masalahnya: pengetahuannya ada di kepala satu orang, dan teknologinya (MySQL latin1, penamaan singkat, ID dibuat manual) menyulitkan orang lain ikut bekerja.
2. Sasaran (Apa yang Ingin Dicapai)¶
| Sasaran | Ukuran keberhasilan |
|---|---|
| Sistem bisa dibaca tim | Pegawai baru paham alur transaksi inti dalam ≤ 1 minggu dari dokumen ini |
| Teknologi modern | PostgreSQL, UTF-8, ID otomatis, skema bernama jelas |
| Logika tetap terkontrol | Stok, HPP FIFO, jurnal tetap di DB (trigger), tetapi terdokumentasi penuh |
| Siap multi-tenant | 1 database erp, 1 schema per tenant/bidang usaha, struktur tenant sama |
| Bisa didelegasikan | Ada standar penamaan, alur kerja, dan onboarding tertulis |
Yang TIDAK diubah: model bisnisnya. FIFO tetap FIFO. Jurnal tetap jurnal. Aturan akuntansinya tidak diutak-atik — hanya dirapikan dan dipindah ke PostgreSQL.
3. Rekomendasi Teknologi (Anda minta saya merekomendasikan)¶
Karena keputusan sudah dibuat bahwa logika bisnis tetap di database (trigger-first), peran "backend" menjadi relatif tipis: dia hanya menangani login, pemilihan tenant, keamanan, dan menyajikan data lewat API (untuk Flutter mobile & web ke depan). Logika berat (stok, HPP, jurnal) tetap di PostgreSQL. Ini menyederhanakan pilihan.
Rekomendasi utama¶
| Lapisan | Rekomendasi | Alasan |
|---|---|---|
| Database | PostgreSQL 16+ | Sudah diputuskan. Matang, gratis, kuat untuk akuntansi & trigger PL/pgSQL. |
| Backend API | Node.js + TypeScript (NestJS) | Anda sudah punya backend Node untuk Flutter — lanjutkan, jangan tambah bahasa baru. TypeScript membuat kode lebih aman & mudah dibaca tim. NestJS memberi struktur jelas (mudah onboarding). Kolam SDM besar di Indonesia. |
| Autentikasi | Firebase Auth (Google/email/MFA) | Rencana Anda; tepat. Hapus utang "password plaintext" lama. authN di Firebase, authZ di kontrol (Dokumen 10). |
| Notifikasi push | Firebase Cloud Messaging (FCM) | Push Android terkuat; dipicu pg_notify dari trigger → backend relai (tetap trigger-first). |
| Mobile | Flutter (tetap) | Sudah berjalan. Grid kaya: Syncfusion Flutter DataGrid. |
| Desktop | Delphi — di-sunset, bukan dimodernkan | Biarkan akses DB langsung apa adanya selama transisi; jangan investasi meng-API-kan Delphi; ganti dengan klien baru (Dokumen 10 §5). |
| Web (baru) | DevExtreme / DevExpress Blazor | Tetap ekosistem DevExpress yang Anda kuasai (lookup, kolom custom) → kurva belajar dari TdxDBGrid paling landai. |
Mengapa Node.js + TypeScript, bukan PHP/Laravel atau yang lain?
- Anda sudah memakai Node untuk backend Flutter. Menambah bahasa baru = menambah jenis pegawai yang harus direkrut. Satu bahasa di backend & web = tim lebih kecil, lebih murah, lebih mudah saling membantu.
- TypeScript "memaksa" kode lebih rapi dan ber-tipe — ini langsung mendukung tujuan Anda: bisa dibaca & didelegasikan.
- Logika berat ada di PostgreSQL, jadi kelemahan klasik Node (kalkulasi berat) tidak relevan di sini.
Catatan jujur: Jika nanti Anda kesulitan merekrut orang Node berkualitas di kota Anda, PHP + Laravel adalah alternatif yang sangat layak (kolam SDM terbesar di Indonesia, ramah hosting cPanel). Itu pilihan B yang aman. Yang tidak disarankan: menambah 3-4 bahasa backend berbeda untuk proyek yang sama.
Satu prinsip yang harus dipegang: berhenti akses database langsung dari aplikasi¶
Saat ini Delphi desktop "menembak" database langsung. Ini sumber kerapuhan terbesar untuk delegasi. Tetapi solusinya BUKAN meng-API-kan Delphi (itu rumit & sia-sia). Solusinya: Delphi dipensiunkan, diganti klien baru yang API-first. Target:
Klien baru (Web DevExtreme) ─┐
Flutter mobile ─┼─► 1 Backend API (Node/TS) ─► PostgreSQL (trigger)
(AI / chat / notifikasi) ─┘ ▲ Firebase Auth + FCM
Delphi lama (transisi, direct DB lama) ┄┄┄┘ ← dibiarkan apa adanya lalu disetop
Klien baru bicara ke satu pintu (API); Delphi lama tidak diutak-atik, hanya dijalankan sampai digantikan, lalu disetop modul demi modul. Detail strategi sunset + pengganti grid DevExpress ada di Dokumen 10.
Tim yang perlu direkrut (gambaran)¶
| Peran | Jumlah awal | Keahlian inti |
|---|---|---|
| Database Engineer (PostgreSQL) | 1 (kunci) | PL/pgSQL, akuntansi/inventory, baca trigger lama |
| Backend Engineer (Node/TS) | 1–2 | NestJS, REST/JSON, autentikasi, multi-tenant |
| Mobile (Flutter) | 1 | Sudah ada, lanjutkan |
| Desktop (Delphi) | sesuai kebutuhan | Untuk transisi & arahkan ke API |
Orang paling kritis di awal adalah Database Engineer yang sanggup membaca trigger lama dan menulis ulang di PL/pgSQL dengan rapi. Dokumen 01, 02, dan 05 dibuat khusus untuk mempercepat orang ini.
4. Strategi Migrasi (Ringkas)¶
Sudah diputuskan: big-bang cutover — pindah sekali jalan pada jendela downtime terjadwal (mis. akhir pekan / tutup buku). Detail lengkap di Dokumen 06.
Garis besar:
- Bangun skema baru PostgreSQL yang rapi & bernama jelas (Dokumen 03).
- Port logika stok/HPP/jurnal ke PL/pgSQL + uji dengan data nyata (Dokumen 05).
- Tulis skrip ETL (pindah data lama → struktur baru) + aturan transformasi.
- Latihan migrasi (dry-run) berulang di server uji sampai angka cocok 100%.
- Hari-H: bekukan sistem lama → jalankan migrasi → rekonsiliasi (stok, saldo piutang/hutang, neraca harus sama persis) → buka sistem baru.
- Rencana mundur disiapkan: jika rekonsiliasi gagal, kembali ke sistem lama.
Aturan emas: cutover hanya boleh dilakukan jika rekonsiliasi 100% cocok. Tidak ada "nanti diperbaiki sambil jalan" untuk data akuntansi.
5. Risiko Utama & Penanganannya¶
| Risiko | Dampak | Penanganan |
|---|---|---|
| Logika tersembunyi di 150 prosedur tak terdokumentasi | Fitur diam-diam hilang setelah pindah | Dokumen 05 memetakan logika inti; sisanya diinventaris sebelum cutover |
ID transaksi dibuat manual (max(id)+1) |
Bentrok ID / data ganda saat ramai | Diganti BIGINT GENERATED ALWAYS AS IDENTITY (otomatis & aman) di skema baru |
| Big-bang = tidak ada jaring pengaman langsung | Jika gagal, bisnis berhenti | Wajib dry-run berulang + rencana rollback + jendela downtime cukup |
| Pengetahuan hanya di kepala pemilik | Tim macet saat pemilik tak ada | Justru ini yang dipecahkan dokumen-dokumen ini |
| Data 10 tahun mungkin "kotor" (tak konsisten) | Rekonsiliasi gagal | Tahap pembersihan data masuk dalam rencana migrasi |
6. Estimasi Kasar (untuk perencanaan, bukan janji)¶
| Fase | Perkiraan | Catatan |
|---|---|---|
| Audit + desain skema baru | 3–5 minggu | Dokumen 01–04 mempercepat ini |
| Port logika ke PL/pgSQL + uji | 6–10 minggu | Bagian terberat; tergantung 1 DB engineer kuat |
| Skrip ETL + dry-run berulang | 4–6 minggu | Paralel sebagian dengan port logika |
| Penyesuaian backend/API & aplikasi | 4–8 minggu | Tergantung keputusan stack |
| Stabilisasi + rekonsiliasi + cutover | 2–3 minggu |
Total realistis: ±4–7 bulan dengan tim kecil yang fokus. Angka ini akan dipertajam setelah inventarisasi 150 prosedur selesai (lihat Dokumen 01 §Tindak Lanjut).
7. Apa yang Perlu Anda Putuskan Selanjutnya¶
- Setujui rekomendasi stack (atau pilih alternatif PHP/Laravel) → menentukan rekrutmen.
- Tunjuk 1 Database Engineer sebagai pemilik teknis migrasi.
- Tentukan jendela downtime untuk big-bang (idealnya saat tutup buku bulanan).
- Setujui prinsip "klien baru lewat API; Delphi di-sunset, bukan di-API-kan" (Dokumen 10).
Keputusan arsitektur lanjutan yang sudah disepakati (rinci di Dokumen 08):
Bagan Akun standar terpusat (konsolidasi tanpa mapping), kdpc dipensiunkan,
login disatukan (opr+inet→satu identitas), devisi→cabang. Tim tidak perlu
memutuskan ulang hal ini — cukup melaksanakan.
Setelah itu, tim mulai dari Dokumen 01.