BAB IV HASIL DAN PEMBAHASAN

Transkripsi

1 BAB IV HASIL DAN PEMBAHASAN 4.1 Mengidentifikasi Proses Penyusunan Anggaran yang Dilakukan Di ANRI, proses penyusunan anggaran yang dilakukan sebagian masih berjalan secara manual, yaitu menggunakan microsoft word untuk pembuatan TOR (Term of Reference). Dan dalam menyusun RAB (Rencana Anggaran Biaya) menggunakan spreadsheet dan ada yang menggunakan aplikasi RKA-K/L (Rencana Kerja Anggaran Kementerian Lembaga). Pelaksanaan penyusunan RKA-K/L pada ANRI dimulai dari menyerahkan usulan anggaran yang diserahkan secara manual (tidak secara online), kemudian penelaahan usulan tersebut dilakukan dengan cara memeriksa secara manual printout yang diserahkan oleh unit kerja disesuaikan dengan program, kegiatan, standar biaya, output, volume, dan alokasi pagu anggaran. Selanjutnya penggabungan data yang dilakukan adalah menggabungkan data RAB yang dibuat menggunakan aplikasi RKA-K/L, kemudian hasil penggabungan data dicetak untuk meminta persetujuan dari KPA (Kuasa Pengguna Anggaran) untuk selanjutnya dilakukan penelaahan dengan Kementerian Keuangan. Setelah dilakukan pembahasan dan disetujui oleh Kementerian Keuangan maka terbitlah RKA-K/L Arsip Nasional Republik Indonesia. Dengan melihat proses bisnis yang ada sekarang ini dapat disimpulkan bahwa proses yang dilakukan sebagian besar masih dilakukan secara manual walaupun dalam penginputan RAB sudah mempergunakan aplikasi RKA-K/L 76

2 77 yang dikeluarkan oleh Kementerian Keuangan. Pengiriman hasil aplikasi diantar oleh staf kepada Bagian Program dan Anggaran berupa back up data RKA-K/L dan printoutnya beserta TOR. Begitupula pengiriman data kepada Kementerian Keuangan juga masih dilakukan tidak secara online. Hal tersebut menunjukkan proses yang dilakukan tidak efektif dan efisien baik dari segi waktu antara lain dalam kecepatan penyampaian data, kecepatan pembuatan usulan, waktu pencarian data, waktu untuk mengakses data sehingga menyebabkan waktu pengumpulan usulan tidak sesuai dengan jadwal yang telah ditetapkan. Di sisi lain kontrol terhadap ketepatan usulan anggaran berupa kesesuaian data masih dilakukan secara manual, dan tidak terintegrasi antara unit satu dengan unit kerja lainnya. Hal tersebut bisa menimbulkan terjadi banyak paperwork, informasi kegiatan tidak dapat diakses antar unit sehingga menyebabkan kegiatan yang berulang maupun kurang berkualitas, dan kekurangan lain seperti data-data yang dihasilkan tidak reliable dan akurat. Hal tersebut menyebabkan dampak negatif yang cukup besar yang nantinya sangat berpengaruh terhadap kinerja manajemen organisasi yang secara langsung juga berdampak terhadap penerapan anggaran berbasis kinerja Proses Pembuatan Alokasi Anggaran Unit Kerja Anggaran disusun dengan tujuan untuk mendukung program yang meliputi kegiatan-kegiatan di unit kerja. Dimana anggaran tersebut nantinya akan direalisasikan dalam bentuk uang untuk membiayai berbagai proses baik dari kegiatan yang mendukung manajemen, pembangunan sarana prasana maupun kegiatan substantif kearsipan di ANRI. Alokasi anggaran dikelompokan menjadi

3 78 kegiatan prioritas, kegiatan mengikat/operasional, kegiatan non operasional, dan kegiatan PNBP (Penerimaan Negara Bukan Pajak), dan kegiatan yang merupakan program rutin. Proses pembuatan Alokasi Anggaran Unit Kerja dimulai pada saat instansi menerima SE (Surat Edaran) dari Kementerian Keuangan yang berisi pagu anggaran Program dan Kegiatan. Dari alokasi yang terdapat pada SE tersebut kemudian di breakdown oleh Bagian Program dan Anggaran sesuai program dan kegiatannya menjadi alokasi per kegiatan di masing-masing unit kerja. Dasar pembagian alokasi per unit kerja adalah usulan unit kerja di tahun anggaran sebelumnya yang telah disetujui oleh Bappenas dan tercantum dalam Rencana Strategis (Renstra) ANRI. Dokumen alokasi anggaran yang telah dibuat oleh Bagian Program dan Anggaran kemudian diusulkan kepada Biro Perencanaan untuk dilakukan rapat dengan para pimpinan yang kemudian dimungkinkan akan terdapatnya beberapa kebijakan untuk dilakukan perubahan alokasi anggaran per unit kerja. Alokasi anggaran yang berlaku apabila sudah disahkan oleh Sekretaris Utama selaku KPA (Kuasa Pengguna Anggaran). Apabila telah disahkan oleh Sekretaris Utama, dokumen Alokasi Anggaran didistribusikan secara manual kepada seluruh unit kerja per eselon II untuk menjadi acuan dalam menentukan pagu anggaran kegiatannya.

4 Proses Pembuatan TOR (Term of Reference) dan RAB (Rencana Anggaran Biaya) TOR dan RAB dibuat oleh masing-masing unit kerja di ANRI berdasarkan target dan ketentuan anggaran yang ada. Unit kerja menerima informasi target dan ketentuan dari Bagian Program dan Anggaran, kemudian di breakdown sesuai dengan kebutuhan kegiatan di masing-masing unit kerja. RAB yang diusulkan baik program maupun kegiatan tidak boleh melebihi pagu anggaran, volume, dan satuan yang telah ditentukan pada alokasi anggaran ANRI yang telah ditetapkan Proses Kompilasi RKA-K/L (Rencana Kerja Anggaran Kementerian/ Lembaga) RAB yang telah dibuat oleh unit kerja diserahkan kepada Bagian Program dan Anggaran untuk dikompilasi dalm bentuk format aplikasi RKA-K/L. Proses kompilasi RKA-K/L merupakan proses pengintegrasian data yang telah dibuat oleh unit kerja di ANRI. Saat ini, dalam RKA-K/L tidak terdapat kontrol secara otomatis terhadap target dan ketentuan yang telah ditetapkan, kontrol masih dilakukan secara manual oleh Bagian Program dan Anggaran Proses Pembuatan Dokumen Pelaksanaan Anggaran Dokumen pelaksanaan anggaran yang dibuat merupakan dokumen yang berisi petunjuk pelaksanaan kegiatan yang akan dilaksanakan di tahun berjalan. Dokumen tersebut dibuat berdasarkan dokumen RKA-K/L Final yang telah disahkan oleh Kementerian Keuangan. Di ANRI dokumen pelaksanaan kegiatan disebut dengan Petunjuk Operasional Kegiatan (POK). Saat ini masih dibuat

5 80 dalam bentuk spreadsheat yang kemudian hardcopynya disahkan oleh Sekretaris Utama selaku Kuasa Pengguna Anggaran (KPA). Selanjutnya setelah disahkan POK tersebut didistribusikan kepada unit kerja sebagai pedoman pelaksanaan anggaran dan kegiatan. 4.2 Tenaga Pelaksana Sistem Informasi Anggaran di ANRI Tenaga pelaksana untuk melaksanakan sistem informasi anggaran saat ini oleh peneliti dibagi menjadi 2 (dua) bagian utama, yaitu penyusun anggaran dan pengendali anggaran. Penyusun anggaran adalah karyawan yang difungsikan pada periode tertentu oleh unit kerjanya untuk menyusun anggaran dan tersebar di unit kerja di ANRI. Sedangkan pengendali anggaran adalah staf/karyawan, pejabat, maupun fungsional perencana yang terdapat di Bagian Program dan Anggaran di Biro Perencanaan. Dimana gambaran tenaga yang terkait dengan sistem informasi anggaran saat ini dapat dilihat pada tabel 4.1. Pengendali anggaran selain bertugas sebagai pengendali anggaran, juga berperan sebagai penyusun anggaran di unit kerjanya,. Begitu pula penyusun anggaran di berbagai unit kerja, mereka tidak hanya melaksanakan tugas penyusunan anggaran yang dilakukan secara periode, tetapi juga mereka memiliki tugas pribadi yang terkait dengan tupoksi di masing-masing unitnya. Kondisi berperan ganda ini akan semakin berat ketika harus mengerjakan proses penyusunan anggaran yang sebagian besar masih secara manual.

6 81 Tabel 4.1 Petugas yang Terkait dengan Sistem Informasi Anggaran NO PETUGAS JUMLAH JENIS TENAGA 1 Penyusun Anggaran a. Biro Hukum dan Kepegawaian tersebar di unit kerja - input data RAB (Rencana Anggaran Biaya) b. Biro Perencanaan - input data TOR (Term of Reference) c. Biro Umum - kompilasi data RKAKL per Eselon II d. Inspektorat - melengkapi data dukung usulan anggaran e. Direktorat Akreditasi dan Profesi Kearsipan f. Direktorat Akuisisi g. Direktorat Pengolahan h. Direktorat Preservasi i. Direktorat Pemanfaatan j. Direktorat Kearsipan Pusat k. Direktorat Kearsipan Daerah l. Pusat Diklat Kearsipan m. Pusat Jasa Kearsipan n. Pusat Pengkajian dan Pengembangan Sistem Kearsipan o. Pusat Pengkajian dan Pengembangan Sistem Informasi Kearsipan - menyesuaikan RAB dengan standar biaya dan ketentuan anggaran 2 Pengendali Anggaran a. Kasubbag. Penyusunan Program b. Kasubbag. Penyusunan Anggaran c. Kasubbag. Evaluasi dan Pelaporan d. Staf Bagian Program dan Anggaran 1 orang - membuat alokasi anggaran 1 orang - mengontrol data RAB dan TOR 1 orang - mengontrol data dukung usulan anggaran 7 orang - menyesuaikan data dengan standar biaya dan ketentuan anggaran e. Fungsional Perencana 4 orang - kompilasi data RKAKL seluruh ANRI Tidak semua penyusun anggaran di unit kerja tidak begitu memahami target maupun ketentuan anggaran yang berlaku, dan knowledge tentang anggaran

7 82 sebelumnya tidak mereka ketahui. Hal tersebut menyebabkan kegiatan penyusunan anggaran menjadi lama, tidak tepat waktu, tidak sesuai yang diharapkan sehingga dapat mengganggu proses kegiatan yang lainnya. 4.3 Masalah-masalah Sistem yang Berjalan Masalah yang ditemui dalam sistem informasi anggaran dapat diidentifikasi dari melakukan observasi, wawancara, dan kuesioner Hasil Observasi Observasi dilakukan di Bagian Program dan Anggaran ANRI, karena di unit kerja inilah pusat proses penyusunan anggaran di internal ANRI dilakukan. Dari observasi yang telah dilaksanakan, maka dapat ditemukan beberapa kekurangan sistem yang berjalan yang selama ini menjadi hambatan dan sangat mempengaruhi proses penyusunan anggaran: 1. Sistem yang dilakukan dalam melakukan pengontrolan terhadap target dan ketentuan yang berkaitan dengan anggaran masih dilakukan secara manual, sehingga memungkinkan proses yang lama dan memungkinkan terjadinya human error. 2. Sistem antar unit kerja tidak terintegrasi dan tidak dapat diakses secara online sehingga apabila dibutuhkan akan kesulitan dalam pencarian data maupun dokumennya, karena membutuhkan key person yang melakukan penyusunan anggaran tersebut, ataupun dengan cara memilah dokumen yang ada. Hal tersebut menyebabkan environment tidak transparannya data anggaran antar unit kerja dan membutuhkan waktu proses yang lama, sehingga tidak efisien.

8 83 3. Dalam melakukan pembuatan usulan anggaran sering tidak tepat waktu karena tidak adanya warning secara otomatis untuk jadwal maupun time frime yang dibutuhkan dalam satu periode waktu anggaran yang diperlukan. 4. Apabila akan dilakukan penggabungan terhadap data anggaran antar unit kerja, dalam proses mengantarkan data masih dilakukan secara manual, karyawan mengantarkan backup data dan hardcopynya. 5. Approval pejabat yang berwenang baik terhadap usulan anggaran unit kerja, maupun terhadap usulan ke Kementerian Keuangan masih dilakukan secara manual dengan menandatangani hardcopy usulan anggaran Hasil Wawancara Pada berbagai kesempatan, wawancara diakukan secara bertahap untuk mengetahui permasalahan akan sistem penganggaran ini. Wawancara tidak hanya dilakukan di lingkungan internal ANRI, tetapi juga dilakukan di Lembaga Administrasi Negara (LAN), dan juga di Kementerian Keuangan. Saat ini sistem yang ada mempunyai fasilitas untuk menggabungkan data, tetapi informasi tentang anggaran adalah hanya standar biaya umum dari tahun anggaran sebelumnya. Sehingga dalam pelaksanaan penyusunan anggaran memiliki banyak kendala antara lain yang berkaitan dengan informasi angaran baik target dan ketentuan yang up to date, data usulan antar unit kerja tidak dapat disinergikan dalam hal kegiatan yang diusulkan, selain itu juga tidak adanya kontrol dalam penjadwalan usulan per pagu maupun time frime yang diberikan. Permasalahan-permasalahan tersebut dapat disimpulkan dari identifikasi masalah hasil wawancara dengan para responden pada tabel 4.2 di bawah ini.

9 84 Tabel 4.2 Hasil Wawancara INSTANSI JABATAN MASALAH ANRI Kepala Sub Bagian Penyusunan Anggaran LAN Kepala Bagian Program dan Anggaran Staf Penyusunan Anggaran Staf Biro Umum Staf Direktorat Kearsipan Daerah Kepala Sub Bagian Program dan Anggaran - unit kerja dalam pengumpulan usulan anggaran tidak sesuai dengan waktu yang telah ditetapkan - usulan tidak sesuai dengan target dan ketentuan yang telah ditetapkan - kontrol manual menyebabkan kesalahan juga masih sering terjadi dan waktu proses lama - banyak sekali berkas usulan anggaran yang harus difilekan - jika butuh data/dokumen membutuhkan waktu lama untuk mencari - sulit dan lama dalam melakukan kontrol terhadap data usulan anggaran, karena dilakukan secara manual dan memeriksa satu-persatu - penggabungan data antar unit kerja menjadi berat karena harus memeriksa semua standar dan ketentuan anggaran yang berlaku, juga target unit kerja secara manual - unit kerja tidak dapat mem follow up perkembangan usulan dan kekurangan dokumen yang dibutuhkan secara langsung - dalam pelaksanaan pembuatan RAB, standar maupun ketentuan mengenai biaya anggaran tidak digunakan karena butuh waktu untuk membuka petunjuknya - dalam pelaksanaannya terdapat berbagai kendala, baik dari dalam instansi maupun luar instansi, seperti tidak terpenuhinya jadwal usulan yang harus masuk, data RAB tidak sesuai standar biaya yang berlaku, kebijakan pimpinan yang mendadak membutuhkan waktu untuk merubah usulan anggaran Kementerian Keuangan Sub Direktorat Anggaran III Pranata Komputer - usulan anggaran sering tidak sesuai dengan target dan ketentuan yang telah ditetapkan - perubahan usulan anggaran berkaitan dengan kebijakan pimpinan internal yang sifatnya mendadak - perlu diberikan 'warning' terhadap para penyusun anggaran di tiap instansi sehingga usulan anggaran tiap pagu bisa selesai pada waktunya

10 85 Tabel 4.3 Permasalahan-permasalahan pada Proses Penyusunan Anggaran NO MASALAH PENYEBAB 1 Kelengkapan Data yang diinput tidak berdasar pada target dan ketentuan 2 Kesesuaian Informasi yang dihasilkan tidak sesuai dengan kebutuhan manajemen 3 Keakuratan Proses pengolahan data di unit kerja, maupun di Bagian Program dan Anggaran yang kurang kontrol 4 Ketepatan Waktu Proses tidak memenuhi time frame Hasil Kuesioner Dalam penelitian ini dilakukan survey terhadap responden akan sistem penganggaran yang sedang berjalan dengan membagikan kuesioner. Kuesioner dibagikan kepada 30 orang responden secara langsung. Setelah dilakukan tabulasi terhadap 30 orang responden tersebut, peneliti dapat mengelompokkan responden kuesioner tersebut terhadap jenis kelamin, usia, pendidikan, lama bekerja. Tabel 4.4 Profil Responden (Sumber : Pengolahan Data, 2012) JUMLAH PROSENTASE KETERANGAN (ORANG) (%) JENIS KELAMIN Laki-laki Perempuan USIA Tahun Tahun Tahun Tahun PENDIKAN SMU D S S MASA BEKERJA Tahun Tahun Tahun Tahun

11 86 Selanjutnya untuk mendapatkan gambaran mengenai subyek penelitian digunakan tabel distribusi frekuensi dalam jumlah dan prosentase. Data profil responden secara rinci dapat dilihat pada tabel 4.4. Mayoritas responden berkelamin laki-laki sebanyak 20 orang atau 66,67% dan sisanya perempuan sebesar 10 orang atau 33,33%. Didominasi usia tahun sebesar 17 orang atau 56,67%, dan usia tahun sebanyak 11 orang atau 36,67%, serta usia 42 tahun sebesar 2 orang atau 6,67%. Sedangkan untuk latar belakang pendidikan para responden lebih banyak berasal dari S1 sebesar 20 orang atau 66,67%, kemudian sisanya S2 sebanyak 5 orang atau 16,67%, D3 sebanyak 4 orang atau 13,33%, dan SMU sebanyak 1 orang atau 3,33%. Responden dengan masa kerja selama 6-10 Tahun sebanyak 12 orang atau 40%, masa kerja 5 tahun dan masa kerja antara tahun sebesar 8 orang atau 26,67%, dan masa kerja 16 tahun sebanyak 2 orang atau 6,67%. Tabel 4.5 Hasil Pertanyaan Umum (Sumber : Pengolahan Data, 2012) KETERANGAN JUMLAH PROSENTASE (ORANG) (%) TERLIBAT DALAM PROSES Setiap Periode Perintah Sewaktu-waktu KOMUNIKASI Surat-menyurat/Nota Dinas Komunikasi Langsung Telepon Lainnya (Chating) INFORMASI Internet Surat Biro Perencanaan Unit Kerja Lain Lainnya - - Selain itu ditanyakan tentang pertanyaan umum terhadap responden untuk melihat keterlibatan dalam proses penganggaran, komunikasi yang dilakukan, dan

12 87 media informasi anggaran yang didapat. Untuk keterlibatan karyawan tersebut dalam proses penganggaran di setiap periode anggaran sebesar 28 orang atau 93,33% dibandingkan dengan yang diperintah oleh atasannya sewaktu-waktu sebesar 2 orang atau 6,67%. Dan komunikasi terhadap Biro Perencanaan terkait dengan penyusunan anggaran banyak dilakukan dengan komunikasi secara langsung sebesar 19 orang atau 63,33%, melalui telepon sebanyak 17 orang atau 56,67%, adanya yang melalui chating sebanyak 5 orang atau 16,67%, melalui dan surat menyurat (nota dinas) sebanyak 4 orang atau 13,33%. Dan sebagian besar responden sebanyak 19 orang atau 63,33% menerima informasi tentang Peraturan, Standar Biaya, dan ketentuan-ketentuan yang berkaitan dalam proses penyusunan anggaran didapat dari Biro Perencanaan, dari Internet sebesar 12 orang atau 40%, dan dari unit kerja lain sebesar 6 orang atau 20%. Tanggapan responden mengenai Ketersediaan Informasi, Keterlibatan Unit Kerja, dan Kecukupan Sistem yang Berjalan dapat dilihat pada tabel-tabel di bawah ini. a. Ketersediaan Informasi Untuk kebutuhan akan ketersediaan informasi dalam sistem tabel 4.6 menunjukkan responden membutuhkan adanya informasi berkisar antara 17%- 63%. Tanpa informasi anggaran yang dapat diterima dengan jelas dan selalu up to date maka akan menghambat proses penyusunan anggaran, karena sistem penganggaran yang sekarang berjalan cukup rumit dan memiliki time frame yang singkat di setiap periode anggarannya. Informasi yang paling dibutuhkan keberadaannya dalam sistem adalah Informasi tentang SE Menteri Keuangan mengenai Pagu Anggaran sebesar 63%, Informasi tentang Alokasi Anggaran

13 88 (kegiatan prioritas/nonprioritas, kegiatan mengikat/nonmengikat, output, volume, satuan,dll) di internal ANRI sebesar 57%, dan Informasi tentang Peraturanperaturan, Standar Biaya serta ketentuan-ketentuan yang berkaitan dengan anggaran sebesar 50%. Tabel 4.6 Tanggapan Responden tentang Ketersediaan Informasi NO PERNYATAAN TAK SETUJU N (%) SETUJU N (%) Informasi tentang SE Menteri Keuangan mengenai Pagu Anggaran Informasi tentang Peraturan-peraturan, Standar Biaya serta ketentuan-ketentuan yang berkaitan dengan anggaran Informasi tentang Alokasi Anggaran (kegiatan prioritas/nonprioritas, kegiatan mengikat/nonmengikat, output, volume, satuan,dll) di internal ANRI Informasi dan perkembangan tentang usulan anggaran dan kegiatan Informasi tentang kelengkapan dokumen pendukung dalam pengusulan anggaran Informasi tentang jadwal mengenai pelaksanaan usulan anggaran Informasi tentang jangka waktu (time frame)dalam penyusunan anggaran cukup dan jelas 11 37% 19 63% 15 50% 15 50% 13 43% 17 57% 17 57% 13 43% 18 60% 12 40% 25 83% 5 17% 8 27% 12 40% b. Keterlibatan Unit Kerja Dalam hal keterlibatan unit kerja dalam sistem pada tabel 4.7 menunjukkan bahwa responden menginginkan keterlibatan dalam proses penganggaran antara 37%-83%. Dimana keterlibatan dengan nilai tertinggi sebesar 83% dalam proses penyusunan RAB (Rencana Anggaran Biaya) kegiatan. Selanjutnya responden menyatakan dengan adanya sistem, unit kerja terbantu dalam memahami proses bisnis penganggaran yang berjalan sebesar 50%, sehingga mereka tahu persis apa yang harus dikerjakan dalam proses

14 89 penganggaran yang dikerjakannya, sehingga data yang dihasilkan reliabel dan waktu proses akan menjadi singkat. Responden juga membutuhkan informasi hasil pembahasan anggaran dari Kementerian Keuangan, Bappenas maupun DPR secara up to date sebesar 50%. Tabel 4.7 Tanggapan Responden tentang Keterlibatan Unit Kerja NO PERNYATAAN TAK SETUJU N (%) SETUJU N (%) Unit kerja paham terhadap bisnis proses sistem penganggaran Unit kerja terlibat langsung dalam proses penyusunan RAB (Rencana Anggaran Biaya) kegiatan Unit kerja dilibatkan dalam pembahasan anggaran di internal ANRI Unit kerja mendapatkan informasi hasil pembahasan anggaran di Kementerian Keuangan, Bappenas, maupun DPR 15 50% 15 50% 5 17% 25 83% 19 63% 11 37% 15 50% 15 50% c. Kebutuhan Sistem Pada tabel 4.8 menunjukkan tanggapan responden terhadap kebutuhan sistem di mana nilainya berkisar antara 53%-77%. Kebutuhan tertinggi yaitu pada approval dalam sistem dari pejabat yang berwenang di instansi dalam proses penyusunan anggaran dan pemberitahuan dalam pribadi untuk informasi seputar proses penyusunan anggaran sebesar 77%. Selain itu kebutuhan akan adanya pembatasan hak atas akses sistem dalam proses penyusunan anggaran sebesar 73%.

15 90 Tabel 4.8 Tanggapan Responden tentang Kebutuhan Sistem NO PERNYATAAN TAK SETUJU N (%) SETUJU N (%) Approval dari pejabat yang berwenang di instansi dalam proses penyusunan anggaran Persetujuan Eselon II dalam sistem sebelum usulan diserahkan ke Bagian Program dan Anggaran Model otorisasi login pada sistem untuk keamanan account Pembatasan hak atas akses sistem dalam proses penyusunan anggaran Pembatasan waktu dalam proses penyusunan anggaran Pembatasan pagu anggaran yang berkaitan dengan standar biaya dan ketentuan tentang anggaran Interaksi dengan sesama penyusun anggaran dari unit kerja lain Pemberitahuan dalam pribadi untuk informasi seputar proses penyusunan anggaran 7 23% 23 77% 8 27% 22 73% 9 30% 21 70% 8 27% 22 73% 14 47% 16 53% 12 40% 18 60% 12 40% 18 60% 7 23% 23 77% 4.4 Benchmarking dengan Negara Lain dan Instansi Lain Proses Penganggaran di Morocco Proses penyusunan anggaran di Morocco dapat dilihat pada gambar 4.1, diawali dengan membuat framework ekonomi makro dan anggaran keseluruhan pada bulan Januari oleh Kementerian Keuangan, yang kemudian dihasilkan draft outline anggaran pada bulan Mei. Selanjutnya draft outline tersebut diterima oleh Perdana Menteri Morocco yang melakukan langkah membuat kebijakan (policy guidelines) anggaran. Di saat yang bersamaan Kementerian-kementerian menyiapkan proposal anggaran yang diajukan pada bulan Juli. Kemudian pada bulan Oktober dilakukan negoisasi antar 3 (tiga) pihak, yaitu Kementerian

16 91 Keuangan, Perdana Menteri, dengan masing-masing Kementerian. Dari negoisasi 3 (tiga) pihak tersebut dihasilkan draft anggaran, yang kemudian pada bulan Desember dilakukan voting dan approval anggaran oleh Parlemen. Gambar 4.1 Proses Penyusunan Anggaran di Morocco (Sumber : Shah, 2007, The World Bank)

17 92 Yang terlihat dari bisnis proses penyusunan anggaran di negara Morocco terdapat secara garis besar memiliki persamaan dengan Indonesia yaitu menentukan draft outline anggaran, policy guidelines anggaran, dan dilakukan negoisasi anggaran, kemudian approval anggaran yang dilakukan oleh Parlemen/DPR. Setiap tahapan prosesnya memiliki time frame dan terdapat pembagian kewenangan yang jelas. Perbedaannya, di Indonesia usulan anggaran dimulai secara bottom up dimana Kementerian/Lembaga mengajukan usulan program dan kegiatan terhadap Bappenas, sedangkan di Morocco, draft outline ditentukan secara top down dari Kementerian Keuangan. Dan pada saat negoisasi anggaran 3 pihak (trilateral meeting), di Indonesia yang berperan adalah Kementerian Keuangan, Bappenas, dan Kementerian/Lembaga. Sedangkan di Morocco yang memiliki peran adalah Kementerian Keuangan, Perdana Menteri, dan Kementerian/Lembaga. Proses penyusunan anggaran di Indonesia berkali-kali dilakukan yaitu dari pagu indikatif, pagu anggaran, dan alokasi anggaran, sehingga proses top down dan bottom up yang dilakukan secara berulang-ulang. Sedangkan di Morocco proses hanya dilakukan satu kali dan diakhiri dengan voting dan approval anggaran dari Parlemen Proses Penganggaran di South Africa Proses penganggaran di South Africa dimulai dengan penetapan kebijakan Rencana Strategis oleh Kabinet pada bulan Januari, kemudian diikuti oleh Kementerian dan Lembaga untuk menyiapkan proposal anggaran pada bulan Februari. Kemudian antara bulan Maret sampai dengan Agustus proses

18 93 penyusunan anggaran terus berlangsung dengan mempertimbangkan pembiayaan baru yang bersifat prioritas, dan juga dilakukan revisi terhadap kebijakankebijakan yang ada. Pada bulan Agustus-September dilakukan pembahasan pembiayaan 3 (tiga) pihak antara Kabinet, Kementerian dan Parlemen, yang kemudian dihasilkan Pengalokasian Anggaran pada bulan September. Setelah Kabinet menyetujui Alokasi Anggaran pada bulan Oktober, kemudian Kementerian/Lembaga menyiapkan dokumen anggaran pada bulan November- Desember. Baru kemudian pada awal tahun depannya dilakukan Penetapan Anggaran Kementerian dan Lembaga. Gambar 4.2 Proses Penganggaran di South Africa (Sumber : Shah, 2007, The World Bank)

19 94 Pada gambar 4.2 memperlihatkan proses penganggaran di South Africa yang berjalan selama 1 (satu) tahun anggaran. Kewenangan yang ada terbagi menjadi Kabinet, Kementerian/Lembaga, dan Parlemen. Persamaan dengan Indonesia yaitu setiap tahapan proses penganggaran memiliki time frame dan terdapat pembagian kewenangan yang jelas, proses penganggaran dilakukan secara pendekatan top down dan bottom up. Kementerian/Lembaga menyiapkan proposal anggaran secara bottom up, dan melakukan pembahasan anggaran dengan Parlemen/DPR. Dan setelah mendapat alokasi anggaran dari Kementerian melakukan penyiapan dokumen anggaran. Kabinet menetapkan Rencana Strategis anggaran secara top down, dan memasukkan mempertimbangkan pembiayaan-pembiayaan baru yang sifatnya prioritas dikaitkan dengan kebijakan yang ada. Setelah adanya usulan anggaran dari Kementerian/Lembaga, Kabinet menetapkan alokasi anggaran yang selanjutnya menjadi Anggaran Kementerian/Lembaga. Parlemen melakukan pembahasan anggaran dengan Kabinet dan Kementerian/Lembaga untuk memberi masukan terhadap penentuan alokasi anggaran. Dari gambar 4.2 dapat terlihat perbedaannya dengan sistem penganggaran di Indonesia adalah penetapan penganggaran di South Africa diawali dari kewenangan Kabinet dalam menentukan Rencana Strategis (Top Down), yang baru kemudian diikuti penyiapan proposal anggaran oleh Kementerian dan Lembaga secara Bottom Up. Pembahasan anggaran tidak dilakukan secara berulang-ulang, hanya sekali dilakukan dengan Parlemen pada pertengahan tahun. Sedangkan di Indonesia dimulai dari usulan program dan kegiatan dari Kementerian/Lembaga (Bottom Up), yang kemudian dari dasar usulan anggaran

20 95 Kementerian/Lembaga tersebut dilakukan pembahasan anggaran yang sudah dimulai dari awal tahun baik dengan Kementerian Keuangan, Bappenas, maupun DPR secara berulang-ulang Proses Penganggaran di Lembaga Administrasi Negara (LAN) Pada gambar 4.3 merupakan proses penyusunan anggaran di Lembaga Administrasi Negara (LAN). Pada prinsipnya proses penyusunan anggaran yang dilakukan sama dengan ANRI, yaitu melakukan koordinasi dengan Bappenas, Kementerian Keuangan dan DPR. LAN juga memberlakukan pembatasan waktu terhadap usulan anggaran di setiap pagu anggaran mengikuti penjadwalan yang ditentukan oleh Kementerian Keuangan. Tetapi karena LAN memiliki instansi vertikal di daerah sehingga dalam pelaksanaan penyusunan anggaran tidak hanya melakukan kompilasi data usulan anggaran di LAN Pusat, tetapi juga dengan Satuan Kerja Daerah. Sehingga proses usulan anggaran akan semakin kompleks baik dari segi penggabungan data, kewenangan jabatan, maupun mengkoordinasikan program dan kegiatan antar instansi baik pusat maupun daerah. Saat ini LAN juga masih menggunakan sistem yang diturunkan oleh Kementerian Keuangan yaitu RKA-K/L, dan memiliki banyak kendala dalam pelaksanaannya.

21 96 Gambar 4.3 Proses Penyusunan Anggaran di Lembaga Administrasi Negara (LAN) Untuk memberikan gambaran yang lebih jelas, disajikan perbandingan proses penganggaran di tabel 4.9 yang menerangkan perbedaan proses penganggaran di Morocco, South Africa dan Indonesia:

22 97 Tabel 4.9 Perbedaan Proses Penganggaran Marocco, South Africa dan Indonesia Morocco South Africa Indonesia Dimulai dari struktur tertinggi (top-down) Dimulai dari struktur tertinggi (top-down) Dimulai dari struktur tertinggi (top-down) dan struktur terendah (bottom-up) Proses 1 kali Proses 1 kali Proses penyusunan anggaran tiga kali interasi, yaitu dari pagu indikatif, pagu anggaran, dan alokasi anggaran Negosiasi anggaran dilakukan oleh Kementerian Keuangan, Perdana Menteri, dan Kementerian/Lembaga Negosiasi pembiayaan 3 (tiga) pihak antara Kabinet, Kementerian dan Parlemen. Negosiasi anggaran dilakukan oleh Kementerian Keuangan, Bappenas, dan Kementerian/Lembaga. 4.5 Rancangan Sistem Informasi Rencana Kerja Anggaran (SIRKA) The Task Tahapan dimulai dengan mendeskripsikan sistem dan prosedur yang diusulkan dalam model Sistem Informasi Rencana Anggaran ini Purpose Proses penyusunan anggaran merupakan proses yang cukup kompleks karena perlu adanya pengintegrasian data usulan anggaran antar unit kerja. Sistem Rencana Kerja Anggaran dibuat untuk mengolah data dan menyediakan informasi tentang rencana kerja anggaran bagi penggunanya. Dimana sistem ini ditujukan untuk digunakan dalam proses penyusunan anggaran di ANRI. Selanjutnya diperlukan sistem yang mampu mengintegrasikan seluruh data antar unit kerja. Selain itu, sistem harus mampu membantu dalam mengontrol usulan anggaran agar sesuai dengan target dan ketentuan anggaran yang berlaku,

23 98 memberikan informasi tentang jadwal anggaran, dan melancarkan komunikasi antar unit kerja untuk mendukung proses penganggaran, serta dapat membantu user yang berwenang dalam berkoordinasi, pengawasan, dan pengambilan keputusan yang akurat. Sistem ini diharapkan dapat menyajikan data dan informasi yang dibutuhkan untuk mendukung proses penyusunan anggaran internal ANRI maupun proses penganggaran di Indonesia System Definition Pada sistem informasi SIRKA yang diusulkan, adalah suatu sistem informasi yang dapat membantu user (penyusun dan pengendali anggaran) untuk dapat melaksanakan sistem dengan tools dan fasilitas yang dapat memberikan kemudahan di dalam mengakses data dan informasi mengenai pelaksanaan proses penyusunan anggaran. Adapun definisi sistem berdasarkan kriteria FACTOR : a. Functionality Sistem dibuat untuk pembuatan usulan anggaran (di tahun berjalan) menjadi efektif dan efisien, dengan kontrol secara otomatis baik target, ketentuan, dan time framenya. Sistem dapat menyediakan data dengan dengan standarisasi dan terintegrasi, sehingga informasi dapat diakses secara mudah, real time dan up to date. Informasi yang dihasilkan dapat menjadi dasar pertimbangan bagi user yang berwenang dalam melakukan koordinasi, pengawasan, dan pengambilan keputusan yang akurat.

24 99 b. Application Domain Pihak-pihak yang akan menggunakan sistem ini antara lain Biro Perencanaan, Unit Kerja, Pejabat Eselon II, dan Sekretaris Utama. Sistem akan memungkinkan pihak-pihak yang berwenang untuk berinteraksi dengan forum untuk mendukung pelaksanaan proses penyusunan anggaran. c. Condition Sistem dirancang untuk membantu dalam proses penyusunan anggaran, proses pembuatan dokumen anggaran, menyajikan informasi anggaran yang diharapkan dapat mengatasi masalah yang dihadapi instansi dalam proses penganggaran. Kondisi yang harus dipenuhi dalam pembuatan model sistem adalah dengan memperhatikan aspek-aspek yang berlaku dalam aturan penganggaran di Indonesia, maupun di internal instansi ANRI. d. Technology Sistem ini berbasis web sehingga dapat digunakan setiap saat dan dapat digunakan pada semua PC (Personal Computer) dan notebook yang terhubung dengan jaringan internet di seluruh Indonesia. Dapat digunakan di semua platform sistem operasi dengan menggunakan internet browser yang terhubung melalui LAN (Local Area Network), WLAN (Wireless Local Area Network), dan internet. e. Object Pada sistem ini yang menjadi objek adalah staf di berbagai unit kerja, staf dan pejabat di Biro Perencanaan, Pejabat Eselon II, Sekretaris Utama,

25 100 Program dan Pembiayaan, Referensi, Rencana Anggaran Biaya (RAB), Term of Reference (TOR), Pagu Indikatif, Pagu Anggaran, Pagu Alokasi Anggaran, Pelaksanaan Anggaran. f. Responsibility Tanggung jawab sistem secara keseluruhan yaitu sebagai alat administrasi yang dapat diandalkan dalam pencatatan usulan anggaran, dan penyediaan informasi yang mendukung proses penyusunan anggaran di internal instansi Context Context memberikan gambaran tentang sistem yang bertujuan untuk menyelesaikan permasalahan yang telah diuraikan pada Bab III. Pengaturan dan fasilitas yang terdapat pada Sistem Rencana Kerja Anggaran (SIRKA) diharapkan dapat menyelesaikan permasalahan pada proses penyusunan anggaran yang terkait dengan kecepatan dan kemudahan dalam melakukan suatu proses Problem Domain Pengiriman dokumen dilakukan pengaturan dengan menyimpan status dokumen pada suatu tabel basisdata tertentu. Dari isi tabel basisdata ini dapat diketahui status suatu dokumen, yaitu belum diproses, sedang diproses, sudah disahkan, atau sudah dikirimkan. Penyimpanan data pada tabel-tabel basis data didesain sehingga pengguna sistem dapat melacak suatu dokumen yang diperlukannya. Pelacakan ini dilakukan dengan melihat status beserta tanggal status tersebut.

26 101 Selain itu kebutuhan akan history anggaran pada tahun sebelumnya juga dipenuhi dengan menyimpan semua data beserta tanggalnya pada tabel-tabel basisdata. History anggaran tersebut selain dapat menjadi knowledge bagi penggunanya antara lain menjadi acuan dalam penyusunan anggaran di tahun berjalan, juga sebagai bahan pertimbangan pimpinan dalam menentukan kebijakan besaran alokasi anggaran unit kerja yang selanjutnya dapat dijadikan dasar dalam pemberian Reward dan Punishment terhadap unit kerja dalam kaitannya dengan proses pengelolaan anggaran Application Domain Model Sistem Informasi Rencana Anggaran yang diusulkan akan mendukung proses penyusunan anggaran yang dilakukan di instansi yang akan digunakan oleh Biro Perencanaan, unit kerja, para pejabat Eselon II, dan Sekretaris Utama. Tugas utama application domain ini adalah menjalankan prosedur-prosedur antara lain meng-create rencana anggaran, mengkaji dan merevisi draft usulan, meminta approval, mencetak usulan, dan menyusun dokumen pelaksanaan anggaran. Konsep perancangan Sistem Informasi Rencana Anggaran (SIRKA) yang diusulkan sebagai berikut :

27 Gambar 4.4 Sistem Informasi Rencana Kerja Anggaran yang diusulkan 102

28 103 Gambar 4.5 Sistem Informasi Rencana Kerja Anggaran yang diusulkan (lanjutan)

29 104 Pada gambar 4.4 dan 4.5, maka dapat dijabarkan Sistem Rencana Kerja Anggaran (SIRKA) yang diusulkan sebagai berikut: a. Setelah menerima Surat Edaran Pagu (Indikatif, Anggaran, Alokasi Anggaran) dari Menteri Keuangan, Biro Perencanaan login ke Sistem Rencana Kerja Anggaran (SIRKA). Kemudian menetapkan jadwal tahapan penyusunan anggaran dan mengalokasikan pagu untuk masing-masing program dan kegiatan. Notifikasi dikirimkan secara otomatis oleh sistem ke masing-masing unit kerja agar menyusun Draft Usulan Program dan Pembiayaan hingga batas waktu tertentu. b. Unit Kerja melakukan login ke Sistem Rencana Kerja Anggaran (SIRKA), untuk mulai menyusun Draft Usulan Program dan Pembiayaan. Sistem membatasi input Unit Kerja sehingga tidak dapat melebihi pagu. Setelah menyelesaikan Draft Rencana Kerja, Draft Rencana Kerja tersebut untuk sementara tidak bisa lagi di-update. Notifikasi dikirim secara otomatis oleh sistem ke Pejabat Eselon II untuk di-approve. c. Draft Rencana Kerja tersebut kemudian diperiksa dan di-approve oleh Pejabat Eselon II, dan notifikasi dikirim secara otomatis oleh sistem ke Biro Perencanaan untuk mengkaji dan Merevisi Draft Usulan Program dan Pembiayaan. d. Bila Biro Perencanaan telah selesai merevisi, notifikasi dikirim secara otomatis oleh sistem ke Sekretaris Utama untuk melakukan approval Draft Usulan Program dan Pembiayaan. e. Bila Sekretaris Utama telah meng-approve, notifikasi dikirim secara otomatis oleh sistem ke Biro Perencanaan untuk mencetak Draft Usulan

30 105 Program dan Pembiayaan dengan digital signature Sekretaris Utama untuk diserahkan ke Direktorat Jenderal Anggaran Kementerian Keuangan. Pada tabel 4.10 menjelaskan aturan pembuatan dokumen dalam sistem dalam rancangan sistem SIRKA. Sistem akan melakukan pemrosesan dokumendokumen terkait proses Rencana Kerja Anggaran, yaitu Dokumen Alokasi Anggaran, pembuatan Dokumen TOR dan RAB, kompilasi Dokumen RKA-K/L yang kemudian menghasilkan Dokumen Pelaksanaan Anggaran. Masing-masing dokumen dibuat oleh pihak-pihak tertentu mengikuti aturan yang ada dalam pembuatannya. Dokumen memerlukan pengesahan berdasarkan pengaturan wewenang yang berlaku. Setelah proses pengesahan dokumen dikirimkan kepada pihak yang memerlukannya untuk melanjutkan proses tertentu. Dokumen yang mengawali proses Rencana Kerja Anggaran di ANRI pada satu tahun anggaran tertentu adalah dokumen Alokasi Anggaran. Dokumen ini dibuat oleh Biro Perencanaan khususnya pada Sub Bagian Penyusunan Program yang sudah disesuaikan dengan usulan unit kerja yang sudah termuat dalam Rencana Strategis ANRI, Usulan alokasi anggaran tersebut dikirimkan kepada Kepala Bagian Program dan Anggaran, kemudian Kepala Biro Perencanaan, dan Sekretaris Utama. Kemudian dokumen tersebut disahkan oleh Sekretaris Utama. Setelah disahkan, dokumen alokasi anggaran tersebut dikirim kepada pengguna sistem yang lain untuk digunakan pada proses selanjutnya. Berdasarkan Dokumen Alokasi Anggaran, Kepala Bagian Program dan Anggaran menyampaikan kepada Kepala Biro Perencanaan, yang kemudian disampaikan kepada Kepala Biro Perencanaan, yang selanjutnya disampaikan

31 106 kepada Sekretaris Utama. Sekretaris Utama beserta jajaran eselon I dan II mengadakan pembahasan untuk menentukan apakah ada kebijakan perubahan pagu anggaran untuk masing-masing unit kerja per Eselon II yang didasari dari analisa kebutuhan kegiatan di tahun berjalan. Apabila ada terdapat perubahan maka akan dikembalikan kepada Subbagian Penyusunan Program untuk dilakukan perbaikan alokasi. Perbaikan alokasi tersebut dapat dilakukan sepanjang tidak merubah pagu baseline di tahun berjalan yang telah ditetapkan oleh Bappenas. Dan setelah dilakukan perubahan alokasi anggaran unit kerja dikembalikan kembali kepada Sekretaris Utama untuk diberikan pengesahan. Dokumen alokasi anggaran tersebut dapat dikirimkan kepada Kepala ANRI untuk diketahui. Setelah disahkan, alokasi anggaran tersebut dapat didistribusikan kepada pimpinan para pejabat Eselon II untuk kemudian didistribusikan kepada penyusun anggaran di unit kerjanya untuk dilakukan proses tahapan selanjutnya.

