SAP BTP คืออะไร? รู้จัก Cloud Platform ที่ทำให้ต่อยอด SAP ได้โดยไม่ต้องรื้อระบบเดิม

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

ผู้บริหารหลายท่านอาจรู้สึกเหมือนกันหมดครับ

ทีมไอทีพูดกันเอง ใช้ศัพท์เทคนิคกันสนุก แล้วก็ไม่มีใครหยุดอธิบายให้คนที่ต้องอนุมัติงบเข้าใจจริงๆ ครับ

คำถามที่มักตามมาก็คือ “ต้องรู้เรื่องนี้ลึกแค่ไหน” กับ “มันเกี่ยวอะไรกับงบประมาณที่กำลังจะขออนุมัติ” สองคำถามนี้สมเหตุสมผลมากครับ บทความนี้ถูกเขียนขึ้นมาเพื่อตอบทั้งสองข้อ พร้อมบอกว่าทำไมเรื่องนี้ถึงสำคัญกว่าที่คิดในช่วง 1-2 ปีข้างหน้าครับ

SAP BTP คืออะไร แบบเข้าใจง่ายที่สุด

SAP BTP ย่อมาจาก SAP Business Technology Platform ครับ เป็นแพลตฟอร์มกลางที่ SAP สร้างขึ้นมาให้บริษัทต่างๆ เอาไปต่อยอด เชื่อมต่อ และสร้างของใหม่รอบๆ ระบบ SAP หลักของตัวเอง โดยไม่ต้องไปแก้ไขโค้ดในระบบหลักโดยตรง 

ผมขออธิบายแบบนี้ครับ ลองนึกภาพระบบ S/4HANA เป็น “บ้านหลังหลัก” ที่คุณสร้างมาอย่างดี อยากให้อยู่ได้นานๆ โดยไม่ต้องทุบผนังบ่อยๆ 

แล้วปัญหาคืออะไร? ก็คือในอดีตนั่นแหละครับ ทุกครั้งที่ธุรกิจต้องการฟังก์ชันพิเศษ รายงานเฉพาะ หรือระบบเชื่อมต่อกับโปรแกรมอื่น ทีมไอทีมักแก้ปัญหาด้วยการเข้าไป “เจาะผนัง” เขียน Custom Code แทรกเข้าไปในระบบหลักตรงๆ ครับ 

ถามว่าได้ผลไหม? ได้ครับ ในระยะสั้น แต่สะสมไปเรื่อยๆ มันกลายเป็นภาระหนัก เพราะทุกครั้งที่ SAP ออกเวอร์ชันใหม่หรือแพตช์ความปลอดภัย ทีมไอทีต้องมานั่งไล่เช็คว่าโค้ดที่เคยแก้ไว้จะพังหรือเปล่า ใครเคยผ่านโปรเจกต์อัปเกรด SAP มาจะรู้ดีว่ามันเจ็บปวดและใช้งบประมาณเยอะขนาดไหนครับ 

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

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

พูดให้ตรงจุดที่สุดครับ BTP ไม่ใช่ระบบ ERP ที่มาแทน S/4HANA และไม่ใช่โปรแกรมที่ใช้แยกเดี่ยวๆ มันคือ ชุดเครื่องมือ ที่รวมความสามารถด้านการจัดการข้อมูล การวิเคราะห์ การพัฒนาแอป การเชื่อมต่อระบบ การทำงานอัตโนมัติ และ AI ไว้บนแพลตฟอร์มคลาวด์เดียว เพื่อให้ทีมไอทีต่อยอดระบบหลักได้เร็วขึ้นโดยไม่กระทบความเสถียรของระบบเดิมครับ 

แล้วบน BTP มีอะไรอยู่บ้าง? ภาพรวมของ Component หลัก

พอเข้าใจว่า BTP คือ “พื้นที่ต่อเติม” แล้ว คำถามต่อไปที่ผมมักเจอคือ “แล้วข้างในมันมีอะไร?” 

SAP อธิบายจุดเด่นของ BTP ไว้ 5 ข้อหลักครับ ไม่จำเป็นต้องจำทั้งหมด แต่ถ้ารู้ 5 ข้อนี้ จะคุยกับทีมไอทีได้ตรงจุดขึ้นเยอะเลยครับ 

1. เชื่อมต่อกับระบบ SAP ได้เนียนตั้งแต่ต้น (Integration with SAP systems) 

