ระบบบริหารการผลิต คลาวด์ 2026 | สิ่งที่หยุดก่อนไม่ใช่เซิร์ฟเวอร์ แต่คือการยืนยันตัวตน

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

การขึ้นคลาวด์ของระบบบริหารการผลิต เงื่อนไขตั้งต้นเปลี่ยนไปแล้วในปี 2026

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

ในปี 2026 เงื่อนไขตั้งต้นข้อนี้เปลี่ยนไป เพราะการวางข้อมูลไว้ภายในประเทศไทยกลายเป็นทางเลือกมาตรฐานได้เป็นครั้งแรก

ความหมายของการที่กรุงเทพฯ มีรีเจี้ยนครบ

เรียงข้อเท็จจริงก่อน AWS (Amazon Web Services บริษัท Amazon.com) เปิดให้บริการทั่วไป Asia Pacific (Thailand) รีเจี้ยน (ap-southeast-7 โครงสร้าง 3 Availability Zone) เมื่อวันที่ 8 มกราคม 2025 ส่วน Google Cloud (บริษัท Google) เปิดรีเจี้ยนกรุงเทพฯ (โครงสร้าง 3 Availability Zone) เมื่อวันที่ 21 มกราคม 2026 พร้อมประกาศการลงทุนระดับ 1 พันล้าน USD สำหรับ Microsoft Azure (บริษัท Microsoft) รีเจี้ยนประเทศไทย (Thailand South) ณ เวลานี้ยังอยู่ในขั้นประกาศแผนการเปิดให้บริการ และในเดือนตุลาคม 2025 ได้เปิดเผยว่าจะใช้ True IDC (บริษัท True Corporation) เป็นหนึ่งใน Availability Zone

ความต่างของสถานะทั้งสามรายนี้ส่งผลตรง ๆ ต่อวิธีเดินเรื่องพิจารณา ระหว่างโครงสร้างพื้นฐานที่เปิดให้บริการทั่วไปแล้ว กับโครงสร้างพื้นฐานที่เพิ่งประกาศแผนเปิด สิ่งที่เขียนลงในเอกสารขออนุมัติได้นั้นต่างกัน ถ้าบริษัทแม่กำหนดเงื่อนไขว่า “ข้อมูลต้องอยู่ภายในประเทศไทย” ณ เวลานี้ตัวที่ตอบเงื่อนไขได้มีเฉพาะกลุ่มแรก ถ้าจะวางแผนโดยตั้งอยู่บนกลุ่มหลัง เท่ากับเขียนแผนการย้ายระบบบนสมมติฐานที่ยังไม่ทราบวันเปิดให้บริการที่แน่นอน ตรงนี้ต้องระบุไว้ให้ชัดว่าเป็นความเสี่ยงของแผน

อีกเรื่องที่มีน้ำหนักในทางปฏิบัติคือการมี Availability Zone ถึง 3 โซน ในศูนย์ข้อมูลแบบจุดเดียวที่มีเพียงโซนเดียว ความขัดข้องของระบบไฟฟ้าหรือระบบปรับอากาศจะกลายเป็นการหยุดให้บริการทันที ถ้าเป็นโครงสร้าง 3 โซน จะจัดวางฐานข้อมูลคร่อมหลายโซนและสลับอัตโนมัติเมื่อฝั่งหนึ่งขัดข้องได้ นี่เป็นคนละระดับกับการวางเซิร์ฟเวอร์ 2 เครื่องในโรงงานตัวเองเพื่อทำ redundancy การทำ redundancy ภายในโรงงานเอาชนะไฟดับทั้งอาคารและน้ำท่วมไม่ได้

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

เหตุผลที่ “ขึ้นคลาวด์ทั้งหมด” ยังไม่ใช่คำตอบ

สิ่งที่มักเกิดขึ้นเมื่อข้อจำกัดหนึ่งข้อหลุดไป คือการเข้าใจไปเองว่าข้อจำกัดที่เหลือหายไปด้วย ในความเป็นจริง ถึงรีเจี้ยนจะมาอยู่ในประเทศ ก็ยังเหลือปัญหาที่ไม่ถูกแก้อยู่ 3 ข้อ

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

ข้อที่สองคือโครงสร้างค่าใช้จ่ายที่อ่านยากขึ้น รายงาน JUAS “การสำรวจแนวโน้ม IT ขององค์กร 2026” ระบุเหตุผลของการเพิ่มงบประมาณ IT ว่า “การอัปเดต ปรับปรุง และขยายระบบเดิม” มาเป็นอันดับหนึ่งที่ 66.3% ตามด้วย “ผลกระทบจากเงินเยนอ่อน ค่าแรงสูงขึ้น และผู้ขายขึ้นราคา” ที่ 46.6% “การเพิ่มขึ้นของบริการคลาวด์” ที่ 45.0% และ “การลงทุนและต้นทุนการใช้งานที่เกี่ยวกับ AI เพิ่มขึ้น” ที่ 43.7% ซึ่งเพิ่มขึ้น 7.4 จุดจาก 36.3% ในปีก่อน ข้อเท็จจริงที่ว่าการเพิ่มขึ้นของคลาวด์ติดอันดับต้น ๆ ของเหตุผลที่งบประมาณโต ก็คือหลักฐานว่าสมมติฐานที่ว่า “ขึ้นคลาวด์แล้วจะถูกลง” พังไปแล้วในหน้างาน

ข้อที่สามคือการไหลย้อนกลับหลังจากที่เทน้ำหนักไปทางคลาวด์แล้ว ซึ่งเกิดขึ้นจริง การรวบรวมข้อมูลเกี่ยวกับการย้ายกลับจากคลาวด์ (repatriation) ระบุว่าใน 2025 State of the Cloud ของบริษัท Flexera มีเวิร์กโหลดหรือข้อมูลย้ายกลับแล้ว 21% และ 84% ยก “การควบคุมค่าใช้จ่ายคลาวด์” เป็นโจทย์ใหญ่ที่สุด ส่วนการสำรวจของบริษัท IDC พบว่าในปี 2024 มี 59% ขององค์กรที่ใช้งบเกิน อย่างไรก็ตาม การสำรวจของ IDC เช่นกัน ณ เดือนตุลาคม 2024 ระบุว่าองค์กรที่ถอนเวิร์กโหลดออกทั้งหมดมีเพียงประมาณ 8% ส่วนใหญ่เป็นการย้ายกลับแบบเลือกเฉพาะบางส่วน

ประเด็น “ส่วนใหญ่เป็นการเลือกเฉพาะบางส่วน” นี้แหละคือข้อเสนอหลักของบทความนี้ บริษัทที่ย้ายกลับก็ไม่ได้ย้ายกลับทั้งหมด แต่ย้ายกลับเฉพาะฟังก์ชันที่ไม่เข้ากัน ถ้าเป็นเช่นนั้น ก็ควรกำหนดที่วางเป็นรายฟังก์ชันตั้งแต่แรก การตั้งคำถามว่า “คลาวด์หรือออนพรีมิส” แล้วเลือกคำตอบเดียวให้ทั้งระบบ ตัววิธีตั้งคำถามเองนั่นแหละที่ผิด

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

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

ถ้าจะตัดสินเป็นรายฟังก์ชัน แล้วใช้อะไรเป็นเกณฑ์แบ่ง คำตอบไม่ใช่ค่าใช้จ่าย แต่คือระยะเวลาหยุดที่ยอมรับได้ หรือ RTO (Recovery Time Objective เป้าหมายระยะเวลาในการกู้คืน)

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

ระยะเวลาหยุดที่ยอมรับได้ของแต่ละฟังก์ชัน

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

พอดูตารางนี้ จะเห็นว่าภายในสิ่งที่เรียกว่า “ระบบบริหารการผลิต” เดียวกัน มีทั้งฟังก์ชันที่หยุดได้แค่ 5-15 นาที และฟังก์ชันที่หยุดไป 3 วันทำการงานก็ยังเดินได้ อยู่ปะปนกัน ส่วนต่างคือหลายร้อยเท่า

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

