ก่อน Go-live S/4HANA ควรเช็คให้พร้อม! นี่คือสิ่งที่ ABAP ต้องระวัง

SAP ECC กำลังเข้าสู่ช่วงปลายของการสนับสนุน ซึ่งเป็นจุดเปลี่ยนสำคัญที่ทำให้องค์กรจำนวนมากเริ่มเร่งวางแผนย้ายระบบไปสู่ SAP S/4HANA อย่างจริงจัง เพื่อรองรับความต้องการของธุรกิจในยุคที่ Data ต้องถูกใช้งานแบบ Real-time และการแข่งขันมีความรวดเร็วมากขึ้นกว่าที่เคย การตัดสินใจย้ายระบบในครั้งนี้ จึงไม่ได้เป็นเพียงเรื่องของการอัปเกรดเทคโนโลยี แต่เป็นการวางรากฐานใหม่ให้กับการดำเนินธุรกิจในระยะยาว ทั้งในด้านความเร็ว ความยืดหยุ่น และความสามารถในการนำข้อมูลมาใช้สร้างความได้เปรียบทางการแข่งขัน

อย่างไรก็ตาม สิ่งที่หลายองค์กรมักมองข้ามคือ การย้ายไปสู่ S/4HANA ไม่ได้หมายถึงแค่ “การเปลี่ยนระบบหลังบ้าน” เท่านั้น แต่คือการเปลี่ยน “แนวคิดในการพัฒนาและใช้งานระบบ” อย่างมีนัยสำคัญ โดยเฉพาะในส่วนของ Custom ABAP ซึ่งเป็นหัวใจสำคัญที่องค์กรใช้ต่อยอดระบบ SAP ให้สอดคล้องกับกระบวนการทำงานของตนเองมานานหลายปี โค้ดและ Logic ที่เคยใช้งานได้ดีในระบบเดิม อาจไม่สามารถนำมาใช้ต่อได้โดยตรง หรืออาจต้องมีการปรับปรุงเพื่อให้สอดคล้องกับสถาปัตยกรรมใหม่ของ S/4HANA ดังนั้น การทำความเข้าใจการเปลี่ยนแปลงในมุมของ ABAP ตั้งแต่ต้น ไม่เพียงช่วยลดความเสี่ยงในการย้ายระบบ แต่ยังเป็นกุญแจสำคัญที่จะทำให้องค์กรสามารถใช้ศักยภาพของ S/4HANA ได้อย่างเต็มประสิทธิภาพตั้งแต่วันแรกของการ Go-live

จาก SAP ECC ไปสู่ SAP S/4HANA ไม่ใช่เพียงแค่การอัพเกรดระบบตามวงจรเทคโนโลยี แต่นี่คือการก้าวข้ามขีดจำกัดเดิมๆ ไปสู่แนวคิด “Digital Core” ที่เน้นความเร็วระดับ Real-time หากคุณเป็นนักพัฒนาหรือผู้บริหารที่กำลังตั้งคำถามว่า “Custom Code เดิมยังไปต่อได้ไหม?” บทความนี้มีคำตอบที่ชัดเจนครับ

โครงสร้างข้อมูลเปลี่ยน (Data Model) 

เมื่อย้ายมา S/4HANA สิ่งแรกที่ต้องรู้คือ “โครงสร้างข้อมูลไม่เหมือนเดิมแล้ว” 

รูปที่ 1 การเปรียบเทียบโครงสร้างข้อมูลระหว่าง SAP ECC และ S/4HANA [1] 

จากภาพจะเห็นว่าในระบบ SAP ECC มีการจัดเก็บข้อมูลแยกออกเป็นหลายประเภท เช่น Hybrid Tables, Aggregate Tables และ History Tables รวมถึงข้อมูล Material Document ที่ต้องอาศัยหลาย Table ในการทำงานร่วมกัน แต่ใน S/4HANA โครงสร้างเหล่านี้ถูกลดความซับซ้อนลงอย่างมาก โดยมีการรวมข้อมูลหลักไว้ใน Table ที่สำคัญ เช่น MATDOC แนวคิดนี้เรียกว่า Data Simplification ซึ่งช่วยให้ระบบมี Single Source of Truth ลดความซับซ้อนของโครงสร้างข้อมูล และทำให้การพัฒนาโปรแกรมมีประสิทธิภาพมากยิ่งขึ้น 

สำหรับฝั่ง ABAP สิ่งที่ต้องระวังคือ

