สร้างวัฒนธรรม DevOps ในโรงงาน: ปัญหาด้านคนที่ไม่มีใครพูดถึง

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

ในบริษัทซอฟต์แวร์ การสร้างวัฒนธรรม DevOps คือความท้าทายด้านคน ในโรงงาน มันคือความท้าทายด้านคนที่มีอีกชั้นหนึ่งเพิ่มเข้ามา นั่นคือคนสองกลุ่มที่มีลำดับความสำคัญต่างกัน ยอมรับความเสี่ยงต่างกัน และมีนิยามของ ดี ที่ต่างกัน แต่ต้องทำงานอยู่บนพื้นที่การผลิตเดียวกัน

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

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

ทำไมวัฒนธรรม DevOps จึงล้มเหลวในภาคการผลิต

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

แต่มันไม่เป็นเช่นนั้น

ความกลัวสี่ประการที่เจาะจงเป็นตัวขับเคลื่อนการต่อต้านบนพื้นโรงงาน:

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

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

วัฒนธรรม DevOps ต้องการอะไรจริง ๆ ในบริบทของการผลิต

รายงาน DORA 2024 State of DevOps ซึ่งเป็นการศึกษาระยะยาวด้าน DevOps ที่ใหญ่ที่สุด ครอบคลุมผู้ตอบแบบสอบถามกว่า 39,000 คน พบว่าวัฒนธรรมองค์กรและคุณภาพความเป็นผู้นำเป็นตัวทำนายประสิทธิภาพการส่งมอบงานที่แข็งแกร่งไม่แพ้แนวปฏิบัติทางเทคนิคใด ๆ วัฒนธรรมไม่ใช่ส่วนเสริมที่นุ่มนวลของการนำเทคนิคไปใช้ แต่เป็นปัจจัยขับเคลื่อนผลลัพธ์ที่เท่าเทียมกัน

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

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

การสำรวจ Smart Manufacturing Survey 2025 ของ Deloitte พบว่า 51% ของโครงการ smart manufacturing เป็นของผู้นำฝ่ายปฏิบัติการ และ 38% เป็นของผู้นำฝ่ายเทคโนโลยี ความเป็นเจ้าของที่แบ่งแยกกันนี้เป็นสาเหตุโดยตรงของความล้มเหลวในการนำไปใช้ ไปป์ไลน์ที่มีเจ้าของสองฝ่ายและไม่มีกลไกไกล่เกลี่ยจะเป็นไปตามผู้ตัดสินใจที่ช้าที่สุดเสมอ ซึ่งในภาคการผลิตคือทีม OT เสมอ เพราะความเสี่ยงด้าน uptime ตกอยู่ที่พวกเขา

จะสร้างวัฒนธรรม DevOps ในโรงงานได้อย่างไร: กรอบการทำงานเชิงปฏิบัติ

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

กรอบการทำงานที่เหมาะกับสภาพแวดล้อมการผลิตมากที่สุดคือโมเดลการเปลี่ยนแปลง 8 ขั้นตอนของ Kotter โดยมีสองขั้นตอนที่มักถูกข้ามไปเสมอ คือการสร้างความเร่งด่วนและการฝังรากการเปลี่ยนแปลงไว้ในวัฒนธรรม

ขั้นตอนที่ 1 - สร้างความเร่งด่วนที่มองเห็นได้ก่อนแตะต้องเทคโนโลยี

การสำรวจ Bitkom 2025 ของบริษัทเยอรมันพบว่า 82% เชื่อว่าเยอรมนีกำลังอยู่ในวิกฤตดิจิทัล และ 73% กล่าวว่าเยอรมนีสูญเสียส่วนแบ่งตลาดไปแล้วเนื่องจากการนำไปใช้ที่ล่าช้า ข้อมูลนั้นมีอยู่ในระดับประเทศ ผู้อำนวยการฝ่ายปฏิบัติการต้องการข้อมูลแบบเดียวกันในระดับบริษัท ที่เจาะจง วัดผลได้ และเห็นผลทันที หากไม่มีต้นทุนของการไม่ลงมือทำที่มองเห็นได้ ทางเลือกเริ่มต้นบนพื้นโรงงานจะเป็นความมั่นคงเสมอ

ขั้นตอนที่ 2 - สร้างพันธมิตรข้ามสายงานโดยมี OT เป็นศูนย์กลาง

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

ขั้นตอนที่ 3 - เริ่มจากสายการผลิตเดียวและทำให้ทีม OT เป็นผู้เชี่ยวชาญ

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

ขั้นตอนที่ 4 - กำหนดตัวชี้วัดร่วมก่อนเครื่องมือร่วม

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

ขั้นตอนที่ 5 - ลงทุนในการยกระดับทักษะในฐานะโครงสร้างพื้นฐาน ไม่ใช่สวัสดิการ

