Gambar 4.34 Cluster Jadwal Produksi. jadwal produksi oleh Kepala Pabrik. Seperti yang sudah dijelaskan dalam system

274

Gambar 4.34 Cluster Jadwal Produksi

Cluster jadwal produksi berisi class-class yang berhubungan dengan pembuatan jadwal produksi oleh Kepala Pabrik. Seperti yang sudah dijelaskan dalam system

definition, jadwal produksi berfungsi sebagai petunjuk bagi karyawan Bagian Produksi dalam menentukan jenis pigura yang harus diproduksi, jumlahnya, dan spesifikasi khusus yang perlu diperhatikan selama proses produksi. Selain itu masing-masing jadwal produksi terdiri dari instruksi produksi yang merupakan panduan bagi karyawan Bagian Produksi dan Bagian Pengemasan dalam menjalankan proses produksi dan nilainilai target yang harus dipenuhi selama proses pengendalian kualitas. Karena itu hubungan antara jadwal produksi dan instruksi produksi merupakan hubungan agregasi.

Gambar 4.35 Cluster Mesin

Cluster mesin hanya terdiri dari 1 class, yaitu mesin. Class ini menjelaskan mesin-mesin yang digunakan selama proses produksi pigura di PT Decorindo Raya.

275 Masing-masing class dalam tabel 4.47 memiliki aktivitasnya masing-masing. Beberapa aktivitas yang dilakukan oleh class-class tersebut berhubungan dengan sistem informasi yang akan dibangun. Aktivitas-aktivitas seingkali disebut sebagai event dan perlu diidentifikasi sebelum sistem informasi dibuat. Sama seperti dalam mendefinisikan

class, pertama-tama perlu dicari event candidate yang diperoleh dari kata kerja yang terdapat dalam system definition. Tabel 4.48 Event Candidate Sistem Pengendalian Kualitas Usulan 1. Memasukkan data pesanan 2. Membaca pesanan 3. Membuat jadwal produksi 4. Membuat instruksi produksi 5. Membaca jadwal produksi 6. Membaca instruksi produksi 7. Dinyatakan lulus uji kualitas 8. Menghasilkan pigura berkualitas 9. Memudahkan 10. Mengoperasikan mesin 11. Menyimpan 12. Dievaluasi 13. Memeriksa pigura 14. Membuat laporan pigura cacat 15. Diproduksi 16. Dicatat 17. Dikelompokkan 18. Dikembalikan 19. Diperbaiki

20. Membuat laporan rework 21. Dilakukan 22. Mencakup 23. Mengetahui 24. Digunakan 25. Mengajukan komplain 26. Membuat laporan bahan baku cacat 27. Diakses 28. Dibutuhkan 29. Membaca laporan 30. Meningkatkan kualitas 31. Dicetak 32. Merugikan 33. Dideteksi 34. Diatasi 35. Dibangun 36. Ditambah 37. Diubah 38. Dihapus

Sumber : Hasil Analisa dan Pembahasan

Dari event candidate, dipilih beberapa di antaranya yang berhubungan dengan

class-class yang sudah ditentukan sebelumnya. Selain itu, event-event yang dipilih harus bersifat instan dan dapat diidentifikasi saat terjadinya. Event-event tersebut antara lain :

276 Tabel 4.49 Event Sistem Pengendalian Kualitas Usulan 1. 2. 3. 4. 5. 6. 7. 8.

Memasukkan data pesanan Membaca pesanan Membuat jadwal produksi Membuat instruksi produksi Membaca jadwal produksi Membaca instruksi produksi Membuat laporan pigura cacat Membuat laporan rework

9. Membuat laporan bahan baku cacat 10. Dicetak 11. Mengelola data konsumen 12. Mengelola data supplier 13. Mengelola data pigura 14. Mengelola data bahan baku 15. Mengelola data mesin


Dari tabel 4.49 di atas, terlihat ada beberapa event tambahan yang sebenarnya bukan merupakan kata kerja di dalam system definition, yaitu nomor pada 12 sampai 15. Bila diperhatikan, kesembilan event tersebut melibatkan 5 objek, yaitu konsumen,

supplier, pigura, bahan baku, dan mesin. Kelimanya memiliki event yang sama yaitu mengelola. Karena event tersebut dilakukan oleh class yang berbeda, maka harus dipisahkan berdasarkan objek yang terlibat. Hubungan antara setiap event dengan class-

class yang ada dapat dilihat pada event table berikut :

277

*

Mengelola data mesin

Mengelola data supplier

*

Mengubah data bahan baku

Mengelola data konsumen

*

Mengelola data pigura

Dicetak

Membuat laporanrework

Membuat laporan pigura cacat

Membaca instruksi produksi

+

Membaca jadwal produksi

Pesanan

Membuat instruksi produksi

*

Membuat jadwal produksi

General Manager

Membaca pesanan

Class

Memasukkan data pesanan

Event

Membuat laporan bahan baku cacat

Tabel 4.50 Event Table Sistem Pengendalian Kualitas Usulan

*

*

+ +

Konsumen

+

Pigura *

Kepala Pabrik

*

*

+

Jadwal produksi

* *

+

Instruksi produksi

+ *

Bagian Produksi

*

*

* +

Mesin *

Bagian Pengemasan

* +

Pigura cacat

+ +

Rework

+ *

Supervisor

+

Bahan baku +

Bahan baku cacat

*

Supplier Keterangan :

+

+ *

sekali berulang


278 Seperti yang terdapat pada perusahaan-perusahaan pada umumnya, data-data karyawan PT Decorindo Raya juga disimpan dalam database. Karena masing-masing karyawan memiliki atribut yang sama, maka dapat dibuat hubungan generalisasi antara karyawan-karyawan tersebut. Dengan demikian, terdapat tambahn class baru yaitu Karyawan yang menampung atribut-atribut General Manager, Kepala Pabrik,

Supervisor, Bagian Produksi, dan Bagian Pengemasan. Class Karyawan dibuat dan diupdate oleh seorang administrator. Dengan kata lain, masing-masing karyawan tidak memiliki hak akses untuk mengubah atribut karyawan lainnya. Dengan memperhatikan event table dalam tabel 4.50, terlihat bahwa setiap event yang dilakukan oleh sebuah class melibatkan class lainnya. Class-class yang terlibat dalam sebuah event bisa berjumlah dua atau lebih. Hubungan antar class tersebut dapat digambarkan

secara

struktural

melaui

class

diagram

sebagai

berikut

:

279

Karyawan -Kode Karyawan : String -Password : String +Nama Karyawan : String #Alamat Karyawan : String #No Telp Karyawan : String -Gaji per Jam : Integer +dikelola()

Supervisor

Kepala Pabrik

Bagian Pengemasan

+Membuat laporan bahan baku cacat()

+Membaca pesanan() +Membuat jadwal produksi() +Membuat instruksi produksi() +Mencetak() +Mengelola data pigura() +Mengelola data bahan baku() +Mengelola data mesin()

+Membaca instruksi produksi() +Membuat laporan pigura cacat()

General Manager 1

+Memasukkan data pesanan() +Mencetak() +Mengelola data konsumen() +Mengelola data supplier()

1 1

1

1 1

1

1

1

1

1 *

1

1..*

1..*

1..*

0..*

1

0..*

Supplier

-Kode Konsumen : String +Nama Konsumen : String #Alamat Konsumen : String #No Telp Konsumen : String +Dikelola()

-Kode Supplier : String +Nama Supplier : String #Alamat Supplier : String #No Telp Supplier : String +Dikelola()

11..*

Bahan Baku

Pigura

-Kode Bahan Baku : String -Tanggal Pengiriman : Date +Nama Bahan Baku : String #Kode Supplier : String #Harga Bahan Baku : Integer #Volume Per Kemasan : Integer

-Kode Pigura : String -Kategori Pigura : String +Jenis Pigura : String -Warna Pigura : String -Jenis Profil : String +Harga per Meter : Integer +Dikelola()

*

1

1..*

Pigura Cacat -Kode Cacat : String -Tanggal Cacat : Date -Kode Produksi : String #Kode Karyawan : String -Kategori Cacat : String -Jumlah Cacat : Integer +Dicetak() 1 1

1 1..* 1 0..1 Pesanan

0..*

1

1

1..*

Konsumen

-Kode Pesanan : String +Tanggal Pesanan : Date -Kode Konsumen : String -Kode Pigura : String +Jumlah Pigura : Integer +Keterangan : String +Dibaca() +Dimasukkan()

+Membaca jadwal produksi() +Membaca instruksi produksi() * +Membuat laporan rework()

1

1..* 1..*

1

Bagian Produksi

Bahan Baku Cacat

0..*

-Kode Bahan Baku : String -Jumlah Cacat : Integer -Volume Diterima : Integer -Keterangan : String +Dicetak()

0..*

1..* 1

Rework Mesin -Kode Rework : String -Kode Mesin : String -Tanggal Rework : Date -Nama Mesin : String -Kode Karyawan : String -Kode Bahan Baku : String -Kode Cacat : String -Biaya Listrik per Jam : Integer -Penyebab Cacat : String -Bahan Baku per Jam : Integer -Keterangan Cacat : String +Dikelola() 1 1..* -Kode Mesin : String -Durasi Rework : Integer -Biaya Kualitas : Integer * 0..* +Dibuat() +Dicetak()

0..*

Gambar 4.36 Class Diagram Sistem Informasi Pengendalian Kualitas Usulan

Jadwal Produksi

0..1

-Kode Produksi : String -Tanggal Produksi : Date -Kode Pigura : String -Jumlah Pigura : Integer +Dibuat() +Dibaca()

1

0..*

1 1..* Instruksi Produksi

+Kode Mesin : String #Setting Mesin : String -Nilai Target Pigura : String 0..* 1

1

280 Dari class diagram dan event table yang sudah dibuat, selanjutnya dapat diketahui perilaku umum dari masing-masing class beserta atributnya. Atribut ini adalah data dan informasi yang terlibat dalam event yang dilakukan oleh sebuah class. Hubungan antara class dan atributnya dapat dilihat dalam bentuk state diagram. Berdasarkan sifat dari suatu hubungan agregasi, class turunan memiliki atribut dan event yang sama dengan class induknya. Oleh karena itu state diagram yang digambar cukup

class induknya saja. State diagram yang didapat dari class diagram pada gambar 4.30 adalah sebagai berikut : / mengelola_data_konsumen

/ memasukkan_data_pesanan

/ mencetak Aktif

/ mengelola_data_supplier

Gambar 4.37 State Diagram General Manager Tabel 4.51 Event dan Attribute Class General Manager Event

memasukkan_data_pesanan mengelola_data_konsumen mengelola_data_supplier

mencetak

Attributes kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan kode_konsumen, nama_konsumen, alamat_konsumen, no_telp_konsumen kode_supplier, nama_supplier, alamat_supplier, no_telp_supplier kode_bahan_baku, kode_bahan_baku_cacat, harga_bahan_baku, kode_supplier, tanggal_pengiriman, jumlah_cacat, keterangan, kode_pigura, kode_cacat, kode_produksi, tanggal_cacat, kode_karyawan, kategori_cacat, jumlah_cacat, kode_rework, tanggal_rework, penyebab_cacat, keterangan_cacat, durasi_rework, biaya_kualitas


281

Gambar 4.38 State Diagram Pesanan Tabel 4.52 Event dan Attribute Class Pesanan Event

dimasukkan dibaca disimpan

Attributes kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan


Gambar 4.39 State Diagram Konsumen Tabel 4.53 Event dan Attribute Class Konsumen Event

ditambah dikelola dihapus

Attributes kode_konsumen, nama_konsumen, alamat_konsumen, no_telp_konsumen nama_konsumen, alamat_konsumen, no_telp_konsumen kode_konsumen, nama_konsumen, alamat_konsumen, no_telp_konsumen


282

Gambar 4.40 State Diagram Pigura Tabel 4.54 Event dan Attribute Class Pigura Event


