🛑 จาก “ผู้ว่าจ้าง” สู่ “ผู้ประสบภัย” ได้ยังไง?
เมื่อการซื้อบริการ…กลายเป็นการซื้อ “ภาระ”
ในโลกขององค์กรขนาดใหญ่ มีตลกร้ายเรื่องหนึ่งที่เกิดในหลายๆ องค์กร คือ
เรายอมเซ็นเช็คจ่ายเงินก้อนโต เพื่อจ้าง Vendor เข้ามา “ช่วย” ทำงานแต่สุดท้าย…คนในองค์กรกลับต้องมานั่งเป็น “นางแบก”
คอยตามงาน แก้ปัญหา เคลียร์ดราม่า และบางครั้ง…ทำงานแทนคนที่เราจ้างมา
“จ่ายเงินซื้อความสบาย…แต่ได้ความปวดหัวกลับมาแทน”
⸻
🇹🇭 Digital Transformation ที่กลายเป็น “Digital Trauma”?
ในช่วง 3–5 ปีที่ผ่านมา องค์กรไทยจำนวนมากเร่งทำ Digital Transformation
หนึ่งใน pattern ที่เกิดขึ้นบ่อยคือ
* เลือก Platform ระดับโลก (CRM / ERP / Data Platform)
* จ้าง Vendor ระดับ Top-tier หรือ Local Partner
* ตั้งเป้า Go-live ภายใน 6–12 เดือน บน slide นำเสนอ และสัญญา…ทุกอย่างดู “ถูกต้อง” ตาม Best Practice ทั้งเทคโนโลยี ทีม และ Roadmap
* แต่สิ่งที่หลายองค์กร “ประเมินต่ำไป” คือ ความซับซ้อนของการเปลี่ยนแปลงทั้งระบบ (System-level Change)
เพราะ Digital Transformation ไม่ใช่แค่ “เปลี่ยนระบบ” แต่คือการเปลี่ยน
* วิธีทำงานของคน
* โครงสร้างการตัดสินใจ
* และ Mindset ของทั้งองค์กร
แต่สิ่งที่เกิดขึ้นจริงในหลายองค์กรคือ
* Timeline มักเลื่อนไปอีก 2–3 เท่า (จาก 6 เดือน → 18 เดือน)
* Scope ถูกลดลง หรือตัดกลางทางเพื่อ “ให้จบ”
* User Adoption ต่ำ แม้ระบบจะ Go-live แล้ว
* และทีมภายใน “หมดแรง” ก่อนระบบจะเสร็จจริง
บางเคสจบด้วยการ “ใช้ระบบได้แค่ 30–40% ของศักยภาพ” เช่น
* CRM ถูกใช้แค่เก็บข้อมูลลูกค้า แต่ไม่เคยใช้ทำ segmentation หรือ personalization
* ERP ถูกใช้แทน Excel แต่ไม่ได้ integrate ข้ามหน่วยงาน
* Data Platform มีข้อมูลครบ แต่ไม่มีใคร “กล้าตัดสินใจจากข้อมูล”
สิ่งที่เกิดขึ้นจึงไม่ใช่แค่ “โปรเจกต์ล่าช้า” แต่คือ “โอกาสทางธุรกิจที่หายไป” และที่สำคัญ…คือความเชื่อมั่นของคนในองค์กรที่ค่อยๆ ลดลง
จากความหวัง → กลายเป็นความระแวง จากความตื่นเต้น → กลายเป็นความเหนื่อยล้า
สุดท้ายคำว่า Digital Transformation เลยกลายเป็นคำที่หลายคน “ไม่อยากได้ยินอีก”
ไม่ใช่เพราะของไม่ดี แต่เพราะ “ระบบการทำงานร่วมกันพังตั้งแต่ต้น”
⸻
📉 ข้ออ้างเหมือนๆ เดิมคือ?
1. Over Promise, Under Deliver
ตอนขาย = Vision ระดับโลก
ตอนทำ = Reality ระดับหน้างาน
Gap นี้คือจุดเริ่มต้นของ “ความไม่ไว้วางใจ” และมักขยายตัวเร็วมากเมื่อโปรเจกต์เริ่มเดิน
สิ่งที่เกิดขึ้นในทางปฏิบัติ
* Scope ถูก “ตีความใหม่” หลังเซ็นสัญญา
* Assumption ที่เคยพูดในห้อง Pitch ไม่ถูกบันทึกเป็นข้อผูกพัน
* Dependency สำคัญ (เช่น data readiness, integration) ถูกประเมินต่ำ
ผลลัพธ์คือ
ลูกค้าคิดว่า “ซื้อของครบ” แต่ Vendor คิดว่า “ขายเฉพาะบางส่วน”
ช่องว่างนี้จะกลายเป็น Change Request, Re-scope และ Delay ในที่สุด
2. Resource Bottleneck
"Vendor Scale Revenue แต่ไม่ Scale Capability"
ลูกค้ากลายเป็น “หนึ่งในหลายโปรเจกต์” ไม่ใช่ “โปรเจกต์สำคัญ”
ในทางปฏิบัติ ปัญหานี้มักแสดงออกเป็นสัญญาณดังนี้
* Key person เปลี่ยนกลางโปรเจกต์ (re-allocate ไปงานใหม่)
* Response time ช้าลงอย่างมีนัยยะ เมื่อ workload เพิ่ม
* งานที่ต้องใช้ expertise สูง ถูกส่งต่อให้ทีม junior
สิ่งที่องค์กรต้องเข้าใจคือ
Capacity ของ Vendor ไม่ได้เท่ากับ “ขนาดบริษัท” แต่เท่ากับ “จำนวนคนเก่งที่ว่างจริงในช่วงเวลานั้น”
เมื่อ Capacity ไม่พอ Vendor จะ “เลือก” โดยปริยายว่าโปรเจกต์ไหนควรได้ priority สูงกว่า
3. Capability Gap
“คิดว่าซื้อของระดับโลก” แต่ Implement ด้วยทีมที่ “ยังไม่เคยผ่านของจริงระดับนั้น”
ช่องว่างนี้ไม่ได้อยู่แค่เรื่องเทคนิค แต่รวมถึง
* การออกแบบ solution ให้ fit กับ business จริง
* การทำ change management กับผู้ใช้งาน
* การ translate requirement ที่ซับซ้อนให้เป็นระบบที่ใช้ได้จริง
อาการที่พบได้บ่อย คือ?
* ระบบทำงานได้ “ตาม spec” แต่ใช้จริงไม่ได้
* ต้องแก้ซ้ำหลายรอบ เพราะ design ไม่สอดคล้อง workflow
* เกิด workaround จำนวนมาก จนระบบเสียความเป็นมาตรฐาน
สุดท้ายองค์กรจะไม่ได้แค่ “ได้ของไม่เต็มศักยภาพ” แต่จะได้ “หนี้ทางเทคนิค + หนี้ทางองค์กร (organizational debt)” เพิ่มขึ้น "ซึ่งใช้เวลาหลายปีในการแก้ไข"
⸻
🚀 ถ้าไม่อยากเป็นเหยื่อ ต้องคิดแบบ “เจ้าของเกม” คือ?
สิ่งที่องค์กรส่วนใหญ่พลาด ไม่ใช่การเลือก Vendor ผิด
แต่คือ “ไม่มีระบบคิดในการบริหาร Vendor”
นี่คือ Framework ที่ควรใช้เป็น baseline ในยุคนี้
⸻
🧠 Phase 1: Pre-Deal (ก่อนเซ็นสัญญา)
จำไว้อย่าซื้อจาก PowerPoint ให้ซื้อจาก “Execution Capability”
สิ่งที่องค์กรจำนวนมากพลาด คือ “ตัดสินใจจากภาพลักษณ์” ไม่ใช่ “ศักยภาพการทำจริง”
เพราะในโลก Vendor
* Slide สามารถสวยได้เสมอ
* Case Study สามารถเลือกเล่าได้
* และ Sales มักถูก optimize ให้ “ปิดดีล” ไม่ใช่ “ส่งงานให้จบ”
* สิ่งที่ต้องทำจริงๆ คือการ “ลด illusion” และมองให้เห็นของจริงให้เร็วที่สุด
สิ่งที่ต้องทำ
* ขอทีมจริง (PM / Tech Lead) มา present ไม่ใช่แค่ Sales
→ เพื่อดูว่า “คนที่จะทำงานกับคุณจริง” เข้าใจโจทย์ลึกแค่ไหน ไม่ใช่แค่ตอบตาม script
* ขอ reference project ที่ “คล้ายกันจริง”
→ ไม่ใช่แค่ industry เดียวกัน แต่ต้องคล้ายทั้ง complexity, scale และบริบทการใช้งาน
* ตรวจสอบ capacity ของทีม (ไม่ได้ดูแค่ชื่อบริษัท)
→ ต้องถามตรงๆ ว่าทีมนี้ดูแลกี่โปรเจกต์อยู่ และมี resource dedicate ให้คุณกี่ %
สิ่งที่ควรถามเพิ่ม (แต่หลายองค์กรไม่เคยถาม)
* ถ้า Key person ลาออกหรือย้ายทีมกลางโปรเจกต์ จะมี backup plan อย่างไร?
* งานที่ยากที่สุดที่ทีมนี้เคยทำคืออะไร และแก้ปัญหายังไง?
* ตอนโปรเจกต์มีปัญหา ใครเป็นคนตัดสินใจสุดท้าย?
Insight สำคัญ คือ
Pre-Deal ไม่ใช่แค่ “เลือก Vendor” แต่คือ “ประเมินความเสี่ยงล่วงหน้า”
ถ้าคุณเห็นสัญญาณผิดปกติในช่วงนี้แล้ว “ยังตัดสินใจเดินต่อ”
อย่าแปลกใจ…ถ้าปัญหาเดียวกันจะ “ขยายใหญ่ขึ้น 10 เท่า” ในช่วง Execution
เพราะสิ่งที่คุณยอมรับในวันเซ็นสัญญา จะกลายเป็น “ต้นทุนที่คุณต้องจ่าย” ไปตลอดทั้งโปรเจกต์
⸻
🧪 Phase 2: Validation (ช่วง POC)
ให้ทดสอบ “คน + วิธีทำงาน” มากกว่า “ระบบ”
POC ที่ดีไม่ใช่แค่ Demo ว่าฟีเจอร์ทำงานได้
แต่ต้องเป็น “สนามทดลองความร่วมมือจริง” ก่อนเอาไปใช้ในสนามรบ
ต้องดูอะไรบ้าง (เชิงพฤติกรรมและระบบ)
* Response time ตอนมีปัญหา
→ วัดทั้ง “ความเร็ว” และ “คุณภาพคำตอบ” ว่าแก้ที่สาเหตุ (root cause) หรือแค่แก้ปลายเหตุ
* วิธี handle ambiguity (เมื่อสเปกไม่ชัด)
→ ทีมที่ดีจะตั้งคำถามกลับ ช่วย clarify และเสนอทางเลือก
ไม่ใช่รอคำสั่งจนงานหยุด
* ความสามารถในการ translate business → tech
→ เข้าใจ KPI ทางธุรกิจและแปลงเป็น solution ที่ใช้ได้จริง
ไม่ใช่ทำตาม requirement แบบ literal แล้วพังตอนใช้งานจริง
สัญญาณเชิงลึกที่ควรสังเกตเพิ่ม
* เวลามี issue ใครเป็นคน “own” ปัญหา และปิดงานได้เร็วแค่ไหน
* การสื่อสารข้ามทีม (Vendor ↔ Business ↔ IT) ลื่นหรือสะดุด
* การ commit timeline มี buffer และ realism หรือ optimistic เกินจริง
POC ที่ดี = Stress test relationship ก่อนลงสนามจริง
ถ้าในช่วงสั้นๆ ยังเห็น friction สูง
ให้ตีความว่า “ความเสี่ยงเชิงระบบ” ยังไม่ได้ถูกแก้
⸻
⚙️ Phase 3: Execution (ช่วงทำจริง)
"จำไว้ Control = ต้องอยู่ที่คุณ ไม่ใช่ Vendor"
ช่วง Execution คือช่วงที่ “ความจริงทั้งหมดจะถูกเปิดเผย”
ถ้าไม่มีระบบควบคุมที่ดี โปรเจกต์จะไหลไปตามแรงเฉื่อยของ Vendor ทันที
องค์กรต้องมีอะไร (ในเชิงโครงสร้าง)
* Internal PM ที่ “เก่งจริง”
→ เข้าใจทั้ง business + tech + stakeholder
และสามารถ challenge Vendor ได้บนข้อมูล ไม่ใช่ความรู้สึก
* Decision-making ที่เร็วและชัด
→ ลด loop การอนุมัติ
เพราะทุก delay = cost ที่เพิ่มขึ้นแบบทบต้น
* Governance ที่โปร่งใสและ enforce ได้
→ มี cadence การติดตาม (weekly/bi-weekly)
มี metric ชัดเจน ไม่ใช่ update แบบ subjective
กับดักที่ต้องระวังในช่วงนี้
* ปล่อยให้ Vendor “define success” แทนองค์กร
* ใช้ report ที่ดูดี แต่ไม่สะท้อนความจริง (vanity metrics)
* ปล่อย issue ค้าง เพราะ “เกรงใจ” หรือ “ยังพอไปได้”
ผลลัพธ์ที่ตามมาคือ control จะค่อยๆ หลุดโดยไม่รู้ตัว
เมื่อคุณปล่อย Vendor drive เกม
คุณจะไม่ได้แค่เสีย control แต่จะเสีย “อำนาจในการตัดสินใจเชิงกลยุทธ์” ไปด้วย
⸻
📊 Phase 4: Contract & Incentive Design
"Incentive ที่ผิด = ผลลัพธ์ที่พัง"
นี่คือ Phase ที่ “หลายองค์กรประมาทที่สุด”
เพราะคิดว่า Contract เป็นแค่เรื่องกฎหมาย แต่จริงๆ แล้ว…มันคือ “เครื่องมือออกแบบพฤติกรรมของ Vendor”
"จ่ายเงินตามเวลา = งานยิ่งช้า Vendor ยิ่งได้ประโยชน์"
* Time-based payment (เช่น จ่ายรายเดือน / ตาม man-day)
→ สร้างแรงจูงใจให้
* งานยืดออกได้
* Scope ไม่ถูก optimize
* และ Vendor ไม่มีเหตุผลเร่งให้จบเร็ว
เพราะทุกวันที่โปรเจกต์ยาวออก = รายได้เพิ่ม
สิ่งที่ต้องเปลี่ยนจาก “จ่ายตามเวลา” → “จ่ายตามคุณค่า”
* Outcome-based payment
* Milestone-based payment
คือการผูกเงินเข้ากับ “ผลลัพธ์” ไม่ใช่ “ความพยายาม”
ตัวอย่างเช่น
* Go-live สำเร็จ = จ่าย milestone
* User adoption ถึง threshold = จ่ายเพิ่ม
* Performance ตรง SLA = bonus / incentive เป็นต้น
⸻
องค์ประกอบสำคัญที่ต้องมี และต้อง enforce ได้จริง?
* SLA ที่วัดได้ (Measurable SLA)
→ เช่น response time, uptime, defect rate
ไม่ใช่คำกว้างๆ ที่ตีความได้หลายแบบ
ขยายความ
* ต้องกำหนด “นิยามการวัด” ให้ชัด (เช่น response time = นับตั้งแต่ ticket ถูกเปิดถึง first response ภายในกี่นาที)
* มี baseline และ target (เช่น P95 response time ≤ 30 นาที)
* มีระบบ monitoring กลางที่ทั้งสองฝ่ายเห็นตรงกัน (single source of truth)
* แยก SLA ตามระดับความรุนแรง (Severity 1–4) เพื่อไม่ให้ทุกอย่างถูก treat เท่ากัน
* Penalty ที่ enforce ได้จริง (ไม่ใช่แค่เขียนสวยๆ ไปงั้น)
→ ต้องมี impact ทางการเงินหรือสัญญาที่ Vendor “รู้สึกจริง”
ขยายความ
* ผูก penalty กับ SLA/Milestone โดยตรง (เช่น breach SLA เกิน X ครั้ง = หักค่าบริการ Y%)
* มีเพดานและขั้นบันได (tiered penalty) เพื่อสร้างแรงจูงใจให้ “แก้เร็ว” ไม่ใช่ยอมเสียเล็กน้อยแล้วปล่อยยาว
* ระบุเงื่อนไข “remedy” ชัดเจน (แผนแก้ไข/เวลาแก้ไข) ไม่ใช่แค่ค่าปรับ
* ระวัง penalty ที่เล็กเกินไปจน Vendor “เลือกจ่ายแทนการแก้”
* KPI ที่ align กับ business impact
→ เช่น conversion rate, system adoption, cycle time
ไม่ใช่แค่ deliver feature ครบตาม spec
ขยายความ
* แปลง KPI ธุรกิจเป็น KPI โครงการ (เช่น เพิ่ม conversion +2% → ต้องมี feature/experiment อะไร และวัดผลอย่างไร)
* วัดทั้ง “output + outcome” (ส่งมอบฟีเจอร์ครบ และผู้ใช้ใช้จริง/เกิดผลลัพธ์)
* กำหนด owner ของ KPI ชัด (Vendor/Client/Shared) เพื่อไม่ให้เกิดพื้นที่สีเทา
* มี cadence รีวิว KPI (weekly/bi-weekly) และกลไกปรับแผนเมื่อไม่ถึงเป้า
* ตัวอย่างเชิงปฏิบัติ
* Go-live: ผ่านเกณฑ์ UAT + defect critical = 0 → จ่าย milestone
* Adoption: active users ≥ 60% ภายใน 60 วัน → จ่าย incentive
* Performance: uptime ≥ 99.9% รายเดือน → bonus / หากต่ำกว่ามี penalty เป็นต้น
⸻
กับดักที่ต้องระวัง?
* KPI ที่วัด “output” แต่ไม่วัด “outcome”
→ เช่น ส่งงานครบ แต่ใช้งานไม่ได้
ขยายความ
* แยก “ส่งมอบเสร็จ” ออกจาก “สร้างผลลัพธ์ได้” (Delivery ≠ Impact)
* ผูก KPI กับพฤติกรรมผู้ใช้จริง (adoption, retention, conversion) ไม่ใช่แค่จำนวนฟีเจอร์
* ตั้งเกณฑ์ acceptance ที่สะท้อนการใช้งาน (เช่น task completion rate, time-to-value)
* ระวัง vanity metrics (จำนวน ticket ปิด, story point) ที่ดูดีแต่ไม่สะท้อนคุณค่า
* SLA ที่ไม่มี baseline หรือไม่มี monitoring จริง
→ วัดไม่ได้ = บังคับใช้ไม่ได้
ขยายความ
* ต้องมี baseline อ้างอิงก่อนเริ่ม (current performance) เพื่อเทียบการปรับปรุง
* ใช้เครื่องมือ monitoring กลางที่ audit ได้ (log/alert/report) และเข้าถึงได้ทั้งสองฝ่าย
* กำหนดวิธีเก็บข้อมูลและช่วงเวลาวัด (real-time / hourly / daily) ให้ชัด
* สร้าง ritual ตรวจ SLA (weekly review) เพื่อปิดช่อง “รู้ทีหลัง”
* Penalty ที่เล็กเกินไปจน Vendor “ยอมจ่าย” แทนการแก้ปัญหา
ขยายความ
* ออกแบบ penalty ให้ “แพงกว่าการไม่แก้” (cost of breach > cost of fix)
* ใช้โครงสร้างขั้นบันได (tiered) เพื่อเร่งการแก้ในช่วงต้น ไม่ปล่อยสะสม
* ผูก penalty กับเหตุการณ์สำคัญ (missed milestone, critical defect) ไม่ใช่เฉลี่ยทั้งโครงการ
* ควบคู่ incentive เชิงบวก (bonus) เพื่อสร้างสมดุล ไม่ใช่มีแต่บทลงโทษ
Insight สำคัญ
Contract ไม่ใช่เอกสารทางกฎหมาย แต่คือ “ระบบ incentive” ที่กำหนดว่า Vendor จะทุ่มเทหรือจะประคอง
ขยายความ คือ
* Incentive กำหนด “ทิศทางพฤติกรรม” มากกว่าคำสั่งหรือความสัมพันธ์
* คนเก่งจะ optimize ตามกติกาเสมอ—ถ้ากติกาเอื้อกำไรระยะสั้น คุณภาพระยะยาวจะถูกละเลย
* การ align incentive ทำให้ “ความตั้งใจดี” กลายเป็น “ผลลัพธ์ที่วัดได้”
ถ้าคุณออกแบบ incentive ผิด
Vendor ที่เก่ง…ก็จะ optimize เพื่อ “กำไรของเขา” ไม่ใช่ “ความสำเร็จของคุณ”
แต่ถ้าคุณออกแบบ incentive ถูก
Vendor จะกลายเป็น “partner ที่วิ่งไปในทิศทางเดียวกัน” โดยอัตโนมัติ
⸻
🧭 ข้อควรจำคือปัญหานี้ไม่ใช่ “Vendor Problem” แต่คือ “System Design Problem”
Vendor ไม่ได้ตั้งใจจะทำงานแย่ และส่วนใหญ่ก็ไม่ได้เริ่มต้นด้วยเจตนาที่จะเอาเปรียบ
แต่ในความเป็นจริง พวกเขากำลัง “optimize ระบบธุรกิจของตัวเอง” อยู่ตลอดเวลา เช่นเดียวกับที่องค์กรของคุณทำ
สิ่งที่ Vendor กำลัง optimize คือ
* เพิ่มรายได้ (maximize revenue per project)
* ลดต้นทุน (minimize cost / headcount)
* กระจาย resource ให้เกิด utilization สูงสุด
* ลดความเสี่ยงของตัวเอง (risk transfer กลับมาที่ลูกค้า)
เมื่อ incentive ถูกตั้งแบบนี้ พฤติกรรมที่ตามมาจะ “คาดเดาได้” เช่น
* รับงานเพิ่ม แม้ capacity ไม่พอ → เพื่อไม่ให้พลาดรายได้
* ส่งงานตาม spec ขั้นต่ำ → เพื่อควบคุมต้นทุน
* เลี่ยงงานที่มีความไม่ชัดเจนสูง → เพื่อไม่ให้เกิด cost overrun
* ผลัก dependency กลับมาที่ลูกค้า → เพื่อรักษา timeline ของตัวเอง
สิ่งเหล่านี้ไม่ใช่ “นิสัยไม่ดีของ Vendor”
แต่คือ “ผลลัพธ์ตามธรรมชาติของระบบ incentive ที่ถูกออกแบบไว้”
ดังนั้น ประเด็นจริงไม่ใช่ว่า Vendor ดีหรือไม่ดี
แต่คือ
ระบบที่คุณออกแบบ…กำลัง “บังคับให้เขาทำงานดี” หรือ “เปิดช่องให้เขา optimize เข้าข้างตัวเอง”?
ตัวอย่างให้เห็นภาพชัด
* ถ้าสัญญาเป็น Time-based → Vendor มีแรงจูงใจ “ยืดเวลา”
* ถ้า KPI วัดแค่การส่งมอบ → Vendor มีแรงจูงใจ “ส่งให้ครบ แต่ไม่ต้องดีที่สุด”
* ถ้าไม่มี SLA ชัด → Vendor มีอิสระในการ prioritize งานของคุณต่ำลง
Insight เชิงระบบที่สำคัญ
* คนเก่งไม่ได้ทำงานตาม “สิ่งที่คุณคาดหวัง” แต่ทำตาม “สิ่งที่ระบบให้รางวัล”
* ระบบที่ไม่ชัด จะเปิดช่องให้การตีความ (interpretation gap) ขยายตัว
* และทุกช่องว่าง จะถูกแปลงเป็น “ต้นทุนของลูกค้า” ในที่สุด
เพราะฉะนั้น การบริหาร Vendor ที่ดี ไม่ใช่การ “หวังให้เขาดี”
แต่คือการ “ออกแบบระบบที่ทำให้เขา ‘ต้อง’ ทำงานดีโดยอัตโนมัติ”
⸻
✨ องค์กรมีแค่เงินจะเอาแต่คิดว่า “จ้าง Vendor เก่ง” เท่านั้น…แต่ “ออกแบบเกมเก่ง”
“ในโลกที่ทุกอย่าง outsource ได้” ความได้เปรียบไม่ได้อยู่ที่ “ใครมี Vendor ดีกว่า” แต่อยู่ที่
* ใครออกแบบกติกาได้ดีกว่า
* ใครควบคุม incentive ได้แม่นกว่า
* และใครเข้าใจเกมนี้ลึกกว่า
เพราะสุดท้ายแล้ว
Vendor จะทำงานตาม “สิ่งที่คุณออกแบบไว้” ไม่ใช่ตาม “สิ่งที่คุณหวังไว้”
#วันละเรื่องสองเรื่อง #VendorManagement #ExecutiveMindset #ProjectGovernance #BusinessStrategy #VendorSurvivalSeries
⸻
📚 Source / Reference
* The Standish Group (CHAOS Report): รายงานการวิจัยระดับโลกด้านการบริหารจัดการโครงการ IT ที่ชี้ให้เห็นว่า ปัจจัยหลักอันดับต้นๆ ที่ทำให้โปรเจกต์ประสบความล้มเหลว (Failure or Challenged) มักเกิดจากการสื่อสารความต้องการที่ผิดพลาด (Poor Requirements) และการบริหารจัดการผู้มีส่วนได้ส่วนเสีย/เวนเดอร์ (Vendor Mismanagement) ที่ขาดความรัดกุมตั้งแต่ต้นทาง
* แนวปฏิบัติ Vendor Governance จากองค์กรขนาดใหญ่ในไทย (ประสบการณ์ภาคสนามในโครงการ Digital Transformation)
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
