การผลิตเครื่องจักรเฉพาะงาน: จัดซื้อด้วยหลักฐาน FAT และ SAT

เมื่อโรงงานในประเทศไทยว่าจ้างผลิตเครื่องจักรเฉพาะงาน สิ่งที่ต้องเปรียบเทียบไม่ได้มีเพียงราคาเครื่องและ Cycle time ผู้ซื้อต้องควบคุมหลักฐานตั้งแต่การตีความความต้องการ จุดเชื่อมต่อกับเครื่องเดิม การยืนยันความปลอดภัย การส่งมอบโปรแกรมและ Backup เกณฑ์ FAT และ SAT ไปจนถึงการเปลี่ยนแปลงหลังรับมอบ บทความนี้อธิบายวิธีเลือกผู้ผลิตเครื่องจักรเฉพาะงานและจัดซื้อระบบที่โรงงานเดินเครื่อง กู้คืน และปรับปรุงได้โดยไม่ต้องรับความเสี่ยงที่ไม่มีเอกสารกำกับ

การผลิตเครื่องจักรเฉพาะงานคือการซื้อขีดความสามารถที่ทำซ้ำได้

เครื่องจักรเฉพาะงานคือระบบที่ออกแบบหรือ Integrate สำหรับชิ้นงาน กระบวนการ การตรวจสอบ การลำเลียง หรือการประกอบที่กำหนด แม้ใช้หุ่นยนต์และ Module มาตรฐาน โครงการก็ยังมีลักษณะเฉพาะเมื่อต้องออกแบบ Fixture, Sequence, Control, Safety guard และการเชื่อมต่อกับโรงงานเป็นรายกรณี

คำสั่งซื้อที่ระบุเพียงว่าเป็นเครื่องประกอบอัตโนมัติหนึ่งชุดไม่สามารถกำหนดขีดความสามารถที่ทำซ้ำได้ คู่สัญญาต้องตกลงเรื่องชิ้นงาน เกณฑ์ผ่าน กำลังการผลิต การเปลี่ยนรุ่น สภาวะผิดปกติ หน้าที่ของผู้ปฏิบัติงาน ข้อมูล การบำรุงรักษา การฝึกอบรม ความปลอดภัย และสิ่งส่งมอบ ผลลัพธ์ของโครงการจึงประกอบด้วยสามส่วนที่แยกจากกันไม่ได้

• เครื่องจักร Fixture, Control และ Software ที่ทำงานได้ตามความต้องการ
• บันทึกการทดสอบ งานประเมินความเสี่ยง แบบ และค่ากำหนดที่พิสูจน์ว่าความต้องการได้รับการตอบสนอง
• Baseline หลังส่งมอบที่ช่วยให้กู้คืนและเปลี่ยนแปลงอย่างควบคุมได้เมื่อเกิดเหตุขัดข้อง เพิ่มรุ่นสินค้า หรือเปลี่ยนบุคลากร

กรอบคิดนี้ช่วยให้เห็นว่าใบเสนอราคาที่ดูต่ำยกเว้นอะไรออก และผู้ผลิตรายใดเข้าใจขอบเขตทั้งหมดของโครงการจริง

เริ่มข้อกำหนดเครื่องจักรเฉพาะงานจาก URS

URS หรือ User Requirements Specification อธิบายว่าระบบต้องบรรลุอะไรภายใต้เงื่อนไขใด ไม่ควรรีบกำหนดรายละเอียดการออกแบบทุกจุด หากผู้ซื้อกำหนดผลิตภัณฑ์ กระบวนการ สภาพใช้งาน และเกณฑ์รับมอบก่อน ผู้ผลิตจะเสนอทางเลือกทางเทคนิคและเปิดประเด็นไม่แน่นอนก่อนตั้งราคาได้ดีขึ้น

Checklist สำหรับ URS และ RFQ

