ERP Implementation, Big and Small

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

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

กลายเป็นว่ามีกิจการหลายแห่งที่ใช้วิธีนี้ หากมีแปลนต้องส่งของตอนเช้า จะเปิดบิลลงวันที่พรุ่งนี้เตรียมไว้ตั้งแต่ตอนเย็น เพื่อให้ฝ่ายจัดส่งสามารถทำงานต่อได้ทันทีในเช้าของวันรุ่งขึ้น ผมจึงตั้งคำถามว่า หากทำเช่นนี้ทราบไหมว่าเมื่อเปิดบิลเกิดอะไรขึ้นบ้าง เช่น สินค้าที่ขายจะถูกบันทึกตัดยอดออกจากสต็อค ดังนั้นยอดคงเหลือที่เห็นจึงเป็นตัวเลขของอนาคต ไม่ใช่วันนี้ หากมีแผนกอื่นที่เขามอนิเตอร์ข้อมูลนี้อยู่ ก็อาจจะเข้าใจผิด ทุกคนในทีมที่เคยดูแลผู้ใช้ตอบในทำนองเดียวกันว่า ผู้ใช้เข้าใจและให้ความสำคัญเรื่องลัดขั้นตอนกระบวนการทำงานมากกว่าปัญหาความคลาดเคลื่อนของข้อมูล ชั่วขณะที่วันที่ในบิลกับเวลาจริงยังไม่ทันกัน คือ แผนกจัดส่งไม่ต้องเสียเวลารอเปิดบิลตอนเช้า
 
จึงเป็นธรรมชาติของกิจการขนาดเล็ก ที่วันที่ที่ระบุในบิลซึ่งมีผลทางบัญชี ไม่จำเป็นต้องยึดโยงตามเส้นเวลาจริงเสมอไป อาจมีการย้อนกลับไปแก้ไขสิ่งที่ล่วงเลยมาแล้ว หรือเตรียมงานล่วงหน้าเพื่อความสะดวกรวดเร็ว
 
มีเรื่องเล่าถึงการประชุมครั้งหนึ่ง เป็นกิจการที่ขนาดไม่เล็กแล้วเพราะมีผู้จัดการแผนกต่าง ๆ รับผิดชอบงานในส่วนของตน แต่ละแผนกก็จะทำรายงานสรุปผลงานมานำเสนอ ปรากฎว่าเมื่อมีตัวเลขบางชุดที่พาดพิงไปถึงแผนกอื่น หลายครั้งที่เป็นการปะทะกันของตัวเลขเรื่องเดียวกันแต่ไม่ตรงกัน แล้วก็จบลงที่ "ข้อมูลที่ใช้สรุปเก็บมาตั้งแต่เมื่อไหร่" สาเหตุเกิดจากข้อมูลเก่ามีโอกาสเขยื้อนเมื่อเวลาผ่านไป ไม่ทันฉุกคิดว่าวิธีเก็บข้อมูลสะสมต่อกันไปเรื่อย ๆ เดือนต่อเดือนอาจล้าสมัยได้
 
"SD + MM"
 
อ้างอิงตามชื่อโมดูลของ SAP - SD (Sale & Delivery) เกี่ยวข้องกับระบบงานขายและจัดส่ง อีกระบบหนึ่ง MM (Material Management) เป็นชื่อโมดูลดั้งเดิมตั้งแต่ใช้กับธุรกิจการผลิต เกี่ยวข้องกับการจัดซื้อและสต็อควัตถุดิบคงเหลือ เมื่อเอามาใช้กับธุรกิจเทรดดิ้ง ไม่มีส่วนงานวางแผนการผลิต จึงกลายเป็นจัดซื้อและดูแลสต็อคสินค้า (Purchase and Supply Chain)
 
โปรแกรม ERP ส่วนใหญ่ก็มักอ้างอิงตามโครงสร้างของ SAP รวมไปถึงการจัดผังองค์กรให้แยกหน้าที่รับผิดชอบออกจากกัน แผนกขาย กับ แผนกซื้อ
 
กิจการที่เคยพบเจอ มีอย่างน้อย 2 แห่งที่ไม่ได้มีผังองค์กรตามนั้น พนักงานขายนอกจากเสนอขายสินค้าแล้ว มีหน้าที่สั่งซื้อสินค้าด้วย เมื่อปิดการขายได้ออเดอร์จากลูกค้าแล้ว จะต้องระบุรายการสินค้า(และผู้จัดจำหน่าย)เพื่อที่ขอให้จัดซื้อมาด้วย ระบบยืนยันขายสินค้าของที่นี่จึงมีความสามารถพิเศษหาซื้อสินค้าได้ด้วย รายการที่ขาย ถ้าไม่มีสต็อคจะต้องมีรายการขอซื้อประกบอยู่ด้วย

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

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

