Studi Kasus: Merancang Sistem IT Terintegrasi untuk Perusahaan Daerah
Pendahuluan
Merancang sistem IT terintegrasi untuk perusahaan daerah memiliki tantangan tersendiri: banyak modul yang harus saling terhubung, user yang beragam, dan kebutuhan deployment on-premise. Artikel ini membagikan pengalaman merancang sistem semacam ini dari perspektif System Analyst.
Konteks Proyek
Sebuah perusahaan daerah membutuhkan sistem IT terintegrasi yang mencakup operasional harian hingga pelaporan manajemen. Pengembangan dibagi menjadi 3 fase.
Fase 1: Operasional & Pelanggan
Modul-modul inti yang langsung bersentuhan dengan operasional:
- Bacameter — Mobile app (Android) untuk 10 petugas lapangan + web dashboard supervisor
- Billing — Pengelolaan tagihan berbasis data bacameter
- CRM (Hubungan Pelanggan) — Diakses oleh 31.000 pelanggan (200 aktif harian)
- Loket — Web app untuk 2 petugas pembayaran
- Litbang (Survey) — Dashboard untuk tim survey lapangan
- Perawatan — Manajemen jadwal maintenance infrastruktur
Fase 2: Manajemen & Logistik
- Dashboard Direktur — Summary laporan keuangan dan operasional
- Distribusi/Logistik — Pengelolaan supply chain
- Gudang — Inventaris dan purchase order
- Keuangan — Jurnal umum dan rekapitulasi
- Operasional — Logbook harian
Fase 3: Pendukung
- Akuntansi — Jurnal, buku besar, laporan keuangan
- Humas — Surat menyurat dan pengaduan
- Customer Service — Pelaporan dan web GIS
Arsitektur Sistem
Pendekatan arsitektur yang digunakan:
- Setiap modul berjalan sebagai Docker container independen
- Semua container mengakses satu central RDBMS
- Deploy on-premise pada rack server
Estimasi Kebutuhan Komputasi
Contoh: Arsitektur Sistem Terintegrasi (Container Diagram)
Visualisasi bagaimana setiap modul terhubung dalam arsitektur Docker on-premise:
flowchart TD
subgraph Server["Rack Server On-Premise"]
subgraph Fase1["Fase 1: Operasional"]
BACA["BacameternMobile + Web"]
BILL["Billing"]
CRM["CRMn31K pelanggan"]
LOKET["LoketnWeb App"]
SURVEY["LitbangnSurvey"]
MAINT["Perawatan"]
end
subgraph Fase2["Fase 2: Manajemen"]
DASH["Dashboard Direktur"]
DIST["Distribusi"]
GDG["Gudang"]
KEU["Keuangan"]
OPS["Operasional"]
end
subgraph Fase3["Fase 3: Pendukung"]
AKT["Akuntansi"]
HUMAS["Humas"]
CS["Customer Servicen+ Web GIS"]
end
DB[("CentralnRDBMS")]
end
BACA --> DB
BILL --> DB
CRM --> DB
LOKET --> DB
SURVEY --> DB
MAINT --> DB
DASH --> DB
DIST --> DB
GDG --> DB
KEU --> DB
OPS --> DB
AKT --> DB
HUMAS --> DB
CS --> DBContoh: Alur Bisnis Modul Bacameter (Sequence Diagram)
Bagaimana data mengalir dari petugas lapangan hingga menjadi tagihan:
sequenceDiagram
participant Petugas as Petugas Lapangan
participant App as Mobile App
participant API as API Server
participant DB as Database
participant Billing as Modul Billing
participant Supervisor
Petugas->>App: Input angka meter + foto
App->>App: Validasi GPS & timestamp
App->>API: POST /bacameter/reading
API->>DB: INSERT reading data
DB-->>API: OK
API-->>App: Sync berhasil
API->>Billing: Trigger kalkulasi tagihan
Billing->>DB: Hitung selisih pemakaian
Billing->>DB: Generate tagihan bulan ini
Billing-->>API: Tagihan created
Supervisor->>API: GET /bacameter/dashboard
API->>DB: Query ringkasan harian
DB-->>API: Data summary
API-->>Supervisor: Dashboard petugas + coveragePelajaran yang Didapat
- Fase-based delivery membantu mengelola ekspektasi klien
- Flowchart per modul wajib dibuat sebelum development dimulai
- C4 diagram sangat efektif untuk komunikasi arsitektur ke non-teknis
- SLA yang jelas (response 4 jam, critical fix 24 jam, uptime 99%) mencegah konflik
Ditulis oleh Dadang Kriswanto — System Analyst & Blogger di dadang.kriswanto.my.id