Dear Forum-Prima,
Tulisan mengenai SPAN berikut ini saya buat untuk memenuhi permintaan Pak
Sucipto, teman saya yang saat ini menjabat sebagai Kepala KPPN Sragen, melalui
milis ini beberapa waktu lalu. Saya minta maaf karena telah membiarkan Pak
Tjip terlalu lama menunggu.
Selain untuk Pak Tjip, tentunya tulisan ini juga untuk semua anggota
Forum-Prima yang tertarik dan ingin mengetahui lebih jauh tentang apa itu SPAN.
Selain dari Pak Tjip, dorongan membuat tulisan tentang SPAN ini juga datang
dari surat Sekditjen kepada para Kakanwil tentang Permintaan Bahan Masukan
Rapimtas. Terus terang ketika membaca surat tersebut saya merasa penasaran
mengapa "orang-orang di daerah" (yang hampir pasti sama sekali tidak tahu
tentang SPAN) diberi pertanyaan tentang SPAN.
Mudah-mudahan tulisan saya berikut ini dapat bermanfaat bagi para pembaca. Saya
merasa lega seandainya tulisan ini dapat membuat mata pembaca terbuka, dan saya
juga akan merasa lega seandainya tanggapan dan kritikan pembaca dapat membuat
mata saya terbuka.
Salam,
budisan
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 (Sekditjen 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
SPAN, 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
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?
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[Non-text portions of this message have been removed]
Hentikan korupsi dana APBN dengan alasan apa pun.
Hentikan sekarang juga.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/forum-prima/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/forum-prima/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
