เกณฑ์การเลือกผู้วางระบบ Odoo ของคุณในฐานะองค์กรผู้ใช้

DISCLAIMER:

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

Source: Essential Criteria for Selecting Your Odoo Partner as an End-User Company

”โมดูล OCA เป็นโอเพนซอร์ส ดังนั้นจึงไม่มีใบอนุญาตใดๆ เกี่ยวข้อง” — ผมรู้สึกประหลาดใจเมื่อได้ Odoo’s Partner พูดแบบนี้กับบริษัทลูกค้า ซึ่งทำให้ผมเขียนโพสต์นี้ขึ้นมา

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

1. เกิดอะไรขึ้นเมื่อ Odoo เติบโต

1-1. การขยายตัวของ Odoo ในญี่ปุ่น

เพียงแค่ดูจาก Google Trends ก็เห็นได้ชัดว่า Odoo กำลังได้รับความนิยมในญี่ปุ่น เนื่องจากส่วนแบ่งตลาดทั่วโลกของ Odoo ยังคงเพิ่มขึ้นอย่างต่อเนื่อง ธุรกิจญี่ปุ่นจึงได้สัมผัสกับผลิตภัณฑ์ดังกล่าวบ่อยขึ้น เมื่อรวมกับความพยายามทางการตลาดแบบเจาะจงจาก Odoo S.A. ซึ่งรวมถึงโฆษณาบน YouTube จำนวนมาก (ใช่ เราได้ยินคำร้องเรียนเหล่านั้นแล้ว!) สถานการณ์ก็พร้อมแล้ว บริษัทญี่ปุ่นจำนวนมากขึ้นเรื่อยๆ กำลังพิจารณาอย่างจริงจังที่จะเลือกใช้ Odoo เป็นตัวเลือกสำหรับระบบองค์กรของตน

1-2. การเพิ่มขึ้นของโครงการที่ล้มเหลว

แต่หากพิจารณาให้ละเอียดขึ้น เราจะเห็นการเพิ่มขึ้นอย่างเห็นได้ชัดในปีที่ผ่านมาในคำถามหนึ่งที่ Quartile ได้รับคือ งานฟื้นฟูโครงการที่ล้มเหลว บริษัทเหล่านี้ได้ลองนำ Odoo ไปใช้โดยการวางระบบจาก Odoo’s Partner แล้ว แต่กลับพบกับผลลัพธ์น่าผิดหวัง และตอนนี้พวกเขากำลังตั้งคำถามว่ามีวิธีใดที่จะปรับปรุงสถานการณ์นี้ได้บ้าง Resources เราเองมีจำกัดมากในช่วงนี้ ดังนั้นเราจึงไม่สามารถรับช่วงดูแลโครงการทั้งหมดได้เสมอไป แต่เรากลับถูกดึงเข้ามาเป็นที่ปรึกษาให้กับการติดตั้งที่มีปัญหาเหล่านี้มากขึ้นเรื่อยๆ

แนวโน้มทั้งในระดับมหภาคและจุลภาคมีความเกี่ยวพันกันอย่างใกล้ชิด ในบทความก่อนหน้าของเรา โมเมนตัมของ Odoo ความกังวลของ OCA และสิ่งที่จะเกิดขึ้นต่อไป (น่าเสียดายที่ยังไม่มีให้บริการเป็นภาษาอังกฤษ) เราได้กล่าวถึงการเกิดขึ้นของ Market for lemons ซึ่งเป็นสถานการณ์ที่ข้อเสนอบริการที่ราคาถูกแต่ไม่ดีจะผลักดันผู้ให้บริการที่มีคุณภาพออกไป ทำให้บริษัทผู้ใช้ยากที่จะหาการสนับสนุนที่มีความสามารถจากผู้ให้บริการ Odoo แนวโน้มนี้ไม่ได้เป็นเพียงทฤษฎีอีกต่อไป เรากำลังเห็นตัวอย่างจริงของแนวโน้มนี้มากขึ้นเรื่อยๆ