Attributes kode_pigura, kategori_pigura, jenis_pigura, warna_pigura, jenis_profil, harga_per_meter harga_per_meter kode_pigura, kategori_pigura, jenis_pigura, warna_pigura, jenis_profil, harga_per_meter


Gambar 4.41 State Diagram Kepala Pabrik

283 Tabel 4.55 Event dan Attribute Class Kepala Pabrik Event

membaca_pesanan membuat_jadwal_produksi mengelola_data_pigura mengelola_data_mesin mengelola_data_bahan_baku

mencetak

Attributes kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura kode_pigura, kategori_pigura, jenis_pigura, warna_pigura, jenis_profil, harga_per_meter kode_mesin, nama_mesin, kode_bahan_baku, biaya_listrik_per_jam, bahan_baku_per_jam kode_bahan_baku, nama_bahan_baku, kode_supplier, harga_bahan_baku, volume_diterima kode_bahan_baku, kode_bahan_baku_cacat, harga_bahan_baku, kode_supplier, tanggal_pengiriman, jumlah_cacat, keterangan, kode_pigura, kode_cacat, kode_produksi, tanggal_cacat, kode_karyawan, kategori_cacat, jumlah_cacat, kode_rework, tanggal_rework, penyebab_cacat, keterangan_cacat, durasi_rework, biaya_kualitas


Gambar 4.42 State Diagram Jadwal Produksi Tabel 4.56 Event dan Attribute Class Jadwal Produksi Event

dibuat dibaca disimpan

Attributes kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura


284

Gambar 4.43 State Diagram Bagian Produksi Tabel 4.57 Event dan Attribute Class Bagian Produksi Event

membaca_jadwal_produksi membuat_laporan_rework

Attributes kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura kode_rework, tanggal_rework, kode_karyawan, kode_cacat, penyebab_cacat, kode_mesin, durasi_rework, biaya_kualitas


Gambar 4.44 State Diagram Mesin Tabel 4.58 Event dan Attribute Class Mesin Event


Attributes kode_mesin, nama_mesin, kode_bahan_baku, biaya_listrik_per_jam, bahan_baku_per_jam biaya_listrik_per_jam kode_mesin, nama_mesin, kode_bahan_baku, biaya_listrik_per_jam, bahan_baku_per_jam


Gambar 4.45 State Diagram Bagian Pengemasan

285 Tabel 4.59 Event dan Attribute Class Bagian Pengemasan Event

membaca_instruksi_produksi membuat_laporan_pigura_cacat

Attributes kode_produksi, tanggal_produksi, kode_pigura, kode_instruksi, kode_mesin, setting_mesin, nilai_target_pigura kode_pigura, kode_cacat, kode_produksi, tanggal_cacat, kode_karyawan, kategori_cacat, jumlah_cacat


Gambar 4.46 State Diagram Rework Tabel 4.60 Event dan Attribute Class Rework Event

Attributes kode_rework, tanggal_rework, kode_karyawan, kode_cacat, penyebab_cacat, keterangan_cacat, kode_mesin, durasi_rework, biaya_kualitas kode_rework, tanggal_rework, kode_karyawan, kode_cacat, penyebab_cacat, keterangan_cacat, kode_mesin, durasi_rework, biaya_kualitas

dibuat dicetak


Gambar 4.47 State Diagram Supervisor Tabel 4.61 Event dan Attribute Class Supervisor Event

Attributes kode_bahan_baku, nama_bahan_baku, membaca_data_bahan_baku kode_supplier, harga_bahan_baku, volume_diterima kode_bahan_baku, kode_bahan_baku_cacat, membuat_laporan_bahan_baku_cacat kode_supplier, tanggal_pengiriman, jumlah_cacat, keterangan Sumber : Hasil Analisa dan Pembahasan

286

Gambar 4.48 State Diagram Supplier Tabel 4.62 Event dan Attribute Class Supplier Event


Attributes kode_supplier, nama_supplier, alamat_supplier, no_telp_supplier nama_supplier, alamat_supplier, no_telp_supplier kode_supplier, nama_supplier, alamat_supplier, no_telp_supplier


4.4.3. Application Domain Analysis

Pada tahap problem domain, diketahui permasalahan-permasalahan yang ada di perusahaan. Dari permasalahan tersebut, dibuat suatu model sistem usulan sehingga dapat meningkatkan kinerja karyawan yang bersangkutan. Setelah mendapatkan model dari sistem yang akan dibangun, selanjutnya perlu dirancang bagaimana karyawan perusahaan dapat berinteraksi dengan sistem tersebut sebagai user. Interaksi tersebut dapat digambarkan melalui use case diagram sebagai berikut :

287

Sistem Informasi Pengendalian Kualitas di PT Decorindo Raya

Login

Pengelolaan Password

Pengelolaan Data Konsumen dan Supplier

Pengelolaan Data Pigura, Bahan Baku, dan Mesin General Manager

Penerimaan Pesanan

Pelaporan Bahan Baku Cacat

Supervisor

Kepala Pabrik

Pembuatan Jadwal Produksi

Pembuatan Instruksi Produksi

Pelaporan Produk Cacat Bagian Produksi Pelaporan Hasil Rework

Bagian Pengemasan

Pencetakan Laporan

Gambar 4.49 Use Case Diagram Sistem Informasi Pengendalian Kualitas Usulan

288 Seperti yang terlihat dalam gambar 4.49, use case diagram terdiri dari beberapa

use case yang memiliki proses bisnis dan aktor yang berbeda-beda. Masing-masing use case tersebut dapat dijelaskan sebagai berikut : Tabel 4.63 Use Case Analysis Login Use Case Brief Description Pre Condition Basic Flow

Alternative Flow Special Requirement Post Condition

Login Use case ini menjelaskan tentang bagaimana karyawan melakukan login untuk masuk ke dalam sistem. - Kode dan data-data karyawan sudah terisi dengan lengkap dan tersimpan ke dalam sistem 1. Karyawan masuk ke layar Login. 2. Karyawan memasukkan kode karyawan dan password. 3. Sistem akan mengecek kesesuaian kode karyawan dan password yang dimasukkan user dengan yang tersimpan di database. 4. Jika datanya sesuai, maka karyawan akan langsung masuk ke halaman utama. Bila datanya tidak sesuai, sistem akan memberikan peringatan kepada karyawan dan layar Login akan direset kembali. 5. Use case selesai.

- Kode karyawan tidak boleh ada yang sama - Kode karyawan tidak dapat diubah-ubah lagi, hanya dapat dihapus - Password Karyawan akan masuk ke halaman utama dari sistem. Sumber : Hasil Analisa dan Pembahasan

289 Tabel 4.64 Use Case Analysis Pengelolaan Password Use Case Brief Description Pre Condition Basic Flow


Pengelolaan Password Use case ini menjelaskan tentang bagaimana Karyawan melakukan perubahan passwordnya masing-masing. - Kode dan data-data karyawan sudah terisi dengan lengkap dan tersimpan ke dalam sistem 1. Karyawan masuk ke layar Pengelolaan Password. 2. Karyawan memasukkan kode konsumen, password lama, dan password baru. 3. Sistem akan mengecek kesesuaian kode karyawan dan password yang dimasukkan user dengan yang tersimpan di database. 4. Jika datanya sesuai, maka sistem akan memberikan pesan bahwa perubahan password berhasil dan karyawan akan kembali ke halaman utama. Bila datanya tidak sesuai, sistem akan memberikan peringatan kepada karyawan dan layar Pengelolaan Password akan direset kembali. 5. Use case selesai.

-

Password

Password baru akan disimpan ke dalam database dan karyawan akan kembali ke halaman utama dari sistem. Sumber : Hasil Analisa dan Pembahasan

290 Tabel 4.65 Use Case Analysis Pengelolaan Data Pigura, Bahan Baku, dan Mesin Use Case Brief Description Pre Condition Basic Flow

Alternative Flow Special Requirement

Post Condition

Pengelolaan Data Pigura, Bahan Baku, dan Mesin Use case ini menjelaskan tentang bagaimana Kepala Pabrik mengelola data-data pigura, bahan baku, dan mesin yang tersimpan dalam database. - Kepala Pabrik memiliki data-data yang lengkap mengenai pigura, bahan baku, dan mesin 1. Kepala Pabrik masuk ke layar Pengelolaan Data. 2. Kepala Pabrik memilih data apa yang ingin dikelola. 3. Untuk menambah data baru, Kepala Pabrik memasukkan data-data berupa nama, jenis, warna, dan lain-lain. 4. Untuk mengubah data yang sudah ada, Kepala pabrik memasukkan kode pigura, bahan baku, atau mesin yang ingin diubah. Setelah itu Kepala Pabrik tinggal mengubah data-data tersebut, dan sistem akan melakukan update terhadap database. 5. Penghapusan data dilakukan berdasarkan kode pigura, bahan baku, atau mesin di mana semua data-data yang berhubungan dengan kode tersebut akan dihapus. 6. Use case selesai.

Kode pigura, bahan baku, dan mesin baru dibuat secara otomatis oleh sistem - Kode pigura, bahan baku, dan mesin tidak dapat diubah-ubah lagi, hanya dapat dihapus - Kode bahan baku dibedakan berdasarkan kode supplier dan tanggal pengirimannya. Bahan baku dengan jenis yang sama namun tanggal pengirimannya berbeda akan memiliki kode bahan baku yang berbeda juga - Kategori pigura hanya dapat bertipe boolean dan hanya dapat dipilih dari combo box di mana terdapat 2 pilihan, yaitu standar dan batangan - Harga bahan baku, harga per meter pigura, dan biaya listrik per jam dinyatakan dalam satuan Rupiah - Volume diterima dan bahan baku per jam harus berupa angka dan boleh berbentuk desimal Database pigura, bahan baku, dan mesin akan diupdate.

-


291 Tabel 4.66 Use Case Analysis Penerimaan Pesanan Use Case Brief Description

Pre Condition Basic Flow

Alternative Flow

Special Requirement

Post Condition

Penerimaan Pesanan Use case ini menjelaskan tentang bagaimana data-data pesanan konsumen yang diterima oleh General Manager akan dimasukkan ke dalam sistem informasi. Selanjutnya data-data pesanan tersebut akan dibaca oleh Kepala Pabrik sebagai dasar dalam menyusun jadwal dan instruksi produksi. - General Manager sudah menerima data-data pesanan dari konsumen dengan lengkap - Kode pesanan sudah terisi secara otomatis oleh sistem 1. General Manager masuk ke layar Penerimaan Pesanan 2. Sistem akan secara otomatis membuat kode pesanan baru dan mengisi tanggal pesanan berdasarkan tanggal pada saat itu 3. General Manager akan melihat database pigura, kemudian memasukkan kode pigura berdasarkan karakteristik pigura yang dipesan oleh konsumen 4. General Manager akan melihat database konsumen, kemudian memasukkan kode konsumen 5. General Manager akan memasukkan jumlah pigura yang dipesan beserta keterangan tambahan. Keterangan ini berisi tentang permintaan khusus yang diajukan oleh konsumen 6. Sistem akan memberikan sinyal kepada Kepala Pabrik sebagai tanda bahwa ada pesanan baru yang masuk ke sistem 7. Use case selesai 3. Untuk konsumen yang sudah sering memesan pigura di PT Decorindo Raya, biasanya mereka juga mengetahui kode pigura yang mereka pesan. Oleh karena itu General Manager tidak perlu melihat kode pigura di dalam database lagi melainkan langsung dari pesanan konsumen 5. Bila tidak ada permintaan khusus dari konsumen, maka bagian keterangan tidak perlu diisi - Kode pesanan tidak boleh ada yang sama - Kode konsumen dan kode pigura harus terisi - Jumlah pigura harus dimasukkan dalam satuan meter dan boleh dalam bentuk desimal Data pesanan konsumen tersimpan ke dalam sistem dan dapat dibaca ulang. Sumber : Hasil Analisa dan Pembahasan

