TA : Rancang Bangun Aplikasi Optimus+ pada PT. PLN (Persero) APJ Surabaya Barat.

TUGAS AKHIR

Nama : Zulfa Ulinnuha Tritita NIM : 09.41010.0269

Program : S1 (Strata 1) Jurusan : Sistem Informasi

SEKOLAH TINGGI

MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA

ABSTRAK

Seperti pada PT. PLN (Persero)—untuk selanjutnya disebut PLN—area lainnya, PLN Area Surabaya Barat (SBB) memiliki sebuah metode yang disebut Operational Performance Improvement (OPI). OPI SBB saat ini dijalankan secara manual dengan menggunakan kertas dan Microsoft Excel. Dalam menjalankan aktivitas OPI ini PLN mengalami beberapa kendala seperti: penggunaan EMI Survey masih manual dan berisiko terhadap nilai indikator yang dihasilkan, status aktivitas workplan yang disajikan dalam Microsoft Excel masih statis dan tidak dapat memberikan informasi yang aktual, dan belum adanya informasi yang dibutuhkan oleh manajer untuk memantau perkembangan initiative.

Untuk mengatasi beberapa kendala tersebut, dibangun sebuah aplikasi OPTIMUS+ dengan spesifikasi kebutuhan perangkat lunak yang memiliki fungsi modul EMI Survey Online, Diagnose, Design, serta Deliver seluruh kegiatan OPI. Selain untuk mengatasi beberapa kendala tersebut, OPTIMUS+ dibangun agar dapat diperoleh output yang dibutuhkan, seperti rekapitulasi EMI Survey, grafik EMI Survey, informasi status aktivitas workplan, serta rekapitulasi aktivitas workplan via website dan Short Message Service (SMS).

OPTIMUS+ dapat membantu pelaksanaan aktivitas OPI secara lebih maksimal dengan mengecilkan risiko dari kendala yang ada dan memberikan keuntungan berupa kemudahan dalam memperoleh output yang dibutuhkan.

Kata Kunci : Operational Performance Improvemance (OPI), OPTIMUS+, Website.

Halaman

ABSTRAK ... vii

KATA PENGANTAR ... viii

DAFTAR ISI ... x

DAFTAR TABEL ... xiii

DAFTAR GAMBAR ... xiv

DAFTAR LAMPIRAN ... xviii

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Perumusan Masalah ... 4

1.3 Batasan Masalah... 4

1.4 Tujuan... 4

1.5 Manfaat ... 5

1.6 Sistematika Penulisan...… 5

BAB II LANDASAN TEORI ...… 7

2.1 OPI ... 7

2.2 Aplikasi OPTIMUS, OPI dengan Microsoft Excel, dan OPTIMUS+ ... 7

2.3 SMS Gateway...… 9

2.4 Testing Software...… 10

2.4.1 Black box Testing ... 11

BAB III ANALISIS DAN PERANCANGAN SISTEM... 12

3.1 Analisa Permasalahan... 12

3.1.1 Business Use Case Diagram ... 13

3.2 Analisis Kebutuhan Perangkat Lunak ... 21

3.3 Perancangan Sistem ... 22

3.3.1 OPTIMUS+ Use Case Diagram ... 24

3.3.2 OPTIMUS+ Acitvity Diagram ... 27

3.3.3 Flow of Event (FOE) ... 38

3.3.5 OPTIMUS+ Class Diagram ... 55

3.4 Desain Input dan Output Sistem ... 57

3.4.1 Rancangan Tampilan EMI Survey ... 57

3.4.2 Rancangan Tampilan Gap ... 57

3.4.3 Rancangan Tampilan RCPS ... 59

3.4.4 Rancangan Tampilan Initiative ... 60

3.4.5 Rancangan Tampilan Initative Approval ... 62

3.4.6 Rancangan Tampilan Workplan ... 63

3.4.7 Rancangan Tampilan Entri Workplan Progress ... 65

3.4.8 Rancangan Tampilan Grafik EMI Survey ... 66

3.4.9 Rancangan Tampilan Rekapitulasi EMI Survey... 67

3.4.10 Rancangan Tampilan Rekapitulasi Workplan... 67

3.4.11 Rancangan Tampilan Notifikasi via SMS... 68

BAB IV IMPLEMENTASI DAN EVALUASI SISTEM... 69

4.1 Implementasi Sistem ... 69

4.1.1 Pembuatan Basis Data dan Jaringan... 69

4.1.2 Pengkodean... 69

4.1.3 Pemasangan Sistem Baru ... 70

4.2 Evaluasi Sistem... 70

4.2.1 Uji Coba dan Evaluasi Form EMI Survey ... 71

4.2.2 Uji Coba dan Evaluasi Form Login ... 72

4.2.3 Uji Coba dan Evaluasi Form Gap... 76

4.2.4 Uji Coba dan Evaluasi Form RCPS... 84

4.2.5 Uji Coba dan Evaluasi Form Initiative... 90

4.2.6 Uji Coba dan Evaluasi Form Initiative Approval... 95

4.2.7 Uji Coba dan Evaluasi Form Workplan... 97

4.2.8 Uji Coba dan Evaluasi Form Workplan Progress... 100

BAB V PENUTUP ... ... ... 109

5.1Kesimpulan……… .. ... 109

5.2Saran ... ... 109

DAFTAR PUSTAKA ... 110

LAMPIRAN ... 111

1.1 Latar Belakang Masalah

Dalam rangka menuju World Class Service (WCS), PT. PLN (Persero), untuk selanjutnya disebut PLN, memiliki sebuah parameter yang disebut sebagai Operational Excellent. Dari parameter itulah Operational Performance Improvement (OPI) dilahirkan, melalui bantuan konsultan dari Amerika, McKinsey. Menurut PT. PLN (Persero) Distribusi Jawa Timur (2012), Operational Performance Improvement atau disingkat OPI adalah suatu metodologi dalam membangun proses dari tiga kerangka kerja (Workstream) yaitu Technical System (TS), Management Infrastructure (MI), dan Mindset Capabilities and Leadership (MCL). Implementasi OPI ini melalui tiga tahap yaitu Diagnose, Design dan Deliver. Diagnose adalah tahap dimana mencari bottleneck yang terjadi pada proses bisnis (tahap identifikasi gap), selanjutnya Design adalah tahapan mencari ide-ide perbaikan untuk menutup atau menghilangkan gap-gap yang sudah diidentifikasi. Selanjutnya adalah tahap implementasi atau Deliver, di tahap inilah ide-ide perbaikan dijalankan dan dimonitor pelaksanaannya, dampaknya serta hasilnya.

PLN menggunakan aplikasi OPTIMUS untuk mengelola hasil kegiatan OPI dari seluruh PLN Area Pelayanan dan Penjaringan (APJ), termasuk PLN Surabaya Barat. Sedangkan pada PLN Surabaya Barat sendiri, pada rayon dan tingkat bagiannya, kegiatan OPI dikelola menggunakan Microsoft Excel.

OPI dengan Microsoft Excel menyajikan informasi status aktivitas rangkaian kerja (workplan) secara statis/tidak aktual. Workplan merupakan

rencana pelaksanaan initiative, (PT. PLN (Persero), 2012). Sedangkan initiative merupakan upaya perbaikan, pada tahap Design. Setiap aktivitas workplan memiliki status. Status yang tidak aktual memungkinkan terjadinya kesalahan penginformasian status aktivitas workplan. Kesalahan penginformasian mengakibatkan terjadinya keterlambatan pengeksekusian suatu aktivitas workplan. Keterlambatan pengeksekusian suatu aktivitas workplan dapat mengulur waktu untuk pengeksekusian aktivitas selanjutnya atau bahkan memberi dampak buruk. Sebagai contoh, terdapat suatu workplan yang bersifat preventif, yaitu untuk mencegah adanya gangguan penyulang pada musim hujan yang terjadi mulai Oktober 2012. Workplan tersebut terlambat dieksekusi sehingga mengakibatkan gangguan yang semakin meningkat hingga bulan berikutnya. Gangguan ini mengakibatkan adanya padam listrik. Semakin tinggi gangguan, semakin tinggi pula jumlah listrik yang padam. Pada sisi internal, padam listrik berarti PLN tidak bisa menjual produknya. Sedangkan pembangkit listrik seperti di Paiton, misalnya, terus menerus memproduksi listrik yang mana membutuhkan biaya. Sedangkan pada sisi eksternal, keluhan pelanggan meningkat karena pelanggan tidak puas. Permasalahan kedua, keterlambatan workplan terjadi karena kurangnya pemantauan. Manajer Area sebagai pemilik initiative membutuhkan informasi tentang perkembangan initiative untuk kebutuhan pemantauan. Sistem sebelumnya belum memberikan informasi semacam ini. Permasalahan terakhir mengenai EMI Survey. EMI Survey merupakan analisa yang dilakukan untuk mengetahui tingkah laku dan mindset para karyawan (staf frontliner dan supervisor). Hasil dari survei ini dapat dijadikan evaluasi dalam menentukan kebijakan pada masa yang akan datang (Roadmap Operational Performance

Improvement (OPI), 2012). Perekapan jawaban EMI Survey yang dilakukan secara manual, seperti sebelumnya, berisiko terjadi kesalahan pada nilai indikator yang dihasilkan.

Untuk mengatasi permasalahan tersebut, dibutuhkan aplikasi OPTIMUS+. Untuk membuat OPTIMUS+ dilakukan beberapa tahap penelitian. Tahap pertama, identifikasi masalah, dengan cara observasi, wawancara, maupun survei data, diperoleh current system OPI serta kendala-kendala PLN SBB. Current System yang telah dipelajari sebelumnya, digunakan untuk melakukan tahap kedua, yaitu analisa masalah. Analisa masalah menghasilkan kebutuhan-kebutuhan dari sistem yang akan dibangun. Selanjutnya, dari kebutuhan-kebutuhan sistem tersebut, dilakukan pendesainan. Pendesainan dilakukan dengan menggunakan beberapa macam diagram visual Unified Modeling Language (UML) untuk mendapatkan banyak pandangan terhadap sistem yang akan dibangun (Sholiq, 2010). Tahap selanjutnya adalah membangun sistem dengan menggunakan web. Web dipilih karena lokasi pengguna aplikasi yang dibangun, tersebar di beberapa rayon dan tingkat bagian. Selain itu, dibutuhkan sifat web yang dinamis dalam menginformasikan data.

Sehingga dihasilkan OPTIMUS+ yang dapat melakukan penginformasian status aktivitas workplan secara aktual, memberikan informasi yang dibutuhkan oleh manajer untuk kebutuhan pemantauan, dan mempunyai EMI Survey Online. Sehingga dengan OPTIMUS+, PLN SBB dapat melakukan aktivitas OPI secara lebih maksimal dengan mengecilkan risiko dari kendala yang ada dan memberikan keuntungan berupa kemudahan dalam memperoleh output yang dibutuhkan.

1.2 Perumusan Masalah

Berdasarkan latar belakang di atas, dapat dirumuskan permasalahan yaitu bagaimana membuat aplikasi OPTIMUS+ pada PLN APJ Surabaya Barat.

1.3 Batasan Masalah

Batasan masalah dari sistem yang dibahas adalah sebagai berikut:

1. Pada aplikasi ini, proses Deliver hanya sampai pada pengimplementasian workplan. Penilaian dampak atau audit implementasi workplan tidak termasuk di dalamnya

2. Aplikasi ini tidak membahas cara pemilihan initiative yang layak untuk dilanjutkan

3. Diasumsikan bahwa tidak ada masalah dalam jaringan provider maupun sisi penerima untuk pengiriman notifikasi SMS

1.4 Tujuan

Berdasarkan perumusan masalah di atas, maka diperoleh tujuan dari tugas akhir ini, yaitu dapat menghasilkan aplikasi OPTIMUS+ yang:

a. Mampu menghasilkan informasi status aktivitas workplan yang dinamis, sehingga pihak terkait seperti PIC dapat mengontrol setiap aktivitas workplan serta waktu pengerjaannya sesuai status terkini

b. Menghasilkan rekapitulasi jumlah workplan sesuai status, via SMS, kepada manajer, agar manajer dapat memperoleh informasi yang tepat/sesuai untuk kebutuhan pemantauan, terutama ketika sedang berada di luar kota, misalnya c. Memiliki modul EMI Survey Online, agar dapat memberikan kemudahan

1.5 Manfaat

Aplikasi ini berfungsi sebagai pengelola kegiatan OPI yang ada di rayon-rayon dan tingkat bagian/bidang pada APJ Surabaya Barat.

1.6 Sistematika Penulisan

Penyusunan laporan Tugas Akhir ini dapat dikelompokkan sebagai berikut:

BAB I PENDAHULUAN

Bab ini menjelaskan tentang latar belakang masalah yang ada, perumusan masalah berdasarkan tujuan, batasan masalah yang akan dibahas, tujuan dari pembuatan aplikasi, dan manfaat serta sistematika penulisan tugas akhir ini.

BAB II LANDASAN TEORI

Bab ini menjelaskan tentang teori-teori dasar yang digunakan dalam membantu menyelesaikan perrmasalahan.

BAB III METODE PENELITIAN DAN PERANCANGAN SISTEM

Bab ini berisi penjelasan tentang metode penelitian dan langkah-langkah untuk pemecahan masalah dalam tugas akhir, termasuk: menganalisis permasalahan, identifikasi dari gambaran proses bisnis yang dijabarkan dalam UML, tujuan penelitian, penyelesaiannya, struktur tabel, desain Input/Output, dll.

BAB IV IMPLEMENTASI SISTEM

Bab ini berisi penjelasan tentang implementasi dan evaluasi sistem yang dibuat, apakah telah sesuai yang diharapkan.

BAB V PENUTUP

Bab ini menjelaskan uraian dari kesimpulan tentang analisis sistem yang dibuat dan saran bagi pengembangan sistem dari aplikasi yang dibuat kedepannya.

2.1 OPI

Menurut PT. PLN (PERSERO) Distribusi Jawa Timur (2012), metode OPI atau Operational Performance Improvement adalah metode perbaikan kinerja suatu unit atau bidang kerja secara holistik dan melibatkan fungsi di bidang teknik, manajemen, sistem organisasi dan kesiapan sumber dayanya (SDM). Oleh karena itu metode OPI terbagi dalam 3 workstream (kerangka kerja) yaitu: Technical System (TS), Management Infrasrtucture (MI), dan Mindset Capabilities – Leadership (MCL).

Implementasi OPI ini melalui tiga tahap yaitu Diagnose, Design dan Deliver. Diagnose adalah tahap dimana mencari bottleneck yang terjadi pada proses bisnis (tahap identifikasi gap), selanjutnya Design adalah tahapan mencari ide-ide perbaikan untuk menutup atau menghilangkan gap-gap yang sudah diidentifikasi dan selanjutnya adalah tahap implementasi atau Deliver, di tahap inilah ide-ide perbaikan dijalankan dan dimonitor pelaksanaannya, dampaknya serta hasilnya.

2.2 Aplikasi OPTIMUS, OPI dengan Microsoft Excel, dan OPTIMUS+ Untuk Meningkatkan efisiensi dan efektifitas dalam Monitoring dan Tracking Program Initiative OPI, Tim OPI Kantor Pusat sudah membuat sebuah aplikasi untuk program tersebut. OPTIMUS (OPI Tracking Initiative Machine Upload System), yang sebelumnya sudah di launching pada Desember 2011, saat ini sudah dengan tampilan dan penggunaan lebih maksimal. Upload File, Entry

Initiative, Worklplan, Task, News, Artikel, dll, sudah bisa digunakan di aplikasi OPTIMUS ini. (PT. PLN (PERSERO), t.t.).

Menurut Modul Pelatihan OPTIMUS (2012), OPTIMUS Application is a tool that will allow managing the tasks/Activities associated with Initiatives. We can discuss the progress of the Initiatives, associate important files to relevant tasks, share reports, manage workflow etc. Dengan fitur-fitur yang dimiliki OPTIMUS tersebut , PLN mengelola hasil kegiatan OPI dari seluruh PLN Area.

Pada PLN Rayon (Taman, Karang Pilang, dan Menganti) dan Tingkat Bagian (Asman Perencanaan, Asman Konstruksi, Asman Jaringan, Asman T. E. L., dan Asman Administrasi), proses OPI dikelola dengan Microsoft Excel. Sama seperti OPTIMUS, OPI dengan Microsoft Excel juga mengelola initiative dan workplan. Dasarnyapun sama, yaitu OPI.

Setiap Rayon memiliki workplan masing-masing. Workplan ini bisa dimiliki oleh Rayon dan Tingkat Bagian/Bidang itu sendiri atau diperoleh dari penurunan dari workplan yang dimiliki Area. Penggunaan Microsoft Excel oleh PLN Rayon dan Tingkat Bagian/Bidang adalah untuk memantau workplan yang ada di Rayon maupun Tingkat Bagian/Bidang itu sendiri.

Ada beberapa permasalahan pada OPI dengan Microsoft Excel. Permasalahan seperti penyajian informasi workplan yang statis, belum adanya informasi yang tepat untuk manajer untuk kebutuhan pemantauan, dan belum adanya modul EMI Survey Online, dapat memberikan dampak yang kurang baik. Oleh karena itu, dibutuhkan adanya aplikasi baru yang dapat mengatasi permasalahan tersebut, yaitu OPTIMUS+.

Nama OPTIMUS+ diambil dari OPTIMUS, aplikasi OPI Pusat, karena OPTIMUS+ memiliki dasar yang sama dengan OPTIMUS, yaitu OPI. Hanya saja, nantinya OPTIMUS+ akan digunakan dalam lingkup Rayon sampai Tingkat Bagian/Bidang menggantikan OPI dengan Microsoft Excel. OPTIMUS+ digunakan untuk menampung hasil kegiatan OPI di Rayon dan Tingkat Bagian/Bidang. Hasil kegiatan OPI Rayon dan Tingkat Bagian/Bidang yang berkaitan dengan workplan Area, nantinya akan digabungkan ke dalam OPTIMUS. Berikut ini adalah gambar hubungan antara OPTIMUS dan OPTIMUS+. APJ Surabaya Barat Bidang Administrasi Bidang T.E.L. Bidang Konstruksi Bidang Jaringan Bidang Perencanaan Rayon Taman Rayon Karang Pilang Rayon Menganti OPTIMUS

Hasil Kegiatan OPI

OPTIMUS + OPTIMUS + OPTIMUS +

OPTIMUS + OPTIMUS + OPTIMUS + OPTIMUS + OPTIMUS +

Gambar 2.1 Gambar Hubungan OPTIMUS dan OPTIMUS+

2.3 SMS Gateway

Menurut Purnamasari (2010), SMS atau Short Message Services merupakan salah satu fasilitas atau layanan pada Teknologi Komunikasi Bergerak yang paling banyak digunakan saat ini karena biaya murah, prosesnya cepat, dan dapat langsung diterima oleh tujuan.

Cara kerja SMS Gateway adalah: 1. Nomor Mobile-Station

2. SMS Gateway akan memproses pengambilan data dari database sesuai dengan format database yang telah ditentukan

3. Kemudian SMS Gateway akan mengirimkan kepada user sesuai dengan format SMS yang telah ditentukan.

2.4 Testing Software

Menurut Romeo (2003), testing software adalah proses mengoperasikan software dalam suatu kondisi yang di kendalikan, untuk verifikasi apakah telah berlaku sebagaimana telah ditetapkan (menurut spesifikasi), mendeteksi error, dan validasi apakah spesifikasi yang telah ditetapkan sudah memenuhi keinginan atau kebutuhan dari pengguna yang sebenarnya. Verifikasi adalah adalah pengecekan atau pengetesan entitas-entitas, termasuk software, untuk pemenuhan dan konsistensi dengan melakukan evaluasi hasil terhadap kebutuhan yang telah ditetapkan. Validasi adalah melihat kebenaran sistem, apakah proses yang telah dilakukan adalah apa yang sebenarnya diinginkan atau dibutuhkan oleh user. Jadi, dapat disimpulkan bahwa testing merupakan tiap-tiap aktifitas pengumpulan informasi yang dibutuhkan untuk melakukan evaluasi atau mengukur suatu atribut dari software.

Testing software dilakukan untuk mendapatkan informasi reliable terhadap software dengan cara termudah dan paling efektif, antara lain:

1. Apakah software telah siap digunakan ? 2. Apa saja resikonya ?

4. Apa saja keterbatasannya ? 5. Apa saja masalahnya ?

6. Apakah telah berlaku seperti yang diharapkan ?

2.4.1 Black box Testing

Black box testing, dilakukan tanpa pengetahuan detil struktur internal dari sistem atau komponen yang ditest, juga disebut sebagai behavioral testing, specification-based testing, input / output testing atau functional testing. Black box testing berfokus pada kebutuhan fungsional pada software, berdasarkan pada spesifikasi kebutuhan dari software. Kategori error yang akan diketahui melalui black box testing adalah sebagai berikut:

a. Fungsi yang hilang atau tidak benar. b. Error dari antar muka.

c. Error dari struktur data atau akses eksternal database. d. Error dari kinerja atau tingkah laku.

e. Error dari inisialisasi dan terminasi.

Test di desain untuk menjawab pertanyaan sebagai berikut: 1. Bagaimana validasi fungsi yang akan ditest ?

2. Bagaimana tingkah laku kinerja dari sistem yang akan ditest ? 3. Kategori masukan apa saja yang bagus digunakan untuk test case ? 4. Apakah sebagian sistem sensitif terhadap suatu nilai masukan tertentu ? 5. Bagaimana batasan suatu kategori masukan ditetapkan ?

3.1 Analisa Permasalahan

Pada bab ini akan dibahas mengenai analisa dan perancangan sistem dengan menggunakan model pengembangan waterfall. Berikut ini adalah gambaran mengenai model waterfall dalam penelitian ini:

Data survey Wawancara Observasi Identifikasi Masalah Analisa Sistem Bangun Sistem Evaluasi dan Implementasi Current System OPI Rayon dan Tingkat Bagian OPTIMUS+ OPTIMUS+ untuk pengguna Spesifikasi kebutuhan perangkat lunak :

memiliki fungsi EMI Survey, Diagnose, Design, dan Deliver Desain Sistem Use Case Diagram, Activity Diagram, Sequence Diagram, Class Diagram

Gambar 3.1 Langkah-Langkah Pengembangan Waterfall

Model pengembangan waterfall terdiri dari proses identifikasi masalah yang dalam penelitian ini inputnya berupa data survey, wawancara, dan observasi

sehingga menghasilkan output berupa current system OPI Rayon dan Tingkat Bagian, serta permasalahan yang ada di dalamnya. Secara detail, current system OPI Rayon dan Tingkat Bagian tersebut dapat digambarkan dalam Business Use Case Diagram pada Gambar 3.2.

3.1.1 Business Use Case Diagram

Pada Gambar 3.2 terdapat empat proses, yakni: EMI Survey, Diagnose, Design dan Deliver. Masing-masing proses tersebut akan dijelaskan dalam Activity Diagram pada Gambar 3.3.

Gambar 3.2 Business Use Case Diagram OPI

A. EMI Survey

