Apa cara profesional melacak sejarah desain dalam rekayasa pabrik?

Jika Anda melihat dokumentasi desain di proyek-proyek kami (Biogas dan pabrik limbah-ke-energi), Anda mengetahui apa yang kami rencanakan untuk dibangun tetapi tidak mempertimbangkan opsi-opsi lain dan mengapa mereka dibuang. Informasi ini hanya ada di kepala insinyur. Kadang-kadang, pabrik akan berada dalam tahap konseptual selama bertahun-tahun, kadang-kadang beralih antar insinyur. Jadi saya menemukan diri saya meninjau kembali opsi yang dipertimbangkan rekan kerja dan akhirnya dibuang tahun lalu.

Apa cara yang baik untuk melacak keputusan desain, 'mengapa' dan 'mengapa-tidak'? Saya lebih suka pendekatan yang telah dicoba, diuji, dan digunakan di tempat lain di industri.

Informasi tambahan: Perusahaan saya akan mengejar sertifikasi ISO 9001, lebih disukai pendekatan yang sesuai dengan rezim QA ini.

Saya pikir ini tergantung pada seberapa banyak informasi yang Anda inginkan, dan seberapa formal Anda ingin melacaknya. Kedengarannya seperti saat ini, tidak ada informasi ini ditulis di mana pun, yang jelas merupakan masalah pertama. Tetapi meletakkan informasi untuk solusi yang tidak ingin Anda kejar, paling banter, adalah penggunaan waktu yang kurang optimal. Anda harus menentukan ide mana yang cukup untuk dicatat. Jika Anda mengadakan rapat dan selusin ide diletakkan di atas meja, tetapi setengahnya segera dibuang, apakah Anda ingin membuat catatan tentang apa ide-ide itu, dan mengapa mereka dibuang? Itu banyak upaya untuk apa yang mungkin merupakan analisis tingkat sangat rendah, tetapi mereka masih membuat keputusan.

Tampaknya lebih intuitif bagi saya untuk hanya melakukan ini untuk ide-ide yang mencapai tahap melakukan beberapa pekerjaan aktual pada mereka. Dengan cara ini, Anda sudah memiliki sesuatu yang nyata, dan ini harus disimpan dalam file proyek, yang saya harap sudah Anda miliki. Karena sistem ini benar-benar hanya akan menghasilkan bahan referensi untuk proyek masa depan, saya tidak berpikir itu akan menjadi ide yang baik untuk membuat sistem yang sama sekali baru untuk pengarsipan bahan-bahan ini, atau merombak sistem yang ada. Temukan cara untuk mengintegrasikannya ke dalam sistem manajemen desain Anda saat ini.

Satu kunci yang akan saya pastikan Anda miliki adalah cara mengklasifikasikan desain Anda yang berbeda dengan parameter kunci mereka. Saya tidak tahu banyak tentang bidang Anda, tetapi saya berasumsi ada parameter desain tertentu yang harus dipenuhi oleh setiap proyek (ukuran fisik, kapasitas, jenis pabrik, dll.). Pastikan ini mudah terlihat di suatu tempat, sehingga saat memulai proyek baru, Anda dapat mengidentifikasi proyek lama yang serupa dalam berbagai hal. Jika Anda menyimpan ide-ide yang dibuang ini di folder-folder itu, Anda akan dapat menganalisis utilitasnya untuk proyek Anda saat ini.

