Service as Software (SaS) คือรูปแบบการให้บริการซอฟต์แวร์แบบใหม่ที่ AI Agent จะเข้ามาดำเนินกระบวนการทำงานต่างๆ อย่างอัตโนมัติ และคิดค่าบริการตามผลลัพธ์ที่ได้

ในขณะที่ SaaS แบบเดิมเป็นรูปแบบที่ "จัดหาเครื่องมือให้มนุษย์เป็นผู้ใช้งาน" แต่ SaS หมายถึงการเปลี่ยนผ่านสู่รูปแบบที่ "AI เป็นผู้ปฏิบัติงานนั้นด้วยตนเอง" การเปลี่ยนแปลงนี้กำลังตั้งคำถามถึงรากฐานของกลยุทธ์ด้านราคา การตัดสินใจจัดซื้อ และการออกแบบกระบวนการทำงานในภาคธุรกิจ B2B

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

Service as Software (SaS) คือรูปแบบการให้บริการซอฟต์แวร์แบบใหม่ที่ AI Agent จะเข้ามาดำเนินกระบวนการทำงานต่างๆ อย่างอัตโนมัติ และคิดค่าบริการตามผลลัพธ์ที่ได้ ซึ่งแตกต่างจาก SaaS แบบเดิมที่ขาย "สิทธิ์ในการเข้าถึงเครื่องมือ" โดยสิ้นเชิง เพราะ SaS เน้นการส่งมอบ "การลงมือปฏิบัติงานจริง"

ด้วยความก้าวหน้าอย่างรวดเร็วของ Generative AI และ LLM ทำให้ AI สามารถตัดสินใจและดำเนินการที่ซับซ้อนได้มากกว่าการทำงานแทนมนุษย์ในงานง่ายๆ รูปแบบธุรกิจนี้จึงได้รับความสนใจอย่างรวดเร็ว ในส่วนถัดไป เราจะมาเจาะลึกถึงคำจำกัดความของ SaS และความแตกต่างที่ชัดเจนจาก SaaS กัน

Service as Software (SaS) หมายถึงรูปแบบที่ AI Agent ทำหน้าที่ควบคุมซอฟต์แวร์โดยอัตโนมัติเพื่อดำเนินกระบวนการทางธุรกิจแทนมนุษย์

ความแตกต่างที่สำคัญที่สุดเมื่อเทียบกับ SaaS (Software as a Service) แบบดั้งเดิม คือ "การเป็นผู้ให้บริการเครื่องมือ หรือการเป็นผู้ส่งมอบผลลัพธ์"

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

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

ความแตกต่างนี้ส่งผลโดยตรงต่อโครงสร้างราคา:

• SaaS: คิดค่าบริการแบบเหมาจ่ายตามการใช้ทรัพยากร เช่น จำนวนที่นั่ง (Seat) หรือปริมาณพื้นที่จัดเก็บข้อมูล
• SaS: คิดค่าบริการตามผลลัพธ์ (Outcome-based) เช่น จำนวนงานที่เสร็จสิ้น, ชั่วโมงงานที่ลดลง หรือความแม่นยำของงาน

แม้ว่า SaS มักจะถูกนำไปเปรียบเทียบกับ BPO (Business Process Outsourcing) แต่เนื่องจาก SaS ใช้ AI Agent ในการทำงานแทนแรงงานคน จึงมีแนวโน้มที่จะควบคุมต้นทุนได้ดีกว่าเมื่อมีการขยายขนาด (Scale up) นอกจากนี้ เนื่องจากมีการบันทึก Log การทำงานของ Agent ไว้ ทำให้สามารถคาดหวังถึงการมองเห็นภาพรวมของกระบวนการทางธุรกิจ (Business Process Visualization) ในมุมมองของ AI Observability ได้อีกด้วย

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

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

ความพร้อมทางด้านเทคโนโลยี

