คลังคำศัพท์ · 318 คำศัพท์
คลังคำศัพท์การพัฒนาซอฟต์แวร์
คำศัพท์จากบทความของเรา อธิบายสำหรับผู้บริหารและทีมธุรกิจ ไม่ใช่วิศวกร — อ่านความหมาย ดูตัวอย่าง แล้วใช้คำถามด้านขวาคุยกับทีมพัฒนา
| คำศัพท์ | คืออะไร | ตัวอย่างที่เข้าใจง่าย | คำถามที่ผู้บริหารควรถามทีมพัฒนา |
|---|---|---|---|
| A/B Test | เปรียบเทียบสองวิธีกับกลุ่มใกล้เคียง | ทีมหนึ่งใช้ Workflow ใหม่ อีกทีมใช้เดิม | สองกลุ่มเทียบกันได้และไม่กระทบลูกค้าอย่างไร? |
| Abstraction Layer | ชั้นกลางที่คั่นระหว่างระบบของเรากับบริการภายนอก เพื่อให้เปลี่ยนผู้ให้บริการได้ง่าย | เปลี่ยนผู้ให้บริการโมเดลโดยแก้ที่ชั้นเดียว | ถ้าเปลี่ยนผู้ให้บริการ ต้องแก้กี่จุดในระบบ? |
| Acceptance Criteria | เงื่อนไขที่ใช้รับรองว่างานเสร็จ เกณฑ์ต้องสังเกตหรือทดสอบได้ และตกลงก่อนส่งมอบ เพื่อป้องกันคำว่า ‘ใช้งานได้ดี’ ที่แต่ละฝ่ายตีความไม่เหมือนกัน | ระบบส่งออกไฟล์ได้ตามรูปแบบ | เกณฑ์นี้ทดสอบได้หรือไม่? |
| Access Control | ควบคุมว่าใครเห็นข้อมูลใด | ทีมหนึ่งเห็นเฉพาะคู่มือตาม Site | สิทธิ์สืบทอดและถูกยกเลิกเมื่อคนย้ายงานอย่างไร? |
| Access Review | การทบทวนเป็นรอบว่าใครยังควรมีสิทธิ์เข้าถึงอะไร | ตรวจทุกไตรมาสว่าบัญชีที่ไม่ใช้แล้วถูกปิดหรือยัง | เราทบทวนสิทธิ์บ่อยแค่ไหน? |
| Accessibility | การออกแบบให้คนหลากหลายใช้ได้ ต้องออกแบบตั้งแต่สี ตัวอักษร คีย์บอร์ด โปรแกรมอ่านจอ ไปถึงภาษาที่เข้าใจง่าย และทดสอบกับผู้ใช้จริง ไม่ใช่เพิ่มภายหลัง | รองรับ Screen Reader และตัวอักษรใหญ่ | AI เปลี่ยน UI แล้วมาตรฐานยังผ่านหรือไม่? |
| Action | การกระทำที่ระบบลงมือทำจริง ต่างจากการแค่ตอบข้อความ | ระบบสร้างใบเสนอราคาและส่งอีเมลให้ลูกค้า | การกระทำใดย้อนกลับได้ และการกระทำใดย้อนไม่ได้? |
| Adaptive UI | หน้าจอที่เปลี่ยนตามบริบทโดยมีกฎ ส่วนที่ปรับควรถูกจำกัดและมี Default เพื่อให้ผู้ใช้ยังคาดเดาตำแหน่งกับพฤติกรรมหลักของผลิตภัณฑ์ได้ | มือใหม่เห็นคำแนะนำเพิ่ม | ส่วนใดปรับได้และส่วนใดต้องคงที่? |
| Adoption Analytics | ข้อมูลว่าคนใช้ระบบอย่างไร | ดู Workflow ที่ใช้ซ้ำ ไม่ใช่แค่ Login | เราวัดการใช้งานหรือคุณค่าที่เกิดจากการใช้งาน? |
| Agent | ซอฟต์แวร์ AI ที่รับเป้าหมายแล้วทำงานหลายขั้นจนจบ ไม่ใช่แค่ตอบคำถามทีละครั้ง | Agent อ่านคำขอ ตรวจข้อมูล แล้วสร้างเอกสารให้คนอนุมัติ | Agent ตัวนี้ทำอะไรได้เอง และหยุดตรงไหน? |
| Agent as Tool | ให้ Agent ช่วยงานย่อยโดย Manager ยังควบคุม แนวคิดนี้ห่อ Agent เฉพาะทางให้ถูกเรียกเหมือนเครื่องมือที่มี Input และ Output ชัด ช่วยลดบทสนทนาระหว่าง Agent ที่ควบคุมไม่ได้ | Research Agent ส่งผลให้ Manager | ผลย่อยตรวจอย่างไรก่อนรวม? |
| Agentic Product | ผลิตภัณฑ์ที่ AI วางขั้นและใช้ Tool ภายใต้ขอบเขต เป็นผลิตภัณฑ์ที่ AI วางหรือทำหลายขั้นภายใต้เครื่องมือ กฎ และการติดตาม ไม่ใช่เพียงหน้าจอแชตที่สร้างข้อความ | Agent เตรียมนัดและขอคนยืนยัน | Outcome และขอบเขตอยู่ที่ใคร? |
| AI Agent | ซอฟต์แวร์ AI ที่รับเป้าหมาย ใช้ข้อมูลหรือเครื่องมือ และทำงานหลายขั้น | Agent อ่านชิ้นงาน เทียบ Checklist และส่งให้ผู้ตรวจ | Agent ใช้ข้อมูลและเครื่องมือใด มีขอบเขตหยุดตรงไหน? |
| AI Literacy | ความเข้าใจพื้นฐานเรื่อง AI ที่พนักงานทุกคนควรมี | รู้ว่าข้อมูลใดห้ามใส่ และต้องตรวจอะไรก่อนใช้ผล | ทุกคนรู้ข้อห้ามพื้นฐานเรื่องข้อมูลหรือยัง? |
| Alert | การแจ้งเตือนเมื่อมีบางอย่างผิดปกติ ควรมีคนรับผิดชอบต่อทุกครั้ง | เตือนเมื่อค่าใช้จ่ายเกินงบที่ตั้งไว้ | ถ้าเตือนแล้วไม่มีใครทำอะไร เราจะรู้ได้อย่างไร? |
| Alert Budget | การจำกัดจำนวนแจ้งเตือนต่อวัน เพื่อให้ทุกครั้งมีความหมาย | ไม่เกิน 5 การแจ้งเตือนต่อกะ | ถ้าเตือนเกินงบ ระบบตัดเรื่องใดออกก่อน? |
| Analytics | เครื่องมือเก็บและอ่านพฤติกรรมผู้ใช้บนเว็บหรือแอป เพื่อรู้ว่าคนมาจากไหน ทำอะไร และหลุดหายตรงจุดใด | เห็นว่าคนเข้าหน้าสินค้าแล้วออกก่อนกดสั่งซื้อ 70% | เราวัดอะไรอยู่บ้าง และตัวเลขไหนที่ใช้ตัดสินใจจริง? |
| Anomaly Detection | การหาค่าที่ต่างจากรูปแบบปกติ | พบแรงสั่นผิดจากช่วง Load เดียวกัน | ความผิดปกติแบบใดนำไปสู่การกระทำได้จริง? |
| API | ช่องทางมาตรฐานให้ระบบแลกข้อมูลกัน | ดึงข้อมูลลูกค้าจาก CRM มาใส่ Brief | มีระบบใดให้เชื่อมและมีข้อจำกัดด้านสิทธิ์หรือปริมาณข้อมูลหรือไม่? |
| App Intent | ความสามารถของแอปที่ระบบเรียกด้วยภาษาธรรมชาติ เป็นช่องทางให้แอปหรือระบบภายนอกเรียกงานที่กำหนดไว้ จึงต้องระบุ Input, Permission และผลลัพธ์ที่คาดหวังให้ชัด | สั่งเปิดงานตรวจรายการถัดไป | Action ใดควรเปิดให้เรียก? |
| Approval | การอนุมัติจากผู้มีอำนาจก่อนดำเนินการต่อ | ส่วนลดเกินเพดานต้องรอผู้จัดการอนุมัติ | เรื่องใดต้องอนุมัติ และถ้าไม่มีคนอนุมัติจะค้างนานแค่ไหน? |
| Approval Flow | เส้นทางขออนุมัติก่อนทำรายการ Flow ต้องระบุผู้อนุมัติตามมูลค่า ความเสี่ยง หรือข้อยกเว้น พร้อมเก็บเหตุผลและเวลาที่ตัดสินใจไว้ตรวจย้อนหลัง | หัวหน้ากดยืนยันตะกร้าบริษัท | วงเงินใดต้องให้ใครอนุมัติ? |
| Approval Workflow | เส้นทางการอนุมัติที่กำหนดไว้ว่าใครต้องดูอะไรและเมื่อใด | งานความเสี่ยงต่ำผ่านหัวหน้าคนเดียว | เราแยกเส้นทางตามความเสี่ยงหรือใช้เส้นทางเดียวทั้งหมด? |
| Asset Library | คลังชิ้นงานที่ค้นหาและนำกลับมาใช้ซ้ำได้ | ภาพและข้อความที่อนุมัติแล้วถูกเก็บไว้ให้ทีมอื่นใช้ต่อ | ชิ้นงานเก่าค้นเจอไหม และรู้ได้อย่างไรว่ายังใช้ได้อยู่? |
| Audit Log | ประวัติว่าใครหรือระบบทำอะไรเมื่อใด | ย้อนดูว่า Proposal ใช้ข้อมูลเวอร์ชันไหน | ต้องย้อนดูเหตุการณ์ย้อนหลังนานเท่าไร? |
| Authentication | การยืนยันว่าผู้ใช้เป็นใครก่อนให้เข้าระบบ เช่น รหัสผ่าน รหัสทางข้อความ หรือการสแกนใบหน้า | คนไข้กรอกเบอร์โทรกับรหัสที่ได้รับทางข้อความเพื่อเปิดใบนัด | ผู้ใช้กลุ่มไหนต้องยืนยันตัวสองชั้น และถ้าลืมรหัสจะกู้บัญชีอย่างไร? |
| Authorization | กฎที่กำหนดว่าผู้ใช้แต่ละคนดูหรือแก้ข้อมูลใดได้ หลังยืนยันตัวแล้ว | คนไข้เปิดได้เฉพาะใบนัดของตัวเอง พนักงานเปิดได้เฉพาะสาขาที่สังกัด | กฎสิทธิ์ถูกตรวจที่เซิร์ฟเวอร์ทุกครั้งที่ดึงข้อมูลหรือเปล่า และใครเป็นคนทดสอบ? |
| Automated Test | ชุดคำสั่งที่ตรวจว่าฟังก์ชันสำคัญยังทำงานถูก รันเองได้ทุกครั้งที่แก้โค้ด | ชุดทดสอบจำลองคนสองคนจองของชิ้นเดียวกันพร้อมกัน แล้วตรวจว่ามีคนเดียวที่จองได้ | กรณีที่เคยพังในระบบจริงถูกเพิ่มเข้าชุดทดสอบแล้วหรือยัง? |
| Automation | ให้ระบบทำขั้นตอนซ้ำตามเงื่อนไข | สร้าง Task หลังประชุมโดยไม่คีย์ซ้ำ | หากระบบทำผิด จะหยุด ย้อนกลับ และแจ้งใคร? |
| Automation Champion | คนในทีมหน้างานที่ผลักดันและดูแลงานอัตโนมัติของทีมตัวเอง | พนักงานที่รู้ว่างานใดควร Automate ต่อไป | ทีมมีคนที่เป็นเจ้าของงานอัตโนมัติหรือยัง? |
| Autonomy | ระดับอิสระที่ระบบลงมือได้ ควรกำหนดแยกตาม Action เพราะระบบเดียวอาจตอบอัตโนมัติได้ แต่ยังต้องขอคนอนุมัติก่อนเปลี่ยนข้อมูลหรือทำรายการ | ทำเคสมาตรฐานโดยไม่รอทุกขั้น | เพิ่มอิสระเมื่อหลักฐานใดผ่าน? |
| Backlog | รายการงานหรือไอเดียที่รอทำ พร้อมลำดับความสำคัญ | ไอเดียที่ผ่านการคัดกรองรอเข้ารอบทดลองถัดไป | ใครจัดลำดับ Backlog และใช้เกณฑ์อะไร? |
| Backup | สำเนาข้อมูลที่เก็บแยกจากระบบหลัก ใช้กู้เมื่อข้อมูลจริงเสียหายหรือหาย | ฐานข้อมูลออเดอร์ถูกสำเนาไปเก็บอีกที่หนึ่งทุกคืน และเก็บย้อนหลังสามสิบวัน | ไฟล์สำรองเก็บที่ไหน ใครเข้าถึงได้ และลองกู้ครั้งล่าสุดเมื่อไร? |
| Barcode | รหัสแท่งบนสินค้าที่สแกนแทนการพิมพ์มือ ลดการกรอกเลขผิดและทำให้ตรวจนับเร็วขึ้น | พนักงานคลังสแกนรับของแทนพิมพ์รหัส 13 หลัก | ของที่ไม่มีบาร์โค้ดเดิมจะจัดการอย่างไร? |
| Baseline | ค่าก่อนเริ่มเปลี่ยนระบบ | เวลาปิดเคสเฉลี่ยก่อนใช้ AI | ช่วงข้อมูลก่อนทดลองเป็นตัวแทนงานปกติหรือไม่? |
| Bottleneck | จุดที่ทำให้ทั้งกระบวนการช้า เพราะรับงานได้จำกัด | ทุกงานต้องรอคนเดียวอนุมัติ | จุดคอขวดตอนนี้อยู่ที่ใด และวัดจากอะไร? |
| Brief | เอกสารตั้งต้นที่บอกโจทย์ กลุ่มเป้าหมาย และสิ่งที่ต้องได้ | เอกสารหนึ่งหน้าที่ทุกฝ่ายใช้อ้างอิงตอนเปิดตัวสินค้า | ทุกทีมทำงานจาก Brief ฉบับเดียวกันหรือไม่? |
| Business Brief | เอกสารสั้นที่ระบุปัญหา ผู้ใช้ ขอบเขต และเกณฑ์วัดผลของโครงการ | เอกสารหนึ่งหน้าที่ส่งให้ผู้พัฒนาทุกรายใช้เสนอราคา | ทุกเจ้าเสนอจากโจทย์เดียวกันหรือไม่? |
| Business Case | เหตุผลทางธุรกิจของโครงการ พร้อมต้นทุน ผลที่คาด และความเสี่ยง | เอกสารที่ใช้ตัดสินว่าจะอนุมัติงบหรือไม่ | สมมติฐานหลักของ Business Case นี้คืออะไร? |
| Business Rule | เงื่อนไขทางธุรกิจที่เขียนไว้ให้ระบบใช้ตัดสิน แยกจากโค้ด | ส่วนลดเกิน 15 เปอร์เซ็นต์ต้องให้ผู้จัดการอนุมัติ | ถ้ากติกาเปลี่ยน ใครแก้ได้และใช้เวลานานแค่ไหน? |
| Capacity | ปริมาณงานสูงสุดที่ทีมหรือระบบรับได้ในช่วงเวลาหนึ่ง | ทีมรับงานได้ 200 รายการต่อสัปดาห์ | ถ้างานเพิ่ม 30 เปอร์เซ็นต์ เราต้องเพิ่มอะไร? |
| Capstone | โครงการจริงที่ใช้พิสูจน์ทักษะ | ลดเวลาทำรายงานพร้อมคุณภาพผ่าน | ผลงานใดพิสูจน์ว่าทักษะนำไปใช้ได้จริง? |
| Capture Value | การเปลี่ยนเวลาหรือต้นทุนที่ประหยัดได้ให้กลายเป็นผลธุรกิจจริง | เอาเวลาที่ประหยัดไปรับงานเพิ่ม ไม่ใช่ปล่อยหายไป | ชั่วโมงที่ประหยัดได้ถูกใช้ทำอะไรต่อ? |
| Career Path | เส้นทางเติบโตของบทบาท ทำให้การเรียนรู้ต่อยอดเป็นตำแหน่งจริง | ผู้ที่ผ่าน Capstone ได้เข้าโครงการข้ามฝ่าย | ทักษะใหม่นำไปสู่ตำแหน่งใด และใครอนุมัติ? |
| Change Management | การเตรียมคนและกระบวนการให้พร้อมรับระบบใหม่ | อบรมและปรับ SOP ก่อนเปิดใช้จริง | ใครรับผิดชอบให้คนใช้จริง ไม่ใช่แค่ระบบเสร็จ? |
| Chatbot | ระบบที่คุยกับลูกค้าแทนคนในคำถามที่เกิดซ้ำ และส่งต่อให้พนักงานเมื่อเกินขอบเขตที่ตั้งไว้ | ตอบราคาและสต็อกทันทีตอนตี 2 แล้วส่งต่อแอดมินตอนลูกค้าจะสั่ง | กรณีไหนที่บอทต้องส่งต่อคนทันที? |
| CI/CD | สายพานอัตโนมัติที่ทดสอบและนำโค้ดขึ้นระบบด้วยขั้นตอนเดิมทุกครั้ง แทนการทำด้วยมือ | ทุกครั้งที่แก้โค้ด ระบบรันชุดทดสอบเอง ถ้าผ่านจึงส่งขึ้นเครื่องทดสอบ | จากแก้โค้ดเสร็จถึงขึ้นระบบจริงใช้เวลาเท่าไร และมีขั้นไหนที่ยังทำด้วยมือ? |
| Citation | การระบุแหล่งที่มาของคำตอบ | แสดงชื่อคู่มือ Version และหน้า | ผู้ใช้เปิดดูต้นฉบับและ Version ได้หรือไม่? |
| CMMS | ระบบจัดการงานซ่อมบำรุง | สร้าง Work Order จาก Alert | Alert จะกลายเป็น Work Order โดยไม่สร้างงานซ้ำอย่างไร? |
| CMS | ระบบหลังบ้านที่ให้ทีมแก้เนื้อหา รูป และราคาบนเว็บได้เอง โดยไม่ต้องเรียกนักพัฒนา | ทีมการตลาดขึ้นโปรโมชั่นใหม่เองได้ในสิบนาที | อะไรที่ทีมแก้เองได้ และอะไรยังต้องให้นักพัฒนาทำ? |
| Code Review | การให้วิศวกรอีกคนอ่านโค้ดก่อนรวมเข้าระบบ เพื่อจับข้อผิดพลาดและรักษามาตรฐานเดียวกัน | โค้ดคิดเงินที่ AI เขียนถูกวิศวกรอีกคนอ่านและถามถึงกรณีส่วนลดซ้อนก่อนขึ้นระบบ | โค้ดส่วนที่แตะเงินและข้อมูลลูกค้าผ่านการรีวิวโดยใคร ทุกครั้งหรือไม่? |
| Computer Vision | AI ที่วิเคราะห์ภาพหรือวิดีโอ | ตรวจหารอยบนชิ้นงาน | สภาพแสง มุม และความเร็วจริงถูกทดสอบหรือยัง? |
| Confidence Score | ระดับความมั่นใจของโมเดล | คะแนนต่ำถูกส่งให้ QC ตรวจ | คะแนนระดับใดส่งให้คนตรวจและเพราะอะไร? |
| Consent | ความยินยอมของผู้ใช้ การยินยอมต้องระบุวัตถุประสงค์ ข้อมูลที่ใช้ และวิธีถอน ไม่ใช่กล่องยอมรับกว้าง ๆ ก่อนเข้าใช้งาน | อนุญาตใช้ภาพเพื่อตรวจเคส | ผู้ใช้ถอนความยินยอมอย่างไร? |
| Context | ข้อมูลแวดล้อมที่ระบบต้องรู้จึงจะตอบได้ถูก | รู้ว่าลูกค้ารายนี้ซื้ออะไรไปแล้วบ้าง | ระบบรู้บริบทมากพอจะตอบถูกหรือยัง? |
| Control Plane | ระบบกลางที่รู้ว่ามีระบบอัตโนมัติใดอยู่ ใครดูแล ใช้สิทธิ์และงบเท่าไร | ทะเบียน Agent พร้อมสิทธิ์ ต้นทุน และปุ่มหยุด | ตอนนี้เรามีที่เดียวที่ตอบได้ไหมว่ามีอะไรทำงานอยู่บ้าง? |
| Conversion Event | เหตุการณ์ที่ถือว่าเกิดผลทางธุรกิจ ควรกำหนด Event ที่สะท้อนผลลัพธ์จริง เช่น นัดสำเร็จหรือส่งข้อมูลครบ แทนการนับเพียงการเปิดแชตและการคลิก | นัดหมายสำเร็จหรือส่งเอกสารครบ | เราวัดการคุยหรือผลสำเร็จจริง? |
| Conversion Rate | สัดส่วนผู้เข้าชมที่กลายเป็นลูกค้าหรือทำสิ่งที่ตั้งเป้าไว้ | ผู้ที่กดจากคำแนะนำแล้วซื้อจริงกี่เปอร์เซ็นต์ | เราวัดจากจุดใดถึงจุดใด และตัดผู้ใช้ซ้ำอย่างไร? |
| Cost Control | กลไกจำกัดและติดตามค่าใช้จ่ายของระบบ AI | ตั้งงบต่อเดือนต่อ Agent และแจ้งเตือนเมื่อใกล้ชน | ถ้าค่าใช้จ่ายพุ่งผิดปกติ ใครรู้และหยุดได้เร็วแค่ไหน? |
| Cost per Transaction | ต้นทุนเฉลี่ยต่อการทำงานหนึ่งรายการ | ต้นทุนต่อการออกใบแจ้งหนี้หนึ่งใบ | ตัวเลขนี้รวมต้นทุนอะไรบ้างและไม่รวมอะไร? |
| CPQ | ระบบกำหนดสินค้า ราคา และใบเสนอราคา CPQ ทำให้ตัวเลือก ราคา และข้อยกเว้นอยู่ภายใต้กฎเดียวกัน จึงช่วยลดข้อเสนอที่ขายได้แต่ส่งมอบไม่ได้ | เลือก Package แล้วคำนวณตามกฎ | กฎราคามาจากแหล่งใด? |
| CRM | ระบบเก็บข้อมูลลูกค้าและประวัติการติดต่อไว้ที่เดียว ย่อจาก Customer Relationship Management | ฝ่ายขายเปิดดูได้ว่าลูกค้ารายนี้เคยคุยอะไรไว้บ้าง | ข้อมูลลูกค้าฉบับจริงอยู่ใน CRM หรือยังอยู่ในไฟล์ของแต่ละคน? |
| CRM Integration | เชื่อมข้อมูลกับระบบลูกค้าสัมพันธ์ การเชื่อมที่ดีควรกำหนดทิศทางข้อมูล เจ้าของ Record และวิธีจัดการข้อมูลชนกัน ไม่ใช่เพียงส่งข้อมูลได้หนึ่งครั้ง | บันทึกข้อเสนอและ Next Step อัตโนมัติ | ข้อมูลใดห้ามเขียนทับ? |
| Cross-functional Team | ทีมที่รวมคนจากหลายหน้าที่มาทำงานเป้าหมายเดียวกัน | ทีมเปิดตัวมีคนจากผลิตภัณฑ์ การตลาด และฝ่ายขายอยู่ด้วยกัน | ใครเป็นเจ้าของผลลัพธ์รวมของทีมนี้? |
| Customer Journey | เส้นทางทั้งหมดที่ลูกค้าเดินผ่าน ตั้งแต่รู้จักจนซื้อและใช้บริการ | ตั้งแต่เห็นโฆษณา ถามราคา ซื้อ และแจ้งปัญหา | ลูกค้าหลุดออกจากเส้นทางนี้มากที่สุดตรงไหน? |
| Cutover | ช่วงเวลาที่สลับจากระบบเดิมไประบบใหม่จริง | คืนวันเสาร์หยุดรับออเดอร์สองชั่วโมง ย้ายยอดค้าง แล้วเปิดระบบใหม่เช้าวันอาทิตย์ | ถ้าคืนตัดระบบมีปัญหา เราย้อนกลับได้ถึงกี่โมง และใครเป็นคนสั่ง? |
| Cycle Time | เวลารวมตั้งแต่งานเข้าจนถึงส่งมอบ รวมเวลารอ ไม่ใช่เฉพาะเวลาที่ลงมือทำ | ใบเสนอราคาใช้เวลาจริง 40 นาที แต่ Cycle Time คือ 2 วัน | เราวัด Cycle Time จากระบบอัตโนมัติหรือให้คนกรอกเอง? |
| Dashboard | หน้าจอรวมข้อมูลเพื่อช่วยตัดสินใจ | หัวหน้าเห็นงานเสี่ยง SLA ในหน้าเดียว | ผู้ใช้ต้องตัดสินใจอะไรหลังเห็นหน้าจอนี้? |
| Data | ข้อมูลที่ระบบใช้ทำงาน ทั้งข้อมูลลูกค้า ราคา สต็อก และประวัติการทำงาน | ราคาสินค้าและสถานะสต็อกที่ระบบดึงมาตอบลูกค้า | ข้อมูลที่ระบบใช้มาจากที่ไหน และใครดูแลให้ถูกต้อง? |
| Data Access | สิทธิ์ว่าระบบหรือคนเข้าถึงข้อมูลชุดใดได้บ้าง | Agent อ่านราคาได้แต่ดูข้อมูลพนักงานไม่ได้ | ระบบนี้เข้าถึงข้อมูลใด และทบทวนสิทธิ์เมื่อใด? |
| Data Classification | การแบ่งข้อมูลเป็นชั้นตามความอ่อนไหว เพื่อกำหนดว่าแต่ละชั้นเก็บ ส่ง และใช้อย่างไรได้บ้าง | ตารางราคาต้นทุนถูกจัดเป็นชั้นลับ จึงใช้ได้กับ AI ภายในเท่านั้น | เอกสารชนิดไหนที่ยังไม่มีชั้น และใครเป็นคนตัดสินเมื่อไม่ชัดเจน? |
| Data Freshness | ความสดของข้อมูล ว่าใหม่พอจะใช้ตัดสินใจหรือไม่ | ตัวเลขบนหน้าจออัปเดตล่าสุดเมื่อ 10 นาทีก่อน | ข้อมูลเก่าที่สุดที่ยอมรับได้คือกี่ชั่วโมง? |
| Data Mapping | ตารางที่บอกว่าข้อมูลช่องไหนของระบบหนึ่งตรงกับช่องไหนของอีกระบบ | รหัสสินค้าของฝ่ายขายจับคู่กับรหัสสินค้าของคลังทีละรายการ | ใครเป็นเจ้าของตารางนี้ และเมื่อมีสินค้าใหม่ใครเป็นคนเพิ่ม? |
| Data Migration | การย้ายข้อมูลจากระบบเดิมเข้าระบบใหม่ รวมการทำความสะอาดและการตรวจหลังย้าย | ย้ายรายชื่อลูกค้าแปดพันรายเข้าระบบใหม่ หลังรวมรายที่ซ้ำกันแล้ว | หลังย้าย เราตรวจอย่างไรว่าข้อมูลครบและยอดค้างตรงกับระบบเดิม? |
| Data Model | โครงสร้างว่าข้อมูลมีอะไรบ้างและสัมพันธ์กันอย่างไร | ตำแหน่งหนึ่งมีหลาย Task และแต่ละ Task มีเวลาและความเสี่ยง | ถ้าเราอยากเพิ่มมิติใหม่ภายหลัง ต้องรื้อระบบหรือไม่? |
| Data Pipeline | เส้นทางนำข้อมูลจากต้นทางไปใช้งาน | Sensor → ฐานข้อมูล → Dashboard | ข้อมูลขาดหรือมาช้าแล้วระบบรับมืออย่างไร? |
| Data Readiness | ความพร้อมของข้อมูลที่ระบบต้องใช้ ทั้งความครบและความถูกต้อง | ข้อมูลลูกค้ามีครบทุกช่องหรือยังกรอกไม่สม่ำเสมอ | ถ้าข้อมูลยังไม่พร้อม เราควรทำอะไรก่อน? |
| Data Residency | ข้อกำหนดว่าข้อมูลต้องถูกเก็บและประมวลผลในประเทศหรือภูมิภาคใด | สัญญากับลูกค้าระบุว่าข้อมูลโครงการต้องอยู่บนเครื่องในประเทศไทย | ข้อมูลของเราถูกประมวลผลที่ประเทศไหนบ้าง รวมถึงตอนที่ส่งให้ AI? |
| Data Retention | นโยบายว่าเก็บข้อมูลไว้นานเท่าใดและลบเมื่อใด | เก็บบทสนทนาลูกค้าตามระยะเวลาที่กฎหมายและนโยบายกำหนด | เราเก็บอะไรไว้นานแค่ไหน และใครอนุมัตินโยบายนี้? |
| Decision | จุดที่ต้องเลือกทางใดทางหนึ่ง และมีผลตามมา | อนุมัติส่วนลดหรือไม่อนุมัติ | การตัดสินใจนี้ใครทำได้ และบันทึกไว้ที่ไหน? |
| Decision Intelligence | การใช้ข้อมูลและระบบช่วยคุณภาพการตัดสินใจ เป็นการจัดข้อมูล แบบจำลอง และกระบวนการตัดสินใจเข้าด้วยกัน โดยผู้รับผิดชอบยังต้องใช้วิจารณญาณและรับผลของการตัดสินใจ | เตรียม Scenario ก่อนเลือก Capacity | ระบบช่วยตัดสินใจอะไร ไม่ใช่แค่แสดงอะไร? |
| Decision Log | บันทึกสิ่งที่เลือกและเหตุผล บันทึกควรเก็บทางเลือก หลักฐาน สมมติฐาน Owner และวันทบทวน เพื่อให้องค์กรเรียนรู้จากผลจริงโดยไม่พึ่งความจำ | เทียบผลจริงกับสมมติฐานเดิม | ใครเข้าถึงและแก้บันทึกได้? |
| Decision Record | บันทึกว่าตัดสินใจอะไร ด้วยข้อมูลใด และใครเป็นคนตัดสิน | ย้อนดูได้ว่าทำไมเดือนนั้นจึงเลือกทางนี้ | เราย้อนอธิบายการตัดสินใจเมื่อสามเดือนก่อนได้ไหม? |
| Decision Rights | การกำหนดชัดว่าใครตัดสินใจเรื่องใดได้เอง และเรื่องใดต้องขออนุมัติ | หัวหน้าอนุมัติส่วนลดได้ถึงเพดานหนึ่ง เกินกว่านั้นต้องขึ้นผู้บริหาร | ใครตัดสินใจเรื่องนี้ได้ และขอบเขตอยู่ตรงไหน? |
| Decommission | การยุติระบบหรือวิธีเดิมอย่างมีแผน | ปิด Excel เดิมหลัง Workflow ใหม่เสถียร | เมื่อใดจะปิดวิธีเดิมและมีแผนย้อนกลับหรือไม่? |
| Dependency Scan | การตรวจชุดโค้ดสำเร็จรูปที่ระบบหยิบมาใช้ ว่ามีรุ่นที่มีช่องโหว่ซึ่งถูกเปิดเผยแล้วหรือไม่ | เครื่องมือแจ้งว่าชุดโค้ดจัดการไฟล์อัปโหลดมีช่องโหว่ ทีมจึงอัปเดตก่อนขึ้นระบบ | การสแกนนี้รันทุกครั้งที่แก้โค้ดหรือเปล่า และใครรับการแจ้งเตือน? |
| Disaster Recovery | แผนและระบบสำหรับกู้การให้บริการเมื่อเกิดเหตุใหญ่ เช่น ศูนย์ข้อมูลล่มหรือข้อมูลถูกเข้ารหัส | เมื่อผู้ให้บริการคลาวด์ล่มทั้งภูมิภาค ทีมเปิดระบบจากสำเนาในอีกภูมิภาคหนึ่ง | แผนนี้ครอบคลุมเหตุแบบไหน และต้องใช้ใครบ้างในการสั่งเริ่มแผน? |
| DLP | เครื่องมือที่ตรวจและกันไม่ให้ข้อมูลสำคัญถูกส่งออกนอกองค์กร ย่อจาก Data Loss Prevention | ระบบเตือนเมื่อมีคนวางเลขบัตรประชาชนจำนวนมากลงเว็บภายนอก | กฎที่ตั้งไว้ครอบคลุมข้อมูลชั้นไหน และมีการเตือนผิดบ่อยแค่ไหน? |
| Dynamic Profile | ชุดคำสั่ง/เครื่องมือที่เปลี่ยนตามสถานะ Profile รวมบริบทที่เปลี่ยนตามเวลา จึงต้องมีแหล่งที่มา ความสด สิทธิ์ และวิธีให้ผู้ใช้แก้ข้อมูลที่ระบบเข้าใจผิด | เปิด Tool วางแผนเมื่อผู้ใช้เลือกโหมดทริป | ใครกำหนด Profile? |
| Edge Computing | ประมวลผลใกล้เครื่องจักรแทนส่งทุกอย่างขึ้น Cloud | วิเคราะห์ภาพที่หน้าไลน์เพื่อลดความหน่วง | งานใดต้องตอบทันทีและทำไมจึงประมวลผลที่หน้างาน? |
| Embedding | การแปลงเนื้อหาเป็นตัวเลขเพื่อค้นความหมาย | ค้นคำว่าเครื่องร้อนเจอเอกสารอุณหภูมิสูง | ข้อมูลภาษาไทยและคำเฉพาะค้นเจอจริงหรือไม่? |
| ERP | ระบบหลังบ้านที่รวมบัญชี สต็อก จัดซื้อ และการผลิตไว้ด้วยกัน ย่อจาก Enterprise Resource Planning | ออกใบสั่งซื้อแล้วสต็อกกับบัญชีอัปเดตตามอัตโนมัติ | ระบบใหม่ต้องเชื่อมกับ ERP เดิมอย่างไร และใครดูแลการเชื่อม? |
| Error | ผลลัพธ์ที่ผิดจากที่ควรเป็น ต้องนับและแยกประเภทเพื่อแก้ให้ถูกจุด | ระบบดึงราคาผิดรุ่นมาใส่ในเอกสาร | ตอนนี้อัตราความผิดพลาดเท่าไร และผิดแบบไหนบ่อยที่สุด? |
| Escalation | ส่งเคสให้คนเมื่อเกินขอบเขต การส่งต่อควรเกิดจากกฎที่ตรวจได้ เช่น ความเสี่ยง ความมั่นใจต่ำ หรือเกินสิทธิ์ พร้อมกำหนดทีมและ SLA ของผู้รับช่วง | ปัญหาไฟฟ้าส่งช่างทันที | เงื่อนไขเสี่ยงครอบคลุมหรือยัง? |
| Evaluation | การทดสอบว่าระบบให้คำตอบถูกต้องแค่ไหน ด้วยชุดตัวอย่างที่มีคำตอบที่ถูกอยู่แล้ว | รันคำถาม 200 ข้อแล้วนับว่าตอบถูกกี่ข้อ | ใครเป็นคนตัดสินว่าคำตอบถูก และทดสอบบ่อยแค่ไหน? |
| Evaluation Set | ชุดตัวอย่างใช้ทดสอบคุณภาพซ้ำ ชุดทดสอบต้องมีเคสปกติ ข้อมูลขาด ข้อยกเว้น และการโจมตี พร้อมคำตอบหรือเกณฑ์ที่ผู้เชี่ยวชาญยอมรับ | เคสปกติ เสี่ยง และข้อมูลไม่ครบ | ครอบคลุมข้อยกเว้นจริงหรือยัง? |
| Event Tracking | บันทึกเหตุการณ์สำคัญในระบบ | เก็บเวลารับงาน อนุมัติ และปิดงาน | เหตุการณ์ใดจำเป็นต่อการวัด Outcome ไม่ใช่แค่ Usage? |
| Exception | รายการที่ไม่เข้าเกณฑ์ปกติ จึงต้องให้คนตัดสินแทนระบบ | คำขอส่วนลดเกินเพดานถูกยกให้ผู้จัดการ | ตอนนี้กี่เปอร์เซ็นต์ของงานเป็นข้อยกเว้น? |
| Exception Queue | คิวรวมงานผิดปกติให้คนตัดสิน | ใบแจ้งหนี้ยอดไม่ตรงถูกส่งเข้าคิวตรวจ | ข้อยกเว้นใดสำคัญที่สุดและ SLA เท่าไร? |
| Exception Rate | สัดส่วนรายการที่ระบบไม่จบเองและต้องให้คนดู | 10 เปอร์เซ็นต์ของคำขอถูกส่งให้คนตัดสิน | ตอนนี้อัตราข้อยกเว้นเท่าไร และมาจากสาเหตุใด? |
| Exit Plan | แผนสำหรับเลิกใช้ผู้ให้บริการหรือระบบหนึ่งโดยธุรกิจไม่สะดุด | เก็บข้อมูลและ Prompt ไว้ฝั่งเราเพื่อย้ายได้ | ถ้าเลิกใช้เจ้านี้ เราเอาอะไรออกมาได้บ้าง? |
| Experiment Dashboard | หน้าจอรวมผลการทดลองทุกชิ้นให้เทียบกันได้ | เห็นทุกไอเดียที่ทดลองพร้อมผลในที่เดียว | ผลการทดลองเก็บรวมกันหรือกระจายอยู่แต่ละทีม? |
| Explainability | ทำให้เห็นเหตุผล/หลักฐานของผลระบบ คำอธิบายที่มีประโยชน์ต้องตอบว่าข้อมูลใดและกฎใดมีผลต่อข้อเสนอ พร้อมบอกข้อจำกัด ไม่ใช่สร้างเหตุผลที่ฟังดีภายหลัง | เปิดดูแหล่ง KPI และการคำนวณ | คำอธิบายพอให้ตรวจหรือแค่ฟังดี? |
| Failover | การสลับไปใช้เครื่องหรือระบบสำรองเองเมื่อเครื่องหลักหยุดทำงาน | ฐานข้อมูลหลักดับ ระบบสลับไปใช้ตัวสำรองภายในหนึ่งนาทีโดยลูกค้าไม่ต้องทำอะไร | การสลับเคยถูกทดสอบกับระบบจริงหรือยัง และมีข้อมูลหายระหว่างสลับไหม? |
| Failure Mode | รูปแบบที่ระบบหรือกระบวนการมักพังหรือให้ผลผิด | ระบบตอบผิดเมื่อข้อมูลลูกค้าไม่ครบ | เรารู้หรือยังว่าระบบนี้พังได้กี่แบบ? |
| Fallback | วิธีสำรองเมื่อ AI หรือ Tool ล้ม ทางสำรองต้องรักษางานและบริบท เช่น เปลี่ยนเป็น Manual Flow หรือส่งคน ไม่ใช่เพียงแสดงข้อความว่าระบบขัดข้อง | ส่งงานเข้าคิวคนโดยไม่สูญข้อมูล | ทีมซ้อม Fallback แล้วหรือไม่? |
| False Accept | การที่ระบบปล่อยของเสียหรือเคสผิดผ่านไป | ชิ้นงานบกพร่องหลุดถึงลูกค้า | ความผิดพลาดแบบใดแพงกว่ากันสำหรับธุรกิจเรา? |
| False Alarm | การแจ้งเตือนที่ไม่ใช่ปัญหาจริง จนคนเลิกสนใจ | เตือนวันละสิบครั้งแต่จริงแค่ครั้งเดียว | อัตราเตือนผิดเท่าไร และใครปรับเกณฑ์? |
| False Reject | การที่ระบบตีตกของดีโดยไม่จำเป็น | ของดีถูกคัดทิ้งจนต้นทุนเพิ่ม | เราตั้งเกณฑ์จากต้นทุนของความผิดสองแบบหรือยัง? |
| FAQ | ชุดคำถามที่ลูกค้าถามบ่อยพร้อมคำตอบมาตรฐาน ย่อจาก Frequently Asked Questions | คำถามเรื่องการคืนสินค้าที่ตอบเหมือนกันทุกครั้ง | คำตอบใน FAQ ตรงกับที่ทีมตอบจริงหรือไม่? |
| Feature Flag | สวิตช์เปิดปิดฟีเจอร์โดยไม่ต้องปล่อยเวอร์ชันใหม่ | เปิดฟีเจอร์ใหม่ให้ลูกค้ากลุ่มเล็กก่อน | ถ้าฟีเจอร์มีปัญหา เราปิดได้เร็วแค่ไหนและใครปิด? |
| Feed | ไฟล์หรือกระแสข้อมูลที่ส่งให้ปลายทางเป็นรอบ เพื่ออัปเดตข้อมูลสินค้า | ส่งรายการสินค้าให้ช่องทางภายนอกทุกชั่วโมง | ถ้า Feed ล้มเหลว ปลายทางใช้ข้อมูลเก่าค้างนานแค่ไหน? |
| Feedback | ข้อมูลย้อนกลับจากผู้ใช้หรือผลงานจริง ใช้ปรับระบบให้ดีขึ้น | พนักงานกดว่าคำตอบนี้ใช้ไม่ได้ พร้อมบอกเหตุผล | เราเก็บสิ่งที่คนแก้กลับเข้าระบบหรือปล่อยหายไป? |
| Fine-tuning | การฝึกโมเดล AI เพิ่มด้วยข้อมูลของเราเอง ให้ตอบด้วยสำนวนและความรู้เฉพาะขององค์กร | ฝึกด้วยประวัติแชตจริง ให้บอทตอบด้วยโทนเดียวกับทีมขาย | ใช้ข้อมูลชุดไหนฝึก และข้อมูลลูกค้าถูกปกป้องอย่างไร? |
| FinOps | การบริหารต้นทุนระบบให้เห็นและควบคุมได้เป็นรายหน่วยงานหรือรายงาน | ตั้งงบต่อเดือนให้ Agent แต่ละตัวและแจ้งเตือนเมื่อใกล้ชน | ต้นทุนต่อการทำงานหนึ่งครั้งคือเท่าไร และใครรับผิดชอบ? |
| Flow | เส้นทางที่งานหรือข้อมูลเดินจากจุดหนึ่งไปอีกจุด | จากคำขอของลูกค้าไปถึงการอนุมัติและส่งของ | เส้นทางนี้มีจุดที่งานค้างบ่อยตรงไหน? |
| Gate | จุดตรวจที่งานต้องผ่านก่อนไปขั้นถัดไป | เอกสารต้องผ่านการตรวจข้อมูลก่อนส่งลูกค้า | ถ้าไม่ผ่านจุดตรวจ ระบบทำอะไรต่อ? |
| Go Criteria | เกณฑ์ที่ตกลงล่วงหน้าว่าอะไรจึงจะไปต่อ | ต้องมีลูกค้ายืนยัน 10 รายจึงพัฒนาเต็มรูปแบบ | เกณฑ์ไปต่อกำหนดไว้ก่อนเริ่มหรือมาตกลงทีหลัง? |
| Golden Set | ชุดตัวอย่างมาตรฐานที่ใช้ทดสอบซ้ำทุกครั้งที่ระบบเปลี่ยน | 50 เคสตัวอย่างที่รันทดสอบก่อนปล่อยเวอร์ชันใหม่ | เรามีชุดทดสอบของตัวเองหรือใช้ของผู้ขาย? |
| Governance | กติกาว่าใครตัดสินใจอะไร อนุมัติอย่างไร และตรวจสอบอย่างไร | คณะทำงานเล็กที่อนุมัติการขยายผลทุกเดือน | ใครมีอำนาจหยุดหรือขยายโครงการ? |
| Ground Truth | คำตอบที่ถูกต้องซึ่งใช้เป็นมาตรฐานวัดผลระบบ | ชุดเคสที่ผู้เชี่ยวชาญยืนยันคำตอบไว้แล้ว | ใครเป็นคนตัดสินว่าคำตอบไหนถูก? |
| Guardrail | กฎตรวจหรือหยุดการทำงาน Guardrail อาจเป็นกฎก่อนทำงาน การตรวจผลหลังทำงาน หรือเงื่อนไขหยุดและเรียกคน จึงต้องออกแบบหลายชั้นตามความเสี่ยง | ห้ามเสนอราคานอกตาราง | ใครเป็นเจ้าของกฎและทบทวนเมื่อใด? |
| Guided Generation | บังคับผล AI ให้อยู่ในโครงสร้างที่กำหนด ระบบให้โครง ตัวเลือก และกฎแก่ AI ก่อนสร้างผลลัพธ์ ทำให้คุณภาพสม่ำเสมอและเปิดพื้นที่ให้คนตรวจในจุดสำคัญ | คืนแผนเป็นรายการวันและกิจกรรม | Schema รองรับกรณีขาดข้อมูลหรือไม่? |
| Handoff | ส่งงานจาก AI ไปยังคนพร้อมบริบท Handoff ที่ดีส่งทั้งข้อเท็จจริง หลักฐาน สิ่งที่ลองแล้ว และเหตุผลที่ส่งต่อ เพื่อให้คนรับช่วงตัดสินใจได้ทันที | ฝ่ายขายได้รับสรุปโดยไม่ถามลูกค้าใหม่ | เงื่อนไขใดต้องส่งคนทันที? |
| Handoff Contract | ข้อตกลงว่าเมื่อส่งงานต่อ ต้องแนบข้อมูลอะไรครบบ้าง | ส่งเคสให้ทีมถัดไปพร้อมข้อมูลลูกค้าและสิ่งที่ลองแล้ว | เราระบุไว้ไหมว่าข้อมูลขั้นต่ำในการส่งต่อคืออะไร? |
| Handover | การส่งมอบระบบ เอกสาร และความรู้ให้ทีมผู้รับดูแลต่อ | ส่งมอบคู่มือ โครงสร้างระบบ และสิทธิ์เข้าถึงครบ | หลังส่งมอบแล้ว ใครดูแลต่อและด้วยเงื่อนไขใด? |
| Headless CMS | CMS ที่แยกส่วนจัดการเนื้อหาออกจากหน้าเว็บ ทำให้เนื้อหาชุดเดียวส่งไปได้ทั้งเว็บ แอป และหน้าจอในสาขา | แก้ราคาที่เดียว เปลี่ยนพร้อมกันทั้งเว็บและแอป | เนื้อหาชุดเดียวต้องไปแสดงกี่ช่องทาง? |
| Human Approval | จุดที่ต้องมีคนอนุมัติก่อนระบบดำเนินการต่อ | ส่วนลดเกินเพดานต้องรอผู้จัดการกดอนุมัติ | การกระทำใดบ้างที่ห้ามทำโดยไม่มีคนอนุมัติ? |
| Human Oversight | การที่คนยังกำกับดูแลผลของระบบอย่างมีความหมาย ไม่ใช่แค่มีชื่อ | สุ่มตรวจผลของระบบทุกสัปดาห์พร้อมบันทึกผล | คนที่กำกับดูแลมีเวลาและข้อมูลพอจริงหรือไม่? |
| Human Review | การให้คนตรวจผลก่อนนำไปใช้ ในจุดที่ความเสี่ยงสูง | ตรวจข้อเสนอราคาก่อนส่งลูกค้ารายใหญ่ | เราตรวจกี่เปอร์เซ็นต์ และเลือกตรวจจากอะไร? |
| Human Touch | จำนวนครั้งที่คนต้องเข้ามาแตะงานหนึ่งรายการ | จากเดิมแตะ 6 ครั้ง เหลือ 1 ครั้งเฉพาะตอนอนุมัติ | ต่อหนึ่งรายการ คนต้องแตะกี่ครั้ง? |
| Human-in-the-loop | ให้คนตรวจหรือตัดสินในจุดสำคัญ | AI ร่าง แต่เจ้าของบัญชีเป็นผู้กดส่ง | คนต้องตรวจทุกเคสหรือเฉพาะเคสเสี่ยง? |
| Idempotency | ป้องกันคำสั่งซ้ำสร้างผลซ้ำ หลักนี้สำคัญเมื่อระบบลองคำสั่งซ้ำหลัง Timeout เพราะช่วยป้องกันผลซ้ำ เช่น สร้างใบสั่งซื้อหรือหักเงินสองครั้ง | Retry แล้วไม่สร้าง PO สองใบ | ทุก Action สำคัญป้องกันซ้ำหรือยัง? |
| Incident | เหตุการณ์ที่ระบบทำงานผิดจนกระทบงานจริง ต้องมีขั้นตอนรับมือไว้ล่วงหน้า | ระบบส่งอีเมลผิดไปหาลูกค้า 200 ราย | ถ้าเกิดเรื่อง ใครรับผิดชอบ และแจ้งลูกค้าอย่างไร? |
| Integration | เชื่อมระบบใหม่กับระบบโรงงานที่มีอยู่ | ส่งเหตุการณ์เข้า CMMS หรือ MES | สัญญาข้อมูลระหว่างระบบและผู้ดูแลแต่ละฝั่งคือใคร? |
| Intent | เป้าหมายที่ผู้ใช้ต้องการทำให้สำเร็จ ในงานออกแบบ ระบบควรผูก Intent เข้ากับข้อมูลที่ต้องใช้ ขั้นตอนถัดไป และนิยามว่าสำเร็จ ไม่ใช่แค่ตั้งชื่อหมวดคำถาม | ต้องการนัดสำรวจ ไม่ใช่แค่ค้นคำว่า survey | เรารู้ Intent หลักจากข้อมูลจริงหรือคาดเดา? |
| Inventory | บัญชีรายการของสิ่งที่มีอยู่ เช่น งาน ข้อมูล หรือระบบ | ทำบัญชีว่าตอนนี้บริษัทมีระบบอัตโนมัติกี่ตัว | เรามีบัญชีครบหรือยัง และใครอัปเดต? |
| IoT | อุปกรณ์หรือ Sensor ที่ส่งข้อมูลผ่านเครือข่าย | อ่านอุณหภูมิเครื่องทุกนาที | Sensor ใดมีเจ้าของ ตรวจสอบ และสอบเทียบอย่างไร? |
| Iteration | การปรับปรุงเป็นรอบสั้นตามผลที่วัดได้ | แก้ข้อเสนอแล้วทดสอบใหม่ในสัปดาห์ถัดไป | รอบการปรับปรุงของเราสั้นแค่ไหน? |
| Job Description | เอกสารระบุขอบเขตงาน ความรับผิดชอบ และการตัดสินใจของตำแหน่งหนึ่ง | ใช้เป็นจุดตั้งต้นออกแบบว่าระบบรับงานส่วนใดได้ | เอกสารนี้อัปเดตหลังกระบวนการเปลี่ยนหรือยัง? |
| Kill Switch | ปุ่มหยุดการทำงานของระบบทันทีเมื่อพบปัญหา | หยุด Agent ทั้งหมดที่ส่งข้อความถึงลูกค้าเมื่อพบข้อผิดพลาด | ใครมีสิทธิ์กดหยุด และหลังกดแล้วงานค้างจัดการอย่างไร? |
| Knowledge | ความรู้ของบริษัทที่ระบบเรียกใช้ตอบคำถามได้ | คู่มือ วิธีแก้ปัญหา และเคสที่เคยเจอ | ความรู้ที่ระบบใช้มาจากเอกสารฉบับใด? |
| Knowledge Base | คลังความรู้ที่จัดหมวดและค้นได้ | รวม SOP, ตัวอย่างงาน และคำถามที่พบบ่อย | ใครรับรองเนื้อหา และข้อมูลเก่าถูกปิดอย่างไร? |
| Knowledge Card | หน่วยความรู้สั้นที่ระบบใช้ตอบได้ตรงจุด | การ์ดหนึ่งใบต่อหนึ่งคำถามที่ลูกค้าถามบ่อย | ความรู้ถูกจัดเป็นชิ้นที่ค้นเจอหรือยังเป็นไฟล์ยาว? |
| Knowledge Curator | คนที่ดูแลให้คลังความรู้ถูกต้อง ทันสมัย และค้นเจอ | ตรวจว่าคู่มือฉบับใดยังใช้ได้และฉบับใดต้องปลดระวาง | ใครรับผิดชอบความถูกต้องของคลังความรู้? |
| Knowledge Layer | ชั้นที่รวบรวมความรู้ของบริษัทให้ระบบเรียกใช้ได้ | คลังคู่มือ กติกา และเคสที่ผ่านการอนุมัติ | ความรู้ที่ระบบใช้มาจากแหล่งใดและใครอนุมัติ? |
| KPI | ตัววัดผลที่เชื่อมกับเป้าหมาย | วัดเวลาปิดเคส ไม่วัดจำนวนอีเมล | ตัวเลขนี้เชื่อมกับ Outcome และมีนิยามเดียวกันหรือไม่? |
| Label | คำตอบกำกับภาพสำหรับสอนและทดสอบโมเดล | ระบุภาพว่า Good หรือ Scratch | ผู้ตรวจเห็นตรงกันแค่ไหนและแก้ Label ผิดอย่างไร? |
| Landing Page | หน้าเว็บเดียวที่ออกแบบเพื่อทดสอบข้อเสนอและวัดการตอบสนอง | หน้าอธิบายบริการใหม่พร้อมปุ่มลงทะเบียน | เราวัดอะไรจากหน้านี้ และเท่าไรจึงเรียกว่าผ่าน? |
| Latency | เวลารอตั้งแต่สั่งจนตอบ ต้องวัดตลอด Journey ไม่ใช่เฉพาะเวลาตอบของโมเดล เพราะการค้นข้อมูล เรียก API และ Sync ล้วนเพิ่มเวลาที่ผู้ใช้รอ | คำแนะนำเสียงต้องตอบเร็วพอหน้างาน | ช้าเกินกี่วินาทีจึงใช้ไม่ได้? |
| Lead | ผู้ที่แสดงความสนใจสินค้าและอาจกลายเป็นลูกค้า | คนที่กรอกฟอร์มขอใบเสนอราคา | Lead ที่เข้ามาถูกติดตามต่อภายในกี่ชั่วโมง? |
| Lead Time | เวลารวมตั้งแต่ลูกค้าหรือผู้ขอเริ่มรอ จนได้รับผลลัพธ์ | ตั้งแต่ลูกค้าขอราคาจนได้ใบเสนอราคา | เราวัดจากเวลาที่ลูกค้ารอ หรือเวลาที่เราเริ่มทำ? |
| Leading Indicator | สัญญาณที่มาก่อนผลลัพธ์ ตัวชี้วัดนำช่วยให้ลงมือก่อนผลปลายทางเกิด แต่ต้องพิสูจน์ว่ามีความสัมพันธ์ที่ใช้ตัดสินใจได้จริง ไม่ใช่เพียงเปลี่ยนเร็วกว่า | งานรออนุมัติก่อน SLA หลุด | สัญญาณนี้นำหน้าได้จริงหรือไม่? |
| Learning Platform | ระบบจัดบทเรียนและติดตามการพัฒนา | พนักงานเห็นเส้นทางเรียนตามบทบาท | ระบบเชื่อมการเรียนกับงานจริงอย่างไร? |
| Least Privilege | ให้สิทธิ์น้อยที่สุดที่จำเป็น ให้เฉพาะสิทธิ์ที่จำเป็นต่อ Task และช่วงเวลานั้น ลดผลกระทบเมื่อคำสั่งผิดหรือข้อมูลถูกใช้เกินขอบเขต | Content Agent อ่านข้อมูลแต่ไม่ส่ง Email | ทบทวนสิทธิ์เมื่อบทบาทเปลี่ยนหรือไม่? |
| LLM | โมเดลภาษาขนาดใหญ่ที่อ่านและเขียนภาษาคนได้ เป็นเครื่องยนต์เบื้องหลังผู้ช่วย AI และบอทตอบแชต | อ่านอีเมลลูกค้าแล้วสรุปเป็นใบสั่งงานให้ทีม | โมเดลทำงานที่ไหน และข้อมูลของเราถูกส่งออกไปหรือไม่? |
| Load Test | การจำลองผู้ใช้จำนวนมากเข้าระบบพร้อมกัน เพื่อวัดว่ารับได้เท่าไรและตันที่จุดไหน | จำลองลูกค้าห้าพันคนกดซื้อพร้อมกันหนึ่งสัปดาห์ก่อนแคมเปญ | ระบบเริ่มช้าที่ผู้ใช้กี่คน และจุดที่ตันคือส่วนไหน? |
| Log | บันทึกอัตโนมัติว่าระบบทำอะไรไปบ้างเมื่อไร ใช้ย้อนตรวจเวลามีปัญหา | ย้อนดูได้ว่าคำตอบนี้ระบบดึงข้อมูลจากที่ไหน | เราเก็บ Log ไว้นานแค่ไหน และใครดูได้? |
| Manual | การทำงานด้วยมือ ไม่มีระบบช่วย มักเป็นจุดที่เสียเวลาและเกิดข้อผิดพลาด | คีย์ข้อมูลจากอีเมลลงในระบบทีละรายการ | งานส่วนใดยังทำด้วยมือ และคิดเป็นกี่ชั่วโมงต่อเดือน? |
| Manual Fallback | วิธีทำงานด้วยมือเมื่อระบบใช้ไม่ได้ เพื่อให้ธุรกิจไม่หยุด | ถ้าระบบล่ม ทีมกลับไปใช้ขั้นตอนสำรองที่ซ้อมไว้ | ถ้าระบบใช้ไม่ได้หนึ่งวัน เราทำงานต่ออย่างไร? |
| Memory | ข้อมูลที่ระบบใช้จำบริบทข้ามครั้ง Memory ควรเก็บเฉพาะสิ่งที่ช่วยงานและมีอายุชัด แยกระหว่างความชอบ ข้อเท็จจริง และประวัติการสนทนาเพื่อควบคุมความเสี่ยง | จำข้อจำกัดอาหารด้วย Consent | ผู้ใช้ดู แก้ และลบได้หรือไม่? |
| Message Queue | ที่พักข้อมูลระหว่างสองระบบ รายการเข้าคิวรอส่งและไม่หายแม้ปลายทางล่มชั่วคราว | ERP ปิดปรับปรุงหนึ่งชั่วโมง ออเดอร์รออยู่ในคิว แล้วทยอยเข้าเมื่อระบบกลับมา | คิวยาวสุดได้แค่ไหนก่อนที่ธุรกิจจะเดือดร้อน และเรารู้ได้จากอะไร? |
| Meta Tag | ข้อความสั้นในโค้ดหน้าเว็บที่บอก Google และโซเชียลว่าหน้านี้คืออะไร มีผลต่อหัวข้อที่คนเห็นในผลค้นหา | ตั้งหัวข้อและคำอธิบายให้ตรงกับสิ่งที่ลูกค้าค้นหาจริง | ทุกหน้าสำคัญมีหัวข้อและคำอธิบายที่เขียนไว้แล้วหรือยัง? |
| Metadata | ข้อมูลกำกับเอกสาร | ระบุรุ่นเครื่อง Owner และวันหมดอายุ | ฟิลด์ใดจำเป็นต่อการหาและควบคุมเอกสาร? |
| Middleware | ซอฟต์แวร์ตัวกลางที่รับข้อมูลจากระบบหนึ่ง แปลงรูปแบบ แล้วส่งต่อให้อีกระบบ | ตัวกลางรับออเดอร์จากแอป แปลงรหัสสินค้า แล้วส่งเข้า ERP | ถ้าตัวกลางหยุดทำงาน รายการที่ค้างอยู่ไปอยู่ที่ไหน และใครได้รับแจ้ง? |
| Mobile App | แอปที่ติดตั้งบนมือถือ ใช้กล้อง ตำแหน่ง และทำงานออฟไลน์ได้ | ช่างหน้างานถ่ายรูปและบันทึกงานจากมือถือ | ต้องใช้ตอนไม่มีสัญญาณหรือไม่? |
| Model | ตัว AI ที่ใช้ประมวลผล มีหลายรุ่นและหลายราคา เก่งคนละด้านกัน | งานง่ายใช้รุ่นเล็ก งานยากใช้รุ่นใหญ่ที่แพงกว่า | เราเลือกรุ่นตามงานหรือใช้รุ่นเดียวทั้งหมด? |
| Model Abstraction | ชั้นแยก Product ออกจากผู้ให้บริการโมเดล ชั้นนี้แยก Product Logic ออกจากผู้ให้บริการโมเดล ช่วยเปลี่ยนรุ่น ควบคุมต้นทุน และทดสอบทางเลือกโดยกระทบระบบน้อยลง | เปลี่ยนโมเดลโดยไม่รื้อ Workflow | คุณภาพ/ต้นทุนต่างกันถูกทดสอบอย่างไร? |
| Model Card | เอกสารสรุปว่าโมเดลถูกใช้ทำอะไร มีข้อจำกัดใด และประเมินอย่างไร | สรุปขอบเขตการใช้งานและกรณีที่ไม่ควรใช้ | เรามีเอกสารแบบนี้สำหรับระบบที่ใช้อยู่หรือยัง? |
| Model Drift | คุณภาพโมเดลลดเมื่อสภาพจริงเปลี่ยน | แสงหรือบรรจุภัณฑ์ใหม่ทำให้ผลคลาดเคลื่อน | เหตุการณ์ใดต้องทดสอบหรือ Train ใหม่? |
| Model Monitoring | ติดตามว่าโมเดลยังทำงานดีหรือไม่ | แจ้งเมื่อข้อมูล Sensor เปลี่ยนรูปแบบ | ใครรับแจ้งเมื่อคุณภาพโมเดลหรือข้อมูลลดลง? |
| Model Routing | การเลือกว่างานแต่ละแบบควรส่งให้โมเดลหรือวิธีใดจัดการ | งานง่ายใช้กติกา งานยากจึงใช้โมเดลใหญ่ | เราเลือกโมเดลตามงานหรือใช้ตัวเดียวทั้งหมด? |
| Monitoring | การเฝ้าดูว่าระบบยังทำงานได้ดีอยู่หลังเปิดใช้จริง ไม่ใช่ตรวจแค่ตอนส่งมอบ | ดูอัตราความผิดพลาดรายสัปดาห์ | ถ้าคุณภาพเริ่มตก เราจะรู้ภายในกี่วัน? |
| Multimodal | รับและเข้าใจข้อมูลหลายรูปแบบ แต่ละสื่อมีจุดแข็งต่างกัน ภาพอาจให้หลักฐาน ส่วนเสียงช่วยตอนมือไม่ว่าง ระบบควรเลือกใช้ตามงาน ไม่ใช่เพิ่มทุกสื่อเพราะทำได้ | อ่านภาพ Error พร้อมคำอธิบายเสียง | รูปแบบใดมีคุณภาพพอใช้จริง? |
| Multimodal Prompt | ส่งหลายสื่อให้โมเดลพิจารณาร่วมกัน คำสั่งควรบอกบทบาทของภาพ เสียง และข้อความแต่ละส่วน รวมถึงสิ่งที่ต้องทำเมื่อหลักฐานอ่านไม่ชัด แทนการปล่อยให้โมเดลเดา | ภาพอุปกรณ์พร้อมคำถามเสียง | สื่อใดจำเป็นและได้รับ Consent? |
| MVP | ผลิตภัณฑ์เล็กที่สุดที่ใช้พิสูจน์คุณค่าได้จริงกับลูกค้า | เปิดบริการเฉพาะเมืองเดียวเพื่อวัดความต้องการ | อะไรคือสิ่งที่ตัดออกได้โดยยังพิสูจน์คุณค่าได้อยู่? |
| Next.js | เฟรมเวิร์กสร้างเว็บที่เรนเดอร์หน้าไว้ล่วงหน้า ทำให้เว็บโหลดเร็วและ Google เก็บข้อมูลได้ครบ | หน้าสินค้าเปิดเกือบทันทีบนมือถือ 4G | เลือกเทคโนโลยีนี้เพราะอะไร และหาคนดูแลต่อได้ง่ายไหม? |
| NLU | ความสามารถของระบบในการเข้าใจว่าประโยคที่ลูกค้าพิมพ์ ต้องการอะไร แม้พิมพ์ผิดหรือใช้คำต่างกัน | เข้าใจว่า ‘มีสีขาวมั้ย’ กับ ‘ขาวเหลือมั้ย’ คือคำถามเดียวกัน | ถ้าระบบไม่มั่นใจว่าลูกค้าถามอะไร จะทำอย่างไร? |
| Observability | ความสามารถในการรู้ว่าระบบกำลังทำอะไรและทำไมจึงได้ผลแบบนั้น | ย้อนดูได้ว่า Agent ตัวนี้เรียกข้อมูลชุดใดก่อนตอบผิด | เมื่อเกิดปัญหา เราใช้เวลานานแค่ไหนกว่าจะรู้สาเหตุ? |
| OCR | การอ่านตัวอักษรจากรูปภาพหรือเอกสารสแกน ให้กลายเป็นข้อความที่ระบบค้นหาและคำนวณต่อได้ | ถ่ายรูปใบสั่งซื้อแล้วระบบกรอกข้อมูลลงตารางให้เอง | เอกสารลายมือหรือถ่ายเอียงจะอ่านได้แม่นแค่ไหน? |
| Offline-first | ออกแบบให้ทำงานได้แม้ไม่มีเน็ต แอปต้องออกแบบให้สร้างและแก้ข้อมูลได้โดยไม่มีเน็ตตั้งแต่ต้น พร้อมแสดงสถานะ Sync และวิธีจัดการเมื่อข้อมูลสองฝั่งขัดกัน | บันทึก Inspection แล้ว Sync ภายหลัง | ข้อมูลชนกันตอน Sync แก้อย่างไร? |
| Omnichannel | การให้ลูกค้าคุยกับเราได้ทุกช่องทางโดยเห็นข้อมูลชุดเดียวกัน ไม่ต้องเล่าเรื่องเดิมซ้ำ | ลูกค้าทักไลน์ต่อจากที่คุยค้างไว้บนเว็บ ประวัติยังอยู่ครบ | ประวัติลูกค้าจากทุกช่องทางมารวมที่เดียวหรือยัง? |
| On-device AI | ประมวลผล AI บนอุปกรณ์ เหมาะกับงานที่ต้องเร็ว เป็นส่วนตัว หรือทำงานออฟไลน์ แต่ต้องคำนึงถึงขนาดโมเดล แบตเตอรี่ และความสามารถของอุปกรณ์แต่ละรุ่น | สรุปบันทึกโดยไม่ส่งเสียงขึ้น Cloud | รุ่นอุปกรณ์ใดรองรับ? |
| On-premise | การติดตั้งระบบบนเครื่องที่อยู่ในสถานที่ของบริษัท แทนการเช่าใช้บนคลาวด์ | เซิร์ฟเวอร์ที่รันโมเดลตั้งอยู่ในห้องเครื่องของสำนักงานใหญ่ | ใครดูแลเครื่อง อัปเดตระบบ และรับผิดชอบเมื่อเครื่องเสีย? |
| Operating Model | วิธีที่องค์กรจัดคน กระบวนการ และระบบเข้าด้วยกันเพื่อส่งมอบงาน | เปลี่ยนจากทำงานตามแผนกเป็นทำงานตาม Value Stream | ถ้าระบบทำงานแทนได้ โครงสร้างทีมควรเปลี่ยนอย่างไร? |
| Opportunity Cost | มูลค่าที่เสียไปจากการเอาคนเก่งไปทำงานที่ระบบทำได้ | นักวิเคราะห์ใช้เวลาครึ่งวันรวมไฟล์ | ถ้าคืนเวลานี้ให้ทีม พวกเขาจะทำอะไรแทน? |
| Orchestration | การควบคุมหลายขั้นและหลายระบบให้ทำงานร่วมกัน ชั้นประสานงานต้องรู้สถานะ Dependency และ Failure ของแต่ละขั้น เพื่อหยุด ลองใหม่ หรือส่งคนโดยไม่เริ่มกระบวนการทั้งหมดใหม่ | เปิดสาขาตาม Dependency | ใครรับผิดชอบ Flow ทั้งเส้น? |
| Orchestrator | ตัวควบคุมลำดับและรวมงาน Agent Orchestrator เป็นเจ้าของแผนและสถานะรวม แต่ไม่ควรถือสิทธิ์ทุกอย่างเอง แต่ละ Tool ยังต้องตรวจสิทธิ์ของงานนั้น | Manager Agent เรียกผู้เชี่ยวชาญ | ใครถือ Outcome สุดท้าย? |
| Outcome | ผลลัพธ์ปลายทางที่ธุรกิจต้องการจริง ต่างจากปริมาณงานที่ทำเสร็จ | ลูกค้าได้ใบเสนอราคาและตัดสินใจได้ ไม่ใช่แค่ระบบสร้างเอกสารได้ | ระบบนี้ทำให้ผลลัพธ์ทางธุรกิจข้อไหนดีขึ้น? |
| Outcome Owner | ผู้รับผิดชอบผลลัพธ์ปลายทาง ไม่ใช่แค่งานส่วนของตน | คนที่ตอบได้ว่าทำไมลูกค้ายังรอ แม้ทุกแผนกบอกว่าทำเสร็จแล้ว | ใครถูกวัดจากผลลัพธ์รวม ไม่ใช่จากงานเฉพาะแผนก? |
| Output | ผลงานที่ระบบผลิตออกมา เช่น เอกสาร ข้อความ หรือคำแนะนำ | ร่างอีเมลตอบลูกค้าที่ระบบเขียนให้ | ผลงานที่ได้ต้องผ่านเกณฑ์อะไรจึงถือว่าใช้ได้? |
| Owner | คนที่รับผิดชอบสิ่งนั้นจริง ๆ ไม่ใช่แค่คนที่เกี่ยวข้อง | ข้อมูลราคามีเจ้าของคือฝ่ายการเงิน | สิ่งนี้ใครเป็นเจ้าของ และเขามีอำนาจแก้ไหม? |
| P50 | ค่ากลาง คืองานครึ่งหนึ่งเร็วกว่านี้ อีกครึ่งช้ากว่านี้ ใช้แทนคำว่า “ปกติแล้วใช้เวลาเท่าไร” | P50 เท่ากับ 25 นาที แปลว่าครึ่งหนึ่งของงานเสร็จเร็วกว่านั้น | ค่ากลางกับค่าเฉลี่ยของเราต่างกันมากไหม ถ้าต่างมากแปลว่ามีเคสสุดโต่ง |
| P90 | ค่าที่ 90 เปอร์เซ็นต์ของงานทำได้ไม่เกินตัวเลขนี้ ใช้ดู “เคสที่ช้า” แทนค่าเฉลี่ยที่ซ่อนปัญหา | ถ้า P90 ของการออกใบเสนอราคาคือ 3 ชั่วโมง แปลว่า 9 ใน 10 ใบเสร็จภายใน 3 ชั่วโมง | เราดูค่าเฉลี่ยหรือ P90 และลูกค้าที่รอนานที่สุดเจออะไร? |
| Parallel Run | การใช้ระบบเดิมกับระบบใหม่คู่กันช่วงหนึ่ง เพื่อเทียบผลก่อนเลิกระบบเดิม | ฝ่ายบัญชีคีย์มือต่ออีกสองสัปดาห์ขณะที่ตัวเชื่อมทำงาน แล้วเทียบยอดทุกวัน | เกณฑ์อะไรที่บอกว่าเลิกรันคู่ได้ และใครเป็นคนตัดสิน? |
| Payback Period | ระยะเวลาที่ผลตอบแทนคุ้มกับเงินที่ลงไป | ประหยัดได้เดือนละเท่านี้ จึงคืนทุนในกี่เดือน | ตัวเลขนี้คิดจากสมมติฐานอะไรบ้าง? |
| Penetration Test | การจ้างผู้เชี่ยวชาญลองเจาะระบบจริงภายใต้ข้อตกลง เพื่อหาช่องโหว่ก่อนผู้ไม่หวังดี | ผู้ทดสอบภายนอกลองเข้าถึงข้อมูลคนไข้โดยไม่มีบัญชี แล้วส่งรายงานสิ่งที่ทำได้ | ทดสอบครั้งล่าสุดเมื่อไร ครอบคลุมส่วนไหน และช่องโหว่ที่พบปิดครบหรือยัง? |
| Percentile | วิธีดูข้อมูลโดยเรียงจากน้อยไปมาก แล้วดูว่าที่ตำแหน่งกี่เปอร์เซ็นต์ได้ค่าเท่าไร | เรียงเวลาทำงานทั้งเดือน แล้วดูตำแหน่งที่ 90 เปอร์เซ็นต์ | ตัวเลขที่รายงานมาเป็นค่าเฉลี่ยหรือ Percentile? |
| PII | ข้อมูลที่ระบุตัวบุคคลได้ ต้องดูแลเป็นพิเศษ | ชื่อ เบอร์โทร และเลขที่เอกสารของลูกค้า | ข้อมูลส่วนบุคคลถูกส่งออกนอกระบบใดบ้าง? |
| Pilot | โครงการทดลองขอบเขตจำกัด เพื่อพิสูจน์ก่อนขยาย | ทดลองเฉพาะทีมบริการลูกค้าหนึ่งทีมเป็นเวลาสองเดือน | Pilot นี้จะถือว่าสำเร็จเมื่อตัวเลขใดถึงเท่าไร? |
| Policy | นโยบายที่บังคับใช้กับระบบ ว่าอะไรทำได้และอะไรห้าม | ห้ามส่งข้อมูลส่วนบุคคลออกนอกระบบ | นโยบายนี้บังคับที่ระบบจริงหรือเขียนไว้เฉย ๆ? |
| Policy Layer | ชั้นกติกาที่บังคับนอกคำสั่ง เพื่อคุมสิ่งที่ระบบทำได้ | ห้ามส่งข้อมูลส่วนบุคคลออกนอกระบบไม่ว่าสั่งอย่างไร | กติกาถูกบังคับที่ระบบหรือแค่เขียนไว้ใน Prompt? |
| POS | ระบบขายหน้าร้านที่บันทึกการขายและตัดสต็อก ณ เวลาที่ขายจริง | ขายหน้าร้านแล้วสต็อกบนเว็บลดตามทันที | POS ที่ใช้อยู่เปิดให้ระบบอื่นดึงข้อมูลได้หรือไม่? |
| Predictive Maintenance | การใช้ข้อมูลจากเครื่องจักรคาดการณ์ว่าจะเสียเมื่อไร เพื่อซ่อมก่อนสายการผลิตหยุด | ระบบเตือนล่วงหน้าสามสัปดาห์ว่าตลับลูกปืนใกล้หมดอายุ | ตอนนี้เครื่องหยุดกะทันหันสร้างความเสียหายเท่าไรต่อครั้ง? |
| Preference | ความชอบหรือข้อจำกัดของผู้ใช้ Preference เปลี่ยนได้ตามสถานการณ์และไม่ควรถูกปฏิบัติเป็นข้อบังคับ ระบบจึงต้องให้ผู้ใช้ตรวจ แก้ และล้างความจำได้ | ไม่เอาสินค้าที่ต้องติดตั้งถาวร | ลูกค้าเห็นและลบ Preference ได้หรือไม่? |
| Private LLM | โมเดลภาษาที่รันบนโครงสร้างพื้นฐานที่บริษัทควบคุมเอง ข้อมูลที่ป้อนไม่ออกไปยังผู้ให้บริการภายนอก | ผู้ช่วยค้นสัญญาของบริษัทรันบนเครื่องในห้องเซิร์ฟเวอร์ของบริษัทเอง | ค่าเครื่องและค่าดูแลต่อปีเท่าไร และคุณภาพคำตอบต่างจากบริการภายนอกแค่ไหน? |
| Problem Framing | ความสามารถเปลี่ยนโจทย์กว้างให้เป็นงาน เกณฑ์ และข้อจำกัดที่ชัด | เปลี่ยน “ช่วยเขียนให้หน่อย” เป็นโจทย์ที่มีเกณฑ์วัดได้ | เราให้โจทย์ที่ชัดพอให้ระบบทำถูกหรือยัง? |
| Process | ลำดับขั้นตอนการทำงานที่บริษัทใช้จริง | ขั้นตอนตั้งแต่รับคำสั่งซื้อจนส่งของ | กระบวนการนี้เขียนไว้ตรงกับที่ทำจริงหรือไม่? |
| Process Map | ภาพลำดับงานจริงพร้อมผู้รับผิดชอบและเวลาในแต่ละขั้น | แผนภาพงานตั้งแต่รับคำสั่งซื้อจนส่งของ | แผนภาพนี้มาจากข้อมูลจริงหรือจากการสัมภาษณ์อย่างเดียว? |
| Process Owner | คนที่รับผิดชอบกระบวนการหนึ่งตั้งแต่ต้นจนจบ ไม่ใช่แค่ช่วงที่อยู่ในแผนกตัวเอง | มีเจ้าของเดียวสำหรับเส้นทางตั้งแต่ลูกค้าขอราคาจนเก็บเงิน | กระบวนการนี้ใครเป็นเจ้าของ และเขามีอำนาจแก้ข้ามแผนกหรือไม่? |
| Product Feed | ข้อมูลสินค้าที่ส่งให้ระบบใช้งาน Feed ที่ดีมีรหัส คุณสมบัติ หน่วย ราคา สต็อก และเวลาอัปเดตสม่ำเสมอ เพื่อให้ทุกช่องทางอ้างข้อมูลชุดเดียวกัน | ราคา สต็อก คุณสมบัติ และรหัสสินค้า | ใครดูแลข้อมูลให้ทันสมัย? |
| Product Information Management | ระบบกลางที่เก็บข้อมูลสินค้าฉบับจริงสำหรับทุกช่องทาง | แก้ราคาที่เดียวแล้วเว็บและ Marketplace อัปเดตตาม | ถ้าข้อมูลสองที่ไม่ตรงกัน ระบบยึดอะไรเป็นหลัก? |
| Production | สภาพแวดล้อมที่ผู้ใช้จริงใช้งาน ต่างจากระบบทดลอง | ระบบที่พนักงานใช้ทำงานประจำวัน | อะไรคือเงื่อนไขที่ทำให้ระบบพร้อมขึ้น Production? |
| Prompt | คำสั่งหรือโจทย์ที่เราเขียนให้ AI ทำงาน คุณภาพของโจทย์มีผลต่อคุณภาพคำตอบมาก | บอกให้สรุปอีเมลลูกค้าโดยระบุว่าต้องได้อะไรบ้าง | ถ้าต้องแก้คำสั่ง ใครแก้ได้และทดสอบก่อนหรือไม่? |
| Prompt Injection | การที่ข้อความจากภายนอกหลอกให้ AI ทำสิ่งที่ไม่ควรทำ | ไฟล์ที่ลูกค้าส่งมามีคำสั่งซ่อนอยู่ | เราป้องกันคำสั่งแปลกปลอมจากข้อมูลภายนอกอย่างไร? |
| Proof of Concept | การทดลองเล็กเพื่อพิสูจน์ว่าแนวคิดเป็นไปได้ทางเทคนิค | ทดสอบว่าระบบอ่านเอกสารรูปแบบนี้ได้จริงหรือไม่ | ผ่านแล้วขั้นถัดไปคืออะไร และใช้เวลาเท่าไร? |
| Prototype | ต้นแบบสำหรับทดลองแนวคิดก่อนพัฒนาจริง | หน้า Skill Dashboard ที่ทดลองกับหนึ่งฝ่าย | เราต้องเรียนรู้อะไรจากต้นแบบก่อนลงทุนพัฒนาจริง? |
| PWA | เว็บที่ใช้งานเหมือนแอปบนมือถือ เปิดผ่านเบราว์เซอร์ได้เลย ไม่ต้องโหลดจากสโตร์ | พนักงานคลังสแกนของผ่านมือถือโดยไม่ต้องติดตั้งแอป | ต้องใช้งานตอนสัญญาณขาดหรือไม่? |
| QC | การตรวจสอบคุณภาพก่อนส่งมอบ ย่อจาก Quality Control | พนักงานตรวจชิ้นงานก่อนแพ็กลงกล่อง | เกณฑ์ตัดสินว่าผ่านหรือไม่ผ่านเขียนไว้ชัดหรืออยู่ในหัวคน? |
| QR Code | รหัสสี่เหลี่ยมที่สแกนด้วยกล้องมือถือ ใช้เปิดหน้าเว็บหรือระบุสินค้าและเอกสารได้ทันที | ติด QR บนชั้นวาง สแกนแล้วเห็นสต็อกจริงของชั้นนั้น | ใครจะเป็นคนสแกน และสแกนด้วยอุปกรณ์อะไร? |
| Quality Gate | จุดตรวจที่ต้องผ่านก่อนเดินงานต่อ | ตรวจราคาและแหล่งอ้างอิงก่อนส่ง Proposal | เกณฑ์ผ่านวัดด้วยกฎหรือผู้เชี่ยวชาญ และบันทึกหลักฐานอย่างไร? |
| Queue | คิวงานที่รอการประมวลผลหรือรอคนตัดสินใจ พร้อมลำดับความสำคัญ | งานความเสี่ยงสูงถูกดันขึ้นบนสุดของคิว | คิวจัดลำดับด้วยเกณฑ์อะไร และใครแก้ลำดับได้? |
| RAG | ให้ AI ค้นข้อมูลขององค์กรก่อนตอบ | ตอบจาก SOP ที่อนุมัติพร้อมลิงก์เอกสาร | ระบบค้นจากแหล่งใดและป้องกันเอกสารเก่าอย่างไร? |
| Rate Card | ตารางราคามาตรฐานของงานหรือบริการแต่ละประเภท | ใช้คิดราคาข้อเสนอให้สม่ำเสมอทุกครั้ง | ราคาในระบบตรงกับที่ฝ่ายขายใช้จริงหรือไม่? |
| Rate Limit | ขีดจำกัดจำนวนงานหรือคำขอในช่วงเวลาหนึ่ง เพื่อกันระบบทำงานเกินตัว | จำกัดให้ Agent ส่งอีเมลได้ไม่เกินจำนวนหนึ่งต่อชั่วโมง | ถ้าชนขีดจำกัด ระบบหยุดหรือเข้าคิว และแจ้งใคร? |
| React | ไลบรารีสร้างหน้าจอที่ใช้กันแพร่หลาย ทำให้ส่วนติดต่อผู้ใช้ตอบสนองเร็วและนำส่วนประกอบกลับมาใช้ซ้ำได้ | ตะกร้าสินค้าอัปเดตยอดทันทีโดยไม่ต้องโหลดหน้าใหม่ | ทีมอื่นรับช่วงดูแลโค้ดชุดนี้ต่อได้ง่ายแค่ไหน? |
| Real-time | ข้อมูลอัปเดตทันทีที่เกิดเหตุ ไม่ต้องรอรอบประมวลผลหรือกดรีเฟรช | ลูกค้าเห็นจำนวนคงเหลือจริงตอนกดสั่ง ไม่ใช่ยอดเมื่อวาน | ข้อมูลช้าได้กี่นาทีก่อนจะสร้างปัญหากับลูกค้า? |
| Realtime API | เชื่อมเสียง/ข้อมูลแบบหน่วงต่ำ เหมาะกับประสบการณ์เสียงหรือเหตุการณ์ที่ต้องตอบทันที แต่ต้องวางแผน Latency การขัดจังหวะ ต้นทุน และทางเลือกเมื่อเครือข่ายไม่พร้อม | สนทนาเสียงพร้อมเรียกดูสถานะเคส | ถ้าเสียงขาดจะกลับสู่ช่องทางใด? |
| Recommendation | การจัดลำดับตัวเลือกให้เหมาะกับบริบท คำแนะนำต้องมีกฎตัดตัวเลือกที่ใช้ไม่ได้และเหตุผลของการจัดลำดับ ไม่ควรอาศัยความคล้ายทางภาษาเพียงอย่างเดียว | เลือกเครื่องตามจำนวนผู้ใช้และงบ | เกณฑ์นี้ให้ประโยชน์ลูกค้าหรือยอดขาย? |
| Reconciliation | การเทียบตัวเลขของสองระบบว่าตรงกัน และไล่หาสาเหตุของรายการที่ไม่ตรง | ทุกเช้ารายงานเทียบจำนวนออเดอร์และยอดเงินของเมื่อวานระหว่างแอปกับ ERP | ใครเป็นคนปิดส่วนต่าง และต้องปิดภายในกี่ชั่วโมง? |
| Refactoring | การจัดโครงสร้างโค้ดใหม่ให้แก้ต่อได้ง่าย โดยที่ระบบยังทำงานเหมือนเดิม | รวมสูตรคิดค่าเช่าห้าที่ให้เหลือที่เดียว ผู้ใช้ไม่เห็นความเปลี่ยนแปลง | งานจัดโครงสร้างรอบนี้จะทำให้ฟีเจอร์ถัดไปเร็วขึ้นหรือถูกลงอย่างไร? |
| Requirement | สิ่งที่ระบบต้องทำได้ ตกลงกันเป็นลายลักษณ์อักษรก่อนพัฒนา | ระบบต้องออกใบเสนอราคาได้ภายใน 2 นาที | ข้อกำหนดนี้วัดผลได้จริงหรือเป็นแค่คำอธิบายกว้าง ๆ? |
| Requirement Map | โครงสร้างความต้องการและข้อจำกัด Map เชื่อมความต้องการกับ Solution, Assumption และ Acceptance ทำให้ตรวจได้ว่าข้อเสนอแต่ละส่วนมีเหตุผลรองรับ | เชื่อม Pain กับ Feature และเกณฑ์รับมอบ | ใครยืนยัน Requirement? |
| Review Queue | คิวงานที่รอให้คนตรวจก่อนดำเนินการต่อ | รายการที่ระบบไม่มั่นใจถูกส่งเข้าคิวให้หัวหน้าดู | ใครดูคิวนี้ และถ้าไม่มีคนดูจะเกิดอะไร? |
| Rework | การทำงานซ้ำเพราะผิดพลาดหรือข้อมูลไม่ครบ | ต้องแก้ใบเสนอราคาเพราะราคาผิด | เรานับ Rework จากอะไร และตอนนี้กี่เปอร์เซ็นต์? |
| Risk Tier | การจัดระดับความเสี่ยงของงาน เพื่อกำหนดว่าต้องควบคุมมากน้อยแค่ไหน | งานที่ส่งถึงลูกค้าถูกจัดระดับสูงกว่างานสรุปภายใน | เราจัดระดับด้วยเกณฑ์ใด และใครอนุมัติระดับสูงสุด? |
| ROI | ผลตอบแทนเทียบกับเงินลงทุน | ประหยัดได้เท่าไรเทียบกับค่าพัฒนาและค่าดูแล | ROI นี้คิดจากช่วงเวลากี่ปีและสมมติฐานใด? |
| Role-based Access | กำหนดสิทธิ์ตามบทบาท | พนักงานเห็นบทเรียนทั่วไป แต่ HR เห็นผลประเมิน | ใครควรเห็น แก้ อนุมัติ หรือดาวน์โหลดข้อมูลแต่ละประเภท? |
| Role-based View | หน้าจอต่างกันตามหน้าที่ | ผู้บริหารเห็นภาพรวม ทีมเห็นงานของตน | แต่ละบทบาทต้องเห็นข้อมูลเท่าใดจึงทำงานได้? |
| Rollback | การย้อนระบบกลับไปรุ่นก่อนหน้าเมื่อรุ่นใหม่มีปัญหา | รุ่นใหม่ทำให้ออกใบเสนอราคาไม่ได้ ทีมย้อนกลับรุ่นเดิมภายในห้านาที | ครั้งล่าสุดที่ซ้อมย้อนรุ่นคือเมื่อไร และข้อมูลที่เกิดระหว่างนั้นเป็นอย่างไร? |
| Root Cause | สาเหตุที่แท้จริงของปัญหา ไม่ใช่อาการที่เห็น | ของเสียเพิ่มเพราะการตั้งเครื่องหลังเปลี่ยน Lot ไม่ใช่เพราะคนตรวจ | เราแก้ที่อาการหรือที่ต้นเหตุ? |
| Row-Level Security | กฎในฐานข้อมูลที่กำหนดว่าผู้ใช้แต่ละคนอ่านหรือแก้ได้เฉพาะแถวข้อมูลใด | ตารางใบนัดคืนเฉพาะแถวที่เป็นของคนไข้ที่ล็อกอินอยู่ | มีตารางไหนที่ยังไม่มีกฎนี้ และเพราะอะไร? |
| RPO | ช่วงข้อมูลที่ยอมให้หายได้เมื่อต้องกู้จากไฟล์สำรอง | สำรองทุกสิบห้านาที ถ้าต้องกู้ ออเดอร์ที่หายจะไม่เกินสิบห้านาทีสุดท้าย | ถ้าต้องกู้ตอนนี้ ข้อมูลล่าสุดที่ได้กลับมาเป็นของกี่โมง? |
| RTO | เวลานานที่สุดที่ยอมให้ระบบหยุดได้ นับตั้งแต่เกิดเหตุจนกลับมาใช้งาน | ร้านกำหนดว่าหน้าชำระเงินต้องกลับมาภายในสามสิบนาที | ค่า RTO ที่ตั้งไว้เคยทำได้จริงในการซ้อมหรือยัง? |
| Rule | กติกาที่เขียนไว้ชัดเพื่อให้ระบบตัดสินแบบเดิมทุกครั้ง | ยอดเกินหนึ่งแสนต้องส่งให้หัวหน้าดู | กติกานี้ใครแก้ได้ และแก้แล้วมีผลทันทีหรือไม่? |
| Runbook | คู่มือทีละขั้นสำหรับรับมือเหตุที่คาดไว้ล่วงหน้า ระบุคนทำและคนตัดสินใจ | เมื่อหน้าชำระเงินล่ม คู่มือบอกว่าใครตรวจอะไร ใครประกาศในเพจ และข้อความที่ใช้ | คู่มือนี้ถูกใช้ซ้อมครั้งล่าสุดเมื่อไร และคนในตารางเวรอ่านแล้วหรือยัง? |
| Safety Stop | เงื่อนไขที่ทำให้ระบบหยุดทำงานทันทีเพื่อความปลอดภัย | หยุดส่งข้อความอัตโนมัติเมื่ออัตราผิดพลาดเกินเกณฑ์ | อะไรทำให้ระบบหยุดเอง และใครได้รับแจ้ง? |
| Sandbox | พื้นที่ทดลองที่แยกจากระบบจริง | ฝึก Agent โดยไม่แตะข้อมูล Production | ข้อมูลทดลองแยกจาก Production และล้างอย่างไร? |
| Scenario | ภาพผลลัพธ์ภายใต้สมมติฐาน Scenario ไม่ใช่คำพยากรณ์ แต่เป็นการคำนวณภายใต้สมมติฐานที่เปิดเผย เพื่อเปรียบเทียบทางเลือกและความไวของผลลัพธ์ | ถ้ายอดโต 10% ต้องใช้คนเท่าไร | สมมติฐานใครเป็นผู้ยืนยัน? |
| Scenario Modeling | การจำลองผลลัพธ์ภายใต้สมมติฐานหลายแบบเพื่อเปรียบเทียบทางเลือก | จำลองกำลังคนเมื่อ Automate ได้ 20, 40, 60 เปอร์เซ็นต์ | สมมติฐานมาจากข้อมูลจริงส่วนใด และใครเป็นคนยืนยัน? |
| Schema Markup | ข้อมูลเพิ่มเติมในหน้าเว็บที่บอก Google ว่าอะไรคือราคา รีวิว หรือสินค้า ทำให้ผลค้นหาแสดงรายละเอียดมากขึ้น | ผลค้นหาโชว์ราคาและดาวรีวิวใต้ชื่อร้าน | หน้าสินค้าของเราติดข้อมูลนี้ครบหรือยัง? |
| Scope | ขอบเขตของงานที่ตกลงว่าจะทำและไม่ทำในรอบนี้ | รอบนี้ทำเฉพาะสินค้ากลุ่มเดียวและภาษาไทยเท่านั้น | อะไรอยู่นอกขอบเขต และถ้าจะเพิ่มต้องทำอย่างไร? |
| Secret Management | วิธีเก็บรหัสลับของระบบ เช่น รหัสฐานข้อมูลและกุญแจของบริการรับชำระเงิน ให้อยู่นอกโค้ดและจำกัดคนที่เห็น | กุญแจของบริการส่งข้อความอยู่ในระบบเก็บรหัสลับ โค้ดหน้าเว็บไม่มีกุญแจนี้ | ถ้ารหัสลับหลุด เราเปลี่ยนรหัสใหม่ได้ภายในกี่นาที และใครเป็นคนทำ? |
| SEO | การทำให้เว็บถูกค้นเจอบน Google โดยไม่ต้องจ่ายค่าโฆษณา ทั้งจากโครงสร้างเว็บและเนื้อหา | ลูกค้าค้นคำว่า ‘โต๊ะไม้สั่งทำ’ แล้วเจอร้านเราหน้าแรก | คำค้นไหนที่พาลูกค้าที่พร้อมซื้อเข้ามาจริง? |
| Service Account | บัญชีสำหรับระบบหรือ Agent ใช้ทำงาน แยกจากบัญชีของพนักงาน | Agent ใช้บัญชีของตัวเองเข้าถึงระบบ ไม่ใช้บัญชีพนักงานร่วม | แต่ละระบบใช้บัญชีของใคร และถอนสิทธิ์ได้ทันทีหรือไม่? |
| Service Blueprint | แผนภาพที่แสดงทั้งสิ่งที่ลูกค้าเห็นและงานเบื้องหลังที่ทำให้เกิดขึ้น | เห็นพร้อมกันว่าหน้าบ้านทำอะไรและหลังบ้านต้องรองรับอะไร | เรามีภาพงานเบื้องหลังครบหรือดูแค่หน้าจอ? |
| Session Context | ข้อมูลที่ระบบจำภายในเคส บริบทควรแยกสิ่งที่ผู้ใช้ยืนยันออกจากสิ่งที่ AI สรุปหรือคาดการณ์ และมีอายุการเก็บที่เหมาะกับความเป็นส่วนตัว | จำรุ่นและขั้นที่ลูกค้าลองแล้ว | เก็บนานเท่าไรและใครเห็น? |
| Session Memory | การจำบริบทของบทสนทนาเดียวกัน เพื่อไม่ต้องถามซ้ำ | ลูกค้าไม่ต้องเล่าเงื่อนไขใหม่ทุกครั้งที่ตอบ | เราเก็บบริบทนานแค่ไหน และลบเมื่อใด? |
| Shadow AI | การที่พนักงานใช้เครื่องมือ AI ที่บริษัทไม่ได้อนุมัติและมองไม่เห็น | พนักงานถ่ายรูปสัญญาด้วยมือถือส่วนตัวแล้วให้แอป AI สรุป | เรารู้ได้อย่างไรว่าตอนนี้พนักงานใช้ AI ตัวไหนกับงานอะไร? |
| Shadow Mode | ให้ระบบแนะนำแต่ยังไม่ควบคุมงานจริง | เปรียบเทียบ Alert กับการตัดสินของช่าง | ต้องทดลองนานและผ่านสภาวะใดก่อนใช้จริง? |
| Single Source Brief | เอกสารตั้งต้นฉบับเดียวที่ทุกฝ่ายใช้อ้างอิงร่วมกัน | ข้อความและข้อเสนอทั้งหมดอ้างจาก Brief ฉบับเดียว | ถ้า Brief เปลี่ยน ชิ้นงานที่ทำไปแล้วรู้ได้อย่างไร? |
| Sitemap | ไฟล์ที่บอก Google ว่าเว็บมีหน้าอะไรบ้าง ช่วยให้หน้าใหม่ถูกเก็บเข้าระบบค้นหาเร็วขึ้น | ขึ้นสินค้าใหม่แล้ว Google เจอภายในวันเดียว | หน้าใหม่ใช้เวลานานแค่ไหนกว่าจะขึ้นผลค้นหา? |
| SKU | รหัสสินค้าหนึ่งรายการที่แยกจากรายการอื่นได้ ย่อจาก Stock Keeping Unit | เสื้อรุ่นเดียวกันแต่คนละสีคนละไซซ์ นับเป็นคนละ SKU | ข้อมูลราคาและสต็อกผูกกับ SKU ครบทุกตัวหรือยัง? |
| SLA | เวลาบริการที่ตกลงไว้ SLA ควรวัดเวลาที่มีความหมายต่อผู้รับบริการ แยกเวลารอข้อมูลออกจากเวลาทำงาน และระบุสิ่งที่เกิดขึ้นเมื่อเกินกำหนด | ฝ่าย IT รับงานภายใน 4 ชั่วโมง | เมื่อใกล้เกิน SLA แจ้งใคร? |
| SOP | คู่มือขั้นตอนการทำงานมาตรฐานที่ทีมใช้ทำงานให้เหมือนกัน ย่อจาก Standard Operating Procedure | ขั้นตอนตรวจรับสินค้าที่ทุกกะทำเหมือนกัน | ถ้าระบบเปลี่ยนวิธีทำงาน SOP ถูกแก้ตามหรือยัง? |
| Source | แหล่งที่มาของข้อมูลหรือคำตอบ ใช้ตรวจย้อนว่าเชื่อได้ไหม | คำตอบอ้างอิงคู่มือหน้า 12 | คำตอบนี้มาจากเอกสารฉบับไหน? |
| Source Code Ownership | ข้อตกลงว่าใครเป็นเจ้าของโค้ดและเอกสารที่พัฒนาขึ้น | บริษัทเป็นเจ้าของโค้ดและเก็บไว้ในระบบของตัวเอง | ถ้าเปลี่ยนผู้พัฒนา เราได้อะไรติดมือไปบ้าง? |
| Source of Truth | แหล่งข้อมูลหลักที่ทุกฝ่ายยึดร่วมกัน | ราคาอ่านจาก ERP ไม่อ่านจากไฟล์เก่า | ข้อมูลฉบับจริงอยู่ที่ใดและใครมีสิทธิ์แก้? |
| SSO | การล็อกอินครั้งเดียวด้วยบัญชีบริษัทแล้วเข้าได้หลายระบบ ย่อจาก Single Sign-On | พนักงานเข้าผู้ช่วย AI ด้วยบัญชีอีเมลบริษัท เมื่อลาออกสิทธิ์ถูกปิดพร้อมกันทุกระบบ | เมื่อพนักงานย้ายแผนก สิทธิ์ในผู้ช่วยเปลี่ยนตามภายในเวลาเท่าไร? |
| Staging | ระบบจำลองที่เหมือนระบบจริง ใช้ลองของใหม่ก่อนปล่อยให้ลูกค้าใช้ | ฝ่ายขายลองฟีเจอร์จองล่วงหน้าบน Staging หนึ่งสัปดาห์ก่อนเปิดจริง | Staging ต่างจากระบบจริงตรงไหนบ้าง และใครเป็นคนอนุมัติให้ขึ้นจริง? |
| State | สถานะปัจจุบันของงานหนึ่งชิ้น ว่าอยู่ขั้นไหนแล้ว | คำขออยู่ในสถานะรออนุมัติ | ทุกงานมีสถานะเดียวที่ทุกฝ่ายเห็นตรงกันหรือไม่? |
| State Machine | กฎว่างานเปลี่ยนสถานะอย่างไร State Machine ทำให้สถานะและทางเปลี่ยนถูกกำหนดชัด จึงป้องกันงานข้ามขั้นหรือค้างในสภาวะที่ไม่มีเจ้าของ | Draft → Review → Approved | สถานะผิดย้อนกลับได้หรือไม่? |
| Statement of Work | เอกสารระบุขอบเขตงาน สิ่งที่ส่งมอบ และเงื่อนไขการยอมรับ | ระบุว่ารอบนี้ส่งมอบอะไรและถือว่าเสร็จเมื่อใด | เงื่อนไขการยอมรับงานเขียนไว้ชัดหรือยัง? |
| Straight-through Processing | การให้รายการมาตรฐานไหลจบโดยไม่ต้องมีคนแตะเลย | คำขอที่เข้าเกณฑ์ถูกอนุมัติและบันทึกอัตโนมัติ | ตอนนี้กี่เปอร์เซ็นต์ของรายการจบได้เองโดยไม่มีคนแตะ? |
| Structured Data | ข้อมูลที่จัดรูปแบบตามมาตรฐานให้เครื่องอ่านเข้าใจ ไม่ใช่ข้อความอิสระ | ระบุราคาและสถานะสต็อกในรูปแบบมาตรฐานบนหน้าสินค้า | หน้าสำคัญของเรามีข้อมูลแบบที่เครื่องอ่านได้ครบหรือยัง? |
| Structured Output | ผล AI ที่อยู่ในรูปข้อมูลแน่นอน รูปแบบที่แน่นอนช่วยให้โปรแกรมตรวจช่องที่ขาดและส่งข้อมูลต่อได้ ลดความเสี่ยงจากการดึงข้อเท็จจริงออกจากข้อความอิสระ | คืนรายการ SKU และเหตุผลเป็นช่อง | ถ้าข้อมูลไม่ครบระบบทำอย่างไร? |
| System Integration | การเชื่อมหลายระบบให้ข้อมูลเดินต่อกัน | อีเมลเข้าแล้วสร้างรายการในระบบอนุมัติ | ระบบใดเป็นเจ้าของข้อมูลและหากเชื่อมต่อไม่ได้จะทำอย่างไร? |
| Task | งานย่อยหนึ่งชิ้นที่แยกออกมาได้ชัด ใช้เป็นหน่วยในการวางแผนและวัดผล | แยกงานแอดมินขายออกเป็น 12 งานย่อย | เราแยกงานเป็นหน่วยย่อยแล้วหรือยัง? |
| Task Completion | การที่งานหนึ่งเดินจนจบตามเป้าหมาย ไม่ค้างกลางทาง | คำขอถูกปิดโดยไม่ต้องเปิดใหม่ | งานกี่เปอร์เซ็นต์ที่จบในรอบเดียว? |
| Task Inventory | บัญชีงานย่อยของตำแหน่งหนึ่ง พร้อมเวลา ความถี่ และความเสี่ยง | แยกงานแอดมินขายเป็น 12 Task แล้วประเมินทีละงาน | เรามีบัญชีงานจริงหรือประเมินจากความรู้สึก? |
| Task Success | สัดส่วนงานที่ผู้ใช้ทำจนสำเร็จตามที่ตั้งใจ | ลูกค้าที่เริ่มขอใบเสนอราคาแล้วได้รับจริง | เราวัดว่าคนทำเรื่องสำเร็จ ไม่ใช่แค่เข้าใช้งาน? |
| TCO | ต้นทุนรวมตลอดอายุระบบ | รวมพัฒนา Cloud Support และเวลาตรวจ | รวมค่าดูแล Integration, Model และคนตรวจครบหรือยัง? |
| Technical Debt | ภาระที่สะสมจากโค้ดที่เขียนแบบเร็วไว้ก่อน ทำให้การแก้ครั้งต่อไปช้าและเสี่ยงขึ้น | สูตรคิดค่าเช่าถูกเขียนซ้ำไว้ห้าที่ ขึ้นราคาครั้งเดียวต้องตามแก้ทั้งห้าที่ | ส่วนไหนของระบบมีหนี้มากที่สุด และมันทำให้งานแก้ช้าลงเท่าไร? |
| Telemetry | ข้อมูลสถานะและการใช้งานที่ระบบส่งต่อเนื่อง | ดูจำนวน Error และค่าใช้ API | ข้อมูลใดช่วยแก้ระบบและข้อมูลใดเกินความจำเป็น? |
| Template | แม่แบบเอกสารหรือข้อความที่ระบบเติมข้อมูลให้อัตโนมัติ | ใบเสนอราคาที่เติมข้อมูลลูกค้าและราคาให้เอง | ใครแก้แม่แบบได้ และมีการควบคุมเวอร์ชันไหม? |
| Threat Model | การไล่ล่วงหน้าว่าใครอาจโจมตีระบบจากทางไหนและจะเสียหายอะไร เพื่อตัดสินใจว่าต้องป้องกันจุดใดก่อน | ทีมไล่ว่าคนไข้ พนักงานที่ลาออก และคนนอก แต่ละกลุ่มเข้าถึงประวัติการรักษาได้ทางไหน | ความเสี่ยงสามอันดับแรกของระบบเราคืออะไร และแต่ละข้อใครรับผิดชอบ? |
| Threshold | ค่าขอบเขตที่ใช้เริ่มการแจ้งเตือน | อุณหภูมิเกินเกณฑ์ต่อเนื่อง 10 นาที | ตั้งเกณฑ์จากความเสี่ยงหรือจากค่าเฉลี่ย และใครอนุมัติ? |
| Throughput | ปริมาณงานที่ระบบหรือทีมทำเสร็จได้ต่อช่วงเวลา | จำนวนใบเสนอราคาที่ออกได้ต่อสัปดาห์ | ถ้างานเพิ่มสองเท่า ระบบรองรับได้หรือไม่? |
| Time-series Data | ข้อมูลที่เรียงตามเวลา | ค่าการสั่นทุกวินาที | เวลา หน่วย และ Operating State ตรงกันหรือไม่? |
| Tool | เครื่องมือหรือระบบภายนอกที่ AI เรียกใช้เพื่อทำงานจริง | เรียกระบบสต็อกเพื่อเช็กของก่อนตอบลูกค้า | ระบบเรียกใช้เครื่องมือใดได้บ้าง และจำกัดอย่างไร? |
| Tool Call | การที่ AI เรียกใช้ระบบอื่นเพื่อทำงานจริง ไม่ใช่แค่ตอบข้อความ | เรียก API เพื่อเช็กสต็อกก่อนตอบลูกค้า | ระบบเรียกเครื่องมือใดได้บ้าง และจำกัดอย่างไร? |
| Tool Calling | ให้ AI ขอเรียกฟังก์ชันของระบบ ตัวโมเดลเป็นผู้ขอใช้เครื่องมือ แต่ระบบซอฟต์แวร์ต้องตรวจพารามิเตอร์ สิทธิ์ และผลลัพธ์ก่อนดำเนินการจริง | ตรวจตารางนัดก่อนเสนอเวลา | ทุก Tool ต้องขออนุมัติหรือไม่? |
| Total Cost | ต้นทุนรวมทั้งค่าพัฒนา ค่าใช้งาน และค่าดูแลต่อเนื่อง | รวมค่าโมเดล ค่าโฮสต์ และเวลาทีมที่ดูแล | ต้นทุนปีที่สองเป็นเท่าไร? |
| Touch Time | เวลาที่มีคนลงมือทำงานจริง ไม่รวมเวลารอ | ตรวจเอกสารใช้เวลา 12 นาที | Touch Time กับ Lead Time ต่างกันเท่าไร? |
| Traceability | ความสามารถย้อนจากผลไปถึงชิ้นงาน | ค้นภาพด้วย Serial และ Lot | ต้องย้อนจากผลไปถึงข้อมูลใดบ้าง? |
| Tracing | บันทึกลำดับการคิดเชิงระบบและ Tool Trace ที่ดีเชื่อม Input, Model, Prompt, Tool, Output, เวลาและต้นทุน ทำให้ทีมตามหาสาเหตุและสร้าง Regression Test ได้ | ดูว่า Flow ล้มที่ขั้นใด | ข้อมูล Trace ปลอดภัยและเก็บนานเท่าไร? |
| UAT | ช่วงที่ผู้ใช้จริงทดลองระบบก่อนเปิดใช้งาน เพื่อยืนยันว่าทำงานได้ตามงานจริง ไม่ใช่แค่ผ่านการทดสอบของทีมพัฒนา | แอดมินสามคนลองรับออเดอร์จริงหนึ่งสัปดาห์ก่อนเปิดใช้ | ใครเป็นคนเซ็นรับว่าระบบพร้อมใช้งาน? |
| UI | หน้าตาของระบบที่ผู้ใช้เห็นและกด ย่อจาก User Interface ต่างจาก UX ที่หมายถึงประสบการณ์ทั้งหมด | ปุ่ม เมนู และตารางบนหน้าจอ | หน้าจอนี้ออกแบบสำหรับใครใช้ และเขาใช้ตอนไหน? |
| Unit Cost | ต้นทุนต่อการทำงานหนึ่งครั้ง ใช้เทียบกับต้นทุนคน | ต้นทุนต่อการตอบลูกค้าหนึ่งเรื่อง | ต้นทุนต่อหน่วยรวมค่าอะไรบ้าง และเปลี่ยนตามปริมาณอย่างไร? |
| UX | ประสบการณ์ของผู้ใช้เมื่อใช้ระบบ ว่าทำงานให้เสร็จได้ง่ายหรือยาก ย่อจาก User Experience | ลูกค้ากรอกฟอร์มจบใน 3 ช่อง แทนที่จะเป็น 12 ช่อง | เราวัดจากอะไรว่าผู้ใช้ทำงานสำเร็จง่ายขึ้น? |
| Validation | การพิสูจน์สมมติฐานด้วยหลักฐานจากผู้ใช้จริง | มีลูกค้า 12 รายยอมจ่ายมัดจำ | หลักฐานแบบใดที่เราถือว่าเชื่อได้จริง? |
| Value Hypothesis | สมมติฐานว่าสิ่งที่จะสร้างมีคุณค่าเพราะอะไร และจะพิสูจน์อย่างไร | เชื่อว่าลูกค้าจะจ่ายถ้าลดเวลารอจาก 2 วันเหลือ 2 ชั่วโมง | เราจะรู้ได้อย่างไรว่าสมมติฐานนี้ผิด? |
| Value Stream | เส้นทางงานที่สร้างคุณค่าให้ลูกค้าตั้งแต่ต้นจนจบ ข้ามแผนก | Lead-to-Cash ตั้งแต่ลูกค้าสนใจจนชำระเงิน | Value Stream นี้เริ่มและจบที่ใคร? |
| Vector Database | ฐานข้อมูลที่ค้นด้วยความหมายแทนการจับคู่คำ ทำให้ AI หาเอกสารที่เกี่ยวข้องเจอแม้ใช้คำต่างกัน | ถามว่า ‘ของกันน้ำมีอะไรบ้าง’ แล้วเจอสินค้าที่เขียนว่า ‘ทนความชื้น’ | ระบบดึงคำตอบมาจากเอกสารชุดไหน และอัปเดตอย่างไร? |
| Vendor | ผู้ให้บริการหรือผู้ขายระบบจากภายนอก | บริษัทที่ขายซอฟต์แวร์หรือบริการโมเดล AI ให้เรา | ถ้าเลิกใช้เจ้านี้ เราเอาข้อมูลออกมาได้อย่างไร? |
| Vendor Lock-in | สภาพที่เปลี่ยนผู้ให้บริการได้ยากเพราะระบบผูกกับเจ้าเดียวมากเกินไป | Prompt และข้อมูลอยู่ในระบบของผู้ขายทั้งหมด | ถ้าเลิกใช้เจ้านี้ เราเอาอะไรออกมาได้บ้าง? |
| Version | รุ่นของเอกสาร กติกา หรือระบบ ใช้บอกว่าตอนนั้นใช้อะไรอยู่ | คู่มือฉบับเดือนนี้ต่างจากฉบับปีที่แล้ว | เรารู้ไหมว่าตอนนั้นระบบใช้กติกาเวอร์ชันใด? |
| Version Control | การควบคุมเวอร์ชันของงาน เพื่อรู้ว่าอันไหนล่าสุดและย้อนกลับได้ | ย้อนกลับไปใช้ข้อความเวอร์ชันก่อนหน้าได้ | ถ้าปล่อยผิดเวอร์ชัน เราย้อนกลับได้เร็วแค่ไหน? |
| Versioning | การเก็บหลายรุ่นอย่างตรวจสอบได้ ทุกการแก้ควรมีหมายเลข ผู้แก้ เวลา และความต่าง เพื่อรู้ว่าเอกสารหรือกฎใดถูกใช้ในวันที่ตัดสินใจ | รู้ว่า Proposal ใช้ราคาเดือนไหน | รุ่นใดเป็นฉบับอนุมัติ? |
| Wait Time | เวลาที่งานรออยู่เฉย ๆ โดยไม่มีใครทำ | เอกสารรออนุมัติสองวันแต่ใช้เวลาตรวจ 10 นาที | เวลารวมของเราเป็นเวลาทำจริงกี่เปอร์เซ็นต์? |
| Web Application | ซอฟต์แวร์ที่ใช้งานผ่านเบราว์เซอร์ ไม่ต้องติดตั้ง | ระบบหลังบ้านที่ทีมเปิดใช้จากคอมพิวเตอร์ทุกเครื่อง | ระบบนี้ต้องใช้บนอุปกรณ์ใดบ้าง? |
| Webhook | สัญญาณอัตโนมัติเมื่อเหตุการณ์เกิด | CRM แจ้งระบบทันทีเมื่อ Lead เปลี่ยนสถานะ | หากส่งสัญญาณซ้ำหรือไม่ถึง ระบบป้องกันงานซ้ำอย่างไร? |
| WIP | งานที่เริ่มแล้วแต่ยังไม่เสร็จ ย่อจาก Work In Progress ยิ่งค้างมากยิ่งใช้เงินจมมาก | ออเดอร์ที่ผลิตค้างอยู่ในไลน์ | ตอนนี้มีงานค้างอยู่กี่รายการ และค้างนานเฉลี่ยเท่าไร? |
| Work Item | หน่วยงานหนึ่งชิ้นในระบบ ที่มีสถานะและเจ้าของชัดเจน | คำขอหนึ่งรายการที่ไหลผ่านหลายขั้นตอน | ทุกงานมี Identifier เดียวตลอดเส้นทางหรือไม่? |
| Work Order | ใบสั่งงานที่ระบุสิ่งที่ต้องทำ ผู้รับผิดชอบ และสถานะ | ใบสั่งซ่อมที่ช่างรับจากระบบและปิดงานเมื่อเสร็จ | ใบสั่งงานผูกกับข้อมูลเครื่องและประวัติซ่อมหรือไม่? |
| Workflow | ลำดับงานตั้งแต่เริ่มจนได้ผลลัพธ์ โดยบอกว่าใครทำอะไร | คำขออบรม → ทำแบบฝึก → หัวหน้าตรวจ → รับรองทักษะ | ขั้นตอนใดควรเป็นอัตโนมัติ และจุดใดต้องให้คนตัดสิน? |
| Workflow Automation | การให้ระบบทำขั้นตอนซ้ำ ๆ ต่อกันเองอัตโนมัติ แทนการคัดลอกข้อมูลข้ามแอปด้วยมือ | ออเดอร์จากไลน์เข้าตารางสต็อกและแจ้งทีมส่งของเองโดยไม่ต้องพิมพ์ซ้ำ | ตอนนี้ทีมเสียเวลาคัดลอกข้อมูลข้ามระบบวันละกี่ชั่วโมง? |
| Workflow Engine | ระบบรันกฎและเส้นทางงาน Engine เก็บกฎ สถานะ งานรอ และการส่งต่อ ทำให้กระบวนการแก้ได้โดยไม่ฝังเงื่อนไขทั้งหมดไว้ในหน้าจอหรือ Prompt | ส่ง Approval ตามวงเงิน | กฎเปลี่ยนได้โดยใคร? |