ข้อความเช่นจำนวนชิ้นต่อนาทีต้องระบุช่วงวัด รุ่นสินค้า วิธีนับของดี ระยะเวลาทดสอบ และเงื่อนไขที่ยกเว้น มิฉะนั้นผู้ขายอาจตั้งราคาและผู้ซื้ออาจตรวจรับด้วยมาตรวัดคนละแบบ การอ้างมาตรฐานก็เช่นกัน ควรระบุ Scope, Edition, สิ่งส่งมอบ และผู้รับผิดชอบประเมิน แทนการใส่เพียงชื่อมาตรฐาน

แยก Mandatory, Option และข้อมูลงานให้ชัด

จัดประเภทแต่ละ Requirement เป็น Mandatory, ยอมรับข้อเสนอทดแทน, Option price, Information only หรือ Out of scope และกำหนด ID เฉพาะให้ทุกข้อ จากนั้นใช้ ID เดิมในข้อกำหนดออกแบบ รายงาน Review, FAT, SAT และทะเบียนส่งมอบ

ตัวอย่างเช่น URS-DATA-014: บันทึก Serial number, ผล, Timestamp และ Recipe revision ของทุกชิ้นที่เสร็จ ช่วยให้ผู้ผลิตถามต่อเรื่อง Storage, Communication, Retention, Retry, Time synchronization และพฤติกรรมเมื่อระบบปลายทางล้มเหลว ผู้ซื้อก็ออกแบบการทดสอบสองช่วงได้ คือส่งข้อมูลเข้า Server จำลองใน FAT และเชื่อม MES จริงใน SAT

Interface control ป้องกันช่องว่างความรับผิดชอบ

โครงการมักล่าช้าที่รอยต่อมากกว่าภายในเครื่อง เช่น ใครเตรียม Feeder ไฟฟ้า ชิ้นงานส่งเข้าด้วย Orientation ใด เมื่อ Conveyor เดิมหยุดฝ่ายใดส่ง Signal อะไร หรือใครยืนยัน Tag ของ MES ให้บันทึกข้อตกลงใน Interface Control Document หรือ Matrix แทนการพึ่งความจำจากที่ประชุม

แต่ละแถวสำคัญควรมีชื่อ Owner, Due date, Input, Output, Revision และ Open issue คำว่า Customer supply หรือ By others อย่างเดียวไม่บอกเกณฑ์เสร็จ งานจะส่งผ่านความรับผิดชอบได้เมื่อทั้งสองฝ่ายยอมรับหลักฐานที่ขอบเขตเดียวกัน

หากต้องการรูปแบบข้อมูลเครื่องที่เป็นมาตรฐาน OPC UA for Machinery Part 1 มี Model ร่วมสำหรับ Identification, Component, State, Operation mode, Counter, Monitoring และ Notification แต่ไม่ได้หมายความว่าเครื่องทุกเครื่องต้องใช้ OPC UA หากเลือกใช้ ต้องกำหนด Profile, Tag, Certificate, Clock และ Failure behavior ให้โรงงานดูแลต่อได้

เปรียบเทียบใบเสนอราคาเครื่องจักรเฉพาะงานด้วยขอบเขตเดียวกัน

ราคารวมต่ำสุดอาจเป็นข้อเสนอที่ยกเว้นงานมากที่สุด ตารางเปรียบเทียบควรครอบคลุม Compliance, Assumption, Exclusion, งานที่ผู้ซื้อจัดหา, Option, Schedule gate, Payment, Acceptance, Warranty, Document, Software rights และ Site work ส่ง Clarification list เดียวกันให้ผู้เสนอราคาทุกราย และให้คำตอบสำคัญรวมอยู่ในใบเสนอราคาฉบับแก้ไข

เกณฑ์เทียบผู้ผลิตเครื่องจักรเฉพาะงาน

การให้คะแนนถ่วงน้ำหนักมีประโยชน์ แต่ไม่ควรลบ Gate condition ข้อ Mandatory ที่ไม่ผ่าน ผู้รับผิดชอบ Safety validation ที่ขาดหาย หรือ Software ที่กู้คืนไม่ได้ ไม่ควรถูกชดเชยอัตโนมัติด้วยราคาต่ำ เป้าหมายไม่ใช่การยึด Intellectual property ทั้งหมด แต่คือสิทธิในการใช้ กู้คืน และปรับแก้ที่จำเป็นต่อ Business continuity อาจใช้ Source escrow หรือ Release condition ในกรณีที่เลือกสัญญาบริการระยะยาว

