# Menyusun analisis dampak bisnis untuk layanan digital

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Mulai dari pekerjaan yang terhenti dan akibatnya bagi pengguna. Target pemulihan perlu mempunyai alasan, pemilik keputusan dan bukti kemampuan; angka dari vendor saja belum cukup.

URL kanonis: https://kompli.id/panduan/kelangsungan-usaha/analisis-dampak-bisnis/
Sumber diakses: 2026-10-02
Diperbarui: 2026-10-02
Penulis: Kompli
Sumber diperiksa: 2026-10-02


## Apa yang ingin dijawab BIA?

**Analisis dampak bisnis atau BIA membantu menentukan pekerjaan yang harus diprioritaskan saat layanan terganggu.** Hasilnya perlu menjelaskan dampak seiring waktu, kemampuan kerja sementara, sumber daya dan dasar target pemulihan. Daftar server penting saja belum menjawab akibat bagi pengguna.

NIST SP 800-34 Rev. 1 bagian 3.2 membahas dampak, sumber daya dan prioritas. Dokumen 2010 itu dipakai sebagai rujukan teknis, bukan kewajiban Indonesia. Langkah dan angka berikut adalah contoh Kompli; ketentuan sektor serta kontrak dinilai terpisah. Pengertian BCP, DRP, RTO dan RPO tetap di [panduan dasarnya](/panduan/kelangsungan-usaha/bcp-drp-layanan-digital/).

## Pilih pekerjaan dan pemilik proses

Mulai dari satu alur, misalnya menerima dan memenuhi pesanan. Libatkan pemilik proses, dukungan pelanggan, keuangan, IT serta pihak terkait. Bedakan aplikasi yang berhenti dari proses yang mungkin tetap berjalan dengan cara lain.

Tuliskan pengguna, jam sibuk, tenggat pekerjaan, jumlah pekerjaan tertunda dan data yang diperlukan. Catat dasar perkiraan; jangan mengarang kerugian rupiah agar setiap layanan tampak kritis. Dampak dapat berbeda pada akhir bulan, hari libur atau saat pemasok tidak tersedia.

## Contoh dampak menurut lama gangguan

Toko fiktif mengalami gangguan panel pesanan pada 09.00 WIB. Tabel ini bahan pembahasan, **bukan hasil wawancara bisnis atau pengujian layanan nyata**.

| Lama / kondisi | Dampak dan pertanyaan contoh |
| --- | --- |
| 30 menit | Petugas belum bisa memeriksa pesanan baru. Apakah antrean dan pelanggan sudah diberi status yang tepat? |
| Dua jam | Pekerjaan mendekati batas pengiriman siang. Berapa pesanan tertunda dan petugas tambahan yang tersedia? |
| Empat jam | Sebagian pesanan berisiko melewati batas pengiriman. Apakah cara kerja sementara cukup dan sudah disetujui? |
| Satu hari | Backlog bertambah dan rekonsiliasi diperlukan. Periksa dampak pelanggan, pemasok, biaya serta kontrak yang benar-benar berlaku. |

Tulis asumsi volume dan batas pengiriman sebagai hal yang perlu dikonfirmasi. Jangan mengubah “berisiko terlambat” menjadi klaim semua pelanggan mengalami kerugian.

## Tentukan layanan minimum dan toleransi

Contoh tim memilih kemampuan membaca pesanan terkonfirmasi sebagai layanan minimum; fitur rekomendasi bisa menunggu. Cara kerja sementara perlu menjaga akses, nomor referensi, penanganan duplikat dan rekonsiliasi. Menggunakan spreadsheet belum tentu aman atau sanggup menampung pekerjaan.

Dalam contoh, toleransi gangguan proses dipilih empat jam dan target ketersediaan sistem dua jam. Sisa waktunya dipakai untuk pemeriksaan serta backlog. Hubungan ini keputusan contoh, bukan rumus wajib; kebutuhan bisnis dan kemampuan teknis harus dibahas bersama.

Target titik data 15 menit juga pilihan contoh. Tentukan transaksi mana yang tidak boleh hilang, sumber pembanding dan cara menangani pekerjaan setelah titik pemulihan. Keberhasilan target waktu tidak membuktikan data lengkap.

## Periksa apakah kemampuan mendukung target

Hubungkan keputusan dengan [peta dependensi](/panduan/kelangsungan-usaha/dependensi-dan-urutan-pemulihan/), kebutuhan petugas, akses cadangan, kunci dan dukungan pemasok. Cocokkan jam dukungan serta objek SLA; janji uptime infrastruktur belum membuktikan aplikasi siap dalam dua jam.

Minta [bukti uji pemulihan](/template/catatan-uji-pemulihan/), bukan hanya status backup. Jika kemampuan belum mendukung target, catat gap, pemilik dan pilihan perbaikan; jangan menyatakan target tercapai sebelum pengujian.

## Simpan keputusan dan tinjau perubahan

Gunakan [lembar BIA](/template/lembar-analisis-dampak-bisnis/) untuk asumsi, dampak, target, bukti dan persetujuan. Tentukan tanggal serta pemicu tinjauan: proses baru, volume berubah, vendor berpindah atau hasil latihan tidak memenuhi target.

BIA tidak menggantikan penilaian seluruh ISO 22301, aturan sektor atau rencana pemulihan teknis. Halaman ini membantu pembahasan prioritas; hasilnya perlu disetujui pemilik proses sesuai kondisi organisasi.
## Sumber rujukan

- [NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf) — §3.2.1–3.2.3: dampak, kebutuhan sumber daya dan prioritas; contoh dan worksheet orisinal Kompli.
- [NIST SP 800-34 Rev. 1 — catatan publikasi dan pembaruan](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) — Revisi 1, pembaruan 11 November 2010; konteks sistem federal AS, bukan kewajiban Indonesia.

## Perlu membahas kebutuhan tim Anda?

Ceritakan standar atau bukti yang diminta pelanggan dan kesiapan tim Anda saat ini.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=standar)

## Bacaan terkait

- [BCP dan DRP: persiapan pemulihan layanan digital](https://kompli.id/panduan/kelangsungan-usaha/bcp-drp-layanan-digital/)
- [Lembar analisis dampak bisnis layanan digital](https://kompli.id/template/lembar-analisis-dampak-bisnis/)
- [Menentukan urutan pemulihan berdasarkan dependensi layanan](https://kompli.id/panduan/kelangsungan-usaha/dependensi-dan-urutan-pemulihan/)
- [SLA dan kontrak vendor IT: apa yang perlu disepakati?](https://kompli.id/panduan/operasional-digital/sla-dan-tanggung-jawab-vendor/)