BTP ถูกออกแบบมาให้เชื่อมกับ S/4HANA และผลิตภัณฑ์อื่นของ SAP ได้โดยตรงครับ ทำให้งานพัฒนาใหม่ไม่ต้องเริ่มจากศูนย์ ตรงนี้ต่างจากการเอาแพลตฟอร์มข้างนอกมาเชื่อมเอง ซึ่งมักต้องเขียน connector เยอะกว่ามาก 

2. มีเนื้อหาสำเร็จรูปให้เริ่มต้นเร็ว (Pre-defined business content) 

มาพร้อมเทมเพลตแอป กระบวนการอัตโนมัติสำเร็จรูป และของที่ใช้งานได้ทันทีจำนวนมากครับ ทีมพัฒนาไม่ต้องสร้างทุกอย่างขึ้นมาใหม่ตั้งแต่ต้น ซึ่งมันแปลตรงๆ ว่าลดเวลาและลดงบที่ใช้ในโครงการ 

3. เครื่องมือพัฒนาแอปครบมือ (Application development services) 

ครอบคลุมทั้งเครื่องมือสำหรับทีมที่เขียนโค้ดเอง และแนวทาง Low-code/No-code สำหรับงานที่ต้องการความเร็วมากกว่าความซับซ้อนครับ เป็นส่วนที่ทีมพัฒนาใช้สร้างแอป เวิร์กโฟลว์ หรือระบบอัตโนมัติเฉพาะทาง แยกออกจากระบบหลัก 

4. การวิเคราะห์ข้อมูลขั้นสูง รวมถึง AI/ML (Advanced analytics) 

รวมความสามารถด้านการจัดการข้อมูล วิเคราะห์ และ AI ไว้ด้วยกันครับ ดึงข้อมูลจากหลายระบบมาสรุปเป็นข้อมูลเชิงลึกที่ใช้ตัดสินใจได้ ผู้ช่วย AI ของ SAP อย่าง Joule กับฟีเจอร์ AI หลายส่วนที่ผนวกเข้ากับ S/4HANA รุ่นใหม่ ก็พัฒนาอยู่บนโครงสร้างส่วนนี้ครับ 

5. ความปลอดภัยมาให้ในตัว (Built-in security) 

มีมาตรการด้านความปลอดภัยตั้งแต่ระดับแพลตฟอร์มเลยครับ ปกป้องข้อมูล แอปพลิเคชัน และการเข้าถึงระบบ ช่วยให้สร้างโซลูชันที่ปลอดภัยและตรงตามข้อกำหนดได้ง่ายขึ้น 

สิ่งที่ผมอยากให้เก็บกลับไปจากส่วนนี้ไม่ใช่ชื่อผลิตภัณฑ์ครับ แต่คือภาพว่า BTP มีจุดเด่นเป็นระบบชัดเจน ไม่ใช่กล่องดำที่ทีมไอทีหยิบมาใช้ตามใจชอบ และที่สำคัญ แต่ละองค์กรไม่จำเป็นต้องใช้ทุกข้อพร้อมกัน เริ่มจากข้อที่ตรงกับปัญหาเร่งด่วนที่สุดก่อนได้ครับ 

แล้วอย่างที่จะเห็นในหัวข้อถัดไป งานพัฒนาแอปในข้อ 3 บางประเภทก็ไม่จำเป็นต้องทำบน BTP เสมอไปนะครับ ถ้าทำในระบบหลักได้เหมาะสมกว่า ก็ทำได้เลย

ทำไมผู้บริหารต้องรู้จัก BTP ตอนนี้ ไม่ใช่ปีหน้า 

เหตุผลที่คำนี้โผล่มาบ่อยขึ้นไม่ใช่เรื่องบังเอิญครับ มันผูกกับกำหนดเวลาที่หลายคนในวงการรู้กันดีครับ SAP จะยุติ Mainstream Support ของระบบ ECC แบบดั้งเดิมในช่วงปลายปี 2027 

ฟังดู เหลืออีกตั้งเกือบปีครึ่ง? ครับ แต่ใครที่เคยทำโปรเจกต์ย้ายระบบ SAP มาก่อนจะรู้ว่าระยะเวลาเกือบปีครึ่งนั้น ไม่เหลือเฟือเลย ครับ โดยเฉพาะถ้ายังไม่เริ่มวางแผน ตอนนี้องค์กรจำนวนมากในไทยกำลังอยู่ในช่วงวางแผนหรือดำเนินการย้ายไปสู่ S/4HANA อย่างจริงจัง และหลายบริษัทที่ยังไม่เริ่มก็เริ่มถูกกดดันด้วยกรอบเวลาที่เหลืออยู่ครับ 