2. Odoo เทียบกับ SAP — จุดแตกต่างพื้นฐาน

2-1. ความแตกต่างที่พบบ่อย: มุมมองผลิตภัณฑ์

คุณมักจะได้ยินการเปรียบเทียบระหว่าง Odoo กับระบบ ERP ระดับองค์กรอื่นๆ โดยเฉพาะอย่างยิ่ง SAP หากจะอธิบายให้เข้าใจง่ายขึ้น (อาจจะมากเกินไปหน่อย) SAP เป็นระบบ “subtraction” (ปิดฟีเจอร์ที่ไม่ได้ใช้) ในขณะที่ Odoo เป็นระบบ “addition” (ติดตั้งฟีเจอร์เพิ่มเมื่อต้องใช้)

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

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

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

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

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

2-2. ความแตกต่างที่ไม่ค่อยมีใครพูดถึง: บทบาทของ OCA

ความแตกต่างของ SAP และ Odoo ส่งผลต่อระบบนิเวศของมันอย่างมาก

สำหรับ SAP ที่ซอร์สโค้ดถูกปิดและการใช้งานมักจะเป็นไปตามแนวทาง “template-driven” ผู้ให้บริการจึงมีพื้นที่ในการตัดสินใจน้อยกว่าโดยเนื้อแท้ นอกเหนือจากตัวผลิตภัณฑ์เองแล้ว SAP ได้ครองตลาด ERP ของญี่ปุ่นมาเกือบ 30 ปี ซึ่งในช่วงเวลาดังกล่าว “best practices” ที่เป็นที่ยอมรับได้หยั่งรากลึกในหมู่พันธมิตรผู้ติดตั้ง ด้วยเหตุนี้ ยกเว้นในกรณีที่เกี่ยวข้องกับการพัฒนาแบบกำหนดเองขนาดใหญ่ โปรเจกต์ SAP จึงมักมีความแตกต่างเพียงเล็กน้อยในวิธีการกำหนดค่าและปรับใช้ผลิตภัณฑ์ระหว่างผู้ให้บริการที่แตกต่างกัน ความสอดคล้องนี้เป็นหนึ่งในจุดแข็งหลักของ SAP ในหลายๆ ด้าน

ในทางตรงกันข้าม Odoo เป็นโอเพนซอร์ส อย่างน้อยก็ใน Community Edition และฐานโค้ดส่วนใหญ่โฮสต์แบบเปิดบน GitHub ดังที่เราได้กล่าวไปแล้ว ลักษณะ “addition” ของ Odoo หมายความว่ามักต้องสร้างฟังก์ชันการทำงานแบบกำหนดเองเพื่อตอบสนองความต้องการเฉพาะของลูกค้า

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

นั่นคือที่มาของ Odoo Community Association (OCA) OCA ก่อตั้งขึ้นในปี 2013 เป็นองค์กรไม่แสวงหาผลกำไรที่ส่งเสริมการพัฒนาร่วมกันระหว่างผู้มีส่วนร่วมในชุมชน ปัจจุบัน OCA บริหารจัดการคลังข้อมูล GitHub กว่า 200 repositories แบ่งตามโดเมนธุรกิจและประเทศ มีโมดูลโอเพนซอร์สประมาณ 2,000 โมดูลที่ได้รับการบำรุงรักษาอย่างต่อเนื่องใน Odoo เวอร์ชันต่างๆ OCA บังคับใช้กระบวนการตรวจสอบและทบทวนรูปแบบโค้ดอย่างเข้มงวด เพื่อให้มั่นใจว่าโมดูลต่างๆ มีคุณภาพสูงและมีเสถียรภาพโดยทั่วไป นอกจากนี้ยังมีคลังข้อมูลเฉพาะสำหรับฟีเจอร์ของญี่ปุ่น ณ เดือนมิถุนายน 2568 โมดูลทั้งหมดในคลังข้อมูลดังกล่าวถูกส่งโดย Quartile แล้ว