292 Tabel 4.67 Use Case Analysis Pelaporan Bahan Baku Cacat Use Case Brief Description Pre Condition Basic Flow


Post Condition

Pelaporan Bahan Baku Cacat Use case ini menjelaskan tentang bagaimana Supervisor melaporkan bahan baku cacat yang diterima dari supplier. - Data-data supplier beserta bahan baku yang disuplainya sudah dimasukkan dengan lengkap oleh General Manager dan disimpan dalam database supplier 1. Supervisor masuk ke layar Pelaporan Bahan Baku Cacat. 2. Supervisor melihat ke dalam database bahan baku untuk melihat kode bahan baku berdasarkan nama bahan baku 3. Supervisor memasukkan data jumlah bahan baku yang cacat beserta keterangannya ke dalam database bahan baku cacat. 4. Use case selesai. 2. Sama seperti supplier, beberapa kode bahan baku yang sering digunakan dalam proses produksi juga sudah dihafal secara manual sehingga tidak perlu melihat ke dalam database terlebih dulu. - Tanggal pengiriman harus diisi - Kode bahan baku cacat dibuat oleh sistem secara otomatis - Jumlah cacat harus diisi dalam bentuk angka dan boleh berupa desimal Data-data bahan baku cacat tersimpan dalam database. Data tersebut sewaktu-waktu dapat dilihat kembali oleh General Manager dan Kepala Pabrik, serta dapat dicetak dalam bentuk laporan. Sumber : Hasil Analisa dan Pembahasan

293 Tabel 4.68 Use Case Analysis Pembuatan Jadwal Produksi Use Case Brief Description Pre Condition

Basic Flow


Pembuatan Jadwal Produksi Use case ini menjelaskan tentang bagaimana data-data pesanan konsumen dibaca oleh Kepala Pabrik dan dijadikan sebagai dasar dalam menyusun jadwal produksi. - Data-data pesanan konsumen sudah tersimpan dalam database - Kode jadwal produksi sudah terisi secara otomatis oleh sistem - Sistem memberikan sinyal kepada Kepala Pabrik sebagai tanda bahwa ada pesanan baru yang masuk ke sistem 1. Kepala Pabrik masuk ke layar Pembuatan Jadwal Produksi. 2. Kepala Pabrik akan melihat database pigura untuk melihat karakteristik pigura yang dipesan oleh konsumen berdasarkan kode pigura yang tercantum dalam pesanan. Selain itu Kepala Pabrik juga dapat melihat database mesin untuk mengecek data-data mesin yang akan digunakan selama proses produksi. 3. Kepala Pabrik akan membuat jadwal produksi yang berisi tentang tanggal produksi harus dimulai, jenis-jenis pigura yang harus diproduksi beserta jumlahnya. 4. Sistem akan memberikan sinyal kepada Bagian Produksi sebagai tanda bahwa ada jadwal produksi baru yang masuk ke sistem. 5. Use case selesai . 3. Untuk jenis-jenis pigura yang sering dipesan, Kepala Pabrik tidak perlu melihat lagi ke dalam database melainkan langsung membuat instruksi produksi. - Kode produksi tidak boleh ada yang sama - Kode pigura harus terisi - Jumlah pigura harus dimasukkan dalam satuan meter Jadwal produksi tersimpan ke dalam sistem dan dapat dibaca ulang oleh Kepala Pabrik. Sumber : Hasil Analisa dan Pembahasan

294 Tabel 4.69 Use Case Analysis Pembuatan Instruksi Produksi Use Case Brief Description Pre Condition Basic Flow


Post Condition

Pembuatan Instruksi Produksi Use case ini menjelaskan tentang bagaimana Kepala Pabrik membuat instruksi produksi untuk jadwal produksi yang sudah dibuat sebelumnya. - Data-data jadwal produksi sudah tersimpan dalam database - Kode instruksi produksi sudah terisi secara otomatis oleh sistem 1. Kepala Pabrik masuk ke layar Pembuatan Instruksi Produksi. 2. Kepala Pabrik akan mengecek data jadwal produksi di dalam database berdasarkan kode produksi. 3. Kepala Pabrik akan melihat database mesin untuk melihat jenisjenis mesin yang ada dan digunakanselama proses produksi pigura. 4. Kepala Pabrik membuat instruksi produksi yang mencakup mesinmesin apa saja yang digunakan selama produksi, setting untuk tiap mesin tersebut, dan nilai target yang diharapkan dari pigura. Masing-masing mesin dibuat dalam instruksi produksi yang berbeda-beda. 5. Use case selesai . 3. Untuk jenis-jenis pigura yang sering dipesan, Kepala Pabrik tidak perlu melihat lagi ke dalam database melainkan langsung membuat instruksi produksi. - Kode instruksi tidak boleh ada yang sama - Masing-masing instruksi produksi harus memiliki kode produksi - Kode mesin dan setting mesin harus terisi - Nilai target pigura harus terisi dan berbentuk numerik Instruksi produksi tersimpan ke dalam sistem dan dapat dibaca ulang oleh Kepala Pabrik. Sumber : Hasil Analisa dan Pembahasan

295 Tabel 4.70 Use Case Analysis Pelaporan Produk Cacat Use Case Brief Description

Pre Condition

Basic Flow


Post Condition

Pelaporan Produk Cacat Use case ini menjelaskan tentang bagaimana Bagian Pengemasan menggunakan instruksi produksi untuk memeriksa pigura-pigura yang sudah selesai diproduksi, kemudian mencatat data-data pigura yang tidak sesuai dengan nilai target. - Data-data karakteristik pigura sudah dibuat dengan lengkap dan disimpan dalam database pigura - Jadwal dan instruksi produksi sudah dibuat dengan lengkap oleh Kepala Pabrik dan disimpan dalam database 1. Bagian Produksi masuk ke layar Pelaporan Produk Cacat. 2. Bagian Pengemasan melihat instruksi produksi yang sudah disimpan dalam database berdasarkan kode produksinya masingmasing. 3. Pada instruksi produksi hanya tercantum kode pigura yang diproduksi. Oleh karena itu Bagian Pengemasan perlu melihat database berdasarkan kode pigura tersebut untuk mengetahui karakteristik pigura. 4. Bagian Pengemasan akan memasukkan data-data mengenai pigura yang cacat ke dalam sistem. Cacat bisa berupa ketidaksesuaian dengan karakteristik pigura (misalnya warna, jenis profil, dll) ataupun ketidaksesuaian dengan nilai target pigura. Sistem akan secara otomatis membuat kode cacat yang baru dan memasukkan tanggal cacat berdasarkan tanggal pada saat itu. 5. Apabila terdapat kategori cacat yang bersifat reusable, sistem akan mengirimkan sinyal kepada Bagian Produksi. Sinyal ini sebagai tanda bahwa terdapat produk yang harus diperbaiki. 6. Use case selesai. 2. Untuk jenis-jenis pigura yang sering dipesan, Bagian Pengemasan tidak perlu melihat lagi ke dalam database melainkan langsung memeriksa produk dan membuat laporan bila terjadi cacat - Kode karyawan yang memasukkan data-data cacat harus diisi - Kode produksi harus diisi untuk menunjukkan produksi mana yang menghasilkan pigura tersebut - Satu kode cacat hanya dapat menampung satu kode karyawan - Kategori cacat bertipe boolean, di mana hanya terdapat 2 pilihan yaitu reusable dan non-reusable - Jumlah cacat harus dimasukkan dalam satuan meter Data-data produk cacat tersimpan dalam database. Data tersebut sewaktuwaktu dapat dilihat kembali oleh General Manager dan Kepala Pabrik, serta dapat dicetak dalam bentuk laporan. Sumber : Hasil Analisa dan Pembahasan

296 Tabel 4.71 Use Case Analysis Pelaporan Hasil Rework Use Case Brief Description Pre Condition

Basic Flow

Alternative Flow

Special Requirement

Pelaporan Hasil Rework Use case ini menjelaskan tentang bagaimana Bagian Produksi membaca data-data pigura pigura yang harus diperbaiki dan melaporkan hasil perbaikannya. - Data-data pigura cacat sudah dimasukkan dengan lengkap dan disimpan dalam database pigura cacat - Data-data mesin dan sumber daya yang dibutuhkan sudah dibuat dengan lengkap dan disimpan dalam database mesin - Sistem memberikan sinyal kepada Bagian Produksi sebagai tanda bahwa ada pigura cacat yang harus diperbaiki 1. Bagian Produksi masuk ke layar Pelaporan Hasil Rework. 2. Bagian Produksi memeriksa database pigura cacat berdasarkan kode cacat untuk memeriksa apabila terdapat pigura cacat yang harus diperbaiki. 3. Sistem akan secara otomatis membuat kode rework dan memasukkan tanggal rework berdasarkan tanggal pada saat itu. 4. Setelah menerima pigura cacat dari Bagian Pengemasan, Bagian Produksi akan memeriksanya dan memasukkan penyebab cacat dan keterangannya ke dalam sistem. 5. Pada umumnya Bagian Produksi hanya mengenali berdasarkan nama mesin. Oleh karena itu Bagian Produksi akan melihat kode mesin berdasarkan namanya di database mesin. 6. Bagian Produksi akan memasukkan kode mesin yang digunakan ke dalam database rework. 7. Pada saat proses pengerjaan ulang selesai dilakukan, Bagian Produksi akan memasukkan durasi waktu yang sudah digunakan. 8. Sistem akan secara otomatis menghitung biaya kualitas yang ditimbulkan akibat kegiatan pengerjaan ulang yang sudah dilakukan. 9. Use case selesai. 5. Beberapa karyawan Bagian Produksi sudah lama bekerja di PT Decorindo Raya. Mereka sudah menghafal masing-masing nama mesin beserta kodenya dan tidak perlu lagi melihat database mesin. - Sebuah kode rework harus memiliki sebuah kode cacat - Kode karyawan yang melakukan rework harus diisi, di mana satu kode rework dapat melibatkan lebih dari satu orang karyawan - Penyebab cacat hanya dapat dipilih dari combo box dan terdapat 4 pilihan, yaitu Man, Machine, Method, dan Material - Durasi rework harus diisi dengan satuan jam dan dapat berupa desimal - Biaya kualitas dipengaruhi oleh beberapa faktor yaitu gaji karyawan, biaya listrik, dan biaya bahan baku dan dinyatakan dalam satuan Rupiah


297 Tabel 4.71 Tabel Use Case Analysis Pelaporan Hasil Rework (lanjutan) Use Case Post Condition

Pelaporan Hasil Rework Data-data rework tersimpan dalam database. Data tersebut sewaktu-waktu dapat dilihat kembali oleh General Manager dan Kepala Pabrik, serta dapat dicetak dalam bentuk laporan.


Tabel 4.72 Use Case Analysis Pencetakan Laporan Use Case Brief Description Pre Condition

Pencetakan Laporan Use case ini menjelaskan tentang bagaimana General Manager dan Kepala Pabrik melihat data-data pigura cacat, bahan baku cacat, dan hasil rework kemudian mencetaknya sebagai laporan. - Data-data bahan baku cacat sudah dimasukkan dengan lengkap oleh Supervisor dan disimpan dalam database bahan baku cacat - Data-data pigura cacat sudah dimasukkan dengan lengkap oleh Bagian Pengemasan dan disimpan dalam database pigura cacat - Data-data rework sudah dimasukkan dengan lengkap oleh Bagian Produksi dan disimpan dalam database rework Sumber : Hasil Analisa dan Pembahasan

298 Tabel 4.72 Tabel Use Case Analysis Pencetakan Laporan (lanjutan) Use Case Basic Flow


