“ตอนนี้เครื่อง PC ในโรงงานที่ประเทศไทยของคุณ มีซอฟต์แวร์อะไรติดตั้งอยู่บ้าง” คำถามนี้มีผู้ผลิตสัญชาติญี่ปุ่นไม่กี่รายที่ตอบได้ทันที ทะเบียนฮาร์ดแวร์อาจจัดทำไว้เรียบร้อย แต่จำนวนซอฟต์แวร์ที่ถูกติดตั้งลงไปในเครื่องเหล่านั้น ตรงกับจำนวนลิขสิทธิ์ที่บริษัทถือครองอยู่หรือไม่ กลับไม่มีใครตามได้ การบริหารสินทรัพย์ซอฟต์แวร์ หรือ Software Asset Management (SAM) คือความพยายามที่จะเติมช่องว่างตรงนี้ บทความนี้จะเรียบเรียงจากข้อมูลที่เปิดเผยต่อสาธารณะว่า ผู้ผลิตสัญชาติญี่ปุ่นที่มีฐานการผลิตในไทยและอาเซียนจะป้องกันความสูญเสีย 3 ด้าน คือการถูกตรวจสอบจากผู้ผลิตซอฟต์แวร์ การละเมิดข้อกำหนด และค่าลิขสิทธิ์ที่จ่ายเกินจำเป็น ได้อย่างไร
การบริหารสินทรัพย์ซอฟต์แวร์คืออะไร – ต่างจากการจัดการทรัพย์สิน PC ตรงไหน
เริ่มจากการทำความเข้าใจคำศัพท์ก่อน ถ้าปล่อยให้จุดนี้คลุมเครือแล้วคุยกันในองค์กร จะนำไปสู่ความสบายใจที่ผิดพลาดว่า “บริษัทเรามีเครื่องมือจัดการทรัพย์สินอยู่แล้ว ไม่มีปัญหาหรอก”
นิยามของการบริหารสินทรัพย์ซอฟต์แวร์ (SAM)
การบริหารสินทรัพย์ซอฟต์แวร์ หมายถึงกิจกรรมการบริหารที่นำข้อมูล 3 ชุดของซอฟต์แวร์ที่องค์กรถือครองและใช้งานอยู่ ได้แก่ จำนวนและเงื่อนไขของลิขสิทธิ์ที่ซื้อมา จำนวนชุดที่ติดตั้งอยู่จริง และ สภาพการใช้งานจริง มากระทบยอดกันอย่างต่อเนื่อง เพื่อขจัดทั้งส่วนที่ขาด ส่วนที่เกิน และการละเมิดสัญญา ภาษาอังกฤษเรียกว่า Software Asset Management ย่อว่า SAM
จุดสำคัญอยู่ที่คำว่า “อย่างต่อเนื่อง” เพราะซอฟต์แวร์เปลี่ยนสถานะไปเรื่อย ๆ นับตั้งแต่วินาทีที่ซื้อมา คนเข้าคนออกทำให้ผู้ใช้เปลี่ยน เปลี่ยนเครื่อง PC ก็เกิดการติดตั้งใหม่ แผนกไหนเริ่มงานใหม่ก็จะมีคนดาวน์โหลดรุ่นทดลองใช้มาเองโดยไม่บอกใคร การตรวจนับปีละครั้งด้วยไฟล์ตารางคำนวณ จึงหมายความว่าพอผ่านไปแค่สัปดาห์เดียวหลังตรวจนับ ตัวเลขก็เริ่มคลาดเคลื่อนจากความจริงแล้ว
พื้นที่ที่ทะเบียนฮาร์ดแวร์เข้าไปไม่ถึง
สิ่งที่ผู้ผลิตจำนวนมากมีอยู่แล้วคือ ทะเบียนทรัพย์สินที่จับต้องได้ อย่าง PC เซิร์ฟเวอร์ และอุปกรณ์เครือข่าย เป็นกลไกที่บริหารเลขทรัพย์สิน วันที่ซื้อ สถานที่ติดตั้ง ผู้ใช้งาน และวันสิ้นสุดสัญญาเช่า โดยทั่วไปมักถูกจัดทำขึ้นตามข้อกำหนดของการบริหารสินทรัพย์ถาวรหรือการควบคุมภายใน
แต่ทะเบียนนี้ไม่ได้มองเข้าไปถึงสิ่งที่อยู่ในกล่อง เบื้องหลังบรรทัดเดียวที่เขียนว่าโน้ตบุ๊ก 1 เครื่อง มีซอฟต์แวร์วางซ้อนอยู่นับสิบตัว ทั้งระบบปฏิบัติการ ชุดโปรแกรมสำนักงาน โปรแกรมดูไฟล์ CAD โปรแกรมแก้ไข PDF ไคลเอนต์ของระบบบริหารการผลิต เครื่องมือเชื่อมต่อระยะไกล และโปรแกรมบีบอัดไฟล์ และซอฟต์แวร์นับสิบตัวนี้ ต่างมีเงื่อนไขสัญญาคนละแบบ และมีเพดานจำนวนลิขสิทธิ์คนละตัว
แนวคิดเรื่องสัญญาและทะเบียนที่ควรจับให้มั่นในฐานะพื้นฐานของการจัดการทรัพย์สินฮาร์ดแวร์ เราเรียบเรียงไว้แล้วใน การบริหารสินทรัพย์ IT ของโรงงาน 2026 ส่วนบทความนี้จะขยับไปอีกขั้น คือเรื่องการบริหารสิ่งที่อยู่ภายในเครื่อง PC ที่ปรากฏอยู่ในทะเบียนแล้ว
ถ้าเปรียบเทียบทั้งสองเรื่อง จะได้ภาพดังนี้
| มุมมอง | การจัดการทรัพย์สินฮาร์ดแวร์ | การบริหารสินทรัพย์ซอฟต์แวร์ (SAM) |
|---|---|---|
| สิ่งที่บริหาร | ตัวเครื่องจริง เช่น PC เซิร์ฟเวอร์ อุปกรณ์ต่อพ่วง | สัญญาลิขสิทธิ์และสภาพการติดตั้งจริง |
| วิธีนับ | นับของจริงก็ได้ตัวเลขที่แน่นอน | วิธีนับเปลี่ยนไปตามเงื่อนไขสัญญา |
| การตัดสินว่าขาดหรือเกิน | ดูจากมีหรือไม่มีตัวเครื่อง | ต้องกระทบยอดจำนวนที่ถือครองกับจำนวนที่ใช้จริง |
| รูปแบบของความเสี่ยง | สูญหาย เสื่อมสภาพ เลยกำหนดสัญญาเช่า | ถูกเรียกเก็บย้อนหลังตอนถูกตรวจสอบ ละเมิดข้อกำหนด |
| ความเร็วของการเปลี่ยนแปลง | เปลี่ยนรอบทุกหลายปี | สถานะการติดตั้งเปลี่ยนเป็นรายวัน |
ความต่างเชิงแก่นอยู่ตรงที่ ของจริงนั้น “นับแล้วก็รู้” ในขณะที่ซอฟต์แวร์นั้น วิธีนับเองขึ้นอยู่กับสัญญา ต่อให้เป็นคำว่า “ติดตั้งไปแล้ว 10 เครื่อง” เหมือนกัน ถ้าสัญญาเป็นแบบผู้ใช้ระบุชื่อกับแบบใช้งานพร้อมกัน จำนวนลิขสิทธิ์ที่ต้องมีอาจเป็น 10 หรือเป็น 3 ก็ได้
ทำไมปี 2026 การบริหารสินทรัพย์ซอฟต์แวร์จึงถูกตั้งคำถาม – สภาพจริงของการตรวจสอบ
สมมติฐานที่ว่า “บริษัทเราไม่มีใครมาตรวจสอบหรอก” ในเชิงสถิติแล้วไม่เป็นความจริงอีกต่อไป
องค์กรที่ถูกตรวจสอบมีถึง 48% (Flexera 2026)
ตามรายงาน 2026 State of ITAM Report ที่ Flexera เผยแพร่เมื่อวันที่ 24 มิถุนายน 2026 ซึ่งสำรวจผู้เชี่ยวชาญด้าน IT จำนวน 512 คน พบว่า องค์กรที่ถูกตรวจสอบลิขสิทธิ์ซอฟต์แวร์ในรอบ 1 ปีที่ผ่านมามีถึง 48% หรือราว 1 ใน 2 บริษัท
ที่หนักกว่านั้นคือต้นทุน รายงานฉบับเดียวกันระบุว่า องค์กรที่ใช้จ่ายไปกับการตรวจสอบลิขสิทธิ์ซอฟต์แวร์เกิน 1 ล้านดอลลาร์สหรัฐในรอบ 3 ปีที่ผ่านมามีถึง 44% ตัวเลขนี้ทรงตัวมาตลอดหลายฉบับของรายงาน แสดงว่าไม่ใช่ปรากฏการณ์ชั่วคราว แต่กลายเป็นต้นทุนเชิงโครงสร้างไปแล้ว
ยอดเกิน 1 ล้านดอลลาร์สหรัฐนี้ไม่ได้มีแค่ค่าลิขสิทธิ์ที่ถูกเรียกเก็บย้อนหลัง แต่รวมถึงชั่วโมงงานภายในที่ทุ่มไปกับการรับมือการตรวจสอบ ค่าจ้างที่ปรึกษาภายนอก และค่าทนายความด้วย พูดอีกอย่างคือ ต่อให้ไม่มีการละเมิดสัญญาเลยแม้แต่ข้อเดียว ตัวการรับมือการตรวจสอบเองก็เป็นภาระหนักสำหรับองค์กรอยู่ดี
ความถี่ในการตรวจสอบต่างกันไปตามผู้ผลิตซอฟต์แวร์
รายงานฉบับเดียวกันยังรวบรวมด้วยว่า ในรอบ 3 ปีที่ผ่านมา องค์กรถูกตรวจสอบจากผู้ผลิตรายใดบ้าง
| ผู้ผลิตซอฟต์แวร์ | อัตราการตรวจสอบในรอบ 3 ปี | แนวโน้ม |
|---|---|---|
| Microsoft | 64% | ครองอันดับ 1 ต่อเนื่องมาหลายปี |
| Oracle | 38% | เพิ่มขึ้นมากจากเดิมที่ 24% |
| Adobe | 32% | เพิ่มขึ้นจากเดิมที่ 24% |
ที่ Microsoft โดดออกมานั้น ส่วนหนึ่งเป็นเพราะมีองค์กรที่ใช้งานมากที่สุดอยู่แล้ว แต่ระดับการเพิ่มขึ้นของ Oracle และ Adobe ต่างหากที่น่าจับตา Oracle ขยับจาก 24% เป็น 38% ส่วน Adobe ขยับจาก 24% เป็น 32% ทั้งคู่เพิ่มความถี่ของการตรวจสอบขึ้นชัดเจน สำหรับผู้ผลิตที่วางฐานข้อมูลและผลิตภัณฑ์ตระกูล CAD ไว้เป็นแกนกลางของงาน ความเคลื่อนไหวของสองรายนี้จึงไม่ใช่เรื่องของคนอื่น
ปัญหารากฐานคือช่องว่างของการมองเห็น
ในรายงานฉบับเดียวกัน องค์กรที่ตอบว่ามองเห็นทรัพย์สิน IT ของตนได้อย่างครบถ้วนมีเพียง 36% และตัวเลขนี้ยังมีแนวโน้มลดลงจากปีก่อนหน้าอีกด้วย ภาพที่เกิดขึ้นคือ การใช้บริการคลาวด์และ SaaS ขยายตัว สิ่งที่ต้องบริหารจึงเพิ่มขึ้นเร็วกว่าที่ระบบการบริหารจะตามทัน
พอมาถึงซอฟต์แวร์ที่เกี่ยวกับ AI องค์กรที่จับสภาพการใช้งานจริงได้อย่างแม่นยำมีเพียง 31% เท่านั้น ในขณะที่การใช้เครื่องมือ Generative AI แพร่ไปอย่างรวดเร็วในระดับแผนก ฝ่าย IT กลับตามจับสัญญาและสถานะการใช้งานไม่ทัน นี่คือ Shadow IT รูปแบบใหม่ที่กำลังก่อตัวขึ้น
และการใช้เวลาของทีม ITAM เองก็บิดเบี้ยวไปด้วย รายงานฉบับเดียวกันระบุว่า เวลาทำงานของทีม ITAM ถูกใช้ไปกับการปรับปรุงประสิทธิภาพซอฟต์แวร์ 32% และใช้ไปกับการรับมือการตรวจสอบอีก 22% รวมกันแล้วเกินครึ่งหนึ่งหายไปกับงานที่โดยหลักการแล้วควรบีบให้เล็กลงได้ด้วยการวางกลไก
โครงสร้างที่ทำให้ทะเบียนกระจัดกระจายในฐานการผลิตไทยและอาเซียน

