Delapan persepsi yang salah tentang manajemen perubahan

Setiap kali saya menyebutkan manajemen perubahan kepada personel pabrik, saya biasanya mendapatkan salah satu dari beberapa tanggapan yang dapat diprediksi. Yang berpengetahuan akan mengutip peraturan OSHA 1910.119(a)(2) dan memberi tahu saya bahwa itu bukan "proses tertutup", jadi itu tidak berlaku untuk mereka - umumnya dengan napas lega. Tanggapan lain yang sering muncul adalah:“Kami memiliki prosedur manajemen gambar, tetapi kami sangat tertinggal sehingga membutuhkan waktu bertahun-tahun dan sumber daya yang tidak perlu kami kejar.” Yang lain masih akan memberi tahu saya bahwa mereka memiliki prosedur yang sangat baik bagi manajer mereka untuk menyetujui proyek-proyek kecil dan perubahan. Dan, beberapa akan dengan malu-malu berpikir tentang uang receh yang memenuhi baki abu mobil mereka.

Jadi, apa itu manajemen perubahan (MOC)? Kembali ke sumbernya, OSHA 1910.119(l)(1) menetapkan persyaratan untuk MOC sebagai:“Pemberi kerja harus menetapkan dan menerapkan prosedur tertulis untuk mengelola perubahan (kecuali untuk “penggantian barang”) untuk memproses bahan kimia, teknologi, peralatan dan Prosedur; dan, perubahan fasilitas yang memengaruhi proses yang tercakup.”

Deskripsi singkat itu mencakup banyak wilayah, tetapi karena diumumkan semata-mata untuk meningkatkan keamanan proses, itu membatasi penerapan hukum untuk "proses yang tercakup". Pembaca yang fasilitasnya memenuhi persyaratan OSHA dari "proses tercakup" sangat mengetahui persyaratan terperinci dari MOC. Mereka harus atau mereka tidak akan tetap beroperasi. Dan semoga Anda semua tahu bahwa banyak dari kecelakaan industri terburuk dalam sejarah baru-baru ini memiliki akar penyebab kegagalan proses MOC. Beberapa sumber menunjukkan bahwa sebanyak 80 persen dari kecelakaan besar yang serius di industri terkait dengan perubahan yang tidak terkendali. Dengan demikian, orang dapat menganggap MOC sebagai semacam asuransi jiwa yang terbayar dengan mencegah kecelakaan.

Tapi artikel ini tidak fokus pada seluk-beluk MOC untuk proses tertutup. Dan, itu tidak semata-mata diarahkan pada keselamatan. Lalu mengapa kita membahas MOC jika tidak "diperlukan" untuk industri Anda? Singkatnya, itu karena setiap bisnis, terlepas dari persyaratan hukum, perlu mengendalikan potensi kerugian. Dan MOC, yang diterapkan dengan tepat, adalah proses pencegahan kerugian yang sangat baik dan hemat biaya untuk hampir semua bisnis. Ini adalah proses pelengkap yang sempurna untuk proses eliminasi kerugian Anda. Dan, kita semua juga ingin aman dan ramah lingkungan, bukan?

Harap dicatat bahwa alamat MOC hanya mengubah hal-hal yang ada saat ini. Desain proses atau fasilitas baru adalah masalah lain sama sekali. Dan, kita harus berasumsi untuk tujuan diskusi MOC bahwa tingkat kinerja sistem yang ada, jika tidak memadai, setidaknya memiliki kelebihan dan kekurangan yang sudah dikenal dan diketahui.

