TA : Rancang Bangun Aplikasi Workflow Persetujuan Permintaan Kebutuhan Workshop Pada Departemen Hse (Health, Safety, Environment, dan Module And Training) PT. Bangun Sarana Baja.

RANCANG BANGUN APLIKASI WORKFLOW PERSETUJUAN PERMINTAAN KEBUTUHAN WORKSHOP PADA DEPARTEMEN HSE (HEALTH, SAFETY, ENVIRONMENT, DAN MODULE AND TRAINING) PT. BANGUN SARANA BAJA

TUGAS AKHIR

Program Studi S1 Sistem Informasi

Oleh:

RANGGA DINANTA 09410100040

FAKULTAS TEKNOLOGI DAN INFORMATIKA

INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA 2016

ix DAFTAR ISI

Halaman

ABSTRAK...vi

KATA PENGANTAR...vii

DAFTAR ISI...ix

DAFTAR TABEL...xii

DAFTAR GAMBAR...xiii

BAB I PENDAHULUAN...1

1.1 LATARBELAKANGMASALAH...1

1.2 PERUMUSANMASALAH...4

1.3 PEMBATASANMASALAH...4

1.4 TUJUANPENELITIAN...4

1.5 SISTEMATIKAPENULISAN...5

BAB II LANDASAN TEORI...5

2.1 WFMS………...7

2.1.1 Keuntungan Penggunaan WFMS…......8

2.1.2 Permintaan Barang………....9

2.2 WEBSITE...9

2.3 SISTEM...10

2.4 SISTEMINFORMASI...10

2.5 PHP...11

2.6 SERVER...12

x

2.8 KONSEPBASISDATA ... ...13

2.9 PERANGKATLUNAKYANGDIGUNAKAN ... 14

2.10 SDLC ... 15

2.10.1 Waterfall ... 15

2.10.2 Fase Dalam Metode Waterfall ... 17

2.11 BLACK BOX TESTING... 18

BAB III ANALISIS DAN PERANCANGAN SISTEM ... 19

3.1 ANALISIS ... 19

3.1.1 Identifikasi Masalah ... 19

3.1.2 Analisis Kebutuhan Sistem ... 21

3.2 PERANCANGANSISTEM ... 23

3.2.1 Blok Diagram ... 24

3.2.2 System Flow ... 29

3.2.3 Diagram Jenjang ... 32

3.2.4 Data Flow Diagram (DFD) ... 35

3.2.5 Entity Relationship Diagram (ERD) ... 40

3.2.6 Struktur Tabel ... 41

3.2.7 Desain User Interface ... 47

3.2.8 Desain Input/Output ... 52

3.3 PERANCANGANUJICOBA ... 56

BAB IV IMPLEMENTASI DAN EVALUASI ... 60

4.1 KEBUTUHANIMPLEMENTASI ... 61

xi

4.1.2 Perangkat Lunak ... 61

4.2 IMPLEMENTASISISTEM ... 61

4.3 EVALUASIHASILPENGUJIANSISTEM ... 62

BAB V PENUTUP ... 86

5.1 KESIMPULAN ... 86

5.2 SARAN... 86

1 BAB I PENDAHULUAN

1.1 Latar Belakang Masalah

PT. Bangun Sarana Baja (BSB) merupakan perusahaan yang bergerak di bidang manufaktur sebagai fabrikator struktur baja berskala besar. Head Office perusahaan ini berkedudukan di Jl. Mayjend Sungkono XII/8, Gresik. PT. Bangun Sarana Baja didirikan pada tahun 1985 dengan luas lahan hanya 16.000 M2. Sekarang telah diperluas menjadi total 130.000 M2. Struktur organisasi yang dimiliki PT. Bangun Sarana Baja dipimpin oleh ketua dan beberapa manager yang memimpin beberapa bagian yang mendukung proses kegiatan workshop dan oprasional.

Salah satu bagian yang mendukung proses kegiatan workshop adalah departemen HSE (health, safety, environment, dan module and training). Dalam mendukung kegiatan workshop departemen HSE membagi kegiatan menjadi dua kategori, yaitu workshop dalam dan workshop luar. Kegiatan tersebut dilakukan dengan adanya invoice berupa form atau memo yang masuk dari bagian lain, instansi luar maupun memo atau surat dari bagian HSE yang ditujukan untuk bagian lain dan instansi luar. Dari invoice tersebut terdapat proses permintaan kebutuhan workshop. Transaksi tersebut menghasilkan form maupun dokumen yang akan digunakan untuk proses pembelian kebutuhan workshop.

Saat ini, proses permintaan kebutuhan workshop dalam dan workshop luar dimulai dari Pemohon mengisi form atau memo permintaan kebutuhan barang kepada admin umum, kemudian admin umum membuat detail daftar

kebutuhan barang dan pembuatan surat permohonan kepada kepala bagian maupun proses persetujuan kepada manager HSE. Dalam perjalanannya sebelum dokumen mendapatkan persetujuan dari kepala bagian dan manager, akan terjadi proses revisi, masukan, reject, cancel dan lain-lain. Setelah dokumen disetujui kepala bagian dan manager, selanjutnya admin umum akan menyerahkan surat permohonan yang telah disetujui kepada bagian purchasing untuk dilakukan proses pembelian kebutuhan workshop, setelah pembelian dilakukan dan barang diterima pihak perusahaan, bagian purchasing akan langsung mengalokasikan kebutuhan workshop kepada unit bagian pemohon, sesuai dengan keterangan di surat permohonan permintaan barang.

Dari proses bisnis yang dijelaskan diatas terdapat permasalahan dalam proses persetujuan. Proses ini harus dilakukan secara langsung antara pemohon, kepala bagian, maupun manager. Namun, pada kenyataannya kepala bagian yang terkait maupun manager HSE sering tidak ada di tempat. Dalam satu kegiatan

workshop pada bulan Mei Tahun 2015, seperti yang nampak pada tabel 1.

3

Dari 12 permohonan persetujuan pengadaan barang, 4 diantaranya mengalami penundaan persetujuan. Hal ini menyebabkan proses permintaan kebutuhan

workshop menjadi semakin tertunda. Penundaan tersebut membuat waktu

persiapan workshop menjadi berkurang dan timbulnya biaya tambahan, seperti biaya lembur karyawan dan biaya denda dari tender penyelenggara (ninecone) saat di lapangan. Permasalahan berikutnya adalah tidak adanya pembuatan laporan tentang permintaan kebutuhan dan pembelian kebutuhan workshop dari semua bagian, hal ini membuat admin umum merekap kembali form dari semua bagian jika sewaktu-waktu dibutuhkan pelaporan.

Berdasarkan uraian di atas, PT. Bangun Sarana Baja memerlukan adanya beberapa perbaikan berkaitan dengan proses permintaan kebutuhan workshop. Bentuk–bentuk perbaikan yang akan dilakukan antara lain, membuat dan mengubah sistem manajemen dokumen perusahaan yang ada saat ini menjadi sistem baru yang menggunakan aplikasi workflow persetujuan permintaan kebutuhan workshop. Aplikasi tersebut dapat melakukan proses approval dari tempat manapun secara online. Selain itu, pada aplikasi ini dapat memberikan fasilitas pengelolaan data kebutuhan workshop.

Dengan dibuatnya aplikasi workflow persetujuan permintaan kebutuhan

workshop, maka kepala bagian dan manager dapat melakukan proses persetujuan

terhadap pengajuan permintaan kebutuhan workshop secara terkomputerisasi. Maka orang yang bersangkutan dapat memberikan persetujuan permintaan barang dari tempat manapun dengan akses internet. Selain itu, pada aplikasi ini departemen HSE dapat membantu pengelolaan dokumen dengan mengetahui

rekap data kebutuhan dari semua bagian, laporan pembelian kebutuhan dan permintaan kebutuhan perperiode.

1.2 Perumusan masalah

Dengan melihat latar belakang yang dibahas, maka dapat dirumuskan permasalahan departemen HSE PT. Bangun Sarana Baja yang akan diselesaikan pada penelitian ini adalah bagaimana membuat aplikasi workflow persetujuan permintaan kebutuhan workshop yang mampu mengelola permintaan kebutuhan workshop dengan proses approval secara online.

1.3 Pembatasan Masalah

Dalam penelitian pada departemen HSE di PT. Bangun Sarana Baja, lingkup pembahasannya dibatasi pada:

1. Proses Permintaan kebutuhan workshop tidak membahas supplier, retur dan distribusi barang.

2. Dokumen-dokumen terkait analisa kebutuhan workshop yang dikelola pada sistem berbentuk softcopy.

3. Tidak membahas masalah keuangan karena itu bagian dari kebijakan perusahaan.

4. Aplikasi dibuat berbasis web menggunakan bahasa pemrograman PHP dan

database mysql.

1.4 Tujuan Penelitian

Berdasarkan perumusan masalah diatas, maka diperoleh tujuan dari tugas akhir ini, yaitu dapat menghasilkan aplikasi workflow persetujuan permintaan kebutuhan workshop berbasis Web yang :

5

1. Mampu menampilkan approval secara online. 2. Mampu menampilkan detail kebutuhan workshop.

3. Mampu menghasilkan laporan rekap data kebutuhan dari semua bagian, laporan pembelian kebutuhan dan permintaan kebutuhan perperiode.

1.5 Sistematika Penulisan

Bab satu merupakan bab pendahuluan. Pada bab ini berisi penjelasan tentang apa yang melatar belakangi diambilnya topik tugas akhir, rumusan masalah dari topik tugas akhir, batasan masalah atau ruang lingkup pekerjaan tugas akhir, dan tujuan tugas akhir ini.

Bab kedua ini menjelaskan tentang landasan teori yang berbentuk uraian-uraian yang berkaitan langsung dengan permasalahan yang dikerjakan. Dalam hal ini, teori yang digunakan dalam penyelesaian masalah tugas akhir ini adalah teori tentang website, sistem informasi, Analisa Sistem, Desain Sistem dan Black

Box Testing.

Bab ketiga ini berisi tentang tahap-tahap yang dikerjakan dalam penyelesaian tugas akhir yang terdiri dari analisis sistem, identifikasi masalah, identifikasi kebutuhan pengguna, pembuatan website, perancangan sistem, dan desain uji coba.

Bab keempat ini membahas tentang implementasi sistem yang dibuat secara keseluruhan serta melakukan pengujian dan evaluasi terhadap sistem yang dibuat untuk mengetahui apakah sistem tersebut dapat menyelesaikan permasalahan yang dihadapi sesuai dengan yang diharapkan.

Bab kelima ini membahas tentang kesimpulan dan saran. Kesimpulan dan saran yang ada di dalam bab ini didapatkan dari hasil evaluasi dari bab empat. Kesimpulan akan dijelaskan hasil dari evaluasi sistem, sedangkan saran akan menjelaskan tentang masukan terhadap sistem untuk pengembangan lebih lanjut.

7 BAB II LANDASAN_TEORI

2.1 Workflow Management System (WFMS)

