ข้อจำกัดของโมเดล Project-based AI
องค์กรจำนวนมากดำเนินโครงการ AI ในรูปแบบ project ต่อเนื่องมาหลายปี คำถามที่ควรพิจารณาคือ จากโครงการที่ดำเนินการไปแล้ว มีสัดส่วนเท่าใดที่ยังใช้งานอยู่ในปัจจุบัน และยังส่งมอบ value อย่างต่อเนื่องสำหรับหลายองค์กร คำตอบคือสัดส่วนที่ยังคงใช้งานได้จริงและขยายผลทั้งองค์กรมีจำนวนจำกัด ปัญหานี้ไม่ได้เกิดจากคุณภาพของเทคโนโลยีหรือทีมผู้ดำเนินการ แต่เกิดจากลักษณะของโมเดลการทำงานเอง Project-based AI ถูกออกแบบมาเพื่อส่งมอบ deliverable ที่มีขอบเขตจำกัด ไม่ใช่เพื่อสร้าง capability ที่ต่อเนื่อง
ข้อจำกัดเชิงโครงสร้างของโมเดล Project
01 — ระยะเวลาเริ่มต้นโครงการกระบวนการ Sales cycle, scoping, SOW และ contracting ใช้เวลารวมหลายเดือนก่อนเริ่มดำเนินงานจริง ผลคือ value ชิ้นแรกมักส่งมอบช้ากว่าจังหวะที่ business context ต้องการ
02 — ความไม่แน่นอนของทั้งสองฝ่ายผู้ให้บริการไม่ทราบรายละเอียด process ภายในของลูกค้าอย่างครบถ้วน ขณะที่ลูกค้าก็ไม่สามารถคาดการณ์ล่วงหน้าได้ว่าการ deploy AI จะเผยปัญหาอะไรบ้าง เช่น คุณภาพข้อมูล, edge case, หรือการยอมรับของผู้ใช้งาน Discovery จึงควรเป็นส่วนหนึ่งของงาน ไม่ใช่ขั้นตอนก่อนเริ่มงาน
03 — การควบคุม Scope ทำได้ยากการเปลี่ยนแปลงแต่ละครั้งนำไปสู่กระบวนการ re-scope, re-budget และ re-negotiate ซึ่งส่งผลให้ momentum ของโครงการชะลอตัว และในบางกรณีลูกค้าหลีกเลี่ยงการรายงานปัญหาเพื่อลดขั้นตอนเอกสาร
04 — ไม่มีจุดสิ้นสุดที่ชัดเจนกระบวนงานทางธุรกิจดำเนินต่อเนื่องโดยธรรมชาติ use case หนึ่งมักนำไปสู่ use case อื่นตามมา การปิดโครงการในความหมายที่สมบูรณ์จึงเกิดขึ้นได้ยาก และ value มักลดลงเมื่อทีมผู้ดำเนินการถอนตัว
05 — การพัฒนาต่อหยุดที่ เวอร์ชั่นแรก Use case เดียวกันมีศักยภาพในการพัฒนาต่อเนื่อง เช่น จาก stat baseline ไปสู่ ML และ personalization แต่ pricing แบบ project มักไม่มีโครงสร้างที่รองรับการพัฒนาต่อ ทำให้ v1 เป็นจุดสิ้นสุดของการพัฒนาในทางปฏิบัติ
CoE-as-a-Service คืออะไร
CoE-as-a-Service เป็นการปรับโครงสร้างจาก project lifecycle ไปสู่ operating model ที่ต่อเนื่อง แทนที่จะจัดซื้อ project ที่มีจุดเริ่มต้นและจุดสิ้นสุด องค์กรเข้าร่วมเป็นสมาชิกของ capability ที่ดำเนินงานต่อเนื่อง และพัฒนาคุณภาพขึ้นตามจำนวน use case ที่เพิ่มขึ้น
โมเดลนี้ประกอบด้วยสามองค์ประกอบหลักที่ทำงานร่วมกัน
- Platform: โครงสร้างพื้นฐานสำหรับการรันระบบ governance และ integration
- Playbooks: pattern และ component ที่ผ่านการทดสอบจาก production deployment จริง
- FDE Talent Pool: ทีม Forward Deployed Engineers ที่พร้อม deploy ในหน่วยงานต่างๆ
Project กับ CoE แนวทางการสร้าง Value ที่แตกต่างกัน
ภายใต้งบประมาณระดับเดียวกัน โมเดล Project-based และ CoE-as-a-Service นำไปสู่ผลลัพธ์ที่แตกต่างกันในเชิงโครงสร้างในรูปแบบ Project-based องค์กรอาจดำเนินการได้ในจำนวน use case ที่จำกัด โดยมีช่วงเวลาหยุดชะงักระหว่างโครงการ และไม่เกิดการสะสมความรู้ระหว่าง use case แต่ละโครงการเริ่มต้นใหม่จากศูนย์ทุกครั้งที่มีการ re-scopeในรูปแบบ CoE-as-a-Service องค์กรสามารถดำเนินการ use case ได้มากขึ้นในช่วงเวลาเดียวกัน ระยะเวลาต่อ use case ลดลงตามลำดับเนื่องจากการสะสมของ Platform และ Playbooks
โครงสร้างราคาที่สอดคล้องกับการสร้าง Value
โมเดลราคาของ CoE-as-a-Service ประกอบด้วยสามส่วน
- Base: CoE Subscription (Annual Retainer) สำหรับการเข้าถึง Platform, Playbooks และทีม CoE leadership ตลอดปี
- Variable: FDE Capacity (Per Pod/Quarter) วิศวกรที่ deploy ใน active use case โดยปรับขนาด pod ได้ทุกไตรมาส
- Variable: Outcome Share (เปอร์เซ็นต์จาก measured value) สำหรับ use case ที่สามารถวัดผลกระทบได้โดยตรง เพื่อ align incentive ระหว่างทั้งสองฝ่าย
เมื่อเปรียบเทียบกับ pricing แบบ project ที่มักประกอบด้วย fixed scope, change order และ T&M overrun โครงสร้างราคาของ CoE-as-a-Service ออกแบบมาเพื่อรองรับการสะสม value ในระยะยาวมากกว่าการจ่ายตามขอบเขตงานครั้งเดียว
บทสรุป
ผู้ให้บริการในรูปแบบ project มักส่งมอบ deliverable ที่มีขอบเขตจำกัด ขณะที่ CoE-as-a-Service มุ่งส่งมอบ capability ที่ดำเนินงานต่อเนื่องและพัฒนาขึ้นตามเวลาสำหรับองค์กรที่กำลังพิจารณาแนวทาง AI Transformation ในระยะยาว การประเมินทางเลือกของโมเดลการทำงานมีความสำคัญไม่น้อยกว่าการเลือกเทคโนโลยี