Jadi, apa MOC dalam istilah non-peraturan, dan untuk siapa sebenarnya itu berlaku? Mari bekerja dengan definisi sederhana ini:MOC adalah proses untuk mencegah atau mengurangi kerugian bisnis – termasuk degradasi keselamatan, kesehatan, atau lingkungan – sebagai akibat dari perubahan yang dilakukan pada cara Anda membangun, mengoperasikan, mengelola, atau memperbaiki fasilitas atau proses Anda. Selain persyaratan peraturan, tidak ada bisnis yang ingin tetap kompetitif yang mampu untuk tidak memiliki proses MOC yang sesuai. Singkatnya, MOC masuk akal untuk keamanan dan masuk akal secara finansial. Apakah proses MOC masuk akal untuk bisnis Anda?

Apa itu 'perubahan'?
“Bagian tersulit dari manajemen perubahan adalah mengenali perubahan.” Titik awal yang paling penting untuk program ini adalah dengan jelas mendefinisikan bagi organisasi apa yang merupakan "perubahan" yang ingin Anda kelola. Atau lebih sederhana, perubahan apa yang termasuk dalam proses MOC dan perubahan seperti apa yang tidak? Kurangnya definisi yang jelas secara efektif melumpuhkan efektivitas program MOC, mengundang kelumpuhan analisis yang tidak perlu dan menciptakan celah bagi mereka yang ingin melewati proses tersebut.

Ada banyak definisi perubahan dari berbagai sumber. Ini adalah tanggung jawab kepemimpinan situs untuk mendefinisikan perubahan dalam istilah yang konsisten dengan kepentingan bisnis dan preseden peraturan apa pun. Risiko apa yang ingin Anda kendalikan dan perubahan seperti apa, jika tidak dikendalikan, yang meningkatkan risiko tersebut? Hanya dengan demikian kegiatan-kegiatan yang mungkin secara wajar dapat didefinisikan sebagai “perubahan” dapat diidentifikasi dengan jelas, dan setelah diidentifikasi harus disampaikan dalam bahasa yang paling sederhana dan lugas.
Meskipun agak berantakan, penggunaan daftar atau tabel contoh seringkali diperlukan untuk menyampaikan poin. Ingatlah bahwa "perubahan" tidak harus terjadi pada perangkat keras untuk memenuhi syarat. Perangkat lunak, prosedur, dan parameter proses adalah contoh perubahan non-perangkat keras yang sering kali harus dikontrol dengan ketat.

Ketika berhadapan dengan perangkat keras, dokumen sumber OSHA 1910 merujuk secara tidak langsung ke perubahan sebagai bukan “Pengganti dalam Jenis” (RIK) dan lebih lanjut mendefinisikan RIK sebagai “pengganti yang memenuhi spesifikasi desain.” RIK umumnya mengacu pada peralatan atau komponen yang identik dalam Bentuk, Kesesuaian dan Fungsi (disebut sebagai F3). Tetapi ada lebih banyak yang harus diubah daripada pendekatan berbasis perangkat keras yang sangat sempit ini. Definisi perubahan OSHA juga mengacu pada teknologi, prosedur dan bahan kimia (lebih luas diartikan sebagai bahan mentah.) Jelas lebih dari sekedar perangkat keras termasuk dalam definisi "perubahan". Saya telah menemukan bahwa definisi formal terbaik yang digunakan untuk "perubahan" dalam proses MOC ditemukan dalam klarifikasi yang diterbitkan dalam OSHA 3313:"Perubahan adalah perubahan atau penyesuaian pada komponen, variabel, atau properti apa pun dalam sistem yang ada (kecuali yang ada di dalam batasan atau tanggung jawab yang jelas).”

Karena setiap bisnis memiliki area eksposur risiko yang berbeda dan toleransi yang berbeda terhadap konsekuensi yang tidak diinginkan, terserah kepada setiap bisnis untuk menilai risiko dan menentukan toleransinya terhadap perubahan yang tidak terkendali. Beberapa (tetapi tidak berarti semua termasuk) contoh jenis perubahan yang mungkin ingin dikelola oleh bisnis adalah:

• Penambahan peralatan proses baru atau sistem bisnis penting (termasuk perangkat lunak)
• Penggantian peralatan proses atau suku cadang “tidak dalam bentuk barang”
• Modifikasi atau penambahan kecil pada peralatan proses
• Modifikasi atau penambahan kecil pada sistem bisnis penting (prosedur atau perangkat lunak)
• Modifikasi atau penambahan kecil pada infrastruktur/peralatan non-proses
• Perubahan pada kontrol proses dan/atau instrumentasi (termasuk strategi kontrol)
• Perubahan spesifikasi atau sumber MRO teknis
• Perubahan batas operasi parameter proses kritis (di luar rentang yang ditentukan dalam prosedur operasi standar [SOP])
• Perubahan pada sistem keselamatan (interlock, shutdown, pemadaman kebakaran atau ledakan, dll.)
• Revisi prosedur operasi standar (termasuk prosedur darurat)
• Perubahan struktur organisasi tingkat situs
• Perubahan pada prosedur pemeliharaan
• Perubahan dalam spesifikasi atau sumber bahan baku/komponen
• Perubahan atau sambungan baru ke sistem utilitas (udara, listrik, gas, air, uap, dll.).
• Perubahan atau koneksi baru ke jaringan data penting
• Perubahan pada prosedur QA atau peralatan uji kritis

Beberapa jam brainstorming "bagaimana jika" berkualitas oleh tim multi-disiplin di awal desain proses untuk mengembangkan definisi dan contoh yang tepat untuk bisnis Anda akan membuahkan hasil yang besar.

Bagaimana dengan perubahan 'sementara'?
Ingatlah konsep penting ini untuk diterapkan ketika menerapkan MOC:Sama seperti tidak ada yang permanen di dunia ini seperti pajak sementara, tidak ada perubahan yang lebih permanen daripada "perubahan sementara" yang lolos dari proses MOC. Pengalaman menunjukkan bahwa hanya ada perubahan permanen yang dimaksudkan untuk sementara sampai dikembalikan ke kondisi semula. Dari semua perubahan tak terkendali yang terjadi, perubahan "sementara" adalah yang paling merusak dan paling sering menyebabkan kecelakaan dan insiden. Dengan demikian, perubahan “sementara” dari sistem yang dikendalikan tidak boleh dikecualikan dari proses MOC.

Jadi, apa yang harus saya lakukan untuk menghadapi perubahan sementara yang harus dilakukan untuk menjalankan bisnis rutin, seperti interlock bypass untuk melakukan perawatan berkala? Jika memang benar-benar rutin, maka yang Anda miliki adalah keadaan tetap penyimpangan periodik dari SOP. Dan cara yang tepat untuk mengatasinya adalah dengan memperlakukan situasi sebagai perubahan permanen, memasukkannya ke dalam prosedur yang disetujui dengan pengamanan yang sesuai. Jika sesuatu dimaksudkan sebagai perubahan sementara yang tidak rutin, perlakukan itu sebagai perubahan. OSHA 3133 dalam klarifikasi mengatakan:"Prosedur MOC harus memastikan bahwa peralatan dan prosedur dikembalikan ke kondisi semula pada akhir perubahan sementara." Sejarah dan kehati-hatian akan menyarankan bahwa perubahan "sementara" harus dikelola sebagai "permanen" dengan perhatian khusus pada prosedur MOC karena mereka menghadirkan risiko tertinggi bagi bisnis Anda.

Delapan Kesalahpahaman Umum tentang MOC
1) “Tapi saya tidak melakukan modifikasi yang sebenarnya. Saya hanya membuatnya sedikit lebih baik.”
Jika Anda tidak meninggalkan bagian/peralatan/sistem bisnis persis seperti sebelum memulai pekerjaan (tentu saja tidak ada kerusakan yang menjadi objek perbaikan), maka Anda telah melakukan perubahan . Apakah perubahan tersebut termasuk dalam lingkup proses MOC Anda ditentukan oleh kriteria yang ditetapkan dalam prosedur Anda. Pendekatan standar yang harus diambil adalah mengasumsikan bahwa setiap perubahan dalam konfigurasi, bentuk, kesesuaian, fungsi, bahan atau prosedur tercakup dalam MOC sampai pemeriksaan kriteria dalam prosedur membuktikan sebaliknya.

