Salinan Terjemahan Tugas Kensis - Managing A Concurrent Engineering Environment.pdf

MENGELOLA LINGKUNGAN TEKNIK KONKUREN: ALAT DAN TEKNIK Banyak alat dan teknik yang berbeda telah dikembangkan untuk mengelola inisiatif rekayasa bersamaan dalam domain dan / atau film tertentu. Namun, hampir semua metode ini menunjukkan fitur bahasa pemodelan proses terstruktur dan teknik untuk mengevaluasi kinerja lingkungan rekayasa bersamaan. Pada bagian ini kami menguraikan beberapa metodologi pemodelan perusahaan yang berguna yang telah digunakan untuk mempelajari sistem teknik bersamaan. Selain itu, strategi penilaian risiko berorientasi siklus hidup produk disajikan untuk mengelola proyek-proyek rekayasa bersamaan. 1. Metodologi untuk Memodelkan Proses Rekayasa Bersamaan Selain menjadi alat penting untuk membangun model proses lingkungan rekayasa bersamaan juga berguna untuk mengelola dan memantau proyek-proyek rekayasa bersamaan. Ada banyak metodologi untuk perusahaan pemodelan. Meskipun metode bervariasi dalam cakupan, penampilan, dan landasan teori, mereka semua memberikan wawasan tentang masalah pengembangan model proses proses rekayasa bersamaan. Bagian ini menjelaskan secara singkat beberapa metodologi yang ada. 1.1 CIM-OSA Computer Integrated Manufacturing-Open Systems Architecture (CIM-OSA) adalah subjek pengembangan yang sedang berlangsung oleh ESPRIT Consortium AMICE. Metodologi ini memfasilitasi pemodelan total perusahaan melalui proses konstruksi model yang mencakup deskripsi implementasi perusahaan. Empat pandangan perusahaan, atau perspektif, dipertimbangkan: fungsi, informasi, sumber daya, dan organisasi. Dalam setiap tampilan, blok bangunan umum menjelaskan fungsi, informasi, sumber daya dalam sistem. Hubungan antara blok bangunan menentukan total perusahaan (Beekman, 1989). CIM-OSA mengakui perspektif fungsional, informasi, sumber daya, dan organisasi yang harus dipertimbangkan secara eksplisit dalam memodelkan lingkungan rekayasa serentak. Lebih lanjut, konsep abstraksi seperti enkapsulasi, klasifikasi, dan pewarisan didukung. 1.2 EXPRESS Pada 1980, ISO TC184 / SC4 / WG5 memulai pekerjaan pada EXPRESS dan Versi 1.0 disetujui pada tahun 1991. Konsorsium PDES menggunakan EXPRESS secara sistematis dalam pekerjaannya pada LANGKAH. Representasi grafis dari bahasa tersedia sebagai EXPRESS-G. Metodologi ini menyediakan sintaks untuk mendefinisikan kelas entitas (yang dapat berupa informasi, sumber daya, material, produk, dll.) Yang mendukung abstraksi. Namun, perilaku dinamis tidak dapat dimodelkan. Meskipun tidak sejelas CIM-OSA, EXPRESS dapat menangkap perspektif fungsional, informasi, sumber daya, dan organisasi dari lingkungan rekayasa bersamaan (European Committee for Standardization, 1994). 1.3 Metode GRAI Metode GRAI dikembangkan oleh Laboratorium GRAI pada awal 1980-an dan telah digunakan secara internasional dalam pembuatan aplikasi (Doumeingts et al., 1987). Metode GRAI dibangun di sekitar model referensi konseptual yang didasarkan pada teori sistem yang kompleks, sistem hierarkis, sistem organisasi, dan teori kegiatan diskrit. Sistem manufaktur terstruktur dalam tiga subsistem: sistem fisik, sistem informasi, dan sistem keputusan. Formalisme GRAI berfokus pada subsistem keputusan dan

