RANCANG BANGUN SISTEM INFORMASI
MONITORING DAN EVALUASI UNIVERSAL CHILD
IMMUNIZATION BERBASIS WEB PADA DINAS
KESEHATAN SURABAYA
TUGAS AKHIR
Program Studi: S1 Sistem Informasi
Oleh:
BADAR YASIFUN ALI 09.41010.0039
FAKULTAS TEKNOLOGI DAN INFORMATIKA
INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA 2016
x DAFTAR ISI
Halaman
ABSTRAK ... vii
KATA PENGANTAR ... viii
DAFTAR ISI ... x
DAFTAR TABEL ... xiv
DAFTAR GAMBAR ... xviii
DAFTAR LAMPIRAN ... xx
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang Masalah ... 1
1.2 Perumusan Masalah ... 3
1.3 Pembatasan Masalah ... 3
1.4 Tujuan Penelitian ... 4
1.5 Manfaat Penelitian ... 4
1.6 Sistematika Penulisan ... 5
BAB II LANDASAN TEORI ... 7
2.1 Pengertian Imunisasi dan Universal Child Immunization (UCI) ... 7
2.1.1 Indikator UCI ... 7
2.1.2 Cakupan Desa/Kelurahan UCI ... 9
2.2 Monitoring dan Evaluasi Program ... 11
2.2.1 Pemantauan Wilayah Setempat (PWS) ... 12
2.2.2 Pengawasan ... 13
2.2.3 Monitoring dan Evaluasi ... 14
xi
2.3.1 Komponen Sistem ... 16
2.3.2 Karakteristtik Sistem ... 17
2.3.3 Membuat Informasi ... 19
2.3.4 Nilai Informasi ... 19
2.3.5 Sumber Informasi ... 20
2.3.6 Kualitas Informasi ... 20
2.4 Dashboard ... 22
2.4.1 Tujuan Penggunaan Dashboard ... 22
2.4.2 Karakteristik Dashboard ... 23
2.4.3 Ciri-ciri Dashboard ... 25
2.4.4 Klasifikasi Dashboard ... 26
2.4.5 Kesalahan Umum Pembuatan Dashboard ... 28
2.5 Siklus Hidup Pengembangan Sistem ... 29
2.5.1 Elisitasi Kebutuhan ... 29
2.5.2 Analisis ... 30
2.5.3 Desain ... 33
2.5.4 Construction ... 36
2.5.5 Testing dan Implementasi ... 38
2.5.6 Maintenance ... 39
BAB III ANALISIS DAN PERANCANGAN SISTEM ... 40
3.1 Identifikasi Permasalahan ... 40
3.2 Analisis Permasalahan ... 48
3.2.1 Analisis Pada Proses Mencatat Form Harian ... 49
xii
3.2.3 Analisis Pada Proses Evaluasi ... 49
3.3 Solusi Permasalahan... 50
3.3.1 Kebutuhan Perangkat Lunak (Software Requirement) ... 50
3.3.2 Desain Sistem (Software Design) ... 67
3.3.3 Context Diagram ... 85
3.3.4 Data Flow Diagram ... 86
3.3.5 Entity Relationship Diagram ... 96
3.3.6 Struktur Basis Data ... 98
3.3.7 Perancangan Prosedur dan Program Unit ... 102
3.3.8 Program Unit ... 111
3.3.9 Program Pseudocode ... 112
3.3.10Desain Uji Coba Fungsional ... 114
3.3.11Desain Uji Coba Non-Fungsional ... 119
3.3.12Desain Implementasi Data ... 120
3.3.13Desain Arsitektur ... 125
BAB IV IMPLEMENTASI DAN EVALUASI ... 127
4.1 Implementasi ... 127
4.2 Penjelasan Penggunaan Aplikasi... 127
4.2.1 Bagian Imunisasi Dinas Kesehatan ... 128
4.2.2 Pengguna Sebagai Petugas Puskesmas ... 131
4.2.3 Pengguna Sebagai Bagian Dinas Kesehatan (Monitoring) .. 135
4.2.4 Pengguna KaSie Wabah Bencana ... 138
4.3 Uji Coba Fungsional ... 140
xiii
4.3.2 Uji Fungsional Bagian Imunisasi Dinas Kesehatan ... 143
4.3.3 Uji Fungsional Kepala Seksi Wabah Bencana ... 147
4.3.4 Uji Non-Fungsional ... 148
4.4 Evaluasi ... 151
4.4.1 Proses Monitoring dan Evaluasi ... 152
BAB V PENUTUP ... 153
5.1 Kesimpulan ... 153
5.2 Saran... ... 153
xiv
DAFTAR TABEL
Halaman
Tabel 2.1 Jadwal Pemberian Imunisasi Pada bayi ... 7
Tabel 2.2 Jadwal Pemberian Imunisasi Vaksin DPT & HB ... 8
Tabel 2.3 Jadwal Pemberian Imunisasi Pada Bayi Vaksin DPT/HB Kombo ... 8
Tabel 2.4 Flow Direction Symbol ... 33
Tabel 2.5 Processing Symbols ... 34
Tabel 2.6 Input / Output Symbol ... 35
Tabel 3.1 Proses Bisnis Berdasarkan Stakeholder ... 41
Tabel 3.2 Penjelasan Alir Proses Mencatat Form Harian ... 44
Tabel 3.3 Penjelasan Alir Proses Monitoring ... 46
Tabel 3.4 Penjelasan Alir Proses Evaluasi ... 48
Tabel 3.5 Data Bayi ... 51
Tabel 3.6 Data Puskesmas ... 52
Tabel 3.7 Data Vaksinasi ... 52
Tabel 3.8 Data pengguna ... 53
Tabel 3.9 Data Kecamatan ... 53
Tabel 3.10 Data Kelurahan ... 53
Tabel 3.11 Tabel Target Puskesmas... 54
Tabel 3.12 Tabel Realisasi vaksin ... 54
Tabel 3.13 Detil Kebutuhan Fungsi Mencatat PKM harian ... 58
Tabel 3.14 Detil Kebutuhan Fungsi Monitoring ... 59
Tabel 3.15 Detil Kebutuhan Set indikator puskesmas ... 63
xv
Halaman
Tabel 3.17 Hubungan Fungsional dan Non-Fungsional Sistem... 66
Tabel 3.18 Kebijakan Berdasarkan Stakeholder Sesuai Sistem Baru ... 68
Tabel 3.19 Alir Sistem Baru Mencatat Form Harian ... 70
Tabel 3.20 Alir Sistem Baru Monitoring ... 78
Tabel 3.21 Alir Sistem Baru Evaluasi ... 85
Tabel 3.22 Penjelasan DFD level 0 ... 88
Tabel 3.23 Penjelasan DFD Level 1 Set Target Puskesmas ... 91
Tabel 3.24 Penjelasan DFD level 1 Pencatatan Data Bayi ... 92
Tabel 3.25 Penjelasan DFD Level 1 Monitoring ... 94
Tabel 3.26 Penjelasan DFD level 1 Evaluasi ... 96
Tabel 3.27 Struktur Tabel M_Puskesmas ... 98
Tabel 3.28 Struktur Tabel Puskesmas ... 99
Tabel 3.29 Struktur Tabel Master Target ... 99
Tabel 3.30 Struktur Tabel data pengobatan ... 99
Tabel 3.31 Struktur Tabel M_Pengguna ... 100
Tabel 3.32 Struktur Tabel data kecamatan ... 100
Tabel 3.33 Struktur Tabel data kelurahan ... 100
Tabel 3.34 Struktur Tabel M_Jabatan ... 101
Tabel 3.35 Struktur Tabel Target_Puskesmas ... 101
Tabel 3.36 Struktur Tabel Transaksi Vaksin... 101
Tabel 3.37 Detil Form Set target Puskesmas ... 102
Tabel 3.38 Detil Form Monitoring UCI ... 105
xvi
Halaman
Tabel 3.40 Detil Form Evaluasi ... 110
Tabel 3.41 Program Unit Sistem ... 112
Tabel 3.42 Program Flowchart dan Pseudocode ... 112
Tabel 3.43 Skenario Testing Fungsi Pencatatan Harian ... 114
Tabel 3.44 Skenario Testing Fungsi Set Indikator UCI ... 115
Tabel 3.45 Skenario Testing Fungsi Monitoring UCI ... 116
Tabel 3.46 Skenario Testing Fungsi Evaluasi ... 118
Tabel 3.47 Skenario Uji Coba Non-Fungsional ... 119
Tabel 3.48 Skenario Testing Fungsi Pencatatan ... 120
Tabel 3.49 Skenario Testing Fungsi Set Indikator ... 121
Tabel 3.50 Skenario Testing Fungsi Set Indikator ... 122
Tabel 3.51 Skenario Testing Fungsi evaluasi ... 125
Tabel 3.52 Spesifikasi Kebutuhan Perangkat Keras ... 126
Tabel 4.1 Penjelasan Form Login ... 128
Tabel 4.2 Penjelasan Halaman Set Up User... 130
Tabel 4.3 Penjelasan Halaman Set Indikator Puskesmas ... 131
Tabel 4.4 Penjelasan Halaman Mencatat Bayi ... 133
Tabel 4.5 Penjelasan Halaman Mencatat Realisasi Vaksin Bayi ... 134
Tabel 4.6 Penjelasan Halaman PWS Puskesmas ... 135
Tabel 4.7 Penjelasan Monitoring UCI Puskesmas ... 136
Tabel 4.8 Penjelasan Monitoring UCI Kecamatan ... 137
Tabel 4.9 Monitoring indikator UCI pada setiap puskesmas. ... 138
xvii
Halaman
Tabel 4.11 Test Objective Plan (Petugas Imunisasi Puskesmas) ... 141
Tabel 4.12 Uji Coba Fungsional (Data Bayi)... 141
Tabel 4.13 Uji Coba Fungsional (Data Realisasi) ... 142
Tabel 4.14 Test Objective Plan (Bagian Imunisasi Dinkes) ... 144
Tabel 4.15 Uji Coba Fungsional (Data Puskesmas)... 144
Tabel 4.16 Uji Coba Fungsional (Data Set Indikator) ... 145
Tabel 4.17 Uji Coba Fungsional (Monitoring Cakupan Vaksin Puskesmas) ... 145
Tabel 4.18 Uji Coba Fungsional (Monitoring Cakupan Imunisasi Kecamatan) . 146 Tabel 4.19 Uji Coba Fungsional (Monitoring vaksin) ... 147
Tabel 4.20 Test Objective Plan (KaSie Waben) ... 147
Tabel 4.21 Uji Coba Fungsional (Mengukur Target)... 148
Tabel 4.22 Uji Coba Non-Fungsional (Correctness) ... 149
Tabel 4.23 Uji Coba Non-Fungsional (Security) ... 149
Tabel 4.24 Uji Coba Non-Fungsional (Interface) ... 150
Tabel 4.25 Uji Coba Non-Fungsional (Operability) ... 150
xviii
DAFTAR GAMBAR
Halaman
Gambar 2.1 Contoh Grafik PWS DPT-1 Puskesmas X tahun 2003 ... 13
Gambar 2.2 Simbol Eksternal Entity ... 35
Gambar 2.3 Simbol Data flow ... 36
Gambar 2.4 Simbol Process ... 36
Gambar 2.5 Simbol Data source ... 36
Gambar 3.1 Alir Proses Mencatat Form Harian ... 43
Gambar 3.2 Alir Proses Monitoring ... 45
Gambar 3.3 Alur Proses Evaluasi ... 47
Gambar 3.4 Alir Sistem Baru Proses Pencatatan ... 70
Gambar 3.5 Set Indikator Puskesmas ... 72
Gambar 3.7 Alir Sistem Baru Monitoring DPT ... 74
Gambar 3.8 Alir Sistem Baru Monitoring Polio ... 75
Gambar 3.9 Alir Sistem Baru Monitoring Campak ... 76
Gambar 3.10 Alir Sistem Baru Monitoring HB ... 77
Gambar 3 11 Alir Sistem Baru Evaluasi ... 84
Gambar 3.12 Context Diagram UCI ... 86
Gambar 3.13 DFD Level 0 ... 87
Gambar 3.14 DFD Level 1 Set target Puskesmas ... 90
Gambar 3.15 DFD level 1 Mencatat Realisasi ... 92
Gambar 3.16 DFD Level 1 Monitoring ... 93
xix
Halaman
Gambar 3.18 Conceptual Data Model (CDM) ... 97
Gambar 3.19 Physical Data Model (PDM) ... 97
Gambar 3.20 WEB Client ... 126
Gambar 4.1 Form Login ... 128
Gambar 4.2 Menu Yang Tersedia Bagian Imunisasi Dinkes ... 129
Gambar 4.3 Daftar Puskesmas ... 130
Gambar 4.4 Halaman Set Indikator Puskesmas ... 131
Gambar 4.5 Halaman Mencatat Bayi Baru ... 132
Gambar 4.6 Halaman Pemberian Jadwal Vaksin Bayi ... 132
Gambar 4.7 Halaman Tampilan Jadwal Vaksin Bayi ... 133
Gambar 4.8 Halaman Tampilan Realisasi Vaksin Bayi ... 134
Gambar 4.9 Halaman PWS Puskesmas ... 135
Gambar 4.10 Halaman Monitoring UCI Puskesmas ... 136
Gambar 4.11 Halaman Monitoring UCI Kecamatan ... 137
Gambar 4.12 Monitoring indikator UCI pada setiap puskesmas ... 138
Gambar 4.13 Evaluasi Backlog Fighting ... 139
Gambar 4.14 Detil Evaluasi Backlog Figthing ... 139
Gambar 4.15 Evaluasi Backlog Fighting (Cetak) ... 140
xx
DAFTAR LAMPIRAN
1 BAB I PENDAHULUAN
1.1 Latar Belakang Masalah
Dinas Kesehatan Kota Surabaya adalah suatu instansi pemerintahan Kota Surabaya yang bertanggung jawab terhadap kesehatan masyarakat Kota Surabaya. Sesuai dengan peraturan Walikota nomor 91 tahun 2008, Dinkes Kota Surabaya mempunyai tugas menyelenggarakan kewenangan daerah dalam bidang kesehatan dan tugas pembantuan yang diberikan oleh pemerintah. Dalam menjalankan tugasnya agar mencapai tujuan, Dinkes Kota Surabaya membaginya kedalam beberapa Bidang. Bidang Pengendalian Masalah Kesehatan, mempunyai beberapa seksi untuk menjalankan tugas pokoknya. Seksi tersebut adalah Seksi Wabah Bencana (Waben) Dinkes. Seksi waben pada Dinkes Kota Surabaya mempunyai tugas yaitu meningkatkannya kesehatan keluarga serta mencegah dan menanggulangi penyakit. Salah satunya merupakan dengan adanya imunisasi untuk mengetahui cakupan imunisasi atau Univesal Child Immunization (UCI) pada Dinkes Kota Surabaya, menurut Surat Keputusan Menteri Kesehatan Republik Indonesia Nomor 1611/MENKES/SK/XI/2005 tentang pedoman penyelenggaraan imunisasi.
tersebut akan diolah menjadi data PKM harian puskesmas selanjutnya dari data PKM harian akan diolah menjadi laporan Pemantauan Wilayah Setempat (PWS). Petugas puskesmas mengirimkan laporan pemantauan wilayah setempat (PWS) dan laporan ByName (laporan berdasarkan urutan nama) melalui email kepada bagian imunisasi Dinkes Kota Surabaya. Bagian imunisasi Dinkes Kota Surabaya melakukan koreksi data dari setiap laporan yang dikirimkan oleh pihak puskesmas melalui aplikasi Microsoft Excel. Hasil koreksi tersebut akan dugunakan untuk perhitungan pada setiap indikator UCI. Hasil perhitungan setiap indikator
di-monitoring untuk mendapatkan beberapa temuan yang tidak mencapai target yang
telah ditetapkan. Dari hasil temuan yang tidak mencapai target akan dibuat sebagai bahan evaluasi oleh bagian imunisasi Dinkes dan Kepala Sie Waben.
Kendala yang dialami Dinkes Kota Surabaya saat ini, seringnya terjadi keterlambatan dalam proses pengiriman laporan, yang seharusnya laporan masuk pada pihak Dinkes setiap satu bulan sekali pada tanggal 15 akan tetapi pada kenyataannya bisa mengalami keterlambatan sampai satu minggu sehingga menyebabkan pihak Dinkes mengalami keterlambatan waktu untuk proses
monitoring UCI. Pada saat melakukan monitoring banyak ditemukan kesalahan isi
laporan dari pihak puskemas ke Dinkes Kota Surabaya yang berdampak pada proses perhitungan indikator sehingga terjadi pemborosan waktu kerja. Bentuk penyajiannya tidak bisa dipantau setiap saat., Evaluasi dari proses perhitungan tidak dapat dilakukan saat itu juga sehingga tidak bisa mencapai tujuan dari Dinkes.
Immunization (UCI). Sistem Informasi ini akan diimplementasikan di seluruh
puskesmas kota Surabaya berbasis web. Agar Dinkes Kota Surabaya dapat memantau laporan berupa dashboard yang dikirim dari puskesmas secara langsung berdasarkan laporan yang sudah dibuat, sehingga dapat menunjukkan indikator capaian secara langsung. Dengan adanya Sistem Informasi Monitoring dan evaluasi Universal Child Immunization (UCI) dengan mengggunakan media
Website diharapkan mampu membantu kegiatan KaSie Waben dalam hal
monitoring dan evaluasi.
1.2 Perumusan Masalah
Berdasarkan latar belakang masalah diatas, bagaimana merancang dan membangun sistem informasi monitoring dan evaluasi Universal Child
Immunization berbasis web pada Dinas Kesehatan Kota Surabaya.
1.3 Pembatasan Masalah
Batasan permasalahan dalam penelitian ini adalah sebagai berikut:
1. Pada penelitian ini hanya membahas proses monitoring dan evaluasi sehingga tidak membahas proses tindak lanjut dari Dinkes Kota Surabaya.
2. Pada penelitian ini data yang diambil merupakan data dari puskesmas Pucang Sewu Surabaya.
3. Dalam penelitian ini pemberian vaksin imunisasi pada bayi berdasarkan puskesmas.
Kesehatan Republik Indonesia Nomor 828/MENKES/SK/IX/2008:12-15 tentang Standar Pelayanan Minimal Bidang Kesehatan di Kabupaten/Kota. 5. Dalam penelitian ini indikator yang digunakan merupakan berdasarkan Surat
Keputusan Menteri Kesehatan Republik Indonesia Nomor 1611/MENKES/SK/XI/2005:20-21.
6. Dalam tugas akhir ini UCI untuk Bayi 0 bulan sampai umur 11 Bulan. 7. Dalam tugas akhir ini penulis tidak membahas Wanita Usia Subur (WUS).
1.4 Tujuan Penelitian
Tujuan dari penelitian ini adalah menghasilkan Rancang Bangun Sistem Informasi Monitoring dan Evaluasi Universal Child Immunization Berbasis Web di Dinas Kesehatan Kota Surabaya, sehingga dapat mempercepat proses perhitungan setiap indikator UCI pada setiap Puskesmas oleh bagian imunisasi Dinkes dan dapat memberikan laporan umpan balik yang tepat kepada setiap Puskesmas.
1.5 Manfaat Penelitian
1.6 Sistematika Penulisan
Secara garis besar sistematika penulisan pada laporan ini adalah sebagai berikut:
Bab I : PENDAHULUAN
Pada bab ini akan dijelaskan mengenai latar belakang permasalahan yang terjadi, perumusan permasalahan yang didapat dari latar belakang, pembatasan permasalahan, tujuan dilakukannya penelitian, manfaat yang akan diberikan kepada stakeholder, serta penjelasan mengenai sistematika penulisan pada penelitian ini.
Bab II : LANDASAN TEORI
Pada bab ini akan dijelaskan mengenai teori-teori yang mendukung atau digunakan sebagai acuan pada saat atau sebelum melakukan penelitian.
Bab III : ANALISIS DAN PERANCANGAN SISTEM
Pada bab ini akan dijelaskan bagaimana awal proses penelitian ini dilakukan hingga menghasilkan sebuah perancangan yang diperoleh melalui beberapa tahapan seperti, pengumpulan data, identifikasi permasalahan, analisis permasalahan, solusi permasalahan, serta dilanjutkan sampai dengan perancangan sistem, seperti document
flow, system flow, data flow diagram, desain ERD baik conceptual
data model maupun physical data model, struktur basis data, dan
Bab IV : IMPLEMENTASI DAN EVALUASI
Pada bab ini akan dijelaskan mengenai implementasi program atau aplikasi yang sudah dibuat, berdasarkan hasil analisis hingga perancangan dan akan dilakukan uji coba fungsional maupun non fungsional terhadap perangkat lunak yang dibangun. Tahap akhir adalah melakukan evaluasi terhadap uji coba yang sudah dilakukan. Bab V : PENUTUP
7 BAB II
LANDASAN TEORI
2.1 Pengertian Imunisasi dan Universal Child Immunization (UCI)
Imunisasi adalah suatu cara untuk meningkatkan kekebalan seseorang secara aktif terhadap suatu penyakit, sehingga bila kelak ia terpapar dengan penyakit tersebut tidak akan menderita penyakit tersebut.
Universal Child Immunization (UCI) adalah suatu keadaaan tercapainya imunisasi dasar secara lengkap pada Semua Bayi. Bayi adalah anak dibawah umur 1tahun (Kepmenkes No. 1611/MENKES/SK/XI/2005: 9).
2.1.1 Indikator UCI
Indikator dalam proses perhitungan UCI sebagai berikut: (1) DPT-1 : jangkauan/aksesibilitas pelayanan, (2) hepatitis B1 < 7 hari : jangkauan/aksesibilitas pelayanan, (3) campak : tingkat perlindungan (efektivitas program), (4) polio-4 :tingkat perlindungan (efektivitas program), dan (5) drop out DPT-1 – campak : efisiensi/manajemen program. Pemberian imunisasi pada bayi dapat dilihat pada tabel 2.1.
Tabel 2.1 Jadwal Pemberian Imunisasi Pada bayi
Vaksin Pemberian Imunisasi
Selang waktu pemberian
(minimal)
Umur
(Bulan) Keterangan
BCG 1x - 0-11
DPT 3x
(1,2,& 3)
4 Minggu 2-11
Polio 4x
(1,2,3, & 4)
4 Minggu 0-11
CAMPAK 1x - 9-11
HB 3x
(1,2,& 3)
4 Minggu 0-11 Untuk bayi lahir di
Vaksin Pemberian Imunisasi
Selang waktu pemberian
(minimal)
Umur
(Bulan) Keterangan
oleh Nakes Pelaksanaan HB segera diberikan dalam 24jam pertama kelahiran, vaksin BCG, Polio, diberikan sebelum bayi pulang kerumah
Tabel 2.2 Jadwal Pemberian Imunisasi Vaksin DPT & HB
Umur Vaksin Tempat
Bayi Lahir di Rumah;
0 Bulan HB1 Rumah
1 Bulan BCG, Polio 1 Posyandu*
2 Bulan DPT1, HB2, Polio2 Posyandu*
3 Bulan DPT2,HB3,Polio3 Posyandu*
4 Bulan DPT3,Polio4 Posyandu*
9 Bulan Campak Posyandu*
Bayi Lahir di RS/RB/Bidan Praktek;
0 Bulan HB1,Polio1, BCG RS/RB/Bidan
2 Bulan DPT1, HB2, Polio2 RS/RB/Bidan#
3 Bulan DPT2,HB3,Polio3 RS/RB/Bidan#
4 Bulan DPT3,Polio4 RS/RB/Bidan#
9 Bulan Campak RS/RB/Bidan#
Tabel 2.3 Jadwal Pemberian Imunisasi Pada Bayi Vaksin DPT/HB Kombo
Umur Vaksin Tempat
Bayi Lahir di Rumah;
0 Bulan HB1 Rumah
1 Bulan BCG, Polio 1 Posyandu*
2 Bulan DPT1, HB kombo 1, Polio2 Posyandu*
Umur Vaksin Tempat
4 Bulan DPT3,HB kombo 3,Polio4 Posyandu*
9 Bulan Campak Posyandu*
Bayi Lahir di RS/RB/Bidan Praktek;
0 Bulan HB1,Polio1, BCG RS/RB/Bidan
2 Bulan DPT1,HB kombo 1, Polio2 RS/RB/Bidan#
3 Bulan DPT2,HB kombo 2,Polio3 RS/RB/Bidan#
4 Bulan DPT3, HB kombo 3,Polio4 RS/RB/Bidan#
9 Bulan Campak RS/RB/Bidan#
Keterangan :
- * : Tempat Pelayanan lain - # : Posyandu
Berdasarkan Kepmenkes (No.1611/MENKES/SK/XI/2005:20-21) untuk pemberian vaksin imunisasi setiap bayi.
2.1.2 Cakupan Desa/Kelurahan UCI
Pada sub bab ini akan dijelaskan tentang pengertian, definisi operasional, dan cara perhitungan rumus dari cakupan desa atau kelurahan UCI.
A. Pengertian
1. Bayi adalah anak berumur 29hari -11 bulan
2. Cakupan kunjungan bayi adalah Cakupan kunjungan bayi umur 29 hari – 11 bulan di sarana pelayanan kesehatan (Polindes, Pustu, Puskesmas, Rumah Bersalin dan Rumah Sakit) maupun di rumah, Posyandu, tempat penitipan anak, panti asuhan dan sebagainya melalui kunjungan petugas. 3. Setiap bayi memperoleh pelayanan kesehatan minimal 4 kali yaitu satu
4. Pelayanan Kesehatan tersebut meliputi pemberian imunisasi dasar (BCG, DPT/ HB1-3, Polio 1-4, Campak), stimulasi deteksi intervensi dini tumbuh kembang (SDIDTK) bayi dan penyuluhan perawatan kesehatan bayi
5. Penyuluhan perawatan kesehatan bayi meliputi: konseling ASI eksklusif, pemberian makanan pendamping ASI sejak usia 6 bulan, perawatan dan tanda bahaya bayi sakit (sesuai MTBS), pemantauan pertumbuhan dan pemberian vitamin A kapsul biru pada usia 6 – 11 bulan.
6. Indikator ini mengukur kemampuan manajemen program KIA dalam melindungi bayi sehingga kesehatannya terjamin melalui penyediaan pelayanan kesehatan.
B. Definisi Operasional
Cakupan kunjungan bayi adalah cakupan bayi yang memperoleh pelayanan kesehatan sesuai dengan standar oleh dokter, bidan, dan perawat yang memiliki kompetensi klinis kesehatan, paling sedikit 4 kali disatu wilayah kerja pada kurun waktu tertentu.
C. Cara Perhitungan Rumus 1. Rumus
2. Pembilang
Jumlah bayi yang memperoleh pelayanan kesehatan sesuai dengan standar, paling sedikit 4 kali di satu wilayah kerja pada kurun waktu tertentu. 3. Penyebut
Seluruh bayi lahir hidup di satu wilayah kerja dalam kurun waktu sama. Catatan:
Jika tidak ada data dapat digunakan angka estimasi jumlah bayi lahir hidup berdasarkan data BPS atau perhitungan CBR dikalikan jumlah penduduk. 4. Ukuran/Konstanta
Persentase (%)
2.2 Monitoring dan Evaluasi Program
diperlukan indikator. Hasil evaluasi sangat berguna untuk kepentingan perencanaan dan pengembangan program.
Salah satu fungsi penting dalam manajemen program adalah pemantuan. Dengan pemantauan kita dapat menjaga agar masing-masing kegiatan sejalan dengan ketentuan program. Pemantauan yang dimiliki oleh program imunisasi merupakan:
2.2.1 Pemantauan Wilayah Setempat (PWS)
Alat pemantuan ini berfungsi untuk meningkatkan cakupan, jadi sifatnya lebih memantau kuantitas program. Dipakai pertama kalinya di Indonesia pada tahun 1985 dan dikenal dengan nama Local Area Monitoring (LAM). LAM terbukti efektif kemudian diakui oleh WHO untuk diperkenalkan dinegara lain. Grafik LAM kemudian disempurnaan menjadi yang di kenal sekarang dengan Pemantauan Wilayah Setempat (PWS). Prinsip PWS:
1. Memanfaatkan data yang ada: dari cakupan/laporan cakupan imunisasi 2. Menggunakan indikator sederhana: tidak terlalu banyak :
a. DPT-1 : Jangkauan/aksesibilitas pelayanan
b. Hepatitis B1 < 7 hari : Jangkauan/aksesibilitas pelayanan c. Campak : Tingkat perlindungan (efektivitas program) d. Polio-4 :Tingkat perlindungan (efektivitas program)
e. Drop Out DPT-1 – Campak : Efisiensi/manajemen program 3. Dimanfaatkan untuk pengambilan keputusan setempat
4. Teratur dan tepat waktu: Setiap bulan
5. Lebih dimanfaatkan sendiri atau sebagai umpan balik untuk dapat mengambil tindakan daripada hanya dikirimkan sebagai laporan.
6. Membuat grafik yang jelas dan menarik untuk masing-masing indikator diatas, untuk memudahkan analisis.
Gambar 2.1 Contoh Grafik PWS DPT-1 Puskesmas X tahun 2003 2.2.2 Pengawasan
Definisi pengawasan yang dikemukakan oleh Robert J.Mockler berikut ini telah memperjelas unsur-unsur esensial proses pengawasan:
Pengawasan manajemen adalah suatu usaha sistematik untuk menetapkan standar pelaksanaan dengan tujuan-tujuan perencanaan, merancang sistem informasi umpan balik, membandingkan kegiatan nyata dengan standar yang telah ditetapkan sebelumnya, menentukan dan mengukur penyimpangan-penyimpangan, serta mengambil tindakan koreksi yang diperlukan untuk menjamin bahwa semua sumber daya perusahaan dipergunakan dengan cara paling efektif dan efisien dalam pencapaian tujuan-tujuan perusahaan. (Handoko, 2000: 359-361).
2.2.3 Monitoring dan Evaluasi
Monitoring dan Evaluasi adalah dua kata yang memiliki aspek kegiatan
yang berbeda yaitu kata monitoring dan evaluasi. Monitoring merupakan kegiatan untuk mengetahui apaka program yang dibuat itu berjalan dengan baik sebagaimana mestinya sesuai dengan yang direncanakan, adakah hambatan yang terjadi dan bagaimana para pelaksana program itu mengatasi hambatan tersebut.
monitoring terhadap sebuah hasil perencanaan yang sedang berlangsung menjadi
alat pengendalian yang baik dalam seluruh proses implementasi.
“Monitoring lebih menekankan pada pemantauan proses pelaksanaan”
(Departemen Pendidikan Nasional: 2001). Monitoring juga lebih ditekankan untuk tujuan supervisi.
kesenjangan (deviasi) antara pelaksanaan dengan standar dan rencana. Menurut Dunn (1981), monitoring mempunya empat fungsi, yaitu:
a. Ketaatan (compliance). Monitoring menentukan apakah tindakan administrator, staf, dan semua yang terlibat mengikuti standar dan prosedur yang telah ditetapkan.
b. Pemeriksaan (auditing). Monitoring menetapkan apakah sumber dan layanan yang diperuntukkan bagi pihak tertentu bagi pihak tertentu (target) telah mencapai mereka.
c. Laporan (accounting). Monitoring menghasilkan informasi yang
membantu “menghitung” hasil perubahan sosial dan masyarakat sebagai
akibat implementasi kebijaksanaan sesudah periode waktu tertentu.
d. Penjelasan (explanation). Monitoring menghasilkan informasi yang membantu menjelaskan bagaimana akibat kebijaksanaan dan mengapa perencaaa dan pelaksanaannya tidak cocok.
Penilaian (Evaluasi) merupakan tahapan yang berkaitan erat dengan kegiatan monitoring, karena kegiatan evaluasi dapat menggunakan data yang disediakan melalui kegiatan monitoring. Dalam merencanakan suatu kegiatan hendaknya evaluasi merupakan bagian yang tidak terpisahkan, sehingga dapat dikatakan sebagai kegiatan yang lengkap. Evaluasi diarahkan untuk mengendalikan dan mengontrol ketercapaian tujuan. Evaluasi berhubungan dengan hasil informasi tentang nilai serta memberikan gambaran tentang manfaat suatu kebijakan. Istilah evaluasi ini berdekatan dengan penafsiran, pemberian
angka dan penilaian. Evaluasi dapat menjawab pertanyaan “Apa pebedaan yang
Evaluasi bertujuan untuk mengetahui apakah program itu mencapai sasaran yang diharapkan atau tidak, evaluasi lebih menekankan pada aspek hasil yang dicapai (output). Evaluasi baru bisa dilakukan jika program itu telah berjalan dalam suatu periode, sesuai dengan tahapan rancangan dan jenis program yang dibuat dan dilaksanakan, misalnya disekolah, untuk satu caturwulan atau enam bulan atau satu tahun pelajaran.
2.3 Sistem Informasi
Sistem Informasi adalah kumpulan dari komponen yang saling terkait yang berjalan bersamaan secara kolektif untuk menjalankan input, proses, output penyimpanan dan pengendalian tidakan yang bertujuan untuk mengubah data kedalam sebuah informasi, sehingga informasi tersebut dapat digunakan untuk membantu dalam proses peramalan, perencanaan, pengendalian, koordinasi, pembuatan keputusan, dan kegiatan operasional di dalam organisasi. (Bocij, 2008:36).
2.3.1 Komponen Sistem
Pada point ini dapat dikemukakan bahwa istilah umum dari sistem terdiri dari lima komponen:
1. Input sistem dapat diartikan sebagai masukan dari proses yang akan
menghasilkan sebuah output.
2. Proses adalah pengubahan input menjadi sebuah output.
3. Output adalah hasil yang diciptakan oleh sistem.
4. Feedback mechanism adalah ketersediaan informasi pada kinerja sistem yang
dapat digunakan untuk mengatur perilaku dari sistem tersebut.
2.3.2 Karakteristtik Sistem
Berikut akan dijelaskan beberapa dari karakteristik sistem:
1. The component of System work towards a collective goal atau diketahui
sebagai tujuan dari sistem. Tujuan sistem secara normal sangat spesifik dan sering ditunjukkan dalam satu kalimat.
2. System do not operate in complete isolation maksud dari hal tersebut adalah
sistem hanya terdiri dari lingkungan sistem tersebut yang di dalamnya terdiri dari beberapa sistem lain dan pihak diluar sistem. Ruang lingkup sistem sendiri didefinisikan oleh batasan dari sistem itu sendiri. Apapun yang ada di luar batas merupakan bagian dari lingkungan sistem, apapun bentuk batasannya merupakan bagian dari sistem itu sendiri. Batasan juga menandakan tampilan antara sistem dan lingkungannya. Tampilan juga menggambarkan pertukaran antara sistem dan sistem yang lain.
3. System can be complex and can be made up of other, smaller system. Atau
4. Susbsystsem in a information system interact by exchanging information.
Atau yang dikenal dengan tampilan antar sistem. Untuk sistem informasi dan sistem bisnis mempunyai tampilan yang jelas sehingga penting untuk efisiensi organisasi.
5. The linkage or coupling betwen subsystem varies. Rangkaian ini
menggambarkan betapa erat keterkatian antar susbsistem. Hal ini merupakan prinsip fundamental dari teori sistem dan desain sistem informasi bisnis yang susbsistemnya seharusnya serangkaian.
Sistem atau subsistem yang tergantung pada sistem yang lain dikenal dengan rangkaian sistem terkait. Dalam beberapa kasus, keluaran dari satu sistem merupakan masukan dari sistem yang lain. Metode just in time yang digunakan oleh beberapa perusahaan manufaktur juga merupakan ilustrasi dari rangkaian sistem terkait.
Sistem yang tidak terkait merupakan sistem yang tingkat ketergantungannya dengan sistem yang lain lebih sedikit dan lebih mampu beradaptasi dengan situasi yang tidak diinginkan. Beberapa sistem cenderung mempunyai level
autonomi yang lebih tinggi, dan lebih memberikan kebebasan untuk
merencanakan dan mengendalikan aktivitasnya. Walaupun sistem yang tidak serangkaian lebih fleksibel dan adaptive daripada sistem yang serangkaian, akan tetapi kebebasan ini meningkatkan kemungkinan terjadinya ketidak efisienan dari sistem tersebut.
6. System are hierarchical. Hal ini seharunya membuat kita menyadari bahwa
2.3.3 Membuat Informasi
Proses data diperlukan untuk menempatkan data-data tersebut ke dalam konteks yang berarti sehingga data-data tersebut dapat lebih mudah untuk dimengerti. Terdapat beberapa proses data yang berbeda yang dapat digunakan untuk melakukan transformasi data ke dalam informasi. Berikut adalah beberapa contoh dari data proses:
1. Classification. Hal ini terdiri dari penempatan data ke dalam beberapa
kategori.
2. Rearranging/sorting. Hal ini terdiri dari pengumpulan data sehingga item dari
data tersebut dapat dikelompokkan menjadi beberapa bagian.
3. Aggregating. Hal ini terdiri dari ringkasan data.
4. Performing Calculation. Contoh dari proses data ini adalah perhitungan gaji
karyawan yang dihitung berdasarkan waktu mereka bekerja.
5. Selection. Hal ini terdiri dari pemilihan dari data item yang berdasarkan pada
kriteria pemilihan. (Bocij, 2008: 8-9).
2.3.4 Nilai Informasi
Nilai dari sebuah informasi terdiri dari dua hal yaitu:
1. Tangible value yang merupakan nilai atau keuntungan yang dapat diukur
secara langsung. Pada dasarnya hal ini berupa nilai finansial.
2. Intangible Value yang merupakan nilai atau keuntungan yang sulit untuk
2.3.5 Sumber Informasi
Informasi dapat dikumpulkan melalui dua hal yakni dengan cara formal
communication dan informal communication,
1. Formal communication terdiri dari informasi yang terdiri atas struktur yang
tetap sehingga komunikasi seperti ini sering dianggap kaku. Contoh dari komunikasi ini adalah laporan-laporan perusahaan yang sudah mempunyai format yang tetap.
2. Informal communication lebih mengambarkan informasi yang didapatkan dari
percakapan sehari-hari. (Bocij, 2008:10).
2.3.6 Kualitas Informasi
Pada dasarnya informasi memang memiliki karakteristik yang berbeda untuk menggambarkan kulitasnya. Perbedaan tersebut terletak pada informasi tersebut merupakan informasi yang baik atau informasi yang buruk. Baik atau buruknya informasi tersebut dapat diidentifikasi sesuai dengan atribut dari kualitas informasi tersebut.
1. Dimensi Waktu
a. Timeliness. Informasi seharusnya tersedia pada saat dibutuhkan.
b. Currency. Informasi seharusnya mampu memberikan data yang terbaru.
c. Frequency. Informasi seharusnya tersedia pada waktu yang regular.
d. Time Period. Informasi seharusnya mampu meng-cover sesuai dengan
periode waktunya. 2. Dimensi konten
a. Accuracy. Informasi yang kesalahannya hanya sebatas pada nilai
b. Relevance. Informasi yang disupply seharusnya relevant dengan sistuasi
yang ada dan mampu memenuhi kebutuhan informasi pengguna.
c. Completness. Seluruh informasi harus memenuhi kebutuhan informasi
pengguna dan seharusnya dapat melengkapi seluruhnya.
d. Conciseness. Hanya informasi yang relevan yang dapat memenuhi
kebutuhan informasi pengguna dan seharusnya tersedia dalam bentuk paling sederhana.
e. Scope. Ruang lingkup dari informasi yang disupply seharusnya sesuai
dengan informasi yang dibutuhkan oleh pengguna. 3. Dimensi form
a. Clarity. Informasi seharusnya dapat mewakili dalam bentuk yang sesuai
dengan tujuan pengguna.
b. Detail. Informasi seharusnya berisi tentang level detil yang sesuai untuk
memenuhi kebutuhan informasi pengguna.
c. Order. Informasi seharusnya tersedia sesuai dengan permintaan pengguna.
d. Presentation. Informasi seharusnya dapat mewakili dalam bentuk yang
sesuai dengan tujuan pengguna.
e. Media. Informasi seharusnya dapat terwakili melalui media yang tepat.
4. Karakteristik tambahan
Dari beberapa atribut yang telah digambarkan di atas, terdapat beberapa karakteristik tambahan antara lain:
mempercayai informasi yang mereka dapat melalui sumber yang akurat dan dipercaya sebelumnya.
b. Atribut dari kualitas informasi adalah informasi tersebut dapat dipercaya. Informasi seharusnya dapat dikemukakan oleh pengguna tanpa keraguan sehingga informasi tersebut dapat diandalkan dan tersedia saat dibutuhkan dengan konsistensi dan akurasi yang dapat dipercaya.
c. Informasi yang tersedia seharusnya sesuai dengan aktivitas pengguna. d. Informasi seharusnya diterima oleh orang yang memang membutuhkannya
sehingga informasi tersebut bernilai.
e. Informasi seharusnya dapat ditransmisikan melalui channels yang benar. (Bocij, 2008: 12-14).
Untuk implementasi pada Dinkes akan digunakan Web 1.0, dikarenakan Dinkes hanya membutuhkan web yang dapat menghubungkan informasi dan berbagi informasi sehngga tidak mengijinkan user untuk dapat berinteraksi.
2.4 Dashboard
Dashboard adalah tampilan visual dari informasi terpenting yang
dibutuhkan untuk mencapai satu atau beberapa tujuan. Pemberian poin penting diatur dalam satu tampilan sehingga informasi dapat di-monitoring dengan mudah (Few, 2006).
2.4.1 Tujuan Penggunaan Dashboard
Dashboard adalah tampilan visual dari informasi terpenting yang
diatur dalam satu tampilan sehingga informasi dapat di-monitoring dengan mudah (Few, 2006). Tujuan dalam penggunaan Dashboard, yaitu:
a. Mengkomunikasikan Strategi
Mengkomunikasikan strategi dan tujuan yang dibuat oleh eksekutif, kepada semua pihak yang berkepentingan, sesuai dengan peran dan levelnya dalam organisasi.
b. Me-monitor dan Menyesuaikan Pelaksanaan Strategi
Me-monitor pelaksanaan dari rencana strategi yang telah dibuat memungkinkan eksekutif untuk mengidentifikasi permasalahan kritis dan membuat strategi untuk mengatasinya.
c. Menyampaikan Wawasan dan informasi ke semua pihak
Menyajikan informasi menggunakan grafik, simbol, bagan dan warna yang memudahkan pengguna dalam memahami informasi secara benar.
2.4.2 Karakteristik Dashboard
Karakteristik dashboard operasional yaitu:
a. Model pemrosesan yang berdsarkan kejadian yaitu menangkap kejadian setiap saat dari beberapa sistem yang mencakup dan mempengaruhi proses bisnis. b. Aturan bisnis yang kuat yaitu mengijinkan penggunanya membuat peringatan,
target, ambang untuk nilai kerja individu.
c. Dashboard bisnis yang user friendly yaitu memperbarui nilai sebagai aliran
d. Sebuah sistem aliran kerja yang bergabung dan bekerja sama yang mengijinkan penggunanya untuk melalui proses secara formal dan informasi, yang dengan proses itu pengguna dapat berkolaborasi mendiskusikan hasilnya. Karakteristik dashboard menurut Hariyanti, yaitu:
a. Synergetic
Ergonomis dan memiliki tampilan visual yang mudah dipahami oleh pengguna. Dashboard mensinergikan informasi dari berbagai aspek yang berbeda dalam satu layar.
b. Monitor
Menampilkan KPI yang diperlukan dalam pembuatan keputusan dalam domain tertentu, sesuai dengan tujuan pembangunan dashboard tersebut.
c. Accurate
Informasi yang disajikan harus akurat dengan tujuan untuk mendapatkan kepercayaan dari penggunanya.
d. Responsive
Merespon threshold yang telah didefinisikan, dengan memberikan alert (seperti bunyi alarm, blinker, email) untuk mendapatkan perhatian pengguna terhadap hal-hal yang kritis.
e. Timely
f. Interactive
Pengguna dapat melakukan drill down dan mendapatkan informasi yang lebih detail, analisis sebab akibat dan sebagainya.
g. More Data History
Melihat tren sejarah KPI contohnya perbandingan jumlah pencapaian penjualan periode saat ini dengan beberapa tahun yang lalu, untuk mengetahui apakah kondisi sekarang lebih baik atau tidak.
h. Personalized
Penyajian informasi spesifik untuk setiap jenis pengguna sesuai domain, tanggung jawab, hak akses, dan batasan akses data.
i. Analitycal
Fasilitas untuk melakukan analisis, seperti analisis sebab akibat.
j. Collaborative
Fasilitas pertukaran catatan (laporan)
k. Trackability
Memungkinkan setiap pengguna untuk mengkustomisasi nilai yang akan dilacaknya. (Hariyanti, 2008:7).
2.4.3 Ciri-ciri Dashboard
Dashboard yang didesain baik, akan menampilkan informasi yang:
a. Luar biasa terorganisir dengan baik.
d. Ditampilkan secara ringkas, kadang dalam media kecil yang mengkomunikasikan data dan pesan tersebut dengan jelas dan langsug pada intinya. (Few, 2006).
2.4.4 Klasifikasi Dashboard
Adapun klasifikasi dashboard akan dijelaskan sebagai berikut:
1. Dashboard untuk tujuan Strategi
a. Mendukung manajemen level strategis.
b. Informasi untuk membuat keputusan bisnis, memprediksi peluang, dan memberikan arahan pencapaian tujuan strategis.
c. Fokus pada pengukuran kinerja high-level dan pencapaian tujuan strategis organisasi.
d. Mengadopsi konsep Balance Score Card.
e. Informasi yang disajikan tidak terlalu banyak dan disajikan secara ringkas. f. Informasional disajikan dengan mekanisme yang sederhana, melalui
tampilan yang “ unidirectional”.
g. Tidak didesain untuk berinteraksi, dalam melakukan analisis yang lebih detail.
h. Tidak memerlukan realtime.
2. Dashboard untuk Taktikal
a. Mendukung manajemen level taktikal.
b. Memberikan informasi yang diperlukan oleh analis untuk mengetahui penyebab suatu kejadian.
d. Dengan fungsi drill-down dan navigasi yang baik.
e. Memiliki konten informasi yang lebih banyak (analisis perbandingan, pola/tren, evaluasi kinerja).
f. Menggunakan media penyajian yang “cerdas”, yang memungkinkan
pengguna melakukan anlisis terhadap data yang kompleks. g. Didesain untuk berinteraksi dengan data.
h. Tidak memerlukan data realtime.
3. Dashboard untuk operasional
a. Mendukung manajemen level operasional.
b. Memberikan informasi mengenai aktifitas yang sedang terjadi, beserta perubahannya secara realtime untuk memberikan kewaspadaan terhadap hal-hal yang perlu direspon secara cepat.
c. Fokus pada monitoring aktifitas dan kejadian yang berubah secara konstan.
d. Informasi disajikan spesifik, tingkat detailnya cukup dalam. e. Media penyajian sederhana.
f. Alert disajikan dengan cara yang mudah dipahami, dan mampu menarik
perhatian pengguna.
g. Bersifat dinamis, sehingga memerlukan realtime.
h. Didesain untuk berinteraksi dengan data, untuk mendapatkan informasi yang lebih detail, maupun informasi pada level yang lebih atas.
belum terpenuhi dapat segera dilakukan evaluasi guna untuk mengambil keputusan.
2.4.5 Kesalahan Umum Pembuatan Dashboard
Beberapa hal dibawah ini merupakan 13 kesalahan umum pada pembuatan
dashboard (Few, 2006)
1. Melebihi batas pada satu layar monitor komputer. Hal ini mengacu pada tampilan dashboard.
2. Menyediaakan data yang tidak memadai.
3. Menampilkan detail atau presisi yang berlebihan: dashboard hampir selalu memerlukan informasi tingkat tinggi untuk mampu mendukung penggunanya untuk peninjauan cepat.
4. Memilih ukuran kurang tepat.
5. Memilih media tampilan yang tidak tepat atau salah memilih media. (bar, pie,
circle atau radar).
6. Menyajikan variasi berbeda yang sia-sia
7. Menggunakan media tampilan yang desainya payah. 8. Menampilkan kuantitas data secara tidak akurat.
9. Mengatur tampilan data dengan payah. Dashboard pada dasarnya menampilkan informasi yang banyak dengan tampilan seminimalis mungkin. 10.Menyortir data penting secara tidak efektif atau tidak sama sekali. Dashboard
11.Mengacaukan tampilan dengan dekorasi yang tak perlu. Sabaiknya tampilan
tidak terlalu “wah”, hal ini akan menyebabkan mata penggunanya mudah lelah
dikemudian hari.
12.Salah satu berlebihan menggunakan warna, gunakan warna yang tepat. 13.Mendesain tampilan yang tidak atraktif seperti tidak ada Combobox-nya
2.5 Siklus Hidup Pengembangan Sistem
Siklus hidup pengembang sistem atau Software Development System Life
Cycle (SDLC) adalah proses mengembangkan atau mengubah suatu sistem
perangkat lunak dengan mengguanakan model-model dan metodologi yang digunakan orang untuk mengembangkan sistem-sistem perangkat lunak sebelumnya (berdasarkan best practice atau cara-cara yang sudah teruji baik) (Chandra, 2012 : 13).
2.5.1 Elisitasi Kebutuhan
Elisitasi atau pengumpulan kebutuhan merupakan aktivitas awal dalam proses rekayasa perangkat kebutuhan. Sebelum kebutuhan dapat dianalisis, dimodelkan, atau ditetapkan, kebutuhan harus dikumpulkan melalui proses elisitasi. Elisitasi kebutuhan adalah sekumpulan aktivitas yang ditujukan untuk menemukan kebutuhan suatu sistem melalui komunikasi dengan pelanggan, pengguna sistem dan pihak lain yang memiliki kepentingan dalam pengembangan sistem.
a. Mengetahui masalah apa saja yang perlu dipecahkan dan mengenali batasan-batasan sistem. Proses-proses dalam pengembangan perangkat lunak sangat ditentukan oleh seberapa dalam dan luas pengetahuan developer tentang permasalahan.
b. Mengenali siapa saja para stakeholder, yaitu setiap pihak yang memiliki kepentingan terhadap sesuatu, dimana dalam konteks perangkat lunak adalah proyek pengembangan perangkat lunak itu sendiri, beberapa yang dapat dikatakan sebagai stakeholder antara lain adalah konsumen atau klien yang membayar sistem, pengembang yang merancang, membangun, dan merawat sistem, dan pengguna yang berinteraksi dengan sistem untuk mendapatkan hasil kerja mereka.
c. Mengenali tujuan dari sistem yaitu sasaran-sasaran yang harus dicapai. Tujuan merupakan sasaran sistem yang harus dipenuhi, penggalian high level goals di awal
proses pengembangan sangatlah penting karena brtujuan lebih terfokus pada ranah
masalah dan kebutuhan stakeholder dari pada solusi yang dimungkinkan untuk
masalah tersebut (Chandra, 2012 : 12-14).
2.5.2 Analisis
Analisis adalah penguraian dari suatu sistem informasi yang utuh kedalam bagian-bagian komponennya dengan maksud untuk mengidentifikasikan dan mengevaluasi permasalahan-permasalahan, kesempatan-kesempatan, hambatan-hambatan yang terjadi dan kebutuhan-kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikannya.
penting karena kesalahan di dalam tahap ini akan menyebabkan juga kesalahan ditahap selanjutnya (Jogiyanto, 2005: 129- 150).
1. Langkah-langkah Analisis Sistem
Langkah-langkah di dalam tahap analisis sistem hampir sama dengan langkah-langkah yang dilakukan dalam mendefinisikan proyek-proyek sistem yang akan dikembangkan di tahap perencanaan sistem.
Di dalam tahap analisis sistem terdapat langkah-langkah dasar yang harus dilakukan oleh analis sistem sebagai berikut ini:
a. Identify, yaitu mengidentifikasi masalah
b. Understand, yaitu memahami kerja dari sistem yang ada
c. Analyze, yaitu menganalisis sistem
d. Report, yaitu membuat laporan hasil analisis
2. Mengidentifikasi Masalah dan Analisis
Merupakan langkah pertama yang dilakukan dalam tahap analisis sistem. Masalah dapat didefinisikan sebagai suatu pertanyaan yang diinginkan untuk dipecahkan. Tugas-tugas yang harus dilakukannya adalah sebagai berikut ini. a. Mengidentifikasi penyebab masalah.
b. Mengidentifikasi titik keputusan.
c. Mengidentifikasi personil-personil kunci
3. Memahami Kerja dari Sistem yang Ada
bagaimana sistem yang ada beroperasi. Untuk mempelajari operasi dari sistem ini diperlukan data yang dapat diperoleh dengan cara melakukan penelitian.
4. Menganalisis Hasil Penelitian
Langkah ini dilakukan berdasarkan data yang telah diperoleh dari hasil penelitian yang telah dilakukan. Menganalisis hasil penelitian sering sulit dilakukan oleh analis sistem yang masih baru. Pengalaman menunjukkan bahwa banyak analis sistem yang masih baru mencoba untuk memecahkan masalah tanpa menganalisisnya.
5. Membuat Laporan Hasil Analisis
Setelah proses analisis sistem ini selesai dilakukan, tugas berikutnya dari analis sistem dan teamnya adalah membuat laporan hasil analisis. Laporan ini diserahkan kepada steering commitee yang nantinya akan diteruskan ke manajemen. Tujuan utama dari penyerahan laporan ini kepada manajemen adalah: a) Pelaporan bahwa analisis telah selesai dilakukan;
b) Meluruskan kesalah-pengertian mengenai apa yang telah ditemukan dan dianalisis oleh analis sistem tetapi tidak sesuai menurut manajemen;
c) Meminta pendapat-pendapat dan saran-saran dari pihak manajemen;
2.5.3 Desain
Menurut John Burch & Gary Grudnitski, desain adalah penggambaran, perencanaan dan pembuatan sketsa atau pengaturan dari beberapa elemen yang terpisah ke dalam satu kesatuan yang utuh dan berfungsi.
Analis sistem dapat mendesain model dari sistem informasi yang diusulkan dalam bentuk physical system dan logical model. Bagan alir sistem (system
flowchart) merupakan alat yang tepat digunakan untuk menggambarkan physical
system.
Logical model dari sistem informasi lebih menjelaskan kepada user
bagaimana nantinya fungsi-fungsi di sistem informasi secara logika akan bekerja.
Logical model dapat digambarkan dengan menggunakan diagram arus data (data
flow diagram). (John Burch & Gary Grudnitski,1986 : 461).
1. Flowchart
a. Flow Direction Symbol
Tabel 2.4 Flow Direction Symbol
Simbol arus / flow, yaitu menyatakan jalannya arus suatu proses
Simbol connector, berfungsi menyatakan sambungan dari proses ke proses lainnya dalam halaman yang sama.
b. Processing Symbols
Tabel 2.5 Processing Symbols
Simbol process, yaitu menyatakan suatu tindakan (proses) yang dilakukan oleh komputer
Simbol manual, yaitu menyatakan suatu tindakan (proses) yang tidak dilakukan oleh komputer
Simbol decision, yaitu menunjukkan suatu kondisi tertentu yang akan menghasikan dua kemungkinan jawaban : ya / tidak.
Simbol preparation, yaitu menyatakan penyediaan tempat penyimpanan suatu pengolahan untuk memberi harga awal
Simbol terminal, yaitu menyatakan permulaan atau akhir suatu program.
Simbol offline-storage, menunjukkan bahwa data dalam simbol ini akan disimpan ke suatu media tertentu
c. Input/Output Symbol
Tabel 2.6 Input / Output Symbol
Simbol input-output menyatakan proses
input atau output tanpa tergantung jenis
peralatannya
Simbol storage menyatakan input berasal dari disk atau output disimpan ke disk Simbol document mencetak keluaran dalam bentuk dokumn (melalui printer) Simbol display mencetak keluaran dalam layar monitor.
2. Data Flow Diagram
DFD adalah diagram yang menggunakan notasi-notasi ini untuk menggambarkan arus dari data sistem, sekarang di kenal dengan nama diagram arus data (data flow diagram). DFD sering digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem baru yang akan di kembangkan secara logika tanpa mempertibangkan lingkungan fisik dimana data tersebut mengalir.
a. External Entity
External entity merupakan kesatuan di lingkungan luar sistem yang dapat
berupa orang, organisasi, atau sistem lainnya yang berada di lingkungan luarnya yang akan memberikan input atau menerima output dari sistem.
b. Data Flow
Data flow menunjukkan arus dari data yang berupa masukan untuk
sistem atau hasil dari proses sistem dan dapat berbentuk sebagai berikut ini.
Gambar 2.3 Simbol Data flow
c. Process
Process adalah kegiatan atau kerja yang dilakukan oleh orang, mesin atau
komputer dari hasil suatu arus data yang masuk kedalam proses untuk dihasilkan arus data yang akan keluar dari proses.
Gambar 2.4 Simbol Process
d. Data Store
Data store adalah simpanan dari data yang berupa, suatu file database di
sistem komputer, arsip atau catatan manual, dan suatu tabel acuan manual.
Gambar 2.5 Simbol Data source 2.5.4 Construction
Software construction lebih diartikan sebagai pembuatan detail dari suatu
pekerjaan, menciptakan satu software yang penting yang dikombinasikan dengan
debuging. Software construction lebih sering dihubungkan dengan proses desain dan proses testing. Hal ini dikarenakan proses tersebut saling ketergantungan satu sama lain, dimana software construction merupakan keluaran dari desain software dan juga sebagai masukan dari software testing. Software construction bertipikal memproduksi volume konfigurasi item yang lebih tinggi dan juga dibutuhkan dalam mengelola sebuah software proyek (file sumber, isi, test cases, dll) (England, John Wiley & Sons, 2004: 65-67)
1. Software Contsruction Fundamentals
Pada tahap pertama, dilakukan pendefinisian dasar tetang prinsip-prinsip yang digunakan dalam proses implementasi seperti minimalisasi kompleksitas, mengantisipasi perubahan, dan standar yang digunakan.
2. Managing Costruction
Bagian ini mendefeinisikan tentang model implementasi yang digunakan, rencana implementasi, dan ukuran pencapaian dari implementasi tersebut.
3. Practical Considerations
Bagian ini membahas tentang desain implementasi yang digunakan, bahasa pemrograman yang digunakan, kualitas dari mplementasi yang dilakukan, proses pengetesan dan integritas.
Dalam proses pengimplementasian ini, digunakan beberapa aplikasi pendukung yaitu:
a. Bahasa Pemrograman PHP
program PHP, sebuah website akan lebih interaktif dan dinamis. (Madcoms, 2011: 186).
b. Database MySQL
Database MySQL adalah jenis database yang sangat populer dan digunakan pada
banyak website di internet sebagai bank data, selain itu Database MySQL juga dapat
dijalankan dibeberapa platform, antara lain linux, windows, dan sebagainya (Madcoms,
2011 : 215).
2.5.5 Testing dan Implementasi
Tahap ini mendemonstrasikan sistem perangkat lunak yang telah selesai dibuat untuk dijalankan, apakah telah sesuai dengan kebutuhan yang telah dispesifikasikan dan dapat diadaptasi pada lingkungan sistem yang baru. Tahapan ini tertuang dalam suatu dokumen Test Plan, yang dimulai dari membuat Software
Testing fundamentals yang berisi tentang penjelasan penting mengenai
terminology testing, kemudian selanjutnya merancang Test Levels yang terbagi antara target pengetesan dan objektif dari pengetesan. Pada tahap berikutnya adalah mendefinisikan Test Techniques, yaitu tentang bagaimana teknik yang digunakan termasuk dasar-dasar pengetesan berdasarkan intuisi dan pengalaman serta teknik pengetesan secara teknik coding, teknik kesalahan, teknik penggunaan, dan teknik terkait lainnya. Tahap selanjutnya adalah mendefinisikan
Test – Related Measures, yaitu ukuran-ukuran pencapaian testing yang telah
2.5.6 Maintenance
Pada tahap ini akan dilakukan pendeskripsian pekerjaan untuk mengoperasikan dan memelihara sistem informasi pada lingkungan pengguna termasuk implementasi akhir dan proses peninjauan kembali. Pemeliharaan sistem ini terdiri dari beberapa jenis yaitu:
a. Corrective, yaitu memperbaiki desain dan error pada program.
b. Adaptive, yaitu memodifikasi sistem untuk beradaptasi dengan perubahan
lingkungan.
c. Perfective, yaitu melibatkan sistem untuk menyelesaikan masalah baru atau
mengambil kesempatan untuk penambahan fitur.
d. Preventive, yaitu menjaga sistem dari kemungkinan masalah di masa yang
akan datang.
Prosedur pemeliharaan tersebut disusun dalam beberapa tahapan. Tahap awal adalah menyusun software maintenance fundamentals yang berisi tentang dasar-dasar pemeliharaan, segala yang dibutuhkan untuk melakukan pemeliharaan, dan ketgori pemeliharaan. Selanjutnya adalah mendefinisikan Key
Issues in Software Maintenance, yang berisi tentang teknik pemeliharaan,
40 BAB III
ANALISIS DAN PERANCANGAN SISTEM
Pada bab ini membahas tentang identifikasi permasalahan, analisis permasalahan, solusi permasalahan dan perancangan sistem dalam Rancang Bangun Sistem Informasi Monitoring dan Evaluasi Universal Child Immunization Berbasis Web. Dalam melakukan identifikasi dan analisis permasalahan menggunakan teknik wawancara dan observasi yang dilakukan di Dinas Kesehatan Kota Surabaya. Adapun hasil dari wawancara dan observasi berikut ini.
3.1 Identifikasi Permasalahan
Identifikasi permasalahan diperoleh berdasarkan proses wawancara pada perusahaan, identifikasi dilakukan yaitu untuk menemukan titik permasalahan yang terjadi pada perusahaan. Analisis yang dilakukan yaitu menggunakan model
value chain. Model value chain merupakan model yang akan digunkan untuk
menganalisis aktifitas-aktifitas spesifik bisnis yang terjadi yang akan menciptakan nilai dan keuntungan kompetitif bagi organisasi. Pada setiap langkah yang diambil pada suatu segmen, akan berdampak pada keseluruhan proses. Jadi dapat dikatakan bahwa setiap segmen saling memiliki keterkaitan dengan yang lain.
Dengan melakukan analisis mulai dari aktivitas Inbound Logistic sampai
Service, akan diperoleh sebuah kesimpulan bahwa permasalahan utama yang
terjadi pada Dinkes Kota Surabaya adalah pada bagian outbound logistic. Pada saat ini Dinkes Kota Surabaya belum tersedia bentuk penyajian monitoring secara
lama. Permasalahan lain adalah pada saat melakukan evaluasi tidak dapat segera dilakukan.
Tahapan selanjutnya adalah dengan melakukan analisis permasalahan. Analisis permasalahan digunakan untuk mendefinisikan suatu permasalahan dan cara mengatasi permasalahan tersebut. Dari hasil pengumpulan data yang dilakukan, diketahui beberapa dokumen mengenai peran (role), tanggung jawab (responsibility), aturan (rule), kebijakan (policy) serta stakeholder atau pengguna yang terlibat dengan sistem yang sudah ada saat ini, yaitu Pegawai imunisasi Puskesmas, Bagian Imunisasi Dinkes, dan KaSIE WaBen. Untuk penjelasan lengkapnya dapat dilihat pada lampiran 3 Secara garis besar proses bisnis perencanaan monitoring dan evaluasi pada Dinas Kesehatan dimulai dari pencatatan form harian yang dilakukan oleh pihak Bagian Imunisasi Puskesmas yang dilanjutkan dengan monitoring dan pengelolaan data yang dilakukan oleh Bagian Imunisasi Dinkes, dan proses evaluasi yang dilakukan oleh KaSIE WaBen Dinkes.
Sebelum menggambarkan proses bisnis menggunakan desain flowchart, perlu diketahui terlebih dahulu mengenai peran (role), aturan (rule) dan kebijakan (policy) yang ada pada perusahaan, lebih lengkapnya bisa dilihat pada tabel 3.1.
Tabel 3.1 Proses Bisnis Berdasarkan Stakeholder
Stakeholder Proses Bisnis Phase Rule Policy
Petugas Imuniasasi Puskesmas
Pencatatan 1 - -
Petugas
Imunisasi Dinas Kesehatan
Monitoring 2 R.1.1 BCG
Stakeholder Proses Bisnis Phase Rule Policy R.3.2 POLIO (4x
selang waktu 4 minggu)
R.4.2 Campak (1x bulan ke 9)
R.5.2 HB (3x selang waktu 4 minggu) Merupakan
prosentase cakupan dalam triwulan pada Setiap
indikator imunisasi - Triwulan 1 hasil kurang dari 22% maka Sistem akan menampilkan warning
- Triwulan 2 hasil kurang dari 45% maka Sistem akan menampilkan warning
- Triwulan 3 hasil kurang dari 67% maka Sistem akan menampilkan warning
- Triwulan 4 hasil kurang dari 80% maka Sistem akan menampilkan warning
Dikarenakan pada periode tersebut cakupan UCI belum mencapai target dan adanya kemungkinan bayi belum menerima imunisasi pada periode tersebut
Stakeholder Proses Bisnis Phase Rule Policy
KaSie Waben Evaluasi 3. - -
Dari peran (role), aturan (rule) dan kebijakan (policy) yang didapatkan, selanjutnya adalah menggambarkan kedalam bentuk flowchart, sehingga diharapkan desain yang akan dibuat sesuai dengan peran, aturan, dan kebijakan yang ada di perusahaan. Serta dengan digambarkan kedalam flowchart, proses bisnis mengenai monitoring dan evaluasi dapat mudah untuk dipahami, Adapun proses saat ini akan dijelaskan lebih detil untuk masing-masing pengguna sistem, dengan tujuan untuk dapat dengan mudah mengetahui proses-proses yang harus dieliminasi, ditambahkan atau diintegrasikan dengan sistem yang baru nantinya, sehingga sistem yang akan dibuat sesuai dengan kebutuhan pengguna.
A. Alir Proses Mencatat Form Harian Saat Ini
Berikut ini merupakan alir sistem yang lebih detil untuk Alir Proses Mencatat form harian. Dimana hasilnya dapat dilihat pada gambar 3.1.
Proses Pencatatan data UCI pada Puskesmas Bagian Puskemas
(imunisasi)
Kader Posyandu/Pasien Kepala Puskesmas
P
ha
se
Start
1. Proses Pencatatan
Data Bayi Imunisasi
Data PKM Harian
2.Proses Pembuatan laporan
PWS dan By Name
Laporan PWS dan By Name
Laporan PWS dan By Name ACC
ya
End Form data Bayi
ACC ?
R.1
Tidak
Adapun penjelasan dari alir proses mencatat form harian yang sesuai dengan gambar 3.1 dapat dilihat pada tabel 3.2.
Tabel 3.2 Penjelasan Alir Proses Mencatat Form Harian Phase No.
Proses
Nama Proses Input Proses Output
1 2 Proses Pencatatan Data Bayi
Data Bayi
Pada Proses ini dimulai dari pencatatan data bayi yang imunisasi pada setiap hari dan akan dibuatkan laporan Data PKM Harian
Data PKM Harian
3 Proses Pembuatan Laporan PWS dan ByName
Data PKM Harian
Pada Proses ini berjalan pada saat data PKM harian tersebut akan diolah berdasarkan dari nama Bayi yang nantinya akan jadi laporan ByName dan juga diolah berdasarkan wilayah lahir bayi
4 Proses melakukan ACC dokumen PWS dan ByName
Laporan PWS dan ByName
Proses ini menjelaskan tentang koreksi yang dilakukan oleh Kepala Bagian Puskesmas sebelum nantinya akan dikirim kepada bagian
Phase No. Proses
Nama Proses Input Proses Output
Surabaya
B. Alir Proses Monitoring Saat Ini
Berikut ini merupakan alir sistem yang lebih detil untuk Alir Proses
monitoring UCI. Hasilnya dapat dilihat pada gambar 3.2.
Monitoring UCI
Bagian Imunisasi Dinas Kesehatan Kepala Bagian Wabah Bencana
P
h
a
se
Start
Laporan PWS dan By Name (ACC
Puskesmas)
1. Proses koreksi data dan Perhitungan Indikator UCI Setiap Puskesmas di Surabaya
Laporan PWS dan By Name (Koreksi)
End Laporan PWS (FIX)
ACC ? R.2
YA Tidak
Gambar 3. 2 Alir Proses Monitoring
Tabel 3.3 Penjelasan Alir Proses Monitoring Phase No.
Proses
Nama Proses Input Proses Output
2 1 Koreksi data Laporan dan Proses perhitungan indikator
UCI setiap
puskesmas di Surabaya PWS dan
Proses ini berjalan ketika laporan PWS dan ByName dikirim oleh pihak puskesmas kepada bagian Imunisasi selanjutnya laporan tersebut akan dikoreksi (data Bayi) oleh pihak imunisasi Dinas Kesehatan Surabaya setelah di koreksi kebenaran data laporan maka bagian imunisasi akan menghitung indikator UCI pada setiap puskemas.
Laporan PWS dan ByName (Koreksi)
Decision Laporan PWS dan ByName (Koreksi)
Setelah proses perhitungan indikator maka bagian Imunisasi Dinas Kesehatan Surabaya akan menyerahkan Laporan PWS dan ByName (Koreksi2) kepada kepala Wabah Bencana Dinas Kesehatan Surabaya yang selanjutnya akan dikoreksi
perhitungannya dan diskusikan
Phase No. Proses
Nama Proses Input Proses Output
jika ada kesalahan perhitungan maka laporan tersebut akan direvisi lagi oleh bagian Imunisasi Dinas Kesehatan Surabaya
C. Alir Proses Evaluasi Saat Ini
Berikut ini merupakan alir sistem yang lebih detil untuk Alir Proses Evaluasi. Hasilnya dapat dilihat pada gambar 3.3
Evaluasi UCI
Bagian Imunisasi Dinkes Kepala Waben
P
h
a
se
Start
1.Membuat Laporan Evaluasi
Laporan Umpan Balik (FIX)
End ACC ?
R.3
Tidak
Laporan Umpan Balik
Ya
Gambar 3. 3 Alur Proses Evaluasi
Tabel 3. 4 Penjelasan Alir Proses Evaluasi Phase No.
Proses
Nama Proses Input Proses Output
3 1 Membuat
Dari Laporan PWS (FIX) maka Bagian Imunisasi Dinas Kesehatan akan membuat laporan evaluasi (laporan Umpan Balik) untuk memberi tindakan pada kelurahan yang belum masuk pada cakupan
UCI
Laporan Umpan Balik
ACC Laporan Umpan Balik
Laporan Umpan Balik
Pada proses ini laporan umpan balik akan di diskusikan dan ACC oleh Kepala Waben. sistem tersebut maka analisis dilakukan untuk mengetahui kebutuhan dari masing-masing pengguna. Selain itu dari hasil analisis pada setiap alir sistem, dapat diketahui proses yang akan dilakukan eliminasi, proses yang dilakukan integrasi menjadi satu fungsi, atau membangun fungsi baru, hal ini dilakukan untuk membangun fungsi sesuai dengan kebutuhan masing-masing pengguna sistem nantinya.
3.2 Analisis Permasalahan
yang sesuai dengan proses-proses tersebut. Analisis kebutuhan ini diperlukan untuk merancang perangkat lunak yang memiliki fungsi-fungsi yang sesuai dengan kebutuhan masing-masing pengguna sistem. Analisis ini dilakukan pada setiap pengguna yang secara langsung berinteraksi dengan sistem nantinya. Berikut ini merupakan hasil analisis kebutuhan untuk masing-masing pengguna.
3.2.1 Analisis Pada Proses Mencatat Form Harian
Dalam proses pelaporan yang dilakukan oleh pihak puskesmas yang dikumpulkan pada setiap triwulan sering terjadi keterlambatan pengumpulan laporan yang disebabkan oleh pihak puskemas tersebut, hal seperti ini tentu saja akan membutuhkan waktu yang lama dalam pengumpulan data pada dinas kesehatan untuk dijadikan untuk kebutuhan monitoring dan evaluasi.
3.2.2 Analisis Pada Proses Monitoring
Dalam proses Monitoring yang dilakukan oleh Bagian Imunisasi Dinkes akan memakan banyak waktu karena saling menunggu data laporan antara petugas Imunisasi puskesmas dengan Bagian Imunisasi Dinkes, untuk proses selanjutnya yaitu laporan dari puskesmas akan dientry ulang oleh Petugas Imunisasi Dinkes ke aplikasi MS-Excel, sehingga hal tersebut juga rawan terjadi kesalahan entry yang dilakukan oleh Petugas Imunisasi dan juga akan berpengaruh pada proses pengelolaan data jika data yang dientry salah.
3.2.3 Analisis Pada Proses Evaluasi