ความแม่นยำในการอนุมานของ LLM (Large Language Models) ได้รับการพัฒนาขึ้น จน AI Agent เริ่มเข้าใกล้ระดับที่สามารถปฏิบัติงานที่ซับซ้อนซึ่งเคยต้องอาศัยการตัดสินใจของมนุษย์ได้ด้วยตนเอง ด้วยการนำการอนุมานแบบหลายขั้นตอน (Multi-step reasoning) และการจัดการประสานงานของ Agent (Agent orchestration) มาใช้จริง บทบาทของ AI จึงกำลังเปลี่ยนจากการเป็นเพียง "ผู้ช่วย" ไปสู่การเป็น "ผู้ปฏิบัติงานแทน"

การเปลี่ยนแปลงของโครงสร้างต้นทุน

SaaS แบบดั้งเดิมมักใช้รูปแบบการเรียกเก็บเงินรายเดือนตามจำนวนที่นั่ง (Seat) เป็นหลัก อย่างไรก็ตาม เมื่อ AI Agent เข้ามารับหน้าที่บางส่วนในกระบวนการทำงาน สมมติฐานที่ว่า "ต้องเป็นไลเซนส์สำหรับคนใช้งาน" ก็เริ่มสั่นคลอน ในหลายกรณี รูปแบบการเรียกเก็บเงินที่อิงตามผลลัพธ์หรือปริมาณงาน (Outcome-based/Usage-based pricing) กลายเป็นทางเลือกที่สมเหตุสมผลกว่าสำหรับทั้งบริษัทผู้ใช้งานและผู้ให้บริการ

ความสัมพันธ์เชิงแข่งขันกับ BPO

AI Agent กำลังก้าวเข้ามาเป็นทางเลือกใหม่ในพื้นที่ของ BPO (Business Process Outsourcing) และการพัฒนาซอฟต์แวร์แบบ Offshore ซึ่งเคยถูกใช้เป็นเครื่องมือในการลดต้นทุนมาก่อน โดยเฉพาะในงานประจำอย่างการคีย์ข้อมูล การจัดการเอกสาร และการตอบรับเบื้องต้น มีรายงานว่าบริการรูปแบบ SaS เริ่มมีความสามารถในการแข่งขันที่สูงขึ้น

สรุปเหตุผลที่ทำให้ได้รับความสนใจเพิ่มขึ้น:

• ความสามารถในการปฏิบัติงานด้วยตนเองของ AI Agent กำลังเข้าสู่ระดับที่ใช้งานได้จริง
• รูปแบบการเรียกเก็บเงินตามผลลัพธ์ช่วยให้บริษัทที่นำไปใช้เห็นภาพ ROI (Return on Investment) ได้ชัดเจนขึ้น
• ความต้องการ "การทดแทนแรงงานคน" กำลังขยายตัวท่ามกลางปัญหาการขาดแคลนแรงงาน
• ผู้ให้บริการ SaaS เดิมกำลังเร่งนำฟังก์ชัน Agent เข้าไปรวมอยู่ในระบบของตน

ในหัวข้อถัดไป เราจะเจาะลึกถึงการเปลี่ยนแปลงที่เป็นรูปธรรม 3 ประการที่ช่วยเร่งการเปลี่ยนผ่านนี้

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

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

ความก้าวหน้าทางเทคโนโลยีหลักที่สนับสนุนการเพิ่มขีดความสามารถ

• การขยาย Context Window: ปริมาณข้อมูลที่ LLM สามารถเก็บและประมวลผลได้ในคราวเดียวเพิ่มขึ้นอย่างมาก ทำให้สามารถดำเนินกระบวนการทำงานที่ยาวนานได้อย่างต่อเนื่องโดยไม่สะดุด
• ความแม่นยำในการใช้เหตุผลแบบหลายขั้นตอน (Multi-step reasoning): การเกิดขึ้นของโมเดลการใช้เหตุผล (Reasoning models) ทำให้สามารถคิดวิเคราะห์ทีละขั้นตอนและนำไปสู่ผลลัพธ์ที่ถูกต้องแม่นยำ แม้ในงานที่ต้องอาศัยการตัดสินใจที่ซับซ้อน
• การเรียกใช้เครื่องมือและการเชื่อมต่อภายนอก: ด้วยมาตรฐานอย่าง MCP (Model Context Protocol) ทำให้เกิดสภาพแวดล้อมที่ AI Agent สามารถใช้งาน ERP หรือ API ภายนอกได้อย่างไร้รอยต่อ
• การประสานงานของ Agent (Agent orchestration): การแพร่หลายของระบบ Multi-agent ทำให้ Agent ผู้เชี่ยวชาญหลายตัวสามารถแบ่งงานและร่วมมือกันจัดการงานขนาดใหญ่ได้

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

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

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

ในยุค SaS (Software as Service ที่ขับเคลื่อนด้วย AI) โครงสร้างการเรียกเก็บเงินนี้จะเปลี่ยนไปจากเดิมอย่างสิ้นเชิง โดยสามารถแบ่งรูปแบบการเรียกเก็บเงินหลักออกเป็น 3 ประเภท ดังนี้:

• การเรียกเก็บเงินตามการใช้งาน (Usage-based): เรียกเก็บเงินตามจำนวนโทเค็นที่ประมวลผล, จำนวนครั้งที่เรียกใช้ API หรือจำนวนงานที่ดำเนินการ
• การเรียกเก็บเงินตามผลลัพธ์ (Outcome-based): เรียกเก็บเงินตามผลลัพธ์ทางธุรกิจ เช่น จำนวนตั๋ว (Ticket) ที่แก้ไขได้สำเร็จ หรือจำนวนดีลที่ปิดการขายได้
• รูปแบบไฮบริด (Hybrid): รูปแบบที่ผสมผสานระหว่างค่าธรรมเนียมพื้นฐาน (การันตีขั้นต่ำ) บวกกับส่วนเพิ่มตามผลลัพธ์ที่ทำได้

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

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

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

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

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

หากมองย้อนกลับไปที่โครงสร้างต้นทุนในอดีต จะมีลักษณะดังนี้:

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

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

สิ่งที่ได้รับผลกระทบมากที่สุดคืองานประจำที่ต้องพึ่งพาแรงงานคนในรูปแบบ BPO (Business Process Outsourcing) โดยมีรายงานว่าในด้านการป้อนข้อมูล การประมวลผลใบแจ้งหนี้ และการรับเรื่องเบื้องต้นจากลูกค้า โครงสร้างต้นทุนได้เปลี่ยนไปจากการแทนที่ด้วย AI Agent แล้ว

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

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

การนำ Service as Software มาใช้ก่อให้เกิดประโยชน์ที่ชัดเจน เช่น การปรับปรุงโครงสร้างต้นทุนและการเพิ่มประสิทธิภาพการดำเนินงาน ในขณะเดียวกันก็จำเป็นต้องเตรียมพร้อมรับมือกับความเสี่ยงใหม่ๆ ด้วย เนื่องจากลักษณะเฉพาะของโมเดลการคิดค่าบริการตามผลลัพธ์ (Outcome-based pricing model) มักทำให้เกิดช่องว่างระหว่างความคาดหวังกับความเป็นจริง การออกแบบล่วงหน้าจึงเป็นปัจจัยชี้ขาดความสำเร็จ ในหัวข้อ H3 ถัดไป จะสรุปถึงประโยชน์ที่ได้รับและประเด็นที่ควรระวังในการนำไปใช้งานตามลำดับ

ประโยชน์ที่บริษัทซึ่งนำ SaS มาใช้งานจะสัมผัสได้จริง สามารถสรุปได้เป็น 3 ประเด็นหลัก ดังนี้

① ต้นทุนเชื่อมโยงกับ "ผลลัพธ์" ทำให้ลดค่าใช้จ่ายคงที่ที่ไม่จำเป็น

SaaS แบบเดิมมักมีค่าใช้จ่ายรายเดือนคงที่ตามจำนวนผู้ใช้งานหรือจำนวนฟังก์ชัน ซึ่งมักนำไปสู่การจ่ายเงินให้กับฟังก์ชันที่ไม่ได้ใช้งานจริง แต่สำหรับ SaS รูปแบบการคิดค่าบริการตามปริมาณการใช้งานหรือตามผลลัพธ์ที่ทำได้ (Usage-based/Outcome-based pricing) จะกลายเป็นกระแสหลัก ทำให้ต้นทุนแปรผันตามปริมาณงานที่เพิ่มขึ้นหรือลดลงได้ง่าย โดยมีการรายงานว่าในอุตสาหกรรมที่มีความแตกต่างของช่วงงานยุ่งและช่วงงานน้อยสูง จะสามารถปรับปรุงประสิทธิภาพด้านต้นทุนได้เป็นพิเศษ

② การเสริมกำลังคนและเพิ่มปริมาณงาน (Throughput)

เนื่องจาก AI Agent เป็นผู้รับผิดชอบการทำงานแบบอัตโนมัติ จึงสามารถสร้างระบบที่ไม่ได้รับผลกระทบจากปัญหาการขาดแคลนแรงงานหรือต้นทุนค่าแรงที่พุ่งสูงขึ้นได้ การมอบหมายงานซ้ำๆ เช่น การป้อนข้อมูล การตรวจสอบเอกสาร และการตอบคำถามเบื้องต้นให้กับ Agent จะช่วยให้สามารถจัดสรรบุคลากรไปโฟกัสกับงานตัดสินใจที่มีมูลค่าสูงกว่าได้ง่ายขึ้น และหากมีการออกแบบ HITL (Human-in-the-Loop) ที่เหมาะสม ก็จะสามารถเพิ่มปริมาณงาน (Throughput) ไปพร้อมกับการรักษาคุณภาพไว้ได้

③ วงจรการปรับปรุงงานรวดเร็วขึ้น

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

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

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

ความเสี่ยงหลักและมาตรการรับมือ

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

• การขาดความรับผิดชอบเนื่องจากกลายเป็นกล่องดำ (Black Box) เนื่องจาก AI Agent ดำเนินการโดยอัตโนมัติ ทำให้เหตุผลในการตัดสินใจมองเห็นได้ยาก ควรใช้เครื่องมือ AI Observability เพื่อสร้างระบบที่สามารถบันทึกและตรวจสอบประวัติการประมวลผลและการตัดสินใจได้

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

• ปัญหา Vendor Lock-in ที่รุนแรงขึ้น หากกระบวนการทำงานต้องพึ่งพา Agent ของผู้ให้บริการ SaS ต้นทุนในการเปลี่ยนผู้ให้บริการมักจะสูงกว่า SaaS แบบเดิม ควรตรวจสอบข้อกำหนด API และความต้องการในการส่งออกข้อมูล (Data export) ล่วงหน้า และออกแบบกลยุทธ์การถอนตัว (Exit strategy) ไว้

• การละเลยการออกแบบ HITL (Human-in-the-Loop) ในบางกรณีอาจมีความเร่งรีบที่จะทำระบบอัตโนมัติเต็มรูปแบบจนตัดกระบวนการตรวจสอบโดยมนุษย์ออกไป สำหรับการตัดสินใจที่มีความเสี่ยงสูง (เช่น การอนุมัติสัญญา, การตัดสินใจด้านสินเชื่อ) จำเป็นต้องรวม HITL เข้าไปเสมอ และต้องกำหนดขั้นตอนการส่งกลับ (Rollback) ในกรณีที่เกิดข้อผิดพลาดด้วย

ในช่วงเริ่มต้นของการนำมาใช้งาน การดำเนินการในระดับ PoC (Proof of Concept) เพื่อค้นหาขอบเขตที่ความเสี่ยงมักจะปรากฏให้เห็นก่อน ถือเป็นแนวทางที่สมเหตุสมผลที่สุด

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

การเลือกระหว่าง SaaS และ SaS ขึ้นอยู่กับ "ลักษณะของงาน" โดยสามารถตัดสินใจได้ง่ายขึ้นหากพิจารณาจากแกนหลักว่า ใครเป็นผู้ใช้งานเครื่องมือ หรือใครเป็นผู้สร้างผลลัพธ์ (มนุษย์หรือ AI Agent)

