SAP Approval Standard_Cover

ทำไมระบบอนุมัติของ SAP Standard ถึงมักเอาไม่อยู่ในองค์กรไทย?

ระบบอนุมัติของ SAP Standard มักไม่ตอบโจทย์องค์กรไทย เพราะถูกออกแบบบนสมมติฐานของโครงสร้างองค์กรแบบสากลที่เรียบง่ายและตายตัว ในขณะที่องค์กรไทยมีโครงสร้างลำดับขั้นการอนุมัติหลายชั้น มีเงื่อนไขซับซ้อนตามวงเงิน ประเภทเอกสาร และวัฒนธรรมการทำงานที่ยืดหยุ่นสูง ทางออกที่ยั่งยืนคือการเริ่มจากแนวคิด Fit-to-Standard ออกแบบกระบวนการให้เรียบง่าย และใช้ประโยชน์จาก SAP Flexible Workflow ให้เต็มศักยภาพ ก่อนตัดสินใจพัฒนาเพิ่มเติม 

ปัญหาที่องค์กรไทยมักพบกับระบบอนุมัติของ SAP 

SAP ถูกออกแบบตามแนวคิด SAP Best Practice และ Fit-to-Standard เพื่อช่วยให้องค์กรใช้กระบวนการมาตรฐานที่เป็นสากลได้อย่างมีประสิทธิภาพ แม้ SAP จะเป็นระบบ ERP ระดับโลก แต่ในทางปฏิบัติหลายองค์กรในประเทศไทยมีรูปแบบการอนุมัติที่ซับซ้อนกว่ากระบวนการมาตรฐาน กลับพบช่องว่างทางกระบวนการ (Business Process Gap) ที่ชัดเจน ปัญหาหลักที่พบบ่อย ได้แก่ 

  • มีโครงสร้างลำดับขั้นการอนุมัติหลายชั้นและเปลี่ยนแปลงบ่อย องค์กรไทยมักมีลำดับการอนุมัติ 4 ถึง 7 ขั้น และมีการปรับโครงสร้างผู้อนุมัติทุกครั้งที่มีการโยกย้ายตำแหน่ง 
  • เงื่อนไขการอนุมัติไม่ได้อิงแค่ตำแหน่งงาน แต่ขึ้นอยู่กับวงเงิน ประเภทเอกสาร ลูกค้า โครงการ หรือแม้กระทั่งหน่วยธุรกิจที่เกี่ยวข้อง 
  • กรณียกเว้นจำนวนมาก ที่ไม่ได้ถูกออกแบบไว้ใน SAP Standard เช่น การอนุมัติแทน การข้ามขั้น หรือการอนุมัติร่วม 
  • ผู้อนุมัติมีหลายบทบาท ทำให้เส้นทางการอนุมัติซ้อนทับและสร้างความสับสน 
  • เกิดคอขวด เมื่อผู้อนุมัติไม่อยู่หรือไม่ได้เข้าระบบ เอกสารจะค้างและกระทบการดำเนินงาน 
  • การอนุมัตินอกระบบ หลายองค์กรยังต้องใช้ Email, Excel หรือ LINE ควบคู่กับ SAP เพื่อเร่งงาน ทำให้ Audit Trail ขาดความสมบูรณ์ 

SAP Approval Process
Source: Approval Process Management Guide 

ต้นเหตุของปัญหาเหล่านี้คือวัฒนธรรมการทำงานแบบไทย ที่ให้ความสำคัญกับความยืดหยุ่น การให้เกียรติลำดับขั้น และการตัดสินใจที่ปรับเปลี่ยนได้ตามสถานการณ์ ซึ่งสวนทางกับแนวทาง Fit-to-Standard ของ SAP

แนวทางแก้ไขและ Best Practice ที่ได้ผลจริง 

การ Customize ระบบอย่างไม่จำกัดไม่ใช่คำตอบ เพราะจะสร้างภาระในการดูแลและเพิ่มความเสี่ยงเมื่อต้อง Upgrade ในอนาคต แนวทางที่ที่ปรึกษาแนะนำคือ 

SAP Fit-to-Standard Approach
Source: Fit-to-Standard Approach for New S/4 HANA Implementation

1. เริ่มจาก Fit-to-Standard ก่อนเสมอ 

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