• การ SELECT จาก Table แบบเดิมอาจใช้ไม่ได้  

• Logic ที่อิงหลาย Table ต้องถูกปรับใหม่ 

ในขณะที่มุมธุรกิจจะได้ประโยชน์จาก

• รายงานที่เร็วขึ้น  

• ข้อมูลที่สอดคล้องกันมากขึ้น  

• รองรับการทำงานแบบ Real-time ได้ดีขึ้น  

ดังนั้น แนวทางที่เหมาะสมคือการหลีกเลี่ยงการอ้างอิง Table โดยตรง และเปลี่ยนมาใช้ CDS View หรือเครื่องมือมาตรฐานของระบบแทน 

 Key Takeaway: ลดจำนวน table → ลดความซับซ้อน → ต้องเปลี่ยนวิธีดึงข้อมูล

แนวคิดเรื่อง Performance เปลี่ยนไป 

S/4HANA มีประสิทธิภาพที่สูงขึ้นอย่างชัดเจน แต่ระดับความเร็วในการทำงานยังคงขึ้นอยู่กับ “วิธีการพัฒนาโปรแกรม” ในระบบ SAP ECC โดยทั่วไปมักมีการดึงข้อมูลออกมาประมวลผลในฝั่ง ABAP แต่ใน S/4HANA มีแนวคิดที่เปลี่ยนไป โดยเน้นให้ฐานข้อมูล (Database) เป็นผู้จัดการการประมวลผลตั้งแต่ต้น 

พูดง่าย ๆ คือ จาก “ดึงข้อมูลมาคำนวณ” เปลี่ยนเป็น “ให้ Database คำนวณให้ตั้งแต่ต้น” 

แนวคิดนี้เรียกว่า Code Push-down ซึ่งเป็นการย้าย logic ไปทำงานที่ Database แทน ABAP layer หากยังคงใช้วิธีการเดิม เช่น การใช้ LOOP ร่วมกับ SELECT ซ้ำ ๆ (SELECT inside LOOP) อาจทำให้ระบบทำงานช้าลงโดยไม่จำเป็น และไม่สามารถใช้ประโยชน์จากศักยภาพของ HANA ได้อย่างเต็มที่ 

Key Takeaway: เขียน Code แบบเดิม = ช้า / ใช้ Code Push-down = ได้ Performance เต็ม HANA

โปรแกรมเดิมอาจไม่สามารถใช้งานได้ทั้งหมดใน S/4HANA 

อีกหนึ่งประเด็นสำคัญที่ต้องพิจารณาคือ โปรแกรมเดิมอาจไม่สามารถใช้งานได้ทั้งหมดหลังการย้ายไปสู่ S/4HANA เนื่องจากในระบบ S/4HANA มีการเปลี่ยนแปลงทั้งในด้านโครงสร้างข้อมูล ฟังก์ชันการทำงาน และแนวทางการพัฒนา ทำให้บาง Function ถูกยกเลิก บาง Transaction ไม่ถูกใช้งานต่อ หรือบาง Logic อาจให้ผลลัพธ์ที่แตกต่างจากเดิม ดังนั้น ไม่ควร assume ว่า Custom ABAP เดิมทั้งหมดจะสามารถใช้งานได้เหมือนเดิมโดยไม่ต้องปรับปรุง 

ความเสี่ยงที่อาจเกิดขึ้นในมุมธุรกิจ ได้แก่

• ระบบบางส่วนไม่สามารถใช้งานได้หลัง Go-live 

• กระทบต่อกระบวนการทำงานหลักขององค์กร 

• เกิดความคลาดเคลื่อนของข้อมูลหรือผลลัพธ์ 

แนวทางที่แนะนำคือ การตรวจสอบระบบล่วงหน้าโดยใช้เครื่องมือมาตรฐาน เช่น SAP Readiness Check เพื่อวิเคราะห์ว่า Custom Code หรือ Function ใดได้รับผลกระทบ และควรได้รับการปรับปรุงก่อนการขึ้นระบบจริง 

 Key Takeaway: Custom เดิมใช้ได้ไม่ทั้งหมด → ต้องตรวจสอบก่อน ไม่ใช่หลัง Go-live

ต้องมีการตรวจสอบและปรับปรุง Custom Code 

Custom Code เป็นจุดที่มี Impact มากที่สุดในการย้ายระบบ อย่างไรก็ตาม ไม่ได้หมายความว่าจำเป็นต้องปรับแก้ทุกส่วน สิ่งสำคัญคือ ต้องสามารถแยกให้ได้ว่าอะไรคือส่วนที่ “สำคัญ” และอะไรคือส่วนที่สามารถ “รอได้” โดยมี แนวทางที่แนะนำโดยทั่วไป ได้แก่ 