Menurut Talaway (2004), Workflow adalah suatu proses kerja/bisnis yang sistematis dimana dokumen atau informasi yang di buat, dialirkan dari satu pihak ke pihak yang lain untuk tindakan lanjutan menurut suatu aturan atau prosedur tertentu yang telah disepakati bersama dalam sebuah organisasi/perusahaan. Pada umumnya workflow dalam aplikasi manajemen dokumen elektronik di bangun untuk memudahkan dan mempercepat tibanya dokumen kepada orang-orang yang memiliki kewenangan otorisasi agar dapat segera memberikan persetujuan terhadap dokumen yang akan dipublikasikan. Dalam perjalanannya sebelum dokumen mendapatkan persetujuan dari semua pihak, akan terjadi proses revisi, masukan, reject, cancel dan lain-lain yang alurnya pun sudah di rancang dalam aplikasi tersebut. Ada beberapa cara agar pihak yang memiliki kewenangan otorisasi dapat mengetahui apakah dokumen yang akan di approval tersebut sudah sampai kepadanya atau belum (in progress), yaitu dengan adanya notifikasi email dan atau login ke Aplikasi DMS itu sendiri. Dalam pemberian approval juga akan ada due date kapan dokumen jatuh tempo untuk di approve apakah 1 hari atau 1 minggu tergantung rancang bangunnya.

Dengan menggunakan workflow dalam aplikasi manajemen dokumen elektronik, ada beberapa manfaat yang dapat kita peroleh yaitu diantaranya:

1. Kemudahan distribusi dokumen yang akan dipublikasikan untuk disetujui secara elektronik kepada orang-orang yang memiliki kewenangan otorisasi, tidak perlu lagi dokumen di kirim secara manual.

2. Persetujuan atau penolakan dokumen oleh pihak yang terkait dapat segera dilakukan dan diketahui.

3. Tidak tergantung pada waktu dan tempat, bisa kapan dan di mana saja untuk melakukan approval dokumen, jika aplikasi DMS tersebut sudah berbasis web.

2.1.1 Keuntungan Penggunaan WFMS

WFMS memberikan berbagai keuntungan bagi perusahaan (Talaway, I 2004), yaitu:

1. Perubahan Organisasi

WFMS (workflow Management System) dapat membantu perubahan organisasi agar dapat beroperasi lebih efektif. Perubahan ini dapat berupa perubahan struktur organisasi menjadi lebih flat dan organisasi dapat lebih berorientasi tim.

2. Perubahan Proses

WFMS (workflow Management System) membantu organisasi untuk mengevaluasi dan mendefinisikan proses bisnis. Hal ini dapat menyebabkan pengembangan proses yang pada gilirannya menyebabkan

9

3. Meningkatkan pengaksesan informasi

Dengan adanya WFMS (workflow Management System), pengetahuan organisasi akan terbentuk. Pengetahuan yang tersebar di antara para pegawai dapat dikombinasikan dan dapat diakses oleh pegawai lainnya. 4. Mengembangkan keamanan

WFMS (workflow Management System) dapat menggunakan berbagai mekanisme yang mendukung keamanan data atau proses.

2.1.2 Permintaan Barang

Menurut Himayati (2008: 87), permintaan barang atau disebut Material

Requisition adalah transaksi intern perusahaan atas permintaan suatu barang/jasa.

Transaksi ini ditujukan untuk manager yang bertanggung jawab terhadap pengadaan barang suatu barang/jasa. Pembelian adalah serangkaian tindakan untuk mendapatkan barang dan jasa melalui pertukaran, dengan maksud untuk digunakan sendiri atau dijual kembali. Menurut Mulyadi (1993: 303) bahwa dalam prosedur permintaan pembelian, fungsi gudang mengajukan permintaan pembelian dalam formulir surat penerimaan pembelian kepada fungsi pembelian. Jika barang tidak disimpan di gudang misalnya untuk barang-barang yang langsung dipakai, fungsi yang memakai barang mengajukan permintaan pembelian langsung ke fungsi pembelian dengan menggunakan surat permintaan pembelian.

2.2 Website

Website atau dalam bahasa Indonesia disebut sebagai situs web merupakan kumpulan berbagai halaman web yang ditulis dengan bahasa HTML

yang kemudian bisa dilihat menggunakan software yang disebut web browser (Zaki, 1999: 127). Halaman web bisa berisi file seperti gambar, video, dan sebagainya. Agar dapat diakses, halaman web harus diletakkan di server web untuk kemudian bisa diakses melalui peranti seperti internet, jaringan, dan sebagainya.

2.3 Sistem

Menurut Herlambang dan Haryanto (2005), definisi sistem dapat dibagi menjadi dua pendekatan, yaitu pendekatan secara prosedur dan pendekatan secara komponen. Berdasarkan pendekatan prosedur, sistem didefinisikan sebagai kumpulan dari beberapa prosedur yang mempunyai tujuan tertentu. Sedangkan berdasarkan pendekatan komponen, sistem merupakan kumpulan dari komponen-komponen yang saling berkaitan untunk mencapai tujuan tertentu.

Dalam perkembangan sistem yang ada, sistem dibedakan menjadi dua jenis, yaitu sistem terbuka dan tertutup. Sistem yang terbuak merupakan sistem yang dihubungkan dengan arus sumber daya luar dan tidak mempunyai elemen pengendali. Sedangkan sistem tertutup tidak mempunyai elemen pengontrol dihubungkan pada lingkungan sekitarnya.

2.4 Sistem Informasi

Menurut Herlambang dan Haryanto (2005), data adalah fakta-fakta atau kejadian-kejadian yang dapat berupa angka-angka atau kode-kode. Data masih belum mempunyai arti bagi penggunanya. Untuk dapat mempunyai arti data dioalah sedemikian rupa sehingga dapat digunakan oleh penggunanya. Hasil pengolahan data inilah yang disebut informasi. Secara ringkas, informasi adalah

11

data yang telah diolah dan mempunyai arti bagi penggunanya. Sehingga sistem informasi dapat didefinisikan sebagi prosedur-prosedur yang digunakan untuk mengelola data sehingga dapat digunakan oleh penggunanya.

2.5 PHP

Menurut Kadir (2008), PHP (akronim dari PHP Hypertext Preprocessor) yang merupakan bahasa pemrogramman berbasis web yang memiliki kemampuan untuk memproses data dinamis. PHP dikatakan sebagai sebuah server-side

embedded script language artinya sintaks-sintaks dan perintah yang kita berikan

akan sepenuhnya dijalankan oleh server tetapi disertakan pada halaman HTML biasa. Aplikasi-aplikasi yang dibangun oleh PHP pada umumnya akan memberikan hasil pada web browser, tetapi prosesnya secara keseluruhan dijalankan di server. Pada prinsipnya server akan bekerja apabila ada permintaan dari client. Dalam hal ini client menggunakan kode-kode PHP untuk mengirimkan permintaan ke server (dapat dilihat pada gambar dibawah). Ketika menggunakan PHP sebagai server-side embedded script language maka server akan melakukan hal-hal sebagai berikut :

1. Membaca permintaan dari client/browser. 2. Mencari halaman/page di server.

3. Melakukan instruksi yang diberikan oleh PHP untuk melakukan modifikasi pada halaman/page.

Mengirim kembali halaman tersebut kepada client melalui internet atau intranet.

2.6 Server

Menurut Sutisna (2007), Server adalah sebuah sistem komputer yang menyediakan jenis layanan tertentu dalam sebuah jaringan komputer. Server didukung dengan prosesor yang bersifat scalable dan RAM yang besar, juga dilengkapi dengan sistem operasi khusus, yang disebut sebagai sistem operasi jaringan atau network operating system. Server juga menjalankan perangkat lunak administratif yang mengontrol akses terhadap jaringan dan sumber daya yang terdapat didalamnya, seperti halnya berkas atau alat pencetak (printer), dan memberikan akses kepada workstation anggota jaringan. Adapun jenis dari server adalah sebagai berikut :

1. Server Aplikasi

Server yang digunakan untuk menyimpan berbagai macam aplikasi yang

dapat diakses oleh client, server data sendiri digunakan untuk menyimpan data baik yang digunakan client secara langsung maupun data yang diproses oleh

server aplikasi.

2. Server Data

Berfungsi untuk mengatur lalu lintas di jaringan melalui pengaturan proxy. Orang awam lebih mengenal proxy server untuk mengkoneksikan komputer client ke Internet.

3. Server Proxy

Proxy Server adalah sebuah komputer server yang dalam perkembangannya saat ini, dapat berupa system operasi tersendiri yaitu sistem operasi fungsional khusus Proxy (seperti Untangle, dll.); atau dapat pula berupa program aplikasi yang diinstallkan pada komputer server tersebut (seperti Squid,

13

Kerio Winroute Firewall, WinGate dll.). Proxy Server memiliki banyak fungsi di dalamnya. Akan tetapi fungsi utama (secara umum) dari server ini adalah untuk menjembatani (biasa disebut gateway) dan menangani setiap request (permintaan akses) terhadap konten-konten yang berasal baik dari dalam maupun luar jaringan lokal.

2.7 Konsep Pemodelan Sistem

Flowchart adalah teknik penyusunan instruksi untuk penulisan program

computer terstruktur dengan menggunakan gambar-gambar/simbol-simbol. Tujuan utama dari penggunaan flowchart adalah untuk menggambarkan suatu tahapan penyelesaian masalah secara sederhana, terurai, rapi dan jelas dengan menggunakan simbol-simbol standar (Jogiyanto, 1990).

Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi (Jogiyanto, 1990).

2.8 Konsep Basis Data

Basis data adalah koleksi dari data-data yang terkait secara logis dan deskripsi dari data-data tersebut, yang dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi (Yourdon, 1989).

Teknik Entity Relationship Diagram ERD merupakan notasi grafis dalam pemodelan data konseptual yang mendeskripsikan hubungan antara penyimpanan. ERD digunakan untuk memodelkan struktur data dan hubungan antar data, karena hal ini relatif kompleks (Yourdon, 1989).

Teknik normalisasi merupakan teknik analisis data yang mengorganisasikan atributatribut data dengan cara mengelompokkan sehingga terbentuk entitas yang nonredundan, stabil, dan fleksibel (Yourdon, 1989).

Structured Query Language (SQL) adalah bahasa yang bersifat request

oriented dan bersifat non-prosedural sehingga lebih mudah untuk dipelajari karena sintaksis yang digunakan hampir menyerupai bahasa yang digunakan oleh manusia untuk berkomunikasi (Yourdon, 1989). Selain itu juga, SQL bersifat non case sensitif. Banyak vendor pembuat DBMS (Database Management Sistem) yang saat ini menggunakan SQL sebagai standarisasi dalam produk mereka, seperti ORACLE, Microsoft SQL Server, PostGreSQL, dan MySQL(Yourdon, 1989).

2.9 Perangkat Lunak Yang Digunakan

MySQL adalah sebuah program database server yang mampu menerima dan mengirimkan datanya dengan sangat cepat, multi user serta menggunakan perintah standar SQL (Structured Query Language). Dengan sifatnya yang open source, memungkinkan juga user untuk melakukan modifikasi pada source code-nya untuk memenuhi kebutuhan spesifik mereka sendiri (Kadir, 2008).

