กรณีศึกษา DX ภาคการผลิต 2026 | อ่านด้วยรูปแบบของจุดเจ็บปวด ไม่ใช่ประเภทอุตสาหกรรม

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

ทำไมอ่านกรณีศึกษา DX แล้วนำมาใช้กับโรงงานตัวเองไม่ได้ – เลิกค้นหาจากประเภทอุตสาหกรรม

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

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

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

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

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

การลงทุนด้าน DX ในไทยกำลังขยายตัวอย่างรวดเร็ว – ความจริงจากข้อมูล BOI ครึ่งแรกของปี 2026

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

ตามรายงานของ Nation Thailand คำขอรับการส่งเสริมการลงทุนที่สำนักงานคณะกรรมการส่งเสริมการลงทุน (BOI) รับไว้ในครึ่งแรกของปี 2026 มีมูลค่ารวม 1.473 ล้านล้านบาท จำนวน 1,299 โครงการ เพิ่มขึ้น 37% เมื่อเทียบกับช่วงเดียวกันของปีก่อน ในจำนวนนี้เป็นการลงทุนในกลุ่มดิจิทัล 1.115 ล้านล้านบาท จำนวน 90 โครงการ โดยรายละเอียดส่วนใหญ่เป็นศูนย์ข้อมูล บริการรับฝากข้อมูล และบริการคลาวด์

ตัวเลขเฉพาะการลงทุนจากต่างประเทศก็มีรายงานไว้เช่นกัน คำขอการลงทุนโดยตรงจากต่างประเทศ (FDI) มีมูลค่า 1.368 ล้านล้านบาท จำนวน 877 โครงการ เพิ่มขึ้น 80% จากช่วงเดียวกันของปีก่อน เมื่อแยกตามประเทศ สิงคโปร์เป็นแหล่งเงินลงทุนอันดับหนึ่งด้วยมูลค่า 1.121 ล้านล้านบาท จำนวน 158 โครงการ ซึ่งส่วนใหญ่ก็อยู่ในกลุ่มดิจิทัลเช่นกัน นอกจากนี้ยังมีรายงานว่าโครงการที่ได้รับอนุมัติแล้ว 1,300 โครงการ มูลค่าการลงทุน 1.306 ล้านล้านบาท คาดว่าจะสร้างการจ้างงานได้มากกว่า 82,000 ตำแหน่ง

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

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

สำหรับแนวโน้มที่ใกล้ระดับองค์กรของเรามากกว่านั้น รายงานภาคการผลิตไทยของ Iconic Research ระบุว่าตลาดการทำดิจิทัลทรานส์ฟอร์เมชันของไทยมีแนวโน้มเติบโตด้วยอัตราการเติบโตเฉลี่ยต่อปี (CAGR) ประมาณ 8.75% ไปจนถึงปี 2031 รายงานฉบับเดียวกันยังกล่าวถึงว่าภาคการผลิตคิดเป็นสัดส่วนราว 25% ของ GDP ไทย และจ้างงานราว 10% ของกำลังแรงงาน อนึ่ง รายงานฉบับนี้ ไม่ได้ ระบุตัวเลขเชิงรูปธรรมอย่างอัตราการนำ DX ไปใช้แยกตามอุตสาหกรรมหรือไทม์ไลน์ของระบบอัตโนมัติ และระบุไว้ชัดเจนว่าตัวเลขเหล่านั้นจำเป็นต้องทำการสำรวจปฐมภูมิเพิ่มเติม จึงต้องระวังไม่พูดถึงตัวเลขอย่างอัตราการนำไปใช้ด้วยความรู้สึกที่เคยเห็นผ่านตามาจากที่ไหนสักแห่ง

สภาพแวดล้อมเป็นลมส่งท้าย ถ้าอย่างนั้นแล้วหน้างานยังไม่เปลี่ยน สาเหตุก็ไม่ได้อยู่ที่สภาพแวดล้อม แต่อยู่ที่อื่น

ทำไมเงินลงทุนเพิ่มแต่ DX หน้างานกลับไม่เดิน – กำแพงเชิงโครงสร้าง 3 ชั้น

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

ชั้นแรกคือกำแพงของการปรับให้ดีที่สุดเฉพาะส่วนที่ทับถมกันไปเรื่อย ๆ คอลัมน์ของ Thai NS Solutions ชี้ว่า เมื่อขับเคลื่อน DX ในหน้างานผลิตของไทย การผลักดันให้แต่ละแผนกนำระบบมาใช้แยกกันมักลงเอยด้วยสภาพที่ “ต่างคนต่างไม่ประสานกัน” ฝ่ายผลิตเปลี่ยนใบรายงานการผลิตประจำวันให้เป็นอิเล็กทรอนิกส์ ฝ่ายคุณภาพนำแอปบันทึกผลตรวจสอบเข้ามา ฝ่ายจัดซื้อจัดทำมาโคร Excel สำหรับบริหารใบสั่งซื้อ แต่ละอย่างล้วนเป็นความพยายามที่ถูกต้องในตัวมันเอง ทว่าเมื่อทุกอย่างเดินแยกกันเป็นเอกเทศ รหัสสินค้าเดียวกันจะถูกจัดการอยู่ใน 3 รูปแบบ แล้วงานใหม่คือการนั่งกระทบยอดด้วยมือตอนสิ้นเดือนก็จะถือกำเนิดขึ้น คอลัมน์นี้เผยแพร่เมื่อเดือนมกราคม 2022 และเป็นการชี้ประเด็นปัญหาเชิงโครงสร้าง ไม่ใช่ผลสำรวจสถิติรายกรณี แต่โครงสร้างแบบนี้ยังคงหลงเหลืออยู่อย่างกว้างขวางจนถึงทุกวันนี้

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

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

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

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