ตัวอย่างสมมติของผลกระทบจาก Downtime

ตัวเลขต่อไปนี้เป็น สมมติฐานเพื่อการคำนวณที่ผู้ซื้อสร้างขึ้น ไม่ใช่ราคาตลาดหรือค่ามาตรฐาน สมมติผลิตของดีได้ 600 ชิ้นต่อชั่วโมง มี Contribution margin 18 THB ต่อชิ้น หยุด 4 ชั่วโมง และมีค่า Recovery กับ Revalidation ภายนอก 35,000 THB ผลกระทบหนึ่งครั้งเท่ากับ

600 ชิ้นต่อชั่วโมง × 18 THB ต่อชิ้น × 4 ชั่วโมง + 35,000 THB = 78,200 THB

78,200 THB ไม่ใช่ค่า Downtime ทั่วไปและไม่ใช่ Expected loss ที่รวม Probability ในงานจริงให้ใช้ Output, Margin, Buffer, Alternative production, Quarantine และ Recovery time ของโรงงานเอง สูตรนี้มีหน้าที่ทำให้ Restore test, Diagnostic, Spare และ Response time ถูกพิจารณาเป็นรายการจัดซื้อ ไม่ใช่อุปกรณ์เสริม

Design review ต้องเตรียมหลักฐาน ไม่ใช่อนุมัติแบบอย่างเดียว

ใช้ Requirement traceability matrix เชื่อมแต่ละ Requirement กับ Design element และ Test ที่จะพิสูจน์ รายการที่ยังไม่ปิดไม่จำเป็นต้องซ่อน โครงการไปต่อได้หากมี Owner, Deadline, Impact และ Interim assumption ที่ควบคุม

Gate ที่พบบ่อยได้แก่ Concept, Basic design, Detail design, Authorization to build, Software freeze, FAT readiness และ Release to ship กำหนด Deliverable กับ Approver ในแต่ละ Gate การอนุมัติคือการตัดสินใจไปต่อโดยรับรู้ประเด็นคงเหลือ ไม่ใช่การประกาศว่าความเสี่ยงหมดไป การเปลี่ยนหลัง Gate ต้องประเมินราคา เวลา Safety, Quality และ Retest

ด้านความปลอดภัย ISO 12100:2010 ให้ Methodology สำหรับระบุ Hazard, Estimate และ Evaluate risk รวมถึง Risk reduction ตลอดช่วงวงจรชีวิตที่เกี่ยวข้อง หน้า ISO ปัจจุบันระบุว่า Edition ปี 2010 ยัง Current และมี Draft ที่คาดว่าจะมาแทนในอนาคต จึงไม่ควรเรียก Draft ว่าเป็นมาตรฐานที่ประกาศใช้แล้ว

ISO 13849-1:2023 ให้ Methodology, Requirement และ Guidance สำหรับออกแบบและ Integrate ส่วนของ Control system ที่เกี่ยวข้องกับ Safety รวมถึง Software แต่ไม่ได้กำหนด Safety function หรือ PLr แบบเดียวให้ทุก Application และไม่ได้ให้ Cybersecurity measure ในตัว ผู้มี Competence ต้องหาและ Validate Safety function กับ PLr จาก Risk assessment เฉพาะเครื่องและข้อกำหนดที่ใช้จริง

ด้านอุปกรณ์ไฟฟ้าของเครื่อง IEC 60204-1:2016+A1:2021 อาจใช้เป็น Contract หรือ Design reference เมื่อเหมาะสม บทความทั่วไปไม่สามารถสรุปว่าโครงการเครื่องจักรทุกงานในไทยมีหน้าที่ตามกฎหมายต้อง Certification ตามมาตรฐานนี้ ต้องตรวจสอบกับโรงงาน เครื่อง สัญญา ลูกค้า และหน่วยงานที่เกี่ยวข้องเป็นกรณี

FAT และ SAT ต้องตอบคำถามคนละชุด

