Agentic Company Enablement

องค์กรที่เราเข้าไปทำงานด้วยเจอปัญหารูปแบบเดียวกันแทบทุกที่ — มีงาน process ภายในแบบ manual มากกว่ากำลังของทีม engineering ที่จะเข้าไป automate ได้ทัน รายการ "น่าจะทำเครื่องมือให้เรื่องนี้นะ" ยาวขึ้นทุกไตรมาส และตัวที่ได้สร้างจริงคือตัวที่มีงบผูกไว้ ไม่ใช่ตัวที่กินเวลาคนมากที่สุด Agentic operating model เข้าโจมตีรายการนี้จากอีกด้าน — ด้วยการทำให้คนที่ทำงานอยู่หน้างานสร้างเครื่องมือของตัวเองได้อย่างปลอดภัย

ทำไม backlog ของ internal tool ถึงไม่เคยสั้นลง?

เพราะตัวเลขมันไม่เคยคุ้ม workflow ที่กินเวลาทีมหนึ่งสี่ชั่วโมงต่อสัปดาห์คือเงินจริง แต่ยังไม่พอจะ justify หนึ่ง sprint หนึ่ง maintainer และหนึ่งรอบ security review งานนั้นจึงยังเป็น manual ต่อไป คูณด้วยจำนวนโต๊ะงานทั้งองค์กรแล้วคุณจะได้ต้นทุนจริง — ที่มองไม่เห็น กระจายตัว และไม่เคยอยู่บน roadmap ของใคร สิ่งที่ agent เปลี่ยนคือต้นทุนของการสร้าง ซึ่งเป็นเหตุผลที่ backlog นี้ควรถูกหยิบมาดูใหม่ตอนนี้ ทั้งที่เมื่อสองปีก่อนยังไม่ควร

ใน 90 วันแรก เราทำอะไรจริง ๆ

เราไม่ได้เริ่มที่แพลตฟอร์ม เราเริ่มด้วยการเข้าไปนั่งกับ 2–3 ทีมเป็นเวลาหนึ่งสัปดาห์ แล้วจดว่าพวกเขาทำอะไรจริง ๆ — แตะระบบไหนบ้าง จุดไหนต้องใช้คนตัดสิน และตอนนี้ใครเป็นคนเซ็น Inventory ชุดนั้นคือสิ่งที่กำหนดว่าเราจะสร้าง connector ตัวไหน และเขียน approval policy อย่างไร จากนั้นจึงค่อยตั้ง capability layer แล้วปล่อยให้แผนก pilot เริ่มสร้าง

• Inventory งาน manual ของแต่ละทีมเป็นลายลักษณ์อักษร จัดอันดับตามชั่วโมงที่เสียไปและความปลอดภัยที่ agent จะรับไปทำได้
• Capability Layer พร้อม connector ที่ถูก scope ไปยัง ERP, CRM, HRIS และ Data Warehouse โดย credential ถือไว้ส่วนกลาง ไม่เคยอยู่ในแอป
• Approval Policy ที่ระบุชัดว่า action ไหนต้องผ่านคน ใครเป็นผู้รีวิว และ audit record ต้องเก็บอะไรบ้าง
• แผนก pilot ที่สร้างและรันแอปจริงบนข้อมูลจริง โดยเรา coach อยู่ในห้อง ไม่ใช่ตอบทางอีเมล

คำถามด้าน governance ที่ทีม security จะถามเป็นข้อแรก

คำถามเดิมเสมอ: อะไรกันไม่ให้คนนอกสาย engineering สร้างของที่ทำข้อมูลรั่ว คำตอบต้องเป็นเชิงโครงสร้าง ไม่ใช่เชิงระเบียบปฏิบัติ แอปรันใน per-user sandbox ที่ไม่มี standing credential และไม่มี ambient network access ทุก external call ต้องผ่าน broker ถูก scope ไปยัง resource ที่ระบุชื่อ และถูก log แบบแก้ไม่ได้ ส่วน action ที่เขียนลง system of record จะเข้าคิวรอผู้อนุมัติที่ระบุตัวตน และการ Deny ถูกบันทึกอย่างละเอียดพอ ๆ กับการ Approve ทั้งหมดนี้ไม่ได้ขึ้นอยู่กับว่าคนสร้างแอปจะตัดสินใจถูกหรือเปล่า

ถ้า safety model ของคุณต้องพึ่งให้ผู้ใช้เลือกถูก นั่นไม่ใช่ safety model แต่เป็นโปรแกรมอบรม

สิ่งที่เราส่งมอบ

เมื่อจบ engagement ทีม platform ของคุณเป็นเจ้าของ capability layer, approval policy และ blueprint library พร้อม runbook, โมเดล cost attribution ที่แสดง model spend รายทีมและราย workflow และ PDPA data map ที่ครอบคลุม connector ทุกตัวที่เราสร้าง เรายังอยู่ต่อในรอบ quarterly review ที่ดูทั้ง usage, cost และ risk และ scope การ rollout ของแผนกถัดไปจากสิ่งที่ pilot สอนเราจริง ๆ ไม่ใช่จากแผนตั้งต้น

ถ้ารายการ internal tool ของคุณยาวกว่า roadmap ของทีม engineering เริ่มด้วย Workshop ครึ่งวัน เรา map งาน manual ของแผนกหนึ่งเทียบกับสิ่งที่ agent รับไปทำได้อย่างปลอดภัย แล้วกลับมาพร้อม pilot ที่ scope ชัดและ governance model ที่ทีม security ของคุณเซ็นอนุมัติได้ ก่อนที่ใครจะต้องผูกมัดกับการ rollout