ทีนี้ประเด็นที่ผู้บริหารต้องรู้คือ SAP แนะนำแนวทางที่เรียกว่า “Clean Core” หลักการง่ายๆ คือรักษาแกนกลางของระบบให้สะอาด ไม่ถูกดัดแปลงเฉพาะกิจแบบที่หลายองค์กรทำกันมานานหลายสิบปีครับ เพราะการดัดแปลงโค้ดแบบนั้นคือสาเหตุหลักที่ทำให้อัปเกรดยาก ใช้เวลานาน งบบานปลาย และเสี่ยงตอน Go-Live 

นี่คือจุดที่ BTP เข้ามามีบทบาทครับ 

แต่เดี๋ยวก่อนครับ ต้องเคลียร์ความเข้าใจผิดที่พบบ่อยก่อนครับ 

Clean Core ไม่ได้แปลว่า ห้ามพัฒนาอะไรในระบบหลักอีกเลย และ ไม่ได้แปลว่าต้องยกงานพัฒนาทั้งหมดออกไปไว้บน BTP 

ผมเน้นตรงนี้เพราะเจอคนเข้าใจผิดเยอะมากจริงๆ ครับ 

สิ่งที่ Clean Core ห้ามจริงๆ คือการ “ดัดแปลง” ของที่ SAP ให้มา คือการเข้าไปแก้โปรแกรมมาตรฐานของ SAP โดยตรง หรือไปเกาะกับโครงสร้างภายในที่ SAP ไม่ได้เปิดให้ใช้อย่างเป็นทางการ ของพวกนี้เปลี่ยนได้ทุกเวอร์ชันโดยไม่แจ้งล่วงหน้าครับ พังเมื่อไหร่ก็ไม่มีใครรับผิดชอบให้ 

ส่วนการเขียนโปรแกรมของตัวเองขึ้นมาใหม่ โดยเชื่อมกับระบบหลักผ่านช่องทางมาตรฐานที่ SAP รับรอง? ทำได้ตามปกติครับ ทำได้ทั้งในระบบหลักเองและบน BTP

คำถามที่แท้จริงจึงไม่ใช่ “ควรพัฒนาในระบบหลักหรือบน BTP อันไหน ถูกต้องกว่า” ครับ เพราะทั้งสองทางถูกทั้งคู่ถ้าทำตามมาตรฐาน แต่คำถามที่ควรถามคือ “งานพัฒนาแต่ละชิ้นควรวางไว้ตรงไหนจึงจะเหมาะกับลักษณะของงานนั้น” และคำตอบนี้ควรถูกวางไว้ตั้งแต่ขั้นตอนวางแผน ไม่ใช่มาคิดทีหลังตอน Go-Live ไปแล้วครับ 

โดยทั่วไปแนวทางที่ใช้พิจารณาก็ไม่ได้ซับซ้อนมากครับ:

ทั้งนี้ควรให้ทีมที่ปรึกษาประเมินเป็นรายกรณีครับ แต่ละองค์กรมีบริบทต่างกัน

BTP ทำอะไรได้บ้างที่ส่งผลต่อธุรกิจจริง

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

การเชื่อมต่อกับระบบ SAP และระบบอื่น: อันนี้เป็นจุดที่ผมเห็นองค์กรได้ประโยชน์ชัดสุดครับ หลายบริษัทมีทั้ง SAP และซอฟต์แวร์อื่นที่ใช้อยู่ เช่น ระบบ CRM ระบบ HR หรือระบบของคู่ค้า BTP ทำหน้าที่เป็นตัวกลางเชื่อมข้อมูลให้ไหลถึงกันโดยอัตโนมัติ ลดงานป้อนข้อมูลซ้ำที่พนักงานต้องทำมือ แบบที่ทุกคนบ่นมาตลอดแต่ไม่เคยมีใครแก้ได้จริงจังครับ 

เนื้อหาสำเร็จรูป: เทมเพลตและกระบวนการอัตโนมัติที่ SAP เตรียมไว้ให้ ช่วยย่นเวลาโครงการได้จริงครับ องค์กรไม่ต้องจ้างทีมพัฒนามาสร้างทุกอย่างตั้งแต่ศูนย์ ซึ่งส่งผลตรงต่องบประมาณและ timeline ของโครงการ 