ในทางกลับกัน การรวบรวมต้นทุน ถึงรวบรวมไม่ได้ในวันนั้น ก็ประมวลผลรวบยอดในวันถัดไปได้ ยกเว้นช่วงก่อนปิดรายเดือน การหยุด 3 วันทำการไม่ทำให้งานหยุด การลงทุนด้านความพร้อมใช้งานให้ฟังก์ชันนี้เท่ากับการออกฉลากถือว่าเกินความจำเป็น

พร้อมกับ RTO ให้กำหนด RPO (Recovery Point Objective เป้าหมายจุดข้อมูลที่กู้คืน คือยอมให้ข้อมูลสูญหายได้ถึงจุดไหน) เป็นรายฟังก์ชันด้วย การบันทึกผลการผลิตมี RPO สั้น เพราะถ้าข้อมูลที่กรอก 30 นาทีก่อนหน้าหายไป ไม่มีใครสร้างขึ้นใหม่ได้ ส่วนการอัปเดตข้อมูลหลัก ต่อให้การอัปเดตครั้งล่าสุดหายไป ผู้ลงทะเบียนยังจำได้และกรอกใหม่ได้ แนวคิดของตัวชี้วัดสองตัวนี้และวิธีแปลงลงสู่การออกแบบจริง เราเขียนไว้ในบทความที่จัดระเบียบแนวทางสำรองข้อมูลของระบบงานจากมุมของ RTO และ RPO แนะนำให้อ่านก่อนกรอกตารางภายในองค์กร

ถ้าตั้ง RTO ค่าเดียวให้ทั้งระบบ จะเกิดทั้งการลงทุนเกินและความไม่เพียงพอพร้อมกัน

สิ่งที่พบบ่อยหน้างานคือเอกสารข้อกำหนดที่เขียนไว้เพียงบรรทัดเดียวว่า “RTO ของทั้งระบบ 4 ชั่วโมง” บรรทัดเดียวนี้ก่อความล้มเหลว 2 อย่างพร้อมกัน

อย่างแรกคือการลงทุนเกิน RTO 4 ชั่วโมงเข้มงวดเกินไปสำหรับการรวบรวมต้นทุนและการจัดซื้อ การเตรียมกลไกให้กลับมาภายใน 4 ชั่วโมงให้กับฟังก์ชันที่ 3 วันทำการก็พอ ทำให้ค่า redundancy และชั่วโมงงานปฏิบัติการส่วนนั้นสูญเปล่าทั้งก้อน ยิ่งกว่านั้น ความสูญเปล่านี้มองไม่เห็นเป็นตัวเงิน เพราะถูกกลบอยู่ในรายการที่ชื่อว่า “เพื่อความพร้อมใช้งานของทั้งระบบ”

อย่างที่สองคือความไม่เพียงพอ RTO 4 ชั่วโมงหลวมเกินไปสำหรับการออกฉลาก ถ้าออกแบบฟังก์ชันที่หยุดได้แค่ 5-15 นาทีด้วยค่า 4 ชั่วโมง เมื่อเกิดเหตุขัดข้องจริง หน้างานจะทำอะไรไม่ได้เลยเป็นเวลา 3 ชั่วโมง 45 นาที และกว่าจะรู้ว่า “รอ 4 ชั่วโมงไม่ไหว” ก็ต่อเมื่อเหตุขัดข้องเกิดขึ้นแล้ว ณ ตอนนั้น ต้นทุนการออกแบบใหม่จะเป็นหลายเท่าของตอนสร้างครั้งแรก

การตั้ง RTO ค่าเดียวให้ทั้งระบบ คือการตัดสินใจที่พลาดทั้งสองทาง ทั้งเพิกเฉยต่อความต้องการของฟังก์ชันที่เข้มงวดที่สุด และลงทุนเกินให้กับฟังก์ชันที่หลวมที่สุด สิ่งที่ควรเขียนไม่ใช่ 1 บรรทัด แต่คือจำนวนบรรทัดเท่ากับจำนวนฟังก์ชัน

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

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

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

การยืนยันตัวตนไม่ถูกรับรู้ว่าเป็น “ฟังก์ชัน” มันไม่ปรากฏในรายการฟังก์ชันงาน ไม่ถูกวาดในผังกระบวนการทำงาน และด้วยเหตุนั้นจึงไม่มีใครกำหนด RTO ให้ แต่ในความเป็นจริง มันอยู่ก่อนหน้าทั้ง 6 ฟังก์ชันในตารางเมื่อครู่ ถ้าล็อกอินไม่ได้ ฉลากก็ไม่ออก ผลการผลิตก็บันทึกไม่ได้

พูดอีกอย่าง RTO ของการยืนยันตัวตนต้องปรับให้เท่ากับค่าที่สั้นที่สุดในตาราง ถ้าการออกฉลากคือ 5-15 นาที RTO ของการยืนยันตัวตนก็คือ 5-15 นาที เพราะจุดนี้หลุดจากการออกแบบ ปัญหาแรกหลังย้ายขึ้นคลาวด์จึงเกิดที่การยืนยันตัวตนแทบจะไม่มีข้อยกเว้น

สามรูปแบบของการยืนยันตัวตน และพฤติกรรมเมื่อวงจรสื่อสารขาด

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

แบบที่ 1 ใช้คลาวด์ IdP อย่างเดียว เป็นโครงสร้างที่ยืนยันตัวตนด้วยผู้ให้บริการอัตลักษณ์บนคลาวด์ เช่น Microsoft Entra ID (บริษัท Microsoft) หรือ Google Workspace (บริษัท Google) และไม่วาง domain controller ไว้ฝั่งออนพรีมิส การดูแลเบาที่สุด แต่เมื่อวงจรขาด เครื่องปลายทางในโรงงานจะล็อกอินไม่ได้เลยสักคน เซสชันที่ล็อกอินอยู่แล้วจะยังทำงานต่อจนกว่า access token จะหมดอายุ แล้วหยุดทันทีที่หมด ถ้าอายุ token คือ 1 ชั่วโมง นับจากวงจรขาด เครื่องทั้งหมดจะทยอยล้มภายในไม่เกิน 1 ชั่วโมง ที่น่าปวดหัวคือทุกคนไม่ได้ล้มพร้อมกัน เพราะเวลาที่ล้มกระจายกันไป หน้างานจึงรับรู้ว่า “ระบบไม่เสถียร” ไม่ใช่ “วงจรขาด” การแยกแยะสาเหตุจึงล่าช้า

แบบที่ 2 AD ออนพรีมิสร่วมกับ federation ไปยังคลาวด์ เป็นโครงสร้างที่วาง Active Directory (บริษัท Microsoft) ไว้ในโรงงาน แล้วเชื่อมการยืนยันตัวตนไปฝั่งคลาวด์ พฤติกรรมจะกลับด้านกันโดยสิ้นเชิงระหว่างกรณีที่ใช้ password hash synchronization กับกรณีที่ใช้ federation ซึ่งเป็นวิธีส่งต่อคำขอยืนยันตัวตนไปยังฝั่งออนพรีมิส ถ้าเป็น password hash synchronization ต่อให้ AD ฝั่งออนพรีมิสล้ม การยืนยันตัวตนก็จบได้ในฝั่งคลาวด์เพียงลำพัง แต่ถ้าเป็น federation ทันทีที่ฐานการยืนยันตัวตนฝั่งออนพรีมิสล้ม การล็อกอินเข้าบริการคลาวด์ก็หยุดตามไปด้วย ความต่างนี้แทบแยกไม่ออกจากหน้าตาของแผนผังโครงสร้าง ถ้าข้อเสนอของผู้ขายเขียนไว้แค่ว่า “เชื่อมต่อกับ AD” ขอให้ตรวจสอบให้แน่ชัดว่าเป็นแบบไหน

แบบที่ 3 AD ออนพรีมิสอย่างเดียว เป็นโครงสร้างที่แอปฝั่งคลาวด์ก็ใช้ได้เฉพาะจากเครื่องที่ join โดเมนของ AD ออนพรีมิสเท่านั้น ถึงวงจรขาด การล็อกอินภายในโรงงานก็ยังผ่าน แต่แน่นอนว่าต่อไปยังแอปบนคลาวด์ไม่ได้ เป็นสภาพที่การยืนยันตัวตนยังมีชีวิตแต่แอปตายแล้ว ซึ่งเมื่อมองจากหน้างานจะแยกไม่ออกจากแบบที่ 1

นอกจาก 3 แบบนี้ ยังต้องตรวจสอบสิ่งที่การยืนยันตัวตนแบบหลายปัจจัย (MFA) พึ่งพาอยู่ด้วย ในการใช้งานที่ยืนยันปัจจัยที่สองด้วยแอปยืนยันตัวตนหรือ SMS ต่อให้วงจรของโรงงานยังมีชีวิต ถ้าสัญญาณโทรศัพท์มือถือมีปัญหา การยืนยันตัวตนก็ไม่ผ่าน ความพร้อมใช้งานของการยืนยันตัวตนไม่ได้ถูกกำหนดด้วยเครือข่ายภายในองค์กรเพียงอย่างเดียว

การออกฉลากและการบันทึกผลการผลิตหยุดเพราะล็อกอินไม่ได้

ขอเขียนให้เห็นภาพว่าเกิดอะไรขึ้นจริง

เวลา 7.30 น. หน้างานเริ่มกะ เปิดเครื่องแฮนดี้เทอร์มินอล พนักงานแตะบัตรประจำตัว แล้วการยืนยันตัวตนไม่ผ่าน สาเหตุคืออุปกรณ์ฝั่งวงจรสื่อสารเสียไปตั้งแต่คืนก่อน เซิร์ฟเวอร์ยังทำงาน แอปก็ยังทำงาน ข้อมูลก็ปลอดภัย แต่ไม่มีใครล็อกอินได้

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

และหลังกู้คืนระบบยังมีอีกด่านหนึ่ง เวลากรอกผลการผลิต 3 ชั่วโมงที่จดบนกระดาษย้อนหลัง เวลาที่บันทึกมักกลายเป็นเวลาขณะที่กรอกทั้งหมด ข้อมูลเวลาของความคืบหน้ากระบวนการจะคลาดไป 3 ชั่วโมง และการวิเคราะห์ lead time ของวันนั้นจะใช้ไม่ได้ ปัญหาที่หนักกว่าไม่ใช่ข้อมูล 1 วันหายไป แต่คือข้อมูลที่ผิด 1 วันเข้าไปอยู่ในระบบ

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

สี่ข้อออกแบบเพื่อไม่ให้การยืนยันตัวตนล้ม

มาตรการมี 4 ข้อ ไม่ต้องใช้เทคโนโลยีพิเศษ เพียงแค่ตัดสินใจในสิ่งที่ควรตัดสินใจ

1. ระบุ RTO ของการยืนยันตัวตนให้ชัด และปรับให้เท่ากับฟังก์ชันที่สั้นที่สุด เขียนลงเอกสารข้อกำหนด 1 บรรทัดว่า “RTO ของการยืนยันตัวตน 15 นาที” แค่นี้เนื้อหาข้อเสนอของผู้ขายก็เปลี่ยน ผู้ขายที่ถูกสั่งให้ออกแบบการยืนยันตัวตนที่กู้คืนได้ใน 15 นาที จะเสนอโครงสร้างที่ฝากไว้กับ IdP ตัวเดียวไม่ได้อีกต่อไป ในทางกลับกัน ถ้าไม่มีบรรทัดนี้ การยืนยันตัวตนจะไม่อยู่ในความรับผิดชอบของใครเลยจนงานสร้างระบบจบลง

2. ทำเส้นทางการยืนยันตัวตนให้มีสองทาง สร้างสภาพที่ฝั่งคลาวด์กับฝั่งออนพรีมิส ถ้าฝั่งใดฝั่งหนึ่งล้ม อีกฝั่งยังยืนยันตัวตนผ่านได้ password hash synchronization ที่กล่าวไปข้างต้นคือตัวอย่างหนึ่ง สิ่งสำคัญไม่ใช่ “ทำสองทางไว้แล้ว” แต่คือ “ทดสอบปิดฝั่งหนึ่งแล้วยืนยันว่าผ่านจริง” ขอให้จัดการหยุดระบบตามแผนปีละ 1 ครั้งเพื่อทดสอบ failover โครงสร้างสำรองที่ไม่เคยทดสอบ ไม่ใช่โครงสร้างสำรอง

3. ออกแบบอายุของ token และ cache แยกตามฟังก์ชัน เครื่องหน้างานกับเครื่องสำนักงานไม่จำเป็นต้องตั้งค่าเหมือนกัน แฮนดี้เทอร์มินอลหน้างานเป็นเครื่องที่มีเฉพาะพนักงานที่กำหนดใช้ในสถานที่ที่กำหนด ตรงนี้ตั้งอายุ token ให้ยาวหน่อย เพื่อให้ยังทำงานต่อได้ระยะหนึ่งแม้วงจรขาด ในทางกลับกัน เครื่องสำนักงานที่เข้าถึงได้จากนอกบริษัทด้วยให้ตั้งสั้น จุดสมดุลระหว่างความปลอดภัยกับความพร้อมใช้งานให้หาในหน่วยของเครื่องและฟังก์ชัน ไม่ใช่หน่วยของระบบ

4. เตรียม fallback สำหรับยืนยันตัวตนแบบออฟไลน์ไว้ที่เครื่องหน้างาน เฉพาะช่วงที่วงจรขาด ให้ยืนยันตัวตนผ่าน cached credential ในเครื่องหรือบัตร IC และให้ทำได้ต่อเนื่องเฉพาะการออกฉลากกับการบันทึกผลการผลิต พร้อมกันนั้น ให้เตรียมบัญชีผู้ดูแลระบบที่ใช้เฉพาะยามฉุกเฉิน (บัญชี break-glass) และวิธีทดแทนเมื่อใช้ MFA ไม่ได้ และทำให้มีคนรับรู้ถึงการมีอยู่และที่เก็บของสิ่งเหล่านี้อย่างน้อย 2 คน คือผู้จัดการโรงงานกับผู้รับผิดชอบด้านระบบสารสนเทศ บัญชีที่มีคนรู้เพียง 1 คน จะไม่ทำงานในวันที่คนคนนั้นหยุด

ตัวแปรสำคัญไม่ใช่แบนด์วิดท์ แต่คือจำนวนรอบไป-กลับ | ความเข้ากันของแฮนดี้เทอร์มินอลกับคลาวด์

เรื่องที่ได้รับการปรึกษามากเป็นอันดับรองจากการยืนยันตัวตน คือ “ขึ้นคลาวด์แล้วหน้างานจะช้าลงหรือเปล่า” ตรงนี้ก็เช่นกัน จุดที่มองมักคลาดออกไป

ปัญหา 1 สแกน 5 รอบไป-กลับ

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

การเห็นตัวเลขนี้แล้วคิดว่า “แค่ 70 ms มนุษย์แยกไม่ออกหรอก” คือความผิดพลาดข้อแรก ปัญหาไม่ใช่ความหน่วงครั้งเดียว แต่คือใน 1 การทำงานเกิดการสื่อสารกี่ครั้ง

เมื่อสแกนบาร์โค้ดบนป้ายบ่งชี้ชิ้นงาน 1 ครั้งด้วยแฮนดี้เทอร์มินอล ภายในระบบจะเกิดการสื่อสารหลายครั้ง โดยทั่วไปคือ การตรวจสอบ token ของการยืนยันตัวตน การสอบถามข้อมูลหลักของรหัสสินค้า การจองสต๊อก การลงทะเบียนผลการผลิต และการสั่งพิมพ์ฉลาก ขึ้นอยู่กับวิธีพัฒนา ตรงนี้อาจกลายเป็น 5 รอบไป-กลับ