โปรแกรมจึงออกแบบให้การทำงานเอกสารต่าง ๆ มีคุณสมบัติ 2 in 1 เป็นทั้งเอกสารการเงินและเอกสารบัญชีแยกประเภท (Dr/Cr) ในใบเดียวกัน หากมีการแก้ไขรายการหรือจำนวนเงิน ก็จะกระทบกับรายการลงบัญชีคู่อัตโนมัติ
 
การพัฒนาระบบ ERP ให้องค์กรลักษณะนี้ ค่อนข้างราบรื่นเพราะผู้ใช้งานเป็นผู้รับผิดชอบ สามารถตัดสินใจได้ว่าต้องการใช้งานอย่างไร
 
"ช่วย ๆ กัน"
 
องค์กรบางแห่ง มีลักษณะตรงข้าม ไม่มีผู้รับผิดชอบชัดเจน ถึงแม้ว่าจะแบ่งงานกันทำ แต่มีความเป็นคร่าว ๆ สามารถสลับสับเปลี่ยน ขึ้นอยู่ว่าตอนนั้นใครว่าง หรือถ้างานเร่งก็จะช่วยกันรุมทำได้
 
มุมสะท้อนกลับ จะเกิดพื้นที่เป็นสูญญากาศ ต่างคนก็นึกว่า เดี๋ยวจะมีใครสักคนทำ บางครั้งเมื่อเกิดปัญหาหรือความผิดพลาด ก็ไม่สามารถสืบสาวราวเรื่องได้กระจ่าง หากเป็นปัญหาที่เกี่ยวข้องกับบุคคลภายนอก ก็ทำให้เกิดภาพของการโยนเรื่องกันไปมา หรือสูญญากาศของการแก้ปัญหา แต่ที่จริงเป็นเพราะไม่รู้ว่าใครเป็นผู้รับผิดชอบ
 
เคยมีกรณีกิจการแห่งหนึ่ง ช่วงที่จะต้องรีบจัดของให้ทันรถขนส่งที่มารอ จึงกลายเป็นเฮกันไปช่วยกันจัดของ แล้วก็เฮกันมาช่วยเปิดบิล กลายเป็นความสับสนอลหม่าน การพัฒนาระบบให้ใช้งานจึงเดินหน้าสองก้าว ถอยหลังหนึ่งก้าว กลับมาสื่อสารทำความเข้าใจให้ทั่วถึงก่อนที่จะเปลี่ยนแปลง หรือทำอะไรใหม่มาให้ใช้งาน
 
Big and Small..
 
ในวันที่กลับมาทบทวน เรื่องราวของกิจการต่าง ๆ ที่ใช้โปรแกรม ผมพบว่าแต่ละแห่งมีความอินดี้หรือออกนอกกรอบแตกต่างกันไป ทีมเล็กต้องคิดยุทธศาสตร์ให้สอดคล้องกับคุณสมบัติของคนในทีม การพัฒนาระบบให้ใช้งานจึงต้องมีความยืดหยุ่นปรับเปลี่ยนให้สอดคล้องกับคน ไม่เหมือนกับวิธีคิดขององค์กรใหญ่ที่สามารถกำหนดยุทธศาสตร์ไว้ก่อน พัฒนาระบบตามแผนที่วางไว้ หากจุดไหนก็ยังติดขัดหรือไม่มีผู้รับผิดชอบพิจารณาเพิ่มหรือปรับเปลี่ยนคนเพื่อให้สามารถทำงานตามกรอบที่วางไว้
 
"What got you here won' t get you there"
 
สำหรับผู้บริหารองค์กรขนาดเล็ก ไม่ควรยึดติดกระบวนท่าที่ทำให้ประสบความสำเร็จ เพราะอาจจะใช้ไม่ได้เมื่อเติบโตไปอีกระดับหนึ่ง
 
ไม่ว่าเล็กหรือใหญ่ต่างก็มีจุดได้เปรียบและเสียเปรียบแตกต่างกัน ผมมีข้อควรระวังที่ผู้พัฒนาระบบต้องเตือนตัวเองเช่นกัน "อย่าเอาวิธีจัดทัพขององค์กรใหญ่ไปใช้กับองค์กรเล็ก"