bergantung pada metode lain, seperti IDEF0 dan atribut hubungan entitas (ERA), untuk memodelkan sistem fisik dan informasi. Formalisme GRAI didukung oleh dua representasi grafis: grid GRAI, dan jaringan GRAI. Meskipun metode GRAI secara eksplisit berfokus pada dekomposisi perspektif organisasi, metode itu sendiri tidak mencakup perspektif fungsional, informasi, dan sumber daya. Melalui dekomposisi, metode ini mendukung enkapsulasi. Namun, klasifikasi dan pewarisan tidak didukung. 1.4 Metode IDEF Seperti dibahas dalam Bagian 9.3.2.1, pengembangan metode IDEF dimulai dengan program Angkatan Udara untuk ICAM dan dilanjutkan sebagai bagian dari program Angkatan Udara IICE. Meskipun IDEF0 dan IDEF3 adalah yang paling populer, metode IDEF tambahan telah dan terus dikembangkan. Model IDEF1x digunakan untuk memodelkan hubungan antara berbagai bagian data secara semantik. Konstruksi dasar model IDEF1x meliputi entitas, atribut, dan hubungan (Mayer, 1990). Metodologi IDEF4 menyediakan sintaks dan semantik untuk menangkap proses pemikiran yang diperlukan untuk mengembangkan aplikasi modular, dipelihara, dan dapat digunakan kembali yang diprogram dalam bahasa berorientasi objek seperti C ++, Object Pascal, Common Lisp Object System (CLOS), Smalltalk (Mayer et al ., 1992b). Perilaku dinamis suatu sistem dapat ditangkap menggunakan IDEF2. Metode untuk memodelkan ontologi domain (IDEF5) dan mendefinisikan motif yang mendorong proses pengambilan keputusan (IDEF6) sedang dalam pengembangan. Secara keseluruhan, keluarga IDEF metode memfasilitasi pembangunan model untuk berbagai perspektif arsitektur. 1.5 IEM Integrated Enterprise Modeling (IEM) adalah metodologi domain publik yang dikembangkan oleh IPK Berlin (Komite Eropa untuk Standardisasi, 1994). Berbeda dengan metode sebelumnya (dengan pengecualian IDEF4), IEM dirancang di sekitar paradigma berorientasi objek. Objek dalam sistem manufaktur dan desain dijelaskan oleh data dan fungsi yang mengubah objek. Objek dibedakan secara sengaja menjadi tiga kelas: produk, pesanan, dan sumber daya. Semua objek nyata di lingkungan manufaktur milik salah satu dari tiga kelas dan subclass IEM. Model aktivitas generik didefinisikan untuk beroperasi pada objek. Paradigma berorientasi objek memungkinkan pemodelan simultan dari perspektif fungsional dan informasi melalui kelas konstruk tunggal. Meskipun tidak secara eksplisit dipertimbangkan dalam IEM, perspektif organisasi dapat ditambahkan dan diintegrasikan menggunakan konsep kelas. Metodologi ini menggambarkan kemampuan pemodelan generik yang kuat yang disediakan oleh paradigma berorientasi objek yang berguna untuk memodelkan lingkungan teknik bersamaan. 1.6 PSL / PSA Bahasa Pernyataan Masalah/ Analisis Pernyataan Masalah (PSL / PSA) dikembangkan secara komersial oleh Sistem META (Komite Eropa untuk Standardisasi, 1994). Komponen PSL adalah bahasa yang dapat digunakan untuk menggambarkan sistem informasi dalam hal objek, properti, dan hubungan. Seperti dengan IDEF1x, PSL / PSA didasarkan pada konsep teori database relasional. Representasi formal dan grafis disediakan dan laporan dapat dihasilkan dari perangkat lunak yang

