TA : Rancang Bangun Sistem Informasi Monitoring dan Evaluasi Universal Child Immunization Berbasis Web Pada Dinas Kesehatan Surabaya.

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

Halaman Lampiran 1 Struktur Organisasi Dinas Kesehatan Kota Surabaya ... 156 Lampiran 2 Peranan dan Tanggung Jawab Stakeholder ... 156 Lampiran 3 Hasil Wawancara ... 159

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.

Saat ini, Dinkes Kota Surabaya telah menjalankan program pemantauan UCI, yang disesuaikan dengan surat keputusan Menteri Kesehatan Republik Indonesia Nomor 1611/MENKES/SK/IX/2005. Dinkes Kota Surabaya dibantu oleh puskesmas dalam hal operasional pemantauan UCI. Proses monitoring dimulai dari pencatatan setiap data bayi oleh petugas puskesmas, dari data

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.

Berdasarkan permasalahan di atas, maka Dinkes Kota Surabaya membutuhkan sistem informasi Monitoring dan Evaluasi Universal Child

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.

4. Acuan kebijakan pada penelitian ini berdasarkan Surat keputusan Menteri Kesehatan Republik Indonesia Nomor 1611/MENKES/SK/XI/2005:1-22 tentang pedoman penyelenggaraan Imunisasi dan Surat Keputusan Menteri

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

Pembuatan Sistem Informasi monitoring dan evaluasi ini di harapkan dapat membantu Kepala Seksi Waben dalam melakukan monitoring dan evaluasi terhadap pelaksanaan program Universal Child Immunization (UCI), sehingga dapat membantu seksi Wabah Bencana dalam mencapai target yang sudah ditentukan oleh Kementerian Kesehatan Republik Indonesia. Melalui Surat Keputusan Menteri Kesehatan Republik Indonesia : 1611/MENKES/SK/XI/2005.

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

Pada bab ini akan dijelaskan mengenai kesimpulan yang diperoleh dari penelitian ini, yaitu hasil dari evaluasi, serta saran terkait dengan sistem yang dikembangkan.

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

kali pada umur 29 hari-3 bulan, 1 kali pada umur 3-6 bulan, 1 kali pada umur 6-9 bulan, dan 1 kali pada umur 9-11 bulan.

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

Berikut adalah perhitngan dari rumus cakupan kunjungan bayi pada satu wilayah.

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

Menurut Surat Keputusan Menteri Kesehatan Republik Indonesia Nomor (Kepmenkes No.1611/MENKES/SK/XI/2005: 42-43). Monitoring dan evaluasi merupakan salah satu fungsi manajemen untuk menilai keberhasilan pelaksanaan program. Monitoring dilaksanakan secara berkala dan terus menerus, untuk dapat segera mendeteksi bila ada masalah dalam pelaksanaan kegiatan yang telah direncanakan, supaya dapat dilakukan tindakan perbaikan segera. Evaluasi dilakukan setelah suatu jarak-waktu (interval) lebih lama, biasanya setiap 6 bulan s/d 1 tahun. Dengan evaluasi dapat dinilai sejauh mana tujuan dan target yang telah ditetapkan sebelumnya dicapai. Dalam mengukur keberhasilan tersebut

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

a. Teratur untuk menghindari hilangnya informasi penting b. Tepat waktu agar tidak terlambat dalam mengambil keputusan.

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

Pengawasan dapat didefinisikan sebagai proses untuk “menjamin” bahwa tujuan tujuan organisasi dan manajemen tercapai. Ini berkenan dengan cara-cara membuat kegiatan yang sesuai perencanaan. Pengertian ini menunjukkan adanya hubungan sangat erat antara perencanaan dan pengawasan. Seperti terlihat dalam kenyataan, langkah awal proses pengawasan adalah sebenarnya langkah perencanaan, penetapan tujuan, standar atau sasaran pelaksanaan antara kegiatan. Karena sulit untuk membedakan antara rencana, standar atau apa itu 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.

Proses dasar dalam monitoring ini meliputi tiga tahap yaitu: (1) menetapkan standar pelaksanaan; (2) pengukuran pelaksanaan; (3) menentukan

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 dibuat”. (William N Dunn, 2000).

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.

