TALAS DASHBOARD

Kabupaten Bogor

DATA ASSESMENT LAYANAN
PSC 119

	Nilai	Catatan/ Keterangan/ Eviden/ Link
1. 1. Identifikasi Risiko
1. Area Dampak	Dampak Negatif
2. Level Dampak	3 - Sedang	Simulator didesain mengikuti status dispatch riil sehingga mengurangi keparahan, tapi tetap ada gap akurasi peta.
3. Kemungkinan Terjadi	4 - Sering	Kondisi berlangsung terus-menerus untuk ambulans yang trackernya belum terpasang.
1. 2. Analisis Risiko
1. Analisis dampak terhadap layanan	Identifikasi dilakukan	Dampak terhadap akurasi monitoring dijelaskan naratif, belum analisis formal.
2. Penetapan level risiko	Belum ada manajemen risiko	Tidak ada skema rating level risiko formal.
3. Prioritas penanganan	Belum ada manajemen risiko	Tidak ada dokumen prioritas penanganan/roadmap pemasangan tracker.
1. 3. Mitigasi Risiko
1. Terdapat rencana mitigasi	Mitigasi berjalan	Sistem otomatis menonaktifkan simulator per-ambulans begitu tracker riil melapor posisi (<2 menit), memungkinkan rollout bertahap; admin bisa matikan simulator global.
2. Ada PIC setiap risiko	Belum ada manajemen risiko	Tidak ada PIC bernama untuk risiko ini di dokumentasi.
3. Ada target penyelesaian	Belum ada manajemen risiko	Tidak ada target waktu pemasangan tracker di seluruh armada.
1. 4. Monitoring Risiko
1. Review risiko minimal 1 kali per tahun	Belum ada manajemen risiko	Tidak ada jadwal review risiko.
2. Dashboard monitoring risiko	Identifikasi dilakukan	Badge status simulator di halaman Monitoring adalah indikator, bukan dashboard risiko formal.
3. Laporan kepada pimpinan	Belum ada manajemen risiko	Tidak ada laporan risiko berkala ke pimpinan.

	Nilai	Catatan/ Keterangan/ Eviden/ Link
2. 1. Perencanaan Perubahan
1. Form usulan perubahan	Tidak ada proses	Tidak ada form usulan perubahan yang disebutkan.
2. Analisis dampak perubahan	Perubahan dilakukan manual	Guard pada ALTER TABLE menunjukkan kehati-hatian informal, bukan proses analisis dampak formal.
2. 2. Persetujuan Perubahan
1. Ada Change Advisory Board (CAB)	Tidak ada proses	Tidak disebutkan.
2. Ada persetujuan pimpinan	Tidak ada proses	Tidak disebutkan.
3. Prioritas perubahan	Tidak ada proses	Tidak ada roadmap/backlog terdokumentasi seperti pada Prolap Wiki.
2. 3. Implementasi Perubahan
1. Jadwal implementasi	Perubahan dilakukan manual	Tidak ada jadwal rilis tetap yang disebutkan.
2. Rollback plan	Perubahan dilakukan manual	Tidak ada prosedur rollback deployment formal; backup harian bisa jadi jalur pemulihan data informal.
2. 4. Evaluasi Perubahan
1. Review pasca implementasi	Tidak ada proses	Tidak disebutkan.
2. Dokumentasi lesson learned	Tidak ada proses	Tidak ada bagian lesson-learned seperti pada Prolap Wiki.

	Nilai	Catatan/ Keterangan/ Eviden/ Link
