Hubungkan permintaan, revisi terdampak, peninjauan, dan implementasi. Ketahui apa yang siap diubah dan apa yang masih harus dikerjakan sebelum produksi menggunakannya.
Masuk untuk menjelajahi contoh di Jodoo. Layar menampilkan catatan manufaktur fiktif.
Software manajemen perubahan rekayasa menghubungkan usulan perubahan produk atau proses dengan peninjauan, pekerjaan implementasi, dan catatan rilisnya. Bagi tim manufaktur, pertanyaan praktisnya adalah apakah pembelian, engineering, dan produksi sama-sama mengetahui apa yang berubah, apa yang masih terhambat, dan revisi mana yang harus digunakan.
Sebuah produsen ingin mengkualifikasi pemasok alternatif untuk bracket. Engineering harus menilai revisi bracket yang diusulkan, pembelian harus memutuskan penanganan 40 bracket yang ada, dan manufaktur harus menangani 12 unit yang sedang dikerjakan. Instruksi perakitan juga perlu diubah.
Satu status persetujuan berwarna hijau tidak dapat menjawab semua pertanyaan itu. Tim perlu menjaga agar usulan, ruang lingkup per item, keputusan fungsional, dan pekerjaan implementasi tetap saling terhubung tanpa kehilangan maknanya masing-masing.
Contoh Jodoo menunjukkan perbedaan itu dalam catatan yang dapat digunakan: perubahan pemasok masih dinilai; perubahan gambar lain sudah diotorisasi tetapi terhambat pekerjaan inspeksi; dan perubahan instruksi telah menyelesaikan rilis yang ditinjau.
| Keputusan | Hal yang ditinjau tim | Hal yang diizinkan keputusan |
|---|---|---|
| Terima permintaan | Item dan revisi saat ini, masalah, perubahan yang diusulkan, serta bukti. | Siapkan perintah perubahan. Produksi belum diizinkan beralih. |
| Otorisasi perintah | Item terdampak, penilaian dampak, penanganan stok dan WIP, serta ruang lingkup implementasi. | Mulai pekerjaan implementasi yang disetujui. Revisi saat ini tetap dipisahkan. |
| Verifikasi implementasi | Tindakan yang telah selesai, buktinya, dan pekerjaan kritis rilis yang masih tersisa. | Keluarkan tindakan tersebut dari jumlah pekerjaan kritis yang masih terbuka. |
| Konfirmasikan rilis | Item terdampak, prasyarat yang selesai, dan batas berlaku yang sebenarnya. | Perbarui item terkendali yang tepat dan pertahankan riwayat dari revisi asal hingga revisi yang dirilis. |
Peninjau menerima tugas yang diberikan dan dapat mengembalikan pekerjaan untuk diperbaiki. Pemohon menyediakan usulan; peninjau yang ditugaskan mengambil keputusan. Tetapkan tanggung jawab dan aturan akses tersebut untuk tim sebelum menggunakan App pada perubahan nyata.
Bandingkan revisi asal dan usulan untuk setiap item. Bracket dan instruksi perakitan dapat berada dalam satu perintah tanpa berbagi nomor revisi atau kehilangan riwayat rilis masing-masing.
Lihat tindakan kritis, penanggung jawab, tenggat, dan hasil verifikasi. Perubahan gambar yang telah diotorisasi tetap menunjukkan pekerjaan terbuka ketika inspeksi unit pertama belum dapat diselesaikan.
Lihat bersama perintah yang sedang disiapkan, peninjauan dampak yang belum selesai, dan item yang telah dirilis. Buka catatan terkait untuk menemukan keputusan atau bukti di balik setiap angka.
Pergantian pemasok membutuhkan pemasok usulan dan bukti kualifikasi. Perubahan proses produksi membutuhkan operasi yang terdampak. Administrator yang berwenang dapat menyesuaikan kolom bersyarat ini tanpa mengubah setiap permintaan menjadi kuesioner umum yang panjang.
Jaga bukti teknis tetap spesifik: catatan gambar, hasil inspeksi, atau instruksi terkendali dapat ditautkan ke perubahan yang memerlukannya, bukan dilampirkan pada tugas yang tidak terkait.
Tambahkan fungsi peninjauan yang diperlukan kategori, ubah penerima tugas, atau buat tampilan untuk pekerjaan implementasi yang terlambat di suatu pabrik. Formulir, catatan terhubung, tugas peninjauan, dan dasbor Jodoo dapat dikonfigurasi sesuai prosedur tim.
Perubahan proses tetap perlu diuji. Periksa catatan yang sudah ada, tugas yang dikembalikan, perhitungan, dan aturan akses sebelum menerapkan pengaturan baru pada pekerjaan nyata.
Permintaan dan peninjauan tersebar di berbagai file dan pesan; tim membutuhkan ruang lingkup per item yang jelas serta tindak lanjut implementasi; dan administrator bisnis perlu menyesuaikan proses ketika produk, pemasok, atau tanggung jawab berubah.
Contoh ini menyediakan titik awal praktis dengan tujuh formulir terhubung dan langkah peninjauan bawaan. Mulailah dengan satu perubahan terkendali dan konfigurasikan tanggung jawab nyata tim.
Hubungan CAD bawaan, penandaan perubahan BOM, konfigurasi produk, atau kontrol data produk skala perusahaan merupakan kebutuhan utama. App ini bukan repositori CAD, mesin rilis atomik banyak item, atau solusi tanda tangan teregulasi yang telah divalidasi.
Bandingkan software koordinasi dan software perubahan rekayasa khusus sebelum memilih sistem yang akan memiliki revisi produk Anda.
Catat alasan perubahan sebelum berkomitmen pada implementasi.
Rencanakan revisi terdampak, stok yang ada, dan peralihan produksi.
Sepakati tanggung jawab dan keputusan rilis di seluruh proses.
Sebelum menerapkan rilis, contoh ini memeriksa apakah item masih aktif dan revisi saat ini masih sama dengan revisi awal perubahan. Jika tidak cocok, rilis tersebut tidak dapat mengubah item. Tim engineering harus menilai ulang ruang lingkup yang terdampak; pemeriksaan ini bukan pengganti pengelolaan konfigurasi BOM atau CAD untuk perubahan yang berjalan bersamaan.
Bisa. Tambahkan satu catatan item terdampak untuk setiap item. Masing-masing catatan menyimpan revisi asal, revisi usulan, disposisi, dan riwayat rilisnya sendiri. Contoh perubahan pemasok mencakup sebuah bracket beserta instruksi perakitannya; keduanya tidak digabungkan ke dalam satu kolom revisi.
Gunakan untuk koordinasi yang dibutuhkan tim, tetapi sepakati sistem mana yang menjadi pemilik data produk yang telah disetujui dan data persediaan. Contoh ini tidak melakukan sinkronisasi dengan PLM atau mencatat transaksi ke ERP. Integrasi memerlukan pengenal yang jelas, aturan akses, penanganan kesalahan, dan rekonsiliasi sebelum salah satu sistem dijadikan sumber data utama.
Administrator bisnis yang berwenang dapat mengubah pilihan formulir, kolom bersyarat, penugasan peninjauan, dan tampilan operasional di Jodoo. Misalnya, perubahan pemasok dapat meminta bukti kualifikasi, sedangkan perubahan proses produksi menanyakan operasi mana yang terdampak. Uji aturan dan izin yang telah diubah sebelum digunakan untuk perubahan nyata.
Tidak. Tugas peninjauan bawaan dan keputusan yang tercatat bukan berarti sistem tanda tangan elektroniknya telah divalidasi. Nilai kewajiban regulasi, pendekatan validasi, dan kontrol yang diperlukan secara terpisah. Contoh ini dimaksudkan untuk memperagakan koordinasi perubahan rekayasa.
Buka tampilan kesiapan, periksa penilaian pembelian yang tertunda, lalu bandingkan dengan perubahan gambar yang telah diotorisasi tetapi masih terhambat. Gunakan perbedaan tersebut untuk menentukan informasi yang perlu dilihat tim.