หมายเหตุ: เทียบได้กับ Quartile, Ecosoft เองก็เป็นผู้ดูแลฟีเจอร์ของประเทศไทยผ่าน OCA ด้วยเหมือนกัน

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

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

3. ผู้เชี่ยวชาญ OSS ตัวจริงจะแบ่งปันข้อมูลกันอย่างไร

3-1. ช่องว่างในการส่งข้อความของ Odoo S.A.

โดยพื้นฐานแล้ว Odoo S.A. ดำเนินงานในสองรูปแบบการสื่อสาร: (1) กิจกรรมที่มุ่งเน้นไปที่โอเพนซอร์ส ซึ่งส่วนใหญ่อยู่บน GitHub โดยมีส่วนร่วมอย่างโปร่งใสกับชุมชนนักพัฒนา และ (2) ความพยายามทางการตลาดที่มุ่งเน้นรายได้และเข้าถึงผู้ใช้ ซึ่งจะเป็นจุดเน้นในที่นี้

ข้อความจาก Odoo S.A. ที่มุ่งเป้าไปที่ตลาดญี่ปุ่นในปัจจุบันมาจากทีมที่รับผิดชอบด้าน Sales & Marketing เนื่องจากโครงสร้างองค์กรของบริษัท ด้วยเหตุนี้ การสื่อสารเหล่านี้จึงไม่ค่อยเน้นถึงระบบนิเวศในวงกว้างหรือความพยายามของชุมชนโอเพนซอร์สอย่าง OCA เลยแม้แต่น้อย แม้ว่าผลงานของ Quartile จะเคยถูกนำเสนอเช่น “การปรับแต่งสำหรับความต้องการของญี่ปุ่นโดย Partner Quartile” โดยสมาชิกทีมที่มีเจตนาดี แต่การขยายผลความพยายามของชุมชนแบบนี้นี้ค่อนข้างหายาก เราได้พูดคุยเพิ่มเติมเกี่ยวกับข้อจำกัดด้านการสื่อสารของ Odoo S.A. ในบล็อกโพสต์อีกโพสต์หนึ่ง: “การสำรวจวิธีเพิ่มการมีส่วนร่วมในโครงการ OSS ของ Odoo”

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

บางคนอาจกล่าวว่า “นั่นเป็นความรับผิดชอบของผู้ให้บริการภายในระบบนิเวศ” ซึ่งบางทีนั่นอาจเป็นความจริง ด้วยเหตุผลนี้ Quartile จึงเชื่อว่าบทบาทส่วนหนึ่งของเราในฐานะพันธมิตรของ Odoo คือการแบ่งปันมุมมองที่กว้างขึ้นนี้ เพื่อช่วยรักษาสมดุลในตลาด

3-2. โมเดลการสื่อสารที่สมดุล

บริษัทหลายแห่งที่โปรโมต Odoo ในญี่ปุ่นมักจะเน้นย้ำถึงข้อดี เช่น “Odoo ตอบโจทย์ความต้องการด้าน Japanese Localization แล้ว!” เป็นต้น แต่ในมุมมองของเรา คำถามที่ตามมามักจะเป็น “จริงเหรอ? ภายใต้เงื่อนไขอะไร?”

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

สิ่งที่เราต้องการจริงๆ คือการสื่อสารที่ตรงไปตรงมามากขึ้น ตัวอย่างเช่น “ฟีเจอร์มาตรฐานของ Odoo ไม่รองรับเงื่อนไขการชำระเงินกลางเดือนแบบทั่วไปของญี่ปุ่น อย่างไรก็ตาม โมดูลโอเพนซอร์ส account_payment_term_cutoff_day จาก OCA รองรับ ได้รับอนุญาตภายใต้ AGPL และสร้างขึ้นโดย [บริษัท X] ณ ขณะนี้ การรองรับเวอร์ชัน 18.0 ยังคงอยู่ระหว่างรอการอนุมัติ แต่งานกำลังดำเนินการอยู่”

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