3. 1. Dokumentasi Pengetahuan
1. Manual pengguna	Ada sebagian	README menjelaskan fitur per modul, tapi bukan manual langkah-demi-langkah untuk petugas.
2. Manual administrator	Lengkap	DEPLOYMENT.md + modul Master Data (kelola petugas/ambulans) didokumentasikan.
3. Dokumentasi teknis	Lengkap	README mencakup tech stack, struktur proyek, API summary, skema database lengkap.
4. Diagram arsitektur	Ada sebagian	Ada struktur folder proyek, tapi tidak ada diagram arsitektur sistem (berbeda dari Prolap Wiki).
3. 2. Basis Pengetahuan (Knowledge Base)
1. FAQ	Tidak ada dokumentasi	Tidak disebutkan.
2. Artikel solusi	Tidak ada dokumentasi	Tidak disebutkan.
3. Video tutorial	Tidak ada dokumentasi	Tidak disebutkan.
4. Troubleshooting	Tidak ada dokumentasi	Tidak ada bagian troubleshooting seperti README Prolap Wiki.
3. 3. Transfer Pengetahuan (Transfer Knowledge)
1. Pelatihan admin	Tidak ada dokumentasi	Tidak disebutkan.
2. Dokumentasi hasil pelatihan	Tidak ada dokumentasi
3. 4. Pemutakhiran Pengetahuan (Upgrade Knowledge)
1. Review dokumen berkala	Tidak ada dokumentasi	Tidak ada jadwal review dokumentasi yang disebutkan.
2. Versioning dokumen	Ada sebagian	Kode & dokumentasi ada di repo git (github.com/kusumaindraputra/psc-internal), tapi tanpa proses versioning dokumen formal.

	Nilai	Catatan/ Keterangan/ Eviden/ Link
4. 1. Backup
1. Backup database	Backup saja	README eksplisit: backup otomatis harian db.sqlite ke backend/backups/, retensi 14 hari — tanpa dokumen rencana pemulihan bencana.
2. Backup aplikasi	Backup saja	Kode di git sebagai bentuk cadangan aplikasi.
3. Backup konfigurasi	Tidak ada	Tidak disebutkan adanya backup file konfigurasi/env terpisah.
4. Jadwal backup	Backup saja	Eksplisit: otomatis harian, retensi 14 hari.
4. 2. Disaster Recovery
1. DRP (Disaster Recovery Plan)	Tidak ada	Hanya backup rutin, tidak ada dokumen DRP.
2. Simulasi DRP	Tidak ada	Tidak disebutkan.
3. Recovery Time Objective (RTO)	Tidak ada	Tidak ada target RTO.
4. Recovery Point Objective (RPO)	Tidak ada	Backup harian mengimplikasikan RPO ~24 jam, tapi tidak ada target RPO formal.
4. 3. High Availability
1. Redundansi server	Tidak ada	Tidak disebutkan.
2. Load balancing	Tidak ada	Tidak disebutkan.
3. Failover	Tidak ada	Tidak disebutkan.
4. 4. Monitoring
1. Monitoring server	Tidak ada	Tidak ada tool monitoring/alerting infrastruktur yang disebutkan.
2. Monitoring aplikasi	Backup saja	Dashboard statistik harian & audit_log memberi visibilitas operasional dasar, bukan monitoring kesehatan aplikasi sistematis.
3. Alert otomatis	Tidak ada	Ada notifikasi getar/suara untuk petugas di Field Mode, tapi itu notifikasi pengguna, bukan alerting operasional/infra.

	Nilai	Catatan/ Keterangan/ Eviden/ Link
5. 1. Helpdesk
1. Helpdesk tersedia	Ada ticketing	Modul Call Reporting mencatat & melacak tiap panggilan darurat dari sumber/kategori/status hingga selesai.
2. Ticketing System	Ada ticketing	Setiap penugasan ambulans dilacak lewat tahapan (Assigned→Departed→On Scene→To Facility→At Facility→Completed) dengan timestamp per tahap.
3. Nomor layanan	Ada kontak	Nomor darurat 119 adalah identitas layanan (PSC 119), meski tidak dinyatakan eksplisit di README aplikasi internal ini.
4. Email layanan	Tidak ada	Tidak disebutkan.
5. 2. Kanal Komunikasi
1. Website	Tidak ada	Aplikasi internal (path /psc) untuk petugas, bukan portal publik.
2. WhatsApp	Tidak ada	Tidak disebutkan.
3. Media sosial	Tidak ada	Tidak disebutkan.
4. Call Center	Ada ticketing	Sistem ini pada dasarnya adalah call center darurat (PSC = Public Safety Center) dengan pencatatan & pelacakan penuh.
5. 3. Penanganan Keluhan
1. SOP	Tidak ada	Tidak ada SOP penanganan keluhan (berbeda dari SOP penanganan panggilan darurat).
2. SLA keluhan	Tidak ada	Ada pelacakan response time operasional, tapi bukan SLA keluhan spesifik.
3. Monitoring tiket	Ada ticketing	Modul Reports melacak response time per periode, utilisasi ambulans, dan rekap harian.
5. 4. Edukasi
1. Panduan	Tidak ada	Tidak ada materi edukasi publik yang disebutkan.
2. Webinar	Tidak ada	Tidak disebutkan.
3. Video tutorial	Tidak ada	Tidak disebutkan.

	Nilai	Catatan/ Keterangan/ Eviden/ Link