32 107 Tabel 4.10 Aturan Pembuatan Dokumen DOKUMEN ATURAN Alokasi Anggaran - dibuat oleh Subbagian Penyusunan Program - berdasarkan Rencana Strategis ANRI - disesuaikan dengan usulan dari unit kerja - pertimbangan persetujuan usulan dari unit kerja didasarkan pada pencapaian realisasi tahun anggaran sebelumnya - dimungkinkan adanya perubahan alokasi anggaran dengan otorisasi - disahkan oleh Sekretaris Utama - dikirimkan kepada Kepala ANRI untuk diketahui Term of Reference (TOR) - dibuat oleh masing-masing unit kerja - dikompilasi di tingkat Eselon II - disesuaikan dengan Rencana Anggaran Biaya (RAB) kegiatan yang diusulkan - berisi penjabaran tahapan Program, Kegiatan, Output, Suboutput, Komponen, dan Subkomponen - disahkan oleh masing-masing pejabat Eselon II unit kerja - dimungkinkan adanya perubahan alokasi anggaran dengan otorisasi RAB (Rencana Anggaran Biaya) - dibuat oleh masing-masing unit kerja - dibuat dalam format RKAKL - berisi detil belanja yang dipilah berdasarkan mata anggaran - dilakukan pengecekan setiap butir usulan - tahapannya disesuaikan dengan KAK - besaran angka pagu kegiatan per unit kerja Eselon II diblok sesuai dengan dokumen alokasi anggaran - untuk data anggaran yang bersifat operasional/mengikat dapat dilakukan pengecekan terhadap data dari sistem lain - penentuan besaran biaya disesuaikan dengan aturan Standar Biaya Umum (SBU), Standar Biaya Keluaran (SBK), dan Harga Perkiraan Sendiri (HPS) - disahkan oleh masing-masing pejabat Eselon II unit kerja - dimungkinkan adanya perubahan alokasi anggaran dengan otorisasi Dokumen RKA-K/L (Rencana Kerja Anggaran Kementerian/Lembaga) - disusun oleh Subbagian Penyusunan Anggaran disusun setelah menerima Surat Edaran Kementerian Keuangan - disesuaikan dengan pagu anggaran yang tercantum pada Surat Edaran Kementerian Keuangan - merupakan kompilasi Rencana Anggaran Biaya (RAB) unit kerja - dilakukan penelaahan kesesuaian dengan aturan dan kebijakan - disahkan oleh Sekretaris Utama - dokumen yang sudah dilakukan pembahasan dengan Kementerian Keuangan dan Bapenas, dan sudah disahkan dapat dikirim kepada pengguna anggaran - dikirimkan kepada Kepala ANRI untuk diketahui Dokumen Pelaksanaan Anggaran (POK) - dibuat oleh Subbagian Penyusunan Anggaran - disahkan oleh Sekretaris Utama - dokumen yang sudah disahkan dapat dikirim ke penggguna anggaran - dikirimkan kepada Kepala ANRI untuk diketahui

33 Problem Domain Problem domain Model Sistem Informasi Rencana Anggaran dianalisis dalam structure dan classes Clusters Kami tidak membagi model ini ke dalam cluster Structure Gambar 4.6 Class Diagram dari Class Program Sistem Informasi Rencana Kerja Anggaran Pada gambar 4.6, struktur ini menggambarkan bahwa setiap program memiliki minimal satu hingga banyak kegiatan dan minimal satu hingga banyak

34 109 indikator_kinerja_utama. Masing-masing kegiatan memiliki minimal satu hingga banyak output dan minimal satu hingga banyak indikator_kinerja_kegiatan. Sedangkan untuk setiap output dapat tidak memiliki hingga banyak subouput Classes Terdapat 26 (dua puluh enam) classes yang dipergunakan, yaitu: program: merupakan instrumen kebijakan yang berisi kegiatankegiatan yang dilaksanakan oleh lembaga untuk mencapai sasaran dan tujuan serta memperoleh alokasi anggaran, dan/atau kegiatan instansi yang dikoordinasikan oleh kementerian/lembaga. Tabel 4.11 Keterangan Behavioral Pattern dari Class program Event Attributes create name update name delete indikator_kinerja_utama: merupakan alat ukur hasil yang terkait dengan pencapaian kinerja/keberhasilan program. Tabel 4.12 Keterangan Behavioral Pattern dari Class indikator_kinerja_utama Event Attributes create program name update program name delete

35 110 kegiatan: proses menggunakan sumber daya untuk menghasilkan output yang ingin dicapai program. Tabel 4.13 Keterangan Behavioral Pattern dari Class kegiatan Event Attributes create program name update program name delete indikator_kinerja_kegiatan: merupakan alat ukur keberhasilan kegiatan yang terkait dengan pencapaian kinerja kegiatan dalam rangka mencapai kinerja hasil (outcome) dari program. Tabel 4.14 Keterangan Behavioral Pattern dari Class indikator_kinerja_kegiatan Event Attributes create kegiatan name update kegiatan name delete output: merupakan barang atau jasa yang dihasilkan oleh kegiatankegiatan yang dilaksanakan untuk mendukung pencapaian kinerja hasil, yang secara akuntabilitas berkaitan dengan unit organisasi setingkat Eselon II.

36 111 Tabel 4.15 Event create update delete Keterangan Behavioral Pattern dari Class output Attributes kegiatan kodeib lokasi kewenangan volume tahun_anggaran_awal tahun_anggaran_akhir Volume kpjm tema kegiatan kodeib lokasi kewenangan volume tahun_anggaran_awal tahun_anggaran_akhir Volume kpjm tema suboutput: merupakan sub keluaran berupa barang atau jasa untuk mendukung pencapaian output kegiatan. Tabel 4.16 Event create update delete Keterangan Behavioral Pattern dari Class suboutput Attributes output uraian volume output uraian volume

37 112 komponen: merupakan tahapan dari proses pencapaian output atau pada suboutput, yang berupa paket-paket pekerjaan. Tabel 4.17 Event create update delete Keterangan Behavioral Pattern dari Class komponen Attributes suboutput uraian jenis_biaya sifat_biaya dikalikan_kpjm dikalikan_output tahun_mulai tahun_selesai suboutput uraian jenis_biaya sifat_biaya dikalikan_kpjm dikalikan_output tahun_mulai tahun_selesai subkomponen: merupakan kelompok-kelompok detil belanja, yang disusun dalam rangka memudahkan dalam pelaksanaan komponen. Tabel 4.18 Event create update delete Keterangan Behavioral Pattern dari Class subkomponen Attributes komponen uraian komponen uraian

38 113 akun_belanja: merupakan item-item belanja. Tabel 4.19 Event create update delete Keterangan Behavioral Pattern dari Class akun_belanja Attributes sub komponen akun kppn beban sub komponen akun kppn beban detil_belanja: merupakan rincian kebutuhan belanja dalam tiap-tiap akun_belanja. Tabel 4.20 Keterangan Behavioral Pattern dari Class detil_belanja Event Attributes create akun_belanja dokumen standar_harga uraian volume satuan harga_satuan update akun_belanja dokumen standar_harga uraian volume satuan harga_satuan delete

39 114 dokumen: merupakan berkas-berkas yang digunakan dalam penyusunan anggaran. Tabel 4.21 Keterangan Behavioral Pattern dari Class dokumen Event Attributes create tahun_anggaran web_account jenis_dokumen status tanggal_mulai tanggal_selesai update tahun_anggaran web_account jenis_dokumen status tanggal_mulai tanggal_selesai delete reminder tahun_anggaran web_account jenis_dokumen status tanggal_mulai tanggal_selesai change_status print tahun_anggaran web_account jenis_dokumen status tanggal_mulai tanggal_selesai standar_harga: merupakan alat untuk penyusunan anggaran yang tidak bersifat penetapan pada suatu jumlah tertentu tanpa ada kemungkinan perubahan (naik/turun) yang disebabkan perubahan parameter yang dijadikan acuan.

40 115 Tabel 4.22 Keterangan Behavioral Pattern dari Class standar_harga Event Attributes create uraian harga_tertinggi update uraian harga_tertinggi delete jenis_dokumen: merupakan tipe dokumen seperti Rencana Anggaran Biaya, Term Of Reference, Petunjuk Operasional Kegiatan, dan lainlain. Tabel 4.23 Event create update delete Keterangan Behavioral Pattern dari Class jenis_dokumen Attributes tahun_anggaran web_account jenis_dokumen status tanggal_mulai tanggal_selesai tahun_anggaran web_account jenis_dokumen status tanggal_mulai tanggal_selesai

41 116 tahun_anggaran: merupakan tahun dimana program akan dilaksanakan. Tabel 4.24 Event create update delete Keterangan Behavioral Pattern dari Class tahun_anggaran Attributes tahun status tahun status pegawai: merupakan data pegawai Tabel 4.25 Event create update delete Keterangan Behavioral Pattern dari Class pegawai Attributes nip ktp golongan jabatan nama dob pob gender tahun_masuk status_kawin alamat telp nip ktp golongan jabatan nama dob pob gender tahun_masuk status_kawin alamat telp

42 117 golongan: berisi golongan pegawai Tabel 4.26 Event create update delete Keterangan Behavioral Pattern dari Class golongan Attributes uraian tahun jabatan: berisi jabatan pegawai Tabel 4.27 Event create update delete Keterangan Behavioral Pattern dari Class jabatan Attributes uraian tahun tiket: merupakan media pengguna untuk mengajukan pertanyaan atau permintaan. Tabel 4.28 Event create update delete Keterangan Behavioral Pattern dari Class tiket Attributes topik uraian tanggal status topik uraian tanggal status

43 118 tiket_log: merupakan detil komunikasi untuk masing-masing tiket. Tabel 4.29 Event create update delete Keterangan Behavioral Pattern dari Class tiket_log Attributes tiket web_account pesan tanggal tiket web_account pesan tanggal thread: merupakan topik dalam forum. Tabel 4.30 Event create update delete Keterangan Behavioral Pattern dari Class thread Attributes web_account tanggal judul deskripsi web_account tanggal judul deskripsi

44 119 thread_comment: merupakan pesan dari user dalam menanggapi suatu topik dalam forum. Tabel 4.31 Event create update delete Keterangan Behavioral Pattern dari Class thread_comment Attributes thread web_account comment tanggal thread web_account comment tanggal web_account: berisi username, password masing-masing pegawai untuk mengakses sistem. Tabel 4.32 Event create update delete log_activity Keterangan Behavioral Pattern dari Class web_account Attributes login password web_group pegawai login password web_group pegawai

45 120 web_group: merupakan daftar pembagian peran (role) pengguna. Tabel 4.33 Event create update delete Keterangan Behavioral Pattern dari Class web_group Attributes uraian uraian group_access: merupakan pembagian hak akses masing-masing peran (role) terhadap sistem. Tabel 4.34 Keterangan Behavioral Pattern dari Class group_access Event Attributes create web_group access_list crud update web_group access_list crud delete access_list: merupakan pengaturan modul dalam sistem. Tabel 4.35 Keterangan Behavioral Pattern dari Class access_list Event Attributes create group_list parent module order jscript_css update group_list parent module order jscript_css delete

46 121 log_activity: merupakan daftar catatan aktifitas pengguna selama menggunakan sistem. Memungkinkan sistem untuk dapat kembali ke kondisi sebelum terjadi suatu kesalahan dan menunjukan siapa yang melakukan kesalahan tersebut. Tabel 4.36 Event create rollback Keterangan Behavioral Pattern dari Class log_activity Attributes web_account activity date web_account activity date Application Domain Usage Usage menggambarkan interaksi sistem dalam lingkungannya dalam proses Penyusunan Anggaran Actors Adapun sistem ini digunakan oleh Biro Perencanaan, Unit Kerja, Pejabat Eselon II, dan Sekretaris Utama ANRI secara terintegrasi. Pusat data berada di Biro Perencanaan, serta yang dilibatkan sebagai user di unit kerja adalah para pejabat dan staf yang difungsikan sebagai penyusun anggaran.

47 Use Cases Merupakan diagram yang menggambarkan hubungan antara user dengan use case pada sistem. Masing-masing dilaksanakan dengan hak akses yang berbeda-beda terhadap sistem. Use case diagram sistem ini digambarkan sebagai berikut: Gambar 4.7 Use Case Diagram