XAMPP merupakan aplikasi server yang menggabungkan beberapa aplikasi server yang biasa digunakan di web server. Berikut beberapa komponen-komponen yang terdapat pada XAMPP, yaitu : Apache (web server), MySQL (database server), Filezilla FTP server, Mercury Mail (mail server), phpMyAdmin (web-based interface MySQL) (Sutisna, 2007).

15

2.10 SDLC

Menurut Aji Suprianto (2005), System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam membangun sistem melalui beberapa langkah. Metode pengembangan perangkat lunak dikenal dengan istilah SDLC (Software

Development Life Cycle). Metodologi ini menjadi perhatian sangat istimewa pada

proses rekayasa perangkat lunak. Karena dengan metodologi SDLC yang digunakan akan sangat menentukan sukses tidaknya proyek software.

2.10.1 Waterfall

Menurut Kendall dan Kendall (2003), model SDLC air terjun atau waterfall sering juga disebut model sekuensial linier atau alur hidup klasik.Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung.Dari kenyataan yang terjadi sangat jarang model air terjun dapat dilakukan sesuai alurnya karena sebab seperti perubahan spesifikasi perangkat lunak terjadi di tengah alur pengembangan, adanya kesulitan bagi pelanggan untuk mendefinisikan semua spesifikasi di awal alur pengembangan.Pelanggan sering kali membutuhkan contoh untuk menjabarkan spesifikasi kebutuhan sistem lebih lanjut, serta pelanggan tidak mungkin bersabar mengakomodasi perubahan yang diperlukan di akhir alur pengembangan. Dengan berbagai kelemahan yang dimiliki model air terjun namun model ini telah menjadi dasar dari model-model lain dalam melakukan perbaikan model pengembangan perangkat lunak.

Model waterfall ini adalah model SDLC yang paling sederhana, dan hanya cocok untuk pengembangan perangkat lunak dengan spesifikasi yang tidak berubah-ubah.Tahapan dari model waterfall ini dapat dilihat pada gambar 1.

2.10.2 Fase dalam metode Waterfall

Berikut ini akan dijelaskan secara singkat tentang tahapan dalam model

waterfall, yaitu:

1. System Requirements

Merupakan tahap pengumpulan data tentang kondisi awal dari suatu permasalahan yang akan diselesaikan. Data tersebut seperti siapa saja stakeholder yang ada, bagaimana keadaan sistem yang sedang digunakan saat ini dan perubahan seperti apa yang diinginkan oleh para stakeholder tersebut.

2. Software Requirements

Tahap selanjutnya adalah mendefinisikan kebutuhan perangkat lunak yang akan dibangun sesuai dengan apa yang diinginkan oleh para stakeholder.

3. Analysis

Tahap ini merupakan tahap mengidentifikasi, menyeleksi, dan merencanakan sistem yang bertujuan untuk mendeteksi dan memberikan solusi terhadap permasalahan yang ada.

17

4. Program Design

Tahap ini melakukan desain, pendefinisian dan pengolahan data yang terkait dengan fungsi, desain basis data, pendefinisian pengolahan database, waktu eksekusi, mendefinisikan interface dan penjelasan tentang input, process, dan output.

5. Coding

Tahap untuk melakukan pengkodean untuk membangun perangkat lunak sesuai dengan hasil dari desain program sekaligus menyiapkan dokumentasi untuk setiap aktivitas pengkodean.

6. Testing

Melakukan uji kelayakan perangkat lunak yang telah dibangun sesuai dengan scenario dan test plan yang disiapkan.

7. Operations

Tahap ini adalah pengimplementasian dan instalasi perangkat lunak, dimana perangkat lunak tersebut akan diadaptasi dengan sistem yang lama untuk kemudian dilakukan evaluasi.

2.11 Black Box Testing

Menurut Rizky (2011), pengertian dari black box testing adalah suatu tipe

testing yang memperlakukan perangkat lunak yang tidak diketahui kinerja

internalnya. Berdasarkan hal tersebut, para tester memandang perangkat lunak

seperti layaknya sebuah “kotak hitam” yang tidak penting dilihat isinya, tetapi

Black box testing hanya memandang perangkat lunak dari sisi spesifikasi dan

kebutuhan yang telah ditentukan pada saat awal perancangan. Keuntungan dari jenis testing ini antara lain:

1. Anggota tim tester tidak harus dari seseorang yang memiliki kemampuan teknis di bidang pemrograman.

2. Kesalahan dari perangkat lunak ataupun bug sering ditemukan oleh komponen tester yang berasal dari pengguna.

3. Hasil dari black box testing dapat memperjelas kontradiksi ataupun kerancuan yang mungkin timbul dari eksekusi sebuah perangkat lunak.

19 BAB III

ANALISIS DAN PERANCANGAN SISTEM

3.1 Analisis

3.1.1 Identifikasi Masalah

Untuk melakukan identifikasi masalah maka dilakukan wawancara di departemen Health, Safety dan Environment (HSE) PT Bangun Sarana Baja, dengan objek wawancara Kepala Bagian Bapak Nibras Nuzulul, Admin Umum HSE Bapak Fiqi dan Manager HSE Bapak Pranata. Adapun hasil dari wawancara adalah sebagai berikut :

1. Selama ini proses persetujuan permintaan kebutuhan workshop harus dilakukan secara langsung antara pemohon, kepala bagian maupun manajer. Namun, pada kenyataannya kepala bagian yang terkait maupun manager HSE sering tidak ada di tempat, yang menyebabkan penundaan persetujuan. 2. Dari penundaan persetujuan tersebut membuat waktu persiapan workshop

menjadi berkurang dan timbulnya biaya tambahan, seperti biaya lembur karyawan dan biaya denda dari tender penyelenggara (ninecone) saat di lapangan.

3. Selama ini tidak adanya pembuatan laporan tentang permintaan kebutuhan dan pembelian kebutuhan workshop dari semua bagian, hal ini membuat admin umum merekap kembali form dari semua bagian jika sewaktu-waktu dibutuhkan pelaporan.

Dari hasil wawancara diatas maka dapat di gambarkan proses bisnis yang sedang berjalan saat ini. Pemohon melakukan permintaan dengan mengisi form

permintaan kebutuhan barang kemudian form yang sudah di isi diberikan kepada Admin Umum untuk di analisis dan dibuatkan surat permohonan persetujuan permintaan yang berisi daftar permintaan kebutuhan barang untuk diajukan persetujuan kepada kepala bagian dan manajer HSE. Jika permintaan disetujui maka daftar barang yang harus dibeli diberikan kepada Bagian purchasing perusahaan, apabila daftar permintaan belum disetujui maka daftar kebutuhan dikembalikan lagi kepada Admin Umum HSE untuk dilakukan revisi permohonan persetujuan permintaan.

Dari proses bisnis yang sudah dijelaskan diatas, dalam melakukan persetujuan permintaan kebutuhan dapat di gambarkan dalam sebuah document

flow keseluruhan untuk proses bisnis saat ini seperti pada gambar 3.1 berikut ini.

Document Flow Persetujuan Permintaan Kebutuhan Workshop

Pemohon Admin Umum HSE Kabag divisi Manager HSE Bag. Purchasing

P ha se start Mengisi form permintaan kebutuhan barang Data kebutuhan workshop Form permintaan barang yang sudah diisi Form permintaan barang yang sudah diisi Membuat surat permohonan persetujuan permintaan Daftar permintaan kebutuhan barang Daftar permintaan kebutuhan barang Daftar permintaan kebutuhan barang yang sudah disetujui

kabag Melakukan persetujuan Detail workshop ACC T Y Detil Workshop Melakukan persetujuan ACC T Data kebutuhan workshop yang harus dibeli Y end

21

Gambar 3.1 menjelaskan proses permintaan kebutuhan yang dilakukan oleh pemohon yang dikirim ke Admin Umum, lalu dari Admin Umum dilakukan pengecekan dan analisis kebutuhan, kemudian dibuat surat permohonan untuk proses persetujuan, bila tidak di setujui permohonan permintaan kebutuhan akan dikembalikan ke Admin Umum, dan bila di setujui maka akan dimasukan ke dalam daftar barang yang harus dibeli untuk diberikan kepada bagian pembelian perusahaan.

Dari proses bisnis diatas maka akan muncul permasalahan pada proses persetujuan, proses persetujuan yang dilakukan secara langsung sering terjadi penundaan karena kepala bagian dan manajer sering tidak ada di tempat. Masalah yang lain muncul penundaan persetujuan tersebut membuat waktu persiapan

workshop menjadi berkurang dan timbulnya biaya tambahan, seperti biaya lembur

karyawan dan biaya denda dari tender penyelenggara (ninecone) saat di lapangan. 3.1.2 Analisis Kebutuhan Sistem

Dengan adanya permasalahan diatas maka dibuatlah perancangan sebuah aplikasi yang bisa melakukan persetujuan permintaan secara online dan pelaporan kebutuhan perperiode, Pada tahap ini digunakan untuk menentukan data apa saja yang diperlukan aplikasi, siapa yang akan menjadi pengguna aplikasi, bagaimana aplikasi dapat menyelesaikan permasalahan persetujuan dan pelaporan permintaan perperiode.

Tabel 3.1 Tabel Analisis Kebutuhan Sistem

Untuk memahami proses yang akan dijalankan oleh aplikasi diperlukan sebuah gambaran umum aplikasi yang akan dibangun. Gambaran umum aplikasi dapat dilihat pada Gambar 3.2

No

Kebutuhan Sistem

Jenis Kebutuhan Kebutuhan

1 Input - Data Permintaan - Daftar Kebutuhan - Daftar Pembelian - Daftar Alokasi Barang 2 Output - Laporan Permintaan

- Laporan Pembelian

- Laporan Alokasi Kebutuhan - Rekap data permintaan perperiode 3 Proses - Analisa daftar permintaan

- Persetujuan Kabag dan Manajer - Pembelian Kebutuhan

- Pengalokasian Kebutuhan 4 Pengguna - Admin divisi departemen HSE

- Bagian Pembelian - Kepala bagian HSE - Manajer HSE 5 Hak Akses Admin Divisi :

- Mengisi Data Permintaan - Mengisi Daftar kebutuhan

- Membaca daftar alokasi kebutuhan Bagian Pembelian :

- Mengisi data daftar alokasi kebutuhan - Membaca daftar pembelian

Kepala Bagian HSE : - Membaca daftar kebutuhan - Membaca Detil workshop / project - Memberikan persetujuan permintaan - Membuat Laporan permintaan divisi Manajer HSE :

-Membaca daftar kebutuhan -Membaca Detil workshop / project -Memberikan persetujuan permintaan -Membaca Laporan Permintaan -Membaca Rekap Laporan Perperiode

23

Gambar 3.2 Gambaran umum aplikasi.

