Open-source ERP and beyond

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

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

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

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

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

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

(1)

วิถีทางหนึ่งที่ผมเคยคิดไว้ (และเชื่อว่าหลายคนก็เคยคิดคล้ายกัน) คือ การสร้าง de facto standard หรือมาตรฐานที่เกิดจากมีผู้ใช้จำนวนมาก จนถูกอ้างอิงเป็นมาตรฐานได้ ในแง่ของโปรแกรม ERP หมายความว่าต้องทำให้แพร่หลาย แล้วจึงเกิดปฏิกิริยาลูกโซ่ชุมชนที่ใช้โปรแกรมเหมือนกับเพื่อนพ้อง ทำให้สามารถเชื่อมต่อข้อมูลกับคู่ค้าในห่วงโซ่อุปทานของตน และอาจผลักดันไปไกลจนถึงภาครัฐ(ภาษี) หรือภาคการเงิน(ทุน) ยอมรับมาตรฐานดังกล่าว

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

อะไรที่ต้อง implement จะถูกคุมกำเนิดด้วยเวลา เป็นทองคำและบิทคอยน์ ไม่อาจเป็นดอลล่าร์ที่ฟ่องฟู

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

หลังจากที่คิดมาหลายตลบ หวยก็น่าจะออกที่ต้องลงทุน framework ที่รองรับการ implement แบบ no code หรือ low code ลองถอดโปรแกรมเมอร์ออกจากกระบวนการ implement บางทียุทธศาสตร์นี้อาจสำคัญกว่าตัว ERP เองด้วยซ้ำ เท่าที่เจอก็มี ERPNext (อินเดีย) ที่ใกล้เคียง (เรื่องเล่าจาก Ecosoft ลองเอาคีย์เวิร์ดไปหาอ่านกัน)

หน้าตาของโปรแกรมในฝันของผมจึงเป็น open-source ERP + low code framework

ทีนี้ PM อาจจะเริ่มมองเห็นภาพผลิตภัณฑ์ในเชิงยุทธศาสตร์ได้เลาๆ ทั้งสองส่วนเป็นปฏิกิริยาผกผันต่อกัน ยิ่งทำ low code engine ได้ยอดเยี่ยมเท่าไหร่ ส่วนที่เคยเป็นโมดูลเกะกะใน ERP ยิ่งไม่จำเป็นต้องพัฒนาเตรียมไว้ ก็ใช้ low code นั่นแหละพัฒนาขึ้นมาใน layer นั้นแทน

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

มีอยู่เรื่องหนึ่งที่อยากบอกอย่างจริงใจว่า อย่าคาดหวังกับ open-source นอกเหนือจากเป็นอาภรณ์ห่อหุ้มให้สบายใจว่าใครๆ ก็นำไปต่อยอดโดยไม่มีเรื่องของผลประโยชน์เป็นเงื่อนไข "Free to use at your own risk" แต่คงไม่ได้เห็นการพัฒนาปรับปรุงที่เกิดจากความช่วยเหลือของชุมชน ทีมที่เป็นแกนกลางต้องคิดหาโมเดลที่หล่อเลี้ยงยืนระยะผ่านวันเวลาได้ด้วย ผมเห็นตัวอย่างจาก community Odoo ที่เป็น open-source โดยเฉพาะส่วนที่เกี่ยวกับประเทศไทย แทบไม่เห็นการเติบโตขึ้นมาได้เลยทั้งในแง่ผลงานและจำนวนผู้คน เพราะโดยธรรมชาติของงาน ERP ไม่สามารถ contribute กลับไปให้ผู้อื่นใช้ได้ง่าย งาน implement ส่วนใหญ่ขึ้นอยู่กับเงื่อนไข business logic ขององค์กรนั้นๆ ที่ไม่สามารถบอกเล่าสั้นๆ แล้วคนทั่วไปจะเข้าใจ

(2)

วิถีทางที่สอง อาจจะเรียกว่าคิดเล่นๆ เพราะอาจเหนือจริงสุดโต่งเกินไป ผมคิดว่าบางทีน่าจะเลิกคิดทำ ERP ให้ SME 

อินเตอร์เน็ตและทุนนิยมเสรีโดยเฉพาะยุคหลังโควิด Globalization ทำให้รู้สึกว่า S และ M เป็นขนาดองค์กรที่ไม่เสถียร ไม่สามารถยืนระยะได้จริง ต้องพยายามข้ามไปสู่ขนาด L ให้เร็วที่สุด (วิถี startup แต่ทุนนิยมเองก็เริ่มถูกตั้งคำถามว่าจะโตไปเรื่อยๆ ไม่มีวันสิ้นสุด?) หรือหดลงมาเป็น micro/individual แล้วมี network infrastructure ที่เชื่อมโยง 

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

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

ถ้ารัฐสามารถจัดเก็บข้อมูลธุรกรรมที่ระบุคู่กรณีได้ สามารถกลั่นออกมาเป็นอะไรได้มากมาย โดยไม่ต้องสร้างภาระให้เจ้าตัวต้องทำบัญชี เก็บหลักฐานกระดาษอะไรที่ยุ่งยากอย่างทุกวันนี้ น่าจะลองเปลี่ยนนโยบายสนับสนุนจากธุรกิจการค้าที่จัดตั้งองค์กร (enterprise) ย้อนยุคไปสนับสนุนการค้าระดับปัจเจก (individual) ในศิลาจารึกพ่อขุนรามคำแหงที่ว่า "ใครใคร่ค้าช้างค้า ใครใคร่ค้าม้าค้า" แค่เพียงมี QR Code บัญชีประจำตัว เปลี่ยน physical เป็น digital money นั่นหมายถึงวิธีคิดทั้งหลายจะพลิกกลับด้านกันไปหมด ภาพตัวอย่างที่พอเห็นคลับคล้ายคลับคลาที่สุดน่าจะได้แก่ การค้าในท้องถิ่นประเทศจีน

ก้าวข้ามความจำเป็นต้องใช้ ERP จนไม่ต้องถกกันว่า open-source หรือไม่

(3)

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

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

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

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

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

(4)

เมื่อมีหนึ่ง จึงเกิดสอง เมื่อมีสองจึงเกิดสาม เมื่อมีสามจึงตระหนักถึงความสำคัญของหนึ่งและสอง 

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