กำหนดขอบเขตโครงการเปลี่ยนผ่านสู่ดิจิทัลในโรงงานอย่างไร: โมเดลการส่งมอบ 6 ขั้น

ทำไมการกำหนดขอบเขตชี้ผลแพ้ชนะมากกว่าการเลือกเทคโนโลยี

เวลาช่วงประเมินส่วนใหญ่หมดไปกับการเทียบเทคโนโลยี จะใช้ SCADA ตัวไหน ต้องมี MES หรือไม่ ฐานข้อมูลอะไร สื่อสารกับเครื่องเดิมได้หรือเปล่า การเทียบแบบนี้มีประโยชน์ แต่แทบไม่เคยเป็นเหตุที่ทำให้โครงการล้ม โครงการล้มเมื่อไม่มีเอกสารฉบับใดระบุว่าเฟสแรกจบที่ไหน

ขอบเขตไม่ใช่ย่อหน้าหนึ่งในข้อเสนอ แต่เป็นชุดคำตอบที่เจาะจง ไลน์ไหน สถานีใดบ้าง เก็บรายการข้อมูลอะไร ออกรายงานอะไร และเข้าเงื่อนไขใดจึงถือว่าเสร็จ ถ้ายังไม่มีคำตอบเหล่านี้ ปริมาณงานก็ได้แค่ตัวเลขประมาณการ และการเปลี่ยนแปลงในภายหลังก็ไม่มีฐานไว้เทียบ

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

สัญญาณทั้งห้าปรากฏก่อนเขียนโค้ดบรรทัดแรก และนั่นคือเหตุที่ในจังหวะนั้นยังแก้ได้ด้วยต้นทุนต่ำ

หกขั้น: แต่ละขั้นต้องให้อะไรและไม่ให้อะไร

โมเดลด้านล่างแบ่งโครงการดิจิทัลออกเป็นหกขั้น การตั้งชื่อขั้นไม่ใช่เพื่อความสวยงามของกระบวนการ แต่เพื่อให้ทุกขั้นมีเงื่อนไขปิดงาน สองฝ่ายจึงตัดสินได้ว่ามันจบจริงหรือยัง

• วินิจฉัย — ให้ผลวินิจฉัยจุดติดขัดและผลการวัดค่าฐานของข้อมูล หลักที่ตกลงกันคือวัดก่อนแล้วค่อยคำนวณ เก็บข้อมูลฐานก่อนจึงคุยเป้าหมายการปรับปรุงและขอบเขต ขั้นนี้ไม่ให้ราคาชี้ชัดสำหรับการขยายทั้งโรงงาน
• นำร่อง — เมื่อขอบเขตล้อมกรอบได้ ให้เริ่มจากพื้นที่เล็กก่อน โดยตกลงเกณฑ์ตรวจรับไว้ล่วงหน้า รอบเวลาและตัวชี้วัดที่ยังไม่มีค่ายืนยันให้สองฝ่ายสำรวจแล้วยืนยันร่วมกัน ขั้นนี้ไม่ให้การเปิดใช้ทั้งโรงงาน
• ติดตั้งและปรับจูน — เริ่มจากเทมเพลตงานวิศวกรรมมาตรฐาน การจัด I/O รายการจุดสัญญาณ ผังเครือข่าย และข้อกำหนดหน้าจอมาก่อนการพัฒนา ส่วนงานปรับปรุงระบบเดิมยังต้องให้แผนงานติดตั้งแบบไม่หยุดการผลิตด้วย ขั้นนี้ไม่ให้ความต้องการใหม่ ความต้องการใหม่ต้องเดินตามกระบวนการเปลี่ยนแปลง
• เอกสารตรวจรับ — ตัวเอกสารคือสิ่งส่งมอบ ส่งมอบคู่มือการใช้งาน คำอธิบายตารางฐานข้อมูล ข้อกำหนดอินเทอร์เฟซข้อมูล อัลบั้มรายการจุดสัญญาณ และเอกสารอื่นตามที่ตกลงในสัญญาและขอบเขตงาน เพื่อให้โรงงานบริหาร สืบค้น และต่อขยายระบบเองได้ในภายหลัง ขั้นนี้ไม่ให้เอกสารแบบ "ตรวจรับไปแล้วนึกออกจึงขอเพิ่ม" รายการยึดตามข้อตกลงทางเทคนิค
• บำรุงรักษารายปี — ให้สัญญาบำรุงรักษามาตรฐาน รายการบำรุงรักษาที่ทบไปทีละปี และรายงานบำรุงรักษาประจำปี เพื่อให้งานดูแลวัดผลและประเมินได้ ขั้นนี้ไม่ให้งานพัฒนาใหม่แบบไม่จำกัด
• ขยายระบบ — เดินหน้าเฟสสองตามขอบเขตงานและการประเมินหน้างาน โดยให้ความสำคัญกับความเข้ากันได้กับการลงทุนเดิม ขั้นนี้ไม่ให้การรื้อทำเฟสแรกใหม่

ครึ่งประโยคที่ว่า "ไม่ให้อะไร" สำคัญเท่ากับครึ่งแรก ข้อพิพาทตอนตรวจรับเกือบทั้งหมดสาวกลับไปถึงงานที่ฝ่ายหนึ่งเข้าใจว่าอยู่ในขั้นใดขั้นหนึ่ง แต่จริง ๆ ไม่เคยถูกตกลงไว้เลย

เทียบทีละขั้น: สิ่งส่งมอบและสิ่งที่ผู้ซื้อต้องตัดสินใจ

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

หมายเลขบอกลำดับ ไม่ได้บอกกำหนดเวลา วินิจฉัยอาจใช้ไม่กี่วัน นำร่องไลน์เดียวสี่ถึงแปดสัปดาห์ ส่วนการติดตั้งทั้งโรงงานยาวกว่านั้นมาก การตกลงเงื่อนไขปิดงานของแต่ละขั้นสำคัญกว่าการตกลงระยะเวลาของมัน

เอกสารคือสิ่งส่งมอบ ไม่ใช่งานกระดาษที่แนบมา

ภาพที่คุ้นเคยคือ ระบบเดินได้ วิศวกรของผู้ขายคนนั้นรู้ว่ามันเดินได้อย่างไร นอกจากนั้นไม่มีใครรู้ สองปีต่อมาโรงงานปรับปรุงไลน์ วิศวกรคนนั้นย้ายงานไปแล้ว และโรงงานจะแก้รายงานหนึ่งใบก็แก้ไม่ได้ เพราะไม่มีใครบันทึกไว้ว่ามันอ่านตารางใด

ชุดเอกสารโครงการอุตสาหกรรมที่ครบถ้วนมี 14 ประเภท การจัดกลุ่มตามจังหวะที่เกิดเอกสารทำให้ถือสัญญาไปสอบทานรายการที่ผู้ขายยื่นมาได้ง่ายขึ้น

แนวทางที่แนะนำคือแนบรายการนี้เข้ากับข้อตกลงทางเทคนิค แทนที่จะฝากไว้กับความสมัครใจของสองฝ่าย การระบุรายการเอกสารตอนเซ็นสัญญาไม่มีค่าใช้จ่ายเพิ่ม แต่ถ้ารอให้ทีมโครงการสลายตัวแล้วย้อนกลับมาทำใหม่ ต้นทุนจะสูงมาก

ตัวชี้วัดใดควรเขียนไว้ในข้อตกลงทางเทคนิคเพื่อตรวจรับ

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

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

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

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