tersedia secara komersial. Pendekatan relasional untuk pemodelan yang disediakan oleh PSL / PSA kurang diinginkan dibandingkan dengan metodologi berorientasi objek yang tersedia. 1.7 SSADM Metode Analisis dan Desain Sistem Terstruktur(SSADM) adalah metode standar analisis dan desain sistem yang digunakan oleh pemerintah Inggris. SSADM dikembangkan oleh Central Computer and Telecommunications Agency pada awal 1980-an. Metode ini berfokus pada analisis persyaratan bisnis, desain, dan spesifikasi basis data aplikasi dan perangkat lunak. Sebuah proyek dipecah menjadi modul yang berisi kegiatan yang harus diselesaikan untuk mengantarkan produk. Setiap langkah memiliki daftar tugas, input, dan output. SSADM memiliki modul untuk studi kelayakan, analisis persyaratan, spesifikasi persyaratan, spesifikasi sistem logis, dan desain fisik (Ashworth, 1988). Fokus yang jelas dari SSADM adalah pada perspektif informasi. Meskipun banyak teknik pemodelan informasi dimasukkan (yaitu, pemodelan aliran data, pemodelan peristiwa entitas, dan analisis data relasional), metode ini tidak menggunakan paradigma berorientasi objek. 1.8 OOMIS Metodologi Pemodelan Berorientasi Objek untuk Sistem Informasi Manufaktur (OOMIS) terdiri dari dua fase, fase analisis dan fase desain (Kim et al., 1993). Tugas pertama dari fase analisis adalah untuk menguraikan fungsi-fungsi manufaktur menjadi fungsi-fungsi komponen menggunakan pendekatan yang mirip dengan IDEF0. Setelah membangun model fungsional, tabel fungsi, tabel data, dan tabel operasi dihasilkan. Dalam fase desain, paradigma berorientasi objek digunakan untuk menerjemahkan tabel fungsi, tabel data, dan tabel operasi ke dalam model informasi yang terintegrasi. Kelas yang terdiri dari pengidentifikasi, atribut, dan metode didefinisikan untuk komponen sistem manufaktur. Dua tipe kelas spesifik digunakan, kelas fungsi dan kelas entitas. Desain semantik difasilitasi oleh diagram hubungan. OOMIS menampilkan banyak fitur yang diinginkan untuk memodelkan lingkungan teknik bersamaan. Tidak seperti metode lain yang memperlakukan perspektif fungsional dan informasi secara independen (yaitu, IDEF), paradigma berorientasi objek digunakan untuk membentuk model yang terintegrasi. Bahkan, perspektif informasi diturunkan langsung dari model fungsional. 2. Penilaian Risiko dalam Teknik Serentak Bagian ini menyajikan strategi untuk penilaian risiko dalam lingkungan teknik bersamaan. Strategi yang diusulkan didasarkan pada premis bahwa model holistik dari siklus hidup produk dapat digunakan untuk mengevaluasi desain produk apa pun dalam domain perusahaan. Oleh karena itu, produk dapat didefinisikan dalam konteks kegiatan yang harus dilakukan untuk menghasilkan produk yang sukses, daripada metode tradisional pemodelan berdasarkan artefak desain. Untuk menangkap tingkat detail yang diperlukan dalam model siklus hidup produk, metodologi pemodelan yang komprehensif harus digunakan. Rangkaian metode IDEF telah diadopsi untuk tujuan ini. Setelah model telah dikembangkan, dapat digunakan berulang kali untuk mengevaluasi desain berbagai produk. Persyaratan pelanggan memberikan ringkasan awal dari kegiatan yang harus dilakukan; namun, seluruh skenario desain (dan jalur selanjutnya melalui siklus hidup produk) mungkin jarang, jika pernah, direalisasikan. Oleh karena itu, tantangan manajemen proyek adalah menentukan kegiatan yang tersisa dalam rencana proyek yang menghasilkan desain yang sukses. Penentuan skenario desain akhir didasarkan pada berbagai faktor risiko rekayasa bersamaan yang berdampak pada sisa siklus hidup produk. Akibatnya, risiko keseluruhan,