5. Jika perubahan dibutuhkan oleh sistem, maka control mechanism akan melakukan pengaturan yang sesuai. (Bocij, 2008: 37).

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

dikenal dengan subsistem. Sistem tersusun dari satu atau beberapa subsistem yang disebut dengan supra sistem. Tujuan dari subsistem adalah untuk mendukung tujuan suprasistem yang lebih luas. Sistem yang melakukan interaksi dengan lingkungannya disebut dengan sistem terbuka. Sistem terbuka ini mempengaruhi perubahan dari lingkungan sistem tersebut. Kebanyakan sistem informasi adalah sistem terbuka karena sistem informasi menerima masukan dan memberikan reaksi. Hal yang tidak biasa adalah secara keseluruhan sistem tertutup tidak melakukan interaksi dengan lingkungannya.

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:

a. Bagian penting dari informasi adalah confidence dalam hal sumber dari informasi tersebut didapat. Pengguna akan lebih memilih menerima dan

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

kejadian melalui sistem dan menempatkan nilai tersebut dalam hubungan dengan menghubungkan ke pencapaian bisnis.

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

Menampilkan informasi teknik yang diperlukan untuk pengambilan keputusan.

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.

b. Meringkas, terutama dalam bentuk ringkasan dan bentuk pengecualian. c. Spesifik dan disesuaikan untuk user dan tujuan dashboard.

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.

c. Fokus pada proses analisis untuk menemukan penyebab dari suatu kondisi atau keadian tertentu.

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.

Untuk penyajian di Dinkes, dashboard yang akan digunakan adalah jenis operasional karena dalam hal ini Dinkes membutuhkan data yang realtime yang dapat digunakan untuk memonitoring, sehingga bila diketahui ada indikator yang

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

yang baik adalah menonjolkan data yang lebih penting dibanding yang lain.sehingga pengguna langsung melihatnya.

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.

Sejalan dengan proses rekayasa kebutuhan secara keseluruhan, elisitasi kebutuhan bertujuan untuk:

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.

Tahap analisis sistem dilakukan setelah tahap perencanaan dan sebelum tahap desain sistem. Tahap analisis merupakan tahap yang kritis dan sangat

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

Langkah ke dua dari tahap analisis sistem adalah memahami kerja dari sistem yang ada. Langkah ini dapat dilakukan dengan mempelajari secara terinci

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;

d) Meminta persetujuan kepada pihak manajemen untuk melakukan tindakan selanjutnya (dapat berupa meneruskan ke tahap desain sistem atau mengehntikan proyek bila dipandang tidak layak lagi) (Jogiyanto, 2005: 130- 149).

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.

Simbol off-page connector, menyatakan sambungan dari proses ke proses lainnya dalam halaman yang berbeda.

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

Simbol manual-input, memasukkan data secara manual dengan menggunakan online keyboard

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

Bahasa Pemrograman PHP adalah bahasa pemrograman yang bekerja dalam sebuah webserver. Script-script PHP harus tersimpan dalam sebuah server dan dieksekusi atau diproses dalam server tersebut. Dengan menggunakan

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

dilakukan untuk kemudian dievaluasi kembali. Tahap terakhir adalah mendefinisikan test Process yang berisi tentang aktivitas testing. (England, John Wiley & sons, 2004 : 73-74).

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,

manajemen pemeliharaan dan biaya, serta ukuran pemeliharaan perangkat lunak. Tahap selanjutnya adalah mendefinisikan proses dan aktivitas pemeliharaan tersebut ke dalam Maintenance Process. (England, John Wiley & Sons, 2004: 90-91).

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

R 2.2 DPT (3x selang waktu 4 minggu)

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 Laporan PWS dan ByName (ACC Puskesmas)

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 imunisasi Dinas Kesehatan Laporan PWS dan ByName (ACC Puskesmas)

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

Adapun penjelasan dari alir proses mencatat form harian yang sesuai dengan tabel 3.3.

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 ByName Laporan PWS dan ByName (ACC Puskesmas) 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 ACC Laporan PWS (FIX)

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

Adapun penjelasan dari alir proses mencatat form harian yang sesuai dengan gambar 3.3 dapat dilihat pada tabel 3.4.