Pencetakan Laporan 1. General Manager dan Kepala Pabrik masuk ke layar Pencetakan Laporan. 2. Untuk mencetak laporan bahan baku cacat, General Manager dan Kepala Pabrik memasukkan tanggal pengiriman yang dikehendaki. Tanggal yang dimasukkan ada 2, yaitu tanggal awal dan akhir. 3. Sistem akan mencari data-data bahan baku cacat yang tersimpan di database bahan baku cacat kemudian mencetaknya dalam bentuk laporan dengan format yang dikehendaki oleh user. 4. Untuk mencetak laporan pigura cacat, General Manager dan Kepala Pabrik memasukkan tanggal cacat yang dikehendaki. Tanggal yang dimasukkan ada 2, yaitu tanggal awal dan tanggal akhir. 5. Sistem akan mencari data-data pigura cacat yang tersimpan di database pigura cacat kemudian mencetaknya dalam bentuk laporan dengan format yang dikehendaki oleh user. 6. Untuk mencetak laporan rework, General Manager dan Kepala Pabrik memasukkan tanggal rework yang dikehendaki. Tanggal yang dimasukkan ada 2, yaitu tanggal awal dan tanggal akhir. 7. Sistem akan mencari data-data rework yang tersimpan di database rework dalam jangka waktu yang dikehendaki, kemudian mencetaknya dalam bentuk laporan dengan format yang dikehendaki oleh user. Selain itu sistem juga akan secara otomatis menghitung dan menampilkan total biaya kualitas selama jangka waktu tersebut. 8. Use case selesai. 2. Selain berdasarkan tanggal pengiriman, General Manager dan Kepala Pabrik juga dapat mencari data-data bahan baku cacat berdasarkan kode bahan baku. - Tanggal awal dan tanggal akhir harus diisi - Data-data laporan harus dapat disajikan dalam bentuk grafik, yaitu run chart, control chart, dan pareto diagram Data-data laporan tercetak. Data tersebut masih tersebut masih tersimpan di dalam database dan sewaktu-waktu dapat dicetak ulang.


Use Case Diagram menggambarkan struktur aktor-aktor yang terlibat di dalam sistem informasi beserta proses bisnisnya. Masing-masing proses bisnis terdiri dari langkah-langkah yang dilakukan dengan berurutan, di mana langkah-langkah dari setiap proses bisnis dapat digambarkan melalui sequence diagram. Masing-masing proses

299 bisnis tersebut dapat dibagi lagi menjadi fungsi-fungsi yang lebih kecil, di mana tiap fungsi memiliki tingkat kompleksitas yang berbeda-beda dan digambarkan melalui function list. Oleh karena itu masing-masing sequence diagram juga memiliki function list yang berbeda-beda. Berikut adalah sequence diagram dan function list dari masingmasing use case yang terdapat pada gambar 4.49.

Gambar 4.50 Sequence Diagram Login Tabel 4.73 Function List Login Functions entryKodeKaryawan entryPassword

Complexity Simple Simple


Type Read Read

300

Gambar 4.51 Sequence Diagram Pengelolaan Password Tabel 4.74 Function List Pengelolaan Password Functions entryKodeKaryawan entryPassword entryNewPassword

Complexity Simple Simple Simple


Type Read Read Update

301

UI : Pengelolaan Data

Konsumen

Supplier

General Manager open() searchKodeKonsumen()

getKodeKonsumen()

deleteDataKonsumen()

update()

UI : Setup Konsumen

open()

setupDataKonsumen()

update()

addDataKonsumen()

close()

X searchKodeSupplier()

getKodeSupplier()

deleteDataSupplier()

update()

UI : Setup Supplier

open()

setupDataSupplier()

update()

addDataKonsumen()

close()

close()

X X

Gambar 4.52 Sequence Diagram Pengelolaan Data Konsumen dan Supplier

302 Tabel 4.75 Function List Pengelolaan Data Konsumen dan Supplier Functions searchKodeKonsumen deleteDataKonsumen addDataKonsumen searchKodeSupplier deleteDataSupplier addDataSupplier

Complexity Simple Simple Simple Simple Simple Simple


Type Read Update Update Read Update Update

303

Gambar 4.53 Sequence Diagram Pengelolaan Data Pigura, Bahan Baku, dan Mesin

304 Tabel 4.76 Function List Pengelolaan Data Pigura, Bahan Baku, dan Mesin Functions searchKodePigura deleteDataPigura addDataPigura searchKodeBahanBaku deleteDataBahanbaku addDataBahanBaku searchKodeMesin deleteDataMesin addDataMesin

Complexity Simple Simple Simple Simple Simple Simple Simple Simple Simple


Type Read Update Update Read Update Update Read Update Update

305

UI : Penerimaan Pesanan

Pesanan

Konsumen

General Manager open() searchKodePesanan()

getKodePesanan()

deleteDataPesanan()

update()

UI : Setup Pesanan

setupDataPesanan()

open()

searchKodeKonsumen()

getKodeKonsumen()

searchKodePigura()

getKodePigura()

addDataPesanan()

update()

close()

close()

X X Gambar 4.54 Sequence Diagram Penerimaan Pesanan

Pigura

306 Tabel 4.77 Function List Penerimaan Pesanan Functions searchKodeKonsumen searchKodePigura updateDataPesanan

Complexity Simple Medium Simple



UI : Pelaporan Bahan Baku Cacat

Bahan Baku

Bahan Baku Cacat

Supervisor open() searchKodeBahanBaku()

getKodeBahanBaku()

UI : Setup Bahan Baku Cacat

open()

setupDataBahanBakuCacat()

update()

addDataBahanBakuCacat()

close()

X

close()

X Gambar 4.55 Sequence Diagram Pelaporan Bahan Baku Cacat Tabel 4.78 Function List Pelaporan Bahan Baku Cacat Functions searchKodeBahanBaku addDataBahanBakuCacat

Complexity Simple Simple


Type Read Update

307

UI : Pembuatan Jadwal Produksi

Jadwal Produksi

Pigura

Kepala Pabrik open() getKodePigura()

searchKodePigura()

getKodeProduksi()

searchKodeProduksi()

UI : Setup Jadwal Produksi

setupDataJadwalProduksi()

open()

addDataJadwalProduksi()

update()

close()

close()

X X

Gambar 4.56 Sequence Diagram Pembuatan Jadwal Produksi Tabel 4.79 Function List Pembuatan Jadwal Produksi Functions searchKodePigura searchKodeProduksi addDataJadwalProduksi

Complexity Simple Simple Simple



308

UI : Pembuatan Instruksi Produksi

Instruksi Produksi

Jadwal Produksi

Kepala Pabrik open() getKodeProduksi()

searchKodeProduksi()

getKodeInstruksi()

searchKodeInstruksi()

UI : Setup Instruksi Produksi

setupDataInstruksiProduksi()

open()

searchKodeMesin()

getKodeMesin()

addDataInstruksiProduksi()

update()

close()

close()

X X

Gambar 4.57 Sequence Diagram Pembuatan Instruksi Produksi Tabel 4.80 Function List Pembuatan Instruksi Produksi Functions searchKodeProduksi searchKodeInstruksi searchKodeMesin addDataInstruksiProduksi

Complexity Simple Simple Simple Simple


Type Read Read Read Update

Mesin

309

UI : Pelaporan Produk Cacat

Pigura Cacat

Pigura

Bagian Pengemasan open() getKodePiguraCacat()

searchKodePiguraCacat()

UI : Pigura

open()

viewDataPigura()

getKodePigura()

searchKodePigura()

close() UI : Instruksi Produksi

X open()

viewDataInstruksi()

getKodeInstruksi()

searchKodeInstruksi()

close()

UI : Setup Pigura Cacat

X

open()

setupDataPiguraCacat()

update()

addDataPiguraCacat()

close()

close()

X X

Gambar 4.58 Sequence Diagram Pelaporan Produk Cacat

Instruksi Produksi

310 Tabel 4.81 Function List Pelaporan Produk Cacat Functions searchKodePiguraCacat searchKodePigura searchKodeInstruksi addDataPiguraCacat

Complexity Simple Simple Simple Simple

Type Read Read Read Update


Gambar 4.59 Sequence Diagram Pelaporan Hasil Rework

311 Tabel 4.82 Function List Pelaporan Hasil Rework Functions searchKodeCacat searchKodeRework searchKodeMesin addDataRework countBiayaKualitas

Complexity Simple Simple Simple Simple Complex

Type Read Read Read Update Compute


Seperti terlihat dalam tabel 4.82, use case Pelaporan Hasil Rework mengandung sebuah fungsi yang bersifat kompleks, yaitu countBiayaKualitas. Oleh karena itu fungsi tersebut harus dijabarkan lagi menggunakan operation specification sebagai berikut :

312 Tabel 4.83 Operation Specification Fungsi countBiayaKualitas Name Category

Purpose Input data Condition Effect

Algorithm

Data Structure

countBiayaKualitas - read - Active - update x Passive x compute - signal Menghitung jumlah biaya kualitas yang ditimbulkan akibat suatu proses pengerjaan ulang terhadap pigura yang cacat. kode_mesin, durasi_rework, biaya_listrik_per_jam, gaji_per_jam, kode_bahan_baku, harga_bahan_baku, bahan_baku_per_jam kode_rework terisi Hasil perhitungan biaya kualitas ini akan dimasukkan ke dalam database rework sesuai kode_rework yang bersangkutan. Sistem akan menghitung biaya kualitas dengan 3 variabel, yaitu biaya listrik, biaya bahan baku, dan gaji karyawan. Jumlah biaya kualitas didapatkan dengan perhitungan sebagai berikut : Biaya listrik = (biaya_listrik_per_jam1 + biaya_listrik_per_jam2 + ..... ..... + biaya_listrik_per_jamx)*durasi_rework bahan_baku_per_jam1 * harga_bahan_baku 1 + Biaya bahan baku= ( volume _ diterima 1 bahan_baku_per_jam 2 * harga_bahan_baku 2 +..... volume _ diterima 2 bahan_baku_per_jam x * harga_bahan_baku x ....+ ) volume _ diterima x *durasi_rework Gaji karyawan = gaji_per_jam *durasi_rework Biaya kualitas = biaya listrik + biaya bahan baku + gaji karyawan kode_mesin : string durasi_rework : integer biaya_listrik_per_jam : integer gaji_per_jam : integer kode_bahan_baku : string harga_bahan_baku : integer bahan_baku_per_jam : integer Rework Mesin, Bahan Baku, Bagian Produksi

Placement Involved Triggering Pelaporan Produk Cacat Event


313

UI : Pencetakan Laporan

Bahan Baku

Pigura

Bahan Baku Cacat

Pigura Cacat

Jadwal Produksi

Rework

General Manager, Kepala Pabrik open() searchKodeBahanBaku()

getKodeBahanBaku()

searchTanggalPengiriman()

getDataBahanBakuCacat()

plotRunChartBahanBaku() createRunChartBahanBaku() plotPchart() createPChart()

UI : Laporan Bahan Baku Cacat

printDataBahanBakuCacat()

create() close()

X getKodePigura()

searchKodePigura()

searchTanggalCacat()

getDataPiguraCacat()

getJumlahProduksi()

plotRunChartPigura() createRunChartPigura() plotUChart() UI : Laporan Pigura Cacat

createUChart()

printDataPiguraCacat()

create() close()

X searchTanggalRework()

getDataRework()

plotParetoDiagramRework() createParetoDiagramRework() plotRunChartRework() createRunChartRework() plotXBarChart()

UI : Laporan Rework createXBarChart()

create()

printDataRework()

close() close()

X X

Gambar 4.60 Sequence Diagram Pencetakan Laporan

314 Tabel 4.84 Function List Pencetakan Laporan Functions searchKodeBahanBaku searchTanggalPengiriman plotRunChartBahanBaku plotPChart printDataBahanBakuCacat searchKodePigura searchTanggalCacat plotRunChartPigura plotUChart printDataPiguraCacat searchTanggalRework plotParetoDiagramRework plotRunChartRework plotXBarChart printDataRework

Complexity Simple Simple Medium Complex Simple Simple Simple Medium Complex Simple Simple Complex Medium Complex Simple

Type Read Read Compute Compute Read, Signal Read Read Compute Compute Read, Signal Read Compute Compute Compute Read, Signal