• ตรวจสอบ Custom Code ทั้งระบบ 

• วิเคราะห์ผลกระทบ (Impact Analysis) 

• Prioritize และแก้ไขเฉพาะส่วนที่จำเป็น 

เครื่องมืออย่าง ATC (ABAP Test Cockpit) สามารถช่วยสแกนและวิเคราะห์ Custom Code เพื่อระบุความเสี่ยงหรือความไม่สอดคล้องกับ S/4HANA เช่น การใช้งาน table ที่ถูกยกเลิก ซึ่งช่วยให้สามารถจัดลำดับความสำคัญของการปรับปรุงได้อย่างมีประสิทธิภาพ 
ในมุมธุรกิจ แนวทางนี้ช่วยลดความเสี่ยงหลังขึ้นระบบ, ควบคุมงบประมาณได้อย่างเหมาะสม ทำให้โครงการสามารถดำเนินไปได้อย่างรวดเร็วและมีประสิทธิภาพ 

 Key Takeaway: ไม่ต้องแก้ทุกอย่าง → แต่ต้องรู้ว่า “อะไรต้องแก้ก่อน” 

การจัดการสิทธิ์การใช้งาน (Authorization) 

อีกหนึ่งประเด็นสำคัญที่ต้องพิจารณาคือ การจัดการสิทธิ์การใช้งาน ซึ่งใน S/4HANA มีการเปลี่ยนแปลงทั้งในมุมของระบบและรูปแบบการใช้งาน แม้แนวคิด Role-based Authorization จะยังคงเหมือนเดิม แต่ใน S/4HANA มีการใช้งานผ่าน SAP Fiori มากขึ้น ส่งผลให้การกำหนดสิทธิ์ไม่ได้จำกัดอยู่เพียงระดับ Transaction (SAP GUI) อีกต่อไป แต่ครอบคลุมถึง Fiori App รวมถึง Fiori Catalog และข้อมูลที่แสดงผล สิ่งที่ต้องคำนึงถึง มีดังนี้

• Role เดิมอาจไม่ครอบคลุมการใช้งานใน Fiori 

• การเข้าถึงข้อมูลจำเป็นต้องควบคุมในระดับที่ละเอียดมากขึ้น 

• ต้องทดสอบสิทธิ์ร่วมกับ Scenario การใช้งานจริง 

ในมุมธุรกิจ หากไม่มีการวางแผนด้าน Authorization อย่างเหมาะสม อาจทำให้ผู้ใช้งานไม่สามารถเข้าถึงข้อมูลที่จำเป็น หรือในทางกลับกัน อาจเข้าถึงข้อมูลที่ไม่ควรเห็น ดังนั้น ควรวางแผน ออกแบบ และทดสอบสิทธิ์ควบคู่ไปกับการพัฒนาและปรับปรุงระบบ เพื่อให้มั่นใจว่าผู้ใช้งานสามารถทำงานได้อย่างถูกต้อง ปลอดภัย และสอดคล้องกับบทบาทหน้าที่ 

Key Takeaway: สิทธิ์ไม่ได้จบที่ Transaction → ต้องครอบคลุม Fiori App และ Data

การย้ายไปสู่ S/4HANA ไม่ใช่เพียงการเปลี่ยนระบบ แต่เป็นการปรับแนวคิดในการพัฒนาและการใช้งานให้สอดคล้องกับสถาปัตยกรรมใหม่ สำหรับองค์กรที่กำลังวางแผนย้ายระบบ การเริ่มต้นด้วยการวิเคราะห์ผลกระทบ (Impact Analysis) และวางแผนให้ชัดเจนตั้งแต่ต้น จะช่วยให้มองเห็นภาพรวมได้ดีขึ้น และสนับสนุนการตัดสินใจในแต่ละขั้นตอนให้มีประสิทธิภาพมากยิ่งขึ้น องค์กรที่สามารถวางแผนและวิเคราะห์ผลกระทบอย่างเป็นระบบตั้งแต่ต้น จะสามารถลดความเสี่ยง ควบคุมต้นทุน และเพิ่มโอกาสความสำเร็จของโครงการได้อย่างมีนัยสำคัญ 

Reference [1] https://help.sap.com/docs/SUPPORT_CONTENT/erpscm/3362167285.html