Factory Acceptance Test ปกติทำที่ผู้ผลิตก่อนส่ง ส่วน Site Acceptance Test ทำหลังติดตั้งในโรงงานจริง ไม่ควรเป็น Checklist เดียวกันที่เปลี่ยนสถานที่ FAT ควรค้นหาและแก้สิ่งที่ทำได้ก่อนขนส่ง ส่วน SAT พิสูจน์ Integration ที่มีเฉพาะปลายทาง

บันทึก Prerequisite, Input, Expected result, Observed result, Tolerance, Evidence และผู้ตัดสิน Deviation ต้องมี Severity, Containment, Permanent correction, Retest scope และเงื่อนไขอนุญาตให้ส่งหรือเดินเครื่อง หากรับแบบมีเงื่อนไขและมี Punch list ค้าง ต้องระบุ Owner, Deadline, Payment hold และผลหากไม่ปิดงาน

ก่อน FAT ผู้ซื้อควร Review procedure และเตรียม Sample, Instrument, Simulated signal และ Witness ก่อน SAT ต้องยืนยัน Installation, Utility, Network, Adjacent equipment, Material, Operator และ Quality approval วิธีนี้ช่วยแยกความล่าช้าจากการเตรียมไม่พร้อมออกจากความบกพร่องของเครื่อง โดยไม่ทำให้ความรับผิดชอบในการเตรียมคลุมเครือ

Handover package ต้องสร้าง Baseline ที่กู้คืนได้

SAT เป็นจุดเริ่มงาน Operation ไม่ใช่จุดสิ้นสุดความรับผิดชอบ เนื้อหาส่งมอบต้องรองรับ Restore, Training, จัดหา Spare, Audit และ Future change ทุกไฟล์ต้องตรงกับเครื่องที่ติดตั้งจริงหรือสถานะ As-built

รายการส่งมอบที่ควรพิจารณา

• แบบ As-built ด้าน Mechanical, Electrical, Pneumatic, Fixture, Network, I/O และ Bill of material
• Source และ Environment ของ PLC, HMI, Robot, Vision, Drive, Safety และ PC application
• Setting, Recipe, User account, Certificate, Device configuration และ Firmware revision
• Full backup, Restore instruction, Tool ที่ต้องใช้ เงื่อนไข Hardware ปลายทาง และหลักฐาน Restore ที่ทดสอบแล้ว
• License ของ Software, Library, Font, Operating system, Runtime และ Hardware key
• Risk assessment, Safety requirement, Design basis, Verification และ Validation record
• Manual และ Training record สำหรับ Operation, Changeover, Cleaning, Inspection, Diagnosis และ Lockout
• Recommended spare, Initial spare, Consumable, Criticality, Source, Lead time และ Alternative
• FAT/SAT procedure, Result, Deviation, Correction, Approval และ Traceability matrix
• Open issue, Warranty, Support contact, Remote support rule, History และ Document register

อย่าใช้คำว่า Program ownership ครอบทุกเรื่อง ให้แยก Copyright, Right to use, Copy, Backup, Disaster recovery, Modify, Third-party maintenance, Multi-site use, Generic library และ Confidential information อาจแยก Library มาตรฐานของผู้ผลิตออกจาก Sequence และ Recipe เฉพาะผู้ซื้อ Source file ไม่มีประโยชน์หากไม่มี Development environment, Compiler revision, License หรือ Password ในอีกด้านหนึ่ง Escrow และ Release condition อาจสร้างความต่อเนื่องได้โดยไม่ต้องรับ Intellectual property ของผู้ผลิตเกินจำเป็น

Backup ผ่านการรับมอบเมื่อ Restore ได้ภายใต้เงื่อนไขที่กำหนด ไม่ใช่เพียงมีไฟล์ สาธิต Restore ใน FAT หรือ SAT แล้วตรวจ I/O, Safety, Communication, Recipe และ History หลัง Recovery รวมถึงวิธีกลับ Baseline ที่อนุมัติ ให้ทุก Package มี Revision, Creation time, Target machine, Approval status และ Hash พร้อม Repository และ Access owner

รวม Spare part และ Obsolescence ตั้งแต่ใบเสนอราคา

