Merancang Sistem Informasi Perencanaan Program Kerja dan Rencana Anggaran Tahunan #2

Di banyak yayasan pendidikan, perencanaan program kerja dan rencana anggaran tahunan (RKA/RPAT) masih dilakukan dengan kombinasi dokumen Word, Excel, dan email. Secara historis pendekatan ini “berjalan”, tetapi semakin lama skalanya membesar:  unit bertambah, program makin kompleks, dan tuntutan akuntabilitas semakin tinggi. Pada titik tertentu, file Excel di berbagai
folder bukan lagi solusi, melainkan sumber masalah baru.

Jika yayasan Anda sudah memiliki Standard Operating Procedure (SOP) yang jelas untuk perencanaan program dan anggaran,
maka sebenarnya Anda sudah memegang 50% dari solusi. Separuh berikutnya adalah menerjemahkan SOP tersebut menjadi
Sistem Informasi Perencanaan Program Kerja dan Rencana Anggaran Tahunan yang konsisten, mudah digunakan,
dan memiliki audit trail yang kuat.

Artikel ini membahas bagaimana merancang sistem tersebut secara end-to-end: mulai dari memetakan SOP ke modul sistem,
mendesain workflow persetujuan 3–5 level, sampai menyiapkan dashboard dan laporan yang dibutuhkan manajemen dan auditor.
Fokusnya adalah konteks yayasan pendidikan, tetapi pendekatan yang sama dapat digunakan di organisasi lain dengan sedikit penyesuaian.

Tantangan Pendekatan Manual dalam Perencanaan & Anggaran

Sebelum bicara sistem, penting untuk memperjelas “rasa sakit” (pain points) yang ingin diselesaikan.
Hampir semua yayasan pendidikan yang masih mengandalkan Word/Excel untuk perencanaan program dan anggaran menghadapi pola masalah yang mirip:

• Versi dokumen tercecer: file “RKA_final_v5_fix_benar.xlsx” bukan fenomena tunggal. Versi dokumen tersebar
  di email, flashdisk, dan folder lokal, sehingga sulit memastikan mana yang resmi.
• Alur approval tidak terlihat: SOP mengatur 3–5 level persetujuan, tetapi di lapangan jejaknya hanya berupa
  tanda tangan di lembar kertas atau komentar di chat. Status “sedang diperiksa siapa” sering tidak jelas.
• Kontrol anggaran lemah: sulit memantau dengan cepat berapa pagu yang sudah dialokasikan, mana yang sudah disetujui,
  dan mana yang baru usulan. Akibatnya, risiko “over budget” meningkat.
• Audit trail minim: ketika auditor bertanya “siapa mengubah angka ini, kapan, dan mengapa?”, jawaban yang muncul
  sering berupa “sepertinya…” bukan data yang objektif.
• Lambat dan repetitif: banyak waktu habis untuk konversi format, penggabungan file, dan komunikasi bolak-balik
  hanya untuk klarifikasi yang seharusnya bisa otomatis tercatat di sistem.

Di sinilah Sistem Informasi Perencanaan Program Kerja dan Rencana Anggaran Tahunan mengambil peran: bukan sekadar memindahkan form ke web, melainkan mengunci proses agar mengikuti SOP secara konsisten, sekaligus memberi visibilitas real-time kepada manajemen.

Prinsip Desain Sistem Informasi Rencana Program & Anggaran

Sebuah sistem informasi yang sehat selalu memiliki “DNA” yang jelas. Untuk konteks perencanaan program dan anggaran tahunan, beberapa prinsip desain berikut akan membantu:

1. SOP-driven, bukan developer-driven.
   Struktur modul, field data, dan workflow harus mengikuti SOP resmi yayasan, bukan sekadar kenyamanan tim IT.
2. Approval hierarchy sebagai tulang punggung.
   Level persetujuan (Pelaksana/PJ, Kepala Divisi Keuangan, Direktur, Anggota DPH, Ketua DPH) harus tercermin eksplisit dalam sistem sebagai role dan workflow, bukan catatan lisan.
3. Audit trail menjadi fitur inti.
   Setiap perubahan signifikan (nilai anggaran, status, catatan persetujuan) wajib tercatat: siapa, kapan, dari nilai apa ke nilai apa.
4. Fleksibel terhadap kebijakan nilai.
   Ambang batas kategori A/B (misalnya > Rp 10 juta untuk 5 level) harus dapat diubah melalui konfigurasi, bukan hardcoded di kode program.
5. Pengalaman pengguna mirip alat yang sudah dikenal.
   Antarmuka dapat didesain agar familiar bagi pengguna yang terbiasa dengan Excel/Word, misalnya menggunakan tampilan tabel yang jelas, form yang terstruktur, dan validasi langsung di layar.
