การบริหารจัดการทรัพย์สินไอทีในโรงงาน ปี 2026 – ครึ่งหนึ่งของสัญญาอยู่นอกทะเบียน

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

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

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

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

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

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

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

การจัดการทรัพย์สินไอทีกับทะเบียนทรัพย์สินเครื่องจักรเป็นคนละเรื่อง – สิ่งที่ต้องจัดการคือสัญญา ไม่ใช่ของ

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

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

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

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

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

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

ทำไมปี 2026 ถึงเป็นจังหวะที่ต้องทบทวน – คลาวด์และ SaaS แซงหน้าทะเบียนไปแล้ว

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

รายงาน Thailand IT and Security Market ของ Mordor Intelligence ซึ่งปรับปรุงข้อมูลเมื่อวันที่ 7 สิงหาคม 2026 ระบุว่าตลาดไอทีและความปลอดภัยของไทยมีแนวโน้มขยายตัวจาก 9.92 พันล้าน USD ในปี 2025 ไปเป็น 10.26 พันล้าน USD ในปี 2026 ส่วนอัตราการเติบโตเฉลี่ยต่อปีหรือ CAGR ระหว่างปี 2026 ถึง 2031 นั้นอยู่ที่ 10.26% พอดี ตัวเลขการเติบโตเองไม่ใช่เรื่องน่าแปลกใจ สิ่งที่ควรสังเกตคือองค์ประกอบข้างใน รายงานฉบับเดียวกันระบุว่าในโครงสร้างตลาดของปี 2025 เมื่อแบ่งตามองค์ประกอบ ซอฟต์แวร์คิดเป็น 41.72% และเมื่อแบ่งตามรูปแบบการติดตั้ง คลาวด์คิดเป็น 55.84%

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

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

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

Money Forward Admina เองก็เขียนบทความอธิบายเรื่องการลดต้นทุนค่าใช้บริการ SaaS ซึ่งเผยแพร่เมื่อวันที่ 30 มกราคม 2026 และปรับปรุงเมื่อวันที่ 23 เมษายน 2026 โดยกล่าวถึงโครงสร้างที่ค่าสมัครสมาชิกซึ่งจับต้นชนปลายไม่ได้เข้ามากดดันการบริหารกิจการ พร้อมยกการลบบัญชีที่ไม่จำเป็น การทบทวนแพ็กเกจ และการจัดระเบียบเครื่องมือที่ซ้ำซ้อน ขึ้นมาเป็นจุดตั้งต้นของงานภาคปฏิบัติ นั่นแปลว่าปัญหาเดียวกันนี้เกิดขึ้นในญี่ปุ่นด้วย ไม่ใช่เรื่องเฉพาะของฐานปฏิบัติการในไทยเท่านั้น

สามเหตุผลที่ทำให้การจัดการทรัพย์สินไอทีของฐานปฏิบัติการในไทยพังง่ายเป็นพิเศษ

เมื่อวางพื้นฐานแบบนั้นแล้ว ฐานปฏิบัติการในไทยยังมีความเปราะบางเฉพาะตัวอยู่อีก 3 ข้อ

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

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

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

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

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

สัญญาที่หลุดจากทะเบียนมีอยู่ 3 รูปแบบ

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

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

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

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

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

กรณีตัวอย่าง – ตรวจนับ 7 สัญญาของโรงงานในระยอง

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

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

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

แค่ทำตารางนี้เสร็จ ก็เจอสิ่งแรกแล้ว ค่าใช้จ่ายต่อปีรวมของ 4 รายการที่อยู่ในทะเบียนคือ 636,000 ซึ่งคิดเป็น 49.5% ของรายจ่ายทั้งหมด ในทางกลับกัน ค่าใช้จ่ายต่อปีรวมของ 3 รายการที่อยู่นอกทะเบียนคือ 648,000 คิดเป็น 50.5% ของรายจ่ายทั้งหมด พูดอีกอย่างคือ รายจ่ายไอทีที่โรงงานแห่งนี้รับรู้อยู่ ยังไม่ถึงครึ่งหนึ่งของรายจ่ายจริง