6. 1. Standarisasi API
1. REST API	API terdokumentasi	README memuat tabel ringkasan endpoint REST lengkap (Auth, Calls, Dispatch, Ambulances, dst).
2. JSON/XML	API terdokumentasi	Backend Express + Axios standar menggunakan JSON.
6. 2. Keamanan API
1. OAuth	API internal	Autentikasi pakai password (scrypt) + token HMAC sendiri, bukan standar OAuth.
2. Token	API aman	Password login (scrypt) + HMAC token, role admin/operator, rate limiting login — kombinasi praktik keamanan token yang solid.
3. HTTPS	API internal	Ada contoh konfigurasi nginx-psc.conf untuk produksi; perlu verifikasi apakah HTTPS/TLS sudah ditegakkan di konfigurasi produksi aktual.
6. 3. Monitoring API
1. API Logging	API aman	Morgan (HTTP request logger) + audit_log (trail semua mutasi: waktu, petugas, aksi, entitas) — logging berlapis.
2. Rate Limit	API internal	Rate limiting hanya disebutkan untuk endpoint login, belum rate limit API secara umum.
3. API Analytics	API internal	Tidak ada tool analitik API yang disebutkan; hanya logging dasar.
6. 4. Integrasi API
1. Integrasi internal	API terdokumentasi	Frontend (Axios + interceptor Authorization) terintegrasi penuh dengan backend lewat API terdokumentasi.
2. Integrasi SPBE/PEMDI	Tidak ada API	Tidak ada integrasi dengan sistem SPBE/PEMDI yang disebutkan.
3. Integrasi SSO	Tidak ada API	Autentikasi mandiri (token+role), tidak terintegrasi SSO.

	Nilai	Catatan/ Keterangan/ Eviden/ Link
7. 1. Dokumen SLA
1. SLA tersedia	Tidak ada SLA	Tidak ada dokumen SLA formal; hanya ada pengukuran response time operasional.
2. Disahkan pimpinan	Tidak ada SLA
3. Dipublikasikan	Tidak ada SLA
7. 2. Target Layanan
1. Availability	Tidak ada SLA	Tidak ada target uptime formal.
2. Response Time	Tidak ada SLA	Sistem MENGUKUR response time (dispatch→departed→on-scene→total misi→kembali) tapi belum ada target/ambang SLA yang dinyatakan.
3. Resolution Time	Tidak ada SLA	Data waktu penyelesaian misi terekam, namun tanpa target SLA formal.
7. 3. Monitoring SLA
1. Laporan SLA	Evaluasi	Laporan bulanan siap-cetak untuk Dinas Kesehatan (print/PDF) ditinjau berkala oleh pimpinan dinas.
2. Evaluasi SLA	Ada dokumen	Ada laporan berkala ke Dinkes, tapi belum jelas apakah dievaluasi terhadap target SLA formal.
7. 4. Pelanggaran SLA
1. Pencatatan	Tidak ada SLA	Tanpa target SLA formal, belum ada konsep pencatatan pelanggaran SLA.
2. Analisis penyebab	Tidak ada SLA
3. Tindak lanjut	Tidak ada SLA

	Nilai	Catatan/ Keterangan/ Eviden/ Link
8. 1. Pelaksanaan SKM
1. Dilaksanakan berkala	Tidak ada SKM	Tidak ada mekanisme survei kepuasan masyarakat yang disebutkan di README, walau layanan ini publik-facing (darurat 119).
2. Menggunakan metode baku	Tidak ada SKM
3. Responden memadai	Tidak ada SKM
8. 2. Analisis SKM
1. Nilai IKM	Tidak ada SKM
2. Analisis komentar	Tidak ada SKM
3. Identifikasi masalah	Tidak ada SKM
8. 3. Publikasi SKM
1. Hasil dipublikasikan	Tidak ada SKM
2. Dashboard	Tidak ada SKM
8. 4. Tindak Lanjut SKM
1. Action Plan	Tidak ada SKM
2. Monitoring	Tidak ada SKM
3. Evaluasi	Tidak ada SKM