- 20
- เมษายน
คำว่า "Sunset Date" คือวันที่ vendor ประกาศหยุด support ผลิตภัณฑ์ — ไม่มี security patch ใหม่, ไม่มี bug fix, ไม่มี help desk และตอนนี้ SAP, Microsoft และ Oracle ประกาศ sunset date ของ ERP รุ่นเก่าพร้อมกันทั้งสามเจ้า ไทม์ไลน์ตั้งแต่ 2570 ถึงอย่างน้อย 2578
Scott Bickley จาก Info-Tech Research Group สรุปแรงกดดันนี้ไว้ชัดเจน: "The message from ERP vendors is clear: get on our cloud now, or else." — สารจาก vendor ชัดเจนคือ "ย้ายขึ้น cloud ของเราเดี๋ยวนี้ หรือไม่ก็…"
สรุปง่ายๆ: SAP Business Suite 7 จบ mainstream support 31 ธันวาคม 2570 (premium maintenance ต่อได้ถึงสิ้นปี 2573), Microsoft Dynamics GP จบ 30 กันยายน 2572 (security patch ถึง เม.ย. 2574), Oracle PeopleSoft ยืนยัน support อย่างน้อยถึง 2578 (rolling 10-year, ไม่มี endpoint ตายตัว) ค่า migration จาก legacy มา modern ERP อาจสูงถึง $1 พันล้าน (Forrester) — องค์กรไทยที่ใช้ระบบเหล่านี้ต้องเริ่มวางแผน migration ภายในปีนี้
ใครจะจบก่อน — Timeline ถึง 2578
ปี 2569 นี้เองที่ vendor ใหญ่สามเจ้าเริ่มประกาศ sunset date พร้อมกัน ลูกค้า enterprise ที่ใช้ระบบเก่ามาสิบๆ ปีกำลังถูก "บังคับเลือก" ว่าจะย้ายไป cloud ของใคร หรือจะ diversify ไปทางอื่น
| ผลิตภัณฑ์ | End-of-Support | Extended Support | Migration Target |
|---|---|---|---|
| SAP Business Suite 7 | 31 ธ.ค. 2570 | Premium maintenance ถึงสิ้นปี 2573 | SAP S/4HANA (support ≥ 2583) |
| Microsoft Dynamics GP | 30 ก.ย. 2572 | Security patch อย่างเดียว ถึง 30 เม.ย. 2574 | Dynamics 365 Business Central |
| Oracle PeopleSoft | อย่างน้อย 2578 | ต่อรายปี ไม่มี fixed end (rolling 10-year) | Oracle Fusion Cloud Applications |
จะเห็นว่า PeopleSoft "หลวม" ที่สุด — Oracle เลือกกลยุทธ์ไม่กำหนด endpoint ชัดเจน แต่ให้สัญญาว่าจะ support อย่างน้อย 10 ปีข้างหน้าจากปัจจุบัน ("rolling 10-year") ส่วน SAP กับ Microsoft ประกาศ deadline แน่นอน — องค์กรต้องเริ่ม plan migration ตั้งแต่ ตอนนี้ เพราะ ERP migration ใช้เวลา 12-36 เดือน โดยเฉลี่ย (ดู การวางแผน Implementation)
ค่า Migration จริงๆ — ไม่ใช่แค่ License
Liz Herbert จาก Forrester วิเคราะห์ค่า migration ของ enterprise ขนาดใหญ่ไว้ว่า อาจสูงถึง "a billion dollars" — 1 พันล้านดอลลาร์ รวมค่า data migration, software license, consulting, และ training ตัวเลขนี้ฟังดูโอเวอร์ แต่ก็ไม่เกินจริงสำหรับ Fortune 500 ที่ใช้ SAP ECC มา 15-20 ปีและมี customization เยอะ
ถ้าเจาะแยกค่า migration เป็นรายหมวด (สัดส่วนโดยประมาณจากโครงการจริง) จะเห็นว่า license เป็นก้อนเล็กที่สุด — ก้อนใหญ่คือ "คน + เวลา":
- Data migration + cleansing — ล้างข้อมูลเก่า 15-20 ปี, map field, validate integrity, reconcile balances
- Consulting / System Integrator — SAP/Oracle/Accenture/Deloitte partners คิดค่าตัวแพงมาก
- Customization rebuild — code ABAP, PeopleCode, Dynamics Extensions ที่เขียนเฉพาะต้องเขียนใหม่หมดบน platform ใหม่
- Training + Change management — ผู้ใช้งานหลักหลายพันคน + business process re-engineering
- Downtime + Parallel run — รันระบบเก่า+ใหม่พร้อมกัน 3-6 เดือน เพื่อเช็ค data consistency
และนี่ยังไม่รวม "ค่าเลื่อน deadline" ที่บางองค์กรต้องจ่าย Greg Leiter จาก Gartner เตือนไว้ว่า vendor "will not offer further extensions, but one can expect if they do, it will come at higher costs." — ถ้าจะขอต่ออายุ support จริงๆ vendor จะคิดแพงขึ้นแบบก้าวกระโดด
คำเตือน: ถ้า migrate ไม่ทัน deadline — องค์กรจะอยู่บนระบบที่ ไม่มี security patch ใหม่อีกต่อไป CVE ใหม่ๆ ที่ค้นพบภายหลังจะกลายเป็นช่องโหว่ถาวร แฮกเกอร์มี playbook สำหรับโจมตี legacy ERP อยู่แล้ว (ดูกรณี SAP Security Patch มีนาคม 2569 และ Oracle CVE-2026-21992) ERP เป็น high-value target เพราะเก็บข้อมูลการเงิน พนักงาน ลูกค้า ครบทั้งองค์กร หนึ่ง CVE ที่ไม่ได้ patch อาจทำให้ข้อมูลทั้งบริษัทรั่วได้
3 เส้นทางที่ Vendor ชี้ให้คุณ — เปรียบเทียบ
เมื่อ vendor บังคับให้ย้าย พวกเขาก็เตรียมปลายทางไว้ให้แล้ว ทั้งสามเจ้าชี้ไปที่ cloud ของตัวเอง เหมือนกันหมด ลองดู comparison ทั้ง 3 path:
| มิติ | SAP S/4HANA | Dynamics 365 BC | Oracle Fusion Cloud |
|---|---|---|---|
| Deployment model | Cloud-first (RISE with SAP / GROW), on-prem ยังมีแต่ไม่ถูกโปรโมต | SaaS ล้วน (Microsoft Cloud) | SaaS ล้วน (Oracle Cloud Infrastructure) |
| Pricing model | Subscription ต่อ user + module, ต่อปี | Subscription ต่อ user/เดือน (Essentials/Premium) | Subscription ต่อ user + module, commitment 3 ปีขึ้นไป |
| Target customer size | Large enterprise, manufacturing, global MNC | SMB-Mid market (5-500 users) | Large enterprise, HR/Finance-heavy org |
| Migration complexity | สูงมาก (S/4 ไม่ compatible backward กับ ECC) | ปานกลาง (GP → BC มี migration tool) | สูง (PeopleSoft → Fusion เปลี่ยน data model หมด) |
| Vendor lock-in risk | สูง (HANA database ผูกแน่น) | สูง (ผูกกับ Microsoft ecosystem) | สูง (Oracle-only stack) |
| Time to deploy | 18-36 เดือน | 6-12 เดือน | 12-24 เดือน |
จุดน่าสังเกตคือ "vendor lock-in risk" สูงทั้งสามเจ้า — ไม่ใช่เพราะ cloud ไม่ดี แต่เพราะแต่ละ vendor ออกแบบ architecture ให้ "ย้ายออกยาก" เช่น SAP ผูก application กับ HANA database เฉพาะ, Oracle ผูก middleware กับ Oracle Cloud Infrastructure, Microsoft ผูก integration กับ Azure AD + Power Platform
Lock-in ใหม่ซ่อนอยู่ในคำว่า "Cloud"
หลายองค์กรเข้าใจผิดว่า "ย้ายขึ้น cloud = ย้ายไปไหนก็ได้" ความจริงคือ ตรงกันข้าม — cloud migration มักทำให้การย้ายออก ยากขึ้น กว่าเดิม สาเหตุมีหลายข้อ:
- Data residency + compliance — ข้อมูลอยู่ใน data center ของ vendor, export format มักเป็น proprietary ไม่ใช่ standard CSV/SQL
- Proprietary APIs — integration ที่เขียนไว้กับ vendor-specific APIs (Oracle REST, SAP OData) ใช้กับ vendor อื่นไม่ได้
- Licensing bundles — ซื้อ ERP cloud มักบังคับซื้อ database + identity + BI tool ของ vendor เดียวกัน
- Custom code ถูก "lock" ใน sandbox — extension ที่เขียนบน cloud (SAP BTP, Oracle APEX) รันนอก cloud ไม่ได้
จุดยืนของผู้เขียนไม่ใช่ "lock-in = เลว" — ทุก platform มี lock-in ระดับหนึ่ง แม้แต่ Linux ก็ยังมี distro lock-in ประเด็นสำคัญคือ "เลือก vendor ให้ดี" — vendor ที่ไม่จับข้อมูลคุณเป็นตัวประกัน, เปิดให้ export ได้อิสระ, และไม่เปลี่ยน sunset date เพื่อบีบลูกค้า (ดูประเด็นนี้ลึกขึ้นที่บทความ Vendor Lock-in)
Cloud เป็นสิ่งที่ดีและหลีกเลี่ยงไม่ได้ แต่ก่อนลงมือ migration ควรตอบ 3 คำถาม: (1) ข้อมูล export ออกมาในรูปแบบ standard ได้ไหม? (2) API เป็น open standard (REST + JSON schema) หรือ proprietary? (3) ถ้าจะย้ายออก 5 ปีข้างหน้า จะใช้เวลาเท่าไร?
ทางเลือกที่ 4 — ERP ไทย ที่ไม่มี Forced Sunset
นอกจาก 3 path ที่ vendor ใหญ่ชี้ให้ ยังมีทางเลือกที่ 4 — ERP ที่พัฒนาในไทย ซึ่งไม่มี "sunset date ที่ vendor กำหนด" เพราะ vendor อยู่ใกล้คุณ ไม่มี HQ ที่อเมริกาหรือเยอรมันมา dictate วันปิด support
Saeree ERP เป็นระบบที่พัฒนาในไทยโดยบริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด — เลือก deploy ได้ทั้ง on-premise หรือ cloud (อยู่ที่ลูกค้าตัดสินใจ ไม่ใช่ vendor บังคับ), อัพเกรดตามจังหวะของลูกค้าเอง, code เป็น open standard (Java + PostgreSQL) ไม่มี proprietary runtime
ต้องพูดตรงๆ ว่า Saeree ERP ไม่ใช่ drop-in replacement ของ SAP S/4HANA สำหรับ Fortune 500 ที่มีโรงงาน 50 ประเทศ — จุดเด่นของ Saeree อยู่ที่ องค์กรไทยขนาดกลางถึงใหญ่ ที่ต้องการ:
- Vendor sovereignty — vendor อยู่ในไทย, ตอบรับเร็ว, เข้าใจ context ท้องถิ่น (VAT, ใบกำกับภาษี, e-Tax, GFMIS)
- Data sovereignty — ข้อมูลเก็บในไทยได้ 100% ไม่ต้องไป server ต่างประเทศ
- ไม่มี forced cloud migration — on-premise ได้ตลอด ถ้าอยาก cloud ค่อยย้ายตามความพร้อม
เทียบละเอียด Saeree vs SAP ได้ที่บทความ Saeree ERP vs SAP และบทความ ERP ไทย vs ERP ต่างประเทศ
ตาราง "เหมาะ / ไม่เหมาะ" ย้ายจาก Legacy ไป Saeree
เพื่อให้ตัดสินใจได้ตรงไปตรงมา — ตารางนี้บอกว่า Saeree ERP เหมาะกับใคร และ ไม่ เหมาะกับใคร (เพราะสำคัญพอๆ กัน)
| ✓ เหมาะ | ✗ ไม่เหมาะ |
|---|---|
| องค์กรไทย / ภูมิภาค ASEAN | Fortune 500 Global MNC ที่มีโรงงาน 50+ ประเทศ |
| งบ ERP 30-500 ล้านบาท | องค์กรที่ใช้ SAP-specific industry modules (IS-Oil, IS-Utilities) |
| ต้องการ vendor ที่พูดไทย สนับสนุนในไทย | มี customization SAP ABAP หนัก 10+ ปี ที่ไม่สามารถเขียนใหม่ได้ |
| ต้องการเก็บข้อมูลในไทย (data sovereignty) | ต้องการ pre-built integration กับ global banking/trading platform |
| ต้องการเลือก on-premise vs cloud ได้เอง | ต้องการ ecosystem ISV + consulting network ขนาดใหญ่ (SAP certified partners) |
| ไม่อยาก lock-in กับ cloud vendor ต่างประเทศ | ต้องการ pure SaaS ไม่มีทางเลือก on-premise เลย |
ถ้าอ่านแล้วพบว่า Saeree เหมาะกับโจทย์ของคุณ — บทความ Pricing Tiers และ วิธีเลือก ERP จะช่วยประเมิน budget และ checklist การเลือก และถ้าเป็นหน่วยงานภาครัฐควรดู ERP สำหรับหน่วยงานรัฐ เพิ่มด้วย
"Sunset deadline ไม่ใช่ปัญหา — ปัญหาคือการปล่อยให้ ERP vendor เป็นคนบอกคุณว่า จะรันธุรกิจของคุณ เมื่อไหร่ ที่ไหน อย่างไร"
— Saeree ERP, 2569