จุดที่อยากให้สังเกตคือ การอยู่หรือไม่อยู่ในทะเบียนไม่ได้แบ่งตาม “ความสำคัญของระบบ” และไม่ได้แบ่งตาม “จำนวนเงินมากหรือน้อย” สิ่งเดียวที่แบ่งคือฝ่ายที่อนุมัติ 4 รายการที่ฝ่ายไอทีอนุมัติอยู่ในทะเบียนทั้งหมด ส่วน 3 รายการที่ฝ่ายอื่นอนุมัติไม่อยู่ในทะเบียนเลยสักรายการ ยิ่งไปกว่านั้น 3 รายการที่อยู่นอกทะเบียนยังมียอดรวมสูงกว่า และถ้าดูเป็นรายฉบับ สัญญาที่แพงที่สุดคือลำดับที่ 7 ระบบใบเสนอราคาและรับคำสั่งซื้อ ที่ 264,000 ก็อยู่นอกทะเบียนเช่นกัน

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

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

เกิดอะไรขึ้นกับ 3 สัญญาที่อยู่นอกทะเบียน

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

ลำดับที่ 7 ระบบใบเสนอราคาและรับคำสั่งซื้อ (ฝ่ายขายอนุมัติ ค่าใช้จ่ายต่อปี 264,000) ในปีที่สองของสัญญา แพ็กเกจถูกเปลี่ยนไปเป็นแพ็กเกจพรีเมียมด้วยการต่ออายุอัตโนมัติ ค่าใช้จ่ายต่อปีเดิมอยู่ที่ 216,000 แต่หลังต่ออายุกลายเป็น 264,000 ส่วนต่างคือ 48,000 เพิ่มขึ้น 22.2% เมื่อเทียบกับค่าใช้จ่ายต่อปีเดิม ฝ่ายขายไม่ได้รับรู้ว่าถูกเปลี่ยนไปเป็นแพ็กเกจระดับสูงขึ้น และไม่ได้ใช้ฟังก์ชันที่เพิ่มเข้ามาด้วย

ลำดับที่ 5 แชทบอทตอบคำถามภายในองค์กร (ฝ่ายธุรการอนุมัติ ค่าใช้จ่ายต่อปี 216,000) เป็นสิ่งที่ฝ่ายธุรการทำสัญญาไว้เพื่อเพิ่มประสิทธิภาพของการตอบคำถามจากพนักงาน แต่ผลการตรวจสอบพบว่า ภายในขอบเขตของสัญญาเดิมของระบบบริหารการผลิต (ลำดับที่ 1) มีฟังก์ชัน FAQ และฟังก์ชันช่วยเหลือพ่วงมาตั้งแต่ต้น พูดอีกอย่างคือฟังก์ชันซ้ำซ้อนกัน และเมื่อตรวจสอบสถิติการใช้งานเพิ่มเติม พบว่าจากคำถามเดือนละ 90 รายการ มีเพียง 18 รายการ (20.0%) เท่านั้นที่ถูกใช้เป็นการสอบถามภายในองค์กรจริง ส่วนที่เหลือเป็นการทดลองใช้และการเปิดเรื่องซ้ำ

ลำดับที่ 6 ระบบเงินเดือนและงานบุคคล (ฝ่ายบัญชีอนุมัติ ค่าใช้จ่ายต่อปี 168,000) เป็นระบบที่คิดเงินตามหน่วยของรหัสผู้ใช้ และมีบัญชีของพนักงานที่ลาออกไปแล้วค้างอยู่ 5 สิทธิ์ ค่าใช้จ่ายต่อหนึ่งสิทธิ์อยู่ที่เดือนละ 800 THB หรือปีละ 9,600 THB รวม 5 สิทธิ์แล้วเท่ากับปีละ 48,000 THB ที่จ่ายให้กับบัญชีซึ่งไม่มีใครใช้งาน

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

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

การต่อสัญญาอัตโนมัติสร้างการขึ้นราคาแบบเงียบ ๆ

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

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

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

