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

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

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

สองคำที่มักถูกใช้ปนกัน

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

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

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

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

ผู้ขายระบุอะไรไว้จริง

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

SAP เผยแพร่แนวคิดที่เรียกว่า clean core ในหลักสูตรของ SAP Learning เรื่องนี้ระบุว่า SAP รับประกันความเสถียรของอินเทอร์เฟซที่ประกาศว่า released จากรุ่นหนึ่งไปอีกรุ่นหนึ่ง และลูกค้าที่ใช้แนวทางนี้ตกลงจะใช้เฉพาะอินเทอร์เฟซที่ released ในงานพัฒนาและส่วนขยายใหม่ เครื่องมือพัฒนาจะแจ้งข้อผิดพลาดเมื่อมีการเรียกวัตถุที่ไม่ได้ประกาศ ตัวอย่างที่หน้าเอกสารยกไว้คือการอ่านตารางข้อมูลประเทศโดยตรง ซึ่งเครื่องมือจะบอกให้ใช้ CDS entity ที่ SAP ออกให้แทน (ดูหน้า Exploring Released APIs ของ SAP Learning)

อีกหน้าหนึ่งของหลักสูตรเดียวกันอธิบายระดับของส่วนขยายสี่ระดับ ระดับ A ใช้ released API และเป็นระดับที่ SAP ระบุว่าให้ความเสถียรในการอัปเกรดสูงสุด ระดับ B ใช้ API และเทคโนโลยีแบบคลาสสิก ระดับ C เข้าถึงวัตถุภายใน (internal objects) ซึ่งหน้าเอกสารระบุว่ามีความเสี่ยงที่จัดการได้ และระดับ D ใช้วัตถุที่ไม่แนะนำ รวมถึงการแก้ไขและการเขียนลงตารางของ SAP โดยตรง ซึ่งเอกสารระบุว่าเป็นความเสี่ยงสูงสุดและเป็นหนี้ทางเทคนิค หน้าเดียวกันกล่าวว่าวัตถุภายในอาจเปลี่ยนโดยไม่แจ้งล่วงหน้าและไม่มีการรับประกันความเข้ากันได้ และแนะนำให้ปรับแต่งด้วยระดับสูงสุดเท่าที่ทำได้ (ดูหน้า Extensibility Model Best Practices)

Odoo เป็นผลิตภัณฑ์คนละแบบ เอกสารสำหรับนักพัฒนาของ Odoo สอนให้ขยาย model และ view ของโมดูลเดิมด้วยกลไก inheritance แทนการเขียนทับ view เดิมตรง ๆ และให้เรียก super() เมื่อ override เมธอดเพื่อไม่ให้ลำดับการทำงานเดิมขาด (ดูบทสอนเรื่อง inheritance ของ Odoo) เอกสารหน้านี้ไม่ได้พูดเรื่องต้นทุนการอัปเกรดโดยตรง เราหยิบมาเพียงเพื่อแสดงว่าอีกผู้ขายหนึ่งก็วางช่องทางขยายไว้แยกจากการแก้โค้ดแกนเช่นกัน

ข้อจำกัดที่ต้องบอกให้ชัด เรายังเปิดเอกสาร white paper เรื่อง clean core extensibility ของ SAP ฉบับเต็มปี 2024 ไม่ได้ เพราะเซิร์ฟเวอร์ตอบกลับว่าไม่อนุญาต และบทความของ ASUG ที่สรุปแนวทางล่าสุดเปิดได้เฉพาะสมาชิก สิ่งที่เราเล่าข้างต้นมาจากหน้าหลักสูตรของ SAP Learning เท่านั้น และเราไม่ได้ตรวจว่านิยามระดับในเอกสารฉบับเต็มตรงกับหลักสูตรทุกคำหรือไม่ นอกจากนี้ เราไม่มีตัวเลขว่าส่วนต่างของค่าอัปเกรดระหว่างระบบที่ปรับแต่งน้อยกับมากเป็นเท่าไร และจะไม่ให้ตัวเลขนั้นในบทความนี้

อะไรทำให้อัปเกรดแพง

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

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

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

• การเรียกสิ่งที่ผู้ขายไม่ได้ประกาศ เอกสารของ SAP ที่อ้างข้างต้นเรียกกลุ่มนี้ว่า internal objects และระบุว่าอาจเปลี่ยนโดยไม่แจ้ง

