KATA PENGANTAR

Sistem pemerintahan berbasis elektronik (SPBE) adalah amanat Perpres Nomor 95 Tahun
2018. SPBE dilaksanakan dengan prinsip efektivitas, keterpaduan, kesinambungan efisiensi,
akuntabilitas dan interoperabilitas. Pada PERMENPANRB 59/2020, Domain SPBE meliputi
Kebijakan SPBE, Tata kelola SPBE, Manajemen SPBE dan Layanan SPBE. Dengan domain baru
yaitu Manajemen SPBE yang meliputi Aspek Penerapan Manajemen dan Audit TIK.
Aspek Audit Teknologi Informasi dan Komunikasi (TIK) adalah proses yang sistematis untuk
memperoleh dan mengevaluasi bukti secara objektif terhadap asset teknologi informasi dan
komunikasi dengan tujuan untuk menetapkan tingkat kesesuaian antara teknologi informasi
dan komunikasi dengan kriteria dan/atau standar yang telah ditetapkan.
Audit teknis aplikasi ini dimaksudkan untuk mengevaluasi tingkat kesesuaian antara sistem
informasi dengan prosedur bisnis (bisnis processes) perusahaan (atau kebutuhan pengguna,
user needs), untuk mengetahui apakah suatu sistem informasi telah didesain dan
diimplementasikan secara efektif, efisien, dan ekonomis, memiliki mekanisme pengamanan
aset, serta menjamin integritas data yang memadai.
Dalam laporan audit aplikasi khususnya tentang Kajian Audit Teknis Aplikasi Pemerintah
Kabupaten Malang ini kami bagi menjadi 2 domain, yaitu Domain Tata Kelola dan
Manajemenserta Domain Fungsionalitas. Hasil kajian berupa kelemahan, kekuatan dan
rekomendasi ke depan tentang pengelolaan aplikasi SPBE yang ada.
Akhirnya semoga hasil dari kegiatan audit aplikasi ini dapat bermanfaat bagi masyarakat dan
pemerintah kabupaten Malang agar dapat menyelenggarakan layanan SPBE dengan lebih
baik dari sebelumnya.

Malang, Desember 2021

Penyusun

1
Daftar Isi
1.
Pendahuluan 1

1.1 Dasar 1

1.2 Latar Belakang dan Ruang Lingkup 1

1.3 Metodologi 2

2. Ringkasan
Hasil Audit 3

2.1. Profil Penyelenggara Layanan 3

2.2. Kriteria Penilaian 3

2.2.1. Kriteria penilaian domain tata Kelola dan Manajemen 4

2.2.2. Kriteria Penilaian Domain Fungsionalitas Layanan 5
2.3. Ringkasan Hasil Audit Aplikasi 6

2.3.1. Ringkasan Audit Domain Tata Kelola dan Manajemen 7

2.3.2. Ringkasan Audit Domain Fungsionalitas Layanan 9

3. Hasil Audit Domain

Tata Kelola 12

3.1. Deskripsi Hasil Audit 12

3.1.1. Indikator Keselarasan strategi organisasi dan pengembangan aplikasi 12

3.1.2. Indikator manajemen risiko dalam pengelolaan aplikasi TIK 13
3.1.3. Indikator monitoring dan evaluasi dalam proses tata Kelola 14
3.1.4. Indikator Frekuensi pemeliharaan layanan 15
3.1.5. Indikator Evaluasi layanan 16
3.2. Detail Hasil Audit Per OPD 16

3.2.1. Dinas Pertanahan Error! Bookmark not defined.

3.2.2. Bagian Perekonomian 17
3.2.3. Dinas Kesehatan 17
3.2.4. Dinas Pendidikan 17
3.2.5. Balitbangda Error! Bookmark not defined.
3.2.6. BKAD 18
3.2.7. Dinas Kominfo 18
3.2.8. Dinas Perhubungan Error! Bookmark not defined.

2
4.
Fungsionalitas 20

4.1. Deskripsi Hasil Audit 20

4.1.1. Indikator Ketersediaan dokumen kebutuhan layanan OPD 21

4.1.2. Indikator Ketersediaan dokumen user requirement 21
4.1.3. Indikator Ketersediaan dokumen teknis Pengembangan Aplikasi 22
4.1.4. Indikator Ketersediaan Dokumen penggunaan 22
4.1.5. Indikator Ketersediaan Source Code Aplikasi 23
4.1.6. Indikator Ketersediaan dokumentasi Pengujian Aplikasi 23
4.2. Detail Hasil Audit Per OPD 24

4.2.1. Dinas Pertanahan Error! Bookmark not defined.

4.2.2. Bagian Perekonomian 24
4.2.3. Dinas Kesehatan 24
4.2.4. Dinas Pendidikan 25
4.2.5. Balitbangda Error! Bookmark not defined.
4.2.6. BKAD 25
4.2.7. Dinas Kominfo Error! Bookmark not defined.
4.2.8. Dinas Perhubungan Error! Bookmark not defined.

LAMPIRAN 1. Form Audit Aplikasi Pemerintahan Kabupaten Malang 26

Lampiran 2. Tahapan Proses Audit 15

Lampiran 3. Manajemen Resiko 16

Lampiran 4. Pengujian Aplikasi 21

Lampiran 5. Manajemen Resiko Error! Bookmark not defined.

3
Daftar Gambar

Figure 1. Profile Penyelenggara dan Jumlah aplikasi pada Pemerintahan Kabupaten

Malang 3
Figure 2 Ringkasan Hasil Audit Domain Tata Kelola 8
Figure 3 Ringkasan Hasil Audit Domain Fungsionalitas Layanan 9
Figure 4. Ringkasan Hasil Audit Domain Keamanan 11

4
Daftar Tabel
Table 1 Ringkasan Hasil Audit 6
Table 2. Persentase Ketersedian Dokumen Tata Kelola 8
Table 3. Ketersediaan Dokumen Penunjang Domain Fungsionalitas Layanan 9
Table 4. Ketersediaan Dokumen Penunjang Domain Keamanan 11
Table 5. Hasil Audit Domain Tata Kelola 12

5
1. Pendahuluan

1.1 Dasar
1. Peraturan Presiden No 95 Tahun 2018 tentang Sistem Pemerintahan Berbasis Elektronik
(SPBE) Pasal 55, 56, 57 dan 58;
2. Peraturan Menteri Komunikasi Dan Informatika Republik Indonesia Tentang Kebijakan Umum
Penyelenggaraan Audit Teknologi Informasi Dan Komunikasi (Draft)
3. Peraturan Menteri Pendayagunaan Aparatur Negara dan Reformasi Birokrasi No. 59 Tahun
2020 tentang Pemantauan dan Evaluasi SPBE
4. Peraturan Menteri Perencanaan Pembangunan Nasional/ Kepala Bappenas RI Nomor 16
Tahun 2020 Tentang Manajemen Data Sistem Pemerintahan Berbasis Elektronik
5. Peraturan BPPT RI Tentang Standar Dan Tata Laksana Audit Infrastruktur Sistem Pemerintahan
Berbasis Elektronik (SPBE) (Draft)

1.2 Latar Belakang dan Ruang Lingkup

Audit Teknologi Informasi dan Komunikasi yang selanjutnya disebut Audit TIK adalah proses
yang sistematis, independen, dan terdokumentasi untuk memperoleh dan mengevaluasi bukti
secara objektif terhadap Teknologi Informasi dan Komunikasi dengan tujuan untuk
menetapkan tingkat kesesuaian antara kondisi dengan kriteria dan/atau standar yang telah
ditetapkan. Berdasarkan Peraturan Presiden No 95 Tahun 2018 Audit Teknologi Informasi dan
Komunikasi terdiri atas: audit Infrastruktur SPBE, audit Aplikasi SPBE dan audit Keamanan
SPBE.

Audit Teknologi Informasi dan Komunikasi meliputi pemeriksaan hal pokok teknis pada:
penerapan tata kelola dan manajemen teknologi informasi dan komunikasi; fungsionalitas
teknologi informasi dan komunikasi; dan kinerja teknologi informasi dan komunikasi yang
dihasilkan; serta aspek teknologi informasi dan komunikasi lainnya.

Salah satu upaya untuk menguatkan aplikasi e-Government di Pemerintahan Kabupaten

Malang sesuai dengan PERMENPAN RB Nomor 59 tahun 2020 adalah kegiatan audit teknis

1
 aplikasi SPBE Pemkab Malang. Audit teknis aplikasi ini dimaksudkan untuk mengevaluasi
tingkat kesesuaian antara sistem informasi dengan prosedur bisnis (bisnis processes)
perusahaan (atau kebutuhan pengguna, user needs), untuk mengetahui apakah suatu sistem
informasi telah didesain dan diimplementasikan secara efektif, efisien, dan ekonomis,
memiliki mekanisme pengamanan aset, serta menjamin integritas data yang memadai.
Dalam laporan audit aplikasi khususnya tentang Kajian Audit Teknis Aplikasi Pemerintah
Kabupaten Malang ini kami bagi menjadi 2 domain, yaitu Domain Tata Kelola dan
Manajemenserta Domain Fungsionalitas. Hasil kajian berupa kelemahan, kekuatan dan
rekomendasi ke depan tentang pengelolaan aplikasi SPBE yang ada.

1.3 Metodologi
Dalam pelaksanaan kegiatan, kami menggunakan beberapa standar yang selama ini dipakai
yaitu :
● Dokumen Standar Audit Intern Pemerintah Indonesia dari Asosiasi Auditor Intern Pemerintah
Indonesia (AAIPI) (AAIPI 19).
● Pendekatan Control Framework dan Metodologi yang digunakan:
● Control Objectives for Information and related Technology (COBIT 2019) framework yang
dibangun oleh Information Systems Audit and Control Association (ISACA). (ISACA)
● Draft Peraturan Badan (Perban) BPPT yang memuat tentang Standar Dan Tata Cara
Pelaksanaan Audit Infrastruktur Dan Audit Aplikasi Sistem Pemerintahan Berbasis Elektronik
tahun 2021. (BPPT)
● Pedoman Tools Audit Aplikasi dan Infrastruktur SPBE yang dikembangkan oleh BPPT pada
Website https://audit-infrastruktur-aplikasi.bppt.go.id/webaudit-v2/. (BPPT)

Dalam pelaksanaannya kami menggunakan standar Pelaksanaan Audit Infrastruktur Dan Audit
Aplikasi Sistem Pemerintahan Berbasis Elektronik dari BPPT, Standar Audit Keamanan SPBE
dari BSSN serta COBIT 2019 sebagai acuan pengujian. Dalam pelaksanaan dibagi menjadi 2
domain, yaitu Domain Tata Kelola dan Manajemen serta Domain Fungsionalitas. Hasil kajian
berupa kelemahan, kekuatan dan rekomendasi ke depan tentang pengelolaan aplikasi SPBE
yang ada. Selain itu juga sekaligus melakukan pencatatan aset yang menghasilkan
dokumentasi aset masing-masing aplikasi.
2. Ringkasan Hasil Audit

2.1. Profil Penyelenggara Layanan

Audit Aplikasi Sistem Pemerintahan Berbasis Elektronik adalah pemeriksaan/evaluasi secara
sistematis dan obyektif dalam rangka memberikan nilai tambah atau meningkatkan kinerja
terhadap Aplikasi Sistem Pemerintahan Berbasis Elektronik. Salah satu upaya untuk
menguatkan aplikasi e-Government pada Pemerintahan Kabupaten Malang sesuai dengan
PERMENPAN RB Nomor 59 tahun 2020 adalah kegiatan audit teknis aplikasi SPBE
Pemerintahan Kabupaten Malang. Terdapat 8 OPD yang berkontribusi dengan jumlah
keseluruhan 58 aplikasi yang dilakukan proses audit aplikasi kali ini, detail per OPD bisa dilihat
pada gambar 1. Berdasarkan hasil pendataan tersebut semua OPD sudah memiliki aplikasi
layanan, namun masih belum merata jumlah layanan masing-masing OPD, kedepan bisa
ditingkatkan pengembangan aplikasi sesuai tupoksi masing-masing OPD dan sesuai
masterplan SPBE Pemerintahan Kabupaten Malang.

Profil Penyelengara

BKAD 1

Dinas Pertanahan 8

Dinas Perhubungan 1

Dinas Pendidikan 9

Dinas Kominfo 28

Dinas Kesehatan 2

Balitbangda 2

Bagian Perekonomian 7

0 5 10 15 20 25 30

Gambar 1. Profil Penyelenggara dan Jumlah aplikasi pada Pemerintahan Kabupaten Malang

2.2. Kriteria Penilaian

Berdasarkan pasal 55 ayat 5 Peraturan Presiden nomor 95 tahun 2018 tentang Sistem
Pemerintahan Berbasis Elektronik maka Menteri Komunikasi Dan Informatika Republik
Indonesia menetapkan Kebijakan Umum Penyelenggaraan Audit Teknologi Informasi Dan
 Komunikasi yang tertuang dalam draft peraturannya. Berdasarkan draft peraturan tersebut
khususnya pasal 5, Audit TIK meliputi pemeriksaan hal pokok teknis pada:
a. penerapan tata kelola dan manajemen TIK;
b. fungsionalitas dan kinerja TIK; dan
c. aspek TIK lainnya.

Pada pelaksanaan audit aplikasi Pemerintahan Kabupaten Malang ini, terdapat 3 domain
utama yang dilakukan proses audit yaitu tata kelola dan manajemen TIK, fungsionalitas dan
kinerja TIK dengan keseluruhan indicator sejumlah 18 indikator. Hasil kajian berupa temuan
dan dan rekomendasi. Tentu hasil audit sangat tergantung pada kondisi saat ini ketika
dilakukan audit. Sehingga kompleksitasnya sangat tergantung pada kondisi saat ini, dan solusi
audit yang tertuang dalam rekomendasi hasil audit disesuaikan dengan tujuan SPBE.

Kriteria penilaian : Kriteria penilaian secara umum berupa nilai kapabilitas yang terdiri dari
nilai 1,2,3 atau 4. Hal ini disesuaikan dengan kriteria penilaian berdasarkan draft standard
BPPT dengan nilai maksimal 4.

2.2.1. Kriteria penilaian domain tata Kelola dan manajemen

TIK harus bisa memberikan nilai tambah bagi organisasi, perlu dipastikan TIK sesuai dengan
kebutuhan bisnis organisasi. Audit tata Kelola memastikan agar TIK memenuhi kebutuhan
bisnis organisasi dan tersedia sistem control internal. Pimpinan perlu melakukan kendali
supaya TIK mempunyai value, diselaraskan dengan visi misi strategi organisasi, selain itu
pengetahuan, analisa dan pengendalian risiko perlu dilakukan untuk memperoleh efektivitas
dan efisiensi yang lebih tinggi. Supaya tetap selalu memberi nilai tambah, maka perlu adanya
monitoring dan evaluasi tata Kelola sehingga sesuai dengan kebutuhan bisnis. Diharapkan
dengan semua hal diatas Aplikasi bisa memberikan value dan nilai tambah bagi organisasi.

Selain itu setiap penyelenggaraan/implementasi TIK mengandung/melekat berbagai resiko,

setiap implementasi TIK memiliki potensi ancaman atau sisi kerawanan hanya tingkatannya
yang berbeda, jika tidak ditangani sungguh-sungguh dapat mengganggu beroperasinya
organisasi yang dimaksud.

Manajemen resiko berisi proses melakukan identifikasi kejadian (event) yang terkait dengan
resiko. Secara sistematis organisasi perlu melakukan identifikasi terhadap kemungkinan
kejadian yang tidak diinginkan, apa saja yang mampu dihadapi unit kerja dan tingkat
probabilitas kemungkinan terjadinya. Perlu adanya usaha untuk menentukan profil risiko yang
 dihadapi, prediksi risiko dan mitigasinya, memahami keterkaitan risiko dengan visi, misi dan
tujuan organisasi dan tugas pokok dan fungsi, memetakan tingkat dampak terhadap
kelancaran pelaksanaan bisnis proses yang ada dalam unit kerja yang bersangkutan serta
membuat prioritas dan rencana aktivitas pengendaliannya dan melakukan pemantauan dan
pengawasan risiko.

Diharapkan dengan adanya manajemen resiko TIK yang dikembangkan organisasi secara
sistematis dan terstruktur tidak akan terjadinya gangguan terhadap aktivitas organisasi
dalam mencapai visi, misi, dan tujuannya melalui pengembangan TIK.

Berdasarkan hal kebutuhan hal diatas, lingkup domain tata Kelola dan manajemen terdiri
atas :
a. Keselarasan antara strategi organisasi (Visi misi) dan pengembangan aplikasi
b. Ketersediaan dokumen manajemen risiko dalam pengelolaan aplikasi TIK
c. Ketersediaan monitoring dan evaluasi dalam proses tata kelola
d. Ketersediaan pemeliharaan dan evaluasi layanan
e. Ketersediaan dokumen kontrak bagi yang dikerjakan oleh pihak ketiga

Kriteria penilaian domain tata Kelola dan manajemen dengan level penilaian mulai dari 1
sampai dengan 4, dengan penilaian sebagai berikut : 1. Apabila tidak terdapat kegiatan atau
produk/dokumen yang dihasilkan, 2. Terdapat Produk/dokumen yang dihasilkan tapi masih
belum dijalankan, 3. Dijalankan dengan perencanaan yang ada 3. Dijalankan berdasarkan
perencanaan yang ada dan dilakukan evaluasi

2.2.2. Kriteria Penilaian Domain Fungsionalitas Layanan