48 123 Masing-masing pengguna dikelompokkan dalam peran dan hak akses tertentu terhadap sistem. Terbagi menjadi 5 (empat) jenis interaksi yang digambarkan dalam Use Case Diagram untuk Unit Kerja, Use Case Diagram untuk Biro Perencanaan, Use Case Diagram untuk Pejabat Eselon II, Use Case Diagram untuk Sekretaris Utama, dan Use Case Diagram untuk aplikasi RKAKL sebagai berikut: a. Use Case Diagram untuk Biro Perencanaan Gambar 4.8 Use Case Diagram untuk Biro Perencanaan

49 124 Tabel 4.37 Use Case Specification Restore Data RKAKL Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk me-restore data RKAKL Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.38 Use Case Specification Mengkaji dan Merevisi Draft Usulan Program dan Pembiayaan Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk mengkaji dan merevisi Draft Usulan Program dan Pembiayaan Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.39 Use Case Specification Menerima dan Mengalokasikan Pagu Indikatif Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk mengalokasikan Pagu Indikatif Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.40 Use Case Specification Mengkaji dan Merevisi Draft TOR dan RAB Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk mengkaji Draft TOR dan RAB Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen.

50 125 Tabel 4.41 Use Case Specification Menerima dan Mengalokasikan Pagu Sementara Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk mengalokasikan Pagu Sementara Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.42 Use Case Specification Mengkaji dan Merevisi Pagu Sementara Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk mengkaji Draft Pagu Sementara Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.43 Use Case Specification Menerima dan Mengalokasikan Pagu Definitif Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk mengalokasikan Pagu Definitif Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.44 Use Case Specification Meng-upload dan Melihat Referensi Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk meng-upload dan melihat referensi Objects web_account, tiket, tiket_log, log_activity, jenis_dokumen, dokumen Tabel 4.45 Use Case Specification Interaksi dengan Tiket Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk berinteraksi melalui tiket Objects web_account, tiket, tiket_log, log_activity

51 126 Tabel 4.46 Use Case Specification Interaksi dengan Forum Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk berinteraksi melalui forum Objects web_account, tiket, tiket_log, log_activity Tabel 4.47 Use Case Specification Back-up Data Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk back-up data Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. b. Use Case Diagram untuk Unit Kerja Gambar 4.9 Use Case Diagram untuk Unit Kerja

52 127 Tabel 4.48 Use Case Specification Menyusun Draft Usulan Program dan Pembiayaan Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk menyusun Draft Usulan Program dan Pembiayaan Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.49 Use Case Specification Menyusun Draft TOR dan RAB Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk menyusun Draft TOR dan RAB Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.50 Use Case Specification Menyusun Draft RKAKL Pagu Sementara Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk menyusun Draft RKAKL Pagu Sementara Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.51 Use Case Specification Menyusun Draft RKAKL Pagu Definitif Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk menyusun Draft RKAKL Pagu Definitif Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen.

53 128 Tabel 4.52 Use Case Specification Meng-upload dan Melihat Referensi untuk Unit Kerja Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk meng-upload dan melihat referensi Objects web_account, tiket, tiket_log, log_activity, jenis_dokumen, dokumen Tabel 4.53 Use Case Specification Interaksi dengan Tiket Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk berinteraksi melalui tiket Objects web_account, tiket, tiket_log, log_activity Tabel 4.54 Use Case Specification Interaksi dengan Forum Use Case Use Case ini menggambarkan bagaimana Unit Kerja menggunakan sistem untuk berinteraksi melalui forum Objects web_account, tiket, tiket_log, log_activity c. Use Case Diagram untuk Pejabat Eselon II Gambar 4.10 Use Case Diagram untuk Pejabat Eselon II Tabel 4.55 Use Case Specification Meng-upload dan Melihat Referensi untuk Pejabat Eselon II Use Case Use Case ini menggambarkan bagaimana Pejabat Eselon II menggunakan sistem untuk meng-upload dan melihat referensi Objects web_account, tiket, tiket_log, log_activity, jenis_dokumen, dokumen

54 129 Tabel 4.56 Use Case Specification Meng-approve Dokumen Use Case Use Case ini menggambarkan bagaimana Pejabat Eselon II menggunakan sistem untuk meng-approve dokumen Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. d. Use Case Diagram untuk Sekretaris Utama Sekretaris Utama Gambar 4.11 Use Case Diagram untuk Sekretaris Utama Tabel 4.57 Use Case Specification Meng-upload dan Melihat Referensi untuk Sekretaris Utama Use Case Use Case ini menggambarkan bagaimana Sekretaris Utama menggunakan sistem untuk meng-upload dan melihat referensi Objects web_account, tiket, tiket_log, log_activity, jenis_dokumen, dokumen Tabel 4.58 Use Case Specification Meng-approve Dokumen Use Case Use Case ini menggambarkan bagaimana Sekretaris Utama menggunakan sistem untuk meng-approve dokumen Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen.

55 130 e. Use Case Diagram untuk Aplikasi RKAKL Gambar 4.12 Use Case Diagram untuk aplikasi RKAKL Tabel 4.59 Use Case Specification Restore Data RKAKL Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk me-restore data RKAKL Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen. Tabel 4.60 Use Case Specification Back-up Data Use Case Use Case ini menggambarkan bagaimana Biro Perencanaan menggunakan sistem untuk back-up data Objects tahun_anggaran, dokumen, detil_belanja, standar_harga, akun_belanja, subkomponen, komponen, suboutput, output, kegiatan, program, indikator_kinerja_utama, indikator_kinerja_kegiatan, jenis_dokumen Function List Complete function list dari Sistem Informasi Rencana Kerja Anggaran (SIRKA) dapat digambarkan sebagai berikut:

56 131 Tabel 4.61 Tabel Function List dari Sistem SIRKA Function Complexity Type Mengkaji dan Merevisi Draft Usulan Program simple read, update dan Pembiayaan get_access simple read, update view simple read create simple update update simple update delete simple update Menyusun Draft Usulan Program dan complex read, update Pembiayaan get_access simple read, update view simple read create simple update update simple update delete simple update Menerima dan Mengalokasikan Pagu Indikatif simple read, update get_access simple read, update view simple read create simple update update simple update delete simple update Menyusun Draft TOR dan RAB complex read, update get_access simple read, update view simple read create complex update update complex update delete complex update Mengkaji dan Merevisi Draft TOR dan RAB simple read, update get_access simple read, update view simple read create simple update update simple update delete simple update Menyusun Draft RKAKL Pagu Sementara complex read, update get_access simple read, update view simple read create complex update update complex update delete complex update Menerima dan Mengalokasikan Pagu simple read, update Sementara get_access simple read, update view simple read create simple update update simple update delete simple update

57 132 Interaksi dengan Forum simple read, update get_access simple read, update view simple read create simple update update simple update delete simple update Interaksi dengan Tiket simple read, update get_access simple read, update view simple read create simple update update simple update delete simple update Menyusun Draft RKAKL Pagu Definitif complex read, update get_access simple read, update view simple read create complex update update complex update delete complex update Mengkaji dan Merevisi Draft RKAKL Pagu simple read, update Definitf get_access simple read, update view simple read create simple update update simple update delete simple update Menerima dan Mengalokasikan Pagu definitif simple read, update get_access simple read, update view simple read create simple update update simple update delete simple update Meng-upload dan Melihat Referensi simple read, update get_access simple read, update view simple read create simple update update simple update delete simple update Meng-approve Dokumen simple read, update get_access simple read, update view simple read create simple update update simple update delete simple update

58 Sequence Diagram Sequence Diagram merupakan bagian dari konsep rancangan sistem dengan menggunakan tools UML yang menggambarkan interaksi antara pengguna dengan sistem dalam rangkaian event. Pada sistem ini digambarkan dalam 4 (empat) proses yaitu pada Biro Perencanaan, Unit Kerja, Pejabat Eselon II, dan Sekretaris Utama. Sequence Diagram pada sistem SIRKA dapat dilihat pada gambar-gambar di bawah ini : Gambar 4.13 Sequence Diagram untuk Biro Perencanaan

59 134 Gambar 4.14 Sequence Diagram untuk Unit Kerja Gambar 4.15 Sequence Diagram untuk Pejabat Eselon II Gambar 4.16 Sequence Diagram untuk Sekretaris Utama

60 Activity Diagram Merupakan bagian dari konsep rancangan sistem dengan menggunakan tools UML yang menggambarkan aliran data antar event. Gambar 4.17 Activity Diagram

61 136 Dalam activity diagram pada gambar 4.17 digambarkan bahwa proses dimulai saat Biro Perencanaan menerima Surat Edaran Pagu Indikatif dari Menteri Keuangan. Selanjutnya Biro Perencanaan login ke Sistem Rencana Kerja Anggaran (SIRKA). Kemudian menetapkan jadwal tahapan penyusunan anggaran dan mengalokasikan pagu untuk masing-masing program dan kegiatan. Notifikasi dikirimkan secara otomatis oleh sistem ke masing-masing unit kerja agar menyusun Draft Usulan Program dan Pembiayaan hingga batas waktu tertentu. Proses dalam Unit Kerja dimulai dengan melakukan login ke Sistem Rencana Kerja Anggaran (SIRKA), untuk mulai menyusun Draft Usulan Program dan Pembiayaan. Sistem membatasi input Unit Kerja sehingga tidak dapat melebihi pagu. Setelah menyelesaikan Draft Rencana Kerja, Draft Rencana Kerja tersebut untuk sementara tidak bisa lagi di-update. notifikasi dikirim secara otomatis oleh sistem ke Pejabat Eselon II untuk di-approve. Draft Rencana Kerja tersebut kemudian diperiksa dan di-approve oleh Pejabat Eselon II, dan notifikasi dikirim secara otomatis oleh sistem ke Biro Perencanaan untuk mengkaji dan Merevisi Draft Usulan Program dan Pembiayaan. Bila Biro Perencanaan telah selesai merevisi, notifikasi dikirim secara otomatis oleh sistem ke Sekretaris Utama untuk melakukan approval Draft Usulan Program dan Pembiayaan. Bila Sekretaris Utama telah meng-approve, notifikasi dikirim secara otomatis oleh sistem ke Biro Perencanaan untuk mencetak Draft Usulan Program dan Pembiayaan dengan digital signature Sekretaris Utama untuk diserahkan ke Direktorat Jenderal Anggaran Kementerian Keuangan.

62 User Interface Halaman Login Gambar 4.18 Halaman Login Untuk mengakses SIRKA, user harus melakukan login terlebih dahulu. Berdasarkan penggolongan user group/role, hak dan batasan akses terhadap masing-masing modul diterapkan. Halaman Home Gambar 4.19 Halaman Home Setelah melakukan login, user akan melihat hanya menu modul yang diberikan hak aksesnya, dapat mengganti bahasa, dan link ke halaman informasi account-nya.

63 138 Halaman Update Account Gambar 4.20 Halaman Update Account Pada halaman ini, user dapat mengganti password. Untuk menjaga keamanan, user disarankan untuk mengganti password sebulan sekali. Halaman Karyawan Gambar 4.21 Halaman Karyawan Pada halaman ini, user dapat melihat daftar karyawan ANRI. Di bagian atas terdapat filter huruf pertama nama karyawan, filter role user,