จากตรงนี้ไปคือเรื่องเฉพาะของบริษัทญี่ปุ่นที่มีฐานการผลิตในประเทศไทย ปัญหาปรากฏออกมาคนละแบบกับบริษัทที่ทำงานจบอยู่ในญี่ปุ่นประเทศเดียว
การปรับให้เหมาะสมเฉพาะจุดของแต่ละฐานผลิตสะสมทับกัน
ในผู้ผลิตสัญชาติญี่ปุ่นที่ขยายหลายฐานผลิตในไทยและอาเซียน ความจริงคือทั้งการจัดซื้อ PC และการนำซอฟต์แวร์เข้ามาใช้ ล้วน ถูกปรับให้เหมาะสมเฉพาะของแต่ละฐานผลิต โรงงานในไทยซื้อ PC จากตัวแทนจำหน่ายท้องถิ่น ฐานผลิตในเวียดนามจัดซื้อผ่านอีกช่องทาง ส่วนอินโดนีเซียยังใช้เครื่องที่สำนักงานใหญ่ส่งมาให้เมื่อหลายปีก่อน สภาพแบบนี้ไม่ใช่เรื่องแปลก
ซอฟต์แวร์ก็เช่นกัน มีทั้งกรณีที่ฐานผลิตในไทยซื้อผลิตภัณฑ์แบบแยกชิ้นโดยไม่รู้ว่าสำนักงานใหญ่ที่ญี่ปุ่นทำสัญญาแบบเหมารวมกับผู้ผลิตรายนั้นอยู่แล้ว และกรณีตรงกันข้ามคือเข้าใจไปเองว่าสัญญาเหมารวมของสำนักงานใหญ่ครอบคลุมอยู่ แต่จริง ๆ แล้วใช้งานอยู่โดยที่ยังไม่ได้รับการจัดสรรลิขสิทธิ์เลย
สิ่งที่เป็นปัญหาในสภาพแบบนี้คือ ไม่มีใครรวมยอดจำนวนลิขสิทธิ์ที่ถือครองและสภาพการใช้งานจริงในระดับทั้งบริษัทได้ ทะเบียนน่ะมีอยู่ แต่แยกกันอยู่ตามแต่ละฐานผลิต ในรูปแบบคนละอย่าง และอยู่ในมือของผู้รับผิดชอบคนละคน ยิ่งกว่านั้นผู้รับผิดชอบคนนั้นมักควบตำแหน่งงานธุรการหรือบัญชีไปด้วย และจะปรับปรุงข้อมูลก็เฉพาะตอนตรวจนับปีละครั้งเท่านั้น กรณีแบบนี้พบได้บ่อย
ช่องว่างสองชั้น – ทั้งฝั่งไทยและสำนักงานใหญ่ต่างมองไม่เห็น
ที่ฝังลึกกว่านั้นคือปัญหาเรื่องคน บริษัทลูกในไทยที่มีบุคลากรเฉพาะทางซึ่งเข้าใจถึงขั้นรับมือการตรวจสอบลิขสิทธิ์ซอฟต์แวร์ได้ประจำอยู่นั้นหายาก ผู้ดูแล IT ในไทยต้องวิ่งตามงานแก้ปัญหาประจำวัน งานเครือข่าย งานเชื่อมต่อกับเครื่องจักรการผลิต และงานสนับสนุนผู้ใช้ จึงไม่มีเวลาเหลือให้อ่านข้อสัญญาลิขสิทธิ์อย่างละเอียด
ในทางกลับกัน ฝ่ายระบบสารสนเทศของสำนักงานใหญ่ที่ญี่ปุ่นก็ไม่ได้ดูว่าเครื่อง PC ในไทยมีอะไรอยู่ข้างใน ผลจากการที่แนวปฏิบัติแบบ “เรื่องของท้องถิ่นให้ท้องถิ่นจัดการ” ดำเนินมายาวนาน ทำให้โครงสร้างกลายเป็นว่าสภาพจริงของฝั่งไทยไม่เคยถูกส่งขึ้นไปถึงสำนักงานใหญ่
ผลลัพธ์คือเกิด “ช่องว่างสองชั้น” ที่ทั้งฝั่งไทยและสำนักงานใหญ่ต่างมองไม่เห็นสภาพจริง และมักจบลงด้วยการที่กว่าจะรู้ว่าไม่มีใครเข้าใจภาพรวมเลย ก็ตอนที่หนังสือแจ้งการตรวจสอบมาถึงแล้ว ช่องว่างนี้ไม่ได้เกิดจากความเกียจคร้านของผู้รับผิดชอบ แต่เป็นปัญหาเชิงโครงสร้างที่มีรูโหว่อยู่ในการออกแบบการแบ่งบทบาทหน้าที่
มุมของการควบคุมภายในก็ถูกชี้ประเด็นได้ง่าย
อีกเรื่องที่มักถูกมองข้ามคือความสัมพันธ์กับการควบคุมภายใน เวลาที่สำนักงานสอบบัญชีตรวจสอบสถานะการจัดทำ J-SOX หรือ ITGC (การควบคุมทั่วไปด้าน IT) ของบริษัทลูกในไทย การบริหารลิขสิทธิ์ซอฟต์แวร์อย่างเหมาะสมเป็นพื้นที่ที่ถูกยกขึ้นมาเป็นประเด็นได้ง่าย
เหตุผลนั้นตรงไปตรงมา เพราะแสดงหลักฐานได้ยาก การจะแสดงว่า “ไม่ได้ใช้ซอฟต์แวร์ที่ไม่ถูกต้อง” ต้องมีเอกสารที่นำรายการสถานะการติดตั้งมากระทบยอดกับหลักฐานการซื้อที่สอดคล้องกัน ในสภาพที่ทะเบียนกระจัดกระจายตามแต่ละฐานผลิต การเตรียมเอกสารชุดนี้ในเวลาสั้น ๆ ย่อมทำไม่ได้
ถูกถามระหว่างการตรวจสอบบัญชีเรื่อง “ระบบการบริหารลิขสิทธิ์ซอฟต์แวร์” แล้วตอบไม่ได้ จนถูกบันทึกเป็นประเด็นที่ต้องปรับปรุง เส้นทางนี้เกิดขึ้นคนละทางกับการตรวจสอบจากผู้ผลิตซอฟต์แวร์ แต่ก็เกิดขึ้นด้วยความถี่ที่ไม่น้อยเลย
ทำไมระบบลิขสิทธิ์ของภาคการผลิตจึงยาก

