APA ITU SPAN?
SPAN (Sistem Perbendaharaan dan Anggaran Negara) merupakan salah satu bagian dari target proyek GFMRAP (Government Financial Management and Revenue Administration Project) yang menurut jadwal awal akan berakhir pada akhir tahun 2008. Proyek GFMRAP yang nilai keseluruhannya sekitar US$ 250 juta menurut rencana akan diselesaikan dalam kurun waktu 12 tahun (2004-2015) yang dibagi dalam 3 fase, yakni GFMRAP-1 (2004-2008), GFMRAP-2 (2006-2010) dan GFMRAP-3 (2010-2015). Sebagai catatan bahwa kondisi penyelesaian proyek GFMRAP-1 sangat menentukan apakah fase-fase proyek berikutnya (GFMRAP-2 dan GFMRAP-3) dapat dimulai pengerjaannya.
Lahirnya proyek GFMRAP merupakan upaya pemerintah untuk mewujudkan ide reformasi di bidang keuangan negara yang telah dirumuskan dalam Buku Putih (Reform of the Public Financial Management System in Indonesia, 2003) Departemen Keuangan (catatan: Buku Putih/White Paper merupakan hasil kajian Komite Penyempurnaan Manajemen Keuangan tentang sistem manajemen keuangan kita yang lama/existing dan konsep reformasi manajemen keuangan pemerintah yang kita usulkan/proposed). Proyek GFMRAP yang sebagian besar dananya dibiayai melalui pinjaman Bank Dunia tersebut merupakan inisiatif pemerintah Indonesia (yang dalam hal ini diwakili oleh Menkeu Budiono) yang pada bulan Oktober 2003 mengajukan proposal proyek tersebut kepada Bank Dunia.
SPAN yang komponen biaya(fisik dan non-fisik)nya sekitar US$ 80 juta (IBRD=US$ 55 juta, IDA=US$ 5 juta, Japan Grant = US$ 5 juta, GOI counterpart=US$ 15 juta) dimaksudkan sebagai suatu sistem pengelolaan keuangan negara (anggaran dan perbendaharaan negara) yang modern dan terintegrasi. Ruang lingkup SPAN meliputi fungsi penyusunan anggaran, manajemen otoritas pembelanjaan (spending authority), manajemen komitmen, manajemen pembayaran, proses penerimaan negara, modul akuntansi (general ledger dan chart of accounts), manajemen kas, pelaporan, dan pemeliharaan data tabel referensi.
Satu hal yang perlu diketahui bahwa, menurut rencana, pengelolaan basis data dalam SPAN akan dilakukan secara terpusat (centralized), walaupun owner dan tanggungjawab pemeliharaan (update) datanya mungkin tetap berada pada instansi penyimpan (penanggungjawab kebenaran) dokumen sumber. Dalam hal ini direktorat yang menangani teknologi informasi di kantor pusat hanya berperan sebagai fasilitator yang menyediakan jasa akses secara aman, sesuai otoritas kewenangannya, bagi KPPN dan unit-unit kerja pemerintah lainnya. Dengan demikian, berdasarkan dokumen sumber dan peraturan perbendaharaan, pegawai KPPN dapat melakukan perekaman (upload) dan perbaikan (update) data penerimaan dan pengeluaran negara yang basis datanya berada pada server kantor pusat. Efektivitas sistem pengelolaan basis data secara tersentralisasi tersebut jelas sangat tergantung pada sejauhmana alat komunikasi data yang digunakan dapat bekerja secara efektif.
Selain itu, menurut rencana, dalam SPAN kita tidak lagi menggunakan program aplikasi yang dibuat dan diperbaiki oleh programer sesuai dengan kebutuhan organisasi. Sebagai penggantinya, kita akan menggunakan paket software aplikasi (yang telah jadi) yang disebut COTS (Commercial Off-The-Shelf) yang beragam jenisnya tersedia dan dapat dibeli di pasar. Hal yang paling penting kita perhatikan di sini adalah memutuskan paket software aplikasi mana yang kita pilih untuk memenuhi kebutuhan organisasi kita.
LATAR BELAKANG SPAN
Keinginan untuk melakukan suatu perubahan (reformasi) terhadap suatu sistem biasanya muncul ketika kita melihat dan menyadari adanya sejumlah kelemahan pada sistem yang sedang berjalan dan kita menemukan ide untuk mengatasi masalah tersebut. Ide yang melahirkan SPAN juga bertolak dari sejumlah masalah yang ditemukan pada sistem perbendaharaan dan anggaran kita yang sedang berjalan.
Salah satu masalah utama yang selalu terjadi, dari tahun ke tahun, dalam sistem pengelolaan anggaran kita adalah masalah pemeliharaan dan konsistensi basis data anggaran. Pengelolaan basis data anggaran yang baik semestinya mampu mengintegrasikan proses perekaman dan perbaikan data anggaran yang terjadi pada Ditjen Anggaran, Ditjen Perbendaharaan (Dit PA, Kanwil DJPB dan KPPN) dan unit-unit (kuasa) pengguna anggaran pada masing-masing Kementerian/Lembaga Negara sedemikian rupa sehingga meskipun masing-masing unit tersebut mempunyai tingkat kewenangan yang berbeda dalam memperbaiki basis datanya, tetapi konsistensi perubahan basis data pada masing-masing unit tersebut harus tetap dapat dipertahankan. Dalam hal ini kadang saya membayangkan sejauhmana sebenarnya tingkat konsistensi data anggaran dapat kita jaga/pertahankan seandainya kita lakukan suatu rekonsiliasi data anggaran tingkat nasional antara masing-masing unit tersebut (DJA, DJPB dan Departemen Teknis selaku pengguna anggaran).
Di lingkungan Ditjen Perbendaharaan saya kira kita bisa melihat secara lebih jelas masalah pemeliharaan dan konsistensi basis data anggaran pada Dit. PA (Kantor Pusat), Bidang PA Kanwil, dan KPPN. Silakan memprediksi hasil yang akan kita dapatkan seandainya kita lakukan rekonsiliasi basis data anggaran antara Dit. PA, Bidang PA Kanwil dan KPPN. Berbagai kasus yang selama ini sering terjadi seperti revisi (pengurangan) pagu DIPA oleh Dit. PA yang tidak memperhatikan revisi DIPA dimaksud di Kanwil dan realisasi dana DIPA tersebut
di KPPN saya kira merupakan salah satu dampak yang kita rasakan akibat pengelolaan basis data anggaran yang tidak kita kelola secara baik.
Pengelolaan basis data realisasi pengeluaran dan penerimaan kita pun ternyata mengalami nasib yang cukup memprihatinkan. Sebagaimana kita ketahui, selama ini KPPN diminta untuk mengirimkan softcopy data harian Bendum dan data harian Vera ke DSP. Bidang Aklap Kanwil juga mempunyai kewajiban untuk mengirimkan softcopy data harian Aklap (yang merupakan kompilasi data harian Vera KPPN-KPPN di wilayah kanwil tersebut) ke DSP. Selain itu, bersamaan dengan pengiriman LKPP bulanan, Seksi Vera KPPN setiap bulan juga mengirimkan softcopy data (akumulasi) bulanan Vera ke Dit. APK (Akuntansi dan Pelaporan Keuangan). Demikian pula, bersamaan dengan pengiriman LKPP triwulanan, Bidang Aklap Kanwil setiap triwulan juga mengirimkan softcopy data (akumulasi) triwulanan ke Dit. APK. Dengan demikian, selain basis data di KPPN dan Kanwil, paling tidak terdapat tiga basis data pengeluaran dan penerimaan di DSP.
Tidak adanya single database di KPPN dan juga di Kantor Pusat telah mengakibatkan munculnya peluang terjadinya selisih data/ laporan realisasi penerimaan dan pengeluaran yang dihasilkan oleh DSP, Dit. PKN dan Dit. APK. Akibatnya, diperlukan proses rekonsiliasi data antar unit-unit terkait yang memerlukan waktu cukup lama dan dengan hasil yang seringkali kurang memuaskan.
Dalam kondisi multiple database yang kita miliki tersebut, selisih data penerimaan dan pengeluaran antar unit di kantor pusat (misalnya, antara data Bendum DSP dan data Bendum/Buku Merah Dit. PKN) dapat terjadi karena kesalahan prosedural atau kesalahan aplikasi. Kesalahan prosedural dapat terjadi kalau Dit. PKN minta KPPN memperbaiki datanya dan mengirimkan(softcopy/hardcopy data)nya ke Dit. PKN tetapi tidak mengingatkan KPPN untuk mengirimkan juga (softcopy) perbaikan data tersebut ke DSP.
Sementara itu, kesalahan aplikasi dapat terjadi kalau perlakuan (cara membaca) aplikasi pada masing-masing basis data (missal, aplikasi Bendum di KPPN dan aplikasi Bendum di Dit. PKN) terhadap data yang sama berbeda. Kebetulan saya pernah menyaksikan sendiri, ketika menguji data KPPN Tangerang yang dinyatakan “salah” oleh Dit. PKN, adanya kesalahan (membaca data pada) aplikasi Bendum di Dit. PKN. Hal tersebut membuktikan bahwa APLIKASI yang sama (misal, Bendum) pada basis data yang berlainan pun (sama dengan basis datanya) ternyata PERLU DIREKONSILIASI.
Dari sisi data penerimaan, di luar basis data pengeluaran dan penerimaan tersebut di atas, kita juga mempunyai basis data MPN Pusat yang dalam skenario modul MPN harus selalu dijaga kesamaannya melalui rekonsiliasi dengan (1) basis data penerimaan yang ada pada Bank-bank Persepsi Pusat (termasuk Bank-bank Pembangunan Daerah yang tercatat sebagai Bank Persepsi) dan (2) basis data penerimaan yang ada pada aplikasi Bendum KPPN (yang diterima dari bank-bank persepsi mitra KPPN yang bersangkutan). Perlu diketahui bahwa aplikasi modul MPN di pusat dikembangkan dan dipelihara oleh Ditjen Pajak (melalui outsourcing dengan pihak ketiga), sedangkan aplikasi modul MPN di daerah (yang digunakan oleh bank-bank persepsi di daerah) dikembangkan dan dipelihara oleh masing-masing Bank Persepsi yang bersangkutan (sebagian bank persepsi menggunakan outsourcing).
Sayang sekali skenario rekonsiliasi modul MPN tersebut, paling tidak sepanjang tahun 2007, tidak berjalan sebagaimana mestinya. Hal tersebut terjadi selain karena pengoperasian aplikasi rekonsiliasi antara data MPN Pusat dan data penerimaan Bendum KPPN (yang dulu disiapkan oleh Pak Puja) belum dapat berjalan secara efektif juga karena rekonsiliasi otomatis antara basis data MPN Pusat dan basis data penerimaan pada Bank-bank Persepsi Pusat belum dilengkapi dengan sarana dan prosedur yang applicable yang memungkinkan Bank Persepsi Pusat Pusat untuk menindaklanjuti data penerimaan yang TIDAK SAMA, yang merupakan hasil
rekonsiliasi tersebut.
Konsekuensinya, untuk menutup kelemahan modul MPN tersebut, hingga kini para petugas helpdesk di Subdit Pengembangan Aplikasi (yang dibantu oleh para pegawai di Subdit Pengelolaan dan Komunikasi Data) DSP harus melakukan “rekonsiliasi semi otomatis/manual” terhadap basis data penerimaan yang ada di pusat, yakni antara data penerimaan MPN Pusat, Bank Persepsi Pusat, dan data penerimaan Bendum KPPN yang telah diterima oleh DSP. Sementara itu DSP berharap KPPN dapat memeriksa kebenaran transaksi data penerimaan yang TIDAK SAMA hasil rekonsiliasi tersebut dengan cara membandingkannya dengan dokumen sumber yang ada di KPPN.
Sekarang, setelah melihat kompleksitas pengelolaan basis data realisasi penerimaan dan pengeluaran di lingkungan DJPB, kita mungkin bisa membayangkan hasil apa yang akan kita dapatkan seandainya kita lakukan rekonsiliasi antar seluruh basis data pengeluaran dan penerimaan yang ada di lingkungan DJPB.
Berbagai permasalahan TI dan proses bisnis yang selama ini tidak mampu kita selesaikan secara tuntas, sebagaimana telah diuraikan tersebut di atas, barangkali telah membuat para pejabat kita di kantor pusat untuk mempertimbangkan solusi melalui outsourcing. Namun, kalau kita perhatikan pengalaman di masa lalu, sebenarnya kita juga pernah berkali-kali mengalami
kegagalan dalam melaksanakan proyek berbasis TI melalui outsourcing, bahkan diantaranya dengan hasil yang sama sekali nihil. Proyek Orafin Bakun, dan juga proyek modul MPN yang saat ini sedang diupayakan perbaikan sistem/aplikasi-nya (oleh Ditjen Pajak dengan bantuan outsourcing) agar tidak terus menghasilkan data “sampah”, merupakan contoh paling mutakhir dari kegagalan proyek pengembangan TI kita.
Perlu diketahui bahwa kali ini kita dihadapkan pada tantangan yang jauh lebih besar, yakni membangun suatu sistem pengelolaan anggaran dan perbendaharaan negara (SPAN) yang modern dan terintegrasi. Lalu, apa sebenarnya yang ingin diperoleh melalui proyek SPAN?
TUJUAN SPAN
SPAN mempunyai dua tujuan utama. Pertama, mengendalikan anggaran negara, aset dan kewajiban (liability) pemerintah pusat. Kedua, menyediakan informasi tentang posisi kas pemerintah yang komprehensif, dapat dipercaya dan tepat waktu guna membantu efektivitas manajemen keuangan pemerintah.
APA YANG DIHARAPKAN DARI SPAN?
Secara umum pembangunan SPAN yang modern dan terintegrasi diharapkan akan membuat pengelolaan keuangan negara menjadi efisien dan efektif, pelayanan publik menjadi prima dan praktek korupsi dapat dicegah atau paling tidak bisa diminimalkan.
Selain itu, dengan dukungan teknologi informasi, SPAN diharapkan dapat menyediakan (1) perbaikan-perbaikan yang cukup signifikan dalam hal transparansi fiskal (kapasitas untuk mengakses, menganalisis dan melaporkan kegiatan-kegiatan fiskal pemerintah), (2) sistem akuntansi dan pelaporan keuangan pemerintah yang cepat dan tepat, (3) koneksi online ke Bank Indonesia dan jaringan perbankan lainnya yang memungkinkan pengoperasian TSA yang
terintegrasi dengan sistem RTGS secara aman, (4) prediksi kas jangka pendek dan menengah yang mampu mengoptimalkan esisiensi penyediaan dana melalui sistem perbankan, (5) pengawasan (verifikasi) yang efektif terhadap setiap transaksi pengeluaran negara, dan (6) sistem penganggaran terpusat yang memungkinkan unit-unit pengguna (Bappenas, Departemen Teknis, DPR) untuk berpartisipasi dalam proses penyusunan anggaran.
APA YANG SUDAH KITA LAKUKAN UNTUK SPAN?
Dalam kaitannya dengan proses pengembangan SPAN, sekretariat GFMRAP (Subdit Dukungan Administrasi pada Direktorat Sistem Perbendaharaan) telah memfasilitasi sejumlah kegiatan seperti pengadaan konsultan dan kontraktor, pembentukan tim-tim (pengadaan, fungsional, teknologi informasi, manajemen perubahan dan komunikasi), pelatihan dan seminar/workshop/sosialisasi yang terkait dengan pengembangan SPAN.
Sesuai dengan ketentuan, proses pengadaan kontraktor SPAN harus dilakukan melalui dua tahap. Pengadaan kontraktor tahap pertama (dimana nominal harga penawaran belum dicantumkan atau masuk dalam kriteria seleksi/penilaian) telah menghasilkan tiga calon kontraktor SPAN. Proses pengadaan kontraktor tahap dua saat ini masih berlangsung. Ketiga calon kontraktor SPAN telah menyampaikan aplikasinya kepada tim pengadaan pengembangan SPAN. Pembukaan amplop aplikasi (bidding) calon kontraktor SPAN yang menurut rencana akan dilaksanakan pada awal tahun 2008 ditunda (diperkirakan sekitar bulan Maret atau April 2008) karena menunggu hasil kajian terhadap SPAN (yang dilakukan oleh Pak Herwidyatmo, seorang staf Menkeu, dan para konsultan SPAN) yang semula menurut rencana akan dilaporkan pada tanggal 12 Februari 2008. Berdasarkan informasi terakhir yang saya terima, rekomendasi hasil kajian staf Menkeu tersebut akan disampaikan ke Menkeu pada tanggal 28 Februari 2008.
Perlu diketahui bahwa kajian terhadap SPAN tersebut dilakukan atas permintaan Menkeu sebagai bahan pengambilan keputusan tentang skenario pilihan terbaik bagi pengembangan SPAN. Artinya, kemungkinan proyek pengembangan SPAN dihentikan, dilaksanakan sesuai rencana yang ada sebelumnya, atau dilaksanakan dengan melakukan sejumlah perubahan terhadap rencana sebelumnya.
Setelah pembukaan amplop aplikasi penawaran (bidding), kita perlu melakukan kegiatan evaluasi terhadap dokumen penawaran tersebut yang biasanya makan waktu sekitar tiga bulan, pengumuman pemenang kontraktor pengembangan SPAN, fit/gap analysis oleh kontraktor SPAN, dan penandatangan kontrak pengembangan SPAN. Berdasarkan kondisi saat ini, diperkirakan penandatangan kontrak akan berlangsung sekitar akhir tahun 2008. Dengan demikian, proses implementasi pengembangan SPAN (yang melibatkan kontraktor SPAN, para konsultan SPAN, dan tim counterpart SPAN) diperkirakan baru dapat mulai dilaksanakan pada awal tahun 2009.
Perlu diketahui bahwa proses pengembangan SPAN (termasuk kegiatan ujicoba sistem aplikasinya) diperkirakan membutuhkan waktu kurang lebih tiga tahun. Sebagai catatan, implementasi proyek pengembangan treasury di Kazakhstan, yang dinilai oleh Bank Dunia sebagai proyek percontohan pengembangan treasury (note: tidak termasuk budget preparation) yang berhasil, membutuhkan total waktu selama tujuh tahun.
Hal lain yang perlu digarisbawahi bahwa target pengembangan SPAN (yang nilainya sekitar US$ 80 juta) yang akan dikerjakan oleh kontraktor SPAN tidak mencakup konsep pengembangan SPAN secara menyeluruh (yang antara lain meliputi modul MPN dan modul TSA). Pengadaan modul MPN (yang telah diimplementasikan mulai awal tahun 2007) dan modul fully IT-based TSA (yang menurut rencana awal akan diimplementasikan pada tahun 2008) tidak termasuk pengadaan yang dibiayai dengan dana yang tersedia untuk pengembangan SPAN.
Demikian pula semua aplikasi akuntansi pada unit (kuasa) pengguna angaran (dari tingkat instansi hingga tingkat departemen), Ditjen Pengelolaan Utang (PU) dan Ditjen Pengelolaan Kekayaan Negara (PKN), menurut rencana, akan tetap dipelihara dan dikembangkan oleh para programer di DSP. Meskipun demikian, Ditjen PU dan Ditjen PKN disertakan dalam keanggotaan tim SPAN karena aplikasi treasury non-akuntansi mereka termasuk dalam pengadaan pengembangan SPAN.
Satu hal yang perlu juga diketahui bahwa (please CMIIW) hingga saat ini tim SPAN masih belum mempunyai dokumen blueprint atau arsitektur SPAN yang telah disepakati secara bersama. Menurut rencana, setelah kontraktor SPAN melakukan evaluasi terhadap semua kebutuhan dalam SPAN, kita berharap mereka dapat mengusulkan blueprint SPAN untuk kita.
PERMASALAHAN DAN TANTANGAN DALAM PENGEMBANGAN SPAN
Berdasarkan kegiatan-kegiatan yang terkait dengan proses pengadaan dan pengembangan SPAN yang selama ini telah kita lakukan, terdapat sejumlah isu permasalahan yang menurut saya menarik untuk didiskusikan. Beberapa hal yang ingin saya sampaikan di sini adalah isu tentang masalah keterlibatan tim SPAN yang tidak optimal, pro-kontra seputar implementasi proyek pengembangan SPAN, bisnis dalam proyek pengembangan teknologi informasi, dan intervensi Bank Dunia.
Salah satu hambatan utama dalam pengembangan SPAN adalah keterlibatan anggota tim SPAN yang tidak optimal. Kontribusi anggota tim SPAN tidak bisa optimal karena, pertama, mereka tidak ditugaskan secara penuh (full-dedicated). Dengan kata lain, pengembangan SPAN hanya merupakan “pekerjaan sambilan” di luar tupoksi yang harus mereka kerjakan. Kedua, para anggota tim SPAN dari waktu ke waktu sering mengalami perubahan, yang antara lain disebabkan oleh pelaksanaan mutasi pegawai,. Akibatnya, mereka yang baru ditunjuk sebagai anggota tim SPAN harus mulai belajar konsep dan rencana pengembangan SPAN mulai dari nol lagi.
Wacana yang selama ini berkembang untuk mengatasi masalah tersebut adalah dengan menyediakan wadah organisasi dimana para pegawai yang ditugaskan untuk menangani pengembangan SPAN dapat bekerja secara penuh (bukan part-time) bersama dengan pihak kontraktor SPAN dan tim konsultan SPAN. Sebagaimana kita ketahui, Subdit Dukungan Administrasi di DSP juga merupakan organisasi struktural yang sengaja dibentuk (pada tahun 2006) untuk mewadahi organisasi proyek (Sekretariat GFMRAP) yang kegiatannya tidak mungkin dititipkan/disisipkan pada unit organisasi struktural lainnya. Selain itu, kebijakan mutasi pegawai semestinya juga mendukung kebutuhan SDM yang diperlukan dalam pengembangan SPAN.
Tantangan pengembangan SPAN berikutnya adalah terkait dengan pro dan kontra dalam implementasi pengembangan SPAN. Konflik dan perbedaan pendapat dalam implementasi proyek pengembangan TI sebenarnya merupakan hal yang biasa dan seringkali terjadi. Konflik dapat terjadi antara unit pengguna dan unit pengembang (kontraktor) maupun antara sesama unit pengguna (misalnya, antara tim proses bisnis dan tim TI). Manajemen proyek seharusnya sudah bisa mengantisipasinya, misalnya dengan memberdayakan atau memperkuat unit manajemen perubahannya. Intinya, setiap permasalahan atau perselisihan dalam pengembangan TI sedapat mungkin agar diselesaikan dan diputuskan oleh mereka yang ahli dalam manajemen proyek (bukan oleh pejabat struktural yang membawahinya), yang menurut tupoksi merupakan tanggungjawab mereka yang ada dalam unit manajemen perubahan.
Mengenai pro-kontra dalam konsep pengembangan SPAN, saya pernah mendengar pendapat seorang teman yang menyatakan bahwa dalam praktek unit atau kelompok TI terlalu mendominasi proses penyusunan blueprint dan proses bisnis SPAN. Padahal, menurut pendapatnya, semestinya proses bisnis SPAN merupakan kewenangan sepenuhnya tim proses bisnis (fungsional). Dalam hal ini semestinya tim TI hanya berfungsi melayani untuk menterjemahan proses bisnis SPAN yang telah ditetapkan ke dalam pengadaan infra struktur TI, termasuk sistem aplikasinya, yang dapat memfasilitasi proses bisnis tersebut.
Kepada teman saya tersebut saya hanya mengatakan bahwa keberhasilan suatu proses bisnis (serangkaian kegiatan yang menghasilkan suatu output) sangat tergantung pada (dipengaruhi oleh) sarana TI yang digunakan, organisasi dan SDM yang melaksanakannya dan peraturan yang mendukungnya. Oleh karena itu, menurut saya, mereka yang terkait dengan bidang tugas tersebut semestinya dilibatkan dalam proses penyusunan atau perubahan proses bisnis. Dalam proses penyusunan proses bisnis, kelompok TI misalnya diharapkan dapat menyumbangkan pemikirannya untuk memanfaatkan perkembangan TI guna menyederhanakan proses bisnis. Dengan kata lain, kegiatan penyusunan proses bisnis memang merupakan tupoksi unit proses bisnis, tetapi proses bisnis (SOP) kegiatan penyusunan/perubahan proses bisnis, menurut saya, semestinya melibatkan unit-unit terkait yang telah saya sebut di atas.
Isu pro-kontra tentang implementasi pengembangan SPAN juga bisa dilihat dari sisi mereka yang optimis dan mereka yang pesimis terhadap pengembangan SPAN yang saat ini sedang dalam kajian staf ahli Menkeu. Mereka yang optimis cenderung mengatakan bahwa bagaimanapun pengembangan SPAN harus tetap dilaksanakan karena ia merupakan the only way menuju pengelolaan keuangan negara secara profesional dan modern. Menurut mereka, perasaan pesimis sebaiknya dihindari karena ia dikhawatirkan dapat mematahkan semangat mereka yang saat ini sedang berusaha mengembangkan dan mewujudkan SPAN. Sebaliknya,
perasaan optimis harus terus kita pompa dan pelihara supaya kita berhasil menemukan the best way untuk implementasi pengembangan SPAN.
Sementara itu mereka yang pesimis cenderung mengatakan bahwa kemungkinan besar proses pengembangan SPAN akan mengalami nasib yang (kurang lebih) sama dengan proyek-proyek pengembangan TI berskala besar sebelumnya yang pernah kita kelola. Menurut mereka, perasaan optimis yang berlebihan dikhawatirkan dapat mengurangi kehati-hatian kita dalam melaksanakan proses pengembangan SPAN. Sebagaimana kita ketahui, faktor utama penyebab kegagalan proyek-proyek pengembangan TI kita sebelumnya bersumber dari ketidakhati-hatian kita dalam menyusun konsep pengembangan TI maupun dalam melakukan ujicoba pelaksanaan operasional sistem aplikasinya.
Terus terang saya tidak tertarik untuk memilih salah satu di antara keduanya. Saya lebih tertarik untuk mengetahui hal-hal yang berpotensi untuk menghambat implementasi pengembangan SPAN dan juga hal-hal yang dapat digunakan sebagai solusi untuk mengatasi masalah dalam proses pengembangan SPAN.
Satu hal yang perlu ditegaskan kembali adalah bahwa potensi terjadinya konflik atau perbedaan pendapat dalam implementasi pengembangan SPAN sungguh sangat besar karena ia bisa merambah di seluruh unsur/bagian SPAN dan juga pada setiap tahapan perubahan yang direncanakan. Dalam hal ini saya hanya berharap mereka yang berada pada unit Change Management and Communication- dapat berperan secara maksimal. Selain itu, nasehat dari seorang penulis artikel tentang change management (saya lupa namanya) berikut ini mungkin berguna untuk kita ambil hikmah(sisi positip)nya. Intinya, agar supaya kita berupaya memelihara kesepakatan dan keajegan tentang tujuan dan sasaran organisasi yang sudah kita
tetapkan sebelumnya, tetapi membuka lebar-lebar metode, cara dan strategi untuk mencapai tujuan tersebut.
Tantangan dalam pengembangan SPAN lainnya adalah yang saya sebut sebagai praktek bisnis dalam proyek pengembangan TI. Sebenarnya praktek bisnis yang akan saya kemukakan dalam tulisan ini hamper sama dengan praktek bisnis yang terjadi dalam setiap proses pengadaan barang dan jasa dalam skala besar. Tiga hal yang saya kemukakan berikut ini hanya dimaksudkan agar kita mewaspadai kemungkinan dampak negatip profit-seeking behavior dari para pemain kunci dalam proses implementasi pengembangan SPAN.
Pertama, para calon kontraktor proyek pengembangan TI biasanya melakukan lobby atau pendekatan (bila perlu melakukan suap atau memberikan gratifikasi) kepada sejumlah pejabat yang mempunyai kekuasaan untuk mempengaruhi keputusan penetapan kontraktor pemenang dalam tender proyek. Apabila mereka melakukan suap kepada sejumlah pejabat dan masing-masing pejabat yang bersangkutan merespon pendekatan mereka, maka selain dana efektif proyek akan berkurang apabila mereka menjadi pemenang juga kondisi demikian dapat memicu konflik kepentingan antar para pejabat yang bersangkutan.
Kedua, keberhasilan kontraktor pemenang dalam menyelesaikan proyeknya tergantung pada (dipengaruhi oleh) sejauhmana informasi dan partisipasi yang diberikan oleh para anggota tim counterpart. Ketergantungan kontraktor pada informasi dan partisipasi tim counterpart tersebut dapat digunakan sebagai amunisi bagi tim counterpart untuk mendapatkan imbalan yang lumayan besar dari pimpinan proyek maupun dari kontraktor pemenang. Perlu diketahui bahwa selain selaku narasumber (penyedia informasi) tim counterpart juga dapat berperan sebagai pengawas terhadap pelaksanaan tugas kontraktor dan penguji sistem aplikasi yang telah diselesaikan oleh kontraktor.
Ketiga, penundaan pelaksanaan kegiatan proyek akibat kelemahan manajerial kontraktor proyek dapat menguntungkan tim konsultan maupun tim counterpart karena hal tersebut dapat memperpanjang masa pemberian honor mereka. Kondisi demikian dan ketergantungan kontraktor pada partisipasi tim counterpart dan tim konsultan dapat dimanfaatkan oleh kedua tim tersebut untuk merekayasa penundaan kegiatan proyek yang disebabkan oleh kelemahan manajerial kontraktor.
Satu hal yang perlu kita perhatikan di sini, apabila kita tidak mengantisipasi dengan melakukan penyiapan solusi dan strategi pencegahannya, praktek bisnis dalam proyek pengembangan TI yang telah saya sampaikan tersebut di atas mungkin dapat merupakan salah satu faktor penghambat utama dalam proses pengembangan SPAN.
Tantangan dalam pengembangan SPAN terakhir yang ingin saya kemukakan melalui tulisan ini adalah tentang masalah intervensi Bank Dunia. Maksud saya dengan intervensi Bank Dunia di sini kurang lebih sama artinya dengan intervensi IMF (dan Bank Dunia) dalam structural adjustment program yang harus dilaksanakan oleh sejumlah negara sedang berkembang ketika mereka membutuhkan dana talangan dalam jumlah besar yang sifatnya mendesak dari IMF (dan Bank Dunia). Intinya, selaku kreditor, Bank Dunia mensyaratkan banyak hal dalam implementasi pengadaan dan pengembangan SPAN yang perlu mendapatkan persetujuan (NOL/No Objection Letter) darinya.
Saya kira sudah menjadi rahasia umum bahwa dalam perjanjian utang tentang pelaksanaan proyek-proyek yang dananya bersumber dari pinjaman Bank Dunia biasanya disebutkan kewajiban negara pengutang untuk menggunakan konsultan asing yang konon bisa digaji sekitar 10-80 kali dari konsultan domestik. Selain itu, biaya pengadaan barangnya bisa beberapa kali lipat lebih mahal dari harga domestik.
Bicara mengenai biaya pengadaan barang yang lebih mahal tersebut, kebetulan beberapa bulan lalu saya pernah menghadiri rapat tentang estimasi biaya pengadaan barang (hardware dan software) SPAN. Pada waktu itu Bank Dunia (melalui surat yang dikirimkannya) tidak menyetujui estimasi biaya pengadaan server yang diusulkan oleh tim pengadaan SPAN (yang berdasarkan acuan standar harga server di IBM Indonesia yang telah dilengkapi dengan spesifikasinya) yang menurutnya terlalu rendah dan tidak sesuai dengan standar internasional best practices. Sayangnya pada waktu itu Bank Dunia tidak menyampaikan informasi tentang spesifikasi/kualitas server yang harganya (menurut standar harga server di IBM Indonesia) terlalu tinggi tersebut. Atau barangkali harga server di pasar lelang internasional memang jauh lebih mahal dibandingkan dengan harga server di pasar domestik?
Sebenarnya indikasi intervensi Bank Dunia dapat secara jelas kita ketahui melalui pernyataan-pernyataan yang tertulis dalam dokumen persetujuan utang (loan agreement). Sudah menjadi rahasia umum bahwa proses negosiasi dalam penyusunan loan agreement biasanya merupakan upaya pendiktean (intervensi) Bank Dunia terhadap negara-negara debitor. Dalam kaitannya dengan proyek GFMRAP, please CMIIW, kalau tidak salah Pak Siswo (Sesditjen DJPB) juga pernah terlibat dalam tim negosiasi yang harus berhadapan dengan Bank Dunia walaupun (karena tidak mau “didikte”) akhirnya posisinya diganti oleh Pak Paruli (Direktur PA).
Satu hal ingin saya sampaikan di sini adalah bahwa sebenarnya masih banyak permasalahan dan tantangan lain yang akan kita hadapi dalam proses pengembangan SPAN. Beberapa di antaranya adalah terkait dengan dukungan manajemen dan komitmen pemerintah, koordinasi antar unit-unit yang terkait dalam pengembangan PAN, seleksi SDM yang akan dilibatkan dalam proses pengembangan SPAN dan penempatannya pada posisi yang tepat, dan manajemen perubahan yang terkait dengan proses perubahan proses bisnis, organisasi dan jumlah SDM yang dibutuhkan. Sayang sekali topik permasalahan yang sebenarnya sangat menarik tersebut, karena alasan keterbatasan target waktu penyelesaian, tidak bisa saya masukkan dalam tulisan ini.
REKOMENDASI
Berdasarkan permasalahan dan tantangan dalam pengembangan SPAN yang telah saya sampaikan tersebut di atas, saya mengusulkan beberapa rekomendasi sebagaimana berikut.
Pertama, diperlukan wadah organisasi dimana para pegawai yang ditugaskan untuk menangani pengembangan SPAN dapat bekerja secara penuh (bukan part-time) bersama dengan pihak kontraktor SPAN dan para konsultan SPAN. Dengan demikian, pembayaran honor untuk tim SPAN sebagaimana yang selama ini berlaku diharapkan akan bisa lebih hemat.
Apakah wadah organisasi tersebut berada pada DJPB atau Setjen Depkeu? Saya mengusulkan supaya di tingkat Setjen Depkeu dibentuk unit yang berfungsi sebagai koordinator. Sementara itu pada masing-masing tingkat eselon I (DJPB, DJA, DJPU dan DJKN) dibentuk suatu unit yang tupoksinya adalah dalam rangka pengembangan SPAN. Unit tersebut diharapkan akan tetap beroperasi meskipun proyek pengembangan SPAN telah berakhir. Sementara itu mengenai besaran unit organisasi pada masing-masing tingkat eselon I tersebut pada prinsipnya dapat disesuaikan dengan kebutuhan masing-masing organisasi.
Khusus untuk DJPB, saya mengusulkan wadah organisasi untuk pengembangan SPAN (note: Sistem Perbendaharaan) tersebut setara dengan tingkat eselon II dan terdiri dari unit-unit yang kurang lebih mempunyai fungsi yang sama dengan tim-tim counterpart SPAN (Transformasi Proses Bisnis, Transformasi Teknologi Informasi, Manajemen Perubahan dan Komunikasi) dan fungsi Sekretariat GFMRAP. Selain itu, perlu pula dipertimbangkan kemungkinan kebutuhan untuk menambah unit Transformasi Organisasi dan SDM dan unit Transformasi Peraturan Perbendaharaan.
Keberadaan wadah organisasi untuk pengembangan Sistem Perbendaharaan di DJPB tersebut dapat digunakan untuk mengantisipasi kemungkinan proyek SPAN dihentikan atau mengalami kegagalan. Selain itu, kegiatan-kegiatan organisasi tersebut (Direktorat Transformasi Sistem Perbendaharaan?) juga dapat disinergikan dengan kegiatan-kegiatan reformasi birokrasi yang antara lain memfokuskan pada penataan organisasi, penyempurnaan proses binis dan peningkatan manajemen SDM. Dengan demikian, semestinya ia juga memikirkan hal-hal penting (strategis) seperti solusi terhadap masalah kelebihan pegawai di Kanwil yang muncul setelah/akibat implementasi pengoperasian KPPN Percontohan.
Kedua, sebaiknya dengan bantuan para konsultan SPAN kita segera mengupayakan kesepakatan internal tentang blueprint atau gambaran arsitektur SPAN secara menyeluruh yang akan kita kembangkan. Penyusunan blueprint SPAN biasanya ditindaklanjuti dengan penyusunan rancangan-rancangan sistem yang lebih detil yang diperlukan oleh pihak kontraktor dalam proses implementasi pengembangan SPAN. Dengan demikian, menurut saya, seharusnya blueprint dan gambaran arsitektur yang lebih detil SPAN tersebut sudah termasuk dalam lampiran dokumen penawaran.
Kualitas blueprint atau rancangan arsitektur SPAN sebenarnya tergantung pada sejauhmana kita telah melakukan serangkaian pengujian atau studi banding (benchmarking) ke beberapa negara yang telah membangun sistem yang sama (treasury system, misalnya). Kualitas blueprint atau rancangan arsitektur yang rendah biasanya akan nampak apabila dalam tahapan implementasi pengembangannya ia mengalami beberapa kali perubahan. Sebagaimana kita ketahui, dampak perubahan pada blueprint dalam praktek biasanya berimbas pada sejumlah perubahan pada sejumlah rancangan detil yang barangkali sebelumnya telah diselesaikan.
Untuk memutuskan apakah (dalam blueprint SPAN) kita akan mengadopsi sistem pengelolaan basis data yang fully centralized, dalam pengertian hanya ada single dabase yang berlokasi di kantor pusat, saya kira sebelumnya kita bisa melakukan pengujian sejauhmana kita dapat menyediakan sarana komunikasi data yang dapat menjamin kelancaran komunikasi data dari KPPN-KPPN di daerah terpencil ke kantor pusat. Sedangkan untuk pilihan apakah kita akan menggunakan COTS (a COTS-based Solution) atau menggunakan program aplikasi yang dibuat sendiri oleh programer kita sesuai dengan kebutuhan (an in house Solution), atau pilihan-pilihan lainnya, kita bisa melakukan benchmarking ke sejumlah negara yang telah membangun sistem yang sama.
Menurut saya, benchmarking itu penting karena kita bisa belajar dari sukses atau kegagalan negara lain tanpa terlebih dahulu harus menanggung semua risiko yang pernah diterima oleh negara tersebut. Dengan melakukan benchmarking seharusnya kita dapat menyelesaikan proyek pengembangan SPAN dengan sukses dalam waktu yang relatip singkat dibandingkan dengan, misalnya, proyek treasury system di Kazakhstan yang proses penyelesaiannya membutuhkan waktu selama tujuh tahun.
Penjelasan yang telah saya sampaikan mengenai penyusunan blueprint tersebut di atas sebenarnya hanya bermaksud meninggalkan pesan bahwa sesungguhnya banyak hal yang dapat kita lakukan terkait dengan pengembangan SPAN tanpa harus menunggu hasil laporan staf ahli Menkeu (Pak Herwidyatmo) kepada Bu Menteri.
Ketiga, sebaiknya perlu dipertimbangkan untuk mengubah rencana implementasi pengembangan SPAN yang telah ditetapkan sebelumnya. Menurut jadwal (tentative) implementasi pengembangan SPAN, urutan kegiatannya adalah (1) persetujuan rencana final proyek, (2) penetapan hardware, software dan basis data yang dibutuhkan, (3) evaluasi terhadap kebutuhan dan fit/gap analysis, (4) perancangan dan pengembangan sistem, (5) testing kelayakan sistem, (6) ujicoba pengoperasian sistem dan (7) testing kelayakan hasil ujicoba.
Melihat jadwal implementasi pengembangan SPAN tersebut di atas saya khawatir bahwa proses pengembangan, testing kelayakan dan ujicoba aplikasi pada semua modul SPAN (penyusunan anggaran, manajemen DIPA, manajemen pembayaran, manajemen kas, dst) secara serentak dapat mengakibatkan risiko kegagalan pada semua modul SPAN yang telah ditargetkan. Lain halnya kalau (misalnya) modul penyusunan anggaran dan modul manajemen DIPA dikerjakan lebih dulu dari mulai tahap pengembangan sampai dengan tahap testing hasil ujicoba aplikasi modul penyusunan anggaran, dan selanjutnya diselesaikan proses pengembangan, testing kelayakan dan ujicoba kelompok modul-modul SPAN lainnya yang saling berdekatan. Intinya, kita tentu akan lebih merasa puas seandainya sampai batas waktu deadline yang telah ditetapkan kita telah dapat menggunakan beberapa modul SPAN sesuai kebutuhan, dibandingkan dengan kondisi dimana semua modul SPAN masih dalam status testing kelayakan sistem atau masih dalam proses ujicoba.
Last but not least, terus terang melihat perkembangan proses pengadaaan SPAN yang berkali-kali mengalami penundaan, saya merasa khawatir bahwa there must be something wrong with the SPAN management. Proyek SPAN bagi saya terlalu besar tingkat kesulitannya dibandingkan dengan kemampuan manajemen proyek kita yang dari waktu ke waktu seakan tidak mengalami perubahan. Barangkali kalau ada orang yang menanyakan kepada saya: “Apa itu SPAN?”, mungkin saya akan menjawab: “SPAN adalah Sebuah Proyek Ambisius (milik) Negara”. Benarkah? Pada akhirnya nanti kita akan melihat, apakah yang dihasilkan oleh SPAN setara dengan biaya yang telah dikeluarkannya.
