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

Sekilas SOP Perencanaan Program Kerja dan Rencana Anggaran Tahunan

Bagian pertama dari dokumen adalah SOP Murni Perencanaan Program Kerja dan Rencana Anggaran Tahunan.
Di dalamnya dijelaskan mulai dari tujuan, ruang lingkup, prinsip umum, peran dan tanggung jawab, hingga langkah-langkah prosedural. SOP ini menjadi blueprint utama yang harus diikuti saat merancang sistem informasi, karena
sistem yang baik tidak boleh mengubah kebijakan, tetapi justru mendukung implementasi kebijakan yang sudah disepakati.

Tujuan Penyusunan SOP dan Sistem

Dari perspektif dokumen, tujuan utama SOP perencanaan program dan anggaran di yayasan pendidikan meliputi:

• Memastikan proses perencanaan berjalan terencana, terintegrasi, dan terdokumentasi di seluruh unit.
• Menghubungkan antara rencana strategis yayasan dengan program kerja operasional di unit-unit pelaksana.
• Menjamin bahwa setiap rencana kegiatan memiliki indikator keberhasilan, jadwal, dan kebutuhan anggaran yang jelas.
• Menghindari praktik anggaran yang tidak wajar dan tidak sesuai dengan kebijakan keuangan yayasan.
• Menyediakan dasar yang kuat bagi proses monitoring, evaluasi, dan audit.

Ketika tujuan tersebut diterjemahkan ke dalam sistem informasi, kita ingin agar setiap fungsi sistem dapat ditelusuri
kembali ke salah satu tujuan di atas. Dengan demikian, fitur yang dibangun tidak hanya “keren secara teknis”
tetapi juga relevan secara manajerial.

Ruang Lingkup dan Aktor yang Terlibat

SOP menjelaskan bahwa proses perencanaan program dan anggaran mencakup berbagai level di yayasan:
mulai dari unit pelaksana (misalnya sekolah, bagian, atau bidang), kepala unit, kepala divisi, hingga tingkat manajemen yayasan. Setiap level memiliki peran berbeda: mengusulkan, mereview, mengoreksi, menyetujui, hingga melakukan konsolidasi.

Dalam rancangan sistem informasi, aktor-aktor ini akan menjadi role utama, misalnya:

• Pengusul Kegiatan: menyusun draft program dan RAB.
• Atasan Langsung: memeriksa kelayakan teknis dan kesesuaian dengan tujuan unit.
• Manajemen Menengah: menguji konsistensi dengan kebijakan bidang/divisi.
• Manajemen Puncak / Yayasan: menyetujui rencana akhir dan plafon anggaran.
• Divisi Keuangan: memastikan kesesuaian dengan kebijakan biaya, kode akun, dan keterbatasan dana.
• Divisi IT: mengelola parameter sistem, pengguna, dan integrasi dengan sistem lain (mis. keuangan atau akuntansi).

Perincian peran ini penting, karena akan berpengaruh pada desain hak akses (role-based access control),
tampilan layar, serta alur notifikasi dan persetujuan di dalam sistem.

Dari SOP ke Sistem Informasi: Prinsip Desain

Dokumen pada Bagian II menjabarkan Product Requirement Document (PRD) untuk Sistem Informasi Perencanaan Program Kerja & Rencana Anggaran Tahunan (SIPKAT).
PRD ini pada dasarnya adalah “penerjemah” dari SOP ke bahasa sistem. Agar implementasi sistem tetap selaras dengan SOP, ada beberapa prinsip desain yang perlu dijaga.

1. Satu Proses, Satu Sumber Kebenaran

Dalam praktik manual, sering kali terdapat beberapa versi file proposal dan RAB yang beredar: versi pengusul, versi yang sudah dikomentari atasan, versi revisi, dan seterusnya. Sistem informasi harus menghapus  pola ini dengan menyediakan satu single source of truth. Setiap revisi terekam sebagai versi, tetapi tetap berada dalam satu entitas kegiatan yang sama.

Hal ini mensyaratkan adanya:

• Nomor unik untuk setiap proposal kegiatan dan rencana anggaran.
• Fitur versioning yang jelas (siapa mengubah apa dan kapan).
• Riwayat persetujuan dan catatan koreksi pada entitas yang sama.

2. No Double Entry dan Minim Duplikasi

SOP yang baik menghindari pengisian data yang sama secara berulang. Oleh karena itu, sistem harus:

• Memisahkan data master (unit, tahun ajaran, akun biaya, jenis program) dari data transaksi (proposal dan RAB).
• Menggunakan lookup dan referensi, bukan pengetikan ulang informasi yang seharusnya sudah ada di sistem.
• Menyediakan template dan pre-filled fields untuk informasi berulang.

3. Transparansi, Audit Trail, dan Kepatuhan

Salah satu nilai penting dari SOP adalah kemampuan untuk diaudit: siapa melakukan apa dan kapan. Sistem informasi harus memperkuat hal ini dengan menyediakan:

• Log aktivitas yang tidak dapat dihapus (hanya dapat dibaca oleh pihak berwenang).
• Riwayat persetujuan dengan nama, jabatan, dan stempel waktu.
• Jejak perubahan di setiap elemen sensitif: nominal anggaran, volume kegiatan, satuan, dan sebagainya.

Dengan demikian, ketika ada pertanyaan dari auditor atau manajemen, sistem dapat memberikan bukti lengkap tanpa perlu mencari-cari dokumen terpisah.

4. Fleksibel terhadap Struktur Organisasi dan Kebijakan

Dokumen PRD menekankan bahwa sistem harus mampu mengakomodasi beberapa jenis struktur, misalnya beberapa unit sekolah di bawah satu yayasan, atau beberapa jenis program (akademik, non-akademik, pengembangan).
Karena itu:

• Level approval tidak boleh hard-coded, tetapi dikonfigurasi melalui parameter.
• Struktur unit, jabatan, dan relasinya perlu disimpan sebagai data master yang mudah diperbarui.
• Kode akun biaya dan kategori kegiatan harus dapat dimodifikasi sesuai perkembangan kebijakan keuangan.

Arsitektur Konseptual SIPKAT

Secara garis besar, arsitektur SIPKAT yang dijelaskan dalam PRD dapat dibagi menjadi tiga lapisan:
lapisan presentasi, lapisan aplikasi, dan lapisan data. Meskipun implementasi teknisnya bisa menggunakan
berbagai teknologi (misalnya web-based dengan framework modern), secara konseptual pola berikut relevan
untuk hampir semua platform.

Lapisan Presentasi (User Interface)

Lapisan ini digunakan oleh pengguna sehari-hari: pengusul kegiatan, atasan, manajemen, dan divisi keuangan.
Berdasarkan dokumen, beberapa fitur kunci di lapisan ini antara lain:

• Formulir digital untuk menyusun proposal kegiatan dan RAB berdasarkan template.
• Dashboard ringkas bagi setiap peran: daftar usulan, status persetujuan, dan notifikasi.
• Tampilan kalender atau time-line program kerja untuk melihat distribusi kegiatan dalam satu tahun.
• Fitur pencarian dan filter berdasarkan unit, kategori program, dan status.

Lapisan Aplikasi (Logika Bisnis)

Di sini seluruh aturan SOP diterjemahkan menjadi logika sistem:

• Alur submit > review > revise > approve multi-level.
• Pemeriksaan otomatis terhadap batas plafon anggaran per unit atau per jenis kegiatan.
• Penguncian (locking) data setelah status tertentu, sehingga tidak bisa diubah sembarangan.
• Notifikasi ke pengguna terkait ketika ada permintaan revisi atau persetujuan baru.

Lapisan Data (Database dan Integrasi)

Lapisan data menyimpan seluruh informasi struktur organisasi, parameter, dan transaksi. PRD juga membuka peluang integrasi dengan sistem lain, misalnya:

• Sistem informasi keuangan atau akuntansi yayasan.
• Sistem informasi kepegawaian, jika data unit dan jabatan diambil dari sana.
• Sistem pelaporan strategis (dashboard manajemen yayasan).

Dengan demikian, data RKA yang disetujui dapat menjadi dasar penyusunan anggaran resmi dan pemantauan realisasi
anggaran di sistem keuangan.

Desain Data Utama dan Struktur Informasi

Salah satu kekuatan dokumen PRD adalah daftar entitas utama yang perlu dikelola oleh sistem. Berdasarkan dokumen, beberapa data utama yang harus mendapat perhatian khusus adalah:

1. Master Organisasi dan Peran

• Unit pendidikan (TK, SD, SMP, SMA, dsb.).
• Sub-unit atau bidang di dalam masing-masing unit.
• Jabatan fungsional dan struktural yang terkait dengan perencanaan program dan anggaran.
• Relasi atasan-bawahan untuk keperluan alur persetujuan.

2. Master Periode dan Parameter Perencanaan

• Tahun anggaran dan tahun ajaran.
• Jadwal pembukaan dan penutupan periode pengusulan kegiatan.
• Plafon anggaran per unit atau per kategori program jika diperlukan.

3. Data Program, Kegiatan, dan RAB

Untuk setiap usulan, sistem menyimpan:

• Judul program dan kegiatan.
• Tujuan, sasaran, dan indikator keberhasilan.
• Waktu pelaksanaan dan lokasi.
• Penanggung jawab dan tim pelaksana.
• Rincian RAB (jenis biaya, volume, satuan, harga satuan, dan total).

4. Lampiran dan Dokumen Pendukung

SOP sering mensyaratkan adanya lampiran, misalnya:

• Rincian teknis kegiatan.
• Penawaran harga atau referensi biaya.
• Dokumen kebijakan atau regulasi yang menjadi dasar kegiatan.

Sistem harus mengizinkan pengunggahan lampiran (misalnya PDF atau gambar) dan mengaitkannya dengan usulan kegiatan yang bersangkutan.

Contoh Representasi Data Approval dalam Bentuk Terstruktur

Secara internal, struktur level approval dapat direpresentasikan dalam format terstruktur
(misalnya JSON) seperti contoh berikut:

{
  "skema_approval": "standar_5_level",
  "level_1": "Pengusul Kegiatan",
  "level_2": "Atasan Langsung Pengusul",
  "level_3": "Kepala Unit / Kepala Sekolah",
  "level_4": "Kepala Divisi / Bidang Terkait",
  "level_5": "Manajemen Yayasan / Pimpinan",
  "divisi_keuangan": "Review nominal dan kode akun biaya"
}

Struktur seperti ini tidak ditampilkan langsung ke pengguna akhir, namun menjadi dasar konfigurasi di sisi admin,
sehingga jika suatu saat pola approval berubah (misalnya hanya 3 level untuk jenis kegiatan tertentu), perubahan dapat dilakukan tanpa perlu memodifikasi kode program.

Workflow Digital dan Otomasi Approval

Salah satu inti dari sistem adalah alur persetujuan (workflow) yang mengikuti SOP. Dokumen SOP dan PRD menjelaskan pola approval yang dapat melibatkan 3 sampai 5 level, tergantung jenis program dan struktur organisasi. Di dalam sistem, alur ini direpresentasikan sebagai serangkaian status dengan aturan perpindahan yang jelas.

Status Utama dalam Siklus Usulan

Sebagai contoh, siklus usulan kegiatan dapat dibagi ke dalam status berikut:

• Draft – pengusul sedang menyusun proposal, belum dikirim untuk persetujuan.
• Diajukan – proposal sudah dikirim ke atasan langsung.
• Direvisi – ada catatan dari atasan/manajemen, pengusul diminta melakukan perbaikan.
• Disetujui Berjenjang – setiap level yang relevan sudah memberikan persetujuan.
• Ditolak – usulan tidak dilanjutkan, beserta alasan penolakan.
• Diproses ke Anggaran Resmi – usulan yang disetujui telah masuk ke konsolidasi anggaran.

Mekanisme Notifikasi dan Tanggung Jawab

Setiap perpindahan status harus memicu notifikasi yang tepat:

• Saat pengusul mengajukan, atasan langsung mendapat notifikasi.
• Saat atasan memberi catatan revisi, pengusul mendapat notifikasi beserta ringkasan catatan.
• Saat usulan mendekati batas waktu tanpa ada tindakan, sistem dapat mengirimkan pengingat otomatis.
• Saat semua level selesai menyetujui, divisi keuangan dan manajemen yayasan dapat melihat status konsolidasi.

Dengan cara ini, SIPKAT tidak hanya menjadi tempat penyimpanan dokumen, tetapi benar-benar menjadi “mesin proses”
yang menggerakkan disiplin perencanaan di yayasan.