Namun, saya juga ingin memperingatkan secara umum tentang terlalu jauh dalam hal ini. Sekali lagi, saya bekerja di industri yang berbeda, di mana proyek jauh lebih pendek, dan karena itu, ada lebih banyak lagi, tetapi beberapa produk telah ada dalam beberapa bentuk selama beberapa dekade, dan ada 15-20 revisi. Mempertahankan riwayat revisi untuk perubahan desain aktual yang diterapkan sangat penting. Mengetahui apa yang diberikan pelanggan di masa lalu, kapan perubahan dilakukan, dan mengapa itu dilakukan adalah kunci untuk tidak mengulangi kesalahan masa lalu dan memperbaiki desain lama dengan benar. Tetapi ketika Anda katalog desain yang tidak pernah sepenuhnya terwujud, Anda menambahkan data yang tidak penting di atas data penting, dan hanya ada begitu banyak yang dapat Anda pilah sebelum hal-hal mulai hilang. Kedengarannya seperti kamu sedang mencari pengganti untuk komunikasi yang solid dan pengalaman yang baik. Ketika proyek-proyek ini berpindah tangan, para insinyur yang terlibat harus mengomunikasikan semua informasi yang relevan. Saya mengerti ingin memastikan Anda tahu apa yang telah dipertimbangkan, tetapi saya akan menyarankan Anda untuk meredam keinginan itu agar tidak membanjiri catatan Anda dengan data yang tidak perlu.

Ini jawaban dari Trevor memberikan cukup baik atas semua filsafat, tapi saya ingin mendapatkan lebih banyak pada detail.

Pertama, cari tahu mengapa catatan alternatif tidak disimpan. Ini kemungkinan dimulai sebagai masalah pandangan jauh ke depan atau masalah penyimpanan (kertas atau komputer).

Pada suatu waktu di masa lalu, seseorang berpikir bahwa alternatif tidak akan berguna, sehingga mereka dibuang atau dihapus. Ini kemungkinan merupakan masalah budaya perusahaan. Sekarang ini telah diidentifikasi sebagai masalah, itu dapat diangkat di seluruh perusahaan. Menyimpan catatan yang sudah dibuat itu mudah.

Bahkan jika insinyur asli berpikir bahwa alternatif mungkin berguna, mereka mungkin belum menyimpan dokumen karena biaya penyimpanan (fisik atau komputer). Jika ini masih terjadi, masalah ini harus diselesaikan sekarang. Jika ini bukan lagi masalahnya, kata itu perlu disebarluaskan ke seluruh perusahaan bahwa menyimpan catatan bukanlah proposisi yang mahal.

Kedua, lihat metode perbandingan alternatif. Ada dua kategori pertimbangan alternatif: pemikiran dan perhitungan.

Perbandingan pemikiran adalah ide-ide yang dibuang cukup cepat sehingga mereka tidak pernah membuatnya menjadi apa pun selain bentuk konsep. Jika ide-ide ini dibuang begitu cepat pertama kali, maka mereka mungkin tidak perlu dicatat. Upaya untuk mendiskreditkan mereka begitu sepele sehingga mereka hanya akan didiskreditkan lagi.

Alternatif yang benar-benar sampai pada tahap perhitungan harus disimpan dalam beberapa bentuk. Jika perhitungan atau rencana dilakukan pertama kali, maka sudah ada sesuatu untuk disimpan. Sekalipun idenya terbukti buntu, pekerjaan sudah dilakukan, jadi taruh di file! Selama ini tanggal, itu bisa direferensikan.

Tulis memo (ke file jika tidak ke seseorang khususnya) ketika keputusan dibuat. Ini menghemat waktu di masa depan, tetapi menambahkan langkah ke proses. Ini adalah sesuatu untuk dikerjakan bersama dengan peningkatan dokumentasi pada umumnya.

Terakhir, kencani semuanya! Cobalah untuk bekerja dengan sistem yang sudah ada untuk menyimpan catatan akhir, cukup tambahkan tanggal untuk semuanya. Bahkan jika metode organisasi lainnya gagal, urutan alternatif dapat dibangun kembali menggunakan tanggal pada item.

Berikut ini adalah tiga metode umum bagaimana barang putih, barang-barang konsumsi, dan manufaktur OEM yang saya kaitkan dengan gagasan dokumen.

$t+1$

Ulasan desain (NPD - Pengembangan Produk Baru)
Desain meninjau proses bagus lainnya yang dapat membantu mendokumentasikan keputusan desain teknik. Dokumentasi ini cenderung lebih teknis, ide-ide yang ditolak cenderung tidak didokumentasikan dengan baik. Di sebagian besar organisasi, ulasan desain adalah bagian dari model gerbang fase .

