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
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.
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
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
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.
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.
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
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
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.
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
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 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).
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.
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.
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
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 :
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
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
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
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
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
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
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
[image:33.595.96.512.170.647.2]dibeli end setuju T Y setuju T Y
Gambar 3.4 System flow Persetujuan Permintaan Kebutuhan.
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
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.
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
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
[image:37.595.175.454.82.295.2]Mengecek data alok asi
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)
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
[image:40.595.96.504.82.530.2]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
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
[image:41.595.93.514.112.533.2]Input data perm intaan
Gambar 3.14 DFD Level 1, Mengelola Data 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
[image:44.595.99.510.120.513.2]<pi> Variable characters (8) Variable characters (50) Number Identifier_1 <pi>
Gambar 3.18 CDM Aplikasi Workflow Permintaan Kebutuhan.
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
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
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
[image:51.595.91.506.312.560.2]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
1. Desain User Interface Halaman Login
[image:52.595.92.506.189.512.2]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
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
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
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
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
53
[image:57.595.99.512.122.533.2]1. Desain Input Warehouse
Gambar 3.25 Desain Input Warehouse
2. Desain Input Pengalokasian
Gambar 3.26 Desain Input Pengalokasian
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.
[image:59.595.94.514.186.633.2]4. Desain Output Laporan Pembelian
Gambar 3.28 Desain Output Laporan Pembelian
dan pesan untuk barang yang akan dilakukannya proses pembelian kebutuhan barangselain itu terdapat tabel yang isinya adalah pelaporan harga total barang selama proses pembelian
[image:60.595.95.514.205.498.2]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
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”
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
[image:62.595.94.518.313.530.2]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
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,
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.
[image:64.595.93.503.320.526.2]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.
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
63
[image:67.595.93.511.138.646.2]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
65
dapat melihat acuan persetujuan dengan melihat data barang di warehouse maupun
detil dari kebutuhan workshop. Proses persetujuan permintaan dan acuan pemberian
[image:69.595.96.509.186.540.2]persetujuan maupun revisi permintaan dapat dilihat pada Gambar 4.7.
Gambar 4.6 Notifikasi Email
Gambar 4.7 Persetujuan Permintaan
C. Pembelian
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
67
Gambar 4.10 Daftar Barang Yang Dialokasikan E. Laporan
Gambar 4.11 Laporan Permintaan
Gambar 4.12 Laporan Pembelian
69
[image:73.595.98.519.136.568.2]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
Gambar 4.14 Hasil Uji Coba Textbox Username dan Password
71
[image:75.595.93.507.275.555.2]Gambar 4.16 Hasil Uji Login Sukses
Gambar 4.18 Uji Coba Sebagai Pengguna Admin Divisi
[image:76.595.108.515.469.735.2]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
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
Gambar 4.20 Uji Coba Textbox Buat Permintaan