Untuk meningkatkan fungsionalitas dan kinerja aplikasi maka aplikasi yang dikembangkan
perlu memiliki hal-hal sbb :
● Kebutuhan layanan aplikasi sesuai dengan kebutuhan proses bisnis dan didokumentasikan
dalam dokumen Deskripsi Perancangan Aplikasi
● Tersedianya Source code aplikasi yang dilengkapi dengan dokumentasi yang memadai
sehingga pengembangan ke depan lebih mudah dan bisa dilakukan kustomisasi jika
dibutuhkan
● Tersedianya dokumentasi Uji coba aplikasi dan terdokumentasi dalam suatu test plan, test
design, test case, test procedures dan dokumen hasil test sehingga jalannya aplikasi sesuai
dengan kebutuhan proses bisnis
● Tersedia dokumentasi penggunaan aplikasi (user guide) baik untuk end-users maupun
administrator;
● Tersedia dokumentasikan pemeliharaan

Diharapkan dengan semua dokumentasi ini fungsionalitas dan kinerja aplikasi bisa terjaga
baik.

Lingkup Audit aplikasi domain fungsionalitas layanan terdiri atas:

a. Perencanaan Aplikasi : Aplikasi direncanakan dalam suatu dokumen Spesifikasi Kemampuan
Aplikasi yang didokumentasikan serta dijelaskan dalam dokumen Deskripsi Rancangan
Aplikasi dengan mengacu kepada arsitektur SPBE dengan mempertimbangkan kebutuhan,
peluang dan proses bisnis.
b. Realisasi Aplikasi : Pembangunan aplikasi harus didokumentasikan dalam dokumen Prosedur
Pembangunan Aplikasi (System build procedures) dan tersedia source code aplikasi untuk
pengembangan ke depan
c. Pengoperasian Aplikasi : Aplikasi dilengkapi dengan dokumentasi penggunaan aplikasi (user
guide) untuk end-users maupun administrator
d. Pengujian Aplikasi : Uji coba terhadap aplikasi harus terdokumentasi dalam suatu test plan,
test design, test case, test procedures dan dokumen hasil test.

Kriteria penilaian domain fungsionalitas layanan berupa : 1. Apabila tidak terdapat kegiatan
dalam proses yang ada dan atau produk/dokumen yang dihasilkan, 2. Terdapat
produk/dokumen yang dihasilkan dari proses 3. Proses dijalankan berdasarkan dokumen yang
ada 4. Dijalankan berdasarkan dokumen dan dilakukan evaluasi .

2.3. Ringkasan Hasil Audit Aplikasi

Berdasarkan entri data yang dilakukan oleh masing-masing OPD serta evaluasi berdasarkan
kriteria yang sudah dibuat berikut adalah rekap table hasil penilaian audit aplikasi
Pemerintahan Kabupaten malang. Kriteria penilaian secara umum berupa nilai kapabilitas
yang terdiri dari nilai 1,2,3 atau 4. Hal ini disesuaikan dengan kriteria penilaian berdasarkan
draft standard BPPT dengan nilai maksimal 4.
 Table 1 Ringkasan Hasil Audit

Nilai Nilai Nilai

N
Domain Indikator Indik Mini Maksimu
o
ator mum m
Tata
Kelola
Keselarasan strategi Visi Misi dengan aplikasi
1 dan 2.67 1 4
yang dibuat
Manajem
en
Dokumen Resiko dalam pengelolaan TIK 2.02 1 4
Monitoring dan Evaluasi 2.53 1 4
Frekuensi pemeliharaan layanan 2.47 1 4
Evaluasi layanan 2.30 1 4
Fungsiona
2 litas Ketersediaan dokumen kebutuhan layanan OPD 2.05 1 4
Layanan
Ketersediaan dokumentasi user requirement 1.31 1 4
Ketersediaan dokumen teknis Pengembagan
2.38 1 4
Aplikasi
Ketersediaan dokumen Dokumen penggunaan 2.38 1 4
Ketersediaan Source Code Aplikasi 4.10 1 4
Ketersediaan Dokumen Pengujian Aplikasi 1.21 1 4

2.3.1. Ringkasan Audit Domain Tata Kelola dan Manajemen

Audit Domain Tata Kelola Perlu dikendalikan supaya TIK mempunyai value, diselaraskan
dengan visi misi strategi organisasi. Proses tata Kelola pada prinsipnya digunakan untuk
memantau dan mengendalikan serta memastikan bahwa TIK mempunyai value dan selaras
dengan visi misi strategi organisasi. Pimpinan dalam suatu organisasi perlu mendorong
kapabilitas TIK. Selain itu juga pimpinan perlu menumbuhkan kepercayaan dari para
pemangku kepentingan utama tentang kapabilitas TIK serta mampu melakukan pengendalian
risiko untuk memperoleh efektivitas dan efisiensi yang lebih tinggi, sehingga TIK dalam hal ini
Aplikasi bisa memberikan value dan nilai tambah bagi organisasi.

Berdasarkan hasil audit domain tata Kelola dan Manajemen :

Sebagian besar layanan sudah terdapat keselarasan strategi organisasi dalam pengembangan
aplikasi, sehingga nantinya perencanaan, penganggaran dan pengembangan serta
pemeliharaan layanan bisa lebih optimal. Beberapa aplikasi pada BKAD, Dinas Kesehatan dan
Dinas Pendidikan belum menunjukkan keselarasan strategi organisasi dalam pengembangan
aplikasi. Meskipun Sebagian besar layanan sudah terdapat keselarasan strategi organisasi
dalam pengembangan aplikasi tapi mayoritas belum ditunjang oleh dokumen yang
mendukung, hanya Dinas Kominfo yang sudah menunjukkan dokumen penunjangnya

Sebagian besar layanan sudah melakukan monitoring dan evaluasi tata kelola, diharapkan
dengan selalu melakukan evaluasi dan monitoring tata kelola layanan bisa memberikan value
dan nilai tambah bagi organisasi. Meskipun sebagian besar layanan sudah melakukan
monitoring dan evaluasi tata Kelola tapi hasil monitoring dan evaluasi belum tersedia, hal ini
melakukan evaluasi capaian yang ada jika belum ada catatan hasil monitoring dan
evaluasinya.

Sebagian besar layanan masih belum tersedia manajemen risiko dalam pengelolaan layanan,
hal ini bisa berakibat bisa terjadi gangguan layanan yang tidak terduga sehingga aktivitas
organisasi dalam mencapai visi, misi, dan tujuannya melalui pengembangan TIK terganggu .
Ke depan perlu dipersiapkan lagi dokumen manajemen risiko yang berisi identifikasi terhadap
kemungkinan kejadian yang tidak diinginkan,tingkat probabilitas kemungkinan
terjadinya,prediksi risiko dan mitigasinya, serta pemetaan tingkat dampak terhadap
kelancaran pelaksanaan.

Domain Tata Kelola dan Manajemen Per OPD

5.00
4.00
3.00
2.00
1.00
0.00
Keselarasan strategi Ketersediaan Ketersediaan Frekuensi Evaluasi layanan
organisasi dan manajemen resiko monitoring dan pemeliharaan layanan
pengembangan dalam pengelolaan evaluasi dalam proses
aplikasi aplikasi TIK tata kelola

Rata-Rata OPD Dinas Pertanahan Bag Perekonomian Dinas Kesehatan Dinas Pendidikan
Balitbangda BKAD KOMINFO Dinas Pehubungan

Figure 2 Ringkasan Hasil Audit Domain Tata Kelola dan Manajemen

Rangkuman ketersediaan dokumen penunjang domain tata Kelola bisa dilihat pada tabel 2 di
bawah ini. Sebagian besar belum tersedia dokumen tata Kelola, hanya dinas kominfo dan
balitbangda yang sudah tersedia dokumen, sedangkan semua OPD belum menyediakan
 dokumen monitoring dan evaluasi dalam proses tata Kelola. Ke depan perlu dipersiapkan lagi
dokumen

Table 2. Persentase Ketersedian Dokumen Tata Kelola dan Manajemen

2.3.2. Ringkasan Audit Domain Fungsionalitas Layanan

Audit Domain Fungsionalitas layanan dititikberatkan pada fungsi dan kinerja aplikasi,
diharapkan dengan terpenuhinya dokumen yang diminta, fungsionalitas dan kinerja aplikasi
bisa tercatat dengan baik. Setiap aplikasi yang dikembangkan perlu memiliki hal-hal sbb :
● tersedia dokumen perencanaan kebutuhan layanan yang didalamnya berisi kesesuaian dan
keselarasan aplikasi dengan kebutuhan proses bisnis,
● tersedianya Source code aplikasi sehingga pengembangan ke depan tidak terkendala,
● tersedianya dokumentasi Uji coba aplikasi sehingga aplikasi bisa dipastikan bahwa software
yang dihasilkan sesuai dengan kebutuhan (requirement) yang sebelumnya ditentukan, selain
itu juga untuk menemukan kesalahan (fault) sebanyak mungkin dari perangkat lunak yang diuji
sehingga implementasi tidak terkendala bug nantinya, selain itu juga untuk tindakan preventif
perencanaan layanan,
● tersedia dokumentasi penggunaan aplikasi (user guide) baik untuk end-users maupun
administrator sehingga jika terjadi pergantian personel layanan aplikasi tidak terganggu
● Tersedia dokumentasikan pemeliharaan untuk menyesuaikan aplikasi dengan proses bisnis
jika dibutuhkan.

