Intermediary Business Model

เหตุใด ERP ขนาดใหญ่จึงไม่ตอบโจทย์นวัตกรรมโมเดลธุรกิจใหม่ๆ

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

และเมื่อไม่นานมานี้ บริษัทแห่งหนึ่งซึ่งเคยใช้โปรแกรมของเรา ได้เปลี่ยนไปใช้ ERP ระดับโลก หลังจากการ Go-live ของระบบใหม่ หัวหน้าทีมวางระบบของเราได้รับเชิญกลับไปเป็นที่ปรึกษา และได้ค้นพบประเด็นที่น่าแปลกใจ

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

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

วิวัฒนาการของ "ตัวกลาง" ในห่วงโซ่ธุรกิจ

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

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

อย่างไรก็ตาม "แพลตฟอร์มโมเดล" ได้สร้างนิยามใหม่ให้กับบทบาทของตัวกลาง ดร. สันติธาร เสถียรไทย ได้อธิบายไว้ในหนังสือ The Great Remake ว่า

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

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

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

เมื่อ ERP กลายเป็นอุปสรรค

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

โมเดล "สั่งด่วน"

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

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

การที่โมเดลนี้ได้มีโอกาส POC (Proof of Concept) มาก่อนการขึ้นโปรแกรมใหม่ ทำให้มีรายละเอียดชัดเจนเพียงพอที่จะกำหนดสเปคความต้องการเพื่อพัฒนาต่อได้

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

ธุรกิจจัดหาวัสดุอุปกรณ์สำหรับโรงงานอุตสาหกรรม

อีกตัวอย่างหนึ่งคือธุรกิจที่จัดหาวัสดุอุปกรณ์ให้กับช่างหรือแผนกซ่อมบำรุงในโรงงานอุตสาหกรรม 

จุดแข็งของทีมขายที่นี่คือความสัมพันธ์อันยาวนานกับลูกค้า และการที่ไม่เคยบอกว่า "ไม่มี"

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

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

ERP ใช้เพื่อ "ควบคุม" มากกว่า "ยืดหยุ่น"

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

ความต้องการในการควบคุมและกำกับดูแล

(Control and Governance)

องค์กรขนาดใหญ่มีธุรกรรมจำนวนมาก มีพนักงานหลากหลายฝ่าย และมีข้อกำหนดด้านกฎระเบียบที่เข้มงวดสูง 

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

การรวมศูนย์ข้อมูลและกระบวนการ

(Centralized Data and Processes)

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

ในขณะเดียวกันก็ทำให้การเปลี่ยนแปลงกระบวนการพื้นฐานทำได้ยาก เนื่องจากต้องกระทบกับหลายส่วน

การลงทุนที่สูงและการปรับใช้ที่ซับซ้อน

(High Investment and Complex Implementation)

การติดตั้งและปรับใช้ ERP ในองค์กรขนาดใหญ่เป็นการลงทุนมหาศาล ทั้งในเรื่องของเงิน เวลา และทรัพยากรบุคคล 

การเปลี่ยนแปลงหรือปรับแต่งระบบในภายหลังจึงมีต้นทุนสูงและความเสี่ยงมาก ทำให้องค์กรลังเลที่จะทดลองโมเดลธุรกิจใหม่ๆ ที่อาจต้องรื้อโครงสร้างระบบ

การออกแบบเพื่อกระบวนการที่พิสูจน์แล้ว

(Designed for Proven Processes)

ERP ส่วนใหญ่มักถูกพัฒนาขึ้นจาก Best Practices ของอุตสาหกรรมต่างๆ ซึ่งเป็นกระบวนการที่ได้รับการพิสูจน์แล้วว่ามีประสิทธิภาพ 

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

ความคาดหวังด้านความเสถียรและความน่าเชื่อถือ

(Stability and Reliability)

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

สมบูรณ์แบบคือ "อุปสรรคต่อนวัตกรรม"

ERP ที่มีระบบที่ดีและสมบูรณ์แบบสำหรับโมเดลธุรกิจปัจจุบัน อาจกลายเป็น จุดอ่อน เมื่อองค์กรต้องการทดลองสิ่งใหม่ๆ นั่นเพราะต้องแลกกับความยากลำบากในการทำ POC (Proof of Concept) เพื่อทดลองโมเดลธุรกิจใหม่ที่ไม่เคยมีมาก่อน ซึ่งแทบจะเป็นไปไม่ได้ที่จะสามารถระบุความต้องการ (requirement) ได้ครบถ้วนเพื่อออกแบบระบบให้ใช้งานได้ตั้งแต่ครั้งแรก

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

ERP ในธุรกิจขนาดใหญ่มักเน้นการควบคุมและความเป็นระบบ การยอมให้มีข้อยกเว้นอาจทำให้สูญเสียสมดุลการควบคุม แตกต่างจากธุรกิจขนาดกลางที่ต้องการความยืดหยุ่นและค้นหาโอกาสทางธุรกิจใหม่ ต้องการ "Agility for Innovation" มากกว่า และไม่เหมือนธุรกิจขนาดเล็กที่มีข้อจำกัดของทรัพยากร ต้องการ "Agility for Survival" ระบบอะไรก็ได้ที่สอดคล้องกับทรัพยากรของตน

บทสรุปและข้อคิด

สมมติฐานที่ว่า ERP ขนาดใหญ่มักให้ความสำคัญกับการควบคุมมากกว่าความยืดหยุ่นในการออกแบบโมเดลธุรกิจใหม่ๆ นั้นได้รับการยืนยันจากตัวอย่างที่เราได้เห็น 

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

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

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

---

จากบทร่าง เป็นบทความ

บทความนี้ ผมเริ่มต้นจากเขียนเนื้อหาทั้งหมดขึ้นมาก่อน แล้วใช้ Gemini ช่วยปรับปรุง

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

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

มองต่างมุม

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

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

ต่อไปนี้คือความเห็นวิพากษ์ของ AI 

(1) เหมารวมว่า ERP ไม่ยืดหยุ่นเท่าที่ควร

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

เช่น SAP, Oracle, Microsoft Dynamics หรือแม้แต่ Odoo เอง ต่างก็มีฟีเจอร์หรือ extension mechanism ที่สามารถรองรับ business innovation ได้ ขึ้นอยู่กับวิธีการออกแบบโครงสร้างและการจัดการ lifecycle

(2) ไม่มีการพิจารณา "ปัจจัยร่วม" ที่สำคัญ เช่น

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

วัฒนธรรม: ถ้าองค์กรไม่เอื้อต่อการทดลอง ระบบอะไรก็ช่วยไม่ได้

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

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

(3) ขาดการวิเคราะห์ trade-off หรือข้อดีของระบบ ERP ที่เข้มงวด

ความเข้มงวดของ ERP มีเหตุผล เช่น การควบคุมภาษี ความโปร่งใสใน supply chain หรือการตรวจสอบย้อนหลัง ซึ่งบทความไม่ได้ชี้ให้เห็นข้อดีเหล่านี้เท่าที่ควร

(4) การพัฒนาเสริม (bolt-on, middleware) ไม่ใช่เรื่องแปลก

ความจริงในองค์กรใหญ่ ระบบเสริมเพื่อ support use case พิเศษมักเกิดขึ้นเสมอ และหลาย ERP ยอมรับโมเดลนี้อยู่แล้ว บทความกลับทำให้ผู้อ่านรู้สึกว่านั่นคือ "ความล้มเหลวของ ERP"