Matriks Perbandingan: Proses Manual vs Sistem SIPKAT

Untuk melihat nilai tambah dari sistem informasi, berikut adalah matriks perbandingan antara proses perencanaan
program dan anggaran secara manual (berbasis dokumen terpisah) dengan proses yang sudah menggunakan SIPKAT.

Strategi Implementasi Bertahap dan Pengendalian Internal

Merancang SIPKAT di atas kertas relatif mudah; tantangannya justru ada pada implementasi. Dokumen SOP dan PRD sudah memberikan landasan, namun yayasan perlu menyusun strategi implementasi bertahap
agar adopsi pengguna berjalan mulus dan risiko gangguan operasional dapat diminimalkan.

Fase 1 – Digitalisasi Template dan Alur Dasar

Pada tahap ini, fokus utama adalah memindahkan proses pengajuan usulan dan RAB ke dalam sistem:

• Menyediakan template digital untuk proposal dan RAB.
• Mengaktifkan alur pengajuan dan persetujuan dasar (misalnya 3 level dulu).
• Memberikan pelatihan ke pengusul dan atasan langsung mengenai cara menggunakan sistem.
• Menjalankan periode uji coba bersamaan dengan proses manual untuk mencegah gangguan.

Fase 2 – Konsolidasi dan Laporan Manajemen

Setelah alur dasar stabil, tahap berikutnya adalah:

• Menggunakan data sistem sebagai sumber utama konsolidasi RKA.
• Menyediakan laporan per unit, per kategori program, dan per jenis biaya.
• Menambahkan fitur analisis sederhana, misalnya proporsi anggaran antar kategori.

Fase 3 – Integrasi dan Penguatan Pengendalian Internal

Pada fase ini, SIPKAT mulai diintegrasikan dengan sistem lain:

• Integrasi dengan sistem keuangan untuk memantau realisasi anggaran berdasarkan RKA yang sudah disetujui.
• Penambahan kontrol seperti pembatasan pengajuan di luar kalender perencanaan.
• Penguatan mekanisme audit trail dan laporan untuk keperluan audit tahunan.

Dengan pendekatan bertahap, yayasan menghindari risiko penolakan pengguna dan dapat melakukan penyesuaian
berdasarkan pengalaman lapangan, tanpa perlu mengubah prinsip dasar yang sudah digariskan dalam SOP dan PRD.

Kesimpulan

Dokumen “Perencanaan Program Kerja dan Rencana Anggaran Tahunan” yang Anda miliki sudah menyediakan dua hal penting: 

• SOP murni yang menjabarkan alur bisnis dan akuntabilitas
• PRD yang mendefinisikan kebutuhan fungsional
  Sistem Informasi Perencanaan Program Kerja & Rencana Anggaran Tahunan (SIPKAT).

Tugas berikutnya adalah merangkai keduanya menjadi rancangan sistem yang konkret dan dapat diimplementasikan secara bertahap.

Kunci keberhasilan bukan hanya pada teknologi yang dipilih, tetapi pada seberapa konsisten sistem tersebut menerjemahkan SOP: peran dan tanggung jawab yang jelas, alur persetujuan yang transparan, data yang rapi dan terpusat, serta kemampuan sistem untuk menyediakan jejak audit yang dapat  dipertanggungjawabkan.
Dengan pendekatan yang tepat, SIPKAT tidak hanya membantu menyusun anggaran tahunan,
tetapi juga meningkatkan kualitas pengambilan keputusan dan tata kelola yayasan secara keseluruhan.

Bagi tim IT, artikel ini dapat menjadi referensi awal untuk menyusun desain teknis dan arsitektur aplikasi. Bagi manajemen dan tim keuangan, artikel ini dapat membantu memetakan ekspektasi dan ruang lingkup proyek  pengembangan sistem, sehingga komunikasi dengan tim pengembang menjadi lebih efektif.
Pada akhirnya, sistem informasi yang dirancang dengan baik akan menjadi tulang punggung perencanaan strategis yayasan dan memastikan bahwa setiap rupiah yang dianggarkan benar-benar sejalan dengan misi pendidikan yang ingin dicapai.

Sumber / Referensi

• 
  https://www.iso.org/standard/62085.html
  
• 
  https://www.kemdikbud.go.id