กรณีวางไว้ที่รีเจี้ยนโตเกียว ถ้าใช้ค่าโดยประมาณของ RTT ที่ 80 ms เฉพาะส่วนไป-กลับก็บวกเพิ่ม 5 × 80 ms = 0.4 วินาที เวลาประมวลผลของเซิร์ฟเวอร์บวกแยกต่างหากจากนี้ ถ้าเป็นรีเจี้ยนภายในประเทศที่กรุงเทพฯ ใช้ค่าโดยประมาณ 10 ms ก็เป็น 5 × 10 ms = 0.05 วินาที ระบบที่พัฒนาแบบเดียวกัน แค่เปลี่ยนที่วางก็ต่างกัน 0.35 วินาที

การรู้สึกว่า 0.4 วินาที “ไม่ใช่เรื่องใหญ่” หรือไม่ ขึ้นอยู่กับจำนวนครั้ง สมมติหน้างานที่สแกนวันละ 1,000 ครั้ง เฉพาะส่วนไป-กลับก็เป็น 0.4 วินาที × 1,000 ครั้ง = 400 วินาที หรือประมาณ 6.7 นาที และเนื่องจากนี่คือเวลารอ พนักงานจึงต้องยืนถือแฮนดี้เทอร์มินอลอยู่ตลอดช่วงนั้น

สิ่งสำคัญตรงนี้คือ การเพิ่มแบนด์วิดท์ไม่ทำให้ตัวเลขนี้ดีขึ้น เพราะความหน่วงไป-กลับถูกกำหนดด้วยความเร็วแสงและความยาวเส้นทาง เปลี่ยนจาก 100 Mbps เป็น 1 Gbps ก็ไม่เปลี่ยน วิธีปรับปรุงมีเพียง 2 ทาง คือย่นระยะทางโดยใช้รีเจี้ยนภายในประเทศ หรือลดจำนวนรอบไป-กลับ

ดังนั้น สิ่งที่ต้องถามผู้ขายไม่ใช่ “ต้องใช้วงจรกี่ Mbps” แต่คือ “การทำงานหลักของหน้างาน 1 ครั้ง เกิดการไป-กลับกับเซิร์ฟเวอร์กี่รอบ” ผู้ขายที่ตอบคำถามนี้ได้ทันทีมีไม่มาก ถ้าตอบไม่ได้ ขอให้สั่งวัดจริงด้วย PoC (การพิสูจน์แนวคิด) ถ้าให้ฝั่งแฮนดี้เทอร์มินอลออก log ก็วัดได้

อนึ่ง จำนวนรอบไป-กลับถูกกำหนดด้วยแนวคิดการออกแบบของแพ็กเกจ การลดในภายหลังจึงไม่ง่าย การปรับปรุงอย่าง “อ่านข้อมูลหลักล่วงหน้ารวดเดียวตอนสแกน” หรือ “ทำการลงทะเบียนผลการผลิตให้เป็นแบบ asynchronous” ทำได้ แต่ทั้งหมดคือการพัฒนาเพิ่ม เป็นหัวข้อที่ควรตรวจสอบตั้งแต่ขั้นคัดเลือก

จะวางบัฟเฟอร์ออฟไลน์ไว้ที่ไหน

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

ทางเลือกของที่วางมี 3 แบบ

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

วางไว้ที่เอดจ์เซิร์ฟเวอร์ในโรงงาน วางเซิร์ฟเวอร์ขนาดเล็ก 1 เครื่องในโรงงาน ให้รับหน้าที่ทำสำเนาข้อมูลหลัก พิมพ์ฉลาก และรับผลการผลิตชั่วคราว เครื่องปลายทางสื่อสารกับเอดจ์เซิร์ฟเวอร์นี้ตลอด และเอดจ์เซิร์ฟเวอร์ซิงค์กับคลาวด์ เพราะระหว่างวงจรขาดยังรักษาความสอดคล้องของหลายเครื่องภายในโรงงานได้ จึงทำงานต่อได้ถึงระดับการจองสต๊อก นี่คือแกนกลางของโครงสร้างไฮบริดที่จะกล่าวถึงต่อไป จุดอ่อนคือเครื่องนี้เพียงเครื่องเดียวกลายเป็นจุดล้มเหลวจุดเดียว และต้องพัฒนาตรรกะการซิงค์เพิ่ม

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

จะเลือกแบบไหน สุดท้ายก็ต้องกลับมาที่ตาราง RTO ถ้าการออกฉลากคือ 5-15 นาที โครงสร้างที่อาจใช้เวลากู้คืนเกิน 15 นาทีย่อมไม่พอ ถ้าการบันทึกผลการผลิตคือ 2-4 ชั่วโมง บัฟเฟอร์ฝั่งเครื่องอาจเพียงพอ เพราะคำตอบต่างกันไปตามฟังก์ชัน ตรงนี้ก็เช่นกัน ให้ตัดสินด้วย “แต่ละฟังก์ชันจะทำอย่างไร” ไม่ใช่ “ทั้งระบบจะทำอย่างไร”

เปรียบเทียบต้นทุน 5 ปีของระบบบริหารการผลิตแบบคลาวด์กับออนพรีมิส [ประมาณการของเราเอง]

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

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

เงื่อนไขตั้งต้นของโรงงานตัวอย่าง

• ที่ตั้ง เขตปริมณฑลกรุงเทพฯ ฐานการผลิตเดียว มีบริษัทแม่ที่ญี่ปุ่น
• พนักงาน 180 คน
• ผู้ใช้ระบบบริหารการผลิต 40 คน (สำนักงาน 25 คน และหน้างาน 15 คน)
• เครื่องปลายทางหน้างาน แฮนดี้เทอร์มินอล 15 เครื่อง และแท็บเล็ต 10 เครื่อง
• สกุลเงิน THB (บาทไทย)
• ระยะเวลาเปรียบเทียบ 5 ปี

ค่าเครื่องปลายทางหน้างาน (750,000 THB) ลงบัญชีเป็นจำนวนเท่ากันในทั้ง 3 สถานการณ์ เพราะไม่ว่าจะเลือกคลาวด์หรือออนพรีมิส เครื่องที่หน้างานใช้ก็จำเป็นอยู่ดี เราเคยเห็นใบเสนอราคาที่ลงรายการนี้ไว้ในฝั่งเดียว แบบนั้นเทียบกันไม่ได้

ต้นทุนรวม 5 ปีของ 3 สถานการณ์

สถานการณ์ A ฟูลคลาวด์ (SaaS)

ค่าดำเนินงาน 5 ปี 4,320,000 + 720,000 + 1,500,000 = 6,540,000 THB

ต้นทุนรวม 5 ปี 9,210,000 THB

สถานการณ์ B ฟูลออนพรีมิส

ค่าดำเนินงาน 5 ปี 3,000,000 + 1,500,000 = 4,500,000 THB

ต้นทุนรวม 5 ปี 11,280,000 THB

สถานการณ์ C ไฮบริด (ระบบหน้างานเป็นออนพรีมิส ระบบบริหารจัดการเป็นคลาวด์)

ค่าดำเนินงาน 5 ปี 2,700,000 + 720,000 + 1,400,000 + 2,000,000 = 6,820,000 THB

ต้นทุนรวม 5 ปี 11,650,000 THB

เรียง 3 สถานการณ์ไว้ด้วยกัน

ส่วนต่างเป็นดังนี้

• B − A = 2,070,000 THB (ออนพรีมิสแพงกว่าคลาวด์ 2,070,000 THB ในกรอบ 5 ปี)
• C − A = 2,440,000 THB
• C − B = 370,000 THB