Tabel 3. 4 Penjelasan Alir Proses Evaluasi Phase No.

Proses

Nama Proses Input Proses Output

3 1 Membuat

Laporan Evaluasi ACC Laporan PWS (FIX) 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.

Laporan Umpan Balik (FIX)

Pada gambar alir sistem yang sudah dibahas sebelumnya yaitu gambaran mengenai alir sistem yang sedang berjalan pada perusahaan saat ini. Dari alir 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

Setelah diketahui proses atau alir sistem yang dilakukan oleh masing-masing pengguna, maka proses berikutnya adalah melakukan analisis kebutuhan

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

Dalam proses evaluasi ini membutuhkan banyak waktu, dikarenakan untuk bisa melakukan evaluasi dibutuhkan data dari bagian imunisasi puskesmas dan juga laporan dari Bagian Imunisasi Dinkes jika terjadi revisi. Bagian imunisasi

Dinkes akan saling menunggu data antara Bagian imunisasi Dinkes dengan KaSie WaBen, KaSie WaBen diharuskan mendapat hasil evaluasi yang tepat sasaran sehingga hal ini akan dibutuhkan data yang benar-benar akurat dari laporan-laporan yang sudah dikumpulkan oleh Bagian imunisasi Dinkes.

3.3 Solusi Permasalahan

Setelah dilakukan pengumpulan data melalui proses wawancara dan observasi, pengolahan data dari hasil observasi, dilanjutkan dengan melakukan identifikasi dan analisis permasalahan, didapatkan suatu permasalahan yang harus diselesaikan dengan memberikan solusi yang sesuai dengan permasalahan yang ada. Dalam menyelesaikan permasalahan, solusi yang diberikan adalah dengan membangun aplikasi yang dapat menghubungkan pihak Petugas Imunisasi puskesmas dengan Bagian Imunisasi DinKes dan KaSIE WaBen untuk memberikan data monitoring secara realtime kepada Dinkes Kota Surabaya dan juga data yang akurat guna melakukan evaluasi dalam pengembangan program kedepan.

Dalam membangun sebuah aplikasi sebagai solusi pada permasalahan yang ada Dinkes Kota Surabaya yaitu dengan melalui beberapa proses tahapan. Tahapan pengembangan aplikasi tersebut yaitu terdiri atas:

3.3.1 Kebutuhan Perangkat Lunak (Software Requirement)

Langkah awal dalam membangun sebuah aplikasi yaitu dengan menganalisa kebutuhan perangkat lunak, hal ini dilakukan agar aplikasi yang dibangun sesuai dengan kebutuhan pengguna. Dalam melakukan identifikasi kebutuhan perangkat lunak, ada beberapa tahapan yaitu:

A. Elisitasi Kebutuhan (Requirement Elicitation)

Elisitasi kebutuhan atau pengumpulan kebutuhan adalah aktivitas awal untuk proses rekayasa kebutuhan (Requirement Engineering). Proses elisitasi dilakukan yaitu dengan cara wawancara dan observasi awal, namun yang dilakukan wawancara hanya kepada stakeholder yang terkait saja. Sebelum kebutuhan dapat dianalisis, kebutuhan harus dikumpulkan melalui proses elisitasi. Pada tahapan ini dilakukan penyeleksian data yang diperoleh sehingga dapat diketahui data-data yang digunakan dan yang tidak digunakan terkait dengan pengembangan perangkat lunak.

Berikut ini data yang dikumpulkan melalui proses wawancara ataupun observasi pada perusahaan. Data tersebut meliputi:

1. Data Bayi

Data Bayi digunakan oleh petugas Imunisasi puskesmas untuk mencatat seluruh data bayi yang melakukan pemberian vaksin imunisasi

Tabel 3.5 Data Bayi

Nama Bayi A. Farid Yanuar Tanggal Lahir 10/1/2013 Jenis Kelamin L

Alamat Kalibokor 1/30 C Data Bayi

2. Data Puskesmas

Data Puskesmas digunakan untuk mencatat nama Puskesmas mana saja yang tercatat sebagai pengguna sistem.

Tabel 3.6 Data Puskesmas

Nama Puskesmas Alamat

Kecamatan Kota Provinsi No telp

Data Puskesmas

