Gartner101-06 อ่าน Magic Quadrant อย่างไรไม่ให้เลือก Vendor ผิด
อ่าน Magic Quadrant อย่างไรไม่ให้เลือก Vendor ผิด จาก Gartner Leader สู่ Vendor ที่เหมาะกับองค์กร
ในตอนที่ผ่านมาเราได้ทำความรู้จัก Gartner Magic Quadrant และเข้าใจความหมายของ Leaders, Challengers, Visionaries และ Niche Players รวมถึงสองแกนสำคัญคือ Ability to Execute และ Completeness of Vision แต่การรู้ว่า Vendor อยู่ Quadrant ใดยังไม่เพียงพอสำหรับการตัดสินใจเลือกเทคโนโลยี เพราะความผิดพลาดที่เกิดขึ้นบ่อยที่สุดคือการนำ Magic Quadrant มาใช้เป็น “ตารางจัดอันดับ Vendor” แล้วสรุปว่า Leader คือดีที่สุด และ Vendor ที่อยู่ขวาบนที่สุดคือคำตอบที่ดีที่สุดขององค์กร
ความจริงแล้ว Gartner ระบุชัดว่า Magic Quadrant ไม่ได้เป็นการรับรอง Vendor, Product หรือ Service ใด และไม่ได้แนะนำให้ผู้ใช้เลือกเฉพาะ Provider ที่มี Rating สูงสุด Gartner ยังชี้ด้วยว่า Providers ใน Challengers, Visionaries หรือ Niche Players อาจเหมาะสมกับความต้องการขององค์กรบางแห่งมากกว่า Leaders
ดังนั้นคำถามที่ควรถามจึงไม่ใช่ “Vendor ไหนดีที่สุดใน Gartner?” แต่คือ “Vendor ไหนเหมาะสมที่สุดกับองค์กรของเรา?” ความแตกต่างของสองคำถามนี้คือหัวใจของ Gartner101-06 Magic Quadrant ควรใช้เป็น “แผนที่ตลาด” ไม่ใช่ “คำตอบสุดท้าย” ลองนึกถึง Magic Quadrant เหมือนแผนที่เมือง แผนที่ช่วยให้เราเห็นว่ามีถนนอะไร สถานที่สำคัญอยู่ตรงไหน และมีเส้นทางใดให้เลือก แต่แผนที่ไม่ได้ตัดสินใจแทนเราว่าควรไปที่ไหน
Magic Quadrant ก็เช่นเดียวกัน
มันช่วยให้เราเห็น Vendor Landscape ของตลาดหนึ่งตาม Market Definition และ Evaluation Criteria ของ Gartner แต่ไม่ได้รู้รายละเอียดทั้งหมดขององค์กรเรา เช่น Budget, Existing Architecture, Data, Skills, Procurement Rules, Security Requirements, Local Support หรือ Business Strategy
ดังนั้น Gartner สามารถบอกเราได้ว่า “ตลาดมีลักษณะอย่างไร และ Provider แต่ละรายมีตำแหน่งอย่างไรตาม Methodology นี้”
แต่คำถามว่า “ใครเหมาะกับเรา?” องค์กรต้องตอบเอง
ขั้นที่ 1: เริ่มจาก Market Definition
ก่อนดูว่ามี Vendor ใดอยู่ใน Leaders Quadrant สิ่งแรกที่ควรอ่านคือ Market Definition
คำถามคือ Gartner กำลังนิยามตลาดนี้ว่าอะไร? นี่เป็นเรื่องสำคัญมาก เพราะชื่อของ Magic Quadrant อาจคล้ายกับสิ่งที่เรากำลังหา แต่ Scope จริงอาจไม่ตรงกันทั้งหมด
ตัวอย่างเช่น องค์กรอาจต้องการ “ระบบรักษาความปลอดภัยเครือข่าย” แต่ตลาด Cybersecurity มีผลิตภัณฑ์หลายประเภท ทั้ง Network Security, Endpoint Security, Identity, SASE, Security Operations และอื่น ๆ
หากเลือก Magic Quadrant ผิดตลาด ต่อให้เลือก Leader ก็อาจได้ Solution ที่ไม่ตรงกับ Problem ตั้งแต่ต้น
ดังนั้นต้องเริ่มจาก
Business Problem → Technology Category → Market Definition
ไม่ใช่
Magic Quadrant → Leader → Product
ขั้นที่ 2: อ่าน Inclusion Criteria
คำถามต่อไปคือ Vendor ต้องมีคุณสมบัติอะไรจึงจะถูกนำมาประเมินใน Magic Quadrant ฉบับนี้? Gartner กำหนด Inclusion Criteria สำหรับงานวิจัยแต่ละตลาด ดังนั้นการที่ Vendor ไม่ปรากฏอยู่ในกราฟไม่ได้หมายความว่า Vendor นั้นไม่มีคุณภาพ อาจเป็นเพราะ Revenue ไม่ถึงเกณฑ์ Coverage ไม่ตรงกับตลาด Geographic Presence ไม่เพียงพอ Product ไม่ตรงกับ Market Definition หรือมีเหตุผลอื่นตาม Inclusion Criteria ของงานวิจัยนั้น
หลักคิดที่ต้องจำคือ Not Included ≠ Bad Vendor
โดยเฉพาะในประเทศไทย เราอาจพบ Local Vendor หรือ Regional Vendor ที่ตอบโจทย์ได้ดีมาก แต่ไม่เข้า Inclusion Criteria ของ Magic Quadrant ระดับโลก หากองค์กรตัด Vendor เหล่านี้ออกเพียงเพราะ “ไม่มีชื่อใน Gartner” ก็อาจเสียตัวเลือกที่เหมาะสมไปโดยไม่จำเป็น
ขั้นที่ 3: เข้าใจ Evaluation Criteria
Magic Quadrant ประเมิน Provider ผ่านสองมิติหลัก ได้แก่ Ability to Execute และ Completeness of Vision แต่ภายในแต่ละมิติประกอบด้วยเกณฑ์ย่อยหลายรายการ ตัวอย่างเกณฑ์มาตรฐานในด้าน Ability to Execute อาจประกอบด้วย Product or Service, Overall Viability, Sales Execution/Pricing, Market Responsiveness/Record, Marketing Execution, Customer Experience และ Operations
ส่วน Completeness of Vision อาจพิจารณา Market Understanding, Marketing Strategy, Sales Strategy, Offering Strategy, Business Model, Vertical/Industry Strategy, Innovation และ Geographic Strategy สิ่งสำคัญคือ เกณฑ์ของ Gartner ไม่จำเป็นต้องมีน้ำหนักเหมือนเกณฑ์ขององค์กรเรา
Gartner อาจให้ความสำคัญกับ Global Presence แต่เราอาจให้ความสำคัญกับ Local Support
Gartner อาจมอง Vision ระยะยาว แต่โครงการของเราอาจให้ความสำคัญกับการติดตั้งภายใน 6 เดือน
ดังนั้นต้องแยกให้ออกระหว่าง Gartner Evaluation Criteria กับ Our Evaluation Criteria
ขั้นที่ 4: อย่าดูแต่จุด ต้องอ่าน Vendor Analysis
กราฟ Magic Quadrant เป็นเพียงส่วนหนึ่งของงานวิจัย สิ่งที่มีประโยชน์มากคือบทวิเคราะห์ Vendor แต่ละราย โดยเฉพาะ Strengths และ Cautions
ตัวอย่างเช่น Vendor หนึ่งอาจเป็น Leader แต่ Cautions ระบุประเด็นเกี่ยวกับ Pricing, Complexity หรือ Geographic Coverage ซึ่งอาจเป็นเรื่องสำคัญสำหรับเรา ขณะที่ Niche Player อาจมี Strength ด้าน Industry-specific Capability ซึ่งตรงกับ Use Case ขององค์กรพอดี ดังนั้นอย่าหยุดที่ “Vendor A เป็น Leader” แต่ควรถามต่อว่า “ทำไมเขาจึงเป็น Leader และ Cautions ของเขากระทบเราหรือไม่?” บางครั้งข้อความไม่กี่ย่อหน้าใน Vendor Analysis มีประโยชน์ต่อการตัดสินใจมากกว่าตำแหน่งของจุดบนกราฟเสียอีก
ขั้นที่ 5: ใช้ Magic Quadrant สร้าง Vendor Longlist
เมื่อเข้าใจ Market Definition, Inclusion Criteria และ Evaluation Criteria แล้ว เราจึงสามารถใช้ Magic Quadrant เป็นหนึ่งในแหล่งข้อมูลสำหรับสร้าง Vendor Longlist Longlist คือ รายชื่อ Providers ที่ควรนำมาศึกษาเพิ่มเติม
ตัวอย่างเช่น เราอาจเลือก Leader 2 ราย
Challenger 1 ราย
Visionary 1 ราย
Niche Player 1 ราย
Local Vendor 2 ราย
รวมเป็น 7 Vendors นี่เป็นวิธีที่ดีกว่าการเลือก Leader 3 รายแล้วปิดตลาดทันที เพราะเปิดโอกาสให้เราเปรียบเทียบ Solution ที่มีแนวทางแตกต่างกัน หลักคิดคือ Magic Quadrant ใช้เพื่อ “เปิดทางเลือก” ไม่ใช่ “ปิดทางเลือก”
ขั้นที่ 6: จาก Longlist สู่ Shortlist
หลังจากได้ Longlist ขั้นต่อไปคือคัดกรองตาม Requirements ขององค์กร อาจเริ่มจากเงื่อนไขพื้นฐาน เช่น รองรับ Functional Requirements หรือไม่? รองรับจำนวน Users หรือ Transactions ที่ต้องการหรือไม่? เชื่อมต่อระบบเดิมได้หรือไม่? ผ่าน Security Requirements หรือไม่? รองรับ Data Residency หรือ Regulation ที่เกี่ยวข้องหรือไม่? มี Support ในประเทศไทยหรือไม่? มี Partner ที่สามารถ Implement ได้หรือไม่? Budget อยู่ในระดับที่รับได้หรือไม่? เมื่อกรองด้วย Requirements เหล่านี้ Longlist 7 รายอาจเหลือ Shortlist เพียง 3–4 ราย นี่คือจุดที่การตัดสินใจเริ่มเปลี่ยนจาก Market Perspective ไปเป็น Organization Perspective
ขั้นที่ 7: สร้าง Vendor Evaluation Matrix ขององค์กร
เมื่อได้ Shortlist แล้ว ควรสร้าง Vendor Evaluation Matrix เพื่อให้การเปรียบเทียบมีโครงสร้างและโปร่งใส ตัวอย่างเกณฑ์สามารถประกอบด้วย
Functional Fit – 20% ระบบตอบ Business และ Functional Requirements ได้ครบเพียงใด
Technical Fit – 15% Architecture เข้ากับ Technology Stack ขององค์กรหรือไม่
Security & Compliance – 10% ผ่าน Cybersecurity, Privacy และ Regulatory Requirements หรือไม่
Integration – 10% เชื่อมต่อ Application, API, Data และ Legacy Systems ได้ดีเพียงใด
Scalability & Performance – 10% รองรับ Workload และการเติบโตในอนาคตหรือไม่
Vendor Stability – 10% Vendor มีความมั่นคงและมีโอกาสสนับสนุน Product ในระยะยาวหรือไม่
Support & Services – 10% มี Local Support, Partner, SLA และบริการหลังการขายเพียงพอหรือไม่
Total Cost of Ownership – 10% ต้นทุนรวมตลอดอายุการใช้งานเหมาะสมหรือไม่
Exit Strategy – 5% หากต้องการเปลี่ยน Vendor สามารถย้าย Data และ System ออกได้ยากเพียงใด
รวมเป็น 100%
ตัวเลขเหล่านี้เป็นเพียงตัวอย่าง แต่หลักสำคัญคือ น้ำหนักต้องสะท้อน Priority ขององค์กร ไม่ใช่คัดลอกจาก Gartner หรือองค์กรอื่น อย่าดูเฉพาะราคาซื้อ ต้องดู Total Cost of Ownership Vendor Selection ที่ดีไม่ควรเปรียบเทียบเพียง Purchase Price ระบบหนึ่งอาจมี License ราคาถูก แต่มี Implementation Cost สูง ต้องใช้ Hardware เพิ่ม ต้องจ้าง Consultant จำนวนมาก หรือมีค่า Subscription เพิ่มตามจำนวน Users และ Data Volume
จึงควรพิจารณา Total Cost of Ownership – TCO ซึ่งอาจรวมถึง
License / Subscription
Implementation
Infrastructure
Cloud Consumption
Integration
Migration
Training
Operation
Support
Upgrade
Security
Data Transfer
และค่าใช้จ่ายในการ Exit จากระบบในอนาคต
Vendor ที่ราคาซื้อแพงกว่าอาจมี TCO ต่ำกว่าตลอด 5 ปีได้
ดังนั้น
Price ≠ Cost
และ
Lowest Price ≠ Lowest TCO
Technical Fit สำคัญไม่แพ้ Functional Fit
Product อาจมี Feature ดีมาก แต่หากไม่เข้ากับ Architecture ขององค์กรก็อาจสร้างต้นทุนและความซับซ้อนในระยะยาว
ควรถามว่า
รองรับ API หรือไม่?
Integration กับระบบเดิมได้หรือไม่?
รองรับ Identity Platform ของเราหรือไม่?
ทำงานบน Cloud ที่เราใช้หรือไม่?
รองรับ Hybrid Environment หรือไม่?
Data Export ได้หรือไม่?
มี Proprietary Technology มากเพียงใด?
เกิด Vendor Lock-in หรือไม่?
ระบบ Monitoring และ Logging เชื่อมกับเครื่องมือเดิมได้หรือไม่?
ดังนั้นการเลือก Vendor ไม่ควรมีเพียง Business Team หรือ Procurement Team แต่ควรมี Enterprise Architecture, Infrastructure, Cybersecurity, Data และ Operations เข้ามามีส่วนร่วมด้วย
Proof of Concept – อย่าเชื่อเพียง Presentation
Vendor Presentation สามารถแสดง Product ในสภาพแวดล้อมที่สมบูรณ์แบบได้ แต่คำถามจริงคือ
“มันทำงานกับข้อมูล ระบบ และผู้ใช้งานของเราได้หรือไม่?”
นี่คือบทบาทของ Proof of Concept – PoC
PoC ที่ดีควรมี Test Cases และ Success Criteria ก่อนเริ่ม เช่น
Response Time ต้องไม่เกินเท่าไร
Accuracy ต้องมากกว่าเท่าไร
รองรับ Transactions เท่าไร
Integration ต้องสำเร็จกับระบบใด
Security Test ต้องผ่านอะไร
ผู้ใช้งานต้องทำงานเร็วขึ้นกี่เปอร์เซ็นต์
หากกำหนด Success Criteria หลังทดลองเสร็จ เรามีความเสี่ยงที่จะปรับเกณฑ์ให้เข้ากับผลลัพธ์
ดังนั้นควร
Define Success Before Testing
Reference Customer สำคัญมาก
ก่อนตัดสินใจควรขอ Customer References โดยเฉพาะลูกค้าที่มีลักษณะใกล้เคียงกับองค์กรเรา
คำถามที่ควรถาม Reference Customer ไม่ใช่เพียง
“ระบบดีไหม?”
แต่ควรถามว่า
Implementation ใช้เวลาจริงเท่าไร?
ปัญหาที่ยากที่สุดคืออะไร?
งบประมาณจริงต่างจากแผนหรือไม่?
Support ตอบสนองเร็วแค่ไหน?
Upgrade มีปัญหาหรือไม่?
มี Hidden Cost หรือไม่?
ถ้าย้อนเวลากลับไปจะเลือก Vendor เดิมหรือไม่?
คำถามสุดท้ายมักให้ข้อมูลที่น่าสนใจมาก
Local Support อาจสำคัญกว่า Global Ranking
สำหรับองค์กรไทย ปัจจัยที่มักถูกมองข้ามคือ Local Ecosystem
Vendor ระดับโลกอาจมี Product ที่ยอดเยี่ยม แต่หากประเทศไทยมี Partner เพียงรายเดียว มี Engineer จำนวนน้อย หรือ Support ต้องส่ง Ticket ไปต่างประเทศทุกครั้ง ความเสี่ยงด้าน Operations อาจสูง
ในทางกลับกัน Vendor ที่ตำแหน่งใน Magic Quadrant ต่ำกว่าอาจมี Partner Ecosystem แข็งแรง มีทีม Support ภาษาไทย และมี Reference Site จำนวนมากในประเทศ
ดังนั้นควรถามว่า
มี Office ในประเทศไทยหรือไม่?
มี Technical Team กี่คน?
Partner มีกี่ราย?
มี Certified Engineers จำนวนเท่าไร?
SLA เป็นอย่างไร?
Escalation ไป Regional หรือ Global อย่างไร?
มี Spare Parts หรือ Infrastructure Support ในประเทศหรือไม่?
สิ่งเหล่านี้ไม่สามารถอ่านได้จากตำแหน่งบน Magic Quadrant เพียงอย่างเดียว
Vendor Lock-in และ Exit Strategy
อีกประเด็นที่ควรคิดตั้งแต่ก่อนซื้อคือ
“ถ้าวันหนึ่งเราไม่ต้องการ Vendor นี้แล้ว เราจะออกอย่างไร?”
คำถามนี้สำคัญมากสำหรับ Cloud, SaaS, Data Platform และ AI Platform
ควรตรวจสอบว่า
สามารถ Export Data ได้หรือไม่?
Format เป็นมาตรฐานหรือ Proprietary?
API เปิดหรือไม่?
มีค่า Data Egress หรือไม่?
Configuration สามารถย้ายได้หรือไม่?
Contract มีเงื่อนไข Auto-renewal หรือไม่?
หลังยกเลิกบริการ Vendor เก็บ Data นานเท่าไร?
Migration ไป Platform อื่นต้องใช้ต้นทุนเท่าไร?
Vendor Selection ที่ดีจึงต้องคิดทั้ง
Entry Strategy
และ
Exit Strategy
พร้อมกัน
อย่าใช้ Magic Quadrant เป็นเงื่อนไข TOR แบบตรง ๆ
สำหรับการจัดซื้อ โดยเฉพาะหน่วยงานที่ต้องให้ความสำคัญกับการแข่งขันและความโปร่งใส ควรระมัดระวังการกำหนดเงื่อนไขประเภท
“ผลิตภัณฑ์ต้องอยู่ใน Leaders Quadrant ของ Gartner”
เพราะ Gartner ไม่ได้ระบุว่า Leaders เหมาะกับทุกองค์กร และเงื่อนไขเช่นนี้อาจตัดผู้เสนอรายอื่นที่สามารถตอบ Requirement ได้ออกไปโดยไม่จำเป็น
แนวทางที่เหมาะสมกว่าคือศึกษาข้อมูลจาก Gartner เพื่อทำความเข้าใจตลาด แล้วแปลงสิ่งที่องค์กรต้องการออกมาเป็น Objective Requirements
เช่น Performance, Availability, Security, Integration, Scalability, SLA, Support และ Functional Capabilities
กล่าวอีกแบบคือ
ใช้ Gartner ช่วยศึกษา TOR แต่ไม่ควรใช้ตำแหน่ง Gartner แทน Requirement ของ TOR
ต้องดู Magic Quadrant หลายปีหรือไม่?
ถ้ามีข้อมูล ควรดูแนวโน้มหลายปี
เพราะภาพปีเดียวบอกเพียง Snapshot แต่การเคลื่อนที่หลายปีสามารถทำให้เราตั้งคำถามเพิ่มเติมได้
Vendor กำลังเคลื่อนไปทางไหน?
Vision ดีขึ้นหรือแย่ลง?
Execution เปลี่ยนหรือไม่?
มีการ Acquisition หรือไม่?
Product Strategy เปลี่ยนหรือไม่?
ออกจากตลาดบาง Segment หรือไม่?
อย่างไรก็ตาม การเปรียบเทียบข้ามปีต้องระวัง เพราะ Gartner อาจเปลี่ยน Market Definition, Inclusion Criteria หรือ Evaluation Criteria ทำให้ตำแหน่งไม่สามารถเปรียบเทียบตรง ๆ ได้เสมอ
ดังนั้น
Movement ≠ Performance Change เสมอไป
ต้องอ่าน Methodology ของแต่ละปีประกอบด้วย
ตัวอย่าง: Leader กับ Niche Player ใครควรชนะ?
สมมติองค์กรกำลังเลือกระบบและมีตัวเลือกสุดท้าย 2 ราย
Vendor A – Leader
Functional Fit 80%
Technical Fit 85%
Local Support ปานกลาง
TCO 15 ล้านบาท
Implementation 12 เดือน
Vendor B – Niche Player
Functional Fit 95%
Technical Fit 90%
Local Support ดีมาก
TCO 9 ล้านบาท
Implementation 6 เดือน
หากตัดสินจาก Magic Quadrant เพียงอย่างเดียว Vendor A ชนะทันที
แต่เมื่อใช้ Evaluation Matrix ขององค์กร Vendor B อาจได้คะแนนสูงกว่า
นี่ไม่ได้หมายความว่า Gartner ผิด
แต่หมายความว่า
Gartner กำลังตอบคนละคำถามกับเรา
Gartner วิเคราะห์ Provider ในบริบทของตลาด
ส่วนองค์กรกำลังวิเคราะห์ว่า Provider ใดเหมาะกับ Requirement ของตนเอง
ทั้งสองคำตอบจึงสามารถถูกต้องพร้อมกันได้
จาก Gartner Evaluation สู่ Our Evaluation
นี่คือแนวคิดที่สำคัญที่สุดของตอนนี้
เริ่มจาก
Gartner Evaluation
เพื่อเข้าใจตลาด
จากนั้นสร้าง
Our Evaluation
เพื่อเข้าใจความเหมาะสมกับองค์กร
เส้นทางจึงควรเป็น
Business Goal → Requirements → Market Research → Magic Quadrant → Vendor Longlist → Shortlist → RFI/RFP → Technical Evaluation → PoC → Commercial Evaluation → Risk Assessment → Decision
ไม่ใช่
Magic Quadrant → Leader → Buy
กระบวนการอาจดูยาวกว่า แต่ต้นทุนในการประเมินก่อนซื้อ มักต่ำกว่าต้นทุนจากการเลือกระบบผิดหลายเท่า
Checklist ก่อนเลือก Vendor
ก่อนตัดสินใจ ลองตอบคำถามเหล่านี้ให้ครบ
เราเข้าใจ Market Definition แล้วหรือไม่?
Requirements ของเราชัดเจนหรือยัง?
Use Case มี KPI หรือไม่?
Vendor ตอบ Functional Requirements ได้กี่เปอร์เซ็นต์?
Architecture เข้ากับระบบเดิมหรือไม่?
ผ่าน Security และ Compliance หรือไม่?
Data สามารถย้ายเข้าและออกได้หรือไม่?
มี Customer Reference ที่คล้ายกับเราหรือไม่?
มี Local Support และ Partner หรือไม่?
Implementation Plan เป็นจริงหรือไม่?
PoC ผ่าน Success Criteria หรือไม่?
TCO ตลอดอายุระบบเท่าไร?
มี Vendor Lock-in หรือไม่?
Exit Strategy คืออะไร?
และคำถามสุดท้าย
“ถ้าเอาคำว่า Gartner ออกจากชื่อ Vendor เรายังเลือก Vendor รายนี้อยู่หรือไม่?”
หากคำตอบยังเป็น “ใช่” แสดงว่าเราน่าจะมีเหตุผลจาก Requirement ขององค์กรรองรับการตัดสินใจมากกว่าการพึ่งตำแหน่งบนกราฟเพียงอย่างเดียว
สรุป
Magic Quadrant เป็นเครื่องมือที่มีประโยชน์อย่างมากในการทำความเข้าใจ Market Landscape และ Provider Positioning แต่ไม่ใช่เครื่องมือจัดอันดับ Vendor และไม่ควรถูกใช้เป็นคำตอบสุดท้ายในการจัดซื้อ
หลักคิดสำคัญคือ Leader ≠ Best for Us Niche, Player ≠ Inferior, Not Included ≠ Not Qualified, Magic Quadrant ≠ Ranking และที่สำคัญที่สุด Gartner Evaluation ≠ Our Evaluation
การเลือก Vendor ที่ดีควรเริ่มจาก Business Goals และ Requirements ขององค์กร แล้วใช้ Gartner เป็นหนึ่งในแหล่งข้อมูลสำหรับทำ Market Research ก่อนนำ Vendor มาประเมินด้วยเกณฑ์ของเราเอง ทั้ง Functional Fit, Technical Fit, Security, Integration, Scalability, Vendor Stability, Local Support, TCO และ Exit Strategy
อย่าเลือก Vendor ที่ “ดีที่สุดในตลาด” แต่จงเลือก Vendor ที่ “เหมาะสมที่สุดสำหรับเรา” เมื่อเข้าใจ Magic Quadrant และรู้วิธีใช้เพื่อสร้าง Vendor Shortlist แล้ว คำถามต่อไปคือ แม้ Vendor จะดูดีในระดับบริษัท แต่ Product หรือ Service ของเขาเหมาะกับ Use Case ของเราจริงหรือไม่? นั่นคือพื้นที่ของเครื่องมืออีกประเภทหนึ่งของ Gartner
#Gartner #Gartner101 #MagicQuadrant #VendorSelection #VendorEvaluation #ITProcurement #TechnologyStrategy #ITStrategy #TechnologyInvestment #DigitalTransformation
.
------------------------
ที่มาข้อมูล
รวบรวมข้อมูลและรูปภาพ