Dokumentasi ide Back end (In atau close production)
Saya menemukan organisasi menggunakan sistem manajemen perubahan yang ada untuk mendokumentasikan ide-ide baru. Dalam sistem ini, sang insinyur mengusulkan gagasan itu dalam dokumen sederhana atau halaman. Idenya ditinjau dan diterima atau disimpan untuk masa depan. Organisasi khusus ini menggunakan SAP untuk manajemen perubahan, sehingga sistem kurang sesuai untuk pencarian basis teknologi tetapi berhasil baik bagi mereka.

Singkatnya, sebagian besar ide disimpan karena alasan berikut

• Kurangnya sumber daya keuangan untuk melaksanakan ide / saran
• Kurangnya sumber daya manusia untuk melaksanakan ide / saran
• Tidak cocok dengan rencana proyek saat ini
• Pasar belum siap untuk merangkul teknologi baru

Oleh karena itu ide jalur bagus, karena ketika hambatan di atas diselesaikan ide-ide menjadi solusi realistis.

Referensi:

• Ubah manajemen
• Ulasan desain
• Model fase-gerbang

Yang lain telah membuat banyak komentar bagus tentang dokumentasi secara umum, tetapi saya ingin menyarankan kelas perangkat lunak tertentu yang akan sangat membantu.

Saya menemukan perangkat lunak kontrol versi menjadi sangat baik untuk masalah semacam ini. Sayangnya, ini tidak terlalu umum di luar pengembangan perangkat lunak, tetapi ini hanya masalah waktu sebelum berkembang di bidang lain.

Berikut ini sebuah contoh: Grup riset saya memiliki repositori Subversion yang kebanyakan orang gunakan (Perangkat lunak alternatif populer adalah git ). Menggunakan kontrol versi membantu memastikan kelangsungan proyek penelitian setelah seseorang pergi, karena sebagian besar file yang relevan dengan proyek ada di sana, bersama dengan log terperinci tentang pekerjaan apa yang mereka lakukan pada jam berapa, dan (jika mereka melakukannya dengan benar), alasan. Saya akan menguraikan.

Katakanlah Anda memiliki folder di komputer Anda yang berisi semua file

Semuanya secara otomatis bertanggal saat dilakukan (istilah kontrol versi untuk apa yang orang lain sebut "mengunggah"). Pesan komit bertindak sebagai memo singkat (seperti yang disarankan Mahendra Gunawardena, Anda mungkin ingin memo yang lebih panjang dan lebih resmi untuk keputusan yang lebih besar). Anda menjelaskan perubahan pada file proyek, katakan "Kami memutuskan bahwa pendekatan X tidak layak. Kami akan mencoba Y sebagai gantinya. Menghapus file yang terkait dengan pendekatan X dan membuat model CAD baru untuk pendekatan Y."

Kemudian, nanti, jika Anda memutuskan bahwa pendekatan X sebenarnya adalah hal yang benar dan Anda ingin menggali file yang dihapus, itu tidak sulit. Anda dapat memutar kembali bagian mana pun ke versi yang lebih lama dengan mudah dan melanjutkan dari sana.

Ada beberapa manfaat tambahan untuk pendekatan ini. Pertama, itu membuat berbagi file dengan orang lain cukup mudah. Mereka hanya memeriksa repositori (istilah kontrol versi yang bisa berarti versi saat ini, atau semua versi) dan kemudian memperbaruinya secara berkala (ada perintah untuk melakukan itu). Pada dasarnya, semua orang disinkronkan. Kedua, Anda bisa mendapatkan cadangan (versi lama) untuk dasarnya gratis. Dengan itu, ini tidak berarti Anda tidak perlu menyimpan cadangan normal, hanya saja Anda memiliki pilihan lain untuk memulihkan file yang hilang secara tidak sengaja. Saya sangat merekomendasikan untuk mencadangkan seluruh repositori juga.