4. ปัญหาคุณภาพและความเสี่ยงสำหรับบริษัทผู้ใช้

4-1. ความกังวลด้านคุณภาพที่เพิ่มขึ้นในหมู่ผู้ให้บริการ Odoo

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

คุณอาจคิดว่า “แต่พันธมิตร Odoo ได้รับการรับรองและจัดอันดับแล้ว นั่นหมายความว่ายังไงล่ะ?” น่าเสียดายที่มีผลไม่มากนัก ระบบการจัดอันดับเน้นการขายสิทธิ์การใช้งานระดับองค์กร เช่นเดียวกับข้อความทั่วไป โปรแกรมพันธมิตรของ Odoo S.A. แทบไม่ได้พูดถึงความสามารถของโอเพนซอร์สเลย แม้ว่าพันธมิตรจะเสนอการปรับปรุงครั้งใหญ่ให้กับ Odoo เองที่ได้รับการยอมรับจากต้นทาง แต่ก็ไม่ได้นำมาพิจารณาในคะแนนของพวกเขา นี่ไม่ใช่ปัญหาใหม่ เราได้กล่าวถึงเรื่องนี้ไปแล้วในปี 2018 ตอนที่เราเผยแพร่บทความ “Quartile Becomes an Odoo Learning Partner”

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

สถานการณ์เช่นนี้ก็ไม่ดีสำหรับเราเช่นกัน การเสียเวลาไปกับการแก้ปัญหาที่น่าจะป้องกันได้ หมายความว่าเราไม่มีเวลาที่จะสร้างการปรับปรุงใหม่ๆ ให้กับชุมชน

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

4-2. ความเสี่ยงขององค์กรของผู้ใช้ที่ไม่เข้าใจชุมชนโอเพนซอร์ส

จากสถานการณ์ปัจจุบัน ดูเหมือนว่าบริษัทผู้ใช้ในญี่ปุ่นแทบจะไม่ได้รับคำอธิบายโดยละเอียดเกี่ยวกับ OCA จาก Odoo S.A. หรือพันธมิตรอื่นๆ นอกจาก Quartile การขาดการเปิดเผยข้อมูลนี้ก่อให้เกิดความเสี่ยงอย่างมากสำหรับบริษัทผู้ใช้

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

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

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

วิธีการเหล่านี้ก่อให้เกิดความเสียหายอย่างใหญ่หลวง จากประสบการณ์ของเรา การกู้คืนโครงการเช่นนี้มักหมายถึงการเริ่มต้นใหม่เกือบทั้งหมด เช่นเดียวกับที่เราทำในกรณีศึกษา “การอัปเกรดเวอร์ชัน Odoo: MI7 ญี่ปุ่น (V10 → V15)“

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

ดังที่ได้กล่าวไปแล้ว ในการใช้งาน Odoo แบบ “freestyle” นั้น บริษัทผู้ใช้มักตกเป็นเหยื่อของผู้ให้บริการคุณภาพต่ำได้ง่าย โดยเฉพาะอย่างยิ่งหากไม่ได้ใส่ใจอย่างจริงจัง โปรแกรมพันธมิตรปัจจุบันของ Odoo S.A. ซึ่งประเมินผู้ให้บริการโดยพิจารณาจากยอดขายเป็นหลัก ไม่ได้ช่วยป้องกันความเสี่ยงนี้เลย อันที่จริง ลูกค้าส่วนใหญ่ที่ Quartile เข้ามาดูแลนั้นมาจากพันธมิตร Odoo อย่างเป็นทางการ รวมถึงบางรายที่มีสถานะ “Gold” หรือ “Silver”

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