Kedua setelah “perubahan sementara” yang tidak terkendali, perbaikan kecil dengan niat baik menduduki peringkat sebagai penyebab insiden terbesar berikutnya yang termasuk dalam kategori kegagalan MOC. Tanpa evaluasi menyeluruh dari konteks dan lingkungan operasi total, siapa yang mengatakan bahwa "lebih baik" dalam satu hal tidak terlalu jauh, jauh lebih buruk dalam hal lain? Obat yang sama yang diberikan kepada satu pasien bisa menjadi obat yang ampuh; ke yang lain, itu mungkin racun yang mematikan. Hal yang sama berlaku untuk "perbaikan" kecil yang bermaksud baik tetapi tidak terkendali, terutama penggantian bahan yang sangat berisiko. Ajari personel Anda di semua tingkatan untuk menyadari dan menghindari perangkap umum ini dan kemudian menegakkannya dengan ketat. Tidak ada orang yang suka mendisiplinkan orang yang melanggar aturan, apalagi jika dilakukan dengan semangat perbaikan. Tapi, jauh lebih buruk untuk memberi tahu keluarga bahwa seseorang tidak akan pulang malam ini.

2) “Saya sangat ketinggalan sehingga saya tidak bisa mulai melakukan MOC. Saya tidak akan pernah bisa mengejar semua gambar yang belum direvisi itu.”
Kontrol dokumen adalah proses yang melengkapi proses MOC yang dirancang dengan baik, dan sering kali menjadi hal pertama yang dipikirkan orang ketika Anda menyebut MOC. Kebutuhan untuk memperbarui dokumen tentu saja merupakan hasil yang sering terjadi dari MOC dan diperlukan untuk integritas jangka panjang dari proses dan fasilitas Anda, tetapi ini bukan MOC. Ini hanyalah hasil yang sering terjadi.

Seringkali ketika menerapkan MOC dengan proses kontrol dokumen, Anda mewarisi kekacauan yang cukup besar dari mereka yang mendahului Anda:tidak ada gambar, gambar yang tidak akurat, dokumen yang kedaluwarsa .. .sebut saja. Jika situasinya mengerikan, Anda mungkin terpaksa memprioritaskan tindakan korektif Anda – jika ada yang didasarkan pada kekritisan sistem. Beberapa mungkin tidak perlu dan tidak akan pernah diperbaiki. Tentu saja metode untuk memperbaiki informasi penting ketika ditemukan dapat dan harus dengan mudah dimasukkan ke dalam prosedur pengendalian kerja Anda. Tapi jangan menambah tugas dengan melanjutkan kebiasaan buruk.

Anda tidak bisa mengubah apa yang telah terjadi di masa lalu. Jika kasus bisnis ada untuk memperbaiki atau mengurangi kesalahan masa lalu, maka lakukanlah. MOC adalah tentang pencegahan kerugian di masa depan. Jadi satu hal yang dapat dilakukan oleh organisasi mana pun adalah mulai menerapkan MOC sekarang. Hari ini adalah hari untuk berhenti menciptakan lebih banyak masalah untuk hari esok. Sepotong kebijaksanaan rakyat yang ringkas mengatakan:"Jika Anda harus mengisi lubang yang sangat besar, hal pertama yang harus dilakukan adalah berhenti menggali lebih dalam." Hal yang sama berlaku untuk kesenjangan yang diciptakan oleh MOC yang buruk. Berhentilah membesar-besarkan.