การพัฒนาแอปพลิเคชันและระบบอัตโนมัติ: ทีมไอทีสร้างแอปหรือระบบอัตโนมัติเฉพาะทางได้เร็วขึ้น โดยไม่ต้องรอคิวพัฒนาในระบบหลักซึ่งมักมีขั้นตอนอนุมัติและทดสอบยาวกว่ามากครับ แต่ว่า ผลลัพธ์แบบเดียวกันนี้ บางกรณีก็ทำได้ดีไม่แพ้กันด้วยการพัฒนาในระบบหลักเอง ขึ้นอยู่กับลักษณะงานตามที่อธิบายไว้ข้างต้น ไม่ใช่ว่าต้องใช้ BTP เสมอไปครับ 

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

ตัวอย่างเช่น ฝ่ายขาย ฝ่ายคลังสินค้า และฝ่ายการเงิน อาจดูข้อมูลชุดเดียวกันแบบเรียลไทม์ได้เลยครับ 

และที่น่าสนใจคือ ความสามารถด้าน AI ที่ SAP ผนวกเข้ากับ S/4HANA รุ่นใหม่ เช่น ผู้ช่วย AI อย่าง Joule ก็พัฒนาอยู่บนโครงสร้างเดียวกันนี้ครับ องค์กรที่วางรากฐาน BTP ไว้ล่วงหน้าจึงเข้าถึงฟีเจอร์เหล่านี้ได้สะดวกกว่า ตรงนี้เป็นเหตุผลที่ควรคิดไว้ตั้งแต่ตอนนี้ ไม่ใช่ตอนที่ AI กลายเป็นของจำเป็นไปแล้ว 

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

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

ตัวอย่างสถานการณ์ที่ผู้บริหารมักเจอ

ผมลองยกตัวอย่างนะครับ 

สมมติบริษัทกำลังวางแผนย้ายจาก ECC ไปสู่ S/4HANA ฝ่ายบัญชีมีรายงานเฉพาะที่พัฒนาขึ้นเองมากว่าสิบปี ใช้ประกอบการปิดงบทุกเดือน ยังไงก็ตัดไม่ได้ ต้องมีต่อครับ 

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

ทางออกที่ถูกต้องมี 2 ทาง ขึ้นอยู่กับลักษณะงาน: 

ทางที่ 1: ถ้ารายงานนี้ต้องดึงข้อมูลธุรกรรมจากระบบหลักโดยตรงและมีตรรกะผูกกับข้อมูลบัญชีอย่างแนบแน่น → เขียนโปรแกรมใหม่ในระบบหลักเอง โดยเชื่อมผ่านช่องทางมาตรฐานที่ SAP รับรอง ก็ปลอดภัยต่อการอัปเกรดไม่แพ้กันครับ 

ทางที่ 2: ถ้ารายงานนี้ต้องรวมข้อมูลจากระบบอื่นนอก SAP ด้วย เช่น ระบบ POS หรือระบบของคู่ค้า → พัฒนาแยกออกไปบน BTP มักจะเหมาะกว่า เพราะออกแบบมาสำหรับงานเชื่อมต่อหลายระบบโดยเฉพาะครับ 

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

คำถามที่ผู้บริหารมักถามเวลาได้ยินคำว่า BTP ครั้งแรก

ผมรวบรวมคำถามที่เจอบ่อยมาให้ครับ: 

“BTP เป็นค่าใช้จ่ายเพิ่มที่ต้องจ่ายแยกหรือเปล่า?” 

ใช่ครับ BTP มีโครงสร้างค่าใช้จ่ายของตัวเองแยกจากไลเซนส์ S/4HANA โดยทั่วไปคิดตามการใช้งานจริงของแต่ละบริการที่เลือกใช้ ราคาที่แน่นอนขึ้นอยู่กับบริการและปริมาณการใช้งานของแต่ละองค์กร 

“บริษัทจำเป็นต้องใช้ BTP ทันทีไหม?” 

ไม่จำเป็นครับ และผมไม่อยากให้ใครตกใจไปเพราะคำว่า “ต้องทำเดี๋ยวนี้” หลายองค์กรพัฒนางานส่วนใหญ่ในระบบหลักต่อไปได้ตามปกติ แล้วค่อยเพิ่ม BTP เฉพาะงานที่เหมาะสม สิ่งสำคัญ กว่า การรีบใช้ BTP คือการวางแนวทาง Clean Core ให้ถูกต้องตั้งแต่ต้นครับ ไม่ว่าจะเลือกทำแบบใด 

“ต่างจาก S/4HANA ยังไง?” 

S/4HANA = ระบบ ERP หลักที่ใช้บริหารจัดการธุรกิจ (บัญชี คลังสินค้า การผลิต) 

BTP = แพลตฟอร์มที่อยู่ “ข้างๆ” ระบบหลัก ใช้ต่อยอด เชื่อมต่อ และพัฒนาสิ่งใหม่ 