Pada Gambar 3.2 menjelaskan tentang arsitektur aplikasi, admin divisi bisa memasukan data permintaan kedalam aplikasi dengan melakukan login menggunakan username dan password. Admin divisi juga bisa mendapatkan informasi tentang informasi daftar barang yang dialokasikan. Sistem akan mengelola data yang telah di input oleh Admin divisi untuk membuat daftar persetujuan kebutuhan, daftar pembelian, daftar alokasi dan pelaporan dengan cara membaca data yang di simpan di database permintaan. Laporan tersebut akan di terima oleh manajer HSE yaitu laporan permintaan, rekapan permintaan per divisi, dan laporan perperiode.

3.2 Perancangan Sistem

Setelah melakukan analisa masalah, maka dibuatlah aplikasi workflow persetujuan permintaan kebutuhan workshop berbasis website yang dimana sistem ini akan digambarkan pada gambaran umum sistem, Data Flow Diagram (DFD), rancangan database berupa Entity Relationship Diagram (ERD), struktur tabel, serta desian I/O dari sistem informasi yang akan dibuat.

3.2.1. Blok Diagram

Data Permintaan

Daftar Kebutuhan

Analisis Admin HSE

Persetujuan Kabag

Daftar Kebutuhan

Input Proses Output

Persetujuan Manager Daftar Pembelian

Daftar Pembelian

Daftar Alokasi Barang

Pembelian

Pengalokasian

Daftar Barang yang akan dialokasikan

Laporan Permintaan, Pembelian dan Pengalokasian

Kebutuhan Workshop Daftar Persetujuan Kabag

Daftar Persetujuan

Kabag

Gambar 3.3 Blok diagram aplikasi persetujuan permintaan kebutuhan A. INPUT

1. Data Permintaan

Data permintaan merupakan data kebutuhan workshop dari pemohon unit divisi, isi dari data permintaan tersebut merupakan kebutuhan workshop divisi yang akan dianalisis dan diinputkan oleh admin divisi untuk proses permintaan kebutuhan.

25

2. Daftar Kebutuhan

Daftar Kebutuhan merupakan data permintaan yang telah dianalisis dan dimasukkan kedalam aplikasi oleh admin divisi untuk selanjutkan diajukan proses persetujuan kepada kabag divisi dan manager HSE.

3. Daftar Pembelian

Daftar Pembelian merupakan daftar kebutuhan yang telah disetujui oleh kabag divisi dan manajer HSE yang berisi daftar barang yang harus dibeli untuk selanjutnya dilakukan proses pembelian oleh bagian purcashing PT. Bangun Sarana Baja.

4. Data Alokasi Kebutuhan

Daftar Alokasi Barang merupakan data barang yang telah dibeli oleh perusahaan, diinputkan kedalam sistem oleh bagian purchasing dan siap dialokasikan kepada divisi unit pemohon.

B. PROSES

1. Analisis Admin HSE

Proses Analisis admin merupakan proses analisa data permintaan kebutuhan, disesuaikan dengan detil persetujuan workshop dengan ninecone, sebelum data permintaan dimasukan kedalam aplikasi data permintaan diklasifikasi sesuai divisi departemen HSE, berikut klasifikasi divisi tersebut dapat dilihat pada tabel 3.2.

Tabel.3.2 Klasifikasi Divisi Data Permintaan

2. Persetujuan Kepala Bagian dan Manajer

Proses persetujuan merupakan proses yang dilakukan kepala bagian dan manager untuk melakukan review pada daftar kebutuhan apakah sudah sesuai dengan divisi dan detil workshop, didalam proses persetujuan tersebut terdapat proses revisi baik reject permintaan mau-pun request permintaan, kepala bagian dan manager yang mempunyai wewenang persetujuan permintaan tersebut untuk disetujui atau masih perlu dilakukan revisi. Permintaan kebutuhan dilakukan by

order berikut persyaratan persetujuan permintaan kebutuhan

3. Proses Pembelian

Proses pembelian merupakan proses yang dilakukan oleh bagian

purchasing perusahaan setelah ada daftar barang yang harus dibeli dari daftar

kebutuhan barang sudah disetujui oleh kepala bagian maupun manager. Adapun proses pembelian dapat dilakukan apabila jumlah barang pada warehouse kurang dari jumlah permintaan, jika barang pada warehouse lebih dari permintaan maka

27

bagian pembelian membuatkan bon pada pemohon yang berisi nama dan satuan serta harga barang.

4. Proses Pengalokasian Barang

Proses pengalokasian merupakan proses yang dilakukan Bagian

Purchasing perusahan setelah barang pembelian datang, proses alokasi barang

disesuaikan dengan surat permohonan permintaan kebutuhan dari unit divisi pemohon.

C. OUTPUT

Terdapat empat output yaitu daftar kebutuhan, daftar pembelian, daftar alokasi barang seperti yang dijelaskan diatas serta pelaporan. Jenis-jenis laporan yang nanti akan dihasilkan adalah sebagai berikut:

a. Laporan Data Permintaan

Laporan data ini digunakan departemen HSE untuk mengetahui permintaan kebutuhan barang yang telah disetujui berdasarkan periode tertentu. Data yang ditampilkan adalah tanggal permintaan, id permintaan, nama barang, jumlah dan satuan berdasarkan tabel permintaan

b. Laporan Pembelian Barang

Laporan data ini digunakan departemen HSE untuk mengetahui data barang yang telah dibeli berdasarkan detail data permintaan yang telah dibeli berdasarkan tabel permintaan

c. Laporan Alokasi Kebutuhan barang

Data laporan ini digunakan bagian purchasing sebagai tanda bukti barang sudah dialokasikan yang dicetak untuk bagian purchasing dan pemohon. Data yang ditampilkan adalah id permintaan, nama barang, jumlah, satuan, keterangan, nama bagian dan tanggal cetak

d. Rekap Data Permintaan Pembelian dan alokasi barang dari semua Divisi Merupakan data yang digunakan departemen HSE untuk menge-tahui rekap pemenuhan kebutuhan workshop semua divisi yang nantinya digunakan sebagai acuan progress pemenuhan kebutuhan workshop. Data yang ditampilkan nama barang, satuan, jumlah, total berdasarkan rekap per divisi dari tabel permintaan.

29

3.2.2. System flow

Dari proses bisnis tersebut dapat di gambarkan menjadi system flow sebagai berikut ini.

System flow persetujuan permintaan dan pembelian kebutuhan workshop

Pemohon Kabag Divisi Manager HSE Bagian Purchasing

P ha se Warehouse start Data kebutuhan Workshop Input Data Permintaan Mengisi data Permintaan workshop Menampilkan data permintaan barang Daftar data permintaan barang Persetujuan (ACC) permintaan barang

Input data master barang

Mengisi data master barang Permintaan Menampilkan data permintaan barang Daftar data permintaan barang Persetujuan (ACC) permintaan barang Menampilkan data barang yang dibeli

Daftar data barang yang harus dibeli

Data Permintaan barang yang harus

dibeli end setuju T Y setuju T Y

Gambar 3.4 System flow Persetujuan Permintaan Kebutuhan.

Pada gambar 3.4 diatas menjelaskan tentang proses persetujuan permintaan kebutuhan workshop dimulai dari Aplikasi menerima masukkan data permintaan kebutuhan workshop dari admin divisi (pemohon) dengan melihat data

master barang yang tersimpan pada tabel Barang. Sistem kemudian akan menyimpan data permintaan tersebut di tabel permintaan. Hasil data permintaan yang disimpan akan ditampilkan oleh sistem. Data yang tersimpan tersebut akan di review oleh kepala bagian dan manager HSE untuk dilakukan proses persetujuan. Kemudian setelah melewati proses persetujuan, data permintaan disim-pan dan akan di review oleh bagian purchasing untuk melihat barang apa saja yang harus dibeli.

System flow alokasi kebutuhan workshop

Pemohon Bagian Purchasing Manager HSE

Ph

as

e

Data barang yang

dibeli Data barang yang

dibeli start

Input da ta ketersediaan

barang

Warehouse Menampilkan

permintaan barang yang bisa diambil

Daftar data permintaan barang yang bisa

diambil

Mencetak data barang yang

diambil

Data barang yang diambil Data barang yang

diambil

Mengisi ketersediaan

barang

end

Gambar 3.5 System flow Mengelola Alokasi Kebutuhan

Pada gambar 3.5 diatas Bagian Purchasing memasukkan data barang yang siap dialokasi-kan ke sistem. Data barang yang tersedia dapat dilihat oleh Admin divisi (pemohon) dari sistem yang ditampilkan melalui tabel Barang,

31

kemudian admin mencetak data barang yang diambil sebagai bukti pengambilan barang. Selanjutnya Bagian Purchasing memberikan data barang yang sudah dibeli dan dialokasikan kepada manajer HSE sebagai bukti barang sudah dialokasikan.

Sistem flow pelaporan permintaan dan pembelian kebutuhan workshop

sistem Manager HSE

Ph

as

e

start

Warehouse

Memelilih laporan yang akan dibuat

Laporan yang dipilih Menampilkan laporan yang dipilih

Membuat laporan Permintaan

Laporan yang telah dibuat Mencetak laporan

Laporan permintaan perpiode Laporan pembelian

perpiode Laporan rekap permintaan semua

bagian end

Gambar 3.6 System flow Mengelola Data Pelaporan.

Pada gambar 3.6 Manager HSE akan memilih jenis laporan yang akan dibuat, kemudian system akan menampilkan laporan yang dipilih dengan

membaca tabel Barang dan Permintaan, selanjutnya system menampilkan laporan yang telah dibuat.

3.2.3. Diagram Jenjang

Selanjutnya yaitu membuat diagram jenjang terlebih dahulu, karena dengan adanya diagram jenjang, alur proses dari sistem akan lebih mudah dan lebih jelas.

Aplikas i Persetujua n Perminta an

Kebutuhan Works hop

0

Mengelola Data pembelian

2

Membuat Laporan 4 Mengelola data

PeNgaloka sian 3 Mengelola Data

Perminta an 1

Gambar 3.7 Diagram Jenjang Aplikasi Permintaan Persetujuan

Setelah membuat diagram jenjang aplikasi persetujuan permintaan kebutuhan workshop, di gambarkan juga subproses dari proses mengelola data permintaan.

Aplikas i Persetujua n Perminta an

Kebutuhan Works hop

0

Mengelola Data Perminta an 1 Persetuj uan Perminta an 1.1 1.2 Input data perminta an

Gambar 3.8 Diagram Jenjang subproses Mengelola Data Permintaan. Kemudian setelah membuat subproses dari proses mengelola data permintaan, digambarkan juga subproses dari proses mengelola data pembelian.

33

Aplikas i Persetujuan Permintaan

Kebutuhan Works hop

0

Mengelola Data pembelian

2

Input data pembelian

2.1 2.2

Persetujuan pembelian

Gambar 3.9 Diagram Jenjang subproses Mengelola Data Pembelian.

Kemudian setelah membuat subproses dari proses mengelola data pembelian, digambarkan juga subproses dari proses mengelola data alokasi kebutuhan.

Aplikas i Persetujuan Permintaan

Kebutuhan

