analisis manajemen perubahan aplikasi penyusunan apbd di
TRANSCRIPT
1
Analisis Manajemen Perubahan Aplikasi Penyusunan APBD
di Pemerintah Provinsi DKI Jakarta
Miranti Benacorry, Emil Bachtiar
1. Department of Accounting, Faculty of Economics, Universitas Indonesia, Indonesia
2. Department of Accounting, Faculty of Economics, Universitas Indonesia, Indonesia
E-mail: [email protected]
Abstrak
Skripsi ini menganalisis manajemen perubahan aplikasi penyusunan Anggaran Pendapatan
dan Belanja Daerah (APBD) di Pemerintah Provinsi DKI Jakarta, dengan studi kasus terhadap
perubahan aplikasi Sistem Informasi Perencanaan (SIP) menjadi aplikasi e-Budgeting. Hasil
analisis menyimpulkan bahwa hasil perubahan aplikasi, yaitu aplikasi e-Budgeting, lebih
unggul dibandingkan dengan aplikasi SIP dalam mendukung proses penyusunan APBD. Hal
tersebut karena aplikasi e-Budgeting membuat perencanaan lebih rinci, penyusunan APBD
lebih mudah, dan manajemen kendali anggaran lebih baik daripada sebelumnya. Terkait
manajemen perubahan aplikasi, pendekatan manajemen perubahan aplikasi yang dipilih sudah
sesuai, namun beberapa praktik dalam tahapan manajemen perubahan aplikasi yang tidak
sesuai. Ketidaksesuaian tersebut berdampak pada timbulnya masalah dan potensi masalah.
Masalah yang terjadi adalah keterlambatan penetapan APBD TA 2014. Sedangkan potensi
masalah yang dapat muncul adalah rendahnya realisasi penyerapan anggaran pada TA 2014,
kemungkinan anggaran siluman muncul, tidak terukurnya kinerja SKPD, dan kesalahan
manajemen perubahan aplikasi yang dapat terulang kembali di masa depan.
Analysis of Application Change Management on Regional Income and Expenditure
Budgeting (APBD) in DKI Jakarta Provincial Government
Abstract
This thesis analyzes the application change management on Regional Income and
Expenditure Budgeting (APBD) in DKI Jakarta Provincial Government, with a case study of
the changes in Information Systems Planning (SIP) application into e-Budgeting application.
The results of the analysis concluded that the application changes results, namely e-Budgeting
application, is superior to SIP application in support the budgeting process. This is due to e-
Budgeting application that made planninng more detailed, budgeting easier, and budget
control management better than before. Related to application change management, selected
application change management approach is appropriate, but some practices in application
change management phase is not appropriate. Such discrepancy affects the onset of problems
and potential problems. The problem that occurs is the delay in setting APBD Final Year (FY)
2014. While the potential problems that can arise is the low absorption in the FY 2014 budget,
the possibility arises stealth budget, the SKPD performance not measurable, and the fault on
application change management can reoccur in the future.
Keywords: application change, budgeting, APBD, DKI Jakarta
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
2
PENDAHULUAN
Pemerintah provinsi (Pemprov) DKI Jakarta memiliki aplikasi untuk mendukung proses
penyusunan APBD yang bernama Sistem Informasi Perencanaan (SIP). Aplikasi tersebut
dibuat untuk memenuhi PP Nomor 56 Tahun 2005 yang mewajibkan Pemerintah Daerah
untuk memiliki Sistem Informasi Keuangan Daerah (SIKD) untuk mendukung pengelolaan
keuangan daerah, mulai dari penyusunan Anggaran Pendapatan dan Belanja Daerah (APBD)
hingga penyusunan Laporan Keuangan Pemerintah Daerah (LKPD). Setelah penggunaan
aplikasi tersebut, manfaat terhadap pengelolaan keuangan daerah terlihat. Pertama, opini
LKPD DKI Jakarta terus meningkat sejak tahun anggaran (TA) 2008. Menurut BPK, opini
terus meningkat karena praktik pengelolaan keuangan daerah semakin baik sejak penggunaan
SIP. Kedua, SIP juga membuat APBD ditetapkan lebih awal sejak TA 2010.
Namun aplikasi SIP memiliki kekurangan. Aplikasi SIP tidak dapat mencegah anggaran
siluman, yaitu anggaran yang tidak jelas kegunaannya bagi SKPD. Hal tersebut karena SIP
tidak hanya meminta jumlah anggaran per kegiatan tanpa rincian sehingga tidak dapat
diketahui keterkaitan anggaran dengan kegiatan. Berdasarkan audit APBD TA 2012 yang
dilakukan oleh BPKP pada pertengahan tahun 2013, diketahui terdapat anggaran siluman
dengan total nilai Rp 1,471 triliun di empat SKPD DKI Jakarta, yaitu Dinas Pekerjaan Umum,
Dinas Pendidikan, Dinas Perhubungan, dan Dinas Kesehatan. Akhirnya Pemprov DKI Jakarta
memutuskan untuk mengganti aplikasi SIP menjadi aplikasi e-Budgeting.
Seharusnya perubahan aplikasi dapat membuat proses penyusunan APBD menjadi lebih baik,
akan tetapi perubahan yang dilakukan membuat penyusunan APBD TA 2014 terganggu dan
APBD terlambat ditetapkan. APBD TA 2014 seharusnya ditetapkan pada tanggal 31
Desember 2013 berdasarkan Permendagri Nomor 27 Tahun 2013. Namun Pemprov DKI
Jakarta baru dapat menetapkannya pada tanggal 3 Maret 2014. Sebagai bukti keterlambatan,
Pemprov dan DPRD DKI Jakarta mendapat surat teguran dari Kementerian Keuangan. Tidak
hanya sekedar teguran, keterlambatan juga membuat kegiatan Pemprov DKI Jakarta
terkendala, seperti pengendalian banjir besar pada bulan Januari 2014 yang tidak dapat
dilakukan dan pelaksanaan Pedagang Kaki Lima (PKL) Night Market yang terlambat.
Terkendalanya kegiatan disebabkan oleh ketidakadaan APBD sebagai landasan pelaksanaan
kegiatan sesuai dengan fungsi yang dimilikinya, yaitu fungsi perencanaan dan otorisasi.
Pencapaian tujuan Pemprov DKI Jakarta untuk memenuhi kebutuhan masyarakat pun
terhambat.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
3
Perubahan aplikasi sebenarnya umum dilakukan agar organisasi dapat memiliki aplikasi yang
paling sesuai untuk mendukung proses bisnis organisasi dan meraih peningkatan performa
(Hunton, Bryant, & Bagranoff, 2004: 70; Duncombe 2012). Walaupun terdapat fakta bahwa
rata-rata organisasi yang melakukan perubahan aplikasi akan mengalami gangguan dalam
proses bisnisnya (Hunton, Bryant, & Bagranoff, 2004: 83). Bahkan kegagalan juga dapat
terjadi, yaitu kondisi dimana aplikasi tidak dapat mendukung proses bisnis organisasi. Namun
risiko tersebut dapat diminimalisir dengan manajemen perubahan aplikasi yang saat ini telah
marak digunakan (Ensslin, Scheid, Ensslin, & Lacerda, 2012).
Berangkat dari latar belakang tersebut, manajemen perubahan aplikasi penyusunan APBD di
Pemprov DKI Jakarta perlu ditelaah kembali karena adanya risiko berupa gangguan terhadap
proses penyusunan APBD yang muncul. Penelitian ini pun ingin menganalisis tiga hal.
Pertama, apakah aplikasi e-Budgeting lebih unggul dalam mendukung proses penyusunan
APBD dibandingkan dengan SIP. Kedua, apakah manajemen perubahan aplikasi yang
dilakukan oleh Pemprov DKI Jakarta sudah sesuai dengan praktik yang seharusnya dilakukan.
Terakhir, apakah masalah dan potensi masalah yang muncul akibat ketidaksesuaian praktik
manajemen perubahan aplikasi yang dilakukan.
TINJAUAN TEORITIS
Manajemen Perubahan Aplikasi
Dalam manajemen perubahan aplikasi, terdapat standar sebagai panduan perubahan aplikasi
bagi organisasi yang dikeluarkan oleh Information Systems Audit and Control Association
(ISACA), yaitu Control Objective for Information and Related Technology (COBIT). COBIT
terbaru yang dikeluarkan oleh ISACA, yaitu COBIT 5, menyatakan prinsip bahwa perubahan
aplikasi yang diajukan oleh pihak internal organisasi harus disetujui oleh komite pengawas
terlebih dahulu. Kemudian, organisasi harus memperhatikan kebutuhan stakeholders, tujuan,
proses perubahan aplikasi, dan praktik yang baik dalam manajemen perubahan aplikasi.
1. Persetujuan Perubahan Aplikasi
Perubahan aplikasi yang diajukan oleh pihak internal organisasi harus disetujui oleh komite
pengawas dengan mengajukan permohonan perubahan aplikasi. Persetujuan komite pengawas
bisa didapatkan jika perubahan aplikasi yang diajukan sesuai dengan kebutuhan organisasi
dan mungkin untuk dilakukan oleh organisasi (Davis & Olson, 1985: 574-576; Hoffer,
George, & Valacich, 2008: 50-51; Prasetya, 2013). Jika perubahan aplikasi sudah sesuai
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
4
dengan kebutuhan organisasi, analisis feasibilitas pun dilakukan. Menurut Davis & Olson
(1985: 574-576), analisis feasibilitas berguna untuk menentukan kesiapan organisasi dalam
perubahan aplikasi. Jika organisasi tidak siap, risiko kegagalan perubahan aplikasi akan
semakin besar. Terdapat beberapa analisis feasibilitas yang harus dilakukan, diantaranya
analisis feasibiltas teknis, analisis feasibilitas ekonomi, analisis feasibilitas motivasi, analisis
feasibilitas jadwal, analisis feasibilitas operasional, serta analisis feasibilitas keuangan.
2. Pertimbangan Kebutuhan Stakeholders
Perubahan aplikasi harus mempertimbangkan kebutuhan stakeholders (pihak internal dan
eksternal organisasi). Pertimbangan kebutuhan pihak eksternal biasanya telah dipikirkan oleh
organisasi. Hal yang sering dilupakan adalah pertimbangan akan kebutuhan pihak internal.
Banyak kasus perubahan aplikasi gagal karena rencana perubahan aplikasi tidak menampung
kebutuhan internal, selain dari pencetus perubahan aplikasi (Al-Mashari & Zairi, 2000 dalam
Aladwani, 2001; Stapleton & Rezak, 2004). Untuk mempertimbangkan kebutuhan internal
organisasi, dibutuhkan komunikasi dua arah, seperti rapat. Rapat harus dihadiri oleh semua
perwakilan divisi untuk mendiskusikan perubahan aplikasi (Stapleton & Rezak, 2004;
Fantina, 2006; Duncombe, 2012). Diskusi dilakukan untuk mendiagnosis aplikasi dengan
mengumpulkan informasi dari user (Falletta, 2005: 3; Fantina, 2006; Harsh, 2011: 3).
Lingkup diagnosis permasalahan aplikasi terbagi menjadi dua. Pertama, sempit dan tidak
sisematis. Menurut Tichy (1983), diagnosis ini dilakukan secara cepat dan fokus pada
masalah aplikasi yang telah muncul. Perubahan akan tepat sasaran sesuai masalah, namun
masalah akan terus muncul (Falletta 2005: 4). Kedua, luas dan sistematis. Menurut French
dan Bell (1995), diagnosis ini dilakukan secara keseluruhan pada aplikasi sehingga hampir
keseluruhan masalah yang ada dalam aplikasi, bahkan yang belum muncul, dapat diatasi.
Namun diagnosis ini membutuhkan waktu yang cukup lama (Falletta 2005: 4). Tahapan
dalam diagnosis aplikasi secara garis besar adalah diagnosis permasalahan yang ada pada
aplikasi saat ini (current practice), pertimbangkan aplikasi yang seharusnya dimiliki (desired
state), dan analisis perbedaan antara current practice dengan desired state untuk memutuskan
perubahan aplikasi yang dibutuhkan (change needed) (Fantina, 2006).
3. Penetapan Tujuan
Perubahan aplikasi harus memiliki tujuan yang jelas. Seluruh tujuan tersebut dijabarkan
dengan kualitas aplikasi yang ingin dicapai.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
5
4. Proses Perubahan Aplikasi
Proses perubahan aplikasi menurut COBIT seharusnya meliputi pembuatan rencana
perubahan aplikasi, pembuatan desain aplikasi, pengembangan atau pembelian aplikasi,
implementasi aplikasi, penggunaan aplikasi, evaluasi dan pengawasan, dan perubahan
kembali. Tahapan perubahan aplikasi ini akan dibahas lebih lanjut pada poin selanjutnya.
5. Praktik yang Baik
Khusus untuk praktik yang baik, hal ini dipertimbangkan setelah aplikasi digunakan. Jika
dirasakan bahwa aplikasi sudah tidak dapat mendukung praktik terbaik dalam organisasi,
organisasi dapat merubahnya kembali.
Tahapan Perubahan Aplikasi
Pembuatan Rencana Perubahan Aplikasi
Menurut Minnock (2004), rencana perubahan aplikasi harus mengandung pembagian tugas,
batas anggaran, jadwal dan tahapan, serta risiko yang mungkin terjadi selama perubahan
aplikasi. Pembagian tugas memastikan pemisahan tugas sesuai, yaitu: 1) peminta perubahan
tidak sama dengan komite pengawas; 2) komite pengawas tidak sama dengan pengembang;
dan 3) pihak yang melakukan tes tidak sama dengan pengembang. Batas anggaran
mencantumkan dana maksimal untuk perubahan aplikasi. Jadwal dan tahapan juga harus
disusun dengan baik. Organisasi juga harus merancang cara mengatasi risiko yang mungkin
terjadi.
Deephouse, Mukhopadhyay, Goldenson, dan Kellner (1996) menyatakan bahwa perubahan
aplikasi sering menemui kegagalan akibat kesalahan perencanaan dan identifikasi risiko.
Kesalahan perencanaan dapat terlihat dari jadwal dan anggaran yang sangat ketat. Kesalahan
identifikasi risiko dapat terlihat dalam kegagalan pengelolaan risiko perubahan aplikasi.
Kesalahan perencanaan dan kesalahan identifikasi risiko dapat terjadi ketika organisasi hanya
mengalokasikan waktu singkat dalam melakukan perubahan aplikasi. Efeknya adalah kualitas
aplikasi rendah sehingga tidak efektif dalam mendukung organisasi.
Pembuatan Desain Aplikasi
Menurut Belle, Eccles, dan Nash (2003: 137), tujuan pembuatan desain aplikasi adalah
menentukan bagaimana aplikasi yang ingin dihasilkan dengan membuat spesifikasi aplikasi.
Desain aplikasi harus didokumentasikan. Terdapat beberapa desain aplikasi yang harus dibuat
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
6
oleh organisasi, diantaranya adalah desain konseptual, desain sistem fisik, dan desain
database fisik (Davis & Olson, 1985: 572-573; Belle, Eccles, & Nash, 2003: 136-138).
1. Desain Konseptual
Menurut Davis & Olson (1985: 576-577), desain konseptual dibuat dengan
mempertimbangkan desain aplikasi yang dilihat user. Desain konseptual berisi deskripsi
aplikasi, rancangan fungsi aplikasi untuk user, dan rancangan tampilan aplikasi untuk user
mulai dari input data hingga tampilan hasil aplikasi yang akan dijadikan poin-poin dalam
manual penggunaan aplikasi. Dalam desain konseptual, desain kontrol yang memadai juga
harus dipikirkan. Tujuan desain kontrol adalah untuk menjaga keamanan dan integritas data
organisasi. Berdasarkan Arfani (2013), kontrol terbagi menjadi dua, yaitu kontrol umum dan
aplikasi.
Kontrol umum merupakan campuran antara kontrol secara manual dan otomatis. Kontrol
umum terbagi menjadi dua. Pertama, kontrol akses untuk memastikan hanya pihak terotorisasi
yang dapat melakukan akses ke aplikasi dan melakukan fungsi tertentu sesuai tugasnya. Hal
yang paling umum dilakukan adalah pemakaian user ID dan password untuk akses. Kedua,
kontrol lainnya, yaitu kontrol selama operasional aplikasi seperti kontrol terhadap back up
dan recovery, kontrol terhadap penjadwalan kerja, dan kontrol terhadap manajemen masalah.
Sedangkan, kontrol aplikasi merupakan kontrol yang telah diotomatisasi dalam aplikasi.
Kontrol aplikasi terbagi menjadi beberapa kategori, diantaranya:
Edit checks yang bertujuan untuk membatasi risiko dari input, proses, output data yang
tidak sesuai dengan format yang ada. Contoh penerapannya adalah required fields atau
specific data format. Ketika input tidak sesuai dengan format, input tidak dapat disimpan.
Validations yang bertujuan untuk membatasi risiko dari input, proses, output data yang
tidak sesuai dengan konfirmasi yang ada. Contoh penerapannya adalah dengan three-way
match atau tolerance limits. Ketika input tidak terdapat dalam database atau melebihi batas
tertinggi anggaran, maka input tidak dapat disimpan.
Calculations yang bertujuan untuk memastikan kalkulasi telah dilakukan secara akurat.
Contoh penerapannya adalah penjumlahan otomatis.
Interfaces yang bertujuan untuk membatasi risiko dari input, proses, output data dapat
diubah dari aplikasi lainnya. Contoh penerapannya adalah dengan memastikan data tidak
dapat diubah melalui aplikasi lain.
Authorizations yang bertujuan untuk membatasi risiko dari input, proses, output data
finansial dapat diakses oleh pihak yang tidak terotorisasi untuk melakukan hal tersebut.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
7
Contoh penerapannya adalah dengan pemisahan tugas dan dilakukan persetujuan dari data
yang telah diinput.
2. Desain Sistem Fisik
Menurut Davis dan Olson (1985: 577-583), desain sistem fisik dibuat untuk menyiapkan
detail teknis penggunaan aplikasi dan keterkaitan keseluruhan fungsi aplikasi. Desain sistem
fisik berisi spesifikasi perangkat keras dan lunak yang dibutuhkan untuk menjalankan
aplikasi, serta dokumentasi aplikasi untuk menggambarkan keterkaitan keseluruhan fungsi
aplikasi.
3. Desain Database Fisik
Desain database fisik dimulai dengan analisis kebutuhan informasi. Menurut Davis dan Olson
(1985: 576), analisis kebutuhan informasi mengandung dua tahapan. Pertama, organisasi
harus membuat daftar data yang dibutuhkan untuk perubahan aplikasi. Kedua, organisasi
melakukan perbandingan terkait data yang sudah dimiliki dengan data yang dibutuhkan
sehingga data yang kurang lengkap dan kurang tepat dapat diidentifikasi. Data yang kurang
tersebut harus dilengkapi sehingga data sesuai kebutuhan aplikasi baru didapatkan.
Pembelian atau Pengembangan Aplikasi
Cara mendapatkan aplikasi terbagi menjadi dua, yaitu dengan pembelian atau pengembangan
aplikasi (Basile, Papa, & Johnston, 2002; Hunton, Bryant, & Bagranoff, 2004: 77-79; Rainer
& Cegielski, 2011: 398). Keputusan tersebut dipengaruhi oleh ketersediaan waktu dan proses
bisnis organisasi. Jika organisasi tidak memiliki waktu cukup untuk pengembangan,
organisasi akan melakukan pembelian. Walaupun risikonya adalah proses bisnis organisasi
yang harus menyesuaikan dengan aplikasi yang dibeli. Jika organisasi memiliki proses bisnis
yang rumit, organisasi akan melakukan pengembangan walaupun memakan waktu yang lama.
Dalam pengembangan, organisasi dapat mengembangkan sendiri (insource) atau
menggunakan konsultan (outsource) (Hunton, Bryant, & Bagranoff 2004: 79-80; Robey,
Coney, & Sommer, 2006; McPherson, 2011). Basile, Papa, dan Johnston (2002) berpendapat
bahwa apapun cara yang ditempuh, organisasi harus memastikan bahwa aplikasi dapat
mendukung organisasi.
Menurut Hunton, Bryant, dan Bagranoff (2004: 81-82), terdapat tiga library yang harus
dibuat untuk melakukan pengembangan. Pertama, library produksi yang hanya dapat diakses
oleh user untuk mengolah data proses bisnis organisasi selama pengembangan aplikasi baru
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
8
berlangsung. Kedua, library pengembangan yang hanya dapat diakses oleh tim pengembang
untuk mengembangkan aplikasi baru, seperti pembuatan layar aplikasi, format input data, dan
lain sebagainya. Ketiga, library tes yang dapat diakses oleh tim pengembang dan user untuk
melakukan tes terhadap aplikasi baru yang dikembangkan tanpa mempengaruhi library
lainnya.
Implementasi Aplikasi
Implementasi aplikasi harus dilaksanakan secara hati-hati dan sistematis. Jika tidak,
implementasi akan menghancurkan organisasi (Schwab & Kallman, 1992; Fichman & Moses,
1999; Hunton, Bryant, & Bagranoff, 2004: 85). Dalam implementasi, organisasi harus
memilih strategi. Menurut Hunton, Bryant, dan Bagranoff (2004: 85-86), terdapat beberapa
strategi implementasi yang dapat dipilih, diantaranya:
1. Implementasi big bang. Dengan strategi ini, aplikasi baru langsung menggantikan aplikasi
lama secara keseluruhan. Kelebihan strategi ini adalah pihak internal organisasi dipaksa
untuk fokus menggunakan aplikasi baru. Kelemahannya adalah ketika aplikasi baru gagal,
keseluruhan proses bisnis akan terganggu. Strategi ini sesuai ketika aplikasi lama sudah
sangat tidak sesuai dengan kebutuhan organisasi dan aplikasi baru yang akan digunakan
untuk memproses keseluruhan data. Big bang adalah strategi berisiko tinggi.
2. Implementasi paralel. Dengan strategi ini, aplikasi baru dan lama dijalankan secara
bersamaan. Kelebihan strategi ini adalah risiko gangguan dapat diminimalisir. Jika aplikasi
baru bermasalah, identifikasi dan perbaikan dapat dilakukan tanpa mempengaruhi
organisasi. Kelemahannya adalah alokasi sumber daya yang besar karena menjalankan dua
aplikasi sekaligus. Strategi ini merupakan strategi yang paling kecil risikonya sehingga
sesuai untuk aplikasi yang kritis, dimana kegagalan aplikasi berbahaya bagi organisasi.
3. Implementasi sebagian. Dengan strategi sebagian, aplikasi diimplementasikan per bagian,
tidak secara keseluruhan. Contohnya adalah aplikasi pendukung proses seleksi pegawai
hingga proses remunerasi pegawai. Aplikasi dapat digunakan di proses seleksi pegawai
saja. Jika sudah baik, baru kemudian aplikasi diimplementasikan di proses lainnya. Dalam
implementasi di setiap proses, organisasi dapat memilih akan melakukan secara paralel
atau big bang. Kelebihan strategi ini adalah risiko kegagalan dapat diminimalisir.
Kelemahannya adalah implementasi memakan waktu yang cukup lama hingga akhirnya
aplikasi dapat diimplementasikan secara penuh dalam organisasi. Apabila waktu
implementasi bukanlah hal yang dikhawatirkan, strategi ini merupakan pilihan yang
ekonomis dan efektif.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
9
4. Implementasi fokus. Dengan strategi ini, aplikasi diimplementasikan secara keseluruhan
namun hanya dalam sekelompok kecil user, misalnya di salah satu cabang organisasi.
Contohnya adalah penerapan awal hanya di cabang X, aplikasi akan diterapkan di cabang
lainnya jika implementasi aplikasi sudah baik di cabang X. Ketika implementasi di setiap
cabang, organisasi juga dapat memilih akan melakukan secara paralel atau big bang.
Kelebihan strategi ini adalah masalah pada aplikasi dapat diidentifikasi dan diperbaiki
tanpa mempengaruhi organisasi keseluruhan, hanya cabang yang terpengaruh.
Kelemahannya adalah implementasi memakan waktu yang cukup lama hingga akhirnya
aplikasi baru dapat diimplementasikan pada keseluruhan organisasi. Apabila waktu
implementasi bukanlah hal yang dikhawatirkan, strategi ini merefleksikan keseimbangan
antara risiko dan kesuksesan.
Setelah memilih strategi, aktivitas implementasi dimulai. Alat yang umum digunakan untuk
implementasi adalah dengan milestone chart, seperti PERT (Program Evaluation Review
Technique), CPM (Critical Path Method), dan lainnya. PERT adalah yang paling sederhana
dan mudah digunakan (Ignizio, 1991: 309-311). Aktivitas yang dilakukan dalam PERT adalah
pengembangan milestone chart, persiapan perangkat keras dan lunak, pelatihan pengguna
aplikasi, persiapan pengawasan dan kontrol, serta tes implementasi aplikasi. Jika telah selesai,
aplikasi dapat digunakan seutuhnya.
Evaluasi dan Pengawasan
Evaluasi bertujuan untuk menilai seberapa baik organisasi dalam melakukan perubahan
aplikasi (Anthony & Govindarajan, 2007: 747). Caranya dengan membandingkan rencana dan
realisasi. Jika terdapat perbedaan, harus dianalisis faktor penyebabnya dan dijadikan bahan
pembelajaran untuk perubahan aplikasi selanjutnya. Ignizio (1991: 317) menyatakan bahwa
cara terbaik melakukan evaluasi adalah dengan menggunakan dokumentasi dari pihak yang
tidak terlibat dalam perubahan. Namun, pihak tersebut harus memiliki pengetahuan mengenai
aplikasi dan tujuan yang ingin dicapai organisasi. Dokumentasi harus jelas, lengkap, singkat,
dan disertai dengan lampiran bukti. (Ignizio, 1991: 316-317; Minnock, 2004; Anthony &
Govindarajan, 2007: 740-741). Dokumentasi yang harus dibuat diantaranya adalah:
Laporan masalah, yaitu laporan yang menggambarkan masalah selama proses perubahan
aplikasi. Organisasi harus menjabarkan penyebab masalah terjadi dan jalan keluar agar hal
tersebut tidak terulang, serta memprioritaskan masalah yang perlu ditangani secepatnya.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
10
Laporan tahapan dan jadwal, yaitu laporan yang menggambarkan rencana dan realisasi
dalam tahapan dan jadwal. Variasi yang ada, seperti keterlambatan jadwal, harus
diidentifikasi faktor penyebabnya dan dicegah untuk terjadi kembali.
Laporan finansial, yaitu laporan yang menggambarkan realisasi dari biaya yang digunakan
dalam proses perubahan aplikasi. Jika biaya lebih besar daripada anggaran, organisasi
harus menganalisis alasannya dan menjadikannya sebagai pembelajaran di lain
kesempatan.
Selain evaluasi, pengawasan juga harus dilakukan dalam kegiatan operasional sehari-hari. Hal
tersebut bertujuan untuk mengidentifikasi dan menyelesaikan masalah yang ditemui selama
aplikasi digunakan.
Pendekatan Pengembangan Aplikasi
Pada awalnya, pengembangan aplikasi hanya memiliki satu pendekatan yang bernama
systems development life cycle (SDLC) yang memiliki tahapan terstruktur (Hough, 1993;
Henders, 1998; Belle, Eccles, & Nash, 2003: 146; Hardcastle, 2008: 27; Avgerou, 2011: 42).
Namun tekanan untuk pengembangan yang lebih cepat menghasilkan banyak alternatif
pendekatan, seperti prototyping, rapid delivery, dan object oriented development.
Systems Development Life Cycle
Ide dasar pendekatan SDLC adalah adanya tahapan yang didefinisikan dengan baik yang
bertujuan untuk mengelola dan mengontrol usaha pengembangan aplikasi (Davis & Olson,
1985: 572; Belle, Eccles, & Nash, 2003: 134; Hardcastle, 2008: 27-32; Avgerou, 2011: 42-
43). Menurut Davis dan Olson (1985: 570-572), pendekatan SDLC pada umumnya
digunakan untuk aplikasi yang besar dan terstruktur, serta pemahaman dari user terhadap
aplikasi sangat dibutuhkan. Secara garis besar, pendekatan SDLC sama dengan yang
disarankan dalam COBIT. Terdapat lima tahapan dalam pendekatan SDLC (Avgerou, 2011:
42-43).
1. Tahap inisiasi, yang terdiri atas persetujuan perubahan aplikasi, pertimbangan kebutuhan
stakeholders, dan penetapan tujuan.
2. Tahap perencanaan, yang terdiri atas pembuatan rencana perubahan aplikasi dan
pembuatan desain aplikasi (desain konseptual, desain sistem fisik, dan desain database
fisik).
3. Tahap pengembangan, yang terdiri atas realisasi rencana pengembangan dengan
melakukan coding. Pengembangan bisa dilakukan sendiri atau bisa memakai konsultan.
4. Tahap implementasi, yang terdiri atas pemilihan strategi dan aktivitas implementasi.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
11
5. Tahap penutupan, yang terdiri atas evaluasi dan pengawasan.
Prototyping
Menurut Belle, Eccles, dan Nash (2003: 143), pendekatan prototyping dibuat untuk
memperbaiki kelemahan pendekatan SDLC yang memakan waktu lama dalam persiapan
perubahan dan terlalu kaku karena tahapan perubahan harus dilaksanakan secara berurutan.
Namun organisasi masih mungkin menemukan kekurangan aplikasi walaupun persiapan dan
tahapan dijalankan sebaik mungkin. Pendekatan prototyping menggunakan siklus prototype-
revisi sehingga memiliki kemampuan untuk menghasilkan aplikasi yang benar-benar tepat.
Pendekatan ini sesuai ketika organisasi berada dalam kondisi ketidaktahuan akan spesifikasi
aplikasi yang diinginkan karena belum dapat merumuskan kebutuhan dari organisasi secara
lengkap (Davis & Olson, 1985: 567-570).
Walaupun begitu, pendekatan ini tetap memiliki kekurangan. Pertama, manajemen proses
pengembangan sulit karena frekuensi revisi prototype yang tinggi hingga prototype dapat
menjadi aplikasi final. Kedua, adanya kemungkinan user cenderung berpikir bahwa prototype
adalah produk final. Namun sebenarnya prototype tersebut hanya merupakan salah satu
spesifikasi aplikasi dan belum dapat memenuhi kebutuhan organisasi. Berikut merupakan
tahapan pendekatan prototyping secara garis besar.
1. Tahap inisiasi. Dalam tahap ini, inisiasi perubahan aplikasi dilakukan oleh user yang
mengerti permasalahan, namun tidak dapat merumuskan kebutuhan. User akan meminta
bantuan konsultan untuk merumuskan spesifikasi aplikasi.
2. Tahap perencanaan. Secara garis besar sama dengan SDLC, namun konsultan yang akan
melakukannya. Selain itu, rencana yang dibuat bukanlah rencana pengembangan aplikasi
secara keseluruhan, namun rencana prototype aplikasi.
3. Tahap pengembangan. Hal yang ditekankan dalam tahap ini adalah pembuatan prototype
aplikasi harus dilaksanakan dengan cepat oleh konsultan.
4. Tahap implementasi. Dalam tahap ini, user mencoba prototype aplikasi dengan strategi
paralel. Kemudian, user memberikan evaluasi atas protoype terkait pemenuhan kebutuhan
user. Jika user merasa bahwa prototype aplikasi telah sesuai dengan kebutuhan organisasi,
prototype aplikasi dapat diterima menjadi prototype operasional. Prototype operasional
yaitu prototype yang diterima menjadi aplikasi organisasi atau menjadi salah satu ide
spesifikasi aplikasi untuk aplikasi yang lebih besar lagi. Namun pada umumnya, hasil
prototype pertama tidak akan memenuhi kebutuhan organisasi dan masih harus direvisi
lagi.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
12
5. Tahap penutupan. Tahap ini terdiri atas penerimaan prototype atau revisi prototype
aplikasi. Jika revisi, tahapan akan berulang kembali dari tahap dua, namun organisasi
harus fokus pada perbaikan kekurangan prototype aplikasi yang telah ada sampai tahapan
ini.
Rapid Delivery
Menurut Hough (1993), pengembangan dengan pendekatan SDLC digambarkan sebagai
proses panjang yang menghabiskan waktu organisasi demi mendapatkan hasil implementasi
aplikasi yang “halus”. Namun berdasarkan penelitian yang dilakukannya, organisasi
menghabiskan waktu rata-rata 2-6 tahun untuk pengembangan aplikasi. Walaupun begitu,
hasil implementasi aplikasi yang “halus” tidak didapatkan oleh organisasi. Terdapat banyak
contoh kasus, diantatanya adalah aplikasi yang telah dikembangkan selama 2 tahun ternyata
menemui banyak masalah dan harus direvisi kembali. Selain itu, ada juga kasus dimana
aplikasi yang sudah dikembangkan selama 5 tahun ternyata gagal total ketika
diimplementasikan dan harus dibuang.
Pendekatan rapid delivery menawarkan sebuah solusi bagi proyek pengembangan aplikasi
besar tanpa membuang waktu organisasi (Hough, 1993; Fichman & Moses, 1999). Aplikasi
besar yang dimaksud adalah aplikasi yang memiliki banyak fungsi dan dapat memakan waktu
lebih dari dua tahun untuk dikembangkan. Selain itu, sangat besar risikonya bagi organisasi
apabila aplikasi tersebut gagal. Tahapan pendekatan ini adalah sebagai berikut.
1. Tahap inisiasi.
2. Tahap perencanaan. Pada tahap ini, aplikasi akan dibagi menjadi beberapa segmen
aplikasi. Sebuah aplikasi pada umumnya memiliki berbagai macam fungsi. Dalam
pendekatan ini, aplikasi akan dibagi berdasarkan fungsi yang ada sehingga menjadi segmen
aplikasi. Setiap segmen aplikasi tersebut akan mengandung fungsi yang berbeda satu sama
lain.
3. Tahap pengembangan. Pengembangan dimulai dengan penentuan kebutuhan dan desain
untuk setiap segmen aplikasi. Jika kebutuhan dan desain sudah tersedia lengkap, segmen
aplikasi dapat dikembangkan. Ketika organisasi melakukan pengembangan segmen
aplikasi tersebut, organisasi dapat berusaha menentukan kebutuhan dan desain segmen
aplikasi lainnya. Pengembangan untuk setiap segmen aplikasi harus memiliki target untuk
selesai dalam jangka waktu tertentu, misalnya 6-8 bulan.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
13
4. Tahap implementasi. Ketika segmen aplikasi selesai, segmen tersebut harus
diimplementasikan. Jika ada segmen aplikasi yang telah diimplementasikan sebelumnya,
maka organisasi juga harus memikirkan integrasi diantara segmen aplikasi tersebut.
5. Tahap penutupan.
Object Oriented Development
Menurut Belle, Eccles, dan Nash (2003: 145), pendekatan object oriented development
(OOD) dibuat untuk memperbaiki kelemahan pendekatan SDLC. Kelemahan pendekatan
SDLC adalah waktu dan biaya yang dihabiskan cukup banyak karena organisasi terlalu fokus
untuk membuat desain aplikasi untuk menyesuaikan dengan kebutuhan. Namun organisasi
tidak pernah melihat ke sekitar bahwa terdapat banyak konsep aplikasi yang hampir sama dan
dapat ditiru konsep dasarnya oleh organisasi. Henders (1998) menyatakan bahwa pendekatan
OOD sesuai untuk digunakan dalam pengembangan aplikasi untuk mendukung proses bisnis
yang sama dengan proses di organisasi lain. Dalam pendekatan ini, organisasi akan
menggunakan bantuan konsultan yang memiliki kode dasar aplikasi proses bisnis tertentu.
Namun, penggunaan kembali kode dasar aplikasi menjadi perdebatan karena beberapa pihak
merasa hal tersebut menyalahi kode etik. Untuk mengatasinya, konsultan melakukan
penyesuaian terhadap kode dasar aplikasi dengan modifikasi sesuai kebutuhan unik dari
masing-masing organisasi.
PROFIL PEMERINTAH PROVINSI DKI JAKARTA
Pemprov DKI Jakarta merupakan Pemda di tingkat provinsi. Pemprov DKI Jakarta dipimpin
oleh kepala daerah dengan jabatan Gubernur dan dibantu oleh Wakil Gubernur. Untuk periode
2013-2017, Pemprov DKI Jakarta dipimpin oleh Joko Widodo dan Basuki Tjahja Purnama.
Pemprov DKI Jakarta memiliki visi dan misi yang berbeda untuk setiap periode tergantung
pemimpin. Berdasarkan Rencana Pembangunan Jangka Menengah Daerah (RPJMD) periode
2013-2017, visi Pemprov DKI Jakarta adalah “Jakarta Baru, kota modern yang tertata rapi,
menjadi tempat hunian yang layak dan manusiawi, memiliki masyarakat yang
berkebudayaan, dan dengan pemerintahan yang berorientasi pada pelayanan publik.” Visi
kemudian dijabarkan lebih lanjut dalam misi. Misi Pemprov DKI Jakarta, diantaranya adalah:
1. Mewujudkan Jakarta sebagai kota modern yang tertata rapi serta konsisten dengan
Rencana Tata Ruang dan Wilayah (RTRW).
2. Menjadikan Jakarta sebagai kota yang bebas dari masalah-masalah menahun seperti macet,
banjir, pemukiman kumuh, sampah dan lain-lain.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
14
3. Menjamin ketersediaan hunian dan ruang publik yang layak serta terjangkau bagi warga
kota dan ketersediaan pelayanan kesehatan yang gratis sampai rawat inap dan pendidikan
yang berkualitas secara gratis selama 12 tahun untuk warga Jakarta.
4. Membangun budaya masyarakat perkotaan yang toleran, tetapi juga sekaligus memiliki
kesadaran dalam memelihara kota.
5. Membangun pemerintahan yang bersih dan transparan serta berorientasi pada pelayanan
publik.
PROSES PERUBAHAN APLIKASI PENYUSUNAN APBD
Pemprov DKI Jakarta memiliki SIKD yang terkomputerisasi untuk mendukung penyusunan
APBD dengan adanya penggunaan komputer dan aplikasi. Aplikasi penyusunan APBD milik
Pemprov DKI Jakarta bernama SIP. Namun kemudian diganti dengan e-Budgeting pada tahun
2013. E-Budgeting tersebut sebenarnya meniru aplikasi penyusunan APBD yang ada di
Pemkot Surabaya. Secara garis besar proses perubahannya seperti yang tercantum dalam tabel
berikut.
Tabel 1. Proses Perubahan Aplikasi SIP Menjadi e-Budgeting
No. Aktivitas Waktu
1 Penggunaan aplikasi e-Budgeting untuk penyusunan APBD 2007 s.d. Akhir Oktober 2013
2 Penemuan masalah anggaran siluman Pertengahan tahun 2013
3 Pengambilan keputusan untuk perubahan aplikasi Pertengahan tahun 2013
4 Pengiriman perwakilan BPKD ke Surabaya untuk belajar e-
Budgeting
Awal Oktober 2013
5 Pengajuan anggaran perubahan aplikasi Awal Oktober 2013
6 Penentuan anggaran perubahan aplikasi 24 Oktober 2013
7 Penandatanganan kontrak konsultan Akhir Oktober 2013
8 Diskusi rencana perubahan aplikasi Akhir Oktober 2013
9 Pemberitahuan kepada seluruh kepala SKPD tentang perubahan Awal November 2013
10 Penggunaan aplikasi e-Budgeting untuk penyusunan APBD Awal November 2013 s.d.
Akhir Januari 2014
11 Pembuatan Pergub Provinsi DKI Jakarta Nomor 145 Tahun
2013 yang menegaskan kewajiban menggunakan e-Budgeting
13 Desember 2013
12 Penyampaian Perda APBD ke DPRD Akhir Januari 2014
13 Penyampaian Perda APBD ke Kemendagri Pertengahan Februari 2014
14 Penetaoan Perda APBD 3 Maret 2014
15 Pelengkapan kekurangan database dan lain sebagainya Setelah 3 Maret 2014
Sumber: Olahan penulis dari hasil wawancara dengan narasumber
PEMBAHASAN
Keunggulan e-Budgeting Dibandingkan SIP Dalam Mendukung Penyusunan APBD
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
15
Apabila aplikasi e-Budgeting dibandingkan dengan aplikasi SIP dalam mendukung proses
penyusunan APBD, aplikasi e-Budgeting lebih unggul. Keunggulan tersebut muncul dari fitur
dalam aplikasi e-Budgeting yang tidak dimiliki oleh SIP. Beberapa keunggulannya adalah:
1. E-Budgeting membuat perencanaan menjadi lebih rinci
Aplikasi e-Budgeting membuat perencanaan menjadi lebih rinci dengan adanya fitur kontrol
edit checks berupa format data spesifik RKA yang telah disesuaikan dengan formulir RKA
2.2.1. Apabila format data spesifik RKA SIP dan e-Budgeting dibandingkan dengan formulir
RKA, bentuk format dalam aplikasi e-Budgeting lebih lengkap daripada SIP. Dengan adanya
format tersebut, SKPD/UKPD diminta untuk melakukan perencanaan lebih rinci.
Tabel 2. Perbandingan Antara Format Data Spesifik RKA Pada
Aplikasi e-Budgeting dan SIP Dengan Formulir RKA SKPD 2.2.1
No. Formulir RKA SKPD 2.2.1 Aplikasi SIP Aplikasi e-Budgeting
1 Urusan Pemerintahan X V
2 Organisasi V V
3 Program V V
4 Kegiatan V V
5 Lokasi Kegiatan V V
6 Jumlah Anggaran n-1 X V
7 Jumlah Anggaran n V V
8 Jumlah Anggaran n+1 X V
9 Indikator Capaian Program V V
10 Indikator Masukan V V
11 Indikator Keluaran V V
12 Indikator Hasil V V
13 Kelompok Sasaran Kegiatan V V
14 Rincian Anggaran Belanja Langsung
(Kode Rekening, Uraian, Volume,
Satuan, Harga Satuan, dan Jumlah)
X V
15 Jumlah Anggaran Belanja Langsung V V
Keterangan: V = Ada X = Tidak ada n = Tahun
Sumber: Olahan penulis dari manual penggunaan aplikasi SIP dan e-Budgeting
Hal yang paling berdampak adalah adanya format rincian anggaran yang harus diisi oleh
SKPD/UKPD. Dengan adanya rincian tersebut, dapat dievaluasi keterkaitan anggaran dengan
kegiatan. Anggaran siluman, yaitu anggaran yang tidak jelas kegunaannya bagi SKPD, pun
dapat diminimalisir. Untuk menghindari kemungkinan rincian tidak diisi, dibuat juga kontrol
edit checks terhadap rincian anggaran. Ketika rincian anggaran tidak diisi, maka input RKA
tidak dapat disimpan. Namun, kontrol edit checks tidak ada pada rincian kegiatan. Aplikasi
tetap dapat menyimpan kegiatan walaupun rincian kegiatan tidak diisi lengkap.
2. E-Budgeting membuat penyusunan APBD menjadi lebih mudah
Aplikasi e-Budgeting membuat penyusunan APBD menjadi lebih mudah dengan adanya fitur
database terpadu yang dimiliki oleh aplikasi e-Budgeting. Database adalah keseluruhan data
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
16
urusan, program, kegiatan, sub kegiatan, kelompok belanja, rekening, dan komponen belanja
(nama barang/jasa, harga satuan, dan satuan volume). Sedangkan, terpadu berarti database
tersebut saling terintegrasi antara satu sama lain. Dengan fitur ini, kegiatan penyusunan
APBD menjadi lebih banyak yang diotomatisasi daripada sebelumnya.
Pertama, fitur database terpadu membantu otomatisasi input RKA. Ketika melakukan input
rincian kegiatan dalam aplikasi e-Budgeting, Satuan Kerja Perangkat Daerah/Unit Kerja
Perangkat Daerah (SKPD/UKPD) hanya perlu memilih kegiatan dalam database, aplikasi
yang akan mengaitkannya langsung dengan program dan urusannya. Input rincian anggaran
juga menjadi lebih mudah. SKPD/UKPD hanya perlu memilih komponen belanja dalam
database dan mengisi volume kebutuhan. Hasil perkalian harga satuan komponen dengan
volume akan otomatis terkalkulasi. Aplikasi juga akan secara otomatis mendeteksi kode
rekening, kelompok belanja, dan sub kegiatan yang terkait dengan komponen belanja.
Tabel 3. Perbandingan Antara Input Rincian Kegiatan Dalam Aplikasi e-Budgeting Dengan Aplikasi SIP
Input Rincian Kegiatan e-Budgeting Input Rincian Kegiatan SIP
Tahapan Input
1) Pilih kegiatan dari database yang tersedia.
2) Program dan urusan terkait kegiatan yang dipilih
akan otomatis terdeteksi.
3) Isi manual lokasi, waktu pelaksanaan, jumlah
anggaran TA n-1 dan TA n+1, capaian program,
masukan, keluaran, hasil, dan kelompok sasaran.
Tahapan Input
1) Pilih program dan capaian program dari
database yang tersedia.
2) Isi manual kegiatan, lokasi, waktu pelaksanaan,
capaian program, masukan, keluaran, hasil, dan
kelompok sasaran.
Hasil Input
Kegiatan: Pelebaran Jalan Seskoal (pilih manual)
Program: Program Pembangunan/Peningkatan Jalan
dan Jembatan (otomatis)
Urusan: Pekerjaan Umum (otomatis)
Capaian program: Terlaksananya pembangunan jalan
seskoal, dst (isi manual)
Hasil Input
Program: Program Pembangunan/Peningkatan Jalan
dan Jembatan (pilih manual)
Capaian program: Terlaksananya pembangunan
jalan seskoal (pilih manual)
Kegiatan: Pelebaran Jalan Seskoal, dst (isi manual)
Sumber: Olahan penulis dari manual penggunaan aplikasi SIP dan e-Budgeting
Tabel 4. Perbandingan Antara Input Rincian Anggaran Dalam Aplikasi e-Budgeting Dengan Aplikasi SIP
Input Rincian Anggaran e-Budgeting Input Rincian Anggaran SIP
Tahapan Input
1) Pilih komponen belanja dari database yang tersedia.
2) Isi manual volume kebutuhan.
3) Hasil perkalian harga satuan komponen belanja dan volume kebutuhan
akan terkalkulasi secara otomatis.
4) Keseluruhan total anggaran per komponen belanja akan terkalkulasi
menjadi total anggaran per kegiatan.
5) Kode rekening, kelompok belanja, dan sub kegiatan terkait komponen
belanja yang dipilih akan otomatis terdeteksi.
Tahapan Input
1) Isi manual jumlah anggaran
per kegiatan.
Hasil Input
Kalkulasi anggaran per komponen belanja:
Uraian
Barang/Jasa
Harga
Satuan
Satuan
Volume
Volume Jumlah
Marka jalan
ketebalan 3 mm
Rp
240.000,-
m2 200 m
2 Rp 48.000.000,-
Aspal AC-WC
t=4 cm
Rp
200.000,-
m2 200 m
2 Rp 40.000.000,-
Hasil Input
Total
Anggaran
Kegiatan
Rp
88.000.000,-
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
17
Total Anggaran Kegiatan Rp 88.000.000,-
Kode rekening: 5.2.3.21.06 Belanja Modal Pengadaan Konstruksi Jalan
Provinsi
Kelompok belanja: Belanja Modal
Sub kegiatan: Kegiatan Fisik
Sumber: Olahan penulis dari manual penggunaan aplikasi SIP dan e-Budgeting
Selain memudahkan penyusunan APBD dengan otomatisasi input RKA, aplikasi e-
Budgeting juga membuat otomatisasi dalam penarikan ringkasan APBD sesuai dengan
struktur APBD dalam peraturan perundang-undangan. Hal tersebut dapat terjadi karena
adanya keterkaitan antara komponen belanja dengan kode rekening dan kelompok belanja.
Jika ditarik dari aplikasi e-Budgeting, maka ringkasan APBD berisi Belanja Langsung dengan
rincian Belanja Modal sebesar Rp 88.000.000,-. Sedangkan, dalam aplikasi SIP, Belanja
Langsung hanya akan memiliki rincian Belanja Program SKPD.
3. E-Budgeting membuat manajemen kendali anggaran lebih baik
Aplikasi e-Budgeting membuat manajemen kendali anggaran lebih baik dengan adanya menu
khusus untuk Gubernur dan Wakil Gubernur, serta adanya fitur penguncian. Terkait menu
khusus, Gubernur dan Wakil Gubernur memiliki dua menu khusus yang dapat digunakan
untuk melakukan manajemen kendali anggaran. Pertama, menu ringkasan untuk melihat
ringkasan APBD berdasarkan urusan pemerintahan, program, kegiatan, rekening, komponen
dan satuan. Dengan menu ini, Gubernur atau Wakil Gubernur dapat memastikan bahwa
anggaran sudah dialokasikan dengan tepat. Misalnya alokasi anggaran untuk urusan
pendidikan harus mencapai 20 persen. Kedua, menu SKPD untuk memantau anggaran
SKPD/UKPD. Menu-menu tersebuy tidak pernah ada dalam aplikasi SIP. Bahkan, tidak ada
ID dan password khusus yang dapat digunakan oleh Gubernur atau Wakil Gubernur untuk
mengakses aplikasi.
Terkait fitur penguncian, TAPD (Bappeda dan BPKD) DKI Jakarta dapat menggunakan fitur
tersebut ketika terdapat ketidaksesuaian dalam Rencana Kerja dan Anggaran (RKA) yang
telah diinput oleh SKPD. Penguncian yang dapat dilakukan adalah sebagai berikut:
Tabel 5. Pilihan Penguncian Dalam Aplikasi e-Budgeting
No. Pilihan
Penguncian Alasan Konsekuensi
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
18
1 Penguncian
SKPD
(Dilakukan oleh
Bappeda jika
permasalahan
terdapat pada
rincian kegiatan
atau BPKD jika
permasalahan
terdapat pada
rincian anggaran)
Penguncian ini dilakukan jika terdapat
SKPD/UKPD yang bermasalah karena
tidak menindaklanjuti teguran TAPD.
Dalam penyusunan APBD, mungkin
terdapat rincian kegiatan maupun
anggaran yang tidak sesuai dengan
kebutuhan kegiatan SKPD/UKPD. Jika
hal tersebut terjadi, TAPD dapat
menegur. Namun ketika peneguran
tidak ditindaklanjuti, SKPD/UKPD ID
dapat dikunci sehingga akses tertutup.
SKPD/UKPD tidak dapat melakukan
input RKA karena SKPD/UKPD ID
dikunci sehingga akses tertutup.
SKPD/UKPD yang dikunci harus
datang ke Bappeda atau BPKD untuk
meminta pembukaan akses kembali.
Bappeda atau BPKD dapat
memanfaatkannya untuk menegur
SKPD/UKPD secara langsung dan
meminta SKPD/UKPD
memperbaikinya di tempat.
2 Penguncian
Kegiatan
(Dilakukan oleh
Bappeda)
Penguncian ini dilakukan jika terdapat
kebijakan khusus mengenai kegiatan
tertentu yang tidak boleh diadakan.
Misalnya tidak boleh ada kegiatan
Pembinaan Rohani Pegawai di TA
yang sedang dirancang.
Apabila ada yang mencoba
memasukkan kegiatan tersebut ke
dalam aplikasi e-Budgeting, maka
secara otomatis tidak akan bisa
tersimpan.
3 Penguncian
Belanja
(Dilakukan oleh
BPKD)
Penguncian ini dapat dilakukan jika
terdapat kebijakan khusus mengenai
belanja tertentu yang tidak boleh
dilakukan. Misalnya tidak boleh ada
belanja modal di TA yang sedang
dirancang.
Apabila ada yang mencoba
memasukkan komponen belanja
dengan jenis belanja tersebut ke
dalam aplikasi e-Budgeting, maka
secara otomatis tidak akan bisa
tersimpan.
4 Penguncian
Rekening
(Dilakukan oleh
BPKD)
Penguncian ini dapat dilakukan jika
terdapat kebijakan khusus mengenai
rekening tertentu tidak boleh diadakan.
Misalnya tidak boleh ada rekening
belanja sewa sarana mobilitas di TA
yang sedang dirancang.
Apabila ada yang mencoba
memasukkan komponen belanja
dengan rekening tersebut ke dalam
aplikasi e-Budgeting, maka secara
otomatis tidak akan bisa tersimpan.
5 Penguncian
Komponen
Belanja
(Dilakukan oleh
BPKD)
Penguncian ini dapat dilakukan jika
terdapat kebijakan khusus bahwa di
APBD yang sedang dirancang tidak
boleh ada komponen belanja tertentu.
Misalnya tidak boleh ada belanja gula
di TA yang sedang dirancang.
Apabila ada yang mencoba
memasukkan komponen belanja
tersebut ke dalam aplikasi e-
Budgeting, maka secara otomatis
tidak akan bisa tersimpan.
Sumber: Diolah dari manual penggunaan aplikasi e-Budgeting
Dapat terlihat bahwa manajemen kendali anggaran dengan aplikasi e-Budgeting dapat
dilakukan sejak awal, bahkan sebelum proses input RKA dimulai dengan adanya fitur
penguncian terhadap kegiatan, belanja, rekening, dan komponen belanja. Dalam hal ini,
aplikasi SIP sangat berbeda dengan aplikasi e-Budgeting. Manajemen kendali anggaran
dengan aplikasi SIP lebih sulit dan membutuhkan waktu yang cukup lama. Kesulitan ditemui
karena aktivitas manajemen kendali anggaran baru dapat dilakukan ketika input RKA telah
selesai dilakukan. TAPD juga harus melakukan pengecekan secara satu per satu untuk setiap
kegiatan. Sedangkan, kebutuhan waktu yang cukup lama karena permasalahan dalam proses
manajemen kendali anggaran itu sendiri. Apabila TAPD menemukan ketidaksesuaian, TAPD
menindaklanjutinya dengan memberikan rekomendasi, namun SKPD/UKPD dapat
menolaknya. TAPD menegur lagi, bisa ditolak kembali. Hal tersebut akan berulang hingga
akhirnya tercapai kesepakatan.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
19
Tabel 6. Pilihan Tindak Lanjut Dalam Aplikasi SIP
No.
Pilihan
Tindak
Lanjut
Alasan Konsekuensi
1 Dikunci Dikunci merupakan status
awal dari seluruh kegiatan
yang akan disupervisi.
Dalam status ini maka kegiatan tidak akan dapat
direvisi apapun oleh SKPD/UKPD.
2 Dihapus
(Dilakukan
oleh Bappeda)
Dihapus karena kegiatan
dirasakan tidak dibutuhkan
oleh SKPD/UKPD.
Supervisor harus memberikan catatan koreksi kegiatan
yang harus dihapus. SKPD/UKPD harus menghapus
kegiatan tersebut. Cara menghapus kegiatan bukanlah
dengan menghapus keseluruhan kegiatan yang
diajukan, namun cukup dengan dinolkan anggarannya.
Setelah proses revisi selesai, secara otomatis kegiatan
dengan anggaran nol akan hilang.
3 Revisi
Program dan
Target
(Dilakukan
oleh Bappeda)
Revisi program dan target
karena kesalahan
perencanaan kegiatan
dalam target kinerja
program, tolok ukur
program, program dan
urusan.
Supervisor akan diminta memilih Target Kinerja
Program, Tolok Ukur Program, Program dan Urusan
yang direkomendasikan untuk perbaikan acuan
perencanaan kegiatan. Revisi yang dapat dilakukan
oleh SKPD/UKPD adalah pemilihan ulang target
kinerja program, tolok ukur program, program dan
urusan.
4 Revisi Teks
Kegiatan
(Dilakukan
oleh Bappeda)
Revisi teks kegiatan karena
nama kegiatan yang
dimasukkan kurang baku.
Supervisor akan diminta untuk mengisikan teks
lengkap nomenklatur perbaikannya. Revisi yang dapat
dilakukan oleh SKPD/UKPD adalah mengubah teks/
nomenklatur kegiatan.
5 Revisi
Indikator
Kegiatan
(Dilakukan
oleh Bappeda)
Revisi indikator kegiatan
karena kesalahan pada teks
tolok ukur dan target
indikator keluaran dan
hasil kegiatan.
Supervisor akan diminta untuk memperbaiki teks tolok
ukur dan target indikator keluaran dan hasil kegiatan.
Revisi yang dapat dilakukan oleh
SKPD/UKPD adalah mengubah indikator keluaran dan
hasil kegiatan.
6 Revisi
Anggaran
(Dilakukan
oleh BPKD)
Revisi anggaran dilakukan
ketika anggaran salah.
Supervisor akan diminta untuk mengisikan anggaran
yang direkomendasikan untuk kegiatan tersebut. Revisi
yang dapat dilakukan oleh SKPD/UKPD adalah
mengubah nilai anggaran dan kode rekening.
Sumber: Diolah dari manual penggunaan aplikasi SIP
Kesesuaian dan Ketidaksesuaian Manajemen Perubahan Aplikasi
Dalam melakukan perubahan aplikasi penyusunan APBD, Pemprov DKI Jakarta telah
memilih pendekatan yang tepat, yaitu pendekatan object oriented development (OOD). Hal
tersebut terlihat dari Pemprov DKI Jakarta yang menggunakan konsep dasar aplikasi e-
Budgeting yang telah digunakan di beberapa Pemkot/Pemkab, salah satunya adalah Pemkot
Surabaya. Apabila dikaitkan, pendekatan OOD tepat karena proses penyusunan APBD antara
satu Pemda dengan lainnya sama. Proses penyusunan APBD telah diatur dalam peraturan
perundang-undangan, seperti UU Nomor 25 Tahun 2004, Permendagri Nomor 13 Tahun 2006
yang terakhir diubah dengan Permendagri Nomor 21 Tahun 2011, PMK Nomor 46 Tahun
2006, dan PP Nomor 56 Tahun 2005. Selain itu, di Indonesia juga terdapat banyak aplikasi
penyusunan APBD yang dapat ditiru konsep dasarnya karena adanya PP Nomor 56 Tahun
2005 yang memperbolehkan Pemda untuk mengembangkan aplikasi SIKD masing-masing.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
20
Walaupun pendekatan tepat, ketidaksesuaian masih ditemukan dalam setiap tahapan
manajemen perubahan aplikasi yang dilakukan oleh Pemprov DKI Jakarta.
Tabel 7. Ikhtisar Kesesuaian dan Ketidaksesuaian Tahapan Perubahan Aplikasi
No. Tahapan Kesesuaian Ketidaksesuaian
1 Inisiasi Permohonan perubahan aplikasi
Pertimbangan kebutuhan pihak
eksternal
Penetapan tujuan
Ketidakpatuhan terhadap DPRD selaku
komite pengawas terkait ketentuan DPRD
agar Pemprov DKI Jakarta tidak
menggunakan aplikasi baru untuk
penyusunan APBD TA 2014 karena waktu
sangat singkat untuk menginput ulang
RKA.
Tidak ada pertimbangan kebutuhan pihak
internal
2 Perencanaan Pembuatan rencana (pembagian
tugas, pembuatan batas anggaran,
pembuatan jadwal dan tahapan,
serta pertimbangan risiko)
Pembuatan desain konseptual
Pembuatan desain sistem fisik
Pembuatan sebagian aktivitas
desain database fisik (pembuatan
daftar data yang dibutuhkan untuk
database)
Pembuatan jadwal terlalu singkat dan
mengabaikan risiko yang akan muncul
akibat pertentangan jadwal perubahan
aplikasi dengan jadwal penyusunan APBD
dalam peraturan perundang-undangan
Desain kontrol edit checks kurang lengkap
Aktivitas desain database fisik tidak
dilakukan baik (tidak ada perbandingan
terkait data yang sudah dimiliki dengan
data yang dibutuhkan dan cara pemenuhan
kekurangan data tidak tepat)
3 Pengembangan Pembagian tugas jelas dalam
pengembangan
Tidak ada pemisahan library produksi,
pengembangan, dan tes
4 Implementasi Pembuatan Peraturan Gubernur
untuk minimalisasi resistensi
Pemilihan strategi implementasi
bigbang
Persiapan perangkat keras dan
lunak
Persiapan pengawasan dan kontrol
Kesalahan strategi implementasi
Tidak ada pengembangan milestone chart
Tidak ada pelatihan pengguna aplikasi
Tidak ada manual penggunaan aplikasi
Tidak ada tes implementasi aplikasi
5 Penutupan Dokumentasi laporan sebagian
dibuat, yaitu laporan finansial
Pengawasan dilakukan dengan baik
oleh konsultan.
Dokumentasi laporan masalah, serta
laporan tahapan dan jadwal tidak dibuat
Sumber: Olahan penulis
Masalah dan Potensi Masalah Akibat Ketidaksesuaian Manajemen Perubahan Aplikasi
Ketidaksesuaian praktik dalam tahapan manajemen perubahan aplikasi yang dilakukan oleh
Pemprov DKI Jakarta menimbulkan masalah dan potensi masalah. Masalah yang telah terjadi
adalah keterlambatan penetapan APBD. Sedangkan, potensi masalah yang dapat terjadi
adalah rendahnya realisasi penyerapan anggaran TA 2014, kemungkinan anggaran siluman
muncul, tidak terukurnya kinerja SKPD, dan kesalahan manajemen perubahan aplikasi dapat
terulang. Diagram fishbone akan digunakan untuk menganalisis ketidaksesuaian praktik
dalam tahap apa yang berkontribusi menimbulkan masalah dan potensi masalah. Berikut
merupakan diagram akar permasalahannya.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
21
Gambar 1. Diagram Fishbone Keterlambatan Penetapan APBD
Sumber: Olahan penulis
Gambar 2. Diagram Fishbone Rendahnya Realisasi Penyerapan Anggaran TA 2014
Sumber: Olahan penulis
Gambar 3. Diagram Fishbone Kemungkinan Anggaran Siluman Muncul
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
22
Sumber: Olahan penulis
Gambar 4. Diagram Fishbone Tidak Terukurnya Kinerja SKPD
Sumber: Olahan penulis
Gambar 5. Diagram Fishbone Kesalahan Manajemen Perubahan Aplikasi Dapat Terulang
Sumber: Olahan penulis
KESIMPULAN
1. Aplikasi e-Budgeting lebih unggul dalam mendukung proses penyusunan APBD
dibandingkan dengan aplikasi SIP karena fitur aplikasi e-Budgeting yang tidak dimiliki
oleh aplikasi SIP. Proses penyusunan APBD menjadi lebih baik karena: a) Perencanaan
menjadi lebih rinci dengan adanya fitur kontrol aplikasi edit checks; b) Penyusunan APBD
menjadi lebih mudah dengan adanya fitur database terpadu dan fitur penarikan ringkasan
APBD; dan c) Manajemen kendali anggaran menjadi lebih baik dengan adanya fitur menu
khusus untuk Gubernur dan Wakil Gubernur dan fitur penguncian.
2. Dalam manajemen perubahan aplikasi penyusunan APBD, Pemprov DKI Jakarta telah
menggunakan pendekatan yang sesuai, yaitu pendekatan object oriented development
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
23
(OOD). Pendekatan OOD sesuai untuk digunakan dalam pengembangan aplikasi yang
mendukung proses bisnis yang sama antara satu organisasi dengan organisasi lainnya, serta
terdapat banyak aplikasi yang dapat ditiru konsep dasarnya. Kondisi Pemprov DKI Jakarta
sesuai karena: a) proses penyusunan APBD antara satu Pemda dengan Pemda lainnya sama
dan b) terdapat banyak aplikasi penyusunan APBD yang dapat ditiru. Sedangkan, untuk
tahapan manajemen perubahan aplikasi, ditemukan ketidaksesuaian praktik dalam tahap
inisiasi, perencanaan, pengembangan, implementasi, dan penutupan.
3. Ketidaksesuaian dalam tahapan manajemen perubahan aplikasi menimbulkan masalah dan
potensi masalah bagi Pemprov DKI Jakarta. Masalah yang telah terjadi adalah
keterlambatan penetapan APBD akibat adanya ketidaksesuaian praktik dalam tahap
inisiasi, perencanaan, pengembangan, dan implementasi. Sedangkan, potensi permasalahan
yang mungkin terjadi di masa depan adalah: a) Rendahnya realisasi penyerapan anggaran
pada TA 2014 karena adanya ketidaksesuaian praktik dalam tahap inisiasi dan
perencanaan; b) Kemungkinan anggaran siluman muncul karena adanya ketidaksesuaian
praktik dalam tahap perencanaan; c) Tidak terukurnya kinerja SKPD karena adanya
ketidaksesuaian praktik dalam tahap perencanaan; dan d) Kesalahan manajemen perubahan
aplikasi dapat terulang karena adanya ketidaksesuaian praktik dalam tahap penutupan.
SARAN
Masalah keterlambatan penetapan APBD TA 2014 yang telah terjadi tidak dapat diubah. Hal
yang dapat dilakukan hanya mengambil pembelajaran dari kesalahan manajemen perubahan
aplikasi yang telah dilakukan. Namun masih terdapat hal yang dapat dilakukan oleh Pemprov
DKI Jakarta untuk mencegah potensi permasalahan.
Tabel 8. Saran Bagi Pemprov DKI Jakarta Untuk Mencegah Potensi Masalah Terjadi
No. Potensi Masalah Hal yang Dapat Dilakukan
1 Rendahnya
realisasi
penyerapan
anggaran TA
2014.
Jika akibat tingginya harga pasar dibandingkan dengan harga database akibat
perbedaan harga satuan antara satu Kota/Kabupaten Adminstrasi dengan
Kota/Kabupaten Adminstrasi lainnya, Pemprov DKI Jakarta harus
menggunakan fitur zona harga satuan.
Jika akibat kesalahan rincian anggaran SKPD, Pemprov DKI Jakarta dapat
meminta SKPD memperbaikinya sesuai kondisi lapangan. Rincian harus
segera diperbaiki sebelum APBD-P TA 2014 ditetapkan agar sisa waktu yang
ada hingga akhir tahun dapat dimanfaatkan untuk merealisasikan kegiatan-
kegiatan yang tertunda.
Jika akibat tingginya harga pasar dibandingkan dengan harga database akibat
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
24
penggunaan komponen belanja Surabaya, Pemprov DKI Jakarta harus
memperbaharui database komponen belanja agar tidak ada lagi yang memakai
komponen milik Surabaya. Database harus diperbaharui sebelum APBD-P
TA 2014 ditetapkan agar sisa waktu yang ada hingga akhir tahun dapat
dimanfaatkan untuk merealisasikan kegiatan-kegiatan yang tertunda.
2 Kemungkinan
anggaran siluman
muncul.
Kemungkinan tersebut dapat muncul karena penggunaan volume paket. Pemprov
DKI Jakarta harus meminta SKPD yang masih menggunakan volume paket untuk
menjabarkannya.
3 Tidak terukurnya
kinerja SKPD.
Tidak terukurnya kinerja karena adanya ketidaklengkapan rincian kegiatan dalam
RKA, terutama pada instrumen kinerja. Pemprov DKI Jakarta harus meminta
SKPD untuk melengkapi kekurangan rincian. Kemudian, harus menambahkan
kontrol edit checks untuk format data spesifik rincian kegiatan harus ditambahkan
dalam aplikasi. Selain itu, sebaiknya dibuat tambahan database koneksi data
terkait program dan capaian program sesuai RPJMD sehingga capaian program
akan otomatis terisi ketika program terdeteksi.
4 Kesalahan
manajemen
perubahan
aplikasi yang
dapat terulang
kembali.
Kesalahan dapat terulang kembali karena ketidaklengkapan dokumentasi
perubahan aplikasi untuk dijadikan bahan evaluasi. Pemprov DKI Jakarta
sebaiknya membuat dokumentasi laporan yang kurang, yaitu laporan masalah
serta laporan tahapan dan jadwal. Laporan tersebut dapat menjadi bahan evaluasi
manajemen perubahan aplikasi. Dengan begitu, Pemprov DKI Jakarta memiliki
bekal untuk tidak mengulangi kesalahan yang sama di masa depan
Sumber: Olahan penulis
DAFTAR REFERENSI
Aladwani, A. M. (2001). Change Management Strategies for Successful ERP Implementation.
Business Process Management Journal, 7 (3), 266-275.
Al-Mudimigh, A., Zairi, M., & Al-Mashari, A. (2001). ERP Software Implementation: An
Integrative Framework. European Journal of Information Systems, 216-226.
Anthony, R. N., & Govindarajan, V. (2007). Management Control Systems. Singapore:
McGraw-Hill Companies Inc.
Arfani, R. N. (2013, November 14). Application Control. Audit Sistem Informasi. Depok:
Ernst and Young.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
25
Avgerou, C. (2011). Information Systems Development and Management. London: University
of London.
Basile, A., Papa, L. J., & Johnston, R. (2002). Leading High-End Accounting Software. The
CPA Journal, 26-33.
Belle, J.-P. V., Eccles, M. G., & Nash, J. M. (2003). Discovering Information Systems. USA:
Berne Convention.
Blondal, J. R., Hawkesworth, I., & Choi, H.-D. (2009). Budgeting in Indonesia. OECD
Journal on Budgeting, 1-31.
Darise, N. (2009). Pengelolaan Keuangan Daerah. Jakarta: PT Indeks.
Davis, G. B., & Olson, M. H. (1985). Management Information Systems: Conceptual
Foundations, Structure, and Development. USA: McGraw-Hill, Inc.
Deephouse, C., Mukhopadhyay, T., Goldenson, D. R., & Kellner, M. I. (1995). Software
Processes and Project Performance. Journal of Management Information Systems, 12 (3),
187-205.
Duncombe, R. (2013). Organisational Change Strategies: Business Process Re-engineering.
Manchester: University of Manchester.
Ensslin, L., Scheid, L. C., Ensslin, S. R., & Lacerda, R. T. (2012). Software Process
Assessment and Improvement Using Multicriteria Decision Aiding - Constructivist. Journal
of Information Systems and Technology Management, 9 (3), 475-496.
Falletta, S. V. (2005). Organizational Diagnostic Models: A Review & Synthetis. California:
Leadersphere, Inc.
Fantina, R. (2006). Successful Software Process Implementation. Software Quality
Professional, 8 (4), 51-52.
Fichman, R. G., & Moses, S. A. (1999). An Incremental Process for Software
Implementation. Sloan Management Review, 40 (2), 39-52.
Hardcastle, E. (2008). Business Information Systems. USA: Ventus Publishing ApS.
Harsh, S. B. (2011). Management Information Systems. Michigan: Michigan State University.
Henders, R. A. (1998). An Evolutionary Approach to Application Development With Object
Technology. IBM Systems Journal, 37 (2), 181-188.
Hoffer, J. A., George, J. A., & Valacich, J. A. (2008). Modern Systems Analysis and Design.
New Jersey: Pearson Prentice Hall.
Hough, D. (1993). Rapid Delivery: An Evolutionary Approach for Application Development.
IBM Systems Journal, 32 (3), 397-419.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
26
Hunton, J. E., Bryant, S. M., & Bagranoff, N. A. (2004). Core Concept of Information
Technology Auditing. USA: John Wiley & Sons, Inc.
Ignizio, J. P. (1991). Introduction to Expert Systems: The Development and Implementation of
Rule-Based Expert Systems. USA: McGraw-Hill, Inc.
ISACA. (2013). COBIT 5: A Business Framework for the Governance and Management of
Enterprise IT. Diambil kembali dari ISACA: http://www.isaca.org/COBIT/Pages/default.aspx
Laporan Keuangan Pemerintah Daerah Provinsi DKI Jakarta Tahun Anggaran 2012
(Audited). (2012). Jakarta.
McPherson, J. (2011). Software Implementation and Development Agreements: The Devil is
in the Detail. Software Tech & Gadget Review, 1.
Minnock, S. (2004). "GO LIVE!" Software Implementation. Construction Accounting and
Taxation, 11-15.
Mudjisantosa. (2013). Memahami Spesifikasi, HPS, dan Kerugian Negara. Jakarta: CV
Primaprint.
Mulyana, B., & Widyaiswara. (2010). Modul Perencanaan dan Penganggaran Daerah.
Jakarta: Kementerian Keuangan Republik Indonesia.
Nordiawan, D., & Hertianti, A. (2010). Akuntansi Sektor Publik. Jakarta: Penerbit Salemba
Empat.
Nordiawan, D., Putra, I. S., & Rahmawati, M. (2008). Akuntansi Pemerintahan. Jakarta:
Penerbit Salemba Empat.
Peraturan Daerah Provinsi DKI Jakarta Nomor 10 Tahun 2008 Tentang Organisasi
Perangkat Daerah. (2008). Jakarta.
Peraturan Gubernur Provinsi Daerah Khusus Ibukota Jakarta Nomor 142 Tahun 2013
Tentang Sistem dan Prosedur Pengelolaan Keuangan Daerah. (2013). Jakarta.
Peraturan Gubernur Provinsi Daerah Khusus Ibukota Jakarta Nomor 70 Tahun 2009
Tentang Organisasi dan Tata Kerja Badan Perencanaan Pembangunan Daerah. (2009).
Jakarta.
Peraturan Gubernur Provinsi DKI Jakarta Nomor 145 Tahun 2013 Tentang Penyusunan
Anggaran Pendapatan dan Belanja Daerah/Anggaran Pendapatan dan Belanja Daerah
Perubahan Melalui Electronic Budgeting. (2013). Jakarta.
Peraturan Menteri Dalam Negeri Nomor 13 Tahun 2006 Tentang Pedoman Pengelolaan
Keuangan Daerah. (2006). Jakarta.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
27
Peraturan Menteri Dalam Negeri Nomor 21 Tahun 2011 Tentang Perubahan Kedua Atas
Peraturan Menteri Dalam Negeri Nomor 13 Tahun 2006 Tentang Pedoman Pengelolaan
Kuangan Daerah. (2011). Jakarta.
Peraturan Menteri Dalam Negeri Nomor 27 Tahun 2013 Tentang Pedoman Penyusunan
Anggaran Pendapatan dan Belanja Daerah Tahun Anggaran 2014. (2013). Jakarta.
Peraturan Menteri Keuangan Nomor 46 Tahun 2006 Tentang Tatacara Penyampaian
Informasi Keuangan Daerah. (2006). Jakarta.
Peraturan Pemerintah Nomor 38 Tahun 2007 Tentang Pembagian Urusan Pemerintahan
antara Pemerintah, Pemerintah Daerah Provinsi dan Pemerintah Daerah Kabupaten/Kota.
(2007). Jakarta.
Peraturan Pemerintah Nomor 56 Tahun 2005 Tentang Sistem Informasi Keuangan Daerah.
(2005). Jakarta.
Peraturan Pemerintah Nomor 58 Tahun 2005 Tentang Pengelolaan Keuangan Daerah.
(2005). Jakarta.
Peraturan Presiden Nomor 70 Tahun 2012 Tentang Pengadaan Barang/Jasa Pemerintah.
(2012). Jakarta.
Prasetya, M. E. (2013). IT Deployment Risk. Audit Sistem Informasi. Depok: Fakultas
Ekonomi Universitas Indonesia.
Prastowo, A. (2012). Metode Penelitian Kualitatif dalam Perspektif Rancangan Penelitian.
Jogjakarta: Ar-Ruzz Media.
Rainer, R. K., & Cegielski, C. G. (2011). Introduction to Information Systems. USA: John
Wiley & Sons, Inc.
Rencana Pembangunan Jangka Menengah Daerah DKI Jakarta Periode 2013-2017. (2013).
Jakarta.
Robbins, S., & Coulter, M. (2012). Management 11th Ed. New Jersey: Pearson Prentice Hall.
Robey, M., Coney, D., & Sommer, R. A. (2006). Contracting for Implementation of Standard
Software. Industrial Management and Data Systems, 106 (4), 562-580.
Romney, M., & Steinbart, P. (2009). Accounting Information System, 11th edition. New
Jersey: Pearson Prentice Hall.
Sak. (2013, Oktober 17). E-Budgeting Solusi Sistem Anggaran. Diambil kembali dari
Ahok.org: http://ahok.org/berita/news/e-budgeting-solusi-sistem-anggaran/
Schwab, S. F., & Kallman, E. A. (1992). Software Implementation Can't Always Go by the
Book, Either. Journal of Systems Management, 43 (3), 13-18.
Analisis manajemen..., Miranti Benacorry, FE UI, 2014
28
Sekaran, U., & Bougie, R. (2013). Research Methods for Business. United Kingdom: John
Wiley & Sons Ltd.
Simons, R. (2000). Performance Measurement and Control Systems for Implementing
Strategy Text & Cases. USA: Prentice-Hall, Inc.
Stapleton, G., & Rezak, C. J. (2004). Change Management Underpins: A Successful ERP
Implementation at Marathon Oil. Journal of Organizational Excellence, 23 (4), 15-22.
Tambun, L. T. (2014, April 12). Penyerapan APBD DKI 2014 Ditargetkan 97 Persen.
Diambil kembali dari BeritaSatu.com: http://www.beritasatu.com/megapolitan/177464-
penyerapan-apbd-dki-2014-ditargetkan-97-persen.html
Taylor, H., & Stephens, C. (1997). Why Software Fails: Quality Implementation and Testing.
Proceedings of the Academy of Information and Management Sciences, 1 (2) (hal. 31-39).
Hawaii: Allied Academies International Conference.
Undang-undang Nomor 25 Tahun 2004 Tentang Perencanaan Nasional. (2004). Jakarta.
Undang-undang Nomor 29 Tahun 2007 Tentang Pemerintah Provinsi DKI Jakarta. (2007).
Jakarta.
Undang-undang Nomor 32 Tahun 2004 Tentang Pemerintahan Daerah. (2004). Jakarta.
United States Agency for International Development. (2008). Integrated Financial
Management Information Systems. USA: The Louis Berger Group, Inc. and Development
Alternatives, Inc.
Wong, R. A. (1998). Software Systems for Planning and Budgeting: An Overview. Bank
Accounting and Finance, 37-40.
Zak. (2014, Mei 20). Realisasi Penyerapan DKI Sangat Lambat. Retrieved from GATRA
News: http://www.gatra.com/nusantara-1/jawa-1/53041-realisasi-penyerapan-dki-sangat-
lambat.html
Analisis manajemen..., Miranti Benacorry, FE UI, 2014