ขอยกประเด็นที่ควรอ่านออกมา 3 ข้อ

ข้อแรก เมื่อมองที่ 5 ปี คลาวด์ถูกที่สุด ส่วนต่างคือ 2,070,000 THB ซึ่งไม่มากเท่าส่วนต่างของค่าเริ่มต้น (6,780,000 − 2,670,000 = 4,110,000) แต่ก็ไม่ใช่จำนวนที่มองข้ามได้

ข้อที่สอง ไฮบริดของสถานการณ์ C แพงที่สุด ตรงนี้คือจุดที่พลิกกลับในการประชุมหลายครั้ง ไฮบริดมักถูกเข้าใจว่า “อยู่กึ่งกลางระหว่างคลาวด์กับออนพรีมิส ค่าใช้จ่ายก็น่าจะอยู่กึ่งกลาง” แต่ในความเป็นจริงมันบวกทั้งค่าเริ่มต้นของทั้งสองฝั่งและค่าดำเนินงานของทั้งสองฝั่ง ทั้งเอดจ์เซิร์ฟเวอร์ ไลเซนส์ SaaS และการทำวงจรสำรอง จำเป็นทั้งหมด ส่วนของการออกแบบการเชื่อมต่อยังทำให้ทั้งค่าสนับสนุนการติดตั้งและการพัฒนาเพิ่มสูงขึ้นด้วย ผลลัพธ์คือแพงกว่าฟูลคลาวด์ 2,440,000 THB และแพงกว่าฟูลออนพรีมิส 370,000 THB

ข้อที่สาม ส่วนต่างของทั้ง 3 แบบนี้ เมื่อมองเป็นยอดรวม 5 ปี ยังอยู่ในระดับหลักเดียวกัน ส่วนต่างระหว่าง 9,210,000 กับ 11,650,000 ไม่ได้ต่างกันเป็นหลักที่จะพลิกการตัดสินใจได้ในทีเดียว ด้วยเหตุนี้เอง จึงจำเป็นต้องมีเกณฑ์อื่นนอกเหนือจากค่าใช้จ่าย

จุดกลับด้านอยู่ที่ 10.1 ปี และเป็น 13.4 ปีเมื่อรวมการเปลี่ยนทดแทน

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

สมการต้นทุนสะสมเป็นดังนี้ โดย n คือจำนวนปี

• สะสมของ A = 2,670,000 + 1,308,000n
• สะสมของ B = 6,780,000 + 900,000n

ส่วนต่างของค่าใช้จ่ายรายปีคือ 1,308,000 − 900,000 = 408,000 ส่วนต่างของค่าเริ่มต้นคือ 4,110,000 เครื่องหมายเท่ากับเป็นจริงเมื่อ 408,000n = 4,110,000 นั่นคือ n = 10.1 ปี

ตรวจทานคำนวณ เมื่อ n = 5 ได้ A = 9,210,000 และ B = 11,280,000 เมื่อ n = 10 ได้ A = 15,750,000 และ B = 15,780,000 ยืนยันได้ว่าปีที่ 10 B ยังสูงกว่า และกลับด้านทันทีหลังจากนั้น

ตรงนี้ขอเพิ่มค่าใช้จ่ายที่เกิดขึ้นแน่นอนในความเป็นจริงอีก 1 รายการ คือการเปลี่ยนทดแทนฮาร์ดแวร์และ OS เซิร์ฟเวอร์จะหมดสัญญาบำรุงรักษาใน 5 ปี และ OS ก็มีวันสิ้นสุดการสนับสนุน ถ้าใส่ค่าเซิร์ฟเวอร์ 900,000 และไลเซนส์ OS กับ DB 450,000 รวม 1,350,000 THB เข้าไป 1 ครั้งในปีที่ 6 จะได้

• สะสมของ B = 8,130,000 + 900,000n
• 408,000n = 5,460,000 จึงได้ n = 13.4 ปี

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

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

ถ้ามองที่กรอบ 5 ปี ตัวที่กลับด้านไม่ใช่จำนวนปี แต่คือจำนวนผู้ใช้ (ประมาณ 59 คน)

ยังมีอีกแกนหนึ่งเกี่ยวกับค่าใช้จ่ายที่มักถูกมองข้าม คือจำนวนผู้ใช้

ไลเซนส์ของสถานการณ์ A คิดตามการใช้งานที่ 1,800 THB ต่อคนต่อเดือน ถ้าผู้ใช้เพิ่ม ค่าใช้จ่ายก็เพิ่มตามสัดส่วน ส่วนไลเซนส์แบบซื้อขาดของออนพรีมิส ยอดรวมไม่เปลี่ยนแม้จำนวนคนจะเพิ่มขึ้นในระดับหนึ่ง ดังนั้น การกลับด้านเมื่อมองที่กรอบเวลาคงที่ 5 ปี จึงเกิดจากจำนวนคน ไม่ใช่จำนวนปี

เมื่อให้ผู้ใช้เป็น u คน ต้นทุนรวม 5 ปีของสถานการณ์ A เป็นดังนี้

ต้นทุนรวม 5 ปีของ A = 4,890,000 + 108,000u

รายละเอียดคือ ค่าเริ่มต้น 2,670,000 บวก 5 ปี × (ไลเซนส์รายปี 21,600u บวกวงจรสื่อสาร 144,000 บวกการพัฒนาเพิ่ม 300,000) = 2,670,000 + 108,000u + 2,220,000

ค่านี้เท่ากับ 11,280,000 ของสถานการณ์ B เมื่อ 108,000u = 6,390,000 นั่นคือ u ประมาณ 59 คน

ตรวจทานคำนวณ เมื่อ u = 40 ได้ 9,210,000 ซึ่งตรงกับสถานการณ์ A เมื่อ u = 70 ได้ 12,450,000 ซึ่งสูงกว่า 11,280,000 ของสถานการณ์ B

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

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

ที่ตั้งข้อมูลของฐานการผลิตในไทยกับ PDPA | กรณีที่การส่งออกนอกประเทศเป็นปัญหาและกรณีที่ไม่เป็น

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

สำหรับ PDPA ของไทย (พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล) กฎเกณฑ์ว่าด้วยการส่งข้อมูลออกนอกประเทศ ได้แก่ ประกาศรายชื่อประเทศปลายทางและประกาศว่าด้วย BCR และมาตรการคุ้มครองที่เหมาะสม มีผลบังคับใช้เมื่อวันที่ 24 มีนาคม 2024 ฐานของการส่งข้อมูลมี 3 ทาง คือ หนึ่ง ส่งไปยังประเทศที่ได้รับการรับรองว่ามีมาตรฐานเพียงพอ สอง BCR (นโยบายคุ้มครองข้อมูลภายในเครือกิจการที่มีผลผูกพัน) และสาม มาตรการคุ้มครองที่เหมาะสม เช่น ข้อสัญญามาตรฐาน