3) “Saya tidak punya waktu untuk menunggu evaluasi MOC. Ini darurat!”
Dalam keadaan darurat justru ketika disiplin diri yang dipaksakan oleh proses MOC yang mapan sangat diperlukan. Ketika sebuah pesawat memiliki masalah dalam penerbangan, pilot tidak melakukan hal pertama yang terlintas dalam pikiran. Sebaliknya mereka mengeluarkan daftar periksa dan mereka berpikir, lalu mereka bertindak. Ketika ada “darurat”, Anda juga harus demikian. Apakah "modifikasi kecil" ini untuk memungkinkan penggantian benar-benar akan menghemat banyak waktu henti dibandingkan dengan mendapatkan bagian yang benar? Perubahan kecil sering kali membutuhkan waktu lebih lama dari yang diharapkan.

Bersikaplah realistis dalam evaluasi Anda tentang berapa lama, berapa banyak uang, dan seberapa besar peningkatan risiko yang benar-benar dibutuhkan "pengerjaan cepat" ini. Adalah baik untuk tetap optimis dalam keadaan darurat. Yang terbaik adalah bersiap untuk yang terburuk. Seperti kata pepatah:"Jika Anda berada di perahu bocor jauh ke laut, yang terbaik adalah berdoa ke Surga, tetapi mendayung ke pantai." Apakah risiko terhadap bisnis Anda terkait dengan pintasan "sementara" sepadan dengan penghematan waktu? Dapatkah Anda benar-benar mengendalikan risiko ke tingkat yang dapat diterima dengan "prosedur operasi khusus"?

Laporan kecelakaan menunjukkan bahwa keputusan yang tergesa-gesa, dibuat di bawah tekanan, tanpa evaluasi yang seimbang, telah menjadi akar dari banyak masalah serius . Waktu untuk berpikir secara disiplin bukanlah waktu yang terbuang percuma. Dan jika proses MOC Anda efisien, itu tidak akan terlalu menghambat kemajuan pada kesempatan langka ketika itu benar-benar darurat. Sama seperti ada prosedur untuk mengesahkan dan mengeluarkan perintah kerja darurat bila diperlukan, prosedur MOC yang baik akan memiliki mekanisme untuk menangani keadaan darurat yang sebenarnya. Tetapi mekanisme itu tidak boleh mengabaikan MOC. Jangan biarkan kebijaksanaan selama satu "darurat" membuat Anda siap untuk keadaan darurat kedua yang lebih besar dan lebih serius. Jangan menjinakkan bom hanya untuk menanam ranjau darat.

Apakah Anda sering mengalami kegagalan yang memerlukan solusi untuk mengatasinya, terus-menerus harus melakukan penggantian suku cadang tengah malam untuk memulihkan dari kegagalan yang tidak terduga, atau konstan proses perubahan untuk mengakomodasi komponen yang tidak stabil atau bahan baku? Kemudian, tantangan Anda adalah untuk tidak mengabaikan MOC atau merancang proses MOC yang mendukung anarki. Sebaliknya, Anda harus memfokuskan upaya Anda untuk menghilangkan situasi ini dengan menerapkan proses analisis akar penyebab kegagalan (RCFA) yang efektif dan program pemeliharaan preventif/pemeliharaan prediktif untuk menghilangkan kegagalan kronis. Selanjutnya, fokuslah untuk memperbaiki kekurangan dalam proses MRO Anda untuk memastikan Anda selalu memiliki suku cadang yang tepat. Dan, yang terakhir, Anda harus menstabilkan proses Anda dengan prosedur kerja standar dan program kualifikasi pemasok bahan.

4) “Memerutekan formulir ini untuk mendapatkan persetujuan membutuhkan waktu begitu lama sehingga kami tidak akan pernah bisa menyelesaikan apa pun.”
Proses MOC yang efektif membutuhkan tingkat persetujuan dan komunikasi yang sesuai. Prosedur persetujuan MOC yang dirancang dengan buruk membingungkan kebutuhan untuk diberitahu tentang perubahan setelah itu terjadi dengan kebutuhan untuk menyetujui perubahan sebelum itu terjadi. Tingkat persetujuan yang diperlukan harus sesuai dengan perubahan dan potensi risiko yang terkait dengannya. Mereka juga harus cukup fleksibel sehingga dapat disesuaikan dengan situasi yang dihadapi. Minimalkan jumlah pemberi persetujuan, dan jadikan mereka yang benar. Proses MOC Anda kemudian dapat disederhanakan dengan aman.