6. Terbuka untuk integrasi.
   Sistem perencanaan bukan silo. Idealnya dapat terhubung ke sistem klaim/pembayaran dan sistem akuntansi di masa depan.

Dengan prinsip-prinsip ini, sistem tidak hanya menyelesaikan masalah hari ini, tetapi juga siap berkembang ketika kebutuhan yayasan meningkat.

Memetakan SOP ke Arsitektur Sistem Informasi

SOP perencanaan program kerja dan rencana anggaran tahunan biasanya sudah mengatur alur lengkap: mulai dari penetapan pagu indikatif, penyusunan usulan oleh unit, konsolidasi Divisi Keuangan, hingga persetujuan berjenjang oleh Direktur dan Dewan Pengurus Harian. Tugas kita adalah menerjemahkan alur tersebut menjadi elemen-elemen sistem yang jelas.

Entitas data kunci

Beberapa entitas data kunci yang umumnya muncul:

• Tahun Anggaran – mengelompokkan seluruh program dan anggaran berdasarkan tahun buku.
• Divisi / Jenjang / Unit – sumber usulan program, sekaligus dimensi utama untuk laporan.
• Program – kumpulan kegiatan yang mendukung sasaran strategis tertentu.
• Kegiatan – unit terkecil yang memiliki jadwal, penanggung jawab, dan rincian anggaran.
• RAB (Rincian Anggaran Biaya) – daftar item biaya, jumlah, harga satuan, dan total per kegiatan.
• Pagu Indikatif – batas awal alokasi anggaran per divisi/unit.
• Approval – catatan persetujuan setiap level (status, tanggal, catatan).
• Versi RKA – penomoran versi (RKA-01, RKA-02, dst.) ketika ada perubahan di tahun berjalan.

Dari langkah SOP ke langkah sistem

Jika di SOP tertulis tahapan seperti “Pengaju menyusun proposal dan RAB lengkap, lalu menyerahkan ke Kepala Divisi Keuangan”,
maka di sistem hal ini diterjemahkan menjadi:

• Pelaksana/PJ mengisi form elektronik program, kegiatan, dan RAB.
• Pelaksana/PJ mengunggah lampiran proposal dan quotation vendor.
• Pelaksana/PJ menekan tombol Submit yang mengubah status dari DRAFT menjadi SUBMITTED.
• Sistem otomatis mengarahkan (route) usulan ke antrian Kepala Divisi Keuangan.

Dengan cara yang sama, setiap kalimat di SOP sebaiknya “diterjemahkan” menjadi aksi konkret di sistem: tombol, status, field, notifikasi, dan peran pengguna. Di sinilah PRD (Product Requirement Document) menjadi jembatan antara dokumen SOP dan desain teknis.

Modul Utama Sistem Informasi Perencanaan Program & Anggaran

Secara garis besar, Sistem Informasi Perencanaan Program Kerja dan Rencana Anggaran Tahunan akan terbagi ke dalam beberapa modul utama berikut.

1. Modul Master & Parameter

Modul ini bertugas menyimpan konfigurasi dasar yang jarang berubah, seperti:

• Master Tahun Anggaran (aktif/non-aktif).
• Struktur Divisi, Jenjang, dan Unit.
• Master pengguna dan role, termasuk pemetaan role ke level approval (1–5).
• Master COA (Chart of Accounts) dan kategori program.
• Batas nilai approval dan definisi kategori (misalnya Kategori A > Rp 10 juta, Kategori B ≤ Rp 10 juta).

Dengan modul ini, ketika ada perubahan organisasi atau kebijakan, admin sistem hanya perlu mengubah parameter – bukan meminta developer mengutak-atik kode sumber setiap saat.

2. Modul Pagu Indikatif & Rencana Makro

Sebelum unit mengusulkan program, manajemen biasanya sudah menetapkan pagu indikatif per divisi atau jenjang.
Modul ini menangani:

• Input pagu per tahun, per divisi/jenjang/unit.
• Rekap total pagu yayasan dalam bentuk tabel dan grafik sederhana.
• Hak akses baca-tulis yang jelas (biasanya Divisi Keuangan dan manajemen).

Nantinya, ketika unit mengajukan usulan, sistem dapat langsung memeriksa apakah total usulan masih sejalan dengan pagu indikatif yang tersedia.

3. Modul Usulan Program & RKA Unit

Ini adalah “meja kerja” utama bagi Pelaksana/PJ dan Kepala Unit. Beberapa elemen penting:

• Form program: tujuan, indikator keberhasilan, prioritas, kategori program, periode pelaksanaan.
• Form kegiatan: nama kegiatan, penanggung jawab, bulan pelaksanaan, output.
• Form RAB: uraian biaya, COA, kuantitas, harga satuan, total, dan kategori biaya.
• Status DRAFT untuk usulan yang belum siap dikirim, dan SUBMITTED ketika resmi diajukan.
• Upload proposal dan quotation vendor sesuai ketentuan SOP.
• Validasi otomatis: misalnya field wajib, perbandingan total usulan dengan pagu indikatif.

Antarmuka modul ini sebaiknya dirancang menyerupai tabel Excel yang rapi, dengan tetap memanfaatkan kekuatan sistem web: validasi real-time dan konsistensi data.

4. Modul Workflow Approval

Modul inilah yang memastikan SOP dijalankan konsisten setiap hari kerja. Fungsinya antara lain:

• Menentukan kategori A/B secara otomatis berdasarkan total nilai usulan.
• Mengatur urutan approval: dari Pelaksana/PJ ke Kepala Divisi Keuangan, lalu Direktur, dan jika perlu sampai Anggota DPH dan Ketua DPH.
• Menyediakan tombol aksi di setiap level: DIPERIKSA, DIREVISI, DITOLAK, DITERIMA DENGAN REVISI, DITERIMA.
• Mewajibkan catatan ketika dokumen direvisi atau ditolak.
• Mencatat tanggal dan waktu setiap keputusan.
• Mengirim notifikasi dan mengelola antrian “Perlu Saya Review” untuk masing-masing approver.

5. Modul RKA Konsolidasi, Versi, dan Perubahan

Setelah usulan disetujui, sistem harus mampu menggabungkannya menjadi RKA tingkat yayasan dan merekam versi-versi perubahan di tahun berjalan. Fitur pentingnya:

• Konsolidasi otomatis per tahun, per divisi, per COA, dan per kategori program.
• Penomoran versi RKA (RKA-01, RKA-02, dan seterusnya).
• Form pengajuan perubahan RKA (in-year adjustment) dengan alasan dan dampak bersih terhadap total anggaran.
• Laporan perbandingan sebelum dan sesudah perubahan.

6. Modul Dashboard, Laporan, dan Audit Trail

Modul ini menjawab kebutuhan manajemen dan auditor:

• Dashboard ringkas: total pagu, total usulan, total disetujui, distribusi per divisi, dan status pengajuan.
• Laporan detail: rencana program dan anggaran per tahun, per unit, per COA, dan per kategori program.
• Laporan waktu rata-rata approval per kategori dan per level.
• Log aktivitas dan histori status proposal untuk keperluan audit internal maupun eksternal.

Desain Workflow Approval 3–5 Level

Salah satu elemen paling krusial adalah workflow persetujuan. Untuk menjaga kepatuhan terhadap SOP, sistem harus mampu
mengatur dua jalur utama:

• Kategori A: nilai usulan > Rp 10.000.000, melalui 5 level approval.
• Kategori B: nilai usulan ≤ Rp 10.000.000, melalui 3 level approval.

Alih-alih mengandalkan pengguna untuk “ingat” jalur mana yang harus digunakan, sistem sendiri yang memutuskan jalur berdasarkan
nilai total usulan.

Contoh logika penentuan kategori (pseudo-konfigurasi)

{
  "batas_kategori": {
    "A": { "min": 10000001, "approval_levels": [1, 2, 3, 4, 5] },
    "B": { "min": 0, "max": 10000000, "approval_levels": [1, 2, 3] }
  }
}

Secara implementasi, konfigurasi di atas bisa berbentuk tabel database atau berkas konfigurasi yang mudah diubah oleh admin
(melalui antarmuka khusus), sehingga ketika batas nilai berubah, sistem dapat menyesuaikan tanpa modifikasi kode.

Mekanisme banding (appeal)

SOP yang baik biasanya menyediakan jalan banding apabila pengaju merasa penolakan tidak tepat. Di sistem, hal ini dapat difasilitasi dengan:

• Tombol Ajukan Banding yang hanya aktif ketika status terakhir adalah DITOLAK.
• Form banding berisi alasan dan data pendukung.
• Routing otomatis ke level di atas pihak yang menolak.
• Pembatasan bahwa banding hanya boleh dilakukan satu kali per proposal.

Audit Trail dan Kontrol Internal

Dari perspektif akuntabilitas dan kepatuhan (termasuk bila mengacu ISO 9001:2015), audit trail bukan fitur opsional, melainkan wajib. Beberapa hal yang perlu diperhatikan:

• Log aktivitas pengguna. Setiap login, submit, approve, revisi, dan penolakan harus tercatat
  dengan timestamp yang akurat.