เครื่องจักรอาจใช้งานหลายปี แต่ PLC, Industrial PC, Camera, Drive, Sensor, Operating system และ Library ถูก Update หรือ Discontinue ได้ หากไม่มี Bill of material ตั้งแต่ตอนเสนอราคา ผู้ซื้อเทียบความสามารถในการกู้คืนในอนาคตของแต่ละ Architecture ไม่ได้ ประเมินชิ้นส่วนสำคัญตาม Single-point failure, ผลต่อ Safety และ Quality, Availability, Substitute, Configuration และ Revalidation

ทะเบียน Spare ควรมี Manufacturer, Model, Revision, Compatibility, Storage, Inventory interval, Warranty, Replacement recommendation และ Substitute approval process คำว่า Equivalent permitted ไม่เพียงพอเมื่อ Response time, Accuracy, Communication, Material compatibility หรือ Software behavior เปลี่ยนได้ ให้การใช้ชิ้นส่วนทดแทนผ่าน Change control และ Update แบบ งาน Risk กับ Test ตาม Impact

กำหนดขอบเขต OT security และ Remote access ในสัญญา

Remote support ช่วยลดเวลา Recovery แต่ Router ที่ไม่มีการควบคุม Password ร่วม Account ถาวร และการแก้ไขที่ไม่มีบันทึกสร้างความเสี่ยง NIST SP 800-82 Rev.3 อธิบายว่าการออกแบบ Cybersecurity สำหรับ OT ต้องคำนึงถึง Performance, Reliability และ Safety ใช้เป็น Guidance เพื่อจัด Requirement ไม่ใช่ใช้แทนกฎหมายไทย

RFQ ควรครอบคลุม Asset inventory, Network zone, Port และ Direction, Individual account, Least privilege, ความเป็นไปได้ของ Multi-factor authentication, Approved connection window, Session record, Log, Malware control, Patch approach, Backup, Recovery และ Incident contact แม้โรงงานไม่ต่อ Internet ก็ยังต้องควบคุม Service laptop, Removable media, Software ที่นำเข้า และ Vendor account

Review ความสัมพันธ์ของ Safety และ Cybersecurity ด้วย Network isolation, Certificate หมดอายุ, Account ถูก Disable, Patch และ Clock drift อาจกระทบ Availability, Diagnosis, Record และระบบรอบ Safety function แต่บทความทั่วไปไม่สามารถเลือก Control ที่ถูกต้องให้เครื่องจริง ต้องมี Assessment เฉพาะเครื่องและ Approval จากผู้รับผิดชอบ

ประเมินมาตรการ Thailand BOI เป็น Scenario ที่ต้องยืนยันแยก

หน้า Smart and Sustainable Industry ของ Thailand BOI ในปัจจุบันระบุว่าเงินลงทุนขั้นต่ำสำหรับการเพิ่มประสิทธิภาพคือ 1 million THB โดยไม่รวมค่าที่ดินและทุนหมุนเวียน โครงการเดิมที่ผ่านเงื่อนไขและได้รับอนุมัติอาจได้รับยกเว้น Corporate income tax 3 ปี โดยมีเพดาน 50% ของเงินลงทุนที่เข้าเกณฑ์สำหรับ Efficiency improvement หรือ Business upgrade ซึ่งไม่รวมค่าที่ดินและทุนหมุนเวียน

เพดานจะเป็น 100% เฉพาะเมื่อ Machinery ที่เชื่อมโยงหรือสนับสนุนอุตสาหกรรม Automation ภายในประเทศไทยมีมูลค่าอย่างน้อย 30% ของมูลค่ารวม Machinery, Automation และ Robotics ที่ใช้หรือ Upgrade การดำเนินงานต้องเสร็จภายใน 3 ปีนับจากออก Promotion certificate การยื่นคำขอ การอนุมัติ การดำเนินงาน และการได้รับสิทธิทางภาษีเป็นคนละขั้น การซื้อเครื่องจักรเฉพาะงานไม่ได้ทำให้เข้าเกณฑ์อัตโนมัติ ต้องยืนยัน Project, Domestic-industry link, Value calculation, Timing และ Evidence กับ BOI เป็นรายกรณี