EMI Survey merupakan analisa yang dilakukan untuk mengetahui tingkah laku dan mindset para karyawan (staf frontliner dan supervisor). Hasil

dari survei ini dapat dijadikan evaluasi dalam menentukan kebijakan pada masa yang akan datang (Roadmap Operational Performance Improvement (OPI), 2012). EMI Survey merupakan sebuah survei untuk mengevaluasi kekuatan dan area perbaikan yang terdapat di APJ.

Dalam activity diagram EMI Survey terdapat permasalahan dalam mendapatkan nilai dari masing-masing indikator EMI Survey. EMI Survey yang ada saat ini, masih manual, dengan menggunakan kertas. Hal ini dapat menjadi masalah dalam mendapatkan nilai indikator, seandainya data kuesioner hilang atau rusak. Selain itu, dengan kuesioner manual seperti itu, untuk mendapatkan nilai indikator, tim OPI harus melakukan perekapan terlebih dahulu secara manual. Hal ini membutuhkan waktu yang tidak sebentar, sebab data kuesioner tidak sedikit, yaitu berasal dari minimal 50% responden. Dalam perekapan manual seperti ini juga terdapat kemungkinan terjadi kesalahan rekap, sehingga membuat hasil perhitungan menjadi tidak valid.

Formula untuk menghitung nilai masing-masing indikator dalam EMI Survey adalah sebagai berikut:

X N ator NilaiIndik n i

∑

= = 1 (Hapsari, 2012) Keterangan:

N : pertanyaan 1 : batas bawah n : batas atas

X : jumlah pertanyaan yang mewakili indikator

Berdasarkan Form EMI Survey, terdapat tujuh indikator dalam EMI Survey. Setiap indikator memiliki pertanyaannya masing-masing, seperti berikut ini:

1. Keterbukaan dan transparasi

a. Pekerja telah berani mengutarakan pendapatnya secara terbuka, sekalipun berbeda pendapat dengan pimpinanya.

b. Kondisi saat ini pimpinan meluangkan cukup waktu untuk berkomunikasi secara terbuka bersama pekerja

c. Pekerja telah mengetahui target dan pencapaian kinerja bagiannya d. Kondisi saat ini masing-masing bagian saling mendukung, sehingga

tidak terjadi saling menyalahkan 2. Akuntabilitas

a. Kondisi saat ini setiap pekerja peduli atas hasil kerja mereka dan dampaknya ke pencapaian kinerja Unit Anda secara keseluruhan 3. Penghargaan (Rewards) dan Konsekuensi (Consequences)

a. SMUK saat ini telah mencerminkan kinerja individu yang sesungguhnya

b. Sistem pemberian penghargaan saat ini telah berlangsung secara berkeadilan dan efektif

c. Sistem promosi pekerja sudah berlangsung sesuai prosedur, transparan dan efektif

4. Kapabilitas kelas dunia

a. Program pelatihan / training sudah memadai dan sesuai dengan kebutuhan pekerjaan

b. Sudah ada sistem yang memantau tingkat kompetensi pekerja maupun pimpinan beserta program pengembangannya

c. Pekerja Unit Anda saat ini telah menjalankan tugas dan tanggung jawab berdasarkan prosedur kerja yang baku

d. Saat ini pimpinan selalu siap membagikan pengetahuannya untuk mengembangkan kapabilitas para pekerja

e. Saya merasa saya saat ini seluruh fasilitas/peralatan di Unit Anda terpelihara dengan baik

5. Visi transformasi

a. Pekerja percaya bahwa para pimpinan telah sepakat bahwa Unit Anda harus berubah untuk menjadi lebih baik

b. Pekerja telah mengetahui dan memahami visi Unit Anda 6. Mengembangkan para pemimpin masa depan

a. Pimpinan telah mampu mendidik dan menyiapkan para calon pemimpin berikutnya dengan baik

b. Saya merasa saat ini potensi kepemimpinan saya dihargai dan dikembangkan oleh perusahaan

7. Budaya safety

a. Pekerja telah dilengkapi dengan peralatan keselamatan kerja yang memadai untuk pelaksanaan pekerjaannya

b. Pekerjaan telah memiliki kapabilitas dan kepedulian yang tinggi terhadap keselamatan dirinya dan pekerja lainnya

c. Pekerja saat ini merasakan kondisi yang bersih, aman dan nyaman selama bekerja di Unit Anda

Setelah diperoleh nilai berdasarkan formula yang tertera sebelumnya, nilai atau angka dari indikator tersebut akan disajikan dalam grafik untuk Manajer.

B. Diagnose

Menurut PT. PLN (Persero) Distribusi Jawa Timur (2012), diagnose adalah tahap dimana mencari bottleneck yang terjadi pada proses bisnis. Diagnose terdiri dari dua langkah, yaitu pembuatan gap dan RCPS. Gap dilakukan dengan dengan melakukan identifikasi terhadap permasalahan dan menemukan selisih dari nilai target dan nilai yang diperoleh dari topik permasalahan tersebut. RCPS dilakukan dengan menemukan akar dan problem solving / ide perbaikan dari suatu permasalahan.

Gambar 3.4 menjelaskan alur proses Diagnose. Dari actitvity diagram Diagnose tersebut terdapat dua proses yang akan diikutkan ke dalam sistem yang baru, yaitu: mencatat gap dan mencatat problem solving.

C. Design

Menurut PT. PLN (Persero) Distribusi Jawa Timur (2012), design adalah tahapan mencari ide-ide perbaikan untuk menutup atau menghilangkan gap-gap yang sudah diidentifikasi. Design dilakukan dengan membuat initiative dan workplan.

Gambar 3.5 menjelaskan alur proses Design. Dari actitvity diagram Design tersebut terdapat beberapa proses yang akan diikutkan ke dalam sistem yang baru, yaitu: memberikan initiative untuk gap, memberi keputusan terhadap setiap initiative, dan mengembangkan initiative menjadi rangkaian aktivitas (workplan).

D. Deliver

Menurut PT. PLN (Persero) Distribusi Jawa Timur (2012), deliver adalah tahap ide-ide perbaikan dijalankan dan dimonitor pelaksanaannya, dampaknya serta hasilnya.

Gambar 3.6 menjelaskan tentang alur proses bisnis Deliver. Dalam proses tersebut terdapat permasalahan, yaitu dalam memperbarui status aktivitas workplan. Informasi status aktivitas workplan ini dibutuhkan oleh banyak pihak, akan tetapi informasi yang disajikan tidak aktual, sehingga bisa mengakibatkan kesalahan informasi. Kesalahan informasi mengakibatkan keterlambatan aktivitas workplan.

Selain itu, dalam aktivitas pelaksanaan workplan tersebut belum ditunjukkan adanya suatu informasi untuk manajer untuk kebutuhan pemantauan. Manajer Area belum memperoleh informasi yang tepat agar bisa memantau perkembangan initiative yang dimilikinya. Hal ini dapat menjadi permasalahan, karena tanpa manajer Area mendapatkan informasi yang tepat, manajer Area selaku pemilik initiative tidak dapat mengetahui perkembangan suatu initiative.

Gambar 3.6 Activity Diagram Deliver

3.2 Analisis Kebutuhan Perangkat Lunak

Dari hasil pengidentifikasian masalah di atas, terdapat beberapa permasalahan, seperti: penggunaan EMI Survey masih manual dan berisiko terhadap nilai indikator yang dihasilkan. Selain itu, status aktivitas workplan yang statis, tidak dapat memberikan informasi yang aktual. Yang terakhir, belum adanya informasi yang dibutuhkan oleh manajer untuk memantau perkembangan initiative . Permasalahan ini nantinya akan digunakan sebagai bahan atau input pada proses selanjutnya dalam model pengembangan Waterfall, yaitu analisa sistem.

Analisis sistem mengurai proses dalam current system OPI serta permasalahan-permasalahannya menjadi suatu spesifikasi perangkat lunak yang

dibutuhkan oleh masing-masing pengguna. Spesifikasi kebutuhan perangkat lunak tersebut terbagi menjadi empat, antara lain:

1. EMI Survey

EMI Survey memiliki beberapa fungsi, yaitu: Pengisian EMI Survey, Perekapan EMI Survey, dan Penghitungan nilai indikator EMI Survey. 2. Diagnose

Diagnose terdiri dari pencatatan gap dan RCPS 3. Design

Design terdiri dari pencatatan initiative , pemberian persetujuan oleh manajer terhadap initiative yang akan dilanjutkan, dan pembuatan workplan.

4. Deliver

Deliver terdiri dari proses memperbarui status dan notifikasi via SMS kepada manajer.

Setelah melakukan proses analisis sistem seperti di atas, dilakukan desain sistem. Tahap desain sistem akan dijelaskan pada sub bab selanjutnya, yaitu perancangan sistem.

3.3 Perancangan Sistem

OPTIMUS+ adalah aplikasi yang dibangun agar dapat digunakan PLN Rayon atau Tingkat Bagian Area Surabaya Barat untuk memantau sejauh mana perkembangan kegiatan OPI dilakukan. Berdasarkan identifikasi masalah dan analisa sistem yang sebelumnya telah dilakukan, diperoleh suatu spesifikasi kebutuhan perangkat lunak yang selanjutnya akan dipetakan melalui blok diagram, seperti tampak pada Gambar 3.7.

Gambar 3.7 Blok Diagram OPTIMUS+

Dalam blok diagram dijelaskan bahwa dalam sistem terdapat empat aktor, yaitu: responden, tim OPI, PIC, dan Manajer Area. OPTIMUS+ akan digunakan di PLN Rayon maupun Tingkat Bagian. Responden berkenaan dengan sistem untuk kepentingan EMI Survey. Sedangkan tim OPI untuk kepentingan tanggung jawabnya dalam gap, RCPS, Initiative dan Workplan. Ketika suatu gap telah memiliki RCPS, initiative , serta workplan, kegiatan berjalan atau dalam progress. Progress ini ditangani oleh PIC. Sampai pada tahapan ini, OPI sudah mencapai tahap Deliver. Dan Manajer Area adalah pihak yang akan memperoleh informasi yang dibutuhkannya untuk kemudian dapat melakukan pemantauan sebagai timbal balik dalam kegiatan OPI.

Secara detail, blok diagram tersebut dapat digambarkan ke dalam Use Case Diagram, Activity Diagram, Sequence Diagram, Class Diagram.

3.3.1 OPTIMUS+ Use Case Diagram A. EMI Survey

Pada spesifikasi kebutuhan perangkat lunak OPTIMUS+ terdapat beberapa fungsi, salah satunya adalah fungsi EMI Survey. Fungsi EMI Survey tersebut memiliki beberapa proses, yaitu: mengisi EMI Survey, menampilkan rekapitulasi EMI Survey, dan menampilkan grafik EMI Survey atau nilai dari masing-masing indikator dalam EMI Survey yang dapat dilihat pada Gambar 3.8.

Gambar 3. 8 Use Case Diagram EMI Survey

Mengisi EMI Survey dilakukan oleh responden. Jawaban-jawaban dari responden tersebut kemudian masuk ke dalam sistem, kemudian direkap dan dihitung hasilnya oleh sistem. Hasil perekapan dan perhitungan EMI Survey diberikan kepada Tim OPI dan Manajer.

B. Diagnose

Spesifikasi kebutuhan perangkat lunak OPTIMUS+ selanjutnya adalah fungsi Diagnose. Fungsi Diagnose tersebut memiliki dua proses, yaitu: mencatat gap dan RCPS yang ditunjukkan pada Gambar 3.9.

Gambar 3. 9 Use Case Diagram Diagnose

Proses Mencatat gap maupun RCPS merupakan tahap Diagnose dalam sistem. Dua proses tersebut ditangani oleh Tim OPI sebagai penganggung jawab tahap Diagnose.