2. ออกแบบ โครงสร้างลำดับขั้นการอนุมัติ ให้เรียบง่ายที่สุด 

แยกความต้องการที่เป็น Need (จำเป็นต่อการควบคุมและ Compliance) ออกจาก Want (สิ่งที่อยากได้ตามความเคยชิน) อย่างชัดเจน 

3. ใช้ SAP Flexible Workflow ให้เต็มศักยภาพ 

ฟีเจอร์นี้รองรับเงื่อนไขที่ซับซ้อนได้มากกว่าที่หลายองค์กรเข้าใจ ควรใช้ให้เต็มที่ก่อนตัดสินใจพัฒนาเพิ่ม 

4. กำหนด Governance และเจ้าของกระบวนการ 

ต้องมี Business Process Owner ที่รับผิดชอบ Workflow แต่ละชุดอย่างชัดเจน เพื่อให้การปรับปรุงทำได้รวดเร็วและมีทิศทาง 

5. ตัดขั้นตอนที่ไม่สร้างคุณค่า 

ขั้นตอนอนุมัติที่ไม่ได้เพิ่มการควบคุมจริง (Non-Value Added Approval) ควรถูกตัดทิ้งหรือเปลี่ยนเป็นการรับทราบแทน 

6. คำนึงถึงการเติบโตในอนาคต 

ออกแบบโครงสร้างให้รองรับการขยายธุรกิจ การเพิ่มหน่วยงาน และการปรับโครงสร้างองค์กรโดยไม่ต้องรื้อระบบใหม่ 

ผลลัพธ์เชิงธุรกิจที่องค์กรจะได้รับ 

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

  • ลดระยะเวลาการอนุมัติเอกสารโดยเฉลี่ย 40 ถึง 60 เปอร์เซ็นต์
  • ลดงาน Manual และการติดตามงานผ่าน Email
  • เพิ่มความโปร่งใสและ Audit Trail ที่ตรวจสอบได้
  • ลดต้นทุนการดูแลรักษาระบบหลัง Go-Live
  • รองรับการ Upgrade SAP ในอนาคตได้ง่ายขึ้น
  • เพิ่มความคล่องตัวเมื่อต้องปรับโครงสร้างองค์กร
  • สร้างสมดุลระหว่างการควบคุม (Compliance) และประสิทธิภาพการดำเนินงาน

คำถามที่พบบ่อย (FAQ)

Q1: ถ้า SAP Standard ไม่พอ ทำไมไม่ Customize ทุกอย่างให้ตรงกับองค์กรไปเลย?

เพราะการ Customize มากเกินไปจะทำให้ต้นทุนการดูแลสูงขึ้น และเมื่อต้อง Upgrade SAP จะมีความเสี่ยงและค่าใช้จ่ายสูง การ Fit-to-Standard ในส่วนที่ทำได้ จะให้ผลตอบแทนระยะยาวที่ดีกว่า

Q2: SAP Flexible Workflow ต่างจาก Classic Workflow อย่างไร?

Flexible Workflow เป็นเครื่องมือที่ SAP S/4HANA พัฒนาขึ้นเพื่อให้ Business User ปรับเงื่อนไขการอนุมัติได้เองผ่าน Fiori App โดยไม่ต้องเขียนโค้ด ลดการพึ่งพาทีม IT ในการเปลี่ยน โครงสร้างลำดับขั้นการอนุมัติ

Q3: ใครควรเป็น Owner ของ Workflow ในองค์กร?

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

Author: Narumon S.

References:

พร้อมยกระดับระบบอนุมัติใน SAP ขององค์กรคุณแล้วหรือยัง? หากองค์กรของคุณกำลังเผชิญปัญหา Workflow ที่ซับซ้อน เอกสารค้าง หรือต้องอนุมัตินอกระบบอยู่บ่อยครั้ง ทีมที่ปรึกษาของเราพร้อมช่วยวิเคราะห์ Business Process Gap และออกแบบกระบวนการอนุมัติที่สมดุลระหว่าง SAP Best Practice กับบริบทขององค์กรไทย

ติดต่อทีมที่ปรึกษาของเรา เพียงกรอกแบบฟอร์ม

แชร์บทความ:  

Facebook
Twitter
LinkedIn
Scroll to Top