อย่าหัก Incentive ที่ยังไม่อนุมัติออกจาก Base business case ให้เก็บ Breakdown ใบเสนอราคา Supply information, Payment, Installation และ Acceptance evidence ที่อาจใช้ประกอบคำขอ เลือกเทคนิคจาก Production, Safety, Quality และ Maintainability แล้วประเมิน Incentive เป็น Scenario แยกหลังยืนยันเงื่อนไข

ควบคุมทุกการเปลี่ยนหลัง SAT ด้วย Baseline ที่รับรองแล้ว

หลัง SAT โรงงานมักปรับ Sensor, Alarm, Recipe, Cycle logic, Part, Network และ Software การเปลี่ยนเล็กอาจกระทบ Quality decision, Safety distance, Stop behavior, Data integrity หรือ Warranty หากแก้ด้วยวาจาและไม่ Update แบบ Source กับ Backup โรงงานจะไม่รู้ว่าสถานะใดคือสถานะถูกต้องเมื่อเกิดเหตุครั้งถัดไป

Change request ควรบันทึก Reason, Affected object, Current state, Proposal, Urgency และ Requester ประเมินผลต่อ Production, Quality, Safety, Maintenance, IT/OT และ Contract รวมทั้ง Test, Training, Document และ Rollback หลังอนุมัติจึง Implement ใน Environment ที่ควบคุม ทำ Regression test และ Release Package ที่มี Version หากล้มเหลวให้กลับ Baseline ที่อนุมัติ

Emergency recovery อาจย่อขั้นตอน แต่ต้องไม่ลบบันทึก เก็บข้อมูลว่าใครเปลี่ยนอะไร เมื่อใด เพราะเหตุใด และตรวจอะไร เมื่อระบบนิ่งให้ทำ Formal risk review และ Update document ให้เสร็จ Change จะปิดได้เมื่อ Test ผ่าน มี Approval, As-built update, Backup, Training และ Communication ครบ

กำหนดทีมผู้ซื้อและ Contract gate ก่อนเริ่มดำเนินงาน

แม้ผู้ผลิตเครื่องจักรเฉพาะงานมีความสามารถสูง Requirement และ Acceptance ก็ไม่เสถียรหากผู้ตัดสินใจฝั่งผู้ซื้อไม่ชัด Production ควรรับผิดชอบ Capability และ Workability, Quality รับผิดชอบ Measurement และ Decision, Maintenance รับผิดชอบ Diagnostic และ Recovery, EHS รับผิดชอบ Risk และกฎโรงงาน, IT/OT รับผิดชอบ Network และ Account ส่วน Purchasing หรือ Legal รับผิดชอบ Contract และ Rights อย่างไรก็ตาม หากทุกคนต้องอนุมัติทุกเรื่อง งานจะค้าง จึงควรกำหนดผู้จัดทำ ผู้ Review, ผู้อนุมัติ และผู้รับข้อมูลแยกตาม Requirement area ผู้ตัดสินใจขั้นสุดท้ายต้องแก้ความต้องการที่ขัดกันได้โดยเปรียบเทียบ Cost, Schedule และ Operation impact โดยไม่ลด Safety หรือ Quality

กำหนด Entry readiness และ Exit completion ของแต่ละ Gate แทนการวัด Governance ด้วยจำนวน Meeting ตัวอย่างเงื่อนไขเข้า Design review คือ Current URS, Open-item list, Layout, I/O proposal, ความคืบหน้า Risk assessment และ Test strategy พร้อม เงื่อนไขออกคือบันทึก Approved, Conditional และ Rejected item พร้อม Next deliverable, Owner และ Due date ผูก Decision กับ Revision ที่ Review ไว้ใน Document register เพื่อไม่ให้ Attachment เก่ากลายเป็นฉบับอ้างอิงภายหลัง