• Histori perubahan field kritikal. Perubahan pada nilai anggaran, COA, dan status harus disimpan
  sebagai histori, bukan ditimpa begitu saja.
• Akses khusus auditor. Auditor internal perlu memiliki akses baca terhadap seluruh data dan log,
  tanpa hak untuk mengubah.
• Backup dan pemulihan. SOP TI perlu mengatur backup harian database dan uji pemulihan (restore)
  berkala agar data anggaran tetap aman.

Dengan audit trail yang baik, pertanyaan seperti “mengapa program ini dihapus?” atau “siapa yang menurunkan anggaran ini?”
dapat dijawab dengan data, bukan dengan dugaan.

Perbandingan: Proses Manual vs Sistem Informasi

Untuk memperjelas manfaat sistem, matriks berikut membandingkan praktik manual (Excel/Word/email) dengan sistem informasi terintegrasi.

Arsitektur Teknis dan Integrasi

Dari sisi teknis, sistem informasi perencanaan program dan anggaran dapat dibangun dengan arsitektur tiga lapis yang cukup umum:

• Frontend web – antarmuka pengguna (misalnya berbasis React, Vue, atau Blade Laravel).
• Backend API – mengimplementasikan logika bisnis SOP dan mengelola akses data.
• Database relasional – menyimpan master data, transaksi program, kegiatan, RAB, approval, dan log.

Sistem dapat di-deploy di lingkungan yang sudah Anda miliki, misalnya:

• VM on-premises di cluster Proxmox yayasan.
• VM cloud (misalnya AWS EC2) dengan backup ke NAS dan cloud storage.

Untuk tahap awal, integrasi dengan sistem lain tidak perlu terlalu kompleks. Cukup sediakan fitur ekspor laporan ke format CSV/Excel yang dapat diimpor ke sistem klaim atau akuntansi. Di tahap lanjut, barulah disiapkan API langsung untuk sinkronisasi data.

Strategi Implementasi Bertahap

Membangun sistem informasi perencanaan program dan anggaran bukan proyek “sekali jadi”.
Lebih aman menggunakan pendekatan bertahap, misalnya:

1. Fase 1 – Core planning & approval.
   Fokus pada input usulan program, RAB, dan workflow approval (kategori A dan B). Pastikan SOP sudah terimplementasi dengan benar.
2. Fase 2 – Versi RKA dan perubahan di tahun berjalan.
   Tambahkan fitur pengelolaan versi RKA, usulan perubahan, serta laporan perbandingan.
3. Fase 3 – Integrasi dengan klaim dan akuntansi.
   Hubungkan dengan sistem klaim/pembayaran dan akuntansi untuk memantau penyerapan anggaran secara real-time.
4. Fase 4 – Analitik dan perencanaan strategis.
   Bangun modul analitik multi-tahun untuk membantu yayasan merencanakan investasi dan program prioritas secara berbasis data.

Pendekatan bertahap seperti ini mengurangi risiko, memberi ruang untuk umpan balik pengguna, dan memastikan bahwa sistem
benar-benar menjawab kebutuhan operasional, bukan sekadar tampak canggih di atas kertas.

Kesimpulan

Merancang Sistem Informasi Perencanaan Program Kerja dan Rencana Anggaran Tahunan yang matang bukan sekadar proyek TI.
Ini adalah upaya menyatukan SOP, tata kelola keuangan, struktur kewenangan, dan kebutuhan akuntabilitas ke dalam satu
platform yang koheren.

Dengan memulai dari SOP yang sudah ada, kemudian memetakannya ke PRD dan modul-modul sistem yang jelas, yayasan pendidikan
dapat beralih dari sekumpulan file Excel ke sebuah sistem informasi yang:

• Memastikan setiap pengajuan program mengikuti jalur persetujuan yang tepat.
• Memberi visibilitas real-time kepada manajemen mengenai posisi pagu dan anggaran.
• Menyediakan jejak audit yang kuat untuk keperluan internal maupun eksternal.
• Siap terintegrasi dengan sistem klaim dan akuntansi di masa depan.

Jika proses perencanaan program dan anggaran di yayasan Anda saat ini terasa berat, lambat, dan membingungkan,
itu bukan sekadar masalah “banyak form”. Mungkin sudah saatnya SOP yang baik mendapatkan “rumah” yang layak
dalam bentuk Sistem Informasi yang dirancang secara serius dan berkelanjutan.

Sumber / Referensi

• ISO 9001:2015 – Quality management systems
• Regulasi terkait perencanaan dan penganggaran publik
• Kementerian Pendidikan, Kebudayaan, Riset, dan Teknologi