Analisis Manajemen Perubahan Aplikasi Penyusunan APBD di Pemerintah Provinsi DKI Jakarta

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 eBudgeting 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 1 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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. 2 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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 3 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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.

4 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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


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. 6 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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


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. 8 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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.


 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: 4243). 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. 10 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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 prototyperevisi 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. 11 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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.


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.


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.

No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Tabel 1. Proses Perubahan Aplikasi SIP Menjadi e-Budgeting Aktivitas Waktu Penggunaan aplikasi e-Budgeting untuk penyusunan APBD 2007 s.d. Akhir Oktober 2013 Penemuan masalah anggaran siluman Pertengahan tahun 2013 Pengambilan keputusan untuk perubahan aplikasi Pertengahan tahun 2013 Pengiriman perwakilan BPKD ke Surabaya untuk belajar eAwal Oktober 2013 Budgeting Pengajuan anggaran perubahan aplikasi Awal Oktober 2013 Penentuan anggaran perubahan aplikasi 24 Oktober 2013 Penandatanganan kontrak konsultan Akhir Oktober 2013 Diskusi rencana perubahan aplikasi Akhir Oktober 2013 Pemberitahuan kepada seluruh kepala SKPD tentang perubahan Awal November 2013 Penggunaan aplikasi e-Budgeting untuk penyusunan APBD Awal November 2013 s.d. Akhir Januari 2014 Pembuatan Pergub Provinsi DKI Jakarta Nomor 145 Tahun 13 Desember 2013 2013 yang menegaskan kewajiban menggunakan e-Budgeting Penyampaian Perda APBD ke DPRD Akhir Januari 2014 Penyampaian Perda APBD ke Kemendagri Pertengahan Februari 2014 Penetaoan Perda APBD 3 Maret 2014 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


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.

No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

15

Tabel 2. Perbandingan Antara Format Data Spesifik RKA Pada Aplikasi e-Budgeting dan SIP Dengan Formulir RKA SKPD 2.2.1 Formulir RKA SKPD 2.2.1 Aplikasi SIP Aplikasi e-Budgeting Urusan Pemerintahan X V Organisasi V V Program V V Kegiatan V V Lokasi Kegiatan V V Jumlah Anggaran n-1 X V Jumlah Anggaran n V V Jumlah Anggaran n+1 X V Indikator Capaian Program V V Indikator Masukan V V Indikator Keluaran V V Indikator Hasil V V Kelompok Sasaran Kegiatan V V Rincian Anggaran Belanja Langsung X V (Kode Rekening, Uraian, Volume, Satuan, Harga Satuan, dan Jumlah) 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


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 Tahapan Input 1) Pilih kegiatan dari database yang tersedia. 1) Pilih program dan capaian program dari 2) Program dan urusan terkait kegiatan yang dipilih database yang tersedia. akan otomatis terdeteksi. 2) Isi manual kegiatan, lokasi, waktu pelaksanaan, 3) Isi manual lokasi, waktu pelaksanaan, jumlah capaian program, masukan, keluaran, hasil, dan anggaran TA n-1 dan TA n+1, capaian program, kelompok sasaran. masukan, keluaran, hasil, dan kelompok sasaran. Hasil Input Hasil Input Kegiatan: Pelebaran Jalan Seskoal (pilih manual) Program: Program Pembangunan/Peningkatan Jalan Program: Program Pembangunan/Peningkatan Jalan dan Jembatan (pilih manual) dan Jembatan (otomatis) Capaian program: Terlaksananya pembangunan Urusan: Pekerjaan Umum (otomatis) jalan seskoal (pilih manual) Capaian program: Terlaksananya pembangunan jalan Kegiatan: Pelebaran Jalan Seskoal, dst (isi manual) 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 Tahapan Input 1) Pilih komponen belanja dari database yang tersedia. 1) Isi manual jumlah anggaran 2) Isi manual volume kebutuhan. per kegiatan. 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. Hasil Input Hasil Input Kalkulasi anggaran per komponen belanja: Total Rp Uraian Harga Satuan Volume Jumlah Anggaran 88.000.000,Barang/Jasa Satuan Volume Kegiatan Marka jalan Rp m2 200 m2 Rp 48.000.000,ketebalan 3 mm 240.000,Aspal AC-WC Rp m2 200 m2 Rp 40.000.000,t=4 cm 200.000,-


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 eBudgeting 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


1

2

3

4

5

Penguncian SKPD (Dilakukan oleh Bappeda jika permasalahan terdapat pada rincian kegiatan atau BPKD jika permasalahan terdapat pada rincian anggaran) Penguncian Kegiatan (Dilakukan oleh Bappeda)

