8 สัญญาณว่า SAP ปัจจุบันถึงเวลาวางแผน Upgrade
องค์กรควรเริ่มวางแผน SAP Upgrade เมื่อระบบใกล้สิ้นสุดระยะการสนับสนุน หรือเริ่มมีข้อจำกัดด้าน Custom Code, Integration, Performance และ Security แม้ SAP ปัจจุบันยังใช้งานได้ตามปกติ เพราะการรอจนเวอร์ชันหมด Support อาจทำให้องค์กรมีเวลาประเมินทางเลือกน้อยลง เพิ่มความเสี่ยงและต้นทุนในการปรับปรุงระบบ
การวาง SAP Upgrade Roadmap ล่วงหน้าควรพิจารณา Maintenance Timeline, Technical Debt และ Business Roadmap ร่วมกัน เพื่อกำหนดช่วงเวลา งบประมาณ และความพร้อมในการเปลี่ยนแปลงได้อย่างเหมาะสม พร้อมเตรียมตรวจสอบ Custom Code, Integration, Test Plan และจัดทำ Business Case เพื่อเปลี่ยนการ Upgrade จากงานแก้ปัญหาเร่งด่วนให้เป็นแผนพัฒนาระบบที่สนับสนุนประสิทธิภาพและการเติบโตของธุรกิจ
NEXUS ให้บริการ Business Consulting, Solution Consulting และ Project Assessments เพื่อช่วยองค์กรประเมินทางเลือกและวางแนวทางปรับปรุงระบบ SAP ให้สอดคล้องกับเป้าหมายธุรกิจ โดยสามารถหารือขอบเขตการประเมินด้าน Maintenance, Custom Code, Add-on, Interface, Infrastructure และ Business Impact ตามสภาพระบบและความต้องการของแต่ละองค์กร
เลือกอ่านหัวที่สนใจ
SAP System สามารถใช้งานต่อเนื่องได้หลายปี และหลายองค์กรเลือกเลื่อน Upgrade เพราะระบบปัจจุบัน “ยังทำงานได้” แต่ความเสี่ยงของ เวอร์ชัน เก่าไม่ได้แสดงออกมาในรูป System Down เสมอไป บางครั้งเริ่มจากการต่อระบบใหม่ยากขึ้น Add-on ไม่รองรับ ต้องใช้ Workaround มากขึ้น หรือทุกการเปลี่ยนแปลงกลายเป็น Project ที่ต้องระวังผลกระทบจำนวนมาก
การวาง SAP Upgrade Roadmap จึงควรเริ่มก่อนระบบถึงจุดวิกฤต เพราะทีมต้องใช้เวลาเช็ก Maintenance, Custom Code, Interface, Add-on, Infrastructure และ Test Plan ล่วงหน้า ยิ่ง Landscape ซับซ้อน ระยะเตรียมตัวก็ยิ่งสำคัญ
8 สัญญาณว่า SAP เวอร์ชัน ปัจจุบันถึงเวลาวางแผน Upgrade
1. เวอร์ชัน กำลังเข้าใกล้หรือพ้นช่วง Maintenance ที่เหมาะสม
สัญญาณแรกคือ เวอร์ชันปัจจุบันเข้าใกล้ End of Mainstream Maintenance หรืออยู่ในช่วงที่องค์กรต้องพึ่ง Extended / Customer-Specific Maintenance มากขึ้น ซึ่งอาจลดความยืดหยุ่นด้าน Patch, Innovation และ Support Strategy
โดย SAP Business Suite 7 Core Applications มี Mainstream Maintenance ถึงสิ้นปี 2027 โดยสำหรับแต่ละเวอร์ชันของ S/4HANA ควรตรวจ Product Availability Matrix และ Maintenance Strategy เพราะ Timeline แตกต่างกัน
2. ทุกครั้งที่ต้องต่อระบบใหม่ เจอ Compatibility Constraint มากขึ้น
เมื่อเวอร์ชันเก่า ระบบรอบข้างที่ใหม่ขึ้น เช่น OS, Database, Browser, Middleware, Security Component หรือ Third-party Add-on อาจไม่ได้รองรับ Combination เดิมต่อไป ทำให้ทีม IT ต้องล็อก Technology Stack ไว้กับ เวอร์ชัน เก่าหรือใช้วิธีแก้เฉพาะกิจ
หากการ Upgrade ระบบอื่นต้องถามก่อนเสมอว่า “SAP เวอร์ชัน นี้รองรับหรือไม่” และคำตอบเริ่มจำกัดทางเลือกของ Infrastructure นั่นคือสัญญาณว่า ERP Core กำลังกลายเป็น Constraint ของ Landscape
3. Custom Code และ Enhancement กลายเป็นภาระในการเปลี่ยนแปลง
ระบบที่ใช้งานนานมักสะสม Z-program, Enhancement, Interface และ Modification จำนวนมาก บางรายการไม่มี Owner หรือไม่มีผู้ใช้งานแล้ว แต่ทีมยังไม่กล้าลบเพราะไม่รู้ผลกระทบ
เมื่อทุก Patch หรือ Change Request ต้องใช้เวลาวิเคราะห์ Custom Code มากขึ้น Upgrade Project จะยิ่งแพงหากปล่อยให้ Technical Debt สะสมต่อ SAP Readiness Check และ ATC สามารถช่วยมองเห็น Custom Code Impact และ Compatibility ในบริบทการ Conเวอร์ชัน/Upgrade ได้
4. Performance และ Batch Window เริ่มไม่ทันธุรกิจ
Transaction Volume โตขึ้น แต่ Architecture และ Release เดิมอาจไม่ได้ถูกปรับให้เหมาะกับปริมาณงานปัจจุบัน องค์กรอาจเริ่มพบ Batch Job ใช้เวลานานขึ้น Report ทำงานช้า Month-end Closing ยาวขึ้น หรือมีช่วงเวลาที่ User ต้องหลีกเลี่ยงการทำงานบาง Process เพราะระบบรับ Load ไม่ไหว
Performance Issue ไม่ได้หมายความว่าต้อง Upgrade เสมอไป เพราะอาจเกิดจาก Code, Data Volume หรือ Infrastructure แต่หากทีมแก้จุดเดิมซ้ำ ๆ และ Technology Stack ปัจจุบันจำกัด Option ในการปรับปรุง ควรนำ Upgrade เข้ามาอยู่ใน Roadmap
5. Add-on และ Interface สำคัญเริ่มรองรับยาก
ระบบ SAP มักเชื่อมกับ WMS, MES, e-Tax, Bank, HR, CRM, POS หรือ Data Platform เมื่อ Partner หรือ Vendor ของระบบเหล่านี้เลิก Support เวอร์ชัน เก่า ความเสี่ยงจะไม่ได้อยู่แค่ SAP แต่ขยายไปทั้ง Ecosystem
สัญญาณที่ควรระวังคือ Vendor แจ้งว่าฟีเจอร์ใหม่รองรับเฉพาะ Release ใหม่, Interface ต้องใช้ Middleware เวอร์ชันที่ระบบเดิมไม่รองรับ หรือ Add-on ต้องอยู่บน Patch Level ที่สูงกว่า ERP ปัจจุบัน
6. Security และ Compliance Requirement ใหม่เริ่มทำได้ยาก
Security Landscape เปลี่ยนเร็วกว่า ERP Lifecycle องค์กรอาจต้องรองรับ Encryption, Identity, Audit, Patch หรือ Policy ใหม่ หาก เวอร์ชัน เก่าจำกัด Security Component หรือ Third-party Platform ที่รองรับ ความเสี่ยงจะเพิ่มขึ้นแม้ตัว ERP ยังใช้งานได้
ประเด็นนี้ควรประเมินร่วมกับ Security Team และ Vendor Matrix ไม่ควรสรุปเพียงจาก เวอร์ชัน Number เพราะบางความเสี่ยงเกิดจาก OS, Database หรือ Middleware ที่หมด Support ก่อน SAP Application
7. Business ต้องการ Innovation แต่ระบบเดิมต่อยอดได้ช้า
องค์กรอาจต้องการ Embedded Analytics, Fiori Experience, Automation, API Integration หรือ AI แต่ทุก Initiative ต้องสร้าง Workaround เพราะ Release ปัจจุบันไม่รองรับ Feature หรือ Architecture ที่ต้องการ หาก Innovation Backlog โตเร็วกว่าความสามารถของระบบเดิม Upgrade อาจสร้าง Business Value มากกว่าการแก้เฉพาะจุดต่อไป
ตั้งแต่ SAP S/4HANA 2023 SAP เปลี่ยน Release Cycle เป็นทุก 2 ปีและให้ Mainstream Maintenance 7 ปีต่อ Release พร้อม Feature Packages ในช่วงระหว่าง Release การวาง Upgrade Cadence จึงควรสัมพันธ์กับ Roadmap Innovation ไม่ใช่รอจนหมด Maintenance เท่านั้น
8. ค่าใช้จ่ายในการ “ไม่เปลี่ยน” เริ่มสูงกว่าค่า Upgrade
ระบบเก่ามักสร้าง Cost of Standing Still เช่น Manual Work, Downtime, Custom Maintenance, Specialized Skill, Hardware Renewal, Extended Support และ Opportunity Cost จาก Innovation ที่ทำไม่ได้ เมื่อต้นทุนเหล่านี้รวมกัน การเลื่อน Upgrade อาจไม่ได้ประหยัดเงินจริง
Checklist: หากพบกี่ข้อควรเริ่มวาง Roadmap
🔷 เข้าใกล้ Maintenance Milestone ที่สำคัญ
🔷 Landscape ใหม่เริ่มติด Compatibility Constraint
🔷 Custom Code ไม่มี Owner หรือใช้เวลาวิเคราะห์มากขึ้น
🔷 Performance / Batch Window กระทบ Operation
🔷 Add-on หรือ Interface สำคัญเริ่มไม่รองรับ
🔷 Security / Compliance ต้องใช้ Workaround
🔷 Business Initiative ใหม่ติดข้อจำกัดของ Release
🔷 Cost of Standing Still เพิ่มขึ้นทุกปี
หากพบ 2-3 ข้อพร้อมกัน ไม่ได้แปลว่าต้อง Upgrade ทันที แต่ควรเริ่ม Assessment เพื่อสร้างข้อมูลสำหรับ Budget และ Timeline หากพบหลายข้อและ Maintenance Window ใกล้เข้ามา การเลื่อนแผนอาจทำให้ Project กลายเป็นงานเร่งที่มีทางเลือกน้อยลง
ก่อน Upgrade SAP ควรตรวจอะไรบ้าง
1. ตรวจ Product, Release และ Maintenance Status ใน PAM / SAP Support
2. ทำ System Landscape Inventory รวม Add-on, Interface, OS, DB และ Middleware
3. วิเคราะห์ Custom Code และ Usage เพื่อหา Technical Debt ที่ควร Retire
4. ตรวจ Simplification / Compatibility และ Feature ที่มีผลต่อ Business Process
5. กำหนด Regression Test Scope และ Business Critical Scenario
6. วาง Downtime, Cutover, Fallback และ Communication Plan
7. ทำ Business Case เปรียบเทียบ Upgrade กับ Migration/Transformation หาก Scope เริ่มใหญ่
Upgrade หรือ Migration? อย่าใช้เวอร์ชันเป็นคำตอบเพียงอย่างเดียว
หากระบบเดิมยังตอบโจทย์ Business และเป้าหมายหลักคือกลับเข้าสู่ Technology / Maintenance ที่เหมาะสม การ Upgrade อาจเพียงพอ แต่ถ้า Pain Point มาจาก Process, Data Model, Customization และ Architecture เดิม การใช้โอกาสนี้ประเมิน Migration หรือ Transformation จะช่วยหลีกเลี่ยงการลงทุนเพื่อทำให้ระบบเดิม “ใหม่ขึ้น” โดยไม่ได้แก้ข้อจำกัดหลัก
FAQ: คำถามที่พบบ่อย
ไม่จำเป็นต้อง Upgrade เพียงเพราะระบบ SAP มีอายุการใช้งานนาน แต่ควรประเมิน Maintenance Status, Compatibility, Security, ประสิทธิภาพระบบ และความต้องการทางธุรกิจร่วมกัน หากระบบเริ่มมีข้อจำกัดหรือใกล้สิ้นสุดระยะการสนับสนุน ควรเริ่มวางแผน SAP Upgrade เพื่อประเมินความเสี่ยงและทางเลือกที่เหมาะสม
ควรเริ่มประเมินความพร้อมก่อนสิ้นสุดระยะ Mainstream Maintenance โดยระยะเวลาเตรียมการขึ้นอยู่กับความซับซ้อนของระบบ องค์กรที่มี Custom Code, Add-on และ Interface จำนวนมากควรเผื่อเวลาสำหรับการวิเคราะห์ผลกระทบ การทดสอบ การจัดสรรทรัพยากร และการวางงบประมาณ เพื่อให้สามารถดำเนินโครงการได้อย่างเป็นระบบ
SAP กำหนด Mainstream Maintenance สำหรับ SAP Business Suite 7 Core Applications ที่อยู่ในขอบเขตการสนับสนุนจนถึงวันที่ 31 ธันวาคม 2027 และมีทางเลือก Optional Extended Maintenance ถึงวันที่ 31 ธันวาคม 2030 ภายใต้เงื่อนไขและค่าบำรุงรักษาเพิ่มเติม องค์กรควรตรวจสอบ Product, Release และ Enhancement Package ที่ใช้งานจริงผ่าน SAP Product Availability Matrix (PAM)
ได้ SAP มี Readiness Check สำหรับทั้งการทำ System Conversion จาก SAP ERP 6.0 ไป SAP S/4HANA และการ Upgrade จาก SAP S/4HANA Release เดิมไปยัง Release ใหม่ โดยช่วยประเมินประเด็นสำคัญ เช่น Simplification Items, Custom Code และ Add-on Compatibility ทั้งนี้ ต้องเลือก Readiness Check ให้ตรงกับประเภทโครงการและตรวจสอบผลร่วมกับข้อกำหนดของระบบเป้าหมาย
ขึ้นอยู่กับระบบปัจจุบันและเป้าหมายขององค์กร หากใช้งาน SAP ERP หรือ SAP ECC และต้องการเปลี่ยนไป SAP S/4HANA ควรเปรียบเทียบแนวทาง System Conversion, Selective Data Transition และ New Implementation โดยพิจารณา Business Process, Custom Code, Data และ Integration ส่วนองค์กรที่ใช้ SAP S/4HANA อยู่แล้ว ควรประเมินความเหมาะสมของ Release Upgrade ตามข้อกำหนดและความต้องการทางธุรกิจ
ปรึกษาทีม NEXUS เพื่อวิเคราะห์กระบวนการ Upgrade SAP สำหรับองค์กรของคุณได้ที่
โทร: 02-091-1900
Line OA: @nexus-sr.com (มี @)
อีเมล: mkt.th@nexus-sr.com