ในกรณีตัวอย่าง ลำดับที่ 7 มีค่าใช้จ่ายต่อปีเพิ่มจาก 216,000 เป็น 264,000 คิดเป็นส่วนต่าง 48,000 ถ้ามองเป็นรายปีเดียว จำนวนนี้ไม่ถึงขั้นต้องเสนอขออนุมัติ และก็ไม่มีใครสังเกตเห็นว่ามันเพิ่มขึ้น แต่ 48,000 นี้จะเกิดขึ้นอีกในปีหน้าและปีถัดไป ยิ่งกว่านั้น สัญญาที่ต่ออายุด้วยแพ็กเกจระดับสูงไปแล้วครั้งหนึ่ง จะดำเนินต่อด้วยแพ็กเกจระดับสูงนั้นในการต่ออายุครั้งถัดไปด้วย ส่วนต่างสะสมจะยิ่งถ่างออกตามความยาวของช่วงเวลาที่ปล่อยทิ้งไว้

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

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

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

สัญญาซ้ำซ้อนเกิดขึ้นได้อย่างไร – ฟังก์ชันทับกันได้ แต่สัญญาเป็นคนละฉบับ

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

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

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

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

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

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

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

ทำไมซอฟต์แวร์สายวิศวกรรมถึงยากเป็นพิเศษ

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

คู่มือเปรียบเทียบโซลูชันบริหารจัดการไลเซนส์สำหรับไอทีระดับองค์กร ฉบับปี 2026 ของ OpenLM Japan ซึ่งเผยแพร่เมื่อวันที่ 17 มิถุนายน 2026 จัดวางซอฟต์แวร์สายวิศวกรรมอย่าง Autodesk, Bentley, ANSYS, Esri และ Dassault Systèmes ไว้ในฐานะขอบเขตที่ต้องการการบริหารจัดการไลเซนส์ซึ่งทั้งมีมูลค่าสูงและซับซ้อนเป็นพิเศษ เหตุที่ขอบเขตนี้ยากในการจัดการทรัพย์สินของโรงงาน เป็นเพราะมีเงื่อนไขต่อไปนี้ซ้อนทับกัน

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

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

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

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

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

ตรวจนับแล้วตัวเลขขยับแค่ไหน – รายละเอียดการลดค่าใช้จ่ายของกรณีตัวอย่าง

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

เมื่อเทียบกับรายจ่ายทั้งหมด 1,284,000 จำนวนที่ลดได้คือ 216,000 คิดเป็นอัตราการลดลง 16.8% และถ้าสภาพหลังการตรวจนับถูกรักษาไว้ได้ ยอดสะสมอย่างง่ายในระยะ 5 ปีจะเท่ากับการลดลง 1,080,000 โดยประมาณการนี้ยังไม่ได้รวมต้นทุนของแรงงานที่ใช้ในการตรวจนับ

พอไล่ดูรายละเอียด จะสังเกตได้ว่าธรรมชาติของมาตรการทั้ง 3 ข้อต่างกันโดยสิ้นเชิง

การลดขนาดแชทบอท (120,000) เป็นการตัดสินใจที่อ้างอิงทั้งความซ้ำซ้อนของฟังก์ชันและสถิติการใช้งาน เป็นมาตรการที่มีจำนวนเงินใหญ่ที่สุดในสามข้อ และใช้เวลาพิจารณานานที่สุดด้วย เพราะต้องตรวจสอบว่าฟังก์ชัน FAQ ของระบบบริหารการผลิตเดิมใช้กับวัตถุประสงค์ที่ฝ่ายธุรการต้องการได้จริงหรือไม่ และต้องตัดสินใจว่าจะรองรับการใช้งานจริงเดือนละ 18 รายการอย่างไร ยิ่งมาตรการมีจำนวนเงินใหญ่ ยิ่งต้องการทั้งการตรวจสอบทางเทคนิคและการตกลงร่วมกันระหว่างฝ่าย

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

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

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

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

