PROBLEMS WE SOLVE
ปัญหาด้านเทคนิคและการจัดซื้อ มักไม่ได้เริ่มจาก “สินค้าไม่ดี”
หลายโครงการเริ่มมีความเสี่ยงตั้งแต่ก่อนเลือกผู้ขาย ตั้งแต่การกำหนดความต้องการที่ไม่ชัดเจน Specification ที่ไม่สะท้อนการใช้งานจริง การเปรียบเทียบข้อเสนอที่ไม่อยู่บนฐานเดียวกัน ไปจนถึงการส่งมอบที่ผ่านเอกสารแต่ยังไม่พร้อมใช้งานจริง
AEGIS ช่วยลูกค้ามองปัญหาจากฝั่งเจ้าของโครงการ โดยใช้ข้อมูล หลักฐาน เกณฑ์ที่ตรวจสอบได้ และความต้องการใช้งานจริงเป็นฐานในการตัดสินใจ
WHY THESE PROBLEMS HAPPEN
ปัญหาส่วนใหญ่ไม่ได้เกิดจากจุดเดียว
การจัดซื้อเทคโนโลยีและอุปกรณ์ทางเทคนิคมีความซับซ้อน เพราะผู้ใช้งาน ฝ่ายจัดซื้อ ผู้บริหาร ฝ่ายวิศวกรรม และผู้ขายมองโครงการจากคนละมุม
หากไม่มีผู้ที่สามารถเชื่อมความต้องการทางธุรกิจ การใช้งานจริง ข้อจำกัดทางเทคนิค ราคา และความเสี่ยงในการส่งมอบเข้าด้วยกัน การตัดสินใจอาจถูกขับเคลื่อนด้วยข้อมูลที่ไม่ครบ หรือข้อมูลที่มาจากฝ่ายใดฝ่ายหนึ่งมากเกินไป
บทบาทของ AEGIS คือช่วยสร้างกรอบการตัดสินใจที่ชัดเจน ไม่ใช่ตัดสินใจแทนลูกค้า
COMMON PROJECT RISKS
11 ปัญหาที่พบบ่อยในโครงการจัดซื้อและลงทุนด้านเทคนิค
ปัญหาเหล่านี้สามารถเกิดขึ้นได้ทั้งก่อนจัดซื้อ ระหว่างการประเมินข้อเสนอ ระหว่างดำเนินโครงการ และหลังการส่งมอบ
ความต้องการโครงการไม่ชัดเจน
เมื่อ Requirement ยังไม่ชัดเจน TOR และ Specification ที่ตามมามักสะท้อน “สิ่งที่คิดว่าต้องการ” มากกว่า “สิ่งที่ต้องใช้จริง”
สัญญาณที่พบบ่อย
- แต่ละฝ่ายอธิบาย Scope ไม่เหมือนกัน
- ระบุคุณสมบัติสินค้า แต่ไม่ได้ระบุผลลัพธ์ที่ต้องการ
- Requirement เปลี่ยนบ่อยหลังเริ่มขอราคา
- ไม่มี Acceptance Criteria ที่ชัดเจนตั้งแต่ต้น
ช่วยแยก Business Need, User Need และ Technical Requirement ก่อนจัดทำ TOR หรือขอข้อเสนอจากผู้ขาย
ข้อเสนอลูกค้าขับเคลื่อนโดยผู้ขายมากกว่าความต้องการจริง
เมื่อ Requirement ยังไม่แข็งแรง Solution ที่นำเสนออาจเริ่มจากสิ่งที่ผู้ขายต้องการขาย แทนที่จะเริ่มจากปัญหาขององค์กร
ความเสี่ยง
- ซื้อ Feature ที่ไม่เคยนำมาใช้จริง
- Architecture ถูกกำหนดโดยสินค้าแทน Workflow
- เกิด Overspec และต้นทุนสูงเกินความจำเป็น
- ลูกค้าไม่มี Independent View สำหรับตรวจสอบข้อเสนอ
เริ่มจากปัญหา กระบวนการ และผลลัพธ์ที่องค์กรต้องการ แล้วจึงประเมินว่า Solution ใดตอบโจทย์จริง
การล็อกสเปกและข้อกำหนดที่จำกัดการแข่งขัน
Specification ที่เจาะจงเกินความจำเป็น อาจทำให้มีผู้ขายเพียงไม่กี่รายที่สามารถผ่านเงื่อนไข โดยไม่ได้เพิ่มคุณค่าต่อการใช้งานจริง
สิ่งที่ควรตรวจสอบ
- ข้อกำหนดใดเป็น Mandatory จริง
- ข้อกำหนดใดผูกกับ Brand หรือ Model โดยไม่จำเป็น
- Specification สะท้อน Performance หรือ Product Feature
- มีทางเลือกที่ให้ผลลัพธ์เทียบเท่าหรือไม่
Review TOR และ Specification จากมุมของการใช้งานจริง ความเป็นกลาง และความสามารถในการแข่งขันอย่างเหมาะสม
ผลประโยชน์ทับซ้อนในกระบวนการจัดซื้อ
ความสัมพันธ์ระหว่างผู้เกี่ยวข้องกับผู้ขาย หรือแรงจูงใจที่ไม่สอดคล้องกับผลประโยชน์ขององค์กร สามารถลดความน่าเชื่อถือของการตัดสินใจได้
ความเสี่ยง
- เกณฑ์ถูกออกแบบให้เอื้อบางข้อเสนอ
- ข้อมูลจากผู้ขายถูกนำมาใช้โดยไม่มี Independent Review
- เหตุผลการตัดสินใจไม่สามารถตรวจสอบย้อนหลังได้
- เกิด Governance และ Reputation Risk
ช่วยสร้างเกณฑ์ กระบวนการประเมิน และหลักฐานประกอบ เพื่อให้การตัดสินใจมีความโปร่งใสและตรวจสอบได้
เปรียบเทียบผู้ขายแบบ Apples-to-Apples ได้ยาก
ใบเสนอราคาที่ดูคล้ายกัน อาจมี Scope, Technology, Warranty, Service, Spare Parts และเงื่อนไขทางการค้าที่แตกต่างกันมาก
ปัญหาที่เกิดขึ้น
- ราคา Total ไม่ได้หมายถึง Scope เท่ากัน
- ข้อยกเว้นและ Assumption ถูกซ่อนไว้ในรายละเอียด
- บางรายรวม Service บางรายคิดเพิ่มภายหลัง
- เปรียบเทียบราคาโดยไม่ Normalize Scope
Normalize Scope และสร้าง Evaluation Matrix เพื่อให้เปรียบเทียบข้อเสนอทั้งด้านเทคนิคและเชิงพาณิชย์บนฐานเดียวกัน
ราคาไม่สะท้อนต้นทุนที่แท้จริง
ราคาซื้อเริ่มต้นที่ต่ำอาจไม่ใช่ทางเลือกที่มีต้นทุนต่ำที่สุด หากมีค่า Service, License, Consumable, Spare Parts หรือ Upgrade สูงในระยะยาว
ต้องมองมากกว่าราคาซื้อ
- Total Cost of Ownership
- Maintenance และ Support
- License / Subscription
- Downtime และ Operational Cost
วิเคราะห์ Cost Structure และ Lifecycle Cost เพื่อให้ลูกค้าเห็นต้นทุนที่อาจเกิดขึ้นหลังการจัดซื้อ
เทคโนโลยีไม่เหมาะกับการใช้งานจริง
เทคโนโลยีที่ดีหรือทันสมัยที่สุด ไม่ได้หมายความว่าเหมาะกับ Operating Environment และความพร้อมขององค์กรเสมอไป
สิ่งที่มักถูกมองข้าม
- ทักษะของผู้ใช้งานและทีม Maintenance
- Infrastructure ที่มีอยู่
- Environment และข้อจำกัดหน้างาน
- Integration กับระบบเดิม
ประเมิน Technology Fit กับ Environment, Workflow, Capability และข้อจำกัดจริงขององค์กร
ความสามารถของผู้ขายไม่ตรงกับสิ่งที่เสนอ
Technical Proposal ที่ดีไม่ได้รับประกันว่า ผู้ขายมีทีม ทรัพยากร ประสบการณ์ และระบบ Support เพียงพอสำหรับส่งมอบจริง
ควรตรวจมากกว่าสเปก
- ประสบการณ์และ Reference ที่เกี่ยวข้อง
- ทีม Engineering และ Project Delivery
- Service Capability
- ความพร้อมด้าน Spare Parts และ Support
ประเมิน Vendor Capability ควบคู่กับ Technical Compliance ไม่พิจารณาเฉพาะเอกสารข้อเสนอ
ความเสี่ยงด้านบริการหลังการขาย
ระบบอาจทำงานได้ดีในวันส่งมอบ แต่ปัญหาเริ่มเกิดเมื่อ Distributor เปลี่ยน ทีม Support หาย หรือ Spare Parts ไม่พร้อม
ประเด็นที่ต้องพิจารณา
- SLA และ Response Time
- Local Service Capability
- Spare Parts Availability
- Warranty และ End-of-Life Risk
ตรวจสอบ Service Model และความเสี่ยงระยะยาว ก่อนตัดสินใจซื้อ ไม่รอให้ปัญหาเกิดหลังหมด Warranty
ส่งมอบแล้วแต่ใช้งานไม่ได้จริง
การส่งมอบครบตามรายการไม่ได้หมายความว่า ระบบพร้อมสำหรับ Operation
สิ่งที่ต้องตรวจสอบ
- Testing และ Functional Verification
- Integration กับระบบจริง
- Training และ User Readiness
- Documentation และ Handover
ช่วยกำหนด Acceptance Criteria และตรวจสอบ Operational Readiness ก่อนปิดโครงการหรืออนุมัติรับมอบ
ความเสี่ยงด้านการกำกับดูแลและความโปร่งใสในการจัดซื้อ
หากเกณฑ์ การอนุมัติ การเปรียบเทียบ และเหตุผลประกอบการตัดสินใจไม่ชัดเจน องค์กรจะมีความเสี่ยงด้าน Governance และ Audit
สิ่งที่ควรมี
- เกณฑ์ประเมินที่กำหนดก่อนเห็นผลลัพธ์
- Evidence Supporting Decision
- Decision Trail ที่ตรวจสอบย้อนหลังได้
- Conflict of Interest Control
ช่วยออกแบบกระบวนการที่มีหลักฐาน เหตุผล และ Audit Trail ที่ชัดเจน เพื่อเพิ่มความน่าเชื่อถือของการตัดสินใจ
OUR APPROACH
เราไม่ได้เริ่มจากการถามว่า “จะซื้อยี่ห้ออะไร”
เราเริ่มจากการทำความเข้าใจว่าองค์กรกำลังพยายามแก้ปัญหาอะไร ต้องการผลลัพธ์แบบใด มีข้อจำกัดอะไร และความเสี่ยงสำคัญอยู่ตรงไหน
Understand the Need
แยกปัญหาทางธุรกิจ การใช้งานจริง และข้อกำหนดทางเทคนิคออกจากกันให้ชัดเจน
Identify Decision Risks
ระบุจุดที่ข้อมูลไม่ครบ สมมติฐานสำคัญ Conflict of Interest และความเสี่ยงที่อาจกระทบการตัดสินใจ
Establish Objective Criteria
สร้างเกณฑ์ที่เชื่อมโยงกับ Requirement และสามารถใช้เปรียบเทียบทางเลือกได้จริง
Evaluate Evidence
ตรวจสอบข้อมูลจากผู้ขาย เอกสารทางเทคนิค ราคา Capability และข้อจำกัดของแต่ละทางเลือก
Support a Defensible Decision
สรุป Trade-off ความเสี่ยง และเหตุผล เพื่อให้ผู้มีอำนาจตัดสินใจสามารถเลือกทางเลือกได้ด้วยข้อมูลที่ชัดเจน
INDEPENDENT ADVISORY
เป้าหมายไม่ใช่การหา “ผู้ขายที่ AEGIS ชอบ” แต่คือช่วยให้ลูกค้าตัดสินใจได้ด้วยเหตุผลที่อธิบายได้
AEGIS ไม่รับค่าคอมมิชชันจากผู้ขาย และไม่ขายสินค้าให้ลูกค้า บทบาทของเราคือทำงานในฝั่งลูกค้า เพื่อช่วยให้การกำหนด Requirement การประเมินทางเลือก การวิเคราะห์ต้นทุน และการตรวจรับ มีความเป็นอิสระ โปร่งใส และตรวจสอบได้มากขึ้น