Penguncian ini dilakukan jika terdapat SKPD/UKPD tidak dapat melakukan SKPD/UKPD yang bermasalah karena input RKA karena SKPD/UKPD ID tidak menindaklanjuti teguran TAPD. dikunci sehingga akses tertutup. Dalam penyusunan APBD, mungkin SKPD/UKPD yang dikunci harus terdapat rincian kegiatan maupun datang ke Bappeda atau BPKD untuk anggaran yang tidak sesuai dengan meminta pembukaan akses kembali. kebutuhan kegiatan SKPD/UKPD. Jika Bappeda atau BPKD dapat hal tersebut terjadi, TAPD dapat memanfaatkannya untuk menegur menegur. Namun ketika peneguran SKPD/UKPD secara langsung dan tidak ditindaklanjuti, SKPD/UKPD ID meminta SKPD/UKPD dapat dikunci sehingga akses tertutup. memperbaikinya di tempat. Penguncian ini dilakukan jika terdapat Apabila ada yang mencoba kebijakan khusus mengenai kegiatan memasukkan kegiatan tersebut ke tertentu yang tidak boleh diadakan. dalam aplikasi e-Budgeting, maka Misalnya tidak boleh ada kegiatan secara otomatis tidak akan bisa Pembinaan Rohani Pegawai di TA tersimpan. yang sedang dirancang. Penguncian Penguncian ini dapat dilakukan jika Apabila ada yang mencoba Belanja terdapat kebijakan khusus mengenai memasukkan komponen belanja (Dilakukan oleh belanja tertentu yang tidak boleh dengan jenis belanja tersebut ke BPKD) dilakukan. Misalnya tidak boleh ada dalam aplikasi e-Budgeting, maka belanja modal di TA yang sedang secara otomatis tidak akan bisa dirancang. tersimpan. Penguncian Penguncian ini dapat dilakukan jika Apabila ada yang mencoba Rekening terdapat kebijakan khusus mengenai memasukkan komponen belanja (Dilakukan oleh rekening tertentu tidak boleh diadakan. dengan rekening tersebut ke dalam BPKD) Misalnya tidak boleh ada rekening aplikasi e-Budgeting, maka secara belanja sewa sarana mobilitas di TA otomatis tidak akan bisa tersimpan. yang sedang dirancang. Penguncian Penguncian ini dapat dilakukan jika Apabila ada yang mencoba Komponen terdapat kebijakan khusus bahwa di memasukkan komponen belanja Belanja APBD yang sedang dirancang tidak tersebut ke dalam aplikasi e(Dilakukan oleh boleh ada komponen belanja tertentu. Budgeting, maka secara otomatis BPKD) Misalnya tidak boleh ada belanja gula tidak akan bisa tersimpan. di TA yang sedang dirancang. 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. 18 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

Tabel 6. Pilihan Tindak Lanjut Dalam Aplikasi SIP No. 1

Pilihan Tindak Lanjut Dikunci

2

Dihapus (Dilakukan oleh Bappeda)

3

Revisi Program dan Target (Dilakukan oleh Bappeda)

4

Revisi Teks Kegiatan (Dilakukan oleh Bappeda) Revisi Indikator Kegiatan (Dilakukan oleh Bappeda) Revisi Anggaran (Dilakukan oleh BPKD)

5

6

Alasan Dikunci merupakan status awal dari seluruh kegiatan yang akan disupervisi. Dihapus karena kegiatan dirasakan tidak dibutuhkan oleh SKPD/UKPD.

Konsekuensi Dalam status ini maka kegiatan tidak akan dapat direvisi apapun 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. Revisi program dan target Supervisor akan diminta memilih Target Kinerja karena kesalahan Program, Tolok Ukur Program, Program dan Urusan perencanaan kegiatan yang direkomendasikan untuk perbaikan acuan dalam target kinerja perencanaan kegiatan. Revisi yang dapat dilakukan program, tolok ukur oleh SKPD/UKPD adalah pemilihan ulang target program, program dan kinerja program, tolok ukur program, program dan urusan. urusan. Revisi teks kegiatan karena Supervisor akan diminta untuk mengisikan teks nama kegiatan yang lengkap nomenklatur perbaikannya. Revisi yang dapat dimasukkan kurang baku. dilakukan oleh SKPD/UKPD adalah mengubah teks/ nomenklatur kegiatan. Revisi indikator kegiatan Supervisor akan diminta untuk memperbaiki teks tolok karena kesalahan pada teks ukur dan target indikator keluaran dan hasil kegiatan. tolok ukur dan target Revisi yang dapat dilakukan oleh indikator keluaran dan SKPD/UKPD adalah mengubah indikator keluaran dan hasil kegiatan. hasil kegiatan. Revisi anggaran dilakukan Supervisor akan diminta untuk mengisikan anggaran ketika anggaran salah. 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 eBudgeting 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. 19 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