5) “Tetapi manajer area saya harus menyetujui dana untuk perubahan.”
Jangan bingung antara otoritas untuk membuat keputusan dengan kepemilikan pengetahuan yang diperlukan untuk membuat keputusan itu. Tidak semua perubahan, dan seringkali yang paling kritis, bahkan melewati persetujuan pendanaan. Seringkali, orang yang paling kompeten untuk mengevaluasi risiko membuat perubahan atau keabsahan teknis dari suatu perubahan bukanlah manajer area tetapi operator, mekanik, supervisor atau insinyur yang paling mengenalnya.

Sekalipun manajer sangat kompeten, jarang ada satu orang yang kompeten dalam semua aspek atau konsekuensi dari perubahan yang diberikan. Dalam proses MOC yang efektif, adalah tanggung jawab manajer untuk memastikan bahwa sumber daya yang ditunjuk yang sesuai terlibat dalam evaluasi yang seimbang dari perubahan yang diusulkan. Kewenangan persetujuan adalah sekunder dari kompetensi untuk mengevaluasi dan tim yang seimbang akan memberikan hasil yang lebih baik secara konsisten daripada bergantung pada satu individu yang cerdas.

6) “Kami adalah gudang / manufaktur ringan / data pusat/fasilitas perbaikan. … Kami tidak memiliki apa pun yang bisa berbahaya.”
Ingat, MOC adalah proses untuk mencegah atau mengurangi semua potensi kerugian bisnis yang ditimbulkan oleh diri sendiri yang terkait dengan perubahan. Ada kerugian lain selain hanya keamanan proses. Merupakan kerugian jika perubahan proses yang tidak terkendali menyebabkan Anda kehilangan pelanggan yang berharga karena produk yang terkontaminasi atau rusak. Merupakan kerugian jika pusat data Anda down dan pemecahan masalah memakan waktu beberapa jam, bukan menit karena gambar listrik tidak mengikuti perubahan. Merupakan kerugian jika penumpuk otomatis mati dan Anda tidak dapat mengirimkan produk karena penggantian suku cadang tengah malam yang memerlukan “modifikasi kecil” menyebabkan satu-satunya suku cadang pengganti yang Anda miliki tidak muat lagi. Merupakan kerugian jika modifikasi yang tidak terdokumentasi pada perangkat lunak kontrol menyebabkan mesin pengujian otomatis Anda gagal ketika patch keamanan terbaru diinstal. Semua ini adalah contoh nyata, dan daftarnya tidak ada habisnya. Meskipun potensi perubahan untuk menciptakan situasi berbahaya di lingkungan Anda kecil, kita semua akan kehilangan sesuatu ketika fasilitas atau proses kita gagal dalam misi utama mereka.

7) “Tapi MOC menang 'tidak menangkap setiap kemungkinan masalah, jadi mengapa melakukannya?”
Anda benar sekali. Terlepas dari upaya terbaik Anda, beberapa masalah akan berlalu tanpa terdeteksi. Tapi berapa banyak yang akan lolos jika Anda tidak melakukan MOC? Manajemen risiko adalah tentang mengubah peluang menjadi lebih menguntungkan Anda. Argumen ini tidak tahan air – tidak lebih dari argumen yang digunakan beberapa orang terhadap kantong udara:“Mereka mungkin menyebar dan menyebabkan kecelakaan, jadi saya mematikannya.” Statistik tidak mendukung pemikiran itu sama seperti mereka mendukung tidak adanya MOC.

