Pengamatan cara berjalan proses bisnis akan membantu pemahaman fungsi bisnis, salah satunya dengan menggambarkan activity diagram. Activity diagram menggambarkan aktivitas dari beragam user atau sistem, siapa yang melakukan aktivitas, dan aliran urutan dari aktivitas. Berikut ini merupakan activity diagram dari aktivitas pengendalian kualitas yang berjalan di IGP4.
Pengendalian kualitas yang berjalan saat ini dimulai dari pendataan line, part, kemudian produksi yang dilakukan. Setelah produksi, dilakukan pendataan terhadap produk suspect dan berikutnya digolongkan menjadi produk ok, reject, atau repair. Jika
repair telah dilakukan, bagian QC akan kembali mendata produk yang berhasil di repair
oleh bagian Production. Belum terdapat sistem yang dapat mengintegrasikan data yang dibutuhkan untuk dapat mendukung analisa dalam rangka peningkatan sistem pengendalian kualitas. Untuk itu diusulkan penggunaan sistem informasi yang yang dapat mengintegrasikan data penyebab dari reject yang terjadi, permasalahan yang terjadi dan operation apa yang terkait langsung dengan masalah yang terjadi, bagaimana perbandingan reject ratio di keseluruhan line, problem apa saja yang sering terjadi, bagaimanakah tingkat terjadinya problem tersebut, dan nilai sigma capability yang telah dicapai dan pendataan action yang telah dilakukan, sehingga sistem dapat digunakan untuk mendukung analisa dan improvement di masa yang akan datang.
4.2.2 Requirements
Berikutnya aktivitas dari sistem yang akan dikembangkan dan juga keterkaitan antara aktivitas yang akan dilakukan, disajikan dalam activity diagram.
Gambar 4.60 Activity Diagram Sistem Pengendalian Kualitas Yang Akan Dikembangkan Pada IGP4
Semua kegiatan yang terjadi dalam suatu sistem, dan juga informasi tambahan lainnya yang perlu didokumentasikan, disajikan dalam bentuk sebuah event table. Event
table dari sistem pengendalian kualitas yang akan dikembangkan sesuai dengan
kebutuhan disajikan sebagai berikut:
No Event Trigger Source Usecase Response Destination
1 Production Dept. wants to maintain line changes in line Production Dept. Maintain line line data updated - 2 Production Dept. wants to maintain part changes in part Production Dept. Maintain part part data updated - 3 Production Dept. wants to maintain operation of a part changes in operation Production Dept. Maintain operation operation data updated - 4 Production Dept. wants to maintain problem of a part changes in partproblem QC Dept. Maintain partproblem partproble m data updated - 5 QC Dept. wants to maintain problem analysis of a product new analysis of a product QC Dept. Maintain Problem analysis problem anaylsis data updated - 6 Production of a product new production Production Dept. Maintain production production data updated - 7 QC Dept. identify suspects from production
new suspect QC Dept. Maintain
suspect
suspect data updated
-
No Event Trigger Source Usecase Response Destination 8 Production Dept. repaired a product
new repair Production
Dept. Maintain repair repair data updated QC Dept. 9 QC Dept. wants to maintain problem analysis of a product new analysis of a product QC Dept. Maintain Problem analysis problem anaylsis data updated - 10 QC Dept. wants to maintain sigma_capa bility data and action as a response to capability level of a product periodically, usually at the beginning of a month QC Dept. Maintain Sigma Capability Sigma Capability data updated 10 QC Dept. wants to print report Every week or month or if needed QC Dept. Create
report report QC Dept.
Gambar 4.62 Event Table Sistem Pengendalian Kualitas Pada IGP4 (lanjutan)
Objek-objek yang ditentukan pada sistem pengendalian kualitas sebagai berikut: 1. Line, menyatakan lini produksi yang ada. Setiap line produksi dapat berhubungan
dengan beberapa jenis part yang dapat diproduksi.
2. Part, menyatakan tipe-tipe part yang diproduksi. Disini dibutuhkan juga data price untuk dapat mengetahui harga dari suatu part dan menjadi pertimbangan untuk
jumlah cost yang harus dikeluarkan apabila terjadi reject pada suatu part, serta jumlah CTQ yang didefinisikan untuk setiap part tertentu.
3. Operation, menyatakan tahapan operasi yang dialami oleh suatu part. Operation ini berikutnya akan merupakan suatu tahap operation di mana dapat terjadi sebuah peristiwa yang mengakibatkan part menjadi reject.
4. PartProblem, menyatakan problem-problem yang dapat terjadi yang mengakibatkan
part menjadi reject. PartProblem juga mengidentifikasikan di operation mana PartProblem tersebut terjadi.
5. Problem Analysis, menyatakan analisa yang telah dilakukan dari suatu produk. Dinyatakan bahwa suatu problem tertentu memiliki akar masalah, di mana akar masalah tersebut dapat mempunyai akar masalah berikutnya, sampai tahap tertentu yang disebut sebagai sumber akar permasalahan.
6. Production, menyatakan produksi part yang dilakukan. Dalam Production ini, jumlah produksi diklasifikasikan ke jumlah produk ok dan jumlah produk suspect. Produk suspect ini merupakan produk yang belum dapat diputuskan, apakah menjadi produk yang dapat diterima atau harus di reject, karena memerlukan pengidentifikasian produk lebih lanjut dari pihak quality berdasarkan kebutuhan untuk perakitan part berikutnya.
7. Suspect, menyatakan klasifikasi dari jumlah suspect pada produksi sebelumnya. Pada
suspect, diklasifikasikan lagi action dari suatu produk, dapat lolos (produk ok), reject
(tidak dapat diperbaiki dan digunakan lagi), atau repair (dianggap dapat menjadi ok setelah mengalami proses ulang yang disebut repair).
9. Sigma_Capability, menyatakan tingkat kapabilitas sigma yang diukur dengan rumus tertentu, terkait dengan jumlah part yang reject dan jumlah part yang telah diproduksi, serta dilakukan pendataan action terhadap tingkat sigma capability saat yang diperoleh setiap selesai mendeskripsikan produksi, suspect, dan repair.
10. Report, menyatakan laporan yang akan digunakan untuk mendukung analisa dan
improvement di masa yang akan datang.
Class-class, asosiasi dan multiplity sistem pengendalian kualitas digambarkan
dalam sebuah domain class diagram sebagai berikut pada gambar 4.63:
-Part_No -LineID -Part_Name -Price -QtyCTQ Part -ProductionID -ProductionDate -Part_No -Shift -QtyOk -QtySuspect Production -SuspectID -ProductionID -SuspectDate -PIC Suspect -RepairID -SuspectID -RepairDate -QtyRepairOk -QtyRepairReject Repair -ProbID -PartProblemID -Caused -Root_Level -AnalysisDate Problem Analysis 1 1..* 1..* 1 0..1 1 1 0..1 -PartProblemID -Part_No -OperationID -Problem PartProblem 1 1..* -LineID -Line_Name Line 1..* 1 -SuspectContentID -SuspectID -SuspectState -Qty -PartProblemID -Cnt_Measure Suspect_Content 1 1..* -OperationID -Part_No -Operation_Name -Machine_Name Operation -SCID -ProductionID -SuspectID -SCDateFrom -SCDateTo -RejectRatio -SC_value -SC_Target -Action -PIC Sigma_Capability 1 1 1 1..* 1 0..*
Berikutnya sistem yang akan dikembangkan ini akan disebut dengan QCSS (Quality Control Support System). Terdapat sebuah matrix yang dapat dibuat untuk menekankan kebutuhan akses antar class. Matrix ini menunjukkan use case mana yang dapat mengakses setiap domain class. CRUD Matrix QCSS disajikan sebagai berikut:
Use Cases Line Part Operation PartProblem Problem An alysis
Production Suspect Repair
Sigma_Capability Maintain Line CR UD Maintain part R CR UD Maintain operation R R CR UD Maintain partproblem R R R CR UD
Maintain problem analysis R R R CR
UD Maintain production R R CR UD Identify suspect R R RU CR UD Maintain repair R R R R CR UD
Maintain sigma capability R R R R CR
UD
Create report R R R R R
Statechart dari objek-objek tertentu pada QSCC yang perlu didefinisikan
disajikan sebagai berikut:
Statechart dari objek-objek pada QSCC disajikan sebagai berikut: 1. Line
Gambar 4.65 Statechart Line
2. Part active / getPart(Part_Name) / updatePart (LineID,Part_Data) Part added / DeletePart (Part_No) / addPart (Part_No,LineID,Part_Data) initPart (Part_No,Line_Name,Part_Data)
Gambar 4.66 Statechart Part
3. Operation
4. PartProblem
Gambar 4.68 Statechart Part Problem
5. Problem Analysis
Gambar 4.69 Statechart Problem Analysis
6. Production
Gambar 4.70 Statechart Production
7. Suspect
8. Repair
Gambar 4.72 Statechart Repair
9. Sigma Capability
Berikutnya digambarkan use case diagram dari QCSS. Use case diagram membuat sebuah daftar isi dari aktivitas event bisnis yang harus didukung oleh sistem:
Pengembangan sistem membutuhkan analisis untuk lebih detail lagi dalam setiap level deskripsi diagram. Karena itu dibuat sebuah use case description. Use case
description. Use case description QCSS disajikan sebagai berikut: 1. Maintain_Line
Use Case Name : Maintain_line Scenario : Maintain data line
Triggering Event : Perubahan pada line produksi
Brief Description :
Ketika terjadi perubahan pada data Line, misalnya perubahan nama, penambahan atau pengurangan Line, dilakukan
maintain_line. Actors : Production dept. Related Use Cases : -
Stakeholders : Production dept : untuk mengupdate data Line Preconditions : -
Postconditions : Data Line telah dimaintain. Add, edit, atau delete Line telah dilakukan.
Flow of Events :
Actor System 1.User melakukan login. 1.Verifikasi login pada
database.
2.User membuka form Line. 2.Form Line menampilkan data Line yang ada pada grid. 3.1.User memilih Add. 3.1.Ditampilkan field yang
dapat diisi dengan data Line yang baru.
3.1.1.User memilih Save. 3.1.1.Menyimpan data Line yang baru, kemudian kembali menampilkan data Line yang telah terupdate pada grid. Gambar 4.75 Use Case Description Maintain Line
3.2.User melakukan perubahan pada data Line yang sedang ditunjuk, kemudian memilih Save.
3.2.Menyimpan data Line yang baru, kemudian kembali
menampilkan data Line yang telah terupdate pada grid. 3.3.User memilih data Line
kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian menghapus data Line terpilih, kemudian kembali
menampilkan data Line yang telah terupdate pada grid. Exception Conditions: -
Gambar 4.76 Use Case Description Maintain Line (lanjutan)
2. Maintain_Part
Use Case Name : Maintain_ Part
Scenario : Maintain data Part
Triggering Event : Perubahan pada Part produksi
Brief Description :
Ketika terjadi perubahan pada data Part, misalnya perubahan nama, penambahan atau pengurangan Part, dilakukan
maintain_ Part. Actors : Production dept. Related Use Cases : -
Stakeholders : Production dept : untuk mengupdate data Part Preconditions : Data Line yang terkiat dengan suatu Part telah ada.
Postconditions : Data Part telah dimaintain. Add, edit, atau delete Part telah dilakukan.
Flow of Events : Actor System
1.User melakukan login. 1.Verifikasi login pada database.
2.User membuka form Part. 2.Form Part menampilkan data Part yang ada pada grid. 3.1.User memilih Add. 3.1.Ditampilkan field yang
dapat diisi dengan data Part yang baru.
3.1.1.User memilih Save. 3.1.1.Menyimpan data Part yang baru, kemudian kembali menampilkan data Part yang telah terupdate pada grid. 3.2.User melakukan
perubahan pada data Part yang sedang ditunjuk, kemudian memilih Save.
3.2.Menyimpan data Part yang baru, kemudian kembali menampilkan data Part yang telah terupdate pada grid. 3.3.User memilih data Part
kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian kembali menampilkan data Part yang telah terupdate pada grid. Exception Conditions: -
Gambar 4.78 Use Case Description Maintain Part (lanjutan)
3. Maintain_Operation
Use Case Name : Maintain_ Operation
Scenario : Maintain data Operation
Triggering Event : Perubahan pada Operation produksi
Brief Description :
Ketika terjadi perubahan pada data Operation, misalnya perubahan nama, penambahan atau pengurangan Operation, dilakukan maintain_Operation.
Actors : Production dept. Related Use Cases : -
Stakeholders : Production dept : untuk mengupdate data Operation Gambar 4.79 Use Case Description Maintain Operation
Preconditions : Data Part yang terkait dengan Operation telah ada. Postconditions : Data Operation telah dimaintain. Add, edit, atau delete
Operation telah dilakukan.
Flow of Events :
Actor System 1.User melakukan login. 1.Verifikasi login pada
database. 2.User membuka form
Operation.
2.Form Operation
menampilkan data Operation yang ada pada grid.
3.1.User memilih Add. 3.1.Ditampilkan field yang dapat diisi dengan data Operation yang baru. 3.1.1.User memilih Save. 3.1.1.Menyimpan data
Operation yang baru, kemudian kembali menampilkan data Operation yang telah terupdate pada grid.
3.2.User melakukan perubahan pada data Operation yang sedang ditunjuk, kemudian memilih Save.
3.2.Menyimpan data Operation yang baru, kemudian kembali menampilkan data Operation yang telah terupdate pada grid.
3.3.User memilih data Operation kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian menghapus data Operation terpilih, kemudian kembali menampilkan data Operation yang telah terupdate pada grid. Exception Conditions: -
Gambar 4.81 Use Case Description Maintain Operation(lanjutan)
4. Maintain_PartProblem
Use Case Name : Maintain_ PartProblem Scenario : Maintain data PartProblem
Triggering Event : Perubahan pada PartProblem produksi
Brief Description :
Ketika terjadi perubahan pada data PartProblem, misalnya perubahan nama, penambahan atau pengurangan PartProblem, dilakukan maintain_PartProblem.
Actors : QC dept. Related Use Cases : -
Stakeholders : QC dept : untuk mengupdate data PartProblem
Preconditions : Data Part dan Operation yang terkait dengan PartProblem telah ada.
Postconditions : Data PartProblem telah dimaintain. Add, edit, atau delete PartProblem telah dilakukan.
Actor System Flow of Events : 1.User melakukan login. 1.Verifikasi login pada
database. 2.User membuka form
PartProblem.
2.Form PartProblem menampilkan data
PartProblem yang ada pada grid.
Flow of Events :
3.1.User memilih Add. 3.1.Ditampilkan field yang dapat diisi dengan data PartProblem yang baru. 3.1.1.User memilih Save. 3.1.1.Menyimpan data
PartProblem yang baru, kemudian kembali
menampilkan data PartProblem yang telah terupdate pada grid. 3.2.User melakukan
perubahan pada data PartProblem yang sedang ditunjuk, kemudian memilih Save.
3.2.Menyimpan data PartProblem yang baru, kemudian kembali
menampilkan data PartProblem yang telah terupdate pada grid. 3.3.User memilih data
PartProblem kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian menghapus data PartProblem terpilih, kemudian kembali menampilkan data PartProblem yang telah terupdate pada grid. Exception Conditions: -
Gambar 4.83 Use Case Description Maintain PartProblem (lanjutan)
5. Maintain_Production
Use Case Name : Maintain_Production Scenario : Maintain data Production Triggering Event : Produksi baru dari sebuah Part
Brief Description :
Ketika terjadi perubahan pada data Production, misalnya perubahan nama, penambahan atau pengurangan Production, dilakukan maintain_Production.
Actors : Production dept.
Related Use Cases : -
Stakeholders : Production dept : untuk mengupdate data Production Preconditions : Data Part akan diproduksi telah ada.
Postconditions : Data Production telah dimaintain. Add, edit, atau delete Production telah dilakukan.
Flow of Events :
Actor System 1.User melakukan login. 1.Verifikasi login pada
database. 2.User membuka form
Production.
2.Form Production
menampilkan data Production yang ada pada grid.
3.1.User memilih Add. 3.1.Ditampilkan field yang dapat diisi dengan data Production yang baru. 3.1.1.User memilih Save. 3.1.1.Menyimpan data
Production yang baru, kemudian kembali
menampilkan data Production yang telah terupdate pada grid. 3.2.User melakukan
perubahan pada data Production yang sedang ditunjuk, kemudian memilih Save.
3.2.Menyimpan data Production yang baru, kemudian kembali
menampilkan data Production yang telah terupdate pada grid. Gambar 4.85 Use Case Description Maintain Production
3.3.User memilih data Production kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian menghapus data Production terpilih, kemudian kembali menampilkan data Production yang telah terupdate pada grid. Exception Conditions: -
Gambar 4.86 Use Case Description Maintain Production (lanjutan)
6. Maintain_Suspect
Use Case Name : Maintain_Suspect Scenario : Maintain data Suspect
Triggering Event : Ditemukan suspect baru dari produksi yang telah dilakukan
Brief Description :
Ketika terdapat sejumlah suspect pada Production, maka QC Dept. akan membuat data Suspect dan mengklasifikasikan action dari Suspect yang telah terjadi, dilakukan
maintain_Suspect. Actors : QC dept.
Related Use Cases : -
Stakeholders : QC dept : untuk mengupdate data Suspect
Preconditions : Data Production yang memuat sejumlah suspect telah ada.
Postconditions :
Data Suspect telah dimaintain. Add, edit, atau delete Suspect telah dilakukan. Status Production bahwa Suspect telah dilakukan terupdate.
Actor System Flow of Events : 1.User melakukan login. 1.Verifikasi login pada
database. Gambar 4.87 Use Case Description Maintain Suspect
Flow of Events :
2.User membuka form Suspect.
2.Form Suspect menampilkan pilihan data Production yang harus dilakukan klasifikasi Suspect.
3.1.User memilih Add. 3.1.Ditampilkan field yang dapat diisi dengan data action yang dilakukan pada sejumlah Suspect tersebut. baru.
3.1.1.User memilih Save. 3.1.1.Menyimpan data Suspect yang baru.
3.2.User memilih Edit, melakukan perubahan pada data Suspect yang sedang ditunjuk, kemudian memilih Save.
3.2.Menyimpan data Suspect yang baru, kemudian kembali menampilkan data Suspect yang telah terupdate pada grid.
3.3.User memilih data Suspect kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian menghapus data Suspect terpilih, kemudian kembali menampilkan data Suspect yang telah terupdate pada grid. Exception Conditions: -
7. Maintain_Repair
Use Case Name : Maintain_Repair Scenario : Maintain data Repair Triggering Event : Repair dari sebuah Part
Brief Description :
Ketika terdapat sejumlah repair setelah klasifikasi yang dilakukan pada data Suspect , maka Production Dept. akan membuat data Repair.
Actors : Production dept. Related Use Cases : -
Stakeholders : Production dept : untuk mengupdate data Repair Preconditions : Data Suspect yang memuat sejumlah Repair telah ada.
Postconditions :
Data Repair telah dimaintain. Add, edit, atau delete Repair telah dilakukan. Status Suspect bahwa telah dilakukan Repair terupdate.
Actor System 1.User melakukan login. 1.Verifikasi login pada
database.
Flow of Events :
2.User membuka form Suspect.
2.Form Repair menampilkan pilihan data Suspect yang harus dilakukan Repair. 3.1.User memilih Add. 3.1.Ditampilkan field yang
dapat diisi dengan data action yang dilakukan pada
sejumlah Repair tersebut. 3.1.1.User memilih Save. 3.1.1.Menyimpan data Repair
yang baru.
3.2.User memilih Edit 3.2.Memperlihatkan data Repair.
3.3.User memilih data Suspect kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian menghapus data Repair terpilih, kemudian kembali menampilkan data Repair yang telah terupdate pada grid. Exception Conditions: -
Gambar 4.90 Use Case Description Maintain Repair (lanjutan)
8. Maintain_ProblemAnalysis
Use Case Name : Maintain_ ProblemAnalysis Scenario : Maintain data ProblemAnalysis
Triggering Event : Problem analysis baru dari sebuah PartProblem
Brief Description : Ketika terdapat perubahan pada problem analysis , maka QC Dept. akan mengupdate data problem analysis.
Actors : QC dept. Related Use Cases : -
Stakeholders : QC dept : untuk mengupdate data ProblemAnalysis Preconditions : Problem yang terkait dengan analysis telah tersedia.
Postconditions :
Data ProblemAnalysis telah dimaintain. Add, edit, atau delete ProblemAnalysis telah dilakukan. Data ProblemAnalysis terupdate.
Flow of events : Actor System
1.User melakukan login. 1.Verifikasi login pada database.
2.User membuka form ProblemAnalysis.
2.Form ProblemAnalysis menampilkan pilihan data ProblemAnalysis.
3.1.User memilih Add. 3.1.Ditampilkan field yang dapat diisi dengan data root name yang dilakukan pada 3.1.1.User memilih Save. 3.1.1.Menyimpan data
ProblemAnalysis yang baru. 3.2.User memilih Edit,
melakukan perubahan pada data ProblemAnalysis yang sedang ditunjuk, kemudian memilih Save.
3.2.Menyimpan data
ProblemAnalysis yang baru, kemudian kembali
menampilkan data
ProblemAnalysis yang telah terupdate pada grid.
3.3.User memilih data ProblemAnalysis kemudian memilih Delete.
3.3. Konfirmasi untuk men-delete data, jika ya kemudian menghapus data
ProblemAnalysis terpilih, kemudian kembali
menampilkan data
ProblemAnalysis yang telah terupdate pada grid.
Exception Conditions: -
Gambar 4.92 Use Case Description Maintain Problem Analysis (lanjutan) 9. Maintain_SC
Use Case Name : Maintain_ SC
Scenario : Maintain data Sigma Capability
Triggering Event : Biasanya setiap akhir minggu, akhir bulan, atau sekiranya diperlukan.
Brief Description :
Ketika pengukuran Sigma Capability yang baru yang akan didokumentasikan pada SC, maka QC Dept. akan mengupdate data SC.
Actors : QC dept. Related Use Cases : -
Stakeholders : QC dept : untuk mengupdate data SC
Preconditions : Suspect dan Repair dari Production telah ditetapkan. Postconditions : Data SC telah dimaintain. Add, edit, atau delete SC telah
dilakukan. Data SC terupdate.
Flow of Events :
Actor System 1.User melakukan login. 1.Verifikasi login pada
database.
2.User membuka form SC. 2.Form SC menampilkan pilihan data SC.
3.1.User memilih Add. 3.1.Ditampilkan field yang dapat diisi dengan data SC. 3.1.1.User memilih Save. 3.1.1.Menyimpan data SC yang
baru. 3.2.User memilih Edit,
melakukan perubahan pada data SC yang sedang
ditunjuk, kemudian memilih Save.
3.2.Menyimpan data SC yang baru, kemudian kembali menampilkan data SC yang telah terupdate pada grid.
3.3.User memilih data SC kemudian memilih Delete.
3.3. Menghapus data SC terpilih, kemudian kembali menampilkan data SC yang telah terupdate pada grid. Exception Conditions: -
10. Create_Report
Use Case Name : Create_Report
Scenario : Melihat Report
Triggering Event : Biasanya periodik setiap minggu atau setiap bulan, atau tergantung kebutuhan.
Brief Description : Setiap minggu, QC dept. melihat laporan line dengan reject tertinggi dan problem yang terkait dengan reject tersebut Actors : QC dept.
Related Use Cases : -
Stakeholders : QC dept : untuk melihat Report Preconditions : Data SC telah terupdate
Postconditions : Report dapat dilihat
Actor System 1.User melakukan login. 1.Verifikasi login pada
database.
Flow of Events : 2.User membuka form report. 2.Form report menampilkan pilihan tanggal.
3.User memilih Show.
3.Ditampilkan grafik yang menunjukkan reject ratio tertinggi pada keseluruhan line dan problem terkait selama kurun waktu dari tanggal yang telah dipilih.
Exception Conditions: -