เชื่อม Payment milestone กับ Deliverable ที่ Verify ได้ ไม่ใช่เพียงวันที่ใน Calendar โครงการอาจแบ่ง Contract, Design approval, FAT acceptance, Shipment, SAT acceptance และ Final-document receipt แต่ต้องกำหนด Evidence กับ Exception route ของแต่ละช่วง หาก Conditional FAT อนุญาตให้ส่ง ต้องตกลง Correction deadline, Retest location, ผู้รับ Additional cost และเงื่อนไข Release retained payment นี่ไม่ใช่กลไกลงโทษ แต่เป็นวิธีทำให้ปัญหาที่ทราบยังมองเห็นจนปิดในสถานที่ที่เหมาะสม

เมื่อคิดราคาการเปลี่ยน Specification ให้แยก Material difference ออกจาก Redesign, Committed component, Software modification, Risk review ซ้ำ, Document revision, FAT หรือ SAT retest และผลต่อ Site schedule การใส่ Rate card หรือ Calculation method ในใบเสนอราคาเดิมช่วยลดเวลาเจรจาหลัง Award ได้ หาก Supplier design improvement ตอบ Requirement ได้เท่ากันหรือดีกว่าโดยไม่เปลี่ยน Boundary และ Acceptance อาจใช้ Simplified change route ได้ แต่ทั้งสองกรณีต้องไม่ใส่การเปลี่ยนลง Build ก่อน Approval

ภาษาก็เป็นส่วนหนึ่งของ Handover quality โรงงานไทยอาจประชุม Design ด้วย English หรือ Japanese และฝึก Operator กับ Maintainer เป็น Thai ใน RFQ ให้กำหนดว่า Document ใดส่งภาษาใด Source หรือ Translation ใดเป็นฉบับ Control, ภาษา HMI และ Alarm, Terminology list และวิธี Update Translation เมื่อ Revision เปลี่ยน อย่าใช้ Translation อย่างเดียวตัดสินความหมายสำคัญด้าน Safety ให้ Drawing reference, Part number, Signal name และ Test ID เป็น Common key เพื่อเทียบ Object เดียวกันข้ามภาษา

เมื่อดูประสบการณ์ผู้ผลิต อย่าดูเพียงภาพเครื่องเสร็จ ให้ถามประสบการณ์จัดการ Boundary ที่คล้ายงานนี้ เช่น Installation ที่ต้องหยุด Existing line, Handshake ระหว่างเครื่องหลาย Supplier, MES integration จริง, Safety-related control, Local training และ Long-term service แม้ Confidentiality ทำให้เปิด Customer name หรือ Drawing ไม่ได้ ผู้ผลิตยังอธิบาย Responsibility split, Gate, Evidence และ Problem-solving method ได้ ความเฉพาะเจาะจงช่วยตัดสินว่า Management approach นั้นทำซ้ำในโครงการนี้ได้หรือไม่

Roadmap จากการจัดซื้อถึงการรับมอบ

1. บันทึกเป้าหมายกระบวนการ ชิ้นงาน Capability, Quality และข้อจำกัดการใช้งานใน URS
2. กำหนด Requirement ID และ Acceptance method พร้อมแยก Mandatory, Option, Information และ Exclusion
3. ใช้ Interface matrix กำหนดขอบเขตของเครื่อง อาคาร เครื่องข้างเคียง ข้อมูล Safety, Cyber และ Document
4. เปรียบเทียบผู้ผลิตด้วย RFQ และ Response format เดียวกัน แล้วรวม Exception กับ Assumption ในข้อเสนอฉบับแก้ไข
5. Trace Requirement ผ่าน Design, Risk, Build และ Test evidence ใน Gate ที่ควบคุม
6. ใช้ FAT ปิดสิ่งที่ตรวจได้ก่อนส่ง และควบคุม Deviation กับ Retest
7. ใช้ SAT พิสูจน์ Site integration กับ Material, People, Utility, System และความเสี่ยงรอบข้างจริง
8. ส่งมอบ As-built, Source, Backup, License, Spare และ Training เป็น Baseline ที่กู้คืนได้
9. ให้ทุกการเปลี่ยนหลัง SAT ผ่าน Change control