ขั้นตอนปฏิบัติของการบริหารจัดการทรัพย์สินไอที 4 ขั้น – ทะเบียน ตรวจนับ รวมสัญญา และเฝ้าระวังการต่ออายุ

ขอจัดระเบียบเนื้อหาทั้งหมดข้างต้นให้เป็นขั้นตอนปฏิบัติ 4 ขั้น ลำดับมีความหมายในตัวเอง จึงขอให้เดินตามโดยไม่ข้ามขั้น

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

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

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

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

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

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

เส้นแบ่งระหว่างสิ่งที่ทำเองกับสิ่งที่จ้างภายนอก

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

สิ่งที่ทำงานได้จริงในทางปฏิบัติคือการแบ่งแบบนี้ การถือครองทะเบียนและการเฝ้าระวังการต่ออายุให้อยู่ภายในบริษัท ส่วนการวิเคราะห์ในการตรวจนับและการออกแบบการเจรจาสัญญาให้จ้างภายนอก

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

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

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

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

ประเด็นเฉพาะที่ได้ผลกับฐานปฏิบัติการในไทยและอาเซียน

ขอยกประเด็นที่ไม่ปรากฏในการถกเถียงภายในประเทศญี่ปุ่น แต่เกิดขึ้นเมื่อดำเนินงานในประเทศไทย

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

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

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

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

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

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

10 หัวข้อที่ต้องเขียนลงในแบบฟอร์มตรวจนับ

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

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

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

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

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

5 รูปแบบความผิดพลาดที่พบบ่อย

ขอยกความผิดพลาด 5 ข้อที่เห็นมาจริงในโรงงานญี่ปุ่นในประเทศไทย

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

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

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

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

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

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

การบริหารจัดการทรัพย์สินไอทีคือการจัดการอะไรบ้าง

คือกิจกรรมที่ทำความเข้าใจฮาร์ดแวร์ ซอฟต์แวร์ และสัญญากับไลเซนส์ที่ผูกอยู่กับสิ่งเหล่านั้น อย่างรวมศูนย์ในฐานะทรัพย์สินของบริษัท ในโรงงานมักเริ่มจากการจัดการเครื่องปลายทางในฐานะส่วนต่อขยายของทะเบียนทรัพย์สินเครื่องจักร แต่ศูนย์กลางของรายจ่ายในปัจจุบันย้ายไปอยู่ที่สัญญาซอฟต์แวร์และคลาวด์แล้ว รายงานตลาดไทยของ Mordor Intelligence เองก็ระบุว่าในโครงสร้างตลาดปี 2025 ซอฟต์แวร์คิดเป็น 41.72% และเมื่อแบ่งตามรูปแบบการติดตั้ง คลาวด์คิดเป็น 55.84% ดังนั้นการบริหารจัดการทรัพย์สินไอทีของโรงงานจึงจำเป็นต้องทำทะเบียนสัญญาแยกจากทะเบียนสิ่งของ แล้วบริหารฝ่ายที่อนุมัติ ค่าใช้จ่ายต่อปี หน่วยของการคิดเงิน วันที่ต่ออายุ และกำหนดสุดท้ายของการแจ้งยกเลิก

การบริหารจัดการไลเซนส์ซอฟต์แวร์ควรเริ่มจากอะไร

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

ในการรับมือ Shadow IT ควรสั่งหยุดอะไรก่อน

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

การจัดการต่ออายุสัญญาระบบควรทำให้เป็นกลไกอย่างไร

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

การทำให้งบประมาณไอทีมองเห็นได้ ต้องทำถึงระดับไหนจึงจะเห็นผล

