Small is Beautiful in Enterprise Software

เมื่อ "เล็กนั้นงาม" ในโลกซอฟต์แวร์

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

มันทำให้ผมนึกถึงแนวคิดจากหนังสือ "Small is Beautiful: Economics as if People Mattered" โดย E.F. Schumacher ที่เสนอว่าเราควรแสวงหา "ขนาดที่เหมาะสม" (Appropriate Scale) และใช้ "เทคโนโลยีระดับกลาง" (Intermediate Technology) ที่ผู้คนสามารถเข้าใจ ควบคุม และบำรุงรักษาได้เอง แทนที่จะมุ่งแต่เทคโนโลยีที่ใหญ่ที่สุดหรือซับซ้อนที่สุดเสมอไป

ในขณะเดียวกัน Lawrence Lessig ก็ได้ชี้ให้เห็นในหนังสือ "Remix" ว่ายุคอุตสาหกรรมได้เปลี่ยนจาก "วัฒนธรรมมือสมัครเล่น" (Amateur Culture) ที่ผู้คนสร้างสรรค์สิ่งต่างๆ ขึ้นมาใช้เอง มาสู่ "วัฒนธรรมมืออาชีพ" (Professional Culture) ที่งานสร้างสรรค์ส่วนใหญ่ถูกผูกขาดและผลิตโดยผู้เชี่ยวชาญ ซึ่งกฎหมายลิขสิทธิ์มีบทบาทสำคัญในการขับเคลื่อนการเปลี่ยนแปลงนี้ ในโลกดนตรีเราหยุดเล่นดนตรีเองและหันไปฟังเพลงจากมืออาชีพ ในโลกซอฟต์แวร์ การเขียนโปรแกรมก็กลายเป็นศาสตร์สำหรับผู้เชี่ยวชาญโดยเฉพาะ

เมื่อมองดูโลกซอฟต์แวร์ปัจจุบัน โดยเฉพาะการถกเถียงเรื่อง AI ช่วยเขียนโค้ด คำถามที่ผุดขึ้นในใจคือ: นี่อาจเป็นเพราะเราคุ้นชินกับ "มาตรฐานมืออาชีพ" จนนำมาตรฐานนั้นไปตัดสินผลงานที่ AI หรือแม้แต่คนที่ไม่ใช่โปรแกรมเมอร์สร้างขึ้นหรือไม่? คนธรรมดาทั่วไปจะสามารถสร้าง "โค้ดที่พอใช้งานได้" สำหรับแก้ปัญหาของตัวเองได้จริงหรือ? และแนวคิด "Small is Beautiful" จะเข้ามาเปลี่ยนโฉมหน้าของ ERP และการพัฒนาซอฟต์แวร์โดยรวมได้อย่างไร?

"เล็กนั้นงาม" ในโลกที่ "ใหญ่คือดี"

กระแสหลักในอุตสาหกรรมซอฟต์แวร์ มักจะเน้นการแข่งขันกันด้วยฟังก์ชันที่เยอะที่สุด ประสิทธิภาพที่สูงสุด และขนาดที่ใหญ่ที่สุด ระบบ ERP ก็มักถูกนำเสนอในฐานะโซลูชันแบบ All-in-One ที่พยายามครอบคลุมทุกความต้องการขององค์กร ทำให้มันเป็นระบบที่ใหญ่ ซับซ้อน และต้องการผู้เชี่ยวชาญเฉพาะทางในการดูแลรักษาและปรับแต่ง

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

วัฒนธรรมมืออาชีพกับซอฟต์แวร์

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

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

AI และการคืนชีพของ "โค้ดที่พอใช้งานได้"

การมาถึงของ AI ที่ช่วยเขียนโค้ด กำลังสั่นคลอนสถานะ "มืออาชีพ" นี้ เพราะ AI ทำให้คนที่ไม่เคยเขียนโค้ดมาก่อน สามารถสร้าง "โค้ด" ขึ้นมาได้

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

แต่คำถามคือ "มาตรฐานมืออาชีพ" นั้นจำเป็นสำหรับทุกการใช้งานหรือไม่? หากคนธรรมดาต้องการสคริปต์ง่ายๆ เพื่อทำงานซ้ำๆ ใน Spreadsheet หรือสร้าง Workflow อัตโนมัติเล็กๆ สำหรับงานส่วนตัว "โค้ดที่พอใช้งานได้" ที่สร้างโดย AI หรือเครื่องมือ Low-Code/No-Code ก็มีคุณค่าในตัวเองอย่างมหาศาล

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

"Small is Beautiful" ในการ Customize ERP

หากนำแนวคิด "Small is Beautiful" มาใช้กับการ Customize ERP แทนที่จะมองว่าการปรับแต่งคือการเขียนโค้ดเพิ่มเติมโดยโปรแกรมเมอร์ เราอาจจินตนาการถึง ERP ที่มีหน้าตาแบบนี้:

• เน้นการตั้งค่า (Configuration) ผ่าน User Interface ที่เข้าใจง่าย ผู้ใช้งานทางธุรกิจ หรือ Business Analyst สามารถปรับเปลี่ยน Workflow, เพิ่ม Field ข้อมูล, สร้าง Form หรือ Report ได้เองผ่านหน้าจอที่เป็นมิตร โดยไม่ต้องเขียนโค้ดแม้แต่บรรทัดเดียว

• เครื่องมือสร้าง Workflow/Process แบบ Visual สามารถลากวาง (Drag-and-Drop) เพื่อออกแบบและปรับแต่งขั้นตอนการทำงานในระบบได้ด้วยตัวเอง

• การสร้าง Logic ทางธุรกิจแบบตั้งค่าได้ กำหนด Business Rules ต่างๆ ได้ผ่าน Rule Engine ที่เป็น UI ไม่ใช่การเขียน If/Else ในโค้ด

• เปิดให้เชื่อมต่อผ่าน API ที่ได้มาตรฐาน หากจำเป็นต้องมีการเขียนโค้ด การทำก็จะผ่าน API ที่ชัดเจนและเป็นมาตรฐาน ทำให้โปรแกรมเมอร์เข้าใจง่ายขึ้น หรือแม้แต่ใช้เครื่องมือ Low-Code ในการเชื่อมต่อได้

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

เมื่อ ERP ของแต่ละองค์กรสื่อสารกันได้

ลองขยายภาพออกไปอีกขั้น หาก ERP ของแต่ละองค์กรสามารถสื่อสารกันได้ด้วย "มาตรฐานการสื่อสาร" ที่ตกลงร่วมกันได้จริง เหมือนกับการที่รัฐต่างๆ ในประเทศหนึ่งสื่อสารกันได้ หรือประเทศต่างๆ ในสหภาพสื่อสารกันได้ จะเกิดอะไรขึ้น?

ระบบ ERP ของบริษัท A สามารถส่ง Purchase Order ไปยัง ERP ของบริษัท B ได้โดยตรง เมื่อบริษัท B จัดส่งสินค้า ERP ของบริษัท B ก็สามารถส่งข้อมูลการจัดส่งและ Invoice กลับไปยัง ERP ของบริษัท A ได้โดยอัตโนมัติ

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

นี่คือการนำแนวคิด "Small is Beautiful" มาใช้ในระดับ Ecosystem โดยมองแต่ละองค์กรที่มี ERP เป็น "โมดูล" ที่มีความสามารถในการบริหารจัดการภายในที่ดี (เล็กในบริบทนี้คือไม่พยายามเป็นทุกอย่างสำหรับทุกองค์กรภายนอก) และเชื่อมต่อกันด้วย "มาตรฐาน" ที่เรียบง่ายและมีประสิทธิภาพเพียงพอ

ทำไมวิสัยทัศน์นี้ยังไม่เป็นจริงง่ายๆ

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

• การขาดมาตรฐานกลางที่ได้รับการยอมรับและพร้อมใช้งาน ยังไม่มี "ภาษากลาง" ที่ทุก ERP และทุกองค์กรยอมรับและนำไปใช้ได้ง่ายๆ

• ความซับซ้อนทางเทคนิคและการลงทุน การปรับระบบเดิม การทำ Data Mapping และการดูแลรักษาการเชื่อมต่อยังต้องใช้ความเชี่ยวชาญและงบประมาณสูง

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

• ปัญหาด้านการกำกับดูแลและกฎหมาย การตกลงในข้อกำหนดการให้บริการ (SLA) และการจัดการเมื่อเกิดข้อผิดพลาดระหว่างระบบของนิติบุคคลต่างกันเป็นเรื่องที่ซับซ้อน

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

การพยายาม "ผลักดัน" ให้เกิดการเชื่อมต่อขนานใหญ่จากบนลงล่าง มักจะติดหล่มกับปัจจัยเหล่านี้

เส้นทางที่ "เป็นธรรมชาติ" สู่การเชื่อมต่อ

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

• เริ่มจากความต้องการที่แท้จริง แก้ปัญหาเฉพาะหน้าที่การเชื่อมต่อระบบจะช่วยได้ ระหว่างคู่ค้าที่มีความสัมพันธ์สำคัญต่อกันก่อน

• การขับเคลื่อนโดยผู้นำตลาด ผู้เล่นรายใหญ่กำหนดมาตรฐานการสื่อสารของตน ซึ่งผลักดันให้คู่ค้ารายย่อยต้องปรับตัวตาม

• ความร่วมมือในอุตสาหกรรม บริษัทในอุตสาหกรรมเดียวกันรวมตัวกันกำหนดมาตรฐานเพื่อประโยชน์ร่วมกัน