งานที่เหมาะกับ SaaS

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

งานที่เหมาะกับ SaS

• งานรูทีนที่เกิดขึ้นซ้ำๆ (เช่น การตรวจสอบใบแจ้งหนี้, การป้อนข้อมูล, การสร้างรายงาน)
• งานที่ต้องประมวลผลเอกสารจำนวนมากหรือข้อมูลที่ไม่มีโครงสร้าง (Unstructured Data)
• งานตรวจสอบหรือจัดหมวดหมู่ที่สามารถกำหนดเกณฑ์การตัดสินใจเป็นกฎหรือตัวเลขได้

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

งานรูทีนที่เคยจ้างบริษัทภายนอกทำผ่าน BPO (Business Process Outsourcing) มักเป็นตัวเลือกอันดับต้นๆ ในการเปลี่ยนผ่านสู่ SaS เนื่องจากโครงสร้างต้นทุนจะเปลี่ยนจาก "ค่าจ้างพนักงาน + ค่าบริหารจัดการ" เป็น "จำนวนผลลัพธ์ × ราคาต่อหน่วย" ซึ่งช่วยให้สามารถเปลี่ยนต้นทุนคงที่ให้เป็นต้นทุนผันแปรและสร้างความเสถียรของคุณภาพงานไปพร้อมกันได้

อย่างไรก็ตาม การแบ่งงานเป็นสองส่วนอาจไม่เพียงพอ การใช้ โครงสร้างแบบไฮบริด (Hybrid) ก็เป็นทางเลือกที่ใช้งานได้จริง โดยโมเดลแบบ On the Loop ที่ AI Agent ทำหน้าที่เตรียมงานเบื้องต้นและให้มนุษย์ตรวจสอบเฉพาะกรณีที่เป็นข้อยกเว้น จะช่วยให้สามารถใช้ประโยชน์จากข้อดีของทั้ง SaaS และ SaS ได้ สิ่งสำคัญคือการมองภาพรวมของกระบวนการทำงานทั้งหมด แล้วออกแบบว่าควรนำเครื่องมือประเภทใดมาใช้ในขั้นตอนไหน

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

ตรวจสอบระดับความเป็นมาตรฐานของงาน

• มีการจัดทำเอกสารขั้นตอนการทำงานและกำหนดเกณฑ์การตัดสินใจที่ชัดเจนหรือไม่
• สัดส่วนของงานที่ต้องจัดการเป็นกรณีพิเศษ (Exception) อยู่ที่ต่ำกว่า 20% ของทั้งหมดหรือไม่
• สามารถกำหนดตัวชี้วัดผลงาน (KPI) เป็นตัวเลขได้หรือไม่

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

ประเมินโครงสร้างต้นทุน

เปรียบเทียบผลรวมของค่าใช้จ่ายด้านบุคลากรและค่าลิขสิทธิ์ซอฟต์แวร์ในปัจจุบัน กับต้นทุนแบบจ่ายตามผลงาน (Outcome-based pricing) ของ SaS โมเดลการจ่ายตามผลงานมักจะมีความได้เปรียบด้านต้นทุนในงานที่มีความผันผวนสูง ในขณะที่งานที่มีปริมาณการประมวลผลคงที่ การใช้ SaaS แบบค่าใช้จ่ายคงที่อาจคุ้มค่ากว่า ทั้งนี้ โปรดตรวจสอบราคาต่อหน่วยล่าสุดจากหน้าเว็บไซต์ของผู้ให้บริการแต่ละราย ณ เวลาที่เขียนบทความนี้

ประเมินความพร้อมด้านข้อมูลและความปลอดภัย

• ข้อมูลที่จำเป็นสำหรับการเรียนรู้และการอนุมาน (Inference) ได้รับการจัดเตรียมและทำความสะอาด (Cleansing) แล้วหรือไม่
• มีการกำหนดนโยบายการจัดการข้อมูลส่วนบุคคลและข้อมูลที่เป็นความลับแล้วหรือไม่
• สามารถจัดตั้งระบบการตรวจสอบโดยมนุษย์ (HITL: Human-in-the-Loop) ได้หรือไม่