แค่ค่าใช้จ่ายต่อปีรายสัญญาถูกเรียงอยู่ในกระดาษแผ่นเดียวจนรวมยอดได้ ผลแรกก็เกิดขึ้นแล้ว ในกรณีตัวอย่าง แค่เรียง 7 สัญญาลงในแผ่นเดียวก็รู้ทันทีว่า “สิ่งที่อยู่ในทะเบียนคิดเป็น 49.5% ของรายจ่ายทั้งหมด” และจากจุดนั้นก็นำไปสู่การลดค่าใช้จ่ายปีละ 216,000 THB ด้วย 3 มาตรการ คิดเป็นอัตราการลดลง 16.8% ขั้นถัดไป เมื่อวางจำนวนที่ทำสัญญาไว้เรียงคู่กับจำนวนที่ใช้งานจริง รายการที่เป็นผู้ต้องสงสัยของการลดค่าใช้จ่ายจะลอยขึ้นมาอย่างเป็นรูปธรรม ไม่จำเป็นต้องสร้างระบบเก็บสถิติการใช้งานอัตโนมัติหรือแดชบอร์ดตั้งแต่แรก แค่ Excel หนึ่งแผ่นกับการแจ้งเตือนวันที่ต่ออายุก็ทำงานได้เพียงพอแล้ว

สรุป

ขอจัดระเบียบประเด็นสำคัญ

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

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

ในประมาณการของกรณีตัวอย่าง โรงงานประกอบชิ้นส่วนอิเล็กทรอนิกส์ในระยองถือสัญญาอยู่ 7 ฉบับ รวมค่าใช้จ่ายต่อปี 1,284,000 THB ในจำนวนนี้ ส่วนที่อยู่ในทะเบียนมีเพียง 636,000 THB คิดเป็น 49.5% ของรายจ่ายทั้งหมด ส่วน 3 สัญญาที่อยู่นอกทะเบียนพบปัญหาคนละแบบ ได้แก่ การเพิ่มขึ้นของค่าใช้จ่ายต่อปีจาก 216,000 เป็น 264,000 จากการต่ออายุอัตโนมัติ ซึ่งเป็นส่วนต่าง 48,000 หรือ 22.2% สัญญาซ้ำซ้อนที่ถูกใช้งานจริงเพียง 18 รายการจาก 90 รายการต่อเดือน คิดเป็น 20.0% และความสูญเปล่าปีละ 48,000 จากบัญชีของผู้ลาออกที่ค้างอยู่ 5 สิทธิ์ หลังการตรวจนับได้ลงมือ 3 มาตรการจนลดค่าใช้จ่ายได้ปีละ 216,000 THB คิดเป็นอัตราการลดลง 16.8% และเมื่อคิดยอดสะสมอย่างง่ายในระยะ 5 ปีจะเท่ากับ 1,080,000 THB ทั้งหมดนี้เป็นประมาณการเฉพาะของเรา ไม่ใช่ตัวเลขของบริษัทที่มีอยู่จริง จึงขอให้ดูที่โครงสร้างว่าการรั่วไหลเกิดขึ้นตรงไหนและจะอุดอย่างไร มากกว่าดูที่จำนวนเงิน

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

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

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

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

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

• OpenLM Japan — คู่มือเปรียบเทียบโซลูชันบริหารจัดการไลเซนส์สำหรับไอทีระดับองค์กร ฉบับปี 2026 (มิถุนายน 2026)
• Cybernet Systems — ประเด็นท้าทายของการบริหารจัดการทรัพย์สินไอทีในระยะถัดไป (คลังความรู้ด้านการบริหารจัดการทรัพย์สินไอที)
• Cybernet Systems — ความสำคัญและจุดสำคัญของการบริหารจัดการไลเซนส์ซอฟต์แวร์ (คลังความรู้ด้านการบริหารจัดการทรัพย์สินไอที)
• Money Forward Admina — แนวทางลดต้นทุน SaaS และการบริหารจัดการไลเซนส์ที่ฝ่ายระบบสารสนเทศควรลงมือทำ (เผยแพร่มกราคม 2026 ปรับปรุงเมษายน 2026)
• Mordor Intelligence — Thailand IT and Security Market Size and Share Analysis (ปรับปรุงสิงหาคม 2026)
• dxeco — Shadow IT คืออะไร ความเสี่ยงที่แฝงอยู่ สาเหตุ และ 5 ขั้นตอนตั้งแต่การสำรวจจนถึงการรับมือ (คอลัมน์ dxeco)