ไม่ใช่ระบบที่มาแทนกันครับ ทำงานร่วมกัน 

“ถ้าไม่ใช้ BTP เลย ระบบจะยังอัปเกรดได้อย่างปลอดภัยไหม?” 

ได้ครับ ตอบสั้นๆ เลย ได้ ถ้างานพัฒนาทั้งหมดยังคงเขียนโปรแกรมใหม่ในระบบหลัก โดยเชื่อมผ่านช่องทางมาตรฐานที่ SAP รับรอง แทนที่จะดัดแปลงโปรแกรมมาตรฐานโดยตรง ระบบก็ยังสะอาดและอัปเกรดได้อย่างปลอดภัยเหมือนกันครับ 

BTP ไม่ใช่เงื่อนไขบังคับ แต่เป็นทางเลือกที่เหมาะกับงานบางประเภทมากกว่า สิ่งที่ควรหลีกเลี่ยง จริงๆ ไม่ใช่การไม่ใช้ BTP ครับ แต่คือการดัดแปลงโค้ดในระบบหลักแบบเก่าที่ไม่ผ่านมาตรฐานใดๆ เลย

บทสรุป

เอาจริงๆ ครับ สิ่งที่ต้องจำจากบทความนี้มีอยู่ไม่กี่ข้อ: 

หนึ่ง BTP ไม่ใช่ระบบแยกที่ต้องตัดสินใจซื้อเพิ่มแบบเร่งด่วน และไม่ใช่ทางเลือกเดียวที่ทำให้ระบบสะอาด มันเป็นส่วนหนึ่งของการวางแผนระยะยาวว่าบริษัทจะดูแลระบบ SAP ของตัวเองอย่างไรหลังปี 2027 ครับ 

สอง คำถามที่ถูกต้องไม่ใช่ “ต้องใช้ BTP ไหม” แต่คือ “งานพัฒนาแต่ละชิ้นของเราควรอยู่บนระบบหลักหรือแยกออกไปบน BTP” วางตั้งแต่ตอนแผน ไม่ใช่ตอน Go-Live ไปแล้วครับ 

สาม สิ่งที่ต้อง หลีกเลี่ยง จริงๆ คือการดัดแปลงโปรแกรมมาตรฐานของ SAP โดยตรงแบบไม่ผ่านมาตรฐานใดๆ ครับ นี่คือสาเหตุหลักที่ทำให้อัปเกรดในอดีตใช้เวลานาน งบบานปลาย และเสี่ยงตอน Go-Live ไม่ใช่เรื่องของ BTP หรือไม่ BTP 

ในฐานะผู้บริหาร สิ่งที่ทำได้ทันทีหลังอ่านบทความนี้ไม่ใช่การไปเรียนรู้ BTP ด้วยตัวเองครับ แต่คือการตรวจสอบว่า ทีมพัฒนา ABAP ขององค์กรคุณ ซึ่งเป็นกลุ่มที่ต้องปรับตัวมากที่สุดในการเปลี่ยนผ่านนี้ มีความเข้าใจแนวคิด Clean Core และแนวทางการพัฒนาบน S/4HANA ที่ถูกต้องแล้วหรือยัง 

ต่อให้ผู้บริหารวางกลยุทธ์ไว้ดีแค่ไหน ถ้าทีมพัฒนายังเขียนโค้ดแบบเดิมที่เคยใช้กับ ECC ปัญหาเดิมก็จะกลับมาในการอัปเกรดครั้งถัดไป ไม่ว่าจะเพิ่ม BTP ในอนาคตหรือไม่ก็ตาม ทักษะ Clean Core ในระบบหลักคือพื้นฐานที่ต้องมีอยู่แล้วครับ 

หากยังรู้สึกว่าทีมพัฒนา ABAP ขององค์กรยังมีความเข้าใจเรื่องนี้ไม่มากพอ
ZyGen มีบริการ ABAP Workshop หลักสูตรอบรมสำหรับองค์กรที่มีทีมพัฒนา ABAP อยู่แล้วครับ ครอบคลุม:

ไม่ว่าองค์กรจะใช้ BTP ร่วมด้วยในอนาคตหรือไม่ก็ตามครับ 

หากกำลังวางแผนย้ายระบบหรืออยู่ระหว่างทบทวนแนวทาง Clean Core แล้วสนใจให้ทีม ZyGen ช่วยประเมินว่าแต่ละงานควรอยู่บนระบบหลักหรือแยกไปบน BTP
กรอกฟอร์มด้านล่างได้เลยครับ