Jadi, bagaimana jika Anda melewatkan konsekuensi yang tidak diinginkan? Manfaat tambahan yang berharga dari MOC dalam sistem yang kompleks adalah ketika melakukan RCFA. Jika ada konsekuensi yang merugikan dari suatu perubahan dan penyebabnya tidak segera terlihat, RCFA berjalan lebih cepat jika Anda memiliki daftar semua perubahan yang disengaja yang telah dibuat. Dan waktu itu bisa menjadi uang nyata. Dalam satu kasus, meneliti catatan MOC memotong waktu berminggu-minggu yang diperlukan untuk menemukan akar penyebab serangkaian kegagalan pabrik proses. Dengan $250.000 per hari untuk menghindari kerugian waktu henti, upaya MOC memiliki pengembalian investasi yang cukup baik meskipun tidak mencegah masalah.

8) “Ini hanya perubahan perangkat lunak/prosedur. Bukannya kami sedang mengganti pipa atau semacamnya. Kami tidak perlu menyetujui atau mendokumentasikan.”
Beberapa insiden yang sangat serius dan kerugian yang parah telah terjadi di sejumlah industri karena perubahan perangkat lunak atau prosedur yang tidak tunduk pada MOC. Selain itu, hanya karena dokumen atau kode telah diubah dan mencerminkan perubahan tersebut, tidak berarti bahwa perubahan tersebut didokumentasikan. Saya tahu bahwa komentar dalam kode dan tanda revisi dalam dokumen memungkinkan pencari untuk mencari perubahan. Tetapi ketika masalah tak terduga terjadi karena perangkat lunak atau perubahan prosedur tidak ditinjau secara memadai, lalu apa gunanya?

Apakah Anda memiliki lini produksi yang turun saat Anda mencari mati-matian ribuan baris kode untuk mencari perubahan yang dibuat oleh insinyur kontrol dua bulan sebelum dia pergi untuk pekerjaan lain? Pemrogram dan insinyur kontrol khususnya cenderung "bermain-main" dengan perangkat lunak tanpa memperhatikan MOC. Ini tidak hanya berlaku untuk kontrol proses Anda tetapi juga untuk perangkat lunak sistem bisnis penting Anda. Jika potensi risiko ada dan membenarkannya, maka perlakukan perubahan baris kode tidak berbeda dengan memasang kembali sistem pemutusan keselamatan; itu harus menerima tingkat pengawasan dan kontrol yang sama.

Kesimpulan
Kesimpulannya, proses MOC yang dirancang dengan baik adalah alat pencegahan kerugian yang penting untuk bisnis apa pun. Ini bukan hanya untuk industri berbahaya tertentu. Proses ini berlaku untuk setiap perusahaan yang ingin menghindari kerugian di masa depan akibat perubahan hari ini. MOC tidak harus berlebihan atau terlalu sulit untuk digunakan sehingga menghambat perubahan. Itu tidak dapat dengan mudah mengkompensasi kelalaian masa lalu, hanya mengurangi risiko masa depan Anda. Jadi, waktu untuk mulai mengembangkan dan menerapkan proses MOC yang efektif dan efisien adalah hari ini.

Artikel ini pertama kali muncul di buletin Life Cycle Engineering edisi Juli, RxToday.

Tentang penulis:
Sam McNair adalah konsultan senior di Life Cycle Engineering (LCE). Seorang Insinyur Profesional dan Profesional Pemeliharaan dan Keandalan Bersertifikat, Sam memiliki lebih dari 32 tahun pengalaman di bidang manufaktur terpisah, industri proses kimia, pertambangan, proses mesin, otomatisasi, penerbangan, konstruksi, dan utilitas. Sam berspesialisasi dalam rekayasa keandalan dengan fokus pada integrasi fungsi pemeliharaan dan manufaktur. Anda dapat menghubungi Sam di [email protected]. Untuk informasi lebih lanjut tentang Life Cycle Engineering, kunjungi www.LCE.com.