3. Data Jenis Vaksinasi

Data Jenis vaksinasi digunakan untuk mencatat histori imunisasi setiap pasien Bayi yang pada setiap Puskesmas di Surabaya supaya dapat dilacak.

Tabel 3.7 Data Vaksinasi

Nama Tanggal Pemberian

BCG Polio 1 Polio2 Polio 3 Polio 4 Campak HB 0-7 HB 7-14

DPT COMBO 1 DPT COMBO 2 DPT COMBO 3

Data Vaksinasi

4. Data Pengguna

Data Pengguna digunakan untuk mengetahui pengguna sistem dan memberikan hak akses pada pengguna sistem, agar pengguna dapat menggunakan sistem sesuai dengan Job description.

Tabel 3.8 Data pengguna

Nama Jabatan Hak Akses

Data Pengguna

5. Data Kecamatan

Data kecamatan digunakan untuk melacak bayi berdasarkan cakupan setiap kecamatan.

Tabel 3.9 Data Kecamatan

6. Data Kelurahan

Data Kelurahan digunakan untuk melacak bayi berdasarkan cakupan setiap kelurahan di Surabaya.

Tabel 3.10 Data Kelurahan

Nama Kelurahan Alamat Kantor

Data Kelurahan

7. Data Target Puskesmas

Data Target Puskesmas digunakan untuk menentukan target tahunan setiap puskesmas yang ada di Surabaya

Nama Kecamatan Jumlah Cakupan Alamat Kantor

A. Evaluasi Backlog Fighting

Mengenai detail uji fungsional dari sub-fungsi mengukur target yang dicapai akan dijelaskan pada Tabel 4.21 berikut ini.

Tabel 4.21 Uji Coba Fungsional (Mengukur Target) Fungsional Evaluasi Backlog Fighting

Stakeholder Kepala seksi Wabah Bencana Alur Normal Aksi

Stakeholder Respon Sistem Hasil

Stakeholder memilih menu BLF

Sistem menampilkan Halaman BLF

Kondisi Akhir

Respon Sistem Hasil

Sistem akan BLF

4.3.4 Uji Non-Fungsional

Pada tahap ini akan dilakukan uji coba non-fungsional terhadap sistem yang telah dibangun. uji coba non-fungsional merupakan suatu kegiatan untuk mengidentifikasikan keberhasilan, kelengkapan, keamanan, dan kualitas pada sistem yang bersangkutan. Berikut adalah hasil uji coba non-fungsional yang terbagi menjadi 5 kategori, yaitu:

A. Uji Coba Non-Fungsional (Correctnes)

Mengenai detail uji coba non-fungsional (Correctnes) akan dijelaskan pada Tabel 4.22 berikut ini.

Tabel 4.22 Uji Coba Non-Fungsional (Correctness) Keterangan Hasil Sistem

Sistem akan menampilkan pesan kepada stakeholder , jika stakeholder

menjalankan sistem tidak berdasarkan rule yang ada.

Kesimpulan Dari hasil uji coba tersebut, maka sistem berhasil menjaga konsistensi data yang akan diolah oleh sistem, dikarenakan data telah divalidasi terlebih dahulu sebelum diproses kedalam database.

B. Uji Coba Non-Fungsional (Security)

Mengenai detail uji coba non-fungsional (Security) akan dijelaskan pada Tabel 4.23 berikut ini.

Tabel 4.23 Uji Coba Non-Fungsional (Security) Keterangan Hasil Sistem

Sistem akan membatasi menu-menu yang dapat diakses oleh stakeholder berdasarkan role yang dimiliki stakeholder .

Kesimpulan Dari hasil uji coba tersebut, maka sistem berhasil mengatur hak akses stakeholder , sehingga keamanan data dan fungsi dari sistem dapat terjaga dan berjalan sesuai dengan rule yang telah ada.

C. Uji Coba Non-Fungsional (Interface)

Mengenai detail uji coba non-fungsional (Interface) akan dijelaskan pada Tabel 4.24 berikut ini.

Tabel 4.24 Uji Coba Non-Fungsional (Interface)

Keterangan Hasil Sistem

Sistem menggunakan bahasa indonesia dalam fungsionanya serta menggunakan font (Arial, 11px) sehingga mudah