Works hop

0

Mengelola Data Pengalokasian

3

Input data alokasi

3.1 3.2

Mengecek data alok asi

Gambar 3.10 Diagram Jenjang subproses Mengelola Data Pengalokasian. Kemudian setelah membuat subproses dari proses mengelola data pengalokasian, digambarkan juga subproses dari proses membuat laporan.

Aplikasi Persetujuan Permintaan Kebutuhan Workshop

0

Laporan 4

Membuat laporan 4.1

Melihat Laporan 4.2

Mencetak Laporan 4.3

Gambar 3.11 Diagram Jenjang subproses Membuat Laporan.. 3.2.4. Data Flow Diagram (DFD)

Diagram aliran data atau DFD menggambarkan proses dalam analisis dan perancangan perangkat lunak, khususnya dengan pendekatan terstruktur. Pada DFD akan dijelaskan mengenai aliran data yang terdapat dalam aplikasi.

1. Diagram konteks (Context Diagram)

Gambaran sistem pada contex diagram menggambarkan informasi dan data yang masuk kedalam sistem dan keluar dari dalam sistem.

35

Info Barang yang s iap dialokas ikan

Daftar Pers etujuan Pem belian Manager

Daftar Pers etujuan Pem belian Kabag

Daftar Kebutuhan yang dis etujui Manager Daftar Barang yang s udah dialokas ikan

Rekap Laporan Perm intaan dari s emua divis i

Laporan Alok as i Laporan Pembelian

Laporan Perm intaan

Daftar Kebutuhan Daftar Kebutuhan

Daftar Barang Yang dialokas ikan Daftar Pembelian

Data Barang yang dibeli

Data Permintaan yang dis etujui Data Permintaan yang dis etujui Kabag

Data Permintaan

0

Aplikas i Workflow Pers etujuan Permintaan Kebutuhan Works hop

+

Pemohon Bagian Purchas ing

Kepala Bagian

Manager HSE

Gambar 3.12 Context Diagram Aplikasi Persetujuan Permintaan.

Dari analisis sistem bisa diketahui 4 pengguna sistem yaitu Pemohon, Bagian Purchasing, Kepala bagian dan Manager HSE maka keempat pengguna tersebut menjadi external entity untuk pembuatan diagram konteks. Pada gambar 3.12 terdapat aliran data yg berjalan pada sistem, baik yang mengalir kedalam sistem atau yang diterima oleh entitas.

2. DFD Level 0

Gambaran sistem pada DFD level 0 merupakan hasil

decompose dari context diagram, pada saat pembuatan DFD level

Data Alokasi Data Pembelian Data Permintaan

Data Alokasi Barang

Data Pembelian data persetujuan perm intaan

[Daftar Kebutuhan yang disetujui Manager]

[Daftar Barang yang sudah dialokasikan]

[Daftar Barang Yang dialokasikan] [Daftar Persetujuan Pembelian Manager]

[Daftar Persetujuan Pembelian Kabag]

[Info Barang yang siap dialokasikan] [Daftar Kebutuhan]

[Daftar Kebutuhan] [Data Permintaan yang disetujui]

[Data Permintaan yang disetujui Kabag]

[Daftar Barang yang harus dibeli]

[Daftar Pem belian]

[Data Barang yang dibeli] [Data Permintaan]

[Rekap Laporan Permintaan dari semua divisi] [Laporan Alokasi]

[Laporan Pem belian] [Laporan Permintaan] Pemohon Kepala Bagian Manager HSE Bagian Purchasing 1

Mengelola data Permintaan

+

2

Mengelola data Pem belian

+ 3 Mengelola data Pengalokasian + 4 Mengelola Laporan +

1 Perm intaan

1 Perm intaan 2 Pembelian 3 Pengalokasian

2 Pembelian

3 Pengalokasian

Gambar 3.13 DFD Level 0 Aplikasi Persetujuan Permintaan.

Pada gambar 3.17 menggambarkan aliran data pada DFD level 0, DFD

level 0 merupakan hasil breakdown dari diagram kontek. Proses utama yang

terjadi dalam DFD level 0 adalah Mengelola Data Permintaan, Mengelola Data Pembelian, Mengeloa data Pelaporan Pengalokasian Kebutuhan dan Membuat Laporan.

37

3. DFD Level 1 Mengelola Data Permintaan

[Daftar Kebutuhan yang dis etujui Manager]

[Daftar Barang yang harus dibeli] [data pers etujuan perm intaan]

[Daftar Kebutuhan]

[Daftar Pem belian]

[Data Permintaan yang dis etujui Kabag] [Data Permintaan yang dis etujui]

[Daftar Kebutuhan] [Data Permintaan]

Pemohon

Kepala Bagian Manager

HSE

Bagian Purchas ing Kepala

Bagian Manager

HSE 1 Perm intaan

1.1

Pers etujuan perm intaan

1.2

Input data perm intaan

Gambar 3.14 DFD Level 1, Mengelola Data Permintaan.

Pada gambar 3.14 merupakan hasil decompose DFD level 0 dari Mengelola Data Permintaan dan mengeluarkan DFD level 1 proses Persetujuan Permintaan didalamnya terdapat tiga entitas yaitu Pemohon, Kepala Bagian dan bagian Purchasing serta terdapat satu database yaitu Permintaan.

4. DFD Level 1 Mengelola Data Pembelian

Data pembelian [Daftar Pers etujuan Pembelian Kabag]

[Daftar Pers etujuan Pembelian Manager]

[Data Pem belian] [Data Barang yang dibeli]

Bagian Purchas ing Kepala Bagian Manager HSE 2 Pembelian 2.1 Input data pembelian 2.2 pers etujuan data pembelian 2 Pembelian

Gambar 3.15 DFD Level 1 Mengelola Pembelian.

Pada gambar 3.15 merupakan hasil decompose DFD level 0 dari Mengelola Data Pembelian dan mengeluarkan DFD level 1 proses persetujuan pembelian didalamnya terdapat dua entitas yaitu kepala bagian dan bagian purchasing dan terdapat satu database yaitu Pembelian.

5. DFD Level 1 Mengelola Data Pengalokasian

Data barang yang dialokas ikan [Data Alokas i Barang]

[Daftar Barang yang s udah dialok as ikan]

[Info Barang yang s iap dialokas ikan] [Daftar Barang Yang dialokas ikan]

Bagian Purchas ing

Pemohon

Pemohon 3 Pengalokas ian 3.1

Input data alokas i

3.2 Mengecek data alokas i Bagian

Purchas ing

39

Pada gambar 3.16 diatas merupakan hasil decompose dari DFD level 0 Mengelola Data Pengalokasian dan mengeluarkan DFD level 1 proses Pengalokasian kebutuhan didalamnya terdapat dua entitas yaitu Pemohon dan bagian purchasing dan terdapat satu database yaitu Pengalokasian.

6. DFD Level 1 Membuat Laporan

Laporan rekas p s emua divis i laporan rekap s emua divis i

laporan alokas i Laporan pembelian Laporan Perm intaan Laporan alok as i Laporan pembelian Laporan perm intaan

Data alokas i

Data Pembelian Data Permintaan

Data perm intaan data pembelian

data alokas i

[Laporan Alokas i]

[Rekap Laporan Permintaan dari s emua divis i] [Laporan Permintaan]

[Laporan Pem belian]

[Data Alokas i] [Data Pem belian]

[Data Permintaan] Manager

HSE 1 Perm intaan

2 Pembelian

3 Pengalokas ian 4.1 Membuat laporan 4.2 Melihat laporan 4.3 Mencetak laporan Manager HSE Manager HSE

Gambar 3.17 DFD Level 1 Membuat Laporan.

Pada gambar 3.17 diatas merupakan hasil decompose dari DFD level 0 Membuat Laporan dan mengeluarkan DFD level 1 satu proses yaitu Membuat Laporan. Ada satu entitas yaitu Manager HSE dan terdapat 3 database yaitu Permintaan, Pembelian dan Pengalokasian.

3.2.5. Entity Relationship Diagram (ERD)

Entity Relationship Diagram (ERD) menggambarkan basis data yang

ada. ERD dalam pengelolaan ini akan dibagi menjadi 2, yakni Conceptual Data

1. Conceptual Data Model (CDM) Memiliki Mempunyai Memiliki Memiliki Mempunyai Mempunyai Mempunyai mempunyai mempunyai memiliki Warehouse Id_barang Nama_barang Satuan Harga Jumlah

<pi> Variable characters (8) Variable characters (50) Variable characters (10) Number Number <M> Identifier_1 <pi> Admin_divisi NIK Nama Pin

<pi> Variable characters (8) Variable characters (50) Variable characters (8)

<M>

Identifier_1 <pi>

Divisi ID_Divisi

Nama_Divisi

<pi> Variable characters (8) Variable characters (20) Identifier_1 <pi>

Permintaan Id_permintaan

Tgl_buat Status

<pi> Variable characters (8) Date Number (1) <M> Identifier_1 <pi> Kategori Id_kategori Nama_kategori

<pi> Variable characters (8) Variable characters (20)

<M> Identifier_1 <pi> Workshop Id_Workshop Tgl_Project Tahun_Periode

<pi> Variable characters (8) Date & Time Number (4) <M> Identifier_1 <pi> Revisi Id_Revisi Tgl_Rev Tgl_App Pesan

<pi> Variable characters (8) Date

Date

Variable characters (400) <M> Identifier_1 <pi> Alokasi id_alokasi Nama_barang Jumlah

<pi> Variable characters (8) Variable characters (50) Number Identifier_1 <pi>

Gambar 3.18 CDM Aplikasi Workflow Permintaan Kebutuhan.

Pada gambar 3.18 menunjukan struktur basis data dari aplikasi yang akan di bangun. Pada aplikasi ini telah disiapkan tujuh tabel yaitu tabel Barang, Admin Divisi, Divisi, kategori, Revisi, Workshop dan Permintaan, dengan masing-masing tabel terdapat sejumlah kolom. Disetiap tabel terdapat kolom sebagai primay key sebagai pembeda dari setiap baris pada tabel yang sama. Selain itu terdapat juga hubungan antara tabel atau bisa disebut juga relationship dengan jenis yang berbeda-beda.

41

2. Physical Data Model (PDM)

