Analisis Manajemen Perubahan Aplikasi Penyusunan APBD di

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.


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


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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


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


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)


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


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


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


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.


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)


terdapat kebijakan khusus mengenai

rekening tertentu tidak boleh diadakan.

Misalnya tidak boleh ada rekening

belanja sewa sarana mobilitas di TA

yang sedang dirancang.



dengan rekening tersebut ke dalam

aplikasi e-Budgeting, maka secara

otomatis tidak akan bisa tersimpan.

5 Penguncian

Komponen

Belanja

(Dilakukan oleh

BPKD)


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.



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.


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.


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.


21

Gambar 1. Diagram Fishbone Keterlambatan Penetapan APBD


Gambar 2. Diagram Fishbone Rendahnya Realisasi Penyerapan Anggaran TA 2014


Gambar 3. Diagram Fishbone Kemungkinan Anggaran Siluman Muncul


22


Gambar 4. Diagram Fishbone Tidak Terukurnya Kinerja SKPD


Gambar 5. Diagram Fishbone Kesalahan Manajemen Perubahan Aplikasi Dapat Terulang


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


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


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


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.


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.


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.


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.


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


Documents

Analisis Manajemen Perubahan Aplikasi Penyusunan APBD di