dipahami oleh stakeholder dan dapat dibaca secara jelas

Kesimpulan Dari hasil uji coba tersebut, maka sistem dapat memberikan kemudahan dan kenyamanan kepada stakeholder dalam menjalankan sistem, dikarenakan sistem ini dirancang berdasarkan kebutuhan stakeholder pada tahap elisitasi.

D. Uji Coba Non-Fungsional (Operability)

Mengenai detail uji coba non-fungsional (Operability) akan dijelaskan pada Tabel 4.25 berikut ini.

Tabel 4.25 Uji Coba Non-Fungsional (Operability) Keterangan Hasil Sistem

Sistem memberikan fasilitas stakeholder an “tab” untuk berpindah dari kolom sebelumnya ke kolom sesudahnya.

Keterangan Hasil Sistem

Kesimpulan Dari hasil uji coba tersebut, maka sistem mampu memenuhi kebutuhan non-fungsional stakeholder , sehingga sistem dapat dengan mudah dioprasikan oleh stakeholder .

E. Uji Coba Non-Fungsional (Performance)

Mengenai detail uji coba non-fungsional (Performance) akan dijelaskan pada Tabel 4.26 berikut ini.

Tabel 4.26 Uji Coba Non-Fungsional (Performance)

Keterangan Hasil Sistem

Sistem mampu berjalan dengan baik walaupun dengan beban stakeholder (10 orang) secara bersamaan

Kesimpulan Dari hasil uji coba tersebut, maka sistem mampu memenuhi kebutuhan dalam kehandalan, sehingga sistem dapat berjalan dengan baik walaupun dibebankan cukup banyak stakeholder .

4.4 Evaluasi

Setelah tahapan implementasi, uji coba fungsional dan non-fungsional dilakukan, selanjutnya adalah melakukan evaluasi terhadap sistem tersebut secara keseluruhan, terutama pada hasil output program yang berupa informasi monitoring dan evaluasi UCI.

4.4.1 Proses Monitoring dan Evaluasi

Dalam proses monitoring dan evaluasi yang dilakukan oleh dinas kesehatan kota Surabaya seharusnya dilakukan secara realtime, namun pada saat ini yang terjadi adalah belum adanya suatu sistem yang mendukung Dinkes kota Surabaya untuk melakukan monitoring dan evaluasi secara realtime sehingga dapat menghambat dan tidak dapat mengetahui hasil capaian dari Puskesmas pada saat yang dibutuhkan. Dinkes kota Surabaya menggunakan sistem untuk monitoring dan Evaluasi UCI Dinas kota Surabaya Berbasis Web. Untuk lebih jelasnya dapat dilihat pada Gambar 4.16.

154

DAFTAR PUSTAKA

Bojic, Paul. 2008. Business Information System. Pearson Education Ltd., England Dinas Kesehatan. (2005). Surat Keputusan Menteri Kesehatan Republik Indonesia

Nomor 1611/MENKES/SK/XI/2005. Surabaya.

England, John Wiley & Sons. IEEE. “Guide to the Software Enginering Body of

Knowledge 2004 Version:” SWEBOK A Project of he IEEE Computer Society.

Few, S. 2006. Information Dashboard Design. Italy: O’reilly media. Handoko, T. (2000). Manajemen. Yogyakarta: BPFE-Yogyakarta.

Hariyanti, E. 2008. Metodologi Pembangunan Dashboard sebagai alat monitoring kinerja organisasi studi kasus institut teknologi bandung

Jogiyanto. 2005. Analisis & desain Sistem Informasi : Pendekatan terstruktur teori dan praktek aplikasi bisnis. Andi, Yogyakarta.

John Burch, Gary Grudnitski. Edisi Keempat, Information System Theory and Practice. New York : John Wiley & Sons, 1986, Chapter 2.13.

MADCOMS. 2011. Adobe Dreamweaver CS5 dengan pemrograman PHP & MySQL. Andi, Yogyakarta.

Suryana, 2011, Strategi dan Evaluasi (MONEV) Sistem Penjamin Mutu Internal Sekolah. Thesis S2 Fakultas Ilmu Pendidikan Universitas Pendidikan Indonesia Bandung.