5. กิจกรรมชุมชนของพาร์ทเนอร์บอกอะไรคุณบ้าง

5-1. การมีส่วนร่วมของชุมชนเผยให้เห็นจุดยืนและทักษะที่แท้จริงของพาร์ทเนอร์

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

• บั๊กและฟีเจอร์ที่ไม่สมบูรณ์เป็นเรื่องปกติ
• การแปลภาษาญี่ปุ่นยังพัฒนาไม่เต็มที่
• ช่องทางการรับฟังความคิดเห็นผ่าน Helpdesk มีจำกัด

ประเด็นแรกเป็นการแลกเปลี่ยนกับการพัฒนาที่รวดเร็วของ Odoo เป็นอย่างมาก สิ่งต่างๆ ได้รับการปรับปรุงไปมากในช่วงหลายปีที่ผ่านมา แม้ว่าบางครั้งเราก็ยังพบปัญหาที่ทำให้เราอยากจะเอาหัวโขกกำแพง (เมื่อปีที่แล้วตอนที่ผมได้คุยกับ Antony CTO ของ Odoo เขาหัวเราะและบอกว่าบั๊กเป็นส่วนหนึ่งของระบบ Odoo ดังนั้นผมคิดว่าเราคงต้องยอมรับเรื่องนี้แล้วล่ะ)

ประเด็นที่สอง การแปลภาษาญี่ปุ่นยังคงอ่อนแอ จนกระทั่งเมื่อ 3-4 ปีที่แล้ว งานแปลภาษาเกือบทั้งหมดสำหรับญี่ปุ่น (การแปล โมดูลบัญชี ฯลฯ) ล้วนมาจาก Quartile Odoo S.A. เพิ่งเริ่มทุ่มเททรัพยากรภายในให้กับเรื่องนี้เมื่อไม่นานมานี้ และถึงอย่างนั้น ความคืบหน้าก็ยังเป็นเพียงบางส่วนเท่านั้น

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

แล้วจะเกิดอะไรขึ้น? ในญี่ปุ่น การนำ Odoo มาใช้ส่วนใหญ่มักต้องการการแก้ไขหรือปรับปรุง แต่ Odoo S.A. กลับไม่พร้อมที่จะช่วยเหลือ

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

หากไม่เป็นเช่นนั้น ทางเลือกที่เหลืออยู่มีดังต่อไปนี้

• เลิกคิดที่จะรับมือกับกรณีเฉพาะหน้าหรือข้อกำหนดเฉพาะที่ถูกมองข้าม
• สร้างโซลูชันแบบส่วนตัวและปิดประตู

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

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

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

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

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

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

5-2. ทำไมบริษัทระดับโลกจึงควรเลือกผู้ให้บริการที่มีส่วนร่วมกับชุมชน

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

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

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

เราประสบความสำเร็จในการดำเนินโครงการร่วมกับ Ecosoft (ประเทศไทย) และ Komit (เวียดนาม) ซึ่งเป็นผู้สนับสนุน OCA รายใหญ่จากเอเชีย แม้ว่าแต่ละบริษัทจะมีแนวปฏิบัติภายในของตนเอง แต่รากฐานร่วมกันของเราทำให้การทำงานร่วมกันเป็นไปอย่างราบรื่น เราได้นำทักษะที่แตกต่างกันมาใช้และบรรลุการทำงานร่วมกันอย่างแท้จริง อันที่จริง เราได้ทำงานร่วมกับพันธมิตรเหล่านี้อย่างหลวมๆ ผ่านการทำงานประจำวันของเราใน OCA ดังนั้นความร่วมมืออย่างเป็นทางการจึงเป็นการขยายขอบเขตความร่วมมือนั้นโดยธรรมชาติ

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

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

5-3. เหตุใดจึงมีผู้ให้บริการเข้าร่วมชุมชนน้อย

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