Berdasarkan hasil audit domain Fungsionalitas layanan :

Sebagian besar layanan masih belum menyertakan perencanaan layanan, untuk ke depan
perlu adanya pembuatan dokumen perencanaan untuk setiap pengembangan aplikasi
sehingga aplikasi yang dibuat benar-benar terdokumentasi dengan baik dan membantu fungsi
proses bisnis yang ada dan terdapat peraturan yang menunjang. Diharapkan dengan adanya
dokumen ini menyebabkan perencanaan, penganggaran dan pengembangan serta
pemeliharaan layanan menjadi lebih optimal.
Selain itu ketersediaan dokumen teknis layanan seperti desain layanan, instalasi dan
konfigurasi serta spesifikasi kebutuhan layanan mayoritas masih belum tersedia. Hal ini dapat
berakibat buruk terhadap kinerja layanan secara menyeluruh karena dapat dipastikan
berhentinya kegiatan pengembangan, terganggunya kegiatan pemeliharaan dan kinerja
layanan kurang optimal.

Temuan lainnya adalah Sebagian layanan tidak menyediakan dokumen penggunaan. Hal ini
dapat menyebabkan terganggunya operasional layanan karena kurangnya pengetahuan
pengguna baik dari admin, operator dan juga masyarakat, dan juga jika terjadi pergantian
personel, layanan aplikasi bisa terganggu.

Sebagian besar layanan masih belum menyertakan dokumen pengujian aplikasi, hal ini bisa
menyebabkan aplikasi yang dihasilkan kurang sesuai dengan kebutuhan (requirement) yang
sebelumnya ditentukan, selain itu juga bisa tidak terdeteksinya kesalahan (fault) sehingga
implementasi bisa terkendala bug nantinya.

Sedangkan Hampir semua sudah tersedia source code aplikasi, hal ini akan mempermudah
jika terjadi pengembangan aplikasi ke depan.

Domain Fungsionalitas
4.00
3.00
2.00
1.00
0.00
Dok Perencanaan Dok user Dok teknis Dok penggunaan Source Code Dok Pengujian
sesuai Proses requirement Pengembagan Aplikasi Aplikasi Aplikasi dan
Bisnis Aplikasi metode pengujian

Rata-Rata OPD Dinas Pertanahan Bag Perekonomian Dinas Kesehatan Dinas Pendidikan
Balitbangda BKAD KOMINFO Dinas Pehubungan

Figure 3 Ringkasan Hasil Audit Domain Fungsionalitas Layanan

Rangkuman ketersediaan dokumen penunjang domain Fungsionalitas Layanan bisa dilihat

pada tabel 3 dibawah ini. Sebagian besar belum tersedia dokumen Fungsionalitas. Rata-rata
ketersediaan masih dibawah 20%, ke depan perlu dipersiapkan lagi dokumen pendukung
yang ada
Table 3. Ketersediaan Dokumen Penunjang Domain Fungsionalitas Layanan
 3. Hasil Audit Domain Tata Kelola dan Manajemen

3.1. Deskripsi Hasil Audit

Proses tata Kelola pada prinsipnya digunakan untuk memantau dan mengendalikan serta
memastikan bahwa TIK mempunyai value dan selaras dengan visi misi strategi organisasi.
Pimpinan dalam suatu organisasi perlu mendorong kapabilitas TIK. Selain itu juga pimpinan
perlu menumbuhkan kepercayaan dari para pemangku kepentingan utama tentang
kapabilitas TIK serta mampu melakukan pengendalian risiko untuk memperoleh efektivitas
dan efisiensi yang lebih tinggi, sehingga TIK dalam hal ini Aplikasi bisa memberikan value dan
nilai tambah bagi organisasi.

Secara garis besar hasil audit domain tata Kelola dan rekomendasi adalah sebagai berikut :
Sebagian besar layanan sudah terdapat keselarasan strategi organisasi dalam pengembangan
aplikasi dan juga sebagian besar layanan sudah melakukan monitoring dan evaluasi tata Kelola
akan tetapi Sebagian besar layanan masih belum tersedia manajemen risiko dalam
pengelolaan layanan. Sehingga ke depan perlu ada peningkatan dalam manajemen risiko
dalam pengelolaan TIK

Table 5. Hasil Audit Domain Tata Kelola

3.1.1. Indikator Keselarasan strategi organisasi dan pengembangan aplikasi

keselarasan strategi organisasi dalam pengembangan aplikasi perlu dilakukan supaya layanan
TIK mempunyai value bagi organisasi, selain itu dengan adanya keselarasan nantinya
perencanaan, penganggaran dan pengembangan serta pemeliharaan layanan bisa lebih
optimal. Dari 58 aplikasi yang dilakukan audit masih terdapat 20 aplikasi yang belum terdapat
dokumen keselarasan antara strategi organisasi dengan pengembangan aplikasi yang
 dibangun hal ini bisa menyebabkan kurang optimalnya pengembangan aplikasi ke depan.
Meskipun Sebagian besar layanan sudah terdapat keselarasan strategi organisasi dalam
pengembangan aplikasi tapi mayoritas belum ditunjang oleh dokumen yang mendukung,
hanya Dinas Kominfo yang sudah menunjukkan dokumen penunjangnya

Keselarasan Antara Strategi Organisasi (Visi misi)

dan Pengembangan Aplikasi
30
25
25
20
20
15
10 8
5
5
0
Tidak ada Terdapat dokumen Terdapat dokumen Terdadapt dokumen
master plan master plan, master Plan
Dilaksanakan dan Dilaksanakan,
Dikelola Dikelola dan
Dievaluasi

Figure 5. Indikator Keselarasan Strategi Organisasi dan Pengembangan Aplikasi

3.1.2. Indikator manajemen risiko dalam pengelolaan aplikasi TIK

Selain itu setiap penyelenggaraan/implementasi TIK mengandung/melekat berbagai resiko,
setiap implementasi TIK memiliki potensi ancaman atau sisi kerawanan hanya tingkatannya
yang berbeda, jika tidak ditangani sungguh-sungguh dapat mengganggu beroperasinya
organisasi yang dimaksud.Diharapkan dengan adanya manajemen resiko TIK yang
dikembangkan organisasi secara sistematis dan terstruktur tidak akan terjadinya gangguan
terhadap aktivitas organisasi dalam mencapai visi, misi, dan tujuannya melalui pengembangan
TIK.

Masih terdapat 30 aplikasi yang belum tersedia manajemen risiko dalam pengelolaan layanan,
hal ini bisa berakibat bisa terjadi gangguan layanan yang tidak terduga sehingga aktivitas
organisasi dalam mencapai visi, misi, dan tujuannya melalui pengembangan TIK terganggu .
Ke depan perlu dipersiapkan lagi dokumen manajemen risiko yang berisi identifikasi terhadap
kemungkinan kejadian yang tidak diinginkan,tingkat probabilitas kemungkinan terjadinya,
prediksi risiko dan mitigasinya, serta pemetaan tingkat dampak terhadap kelancaran
pelaksanaan.
 Manajemen Resiko Dalam Pengelolaan Aplikasi
TIK
35
30
30
25
25
20
15
10
5 3
0
0
Tidak ada Terdapat dokumen Terdapat dokumen, Terdadapt dokumen,
Dilaksanakan dan Dilaksanakan,
Dikelola Dikelola dan
Dievaluasi

Figure 6. Manajemen Risiko Dalam Pengelolaan Aplikasi TIK

3.1.3. Indikator monitoring dan evaluasi dalam proses tata Kelola

TIK harus bisa memberikan nilai tambah bagi organisasi, perlu dipastikan TIK sesuai dengan
kebutuhan bisnis organisasi.Audit tata Kelola memastikan agar TIK memenuhi kebutuhan
bisnis organisasi dan tersedia sistem control internal. Monitoring dan Evaluasi Tata Kelola
merupakan salah satu bentuk control internal supaya Aplikasi bisa memberikan value dan nilai
tambah bagi organisasi.

Berdasarkan data audit terdapat 23 layanan belum tersedia monitoring dan evaluasi dalam
proses tata Kelola organisasi, sedang sisanya sudah tersedia monitoring dan evaluasi tata
kelola, diharapkan dengan selalu melakukan evaluasi dan monitoring tata kelola layanan bisa
memberikan value dan nilai tambah bagi organisasi. Meskipun sebagian besar layanan sudah
melakukan monitoring dan evaluasi tata Kelola tapi hasil monitoring dan evaluasi belum
tersedia, hal ini melakukan evaluasi capaian yang ada jika belum ada catatan hasil monitoring
dan evaluasinya
 Monitoring dan Evaluasi Dalam Proses Tata Kelola
25 23 23

20

15

10
7
5
5

0
Tidak ada Terdapat dokumen Terdapat dokumen, Terdadapt dokumen,
Dilaksanakan dan Dilaksanakan,
Dikelola Dikelola dan
Dievaluasi

Figure 7. Monitoring dan Evaluasi Dalam Proses Tata Kelola

3.1.4. Indikator Frekuensi pemeliharaan layanan

Frekuensi pemeliharaan layanan dapat berupa kegiatan pembaharuan(update), penambalan
kerentanan (patch), backup dan kegiatan teknis lainnya.Indikator ini menunjukkan seberapa
sering pemeliharaan teknis dari sebuah layanan. Pemeliharaan layanan menunjukkan
bahwa pengelolaan aplikasi sudah berjalan dengan baik atau tidak. Berdasarkan hasil audit
masih terdapat 19 aplikasi yang belum melakukan pemeliharaan layanan, hal ini bisa
menyebabkan kinerja aplikasi terkendala.

Frekuensi Pemeliharaan Layanan

20 19
18 17
16
14 13
12
10 9
8
6
4
2
0
Tidak pernah Sekali dalam 1 tahun Lebih satu kali dalam Lainnya
satu tahun

Figure 8. Frekuensi Pemeliharaan Layanan

3.1.5. Indikator Evaluasi layanan
Indikator evaluasi Layanan menunjukkan seberapa sering dari pihak manajemen melakukan
evaluasi terhadap layanannya. Didapatkan data bahwa sudah terdapat 33 layanan aplikasi
yang melakukan evaluasi secara berkala, sebanyak 25 layanan masih belum melakukan
evaluasi. Dari 33 layanan dilakukan evaluasi sekali dalam 1 tahun sebesar 14 dan sudah
dilakukan evaluasi lebih dari satu kali sebesar 12 sisanya dilakukan evaluasi jika diperlukan.
Hal ini menunjukkan bahwa
pengelolaan aplikasi sudah berjalan dengan baik, meskipun perlu peningkatan lebih lanjut.

Evaluasi Layanan
30
25
25

20
14
15 12

10 7

0
Tidak pernah Sekali dalam 1 tahun Lebih satu kali dalam Jika diperlukan dan
satu tahun Ketika diketemukan
masalah

Figure 9. Evaluasi Layanan

3.2. Detail Hasil Audit Per OPD

3.2.1. Dinas Pertanahan
Sebagian besar aplikasi yang dikelola Dinas Pertanahan sudah terdapat keselarasan strategi
organisasi dengan aplikasi yang ada, masih terdapat 3 aplikasi yang belum ada keselarasan
dengan strategi perusahaan, meskipun Sebagian besar sudah terdapat keselarasan strategi
organisasi dengan aplikasi akan tetapi belum ditunjukkan ketersediaan dokumen yang
menunjukkan keselarasan antara aplikasi yang dibuat dengan strategi organisasi serta seluruh
aplikasi belum tersedia dokumen manajemen risiko selain itu juga masih perlu peningkatan
monitoring dan evaluasi tata Kelola

Secara keseluruhan sudah dilakukan pemeliharaan layanan secara berkala dan dilakukan
evaluasi untuk pengembangan aplikasi.
3.2.2. Bagian Perekonomian
Sebagian besar aplikasi yang dikelola Bagian Perekonomian belum ada keselarasan strategi
organisasi dengan aplikasi yang ada, perlu adanya peningkatan keselarasan strategi dengan
aplikasi yang ada, baru 1 yang selaras dengan strategi dan semua belum menunjukkan
dokumen strategi perusahaan dan dokumen manajemen resiko (Belum menyertakan
dokumen master plan yang menunjukkan keselarasan strategi dan belum terdapat dokumen
resiko), selain itu masih perlu peningkatan monitoring dan evaluasi tata Kelola.

Secara keseluruhan sudah dilakukan pemeliharaan layanan secara berkala dan dilakukan
evaluasi untuk pengembangan aplikasi

3.2.3. DINAS KESEHATAN

Seluruh aplikasi yang dikelola Dinas Kesehatan belum ada keselarasan strategi organisasi
dengan aplikasi yang ada, perlu adanya peningkatan keselarasan strategi dengan aplikasi yang
ada dan semua belum menunjukkan dokumen strategi perusahaan dan dokumen manajemen
resiko (Belum menyertakan dokumen master plan yang menunjukkan keselarasan strategi dan
belum terdapat dokumen resiko), selain itu masih perlu peningkatan monitoring dan evaluasi
tata Kelola.

Secara keseluruhan sudah dilakukan pemeliharaan layanan secara berkala dan dilakukan
evaluasi untuk pengembangan aplikasi

3.2.4. DINAS PENDIDIKAN

Terdapat 9 aplikasi yang dipunyai oleh Dinas Pendidikan, dari 9 aplikasi Terdapat 5 layanan
yang belum digunakan sehingga tidak dimasukkan dalam evaluasi.

Seluruh aplikasi yang dikelola Dinas Pendidikan belum ada keselarasan strategi organisasi
dengan aplikasi yang ada, perlu adanya peningkatan keselarasan strategi dengan aplikasi yang
ada dan semua belum menunjukkan dokumen strategi perusahaan dan dokumen manajemen
resiko (Belum menyertakan dokumen master plan yang menunjukkan keselarasan strategi dan
belum terdapat dokumen resiko), selain itu masih perlu peningkatan monitoring dan evaluasi
tata Kelola.
 Secara keseluruhan sudah dilakukan pemeliharaan layanan secara berkala dan dilakukan
evaluasi untuk pengembangan aplikasi

3.2.5. Balitbangda
Semua aplikasi yang dikelola oleh Balitbangda sudah terdapat keselarasan antara aplikasi yang
terbangun dengan master plan organisasi. Meskipun sudah terdapat keselarasan antara
aplikasi yang terbangun dengan master plan organisasi akan tetapi 50% belum menunjukkan
ketersediaan dokumen master plan serta seluruh aplikasi belum tersedia dokumen
manajemen resiko. Selain itu juga perlu peningkatan monitoring dan evaluasi tata Kelola

Secara keseluruhan sudah dilakukan pemeliharaan layanan secara berkala dan dilakukan
evaluasi untuk pengembangan aplikasi

3.2.6. BKAD
Semua aplikasi yang dikelola oleh BKAD Sudah terdapat keselarasan antara aplikasi yang
terbangun dengan master plan organisasi, akan tetapi belum mempunyai manajemen risiko,
meskipun sudah sudah melakukan proses monitoring dan evaluasi tata Kelola.

Secara keseluruhan perlu dilakukan pemeliharaan layanan secara berka;a dan dilakukan
evaluasi ntuk pengembangan aplikasi

3.2.7. Dinas KOMINFO

Seluruh aplikasi yang dikelola Dinas Kominfo sudah Sudah terdapat keselarasan antara aplikasi
yang terbangun dengan master plan organisasi, meskipun perlu adanya evaluasi secara
berkala terhadap kesesuaiannya. Dan seluruh aplikasi tersedia dokumen master plan. Seluruh
aplikasi tersedia dokumen manajemen resiko tinggal dilaksanakan dan dievaluasi , dan sudah
terdapat monitoring dan evaluasi tata Kelola

Secara keseluruhan sudah dilakukan pemeliharaan layanan secara berkala dan dilakukan
evaluasi untuk pengembangan aplikasi

3.2.8. Dinas Perhubungan

Aplikasi yang dikelola Dinas Perhubungan Sudah terdapat keselarasan antara aplikasi yang
terbangun dengan master plan organisasi dan dilakukan evaluasi secara berkala terhadap
kesesuaiannya, selain itu sudah terdapat manajemen risiko yang dilakukan. Dan sudah
dilakukan pemeliharaan layanan secara berkala dan dilakukan evaluasi untuk pengembangan
aplikasi

Meskipun terdapat keselarasan strategi organisasi dengan aplikasi akan tetapi belum
ditunjukkan ketersediaan dokumen yang menunjukkan keselarasan antara aplikasi yang
dibuat dengan strategi organisasi serta seluruh aplikasi belum tersedia dokumen manajemen
resiko.
 4. Hasil Audit Domain Fungsionalitas Layanan

4.1. Deskripsi Hasil Audit

Kebutuhan layanan aplikasi harus sesuai dengan kebutuhan proses bisnis ditunjukkan dengan
tersedia berbagai dokumen yang menunjang, diharapkan dengan terpenuhinya dokumen
yang diminta, fungsionalitas dan kinerja aplikasi bisa tercatat dengan baik.

Secara garis besar hasil audit dan rekomendasi domain Fungsionalitas Layanan adalah
sebagai berikut :
Sebagian besar layanan masih belum menyertakan perencanaan layanan, padahal diharapkan
dengan adanya dokumen ini perencanaan, penganggaran dan pengembangan serta
pemeliharaan layanan menjadi lebih optimal.
Selain itu ketersediaan dokumen teknis layanan seperti desain layanan, instalasi dan
konfigurasi serta spesifikasi kebutuhan layanan mayoritas masih belum tersedia. Hal ini dapat
berakibat berhentinya kegiatan pengembangan, terganggunya kegiatan pemeliharaan dan
kinerja layanan kurang optimal.

Temuan lainnya adalah Sebagian layanan tidak menyediakan dokumen penggunaan. Hal ini
dapat menyebabkan terganggunya operasional layanan jika terjadi pergantian personel.

Sebagian besar layanan masih belum menyertakan dokumen pengujian aplikasi, hal ini bisa
menyebabkan aplikasi yang dihasilkan kurang sesuai dengan kebutuhan (requirement) dan
juga tidak terdeteksinya kesalahan (fault) atau bug.

Sedangkan Hampir semua sudah tersedia source code aplikasi, hal ini akan mempermudah
jika terjadi pengembangan aplikasi ke depan.

Table 6. Hasil Audit Domain Fungsionalitas

4.1.1. Indikator Ketersediaan dokumen kebutuhan layanan OPD
Kebutuhan layanan aplikasi harus sesuai dengan kebutuhan proses bisnis ditunjukkan dengan
tersedia berbagai dokumen yang menunjang, salah satunya adalah dokumen perencanaan
kebutuhan layanan. Dokumen perencanaan kebutuhan layanan yang didalamnya berisi
kesesuaian dan keselarasan aplikasi dengan kebutuhan proses bisnis diharapkan dengan
adanya dokumen ini perencanaan, penganggaran dan pengembangan serta pemeliharaan
layanan menjadi lebih optimal.

Dari 58 aplikasi yang dilakukan audit masih terdapat 29 aplikasi belum tersedia dokumen
kebutuhan layanan, hal ini bisa menyebabkan perencanaan, penganggaran dan
pengembangan serta pemeliharaan layanan menjadi kurang optimal.

Table 7. Ketersediaan Dokumen Perencanaan Layanan

Ketersediaan Dok Kebutuhan Layanan OPD Sebelum

Membuat Aplikasi
2
Tidak ada
9
2
Terdapat dokumen
7
Terdapat dokumen, Dilaksanakan dan Dikelola 1
Dilaksanakan, Dikelola dan Dievaluasi 1

4.1.2. Indikator Ketersediaan dokumen user requirement

user requirement ialah suatu kebutuhan yang harus dimiliki seorang pengguna terhadap suatu
aplikasi. Ketersediaan dokumen user requirement dipastikan bahwa software yang dihasilkan
sesuai dengan kebutuhan (requirement).

Berdasarkan hasil audit, dari 58 aplikasi yang dilakukan audit masih terdapat 49 aplikasi belum
tersedia dokumen user requirement, ketidaktersediaan user requirement bisa menyebabkan
aplikasi kurang berjalan sesuai dengan kebutuhan sehingga aplikasi menjadi kurang optimal
atau bahkan tidak bisa digunakan.
 Table 8. Ketersediaan User Requirement

Ketersediaan Dokumen User Requirement

4
Tidak ada
9
Terdapat dokumen 7
Terdapat dokumen, Dilaksanakan dan Dikelola 0
Dilaksanakan, Dikelola dan Dievaluasi 1

4.1.3. Indikator Ketersediaan dokumen teknis Pengembangan Aplikasi

Dokumen teknis adalah dokumen perancangan aplikasi, desain aplikasi, instalasi dan
konfigurasi aplikasi serta spesifikasi teknis aplikasi.

Berdasarkan temuan hasil audit , ditemukan bahwa hampir sebagian (38 aplikasi ) belum
mempunyai dokumen teknis.
Table 9. Ketersediaan Dokumen Teknis

Ketersediaan Dokumen User Requirement

3
Tidak ada
8
1
Terdapat dokumen
7
Terdapat dokumen, Dilaksanakan dan Dikelola 1
Dilaksanakan, Dikelola dan Dievaluasi 2

4.1.4. Indikator Ketersediaan Dokumen penggunaan

Dokumen Penggunaan biasa disebut sebagai user guide, user guide berguna sebagai panduan
menggunakan aplikasi, panduan instalasi, konfigurasi dan Pengelolaan aplikasi. Pengguna
menggunakan dokumen ini sebagai panduan untuk mengetahui cara-cara penggunaan
aplikasi. Ketiadaan dokumen ini bisa menyebabkan fungsi aplikasi tidak bisa digunakan secara
optimal. Dari temuan hasil audit , ditemukan bahwa masih terdapat 22 aplikasi yang belum
mempunyai dokumen pengguna, hal ini bisa menyebabkan fungsi aplikasi tidak bisa digunakan
secara optimal. Selain itu hal ini dapat menyebabkan terganggunya operasional layanan
jika terjadi pergantian personel.
 Table 10. Ketersediaan Dokumen Pengguna

Ketersediaan Dokumen Pengguna

Tidak ada 22
Terdapat dokumen 36

4.1.5. Indikator Ketersediaan Source Code Aplikasi

Pembangunan aplikasi harus didokumentasikan dalam dokumen Prosedur Pembangunan
Aplikasi (System build procedures) dan tersedia source code aplikasi untuk pengembangan ke
depan. Dengan source code aplikasi akan mempermudah pengembangan aplikasi ke depan,
ketiadaan source code akan menjadi kendala jika terjadi pengembangan aplikasi ke depan.
Berdasarkan hasil audit, mayoritas sudah tersedia source code aplikasi, sisanya masih terdapat
13 aplikasi yang tidak tersedia source code.

Table 11. Ketersediaan Source Code

Ketersediaan Source Code

Tidak ada 13
Terdapat dokumen 45

4.1.6. Indikator Ketersediaan dokumentasi Pengujian Aplikasi

Pengujian Aplikasi adalah aktivitas-aktivitas yang bertujuan untuk mengevaluasi atribut-
atribut atau kemampuan sebuah program atau sistem dan penentuan apakah sesuai dengan
hasil yang diharapkan. Pengujian aplikasi bertujuan untuk menemukan cacat yang mungkin
ada dalam mengembangkan perangkat lunak, mendapatkan kepercayaan dan memberikan
informasi tentang tingkat kualitas, mencegah cacat dan memastikan bahwa aplikasi sudah
memenuhi proses bisnis. Uji coba terhadap aplikasi harus terdokumentasi dalam suatu test
plan, test design, test case, test procedures dan dokumen hasil test.

Berdasarkan hasil audit mayoritas aplikasi (54 aplikasi dari 58 aplikasi belum tersedia
dokumentasi hasil pengujian aplikasi.
 Table 12.Pengujian Aplikasi

Pengujian Aplikasi
Tidak ada 54
Terdapat dokumen 4

4.2. Detail Hasil Audit Per OPD

4.2.1. Dinas Pertanahan
Aplikasi yang dikelola oleh Dinas Pertanahan masih terdapat aplikasi yang belum membuat
dokumen kebutuhan layanan sebelum membuat aplikasi. Dan hampir semua aplikasi belum
memiliki dokumen user requirement, selain itu juga belum tersedia dokumen pengembangan
aplikasi. Dan juga masih terdapat aplikasi yang belum mempunyai user guide. Mayoritas
belum mempunyai source code aplikasi serta mayoritas belum mempunyai dokumentasi
pengujian aplikasi

4.2.2. Bagian Perekonomia

Semua aplikasi yang dikelola Bagian Perekonomian belum tersedia dokumen kebutuhan
layanan sebelum membuat aplikasi, hampir semua aplikasi belum memiliki dokumen user
requirement. Selain itu juga belum tersedia dokumen pengembangan aplikasi. Hampir semua
aplikasi yang belum mempunyai user guide, akan tetapi mayoritas aplikasi sudah tersedia
source code aplikasi, hanya 2 dari 7 aplikasi yang tidak tersedia source codenya . Semua
aplikasi belum mempunyai dokumentasi pengujian aplikasi

4.2.3. Dinas Kesehatan

Semua aplikasi yang dikelola oleh Dinas Kesehatan Belum terdapat dokumen kebutuhan
layanan, dan juga semua aplikasi belum memiliki dokumen user requirement sebelum
membuat aplikasi, Belum tersedia dokumen pengembangan aplikasi dan juga belum tersedia
user guide untuk semua aplikasi.
Semua aplikasi tersedia source code aplikasinya akan tetapi semua aplikasi belum
mempunyai dokumentasi pengujian aplikasi
4.2.4. Dinas Pendidikan
Semua aplikasi yang dikelola oleh Dinas Pendidikan belum terdapat dokumen kebutuhan
layanan, semua aplikasi belum memiliki dokumen user requirement sebelum membuat
aplikasi, dokumen pengembangan aplikasi juga belum tersedi, dan juga belum tersedia user
guide untuk semua aplikasi.Hampir Semua aplikasi sudah tersedia source code aplikasinya,
sedangkan pengujian aplikasi belum dilakukan

4.2.5. Balitbangda
Dari dua aplikasi yang dipunyai oleh Balitbangda, salah satu aplikasinya sudah terdapat
dokumen kebutuhan layanan, akan tetapi semua aplikasi belum memiliki dokumen user
requirement, selain itu juga belum tersedia dokumen teknis pengembangan aplikasi dan juga
belum tersedia source code aplikasinya. Semua aplikasi belum mempunyai dokumentasi
pengujian aplikasi. Seluruh aplikasi tersedia user guide untuk semua aplikasi.

4.2.6. BKAD
Semua aplikasi yang dikelola oleh BKAD semua memiliki dokumen yang dipersyaratkan tapi
bukti dokumen belum tersedia.

4.2.7. Dinas Kominfo

Hamper semua aplikasi yang dikelola Dinas Kominfo sudah tersedia dokumen perencanaan
dan buktinya juga ada tapi belum dilakukan evaluasi. Mayoritas belum mempunyai user
requirement, hanya 3 dari 28 aplikasi. Mayoritas tersedia dokumen teknis pengembagan
aplikasi dan terdapat bukti dokumennya. Semua aplikasi terdapat user guide dan terdapat
bukti dokumennya. Semua aplikasi terdapat source code dan terdapat bukti dokumennya
akan tetapi belum terdapat pengujian aplikasi

4.2.8. Dinas Perhubungan

Aplikasi yang dikelola oleh Dinas Perhubungan semua dokumen yang dipersyaratkan belum
tersedia.
LAMPIRAN 1. Form Audit Aplikasi Pemerintahan Kabupaten
Malang
 FORM SURVEI AUDIT TEKNIS

APLIKASI SPBE PADA PEMERINTAH KABUPATAN MALANG

Di isi satu-satu untuk masing-masing layanan

A PROFIL SISTEM ELEKTRONIK

1 Identitas Instansi *)
.

Data organisasi/unit kerja/satuan kerja yang bertanggung jawab terhadap layanan Sistem
Elektronik

Nama Satuan kerja :

No Telp :

Website :

2 Nama Internal *)
.
(Nama Sistem Elektronik yang hanya diketahui oleh pihak internal Instansi)

3 No Kode Aplikasi *)
.
(No Identitas Aplikasi)

4 No Register Aplikasi di Kominfo (Jika ada)

.
(No Registrasi Aplikasi di kominfo jika ada)

5 Nama Eksternal *)
.
(Nama Sistem Elektronik yang dikenal oleh pihak di luar Instansi Penyelenggara jika ada)
6 Deskripsi Aplikasi *)
.
(Deskripsi Aplikasi yang diaudit)

7 Alamat URL *)
.

8 Pengisi Lembar Evaluasi *)

.
(Nama Staff atau Pejabat)

Jabatan *)

9 Tanggal Pengisian *)
.
 DATA SISTEM YANG DIAUDIT

B DATA UMUM

1 Sasaran Pelayanan dari system yang diaudit **)

.
Pilih salah satu kategori target pengguna Sistem Elektronik :

Administrasi Pemerintahan (internal OPD)

Administrasi Pemerintahan (antar OPD)

Administrasi Pemerintahan (dengan Provinsi atau Pemerintah Pusat)

Layanan Publik

2 Pengguna Layanan
.

3 Dasar Hukum Layanan *)

.
Sebutkan kebijakan (peraturan perundangan seperti Peraturan Pemerintah, Peraturan
Pimpinan Daerah dls) yang mendasari pembuatan layanan

4 Kategori Akses **)

.
Pilih salah satu kategori akses

Melalui jaringan intra pemerintah

Internet (jalur publik)

Catatan:
*) isikan dibawah
**) Pilih salah satu coret yang tidak perlu
***) Pilih dan Isikan
 5 Kesediaan untuk dipublikasikan melalui Portal Layanan Publik **)
.
Ya

Tidak

6 Kategori Jenis Aplikasi

.
(Berdasarkan Perpres 95/2020 yaitu Aplikasi Umum/Khusus)

Aplikasi Umum, pilihlah kategori ruang lingkup aplikasi : **)

perencanaan;

penganggaran;

pengadaan barang dan jasa pemerintah;

akuntabilitas kinerja;

pemantauan dan evaluasi;

kearsipan;

kepegawaian; dan

pengaduan pelayanan publik.

Lainnya. (Isikan) ………………………….

Aplikasi khusus, pilih kategori Ruang Lingkup : **)

Jaminan Sosial

Komunikasi dan Informasi

Pariwisata

Pendidikan

Perhubungan

Catatan:
*) isikan dibawah
**) Pilih salah satu coret yang tidak perlu
***) Pilih dan Isikan
 Tempat Tinggal

Energi

Kesehatan

Lingkungan Hidup

Pekerjaan dan Usaha

Perbankan

Sumber Daya Alam

Pengajaran

sektor lainnya (isikan) ………….

7 Tingkat kematangan layanan ***)

.
Berdasarkan Fungsi (fitur) yang dimiliki Sistem Elektronik sesuai dengan tingkat
kematangan kapabilitas layanan (halaman 27 Permenpan RB 59/2020) :

Tingkat Informatif1

Tingkat interaksi2

Tingkat transaksi3

1 Jika aplikasi hanya dalam bentuk informasi satu arah (misal website tanpa interaksi)
2 Jika kriteria pertama dipenuhi dan mempunyai interaksi dua arah
3 Jika kriteria kedua terpenuhi dan terdapat transaksi yang menggunakan
sumberdaya/data
Catatan:
*) isikan dibawah
**) Pilih salah satu coret yang tidak perlu
***) Pilih dan Isikan
 Tingkat kolaborasi4

Tingkat Optimum5

8 Sistem Terkait *)
.
(Isi dengan satu atau lebih sistem elektronik lain yang berkaitan langsung dengan
sistem yang didaftarkan (jika ada))

9 Sertifikat
.
(Diisi semua sertifikasi yang terkait dengan Sistem Elektronik. Contoh sertifikasi yang
dapat dimasukkan yaitu: sertifikasi lulus audit, sertifikasi layanan publik terbaik di
kabupaten tertentu. (softcopy sertifikat dapat dilampirkan))

Nama Tangg Tangg

Institusi Tan al al Mas
(pemberi ggal Mulai Habis a No.
N Nama sertifikat Terb Berla Berlak Berl Sertifi Ruan
o Sertifikat ) it ku u aku kat Lingk

4 Jika kriteria ketiga terpenuhi dan terdapat integrasi/kolaborasi dengan layanan

lainnya
5 Jika kriteria keempat terpenuhi dan ada evaluasi continuous improvement
Catatan:
*) isikan dibawah
**) Pilih salah satu coret yang tidak perlu
***) Pilih dan Isikan
 1

4
*
)

*) Tambahkan sesuai dengan jumlah sertifikasi yang dimiliki

Catatan:
*) isikan dibawah
**) Pilih salah satu coret yang tidak perlu
***) Pilih dan Isikan
 C DATA PERANGKAT KERAS DAN PERANGKAT LUNAK

1. Perangkat Keras Utama

Data perangkat keras tempat Sistem Elektronik dipasang

(Minimal isi dengan 1 (satu) data Perangkat Keras Utama)

N Jenis Pemilik Penye Ba Ju Tipe Proc Kapasi Memo

o dia nd m esso tas ry
PC/Serv Milik
Data wi la r Hardis
er/Lainn Sendiri/Se
Center dth h k
ya **) wa **)
***)

3
*
)

Catatan:
*) Tambahkan sesuai dengan jumlah perangkat keras utama yang digunakan untuk operasional Sistem
Elektronik
**) Pilih salah satu
***) Isi kolom ini dengan nama Instansi penyedia data center (jika sewa)

1.1 Informasi Data Center

Penempatan aplikasi (pilih salah satu)
Di Data Center Dinas Kominfo Pemkot Pemerintahan Kabupaten Malang
Diluar Data Center Dinas Kominfo Pemkot Pemerintahan Kabupaten Malang

Jika Perangkat Keras Utama yang digunakan ada yang berupa server, dan penempatan di luar
data center yang disediakan selain DC Dinas Kominfo Pemkot Pemerintahan Kabupaten
Malang, isikan isian dibawah ini
 Lokasi

Nama Penyedia Data Center

Bandwidth

Apakah Server digunakan bersama dengan aplikasi lain?

1.2 Perangkat Khusus

Perangkat keras yang berfungsi spesifik sesuai dengan spesifikasi Sistem Elektronik (misal :
biometrik, camera, rfid reader, dll) yang mendukung aplikasi

No Jenis Tipe Keterang

an

3
*)

Catatan:
*) Tambahkan sesuai jumlah perangkat keras khusus yang ada

2. Perangkat Lunak Utama

Data perangkat lunak (aplikasi) utama yang menjalankan Sistem Elektronik (pilihan OS, Web
Server, Database, Bahasa pemrograman (framework), lainnya…)
a. Sistem Operasi dan versi :
 Missal : Windows Server 2004, Linux debian 10, dll Tuliskan
b. Web server dan versi :
Misal : IIS v??, Apache v??, nginx v?? dll Tuliskan
c. BasisData dan versi :
Missal : Oraclev??, SQL Serverv??, MySQL v??, DB2, Posgree v?? dll Tuliskan
d. Bahasa pemrograman dan versi :
Missal : php v5, python v?, java v?, perl v?, dll tuliskan
e. Jika menggunakan framework tuliskan framework yang dipakai :
misal : laravel, ci, Yii, jango dll (Tuliskan)

E Data Tenaga Pendukung Teknis

(Isi dengan data Pendukung Teknis tersedia untuk operasional Sistem Elektronik)
1. Tenaga Pendukung Teknis (pilihan) operator,programmer, database, data analis, system
analis
N Jenis Jumlah Kompetensi Status**)
o
(Pilih berdasarkan kategori jenis
tenaga ahli)

3
*
)

Catatan:
*)Tambahkan sesuai dengan jumlah dan jenis tenaga ahli
**) status :
Pilih salah satu status kepegawaian tenaga ahli yang tersedia:
- PNS
- Non-PNS penyedia (jika diambil dari rekanan/penyedia)
- Non-PNS non-rekanan (jika bukan dari rekanan misal pegawai kontrak)
-
F Penanggung Jawab
(Isi dengan data pejabat penanggung jawab Sistem Elektronik)

Nama Penanggung
Jawab *)

NIP *)

Nama Satuan Kerja *)

Alamat Satuan Kerja *)

Provinsi *)

Kota/Kabupaten *)

Kode Pos *)

No HP *)

Email *)

Catatan:
*) Kolom ini harus diisi

G Penanggung Jawab Teknis

Nama Penanggung
Jawab *)

NIP *)

Nama Satuan Kerja

*)

Alamat Satuan Kerja

*)

Provinsi *)

Kota/Kabupaten *)
Kode Pos *)

No HP *)

Email *)
 AUDIT SISTEM :

H Tata Kelola
1. Prinsip proses tata kelola
a. Apakah sudah terdapat keselarasan antara strategi organisasi (Visi misi) dan
pengembangan aplikasi yang dibuat ? **)

Tidak ada

Terdapat dokumen master plan

Terdapat dokumen master plan, Dilaksanakan dan Dikelola

Dilaksanakan, Dikelola dan Didefinisikan

b. Apakah terdapat dokumen manajemen resiko dalam pengelolaan aplikasi TIK

Tidak ada
Terdapat dokumen
Terdapat dokumen, Dilaksanakan dan Dikelola
Dilaksanakan, Dikelola dan Dievaluasi

c. Apakah Terdapat monitoring dan evaluasi dalam proses tata kelola ? **)

Tidak ada

Terdapat dokumen master plan

Terdapat dokumen master plan, Dilaksanakan dan Dikelola

Dilaksanakan, Dikelola dan Didefinisikan

2. Frekuensi pemeliharaan layanan

Tidak pernah
Sekali dalam 1 tahun
 Lebih satu kali dalam satu tahun
Lainnya (Tuliskan) …..

3. Evaluasi layanan (misal evaluasi untuk perencanaan dan pengembangan aplikasi kedepan,
evaluasi operasional aplikasi yang dilakukan oleh manajemen)
Tidak pernah
Sekali dalam 1 tahun
Lebih satu kali dalam satu tahun
Lainnya (Tuliskan) …..

4. Dokumen kontrak pengembangan aplikasi dengan pihak ketiga (jika pengembangan

aplikasi dibuat pihak ketiga)
Tidak ada
Terdapat dokumen
Terdapat dokumen, Dilaksanakan dan Dikelola
Dilaksanakan, Dikelola dan Dievaluasi

Isikan nama dokumen jika ada : ……

Lampiran 2. Tahapan Proses Audit

Tahap-tahapan dalam proses audit yang dilakukan :

1. Persiapan dan Penyamaan Persepsi : Mendefinisikan ruang lingkup pekerjaan audit,

mendiskusikan dan mencari kesepatakan ruang lingkup audit

2. Penyiapan Rencana Kerja dan SDM : Berdasarkan ruang lingkup disusun rencana kerja dan
kebutuhan sumber daya

3. Menyiapan Instrumen Audit : Menyiapkan instrument Audit berdasarkan ruang lingkup yang
sudah disepakati

4. Sosialiasi Pra Audit : Sosialiasi instrument Audit, Jadwal dan tata Cara Audit

5. Pelaksanaan Aduit : Melaksanakan Audit Sesuai waktu yang sudah disepakati

6. Penyiapan Report : Analisa Hasil Audit dan Rekomendasi

7. Diseminisi Hasil : Melaporkan Hasil Audit, rekomendasi dan Perbaikan ke depan

hasil audit bisa dipakai sebagai bahan untuk melakukan rapat tinjauan manajemen untuk
menyiapkan rencana perbaikan ke depan
Lampiran 3. Manajemen Resiko

Implementasi TIK melekat berbagai resiko (potensi ancaman, kerawanan dll) perlu
dikembangkan supaya tidak terjadinya gangguan terhadap aktivitas. Manajemen resiko
merupakan identifikasi terhadap kemungkinan kejadian yang tidak diinginkan. Perlu adanya
usaha untuk menentukan profil risiko yang dihadapi, prediksi risiko memetakan tingkat
dampak terhadap kelancaran pelaksanaan bisnis proses yang ada dalam unit kerja yang
bersangkutan serta membuat prioritas dan rencana aktivitas pengendaliannya dan melakukan
pemantauan dan pengawasan risiko.

Terdapat beberapa metode yang biasa dipakai salah satunya adalah metode Octave
(Operationally Critical Threat, Asset and Vulnerability Evaluation). Berikut adalah contoh
manajemen resiko berbasis metode OCTAVE. Tahapan metode OCTAVE bisa dilihat pada
gambar dibawah ini.

Gambar 1 Tahapan metode OCTAVE

Tahapan managemen resiko metode OCTAVE :

1. Membangun Aset Berbasis Ancaman Profil :Identuifikasi asset yang penting, kebutuhan
keamanan dan cara melindungi asset

2. Identifikasi Infrastruktur Vulnerabilities : diidentifikasi kelemahannya baik dari sisi teknologi

dan konfigurasi

3. Mengembangkan Strategi Keamanan dan Perencanaannya : identifikasi resiko terhadap

asset yang ada, mengukur tingkat resiko, strategi dan rencana mitigasi

Pengukuran tingakt resiko bisa menggunkan metode Failure Mode and Effect Analysis (FMEA)
dan Diagram Fishbone. Fungsi dari FMEA sendiri adalah mengidentifikasi kegagalan dalam
proses produksi yang bertujuan untuk menghitung RPN (Risk Priority Number) yang di dapat
dari hasil perhitungan Severity x Occurance x Detectability

Severity, merupakan penilaian yang berhubungan dengan seberapa besar kemungkinan

terjadinya dampak yang timbul akibat adanya kegagalan atau kecacatan yang terjadi, nilai
severity di hasilkan melalui kuisioner yang sudah di lakukan terhadap seluruh user yang
terlibat. Nilai range tergantung dari kuisioner yang kita siapkan. Terdiri atas rating 0-10; mulai
dari sangat buruk sampai sangat baik.
Occurrence, menilai seberapa sering kemungkinan penyebab kegagalan terjadi. Nilai
occurrence ini di berikan untuk setiap penyebab kegagalan. Terdiri dari rating 1-10, makin
sering penyebab kegagalan terjadi,makin tinggi nilai rating yang di berikan.

Detection, menilai seberapa jauh penyebab kegagalan dapat di deteksi.terdiri dari rating dari
1-10, semakin sulit mendeteksi penyebab kegagalan yang terjadi makin tinggi nilai rating
yang di berikan.

Risk Priority Number (RPN), merupakan perkalian dari rating Occurrence (O), Severity (S) dan
Detectability (D).Rumus RPN: RPN = O x S x D
Selajutnya adalah menentukan level berdsarkan nilai RPN, missal sebagai berikut :

Skala Level

>151 Sangat tinggi

100 - 150 Tinggi

51- 100 Sedang

20 – 50 Rendah

0 - 20 Sangat rendah

Berikut adalah Contoh form Manajamen resiko dan Tindakan mitigasinya.

Form Manajemen Resiko

Dan berikut adalah form mitigasi

Lampiran 4. Pengujian Aplikasi

Salah satu bentuk pengujian aplikasi adalah pengujian black box yang dilakukan untuk
mengamati hasil eksekusi melalui data uji dan memeriksa fungsional dari aplikasi. Berikut
adalah contoh Form Pengujian Black Box Aolikasi.

Contoh Form Pengujian Black Box Aplikasi

No. Skenario Test Hasil yang Hasil Kesimpulan

Pengujian Case Diharapkan Pengujian
1
2
3
….

Contoh Implementasi Form Pengujian Black Box Testing Login Admin