สรุปจากเอกสารทางการของ Microsoft (Dynamics 365 Implementation Guide) ฉบับอัปเดตมิถุนายน 2026 ซึ่งต่างจากที่หลายคนเคยอ่านเมื่อ 2-3 ปีก่อนพอสมควร โดยเฉพาะส่วนที่เกี่ยวกับ AI
ปัญหาที่กรอบนี้เกิดมาเพื่อแก้
โปรเจกต์ ERP ที่ล้ม ส่วนใหญ่ไม่ได้ล้มตอน go-live มันล้มไปแล้วตั้งแต่ตอนออกแบบ แค่ยังไม่มีใครรู้ตัว
Microsoft เห็นเรื่องนี้ซ้ำจนกลายเป็นแบบแผน ตอนที่ Dynamics 365 โตขึ้นเรื่อย ๆ ข้อสรุปหนึ่งที่ได้คือ การออกแบบฟีเจอร์ให้ดีอย่างเดียวไม่พอ ต้องเข้าใจด้วยว่าการส่งมอบระบบที่ใช้งานได้จริงตั้งแต่ต้นจนจบบนธุรกิจของลูกค้า ต้องใช้อะไรบ้าง
Microsoft นิยาม Success by Design ตรง ๆ ว่าเป็น the sum of Microsoft's Dynamics 365 implementation experience คือผลรวมของประสบการณ์ implement ทั้งหมดที่มี กลั่นจากโปรเจกต์ลูกค้าจริงหลายพันโปรเจกต์ผ่านทีม FastTrack
และเป้าหมายที่ประกาศไว้ชัดเจนคือ democratize the practice of Success by Design เอาของที่เคยมีแต่ทีม FastTrack ใช้ ออกมาเปิดให้ partner, ISV และลูกค้าเองใช้ได้
มันคืออะไร และไม่ใช่อะไร
เรื่องนี้เข้าใจผิดกันบ่อยที่สุด เลยต้องเคลียร์ก่อน
- ไม่ใช่ methodology: Microsoft พูดเองว่ามันเป็น adjunct คือของที่เอาไปเสริมวิธีทำงานที่ทีมใช้อยู่ ไม่ได้มาแทน ใช้ Agile อยู่ก็ใช้ต่อ ใช้ Waterfall ก็ใช้ต่อ
- ไม่ใช่ checklist ตอนจบ: ไม่ใช่แบบฟอร์มที่กรอกก่อน go-live หนึ่งอาทิตย์แล้วถือว่าผ่าน
- ไม่ใช่การรับประกันผลลัพธ์: เอกสารเขียนไว้ตรง ๆ ว่ามัน doesn't guarantee implementation outcomes
สิ่งที่มันเป็นคือกรอบการทบทวนดีไซน์อย่างมีระบบ ที่วางจุดตรวจไว้ตามช่วงชีวิตของโปรเจกต์ พร้อมคำถามที่บังคับให้ทีมคุยเรื่องยาก ๆ ในวันที่ยังแก้ทัน
Microsoft อธิบายว่า review คือแบบฝึกหัดของ 3 อย่าง: reflection (ทบทวน), discovery (สังเกตให้เห็นสิ่งที่มองข้าม) และ alignment (จับสิ่งที่เห็นไปเทียบกับแบบแผนที่รู้อยู่แล้วว่าจบยังไง)
ต้นทุนของการแก้ไขเพิ่มขึ้นตามระยะเวลาที่ปัญหาถูกค้นพบช้า และเพิ่มแบบไม่เป็นเชิงเส้น กรอบทั้งหมดถูกออกแบบมาบนสมมติฐานข้อนี้
เหตุผลที่ต้นทุนไม่เพิ่มแบบเชิงเส้น อยู่ที่จำนวนสิ่งที่ผูกกับการตัดสินใจนั้นไปแล้ว การเปลี่ยนโครงสร้างข้อมูลในสัปดาห์แรกกระทบเฉพาะตัวโครงสร้างเอง เพราะยังไม่มีอะไรอ้างอิงถึงมัน
การเปลี่ยนเรื่องเดียวกันในช่วง UAT กระทบสิ่งที่ผูกไว้แล้วทั้งหมด คือโค้ดที่เขียนไปแล้ว ข้อมูลที่คีย์เข้าระบบ รายงานที่อ้างโครงสร้างเดิม และรอบทดสอบที่ต้องทำซ้ำ
หลัง go-live มีตัวแปรเพิ่มอีกชั้นคือข้อมูลจริงที่ถูกใช้อ้างอิงภายนอกไปแล้ว ในบริบทของธุรกิจไทยหมายรวมถึงเอกสารที่ยื่นต่อกรมสรรพากร การแก้จึงไม่ใช่การแก้ระบบอย่างเดียว แต่เป็นการย้ายข้อมูลบนระบบที่มีผู้ใช้งานอยู่
Microsoft ระบุแรงกดดัน 3 อย่างที่ทำให้ทีมข้ามการทบทวนนี้ คือ เวลา งบประมาณ และกำลังคน ข้อสังเกตคือทั้งสามอย่างเป็นข้อจำกัดที่มีอยู่ในทุกโปรเจกต์ กรอบนี้จึงไม่ได้เสนอให้กำจัดข้อจำกัด แต่เสนอให้ตรึงจุดตรวจไว้ล่วงหน้าเพื่อไม่ให้ข้อจำกัดเป็นตัวตัดสินว่าจะทบทวนหรือไม่
5 ช่วงของโปรเจกต์ (ไม่ใช่ 4)
ข้อนี้คนจำผิดบ่อย เพราะฉบับเก่ามี 4 ช่วง ฉบับปัจจุบันเพิ่ม Discover เข้ามาเป็นช่วงแรก
Discover: ค้นให้เจอก่อนลงมือ
เก็บและ validate ความต้องการทางธุรกิจ สรุปแนวทางระดับสูงว่าระบบจะไปทางไหน รวมถึง environment strategy และ organizational strategy
จุดที่ฉบับใหม่เน้นมากคือ Solution Blueprint Review ต้องเริ่มตั้งแต่ช่วง Discover ห้ามรอไปทำตอน Initiate เหตุผลที่ให้ไว้คือ ต้องดึงความเสี่ยงเชิงสถาปัตยกรรมขึ้นมาให้เห็นก่อนที่การตัดสินใจเรื่องดีไซน์จะแพงเกินกว่าจะย้อนกลับ
Initiate: ปักหมุดขอบเขต
กำหนด workstream ทั้งหมดที่อยู่ในขอบเขต ปรับแผนโปรเจกต์ให้ตรง และทำ Solution Blueprint ให้จบ
Implement: ลงมือสร้าง
สร้างตามดีไซน์และขอบเขตที่ตกลง ระหว่างทางมี Implementation Reviews เจาะเป็นเรื่อง ๆ ตามความเสี่ยงที่เจอจากรอบแรก เช่น data model, security, integration, ALM, testing strategy
Microsoft ระบุจังหวะไว้ชัดว่าต้องทำ หลัง Solution Blueprint Review แต่ ก่อน ที่การ build จะไปไกลเกินแก้
Prepare: เตรียมขึ้นจริง
สร้างเสร็จ เทสเสร็จ กำลังเข้า UAT รอบสุดท้ายและเทรน ต้องมีครบทั้งการอนุมัติจากลูกค้า, information security review, cutover plan พร้อมเกณฑ์ go/no-go, mock go-live, support model และ deployment runbook ที่ระบุงาน เจ้าของ ระยะเวลา และลำดับการพึ่งพา แล้วจึงทำ Go-live Readiness Review
Operate: หลังขึ้นระบบ
เป้าหมายคือทำให้นิ่ง แล้วค่อยเปลี่ยนโฟกัสไปที่ฟีเจอร์เฟสถัดไป
Review 3 แบบ
| Review | บังคับไหม | ทำเมื่อไหร่ |
|---|---|---|
| Solution Blueprint Review | บังคับ | เริ่มที่ Discover เป็นจุดตั้งต้นของทั้งกรอบ |
| Implementation Reviews | ตามความเสี่ยงที่เจอ | ระหว่าง Implement |
| Go-live Readiness Review | บังคับ | Prepare ด่านสุดท้ายก่อนขึ้นจริง |
จุดที่ควรสังเกตคือ Implementation Reviews ไม่ได้มีรายการตายตัว มันงอกมาจากสิ่งที่เจอใน Solution Blueprint Review โปรเจกต์ที่ integration เยอะก็เจาะ integration โปรเจกต์ที่ custom หนักก็เจาะ ALM กับ testing
Microsoft ย้ำด้วยว่า review ไม่ใช่พิธีกรรมลอย ๆ ที่แยกจากโปรเจกต์ การจะจัด review ได้ต้องมี artifact จริง ของโปรเจกต์พร้อม และทีมพร้อมคุยเรื่องนั้นจริง ๆ ไม่งั้นคือการนั่งประชุมเปล่า
ผลลัพธ์ของ review: findings 3 ประเภท
ตรงนี้มีประโยชน์มากและเอาไปใช้ได้ทันที แม้ไม่ได้ทำ Success by Design เต็มรูปแบบ
| ประเภท | ความหมาย |
|---|---|
| Assertions | สิ่งที่ทีมทำถูกแล้ว ตรงกับแนวปฏิบัติที่ดี บันทึกไว้ด้วย ไม่ใช่จดแต่ปัญหา |
| Risks | ยังไม่กระทบตอนนี้ แต่ถ้าไม่จัดการจะกระทบแน่ |
| Issues | กระทบอยู่แล้ว หรือกำลังจะกระทบถ้าไม่แก้ |
การแยก Risk ออกจาก Issue สำคัญกว่าที่คิด เพราะสองอย่างนี้ต้องการการตัดสินใจคนละแบบ Risk คือเรื่องที่ตัดสินใจว่าจะรับไว้หรือปิด ส่วน Issue คือเรื่องที่ต้องหาคนทำและกำหนดวันเสร็จ
และการมี Assertions อยู่ในระบบ คือสิ่งที่ทำให้ review ไม่กลายเป็นเวทีจับผิด
เคสตัวอย่างจากเอกสาร Microsoft
บริษัทท่องเที่ยวองค์กรระดับโลกแห่งหนึ่ง implement Dynamics 365 Customer Service เพื่อยกเครื่อง call center
ระหว่างเก็บ requirement ทีมพบว่าต้องต่อกับระบบเก่าหลายตัวที่ transaction เยอะมาก และมี customization ที่ธุรกิจยืนยันว่าต้องมี ทำด้วยของมาตรฐานไม่ได้
ตอนเตรียม Solution Blueprint Review ทีมต้องยืนยันเรื่องหนึ่ง คือ performance testing ถูกตัดออกจากขอบเขตโปรเจกต์ ด้วยเหตุผลว่าคลาวด์ของ Microsoft น่าจะเร็วอยู่แล้ว ทั้งที่ระบบนี้จะรองรับ 4,000 users พร้อม integration หลายตัวและ customization หลัก
Finding จึงชัดเจนว่าการตัด performance testing ออกคือ Risk สถาปนิกที่นำ review เสนอให้ Steering Committee อนุมัติเพิ่ม performance testing กลับเข้าไปในรอบเทส
Microsoft รับผิดชอบให้ cloud service เร็วและเสถียรก็จริง แต่ดีไซน์ การตั้งค่า customization และ solution ของ partner ที่ใส่เข้าไป ล้วนมีผลต่อ performance ของระบบโดยรวม
Success Measures: วัดสุขภาพโปรเจกต์
Success by Design ให้ติดตามสุขภาพโปรเจกต์ผ่าน 7 หมวด กว่า 30 ตัวชี้วัด ครอบคลุมตั้งแต่ architecture, การ implement, ความเข้ากันของ product, project governance, ความสามารถของทีม ไปจนถึง support
วิธีวัดง่ายมาก หลัง review หรือหลังเหตุการณ์สำคัญ สถาปนิกอัปเดตสถานะเป็นแดง เหลือง หรือเขียว พร้อมรายละเอียด
ที่มันมีค่าคือมันอ่านได้สองระดับ
- ระดับโปรเจกต์เดียว: ผู้บริหารเหลือบดูครั้งเดียวรู้เลยว่าสุขภาพเป็นยังไง
- ระดับหลายโปรเจกต์: พอดู 20-100 โปรเจกต์พร้อมกันจะเห็นแบบแผน เช่นถ้า ALM แดงเกือบทุกโปรเจกต์ นั่นไม่ใช่ปัญหาของโปรเจกต์ใดโปรเจกต์หนึ่ง แต่เป็นปัญหาของ product หรือของวิธีทำงาน
ของใหม่ปี 2026: Success by Design ในยุค AI
ส่วนนี้คือสิ่งที่คนที่อ่าน Success by Design เมื่อ 2-3 ปีก่อนจะไม่เคยเห็น และเป็นส่วนที่เปลี่ยนเยอะที่สุด
จาก review เป็น Living Solution Blueprint
เดิม Solution Blueprint Review คือ workshop ที่จัดเป็นจุด ๆ ตาม milestone ฉบับใหม่ขยับไปเป็น Living Solution Blueprint คือเอกสารที่มีชีวิต อัปเดตต่อเนื่องจาก telemetry, transcript การประชุม, artifact ในโปรเจกต์ และการวิเคราะห์ของ agent
| หลักการ | เดิม | ใหม่ |
|---|---|---|
| Solution blueprint | รีวิวเป็นจุด ๆ | เอกสารมีชีวิต ปรับต่อเนื่อง |
| Workshop | ตายตัว ตามตาราง | ต่อเนื่อง ขับด้วยข้อมูลและ AI |
| คำแนะนำ | คนล้วน ทำมือ | agent เสนอแบบไดนามิก |
| การจับความเสี่ยง | ตั้งรับ ตอนจบเฟส | เชิงรุก เรียลไทม์ตลอดโปรเจกต์ |
Microsoft ย้ำชัดว่าสิ่งนี้ ไม่ได้มาแทน review ที่เป็นทางการ แต่มาเติมข้อมูลให้ review คมขึ้น และมีอีกประโยคที่สำคัญมากคือ การเปลี่ยนไปใช้ AI ช่วย ไม่ได้ลดความรับผิดชอบของคน ทีมยังต้องตรวจสิ่งที่ agent ตอบ กำหนดขอบเขตและสิทธิ์เข้าถึงข้อมูลของ agent และดูแลมันตลอดโปรเจกต์
หลักการออกแบบสำหรับ agent
- Integrate agents: มอง agent เป็นส่วนหนึ่งของสถาปัตยกรรมตั้งแต่แรก ไม่ใช่ของแถมที่ค่อยแปะทีหลัง
- Embrace agent-first experiences: ออกแบบกระบวนการโดยคิดเผื่อว่าบางขั้นตอน agent จะทำเอง
- Model business processes for agents: ออกแบบให้ครอบคลุมการทำงานร่วมกันของคนกับ agent รวมถึงการจัดการข้อยกเว้นและเส้นทางส่งต่อให้คน
ระดับความพร้อมด้าน AI 4 ระดับ
| ระดับ | สภาพ |
|---|---|
| 1 - Human first | คนทำเอง AI ยังไม่อยู่ในกระบวนการ |
| 2 - Copilot assisted | AI ช่วยเสนอแนะ คนตัดสินใจ |
| 3 - Humans with agents | agent ทำงานย่อยได้เอง คนสั่งและตรวจ |
| 4 - Agent first with human oversight | agent เดินกระบวนการเอง คนเฝ้าและเข้าแทรกเมื่อจำเป็น |
ประโยชน์ของตารางนี้คือมันทำให้คุยกันรู้เรื่องว่าองค์กรเราอยู่ระดับไหน ก่อนจะไปตั้งเป้าเรื่อง AI ในโปรเจกต์ องค์กรที่ยังอยู่ระดับ 1 แล้วตั้งเป้าไประดับ 4 ในโปรเจกต์เดียว คือการตั้งเป้าให้ตัวเองล้ม
agent ที่มีมาให้แล้วใน Business Central
Microsoft ใส่ agent มาให้ในตัวสินค้าแล้วหลายตัวทุก workload สำหรับ Business Central ที่ระบุไว้คือ Sales Order Agent และ Payables Agent และองค์กรยังต่อยอด agent ของ Microsoft หรือสร้างเองด้วย Copilot Studio ได้
สิ่งที่ต้องเพิ่มในแต่ละช่วง ถ้าโปรเจกต์มี AI
- Discover: จัดลำดับ use case ที่คุ้มที่สุด ประเมินระดับความพร้อม AI ประเมินความพร้อมของข้อมูล และดูข้อกำหนดด้านกำกับดูแล
- Initiate: นิยามขอบเขต agent ให้ชัดว่าอันไหนทำอะไร ขอบเขตแค่ไหน ส่งต่อให้คนเมื่อไหร่ ทำ responsible AI review และออกแบบจุดที่ต้องมีคนอนุมัติ
- Implement: ทำ evals ทดสอบพฤติกรรม agent ก่อนเอาเข้ากระบวนการจริง วางแผนรับมือกับความจริงที่ว่า AI ตอบไม่เหมือนเดิมทุกครั้ง และตรวจสิทธิ์เข้าถึงข้อมูลตามหลัก least privilege
- Prepare: ทดสอบกับข้อมูลที่เหมือนของจริง เซ็นรับความเสี่ยง AI อย่างเป็นทางการ มี monitoring พร้อมก่อนขึ้น และมีแผนรับมือเมื่อ agent ทำตัวผิดปกติ
- Operate: เฝ้าดูพฤติกรรม agent ต่อเนื่อง โดยเฉพาะหลัง platform อัปเดต รัน eval ซ้ำเป็นรอบ ๆ และขยายขอบเขตเมื่อพิสูจน์แล้วว่าเชื่อถือได้
ตัวชี้วัดเพิ่มสำหรับโปรเจกต์ AI ก็มีเป็นชุด ทั้งความพร้อมของ agent, คุณภาพของ eval, สุขภาพการทำงาน (uptime และอัตราการโยนกลับให้คน), ผลกระทบต่อธุรกิจ และ responsible AI
แล้ว SME ไทยที่ทีมมีสามคนล่ะ
คำถามที่ต้องเจอแน่นอนคือ กรอบของ Microsoft มันสำหรับองค์กรใหญ่ไม่ใช่เหรอ
ใช่และไม่ใช่
รูปแบบการจัดรีวิวไม่สเกลลงมาโดยตรง โปรเจกต์ระดับ 4,000 users ตามเคสในเอกสารมีเวิร์กช็อปเต็มวันและมี Steering Committee ซึ่งเป็นต้นทุนที่ไม่สมเหตุสมผลกับโปรเจกต์ 15 users
แต่คำถามเป็นคำถามเดียวกัน โปรเจกต์เล็กก็ต้องรู้ว่า custom ตัวไหนจำเป็น ข้อมูลเก่าย้ายมาแค่ไหน ใครเทส ใครดูแลต่อ ระบบจะช้าไหมตอนปิดงวด ต่างกันที่รูปแบบ ไม่ใช่เนื้อหา
- โปรเจกต์ 200 users: Solution Blueprint Review เต็มรูปแบบ
- โปรเจกต์ 15 users: ประชุมสองชั่วโมง ถามคำถามชุดเดิม จดเป็นเอกสารหน้าเดียว แล้วแยก finding เป็น assertion, risk และ issue ให้ชัด
ส่วนนี้เป็นความเห็นจากประสบการณ์ ไม่ได้มาจากเอกสาร Microsoft สิ่งที่ทีมขนาดเล็กมักขาดไม่ใช่กระบวนการทบทวน แต่คือการบันทึกข้อตกลงให้ชัดว่าตกลงอะไรไว้ และการกำหนดจังหวะกลับมาตรวจว่าข้อตกลงนั้นยังใช้ได้อยู่หรือไม่ ประโยชน์ของเอกสารจึงขึ้นกับว่ามีคนอ่านมันหรือเปล่า มากกว่าความยาวของมัน
สรุป
สิ่งที่ Success by Design ให้ไม่ใช่การรับประกันผลลัพธ์ เอกสารระบุเรื่องนี้ไว้เอง สิ่งที่มันให้คือการกำหนดจุดตรวจไว้ล่วงหน้า พร้อมชุดคำถามที่ต้องตอบ ณ จุดนั้น และรูปแบบการบันทึกผลที่แยกประเภทของสิ่งที่พบออกจากกัน
คุณค่าของการตรึงจุดตรวจไว้ล่วงหน้าอยู่ที่มันทำให้การทบทวนไม่ขึ้นกับว่าใครในทีมกล้าตั้งคำถามในวันนั้น คำถามว่า custom ตัวนี้จำเป็นหรือไม่ ให้ผลต่างกันมากเมื่อถูกถามในสัปดาห์ที่สาม เทียบกับตอนที่มันถูกสร้างไปแล้ว และความต่างนี้ไม่ได้มาจากตัวคำถาม แต่มาจากจำนวนสิ่งที่ผูกกับคำตอบไปแล้ว
ข้อจำกัดที่ควรระบุไว้ด้วยคือกรอบนี้ตั้งอยู่บนสมมติฐานว่ามี artifact ของโปรเจกต์พร้อมให้ทบทวน โปรเจกต์ที่ยังไม่มีเอกสารดีไซน์ในรูปแบบใดเลย จะยังไม่ได้ประโยชน์จากการจัดรีวิว จนกว่าจะมีสิ่งที่เอามาวางบนโต๊ะได้ก่อน
เอกสารปิดท้ายด้วยข้อสังเกตว่า แม้แต่ลูกค้าและ partner ที่มีประสบการณ์สูงและมี methodology ของตัวเองอยู่แล้ว ก็ยังได้ประโยชน์จากการนำ Success by Design เข้าไปใช้ร่วม ซึ่งสอดคล้องกับการที่ Microsoft นิยามมันเป็น adjunct ไม่ใช่ methodology ที่มาแทนของเดิม
อ้างอิง: Microsoft Learn: Introduction to the Success by Design framework (อัปเดต 23 มิถุนายน 2026), Success by Design training modules และ FastTrack for Dynamics 365
กำลังจะเริ่มโปรเจกต์ Business Central อยู่ไหม?
นัดคุยเพื่อทบทวนดีไซน์และขอบเขตก่อนลงมือ ในวันที่การแก้ยังราคาถูก
ปรึกษาเรื่องโปรเจกต์ →