สภาพแวดล้อมซอฟต์แวร์ของภาคการผลิตมีโครงสร้างซับซ้อนกว่าสำนักงานทั่วไป และความซับซ้อนนี้เองคือเหตุผลว่าทำไมเครื่องมือจัดการทรัพย์สิน PC แบบทั่วไปเพียงอย่างเดียวจึงตามไม่ไหว
วิธีนับต่างกันไปในแต่ละผลิตภัณฑ์
ERP, CAD, CAM, ระบบบริหารการผลิต, PLM, ซอฟต์แวร์วิเคราะห์ของเครื่องมือวัด ซอฟต์แวร์เชิงธุรกิจที่ใช้ในหน้างานภาคการผลิตล้วนมีระบบลิขสิทธิ์เป็นของตัวเอง ขอสรุปแบบหลัก ๆ ไว้ดังนี้
| รูปแบบลิขสิทธิ์ | แนวคิดในการนับ | ข้อควรระวังในการบริหาร |
|---|---|---|
| ลิขสิทธิ์แบบอุปกรณ์ (Device) | นับตามจำนวนเครื่องที่ติดตั้ง | การลืมถอนสิทธิ์ตอนเปลี่ยนเครื่อง PC สะสมขึ้นเรื่อย ๆ |
| ลิขสิทธิ์แบบผู้ใช้ระบุชื่อ (Named User) | นับตามจำนวนคนที่ได้รับอนุญาตให้ใช้ | บัญชีของผู้ที่ลาออกแล้วถูกทิ้งไว้จนกลายเป็นสาเหตุของการใช้เกิน |
| ลิขสิทธิ์แบบใช้งานพร้อมกัน (Floating) | นับตามจำนวนสูงสุดที่ใช้พร้อมกันได้ | ถ้าไม่บันทึกจำนวนผู้ใช้พร้อมกันช่วงพีกไว้ ก็พิสูจน์ย้อนหลังไม่ได้ |
| ลิขสิทธิ์แบบเซิร์ฟเวอร์ | นับตามจำนวน CPU หรือคอร์ของเซิร์ฟเวอร์ | เงื่อนไขเปลี่ยนไปเมื่อใช้ระบบเสมือนหรือคลัสเตอร์ |
| ลิขสิทธิ์การเข้าถึงฝั่งไคลเอนต์ (CAL) | นับตามจำนวนเครื่องหรือผู้ใช้ที่เชื่อมต่อเข้าเซิร์ฟเวอร์ | มองข้ามได้ง่ายว่าต้องมีแยกต่างหากจากตัวเซิร์ฟเวอร์ |
ถ้าดูตารางนี้แล้วรู้สึกว่า “ตอบไม่ได้ทันทีว่าผลิตภัณฑ์ตัวไหนของบริษัทเราใช้รูปแบบใด” นั่นแหละคือสภาพที่ยังไม่ได้จัดทำ SAM
จุดที่เกิดอุบัติเหตุได้ง่ายเป็นพิเศษคือ การผสมกันระหว่างลิขสิทธิ์แบบเซิร์ฟเวอร์กับ CAL คือเข้าใจไปเองว่าซื้อผลิตภัณฑ์เซิร์ฟเวอร์แล้วก็ใช้ได้เลย จึงไม่ได้ซื้อลิขสิทธิ์ฝั่งไคลเอนต์ที่เชื่อมต่อเข้ามา โครงสร้างแบบนี้เป็นหนึ่งในรายการที่ถูกตรวจสอบง่าย และเนื่องจากส่วนที่ขาดจะกว้างขึ้นทุกครั้งที่มีเครื่องเชื่อมต่อเพิ่ม ยอดที่ถูกเรียกเก็บย้อนหลังตอนถูกพบจึงมักสูง
สภาพแวดล้อมเสมือนก็ต้องระวังเช่นกัน เมื่อสร้างเครื่องเสมือนหลายตัวบนเซิร์ฟเวอร์กายภาพ 1 เครื่อง บางผลิตภัณฑ์กำหนดให้ต้องนับลิขสิทธิ์โดยยึดจำนวนคอร์กายภาพเป็นเกณฑ์ ถ้าคำนวณจากจำนวนเครื่องเสมือนอย่างเดียว จะขาดไปมาก ยิ่งบริษัทที่รวมเซิร์ฟเวอร์ระบบบริหารการผลิตของโรงงานเข้าไปไว้บนแพลตฟอร์มเสมือน ก็ยิ่งตกหลุมนี้ได้ง่าย
SAM ในฐานะมาตรการรับมือ Shadow IT
อีกประเด็นหนึ่งคือ Shadow IT ในที่นี้หมายถึงสภาพที่ซอฟต์แวร์หรือบริการซึ่งฝ่ายระบบสารสนเทศไม่รับรู้ ถูกนำเข้ามาใช้งานตามดุลยพินิจของหน้างาน
กรณีที่พบเป็นแบบฉบับในหน้างานภาคการผลิตมีดังนี้
- ผู้รับผิดชอบงานออกแบบดาวน์โหลดโปรแกรมดูไฟล์รุ่นทดลองใช้มาเองเพื่อเปิดข้อมูล CAD ที่ได้รับจากคู่ค้า แล้วใช้ต่อไปแม้หมดอายุแล้ว
- เพื่อปรับปรุงหน้างาน ผู้รับผิดชอบทำสัญญาบริการตารางคำนวณบนคลาวด์ด้วยบัญชีส่วนตัว แล้วป้อนข้อมูลการผลิตลงไป
- เครื่อง PC ของอุปกรณ์ที่ผู้รับเหมาบำรุงรักษานำเข้ามา มีโปรแกรมอรรถประโยชน์ที่ไม่ทราบวัตถุประสงค์ติดตั้งอยู่หลายตัว
- ทำสัญญาเครื่องมือ Generative AI ด้วยบัตรเครดิตงบประมาณของแผนก โดยที่ฝ่าย IT ไม่รู้ว่ามีอยู่
พูดถึงมาตรการรับมือ Shadow IT คนมักคุยกันในบริบทของข้อมูลรั่วไหล แต่ในมุมของลิขสิทธิ์ก็ร้ายแรงพอกัน กรณีที่เครื่องมือซึ่งใช้อยู่โดยเข้าใจว่าเป็นรุ่นฟรี แท้จริงแล้วเป็นผลิตภัณฑ์ที่ต้องมีลิขสิทธิ์แบบเสียเงินสำหรับการใช้ในเชิงพาณิชย์ เกิดขึ้นบ่อยครั้ง การตรวจสอบจากผู้ผลิตซอฟต์แวร์ไม่ได้ถามว่าใครเป็นคนติดตั้งด้วยวัตถุประสงค์อะไร สิ่งที่ถูกถามคือข้อเท็จจริงที่ว่ามันติดตั้งอยู่บนเครื่อง PC ขององค์กรเท่านั้น
และอย่างที่ข้อมูลของ Flexera ข้างต้นแสดงให้เห็น องค์กรที่จับสภาพการใช้งานซอฟต์แวร์ที่เกี่ยวกับ AI ได้มีเพียง 31% การใช้ Generative AI ในหน้างานยิ่งขยายตัวขึ้นอีกเมื่อเข้าสู่ปี 2026 จึงกลายเป็นสมรภูมิใหม่ของ Shadow IT
ค่าลิขสิทธิ์ที่สูญเปล่า ความสูญเสียในทิศทางตรงกันข้าม
ที่ผ่านมาเราพูดถึงความเสี่ยงของการ “ขาด” แต่ในทางปฏิบัติ ทิศทางตรงกันข้ามก็เกิดขึ้นพอ ๆ กัน นั่นคือสภาพที่ จ่ายเงินต่อไปให้กับลิขสิทธิ์ที่ไม่มีใครใช้
ต่ออายุบัญชีของผู้ที่ลาออกไปแล้วโดยไม่ยกเลิก คงรุ่นที่มีฟังก์ชันสูงไว้แม้โครงการจะจบไปแล้ว สัญญาซ้ำซ้อนที่ไม่จำเป็นหลังการควบรวมแผนกยังเหลือค้างอยู่ ความสูญเปล่าเหล่านี้มีลักษณะที่ถูกปล่อยทิ้งไว้ได้ง่าย เพราะไม่มีใครจากภายนอกมาชี้ให้เห็นเหมือนอย่างการตรวจสอบ
คุณค่าของการจัดทำ SAM ไม่ได้อยู่แค่การเลี่ยงความเสี่ยง เมื่อจับสภาพจริงได้แล้ว ก็จะได้เครื่องมือต่อรองในจังหวะต่ออายุสัญญา ทั้งการ “ตัดส่วนที่ไม่ได้ใช้ออก” และการ “ลดระดับรุ่นลง” ประเด็นนี้เชื่อมโยงกับการพูดถึง ROI ที่จะกล่าวถึงต่อไป
ถ้าการตรวจสอบลิขสิทธิ์ซอฟต์แวร์มาถึงจะเกิดอะไรขึ้น