C. Design

Spesifikasi kebutuhan perangkat lunak OPTIMUS+ ketiga adalah fungsi Design. Fungsi Design tersebut memiliki tiga proses, yaitu: memberikan initiative untuk gap, memberi keputusan terhadap initiative , dan membuat workplan atau rangkaian aktivitas. Proses-proses tersebut dapat dilihat pada Gambar 3.10.

Gambar 3. 10 Use Case Diagram Design

Setelah melakukan pencatatan gap dan RCPS, Tim OPI memberikan initiative terhadap gap tersebut. Initiative merupakan ide perbaikan untuk gap. Setelah Tim OPI memasukkan initiative, Manajer dapat memberikan keputusan, apakah initiative tersebut akan dilajutkan atau tidak. Jika initiative tersebut disetujui, maka Tim OPI akan membuatkan rangkaian aktivitas nyata untuk initiative tersebut.

D. Deliver

Spesifikasi kebutuhan perangkat lunak OPTIMUS+ terakhir adalah fungsi Deliver. Fungsi Deliver tersebut memiliki dua proses, yaitu: memperbarui status workplan dan melakukan notifikasi via SMS. Dua proses tersebut dapat dilihat pada Gambar 3.11.

Gambar 3. 11 Use Case Diagram Deliver

Dalam sistem, workplan memiliki status-status. Status tersebut antara lain, “Belum Dimulai”, “Dalam Proses”, “Selesai”, “Ditunda”, dan “Melebihi Deadline”. Sistem akan menampilkan setiap aktivitas workplan dengan statusnya masing-masing. Sistem dapat mengubah status aktivitas workplan secara otomatis sesuai perubahan tanggal menjadi “Belum Dimulai”, “Dalam Proses”, dan “Melebihi Deadline”. Selain itu, sistem dapat merespon aksi yang dilakukan PIC, sehingga status “Belum Dimulai”, “Dalam Proses”, dan “Melebihi Deadline” bisa berubah menjadi “Selesai” atau “Ditunda”.

3.3.2 OPTIMUS+ Acitvity Diagram

Pada tahap pemodelan sistem, diagram aktivitas dapat digunakan untuk menjelaskan aktivitas yang terjadi di dalam sebuah use case. Berikut ini adalah activity diagram dari masing-masing use case yang telah digambarkan di atas:

A. Mengisi EMI Survey

Diawali dengan halaman web menampilkan EMI Survey, kemudian responden melakukan pengisian EMI Survey di halaman tersebut. Setelah itu, ketika responden mengklik button Simpan, maka sistem akan memeriksa, apakah semua item dalam halaman survei telah diisi atau tidak. Jika semua item telah terisi, maka sistem akan melanjutkan penyimpanan isian survey ke dalam database. Jika tidak, maka sistem akan memberikan peringatan agar responden melengkapi isiannya terlebih dahulu, kemudian menyimpannya lagi. Proses Mengisi EMI Survey dapat dilihat pada Gambar 3.12.

B. Menampilkan Rekapitulasi EMI Survey

Perekapan EMI Survey dilakukan dengan cara mengklik button rekapitulasi yang telah disediakan di dalam halaman report, kemudian sistem akan memuat data EMI Survey yang diperlukan dari database. Pemuatan data tersebut ditampilkan dalam bentuk Microsoft Excel. Proses menampilkan rekapitulasi EMI Survey dapat dilihat pada Gambar 3.13.

Gambar 3. 13 Activity Diagram Menampilkan Rekapitulasi EMI Survey

C. Menampilkan Grafik EMI Survey

Menampilkan EMI Survey dilakukan dengan cara mengklik button grafik yang telah disediakan di dalam halaman report, kemudian sistem akan memuat data EMI Survey yang diperlukan dari database berupa angka-angka jawaban dari responden. Angka-angka tersebut diolah menjadi nilai dari masing-masing

indikator EMI Survey. Proses menampilkan grafik EMI Survey dapat dilihat pada Gambar 3.14.

Gambar 3. 14 Activity Diagram Menampilkan Grafik EMI Survey

D. Mencatat Gap

Proses pencatatan gap ini yaitu: web menampilkan halaman gap. Kemudian tim OPI memasukkan data-data gap dan menyimpannya. Sistem akan menolak penyimpanan, jika data gap yang diisikan belum lengkap. Selain itu, sistem juga akan memberikan peringatan agar tim OPI melengkapi data gap-nya. Jika data telah lengkap, maka data akan disimpan ke dalam database. Proses Mencatat gap dapat dilihat pada Gambar 3.15.

Gambar 3. 15 Activity Diagram Mencatat Gap

E. Mencatat RCPS

Proses pencatatan RCPS ini yaitu: web menampilkan halaman RCPS. Kemudian Tim OPI memasukkan data-data RCPS dan menyimpannya. Sistem akan menolak penyimpanan, jika data RCPS yang diisikan belum lengkap. Selain itu, sistem juga akan memberikan peringatan agar tim OPI melengkapi data

RCPSnya. Jika data telah lengkap, maka data akan disimpan ke dalam database. Proses Mencatat RCPS dapat dilihat pada Gambar 3.16.

F. Memberikan Initiative untuk Gap

Proses pencatatan initiative ini yaitu: web menampilkan halaman initiative. Kemudian tim OPI memasukkan data-data initiative dan menyimpannya. Sistem akan menolak penyimpanan, jika data initiative yang diisikan belum lengkap. Selain itu, sistem juga akan memberikan peringatan agar tim OPI melengkapi data initiative nya. Jika data telah lengkap, maka data akan disimpan ke dalam database. Proses Memberikan Initiative untuk gap dapat dilihat pada Gambar 3.17.

G. Memberi Keputusan terhadap setiap Initiative

Setiap initiative adalah milik dari manajer. Untuk itu pemberian keputusan oleh manajer terhadap setiap intiative menjadi penting. Pada mulanya, pada proses manualnya, pemberian keputusan ini dilakukan saat rapat. Dengan OPTIMUS+, pemberian keputusan dilakukan dengan tujuan sebagai filter bagi iniatiatve-initiative yang akan ditindak-lanjuti. Proses Memberikan Keputusan terhadap setiap Initiative dapat dilihat pada Gambar 3.18.

Gambar 3. 18 Activity Diagram Memberi Keputusan terhadap setiap Initiative

H. Membuat Workplan

Initiative -Go atau initiative yang telah disetujui oleh manajer, harus ditindak-lanjuti oleh tim OPI dengan cara membuat workplan. Di dalam workplan tersebut terdapat dua hal penting, yaitu tanggal mulai dan tanggal akhir aktivitas. Dua tanggal itu masuk ke dalam daftar isian workplan. Setelah tim OPI selelsai mengisi data workplan dengan lengkap, menyimpan, maka sistem akan melakukan penyimpanan ke dalam database. Jika tidak, maka sistem akan memberikan peringatan agar tim OPI melengkapi data isian terlebih dahulu, kemudian coba menyimpannya lagi. Proses Membuat Workplan dapat dilihat pada Gambar 3.19.

I. Memperbarui Status Aktivitas Workplan

Status diperbarui karena perubahan tanggal dan/atau PIC memasukkan progress aktivitas workplan. Sistem akan memeriksa selisih tanggal sekarang dengan tanggal mulai/akhir aktivitas workplan. Selisih tanggal sekarang dengan tanggal mulai/akhir aktivitas workplan dapat berupa status “Belum Dimulai”, “Dalam Proses”, atau “Melebihi Deadline”. Sedangkan proses memasukkan progress workplan dapat mengubah status aktivitas menjadi “Selesai” atau “Ditunda”. Proses Memperbarui Status Aktivitas Workplan dapat dilihat pada Gambar 3.20.

J. Notifikasi via SMS

Notifikasi SMS ini diawali dengan penghitungan jumlah aktivitas sesuai statusnya. Hasilnya berupa rangkuman yang nantinya akan dikirim dengan menggunakan SMS kepada manajer selaku pemantau perkembangan initiative sebelum tanggal akhir aktivitas berakhir. Proses Notifikasi via SMS dapat dilihat pada Gambar 3.21.

3.3.3 Flow of Event

Detail spesifikasi Use Case ditulis dalam Flow of Event. Tujuan utama Flow of Event adalah untuk mendokumentasikan aliran logika dalam Use Case dan menjelaskan secara rinci apa yang pemakai akan lakukan serta apa yang sistem itu sendiri lakukan. Sistematika Flow of Event terdiri dari beberapa elemen berikut:

1.Deskripsi singkat 2.Prasyarat

3.Alur utama

4.Alur alternatif dan alur salah 5.Kondisi akhir

A. Flow of Event Use Case Mengisi EMI Survey

Flow of Event pada Tabel 3.1 menjelaskan tentang alur logika pada Use Case Mengisi EMI Survey. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Mengisi EMI Survey.

Tabel 3.1 Flow of Event Use Case Mengisi EMI Survey Deskripsi Use Case

Nama Use Case Mengisi EMI Survey

Deskripsi Singkat Mengisi EMI Survey oleh responden dilakukan untuk memperoleh Diagnose awal

Aktor Responden

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Pengguna mengklik link ke EMI Survey 2. Sistem menampilkan daftar pertanyaan EMI

Survey

3. Pengguna mengisi jawaban atas setiap pertanyaan EMI Survey

Deskripsi Use Case

meyimpan jawaban ke dalam database

5. Sistem mengkonfirmasi apakah pengguna telah yakin dengan jawabannya

6. Pengguna menekan tombol “Ya”

7. Pengguna dapat meninggalkan halaman EMI Survey

Alur Alternatif 3. 1. Jika pengguna tidak lengkap mengisi jawaban, dan pengguna menekan tombol “Simpan”, maka sistem akan menampilkan pesan dialog bahwa pengguna harus melengkapi jawabannnya terlebih dahulu

6. 1. Jika pengguna menekan tombol “Tidak”, maka data belum akan tersimpan dalam database. pengguna juga masih dapat memperbaiki jawabannya.

Kondisi Akhir Sukses Jawaban kuesioner tersimpan dalam database Kondisi Akhir Gagal Jawaban kuesioner tidak tersimpan dalam database

B. Flow of Event Use Case Menampilkan Rekapitulasi EMI Survey

Flow of Event pada Tabel 3.2 menjelaskan tentang alur logika pada Use Case Menampilkan Rekapitulasi EMI Survey. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Menampilkan Rekapitulasi EMI Survey.

Tabel 3.2 Flow of Event Use Case Menampilkan Rekapitulasi EMI Survey Deskripsi Use Case

Nama Use Case Menampilkan Rekapitulasi EMI Survey

Deskripsi Singkat Menampilkan Rekapitulasi EMI Survey oleh sistem dilakukan untuk memperoleh rekapitulasi yang dibutuhkan Tim OPI dan Manajer

Aktor Sistem

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Sistem memperoleh jawaban dari responden, lalu menyimpannya ke dalam database

2. Pengguna membuka laporan “Rekapitulasi EMI Survey”

3. Sistem mengunduh rekapitulasi yang berisi jawaban-jawaban EMI Survey

Deskripsi Use Case

dalam berkas Microsoft Excel. Alur Alternatif Tidak ada

Kondisi Akhir Sukses Sistem mengunduh dan menampilkan Rekapitulasi EMI Survey

Kondisi Akhir Gagal Sistem tidak dapat mengunduh dan menampilkan Rekpitulasi EMI Survey

C. Flow of Event Use Case Menampilkan Grafik EMI Survey

Flow of Event pada Tabel 3.3 menjelaskan tentang alur logika pada Use Case Menampilkan Grafik EMI Survey. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Menampilkan Grafik EMI Survey.

Tabel 3.3 Flow of Event Use Case Menampilkan Grafik EMI Survey Deskripsi Use Case

Nama Use Case Menampilkan Grafik EMI Survey

Deskripsi Singkat Menampilkan Grafik EMI Survey dilakukan untuk memperoleh masing-masing nilai indikator, kemudian menampilkannya dalam bentuk grafik EMI Survey

Aktor Sistem

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Sistem memperoleh jawaban yang dimasukkan responden

2. Sistem menghitung nilai masing-masing indikator yang berasal dari jawaban yang dimasukkan responden-responden dengan rumus masing-masing indikator

3. Pengguna membuka grafik EMI Survey 4. Sistem menampilkan grafik EMI Survey Alur Alternatif Tidak ada

Kondisi Akhir Sukses Sistem menampilkan grafik EMI Survey

Kondisi Akhir Gagal Sistem tidak dapat menampilkan grafik EMI Survey

D. Flow of Event Use Case Mencatat Gap

Flow of Event pada Tabel 3.4 menjelaskan tentang alur logika pada Use Case Mencatat Gap. Dari flow of Event tersebut dapat diketahui deskripsi singkat,

prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Mencatat Gap.

Tabel 3.4 Flow of Event Use Case Mencatat Gap

Deskripsi Use Case

Nama Use Case Mencatat Gap

Deskripsi Singkat Mencatat gap dilakukan untuk kebutuhan diagnosa

awal

Aktor Tim OPI

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Pengguna membuka halaman gap

2. Sistem menampilkan halaman entri gap 3. Pengguna memasukkan data gap 4. Sistem akan mengecek data gap yang

dimasukkan, apakah telah lengkap atau belum 5. Pengguna menekan tombol “Simpan”

Alur Alternatif 4.1 Jika data yang dimasukkan belum lengkap, dan

pengguna menekan tombol “Simpan”, maka akan keluar pesan peringatan bahwa data belum

lengkap

Kondisi Akhir Sukses Data gap tersimpan ke dalam database

Kondisi Akhir Gagal Data gap tidak tersimpan ke dalam database

E. Flow of Event Use Case Mencatat RCPS

Flow of Event pada Tabel 3.5 menjelaskan tentang alur logika pada Use Case Mencatat RCPS. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Mencatat RCPS.

Tabel 3.5 Flow of Event Use Case Mencatat RCPS Deskripsi Use Case

Nama Use Case Mencatat RCPS

Deskripsi Singkat Mencatat RCPS dilakukan untuk kebutuhan diagnosa awal

Aktor Tim OPI

Prasyarat (kondisi) Tidak ada

Deskripsi Use Case

2. Sistem menampilkan halaman entri RCPS 3. Pengguna memasukkan data RCPS 4. Sistem akan mengecek data RCPS yang

dimasukkan, apakah telah lengkap atau belum 5. Pengguna menekan tombol “Simpan”

Alur Alternatif 4.1 Jika data yang dimasukkan belum lengkap, dan pengguna menekan tombol “Simpan”, maka akan keluar pesan peringatan bahwa data belum lengkap Kondisi Akhir Sukses Data RCPS tersimpan ke dalam database

Kondisi Akhir Gagal Data RCPS tidak tersimpan ke dalam database

F. Flow of Event Use Case Membuat Initiative untuk Gap

Flow of Event pada Tabel 3.6 menjelaskan tentang alur logika pada Use Case Membuat Initiative untuk Gap. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Membuat Initiative untuk Gap.

Tabel 3.6 Flow of Event Use Case Membuat Initiative untuk Gap Deskripsi Use Case

Nama Use Case Membuat Initiative untuk Gap

Deskripsi Singkat Membuat initiative digunakan kebutuhan Design

Aktor Tim OPI

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Pengguna membuka halaman initiative 2. Sistem menampilkan halaman entri initiative 3. Pengguna memasukkan data initiative 4. Sistem akan mengecek data initiative yang

dimasukkan, apakah telah lengkap atau belum 5. Pengguna menekan tombol “Simpan”

Alur Alternatif 4.1 Jika data yang dimasukkan belum lengkap, dan pengguna menekan tombol “Simpan”, maka akan keluar pesan peringatan bahwa data belum lengkap Kondisi Akhir Sukses Data initiative tersimpan ke dalam database

G. Flow of Event Use Case Pemberian Keputusan terhadap Initiative Flow of Event pada Tabel 3.7 menjelaskan tentang alur logika pada Use Case Pemberian Keputusan terhadap Initiative. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Pemberian Keputusan terhadap Initiative.

Tabel 3.7 Flow of Event Use Case Pemberian Keputusan terhadap Initiative

Deskripsi Use Case

Nama Use Case Pemberian Keputusan terhadap Initiative Deskripsi Singkat Dilakukan ketika ada initiative yang perlu

dipertimbangkan terlebih dahulu oleh Manajer, apakah akan ditindaklanjuti (Go) atau tidak ditindaklanjuti (No-Go)

Aktor Manajer

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Pengguna membuka halaman initiative approval

2. Sistem menampilkan initiative-initiative yang perlu mendapatkan persetujuan

3. Memilih initiative

4. Pengguna mengklik “Simpan”

5. Sistem mengkonfirmasi, apakah pengguna telah yakin

Alur Alternatif 5.1 Jika pengguna belum yakin dengan initiative yang dipilihnya, pengguna dapat memeriksa pilihannya kembali dengan mengklik “Batal” terlebih dahulu Kondisi Akhir Sukses Intiative tersimpan dengan status, apakah Go atau

No-Go

Kondisi Akhir Gagal Intiative tidak tersimpan dengan status, apakah Go atau No-Go

H. Flow of Event Use Case Membuat Workplan

Flow of Event pada Tabel 3.8 menjelaskan tentang alur logika pada Use Case Membuat Workplan. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Membuat Workplan.

Tabel 3.8 Flow of Event Use Case Membuat Workplan Deskripsi Use Case

Nama Use Case Mencatat Workplan

Deskripsi Singkat Mencatat Workplan dilakukan untuk kebutuhan Design

Aktor Tim OPI

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Pengguna membuka halaman workplan 2. Sistem menampilkan initiative Go

3. Pengguna memilih salah satu initiative Go 4. Pengguna memasukkan workplan untuk

initiative yang dipilih

5. Sistem akan mengecek apakah data yang dimasukkan telah lengkap atau belum 6. Pengguna menekan tombol “Simpan” Alur Alternatif 5.1 Jika data yang dimasukkan belum lengkap, dan

pengguna menekan tombol “Simpan”, maka akan keluar pesan peringatan bahwa data belum

lengkap

Kondisi Akhir Sukses Data workplan tersimpan ke dalam database Kondisi Akhir Gagal Data workplan tidak tersimpan ke dalam database

I. Flow of Event Use Case Memperbarui Status Aktivitas Workplan

Flow of Event pada Tabel 3.9 menjelaskan tentang alur logika pada Use Case Update Status Aktivitas Workplan. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Update Status Aktivitas Workplan.

Tabel 3.9 Flow of Event Use Case Memperbarui Status Aktivitas Workplan

Deskripsi Use Case

Nama Use Case Update Status Aktivitas Workplan

Deskripsi Singkat Update Status Aktivitas workplan salah satunya dilakukan dengan memanfaatkan perubahan tanggal karena setiap aktivitas memiliki waktu pengerjaan yang berkaitan dengan statusnya. Selain itu dilakukan

dengan pengunggahan foto bukti.

Aktor Sistem dan PIC

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Pengguna membuka halaman workplan progress

Deskripsi Use Case

2. Sistem menampilkan workplan dan statusnya 3. PIC mengklik ID Aktivitas Workplan

4. Mengunggah berkas sebagai bukti bahwa aktivitas tersebut telah dilakukan/ditunda 5. Mengisi status aktvitas

6. PIC mengklik tombol “Simpan”

7. Sistem mengkonfirmasi apakah data yang dimasukkan telah benar

8. PIC menekan tombol “Ya”

Alur Alternatif 2.1Jika selisih tanggal mulai aktivitas dan tanggal sekarang kurang dari 0, maka sistem akan menampilkan status “Belum Dimulai”

2.2Jika selisih tanggal mulai aktivitas dan tanggal sekarang lebih dari atau sama dengan 0, maka sistem akan memeriksa selisih tanggal akhir dan tanggal sekarang

2.2.1 Jika selisih tanggal mulai aktivitas dan tanggal sekarang lebih dari 0, maka sistem akan menampilkan status “Melebihi Deadline”

2.2.2 Jika selisih tanggal mulai aktivitas dan tanggal sekarang kurang dari atau sama dengan 0, maka sistem akan

menampilkan status “Dalam Proses” 8.1Jika pengguna belum yakin dengan data yang

dimasukkan, pengguna dapat mengklik tombol “Tidak” dan memperbaikinya

Kondisi Akhir Sukses 1. Status “Belum Dimulai”, “Dalam Proses”, dan “Melebihi Deadline” dapat berubah sesuai perubahan tanggal

2. Data aktivitas tersimpan ke dalam database setelah tombol “Simpan” diklik

3. Status aktivitas berubah menjadi “Selesai” atau “Ditunda” jika PIC telah mengunggah berkas bukti

Kondisi Akhir Gagal 1. Status “Belum Dimulai”, “Dalam Proses”, dan “Melebihi Deadline” tidak dapat berubah sesuai perubahan tanggal

2. Data aktivitas tidak tersimpan ke dalam database setelah tombol “Simpan” diklik 3. Status aktivitas tidak berubah menjadi “Telah

Tercapai” ketika PIC selesai mengunggah berkas bukti

J. Flow of Event Use Case Notifikasi via SMS

Flow of Event pada Tabel 3.10 menjelaskan tentang alur logika pada Use Case Notifikasi via SMS. Dari flow of Event tersebut dapat diketahui deskripsi singkat, prasyarat, alur utama, alur alternatif dan alur salah, serta kondisi akhir dari Use Case Notifikasi via SMS.

Tabel 3.10 Flow of Event Use Case Notifikasi via SMS Deskripsi Use Case

Nama Use Case Notifikasi via SMS

Deskripsi Singkat Notifikasi via SMS digunakan untuk kebutuhan Deliver

Aktor Manajer

Prasyarat (kondisi) Tidak ada

Alur Utama 1. Pengguna membuka halaman notifikasi

2. Sistem merefresh halaman notifikasi dalam web per waktu tertentu

3. Per refresh, sistem menghitung jumlah aktivitas workplan sesuai statusnya (rekapitulasi

workplan)

4. Per refresh, sistem menampilkan rekapitulasi dalam web

5. Per refresh, sistem mengecek dalam database SMS Gateway, apakah terdapat SMS dengan tanggal sekarang sistem

Alur Alternatif 5.1Jika tidak ada, maka sistem akan

mengirimkankan SMS notifikasi ke Manajer 5.2Jika ada, maka sistem tidak akan

mengirimkankan SMS notifikasi ke Manajer Kondisi Akhir Sukses 1. Sistem menampilkan rekapitulasi workplan

2. SMS terkirim ke Manajer

Kondisi Akhir Gagal 1. Sistem tidak dapat menampilkan rekapitulasi workplan

2. SMS tidak terkirim ke Manajer

3.3.4 OPTIMUS+ Sequence Diagram

Sequence Diagram menjelaskan realisasi dari use case diagram. Diagram sequence merupakan salah satu diagram interaksi yang mengurutkan

alur berdasarkan waktu. Berikut ini adalah sequence diagram dari masing-masing use case diagram OPTIMUS+:

A. Mengisi EMI Survey

Proses dimulai ketika responden membuka halaman EMI Survey dalam website, kemudian web memberi respon dengan menampilkan halaman EMI Survey. Di dalam halaman EMI Survey tersebut, terdapat pertanyaan-pertanyaan kuesioner yang akan dijawab oleh responden. Selanjutnya, sistem akan memeriksa dengan control, apakah isian reponden telah lengkap atau belum. Jika belum, maka sistem akan menampilkan pesan agar responden melengkapi isian kuesionernya. Jika isian telah lengkap, maka data-data isian tersebut akan masuk ke dalam database. Sequence Diagram tersebut dapat dilihat pada Gambar 3.22.

Gambar 3. 22 Sequence Diagram Mengisi EMI Survey

B. Menampilkan Rekapitulasi EMI Survey

Perekapan EMI Survey dilakukan oleh sistem ketika ada perintah dari Tim OPI berupa klik untuk membuka rekap. Kemudian data-data yang dibutuhkan

dari database dimuat untuk ditampilkan dalam bentuk rekapitulasi. Rekapitulasi disini berupa berkas excel. Sequence Diagram tersebut dapat dilihat pada Gambar 3.23.

Gambar 3. 23 Sequence Diagram Menampilkan Rekapitulasi EMI Survey

C. Menampilkan Grafik EMI Survey

Penghitungan hasil EMI Survey dilakukan ketika ada perintah berupa klik dari Manajer untuk membuka grafik EMI Survey. Kemudian data yang dibutuhkan dari database di-load, dihitung oleh sistem sesuai rumus EMI Survey yang telah dibahas sebelumnya, lalu diperoleh hasil berupa angka-angka yang ditampilkan dalam grafik. Sequence Diagram tersebut dapat dilihat pada Gambar 3.24.

Gambar 3. 24 Sequence Diagram Menampilkan Grafik EMI Survey

D. Mencatat Gap

Untuk gap, Tim OPI dapat membuka halaman Gap. Dalam halaman gap tersebut terdapat data-data gap yang harus diisi. Data-data yang diisi akan dicek oleh sistem, tentang kelengkapannya. Jika lengkap, maka sistem akan menyimpan data-data tersebut ke dalam database. Jika belum, Tim OPI harus melengkapinya terlebih dahulu. Sequence Diagram tersebut dapat dilihat pada Gambar 3.25.

E. Mencatat RCPS

Pencatatan RCPS dimulai dengan Tim OPI mengklik menu RCPS. Lalu sistem akan menampilkan halaman RCPS yang di dalamnya terdapat masalah-masalah yang sudah/belum memiliki RCPS. Masalah yang belum memiliki RCPS dapat ditindaklanjuti dengan mengisi/mengentri form entri RCPS. Setelah itu, sistem akan merespon saat pengguna mengklik tombol “Simpan”. Sistem akan memberikan peringatan, jika isian belum lengkap. Sistem akan menyimpan data isian ke dalam database, jika isian telah lengkap. Sequence Diagram tersebut dapat dilihat pada Gambar 3.26.

Gambar 3. 26 Sequence Diagram Mencatat RCPS

F. Membuat Initiative untuk Gap

Pembuatan initiative untuk gap dilakukan dengan cara membuka halaman initiative . Pada halaman initiative akan ditemukan masalah-masalah yang telah melalui tahap RCPS. Ketika muncul halaman entri ini initiative maka Tim OPI akan mengisikan data-data yang dibutuhkan. Selanjutnya, sistem akan menyimpannya ke dalam database jika data yang diisikan telah lengkap. Sequence Diagram tersebut dapat dilihat pada Gambar 3.27.

Gambar 3. 27 Sequence Diagram Membuat Initiative Untuk Gap

G. Memberi Keputusan terhadap Initiative

Pemberian keputusan terhadap initiative dilakukan dengan membuka halaman initiative approval. Sistem akan menampilkan topik masalah yang telah melalui tahap RCPS dan pembuatan initiative . Dari sini, manajer selaku pemegang initiative dapat memilih initiative-initiative yang akan disetujui. Sebelum initiative yang disetujui masuk ke dalam database, terlebih dahulu sistem akan melakukan konfirmasi, apakah benar initiative tersebut yang disetujui. Sebab pemberian keputusan ini berpengaruh untuk proses selanjutnya. Sequence Diagram tersebut dapat dilihat pada Gambar 3.28.

Gambar 3. 28 Sequence Diagram Pemberian Keputusan terhadap initiative

H. Membuat Workplan

Initiative-Go adalah initiative yang disetujui oleh manajer. Dari manajer, proses berlanjut ke pembuatan workplan yang dihandle oleh Tim OPI kembali. Tim OPI dapat mengklik initiative yang akan dibuatkan workplannya dengan mengisi data-data yang dibutuhkan. Setelah itu, sistem akan mengecek kelengkapan data tersebut. Jika lengkap, simpan ke dalam database. Jika belum, sistem akan memberikan peringatan. Sequence Diagram tersebut dapat dilihat pada Gambar 3.29.

Gambar 3. 29 Sequence Diagram Membuat Workplan

I. Update Status Aktivitas Workplan

Ketika PIC membuka halaman workplan, maka akan ditampilkan data-data workplan yang ada beserta aktivitasnya dan status-status yang telah terupdate secara otomatis oleh sistem berdasarkan perubahan tanggal. Status-status ini diperoleh karena sistem mengecek selisih tanggal mulai/akhir dengan tanggal sekarang. Status-status berdasarkan perubahan tanggal tersebut antara lain: ‘Belum dimulai’, ‘Dalam Proses, dan ‘Melebihi Deadline’. Kemudian, dari data-data dan status-status yang ditampilkan tersebut, PIC dapat memilih id workplan mana yang akan diupdate statusnya menjadi ‘Ditunda’ atau ‘Selesai’ melalui pengisian data. Pengisian data selanjutnya akan diperiksa oleh sistem, jika lengkap maka sistem akan menyimpan data-data tersebut ke dalam database dan mengubah status yang semula ‘Belum dimulai’, ‘Dalam Proses, dan ‘Melebihi Deadline’ menjadi ‘Ditunda’ atau ‘Selesai’. Sequence Diagram tersebut dapat dilihat pada Gambar 3.30.

Gambar 3. 30 Sequence Diagram Update Status Aktivitas Workplan

J. Notifikasi (via SMS)

Halaman notifikasi selalu terbuka, dan sistem akan melakukan auto refresh halaman tersebut per waktu tertentu. Ketika terjadi refresh, sistem akan selalu menghitung berapa jumlah aktivitas workplan sesuai statusnya. Selain itu, per refresh tersebut sistem akan melakukan pengecekan apakah pada database Gammu sudah ada SMS notifikasi pada tanggal sekarang sistem atau belu. Jika belum, maka sistem akan melakukan pengiriman SMS. Jika sudah, maka sistem tidak akan melakukan pengiriman SMS lagi. Sequence Diagram tersebut dapat dilihat pada Gambar 3.31.

Gambar 3. 31 Sequence Diagram Notifikasi (via SMS)

3.3.5 Class Diagram OPTIMUS+

Class Diagram digunakan untuk menampilkan kelas-kelas di dalam sistem dan relasi antar kelas tersebut (menunjukkan interaksi antar kelas di dalam aplikasi). Menurut Sholiq, Satu diagram kelas menampilkan subset dari kelas-kelas dan relasinya. Diagram kelas-kelas lainnya, mungkin menampilkan kelas-kelas-kelas-kelas termasuk atribut dan operasi dari kelas-kelas pembentuk diagram. Sedangkan diagram kelas yang lainnya lagi, mungkin menampilkan paket-paket kelas dan relasi antar paket-paket.

Gambar 3.32 menunjukkan class diagram OPTIMUS+. Class diagram tersebut merupakan gambaran lengkap terhadap aplikasi yang akan dibangun. Class diagram tersebut juga menggambarkan aplikasi sebelum dituliskan menjadi kode program.

3.4 Desain Input dan Output Sistem

Pada tahap ini dilakukan perancangan input/output untuk berinteraksi antara pengguna dengan sistem. Desain antarmuka ini dibuat dengan menggunakan perangkat lunak Pencil. Adapun desain tampilan yang akan digunakan yaitu sebagai berikut:

3.4.1 Rancangan Tampilan EMI Survey

Tampilan EMI Survey akan muncul ketika pengguna mengklik link EMI Survey. Pada tampilan ini terdapat Combo-box untuk memilih status responden serta waktu pengisian EMI Survey. Selain itu, terdapat daftar pertanyaan dan pilihan jawaban kuesioner. Rancangan tampilan dapat dilihat pada Gambar 3.33.

Gambar 3. 33 Tampilan EMI Survey

3.4.2 Rancangan Tampilan Gap

Tampilan gap akan muncul ketika pengguna memilih menu gap pada menu. Pada tampilan ini terdapat Combo-button Unit/Rayon untuk memilih gap

dari Rayon mana yang akan ditampilkan. Selain itu, terdapat button Entri Problem/Gap. Jika button ini diklik, maka akan menampilkan suatu halaman baru untuk mengentri gap. Rancangan tampilan dapat dilihat pada Gambar 3.34.

Gambar 3. 34 Tampilan Gap

Tampilan halaman Entri gap pada Gambar 3.35 digunakan untuk masukan data-data gap yang dibutuhkan, salah satunya adalah tombol unggah. Berkas nggah dalam entri gap ini adalah lampiran berupa berkas .jpg atau .pdf. Lampiran ini nantinya difungsikan sebagai bukti bahwa memang terdapat permasalahan yang mungkin untuk mendapatkan perbaikan.

3.4.3 Rancangan Tampilan RCPS

Tampilan RCPS pada Gambar 3.36 akan muncul ketika pengguna memilih menu RCPS. Tampilan ini menampilkan root-cause atau penyebab dari suatu permasalahan/gap/problem dan problem solving dari permasalahan tersebut. Terdapat combo-button yang terdiri dari dua pilihan, yaitu: Problem belum ada RCPS dan Problem sudah ada RCPS. Problem belum ada RCPS artinya terdapat problem/gap yang belum dilanjutkan ke tahap RCPS sama sekali. Sedangkan RCPS sudah ada gap artinya suatu gap sudah memiliki RCPS.

Pada gambar di atas juga terdapat link Unggah RCPS. Link Unggah RCPS adalah link ke halaman unggah. Unggah dapat dilakukan lebih dari sekali, sebanyak RCPS yang ditemukan. Misalnya, gap/Diagnose awal adalah gangguan listrik. Root cause bisa jadi lebih dari satu, yaitu karena binatang yang merusak kabel, karena usia peralatan, karena hujan/petir, atau karena isolator yang kotor, dan masih ada lagi alasan yang lain. Untuk itu, Unggah RCPS ini diperlukan, agar masing-masing sebab tadi menjadi jelas. Rancangan tampilan Unggah RCPS ini dapat dilihat pada Gambar 3.37.

Gambar 3. 37 Tampilan Unggah RCPS

3.4.4 Rancangan Tampilan Initiative

Tampilan initiative menampilkan initiative . Pada tampilan terdapat combo-button yang terdiri dari dua pilihan, yaitu: RCPS belum ada initiative dan

RCPS sudah ada initiative . RCPS belum ada initiative artinya RCPS tersebut belum memiliki initiative . Untuk itu, di kolom Kode Diagnose diberi link untuk entri initiative. Rancangan tampilan dapat dilihat pada Gambar 3.38.

Gambar 3. 38 Tampilan Initiative

Pada halaman entri initiative dibutuhkan masukan seperti judul initiative, nama-nama yang termasuk sebagai tim member serta leader dalam gap dengan kode Diagnose yang terpilih. Rancangan tampilan dapat dilihat pada Gambar 3.39.

3.4.5 Rancangan Tampilan Initative Approval

Tampilan initiative approval adalah tampilan untuk manajer. terdiri dari Kode initiative (kode yang diperoleh karena suatu gap telah melalui tahap RCPS dan tahap Initiative sebelumnya), judul initiative , dan keputusan manajer (Go/No-Go). Rancangan tampilan Initative Approval dapat dilihat pada Gambar 3.40.

Gambar 3. 40 Tampilan Halaman Persetujuan Initiative

Keputusan manajer ini berpengaruh pada tahap selanjutnya. Karena initiative yang telah dipertimbangkan untuk Go akan maju dan direalisasikan menjadi workplan atau rangkaian aktivitas kerja. Jika No-Go maka initiative itu berakhir di tahap itu saja.

Keputusan manajer ini diperoleh tidak dengan keputusan sepihak oleh manajer saja, melainkan terdapat rapat untuk berdiskusi. Dalam aplikasi ini, rapat serta proses menyangkut persetujuan manajer, diwujudkan seperti tampilan ini serta fungsinya.

3.4.6 Rancangan Tampilan Workplan

Tampilan workplan akan muncul jika pengguna memilih menu workplan. Initiative-Go akan masuk ke dalam tahap ini, yaitu pembuatan workplan. Rancangan tampilan dapat dilihat pada Gambar 3.41.

Gambar 3. 41 Tampilan Workplan

Pada Gambar 3.41 terdapat link menuju halaman untuk memasukkan data-data workplan. Melalui form entri workplan tersebut, pengguna dapat menambahkan aktivitas workplan apa saja yang akan dilakukan serta waktu yang dibutuhkan untuk pengerjaan aktivitas tersebut. Waktu ditandai dengan tanggal mulai dan tanggal akhir. Rancangan tampilan entri workplan dapat dilihat pada Gambar 3.42.

Gambar 3. 42 Tampilan Entri Workplan

Gambar 3.43 menjelaskan tentang tampilan workplan yang telah dimasukkan. Tanggal mulai dan akhir aktivitas yang dimasukkan pada form entri workplan sebelumnya, akan menjadi salah satu patokan bagi perubahan status aktivitas workplan (“Belum dimulai” jika tanggal sekarang belum masuk tanggal mulai aktivitas, “Dalam Proses” jika tanggal sekarang berada di antara tanggal mulai dan akhir aktivitas, dan “Melebihi Deadline” jika tanggal sekarang melewati tanggal akhir aktivitas dan aktivitas tersebut belum terselesaikan). Status workplan ditandai dengan warna dan keterangan di sampingnya.

Gambar 3. 43 Tampilan Workplan Progress

3.4.7 Rancangan Tampilan Entri Workplan Progress

Tampilan ini akan muncul jika pengguna memilih menu Workplan Progress. Halaman entri ini digunakan untuk menguppdate status aktivitas workplan menjadi ‘Selesai’ atau ‘Ditunda’. Combo-box status berisi pilihan apakah suatu aktivitas ‘Selesai’ atau ‘Ditunda’. Rancangan tampilan dapat dilihat pada Gambar 3.44.

3.4.8 Rancangan Tampilan Grafik EMI Survey

Tampilan ini akan muncul jika pengguna memilih menu report, lalu mengklik button grafik EMI Survey. Grafik ini merupakan salah satu output dari pengisian EMI Survey yang dilakukan oleh responden sebelumnya. Dalam grafik terdapat nilai dari tujuh indikator EMI Survey. Rancangan tampilan dapat dilihat pada Gambar 3.45.

Gambar 3. 45 Tampilan Grafik EMI Survey

Terdapat tiga warna batang grafik, yaitu merah yang menandakan bahwa asumsi responden terhadap sebuah indikator rendah; kuning yang menandakan bahwa asumsi responden terhadap sebuah indicator sedang; dan hijau yang menandakan bahwa asumsi responden terhadap sebuah indikator tinggi. Setiap batang pada grafik akan memunculkan warna sesuai dengan nilainya. Untuk nilai indikator 0 hingga 4,5, batang grafik akan berwarna merah; untuk nilai indikator lebih dari 4,5 hingga kurang dari 5, batang grafik akan berwarna kuning; dan

untuk nilai indikator lebih dari atau sama dengan 5, batang grafik akan berwarna hijau. Pewarnaan tiap batang grafik sesuai nilainya ini dapat digunakan untuk mempermudah melihat indikator mana yang memiliki asumsi rendah. Sebab tiga indikator dengan asumsi paling rendah akan dibahas lebih lanjut dengan cara dijadikan bahan gap.

3.4.9 Rancangan Tampilan Rekapitulasi EMI Survey

Untuk mendapatkan rekapitulasi EMI Survey, pengguna harus ke menu report, kemudian mengklik button rekapitulasi. Untuk selanjutnya, rekapitulasi EMI Survey akan muncul sebagai unduhan dalam format .xlsx. Rancangan tampilan dapat dilihat pada Gambar 3.46.

Gambar 3. 46 Tampilan Rekapitulasi EMI Survey

3.4.10 Rancangan Tampilan Rekapitulasi Workplan

Tampilan ini akan muncul jika pengguna memilih menu report, lalu mengklik button Notifikasi. Tampilan di atas menjelaskan tentang rekapitulasi workplan dari masing-masing rayon dan tingkat bagian, juga PLN SBB secara keseluruhan. Rancangan tampilan dapat dilihat pada Gambar 3.47.

Gambar 3. 47 Tampilan Rekapitulasi Workplan

3.4.11 Rancangan Tampilan Notifikasi via SMS

Tampilan di bawah ini menjelaskan tentang notifikasi via SMS. Rekapitulasi workplan, selain ditampilkan di dalam web, juga dikirimkan melalui SMS. Rancangan tampilan notifikasi via SMS dapat dilihat pada Gambar 3.48.

4.1 Implementasi Sistem

Tahap ini merupakan pembuatan perangkat lunak yang disesuaikan dengan rancangan atau desain sistem yang telah dibuat. Aplikasi OPTIMUS+ yang dibuat diterapkan dan disesuaikan dengan kebutuhan. Adapun langkah-langkah dalam melakukan implementasi, antara lain:

4.1.1 Pembuatan Basis Data dan Jaringan

Sesuai dokumen PLN, activity diagram, flow of event, serta sequence diagram yang telah dibahas pada bab tiga, dapat diketahui data apa saja yang dibutuhkan oleh aplikasi. Untuk menampung data-data tersebut, digunakan Microsoft SQL Server. Sementara itu, untuk jaringan aplikasi, digunakan Local Area Network (LAN) yang telah ada.

4.1.2 Pengkodean

Pengkodean dilakukan untuk menterjemahkan rancangan desain UML pada bab sebelumnya. Untuk aplikasi ini, digunakan bahasa pemrograman PHP karena menurut Kadir (2002), PHP dirancang untuk membentuk web dinamis. Selain itu, dengan menggunakan PHP, maintenance suatu situs web menjadi lebih mudah (Sidik, 2001). Pada tahap ini dihasilkan aplikasi dengan sitemap yang ditunjukkan pada Gambar di bawah ini:

OPTIMUS+

Gap RCPS Initiative Initiative

Approval Workplan Workplan Progress Report EMI Survey Notifikasi Rekapitulasi EMI Survey Grafik EMI Survey Notifikasi via SMS Entri Workplan Progress Entri Workplan Tambah/Edit

Gap Unggah RCPS

Daftar RCPS Sudah/Belum Memiliki RCPS Daftar Initiative EMI Survey Halaman Petunjuk EMI Survey Kuesioner EMI Survey Daftar Gap Daftar Gap Sudah/Belum Memiliki RCPS Tambah Initiative Daftar Initiative-Go Daftar Workplan

Gambar 4.1 Sitemap OPTIMUS+

4.1.3 Pemasangan Sistem Baru

Tahap ini dilakukan untuk mengetahui apakah kebutuhan integrasi sistem baru terpenuhi atau tidak. Pada tahap ini dilakukan pemasangan basis data yang telah dibuat, penyediaan perangkat keras yang dibutuhkan seperti PC; modem; dan ponsel, serta pengevaluasian sistem.

4.2 Evaluasi Sistem

Untuk memastikan bahwa sistem telah dibuat sesuai dengan kebutuhan atau tujuan yang diharapkan maka dilakukan beberapa uji coba. Uji coba meliputi pengujian terhadap fitur dasar aplikasi, uji coba perhitungan dan uji coba validasi pengguna terhadap aplikasi dengan menggunakan blackbox testing.

4.2.1 Uji Coba dan Evaluasi Form EMI Survey

Uji coba ini bertujuan untuk mengetahui keberhasilan proses tambah data kuesioner EMI Survey. Dalam form EMI Survey ini, pengguna adalah responden (pegawai / outsourcing). Pengguna bisa melakukan simpan setelah pengisian survei selesai dilakukan. Gambar 4.2 menunjukkan uji coba form EMI Survey.

Gambar 4.2 Form EMI Survey

Gambar 4.3 menujukkan sebuah pemberitahuan yang akan muncul setelah proses penyimpanan jawaban kuesioner selesai dilakukan. Munculnya pemberitahuan tersebut agar pengguna mengetahui apakah proses penyimpanan telah berhasil atau belum.

Setelah dilakukan uji coba, dilakukan evaluasi terhadap form EMI Survey. Tabel 4.1 menunjukkan hasil dari uji coba form EMI Survey.

Tabel 4.1 Evaluasi EMI Survey Test

Case ID

Tujuan Input Output

Diharapkan

Output Dihasilkan 1 Mengisi Data

Kuesioner Memasukkan data kuesioner Data baru berhasil tersimpan ke dalam database lalu muncul pemberitahuan bahwa penyimpanan berhasil 1. Simpan berhasil, 2. Pemberitahuan Muncul

4.2.2 Uji Coba dan Evaluasi Form Login

Uji coba ini bertujuan untuk mengetahui keberhasilan proses inputan data yang dapat dilakukan melalui aplikasi seperti terlihat pada Gambar 4.4. Proses login dilakukan dengan cara menginputkan nama pengguna dan kata sandi. Berdasarkan nama pengguna dan kata sandi ini, akan diketahui priviledges login masing-masing pengguna.

Pengguna aplikasi terdiri dari: Tim OPI, PIC, dan Manajer Area. Masing-masing user memiliki hak Masing-masing-Masing-masing dalam aplikasi. Tim OPI, misalnya, dapat melakukan maintenance terhadap data Gap, RCPS, Initiative, dan Workplan, serta mendapatkan informasi mengenai rekapitulasi EMI Survey. Sementara PIC, dapat melakukan pengupdate-an status aktivitas Workplan jika telah melakukan aktivitas tersebut. Kemudian Manajer Area, dapat mengetahui berbagai informasi dari output yang dihasilkan oleh aplikasi. Output tersebut, misalnya, grafik EMI Survey, Rekapitulasi EMI Survey, informasi mengenai perkembangan Initiative.

Adapun menu utama dari masing-masing pengguna, antara lain: Gambar 4.5 menunjukkan form utama untuk Tim OPI, Gambar 4.6 menunjukkan form utama untuk PIC, dan Gambar 4.7 menunjukkan form utama untuk Manajer setelah berhasil login.

Gambar 4.6 Form Utama PIC

Gambar 4.8 di bawah ini, menjelaskan bahwa apabila nama pengguna atau kata sandi salah maka sistem akan berpindah ke halaman pemberitahuan bahwa nama pengguna dan kata sandi yang dimasukkan salah.

Gambar 4.8 Peringatan Login Gagal

Setelah dilakukan uji coba, dilakukan evaluasi terhadap form Login. Tabel 4.2 menunjukkan hasil dari uji coba form Login.

Tabel 4.2 Evaluasi Form Login Test

Case ID

Tujuan Input Output

Diharapkan

Output Sistem 2 Deskripsi nama