FK_MEMILIKI FK_MEMPUNYAI FK_MEMILIKI1 FK_MEMILIKI2 FK_MEMILIKI3 FK_MEMPUNYAI1 FK_MEMPUNYAI2 FK_MEMPUNYAI3 FK_MEMPUNYAI4 FK_MEMILIKI24 FK_MEMPUNYAI13 FK_MEMPUNYAI12 FK_MEMILIKI14 Warehouse Id_barang Id_kategori Nama_barang Satuan Harga Jumlah varchar(8) varchar(8) varchar(50) varchar(10) numeric(8,0) numeric(8,0) <pk> <fk> Admin_divisi NIK ID_Divisi Nama Pin varchar(8) varchar(8) varchar(50) varchar(8) <pk> <fk> Divisi ID_Divisi Nama_Divisi varchar(8) varchar(20) <pk> Permintaan Id_permintaan NIK Tgl_buat Status Tgl_butuh varchar(8) varchar(8) date numeric(1,0) date <pk> <fk> Kategori Id_kategori Nama_kategori varchar(8) varchar(20) <pk> Workshop Id_Workshop ID_Divisi Tgl_Project Tahun varchar(8) varchar(8) datetime numeric(4,0) <pk> <fk> Revisi Id_Revisi Id_permintaan Tgl_Rev Tgl_App Pesan Kabag_status Manager_status varchar(8) varchar(8) date date varchar(400) numeric(2,0) numeric(2,0) <pk> <fk> Detil_Workshop Id_barang Id_Workshop Bulan Jumlah Keterangan varchar(8) varchar(8) varchar(15) numeric(0,0) longtext <pk,fk1> <pk,fk2> Detil_Permintaan Id_barang Id_permintaan Bulan Pesan_Pemohon Approve_Kabag approve_Manager Tgl_Alokasi Status_brg varchar(8) varchar(8) varchar(15) varchar(400) numeric(2,0) numeric(2,0) date numeric(2,0) <pk,fk1> <pk,fk2> Pembelian id_pembelian id_barang Id_permintaan tgl_beli Nama_barang jumlah total varchar(8) varchar(8) varchar(8) datetime varchar(30) numeric(8,0) numeric(8,0) <pk> <pk> <fk1> Pengalokasian id_alokasi id_permintaan id_barang tanggal_alokasi jumlah_alokasi varchar(8) varchar(8) varchar(8) datetime numeric(8,0) <fk1> <fk2>

Gambar 3.19 PDM Aplikasi Workflow Permintaan Kebutuhan.

Pada gambar 3.19 diatas merupakan hasil generate dari CDM dimana bentuk konsep dari struktur basis data aplikasi dikembangkan menjadi bentuk yang lebih jelas.

3.2.6. Struktur Tabel

Tabel-tabel yang digunakan pada sistem yang telah dibuat ini sebagaimana yang terdapat pada Physical Data model yaitu

1. Tabel Warehouse

Tabel barang di gunakan untuk menyimpan data barang yang diminta dari masing-masing divisi di HSE. Mempunyai primary key pada field id Barang dan foreign key pada field id Kategori. Struktur tabelnya dapat dilihat pada tabel 3.2 di bawah ini.

Tabel 3.3 Warehouse

Field Nama Tipe data Constraint Id barang Varchar (8) Primary key Id kategori Varchar (8) Foreign key Nama barang Varchar (50) -

Satuan Varchar (10) -

Harga Numeric (8) -

Jumlah Numeric (8) -

2. Tabel Admin Divisi

Tabel Admin Divisi digunakan untuk menyimpan data admin sub masing-masing divisi, yang bertujuan sebagai user yang melakukan input permintaan sesuai divisi di departemen HSE. Mempunyai primary key pada field NIK, dan foreign key yaitu pada field id divisi. Struktur tabel dapat dilihat pada tabel 3.3 di bawah ini.

Tabel 3.4 Admin Divisi

Field Nama Tipe data Constraint

43

Id divisi Varchar (8) Foreign key

Nama Varchar (20) -

Pin Varchar (8) -

3. Tabel Divisi

Tabel ini digunakan untuk menyimpan data divisi yang ada di departeman HSE didalamnya terdapat primary key pada field id divisi . Struktur tabel dapat di lihat pada tabel 3.4 di bawah ini.

Tabel 3.5 Divisi

Field Nama Tipe data Constraint Id Divisi Varchar (8) Primary key Nama Divisi Varchar (20) -

Kabag Divisi Varchar (30) -

Manager Varchar (30) -

4. Tabel Workshop

Tabel ini digunakan untuk menyimpan data workshop atau project, didalamnya terdapat primary key pada field id workshop dan foreign key yaitu pada

field id divisi. Struktur tabel dapat di lihat pada tabel 3.5 di bawah ini.

Tabel 3.6 Workshop

Field Nama Tipe data Constraint

Id Workshop Varchar (8) Primary key Id divisi Varchar (8) Foreign key

Tgl project Datetime -

5. Tabel Detil Workshop

Tabel ini digunakan untuk menyimpan data Detil dari project atau workshop, didalamnya terdapat primary key dan foreign key pada field id barang dan id workshop. Struktur tabel dapat di lihat pada tabel 3.6 di bawah ini.

Tabel 3.7 Detil Workshop

Field Nama Tipe data Constraint Id barang Varchar (8) Primary key,

Foreign key Id workshop Varcahr (8) Primary key,

Foreign key

bulan Int -

jumlah Int -

keterangan Int -

6. Tabel Permintaan

Tabel ini digunakan untuk menyimpan data permintaan, di dalamnya terdapat primary key pada field id permintaan. Struktur tabel dapat di lihat pada tabel 3.7 di bawah ini.

Tabel 3.8 Permintaan

Field Nama Tipe data Constraint Id permintaan Varchar (8) Primary key

NIK Varcahr (8) Foreign key

Tgl buat date -

Status number -

45

7. Tabel Kategori

Tabel ini digunakan untuk menyimpan data kategori barang, didalamnya terdapat primary key pada field id kategori. Struktur tabel dapat dilihat pada tabel 3.8 di bawah ini.

Tabel 3.9 Kategori

Field Nama Tipe data Constraint Id kategori Varchar (8) Primary key Nama kategori Varchar (20) -

8. Tabel Detil Permintaan

Tabel detil permintaan digunakan untuk menyimpan data detil permintaan, yang didapat dari inputan data permintaan kebutuhan divisi. Mempunyai primary key dan foreign key yaitu pada field id Barang dan id Permintaan. Struktur tabel dapat dilihat pada tabel 3.9 di bawah ini.

Tabel 3.10 Detil Permintaan Field Nama Tipe data Constraint

Id Barang Varchar (8) Primary key, Foreign Key

Id Permintaan Varcahr (8) Primary key,Foreign key

Bulan Varchar (15) -

Pesan Varchar (400) -

Approve Kabag Number -

Approve Manager Number -

Tgl Alokasi date -

9. Tabel Revisi

Tabel Revisi digunakan untuk menyimpan revisi persetujuan permintaan, mempunyai primary key pada field id revisi dan foreing key pada field id permintaan. Struktur tabel dapat dilihat pada tabel 3.10 di bawah ini.

Tabel 3.11 Revisi

Field Nama Tipe data Constraint Id revisi Varchar (8) Primary key Id permintaan Varchar (8) Foreign key

Tgl rev Date -

Tgl App Date -

Pesan Varchar (400) -

Kabag status Number -

Manager status Number -

10. Tabel Pembelian

Tabel Pembelian digunakan untuk menyimpan Pembelian persetujuan permintaan, mempunyai primary key pada field id pembelian dan foreing key pada

field id permintaan. Struktur tabel dapat dilihat pada tabel 3.12 di bawah ini.

Tabel 3.12 Pembelian

Field Nama Tipe data Constraint Id Pembelian Varchar (8) Primary key Id Permintaan Varchar (8) Foreign key

47

Id Barang Varchar (8) Foreign key

Tgl Beli Date -

Nama barang Varchar (30) -

Jumlah Number -

Total Number -

11. Tabel Pengalokasian

Tabel Pengalokasian digunakan untuk menyimpan alokasi persetujuan permintaan, mempunyai primary key pada field id alokasi dan foreing key pada

field id permintaan. Struktur tabel dapat dilihat pada tabel 3.13 di bawah ini.

Tabel 3.13 Pengalokasian

Field Nama Tipe data Constraint Id alokasi Varchar (8) Primary key Id barang Varchar (8) Foreign key Id permintaan Varchar (8) Foreign key

Tgl Alokasi Date -

Jumlah Alokasi Number -

3.2.7. Desain User Interface

Desain user interface diperlukan untuk menghasilkan tampilan yang digunakan pengguna untuk berinteraksi dengan sistem.

1. Desain User Interface Halaman Login

Dibawah ini merupakan desain user interface Halaman Login yaitu halaman website yang di akses pertama kali oleh pihak departemen HSE.

Gambar 3.20 Desain User Interface Halaman Login

Pada gambar 3.20 diatas terdapat button login untuk masing-masing pengguna aplikasi, setelah melakukan pengisian kolom user name dan password dengan benar.

2. Desain interface halaman utama

Dibawah ini merupakan desain interface halaman utama aplikasi, halaman ini untuk kepala bagian dan manajer.

49

Gambar 3.21 Desain User Interface Halaman Utama

Pada gambar 3.21 diatas terdapat beberapa menu untuk melihat info workshop maupun project, selain itu juga di desain pop up untuk notifikasi, dan juga beberapa menu untuk melihat pelaporan.

3. Desain User Interface Admin divisi

Dibawah ini merupakan desain user interface Halaman Admin divisi, berisi tentang proses awal input data permintaan kebutuhan.

Gambar 3.22 Desain User Interface Admin Divisi

Pada gambar 3.22 diatas terdapat menu input permintaan sesuai divisi untuk dikirimkan ke persetujuan permintaan, info workshop daninfo alokasi.

4. Desain User Interface Permintaan Kebutuhan

Dibawah ini merupakan desain user interface Permintaan Kebutuhan, berisi tentang halaman proses input data permintaan.

51

Gambar 3.23 Desain User Interface Permintaan Kebutuhan

Pada gambar 3.23 diatas terdapat kolom nama barang, jumlah, satuan dan tanggal pembuatan serta tanggal dibutuhkannya permintaan. Setelah data ditambahkan data permintaan tersebut akan dikirim untuk dilakukannya proses persetujuan kepala bagian dan manajer.

5. Desain User Interface Persetujuan Permintaan

Dibawah ini merupakan desain user interface Halaman Persetujuan Permintaan, ini berisi tentang proses ACC permintaan dari kepala bagian dan manajer HSE.

Gambar 3.24 Desain User Interface Persetujuan Permintaan

Pada gambar 3.24 diatas berisi tentang persetujuan permintaan, dengan adanya halaman ini kepala bagian dan manajer bisa melakukan proses persetujuan maupun revisi permintaan.

3.2.8. Desain Input/Output

Desain input merupakan perancangan untuk memasukan data dari hasil transaksi maupun kegiatan yang dilakukan oleh objek dan subjek yang bersangkutan dan desain output adalah perancangan bentuk keluaran dari sebuah input yang dilakukan.

53

1. Desain Input Warehouse

Gambar 3.25 Desain Input Warehouse

Pada gambar 3.25 diatas dalam form tersebut terdapat kolom untuk penambahan barang yang ada di warehouse, data di warehouse ini berfungsi untuk pengecekan status barang untuk proses permintaan serta pembelian barang.

2. Desain Input Pengalokasian

Gambar 3.26 Desain Input Pengalokasian

Pada gambar 3.26 diatas adalah form alokasi, form tersebut untuk melakukan pelaporan barang permintaan yang sudah ada di warehouse maupun yang sudah dialokasikan.

55

3. Desain Output Laporan Permintaan

Gambar 3.27 Desain Output Laporan Permintaan

