เนื่องจากปัจจุบันเริ่มมีการพูดถึงการจัดทำเอกสาร Safety Life-cycle (SLC) ในระหว่างการทำโครงการอยู่บ่อยครั้ง และผู้เขียนบทความพบว่า ในอุตสาหกรรมยังมีความเข้าใจที่ผิดเกี่ยวกับวัตถุประสงค์และการจัดเตรียมเอกสารที่เกี่ยวข้องในระหว่างโครงการอยู่บ้าง จนนำไปสู่การจัดทำเอกสารที่มากเกินความจำเป็นและยังสร้างความสับสนและขัดแย้งในเรื่องการจัดการระบบ SIS ของภายในบริษัทที่ทำโครงการเองอีกด้วย บทความนี้จึงขอเล่าเรื่องของ SLC คร่าวๆ พอให้ได้เป็นแนวคิดกันนะครับ
Safety Life-cycle (SLC) คือ กรอบการจัดการของระบบ SIS ที่ครอบคลุมเริ่มต้นตั้งแต่ก่อนการออกแบบ ออกแบบ นำไปใช้ แก้ไขเปลี่ยนแปลง จนกระทั่งถึงการยกเลิกการใช้งานระบบ ซึ่งสามารถแบ่งออกเป็นสองส่วนใหญ่ๆ คือ ส่วนของระบบการบริหารจัดการ และส่วนของขั้นตอนวิธีการปฏิบัติ
1) ส่วนของระบบบริหารจัดการ ได้แก่
– Management of Functional Safety and Functional Safety Assessment and Auditing
– Safety Lifecycle Structure and Planning
– Verification
หรือก็คือในส่วนของบล๊อคสีส้ม ที่ประกบด้านข้างของ Model นั่นแหละครับ ส่วนนี้จะเป็นเสมือนแผนแม่บทที่ใช้ในการบริหารจัดการระบบ SIS ทั้งหมดในองค์กร (ย้ำว่าทั้งหมดนะครับ ไม่ใช่แค่ในโครงการนั้นๆ) โดยในเนื้อหาก็จะพูดถึง การกระจายอำนาจการบริหารไปยังส่วนงานต่างๆ การบริหารจัดการระบบ SIS ทั่วไป การตรวจประเมิน การติดตามผลต่างๆ หลักๆก็คือการวางระบบควบคุมการทำงานนั่นแหละครับ ซึ่งเอกสารที่เกี่ยวข้องกับส่วนนี้ ควรจะมีฉบับเดียว และถูกวางในระดับนโยบาย คล้ายๆ Quality Manual ของบริษัทครับ ดังนั้น เอกสารในส่วนนี้จึงไม่ควรถูกจัดทำซ้ำๆแบบ โครงการต่อโครงการ
2) ส่วนของขั้นตอนวิธีการปฏิบัติ ได้แก่
– Analysis
– Implementation
– Operation
ในส่วนนี้หล่ะครับ ที่มักจะเกี่ยวข้องโดยตรงในระหว่างทำโครงการ เริ่มต้นที่ Analysis ที่ต้องทำการประเมินความเสี่ยงโดย วิธีทั่วไป นิยมมากๆ ก็ Hazard and Operability Study (HAZOP) แล้วมักต่อด้วย Risk Graph หรือไม่ก็ Layers of Protection Analysis (LOPA) ถ้ายังไม่ละเอียดพอก็อาจจะยกมาทำให้ละเอียดขึ้นอีกครั้งใน SIL Study ก็ได้ครับ ซึ่งผลลัพธ์จะได้ออกมาเป็นค่า SIL level ของแต่ละ Safety Function ซึ่งในท้ายที่สุดแล้วจะต้องมีการออกแบบระบบ SIS ให้ได้ตามค่า SIL ที่ต้องการ และออกเอกสารตัวหนึ่งที่ชื่อว่า Safety Requirements Specification (SRS) ออกมา เอกสารตัวนี้จะใช้เพื่อDevelop พวก Instrument Datasheet, SIS functional design spec., หรือ Material Requirements ต่างๆ ให้ Vendors จัดของให้ตามที่เราต้องการครับ จากนั้นในขั้นตอน Implementation ก็ทำงานๆๆๆ ครับ มาจบตรงที่ Function test เรียบร้อย ใช้งานได้ พร้อมส่งมอบให้ฝ่ายผลิต หลังจากนั้นในช่วง Operation ก็จะถูกควบคุมโดย Work Procedure ของการทำงานทั่วไปแล้วครับ เช่น จะซ้อมยังไง จะทดสอบเมื่อไหร่ ขออนุญาติใครก่อนทำงาน จะแก้ไขดัดแปลงอย่างไร (หลักๆก็จะย้อนไปหา ข้อมูลใน SRS แหละครับอะไรที่ไม่มีบอก หรือเปลี่ยนแปลงจนทำให้ SRS ไม่ทันสมัย ก็ย้อนไปทำขั้นตอน Analysis ใหม่ หรือขั้นตอนอื่นๆ ที่เห็นสมควร)
ดังนั้น เอกสารที่จำเป็นต้องทำแบบ โครงการต่อโครงการ ก็จะมีแค่เอกสาร SRS ที่รวบรวมข้อมูลในขั้นตอน Analysis (SIL classification และ SIF Verification) รวมถึงผลการทำ Function Test (Safety Validation) ก่อนการใช้งานจริง เท่านั้น ครับ
ปล. พวก Spec, instruction manual หรือ เอกสารที่เกี่ยวข้องกับระบบ SIS หรือ อุปกรณ์ต่างๆ ไม่พูดถึงนะครับ เพราะเป็นเอกสารที่ต้องมีในการทำโครงการอยู่แล้ว
ขอบคุณ ภาพประกอบจากบริษัท Emerson Process Management ครับ