และสิ่งที่สำคัญในทางปฏิบัติคือ ณ ปี 2025 PDPC (คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ยังไม่ได้ประกาศรายชื่อประเทศที่ได้รับการรับรองว่ามีมาตรฐานเพียงพอ ดังนั้น ในระยะนี้ต้องถือว่าการส่งข้อมูลออกนอกประเทศทุกกรณีเป็นการส่งไปยังปลายทางที่ยังไม่ได้รับการรับรอง และต้องมีมาตรการคุ้มครองตามข้อสองหรือข้อสาม การสรุปว่า “ญี่ปุ่นมีกฎหมายคุ้มครองข้อมูลส่วนบุคคลอยู่แล้วจึงไม่มีปัญหา” อย่างน้อยก็ไม่เป็นจริงในฐานตามข้อหนึ่ง

เมื่อมองอย่างใจเย็นตรงนี้ ข้อมูลส่วนใหญ่ที่ระบบบริหารการผลิตจัดการไม่ใช่ข้อมูลส่วนบุคคล รหัสสินค้า BOM กระบวนการผลิต เครื่องจักร ปริมาณสต๊อก หมายเลขล็อต ต้นทุน สิ่งเหล่านี้อยู่นอกขอบเขตของ PDPA ต่อให้วางไว้ที่รีเจี้ยนนอกประเทศ ก็ไม่กลายเป็นประเด็นการส่งข้อมูลออกนอกประเทศตาม PDPA

สิ่งที่กลายเป็นปัญหาคือรายการต่อไปนี้

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

ในกลุ่มนี้ ข้อมูลชีวมิติต้องระวังเป็นพิเศษ การถกเรื่องว่าจะจัดการการยืนยันตัวตนอย่างไรเมื่อครู่ กับการถกเรื่องที่ตั้งข้อมูล มาบรรจบกันตรงนี้ ความต้องการที่ว่า “อยากให้ล็อกอินหน้างานใช้ลายนิ้วมือ” สมเหตุสมผลในเชิงการใช้งาน แต่ ณ วินาทีนั้น องค์กรก็เริ่มถือครองข้อมูลที่ต้องใช้ความระมัดระวังมากขึ้น ขอให้ตรวจสอบกับฝ่ายกฎหมายตั้งแต่ขั้นออกแบบว่าจะเก็บเทมเพลตไว้ที่ใด จะออกนอกประเทศหรือไม่ และจะขอความยินยอมอย่างไร

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

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

สี่กำหนดเวลาที่ต้องตัดสินใจไว้ก่อน ถ้าเลือกออนพรีมิส

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

อย่างไรก็ตาม ถ้าเลือกออนพรีมิส ขอให้ตัดสินใจ 4 กำหนดเวลานี้ไว้ก่อน ถ้านำมาใช้โดยไม่ตัดสินใจ อีก 5 ปีจะได้ “เซิร์ฟเวอร์ที่ยังทำงานอยู่แต่ไม่มีใครแตะได้”

1. วันสิ้นสุดการสนับสนุนของ OS การสนับสนุนแบบขยายของ Windows Server 2016 (บริษัท Microsoft) จะสิ้นสุดในวันที่ 12 มกราคม 2027 ถ้าตอนนี้ในโรงงานมีเซิร์ฟเวอร์ที่รันด้วย 2016 อยู่ ก็คำนวณย้อนกลับได้ว่าเหลือเวลาผ่อนผันเท่าไร กรณีสร้างขึ้นใหม่ก็เช่นกัน ขอให้เขียนวันสิ้นสุดการสนับสนุนแบบขยายของ OS ที่เลือกลงในเอกสารขออนุมัติ เมื่อมีบรรทัดนี้ ช่วงเวลาที่ต้องตั้งงบสำหรับการเปลี่ยนทดแทนครั้งถัดไปก็ถูกกำหนดโดยอัตโนมัติ

2. วันสิ้นสุดการสนับสนุนของฐานข้อมูล SQL Server 2019 (บริษัท Microsoft) สิ้นสุดการสนับสนุนหลักเมื่อวันที่ 28 กุมภาพันธ์ 2025 และการสนับสนุนแบบขยายจะสิ้นสุดในวันที่ 8 มกราคม 2030 การที่การสนับสนุนหลักจบไปแล้วหมายความว่า โดยหลักการจะไม่มีการเพิ่มฟังก์ชันและไม่มีการแก้ไขที่มาพร้อมการเปลี่ยนข้อกำหนด ระบบยังทำงานได้ แต่ตอบสนองความต้องการใหม่ไม่ได้

3. วันสิ้นสุดการบำรุงรักษาฮาร์ดแวร์ สัญญาบำรุงรักษาเซิร์ฟเวอร์โดยทั่วไปคือ 5 ปี เมื่อเกิน 5 ปี การจัดหาอะไหล่สำหรับการบำรุงรักษาจะหยุด และวิธีกู้คืนเมื่อเครื่องเสียจะกลายเป็น “หาเครื่องรุ่นเดียวกันมือสอง” การรักษา “RTO 15 นาที” ในสภาพนี้เป็นไปไม่ได้ ขอให้เรียงวันสิ้นสุดสัญญาบำรุงรักษากับ RTO ของแต่ละฟังก์ชันไว้ในตารางเดียวกันเพื่อตรวจสอบ

4. กำหนดเวลาของคน เป็นกำหนดเวลาที่ถูกมองข้ามมากที่สุด คนที่ตั้งค่าเซิร์ฟเวอร์เครื่องนั้น อีก 5 ปีจะยังอยู่ที่ฐานการผลิตนี้หรือไม่ ผู้รับผิดชอบด้านระบบสารสนเทศของโรงงานญี่ปุ่น ถ้าเป็นพนักงานที่ส่งมาประจำการก็มีวาระ ถ้าเป็นพนักงานท้องถิ่นก็มีการย้ายงาน สภาพแวดล้อมออนพรีมิสที่สร้างขึ้นโดยผูกกับตัวบุคคล จะกลายเป็นกล่องดำทันทีที่ผู้รับผิดชอบพ้นตำแหน่ง ขอให้ผูกที่เก็บข้อมูลการตั้งค่าและรหัสผ่านไว้กับองค์กร ไม่ใช่กับตัวบุคคล ในทางรูปธรรมคือ รวมแผนผังโครงสร้าง ทะเบียน IP address รายการบัญชีผู้ดูแลระบบ และรายชื่อผู้ติดต่อของผู้ขาย ไว้ในเอกสารเดียว เก็บไว้ 2 แห่งคือที่บริษัทแม่ในญี่ปุ่นและที่ประเทศไทย และปรับปรุงปีละ 1 ครั้ง การมีหรือไม่มีแนวปฏิบัตินี้ทำให้ทางเลือกในอีก 5 ปีต่างกัน

อนึ่ง ในบรรดา 4 กำหนดเวลานี้ ข้อ 1 ข้อ 2 และข้อ 3 จะย้ายไปอยู่ในขอบเขตความรับผิดชอบของผู้ให้บริการเมื่อเลือกคลาวด์ สิ่งที่รวมอยู่ในค่าใช้จ่ายของคลาวด์ไม่ได้มีเพียงทรัพยากรการประมวลผล แต่ยังรวมถึงการโอนการบริหารกำหนดเวลาเหล่านี้ออกไปข้างนอกด้วย ส่วนต่างรายปี 408,000 THB ที่เห็นในประมาณการ จะมองว่าแพงหรือสมเหตุสมผล ขึ้นอยู่กับว่าบริษัทท่านมีทีมงานที่จะดูแลการบริหารนี้ต่อไปหรือไม่

สามรูปแบบของโครงสร้างไฮบริด

อย่างที่เห็นในสถานการณ์ C ไฮบริดไม่ได้ถูก แพงกว่าฟูลคลาวด์ 2,440,000 THB และแพงกว่าฟูลออนพรีมิส 370,000 THB เหตุผลที่ยังเลือกไฮบริดไม่ใช่ค่าใช้จ่าย แต่คือระยะเวลาหยุดที่ยอมรับได้ ถ้าไม่สื่อสารประเด็นนี้ตั้งแต่แรก ระหว่างทางของการขออนุมัติจะเกิดข้อถกเถียงว่า “เลือกไฮบริดแล้วทำไมยังแพง” อย่างแน่นอน

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

บนพื้นฐานนั้น ไฮบริดมี 3 รูปแบบในทางปฏิบัติ

รูปแบบที่ 1 ระบบหน้างานเป็นออนพรีมิส ระบบบริหารจัดการเป็นคลาวด์ สถานการณ์ C คือแบบนี้ วางฟังก์ชันที่มีระยะเวลาหยุดที่ยอมรับได้สั้น เช่น การออกฉลาก การบันทึกผลการผลิต และการจองสต๊อก ไว้ที่เอดจ์เซิร์ฟเวอร์ในโรงงาน แล้ววางการจัดซื้อ ต้นทุน การวิเคราะห์ และการจัดการข้อมูลหลักไว้บนคลาวด์ เพราะเส้นแบ่งชัดเจนในเชิงงาน ขอบเขตความรับผิดชอบจึงชัดเจนด้วย จุดอ่อนคือต้องถือไลเซนส์ทั้งฝั่งระบบหน้างานและฝั่งคลาวด์ซ้อนกัน และส่วนการเชื่อมต่อกลายเป็นการพัฒนาเพิ่ม เหตุที่การพัฒนาเพิ่มในประมาณการเป็น 400,000 THB ซึ่งสูงกว่า 300,000 THB ของฟูลคลาวด์ ก็เพราะเรื่องนี้

รูปแบบที่ 2 ตัวระบบหลักอยู่บนคลาวด์ ในโรงงานวางเพียง cache แบบอ่านอย่างเดียวและฟังก์ชันพิมพ์ เป็นโครงสร้างที่วางตัวระบบหลักทั้งหมดไว้บนคลาวด์ ส่วนในโรงงานวางเพียงสำเนาข้อมูลหลักของรหัสสินค้าและสต๊อก กับฟังก์ชันพิมพ์ฉลาก เพราะการเขียนข้อมูลจะไปที่คลาวด์เสมอ ความสอดคล้องของข้อมูลจึงรักษาได้ง่าย ระหว่างวงจรขาดจะทำได้เพียง “ดู” และ “พิมพ์” แต่ “ลงทะเบียน” ไม่ได้ สร้างได้ถูกกว่ารูปแบบที่ 1 แต่เพราะทำการบันทึกผลการผลิตต่อไม่ได้ จึงไม่พอสำหรับโรงงานที่ RTO ของการบันทึกผลการผลิตสั้น

รูปแบบที่ 3 ระบบจริงอยู่บนคลาวด์ ออนพรีมิสใช้เฉพาะการเดินระบบแบบจำกัด เป็นโครงสร้างที่ยามปกติเดินทุกอย่างบนคลาวด์ และวางเซิร์ฟเวอร์ในโรงงานไว้สำหรับการเดินระบบแบบจำกัด โดยจะเปิดใช้เฉพาะยามภัยพิบัติหรือยามวงจรขาดเป็นเวลานาน เป็นการนำแนวคิด DR (การกู้คืนจากภัยพิบัติ) มาใช้ตรง ๆ หลุมพรางที่ใหญ่ที่สุดคือ เพราะไม่ได้ใช้ฝั่งจำกัดในยามปกติ พอถึงเวลาจำเป็นจริงจึงใช้ไม่ได้ ระบบสำรองที่ไม่ได้ใช้งานย่อมเสื่อมสภาพเสมอ ขอให้ใส่การฝึกซ้อมเดินระบบครึ่งวันด้วยฝั่งจำกัดเพียงอย่างเดียว ไตรมาสละ 1 ครั้ง ไว้ในการออกแบบการปฏิบัติการ ถ้าใส่การฝึกซ้อมไม่ได้ ไม่ควรเลือกรูปแบบนี้

ทั้ง 3 รูปแบบมีวิธีตัดสินเหมือนกัน คือวางตาราง RTO ของแต่ละฟังก์ชันไว้ข้าง ๆ แล้วตัดสินทีละบรรทัดว่า “ฟังก์ชันนี้วางไว้ฝั่งไหนจึงจะได้ตามค่าในตาราง” เท่านั้นเอง ไม่มีจุดใดที่ตัดสินด้วยความชอบทางเทคนิค

เจ็ดข้อที่ต้องตัดสินใจก่อนสั่งซื้อ (เช็กลิสต์)

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

ขอเสริมข้อ 7 กรณีเลือก SaaS ขอให้ตรวจสอบในสัญญาว่าเมื่อสิ้นสุดสัญญาจะรับข้อมูลกลับมาได้ในรูปแบบใด แค่ “ส่งออกเป็น CSV ได้” ยังไม่พอ ต้องตรวจสอบเป็นรายข้อว่าโครงสร้างลำดับชั้นของข้อมูลหลัก ความสัมพันธ์แม่ลูกของ BOM ไฟล์แนบ และประวัติการเปลี่ยนแปลง รวมอยู่ในสิ่งที่ส่งออกได้หรือไม่ ถ้าใช้งานไป 5 ปีโดยที่จุดนี้ยังคลุมเครือ พอถึงการเปลี่ยนระบบครั้งถัดไปจะตกอยู่ในสภาพ “ค่าย้ายข้อมูลแพงเกินจนขยับไม่ได้” ข้อกำหนดการขึ้นราคาก็เช่นกัน ถ้าสัญญาไม่ได้เขียนเพดานอัตราการปรับราคาต่อปีไว้ การประมาณการต้นทุนรวม 5 ปีก็ไม่มีความหมายตั้งแต่ต้น

ข้อ 6 ก็สำคัญในทางปฏิบัติ ถ้าไม่ให้ยื่นในรูปแบบเดียวกัน ข้อเสนอที่ถูกเฉพาะค่าเริ่มต้นแต่แพงในค่ารายปีจะดูได้เปรียบ อย่างที่แสดงในประมาณการ ในขนาดนี้ ส่วนต่างของค่ารายปีกลายเป็นส่วนต่างระดับหลายล้าน THB ใน 5 ปี ขอให้ฝ่ายผู้สั่งซื้อเป็นผู้กำหนดรูปแบบการยื่น

คำถามที่พบบ่อย (FAQ)

ระบบบริหารการผลิตแบบคลาวด์กับออนพรีมิส แบบไหนถูกกว่า

ขึ้นอยู่กับระยะเวลาที่ใช้เปรียบเทียบ ในโรงงานตัวอย่างของบทความนี้ ซึ่งมีพนักงาน 180 คนและผู้ใช้ 40 คน ต้นทุนรวม 5 ปีของฟูลคลาวด์คือ 9,210,000 THB และฟูลออนพรีมิสคือ 11,280,000 THB คลาวด์จึงถูกกว่า 2,070,000 THB ต้นทุนสะสมจะกลับด้านในปีที่ 10.1 และถ้าใส่การเปลี่ยนทดแทนฮาร์ดแวร์กับ OS จำนวน 1,350,000 THB เข้าไป 1 ครั้งในปีที่ 6 ก็จะเป็นปีที่ 13.4 เพราะไม่อยู่ในกรอบ 5-7 ปีซึ่งเป็นช่วงเวลาตัดสินใจลงทุนตามปกติ ในขนาดนี้จึงไม่ได้คำตอบแม้ใช้ค่าใช้จ่ายเป็นเกณฑ์ตัดสิน ขอให้ตัดสินด้วยระยะเวลาหยุดที่ยอมรับได้

ราคาตลาดของระบบบริหารการผลิตแบบคลาวด์อยู่ที่เท่าไร

เปลี่ยนแปลงมากตามขนาดและข้อกำหนดของฐานการผลิตในไทย จึงตัดสินจากราคาต่อหน่วยอย่างเดียวไม่ได้ เพื่อเป็นข้อมูลอ้างอิง ช่วงราคาของระบบบริหารการผลิตแบบคลาวด์ในประเทศญี่ปุ่น ระบุไว้ว่าเริ่มต้นประมาณ 30,000-50,000 เยนต่อเดือน ถ้าเป็นแบบคิดตามผู้ใช้จะอยู่ราว 10,000 เยนต่อคนต่อเดือน และค่าเริ่มต้นอยู่ในระดับหลักแสนเยน ส่วนแบบออนพรีมิสมีค่าเริ่มต้นประมาณ 1,000,000-3,000,000 เยน และประมาณ 30,000 เยนต่อเดือนเป็นค่าโดยประมาณ อย่างไรก็ตาม นี่คือราคาตลาดในประเทศญี่ปุ่น การนำมาใช้ในไทยจะมีชั่วโมงงานของการกำหนดข้อกำหนด การย้ายข้อมูลหลัก การรองรับภาษาไทย และการอบรมหน้างาน บวกเพิ่มต่างหาก เหตุที่ประมาณการในบทความนี้กำหนดค่าสนับสนุนการติดตั้งของฟูลคลาวด์ไว้ที่ 1,800,000 THB ก็คือส่วนนี้ ขอให้เปรียบเทียบด้วยยอดรวมของค่าเริ่มต้นบวกรายปีคูณ 5 ไม่ใช่ราคาไลเซนส์ต่อหน่วย

โรงงานในไทยใช้ระบบบริหารการผลิตแบบคลาวด์ได้ไหมในแง่ของวงจรสื่อสาร

ถูกกำหนดด้วยผลคูณของจำนวนรอบไป-กลับต่อ 1 การทำงานกับ RTT มากกว่าแบนด์วิดท์ ค่าโดยประมาณของ RTT คือ 5-15 ms สำหรับรีเจี้ยนภายในประเทศที่กรุงเทพฯ 25-40 ms สำหรับกรุงเทพฯ ถึงสิงคโปร์ และ 70-90 ms สำหรับกรุงเทพฯ ถึงโตเกียว ทั้งหมดนี้เป็นเพียงตัวเลขโดยประมาณที่สังเกตได้ทั่วไป ไม่ใช่ค่าที่แน่นอน ควรวัดจากวงจรของท่านเองเสมอ ถ้าเป็นการพัฒนาที่ 1 สแกนเกิด 5 รอบไป-กลับ ที่รีเจี้ยนโตเกียวเฉพาะส่วนไป-กลับก็บวกเพิ่ม 5 × 80 ms = 0.4 วินาที ถ้าเป็นรีเจี้ยนภายในประเทศที่กรุงเทพฯ จะเป็น 5 × 10 ms = 0.05 วินาที การเพิ่มแบนด์วิดท์ไม่ทำให้ส่วนต่างนี้แคบลง มีเพียง 2 วิธีเท่านั้น คือลดจำนวนรอบไป-กลับ หรือย่นระยะทาง

กรณีแบบไหนที่อยู่กับออนพรีมิสต่อไปก็เพียงพอ

กรณีที่ฟังก์ชันซึ่งมีระยะเวลาหยุดที่ยอมรับได้ 5-15 นาที เป็นแกนกลางของงาน และตั้งอยู่ในทำเลที่การทำวงจรสำรองไม่สมจริง เพิ่มเติมคือ ต้องมีทีมงานภายในฐานการผลิตที่บริหารกำหนดเวลาของ OS ฐานข้อมูล และการบำรุงรักษาฮาร์ดแวร์ได้อย่างต่อเนื่องด้วย ถ้ารักษาออนพรีมิสไว้โดยไม่มีทีมงานนี้ ทุกครั้งที่กำหนดเวลามาถึง เช่น การสนับสนุนแบบขยายของ Windows Server 2016 (บริษัท Microsoft) สิ้นสุดในวันที่ 12 มกราคม 2027 ก็จะถูกบังคับให้เปลี่ยนทดแทนแบบฉุกเฉิน ในทางกลับกัน ไม่มีเหตุผลที่จะวางฟังก์ชันอย่างการรวบรวมต้นทุนหรือการจัดซื้อ ซึ่งหยุด 3 วันทำการงานก็ยังเดินได้ ไว้ที่ออนพรีมิสด้วย ขอให้คิดด้วยคำถามว่า “จะเหลือฟังก์ชันใดไว้ที่ออนพรีมิส” ไม่ใช่ “อยู่กับออนพรีมิสต่อไปได้หรือไม่”

การย้ายระบบหลักขึ้นคลาวด์ใช้เวลานานแค่ไหน

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

สรุป

ปี 2026 กรุงเทพฯ มีคลาวด์รีเจี้ยนครบ และ “การวางข้อมูลไว้ภายในประเทศไทย” กลายเป็นทางเลือกมาตรฐานเป็นครั้งแรก แต่สิ่งที่เปลี่ยนไปมีเพียงข้อจำกัดเรื่องที่ตั้งข้อมูล กรอบของการตัดสินใจไม่ได้เปลี่ยน

สิ่งที่ควรเลิกทำคือการพยายามเลือกคำตอบเดียวให้ทั้งระบบว่าจะเอา “คลาวด์หรือออนพรีมิส” ภายในระบบบริหารการผลิตมีทั้งการออกฉลากที่หยุดได้แค่ 5-15 นาที และการรวบรวมต้นทุนที่หยุดได้ 3 วันทำการ อยู่ปะปนกัน การพยายามหาคำตอบเดียวให้สองสิ่งนี้คือเหตุที่ประชุมไม่จบ หน่วยของการตัดสินใจคือฟังก์ชัน

เกณฑ์ตัดสินไม่ใช่ค่าใช้จ่าย ในประมาณการของโรงงานตัวอย่าง ต้นทุนรวม 5 ปีคือ ฟูลคลาวด์ 9,210,000 THB ฟูลออนพรีมิส 11,280,000 THB และไฮบริด 11,650,000 THB ต้นทุนสะสมกลับด้านในปีที่ 10.1 และเป็นปีที่ 13.4 เมื่อใส่การเปลี่ยนทดแทน 1 ครั้ง ส่วนต่างที่ไม่อยู่ในกรอบการตัดสินใจลงทุน 5-7 ปี ทำงานเป็นเกณฑ์ตัดสินไม่ได้ อย่างไรก็ตาม ถ้ามองที่กรอบเวลาคงที่ 5 ปี ตัวที่กำหนดการกลับด้านไม่ใช่จำนวนปี แต่คือจำนวนคน เมื่อผู้ใช้เกินประมาณ 59 คน ยอดรวมของฟูลคลาวด์จะสูงกว่าฟูลออนพรีมิส ขอให้ยืนยันจำนวนผู้ใช้ในอีก 5 ปีไว้ก่อน

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

ถ้าเลือกไฮบริด ขอให้สื่อสารตั้งแต่แรกว่าไม่ได้เลือกเพราะมันถูก ในประมาณการ มันแพงกว่าฟูลคลาวด์ 2,440,000 THB และแพงกว่าฟูลออนพรีมิส 370,000 THB สิ่งที่กำลังซื้อไม่ใช่จำนวนเงิน แต่คือระยะเวลาหยุดที่ยอมรับได้ ถ้าเดินหน้าโดยไม่สื่อสารเงื่อนไขนี้ จะเกิดข้อพิพาทหลังเริ่มใช้งานอย่างแน่นอน

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

การแยกแยะว่าจะวางฟังก์ชันไว้ฝั่งไหน ตัดสินไม่ได้ถ้าไม่ได้ดูการปฏิบัติงานจริงที่หน้างานและสภาพจริงของวงจรสื่อสาร แม้จะเป็น “การออกฉลาก 15 นาที” เหมือนกัน เวลาที่ทนได้จริงก็เปลี่ยนไปตามขนาดพื้นที่พักของชั่วคราวและเวลาของรอบรถขนส่ง TOMAS TECH มีฐานอยู่ที่กรุงเทพฯ และทำงานด้าน IT ของโรงงานและงาน FA ให้กับผู้ผลิตญี่ปุ่น รวมถึงการคัดเลือก การย้ายระบบ และการออกแบบการปฏิบัติงานฝั่งหน้างานของระบบบริหารการผลิต ท่านที่ยังไม่ได้เลือกแพ็กเกจ หรือยังไม่ได้ตัดสินว่าควรขึ้นคลาวด์หรือไม่ ก็ปรึกษาได้ตั้งแต่ขั้นตอนของการแยกแยะนั้น หากท่านมีรายการฟังก์ชันปัจจุบันและโครงสร้างวงจรสื่อสารอยู่แล้ว เรายินดีเริ่มต้นไปด้วยกันจากการกรอกตารางระยะเวลาหยุดที่ยอมรับได้ ติดต่อเราได้ที่นี่