Untuk beberapa fungsi yang bersifat kompleks, masing-masing akan dijabarkan ke dalam operation specification sebagai berikut :

315 Tabel 4.85 Operation Specification Fungsi plotPChart Name Category


plotPChart - read - Active - update x Passive x compute - signal Menghitung peta kendali P yang menggambarkan proporsi jumlah bahan baku yang cacat terhadap jumlah bahan baku yang diterima. kode_bahan_baku, volume_diterima, kode_bahan_baku_cacat, jumlah_cacat, kode_supplier, tanggal_pengiriman kode_bahan_baku_cacat terisi Hasil perhitungan peta kendali P ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Bahan Baku Cacat. jumlah cacat CL = volume diterima

UCL

= CL + 3

CL * (1 - CL) volume diterima per hari

LCL

= CL - 3

CL * (1 - CL) volume diterima per hari

P

=

Algorithm

Data Structure

jumlah cacat per hari volume diterima per hari

Selanjutnya nilai P akan dibandingkan dengan nilai UCL dan LCL. Bila ada nilai P yang lebih besar dari UCL atau lebih kecil dari LCL, maka sistem akan memberikan sinyal peringatan kepada user melalui laporan yang dicetak. kode_bahan_baku : string kode_bahan_baku_cacat : string jumlah_cacat : integer kode_supplier : string tanggal_pengiriman : string volume_diterima : integer user interface Laporan Bahan Baku Cacat Bahan Baku, Bahan Baku Cacat

Placement Involved Triggering Pelaporan Bahan Baku Cacat Event


316 Tabel 4.86 Operation Specification Fungsi plotUChart Name Category


Algorithm

Data Structure

plotUChart - read - update - Active x compute x Passive - signal Menghitung peta kendali U yang menggambarkan proporsi jumlah pigura yang cacat terhadap jumlah produksi. kode_produksi, kode_pigura, jumlah_pigura, kode_cacat, tanggal_cacat, kategori_cacat, jumlah_cacat kode_cacat terisi Hasil perhitungan peta kendali U ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Pigura Cacat. jumlah cacat CL = jumlah pigura

UCL

= CL + 3

CL jumlah produksi per hari

LCL

= CL − 3

CL jumlah produksi per hari

U

=

jumlah cacat per hari jumlah produksi per hari

Selanjutnya nilai U akan dibandingkan dengan nilai UCL dan LCL. Bila ada nilai U yang lebih besar dari UCL atau lebih kecil dari LCL, maka sistem akan memberikan sinyal peringatan kepada user melalui laporan yang dicetak. kode_produksi : string kode_pigura : string jumlah_pigura : integer kode_cacat : string tanggal_cacat : date kategori_cacat : string jumlah_cacat : integer user interface Laporan Pigura Cacat Pigura Cacat, Jadwal Produksi

Placement Involved Triggering Pelaporan Pigura Cacat Event


317 Tabel 4.87 Operation Specification Fungsi plotParetoDiagramRework Name Category


Algorithm

plotParetoDiagramRework - read - update - Active x compute x Passive - signal Menghitung persentase jumlah cacat untuk masing-masing penyebab cacat kemudian menggambarkan persentase kumulatif dalam bentuk diagram Pareto. kode_rework, tanggal_rework, penyebab_cacat, jumlah_cacat kode_rework terisi Hasil perhitungan diagram Pareto ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Rework. Data-data jumlah cacat akan dikelompokkan berdasarkan penyebab cacatnya. Kemudian masing-masing kelompok tersebut akan dihitung jumlahnya dan dihitung persentasenya terhadap jumlah cacat total. jumlah cacat per penyebab cacat persentase cacat = jumlah cacat total Masing-masing kelompok cacat tersebut akan diurutkan dari yang persentasenya terbesar hingga terkecil, kemudian dihitung persentase kumulatifnya secara keseluruhan. n

persentase kumulatifn =

∑ persentase cacat t =1

Data Structure

kode_rework : string tanggal_rework : date penyebab_cacat : string jumlah_cacat : integer user interface Laporan Rework Rework, Pigura Cacat

Placement Involved Triggering Pelaporan Hasil Rework Event


t

318 Tabel 4.88 Operation Specification Fungsi plotXBarChart Name Category


Algorithm

Data Structure

plotXBarChart - read - Active - update x Passive x compute - signal Menghitung peta kendali X yang menggambarkan kendali perusahaan terhadap data-data biaya kualitas yang timbul akibat kegiatan pengerjaan ulang. kode_rework, tanggal_rework, biaya_kualitas kode_rework terisi Hasil perhitungan peta kendali X ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Rework. R = biaya kualitas terbesar per hari - biaya kualitas terkecil per hari jumlah R R = jumlah hari jumlah biaya kualitas CL = jumlah hari

UCL

= CL + (0.577 * R )

LCL

= CL − (0.577 * R )

Selanjutnya data biaya kualitas per hari akan dibandingkan dengan nilai UCL dan LCL. Bila ada data biaya kualitas yang lebih besar dari UCL atau lebih kecil dari LCL, maka sistem akan memberikan sinyal peringatan kepada user melalui laporan yang dicetak. kode_rework : string tanggal_rework : date biaya_kualitas : integer user interface Laporan Rework Rework

Placement Involved Triggering Pelaporan Hasil Rework Event


Selanjutnya berdasarkan sequence diagram, interaksi antara user dengan sistem informasi usulan akan digambarkan dalam bentuk sketsa yang disebut navigation

diagram. Karena terdapat 5 jenis user yang terlibat dengan sistem dan masing-masing memiliki event yang berbeda-beda, maka masing-masing user memiliki navigation

diagram yang berbeda-beda.

319

Gambar 4.61 Navigation Diagram untuk General Manager

320

Gambar 4.62 Navigation Diagram untuk Kepala Pabrik

321

Gambar 4.63 Navigation Diagram untuk Supervisor

322

Gambar 4.64 Navigation Diagram untuk Bagian Produksi

323

Gambar 4.65 Navigation Diagram untuk Bagian Pengemasan

4.4.4. Architectural Design

Architectural design bertujuan untuk menggambarkan struktur dari sistem informasi usulan yang akan digunakan di PT Decorindo Raya. Pertama-tama, ditetapkan kriteria yang harus dipenuhi oleh sistem informasi tersebut.

324 Tabel 4.89 Prioritas Kriteria pada Sistem Informasi Pengendalian Kualitas Usulan Criterion Usable Secure Efficient Correct Reliable Maintainable Testable Flexible Comprehensible Reusable Portable Interoperable

Very Important V

Important

Less Important

Irrelevant

Easily Fulfiled

V V V V V V V V V V V


Berikut adalah penjelasan dari masing-masing kriteria tersebut :

-

Usable. Sistem informasi yang akan dibangun harus dapat diimplementasikan dengan cepat dan mudah. Kecepatan dalam implementasi sistem dibutuhkan khususnya dalam mendukung fungsi-fungsi seperti penyampaian pesanan konsumen dari General Manager kepada Kepala Pabrik, pendokumentasian kegiatan pengendalian kualitas di perusahaan, serta penyimpanan data-data perusahaan yang penting lainnya. Sedangkan kemudahan implementasi dibutuhkan mengingat sebagian besar karyawan perusahaan belum terbiasa untuk mengoperasikan komputer.

-

Secure. Seperti sistem yang berjalan di perusahaan-perusahaan lain pada umumnya, keamanan adalah hal yang mutlak. Keamanan yang dimaksudkan di sini mencakup beberapa hal. Di antaranya adalah pembatasan hak akses, di mana hanya orang-orang tertentu yang boleh mengakses data-data perusahaan. Dalam hal ini, General Manager dan Kepala Pabrik adalah orang yang berhak untuk

325 melihat data-data internal perusahaan seperti data konsumen, supplier, dan bahan baku. Sistem yang dibangun harus menunjang pembatasan hak akses tersebut dengan password untuk masing-masing user di mana password tersebut hanya diketahui oleh orang yang bersangkutan dan pihak administrator. Selain itu sistem informasi yang dibangun juga harus aman dari pihak-pihak luar yang tidak berhubungan dengan proses bisnis perusahaan. Hal ini disebabkan karena sistem yang dibangun harus diakses melalui internet sehingga lebih rawan untuk diakses secara ilegal oleh pihak-pihak yang tidak bertanggung jawab.

-

Efficient. Kriteria efisiensi dari sisi ekonomis tidak terlalu penting bagi perusahaan karena tujuan utama dari perusahaan adalah meningkatkan kualitas produk-produk yang dihasilkannya. Hal itu dapat tercapai apabila didukung oleh sistem informasi yang dirancang dengan baik dan dapat berfungsi secara maksimal.

-

Correct. Dalam sistem informasi yang dibangun, terdapat beberapa pengolahan data. Pengolahan data ini harus sesuai dengan kebutuhan dari pihak manajemen perusahaan, khususnya yang berhubungan dengan kegiatan pengendalian kualitas. Informasi-informasi yang dibutuhkan di antaranya perhitungan biaya kualitas, jumlah cacat, dan sebagainya. Informasi-informasi tersebut digunakan oleh pihak manajemen perusahaan sebagai bahan analisa dan pendukung pengambilan keputusan. Karena itu data-data yang diolah dan dicetak harus akurat dan mencerminkan kondisi yang sebenarnya di pabrik.

-

Reliable. Sistem yang dibangun memiliki fungsi-fungsi tertentu yang dapat diakses oleh beberapa karyawan yang bersangkutan. Fungsi-fungsi tersebut dapat berupa melihat, menambah, mengubah, dan menghapus isi database, serta

326 mencetak laporan. Untuk mendukung proses bisnis perusahaan, maka masigmasing fungsi tersebut harus dapat dijalankan dan menghasilkan output yang sesuai dengan hasil rancangan sebelumnya.

-

Maintainable. Agar dapat digunakan dalam jangka panjang, maka sistem informasi yang dibangun harus dapat dimaintain dengan mudah. Terlebih lagi karena sistem tersebut menyimpan data-data perusahaan yang penting dan krusial bagi proses bisnis perusahaan seperti data-data supplier, konsumen, pesanan, dan sebagainya. Kemudahan yang dimaksudkan berarti bahwa sistem dapat diperbaiki dengan cepat dan dengan biaya yang relatif rendah.

-

Testable. Untuk memastikan bahwa sistem informasi yang dibangun dapat berfungsi sebagaimana mestinya dan sesuai dengan kebutuhan perusahaan, maka sistem tersebut harus dapat diuji. Pengujian ini dilakukan sebelum sistem benarbenar diimplementasikan dalam perusahaan sehingga dapat mengantisipasi terjadinya error yang dapat merugikan perusahaan nantinya.

-

Flexible. Berdasarkan situasi dan kondisi bisnis yang dinamis dan berkembang dengan pesat, maka sistem informasi yang dibangun juga harus fleksibel dan dapat beradaptasi terhadap situasi dan kondisi tersebut. Fleksibilitas dari sistem dapat dilihat dari biaya dan waktu yang diperlukan untuk melakukan modifikasi terhadap sistem. Semakin sedikit biaya dan waktu yang diperlukan, semakin tinggi tingkat fleksibilitas dari sistem tersebut.

-

Comprehensible. Selama ini kegiatan pengendalian kualitas yang dilakukan di PT Decorindo Raya dilakukan secara manual. Penggunaan komputer hanya sebatas pencetakan surat jalan, faktur, dan dokumen-dokumen standar lainnya. Hal ini menunjukkan bahwa sebagian besar karyawan yang ada belum terbiasa

327 untuk bekerja dengan bantuan komputer. Karena itu tampilan dari sistem informasi usulan harus dibuat sesederhana mungkin, dan fitur-fitur yang tersedia harus dapat digunakan dengan mudah tanpa membutuhkan training khusus

-