อ่านกรณีศึกษาด้วยรูปแบบของจุดเจ็บปวด – 5 รูปแบบ

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

การใช้ตารางนี้มีเคล็ดลับอยู่ 2 ข้อ

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

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

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

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

รูปแบบที่ 1 – โรงงานที่คีย์ข้อมูลซ้ำและเกิดข้อผิดพลาดจากการคัดลอกบ่อย

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

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

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

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

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

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

รูปแบบที่ 2 – โรงงานที่การเลิกใช้กระดาษหยุดค้างอยู่กลางทาง

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

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

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

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

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

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

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

รูปแบบที่ 3 – โรงงานที่ความรู้ผูกติดตัวบุคคลจนส่งต่อไม่ได้

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

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

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

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

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

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

รูปแบบที่ 4 – โรงงานที่กว่าจะรู้ว่ามีความผิดปกติก็สายไปแล้ว

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

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

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

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

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

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

รูปแบบที่ 5 – โรงงานที่ตัวเลขระหว่างสาขาและระหว่างแผนกไม่เชื่อมกัน

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

ในองค์กรที่มีหลายฐานที่ตั้ง เรื่องนี้เกิดขึ้นระหว่างฐานที่ตั้งด้วย โรงงานในไทยกับโรงงานในเวียดนามนับสต็อกด้วยวิธีต่างกัน พอสำนักงานใหญ่นำมาวางเรียงกันก็เปรียบเทียบไม่ได้

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

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

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

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

ประมาณการของเราเอง – ต้นทุนต่อปีเมื่อปล่อยให้การคีย์ข้อมูลซ้ำดำเนินต่อไป

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

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

เริ่มจากคำนวณเวลาทำงานก่อน กำหนดให้เวลาที่ใช้ไปกับการคีย์ข้อมูลซ้ำคือ 25 นาทีต่อคนต่อวัน และจำนวนวันทำงานคือ 22 วันต่อเดือน เมื่อคูณ 12 คน คูณ 25 นาที คูณ 22 วัน จะได้ 6,600 นาทีต่อเดือน แปลงเป็นชั่วโมงได้ 110 ชั่วโมงต่อเดือน เมื่อคิดค่าแรงพนักงานหน้างานที่ 350 บาทต่อชั่วโมง จะได้ 110 ชั่วโมง คูณ 350 บาท เท่ากับ 38,500 บาทต่อเดือน คิดเป็นรายปีคือ 38,500 บาท คูณ 12 เท่ากับ 462,000 บาท

ถัดมาคำนวณงานแก้ไขที่เกิดจากความผิดพลาดในการคัดลอก กำหนดให้เกิดความผิดพลาดเฉลี่ยเดือนละ 4 ครั้ง และแต่ละครั้งมีต้นทุนการรับมือเท่ากับ 2 คน คูณ 2 ชั่วโมง คูณ 250 บาทต่อชั่วโมง เท่ากับ 1,000 บาทต่อครั้ง รายเดือนคือ 4 ครั้ง คูณ 1,000 บาท เท่ากับ 4,000 บาท และรายปีคือ 4,000 บาท คูณ 12 เท่ากับ 48,000 บาท

ผลลัพธ์ออกมาที่ 510,000 บาทต่อปี ขอเสริมเรื่องวิธีอ่านตัวเลขนี้เพียง 3 ข้อ

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

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

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

สิ่งที่ต้องตรวจสอบก่อนหยิบกรณีศึกษากลับมาใช้กับองค์กรของคุณ

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

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

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

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

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

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

เริ่มจากเล็กแล้วขยับเข้าใกล้กรณีศึกษา – ทางเลือกที่เรียกว่า Small Start

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

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

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

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

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

ทำเองหรือใช้กำลังจากภายนอก – จุดแยกของวิธีเดินหน้า

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

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

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

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

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

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

ไม่ควรมองหากรณีศึกษา DX ในภาคการผลิตจากอุตสาหกรรมเดียวกันเลยหรือ

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

ถ้ายังไม่รู้ว่าองค์กรตัวเองเข้าข่ายรูปแบบใด ควรเริ่มสำรวจจากตรงไหน

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

นึกออกครบทั้ง 5 รูปแบบเลย ควรลงมือจากอันไหนก่อน

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

ยอด 510,000 บาทจากประมาณการของท่าน คือจำนวนเงินที่จะลดได้ถ้านำระบบเข้ามาใช้ใช่หรือไม่

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

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

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

สรุป

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

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

ข้อมูลอ้างอิง

• Nation Thailand — BOI says first-half investment tops B1.47tn as digital and data centre projects pour into Thailand
• Iconic Research — Thailand Manufacturing Industry – Strategic Intelligence 2026
• Thai NS Solutions — สภาพจริงของการขับเคลื่อน DX ในประเทศไทย ตอนที่ 2
• JETRO — การสนับสนุนการทำงานให้เป็นมาตรฐานสำหรับบริษัทญี่ปุ่นที่เข้ามาลงทุนในประเทศไทย
• JETRO — สถานการณ์การขาดแคลนบุคลากรและการรับมือ พร้อมจับตาแนวโน้มค่าจ้างขั้นต่ำในอนาคต