dengan mempertimbangkan perspektif berbagai bidang fungsional yang berbeda, dapat dikurangi. Penilaian risiko adalah proses yang berupaya menjawab tiga pertanyaan: (1) Apa yang salah? (2) Apa kemungkinan itu salah? (3) Apa konsekuensinya? (Lihat Bab 3.) Berdasarkan pertanyaan-pertanyaan ini, Persamaan (9.1) adalah definisi risiko kuantitatif, di mana R adalah risiko, S adalah skenario peristiwa yang mengarah ke masalah, P adalah kemungkinan skenario, dan C adalah konsekuensi dari skenario: R ​= {​S, P, C}​

(9.1)

Skenario menangkap semua aktivitas dalam siklus hidup produk, termasuk segala sesuatu mulai dari desain hingga pembuangan. Probabilitas skenario ditentukan oleh kemungkinan bahwa kegiatan dalam skenario tersebut tidak mencapai tujuan produk. Konsekuensi buruk untuk skenario, atau desain produk / proses (misalnya, tanggal jatuh tempo yang dilanggar, potensi daur ulang yang rendah), dapat dihasilkan dari kegiatan di seluruh siklus hidup produk. Risiko R dihitung dengan Persamaan (9.2), di mana P​k​ adalah probabilitas skenario k, C​k​ adalah konsekuensi dari skenario k: K

R​ = ∑ (P k x Ck)

(9.2)

k=1

Risiko yang berorientasi pada siklus hidup prosedur penilaian dirangkum di bawah ini. Di bagian 9.4.2.1-9.4.2.4 kita membahas setiap langkah secara lebih rinci. Prosedur Penilaian Risiko 1. Identifikasi skenario dengan menentukan semua set path yang mungkin dalam model IDEF3 dari siklus hidup produk. 2. Perkirakan probabilitas setiap skenario menggunakan skema pembobotan formal. 3. Tentukan konsekuensi dari setiap skenario berdasarkan ukuran kinerja yang relevan dan persepsi para ahli domain tentang risiko. 4. Hitung risiko menggunakan Persamaan (9.2). 2. 1 Mengidentifikasi Skenario Siklus Hidup Produk Konsep set path dalam model IDEF3 digunakan untuk mengidentifikasi skenario. Path-set P​k = I, ..., K) dalam model IDEF3 adalah himpunan semua UOB yang mendefinisikan path dari sumber ke sink dalam model. Path-set ditentukan oleh persimpangan dalam model dan hanya satu set path yang diambil untuk setiap eksekusi model. Dengan demikian, set path mengidentifikasi skenario dalam siklus hidup produk. Karena semantik dari kotak persimpangan IDEF3, set-path sulit untuk diidentifikasi dengan inspeksi, bahkan dalam model yang relatif sederhana. Algoritme set path IDEF3 (Larson dan Kusiak, 1996) menggunakan matriks aktivitas-aktivitas diutamakan untuk mewakili model dan menentukan semua set path yang mungkin. Contoh 9.7. Mengidentifikasi Skenario Siklus Hidup Produk​. Contoh ini didasarkan pada bagian dari siklus hidup produk yang sesuai dengan proses pembuatan di pabrik elektronik. Gambar 9.27 menunjukkan versi sederhana dari model IDEF3 untuk proses dengan 27 DaBs dan berbagai kotak persimpangan. Algoritma set path IDEF3 diterapkan untuk mendapatkan set path yang tercantum dalam Tabel 9.9. Seperti yang diperlihatkan dalam contoh ini, untuk model kecil sekalipun, tidak layak untuk menentukan semua set jalur yang mungkin dengan inspeksi. Contoh ini menggambarkan