โดยเฉพาะในภาคการเงิน การแพทย์ และกฎหมาย การมีขั้นตอนให้มนุษย์ตรวจสอบการตัดสินใจของ AI Agent อาจเป็นข้อบังคับทางกฎหมาย

ประเมินขนาดของ PoC (Proof of Concept)

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

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

การเริ่มต้นสู่ความสำเร็จในการนำ SaS มาใช้ จุดเริ่มต้นคือการทำความเข้าใจสถานะปัจจุบันของธุรกิจตนเองอย่างถูกต้อง หากนำ AI Agent มาใช้โดยปราศจากการวางแผนที่ชัดเจน ย่อมยากที่จะคาดหวังความคุ้มค่าในการลงทุน (ROI)

3 สิ่งที่ควรตรวจสอบในการวิเคราะห์สถานะปัจจุบัน

• ความถี่ในการทำซ้ำของงาน: งานนั้นเกิดขึ้นบ่อยครั้งหรือไม่ เช่น รายเดือน รายสัปดาห์ หรือรายวัน
• ความชัดเจนของกฎเกณฑ์: เกณฑ์การตัดสินใจมีการจัดทำเป็นเอกสารและมีข้อยกเว้นน้อยหรือไม่
• สถานะความพร้อมของข้อมูล: มีข้อมูลที่มีโครงสร้าง (Structured Data) หรือบันทึกประวัติ (History Log) ที่ AI สามารถอ้างอิงได้หรือไม่

งานที่ตรงตามเงื่อนไขทั้ง 3 ประการนี้ มักจะได้รับประโยชน์จากการทำระบบอัตโนมัติผ่าน SaS ได้ง่ายกว่า

เกณฑ์การคัดเลือกงานนำร่อง (Pilot Project)

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

• งานภายในองค์กร (ส่งผลกระทบต่อลูกค้าภายนอกน้อย)
• สามารถวัดจำนวนงานที่ประมวลผลได้ และวัดผลลัพธ์ได้ง่าย
• สามารถเชื่อมต่อ API กับเครื่องมือ SaaS ที่มีอยู่เดิมได้

ตัวอย่างเช่น การคัดแยกคำถามเบื้องต้นสำหรับงานสอบถามภายใน หรือการสร้างรายงานตามรูปแบบมาตรฐาน มักถูกยกให้เป็นงานที่เหมาะสมสำหรับการนำร่อง

การใช้ประโยชน์จาก Process Mining

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

หากพิจารณาถึงความจำเป็นของ HITL (Human-in-the-Loop) ในขั้นตอนการวิเคราะห์สถานะปัจจุบัน จะช่วยให้สามารถออกแบบขั้นตอนการเปลี่ยนผ่านในระยะถัดไปได้อย่างราบรื่น

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

แนวทางระยะการย้ายระบบ (Migration Phases)

• ระยะที่ 1 (ช่วงตรวจสอบ): ยกระดับงานนำร่องขึ้นสู่สภาพแวดล้อมจริง โดยใช้ AI Agent ควบคู่ไปกับ HITL (Human-in-the-Loop) และคงการดำเนินงานที่ให้มนุษย์ตรวจสอบผลลัพธ์ไว้
• ระยะที่ 2 (ช่วงขยายผล): ขยายผลไปยังกระบวนการทำงานที่เกี่ยวข้อง โดยต้องตรวจสอบให้แน่ใจว่า KPI ต่างๆ เช่น อัตราข้อผิดพลาดและความเร็วในการประมวลผลมีความเสถียรก่อนที่จะย้ายไปยังงานถัดไป
• ระยะที่ 3 (ช่วงปรับปรุงประสิทธิภาพ): เพิ่มสัดส่วนการทำงานแบบอัตโนมัติและเปลี่ยนบทบาทของมนุษย์ไปสู่การกำกับดูแล (On the Loop) พร้อมทั้งปรับปรุงกฎการจัดการข้อยกเว้นให้มีความซับซ้อนยิ่งขึ้น

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