เราสังเกตเห็นว่าบริษัทผู้ใช้ที่มีความเชี่ยวชาญเพิ่มขึ้นเรื่อยๆ ที่เลือกพันธมิตรโดยเฉพาะอย่างยิ่งเพราะการมีส่วนร่วมในชุมชนของพวกเขา แม้ว่าเอกสารของ Odoo S.A. จะไม่ได้กล่าวถึงระบบนิเวศโอเพนซอร์สมากนัก แต่ผู้ใช้ก็กำลังค้นพบ OCA ด้วยตนเอง บางคนติดต่อเรามาหลังจากทราบประวัติชุมชนของเรา บางครั้งได้รับความช่วยเหลือจากเครื่องมือ AI ที่เปิดเผยผลงานของเราได้อย่างมีประสิทธิภาพมากกว่าไดเรกทอรีอย่างเป็นทางการใดๆ

แต่ประเด็นสำคัญคือ แม้จะมีข้อดีมากมายเหล่านี้ แต่มีผู้ให้บริการ Odoo เพียงไม่กี่รายเท่านั้นที่เข้าร่วมในชุมชน ณ เดือนมิถุนายน 2568 มีพันธมิตร Odoo อย่างเป็นทางการทั่วโลกมากกว่า 3,300 ราย ในปี 2567 มีเพียง 448 รายเท่านั้นที่มีส่วนร่วมกับ OCA และจำนวนที่มีกิจกรรมอย่างต่อเนื่องนั้นน้อยกว่ามาก ในญี่ปุ่น ปัจจุบันมีเพียง Quartile เท่านั้น (หรือกรณีของประเทศไทย ก็มีเพียง Ecosoft เท่านั้น)

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

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

• ความเข้าใจเชิงลึกเกี่ยวกับระบบนิเวศ Odoo
• ความเชี่ยวชาญทางเทคนิคในผลิตภัณฑ์
• ทักษะการสื่อสารในภาษาที่ชุมชนใช้ทำงาน (ภาษาอังกฤษ)
• การปฏิบัติตามมาตรฐานคุณภาพและขั้นตอน

Pull Request ที่ส่งไปยังคลังข้อมูลหลักของ Odoo หรือ OCA ที่ตรงตามความสามารถเหล่านี้จะถูกรวมเข้าด้วยกันหลังจากได้รับการอนุมัติจากสมาชิกที่มีประสบการณ์ ซึ่งโดยปกติแล้วจะมีมากกว่าหนึ่งราย

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

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

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

5-4. ข้อกำหนดสัญญาสำหรับการใช้ประโยชน์จากโอเพนซอร์ส

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

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

สิ่งนี้ยังส่งผลกระทบมากกว่าแค่การพัฒนาใหม่ๆ หากคุณกำลังปรับปรุงฟีเจอร์หลักของ Odoo ที่มีอยู่หรือปรับปรุงโมดูล OCA คุณอาจพบอุปสรรค คลังข้อมูล Odoo และ OCA กำหนดให้ต้องลงนามในข้อตกลงสิทธิ์การใช้งานสำหรับผู้ร่วมพัฒนา (Client Authorized License Agreement: CLA) ก่อนที่จะยอมรับผลงานใดๆ แต่คุณไม่สามารถคาดหวังให้บริษัทผู้ใช้ปลายทางดำเนินการตามกระบวนการ CLA ได้ เพราะมันไม่สามารถปฏิบัติได้จริง

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

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

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

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

5-5. วิธีตรวจสอบประวัติผลงานชุมชนของผู้ให้บริการ

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

และนี่คือจุดที่คุณสามารถดูเพื่อประเมินกิจกรรมของชุมชนได้:

• คลังข้อมูล GitHub ของ Odoo (Pull Requests, Issues)
• คลังข้อมูล GitHub ของ OCA (จัดเรียงตามหมวดหมู่โมดูล)
• OCA Apps Store/Odoo Apps Store (สำหรับแอปโอเพนซอร์สเท่านั้น)
• Transifex (สำหรับการแปลหลักของ Odoo) / Weblate (สำหรับการแปลโมดูลของ OCA)
• รายชื่ออีเมลของ OCA
• ฟอรัม Odoo
• แพลตฟอร์มบางอย่าง เช่น เครื่องมือแปลภาษา อาจต้องเข้าสู่ระบบและอาจไม่ง่ายนักที่จะเรียกดู แต่แพลตฟอร์มส่วนใหญ่ที่กล่าวมาข้างต้นเปิดให้ทุกคนใช้งานได้ฟรี

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

เคล็ดลับสั้นๆ: OCA เผยแพร่บล็อกโพสต์ประจำปีบนเว็บไซต์ของตน ซึ่งนำเสนอการจัดอันดับ Top Contributor Ranking สเปรดชีตที่แนบมากับบทความดังกล่าวจะแสดงภาพรวมเชิงปริมาณของการมีส่วนร่วม โดยจะติดตามจำนวนคำขอ Pull Request ที่รวมเข้าด้วยกัน รวมถึงจำนวนรีวิวที่เกี่ยวข้อง ซึ่งรวบรวมทั้งตามองค์กรและตามบุคคล

ดังที่ได้กล่าวไปแล้ว การส่งการปรับปรุงหรือแก้ไขไปยัง Odoo Core หรือที่เก็บข้อมูล OCA จำเป็นต้องมี CLA สำหรับ Odoo Core คุณสามารถตรวจสอบว่าองค์กรได้ลงนามใน CLA หรือไม่ โดยตรวจสอบไดเรกทอรี CLA ในที่เก็บข้อมูล GitHub ของ Odoo หากผู้ให้บริการไม่ปรากฏ แสดงว่าพวกเขาไม่ได้ลงนามใน CLA และไม่สามารถส่งการปรับปรุงหรือแก้ไขไปยัง Odoo Core ได้ กล่าวอีกนัยหนึ่ง หากผู้ให้บริการไม่ปรากฏอยู่ในรายชื่อ แสดงว่าผู้ให้บริการไม่มีประวัติการมีส่วนร่วมในการพัฒนา Odoo (คุณสามารถดู CLA ของ Quartile ได้ที่นี่)

5-6. รูปแบบการสื่อสารของผู้ให้บริการที่ไม่ได้มีส่วนร่วมในชุมชนโอเพ่นซอร์ส

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

1. การส่งเสริมจุดแข็งของ Odoo ในฐานะผลิตภัณฑ์

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

2. การเน้นย้ำถึงขนาดบริษัทและข้อได้เปรียบด้านบริการ

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

3. การเน้นย้ำสถานะพันธมิตรกับ Odoo S.A.

ซึ่งรวมถึงข้อความ เช่น “เราได้รับการรับรองให้เป็นพันธมิตร Odoo” “พันธมิตรระดับ Gold เพียงรายเดียวใน [ภูมิภาค]” หรือ “พันธมิตรยอดเยี่ยมแห่งปี 20xx” เมื่อมองแวบแรก ข้อความเหล่านี้อาจดูเหมือนเป็นจุดขายที่แท้จริง อย่างไรก็ตาม หากการประเมินพันธมิตรของ Odoo S.A. อ้างอิงจากยอดขายใบอนุญาตองค์กรเป็นหลัก และไม่ได้สะท้อนถึงคุณภาพบริการที่แท้จริง การยกย่องเชิดชูเกียรติดังกล่าวก็ไม่น่าจะเป็นปัญหาสำคัญสำหรับบริษัทผู้ใช้ อย่างไรก็ตาม การ “รับรอง” ในรูปแบบเหล่านี้มักสะท้อนถึงบริษัทที่ไม่คุ้นเคยกับบริบทในวงกว้าง ด้วยเหตุนี้ พันธมิตรของ Odoo ที่ขาดความแตกต่างที่ชัดเจนจึงมักให้ความสำคัญกับการรับรองและรางวัลที่ Odoo S.A. มอบให้อย่างไม่สมส่วน