Walaupun pendekatan tepat, ketidaksesuaian masih ditemukan dalam setiap tahapan manajemen perubahan aplikasi yang dilakukan oleh Pemprov DKI Jakarta.

No. 1

2

3 4

5

Tabel 7. Ikhtisar Kesesuaian dan Ketidaksesuaian Tahapan Perubahan Aplikasi Tahapan Kesesuaian Ketidaksesuaian Inisiasi  Permohonan perubahan aplikasi  Ketidakpatuhan terhadap DPRD selaku komite pengawas terkait ketentuan DPRD  Pertimbangan kebutuhan pihak agar Pemprov DKI Jakarta tidak eksternal menggunakan aplikasi baru untuk  Penetapan tujuan penyusunan APBD TA 2014 karena waktu sangat singkat untuk menginput ulang RKA.  Tidak ada pertimbangan kebutuhan pihak internal Perencanaan  Pembuatan rencana (pembagian  Pembuatan jadwal terlalu singkat dan tugas, pembuatan batas anggaran, mengabaikan risiko yang akan muncul pembuatan jadwal dan tahapan, akibat pertentangan jadwal perubahan serta pertimbangan risiko) aplikasi dengan jadwal penyusunan APBD dalam peraturan perundang-undangan  Pembuatan desain konseptual  Desain kontrol edit checks kurang lengkap  Pembuatan desain sistem fisik  Aktivitas desain database fisik tidak  Pembuatan sebagian aktivitas dilakukan baik (tidak ada perbandingan desain database fisik (pembuatan terkait data yang sudah dimiliki dengan daftar data yang dibutuhkan untuk data yang dibutuhkan dan cara pemenuhan database) kekurangan data tidak tepat) Pengembangan  Pembagian tugas jelas dalam  Tidak ada pemisahan library produksi, pengembangan pengembangan, dan tes Implementasi  Pembuatan Peraturan Gubernur  Kesalahan strategi implementasi untuk minimalisasi resistensi  Tidak ada pengembangan milestone chart  Pemilihan strategi implementasi  Tidak ada pelatihan pengguna aplikasi bigbang  Tidak ada manual penggunaan aplikasi  Persiapan perangkat keras dan  Tidak ada tes implementasi aplikasi lunak  Persiapan pengawasan dan kontrol Penutupan  Dokumentasi laporan sebagian  Dokumentasi laporan masalah, serta dibuat, yaitu laporan finansial laporan tahapan dan jadwal tidak dibuat  Pengawasan dilakukan dengan baik oleh konsultan. 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. 20 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

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


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 22 Analisis manajemen..., Miranti Benacorry, FE UI, 2014

(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. No. 1

Tabel 8. Saran Bagi Pemprov DKI Jakarta Untuk Mencegah Potensi Masalah Terjadi Potensi Masalah Hal yang Dapat Dilakukan Rendahnya

 Jika akibat tingginya harga pasar dibandingkan dengan harga database akibat

realisasi

perbedaan harga satuan antara satu Kota/Kabupaten Adminstrasi dengan

penyerapan

Kota/Kabupaten Adminstrasi lainnya, Pemprov DKI Jakarta harus

anggaran TA

menggunakan fitur zona harga satuan.

2014.

 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 kegiatankegiatan yang tertunda.  Jika akibat tingginya harga pasar dibandingkan dengan harga database akibat


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

3

Kemungkinan

Kemungkinan tersebut dapat muncul karena penggunaan volume paket. Pemprov

anggaran siluman

DKI Jakarta harus meminta SKPD yang masih menggunakan volume paket untuk

muncul.

menjabarkannya.

Tidak terukurnya

Tidak terukurnya kinerja karena adanya ketidaklengkapan rincian kegiatan dalam

kinerja SKPD.

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

Kesalahan dapat terulang kembali karena ketidaklengkapan dokumentasi

manajemen

perubahan aplikasi untuk dijadikan bahan evaluasi. Pemprov DKI Jakarta

perubahan

sebaiknya membuat dokumentasi laporan yang kurang, yaitu laporan masalah

aplikasi yang

serta laporan tahapan dan jadwal. Laporan tersebut dapat menjadi bahan evaluasi

dapat terulang

manajemen perubahan aplikasi. Dengan begitu, Pemprov DKI Jakarta memiliki

kembali.

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.


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.


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.


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.


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/177464penyerapan-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 Perubahan Aplikasi Penyusunan APBD di Pemerintah Provinsi DKI Jakarta

Recommend Documents