ตัวชี้วัดหลักที่ควรวัดผล

• ต้นทุนการประมวลผล (Processing Cost): ต้นทุนต่อหน่วยเปลี่ยนแปลงไปอย่างไรเมื่อเทียบกับยุค SaaS
• ปริมาณงาน (Throughput): การเพิ่มขึ้นหรือลดลงของจำนวนงานที่ประมวลผลได้ต่อหน่วยเวลา
• อัตราข้อผิดพลาดและอัตราการส่งกลับ (Error Rate / Rejection Rate): การวัดคุณภาพผลลัพธ์ของ AI Agent เชิงปริมาณ
• AI ROI (ผลตอบแทนจากการลงทุนใน AI): การคำนวณว่าผลลัพธ์ในการลดภาระงานคุ้มค่ากับต้นทุนที่ใช้ไปเพียงใด

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

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

Q1. SaS และ SaaS มีความแตกต่างกันอย่างไรมากที่สุด?

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

Q2. เครื่องมือ SaaS ที่มีอยู่เดิมทั้งหมดจะถูกแทนที่ด้วย SaS หรือไม่?

ไม่จำเป็นต้องถูกแทนที่ทั้งหมด งานที่มีกฎเกณฑ์ชัดเจนและมีการทำซ้ำสูง (เช่น การป้อนข้อมูล, การสร้างรายงาน, การตอบคำถาม) มักจะมีความเหมาะสมกับ SaS สูง ในขณะที่งานที่ต้องใช้การตัดสินใจขั้นสูงหรือความคิดสร้างสรรค์ของมนุษย์ หรือในส่วนงานที่ต้องการการจัดการด้านการปฏิบัติตามกฎระเบียบ (Compliance) อย่างเข้มงวด การใช้งานร่วมกับ SaaS ต่อไปในระยะนี้ถือเป็นทางเลือกที่สมเหตุสมผลกว่า

Q3. โมเดลการคิดค่าบริการตามผลลัพธ์ (Outcome-based pricing) สามารถนำมาใช้กับธุรกิจขนาดกลางและขนาดย่อม (SME) ได้หรือไม่?

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

Q4. การนำ SaS มาใช้จะทำให้ความเสี่ยงด้านความปลอดภัยเพิ่มขึ้นหรือไม่?

เนื่องจากขอบเขตที่ AI Agent เข้าถึงระบบภายในองค์กรจะกว้างขึ้น ความสำคัญของการจัดการสิทธิ์และการตรวจสอบบันทึกการใช้งาน (Log Audit) จึงเพิ่มขึ้นตามไปด้วย การนำแนวคิด Zero Trust Network Access (ZTNA) มาปรับใช้และการออกแบบโดยจำกัดสิทธิ์ที่มอบให้แก่ Agent ให้เหลือเพียงเท่าที่จำเป็นถือเป็นวิธีที่มีประสิทธิภาพ ก่อนการนำมาใช้งาน โปรดตรวจสอบนโยบายความปลอดภัยของผู้ให้บริการและเงื่อนไขการจัดการข้อมูลในสัญญาให้ถี่ถ้วนเสมอ

Service as Software (SaS) คือรูปแบบการให้บริการซอฟต์แวร์แบบใหม่ที่ AI Agent จะเข้ามาดำเนินการตามภารกิจต่างๆ อย่างอิสระ และคิดค่าบริการตามผลลัพธ์ที่เกิดขึ้นจริง

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

ในการพิจารณานำมาใช้งาน ขอให้เริ่มจาก 3 ประเด็นดังต่อไปนี้:

• เริ่มต้นทำ PoC (Proof of Concept) ในสเกลเล็กๆ กับงานที่มีความซ้ำซ้อนสูง
• กำหนดตัวชี้วัดผลสำเร็จ (KPI) ล่วงหน้า และเตรียมระบบสำหรับการวัดผล
• ออกแบบระบบ AI Governance และ HITL (Human-in-the-Loop) ควบคู่กันไป

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