• รายงานและอินเทอร์เฟซที่ไม่มีเอกสาร งานที่คนเดิมเขียนไว้และไม่มีใครรู้ว่าฝ่ายไหนใช้ จะถูกพบเมื่อมันพังหลังอัปเกรด ไม่ใช่ก่อน

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

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

ตรวจคำขอปรับแต่งทีละข้อ

เราแนะนำให้ทุกคำขอที่ไม่ใช่การตั้งค่าผ่านผู้ขายต้องตอบคำถามต่อไปนี้เป็นลายลักษณ์อักษรก่อนอนุมัติ

1. ความต้องการนี้ทำได้ด้วยการตั้งค่าหรือไม่ ให้ผู้พัฒนาแสดงว่าตรวจแล้วว่าตัวเลือกมาตรฐานทำไม่ได้ ไม่ใช่เพียงบอกว่าไม่คุ้นกับตัวเลือกนั้น

2. ถ้าทำเป็นส่วนขยาย ใช้ช่องทางที่ผู้ขายประกาศหรือไม่ ขอให้ระบุชื่อ API หรือจุดต่อที่ใช้ และลิงก์ไปยังเอกสารของผู้ขาย

3. มีการเขียนลงตารางหรือเรียกวัตถุภายในหรือไม่ ถ้ามี ให้บันทึกเป็นข้อยกเว้นพร้อมเหตุผลและชื่อผู้อนุมัติ

4. ธุรกิจเสียอะไรถ้าไม่ทำ คำตอบที่เป็นความเจ็บปวดจริงของกระบวนการ ควรหนักกว่าคำตอบว่าผู้ใช้คุ้นกับระบบเก่าแบบนั้น

5. ใครดูแลมันหลังส่งมอบ ถ้าเป็นผู้พัฒนาคนเดียว ให้ถามต่อว่าถ้าเขาไม่อยู่แล้ว ใครอ่านโค้ดนี้ได้

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

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

เขียนลงใน TOR อย่างไร

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

• ส่วนขยายทั้งหมดต้องใช้ช่องทางที่ผู้ขายผลิตภัณฑ์ประกาศไว้ในเอกสาร การเขียนลงตารางโดยตรง การแก้โค้ดแกน และการเรียกวัตถุที่ผู้ขายไม่ได้ประกาศ ต้องได้รับอนุมัติเป็นรายกรณีเป็นลายลักษณ์อักษร

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

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

• ตกลงล่วงหน้าว่าใครรับค่าใช้จ่ายของรอบทดสอบนั้น และงานแก้ที่เกิดจากการปรับแต่งที่อยู่นอกช่องทางที่ประกาศ ว่าอยู่ในสัญญาดูแลระบบหรือเป็นงานแยก

• ชุดทดสอบของส่วนที่ปรับแต่งต้องเป็นส่วนหนึ่งของงานส่งมอบ เพื่อให้ผู้ที่มารับช่วงต่อรันซ้ำได้

รายละเอียดว่าข้อกำหนดแบบไหนทำให้ระบบดูแลต่อได้ เราเขียนไว้ในบทความเรื่องเงื่อนไขใน TOR ส่วนการแบ่งงานรอบอัปเกรดเข้ากับสัญญาบำรุงรักษารายปีอยู่ในบทความเรื่องสัญญาดูแลระบบรายปี

เรื่องที่ไม่ควรทำ

ในมุมของเรา มีสามเรื่องที่ควรเลี่ยง

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

1. ขอรายการสิ่งที่ปรับแต่งทั้งหมดในระบบที่ใช้อยู่ ถ้าไม่มีรายการ ให้ผู้พัฒนาจัดทำฉบับแรก แม้ไม่ครบก็ดีกว่าไม่มี

2. จัดกลุ่มแต่ละรายการ เป็นการตั้งค่า ส่วนขยายผ่านช่องทางที่ประกาศ หรือการแก้ภายใน และดูว่ากลุ่มสุดท้ายมีกี่รายการและใครใช้

3. ถามผู้ขายว่าเวอร์ชันที่ใช้อยู่ได้รับการสนับสนุนถึงเมื่อไร และบันทึกคำตอบพร้อมวันที่

4. เลือกรายการที่เสี่ยงที่สุดหนึ่งถึงสองรายการ แล้วให้ผู้พัฒนาเขียนชุดทดสอบที่รันซ้ำได้ก่อน ยังไม่ต้องแก้โค้ด

5. เพิ่มแบบฟอร์มหกคำถามข้างต้นเข้ากระบวนการอนุมัติคำขอ และปรับ TOR หรือสัญญาดูแลระบบในรอบต่ออายุถัดไป

สรุป

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส