Rencana business continuity untuk operasional UKM bukan buku tebal yang ditulis konsultan. Cukup satu halaman yang menjawab satu pertanyaan: kalau sistem mati jam 9 pagi di hari paling sibuk, bagaimana caranya tetap jualan sampai sistem kembali normal?
Saya menanyakan hal ini di hampir setiap engagement, dan jawaban jujurnya biasanya diam. Ironis, karena lima tahun lalu bisnis yang sama berjalan sepenuhnya dengan kertas dan telepon. Digitalisasi membuat Anda lebih cepat, tapi juga menciptakan ketergantungan yang dulu tidak ada. Kasir yang dulu terbiasa menulis nota tangan sekarang membeku begitu layar POS blank, bukan karena dia lupa cara jualan, tapi karena tidak ada yang bilang dia boleh melakukannya secara manual.
Kegagalan sistem itu pasti terjadi. Internet mati, gangguan payment gateway, disk server yang penuh, laptop hilang dicuri dari mobil, PLN mematikan listrik satu kompleks untuk maintenance. Pertanyaannya bukan lagi kalau, tapi apakah Anda cuma kehilangan satu jam ketenangan, atau kehilangan satu hari penuh omzet.
Digitalisasi menciptakan single point of failure baru
Ini pola yang terus saya lihat. Sebuah bisnis mendigitalkan satu proses, entah POS, penerimaan order, atau penjadwalan pengiriman, dan berjalan begitu mulus sehingga dalam enam bulan tidak ada lagi yang ingat cara manualnya. Formulir kertas dibuang. Staf baru hanya dilatih pakai aplikasi. Sistem menjadi satu-satunya proses.
Itu persis yang Anda inginkan di hari normal. Di hari yang tidak normal, artinya modem seharga Rp 200 ribu yang rusak bisa menghentikan bisnis yang omzetnya Rp 30 juta sehari. Seorang distributor yang pernah saya tangani kehilangan hampir seluruh hari Sabtu, hari terbesar mereka, karena internet mati dan tidak ada yang tahu apakah mereka boleh tetap menerima order tanpa sistem. Sebenarnya bisa. Hanya saja tidak ada yang memutuskannya lebih dulu, jadi tidak ada yang berani memutuskan sama sekali.
Perencanaan continuity pada dasarnya adalah membuat keputusan-keputusan itu sebelum gangguan terjadi, saat kepala masih dingin, bukan di tengah kepanikan saat gangguan sedang berlangsung.
Rencana continuity satu halaman
Jangan menulis dokumen yang tidak akan dibaca siapa pun. Tulis satu halaman dengan tiga bagian, lalu tempel salinannya di kasir, di gudang, dan di kantor.
1. Fallback manual per proses kritikal
Daftar proses kritikal Anda, biasanya empat sampai enam proses, dan tulis satu baris untuk masing-masing: apa yang kita lakukan saat sistem down.
| Proses | Fallback manual |
|---|---|
| Menerima pembayaran | Buku nota bernomor cetak, tunai dan transfer bank ke rekening yang tercantum, standee QRIS tetap berfungsi kalau kodenya statis milik bank |
| Mencatat penjualan | Lembar log penjualan kertas, satu baris per transaksi, dimasukkan ke sistem setelah pulih |
| Cek stok | Pengecekan fisik, tandai barang yang terjual di log agar hitungan bisa direkonstruksi |
| Menerima order | WhatsApp di HP pemilik sebagai kanal fallback, order ditulis di formulir penerimaan |
| Pengiriman | Salinan cetak jadwal pengiriman hari itu, dicetak setiap pagi sebagai rutinitas |
Dua detail ini lebih penting dari yang terlihat. Buku nota bernomor menjaga jejak kertas tetap bisa diaudit, sehingga entri data saat pemulihan lengkap dan kecurangan selama gangguan sulit terjadi. Dan mencetak jadwal hari itu setiap pagi hanya menghabiskan selembar kertas, tapi memastikan gangguan tidak pernah menghapus data hari berjalan.
2. Siapa yang dihubungi, dalam urutan apa
Saat gangguan terjadi, aktivitas paling mahal adalah orang-orang saling bertanya siapa yang seharusnya bertindak. Tulis daftar eskalasi dengan nama dan nomor telepon yang sebenarnya:
- First responder: siapa yang mengecek hal-hal dasar, listrik, restart modem, apakah ini cuma kita atau providernya yang down.
- Kontak teknis: developer, vendor, atau IT support Anda, dengan nomor telepon, bukan sekadar email.
- Kontak provider: nomor customer service ISP, URL halaman status payment gateway, dukungan hosting provider.
- Pengambil keputusan: siapa yang berwenang bilang "pindah ke mode manual" agar staf tidak menunggu izin yang tidak pernah datang.
Baris keempat itu yang paling sering terlewat di kebanyakan rencana. Berikan wewenang eksplisit ke supervisor shift: kalau sistem down lebih dari 15 menit, langsung pindah ke kertas, tanpa perlu persetujuan lagi. Izin yang sudah ditulis lebih dulu ini nilainya lebih besar dari teknologi apa pun.
3. Urutan prioritas pemulihan
Saat sistem kembali online, atau saat orang teknis Anda harus memilih apa yang dipulihkan lebih dulu, urutannya harus sudah menjadi keputusan bisnis, ditentukan sekarang. Urutan tipikal untuk bisnis trading:
- Kemampuan menerima pembayaran
- Kemampuan menerima order baru
- Akurasi stok
- Pelaporan dan sisanya
Urutan Anda bisa berbeda. Bisnis jasa mungkin menempatkan komunikasi pelanggan di urutan pertama. Intinya, developer Anda tidak seharusnya menebak-nebak prioritas komersial Anda di tengah malam saat insiden sedang berlangsung.
Jalankan satu tabletop drill, cuma butuh satu jam
Rencana yang belum pernah diuji coba hanyalah teori. Anda tidak perlu benar-benar mencabut colokan di hari sibuk. Sebagai gantinya, jalankan tabletop drill: kumpulkan tim selama satu jam, umumkan sebuah skenario, "sekarang Sabtu jam 10 pagi, POS mati dan ISP bilang butuh empat jam", lalu jalankan rencana itu secara verbal.
Anda akan menemukan lubang-lubangnya dalam lima belas menit pertama. Buku nota yang ternyata belum pernah dibeli. Nomor akun ISP yang tidak ada yang tahu. Standee QRIS yang ternyata dinamis dan butuh sistem untuk generate kode. Kasir baru yang belum pernah lihat lembar log kertas. Setiap lubang yang ditemukan saat drill adalah lubang yang tidak akan mengejutkan Anda saat gangguan sungguhan terjadi.
Perbaiki lubang-lubangnya, perbarui satu halaman itu, dan jadwalkan drill ulang enam bulan kemudian dengan mengundang seorang kolega untuk mengamati. Dalam pengalaman saya, drill pertama sebuah UKM biasanya memunculkan tiga sampai lima celah nyata, dan drill kedua berjalan hampir membosankan. Membosankan itu justru tujuannya.
Continuity tidak sama dengan backup
Satu klarifikasi, karena dua hal ini sering tercampur. Backup menjawab "bisakah kita mendapatkan kembali data kita setelah bencana". Continuity menjawab "bisakah kita tetap beroperasi selama menunggu". Anda butuh keduanya, dan keduanya adalah proyek yang berbeda. Backup yang sempurna tidak menolong kasir jam 9 pagi, dan fallback kertas yang sempurna tidak menyelamatkan Anda kalau database hilang selamanya. Saya membahas sisi data secara terpisah di backup dan disaster recovery, penyelamat yang tidak seksi, dan rencana di atas melengkapi pemikiran yang lebih luas di kenapa bisnis Anda butuh strategi teknologi.
Kesimpulan
Rencana business continuity yang nyata untuk skala UKM adalah satu halaman, total empat jam usaha, dan satu tabletop drill:
- Satu baris fallback manual per proses kritikal, dengan materi fisiknya benar-benar sudah dibeli dan ditempatkan.
- Daftar kontak dengan nama, nomor, dan satu orang yang sudah diberi wewenang lebih dulu untuk menyatakan mode manual.
- Urutan prioritas pemulihan yang diputuskan oleh pemilik bisnis, bukan diimprovisasi oleh orang teknis.
- Satu drill selama satu jam untuk menemukan lubang-lubangnya selagi masih gratis untuk diperbaiki.
Bisnis yang menangani gangguan dengan baik bukanlah yang sistemnya paling canggih. Mereka adalah yang gangguan lima belas menitnya memicu peralihan tenang dan terlatih ke kertas, sampai-sampai pelanggan nyaris tidak sadar. Ketenangan itu nyaris tidak butuh biaya untuk dibangun. Bangun minggu ini, sebelum Anda benar-benar membutuhkannya.