Ruang publik diramaikan dengan temuan kejanggalan rancangan anggaran pada Dinas Pendidikan Provinsi DKI Jakarta. Pada website resmi APBD DKI Jakarta (apbd.jakarta.go.id), tercantum rencana belanja alat tulis kantor dengan komponen lem aibon dan tinta printer.
Kejanggalan pada komponen lem aibon terlihat mulai dari sisi harga per kilogramnya (Rp. 184,000) sampai koefisiennya (37500 orang x 12 bulan) sehingga membuat total anggaran yang diperlukan untuk rencana belanja ini sendiri, membludak sampai 82M lebih.
Polemik yang terjadi mulai melahirkan klarifikasi demi klarifikasi. Mulai dari anggota dewan, SKPD terkait (Dinas Pendidikan), sampai ke Gubernur Anies Baswedan sendiri.
Pembelaan yang dilakukan berbagai macam (dan tidak jelas yang mana yang harus dipegang), mulai dari salah input, sampai bahwa data yang diinput adalah data dummy.
Dalam bahasa informatika, data dummy adalah data yang tidak informatif atau tidak bermakna, tapi berguna untuk mengisi ruang data yang sebenarnya. Maksudnya bagaimana?
Analogi sederhananya, seperti saat kita pergi ke tempat makan, kita berniat untuk mencari kursi kosong untuk kita tempati. Tapi, kita mungkin perlu ke toilet dulu sebelum memesan makanan.
Nah, untuk menjaga kursi yang kita incar tidak diambil orang lain, apa yang kita lakukan? Banyak cara, salah satunya meletakkan ransel kita di kursi tersebut, sebagai penanda bahwa kursi telah ditempati seseorang.
Ransel tersebut adalah dummy, tidak informatif (tidak dapat diketahui orangnya siapa) tetapi berguna untuk mengisi ruang data yang sebenarnya, dalam hal ini, data tersebut adalah kita sebagai orangnya.
Kembali ke lem aibon. Menurut Kadisdik DKI, data yang bermasalah tersebut adalah data dummy yang diinput Dinas Pendidikan karena dari tiap sekolah belum selesai menyediakan detail-detail tiap komponen yang ingin diadakan.
Untuk mengisi postur anggaran tersebut, diinputlah sembarang komponen, dalam hal ini kebetulan komponen tersebut adalah lem aibon, dan diisilah koefisien yang memungkinkan perhitungan sampai pada postur anggaran yang direncanakan.
Ada beberapa contoh lain yang terjadi dengan komponen yang berbeda seperti pulpen, dll. Data dummy tersebut akan diubah dengan komponen yang sebenarnya setelah proses pembahasan.
Munculah argumen kontra dari beberapa pihak.
"Harusnya gak bisa diinput sembarang begitu. Masa' uang rakyat dikira-kira", "Ini berarti tidak profesional. Harusnya ada perencanaan yang matang di tiap SKPD untuk detail pengadaan", "Harus ada sanksi bagi SKPD yang lambat menyusun komponen sampai harus membuat data dummy".
Ribut-ribut ini akhirnya membuat Gubernur Anies Baswedan angkat bicara. Gubernur membawa ide untuk meng-upgrade sistem. "Sistem itu sekarang sudah digital, but not smart" -- kata pak Gubernur.
Lebih jauh lagi, Gubernur Anies menyoroti sistem yang menerima inputan yang tidak wajar tersebut. "Kalau sistemnya smart, inputan yang tidak wajar itu harusnya ditolak".
Sebagai orang yang bergelut dibidang teknologi informasi dan pengembangan sistem elektronik, saya tertarik untuk mengangkat ini sebagai topik tulisan.
Terlepas dari perdebatan apakah ini merupakan tindak curi-curi kesempatan untuk 'bermain' anggaran atau murni salah input, tulisan ini hanya sebatas membahas dari sisi sistem saja, tentang ide dari Gubernur Anies Baswedan.
Mungkinkah membuat sistem yang bisa mendeteksi kesalahan input anggaran?
Validasi Digital dan Nilai Pembanding
Pertama-tama kita harus paham, bagaimana cara sistem elektronik yang tidak memiliki daya pikir seperti manusia, bisa melakukan pengecekan terhadap nilai yang diinputkan manusia ke dalam sistem.
Validasi yang dilakukan sistem elektronik sederhananya hanya merupakan perbandingan nilai berdasarkan suatu rule atau aturan. Nilai yang diinput manusia akan dibandingkan dengan suatu nilai lain yang jika hasil perbandingan tersebut tidak memenuhi kondisi yang diberikan, maka validasi dianggap gagal. Mari kita perjelas dengan gambaran yang lebih konkrit.
Misalkan ada suatu inputan, sebutlah sebuah input tanggal. Konteks dari inputan tersebut adalah tanggal untuk pemesanan tiket pesawat. Sebagai seorang perancang sistem elektronik, langkah pertama yang harus dilakukan adalah mendefinisikan rule atau aturan untuk inputan tersebut. Dalam kondisi apa input tanggal tersebut dianggap tidak valid? Sesuai konteks, kira-kira contoh rule yang masuk akal dalam kasus ini adalah sebagai berikut :
- Tanggal yang diinput harus cocok dengan format tanggal yang valid
- Tanggal yang diinput haruslah tanggal setelah tanggal hari ini
Rule pertama untuk mencegah user menginput nilai tanggal yang tidak valid (misalnya: 99-99-2099). Rule kedua untuk mencegah user menginput tanggal yang sudah lewat karena tidak mungkin memesan tiket pesawat untuk jadwal penerbangan yang sudah lewat.
Dalam satu rule, terdiri dari input atau nilai yang dimasukkan (kuning), operator pembanding (biru) dan nilai/ekspresi pembanding (hijau). Hasil evaluasi dari rule tersebut akan mengembalikan nilai kebenaran.
Apakah benar tanggal yang diinput cocok dengan format tanggal yang valid? Apakah benar tanggal yang diinput memiliki nilai lebih dari tanggal hari ini? Dalam kasus ini, jika satu saja kembalian dari evaluasi tersebut adalah tidak, maka validasi dianggap gagal dan tanggal tidak akan disimpan dalam sistem.
Sebagai contoh :
- Input tanggal : 11-22-2019
- Tanggal hari ini : 11-23-2019
Evaluasi :
Input
Operator Pembanding
Nilai Pembanding
Hasil Evaluasi
11-22-2019
Cocok/Sama dengan (=)
Format tanggal yang valid
Ya
11-22-2019
Setelah/Lebih dari (>)
11-23-2019
Tidak
Kesimpulan : tanggal 11-22-2019 adalah tanggal yang tidak valid karena tidak memenuhi satu dari dua rule yang ada.
Rule bisa bermacam-macam, tergantung kebutuhan sistem. Operator pembanding juga bisa jadi bukan sebuah operator matematika sederhana seperti sama dengan (=), tidak sama dengan (!=), kurang/lebih () dari dll, tapi bisa merupakan suatu ekspresi yang lebih kompleks seperti rumus, formula, atau algoritma khusus.
Teorinya, semua nilai yang diinput manusia dapat divalidasi selama rule untuk validasi tersebut bisa dirancang secara rigid. Artinya, si perancang sistem harus tau, harus menggunakan operator pembanding seperti apa dan mengambil nilai pembanding darimana. Dan itu adalah hal yang sangat krusial ketika kita berbicara spesifik ke kasus salah input anggaran di DKI Jakarta.
Ide Gubernur
Gubernur Anies menyalahkan sistem karena tidak menolak inputan janggal yang dimasukkan. Pertanyaannya sekarang: rule seperti apa yang harus dirancang untuk bisa menolak inputan yang janggal?
Dalam podcast dan video di channel YouTube Deddy Corbuzier, Gubernur Anies yang diundang mengatakan:
“Jadi, item yang banyak itu, data entrinya digital, ‘kan sistem nih, aplikasi, masukin. Tapi sesudah masuk, diperiksain satu-satu, ada nggak yang aneh, ini yang saya bilang nggak bisa. Kalau kita punya aplikasi, pada saat dia (pengguna) masukkin data, aplikasi itu harus nolak kalau orang itu masukkin angka yang nggak masuk akal. Misalnya nih, beli Aica-Aibon, per anak, 10 kilo, 82M, itu, aplikasinya sudah harus bilang ‘eh, anak ini mau diapain pake Aica-Aibon?’. Jadi yang kami lakukan itu, mengupgrade aplikasi agar bisa memaksa orang itu memasukan data yang benar”
Kata kunci yang penting dari kalimat pak Gubernur adalah “angka yang nggak masuk akal”. Pertanyaannya, angka seperti apa yang dianggap sebagai angka yang tidak masuk akal? Pak Gubernur memberi contoh seperti “10kilo”, “82M”.
Dari mana angka 82M ini muncul? 82M adalah hasil perhitungan harga komponen terhadap koefisien yang dimasukkan. Apa itu koefisien? Sederhanannya, koefisien adalah nilai/ekspresi yang akan menjadi acuan untuk seberapa banyak item komponen yang akan dibeli.
Dalam hal ini, koefisien yang diinput adalah 37000 orang dikali 12 bulan, sedangkan harga komponen per item adalah Rp.184000. Disini kita lihat, angka 82M itu tidak diinput, tapi merupakan hasil perhitungan dari angka-angka acuan ini yaitu harga barang dan koefisien. Dua input inilah yang harus disorot.
Harga
Logikanya, harga dianggap tidak valid ketika nilai harga tidak sesuai dengan pasaran. Bagaimana menjaga nilai harga komponen tetap berada pada nilai yang sesuai?
Dalam proses pengadaan barang dan jasa pada instansi pemerintahan, ada suatu dokumen yang dijadikan acuan untuk harga barang. Standar Satuan Harga. Ini adalah dokumen yang diatur pemerintah daerah untuk harga tiap komponen yang akan diadakan baik itu barang atau jasa.
Mari kita kembali merancang rule.
Harga yang diinput harus cocok dengan standar satuan harga
Rule ini bisa diterapkan dengan syarat nilai standar satuan harga itu bisa diakses secara elektronik dan terintegrasi dengan sistem e-Budgeting. Bahkan, dengan infrastruktur ini, orang tidak lagi menginput harga secara manual, tetapi harga langsung diambil dari standar satuan harga.
Saya tidak tahu secara detail apakah para pengembang di ibu kota menerapkan teknik ini atau tidak tapi mari kita asumsikan bahwa standar satuan harga telah terintegrasi secara elektronik. Ini tetap melahirkan masalah baru.
Nilai harga yang ada di sistem standar satuan harga (e-Harga) tetap harus diinputkan oleh manusia. Bagaimana kalau ini dimanipulasi? Otomatis, sistem e-Budgeting untuk pengadaan barang dan jasa akan mendapatkan standar baru yang sudah dimanipulasi. Misalnya, SKPD ingin mengadakan suatu item dengan nilai harga yang ‘dilebihkan’.
Normalnya, nilai tersebut akan ditolak oleh e-Budgeting karena melebihi nilai harga komponen pada standar satuan harga. Tetapi jika nilai pada standar satuan harga tersebut ‘dilebihkan’, maka harga siluman ini akan bisa masuk di e-Budgeting. Pertanyaan muncul. Bagaimana menjaga nilai harga pada sistem standar satuan harga (e-Harga) agar tetap valid? Harus ada nilai pembanding untuk harga tersebut.
Bagaimana menjaga nilai pembanding ini tetap valid? Harus ada nilai pembanding lagi untuk pembanding tersebut. Begitulah seterusnya. Lahirlah sebuah lingkaran setan yang tak berujung.
Seperti perdebatan soal dewan pengawas KPK. Siapa yang akan mengawasi pengawas? Dan siapa yang akan mengawasi pengawasnya pengawas? Soal yang tak pernah berakhir.
Koefisien
Koefisien ini adalah yang paling tricky. Masalahnya, kita tidak tahu kebutuhan suatu SKPD untuk seberapa banyak jumlah item komponen yang ingin diadakan. Misalnya dalam kasus lem Aibon, kalau nilai koefisien 37000 orang x 12 bulan dianggap tidak wajar, lalu sampai batas mana koefisien itu dianggap wajar? Misalnya, dibatasi hanya bisa sampai 10000 orang.
Diatas itu dianggap tidak wajar. Bagaimana kalau pengguna komponen memang benar-benar diatas 10000 orang? Seperti alat tulis atau kertas ujian untuk para siswa misalnya. Bisa jadi memang benar-benar diatas 10000 orang pemakainya. Berlaku juga dengan koefisien waktu.
Jadi seperti apa yang diinginkan? Mari merujuk kembali ke pernyataan pak Gubernur.
“Misalnya nih, beli Aica-Aibon, per anak, 10 kilo, 82M, itu, aplikasinya sudah harus bilang ‘eh, anak ini mau diapain pake Aica-Aibon?’”
Pak Gubernur menyorot merk komponen dengan pihak yang akan memakainya. Lem Aibon dengan para siswa. Artinya, ada korelasi antara merk komponen dengan pemakai, apakah pemakai tersebut layak menggunakan komponen itu.
Misalnya, siswa menggunakan lem Aibon 10 kilo, per bulan, dianggap tidak wajar. Masalahnya, dalam sistem e-Budgeting, pemakai item komponen disederhanakan menjadi ‘orang’, tidak menjelaskan spesifik seperti ‘siswa’, ‘anak’, dll. PR yang harus dilakukan adalah mendefinisikan semua status perorangan, pengguna item komponen.
Disini akan terlalu banyak kombinasi. Misalnya status umur orang tertentu tidak bisa menggunakan item komponen tertentu dalam jumlah tertentu, jabatan tertentu tidak bisa mengunakan item komponen tertentu dalam jumlah tertentu, bahkan hubungan struktur birokrasi bisa jadi penentu seseorang bisa dianggap layak menggunakan suatu item komponen dalam jumlah tertentu pula.
Terlalu banyak kasus. Pemerintah harus mendefinisikan setiap rule ini dalam bentuk yang rigid entah itu sebagai suatu SK atau regulasi. Misalnya: lem Aibon tidak layak digunakan oleh siswa jika jumlah item lem lebih dari 10000 per bulan.
Kenapa harus didefinisikan sedetail dan se-spesifik itu? Karena sistem harus memiliki patokan yang pasti. Program komputer tidak bisa memproses suatu rule yang ambigu. Harus jelas dan spesifik. Sangat merepotkan memang, tetapi itu bisa dilakukan.
Mari asumsikan ini berhasil dilakukan. Pemerintah sukses mendefinisikan semua rule untuk pengadaan barang dan jasa sesuai masing-masing individu yang membutuhkannya dan menginputnya ke sistem. Apa ini menyelesaikan masalahnya? Sayang sekali belum. Bagaimana kalau rule ini diubah untuk mengakomodir inputan siluman?
Misalnya rule aibon tadi diubah menjadi : lem Aibon tidak layak digunakan oleh siswa jika jumlah item lem lebih dari 9999999999999 per bulan. Maka, inputan koefisien untuk lem Aibon bisa dibuat membludak. Bagaimana mencegah rule ini terjadi?
Buat rule untuk memvalidasi rule tersebut. Bagaimana mencegah rule untuk menvalidasi rule tersebut tetap layak? Buat rule untuk menvalidasi rule yang memvalidasi rule. Begitu seterusnya. Kita masuk lagi ke lingkaran setan tadi.
Dari sini kita simpulkan, kita tidak bisa menggunakan pendekatan elektronik 100% untuk melakukan kontrol terhadap inputan-inputan ini. Saatnya kita – dan pak Gubernur - melirik pendekatan lain untuk memutus lingkaran setan itu, atau bahkan, menghindari terjebak di dalamnya.
Memutus Lingkaran Setan
Esensi dari e-Budgeting sebenarnya bertumpu bukan pada validasi otomatis secara elektronik, tetapi kontrol dan transparansi. Maka, sistem e-Budgeting yang baik adalah yang memiliki kemampuan mengekspos data yang perlu diketahui publik dan mengakomodir pengecekan secara bertahap sesuai birokrasi, agar ketika sampai ke publik, data ini bisa benar-benar bisa dipertanggung-jawabkan.
Misalnya, dana lem Aibon yang diinputkan staff pada Dinas Pendidikan tersebut, harus dicek terlebih dahulu oleh Kepala Seksi, Kepala Bidang, sampai Kepala Dinas, baru bisa naik sebagai informasi publik.
Kejadian sekarang membuktikan tidak adanya sistem kontrol dalam SKPD itu sendiri, dalam hal ini Dinas Pendidikan. Paradigma yang dipakai dalam sistem kontrol yang dimaksud, berorientasi kepada tanggung jawab para pejabat yang ada dalam instansi, alih-alih bergantung pada rule sistem elektronik semata.
Kemudian pertanyaan muncul: “Kalau demikian, kapan lingkaran setan ini akan berakhir? Bukankah kontrol oleh manusia lebih rawan?”
Jawabannya ada di transparansi. Ketika produk kontrol oleh para birokrat ini bisa diakses publik, proses di dalam instansi menjadi seperti aquarium, bisa diintip dari segala sisi. Ketika publik menilai produk birokrasi ini tidak benar, maka tuntutan keberatan bisa memicu adanya pengecekan terhadap proses birokrasi yang terjadi sebelumnya.
Akan ketahuan, siapa sih yang meloloskan inputan yang aneh ini? Sistem e-Budgeting yang ideal akan me-record setiap ada persetujuan item komponen baik itu dari Kepala Seksi, Kepala Bidang, Kepala Dinas, maupun pejabat lain yang berhubungan.
Apa keuntungannya? Selain fungsi kontrol, performa para birokrat juga bisa terlihat. Alhasil, para pengambil kebijakan bisa memilih untuk mengevaluasi para birokrat yang tidak perform dengan baik dalam tupoksi mereka.
Jadi pak Gubernur alih-alih berfokus membenahi sistem elektronik untuk otomatis memvalidasi inputan, buat saja sistem yang membuat mereka ‘takut’ untuk bermain, dengan kesadaran bahwa pekerjaan mereka sedang dipantau masyarakat bahkan pak Gubernur sendiri.
Lagipula, aneh kalau pak Gubernur menyoroti repotnya memeriksa satu-satu item komponen pake mata. Bukankah itu sudah menjadi tanggung jawab para birokrat? Terlebih lagi, item komponen tetap akan melalui proses pembahasan di DPRD, yang disana akan dilakukan penyisiran satu per satu. Sama saja. Dalam hal sepenting uang rakyat, pengecekan manual adalah hal yang tidak terhindarkan.
Mari kita mengubah paradigma kita tentang sistem. Jangan sampai kita terjebak pada masalah yang tidak substansial, sementara banyak PR yang harus diselesaikan dalam birokrasi, manusia-manusia itu sendiri.
Rasanya tidak berlebihan berkata bahwa, secanggih apapun sistem elektronik, kalau penggunanya tidak andal, percuma saja. Secanggih apapun mobil F1, kalau pengendaranya amatir, semua sia-sia.