sejumlah besar skenario yang ditetapkan untuk satu fase saja dari siklus hidup produk. Dengan demikian, jelas bahwa sebagai fungsi desain, mailUfacturing, penjualan, layanan, dan pembuangan digabungkan, model menjadi sangat kompleks dan banyak skenario siklus hidup produk yang mungkin harus dievaluasi (satu yang sesuai dengan setiap jalur-set). Sebagai persyaratan pelanggan menjadi dikenal untuk produk-produk baru, mungkin melalui penggunaan QFD (Hauser dan Clausing, 1988), skenario tidak layak dapat dihilangkan dari siklus hidup produk. 2. 2 Probabilitas Skenario Penimbangan dan Agregat Ingatlah bahwa probabilitas skenario adalah kemungkinan UOB di set-path tidak berhasil diselesaikan. Gambar 9.27 Langkah pertama dalam menghitung probabilitas skenario adalah menentukan faktor-faktor risiko yang akan dipertimbangkan dan mempertimbangkannya. Informasi ini dapat diperoleh dengan menanyakan kepada pakar domain pertanyaan-pertanyaan berikut: (I) Karakteristik kunci apa dari produk dan proses yang penting untuk menyelesaikan desain yang sukses? (2) Bagaimana karakteristik ini dapat diukur, dipantau, dan dievaluasi? Karakteristik utama memberikan informasi berharga tentang faktor risiko di awal proses desain. Misalnya, pengiriman tepat waktu kepada pelanggan dapat disebut sebagai karakteristik utama. Oleh karena itu, risiko jadwal dapat diidentifikasi sebagai faktor risiko. Ukuran yang mungkin dari karakteristik ini adalah persentase pengiriman tepat waktu untuk produk yang serupa. Setelah mengumpulkan informasi ini, hierarki yang mirip dengan yang ditunjukkan pada Gambar 9.28 dapat dibangun untuk menerapkan bobot pada faktor risiko yang relevan. Metode seperti AHP dapat digunakan untuk menentukan faktor risiko. AHP adalah metode untuk pengambilan keputusan multikriteria yang diusulkan oleh Saaty (1981). Hal ini didasarkan pada premis bahwa jika masalah yang rumit didekomposisi menjadi hierarki, perbandingan berpasangan dapat dibuat antara atribut masalah untuk menentukan alternatif terbaik. Tujuan (sasaran) ditempatkan di bagian atas hierarki. Level hierarki berikutnya berisi atribut, atau kriteria, yang berkontribusi pada kualitas keputusan. Setiap atribut dapat didekomposisi menjadi atribut yang lebih rinci, dengan tingkat hierarki terendah yang berisi alternatif keputusan. Setelah jaringan hierarkis dibangun, prioritas elemen ditentukan pada setiap tingkat hirarki keputusan, dan prioritas dasar disintesis untuk menentukan peringkat alternatif keputusan. Hirarki dapat memfokuskan analisis pada faktor risiko spesifik yang relevan dengan tujuan keseluruhan untuk mencapai desain yang sukses. Pakar domain kemudian dapat memperkirakan kemungkinan bahwa dampak buruk akan dihasilkan dari faktor risiko. Misalnya, tingkat kegagalan mesin dapat digunakan untuk memperkirakan probabilitas bahwa jadwal produksi tidak akan dipenuhi. Dalam praktiknya, banyak faktor dapat berkontribusi pada probabilitas efek samping (yaitu, probabilitas hasil skenario dalam desain yang cacat). Penelitian yang sedang berlangsung sedang mengeksplorasi metode tambahan, seperti logika fuzzy, untuk mendapatkan ukuran yang akurat untuk kemungkinan skenario (Larson dan Kusiak, 1996). Tabel 9.9 Path-Sets untuk Model IDEF3 pada Gambar 9.27 2. 3 Mengidentifikasi dan Mengevaluasi Konsekuensi Skenario Gambar 9.28 Hierarki untuk menghitung bobot faktor risiko Tabel 9.10 Konsekuensi Faktor Rekayasa Bersamaan Faktor

