ERP ใหม่ วิธีทำงานเดิม: องค์กรกำลังเปลี่ยนผ่าน หรือแค่จ่ายแพงขึ้น?

“เราต้องการใช้ ERP เพื่อยกระดับการทำงาน สร้างมาตรฐาน และเชื่อมโยงข้อมูลทั้งองค์กร”

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

ฝ่ายขายขอใช้ขั้นตอนอนุมัติแบบเดิม ฝ่ายบัญชีต้องการรายงานหน้าตาเดิม ฝ่ายปฏิบัติการยืนยันว่าปรับวิธีทำงานไม่ได้ และบางคนถามว่า “ฟังก์ชันนี้ใช้มา 15 ปีแล้ว ทำไมระบบใหม่ถึงไม่มี?”

 

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

 

คำถามคือ เรากำลังเปลี่ยนธุรกิจ หรือกำลังย้ายความเคยชินไปอยู่บนซอฟต์แวร์ใหม่?

 

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

สิ่งที่ต้องระวังคือการใช้ความคุ้นเคยเป็นเหตุผลหลักในการออกแบบระบบ

“เราเคยทำแบบนี้” อธิบายอดีตได้ แต่ยังตอบไม่ได้ว่าทำไมองค์กรควรทำแบบนี้ต่อไป

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

เมื่อระบบใหม่เชื่อมโยงข้อมูลและควบคุมกระบวนการได้ดีขึ้น องค์กรควรถามว่าขั้นตอนเหล่านั้นยังสร้างคุณค่าอยู่หรือไม่

 

ปัญหาคือการตั้งคำถามเช่นนี้มักยากกว่าการเขียนโปรแกรมเพิ่ม

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

ต้นทุนที่แท้จริงเริ่มชัดหลังวัน Go-live

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

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

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

 

มาตรฐานจะเกิดขึ้นได้ เมื่อผู้บริหารยอมเปลี่ยนด้วย

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

หากผู้นำแต่ละฝ่ายปกป้องวิธีทำงานเดิมทั้งหมด ทีม IT ย่อมสร้างมาตรฐานระดับองค์กรได้ยาก เพราะทุกความต้องการจะถูกอธิบายว่าเป็น “ความจำเป็นของธุรกิจ”

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

 

ก่อนอนุมัติ Customisation ผู้บริหารควรถามร่วมกันอย่างน้อยห้าข้อ

  1. เรากำลังแก้ปัญหาอะไร? ระบุผลกระทบทางธุรกิจให้ชัด ก่อนตัดสินใจว่าต้องเพิ่มฟังก์ชันใด
  2. ได้ทดลองกระบวนการมาตรฐานแล้วหรือยัง? ให้ผู้ใช้งานเห็นการทำงานจริง และประเมินว่าการปรับกระบวนการตอบโจทย์ได้เพียงใด
  3. คุณค่าที่ได้รับคุ้มกับต้นทุนตลอดอายุระบบหรือไม่? รวมค่าทดสอบ ดูแล อัปเกรด และผลกระทบต่อส่วนอื่นด้วย
  4. ใครเป็นเจ้าของผลลัพธ์? ทุกการปรับแต่งสำคัญควรมีเจ้าของธุรกิจที่รับผิดชอบประโยชน์ตามที่เสนอไว้
  5. จะทบทวนข้อยกเว้นเมื่อใด? ความจำเป็นวันนี้อาจหมดไป เมื่อธุรกิจเปลี่ยนหรือระบบมาตรฐานพัฒนาขึ้น

 

แล้วใครควรมีสิทธิ์ตัดสินใจสุดท้าย เจ้าของกระบวนการหรือ CIO?

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

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

ERP ที่ดีควรรองรับสิ่งที่ทำให้ธุรกิจแตกต่างอย่างมีคุณค่า พร้อมเปิดโอกาสให้องค์กรเลิกทำสิ่งที่หมดความจำเป็นไปแล้ว

ความสำเร็จจึงควรวัดต่อจากวัน Go-live ว่างานเร็วขึ้นหรือไม่ ข้อมูลเชื่อถือได้ขึ้นเพียงใด และขั้นตอนที่ไม่สร้างคุณค่าลดลงจริงหรือยัง

 

หากทุกกระบวนการเดิมยังอยู่ครบหลังติดตั้ง ERP องค์กรได้เปลี่ยนอะไรไปบ้าง นอกจากระบบและใบแจ้งหนี้?

FAQ: ERP ใหม่ วิธีทำงานเดิม—องค์กรควรจัดการอย่างไร?

1. ทำไมติดตั้ง ERP ใหม่แล้ว วิธีทำงานขององค์กรยังเหมือนเดิม?

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

 

2. การ Customise ERP เป็นเรื่องที่ควรหลีกเลี่ยงเสมอหรือไม่?

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

 

3. จะแยก “ความจำเป็นทางธุรกิจ” ออกจาก “ความเคยชิน” ได้อย่างไร?

ลองถามว่า หากไม่ปรับแต่ง องค์กรจะเสียหายอย่างไร และมีหลักฐานใดรองรับ จากนั้นทดลองใช้กระบวนการมาตรฐานเพื่อประเมินทางเลือก หากเหตุผลมีเพียง “เคยทำแบบนี้มาตลอด” ควรทบทวนกระบวนการก่อนอนุมัติให้พัฒนาเพิ่มเติม

 

4. ก่อนอนุมัติ Customisation ควรประเมินอะไรบ้าง?

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

 

5. ต้นทุนแฝงของการ Customise ERP มีอะไรบ้าง?

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

 

6. ใครควรมีอำนาจอนุมัติหรือปฏิเสธการ Customise ERP?

เจ้าของกระบวนการควรรับผิดชอบเหตุผลและผลลัพธ์ทางธุรกิจ ส่วน CIO ควรประเมินผลต่อมาตรฐาน สถาปัตยกรรม และความเสี่ยงของระบบ โดยใช้อำนาจตามกติกาที่องค์กรกำหนดไว้ หากมีข้อขัดแย้งสำคัญ ควรให้คณะกำกับโครงการตัดสินจากประโยชน์รวมขององค์กร

 

7. จะลดแรงต้านจากผู้ใช้งานที่ต้องการวิธีทำงานเดิมได้อย่างไร?

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

 

8. จะวัดได้อย่างไรว่า ERP ทำให้องค์กรเปลี่ยนแปลงจริง?

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

 

 

สอบถามรายละเอียด SAP Business One ได้ที่

บริษัท ซันเด โซลูชันส์ จำกัด

โทร 026348899 อีเมล sales@sundae.co.th

เว็บไซต์ https://www.sundae.co.th/solution/erp/sap-business-one/

 

 

ติดตามเราได้ที่:

Line OA: @sundae.co.th

Facebook: https://www.facebook.com/sundaesolutions

LinkedIn: https://www.linkedin.com/company/sundaeth
IG https://www.instagram.com/sundaesolutions/
X https://www.x.com/@SundaeSolutions