pengguna dan kata sandi valid Memasukkan nama pengguna dan kata sandi Form login berganti menjadi form utama 1. login berhasil, 2. Masuk ke dalam form utama 3 Deskripsi nama

pengguna dan kata

Memasukkan nama

Muncul halaman pembertahuan

1. login tidak berhasil, 2.

Test Case ID

Tujuan Input Output

Diharapkan

Output Sistem sandi tidak valid pengguna dan

kata sandi yang salah

bahwa nama pengguna dan kata sandi salah

Masuk ke halaman

pemberitahuan 4 nama pengguna dan

kata sandi tidak ada atau kosong Tidak mengisi nama pengguna dan kata sandi Muncul halaman pemberitahuan bahwa nama pengguna dan kata sandi salah

1. login tidak berhasil, 2. Masuk ke halaman

pemberitahuan

4.2.3 Uji Coba dan Evaluasi Form Gap

Uji coba ini bertujuan untuk mengetahui keberhasilan proses tambah dan edit data Gap. Gambar 4.9 menunjukkan daftar gap yang telah dimasukkan. Pada combo box terdapat keterangan bahwa gap yang sedang ditampilkan adalah milik Karang Pilang. Sementara keterangan “Unit : Taman” di samping tombol Entri Gap Baru adalah unit dari pengguna. Pengguna dari form ini adalah Tim OPI. Untuk pengguna Tim OPI, tombol Entri Gap Baru ini aktif. Tim OPI diberi hak untuk memasukkan data gap sesuai rayonnya/unitnya serta melihat daftar gap dari seluruh rayon maupun tingkat bagian. Sementara untuk pengguna lain, tombol Entri Gap Baru tidak aktif. Pengguna lain hanya bisa melihat daftar gap dari seluruh rayon maupun tingkat bagian.

Gambar 4.9 Form Gap

Uji coba untuk menambah data pada form gap, dilakukan dengan menekan tombol Entri Gap Baru. Gambar 4.10, 4.12, dan 4.13 menunjukkan form Entri Gap. Form tersebut hanya bisa diisi oleh Tim OPI dari rayon/unitnya. Gambar 4.10, 4.12, dan 4.13 menunjukkan contoh untuk unit/rayon Taman, sesuai unit/rayon yang muncul pada Form Gap pada Gambar 4.9.

Pada Gambar 4.10 dilakukan uji coba dengan melakukan pengisian form entri gap secara tidak lengkap. Satuan, Polaritas, dan Upload File adalah item-item masukan yang tidak diisi. Jika data gap yang dimasukkan tidak lengkap, maka akan muncul pemberitahuan bagi pengguna agar melengkapi data tersebut terlebih dahulu sebelum melakukan proses penyimpanan.

Gambar 4.10 Form Entri Gap (Periksa Kelengkapan Pengisian Data)

Gambar 4.11 menunjukkan peringatan yang muncul bagi pengguna jika data yang dimasukkan belum lengkap. Pengguna bisa melengkapi data kembali untuk melakukan penyimpanan.

Gambar 4.12 menunjukkan uji coba terhadap Upload File (Unggah Berkas). Berkas yang dapat diunggah memiliki ketentuan sebagai berikut: ukuran berkas maksimal 3 MB dan jenis berkas .jpg atau .pdf. Pada Gambar 4.12 ditunjukkan uji coba dengan memasukkan berkas jenis .wmv dengan ukuran 25 MB.

Gambar 4.12 Form Entri Gap (Periksa Upload File)

Hasil yang diperoleh dari pengujian tersebut adalah munculnya kotak dialog/pemberitahuan bagi pengguna bahwa berkas yang dimasukkan tidak sesuai dengan ketentuan. Gambar 4.13 menunjukkan kotak dialog tersebut.

Gambar 4.13 Pemberitahuan File Upload Tidak Sesuai Ketentuan

Gambar 4.14 menunjukkan form entri gap yang dilakukan sesuai ketentuan. Uji coba pada Gambar 4.14 akan menunjukkan apakah penyimpanan data berhasil dilakukan atau tidak.

Setelah proses penyimpanan data selesai dilakukan, pemberitahuan seperti pada Gambar 4.15 akan muncul sebagai tanda bahwa proses penyimpanan data berhasil dilakukan.

Gambar 4.15 Pemberitahuan Data Gap Telah Tersimpan

Gambar 4.16 menunjukkan data gap yang telah berhasil dimasukkan. Data yang dimasukkan pada Gambar 4.14 muncul pada daftar gap pada Gambar 4.16.

Uji coba pada Gambar 4.17 menunjukkan form untuk edit data Gap. Sama halnya dengan entri gap, edit gap hanya bisa dilakukan oleh Tim OPI. Pada Gambar 4.17, Polaritas dari gap diubah dari “Baik bila Skala Naik” menjadi “Baik bila Skala Turun”.

Gambar 4.17 Form Edit Gap

Data yang berhasil diperbarui akan memunculkan pemberitahuan seperti pada Gambar 4.18. Setelah itu, halaman akan kembali ke form utama Gap.

Gambar 4.18 Pemberitahuan Update Data Berhasil

Data yang berhasil diperbarui akan muncul pada form utama Gap. Gambar 4.19 menunjukkan data yang telah diperbarui melalui form edit. Polaritas gap dengan kode D-201403-51161-001 yang awalnya positif (+) berubah menjadi negative (-).

Data-data kuesioner yang telah diinputkan oleh responden akan masuk ke dalam rekapitulasi tersebut. Selanjutnya sistem akan menghitung sesuai formula EMI Survey menggunakan fungsi yang ada dalam Microsoft Excel.

Gambar 4.45 Grafik EMI Survey

Pada uji coba selanjutnya, yaitu mengelola data kuesioner menjadi grafik EMI Survey pada halaman laporan, dilakukan dengan mengklik tombol grafik EMI Survey. Gambar uji coba Mengelola data kuesioner menjadi grafik EMI Survey dapat dilihat pada Gambar 4.30. Hasil perhitungan dalam grafik ini akan selalu sama dengan hasil yang diperoleh dalam rekapitulasinya.

Pada Gambar 4.31 terdapat rekapitulasi workplan via web. Pada sistem sebelumnya belum ada informasi mengenai rekapitulasi Workplan Progress. Ketika dilakukan wawancara, juga dengan pengamatan/observasi peneliti, Manajer Area

106

selaku pemilik Initiative belum mendapatkan informasi yang seharusnya, yaitu informasi yang memudahkannya mengetahui perkembangan Initiative. Oleh karena itu, pada OPTIMUS+ ditambahkan laporan berupa rekapitulasi Workplan dari masing-masing rayon/tingkat bagian.

Gambar 4.46 Rekapitulasi Workplan

Sesuai dengan kebutuhan Manajer Area, yang mana tidak selalu berada di kantor untuk mengecek kondisi Workplan Progress, maka rekapitulasi Workplan tersebut juga disajikan via SMS. SMS dikirimkan setiap hari kepada Manajer secara otomatis. Gambar 4.32 menunjukkan SMS rekapitulasi workplan.

Gambar 4.47 Rekapitulasi Workplan via SMS

Setelah dilakukan uji coba, dilakukan evaluasi terhadap form Report. Tabel 4.8 menunjukkan hasil dari uji coba form Report.

Tabel 4.9 Evaluasi Report Test

Case ID

Tujuan Input Output

Diharapkan

Output Dihasilkan 12 Mengelola data

kuesioner menjadi rekapitulasi EMI Survey Melakukan klik pada button rekapitulasi EMI Survey Rekapitulasi EMI Survey berhasil diproses 1. Proses berhasil, 2. Muncul rekapitulasi EMI Survey dalam bentuk file .xlsx 13 Mengelola data

kuesioner menjadi Grafik EMI Survey Melakukan klik pada button Grafik EMI Survey Grafik EMI Survey berhasil diproses 1. Proses berhasil, 2. Muncul Grafik EMI Survey 14 Mengelola data

aktivitas Workplan menjadi laporan Melakukan klik link laporan perkembangan Laporan perkembangan Initiative berhasil 1. Proses berhasil, 2. Laporan muncul

108

Test Case ID

Tujuan Input Output

Diharapkan

Output Dihasilkan perkembangan

Initiative per unit

Initiative diproses 15 Mengelola data

Workplan menjadi laporan perkembangan Initiative via SMS

Sistem merefresh halaman Notifikasi

SMS terkirim ke nomer tujuan

SMS terkirim ke nomer tujuan

Dari hasil uji coba dan evaluasi secara keseluruhan, dapat diketahui bahwa aplikasi dapat menghasilkan informasi aktivitas workplan yang aktual untuk PIC. Aplikasi juga dapat menghasilkan rekapitulasi workplan via SMS, sehingga Manajer dapat memperoleh informasi mengenai workplan dimana saja. Selain itu, pada EMI Survey, sistem dapat menghasilkan output berupa rekapitulasi dan grafik EMI Survey.

BAB V PENUTUP

5.1 Kesimpulan

Setelah dilakukan uji coba dan evaluasi terhadap aplikasi OPTIMUS+, maka dapat diambil beberapa kesimpulan sebagai berikut :

1. Dengan status aktivitas workplan yang aktual/terkini, PIC dapat mengontrol setiap aktivitas workplan serta waktu pengerjaannya sesuai status terkini, dan penggunaannya telah diuji menggunakan kuesioner dengan hasil: Goal = 4.05, Posession = 4.01, Place = 4.27, Form = 4.14, Time = 3.93, Actualization = 4 dengan skala 1 sampai 5

2. Dengan rekapitulasi workplan yang disajikan dalam website maupun via SMS, Manajer dapat memperoleh informasi yang tepat/sesuai untuk kebutuhan pemantauan perkembangan initiative baik di dalam maupun luar kantor, dan penggunaannya telah diuji menggunakan kuesioner dengan hasil: Goal = 4.05, Posession = 4.01, Place = 4.27, Form = 4.14, Time = 3.93, Actualization = 4 dengan skala 1 sampai 5

3. Sistem memiliki modul EMI Survey Online, yang memiliki output berupa rekapitulasi dan grafik EMI Survey.

5.2 Saran

Saran untuk pengembangan sistem adalah dengan menambahkan sistem berbasis mobile untuk menangani unggah berkas aktivitas workplan, sehingga pengunggahan bisa dilakukan dimana saja.

DAFTAR PUSTAKA

Falahah, Juli 2011, “Evaluasi Implementasi Sistem Informasi dengan Pendekatan Utility System”. Kursor. Volume 6, No. 2, http://kursor.trunojoyo.ac.id/wp-content/uploads/2012/05/0602_p3.pdf, 24 Maret 2014.

Hapsari. 2012. Simulasi EMI. Surabaya.

PT. PLN (Persero) Distribusi Jawa Timur. 2012. Roadmap Operational Performance Improvement (OPI). Surabaya.

PT. PLN (PERSERO). 2012. Modul Pelatihan OPTIMUS. Jakarta.

PT. PLN (Persero). t.t. Sosialisasi SOP Aplikasi OPTIMUS.

http://optimus.pln.co.id/index.php/kabar-opi/47-sosialisasi-sop-aplikasi-optimus. Diakses pada tanggal 11 April 2013.

Purnamasari, Chindie. 2010. Implementasi SMS Gateway dalam Solusi

Penyediaan Laporan eserta Didik Kursus. http://courseware.politekniktelkom.ac.id/Jurnal%20Proyek%20Akhir/TK/J

urnal%20PA%20Cindi.pdf. Diakses pada tanggal 16 April 2013.

Romeo, 2003. Testing dan Implementasi Sistem, Edisi Pertama. Surabaya: STIKOM Surabaya.

Sholiq. 2010. Analisis dan Perancangan Berorientasi Obyek. Bandung : Muara Indah.