64 139 dan tombol untuk menambah data karyawan baru. Di bagian header tabel, tulisan yang bergaris bawah dapat di-klik untuk mengurutkan data berdasarkan abjad pada kolom tersebut. Pada setiap baris, tulisan nama yang bergaris bawah dapat di-klik untuk melihat detil informasi karyawan. Di kolom action terdapat tombol untuk meng-upload foto profil karyawan dan tombol untuk mengubah data karyawan. Halaman Kelompok Pengguna Gambar 4.22 Halaman Kelompok Pengguna Pada halaman ini, pengelompokan user dikelola. Masing-masing kelompok user tersebut akan diatur hak aksesnya terhadap masing-masing modul.

65 140 Halaman Pengaturan User Gambar 4.23 Halaman Pengaturan User Pada halaman ini, pengelompokan user dikelola. Masing-masing kelompok user tersebut akan diatur hak aksesnya terhadap masing-masing modul. Halaman Pengaturan Modul Gambar 4.24 Halaman Pengaturan Modul Pada halaman ini, pengaturan modul dilakukan. Di bagian kiri terdapat navigasi berbentuk hirarki, sehingga dapat dilakukan drill-down untuk masing-masing kelompok modul. Di bagian kanan terdapat tombol untuk menambah dan mengubah modul.

66 141 Halaman Referensi Dokumen Gambar 4.25 Halaman Referensi Dokumen Pada halaman ini, user dapat meng-upload dan men-download dokumen yang dibutuhkan dalam penyusunan anggaran. Terdapat filter judul dokumen untuk memudahkan pencarian. Halaman Hak Akses Gambar 4.26 Halaman Hak Akses Pada halaman ini, pengaturan hak akses setiap kelompok user terhadap masing-masing modul dilakukan. User dapat dibatasi apakah dapat melihat, menambah, mengubah, atau menghapus data dengan mengklik di tabel sebelah kanan.

67 142 Halaman Penjadwalan Gambar 4.27 Halaman Penjadwalan Pada halaman ini, user dapat menginput penjadwalan setiap proses penyusunan anggaran. Sistem akan men-generate dan mengirim otomatis kepada user untuk mengingatkan bahwa proses penyusunan telah dimulai dan akan berakhir pada tanggal yang telah ditentukan. Halaman Alokasi Anggaran Gambar 4.28 Halaman Alokasi Anggaran Pada halaman ini, user dapat menginput alokasi anggaran. Terdapat filter tahun anggaran dan tahapan penyusunan anggaran untuk memudahkan pencarian data. Alokasi anggaran ini akan membatasi input pada modul Rencana Anggaran Biaya agar tidak melebihi batas pagu yang telah dialokasikan.

68 143 Halaman Program dan Kegiatan Gambar 4.29 Halaman Program dan Kegiatan Pada halaman ini, user dapat menginput program dan kegiatan. Halaman Output dan Sub Output Gambar 4.30 Halaman Output dan Suboutput Pada halaman ini, user dapat menginput output dan sub output.

69 144 Halaman Komponen dan Sub Komponen Komponen. Gambar 4.31 Halaman Komponen dan Sub Komponen Pada halaman ini, user dapat menginput Komponen dan Sub Halaman Rencana Anggaran Biaya Gambar 4.32 Halaman Rencana Anggaran Biaya Pada halaman ini, user dapat menginput detil belanja dalam menyusun rencana anggaran biaya. Terdapat filter kode program/kegiatan, uraian akun belanja, tahun anggaran, dan proses penyusunan pagu untuk memudahkan pencarian data. Standar biaya dan alokasi anggaran akan membatasi input pada modul ini agar tidak melebihi batas yang telah ditentukan.

70 145 Halaman Standar Biaya Gambar 4.33 Halaman Standar Biaya Pada halaman ini, user dapat menginput standar biaya. Terdapat filter biaya dan satuan untuk memudahkan pencarian data. Standar biaya ini akan membatasi input pada modul Rencana Anggaran Biaya agar tidak melebihi batas standar biaya yang telah ditentukan. Halaman Tiket Gambar 4.34 Halaman Tiket Pada halaman ini, unit kerja dapat mengajukan pertanyaan atau permintaan kepada Biro Perencanaan. Setiap kasus mendapat tiket antrian yang akan ditindak lanjuti perkembangannya hingga terjadi penyelesaian.

71 146 Halaman Forum Gambar 4.35 Halaman Forum Pada halaman ini, setiap user dapat berbagi pengetahuan, masalah, dan pendapat yang berhubungan dengan proses penyusunan anggaran. Halaman Approval Gambar 4.36 Halaman Approval Pada halaman ini, pejabat Eselon II dan Sekretaris Utama dapat melihat, mencetak dan meng-approve detil belanja. Tombol Approve hanya akan muncul pada status tertentu.

72 147 Halaman Restore Data RKAKL Gambar 4.37 Halaman Restore Data RKAKL Pada halaman ini, user dapat me-restore data RKAKL ke sistem. Halaman Back-up Data RKAKL. Gambar 4.38 Halaman Back-up Data Pada halaman ini, user dapat memback-up data ke format foxpro Technical Platform Sistem SIRKA adalah aplikasi web-based, yang dapat berjalan di semua platform sistem operasi dengan menggunakan internet browser seperti Internet Explorer, Firefox, Chrome, Safari, dan Opera. Adapun teknologi yang digunakan

73 148 dalam Model Sistem Informasi Rencana Kerja Anggaran (SIRKA) ini adalah sebagai berikut: Web server: apache Mail server: Mercury Server script: PHP Client script: javascript, HTML, dan CSS Database: mysql Internet Network Gambar 4.39 Topologi Jaringan SIRKA Dapat dilihat pada gambar di atas, setiap workstation (PC) dan notebook dapat mengakses SIRKA dengan adanya jaringan LAN, WLAN, dan internet. Dengan adanya akses internet, SIRKA dapat diakses oleh unit kerja di pusat dan daerah seluruh Indonesia.

74 Deployment Diagram Arsitektur proses SIRKA menggunakan pola distribusi centralizes pattern, pada setiap client terdapat komponen user interface, function, model, dan printer. Sedangkan pada server terdapat system interface dan komponen model. Agar lebih jelas, berikut gambar deployment diagram: Gambar 4.40 Deployment Diagram Revised Class Diagram Hasil analisis class diagram pada analysis document direvisi menjadi revised class diagram sebagai berikut:

75 150 Gambar 4.41 Revised Class Diagram Table Specification Database Management System yang digunakan adalah MySQL dengan rincian tabel sebagai berikut: Tabel 4.62 Table Specification program Table program Primary Key Foreign Key - Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key name varchar 255 Not Null No Nama program

76 151 Tabel 4.63 Table Specification indikator_kinerja_utama Table web_account Primary Key Foreign Key program Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key program integer 10 Not Null No Foreign Key name varchar 255 Not Null No Nama indikator Tabel 4.64 Table Specification kegiatan Table kegiatan Primary Key Foreign Key program Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key program integer 10 Not Null No Foreign Key name varchar 255 Not Null No Nama kegiatan Tabel 4.65 Table Specification indikator_kinerja_kegiatan Table indicator_kinerja_kegiatan Primary Key Foreign Key kegiatan Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key kegiatan integer 10 Not Null No Foreign Key name varchar 255 Not Null No Nama indikator Tabel 4.66 Table Specification output Table output Primary Key Foreign Key kegiatan Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key kegiatan integer 10 Not Null No Foreign Key lokasi varchar 255 Not Null No Lokasi kewenangan varchar 255 Not Null No Kewenangan volume integer 10 Not Null No Volume tahun_anggaran_awal integer 4 Not Null No Tahun anggaran awal tahun_anggaran_akhir integer 4 Not Null No Tahun anggaran akhir volume kpjm integer 10 Not Null No Volume kpjm

77 152 Tabel 4.67 Table Specification suboutput Table suboutput Primary Key Foreign Key output Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key output integer 10 Not Null No Foreign Key uraian varchar 255 Not Null No Lokasi volume integer 10 Not Null No Volume Tabel 4.68 Table Specification komponen Table komponen Primary Key Foreign Key suboutput Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key suboutput integer 10 Not Null No Foreign Key uraian varchar 255 Not Null No Uraian jenis_biaya varchar 255 Not Null No Jenis Biaya sifat_biaya varchar 255 Not Null No Sifat Biaya dikalikan_ kpjm integer 10 Not Null No Dikalikan kpjm dikalikan_output integer 10 Not Null No Dikalikan output tahun_mulai integer 4 Not Null No Tahun anggaran awal tahun_selesai integer 4 Not Null No Tahun anggaran akhir Tabel 4.69 Table Specification subkomponen Table subkomponen Primary Key Foreign Key komponen Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key komponen integer 10 Not Null No Foreign Key uraian varchar 255 Not Null No Uraian Tabel 4.70 Table Specification akun_belanja Table akun_belanja Primary Key Foreign Key subkomponen Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key subkomponen integer 10 Not Null No Foreign Key akun integer 10 Not Null No Foreign Key kppn varchar 255 Not Null No kppn beban integer 10 Not Null No beban

78 153 Tabel 4.71 Table Specification detil_belanja Table detil_belanja Primary Key Foreign Key akun_belanja Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key akun_belanja integer 10 Not Null No Foreign Key dokumen integer 10 Not Null No Foreign Key standar_harga integer 10 Not Null No Foreign Key uraian varchar 255 Not Null No Uraian volume integer 10 Not Null No Volume satuan varchar 255 Not Null No Satuan harga_satuan integer 10 Not Null No Harga Satuan Tabel 4.72 Table Specification standar_harga Table standar_harga Primary Key Foreign Key - Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key uraian varchar 255 Not Null No Uraian harga_tertinggi integer 10 Not Null No Harga tertinggi Tabel 4.73 Table Specification dokumen Table dokumen Primary Key Foreign Key tahun_anggaran, web_account, jenis_dokumen Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key tahun_anggaran integer 10 Not Null No Foreign Key web_account integer 10 Not Null No Foreign Key jenis_dokumen integer 10 Not Null No Foreign Key status varchar 255 Not Null No Status url varchar 255 Not Null No url tanggal_mulai date Not Null No Tanggal Mulai tanggal_mulai date Not Null No Tanggal Selesai Tabel 4.74 Table Specification tahun_anggaran Table tahun_anggaran Primary Key Foreign Key - Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key tahun integer 4 Not Null No Tahun status varchar 255 Not Null No Status

79 154 Tabel 4.75 Table Specification jenis_dokumen Table jenis_dokumen Primary Key Foreign Key - Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key uraian varchar 255 Not Null No Uraian Tabel 4.76 Table Specification web_account Table web_account Primary Key Foreign Key web_group, pegawai Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key login varchar 255 Not Null No User name password varchar 255 Not Null No Kata Kunci web_group integer 10 Not Null No Foreign Key pegawai integer 10 Not Null No Foreign Key Tabel 4.77 Table Specification tiket_log Table tiket_log Primary Key Foreign Key web_account, tiket Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key tiket integer 10 Not Null No Foreign Key web_account integer 10 Not Null No Foreign Key pesan text Pesan tanggal date Tanggal pencatatan Tabel 4.78 Table Specification tiket Table tiket Primary Key Foreign Key web_account Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key web_account integer 10 Not Null No Foreign Key topik varchar 255 Not Null No Topik uraian text Uraian tanggal date Tanggal tiket status varchar 255 Not Null No Status