Reusable. Selain pengendalian kualitas, sistem keseluruhan yang berjalan di perusahaan sangat luas dan kompleks. Dengan kata lain sistem informasi yang dibangun hanya merupakan sebagian kecil dari sistem tersebut. Untuk dapat berfungsi secara maksimal, maka sistem informasi tersebut harus dapat diintegrasikan dengan sistem-sistem perusahaan lainnya. Walaupun sementara ini sistem lainnya masih sebagian besar dijalankan secara manual, namun tidak menutup kemungkinan bahwa suatu saat semua sistem di perusahaan akan terkomputerisasi. Karena itu sistem informasi yang dibangun harus dapat mendukung adanya kemungkinan tersebut.

-

Portable. Seperti yang sudah dijelaskan sebelumnya, sistem informasi usulan akan dibangun berbasiskan internet. Berhubungan dengan perkembangan

internet yang sangat pesat, maka sistem informasi yang dibangun harus dapat berjalan dengan baik walaupun digunakan dalam platform yang berbeda-beda. Walaupun demikian, kriteria ini kurang penting karena penggunaan komputer yang masih minimal di perusahaan sehingga kemungkinan terjadinya perpindahan platform sangat kecil.

-

Interoperable. Kriteria ini berfokus pada biaya yang diperlukan untuk mengintegrasikan sistem informasi usulan dengan sistem informasi yang sudah ada di perusahaan. Saat ini penggunaan komputer di PT Decorindo Raya masih sangat minimal. Sebagian besar sistem masih dijalankan secara manual. Dengan kata lain, sistem informasi yang dibangun tidak akan diintegrasikan dengan

328 sistem-sistem lainnya dalam waktu dekat ini. Karena itu kriteria ini dinyatakan tidak berhubungan. Berdasarkan kriteria yang sudah ditentukan untuk sistem informasi usulan, selanjutnya dibuat arsitektur untuk menggambarkan sistem informasi yang dibangun. Arsitektur tersebut dibedakan menjadi 2 bagian, yaitu :

-

Arsitektur komponen Arsitektur komponen bertujuan untuk memudahkan dalam memahami sistem, mengatur pengerjaan desain, dan menggambarkan stabilitas dalam konteks sistem. Arsitektur komponen digambarkan dalam bentuk component diagram. Dalam diagram tersebut, masing-masing komponen dari sistem usulan digambarkan dalam bentuk packages yang saling berhubungan. Tiap packages dapat memiliki dari user interface (UI), function (F), dan system interface (SI). Dari hasil analisa ditentukan bahwa jenis arsitektur yang digunakan pada sistem informasi usulan adalah centralized data. Dalam tipe arsitektur ini masingmasing user hanya memiliki user interface dan function, sedangkan semua

database disimpan dalam server secara terpusat. Alasan pemilihan tipe arsitektur ini adalah proses pembuatannya yang mudah dan cepat diimplementasikan ke dalam sistem perusahaan. Selain itu data-data yang ditampilkan juga lebih konsisten karena hanya disimpan di satu tempat. Akan tetapi jenis arsitektur ini juga memiliki beberapa resiko. Di antaranya adalah koneksi ke database yang lambat apabila ada beberapa user sekaligus yang mengakses database secara bersamaan. Resiko lainnya adalah resiko kehilangan data. Karena hanya disimpan di satu tempat terpusat, maka diperlukan back up secara rutin sebagai cadangan apabila data yang asli rusak atau terhapus.

329 <> Client General Manager

<> Client Kepala Pabrik

User Interface

User Interface

Function

Function

<> Web Server System Interface

System Interface System Interface

<> Client Bagian Produksi

Model

<> Client Supervisor

User Interface

User Interface

Function

Function

System Interface

System Interface

<> Client Bagian Pengemasan

User Interface

Function

System Interface

Gambar 4.66 Component Diagram Sistem Informasi Pengendalian Kualitas Usulan

330

-

Arsitektur proses Setelah membuat arsitektur komponen, selanjutnya perlu dibuat arsitektur proses yang lebih menggambarkan bentuk fisik daripada bentuk logis dari sistem. Arsitektur komponen digambarkan daam bentuk deployment diagram.

Client General Manager

Client Kepala Pabrik User Interface

User Interface

Function

Function

Web Server Active Object

System Interface

System Interface

Active Object

System Interface

Printer General Manager

Printer Kepala Pabrik

Model Client Supervisor

Client Bagian Produksi User Interface

User Interface

Function

Function

System Interface

System Interface

Client Bagian Pengemasan

User Interface

Function

System Interface

Gambar 4.67 Deployment Diagram Sistem Informasi Pengendalian Kualitas Usulan

331 Dengan memperhatikan deployment diagram di atas, terlihat bahwa arsitektur proses memiliki bentuk yang sama dengan arsitektur komponen. Perbedaannya hanyalah pada arsitektur proses, terdapat hubungan antara user dengan processor eksternal. Hubungan ini terjadi dengan bantuan active object (AO) sebagai perantaranya. Dalam sistem usulan, processor eksternal yang berhubungan adalah printer. Sesuai dengan use

case yang dibuat sebelumnya, printer digunakan untuk kegiatan pencetakan laporan. Kegiatan ini hanya dapat dilakukan oleh Kepala Pabrik dan General Manager. Oleh karena itu hanya kedua user tersebut yang memiliki hubungan terdahadap printer melalui active object sebagai perantara.

4.4.5. Component Design

Setelah arsitektur dari sistem informasi usulan dibuat, perancangan sistm dilanjutkan pada tahap component design. Kegiatan perancangan komponen ini dilakukan melalui 2 tahap :

-

perancangan model component

Model component menggambarkan problem domain dalam class, objek, dan sruktur serta perilaku mereka berdasarkan konsep pemrograman berorientasi objek. Hasil akhir dari aktivitas ini adalah sebuah class diagram yang sudah direvisi.

332

Gambar 4.68 Revised Class Diagram Sistem Informasi Pengendalian Kualitas Usulan

333

Revised class diagram merupakan hasil perubahan dari class diagram sebelumnya. Perubahan yang terjadi hanya sebatas penambahan detil class pesanan, mesin, instruksi produksi, dan rework. Hubungan antara class dengan detilnya dinyatakan dalam hubungan agregasi. Sebagai akibat dari penambahan detil class tersebut, beberapa atribut yang dimiliki class induknya akan dipindahkan ke class turunannya. Selain itu class-class karyawan juga dihilangkan karena class-class tersebut bukan merupakan bagian dari sistem informasi usulan, melainkan objek yang mengakses dan mengoperasikan sistem tersebut. Sehingga lebih tepat apabila class-class karyawan ditempatkan sebagai

actor di dalam application domain. -

perancangan function component

Function component dirancang dengan cara merancang fungsi sebagai operasi berdasarkan jenisnya. Dari kegiatan ini dihasilkan operasi-operasi yang dapat mengimplementasikan fungsionalitas sistem informasi usulan.

334

Gambar 4.69 Function Class Placement Sistem Informasi Pengendalian Kualitas Usulan

335

Function component di atas dirancang berdasarkan function class placement karena terdapat beberapa operasi yang sifatnya umum namun melibatkan oleh dua class atau lebih. Operasi-operasi tersebut di antaranya pencetakan laporan dan pengelolaan data. Pencetakan laporan dapat dilakukan terhadap class bahan baku cacat, pigura cacat, dan rework. Sedangkan operasi pengelolaan data dapat dilakukan terhadap class konsumen, supplier, pigura, bahan baku, dan mesin. Kelima class tersebut sama-sama dikelola, akan tetapi actor yang melakukannya berbeda. Class konsumen dan supplier dikelola oleh General Manager, sedangkan class pigura, bahan baku, dan mesin dikelola oleh Kepala Pabrik. Walaupun berbeda actornya namun tiap-tiap pengelolaan data tersebut memiliki fungsi-fungsi yang sama.

4.5.

Pengembangan Aplikasi Sistem

Pada tahap perancangan sistem informasi, dilakukan analisa terhadap permasalahan-permasalahan yang terjadi di PT Decorindo Raya khususnya yang berhubungan dengan kegiatan pengendalian kualitas. Dari berbagai masalah tersebut, selanjutnya diusulkan suatu sistem informasi yang dapat membantu meningkatkan kinerja dari perusahaan. Sistem informasi diusulkan berfungsi sebagai media komunikasi antara pihak kantor dengan pihak pabrik PT Decorindo Raya khususnya dalam pengendalian kualitas. Selain itu sistem informasi tersebut juga memfasilitasi kegiatan dokumentasi terhadap jenis-jenis cacat dan kegiatan rework yang ditimbulkan, sehingga dapat dilihat ulang untuk tujuan analisa. Pada subbab sebelumnya, dijelaskan rancangan dari sistem informasi usulan dengan menggunakan diagram UML. Selanjutnya dilakukan pengembangan aplikasi sistem untuk mengubah hasil rancangan menjadi sebuah sistem informasi yang nyata

336 dan benar-benar dapat digunakan di perusahaan. Karena akan dijalankan berbasis web, pengembangan aplikasi sistem ini dilakukan dengan ASP.NET. Berikut adalah tampilantampilan layar dari sistem informasi yang dibuat beserta penjelasannya.

Gambar 4.70 Window Login Merupakan layar yang pertama kali muncul pada saat sistem informasi dijalankan. Pada layar ini, user harus memasukkan user name dan password mereka masing-masing, kemudian mengklik tombol enter untuk masuk ke dalam sistem. Untuk alasan keamanan, setiap user hanya boleh salah memasukkan password sebanyak maksimal 3 kali. Apabila lebih dari 3 kali, maka sistem akan memblock hak akses user itu untuk sementara dan tidak dapat digunakan sebelum diaktifkan kembali oleh

administrator.

337

Gambar 4.71 Window Menu Utama Merupakan layar utama yang tampil setelah user berhasil melakukan login. Pada menu di sebelah kanan atas, terdapat 3 pilihan yaitu welcome untuk kembali ke menu utama, change password untuk merubah password user, dan logout untuk keluar dari sistem. Sedangkan di sebelah kiri terdapat kategori-kategori fitur yang dapat digunakan oleh user, di antaranya security untuk mengatur privilege dan user, data processing untuk pengelolaan data-data perusahaan, dan report untuk menghasilkan laporan bagi

General Manager dan Kepala Pabrik. Di bagian bawah terdapat ruang kosong yang digunakan untuk menampilkan signal-signal yang berhubungan dengan tanggal login dan harus diperhatikan oleh user yang bersangkutan. Sinyal tersebut dapat berupa pesanan, jadwal produksi, atau pigura cacat yang baru diinput ke sistem pada hari itu.

338

Gambar 4.72 Window Pengelolaan Password Merupakan layar yang digunakan user untuk mengubah passwordnya masingmasing. Apabila user tidak jadi mengubah passwordnya, dapat menekan tombol cancel. Untuk alasan keamanan, maka password masing-masing user hanya diketahui oleh mereka sendiri dan dienkripsi sebelum disimpan ke database.

339

Gambar 4.73 Window Pengelolaan Privilege Layar ini digunakan untuk mengatur privilege yang digunakan dalam sistem informasi usulan. Privilege merupakan pembatasan hak akses user terhadap sistem sesuai dengan pembagian tugasnya masing-masing. Masing-masing privilege memiliki nama dan deskripsinya masing-masing. Layar ini bersifat rahasia dan hanya dapat diakses oleh administrator.

340

Gambar 4.74 Window Setup Privilege Merupakan kelanjutan dari layar pengelolaan privilege, di mana pada layar ini

administrator dapat memasukkan jenis-jenis privilege baru dan mengatur pembatasan hak aksesnya masing-masing. Untuk melakukannya, administrator tinggal mengaktifkan

checkbox yang terdapat di kolom sebelah kanan.

341