จากนี้ไปจะดูอย่างเป็นรูปธรรมว่า เมื่อหนังสือแจ้งการตรวจสอบมาถึงจริง ๆ จะเกิดอะไรขึ้นบ้าง
การตรวจสอบดำเนินการบนพื้นฐานของสัญญา
ก่อนอื่นต้องเข้าใจว่า การตรวจสอบลิขสิทธิ์ซอฟต์แวร์คือ การใช้สิทธิ์ตามสัญญาที่ทำไว้กับผู้ผลิตซอฟต์แวร์ ในกรณีของ Microsoft เอกสารคำถามที่พบบ่อยเรื่องการตรวจสอบการปฏิบัติตามข้อกำหนดฉบับทางการ อธิบายไว้ว่าการตรวจสอบดำเนินการโดยผู้ตรวจสอบอิสระตามสัญญา นั่นคือไม่ใช่การจู่โจมแบบไม่มีปี่มีขลุ่ย แต่ตั้งอยู่บนเงื่อนไขว่ามีข้อสัญญาว่าด้วยการตรวจสอบอยู่ในเอกสารสัญญาแล้ว
บริษัทจำนวนมากยินยอมกับข้อสัญญานี้ไปตั้งแต่ตอนทำสัญญาลิขสิทธิ์แบบปริมาณหรือสัญญาสำหรับองค์กร ปฏิกิริยาที่ว่า “ไม่รู้เลยว่าในสัญญามีข้อแบบนั้นอยู่ด้วย” เกิดขึ้นบ่อย แต่ตัวข้อสัญญาเองเป็นเรื่องปกติทั่วไป
สิ่งที่ถูกขอให้ส่งคือตัวเลข 3 ตัว
ตามที่รายงาน “การตั้งรับช่วงแรกของการตรวจสอบลิขสิทธิ์ซอฟต์แวร์” ของ ITR เรียบเรียงไว้ ในทางปฏิบัติของการรับมือการตรวจสอบ องค์กรจะถูกขอให้รวบรวมและส่งข้อมูล 3 อย่างต่อไปนี้แยกตามผลิตภัณฑ์ซอฟต์แวร์แต่ละตัว
| รายการที่ต้องส่ง | เนื้อหา | จุดที่เตรียมยาก |
|---|---|---|
| จำนวนเครื่องที่ใช้งาน | จำนวนเครื่องที่มีซอฟต์แวร์เป้าหมายติดตั้งอยู่ | การทำให้ครอบคลุมข้ามฐานผลิตและข้ามแผนก |
| จำนวนชุดซอฟต์แวร์ที่ใช้ | จำนวนชุดที่ติดตั้งอยู่จริง | การตัดข้อมูลซ้ำของส่วนที่ลบแล้วหรือติดตั้งใหม่ |
| จำนวนลิขสิทธิ์ที่ถือครอง | จำนวนลิขสิทธิ์ถูกต้องที่ถือครองจากการซื้อ | การตามหาหลักฐานการซื้อในอดีตและการตีความเงื่อนไขสัญญา |
เมื่อมองผ่าน ๆ ก็เป็นแค่ตัวเลข 3 ตัวที่ดูเรียบง่าย แต่การรวบรวมตัวเลขเหล่านี้แยกตามผลิตภัณฑ์ โดยรับประกันทั้งความถูกต้องและความครอบคลุม เป็นงานที่กินเวลามหาศาล จุดที่เป็นปัญหาเป็นพิเศษคือการพิสูจน์ “จำนวนลิขสิทธิ์ที่ถือครอง” หลักฐานของซอฟต์แวร์ที่ซื้อมาเมื่อ 5 ปีก่อนเหลืออยู่แค่ในกล่องจดหมายของผู้รับผิดชอบในตอนนั้น ตัวแทนจำหน่ายที่ซื้อมาปิดกิจการไปแล้ว เหตุการณ์แบบนี้ไม่ใช่เรื่องแปลก
และเมื่อรวมฐานผลิตในต่างประเทศเข้ามาด้วย งานนี้จะกลายเป็นการร้องขอไปยังผู้รับผิดชอบในแต่ละประเทศ จัดรูปแบบเอกสารให้ตรงกัน แล้วรวบรวมพร้อมกับสอบถามข้อสงสัยไปด้วย จนบางกรณีก็หลีกเลี่ยงไม่ได้ที่จะต้องหยุดงานปกติมารับมือ
ภาระจะหนักหรือเบาตัดสินกันที่การตั้งรับช่วงแรก
สิ่งที่ชี้ขาดผลลัพธ์ของการรับมือการตรวจสอบคือการตั้งรับช่วงแรก ขอสรุปจุดสำคัญเชิงปฏิบัติไว้ดังนี้
- เมื่อได้รับหนังสือแจ้ง ให้รวมช่องทางการตอบกลับภายในองค์กรให้เหลือช่องทางเดียว หากผู้รับผิดชอบหลายคนต่างตอบแยกกัน จะเกิดความขัดแย้งของข้อมูลตามมาภายหลังและทำลายความน่าเชื่อถือ
- ตรวจสอบข้อสัญญาว่าด้วยการตรวจสอบในเอกสารสัญญา แล้วจับให้แม่นว่าขอบเขตการส่งข้อมูล กำหนดเวลา และผลิตภัณฑ์เป้าหมายคืออะไร ไม่จำเป็นต้องให้ข้อมูลเกินกว่าที่ถูกร้องขอ
- การรีบซื้อลิขสิทธิ์เพิ่มหรือลบการติดตั้งออกหลังจากที่การตรวจสอบเริ่มแล้ว อาจทำให้สถานการณ์แย่ลง ให้ยึดการจับข้อเท็จจริงให้แม่นยำเป็นลำดับแรก
- เผื่อกรณีที่ผลการรวบรวมของบริษัทกับของผู้ตรวจสอบไม่ตรงกัน ให้บันทึกที่มาและขั้นตอนของการรวบรวมเอาไว้
การจะตั้งรับแบบนี้ได้หรือไม่ ไม่ใช่เรื่องที่ค่อยมาคิดตอนหนังสือแจ้งการตรวจสอบมาถึงแล้ว จำนวนชั่วโมงงานที่ใช้รับมือจะต่างกันเป็นหลักเท่าตัว ขึ้นอยู่กับว่า ในภาวะปกติได้จัดทำทะเบียนไว้เรียบร้อยหรือไม่ ถ้าจัดทำไว้แล้ว งานก็เหลือเพียงการดึงตัวเลขออกมา แต่ถ้ายังไม่ได้จัดทำ มันจะกลายเป็นโครงการสำรวจข้ามทุกฐานผลิต
อนึ่ง ในภูมิภาคเอเชียตะวันออกเฉียงใต้ ความสนใจต่อการปฏิบัติตามข้อกำหนดลิขสิทธิ์เองก็สูงขึ้นเช่นกัน BSA (Business Software Alliance) ได้เปิดสายด่วนให้คำปรึกษาด้านการปฏิบัติตามข้อกำหนดซอฟต์แวร์สำหรับกลุ่มวิศวกรรม ก่อสร้าง และการผลิต ในประเทศไทย อินโดนีเซีย มาเลเซีย และฟิลิปปินส์ พร้อมทั้งเดินหน้ารณรงค์ให้แก้ไขการใช้ซอฟต์แวร์ที่ไม่ได้รับอนุญาต สำหรับบริษัทที่มีฐานการผลิตในไทย ข้อเท็จจริงที่ว่าพื้นที่นี้ถูกจับตาในระดับภูมิภาคด้วย จึงคุ้มค่าที่จะจดจำไว้
ต้นทุนและผลตอบแทนของการบริหารสินทรัพย์ซอฟต์แวร์
ปฏิกิริยาที่ว่า “เข้าใจว่าจำเป็น แต่ไม่มีกำลังพอจะลงแรงขนาดนั้น” เป็นเรื่องธรรมดา ตรงนี้จะมาดูความคุ้มค่าเป็นตัวเลขกัน
ค่าใช้จ่ายของโปรแกรมอยู่ที่ 0.4-1.2% ของงบประมาณ IT
ตาม Software License Compliance Cost Benchmark 2026 ซึ่งเก็บข้อมูลในช่วงไตรมาสที่ 4 ของปี 2025 ถึงไตรมาสที่ 1 ของปี 2026 บริษัทที่ดำเนินโปรแกรม SAM และการปฏิบัติตามข้อกำหนดลิขสิทธิ์อยู่ มี ค่าใช้จ่ายของโปรแกรมอยู่ที่ 0.4-1.2% ของงบประมาณ IT โดยมีค่ามัธยฐานที่ 0.7%
ตัวเลขนี้เป็นยอดรวมที่นับทั้งค่าเครื่องมือ ค่าจ้างบุคลากรผู้รับผิดชอบ และค่าใช้จ่ายสำหรับการสนับสนุนจากภายนอก เมื่อดูที่ค่ามัธยฐานก็อยู่ในระดับไม่ถึง 1% ของงบประมาณ IT ทั้งหมด ซึ่งไม่ใช่ตัวเลขเล็ก ๆ แต่ก็ไม่ถึงขนาดต้องตั้งแผนกเฉพาะขึ้นมาใหม่
ROI อยู่ที่ 6-14 เท่า
เบนช์มาร์กฉบับเดียวกันรายงาน ผลตอบแทนจากการลงทุน (ROI) ของโปรแกรม SAM ไว้ที่ 6-14 เท่า โดยแยกรายละเอียดของผลลัพธ์ออกเป็น 3 ส่วน
- การลดต้นทุนการรับมือการตรวจสอบ ถ้าทะเบียนพร้อม ชั่วโมงงานภายในและค่าจ้างภายนอกที่ใช้ในการรับมือการตรวจสอบจะลดลงอย่างมาก เมื่อคำนึงถึงความจริงที่ว่ามีองค์กรถึง 44% ที่ใช้จ่ายกับการตรวจสอบเกิน 1 ล้านดอลลาร์สหรัฐดังที่กล่าวไปแล้ว ส่วนลดตรงนี้ก็มองข้ามไม่ได้
- การปรับลิขสิทธิ์ให้เหมาะสม การขจัดลิขสิทธิ์ที่ไม่มีใครใช้ รุ่นที่เกินความจำเป็น และสัญญาซ้ำซ้อน ทำให้รายจ่ายลดลงโดยตรง
- การเสริมอำนาจต่อรองในการต่ออายุ บริษัทที่แสดงสภาพการใช้งานจริงออกมาเป็นตัวเลขได้ ย่อมอยู่ในสถานะที่ได้เปรียบในการเจรจาต่ออายุสัญญากับผู้ผลิตซอฟต์แวร์ การต่ออายุแบบ “ไม่ค่อยแน่ใจ เอาเท่าปีที่แล้วละกัน” คือการต่ออายุที่แพงที่สุด
ข้อที่สามนี้มักถูกมองข้าม แต่ในทางปฏิบัติแล้วได้ผลมากที่สุด ฝั่งผู้ผลิตซอฟต์แวร์รู้สถานะการใช้งานผลิตภัณฑ์ของตัวเองอยู่แล้ว หากฝั่งลูกค้าไม่รู้ การเจรจาก็จะดำเนินไปในสภาพที่ข้อมูลไม่สมมาตร การสร้างสภาพที่ว่าบริษัทเรารู้สภาพจริงของบริษัทเราดีที่สุด จึงเป็นจุดตั้งต้นของการเจรจา
สัญญาบำรุงรักษากับสัญญาลิขสิทธิ์เป็นคนละเรื่องกัน แต่ก็ถูกสับสนได้ง่าย และถ้าแยกสองอย่างนี้ไม่ออก รายจ่ายที่ไม่โปร่งใสจะสะสมขึ้นทุกครั้งที่ต่ออายุ ประเด็นนี้เราพูดถึงไว้ใน ค่าใช้จ่ายในการบำรุงรักษาระบบธุรกิจ 2026 ด้วยเช่นกัน
ความเสี่ยงหากปล่อยทิ้งไว้โดยไม่จัดทำ
ในทางกลับกัน ขอสรุปเป็นตารางว่าถ้าปล่อยทิ้งไว้โดยไม่จัดทำจะเกิดอะไรขึ้นบ้าง
| ด้านความเสี่ยง | สิ่งที่เกิดขึ้นอย่างเป็นรูปธรรม | รูปแบบของผลกระทบ |
|---|---|---|
| การตรวจสอบจากผู้ผลิตซอฟต์แวร์ | ถูกเรียกเก็บค่าลิขสิทธิ์ส่วนที่ขาดและเกิดชั่วโมงงานรับมือ | รายจ่ายก้อนเดียวที่ไม่ได้คาดคิดและงานที่ชะงัก |
| การปฏิบัติตามข้อกำหนด | ปัญหาทางกฎหมายและชื่อเสียงจากการถูกพบว่าใช้งานโดยไม่ได้รับอนุญาต | ถูกชี้ประเด็นตอนคู่ค้าตรวจประเมินหรือสำนักงานใหญ่ตรวจสอบ |
| การควบคุมภายใน | ถูกชี้ให้ปรับปรุงในงาน ITGC และ J-SOX | ต้องชี้แจงต่อสำนักงานสอบบัญชีอย่างต่อเนื่อง |
| ต้นทุน | จ่ายเงินให้ลิขสิทธิ์ที่ไม่มีใครใช้ต่อไปเรื่อย ๆ | ถูกคงไว้เป็นต้นทุนคงที่ในการต่ออายุทุกปี |
| Shadow IT | การนำเข้ามาใช้งานที่ฝ่าย IT ไม่รับรู้ขยายตัว | พบการติดตั้งนอกความคาดหมายตอนถูกตรวจสอบ |
| ความต่อเนื่องทางธุรกิจ | มาตรการระงับการใช้งานซอฟต์แวร์หลัก | งานออกแบบและงานผลิตหยุดโดยตรง |
บรรทัดสุดท้ายคือรายการที่หนักที่สุด หากตรวจพบการละเมิดลิขสิทธิ์ ผู้ผลิตซอฟต์แวร์บางรายอาจใช้มาตรการระงับการใช้ผลิตภัณฑ์จนกว่าจะแก้ไขเสร็จ ถ้า CAD หรือระบบบริหารการผลิตหยุด ทั้งงานออกแบบและการส่งมอบก็หยุดตาม การบริหารลิขสิทธิ์จึงเป็นทั้งปัญหาด้านการปฏิบัติตามข้อกำหนด และปัญหาด้านความต่อเนื่องทางธุรกิจไปพร้อมกัน
6 ขั้นตอนนำการบริหารสินทรัพย์ซอฟต์แวร์ไปใช้จริง
แล้วจะเริ่มจากอะไร สิ่งสำคัญคือการรักษาลำดับ ต่อให้รีบซื้อเครื่องมือมา ถ้าไม่มีการออกแบบว่าจะเอาไปใส่ไว้ตรงไหน ก็ไม่เป็นรูปเป็นร่าง
ขั้นตอนที่ 1 – กำหนดขอบเขตและผู้รับผิดชอบ
สิ่งแรกที่ต้องตัดสินใจคือ จะเอาอะไรเป็นเป้าหมาย และใครเป็นผู้รับผิดชอบ ถ้าตั้งเป้าครอบคลุมทั้งบริษัทและทุกซอฟต์แวร์ในคราวเดียว จะล้มเหลวแน่นอน ให้เริ่มจากผลิตภัณฑ์ที่มูลค่าสูงและมีความเสี่ยงถูกตรวจสอบสูงก่อน โดยเจาะจงไปที่ระบบปฏิบัติการ ชุดโปรแกรมสำนักงาน ฐานข้อมูล CAD และ ERP
ส่วนผู้รับผิดชอบ ให้เขียนการแบ่งบทบาทระหว่างสำนักงานใหญ่ที่ญี่ปุ่นกับฐานผลิตในไทยออกมาเป็นลายลักษณ์อักษร การขีดเส้นอย่างเช่น “สำนักงานใหญ่บริหารข้อมูลสัญญาของทั้งบริษัท ฐานผลิตในไทยรับหน้าที่รายงานสภาพการติดตั้ง” ควรทำเป็นเอกสารแทนการตกลงกันด้วยวาจา ซึ่งจะส่งผลดีในภายหลัง
ขั้นตอนที่ 2 – รวบรวมข้อมูลสัญญาไว้ที่เดียว
รวบรวมหลักฐานการซื้อ เอกสารสัญญา ใบรับรองลิขสิทธิ์ และข้อมูลบนพอร์ทัลของลิขสิทธิ์แบบปริมาณ จากทุกฐานผลิตมาไว้ที่เดียวกัน งานนี้เป็นงานที่ดูไม่หวือหวาที่สุดและกินเวลามากที่สุด
จะต้องมีหลักฐานในอดีตบางส่วนที่หาไม่เจอแน่นอน แต่สิ่งสำคัญคืออย่าหยุดอยู่ตรงนั้น สิ่งที่หาไม่เจอให้บันทึกว่า “ไม่ทราบ” แล้วจัดเป็นรายการที่จะรื้อสัญญาใหม่ในการต่ออายุครั้งถัดไป
ขั้นตอนที่ 3 – เก็บสภาพการติดตั้งด้วยวิธีอัตโนมัติ
การรวบรวมสภาพการติดตั้งด้วยแบบสอบถามที่ใช้แรงคนมีขีดจำกัด ให้ใช้ฟังก์ชันสำรวจรายการของเครื่องมือจัดการทรัพย์สินหรือเครื่องมือจัดการอุปกรณ์ปลายทาง เก็บข้อมูลด้วยวิธีอัตโนมัติ
สิ่งสำคัญตรงนี้คือ ทำให้เครื่องที่เก็บข้อมูลไม่ได้เหลือใกล้ศูนย์ เครื่อง PC ที่ติดมากับอุปกรณ์และไม่ได้ต่อเครือข่ายตลอดเวลา โน้ตบุ๊กสำหรับพกออกนอกสถานที่ เครื่องที่รับคืนจากผู้ที่ลาออกและเก็บรักษาไว้ ถ้าเครื่องเหล่านี้หลุดจากการรวบรวม ก็จะกลายเป็นสาเหตุที่ทำให้พบการติดตั้งนอกความคาดหมายตอนถูกตรวจสอบ
ขั้นตอนที่ 4 – กระทบยอดเพื่อให้เห็นช่องว่าง
นำข้อมูลสัญญามากระทบยอดกับสภาพการติดตั้งแยกตามผลิตภัณฑ์ แล้วสาวออกมาว่าส่วนไหนขาดและส่วนไหนเกิน ณ จุดนี้เองที่จะเห็นสภาพจริงของบริษัทเป็นครั้งแรก
ในหลายบริษัทจะพบทั้งส่วนที่ขาดและส่วนที่เกินพร้อมกัน คือผลิตภัณฑ์หนึ่งขาดไป 10 ชุด ในขณะที่อีกผลิตภัณฑ์หนึ่งเหลืออยู่ 30 ชุด บางกรณีการเจรจายกเลิกส่วนที่เกินควบคู่ไปกับการซื้อส่วนที่ขาด ก็สามารถแก้ไขให้ถูกต้องได้โดยไม่ต้องเพิ่มรายจ่าย
ขั้นตอนที่ 5 – เดินกฎการปฏิบัติงานให้เป็นวงจร
นี่คือการวางกลไกเพื่อไม่ให้จบลงแค่การตรวจนับครั้งเดียว ให้ฝัง 3 ข้อต่อไปนี้เข้าไปในกระบวนการทำงาน
- ใส่ขั้นตอนการลงทะเบียนเข้าทะเบียนตอนซื้อใหม่ ให้เป็นขั้นตอนบังคับภายในกระบวนการจัดซื้อ
- รวมการถอนการจัดสรรลิขสิทธิ์เข้าไปในการจัดการบัญชีตอนเข้างาน ลาออก และโยกย้าย
- ตรวจสอบวิธีจัดการกับซอฟต์แวร์ที่ติดตั้งอยู่ ตอนที่จะทิ้งหรือเปลี่ยนเครื่อง PC
ถ้า 3 ข้อนี้เดินเป็นวงจรได้ ความเร็วในการเสื่อมสภาพของทะเบียนจะลดลงอย่างมาก
ขั้นตอนที่ 6 – สื่อสารภายในองค์กรและปิดทางเข้าของ Shadow IT
ขั้นสุดท้ายคือการสื่อสารไปยังหน้างาน การเรียงข้อห้ามออกมาอย่างเดียวไม่เกิดผลจริง วิธีที่เป็นไปได้จริงคือเตรียมเส้นทางที่ว่า “ถ้ามีซอฟต์แวร์ที่จำเป็นต่องาน ยื่นขอแล้วได้ใช้” ไว้ก่อน แล้วค่อยหยุดการนำเข้ามาใช้เองตามใจ ถ้ายื่นขอแล้วต้องรอครึ่งปีแต่กลับเพิ่มความเข้มของการห้ามอย่างเดียว การนำเข้ามาใช้จะยิ่งเดินหน้าในที่ที่มองไม่เห็น
ทำเองหรือให้ภายนอกทำ
การเดิน 6 ขั้นตอนข้างต้นด้วยกำลังคนที่จำกัดของฐานผลิตในไทยเพียงลำพังนั้นไม่ง่าย โดยเฉพาะการรวบรวมข้อมูลสัญญาในขั้นตอนที่ 2 และการกระทบยอดในขั้นตอนที่ 4 ซึ่งต้องการทั้งความรู้เฉพาะทางและเวลาที่ไม่ถูกงานอื่นแทรก
ทางเลือกที่เป็นไปได้จริงคือการมอบส่วนของการดำเนินงาน SAM ให้ภายนอกทำ แต่การโยนให้ทั้งหมดจะไม่ทำงาน จำเป็นต้องขีดเส้นว่า การตัดสินใจเรื่องสัญญาและการสื่อสารภายในองค์กรยังเก็บไว้กับตัวเอง ส่วนงานที่เป็นรูปแบบตายตัวอย่างการเก็บรายการติดตั้ง การกระทบยอด และการจัดทำรายงาน ให้ส่งออกไปข้างนอก แนวคิดนี้เราเรียบเรียงไว้อย่างละเอียดใน การเอาท์ซอร์สแผนก IT ในประเทศไทย 2026
แนวโน้มการบริหารสินทรัพย์ซอฟต์แวร์ในปี 2026
ท้ายที่สุด ขอจับทิศทางที่จะเกิดขึ้นต่อจากนี้ไว้ด้วย
มุ่งสู่ SAM เชิงพยากรณ์ด้วย AI
ตามบทวิเคราะห์แนวโน้ม SAM ปี 2026 ที่ OpenLM Japan เผยแพร่ แนวโน้มกำลังมุ่งไปในทิศทางที่เครื่องมือ SAM ซึ่งใช้ AI จะจับสถานะการติดตั้งและสถานะการใช้งานได้โดยอัตโนมัติ แล้ว พยากรณ์จำนวนลิขสิทธิ์ที่จะต้องใช้ในอนาคต
ในขณะที่ SAM แบบเดิมเน้นไปที่การ “นับสถานะปัจจุบันให้ถูกต้อง” SAM ต่อจากนี้จะเดินไปในทิศทางที่เสนอว่า “งวดหน้าต้องใช้กี่ชุด” ถ้าประเมินจำนวนลิขสิทธิ์ที่จำเป็นล่วงหน้าให้สอดคล้องกับแผนเพิ่มกำลังคนหรือการเริ่มโครงการใหม่ได้ ก็จะไม่ต้องรีบซื้อเพิ่มระหว่างงวดอีก
อย่างไรก็ตาม สิ่งที่เป็นเงื่อนไขตั้งต้นของการพยากรณ์คือข้อมูลสถานะปัจจุบันที่ถูกต้อง ต่อให้นำเครื่องมือ AI เข้ามาใช้ทั้งที่ทะเบียนยังกระจัดกระจาย ผลที่ได้ก็เป็นแค่การพยากรณ์ที่ผิดจากข้อมูลที่ผิด ในเชิงลำดับแล้ว การทำให้เห็นสถานะปัจจุบันต้องมาก่อน
ขอบเขตการบริหารขยายไปสู่ SaaS และ AI
การเปลี่ยนแปลงอีกอย่างคือการขยายตัวของขอบเขตที่ต้องบริหาร ในอดีตเป้าหมายของ SAM คือซอฟต์แวร์แบบซื้อขาดที่ติดตั้งลงบน PC เป็นหลัก ปัจจุบันมีการสมัครสมาชิกแบบ SaaS ลิขสิทธิ์บนคลาวด์ และสิทธิ์การใช้เครื่องมือ Generative AI เพิ่มเข้ามา
สิ่งเหล่านี้ทำสัญญาได้ด้วยการชำระเงินผ่านบัตรเครดิตโดยไม่ต้องผ่านฝ่ายจัดซื้อ จึงมีลักษณะที่หลุดจากตาข่ายของการจัดการทรัพย์สินแบบเดิมได้ง่าย ผลสำรวจของ Flexera ที่กล่าวถึงตั้งแต่ต้นบทความ สะท้อนความหยาบของตาข่ายนี้ได้อย่างตรงไปตรงมา
ในฐานผลิตที่ประเทศไทยเองก็มีตัวอย่างที่พนักงานท้องถิ่นทำสัญญาเครื่องมือคลาวด์ต่าง ๆ แยกกันเองเพื่อเพิ่มประสิทธิภาพการทำงานมากขึ้นเรื่อย ๆ จึงจำเป็นต้องออกแบบขอบเขตของ SAM ให้ขยายครอบคลุมไม่ใช่แค่ซอฟต์แวร์แบบติดตั้ง แต่รวมถึงสัญญาแบบสมัครสมาชิกทั้งหมด
คำถามที่พบบ่อย
การบริหารสินทรัพย์ซอฟต์แวร์ต้องใช้คนกี่คนถึงจะเดินได้
ขึ้นอยู่กับขนาด แต่ถ้ามีฐานผลิตไม่กี่แห่งและจำกัดเป้าหมายไว้ที่ผลิตภัณฑ์หลัก มีผู้รับผิดชอบเต็มเวลา 1 คนก็เดินได้อย่างเพียงพอ ผู้ผลิตขนาดกลางจำนวนมากเริ่มจากการจัดสรรเวลาเดือนละไม่กี่วัน ในฐานะส่วนหนึ่งของงานผู้ดูแล IT สิ่งสำคัญไม่ใช่จำนวนคน แต่คือกฎการปฏิบัติงานในขั้นตอนที่ 5 ถูกฝังเข้าไปในกระบวนการจัดซื้อและงานบุคคลแล้วหรือยัง ถ้ากฎยังไม่เข้าไป มีคนกี่คนทะเบียนก็เสื่อมสภาพอยู่ดี
ตราบใดที่ยังไม่ถูกตรวจสอบ ไว้ทีหลังก็ได้ไม่ใช่หรือ
ในเชิงสถิติแล้วไม่ใช่สถานการณ์ที่จะผัดไว้ทีหลังได้ ดังที่กล่าวไปแล้วว่าองค์กรที่ถูกตรวจสอบในรอบ 1 ปีที่ผ่านมามีถึง 48% ยิ่งกว่านั้น ต่อให้ไม่ถูกตรวจสอบจากผู้ผลิตซอฟต์แวร์ ก็ยังมีเส้นทางที่จะถูกสำนักงานสอบบัญชีชี้ประเด็นในมุมของการควบคุมภายใน และการจ่ายเงินให้ลิขสิทธิ์ที่ไม่มีใครใช้ก็ยังเกิดขึ้นทุกปีต่อไป ต่อให้ไม่มีแรงกดดันจากภายนอกอย่างการตรวจสอบ ความสมเหตุสมผลของการจัดทำก็ตั้งอยู่ได้ด้วยด้านต้นทุนเพียงอย่างเดียว
ใช้เครื่องมือฟรีหรือโปรแกรมตารางคำนวณบริหารได้ไหม
ถ้าขนาดอยู่ที่ฐานผลิตแห่งเดียว เครื่องไม่กี่สิบเครื่อง และผลิตภัณฑ์เป้าหมายไม่กี่ตัว ตารางคำนวณก็ใช้งานได้ แต่เมื่อเข้าสู่ระยะที่ฐานผลิตกระจายข้ามหลายประเทศและจำนวนเครื่องเกินหลายร้อยเครื่อง การซิงค์ข้อมูลและความล่าช้าของการปรับปรุงข้อมูลจะกลายเป็นปัญหา เกณฑ์ตัดสินคร่าว ๆ คือ “ใช้เวลากี่สัปดาห์กว่าจะตรวจนับเสร็จ” ถ้าใช้เวลาเกิน 1 เดือน ก็ถึงขั้นที่ควรพิจารณานำเครื่องมือเข้ามาใช้
จัดทำเฉพาะฐานผลิตในไทยก่อนจะมีความหมายไหม
มีความหมาย ในทางปฏิบัติแล้วการสร้างต้นแบบให้เสร็จก่อนในหน่วยที่ขอบเขตจำกัดอย่างฐานผลิตในไทย แล้วค่อยขยายไปยังฐานผลิตอื่น กลับเป็นวิธีเดินที่สำเร็จง่ายกว่า ถ้าเริ่มพร้อมกันทั้งบริษัท จะหยุดชะงักเพราะรับมือความแตกต่างของเงื่อนไขในแต่ละฐานผลิตไม่ไหว เราจึงแนะนำลำดับที่ว่า ทำให้เดินได้จริงในฐานผลิตเดียวก่อน แล้วจึงขยาย
สรุป
ขอสรุปประเด็นสำคัญของบทความนี้
- การบริหารสินทรัพย์ซอฟต์แวร์คือกิจกรรมการบริหารที่นำจำนวนลิขสิทธิ์ที่ถือครอง จำนวนชุดที่ติดตั้ง และสภาพการใช้งานจริง มากระทบยอดกันอย่างต่อเนื่อง ซึ่งต่างจากการบริหารทะเบียนฮาร์ดแวร์ทั้งในแง่เป้าหมายและความยาก
- ตาม 2026 State of ITAM Report ของ Flexera ที่เผยแพร่วันที่ 24 มิถุนายน 2026 องค์กรที่ถูกตรวจสอบในรอบ 1 ปีที่ผ่านมามี 48% และองค์กรที่ใช้จ่ายกับการตรวจสอบเกิน 1 ล้านดอลลาร์สหรัฐในรอบ 3 ปีมีถึง 44%
- อัตราการตรวจสอบแยกตามผู้ผลิตซอฟต์แวร์คือ Microsoft 64% Oracle 38% และ Adobe 32% โดย Oracle และ Adobe เพิ่มขึ้นอย่างชัดเจนจากเดิมที่ 24%
- องค์กรที่มองเห็นทรัพย์สิน IT ได้อย่างครบถ้วนมี 36% และองค์กรที่จับสภาพการใช้งานซอฟต์แวร์ AI ได้มีเพียง 31% ตาข่ายของการบริหารจึงตามสภาพแวดล้อม IT ที่ขยายตัวไม่ทัน
- ในฐานผลิตไทยและอาเซียน การปรับให้เหมาะสมเฉพาะของแต่ละฐานผลิตทำให้ทะเบียนกระจัดกระจาย และเกิด “ช่องว่างสองชั้น” ที่ทั้งฝั่งไทยและสำนักงานใหญ่ต่างมองไม่เห็นสภาพจริงได้ง่าย
- ERP, CAD และระบบบริหารการผลิตของภาคการผลิตมีวิธีนับต่างกันไปในแต่ละผลิตภัณฑ์ ทั้งลิขสิทธิ์แบบเซิร์ฟเวอร์ CAL และแบบใช้งานพร้อมกัน เครื่องมือจัดการทรัพย์สิน PC แบบทั่วไปเพียงอย่างเดียวจึงตามไม่ไหว
- ในการตรวจสอบต้องรวบรวมจำนวนเครื่องที่ใช้งาน จำนวนชุดซอฟต์แวร์ที่ใช้ และจำนวนลิขสิทธิ์ที่ถือครอง แยกตามซอฟต์แวร์แล้วส่งให้ ซึ่งชั่วโมงงานจะต่างกันเป็นหลักเท่าตัว ขึ้นอยู่กับว่าได้จัดทำทะเบียนไว้ในภาวะปกติหรือไม่
- ค่าใช้จ่ายของโปรแกรม SAM อยู่ที่ 0.4-1.2% ของงบประมาณ IT โดยมีค่ามัธยฐานที่ 0.7% และมีรายงาน ROI ไว้ที่ 6-14 เท่า โดยมีการลดต้นทุนการรับมือการตรวจสอบ การปรับลิขสิทธิ์ให้เหมาะสม และการเสริมอำนาจต่อรองในการต่ออายุ เป็นเสาหลักของผลลัพธ์
การบริหารสินทรัพย์ซอฟต์แวร์เป็นเรื่องประเภทที่ลงมือหลังการตรวจสอบมาถึงแล้วก็ไม่ทัน พูดกลับกันคือ สำหรับบริษัทที่จัดทำทะเบียนไว้เรียบร้อยในภาวะปกติ การตรวจสอบจะกลายเป็นเพียง “งานดึงตัวเลขออกมา” เท่านั้น การสร้างความต่างตรงนี้ได้หรือไม่ คือทางแยกในทางปฏิบัติ
จะเป็นเพียงขั้นของการตัดสินว่าสถานะของบริษัทตัวเองอยู่ระดับไหน และควรเริ่มลงมือจากตรงไหน ก็ยินดีครับ TOMAS TECH ตั้งฐานอยู่ที่กรุงเทพมหานคร ประเทศไทย และสนับสนุนงานภาคปฏิบัติในพื้นที่ให้กับผู้ผลิตสัญชาติญี่ปุ่น ตั้งแต่การตรวจนับทรัพย์สิน IT และลิขสิทธิ์ซอฟต์แวร์ ไปจนถึงการออกแบบการดำเนินงาน เรารับปรึกษาเพียงแค่การจัดระเบียบปัญหาปัจจุบันหรือแนวทางการเดินหน้าก็ได้เช่นกัน หากท่านอยู่ในขั้นพิจารณาและอยากคุยแบบไม่เป็นทางการ ติดต่อสอบถามได้ที่นี่
แหล่งอ้างอิง
- Flexera 2026 State of ITAM Report – Flexera (เผยแพร่วันที่ 24 มิถุนายน 2026 สำรวจผู้เชี่ยวชาญด้าน IT จำนวน 512 คน)
- Software License Compliance Cost Benchmark 2026 – Vendor Benchmark (ช่วงเก็บข้อมูล ไตรมาสที่ 4 ปี 2025 ถึงไตรมาสที่ 1 ปี 2026)
- BSA helpline to fight unlicensed software – Bangkok Post (สายด่วนให้คำปรึกษาด้านการปฏิบัติตามข้อกำหนดสำหรับเอเชียตะวันออกเฉียงใต้โดย BSA)
- การตั้งรับช่วงแรกของการตรวจสอบลิขสิทธิ์ซอฟต์แวร์ – ITR (การเรียบเรียงรายการที่ต้องรวบรวมในการรับมือการตรวจสอบ)
- คำถามที่พบบ่อยเกี่ยวกับการตรวจสอบการปฏิบัติตามข้อกำหนด – Microsoft (เรื่องการดำเนินการตรวจสอบโดยผู้ตรวจสอบอิสระตามสัญญา)
- อนาคตของการบริหารสินทรัพย์ซอฟต์แวร์ SAM แนวโน้มที่น่าจับตาในปี 2026 – OpenLM Japan (บทวิเคราะห์แนวโน้มของเครื่องมือ SAM ที่ใช้ AI)