RisikoFaktorFaktor Persyaratan risiko Risiko teknis Risiko risiko

KonsekuensiKonsekuensi Kehilangan basis pelanggan Karena pelanggaran tanggal Kualitas buruk Persyaratan sumber daya tambahan Pelanggaran tanggal

Risiko risiko risiko

Lebih tinggi biaya produk

jaringan

Pelanggaran tanggal Kerugian informasi desainIterasi desain tambahan Karena pelanggaran tanggal Tambahan persyaratan sumber daya tambahan Karena pelanggaran tanggal Tambahan kebutuhan sumber daya

Risikoulang Risiko

sumber daya Risiko

lingkungan

Polusi Persepsi publik negatif

Pengukuran Konsekuensi Jumlah keluhan pelanggan Hari terakhirbatas waktu Jumlahbiayamenolak Mengolah Daybatas waktu terakhir Personilbiaya biayaOverhead harga jual Kerugian produkpasarsaham biayamodal Daysbatas waktu terakhir Personilbiaya biaya overhead Daysbatas waktu terakhir Capital biaya biaya Personil Biaya overhead Hari melewati batas waktu Biaya pembersihan Biaya pembuangan produk

Konsekuensi dari skenario adalah efek buruk yang direalisasikan dengan gagal menyelesaikan UOB di jalur-set yang sesuai. Tabel 9.10 mencantumkan beberapa konsekuensi umum dari berbagai faktor risiko rekayasa bersamaan. Jelas, setiap konsekuensi ini menghasilkan biaya pengembangan produk yang lebih tinggi. Ukuran agregat dari biaya ini biasanya tergantung pada domain dan mencerminkan tujuan manajemen dan perhatian pelanggan. Sekali lagi, hubungan antara faktor risiko, konsekuensi, dan skenario desain alternatif dapat ditangkap dalam hierarki, seperti yang ditunjukkan pada Gambar 9.29. Tujuan keseluruhan adalah untuk mengurangi risiko. Konsekuensi pada tingkat kedua dapat dievaluasi untuk menentukan orang-orang yang paling penting untuk mencapai tujuan itu. Pentingnya setiap skenario dalam berkontribusi pada konsekuensi dievaluasi pada tingkat terendah. Skenario di tingkat terendah sesuai dengan skenario siklus hidup produk, seperti yang tercantum dalam Tabel 9.9. Bobot yang diperoleh pada tingkat kedua pada Gambar 9.29 dapat digunakan untuk menurunkan fungsi biaya untuk faktor risiko tertentu. Prosedur formal untuk menentukan konsekuensi harus mengatasi masalah membangun hierarki yang valid, termasuk protokol untuk melakukan pertemuan kelompok (Saaty, 1981; Larson dan Kusiak, 1996). 2. 4 Menghitung Risiko Gambar 9.29 Hierarki untuk mitigasi risiko Skenario siklus hidup produk yang diinginkan dapat diidentifikasi menggunakan AHP dan hierarki seperti yang ditunjukkan pada Gambar 9.29. Namun, juga informatif untuk menghitung nilai risiko proses dan membandingkannya dengan skenario lain. Ingatlah bahwa jika probabilitas skenario dapat diperkirakan dan fungsi biaya diturunkan untuk konsekuensi skenario, risiko proses dihitung

menggunakan Persamaan (9.2). Semua kegiatan dalam prosedur penilaian risiko yang berorientasi pada siklus hidup dilakukan oleh tim teknis bersamaan (lihat Bagian 9.3.1.1). Hal ini memungkinkan berbagai perspektif offungsional yang luas berkontribusi pada proses penilaian risiko. Bahkan, setiap program penilaian risiko siklus hidup yang sukses harus dibangun di sekitar konsep tim desain teknik bersamaan. Selain itu, penilaian risiko harus berfungsi sebagai komponen kunci untuk mengelola lingkungan teknik bersamaan.