• การเกิดมาตรฐานโดยพฤตินัย เมื่อเทคโนโลยีหรือเครื่องมือสำหรับการเชื่อมต่อ (เช่น API, iPaaS) ใช้งานง่ายและได้รับความนิยม ก็จะกลายเป็นมาตรฐานที่คนนิยมใช้ตามๆ กันไป

• การแสดงให้เห็นผลลัพธ์ที่เป็นรูปธรรม กรณีศึกษาความสำเร็จในการเชื่อมต่อที่แสดง ROI ที่ชัดเจน จะเป็นแรงจูงใจให้ผู้อื่นนำไปทำตาม

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

บทสรุป "เล็กนั้นงาม" และเชื่อมต่อถึงกัน

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

การมาถึงของ AI และเครื่องมือ Low-Code/No-Code กำลังช่วยฟื้นคืน "วัฒนธรรมมือสมัครเล่น" ในการสร้างสรรค์ซอฟต์แวร์ขนาด "Small" เพื่อแก้ปัญหาเฉพาะหน้า

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

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

---

จากบทสนทนา สู่บทความ

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

ในใจลึกๆ ยังรู้สึกว่าการออกแบบโปรแกรมให้สามารถ customize ได้อย่างนี้ต้อง "แลกกับอะไร" ข้อจำกัดหรือเพดานรออยู่ตรงไหน บางทีสิ่งนั้นมันยังไม่ปรากฏมาให้เห็น บทเรียนในแวดวง software engineer เราได้เห็นว่าสำหรับบางคนเมื่อเดินไปสุดทาง microservices ก็เลือกที่จะย้อนกลับมา monolithic อีกครั้ง 

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

Henry David Thoreau บอกว่า 

"A man thinking or working will always be alone, 

let hime be where he will."

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

..เมื่อมือสมัครเล่นลองให้ AI ช่วยเรียบเรียงความคิดที่กระจัดกระจาย มาเป็นบทความที่อ่านรู้เรื่อง(กว่าเขียนเอง)

ผมให้คุณมาร่วมอภิปรายหัวข้อ "small is beautiful" โดยเน้นไปในแวดวงของการพัฒนาซอฟต์แวร์ ในฐานะที่ผมเป็นโปรแกรมเมอร์ที่พัฒนา ERP ซึ่งจะมีงาน implement ที่ต้อง customize โปรแกรมบางส่วนให้สอดคล้องกับระบบงานของแต่ละที่ แนวคิดหลักของผมอยากนำเสนอ เริ่มต้นจาก หนังสือ small is beautiful ของ E.F. Schumacher ที่บอกว่าเราควรคิดถึงขนาดที่เหมาะสมกับความต้องการใช้งาน เช่น เทคโนโลยีระดับกลางที่ใช้งานได้ ฯลฯ ขณะที่กระแสของโลกปัจจุบัน กลับสร้างค่านิยมให้เราแข่งขันกันไปจนสุดขอบ ในหนังสือ Remix โดย Lawrence Lessig บอกว่า ยุคอุตสาหกรรมทำให้ "วัฒนธรรมมือสมัครเล่นถูกแทนที่ด้วยวัฒนธรรมมืออาชีพ" เช่น ดนตรี รวมถึงซอฟต์แวร์ กลไกลิขสิทธิ์ ทำให้ถูกผูกขาดว่าจะงานเหล่านั้นต้องสร้างสรรค์จากมืออาชีพเท่านั้น ปัจจุบันในแวดวงซอฟต์แวร์ มีการถกเถียงกันเรื่อง AI ช่วยเขียนโค้ด ซึ่งผมมีความคิดว่า อาจจะเป็นความเคยชินของวัฒนธรรมมือชีพ ทำให้บางคนใช้มาตรฐานนี้ตัดสินผลงานเหล่านั้นหรือเปล่า คนที่ไม่ใช่โปรแกรมเมอร์ สามารถสร้างโค้ดที่พอ "ใช้งานได้" สำหรับใช้งานเองได้หรือไม่? หาทำได้การออกแบบ ERP ที่ implement โดยไม่ต้องอาศัยโปรแกรมเมอร์ จะมีหน้าตาเป็นอย่างไร?

…

แนวคิดนี้มีข้อบกพร่องหรือข้อจำกัด ในบริบทใดบ้าง

…

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

…

ถ้าคิดภาพที่ใหญ่กว่านั้น ERP เมื่อมีมาตรฐานสื่อสาร ก็สามารถเชื่อมต่อระหว่างองค์กรได้ เหมือนกับรัฐ จากรัฐรวมเป็นประเทศ เช่น อเมริกา ประเทศรวมเป็นสหภาพ เช่น สหภาพยุโรป

…

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

…

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

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