Gambar 4.75 Window Pengelolaan User Layar ini digunakan untuk mengelola user-user mana saja yang dapat mengakses sistem beserta jenis privilegenya masing-masing. Seperti yang terlihat pada gambar di atas, masing-masing user juga memiliki status. Apabila statusnya aktif, maka mereka masih dapat mengakses sistem dan menggunakan fitur-fitur yang ada. Sedangkan apabila statusnya tidak aktif, maka hak aksesnya sudah diblock dan untuk sementara tidak dapat mengakses sistem.

342

Gambar 4.76 Window Setup User Merupakan kelanjutan dari layar pengelolaan user, di mana administrator dapat menambahkan user baru dan menentukan jenis privilegenya masing-masing. Pada saat suatu user baru dibuat, password awal akan ditentukan oleh administrator. Setelah itu

user dapat mengubah passwordnya masing-masing.

343

Gambar 4.77 Window Pengelolaan Karyawan Layar ini digunakan untuk melihat data-data karyawan yang bekerja di PT Decorindo Raya. Masing-masing karyawan dibedakan jabatannya berdasarkan jenis

privilegenya masing-masing. Pada gambar di atas terlihat bahwa masing-masing karyawan memiliki salary per jam yang dinyatakan dalam satuan Rupiah.

344

Gambar 4.78 Window Setup Karyawan Merupakan kelanjutan dari layar pengelolaan karyawan, di mana administrator dapat menambahkan data-data karyawan baru. Setelah selesai mengisi data, tombol add ditekan dan data-data tersebut akan tersimpan di dalam database.

345

Gambar 4.79 Window Pengelolaan Data Merupakan layar yang digunakan untuk mengelola data-data perusahaan. Datadata tersebebut mencakup data konsumen, supplier, bahan baku, pigura, dan mesin. Sesuai dengan pembagian tugas, maka General Manager dapat mengelola data konsumen dan supplier. Sedangkan Kepala Pabrik dapat mengelola data bahan baku, pigura, dan mesin.

346

Gambar 4.80 Window Setup Data Merupakan kelanjutan dari layar pengelolaan data, di mana user dapat menambahkan data-data baru. Setelah semua terisi, tombol add ditekan dan data-data tersebut tersimpan ke dalam database.

347

Gambar 4.81 Window View Data Pada gambar 4.79 terlihat bahwa di sebelah kanan masing-masing item data terdapat 3 tombol. Yang paling kiri berbentuk kaca pembesar dan bila ditekan akan menampilkan layar view data. Layar ini hanya berfungsi untuk menampilkan data secara lengkap. Pada layar ini user tidak dapat melakukan update ataupung menghapus isi data, karena itu semua field yang tersedia bersifat tidak aktif.

348

Gambar 4.82 Window Update Data Selain tombol view, di sebelah kanan dari masing-masing item data juga terdapat tombol yang berbentuk pensil. Apabila tombol tersebut ditekan, maka layar update data akan muncul. Pada layar ini semua field bersifat aktif dan semua data dapat diubah-ubah oleh user, kecuali kode data itu sendiri. Kode data merupakan primary key sehingga tidak dapat diubah-ubah lagi, kecuali dihapus secara keseluruhan.

349

Gambar 4.83 Window Pengelolaan Bahan Baku Cacat Layar ini digunakan melihat data-data bahan baku yang cacat. Pada saat pertama kali layar ini ditampilkan, sistem akan langsung menampilkan semua data-data bahan baku yang cacat. Kemudian user dapat menggunakan fasilitas search untuk mencari data-data bahan baku yang ingin dicari berdasarkan kode bahan baku atau nama bahan baku.

350

Gambar 4.84 Window Setup Bahan Baku Cacat Merupakan kelanjutan dari layar pengelolaan bahan baku cacat. Layar ini digunakan oleh Supervisor untuk memasukkan data-data bahan baku cacat yang baru. Tanggal cacat akan secara otomatis terisi pada tanggal hari itu, tapi user dapat menyesuaikannya dengan data sebenarnya. Pada saat tombol add ditekan, maka datadata tersebut akan tersimpan di database.

351

Gambar 4.85 Window Pengelolaan Pigura Cacat Layar ini berfungsi untuk menampilkan data-data pigura cacat yang ada di

database. Sama seperti pada pengelolaan bahan baku cacat, layar ini juga dilengkapi dengan fitur search untuk mencari data-data yang dibutuhkan. Pencarian data pigura cacat dapat dilakukan berdasarkan kode cacat, kode produksi, atau kode karyawan.

352

Gambar 4.86 Window Setup Pigura Cacat Merupakan kelanjutan dari layar pengelolaan pigura cacat. Layar ini digunakan oleh karyawan Bagian Pengemasan untuk memasukkan data-data pigura yang cacat. Tanggal cacat akan secara otomatis terisi pada tanggal hari itu, tapi user dapat menyesuaikannya dengan data sebenarnya. Pada saat tombol add ditekan, maka datadata tersebut akan tersimpan di database.

353

Gambar 4.87 Window Pengelolaan Rework Layar ini menampilkan data-data kegiatan rework yang sudah dilakukan selama ini. Layar ini juga dilengkapi dengan fitur search untuk mencari data-data yang dibutuhkan. Pencarian data rework dapat dilakukan berdasarkan tanggal rework atau kode cacat.

354

Gambar 4.88 Window Setup Rework Merupakan kelanjutan dari layar pengelolaan rework. Layar ini digunakan oleh karyawan Bagian Produksi untuk melaporkan data-data rework untuk setiap pigura yang cacat. Tanggal rework akan secara otomatis terisi pada tanggal hari itu, tapi user dapat menyesuaikannya dengan data sebenarnya. Satu kegiatan rework dapat menggunakan berbagai jenis mesin dengan durasi yang berbeda-beda oleh karyawan yang berbedabeda juga. Karena itu layar ini dilengkapi dengan list yang menampilkan detil dari masing-masing mesin, durasi, dan karyawan yang bersangkutan dengan rework tersebut.

List ini dapat ditambah ataupun dihapus sebelum disimpan ke dalam database.

355

Gambar 4.89 Window Pengelolaan Pesanan Layar ini digunakan untuk melihat data-data pesanan konsumen yang masuk ke Pt Decorindo Raya. Layar ini memiliki fitur search untuk mencari data-data yang dibutuhkan. Pencarian data pesanan dapat dilakukan berdasarkan kode pesanan, kode konsumen, atau tanggal pesanan.

356

Gambar 4.90 Window Setup Pesanan Merupakan kelanjutan dari layar pengelolaan pesanan. Layar ini digunakan oleh

General Manager untuk memasukkan data-data pesanan baru. Dalam satu pesanan bisa terdapat lebih dari satu jenis pigura dengan jumlah yang berbeda-beda. Karena itu layar ini juga dilengkapi dengan list untuk menampung item-item pesanan tersebut. Isi dari list tersebut dapat ditambah atau dihapus sebelum disimpan ke dalam database.

357

Gambar 4.91 Window Pengelolaan Jadwal Produksi Layar ini digunakan untuk melihat jadwal-jadwal produksi yang selama ini sudah dilakukan di PT Decorindo Raya. Untuk memudahkan dalam melihat data, layar ini juga dilengkapi dengan fitur search di mana user dapat mencari data-data jadwal produksi berdasarkan kode produksi, tanggal produksi, atau kode pigura.

358

Gambar 4.92 Window Setup Jadwal Produksi Merupakan kelanjutan dari layar pengelolaan jadwal produksi. Layar ini digunakan oleh Kepala Pabrik untuk memasukkan data-data jadwal produksi yang baru. Karena produksi langsung dilakukan dalam jumlah banyak, maka satu jadwal produksi hanya dibuat untuk satu kode pigura.

359

Gambar 4.93 Window Pengelolaan Instruksi Produksi Layar ini digunakan untuk melihat data-data instruksi produksi yang sudah dibuat untuk masing-masing jadwal produksi. Untuk memudahkan pencarian data, layar ini dilengkapi dengan fitur search untuk mencari data-data instruksi produksi berdasarkan kode instruksi atau kode produksi.

360

Gambar 4.94 Window Setup Instruksi Produksi Layar ini merupakan kelanjutan dari layar pengelolaan instruksi produksi. Layar ini digunakan oleh Kepala Pabrik untuk memasukkan data-data instruksi produksi yang baru. Masing-masing instruksi produksi dibuat berdasarkan jadwal produksi yang sudah ada. Dalam suatu kegiatan produksi, digunakan berbagai mesin dengan setting dan nilai target yang berbeda-beda. Karena itu layar ini juga dilengkapi dengan list untuk menampung jenis-jenis mesin yang digunakan beserta setting dan nilai targetnya. Isi dari

list ini dapat ditambah atau dihapus sebelum disimpan ke database.

361

Gambar 4.95 Window View Laporan Layar ini dapat digunakan oleh General Manager dan Kepala Pabrik. Tujuannya adalah melihat laporan dari kinerja perusahaan selama ini, khususnya yang berhubungan dengan cacat yang terjadi selama proses produksi. Karena itu laporan dibedakan menjadi 3 jenis, yaitu laporan bahan baku cacat, laporan pigura cacat, dan laporan rework. Masing-masing dapat laporan dicari berdasarkan tanggal terjadinya cacat, kemudian ditampilkan dalam bentuk grafik untuk mempermudah dalam analisa data-data tersebut. Grafik yang dapat disajikan di antaranya run chart dan control chart. Sedangkan untuk laporan rework dilengkapi dengan pareto diagram untuk melihat persentase biaya kualitas berdasarkan penyebab cacat yaitu Man, Machine, Method, dan Material.

362

Gambar 4.96 Window Print Laporan Layar merupakan kelanjutan dari layar view laporan. Layar ini muncul pada saat tombol export diklik, dan langsung menampilkan laporan yang sedang aktif dalam bentuk tabel. Laporan ini disajikan dengan bantuan Microsoft Excel, dan dapat disesuaikan oleh user sebelum dicetak. Selain merancang layar user interface, pada tahap ini juga dilakukan perancangan terhadap database yang digunakan untuk mendukung penyimpanan dan pengolahan data-data dan informasi dari sistem informasi yang dibuat. Database tersebut dibuat menggunakan software Microsoft Access. Berikut adalah hasil perancangan database.

363 Tabel 4.90 Hasil Perancangan Database Sistem Informasi Usulan Nama Tabel

tblCustomer tblDefectCategory tblDefectMaterial tblDefectPigura tblDefectType tblEmployee tblFunction tblGroupFunction tblInstruction tblInstructionDetail tblMachine tblMachineDetail tblMaterial tblMenu tblOrder tblOrderDetail tblPigura tblPiguraCategory tblPrivilege tblPrivilegeDetail tblProduction

Atribut customer_ID, customer_name, customer_address, customer_tlp, create_date, create_by, modify_date, modify_by defectcategory_ID, defectcategory_name dmaterial_ID, material_ID, dmaterial_date, dmaterial_value, dmaterial_volume_receive, dmaterial_description, create_date, create_by, modify_date, modify_by dpigura_ID, production_ID, dpigura_date, defectcategory_ID, employee_ID, dpigura_amount, create_date, create_by, modify_date, modify_by defecttype_ID, defecttype_name employee_ID, employee_name, employee_address, employee_phone, employee_salary, create_date, create_by, modify_date, modify_by function_ID, group_function_ID, function_name group_function_ID, group_function_name production_ID, instruction_ID, instruction_target_amount, create_date, create_by, modify_date, modify_by instruction_ID, detail_ID, machine_ID, detail_target_amount, detail_settings machine_ID, machine_name, machine_power_cost, create_date, create_by, modify_date, modify_by detailmachine_ID, machine_ID, material_ID, detailmachine_material_cost material_ID, material_name, material_receive_date, supplier_ID, material_price, material_volume, create_date, create_by, modify_date, modify_by menu_ID, menu_name, menu_parent, menu_link, menu_flag_islink, function_ID order_ID, order_date, customer_id, order_description, create_date, create_by, modify_date, modify_by order_ID, pigura_ID, order_amount, order_description pigura_ID, pigura_category_ID, pigura_type, pigura_color, pigura_profile_type, pigura_price, create_date, create_by, modify_date, modify_by pigura_category_ID, pigura_category_name privilege_ID, privilege_name, privilege_description, create_date, create_by, modify_date, modify_by privilege_ID, function_ID production_ID, production_date, pigura_ID, production_amount, create_date, create_by, modify_date, modify_by


364 Tabel 4.90 Tabel Hasil Perancangan Database Sistem Informasi Usulan (lanjutan) Nama Tabel

tblRework tblReworkDetail tblSupplier tblUser

Atribut rework_ID, rework_date, defecttype_ID, dpigura_ID, rework_description, rework_quality_cost, create_date, create_by, modify_date, modify_by reworkdetail_ID, rework_ID, machine_ID, reworkdetail_value, reworkdetail_duration, employee_ID supplier_ID, supplier_name, supplier_address, supplier_tlp, create_date, create_by, modify_date, modify_by user_name, user_password, user_last_login, user_counter, user_status, privilege_ID, create_date, create_by, modify_date, modify_by


Tabel di atas menunjukkan jenis-jenis field yang terdapat pada database sistem informasi usulan. Masing-masing field memiliki primary key yang dilambangkan dengan tulisan yang dicetak tebal, dan foreign key yang dilambangkan dengan tulisan yang dicetak miring. Berikut adalah penjelasan dari masing-masing field tersebut.

-

tblCustomer. Menyimpan data-data konsumen seperti nama, alamat, dan nomor telepon yang diinput oleh General Manager.

-

tblDefectCategory. Menyimpan data-data kategori cacat yang dibedakan menjadi 2 bagian, yaitu reusable dan nonreusable. Pigura-pigura yang tergolong reusable akan digunakan juga dalam tblRework.

-

tblDefectMaterial. Menyimpan data-data bahan baku yang cacat seperti tanggal, jumlah cacat, dan jumlah material tersebut yang diterima secara keseluruhan dari

supplier pada tanggal pengiriman yang sama. Data-data ini diinput oleh supervisor. -

tblDefectPigura. Menyimpan data-data pigura yang cacat kode produksi, tanggal, kategori cacat, kode karyawan yang menginput, dan jumlah cacatnya. Data-data

365 ini diinput oleh karyawan Bagian Pengemasan pada saat mengetahui adanya pigura yang cacat sebelum dikemas.

-

tblDefectType. Menyimpan data-data jenis cacat pada pigura. Sesuai dengan

fishbone diagram yang sudah dibuat, jenis-jenis cacat ini dibedakan menjadi 4, yaitu Man, Machine, Method, dan Material.

-

tblEmployee. Menyimpan data-data karyawan seperti nama, alamat, nomor telepon, dan gaji per jam nya.

-

tblFunction. Menyimpan data berupa fungsi-fungsi yang dapat digunakan oleh

user selama berinteraksi dengan sistem. Fungsi-fungsi ini mencakup view, update, delete, dan sebagainya. -

tblGroupFunction. Merupakan pengelompokan dari fungsi-fungsi yang ada. Secara umum, fungsi-fungsi tersebut dapat dikelompokkan menjadi 3 jenis yaitu

security untuk pengelolaan password, data processing untuk manajemen data, dan report untuk mencetak laporan.

-

tblInstruction. Menyimpan data-data instruksi produksi yang dibuat berdasarkan masing-masing kode produksi.

-

tblInstructionDetail. Merupakan penjabaran dari tblInstruction, di mana satu instruksi bisa terdiri dari beberapa mesin beserta nilai setting dan nilai targetnya masing-masing.

-

tblMachine. Menyimpan data-data mesin seperti nama dan biaya listrik yang diinput oleh Kepala Pabrik.

-

tblMachineDetail. Merupakan penjabaran dari masing-masing mesin di mana tiap mesin mengunakan bahan baku dengan jenis dan jumlah yang berbeda-beda.

366

-

tblMaterial. Menyimpan data-data bahan baku seperti nama, supplier, tanggal penerimaan, harga, dan volume per kemasannya yang diinput oleh Kepala Pabrik.

-

tblMenu. Menyimpan pilihan menu yang ditampilkan pada user interface. Masing-masing menu mewakili fungsi yang berbeda. Menu-menu tersebut dapat dikelompokkan ke dalam menu utama melalui atribut menu_parent. Selain itu menu-menu tersebut juga dapat diatur apakah memiliki link ke menu lain atau tidak melalui atribut menu_flag_islink.

-

tblOrder. Menyimpan data-data pesanan konsumen yang diterima oleh General

Manager. Data-data pesanan tersebut mencakup tanggal pemesanan, konsumen yang memesan, dan deskripsi dari pesanan.

-

tblOrderDetail. Merupakan penjabaran dari masing-masing pesanan konsumen di mana sebuah pesanan bisa terdiri dari beberapa pigura dengan jumlah dan spesifikasi yang berbeda-beda.

-

tblPigura. Menyimpan data-data pigura seperti jenis, warna, tipe profil, dan harga yang diinput oleh Kepala Pabrik.

-

tblPiguraCategory. Menyimpan data-data kategori pigura yang diproduksi di PT Decorindo Raya. Secara umum, kategori pigura dapat dibedakan menjadi 2 bagian, yaitu pigura standar dan pigura batangan.

-

tblPrivilege. Menyimpan data-data jenis user yang dapat mengakses sistem. Data-data tersebut mencakup nama dan deskripsi masing-masing jenis user.

-

tblPrivilegeDetail. Merupakan penjabaran dari data-data privilege, di mana masing-masing privilege dapat mengakses fungsi-fungsi yang berbeda-beda.

-

tblProduction. Menyimpan data-data jadwal produksi yang diinput oleh Kepala Pabrik. data-data tersebut meliputi tanggal produksi, jenis pigura yang harus

367 diproduksi, dan jumlahnya. Karena diproduksi dalam jumlah yang banyak sekaligus, maka satu jadwal produksi hanya dibuat untuk satu jenis pigura.

-

tblRework. Menyimpan data-data rework yang diinput oleh karyawan Bagian Produksi. Data-data tersebut mencakup tanggal, jenis cacat, kode pigura yang cacat, dan biaya kualitas yang didapat dari hasil perhitungan otomatis oleh sistem.

-

tblReworkDetail. Merupakan penjabaran dari masing-masing rework, di mana kegiatan rework untuk sebuah pigura melibatkan serangkaian proses yang dilakukan oleh beberapa karyawan dengan mesin-mesin dan durasi yang berbeda.

-

tblSupplier. Menyimpan data-data supplier seperti nama, alamat, dan nomor telepon yang diinput oleh General Manager.

-

tblUser. Menyimpan data-data mengenai user yang dapat mengakses sistem tersebut. Masing-masing user memiliki user name dan passwordnya masingmasing. User juga dapat berinteraksi dengan sistem melalui fungsi-fungsi yang ditetapkan berdasarkan privilege yang dimiliki oleh user tersebut. Untuk alasan keamanan, maka pada saat login user hanya diberikan kesempatan untuk salah mengisi password sebanyak maksimal 3 kali. Jumlah kesalahan password ini ditampung dalam atribut user_counter. Apabila lebih dari 3 kali, maka user tersebut akan diblock dan tidak dapat mengakses sistem sebelum menghubungi pihak administrator. Status aktif atau tidaknya seorang user ditetapkan dalam user_status. User yang masih aktif akan memiliki nilai user_status 1. Sedangkan

user yang sudah tidak aktif atau diblock aksesnya akan memiliki nilai user_status 0.

368 4.6.

Usulan Penerapan Sistem Informasi

Setelah merancang aplikasi untuk sistem informasi usulan, selanjutnya ditetapkan usulan untuk menerapkan aplikasi tersebut di PT Decorindo Raya. Usulan tersebut mencakup peralatan-peralatan yang dibutuhkan untuk mendukung sistem tersebut maupun rencana implementasinya.

4.6.1.Technical Platform

Technical platform mencakup hal-hal yang dibutuhkan untuk mengoperasikan sistem informasi usulan dari sisi teknis. Kebutuhan tersebut mencakup hardware,

software, dan bahasa perancangan.

4.6.1.1.Software

Karena sistem informasi usulan akan dijalankan berbasiskan web, maka digunakan ASP.NET 2.0 yang disediakan oleh Microsoft Visual Studio 2005. Sedangkan bahasa pemrograman yang digunakan adalah Visual Basic. Selain sudah mendukung konsep pemrograman yang berorientasi objek, ASP.NET juga bersifat lebih dinamis sehingga memudahkan untuk pengembangan atau modifikasi sistem di masa yang akan datang. Untuk menjalankan fungsi-fungsi yang terdapat pada ASP.NET, komputer juga membutuhkan dukungan .NET Framework 2.0. Kebutuhan penyimpanan data didukung oleh Microsoft Access, sedangkan pencetakan laporan dilakukan dengan bantuan Microsoft Excel. Keduanya merupakan bagian dari Microsoft Office System 2003. Untuk menjalankan ketiga software tersebut, digunakan sistem operasi yaitu Microsoft Windows XP SP1.

369 4.6.1.2.Hardware

Untuk menjalankan software dengan baik, dibutuhkan personel computer dengan rekomendasi spesifikasi minimum processor Intel® Celeron® 2.40 GHz, 512 MB RAM, dan HDD 40 GB. Sedangkan untuk server, spesifikasi minimum yang direkomendasikan adalah processor Intel® Pentium® IV 2.40 GHz, 512 MB RAM, dan HDD 120 GB. Untuk jaringan LAN yang menghubungkan komputer client dengan

server digunakan switch 12 port, NIC, dan kabel UTP. Selain komputer, sistem informasi juga membutuhkan perlengkapan hardware tambahan yaitu printer yang digunakan masing-masing oleh General Manager dan Kepala Pabrik untuk mencetak laporan.

4.6.1.3.Bahasa Perancangan

Kegiatan perancangan sistem informasi mulai dari preliminary analysis hingga

component design dilakukan berdasarkan notasi UML Diagram. Sedangkan software yang digunakan untuk membuat diagram-diagram tersebut adalah Miscosoft Visio yang juga merupakan bagian dari Microsoft Office System 2003.

4.6.2.Rencana Implementasi

Setelah fasilitas-fasilitas tersedia dan dapat menjalankan sistem informasi usulan dengan baik, maka ditetapkan rencana untuk mengimplementasikan sistem tersebut pada kegiatan bisnis di PT Decorindo Raya, khususnya yang berhubungan dengan pengendalian kualitas. Berikut adalah rencana implementasi dari sistem informasi usulan.

370 Tabel 4.91 Rencana Implementasi Sistem Informasi Usulan Periode waktu (minggu) Proses 1 2 3 4 5 6 7 8 Pengembangan sistem Persiapan kebutuhan technical platform Instalasi sistem Uji coba sistem Training user Penerapan sistem Pemeliharaan sistem

….


Untuk mendapatkan hasil yang maksimal, maka sistem usulan harus diimpelementasikan dengan metode yang tepat dan sesuai dengan kondisi perusahaan. Seperti yang sudah dijelaskan sebelumnya, sebagian besar karyawan di PT Decorindo Raya khususnya di bagian pabrik belum terbiasa untuk bekerja menggunakan komputer. Kegiatan sehari-hari lebih banyak dilakukan secara manual. Karena itu metode implementasi yang sebaiknya digunakan adalah parallel conversion di mana pada saat sistem informasi usulan diterapkan, sistem lama yang menggunakan cara manual juga masih digunakan. Tujuannya adalah untuk meminimasi resiko kehilangan data dan kesalahankesalahan yang mungkin terjadi selama proses produksi. Selain itu metode ini juga memberikan kesempatan bagi karyawan-karyawan untuk membiasakan diri untuk mengoperasikan komputer dan menjalankan sistem informasi usulan.

Gambar 4.34 Cluster Jadwal Produksi. jadwal produksi oleh Kepala Pabrik. Seperti yang sudah dijelaskan dalam system

Recommend Documents