ความต้องการทักษะด้านการจำลองสถานการณ์และซอฟต์แวร์ในภาคการผลิตเพิ่มขึ้น 75% ระหว่างปี 2021 ถึง 2024 ตาม Workforce Study 2024 ของ Deloitte และ Manufacturing Institute วิศวกร OT ที่ถูกขอให้ทำงานในไปป์ไลน์ DevOps ไม่ได้ถูกจ้างมาด้วยทักษะเหล่านั้น การยกระดับทักษะไม่ใช่ทางเลือก แต่เป็นปัจจัยที่ทำให้ความเป็นเจ้าของร่วมเป็นไปได้จริงในทางปฏิบัติ ให้ปฏิบัติต่อมันเหมือนการลงทุนด้านทุน ไม่ใช่รายการงบประมาณฝึกอบรม

ขั้นตอนที่ 6 - ฝังรากการเปลี่ยนแปลงด้วยภาษาปฏิบัติการ ไม่ใช่ภาษา IT

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

ผลลัพธ์ที่ดีมีหน้าตาเป็นอย่างไร

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

ช่องว่างระหว่างความผูกพัน 15% กับอัตรากำไรที่ดีกว่า 50% ไม่ใช่ช่องว่างด้านเทคโนโลยี แต่เป็นช่องว่างด้านความเป็นผู้นำและวัฒนธรรม บริษัทที่ปิดช่องว่างนี้ไม่ได้ทำโดยการนำระบบมาใช้เพิ่มขึ้น แต่ทำโดยการเปลี่ยนความหมายของระบบเหล่านั้นสำหรับคนที่ใช้งานมัน

FAQ

จะสร้างวัฒนธรรม DevOps ในบริษัทผลิตได้อย่างไร

การสร้างวัฒนธรรม DevOps ในภาคการผลิตต้องมองช่องว่าง OT/IT เป็นปัญหาด้านองค์กร ไม่ใช่ปัญหาด้านเทคนิค ขั้นตอนเชิงปฏิบัติได้แก่ สร้างความเร่งด่วนในระดับบริษัท สร้างพันธมิตรข้ามสายงานโดยมีผู้นำ OT เป็นศูนย์กลาง เริ่มด้วยโครงการนำร่องสายการผลิตเดียวที่ทีม OT ร่วมออกแบบกระบวนการ กำหนดตัวชี้วัด DORA ร่วมก่อนเครื่องมือร่วม และลงทุนในการยกระดับทักษะในฐานะโครงสร้างพื้นฐาน การยอมรับด้านวัฒนธรรมใช้เวลา 3 ถึง 5 ปีในระดับเต็มรูปแบบ วางแผนให้สอดคล้องกับเรื่องนี้

ทำไมการทรานส์ฟอร์เมชัน DevOps จึงล้มเหลวในภาคการผลิต

70% ของโครงการทรานส์ฟอร์มดิจิทัลไม่บรรลุเป้าหมาย ตามงานวิจัยของ McKinsey โดยวัฒนธรรมองค์กรถูกระบุอย่างต่อเนื่องว่าเป็นอุปสรรคหลัก ในภาคการผลิตโดยเฉพาะ รูปแบบความล้มเหลวมีลักษณะเชิงโครงสร้าง ทีม OT และ IT มีการยอมรับความเสี่ยงต่างกัน ตัวชี้วัดผลงานต่างกัน และนิยามความสำเร็จต่างกัน มีเพียง 26% ของธุรกิจที่มองว่าการบริหารการเปลี่ยนแปลงเป็นส่วนสำคัญของการเปลี่ยนผ่านสู่อุตสาหกรรม 4.0 หมายความว่าส่วนใหญ่นำเทคโนโลยีมาใช้โดยไม่ได้จัดการเงื่อนไขด้านคนที่กำหนดว่ามันจะได้ผลหรือไม่

วัฒนธรรม DevOps ในซอฟต์แวร์ต่างจากในภาคการผลิตอย่างไร

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

การสร้างวัฒนธรรม DevOps ในโรงงานต้องใช้เวลานานเท่าใด

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

ช่องว่าง OT/IT คืออะไร และเหตุใดจึงสำคัญต่อ DevOps ในภาคการผลิต

ช่องว่าง OT/IT คือช่องว่างด้านองค์กรและวัฒนธรรมระหว่างทีมเทคโนโลยีปฏิบัติการ ซึ่งดูแลอุปกรณ์โรงงานรวมถึง PLC, SCADA และเซนเซอร์ กับทีมเทคโนโลยีสารสนเทศที่สร้างและจัดการระบบซอฟต์แวร์ ทีม OT ให้ความสำคัญกับ uptime และความมั่นคง ทีม IT ให้ความสำคัญกับความเร็วและการเปลี่ยนแปลง DevOps ต้องการให้ทั้งสองทีมใช้ไปป์ไลน์ร่วมกันและรับผิดชอบร่วมกัน การเชื่อมช่องว่างนี้คือความท้าทายหลักของ DevOps ในภาคการผลิต และมันคือปัญหาด้านวัฒนธรรม ไม่ใช่ปัญหาด้านเทคโนโลยี