หากโครงการมีหุ่นยนต์ คู่มือ การเลือก Robot System Integrator ในประเทศไทย ช่วยจัดขอบเขตความรับผิดชอบด้าน Integration และบทความ ความเสี่ยงที่ทำให้โครงการ Automation ในไทยล้มเหลว อธิบายความเสี่ยงด้าน Schedule และ Governance ในภาพรวม

สรุป จัดซื้อเครื่องจักรเฉพาะงานผ่าน Evidence gate

การผลิตเครื่องจักรเฉพาะงานที่มีคุณภาพเริ่มจาก Acceptance condition ไม่ใช่คำสั้นในใบสั่งซื้อ URS กำหนดผลลัพธ์ Interface control กำหนดเจ้าของขอบเขต Design และ Risk review เตรียมหลักฐาน FAT กับ SAT ลดความไม่แน่นอนคนละประเภท และ Handover สร้าง Baseline ที่กู้คืนได้ การควบคุม Change หลัง SAT ช่วยรักษาหลักฐานแม้เปลี่ยนคนหรือผู้ผลิต

หากกำลังเปรียบเทียบผู้ผลิต หรือจัดทำ URS, RFQ, FAT/SAT plan หรือขอบเขตเชื่อม MES สามารถติดต่อ TOMAS TECHได้ตั้งแต่ระยะวางแผน เราช่วย Review เอกสารที่มีและจัดโครงสร้างประเด็นที่ควรปิดก่อน Commit โครงการได้

คำถามที่พบบ่อยเกี่ยวกับเครื่องจักรเฉพาะงาน

เครื่องจักรเฉพาะงานคืออะไร

คือเครื่องที่ออกแบบหรือ Integrate สำหรับผลิตภัณฑ์ กระบวนการ การตรวจ การลำเลียง หรือการประกอบที่กำหนด แม้ใช้หุ่นยนต์และ Module มาตรฐาน Fixture, Control, Safety และ Data integration ที่ออกแบบเฉพาะก็ควรบริหารแบบโครงการเฉพาะ ขอบเขตจัดซื้อควรรวมหลักฐานและ Package ที่กู้คืนได้ ไม่ใช่ Hardware อย่างเดียว

เปรียบเทียบใบเสนอราคาอย่างไร

ให้ URS, Boundary matrix, Acceptance condition และ Response format เดียวกันแก่ผู้เสนอราคา แล้ว Normalize Compliance, Exception, Assumption, Exclusion, Option, Site work, Document, Software rights และ Support ช่องว่าง Mandatory หรือเจ้าของ Safety และ Recovery ที่ไม่ชัดควรเป็น Gate แยกจากคะแนนราคา

FAT และ SAT ควรพิสูจน์อะไร

FAT พิสูจน์ Function, Capability, Quality, Fault recovery, Safety, Interface จำลอง และ Draft handover ก่อนส่ง SAT พิสูจน์การทำงานกับ Material, People, Utility, Adjacent equipment และ Production system จริง ทั้งสองต้องมี Prerequisite, Expected result, Observed result, Tolerance, Deviation, Evidence และ Approval

ใครเป็นเจ้าของ Program และ Backup

ขึ้นกับสัญญาโครงการ ควรแยก Copyright ออกจากสิทธิใช้ Copy, Backup, Recover, Modify และจ้าง Third party support รวม Environment version, License, Credential, Restore instruction และการสาธิต Restore เป้าหมายคือ Business continuity ที่เชื่อถือได้ ไม่ใช่คำกว้างว่าเป็นเจ้าของ Source ทั้งหมด

จัดการการเปลี่ยนหลังรับมอบอย่างไร

เก็บสถานะ SAT ที่อนุมัติเป็น Baseline ใช้ Change request, Impact review, Approval, Controlled implementation, Regression test, Versioned release และ Document update กำหนด Rollback ก่อนเปลี่ยน และกำหนดขอบเขต Retest ตามผลที่อาจเกิดกับ Safety, Quality, Data และ Warranty

แหล่งข้อมูลหลัก

• ISO 12100:2010
• ISO 13849-1:2023
• IEC 60204-1:2016+A1:2021
• NIST SP 800-82 Rev.3
• OPC UA for Machinery Part 1 v1.04.1
• Thailand BOI Smart and Sustainable Industry