6. ความหมายของการที่ผู้ให้บริการเก็บทุกอย่างไว้ภายในองค์กร

6-1. การมีทีมพัฒนาภายในองค์กรเป็นจุดแข็งจริงหรือ?

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

ที่ Quartile เรามีสมาชิกจากต่างประเทศที่ส่วนใหญ่มีส่วนร่วมในกิจกรรมการพัฒนา แต่เราไม่มี “ทีมพัฒนา” เฉพาะ

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

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

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

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

6-2. ข้อผิดพลาดของโมดูลภายในองค์กร

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

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

ด้วยเหตุนี้ จึงควรใช้ประโยชน์จากฟีเจอร์โอเพนซอร์สที่กลายเป็นส่วนหนึ่งของสินทรัพย์ร่วมของชุมชนภายใต้ OCA เมื่อปรับแต่ง Odoo

7. 18 เกณฑ์สำคัญสำหรับการประเมินพันธมิตรการติดตั้ง Odoo

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

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

Ⅰ. Community Contribution & OSS Competency

Measures how deeply a Odoo service provider can engage with Odoo as an open-source product.

1. Contribution to Odoo Core:

Has the provider signed the Contributor License Agreement (CLA) and made improvements to the official Odoo repositories?

2. Contributions to the OCA:

Has the provider had pull requests successfully merged into OCA GitHub repositories?

3. Knowledge of OCA Modules:

Can the provider suggest a wide range of relevant OCA modules to match feature requirements?

4. Localization Expertise for Japan:

Has the provider developed or reviewed modules for Japanese-specific needs (e.g., language, accounting, taxation)?

5. Bug Reporting & Feedback Loop:

Does the provider log bugs in Odoo/OCA GitHub repositories and keep clients informed?

6. License Compliance:

Does the provider understand and explain AGPL/LGPL license terms when using OCA modules?

7. Open Information Sharing: Does the provider proactively introduce both its own and OCA’s solutions (especially those commonly used in Japan)?

8. Copyright Ownership: Does the provider retain copyright of deliverables on the provider side to ensure continued contribution and reuse?

Ⅱ. Technical Capability & Quality Assurance

Assesses the provider’s ability to deliver reliable, long-term service at a sustainable cost.

9. Community-Driven Development Process:

Are coding standards, automated testing, and code review applied consistently by the provider?

10. Track Record of Rescue Projects:

Has the provider successfully restructured failed implementations or performed major version upgrades?

11. Multinational/Multi-site Experience:

Has the provider rolled out Odoo across multiple international sites in collaboration with other partners?

12. Technical Communication in English:

Can the provider conduct design discussions and code reviews with other community contributors or partners?

13. Customization Policy for Maintainability:

Does the provider prioritize OCA/standard modules over unnecessary customizations?

14. Quality Assurance & Long-Term Support:

Can the provider demonstrate test coverage, CI/CD practices, and upgrade roadmaps?

15. Customer Churn:

Have clients ever left the provider’s services? If so, why?

Ⅲ. Contract & Operational Transparency

Assesses whether the provider reduces user risk and supports healthy long-term relationships.

16. Clarity on Copyright and Licensing:

Do the provider’s contracts allow users to freely use, modify, and distribute deliverables?

17. Billing Transparency:

Is it clear what clients are being charged for, and are billing logs (e.g., timesheets) shared in a timely manner?

18. Provider Lock-in Avoidance:

Can clients leave the provider’s service easily, without significant switching costs?

8. สู่ระบบนิเวศ Odoo ที่ดีขึ้น

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

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

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

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

ในระดับบุคคล การมีส่วนร่วมในกิจกรรมชุมชนโอเพนซอร์สมีข้อดีหลายประการ ดังนี้

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

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

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