Pada gambar 3.27 diatas merupakan desain laporan permintan yang akan dikeluarkan oleh aplikasi, didalam laporan Permintaan ini terdapat Nama barang, jumlah,satuan, status, bulan, tanggal alokasi dan pesan dari pemohon.

4. Desain Output Laporan Pembelian

Gambar 3.28 Desain Output Laporan Pembelian

Pada gambar 3.28 diatas merupakan desain laporan pembelian, didalamnya terdapat Nama barang, jumlah,satuan, status, bulan, tanggal alokasi

dan pesan untuk barang yang akan dilakukannya proses pembelian kebutuhan barangselain itu terdapat tabel yang isinya adalah pelaporan harga total barang selama proses pembelian

5. Desain Output Rekap Permintaan

Gambar 3.35 Desain Output Rekap Permintaan

Pada gambar 3.29 diatas merupakan desain Rekap permintaan yang menampilkan jumlah permintaan dari masing-masing divisi departemen HSE, laporan tersebut juga di desain untuk bisa melihat per periode baik untuk per bulan maupun tahun.

3.3. Perancangan Uji Coba

(fungsional dan perhitungannya) Rancangan pengujian digunakan sebagai pedoman untuk menguji sistem dan memastikan kesesuaian hasil rancangan sistem telah memenuhi kebutuhan pengguna. Metode yang akan digunakan untuk pengujian adalah Black-Box Method. Ruang lingkup pengujian yang diterapkan yaitu : Pengujian Fungsional, Pengujian Antar Muka (Interface), dan Pengujian Keamanan dan Hak Akses.

57

Tabel 3.14 Rancangan Uji Halaman Detail Workshop

No Tujuan Input Output Diharapkan

1 Menguji halaman detail kebutuhan workshop

Menguji tombol detail dari kebutuhan workshop

Menampilkan detail dari workshop

2 Menguji tombol view dari detail kebutuhan workshop

Memasukkan username dan password yang telah diverifikasi

Masuk pada halaman yang sesuai divisi dan sesuai dengan hak aksesnya

Proses rancangan halaman pada Tabel 3.14 diatas bertujuan untuk verifikasi user yang akan masuk aplikasi persetujuan permintaan kebutuhan dengan memasukkan username dan password sehingga bisa masuk sesuai divisi dan hak aksesnya.

Tabel 3.15 Rancangan Uji coba form master warehouse

No Tujuan Input Output Diharapkan

1 Menguji button tambah untuk data barang baru

Menekan button tambah Data tersimpan pada database, ”data barang disimpan”.

2 Menguji field harga Memasukkan tipe data yang bukan numeric

“harga tidak boleh huruf”

3 Ubah data barang Klik filed pada baris untuk ubah data

Tampil form edit, “data berhasil disimpan”

Proses rancangan halaman master warehouse pada Tabel 3.15 diatas bertujuan untuk maintenance data barang yang ada pada departemen HSE, data tersebut diupdate oleh bagian prmbelian, dengan memasukkan data nama barang, jumlah, satuan serta harga barang.

Tabel 3.16 Rancangan Uji Coba Halaman divisi

No Tujuan Input Output Diharapkan

1 Menguji username dan password

Memasukkan data username atau password yang salah

Menampilkan pesan kesalahan login

2 Menguji login sesuai divisi Memasukkan username dan password yang telah diverifikasi

Masuk pada halaman yang sesuai divisi dan sesuai dengan hak aksesnya

Tabel 3.17 Rancangan Uji Coba Halaman input permintaan

No Tujuan Input Output Diharapkan

1 Menambah data permintaan barang

Pilih id permintaan pada kolom permintaan

Menampilkan data permintaan sesuai id 2 Menguji ubah data Memasukkan tekan field

yang akan diubah

Data berhasil diubah dan disimpan di database 3 Menguji hapus data

permintaan

Tekan tombol silang pada baris data yang dipilih

Data terhapus dari database, “data berhasil dihapus

4 Menguji permintaan dapat dikirim

Tekan tombol ‘kirim’ Data masuk ke database,

“data berhasil dikirim”

Tabel 3.18 Rancangan Uji Coba Halaman Persetujuan

No Tujuan Input Output Diharapkan

1 Menampilkan data permintaan barang Memasukkan id permintaan Menampilkan permintaan berdasarkan id permintaan

2 Menyimpan data persetujuan

Memasukkan status Approve pada kolom persetujuan

Data tersimpan di database, “Data persetujuan berhasil disimpan”

59

3 Menguji hapus data permintaan

Tekan tombol silang pada baris data yang dipilih

Data terhapus dari database, “data berhasil dihapus

4 Menguji permintaan dapat dikirim

Tekan tombol ‘kirim’ Data masuk ke database,

“data berhasil dikirim”

Tabel 3.19 Rancangan Uji Coba Notifikasi Persetujuan Permintaan

No Tujuan Input Output Diharapkan

1 Menampilkan data permintaan barang Memasukkan id permintaan Menampilkan permintaan berdasarkan id permintaan

2 Menyimpan data persetujuan

Memasukkan status Approve pada kolom persetujuan

Data tersimpan di database, “Data persetujuan berhasil disimpan”

3 Menguji hapus data permintaan

Tekan tombol silang pada baris data yang dipilih

Data terhapus dari database, “data berhasil dihapus

4 Menguji permintaan dapat dikirim

Tekan tombol ‘kirim’ Data masuk ke database,

“data berhasil dikirim” 5 Menguji notifikasi email

masuk kepada kepala divisi maupun manager HSE

Cek email kepala bagian yang dilakukan transaksi pengiriman permintaan, serta email manager HSE

Email masuk,

“ada permintaan barang masuk”

60

Testing dan Evaluasi

aplikasi

pengkodean

aplikasi Running aplikasi

Tahapan Testing dan Evaluasi

BAB IV

IMPLEMENTASI_DAN_EVALUASI

Pada tahap ini, desain yang telah dibuat pada tahap sebelumnya diimplementasikan dalam bentuk kode-kode program. Perangkat lunak lain dibutuhkan pengembang untuk melakukan menuliskan kode-kode program. Selain itu, perangkat lunak lain juga dibutuhkan untuk melakukan pengembang dalam membangun database dari desain yang telah dibuat pada tahap sebelumnya. Beberapa tahapan dalam implementasi sistem ini meliputi pengkodean website

running website, dan testing.

Pada Blok diagram diatas dalam proses terdapat tiga (3) proses yaitu pengkodean website, running website, dan testing website. Pengkodean yaitu pembuatan website menggunakan kode-kode program. Hasil dari pengkodean menjadi website Aplikasi workflow persetujuan permintaan workshop. Setalah itu dilakukan running dan testing untuk mendapatkan kesesuaian antara desain yang dibuat dengan website yang dihasilkan. Untuk melakukan website dapat berjalan

61

pada komputer pribadi maka pengembang menginstall website pendukung yaitu XAMPP.

4.1 Implementasi

Implementasi program merupakan penyesuaian perangkat lunak dengan rancangan dan desain sistem yang telah dibuat sebelumnya. Diharapkan dengan adanya implementasi ini dapat membantu Departemen HSE dalam melakukan permintaan, persetujuan dan pembelian barang jadi lebih optimal. Sebelum menjalankan aplikasi, hal yang harus diperhatikan untuk pertama kali adalah kebutuhan untuk dapat menjalankan sistem ini. Kebutuhannya terdiri dari perangkat keras (hardware) dan perangkat lunak (software).

4.1.1 Kebutuhan Perangkat Keras

Kebutuhan minimal perangkat keras untuk server yaitu adalah sebagai berikut.

1. Processor: Intel (x86), AMD64, dan Intel EM64T. 2. Physical memory (RAM) 1 GB.

3. Hard disk space 50 GB.

4. Screen Resolution 1024 X 768. 5. Monitor, mouse dan keyboard. 4.1.2 Kebutuhan Perangkat Lunak

Kebutuhan minimal perangkat lunak untuk server yaitu adalah sebagai berikut.

1. Sistem Operasi : Windows XP Professional. 2. Browser : Mozilla Firefox dan Google Chrome

3. Web server : XAMPP 4. Web Editor : Notepad++. 4.2 Evaluasi

Evaluasi sistem ini dilakukan untuk menguji apa yang diharapkan dan dibutuhkan telah tercapai atau tidak dengan beberapa test case dalam pengujiannya.

4.2.1 Evaluasi Hasil Uji Coba Sistem

Aplikasi workflow persetujuan permintaan kebutuhan workshop ini dijalankan berdasarkan pembagian hak akses untuk setiap pengguna. Dalam uji coba ini melibatkan beberapa user yaitu Super admin, Admin Divisi, Kabag dan Manager HSE. Penjelasan berikut difokuskan pada fungsi-fungsi utama sistem sesuai dengan kebutuhan dan tujuan yang diharapkan. Berikut fungsi-fungsi aplikasi sesuai dengan tujuan yang telah dirumuskan.

A. Analisis Admin Divisi

Analisa admin divisi merupakan proses penentuan kebutuhan sebelum dilakukannya proses permintaan kebutuhan workshop oleh masing-masing divisi pada departemen HSE. Proses ini dimulai setelah masuk data dari tender

workshop, masing-masing divisi akan menginputkan data kebutuhan workshop

pada aplikasi yang dapat dilihat pada Gambar 4.2, yang nantinya akan menghasilkan daftar kebutuhan, daftar kebutuhan dapat dilihat pada Gambar 4.3, dari daftar kebutuhan ini maka masing-masing divisi dapat melihat kebutuhan barang apa saja sesuai divisi mereka yang akan dilakukan permintaan. Data permintaan kemudian akan diajukan persetujuan kepada kepala bagian divisi dan

63

manajer HSE. Berikut menu tab pembuatan permintaan dan daftar persetujuan kepala bagian maupun manajer dapat dilihat pada Gambar 4.4 dan Gambar 4.5.

Gambar 4.2 Detil Workshop

Gambar 4.4 Form Buat Permintaan

Gambar 4.5 Daftar Persetujuan B. Persetujuan Kepala Bagian dan Manajer

Dari permintaan kebutuhan yang telah dibuat oleh pemohon, permintaan kebutuhan akan dikirimkan kepada kepala bagian divisi dan manajer HSE, setelah proses pengiriman daftar persetujuan kepala bagian divisi akan memperoleh notifikasi berupa email yang berisi pesan bahwa ada permintaan barang barang masuk, notifikasi tersebut dapat dilihat pada Gambar 4.6. Kemudian setelah kepala bagian maupun manajer membuka daftar persetujuan permintaan barang, Kepala bagian

65

dapat melihat acuan persetujuan dengan melihat data barang di warehouse maupun detil dari kebutuhan workshop. Proses persetujuan permintaan dan acuan pemberian persetujuan maupun revisi permintaan dapat dilihat pada Gambar 4.7.

Gambar 4.6 Notifikasi Email

Gambar 4.7 Persetujuan Permintaan

C. Pembelian