80 155 Tabel 4.79 Table Specification thread Table thread Primary Key Foreign Key web_account Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key web_account integer 10 Not Null No Foreign Key tanggal date Tanggal thread dibuat judul text Uraian deskripsi varchar 255 Not Null No Deskripsi Tabel 4.80 Table Specification thread_comment Table thread_comment Primary Key Foreign Key threaded, web_account Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key thread integer 10 Not Null No Foreign Key web_account integer 10 Not Null No Foreign Key comment text Komentar tanggal date Tanggal thread dibuat Tabel 4.81 Table Specification log_activity Table log_activity Primary Key Foreign Key web_account Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key web_account integer 10 Not Null No Foreign Key activity text Komentar date date Tanggal aktifitas Tabel 4.82 Table Specification jabatan Table jabatan Primary Key Foreign Key - Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key uraian varchar 255 Not Null No Uraian

81 156 Tabel 4.83 Table Specification golongan Table golongan Primary Key Foreign Key - Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key uraian varchar 255 Not Null No Uraian Tabel 4.84 Table Specification pegawai Table pegawai Primary Key Foreign Key golongan, jabatan Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key nip varchar 255 Not Null No NIP ktp varchar 255 Not Null No KTP golongan integer 10 Not Null No Foreign Key jabatan integer 10 Not Null No Foreign Key nama varchar 255 Not Null No Nama pegawai dob date Tanggal lahir pob varchar 255 Not Null No Tempat lahir gender varchar 255 Not Null No Jenis Kelamin tahun_masuk integer 4 Not Null No Tahun masuk status_kawin varchar 255 Not Null No Status kawin alamat text Alamat telp varchar 255 Not Null No Telepon varchar 255 Not Null No Tabel 4.85 Table Specification web_group Table web_group Primary Key Foreign Key - Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key uraian varchar 255 Not Null No Uraian Tabel 4.86 Table Specification group_access Table group_access Primary Key Foreign Key web_group, access_list Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key web_group integer 10 Not Null No Foreign Key access_list integer 10 Not Null No Foreign Key crud integer 4 Not Null No create, read, update, delete

82 157 Tabel 4.87 Table Specification access_list Table access_list Primary Key Foreign Key group_list Field Tipe Data Size Null Auto Increment Keterangan integer 10 Not Null Yes Primary Key group_list integer 10 Not Null No Foreign Key parent integer 10 Not Null No induk module varchar 255 Not Null No Nama modul order integer 10 Not Null No Urutan tampil jscript_css text javascript dan style Function Component Diagram Function Component diagram digambarkan sebagai berikut: Gambar 4.42 Function Component Diagram

83 Evaluasi Penerimaan Model Sistem Evaluasi rancangan model sistem yang dipakai dalam penelitian ini dilakukan sebelum (Pre Test) yaitu yang selanjutnya digunakan untuk menganalisa kebutuhan sistem dan sesudah pembuatan rancangan model (Post Test). Responden untuk mengevaluasi rancangan model sistem adalah orang yang sama dengan responden saat menganalisa kebutuhan sistem. Sehingga mereka paham akan letak perbedaan antara sistem yang lama dengan sistem yang diusulkan Analisa dengan Pendekatan Model TAM Evaluasi rancangan model sistem yang dipakai dalam penelitian ini menggunakan model TAM dengan variabel perceived ease of use, perceived usefulness, attitude toward using, dan intention to use, untuk menilai penerimaan responden terhadap sistem informasi yang dirancang. Evaluasi ini dilakukan dengan membagikan kuesioner kepada 30 (tiga puluh) orang responden yang merupakan penyusun anggaran di unit kerja ANRI. Untuk memperlihatkan rancangan sistem SIRKA, maka dilakukan presentasi pada responden, dan kemudian dibagikan kuesioner TAM untuk melihat penerimaan responden. Hasil evaluasi yang akan menunjukkan penerimaan pengguna terhadap model sistem SIRKA yang diusulkan dikelompokan menjadi 4 (empat) variabel TAM dengan indikatornya dapat terlihat di tabel-tabel di bawah ini :

84 159 a. Perceived Ease of Use (PEoU) Tanggapan responden akan Perceived Ease of Use (PEoU) pada tabel menunjukkan pandangan user tentang kemudahan dalam menggunakan sistem, mudah dipahami, dipelajari dan digunakan. Tabel 4.88 menunjukkan tanggapan responden di mana sistem dapat diakses dari mana saja dan kapan saja sebesar 60%. Sistem akan dapat diakses dengan mudah melalui fasilitas instansi sebesar 87%. Kemudahan dalam mempelajari proses bisnis sistem sebesar 80%, dan cara penggunaan sistem sebesar 70%. Fasilitas/fitur yang ada akan akan mudah untuk digunakan sebesar 43%. Sistem akan memperlancar proses penyusunan anggaran sebesar 53%. Sistem akan mempermudah interaksi dengan Bagian Program dan Anggaran sebesar 60%, dan interaksi dengan sesama penyusun anggaran dari unit kerja lain sebesar 43%. NO Tabel 4.88 Tanggapan Responden tentang Perceived Ease of Use (PEoU) PERNYATAAN Sistem akan dapat diakses dengan mudah dari mana saja dan kapan saja Sistem akan dapat diakses dengan mudah melalui fasilitas instansi Proses bisnis sistem akan dapat dengan mudah untuk dipelajari Cara penggunaan sistem akan mudah untuk dipelajari Fasilitas/fitur yang ada akan mudah untuk digunakan Sistem akan memperlancar proses penyusunan anggaran Saya akan sangat mudah berinteraksi dengan Bagian Program dan Anggaran kaitannya dalam proses penyusunan anggaran Sistem akan mempermudah interaksi saya dengan sesama penyusun anggaran dari unit kerja lain TAK SETUJU N (%) SETUJU N (%) 12 40% 18 60% 4 13% 26 87% 6 20% 24 80% 9 30% 21 70% 17 57% 13 43% 4 13% 16 53% 12 40% 18 60% 17 57% 13 43%

85 160 b. Perceived Usefulness (PU) Tanggapan responden akan Perceived Usefulness (PU) menunjukkan kepercayaan user bahwa sistem dapat memberikan manfaat jika digunakan. Pada tabel 4.89 memperlihatkan tanggapan responden tentang Perceived Usefulness (PU) yang menunjukkan kepercayaan user bahwa model sistem yang baru dapat memberikan manfaat jika digunakan. Dimana responden menyatakan sistem akan meningkatkan efektifitas, menjawab akan kebutuhan informasi, meningkatkan kinerja, dan meningkatkan efisiensi dengan rata-rata jawaban sebesar 57%-90%. Tabel 4.89 Tanggapan Responden tentang Perceived Usefulness (PU) NO PERNYATAAN TAK SETUJU N (%) SETUJU N (%) Sistem akan meningkatkan efektifitas dalam mengerjakan penyusunan anggaran Sistem akan memungkinkan tersimpannya knowledge dalam proses penyusunan anggaran sehingga membantu dalam pengambilan keputusan Sistem akan dapat menghasilkan informasi yang mendukung proses penyusunan anggaran Sistem akan dapat menghasilkan informasi yang dibutuhkan manajemen dalam proses pengambilan keputusan/kebijakan Sistem akan membuat saya lebih cepat dalam mengerjakan penyusunan anggaran Sistem akan mempermudah saya untuk mengerjakan penyusunan anggaran Sistem akan membuat hemat waktu dalam proses seputar penyusunan anggaran Sistem akan membuat hemat biaya dalam melakukan proses penyusunan anggaran 7 23% 23 77% 3 10% 27 90% 13 43% 17 57% 6 20% 24 80% 12 40% 18 60% 5 17% 25 83% 5 17% 25 83% 4 13% 26 87%

86 161 c. Attitude Toward Using (ATU) Tanggapan responden akan Attitude Toward Using (ATU) menunjukkan sikap user menerima atau menolak untuk menggunakan sistem SIRKA yang diusulkan. Pada tabel 4.90, terlihat responden menerima akan adanya approval dalam sistem dari pejabat yang berwenang di instansi dalam proses penyusunan anggaran sebanyak 25 orang atau 83%, dan menerima akan adanya persetujuan Eselon II dalam sistem sebelum usulan diserahkan ke Bagian Program dan Anggaran sebanyak 23 orang atau 77%. Selain itu responden menerima akan adanya model otorisasi login pada sistem untuk keamanan account sebanyak 20 orang atau 67%. NO Tabel 4.90 Tanggapan Responden tentang Attitude Toward Using (ATU) PERNYATAAN TAK SETUJU N (%) SETUJU N (%) Saya menerima akan adanya approval dalam sistem dari pejabat yang berwenang di instansi dalam proses penyusunan anggaran (Sekretaris Utama) Saya menerima akan adanya persetujuan Eselon II dalam sistem sebelum usulan diserahkan ke Bagian Program dan Anggaran Saya menerima akan adanya model otorisasi login pada sistem untuk keamanan account saya Saya menerima akan adanya pembatasan hak atas akses sistem dalam proses penyusunan anggaran Saya menolak akan adanya pembatasan waktu dalam proses penyusunan anggaran Saya menolak akan tersedianya pembatasan pagu anggaran yang berkaitan dengan standar biaya dan ketentuan tentang anggaran Saya tidak senang akan berinteraksi dengan sesama penyusun anggaran dari unit kerja lain Saya tidak senang akan mendapatkan pemberitahuan dalam pribadi saya untuk informasi seputar penyusunan anggaran 5 17% 25 83% 7 23% 23 77% 10 33% 20 67% 20 67% 10 33% 13 43% 17 57% 16 53% 14 47% 20 67% 10 33% 17 57% 13 43%

87 162 d. Intention to Use (ITU) Tanggapan responden akan Intention to Use (ITU) memperlihatkan keinginan user untuk memakai sistem tersebut. Dari tabel 4.91, responden menyatakan akan menggunakan sistem, merekomendasikan, dan mengajak pengguna lain untuk menggunakan fasilitas yang tersedia dengan prosentase 33%-60%. Hal tersebut menunjukan di kemudian hari responden memungkinkan menerima adanya rancangan sistem SIRKA ini. NO Tabel 4.91 Tanggapan Responden tentang Intention to Use (ITU) PERNYATAAN TAK SETUJU N (%) SETUJU N (%) Saya akan menggunakan sistem ini dalam proses usulan anggaran dan kegiatan di tiap periode anggaran Saya akan menggunakan sistem ini dalam pembahasan anggaran internal ANRI Saya akan merekomendasikan kepada sesama penyusunan anggaran lain untuk menggunakan sistem ini Saya akan mengajak penyusun anggaran lain untuk berinteraksi antar penyusun anggaran dengan menggunakan fasilitas yang tersedia 20 67% 10 33% 12 40% 18 60% 12 40% 18 60% 17 57% 13 43% Dari hasil evaluasi yang menunjukkan penerimaan pengguna terhadap model sistem SIRKA dengan pertanyaan yang diadopsi dari variabel TAM yaitu perceived ease of use, perceived usefulness, attitude toward using, dan intention to use yang elemen-elemen pentingnya dapat terlihat pada gambar di bawah ini :

88 163 Gambar 4.43 Elemen-elemen Penting dalam Variabel TAM Dari gambar di atas dapat terlihat lebih dari 75% responden menunjukkan SETUJU dari jumlah total 30 responden terhadap semua elemen penting yang diajukan dalam kuesioner. Hal tersebut menunjukkan besarnya tingkat penerimaan terhadap model sistem SIRKA yang diusulkan. Gambar 4.44 Tanggapan Responden Berdasarkan Masa Kerja