Process Safety Tips of the Week: Pre-Start Up Safety Review (PSSR) Practice
PSSR sederhananya adalah verifikasi formal untuk memastikan bahwa aspek yang penting/critical untuk menjaga integritas peralatan dan operasi sudah siap untuk digunakan sebelum energi dan material berbahaya dialirkan kedalam peralatan proses.
Elemen PSM ini penting karena sebelum Startup, peralatan proses belum menjadi sumber Major Hazard. Setelah di-energize dan dimasukkan/dialirkan material berbahaya baru ia menjadi Major Hazard Facility. Umumnya PSSR diwajibkan untuk fasilitas yang baru, atau mengalami modifikasi cukup signifikan. Tolak ukur modifikasi signifikan ini adalah apabila modifikasi tersebut merubah Process Safety Information dari operasi dan fasilitas yang bersangkutan (merubah proses, merubah material yang digunakan, disimpan, diolah atau dialirkan dan merubah peralatan).
Aspek yang perlu diverifikasi setidaknya mencakup 3 hal, yang dapat disingkat dengan 3P:
– Plant (memastikan peralatan yang sudah terpasang sudah sesuai desain, dan desain sudah sesuai spesifikasi; termasuk aspek keselamatan proses dari fasilitas tersebut)
– People (tenaga Kerja yang berinteraksi mengoperasikan dan memelihara peralatan tersedia dalam Jumlah yang cukup dan memiliki kompetensi yang diperlukan)
– Procedure/Paper (sistem manajemen operasi, izin operasi, sistem PSM sudah terimplementasi termasuk memastikan bahwa PHA (HAZOP, HAZID, dsb.) sudah dilakukan dan rekomendasinya diimplementasikan. Prosedur operasi dan pemeliharan sudah dibuat, disetujui, dikomuniasikan dan pekerja sudah dianggap kompeten dalam menggunakannya)
Ada beberapa diskusi menarik dalam training ini yang mungkin cukup berharga untuk didiskusikan juga di sini sebagai tips mengimplementasikan PSSR:
Q1 : Apakah PSSR harus selalu dilakukan oleh tim besar, meliputi semua disiplin engineering?
A1: Tidak. PSSR, seperti element PSM lain bersifat Risk-Based dan Performance-Based.
Risk-Based artinya kedalaman verifikasi dan besar tim yang melakukannya disesuaikan dengan risiko yang terlibat dalam startup dan fasilitas yang bersangkutan. Fasilitas dengan modifikasi sederhana mungkin cukup diverifikasi dengan tim kecil yang kompeten sesuai dengan aspek modifikasinya. Fasilitas greenfield besar, sebaliknya, memerlukan kontribusi dari tim lebih besar untuk memastikan berbagai disiplin yang lengkap mengecek aspek-aspek terkait.
Performance-Based artinya standard dan code tidak menspesifikasikan secara prescriptive bagaimana cara kita melakukan PSSR. Masing-masing operator diminta mendesain proses PSSR-nya untuk mencapai tujuan yang diminta, yaitu verifikasi formal untuk memastikan peralatan dan fasilitas bisa di-Startup dan dioperasikan dengan aman.
Q2: Kebanyakan referensi (buku, guidelines, dsb.) memberikan PSSR checklist dengan volume yang sangat besar. Kebanyakan melibatkan verifikasi lebih dari ratusan item yang harus di-check. Apakah memang PSSR harus mengecek sedemikian banyak item?
A2: Jawabannya Kembali ke sifat PSSR yang Performance-Based. PSSR Team Lead dan timnya berhak untuk mendesain checklist yang akan mereka akan gunakan dengan cara menyesuaikannya dengan cakupan modifikasi dan fasilitas yang akan di-startup. Yang perlu dihindari adalah membuat checklist Panjang dengan ribuan item untuk dicek sehingga pengguna checklist merasa tools ini tidak fit-for-purpose. Dalam Bahasa kerennya mendorong terjadinya “Checklist Fatigue”.
Checklist harusnya menjadi referensi dan standar. Sebagai referensi dan standar pengguna tetap harus diberikan sedikit ruang untuk bermanuver selama ekspektasi checklist tersebut terpenuhi. Artinya, checklist diberikan sebagai standar lengkap yang dapat diaplikasikan pada kasus yang paling sering atau paling mungkin terjadi. Checklist juga biasanya didesain untuk aplikasi yang memerlukan kedalaman verifikasi paling dalam. Namun, tim yang menggunakannya seharusnya tidak dipaksa untuk mengikuti cheklist tersebut secara eksplist item demi item. Inilah salah satu aplikasi dari filosofi performance-based tersebut.
Ketika sebuah praktik, prosedur atau tools dirasa tidak fit-for-purpose, bisa terjadi erosi atas standar pelaksanaan penggunaanya. Pekerja kemudian cenderung menghindari untuk ditunjuk atau terlibat menjadi tim PSSR karena membayangkan beban mengisi checklist yang harus dilakukan. Kalaupun menjadi bagian dari proses ini, banyak yang akan melakukan shortcut/jalan pintas. Pengisian checklist verifikasi dilakukan seadanya hanya untuk menyelesaikan checklist yang berjumlah masif tersebut tanpa melihat kualitas verifikasinya.
Q3: Apakah semua temuan PSSR harus diselesaikan sebelum start up?
A3: Umumnya temuan PSSR dibagi menjadi tiga:
– Temuan yang harus diselesaikan sebelum Startup (Category A)
– Temuan yang harus diselesaikan setelah Startup namun sebelum Fasilitas di-handover secara formal kepada tim operasi (Category B)
– Temuan yang bersifat continuous improvement yang bisa disepakati penyelesaianya setelah handover fasilitas tersebut (Category C)
Dalam prosesnya pun, temuan Category A (atau apapun namanya di operasi masing-masing) ini tidak rigid. Bisa jadi tim PSSR menyepakati dengan tim fasilitas dan projek untuk menurunkan temuan Category A menjadi Category B. Namun penurunan ini dilakukan dengan syarat sebuah rekomendasi penyelesaian temporer lain dimasukkan sebagai temuan Category A untuk memetigasi sementara risiko yang teridentifikasi sampai tim projek dan operasi dapat menyelesaikan solusi permanennya. Solusi permanennya dijadikan temuan Category B.
Intinya tim projek dan operasi memiliki tiga opsi dalam menangani temuan yang diberikan tim PSSR:
– Mengimplementasikan rekomendasi sesuai apa yang ditulis oleh tim PSSR (adopt exactly as stated)
– Mengimplementasikan cara lain dengan tujuan yang sama dan dengan tingkat penurunan risiko yang sama dengan apa yang ditulis oleh tim PSSR (adopt the principle)
– Mengajukan solusi temporer sambil menyelesaikan solusi permanen yang mungkin membutuhkan waktu karena memerlukan proses desain, pembelian, fabrikasi, dan konstruksi yang memakan waktu. Dalam kasus ini temuan Category B untuk menyelesaikan solusi permanen harus didafatarkan dalam daftar temuan agar tetap diimplementasikan (adopt temporary solution while completing permanent solution).
“Written by Adam Maulana Musthafa, ST, MT, IPM, CFSP, CCPSC”
Technical Director LebSolution Indonesia