Dari proses persetujuan yang telah dilakukan akan muncul daftar pembelian barang (Gambar 4.8) dan daftar barang yang siap dialokasikan,. Pembelian kebutuhan dilakukan jika barang yang diminta tidak ada pada warehouse atau kurang dari jumlah barang yang diminta, sedangkan barang yang siap dialokasikan adalah barang yang tersedia pada warehouse atau jumlah di warehouse lebih dari barang yang diminta oleh pemohon, maka barang tersebut

siap langsung untuk dilakukan proses pengalokasian kebutuhan. Pengalokasian kebutuhan dapat dilihat pada Gambar 4.9.

Gambar 4.8 Daftar Pembelian

Gambar 4.9 Alokasi Permintaan Kebutuhan

D. Pengalokasian

Pengalokasian kebutuhan dilakukan setelah permintaan disetujui oleh kepala bagian divisi maupuun manajer HSE, alokasi kebutuhan dapat segera dilakukan jika barang yang diminta sudah ada pada warehouse maupun sudah dilakukan pembelian. Alokasi kebutuhan barang dilakukan sesuai divisi pemohon, berikut daftar alokasi yang disertai divisi pemohon, jumlah barang yang dialokasikan dan tanggal alokasi barang dapat dilihat pada Gambar 4.10.

67

Gambar 4.10 Daftar Barang Yang Dialokasikan E. Laporan

Dari permasalahan tidak adanya pembuatan laporan tentang permintaan kebutuhan dan pembelian kebutuhan workshop dari semua bagian yang membuat admin umum merekap kembali form dari semua bagian jika sewaktu-waktu dibutuhkan pelaporan, maka aplikasi telah membuat output berupa laporan permintaan, yang dapat dilihat pada Gambar 4.11, laporan permintaan dapat dibuat sesuai periode yang diminta, dapat berupa mingguan, bulanan maupun pertahun, begitu juga dengan laporan pembelian yang dapat dilihat pada Gambar 4.12. Sedangkan laporan rekap permintaan adalah jenis laporan yang memberikan informasi semua permintan kebutuhan yang direkap berdasarkan workshop dan divisi, laporan rekap ini juga bisa dibuat secara periode. Gambar laporan rekap permintaan kebutuhan dapat dilihat pada Gambar 4.13.

Gambar 4.11 Laporan Permintaan

Gambar 4.12 Laporan Pembelian

69

4.3 Evaluasi Hasil Pengujian Sistem

Tabel 4. 1 Uji Coba Halaman Login Objek Pengujian Halaman Login

Keterangan Mengetahui tampilan dan fungsi yang terdapat dalam Halaman Login dapat berjalan dan menghasilkan keluaran yang diharapkan.

No Tujuan Pengujian Masukan Keluaran Hasil

Pengujian 1. Menguji Textbox

untuk Password.

Karakter keyboard bebas

Karakter yang dimasukkan tidak tampil

Uji Berhasil (Gambar 4.14)

2. Menguji Textbox untuk username

Karakter keyboard bebas

Karakter yang dimasukkan tampil 3. Menguji Fungsi

Tombol

Tombol Login Peringatan

Username atau Password salah Uji Berhasil (Gambar 4.15) Peringatan login sukses Uji Berhasil (Gambar 4.16) 4. Menguji Fungsi

tambah pengguna

Text box tambah pengguna

Tampil form regrestasi Uji Berhasil (Gambar 4.17) Tombol simpan pengguna 5. Menguji fungsi login

sebagai admin divisi

Login menggunakan username divisi Menampilkan halaman admin divisi Uji Berhasil (Gambar 4.18)

6. Menguji fungsi login sebagai admin E-HSE

Login

menggunakan

username admin

E-HSE Menampilkan halaman admin Uji Berhasil (Gambar 4.19)

Gambar 4.14 Hasil Uji Coba Textbox Username dan Password

71

Gambar 4.16 Hasil Uji Login Sukses

Gambar 4.18 Uji Coba Sebagai Pengguna Admin Divisi

Gambar 4.19 Uji Coba Sebagai Super Admin

Tabel 4. 2 Uji Coba Halaman Permintaan Objek Pengujian Halaman Permintaan

Keterangan Mengetahui tampilan dan fungsi yang terdapat dalam halaman Permintaan dapat berjalan dan menghasilkan keluaran yang diharapkan.

No Tujuan Pengujian Masukan Keluaran Hasil

Pengujian 1. Menguji Textbox

untuk buat permintaan

Mengisi Combo

Box nama barang

Karakter yang dimasukkan muncul

Uji Berhasil (Gambar 4.20)

Mengisi Combo

Box Bulan

Karakter yang dimasukkan tidak muncul Mengisi Textbox Karakter yang

73

Objek Pengujian Halaman Permintaan

Keterangan Mengetahui tampilan dan fungsi yang terdapat dalam halaman Permintaan dapat berjalan dan menghasilkan keluaran yang diharapkan.

No Tujuan Pengujian Masukan Keluaran Hasil

Pengujian Nama Jumlah dimasukkan

tampil Mengisi Textbox

alamat Tanggal Buat

Karakter yang dimasukkan muncul Mengisi Textbox

jumlah

Karakter yang dimasukkan muncul Mengisi Text

Box Pesan

Pemohon

Karakter yang dimasukkan muncul Mengisi Text

Box Tanggal Alokasi

Karakter yang dimasukkan muncul 2. Menguji fungsi tombol Tombol Simpan Konfirmasi

data telah disimpan Uji Berhasil (Gambar 4.21) Konfirmasi Textbox belum diisi Uji Berhasil (Gambar 4.22)

Gambar 4.20 Uji Coba Textbox Buat Permintaan

75

Gambar 4.22 Uji Coba Konfirmasi TextBox Belum Diisi Lengkap

Tabel 4. 3 Uji Coba Halaman Data Workshop Objek Pengujian Halaman Workshop

Keterangan Mengetahui tampilan dan fungsi yang terdapat dalam Halaman Workshop dapat berjalan dan menghasilkan keluaran yang diharapkan.

No Tujuan Pengujian Masukan Keluaran Hasil

Pengujian 1. Menguji Textbox nama

workshop

Karakter keyboard bebas

Karakter yang dimasukkan tampil

Uji Berhasil (Gambar 4.23)

2. Menguji date picker untuk tanggal

Pilih tanggal Tanggal dapat di set

3. Menguji Tahun Periode

Pilih Tahun Uji Berhasil

(Gambar 4.24) Tahun

berhasil di set

Uji Berhasil (Gambar 4.25) 4. Menguji Fungsi

tambah workshop Tombol selanjutnya Data workshop berhasil disimpan Uji Berhasil (Gambar 4.26)

Gambar 4.24 Ujicoba Date Pick Tanggal Workshop

Gambar 4.25 Ujicoba Date Pick Tahun Periode Workshop

Gambar 4.26 Ujicoba Simpan Workshop

Tabel 4. 4 Uji Coba Halaman Persetujuan Objek Pengujian Halaman Persetujuan

Keterangan Mengetahui tampilan dan fungsi yang terdapat dalam Halaman Persetujuan dapat berjalan dan menghasilkan keluaran yang diharapkan.

No Tujuan Pengujian Masukan Keluaran Hasil

Pengujian 1. Menguji view detil

workshop

Klik button view

worhshop

Daftar detil

workshop tampil Uji Berhasil (Gambar 4.27) Uji Berhasil (Gambar 4.28) 2. Menguji Textbox

untuk username

Klik button view

warehouse

Karakter yang dimasukkan tampil 3. Menguji Fungsi

Tombol ACC

Button ACC Data berhasil

disetujui, status berubah

“sudah di

approve

Peringatan login sukses

Uji Berhasil (Gambar 4.29) 4. Menguji Revisi Tombol revisi Tampil form

pesan revisi

Uji Berhasil (Gambar 4.30)

77

Objek Pengujian Halaman Persetujuan

Keterangan Mengetahui tampilan dan fungsi yang terdapat dalam Halaman Persetujuan dapat berjalan dan menghasilkan keluaran yang diharapkan.

No Tujuan Pengujian Masukan Keluaran Hasil

Pengujian

Gambar 4.27 Ujicoba View Detil Workshop

Gambar 4.35 Ujicoba Date Time Pick Laporan Permintaan

83

Gambar 4.37 Ujicoba reset

Gambar 4.39 Ujicoba Tampilkan Laporan Pembelian

85

Gambar 4.41 Ujicoba Tampilkan Laporan Rekap

86

2. Aplikasi ini mampu mengelola daftar kebutuhan sampai pada tahap detil work-shop, mengelola permintaan, pembelian dan pengalokasian kebutuhan masing-masing divisi pada departemen HSE.

3. Dan juga dapat menampilkan laporan permintaan barang, laporan pembelian barang, laporan rekap permintaan dari semua bagian.

5.2 Saran

Berdasarkan penelitian dan penyusunan laporan yang telah dibuat, saran yang dapat diberikan sebagai pertimbangan untuk pengembangan sistem maupun penelitian selanjutnya adalah sebagai berikut:

1. Dibuatnya sistem notifikasi juga untuk ketersediaan barang pada warehouse yang dapat memberikan info terhadap siapa saja yang bersangkutan.

2. Aplikasi ini kedepannya bisa di integrasikan antara departemen HSE dengan bagian keuangan PT. Bangun Sarana Baja, yang nantinya diharapkan bisa menentukan anggaran masing-masing kebutuhan workshop.

3. Ditambahkannya fitur-fitur yang mendukung fungsi dan oprasional aplikasi bisa berjalan lebih baik lagi.

87

DAFTAR PUSTAKA

Herlambang, Soendoro, dan Tanuwijaya, Haryanto. 2005. Sistem Informasi: konsep, teknologi, dan manajemen. Yogyakarta: Graha Ilmu.

Himayati. 2008. Eksplorasi Zahir Accounting. Jakarta: PT Elex Media Komputindo.

Jogiyanto. 1990. Analisis dan Disain Sistem Informasi. Yogyakarta: ANDI.

Kadir, Abdul. 2008. Dasar Pemrograman WEB Dinamis Menggunakan PHP. Yogyakarta: ANDI.

Kendall, K.E. dan Kendall, J.E. 2003. Analisis dan Perancangan Sistem. (B. M. Thamir Abdul Hafedh Al-Hamdany, Penerj.) Jakarta: Pearson Education Asia Pte. Ltd. dan PT. Prenhallindo.

Risky, Muhammad. 2011. Testing dan Implementasi Sistem dan Penerapannya. Jakarta : Salemba Empat

Sutisna, Dadan. 2007. 7 Langkah Mudah Menjadi Webmaster. Jakarta Selatan: Mediakita.

Suprianto, Aji. 2005. Pengantar Teknologi Informasi. Jakarta: Salemba Infotek Talaway, I. 2004. Adaptive WFMS. Fakultas Ilmu Komputer. Universitas

Indonesia.

Yourdon, Edward. 1989. Modern Structure Analysis. USA: Prentice-Hall.

Zaki, Ali. 1999. E-Life Style: Memanfaatkan Beragam Perangkat Teknologi Digital. Jakarta: Salemba Infotek.